[Yahoo-eng-team] [Bug 1837847] [NEW] [RFE] neutron-vpnaas OpenVPN driver
Public bug reported: I started implementing an OpenVPN driver that allows remote client logins to Neutron networks, similar to the patches started and then abandoned by Rajesh Mohan [1]. In my specific use case this allows remote clients to join Neutron networks in a way that allows broadcast/multicast communication with the instances. There is a PoC with code in gerrit [2]. One point of criticism of the previous implementation was the storage of VPN server secrets. I addressed this by storing them in Barbican. There is one questionable detail in the current implementation: IP addresses of remote clients are not assigned by OpenVPN. Instead, during the connection process, a Neutron Port is created, and the IP address is assigned by the Neutron DHCP service. This is ugly, and I didn’t find a good way to clean up those ports when clients disconnect. But, doing it this way, the only neutron-vpnaas object needed is a vpnservice, so it made a first implementation simpler. I expect to have OpenVPN assign the addresses would also require an endpoint group (to configure the address range for the VPN server) and a site connection (which may require IKE and IPsec policies as well). Any feedback is welcome. [1] https://review.opendev.org/#/c/70274/ [2] https://review.opendev.org/#/c/666282 ** Affects: neutron Importance: Undecided Status: New ** Tags: rfe -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1837847 Title: [RFE] neutron-vpnaas OpenVPN driver Status in neutron: New Bug description: I started implementing an OpenVPN driver that allows remote client logins to Neutron networks, similar to the patches started and then abandoned by Rajesh Mohan [1]. In my specific use case this allows remote clients to join Neutron networks in a way that allows broadcast/multicast communication with the instances. There is a PoC with code in gerrit [2]. One point of criticism of the previous implementation was the storage of VPN server secrets. I addressed this by storing them in Barbican. There is one questionable detail in the current implementation: IP addresses of remote clients are not assigned by OpenVPN. Instead, during the connection process, a Neutron Port is created, and the IP address is assigned by the Neutron DHCP service. This is ugly, and I didn’t find a good way to clean up those ports when clients disconnect. But, doing it this way, the only neutron-vpnaas object needed is a vpnservice, so it made a first implementation simpler. I expect to have OpenVPN assign the addresses would also require an endpoint group (to configure the address range for the VPN server) and a site connection (which may require IKE and IPsec policies as well). Any feedback is welcome. [1] https://review.opendev.org/#/c/70274/ [2] https://review.opendev.org/#/c/666282 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1837847/+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 1837252] Re: IFLA_BR_AGEING_TIME of 0 causes flooding across bridges
Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions. ** Information type changed from Public to Public Security ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- 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/1837252 Title: IFLA_BR_AGEING_TIME of 0 causes flooding across bridges Status in neutron: Invalid Status in OpenStack Compute (nova): Invalid Status in os-vif: Confirmed Status in OpenStack Security Advisory: Incomplete Bug description: Release: OpenStack Stein Driver: LinuxBridge Using Stein w/ the LinuxBridge mech driver/agent, we have found that traffic is being flooded across bridges. Using tcpdump inside an instance, you can see unicast traffic for other instances. We have confirmed the macs table shows the aging timer set to 0 for permanent entries, and the bridge is NOT learning new MACs: root@lab-compute01:~# brctl showmacs brqd0084ac0-f7 port no mac addris local? ageing timer 5 24:be:05:a3:1f:e1 yes0.00 5 24:be:05:a3:1f:e1 yes0.00 1 fe:16:3e:02:62:18 yes0.00 1 fe:16:3e:02:62:18 yes0.00 7 fe:16:3e:07:65:47 yes0.00 7 fe:16:3e:07:65:47 yes0.00 4 fe:16:3e:1d:d6:33 yes0.00 4 fe:16:3e:1d:d6:33 yes0.00 9 fe:16:3e:2b:2f:f0 yes0.00 9 fe:16:3e:2b:2f:f0 yes0.00 8 fe:16:3e:3c:42:64 yes0.00 8 fe:16:3e:3c:42:64 yes0.00 10 fe:16:3e:5c:a6:6c yes0.00 10 fe:16:3e:5c:a6:6c yes0.00 2 fe:16:3e:86:9c:dd yes0.00 2 fe:16:3e:86:9c:dd yes0.00 6 fe:16:3e:91:9b:45 yes0.00 6 fe:16:3e:91:9b:45 yes0.00 11 fe:16:3e:b3:30:00 yes0.00 11 fe:16:3e:b3:30:00 yes0.00 3 fe:16:3e:dc:c3:3e yes0.00 3 fe:16:3e:dc:c3:3e yes0.00 root@lab-compute01:~# bridge fdb show | grep brqd0084ac0-f7 01:00:5e:00:00:01 dev brqd0084ac0-f7 self permanent fe:16:3e:02:62:18 dev tap74af38f9-2e master brqd0084ac0-f7 permanent fe:16:3e:02:62:18 dev tap74af38f9-2e vlan 1 master brqd0084ac0-f7 permanent fe:16:3e:86:9c:dd dev tapb00b3c18-b3 master brqd0084ac0-f7 permanent fe:16:3e:86:9c:dd dev tapb00b3c18-b3 vlan 1 master brqd0084ac0-f7 permanent fe:16:3e:dc:c3:3e dev tap7284d235-2b master brqd0084ac0-f7 permanent fe:16:3e:dc:c3:3e dev tap7284d235-2b vlan 1 master brqd0084ac0-f7 permanent fe:16:3e:1d:d6:33 dev tapbeb9441a-99 vlan 1 master brqd0084ac0-f7 permanent fe:16:3e:1d:d6:33 dev tapbeb9441a-99 master brqd0084ac0-f7 permanent 24:be:05:a3:1f:e1 dev eno1.102 vlan 1 master brqd0084ac0-f7 permanent 24:be:05:a3:1f:e1 dev eno1.102 master brqd0084ac0-f7 permanent fe:16:3e:91:9b:45 dev tapc8ad2cec-90 master brqd0084ac0-f7 permanent fe:16:3e:91:9b:45 dev tapc8ad2cec-90 vlan 1 master brqd0084ac0-f7 permanent fe:16:3e:07:65:47 dev tap86e2c412-24 master brqd0084ac0-f7 permanent fe:16:3e:07:65:47 dev tap86e2c412-24 vlan 1 master brqd0084ac0-f7 permanent fe:16:3e:3c:42:64 dev tap37bcb70e-9e master brqd0084ac0-f7 permanent fe:16:3e:3c:42:64 dev tap37bcb70e-9e vlan 1 master brqd0084ac0-f7 permanent fe:16:3e:2b:2f:f0 dev tap40f6be7c-2d vlan 1 master brqd0084ac0-f7 permanent fe:16:3e:2b:2f:f0 dev tap40f6be7c-2d master brqd0084ac0-f7 permanent fe:16:3e:b3:30:00 dev tap6548bacb-c0 vlan 1 master brqd0084ac0-f7 permanent fe:16:3e:b3:30:00 dev tap6548bacb-c0 master brqd0084ac0-f7 permanent fe:16:3e:5c:a6:6c dev tap61107236-1e vlan 1 master brqd0084ac0-f7 permanent fe:16:3e:5c:a6:6c dev tap61107236-1e master brqd0084ac0-f7 permanent The ageing time for the bridge is set to 0: root@lab-compute01:~# brctl showstp brqd0084ac0-f7 brqd0084ac0-f7 bridge id8000.24be05a31fe1 designated root 8000.24be05a31fe1 root port 0path cost 0 max age20.00 bridge max age20.00 hello time 2.00 bridge hello time 2.00 forward delay 0.00 bridge forward delay 0.00 ageing time 0.00 hello timer 0.00 tcn timer 0.00 to
[Yahoo-eng-team] [Bug 1714987] Re: description in _create_backup.html only assumes object storage service
@Nobuto Murata The current description in '_create_backup.html' looks
good to me. So mark it as invalid.
** Changed in: horizon
Status: New => Invalid
--
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/1714987
Title:
description in _create_backup.html only assumes object storage service
Status in OpenStack Dashboard (Horizon):
Invalid
Bug description:
Actually cinder-backup driver can be something other than object
storage, such as Ceph, NFS. So mentioning "object storage service must
be enabled" is confusing to end users. The description below could
have some space for improvement.
[./openstack_dashboard/dashboards/project/backups/templates/backups/_create_backup.html]
{% block modal-body-right %}
{% trans "Volume Backup:" %} {% trans "Volume Backups
are stored using the Object Storage service. You must have this service
activated in order to create a backup." %}
{% trans "If no container name is provided, a default container named
volumebackups will be provisioned for you. Backups will be the same size as the
volume they originate from." %}
{% endblock %}
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1714987/+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 1732067] Re: openvswitch firewall flows cause flooding on integration bridge
Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions. (The duplicate bug 1813439 was previously being tracked as a potential vulnerability report.) ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete ** Information type changed from Public to Public Security -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1732067 Title: openvswitch firewall flows cause flooding on integration bridge Status in neutron: In Progress Status in OpenStack Security Advisory: Incomplete Bug description: Environment: OpenStack Newton Driver: ML2 w/ OVS Firewall: openvswitch In this environment, we have observed OVS flooding network traffic across all ports in a given VLAN on the integration bridge due to the lack of a FDB entry for the destination MAC address. Across the large fleet of 240+ nodes, this is causing a considerable amount of noise on any given node. In this test, we have 3 machines: Client: fa:16:3e:e8:59:00 (10.10.60.2) Server: fa:16:3e:80:cb:0a (10.10.60.9) Bystander: fa:16:3e:a0:ee:02 (10.10.60.10) The server is running a web server using netcat: while true ; do sudo nc -l -p 80 < index.html ; done Client requests page using curl: ip netns exec qdhcp-b07e6cb3-0943-45a2-b5ff-efb7e99e4d3d curl http://10.10.60.9/ We should expect to see the communication limited to the client and server. However, the captures below reflect the server->client responses being broadcast out all tap interfaces connected to br-int in the same local vlan: root@osa-newton-ovs-compute01:~# tcpdump -i tap5f03424d-1c -ne port 80 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tap5f03424d-1c, link-type EN10MB (Ethernet), capture size 262144 bytes 02:20:30.190675 fa:16:3e:e8:59:00 > fa:16:3e:80:cb:0a, ethertype IPv4 (0x0800), length 74: 10.10.60.2.54796 > 10.10.60.9.80: Flags [S], seq 213484442, win 29200, options [mss 1460,sackOK,TS val 140883559 ecr 0,nop,wscale 7], length 0 02:20:30.191926 fa:16:3e:80:cb:0a > fa:16:3e:e8:59:00, ethertype IPv4 (0x0800), length 74: 10.10.60.9.80 > 10.10.60.2.54796: Flags [S.], seq 90006557, ack 213484443, win 14480, options [mss 1460,sackOK,TS val 95716 ecr 140883559,nop,wscale 4], length 0 02:20:30.192837 fa:16:3e:e8:59:00 > fa:16:3e:80:cb:0a, ethertype IPv4 (0x0800), length 66: 10.10.60.2.54796 > 10.10.60.9.80: Flags [.], ack 1, win 229, options [nop,nop,TS val 140883560 ecr 95716], length 0 02:20:30.192986 fa:16:3e:e8:59:00 > fa:16:3e:80:cb:0a, ethertype IPv4 (0x0800), length 140: 10.10.60.2.54796 > 10.10.60.9.80: Flags [P.], seq 1:75, ack 1, win 229, options [nop,nop,TS val 140883560 ecr 95716], length 74: HTTP: GET / HTTP/1.1 02:20:30.195806 fa:16:3e:80:cb:0a > fa:16:3e:e8:59:00, ethertype IPv4 (0x0800), length 79: 10.10.60.9.80 > 10.10.60.2.54796: Flags [P.], seq 1:14, ack 1, win 905, options [nop,nop,TS val 95717 ecr 140883560], length 13: HTTP 02:20:30.196207 fa:16:3e:e8:59:00 > fa:16:3e:80:cb:0a, ethertype IPv4 (0x0800), length 66: 10.10.60.2.54796 > 10.10.60.9.80: Flags [.], ack 14, win 229, options [nop,nop,TS val 140883561 ecr 95717], length 0 02:20:30.197481 fa:16:3e:80:cb:0a > fa:16:3e:e8:59:00, ethertype IPv4 (0x0800), length 66: 10.10.60.9.80 > 10.10.60.2.54796: Flags [.], ack 75, win 905, options [nop,nop,TS val 95717 ecr 140883560], length 0 ^^^ On the server tap we see the bi-directional traffic root@osa-newton-ovs-compute01:/home/ubuntu# tcpdump -i tapb8051da9-60 -ne port 80 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tapb8051da9-60, link-type EN10MB (Ethernet), capture size 262144 bytes 02:20:30.192165 fa:16:3e:80:cb:0a > fa:16:3e:e8:59:00, ethertype IPv4 (0x0800), length 74: 10.10.60.9.80 > 10.10.60.2.54796: Flags [S.], seq 90006557, ack 213484443, win 14480, options [mss 1460,sackOK,TS val 95716 ecr 140883559,nop,wscale 4], length 0 02:20:30.195827 fa:16:3e:80:cb:0a > fa:16:3e:e8:59:00, ethertype IPv4 (0x0800), length 79: 10.10.60.9.80 > 10.10.60.2.54796: Flags [P.], seq 1:14, ack 1, win 905, options [nop,nop,TS val 95717 ecr 140883560], length 13: HTTP 02:20:30.197500 fa:16:3e:80:cb:0a > fa:16:3e:e8:59:00, ethertype IPv4 (0x0800), length 66: 10.10.60.9.80 > 10.10.60.2.54796: Flags [.], ack 75, win 905, options [nop,nop,TS val 95717 ecr 140883560], length 0 ^^^ On the bystander tap we see the flooded traffic The FDB tables reflect the lack of CAM entry for the client on br-int bridge. I would expect to see the MAC address on the patch uplink: root@osa-newton-ovs-compute01:/home/ubuntu# ovs-a
[Yahoo-eng-team] [Bug 1837756] Re: ImagePropertiesFilter: hypervisor_type matchmaking not compliant with documentation
Reviewed: https://review.opendev.org/672559 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=743dc083bb5628554d9abfa82665738233ed47e9 Submitter: Zuul Branch:master commit 743dc083bb5628554d9abfa82665738233ed47e9 Author: Matt Riedemann Date: Wed Jul 24 16:22:52 2019 + Revert "[libvirt] Filter hypervisor_type by virt_type" This reverts commit eaa766ee2093c24fd61c61e52f46bdd9ff9e93d2. The change regressed the behavior of the ImagePropertiesFilter because existing images with hypervisor_type=QEMU, which would match what is reported for hypervisor_type in the API for both qemu/kvm virt_type nodes, will now get filtered out for hosts where the configured virt_type is kvm. Note that both the ImagePropertiesFilter docs [1] and hypervisor_type image property docs [2] mention that for both qemu and kvm nodes the value to use is qemu since that is the actual hypervisor. Presumably the change was made for a deployment with some hosts configured with virt_type=qemu and other hosts configured with virt_type=kvm and there were separate images with hypervisor_type=qemu and hypervisor_type=kvm to match those hosts for scheduler filter, but as noted this was a regression in behavior for something that could have been achieved using host aggregates and the AggregateImagePropertiesIsolation filter. We could even use traits and a placement request pre-filter these days for a more modern approach. Also, since the API continues to report hypervisor_type=QEMU it's doubly confusing for operators to have to configure their images to use hypervisor_type=kvm (despite the docs). And finally, any existing instances which have hypervisor_type=qemu embedded in their RequestSpec can no longer be migrated to kvm hosts without manually fixing the entries in the request_specs table in the API DB. Note that this is not a clean revert because of change I5d95bd50279a6bf903a5793ad5f3ae9d06f085f4 made in Stein. [1] https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#imagepropertiesfilter [2] https://docs.openstack.org/glance/latest/admin/useful-image-properties.html Change-Id: I7d761dc269f8c12c4a76ba14201ccdd82a04d01d Closes-Bug: #1837756 ** 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/1837756 Title: ImagePropertiesFilter: hypervisor_type matchmaking not compliant with documentation Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) rocky series: Triaged Status in OpenStack Compute (nova) stein series: In Progress Bug description: All compute nodes of my Cloud are configured using libvirt]/virt_type=kvm Please note that this is not exposed in the 'openstack hypervisor list --long' output which reports QEMU as 'Hypervisor Type'. I have some images with the following property: hypervisor_type='qemu' No problems scheduling instances using these images in Ocata. After having updated to Rocky, the ImagePropertiesFilter filters out all the compute nodes, because they offer 'kvm' while 'qemu' is requested. This is not compliant with documentation. Both Nova (https://docs.openstack.org/nova/rocky/admin/configuration/schedulers.html) and Glance (https://docs.openstack.org/glance/latest/admin/useful-image-properties.html) documentation say that qemu is supposed to be used for both QEMU and KVM hypervisor types. The issue is discussed in: http://lists.openstack.org/pipermail/openstack-discuss/2019-July/thread.html#7842 where it is reported that the new behavior is likely because this change: https://review.opendev.org/531347 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1837756/+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 1820125] Re: Libvirt driver ungracefully explodes if unsupported arch is found
** Also affects: nova/rocky 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/1820125 Title: Libvirt driver ungracefully explodes if unsupported arch is found Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) rocky series: New Bug description: If a new libvirt exposes an arch name that nova does not support, we fail to gracefully skip it during the instance capability gathering: 2019-03-14 19:11:31.709 6 ERROR nova.compute.manager [req-4e626631-fefc-4c58-a1cd-5207c9384a1b - - - - -] Error updating resources for node primary.: InvalidArchitectureName: Architecture name 'armv6l' is not recognised 2019-03-14 19:11:31.709 6 ERROR nova.compute.manager Traceback (most recent call last): 2019-03-14 19:11:31.709 6 ERROR nova.compute.manager File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/compute/manager.py", line 7956, in _update_available_resource_for_node 2019-03-14 19:11:31.709 6 ERROR nova.compute.manager startup=startup) 2019-03-14 19:11:31.709 6 ERROR nova.compute.manager File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/compute/resource_tracker.py", line 727, in update_available_resource 2019-03-14 19:11:31.709 6 ERROR nova.compute.manager resources = self.driver.get_available_resource(nodename) 2019-03-14 19:11:31.709 6 ERROR nova.compute.manager File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 7070, in get_available_resource 2019-03-14 19:11:31.709 6 ERROR nova.compute.manager data["supported_instances"] = self._get_instance_capabilities() 2019-03-14 19:11:31.709 6 ERROR nova.compute.manager File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/virt/libvirt/driver.py", line 5943, in _get_instance_capabilities 2019-03-14 19:11:31.709 6 ERROR nova.compute.manager fields.Architecture.canonicalize(g.arch), 2019-03-14 19:11:31.709 6 ERROR nova.compute.manager File "/var/lib/kolla/venv/local/lib/python2.7/site-packages/nova/objects/fields.py", line 200, in canonicalize 2019-03-14 19:11:31.709 6 ERROR nova.compute.manager raise exception.InvalidArchitectureName(arch=name) 2019-03-14 19:11:31.709 6 ERROR nova.compute.manager InvalidArchitectureName: Architecture name 'armv6l' is not recognised 2019-03-14 19:11:31.709 6 ERROR nova.compute.manager To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1820125/+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 1836140] Re: 500 response while try to delete image is in uploading state
Reviewed: https://review.opendev.org/670236 Committed: https://git.openstack.org/cgit/openstack/glance/commit/?id=7f74a92338894d01feebf706663b1b5a10d99ece Submitter: Zuul Branch:master commit 7f74a92338894d01feebf706663b1b5a10d99ece Author: Abhishek Kekane Date: Thu Jul 11 06:06:04 2019 + Image deletion returns 500 if 'file' store is not enabled When image import fails during image is uploading from staging area, image remains in uploading state and data remains in staging area. In this scenario if 'file' store is not enabled then while deleting the image glance-api returns 500 status code with error 'file' scheme is Unknwon. Used os module to unlink the file present in staging area explicitly to delete the data from staging area. Change-Id: I57dcd6b18b0039e824e8adbe77de59079360a34f Closes-Bug: #1836140 ** Changed in: glance Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1836140 Title: 500 response while try to delete image is in uploading state Status in Glance: Fix Released Bug description: When image import fails during image is in uploaded from staging area image remains in uploading state and data remains in staging area. In this scenario if file store is not enabled then while deleting the image glance-api returns 500 status code with error 'file' scheme is Unknwon. Traceback (most recent call last): File "/usr/lib/python2.7/site-packages/glance_store/backend.py", line 409, in delete_from_backend loc = location.get_location_from_uri(uri, conf=CONF) File "/usr/lib/python2.7/site-packages/glance_store/location.py", line 75, in get_location_from_uri raise exceptions.UnknownScheme(scheme=pieces.scheme) UnknownScheme: Unknown scheme 'file' found in URI Note: Solution is similar as proposed in this patch: https://review.opendev.org/#/c/618468/7 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1836140/+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 1816399] Re: The periodic task to clean up expired console_auth tokens is invalid
Reviewed: https://review.opendev.org/637716
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=57112a7174945cdcd9f395d20fd6a242cecf5072
Submitter: Zuul
Branch:master
commit 57112a7174945cdcd9f395d20fd6a242cecf5072
Author: Takashi NATSUME
Date: Fri May 3 22:19:17 2019 +0900
Fix cleaning up console tokens
The periodic task to clean up expired console_auth tokens
does not work properly because there are cases that 'host'
in the 'console_auth_tokens' table is different from
hosts where nova-compute processes run.
So make the periodic task to clear all expired console tokens
regardless of hosts where nova-compute processes run.
Change-Id: I61cee4245e612b4bef1ffaacc634a8302cf836e9
Closes-Bug: #1816399
** 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/1816399
Title:
The periodic task to clean up expired console_auth tokens is invalid
Status in OpenStack Compute (nova):
Fix Released
Bug description:
Description
===
In compute node, the periodic task to clean up expired console_auth tokens is
invalid, can't remove expired console auth tokens for this host.
Steps to reproduce
==
1.In controller node, config nova-novncproxy using database to store novnc
auth tokens.
enable_consoleauth=false
2.In compute node, config vnc server address and token_ttl.
server_proxyclient_address=10.43.203.225
token_ttl=60
3.Restart nova-compute and nova-novncproxy.
4.Using nova command to get novncproxy_base_url and token.
Expected result
===
The periodic task can remove expired console auth tokens in database.
Actual result
=
This periodic task is invalid.
Environment
===
1. Exact version of OpenStack you are running. See the following
master
2. Which hypervisor did you use?
Libvirt + KVM
3. Which networking type did you use?
Neutron with OpenVSwitch
Logs & Configs
==
1. In console_auth_tokens table, host's value is
CONF.vnc.server_proxyclient_address.
def get_vnc_console(self, context, instance):
def get_vnc_port_for_instance(instance_name):
guest = self._host.get_guest(instance)
xml = guest.get_xml_desc()
xml_dom = etree.fromstring(xml)
graphic = xml_dom.find("./devices/graphics[@type='vnc']")
if graphic is not None:
return graphic.get('port')
# NOTE(rmk): We had VNC consoles enabled but the instance in
# question is not actually listening for connections.
raise exception.ConsoleTypeUnavailable(console_type='vnc')
port = get_vnc_port_for_instance(instance.name)
host = CONF.vnc.server_proxyclient_address
return ctype.ConsoleVNC(host=host, port=port)
2. In periodic task, the host's value is hostname.
@periodic_task.periodic_task(spacing=CONF.instance_delete_interval)
def _cleanup_expired_console_auth_tokens(self, context):
"""Remove expired console auth tokens for this host.
Console authorization tokens and their connection data are stored
in the database when a user asks for a console connection to an
instance. After a time they expire. We periodically remove any expired
tokens from the database.
"""
# If the database backend isn't in use, don't bother looking for
# expired tokens. The database backend is not supported for cells v1.
if not CONF.cells.enable:
objects.ConsoleAuthToken.\
clean_expired_console_auths_for_host(context, self.host)
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1816399/+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 1835063] Re: Compute API in nova - server actions project/user id descriptions are wrong
Reviewed: https://review.opendev.org/670027 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=6b3aa31458ba1f40bf68c54f5a1e840e8e504893 Submitter: Zuul Branch:master commit 6b3aa31458ba1f40bf68c54f5a1e840e8e504893 Author: qiufossen Date: Wed Jul 10 05:31:54 2019 -0400 Correct project/user id descriptions for os-instance-actions The 'user_id' and 'project_id' parameter descriptions for server actions imply that they are the value of the user/project that owns the server, but that is incorrect - they are the project/user id of whoever made the request/initiated the action. The existing project_id_instance_action parameter variable, which is only used by the os-cloudpipe reference, is renamed to avoid confusion with instance actions. Co-Authored-By: Brin Zhang Closes-Bug: #1835063 Change-Id: I1c05d59ebf1fda6319df5ee305c2b8a6a9562242 ** 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/1835063 Title: Compute API in nova - server actions project/user id descriptions are wrong Status in OpenStack Compute (nova): Fix Released Bug description: - [x] This doc is inaccurate in this way: https://developer.openstack.org/api-ref/compute/#servers-actions- servers-os-instance-actions The user_id and project_id parameter descriptions for server actions imply that they are the value of the user/project that owns the server, but that is incorrect - they are the project/user id of whoever made the request / initiated the action: https://github.com/openstack/nova/blob/5c6c1f8fce7cd976dedc0a1ad28836ed87af2780/nova/objects/instance_action.py#L56-L57 For example, the server could be owned by project Foo and user A but an admin live migrates the server and the admin's project is Bar and the user is B, so the server actions should reflect project B and user B. --- Release: 19.1.0.dev764 on 2019-03-05 15:57:14 SHA: 5c6c1f8fce7cd976dedc0a1ad28836ed87af2780 Source: https://opendev.org/openstack/nova/src/api-ref/source/index.rst URL: https://developer.openstack.org/api-ref/compute/ To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1835063/+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 1837908] [NEW] Dashboard Hangs while trying to create and associate floating IP to instance at the same time
Public bug reported:
OS: Ubuntu 18.04
Horizon Installation: Manual via apt
Package repo: ubuntu cloud archive
Openstack release: Stein
Architecture: 3 node, controller, network, compute.
Services
controller: keystone, nova, glance, neutron-server/ml2-plugin, designate,
horizon, heat
Network: neutron-l3-agent neutron-metadata-agent neutron-dhcp-agent
neutron-linuxbridge-agent Compute: nova-compute, neutron-linuxbridge-agent
All services behind HA proxy with TLS.
Description:
I have tested this exact bug twice, and have the exact same issue on both
installations, one production, one test.
The UI does not allow the creation and association of a floating IP at
the same time.
However succeds using the CLI
create a floating IP manually using CLI and attaching to instance in one
command succeed
openstack floating ip create --dns-domain=stack.lon.example.com. --dns-
name=testy101 --fixed-ip-address=192.1.2.51 --port 59934e2e-6c6f-4c8f-
b0cf-933bcf3497c0 91217bab-6250-4ff5-ae61-0accd79a5d41
ability to ping host afterwards verified.
when using the UI the following was carried out.
Reproducible steps
log into UI and select ( associate floating IP on instance ), then select (
plus+ ) button, then select ( Allocate IP ) this is the part where a new
floating IP is created and attached to the instance I had this working in
ocata, but now it goes into a continuous loop with the working twirler never
stopping.
Refreshing the page, the floating IP is confirmed as being created but
never actually attached.
no errors in logs
tail -f -n1000 /var/log/apache2/horizon/error.log
[Thu Jul 25 13:47:44.477285 2019] [wsgi:error] [pid 11933:tid 140288635377408]
[remote 172.30.0.2:50814] DEBUG:stevedore.extension:found extension
EntryPoint.parse('http = oslo_policy._external:HttpCheck')
[Thu Jul 25 13:47:44.477908 2019] [wsgi:error] [pid 11933:tid 140288635377408]
[remote 172.30.0.2:50814] DEBUG:stevedore.extension:found extension
EntryPoint.parse('https = oslo_policy._external:HttpsCheck')
[Thu Jul 25 13:47:58.151732 2019] [wsgi:error] [pid 11932:tid 140288710911744]
[remote 172.30.0.2:51324] DEBUG:stevedore.extension:found extension
EntryPoint.parse('http = oslo_policy._external:HttpCheck')
[Thu Jul 25 13:47:58.152439 2019] [wsgi:error] [pid 11932:tid 140288710911744]
[remote 172.30.0.2:51324] DEBUG:stevedore.extension:found extension
EntryPoint.parse('https = oslo_policy._external:HttpsCheck')
tail -f -n1000 /var/log/apache2/horizon/access.log
172.30.0.2 - - [25/Jul/2019:14:47:22 +0100] "GET /horizon/project/instances/
HTTP/1.1" 200 8564 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0)
Gecko/20100101 Firefox/68.0"
172.30.0.2 - - [25/Jul/2019:14:47:45 +0100] "GET
/horizon/static/dashboard/css/361cca58bb99.css HTTP/1.1" 200 4729
"https://openstack.lon.example.com/horizon/project/instances/"; "Mozilla/5.0
(Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0"
172.30.0.2 - - [25/Jul/2019:14:47:45 +0100] "GET
/horizon/i18n/js/horizon+openstack_dashboard/ HTTP/1.1" 200 3612
"https://openstack.lon.example.com/horizon/project/instances/"; "Mozilla/5.0
(Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0"
172.30.0.2 - - [25/Jul/2019:14:47:45 +0100] "GET
/horizon/static/dashboard/js/b2bb2963e6de.js HTTP/1.1" 200 37926
"https://openstack.lon.example.com/horizon/project/instances/"; "Mozilla/5.0
(Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0"
172.30.0.2 - - [25/Jul/2019:14:47:45 +0100] "GET
/horizon/static/dashboard/css/7b50ccce00d0.css HTTP/1.1" 200 60951
"https://openstack.lon.example.com/horizon/project/instances/"; "Mozilla/5.0
(Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0"
172.30.0.2 - - [25/Jul/2019:14:47:45 +0100] "GET
/horizon/static/dashboard/js/787a5a315d99.js HTTP/1.1" 200 122901
"https://openstack.lon.example.com/horizon/project/instances/"; "Mozilla/5.0
(Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0"
172.30.0.2 - - [25/Jul/2019:14:47:45 +0100] "GET
/horizon/static/dashboard/js/c927fd827a6d.js HTTP/1.1" 200 429891
"https://openstack.lon.example.com/horizon/project/instances/"; "Mozilla/5.0
(Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0"
172.30.0.2 - - [25/Jul/2019:14:47:45 +0100] "GET
/horizon/static/dashboard/img/logo.svg HTTP/1.1" 200 5972
"https://openstack.lon.example.com/horizon/project/instances/"; "Mozilla/5.0
(Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101 Firefox/68.0"
172.30.0.2 - - [25/Jul/2019:14:47:45 +0100] "GET
/horizon/static/horizon/lib/font_awesome/fonts/fontawesome-webfont.woff2?v=4.7.0
HTTP/1.1" 200 77387
"https://openstack.lon.example.com/horizon/static/dashboard/css/7b50ccce00d0.css";
"Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:68.0) Gecko/20100101
Firefox/68.0"
172.30.0.2 - - [25/Jul/2019:14:47:45 +0100] "GET
/horizon/static/dashboard/img/apple-touch-icon.png HTTP/1.1" 200 1171 "-"
"Mozilla/5.0 (Windows NT 10.0; W
[Yahoo-eng-team] [Bug 1837916] [NEW] Trunk subports sometimes not becoming ACTIVE and trunk:subport
Public bug reported: We're occasionally hitting a bug preventing Kuryr-Kubernetes from attaching ports to a trunk. The result of the operation on the API is 200, but ports never gets into ACTIVE and switches device_owner to trunk:subport. In our case Kuryr is creating those ports in bulks of 3, then tagging them one-by-one, then attaching to a trunk using random segmentation ID's. Removing the subport from trunk and attaching it again resolves the issue. In the logs of openvswitch-agent we see: Remote error: StaleDataError UPDATE statement on table 'standardattributes' expected to update 1 row(s); 0 were matched. Version-Release number of selected component (if applicable): Rocky How reproducible: Occasionally. :( Steps to Reproduce (I'm putting what Kuryr does): 1. Create 3 ports in bulk. 2. Tag them. 3. Add them to a trunk. Actual results: Sometimes port stays DOWN and still has what Kuryr put as device_owner instead of trunk:subport. Expected results: Port becomes ACTIVE and has trunk:subport as device_owner. ** 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/1837916 Title: Trunk subports sometimes not becoming ACTIVE and trunk:subport Status in neutron: New Bug description: We're occasionally hitting a bug preventing Kuryr-Kubernetes from attaching ports to a trunk. The result of the operation on the API is 200, but ports never gets into ACTIVE and switches device_owner to trunk:subport. In our case Kuryr is creating those ports in bulks of 3, then tagging them one-by-one, then attaching to a trunk using random segmentation ID's. Removing the subport from trunk and attaching it again resolves the issue. In the logs of openvswitch-agent we see: Remote error: StaleDataError UPDATE statement on table 'standardattributes' expected to update 1 row(s); 0 were matched. Version-Release number of selected component (if applicable): Rocky How reproducible: Occasionally. :( Steps to Reproduce (I'm putting what Kuryr does): 1. Create 3 ports in bulk. 2. Tag them. 3. Add them to a trunk. Actual results: Sometimes port stays DOWN and still has what Kuryr put as device_owner instead of trunk:subport. Expected results: Port becomes ACTIVE and has trunk:subport as device_owner. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1837916/+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 1652619] Re: Creation of ICMPV6 rule through horizon is treating as invalid packet
Reviewed: https://review.opendev.org/473481 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=d5dcf1be93d9bb26bda7b375e41f03dd297888bb Submitter: Zuul Branch:master commit d5dcf1be93d9bb26bda7b375e41f03dd297888bb Author: Radomir Dopieralski Date: Mon Jun 12 16:23:54 2017 +0200 Allow creating ICMPV6 rules Right now, even if we specify a ::/0 (or other IPv6) CIDR in an ICMP rule, Horizon sets 'icmp' as the ip_protocol of that rule but neutron expects 'ipv6-icmp' which is the right ip_protocol for ICMPv6. This results in that rule never matching anything. This change makes Horizon set the ip_protocol to ipv6-icmp when the CIDR is an IPv6 one, and icmp when it's IPv4. Co-Authored-By: Akihiro Motoki Change-Id: I1f68e1e5a3e073e38ac258de5ed9c43f8acb04e9 Closes-Bug: #1652619 ** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1652619 Title: Creation of ICMPV6 rule through horizon is treating as invalid packet Status in OpenStack Dashboard (Horizon): Fix Released Status in neutron: Fix Committed Bug description: Go to the dashboard and select the access and security for admin role 1.Create a Security Group say SG1 2.Select the manage rule for security Group SG1 3.Click on ALL icmp and select the CIDR AS ::/0 for ingress and egress rule 4.Associate to the VMs 5.try to ping its treating as invalid because while creating the rule for ethertype=ipv6 as icmp Please refer the snapshot for your reference Note : Same configuration through CLI works fine. example : neutron security-group-rule-create --protocol icmpv6 --direction egress --ethertype IPv6 SG1 neutron security-group-rule-create --protocol icmpv6 --direction ingress --ethertype IPv6 SG1 After executing above command and its showing as icmpv6 in dashboard and its works fine. This issue is seen in stable/mitaka branch. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1652619/+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 1837921] [NEW] enforce filesystem store datadir uniqueness
Public bug reported: The multistore admin docs say that using the same filesystem_store_datadir for different stores is not supported. This is important enough that it should be enforced in the code. ** Affects: glance Importance: Undecided Status: Triaged -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1837921 Title: enforce filesystem store datadir uniqueness Status in Glance: Triaged Bug description: The multistore admin docs say that using the same filesystem_store_datadir for different stores is not supported. This is important enough that it should be enforced in the code. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1837921/+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 1829161] Re: Could not install packages due to an EnvironmentError: HTTPSConnectionPool(host='git.openstack.org', port=443)
Not a nova bug. ** Changed in: nova Status: Fix Committed => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1829161 Title: Could not install packages due to an EnvironmentError: HTTPSConnectionPool(host='git.openstack.org', port=443) Status in OpenStack Compute (nova): Invalid Bug description: The tempest jobs have stared to periodicaly fail with Could not install packages due to an EnvironmentError: HTTPSConnectionPool(host='git.openstack.org', port=443) starting on may 6th http://logstash.openstack.org/#/dashboard/file/logstash.json?query=message:%5C%22Could%20not%20install%20packages%20due%20to%20an%20EnvironmentError:%20HTTPSConnectionPool(host%3D'git.openstack.org',%20port%3D443)%5C%22 based on the logstash results this has been hit ~330 times in the last 7 days this appears to trigger more frequently on the grenade jobs but also effects others. this looks like an infra issue likely related to the redicrts not working in all cases. this is a tracking bug untill the issue is resolved. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1829161/+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 1837927] [NEW] Missing mandatory path: http://169.254.169.254/openstack/2018-08-27/meta_data.json
Public bug reported: I'm running OpenStack Stein. Cloud init from the bionic-cloud images it's not working correctly. I'm launching instances with ubuntu-bionic 18.04 cloud and the following message appears when reaching the openstack metadata server: "[ 86.559374] cloud-init[843]: 2019-07-25 15:25:21,978 - util.py[WARNING]: Missing mandatory path: http://169.254.169.254/openstack/2018-08-27/meta_data.json"; Now, I can (without doing anything special) use ubuntu 14.04 cloud, 16.04 cloud, Centos7-cloud (all with different versions of cloud-init) and everything works, but with 'Cloud-init v. 19.1-1-gbaa47854-0ubuntu1~16.04.1' on the bionic cloud images it does not. I have tried to use EC2 datasources, OpenStack datasources [1] and it does not work. It connects to the metadata server and gets the meta_data.json file but doesn't do much more. therefore I'm unable to provision ssh keys, etc, with bionic-cloud. Attached is the full log for one bionic-cloud-1804 instance. 1. https://cloudinit.readthedocs.io/en/latest/topics/datasources/openstack.html ** Affects: cloud-init Importance: Undecided Status: New ** Attachment added: "console output from the instance" https://bugs.launchpad.net/bugs/1837927/+attachment/5279238/+files/console.txt -- 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/1837927 Title: Missing mandatory path: http://169.254.169.254/openstack/2018-08-27/meta_data.json Status in cloud-init: New Bug description: I'm running OpenStack Stein. Cloud init from the bionic-cloud images it's not working correctly. I'm launching instances with ubuntu-bionic 18.04 cloud and the following message appears when reaching the openstack metadata server: "[ 86.559374] cloud-init[843]: 2019-07-25 15:25:21,978 - util.py[WARNING]: Missing mandatory path: http://169.254.169.254/openstack/2018-08-27/meta_data.json"; Now, I can (without doing anything special) use ubuntu 14.04 cloud, 16.04 cloud, Centos7-cloud (all with different versions of cloud-init) and everything works, but with 'Cloud-init v. 19.1-1-gbaa47854-0ubuntu1~16.04.1' on the bionic cloud images it does not. I have tried to use EC2 datasources, OpenStack datasources [1] and it does not work. It connects to the metadata server and gets the meta_data.json file but doesn't do much more. therefore I'm unable to provision ssh keys, etc, with bionic-cloud. Attached is the full log for one bionic-cloud-1804 instance. 1. https://cloudinit.readthedocs.io/en/latest/topics/datasources/openstack.html To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1837927/+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 1750615] Re: The v3 application credential API should account for different scopes
Reviewed: https://review.opendev.org/670926
Committed:
https://git.openstack.org/cgit/openstack/keystone/commit/?id=52da4d0e129048d1b808bdde07364cde698cf475
Submitter: Zuul
Branch:master
commit 52da4d0e129048d1b808bdde07364cde698cf475
Author: Guang Yee
Date: Mon Jul 15 16:57:21 2019 -0700
implement system scope for application credential
Implement system scopes, namely 'admin', 'reader', and 'member' for
the application credential API. Thus, making it consistent with other
system-scoped policy definitions.
For the application credential API, the follow policies will be enforced:
- system admin can fetch, list, lookup, and delete user's application
credentials.
- system member and reader can only fetch, list, and lookup user's
application
credentials. Deleting a user's application credential other their own is
strictly prohibitted.
- domain and project admins can no longer touch user's application
credentials
other their own.
- domain and project readers cannot touch user's application credentials
other their own.
- domain and project members cannot touch user's application credentials
other their own.
- create an application credential can only be done by the owner. No one
else
can create an application credential on behalf of another user.
Test cases are added to guard the above policy changes.
Change-Id: I26ee11571b6d0f700a5fe3a62ad2e8fc7f5316fe
Closes-Bug: 1818725
Closes-Bug: 1750615
** Changed in: keystone
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1750615
Title:
The v3 application credential API should account for different scopes
Status in OpenStack Identity (keystone):
Fix Released
Bug description:
Keystone implemented scope_types for oslo.policy RuleDefault objects
in the Queens release. In order to take full advantage of scope_types,
keystone is going to have to evolve policy enforcement checks in the
user API. This is documented in each patch with FIXMEs [1].
The following acceptance criteria describes how the v3 application
credentials API should behave with tokens from multiple scopes:
GET
/v3/users/{user_id}/application_credentials/{application_credential_id}
- Someone with a system role assignment that passes the check string should
be able to get any application credential in the system (system-scoped)
- Someone with a valid token should be able to call this API for an
application credential associated to their user (project-scoped, user-scoped?)
GET /v3/users/{user_id}/application_credentials
- Someone with a system role assignment that passes the check string should
be able to list all application credentials for any user in the system
(system-scoped)
- Someone with a valid token should be able to call this API and list all
application credentials they've created
POST /v3/users/{user_id}/application_credentials
- Someone with a project role assignment should be able to create
application credentials for the project they have a role assignment on
(project-scoped)
DELETE
/v3/users/{user_id}/application_credentials/{application_credential_id}
- Someone with a system role assignment that passes the check string should
be able to delete any application credential for any user in the system
(system-scoped)
- Someone with a valid token should be able to delete any application
credential they've created (project-scoped, user-scoped?)
[0]
https://github.com/openstack/keystone/blob/68df7bf1f3b3d6ab3f691f59f1ce6de6b0b1deab/keystone/common/policies/application_credential.py#L24-L32
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1750615/+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 1818725] Re: Application credential API doesn't use default roles
Reviewed: https://review.opendev.org/670926 Committed: https://git.openstack.org/cgit/openstack/keystone/commit/?id=52da4d0e129048d1b808bdde07364cde698cf475 Submitter: Zuul Branch:master commit 52da4d0e129048d1b808bdde07364cde698cf475 Author: Guang Yee Date: Mon Jul 15 16:57:21 2019 -0700 implement system scope for application credential Implement system scopes, namely 'admin', 'reader', and 'member' for the application credential API. Thus, making it consistent with other system-scoped policy definitions. For the application credential API, the follow policies will be enforced: - system admin can fetch, list, lookup, and delete user's application credentials. - system member and reader can only fetch, list, and lookup user's application credentials. Deleting a user's application credential other their own is strictly prohibitted. - domain and project admins can no longer touch user's application credentials other their own. - domain and project readers cannot touch user's application credentials other their own. - domain and project members cannot touch user's application credentials other their own. - create an application credential can only be done by the owner. No one else can create an application credential on behalf of another user. Test cases are added to guard the above policy changes. Change-Id: I26ee11571b6d0f700a5fe3a62ad2e8fc7f5316fe Closes-Bug: 1818725 Closes-Bug: 1750615 ** Changed in: keystone Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1818725 Title: Application credential API doesn't use default roles Status in OpenStack Identity (keystone): Fix Released Bug description: In Rocky, keystone implemented support to ensure at least three default roles were available [0]. The application credentials API doesn't incorporate these defaults into its default policies [1], but it should. For example, system administrators should be able to clean up application credentials regardless of users, but system members or readers should only be able to list or get application credentials. Users who are not system users should only be able to manage their application credentials. [0] http://specs.openstack.org/openstack/keystone-specs/specs/keystone/rocky/define-default-roles.html [1] http://git.openstack.org/cgit/openstack/keystone/tree/keystone/common/policies/application_credential.py?id=6e3f1f6e46787ed4542609c935c13cb85e91d7fc To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1818725/+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 1837943] [NEW] class 'keystoneauth1.exceptions.http.Unauthorized'
Public bug reported: Running this command to create and instance: openstack server create --flavor m0.small --image CentOS7 --security- group secgroup01 --nic net-id=$netID --key-name mykey CentOS_7 This returns the following information/error: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. (HTTP 500) (Request-ID: req-3fcd4a52-f56f-4231-8050-6ac6a006bac3) Last few lines of nova-api.log contains the following: 2019-07-25 20:47:17.893 14237 INFO nova.osapi_compute.wsgi.server [req-b94b302b-2310-47bc-a282-6c1f4a90ec82 2c121dcf583c42cb9cb03fb23d14d872 bde6b090ffca4202829409b8025107e6 - default default] 192.168.1.53 "POST /v2.1/bde6b090ffca4202829409b8025107e6/servers HTTP/1.1" status: 500 len: 649 time: 1.6274502 2019-07-25 20:53:22.743 14215 INFO nova.api.openstack.wsgi [req-75acb559-bdeb-4b38-8211-c8c71ad6f7f6 2c121dcf583c42cb9cb03fb23d14d872 bde6b090ffca4202829409b8025107e6 - default default] HTTP exception thrown: Flavor m0.small could not be found. 2019-07-25 20:53:22.744 14215 INFO nova.osapi_compute.wsgi.server [req-75acb559-bdeb-4b38-8211-c8c71ad6f7f6 2c121dcf583c42cb9cb03fb23d14d872 bde6b090ffca4202829409b8025107e6 - default default] 192.168.1.53 "GET /v2.1/bde6b090ffca4202829409b8025107e6/flavors/m0.small HTTP/1.1" status: 404 len: 501 time: 0.0161169 2019-07-25 20:53:22.762 14215 INFO nova.osapi_compute.wsgi.server [req-1414d51c-de2a-4eb8-ac36-e686c0fb0cd3 2c121dcf583c42cb9cb03fb23d14d872 bde6b090ffca4202829409b8025107e6 - default default] 192.168.1.53 "GET /v2.1/bde6b090ffca4202829409b8025107e6/flavors HTTP/1.1" status: 200 len: 2866 time: 0.0146952 2019-07-25 20:53:22.776 14215 INFO nova.osapi_compute.wsgi.server [req-c707606a-f499-4069-82d2-8a200be388e0 2c121dcf583c42cb9cb03fb23d14d872 bde6b090ffca4202829409b8025107e6 - default default] 192.168.1.53 "GET /v2.1/bde6b090ffca4202829409b8025107e6/flavors/9 HTTP/1.1" status: 200 len: 826 time: 0.0109811 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi [req-3fcd4a52-f56f-4231-8050-6ac6a006bac3 2c121dcf583c42cb9cb03fb23d14d872 bde6b090ffca4202829409b8025107e6 - default default] Unexpected exception in API method: Unauthorized: The request you have made requires authentication. (HTTP 401) (Request-ID: req-16b0ed54-4751-4ede-a327-b7bb409f165f) 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi Traceback (most recent call last): 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/api/openstack/wsgi.py", line 671, in wrapped 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi return f(*args, **kwargs) 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 110, in wrapper 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi return func(*args, **kwargs) 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 110, in wrapper 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi return func(*args, **kwargs) 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 110, in wrapper 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi return func(*args, **kwargs) 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 110, in wrapper 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi return func(*args, **kwargs) 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 110, in wrapper 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi return func(*args, **kwargs) 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 110, in wrapper 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi return func(*args, **kwargs) 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 110, in wrapper 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi return func(*args, **kwargs) 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 110, in wrapper 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi return func(*args, **kwargs) 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi File "/usr/lib/python2.7/site-packages/nova/api/validation/__init__.py", line 110, in wrapper 2019-07-25 20:53:24.749 14215 ERROR nova.api.openstack.wsgi return func(*args, **kwargs) 2019-07-25 20:53:24.749 14215 ERROR nova.api
[Yahoo-eng-team] [Bug 1837927] Re: Missing mandatory path: http://169.254.169.254/openstack/2018-08-27/meta_data.json
Hi Orestes, To work around this problem, you'll need to configure ds-identify[0] to change its defaults. You should be able to do this by creating a file named /etc/cloud/ds-identify.cfg and putting this in there: datasource: Ec2 This will configure ds-identify to disable its usual platform-checking behaviour and instead configure cloud-init to just attempt the Ec2 data source. As this is an issue with the OpenStack deployment you're using (rather than a cloud-init bug), I'm going to close this out as Invalid. Please feel free to follow up here, or drop in to #cloud-init on freenode for any further assistance. Thanks! Dan [0] https://git.launchpad.net/cloud-init/tree/tools/ds-identify ** 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/1837927 Title: Missing mandatory path: http://169.254.169.254/openstack/2018-08-27/meta_data.json Status in cloud-init: Invalid Bug description: I'm running OpenStack Stein. Cloud init from the bionic-cloud images it's not working correctly. I'm launching instances with ubuntu-bionic 18.04 cloud and the following message appears when reaching the openstack metadata server: "[ 86.559374] cloud-init[843]: 2019-07-25 15:25:21,978 - util.py[WARNING]: Missing mandatory path: http://169.254.169.254/openstack/2018-08-27/meta_data.json"; Now, I can (without doing anything special) use ubuntu 14.04 cloud, 16.04 cloud, Centos7-cloud (all with different versions of cloud-init) and everything works, but with 'Cloud-init v. 19.1-1-gbaa47854-0ubuntu1~16.04.1' on the bionic cloud images it does not. I have tried to use EC2 datasources, OpenStack datasources [1] and it does not work. It connects to the metadata server and gets the meta_data.json file but doesn't do much more. therefore I'm unable to provision ssh keys, etc, with bionic-cloud. Attached is the full log for one bionic-cloud-1804 instance. 1. https://cloudinit.readthedocs.io/en/latest/topics/datasources/openstack.html To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1837927/+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 1837252] Re: IFLA_BR_AGEING_TIME of 0 causes flooding across bridges
** Also affects: os-vif/stein Importance: Undecided Status: New ** Also affects: os-vif/trunk Importance: High Assignee: sean mooney (sean-k-mooney) Status: In Progress ** Changed in: os-vif/stein Status: New => Confirmed ** Changed in: os-vif/stein Assignee: (unassigned) => sean mooney (sean-k-mooney) ** Changed in: os-vif/stein Importance: Undecided => High -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1837252 Title: IFLA_BR_AGEING_TIME of 0 causes flooding across bridges Status in neutron: Invalid Status in OpenStack Compute (nova): Invalid Status in os-vif: In Progress Status in os-vif stein series: Confirmed Status in os-vif trunk series: In Progress Status in OpenStack Security Advisory: Incomplete Bug description: Release: OpenStack Stein Driver: LinuxBridge Using Stein w/ the LinuxBridge mech driver/agent, we have found that traffic is being flooded across bridges. Using tcpdump inside an instance, you can see unicast traffic for other instances. We have confirmed the macs table shows the aging timer set to 0 for permanent entries, and the bridge is NOT learning new MACs: root@lab-compute01:~# brctl showmacs brqd0084ac0-f7 port no mac addris local? ageing timer 5 24:be:05:a3:1f:e1 yes0.00 5 24:be:05:a3:1f:e1 yes0.00 1 fe:16:3e:02:62:18 yes0.00 1 fe:16:3e:02:62:18 yes0.00 7 fe:16:3e:07:65:47 yes0.00 7 fe:16:3e:07:65:47 yes0.00 4 fe:16:3e:1d:d6:33 yes0.00 4 fe:16:3e:1d:d6:33 yes0.00 9 fe:16:3e:2b:2f:f0 yes0.00 9 fe:16:3e:2b:2f:f0 yes0.00 8 fe:16:3e:3c:42:64 yes0.00 8 fe:16:3e:3c:42:64 yes0.00 10 fe:16:3e:5c:a6:6c yes0.00 10 fe:16:3e:5c:a6:6c yes0.00 2 fe:16:3e:86:9c:dd yes0.00 2 fe:16:3e:86:9c:dd yes0.00 6 fe:16:3e:91:9b:45 yes0.00 6 fe:16:3e:91:9b:45 yes0.00 11 fe:16:3e:b3:30:00 yes0.00 11 fe:16:3e:b3:30:00 yes0.00 3 fe:16:3e:dc:c3:3e yes0.00 3 fe:16:3e:dc:c3:3e yes0.00 root@lab-compute01:~# bridge fdb show | grep brqd0084ac0-f7 01:00:5e:00:00:01 dev brqd0084ac0-f7 self permanent fe:16:3e:02:62:18 dev tap74af38f9-2e master brqd0084ac0-f7 permanent fe:16:3e:02:62:18 dev tap74af38f9-2e vlan 1 master brqd0084ac0-f7 permanent fe:16:3e:86:9c:dd dev tapb00b3c18-b3 master brqd0084ac0-f7 permanent fe:16:3e:86:9c:dd dev tapb00b3c18-b3 vlan 1 master brqd0084ac0-f7 permanent fe:16:3e:dc:c3:3e dev tap7284d235-2b master brqd0084ac0-f7 permanent fe:16:3e:dc:c3:3e dev tap7284d235-2b vlan 1 master brqd0084ac0-f7 permanent fe:16:3e:1d:d6:33 dev tapbeb9441a-99 vlan 1 master brqd0084ac0-f7 permanent fe:16:3e:1d:d6:33 dev tapbeb9441a-99 master brqd0084ac0-f7 permanent 24:be:05:a3:1f:e1 dev eno1.102 vlan 1 master brqd0084ac0-f7 permanent 24:be:05:a3:1f:e1 dev eno1.102 master brqd0084ac0-f7 permanent fe:16:3e:91:9b:45 dev tapc8ad2cec-90 master brqd0084ac0-f7 permanent fe:16:3e:91:9b:45 dev tapc8ad2cec-90 vlan 1 master brqd0084ac0-f7 permanent fe:16:3e:07:65:47 dev tap86e2c412-24 master brqd0084ac0-f7 permanent fe:16:3e:07:65:47 dev tap86e2c412-24 vlan 1 master brqd0084ac0-f7 permanent fe:16:3e:3c:42:64 dev tap37bcb70e-9e master brqd0084ac0-f7 permanent fe:16:3e:3c:42:64 dev tap37bcb70e-9e vlan 1 master brqd0084ac0-f7 permanent fe:16:3e:2b:2f:f0 dev tap40f6be7c-2d vlan 1 master brqd0084ac0-f7 permanent fe:16:3e:2b:2f:f0 dev tap40f6be7c-2d master brqd0084ac0-f7 permanent fe:16:3e:b3:30:00 dev tap6548bacb-c0 vlan 1 master brqd0084ac0-f7 permanent fe:16:3e:b3:30:00 dev tap6548bacb-c0 master brqd0084ac0-f7 permanent fe:16:3e:5c:a6:6c dev tap61107236-1e vlan 1 master brqd0084ac0-f7 permanent fe:16:3e:5c:a6:6c dev tap61107236-1e master brqd0084ac0-f7 permanent The ageing time for the bridge is set to 0: root@lab-compute01:~# brctl showstp brqd0084ac0-f7 brqd0084ac0-f7 bridge id8000.24be05a31fe1 designated root 8000.24be05a31fe1 root port 0path cost 0 max age20.00 bridge max age20.00 hello time 2.00 bridge hello time 2.00 forward delay 0.00 bridge forward delay 0.00 ageing time 0.00 hello timer 0.00
[Yahoo-eng-team] [Bug 1837955] [NEW] MaxRetriesExceeded sometime fails with messaging exception
Public bug reported:
We are occasionally seeing MaxRetriesExceeded causing an "Exception
during message handling" error. This prevents the database from setting
the instance into error'd state and causes it to get stuck scheduling.
Example logs:
WARNING nova.scheduler.client.report [req-] Unable to submit allocation for
instance x (409 {"errors": [{"status": 409, "request_id": "req-", "code":
"placement.undefined_code", "detail": "There was a conflict when trying to
complete your request.\n\n Unable to allocate inventory: Unable to create
allocation for 'DISK_GB' on resource provider 'req-'. The requested amount
would exceed the capacity. ", "title": "Conflict"}]})
ERROR oslo_messaging.rpc.server [req-] Exception during message handling:
MaxRetriesExceeded: Exceeded maximum number of retries. Exhausted all hosts
available for retrying build failures for instance x.
** 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/1837955
Title:
MaxRetriesExceeded sometime fails with messaging exception
Status in OpenStack Compute (nova):
New
Bug description:
We are occasionally seeing MaxRetriesExceeded causing an "Exception
during message handling" error. This prevents the database from
setting the instance into error'd state and causes it to get stuck
scheduling.
Example logs:
WARNING nova.scheduler.client.report [req-] Unable to submit allocation for
instance x (409 {"errors": [{"status": 409, "request_id": "req-", "code":
"placement.undefined_code", "detail": "There was a conflict when trying to
complete your request.\n\n Unable to allocate inventory: Unable to create
allocation for 'DISK_GB' on resource provider 'req-'. The requested amount
would exceed the capacity. ", "title": "Conflict"}]})
ERROR oslo_messaging.rpc.server [req-] Exception during message handling:
MaxRetriesExceeded: Exceeded maximum number of retries. Exhausted all hosts
available for retrying build failures for instance x.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1837955/+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
