On Sat, Jul 25, 2015 at 1:00 PM, Fox, Kevin M <kevin....@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev