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::<project>::<resource>" , I think this should probably be "OS::<endpoint>::<resource>"
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