[openstack-dev] [heat] Sofware Config progress

Clint Byrum clint at fewbar.com
Tue Jan 14 17:59:36 UTC 2014


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.



More information about the OpenStack-dev mailing list