Re: Removing 'internal' from TO API

I think we should do as Dave mentioned, assess and rename. > On Mar 15, 2017, at 2:18 PM, Jeremy Mitchell wrote: > > I don't like duplicating routes either but I thought it would ease the > transition rather than just changing the route. So no code duplication, > just 2

Re: Removing 'internal' from TO API

I don't like duplicating routes either but I thought it would ease the transition rather than just changing the route. So no code duplication, just 2 routes that go to the same place: $r->get("/internal/api/$version/steering")->over( authenticated => 1 )->to( 'Steering#index', namespace =>

Re: Removing 'internal' from TO API

At least a few of those (Steering, federations) were put in the "internal" namespace to work around Comcast specific issues. I don't know that I like the idea of duplicating routes, if anything we should see what is impacted by moving them out of the internal namespace. On Wed, Mar 15, 2017 at

Re: Public CI Builds for Traffic Control

So, after some investigation, I've circled back on the mounting docker-compose sideways and letting it manage sibling containers. It appears that docker folks have already tamed the maddest of the madness. There's a relatively reasonably supported script for doing it that I was able to reasonably

Re: Public CI Builds for Traffic Control

Docker isn't required to build the software, it's just another option. There's a build script, `build/build.sh`, that works just fine so long as you have the dependencies required to successfully build all components. I only mention this because if Docker is going to gate our ability to perform CI