[Yahoo-eng-team] [Bug 1693168] Re: Different APIs 'os-quota-class-sets' Response between v2 and v2.1
Reviewed: https://review.openstack.org/467999 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=92e0efeefd6782f205dc6a2b1f8e8a97f146596d Submitter: Jenkins Branch:master commit 92e0efeefd6782f205dc6a2b1f8e8a97f146596d Author: ghanshyam Date: Thu Jul 6 08:58:48 2017 +0300 Fix quota class set APIs v2.1 API which does not return the 'server_groups' and 'server_group_members' quotas in GET & PUT os-quota-class-sets API response. v2 API used to return those keys in API response. Also filter out the network related quotas from os-quota-class-sets APIs Fixing this with microversion. Closes-Bug: #1701211 Closes-Bug: #1693168 implement-blueprint fix-quota-classes-api Change-Id: I66aeb7a92fb5ee906fead78030bd84a2e97916e8 ** 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/1693168 Title: Different APIs 'os-quota-class-sets' Response between v2 and v2.1 Status in OpenStack Compute (nova): Fix Released Bug description: 'os-quota-class-sets' GET and PUT APIs response is different between v2(all extensions) and v2.1 There is no 'server_groups' and 'server_group_members' in quota class set APIs response where these were present in v2 (with all extension). 'os-server-group-quotas' extension was introduced in this - I78974602d4be04deaf173b3e43f2dab92e8f4171 in v2 API. and if extension 'os-server-group-quotas' was enabled in v2, then 'server_groups' and 'server_group_members' were present in APIs response. This behavior was till we had the legacy_v2 code where this extensions class and way to enable/disable extensions was available. In v2.1 API, there was never such extensions. v2.1 should behave same as v2 with all extensions. But we forgot to merge the if/else extension code[1] which caused 'server_groups' and 'server_group_members' never showed up in quota class set APIs (GET and PUT) response. .. 1 http://git.openstack.org/cgit/openstack/nova/tree/nova/api/openstack/compute/quota_classes.py#n47 This issue did not get caught on tests as legacy_v2 code got removed before functional tests with all extensions were enabled. And somehow sample file with 'server_groups' and 'server_group_members' attributes in response got disappeared while changing the directory structure v3->v2.1>/compute etc. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1693168/+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 1701211] Re: The network related quotas aren't deprecated in quota-class API
Reviewed: https://review.openstack.org/467999 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=92e0efeefd6782f205dc6a2b1f8e8a97f146596d Submitter: Jenkins Branch:master commit 92e0efeefd6782f205dc6a2b1f8e8a97f146596d Author: ghanshyam Date: Thu Jul 6 08:58:48 2017 +0300 Fix quota class set APIs v2.1 API which does not return the 'server_groups' and 'server_group_members' quotas in GET & PUT os-quota-class-sets API response. v2 API used to return those keys in API response. Also filter out the network related quotas from os-quota-class-sets APIs Fixing this with microversion. Closes-Bug: #1701211 Closes-Bug: #1693168 implement-blueprint fix-quota-classes-api Change-Id: I66aeb7a92fb5ee906fead78030bd84a2e97916e8 ** 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/1701211 Title: The network related quotas aren't deprecated in quota-class API Status in OpenStack Compute (nova): Fix Released Bug description: The network related quotas are deprecated in the quota-set API since 2.36. (https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/schemas/quota_sets.py#L49) But still existed in the quota-class API. https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/schemas/quota_classes.py#L22 We should deprecate those network quotas in the quota-class API also. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1701211/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1703369] Re: get_identity_providers policy should be singular
Reviewed: https://review.openstack.org/482142 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=b7119637a04d0a07fa6419a407f433c01bbd1db2 Submitter: Jenkins Branch:master commit b7119637a04d0a07fa6419a407f433c01bbd1db2 Author: Matthew Edmonds Date: Mon Jul 10 09:20:18 2017 -0400 fix identity:get_identity_providers typo Changes identity:get_identity_providers policy rule to identity:get_identity_provider to match what is checked by the code. Change-Id: I0841abd30fd15c034b5836e42a18938634b509b1 Closes-Bug: #1703369 ** 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/1703369 Title: get_identity_providers policy should be singular Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) newton series: New Status in OpenStack Identity (keystone) ocata series: New Status in OpenStack Security Advisory: Incomplete Status in OpenStack Security Notes: New Bug description: identity:get_identity_providers should be identity:get_identity_provider (singular) since a GET is targeted on a single provider and the code is setup to check for identity:get_identity_provider (singular). See https://github.com/openstack/keystone/blob/c7e29560b7bf7a44e44722eea0645bf18ad56af3/keystone/federation/controllers.py#L112 found in master (pike) The ocata default policy.json also has this problem. Unless someone manually overrode policy to specify identity:get_identity_provider (singular), the result would be that the default rule was actually used for that check instead of identity:get_identity_providers. We could go back and fix the default policy.json for past releases, but the default actually has the same value as identity:get_identity_providers, and if nobody has complained it's probably safer to just leave it. It is, after all, just defaults there and anyone can override by specifying the correct value. But we must fix in pike to go along with the shift of policy into code. Policy defaults in code definitely need to match up with what the code actually checks. There should no longer be any reliance on the default rule. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1703369/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1703369] Re: get_identity_providers policy should be singular
I've added an OSSN task to see if a Security Note would make more sense here since this is kind of an insecure default config value (class B2). ** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1703369 Title: get_identity_providers policy should be singular Status in OpenStack Identity (keystone): In Progress Status in OpenStack Identity (keystone) newton series: New Status in OpenStack Identity (keystone) ocata series: New Status in OpenStack Security Advisory: Incomplete Status in OpenStack Security Notes: New Bug description: identity:get_identity_providers should be identity:get_identity_provider (singular) since a GET is targeted on a single provider and the code is setup to check for identity:get_identity_provider (singular). See https://github.com/openstack/keystone/blob/c7e29560b7bf7a44e44722eea0645bf18ad56af3/keystone/federation/controllers.py#L112 found in master (pike) The ocata default policy.json also has this problem. Unless someone manually overrode policy to specify identity:get_identity_provider (singular), the result would be that the default rule was actually used for that check instead of identity:get_identity_providers. We could go back and fix the default policy.json for past releases, but the default actually has the same value as identity:get_identity_providers, and if nobody has complained it's probably safer to just leave it. It is, after all, just defaults there and anyone can override by specifying the correct value. But we must fix in pike to go along with the shift of policy into code. Policy defaults in code definitely need to match up with what the code actually checks. There should no longer be any reliance on the default rule. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1703369/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1701511] Re: hyperv: Bad log message formating in livemigrationops
Reviewed: https://review.openstack.org/479245 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=2a42776205f921c5b6e3186e8f043af758bbc494 Submitter: Jenkins Branch:master commit 2a42776205f921c5b6e3186e8f043af758bbc494 Author: Claudiu Belu Date: Fri Jun 30 13:10:14 2017 +0300 hyperv: Fixes log message in livemigrationops The instance should be passed as key-value argument to the logger. Change-Id: Id59f709a0c40dccdc75212816f97298cd9a6d521 Closes-Bug: #1701511 ** 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/1701511 Title: hyperv: Bad log message formating in livemigrationops Status in OpenStack Compute (nova): Fix Released Bug description: In nova.virt.hyperv.livemigrationops, in the check_can_live_migrate_source method, the instance is passed as an argument to the logger, instead of as a key-value argument. Because of this, the log message is never printed: [1] [1] http://paste.openstack.org/show/614164/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1701511/+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 1702150] Re: Instance sanitization in InstanceMetadata causes metadata_for_config_drive to fail
Reviewed: https://review.openstack.org/481235 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=004d5ed1f3e35d43dc5726aa80d31429b931bd45 Submitter: Jenkins Branch:master commit 004d5ed1f3e35d43dc5726aa80d31429b931bd45 Author: Matt Riedemann Date: Thu Jul 6 16:56:02 2017 -0400 Pre-load instance.device_metadata in InstanceMetadata Change Ie7d97ce5c62c8fb9da5822590a64210521f8ae7a orphans the Instance object so that we can pickle it. However, this means we can't lazy-load any attributes that we need when building up metadata, like when building the config drive during server create. We need to pre-load the device_metadata field so it's available when building the config drive. This isn't a problem for the libvirt driver since it loads device_metadata before building the config drive, but the hyperv driver doesn't do that, so the change above breaks hyperv when there are device tags without this fix. Change-Id: I08b905d2734ff9d484b373369f36d48c4d056fd8 Closes-Bug: #1702150 ** 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/1702150 Title: Instance sanitization in InstanceMetadata causes metadata_for_config_drive to fail Status in OpenStack Compute (nova): Fix Released Bug description: A recent patch [1] has merged in nova, which sanitizes the nova instance object, making it picklable. The sanitized instance object no longer has a _context attribute, which means that lazy-loading attributes are no longer loadable [2]. This can be an issue whenever a config drive has to be built for an instance, as InstanceMetadata.metadata_for_config_drive needs some unloaded attributes (device_metadata). This issue has been seen to affect mostly rebuild, unshelve, rescue operations. [1] https://review.openstack.org/#/c/478991/ [2] http://paste.openstack.org/show/614328/ Logs: http://64.119.130.115/nova/479245/1/Hyper- V_logs/c2-r21-u36-n02-compute02/nova-compute.log.gz To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1702150/+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 1229823] Re: Image cache clean should catch the not exist exception
Reviewed: https://review.openstack.org/479853 Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=2ee6e04276e3c26e3f05ef10751786cc170e877e Submitter: Jenkins Branch:master commit 2ee6e04276e3c26e3f05ef10751786cc170e877e Author: Sean McGinnis Date: Mon Jul 3 14:57:11 2017 + Handle file delete races in image cache In at least one case (see bug report) files have been deleted between when we check that they exist and when we actually attempt the deletion. Since we ultimately just want the file gone, we shouldn't care if we get an error that the file does not exist and just move on. Change-Id: Iaf71109fc6659650075ab4b4b48aec57819fb0b5 Closes-bug: #1229823 ** Changed in: glance Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1229823 Title: Image cache clean should catch the not exist exception Status in Glance: Fix Released Bug description: For image cache clean, Glance will remove the invalid files and stalled files, but if there is a cron job and at the same time if the admin has removed one of file before the cron job deletes it. There will be a non existed exception. It's rare but possible. As a result, that will not clean the entire cache i think To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1229823/+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 1703708] [NEW] Horizon image upload with bad Glance CORS config fails with "[object Object]"
Public bug reported: How to reproduce: Configure Horizon to use direct upload mode: HORIZON_IMAGES_UPLOAD_MODE=direct In glance-api.conf, make sure cors is enabled but configured badly with a bogus origin: [cors] allowed_origin = https://foobar Try uploading an image from Horizon. This should fail with this error in the console: XMLHttpRequest cannot load https://glance.example.org/v2/images//file. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow- Origin' header is present on the requested resource. Origin 'https://foobar' is therefore not allowed access. And Horizon will show this error at the top of the image creation popup: [object Object] Expected result: The error message shown should not be the one mentioned above, it's not user friendly. It can be a generic one like "Unable to create the image." or specific one if we want to inform the user that the provider improperly configured cors support in Glance. ** 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/1703708 Title: Horizon image upload with bad Glance CORS config fails with "[object Object]" Status in OpenStack Dashboard (Horizon): New Bug description: How to reproduce: Configure Horizon to use direct upload mode: HORIZON_IMAGES_UPLOAD_MODE=direct In glance-api.conf, make sure cors is enabled but configured badly with a bogus origin: [cors] allowed_origin = https://foobar Try uploading an image from Horizon. This should fail with this error in the console: XMLHttpRequest cannot load https://glance.example.org/v2/images//file. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow- Origin' header is present on the requested resource. Origin 'https://foobar' is therefore not allowed access. And Horizon will show this error at the top of the image creation popup: [object Object] Expected result: The error message shown should not be the one mentioned above, it's not user friendly. It can be a generic one like "Unable to create the image." or specific one if we want to inform the user that the provider improperly configured cors support in Glance. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1703708/+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 1703699] [NEW] B*m*W+!!!!!++$$$$++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone number
Private bug reported: B*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK suppor t phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone number Facebook online help, Facebook number customer support, Facebook customer relations, Facebook tech support phone number for iphone, phone number for Facebook help desk, Facebook iphone number support, Facebook product support,Facebook support by phone, Facebook it support phone number, Facebook telephone technical support, Facebook assistance phone, telephone number for Facebook technical support, Facebook phone help,Facebook tech support hours, call Facebook for help,Facebook customer helpline, Facebook help phone,Facebook mac support number, contact Facebook tech support, Facebook contact number support, Facebook support call number, Facebook customer service phone number iphone, 800 number for Facebook support, iphone Facebook support number, Facebook tech help number, Facebook's tech support number, telephone for Facebook support ,Facebook phone number 24 hours, Facebook tech help phone number, customer care Facebook, tech support number for Facebook, Facebook phone customer service, iphone customer service phone number, telephone Facebook support, iphone service number, Facebook support website, Facebook telephone support number, Facebook assistance phone number, Facebook help contact, Facebook phone customer service number, Facebook phone service number, Facebook support phone no ,phone number Facebook, Facebook support phone number iphone, Facebook customer service contact number, Facebook telephone help, what's Facebook's phone number, get support Facebook number, my Facebook phone number, phone number for Facebook computer support, contact number Facebook support, telephone number for Facebook tech support, Facebook technical support contact, number to Facebook tech support, Facebook support help, Facebook call center number, Facebook help phone line, Facebook phone help number, phone for Facebook tech support, Facebook number phone, Facebook support team number, Facebook tech support line, Facebook help center number, Facebook support 1800 number, Facebook phone number help, Facebook computer help number, i need a phone number for Facebook support, Facebook technical help phone number, Facebook technical assistance, Facebook laptop support number, Facebook support tech, Facebook number tech support, Facebook customer help, the number for Facebook support, Facebook customer service tech support, Facebook help desk contact number, Facebook text support number, Facebook call number, mac customer support phone number, support number for Facebook, Facebook tech support 800 number, Facebook iphone helpline telephone number, Facebook customer support telephone number, Facebook customer service contact, Facebook customer service hotline, Facebook customer service number iphone, phone number for Facebook support iphone, contact number Facebook,Facebook number uk, Facebook technical service, 800 number for Facebook tech support, Facebook tech support online, Facebook computer telephone number, Facebook customer assistance, Facebook customer service number fo
[Yahoo-eng-team] [Bug 1703699] Re: B*m*W+!!!!!++$$$$++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone number
** Project changed: nova => null-and-void ** Information type changed from Public to Private ** Changed in: null-and-void 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/1703699 Title: B*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone number Status in NULL Project: Invalid Bug description: B*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK supp ort phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberB*m*W+!++++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone number Facebook online help, Facebook number customer support, Facebook customer relations, Facebook tech support phone number for iphone, phone number for Facebook help desk, Facebook iphone number support, Facebook product support,Facebook support by phone, Facebook it support phone number, Facebook telephone technical support, Facebook assistance phone, telephone number for Facebook technical support, Facebook phone help,Facebook tech support hours, call Facebook for help,Facebook customer helpline, Facebook help phone,Facebook mac support number, contact Facebook tech support, Facebook contact number support, Facebook support call number, Facebook customer service phone number iphone, 800 number for Facebook support, iphone Facebook support number, Facebook tech help number, Facebook's tech support number, telephone for Facebook support ,Facebook phone number 24 hours, Facebook tech help phone number, customer care Facebook, tech support number for Facebook, Facebook phone customer service, iphone customer service phone number, telephone Facebook support, iphone service number, Facebook support website, Facebook telephone support number, Facebook assistance phone number, Facebook help contact, Facebook phone customer service number, Facebook phone service number, Facebook support phone no ,phone number Facebook, Facebook support phone number iphone, Facebook customer service contact number, Facebook telephone help, what's Facebook's phone number, get support Facebook number, my Facebook phone number, phone number for Facebook computer support, contact number Facebook support, telephone number for Facebook tech support, Facebook technical support contact, number to Facebook tech support, Facebook support help, Facebook call center number, Facebook help phone line, Facebook phone help number, phone for Facebook tech support, Facebook number phone, Facebook support team number, Facebook tech support line, Facebook help center number, Facebook support 1800 number, Facebook phone number help, Facebook computer help number, i need a phone number for Facebook support, Facebook technical help phone number, Facebook technical assistance, Facebook laptop support number, Facebook support tech, Facebook number tech support, Facebook customer help, the number for Facebook support, Facebook customer service tech support, Facebook help desk contact number, Facebook text s
[Yahoo-eng-team] [Bug 1703701] Re: ~~~~HElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone number
** Project changed: nova => null-and-void ** Information type changed from Public to Private ** Changed in: null-and-void 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/1703701 Title: HElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone number Status in NULL Project: Invalid Bug description: HElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACE BOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numb erHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone number Facebook online help, Facebook number customer support, Facebook customer relations, Facebook tech support phone number for iphone, phone number for Facebook help desk, Facebook iphone number support, Facebook product support,Facebook support by phone, Facebook it support phone number, Facebook telephone technical support, Facebook assistance phone, telephone number for Facebook technical support, Facebook phone help,Facebook tech support hours, call Facebook for help,Facebook customer helpline, Facebook help phone,Facebook mac support number, contact Facebook tech support, Facebook contact number support, Facebook support call number, Facebook customer service phone number iphone, 800 number for Facebook support, iphone Facebook support number, Facebook tech help number, Facebook's tech support number, telephone for Facebook support ,Facebook phone number 24 hours, Facebook tech help phone number, customer care Facebook, tech support number for Facebook, Facebook phone customer service, iphone customer service phone number, telephone Facebook support, iphone service number, Facebook support website, Facebook telephone support number, Facebook assistance phone number, Facebook help contact, Facebook phone customer service number, Facebook phone service number, Facebook support phone no ,phone number Facebook, Facebook support phone number iphone, Facebook customer service contact number, Facebook telephone help, what's Facebook's phone number, get support Facebook number, my Facebook phone number, phone number for Facebook computer support, contact number Facebook support, telephone number for Facebook tech support, Facebook technical support contact, number to Facebook tech support, Facebook support help, Facebook call center number, Facebook help phone line, Facebook phone help number, phone for Facebook tech support, Facebook number phone, Facebook support team number, Facebook tech support line, Facebook help center number, Face
[Yahoo-eng-team] [Bug 1703700] [NEW] TATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone number
Private bug reported: TATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone numb er==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone number Facebook online help, Facebook number customer support, Facebook customer relations, Facebook tech support phone number for iphone, phone number for Facebook help desk, Facebook iphone number support, Facebook product support,Facebook support by phone, Facebook it support phone number, Facebook telephone technical support, Facebook assistance phone, telephone number for Facebook technical support, Facebook phone help,Facebook tech support hours, call Facebook for help,Facebook customer helpline, Facebook help phone,Facebook mac support number, contact Facebook tech support, Facebook contact number support, Facebook support call number, Facebook customer service phone number iphone, 800 number for Facebook support, iphone Facebook support number, Facebook tech help number, Facebook's tech support number, telephone for Facebook support ,Facebook phone number 24 hours, Facebook tech help phone number, customer care Facebook, tech support number for Facebook, Facebook phone customer service, iphone customer service phone number, telephone Facebook support, iphone service number, Facebook support website, Facebook telephone support number, Facebook assistance phone number, Facebook help contact, Facebook phone customer service number, Facebook phone service number, Facebook support phone no ,phone number Facebook, Facebook support phone number iphone, Facebook customer service contact number, Facebook telephone help, what's Facebook's phone number, get support Facebook number, my Facebook phone number, phone number for Facebook computer support, contact number Facebook support, telephone number for Facebook tech support, Facebook technical support contact, number to Facebook tech support, Facebook support help, Facebook call center number, Facebook help phone line, Facebook phone help number, phone for Facebook tech support, Facebook number phone, Facebook support team number, Facebook tech support line, Facebook help center number, Facebook support 1800 number, Facebook phone number help, Facebook computer help number, i need a phone number for Facebook support, Facebook technical help phone number, Facebook technical assistance, Facebook laptop support number, Facebook support tech, Facebook number tech support, Facebook customer help, the number for Facebook support, Facebook customer service tech support, Facebook help desk contact number, Facebook text support number, Facebook call number, mac customer support phone number, support number for Facebook, Facebook tech support 800 number, Facebook iphone helpline telephone number, Facebook customer support telephone number, Facebook customer service contact, Facebook customer service hotline, Facebook customer service number iphone, phone number for Facebook support iphone, contact number Facebook,Facebook number uk, Facebook technical service, 800 number for Facebook tech support, Facebook tech support online, Facebook computer telephone number, Facebook customer assistance, Facebook customer service number for iphone, telephone number for Facebook h
[Yahoo-eng-team] [Bug 1703700] Re: TATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone number
** Project changed: nova => null-and-void ** Information type changed from Public to Private ** Changed in: null-and-void 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/1703700 Title: TATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone number Status in NULL Project: Invalid Bug description: TATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone nu mber==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone numberTATA~MOTORS++1@@844+==851***9490 FACEBOOK phone number==FACEBOOK support phone number Facebook online help, Facebook number customer support, Facebook customer relations, Facebook tech support phone number for iphone, phone number for Facebook help desk, Facebook iphone number support, Facebook product support,Facebook support by phone, Facebook it support phone number, Facebook telephone technical support, Facebook assistance phone, telephone number for Facebook technical support, Facebook phone help,Facebook tech support hours, call Facebook for help,Facebook customer helpline, Facebook help phone,Facebook mac support number, contact Facebook tech support, Facebook contact number support, Facebook support call number, Facebook customer service phone number iphone, 800 number for Facebook support, iphone Facebook support number, Facebook tech help number, Facebook's tech support number, telephone for Facebook support ,Facebook phone number 24 hours, Facebook tech help phone number, customer care Facebook, tech support number for Facebook, Facebook phone customer service, iphone customer service phone number, telephone Facebook support, iphone service number, Facebook support website, Facebook telephone support number, Facebook assistance phone number, Facebook help contact, Facebook phone customer service number, Facebook phone service number, Facebook support phone no ,phone number Facebook, Facebook support phone number iphone, Facebook customer service contact number, Facebook telephone help, what's Facebook's phone number, get support Facebook number, my Facebook phone number, phone number for Facebook computer support, contact number Facebook support, telephone number for Facebook tech support, Facebook technical support contact, number to Facebook tech support, Facebook support help, Facebook call center number, Facebook help phone line, Facebook phone help number, phone for Facebook tech support, Facebook number phone, Facebook support team number, Facebook tech support line, Facebook help center number, Facebook support 1800 number, Facebook phone number help, Facebook computer help number, i need a phone number for Facebook support, Facebook technical help phone number, Facebook technical assistance, Facebook laptop support number, Facebook support tech, Facebook number tech support, Facebook customer help, the number for Facebook support, Facebook customer service tech support, Facebook help desk contact number, Facebook text support number, Facebook call number, mac
[Yahoo-eng-team] [Bug 1703701] [NEW] ~~~~HElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone number
Private bug reported: HElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBO OK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone number HElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone numberHElp For FACEBOOK++1@@844+*851***9490 FACEBOOK phone number==FACEBOOK support phone number Facebook online help, Facebook number customer support, Facebook customer relations, Facebook tech support phone number for iphone, phone number for Facebook help desk, Facebook iphone number support, Facebook product support,Facebook support by phone, Facebook it support phone number, Facebook telephone technical support, Facebook assistance phone, telephone number for Facebook technical support, Facebook phone help,Facebook tech support hours, call Facebook for help,Facebook customer helpline, Facebook help phone,Facebook mac support number, contact Facebook tech support, Facebook contact number support, Facebook support call number, Facebook customer service phone number iphone, 800 number for Facebook support, iphone Facebook support number, Facebook tech help number, Facebook's tech support number, telephone for Facebook support ,Facebook phone number 24 hours, Facebook tech help phone number, customer care Facebook, tech support number for Facebook, Facebook phone customer service, iphone customer service phone number, telephone Facebook support, iphone service number, Facebook support website, Facebook telephone support number, Facebook assistance phone number, Facebook help contact, Facebook phone customer service number, Facebook phone service number, Facebook support phone no ,phone number Facebook, Facebook support phone number iphone, Facebook customer service contact number, Facebook telephone help, what's Facebook's phone number, get support Facebook number, my Facebook phone number, phone number for Facebook computer support, contact number Facebook support, telephone number for Facebook tech support, Facebook technical support contact, number to Facebook tech support, Facebook support help, Facebook call center number, Facebook help phone line, Facebook phone help number, phone for Facebook tech support, Facebook number phone, Facebook support team number, Facebook tech support line, Facebook help center number, Facebook support 1800 number, Facebook phone number help, Facebook computer help number, i need a phone number for Facebook support, Facebook technical help phone number, Facebook technical assistance, Facebook laptop support number, Facebook support tech, Facebook number tech support, Facebook customer help, the number for Facebook support, Facebook customer service tech support, Facebook help desk contact number, Facebook text support number, Facebook call number, mac customer support phone number, support number for Facebook, Facebook tech support 800 number, Facebook iphone helpline teleph
[Yahoo-eng-team] [Bug 1703697] [NEW] tox fails under python 3.6
Public bug reported: Steps to reproduce: 1. lxc launch ubuntu-daily:a a 2. lxc exec a bash 3. add-apt-repository ppa:canonical-foundations/python3.6-as-default -y 4. apt-get update 5. apt-get upgrade -y 6. apt-get install tox 6. git clone https://git.launchpad.net/cloud-init 7. cd cloud-init 8. tox Expected results: All tests pass Actual results: Numerous unittest failures, see: http://paste.ubuntu.com/25071344/ There appear to be three types of errors: 9x jsonpatch issues related: http://paste.ubuntu.com/25071366/ 2x unexpected None type: http://paste.ubuntu.com/25071385/ 1x incorrect assert/mock(?) http://paste.ubuntu.com/25071375/ ** Affects: cloud-init Importance: Undecided Status: New -- 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/1703697 Title: tox fails under python 3.6 Status in cloud-init: New Bug description: Steps to reproduce: 1. lxc launch ubuntu-daily:a a 2. lxc exec a bash 3. add-apt-repository ppa:canonical-foundations/python3.6-as-default -y 4. apt-get update 5. apt-get upgrade -y 6. apt-get install tox 6. git clone https://git.launchpad.net/cloud-init 7. cd cloud-init 8. tox Expected results: All tests pass Actual results: Numerous unittest failures, see: http://paste.ubuntu.com/25071344/ There appear to be three types of errors: 9x jsonpatch issues related: http://paste.ubuntu.com/25071366/ 2x unexpected None type: http://paste.ubuntu.com/25071385/ 1x incorrect assert/mock(?) http://paste.ubuntu.com/25071375/ To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1703697/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1703369] Re: get_identity_providers policy should be singular
To recap the conversation and summarize what was discuss in IRC [0]. There is a security issue if a deployer modifies the default policy role required for an operation but wishes to keep the identity:get_identity_providers protected at the "admin-level". This was deemed as unlikely since the default and get_identity_provider were protected with the same admin_required rule. For the sake of process, we can merge the proposed fix [1] with a detailed release note explaining the case. After that we can propose the patch to stable/ocata as well as stable/newton. Even though a deployer can technically issue this fix without a new release, the process of issuing a release note seems valuable at least for the sake of process. [0] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2017-07-11.log.html#t2017-07-11T21:26:46 [1] https://review.openstack.org/#/c/482142/ ** Also affects: keystone/newton Importance: Undecided Status: New ** Also affects: keystone/ocata Importance: Undecided Status: New ** Changed in: keystone Milestone: None => pike-3 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1703369 Title: get_identity_providers policy should be singular Status in OpenStack Identity (keystone): In Progress Status in OpenStack Identity (keystone) newton series: New Status in OpenStack Identity (keystone) ocata series: New Status in OpenStack Security Advisory: Incomplete Bug description: identity:get_identity_providers should be identity:get_identity_provider (singular) since a GET is targeted on a single provider and the code is setup to check for identity:get_identity_provider (singular). See https://github.com/openstack/keystone/blob/c7e29560b7bf7a44e44722eea0645bf18ad56af3/keystone/federation/controllers.py#L112 found in master (pike) The ocata default policy.json also has this problem. Unless someone manually overrode policy to specify identity:get_identity_provider (singular), the result would be that the default rule was actually used for that check instead of identity:get_identity_providers. We could go back and fix the default policy.json for past releases, but the default actually has the same value as identity:get_identity_providers, and if nobody has complained it's probably safer to just leave it. It is, after all, just defaults there and anyone can override by specifying the correct value. But we must fix in pike to go along with the shift of policy into code. Policy defaults in code definitely need to match up with what the code actually checks. There should no longer be any reliance on the default rule. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1703369/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1684071] Re: No tests available for default-subnetpools in neutron tempest tests
Reviewed: https://review.openstack.org/468257 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=316e2f42c163e3a363f660af65bdf4c9acd43ee2 Submitter: Jenkins Branch:master commit 316e2f42c163e3a363f660af65bdf4c9acd43ee2 Author: Dongcan Ye Date: Fri May 26 10:48:40 2017 +0800 Tempest: Add default-subnetpools tests Add missing default-subnetpools tempest tests. Change-Id: I59a98b822400a6f3ba480daf275c1e3058225b87 Closes-Bug: #1684071 ** 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/1684071 Title: No tests available for default-subnetpools in neutron tempest tests Status in neutron: Fix Released Bug description: There are no tests available under neutron tests for default- subnetpools, filing this bug to take care of the same. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1684071/+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 1133435] Re: policy should return a 400 if a required field is missing
Found the problem and proposing a fix... ** Changed in: keystone Status: Expired => Confirmed ** Changed in: keystone Assignee: (unassigned) => Matthew Edmonds (edmondsw) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1133435 Title: policy should return a 400 if a required field is missing Status in OpenStack Identity (keystone): In Progress Bug description: Instead, policy will return a 403 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1133435/+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 1701297] Re: NTP reload failure (unable to read library) on overlayfs
** Changed in: cloud-init Status: Incomplete => Won't Fix -- 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/1701297 Title: NTP reload failure (unable to read library) on overlayfs Status in cloud-init: Won't Fix Status in apparmor package in Ubuntu: Confirmed Status in cloud-init package in Ubuntu: Incomplete Status in linux package in Ubuntu: Confirmed Bug description: After update [1] of cloud-init in Ubuntu (which landed in xenial- updates on 2017-06-27), it is causing NTP reload failures. https://launchpad.net/ubuntu/+source/cloud-init/0.7.9-153-g16a7302f- 0ubuntu1~16.04.1 In MAAS scenarios, this is causing the machine to fail to deploy. Related bugs: * bug 1645644: cloud-init ntp not using expected servers To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1701297/+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 1703666] [NEW] Templated catalog does not handle multi-regions properly
Public bug reported: The current implementation of the keystone templated catalog does not group endpoints properly when there are multiple region available. This is an working example when using the sql backend and the openstack catalog list command. | nova| compute| RegionTwo | || admin: http://10.0.3.15:8774/v2.1 | || RegionOne | || admin: http://10.0.2.15:8774/v2.1 This is the same example using the templated backend and the openstack catalog list command. | nova| compute| RegionTwo | || admin: http://10.0.3.15:8774/v2.1 | nova| compute| RegionOne | || admin: http://10.0.2.15:8774/v2.1 This causes issues in services that expects each service_type to include the endpoint for all regions. This is because the code in Horizon is initially only looking for the service_type, which will return the first one, in this case is RegionTwo. If Horizon was requesting RegionOne, this would fail, as the list of endpoints would only contains RegionTwo. As a work-around for Horizon a change like this is required -def get_service_from_catalog(catalog, service_type): +def get_service_from_catalog(catalog, service_type, region): if catalog: for service in catalog: if 'type' not in service: continue if service['type'] == service_type: -return service +for endpoint in service['endpoints']: +if endpoint['region'] == region: +return service return None ** Affects: keystone Importance: Medium Assignee: Erik Olof Gunnar Andersson (eandersson) Status: Triaged -- 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/1703666 Title: Templated catalog does not handle multi-regions properly Status in OpenStack Identity (keystone): Triaged Bug description: The current implementation of the keystone templated catalog does not group endpoints properly when there are multiple region available. This is an working example when using the sql backend and the openstack catalog list command. | nova| compute| RegionTwo | || admin: http://10.0.3.15:8774/v2.1 | || RegionOne | || admin: http://10.0.2.15:8774/v2.1 This is the same example using the templated backend and the openstack catalog list command. | nova| compute| RegionTwo | || admin: http://10.0.3.15:8774/v2.1 | nova| compute| RegionOne | || admin: http://10.0.2.15:8774/v2.1 This causes issues in services that expects each service_type to include the endpoint for all regions. This is because the code in Horizon is initially only looking for the service_type, which will return the first one, in this case is RegionTwo. If Horizon was requesting RegionOne, this would fail, as the list of endpoints would only contains RegionTwo. As a work-around for Horizon a change like this is required -def get_service_from_catalog(catalog, service_type): +def get_service_from_catalog(catalog, service_type, region): if catalog: for service in catalog: if 'type' not in service: continue if service['type'] == service_type: -return service +for endpoint in service['endpoints']: +if endpoint['region'] == region: +return service return None To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1703666/+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 1702542] Re: feature support matrix docs build fails with misleading error
Reviewed: https://review.openstack.org/480708 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=9269d35ea876fa54edb9b332e927ee9d73c40f50 Submitter: Jenkins Branch:master commit 9269d35ea876fa54edb9b332e927ee9d73c40f50 Author: Matt Riedemann Date: Wed Jul 5 15:15:50 2017 -0400 Fix error message when support matrix entry is missing a driver This was noticed in change If10cffd0dc4c9879f6754ce39bee5fae1d04f474 which was missing the powervm driver target for the extend-volume entry. Before this change, the error message was: 'libvirt-vz-ct' missing in '[operation.extend-volume]' section This was really confusing because that driver is in the change. What was missing was powervm, but because the error message is using the wrong key that was not showing up. Change-Id: I2e7ea49d5ba42cc633796222af47c1d4cd59f96b Closes-Bug: #1702542 ** 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/1702542 Title: feature support matrix docs build fails with misleading error Status in OpenStack Compute (nova): Fix Released Bug description: The docs job kept failing on this patch: https://review.openstack.org/#/c/454322/24 With this error: http://logs.openstack.org/22/454322/24/check/gate-nova-docs-ubuntu- xenial/62d7b0a/console.html#_2017-07-05_16_18_34_699873 Exception: 'libvirt-vz-ct' missing in '[operation.extend-volume]' section But that driver is in the patch: https://review.openstack.org/#/c/454322/24/doc/source/support- matrix.ini The problem was the powervm impl was missing, but there is a bug in the support matrix parsing code such that when it failed, it put the wrong driver target key in the error message, so it was misleading. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1702542/+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 1687479] Re: Evacuated instances that are deleted before the source host comes up causes cleanup not to happen
** Also affects: nova/ocata
Importance: Undecided
Status: New
** Changed in: nova
Importance: Undecided => Medium
** Changed in: nova/ocata
Importance: Undecided => Medium
** Changed in: nova/ocata
Status: New => In Progress
** Changed in: nova/ocata
Assignee: (unassigned) => Matt Rabe (mdrabe)
--
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/1687479
Title:
Evacuated instances that are deleted before the source host comes up
causes cleanup not to happen
Status in OpenStack Compute (nova):
In Progress
Status in OpenStack Compute (nova) ocata series:
In Progress
Bug description:
Description
===
When an instance is evacuated to another host, the VM remains on the source
host until it is brought back up and deleted by compute via
_destroy_evacuated_instances.
However if the VM that's created on the destination is deleted before
the source host is brought back up, then _destroy_evacuated_instances
won't reap the remains because it searches non-deleted records.
Steps to reproduce
==
1. Deploy a VM.
2. Bring the host the VM is on down.
3. Evacuate the VM to a different host.
4. Delete the VM from the destination.
5. Bring the source host back up.
The source remnants from the evacuation will not be cleaned up, but
they should be.
Suspect code is in the nova compute manager in
_destroy_evacuated_instances:
1. MigrationList.get_by_filters doesn't appear to return deleted migration
records.
2. {'deleted': False} is currently passed as the filter to
_get_instances_on_driver.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1687479/+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 1702932] Re: Unshelving an offloaded server with volume attachments may not attach to the guest in multi-cell env
Turns out this was invalid. Volume attach works for a shelved offloaded instance with cells v2 because the context is targeted to the cell that the target instance lives in when we lookup the instance in the API code, in nova.compute.api.API._get_instance. So when the BDM is created using that context, it's also created in the same cell as the instance. ** Changed in: nova Status: In Progress => 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/1702932 Title: Unshelving an offloaded server with volume attachments may not attach to the guest in multi-cell env Status in OpenStack Compute (nova): Invalid Bug description: This is based on code inspection currently but it looks like this should fail in the following case: https://github.com/openstack/nova/blob/56cd608d3a199dcb02ac2ae071ff3057241259da/nova/compute/api.py#L3723 When we attach a volume to a shelved offloaded server, we create the BDM in the API. If the API is configured to point at cell0, then the BDM would be created in cell0. When we unshelve the instance, conductor asks the scheduler for a host (which is in some cell) and we build the instance in that cell. This could be a different cell because we currently don't restrict that in the conductor task manager when unshelving like we do for migrate: https://github.com/openstack/nova/blob/56cd608d3a199dcb02ac2ae071ff3057241259da/nova/conductor/tasks/migrate.py#L63-L66 The fact we don't restrict where the instance goes when it's unshelved is a separate bug. When unshelving the instance, it gets built on some compute and we pull the BDMs from the database configured for that cell (should be cell1, cell2, ..., cellN - some specific non-cell0 database). https://github.com/openstack/nova/blob/56cd608d3a199dcb02ac2ae071ff3057241259da/nova/compute/manager.py#L4513 If the BDM was created in the API in cell0, it shouldn't come back from that query in the compute manager code. What's most confusing about this is Tempest has tests for testing attach/detach a volume to a shelved offloaded instance: https://github.com/openstack/tempest/blob/21dd8a5ee2ab5a068cbb20d0468bd5f444fef59a/tempest/api/compute/volumes/test_attach_volume.py#L148 And those are passing on the devstack change that runs with multiple cells and configures the API to use cell0 for the [database] section where the BDM would live: https://review.openstack.org/#/c/473565/ Unless maybe that test is broken. We are configured to run ssh validation in the gate jobs on master (pike) though, so the test is counting the number of partitions on the guest before and after the unshelve operation to see that they show up. It's also listing volume attachments for the instance after unshelve. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1702932/+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 1691885] Re: Updating Nova::Server with Neutron::Port resource 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 neutron.
https://bugs.launchpad.net/bugs/1691885
Title:
Updating Nova::Server with Neutron::Port resource fails
Status in heat:
Won't Fix
Status in neutron:
New
Status in OpenStack Compute (nova):
New
Bug description:
A Nova::Server resource that was created with an implicit port cannot
be updated.
If I first create the following resource:
# template1.yaml
resources:
my_ironic_instance:
type: OS::Nova::Server
properties:
key_name: default
image: overcloud-full
flavor: baremetal
networks:
- network: ctlplane
ip_address: "192.168.24.10"
And then try to run a stack update with a different ip_address:
# template2.yaml
resources:
my_ironic_instance:
type: OS::Nova::Server
properties:
key_name: default
image: overcloud-full
flavor: baremetal
networks:
- network: ctlplane
ip_address: "192.168.24.20"
This fails with the following error:
RetryError: resources.my_ironic_instance: RetryError[]
I also tried assigning an external IP to the Nova::Server created in the
template1.yaml, but that gave me the same error.
# template3.yaml
resources:
instance_port:
type: OS::Neutron::Port
properties:
network: ctlplane
fixed_ips:
- subnet: "ctlplane-subnet"
ip_address: "192.168.24.20"
my_ironic_instance:
type: OS::Nova::Server
properties:
key_name: default
image: overcloud-full
flavor: baremetal
networks:
- network: ctlplane
port: {get_resource: instance_port}
However, if I first create the Nova::Server resource with an external
port specified (as in template3.yaml above), then I can update the
port to a different IP address and Ironic/Neutron does the right thing
(at least since the recent attach/detach VIF in Ironic code has
merged). So it appears that you can update a port if the port was
created externally, but not if the port was created as part of the
Nova::Server resource.
To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1691885/+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 1703629] [NEW] Evacuation fails for instances with PCI devices due to missing migration
Public bug reported: Description === The fix for bug https://bugs.launchpad.net/nova/+bug/1677621 enforced a requirement for a migration object to be present in the call to update_port_binding_for_instance() in order to do any mapping from old PCI devices to new PCI devices when an instance is migrated/resized/evacuated. During an evacuation, a migration is created, but never passed down to update_port_binding_for_instance(). This can cause an instance to be spawned on the new host with an incorrect (PCI) port binding. This can happen even with the proposed fix to related bug #1630698. Steps to reproduce == Two node setup - Launch an instance with PCI-PT or SR-IOV port bindings - Stop nova-compute on the destination host - nova evacuate Expected result === The instance should migrate to a new host (provided resources are available) with an updated port binding using PCI device(s) on the new host. Actual result = Instance launched using port bindings from the old host. Environment === 2. Which hypervisor did you use? libvirt 3. Which networking type did you use? - Affects neutron with openvswitch ** Affects: nova Importance: Undecided Assignee: Steven Webster (swebster-wr) Status: New ** Changed in: nova Assignee: (unassigned) => Steven Webster (swebster-wr) -- 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/1703629 Title: Evacuation fails for instances with PCI devices due to missing migration Status in OpenStack Compute (nova): New Bug description: Description === The fix for bug https://bugs.launchpad.net/nova/+bug/1677621 enforced a requirement for a migration object to be present in the call to update_port_binding_for_instance() in order to do any mapping from old PCI devices to new PCI devices when an instance is migrated/resized/evacuated. During an evacuation, a migration is created, but never passed down to update_port_binding_for_instance(). This can cause an instance to be spawned on the new host with an incorrect (PCI) port binding. This can happen even with the proposed fix to related bug #1630698. Steps to reproduce == Two node setup - Launch an instance with PCI-PT or SR-IOV port bindings - Stop nova-compute on the destination host - nova evacuate Expected result === The instance should migrate to a new host (provided resources are available) with an updated port binding using PCI device(s) on the new host. Actual result = Instance launched using port bindings from the old host. Environment === 2. Which hypervisor did you use? libvirt 3. Which networking type did you use? - Affects neutron with openvswitch To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1703629/+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 1088611] Re: using random hostnames to detect dns proxies allows for false positives
** Also affects: cloud-init Importance: Undecided Status: New ** Changed in: cloud-init Status: New => Confirmed ** Changed in: cloud-init Importance: Undecided => Medium -- 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/1088611 Title: using random hostnames to detect dns proxies allows for false positives Status in cloud-init: Confirmed Status in cloud-init package in Ubuntu: Confirmed Bug description: The fix that's been applied for bug #974509 checks for the presence of a redirector by looking of three hostnames, and treating as invalid any results pointing to a matching address: - does-not-exist.example.com. - example.invalid. - a random, unqualified 32-character alphanumeric hostname. The last of these carries a small but non-zero risk of colliding with a real hostname, and there's a small but non-zero risk that this host points to the same address as something we care about. If possible, it would be better to not include this random-host lookup in the algorithm, as somewhere, some day, chances are there will eventually be a collision, causing an incomprehensible and unreproducible failure for a user. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1088611/+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 1418031] Re: The instance creation time is not correct
Reviewed: https://review.openstack.org/376196 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=29a3768379c5804891c1cd679b2bed3556588740 Submitter: Jenkins Branch:master commit 29a3768379c5804891c1cd679b2bed3556588740 Author: bhavani.cr Date: Tue Jun 27 11:17:21 2017 +0530 Use request.COOKIES to activate the timezone This patch fixes the inconsistency in the instance creation time. Change-Id: Ic4afd9a03f0278883e0d00a2e075acaa4b4f8dc1 Co-Authored-By: bhavani Closes-Bug: #1418031 ** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1418031 Title: The instance creation time is not correct Status in OpenStack Dashboard (Horizon): Fix Released Bug description: The instance is created at Jan. 17, 2015, 3:02 p.m.(UTC +08:00), The creation time in UTC is Jan. 17, 2015, 7:02 a.m., then we will reproduce the problem, 1. Save Timezone as UTC in user settings page, the creation time is Jan. 17, 2015, 7:02 a.m. 2. Save Timezone as UTC +08:00 in user settings page, the creation time is Jan. 17, 2015, 3:02 p.m. 3. logout horizon 4. login horizon 5. the timezone of user settings page is UTC +08:00, but the creation time of instance in detail page is UTC time(Jan. 17, 2015, 7:02 a.m.) it's not consistent, we should fix it To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1418031/+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 1702466] Re: Subnet details page fails when a subnet uses IPv6 with prefix delegation
** Also 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/1702466
Title:
Subnet details page fails when a subnet uses IPv6 with prefix
delegation
Status in OpenStack Dashboard (Horizon):
New
Status in horizon package in Ubuntu:
New
Bug description:
Package: openstack-dashboard
Description:Ubuntu 16.04.2 LTS
Release:16.04
openstack-dashboard:
Installed: 2:9.1.2-0ubuntu1
Candidate: 2:9.1.2-0ubuntu1
Description: problem occurs when using an IPv6 subnet with prefix
delegation (IPv4 subnets are ok). When using web interface, if we try
to see subnet details in menu System -> Networks -> Click on network
name -> Click on subnet name we got the following error:
neutron-server[22658]: 2017-07-04 16:29:21.186 22864 INFO neutron.wsgi
[req-0fbaad92-83ff-4179-8056-8521fbef5ff9
e85813733498d6d6b6678b77d4756aaddef55bba18166be7d3bc3a8d20a65fd8
769822d4bf984cfeb3ab910cec9fa5b3 - - -] 192.168.0.1 - - [04/Jul/2017
16:29:21] "GET /v2.0/subnetpools/prefix_delegation.json HTTP/1.1" 404
266 0.007587
The subnet is working fine. Here is the output of opentack CLI 'show'
statement:
$ openstack subnet show nti-subnet-ipv6
+---+-+
| Field | Value
|
+---+-+
| allocation_pools |
2001:DB8:1400:5026::2-2001:DB8:1400:5026::::|
| cidr | 2001:DB8:1400:5026::/64
|
| created_at| 2016-09-12T13:01:15
|
| description |
|
| dns_nameservers | 2001:DB8:1400:2127::FFFE
|
| enable_dhcp | True
|
| gateway_ip| 2001:DB8:1400:5026::1
|
| host_routes |
|
| id| 129bd534-7121-4759-93a2-68ac907edf74
|
| ip_version| 6
|
| ipv6_address_mode | dhcpv6-stateless
|
| ipv6_ra_mode | dhcpv6-stateless
|
| name | nti-subnet-ipv6
|
| network_id| d204d9a2-bb8a-48af-bfa0-f0438970d98b
|
| project_id| 769822d4bf984cfeb3ab910cec9fa5b3
|
| subnetpool_id | prefix_delegation
|
| updated_at| 2017-05-31T18:59:50
|
+---+
+
Trying to find the problem, I found the file
openstack_dashboard/dashboards/project/networks/subnets/views.py with
this code (comments are mine):
class DetailView(tabs.TabView):
tab_group_class = project_tabs.SubnetDetailTabs
template_name = 'horizon/common/_detail.html'
page_title = "{{ subnet.name|default:subnet.id }}"
@memoized.memoized_method
def get_data(self):
subnet_id = self.kwargs['subnet_id']
try:
subnet = api.neutron.subnet_get(self.request, subnet_id)
except Exception:
subnet = []
msg = _('Unable to retrieve subnet details.')
exceptions.handle(self.request, msg,
redirect=self.get_redirect_url())
else:
if subnet.ip_version == 6:
ipv6_modes = utils.get_ipv6_modes_menu_from_attrs(
subnet.ipv6_ra_mode, subnet.ipv6_address_mode)
subnet.ipv6_modes_desc = utils.IPV6_MODE_MAP.get(ipv6_modes)
#if ('subnetpool_id' in subnet and
#subnet.subnetpool_id and
#api.neutron.is_extension_supported(self.request,
# 'subnet_allocation')):
#subnetpool = api.neutron.subnetpool_get(self.request,
#subnet.subnetpool_id)
#subnet.subnetpool_name = subnetpool.name
The commented code snippet seems to be the problem. It tries to get
some information about the subnetpool. However, when a subnet uses
IPv6 prefix delegation this is automatically setted when creating de
subnet and if we try to read information about a subnetpool called
"prefix_delega
[Yahoo-eng-team] [Bug 1700546] Re: Translate to first word capital for new visibility type `shared` in glance images page
Reviewed: https://review.openstack.org/477532 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=c9f541ec1cce0dc5a85fb87c4116b722c2fb0770 Submitter: Jenkins Branch:master commit c9f541ec1cce0dc5a85fb87c4116b722c2fb0770 Author: Alok Kumar Date: Mon Jun 26 18:50:16 2017 +0530 Capitalize shared|community visibility for images Added new visibility type `shared` and `community` to be displayed in capital case as `Shared` or `Community` in image listing page. Similar to `public` ==> `Public` `private` ==> `Private` ` Closes Bug: #1700546 Change-Id: Ia82bcd026412ad14a98dd5dca5b83eee14113e59 ** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1700546 Title: Translate to first word capital for new visibility type `shared` in glance images page Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Presently on listing images page, `public` or `private` visibility type is capitalised. Add change to do the same for new visibility type `shared` too. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1700546/+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 1253497] Re: Replace uuidutils.generate_uuid() with str(uuid.uuid4())
** No longer affects: neutron ** No longer affects: horizon -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1253497 Title: Replace uuidutils.generate_uuid() with str(uuid.uuid4()) Status in Barbican: Fix Released Status in BillingStack: Invalid Status in Blazar: Fix Committed Status in Cinder: Invalid Status in Designate: Fix Released Status in Glance: Fix Released Status in heat: Fix Released Status in Ironic: Fix Released Status in Karbor: New Status in Manila: Fix Released Status in OpenStack Compute (nova): Invalid Status in oslo-incubator: Fix Released Status in Sahara: Fix Released Status in staccato: Invalid Status in taskflow: Invalid Status in OpenStack DBaaS (Trove): Fix Released Status in tuskar: Fix Released Bug description: http://lists.openstack.org/pipermail/openstack- dev/2013-November/018980.html > Hi all, > > We had a discussion of the modules that are incubated in Oslo. > > https://etherpad.openstack.org/p/icehouse-oslo-status > > One of the conclusions we came to was to deprecate/remove uuidutils in > this cycle. > > The first step into this change should be to remove generate_uuid() from > uuidutils. > > The reason is that 1) generating the UUID string seems trivial enough to > not need a function and 2) string representation of uuid4 is not what we > want in all projects. > > To address this, a patch is now on gerrit. > https://review.openstack.org/#/c/56152/ > > Each project should directly use the standard uuid module or implement its > own helper function to generate uuids if this patch gets in. > > Any thoughts on this change? Thanks. > Unfortunately it looks like that change went through before I caught up on email. Shouldn't we have removed its use in the downstream projects (at least integrated projects) before removing it from Oslo? Doug To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1253497/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1702925] Re: The servers group api is called even if the policy disallows it [launch instance modal]
Reviewed: https://review.openstack.org/481682 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=f93c546c141ce2ba4356c5e57c8c5e1663663a83 Submitter: Jenkins Branch:master commit f93c546c141ce2ba4356c5e57c8c5e1663663a83 Author: Pascal Boutin Date: Fri Jul 7 11:44:04 2017 -0400 Prevent getServerGroups if the policy disallows it The old implementation did not wait for the promise to resolve before doing the call, thus ignoring the policy. Change-Id: I2a7a55ddf287e660371dd6b268953a75afa2a380 Closes-Bug: #1702925 ** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1702925 Title: The servers group api is called even if the policy disallows it [launch instance modal] Status in OpenStack Dashboard (Horizon): Fix Released Bug description: When the "os_compute_api:os-server-groups:discoverable" from the nova policy is disabled, a call is make to this api when the launch instance modal is opened, resulting into an 404 error. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1702925/+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 1703602] [NEW] Wrong snapshot usage info
Public bug reported: When creating snapshot on the page of creating we can see count of used snapshot that is based on tenants quotas. But now we see volumes' usage instead of snapshots'. The reason - this line [0] always uses volumes data instead of snapshots data. We already have necessary info in snapshot_limit template here [1], but we don't use it. [0] - https://github.com/openstack/horizon/blob/29a6ed4cc06ef9cbadee311c947fe19308a387ed/openstack_dashboard/dashboards/project/volumes/templates/volumes/_limits.html#L42 [1] - https://github.com/openstack/horizon/blob/29a6ed4cc06ef9cbadee311c947fe19308a387ed/openstack_dashboard/dashboards/project/volumes/templates/volumes/_snapshot_limits.html#L24-L30 ** Affects: horizon Importance: Undecided Assignee: Michael Dovgal (mdovgal) Status: In Progress -- 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/1703602 Title: Wrong snapshot usage info Status in OpenStack Dashboard (Horizon): In Progress Bug description: When creating snapshot on the page of creating we can see count of used snapshot that is based on tenants quotas. But now we see volumes' usage instead of snapshots'. The reason - this line [0] always uses volumes data instead of snapshots data. We already have necessary info in snapshot_limit template here [1], but we don't use it. [0] - https://github.com/openstack/horizon/blob/29a6ed4cc06ef9cbadee311c947fe19308a387ed/openstack_dashboard/dashboards/project/volumes/templates/volumes/_limits.html#L42 [1] - https://github.com/openstack/horizon/blob/29a6ed4cc06ef9cbadee311c947fe19308a387ed/openstack_dashboard/dashboards/project/volumes/templates/volumes/_snapshot_limits.html#L24-L30 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1703602/+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 1682060] Re: empty nova service and hypervisor list
** Also affects: kolla-ansible/ocata 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/1682060 Title: empty nova service and hypervisor list Status in kolla-ansible: Fix Released Status in kolla-ansible ocata series: New Status in OpenStack Compute (nova): Fix Released Status in openstack-manuals: Fix Released Bug description: In current master, openstack compute service list and openstack hypervisor list (same issue with nova cli) result in an empty list. If I check the database, services are registered in the database. [root@controller tools]# docker exec -ti kolla_toolbox mysql -unova -pYVDa3l8vA57Smnbu9Q5qdgSKJckNxP3Q3rYvVxsD -h 192.168.100.10 nova -e "SELECT * from services WHERE topic = 'compute'"; +-+-++++--+-+--+--+-+-+-+-+-+ | created_at | updated_at | deleted_at | id | host | binary | topic | report_count | disabled | deleted | disabled_reason | last_seen_up| forced_down | version | +-+-++++--+-+--+--+-+-+-+-+-+ | 2017-04-12 09:12:10 | 2017-04-12 09:14:33 | NULL | 9 | controller | nova-compute | compute | 13 |0 | 0 | NULL| 2017-04-12 09:14:33 | 0 | 17 | +-+-++++--+-+--+--+-+-+-+-+-+ [root@controller tools]# openstack compute service list --long [root@controller tools]# [root@controller tools]# openstack hypervisor list --long [root@controller tools]# Logs from kolla deploy gates http://logs.openstack.org/08/456108/1/check/gate-kolla-dsvm-deploy- centos-source-centos-7-nv/9cf1e73/ Environment: - source code - OS: centos/ubuntu/oraclelinux - Deployment type: kolla-ansible Please let me know if more info is needed or if there is a workaround. Regards To manage notifications about this bug go to: https://bugs.launchpad.net/kolla-ansible/+bug/1682060/+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 1703584] [NEW] Get rid of redundant cinder api calls
Public bug reported:
During executing tenant_limit_usages quotas function here [0] we get
information about cinder volumes/snapshots/gigabites usage. Like this:
{u'maxTotalBackupGigabytes': 1000,
u'maxTotalBackups': 10,
u'maxTotalSnapshots': 10,
u'maxTotalVolumeGigabytes': 1000,
u'maxTotalVolumes': 10,
u'totalBackupGigabytesUsed': 1,
u'totalBackupsUsed': 1,
u'totalGigabytesUsed': 8,
u'totalSnapshotsUsed': 1,
u'totalVolumesUsed': 6
}
After it here [1] we trying to get the same information as we've already got
and add it one more time to limits dict here [2]
Also these calls slows down the application, so we need to get rid of them.
[0] -
https://github.com/openstack/horizon/blob/29a6ed4cc06ef9cbadee311c947fe19308a387ed/openstack_dashboard/usage/quotas.py#L489
https://github.com/openstack/horizon/blob/29a6ed4cc06ef9cbadee311c947fe19308a387ed/openstack_dashboard/usage/quotas.py#L490-L491
[2] -
https://github.com/openstack/horizon/blob/29a6ed4cc06ef9cbadee311c947fe19308a387ed/openstack_dashboard/usage/quotas.py#L497-L499
** Affects: horizon
Importance: Undecided
Assignee: Michael Dovgal (mdovgal)
Status: In Progress
** Description changed:
During executing tenant_limit_usages quotas function here [0] we get
information about cinder volumes/snapshots/gigabites usage. Like this:
{u'maxTotalBackupGigabytes': 1000,
- u'maxTotalBackups': 10,
- u'maxTotalSnapshots': 10,
- u'maxTotalVolumeGigabytes': 1000,
- u'maxTotalVolumes': 10,
- u'totalBackupGigabytesUsed': 1,
- u'totalBackupsUsed': 1,
- u'totalGigabytesUsed': 8,
- u'totalSnapshotsUsed': 1,
- u'totalVolumesUsed': 6
+ u'maxTotalBackups': 10,
+ u'maxTotalSnapshots': 10,
+ u'maxTotalVolumeGigabytes': 1000,
+ u'maxTotalVolumes': 10,
+ u'totalBackupGigabytesUsed': 1,
+ u'totalBackupsUsed': 1,
+ u'totalGigabytesUsed': 8,
+ u'totalSnapshotsUsed': 1,
+ u'totalVolumesUsed': 6
}
- After it here [1] we trying to get the same information as we've already got.
+ After it here [1] we trying to get the same information as we've already got
and add it one more time to limits dict here [2]
Also these calls slows down the application, so we need to get rid of them.
-
- [0] -
https://github.com/openstack/horizon/blob/29a6ed4cc06ef9cbadee311c947fe19308a387ed/openstack_dashboard/usage/quotas.py#L489
+ [0] -
+
https://github.com/openstack/horizon/blob/29a6ed4cc06ef9cbadee311c947fe19308a387ed/openstack_dashboard/usage/quotas.py#L489
https://github.com/openstack/horizon/blob/29a6ed4cc06ef9cbadee311c947fe19308a387ed/openstack_dashboard/usage/quotas.py#L490-L491
+ [2] -
https://github.com/openstack/horizon/blob/29a6ed4cc06ef9cbadee311c947fe19308a387ed/openstack_dashboard/usage/quotas.py#L497-L499
--
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/1703584
Title:
Get rid of redundant cinder api calls
Status in OpenStack Dashboard (Horizon):
In Progress
Bug description:
During executing tenant_limit_usages quotas function here [0] we get
information about cinder volumes/snapshots/gigabites usage. Like this:
{u'maxTotalBackupGigabytes': 1000,
u'maxTotalBackups': 10,
u'maxTotalSnapshots': 10,
u'maxTotalVolumeGigabytes': 1000,
u'maxTotalVolumes': 10,
u'totalBackupGigabytesUsed': 1,
u'totalBackupsUsed': 1,
u'totalGigabytesUsed': 8,
u'totalSnapshotsUsed': 1,
u'totalVolumesUsed': 6
}
After it here [1] we trying to get the same information as we've already got
and add it one more time to limits dict here [2]
Also these calls slows down the application, so we need to get rid of them.
[0] -
https://github.com/openstack/horizon/blob/29a6ed4cc06ef9cbadee311c947fe19308a387ed/openstack_dashboard/usage/quotas.py#L489
https://github.com/openstack/horizon/blob/29a6ed4cc06ef9cbadee311c947fe19308a387ed/openstack_dashboard/usage/quotas.py#L490-L491
[2] -
https://github.com/openstack/horizon/blob/29a6ed4cc06ef9cbadee311c947fe19308a387ed/openstack_dashboard/usage/quotas.py#L497-L499
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1703584/+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 1253497] Re: Replace uuidutils.generate_uuid() with str(uuid.uuid4())
** No longer affects: murano -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1253497 Title: Replace uuidutils.generate_uuid() with str(uuid.uuid4()) Status in Barbican: Fix Released Status in BillingStack: Invalid Status in Blazar: Fix Committed Status in Cinder: Invalid Status in Designate: Fix Released Status in Glance: Fix Released Status in heat: Fix Released Status in OpenStack Dashboard (Horizon): Invalid Status in Ironic: Fix Released Status in Karbor: New Status in Manila: Fix Released Status in neutron: Invalid Status in OpenStack Compute (nova): Invalid Status in oslo-incubator: Fix Released Status in Sahara: Fix Released Status in staccato: Invalid Status in taskflow: Invalid Status in OpenStack DBaaS (Trove): Fix Released Status in tuskar: Fix Released Bug description: http://lists.openstack.org/pipermail/openstack- dev/2013-November/018980.html > Hi all, > > We had a discussion of the modules that are incubated in Oslo. > > https://etherpad.openstack.org/p/icehouse-oslo-status > > One of the conclusions we came to was to deprecate/remove uuidutils in > this cycle. > > The first step into this change should be to remove generate_uuid() from > uuidutils. > > The reason is that 1) generating the UUID string seems trivial enough to > not need a function and 2) string representation of uuid4 is not what we > want in all projects. > > To address this, a patch is now on gerrit. > https://review.openstack.org/#/c/56152/ > > Each project should directly use the standard uuid module or implement its > own helper function to generate uuids if this patch gets in. > > Any thoughts on this change? Thanks. > Unfortunately it looks like that change went through before I caught up on email. Shouldn't we have removed its use in the downstream projects (at least integrated projects) before removing it from Oslo? Doug To manage notifications about this bug go to: https://bugs.launchpad.net/barbican/+bug/1253497/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1696264] Re: Create OpenStack client environment scripts in Installation Guide INCOMPLETE - doesn't state path for file
** Also affects: keystone Importance: Undecided Status: New ** Changed in: keystone Status: New => In Progress ** Changed in: keystone Assignee: (unassigned) => wingwj (wingwj) -- 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/1696264 Title: Create OpenStack client environment scripts in Installation Guide INCOMPLETE - doesn't state path for file Status in OpenStack Identity (keystone): In Progress Status in openstack-manuals: In Progress Bug description: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [X] This doc is inaccurate in this way: It says to create a file but doesn't say where... so I can't. So I'm stuck. - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - Ask OpenStack: http://ask.openstack.org - The mailing list: http://lists.openstack.org - IRC: 'openstack' channel on Freenode --- Release: 15.0.0 on 2017-06-02 17:52 SHA: 3d8b9d021dd5f85bb0f0232a0475271d7f5537fc Source: https://git.openstack.org/cgit/openstack/openstack-manuals/tree/doc/install-guide/source/keystone-openrc.rst URL: https://docs.openstack.org/ocata/install-guide-ubuntu/keystone-openrc.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1696264/+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 1703540] [NEW] Reschedule with libvirt exception leaves dangling neutron ports
Public bug reported: When an instance fails to spawn, for example with the exception: 2017-07-11 04:39:56.942 ERROR nova.compute.manager [req-1e54a66a-6da5-4720-89cc-f65568dea131 ashok ashok] [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] Instance failed to spawn 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] Traceback (most recent call last): 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] File "/opt/stack/nova/nova/compute/manager.py", line 2124, in _build_resources 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] yield resources 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] File "/opt/stack/nova/nova/compute/manager.py", line 1930, in _build_and_run_instance 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] block_device_info=block_device_info) 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 2714, in spawn 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] destroy_disks_on_failure=True) 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 5130, in _create_domain_and_network 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] destroy_disks_on_failure) 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] self.force_reraise() 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] six.reraise(self.type_, self.value, self.tb) 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 5102, in _create_domain_and_network 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] post_xml_callback=post_xml_callback) 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] File "/opt/stack/nova/nova/virt/libvirt/driver.py", line 5020, in _create_domain 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] guest.launch(pause=pause) 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] File "/opt/stack/nova/nova/virt/libvirt/guest.py", line 145, in launch 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] self._encoded_xml, errors='ignore') 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] self.force_reraise() 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] six.reraise(self.type_, self.value, self.tb) 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] File "/opt/stack/nova/nova/virt/libvirt/guest.py", line 140, in launch 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] return self._domain.createWithFlags(flags) 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] File "/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 186, in doit 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] result = proxy_call(self._autowrap, f, *args, **kwargs) 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] File "/usr/local/lib/python2.7/dist-packages/eventlet/tpool.py", line 144, in proxy_call 2017-07-11 04:39:56.942 TRACE nova.compute.manager [instance: d37e6882-8c94-47dc-8c2f-c9052a25b95b] rv = execute(f, *arg
