[Yahoo-eng-team] [Bug 1253497] Re: Replace uuidutils.generate_uuid() with str(uuid.uuid4())
** Also affects: karbor Importance: Undecided Status: New ** Changed in: karbor Assignee: (unassigned) => Spencer Yu (yushb) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1253497 Title: Replace uuidutils.generate_uuid() with str(uuid.uuid4()) Status in Barbican: Fix Released Status in BillingStack: Invalid Status in Blazar: Fix Committed Status in Cinder: Invalid Status in Designate: Fix Released Status in Glance: Fix Released Status in heat: Fix Released Status in OpenStack Dashboard (Horizon): Invalid Status in Ironic: Fix Released Status in Karbor: New Status in Manila: Fix Released Status in Murano: Fix Released Status in neutron: Invalid Status in OpenStack Compute (nova): Invalid Status in oslo-incubator: Fix Released Status in Sahara: Fix Released Status in staccato: Invalid Status in taskflow: Invalid Status in OpenStack DBaaS (Trove): Fix Released Status in tuskar: Fix Released Bug description: http://lists.openstack.org/pipermail/openstack- dev/2013-November/018980.html > Hi all, > > We had a discussion of the modules that are incubated in Oslo. > > https://etherpad.openstack.org/p/icehouse-oslo-status > > One of the conclusions we came to was to deprecate/remove uuidutils in > this cycle. > > The first step into this change should be to remove generate_uuid() from > uuidutils. > > The reason is that 1) generating the UUID string seems trivial enough to > not need a function and 2) string representation of uuid4 is not what we > want in all projects. > > To address this, a patch is now on gerrit. > https://review.openstack.org/#/c/56152/ > > Each project should directly use the standard uuid module or implement its > own helper function to generate uuids if this patch gets in. > > Any thoughts on this change? Thanks. > Unfortunately it looks like that change went through before I caught up on email. Shouldn't we have removed its use in the downstream projects (at least integrated projects) before removing it from Oslo? Doug To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1253497/+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 1703511] [NEW] Attach/detach volume should not showed in instance actions when cinder disabled
Public bug reported: At Instances index view, Attach volume/ Detach volume are showed on drop list of an instance even cinder not enabled. ** Affects: horizon Importance: Undecided Assignee: Min Sun (minsu) 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/1703511 Title: Attach/detach volume should not showed in instance actions when cinder disabled Status in OpenStack Dashboard (Horizon): New Bug description: At Instances index view, Attach volume/ Detach volume are showed on drop list of an instance even cinder not enabled. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1703511/+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 1703510] [NEW] ML2-Linuxbridge not keep routes on physical interface
Public bug reported: When using ML2-Linuxbridge flat network, the bridge is dynamically created when the first VM using the flat network is provisioned. The bridge is dynamically deleted when the last VM using the flat network is deleted. During the switch over, all configuration on the physical interface is moved from the physical device to the bridge device. In today's ML2-Linux bridge implementation, only the ip address and the gateway are retained. There is no consideration to move the routes associated with the physical interface and they are lost. In the case when openstack components communicate with openstack controller, the connectivity would be lost after the first VM is provisioned. To reproduce the issue, add arbitrary route on the underflying physical interface, e.g., eth0, 1. "route add -net 10.75.0.0/16 gw 20.20.20.1" prior to start ML2-Linux-bridge agent. 2. Start ML2-Linuxbridge agent, and provision a new VM to use flat network. 3. do a route show "ip route list" and observe the 10.75.0.0 routes disapppears. This happens from kilo code to master branch. The relevant code on master branch is neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py def update_interface_ip_details(self, destination, source): # Returns True if there were IPs or a gateway moved updated = False for ip_version in (constants.IP_VERSION_4, constants.IP_VERSION_6): ips, gateway = self.get_interface_details(source, ip_version) if ips or gateway: self._update_interface_ip_details(destination, source, ips, gateway) updated = True return updated only ips and gateway are considered, routes associated with the interafce is not considered at all. ** 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/1703510 Title: ML2-Linuxbridge not keep routes on physical interface Status in neutron: New Bug description: When using ML2-Linuxbridge flat network, the bridge is dynamically created when the first VM using the flat network is provisioned. The bridge is dynamically deleted when the last VM using the flat network is deleted. During the switch over, all configuration on the physical interface is moved from the physical device to the bridge device. In today's ML2-Linux bridge implementation, only the ip address and the gateway are retained. There is no consideration to move the routes associated with the physical interface and they are lost. In the case when openstack components communicate with openstack controller, the connectivity would be lost after the first VM is provisioned. To reproduce the issue, add arbitrary route on the underflying physical interface, e.g., eth0, 1. "route add -net 10.75.0.0/16 gw 20.20.20.1" prior to start ML2-Linux-bridge agent. 2. Start ML2-Linuxbridge agent, and provision a new VM to use flat network. 3. do a route show "ip route list" and observe the 10.75.0.0 routes disapppears. This happens from kilo code to master branch. The relevant code on master branch is neutron/plugins/ml2/drivers/linuxbridge/agent/linuxbridge_neutron_agent.py def update_interface_ip_details(self, destination, source): # Returns True if there were IPs or a gateway moved updated = False for ip_version in (constants.IP_VERSION_4, constants.IP_VERSION_6): ips, gateway = self.get_interface_details(source, ip_version) if ips or gateway: self._update_interface_ip_details(destination, source, ips, gateway) updated = True return updated only ips and gateway are considered, routes associated with the interafce is not considered at all. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1703510/+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 1700454] Re: "Quota exceeded for instances" in fwaas tempest tests
i haven't seen it recently. i guess it has been fixed in the meantime.
** Changed in: neutron
Status: New => Invalid
** Changed in: networking-midonet
Status: In Progress => Invalid
** Changed in: networking-midonet
Importance: Critical => Undecided
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1700454
Title:
"Quota exceeded for instances" in fwaas tempest tests
Status in networking-midonet:
Invalid
Status in neutron:
Invalid
Bug description:
eg. http://logs.openstack.org/87/199387/83/check/gate-tempest-dsvm-
networking-midonet-ml2-full-
centos-7-nv/b221d8d/logs/testr_results.html.gz
Traceback (most recent call last):
File
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/scenario/test_fwaas.py",
line 366, in test_firewall_disable_rule
allow=self._disable_rule)
File
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/scenario/test_fwaas.py",
line 305, in _test_firewall_basic
self._create_topology()
File
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/scenario/test_fwaas.py",
line 267, in _create_topology
security_group=security_group)
File
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/scenario/test_fwaas.py",
line 59, in _create_server
**kwargs)
File
"/opt/stack/new/neutron-fwaas/neutron_fwaas/tests/tempest_plugin/tests/scenario/manager.py",
line 208, in create_server
image_id=image_id, **kwargs)
File "tempest/common/compute.py", line 168, in create_test_server
**kwargs)
File "tempest/lib/services/compute/servers_client.py", line 89, in
create_server
resp, body = self.post('servers', post_body)
File "tempest/lib/common/rest_client.py", line 270, in post
return self.request('POST', url, extra_headers, headers, body, chunked)
File "tempest/lib/services/compute/base_compute_client.py", line 48, in
request
method, url, extra_headers, headers, body, chunked)
File "tempest/lib/common/rest_client.py", line 659, in request
self._error_checker(resp, resp_body)
File "tempest/lib/common/rest_client.py", line 760, in _error_checker
raise exceptions.Forbidden(resp_body, resp=resp)
tempest.lib.exceptions.Forbidden: Forbidden
Details: {u'message': u'Quota exceeded for instances: Requested 1, but
already used 10 of 10 instances', u'code': 403}
To manage notifications about this bug go to:
https://bugs.launchpad.net/networking-midonet/+bug/1700454/+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 1670627] Re: quota is always in-use after delete the ERROR instances
Should be fixed in Ocata 15.0.1. ** Changed in: nova/ocata Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1670627 Title: quota is always in-use after delete the ERROR instances Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) ocata series: Fix Released Bug description: 1. stop nova-compute 2. boot an instance 3. the instance is in ERROR 4. delete the instance 5. repeat 1-4 for several times(actually, I create the instance by heat, heat will retry to create the instance 5 times by default and will delete the error instance before every retrying) 6. I can't boot instance after nova-compute back, the reason is "Quota exceeded for instances: Requested 1, but already used 10 of 10 instances" 7. but in fact, there is no instance return by cmd nova-list 8. I find that the quota is still in-use, see table 'quota_usages': mysql> select *from quota_usages; +-+-+++--+---++--+---+-+--+ | created_at | updated_at | deleted_at | id | project_id | resource | in_use | reserved | until_refresh | deleted | user_id | +-+-+++--+---++--+---+-+--+ | 2017-03-07 06:26:08 | 2017-03-07 08:48:09 | NULL | 1 | 2b623ba1dddc476cbb7728a944d539c5 | instances | 10 |0 | NULL | 0 | 8d57d7a267b54992b382a6607ecd700a | | 2017-03-07 06:26:08 | 2017-03-07 08:48:09 | NULL | 2 | 2b623ba1dddc476cbb7728a944d539c5 | ram | 5120 |0 | NULL | 0 | 8d57d7a267b54992b382a6607ecd700a | | 2017-03-07 06:26:08 | 2017-03-07 08:48:09 | NULL | 3 | 2b623ba1dddc476cbb7728a944d539c5 | cores | 10 |0 | NULL | 0 | 8d57d7a267b54992b382a6607ecd700a | | 2017-03-07 09:17:37 | 2017-03-07 09:35:14 | NULL | 4 | 12bdc74d666d4f7687c0172a003f190d | instances | 13 |0 | NULL | 0 | 98887477e65e43f383f8a9ec732a3eae | | 2017-03-07 09:17:37 | 2017-03-07 09:35:14 | NULL | 5 | 12bdc74d666d4f7687c0172a003f190d | ram | 6656 |0 | NULL | 0 | 98887477e65e43f383f8a9ec732a3eae | | 2017-03-07 09:17:37 | 2017-03-07 09:35:14 | NULL | 6 | 12bdc74d666d4f7687c0172a003f190d | cores | 13 |0 | NULL | 0 | 98887477e65e43f383f8a9ec732a3eae | +-+-+++--+---++--+---+-+--+ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1670627/+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 1703488] [NEW] Database not delete PCI info after device is removed from host and nova.conf
Public bug reported: Hi, this is my 1st time write this report at Launchpad. ===Description=== I'm using Mitaka installed by Fuel 9.2, and I meet a issue that the info didn't remove at pci_devices table in Nova Database after I removed one of the device from compute node and nova.conf ===How did I reproduce?=== 1. Plug two different model PCI devices and add two PCI devices information into nova.conf in target compute node and each control node by following format: 2. Restart nova-api, nova-scheduler, and nova-compute. Compute node only shows the last device I add. But if I do some actions on instance with the flavor contained PCI passthrough info, it will be normal. And database info is correct. 3. Remove one of the PCI device info from nova.conf (included target compute and controllers), restart services, shutdown the compute node and unplug the device. (Note: The card ID of what I remove is 1002:68c8) Power on the compute code and check nova-compute log, the report is correct. ===Expected result=== The info of removed device should be deleted or stayed at "DELETED" status in Nova DB. ===Actual result=== The info of removed device still exist and stayed at "AVAILABLE" status in Nova DB. ===Log and configs=== [1] Format of pci_alias and pci_passthrough_whitelist in nova.conf http://paste.openstack.org/show/614973/ [2] Nova-compute log after added info and restart service http://paste.openstack.org/show/z015rYGXaxYhVoafKdbx/ [3] Nova-compute log after doing few actions on instance contained with PCI http://paste.openstack.org/show/614658/ [4] Pci_devices table info in Nova DB after add devices http://paste.openstack.org/show/8JS0i6BMitjeBVRJTkRo/ [5] Nova-compute log after remove one of the device and restart service http://paste.openstack.org/show/qUCOX09jyeMydoYHc8Oz/ [6] Pci_devices table info in Nova DB after remove one of the device http://paste.openstack.org/show/SnJ8AzJYD6wCo7jslIc2/ ** Affects: nova Importance: Undecided Status: New ** Tags: db pci -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1703488 Title: Database not delete PCI info after device is removed from host and nova.conf Status in OpenStack Compute (nova): New Bug description: Hi, this is my 1st time write this report at Launchpad. ===Description=== I'm using Mitaka installed by Fuel 9.2, and I meet a issue that the info didn't remove at pci_devices table in Nova Database after I removed one of the device from compute node and nova.conf ===How did I reproduce?=== 1. Plug two different model PCI devices and add two PCI devices information into nova.conf in target compute node and each control node by following format: 2. Restart nova-api, nova-scheduler, and nova-compute. Compute node only shows the last device I add. But if I do some actions on instance with the flavor contained PCI passthrough info, it will be normal. And database info is correct. 3. Remove one of the PCI device info from nova.conf (included target compute and controllers), restart services, shutdown the compute node and unplug the device. (Note: The card ID of what I remove is 1002:68c8) Power on the compute code and check nova-compute log, the report is correct. ===Expected result=== The info of removed device should be deleted or stayed at "DELETED" status in Nova DB. ===Actual result=== The info of removed device still exist and stayed at "AVAILABLE" status in Nova DB. ===Log and configs=== [1] Format of pci_alias and pci_passthrough_whitelist in nova.conf http://paste.openstack.org/show/614973/ [2] Nova-compute log after added info and restart service http://paste.openstack.org/show/z015rYGXaxYhVoafKdbx/ [3] Nova-compute log after doing few actions on instance contained with PCI http://paste.openstack.org/show/614658/ [4] Pci_devices table info in Nova DB after add devices http://paste.openstack.org/show/8JS0i6BMitjeBVRJTkRo/ [5] Nova-compute log after remove one of the device and restart service http://paste.openstack.org/show/qUCOX09jyeMydoYHc8Oz/ [6] Pci_devices table info in Nova DB after remove one of the device http://paste.openstack.org/show/SnJ8AzJYD6wCo7jslIc2/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1703488/+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 1703486] [NEW] instance catalogue residual after excute resize-revert
Public bug reported: images_type configuration is rbd,but the instance catalogue is not shared.After exceute resize revert, the instance catalogue will residual in destination node.This will affect live-migration later.When the imagebacken is RBd, we think this is shared storage, but in actual environment,the instance catalogue can be not in shared storage. ** Affects: nova Importance: Undecided Status: New ** Changed in: nova Milestone: None => pike-1 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1703486 Title: instance catalogue residual after excute resize-revert Status in OpenStack Compute (nova): New Bug description: images_type configuration is rbd,but the instance catalogue is not shared.After exceute resize revert, the instance catalogue will residual in destination node.This will affect live-migration later.When the imagebacken is RBd, we think this is shared storage, but in actual environment,the instance catalogue can be not in shared storage. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1703486/+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 1486127] Re: No API reference of RBAC API
Reviewed: https://review.openstack.org/479134 Committed: https://git.openstack.org/cgit/openstack/neutron-lib/commit/?id=ee0fc48f7c76a61ea02eb42b5f7f368d576601ea Submitter: Jenkins Branch:master commit ee0fc48f7c76a61ea02eb42b5f7f368d576601ea Author: Felipe Monteiro Date: Fri Jun 30 05:14:20 2017 +0100 api-ref: RBAC policies api reference This patch adds RBAC policies API reference for the RBAC policies extension. Change-Id: I036a8108071b4b1db32c96ebb1b48da453e268b1 Closes-Bug: #1486127 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1486127 Title: No API reference of RBAC API Status in neutron: Fix Released Bug description: https://review.openstack.org/205482 commit 22c84927d133158c9de429ba1b9dbcd1d077d773 Author: Ramanjaneya Date: Fri Jul 24 15:51:53 2015 +0530 Support RBAC neutron-client changes. This patch adds the command line support for RBAC work. DocImpact APIImpact Partially-Implements: blueprint rbac-networks Co-Authored-By: dongfeng Change-Id: I00c6b84b3f7d810f137ce05c0cd936dc194d9708 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1486127/+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 1703467] [NEW] assert_admin is checking default policy rule not admin_required
Public bug reported: https://github.com/openstack/keystone/commit/40c118d6ba94b15d6f66da618e1d368a0f876340 broke all places calling assert_admin. Previously, assert_admin checked the "admin_required" rule. With that change, assert_admin now checks the "identity:admin_required" rule. That rule is not defined, so what actually gets checked is the default rule. We must fix this before shipping Pike to avoid breaking backward compatibility. ** Affects: keystone Importance: Undecided Assignee: Matthew Edmonds (edmondsw) Status: New ** Changed in: keystone Assignee: (unassigned) => Matthew Edmonds (edmondsw) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1703467 Title: assert_admin is checking default policy rule not admin_required Status in OpenStack Identity (keystone): New Bug description: https://github.com/openstack/keystone/commit/40c118d6ba94b15d6f66da618e1d368a0f876340 broke all places calling assert_admin. Previously, assert_admin checked the "admin_required" rule. With that change, assert_admin now checks the "identity:admin_required" rule. That rule is not defined, so what actually gets checked is the default rule. We must fix this before shipping Pike to avoid breaking backward compatibility. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1703467/+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 1698517] Re: DVR FIP namespace missing default route after upgrade
** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1698517 Title: DVR FIP namespace missing default route after upgrade Status in neutron: Fix Released Bug description: After upgrading from a code without https://review.openstack.org/#/q/Ida165d1ecf5c07af31dac11d9daed33ccaaf5605,n,z to code with it, the FIP namespace default route gets removed but the rule based route does not get added so traffic destined to the addresses outside of the external network does not work. The grenade job likely missed this because the test nodes have addresses directly on the external network so the default route isn't used. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1698517/+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 1703457] Re: RFE: More intuitive usage of --min and --max arguments in openstack server create
*** This bug is a duplicate of bug 1458122 *** https://bugs.launchpad.net/bugs/1458122 This is a duplicate of bug 1458122. ** This bug has been marked a duplicate of bug 1458122 nova shouldn't error if we can't schedule all of max_count instances at boot time -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1703457 Title: RFE: More intuitive usage of --min and --max arguments in openstack server create Status in OpenStack Compute (nova): New Bug description: Currently the --min argument passed to openstack server create is only used to check the Quota but once the Quota check passes, if the --max number of instances can't be scheduled all instances go into ERROR state. However, when --min and --max are passed, it would be great if nova schedules as many instances as possible upto --max and only fails when even the --min number of instances can't be scheduled. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1703457/+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 1703457] [NEW] RFE: More intuitive usage of --min and --max arguments in openstack server create
*** This bug is a duplicate of bug 1458122 *** https://bugs.launchpad.net/bugs/1458122 Public bug reported: Currently the --min argument passed to openstack server create is only used to check the Quota but once the Quota check passes, if the --max number of instances can't be scheduled all instances go into ERROR state. However, when --min and --max are passed, it would be great if nova schedules as many instances as possible upto --max and only fails when even the --min number of instances can't be scheduled. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1703457 Title: RFE: More intuitive usage of --min and --max arguments in openstack server create Status in OpenStack Compute (nova): New Bug description: Currently the --min argument passed to openstack server create is only used to check the Quota but once the Quota check passes, if the --max number of instances can't be scheduled all instances go into ERROR state. However, when --min and --max are passed, it would be great if nova schedules as many instances as possible upto --max and only fails when even the --min number of instances can't be scheduled. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1703457/+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 1483853] Re: Cannot set the VXLAN UDP destination port to 4789 using Linux Bridge
Reviewed: https://review.openstack.org/468911
Committed:
https://git.openstack.org/cgit/openstack/neutron/commit/?id=d7c4428525dac6cbde005f51bcd44b12ebc3bc0a
Submitter: Jenkins
Branch:master
commit d7c4428525dac6cbde005f51bcd44b12ebc3bc0a
Author: Gyorgy Szombathelyi
Date: Mon May 29 16:21:15 2017 +0200
Allow to set UDP ports for VXLAN in Linuxbridge agent
Introduce vxlan.{udp_srcport_min, udp_srcport_max and udp_dstport}
for setting the port range used for VXLAN communication.
Change-Id: I9788090eee7aee9b533ac1dad2de95b29cbe
Closes-Bug: #1483853
DocImpact: vxlan.{udp_srcport_min, udp_srcport_max and udp_dstport}
can be used to set UDP port numbers used for VXLAN in LinuxBridge
agent.
** Changed in: neutron
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1483853
Title:
Cannot set the VXLAN UDP destination port to 4789 using Linux Bridge
Status in neutron:
Fix Released
Bug description:
I'm running stable/Juno with VXLAN and Linux Bridge.
Linux default VxLAN UDP port is 8472.
IANA assigned port is 4789.
I tried to add the following in /etc/neutron/plugins/ml2/ml2_conf.ini
file, but it still use port 8472 afterwards.
[agent]
vxlan_udp_port=4789
##
Comments from Kevin Benton:
Looking at the code, it doesn't look like vxlan_udp_port applies to
Linux Bridge. Please file a bug and we should be able to get a fix
pretty quickly.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1483853/+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 1703369] Re: get_identity_providers policy should be singular
Just to confirm, this is only a risk for the upcoming Pike release, not
a defect in current supported stable branches? If so, we would not issue
a security advisory unless it remains unfixed at release time per report
class Y ("Vulnerability only found in development release") in our
taxonomy: https://security.openstack.org/vmt-process.html#incident-
report-taxonomy
** Also affects: ossa
Importance: Undecided
Status: New
** Changed in: ossa
Status: New => Incomplete
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1703369
Title:
get_identity_providers policy should be singular
Status in OpenStack Identity (keystone):
In Progress
Status in OpenStack Security Advisory:
Incomplete
Bug description:
identity:get_identity_providers should be
identity:get_identity_provider (singular) since a GET is targeted on a
single provider and the code is setup to check for
identity:get_identity_provider (singular). See
https://github.com/openstack/keystone/blob/c7e29560b7bf7a44e44722eea0645bf18ad56af3/keystone/federation/controllers.py#L112
found in master (pike)
The ocata default policy.json also has this problem. Unless someone
manually overrode policy to specify identity:get_identity_provider
(singular), the result would be that the default rule was actually
used for that check instead of identity:get_identity_providers. We
could go back and fix the default policy.json for past releases, but
the default actually has the same value as
identity:get_identity_providers, and if nobody has complained it's
probably safer to just leave it. It is, after all, just defaults there
and anyone can override by specifying the correct value.
But we must fix in pike to go along with the shift of policy into
code. Policy defaults in code definitely need to match up with what
the code actually checks. There should no longer be any reliance on
the default rule.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1703369/+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 1703413] [NEW] Allow to set UDP ports for VXLAN in Linuxbridge agent
Public bug reported:
https://review.openstack.org/468911
Dear bug triager. This bug was created since a commit was marked with DOCIMPACT.
Your project "openstack/neutron" is set up so that we directly report the
documentation bugs against it. If this needs changing, the docimpact-group
option needs to be added for the project. You can ask the OpenStack infra team
(#openstack-infra on freenode) for help if you need to.
commit d7c4428525dac6cbde005f51bcd44b12ebc3bc0a
Author: Gyorgy Szombathelyi
Date: Mon May 29 16:21:15 2017 +0200
Allow to set UDP ports for VXLAN in Linuxbridge agent
Introduce vxlan.{udp_srcport_min, udp_srcport_max and udp_dstport}
for setting the port range used for VXLAN communication.
Change-Id: I9788090eee7aee9b533ac1dad2de95b29cbe
Closes-Bug: #1483853
DocImpact: vxlan.{udp_srcport_min, udp_srcport_max and udp_dstport}
can be used to set UDP port numbers used for VXLAN in LinuxBridge
agent.
** Affects: neutron
Importance: Undecided
Status: New
** Tags: doc neutron
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1703413
Title:
Allow to set UDP ports for VXLAN in Linuxbridge agent
Status in neutron:
New
Bug description:
https://review.openstack.org/468911
Dear bug triager. This bug was created since a commit was marked with
DOCIMPACT.
Your project "openstack/neutron" is set up so that we directly report the
documentation bugs against it. If this needs changing, the docimpact-group
option needs to be added for the project. You can ask the OpenStack infra team
(#openstack-infra on freenode) for help if you need to.
commit d7c4428525dac6cbde005f51bcd44b12ebc3bc0a
Author: Gyorgy Szombathelyi
Date: Mon May 29 16:21:15 2017 +0200
Allow to set UDP ports for VXLAN in Linuxbridge agent
Introduce vxlan.{udp_srcport_min, udp_srcport_max and udp_dstport}
for setting the port range used for VXLAN communication.
Change-Id: I9788090eee7aee9b533ac1dad2de95b29cbe
Closes-Bug: #1483853
DocImpact: vxlan.{udp_srcport_min, udp_srcport_max and udp_dstport}
can be used to set UDP port numbers used for VXLAN in LinuxBridge
agent.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1703413/+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 1703392] [NEW] default rule no longer applies with policy in code
Public bug reported: The following should not exist in keystone/common/policies/base.py: policy.RuleDefault( name='default', check_str='rule:admin_required') because a default rule should no longer apply with policy in code. If we've correctly defined all policy rules in code, then we'll never have a case where code is checking a rule that can't be found, which is when the default rule is checked. In previous releases, some operators who override policy used the default rule to restrict all rules that they (intentionally) omitted from their policy.json. This shortened those files, and protected them if keystone added new policy checks until/unless they decided to open things up more widely. Leaving the default rule defined now that policy is in code will confuse this kind of operator (and possibly others) who haven't thought it through and realized that the default rule can't be used like that anymore because it won't be checked just because you didn't define another rule in policy.json. ** Affects: keystone Importance: Undecided Assignee: Matthew Edmonds (edmondsw) Status: In Progress ** Changed in: keystone Assignee: (unassigned) => Matthew Edmonds (edmondsw) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1703392 Title: default rule no longer applies with policy in code Status in OpenStack Identity (keystone): In Progress Bug description: The following should not exist in keystone/common/policies/base.py: policy.RuleDefault( name='default', check_str='rule:admin_required') because a default rule should no longer apply with policy in code. If we've correctly defined all policy rules in code, then we'll never have a case where code is checking a rule that can't be found, which is when the default rule is checked. In previous releases, some operators who override policy used the default rule to restrict all rules that they (intentionally) omitted from their policy.json. This shortened those files, and protected them if keystone added new policy checks until/unless they decided to open things up more widely. Leaving the default rule defined now that policy is in code will confuse this kind of operator (and possibly others) who haven't thought it through and realized that the default rule can't be used like that anymore because it won't be checked just because you didn't define another rule in policy.json. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1703392/+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 1703305] Re: some functions are deprecated in tempest
This isn't actually a bug in tempest, those are interfaces that will be
removed in a future version. The neutron tempest plugin is using them
which is causing the warning to be emitted. The issue is that the
neutron plugin code needs to be updated
** Changed in: tempest
Status: New => Invalid
** Also affects: neutron
Importance: Undecided
Status: New
** No longer affects: tempest
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1703305
Title:
some functions are deprecated in tempest
Status in neutron:
New
Bug description:
There are some logs I could find where I could see there are some deprecated
functions in tempest like following:
/usr/lib/python2.7/site-packages/neutron/tests/tempest/api/admin/test_external_network_extension.py:41:
DeprecationWarning: Function 'tempest.test.idempotent_id()' has moved to
'tempest.lib.decorators.idempotent_id()' in version 'Mitaka' and will be
removed in a future version
@test.idempotent_id('afd8f1b7-a81e-4629-bca8-a367b3a144bb')
/usr/lib/python2.7/site-packages/neutron/tests/tempest/api/admin/test_floating_ips_admin_actions.py:45:
DeprecationWarning: Function 'tempest.test.idempotent_id()' has moved to
'tempest.lib.decorators.idempotent_id()' in version 'Mitaka' and will be
removed in a future version
@test.idempotent_id('6ee9-4e99-5b15-b8e1-aa7df92ca589')
/usr/lib/python2.7/site-packages/neutron/tests/tempest/api/admin/test_l3_agent_scheduler.py:67:
DeprecationWarning: Function 'tempest.test.idempotent_id()' has moved to
'tempest.lib.decorators.idempotent_id()' in version 'Mitaka' and will be
removed in a future version
@test.idempotent_id('b7ce6e89-e837-4ded-9b78-9ed3c9c6a45a')
/usr/lib/python2.7/site-packages/neutron/tests/tempest/api/admin/test_networks.py:22:
DeprecationWarning: Function 'tempest.test.idempotent_id()' has moved to
'tempest.lib.decorators.idempotent_id()' in version 'Mitaka' and will be
removed in a future version
@test.idempotent_id('d3c76044-d067-4cb0-ae47-8cdd875c7f67')
/usr/lib/python2.7/site-packages/neutron/tests/tempest/api/admin/test_quotas.py:78:
DeprecationWarning: Function 'tempest.test.idempotent_id()' has moved to
'tempest.lib.decorators.idempotent_id()' in version 'Mitaka' and will be
removed in a future version
@test.idempotent_id('2390f766-836d-40ef-9aeb-e810d78207fb')
/usr/lib/python2.7/site-packages/neutron/tests/tempest/api/admin/test_quotas_negative.py:26:
DeprecationWarning: Function 'tempest.test.idempotent_id()' has moved to
'tempest.lib.decorators.idempotent_id()' in version 'Mitaka' and will be
removed in a future version
@test.idempotent_id('952f9b24-9156-4bdc-90f3-682a3d4302f0')
/usr/lib/python2.7/site-packages/neutron/tests/tempest/api/admin/test_routers_dvr.py:42:
DeprecationWarning: Function 'tempest.test.idempotent_id()' has moved to
'tempest.lib.decorators.idempotent_id()' in version 'Mitaka' and will be
removed in a future version
@test.idempotent_id('08a2a0a8-f1e4-4b34-8e30-e522e836c44e')
/usr/lib/python2.7/site-packages/neutron/tests/tempest/api/admin/test_routers_flavors.py:83:
DeprecationWarning: Function 'tempest.test.idempotent_id()' has moved to
'tempest.lib.decorators.idempotent_id()' in version 'Mitaka' and will be
removed in a future version
@test.idempotent_id('a4d01977-e968-4983-b4d9-824ea6c33f4b')
/usr/lib/python2.7/site-packages/neutron/tests/tempest/api/admin/test_shared_network_extension.py:33:
DeprecationWarning: Function 'tempest.test.idempotent_id()' has moved to
'tempest.lib.decorators.idempotent_id()' in version 'Mitaka' and will be
removed in a future version
@test.idempotent_id('6661d219-b96d-4597-ad10-55766123421a')
/usr/lib/python2.7/site-packages/neutron/tests/tempest/api/test_address_scopes.py:59:
DeprecationWarning: Function 'tempest.test.idempotent_id()' has moved to
'tempest.lib.decorators.idempotent_id()' in version 'Mitaka' and will be
removed in a future version
@test.idempotent_id('045f9294-8b1a-4848-b6a8-edf1b41e9d06')
/usr/lib/python2.7/site-packages/neutron/tests/tempest/api/test_address_scopes_negative.py:25:
DeprecationWarning: Function 'tempest.test.idempotent_id()' has moved to
'tempest.lib.decorators.idempotent_id()' in version 'Mitaka' and will be
removed in a future version
@test.idempotent_id('9c92ec34-0c50-4104-aa47-9ce98d5088df')
/usr/lib/python2.7/site-packages/neutron/tests/tempest/api/test_allowed_address_pair.py:51:
DeprecationWarning: Function 'tempest.test.idempotent_id()' has moved to
'tempest.lib.decorators.idempotent_id()' in version 'Mitaka' and will be
removed in a future version
@test.idempotent_id('86c3529b-1231-40de-803c-00e40882f043')
/usr/lib/python2.7/site-packages/neutron/tests/tempest/api/test_
[Yahoo-eng-team] [Bug 1703390] [NEW] Allow setting default region to log into
Public bug reported: This is based on the solution provided with https://bugs.launchpad.net/horizon/+bug/1506825 by Timur Sufiev. The point is to have a setting (in local_settings.py) that allows user to set the value of the default region to log into. If it is specified (and no other region is set explicitly) and valid, it is used for logging in. If it is empty, the existing mechanism of checking the cookies is used. ** Affects: horizon Importance: Undecided Assignee: Jiri Suchomel (jsuchome) Status: In Progress ** Changed in: horizon Assignee: (unassigned) => Jiri Suchomel (jsuchome) -- 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/1703390 Title: Allow setting default region to log into Status in OpenStack Dashboard (Horizon): In Progress Bug description: This is based on the solution provided with https://bugs.launchpad.net/horizon/+bug/1506825 by Timur Sufiev. The point is to have a setting (in local_settings.py) that allows user to set the value of the default region to log into. If it is specified (and no other region is set explicitly) and valid, it is used for logging in. If it is empty, the existing mechanism of checking the cookies is used. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1703390/+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 1663225] Re: ironic does not clean or shutdown nodes if nova-compute is down at the moment of 'nova delete'
This problem exists in Ironic regardless of bot attempts to sweep it under the expiration rug. ** Changed in: nova Status: Expired => New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1663225 Title: ironic does not clean or shutdown nodes if nova-compute is down at the moment of 'nova delete' Status in OpenStack Compute (nova): New Bug description: Affected configuration: Ironic installation with Ironic driver for nova. If nova-compute service is down at the moment of execution 'nova delete' for instance, nova marks instance as 'deleted' even node is continue to run. Steps to reproduce: 1. Prepare ironic/nova 2. Start instance (nova boot/openstack server create) 3. Wait until 'ACTIVE' state for instance. 4. Stop nova-compute 5. Wait until it become 'down' in 'nova service-list' 5. Execute 'nova delete' command for instance. 6. Start nova-compute serivce Expected result: - Instance sits in the 'deleting' state until nova-compute is not come back. - Node switch to 'cleaning/available' as soon as nova-compute come back - Tenant instance (baremetal server) stops to operate as soon as nova-compute is up. nova-compute is up. Actual result: - Instance deleted almost instantly regardless of nova-compute status. - Node keeps 'active' state with filled in 'Instance UUID' field. - Tenant instance (baremetal server) continue to work after nova-compute is up to "running_deleted_instance_action" time. I believe this is incorrect behavior, because it allows tenants to continue to use services regardless of nova report that there are no instances are allocated to tenant. Affected version: newton. P.S. Normally nova (with libvirt/kvm driver) would keep instance in 'deleting' state until nova-compute is not come back, and remove it from server (from libvirt). Only after that nova marks instance as deleted in database. Ironic driver should do the same. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1663225/+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 1703369] [NEW] get_identity_providers policy should be singular
Public bug reported: identity:get_identity_providers should be identity:get_identity_provider (singular) since a GET is targeted on a single provider. found in master (pike) ** Affects: keystone Importance: Undecided Assignee: Matthew Edmonds (edmondsw) Status: In Progress ** Changed in: keystone Assignee: (unassigned) => Matthew Edmonds (edmondsw) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1703369 Title: get_identity_providers policy should be singular Status in OpenStack Identity (keystone): In Progress Bug description: identity:get_identity_providers should be identity:get_identity_provider (singular) since a GET is targeted on a single provider. found in master (pike) To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1703369/+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 1703360] [NEW] Don't show IPv6 addresses when selecting port for floating IP
Public bug reported: A floating IP can only be associated with an IPv4 address, trying to use an IPv6 address leads to an error like this: Error: Bad floatingip request: Cannot process floating IP association with fdb7:6005:3c07:0:f816:3eff:fe94:35d4, since that is not an IPv4 address. Neutron server returns request_ids: ['req-1ffbc2fb-5e84-44ac- 990e-62be46801e77'] So the selector should only show the IPv4 addresses of an instance to choose from in the "Associate Floating IP" action. Tested with current stable/ocata. ** 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/1703360 Title: Don't show IPv6 addresses when selecting port for floating IP Status in OpenStack Dashboard (Horizon): New Bug description: A floating IP can only be associated with an IPv4 address, trying to use an IPv6 address leads to an error like this: Error: Bad floatingip request: Cannot process floating IP association with fdb7:6005:3c07:0:f816:3eff:fe94:35d4, since that is not an IPv4 address. Neutron server returns request_ids: ['req-1ffbc2fb-5e84-44ac- 990e-62be46801e77'] So the selector should only show the IPv4 addresses of an instance to choose from in the "Associate Floating IP" action. Tested with current stable/ocata. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1703360/+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 1417305] Re: Default value for Physical Network is hardcoded value
Reviewed: https://review.openstack.org/476453 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=449aa1a48cc7260ffc3c78570334e9ee2fbc51cb Submitter: Jenkins Branch:master commit 449aa1a48cc7260ffc3c78570334e9ee2fbc51cb Author: Beth Elwell Date: Thu Jun 22 11:20:33 2017 +0100 Removed default value for 'Physical Network' When creating a network there is currently a default value of 'default' which causes the network creation to fail. It is nonsensical to have a default value here as it will change depending on the provider network type and needs to be set according to custom settings if the user is not creating a simple local network which then does not require the physical network value at all. Change-Id: I448713d986f17ea1c00cd4dd22487291545cfe2a Closes-Bug: #1417305 ** Changed in: horizon Status: In Progress => Fix Released -- 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/1417305 Title: Default value for Physical Network is hardcoded value Status in OpenStack Dashboard (Horizon): Fix Released Bug description: The default value for the "Physical Network" field in the "Create Network" form of the Admin dashboard, shown when the Neutron provider extension is supported, is "default". It makes more sense for the default to be blank instead of a hardcoded string. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1417305/+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 1703347] [NEW] insert_rule/remove_rule in policy.json should be moved to neutron-fwaas
Public bug reported: etc/policy.json in the neutron repo contains 'insert_rule' and 'remove_rule' which are specific to neutron-fwaas [1]. They should be moved to neutron-fwaas. [1] https://github.com/openstack/neutron/blob/master/etc/policy.json#L121-L122 ** Affects: neutron Importance: Low Assignee: Akihiro Motoki (amotoki) Status: New ** Tags: fwaas ** Changed in: neutron Importance: Undecided => Low -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1703347 Title: insert_rule/remove_rule in policy.json should be moved to neutron- fwaas Status in neutron: New Bug description: etc/policy.json in the neutron repo contains 'insert_rule' and 'remove_rule' which are specific to neutron-fwaas [1]. They should be moved to neutron-fwaas. [1] https://github.com/openstack/neutron/blob/master/etc/policy.json#L121-L122 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1703347/+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 1703340] [NEW] Login twice after 'service apache2 restart'
Public bug reported: After restart Apache/Horizon I need to login twice. Step to reproduce: 1. Go to login page 2. sudo service apache2 restart 3. Log in as admin. After that, you will be redirected back to the login page 4. You need type login and password one more time Expected behaviour: After restart I should type login and password only one time ** Affects: horizon Importance: Undecided Status: New ** Project changed: django-openstack-auth => horizon -- 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/1703340 Title: Login twice after 'service apache2 restart' Status in OpenStack Dashboard (Horizon): New Bug description: After restart Apache/Horizon I need to login twice. Step to reproduce: 1. Go to login page 2. sudo service apache2 restart 3. Log in as admin. After that, you will be redirected back to the login page 4. You need type login and password one more time Expected behaviour: After restart I should type login and password only one time To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1703340/+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 1703340] [NEW] Login twice after 'service apache2 restart'
You have been subscribed to a public bug: After restart Apache/Horizon I need to login twice. Step to reproduce: 1. Go to login page 2. sudo service apache2 restart 3. Log in as admin. After that, you will be redirected back to the login page 4. You need type login and password one more time Expected behaviour: After restart I should type login and password only one time ** Affects: horizon Importance: Undecided Status: New -- Login twice after 'service apache2 restart' https://bugs.launchpad.net/bugs/1703340 You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). -- 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 1703318] [NEW] add gateway on router for L3 API
Public bug reported:
This bug tracker is for errors with the documentation, use the following
as a template and remove or add fields as you see fit. Convert [ ] into
[x] to check boxes:
- [ ] This doc is inaccurate in this way: __
- [x ] This is a doc addition request.
- [ ] I have a fix to the document that I can paste below including example:
input and output.
I found the python-openstacksdk has a "add_gateway_to_router" method
which is finally mapped to /v2/routers/{router_id}/add_gateway_router in
the RESTful api with `PUT` method, however, in the official doc, there
are only /v2.0/routers/{router_id}/add_router_interface API for adding
interface on router. As far as I can see, it's necessary to introduce
add_gateway_router and remove_gateway_router API
If you have a troubleshooting or support issue, use the following
resources:
- Ask OpenStack: http://ask.openstack.org
- The mailing list: http://lists.openstack.org
- IRC: 'openstack' channel on Freenode
---
Release: 1.7.1.dev53 on 'Thu Jul 6 17:54:16 2017, commit 4e100d9'
SHA:
Source: Can't derive source file URL
URL: https://developer.openstack.org/api-ref/networking/v2/index.html
** 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/1703318
Title:
add gateway on router for L3 API
Status in neutron:
New
Bug description:
This bug tracker is for errors with the documentation, use the
following as a template and remove or add fields as you see fit.
Convert [ ] into [x] to check boxes:
- [ ] This doc is inaccurate in this way: __
- [x ] This is a doc addition request.
- [ ] I have a fix to the document that I can paste below including example:
input and output.
I found the python-openstacksdk has a "add_gateway_to_router" method
which is finally mapped to /v2/routers/{router_id}/add_gateway_router
in the RESTful api with `PUT` method, however, in the official doc,
there are only /v2.0/routers/{router_id}/add_router_interface API for
adding interface on router. As far as I can see, it's necessary to
introduce add_gateway_router and remove_gateway_router API
If you have a troubleshooting or support issue, use the following
resources:
- Ask OpenStack: http://ask.openstack.org
- The mailing list: http://lists.openstack.org
- IRC: 'openstack' channel on Freenode
---
Release: 1.7.1.dev53 on 'Thu Jul 6 17:54:16 2017, commit 4e100d9'
SHA:
Source: Can't derive source file URL
URL: https://developer.openstack.org/api-ref/networking/v2/index.html
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1703318/+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 1703313] [NEW] DataTable column level policy_rules(allowed function) throw exception
Public bug reported: Version: Ocata Problem: The function allowed(self, request) in class Column which is in horizon/tables/base.py will throw exception "TypeError: 'str' object is not callable" if you add the "policy_rules" for DataTable column. I check the history: In bellowing changelist, the "DataTable column level policy" was merged on Dec 9, 2016 https://github.com/openstack/horizon/commit/0744e8e5942858756e80aff6f16fd5f89dec6077 But there was a refactor for "POLICY_CHECK_FUNCTION" on Nov 25, 2016 https://github.com/openstack/horizon/commit/f5685ebe468626a983954132c3e5754e9954563b The refactor shall also apply to "DataTable column level policy", otherwise, the exception will be throw. ** 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/1703313 Title: DataTable column level policy_rules(allowed function) throw exception Status in OpenStack Dashboard (Horizon): New Bug description: Version: Ocata Problem: The function allowed(self, request) in class Column which is in horizon/tables/base.py will throw exception "TypeError: 'str' object is not callable" if you add the "policy_rules" for DataTable column. I check the history: In bellowing changelist, the "DataTable column level policy" was merged on Dec 9, 2016 https://github.com/openstack/horizon/commit/0744e8e5942858756e80aff6f16fd5f89dec6077 But there was a refactor for "POLICY_CHECK_FUNCTION" on Nov 25, 2016 https://github.com/openstack/horizon/commit/f5685ebe468626a983954132c3e5754e9954563b The refactor shall also apply to "DataTable column level policy", otherwise, the exception will be throw. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1703313/+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 1703311] [NEW] gkk
Public bug reported: gkk test ** Affects: nova Importance: Undecided Assignee: kaikaige (krunerge) Status: New ** Changed in: nova Assignee: (unassigned) => kaikaige (krunerge) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1703311 Title: gkk Status in OpenStack Compute (nova): New Bug description: gkk test To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1703311/+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 1703303] [NEW] compute.pp fails during installation on rhel 7.4
Public bug reported: I was trying to install packstack on rhel 7.4, but I am getting following error- ^[[1;31mError: /Stage[main]/Packstack::Nova::Compute::Libvirt/File_line[libvirt-guests]: Could not evaluate: No such file or directory - /etc/sysconfig/libvirt-guests^[[0m ^[[1;31mError: /Stage[main]/Packstack::Nova::Compute::Libvirt/Exec[virsh-net-destroy-default]: Could not evaluate: Could not find command '/usr/bin/virsh'^[[0m and compute.pp gets fail. ** Affects: nova Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1703303 Title: compute.pp fails during installation on rhel 7.4 Status in OpenStack Compute (nova): New Bug description: I was trying to install packstack on rhel 7.4, but I am getting following error- ^[[1;31mError: /Stage[main]/Packstack::Nova::Compute::Libvirt/File_line[libvirt-guests]: Could not evaluate: No such file or directory - /etc/sysconfig/libvirt-guests^[[0m ^[[1;31mError: /Stage[main]/Packstack::Nova::Compute::Libvirt/Exec[virsh-net-destroy-default]: Could not evaluate: Could not find command '/usr/bin/virsh'^[[0m and compute.pp gets fail. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1703303/+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
