Open Stack

Excerpts from Sylvain Bauza's message of 2017-02-16 10:55:14 +0100:
> 
> Le 16/02/2017 10:17, Neil Jerram a écrit :
> > On Thu, Feb 16, 2017 at 5:26 AM Joshua Harlow <harlowja at fastmail.com
> > <mailto:harlowja at fastmail.com>> 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.

Right. The liaison program used by other cross-project teams is
designed to deal with this communication gap by identifying someone
to focus on ensuring the communication happens. Perhaps we need to
apply that idea to to some of the deployment projects as well.

Doug

> 
> 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: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> > 
>