RDO tickets are now tracked in Jira https://issues.redhat.com/projects/RDO/issues/
Bug 1065826 - [RFE] [neutron] neutron services needs more RPM granularity
Summary: [RFE] [neutron] neutron services needs more RPM granularity
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: RDO
Classification: Community
Component: openstack-neutron
Version: Juno
Hardware: Unspecified
OS: Unspecified
low
unspecified
Target Milestone: ---
: ---
Assignee: Nir Magnezi
QA Contact: Ofer Blaut
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-17 04:33 UTC by Gilles Dubreuil
Modified: 2017-06-18 13:20 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-06-18 13:20:23 UTC
Embargoed:


Attachments (Terms of Use)

Description Gilles Dubreuil 2014-02-17 04:33:57 UTC
The way neutron is packaged there is no granularity to be able to install only certain services/plugins.

All nodes must have those same neutron packages, regardless of the service they must provide:
openstack-neutron
openstack-neutron-openvswitch

They provides all the binaries and corresponding RC scripts on all machines.
But that's 

- Controllers, which Neutron role is only to serve neutron api (neutron-server) gets all the agents and the ovs plugin even though it doesn't need them.

- Networker, gets the api where it doesn't need.

- All Computes nodes needs only the ovs plugin.

Of courses all the services not needed are (supposed to be) off (chkconfig).
I'm not sure how impacted the cluster would be if some of those services are started randomly, in most cases nothing would happened but there might harmful cases.

One thing for sure, it's not helping.

I believe that is not the intent of OpenStack and it just happened to be the way neutron got packaged for RDO/RHOS.

It would be better to have every Neutron Openstack component packaged on its own:
neutron-server (api)
neutron-agent-l3
neutron-agent-dhcp
neutron-agent-metadata
neutron-agent-openvswitch
neutron-<etc>

Regards,
Gilles

Comment 2 Miguel Angel Ajo 2014-02-17 07:22:27 UTC

Hi Gilles,

   By the way openstack-neutron it's designed, I believe we cannot handle that kind of granularity, It's only a single software project, with a lot of libraries and inter-dependencies. Which makes it almost impossible to break up things.

Comment 3 Gilles Dubreuil 2014-03-20 05:34:40 UTC
Hi Miguel,

Thanks for the follow-up.

Any chance that could changed over time?

I believe, that would prevent things like this one to happen:
https://bugzilla.redhat.com/show_bug.cgi?id=1006544

Comment 4 Nir Yechiel 2014-04-02 11:14:40 UTC
Giving the other items we currently have in Neutron this is considered to be low priority, hence I am closing this bug.

-Nir

Comment 5 Gilles Dubreuil 2014-05-14 02:22:23 UTC
This is not a bug but a RFE!

Reopening it because we need to have such repackaging done especially as neutron multi nodes capabilities are expanding.

Comment 6 Ihar Hrachyshka 2014-05-14 09:06:51 UTC
I've briefly discussed the matter with Miguel. Some points made:
- we don't need to split python-neutron package into parts to fulfil the request. The reporter's concern is not about disk space, but service list and configuration directory cluttering. It's about openstack-neutron package.
- such a change would require updating puppet modules
- such a change would require upgrade path (meaning, .spec file will be cluttered by 'Provides: ...' directives)
- we may still need to have a way to install all the services via a virtual package with the same name (openstack-neutron)
- such a change will require consultations with experienced packagers / the puppet masters to make sure we don't break anything
- it's not a change for Icehouse, maybe Juno

Comment 7 Ihar Hrachyshka 2015-03-19 14:30:40 UTC
That is really something to consider for Liberty.

Comment 8 Christopher Brown 2017-06-18 13:20:23 UTC
Because a tripleo image is standard across all nodes, there is no requirement for granularity as it would make things more complex. The design is that a single image is orchestrated dependent on operator requirements.

So this might have been a valid requirement in OSP 5-6 days but not from 7/Kilo onwards.

Closing as WONTFIX


Note You need to log in before you can comment on or make changes to this bug.