Open Stack

On 01/05/2015 01:45 PM, Dean Troyer wrote:
> On Mon, Jan 5, 2015 at 8:09 AM, Sean Dague <sean at dague.net
> <mailto:sean at dague.net>> wrote:
> 
>     1) install_plugins - currently is a one way process
> 
>     Dean correctly points out that install_plugins is currently a one way
>     process. I actually wonder if we should change that fact and run a 'git
>     clean -f extras.d' before the install plugins under the principle of
>     least surprise. This would make removing the enable_plugin actually
>     remove it from the environment.
> 
> 
> Or we just don't copy things around and the problem doesn't even
> appear.  If the configuration of the plugin includes the path to the
> dispatch script (what is currently in extras.d) and we run it in place,
> removing it doesn't have any surprises if the first place.

The reason I avoided that was because of possible pathing issues,
especially as we source the files instead of running them in their own
address space (which means they don't have to have all the includes
locally). I'm somewhat concerned that any cd logic is going to leave us
in odd places (which I guess we could fix with a reset at the top level).

Maybe if we symlinked instead?

>  
> 
>     2) is_service_enabled for things that aren't OpenStack services?
> 
>     Overloading ENABLED_SERVICES with things that aren't OpenStack services
>     is something I'd actually like to avoid. Because other parts of our tool
>     chain, like grenade, need some understanding of what's an openstack
>     service and what is not.
> 
>     Maybe for things like ceph, glusterfs, opendaylight we need some other
>     array of "features" or something. Honestly I'd really like to get mysql
>     and rabbitmq out of the service list as well. It confusing things quite
>     a bit at times.
> 
> 
> We do need to separate system services from OpenStack services, and this
> might be a good time to find another word to use here for one of them:
> 'system service' vs 'openstack service'.
> 
> One of the things multi-node adds is the distinction between the cluster
> using a service and a specific node needing it configured or started.
> 
> Does this need to be solved before the plugin work can be completed?

Probably not. But I was trying to avoid further overloading the
is_service_enabled on these plugins by just running them if they exist.

	-Sean

-- 
Sean Dague
http://dague.net