[Yahoo-eng-team] [Bug 1925702] [NEW] The created virtual machine state is paused
Public bug reported: openstack version: train controller # openstack server create --flavor m1.nano --image cirros --nic net-id=7611f269-84ab-4759-84db-5b52def82830 --security-group default --key-name mykey selfservice-instance # The log information is too long, I put it in the attachment nova-compute # tail -f /var/log/nova/nova-compute.log nova-compute # virsh list IdName State 2 hg-vm-ceph-mds-55 running （Not managemented by openstack) 3 hg-vm-ceph-mgr-53 running （Not managemented by openstack) 4 hg-vm-ceph-deploy-140 running （Not managemented by openstack) 5 hg-vm-ceph-mon-50 running （Not managemented by openstack) 8 hg-vm-ceph-osd-57 running （Not managemented by openstack) 10hg-vm-openstack-controller-160 running （Not managemented by openstack) 17hg-vm-openstack-common-163 running 19instance-0012 paused ** Affects: nova Importance: Undecided Status: New ** Attachment added: "nova-compute.log" https://bugs.launchpad.net/bugs/1925702/+attachment/5491137/+files/nova-compute.log ** Description changed: openstack version: train controller # openstack server create --flavor m1.nano --image cirros --nic net-id=7611f269-84ab-4759-84db-5b52def82830 --security-group default --key-name mykey selfservice-instance - - nova-compute # tail -f /var/log/nova/nova-compute.log + # The log information is too long, I put it in the attachment + nova-compute # tail -f /var/log/nova/nova-compute.log nova-compute # virsh list - IdName State + IdName State - 2 hg-vm-ceph-mds-55 running （Not managemented by openstack) - 3 hg-vm-ceph-mgr-53 running （Not managemented by openstack) - 4 hg-vm-ceph-deploy-140 running （Not managemented by openstack) - 5 hg-vm-ceph-mon-50 running （Not managemented by openstack) - 8 hg-vm-ceph-osd-57 running （Not managemented by openstack) - 10hg-vm-openstack-controller-160 running （Not managemented by openstack) - 17hg-vm-openstack-common-163 running - 19instance-0012 paused + 2 hg-vm-ceph-mds-55 running （Not managemented by openstack) + 3 hg-vm-ceph-mgr-53 running （Not managemented by openstack) + 4 hg-vm-ceph-deploy-140 running （Not managemented by openstack) + 5 hg-vm-ceph-mon-50 running （Not managemented by openstack) + 8 hg-vm-ceph-osd-57 running （Not managemented by openstack) + 10hg-vm-openstack-controller-160 running （Not managemented by openstack) + 17hg-vm-openstack-common-163 running + 19instance-0012 paused ** Description changed: openstack version: train controller # openstack server create --flavor m1.nano --image cirros --nic net-id=7611f269-84ab-4759-84db-5b52def82830 --security-group default --key-name mykey selfservice-instance - # The log information is too long, I put it in the attachment - nova-compute # tail -f /var/log/nova/nova-compute.log + # The log information is too long, I put it in the attachment + nova-compute # tail -f /var/log/nova/nova-compute.log nova-compute # virsh list IdName State 2 hg-vm-ceph-mds-55 running （Not managemented by openstack) 3 hg-vm-ceph-mgr-53 running （Not managemented by openstack) 4 hg-vm-ceph-deploy-140 running （Not managemented by openstack) 5 hg-vm-ceph-mon-50 running （Not managemented by openstack) 8 hg-vm-ceph-osd-57 running （Not managemented by openstack) 10hg-vm-openstack-controller-160 running （Not managemented by openstack) 17hg-vm-openstack-common-163 running 19instance-0012 paused -- 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/1925702 Title: The created virtual machine state is paused Status in OpenStack Compute (nova): New Bug description: openstack version: train controller # openstack server create --flavor m1.nano --image cirros --nic net-id=7611f269-84ab-4759-84db-5b52def82830 --security-group default --key-name mykey selfservice-instance # The log information is too long, I put it in the attachment nova-compute # tail -f /var/log/nova/nova-compute.log nova-compute # virsh list IdName State 2
[Yahoo-eng-team] [Bug 1925684] [NEW] [spec] X-Project-Id passthrough
Public bug reported: Launchpad bug to track a new Wallaby spec. ** Affects: keystone Importance: Undecided Assignee: Douglas Mendizábal (dougmendizabal) Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1925684 Title: [spec] X-Project-Id passthrough Status in OpenStack Identity (keystone): New Bug description: Launchpad bug to track a new Wallaby spec. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1925684/+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 1925454] Re: Update Ubuntu 20.04 default network-config by cloud-config
I'm marking this bug as Invalid. cloud-init is working as expected for
NoCloud datasource. Changes to the network-config during execution
can't affect cloud-inits behavior during boot with the NoCloud
datasource.
** 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/1925454
Title:
Update Ubuntu 20.04 default network-config by cloud-config
Status in cloud-init:
Invalid
Bug description:
This is a follow-up on the case https://bugs.launchpad.net/cloud-
init/+bug/1924922
I cannot update default Ubuntu network-config by writing user-data
file in cloud-config.
Attached are logs. Below is a snippet from the cloud-config
#cloud-config
write_files:
- path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
permissions: '0644'
content: |
network:
config: disabled
- path: /etc/netplan/50-cloud-init.yaml
permissions: '0644'
content: |
network:
version: 2
ethernets:
eth0:
dhcp4: true
addresses:
- 192.168.53.3/26
gateway4: 192.168.53.62
nameservers:
addresses:
- 1.1.1.1
- 8.8.8.8
runcmd:
- [sudo, netplan, try]
- [sudo, netplan, generate]
- [sudo, netplan, apply]
power_state:
mode: 'reboot'
message: 'reboot triggered by cloud-init'
-
Result is such that the hardcoded network-config ('optional': True, not
waiting for DHCP server) is attached/generated with IP as, for an example -
192.168.53.4, not the IP I really want 192.168.53.3. This leads to couple of
problems, one as specified in bug/1924922, that ssh_import_id is not working
(for the time is not sync up)
Is there a way to overwrite this default with user-data, and not to go to the
config partition and manually change it?
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1925454/+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 1925528] [NEW] Improve "NeutronDbObject.objects_exist" performance
Public bug reported: Current "NeutronDbObject.objects_exist" implementation generates a query (quite complex most of the time) to retrieve an OVO object. That usually implies a large set of register columns, joined queries or subqueries. Then, the method adds the "count" SQL syntagm to return only the number of registers found. This query can be optimized by: - Limiting the number of registers to be retrieved to only one. The goal of the "objects_exist" method is to know if there are objects or not. Finding one is enough - Limiting the complexity of the query by requesting only one column, provided as a method parameter, that could be, for example, the ID. ** Affects: neutron Importance: Wishlist Assignee: Rodolfo Alonso (rodolfo-alonso-hernandez) Status: New ** Changed in: neutron Importance: Undecided => Wishlist ** Changed in: neutron Assignee: (unassigned) => Rodolfo Alonso (rodolfo-alonso-hernandez) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1925528 Title: Improve "NeutronDbObject.objects_exist" performance Status in neutron: New Bug description: Current "NeutronDbObject.objects_exist" implementation generates a query (quite complex most of the time) to retrieve an OVO object. That usually implies a large set of register columns, joined queries or subqueries. Then, the method adds the "count" SQL syntagm to return only the number of registers found. This query can be optimized by: - Limiting the number of registers to be retrieved to only one. The goal of the "objects_exist" method is to know if there are objects or not. Finding one is enough - Limiting the complexity of the query by requesting only one column, provided as a method parameter, that could be, for example, the ID. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1925528/+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 1919177] Re: Azure: issues with accelerated networking on Hirsute
** Also affects: systemd (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to cloud-init.
https://bugs.launchpad.net/bugs/1919177
Title:
Azure: issues with accelerated networking on Hirsute
Status in cloud-init:
Incomplete
Status in cloud-init package in Ubuntu:
New
Status in linux-azure package in Ubuntu:
New
Status in systemd package in Ubuntu:
New
Bug description:
[General]
On Azure, when provisioning a Hirsute VM with Accelerated Networking
enabled, sometimes part of the cloud-init configuration is not
applied.
Especially, in those cases, the public SSH key is not setup properly.
[how to reproduce]
Start a VM with AN enabled:
```
az vm create --name "$VM_NAME --resource-group "$GROUP" --location "UK South"
--image
'Canonical:0001-com-ubuntu-server-hirsute-daily:21_04-daily-gen2:latest' --size
Standard_F8s_v2 --admin-username ubuntu --ssh-key-value "$SSH_KEY"
--accelerated-networking
```
After a moment, try to SSH: if you succeed, delete and recreate a new
VM.
[troubleshooting]
To be able to connect into the VM, run:
az vm run-command invoke -g "$GROUP" -n "$VM_NAME" --command-id
RunShellScript --scripts "sudo -u ubuntu ssh-import-id $LP_USERNAME"
```
In "/run/cloud-init/instance-data.json", I can see:
```
"publicKeys": [
{
"keyData": "",
"path": "/home/ubuntu/.ssh/authorized_keys"
}
],
```
as expected.
[workaround]
As mentioned, Azure allows the user to run command into the VM without
SSH connection. To do so, one can use the Azure CLI:
az vm run-command invoke -g "$GROUP" -n "$VM_NAME" --command-id
RunShellScript --scripts "sudo -u ubuntu ssh-import-id $LP_USERNAME"
This example uses "ssh-import-id" but it's also possible to just echo
a given public key into /home/ubuntu/.ssh/authorized_keys
NOTE: this will only solves the SSH issue, I do not know if this bug
affects other things. If so the user would have to apply those things
manually.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1919177/+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 1925498] [NEW] SNAT is not working
Public bug reported: Centos 8.3, Openstack Ussuri. I have 3 controllers node and 2 network nodes. I'm using self-service network with linuxbridge. The SNAT is not working. A tcpdump (in the destination) shows that the ip is not being masquerade. If I assing a floating IP, everything works. Here is the router iptables: # Generated by iptables-save v1.8.4 on Thu Apr 22 09:30:43 2021 *filter :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :neutron-filter-top - [0:0] :neutron-l3-agent-FORWARD - [0:0] :neutron-l3-agent-INPUT - [0:0] :neutron-l3-agent-OUTPUT - [0:0] :neutron-l3-agent-local - [0:0] :neutron-l3-agent-scope - [0:0] -A INPUT -j neutron-l3-agent-INPUT -A FORWARD -j neutron-filter-top -A FORWARD -j neutron-l3-agent-FORWARD -A OUTPUT -j neutron-filter-top -A OUTPUT -j neutron-l3-agent-OUTPUT -A neutron-filter-top -j neutron-l3-agent-local -A neutron-l3-agent-FORWARD -j neutron-l3-agent-scope -A neutron-l3-agent-INPUT -m mark --mark 0x1/0x -j ACCEPT -A neutron-l3-agent-INPUT -p tcp -m tcp --dport 9697 -j DROP -A neutron-l3-agent-scope -o qr-ba03dc8a-87 -m mark ! --mark 0x401/0x -j DROP COMMIT # Completed on Thu Apr 22 09:30:43 2021 # Generated by iptables-save v1.8.4 on Thu Apr 22 09:30:43 2021 *mangle :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :FORWARD ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :neutron-l3-agent-FORWARD - [0:0] :neutron-l3-agent-INPUT - [0:0] :neutron-l3-agent-OUTPUT - [0:0] :neutron-l3-agent-POSTROUTING - [0:0] :neutron-l3-agent-PREROUTING - [0:0] :neutron-l3-agent-float-snat - [0:0] :neutron-l3-agent-floatingip - [0:0] :neutron-l3-agent-mark - [0:0] :neutron-l3-agent-scope - [0:0] -A PREROUTING -j neutron-l3-agent-PREROUTING -A INPUT -j neutron-l3-agent-INPUT -A FORWARD -j neutron-l3-agent-FORWARD -A OUTPUT -j neutron-l3-agent-OUTPUT -A POSTROUTING -j neutron-l3-agent-POSTROUTING -A neutron-l3-agent-POSTROUTING -o qg-33922118-c1 -m connmark --mark 0x0/0x -j CONNMARK --save-mark --nfmask 0x --ctmask 0x -A neutron-l3-agent-PREROUTING -j neutron-l3-agent-mark -A neutron-l3-agent-PREROUTING -j neutron-l3-agent-scope -A neutron-l3-agent-PREROUTING -m connmark ! --mark 0x0/0x -j CONNMARK --restore-mark --nfmask 0x --ctmask 0x -A neutron-l3-agent-PREROUTING -j neutron-l3-agent-floatingip -A neutron-l3-agent-PREROUTING -d 169.254.169.254/32 -i qr-+ -p tcp -m tcp --dport 80 -j MARK --set-xmark 0x1/0x -A neutron-l3-agent-float-snat -m connmark --mark 0x0/0x -j CONNMARK --save-mark --nfmask 0x --ctmask 0x -A neutron-l3-agent-mark -i qg-33922118-c1 -j MARK --set-xmark 0x2/0x -A neutron-l3-agent-scope -i qr-ba03dc8a-87 -j MARK --set-xmark 0x401/0x -A neutron-l3-agent-scope -i qg-33922118-c1 -j MARK --set-xmark 0x401/0x COMMIT # Completed on Thu Apr 22 09:30:43 2021 # Generated by iptables-save v1.8.4 on Thu Apr 22 09:30:43 2021 *nat :PREROUTING ACCEPT [0:0] :INPUT ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :neutron-l3-agent-OUTPUT - [0:0] :neutron-l3-agent-POSTROUTING - [0:0] :neutron-l3-agent-PREROUTING - [0:0] :neutron-l3-agent-float-snat - [0:0] :neutron-l3-agent-snat - [0:0] :neutron-postrouting-bottom - [0:0] -A PREROUTING -j neutron-l3-agent-PREROUTING -A POSTROUTING -j neutron-l3-agent-POSTROUTING -A POSTROUTING -j neutron-postrouting-bottom -A OUTPUT -j neutron-l3-agent-OUTPUT -A neutron-l3-agent-POSTROUTING ! -o qg-33922118-c1 -m conntrack ! --ctstate DNAT -j ACCEPT -A neutron-l3-agent-PREROUTING -d 169.254.169.254/32 -i qr-+ -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 9697 -A neutron-l3-agent-snat -j neutron-l3-agent-float-snat -A neutron-l3-agent-snat -o qg-33922118-c1 -m connmark --mark 0x401/0x -j ACCEPT -A neutron-l3-agent-snat -o qg-33922118-c1 -j SNAT --to-source X.X.X.X --random-fully -A neutron-l3-agent-snat -m mark ! --mark 0x2/0x -m conntrack --ctstate DNAT -j SNAT --to-source X.X.X.X --random-fully -A neutron-postrouting-bottom -m comment --comment "Perform source NAT on outgoing traffic." -j neutron-l3-agent-snat COMMIT # Completed on Thu Apr 22 09:30:43 2021 # Generated by iptables-save v1.8.4 on Thu Apr 22 09:30:43 2021 *raw :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] :neutron-l3-agent-OUTPUT - [0:0] :neutron-l3-agent-PREROUTING - [0:0] -A PREROUTING -j neutron-l3-agent-PREROUTING -A OUTPUT -j neutron-l3-agent-OUTPUT COMMIT # Completed on Thu Apr 22 09:30:43 2021 ** 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/1925498 Title: SNAT is not working Status in neutron: New Bug description: Centos 8.3, Openstack Ussuri. I have 3 controllers node and 2 network nodes. I'm using self-service network with linuxbridge. The SNAT is not working. A tcpdump (in the destination) shows that the
[Yahoo-eng-team] [Bug 1925494] [NEW] Section on configuring x86_64=q35 in hypervisor-kvm.html is gone
Public bug reported: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [x] This doc is inaccurate in this way: Section on configuring x86_64=q35 disappeared from train to latest versions of the doc - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - The mailing list: https://lists.openstack.org - IRC: 'openstack' channel on Freenode Steps to reproduce: 1. search for x86_64=q35 in https://docs.openstack.org/nova/train/admin/configuration/hypervisor-kvm.html 2. search for x86_64=q35 in https://docs.openstack.org/nova/latest/admin/configuration/hypervisor-kvm.html --- Release: 23.1.0.dev74 on 2021-02-23 10:21:55 SHA: 21b376a42446315471b583ed8ee875dbfa115a58 Source: https://opendev.org/openstack/nova/src/doc/source/admin/configuration/hypervisor-kvm.rst URL: https://docs.openstack.org/nova/latest/admin/configuration/hypervisor-kvm.html ** Affects: nova Importance: Undecided Status: New ** Tags: doc -- 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/1925494 Title: Section on configuring x86_64=q35 in hypervisor-kvm.html is gone Status in OpenStack Compute (nova): New Bug description: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [x] This doc is inaccurate in this way: Section on configuring x86_64=q35 disappeared from train to latest versions of the doc - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. If you have a troubleshooting or support issue, use the following resources: - The mailing list: https://lists.openstack.org - IRC: 'openstack' channel on Freenode Steps to reproduce: 1. search for x86_64=q35 in https://docs.openstack.org/nova/train/admin/configuration/hypervisor-kvm.html 2. search for x86_64=q35 in https://docs.openstack.org/nova/latest/admin/configuration/hypervisor-kvm.html --- Release: 23.1.0.dev74 on 2021-02-23 10:21:55 SHA: 21b376a42446315471b583ed8ee875dbfa115a58 Source: https://opendev.org/openstack/nova/src/doc/source/admin/configuration/hypervisor-kvm.rst URL: https://docs.openstack.org/nova/latest/admin/configuration/hypervisor-kvm.html To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1925494/+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 1925433] Re: [doc] SR-IOV config documentation has not been updated when SRIOV attach got implemented
Reviewed: https://review.opendev.org/c/openstack/neutron/+/787500 Committed: https://opendev.org/openstack/neutron/commit/947e8a041c22c97bf342b1498b837a5c3f553d95 Submitter: "Zuul (22348)" Branch:master commit 947e8a041c22c97bf342b1498b837a5c3f553d95 Author: Balazs Gibizer Date: Thu Apr 22 09:39:44 2021 +0200 Remove SRIOV attach limitation from the doc Since I67504a37b0fe2ae5da3cba2f3122d9d0e18b9481 Nova supports attaching neutron ports backed by PCI devices. So the limitation can be removed from the doc. Closes-Bug: #1925433 Change-Id: I44e573bd55e3631901d782d6d65987a58ca3e4fb ** 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/1925433 Title: [doc] SR-IOV config documentation has not been updated when SRIOV attach got implemented Status in neutron: Fix Released Bug description: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [x] This doc is inaccurate in this way: When the support for SRIOV interface attach was implemented in Victoria with [1] the limitation from the neutron doc wasn't removed. This impacts Victoria, Wallaby and master - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. [1] https://review.opendev.org/c/openstack/nova/+/740995/17 --- Release: 17.1.2.dev40 on 2020-06-11 17:02:41 SHA: 7cc94725bcfcc2364d3b7d0febaa50c5b0b36683 Source: https://opendev.org/openstack/neutron/src/doc/source/admin/config-sriov.rst URL: https://docs.openstack.org/neutron/victoria/admin/config-sriov.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1925433/+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 1340197] Re: Horizon doesn't notify when fail to attach a volume
Hi, this bug looks quite old. I am not able to reproduce it in the master branch. Please find below the steps how I tried to reproduce it: 1. I have updated the status for a volume(name= test). 2. Then If I try to attach to a nova instance, I get an error in the horizon. I have also attached a screenshot for the same. So I am changing this bug status to invalid. Feel free to open it if you are still facing the same issue and add the steps to reproduce it. ** Attachment added: "bug.PNG" https://bugs.launchpad.net/horizon/+bug/1340197/+attachment/5490975/+files/bug.PNG ** Changed in: horizon Status: New => Invalid ** Changed in: horizon Importance: Wishlist => Undecided -- 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/1340197 Title: Horizon doesn't notify when fail to attach a volume Status in OpenStack Dashboard (Horizon): Invalid Bug description: Description of problem: Horizon doesn't notify when the attachment of volume process fail with Errors. The nova-compute log show errors during the process of the volume attachment but the Horizon doesn't present the failure and the error. Version-Release number of selected component (if applicable): python-django-horizon-2014.1-7.el7ost.noarch openstack-nova-network-2014.1-7.el7ost.noarch python-novaclient-2.17.0-2.el7ost.noarch openstack-nova-common-2014.1-7.el7ost.noarch openstack-nova-compute-2014.1-7.el7ost.noarch openstack-nova-conductor-2014.1-7.el7ost.noarch openstack-nova-scheduler-2014.1-7.el7ost.noarch openstack-nova-api-2014.1-7.el7ost.noarch openstack-nova-cert-2014.1-7.el7ost.noarch openstack-nova-novncproxy-2014.1-7.el7ost.noarch python-nova-2014.1-7.el7ost.noarch openstack-nova-console-2014.1-7.el7ost.noarch How reproducible: 100% Steps to Reproduce: 1. Follow the step of the bug: https://bugs.launchpad.net/nova/+bug/1340169 2. In the Horizon try to attach a volume Actual results: The Horizon shows an info message: Info: Attaching volume bowl-the-dust to instance cougar-01-fe5510a5-c50c-46ee-9d71-6f8e41a58ecc on /dev/vdc. The volume status changes to 'attaching' then change back to available. Expected results: An error should appear saying "Error: the volume attachment failed" Additional info: The Horizon log is attached. The nova-compute log with the volume attachment error is available in the bug https://bugs.launchpad.net/nova/+bug/1340169 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1340197/+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 1925454] [NEW] Update Ubuntu 20.04 default network-config by cloud-config
Public bug reported:
This is a follow-up on the case https://bugs.launchpad.net/cloud-
init/+bug/1924922
I cannot update default Ubuntu network-config by writing user-data file
in cloud-config.
Attached are logs. Below is a snippet from the cloud-config
#cloud-config
write_files:
- path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
permissions: '0644'
content: |
network:
config: disabled
- path: /etc/netplan/50-cloud-init.yaml
permissions: '0644'
content: |
network:
version: 2
ethernets:
eth0:
dhcp4: true
addresses:
- 192.168.53.3/26
gateway4: 192.168.53.62
nameservers:
addresses:
- 1.1.1.1
- 8.8.8.8
runcmd:
- [sudo, netplan, try]
- [sudo, netplan, generate]
- [sudo, netplan, apply]
power_state:
mode: 'reboot'
message: 'reboot triggered by cloud-init'
-
Result is such that the hardcoded network-config ('optional': True, not waiting
for DHCP server) is attached/generated with IP as, for an example -
192.168.53.4, not the IP I really want 192.168.53.3. This leads to couple of
problems, one as specified in bug/1924922, that ssh_import_id is not working
(for the time is not sync up)
Is there a way to overwrite this default with user-data, and not to go to the
config partition and manually change it?
** Affects: cloud-init
Importance: Undecided
Status: New
** Attachment added: "cloud-init.tar.gz"
https://bugs.launchpad.net/bugs/1925454/+attachment/5490924/+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/1925454
Title:
Update Ubuntu 20.04 default network-config by cloud-config
Status in cloud-init:
New
Bug description:
This is a follow-up on the case https://bugs.launchpad.net/cloud-
init/+bug/1924922
I cannot update default Ubuntu network-config by writing user-data
file in cloud-config.
Attached are logs. Below is a snippet from the cloud-config
#cloud-config
write_files:
- path: /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg
permissions: '0644'
content: |
network:
config: disabled
- path: /etc/netplan/50-cloud-init.yaml
permissions: '0644'
content: |
network:
version: 2
ethernets:
eth0:
dhcp4: true
addresses:
- 192.168.53.3/26
gateway4: 192.168.53.62
nameservers:
addresses:
- 1.1.1.1
- 8.8.8.8
runcmd:
- [sudo, netplan, try]
- [sudo, netplan, generate]
- [sudo, netplan, apply]
power_state:
mode: 'reboot'
message: 'reboot triggered by cloud-init'
-
Result is such that the hardcoded network-config ('optional': True, not
waiting for DHCP server) is attached/generated with IP as, for an example -
192.168.53.4, not the IP I really want 192.168.53.3. This leads to couple of
problems, one as specified in bug/1924922, that ssh_import_id is not working
(for the time is not sync up)
Is there a way to overwrite this default with user-data, and not to go to the
config partition and manually change it?
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1925454/+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 1925451] [NEW] [stable/rocky] grenade job is broken
Public bug reported:
I just saw in the neutron-grenade job in stable/rocky branch error like:
2021-04-22 08:11:54.188 | Complete output from command python setup.py
egg_info:
2021-04-22 08:11:54.188 | Couldn't find index page for 'pbr' (maybe
misspelled?)
2021-04-22 08:11:54.188 | No local packages or download links found for
pbr>=1.8
2021-04-22 08:11:54.188 | Traceback (most recent call last):
2021-04-22 08:11:54.188 | File "", line 1, in
2021-04-22 08:11:54.188 | File
"/tmp/pip-build-9jeigq7n/devstack-tools/setup.py", line 29, in
2021-04-22 08:11:54.188 | pbr=True)
2021-04-22 08:11:54.188 | File "/usr/lib/python3.5/distutils/core.py",
line 108, in setup
2021-04-22 08:11:54.188 | _setup_distribution = dist = klass(attrs)
2021-04-22 08:11:54.188 | File
"/usr/lib/python3/dist-packages/setuptools/dist.py", line 269, in __init__
2021-04-22 08:11:54.188 | self.fetch_build_eggs(attrs['setup_requires'])
2021-04-22 08:11:54.188 | File
"/usr/lib/python3/dist-packages/setuptools/dist.py", line 313, in
fetch_build_eggs
2021-04-22 08:11:54.188 | replace_conflicting=True,
2021-04-22 08:11:54.188 | File
"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 826, in resolve
2021-04-22 08:11:54.188 | dist = best[req.key] = env.best_match(req,
ws, installer)
2021-04-22 08:11:54.188 | File
"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1092, in
best_match
2021-04-22 08:11:54.188 | return self.obtain(req, installer)
2021-04-22 08:11:54.188 | File
"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1104, in obtain
2021-04-22 08:11:54.188 | return installer(requirement)
2021-04-22 08:11:54.188 | File
"/usr/lib/python3/dist-packages/setuptools/dist.py", line 380, in
fetch_build_egg
2021-04-22 08:11:54.188 | return cmd.easy_install(req)
2021-04-22 08:11:54.188 | File
"/usr/lib/python3/dist-packages/setuptools/command/easy_install.py", line 657,
in easy_install
2021-04-22 08:11:54.188 | raise DistutilsError(msg)
2021-04-22 08:11:54.188 | distutils.errors.DistutilsError: Could not find
suitable distribution for Requirement.parse('pbr>=1.8')
Failure in
https://447f476affa473a2-ba0bbef8fa5bd9d33ddbd8694210833c.ssl.cf5.rackcdn.com/777123/4/check
/neutron-grenade/e900d19/logs/grenade.sh.txt
** Affects: neutron
Importance: Critical
Status: New
** Tags: gate-failure grenade
** Changed in: neutron
Status: Confirmed => 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/1925451
Title:
[stable/rocky] grenade job is broken
Status in neutron:
New
Bug description:
I just saw in the neutron-grenade job in stable/rocky branch error
like:
2021-04-22 08:11:54.188 | Complete output from command python setup.py
egg_info:
2021-04-22 08:11:54.188 | Couldn't find index page for 'pbr' (maybe
misspelled?)
2021-04-22 08:11:54.188 | No local packages or download links found for
pbr>=1.8
2021-04-22 08:11:54.188 | Traceback (most recent call last):
2021-04-22 08:11:54.188 | File "", line 1, in
2021-04-22 08:11:54.188 | File
"/tmp/pip-build-9jeigq7n/devstack-tools/setup.py", line 29, in
2021-04-22 08:11:54.188 | pbr=True)
2021-04-22 08:11:54.188 | File "/usr/lib/python3.5/distutils/core.py",
line 108, in setup
2021-04-22 08:11:54.188 | _setup_distribution = dist = klass(attrs)
2021-04-22 08:11:54.188 | File
"/usr/lib/python3/dist-packages/setuptools/dist.py", line 269, in __init__
2021-04-22 08:11:54.188 |
self.fetch_build_eggs(attrs['setup_requires'])
2021-04-22 08:11:54.188 | File
"/usr/lib/python3/dist-packages/setuptools/dist.py", line 313, in
fetch_build_eggs
2021-04-22 08:11:54.188 | replace_conflicting=True,
2021-04-22 08:11:54.188 | File
"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 826, in resolve
2021-04-22 08:11:54.188 | dist = best[req.key] = env.best_match(req,
ws, installer)
2021-04-22 08:11:54.188 | File
"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1092, in
best_match
2021-04-22 08:11:54.188 | return self.obtain(req, installer)
2021-04-22 08:11:54.188 | File
"/usr/lib/python3/dist-packages/pkg_resources/__init__.py", line 1104, in obtain
2021-04-22 08:11:54.188 | return installer(requirement)
2021-04-22 08:11:54.188 | File
"/usr/lib/python3/dist-packages/setuptools/dist.py", line 380, in
fetch_build_egg
2021-04-22 08:11:54.188 | return cmd.easy_install(req)
2021-04-22 08:11:54.188 | File
"/usr/lib/python3/dist-packages/setuptools/command/easy_install.py", line 657,
in easy_install
2021-04-22 08:11:54.188 | raise DistutilsError(msg)
[Yahoo-eng-team] [Bug 1925213] Re: o-api seems to leak memory when ovn-octavia-provider is used
Let me put this into invalid, I realized it was an amphora LB being hit with constant updates and now I don't see this issue on my env. ** Changed in: neutron Status: Incomplete => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1925213 Title: o-api seems to leak memory when ovn-octavia-provider is used Status in neutron: Invalid Bug description: I left my DevStack env for a several days to see the following: stack@mdulko-devstack-ovnvm-0:~$ free -m totalusedfree shared buff/cache available Mem: 16039 15407 132 375 499 22 Swap: 0 0 0 htop confirmed me that this is o-api taking that and restarting it helped immediately: stack@mdulko-devstack-ovnvm-0:~$ sudo systemctl kill devstack@o-api stack@mdulko-devstack-ovnvm-0:~$ sudo systemctl restart devstack@o-api stack@mdulko-devstack-ovnvm-0:~$ free -h totalusedfree shared buff/cache available Mem:15G8.4G6.3G375M1.0G 6.7G Swap:0B 0B 0B This was an env running kuryr-kubernetes that happened to have a bug that kept setting the listener timeouts for the LB all the time. I guess this might have had contributed to the problem. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1925213/+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 1925433] [NEW] [doc] SR-IOV config documentation has not been updated when SRIOV attach got implemented
Public bug reported: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [x] This doc is inaccurate in this way: When the support for SRIOV interface attach was implemented in Victoria with [1] the limitation from the neutron doc wasn't removed. This impacts Victoria, Wallaby and master - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. [1] https://review.opendev.org/c/openstack/nova/+/740995/17 --- Release: 17.1.2.dev40 on 2020-06-11 17:02:41 SHA: 7cc94725bcfcc2364d3b7d0febaa50c5b0b36683 Source: https://opendev.org/openstack/neutron/src/doc/source/admin/config-sriov.rst URL: https://docs.openstack.org/neutron/victoria/admin/config-sriov.html ** Affects: neutron Importance: Undecided Assignee: Balazs Gibizer (balazs-gibizer) Status: New ** Tags: doc ** Changed in: neutron Assignee: (unassigned) => Balazs Gibizer (balazs-gibizer) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1925433 Title: [doc] SR-IOV config documentation has not been updated when SRIOV attach got implemented Status in neutron: New Bug description: This bug tracker is for errors with the documentation, use the following as a template and remove or add fields as you see fit. Convert [ ] into [x] to check boxes: - [x] This doc is inaccurate in this way: When the support for SRIOV interface attach was implemented in Victoria with [1] the limitation from the neutron doc wasn't removed. This impacts Victoria, Wallaby and master - [ ] This is a doc addition request. - [ ] I have a fix to the document that I can paste below including example: input and output. [1] https://review.opendev.org/c/openstack/nova/+/740995/17 --- Release: 17.1.2.dev40 on 2020-06-11 17:02:41 SHA: 7cc94725bcfcc2364d3b7d0febaa50c5b0b36683 Source: https://opendev.org/openstack/neutron/src/doc/source/admin/config-sriov.rst URL: https://docs.openstack.org/neutron/victoria/admin/config-sriov.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1925433/+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 1916428] Re: dibbler tool for dhcpv6 is concluded
** Changed in: neutron Status: Opinion => Confirmed ** Changed in: neutron Importance: Undecided => Medium -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1916428 Title: dibbler tool for dhcpv6 is concluded Status in neutron: Confirmed Bug description: Hi team, according to the latest annoucement of https://github.com/tomaszmrugalski/dibbler, seems the said project is concluded by lacking maintainers, and I also found the said tools have been as the Ipv6 dhcp default implementation. The author suggest https://gitlab.isc.org/isc-projects/kea . Is there any plan for this in Neutron team? Thanks very much To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1916428/+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
