[Yahoo-eng-team] [Bug 1818960] [NEW] IPv6 not working with iptables
Public bug reported: Hi, Running rocky on Ubuntu 18.04 deployed by juju, using ML2, ovs, iptables. IPv6 appears to be broken because of missing MARK-related rules in the qrouter netns. The iptables and ip6tables rules generated by neutron are https://pastebin.ubuntu.com/p/S32TQcmTzX/ For egress (traffic leaving an instance) to work, the following additional rule is needed : sudo ip6tables -t mangle -I neutron-l3-agent-POSTROUTING -o qg-45ba891c-4c -m connmark --mark 0x0/0x -j CONNMARK --save-mark --nfmask 0x --ctmask 0x The following patch should fix the problem : https://pastebin.ubuntu.com/p/RpbYBjCVnp/ (sorry, I don't have time right now to update the tests for a proper merge request) For ingress, the following is needed : sudo ip6tables -t mangle -A neutron-l3-agent-scope -i qg-45ba891c-4c -j MARK --set-xmark 0x400/0x Haven't had the time to dig out in the code where exactly the bug is. Is IPv6 working for anyone with this setup ? Are these commands the right fix ? (I'm just mimicking what IPv4 does) I've looked at unit tests for my patch above, and IPv6 testing is extremely limited. My IPv6 subnet got created with : $ openstack subnet create --network net_instances --ip-version 6 --ipv6-address-mode=slaac --ipv6-ra-mode=slaac --allocation-pool start=,end= --subnet-range ::/64 --gateway subnet_instances_v6 Thanks ** 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/1818960 Title: IPv6 not working with iptables Status in neutron: New Bug description: Hi, Running rocky on Ubuntu 18.04 deployed by juju, using ML2, ovs, iptables. IPv6 appears to be broken because of missing MARK-related rules in the qrouter netns. The iptables and ip6tables rules generated by neutron are https://pastebin.ubuntu.com/p/S32TQcmTzX/ For egress (traffic leaving an instance) to work, the following additional rule is needed : sudo ip6tables -t mangle -I neutron-l3-agent-POSTROUTING -o qg-45ba891c-4c -m connmark --mark 0x0/0x -j CONNMARK --save-mark --nfmask 0x --ctmask 0x The following patch should fix the problem : https://pastebin.ubuntu.com/p/RpbYBjCVnp/ (sorry, I don't have time right now to update the tests for a proper merge request) For ingress, the following is needed : sudo ip6tables -t mangle -A neutron-l3-agent-scope -i qg-45ba891c-4c -j MARK --set-xmark 0x400/0x Haven't had the time to dig out in the code where exactly the bug is. Is IPv6 working for anyone with this setup ? Are these commands the right fix ? (I'm just mimicking what IPv4 does) I've looked at unit tests for my patch above, and IPv6 testing is extremely limited. My IPv6 subnet got created with : $ openstack subnet create --network net_instances --ip-version 6 --ipv6-address-mode=slaac --ipv6-ra-mode=slaac --allocation-pool start=,end= --subnet-range ::/64 --gateway subnet_instances_v6 Thanks To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1818960/+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 1027188] Re: Cloud-init chef plugin should support more distros and installation methods
Omnibus support was merged; if people want more methods, please open new bugs. ** Changed in: cloud-init Status: Triaged => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/1027188 Title: Cloud-init chef plugin should support more distros and installation methods Status in cloud-init: Fix Released Bug description: Currenlty, ruby pacakges in the cc_chef module are correct only for debian and ubuntu. Also we should support the Omnibus installer. Related bugs: * bug 785570: Use distro agnostic way of install/update packages To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1027188/+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 882940] Re: cloud-init should support cloudformation metadata
No clarification has been forthcoming; please set back to New if this is still interesting. ** Changed in: cloud-init Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/882940 Title: cloud-init should support cloudformation metadata Status in cloud-init: Won't Fix Bug description: CloudFormation introduced per resource metadata allowing configuration data to be passed from templates. This is currently implemented by Amazon's cfn-init tool and would be beneficial with cloudinit as well. Pros: metadata can be modified it allows using one user_data file for all stack machines To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/882940/+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 925145] Re: Use ip instead of ifconfig and route
** Changed in: cloud-init Status: Triaged => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/925145 Title: Use ip instead of ifconfig and route Status in cloud-init: Fix Released Status in Fedora: Confirmed Bug description: ifconfig just changed its output format again, breaking netinfo.py. Since net-tools have been deprecated for some time it makes more sense to switch to iproute as the net-tools maintainers suggest. Attached is a patch for netinfo.py and cc_disable_ec2_metadata.py that does so. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/925145/+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 684804] Re: cloud-init should fetch image-data as well as user-data
cloud-init does now support vendor-data. ** Changed in: cloud-init Status: Triaged => Fix Released ** Changed in: cloud-init (Ubuntu) Status: Triaged => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to cloud-init. https://bugs.launchpad.net/bugs/684804 Title: cloud-init should fetch image-data as well as user-data Status in cloud-init: Fix Released Status in cloud-init package in Ubuntu: Fix Released Bug description: Binary package hint: cloud-init cloud-init should fetch data specific to the image (and the platform) prior to fetching user-data, and treat it the same way. It should be an objective of ubuntu cloud images that they will run on multiple cloud platforms without customization. As cloud platforms differ, if the image is not customized, it is necessary for the image to perform certain platform-specific operations on first boot. These tend to be image specific too. An example would be to map PV driver disks. Currently cloud-init sucks down and run a user-data script if supplied. It gets this by default by reading http://169.254.169.254/user-data Cloud platform providers cannot provide data there because there is no agreed format for user-data (i.e. not every user uses the MIME format ubuntu's cloud-init uses), meaning that (a) we would corrupt the user-data blob, and (b) even prepending another MIME part, we'd run into problems with bad MIME etc. It is suggested that instead cloud-init FIRST gets a user-data script from http://169.254.169.254/image-data or similar. This would be platform specific data (as opposed to instance specific data) that would be run first. This could do platform specific stuff (for instance, change UUID, use custom first password code, disable bits of udev, and so forth). Added to the end of the URL would be GET parameters describing the operating system type, release, etc. that could be used to help the platform provider interpret what they should send down (although this could form part of the metadata of the image itself, in a situation where a server is e.g. installed manually on a blank disk it won't be there). This should be a pretty trivial addition to cloud-init. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/684804/+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 1818919] [NEW] CooperativeReader not py3-ready
Public bug reported: Tim Burke noticed this in IRC today: https://github.com/openstack/glance/blob/17.0.0/glance/common/utils.py#L231 Should be returning b'' since we're supposed to be returning bytes. Apparently our unit tests could use some beefing up, because they're not breaking under py3. ** Affects: glance Importance: High 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/1818919 Title: CooperativeReader not py3-ready Status in Glance: Triaged Bug description: Tim Burke noticed this in IRC today: https://github.com/openstack/glance/blob/17.0.0/glance/common/utils.py#L231 Should be returning b'' since we're supposed to be returning bytes. Apparently our unit tests could use some beefing up, because they're not breaking under py3. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1818919/+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 1818914] [NEW] Hypervisor resource usage on source still shows old flavor usage after resize confirm until update_available_resource periodic runs
Public bug reported:
I actually uncovered this due to some failing functional tests for
cross-cell resize:
https://review.openstack.org/#/c/641176/2/nova/compute/resource_tracker.py@503
But this goes back to https://review.openstack.org/#/c/370374/ for bug
1641750 and StarlingX has already fixed it:
https://github.com/starlingx-staging/stx-
nova/blob/master/nova/compute/resource_tracker.py#L728
The issue is that if you set the "update_resources_interval" to some
higher value, let's say 10 minutes, and resize an instance and
immediately confirm it, because let's say "resize_confirm_window" is set
to 1 second, then the GET /os-hypervisors/{hypervisor_id} results for
things like "local_gb_used", "memory_mb_used" and "vcpus_used" will
still show usage for the old flavor even though the instance is running
on the dest host with the new flavor and is gone from the source host.
That doesn't get fixed until the update_available_resource periodic task
runs on the source again (or the source nova-compute service is
restarted).
This is because the source compute resource tracker is not tracking the
migration in it's "tracked_migrations" dict. The resize claim happens on
the dest host and that's where the migration is "tracked". The
ResourceTracker on the source is tracking the instance in
'tracked_instances' rather than 'tracked_migrations'.
On the source host when the RT code is called here:
https://github.com/openstack/nova/blob/eaa29f71ef01f5da2edfa79886a302f8a5f352ae/nova/compute/resource_tracker.py#L1063
"tracked = uuid in self.tracked_instances" will be True because the
instance is on the source until it gets resized to the dest and then the
host value changes here:
https://github.com/openstack/nova/blob/eaa29f71ef01f5da2edfa79886a302f8a5f352ae/nova/compute/manager.py#L4500
But in the RT this means we won't get the itype here:
https://github.com/openstack/nova/blob/eaa29f71ef01f5da2edfa79886a302f8a5f352ae/nova/compute/resource_tracker.py#L1125
So the source RT doesn't track the migration here:
https://github.com/openstack/nova/blob/eaa29f71ef01f5da2edfa79886a302f8a5f352ae/nova/compute/resource_tracker.py#L1146
This is important because later in confirm_resize (on the source host)
when it calls RT.drop_move_claim:
https://github.com/openstack/nova/blob/eaa29f71ef01f5da2edfa79886a302f8a5f352ae/nova/compute/manager.py#L4014
That will only update resource usage and decrement the old flavor if
it's a tracked migration:
https://github.com/openstack/nova/blob/eaa29f71ef01f5da2edfa79886a302f8a5f352ae/nova/compute/resource_tracker.py#L478
As noted from the TODO in the elif block below:
https://github.com/openstack/nova/blob/eaa29f71ef01f5da2edfa79886a302f8a5f352ae/nova/compute/resource_tracker.py#L489
This is semi-low priority given how latent it is and the fact it's self-
healing since the next run of the update_available_resource periodic
will fix the resource usage on the source host, but in a busy cloud it
could mean the difference between a server being able to build on that
source host or not based on it's tracked resource usage.
** Affects: nova
Importance: Low
Status: Triaged
** Tags: resize resource-tracker starlingx
** Changed in: nova
Status: New => Triaged
** Tags added: starlingx
--
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/1818914
Title:
Hypervisor resource usage on source still shows old flavor usage after
resize confirm until update_available_resource periodic runs
Status in OpenStack Compute (nova):
Triaged
Bug description:
I actually uncovered this due to some failing functional tests for
cross-cell resize:
https://review.openstack.org/#/c/641176/2/nova/compute/resource_tracker.py@503
But this goes back to https://review.openstack.org/#/c/370374/ for bug
1641750 and StarlingX has already fixed it:
https://github.com/starlingx-staging/stx-
nova/blob/master/nova/compute/resource_tracker.py#L728
The issue is that if you set the "update_resources_interval" to some
higher value, let's say 10 minutes, and resize an instance and
immediately confirm it, because let's say "resize_confirm_window" is
set to 1 second, then the GET /os-hypervisors/{hypervisor_id} results
for things like "local_gb_used", "memory_mb_used" and "vcpus_used"
will still show usage for the old flavor even though the instance is
running on the dest host with the new flavor and is gone from the
source host. That doesn't get fixed until the
update_available_resource periodic task runs on the source again (or
the source nova-compute service is restarted).
This is because the source compute resource tracker is not tracking
the migration in it's "tracked_migrations" dict. The resize claim
happens on the dest host and that's where the migration is "tracked".
The ResourceTracker on the source is tracking the instance
[Yahoo-eng-team] [Bug 1805891] Re: pci numa polices are not followed
Reviewed: https://review.openstack.org/62
Committed:
https://git.openstack.org/cgit/openstack/nova/commit/?id=59d94633518e6f6272e9f0654bb908e332f97a96
Submitter: Zuul
Branch:master
commit 59d94633518e6f6272e9f0654bb908e332f97a96
Author: Stephen Finucane
Date: Tue Dec 11 16:01:38 2018 +
objects: Store InstancePCIRequest.numa_policy in DB
In change I9360fe29908, we added the 'numa_policy' field to the
'InstancePCIRequest' object. Unfortunately we did not update the
(de)serialization logic for the 'InstancePCIRequests' object, meaning
this field was never saved to the database. As a result, claiming will
always fail [1].
The resolution is simple - add the (de)serialization logic and tests to
prevent regression.
[1]
https://github.com/openstack/nova/blob/18.0.0/nova/compute/resource_tracker.py#L214-L215
Change-Id: Id4d8ecb8fee46b21590ebcc62a2850030cef6508
Closes-Bug: #1805891
** 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/1805891
Title:
pci numa polices are not followed
Status in OpenStack Compute (nova):
Fix Released
Bug description:
Description
===
https://specs.openstack.org/openstack/nova-specs/specs/queens/implemented/share-pci-between-numa-nodes.html
introduced the concept of numa affinity policies for pci passthough devices.
upon testing it was observed that the prefer policy is broken.
for contested there is a sperate bug to track the lack of support for
neutron sriov interfaces.
https://bugs.launchpad.net/nova/+bug/1795920 so the scope of this bug is
limited
pci numa policies for passtrhough devices using a flavor alias.
background
--
by default in nova pci devices are numa affinitesed using the legacy policy.
but you can override this behavior via the alias. when set to prefer nova
should fall back to no numa affintiy bwteen the guest and the pci devce
if a device on a local numa node is not availeble.
the policies are discibed below.
legacy
This is the default value and it describes the current nova
behavior. Usually we have information about association of PCI devices
with NUMA nodes. However, some PCI devices do not provide such
information. The legacy value will mean that nova will boot instances
with PCI device if either:
The PCI device is associated with at least one NUMA nodes on which
the instance will be booted
There is no information about PCI-NUMA affinity available
preferred
This value will mean that nova-scheduler will choose a compute
host with minimal consideration for the NUMA affinity of PCI devices.
nova-compute will attempt a best effort selection of PCI devices based
on NUMA affinity, however, if this is not possible then nova-compute
will fall back to scheduling on a NUMA node that is not associated
with the PCI device.
Note that even though the NUMATopologyFilter will not consider
NUMA affinity, the weigher proposed in the Reserve NUMA Nodes with PCI
Devices Attached spec [2] can be used to maximize the chance that a
chosen host will have NUMA-affinitized PCI devices.
Steps to reproduce
==
the test case was relitively simple
- deploy a singel node devstack install on a host with 2 numa nodes.
- enable the pci and numa topology fileters
- whitelist a pci device attach to numa_node 0
e.g. passthrough_whitelist = { "address": ":01:00.1" }
- adust the vcpu_pin_set to only list the cpus on numa_node 1
e.g. vcpu_pin_set=8-15
- crate an alias in the pci section of the nova.conf
alias = { "vendor_id":"8086", "product_id":"10c9", "device_type":"type-PF",
"name":"nic-pf", "numa_policy": "preferred"}
- restart the nova services
sudo systemctl restart devstack@n-*
- update a flavour with the alias and a numa toplogy of 1
openstack flavour set --property pci_passthrough:alias='nic-pf:1' 42
openstack flavour set --property hw:numa_nodes=1 42
++-+
| Field | Value
|
++-+
| OS-FLV-DISABLED:disabled | False
|
| OS-FLV-EXT-DATA:ephemeral | 0
|
| access_project_ids | None
|
| disk | 0
|
| id | 42
|
| name | m1.nano
[Yahoo-eng-team] [Bug 1818873] [NEW] When post_live_migration_at_destination fails the instance is not put into ERROR/None vm_state/task_state
Public bug reported: Seen here: http://logs.openstack.org/43/635343/4/check/tempest-slow- py3/a2497ae/controller/logs/screen-n-cpu.txt.gz?level=TRACE#_Mar_06_05_26_25_035103 Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: ERROR nova.compute.manager [-] [instance: b78e10fb-44b8-4010-a72d-c86410950c15] Post live migration at destination ubuntu-bionic-rax-iad-0003421804 failed: AttributeError: 'dict' object has no attribute 'dest_compute' Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: Traceback (most recent call last): Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/server.py", line 166, in _process_incoming Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: res = self.dispatcher.dispatch(message) Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 265, in dispatch Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: return self._do_dispatch(endpoint, method, ctxt, args) Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: File "/usr/local/lib/python2.7/dist-packages/oslo_messaging/rpc/dispatcher.py", line 194, in _do_dispatch Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: result = func(ctxt, **new_args) Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: File "/opt/stack/nova/nova/exception_wrapper.py", line 79, in wrapped Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: function_name, call_dict, binary, tb) Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: self.force_reraise() Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: six.reraise(self.type_, self.value, self.tb) Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: File "/opt/stack/nova/nova/exception_wrapper.py", line 69, in wrapped Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: return f(self, context, *args, **kw) Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: File "/opt/stack/nova/nova/compute/utils.py", line 1301, in decorated_function Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: return function(self, context, *args, **kwargs) Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: File "/opt/stack/nova/nova/compute/manager.py", line 212, in decorated_function Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: kwargs['instance'], e, sys.exc_info()) Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 220, in __exit__ Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: self.force_reraise() Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: File "/usr/local/lib/python2.7/dist-packages/oslo_utils/excutils.py", line 196, in force_reraise Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: six.reraise(self.type_, self.value, self.tb) Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: File "/opt/stack/nova/nova/compute/manager.py", line 200, in decorated_function Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: return function(self, context, *args, **kwargs) Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: File "/opt/stack/nova/nova/compute/manager.py", line 6942, in post_live_migration_at_destination Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: migration) Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: File "/opt/stack/nova/nova/network/neutronv2/api.py", line 2815, in migrate_instance_finish Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: context, instance, migration.dest_compute, migration=migration) Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: AttributeError: 'dict' object has no attribute 'dest_compute' Mar 06 05:26:25.035103 ubuntu-bionic-rax-iad-0003421801 nova-compute[20242]: ERROR nova.compute.manager [instance: b78e10fb-44b8-4010-a72d-c86410950c15] Traceback (most recent call
[Yahoo-eng-team] [Bug 1818859] [NEW] neutron functional job intermittent failures with ovsdbapp.backend.ovs_idl.idlutils.RowNotFound
Public bug reported: It appears the neutron functional job started failing with errors related to: ovsdbapp.backend.ovs_idl.idlutils.RowNotFound For example [1][2]. Based on logstash [3] it looks like this issue may have cropped up around March 5th. [1] http://logs.openstack.org/34/639034/7/check/neutron-functional/d32644a/job-output.txt.gz [2] http://logs.openstack.org/04/637004/2/check/neutron-functional-python27/5dd04c3/job-output.txt.gz#_2019-03-06_13_27_21_193728 [3] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22ovsdbapp.backend.ovs_idl.idlutils.RowNotFound%3A%20Cannot%20find%20Port%20with%20name%3D%5C%22 ** Affects: neutron Importance: Undecided Status: New ** Tags: gate-failure -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1818859 Title: neutron functional job intermittent failures with ovsdbapp.backend.ovs_idl.idlutils.RowNotFound Status in neutron: New Bug description: It appears the neutron functional job started failing with errors related to: ovsdbapp.backend.ovs_idl.idlutils.RowNotFound For example [1][2]. Based on logstash [3] it looks like this issue may have cropped up around March 5th. [1] http://logs.openstack.org/34/639034/7/check/neutron-functional/d32644a/job-output.txt.gz [2] http://logs.openstack.org/04/637004/2/check/neutron-functional-python27/5dd04c3/job-output.txt.gz#_2019-03-06_13_27_21_193728 [3] http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22ovsdbapp.backend.ovs_idl.idlutils.RowNotFound%3A%20Cannot%20find%20Port%20with%20name%3D%5C%22 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1818859/+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 1818847] [NEW] Fix QEMU cache mode used for image conversion and Nova instances
Public bug reported: Nova uses QEMU's disk image cache modes in two main areas: (1) When decicding what cache mode to use for the target disk image when converting (using `qemu-img convert`) images from one format to another (qcow2 <-> raw). See unprivileged_convert_image() in nova/privsep/qemu.py. (2) When configuring cache modes for running guests (Nova instances). Nova tells libvirt what cache mode to use, and libvirt will in turn configure block devices via QEMU (using its '-drive' command-line option). See disk_cachemode() in nova/virt/libvirt/driver.py. (And also for "volume drivers" like SMBFS and Virtuozzo Storage also use 'writethrough' -- refer smbfs.py and vzstorage.py.) In both cases Nova uses QEMU's a combination of cache modes 'none' and 'writethrough'. But that is incorrect, because of our misunderstanding of how cache modes work. E.g. Nova's libvirt driver currently assumes (refer disk_cachemode()) that 'writethrough' and 'none' cache modes have the same behaviour with respect to host crash safety, which is not at all true. Fix these wrong assumptions. (Also consult the QEMU Block Layer developers to double-check the behaviour of cache modes and where they are applicable.) ** Affects: nova Importance: Undecided Status: New ** Summary changed: - Fix QEMU cache mode for image conversion and Nova instances + Fix QEMU cache mode used for image conversion and Nova instances -- 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/1818847 Title: Fix QEMU cache mode used for image conversion and Nova instances Status in OpenStack Compute (nova): New Bug description: Nova uses QEMU's disk image cache modes in two main areas: (1) When decicding what cache mode to use for the target disk image when converting (using `qemu-img convert`) images from one format to another (qcow2 <-> raw). See unprivileged_convert_image() in nova/privsep/qemu.py. (2) When configuring cache modes for running guests (Nova instances). Nova tells libvirt what cache mode to use, and libvirt will in turn configure block devices via QEMU (using its '-drive' command-line option). See disk_cachemode() in nova/virt/libvirt/driver.py. (And also for "volume drivers" like SMBFS and Virtuozzo Storage also use 'writethrough' -- refer smbfs.py and vzstorage.py.) In both cases Nova uses QEMU's a combination of cache modes 'none' and 'writethrough'. But that is incorrect, because of our misunderstanding of how cache modes work. E.g. Nova's libvirt driver currently assumes (refer disk_cachemode()) that 'writethrough' and 'none' cache modes have the same behaviour with respect to host crash safety, which is not at all true. Fix these wrong assumptions. (Also consult the QEMU Block Layer developers to double-check the behaviour of cache modes and where they are applicable.) To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1818847/+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 1818846] [NEW] The trust API doesn't use default roles
Public bug reported: In Rocky, keystone implemented support to ensure at least three default roles were available [0]. The trust API doesn't incorporate these defaults into its default policies [1], but it should. It would be useful for system members and readers to diagnose issues with trusts, instead of requiring system administrators to do everything. [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/trust.py?id=6e3f1f6e46787ed4542609c935c13cb85e91d7fc ** Affects: keystone Importance: Low Status: Triaged ** Tags: default-roles policy ** Tags added: default-roles policy ** Changed in: keystone Status: New => Triaged ** Changed in: keystone Importance: Undecided => Low -- 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/1818846 Title: The trust API doesn't use default roles Status in OpenStack Identity (keystone): Triaged Bug description: In Rocky, keystone implemented support to ensure at least three default roles were available [0]. The trust API doesn't incorporate these defaults into its default policies [1], but it should. It would be useful for system members and readers to diagnose issues with trusts, instead of requiring system administrators to do everything. [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/trust.py?id=6e3f1f6e46787ed4542609c935c13cb85e91d7fc To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1818846/+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 1818850] [NEW] The v3 trust API should account for different scopes
Public bug reported:
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.
The trust API and trust entities require projects in order to be useful,
but allowing system users to list or manage trusts would be useful for
support personnel.
GET /v3/OS-TRUST/trusts or GET /v3/OS-TRUST/trusts/{trust_id}
For example, a system user should be able to list all trusts in the
deployment, while project users should only be able to access that API
for trusts they own.
POST /v3/OS-TRUST/trusts
Only project users should be able to call this API since trusts require
a project in order to be useful
DELETE /v3/OS-TRUST/trusts/{trust_id}
This API should be accessible to system administrators and users
attempting to delete their own trust. This work might also present us
with an opportunity to remove some of the logic in the trust API layer,
in favor of something that's more commonly used across keystone APIs
[0].
[0]
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/api/trusts.py?id=6e3f1f6e46787ed4542609c935c13cb85e91d7fc#n45
** Affects: keystone
Importance: Low
Status: Triaged
** Tags: policy system-scope
** Tags added: policy system-scope
** Changed in: keystone
Status: New => Triaged
** Changed in: keystone
Importance: Undecided => Low
** Description changed:
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.
The trust API and trust entities require projects in order to be useful,
but allowing system users to list or manage trusts would be useful for
support personnel.
GET /v3/OS-TRUST/trusts or GET /v3/OS-TRUST/trusts/{trust_id}
For example, a system user should be able to list all trusts in the
deployment, while project users should only be able to access that API
for trusts they own.
POST /v3/OS-TRUST/trusts
Only project users should be able to call this API since trusts require
a project in order to be useful
DELETE /v3/OS-TRUST/trusts/{trust_id}
This API should be accessible to system administrators and users
- attempting to delete their own trust.
+ attempting to delete their own trust. This work might also present us
+ with an opportunity to remove some of the logic in the trust API layer,
+ in favor of something that's more commonly used across keystone APIs
+ [0].
+
+ [0]
+
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/api/trusts.py?id=6e3f1f6e46787ed4542609c935c13cb85e91d7fc#n45
--
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/1818850
Title:
The v3 trust API should account for different scopes
Status in OpenStack Identity (keystone):
Triaged
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.
The trust API and trust entities require projects in order to be
useful, but allowing system users to list or manage trusts would be
useful for support personnel.
GET /v3/OS-TRUST/trusts or GET /v3/OS-TRUST/trusts/{trust_id}
For example, a system user should be able to list all trusts in the
deployment, while project users should only be able to access that API
for trusts they own.
POST /v3/OS-TRUST/trusts
Only project users should be able to call this API since trusts
require a project in order to be useful
DELETE /v3/OS-TRUST/trusts/{trust_id}
This API should be accessible to system administrators and users
attempting to delete their own trust. This work might also present us
with an opportunity to remove some of the logic in the trust API
layer, in favor of something that's more commonly used across keystone
APIs [0].
[0]
http://git.openstack.org/cgit/openstack/keystone/tree/keystone/api/trusts.py?id=6e3f1f6e46787ed4542609c935c13cb85e91d7fc#n45
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1818850/+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 1818844] [NEW] Token API doesn't use default roles
Public bug reported: In Rocky, keystone implemented support to ensure at least three default roles were available [0]. The token API doesn't incorporate these defaults into its default policies [1], but it should. For example, a system reader should be able to validate tokens for other users, but only system administrators should be able to revoke them (since it's technically a writeable API). Building these roles into the token API will make it easier for system users who aren't administrators to diagnose token issues for users. [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/token.py?id=6e3f1f6e46787ed4542609c935c13cb85e91d7fc ** Affects: keystone Importance: Medium Status: Triaged ** Tags: default-roles policy ** Changed in: keystone Status: New => Triaged ** Changed in: keystone Importance: Undecided => Medium ** Tags added: policy ** Tags added: default-roles -- 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/1818844 Title: Token API doesn't use default roles Status in OpenStack Identity (keystone): Triaged Bug description: In Rocky, keystone implemented support to ensure at least three default roles were available [0]. The token API doesn't incorporate these defaults into its default policies [1], but it should. For example, a system reader should be able to validate tokens for other users, but only system administrators should be able to revoke them (since it's technically a writeable API). Building these roles into the token API will make it easier for system users who aren't administrators to diagnose token issues for users. [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/token.py?id=6e3f1f6e46787ed4542609c935c13cb85e91d7fc To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1818844/+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 1818845] [NEW] The revocation list API doesn't use default roles or proper scope types
Public bug reported: In Rocky, keystone implemented support to ensure at least three default roles were available [0]. The revocation list API doesn't incorporate these defaults into its default policies [1], but it should. Even though this API isn't really useful without PKI/Z tokens, we should apply the same default role conventions to it that we use for all other policies in keystone. The revocation list policy also allows for project-scoped and system- scoped tokens. This should probably be a system-only API since it's dealing with sensitive token revocation information (unless there is a good reason for project or domain users to fetch this list). [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/token_revocation.py?id=6e3f1f6e46787ed4542609c935c13cb85e91d7fc ** Affects: keystone Importance: Wishlist Status: Triaged ** Tags: default-roles policy ** Tags added: default-roles policy ** Changed in: keystone Status: New => Triaged ** Changed in: keystone Importance: Undecided => Wishlist ** Summary changed: - The revocation list API doesn't use default roles + The revocation list API doesn't use default roles or proper scope types ** Description changed: In Rocky, keystone implemented support to ensure at least three default roles were available [0]. The revocation list API doesn't incorporate these defaults into its default policies [1], but it should. Even though this API isn't really useful without PKI/Z tokens, we should apply the same default role conventions to it that we use for all other policies in keystone. + The revocation list policy also allows for project-scoped and system- + scoped tokens. This should probably be a system-only API since it's + dealing with sensitive token revocation information (unless there is a + good reason for project or domain users to fetch this list). + [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/token_revocation.py?id=6e3f1f6e46787ed4542609c935c13cb85e91d7fc -- 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/1818845 Title: The revocation list API doesn't use default roles or proper scope types Status in OpenStack Identity (keystone): Triaged Bug description: In Rocky, keystone implemented support to ensure at least three default roles were available [0]. The revocation list API doesn't incorporate these defaults into its default policies [1], but it should. Even though this API isn't really useful without PKI/Z tokens, we should apply the same default role conventions to it that we use for all other policies in keystone. The revocation list policy also allows for project-scoped and system- scoped tokens. This should probably be a system-only API since it's dealing with sensitive token revocation information (unless there is a good reason for project or domain users to fetch this list). [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/token_revocation.py?id=6e3f1f6e46787ed4542609c935c13cb85e91d7fc To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1818845/+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 1818826] [NEW] Volume Type 'View Extra Specs' overrides existing key value
Public bug reported: When User create a new spec using 'View Extra Spec' with an existing key name under Volume Type panel, the existing spec will be overridden.In the cinder API, the behavior is "set" so it is not surprising to override an existing spec.However, in the horizon implementation, "Create" and "Edit" are used.So We it is better to suggest "Edit" when a specified key already exists in the "Create" spec form. ** Affects: horizon Importance: Undecided Assignee: Vishal Manchanda (vishalmanchanda) Status: New ** Changed in: horizon Assignee: (unassigned) => Vishal Manchanda (vishalmanchanda) -- 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/1818826 Title: Volume Type 'View Extra Specs' overrides existing key value Status in OpenStack Dashboard (Horizon): New Bug description: When User create a new spec using 'View Extra Spec' with an existing key name under Volume Type panel, the existing spec will be overridden.In the cinder API, the behavior is "set" so it is not surprising to override an existing spec.However, in the horizon implementation, "Create" and "Edit" are used.So We it is better to suggest "Edit" when a specified key already exists in the "Create" spec form. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1818826/+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 1816360] Re: nova-scheduler did not logged the weight of each compute_node
Reviewed: https://review.openstack.org/641143 Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=84533f5eb3c5b4ab7598d7c278b53524acc1c6e0 Submitter: Zuul Branch:master commit 84533f5eb3c5b4ab7598d7c278b53524acc1c6e0 Author: Matt Riedemann Date: Tue Mar 5 17:16:23 2019 -0500 Fix WeighedHost logging regression Change I8666e0af3f057314f6b06939a108411b8a88d64b in Pike refactored some code in the FilterScheduler which accidentally changed how the list of weighed hosts are logged, which caused the wrapped HostState objects to be logged rather than the WeighedHost objects, which contain the actual "weight" attribute which is useful for debugging weigher configuration and scheduling decisions. This fixes the regression by logging the weighed hosts before stripping off the WeighedHost wrapper and adds a simple wrinkle to an existing test to assert we are logging the correct object. Change-Id: I528794b4b6f0007efc1238ad28dc402456664f86 Closes-Bug: #1816360 ** 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/1816360 Title: nova-scheduler did not logged the weight of each compute_node Status in OpenStack Compute (nova): Fix Released 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: Description === nova-scheduler did not logged the weight of each compute_node, even if we configured "debug=true". You can only see this in nova-scheduler.log (Rocky version). 2019-02-18 15:02:56.918 18716 DEBUG nova.scheduler.filter_scheduler [req-242d0408-395d-4dc2-a237-e3f2b55c2ba8 8fdccd78f9404ccbb427b0b798f46f67 d8706f56f2314bbb8e62463ba833bb1e - default default] Weighed [(nail1, nail1) ram: 27527MB disk: 226304MB io_ops: 0 instances: 2, (Shelf1Slot3SBCR, Shelf1Slot3SBCR) ram: 12743MB disk: 112640MB io_ops: 0 instances: 3, (nail2, nail2) ram: 19919MB disk: 120832MB io_ops: 0 instances: 0] _get_sorted_hosts /usr/lib/python2.7/site- packages/nova/scheduler/filter_scheduler.py:455 But in kilo OpenStack, we can see: 2019-02-18 15:31:07.418 24797 DEBUG nova.scheduler.filter_scheduler [req-9449a23f-643d-45a1-aed7-9d62639d874d 8228476c4baf4a819f2c7b890069c5d1 7240ab9c4351484095c15ae33e0abd0b - - -] Weighed [WeighedHost [host: (computer16-02, computer16-02) ram:45980 disk:69632 io_ops:0 instances:11, weight: 1.0], WeighedHost [host: (computer16-08, computer16-08) ram:45980 disk:73728 io_ops:0 instances:15, weight: 1.0], WeighedHost [host: (computer16-03, computer16-03) ram:43932 disk:117760 io_ops:0 instances:10, weight: 0.955458895172], WeighedHost [host: (computer16-07, computer16-07) ram:43932 disk:267264 io_ops:0 instances:11, weight: 0.955458895172], WeighedHost [host: (computer16-15, computer16-15) ram:41884 disk:-114688 io_ops:0 instances:15, weight: 0.910917790344], WeighedHost [host: (computer16-16, computer16-16) ram:35740 disk:967680 io_ops:0 instances:10, weight: 0.777294475859], WeighedHost [host: (computer16-12, computer16-12) ram:31644 disk:-301056 io_ops:0 instances:13, weight: 0.688212266203], WeighedHost [host: (computer16-05, computer16-05) ram:25500 disk:-316416 io_ops:0 instances:13, weight: 0.554588951718], WeighedHost [host: (computer16-06, computer16-06) ram:17308 disk:-66560 io_ops:0 instances:12, weight: 0.376424532405]] _schedule /usr/lib/python2.7/site- packages/nova/scheduler/filter_scheduler.py:149 Obviously, we have lost the weight value for each compute_nodes now. Environment === [root@nail1 ~]# rpm -qi openstack-nova-api Name: openstack-nova-api Epoch : 1 Version : 18.0.2 Release : 1.el7 Architecture: noarch Install Date: Wed 17 Oct 2018 02:23:03 PM CST Group : Unspecified Size: 5595 License : ASL 2.0 Signature : RSA/SHA1, Mon 15 Oct 2018 05:02:18 PM CST, Key ID f9b9fee7764429e6 Source RPM : openstack-nova-18.0.2-1.el7.src.rpm Build Date : Tue 09 Oct 2018 05:54:47 PM CST Build Host : p8le01.rdu2.centos.org Relocations : (not relocatable) Packager: CBS Vendor : CentOS URL : http://openstack.org/projects/compute/ Summary : OpenStack Nova API services To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1816360/+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 1818824] [NEW] When a fip is added to a vm with dvr, previous connections loss the connectivity
Public bug reported: The behavior wihout DVR is that the previous connections continue using the snat ip and the new connections go to use the fip. then without dvr: -1 add fip -> no delete conntrack flows -2 delete fip -> delete conntrack flows I don know if 1 is a expected behavior or a bug. Delete the conntrack entries in the 1 and 2 would be a simpler solution(less casuistic). then first we should be sure of the desired behavior when a fip is added, becuase it is not working with DVR. If the decission isn't maintain the old connections then: -with and without DVR the conntrack entries shoud be deleted. If the decission is maintais the old connection then: -the fix only would be necessary for DVR and it consists in create a way for the external traffic without nat(in the qrouter of the compute, the nat is done in the controller qrouter )(*). Related bug: https://bugs.launchpad.net/neutron/+bug/1818805 "Conntrack rules in the qrouter are not deleted when a fip is removed with dvr" (*) With dvr the external traffic is managed using pbr(in the qrouter): without fip: [root@compute-2 heat-admin]# ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: rfp-d01c89b0-c: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 06:09:90:b6:24:47 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 169.254.106.114/31 scope global rfp-d01c89b0-c valid_lft forever preferred_lft forever inet6 fe80::409:90ff:feb6:2447/64 scope link valid_lft forever preferred_lft forever 43: qr-c47b0417-7d: mtu 1450 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether fa:16:3e:d9:7d:01 brd ff:ff:ff:ff:ff:ff inet 10.2.0.1/24 brd 10.2.0.255 scope global qr-c47b0417-7d valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fed9:7d01/64 scope link valid_lft forever preferred_lft forever [root@compute-2 heat-admin]# ip r 10.2.0.0/24 dev qr-c47b0417-7d proto kernel scope link src 10.2.0.1 169.254.106.114/31 dev rfp-d01c89b0-c proto kernel scope link src 169.254.106.114 [root@compute-2 heat-admin]# ip rule list 0: from all lookup local 32766: from all lookup main 32767: from all lookup default 167903233: from 10.2.0.1/24 lookup 167903233 [root@compute-2 heat-admin]# ip r show table 167903233 default via 10.2.0.8 dev qr-c47b0417-7d [root@compute-2 heat-admin]# ip route get 8.8.8.8 from 10.2.0.12 iif qr-c47b0417-7d 8.8.8.8 from 10.2.0.12 via 10.2.0.8 dev qr-c47b0417-7d cache iif * The traffic is sent to the qrouter in the controller With fip: [root@compute-1 heat-admin]# ip a 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: rfp-d01c89b0-c@if3: mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether 06:5e:ac:51:83:7a brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet 169.254.106.114/31 scope global rfp-d01c89b0-c valid_lft forever preferred_lft forever inet6 fe80::45e:acff:fe51:837a/64 scope link valid_lft forever preferred_lft forever 23: qr-c47b0417-7d: mtu 1450 qdisc noqueue state UNKNOWN group default qlen 1000 link/ether fa:16:3e:d9:7d:01 brd ff:ff:ff:ff:ff:ff inet 10.2.0.1/24 brd 10.2.0.255 scope global qr-c47b0417-7d valid_lft forever preferred_lft forever inet6 fe80::f816:3eff:fed9:7d01/64 scope link valid_lft forever preferred_lft forever [root@compute-1 heat-admin]# ip r 10.2.0.0/24 dev qr-c47b0417-7d proto kernel scope link src 10.2.0.1 169.254.106.114/31 dev rfp-d01c89b0-c proto kernel scope link src 169.254.106.114 [root@compute-1 heat-admin]# ip rule list 0: from all lookup local 32766: from all lookup main 32767: from all lookup default 57483: from 10.2.0.12 lookup 16 167903233: from 10.2.0.1/24 lookup 167903233 [root@compute-1 heat-admin]# ip r show table 16 default via 169.254.106.115 dev rfp-d01c89b0-c [root@compute-1 heat-admin]# [root@compute-1 heat-admin]# ip route get 8.8.8.8 from 10.2.0.12 iif qr-c47b0417-7d 8.8.8.8 from 10.2.0.12 via 169.254.106.115 dev rfp-d01c89b0-c cache iif * The traffic is sent to the fip namestpace to out directly without pass for the controller. The problem is that the traffic of old connections with contrack entries is sent to the fip name space without snat, but this traffic should be sent to the controller in the same way than in the scenario without fip. traffic before adding fip: [root@compute-1 heat-admin]# [root@compute-1 heat-admin]# tcpdump -nei rfp-d01c89b0-c tcpdump: verbose output
[Yahoo-eng-team] [Bug 1818791] Re: Volume Snapshot table has incorrect error message.
Reviewed: https://review.openstack.org/641257 Committed: https://git.openstack.org/cgit/openstack/horizon/commit/?id=beedc4e729ae2c819ef3ae4ece87e7b913a9f0da Submitter: Zuul Branch:master commit beedc4e729ae2c819ef3ae4ece87e7b913a9f0da Author: manchandavishal Date: Wed Mar 6 07:16:55 2019 + Correcting the error messages of Volume Snapshot Table Change-Id: I8d0e2879a9d2a76cf5173764035f690072a80c82 Closes-Bug: #1818791 ** Changed in: horizon Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1818791 Title: Volume Snapshot table has incorrect error message. Status in OpenStack Dashboard (Horizon): Fix Released Bug description: Volume snapshot table to retrieve volume snapshot project project information has incorrect error message here [1]. [1] https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/admin/snapshots/tables.py#L52 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1818791/+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 1818823] [NEW] Missing community image name
Public bug reported:
When listing instances in the main instance table, instances launched
from community images have a dash ("-") in the image name cell rather
than the name of the image.
** 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/1818823
Title:
Missing community image name
Status in OpenStack Dashboard (Horizon):
New
Bug description:
When listing instances in the main instance table, instances launched
from community images have a dash ("-") in the image name cell rather
than the name of the image.
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1818823/+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 1818693] Re: Make "phys_brs" parameter variable in OVSAgentExtensionAPI
Reviewed: https://review.openstack.org/641064 Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=f08de5cbe9695700e282b9882c661353a2c36d74 Submitter: Zuul Branch:master commit f08de5cbe9695700e282b9882c661353a2c36d74 Author: Rodolfo Alonso Hernandez Date: Tue Mar 5 15:59:00 2019 + Make "phys_brs" argument in OVSAgentExtensionAPI optional In [1], a new init parameter was introduced in the class OVSAgentExtensionAPI. This change in the extension API can break backwards compatibility with other projects (networking_sfc and bagpipe are affected). Because this parameter is needed only in qos_driver extension when calling OVSAgentExtensionAPI.request_phy_brs() (to retrieve the physical bridges list), we can make this new parameter optional not to break other stadium projects. When the OVS it's initialized (in-tree agent), the extension is called with the three needed parameters. [1] https://review.openstack.org/#/c/406841/22/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_agent_extension_api.py@43 Change-Id: I31d1a31a935fdcdd12e13e1bc58f7c5f640ca092 Closes-Bug: #1818693 ** 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/1818693 Title: Make "phys_brs" parameter variable in OVSAgentExtensionAPI Status in neutron: Fix Released Bug description: In [1], a new init parameter was introduced in the class OVSAgentExtensionAPI. This change in the extension API can break backwards compatibility with other projects (networking_sfc and bagpipe are affected). Because this parameter is needed only in qos_driver extension when calling OVSAgentExtensionAPI.request_phy_brs() (to retrieve the physical bridges), we can make this new parameter optional not to break other stadium projects. When the OVS it's initialized (in-tree agent), the extension is called with the three needed parameters. [1] https://review.openstack.org/#/c/406841/22/neutron/plugins/ml2/drivers/openvswitch/agent/ovs_agent_extension_api.py@43 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1818693/+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 1818805] [NEW] Conntrack rules in the qrouter are not deleted when a fip is removed with dvr
Public bug reported:
If a fip ip is removed of a network with a distributed router:
openstack server remove floating ip X
The conntrack rules aren't deleted in the qrouter and the qrouter continues
doing nating of the ongoing connections.
overcloud) [stack@undercloud-0 ~]$ openstack router show router
+-+--+
| Field | Value
|
+-+--+
| admin_state_up | UP
|
| availability_zone_hints |
|
| availability_zones | nova
|
| created_at | 2019-02-20T15:46:53Z
|
| description |
|
| distributed | True
|
| external_gateway_info | {"network_id":
"15a5c01e-4e42-4890-a850-db4f97bb5834", "enable_snat": true,
"external_fixed_ips": [{"subnet_id": "c59ae813-1df7-4a14-9eba-be2e35afa13e",
"ip_address": "10.0.0.214"}]}
|
| flavor_id | None
|
| ha | False
|
| id | d01c89b0-c2df-46e2-9c12-8d14b1c8ce9a
|
| interfaces_info | [{"subnet_id":
"5e8ddfa7-d546-4f59-94d1-e2b65e8ecdb6", "ip_address": "10.2.0.8", "port_id":
"06c6e9d3-2c6b-40b8-8919-92be6efd0153"}, {"subnet_id":
"5e8ddfa7-d546-4f59-94d1-e2b65e8ecdb6", "ip_address": "10.2.0.1", "port_id":
"c47b0417-7dbe-4434-8c50-72a78e6335a1"}] |
| name| router
|
| project_id | 9447276fedbf4c4eab15494f8d187d97
[Yahoo-eng-team] [Bug 1818798] [NEW] Should not skip volume_size check for bdm.image_id == image_ref case
Public bug reported: The volume size should be checked in bdm.sourece_type=image, dest_type=volume case no matter what the image is, but in: https://github.com/openstack/nova/blob/5a09c81af3b438ecbcf27fa653095ff55abb3ed4/nova/compute/api.py#L1452-L1453 we skipped the check if the bdm.image_id == image_ref, it was meant to skip only the _get_image() check as it is already checked before, but it skipped the volume_size check too. ** 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/1818798 Title: Should not skip volume_size check for bdm.image_id == image_ref case Status in OpenStack Compute (nova): New Bug description: The volume size should be checked in bdm.sourece_type=image, dest_type=volume case no matter what the image is, but in: https://github.com/openstack/nova/blob/5a09c81af3b438ecbcf27fa653095ff55abb3ed4/nova/compute/api.py#L1452-L1453 we skipped the check if the bdm.image_id == image_ref, it was meant to skip only the _get_image() check as it is already checked before, but it skipped the volume_size check too. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1818798/+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
