Open Stack

Excerpts from Prasad Vellanki's message of 2014-01-13 23:23:15 -0800:
> On Thu, Jan 9, 2014 at 6:14 AM, Steven Dake <sdake at redhat.com> wrote:
> 
> > that
> 
> 
> Steve
> Thanks for detailed email. Apologize for the delayed response but we have
> been thinking about how does software config fit into configuring network
> and service function devices. I agree with you that in general it is best
> to get appliance vendors to put cloudinit into their images and thus get on
> board with what every cloud is doing. I thought I would get some feedback
> on the direction of Heat for configuring network devices and appliances.
> 
> I am thinking there are few things to consider for configuring Network and
> Network Service devices/Virtual Appliances.
> 
> Neutron APIs along with the service APIs provide a way to configure network
> devices by abstracting the APIs and have a plugin model for individual
> devices. These APIs include Neutron core apis, Service API such as LBaaS,
> FWaaS, VPNaaS. Though these are currently for physical devices, there is a
> movement towards configuring Virtual Appliances too. These APIs will be
> addressed via Heat Neutron resources.
> 
> While *aaS do address configuring the supported service, they do not
> address the bootstrapping of the device. Generally for most devices
> bootstrapping is done via rest API and/or SSH. And for unsupported
>  services that do not have these APIs one needs to use custom way to
> configure where Heat can really help.  Bootstrapping includes installing
> licences, configuring admin password, upgrade software  and some with more
> than that. For this our thought is it would be great to have  Heat software
> config/deployment do bootstrapping, upgrade etc.
> 

I think what you need is a very small service VM that does this
bootstrapping. We don't want the heat engine reaching into VMs directly.
So what you would want to do is have a service VM which SSH's in, or hits
those REST API's. Now, if one of those REST API's is stable enough that
your cloud provider _does_ want to be able to hit it, they can write a
resource plugin and provide that.

I think it might be cool to have a Heat resource which is just a server
that is deleted as soon as it signals a wait condition. That would enable
these sort of "external bootstrap" things quite nicely without costing
users or requiring them to remove the server definition after creating
the stack.