Open Stack

-----Original Message-----
From: Doug Hellmann <doug at doughellmann.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev at lists.openstack.org>
Date: February 16, 2017 at 07:06:25
To: openstack-dev <openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [chef] Making the Kitchen Great Again: A
Retrospective on OpenStack & Chef

> 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 > > > > 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.

I know the OpenStack-Ansible project went out of its way to try to
create a liaison program with the OpenStack services it works on. The
only engagement (that I'm aware) of it seeing has been from other
Rackspace employees whose management has told them to work on the
Ansible roles to ship the project they work on.

It seems like a lot of people view "developing OpenStack" as more
attractive than "making it easy to deploy OpenStack" (via the
deployment tools in the tent). Doing both is really something project
teams should do, but I don't think shoving all of the deployment
tooling in repo makes that any better frankly. If we put our tooling
in repo, we'll likely then start collecting RPM/Debian/etc. packaging
in repo as well.

I think what would help improve willing bidirectional communication
between service and deployment/packaging teams would be an
understanding that without the deployment/packaging teams, the service
teams will likely be out of a job. People will/can not deploy
OpenStack without the tooling these other teams provide.

Cheers,
--
Ian Cordasco