[Yahoo-eng-team] [Bug 1792503] Re: allocation candidates "?member_of=" doesn't work with nested providers
** Also affects: nova/rocky Importance: Undecided Status: New ** Changed in: nova/rocky Status: New => In Progress ** Changed in: nova/rocky Assignee: (unassigned) => Tetsuro Nakamura (tetsuro0907) ** Changed in: nova/rocky Importance: Undecided => Medium -- 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/1792503 Title: allocation candidates "?member_of=" doesn't work with nested providers Status in OpenStack Compute (nova): In Progress Status in OpenStack Compute (nova) rocky series: In Progress Bug description: "GET /allocation_candidates" now supports "member_of" parameter. With nested providers present, this should work with the following constraints. - (a) With "member_of" qparam, aggregates on the root should span on the whole tree If a root provider is in the aggregate, which has been specified by "member_of" qparam, the resource providers under that root can be in allocation candidates even the root is absent. (b) Without "member_of" qparam, sharing resource provider should be shared with the whole tree If a sharing provider is in the same aggregate with one resource provider (rpA), and "member_of" hasn't been specified in qparam by user, the sharing provider can be in allocation candidates with any of the resource providers in the same tree with rpA. (c) With "member_of" qparam, the range of the share of sharing resource providers should shrink to the resource providers "under the specified aggregates" in a tree. Here, whether the rp is "under the specified aggregates" is determined with the constraints of (a). Namely, not only rps that belongs to the aggregates directly are "under the aggregates", but olso rps whose root is under the aggregates are also "under the aggregates". - So far at Stein PTG time, 2018 Sep. 13th, this constraint is broken in the point that when placement picks up allocation candidates, the aggregates of nested providers are assumed as the same as root providers. This means it ignores the aggregates of the nested provider itself. This could result in the lack of allocation candidates when an aggregate which on a nested provider but not on the root has been specified in the `member_of` query parameter. This bug is well described in a test case which is submitted shortly. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1792503/+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 1806777] [NEW] cloud-init with iscsi ibft keeps interface at 'manual' so the system gets no dns search domain
Public bug reported: [impact] in bug 1752391, cloud-init was updated to check if the initramfs has specific iscsi root device config (e.g. static initramfs config, or ibft), and if so then set up the interface in e/n/i but do not mark it as 'auto'. This prevents ifupdown from actually running dhclient for the interface; the reason for the change in that bug was to prevent a hang at shutdown, as taking down the interface removes access to the iscsi root disk (thus hanging the system). However, iBFT has no mechanism in its spec to provide the DNS search domain, so while the interface ip address/netmask and gateway is correctly set up when the system finishes booting, it does not contain any search domain in /etc/resolv.conf. There is no way to get this information except from an actual dhcp query/response. In the initramfs, if open-iscsi does not detect ibft (or have static config built-in) then it will not create a /run/net-IFACE.conf file; if it does find ibft (or have static config) it will create a /run/net- IFACE.conf file with the config data that it has (e.g. with ibft, all the interface configuration that ibft is able and configured to provide). After this (setting up the interface and mounting the root dev), ipconfig runs and checks for the existence of /run/net-IFACE.conf file. If it does NOT exist, then ipconfig creates it containing the result of the dhcp lease response that ipconfig received - which includes the dns search domain. However, if there is already a /run /net-IFACE.conf file, ipconfig does NOT update it. So, the file created by open-iscsi remains, without any dns search domain. Once the system boots, resolvconf checks for existance of the /etc/net- IFACE.conf file, and if found it transfers some of the data into /etc/resolv.conf (e.g. the dns search domain). Since it does not contain any dns search domain, the /etc/resolv.conf file does not contain it either. If the system is configured to start dhclient for the interface, then dhclient receives and sets up the system resolv.conf to use the dns search domain correctly. For trusty: cloud-init is very different and sets up the running system ifupdown to start dhclient for the root device interface. The dns search domain is therefore configured by dhclient in the runtime system. For xenial: cloud-init sets up the iscsi root device's interface with a e/n/i configuration for dhcp, but leaves its 'auto' line commented out, e.g.: # control-manual ens3f0 iface ens3f0 inet dhcp dns-nameservers 169.254.169.254 gateway 10.0.0.1 this results in no dns search domain for the system. For bionic and later: cloud-init sets up netplan instead of ifupdown; netplan has no such 'auto' mechanism, but it creates systemd-networkd .network file with the "CriticalConnection" parameter set to true, which prevents systemd-networkd from ever taking the interface down, which avoids the hang on shutdown (or any other time dhcp fails/stops for the interface). [test case] start a xenial system that uses ibft and check /etc/resolv.conf; there will be no dns search domain. [regression potential] depending on the specific fix, this has the potential to cause the interface to be taken down which would then hang the system (due to root device being iscsi). [other info] this appears to have been introduced by bug 1752391. This bug may possibly also exist if the "ip=" parameter is used, which also triggers the cloud-init code that sets the runtime interface to 'manual' instead of 'auto', though I have not specifically tested that. ** Affects: cloud-init Importance: Undecided Status: Invalid ** Affects: cloud-init (Ubuntu) Importance: Undecided Status: Invalid ** Affects: cloud-init (Ubuntu Trusty) Importance: Undecided Status: Invalid ** Affects: cloud-init (Ubuntu Xenial) Importance: Medium Assignee: Dan Streetman (ddstreet) Status: In Progress ** Affects: cloud-init (Ubuntu Bionic) Importance: Undecided Status: Invalid ** Also affects: cloud-init (Ubuntu) Importance: Undecided Status: New ** Changed in: cloud-init Status: New => Invalid ** Also affects: cloud-init (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: cloud-init (Ubuntu Trusty) Importance: Undecided Status: New ** Changed in: cloud-init (Ubuntu Trusty) Status: New => Invalid ** Changed in: cloud-init (Ubuntu Bionic) Status: New => Invalid ** Changed in: cloud-init (Ubuntu Xenial) Status: New => In Progress ** Changed in: cloud-init (Ubuntu Xenial) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: cloud-init (Ubuntu) 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/1806
[Yahoo-eng-team] [Bug 1385234] Re: OVS tunneling between multiple neutron nodes misconfigured if amqp is restarted
** Changed in: oslo.messaging Status: Incomplete => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1385234 Title: OVS tunneling between multiple neutron nodes misconfigured if amqp is restarted Status in neutron: Incomplete Status in oslo.messaging: Fix Released Status in tripleo: Fix Released Bug description: At completion of a deployment with multiple controllers, by observing the gre tunnels created in OVS by the neutron ovs-agent, one will find that some neutron nodes may miss the tunnels in between them or to the computes. This is due to ovs-agents getting disconnected from the rabbit cluster without them noticing and as a result, being unable to receive updates from other nodes or publish updates. The disconnection may happen following a reconfig of a rabbit node, the VIP moving over a different node when rabbit is load balanced, or even _during_ tripleo overcloud deployment due to rabbit cluster configuration changes. This was observed using Kombu 3.0.33 as well as 2.5. Use of some aggressive (low) kernel keepalive probes interval seems to improve the reliability but a more appropriate fix seems to be support for heartbeat in oslo.messaging To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1385234/+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 1806770] [NEW] DHCP Agent should not release DHCP lease when client ID is not set on port
Public bug reported: DHCP agent has a really strict enforcement of client ID, which is part of the DHCP extra options. If a VM advertises a client ID, DHCP agent will automatically release it's lease whenever *any* other port is updated/deleted. This happens even if no client ID is set on the port. When reload_allocations() is called, DHCP agent parses the current leases file, the hosts file, and gets the list all the ports in the network from DB, computing 3 different sets. The set from leases file (v4_leases) will have some client ID. The set from port DB will have None. As a result the set subtraction does not filter out the entry, and the port's DHCP lease is constantly released, whenever the VM renews its lease and any other port in the network is deleted: https://github.com/openstack/neutron/blob/stable/pike/neutron/agent/linux/dhcp.py#L850 v4_leases = set() for (k, v) in cur_leases.items(): # IPv4 leases have a MAC, IPv6 ones do not, so we must ignore if netaddr.IPAddress(k).version == constants.IP_VERSION_4: # treat '*' as None, see note in _read_leases_file_leases() client_id = v['client_id'] if client_id is '*': client_id = None v4_leases.add((k, v['iaid'], client_id)) new_leases = set() for port in self.network.ports: client_id = self._get_client_id(port) for alloc in port.fixed_ips: new_leases.add((alloc.ip_address, port.mac_address, client_id)) # If an entry is in the leases or host file(s), but doesn't have # a fixed IP on a corresponding neutron port, consider it stale. entries_to_release = (v4_leases | old_leases) - new_leases if not entries_to_release: return I believe that this client ID and releasing of lease should only occur if a client id is set in the port's DHCP Extra opts and there is a mismatch. Otherwise, ignore whatever client ID the VM advertises. This can cause issues where when the VM later asks to renew its lease when the expiry period is coming up (I think about halfway thru), dnsmasq sends an DHCP NAK and the lease is re-negotiated and existing networking connections can get disrupted. It also just causes DHCP agent to do unneccessary work, releasing a ton of leases when it technically shouldn't. Setting the client ID in the port's DHCP extra opts is not an good solution: 1. In some cases, like Windows VMs, the client ID is advertised as the MAC by default. In fact, there is a Windows bug which prevents you from even turning this off: https://support.microsoft.com/en-us/help/3004537 /dhcp-client-always-includes-option-61-in-the-dhcp-request-in-windows-8 Linux VMs dont have this on by default, when I checked, but they may be enabled in some templates unknown to users 2. End users will usually just be deploying a VM, with the port being auto created by Nova. They don't know or need to know about advanced networking concepts like DHCP client IDs. 3. We can't expect everyone to modify their existing app templates, or end users to make API calls, to update ports everytime they deploy a VM So, client ID should only be enforce, and leases released, if it's actually set on the port. In that case it means someone knows what they are doing, and we want to check for a mismatch. If its None, I suspect in 99.% of cases the operator does not know or care about client ID field. ** Affects: neutron Importance: Undecided Assignee: Arjun Baindur (abaindur) Status: New ** Tags: l3-ipam-dhcp ** Changed in: neutron Assignee: (unassigned) => Arjun Baindur (abaindur) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1806770 Title: DHCP Agent should not release DHCP lease when client ID is not set on port Status in neutron: New Bug description: DHCP agent has a really strict enforcement of client ID, which is part of the DHCP extra options. If a VM advertises a client ID, DHCP agent will automatically release it's lease whenever *any* other port is updated/deleted. This happens even if no client ID is set on the port. When reload_allocations() is called, DHCP agent parses the current leases file, the hosts file, and gets the list all the ports in the network from DB, computing 3 different sets. The set from leases file (v4_leases) will have some client ID. The set from port DB will have None. As a result the set subtraction does not filter out the entry, and the port's DHCP lease is constantly released, whenever the VM renews its lease and any other port in the network is deleted: https://github.com/openstack/neutron/blob/stable/pike/neutron/agent/linux/dhcp.py#L850 v4_leases = set() for (k, v) in cur_leases.items(): # IPv4 leases have a MAC, IPv6
[Yahoo-eng-team] [Bug 1806762] [NEW] policy.v3cloudsample.json contains redundant policies
Public bug reported: The policy.v3cloudsample.json policy file contains a bunch of redundant policies. This is because when it was created to try and solve the admin-ness problem [0], policies were not in code and didn't have defaults. This meant that we needed to define every policy in the policy.v3cloudsample.json even if it had the same value as the default policies. Ultimately, the policy.v3cloudsample.json policy file should be removed because it is obsolete with the advent of system-scope [0] and default roles [1]. [0] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html [1] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html ** Affects: keystone Importance: Medium Status: Triaged ** Tags: policy ** Tags added: policy ** Changed in: keystone Status: New => Triaged ** Changed in: keystone Importance: Undecided => Medium -- 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/1806762 Title: policy.v3cloudsample.json contains redundant policies Status in OpenStack Identity (keystone): Triaged Bug description: The policy.v3cloudsample.json policy file contains a bunch of redundant policies. This is because when it was created to try and solve the admin-ness problem [0], policies were not in code and didn't have defaults. This meant that we needed to define every policy in the policy.v3cloudsample.json even if it had the same value as the default policies. Ultimately, the policy.v3cloudsample.json policy file should be removed because it is obsolete with the advent of system-scope [0] and default roles [1]. [0] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/queens/system-scope.html [1] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1806762/+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 1229324] Re: extraneous vim editor configuration comments
** Changed in: manila-ui Importance: Undecided => Low ** Changed in: manila-ui Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1229324 Title: extraneous vim editor configuration comments Status in Ceilometer: Fix Released Status in Cinder: Fix Released Status in Glance: Fix Released Status in OpenStack Heat: Fix Released Status in OpenStack Dashboard (Horizon): Fix Released Status in Manila: Fix Released Status in manila-ui: Fix Released Status in neutron: Fix Released Status in OpenStack Compute (nova): Fix Released Status in oslo-incubator: Fix Released Status in python-ceilometerclient: Fix Released Status in python-cinderclient: Fix Released Status in Glance Client: Fix Released Status in python-neutronclient: Fix Released Status in python-swiftclient: In Progress Status in python-troveclient: Fix Released Status in storyboard: New Status in OpenStack Object Storage (swift): In Progress Status in taskflow: Fix Released Status in tempest: Fix Released Status in tuskar: Fix Released Bug description: Many of the source code files have a beginning line # vim: tabstop=4 shiftwidth=4 softtabstop=4 This should be deleted. Many of these lines are in the ceilometer/openstack/common directory. To manage notifications about this bug go to: https://bugs.launchpad.net/ceilometer/+bug/1229324/+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 1806515] Re: Instance tag not taken care of when bury in cell0
** Changed in: nova Importance: Undecided => Medium ** Tags added: api cells ** Also affects: nova/pike Importance: Undecided Status: New ** Also affects: nova/rocky Importance: Undecided Status: New ** Also affects: nova/queens Importance: Undecided Status: New ** Changed in: nova/pike Importance: Undecided => Medium ** Changed in: nova/rocky Importance: Undecided => Medium ** Changed in: nova/queens Importance: Undecided => Medium ** Changed in: nova/pike Status: New => Confirmed ** Changed in: nova/queens Status: New => Confirmed ** Changed in: nova/rocky Status: New => Confirmed -- 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/1806515 Title: Instance tag not taken care of when bury in cell0 Status in OpenStack Compute (nova): In Progress Status in OpenStack Compute (nova) pike series: Confirmed Status in OpenStack Compute (nova) queens series: Confirmed Status in OpenStack Compute (nova) rocky series: Confirmed Bug description: We allowed add instance tags when booting in Iac54b9627cb4398e45f1f15a2f4e7d6f86242093, conductor will create tags for us in the selected cell, but we forgot to consider the case that no valid host was found. So we will be unable to filter those instances in cell0 with tags. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1806515/+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 1806701] [NEW] cloud-init may hang OS boot process due to grep for the entire ISO file when it is attached
Public bug reported:
We have found in our test for SLES15 with cloud-init installed, if we
attach a ISO file with the VM before VM is boot, it often takes more
than 10 minutes to start the SLES OS. Sometimes it failed to start the
SLES OS at all.
We've root caused it is due to the "is_cdrom_ovf()" func of "tools/ds-
identify".
In this function, there is the following logic to detect if an ISO contains
certain string:
>local idstr="http://schemas.dmtf.org/ovf/environment/1";
>grep --quiet --ignore-case "$idstr" "${PATH_ROOT}$dev"
ref: https://git.launchpad.net/cloud-init/tree/tools/ds-identify
It is trying to grep the who ISO file for a certain string, which causes
intense IO pressure for the system.
What is worse is that sometimes the ISO file is large (e.g. >5GB for installer
DVD) and it is mounted over NFS. The "grep" process often consume 99% CPU and
seems hang. Then the systemd starts more and more "grep" process which smoke
the CPU and consumes all the IO bandwidth for the ISO file. Then the system may
hang for a long time and sometimes failed to start.
To fix this issue, I suggest that we should not grep for the entire ISO
file. Rather then we should just check if the file/dir exists with
os.path.exists().
-debug log snip
pek2-gosv-16-dhcp180:~ # ps -ef
UIDPID PPID C STIME TTY TIME CMD
root 1 0 0 13:32 ?00:00:04 /usr/lib/systemd/systemd
--switched-root --system --deserialize 24
…
root 474 1 0 13:34 ?00:00:00 /bin/sh
/usr/lib/cloud-init/ds-identify
root 482 474 2 13:34 ?00:00:15 grep --quiet --ignore-case
http://schemas.dmtf.org/ovf/environment/1 /dev/sr1
root 1020 1 0 13:35 ?00:00:00 /bin/sh
/usr/lib/cloud-init/ds-identify
root 1039 1020 1 13:35 ?00:00:07 grep --quiet --ignore-case
http://schemas.dmtf.org/ovf/environment/1 /dev/sr1
polkitd 1049 1 0 13:37 ?00:00:00 /usr/lib/polkit-1/polkitd
--no-debug
root 1051 1 0 13:37 ?00:00:00 /usr/sbin/wickedd --systemd
--foreground
root 1052 1 0 13:37 ?00:00:00 /usr/lib/systemd/systemd-logind
root 1054 1 0 13:37 ?00:00:00 /usr/sbin/wickedd-nanny
--systemd --foreground
root 1073 1 0 13:37 ?00:00:00 /usr/bin/vmtoolsd
root 1097 1 0 13:37 ?00:00:00 /bin/sh
/usr/lib/cloud-init/ds-identify
root 1110 1097 1 13:37 ?00:00:04 grep --quiet --ignore-case
http://schemas.dmtf.org/ovf/environment/1 /dev/sr1
root 1304 1 0 13:38 ?00:00:00 /bin/sh
/usr/lib/cloud-init/ds-identify
root 1312 1304 1 13:38 ?00:00:03 grep --quiet --ignore-case
http://schemas.dmtf.org/ovf/environment/1 /dev/sr1
root 1537 1 0 13:40 ?00:00:00 /usr/bin/plymouth --wait
root 1613 1 0 13:40 ?00:00:00 /bin/sh
/usr/lib/cloud-init/ds-identify
root 1645 1613 0 13:40 ?00:00:02 grep --quiet --ignore-case
http://schemas.dmtf.org/ovf/environment/1 /dev/sr1
…
Grep use nearly 100% cpu, system very slow.
top - 13:46:37 up 26 min, 2 users, load average: 14.14, 15.03, 10.57
Tasks: 225 total, 6 running, 219 sleeping, 0 stopped, 0 zombie
%Cpu(s): 40.1 us, 49.3 sy, 0.0 ni, 0.0 id, 1.4 wa, 0.0 hi, 9.1 si, 0.0 st
KiB Mem : 1000916 total,64600 free, 355880 used, 580436 buff/cache
KiB Swap: 1288168 total, 1285600 free, 2568 used. 492688 avail Mem
PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND
4427 root 20 0 40100 3940 3084 R 99.90 0.394 0:27.41 top
1016 root 20 0 197796 4852 3400 R 99.90 0.485 1:26.44 vmtoolsd
1723 root 20 07256 1860 1556 D 99.90 0.186 0:28.44 grep
484 root 20 07256 1684 1396 D 99.90 0.168 1:51.22 grep
1278 root 20 07256 1856 1556 D 99.90 0.185 0:38.44 grep
1398 root 20 07256 1860 1556 R 99.90 0.186 0:28.53 grep
1061 root 20 07256 1856 1556 D 99.90 0.185 0:56.62 grep
-debug log snip
** 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/1806701
Title:
cloud-init may hang OS boot process due to grep for the entire ISO
file when it is attached
Status in cloud-init:
New
Bug description:
We have found in our test for SLES15 with cloud-init installed, if we
attach a ISO file with the VM before VM is boot, it often takes more
than 10 minutes to start the SLES OS. Sometimes it failed to start the
SLES OS at all.
We've root caused it is due to the "is_cdrom_ovf()" func of "tools
/ds-identify".
In this function, there is the following logic to detect if an ISO contains
certain string:
>local idstr="ht
[Yahoo-eng-team] [Bug 1806713] [NEW] Remove obsolete role policies from policy.v3cloudsample.json
Public bug reported: Once support for scope types landed in the role API policies, the policies in policy.v3cloudsample.json became obsolete [0][1]. We should add formal protection for the policies with enforce_scope = True in keystone.tests.unit.protection.v3 and remove the old policies from the v3 sample policy file. This will reduce confusion by having a true default policy for limits and registered limits. [0] https://review.openstack.org/#/c/526171/ [1] http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json?id=fb73912d87b61c419a86c0a9415ebdcf1e186927#n91 ** Affects: keystone Importance: Undecided Status: New ** Tags: policy ** Tags added: policy -- 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/1806713 Title: Remove obsolete role policies from policy.v3cloudsample.json Status in OpenStack Identity (keystone): New Bug description: Once support for scope types landed in the role API policies, the policies in policy.v3cloudsample.json became obsolete [0][1]. We should add formal protection for the policies with enforce_scope = True in keystone.tests.unit.protection.v3 and remove the old policies from the v3 sample policy file. This will reduce confusion by having a true default policy for limits and registered limits. [0] https://review.openstack.org/#/c/526171/ [1] http://git.openstack.org/cgit/openstack/keystone/tree/etc/policy.v3cloudsample.json?id=fb73912d87b61c419a86c0a9415ebdcf1e186927#n91 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1806713/+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 1806711] [NEW] Message timeout leads to inconsistant disk attachments
Public bug reported: A message timeout causes a disk attachment to fail (which is legit). The problem is that the disk is actually attached to the VM and the rollback does not remove the disk from the VM and only sets the cinder/nova stats as available for the volume. Subsequent attachments will fail. Original stack is: 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] Traceback (most recent call last): 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] File "/usr/lib/python2.7/dist-packages/nova/virt/block_device.py", line 306, in attach 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] encryption=encryption) 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] File "/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/driver.py", line 465, in detach_volume 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] if self._check_vio_import(instance): 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] File "/usr/lib/python2.7/dist-packages/nova/virt/vmwareapi/driver.py", line 458, in _check_vio_import 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] instance_meta = instance_metadata.InstanceMetadata(instance) 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] File "/usr/lib/python2.7/dist-packages/nova/api/metadata/base.py", line 141, in __init__ 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] self.mappings = _format_instance_mapping(ctxt, instance) 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] File "/usr/lib/python2.7/dist-packages/nova/api/metadata/base.py", line 700, in _format_instance_mapping 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] ctxt, instance.uuid) 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] File "/usr/lib/python2.7/dist-packages/oslo_versionedobjects/base.py", line 177, in wrapper 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] args, kwargs) 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] File "/usr/lib/python2.7/dist-packages/nova/conductor/rpcapi.py", line 239, in object_class_action_versions 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] args=args, kwargs=kwargs) 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] File "/usr/lib/python2.7/dist-packages/oslo_messaging/rpc/client.py", line 169, in call 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] retry=self.retry) 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] File "/usr/lib/python2.7/dist-packages/oslo_messaging/transport.py", line 97, in _send 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] timeout=timeout, retry=retry) 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 458, in send 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] retry=retry) 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 447, in _send 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] result = self._waiter.wait(msg_id, timeout) 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 339, in wait 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] message = self.waiters.get(msg_id, timeout=timeout) 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-4afb-9317-bbab4599dad9] File "/usr/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqpdriver.py", line 238, in get 2018-12-03 04:30:58.003 2442 ERROR nova.virt.block_device [instance: 500f5906-1385-
[Yahoo-eng-team] [Bug 1805808] Re: Openvswitch firewall driver don't reinitialize after ovs-vswitchd restart
Reviewed: https://review.openstack.org/620886 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=2ba9e95156d86bc67ecd8440d7343028e89cae3a Submitter: Zuul Branch:master commit 2ba9e95156d86bc67ecd8440d7343028e89cae3a Author: Slawek Kaplonski Date: Thu Nov 29 12:18:17 2018 +0100 Reinitialize ovs firewall after ovs-vswitchd restart When ovs-vswitchd process is restarted on host neutron-ovs-agent can properly handle that and recover openflows and bridges config. But when ovs firewall driver is used, it wasn't reinitialized so there were missing some OF rules in br-int and connectivity to/from instances was broken. This patch adds reinitialization of firewall in such case so all OF rules are properly reconfigured and connectivity is restored. Change-Id: I8d525bbe48216fef4da890582b8e198933a27833 Closes-Bug: 1805808 ** Changed in: neutron Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1805808 Title: Openvswitch firewall driver don't reinitialize after ovs-vswitchd restart Status in neutron: Fix Released Bug description: When ovs-vswitchd is restarted, neutron-ovs-agent can handle that but openvswitch firewall driver will not reinitialize br-int properly and because of that connectivity from instance will be broken. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1805808/+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 1806621] [NEW] Keystone Federation only create one project
Public bug reported: Hi every one, I'm deploying keystone to keystone federation with two regions cloud. Everything is ok. But when I use dashboard I have an issue. Assume on Keystone IDP I have three projects and an user (can access to three project). When I switch to Keystone SP, Horizon is create a scope token from list project (first project from list) and send assertion to Keystone SP. But I would like to create three projects. I mean create current project when switch to other keystone SP. Thank you. ** 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/1806621 Title: Keystone Federation only create one project Status in OpenStack Dashboard (Horizon): New Bug description: Hi every one, I'm deploying keystone to keystone federation with two regions cloud. Everything is ok. But when I use dashboard I have an issue. Assume on Keystone IDP I have three projects and an user (can access to three project). When I switch to Keystone SP, Horizon is create a scope token from list project (first project from list) and send assertion to Keystone SP. But I would like to create three projects. I mean create current project when switch to other keystone SP. Thank you. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1806621/+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
