[Yahoo-eng-team] [Bug 1682020] [NEW] Remove nova default keymap option for qemu-kvm (deprecated)
Public bug reported: Hi, Nowdays, qemu-kvm default keymap option -k en-us, or any keymap option is deprecated. In OpenStack it renders the web console access to vm unsuable even with the proper keymap in nova.conf. For exapmle the use of 'Alt-Gr + key' combination in French, Belgium, spanish, or alike keyboard is not working, this can be problematic for hard passwords. Using the linked patch and removing/commenting the keymap options in nova.conf, makes everything working again (depending on the NoVnc version which might be patched also on previous ones). So maybe by default the nova.conf should now comment/remove this option and we need to remove the default option in the nova code. Regards, Pierre-André ** Affects: nova Importance: Undecided Status: New ** Attachment added: "0001-nova-keymap-no-default.patch" https://bugs.launchpad.net/bugs/1682020/+attachment/4860545/+files/0001-nova-keymap-no-default.patch -- 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/1682020 Title: Remove nova default keymap option for qemu-kvm (deprecated) Status in OpenStack Compute (nova): New Bug description: Hi, Nowdays, qemu-kvm default keymap option -k en-us, or any keymap option is deprecated. In OpenStack it renders the web console access to vm unsuable even with the proper keymap in nova.conf. For exapmle the use of 'Alt-Gr + key' combination in French, Belgium, spanish, or alike keyboard is not working, this can be problematic for hard passwords. Using the linked patch and removing/commenting the keymap options in nova.conf, makes everything working again (depending on the NoVnc version which might be patched also on previous ones). So maybe by default the nova.conf should now comment/remove this option and we need to remove the default option in the nova code. Regards, Pierre-André To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1682020/+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 1682014] [NEW] network Renderer for rhel is unavailable when render bond/vlan interface.
Public bug reported:
In rhel, when use clodinit to config network from network_data.json, network
renderer cann't work well when render bond or vlan.
In sysconfig renderer, '_render_bond_interfaces' method has a wrong logic when
type is bond，there is no 'bond-master' in iface object.
apart from this, '_render_bond_interfaces' and '_render_vlan_interfaces' should
also process _render_subnet too. IMO, this two method should like this:
@classmethod
def _render_bond_interfaces(cls, network_state, iface_contents):
bond_filter = renderer.filter_by_type('bond')
for iface in network_state.iter_interfaces(bond_filter):
iface_name = iface['name']
iface_cfg = iface_contents[iface_name]
cls._render_bonding_opts(iface_cfg, iface)
iface_subnets = iface.get("subnets", [])
route_cfg = iface_cfg.routes
if len(iface_subnets) == 1:
cls._render_subnet(iface_cfg, route_cfg, iface_subnets[0])
elif len(iface_subnets) > 1:
for i, iface_subnet in enumerate(iface_subnets,
start=len(iface.children)):
iface_sub_cfg = iface_cfg.copy()
iface_sub_cfg.name = "%s:%s" % (iface_name, i)
iface.children.append(iface_sub_cfg)
cls._render_subnet(iface_sub_cfg, route_cfg, iface_subnet)
master_cfgs = [iface_cfg]
master_cfgs.extend(iface_cfg.children)
for master_cfg in master_cfgs:
master_cfg['BONDING_MASTER'] = True
master_cfg.kind = 'bond'
@classmethod
def _render_vlan_interfaces(cls, network_state, iface_contents):
vlan_filter = renderer.filter_by_type('vlan')
for iface in network_state.iter_interfaces(vlan_filter):
iface_name = iface['name']
iface_cfg = iface_contents[iface_name]
iface_cfg['VLAN'] = True
iface_cfg['PHYSDEV'] = iface_name[:iface_name.rfind('.')]
iface_subnets = iface.get("subnets", [])
route_cfg = iface_cfg.routes
if len(iface_subnets) == 1:
cls._render_subnet(iface_cfg, route_cfg, iface_subnets[0])
elif len(iface_subnets) > 1:
for i, iface_subnet in enumerate(iface_subnets,
start=len(iface.children)):
iface_sub_cfg = iface_cfg.copy()
iface_sub_cfg.name = "%s:%s" % (iface_name, i)
iface.children.append(iface_sub_cfg)
cls._render_subnet(iface_sub_cfg, route_cfg, iface_subnet)
** Affects: cloud-init
Importance: Undecided
Status: New
** Tags: rhel+sysconfig
--
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/1682014
Title:
network Renderer for rhel is unavailable when render bond/vlan
interface.
Status in cloud-init:
New
Bug description:
In rhel, when use clodinit to config network from network_data.json, network
renderer cann't work well when render bond or vlan.
In sysconfig renderer, '_render_bond_interfaces' method has a wrong logic
when type is bond，there is no 'bond-master' in iface object.
apart from this, '_render_bond_interfaces' and '_render_vlan_interfaces'
should also process _render_subnet too. IMO, this two method should like this:
@classmethod
def _render_bond_interfaces(cls, network_state, iface_contents):
bond_filter = renderer.filter_by_type('bond')
for iface in network_state.iter_interfaces(bond_filter):
iface_name = iface['name']
iface_cfg = iface_contents[iface_name]
cls._render_bonding_opts(iface_cfg, iface)
iface_subnets = iface.get("subnets", [])
route_cfg = iface_cfg.routes
if len(iface_subnets) == 1:
cls._render_subnet(iface_cfg, route_cfg, iface_subnets[0])
elif len(iface_subnets) > 1:
for i, iface_subnet in enumerate(iface_subnets,
start=len(iface.children)):
iface_sub_cfg = iface_cfg.copy()
iface_sub_cfg.name = "%s:%s" % (iface_name, i)
iface.children.append(iface_sub_cfg)
cls._render_subnet(iface_sub_cfg, route_cfg, iface_subnet)
master_cfgs = [iface_cfg]
master_cfgs.extend(iface_cfg.children)
for master_cfg in master_cfgs:
master_cfg['BONDING_MASTER'] = True
master_cfg.kind = 'bond'
@classmethod
def _render_vlan_interfaces(cls, network_state, iface_contents):
vlan_filter = renderer.filter_by_type('vlan')
for iface in network_stat
[Yahoo-eng-team] [Bug 1681950] [NEW] Broken links in federated identity docs
You have been subscribed to a public bug: There are two references to: http://specs.openstack.org/openstack/keystone-specs/api/v3/identity-api-v3-os-federation-ext.html on the doc page for federated identity: https://docs.openstack.org/ocata/config-reference/identity/federated-identity.html Both of these links give 404. ** Affects: keystone Importance: Medium Assignee: Chason (chen-xing) Status: Triaged ** Tags: 404 docs federation keystone specs -- Broken links in federated identity docs https://bugs.launchpad.net/bugs/1681950 You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). -- 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 1681005] Re: install hooks fail because enable-os-upgrade/refresh-update ignored
The xenial machine which doesn't run apt-get update/upgrade appears to have the correct config as shown in cloud-init.log output: all: '| tee -a /var/log/cloud-init-output.log' package_update: true package_upgrade: true packages: - curl - cpu-checker - bridge-utils - cloud-utils - tmux - socat ** 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/1681005 Title: install hooks fail because enable-os-upgrade/refresh-update ignored Status in cloud-init: New Status in juju: Triaged Bug description: As seen at http://reports.vapour.ws/releases/issue/5553b279749a56508ba88b45 There is a dramatic rise in hook failures since March 24. This is because juju is not running apt-get update or upgrade. Joyent dominates, but rackspace and GCE have had spots of failures. The unit logs show apt fails to find packages. Joyent tends to have stale images so Juju CI tests always run with os-enable-refresh-update to have the correct list of packages. Today I deployed the landscape bundle in joyent and repeated the postgresql install hook failures. The log confirm an apt issue E: Failed to fetch http://security.ubuntu.com/ubuntu/pool/main/l/linux/linux-libc- dev_4.4.0-71.92_amd64.deb 404 Not Found [IP: 91.189.88.149 80] juju model-config shows apt should have been updated and the host upgraded enable-os-refresh-updatedefault true enable-os-upgrade default true But /var/log/apt/history.log and /var/log/apt/term.log show apt has not been touched since the image was made in March. I left the model untouched for 3 hours. It remained in error. I ran juju ssh 2 -- sudo apt-get update 3 minutes later the unit was installed. This bug is in 2.1 and 2.2 To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1681005/+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 1681997] [NEW] [api-ref]scope token request missing domain in project
Public bug reported: In POST /v3/auth/tokens Password authentication with scoped authorization, request example missing the domain in the project. If send request with the given content, it will response with 400 error, "message": "Expecting to find domain in project. ** Affects: keystone Importance: Undecided Assignee: guoshan (guoshan) Status: New ** Tags: api-ref ** Changed in: keystone Assignee: (unassigned) => guoshan (guoshan) ** Tags added: api-ref ** Description changed: In POST /v3/auth/tokens - Password authentication with scoped authorization, request example missing the domain in the project. If sent request with the given content, it will response with 400 error, "message": "Expecting to find domain in project. + Password authentication with scoped authorization, request example missing the domain in the project. If send request with the given content, it will response with 400 error, "message": "Expecting to find domain in project. -- 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/1681997 Title: [api-ref]scope token request missing domain in project Status in OpenStack Identity (keystone): New Bug description: In POST /v3/auth/tokens Password authentication with scoped authorization, request example missing the domain in the project. If send request with the given content, it will response with 400 error, "message": "Expecting to find domain in project. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1681997/+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 1681996] [NEW] [api-ref]scope token request missing domain in project
Public bug reported: In POST /v3/auth/tokens Password authentication with scoped authorization, request example missing the domain in the project. If sent request with the given content, it will response with 400 error, "message": "Expecting to find domain in project. ** 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/1681996 Title: [api-ref]scope token request missing domain in project Status in OpenStack Identity (keystone): New Bug description: In POST /v3/auth/tokens Password authentication with scoped authorization, request example missing the domain in the project. If sent request with the given content, it will response with 400 error, "message": "Expecting to find domain in project. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1681996/+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 1681998] [NEW] Bypass the dirty BDM enty no matter how it is produced
Public bug reported:
Sometimes the following dirty BDM enty (1.row) can be seen in the
database that multiple BDMs with the same image_id and instance_uuid.
mysql> select * from block_device_mapping where
volume_id='153bcab4-1f88-440c-9782-3c661a7502a8' \G
*** 1. row ***
created_at: 2017-02-02 02:28:45
updated_at: NULL
deleted_at: NULL
id: 9754
device_name: /dev/vdb
delete_on_termination: 0
snapshot_id: NULL
volume_id: 153bcab4-1f88-440c-9782-3c661a7502a8
volume_size: NULL
no_device: NULL
connection_info: NULL
instance_uuid: b52f9264-d8b3-406a-bf9b-d7d7471b13fc
deleted: 0
source_type: volume
destination_type: volume
guest_format: NULL
device_type: NULL
disk_bus: NULL
boot_index: NULL
image_id: NULL
*** 2. row ***
created_at: 2017-02-02 02:29:31
updated_at: 2017-02-27 10:59:42
deleted_at: NULL
id: 9757
device_name: /dev/vdc
delete_on_termination: 0
snapshot_id: NULL
volume_id: 153bcab4-1f88-440c-9782-3c661a7502a8
volume_size: NULL
no_device: NULL
connection_info: {"driver_volume_type": "rbd", "serial":
"153bcab4-1f88-440c-9782-3c661a7502a8", "data": {"secret_type": "ceph", "name":
"cinder-ceph/volume-153bcab4-1f88-440c-9782-3c661a7502a8", "secret_uuid": null,
"qos_specs": null, "hosts": ["10.7.1.202", "10.7.1.203", "10.7.1.204"],
"auth_enabled": true, "access_mode": "rw", "auth_username": "cinder-ceph",
"ports": ["6789", "6789", "6789"]}}
instance_uuid: b52f9264-d8b3-406a-bf9b-d7d7471b13fc
deleted: 0
source_type: volume
destination_type: volume
guest_format: NULL
device_type: disk
disk_bus: virtio
boot_index: NULL
image_id: NULL
then it cause we fail to detach the volume and see the following error
since connection_info of row 1 is NULL.
2017-03-23 13:28:05.360 1865733 TRACE oslo_messaging.rpc.dispatcher
self._detach_volume(context, instance, bdm)
2017-03-23 13:28:05.360 1865733 TRACE oslo_messaging.rpc.dispatcher File
"/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 4801, in
_detach_volume
2017-03-23 13:28:05.360 1865733 TRACE oslo_messaging.rpc.dispatcher
connection_info = jsonutils.loads(bdm.connection_info)
2017-03-23 13:28:05.360 1865733 TRACE oslo_messaging.rpc.dispatcher File
"/usr/lib/python2.7/dist-packages/oslo_serialization/jsonutils.py", line 215,
in loads
2017-03-23 13:28:05.360 1865733 TRACE oslo_messaging.rpc.dispatcher return
json.loads(encodeutils.safe_decode(s, encoding), **kwargs)
2017-03-23 13:28:05.360 1865733 TRACE oslo_messaging.rpc.dispatcher File
"/usr/lib/python2.7/dist-packages/oslo_utils/encodeutils.py", line 33, in
safe_decode
2017-03-23 13:28:05.360 1865733 TRACE oslo_messaging.rpc.dispatcher raise
TypeError("%s can't be decoded" % type(text))
2017-03-23 13:28:05.360 1865733 TRACE oslo_messaging.rpc.dispatcher TypeError:
can't be decoded
This kind of dirty data can be produced when happened to fail to run this line
_attach_volume()#volume_bdm.destroy() [1], I think these conditions may cause
it to happen:
1, lose the database during the operation volume_bdm.destroy()
2, lose an MQ connection or RPC timing out during the operation
volume_bdm.destroy()
If you lose the database during any operation, things are going to be
bad, so in general I'm not sure how realistic guarding for that case is.
Losing an MQ connection or RPC timing out is probably more realistic.
Seems the fix [2] is trying to solve the point 2.
However, I'm thinking if we can bypass the dirty BDM entry according to
the condition that connection_info is NULL no matter how it is produced.
[1] https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3724
[2] https://review.openstack.org/#/c/290793
** 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/1681998
Title:
Bypass the dirty BDM enty no matter how it is produced
Status in OpenStack Compute (nova):
New
Bug description:
Sometimes the following dirty BDM enty (1.row) can be seen in the
database that multiple BDMs with the same image_id and instance_uuid.
mysql> select * from block_device_mapping where
volume_id='153bcab4-1f88-440c-9782-3c661a7502a8' \G
*** 1. row ***
created_at: 2017-02-02 02:28:45
updated_at: NULL
deleted_at: NULL
id: 9754
device_name: /dev/vdb
delete_on_termination: 0
[Yahoo-eng-team] [Bug 1681989] [NEW] the deletion of the instance does not release the memory quota for vram
Public bug reported: When creating an instance, the quota is used to contain vram, and the deletion of the instance does not release the memory quota for vram If a flavor defines 512MB of RAM and 64MB of video RAM, creating an instance will take up 576MB of memory quota, but after deleting the instance, it will only release 512MB of memory quotas. In this way, after multiple creation and deletion of the virtual machine, it will gradually run out of the memory quota, but in fact did not run so many instances. ** Affects: nova Importance: Undecided Assignee: 赵明俊 (falseuser) Status: New ** Changed in: nova Assignee: (unassigned) => 赵明俊 (falseuser) -- 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/1681989 Title: the deletion of the instance does not release the memory quota for vram Status in OpenStack Compute (nova): New Bug description: When creating an instance, the quota is used to contain vram, and the deletion of the instance does not release the memory quota for vram If a flavor defines 512MB of RAM and 64MB of video RAM, creating an instance will take up 576MB of memory quota, but after deleting the instance, it will only release 512MB of memory quotas. In this way, after multiple creation and deletion of the virtual machine, it will gradually run out of the memory quota, but in fact did not run so many instances. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1681989/+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 1592362] Re: [XenAPI] add a maximum retry count for vbd unplug
** Also affects: os-xenapi Importance: Undecided Status: New ** No longer affects: nova -- 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/1592362 Title: [XenAPI] add a maximum retry count for vbd unplug Status in os-xenapi: New Bug description: https://github.com/openstack/nova/blob/bc5035343d366a18cae587f92ecb4e871aba974a/plugins/xenserver/xenapi/etc/xapi.d/plugins/pluginlib_nova.py#L139 If the vbd unplug always return DEVICE_DETACH_REJECTED, it will be in loop for ever. So need add a maximum retry count in _vbd_unplug_with_retry. To manage notifications about this bug go to: https://bugs.launchpad.net/os-xenapi/+bug/1592362/+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 1667259] Re: one more pool is created for a loadbalancer
Let's plan something deeper from heat side if neutron can't solve this
issue at the end(which will not happen)
** Changed in: heat
Status: New => Won't Fix
** Changed in: heat
Assignee: Rico Lin (rico-lin) => (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/1667259
Title:
one more pool is created for a loadbalancer
Status in heat:
Won't Fix
Status in neutron:
New
Bug description:
One more pool is created when creating a load balancer with two pools.
That pool doesn't have complete information but related to that
loadblancer, which caused failure when deleting loadbalancer.
heat resource-list lbvd
WARNING (shell) "heat resource-list" is deprecated, please use "openstack
stack resource list" instead
+---+--+---+-+--+
| resource_name | physical_resource_id | resource_type
| resource_status | updated_time |
+---+--+---+-+--+
| listener | 12dfe005-80e0-4439-a4f8-1333f688e73b |
OS::Neutron::LBaaS::Listener | CREATE_COMPLETE | 2017-02-23T09:38:58Z |
| listener2 | 26ba1151-3d4b-4732-826b-7f318800070d |
OS::Neutron::LBaaS::Listener | CREATE_COMPLETE | 2017-02-23T09:38:58Z |
| loadbalancer | 3a5bfa24-220c-4316-9c3d-57dd9c13feb8 |
OS::Neutron::LBaaS::LoadBalancer | CREATE_COMPLETE | 2017-02-23T09:38:58Z |
| monitor | 241bc328-4c9b-4f58-a34a-4e25ed7431ea |
OS::Neutron::LBaaS::HealthMonitor | CREATE_COMPLETE | 2017-02-23T09:38:58Z |
| monitor2 | 6592b768-f3be-4ff9-bbf4-2c30b94f98e2 |
OS::Neutron::LBaaS::HealthMonitor | CREATE_COMPLETE | 2017-02-23T09:38:58Z |
| pool | 41652d9a-d0fe-4743-9e5f-2dfe98b19f3d |
OS::Neutron::LBaaS::Pool | CREATE_COMPLETE | 2017-02-23T09:38:58Z |
| pool2 | fae40172-7f16-4b1a-93f0-877d404fe466 |
OS::Neutron::LBaaS::Pool | CREATE_COMPLETE | 2017-02-23T09:38:58Z |
+---+--+---+-+--+
neutron lbaas-pool-list | grep lbvd
| 095c94b8-8c18-443f-9ce9-3d34e94f0c81 | lbvd-pool-ujtp6ddt4g6o
| HTTP| True |
| 41652d9a-d0fe-4743-9e5f-2dfe98b19f3d | lbvd-pool-ujtp6ddt4g6o
| HTTP| True |
| fae40172-7f16-4b1a-93f0-877d404fe466 | lbvd-pool2-kn7rlwltbdxh
| HTTPS| True |
neutron lbaas-pool-show 095c94b8-8c18-443f-9ce9-3d34e94f0c81
+-++
| Field | Value |
+-++
| admin_state_up | True |
| description||
| healthmonitor_id||
| id | 095c94b8-8c18-443f-9ce9-3d34e94f0c81 |
| lb_algorithm| ROUND_ROBIN|
| listeners ||
| loadbalancers | {"id": "3a5bfa24-220c-4316-9c3d-57dd9c13feb8"} |
| members||
| name| lbvd-pool-ujtp6ddt4g6o|
| protocol| HTTP |
| session_persistence ||
| tenant_id | 3dcf8b12327c460a966c1c1d4a6e2887 |
+-++
To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1667259/+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 1681979] [NEW] L2pop flows are lost after OVS agent restart
Public bug reported:
In OVS agent, there is a race condition between l2pop's add_fdb_entries
notification and provision_local_vlan when we create a vlanmanager
mapping. This results in either unicast, flooding, or both entries not
being populated on the host. Without the flooding entries, connectivity
is lost.
They are lost semi-permanently after this as l2Pop mechanism driver only
sends full list of fdb entries after a port_update_up, but only on 1st
agent port, or after OVS reboot (where we again hit same race condition,
or it partially fixed flows).
Legacy testbed w/ 3 nodes. 4 tenant networks:
1. The add_fdb_entries code path will create the tunnel port(s) in
add_fdb_tun, then invoke add_fdb_flow to add the BC/UC l2pop flows and -
but only if it can get a Vlanmanager mapping:
def fdb_add(self, context, fdb_entries):
LOG.info("2. fdb_add received")
for lvm, agent_ports in self.get_agent_ports(fdb_entries):
agent_ports.pop(self.local_ip, None)
LOG.info("2. fdb_add: agent_ports = %s", agent_ports)
LOG.info("2. fdb_add: lvm = %s", lvm)
if len(agent_ports):
if not self.enable_distributed_routing:
with self.tun_br.deferred() as deferred_br:
LOG.info("2. fdb_add: about to call fdb_add_tun w/ lvm
= %s", lvm)
self.fdb_add_tun(context, deferred_br, lvm,
agent_ports, self._tunnel_port_lookup)
else:
self.fdb_add_tun(context, self.tun_br, lvm,
agent_ports, self._tunnel_port_lookup)
def get_agent_ports(self, fdb_entries, local_vlan_map=None):
"""Generator to yield port info.
For each known (i.e found in VLAN manager) network in
fdb_entries, yield (lvm, fdb_entries[network_id]['ports']) pair.
:param fdb_entries: l2pop fdb entries
:param local_vlan_map: Deprecated.
"""
lvm_getter = self._get_lvm_getter(local_vlan_map)
for network_id, values in fdb_entries.items():
try:
lvm = lvm_getter(network_id, local_vlan_map)
except vlanmanager.MappingNotFound:
LOG.info("get_agent_ports: vlanmanager.MappingNotFound
EXCEPTION! netid = %s, local_vlan_map = %s", network_id, local_vlan_map)
continue
agent_ports = values.get('ports')
LOG.info("get_agent_ports: got lvm= %s", lvm)
yield (lvm, agent_ports)
2. If the vlan mapping isn't found, the tunnel port creation is skipped, as are
flows.
3. When we create VLAN mapping in provision_local_vlan(), the
install_flood_to_tun however is skipped if there are currently no tunnel
ports created:
def provision_local_vlan(self, net_uuid, network_type, physical_network,
segmentation_id):
...
if network_type in constants.TUNNEL_NETWORK_TYPES:
LOG.info("ARJUN: network_type = %s", network_type)
if self.enable_tunneling:
# outbound broadcast/multicast
ofports = list(self.tun_br_ofports[network_type].values())
LOG.info("ARJUN: provision_local_vlan: ofports = %s
enable_tunneling = %s", ofports, self.enable_tunneling)
if ofports:
LOG.info("ARJUN: installing FLOODING_ENTRY: lvid = %s
segment_id = %s", lvid, segmentation_id)
self.tun_br.install_flood_to_tun(lvid,
segmentation_id,
ofports)
# inbound from tunnels: set lvid in the right table
# and resubmit to Table LEARN_FROM_TUN for mac learning
4. Finally, the cleanup stale flows logic removes all old flows. At this
point br-tun is left with missing flooding and/or unicast flows.
5. If #3 always happens first for all networks, we are good. Otherwise flows
are lost:
Unicast only flows missing if (but flood added):
- Network Vlanmanager mapping is allocated *after* it's
add_fdb_entries, but some other network sets up tunnel ports on br-tun
Broadcast AND UC flows missing if:
- A network tries to add fdb flows before vlanmanager allocated, and no
other network has created the tunnel ports/ofports on br-tun yet.
Example with 3 tenant networks:
1. add_fdb_entries for network 1 and 2 - no LVM yet, so flow and tunnel ports
not created yet
2. LVM created for network 2, but flood not installed because no ofports
3. LVM created for networks 3
4. add_fdb_entries for network 3, here it properly finds the LVM, and creates
tunnel ports/flows
5. LVM created for network 1, tunnel ofports created, so flood installed - but
unicast missing
After this point, network 3 would be fine, network 2 would me missing
all flows, network 1 would have flood but not unicast.
The ordering seems to vary wildly depending
[Yahoo-eng-team] [Bug 1681973] [NEW] neutron-ns-metadata-proxy wsgi settings not tunable
Public bug reported: Based on commit https://github.com/openstack/neutron/commit/9d573387f1e33ce85269d3ed9be501717eed4807, the wsgi connection pool has been lowered to 100 threads, which is now a problem for the neutron-ns-metadata-proxy spawned by the neutron-metadata-agent and not passing through any wsgi parameters via the command line. Originally I ran into this issue where a customer was using chef on his guest instances and calling the metadata quite heavily (ohai plugin) and this was leading to a socket bottleneck. The ns-metadata-proxy can only open 100 sockets, per namespace, to the metadata agent and then all further TCP connections (all the way to the configured backlog limit) are getting delayed/back logged. This leads to further timeouts in the clients using metadata, exaggerating the problem even more. Once I manually started the ns-metadata-proxy, increasing the wsgi threads, all application issues disappeared. This particular problem can be experienced the more networks are attached to a neutron router. Knowing that master and Ocata is using a new nginx based implementation now, can this issue be even solved (although I assume the actual fix will be quite small) ? ** Affects: neutron Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1681973 Title: neutron-ns-metadata-proxy wsgi settings not tunable Status in neutron: New Bug description: Based on commit https://github.com/openstack/neutron/commit/9d573387f1e33ce85269d3ed9be501717eed4807, the wsgi connection pool has been lowered to 100 threads, which is now a problem for the neutron-ns-metadata-proxy spawned by the neutron-metadata-agent and not passing through any wsgi parameters via the command line. Originally I ran into this issue where a customer was using chef on his guest instances and calling the metadata quite heavily (ohai plugin) and this was leading to a socket bottleneck. The ns-metadata-proxy can only open 100 sockets, per namespace, to the metadata agent and then all further TCP connections (all the way to the configured backlog limit) are getting delayed/back logged. This leads to further timeouts in the clients using metadata, exaggerating the problem even more. Once I manually started the ns-metadata-proxy, increasing the wsgi threads, all application issues disappeared. This particular problem can be experienced the more networks are attached to a neutron router. Knowing that master and Ocata is using a new nginx based implementation now, can this issue be even solved (although I assume the actual fix will be quite small) ? To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1681973/+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 1681972] [NEW] Two tables overlap each other in Freezer UI when entries are in the table
Public bug reported: This problem occurs when the freezer panels are enabled and in Disaster Recovery -> Backup and Restore -> Jobs. When there are no entries in the table and the window is re-sized horizontally, there are no problems. However, when there are entries, the right-most table overlaps the left table. See attachments for example. Running off the code base (horizon, freezer, freezer-web-ui, python-freezerclient) on master branch on 2017-04-11. ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "Screenshots of this issue" https://bugs.launchpad.net/bugs/1681972/+attachment/4860469/+files/screenshots.zip -- 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/1681972 Title: Two tables overlap each other in Freezer UI when entries are in the table Status in OpenStack Dashboard (Horizon): New Bug description: This problem occurs when the freezer panels are enabled and in Disaster Recovery -> Backup and Restore -> Jobs. When there are no entries in the table and the window is re-sized horizontally, there are no problems. However, when there are entries, the right-most table overlaps the left table. See attachments for example. Running off the code base (horizon, freezer, freezer-web-ui, python-freezerclient) on master branch on 2017-04-11. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1681972/+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 1681946] [NEW] py27 unit test failure: ImageMetaProps has a system dependent hash signature.
Public bug reported:
Description
===
Running the Nova py27 unit tests on CentOS will result in the following
failures:
nova.tests.unit.objects.test_objects.TestObjectVersions.test_versions
nova.tests.unit.notifications.objects.test_notification.TestNotificationObjectVersions.test_versions
With a traceback similar to the following:
Captured traceback:
~~~
Traceback (most recent call last):
File "nova/tests/unit/objects/test_objects.py", line 1216, in
test_versions
'Some objects have changed; please make sure the '
File
"/src/nova/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py", line
411, in assertEqual
self.assertThat(observed, matcher, message)
File
"/src/nova/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py", line
498, in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: !=:
reference = {'ImageMetaProps': '1.18-3e5975251f5843e817de68ac83274c27'}
actual= {'ImageMetaProps': '1.18-d62a383b8cfa1779cb98014a3bf91581'}
: Some objects have changed; please make sure the versions have been
bumped, and then update their hashes here.
This was introduced as part of the following change:
https://review.openstack.org/#/c/351232/
The ImageSignatureHashType and ImageSignatureKeyType now use cursive's
signature_utils to generate a hash. The problem is that these values can be
different depending on the underlying capabilities of the system.
For example:
Ubuntu Xenial:
>>> signature_utils.SignatureKeyType.REGISTERED_TYPES.keys()
['RSA-PSS', 'ECC_SECP521R1', 'ECC_SECT409R1', 'ECC_SECT409K1', 'ECC_SECT571R1',
'ECC_SECP384R1', 'ECC_SECT571K1', 'DSA']
CentOS 7.3.1611:
>>> signature_utils.SignatureKeyType.REGISTERED_TYPES.keys()
['RSA-PSS', 'ECC_SECP521R1', 'ECC_SECP384R1', 'DSA']
For this reason, the values can't be reliably compared with the hardcoded hash
result in nova/tests/unit/objects/test_objects.py
Steps to reproduce
==
1. tox -e py27 on a CentOs (7) system. Other systems may suffer the same
failures.
Expected result
===
Unit tests pass
Actual result
=
Unit tests failed
Environment
===
1. Latest devstack, stock CentOS 7 VM, latest Nova
Logs & Configs
==
https://pastebin.com/1rqJaTPs
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-04-11.log.html#t2017-04-11T20:38:56
** 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/1681946
Title:
py27 unit test failure: ImageMetaProps has a system dependent hash
signature.
Status in OpenStack Compute (nova):
New
Bug description:
Description
===
Running the Nova py27 unit tests on CentOS will result in the
following failures:
nova.tests.unit.objects.test_objects.TestObjectVersions.test_versions
nova.tests.unit.notifications.objects.test_notification.TestNotificationObjectVersions.test_versions
With a traceback similar to the following:
Captured traceback:
~~~
Traceback (most recent call last):
File "nova/tests/unit/objects/test_objects.py", line 1216, in
test_versions
'Some objects have changed; please make sure the '
File
"/src/nova/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py", line
411, in assertEqual
self.assertThat(observed, matcher, message)
File
"/src/nova/.tox/py27/lib/python2.7/site-packages/testtools/testcase.py", line
498, in assertThat
raise mismatch_error
testtools.matchers._impl.MismatchError: !=:
reference = {'ImageMetaProps': '1.18-3e5975251f5843e817de68ac83274c27'}
actual= {'ImageMetaProps': '1.18-d62a383b8cfa1779cb98014a3bf91581'}
: Some objects have changed; please make sure the versions have been
bumped, and then update their hashes here.
This was introduced as part of the following change:
https://review.openstack.org/#/c/351232/
The ImageSignatureHashType and ImageSignatureKeyType now use cursive's
signature_utils to generate a hash. The problem is that these values can be
different depending on the underlying capabilities of the system.
For example:
Ubuntu Xenial:
>>> signature_utils.SignatureKeyType.REGISTERED_TYPES.keys()
['RSA-PSS', 'ECC_SECP521R1', 'ECC_SECT409R1', 'ECC_SECT409K1',
'ECC_SECT571R1', 'ECC_SECP384R1', 'ECC_SECT571K1', 'DSA']
CentOS 7.3.1611:
>>> signature_utils.SignatureKeyType.REGISTERED_TYPES.keys()
['RSA-PSS', 'ECC_SECP521R1', 'ECC_SECP384R1', 'DSA']
For this reason, the values can't be reliably compared with the hardcoded
hash result in nova/tests/unit/objects/test_objects.py
Steps to reproduce
==
1. tox -e py27 on a CentOs (7) system. Other systems may suffer the
[Yahoo-eng-team] [Bug 1681945] [NEW] Neutron Agent error "constraint violation"
Public bug reported:
screen-q-agt.txt:2017-04-11 20:40:50.354 8722 ERROR
neutron.agent.ovsdb.impl_vsctl [req-e330d428-6ab8-4594-8805-139a8ffa67b5 - -]
Unable to execute [
'ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--',
'--id=@manager', 'create', 'Manager', 'target="ptcp:6640:127.0.0.1"', '--',
'add', '
Open_vSwitch', '.', 'manager_options', '@manager']. Exception: Exit code: 1;
Stdin: ; Stdout: ; Stderr: ovs-vsctl: transaction error: {"details":"Tra
nsaction causes multiple rows in \"Manager\" table to have identical values
(\"ptcp:6640:127.0.0.1\") for index on column \"target\". First row, wit
h UUID c84c9746-c000-45b5-b5df-c20a39aa4569, was inserted by this transaction.
Second row, with UUID b80bee4e-6bea-4dcd-a3ac-12aa027dccf5, existed i
n the database before this transaction and was not modified by the
transaction.","error":"constraint violation"}
Full logs: http://10.49.81.37/logs/12/453012/3/check/dell-hw-tempest-
dsvm-ironic-pxe_drac/ff03702/
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1681945
Title:
Neutron Agent error "constraint violation"
Status in neutron:
New
Bug description:
screen-q-agt.txt:2017-04-11 20:40:50.354 8722 ERROR
neutron.agent.ovsdb.impl_vsctl [req-e330d428-6ab8-4594-8805-139a8ffa67b5 - -]
Unable to execute [
'ovs-vsctl', '--timeout=10', '--oneline', '--format=json', '--',
'--id=@manager', 'create', 'Manager', 'target="ptcp:6640:127.0.0.1"', '--',
'add', '
Open_vSwitch', '.', 'manager_options', '@manager']. Exception: Exit code: 1;
Stdin: ; Stdout: ; Stderr: ovs-vsctl: transaction error: {"details":"Tra
nsaction causes multiple rows in \"Manager\" table to have identical values
(\"ptcp:6640:127.0.0.1\") for index on column \"target\". First row, wit
h UUID c84c9746-c000-45b5-b5df-c20a39aa4569, was inserted by this
transaction. Second row, with UUID b80bee4e-6bea-4dcd-a3ac-12aa027dccf5,
existed i
n the database before this transaction and was not modified by the
transaction.","error":"constraint violation"}
Full logs: http://10.49.81.37/logs/12/453012/3/check/dell-hw-tempest-
dsvm-ironic-pxe_drac/ff03702/
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1681945/+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 1675571] Re: Cloud-init update renders secondary addresses to be incompatible with standard tools
** Bug watch added: Debian Bug tracker #783596
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783596
** Also affects: resolvconf (Debian) via
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=783596
Importance: Unknown
Status: Unknown
--
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/1675571
Title:
Cloud-init update renders secondary addresses to be incompatible with
standard tools
Status in cloud-init:
Confirmed
Status in curtin:
Confirmed
Status in cloud-init package in Ubuntu:
Confirmed
Status in resolvconf package in Ubuntu:
New
Status in resolvconf package in Debian:
Unknown
Bug description:
The change of how cloud-init renders
/etc/network/interface.d/50-cloud-init.cfg, standard tools no longer work as
expected:
* resolvconf will nullify nameservers
* if* commands ignore secondary addresses
[ORIGINAL REPORT]
Regresion from Bug #1657940.
When provisioning with multiple eth0 addresses, /etc/resolv.conf is
empty:
Consider:
root@tester:~# cat /etc/network/interfaces.d/50-cloud-init.cfg
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 138.197.98.102
dns-nameservers 8.8.8.8 8.8.4.4
gateway 138.197.96.1
netmask 255.255.240.0
# control-alias eth0
iface eth0 inet static
address 10.17.0.11
netmask 255.255.0.0
Which then yields an empty /etc/resolv.conf:
root@tester:/run/resolvconf# cat interface/eth0.inet
root@tester:/run/resolvconf# cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
The problem is that resolvconfg does pattern matching for eth*.inet.
The second definition of eth0 has no nameserver and therefore
overrides the definition.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1675571/+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 1681348] Re: keystone list project api returns empty if "?name=" is added as url parameter
If you're looking for all projects a user has access to, we have a
dedicated API for that per Kristi's comment:
GET http://{keystone_url}/v3/auth/projects
Feel free to re-open this if you believe this behavior is causing a bug
of some sort.
** Changed in: keystone
Status: New => Invalid
--
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/1681348
Title:
keystone list project api returns empty if "?name=" is added as url
parameter
Status in OpenStack Identity (keystone):
Invalid
Bug description:
request: https://{{keystone_ip}}:5000/v3/projects?name=
expect: returns all projects of current user.
but: return empty.
Other OpenStack components obey this convention properly, so keystone
is inconsistent with them.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1681348/+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 1681917] [NEW] Launch instance does not support vnic port types direct-physical or baremetal
Public bug reported: python-neutronclient was modified quite some time ago to support vnic types of direct-physical (https://review.openstack.org/262443) and baremetal (https://review.openstack.org/249393), but these are still not supported when launching instances in horizon. ** Affects: horizon Importance: Undecided Assignee: Gary W. Smith (gary-w-smith) Status: New ** Changed in: horizon Assignee: (unassigned) => Gary W. Smith (gary-w-smith) -- 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/1681917 Title: Launch instance does not support vnic port types direct-physical or baremetal Status in OpenStack Dashboard (Horizon): New Bug description: python-neutronclient was modified quite some time ago to support vnic types of direct-physical (https://review.openstack.org/262443) and baremetal (https://review.openstack.org/249393), but these are still not supported when launching instances in horizon. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1681917/+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 1642679] Re: The OpenStack network_config.json implementation fails on Hyper-V compute nodes
Reviewed: https://review.openstack.org/400883 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=f559be35a03f5801f527355895a97c89cdc3c336 Submitter: Jenkins Branch:master commit f559be35a03f5801f527355895a97c89cdc3c336 Author: Scott Moser Date: Fri Mar 31 17:01:33 2017 -0400 Limit exposure of network device types to the guest. Previously, the 'type' of the hypervisor network device, was exposed to the guest directly. That does not make sense, as a.) this leaks needless information into the guest b.) the guest cannot be reasonably expected to make decisions based on a type of link that is present underneath the virtual device that is presented to the guest. c.) guests then are forced to either continuously track these types or to assume that unknown type is "phy". This limits the exposure of types to a specific list. Any other type will be shown to the guest as 'phy'. Change-Id: Iea458fba29596cd2773d8d3565451af60b02bcca Closes-Bug: #1642679 ** 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/1642679 Title: The OpenStack network_config.json implementation fails on Hyper-V compute nodes Status in cloud-init: Fix Released Status in OpenStack Compute (nova): Fix Released 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 Yakkety: Fix Released Bug description: === Begin SRU Template === [Impact] When a config drive provides network_data.json on Azure OpenStack, cloud-init will fail to configure networking. Console log and /var/log/cloud-init.log will show: ValueError: Unknown network_data link type: hyperv This woudl also occur when the type of the network device as declared to cloud-init was 'hw_veb', 'hyperv', or 'vhostuser'. [Test Case] Launch an instance with config drive on hyperv cloud. [Regression Potential] Low to none. cloud-init is relaxing requirements and will accept things now that it previously complained were invalid. === End SRU Template === We have discovered an issue when booting Xenial instances on OpenStack environments (Liberty or newer) and Hyper-V compute nodes using config drive as metadata source. When applying the network_config.json, cloud-init fails with this error: http://paste.openstack.org/show/RvHZJqn48JBb0TO9QznL/ The fix would be to add 'hyperv' as a link type here: /usr/lib/python3/dist-packages/cloudinit/sources/helpers/openstack.py, line 587 Related bugs: * bug 1674946: cloud-init fails with "Unknown network_data link type: dvs * bug 1642679: OpenStack network_config.json implementation fails on Hyper-V compute nodes To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1642679/+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 1680240] Re: test_no_migrations_have_downgrade is broken
Reviewed: https://review.openstack.org/453872 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=f845e179687695d4b146c0143f4fa035d115fdd4 Submitter: Jenkins Branch:master commit f845e179687695d4b146c0143f4fa035d115fdd4 Author: Matt Riedemann Date: Wed Apr 5 17:00:05 2017 -0400 Fix test_no_migrations_have_downgrade This wasn't walking the correct directory and it wasn't including the API database migrations. Change-Id: Idff0e8089faf4025a080a5842ff65eaad7b6fdb8 Closes-Bug: #1680240 ** 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/1680240 Title: test_no_migrations_have_downgrade is broken Status in OpenStack Compute (nova): Fix Released Bug description: We have a unit test to check if a database migration script has a downgrade method, but it's broken since it didn't catch this: https://review.openstack.org/#/c/453025/2/nova/db/sqlalchemy/migrate_repo/versions/359_add_service_uuid.py To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1680240/+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 1681658] Re: disk_allocation_ratio does not work with placement API
** Changed in: nova Status: New => Won't Fix -- 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/1681658 Title: disk_allocation_ratio does not work with placement API Status in OpenStack Compute (nova): Won't Fix Bug description: disk_allocation_ratio is not working with Ocata since we are checking if requested amount is less than max_unit. Because of this if I have a compute with 64GB local disk and I'm using iSCSI storage then even after setting disk_allocation_ratio to .0 I can not create a VM with 80GB as root disk. Following code segment in objects/resource_provider.py is causing this to fail: _INV_TBL.c.resource_class_id == r_idx, (func.coalesce(usage.c.used, 0) + amount <= ( _INV_TBL.c.total - _INV_TBL.c.reserved ) * _INV_TBL.c.allocation_ratio), _INV_TBL.c.min_unit <= amount, _INV_TBL.c.max_unit >= amount, Environment: # openstack --version openstack 3.8.1 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1681658/+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 1636531] Re: unittests blkid command fails on slave s390x
Fixed by modifying the jenkins env. path to include /home/jenkins/bin:/home/jenkins/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin:/snap/bin ** Changed in: cloud-init Status: New => Invalid -- 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/1636531 Title: unittests blkid command fails on slave s390x Status in cloud-init: Invalid Bug description: Running the unittests on our slave s390x system, the blkid command fails. Running it manually returns the following: jenkins@s1lp04:~$ blkid -tLABEL=CDROM -odevice jenkins@s1lp04:~$ echo $? 2 jenkins@s1lp04:~$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT dasda 94:00 20.6G 0 disk |-dasda1 94:10 19.7G 0 part / `-dasda2 94:20 953.5M 0 part [SWAP] Full run output: https://jenkins.ubuntu.com/server/job/cloud-init-ci/nodes=s390x/53/console To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1636531/+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 1681784] Re: neutronclient: incorrect treatment of input parameters
** Also affects: python-neutronclient
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/1681784
Title:
neutronclient: incorrect treatment of input parameters
Status in neutron:
New
Status in python-neutronclient:
New
Bug description:
Hi colleagues,
Neutron 10.0.0 (as part Ocata) on Ubuntu 16.04
Everything is ok when I use Neutron CLI to update port parameters, but
when I'm doing the same using Heat, it fails.
Heat's template for the object is:
e-secgroup:
type: OS::Neutron::SecurityGroup
properties:
name: SSH_ICMP
rules:
- direction: ingress
- protocol: tcp
remote_ip_prefix: 0.0.0.0/0
port_range_min: 22
port_range_max: 22
- protocol: icmp
remote_ip_prefix: 0.0.0.0/0
node1-wan:
type: OS::Neutron::Port
properties:
name: jadm-node1-wan
network: e-net
port_security_enabled: True
security_groups: [ default, { get_resource: e-secgroup } ]
Heat makes a call to Neutron using neutronclient and provides input
parameters in such way:
updating port with {'allowed_address_pairs': [], 'binding:vnic_type':
None, 'device_owner': None, 'mac_address': None, 'security_groups': [u
'53ede63e-b08f-4c95-b5fe-29cd21ed442a', u'0a48c45e-5a6d-
4b80-8226-08d2e8c5bb00'], 'device_id': None} handle_update
/usr/lib/python2.7/dist-
packages/heat/engine/resources/openstack/neutron/port.py:520
In return, I get the following error:
2017-04-11 09:51:31.809 14474 DEBUG neutronclient.v2_0.client [req-
54a51260-8701-4f94-9141-562443a3ad7e - bush - - -] Error message:
{"NeutronError": {"message": "Invalid input for device_owner. Reason:
'None' is not a valid string.", "type": "HTTPBadRequest", "detail":
""}} _handle_fault_response /usr/lib/python2.7/dist-
packages/neutronclient/v2_0/client.py:266
If I explicitly set device_owner='' in Heat template, then
neutronclient accepts this key-value pair and returns error for the
next parameter (e.g. device_id):
2017-04-11 10:45:26.808 14474 DEBUG neutronclient.v2_0.client [req-
3f5c1c53-bec4-418f-bc0e-e04b23474c0e - bush - - -] Error message:
{"NeutronError": {"message": "Invalid input for device_id. Reason:
'None' is not a valid string.", "type": "HTTPBadRequest", "detail":
""}} _handle_fault_response /usr/lib/python2.7/dist-
packages/neutronclient/v2_0/client.py:266
and this affects not only parameters of OS::Neutron::Port object, but
OS::Neutron::SecurityGroup's ones as well:
Resource UPDATE failed: BadRequest: resources.e-secgroup: Invalid
input for description. Reason: 'None' is not a valid string. Neutron
server returns request_ids: ['req-287db7f6-06be-4bc8-a11b-
94be203c67da']
So, the problem is general and it seems that something wrong with
treatment of 'None' in input parameters: all clients should always
treat None values the same as not passing any value, while
neutronclient accepts '' and refuses None.
Severity: this bug blocks using Heat.
Thank you.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1681784/+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 1681843] [NEW] Nova-placement returns "ValueError: invalid literal for int() with base 10: ''"
Public bug reported:
Since
https://github.com/openstack/nova/commit/6dd047a3307a1056077608fd5bc2d1c3b3285338
we're seeing errors for Nova-placement service in the OpenStack-Ansible
gate jobs:
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack
[req-a9cb7079-b603-4c2c-9f99-8bc4293f9700 78e46f12329c4f71a7f6b97aa3a7eb57
f7d6ca89f4fb446eaebef93f7f235a50 - default default] Caught error: invalid
literal for int() with base 10: ''
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack Traceback (most recent
call last):
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack File
"/openstack/venvs/nova-master/lib/python2.7/site-packages/nova/api/openstack/__init__.py",
line 85, in __call__
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack return
req.get_response(self.application)
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack File
"/openstack/venvs/nova-master/lib/python2.7/site-packages/webob/request.py",
line 1316, in send
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack application,
catch_exc_info=False)
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack File
"/openstack/venvs/nova-master/lib/python2.7/site-packages/webob/request.py",
line 1280, in call_application
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack app_iter =
application(self.environ, start_response)
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack File
"/openstack/venvs/nova-master/lib/python2.7/site-packages/webob/dec.py", line
131, in __call__
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack resp =
self.call_func(req, *args, **self.kwargs)
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack File
"/openstack/venvs/nova-master/lib/python2.7/site-packages/webob/dec.py", line
196, in call_func
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack return self.func(req,
*args, **kwargs)
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack File
"/openstack/venvs/nova-master/lib/python2.7/site-packages/nova/api/openstack/placement/microversion.py",
line 123, in __call__
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack response =
req.get_response(self.application)
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack File
"/openstack/venvs/nova-master/lib/python2.7/site-packages/webob/request.py",
line 1316, in send
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack application,
catch_exc_info=False)
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack File
"/openstack/venvs/nova-master/lib/python2.7/site-packages/webob/request.py",
line 1280, in call_application
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack app_iter =
application(self.environ, start_response)
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack File
"/openstack/venvs/nova-master/lib/python2.7/site-packages/nova/api/openstack/placement/handler.py",
line 182, in __call__
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack if
int(environ.get('CONTENT_LENGTH', 0)):
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack ValueError: invalid
literal for int() with base 10: ''
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack
The Error is occurring because "CONTENT_LENGTH" is present but = '' and
the change attempts to set "None" to an int - which fails.
We're using Nginx /w uWSGI and I believe a default uwsgi param is set to
always send a CONTENT_LENGTH and CONTENT_TYPE header even when those are
empty.
** 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/1681843
Title:
Nova-placement returns "ValueError: invalid literal for int() with
base 10: ''"
Status in OpenStack Compute (nova):
New
Bug description:
Since
https://github.com/openstack/nova/commit/6dd047a3307a1056077608fd5bc2d1c3b3285338
we're seeing errors for Nova-placement service in the OpenStack-
Ansible gate jobs:
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack
[req-a9cb7079-b603-4c2c-9f99-8bc4293f9700 78e46f12329c4f71a7f6b97aa3a7eb57
f7d6ca89f4fb446eaebef93f7f235a50 - default default] Caught error: invalid
literal for int() with base 10: ''
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack Traceback (most recent
call last):
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack File
"/openstack/venvs/nova-master/lib/python2.7/site-packages/nova/api/openstack/__init__.py",
line 85, in __call__
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack return
req.get_response(self.application)
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack File
"/openstack/venvs/nova-master/lib/python2.7/site-packages/webob/request.py",
line 1316, in send
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack application,
catch_exc_info=False)
2017-04-10 17:43:45.761 2477 ERROR nova.api.openstack File
"/openstack/venvs/
[Yahoo-eng-team] [Bug 1675559] Re: api-ref: os-extended-volumes:volumes_attached keys are not described
Reviewed: https://review.openstack.org/449809
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=28831f3b3d5b889a8e260b007b4010a0ed571ec0
Submitter: Jenkins
Branch:master
commit 28831f3b3d5b889a8e260b007b4010a0ed571ec0
Author: Matt Riedemann
Date: Fri Mar 24 16:27:06 2017 -0400
api-ref: fix os-extended-volumes:volumes_attached in servers responses
There are two main changes here:
1. The contents of the os-extended-volumes:volumes_attached list are
described, which are the id and delete_on_termination keys, the latter
being introduced in the GET /servers response in 2.3.
2. The os-extended-volumes:volumes_attached parameters are removed from
the PUT /servers and POST /servers responses, since we don't actually
include those in the response for create and update operations, only
GET /servers/{server_id} and GET /servers/detail operations.
Note: create server is fixed in a follow up patch.
Change-Id: Ic92055e3095d220a3a11e35628f04e9e67c6b71a
Closes-Bug: #1675559
** 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/1675559
Title:
api-ref: os-extended-volumes:volumes_attached keys are not described
Status in OpenStack Compute (nova):
Fix Released
Bug description:
In the api-ref for server details we have os-extended-
volumes:volumes_attached which just says it's an array of attached
volumes. At 2.1 it's a list of dicts with a single 'id' key which is
the volume id. After 2.3 the list of dicts can also contain the
'delete_on_termination' key.
We don't describe the actual contents of that dict in the list, i.e.
the id and delete_on_termination keys.
We need to add os-extended-volumes:volumes_attached.id and os-
extended-volumes:volumes_attached.delete_on_termination keys to the
server details reference and note that delete_on_termination is only
shown with microversion >= 2.3.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1675559/+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 1681784] [NEW] neutronclient: incorrect treatment of input parameters
Public bug reported:
Hi colleagues,
Neutron 10.0.0 (as part Ocata) on Ubuntu 16.04
Everything is ok when I use Neutron CLI to update port parameters, but
when I'm doing the same using Heat, it fails.
Heat's template for the object is:
e-secgroup:
type: OS::Neutron::SecurityGroup
properties:
name: SSH_ICMP
rules:
- direction: ingress
- protocol: tcp
remote_ip_prefix: 0.0.0.0/0
port_range_min: 22
port_range_max: 22
- protocol: icmp
remote_ip_prefix: 0.0.0.0/0
node1-wan:
type: OS::Neutron::Port
properties:
name: jadm-node1-wan
network: e-net
port_security_enabled: True
security_groups: [ default, { get_resource: e-secgroup } ]
Heat makes a call to Neutron using neutronclient and provides input
parameters in such way:
updating port with {'allowed_address_pairs': [], 'binding:vnic_type':
None, 'device_owner': None, 'mac_address': None, 'security_groups': [u
'53ede63e-b08f-4c95-b5fe-29cd21ed442a', u'0a48c45e-5a6d-
4b80-8226-08d2e8c5bb00'], 'device_id': None} handle_update
/usr/lib/python2.7/dist-
packages/heat/engine/resources/openstack/neutron/port.py:520
In return, I get the following error:
2017-04-11 09:51:31.809 14474 DEBUG neutronclient.v2_0.client [req-
54a51260-8701-4f94-9141-562443a3ad7e - bush - - -] Error message:
{"NeutronError": {"message": "Invalid input for device_owner. Reason:
'None' is not a valid string.", "type": "HTTPBadRequest", "detail": ""}}
_handle_fault_response /usr/lib/python2.7/dist-
packages/neutronclient/v2_0/client.py:266
If I explicitly set device_owner='' in Heat template, then neutronclient
accepts this key-value pair and returns error for the next parameter
(e.g. device_id):
2017-04-11 10:45:26.808 14474 DEBUG neutronclient.v2_0.client [req-
3f5c1c53-bec4-418f-bc0e-e04b23474c0e - bush - - -] Error message:
{"NeutronError": {"message": "Invalid input for device_id. Reason:
'None' is not a valid string.", "type": "HTTPBadRequest", "detail": ""}}
_handle_fault_response /usr/lib/python2.7/dist-
packages/neutronclient/v2_0/client.py:266
and this affects not only parameters of OS::Neutron::Port object, but
OS::Neutron::SecurityGroup's ones as well:
Resource UPDATE failed: BadRequest: resources.e-secgroup: Invalid input
for description. Reason: 'None' is not a valid string. Neutron server
returns request_ids: ['req-287db7f6-06be-4bc8-a11b-94be203c67da']
So, the problem is general and it seems that something wrong with
treatment of 'None' in input parameters: all clients should always treat
None values the same as not passing any value, while neutronclient
accepts '' and refuses None.
Severity: this bug blocks using Heat.
Thank you.
** Affects: neutron
Importance: Undecided
Status: New
** Tags: neutron neutronclient
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1681784
Title:
neutronclient: incorrect treatment of input parameters
Status in neutron:
New
Bug description:
Hi colleagues,
Neutron 10.0.0 (as part Ocata) on Ubuntu 16.04
Everything is ok when I use Neutron CLI to update port parameters, but
when I'm doing the same using Heat, it fails.
Heat's template for the object is:
e-secgroup:
type: OS::Neutron::SecurityGroup
properties:
name: SSH_ICMP
rules:
- direction: ingress
- protocol: tcp
remote_ip_prefix: 0.0.0.0/0
port_range_min: 22
port_range_max: 22
- protocol: icmp
remote_ip_prefix: 0.0.0.0/0
node1-wan:
type: OS::Neutron::Port
properties:
name: jadm-node1-wan
network: e-net
port_security_enabled: True
security_groups: [ default, { get_resource: e-secgroup } ]
Heat makes a call to Neutron using neutronclient and provides input
parameters in such way:
updating port with {'allowed_address_pairs': [], 'binding:vnic_type':
None, 'device_owner': None, 'mac_address': None, 'security_groups': [u
'53ede63e-b08f-4c95-b5fe-29cd21ed442a', u'0a48c45e-5a6d-
4b80-8226-08d2e8c5bb00'], 'device_id': None} handle_update
/usr/lib/python2.7/dist-
packages/heat/engine/resources/openstack/neutron/port.py:520
In return, I get the following error:
2017-04-11 09:51:31.809 14474 DEBUG neutronclient.v2_0.client [req-
54a51260-8701-4f94-9141-562443a3ad7e - bush - - -] Error message:
{"NeutronError": {"message": "Invalid input for device_owner. Reason:
'None' is not a valid string.", "type": "HTTPBadRequest", "detail":
""}} _handle_fault_response /usr/lib/python2.7/dist-
packages/neutronclient/v2_0/client.py:266
If I explicitly set device_owner='' in Heat template, then
neutronclient accepts this key-value pair and returns error for the
next parameter (e.g. device_id):
2017-04-11 10:45:26.808 14474 DEBUG neutronclient.v2_0.cl
[Yahoo-eng-team] [Bug 1681756] [NEW] FIP allocation form: max is incorrect in N (used) of M (max)
Public bug reported: In the FIP allocation form, maximum count (M) and used count (N) are displayed in the form of "N of M", but the maximum count is not correct. Available count is displayed instead. In case of max 5, available 3, used 2, the message should be "2 of 5", but "2 of 3" is displayed. ** Affects: horizon Importance: Low Assignee: Akihiro Motoki (amotoki) Status: In Progress ** Changed in: horizon Importance: Undecided => Low -- 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/1681756 Title: FIP allocation form: max is incorrect in N (used) of M (max) Status in OpenStack Dashboard (Horizon): In Progress Bug description: In the FIP allocation form, maximum count (M) and used count (N) are displayed in the form of "N of M", but the maximum count is not correct. Available count is displayed instead. In case of max 5, available 3, used 2, the message should be "2 of 5", but "2 of 3" is displayed. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1681756/+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 1681728] [NEW] QoS rule object should be manage in QosRule metaclass
Public bug reported: All QoS rule type classes inherit from abstract class QosRule [1]. Those rules are always dependent on a QoS rule, through a coerced relationship on the abstract class. QosPolicy: rules: obj_fields.ListOfObjectsField(QosRule.obj_name(), subclasses=True) Versions in QoS rule classes need to be handled from the parent QosRule object because it's the only reference QosPolicy can make to them via obj_relationships version map. [1] https://github.com/openstack/neutron/blob/master/neutron/objects/qos/rule.py#L49 ** Affects: neutron Importance: Undecided Status: New ** Tags: qos ** Tags added: qos -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1681728 Title: QoS rule object should be manage in QosRule metaclass Status in neutron: New Bug description: All QoS rule type classes inherit from abstract class QosRule [1]. Those rules are always dependent on a QoS rule, through a coerced relationship on the abstract class. QosPolicy: rules: obj_fields.ListOfObjectsField(QosRule.obj_name(), subclasses=True) Versions in QoS rule classes need to be handled from the parent QosRule object because it's the only reference QosPolicy can make to them via obj_relationships version map. [1] https://github.com/openstack/neutron/blob/master/neutron/objects/qos/rule.py#L49 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1681728/+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 1681627] Re: Page not found error on refreshing bowser
** 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/1681627 Title: Page not found error on refreshing bowser Status in OpenStack Dashboard (Horizon): New Status in Zun-UI: New Bug description: Once I get into the container detail view, refresh the browser will show a page not found error: The current URL, ngdetails/OS::Zun::Container/c54ba416-a955-45b2 -848b-aee57b748e08, didn't match any of these Full output: http://paste.openstack.org/show/605296/ To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1681627/+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 1681687] [NEW] instance path not be deleted after evacuate
Public bug reported: Description === After evacuate an instance to a new host, then live-migration it to the old host, nova-compute report "DestinationDiskExists" error. When nova-compute on old host restarts, it only deletes the evacuated instance path that needs destroying disks. If the instance is on shared block storage such as ceph, nova-compute will not delete instance path. Steps to reproduce === * create an instance on a compute node using ceph backend * crash the compute node * evacuate the instance * reboot the crashed node Expected result === The evacuated instance path should be deleted. Actual result = After crashed nova-compute restarts, the instance path still exists. Environment === I used stable Kilo. But I think it's still valid on the master. ** Affects: nova Importance: Undecided Assignee: Xiao Gong (gongxiao) Status: New ** Changed in: nova Assignee: (unassigned) => Xiao Gong (gongxiao) -- 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/1681687 Title: instance path not be deleted after evacuate Status in OpenStack Compute (nova): New Bug description: Description === After evacuate an instance to a new host, then live-migration it to the old host, nova-compute report "DestinationDiskExists" error. When nova-compute on old host restarts, it only deletes the evacuated instance path that needs destroying disks. If the instance is on shared block storage such as ceph, nova-compute will not delete instance path. Steps to reproduce === * create an instance on a compute node using ceph backend * crash the compute node * evacuate the instance * reboot the crashed node Expected result === The evacuated instance path should be deleted. Actual result = After crashed nova-compute restarts, the instance path still exists. Environment === I used stable Kilo. But I think it's still valid on the master. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1681687/+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
