Open Stack

On Thu, Feb 16, 2017 at 7:54 AM, Ian Cordasco <sigmavirus24 at gmail.com> 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.

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.

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

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.

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.

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.

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

dt

-- 

Dean Troyer
dtroyer at gmail.com