[Yahoo-eng-team] [Bug 1753661] [NEW] missing description field for instance update/rebuild

[Liyingjun]

Public bug reported:

Description is supported when creating instance, this bug is reported to
request support update description for instance.

** Affects: horizon
 Importance: Undecided
 Assignee: Liyingjun (liyingjun)
 Status: New

** Changed in: horizon
 Assignee: (unassigned) => Liyingjun (liyingjun)

-- 
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/1753661

Title:
  missing description field for instance update/rebuild

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Description is supported when creating instance, this bug is reported
  to request support update description for instance.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1753661/+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 1753656] [NEW] Cannot update ssl certificate when update listener

[Min Sun]

Public bug reported:

   Description
   ===
   Cannot update ssl certificate when update listener

   Steps to reproduce
   ==
   1. Create one load balancer, choose "TERMINATED_HTTPS" as listener protocol 
and select a certificate
   2. Edit the existed listener with another certificate

   Expected result
   ===
   Listener should be updated successfully

   Actual result
   =
   Update listener success, but only the name and description of the listener 
has been updated. Certificate remains same as old one.

** 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/1753656

Title:
  Cannot update ssl certificate when update listener

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
 Description
 ===
 Cannot update ssl certificate when update listener

 Steps to reproduce
 ==
 1. Create one load balancer, choose "TERMINATED_HTTPS" as listener 
protocol and select a certificate
 2. Edit the existed listener with another certificate

 Expected result
 ===
 Listener should be updated successfully

 Actual result
 =
 Update listener success, but only the name and description of the listener 
has been updated. Certificate remains same as old one.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1753656/+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 1644725] Re: Check destination_type when booting with bdm provided

[Takashi NATSUME]

The issue was fixed in python-novaclient 7.0.0.

** Changed in: python-novaclient
   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/1644725

Title:
  Check destination_type when booting with bdm provided

Status in Cinder:
  New
Status in OpenStack Compute (nova):
  Opinion
Status in python-novaclient:
  Fix Released

Bug description:
  When booting instance with block_device_mapping provided, in the
  current implementation, the "destination_type" is allowed to be None,
  and this lead to un-sync between Nova and Cinder:

  Step 1: Booting with block_device_mapping, leave destination_type to
  be None:

  root@SZX1000191849:/var/log/nova# nova --debug boot  --flavor 1
  --image 2ba75018-403f-407b-864a-08564022e1f8 --nic net-
  id=cce1d2f1-acf4-4646-abdc-069f8d0dbb71 --block-device
  'source=volume,id=9f49d5b0-3625-46a2-9ed4-d82f19949148' test_bdm

  the corresponding REST call is:
  DEBUG (session:342) REQ: curl -g -i -X POST 
http://10.229.45.17:8774/v2.1/os-volumes_boot -H "Accept: application/json" -H 
"User-Agent: python-novaclient" -H "OpenStack-API-Version: compute 2.37" -H 
"X-OpenStack-Nova-API-Version: 2.37" -H "X-Auth-Token: 
{SHA1}4d8c2c43338e1c4d96e08bcd1c2f3ff36de14154" -H "Content-Type: 
application/json" -d '{"server": {"name": "test_bdm", "imageRef": 
"2ba75018-403f-407b-864a-08564022e1f8", "block_device_mapping_v2": 
[{"source_type": "image", "delete_on_termination": true, "boot_index": 0, 
"uuid": "2ba75018-403f-407b-864a-08564022e1f8", "destination_type": "local"}, 
{"source_type": "volume", "uuid": "9f49d5b0-3625-46a2-9ed4-d82f19949148"}], 
"flavorRef": "1", "max_count": 1, "min_count": 1, "networks": [{"uuid": 
"cce1d2f1-acf4-4646-abdc-069f8d0dbb71"}]}}'

  Step 2: After the instance is successfully launched, the detailed info
  is like this:

  root@SZX1000191849:/var/log/nova# nova show 
83d9ec32-93e0-441a-ae10-00e08b65de0b
  
+--+--+
  | Property | Value
|
  
+--+--+
  | OS-DCF:diskConfig| MANUAL   
|
  | OS-EXT-AZ:availability_zone  | nova 
|
  | OS-EXT-SRV-ATTR:host | SZX1000191849
|
  | OS-EXT-SRV-ATTR:hostname | test-bdm 
|
  | OS-EXT-SRV-ATTR:hypervisor_hostname  | SZX1000191849
|
  | OS-EXT-SRV-ATTR:instance_name| instance-0016
|
  | OS-EXT-SRV-ATTR:kernel_id| 87c9afd6-3a47-4a4c-a804-6b456d68136d 
|
  | OS-EXT-SRV-ATTR:launch_index | 0
|
  | OS-EXT-SRV-ATTR:ramdisk_id   | acd02b28-6484-4f90-a5e7-bba7159343e1 
|
  | OS-EXT-SRV-ATTR:reservation_id   | r-fiqwkq02   
|
  | OS-EXT-SRV-ATTR:root_device_name | /dev/vda 
|
  | OS-EXT-SRV-ATTR:user_data| -
|
  | OS-EXT-STS:power_state   | 1
|
  | OS-EXT-STS:task_state| -
|
  | OS-EXT-STS:vm_state  | active   
|
  | OS-SRV-USG:launched_at   | 2016-11-25T06:50:36.00   
|
  | OS-SRV-USG:terminated_at | -
|
  | accessIPv4   |  
|
  | accessIPv6   |  
|
  | config_drive |  
|
  | created

[Yahoo-eng-team] [Bug 1616274] Re: external dns doesnt get updated

[Launchpad Bug Tracker]

[Expired for neutron because there has been no activity for 60 days.]

** Changed in: neutron
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1616274

Title:
  external dns doesnt get updated

Status in neutron:
  Expired

Bug description:
  The current logic [1] only passes info to external DNS under the
  following circumstances:

  * The network is a flat non-provider network
  * The network has 2 or more subnets

  These are strange requirements to say the least, but I see no reason
  not to be setting DNS for every instance spawn, regardless of network
  type.

  [1]
  
https://github.com/openstack/neutron/blob/64f5fc82596ec6b78b76ca5d9cfc1d4b5a0b975d/neutron/plugins/ml2/extensions/dns_integration.py#L292

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1616274/+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 1696048] Re: Neutron/designate sync in OS Newton

[Launchpad Bug Tracker]

[Expired for neutron because there has been no activity for 60 days.]

** Changed in: neutron
   Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1696048

Title:
  Neutron/designate sync in OS Newton

Status in neutron:
  Expired

Bug description:
  Hi
  I installed designate on Newton openstack in Centos 7.3.
  After complete designate setup as indicated in
  https://docs.openstack.org/project-install-guide/dns/ocata/install-rdo.html 
(I have not found specific doc for newton).
- All processes are running (central, api, mdns, worker, producer, sink)
- I created zone with my domain.
- I updated my network to indicates domain name ( update with --dns-domain)
- I updated my server.conf on the 3 HA neutron servers (add '[designate]' 
group directives, add final dot to my [default] 'dns_domain' attribute and add 
in '[default]' the driver : 'external_dns_driver = designate'.
- I updated my ml2 plugin to add 'dns' in 'extension_drivers' attribute.
- I restarted neutron servers.
  All commands as 'openstack dns service list' and 'openstack zone list and 
openstack recordset list xxx' are ok.
  Now, when i create a VM from dashboard, the VM is created without problem (as 
without designate) but no recordset is created. I don't see any call to port 
9001 in api log. It seems that designate plugin is not called...
  So to debug :
- I installed devstack/newton with designate.
- Analyzing neutron log, I've set some logging into 
neutron.plugins.ml2.extensions.dns_integration.py as it contains callbacks used 
by neutron.
  When I create an instance on the private newtork (which has dns_domain set to 
my test domain) neutron schedules the callback 
'_create_port_in_external_dns_service'.

  So, I set into it some trace and the problem is that function return
  because port id (newly created) is not in db :

  ...
  def _create_port_in_external_dns_service(resource, event, trigger, **kwargs):
 dns_driver = _get_dns_driver()
 if not dns_driver:
LOG.info(_LE("NO DRIVER"))
return
 context = kwargs['context']
 port = kwargs['port']
 dns_data_db = context.session.query(dns_db.PortDNS).filter_by(
 port_id=port['id']).one_or_none()
 LOG.info(_LE("PORT : " + port['id']))<- port id is really id 
newly created
 if not (dns_data_db and dns_data_db['current_dns_name']):
LOG.info(_LE("NO DNS_DATA_DB : "))
return<- I return here !
 records = [ip['ip_address'] for ip in port['fixed_ips']]
 _send_data_to_external_dns_service(context, dns_driver,
dns_data_db['current_dns_domain'],
dns_data_db['current_dns_name'],
records)
  ...

  After VM creation, if I do a 'openstack port list', port id is present !
  Async problem ?
  Many thanks

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1696048/+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 1753380] Re: Lbaasv2 Update listener failed

[Min Sun]

*** This bug is a duplicate of bug 1720313 ***
https://bugs.launchpad.net/bugs/1720313

** This bug has been marked a duplicate of bug 1720313
   update HTTPS protocol loadbalancer's listener occured error

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1753380

Title:
  Lbaasv2 Update listener failed

Status in neutron:
  New

Bug description:
 Description
 ===
 Lbaasv2 update listener failed with AttributeError: 'dict' object has no 
attribute 'tls_container_id'

 Steps to reproduce
 ==
 1. Create one load balancer, choose "TERMINATED_HTTPS" as listener 
protocol and select a certificate
 2. Edit the existed listener with another certificate

 Expected result
 ===
 Listener should be updated successfully

 Actual result
 =
 Update listener fail with AttributeError: 'dict' object has no attribute 
'tls_container_id'

 2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource 
[req-4ff29fcc-5c4e-4a1c-980d-bc8bac5993ef bcd78d3b2dfd49daac46fb056b81d7cd 
f4c794a249b34eb992f497f0e6af2a28 - - -] update failed: No details.
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource Traceback 
(most recent call last):
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/neutron/api/v2/resource.py", line 79, in 
resource
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource result = 
method(request=request, **args)
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/neutron/api/v2/base.py", line 604, in update
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource return 
self._update(request, id, body, **kwargs)
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/neutron/db/api.py", line 88, in wrapped
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource 
setattr(e, '_RETRY_EXCEEDED', True)
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource 
self.force_reraise()
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource 
six.reraise(self.type_, self.value, self.tb)
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/neutron/db/api.py", line 84, in wrapped
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource return 
f(*args, **kwargs)
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/oslo_db/api.py", line 151, in wrapper
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource 
ectxt.value = e.inner_exc
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource 
self.force_reraise()
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource 
six.reraise(self.type_, self.value, self.tb)
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/oslo_db/api.py", line 139, in wrapper
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource return 
f(*args, **kwargs)
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/neutron/db/api.py", line 124, in wrapped
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource 
traceback.format_exc())
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 220, in __exit__
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource 
self.force_reraise()
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 196, in 
force_reraise
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource 
six.reraise(self.type_, self.value, self.tb)
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource   File 
"/usr/lib/python2.7/site-packages/neutron/db/api.py", line 119, in wrapped
  2018-03-05 07:01:01.914 325616 ERROR neutron.api.v2.resource return 
f(*dup_args, **dup_kwargs)
  

[Yahoo-eng-team] [Bug 1753585] [NEW] LDAP user name attribute is case sensitive

[Matthew Edmonds]

Public bug reported:

keystone was not able to find any users while the LDAP user name
attribute was configured to "samaccountname", but could find users when
reconfigured to use "sAMAccountName". LDAP is not supposed to be case-
sensitive, so either should work.

This appears to be a result of
https://github.com/openstack/keystone/blob/12.0.0.0rc2/keystone/identity/backends/ldap/common.py#L1403
looking for that attribute in a case-sensitive manner, though there may
be other places as well.

found in: Pike

** Affects: keystone
 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/1753585

Title:
  LDAP user name attribute is case sensitive

Status in OpenStack Identity (keystone):
  New

Bug description:
  keystone was not able to find any users while the LDAP user name
  attribute was configured to "samaccountname", but could find users
  when reconfigured to use "sAMAccountName". LDAP is not supposed to be
  case-sensitive, so either should work.

  This appears to be a result of
  
https://github.com/openstack/keystone/blob/12.0.0.0rc2/keystone/identity/backends/ldap/common.py#L1403
  looking for that attribute in a case-sensitive manner, though there
  may be other places as well.

  found in: Pike

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1753585/+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 1753584] [NEW] incorrect ImportError message raised

[Mark Hamzy]

Public bug reported:

Logs show:

2018-03-05 20:50:01.665 35 WARNING stevedore.named [-] Could not load uuid
2018-03-05 20:50:01.666 35 CRITICAL keystone [-] Unhandled error: ImportError: 
(u'Unable to find %(name)r driver in %(namespace)r.',
 {'namespace': 'keystone.token.provider', 'name': 'uuid'})
2018-03-05 20:50:01.666 35 ERROR keystone Traceback (most recent call last):
2018-03-05 20:50:01.666 35 ERROR keystone   File 
"/var/lib/kolla/venv/bin/keystone-manage", line 10, in 
2018-03-05 20:50:01.666 35 ERROR keystone sys.exit(main())
2018-03-05 20:50:01.666 35 ERROR keystone   File 
"/var/lib/kolla/venv/lib/python2.7/site-packages/keystone/cmd/manage.py", line 
45, 
in main
2018-03-05 20:50:01.666 35 ERROR keystone cli.main(argv=sys.argv, 
config_files=config_files)
2018-03-05 20:50:01.666 35 ERROR keystone   File 
"/var/lib/kolla/venv/lib/python2.7/site-packages/keystone/cmd/cli.py", line 
1349, i
n main
2018-03-05 20:50:01.666 35 ERROR keystone CONF.command.cmd_class.main()
2018-03-05 20:50:01.666 35 ERROR keystone   File 
"/var/lib/kolla/venv/lib/python2.7/site-packages/keystone/cmd/cli.py", line 
397, in
 main
2018-03-05 20:50:01.666 35 ERROR keystone klass = cls()
2018-03-05 20:50:01.666 35 ERROR keystone   File 
"/var/lib/kolla/venv/lib/python2.7/site-packages/keystone/cmd/cli.py", line 66, 
in 
__init__
2018-03-05 20:50:01.666 35 ERROR keystone self.load_backends()
2018-03-05 20:50:01.666 35 ERROR keystone   File 
"/var/lib/kolla/venv/lib/python2.7/site-packages/keystone/cmd/cli.py", line 
129, in
 load_backends
2018-03-05 20:50:01.666 35 ERROR keystone drivers = backends.load_backends()
2018-03-05 20:50:01.666 35 ERROR keystone   File 
"/var/lib/kolla/venv/lib/python2.7/site-packages/keystone/server/backends.py", 
line
 53, in load_backends
2018-03-05 20:50:01.666 35 ERROR keystone drivers = {d._provides_api: d() 
for d in managers}
2018-03-05 20:50:01.666 35 ERROR keystone   File 
"/var/lib/kolla/venv/lib/python2.7/site-packages/keystone/server/backends.py", 
line
 53, in 
2018-03-05 20:50:01.666 35 ERROR keystone drivers = {d._provides_api: d() 
for d in managers}
2018-03-05 20:50:01.666 35 ERROR keystone   File 
"/var/lib/kolla/venv/lib/python2.7/site-packages/keystone/token/provider.py", 
line 
65, in __init__
2018-03-05 20:50:01.666 35 ERROR keystone super(Manager, 
self).__init__(CONF.token.provider)
2018-03-05 20:50:01.666 35 ERROR keystone   File 
"/var/lib/kolla/venv/lib/python2.7/site-packages/keystone/common/manager.py", 
line 
181, in __init__
2018-03-05 20:50:01.666 35 ERROR keystone self.driver = 
load_driver(self.driver_namespace, driver_name)
2018-03-05 20:50:01.666 35 ERROR keystone   File 
"/var/lib/kolla/venv/lib/python2.7/site-packages/keystone/common/manager.py", 
line 
81, in load_driver
2018-03-05 20:50:01.666 35 ERROR keystone raise ImportError(msg, {'name': 
driver_name, 'namespace': namespace})
2018-03-05 20:50:01.666 35 ERROR keystone ImportError: (u'Unable to find 
%(name)r driver in %(namespace)r.', {'namespace': 'keystone
.token.provider', 'name': 'uuid'})
2018-03-05 20:50:01.666 35 ERROR keystone 

which is misleading.  The correct error should be:

2018-03-05 20:50:25.517 47 ERROR keystone ImportError: Unable to find
'uuid' driver in 'keystone.token.provider'.

** Affects: keystone
 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/1753584

Title:
  incorrect ImportError message raised

Status in OpenStack Identity (keystone):
  New

Bug description:
  Logs show:

  2018-03-05 20:50:01.665 35 WARNING stevedore.named [-] Could not load uuid
  2018-03-05 20:50:01.666 35 CRITICAL keystone [-] Unhandled error: 
ImportError: (u'Unable to find %(name)r driver in %(namespace)r.',
   {'namespace': 'keystone.token.provider', 'name': 'uuid'})
  2018-03-05 20:50:01.666 35 ERROR keystone Traceback (most recent call last):
  2018-03-05 20:50:01.666 35 ERROR keystone   File 
"/var/lib/kolla/venv/bin/keystone-manage", line 10, in 
  2018-03-05 20:50:01.666 35 ERROR keystone sys.exit(main())
  2018-03-05 20:50:01.666 35 ERROR keystone   File 
"/var/lib/kolla/venv/lib/python2.7/site-packages/keystone/cmd/manage.py", line 
45, 
  in main
  2018-03-05 20:50:01.666 35 ERROR keystone cli.main(argv=sys.argv, 
config_files=config_files)
  2018-03-05 20:50:01.666 35 ERROR keystone   File 
"/var/lib/kolla/venv/lib/python2.7/site-packages/keystone/cmd/cli.py", line 
1349, i
  n main
  2018-03-05 20:50:01.666 35 ERROR keystone CONF.command.cmd_class.main()
  2018-03-05 20:50:01.666 35 ERROR keystone   File 
"/var/lib/kolla/venv/lib/python2.7/site-packages/keystone/cmd/cli.py", line 
397, in
   main
  2018-03-05 20:50:01.666 35 ERROR keystone klass = cls()
  2018-03-05 20:50:01.666 35 ERROR keystone   File 

[Yahoo-eng-team] [Bug 1422674] Re: Glance can't share images via Horizon dashboard but can show shared images.

[George]

It would be great if this feature can be added to dashboard.

Asking the users to install python-glanceclient or python-
openstackclient in order to share an image or snapshot makes for a poor
user experience.

Thank you.

** Changed in: horizon
   Status: Expired => Confirmed

-- 
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/1422674

Title:
  Glance can't share images via Horizon dashboard but can show shared
  images.

Status in OpenStack Dashboard (Horizon):
  Confirmed

Bug description:
  Glance have functions for share uploaded images with other tenants.
  But this functional is unavailable via Horizon Dashboard.

  in Project > Compute > Images we can see category named 'Shared with
  me', but user can't share image.

  From CLI this work correctly.

  Steps: 
  1. Deploy OS with Horizon Dashboard
  2. Upload an image to Glance from admin tenant and don't set Public = True in 
image options.
  3. SSH to controller node, use . openrc.
  4. Execute `glance member-create` to share image with other non-admin tenant.
  5. Log into Horizon as user, which we shared an image.
  6. Navigate to Project> Compute > Images

  Actual result:
  Image, which shared with this tenant was appeared in category 'Shared With Me'

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1422674/+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 1752660] Re: python-cryptography missing cffi dependency

[Corey Bryant]

I think our long-term fix will come from the Debian maintainer's
approach to adding dependencies. I'm going to fix this in Ubuntu for now
by adding python-cffi to debian/control Depends.

** Summary changed:

- keystone requires cffi to be installed for fernat tokens
+ python-cryptography missing cffi dependency

** Also affects: cloud-archive/mitaka
   Importance: Undecided
   Status: New

** Also affects: cloud-archive/queens
   Importance: High
   Status: Triaged

** Also affects: cloud-archive/newton
   Importance: Undecided
   Status: New

** Also affects: cloud-archive/pike
   Importance: Undecided
   Status: New

** Also affects: cloud-archive/ocata
   Importance: Undecided
   Status: New

** Changed in: cloud-archive/pike
   Status: New => Triaged

** Changed in: cloud-archive/ocata
   Status: New => Triaged

** Changed in: cloud-archive/newton
   Status: New => Triaged

** Changed in: cloud-archive/mitaka
   Status: New => Triaged

** Changed in: cloud-archive/pike
   Importance: Undecided => High

** Changed in: cloud-archive/ocata
   Importance: Undecided => High

** Changed in: cloud-archive/mitaka
   Importance: Undecided => High

** Changed in: cloud-archive/newton
   Importance: Undecided => High

** Also affects: keystone (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: python-cryptography (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: keystone (Ubuntu Bionic)
   Importance: Undecided
   Status: Invalid

** Also affects: python-cryptography (Ubuntu Bionic)
   Importance: High
   Status: Triaged

** Also affects: keystone (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Also affects: python-cryptography (Ubuntu Artful)
   Importance: Undecided
   Status: New

** Changed in: python-cryptography (Ubuntu Xenial)
   Status: New => Triaged

** No longer affects: keystone (Ubuntu Artful)

** No longer affects: keystone

** No longer affects: keystone (Ubuntu)

** No longer affects: keystone (Ubuntu Xenial)

** No longer affects: keystone (Ubuntu Bionic)

** Changed in: python-cryptography (Ubuntu Artful)
   Importance: Undecided => High

** Changed in: python-cryptography (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: python-cryptography (Ubuntu Artful)
   Status: New => 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/1752660

Title:
  python-cryptography missing cffi dependency

Status in Ubuntu Cloud Archive:
  Triaged
Status in Ubuntu Cloud Archive mitaka series:
  Triaged
Status in Ubuntu Cloud Archive newton series:
  Triaged
Status in Ubuntu Cloud Archive ocata series:
  Triaged
Status in Ubuntu Cloud Archive pike series:
  Triaged
Status in Ubuntu Cloud Archive queens series:
  Triaged
Status in python-cryptography package in Ubuntu:
  Triaged
Status in python-cryptography source package in Xenial:
  Triaged
Status in python-cryptography source package in Artful:
  Triaged
Status in python-cryptography source package in Bionic:
  Triaged

Bug description:
  When installing keystone (via apt-get install keystone) apt does not
  install python-cffi, which is required for keystone to implement
  fernat tokens (the current recommended token type)

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: keystone 2:13.0.0-0ubuntu1~cloud0 [origin: Canonical]
  Uname: Linux 4.4.88-mainline-rev1 x86_64
  ApportVersion: 2.20.1-0ubuntu2.15
  Architecture: amd64
  CrashDB:
   {
  "impl": "launchpad",
  "project": "cloud-archive",
  "bug_pattern_url": 
"http://people.canonical.com/~ubuntu-archive/bugpatterns/bugpatterns.xml;,
   }
  Date: Thu Mar  1 17:19:34 2018
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: keystone
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.keystone.keystone.conf: 2018-03-01T16:51:52.734036

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1752660/+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 1753443] Re: os_nova: upgrade_levels/compute=auto failure on master

[new]

** Changed in: openstack-ansible
   Status: In Progress => Fix Committed

** Changed in: openstack-ansible
   Status: Fix Committed => 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/1753443

Title:
  os_nova: upgrade_levels/compute=auto failure on master

Status in OpenStack Compute (nova):
  In Progress
Status in openstack-ansible:
  Fix Released

Bug description:
  It looks like a recent change [1] in nova, to remove RPC 4.x support,
  has exposed a bug when using upgrade_levels/compute=auto on a new
  deployment. This is blocking the openstack-ansible-os_nova master
  gate.

  Tempest tests are failing, the following in nova-conductor.log shows the 
failure:
  ```
  2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server 
[req-9c3f2dd3-81dd-4275-9a61-a3a859dde29d 3639ea84ebcf4c858de98eeede6789a9 
3b9624e03ed740f483c64301d0d11372 - default default] Exception during message 
handling: RPCVersionCapError: Requested message version, 5.0 is incompatible.  
It needs to be equal in major version and less than or equal in minor version 
as the specified version cap 4.11.
  2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server Traceback (most 
recent call last):
  2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server   File 
"/openstack/venvs/nova-testing/local/lib/python2.7/site-packages/oslo_messaging/rpc/server.py",
 line 163, in _process_incoming
  2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server res = 
self.dispatcher.dispatch(message)
  2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server   File 
"/openstack/venvs/nova-testing/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py",
 line 220, in dispatch
  2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server return 
self._do_dispatch(endpoint, method, ctxt, args)
  2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server   File 
"/openstack/venvs/nova-testing/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py",
 line 190, in _do_dispatch
  2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server result = 
func(ctxt, **new_args)
  2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server   File 
"/openstack/venvs/nova-testing/local/lib/python2.7/site-packages/nova/conductor/manager.py",
 line 1265, in schedule_and_build_instances
  2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server 
limits=host.limits, host_list=host_list)
  2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server   File 
"/openstack/venvs/nova-testing/local/lib/python2.7/site-packages/nova/compute/rpcapi.py",
 line 1030, in build_and_run_instance
  2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server 
cctxt.cast(ctxt, 'build_and_run_instance', **kwargs)
  2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server   File 
"/openstack/venvs/nova-testing/local/lib/python2.7/site-packages/oslo_messaging/rpc/client.py",
 line 149, in cast
  2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server 
self._check_version_cap(msg.get('version'))
  2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server   File 
"/openstack/venvs/nova-testing/local/lib/python2.7/site-packages/oslo_messaging/rpc/client.py",
 line 126, in _check_version_cap
  2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server 
version_cap=self.version_cap)
  2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server 
RPCVersionCapError: Requested message version, 5.0 is incompatible.  It needs 
to be equal in major version and less than or equal in minor version as the 
specified version cap 4.11.
  2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server 
  ```

  When openstack-ansible-os_nova is used for a new deployment, the following 
appears in the logs:
  ```
  2018-03-02 17:25:55.954 19495 DEBUG nova.compute.rpcapi 
[req-97c173ed-052e-4ce7-8314-d220dfdab8e7 - - - - -] Not caching compute RPC 
version_cap, because min service_version is 0. Please ensure a nova-compute 
service has been started. Defaulting to Mitaka RPC. _determine_version_cap 
/openstack/venvs/nova-master/lib/python2.7/site-packages/nova/compute/rpcapi.py:408
  ```

  The reference to Mitaka is caused by [2], it looks to be intended to
  set the version cap to be as permissive as possible (N to N+1
  upgrades) but it appears it hasn't been updated since it was first
  added for newton.

  Restarting the services addresses the issue, observed by:
  ```
  2018-03-04 21:42:14.367 21270 INFO nova.compute.rpcapi 
[req-95678c1e-8465-4059-8095-70479085b179 - - - - -] Automatically selected 
compute RPC version 5.0 from minimum service version 30
  ```

  It seems like there may be two issues exposed here, one is the bug in
  nova setting the minimum version and the other is how OSA handles the
  deployment. With the default OSA deployment the minimum RPC version
 

[Yahoo-eng-team] [Bug 1753557] [NEW] i18n javascript on login page requires login (again)

[John Dilley]

Public bug reported:

https://bugs.launchpad.net/horizon/+bug/1708671 was marked as
"Invalid"/Fixed, with the fix being this revert:
https://git.openstack.org/cgit/openstack/horizon/commit/?h=stable/queens=c16ceb149c855411aec66d713eddc8d6c62f9b30

However, it seems to have been reintroduced in
https://git.openstack.org/cgit/openstack/horizon/commit/?h=stable/queens=077163a03c9aea08efd56251e49d69eb1cc4d093
- after reverting this patch in my local installation it all seems happy
again.

This affects the queens release.

** 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/1753557

Title:
  i18n javascript on login page requires login (again)

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  https://bugs.launchpad.net/horizon/+bug/1708671 was marked as
  "Invalid"/Fixed, with the fix being this revert:
  
https://git.openstack.org/cgit/openstack/horizon/commit/?h=stable/queens=c16ceb149c855411aec66d713eddc8d6c62f9b30

  However, it seems to have been reintroduced in
  
https://git.openstack.org/cgit/openstack/horizon/commit/?h=stable/queens=077163a03c9aea08efd56251e49d69eb1cc4d093
  - after reverting this patch in my local installation it all seems
  happy again.

  This affects the queens release.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1753557/+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 1753558] [NEW] NoCloud data source is mis-using the "system-serial-number" SMBIOS field, should use "OEM Strings" instead

[Daniel Berrange]

Public bug reported:

As the name suggests, the "system-serial-number" field in SMBIOS is
intended for exposing a serial number identifying the hardware, to the
operating system.

The NoCloud data source is mis-using this field for receiving metadata
for initializing cloud-init.

Admittedly there was not really a better alternative available from QEMU
historically, if SMBIOS was the required comms channel. This is not true
for the SMBIOS spec in general though. It has a specified a table called
"OEM Strings" which has no semantics defined and thus intentionally
available for passing arbitrary OEM defined data to the guest OS.

This is much better suited to usage by cloud-init, and with careful
namespacing it is possible to use "OEM strings" for multiple purposes,
not only cloud-init.

Thus I have implemented patches for QEMU to enable use of the "OEM
strings" SMBIOS table

  commit 2d6dcbf93fb01b4a7f45a93d276d4d74b16392dd
  Author: Daniel P. Berrange 
  Date:   Sat Oct 28 21:51:36 2017 +0100

smbios: support setting OEM strings table

The cloud-init program currently allows fetching of its data by repurposing 
of
the 'system' type 'serial' field. This is a clear abuse of the serial field 
that
would clash with other valid usage a virt management app might have for that
field.

Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to 
allow
exposing of arbitrary vendor specific strings to the operating system. This 
is
perfect for use with cloud-init, or as a way to pass arguments to OS 
installers
such as anaconda.

This patch makes it easier to support this with QEMU. e.g.

  $QEMU -smbios type=11,value=Hello,value=World,value=Tricky,,value=test

Which results in the guest seeing dmidecode data

  Handle 0x0E00, DMI type 11, 5 bytes
  OEM Strings
  String 1: Hello
  String 2: World
  String 3: Tricky,value=test

It is suggested that any app wanting to make use of this OEM strings 
capability
for accepting data from the host mgmt layer should use its name as a string
prefix. e.g. to expose OEM strings targetting both cloud init and anaconda 
in
parallel the mgmt app could set

  $QEMU -smbios 
type=11,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\

value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os

which would appear as

  Handle 0x0E00, DMI type 11, 5 bytes
  OEM Strings
  String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
  String 2: 
anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os

Use of such string prefixes means the app won't have to care which string 
slot
its data appears in.

Signed-off-by: Daniel P. Berrange 
Reviewed-by: Michael S. Tsirkin 
Signed-off-by: Michael S. Tsirkin 

This will be in the QEMU 2.12 release due out end of April

And and equivalent patch to libvirt (released yesterday in 4.1.0) to
allow it to be configured there and passed into QEMU

  commit 68eed56b2d51e66bb540062fe09f5ffd44e99f6e
  Author: Daniel P. Berrange 
  Date:   Sat Oct 28 14:56:51 2017 +0100

conf: add support for setting OEM strings SMBIOS data fields

The OEM strings table in SMBIOS allows the vendor to pass arbitrary
strings into the guest OS. This can be used as a way to pass data to an
application like cloud-init, or potentially as an alternative to the
kernel command line for OS installers where you can't modify the install
ISO image to change the kernel args.

As an example, consider if cloud-init and anaconda supported OEM strings
you could use something like


  cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
  
anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os


use of a application specific prefix as illustrated above is
recommended, but not mandated, so that an app can reliably identify
which of the many OEM strings are targetted at it.

Reviewed-by: John Ferlan 
Signed-off-by: Daniel P. Berrange 


All that's missing now is a patch for cloud-init's  NoCloud data source to make 
it look for data via the OEM strings table, in preference to the system table 
serial field.

Note in the above commits to QEMU/libvirt I illustrated an example of
how to use an application specific prefix in the OEM strings entry to
get nice namespacing.

** 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/1753558

Title:
  NoCloud data 

[Yahoo-eng-team] [Bug 1753555] [NEW] horizon test helper prevents mox free horizon plugin

[Akihiro Motoki]

Public bug reported:

Currently horizon test helpers (horizon/test/helpers.py and 
openstack_dashboard/test/helpers.py) always imports mox3.
These test helpers are consumed by horizon plugins.
Even when horizon plugins are mox free, these test helpers requires mox3 and 
plugins cannot drop mox3 from test-requirements.txt. mox should be optional in 
horizon test helpers.

** Affects: horizon
 Importance: High
 Assignee: Akihiro Motoki (amotoki)
 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/1753555

Title:
  horizon test helper prevents mox free horizon plugin

Status in OpenStack Dashboard (Horizon):
  New

Bug description:
  Currently horizon test helpers (horizon/test/helpers.py and 
openstack_dashboard/test/helpers.py) always imports mox3.
  These test helpers are consumed by horizon plugins.
  Even when horizon plugins are mox free, these test helpers requires mox3 and 
plugins cannot drop mox3 from test-requirements.txt. mox should be optional in 
horizon test helpers.

To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1753555/+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 1752660] Re: keystone requires cffi to be installed for fernat tokens

[Corey Bryant]

Ok thanks, that's helpful. Something seems to be wrong with the python-
cryptography package. It seems to intend to install cffi but it is
obviously not happening.

** Changed in: cloud-archive
   Status: Incomplete => Triaged

** Changed in: cloud-archive
   Importance: Undecided => High

** Changed in: keystone (Ubuntu)
   Status: Incomplete => Invalid

** Changed in: keystone
   Status: New => Invalid

** Also affects: python-cryptography (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: python-cryptography (Ubuntu)
   Status: New => Triaged

** Changed in: python-cryptography (Ubuntu)
   Importance: Undecided => High

-- 
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/1752660

Title:
  keystone requires cffi to be installed for fernat tokens

Status in Ubuntu Cloud Archive:
  Triaged
Status in OpenStack Identity (keystone):
  Invalid
Status in keystone package in Ubuntu:
  Invalid
Status in python-cryptography package in Ubuntu:
  Triaged

Bug description:
  When installing keystone (via apt-get install keystone) apt does not
  install python-cffi, which is required for keystone to implement
  fernat tokens (the current recommended token type)

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: keystone 2:13.0.0-0ubuntu1~cloud0 [origin: Canonical]
  Uname: Linux 4.4.88-mainline-rev1 x86_64
  ApportVersion: 2.20.1-0ubuntu2.15
  Architecture: amd64
  CrashDB:
   {
  "impl": "launchpad",
  "project": "cloud-archive",
  "bug_pattern_url": 
"http://people.canonical.com/~ubuntu-archive/bugpatterns/bugpatterns.xml;,
   }
  Date: Thu Mar  1 17:19:34 2018
  PackageArchitecture: all
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: keystone
  UpgradeStatus: No upgrade log present (probably fresh install)
  mtime.conffile..etc.keystone.keystone.conf: 2018-03-01T16:51:52.734036

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1752660/+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 1753550] [NEW] Status does not update to "Shutoff" when instance shuts down itself

[Raoul Hidalgo Charman]

Public bug reported:

For instances that shut down themselves, the status remains Active, even
though the power state updates to Shutdown. If however the shutdown
signal is sent via openstack it does change the status to "SHUTOFF".

After creating an instance, the states are:
++-+
| Field  | Value   |
++-+
| OS-EXT-STS:power_state | Running |
| OS-EXT-STS:task_state  | None|
| OS-EXT-STS:vm_state| active  |
| status | ACTIVE  |
++-+

Using openstack server stop results in:
++--+
| Field  | Value|
++--+
| OS-EXT-STS:power_state | Shutdown |
| OS-EXT-STS:task_state  | None |
| OS-EXT-STS:vm_state| stopped  |
| status | SHUTOFF  |
++--+

However logging into the instance and using the poweroff command results in:
++--+
| Field  | Value|
++--+
| OS-EXT-STS:power_state | Shutdown |
| OS-EXT-STS:task_state  | None |
| OS-EXT-STS:vm_state| active   |
| status | ACTIVE   |
++--+

This results in being unable to use the openstack server start command
on it fails and returns:

# openstack server start test_shutdown
Cannot 'start' instance 8881bebb-efbd-45e6-a052-7d23b9b63222 while it is in 
vm_state active (HTTP 409) (Request-ID: 
req-e473415d-d6e0-4342-b1f6-267efa934dc0)

despite the virtual machine being powered off. You can work around this
by running openstack server stop, and then openstack server start.

This is also an issue for external applications that check the status
(and how I noticed it to begin with).

This on devstack with commit id:
5d2add74534719c5670b29152964a60e8f23b42b

Not sure if the following is useful, but
- Using hypervisor libvirt+qemu/kvm:
# virsh version
Compiled against library: libvirt 3.2.0
Using library: libvirt 3.2.0
Using API: QEMU 3.2.0
Running hypervisor: QEMU 2.9.0
- Using ephemeral storage with ex4
- Neutron with OpenVSwitch

** Affects: nova
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1753550

Title:
  Status does not update to "Shutoff" when instance shuts down itself

Status in OpenStack Compute (nova):
  New

Bug description:
  For instances that shut down themselves, the status remains Active,
  even though the power state updates to Shutdown. If however the
  shutdown signal is sent via openstack it does change the status to
  "SHUTOFF".

  After creating an instance, the states are:
  ++-+
  | Field  | Value   |
  ++-+
  | OS-EXT-STS:power_state | Running |
  | OS-EXT-STS:task_state  | None|
  | OS-EXT-STS:vm_state| active  |
  | status | ACTIVE  |
  ++-+

  Using openstack server stop results in:
  ++--+
  | Field  | Value|
  ++--+
  | OS-EXT-STS:power_state | Shutdown |
  | OS-EXT-STS:task_state  | None |
  | OS-EXT-STS:vm_state| stopped  |
  | status | SHUTOFF  |
  ++--+

  However logging into the instance and using the poweroff command results in:
  ++--+
  | Field  | Value|
  ++--+
  | OS-EXT-STS:power_state | Shutdown |
  | OS-EXT-STS:task_state  | None |
  | OS-EXT-STS:vm_state| active   |
  | status | ACTIVE   |
  ++--+

  This results in being unable to use the openstack server start command
  on it fails and returns:

  # openstack server start test_shutdown
  Cannot 'start' instance 8881bebb-efbd-45e6-a052-7d23b9b63222 while it is in 
vm_state active (HTTP 409) (Request-ID: 
req-e473415d-d6e0-4342-b1f6-267efa934dc0)

  despite the virtual machine being powered off. You can work around
  this by running openstack server stop, and then openstack server
  start.

  This is also an issue for external applications that check the status
  (and how I noticed it to begin with).

  This on devstack with commit id:
  5d2add74534719c5670b29152964a60e8f23b42b

  Not sure if the following is useful, but
  - Using hypervisor libvirt+qemu/kvm:
  # virsh version
  Compiled against library: libvirt 3.2.0
  Using library: libvirt 3.2.0
  Using API: QEMU 3.2.0
  Running hypervisor: QEMU 2.9.0
  - Using ephemeral storage with ex4
  - Neutron with OpenVSwitch

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1753550/+subscriptions

-- 
Mailing list: 

[Yahoo-eng-team] [Bug 1753542] [NEW] TypeError: set_override() got an unexpected keyword argument 'enforce_type'

[KI4RBC]

Public bug reported:

On a new install of Openstack (ocata), we are having a problem getting the 
glance API up and running.
This first presented it self in a failure using the CLI.
http://paste.openstack.org/show/692023/
Both the glance-api.log and glance-registry.log show the same error reporting 
an unexpected keyword argument 'enforce_type'
http://paste.openstack.org/show/692023/

I've found this is not a config directive but is set in various python
packages "enforce_type=True"

** Affects: glance
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1753542

Title:
  TypeError: set_override() got an unexpected keyword argument
  'enforce_type'

Status in Glance:
  New

Bug description:
  On a new install of Openstack (ocata), we are having a problem getting the 
glance API up and running.
  This first presented it self in a failure using the CLI.
  http://paste.openstack.org/show/692023/
  Both the glance-api.log and glance-registry.log show the same error reporting 
an unexpected keyword argument 'enforce_type'
  http://paste.openstack.org/show/692023/

  I've found this is not a config directive but is set in various python
  packages "enforce_type=True"

To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1753542/+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 1753540] [NEW] When isolated/force metadata is enabled, metadata proxy doesn't get automatically started/stopped when needed

[Daniel Alvarez]

Public bug reported:

When enabled_isolated_metadata option is set to True in DHCP agent
configuration, the metadata proxy instances won't get started
dynamically when the network gets isolated. Similarly, when a subnet is
added to the router, they don't get stopped if they were already
running.

100% reproducible:

With enable_isolated_metadata=True:

1. Create a network, a subnet and a router.
2. Check that there's a proxy instance running in the DHCP namespace for this 
network:

neutron   89   1  0 17:01 ?00:00:00 haproxy -f
/var/lib/neutron/ns-metadata-
proxy/9d1c7905-a887-419a-a885-9b07c20c2012.conf

3. Attach the subnet to the router.
4. Verify that the proxy instance is still running.
5. Restart DHCP agent
6. Verify that the proxy instance went away (since the network is not isolated).
7. Remove the subnet from the router.
8. Verify that the proxy instance has not been spawned.

At this point, booting any VM on the network will fail since it won't be able 
to fetch metadata.
However, any update on the network/subnet will trigger the agent to refresh the 
status of the isolated metadata proxy:

For example: openstack network set  --name foo 
would trigger that DHCP agent spawns the proxy for that network.

** Affects: neutron
 Importance: Undecided
 Assignee: Daniel Alvarez (dalvarezs)
 Status: In Progress

** Changed in: neutron
 Assignee: (unassigned) => Daniel Alvarez (dalvarezs)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1753540

Title:
  When isolated/force metadata is enabled, metadata proxy doesn't get
  automatically started/stopped when needed

Status in neutron:
  In Progress

Bug description:
  When enabled_isolated_metadata option is set to True in DHCP agent
  configuration, the metadata proxy instances won't get started
  dynamically when the network gets isolated. Similarly, when a subnet
  is added to the router, they don't get stopped if they were already
  running.

  100% reproducible:

  With enable_isolated_metadata=True:

  1. Create a network, a subnet and a router.
  2. Check that there's a proxy instance running in the DHCP namespace for this 
network:

  neutron   89   1  0 17:01 ?00:00:00 haproxy -f
  /var/lib/neutron/ns-metadata-
  proxy/9d1c7905-a887-419a-a885-9b07c20c2012.conf

  3. Attach the subnet to the router.
  4. Verify that the proxy instance is still running.
  5. Restart DHCP agent
  6. Verify that the proxy instance went away (since the network is not 
isolated).
  7. Remove the subnet from the router.
  8. Verify that the proxy instance has not been spawned.

  At this point, booting any VM on the network will fail since it won't be able 
to fetch metadata.
  However, any update on the network/subnet will trigger the agent to refresh 
the status of the isolated metadata proxy:

  For example: openstack network set  --name foo 
  would trigger that DHCP agent spawns the proxy for that network.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1753540/+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 1724128] Re: Need a Success / Failure notification mechanism when cloud-init finishes.

[Sankar Tanguturi]

** Also 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/1724128

Title:
  Need a Success / Failure notification mechanism when cloud-init
  finishes.

Status in cloud-init:
  New
Status in open-vm-tools package in Ubuntu:
  New

Bug description:
  I discussed this issue during the 'cloud-init' summit that happened in
  August 2017. Logging a bug for tracking purposes. Today, there is no
  way for datasources to get notified about success / failure when
  cloud-init finishes executing.

  Following is an example:

  > From cloudinit/sources/DataSourceOVF.py

  # TODO: Need to set the status to DONE only when the
  # customization is done successfully.
  enable_nics(self._vmware_nics_to_enable)
  set_customization_status(
  GuestCustStateEnum.GUESTCUST_STATE_DONE,
  GuestCustErrorEnum.GUESTCUST_ERROR_SUCCESS)

  Ideally, the datasourceOVF wants to get notified when the cloud-init
  finally completes. Then, the datasource needs to send success /
  failure events to the underlying hypervisor. But today the mechanism /
  framework is not available. So, the datasourceOVF just blindly returns
  SUCCESS to the hypervisor without even waiting for the completion.

  We really really need a better framework / mechanism to handle
  situations like this. Please do let me know if any information is
  requried.

  Thanks
  Sankar.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1724128/+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 1670628] Re: nova-compute will try to re-plug the vif even if it exists for vhostuser port.

[Stephen Finucane]

** Changed in: nova
   Status: Opinion => Confirmed

** Changed in: nova
   Importance: Undecided => High

-- 
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/1670628

Title:
  nova-compute will try to re-plug the vif even if it exists for
  vhostuser port.

Status in OpenStack Compute (nova):
  Confirmed

Bug description:
  Description
  ===
  In mitaka version, deploy neutron with ovs-dpdk.
  If we stop ovs-agent, then re-start the nova-compute,the vm in the host will 
get network connection failed.

  Steps to reproduce
  ==
  deploy mitaka. with neutron, enabled ovs-dpdk, choose one compute node, where 
vm has network connection.
  run this in host,
  1. #systemctl stop neutron-openvswitch-agent.service
  2. #systemctl restart openstack-nova-compute.service

  then ping $VM_IN_THIS_HOST

  Expected result
  ===
  ping $VM_IN_THIS_HOST would would success

  Actual result
  =
  ping $VM_IN_THIS_HOST failed.

  Environment
  ===
  Centos7
  ovs2.5.1
  dpdk 2.2.0
  openstack-nova-compute-13.1.1-1

  Reason:
  after some digging, I found that nova-compute will try to plug the vif every 
time when it booting.
  Specially for vhostuser port, nova-compute will not check whether it exists 
as legacy ovs,and it will re-plug the port with vsctl args like "--if-exists 
del-port vhu".
  (refer 
https://github.com/openstack/nova/blob/stable/mitaka/nova/virt/libvirt/vif.py#L679-L683)
  after recreate the ovs vhostuser port, it will not get the right vlan tag 
which set from ovs agent.

  In the test environment, after restart the ovs agent, the agent will
  set a proper vlan id for the port. and the network connection will be
  resumed.

  Not sure it's a bug or config issue, do I miss something?
  there is also fp_plug type for vhostuser port, how could we specify it?

To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1670628/+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 1753507] [NEW] FWaaS V2: Upgrade Pike->Queen causes error

[German Eichberger]

Public bug reported:

>From our chat:

 Jon Davis Hello - I just upgraded to Queens and fwaas_v2 is throwing 
error: http://paste.openstack.org/raw/68/
6:46 PM J Jon Davis Everything was working fine in Pike
6:46 PM for attr, position in ATTR_POSITIONS[protocol]: KeyError: 'unknown'
6:47 PM Ideas on where to look?

** Affects: neutron
 Importance: Critical
 Status: New

** Project changed: neutron-fwaas-dashboard => neutron

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1753507

Title:
  FWaaS V2: Upgrade Pike->Queen causes error

Status in neutron:
  New

Bug description:
  From our chat:

   Jon Davis Hello - I just upgraded to Queens and fwaas_v2 is throwing 
error: http://paste.openstack.org/raw/68/
  6:46 PM J Jon Davis Everything was working fine in Pike
  6:46 PM for attr, position in ATTR_POSITIONS[protocol]: KeyError: 'unknown'
  6:47 PM Ideas on where to look?

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1753507/+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 1753507] [NEW] FWaaS V2: Upgrade Pike->Queen causes error

[Launchpad Bug Tracker]

You have been subscribed to a public bug:

>From our chat:

 Jon Davis Hello - I just upgraded to Queens and fwaas_v2 is throwing 
error: http://paste.openstack.org/raw/68/
6:46 PM J Jon Davis Everything was working fine in Pike
6:46 PM for attr, position in ATTR_POSITIONS[protocol]: KeyError: 'unknown'
6:47 PM Ideas on where to look?

** Affects: neutron
 Importance: Critical
 Status: New

-- 
FWaaS V2: Upgrade Pike->Queen causes error
https://bugs.launchpad.net/bugs/1753507
You received this bug notification because you are a member of Yahoo! 
Engineering Team, which is subscribed to neutron.

-- 
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 1753499] [NEW] hostname in FreeBSD should prefere FQDN

[do3meli]

Public bug reported:

in its current behavior cloud-init does not set the hostname on FreeBSD
servers to it's FQDN if it is given. As per [1] FreeBSD Man Page for
rc.conf the hostname variable in rc.conf should be set to FQDN.

[1]
https://www.freebsd.org/cgi/man.cgi?query=rc.conf=5=0=FreeBSD+11.1-RELEASE+and+Ports

** 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/1753499

Title:
  hostname in FreeBSD should prefere FQDN

Status in cloud-init:
  New

Bug description:
  in its current behavior cloud-init does not set the hostname on
  FreeBSD servers to it's FQDN if it is given. As per [1] FreeBSD Man
  Page for rc.conf the hostname variable in rc.conf should be set to
  FQDN.

  [1]
  
https://www.freebsd.org/cgi/man.cgi?query=rc.conf=5=0=FreeBSD+11.1-RELEASE+and+Ports

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1753499/+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 1752711] Re: cloud-init no longer processes user data on GCE in artful

[Launchpad Bug Tracker]

This bug was fixed in the package cloud-init -
17.2-35-gf576b2a2-0ubuntu1~16.04.2

---
cloud-init (17.2-35-gf576b2a2-0ubuntu1~16.04.2) xenial-proposed; urgency=medium

  * cherry-pick 40e7738: GCE: fix reading of user-data that is not
base64 encoded. (LP: #1752711)

cloud-init (17.2-35-gf576b2a2-0ubuntu1~16.04.1) xenial-proposed;
urgency=medium

  * New upstream snapshot. (LP: #1747059)
- tests: add support for logs with lxd from snap and future lxd 3.
- EC2: Fix get_instance_id called against cached datasource pickle.
- cli: fix cloud-init status to report running when before result.json
- net: accept network-config in netplan format for renaming interfaces
- Fix ssh keys validation in ssh_util [Tatiana Kholkina]

 -- Chad Smith   Thu, 01 Mar 2018 16:05:39
-0700

** Changed in: cloud-init (Ubuntu Xenial)
   Status: Fix Committed => Fix Released

-- 
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/1752711

Title:
  cloud-init no longer processes user data on GCE in artful

Status in cloud-init:
  Fix Committed
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-init source package in Artful:
  Fix Released
Status in cloud-init source package in Bionic:
  Fix Released

Bug description:
  === Begin SRU Template ===
  [Impact]
  Any user-data provided when creating google cloud instances is ignored so no 
instance customization is observed. This is a silent failure and no tracebacks 
in cloud-init represent that failure to the user.

  Providing a simple cloud-config to set a hostname will provide a quick
  validation of cloud-init observing user-data.

  [Test Case]

  # Create cloud-config which should change the hostname, and cli prompt
  $ cat > sethostname.yaml 

[Yahoo-eng-team] [Bug 1753466] [NEW] [RFE] Support stateless security groups

[Giel Dops]

Public bug reported:

Neutron currently only provides stateful security groups. The rules of
these security groups are then configured in a stateful manner.

The goal of this RFE is to support stateless security groups. Analogous
to stateful security groups, all rules of a stateless security group
will be implemented as stateless. The statefulness of a security group
can be modified only if it has no associated ports. By default, security
groups are stateful.

For some use cases, this statelessness will allow operators to choose
for optimized datapath performance whereas stateful security groups
impose extra processing on the system. On the downside, operators need
to provision security group rules for ingress and egress to their exact
intent, as reverse traffic is no longer automatically allowed.

The motivation for defining statefulness/statelessness at security group
level and not at rule level is to avoid operational complexity when
mixing up both. However, it would be possible to assign both stateless
and stateful security groups to the same port.

>From an API point of view, a new boolean attribute `stateful` will be
added to security groups, defaulting to True. When the attribute is set
to False, a stateless security group is created. As this attribute will
be persisted, alembic migration is needed. Currently existing security
groups will all be set to stateful during the alembic migration.

The following OpenStack components will need to be modified when implementing 
this feature:
  - neutron: implementing stateless security groups and unit tests
  - python-openstacksdk: add new resource property
  - python-openstackclient: support for the new security group attribute
  - horizon: adding the new security group attribute
  - heat: adding a resource property

We will implement and verify this feature for OVS/iptables.

** Affects: neutron
 Importance: Undecided
 Assignee: Giel Dops (nuage.gieldops)
 Status: New


** Tags: rfe

** Changed in: neutron
 Assignee: (unassigned) => Giel Dops (nuage.gieldops)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1753466

Title:
  [RFE] Support stateless security groups

Status in neutron:
  New

Bug description:
  Neutron currently only provides stateful security groups. The rules of
  these security groups are then configured in a stateful manner.

  The goal of this RFE is to support stateless security groups.
  Analogous to stateful security groups, all rules of a stateless
  security group will be implemented as stateless. The statefulness of a
  security group can be modified only if it has no associated ports. By
  default, security groups are stateful.

  For some use cases, this statelessness will allow operators to choose
  for optimized datapath performance whereas stateful security groups
  impose extra processing on the system. On the downside, operators need
  to provision security group rules for ingress and egress to their
  exact intent, as reverse traffic is no longer automatically allowed.

  The motivation for defining statefulness/statelessness at security
  group level and not at rule level is to avoid operational complexity
  when mixing up both. However, it would be possible to assign both
  stateless and stateful security groups to the same port.

  From an API point of view, a new boolean attribute `stateful` will be
  added to security groups, defaulting to True. When the attribute is
  set to False, a stateless security group is created. As this attribute
  will be persisted, alembic migration is needed. Currently existing
  security groups will all be set to stateful during the alembic
  migration.

  The following OpenStack components will need to be modified when implementing 
this feature:
- neutron: implementing stateless security groups and unit tests
- python-openstacksdk: add new resource property
- python-openstackclient: support for the new security group attribute
- horizon: adding the new security group attribute
- heat: adding a resource property

  We will implement and verify this feature for OVS/iptables.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1753466/+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 1621615] Re: network not configured when ipv6 netbooted into cloud-init

[Blake Rouse]

** Changed in: maas
   Status: In Progress => Invalid

** Changed in: maas
 Assignee: LaMont Jones (lamont) => (unassigned)

** Changed in: maas
Milestone: 2.1.3 => None

-- 
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/1621615

Title:
  network not configured when ipv6 netbooted into cloud-init

Status in cloud-init:
  Fix Released
Status in MAAS:
  Invalid
Status in cloud-init package in Ubuntu:
  Fix Released
Status in cloud-initramfs-tools package in Ubuntu:
  Fix Released
Status in cloud-init source package in Xenial:
  Fix Released
Status in cloud-initramfs-tools source package in Xenial:
  Fix Released
Status in cloud-init source package in Yakkety:
  Fix Released
Status in cloud-initramfs-tools source package in Yakkety:
  Fix Released

Bug description:
  https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1621507 talks of
  how IPv6 netboot with iscsi root disk doesn't work, blocking IPv6-only
  MAAS.

  After I hand-walked busybox through getting an IPv6 address,
  everything worked just fine until cloud-init couldn't fetch the
  instance data, because it insisted on bringing up the interface in
  IPv4, and there is no IPv4 DHCP on that vlan.

  Please work with initramfs and friends on getting IPv6 netboot to
  actually configure the interface.  This may be as simple as teaching
  it about "inet6 dhcp" interfaces, and bolting the pieces together.
  Note that "use radvd" is not really an option for our use case.

  Related bugs:
   * bug 1621507: initramfs-tools configure_networking() fails to dhcp IPv6 
addresses
   * bug 1635716: Can't bring up a machine on a dual network (ipv4 and ipv6)
   * bug 1639930: initramfs network configuration ignored if only ip6= on 
kernel command line 

  [Impact]

  It is not possible to enlist, commmission, or deploy with MAAS in an
  IPv6-only environment. Anyone wanting to netboot with a network root
  filesystem in an IPv6-only environment is affected.

  This upload addresses this by accepting, using, and forwarding any
  IPV6* variables from the initramfs boot.  (See
  https://launchpad.net/bugs/1621507)

  [Test Case]

  See Bug 1229458. Configure radvd, dhcpd, and tftpd for your IPv6-only
  netbooting world. Pass the boot process an IPv6 address to fetch
  instance-data from, and see it fail to configure the network.

  [Regression Potential]

  1) If the booting host is in a dual-boot environment, and the
  instance-dat URL uses a hostname that has both A and  RRsets, the
  booting host may try to talk IPv6 to get instance data.  If the
  instance-data providing host is only allowing that to happen over
  IPv4, it will fail. (It also represents a configuraiton issue on the
  providing host...)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1621615/+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 1753443] [NEW] os_nova: upgrade_levels/compute=auto failure on master

[git-harry]

Public bug reported:

It looks like a recent change [1] in nova, to remove RPC 4.x support,
has exposed a bug when using upgrade_levels/compute=auto on a new
deployment. This is blocking the openstack-ansible-os_nova master gate.

Tempest tests are failing, the following in nova-conductor.log shows the 
failure:
```
2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server 
[req-9c3f2dd3-81dd-4275-9a61-a3a859dde29d 3639ea84ebcf4c858de98eeede6789a9 
3b9624e03ed740f483c64301d0d11372 - default default] Exception during message 
handling: RPCVersionCapError: Requested message version, 5.0 is incompatible.  
It needs to be equal in major version and less than or equal in minor version 
as the specified version cap 4.11.
2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server Traceback (most 
recent call last):
2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server   File 
"/openstack/venvs/nova-testing/local/lib/python2.7/site-packages/oslo_messaging/rpc/server.py",
 line 163, in _process_incoming
2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server res = 
self.dispatcher.dispatch(message)
2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server   File 
"/openstack/venvs/nova-testing/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py",
 line 220, in dispatch
2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server return 
self._do_dispatch(endpoint, method, ctxt, args)
2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server   File 
"/openstack/venvs/nova-testing/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py",
 line 190, in _do_dispatch
2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server result = 
func(ctxt, **new_args)
2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server   File 
"/openstack/venvs/nova-testing/local/lib/python2.7/site-packages/nova/conductor/manager.py",
 line 1265, in schedule_and_build_instances
2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server 
limits=host.limits, host_list=host_list)
2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server   File 
"/openstack/venvs/nova-testing/local/lib/python2.7/site-packages/nova/compute/rpcapi.py",
 line 1030, in build_and_run_instance
2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server 
cctxt.cast(ctxt, 'build_and_run_instance', **kwargs)
2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server   File 
"/openstack/venvs/nova-testing/local/lib/python2.7/site-packages/oslo_messaging/rpc/client.py",
 line 149, in cast
2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server 
self._check_version_cap(msg.get('version'))
2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server   File 
"/openstack/venvs/nova-testing/local/lib/python2.7/site-packages/oslo_messaging/rpc/client.py",
 line 126, in _check_version_cap
2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server 
version_cap=self.version_cap)
2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server 
RPCVersionCapError: Requested message version, 5.0 is incompatible.  It needs 
to be equal in major version and less than or equal in minor version as the 
specified version cap 4.11.
2018-03-03 05:13:23.679 9771 ERROR oslo_messaging.rpc.server 
```

When openstack-ansible-os_nova is used for a new deployment, the following 
appears in the logs:
```
2018-03-02 17:25:55.954 19495 DEBUG nova.compute.rpcapi 
[req-97c173ed-052e-4ce7-8314-d220dfdab8e7 - - - - -] Not caching compute RPC 
version_cap, because min service_version is 0. Please ensure a nova-compute 
service has been started. Defaulting to Mitaka RPC. _determine_version_cap 
/openstack/venvs/nova-master/lib/python2.7/site-packages/nova/compute/rpcapi.py:408
```

The reference to Mitaka is caused by [2], it looks to be intended to set
the version cap to be as permissive as possible (N to N+1 upgrades) but
it appears it hasn't been updated since it was first added for newton.

Restarting the services addresses the issue, observed by:
```
2018-03-04 21:42:14.367 21270 INFO nova.compute.rpcapi 
[req-95678c1e-8465-4059-8095-70479085b179 - - - - -] Automatically selected 
compute RPC version 5.0 from minimum service version 30
```

It seems like there may be two issues exposed here, one is the bug in
nova setting the minimum version and the other is how OSA handles the
deployment. With the default OSA deployment the minimum RPC version will
change with a restart, it would seem that has the potential to cause
failures if the order of the restarts is not controlled given those
restarts are not triggered by the deployment process.

[1] 
https://github.com/openstack/nova/commit/a761e57368280b6d3e931831ecd393fd5787b3ef
[2] 
https://github.com/openstack/nova/blob/a761e57368280b6d3e931831ecd393fd5787b3ef/nova/compute/rpcapi.py#L384-L392

** Affects: nova
 Importance: Undecided
 Assignee: git-harry (git-harry)
 Status: In Progress

** Affects: openstack-ansible
 Importance: Undecided

[Yahoo-eng-team] [Bug 1753434] [NEW] Unbound ports floating ip not working with address scopes in DVR HA

[Bartosz Bezak]

Public bug reported:

using latest build stable Pike

This commit properly addressed problem of unbound ports centralized
floating Ips -
https://git.openstack.org/cgit/openstack/neutron/commit/?id=8b4bb9c0b057da175f2d773f8257de3e571aed4e

However traffic towards unbound port (Octavia Pike VIP) when using address 
scopes is getting blocked in snat namespace:
Chain neutron-l3-agent-scope (1 references)
 pkts bytes target prot opt in out source   destination
   23  1612 DROP   all  --  anysg-775c0432-f1  anywhere 
anywhere mark match ! 0x401/0x
   
It is working properly with centralized router HA with address scopes, and with 
DVR HA without address scopes.

** Affects: neutron
 Importance: Undecided
 Status: Confirmed

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1753434

Title:
  Unbound ports floating ip not working with address scopes in DVR HA

Status in neutron:
  Confirmed

Bug description:
  using latest build stable Pike

  This commit properly addressed problem of unbound ports centralized
  floating Ips -
  
https://git.openstack.org/cgit/openstack/neutron/commit/?id=8b4bb9c0b057da175f2d773f8257de3e571aed4e

  However traffic towards unbound port (Octavia Pike VIP) when using address 
scopes is getting blocked in snat namespace:
  Chain neutron-l3-agent-scope (1 references)
   pkts bytes target prot opt in out source   
destination
 23  1612 DROP   all  --  anysg-775c0432-f1  anywhere 
anywhere mark match ! 0x401/0x
 
  It is working properly with centralized router HA with address scopes, and 
with DVR HA without address scopes.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1753434/+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 1517839] Re: Make CONF.set_override with parameter enforce_type=True by default

[Ji.Wei]

** Changed in: freezer
   Status: In Progress => Fix Committed

** Changed in: quark
 Assignee: Ji.Wei (jiwei) => (unassigned)

** Changed in: magnum
   Status: In Progress => Fix Released

** Changed in: magnum
 Assignee: Ji.Wei (jiwei) => (unassigned)

** Changed in: kolla
 Assignee: Ji.Wei (jiwei) => (unassigned)

** Changed in: octavia
 Assignee: Ji.Wei (jiwei) => (unassigned)

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1517839

Title:
  Make CONF.set_override with parameter enforce_type=True by default

Status in Cinder:
  In Progress
Status in cloudkitty:
  Fix Released
Status in Designate:
  Fix Released
Status in OpenStack Backup/Restore and DR (Freezer):
  Fix Committed
Status in Glance:
  Invalid
Status in OpenStack Heat:
  Fix Released
Status in Ironic:
  Fix Released
Status in Karbor:
  Fix Released
Status in OpenStack Identity (keystone):
  Fix Released
Status in kolla:
  Confirmed
Status in Magnum:
  Fix Released
Status in Manila:
  Fix Released
Status in Murano:
  Fix Released
Status in neutron:
  Won't Fix
Status in OpenStack Compute (nova):
  Fix Released
Status in octavia:
  New
Status in oslo.config:
  Fix Released
Status in oslo.messaging:
  Fix Released
Status in Quark: Money Reinvented:
  New
Status in Rally:
  Fix Released
Status in senlin:
  Fix Released
Status in tacker:
  Fix Released
Status in tempest:
  Fix Released
Status in watcher:
  Fix Released

Bug description:
  1. Problems :
     oslo_config provides method CONF.set_override[1] , developers usually use 
it to change config option's value in tests. That's convenient .
     By default  parameter enforce_type=False,  it doesn't check any type or 
value of override. If set enforce_type=True , will check parameter
     override's type and value.  In production code(running time code),  
oslo_config  always checks  config option's value.
     In short, we test and run code in different ways. so there's  gap:  config 
option with wrong type or invalid value can pass tests when
     parameter enforce_type = False in consuming projects.  that means some 
invalid or wrong tests are in our code base.

     [1]
  https://github.com/openstack/oslo.config/blob/master/oslo_config/cfg.py#L2173

  2. Proposal
     1) Fix violations when enforce_type=True in each project.

    2) Make method CONF.set_override with  enforce_type=True by default
  in oslo_config

   You can find more details and comments  in
  https://etherpad.openstack.org/p/enforce_type_true_by_default

  3. How to find violations in your projects.

     1. Run tox -e py27

     2. then modify oslo.config with enforce_type=True
    cd .tox/py27/lib64/python2.7/site-packages/oslo_config
    edit cfg.py with enforce_type=True

  -def set_override(self, name, override, group=None, enforce_type=False):
  +def set_override(self, name, override, group=None, enforce_type=True):

    3. Run tox -e py27 again, you will find violations.

  
  The current state is that oslo.config make enforce_type as True by default 
and deprecate this parameter, will remove it in the future, the current work
  is that remove usage of enforce_type in consuming projects. We can list the
  usage of it in 
http://codesearch.openstack.org/?q=enforce_type=nope==

To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1517839/+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