Open Stack

-----Original Message-----
From: Dean Troyer <dtroyer at gmail.com>
Reply: OpenStack Development Mailing List (not for usage questions)
<openstack-dev at lists.openstack.org>
Date: February 16, 2017 at 08:27:12
To: OpenStack Development Mailing List (not for usage questions)
<openstack-dev at lists.openstack.org>
Subject:  Re: [openstack-dev] [chef] Making the Kitchen Great Again: A
Retrospective on OpenStack & Chef

> On Thu, Feb 16, 2017 at 7:54 AM, Ian Cordasco wrote:
> > 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.
>
> Part of it _is_ the "deployment isn't shiny/new/features", but there
> is also the historical view lingering that we ship tarballs (and
> realistically, git repo tags) so as not to pick favorites and to keep
> deployment and packaging out of the project repos directly.

Right, I understand that.

> We have >5 different tools that are "mainstream" to consider, not even
> the large project teams have enough expertise to maintain those. I
> had a hard enough time myself keeping both rpm and apt up to date in
> previous projects, much less recipies, playbooks and the odd shell
> script.

Next week it'll be 7. ;)

> It is also hard to come in to a community and demand that other
> projects suddenly have to support your project just because you showed
> up. (This works both ways, when we add a "Big Tent" project, now all
> of the downstreams are expected to suddenly add it.)

Right. And we've seen teams like the UCA team be selective in what
they add (rightfully so).

> The solution I see is to have a mechanism by which important things
> can be communicated from the project developers that can be consumed
> by the packager/deployer community. Today, however sub-optimal it
> seems to be, that is release notes. Maybe adding a specific section
> for packaging would be helpful, but in practice that adds one more
> thing to remember to write to a list that is already hard to get devs
> to do.

I would think the mailing list (with a certain tag) might be better.

> Ad Doug mentions elsewhere in this thread, the liaison approach has
> worked in other areas, it may be a useful approach here. But I know
> as the PTL of a very small project I do not want 5 more hats to wear.
> Maybe one.

Right. And teams like Glance are struggling with their review queue
given the contraction you mention later on.

> We have encouraged the packaging groups to work together in the past,
> with mixed results, but it seems to me that a lot of the things that
> need to be discovered and learned in new releases will be similar for
> all of the downstream consumers. Maybe if that downstream community
> could reach a critical mass and suggest a single common way to
> communicate the deployment considerations in a release it would get
> more traction. And a single project liaison for the collective rather
> than one for each deployment project.

We also have packaging teams that repeatedly denegrate others who
create derivatives of their work while discouraging and denigration
others' participation. I think that coordination will be hard until
those packagers learn the hard lessons of their harmful actions.

> > 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.
>
> True in a literal sense. This is also true for our users, without
> them nobody will deploy a cloud in the first place. That has not
> changed anything unfortunately, we still regularly give our users
> miserable experiences because it is too much effort to participate
> with the (now comatose) UX team or prioritize making a common log
> format or reduce the number of knobs available to twiddle to make each
> cloud a unique snowflake.
>
> We can not sustain being all things to all people. Given the
> contraction of investment being considered and implemented by many of
> our foundation member companies, we will have to make some hard
> decisions about where to spend the resources we have left. Some of
> those decision are made for us by those member companies promoting
> their own priorities (your example of Ansible contributions is one).
> But as a community we have an opportunity to express our desires and
> potentially influence those decisions.

We are in nearly-violent agreement here. Perhaps given my own
cross-team focus (as a result of my own emmployer's interests) I am
biased in thinking that other service teams should be made up of
similarly cross-functional developers.

If we're being frank, we have 5 deployment strategies (at least?) and
if we could convince member companies to standardize (like we try to
help them standardize on APIs) then maybe that would improve the
collaboration and success of these projects.

Just looking ahead, we have several upgrade efforts going on in most
of the service projects (Rolling Upgrades, Zero-Downtime Upgrades,
etc.). Deployers want those features, that will put pressure on
already strained deployment teams to solve them, and the likelihood is
that each solution will be just different enough that they'll run into
different problems. That said, part of that problem is that different
service teams are achieving those solutions via just slightly
different methods. There is a good foundation of cross-project
communication in our community, but I'm worried it's not enough.

--
Ian Cordasco