[Yahoo-eng-team] [Bug 1968645] Re: Concurrent migration of vms with the same multiattach volume fails
** Also 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/1968645
Title:
Concurrent migration of vms with the same multiattach volume fails
Status in Cinder:
New
Status in OpenStack Compute (nova):
New
Bug description:
reproduce：
1. Create multiple vms
2. Create a multiattach volume
3. Attach the volume to all vms
4. Shut down all vms and migrate all vms at the same time
5. It is possible to find that a vm migration failed
The nova-compute log is as follows：
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager
[req-95d6268a-95eb-4ea2-98e0-a9e973b8f19c cb6c975e503c4b1ca741f64a42d09d50
68dd5eeecb434da0aa5ebcdda19a8db6 - default default] [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] Setting instance vm_state to ERROR:
nova.exception.InvalidInput: Invalid input received: Invalid volume: Volume
e269257b-831e-4be0-a1e6-fbb2aac922a6 status must be available or in-use or
downloading to reserve, but the current status is attaching. (HTTP 400)
(Request-ID: req-3515d919-aee2-40f4-887e-d5abb34a9d2e)
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] Traceback (most recent call last):
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] File
"/usr/local/lib/python3.6/site-packages/nova/volume/cinder.py", line 396, in
wrapper
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] res = method(self, ctx, *args,
**kwargs)
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] File
"/usr/local/lib/python3.6/site-packages/nova/volume/cinder.py", line 432, in
wrapper
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] res = method(self, ctx, volume_id,
*args, **kwargs)
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] File
"/usr/local/lib/python3.6/site-packages/nova/volume/cinder.py", line 807, in
attachment_create
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] instance_uuid=instance_id)
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] File
"/usr/local/lib/python3.6/site-packages/oslo_utils/excutils.py", line 227, in
__exit__
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] self.force_reraise()
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] File
"/usr/local/lib/python3.6/site-packages/oslo_utils/excutils.py", line 200, in
force_reraise
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] raise self.value
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] File
"/usr/local/lib/python3.6/site-packages/nova/volume/cinder.py", line 795, in
attachment_create
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] volume_id, _connector, instance_id)
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] File
"/usr/local/lib/python3.6/site-packages/cinderclient/api_versions.py", line
423, in substitution
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] return method.func(obj, *args,
**kwargs)
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] File
"/usr/local/lib/python3.6/site-packages/cinderclient/v3/attachments.py", line
39, in create
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] retval = self._create('/attachments',
body, 'attachment')
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] File
"/usr/local/lib/python3.6/site-packages/cinderclient/base.py", line 300, in
_create
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] resp, body =
self.api.client.post(url, body=body)
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] File
"/usr/local/lib/python3.6/site-packages/cinderclient/client.py", line 217, in
post
2022-04-11 16:49:46.685 23871 ERROR nova.compute.manager [instance:
17fc694e-284a-43f0-b6c6-c640a02db23d] return self._cs_request(url, 'POST',
**kwargs)
2022-04-11 16:49:46.685
[Yahoo-eng-team] [Bug 1602081] Re: Use oslo.context's policy dict
** No longer affects: taskflow ** No longer affects: os-brick ** No longer affects: glance-store -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1602081 Title: Use oslo.context's policy dict Status in Cinder: In Progress Status in Glance: Fix Released Status in heat: Fix Released Status in neutron: In Progress Status in OpenStack Compute (nova): In Progress Bug description: This is a cross project goal to standardize the values available to policy writers and to improve the basic oslo.context object. It is part of the follow up work to bug #1577996 and bug #968696. There has been an ongoing problem for how we define the 'admin' role. Because tokens are project scoped having the 'admin' role on any project granted you the 'admin' role on all of OpenStack. As a solution to this keystone defined an is_admin_project field so that keystone defines a single project that your token must be scoped to to perform admin operations. This has been implemented. The next phase of this is to make all the projects understand the X -Is-Admin-Project header from keystonemiddleware and pass it to oslo_policy. However this pattern of keystone changes something and then goes to every project to fix it has been repeated a number of times now and we would like to make it much more automatic. Ongoing work has enhanced the base oslo.context object to include both the load_from_environ and to_policy_values methods. The load_from_environ classmethod takes an environment dict with all the standard auth_token and oslo middleware headers and loads them into their standard place on the context object. The to_policy_values() then creates a standard credentials dictionary with all the information that should be required to enforce policy from the context. The combination of these two methods means in future when authentication information needs to be passed to policy it can be handled entirely by oslo.context and does not require changes in each individual service. Note that in future a similar pattern will hopefully be employed to simplify passing authentication information over RPC to solve the timeout issues. This is a prerequisite for that work. There are a few common problems in services that are required to make this work: 1. Most service context.__init__ functions take and discard **kwargs. This is so if the context.from_dict receives arguments it doesn't know how to handle (possibly because new things have been added to the base to_dict) it ignores them. Unfortunately to make the load_from_environ method work we need to pass parameters to __init__ that are handled by the base class. To make this work we simply have to do a better job of using from_dict. Instead of passing everything to __init__ and ignoring what we don't know we have from_dict extract only the parameters that context knows how to use and call __init__ with those. 2. The parameters passed to the base context.__init__ are old. Typically they are user and tenant where most services expect user_id and project_id. There is ongoing work to improve this in oslo.context but for now we have to ensure that the subclass correctly sets and uses the right variable names. 3. Some services provide additional information to the policy enforcement method. To continue to make this function we will simply override the to_policy_values method in the subclasses. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1602081/+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 1596829] Re: String interpolation should be delayed at logging calls
** No longer affects: swift
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1596829
Title:
String interpolation should be delayed at logging calls
Status in Ceilometer:
New
Status in congress:
Fix Released
Status in Glance:
In Progress
Status in glance_store:
In Progress
Status in heat:
New
Status in Ironic:
Fix Released
Status in masakari:
Fix Released
Status in networking-vsphere:
Fix Released
Status in neutron:
Fix Released
Status in OpenStack Compute (nova):
In Progress
Status in os-brick:
Fix Released
Status in os-vif:
Fix Released
Status in python-cinderclient:
Fix Released
Status in python-glanceclient:
Fix Released
Status in python-neutronclient:
Fix Released
Bug description:
String interpolation should be delayed to be handled by the logging
code, rather than being done at the point of the logging call.
Wrong: LOG.debug('Example: %s' % 'bad')
Right: LOG.debug('Example: %s', 'good')
See the following guideline.
* http://docs.openstack.org/developer/oslo.i18n/guidelines.html
#adding-variables-to-log-messages
The rule for it should be added to hacking checks.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1596829/+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 1596829] Re: String interpolation should be delayed at logging calls
** No longer affects: taskflow
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1596829
Title:
String interpolation should be delayed at logging calls
Status in Ceilometer:
New
Status in congress:
Fix Released
Status in Glance:
In Progress
Status in glance_store:
In Progress
Status in heat:
New
Status in Ironic:
Fix Released
Status in masakari:
Fix Released
Status in networking-vsphere:
Fix Released
Status in neutron:
Fix Released
Status in OpenStack Compute (nova):
In Progress
Status in os-brick:
Fix Released
Status in os-vif:
Fix Released
Status in python-cinderclient:
Fix Released
Status in python-glanceclient:
Fix Released
Status in python-neutronclient:
Fix Released
Bug description:
String interpolation should be delayed to be handled by the logging
code, rather than being done at the point of the logging call.
Wrong: LOG.debug('Example: %s' % 'bad')
Right: LOG.debug('Example: %s', 'good')
See the following guideline.
* http://docs.openstack.org/developer/oslo.i18n/guidelines.html
#adding-variables-to-log-messages
The rule for it should be added to hacking checks.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1596829/+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 1596829] Re: String interpolation should be delayed at logging calls
** Also affects: python-cinderclient
Importance: Undecided
Status: New
** Changed in: python-cinderclient
Assignee: (unassigned) => haobing1 (haobing1)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1596829
Title:
String interpolation should be delayed at logging calls
Status in Ceilometer:
New
Status in Glance:
In Progress
Status in glance_store:
New
Status in heat:
New
Status in Ironic:
New
Status in OpenStack Identity (keystone):
New
Status in networking-vsphere:
Fix Released
Status in neutron:
Fix Released
Status in OpenStack Compute (nova):
In Progress
Status in os-brick:
Fix Released
Status in python-cinderclient:
New
Status in python-glanceclient:
In Progress
Status in OpenStack Object Storage (swift):
New
Status in taskflow:
New
Bug description:
String interpolation should be delayed to be handled by the logging
code, rather than being done at the point of the logging call.
Wrong: LOG.debug('Example: %s' % 'bad')
Right: LOG.debug('Example: %s', 'good')
See the following guideline.
* http://docs.openstack.org/developer/oslo.i18n/guidelines.html
#adding-variables-to-log-messages
The rule for it should be added to hacking checks.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1596829/+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 1596829] Re: String interpolation should be delayed at logging calls
** No longer affects: python-cinderclient
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1596829
Title:
String interpolation should be delayed at logging calls
Status in Ceilometer:
New
Status in Glance:
In Progress
Status in glance_store:
New
Status in heat:
New
Status in Ironic:
New
Status in OpenStack Identity (keystone):
New
Status in networking-vsphere:
Fix Released
Status in neutron:
Fix Released
Status in OpenStack Compute (nova):
In Progress
Status in os-brick:
Fix Released
Status in python-glanceclient:
In Progress
Status in OpenStack Object Storage (swift):
New
Status in taskflow:
New
Bug description:
String interpolation should be delayed to be handled by the logging
code, rather than being done at the point of the logging call.
Wrong: LOG.debug('Example: %s' % 'bad')
Right: LOG.debug('Example: %s', 'good')
See the following guideline.
* http://docs.openstack.org/developer/oslo.i18n/guidelines.html
#adding-variables-to-log-messages
The rule for it should be added to hacking checks.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1596829/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests
** No longer affects: ceilometer -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to anvil. https://bugs.launchpad.net/bugs/1280522 Title: Replace assertEqual(None, *) with assertIsNone in tests Status in Anchor: Fix Released Status in anvil: New Status in bifrost: Fix Released Status in Blazar: In Progress Status in Cinder: Fix Released Status in congress: Fix Released Status in Designate: Fix Released Status in dox: New Status in DragonFlow: New Status in Freezer: New Status in Glance: Fix Released Status in glance_store: Fix Released Status in heat: Fix Released Status in heat-cfntools: Fix Released Status in Heat Translator: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in keystoneauth: Fix Released Status in kolla-mesos: Fix Released Status in Manila: Fix Released Status in networking-brocade: New Status in networking-cisco: Fix Released Status in OpenStack Compute (nova): Fix Released Status in octavia: Fix Released Status in ooi: Fix Released Status in os-brick: Fix Released Status in os-client-config: Fix Released Status in oslo.messaging: Fix Released Status in python-barbicanclient: Fix Released Status in python-ceilometerclient: Fix Released Status in python-cinderclient: Fix Released Status in python-congressclient: Fix Released Status in python-cueclient: Fix Released Status in python-designateclient: Fix Released Status in python-glanceclient: Fix Released Status in python-heatclient: Fix Released Status in python-ironicclient: Fix Released Status in python-manilaclient: Fix Released Status in python-neutronclient: Fix Released Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Released Status in python-swiftclient: Fix Released Status in python-troveclient: Fix Released Status in Python client library for Zaqar: Fix Released Status in Quark: Money Reinvented: New Status in Sahara: Fix Released Status in OpenStack Search (Searchlight): Fix Released Status in Solum: Fix Released Status in Stackalytics: Fix Released Status in OpenStack Object Storage (swift): Invalid Status in taskflow: In Progress Status in tempest: Fix Released Status in OpenStack DBaaS (Trove): Fix Released Status in tuskar: Fix Released Status in watcher: Fix Released Status in zaqar: Fix Released Status in designate package in Ubuntu: Fix Released Status in python-tuskarclient package in Ubuntu: Fix Committed Bug description: Replace assertEqual(None, *) with assertIsNone in tests to have more clear messages in case of failure. To manage notifications about this bug go to: https://bugs.launchpad.net/anchor/+bug/1280522/+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 1602081] Re: Use oslo.context's policy dict
** Also affects: glance-store Importance: Undecided Status: New ** Changed in: glance-store Assignee: (unassigned) => haobing1 (haobing1) ** Also affects: os-brick Importance: Undecided Status: New ** Changed in: os-brick Assignee: (unassigned) => haobing1 (haobing1) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1602081 Title: Use oslo.context's policy dict Status in Cinder: In Progress Status in Glance: Fix Released Status in glance_store: New Status in heat: In Progress Status in neutron: Triaged Status in OpenStack Compute (nova): In Progress Status in os-brick: New Status in taskflow: New Bug description: This is a cross project goal to standardize the values available to policy writers and to improve the basic oslo.context object. It is part of the follow up work to bug #1577996 and bug #968696. There has been an ongoing problem for how we define the 'admin' role. Because tokens are project scoped having the 'admin' role on any project granted you the 'admin' role on all of OpenStack. As a solution to this keystone defined an is_admin_project field so that keystone defines a single project that your token must be scoped to to perform admin operations. This has been implemented. The next phase of this is to make all the projects understand the X -Is-Admin-Project header from keystonemiddleware and pass it to oslo_policy. However this pattern of keystone changes something and then goes to every project to fix it has been repeated a number of times now and we would like to make it much more automatic. Ongoing work has enhanced the base oslo.context object to include both the load_from_environ and to_policy_values methods. The load_from_environ classmethod takes an environment dict with all the standard auth_token and oslo middleware headers and loads them into their standard place on the context object. The to_policy_values() then creates a standard credentials dictionary with all the information that should be required to enforce policy from the context. The combination of these two methods means in future when authentication information needs to be passed to policy it can be handled entirely by oslo.context and does not require changes in each individual service. Note that in future a similar pattern will hopefully be employed to simplify passing authentication information over RPC to solve the timeout issues. This is a prerequisite for that work. There are a few common problems in services that are required to make this work: 1. Most service context.__init__ functions take and discard **kwargs. This is so if the context.from_dict receives arguments it doesn't know how to handle (possibly because new things have been added to the base to_dict) it ignores them. Unfortunately to make the load_from_environ method work we need to pass parameters to __init__ that are handled by the base class. To make this work we simply have to do a better job of using from_dict. Instead of passing everything to __init__ and ignoring what we don't know we have from_dict extract only the parameters that context knows how to use and call __init__ with those. 2. The parameters passed to the base context.__init__ are old. Typically they are user and tenant where most services expect user_id and project_id. There is ongoing work to improve this in oslo.context but for now we have to ensure that the subclass correctly sets and uses the right variable names. 3. Some services provide additional information to the policy enforcement method. To continue to make this function we will simply override the to_policy_values method in the subclasses. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1602081/+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 1596829] Re: String interpolation should be delayed at logging calls
** Also affects: taskflow
Importance: Undecided
Status: New
** Changed in: taskflow
Assignee: (unassigned) => haobing1 (haobing1)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1596829
Title:
String interpolation should be delayed at logging calls
Status in Ceilometer:
New
Status in Cinder:
New
Status in Glance:
New
Status in glance_store:
New
Status in heat:
New
Status in Ironic:
New
Status in OpenStack Identity (keystone):
New
Status in neutron:
In Progress
Status in OpenStack Compute (nova):
In Progress
Status in os-brick:
New
Status in python-cinderclient:
New
Status in python-glanceclient:
New
Status in OpenStack Object Storage (swift):
New
Status in taskflow:
New
Bug description:
String interpolation should be delayed to be handled by the logging
code, rather than being done at the point of the logging call.
Wrong: LOG.debug('Example: %s' % 'bad')
Right: LOG.debug('Example: %s', 'good')
See the following guideline.
* http://docs.openstack.org/developer/oslo.i18n/guidelines.html
#adding-variables-to-log-messages
The rule for it should be added to hacking checks.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1596829/+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 1602081] Re: Use oslo.context's policy dict
** Also affects: taskflow Importance: Undecided Status: New ** Changed in: taskflow Assignee: (unassigned) => haobing1 (haobing1) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1602081 Title: Use oslo.context's policy dict Status in Cinder: In Progress Status in Glance: New Status in heat: In Progress Status in neutron: New Status in OpenStack Compute (nova): New Status in taskflow: New Bug description: This is a cross project goal to standardize the values available to policy writers and to improve the basic oslo.context object. It is part of the follow up work to bug #1577996 and bug #968696. There has been an ongoing problem for how we define the 'admin' role. Because tokens are project scoped having the 'admin' role on any project granted you the 'admin' role on all of OpenStack. As a solution to this keystone defined an is_admin_project field so that keystone defines a single project that your token must be scoped to to perform admin operations. This has been implemented. The next phase of this is to make all the projects understand the X -Is-Admin-Project header from keystonemiddleware and pass it to oslo_policy. However this pattern of keystone changes something and then goes to every project to fix it has been repeated a number of times now and we would like to make it much more automatic. Ongoing work has enhanced the base oslo.context object to include both the load_from_environ and to_policy_values methods. The load_from_environ classmethod takes an environment dict with all the standard auth_token and oslo middleware headers and loads them into their standard place on the context object. The to_policy_values() then creates a standard credentials dictionary with all the information that should be required to enforce policy from the context. The combination of these two methods means in future when authentication information needs to be passed to policy it can be handled entirely by oslo.context and does not require changes in each individual service. Note that in future a similar pattern will hopefully be employed to simplify passing authentication information over RPC to solve the timeout issues. This is a prerequisite for that work. There are a few common problems in services that are required to make this work: 1. Most service context.__init__ functions take and discard **kwargs. This is so if the context.from_dict receives arguments it doesn't know how to handle (possibly because new things have been added to the base to_dict) it ignores them. Unfortunately to make the load_from_environ method work we need to pass parameters to __init__ that are handled by the base class. To make this work we simply have to do a better job of using from_dict. Instead of passing everything to __init__ and ignoring what we don't know we have from_dict extract only the parameters that context knows how to use and call __init__ with those. 2. The parameters passed to the base context.__init__ are old. Typically they are user and tenant where most services expect user_id and project_id. There is ongoing work to improve this in oslo.context but for now we have to ensure that the subclass correctly sets and uses the right variable names. 3. Some services provide additional information to the policy enforcement method. To continue to make this function we will simply override the to_policy_values method in the subclasses. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1602081/+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 1596829] Re: String interpolation should be delayed at logging calls
** Also affects: swift
Importance: Undecided
Status: New
** Changed in: swift
Assignee: (unassigned) => haobing1 (haobing1)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1596829
Title:
String interpolation should be delayed at logging calls
Status in Ceilometer:
New
Status in Cinder:
New
Status in Glance:
New
Status in glance_store:
New
Status in heat:
New
Status in Ironic:
New
Status in OpenStack Identity (keystone):
New
Status in neutron:
In Progress
Status in OpenStack Compute (nova):
In Progress
Status in os-brick:
New
Status in python-cinderclient:
New
Status in python-glanceclient:
New
Status in OpenStack Object Storage (swift):
New
Bug description:
String interpolation should be delayed to be handled by the logging
code, rather than being done at the point of the logging call.
Wrong: LOG.debug('Example: %s' % 'bad')
Right: LOG.debug('Example: %s', 'good')
See the following guideline.
* http://docs.openstack.org/developer/oslo.i18n/guidelines.html
#adding-variables-to-log-messages
The rule for it should be added to hacking checks.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1596829/+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 1280522] Re: Replace assertEqual(None, *) with assertIsNone in tests
** Also affects: ceilometer Importance: Undecided Status: New ** Changed in: ceilometer Assignee: (unassigned) => haobing1 (haobing1) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to anvil. https://bugs.launchpad.net/bugs/1280522 Title: Replace assertEqual(None, *) with assertIsNone in tests Status in Anchor: Fix Released Status in anvil: New Status in bifrost: Fix Released Status in Blazar: In Progress Status in Ceilometer: New Status in Cinder: Fix Released Status in congress: Fix Released Status in Designate: Fix Released Status in dox: New Status in DragonFlow: New Status in Freezer: New Status in Glance: Fix Released Status in glance_store: Fix Released Status in heat: Fix Released Status in heat-cfntools: Fix Released Status in Heat Translator: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in Ironic: Fix Released Status in ironic-python-agent: Fix Released Status in OpenStack Identity (keystone): Fix Released Status in keystoneauth: Fix Released Status in kolla-mesos: Fix Released Status in Manila: Fix Released Status in networking-brocade: New Status in networking-cisco: Fix Released Status in OpenStack Compute (nova): Fix Released Status in octavia: Fix Released Status in ooi: Fix Released Status in os-brick: In Progress Status in os-client-config: Fix Released Status in oslo.messaging: New Status in python-barbicanclient: Fix Released Status in python-ceilometerclient: Fix Released Status in python-cinderclient: Fix Released Status in python-congressclient: Fix Released Status in python-cueclient: Fix Released Status in python-designateclient: Fix Released Status in python-glanceclient: Fix Released Status in python-heatclient: Fix Released Status in python-ironicclient: Fix Released Status in python-manilaclient: Fix Released Status in python-neutronclient: Fix Released Status in python-openstackclient: Fix Released Status in OpenStack SDK: Fix Released Status in python-swiftclient: Fix Released Status in python-troveclient: Fix Released Status in Python client library for Zaqar: Fix Released Status in Quark: Money Reinvented: New Status in Sahara: Fix Released Status in OpenStack Search (Searchlight): New Status in Solum: Fix Released Status in Stackalytics: Fix Released Status in OpenStack Object Storage (swift): New Status in taskflow: New Status in tempest: Fix Released Status in OpenStack DBaaS (Trove): Fix Released Status in tuskar: Fix Released Status in watcher: Fix Released Status in zaqar: Fix Released Status in designate package in Ubuntu: Fix Released Status in python-tuskarclient package in Ubuntu: Fix Committed Bug description: Replace assertEqual(None, *) with assertIsNone in tests to have more clear messages in case of failure. To manage notifications about this bug go to: https://bugs.launchpad.net/anchor/+bug/1280522/+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 1596829] Re: String interpolation should be delayed at logging calls
** Also affects: python-cinderclient
Importance: Undecided
Status: New
** Changed in: python-cinderclient
Assignee: (unassigned) => haobing1 (haobing1)
** Also affects: python-glanceclient
Importance: Undecided
Status: New
** Changed in: python-glanceclient
Assignee: (unassigned) => haobing1 (haobing1)
** Also affects: glance-store
Importance: Undecided
Status: New
** Changed in: glance-store
Assignee: (unassigned) => haobing1 (haobing1)
** Also affects: ceilometer
Importance: Undecided
Status: New
** Changed in: ceilometer
Assignee: (unassigned) => haobing1 (haobing1)
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1596829
Title:
String interpolation should be delayed at logging calls
Status in Ceilometer:
New
Status in Cinder:
New
Status in Glance:
New
Status in glance_store:
New
Status in neutron:
In Progress
Status in OpenStack Compute (nova):
In Progress
Status in os-brick:
New
Status in python-cinderclient:
New
Status in python-glanceclient:
New
Bug description:
String interpolation should be delayed to be handled by the logging
code, rather than being done at the point of the logging call.
Wrong: LOG.debug('Example: %s' % 'bad')
Right: LOG.debug('Example: %s', 'good')
See the following guideline.
* http://docs.openstack.org/developer/oslo.i18n/guidelines.html
#adding-variables-to-log-messages
The rule for it should be added to hacking checks.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ceilometer/+bug/1596829/+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 1592212] [NEW] conversion_format should assign as the input parameter
Public bug reported:
when use the command of 'glance task-create --type --input' to create a
image, if we want to convert the image's format, we have to set the
conversion_format in the glance-api.conf file,such as 'conversion_format
= raw'. I think this is inconvenient,we should set the conversion_format
as the input parameter. such as 'glance task-create --type import
--input
'{"import_from":"http://10.43.176.8/images/cirros-0.3.1-x86_64-disk.img","import_from_format":
"", "conversion_format": "raw",
"image_properties":{"disk_format":"raw","container_format":"bare","name
":"test-hb_1"}}'
** Affects: glance
Importance: Undecided
Status: New
** Description changed:
when use the command of 'glance task-create --type --input' to create a
image, if we want to convert the image's format, we have to set the
conversion_format in the glance-api.conf file,such as 'conversion_format
= raw'. I think this is inconvenient,we should set the conversion_format
as the input parameter. such as 'glance task-create --type import
--input
'{"import_from":"http://10.43.176.8/images/cirros-0.3.1-x86_64-disk.img","import_from_format":
"", "conversion_format": "raw",
- "image_properties":{"disk_format":"qcow2","container_format":"bare","name
+ "image_properties":{"disk_format":"raw","container_format":"bare","name
":"test-hb_1"}}'
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1592212
Title:
conversion_format should assign as the input parameter
Status in Glance:
New
Bug description:
when use the command of 'glance task-create --type --input' to create
a image, if we want to convert the image's format, we have to set the
conversion_format in the glance-api.conf file,such as
'conversion_format = raw'. I think this is inconvenient,we should set
the conversion_format as the input parameter. such as 'glance task-
create --type import --input
'{"import_from":"http://10.43.176.8/images/cirros-0.3.1-x86_64-disk.img","import_from_format":
"", "conversion_format": "raw",
"image_properties":{"disk_format":"raw","container_format":"bare","name
":"test-hb_1"}}'
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1592212/+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 1572862] Re: update volume multiattach to true
** Changed in: nova Status: New => Invalid -- 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/1572862 Title: update volume multiattach to true Status in OpenStack Compute (nova): Invalid Bug description: When i use "cinder create" to create a volume,the default multiattach is false.But then i want to attach this volume to multi-instances,it will failed. It would be fine we can use a command to update volume multiattach to True, then we can attach this volume to multi- instances. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1572862/+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 1572862] [NEW] update volume multiattach to true
Public bug reported: When i use "cinder create" to create a volume,the default multiattach is false.But then i want to attach this volume to multi-instances,it will failed. It would be fine we can use a command to update volume multiattach to True . ** 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/1572862 Title: update volume multiattach to true Status in OpenStack Compute (nova): New Bug description: When i use "cinder create" to create a volume,the default multiattach is false.But then i want to attach this volume to multi-instances,it will failed. It would be fine we can use a command to update volume multiattach to True . To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1572862/+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
