Le 16/02/2017 10:17, Neil Jerram a écrit :
> On Thu, Feb 16, 2017 at 5:26 AM Joshua Harlow <harlo...@fastmail.com
> <mailto:harlo...@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.

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

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to