I personally equate OpenStack to the Linux Kernel. It's the foundation and core components that, in OpenStack's case, make up an Infrastructure as as Service (IaaS) system, a "cloud" kernel. We should expect the core components and APIs to be stable with sane deprecation policies, but OpenStack shouldn't do everything for everyone. It should facilitate and provide the stable framework or foundation in which to build production quality, large scale (and small) public and private IaaS systems. In and of itself I believe OpenStack is not an IaaS distribution, ala Linux distributions (Debian, Fedora, RedHat, SuSe, Ubuntu) which take the Linux kernel and build all the user-space and complementary services that make up a manageable, secure, monitored system.
However, that doesn't mean OpenStack ignores the user/operator/packager/distro side of things. Where we the developers and operators of OpenStack see areas to make configuration, management, development, documentation of OpenStack easier we strive to incorporate those things back into core. None of the above is meant as criticism, it's simply how I categorize OpenStack in the cloudy landscape. Nate On Aug 10, 2012 5:47 PM, "Andrew Clay Shafer" <a...@parvuscaptus.com> wrote: > > What is OpenStack? > > Clearly, OpenStack is many things to many people and organizations. > > What does it mean to contribute to OpenStack? What does it mean to deploy > OpenStack? What does it mean to operate OpenStack? > > What do we mean when we say compatible? interoperable? community? branded? > > Is OpenStack a framework? a project? a product? > > Recent discussions make it clear that we have a lot of different ideas > about all of these things. > > Our collective and individual responsibilities to each other are also a > point of tension. > > There is a marked difference in the perspective of those developing the > projects, those operating the projects as services and the final > consumers/clients of those services. > > If OpenStack is going to live up to it's full potential and stated > mission, I believe there needs to be a much stronger collective conscience > about how decisions are made. > > I feel we will all benefit by making some things more explicit. > > If the expectation is that OpenStack is a framework, which is a word I've > heard people use many times, then does an upgrade path have to exist? > > The OpenStack dashboard was essentially rewritten to upgrade to a new > version of Django. Was there any expectation that Django should upgrade > itself for us? > > Upgrading an application to use a different versions of Rails, another > framework, often borders on impossible, particularly if the application > happens have some feature with a dependency of a gem that hasn't been kept > in sync with the upstream project. > > Is OpenStack more or less complicated than those frameworks? What > responsibility should OpenStack core development have to consider existing > deployments? Frameworks are expected be a foundation to build on. By > definition, changing foundations is not easy. Clearly, OpenStack can be > deployed and operated, but if OpenStack needs to be easier to deploy, > operate and upgrade, and that is a responsibility of OpenStack itself, that > can't be something that get's tacked on at the end. There is no 'ease of > deployment' powder to sprinkle on at the end. > > Distributions and tooling can and do obscure the difficultly for the > downstream user, but that also leads to a lot of potential fragmentation. > And is that the right answer? Who can and should answer that? > > That OpenStack should be easy to deploy and upgrade is somewhat at odds > with OpenStack supporting every possible combination of hypervisor, storage > and networking option, let alone what the expectation should be with closed > source customizations/integrations. > > Which brings up questions of compatibility. API compatibility is > potentially misleading if the semantics and behaviors vary. I've heard > several service provider discuss ideas about how they can be differentiated > in the market, and many of those ideas lead differences in APIs to expose. > Is that wrong? Maybe, maybe not, but it certainly makes a lot of work if > your core business is dependent on maintaining integrations with service > providers. Taken to an extreme these decisions complicate and call into > question any future of federated OpenStack services. > > I'm not advocating any choice here. > > I just want to point out there are compromises that have to be made. There > are goals and desires for OpenStack that are at odds with each other. > > Some of that is a function of the perspective of persona, but a lot is > also from fundamental differences in understanding about where OpenStack > is, where OpenStack needs to be, and how to get there. > > If there isn't a core guiding conscience about what we are trying to > accomplish that gets applied across the board, then I worry that the future > of OpenStack ends up with more fragments optimizing for their perspective > and inevitable skirmishes when the perspectives collide. > > I see there are many conversations we aren't having, which leads to > surfacing all the unaddressed issues when someone does try to involve the > community in discussions. > > OpenStack can't be all things, but we get to decide what it will be. > > The question is will we do that explicitly and consciously, or indirectly > and passively. > > There is no one person who can address this alone. > > I'm hoping this can start a conversation. > > Best Regards, > Andrew > > _______________________________________________ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > >
_______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
