Promote Golang Traffic Monitor to Default

[Jeff Elsloo <el...@apache.org>]

Hi all,

We currently have two versions of Traffic Monitor: Java and golang.
When we build all components, as far as I know, it results in a race
condition between the two, as the resulting RPMs have the same
filename. A PR[1] was opened to address the issue and the approach was
to add `_go` to the version string used for the golang version's RPM.

Rob and I both think we (Comcast) have enough experience running the
golang version that we have identified and corrected any major issues
and that it is stable enough to be the preferred Traffic Monitor hence
forth.

Therefore, I propose that within the project's directory structure, we:
  1) rename traffic_monitor to traffic_monitor_legacy
  2) rename traffic_monitor_golang to traffic_monitor

..then work with the person that submitted the PR to take the same
approach, except change the Java version's RPM name to contain
`_legacy`.

I realize that this is a fairly significant change, the type that we
typically reserve for major releases. The next major release, 3.0.0,
is likely to be some time out in the future, and I don't know that we
need to wait for it in order to make this change.

How does the group feel about the above proposal, and executing on it
prior to the 3.0.0 release (i.e.: for 2.1.0)? Then, when we do
actually prepare the 3.0.0 release, we can remove the Java version
from the codebase entirely. Obviously this could impact anyone that
has automated CI systems building components, in addition to the
Apache CI we use ourselves.

Thoughts?

[1] https://github.com/apache/incubator-trafficcontrol/pull/731
--
Thanks,
Jeff

Re: Promote Golang Traffic Monitor to Default

[Jeff Elsloo <el...@apache.org>]

I think we can handle the config file differences with a release note
for 2.2.0, with a note that the Java version has been officially
deprecated and will be retired in the next release. I think that
allows people time to get to the new version without being too heavy
handed in the project's repo prior to 2.3.
--
Thanks,
Jeff


On Mon, Oct 23, 2017 at 3:07 PM, Hongfei Zhang (hongfezh)
<ho...@cisco.com> wrote:
> thanks. can we document the usage of the new directives then? a simple read me in configure dir?
>
> On Oct 23, 2017, at 5:03 PM, Dave Neuman <ne...@apache.org>> wrote:
>
> I don't think the rpm upgrade will take care of this for you.  This will be
> a one-time manual upgrade.
>
> On Mon, Oct 23, 2017 at 2:59 PM, Hongfei Zhang (hongfezh) <
> hongfezh@cisco.com<ma...@cisco.com>> wrote:
>
> Hi,
>
> We noticed the new Go Monitor uses two config files and these files are
> incompatible with the Java implementation. Some config directive's name
> also changed.  Will/should the rpm upgrade be able to take care of the
> config file conversion/split?
>
> Thanks,
> -Hongfei
>
> -----Original Message-----
> From: Nir Sopher [mailto:nirs@qwilt.com]
> Sent: Monday, October 23, 2017 3:34 PM
> To: dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>
> Subject: Re: Promote Golang Traffic Monitor to Default
>
> Hi,
>
> What would be the content of 2.2?
> If we want to have very limited content as suggested in the summit, I
> would suggest to leave Java TM, removing it only on TC 2.3.
>
> If the 2.2 version has substantial content, I would see leaving the old TM
> as part of the release as a liability. Old TM should be adjusted to the
> changes and tested regularly.
> So in this case, if there are no automated tests to cover its
> functionality, I would suggest to remove Java TM from the code base.
>
> Nir
>
> On Mon, Oct 23, 2017 at 5:58 PM, Jeff Elsloo <el...@apache.org>> wrote:
>
> Hi all,
>
> Apologies for the delay, and thanks to Rob for submitting PR 1427 to
> take care of this. I just merged his PR and that means that
> `traffic_monitor` has been renamed to `traffic_monitor_java` and
> `traffic_monitor_golang` has been renamed to `traffic_monitor` (thanks
> Rob!). This means that we are now one step closer to formally retiring
> the Java version of Traffic Monitor.
>
> Before proposing a vote, I'd like to get a feel for how quickly we can
> do the formal retirement. We're currently working on 2.1 so that means
> that we could retire it as early as 2.2. If we want to be more
> conservative, we could keep both with the renamed structure for 2.2,
> and remove the Java version in 2.3. This is the direction I'm leaning,
> though I'd like to hear from interested parties first.
>
> Thoughts?
> --
> Thanks,
> Jeff
>
>
> On Mon, Jul 24, 2017 at 8:23 AM, Jeff Elsloo <el...@apache.org>> wrote:
> It sounds like we do not have any -1s on this, so I'm going to
> assume we're good to make this change. I have some other things to
> focus on at the moment, but will try to get this done as time
> permits. I'll send another email out with details when I go to make
> the change, and will allow some time before pushing anything in case
> someone has concerns.
> --
> Thanks,
> Jeff
>
>
> On Mon, Jul 17, 2017 at 2:14 PM, Dave Neuman <ne...@apache.org>>
> wrote:
> +1 on the rename
>
> On Mon, Jul 17, 2017 at 10:23 AM, Jan van Doorn <jv...@knutsel.com>>
> wrote:
>
> +1
>
> On Mon, Jul 17, 2017 at 9:47 AM Dewayne Richardson
> <de...@gmail.com>>
> wrote:
>
> When:   Read · Mon, Jul 17.
> <https://timyo.com/?utm_source=expectationheader&utm_medium=emai
> l>
> [image: Timyo expectation line]
> +1
>
> On Fri, Jul 14, 2017 at 2:49 PM, Jeff Elsloo <el...@apache.org>>
> wrote:
>
> For the most part, it's a drop in replacement for the Java
> version, and based on our own experience it seems to work
> exactly as the
> Java
> version would, including co-existence. There is a TO API
> dependency for monitoring.json that the Java version does not
> have, and I'm
> not
> sure what the history is with that endpoint and how far back
> we
> could
> remain compatible. Traffic Router does not care what version
> of Traffic Monitor it talks to, as the format of
> cr-states.json has
> not
> changed. Same goes for TM and ATS. I believe we had
> co-existence running in production going back to the 1.8.x
> releases.
>
> Keep in mind that the intent is to drive users toward using
> the
> Golang
> component by default starting with the 2.1.0 (or maybe 2.2.0?)
> release
> while still allowing one to build, run, or contribute to the
> Java version until our next major release (3.0.0). The intent
> is not to give people a drop in replacement that works with
> prior versions;
> we
> have not tested that thoroughly across all versions, and while
> it might work, we should think of the Golang Traffic Monitor
> as a
> 2.0.x
> and onward component. I think that statement holds for most of
> our components; we wouldn't want to run a 1.7 Traffic Stats
> with a
> 2.0.0
> Traffic Ops system. 1.7 is ancient, and have we ever really
> done backward compatibility testing with versions?
>
> To this end, if we do decide to make the Golang version the
> default in
> the future, at a minimum we will need to provide release notes
> that explain how to convert the Java configuration to the
> Golang
> version's
> config. Ideally we would provide a simple script to convert
> the configuration for our users, potentially running it as a
> postinstall
> scriptlet in the RPM if the Java version is already installed.
> Theoretically we could `yum upgrade traffic_monitor` and
> seamlessly move from Java to Golang.
> --
> Thanks,
> Jeff
>
>
> On Fri, Jul 14, 2017 at 2:07 PM, Eric Friedrich (efriedri)
> <ef...@cisco.com>> wrote:
> I think I remember Rob making this point in Miami, but all
> of TMs
> APIs
> (REST, CRConfig, Health.json, etc…) are identical between the
> Java
> and
> Golang version, right?
>
> What about compatibility with earlier versions of TC?
>
> For example:
> - Can a TC1.7 traffic ops configure a Golang TM?
> - Does the Golang TM have any dependencies on a certain
> version
> of
> TrafficServer or astats?
> - Whats the minimum required version of Traffic Router to
> use the
> Golang
> TM?
> - I know Golang TMs can gossip with Java TMs, but can we mix
> versions
> here too? (i.e. TC1.7 Java TM with TC2.1 Golang TM)?
>
> —Eric
>
>
> On Jul 14, 2017, at 1:00 PM, Jeff Elsloo
> <el...@apache.org>>
> wrote:
>
> Hi all,
>
> We currently have two versions of Traffic Monitor: Java and
> golang.
> When we build all components, as far as I know, it results
> in a
> race
> condition between the two, as the resulting RPMs have the
> same filename. A PR[1] was opened to address the issue and
> the
> approach
> was
> to add `_go` to the version string used for the golang
> version's
> RPM.
>
> Rob and I both think we (Comcast) have enough experience
> running the
> golang version that we have identified and corrected any
> major
> issues
> and that it is stable enough to be the preferred Traffic
> Monitor
> hence
> forth.
>
> Therefore, I propose that within the project's directory
> structure,
> we:
> 1) rename traffic_monitor to traffic_monitor_legacy
> 2) rename traffic_monitor_golang to traffic_monitor
>
> ..then work with the person that submitted the PR to take
> the
> same
> approach, except change the Java version's RPM name to
> contain `_legacy`.
>
> I realize that this is a fairly significant change, the
> type
> that we
> typically reserve for major releases. The next major
> release,
> 3.0.0,
> is likely to be some time out in the future, and I don't
> know
> that
> we
> need to wait for it in order to make this change.
>
> How does the group feel about the above proposal, and
> executing
> on
> it
> prior to the 3.0.0 release (i.e.: for 2.1.0)? Then, when we
> do actually prepare the 3.0.0 release, we can remove the
> Java
> version
> from the codebase entirely. Obviously this could impact
> anyone
> that
> has automated CI systems building components, in addition
> to the Apache CI we use ourselves.
>
> Thoughts?
>
> [1]
> https://github.com/apache/incubator-trafficcontrol/pull/731
> --
> Thanks,
> Jeff
>
>
>
>
>
>

Re: Promote Golang Traffic Monitor to Default

["Hongfei Zhang (hongfezh)" <ho...@cisco.com>]

thanks. can we document the usage of the new directives then? a simple read me in configure dir?

On Oct 23, 2017, at 5:03 PM, Dave Neuman <ne...@apache.org>> wrote:

I don't think the rpm upgrade will take care of this for you.  This will be
a one-time manual upgrade.

On Mon, Oct 23, 2017 at 2:59 PM, Hongfei Zhang (hongfezh) <
hongfezh@cisco.com<ma...@cisco.com>> wrote:

Hi,

We noticed the new Go Monitor uses two config files and these files are
incompatible with the Java implementation. Some config directive's name
also changed.  Will/should the rpm upgrade be able to take care of the
config file conversion/split?

Thanks,
-Hongfei

-----Original Message-----
From: Nir Sopher [mailto:nirs@qwilt.com]
Sent: Monday, October 23, 2017 3:34 PM
To: dev@trafficcontrol.incubator.apache.org<ma...@trafficcontrol.incubator.apache.org>
Subject: Re: Promote Golang Traffic Monitor to Default

Hi,

What would be the content of 2.2?
If we want to have very limited content as suggested in the summit, I
would suggest to leave Java TM, removing it only on TC 2.3.

If the 2.2 version has substantial content, I would see leaving the old TM
as part of the release as a liability. Old TM should be adjusted to the
changes and tested regularly.
So in this case, if there are no automated tests to cover its
functionality, I would suggest to remove Java TM from the code base.

Nir

On Mon, Oct 23, 2017 at 5:58 PM, Jeff Elsloo <el...@apache.org>> wrote:

Hi all,

Apologies for the delay, and thanks to Rob for submitting PR 1427 to
take care of this. I just merged his PR and that means that
`traffic_monitor` has been renamed to `traffic_monitor_java` and
`traffic_monitor_golang` has been renamed to `traffic_monitor` (thanks
Rob!). This means that we are now one step closer to formally retiring
the Java version of Traffic Monitor.

Before proposing a vote, I'd like to get a feel for how quickly we can
do the formal retirement. We're currently working on 2.1 so that means
that we could retire it as early as 2.2. If we want to be more
conservative, we could keep both with the renamed structure for 2.2,
and remove the Java version in 2.3. This is the direction I'm leaning,
though I'd like to hear from interested parties first.

Thoughts?
--
Thanks,
Jeff


On Mon, Jul 24, 2017 at 8:23 AM, Jeff Elsloo <el...@apache.org>> wrote:
It sounds like we do not have any -1s on this, so I'm going to
assume we're good to make this change. I have some other things to
focus on at the moment, but will try to get this done as time
permits. I'll send another email out with details when I go to make
the change, and will allow some time before pushing anything in case
someone has concerns.
--
Thanks,
Jeff


On Mon, Jul 17, 2017 at 2:14 PM, Dave Neuman <ne...@apache.org>>
wrote:
+1 on the rename

On Mon, Jul 17, 2017 at 10:23 AM, Jan van Doorn <jv...@knutsel.com>>
wrote:

+1

On Mon, Jul 17, 2017 at 9:47 AM Dewayne Richardson
<de...@gmail.com>>
wrote:

When:   Read · Mon, Jul 17.
<https://timyo.com/?utm_source=expectationheader&utm_medium=emai
l>
[image: Timyo expectation line]
+1

On Fri, Jul 14, 2017 at 2:49 PM, Jeff Elsloo <el...@apache.org>>
wrote:

For the most part, it's a drop in replacement for the Java
version, and based on our own experience it seems to work
exactly as the
Java
version would, including co-existence. There is a TO API
dependency for monitoring.json that the Java version does not
have, and I'm
not
sure what the history is with that endpoint and how far back
we
could
remain compatible. Traffic Router does not care what version
of Traffic Monitor it talks to, as the format of
cr-states.json has
not
changed. Same goes for TM and ATS. I believe we had
co-existence running in production going back to the 1.8.x
releases.

Keep in mind that the intent is to drive users toward using
the
Golang
component by default starting with the 2.1.0 (or maybe 2.2.0?)
release
while still allowing one to build, run, or contribute to the
Java version until our next major release (3.0.0). The intent
is not to give people a drop in replacement that works with
prior versions;
we
have not tested that thoroughly across all versions, and while
it might work, we should think of the Golang Traffic Monitor
as a
2.0.x
and onward component. I think that statement holds for most of
our components; we wouldn't want to run a 1.7 Traffic Stats
with a
2.0.0
Traffic Ops system. 1.7 is ancient, and have we ever really
done backward compatibility testing with versions?

To this end, if we do decide to make the Golang version the
default in
the future, at a minimum we will need to provide release notes
that explain how to convert the Java configuration to the
Golang
version's
config. Ideally we would provide a simple script to convert
the configuration for our users, potentially running it as a
postinstall
scriptlet in the RPM if the Java version is already installed.
Theoretically we could `yum upgrade traffic_monitor` and
seamlessly move from Java to Golang.
--
Thanks,
Jeff


On Fri, Jul 14, 2017 at 2:07 PM, Eric Friedrich (efriedri)
<ef...@cisco.com>> wrote:
I think I remember Rob making this point in Miami, but all
of TMs
APIs
(REST, CRConfig, Health.json, etc…) are identical between the
Java
and
Golang version, right?

What about compatibility with earlier versions of TC?

For example:
- Can a TC1.7 traffic ops configure a Golang TM?
- Does the Golang TM have any dependencies on a certain
version
of
TrafficServer or astats?
- Whats the minimum required version of Traffic Router to
use the
Golang
TM?
- I know Golang TMs can gossip with Java TMs, but can we mix
versions
here too? (i.e. TC1.7 Java TM with TC2.1 Golang TM)?

—Eric


On Jul 14, 2017, at 1:00 PM, Jeff Elsloo
<el...@apache.org>>
wrote:

Hi all,

We currently have two versions of Traffic Monitor: Java and
golang.
When we build all components, as far as I know, it results
in a
race
condition between the two, as the resulting RPMs have the
same filename. A PR[1] was opened to address the issue and
the
approach
was
to add `_go` to the version string used for the golang
version's
RPM.

Rob and I both think we (Comcast) have enough experience
running the
golang version that we have identified and corrected any
major
issues
and that it is stable enough to be the preferred Traffic
Monitor
hence
forth.

Therefore, I propose that within the project's directory
structure,
we:
1) rename traffic_monitor to traffic_monitor_legacy
2) rename traffic_monitor_golang to traffic_monitor

..then work with the person that submitted the PR to take
the
same
approach, except change the Java version's RPM name to
contain `_legacy`.

I realize that this is a fairly significant change, the
type
that we
typically reserve for major releases. The next major
release,
3.0.0,
is likely to be some time out in the future, and I don't
know
that
we
need to wait for it in order to make this change.

How does the group feel about the above proposal, and
executing
on
it
prior to the 3.0.0 release (i.e.: for 2.1.0)? Then, when we
do actually prepare the 3.0.0 release, we can remove the
Java
version
from the codebase entirely. Obviously this could impact
anyone
that
has automated CI systems building components, in addition
to the Apache CI we use ourselves.

Thoughts?

[1]
https://github.com/apache/incubator-trafficcontrol/pull/731
--
Thanks,
Jeff

Re: Promote Golang Traffic Monitor to Default

[Dave Neuman <ne...@apache.org>]

I don't think the rpm upgrade will take care of this for you.  This will be
a one-time manual upgrade.

On Mon, Oct 23, 2017 at 2:59 PM, Hongfei Zhang (hongfezh) <
hongfezh@cisco.com> wrote:

> Hi,
>
> We noticed the new Go Monitor uses two config files and these files are
> incompatible with the Java implementation. Some config directive's name
> also changed.  Will/should the rpm upgrade be able to take care of the
> config file conversion/split?
>
> Thanks,
> -Hongfei
>
> -----Original Message-----
> From: Nir Sopher [mailto:nirs@qwilt.com]
> Sent: Monday, October 23, 2017 3:34 PM
> To: dev@trafficcontrol.incubator.apache.org
> Subject: Re: Promote Golang Traffic Monitor to Default
>
> Hi,
>
> What would be the content of 2.2?
> If we want to have very limited content as suggested in the summit, I
> would suggest to leave Java TM, removing it only on TC 2.3.
>
> If the 2.2 version has substantial content, I would see leaving the old TM
> as part of the release as a liability. Old TM should be adjusted to the
> changes and tested regularly.
> So in this case, if there are no automated tests to cover its
> functionality, I would suggest to remove Java TM from the code base.
>
> Nir
>
> On Mon, Oct 23, 2017 at 5:58 PM, Jeff Elsloo <el...@apache.org> wrote:
>
> > Hi all,
> >
> > Apologies for the delay, and thanks to Rob for submitting PR 1427 to
> > take care of this. I just merged his PR and that means that
> > `traffic_monitor` has been renamed to `traffic_monitor_java` and
> > `traffic_monitor_golang` has been renamed to `traffic_monitor` (thanks
> > Rob!). This means that we are now one step closer to formally retiring
> > the Java version of Traffic Monitor.
> >
> > Before proposing a vote, I'd like to get a feel for how quickly we can
> > do the formal retirement. We're currently working on 2.1 so that means
> > that we could retire it as early as 2.2. If we want to be more
> > conservative, we could keep both with the renamed structure for 2.2,
> > and remove the Java version in 2.3. This is the direction I'm leaning,
> > though I'd like to hear from interested parties first.
> >
> > Thoughts?
> > --
> > Thanks,
> > Jeff
> >
> >
> > On Mon, Jul 24, 2017 at 8:23 AM, Jeff Elsloo <el...@apache.org> wrote:
> > > It sounds like we do not have any -1s on this, so I'm going to
> > > assume we're good to make this change. I have some other things to
> > > focus on at the moment, but will try to get this done as time
> > > permits. I'll send another email out with details when I go to make
> > > the change, and will allow some time before pushing anything in case
> > > someone has concerns.
> > > --
> > > Thanks,
> > > Jeff
> > >
> > >
> > > On Mon, Jul 17, 2017 at 2:14 PM, Dave Neuman <ne...@apache.org>
> wrote:
> > >> +1 on the rename
> > >>
> > >> On Mon, Jul 17, 2017 at 10:23 AM, Jan van Doorn <jv...@knutsel.com>
> > wrote:
> > >>
> > >>> +1
> > >>>
> > >>> On Mon, Jul 17, 2017 at 9:47 AM Dewayne Richardson
> > >>> <de...@gmail.com>
> > >>> wrote:
> > >>>
> > >>> > When:   Read · Mon, Jul 17.
> > >>> > <https://timyo.com/?utm_source=expectationheader&utm_medium=emai
> > >>> > l>
> > >>> > [image: Timyo expectation line]
> > >>> > +1
> > >>> >
> > >>> > On Fri, Jul 14, 2017 at 2:49 PM, Jeff Elsloo <el...@apache.org>
> > wrote:
> > >>> >
> > >>> > > For the most part, it's a drop in replacement for the Java
> > >>> > > version, and based on our own experience it seems to work
> > >>> > > exactly as the
> > Java
> > >>> > > version would, including co-existence. There is a TO API
> > >>> > > dependency for monitoring.json that the Java version does not
> > >>> > > have, and I'm
> > not
> > >>> > > sure what the history is with that endpoint and how far back
> > >>> > > we
> > could
> > >>> > > remain compatible. Traffic Router does not care what version
> > >>> > > of Traffic Monitor it talks to, as the format of
> > >>> > > cr-states.json has
> > not
> > >>> > > changed. Same goes for TM and ATS. I believe we had
> > >>> > > co-existence running in production going back to the 1.8.x
> releases.
> > >>> > >
> > >>> > > Keep in mind that the intent is to drive users toward using
> > >>> > > the
> > Golang
> > >>> > > component by default starting with the 2.1.0 (or maybe 2.2.0?)
> > release
> > >>> > > while still allowing one to build, run, or contribute to the
> > >>> > > Java version until our next major release (3.0.0). The intent
> > >>> > > is not to give people a drop in replacement that works with
> > >>> > > prior versions;
> > we
> > >>> > > have not tested that thoroughly across all versions, and while
> > >>> > > it might work, we should think of the Golang Traffic Monitor
> > >>> > > as a
> > 2.0.x
> > >>> > > and onward component. I think that statement holds for most of
> > >>> > > our components; we wouldn't want to run a 1.7 Traffic Stats
> > >>> > > with a
> > 2.0.0
> > >>> > > Traffic Ops system. 1.7 is ancient, and have we ever really
> > >>> > > done backward compatibility testing with versions?
> > >>> > >
> > >>> > > To this end, if we do decide to make the Golang version the
> > default in
> > >>> > > the future, at a minimum we will need to provide release notes
> > >>> > > that explain how to convert the Java configuration to the
> > >>> > > Golang
> > version's
> > >>> > > config. Ideally we would provide a simple script to convert
> > >>> > > the configuration for our users, potentially running it as a
> > postinstall
> > >>> > > scriptlet in the RPM if the Java version is already installed.
> > >>> > > Theoretically we could `yum upgrade traffic_monitor` and
> > >>> > > seamlessly move from Java to Golang.
> > >>> > > --
> > >>> > > Thanks,
> > >>> > > Jeff
> > >>> > >
> > >>> > >
> > >>> > > On Fri, Jul 14, 2017 at 2:07 PM, Eric Friedrich (efriedri)
> > >>> > > <ef...@cisco.com> wrote:
> > >>> > > > I think I remember Rob making this point in Miami, but all
> > >>> > > > of TMs
> > >>> APIs
> > >>> > > (REST, CRConfig, Health.json, etc…) are identical between the
> > >>> > > Java
> > and
> > >>> > > Golang version, right?
> > >>> > > >
> > >>> > > > What about compatibility with earlier versions of TC?
> > >>> > > >
> > >>> > > > For example:
> > >>> > > > - Can a TC1.7 traffic ops configure a Golang TM?
> > >>> > > > - Does the Golang TM have any dependencies on a certain
> > >>> > > > version
> > of
> > >>> > > TrafficServer or astats?
> > >>> > > > - Whats the minimum required version of Traffic Router to
> > >>> > > > use the
> > >>> > Golang
> > >>> > > TM?
> > >>> > > > - I know Golang TMs can gossip with Java TMs, but can we mix
> > versions
> > >>> > > here too? (i.e. TC1.7 Java TM with TC2.1 Golang TM)?
> > >>> > > >
> > >>> > > > —Eric
> > >>> > > >
> > >>> > > >
> > >>> > > >> On Jul 14, 2017, at 1:00 PM, Jeff Elsloo
> > >>> > > >> <el...@apache.org>
> > wrote:
> > >>> > > >>
> > >>> > > >> Hi all,
> > >>> > > >>
> > >>> > > >> We currently have two versions of Traffic Monitor: Java and
> > golang.
> > >>> > > >> When we build all components, as far as I know, it results
> > >>> > > >> in a
> > race
> > >>> > > >> condition between the two, as the resulting RPMs have the
> > >>> > > >> same filename. A PR[1] was opened to address the issue and
> > >>> > > >> the
> > approach
> > >>> was
> > >>> > > >> to add `_go` to the version string used for the golang
> > >>> > > >> version's
> > >>> RPM.
> > >>> > > >>
> > >>> > > >> Rob and I both think we (Comcast) have enough experience
> > running the
> > >>> > > >> golang version that we have identified and corrected any
> > >>> > > >> major
> > >>> issues
> > >>> > > >> and that it is stable enough to be the preferred Traffic
> > >>> > > >> Monitor
> > >>> hence
> > >>> > > >> forth.
> > >>> > > >>
> > >>> > > >> Therefore, I propose that within the project's directory
> > structure,
> > >>> > we:
> > >>> > > >>  1) rename traffic_monitor to traffic_monitor_legacy
> > >>> > > >>  2) rename traffic_monitor_golang to traffic_monitor
> > >>> > > >>
> > >>> > > >> ..then work with the person that submitted the PR to take
> > >>> > > >> the
> > same
> > >>> > > >> approach, except change the Java version's RPM name to
> > >>> > > >> contain `_legacy`.
> > >>> > > >>
> > >>> > > >> I realize that this is a fairly significant change, the
> > >>> > > >> type
> > that we
> > >>> > > >> typically reserve for major releases. The next major
> > >>> > > >> release,
> > 3.0.0,
> > >>> > > >> is likely to be some time out in the future, and I don't
> > >>> > > >> know
> > that
> > >>> we
> > >>> > > >> need to wait for it in order to make this change.
> > >>> > > >>
> > >>> > > >> How does the group feel about the above proposal, and
> > >>> > > >> executing
> > on
> > >>> it
> > >>> > > >> prior to the 3.0.0 release (i.e.: for 2.1.0)? Then, when we
> > >>> > > >> do actually prepare the 3.0.0 release, we can remove the
> > >>> > > >> Java
> > version
> > >>> > > >> from the codebase entirely. Obviously this could impact
> > >>> > > >> anyone
> > that
> > >>> > > >> has automated CI systems building components, in addition
> > >>> > > >> to the Apache CI we use ourselves.
> > >>> > > >>
> > >>> > > >> Thoughts?
> > >>> > > >>
> > >>> > > >> [1]
> > >>> > > >> https://github.com/apache/incubator-trafficcontrol/pull/731
> > >>> > > >> --
> > >>> > > >> Thanks,
> > >>> > > >> Jeff
> > >>> > > >
> > >>> > >
> > >>> >
> > >>>
> >
>

RE: Promote Golang Traffic Monitor to Default

["Hongfei Zhang (hongfezh)" <ho...@cisco.com>]

Hi,

We noticed the new Go Monitor uses two config files and these files are incompatible with the Java implementation. Some config directive's name also changed.  Will/should the rpm upgrade be able to take care of the config file conversion/split?   

Thanks,
-Hongfei

-----Original Message-----
From: Nir Sopher [mailto:nirs@qwilt.com] 
Sent: Monday, October 23, 2017 3:34 PM
To: dev@trafficcontrol.incubator.apache.org
Subject: Re: Promote Golang Traffic Monitor to Default

Hi,

What would be the content of 2.2?
If we want to have very limited content as suggested in the summit, I would suggest to leave Java TM, removing it only on TC 2.3.

If the 2.2 version has substantial content, I would see leaving the old TM as part of the release as a liability. Old TM should be adjusted to the changes and tested regularly.
So in this case, if there are no automated tests to cover its functionality, I would suggest to remove Java TM from the code base.

Nir

On Mon, Oct 23, 2017 at 5:58 PM, Jeff Elsloo <el...@apache.org> wrote:

> Hi all,
>
> Apologies for the delay, and thanks to Rob for submitting PR 1427 to 
> take care of this. I just merged his PR and that means that 
> `traffic_monitor` has been renamed to `traffic_monitor_java` and 
> `traffic_monitor_golang` has been renamed to `traffic_monitor` (thanks 
> Rob!). This means that we are now one step closer to formally retiring 
> the Java version of Traffic Monitor.
>
> Before proposing a vote, I'd like to get a feel for how quickly we can 
> do the formal retirement. We're currently working on 2.1 so that means 
> that we could retire it as early as 2.2. If we want to be more 
> conservative, we could keep both with the renamed structure for 2.2, 
> and remove the Java version in 2.3. This is the direction I'm leaning, 
> though I'd like to hear from interested parties first.
>
> Thoughts?
> --
> Thanks,
> Jeff
>
>
> On Mon, Jul 24, 2017 at 8:23 AM, Jeff Elsloo <el...@apache.org> wrote:
> > It sounds like we do not have any -1s on this, so I'm going to 
> > assume we're good to make this change. I have some other things to 
> > focus on at the moment, but will try to get this done as time 
> > permits. I'll send another email out with details when I go to make 
> > the change, and will allow some time before pushing anything in case 
> > someone has concerns.
> > --
> > Thanks,
> > Jeff
> >
> >
> > On Mon, Jul 17, 2017 at 2:14 PM, Dave Neuman <ne...@apache.org> wrote:
> >> +1 on the rename
> >>
> >> On Mon, Jul 17, 2017 at 10:23 AM, Jan van Doorn <jv...@knutsel.com>
> wrote:
> >>
> >>> +1
> >>>
> >>> On Mon, Jul 17, 2017 at 9:47 AM Dewayne Richardson 
> >>> <de...@gmail.com>
> >>> wrote:
> >>>
> >>> > When:   Read · Mon, Jul 17.
> >>> > <https://timyo.com/?utm_source=expectationheader&utm_medium=emai
> >>> > l>
> >>> > [image: Timyo expectation line]
> >>> > +1
> >>> >
> >>> > On Fri, Jul 14, 2017 at 2:49 PM, Jeff Elsloo <el...@apache.org>
> wrote:
> >>> >
> >>> > > For the most part, it's a drop in replacement for the Java 
> >>> > > version, and based on our own experience it seems to work 
> >>> > > exactly as the
> Java
> >>> > > version would, including co-existence. There is a TO API 
> >>> > > dependency for monitoring.json that the Java version does not 
> >>> > > have, and I'm
> not
> >>> > > sure what the history is with that endpoint and how far back 
> >>> > > we
> could
> >>> > > remain compatible. Traffic Router does not care what version 
> >>> > > of Traffic Monitor it talks to, as the format of 
> >>> > > cr-states.json has
> not
> >>> > > changed. Same goes for TM and ATS. I believe we had 
> >>> > > co-existence running in production going back to the 1.8.x releases.
> >>> > >
> >>> > > Keep in mind that the intent is to drive users toward using 
> >>> > > the
> Golang
> >>> > > component by default starting with the 2.1.0 (or maybe 2.2.0?)
> release
> >>> > > while still allowing one to build, run, or contribute to the 
> >>> > > Java version until our next major release (3.0.0). The intent 
> >>> > > is not to give people a drop in replacement that works with 
> >>> > > prior versions;
> we
> >>> > > have not tested that thoroughly across all versions, and while 
> >>> > > it might work, we should think of the Golang Traffic Monitor 
> >>> > > as a
> 2.0.x
> >>> > > and onward component. I think that statement holds for most of 
> >>> > > our components; we wouldn't want to run a 1.7 Traffic Stats 
> >>> > > with a
> 2.0.0
> >>> > > Traffic Ops system. 1.7 is ancient, and have we ever really 
> >>> > > done backward compatibility testing with versions?
> >>> > >
> >>> > > To this end, if we do decide to make the Golang version the
> default in
> >>> > > the future, at a minimum we will need to provide release notes 
> >>> > > that explain how to convert the Java configuration to the 
> >>> > > Golang
> version's
> >>> > > config. Ideally we would provide a simple script to convert 
> >>> > > the configuration for our users, potentially running it as a
> postinstall
> >>> > > scriptlet in the RPM if the Java version is already installed.
> >>> > > Theoretically we could `yum upgrade traffic_monitor` and 
> >>> > > seamlessly move from Java to Golang.
> >>> > > --
> >>> > > Thanks,
> >>> > > Jeff
> >>> > >
> >>> > >
> >>> > > On Fri, Jul 14, 2017 at 2:07 PM, Eric Friedrich (efriedri) 
> >>> > > <ef...@cisco.com> wrote:
> >>> > > > I think I remember Rob making this point in Miami, but all 
> >>> > > > of TMs
> >>> APIs
> >>> > > (REST, CRConfig, Health.json, etc…) are identical between the 
> >>> > > Java
> and
> >>> > > Golang version, right?
> >>> > > >
> >>> > > > What about compatibility with earlier versions of TC?
> >>> > > >
> >>> > > > For example:
> >>> > > > - Can a TC1.7 traffic ops configure a Golang TM?
> >>> > > > - Does the Golang TM have any dependencies on a certain 
> >>> > > > version
> of
> >>> > > TrafficServer or astats?
> >>> > > > - Whats the minimum required version of Traffic Router to 
> >>> > > > use the
> >>> > Golang
> >>> > > TM?
> >>> > > > - I know Golang TMs can gossip with Java TMs, but can we mix
> versions
> >>> > > here too? (i.e. TC1.7 Java TM with TC2.1 Golang TM)?
> >>> > > >
> >>> > > > —Eric
> >>> > > >
> >>> > > >
> >>> > > >> On Jul 14, 2017, at 1:00 PM, Jeff Elsloo 
> >>> > > >> <el...@apache.org>
> wrote:
> >>> > > >>
> >>> > > >> Hi all,
> >>> > > >>
> >>> > > >> We currently have two versions of Traffic Monitor: Java and
> golang.
> >>> > > >> When we build all components, as far as I know, it results 
> >>> > > >> in a
> race
> >>> > > >> condition between the two, as the resulting RPMs have the 
> >>> > > >> same filename. A PR[1] was opened to address the issue and 
> >>> > > >> the
> approach
> >>> was
> >>> > > >> to add `_go` to the version string used for the golang 
> >>> > > >> version's
> >>> RPM.
> >>> > > >>
> >>> > > >> Rob and I both think we (Comcast) have enough experience
> running the
> >>> > > >> golang version that we have identified and corrected any 
> >>> > > >> major
> >>> issues
> >>> > > >> and that it is stable enough to be the preferred Traffic 
> >>> > > >> Monitor
> >>> hence
> >>> > > >> forth.
> >>> > > >>
> >>> > > >> Therefore, I propose that within the project's directory
> structure,
> >>> > we:
> >>> > > >>  1) rename traffic_monitor to traffic_monitor_legacy
> >>> > > >>  2) rename traffic_monitor_golang to traffic_monitor
> >>> > > >>
> >>> > > >> ..then work with the person that submitted the PR to take 
> >>> > > >> the
> same
> >>> > > >> approach, except change the Java version's RPM name to 
> >>> > > >> contain `_legacy`.
> >>> > > >>
> >>> > > >> I realize that this is a fairly significant change, the 
> >>> > > >> type
> that we
> >>> > > >> typically reserve for major releases. The next major 
> >>> > > >> release,
> 3.0.0,
> >>> > > >> is likely to be some time out in the future, and I don't 
> >>> > > >> know
> that
> >>> we
> >>> > > >> need to wait for it in order to make this change.
> >>> > > >>
> >>> > > >> How does the group feel about the above proposal, and 
> >>> > > >> executing
> on
> >>> it
> >>> > > >> prior to the 3.0.0 release (i.e.: for 2.1.0)? Then, when we 
> >>> > > >> do actually prepare the 3.0.0 release, we can remove the 
> >>> > > >> Java
> version
> >>> > > >> from the codebase entirely. Obviously this could impact 
> >>> > > >> anyone
> that
> >>> > > >> has automated CI systems building components, in addition 
> >>> > > >> to the Apache CI we use ourselves.
> >>> > > >>
> >>> > > >> Thoughts?
> >>> > > >>
> >>> > > >> [1] 
> >>> > > >> https://github.com/apache/incubator-trafficcontrol/pull/731
> >>> > > >> --
> >>> > > >> Thanks,
> >>> > > >> Jeff
> >>> > > >
> >>> > >
> >>> >
> >>>
>

Re: Promote Golang Traffic Monitor to Default

[Nir Sopher <ni...@qwilt.com>]

Hi,

What would be the content of 2.2?
If we want to have very limited content as suggested in the summit, I would
suggest to leave Java TM, removing it only on TC 2.3.

If the 2.2 version has substantial content, I would see leaving the old TM
as part of the release as a liability. Old TM should be adjusted to the
changes and tested regularly.
So in this case, if there are no automated tests to cover its
functionality, I would suggest to remove Java TM from the code base.

Nir

On Mon, Oct 23, 2017 at 5:58 PM, Jeff Elsloo <el...@apache.org> wrote:

> Hi all,
>
> Apologies for the delay, and thanks to Rob for submitting PR 1427 to
> take care of this. I just merged his PR and that means that
> `traffic_monitor` has been renamed to `traffic_monitor_java` and
> `traffic_monitor_golang` has been renamed to `traffic_monitor` (thanks
> Rob!). This means that we are now one step closer to formally retiring
> the Java version of Traffic Monitor.
>
> Before proposing a vote, I'd like to get a feel for how quickly we can
> do the formal retirement. We're currently working on 2.1 so that means
> that we could retire it as early as 2.2. If we want to be more
> conservative, we could keep both with the renamed structure for 2.2,
> and remove the Java version in 2.3. This is the direction I'm leaning,
> though I'd like to hear from interested parties first.
>
> Thoughts?
> --
> Thanks,
> Jeff
>
>
> On Mon, Jul 24, 2017 at 8:23 AM, Jeff Elsloo <el...@apache.org> wrote:
> > It sounds like we do not have any -1s on this, so I'm going to assume
> > we're good to make this change. I have some other things to focus on
> > at the moment, but will try to get this done as time permits. I'll
> > send another email out with details when I go to make the change, and
> > will allow some time before pushing anything in case someone has
> > concerns.
> > --
> > Thanks,
> > Jeff
> >
> >
> > On Mon, Jul 17, 2017 at 2:14 PM, Dave Neuman <ne...@apache.org> wrote:
> >> +1 on the rename
> >>
> >> On Mon, Jul 17, 2017 at 10:23 AM, Jan van Doorn <jv...@knutsel.com>
> wrote:
> >>
> >>> +1
> >>>
> >>> On Mon, Jul 17, 2017 at 9:47 AM Dewayne Richardson <de...@gmail.com>
> >>> wrote:
> >>>
> >>> > When:   Read · Mon, Jul 17.
> >>> > <https://timyo.com/?utm_source=expectationheader&utm_medium=email>
> >>> > [image: Timyo expectation line]
> >>> > +1
> >>> >
> >>> > On Fri, Jul 14, 2017 at 2:49 PM, Jeff Elsloo <el...@apache.org>
> wrote:
> >>> >
> >>> > > For the most part, it's a drop in replacement for the Java version,
> >>> > > and based on our own experience it seems to work exactly as the
> Java
> >>> > > version would, including co-existence. There is a TO API dependency
> >>> > > for monitoring.json that the Java version does not have, and I'm
> not
> >>> > > sure what the history is with that endpoint and how far back we
> could
> >>> > > remain compatible. Traffic Router does not care what version of
> >>> > > Traffic Monitor it talks to, as the format of cr-states.json has
> not
> >>> > > changed. Same goes for TM and ATS. I believe we had co-existence
> >>> > > running in production going back to the 1.8.x releases.
> >>> > >
> >>> > > Keep in mind that the intent is to drive users toward using the
> Golang
> >>> > > component by default starting with the 2.1.0 (or maybe 2.2.0?)
> release
> >>> > > while still allowing one to build, run, or contribute to the Java
> >>> > > version until our next major release (3.0.0). The intent is not to
> >>> > > give people a drop in replacement that works with prior versions;
> we
> >>> > > have not tested that thoroughly across all versions, and while it
> >>> > > might work, we should think of the Golang Traffic Monitor as a
> 2.0.x
> >>> > > and onward component. I think that statement holds for most of our
> >>> > > components; we wouldn't want to run a 1.7 Traffic Stats with a
> 2.0.0
> >>> > > Traffic Ops system. 1.7 is ancient, and have we ever really done
> >>> > > backward compatibility testing with versions?
> >>> > >
> >>> > > To this end, if we do decide to make the Golang version the
> default in
> >>> > > the future, at a minimum we will need to provide release notes that
> >>> > > explain how to convert the Java configuration to the Golang
> version's
> >>> > > config. Ideally we would provide a simple script to convert the
> >>> > > configuration for our users, potentially running it as a
> postinstall
> >>> > > scriptlet in the RPM if the Java version is already installed.
> >>> > > Theoretically we could `yum upgrade traffic_monitor` and seamlessly
> >>> > > move from Java to Golang.
> >>> > > --
> >>> > > Thanks,
> >>> > > Jeff
> >>> > >
> >>> > >
> >>> > > On Fri, Jul 14, 2017 at 2:07 PM, Eric Friedrich (efriedri)
> >>> > > <ef...@cisco.com> wrote:
> >>> > > > I think I remember Rob making this point in Miami, but all of TMs
> >>> APIs
> >>> > > (REST, CRConfig, Health.json, etc…) are identical between the Java
> and
> >>> > > Golang version, right?
> >>> > > >
> >>> > > > What about compatibility with earlier versions of TC?
> >>> > > >
> >>> > > > For example:
> >>> > > > - Can a TC1.7 traffic ops configure a Golang TM?
> >>> > > > - Does the Golang TM have any dependencies on a certain version
> of
> >>> > > TrafficServer or astats?
> >>> > > > - Whats the minimum required version of Traffic Router to use the
> >>> > Golang
> >>> > > TM?
> >>> > > > - I know Golang TMs can gossip with Java TMs, but can we mix
> versions
> >>> > > here too? (i.e. TC1.7 Java TM with TC2.1 Golang TM)?
> >>> > > >
> >>> > > > —Eric
> >>> > > >
> >>> > > >
> >>> > > >> On Jul 14, 2017, at 1:00 PM, Jeff Elsloo <el...@apache.org>
> wrote:
> >>> > > >>
> >>> > > >> Hi all,
> >>> > > >>
> >>> > > >> We currently have two versions of Traffic Monitor: Java and
> golang.
> >>> > > >> When we build all components, as far as I know, it results in a
> race
> >>> > > >> condition between the two, as the resulting RPMs have the same
> >>> > > >> filename. A PR[1] was opened to address the issue and the
> approach
> >>> was
> >>> > > >> to add `_go` to the version string used for the golang version's
> >>> RPM.
> >>> > > >>
> >>> > > >> Rob and I both think we (Comcast) have enough experience
> running the
> >>> > > >> golang version that we have identified and corrected any major
> >>> issues
> >>> > > >> and that it is stable enough to be the preferred Traffic Monitor
> >>> hence
> >>> > > >> forth.
> >>> > > >>
> >>> > > >> Therefore, I propose that within the project's directory
> structure,
> >>> > we:
> >>> > > >>  1) rename traffic_monitor to traffic_monitor_legacy
> >>> > > >>  2) rename traffic_monitor_golang to traffic_monitor
> >>> > > >>
> >>> > > >> ..then work with the person that submitted the PR to take the
> same
> >>> > > >> approach, except change the Java version's RPM name to contain
> >>> > > >> `_legacy`.
> >>> > > >>
> >>> > > >> I realize that this is a fairly significant change, the type
> that we
> >>> > > >> typically reserve for major releases. The next major release,
> 3.0.0,
> >>> > > >> is likely to be some time out in the future, and I don't know
> that
> >>> we
> >>> > > >> need to wait for it in order to make this change.
> >>> > > >>
> >>> > > >> How does the group feel about the above proposal, and executing
> on
> >>> it
> >>> > > >> prior to the 3.0.0 release (i.e.: for 2.1.0)? Then, when we do
> >>> > > >> actually prepare the 3.0.0 release, we can remove the Java
> version
> >>> > > >> from the codebase entirely. Obviously this could impact anyone
> that
> >>> > > >> has automated CI systems building components, in addition to the
> >>> > > >> Apache CI we use ourselves.
> >>> > > >>
> >>> > > >> Thoughts?
> >>> > > >>
> >>> > > >> [1] https://github.com/apache/incubator-trafficcontrol/pull/731
> >>> > > >> --
> >>> > > >> Thanks,
> >>> > > >> Jeff
> >>> > > >
> >>> > >
> >>> >
> >>>
>

Re: Promote Golang Traffic Monitor to Default

[Jeff Elsloo <el...@apache.org>]

Hi all,

Apologies for the delay, and thanks to Rob for submitting PR 1427 to
take care of this. I just merged his PR and that means that
`traffic_monitor` has been renamed to `traffic_monitor_java` and
`traffic_monitor_golang` has been renamed to `traffic_monitor` (thanks
Rob!). This means that we are now one step closer to formally retiring
the Java version of Traffic Monitor.

Before proposing a vote, I'd like to get a feel for how quickly we can
do the formal retirement. We're currently working on 2.1 so that means
that we could retire it as early as 2.2. If we want to be more
conservative, we could keep both with the renamed structure for 2.2,
and remove the Java version in 2.3. This is the direction I'm leaning,
though I'd like to hear from interested parties first.

Thoughts?
--
Thanks,
Jeff


On Mon, Jul 24, 2017 at 8:23 AM, Jeff Elsloo <el...@apache.org> wrote:
> It sounds like we do not have any -1s on this, so I'm going to assume
> we're good to make this change. I have some other things to focus on
> at the moment, but will try to get this done as time permits. I'll
> send another email out with details when I go to make the change, and
> will allow some time before pushing anything in case someone has
> concerns.
> --
> Thanks,
> Jeff
>
>
> On Mon, Jul 17, 2017 at 2:14 PM, Dave Neuman <ne...@apache.org> wrote:
>> +1 on the rename
>>
>> On Mon, Jul 17, 2017 at 10:23 AM, Jan van Doorn <jv...@knutsel.com> wrote:
>>
>>> +1
>>>
>>> On Mon, Jul 17, 2017 at 9:47 AM Dewayne Richardson <de...@gmail.com>
>>> wrote:
>>>
>>> > When:   Read · Mon, Jul 17.
>>> > <https://timyo.com/?utm_source=expectationheader&utm_medium=email>
>>> > [image: Timyo expectation line]
>>> > +1
>>> >
>>> > On Fri, Jul 14, 2017 at 2:49 PM, Jeff Elsloo <el...@apache.org> wrote:
>>> >
>>> > > For the most part, it's a drop in replacement for the Java version,
>>> > > and based on our own experience it seems to work exactly as the Java
>>> > > version would, including co-existence. There is a TO API dependency
>>> > > for monitoring.json that the Java version does not have, and I'm not
>>> > > sure what the history is with that endpoint and how far back we could
>>> > > remain compatible. Traffic Router does not care what version of
>>> > > Traffic Monitor it talks to, as the format of cr-states.json has not
>>> > > changed. Same goes for TM and ATS. I believe we had co-existence
>>> > > running in production going back to the 1.8.x releases.
>>> > >
>>> > > Keep in mind that the intent is to drive users toward using the Golang
>>> > > component by default starting with the 2.1.0 (or maybe 2.2.0?) release
>>> > > while still allowing one to build, run, or contribute to the Java
>>> > > version until our next major release (3.0.0). The intent is not to
>>> > > give people a drop in replacement that works with prior versions; we
>>> > > have not tested that thoroughly across all versions, and while it
>>> > > might work, we should think of the Golang Traffic Monitor as a 2.0.x
>>> > > and onward component. I think that statement holds for most of our
>>> > > components; we wouldn't want to run a 1.7 Traffic Stats with a 2.0.0
>>> > > Traffic Ops system. 1.7 is ancient, and have we ever really done
>>> > > backward compatibility testing with versions?
>>> > >
>>> > > To this end, if we do decide to make the Golang version the default in
>>> > > the future, at a minimum we will need to provide release notes that
>>> > > explain how to convert the Java configuration to the Golang version's
>>> > > config. Ideally we would provide a simple script to convert the
>>> > > configuration for our users, potentially running it as a postinstall
>>> > > scriptlet in the RPM if the Java version is already installed.
>>> > > Theoretically we could `yum upgrade traffic_monitor` and seamlessly
>>> > > move from Java to Golang.
>>> > > --
>>> > > Thanks,
>>> > > Jeff
>>> > >
>>> > >
>>> > > On Fri, Jul 14, 2017 at 2:07 PM, Eric Friedrich (efriedri)
>>> > > <ef...@cisco.com> wrote:
>>> > > > I think I remember Rob making this point in Miami, but all of TMs
>>> APIs
>>> > > (REST, CRConfig, Health.json, etc…) are identical between the Java and
>>> > > Golang version, right?
>>> > > >
>>> > > > What about compatibility with earlier versions of TC?
>>> > > >
>>> > > > For example:
>>> > > > - Can a TC1.7 traffic ops configure a Golang TM?
>>> > > > - Does the Golang TM have any dependencies on a certain version of
>>> > > TrafficServer or astats?
>>> > > > - Whats the minimum required version of Traffic Router to use the
>>> > Golang
>>> > > TM?
>>> > > > - I know Golang TMs can gossip with Java TMs, but can we mix versions
>>> > > here too? (i.e. TC1.7 Java TM with TC2.1 Golang TM)?
>>> > > >
>>> > > > —Eric
>>> > > >
>>> > > >
>>> > > >> On Jul 14, 2017, at 1:00 PM, Jeff Elsloo <el...@apache.org> wrote:
>>> > > >>
>>> > > >> Hi all,
>>> > > >>
>>> > > >> We currently have two versions of Traffic Monitor: Java and golang.
>>> > > >> When we build all components, as far as I know, it results in a race
>>> > > >> condition between the two, as the resulting RPMs have the same
>>> > > >> filename. A PR[1] was opened to address the issue and the approach
>>> was
>>> > > >> to add `_go` to the version string used for the golang version's
>>> RPM.
>>> > > >>
>>> > > >> Rob and I both think we (Comcast) have enough experience running the
>>> > > >> golang version that we have identified and corrected any major
>>> issues
>>> > > >> and that it is stable enough to be the preferred Traffic Monitor
>>> hence
>>> > > >> forth.
>>> > > >>
>>> > > >> Therefore, I propose that within the project's directory structure,
>>> > we:
>>> > > >>  1) rename traffic_monitor to traffic_monitor_legacy
>>> > > >>  2) rename traffic_monitor_golang to traffic_monitor
>>> > > >>
>>> > > >> ..then work with the person that submitted the PR to take the same
>>> > > >> approach, except change the Java version's RPM name to contain
>>> > > >> `_legacy`.
>>> > > >>
>>> > > >> I realize that this is a fairly significant change, the type that we
>>> > > >> typically reserve for major releases. The next major release, 3.0.0,
>>> > > >> is likely to be some time out in the future, and I don't know that
>>> we
>>> > > >> need to wait for it in order to make this change.
>>> > > >>
>>> > > >> How does the group feel about the above proposal, and executing on
>>> it
>>> > > >> prior to the 3.0.0 release (i.e.: for 2.1.0)? Then, when we do
>>> > > >> actually prepare the 3.0.0 release, we can remove the Java version
>>> > > >> from the codebase entirely. Obviously this could impact anyone that
>>> > > >> has automated CI systems building components, in addition to the
>>> > > >> Apache CI we use ourselves.
>>> > > >>
>>> > > >> Thoughts?
>>> > > >>
>>> > > >> [1] https://github.com/apache/incubator-trafficcontrol/pull/731
>>> > > >> --
>>> > > >> Thanks,
>>> > > >> Jeff
>>> > > >
>>> > >
>>> >
>>>

Re: Promote Golang Traffic Monitor to Default

[Jeff Elsloo <el...@apache.org>]

It sounds like we do not have any -1s on this, so I'm going to assume
we're good to make this change. I have some other things to focus on
at the moment, but will try to get this done as time permits. I'll
send another email out with details when I go to make the change, and
will allow some time before pushing anything in case someone has
concerns.
--
Thanks,
Jeff


On Mon, Jul 17, 2017 at 2:14 PM, Dave Neuman <ne...@apache.org> wrote:
> +1 on the rename
>
> On Mon, Jul 17, 2017 at 10:23 AM, Jan van Doorn <jv...@knutsel.com> wrote:
>
>> +1
>>
>> On Mon, Jul 17, 2017 at 9:47 AM Dewayne Richardson <de...@gmail.com>
>> wrote:
>>
>> > When:   Read · Mon, Jul 17.
>> > <https://timyo.com/?utm_source=expectationheader&utm_medium=email>
>> > [image: Timyo expectation line]
>> > +1
>> >
>> > On Fri, Jul 14, 2017 at 2:49 PM, Jeff Elsloo <el...@apache.org> wrote:
>> >
>> > > For the most part, it's a drop in replacement for the Java version,
>> > > and based on our own experience it seems to work exactly as the Java
>> > > version would, including co-existence. There is a TO API dependency
>> > > for monitoring.json that the Java version does not have, and I'm not
>> > > sure what the history is with that endpoint and how far back we could
>> > > remain compatible. Traffic Router does not care what version of
>> > > Traffic Monitor it talks to, as the format of cr-states.json has not
>> > > changed. Same goes for TM and ATS. I believe we had co-existence
>> > > running in production going back to the 1.8.x releases.
>> > >
>> > > Keep in mind that the intent is to drive users toward using the Golang
>> > > component by default starting with the 2.1.0 (or maybe 2.2.0?) release
>> > > while still allowing one to build, run, or contribute to the Java
>> > > version until our next major release (3.0.0). The intent is not to
>> > > give people a drop in replacement that works with prior versions; we
>> > > have not tested that thoroughly across all versions, and while it
>> > > might work, we should think of the Golang Traffic Monitor as a 2.0.x
>> > > and onward component. I think that statement holds for most of our
>> > > components; we wouldn't want to run a 1.7 Traffic Stats with a 2.0.0
>> > > Traffic Ops system. 1.7 is ancient, and have we ever really done
>> > > backward compatibility testing with versions?
>> > >
>> > > To this end, if we do decide to make the Golang version the default in
>> > > the future, at a minimum we will need to provide release notes that
>> > > explain how to convert the Java configuration to the Golang version's
>> > > config. Ideally we would provide a simple script to convert the
>> > > configuration for our users, potentially running it as a postinstall
>> > > scriptlet in the RPM if the Java version is already installed.
>> > > Theoretically we could `yum upgrade traffic_monitor` and seamlessly
>> > > move from Java to Golang.
>> > > --
>> > > Thanks,
>> > > Jeff
>> > >
>> > >
>> > > On Fri, Jul 14, 2017 at 2:07 PM, Eric Friedrich (efriedri)
>> > > <ef...@cisco.com> wrote:
>> > > > I think I remember Rob making this point in Miami, but all of TMs
>> APIs
>> > > (REST, CRConfig, Health.json, etc…) are identical between the Java and
>> > > Golang version, right?
>> > > >
>> > > > What about compatibility with earlier versions of TC?
>> > > >
>> > > > For example:
>> > > > - Can a TC1.7 traffic ops configure a Golang TM?
>> > > > - Does the Golang TM have any dependencies on a certain version of
>> > > TrafficServer or astats?
>> > > > - Whats the minimum required version of Traffic Router to use the
>> > Golang
>> > > TM?
>> > > > - I know Golang TMs can gossip with Java TMs, but can we mix versions
>> > > here too? (i.e. TC1.7 Java TM with TC2.1 Golang TM)?
>> > > >
>> > > > —Eric
>> > > >
>> > > >
>> > > >> On Jul 14, 2017, at 1:00 PM, Jeff Elsloo <el...@apache.org> wrote:
>> > > >>
>> > > >> Hi all,
>> > > >>
>> > > >> We currently have two versions of Traffic Monitor: Java and golang.
>> > > >> When we build all components, as far as I know, it results in a race
>> > > >> condition between the two, as the resulting RPMs have the same
>> > > >> filename. A PR[1] was opened to address the issue and the approach
>> was
>> > > >> to add `_go` to the version string used for the golang version's
>> RPM.
>> > > >>
>> > > >> Rob and I both think we (Comcast) have enough experience running the
>> > > >> golang version that we have identified and corrected any major
>> issues
>> > > >> and that it is stable enough to be the preferred Traffic Monitor
>> hence
>> > > >> forth.
>> > > >>
>> > > >> Therefore, I propose that within the project's directory structure,
>> > we:
>> > > >>  1) rename traffic_monitor to traffic_monitor_legacy
>> > > >>  2) rename traffic_monitor_golang to traffic_monitor
>> > > >>
>> > > >> ..then work with the person that submitted the PR to take the same
>> > > >> approach, except change the Java version's RPM name to contain
>> > > >> `_legacy`.
>> > > >>
>> > > >> I realize that this is a fairly significant change, the type that we
>> > > >> typically reserve for major releases. The next major release, 3.0.0,
>> > > >> is likely to be some time out in the future, and I don't know that
>> we
>> > > >> need to wait for it in order to make this change.
>> > > >>
>> > > >> How does the group feel about the above proposal, and executing on
>> it
>> > > >> prior to the 3.0.0 release (i.e.: for 2.1.0)? Then, when we do
>> > > >> actually prepare the 3.0.0 release, we can remove the Java version
>> > > >> from the codebase entirely. Obviously this could impact anyone that
>> > > >> has automated CI systems building components, in addition to the
>> > > >> Apache CI we use ourselves.
>> > > >>
>> > > >> Thoughts?
>> > > >>
>> > > >> [1] https://github.com/apache/incubator-trafficcontrol/pull/731
>> > > >> --
>> > > >> Thanks,
>> > > >> Jeff
>> > > >
>> > >
>> >
>>

Re: Promote Golang Traffic Monitor to Default

[Dave Neuman <ne...@apache.org>]

+1 on the rename

On Mon, Jul 17, 2017 at 10:23 AM, Jan van Doorn <jv...@knutsel.com> wrote:

> +1
>
> On Mon, Jul 17, 2017 at 9:47 AM Dewayne Richardson <de...@gmail.com>
> wrote:
>
> > When:   Read · Mon, Jul 17.
> > <https://timyo.com/?utm_source=expectationheader&utm_medium=email>
> > [image: Timyo expectation line]
> > +1
> >
> > On Fri, Jul 14, 2017 at 2:49 PM, Jeff Elsloo <el...@apache.org> wrote:
> >
> > > For the most part, it's a drop in replacement for the Java version,
> > > and based on our own experience it seems to work exactly as the Java
> > > version would, including co-existence. There is a TO API dependency
> > > for monitoring.json that the Java version does not have, and I'm not
> > > sure what the history is with that endpoint and how far back we could
> > > remain compatible. Traffic Router does not care what version of
> > > Traffic Monitor it talks to, as the format of cr-states.json has not
> > > changed. Same goes for TM and ATS. I believe we had co-existence
> > > running in production going back to the 1.8.x releases.
> > >
> > > Keep in mind that the intent is to drive users toward using the Golang
> > > component by default starting with the 2.1.0 (or maybe 2.2.0?) release
> > > while still allowing one to build, run, or contribute to the Java
> > > version until our next major release (3.0.0). The intent is not to
> > > give people a drop in replacement that works with prior versions; we
> > > have not tested that thoroughly across all versions, and while it
> > > might work, we should think of the Golang Traffic Monitor as a 2.0.x
> > > and onward component. I think that statement holds for most of our
> > > components; we wouldn't want to run a 1.7 Traffic Stats with a 2.0.0
> > > Traffic Ops system. 1.7 is ancient, and have we ever really done
> > > backward compatibility testing with versions?
> > >
> > > To this end, if we do decide to make the Golang version the default in
> > > the future, at a minimum we will need to provide release notes that
> > > explain how to convert the Java configuration to the Golang version's
> > > config. Ideally we would provide a simple script to convert the
> > > configuration for our users, potentially running it as a postinstall
> > > scriptlet in the RPM if the Java version is already installed.
> > > Theoretically we could `yum upgrade traffic_monitor` and seamlessly
> > > move from Java to Golang.
> > > --
> > > Thanks,
> > > Jeff
> > >
> > >
> > > On Fri, Jul 14, 2017 at 2:07 PM, Eric Friedrich (efriedri)
> > > <ef...@cisco.com> wrote:
> > > > I think I remember Rob making this point in Miami, but all of TMs
> APIs
> > > (REST, CRConfig, Health.json, etc…) are identical between the Java and
> > > Golang version, right?
> > > >
> > > > What about compatibility with earlier versions of TC?
> > > >
> > > > For example:
> > > > - Can a TC1.7 traffic ops configure a Golang TM?
> > > > - Does the Golang TM have any dependencies on a certain version of
> > > TrafficServer or astats?
> > > > - Whats the minimum required version of Traffic Router to use the
> > Golang
> > > TM?
> > > > - I know Golang TMs can gossip with Java TMs, but can we mix versions
> > > here too? (i.e. TC1.7 Java TM with TC2.1 Golang TM)?
> > > >
> > > > —Eric
> > > >
> > > >
> > > >> On Jul 14, 2017, at 1:00 PM, Jeff Elsloo <el...@apache.org> wrote:
> > > >>
> > > >> Hi all,
> > > >>
> > > >> We currently have two versions of Traffic Monitor: Java and golang.
> > > >> When we build all components, as far as I know, it results in a race
> > > >> condition between the two, as the resulting RPMs have the same
> > > >> filename. A PR[1] was opened to address the issue and the approach
> was
> > > >> to add `_go` to the version string used for the golang version's
> RPM.
> > > >>
> > > >> Rob and I both think we (Comcast) have enough experience running the
> > > >> golang version that we have identified and corrected any major
> issues
> > > >> and that it is stable enough to be the preferred Traffic Monitor
> hence
> > > >> forth.
> > > >>
> > > >> Therefore, I propose that within the project's directory structure,
> > we:
> > > >>  1) rename traffic_monitor to traffic_monitor_legacy
> > > >>  2) rename traffic_monitor_golang to traffic_monitor
> > > >>
> > > >> ..then work with the person that submitted the PR to take the same
> > > >> approach, except change the Java version's RPM name to contain
> > > >> `_legacy`.
> > > >>
> > > >> I realize that this is a fairly significant change, the type that we
> > > >> typically reserve for major releases. The next major release, 3.0.0,
> > > >> is likely to be some time out in the future, and I don't know that
> we
> > > >> need to wait for it in order to make this change.
> > > >>
> > > >> How does the group feel about the above proposal, and executing on
> it
> > > >> prior to the 3.0.0 release (i.e.: for 2.1.0)? Then, when we do
> > > >> actually prepare the 3.0.0 release, we can remove the Java version
> > > >> from the codebase entirely. Obviously this could impact anyone that
> > > >> has automated CI systems building components, in addition to the
> > > >> Apache CI we use ourselves.
> > > >>
> > > >> Thoughts?
> > > >>
> > > >> [1] https://github.com/apache/incubator-trafficcontrol/pull/731
> > > >> --
> > > >> Thanks,
> > > >> Jeff
> > > >
> > >
> >
>

Re: Promote Golang Traffic Monitor to Default

[Jan van Doorn <jv...@knutsel.com>]

+1

On Mon, Jul 17, 2017 at 9:47 AM Dewayne Richardson <de...@gmail.com>
wrote:

> When:   Read · Mon, Jul 17.
> <https://timyo.com/?utm_source=expectationheader&utm_medium=email>
> [image: Timyo expectation line]
> +1
>
> On Fri, Jul 14, 2017 at 2:49 PM, Jeff Elsloo <el...@apache.org> wrote:
>
> > For the most part, it's a drop in replacement for the Java version,
> > and based on our own experience it seems to work exactly as the Java
> > version would, including co-existence. There is a TO API dependency
> > for monitoring.json that the Java version does not have, and I'm not
> > sure what the history is with that endpoint and how far back we could
> > remain compatible. Traffic Router does not care what version of
> > Traffic Monitor it talks to, as the format of cr-states.json has not
> > changed. Same goes for TM and ATS. I believe we had co-existence
> > running in production going back to the 1.8.x releases.
> >
> > Keep in mind that the intent is to drive users toward using the Golang
> > component by default starting with the 2.1.0 (or maybe 2.2.0?) release
> > while still allowing one to build, run, or contribute to the Java
> > version until our next major release (3.0.0). The intent is not to
> > give people a drop in replacement that works with prior versions; we
> > have not tested that thoroughly across all versions, and while it
> > might work, we should think of the Golang Traffic Monitor as a 2.0.x
> > and onward component. I think that statement holds for most of our
> > components; we wouldn't want to run a 1.7 Traffic Stats with a 2.0.0
> > Traffic Ops system. 1.7 is ancient, and have we ever really done
> > backward compatibility testing with versions?
> >
> > To this end, if we do decide to make the Golang version the default in
> > the future, at a minimum we will need to provide release notes that
> > explain how to convert the Java configuration to the Golang version's
> > config. Ideally we would provide a simple script to convert the
> > configuration for our users, potentially running it as a postinstall
> > scriptlet in the RPM if the Java version is already installed.
> > Theoretically we could `yum upgrade traffic_monitor` and seamlessly
> > move from Java to Golang.
> > --
> > Thanks,
> > Jeff
> >
> >
> > On Fri, Jul 14, 2017 at 2:07 PM, Eric Friedrich (efriedri)
> > <ef...@cisco.com> wrote:
> > > I think I remember Rob making this point in Miami, but all of TMs APIs
> > (REST, CRConfig, Health.json, etc…) are identical between the Java and
> > Golang version, right?
> > >
> > > What about compatibility with earlier versions of TC?
> > >
> > > For example:
> > > - Can a TC1.7 traffic ops configure a Golang TM?
> > > - Does the Golang TM have any dependencies on a certain version of
> > TrafficServer or astats?
> > > - Whats the minimum required version of Traffic Router to use the
> Golang
> > TM?
> > > - I know Golang TMs can gossip with Java TMs, but can we mix versions
> > here too? (i.e. TC1.7 Java TM with TC2.1 Golang TM)?
> > >
> > > —Eric
> > >
> > >
> > >> On Jul 14, 2017, at 1:00 PM, Jeff Elsloo <el...@apache.org> wrote:
> > >>
> > >> Hi all,
> > >>
> > >> We currently have two versions of Traffic Monitor: Java and golang.
> > >> When we build all components, as far as I know, it results in a race
> > >> condition between the two, as the resulting RPMs have the same
> > >> filename. A PR[1] was opened to address the issue and the approach was
> > >> to add `_go` to the version string used for the golang version's RPM.
> > >>
> > >> Rob and I both think we (Comcast) have enough experience running the
> > >> golang version that we have identified and corrected any major issues
> > >> and that it is stable enough to be the preferred Traffic Monitor hence
> > >> forth.
> > >>
> > >> Therefore, I propose that within the project's directory structure,
> we:
> > >>  1) rename traffic_monitor to traffic_monitor_legacy
> > >>  2) rename traffic_monitor_golang to traffic_monitor
> > >>
> > >> ..then work with the person that submitted the PR to take the same
> > >> approach, except change the Java version's RPM name to contain
> > >> `_legacy`.
> > >>
> > >> I realize that this is a fairly significant change, the type that we
> > >> typically reserve for major releases. The next major release, 3.0.0,
> > >> is likely to be some time out in the future, and I don't know that we
> > >> need to wait for it in order to make this change.
> > >>
> > >> How does the group feel about the above proposal, and executing on it
> > >> prior to the 3.0.0 release (i.e.: for 2.1.0)? Then, when we do
> > >> actually prepare the 3.0.0 release, we can remove the Java version
> > >> from the codebase entirely. Obviously this could impact anyone that
> > >> has automated CI systems building components, in addition to the
> > >> Apache CI we use ourselves.
> > >>
> > >> Thoughts?
> > >>
> > >> [1] https://github.com/apache/incubator-trafficcontrol/pull/731
> > >> --
> > >> Thanks,
> > >> Jeff
> > >
> >
>

Re: Promote Golang Traffic Monitor to Default

[Dewayne Richardson <de...@gmail.com>]

When:   Read · Mon, Jul 17.
<https://timyo.com/?utm_source=expectationheader&utm_medium=email>
[image: Timyo expectation line]
+1

On Fri, Jul 14, 2017 at 2:49 PM, Jeff Elsloo <el...@apache.org> wrote:

> For the most part, it's a drop in replacement for the Java version,
> and based on our own experience it seems to work exactly as the Java
> version would, including co-existence. There is a TO API dependency
> for monitoring.json that the Java version does not have, and I'm not
> sure what the history is with that endpoint and how far back we could
> remain compatible. Traffic Router does not care what version of
> Traffic Monitor it talks to, as the format of cr-states.json has not
> changed. Same goes for TM and ATS. I believe we had co-existence
> running in production going back to the 1.8.x releases.
>
> Keep in mind that the intent is to drive users toward using the Golang
> component by default starting with the 2.1.0 (or maybe 2.2.0?) release
> while still allowing one to build, run, or contribute to the Java
> version until our next major release (3.0.0). The intent is not to
> give people a drop in replacement that works with prior versions; we
> have not tested that thoroughly across all versions, and while it
> might work, we should think of the Golang Traffic Monitor as a 2.0.x
> and onward component. I think that statement holds for most of our
> components; we wouldn't want to run a 1.7 Traffic Stats with a 2.0.0
> Traffic Ops system. 1.7 is ancient, and have we ever really done
> backward compatibility testing with versions?
>
> To this end, if we do decide to make the Golang version the default in
> the future, at a minimum we will need to provide release notes that
> explain how to convert the Java configuration to the Golang version's
> config. Ideally we would provide a simple script to convert the
> configuration for our users, potentially running it as a postinstall
> scriptlet in the RPM if the Java version is already installed.
> Theoretically we could `yum upgrade traffic_monitor` and seamlessly
> move from Java to Golang.
> --
> Thanks,
> Jeff
>
>
> On Fri, Jul 14, 2017 at 2:07 PM, Eric Friedrich (efriedri)
> <ef...@cisco.com> wrote:
> > I think I remember Rob making this point in Miami, but all of TMs APIs
> (REST, CRConfig, Health.json, etc…) are identical between the Java and
> Golang version, right?
> >
> > What about compatibility with earlier versions of TC?
> >
> > For example:
> > - Can a TC1.7 traffic ops configure a Golang TM?
> > - Does the Golang TM have any dependencies on a certain version of
> TrafficServer or astats?
> > - Whats the minimum required version of Traffic Router to use the Golang
> TM?
> > - I know Golang TMs can gossip with Java TMs, but can we mix versions
> here too? (i.e. TC1.7 Java TM with TC2.1 Golang TM)?
> >
> > —Eric
> >
> >
> >> On Jul 14, 2017, at 1:00 PM, Jeff Elsloo <el...@apache.org> wrote:
> >>
> >> Hi all,
> >>
> >> We currently have two versions of Traffic Monitor: Java and golang.
> >> When we build all components, as far as I know, it results in a race
> >> condition between the two, as the resulting RPMs have the same
> >> filename. A PR[1] was opened to address the issue and the approach was
> >> to add `_go` to the version string used for the golang version's RPM.
> >>
> >> Rob and I both think we (Comcast) have enough experience running the
> >> golang version that we have identified and corrected any major issues
> >> and that it is stable enough to be the preferred Traffic Monitor hence
> >> forth.
> >>
> >> Therefore, I propose that within the project's directory structure, we:
> >>  1) rename traffic_monitor to traffic_monitor_legacy
> >>  2) rename traffic_monitor_golang to traffic_monitor
> >>
> >> ..then work with the person that submitted the PR to take the same
> >> approach, except change the Java version's RPM name to contain
> >> `_legacy`.
> >>
> >> I realize that this is a fairly significant change, the type that we
> >> typically reserve for major releases. The next major release, 3.0.0,
> >> is likely to be some time out in the future, and I don't know that we
> >> need to wait for it in order to make this change.
> >>
> >> How does the group feel about the above proposal, and executing on it
> >> prior to the 3.0.0 release (i.e.: for 2.1.0)? Then, when we do
> >> actually prepare the 3.0.0 release, we can remove the Java version
> >> from the codebase entirely. Obviously this could impact anyone that
> >> has automated CI systems building components, in addition to the
> >> Apache CI we use ourselves.
> >>
> >> Thoughts?
> >>
> >> [1] https://github.com/apache/incubator-trafficcontrol/pull/731
> >> --
> >> Thanks,
> >> Jeff
> >
>

Re: Promote Golang Traffic Monitor to Default

[Jeff Elsloo <el...@apache.org>]

For the most part, it's a drop in replacement for the Java version,
and based on our own experience it seems to work exactly as the Java
version would, including co-existence. There is a TO API dependency
for monitoring.json that the Java version does not have, and I'm not
sure what the history is with that endpoint and how far back we could
remain compatible. Traffic Router does not care what version of
Traffic Monitor it talks to, as the format of cr-states.json has not
changed. Same goes for TM and ATS. I believe we had co-existence
running in production going back to the 1.8.x releases.

Keep in mind that the intent is to drive users toward using the Golang
component by default starting with the 2.1.0 (or maybe 2.2.0?) release
while still allowing one to build, run, or contribute to the Java
version until our next major release (3.0.0). The intent is not to
give people a drop in replacement that works with prior versions; we
have not tested that thoroughly across all versions, and while it
might work, we should think of the Golang Traffic Monitor as a 2.0.x
and onward component. I think that statement holds for most of our
components; we wouldn't want to run a 1.7 Traffic Stats with a 2.0.0
Traffic Ops system. 1.7 is ancient, and have we ever really done
backward compatibility testing with versions?

To this end, if we do decide to make the Golang version the default in
the future, at a minimum we will need to provide release notes that
explain how to convert the Java configuration to the Golang version's
config. Ideally we would provide a simple script to convert the
configuration for our users, potentially running it as a postinstall
scriptlet in the RPM if the Java version is already installed.
Theoretically we could `yum upgrade traffic_monitor` and seamlessly
move from Java to Golang.
--
Thanks,
Jeff


On Fri, Jul 14, 2017 at 2:07 PM, Eric Friedrich (efriedri)
<ef...@cisco.com> wrote:
> I think I remember Rob making this point in Miami, but all of TMs APIs (REST, CRConfig, Health.json, etc…) are identical between the Java and Golang version, right?
>
> What about compatibility with earlier versions of TC?
>
> For example:
> - Can a TC1.7 traffic ops configure a Golang TM?
> - Does the Golang TM have any dependencies on a certain version of TrafficServer or astats?
> - Whats the minimum required version of Traffic Router to use the Golang TM?
> - I know Golang TMs can gossip with Java TMs, but can we mix versions here too? (i.e. TC1.7 Java TM with TC2.1 Golang TM)?
>
> —Eric
>
>
>> On Jul 14, 2017, at 1:00 PM, Jeff Elsloo <el...@apache.org> wrote:
>>
>> Hi all,
>>
>> We currently have two versions of Traffic Monitor: Java and golang.
>> When we build all components, as far as I know, it results in a race
>> condition between the two, as the resulting RPMs have the same
>> filename. A PR[1] was opened to address the issue and the approach was
>> to add `_go` to the version string used for the golang version's RPM.
>>
>> Rob and I both think we (Comcast) have enough experience running the
>> golang version that we have identified and corrected any major issues
>> and that it is stable enough to be the preferred Traffic Monitor hence
>> forth.
>>
>> Therefore, I propose that within the project's directory structure, we:
>>  1) rename traffic_monitor to traffic_monitor_legacy
>>  2) rename traffic_monitor_golang to traffic_monitor
>>
>> ..then work with the person that submitted the PR to take the same
>> approach, except change the Java version's RPM name to contain
>> `_legacy`.
>>
>> I realize that this is a fairly significant change, the type that we
>> typically reserve for major releases. The next major release, 3.0.0,
>> is likely to be some time out in the future, and I don't know that we
>> need to wait for it in order to make this change.
>>
>> How does the group feel about the above proposal, and executing on it
>> prior to the 3.0.0 release (i.e.: for 2.1.0)? Then, when we do
>> actually prepare the 3.0.0 release, we can remove the Java version
>> from the codebase entirely. Obviously this could impact anyone that
>> has automated CI systems building components, in addition to the
>> Apache CI we use ourselves.
>>
>> Thoughts?
>>
>> [1] https://github.com/apache/incubator-trafficcontrol/pull/731
>> --
>> Thanks,
>> Jeff
>

Re: Promote Golang Traffic Monitor to Default

["Eric Friedrich (efriedri)" <ef...@cisco.com>]

I think I remember Rob making this point in Miami, but all of TMs APIs (REST, CRConfig, Health.json, etc…) are identical between the Java and Golang version, right?

What about compatibility with earlier versions of TC?

For example:
- Can a TC1.7 traffic ops configure a Golang TM?
- Does the Golang TM have any dependencies on a certain version of TrafficServer or astats?
- Whats the minimum required version of Traffic Router to use the Golang TM?
- I know Golang TMs can gossip with Java TMs, but can we mix versions here too? (i.e. TC1.7 Java TM with TC2.1 Golang TM)?

—Eric


> On Jul 14, 2017, at 1:00 PM, Jeff Elsloo <el...@apache.org> wrote:
> 
> Hi all,
> 
> We currently have two versions of Traffic Monitor: Java and golang.
> When we build all components, as far as I know, it results in a race
> condition between the two, as the resulting RPMs have the same
> filename. A PR[1] was opened to address the issue and the approach was
> to add `_go` to the version string used for the golang version's RPM.
> 
> Rob and I both think we (Comcast) have enough experience running the
> golang version that we have identified and corrected any major issues
> and that it is stable enough to be the preferred Traffic Monitor hence
> forth.
> 
> Therefore, I propose that within the project's directory structure, we:
>  1) rename traffic_monitor to traffic_monitor_legacy
>  2) rename traffic_monitor_golang to traffic_monitor
> 
> ..then work with the person that submitted the PR to take the same
> approach, except change the Java version's RPM name to contain
> `_legacy`.
> 
> I realize that this is a fairly significant change, the type that we
> typically reserve for major releases. The next major release, 3.0.0,
> is likely to be some time out in the future, and I don't know that we
> need to wait for it in order to make this change.
> 
> How does the group feel about the above proposal, and executing on it
> prior to the 3.0.0 release (i.e.: for 2.1.0)? Then, when we do
> actually prepare the 3.0.0 release, we can remove the Java version
> from the codebase entirely. Obviously this could impact anyone that
> has automated CI systems building components, in addition to the
> Apache CI we use ourselves.
> 
> Thoughts?
> 
> [1] https://github.com/apache/incubator-trafficcontrol/pull/731
> --
> Thanks,
> Jeff

Re: Promote Golang Traffic Monitor to Default

["Gelinas, Derek" <De...@comcast.com>]

+1

> On Jul 14, 2017, at 1:00 PM, Jeff Elsloo <el...@apache.org> wrote:
> 
> Hi all,
> 
> We currently have two versions of Traffic Monitor: Java and golang.
> When we build all components, as far as I know, it results in a race
> condition between the two, as the resulting RPMs have the same
> filename. A PR[1] was opened to address the issue and the approach was
> to add `_go` to the version string used for the golang version's RPM.
> 
> Rob and I both think we (Comcast) have enough experience running the
> golang version that we have identified and corrected any major issues
> and that it is stable enough to be the preferred Traffic Monitor hence
> forth.
> 
> Therefore, I propose that within the project's directory structure, we:
>  1) rename traffic_monitor to traffic_monitor_legacy
>  2) rename traffic_monitor_golang to traffic_monitor
> 
> ..then work with the person that submitted the PR to take the same
> approach, except change the Java version's RPM name to contain
> `_legacy`.
> 
> I realize that this is a fairly significant change, the type that we
> typically reserve for major releases. The next major release, 3.0.0,
> is likely to be some time out in the future, and I don't know that we
> need to wait for it in order to make this change.
> 
> How does the group feel about the above proposal, and executing on it
> prior to the 3.0.0 release (i.e.: for 2.1.0)? Then, when we do
> actually prepare the 3.0.0 release, we can remove the Java version
> from the codebase entirely. Obviously this could impact anyone that
> has automated CI systems building components, in addition to the
> Apache CI we use ourselves.
> 
> Thoughts?
> 
> [1] https://github.com/apache/incubator-trafficcontrol/pull/731
> --
> Thanks,
> Jeff
> 

Re: Promote Golang Traffic Monitor to Default

[Robert Butts <ro...@gmail.com>]

+1

> it results in a race condition between the two, as the resulting RPMs
have the same filename

That used to happen, but it was fixed in 556ccf. But still, +1 on renaming
and making the Golang TM the default.


On Fri, Jul 14, 2017 at 11:00 AM, Jeff Elsloo <el...@apache.org> wrote:

> Hi all,
>
> We currently have two versions of Traffic Monitor: Java and golang.
> When we build all components, as far as I know, it results in a race
> condition between the two, as the resulting RPMs have the same
> filename. A PR[1] was opened to address the issue and the approach was
> to add `_go` to the version string used for the golang version's RPM.
>
> Rob and I both think we (Comcast) have enough experience running the
> golang version that we have identified and corrected any major issues
> and that it is stable enough to be the preferred Traffic Monitor hence
> forth.
>
> Therefore, I propose that within the project's directory structure, we:
>   1) rename traffic_monitor to traffic_monitor_legacy
>   2) rename traffic_monitor_golang to traffic_monitor
>
> ..then work with the person that submitted the PR to take the same
> approach, except change the Java version's RPM name to contain
> `_legacy`.
>
> I realize that this is a fairly significant change, the type that we
> typically reserve for major releases. The next major release, 3.0.0,
> is likely to be some time out in the future, and I don't know that we
> need to wait for it in order to make this change.
>
> How does the group feel about the above proposal, and executing on it
> prior to the 3.0.0 release (i.e.: for 2.1.0)? Then, when we do
> actually prepare the 3.0.0 release, we can remove the Java version
> from the codebase entirely. Obviously this could impact anyone that
> has automated CI systems building components, in addition to the
> Apache CI we use ourselves.
>
> Thoughts?
>
> [1] https://github.com/apache/incubator-trafficcontrol/pull/731
> --
> Thanks,
> Jeff
>