openstack team mailing list archive

[Kiall Mac Innes <kiall@xxxxxxxxxxxx>]

Inline..

Thanks,
Kiall


On Mon, Apr 2, 2012 at 11:42 AM, Deepak Garg <deepakgarg.iitg@xxxxxxxxx>wrote:

> > The only disadvantage of having it in python-keystone over
> > a python-keystone-middleware package is a few extra .py files on disk..
> > Personally, I don't see that as an issue..
> [Deepak] A few extra files but you are installing keystone client
> unnecessarily


Humm - you're right about about. python-keystone depends on
python-keystoneclient for some reason.

I wonder if that is a packaging bug, or if there is a legitimate reason for
the depends.


>  >> It might be better to include it in a new python-keystone-middleware
> >> package, but not python-openstack-common..
> >> python-openstack-common is this
> >> code: https://github.com/openstack/openstack-common. These are
> libraries
> >> that are service independent, eg config libs,
> [Deepak] Isn't it service independent ? All the services are using it,
> so they might as well borrow it from openstack-common
>

It's optionally used by many services, but is a piece of the keystone
project.. It should IMO belong in a keystone named package.. But, you are
right, its could go in openstack-common from a install perspective, but
from a development+packaging perspective, allowing for this would be more
hassle that it's worth.


> The reason I have suggested to include it in openstack-common because
> I think it is installed in all the nodes as all the services are
> dependent on openstack-common. I am not sure if we will run into
> maintenance issues.


I'm not sure what extra maintenance issues there may be over the already
installed set of python-{nova,glance,swift} packages?

Being overly simplistic, `apt-get` should be all you need to maintain the
package. Additionally, Once keystone becomes the only auth system for
OpenStack, I would assume the packages will have the middleware listed as a
hard dependency to make even easier..

Thanks,
Kiall