[Yahoo-eng-team] [Bug 1934420] [NEW] [OVN]ControllerAgent cannot be changed to ControllerGatewayAgent dynamically
Public bug reported: I have 3 nodes. NodeA, NodeB, NodeC. I execute cmd 'ovs-vsctl set open_vswitch . external-ids:ovn-cms-options =enable-chassis-as-gw' in NodeA and NodeV, as gateway Node. show agent list by executing the command 'openstack network agent list': NodeA is 'OVN Controller Gatewaty agent' NodeB is 'OVN Controller Gatewaty agent' NodeC is 'OVN Controller agent' the result is the same as I expected. next I execute cmd 'ovs-vsctl set open_vswitch . external-ids:ovn-cms- options=enable-chassis-as-gw' in NodeC, show agent list by executing the command 'openstack network agent list': NodeA is 'OVN Controller Gatewaty agent' NodeB is 'OVN Controller Gatewaty agent' NodeC is 'OVN Controller agent' The NodeC is still 'OVN Controller agent', not 'OVN Controller Gatewaty agent', The command has been executed many times and the result is still unchanged. But as long as I execute the command to restart the neutron service, the result will be correct. NodeC is 'OVN Controller Gatewaty agent'. Similarly, the 'OVN Controller Gatewaty agent' cannot be turned into 'OVN Controller agent' without restarting the neutron service. ** Affects: neutron Importance: Undecided Status: New ** Tags: ovn ** Tags added: ovn -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1934420 Title: [OVN]ControllerAgent cannot be changed to ControllerGatewayAgent dynamically Status in neutron: New Bug description: I have 3 nodes. NodeA, NodeB, NodeC. I execute cmd 'ovs-vsctl set open_vswitch . external-ids:ovn-cms- options=enable-chassis-as-gw' in NodeA and NodeV, as gateway Node. show agent list by executing the command 'openstack network agent list': NodeA is 'OVN Controller Gatewaty agent' NodeB is 'OVN Controller Gatewaty agent' NodeC is 'OVN Controller agent' the result is the same as I expected. next I execute cmd 'ovs-vsctl set open_vswitch . external-ids:ovn-cms- options=enable-chassis-as-gw' in NodeC, show agent list by executing the command 'openstack network agent list': NodeA is 'OVN Controller Gatewaty agent' NodeB is 'OVN Controller Gatewaty agent' NodeC is 'OVN Controller agent' The NodeC is still 'OVN Controller agent', not 'OVN Controller Gatewaty agent', The command has been executed many times and the result is still unchanged. But as long as I execute the command to restart the neutron service, the result will be correct. NodeC is 'OVN Controller Gatewaty agent'. Similarly, the 'OVN Controller Gatewaty agent' cannot be turned into 'OVN Controller agent' without restarting the neutron service. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1934420/+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 1934412] [NEW] Find none logs when not fitting numa topology in nova-compute log
Public bug reported: Description === When 'host_topology' can not be satified with 'requested_topology', nova-compute returns the msg to nova-conductor but there is no logs in nova-compute.log. Thouth there are some debug logs, but `debug` configuration is not be set to true in production environment. So the warning log should be added. Steps to reproduce == * Set flavor with hugepage and total ram that exceeds the limit configured on the node openstack flavor create --vcpus 2 --ram 3000 --disk 10 --property hw:mem_page_size=2MB flv-2MB-huge On the node: vm.nr_hugepages = 20480 * Create one vm with the flavor openstack server create --image 1512209c-83ca-4a64-aab5-973120e61718 --flavor flv-2MB-huge --network 44dc3e3e-5146-458b-b9b9-6b65e5282efc --availability-zone ::compute01 test-vm Expected result === Find failed logs in nova-compute.log Actual result = Find no logs, and the failed logs can be found in nova-conductor.log Environment === Libvirt + KVM nova: $ git log commit 90455cdae3fae5289b07ae284db0f96e0544d9d2 (HEAD -> stable/wallaby, origin/stable/wallaby) Merge: 97c3517e7e 5d65680095 Author: Zuul Date: Sun Jun 27 07:27:03 2021 + Merge "libvirt: Set driver_iommu when attaching virtio devices to SEV instance" into stable/wallaby ** 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/1934412 Title: Find none logs when not fitting numa topology in nova-compute log Status in OpenStack Compute (nova): New Bug description: Description === When 'host_topology' can not be satified with 'requested_topology', nova-compute returns the msg to nova-conductor but there is no logs in nova-compute.log. Thouth there are some debug logs, but `debug` configuration is not be set to true in production environment. So the warning log should be added. Steps to reproduce == * Set flavor with hugepage and total ram that exceeds the limit configured on the node openstack flavor create --vcpus 2 --ram 3000 --disk 10 --property hw:mem_page_size=2MB flv-2MB-huge On the node: vm.nr_hugepages = 20480 * Create one vm with the flavor openstack server create --image 1512209c-83ca-4a64-aab5-973120e61718 --flavor flv-2MB-huge --network 44dc3e3e-5146-458b-b9b9-6b65e5282efc --availability-zone ::compute01 test-vm Expected result === Find failed logs in nova-compute.log Actual result = Find no logs, and the failed logs can be found in nova-conductor.log Environment === Libvirt + KVM nova: $ git log commit 90455cdae3fae5289b07ae284db0f96e0544d9d2 (HEAD -> stable/wallaby, origin/stable/wallaby) Merge: 97c3517e7e 5d65680095 Author: Zuul Date: Sun Jun 27 07:27:03 2021 + Merge "libvirt: Set driver_iommu when attaching virtio devices to SEV instance" into stable/wallaby To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1934412/+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 1915255] Re: [Victoria] nova-compute won't start on aarch64 - raises PciDeviceNotFoundById
Reviewed: https://review.opendev.org/c/openstack/nova/+/777679 Committed: https://opendev.org/openstack/nova/commit/a569a51fedd058fdae2eb0066e087c37688987f8 Submitter: "Zuul (22348)" Branch:master commit a569a51fedd058fdae2eb0066e087c37688987f8 Author: Sean Mooney Date: Fri May 21 14:45:45 2021 +0100 fix sr-iov support on Cavium ThunderX hosts. This change is a partial revert of Ibf8dca4bd57b3bddb39955b53cc03564506f5754 to reintoduce a try-except which is required for some non standard hardware. On the Cavium ThunderX platform, it's possible to have virutal functions which are netdevs which are not associated to a PF. This causes the PF name lookup to fail. Prior to Ibf8dca4bd57b3bddb39955b53cc03564506f5754 when the lookup failed it was caught and we skipped populating the parent PF interface name. This change restores that behavior. Closes-Bug: #1915255 Change-Id: Ia10ccdd9fbed3870d0592e3cbbff17f292651dd2 ** 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/1915255 Title: [Victoria] nova-compute won't start on aarch64 - raises PciDeviceNotFoundById Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) victoria series: Triaged Bug description: Description === When deploying OpenStack Victoria on Ubuntu 20.04 (Focal) on arm64/aarch64, nova-compute 22.0.1 fails to start with (nova- compute.log): -- Traceback (most recent call last): File "/usr/lib/python3/dist-packages/nova/pci/utils.py", line 156, in get_ifname_by_pci_address dev_info = os.listdir(dev_path) FileNotFoundError: [Errno 2] No such file or directory: '/sys/bus/pci/devices/0002:01:00.1/physfn/net' During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/usr/lib/python3/dist-packages/nova/compute/manager.py", line 9823, in _update_available_resource_for_node self.rt.update_available_resource(context, nodename, File "/usr/lib/python3/dist-packages/nova/compute/resource_tracker.py", line 880, in update_available_resource resources = self.driver.get_available_resource(nodename) File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 8473, in get_available_resource data['pci_passthrough_devices'] = self._get_pci_passthrough_devices() File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 7223, in _get_pci_passthrough_devices pci_info = [self._get_pcidev_info(name, dev, net_devs) for name, dev File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 7223, in pci_info = [self._get_pcidev_info(name, dev, net_devs) for name, dev File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 7199, in _get_pcidev_info device.update(_get_device_type(cfgdev, address, dev, net_devs)) File "/usr/lib/python3/dist-packages/nova/virt/libvirt/driver.py", line 7154, in _get_device_type parent_ifname = pci_utils.get_ifname_by_pci_address( File "/usr/lib/python3/dist-packages/nova/pci/utils.py", line 159, in get_ifname_by_pci_address raise exception.PciDeviceNotFoundById(id=pci_addr) nova.exception.PciDeviceNotFoundById: PCI device 0002:01:00.1 not found -- This results in an empty `openstack hypervisor list`. This does not happen with OpenStack Ussuri (nova-compute 21.1.0). We also haven't seen this on other architectures (yet?). This code actually appeared between Ussuri and Victoria, [0] i.e. the first version having it is 22.0.0. $ lspci | grep 0002:01:00.1 0002:01:00.1 Ethernet controller: Cavium, Inc. THUNDERX Network Interface Controller virtual function (rev 09) Indeed /sys/bus/pci/devices/0002:01:00.1/physfn/ doesn't contain `net` but I'm not sure if that's really a problem or if nova-compute should just catch the exception and move on? A similar issue in the past [1] shows that this might be an issue specific to the Cavium Thunder X NIC. Related issue: [2] Steps to reproduce == Install and run nova >= 22.0.0 on an aarch64 machine (with a Cavium Thunder X NIC if possible). I personally use Juju [3] for deploying an entire OpenStack Victoria setup to a lab: $ git clone https://github.com/openstack-charmers/openstack-bundles $ cd openstack-bundles/development/openstack-base-focal-victoria/ $ juju deploy ./bundle.yaml Expected result === `openstack hypervisor list` shows at least one hypervisor. nova-compute.log doesn't contain nova.exception.PciDeviceNotFoundById Actual result = `openstack hypervisor list` doesn't show any hypervisor. nova-compute.log contains nova.exception.PciDeviceN
[Yahoo-eng-team] [Bug 1934389] [NEW] Cannot attach interface to instance
Public bug reported: I am trying to add an interface to an instance. The network I created called net_11 I see this error Error: Unable to attach interface. Details 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-3c8b4f47-597e-475d-b32a-6a093a38ddce) rajai@openstack:~$ openstack network create --provider-physical-network net_11 --provider-network-type flat --external net_11 +---+--+ | Field | Value| +---+--+ | admin_state_up| UP | | availability_zone_hints | | | availability_zones| | | created_at| 2021-07-01T17:13:56Z | | description | | | dns_domain| None | | id| 67fcbebf-d6fc-4089-a830-d4cbc36ec9e5 | | ipv4_address_scope| None | | ipv6_address_scope| None | | is_default| False| | is_vlan_transparent | None | | mtu | 1500 | | name | net_11 | | port_security_enabled | True | | project_id| 9ea4644b29b342d19087c4862c9385b6 | | provider:network_type | flat | | provider:physical_network | net_11 | | provider:segmentation_id | None | | qos_policy_id | None | | revision_number | 1| | router:external | External | | segments | None | | shared| False| | status| ACTIVE | | subnets | | | tags | | | updated_at| 2021-07-01T17:13:56Z | +---+--+ rajai@openstack:~$ openstack subnet create --subnet-range 11.0.0.0/8 --no-dhcp --network net_11 --allocation-pool start=11.0.0.10,end=11.0.0.100 net_11-subnet +--+--+ | Field| Value| +--+--+ | allocation_pools | 11.0.0.10-11.0.0.100 | | cidr | 11.0.0.0/8 | | created_at | 2021-07-01T17:14:24Z | | description | | | dns_nameservers | | | dns_publish_fixed_ip | None | | enable_dhcp | False| | gateway_ip | 11.0.0.1 | | host_routes | | | id | 70ce904d-e992-4f86-8f23-9e9507111df8 | | ip_version | 4| | ipv6_address_mode| None | | ipv6_ra_mode | None | | name | net_11-subnet| | network_id | 67fcbebf-d6fc-4089-a830-d4cbc36ec9e5 | | prefix_length| None | | project_id | 9ea4644b29b342d19087c4862c9385b6 | | revision_number | 0| | segment_id | None | | service_types| | | subnetpool_id| None | | tags | | | updated_at | 2021-07-01T17:14:24Z | +--+--+ rajai@openstack:~$ rajai@openstack:~$ rajai@openstack:~$ rajai@openstack:~$ rajai@openstack:~$ rajai@openstack:~$ rajai@openstack:~$ rajai@openstack:~$ openstack network list +--+-++ | ID | Name| Subnets | +--+-+---
[Yahoo-eng-team] [Bug 1732522] Re: [2.3] Ephemeral boot environment does not renew DHCP leases
** Changed in: cloud-init Status: Incomplete => 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/1732522 Title: [2.3] Ephemeral boot environment does not renew DHCP leases Status in cloud-init: Invalid Status in MAAS: Fix Released Status in cloud-initramfs-tools package in Ubuntu: Confirmed Status in systemd package in Ubuntu: Invalid Bug description: I started commissioning+hardware testing on a machine, and while the machine was testing (for 2hrs+) i noticed that the IP address had disappeared. The machine has the MAC of 00:25:90:4c:e7:9e and IP of 192.168.0.211 from the dynamic range. Checking the MAAS server, I noticed that the IP/MAC was in the ARP table: andreserl@maas:/var/lib/maas/dhcp$ arp -a | grep 211 192-168-9-211.maas (192.168.9.211) at 00:25:90:4c:e7:9e [ether] on bond-lan Checking the leases file has the following: http://pastebin.ubuntu.com/25969442/ Then I checked a couple areas of MAAS: - Device discovery, the machine wasn't there. - Subnet details page, the machine wasn't there (e.g. as observed) To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1732522/+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 1934301] Re: neutron-lib pep8 is failing with pylint >= 2.9.0
Reviewed: https://review.opendev.org/c/openstack/neutron-lib/+/799055 Committed: https://opendev.org/openstack/neutron-lib/commit/303258fbfc8be361c1ec7ab2c4d292336b490dfc Submitter: "Zuul (22348)" Branch:master commit 303258fbfc8be361c1ec7ab2c4d292336b490dfc Author: Przemyslaw Szczerbik Date: Thu Jul 1 14:48:21 2021 +0200 Fix pep8 check With pylint >= 2.9.0 neutron-lib pep8 fails with following error: neutron_lib/api/extensions.py:256:4: W0237: Parameter 'extended_attributes' has been renamed to 'attributes' in overridden 'APIExtensionDescriptor.update_attributes_map' method (arguments-renamed) Closes-Bug: #1934301 Change-Id: Ia3fb78cda862f730b51775fa48eec673d971c93b ** 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/1934301 Title: neutron-lib pep8 is failing with pylint >= 2.9.0 Status in neutron: Fix Released Bug description: Running pep8 tox environment with pylint >= 2.9.0 fails with following error: neutron_lib/api/extensions.py:256:4: W0237: Parameter 'extended_attributes' has been renamed to 'attributes' in overridden 'APIExtensionDescriptor.update_attributes_map' method (arguments- renamed) The issue is not reproducible with pylint==2.8.3. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1934301/+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 1933517] Re: [RFE][OVN] Create an intermediate OVS bridge between VM and intergration bridge to improve the live-migration process
** Also affects: os-vif 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/1933517 Title: [RFE][OVN] Create an intermediate OVS bridge between VM and intergration bridge to improve the live-migration process Status in neutron: New Status in os-vif: New Bug description: When live migrating network sensitive VMs, the communication is broken. This is similar to [1] but in OVN the vif-plugged events are directly controller by the Neutron server, not by the OVS/DHCP agents. The problem lies in when the destination chassis creates the needed OF rules for the destination VM port. Same as in OVS, the VM port is created when the instance is unpaused. At this moment the VM continues sending packets through the interface but OVN didn't finish the configuration. Related BZs: - OSP16.1: https://bugzilla.redhat.com/show_bug.cgi?id=1903653 - OSP16.1: https://bugzilla.redhat.com/show_bug.cgi?id=1872937 - OSP16.1: https://bugzilla.redhat.com/show_bug.cgi?id=1966512 [1]https://bugs.launchpad.net/neutron/+bug/1901707 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1933517/+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 1934303] [NEW] Debian IPv6 not activated
Public bug reported: I'm launching a Debian 10 image on Openstack Kolla. The VM has static IPv4 and IPv6 addresses. The VM uses DHCP to get its IPv4 address (which works) and cloud-init writes to /etc/network/interfaces.d/50-cloud-init for the static configuration; however, this is not honoured by the system as the original dhcp config in /etc/network/interfaces remains intact. This seems to take precedence over the static configuration. ** Affects: cloud-init Importance: Undecided Status: New ** Attachment added: "cloud-init.tar.gz" https://bugs.launchpad.net/bugs/1934303/+attachment/5508457/+files/cloud-init.tar.gz -- 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/1934303 Title: Debian IPv6 not activated Status in cloud-init: New Bug description: I'm launching a Debian 10 image on Openstack Kolla. The VM has static IPv4 and IPv6 addresses. The VM uses DHCP to get its IPv4 address (which works) and cloud-init writes to /etc/network/interfaces.d/50-cloud-init for the static configuration; however, this is not honoured by the system as the original dhcp config in /etc/network/interfaces remains intact. This seems to take precedence over the static configuration. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1934303/+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 1934301] [NEW] neutron-lib pep8 is failing with pylint >= 2.9.0
Public bug reported: Running pep8 tox environment with pyline >= 2.9.0 fails with following error: neutron_lib/api/extensions.py:256:4: W0237: Parameter 'extended_attributes' has been renamed to 'attributes' in overridden 'APIExtensionDescriptor.update_attributes_map' method (arguments- renamed) The issue is not reproducible with pylint==2.8.3. ** Affects: neutron Importance: Undecided Assignee: Przemyslaw Szczerbik (pszczerbik) Status: Confirmed ** Changed in: neutron Assignee: (unassigned) => Przemyslaw Szczerbik (pszczerbik) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1934301 Title: neutron-lib pep8 is failing with pylint >= 2.9.0 Status in neutron: Confirmed Bug description: Running pep8 tox environment with pyline >= 2.9.0 fails with following error: neutron_lib/api/extensions.py:256:4: W0237: Parameter 'extended_attributes' has been renamed to 'attributes' in overridden 'APIExtensionDescriptor.update_attributes_map' method (arguments- renamed) The issue is not reproducible with pylint==2.8.3. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1934301/+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 1934256] [NEW] neutron-lib duplicates os-resource-classes constants
Public bug reported: The os-resource-classes lib is the official source of the standard placement resource classes. The neutron-lib repo has a copy of those constants[1]. Instead of duplicating the names, neutron-lib could depend on the os-resource-classes lib and import the constants from there[2]. [1] https://github.com/openstack/neutron-lib/blob/63c8443a65db4c662237b8687beff19c3973b819/neutron_lib/placement/constants.py#L20-L21 [2] https://github.com/openstack/os-resource-classes/blob/3aead5dd249d753a85585879ea501e1f4f4bcd17/os_resource_classes/__init__.py#L59-L62 ** Affects: neutron Importance: Undecided Status: New ** Tags: lib low-hanging-fruit ** Tags added: low-hanging-fruit ** Tags added: lib -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1934256 Title: neutron-lib duplicates os-resource-classes constants Status in neutron: New Bug description: The os-resource-classes lib is the official source of the standard placement resource classes. The neutron-lib repo has a copy of those constants[1]. Instead of duplicating the names, neutron-lib could depend on the os-resource-classes lib and import the constants from there[2]. [1] https://github.com/openstack/neutron-lib/blob/63c8443a65db4c662237b8687beff19c3973b819/neutron_lib/placement/constants.py#L20-L21 [2] https://github.com/openstack/os-resource-classes/blob/3aead5dd249d753a85585879ea501e1f4f4bcd17/os_resource_classes/__init__.py#L59-L62 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1934256/+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 1934241] [NEW] snapshot doesn't flush dirty data
Public bug reported: libvirt driver Login a deployed VM and write some files, for example: ``` [lynn@host-172-26-105-43 ~]$ ls -lrt ... -rw-rw-r--. 1 lynn lynn 677 Jun 29 06:30 sum -rw-rw-r--. 1 lynn lynn 38 Jun 29 06:30 sum3.md5 [lynn@host-172-26-105-38 ~]$ ``` then *right* after the file created, trigger the snapshot action of the VM after that, deploy a new VM through the created image found some files missing (e.g sum3.md5 file) ``` [lynn@host-172-26-105-43 ~]$ ls -lrt ... -rw-rw-r--. 1 lynn lynn 648 Jun 29 06:30 sum [lynn@host-172-26-105-43 ~]$ ``` I checked the code and seems no flush operation in live or cold snapshot (cold seems suspend the VM only) https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2952 is it by design or best practice ? ** 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/1934241 Title: snapshot doesn't flush dirty data Status in OpenStack Compute (nova): New Bug description: libvirt driver Login a deployed VM and write some files, for example: ``` [lynn@host-172-26-105-43 ~]$ ls -lrt ... -rw-rw-r--. 1 lynn lynn 677 Jun 29 06:30 sum -rw-rw-r--. 1 lynn lynn 38 Jun 29 06:30 sum3.md5 [lynn@host-172-26-105-38 ~]$ ``` then *right* after the file created, trigger the snapshot action of the VM after that, deploy a new VM through the created image found some files missing (e.g sum3.md5 file) ``` [lynn@host-172-26-105-43 ~]$ ls -lrt ... -rw-rw-r--. 1 lynn lynn 648 Jun 29 06:30 sum [lynn@host-172-26-105-43 ~]$ ``` I checked the code and seems no flush operation in live or cold snapshot (cold seems suspend the VM only) https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L2952 is it by design or best practice ? To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1934241/+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
