Open Stack

Excerpts from Christopher Aedo's message of 2015-07-25 19:35:24 -0700:
> On Sat, Jul 25, 2015 at 1:00 PM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:
> > I'm not really sure how to start this conversation so I'll just start in.
> > Please bare with me for a bit.
> >
> > Something of a problem description:
> > With my Operator hat on, I've been quite interested in adopting TripleO. Due
> > to many reasons, its been hard for me to to explore as much as I'd like.
> > While time is one reason, another is its kind of monolithic. To try it out,
> > the best way so far has been to try and use it all.
> >
> > We've been interested in deploying some advanced services on our clouds to
> > add features for our users. Again, due to limited time limitations, I
> > haven't been able to explore as many of them as I would have liked.
> >
> > Some of the advanced services we've had a chance to play with, to varying
> > degrees are Sahara, Trove, Designate, and Barbican. We'd also like to play
> > with Manilla, Octavia, Murano, Mistral, Magnum, etc. The majority of these
> > services can be deployed in VM's (or Containers) running within the Cloud
> > and then provided through the Cloud.
> >
> > Proposal:
> > So that got me thinking. Could the TripleO deployment template set be broken
> > up in such a way that it could be used to augment an existing cloud
> > deployment instead of just deploying a fresh cloud? This would allow Clouds
> > to add advanced features such as Manilla before the Cloud distribution they
> > are running on supports it. Also, to make it easy for this enhancement to be
> > discoverable, they could be added to the application catalog:
> > http://apps.openstack.org. As the App Catalog UI gets integrated further
> > with Horzion, it would make it very easy for Operators to extend their
> > clouds with Advanced services. They would just do a quick search, hit
> > Launch, and fill out a simple form.
> >
> > Thoughts?
> 
> I think this is a really interesting idea, but I would be surprised to
> hear an approach like this is possible.  My understanding of TripleO
> is that the entire model is tightly coupled such that you must take an
> all or nothing approach (i.e. you can not use one deployment method
> for your cloud, and then use TripleO to deploy other components of
> your cloud later on).  I would be happy to hear my understanding is
> wrong in this case though.
> 

I can understand why it might have seemed that way because we were
driving at producing something production-like that ran in the gate,
but you actually heard wrong. The entire thing is intended to be modular
and one of the reasons to use OpenStack to deploy OpenStack is so that
you can easily move components into the cloud. Any tight coupling is an
accident and is likely only there because at this point there is only
one implementation receiving much attention (the puppet one).

> I think Kevin points out a very legitimate use case, but the only
> approach I've seen that is really nicely decoupled is the "Rally in a
> container" model [1].  The challenge all the deployment methods face
> is that they legitimately want to own the configuration and deployment
> from top to bottom of all components.  That's why mixing and matching
> Chef and Puppet for managing your deployment doesn't tend to work out
> (as many projects expect to share the message queue or DB).
> 

Mixing and matching chef and puppet on a single box doesn't work, because
they both make assumptions about what they own. But you can quite easily
have two services managed by two separate sets of tools.

> I would love to see some way for the App Catalog to allow OpenStack
> users or operators add additional services easily though, and I'm
> excited to see this floated here.  It's possible at least to do this
> with Rally via Murano[2] but that assumes the environment has included
> Murano and also has a Heat environment that includes everything needed
> by the resulting template.  As many have seen, it's not necessarily
> easy for users to know in advance whether this will work (another good
> thread, unfortunately with an unsatisfactory resolution).
> 
> Hopefully we'll see some great responses here on how we can solve some
> of this together!
> 

This is blowing my mind a little, because I've always been told that
Rally is a performance measuring tool. :-P I guess I should read up on
it because it sounds like it is also a packaging or deployment tool?

Anyway, It should be relatively easy to take the Heat provider templates
from TripleO and deploy them into a cloud in the same way you should
have no trouble deploying os-ansible-deployment into a cloud. Whatever
assumptions about real hardware are made will need to be addressed, but
ultimately 99% of what is called "advanced services" is just services
running regular binaries speaking regular protocols storing things on
regular filesystems.