Open Stack

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.