On 09/07/14 17:10, Angus Salkeld wrote:
If we could make them separate Python packages within a single Git repo,
>I would be +2 on that. I don't know if that's feasible with our current
>tooling (though I guess it's not dissimilar to what you're doing with
>the contrib stuff in this patch series?).
>
Another option is we could move away from "contrib" and have:
heat/resources/<builtin>/<all native resources here>
heat/resources/optional/{aws,contrib}
The ones under "optional" have their own setup.cfg and need to be packaged
(by the distro) separately.
I'm not familiar enough with Python packaging to know if that works, but
I'm fine with it if it does ;) Given the choice I'd probably marginally
prefer to move the plugins to a separate tree (i.e. keep them in the
same repo but not have them under heat/) though.
>>We can default to "resources are loaded but not enabled by default"
>>the each distro package can drop a file into/etc/environment.d/ that
>>enables it's resources.
>
>Sounds like a recipe for distro bugs.
>
What I was getting at was, we should separate the mechanism for loading the
plugins and what is "enabled/visible" to the user. And that logic should
really live in the resource registry in the environment.
+1
>>>One of the main design goals of the current resource plugins was to move
>>>the mapping from resource names to classes away from one central point
>>>(where all of the modules were imported) and place the configuration
>>>alongside the code it applies to. I am definitely not looking forward to
>>>having to go look up a config file to find out what each resource is
>>>every time I open the autoscaling module (and I do need to remind myself
>>>_every_ time I open it), to say nothing of the constant merge conflicts
>>>that we used to have to deal with when there was a central registry.
>>
>>They are grouped by name, so you will only run into an issue when someone
>>else is working on the same area as you.
>>
>>>
>>>A central registry is also problematic for operators that modify it, who
>>>will have a difficult, manual and potentially error-prone merge task to
>>>perform on the config file every time they upgrade.
>>
>>I don't see why an operator will be editing this, they should be using
>>the environment to disable plugins/rename things. You don't have to
>>touch this if you are adding your own plugin.
>>
>>>
>>>Constraints, I feel, are very similar to resources in this respect. I am
>>>less concerned about template formats, since there are so few of them...
>>>although it would be really nice to be able to install these as
>>>subpackages too, and using stevedore appears to eliminate that as an
>>>option :(
Do we want to move constraints to Hooks as well? Guessing yes, to make
it consistent.
I'm not too familiar with the constraints stuff, but I think yes - I
doubt we want to be listing all of these in setup.cfg either. We can
probably have one hook plugin for each client plugin to cover the
built-in stuff, while still allowing out-of-tree plugins to join at the
same hook point.
cheers,
Zane.
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
