On 02/26/2014 06:47 AM, Charles Walker wrote:

Hi,


I am trying to deploy the proprietary application made in my company on the cloud. The pre requisite for this is to have a IAAS which can be either a public cloud or private cloud (openstack is an option for a private IAAS).


The first prototype I made was based on a homemade python orchestrator and apache libCloud to interact with IAAS (AWS and Rackspace and GCE).

The orchestrator part is a python code reading a template file which contains the info needed to deploy my application. This template file indicates the number of VM and the scripts associated to each VM type to install it.


Now I was trying to have a look on existing open source tool to do the orchestration part. I find JUJU (https://juju.ubuntu.com/) or HEAT (https://wiki.openstack.org/wiki/Heat).

I am investigating deeper HEAT and also had a look on https://wiki.openstack.org/wiki/Heat/DSL which mentioned:


You will notice at the top of this page, it is clearly labeled "Proposal Only". Just a tip, but I'd recommend taking anything on the wiki with a grain of salt (vs what is actually put on docs.openstack.org, which is a more accurate world view).

The Heat developers have coalesced around a de-facto standard DSL called HOT instead:

http://docs.openstack.org/developer/heat/template_guide/hot_spec.html

*"Cloud Service Provider* - A service entity offering hosted cloud services on OpenStack or another cloud technology. Also known as a Vendor."


I think HEAT as its actual version will not match my requirement but I have the feeling that it is going to evolve and could cover my needs.


I would like to know if it would be possible to use HEAT as a standalone component in the future (without Nova and other Ostack modules)? The goal would be to deploy an application from a template file on multiple cloud service (like AWS, GCE).


First, Heat has a hard dependency on keystone. Second, it wouldn't be very useful in this configuration. Heat provides built-in resources for managing things like servers, floating ips, and other types of resources. These resource plugins expect to communicate with openstack nova, neutron, etc. If you were really motivated, you could write bespoke plugins for all of the AWS/GCE services to run a hybrid cloud using Heat. If you were even more motivated, you could get these merged upstream. But hybrid cloud is not in scope for the Orchestration program. We don't stop people from trying to use Heat in this way, but we don't directly enable it in the resources either.

In the future, I'd recommend asking general questions like this on ask.openstack.org so the entire community can share and record the experience, rather then being lost on a mailing list.

Thanks!
-steve

Any feedback from people working on HEAT could help me.


Thanks, Charles.



_______________________________________________
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

Reply via email to