Open Stack

Excerpts from James Slagle's message of 2014-02-15 13:02:36 -0800:
> On Fri, Feb 14, 2014 at 11:12 PM, Robert Collins
> <robertc at robertcollins.net> wrote:
> > On 15 February 2014 08:42, Dan Prince <dprince at redhat.com> wrote:
> >>
> >
> >> Option B is we make our job easy by strong arming everyone into the same defaults of our "upstream" choosing.
> >
> > Does Nova strong arm everyone into using kvm? Its the default. Or
> > keystone into using the SQL token store - its the default?
> >
> > No - defaults are not strong arming. But the defaults are obviously
> > defaults, and inherited by downstreams. And some defaults are larger
> > than others -  we've got well defined interfaces in OpenStack, which
> > have the primary characteristic of 'learn once, apply everywhere' -
> > even though in principle you can replace them. At the low level REST
> > and message-bus RPCs, at a level up Keystone and more recently Nova
> > and Neutron have become that as we get higher order code like Heat and
> > Savanna that depend on them. I hope none would replace Nova with
> > Eucalyptus and then say they're running OpenStack - in the same way
> > we're both defining defaults, *and* building interfaces. *That* is our
> > job - making OpenStack *upstream* deployable, in the places, and on
> > the platforms, with the options, that our users want.
> >
> > Further to that, upstream we're making choices with the thoughts of
> > our *users* in mind - both cloud consumers and cloud operators. They
> > are why we ask questions like 'is having every install have
> > potentially different usernames for the nova service a good idea'. The
> > only answer so far has been 'because distros have chosen different
> > usernames already and we need to suck it up'. Thats not a particularly
> > satisfying answer.
> 
> It seems we're talking defaults now. I did not get that from the email
> that started the discussion, it sounded like an "either or" to me.
> 
> So, if we're talking defaults, let the upstream architecture be the
> default. Let your #A be a choice. If someone wants to come along and
> do #B, we let them, but I really don't think you'd fine anyone :).
> 
> We question and we challenge new implementations (just like we always
> do and as you're doing here, which is good).  But at the end of day if
> someone is saying they have a real documented need in order for them
> to adopt OpenStack, and it makes sense for that option to be "in tree"
> for OpenStack,  we empower them by having a flexible framework, and
> hopefully our tools are good enough to handle what differences there
> are. If not, we make them better.
> 
> I'm not sure I entirely get the comparisons to Nova you're making. Let
> me take a shot though and try to further it along as I see it:
> 
> Let the dib style element be the "API". What the implementation is,
> whether a source install or a package install shouldn't affect the
> interface. And there's no reason to "coerce" all the implementations
> to be exactly the same.
> 
> The Nova virt drivers (libvirt/kvm, libvirt/xen, xenapi, etc) are our
> different install types today, source-install, package-install. Our
> different install type implementations still conform to the framework,
> our install scripts have to be in the right place, we make use of
> install-packages, we use os-svc-*, we use os-*-config, etc. Just like
> the python code for each Nova virt driver has requirements (the
> correct base class inheritance, methods, etc).
> 
> However, Nova makes no enforcement of how each driver is *actually*
> implemented. It doesn't particularly care about what's happening in
> each driver's power_on method.  It doesn't enforce that all
> hypervisors kernel modules are called the same thing so that it's
> easier to check if you loaded the right one. No one said that we can't
> have a Nova baremetal driver b/c what if someone drops down to the
> console to troubleshoot and they run "virsh list" and don't see
> baremetal instances.  Coercing the implementation to be the same just
> doesn't make sense to me, and I think where this comparison you're
> making really breaks down.
> 
> The abstracting away of the hypervisor differences happens in the virt
> drivers. For TripleO's purposes, the abstracting away of the install
> type particularities should happen by the install and setup code. Not
> by trying to coerce things to look the same after the fact, which
> sounds to me exactly like what Nova *doesn't* do and require.
> 
> >> Take /mnt/state for example. This isn't the normal place for things to live. Why not use the read only root mechanism some distributions already have and work with that instead. Or perhaps have /mnt/state as a backup solution which can be used if a mechanism doesn't exist or is faulty?
> >
> > Currently we have two options for upgrading images. A) /mnt/state, B)
> > a SAN + cinder. We haven't tested B), and I expect for many installs B
> > won't be an option. /mnt/state is 100% technical, as no other options
> > exist - none of the Linux distro 'read only root' answers today answer
> > the problem /mnt/state solves in a way compatible with Nova.
> >
> >> In the end I think option A is the way we have to go. Is it more work... maybe. But in the end users will like us for it. And there is always the case that by not reimplementing some of the tools and mechanisms which already exist in distros that this ends up being less work anyways. I do hope so...
> >
> > Certainly we're trying very hard to keep things we reimplement minimal
> > and easily swap-outable (like o-r-c which I expect some deployments
> > will want to replace with chef/puppet).
> 
> As I said above, the swap-outable defaults is what I think is the real key here.
> 
> We work hard to have a great upstream architecture, but we allow for
> variation with opt-in and opt-out. It doesn't necessarily mean that
> all variants have to be in the openstack TripleO git repos. But, where
> there's a cross section of folks wanting a particular variant, and
> there's people in the community volunteering to do the work and
> support it, I think it makes sense to consider those variants on their
> individual merits.
> 
> /mnt/state is a great example of that. There was nothing consistent
> across distros, so TripleO did it's own relatively straightforward
> implementation that could be used on any distro. But, TripleO
> shouldn't necessarily *enforce* that it's used. It doesn't have to be
> an all-or-nothing  type approach IMO.
> 

All of the above is well said. I agree that there should not be
enforcement. I think what Robert and I are concerned about is that the
more we have to divert attention away from the core architecture into
modularizing for alternatives, the less velocity we will have.

It is important to make sure we're empowering support organizations to
work today, and not making them retool everything too. The balancing
act of "success today" versus "healthy ecosystem" is non-trivial, but
we should definitely make sure we're doing what is best for the greater
ecosystem at all times. Having too much modularity will just encourage
differentiation at a level that slows overall adoption due to market
confusion.

To contrast with earlier parts of our industry, commodity PC's didn't
succeed because Compaq's PC's were different from IBM's. They succeeded
because they were nearly identical, but differentiated on price and
quality. Users had less confusion, more things "known" about the product,
and thus built more dependence on the platform. That sounds like exactly
what we want with OpenStack.