On Fri, Aug 2, 2019 at 4:28 PM Dave Neuman <neu...@apache.org> wrote: > I do think large changes like this might be better first discussed and > requirements understood before we write code. I realize that it's hard to > actually accomplish that with so many different opinions, but I do think > it's the right thing to do. Having discussions up front lets us think > through things as a group and in my experience often leads to a better > solution.
+100 on this. Internally at Comcast some of us have been kicking around the idea of a blueprint design process, where the general idea is you: 1. get some initial feedback from a smaller set of stakeholders on requirements 2. given an initial set of requirements, fill out a blueprint template describing the problem, proposed solution and design, areas of impact, etc 3. open a PR of just your new blueprint and ask the community for input 4. any community stakeholders can provide feedback directly on the blueprint PR 5. once design feedback has been addressed, the blueprint PR is merged 6. implementation of the blueprint will begin This process basically gives all interested parties the ability to provide input on a design before the implementation begins, so that we can better address everyone's concerns and ideas. If there are certain trade-offs to be made as part of the design, those trade-offs would be agreed upon in the PR review and included in a section of the blueprint for posterity. There are multiple other advantages to the blueprint process as well, such as being a good starting point for user-facing documentation, a resource for QA to verify the feature against, and information about what's new in a release. Writing up a blueprint would be optional, of course, but my hope is that by doing it, the benefit of writing a blueprint first will speak for itself and encourage contributors to follow the process. If you're curious what a blueprint could look like, Jeremy and I have been pitching the idea here for feedback (it includes a template along with a couple examples of completed blueprints): https://github.com/ocket8888/trafficcontrol/pull/2 On Fri, Aug 9, 2019 at 3:45 PM Robert Butts <r...@apache.org> wrote: > > Architecture wise, I'm in favor of the traffic ops sending the specific > > configuration to the cache. Main reason is taking features like "DS > > *individual *automatic deployment" > > into account, where we would like to be able to control "which server get > > which configuration and when" - e.g. edge cache "A" can be assigned with a > > DS only after all its parents are aware of the DS. I believe that if the > > control of "what configuration is pulled" is in the hand of the cache, the > > complexity of the cfg distribution flow would increase and debug-ability > > would be very difficult. > > @nirs Those are valid points, and I don't want to steamroll over your > concerns. But on some level, I'm afraid our concerns are at odds, being > able to canary versus having a single config source. I have a couple ideas > how we might reconcile them. I don't think they necessarily have to be at odds. We could still have TO push the set of config data to the caches without having it push the actual config files themselves. The caches would then digest the config data and generate their own config files from that. We'd get both the ability to canary config generation and the ability to push data from TO to ORT instead of ORT polling TO for data. - Rawlin
