Open Stack

----- Original Message -----
> From: "Robert Collins" <robertc at robertcollins.net>
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Cc: openstack-operators at lists.openstack.org
> Sent: Friday, February 14, 2014 11:12:12 PM
> Subject: Re: [Openstack-operators] [openstack-dev] [TripleO] consistency vs	packages in TripleO
> 
> On 15 February 2014 08:42, Dan Prince <dprince at redhat.com> wrote:
> >
> 
> > Let me restate the options the way I see it:
> >
> > Option A is we do our job... by making it possible to install OpenStack
> > using various distributions using a set of distro agnostic tools
> > (TripleO).
> 
> So our job is to be the upstream installer. If upstream said 'we only
> support RHEL and Ubuntu, our job would arguably end there. And in
> fact, we're being much more inclusive than many other parts of
> upstream - Suse isn't supported upstream, nor is Ubuntu non-LTS, nor
> Fedora.
> 
> > 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?


Your initial email didn't use the word default at all. You said "we coerce the package into reference upstream shape as part of installing it". That sounds like strong arming to me... and is what I'm concerned with.

> 
> 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.
> 
> > Does option B look appealing? Perhaps at first glance. By taking away the
> > differences it seems like we are making everyone's lives easier by
> > "streamlining" our depoyment codebase. There is this one rub though: it
> > isn't what users expect.
> 
> I don't know what users expect: There's an assumption stated in some
> of the reponses that people which choose 'TripleO + Packages' do that
> for a reason. I think this is likely going to be wrong much of the
> time. Why? Because upstream doesn't offer someone to ring when there
> is a problem. So people will grab RDO, or Suse's offering, or
> Rackspace Private Cloud, or HP Cloud OS, or
> $distribution-of-openstack-of-choice : and I don't expect for most
> people that 'and we used a nova deb package' vs 'and we used a nova
> pip package' is going to be *why* they choose that vendor, so as a
> result many people will get TripleO+Packages because their vendor
> chose that for them. That places a responsibility on the vendors and
> on us. The vendors need to understand the consequences of their
> packages varying trivially from upstream - the
> every-unix-is-a-little-different death of a thousand cuts problem -
> and we need to help vendors understand the drivers that lead them to
> need to build images via packages.
> 
> > 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.

I would argue that we haven't tried all of the read only root mechanism either... at least to the point where we can definitely don't work. Sure the data has to go somewhere... but it is how we present this to the end user that is the point in this thread, no?

All I'm arguing for here is the ability to avoid doing this to our nova.conf file (what we do today in TripleO):

 state_path=/mnt/state/var/lib/nova

And instead simply use the Nova default (/var/lib/nova) and have some other mechanism take care of the mapping for us (bind mounts, etc). In the context of end user documentation I certainly think this has less of an impact and is more pleasing to all.

> 
> > 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 for the reference implementation part of A I do hope we choose it wisely
> > and that as much as possible the distros take note of our choices.
> 
> +1
> 
> -Rob
> 
> 
> --
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
> 
> _______________________________________________
> OpenStack-operators mailing list
> OpenStack-operators at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>