[Yahoo-eng-team] [Bug 1829414] [NEW] Attribute filtering should be based on all objects instead of only first
Public bug reported: When returning a resource from neutron the resouce attribute are filtered based on the current policy and the attributes defined in the resource definition. Currently on the first object in a list of objects to be returned is checked, if it happens that there are other objects in the list that have additional attributes, those are not checked at all. I believe all attributes should be checked. Since this originally changed from checking all to only checking the first in a "efficiency of api" commit, I will propose a patchset that has minimal impact while still fixing the issue; please provide feedback here or on gerrit. ** Affects: neutron Importance: Undecided Assignee: Tom Stappaerts (tstappae) Status: New ** Changed in: neutron Assignee: (unassigned) => Tom Stappaerts (tstappae) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1829414 Title: Attribute filtering should be based on all objects instead of only first Status in neutron: New Bug description: When returning a resource from neutron the resouce attribute are filtered based on the current policy and the attributes defined in the resource definition. Currently on the first object in a list of objects to be returned is checked, if it happens that there are other objects in the list that have additional attributes, those are not checked at all. I believe all attributes should be checked. Since this originally changed from checking all to only checking the first in a "efficiency of api" commit, I will propose a patchset that has minimal impact while still fixing the issue; please provide feedback here or on gerrit. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1829414/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1848152] [NEW] Update mtu of network has no validation
Public bug reported: When creating a network the mtu value is checked against the type driver of the physical network by calling _get_network_mtu(self, network_db, validate=True) with validate=True. This check is not performed when doing a network update. ** Affects: neutron Importance: Undecided Assignee: Tom Stappaerts (tstappae) Status: New ** Changed in: neutron Assignee: (unassigned) => Tom Stappaerts (tstappae) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1848152 Title: Update mtu of network has no validation Status in neutron: New Bug description: When creating a network the mtu value is checked against the type driver of the physical network by calling _get_network_mtu(self, network_db, validate=True) with validate=True. This check is not performed when doing a network update. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1848152/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1751040] [NEW] [RFE] Extended resources should not always calculate all attributes
Public bug reported: Currently [1] resource extensions are asked to retrieve all attributes when calling resource_extend. This poses some problems: - Extensions need to gather all attributes for the resource they extend - ML2 mechanism drivers cannot make a difference between list and show of an object We propose to: A) Add a 'fields' argument to the extensions functions. This 'fields' argument is already present when creating the object dictionary, typically passed from ?fields=x parameters through the api. Passing it to resource extensions would prevent them from calculating attributes that will be discarded anyway. B) Let the clients when calling the API for list functions, use the 'fields' parameters to restrict the fields that are returned. We think this is a positive improvement as it: 1) Prevents unneeded data transfer between api and client. 2) Provides the ability for extensions that are interfacing with external components (like an SDN controller) to only process the requested attributes. The purpose of this RFE is to gather your comments before we start any devwork. Components that would need changing: - Neutron: resource_extend and all calling functions - Ml2: extension drivers (Both needing full backwards compatibility) - openstackclient & openstack sdk: list api calls need to include ?fields parameters - neutronclient: list api calls need to include ?fields parameters - neutron-tempest-plugin: new test cases [1]https://github.com/openstack/neutron/blob/master/neutron/db/_resource_extend.py ** Affects: neutron Importance: Undecided Assignee: Tom Stappaerts (tstappae) Status: New ** Changed in: neutron Assignee: (unassigned) => Tom Stappaerts (tstappae) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1751040 Title: [RFE] Extended resources should not always calculate all attributes Status in neutron: New Bug description: Currently [1] resource extensions are asked to retrieve all attributes when calling resource_extend. This poses some problems: - Extensions need to gather all attributes for the resource they extend - ML2 mechanism drivers cannot make a difference between list and show of an object We propose to: A) Add a 'fields' argument to the extensions functions. This 'fields' argument is already present when creating the object dictionary, typically passed from ?fields=x parameters through the api. Passing it to resource extensions would prevent them from calculating attributes that will be discarded anyway. B) Let the clients when calling the API for list functions, use the 'fields' parameters to restrict the fields that are returned. We think this is a positive improvement as it: 1) Prevents unneeded data transfer between api and client. 2) Provides the ability for extensions that are interfacing with external components (like an SDN controller) to only process the requested attributes. The purpose of this RFE is to gather your comments before we start any devwork. Components that would need changing: - Neutron: resource_extend and all calling functions - Ml2: extension drivers (Both needing full backwards compatibility) - openstackclient & openstack sdk: list api calls need to include ?fields parameters - neutronclient: list api calls need to include ?fields parameters - neutron-tempest-plugin: new test cases [1]https://github.com/openstack/neutron/blob/master/neutron/db/_resource_extend.py To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1751040/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1776187] [NEW] Workflow unregister raises unexpected exception when worklfow is not registered
Public bug reported:
This is seen as of Change-Id: I347d113f47587932e4f583d3152e781ad1a4849f
on master/Rocky:
When unregistering a workflow there used to be a catched exception
horizon/workflows/base.py:
try:
cls._cls_registry.remove(step_class)
except KeyError:
raise base.NotRegistered('%s is not registered' % cls)
return cls._unregister(step_class)
However since the change _cls_registry changed from a set to a list, making the
error a ValueError instead of a KeyError.
class WorkflowMetaclass(type):
def __new__(mcs, name, bases, attrs):
super(WorkflowMetaclass, mcs).__new__(mcs, name, bases, attrs)
attrs["_cls_registry"] = []
return type.__new__(mcs, name, bases, attrs)
** Affects: horizon
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1776187
Title:
Workflow unregister raises unexpected exception when worklfow is not
registered
Status in OpenStack Dashboard (Horizon):
New
Bug description:
This is seen as of Change-Id:
I347d113f47587932e4f583d3152e781ad1a4849f on master/Rocky:
When unregistering a workflow there used to be a catched exception
horizon/workflows/base.py:
try:
cls._cls_registry.remove(step_class)
except KeyError:
raise base.NotRegistered('%s is not registered' % cls)
return cls._unregister(step_class)
However since the change _cls_registry changed from a set to a list, making
the error a ValueError instead of a KeyError.
class WorkflowMetaclass(type):
def __new__(mcs, name, bases, attrs):
super(WorkflowMetaclass, mcs).__new__(mcs, name, bases, attrs)
attrs["_cls_registry"] = []
return type.__new__(mcs, name, bases, attrs)
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1776187/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1859163] [NEW] Create port with fixed ipv6 address for non-router ports is not allowed anymore
Public bug reported: As per merge in of https://review.opendev.org/#/c/699465/12/neutron/ipam/utils.py it is not allowed to create or update ports with fixed ips if the device_owner is not empty or a router device owner. This blocks us from creating ports with our own custom device owner, but also blocks for example the following example with a nova port: openstack network create net1 openstack subnet create --ip-version 6 --subnet-range cafe:babe::/64 --network net1 subnet1 openstack port create net1 --fixed-ip subnet=subnet1,ip-address=cafe:babe::5 port1 openstack server create --flavor 1 --image cirros --port port1 server1 openstack port set --fixed-ip subnet=subnet1,ip-address=cafe:babe::6 port1 ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1859163 Title: Create port with fixed ipv6 address for non-router ports is not allowed anymore Status in neutron: New Bug description: As per merge in of https://review.opendev.org/#/c/699465/12/neutron/ipam/utils.py it is not allowed to create or update ports with fixed ips if the device_owner is not empty or a router device owner. This blocks us from creating ports with our own custom device owner, but also blocks for example the following example with a nova port: openstack network create net1 openstack subnet create --ip-version 6 --subnet-range cafe:babe::/64 --network net1 subnet1 openstack port create net1 --fixed-ip subnet=subnet1,ip-address=cafe:babe::5 port1 openstack server create --flavor 1 --image cirros --port port1 server1 openstack port set --fixed-ip subnet=subnet1,ip-address=cafe:babe::6 port1 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1859163/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1861442] [NEW] QOS minimum bandwidth rejection of non-physnet network and updates should be driver specific
Public bug reported: When adding a qos policy to a network or port, there is the following check in the qos_plugin: # minimum-bandwidth rule is only supported (independently of # drivers) on networks whose first segment is backed by a physnet if rule.rule_type == qos_consts.RULE_TYPE_MINIMUM_BANDWIDTH: net = network_object.Network.get_object( context, id=port.network_id) physnet = net.segments[0].physical_network if physnet is None: raise qos_exc.QosRuleNotSupported(rule_type=rule.rule_type, port_id=port['id']) To my knowledge this statement is simply untrue as it is precisly the reference drivers which have this problem, not necessarily all drivers. This blocks me from creating a qos_driver that does support mimimum bandwidth without a physnet. The same goes for min_bw_rule_updates when the port is bound. I propose we move those checks to the qos_drivers themselves. ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1861442 Title: QOS minimum bandwidth rejection of non-physnet network and updates should be driver specific Status in neutron: New Bug description: When adding a qos policy to a network or port, there is the following check in the qos_plugin: # minimum-bandwidth rule is only supported (independently of # drivers) on networks whose first segment is backed by a physnet if rule.rule_type == qos_consts.RULE_TYPE_MINIMUM_BANDWIDTH: net = network_object.Network.get_object( context, id=port.network_id) physnet = net.segments[0].physical_network if physnet is None: raise qos_exc.QosRuleNotSupported(rule_type=rule.rule_type, port_id=port['id']) To my knowledge this statement is simply untrue as it is precisly the reference drivers which have this problem, not necessarily all drivers. This blocks me from creating a qos_driver that does support mimimum bandwidth without a physnet. The same goes for min_bw_rule_updates when the port is bound. I propose we move those checks to the qos_drivers themselves. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1861442/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1718385] [NEW] neutron-lib validate_subports incorrectly blocks segmentation_id 0
Public bug reported:
When supplying a subport for a trunk with segmenation_id 0 Neutron
reports:
Invalid subport details '{u'segmentation_type': u'vlan', u'port_id':
u'449451c4-f134-4fbc-b405-df9109746e51', u'segmentation_id': 0}':
missing segmentation information. Must specify both segmentation_id and
segmentation_type from (pid=16359) validate_subports
/Ocata/local/lib/python2.7/site-
packages/neutron_lib/api/validators.py:923
This is due to the following lines:
segmentation_id = subport.get("segmentation_id")
segmentation_type = subport.get("segmentation_type")
if (not segmentation_id or not segmentation_type) and len(subport) > 1:
Can we allow segmentation_id 0 to pass or provide a more suitable error
message?
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1718385
Title:
neutron-lib validate_subports incorrectly blocks segmentation_id 0
Status in neutron:
New
Bug description:
When supplying a subport for a trunk with segmenation_id 0 Neutron
reports:
Invalid subport details '{u'segmentation_type': u'vlan', u'port_id':
u'449451c4-f134-4fbc-b405-df9109746e51', u'segmentation_id': 0}':
missing segmentation information. Must specify both segmentation_id
and segmentation_type from (pid=16359) validate_subports
/Ocata/local/lib/python2.7/site-
packages/neutron_lib/api/validators.py:923
This is due to the following lines:
segmentation_id = subport.get("segmentation_id")
segmentation_type = subport.get("segmentation_type")
if (not segmentation_id or not segmentation_type) and len(subport) >
1:
Can we allow segmentation_id 0 to pass or provide a more suitable
error message?
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1718385/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
