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 <sd...@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. _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
