Open Stack

On Sat, Jul 25, 2015 at 4: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.

Yes, I think it would be possible. It would take a little work to get
there though, as I don't expect it to work today without someone
diving into the templates and starting to try it out, and fixing
mistakes and possibly some bad assumptions that were made, etc.

What you're proposing though I think is very compelling. Ideally, you
could take just the compute template from tripleo-heat-templates and
use Heat to deploy a ResourceGroup of compute nodes. Since the
implementation in the templates is so heavily reliant on provider
templates and nested stacks, I think it could work without large
architectural changes.

You'd have to manually pass in via parameters to the compute template
what would usually be passed in by the parent template in a full
TripleO deployment. For instance, the compute-puppet.yaml template
takes a KeystoneHost parameter. When deploying a cloud with TripleO,
that IP address is known to Heat since it asked Nova to launch the
instance running Keystone, so it passes in that IP address as the
value for KeystoneHost. Without Heat orchestrating the parent template
as well, you'd have to pass this parameter in manually. Not a huge
deal, but it would be a fair amount of manual work that is usually
handled by the Heat orchestration automatically.

Assuming the cloud had Ironic, you could even use this method to scale
out an existing cloud not deployed with TripleO onto more baremetal
machines, not just things that can run in VM's. Effectively, it's Heat
scaling out the same cloud Heat is running on. We've had similar
thoughts before about doing such a thing to scale out a TripleO
undercloud so that the seed vm is no longer needed.

I think we've developed (and continue to do so) some good patterns in
tripleo-heat-templates to not make things so tightly coupled. The
puppet implementation proved that out and helped drive a lot of that.
We've been able to build on that, and do things like deploy a puppet
based controller, and a docker based compute node by just swapping out
the compute template. So, I think we're continuing to move towards
having less coupling, and that's a good thing.

There is also some preliminary work going on into looking at using
Heat to configure already running instances that are not known to
Nova. Since most (all?) of the configuration of instances is driven
via SoftwareDeployments, it serves to reason that if you created a
Heat stack that was a bunch of SoftwareDeployments (as TripleO does),
and then configured os-collect-config on an already installed system
that you could then run os-collect-config and apply those
SoftwareDeployments. This requires mapping the OS::Nova::Server
resource to a custom resource that you then map to a nested stack that
doesn't actually launch an instance. This would allow someone to make
use of all the work that has gone into the templates about how to
install and configure OpenStack, but use less of OpenStack itself to
take advantage of it.

-- 
-- James Slagle
--