[Yahoo-eng-team] [Bug 1643301] Re: bootstrapping keystone failed when LDAP backend is in use
I'm closing this Won't fix because running with the LDAP backend is a
bad approach. Use SQL, with LDAP in a domain specific back end.
** Changed in: keystone
Status: Triaged => Won't Fix
--
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/1643301
Title:
bootstrapping keystone failed when LDAP backend is in use
Status in devstack:
In Progress
Status in OpenStack Identity (keystone):
Won't Fix
Bug description:
"keystone-manage bootstrap" command is coded for SQL backend, it's
should be okay if admin token is always supported by keystone, but we
have a plan to remove the support of admin token since it's expose a
security risk. And the patch to remove the support of write operation
for LDAP backend is on the fly.
Based on the above consideration, we should enable the bootrapping
keystone when using LDAP backend, but it currently not work sometimes,
for example.
# keystone-manage bootstrap --bootstrap-username Dave --bootstrap-password
abc123 --bootstrap-project-name admin --bootstrap-role-name admin
2016-10-27 16:26:29.845 11359 TRACE keystone return
self.result(msgid,all=1,timeout=self.timeout)
2016-10-27 16:26:29.845 11359 TRACE keystone File
"/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py", line 497, in result
2016-10-27 16:26:29.845 11359 TRACE keystone resp_type, resp_data,
resp_msgid = self.result2(msgid,all,timeout)
2016-10-27 16:26:29.845 11359 TRACE keystone File
"/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py", line 501, in
result2
2016-10-27 16:26:29.845 11359 TRACE keystone resp_type, resp_data,
resp_msgid, resp_ctrls = self.result3(msgid,all,timeout)
2016-10-27 16:26:29.845 11359 TRACE keystone File
"/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py", line 508, in
result3
2016-10-27 16:26:29.845 11359 TRACE keystone
resp_ctrl_classes=resp_ctrl_classes
2016-10-27 16:26:29.845 11359 TRACE keystone File
"/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py", line 515, in
result4
2016-10-27 16:26:29.845 11359 TRACE keystone ldap_result =
self._ldap_call(self._l.result4,msgid,all,timeout,add_ctrls,add_intermediates,add_extop)
2016-10-27 16:26:29.845 11359 TRACE keystone File
"/usr/local/lib/python2.7/dist-packages/ldap/ldapobject.py", line 106, in
_ldap_call
2016-10-27 16:26:29.845 11359 TRACE keystone result =
func(*args,**kwargs)
2016-10-27 16:26:29.845 11359 TRACE keystone UNDEFINED_TYPE: {'info':
'enabled: attribute type undefined', 'desc': 'Undefined attribute type'}
To manage notifications about this bug go to:
https://bugs.launchpad.net/devstack/+bug/1643301/+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 1779781] Re: virt/vmware not suport VirtualSriovEthernetCard
** Also affects: glance Importance: Undecided Status: New ** Changed in: glance Assignee: (unassigned) => yuqian (roger-yu) -- 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/1779781 Title: virt/vmware not suport VirtualSriovEthernetCard Status in Glance: New Status in OpenStack Compute (nova): New Bug description: Description === In nova/virt/vmwareapi/vm_util.py: Through the code, this type of "VirtualSriov\ EthernetCard" network card can be managed. But in fact, "VirtualSriovEthernetCard" can not be achieved through the current code architecture. Steps to reproduce == In horizon: * Choose a image that you need to launch； * Update the metadata of this image: hw_vif_model: VirtualSriovEthernetCard (hw_vif_model in `VMware Driver Options`) * Create a VM from this image; * At this time, the background of nova will report an error. Actual result = ”VirtualSriovEthernetCard“ is actually a physical NIC, unlike other virtual NICs that can directly configure properties. The sriovbacking attribute must be configured in its spec, which contains information about vf and pf. This information needs to be obtained through the vsphere client. The vf/pf information included 'system_id' which is needs to be get after vm_vmotion is created. But in current code architecture, this is impossible to achieve Environment === 1.Version: Not related to the version; 2.Hypervisor: compute_driver: vmwareapi.VMwareVCDriver; 3.Storage: Not related to the storage. 4.Networking: core_plugin: vmware_nsx.plugin.NsxDvsPlugin; Logs & Configs == 2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall [req-31efa6ac-de11-4352-bec6-49c75a0a847a 72b0403e87184504bfaec9bcff45109c e387c7a4f9fc4e1aa5be07c7e1bfba0e - default default] in fixed duration looping call: VimFaultException: Invalid configuration for device '0'. Faults: ['InvalidDeviceSpec'] 2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall Traceback (most recent call last): 2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall File "/usr/lib/python2.7/site-packages/oslo_vmware/common/loopingcall.py", line 75, in _inner 2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall self.f(*self.args, **self.kw) 2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall File "/usr/lib/python2.7/site-packages/oslo_vmware/api.py", line 452, in _poll_task 2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall raise task_ex 2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall VimFaultException: Invalid configuration for device '0'. 2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall Faults: ['InvalidDeviceSpec'] 2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall Solution == According to the logic of the code, this type of network card is available, but in fact it is confusing here. According to the current code architecture, the problem cannot be fixed. I suggest to delete the corresponding code snippet and add comments to remind users. In the future, if necessary, support this type of network card by adding BP. Here upon is my cordial suggest！ :) To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1779781/+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 1711883] Re: An error in function get_user_unique_id_and_display_name()
Reviewed: https://review.openstack.org/576433
Committed:
https://git.openstack.org/cgit/openstack/keystone/commit/?id=f4729795ecfbc53ae391204726fd441ce4b462ef
Submitter: Zuul
Branch:master
commit f4729795ecfbc53ae391204726fd441ce4b462ef
Author: Vishakha Agarwal
Date: Tue Jun 19 14:21:46 2018 +0530
Added check to avoid keyerror "user['name']"
In get_user_unique_id_and_display_name() of
keystone/auth/plugins/mapped.py, the checking
of user dict's key "name" is not very strict.
So, we need to add more strict validation here.
Change-Id: Ib147e90e4076c1c2ca7a9fd1cf8d17ce3ddc5e34
Closes-Bug: #1711883
** Changed in: keystone
Status: In Progress => Fix Released
--
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/1711883
Title:
An error in function get_user_unique_id_and_display_name()
Status in OpenStack Identity (keystone):
Fix Released
Bug description:
Firstly, see the code of function
get_user_unique_id_and_display_name() of
keystone/auth/plugins/mapped.py
# keystone/auth/plugins/mapped.py
def get_user_unique_id_and_display_name(request,
mapped_properties):
user = mapped_properties['user']
user_id = user.get('id')
user_name = user.get('name') or request.remote_user
if not any([user_id, user_name]):
msg = _("Could not map user while setting ephemeral user
identity. "
"Either mapping rules must specify user id/name or "
"REMOTE_USER environment variable must be set.")
raise exception.Unauthorized(msg)
elif not user_name:
user['name'] = user_id
elif not user_id:
user_id = user_name
user['id'] = parse.quote(user_id)
return (user['id'], user['name'])
There is an error inside above function.
If user.get('name') is None, but request.remote_user is not None, e.g.
request.remote_user is "fed_user", then user_name will be "fed_user".
So, the execution path will not go into "elif not user_name". So, for last
line "return (user['id'], user['name'])", user['name'] will raise KeyError
exception.
https://github.com/openstack/keystone/blob/682cfa5c6d135641797ec9e51299287e8191e858/keystone/auth/plugins/mapped.py#L324-L368
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1711883/+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 1779781] [NEW] virt/vmware not suport VirtualSriovEthernetCard
Public bug reported: Description === In nova/virt/vmwareapi/vm_util.py: Through the code, this type of "VirtualSriov\ EthernetCard" network card can be managed. But in fact, "VirtualSriovEthernetCard" can not be achieved through the current code architecture. Steps to reproduce == In horizon: * Choose a image that you need to launch； * Update the metadata of this image: hw_vif_model: VirtualSriovEthernetCard (hw_vif_model in `VMware Driver Options`) * Create a VM from this image; * At this time, the background of nova will report an error. Actual result = ”VirtualSriovEthernetCard“ is actually a physical NIC, unlike other virtual NICs that can directly configure properties. The sriovbacking attribute must be configured in its spec, which contains information about vf and pf. This information needs to be obtained through the vsphere client. The vf/pf information included 'system_id' which is needs to be get after vm_vmotion is created. But in current code architecture, this is impossible to achieve Environment === 1.Version: Not related to the version; 2.Hypervisor: compute_driver: vmwareapi.VMwareVCDriver; 3.Storage: Not related to the storage. 4.Networking: core_plugin: vmware_nsx.plugin.NsxDvsPlugin; Logs & Configs == 2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall [req-31efa6ac-de11-4352-bec6-49c75a0a847a 72b0403e87184504bfaec9bcff45109c e387c7a4f9fc4e1aa5be07c7e1bfba0e - default default] in fixed duration looping call: VimFaultException: Invalid configuration for device '0'. Faults: ['InvalidDeviceSpec'] 2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall Traceback (most recent call last): 2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall File "/usr/lib/python2.7/site-packages/oslo_vmware/common/loopingcall.py", line 75, in _inner 2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall self.f(*self.args, **self.kw) 2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall File "/usr/lib/python2.7/site-packages/oslo_vmware/api.py", line 452, in _poll_task 2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall raise task_ex 2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall VimFaultException: Invalid configuration for device '0'. 2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall Faults: ['InvalidDeviceSpec'] 2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall Solution == According to the logic of the code, this type of network card is available, but in fact it is confusing here. According to the current code architecture, the problem cannot be fixed. I suggest to delete the corresponding code snippet and add comments to remind users. In the future, if necessary, support this type of network card by adding BP. Here upon is my cordial suggest！ :) ** Affects: nova Importance: Undecided Assignee: yuqian (roger-yu) Status: New ** Changed in: nova Assignee: (unassigned) => yuqian (roger-yu) -- 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/1779781 Title: virt/vmware not suport VirtualSriovEthernetCard Status in OpenStack Compute (nova): New Bug description: Description === In nova/virt/vmwareapi/vm_util.py: Through the code, this type of "VirtualSriov\ EthernetCard" network card can be managed. But in fact, "VirtualSriovEthernetCard" can not be achieved through the current code architecture. Steps to reproduce == In horizon: * Choose a image that you need to launch； * Update the metadata of this image: hw_vif_model: VirtualSriovEthernetCard (hw_vif_model in `VMware Driver Options`) * Create a VM from this image; * At this time, the background of nova will report an error. Actual result = ”VirtualSriovEthernetCard“ is actually a physical NIC, unlike other virtual NICs that can directly configure properties. The sriovbacking attribute must be configured in its spec, which contains information about vf and pf. This information needs to be obtained through the vsphere client. The vf/pf information included 'system_id' which is needs to be get after vm_vmotion is created. But in current code architecture, this is impossible to achieve Environment === 1.Version: Not related to the version; 2.Hypervisor: compute_driver: vmwareapi.VMwareVCDriver; 3.Storage: Not related to the storage. 4.Networking: core_plugin: vmware_nsx.plugin.NsxDvsPlugin; Logs & Configs == 2018-07-02 19:10:41.827 9772 ERROR oslo_vmware.common.loopingcall [req-31efa6ac-de11-4352-bec6-49c75a0a847a 72b0403e87184504bfaec9bcff45109c
[Yahoo-eng-team] [Bug 1779684] Re: Call forwarded to deprecated API
** Description changed: When calling ``` openstack image list ``` - The call is forwarded to OS_FEDERATION/projects rather than auth/projects, which is deprecated. This causes it not to show all the projects in the OpenStack federation. + The call is forwarded to OS_FEDERATION/projects rather than auth/projects, which is deprecated. This causes it not to show all the projects in the OpenStack federation. version: 2.11.1 ** Changed in: glance Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1779684 Title: Call forwarded to deprecated API Status in Glance: Invalid Bug description: When calling ``` openstack image list ``` The call is forwarded to OS_FEDERATION/projects rather than auth/projects, which is deprecated. This causes it not to show all the projects in the OpenStack federation. version: 2.11.1 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1779684/+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 1779725] [NEW] Auto-created consumer record not cleaned up after failed allocation
Public bug reported:
If a call to ``PUT /allocations/{consumer}`` fails, for example with a
409 Conflict due to a resource provider or inventory being concurrently
updated, the consumer record that is auto-created in the handler before
calling AllocationList.create_all() is not being cleaned up properly.
This results in situations like bug #1778591 where a caller can get
seriously confused when attempting to retry creating allocations for a
consumer, since the retry will now expect a non-null consumer generation
when the API is called with microversion 1.28+
The solution is simple: clean up the auto-created consumer record if a
failure occurs when creating allocations for a *new* consumer.
** Affects: nova
Importance: Medium
Assignee: Jay Pipes (jaypipes)
Status: Triaged
** Tags: placement
--
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/1779725
Title:
Auto-created consumer record not cleaned up after failed allocation
Status in OpenStack Compute (nova):
Triaged
Bug description:
If a call to ``PUT /allocations/{consumer}`` fails, for example with a
409 Conflict due to a resource provider or inventory being
concurrently updated, the consumer record that is auto-created in the
handler before calling AllocationList.create_all() is not being
cleaned up properly.
This results in situations like bug #1778591 where a caller can get
seriously confused when attempting to retry creating allocations for a
consumer, since the retry will now expect a non-null consumer
generation when the API is called with microversion 1.28+
The solution is simple: clean up the auto-created consumer record if a
failure occurs when creating allocations for a *new* consumer.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1779725/+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 1749574] Re: [tracking] removal and migration of pycrypto
pycrypto was removed from most / the main openstack projects, there are still a few outliers, but nothing core. ** Changed in: openstack-requirements Importance: Undecided => High ** Changed in: openstack-requirements Status: New => 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/1749574 Title: [tracking] removal and migration of pycrypto Status in Barbican: In Progress Status in Compass: New Status in daisycloud: New Status in OpenStack Backup/Restore and DR (Freezer): New Status in Fuel for OpenStack: New Status in OpenStack Compute (nova): Triaged Status in openstack-ansible: Fix Committed Status in OpenStack Global Requirements: Fix Released Status in pyghmi: Fix Committed Status in Solum: Fix Released Status in Tatu: New Status in OpenStack DBaaS (Trove): Fix Released Bug description: trove tatu barbican compass daisycloud freezer fuel nova openstack-ansible - https://review.openstack.org/544516 pyghmi - https://review.openstack.org/569073 solum To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1749574/+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 1774710] Re: DHCP agent doesn't do anything with a network's dns_domain attribute
Reviewed: https://review.openstack.org/571546 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=137a6d61053fb1cfb9a0a583b5a5c0f6253c75e6 Submitter: Zuul Branch:master commit 137a6d61053fb1cfb9a0a583b5a5c0f6253c75e6 Author: Assaf Muller Date: Thu May 31 14:24:00 2018 -0400 Pass network's dns_domain to dnsmasq conf The Neutron API exposes the 'dns_domain' attribute on the Network model. Presently, deployments using the DHCP agent ignore this attribute when resolving DNS queries between instances. This patch changes that so that the DHCP agent will pass on the dns_domain to the network's dnsmasq process, in turn passing it to instances. UpgradeImpact Closes-Bug: 1774710 Change-Id: I6120d504959631f084d63458f6e9dada0dc5cbdf ** 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/1774710 Title: DHCP agent doesn't do anything with a network's dns_domain attribute Status in neutron: Fix Released Bug description: 0) Set up Neutron with ML2/OVS or LB, or anything that uses the DHCP agent 1) Create a network with dns_domain 2) Boot a VM on it Notice the VM doesn't have the DNS domain in it's /etc/resolv.conf In short, per-network DNS domains are not respected by the DHCP agent. The dns_domain attribute is persisted in the Neutron DB and passed on to the DHCP agent via RPC, but the agent doesn't do anything with it. Versions: Master and all previous versions. WIP fix is in https://review.openstack.org/#/c/571546. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1774710/+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 1779606] Re: Missing versioned notification examples in Python 3
Reviewed: https://review.openstack.org/579436 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=54d3e7096ca3b68af3cf5f0d30f7c0949e87c6d9 Submitter: Zuul Branch:master commit 54d3e7096ca3b68af3cf5f0d30f7c0949e87c6d9 Author: Takashi NATSUME Date: Mon Jul 2 13:59:19 2018 +0900 Fix missing versioned notification examples Python 3 is used in executing 'tox -e docs' by default currently. When Python 3 is used, there are some missing notification examples. In python 3, map function returns an iterator instead of a list, and importlib.import_module is not executed in the document generation. So it causes missing versioned notification examples in the nova docs. This patch fixes it. Change-Id: Ie4f3f9be0ca7f94ce00a14f3d825a067a807eb12 Closes-Bug: #1779606 ** Changed in: nova 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/1779606 Title: Missing versioned notification examples in Python 3 Status in OpenStack Compute (nova): Fix Released Bug description: Python 3 is used in executing 'tox -e docs' by default currently. When Python 3 is used, there are some missing notification examples. In python 3, map function returns an iterator instead of a list, and importlib.import_module(*1) is not executed in the document generation. So it causes missing versioned notification examples in the nova docs. *1: https://github.com/openstack/nova/blob/4ea64cad3fcc4897690bfb2c02d2b06d65db4dcf/doc/ext/versioned_notifications.py#L59-L61 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1779606/+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 1779717] [NEW] No ability to update consumer's project and/or user external ID
Public bug reported:
Even though in Placement API microversion 1.12, we began requiring
project and user ID in the PUT /allocations request payload, the project
ID and user ID for an *existing* consumer are never actually updated.
What this means is that if you created an allocation for consumer X
before 1.12, like so:
```
PUT /allocations/X
{
"allocations": ...
}
```
a consumer record will be created for the allocation and the project and
user ID for that consumer record will be the
CONF.placement.incomplete_consumer_project_id value (or user ID value).
If I want to set the project and user ID of the allocation's consumer to
some other value, there's no way I can do that.
If I do the following:
```
OpenStack-API-Version: placement 1.28
PUT /allocations/X
{
"allocations": ...
"consumer_generation": 1,
"project_id": $NEW_PROJECT_ID,
"user_id": $NEW_USER_ID
}
```
The $NEW_PROJECT_ID and $NEW_USER_ID values are merely ignored.
** Affects: nova
Importance: Medium
Assignee: Jay Pipes (jaypipes)
Status: Triaged
** Tags: placement
--
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/1779717
Title:
No ability to update consumer's project and/or user external ID
Status in OpenStack Compute (nova):
Triaged
Bug description:
Even though in Placement API microversion 1.12, we began requiring
project and user ID in the PUT /allocations request payload, the
project ID and user ID for an *existing* consumer are never actually
updated.
What this means is that if you created an allocation for consumer X
before 1.12, like so:
```
PUT /allocations/X
{
"allocations": ...
}
```
a consumer record will be created for the allocation and the project
and user ID for that consumer record will be the
CONF.placement.incomplete_consumer_project_id value (or user ID
value). If I want to set the project and user ID of the allocation's
consumer to some other value, there's no way I can do that.
If I do the following:
```
OpenStack-API-Version: placement 1.28
PUT /allocations/X
{
"allocations": ...
"consumer_generation": 1,
"project_id": $NEW_PROJECT_ID,
"user_id": $NEW_USER_ID
}
```
The $NEW_PROJECT_ID and $NEW_USER_ID values are merely ignored.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1779717/+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 1779711] [NEW] test_pre_live_migration_volume_backed* intermittently fails serialized json compare
Public bug reported:
Introduced in these new tests:
https://review.openstack.org/#/c/540679/
They are doing a primitive dict compare with nested dicts and the keys
can be in random orders. We need to use something like
self.assertJsonEqual.
Seen here:
http://logs.openstack.org/04/523604/21/check/openstack-tox-lower-
constraints/8a273cd/testr_results.html.gz
ft1.600:
nova.tests.unit.virt.libvirt.test_driver.LibvirtConnTestCase.test_pre_live_migration_volume_backed_StringException:
pythonlogging:'': {{{2018-06-29 18:43:57,584 WARNING
[os_brick.initiator.connectors.remotefs] Connection details not present.
RemoteFsClient may not initialize properly.}}}
stderr: {{{
/home/zuul/src/git.openstack.org/openstack/nova/nova/test.py:323:
DeprecationWarning: Using class 'MoxStubout' (either directly or via
inheritance) is deprecated in version '3.5.0'
mox_fixture = self.useFixture(moxstubout.MoxStubout())
}}}
Traceback (most recent call last):
File
"/home/zuul/src/git.openstack.org/openstack/nova/nova/tests/unit/virt/libvirt/test_driver.py",
line 11972, in test_pre_live_migration_volume_backed
self._test_pre_live_migration_volume_backed()
File
"/home/zuul/src/git.openstack.org/openstack/nova/nova/tests/unit/virt/libvirt/test_driver.py",
line 11969, in _test_pre_live_migration_volume_backed
returned_migrate_data.obj_to_primitive())
File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/lower-constraints/lib/python3.5/site-packages/testtools/testcase.py",
line 411, in assertEqual
self.assertThat(observed, matcher, message)
File
"/home/zuul/src/git.openstack.org/openstack/nova/.tox/lower-constraints/lib/python3.5/site-packages/testtools/testcase.py",
line 498, in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: !=:
reference = {'nova_object.data': {'bdms': [{'nova_object.data': {'boot_index':
None,
'bus': 'scsi',
'connection_info_json':
'{"data": '
'{"device_path": '
'"/dev/disk/path/lun-X"}, '
'"serial": '
'"53641be9-7553-4b55-b2fd-cb3cf6373505"}',
'dev': 'sda',
'format': None,
'serial':
'53641be9-7553-4b55-b2fd-cb3cf6373505',
'type': 'disk'},
'nova_object.name': 'LibvirtLiveMigrateBDMInfo',
'nova_object.namespace': 'nova',
'nova_object.version': '1.1'},
{'nova_object.data': {'boot_index': None,
'bus': 'scsi',
'connection_info_json':
'{"data": '
'{"device_path": '
'"/dev/disk/path/lun-Z"}, '
'"serial": '
'"1f5cf6f3-6afb-45d2-a4a9-7a206f3a3cf8"}',
'dev': 'sdb',
'format': None,
'serial':
'1f5cf6f3-6afb-45d2-a4a9-7a206f3a3cf8',
'type': 'disk'},
'nova_object.name': 'LibvirtLiveMigrateBDMInfo',
'nova_object.namespace': 'nova',
'nova_object.version': '1.1'}],
'block_migration': False,
'disk_available_mb': 123,
'disk_over_commit': False,
'filename': 'foo',
'image_type': 'qcow2',
'instance_relative_path': 'instance-0001',
'is_shared_block_storage': False,
'is_shared_instance_path': True,
'is_volume_backed': True,
'serial_listen_ports': [],
'src_supports_native_luks': True,
'supported_perf_events': [],
'target_connect_addr': None},
'nova_object.name': 'LibvirtLiveMigrateData',
'nova_object.namespace': 'nova',
'nova_object.version': '1.8'}
actual= {'nova_object.data': {'bdms': [{'nova_object.data':
[Yahoo-eng-team] [Bug 1678056] Re: RequestSpec records are never deleted when destroying an instance
** No longer affects: nova/newton -- 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/1678056 Title: RequestSpec records are never deleted when destroying an instance Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) ocata series: New Bug description: When an instance is created, Nova adds a record in the API DB 'request_specs' table by providing the user request. That's used by the scheduler for knowing the boot request, also when the instance is moved afterwards. That said, when destroying the instance, we don't delete the related RequestSpec record. Of course, operators could run a script for deleting them by checking the instance UUIDs, but it would be better if when an instance is hard-deleted (ie. when operators don't use [DEFAULT]/reclaim_instance_interval for restoring deleted instances), we could then delete the RequestSpec too. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1678056/+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 1779619] Re: Request Specs records did not got deleted and the table grows continuesly
*** This bug is a duplicate of bug 1678056 *** https://bugs.launchpad.net/bugs/1678056 This is already fixed, they are deleted during archive: https://github.com/openstack/nova/commit/32fd58813f8247641a6b574b5f01528b29d48b76 ** This bug has been marked a duplicate of bug 1678056 RequestSpec records are never deleted when destroying an instance -- 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/1779619 Title: Request Specs records did not got deleted and the table grows continuesly Status in OpenStack Compute (nova): New Bug description: Currently there are no logic in nova to clean the request_spec logic even when the instances related to it are gone. This will lead to the request_specs table in nova_api DB grows continuously. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1779619/+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 1779700] [NEW] The "parent_provider_uuid" response parameter for resource provider create/list/show/update is missing the 1.14 min_version flag
Public bug reported: This was unintentionally regressed here: https://review.openstack.org/#/c/548934/5/placement-api- ref/source/parameters.yaml@354 ** Affects: nova Importance: Medium Assignee: Matt Riedemann (mriedem) Status: In Progress ** Tags: api-ref placement -- 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/1779700 Title: The "parent_provider_uuid" response parameter for resource provider create/list/show/update is missing the 1.14 min_version flag Status in OpenStack Compute (nova): In Progress Bug description: This was unintentionally regressed here: https://review.openstack.org/#/c/548934/5/placement-api- ref/source/parameters.yaml@354 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1779700/+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 1779684] [NEW] Call forwarded to deprecated API
Public bug reported: When calling ``` openstack image list ``` The call is forwarded to OS_FEDERATION/projects rather than auth/projects, which is deprecated. This causes it not to show all the projects in the OpenStack federation. version: 2.11.1 ** Affects: glance Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1779684 Title: Call forwarded to deprecated API Status in Glance: New Bug description: When calling ``` openstack image list ``` The call is forwarded to OS_FEDERATION/projects rather than auth/projects, which is deprecated. This causes it not to show all the projects in the OpenStack federation. version: 2.11.1 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1779684/+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 1779672] [NEW] netdev_pformat key error on FreeBSD with 18.3
Public bug reported:
i am running cloud-init on commit id
c42a926ae730994f66fe87c264b65f6e4dca69a1 against a FreeBSD 10.4 Host an
getting the following stacktrace:
2018-07-02 11:40:18,158 - util.py[DEBUG]: Cloud-init v. 18.3 running 'init' at
Mon, 02 Jul 2018 11:40:18 +. Up 20.11459589 seconds.
2018-07-02 11:40:18,159 - main.py[DEBUG]: No kernel command line url found.
2018-07-02 11:40:18,159 - main.py[DEBUG]: Closing stdin.
2018-07-02 11:40:18,172 - util.py[DEBUG]: Writing to /var/log/cloud-init.log -
ab: [644] 0 bytes
2018-07-02 11:40:18,175 - util.py[DEBUG]: Changing the ownership of
/var/log/cloud-init.log to 0:0
2018-07-02 11:40:18,175 - util.py[DEBUG]: Running command ['ifconfig', '-a']
with allowed return codes [0, 1] (shell=False, capture=True)
2018-07-02 11:40:18,195 - util.py[WARNING]: failed stage init
2018-07-02 11:40:18,196 - util.py[DEBUG]: failed stage init
Traceback (most recent call last):
File
"/usr/local/lib/python2.7/site-packages/cloud_init-18.3-py2.7.egg/cloudinit/cmd/main.py",
line 655, in status_wrapper
ret = functor(name, args)
File
"/usr/local/lib/python2.7/site-packages/cloud_init-18.3-py2.7.egg/cloudinit/cmd/main.py",
line 284, in main_init
sys.stderr.write("%s\n" % (netinfo.debug_info()))
File
"/usr/local/lib/python2.7/site-packages/cloud_init-18.3-py2.7.egg/cloudinit/netinfo.py",
line 447, in debug_info
netdev_lines = netdev_pformat().splitlines()
File
"/usr/local/lib/python2.7/site-packages/cloud_init-18.3-py2.7.egg/cloudinit/netinfo.py",
line 392, in netdev_pformat
(dev, data["up"], addr["ip"], empty, addr["scope6"],
KeyError: 'scope6'
2018-07-02 11:40:18,204 - util.py[DEBUG]: cloud-init mode 'init' took 0.142
seconds (0.14)
2018-07-02 11:40:18,205 - handlers.py[DEBUG]: finish: init-network: SUCCESS:
searching for network datasources
The interface setup on the host is like:
root@host-10-1-80-61:~ # ifconfig -a
vtnet0: flags=8843 metric 0 mtu 1500
options=6c07bb
ether fa:16:3e:14:1f:99
hwaddr fa:16:3e:14:1f:99
inet 10.1.80.61 netmask 0xf000 broadcast 10.1.95.255
nd6 options=29
media: Ethernet 10Gbase-T
status: active
pflog0: flags=0<> metric 0 mtu 33160
pfsync0: flags=0<> metric 0 mtu 1500
syncpeer: 0.0.0.0 maxupd: 128 defer: off
lo0: flags=8049 metric 0 mtu 16384
options=63
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
inet 127.0.0.1 netmask 0xff00
nd6 options=21
with previous 18.2 release i did not have any problems.
** Affects: cloud-init
Importance: Undecided
Status: New
** Tags: freebsd
** Tags added: freebsd
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1779672
Title:
netdev_pformat key error on FreeBSD with 18.3
Status in cloud-init:
New
Bug description:
i am running cloud-init on commit id
c42a926ae730994f66fe87c264b65f6e4dca69a1 against a FreeBSD 10.4 Host
an getting the following stacktrace:
2018-07-02 11:40:18,158 - util.py[DEBUG]: Cloud-init v. 18.3 running 'init'
at Mon, 02 Jul 2018 11:40:18 +. Up 20.11459589 seconds.
2018-07-02 11:40:18,159 - main.py[DEBUG]: No kernel command line url found.
2018-07-02 11:40:18,159 - main.py[DEBUG]: Closing stdin.
2018-07-02 11:40:18,172 - util.py[DEBUG]: Writing to /var/log/cloud-init.log
- ab: [644] 0 bytes
2018-07-02 11:40:18,175 - util.py[DEBUG]: Changing the ownership of
/var/log/cloud-init.log to 0:0
2018-07-02 11:40:18,175 - util.py[DEBUG]: Running command ['ifconfig', '-a']
with allowed return codes [0, 1] (shell=False, capture=True)
2018-07-02 11:40:18,195 - util.py[WARNING]: failed stage init
2018-07-02 11:40:18,196 - util.py[DEBUG]: failed stage init
Traceback (most recent call last):
File
"/usr/local/lib/python2.7/site-packages/cloud_init-18.3-py2.7.egg/cloudinit/cmd/main.py",
line 655, in status_wrapper
ret = functor(name, args)
File
"/usr/local/lib/python2.7/site-packages/cloud_init-18.3-py2.7.egg/cloudinit/cmd/main.py",
line 284, in main_init
sys.stderr.write("%s\n" % (netinfo.debug_info()))
File
"/usr/local/lib/python2.7/site-packages/cloud_init-18.3-py2.7.egg/cloudinit/netinfo.py",
line 447, in debug_info
netdev_lines = netdev_pformat().splitlines()
File
"/usr/local/lib/python2.7/site-packages/cloud_init-18.3-py2.7.egg/cloudinit/netinfo.py",
line 392, in netdev_pformat
(dev, data["up"], addr["ip"], empty, addr["scope6"],
KeyError: 'scope6'
2018-07-02 11:40:18,204 - util.py[DEBUG]: cloud-init mode 'init' took 0.142
seconds (0.14)
2018-07-02 11:40:18,205 - handlers.py[DEBUG]: finish: init-network: SUCCESS:
searching for network datasources
The interface setup on the host is like:
root@host-10-1-80-61:~ # ifconfig -a
vtnet0: flags=8843 metric 0 mtu 1500
options=6c07bb
ether
[Yahoo-eng-team] [Bug 1779669] [NEW] Horizon not able to distinguish between simple tenant and address scope networks
Public bug reported: Description of problem: Horizon not able to distinguish between simple tenant and address scope networks in Network topology tab. However in "Networks" tab it does show the difference between simple and subnet pool network. How reproducible: Everytime. Steps to Reproduce: 1. Create neutron address scopes along with simple tenant network. 2. Go to horizon dashboard "network --> Network Topology" it's showing simple tenant and subnet pools in address scope as similar kind of network. It creates confusion because they are L3 separated networks. 3. Actual results: Showing subnet pools and simple tenant networks in similar way. Expected results: It should show subnet pools in different way. Clarifying info: "The requirement is the ability to identify the networks/subnets which are 'address scoped' from horizon dashboard in Network topology tab." ** 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/1779669 Title: Horizon not able to distinguish between simple tenant and address scope networks Status in OpenStack Dashboard (Horizon): New Bug description: Description of problem: Horizon not able to distinguish between simple tenant and address scope networks in Network topology tab. However in "Networks" tab it does show the difference between simple and subnet pool network. How reproducible: Everytime. Steps to Reproduce: 1. Create neutron address scopes along with simple tenant network. 2. Go to horizon dashboard "network --> Network Topology" it's showing simple tenant and subnet pools in address scope as similar kind of network. It creates confusion because they are L3 separated networks. 3. Actual results: Showing subnet pools and simple tenant networks in similar way. Expected results: It should show subnet pools in different way. Clarifying info: "The requirement is the ability to identify the networks/subnets which are 'address scoped' from horizon dashboard in Network topology tab." To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1779669/+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 1777458] Re: Listing instances with a marker that is in the build_requests table and the ip/ip6 filters results in an error
Reviewed: https://review.openstack.org/576161 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=8cea14abf30c40da4ce5ffcfb4fb37dd79083255 Submitter: Zuul Branch:master commit 8cea14abf30c40da4ce5ffcfb4fb37dd79083255 Author: Matt Riedemann Date: Mon Jun 18 10:27:43 2018 -0400 Fix regression when listing build_requests with marker and ip filter Change Ic02206e887e3fea7752d615bbed680510c482097 attempted to optimize the GET /servers flow by skipping filtering on build requests if the ip or ip6 filters were used, since servers that are not yet scheduled (build requests) can't have ips. However, if a marker is provided and the marker is in the build_requests table, we fail to look there and then check the cells for the marker, which won't exist and result in a 400 MarkerNotFound error. This fixes the issue by *not* skipping build requests if there is a marker specified. A functional test is added which will show the 400 MarkerNotFound error if the code fix is removed. Change-Id: Ibdd157d06252c3c0219539ec798c8d9d3a8ae26f Closes-Bug: #1777458 ** Changed in: nova 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/1777458 Title: Listing instances with a marker that is in the build_requests table and the ip/ip6 filters results in an error Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) queens series: Confirmed Bug description: This is very similar to bug 1773945 but has a specific recreate: 1. create server 2. while it's a build request (before scheduling), immediately list servers with the id from server in #1 as the marker and filter using the 'ip' filter - it doesn't matter what the value is Due to change https://review.openstack.org/#/c/539469/ this will bypass the build_requests table because of the ip filter and then attempt to look for the marker in the cell database instances tables, and not find it and fail with a 400 error. If you do this on top of change https://review.openstack.org/#/c/575556/ then it's a 500 error. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1777458/+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 1653587] Re: Images tab not showing the available images
If the issue still exists with current devstack, please describe the steps needed to reproduce. ** Changed in: devstack Status: Confirmed => Invalid -- 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/1653587 Title: Images tab not showing the available images Status in devstack: Invalid Status in OpenStack Dashboard (Horizon): Invalid Bug description: After installing the devstack, when we click on images tab of dashboard , it is showing the blank page. With cli it is ok To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1653587/+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 1778734] Re: nova-manage api_db sync uses the wrong version option when synchronizing the placement database
Reviewed: https://review.openstack.org/579200 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=dd4e9496d37f2bc27763926327d45df01fd08a05 Submitter: Zuul Branch:master commit dd4e9496d37f2bc27763926327d45df01fd08a05 Author: Chris Dent Date: Fri Jun 29 16:38:43 2018 +0100 Use 'version2' when syncing placement db The original code was started before the version2 variable existed. Somewhere along the way the change was missed in a merge. This corrects the migration.db_sync call to use the right version. Change-Id: I1c0c9bbd9a2595822d74d2b82e26c39b60ca1822 Closes-Bug: #1778734 ** Changed in: nova 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/1778734 Title: nova-manage api_db sync uses the wrong version option when synchronizing the placement database Status in OpenStack Compute (nova): Fix Released Bug description: https://github.com/openstack/nova/blob/b992b90d73ab745b41924db9c2173f6cecb9d85e/nova/cmd/manage.py#L859 That should be using the "version2" parameter since the "version" parameter is deprecated. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1778734/+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 1779626] [NEW] MTU setting feature conflicts with minimum Qemu version
Public bug reported: Afaics Nova breaks with Qemu versions newer than the minimum required version. The change at [1] added support for setting MTU size in the libvirt settings of guests. This code checks for a minimum libvirt version 3.3.0 [2] but not for a required Qemu version. The Nova minimum required Qemu version is 2.5 currently according to [3] (which is the latest release available with Ubuntu Xenial 16.04). Afaics Qemu added support with release 2.9 [4] which means versions 2.5 to 2.8 of Qemu will break despite being listed as supported iiuc. This issue broke our CIs. For verification i checked the master commit [5] which merged prior to [1] which tested ok with our CI. The fix probably is to simply add a check for the minimum required Qemu version beside the minimum required libvirt version. [1] https://review.openstack.org/#/c/553072/ [2] https://github.com/openstack/nova/blob/4ea64cad3fcc4897690bfb2c02d2b06d65db4dcf/nova/virt/libvirt/vif.py#L55 [3] https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix [4] https://wiki.qemu.org/ChangeLog/2.9) [5] https://review.openstack.org/#/c/570656/ ** 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/1779626 Title: MTU setting feature conflicts with minimum Qemu version Status in OpenStack Compute (nova): New Bug description: Afaics Nova breaks with Qemu versions newer than the minimum required version. The change at [1] added support for setting MTU size in the libvirt settings of guests. This code checks for a minimum libvirt version 3.3.0 [2] but not for a required Qemu version. The Nova minimum required Qemu version is 2.5 currently according to [3] (which is the latest release available with Ubuntu Xenial 16.04). Afaics Qemu added support with release 2.9 [4] which means versions 2.5 to 2.8 of Qemu will break despite being listed as supported iiuc. This issue broke our CIs. For verification i checked the master commit [5] which merged prior to [1] which tested ok with our CI. The fix probably is to simply add a check for the minimum required Qemu version beside the minimum required libvirt version. [1] https://review.openstack.org/#/c/553072/ [2] https://github.com/openstack/nova/blob/4ea64cad3fcc4897690bfb2c02d2b06d65db4dcf/nova/virt/libvirt/vif.py#L55 [3] https://wiki.openstack.org/wiki/LibvirtDistroSupportMatrix [4] https://wiki.qemu.org/ChangeLog/2.9) [5] https://review.openstack.org/#/c/570656/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1779626/+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 1779635] [NEW] placement allows RP parent loop in PUT resource_providers/{uuid}
Public bug reported:
Placement allows setting the parent_rp_uuid of an RP to itself. This
leads to a trivial loop in the RP tree.
Version, current master:
stack@ubuntu:~/nova$ git log --oneline | head -n1
4ea64ca Merge "manage: Remove dead code"
To reproduce in devstack I used a not yet merged osc-placement patch
adding support to api version 1.14.
Steps:
stack@ubuntu:~/osc-placement$ openstack --debug resource provider list
--os-placement-api-version 1.14
+--+++--+--+
| uuid | name | generation |
root_provider_uuid | parent_provider_uuid |
+--+++--+--+
| f4d95373-b15f-4dd9-94ed-f7908fe10dd1 | ubuntu | 1 |
f4d95373-b15f-4dd9-94ed-f7908fe10dd1 | None |
+--+++--+--+
stack@ubuntu:~/osc-placement$ openstack --debug resource provider --os-
placement-api-version 1.14 set f4d95373-b15f-4dd9-94ed-f7908fe10dd1
--name ubuntu --parent-provider-uuid f4d95373-b15f-4dd9-94ed-
f7908fe10dd1
+--+--+
| Field| Value|
+--+--+
| uuid | f4d95373-b15f-4dd9-94ed-f7908fe10dd1 |
| name | ubuntu |
| generation | 1|
| root_provider_uuid | f4d95373-b15f-4dd9-94ed-f7908fe10dd1 |
| parent_provider_uuid | f4d95373-b15f-4dd9-94ed-f7908fe10dd1 |
+--+--+
stack@ubuntu:~/osc-placement$ openstack --debug resource provider list
--os-placement-api-version 1.14
+--+++--+--+
| uuid | name | generation |
root_provider_uuid | parent_provider_uuid |
+--+++--+--+
| f4d95373-b15f-4dd9-94ed-f7908fe10dd1 | ubuntu | 1 |
f4d95373-b15f-4dd9-94ed-f7908fe10dd1 | f4d95373-b15f-4dd9-94ed-f7908fe10dd1 |
+--+++--+--+
Full debug output with has been attached.
** Affects: nova
Importance: Undecided
Status: New
** Tags: placement
** Tags added: placement
--
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/1779635
Title:
placement allows RP parent loop in PUT resource_providers/{uuid}
Status in OpenStack Compute (nova):
New
Bug description:
Placement allows setting the parent_rp_uuid of an RP to itself. This
leads to a trivial loop in the RP tree.
Version, current master:
stack@ubuntu:~/nova$ git log --oneline | head -n1
4ea64ca Merge "manage: Remove dead code"
To reproduce in devstack I used a not yet merged osc-placement patch
adding support to api version 1.14.
Steps:
stack@ubuntu:~/osc-placement$ openstack --debug resource provider list
--os-placement-api-version 1.14
+--+++--+--+
| uuid | name | generation |
root_provider_uuid | parent_provider_uuid |
+--+++--+--+
| f4d95373-b15f-4dd9-94ed-f7908fe10dd1 | ubuntu | 1 |
f4d95373-b15f-4dd9-94ed-f7908fe10dd1 | None |
+--+++--+--+
stack@ubuntu:~/osc-placement$ openstack --debug resource provider
--os-placement-api-version 1.14 set f4d95373-b15f-4dd9-94ed-
f7908fe10dd1 --name ubuntu --parent-provider-uuid f4d95373-b15f-4dd9
-94ed-f7908fe10dd1
+--+--+
| Field| Value|
+--+--+
| uuid | f4d95373-b15f-4dd9-94ed-f7908fe10dd1 |
| name | ubuntu |
| generation | 1|
| root_provider_uuid | f4d95373-b15f-4dd9-94ed-f7908fe10dd1 |
| parent_provider_uuid |
[Yahoo-eng-team] [Bug 1779619] [NEW] Request Specs records did not got deleted and the table grows continuesly
Public bug reported: Currently there are no logic in nova to clean the request_spec logic even when the instances related to it are gone. This will lead to the request_specs table in nova_api DB grows continuously. ** Affects: nova Importance: Undecided Assignee: Zhenyu Zheng (zhengzhenyu) Status: New ** Changed in: nova Assignee: (unassigned) => Zhenyu Zheng (zhengzhenyu) -- 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/1779619 Title: Request Specs records did not got deleted and the table grows continuesly Status in OpenStack Compute (nova): New Bug description: Currently there are no logic in nova to clean the request_spec logic even when the instances related to it are gone. This will lead to the request_specs table in nova_api DB grows continuously. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1779619/+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
