[Yahoo-eng-team] [Bug 2084782] [NEW] [OVN] VLAN/flat LRP should be updated when the router networks are updated
Public bug reported: This bug is related to [1] and the mentioned bugs and patches in the commit message. Context: * ML2/OVN driver. * Distributed floating IPs. When a router has "mixed type networks" (tunnelled and not tunnelled networks), the VLAN/flat LRP should have the flag 'reside-on-redirect- chassis' to True. If the router has only VLAN/flat networks, the flag 'reside-on-redirect-chassis' should be False and 'redirect- type'='bridge'. The patch [1] does not consider the router LRP addition/deletion. For example, if we initially add the VLAN/flat network to the router, the router won't have "mixed type networks". If we then add a tunnelled network, we don't update the VLAN/flat LRP. The same scenario happens when we remove a tunnelled LRP and the router has only VLAN/flat networks. [1]https://review.opendev.org/c/openstack/neutron/+/878450 OSP18 bug: https://issues.redhat.com/browse/OSPRH-10761 ** Affects: neutron Importance: Medium Assignee: Rodolfo Alonso (rodolfo-alonso-hernandez) Status: New ** Changed in: neutron Assignee: (unassigned) => Rodolfo Alonso (rodolfo-alonso-hernandez) ** Changed in: neutron Importance: Undecided => Medium ** Description changed: This bug is related to [1] and the mentioned bugs and patches in the commit message. Context: * ML2/OVN driver. * Distributed floating IPs. When a router has "mixed type networks" (tunnelled and not tunnelled networks), the VLAN/flat LRP should have the flag 'reside-on-redirect- chassis' to True. If the router has only VLAN/flat networks, the flag 'reside-on-redirect-chassis' should be False and 'redirect- type'='bridge'. The patch [1] does not consider the router LRP addition/deletion. For example, if we initially add the VLAN/flat network to the router, the router won't have "mixed type networks". If we then add a tunnelled network, we don't update the VLAN/flat LRP. The same scenario happens when we remove a tunnelled LRP and the router has only VLAN/flat networks. [1]https://review.opendev.org/c/openstack/neutron/+/878450 + + OSP18 bug: https://issues.redhat.com/browse/OSPRH-10761 -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/2084782 Title: [OVN] VLAN/flat LRP should be updated when the router networks are updated Status in neutron: New Bug description: This bug is related to [1] and the mentioned bugs and patches in the commit message. Context: * ML2/OVN driver. * Distributed floating IPs. When a router has "mixed type networks" (tunnelled and not tunnelled networks), the VLAN/flat LRP should have the flag 'reside-on-redirect- chassis' to True. If the router has only VLAN/flat networks, the flag 'reside-on-redirect-chassis' should be False and 'redirect- type'='bridge'. The patch [1] does not consider the router LRP addition/deletion. For example, if we initially add the VLAN/flat network to the router, the router won't have "mixed type networks". If we then add a tunnelled network, we don't update the VLAN/flat LRP. The same scenario happens when we remove a tunnelled LRP and the router has only VLAN/flat networks. [1]https://review.opendev.org/c/openstack/neutron/+/878450 OSP18 bug: https://issues.redhat.com/browse/OSPRH-10761 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/2084782/+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 2084538] Re: FIP port has an IPv6 fixed_ip
Set the service type of IPv6 subnet of external network should solve the
problem. The service type should be "network:router_gateway". See the
doc for more details:
https://docs.openstack.org/neutron/latest/admin/config-service-
subnets.html
** Changed in: neutron
Status: In Progress => 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/2084538
Title:
FIP port has an IPv6 fixed_ip
Status in neutron:
Invalid
Bug description:
A port whose device_owner is floatingip has an IPv6 fixed_ip.
This is an old issue, but I haven't focused on it.
Steps to reproduce:
1.create an external network:
openstack network create --provider-network-type vlan
--provider-physical-network physnet1 --external pu
2.create an ipv4 subnet:
openstack subnet create --network pu --subnet-range 172.133.10.0/24 pu
3.create an ipv6 subnet:
openstack subnet create --network pu --ip-version 6 --subnet-range
2011::/64 --dhcp --ipv6-ra-mode dhcpv6-stateful --ipv6-address-mode
dhcpv6-stateful pu
4.create an floating ip with the external network:
neutron floatingip-create pu
Created a new floatingip:
+-+--+
| Field | Value|
+-+--+
| created_at | 2024-10-15T03:05:20Z |
| description | |
| dns_domain | |
| dns_name| |
| extra_fields| {} |
| fixed_ip_address| |
| floating_ip_address | 172.133.10.43|
| floating_network_id | 63b02c2d-007b-4096-8923-f63a8c993b7b |
| id | 9fb736b4-a0c3-429c-a59b-f82450d496e4 |
| port_details| |
| port_id | |
| project_id | d2ee4ab6e0344563812cabb655aeb9c3 |
| qos_policy_id | |
| revision_number | 0|
| router_id | |
| status | DOWN |
| tags| |
| tenant_id | d2ee4ab6e0344563812cabb655aeb9c3 |
| updated_at | 2024-10-15T03:05:20Z |
+-+--+
5.we can find the floating ip port has an ipv6 address:
neutron port-show 77e4caa2-2953-48d2-bbfe-9d658de42a35
+---+--+
| Field | Value
|
+---+--+
| admin_state_up| True
|
| allowed_address_pairs |
|
| binding:host_id |
|
| binding:profile | {}
|
| binding:vif_details | {}
|
| binding:vif_type | unbound
|
| binding:vnic_type | normal
|
| created_at| 2024-10-15T03:05:20Z
|
| description |
|
| device_id | 9fb736b4-a0c3-429c-a59b-f82450d496e4
|
| device_owner | network:floatingip
|
| extra_dhcp_opts |
|
| fixed_ips | {"subnet_id":
"5a70bc02-7017-4aa6-a879-4cb4a9b19ccf", "ip_address": "172.133.10.43"} |
| | {"subnet_id":
"6853c78f-8083-40c5-ac8a-0a76a9a1261d", "ip_address": "2011::a9"} |
| id| 77e4caa2-2953-48d2-bbfe-9d658de42a35
|
| mac_address | fa:16:3
[Yahoo-eng-team] [Bug 2084796] [NEW] Typo in resource type for metadef - OS::Cinder::VolumeType
Public bug reported: There is a typo in the Glance metadef resource type for Volume Type. Currently, there is OS:Cinder::VolumeType, but every other resource type starts with OS:: (double :). This looks like a typo, and if a user wants to create a custom metadef namespace with this resource type, this typo must be copied, which is very confusing. ** Affects: horizon Importance: Undecided Assignee: Viktor Křivák (viktor-krivak) Status: New ** Changed in: horizon Assignee: (unassigned) => Viktor Křivák (viktor-krivak) -- 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/2084796 Title: Typo in resource type for metadef - OS::Cinder::VolumeType Status in OpenStack Dashboard (Horizon): New Bug description: There is a typo in the Glance metadef resource type for Volume Type. Currently, there is OS:Cinder::VolumeType, but every other resource type starts with OS:: (double :). This looks like a typo, and if a user wants to create a custom metadef namespace with this resource type, this typo must be copied, which is very confusing. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/2084796/+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 2078669] Re: Specify --availability-zone=nova does not work since caracal
since the intorduction of AZ nova has documented that pinning to the nova az should never be done https://docs.openstack.org/nova/latest/admin/availability-zones.html """ The use of the default availability zone name in requests can be very error-prone. Since the user can see the list of availability zones, they have no way to know whether the default availability zone name (currently nova) is provided because a host belongs to an aggregate whose AZ metadata key is set to nova, or because there is at least one host not belonging to any aggregate. Consequently, it is highly recommended for users to never ever ask for booting an instance by specifying an explicit AZ named nova and for operators to never set the AZ metadata for an aggregate to nova. This can result is some problems due to the fact that the instance AZ information is explicitly attached to nova which could break further move operations when either the host is moved to another aggregate or when the user would like to migrate the instance. """ while it is possible to do it is generally considered unsupported and incorrect by the nova core team. hoizon has historically been the leading culpert to people actually using nova in the request as it places it in the dropdown when creating a VM. this is a horizon bug and has never been a valid approach. you do not need to specify an az when creating a VM in nova and you should not in this case. ** Changed in: nova Status: In Progress => Opinion -- 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/2078669 Title: Specify --availability-zone=nova does not work since caracal Status in OpenStack Compute (nova): Opinion Bug description: openstack server create with --availability-zone=nova can place instance onto the compute which belongs to non default AZ since caracal release. The issue is introduced by removal of nova availabilityZone filter https://review.opendev.org/c/openstack/nova/+/886779. When using placement to filter AZs we add member_of=XXX, where XXX is the aggregate UUID which corresponds to AZ. In case of default AZ (nova) there is no any aggregate. As result we request computes without any aggregate/az filtering. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/2078669/+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 2076089] Re: admin cannot force instance launch on disabled host
The disable feature on the comptue service is intended to prevent any scudling of new workload to a disabled host. this is intended to include new workload and all move operations to a disabled host. the host is being rejected as intended so setting this to invalid as the expectations of the reporter do not match the intended semantics of the api. ** Changed in: nova Status: New => Invalid -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/2076089 Title: admin cannot force instance launch on disabled host Status in OpenStack Compute (nova): Invalid Bug description: Description === I have a set of disabled nova compute services, with nova compute service up and running, and I would like to force instance creation, as admin, on a disabled conpute node for testing purposes. I added the option --availability-zone nova:$HOST to the openstack server create command, however it fails with "no valid host found" even if it should have skipped placement filters. Steps to reproduce == * openstack compute service list --service nova-compute +--+--+--+--+--+---++ | ID | Binary | Host | Zone | Status | State | Updated At | +--+--+--+--+--+---++ | cdfe3225-a705-4c30-9f1b-a34be15d89a0 | nova-compute | test1-cg0001 | nova | disabled | down | 2024-07-18T16:03:00.00 | | f44ad40d-b161-48b0-914a-738638dc10ea | nova-compute | test1-c0001 | nova | enabled | up| 2024-08-05T09:57:08.00 | | 3e15725b-6b9d-44e9-ae03-fe121d75017c | nova-compute | test1-c0003 | nova | disabled | up| 2024-08-05T09:57:05.00 | +--+--+--+--+--+---++ * openstack server create --wait --flavor 016016 --boot-from-volume 20 --image "Debian 12 (Switch Cloud)" --network my_private_network --availability-zone nova:test1-c0003 strider-force-launch Error creating server: strider-force-launch Error creating server Expected result === Launch process should have skipped placement filters and instance should have been launched on requested hypervisor Actual result = * Failure reason is "No valid host found": openstack server show strider-force-launch +-+---+ | Field | Value | +-+---+ | OS-DCF:diskConfig | MANUAL | | OS-EXT-AZ:availability_zone | nova | | OS-EXT-SRV-ATTR:host| None | | OS-EXT-SRV-ATTR:hypervisor_hostname | None | | OS-EXT-SRV-ATTR:instance_name | instance-1256 | | OS-EXT-STS:power_state | NOSTATE | | OS-EXT-STS:task_state | None | | OS-EXT-STS:vm_state | error | | OS-SRV-USG:launched_at | None | | OS-SRV-USG:terminated_at| None | | accessIPv4 | | | accessIPv6 | | | addresses |
[Yahoo-eng-team] [Bug 2084794] Re: Volume tab/volume quotas completely missing in Zuul deployed UI.
https://0a5c623ff913673f34ed-80527d3715cd24d9d5daf12827bd66d5.ssl.cf2.rackcdn.com/932271/1/check/horizon- integration-pytest/bb06070/controller/logs/apache/horizon_error_log.txt has some errors indicating that the service catalog might not be setup correctly: 2024-10-16 12:51:41.216528 horizon.exceptions.ServiceCatalogException: Invalid service catalog: Cinder 3 requested but no '['volumev3', 'volume']' service type available in Keystone catalog. 2024-10-16 12:51:41.216531 version, cinder_url = _find_cinder_url(request, version) 2024-10-16 12:51:41.216531 ERROR openstack_dashboard.api.rest.utils HTTP exception with no status/code also odd KeyErrors: 2024-10-16 12:51:41.216421 KeyError: ((,), ()) ** Also affects: horizon Importance: Undecided Status: New ** Also affects: python-cinderclient Importance: Undecided Status: New ** No longer affects: cinder -- 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/2084794 Title: Volume tab/volume quotas completely missing in Zuul deployed UI. Status in OpenStack Dashboard (Horizon): New Status in python-cinderclient: New Bug description: Hello, We (In Horizon UI) are facing an issue in Zuul deployment that this deployment completely missing Volume tab, Volume quotas, etc. So it looks like the Cinder does not work at all in the Zuul deploy. Our last patch was merged October 1, then tests passed without any issue for a few days and from October 10 our tests are failing because the Volume tab is missing in UI. Horizon opendev: https://review.opendev.org/q/project:openstack/horizon+branch:master Failing tests because of the missing volume tab: https://zuul.opendev.org/t/openstack/build/bb060700efa84a9ab2e6bf6c4c70162e It blocks us from merging any new patch for Horizon. Screenshot of missing Volume tab in attachment. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/2084794/+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
