On 01/14/2014 12:23 AM, Prasad Vellanki wrote:
On Thu, Jan 9, 2014 at 6:14 AM, Steven Dake <sd...@redhat.com
<mailto: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.
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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
