Difference between revisions of "Talk:Heat/Providers"
| Line 1: | Line 1: | ||
| − | + | '''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 | |
| − | as some might be provided even by us | ||
| − | |||
| − | |||
the other issue we are going to come up against is what format to go with | 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 | I'd suggest not supporting multiple AWS style resources | ||
| Line 12: | Line 9: | ||
so a user can just say I want to use all "Dreamhost" resources | 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 | 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) | 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 | we an issue is the properties | ||
and the naming | 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 | 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''' | |
| − | default to upstream openstack | + | 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 | 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 | |
| − | {"Fn::OS::User"}::Nova::Instance | + | 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 | 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 | + | 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 | doesn't really make sense | ||
| − | |||
Latest revision as of 09:13, 23 May 2013
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
