Sorry bout the nitpicking... Whatever approach we choose for naming, we should use “go” instead of “golang”.
"The language is called Go, not Golang. http://golang.org <https://t.co/dtRvuLrbZr> is just the the web site address, not the name of the language.” - Rob Pike https://twitter.com/rob_pike/status/886054143235719169 —Eric On Jul 20, 2017, at 8:04 AM, Steve Malenfant <[email protected]<mailto:[email protected]>> wrote: +1 to move to Golang. Few questions. Configuration seems like a none issue for us since we are using Ansible, we would prefer less postinstall interaction as possible as long as the configuration is documented. As for the name, do we plan to keep "traffic_ops_golang" in the future? Have we thought about using "traffic_ops" for golang and "traffic_ops_something" for Perl? It seems like the "Perl TO" should be the dependency here and should be handled by the RPM at installation. There could be confusion about folks not installing "traffic_ops_golang" on upgrades since they are doing a "yum update traffic_ops". If the dependency is this way, the golang version will need to be installed and the perl version as well. But you don't need to run any postinstall and simply need to change golang configuration to change the proxy. Talking about postinstall and migrations (SQL), which package would contain it in the future? The Perl or TO version? Is there something preventing re-using the same /opt/traffic_ops directory for both? Steve On Wed, Jul 19, 2017 at 5:25 PM, Dewayne Richardson <[email protected]<mailto:[email protected]>> wrote: 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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>> wrote: On Thu, Jul 13, 2017 at 11:11 AM, Robert Butts <[email protected]<mailto:[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]<mailto:[email protected]>
