On Wed, 17 Feb 2016, Doug Hellmann wrote:
Excerpts from Chris Dent's message of 2016-02-17 11:30:29 +0000:
A reason _I_[1] think we need to limit things is because from the
outside OpenStack doesn't really look like anything that you can put
a short description on. It's more murky than that and it is hard to
experience positive progress in a fog. Many people react to this fog
by focusing on their specific project rather than OpenStack at
large: At least there they can see their impact.
I've never understood this argument. OpenStack is a community
creating a collection of tools for building clouds. Each part
implements a different set of features, and you only need the parts
for the features you want. In that respect, it's no different from
a Linux distro. You need a few core pieces (kernel, init, etc.),
and you install the other parts based on your use case (hardware
drivers, $SHELL, $GUI, etc.).
Ah. I think this gets to the heart of the matter. "OpenStack is a
[...] collection of tools for building clouds" is not really how I
think about it, so perhaps that's where I experience a problem. I
wonder how many people feel the way you do and how many people feel
more like I do, which is: I want OpenStack to be a thing that I, as
an individual without the help of a "vendor", can use to deploy a
cloud (that is easy for me and my colleagues to use) if I happen to
have >1 (or even just 1) pieces of baremetal lying around.
It's that "vendor" part that is the rub and to me starts bringing us
back into the spirit of "open core" that started the original
thread. If I need a _vendor_ to make use of the main features of
OpenStack then good golly that makes me want to cry, and want to fix
it.
To fix it, you're right, it does need a greater sense of "product"
"instead" of kit and the injection of opinions about reasonable
defaults and expectations of some reasonable degree of sameness
between different deployments of OpenStack. This is, in fact, what
much of the cross-project work that is happening now is trying to
accomplish.
This results in increasing the fog because cross-project concerns (which
help unify the vision and actuality that is OpenStack) get less
attention and the cycle deepens.
I'm not sure cross-project issues are really any worse today than
when I started working on OpenStack a few years ago. In fact, I think
they're significantly better.
I agree it is much better but it can be better still with some
reasonable sense of us all working in a similar direction. The
addition of "users" to the mission is helpful.
Architecturally and technically, project teams have always wanted
to go their own way to some degree. Experimentation with different
approaches and tools to address similar problems like that is good,
and success has resulted in the adoption of more common tools like
third-party WSGI frameworks, test tools, and patterns like the specs
review process and multiple teams managing non-client libraries.
So on a technical front we're doing better than the days where we
all just copied code out of nova and modified it for our own purposes
without looking back.
History is always full of weird stuff.
We've had to change our approaches to dealing with the growth,
and we still have a ways to go (much of it uphill), but I'm not
prepared to say that we've failed to meet the challenge.
I fear that I gave you the wrong impression. I wasn't trying to imply
that we are doing poorly at cross project things, rather that if we had
fewer projects we could do even better at cross project things (as a
result of fewer combinations).
Also that growth should not be considered a good thing in and of itself.
--
Chris Dent (�s°□°)�s�喋擤ォ� http://anticdent.org/
freenode: cdent tw: @anticdent
__________________________________________________________________________
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
