When: Read · Wed, Jul 19. If Cc: read <https://timyo.com/?utm_source=expectationheader&utm_medium=email> [image: Timyo expectation line] I had a knee jerk reaction to separate the RPMs because of the potential for a "new" approach, but I've now been convinced otherwise based upon the "Strangler Pattern" where the Perl gets rewritten into Golang overtime and the TO clients know none the difference.
+1 -Dew On Wed, Jul 19, 2017 at 12:52 PM, Jeff Elsloo <[email protected]> wrote: > I see. If that's the case, it's a hard requirement to run the golang > portion from whenever this is introduced onward. As long as we have > discipline around removing migrated routes, that should work okay and > would solve the "two watches" issue Mark mentioned when we discussed > this in person: A man with two watches (old API route, golang route) > does not know what time it is. > > I don't think that it makes a lot of sense to have a separate RPM > since the dependency goes the other direction, and users are required > to run the golang component no matter what. We might as well just > build that into the existing RPM build process for traffic_ops. > > Do we really need to ask the user for the port to move mojo to? > Obviously we can ask them to provide a port, but we could also just > pick a random, unused high port, and have mojo listen only on the > loopback interface. Maybe that's too "magical"? > > Does the golang app run as trafops:trafops and drop privileges after > opening :443? > -- > Thanks, > Jeff > > > On Wed, Jul 19, 2017 at 11:58 AM, Robert Butts <[email protected]> > wrote: > >> This means that the traffic_ops side would have to check to see whether > >> traffic_ops_golang > > > >> Because the traffic_ops_golang package will depend on traffic_ops, not > the > >> other way around > > > > I was suggesting the other way around - traffic_ops will depend on > > traffic_ops_golang. Which means upgrading traffic_ops automatically > installs > > traffic_ops_golang, and we don't need to do the check. It'd mean you > > couldn't remove `traffic_ops_golang`, but the plan is to remove old > > endpoints from old TO anyway. Which is another reason making > > traffic_ops_golang a dependency of traffic_ops makes sense: it really is, > > traffic_ops really does require it for the migrated endpoints. > > > > I agree with moving away from manual post-installation scripts, but I > don't > > think we can avoid it here, because we need the user to set a new port. > > > > > > On Wed, Jul 19, 2017 at 11:40 AM, Jeff Elsloo <[email protected]> wrote: > >> > >> I'm +1 on most of what you suggest, except for doing the takeover in > >> postinstall in traffic_ops. > >> > >> While we can do whatever we want with postinstall, I think it's > >> awkward to have a tool within the traffic_ops package configuring > >> something under the traffic_ops_golang package, when the latter > >> package might not be installed. This means that the traffic_ops side > >> would have to check to see whether traffic_ops_golang is installed > >> outside of the normal RPM dependencies, adding more platform specific > >> code to postinstall. I don't see a generic way to implement the > >> "check" for the golang package within postinstall that will work. We > >> would have to check for a path that is not likely to exist for most > >> users, or check for a package. Both approaches require platform > >> specific code and assumptions. > >> > >> Because the traffic_ops_golang package will depend on traffic_ops, not > >> the other way around, it makes more sense to place the configuration > >> piece in the golang package. When the golang package is installed, we > >> can "take over" the port in the listen directive of cdn.conf, because > >> we know for a fact that it is on disk because of the RPM dependency on > >> traffic_ops. We also know that cdn.conf will be left alone if/when > >> traffic_ops is upgraded due to being marked as a config file. If the > >> user has installed either component outside of the normal RPM process, > >> they will have to figure out how to run the golang package separately, > >> as one would expect. > >> > >> We can do the configuration during the postinstall step of the > >> traffic_ops_golang RPM. It's advantageous to manage that piece within > >> the RPM, because if, for example, one wanted to remove the golang > >> portion, we could have a postuninstall step that reverts changes made > >> to cdn.conf (put the port we took over back into cdn.conf). We could > >> seamlessly add and remove the traffic_ops_golang component without > >> disturbing anything in traffic_ops, and without having to run some > >> script manually. The platform specific things that would need to be > >> done in postinstall should be done in the RPM, because then we know > >> for sure which platform we're on, and assumptions about packages and > >> paths will be accurate. > >> > >> Ideally we should be moving away from any manual run of any script > >> after an installation or upgrade, including postinstall, if that work > >> can be done within the RPM. > >> -- > >> Thanks, > >> Jeff > >> > >> > >> On Wed, Jul 19, 2017 at 9:08 AM, Robert Butts <[email protected] > > > >> wrote: > >> > It sounds like the only -1 is having a unified Service and RPM. > >> > > >> > How about the following compromise: a separate RPM and Service for the > >> > New > >> > TO, and the New TO RPM is a dependency of Old TO, and likewise the > >> > Service > >> > is a dependency of `traffic_ops`. This way, upgrades will still > require > >> > building the New TO RPM and adding it to Yum, but `yum upgrade` will > >> > automatically install it without additional ops work, and `service > >> > traffic_ops start` will also start the New TO. Bearing in mind this > >> > double-service awkwardness will go away when all endpoints are > migrated. > >> > > >> > Also, @alficles suggested configuring the New TO Config in Postinstall > >> > (which must be run after upgrading anyway). Because the New is a > >> > dependency > >> > of the Old, we're guaranteed `/opt/traffic_ops_golang` exists in > >> > Postinstall, and can populate its config. > >> > > >> > Also, I realized the New TO needs moved from > >> > `/traffic_ops/traffic_ops_golang` to `/traffic_ops_golang`, because > >> > `build_all.sh` requires projects be in the root directory. > >> > > >> > Also, I will add tests, docs, and configurable logging before the PR > is > >> > merged. (Just wanted to wait until we had consensus before putting > more > >> > work > >> > into it.) > >> > > >> > How does that sound? > >> > > >> > > >> > On Thu, Jul 13, 2017 at 1:00 PM, Robert Butts < > [email protected]> > >> > wrote: > >> >> > >> >> @dewrich It's not that putting both services in the same Service and > >> >> RPM > >> >> is a good long-term solution; it's that it's easier to configure and > >> >> deploy. > >> >> A separate RPM and service is another step to install, and another > step > >> >> to > >> >> start the service. It's not that it's good, it's that it's the lesser > >> >> of two > >> >> evils. My fear is, the more complex we make this, the less chance of > >> >> getting > >> >> it done at all. > >> >> > >> >> @efriedri > >> >> 1. Same answer: long-term, I absolutely agree proxies should be > >> >> separate. > >> >> But this is the simplest way to deploy an incremental migration. > >> >> 2. Yes, the Perl GUI can transparently request what it needs. That's > a > >> >> goal of this: transparent new endpoints, that existing services don't > >> >> know > >> >> or care that they come from a different backend. > >> >> > >> >> Also bear in mind, this "proxy" only exists until Perl TO goes away. > >> >> Having it in the same Service and RPM as old TO, and having the proxy > >> >> be the > >> >> same binary as the new endpoints, makes it easier to completely > remove > >> >> the > >> >> Proxy and Perl, once every endpoint is rewritten. If we make the > >> >> Service and > >> >> RPM separate, you have to change configs and uninstall the separate > >> >> Service > >> >> and RPM of the Perl TO. If the Proxy is a separate binary, you have > to > >> >> uninstall that, and then change the config of the Golang TO to serve > on > >> >> the > >> >> real port (443). As proposed, once all endpoints are rewritten, we > >> >> simply > >> >> remove the old TO from the RPM and Service, and users just upgrade, > and > >> >> it > >> >> keeps working, with no changes to config, Puppet, RPM, or anything > >> >> else. > >> >> > >> >> I'd fully support different RPMs, different Services, and a separate > >> >> Proxy, once this is deployed. The fear is that the more complex we > make > >> >> this, the less chance it gets deployed at all. > >> >> > >> >> > >> >> On Thu, Jul 13, 2017 at 12:23 PM, Eric Friedrich (efriedri) > >> >> <[email protected]> wrote: > >> >>> > >> >>> Rob- > >> >>> Two minor questions: > >> >>> > >> >>> 1) An alternative approach could have been using an LB/proxy to > >> >>> choose > >> >>> between perl and golang TO’s. Any particular reason you chose to > proxy > >> >>> requests to the perl TO instead? > >> >>> > >> >>> 2) As APIs are rebuilt in golang which effect GUI components, what > >> >>> does > >> >>> this mean for the perl GUI? Will we continue updating the perl GUI > to > >> >>> interact with updated golang APIs? (until we cut over to Jeremy’s > >> >>> Angular > >> >>> UI) > >> >>> > >> >>> —Eric > >> >>> > >> >>> > >> >>> > >> >>> > On Jul 13, 2017, at 12:39 PM, Eric Covener <[email protected]> > >> >>> > wrote: > >> >>> > > >> >>> > On Thu, Jul 13, 2017 at 11:11 AM, Robert Butts > >> >>> > <[email protected]> wrote: > >> >>> >> A Golang application which serves endpoints which have been > >> >>> >> rewritten, > >> >>> >> and > >> >>> >> reverse-proxies the old Perl Traffic Ops for all other requests. > >> >>> >> This > >> >>> >> app > >> >>> >> can be included in the RPM and Service files for Traffic Ops. > Then, > >> >>> >> the old > >> >>> >> Traffic Ops config can be changed to a different port (say, > 60443), > >> >>> >> and the > >> >>> >> new Go Traffic Ops can be configured to serve on 443, and > >> >>> >> reverse-proxy to > >> >>> >> the old application. Both applications will run on the same > >> >>> >> machine. > >> >>> > > >> >>> > > >> >>> > Sounds neat and you didn't resort to saying "microservices"! > >> >>> > > >> >>> > -- > >> >>> > Eric Covener > >> >>> > [email protected] > >> >>> > >> >> > >> > > > > > >
