[Yahoo-eng-team] [Bug 1956788] Re: system_cfg not read on Oracle datasource
This bug is believed to be fixed in cloud-init in version 23.2. If this is still a problem for you, please make a comment and set the state back to New Thank you. ** Changed in: cloud-init Status: Fix Committed => 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/1956788 Title: system_cfg not read on Oracle datasource Status in cloud-init: Fix Released Bug description: In https://github.com/canonical/cloud- init/commit/2c52e6e88b19f5db8d55eb7280ee27703e05d75f , the order of reading network config was changed for Oracle due to initramfs needing to take lower precedence than the datasource. However, this also bumped system_cfg to a lower precedence than ds, which means that any network configuration specified in /etc/cloud will not be applied. system_cfg should instead be moved above ds so network configuration in /etc/cloud takes precedence. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1956788/+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 2008888] Re: RuntimeError: duplicate mac found! both 'wwan1' and 'wwan0'
This bug is believed to be fixed in cloud-init in version 23.2. If this is still a problem for you, please make a comment and set the state back to New Thank you. ** Changed in: cloud-init Status: Fix Committed => 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/200 Title: RuntimeError: duplicate mac found! both 'wwan1' and 'wwan0' Status in cloud-init: Fix Released Bug description: Hi This bug is a variant of https://bugs.launchpad.net/cloud-init/+bug/1997922. I got this error only when PXE booting a target with a modem that has dual interface support, and using ubuntu-22.04.2-live-server-amd64.iso or ubuntu-22.04.1-live-server-amd64.iso. After a manual installation, the target boots fine without this error. Detected modems that cause this error: Quectel EG25 Quectel RM510Q-GLHA Sierra Wireless MC7455 Failure in cloud-init prevent automatic installation of targets in our production. Tested solution: After studying the info in bug 1997922, I downloaded https://github.com/canonical/cloud-init/blob/main/cloudinit/net/__init__.py and changed line 1043 to: if driver == "mscc_felix" or driver == "fsl_enetc" or driver == "qmi_wwan": Then created a customized version of ubuntu-22.04.2-live-server- amd64.iso and tested in our production line, and now everything works fine. Logs: cat > get_driver.py < ../../devices/pci:00/:00:15.0/usb2/2-1/2-1:1.4/net/wwan0 qmi_wwan wwan1 lrwxrwxrwx 1 root root 0 Mar 1 08:11 /sys/class/net/wwan1 -> ../../devices/pci:00/:00:15.0/usb1/1-4/1-4:1.4/net/wwan1 qmi_wwan eno1 lrwxrwxrwx 1 root root 0 Mar 1 08:10 /sys/class/net/eno1 -> ../../devices/pci:00/:00:09.0/:02:00.0/net/eno1 igb eno2 lrwxrwxrwx 1 root root 0 Mar 1 08:10 /sys/class/net/eno2 -> ../../devices/pci:00/:00:0a.0/:03:00.0/net/eno2 igb eno3 lrwxrwxrwx 1 root root 0 Mar 1 08:10 /sys/class/net/eno3 -> ../../devices/pci:00/:00:0b.0/:04:00.0/net/eno3 igb eno4 lrwxrwxrwx 1 root root 0 Mar 1 08:10 /sys/class/net/eno4 -> ../../devices/pci:00/:00:0c.0/:05:00.0/net/eno4 igb eno5 lrwxrwxrwx 1 root root 0 Mar 1 08:10 /sys/class/net/eno5 -> ../../devices/pci:00/:00:16.0/:0a:00.0/net/eno5 ixgbe eno6 lrwxrwxrwx 1 root root 0 Mar 1 08:10 /sys/class/net/eno6 -> ../../devices/pci:00/:00:16.0/:0a:00.1/net/eno6 ixgbe Please let me know if you want more info or help for testing a final solution To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/200/+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 2011291] Re: After Cloud-Init is completed, an error is reported when the sshd service is restarted.
This bug is believed to be fixed in cloud-init in version 23.2. If this is still a problem for you, please make a comment and set the state back to New Thank you. ** Changed in: cloud-init Status: Fix Committed => 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/2011291 Title: After Cloud-Init is completed, an error is reported when the sshd service is restarted. Status in cloud-init: Fix Released Bug description: I tested this issue on multiple versions, I found that cloud-init 21.4 is ok, cloud-init 22.2 and 23.1 is not ok. The following error information is displayed for the sshd service: Mar 11 17:17:53 openEuler sshd[2232]: @@@ Mar 11 17:17:53 openEuler sshd[2232]: @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ Mar 11 17:17:53 openEuler sshd[2232]: @@@ Mar 11 17:17:53 openEuler sshd[2232]: Permissions 0640 for '/etc/ssh/ssh_host_rsa_key' are too open. Mar 11 17:17:53 openEuler sshd[2232]: It is required that your private key files are NOT accessible by others. Mar 11 17:17:53 openEuler sshd[2232]: This private key will be ignored. Mar 11 17:17:53 openEuler sshd[2232]: Unable to load host key "/etc/ssh/ssh_host_rsa_key": bad permissions Mar 11 17:17:53 openEuler sshd[2232]: Unable to load host key: /etc/ssh/ssh_host_rsa_key Mar 11 17:17:53 openEuler sshd[2232]: @@@ Mar 11 17:17:53 openEuler sshd[2232]: @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ Mar 11 17:17:53 openEuler sshd[2232]: @@@ Mar 11 17:17:53 openEuler sshd[2232]: Permissions 0640 for '/etc/ssh/ssh_host_ed25519_key' are too open. Mar 11 17:17:53 openEuler sshd[2232]: It is required that your private key files are NOT accessible by others. Mar 11 17:17:53 openEuler sshd[2232]: This private key will be ignored. Mar 11 17:17:53 openEuler sshd[2232]: Unable to load host key "/etc/ssh/ssh_host_ed25519_key": bad permissions Mar 11 17:17:53 openEuler sshd[2232]: Unable to load host key: /etc/ssh/ssh_host_ed25519_key Mar 11 17:17:53 openEuler sshd[2232]: sshd: no hostkeys available -- exiting. At the same time, I found that the key file permission generated by the sshd service is 0o400, But the file permission generated by cloud- init cc_ssh is 0o644 (publibc key) and 0o640 (private key). Should cloud-init be consistent with sshd? [root@openEuler ~]# cd /etc/ssh/ [root@openEuler ssh]# ll ssh_host_* -r. 1 root ssh_keys480 Mar 11 15:57 ssh_host_ecdsa_key -r. 1 root root162 Mar 11 15:57 ssh_host_ecdsa_key.pub -r. 1 root ssh_keys387 Mar 11 15:57 ssh_host_ed25519_key -r. 1 root root 82 Mar 11 15:57 ssh_host_ed25519_key.pub -r. 1 root ssh_keys 2578 Mar 11 15:57 ssh_host_rsa_key -r. 1 root root554 Mar 11 15:57 ssh_host_rsa_key.pub After Cloud-Init is completed： [root@openEuler ssh]# ll ssh_host_* -rw-r-. 1 root ssh_keys 1381 Mar 11 17:17 ssh_host_dsa_key -rw-r--r--. 1 root root 604 Mar 11 17:17 ssh_host_dsa_key.pub -rw-r-. 1 root ssh_keys 505 Mar 11 17:17 ssh_host_ecdsa_key -rw-r--r--. 1 root root 176 Mar 11 17:17 ssh_host_ecdsa_key.pub -rw-r-. 1 root ssh_keys 411 Mar 11 17:17 ssh_host_ed25519_key -rw-r--r--. 1 root root 96 Mar 11 17:17 ssh_host_ed25519_key.pub -rw-r-. 1 root ssh_keys 2602 Mar 11 17:17 ssh_host_rsa_key -rw-r--r--. 1 root root 568 Mar 11 17:17 ssh_host_rsa_key.pub To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/2011291/+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 2016350] Re: Growpart fails on FreeBSD with MBR/Slices
This bug is believed to be fixed in cloud-init in version 23.2. If this is still a problem for you, please make a comment and set the state back to New Thank you. ** Changed in: cloud-init Status: Fix Committed => 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/2016350 Title: Growpart fails on FreeBSD with MBR/Slices Status in cloud-init: Fix Released Bug description: A VM with slices and/or MBR will have a slice named /dev/da0s1a and makes growpart fail on its partition detection; Traceback (most recent call last): File "/usr/local/lib/python3.9/site-packages/cloudinit/config/modules.py", line 246, in _run_modules ran, _r = cc.run( File "/usr/local/lib/python3.9/site-packages/cloudinit/cloud.py", line 67, in run return self._runners.run(name, functor, args, freq, clear_on_fail) File "/usr/local/lib/python3.9/site-packages/cloudinit/helpers.py", line 185, in run results = functor(*args) File "/usr/local/lib/python3.9/site-packages/cloudinit/config/cc_growpart.py", line 613, in handle resized = util.log_time( File "/usr/local/lib/python3.9/site-packages/cloudinit/util.py", line 2721, in log_time ret = func(*args, **kwargs) File "/usr/local/lib/python3.9/site-packages/cloudinit/config/cc_growpart.py", line 526, in resize_devices (disk, ptnum) = device_part_info(blockdev) File "/usr/local/lib/python3.9/site-packages/cloudinit/config/cc_growpart.py", line 273, in device_part_info return (m.group(1), m.group(2)) AttributeError: 'NoneType' object has no attribute 'group' It seems the regex needs to be modified to support MBR disks, if we want to support them. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/2016350/+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 2020703] [NEW] horizon no translation of tables.py
Public bug reported: Hello, I am working on the translation of openstack-horizon, the problem is with the tables, the translation does not work, there is a translation in the *.mo file. I will be very grateful for any help. ** Affects: horizon Importance: Undecided Status: New ** Tags: translate ** Attachment added: "1.jpg" https://bugs.launchpad.net/bugs/2020703/+attachment/5675459/+files/1.jpg -- 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/2020703 Title: horizon no translation of tables.py Status in OpenStack Dashboard (Horizon): New Bug description: Hello, I am working on the translation of openstack-horizon, the problem is with the tables, the translation does not work, there is a translation in the *.mo file. I will be very grateful for any help. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/2020703/+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 2020699] [NEW] Nova's rescue and unrescue assumes os-brick connect_volume is idempotent
Public bug reported: The rescue and unrescue operations in Nova assume that calls to `connect_volume` in os-brick are idempotent which it's currently true, but it was not something we guaranteed in os-brick. With the recent CVE [1][2] we realized that os-brick cannot assume on the `connect_volume` that if there is a device/s present for the provided connection information then it is the right volume, and even if it's the right volume it cannot assume that it has the right information in sysfs (like the volume size), so it needs to clean things up to the best of its ability before actually connecting, and just in case it needs to confirm just before returning a patch to the caller that the device it's going to return is actually correct and consistent (as in the multipath only has devices with the same size and SCSI ID). This means that os-brick's `connect_volume` will no longer be idempotent by design once this patch [3] merges to prevent data leak in any corner cases. This will break the rescue and unrescue nova operations, because on the rescue call it stashes the original XML [4] and then unstashes it on unrescue [5], but in between Nova calls `connect_volume` for the rescue instance, effectively disconnecting the original device path. This means that reusing that original path either points to a non- existent device or to a volume of another instance. We can see an example of the non-existent device case in the failed CI job [6] where test `tempest.api.compute.servers.test_server_rescue.ServerStableDeviceRescueTest.test_stable_device_rescue_disk_virtio_with_volume_attached` fails with a nova-compute error [7]: libvirt.libvirtError: Cannot access storage file '/dev/sdd': No such file or directory [1]: https://nvd.nist.gov/vuln/detail/CVE-2023-2088 [2]: https://bugs.launchpad.net/nova/+bug/2004555 [3]: https://review.opendev.org/c/openstack/os-brick/+/882841 [4]: https://github.com/openstack/nova/blob/71b105a4cfea054827e09b5b8df6be845909275a/nova/virt/libvirt/driver.py#L4229-L4232 [5]: https://github.com/openstack/nova/blob/71b105a4cfea054827e09b5b8df6be845909275a/nova/virt/libvirt/driver.py#L4323-L4328 [6]: https://a30336fa6a8fca5c6dba- fe779e5654b21fdff79727b204dfb7d6.ssl.cf1.rackcdn.com/882841/3/check/os- brick-src-tempest-lvm-lio-barbican/8ef7adf/testr_results.html [7]: https://zuul.opendev.org/t/openstack/build/8ef7adf6a82248d8b9f94eb5b5bba73c/log/controller/logs/screen- n-cpu.txt?severity=4#77239 ** Affects: nova Importance: High Status: Triaged ** Tags: cinder libvirt rescue volumes -- 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/2020699 Title: Nova's rescue and unrescue assumes os-brick connect_volume is idempotent Status in OpenStack Compute (nova): Triaged Bug description: The rescue and unrescue operations in Nova assume that calls to `connect_volume` in os-brick are idempotent which it's currently true, but it was not something we guaranteed in os-brick. With the recent CVE [1][2] we realized that os-brick cannot assume on the `connect_volume` that if there is a device/s present for the provided connection information then it is the right volume, and even if it's the right volume it cannot assume that it has the right information in sysfs (like the volume size), so it needs to clean things up to the best of its ability before actually connecting, and just in case it needs to confirm just before returning a patch to the caller that the device it's going to return is actually correct and consistent (as in the multipath only has devices with the same size and SCSI ID). This means that os-brick's `connect_volume` will no longer be idempotent by design once this patch [3] merges to prevent data leak in any corner cases. This will break the rescue and unrescue nova operations, because on the rescue call it stashes the original XML [4] and then unstashes it on unrescue [5], but in between Nova calls `connect_volume` for the rescue instance, effectively disconnecting the original device path. This means that reusing that original path either points to a non- existent device or to a volume of another instance. We can see an example of the non-existent device case in the failed CI job [6] where test `tempest.api.compute.servers.test_server_rescue.ServerStableDeviceRescueTest.test_stable_device_rescue_disk_virtio_with_volume_attached` fails with a nova-compute error [7]: libvirt.libvirtError: Cannot access storage file '/dev/sdd': No such file or directory [1]: https://nvd.nist.gov/vuln/detail/CVE-2023-2088 [2]: https://bugs.launchpad.net/nova/+bug/2004555 [3]: https://review.opendev.org/c/openstack/os-brick/+/882841 [4]: https://github.com/openstack/nova/blob/71b105a4cfea054827e09b5b8df6be845909275a/nova/virt/libvirt/driver.py#L4229-L4232 [5]:
[Yahoo-eng-team] [Bug 2020698] [NEW] neutron-tempest-plugin-bgpvpn-bagpipe job unstable
Public bug reported: The neutron-tempest-plugin-bgpvpn-bagpipe has been unstable for over a week, and yesterday it got worse where half the tests are failing now. I thought increasing the job timeout would help, but it has not: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/883991 I realize there are changes in-flight wrt to sRBAC which might fix the issue, but until they all merge I think we should just make it non- voting on the master branch. The other branches don't seem to have any problems. ** Affects: neutron Importance: High Assignee: Brian Haley (brian-haley) Status: Confirmed ** Tags: l3-bgp tempest -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2020698 Title: neutron-tempest-plugin-bgpvpn-bagpipe job unstable Status in neutron: Confirmed Bug description: The neutron-tempest-plugin-bgpvpn-bagpipe has been unstable for over a week, and yesterday it got worse where half the tests are failing now. I thought increasing the job timeout would help, but it has not: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/883991 I realize there are changes in-flight wrt to sRBAC which might fix the issue, but until they all merge I think we should just make it non- voting on the master branch. The other branches don't seem to have any problems. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2020698/+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 2019119] Re: [sqlalchemy-20] Add the corresponding context to the upgrade checks methods
Reviewed: https://review.opendev.org/c/openstack/neutron/+/882865 Committed: https://opendev.org/openstack/neutron/commit/98ac1fa31a80387d9c270b676dd96ac8ba649891 Submitter: "Zuul (22348)" Branch:master commit 98ac1fa31a80387d9c270b676dd96ac8ba649891 Author: Rodolfo Alonso Hernandez Date: Wed May 10 03:06:23 2023 +0200 [sqlalchemy-20] Add the transaction context to the upgrade checks methods In ``cmd.upgrade_checks.checks``, there are some methods that access to the database. The queries are now inside a database context (reader or writer depending on the query). Closes-Bug: #2019119 Change-Id: I35b1311576bcf1681ab4932f0baeb4cd3099301c ** 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/2019119 Title: [sqlalchemy-20] Add the corresponding context to the upgrade checks methods Status in neutron: Fix Released Bug description: In ``cmd.upgrade_checks.checks``, there are some methods that access to the database. The queries are not inside a database context (reader or writer depending on the query). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2019119/+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 2020663] [NEW] [FT] Errors during the port creation in ``test_ovs_lib.BaseOVSTestCase``
Public bug reported: Some ``BaseOVSTestCase`` tests are failing during the port creation. Snippet: https://paste.opendev.org/show/bYA9Z5PRutHQ5F6sYStv/ Logs: * https://f326700999a21a41aed9-1ea95ca857946beec6346fe0f4481db6.ssl.cf1.rackcdn.com/883269/2/check/neutron-functional-with-uwsgi/f3242b7/testr_results.html * https://7814844573a763db7ab8-0ac84b2ac4d53823f5d0fa90b7a93a42.ssl.cf2.rackcdn.com/882865/2/gate/neutron-functional-with-uwsgi/3e74eb2/testr_results.html ** 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/2020663 Title: [FT] Errors during the port creation in ``test_ovs_lib.BaseOVSTestCase`` Status in neutron: New Bug description: Some ``BaseOVSTestCase`` tests are failing during the port creation. Snippet: https://paste.opendev.org/show/bYA9Z5PRutHQ5F6sYStv/ Logs: * https://f326700999a21a41aed9-1ea95ca857946beec6346fe0f4481db6.ssl.cf1.rackcdn.com/883269/2/check/neutron-functional-with-uwsgi/f3242b7/testr_results.html * https://7814844573a763db7ab8-0ac84b2ac4d53823f5d0fa90b7a93a42.ssl.cf2.rackcdn.com/882865/2/gate/neutron-functional-with-uwsgi/3e74eb2/testr_results.html To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2020663/+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 2020661] [NEW] [CentOS] Periodic job "neutron-ovs-tempest-fips" failing since May 18 2023
Public bug reported: The periodic job "neutron-ovs-tempest-fips" is failing since May 18 [1]. The issue seems to be in some missing packages: * rabbitmq-server: https://zuul.openstack.org/build/0f33bf8c2a1c4854aaadaa48badb8c73/log/job-output.txt#5294 * openstack-network-scripts: https://zuul.openstack.org/build/07183ad3d88f461f9cebadd2bf76cdff/log/job-output.txt#6181 [1]https://zuul.opendev.org/t/openstack/builds?job_name=neutron-ovs- tempest-fips=master=periodic=0 ** Affects: neutron Importance: Undecided Assignee: Rodolfo Alonso (rodolfo-alonso-hernandez) Status: New ** 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/2020661 Title: [CentOS] Periodic job "neutron-ovs-tempest-fips" failing since May 18 2023 Status in neutron: New Bug description: The periodic job "neutron-ovs-tempest-fips" is failing since May 18 [1]. The issue seems to be in some missing packages: * rabbitmq-server: https://zuul.openstack.org/build/0f33bf8c2a1c4854aaadaa48badb8c73/log/job-output.txt#5294 * openstack-network-scripts: https://zuul.openstack.org/build/07183ad3d88f461f9cebadd2bf76cdff/log/job-output.txt#6181 [1]https://zuul.opendev.org/t/openstack/builds?job_name=neutron-ovs- tempest-fips=master=periodic=0 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2020661/+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 2020630] [NEW] create instance window, Network Ports tab, some ports have no name and ip
Public bug reported: 1. Go to Project > Compute > Instances 2. Add port from CLI (e.g. openstack port create --network int --fixed-ip subnet=intsub,ip-address=192.168.168.69 mynetworkport) 3. Press Lauch Instance and go to Network Ports tab Newly added port have no name and ip info. Browser developer console indicates the presence of 2 errors: data is undefined, port is undefined. ** Affects: horizon Importance: Undecided Status: New ** Attachment added: "screenshot.PNG" https://bugs.launchpad.net/bugs/2020630/+attachment/5675223/+files/screenshot.PNG -- 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/2020630 Title: create instance window, Network Ports tab, some ports have no name and ip Status in OpenStack Dashboard (Horizon): New Bug description: 1. Go to Project > Compute > Instances 2. Add port from CLI (e.g. openstack port create --network int --fixed-ip subnet=intsub,ip-address=192.168.168.69 mynetworkport) 3. Press Lauch Instance and go to Network Ports tab Newly added port have no name and ip info. Browser developer console indicates the presence of 2 errors: data is undefined, port is undefined. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/2020630/+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
