Open Stack

I'd like to swap the perspective of the definition here.

There is a lot of concern about what pieces a deployer may or may not
want to run, which is understandable given the background of a lot of us.

However, as a USER of two of these clouds, I can tell you that every
single solitary time that one of these clouds "decides" to not run some
piece of OpenStack (keystone reimplementations) or runs/doesn't run
their own thing because OpenStack doesn't have one yet (DNSaaS) it makes
my life a living hell. As a user, I do not benefit from those deployer
decisions, and the value of OpenStack as a Open Source Cloud Operating
System from a user's point of view is diminished.

It is not helpful to me as a user that Rackspace Cloud requires a
non-standard header to be set to access their re-implementation of keystone.

It is not helpful to me as a user that I have no way to set DNS entries
on my HP Cloud nodes - although there are discussions out there that
DNSaaS should for some bizarre reason not be a part of OpenStack.

It is not helpful to me as a user that HP and Rackspace's Web Dashboards
are completely different.

It is not helpful to me as a user that Rackspace and HP each have
branded versions of client libraries for download from their site - even
though the upstream versions of those client libraries should work out
of the box against an OpenStack cloud.

It is not helpful to me as a user that HP has it's own CLI - although HP
sees it as necessary to provide a consistent experience for their users
as they might deploy some services that OpenStack doesn't have CLI
support for.

I think it's our duty to protect our users, so I think it's important
for us to ensure that we have services and APIs for everything our users
want - so that HP doesn't have to make it's own crazy vendor-lock-in
inducing CLI.

I think:
- There should be only Core
- It should include all of the things that a user would want (IaaS,
- No one should be able to call themselves an OpenStack Cloud unless
they deploy every single OpenStack API that exists in a manner that
works with the stock OpenStack client libraries.

Any other set of actions by their nature will create a fragmented
playing field, because every time we don't have an opinion on a key
element, some annoying company is going to go off an "differentiate" and
users are going to suffer.

Monty

On 11/08/2012 06:34 AM, John Dickinson wrote:
> 
> On Nov 7, 2012, at 5:10 PM, Gabriel Hurley
> <Gabriel.Hurley at nebula.com> wrote:
> 
>> Let me throw out a different possible definition of Core:
>> 
>> 
>> OpenStack Core is a set of recommended components which work
>> together to comprise a "batteries-included" OpenStack Cloud.
>> 
>> 
>> That definition does not imply that any component in Core is
>> irreplaceable or that they all must be deployed, and it leaves room
>> for the technical judgment of the TC and the Board to determine
>> what projects benefit the entire community and project by being
>> "recommended" at the expense of hindering ecosystem competition.
>> 
>> In case you couldn't tell, I'm not in favor of an IaaS-only Core...
>> I don't want to see the voices of arguably *critical* non-IaaS
>> projects (Horizon, Ceilometer, Heat, and even Keystone) be
>> sidelined.
>> 
>> Speaking of Keystone, it's not infrastructure either. It doesn't
>> compute, store or move data (not in the way John meant), but your
>> stack is gonna suffer without it. It's *recommended*. You can run
>> OpenStack with only Nova and Glance if you want to. Quantum, Swift
>> and Cinder may be infrastructure but they're nice-to-haves. Swift
>> isn't even enabled by default in DevStack. Defining what is
>> *necessary* infrastructure (e.g. Core) is a complicated issue. The
>> bar can't just be "IaaS".
> 
> 
> While I think your definition is pretty good, you have a false
> dichotomy that an IaaS-only Core requires that all must be deployed
> at the same time. To rephrase your last statement (with tongue firmly
> planted in my cheek): You can run OpenStack with only Swift if you
> want to. Nova, Quantum, and Cinder may be infrastructure, but they're
> a nice-to-haves. Swift solves storage needs, and it also happens to
> be useful in storing Nova's VM images.
> 
> Now, I'm not saying that the Core projects don't need to work
> together or integrate. I think core-project cooperation is an
> important part of being "core". But an IaaS-only core still allows
> for the individual core projects to be deployed independently and be
> useful on their own. (The trademark branding on how such a deployment
> can use the OpenStack mark is a separate discussion for the board of
> directors.)
> 
> The problem with a "core as necessary projects" definition is that
> it's fuzzy and is different to each deployer. Rackspace doesn't use
> Keystone. Does that mean it's not "necessary"? SwiftStack customers
> don't use Nova. Is it "necessary"? What about the Nova deployments
> that don't use Swift or Cinder? Beyond these, the general usefulness
> of ceilometer, heat, and horizon becomes even more unsure. They
> absolutely solve important problems, but they do so in a way that is
> not as generally applicable to deployments (from a "you must install
> this for it to work" perspective).
> 
> The way around this is for projects to be API integration points, but
> that implies that OpenStack becomes an API standards body. That's a
> separate discussion, but something I'm completely opposed
> to--implementations matter and are a vital part of the project
> definition.
> 
> The important thing is that deployments solve use-cases. In my mind,
> those use cases are commonly rooted in infrastructure (compute,
> storage, and networking). That's why OpenStack Core should be defined
> as IaaS, and the "batteries-included" parts should be part of the
> ecosystem but not part of core.
> 
> --John
> 
> 
> 
> 
> 
> _______________________________________________ OpenStack-dev mailing
> list OpenStack-dev at lists.openstack.org 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>