<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 01/14/2014 12:23 AM, Prasad Vellanki
wrote:<br>
</div>
<blockquote
cite="mid:CADstcNZjXjGgaYG1=wa=N6cW_XVs3SWEAOjsT+Q92=4Dshb8UQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, Jan 9, 2014 at 6:14 AM,
Steven Dake <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:sdake@redhat.com" target="_blank">sdake@redhat.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">that</blockquote>
</div>
<br>
Steve
<div>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. </div>
<div><br>
</div>
<div>I am thinking there are few things to consider for
configuring Network and Network Service devices/Virtual
Appliances. </div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div> 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 <span
style="font-family:arial,sans-serif;font-size:13px">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.</span></div>
<div> </div>
</div>
</div>
</blockquote>
Prasad,<br>
<br>
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:<br>
<br>
1) Implement a ReST server which the vendor's image talks to ReST
server to obtain bootstrapping information<br>
2) SSH into the machine from an external configuration server
process<br>
<br>
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 :)<br>
<br>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
When we take on new work with OpenStack, we want everyone to have
the potential to be winners.<br>
<br>
Regards<br>
-steve<br>
<br>
<blockquote
cite="mid:CADstcNZjXjGgaYG1=wa=N6cW_XVs3SWEAOjsT+Q92=4Dshb8UQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div>BTW puppet seems to use similar proxy way to network
device configuration. See link below</div>
<div><a moz-do-not-send="true"
href="https://puppetlabs.com/blog/managing-f5-big-ip-network-devices-with-puppet">https://puppetlabs.com/blog/managing-f5-big-ip-network-devices-with-puppet</a><br>
</div>
<div><br>
</div>
<div>thanks</div>
<div>prasadv</div>
<div><br>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
</body>
</html>