Open Stack

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 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).

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!

[1]: https://registry.hub.docker.com/u/rallyforge/rally/
[2]: http://apps.openstack.org/#tab=murano-apps&asset=Rally

-Christopher