Heat/on-public-clouds

This wiki page is to plan the changes we need to support running Heat againt public clouds like HPCloud and Rackspace Cloud.

If you are interested in helping make this happen put your name below to help organize efforts.

Public Cloud Restrictions

Please update if these are incorrect.

Rackspace and HPCloud

• No self service VM image uploads. Must use either provided VM images or boot snapshots.
• Keystone is slightly special in each case. Rackspace has different auth and HPCloud returns extra data.

Rackspace

• No cloud-init in the base images and no running metadata server.

Features that may help

• Ability to boot snapshots.
• Keystone middleware for Rackspace and HPCloud.

Proposal to keep Public OpenStack cloud resources in-tree

I think we need to agree that we are going to keep any public cloud specific resource types in-tree. So not every public cloud on the planet, but rather where there are developers that are actively participating in the Heat commutity. I am thinking of Rackspace and HP (and maybe Dreamhost if they contiribute).

1. there must be a directory engine/resource/<cloud>/ with the resource types
2. there must be a README with the maintainer's details (who to blame) - if no one is contactable we could remove the resources.

Irc discussion:

<sdake> asalkeld: I'd think if its not openstack specific, it probably wouldn't go in tree since we would have no way to validate it 
<asalkeld> sdake, yea in tree
<sdake> how would it be tested?
<asalkeld> sdake, more important to have them in, rackers should test  and maintain. But i think they would be widely useful
so shooting ourselves in the foot not having them  in tree
<wirehead_> Yeah, there are a *lot* of folks who are going to be super-keen on running their own Heat against public cloud infrastructure
The more I've been giving my "Hey, here's why Heat is awesome" talk to people, the more I can tell
<asalkeld> yip
<sdake> just general concerns with bunch of in-tree plugins for custom cloud providers
<wirehead_> Well, it's still bad form to have a vendor-specific in-tree plugin that goes stale
<sdake> wirehead_ this has happened alot with nova (stale plugin)
<asalkeld> and easier to maintain the resource api
<stevebaker> I think we should do what the kernel does, encourage plugins to be in-tree by:
 1. not guaranteeing a stable internal api
 2. committing to updating in-tree plugins whenever internal api does change
<asalkeld> encourages an active communtiy  and contirbutions, so stevebaker +1
<sdake> should probably be discussed on team meeting now we have basics out
just see a future where there are 20 server plugins, 20 storage plugins, 20 different type of quantum plugins etc
becomes especially intrusive if we change around the dsl
(since that changes the api)
<asalkeld> yea, but that is worse if out of tree
<stevebaker> I'm all for that fwiw. think of the 100s of esoteric hardware drivers in the kernel
<sdake> kernel has a way to turn on and off device drivers
<asalkeld> at least people know where the source code is
<sdake> for when kernel vendors sluggish to update their drivers
<asalkeld> sdake, sounds like a new feature
<stevebaker> we will too with providers and environments
<sdake> ya could be :)
<stevebaker> maybe one day we could have a separate repo with all the plugins, and give it a separate release schedule
<asalkeld> err, same release sched
 api ...
I vote for all in tree
<sdake> I don't have a strong preference just acting as voice of reason :)
<asalkeld> with a README in each dir rackspace/README (with who is the maintainer)
i.e. when it breaks who to complain to
<wirehead_> Yeah, I think the sad truth is that no matter how we try to make it easier, it's still going to be a bit troublesome
<asalkeld> best solution is to have the same api as upstream
<asalkeld> then we can use the same resource
<wirehead_> Yes.  I think the market forces will eventually mostly make that the case
<asalkeld> so hopefully this is a short term thing