Bug 1065826

Summary:	[RFE] [neutron] neutron services needs more RPM granularity
Product:	[Community] RDO	Reporter:	Gilles Dubreuil <gdubreui>
Component:	openstack-neutron	Assignee:	Nir Magnezi <nmagnezi>
Status:	CLOSED WONTFIX	QA Contact:	Ofer Blaut <oblaut>
Severity:	unspecified	Docs Contact:
Priority:	low
Version:	Juno	CC:	chris.brown, chrisw, ihrachys, majopela, markmc, nyechiel, srevivo, twilson
Target Milestone:	---	Keywords:	FutureFeature, Reopened
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-06-18 13:20:23 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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