Open Stack

On Mon, Jan 5, 2015 at 8:09 AM, Sean Dague <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.


> 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?

dt

-- 

Dean Troyer
dtroyer at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150105/ecf328cf/attachment.html>