Le 16/02/2017 10:17, Neil Jerram a écrit : > On Thu, Feb 16, 2017 at 5:26 AM Joshua Harlow <[email protected] > <mailto:[email protected]>> wrote: > > Radical idea, have each project (not libraries) contain a dockerfile > that builds the project into a deployable unit (or multiple dockerfiles > for projects with multiple components) and then it becomes the projects > responsibility for ensuring that the right code is in that dockerfile to > move from release to release (whether that be a piece of code that does > a configuration migration). > > > I've wondered about that approach, but worried about having the Docker > engine as a new dependency for each OpenStack node. Would that matter? > (Or are there other reasons why OpenStack nodes commonly already have > Docker on them?) >
And one could claim that each project should also maintain its Ansible playbooks. And one could claim that each project should also maintain its Chef cookbooks. And one could claim that each project should also maintain its Puppet manifests. I surely understand the problem that it is stated here and how it is difficult for a deployment tool team to cope with the requirements that every project makes every time it writes an upgrade impact. For the good or worst, as a service project developer, the only way to signal the change is to write a release note. I'm not at all seasoned by all the quirks and specifics of a specific deployment tool, and it's always hard time for figuring out if what I write can break other things. What could be the solution to that distributed services problem ? Well, understanding each other problem is certainly one of the solutions. Getting more communication between teams can also certainly help. Having consistent behaviours between heteregenous deployment tools could also be a thing. That's an iterative approach, and that takes time. Sure, and that's frustrating. But, please, keep in mind we all go into the same direction. -S > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
