Talk:Heat/Providers

asalkeld 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? I just chose the RDS one as an example 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 I think 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: 1 what I implement 2 what my provider name is I implement OS::bla and my provider name is "RACKSPACE::bla" shardy which is about overriding the default cloud-provider resource It could just be the namespace is the user (or tenant) ID 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 I am also having misgivings with "OS:: :: ", I think this should probably be "OS:: :: " so OS::volume... I think that makes it easer to have different providers so you could have cinder/nova providers for volume (just thinking aloud) shardy kk, sounds reasonable Yeah, I guess exposing the codename of the project providing the resource is not really that useful unless, as you say, there is more than one, then you need to distinguish which one you want (possibly) 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