Excerpts from Chris Dent's message of 2016-02-17 17:00:00 +0000: > 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.
You don't need a vendor to use OpenStack. The community has deployment stories for, I think, every possible automation framework. Packages are available for distros that don't have license fees. It is entirely possible to deploy a cloud using these tools. The challenge with deployment is that everyone wants to make their own choices about the cloud they're building. If we were going to give everyone the same sort of cloud, all of OpenStack would be a lot simpler and no one would want to use it because it wouldn't meet their needs. If some of the existing installation mechanisms don't meet simplicity requirements, we should figure out why, specifically. It's quite likely there's room for a "fewer choices needed" deployment tool that expresses more opinions than the existing tools, and is useful for some simpler cases by removing some of the flexibility. > > >> 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). OK. Speaking as someone heavily involved in "cross project things" when we had only a very few projects, I can report that at that time we did not do as well at cooperation even as we are doing today. That's not to say you're wrong about the future, since I think more people see the value in those efforts today. It's just a data point about the past. > Also that growth should not be considered a good thing in and of itself. No more so than it should be seen as a bad thing. Doug __________________________________________________________________________ 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
