Open Stack

On 01/14/2014 12:23 AM, Prasad Vellanki wrote:
>
> On Thu, Jan 9, 2014 at 6:14 AM, Steven Dake <sdake at redhat.com 
> <mailto: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.
>
>  While I agree long term is to have vendors to implement cloudinit 
> framework, we were wondering if there is an intermediate solution that 
> will allow configuration without requiring agent and cloudinit, If 
> there is enough critical mass behind such a requirement we can have 
> further discussions on the design and implementation options.
Prasad,

The crux of the problem is how do you obtain critical mass for custom 
one-off solutions?  Lets assume two possible solutions to this problem 
that these vendors could take.  If there are more, please feel free to 
explain them:

1) Implement a ReST server which the vendor's image talks to ReST server 
to obtain bootstrapping information
2) SSH into the machine from an external configuration server process

In both of these cases, these would be one-off solutions for each 
particular vendor.  Now assume you take this to the natural conclusion 
of hundreds of application images - you end up with hundreds of these 
daemons to handle all the various application images.  What is worse, 
they would have to documented, HA-ified, scale-ified, secure-ified, and 
deployed.  I am doubtful the SSH model would work fitting your 
constraints (not modifying the image) since some type of SSH key 
injection would need to be done.  I further doubt service providers are 
really going to want to deal with an extra server in their environment 
that is not specifically required for OpenStack unless the value offered 
by the cloud application is tremendous.  There are enough daemons 
already to deal with :)

I get that a whole bunch of different cloud application vendor 
bootstrapping tools could be merged into "one" daemon and then this one 
master daemon could be documented, HA-ified, scale-ified, secureified, 
and deployed.  Perhaps there is some sort of financial incentive to make 
that happen and maybe someone can make a business out of it but my 
personal feeling is it is the wrong approach.  If this is the approach 
your proposing, it does not fit in with the mission of Heat program 
specifically, and TBH I'm not certain your goals fit with an existing 
program to "solve" this particular problem.

Frankly, I don't believe there is a intermediate step application 
vendors can take here.  If they want their images to run in cloud 
environments because they are cloud workload applications, they need to 
commit to cloudinit.  Cloud application vendors need to balance the 
position of "We don't want cloudinit because we want our own custom 
bootstrapping" with "The entire cloud community has made a decision to 
handle bootstrapping with cloudinit".  On balance, the cloud application 
vendors should follow the lead of the cloud community in general.  The 
cloud community has chosen cloudinit for a reason - it wasn't some 
random act.

Any other option IMNSHO harms the application vendor's SAM, the 
OpenStack ecosystem, the architectural clarity of OpenStack and is 
detrimental to other cloud environments as well.

In this thread I have seen no rationale for *why* cloudinit can't be 
added to cloud vendor's images by the cloud vendor.  We just added 
heat-cfntools to the RHEL6.5 cloud image, and it cost money to make that 
happen, but investment in core engineering is a normal activity of any 
technology business.  Are there other rationale beyond the investment 
expense?

There really is no winner to a custom bootstrapping system, other then 
the team who make the custom bootstrapping system and sell/support it 
;)  Even the application vendor loses because their SAM is reduced to 
the number of customers who purchase this special-purpose bootstrapping 
service.

When we take on new work with OpenStack, we want everyone to have the 
potential to be winners.

Regards
-steve

> BTW puppet seems to use similar proxy way to network device 
> configuration. See link below
> https://puppetlabs.com/blog/managing-f5-big-ip-network-devices-with-puppet
>
> thanks
> prasadv
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140114/2b3a8da1/attachment.html>