Difference between revisions of "Talk:Heat/Providers"

Revision as of 08:59, 23 May 2013

<asalkeld> shardy, I don't think we should limit the providers to nested templates to me is should be any resource as some might be provided even by us (native openstack/hp/rack) but user providers could be only nested stacks the other issue we are going to come up against is what format to go with I'd suggest not supporting multiple AWS style resources only native openstack style resources else we are encouraging the wrong thing the other thing is we probably want provider to be of the form "cloud::resource_type" so a user can just say I want to use all "Dreamhost" resources and not have to specify all resource types they want over the defaults <shardy> asalkeld: So yes, any resource, but expressed as a template right? <shardy> I just chose the RDS one as an example <-- wajiii-afk has quit (Ping timeout: 248 seconds) <shardy> I don't really see why we should mandate a particular template language, considering we'll have to support more than one internally anyway but I guess maybe it makes sense to start with one (ie what we have) <asalkeld> so I think we also support multiple internal instances we an issue is the properties and the naming <shardy> asalkeld: so allow multiple resource plugins for the same type? <asalkeld> yea, that's the whole point user provided ones are nested stacks <shardy> asalkeld: I mean multiple python plugins, not just via the providers API <asalkeld> yea python plugins too <shardy> how do we tell which one is the default for the python plugins? <asalkeld> (pretty please) it has a name OS:: DREAMHOST::/RACKSPACE:: HP etc... default to upstream openstack <shardy> asalkeld: ah, well we already support that right, it's not multiple resource of the exact same type, because the namespaces are different <shardy> to me that is a separate thing from the providers API <asalkeld> well there are 2 things: <shardy> which is about overriding the default cloud-provider resource <asalkeld> 1 what I implement 2 what my provider name is <shardy> It could just be the namespace is the user (or tenant) ID <asalkeld> I implement OS::bla and my provider name is "RACKSPACE::bla" <shardy> and we provide an intrinsic to get that data, so you have providers-API created stuff being {"Fn::OS::User"}::Nova::Instance or something <asalkeld> for user stuff defined stuff --> trapni (~trapni@gentoo/developer/trapni) has joined #heat <asalkeld> I am also having misgivings with "OS::<project>::<resource>" , I think this should probably be "OS::<endpoint>::<resource>" <shardy> asalkeld: well please do hack on that wiki page, I was just trying to get a starting point, as many people (including us by the sounds of it) are a bit confused about how this will work <asalkeld> so OS::volume... <shardy> kk, sounds reasonable <asalkeld> I think that makes it easer to have different providers so you could have cinder/nova providers for volume <shardy> Yeah, I guess exposing the codename of the project providing the resource is not really that useful <asalkeld> (just thinking aloud) <shardy> unless, as you say, there is more than one, then you need to distinguish which one you want (possibly) <asalkeld> yea <shardy> or you manage that outside the template via priorities/defaults e.g bit like the examle I put in the wiki of imaginary cli workflow example <asalkeld> yea but you don't want "OS::cinder" in the template and find you are getting something else doesn't really make sense