Description of problem: When a stateless security group is attached to the instance it fails to reach metadata. An explicit rule is required to allow traffic from 169.254.169.254. Checked with the custom security group (only egress traffic is allowed) as well as with the default security group (egress and ingress from the same SG are allowed). Version-Release number of selected component (if applicable): RHOS-17.1-RHEL-9-20221115.n.2 Red Hat Enterprise Linux release 9.1 (Plow) How reproducible: 100% Steps to Reproduce: openstack security group create --stateless test_sg openstack server create --image <IMG> --flavor <FLAV> --network <NET> --security-group test_sg vm_1 Actual results: Output from cirros console: ``` checking http://169.254.169.254/2009-04-04/instance-id failed 1/20: up 9.42. request failed failed 2/20: up 58.45. request failed ``` Expected results: Instance should be able to reach metadata Additional info:
Metadata should continue working by default for stateless SGs. (Whether stateful flows should be used to implement it is a separate question.)
Hi Ihar, can you update regarding the fix of this issue?
This bug is reported for ipv4 metadata service. I believe we also support ipv6 metadata since https://specs.openstack.org/openstack/neutron-specs/specs/ussuri/metadata-add-ipv6-support.html (not sure about product support status, please confirm.) Is ipv6 scenario covered in the test plan? Should we report a bug for ipv6 in addition to this one? Thanks.
I've posted the fix for this bug upstream here: https://review.opendev.org/q/topic:bug%252F2009053
(In reply to Ihar Hrachyshka from comment #3) > This bug is reported for ipv4 metadata service. I believe we also support > ipv6 metadata since > https://specs.openstack.org/openstack/neutron-specs/specs/ussuri/metadata- > add-ipv6-support.html (not sure about product support status, please > confirm.) Is ipv6 scenario covered in the test plan? Should we report a bug > for ipv6 in addition to this one? Thanks. Ihar I don't think RH OSP supports IPv6 metadata. I did not find any docs about it or any test plan
Status update: 1) patches are posted in upstream; 2) upstream reviewers (Slawek and Rodolfo) suggested that this topic needs more elaboration and discussion since they don't necessarily agree with the assumption that both metadata and ipv6 dhcp should work by default for stateless SGs; (I disagree) 3) they suggested to have a discussion on this topic during the vPTG this week; specifically, this Wed at 9am EST we'll discuss this exact topic; 4) once we have a resolution on what can be implemented upstream, I will work on adjusting the existing patches to upstream (if needed) this Friday. Note that the above suggests that we may not have the bug fixed as expected in the test plan; at least upstream. So we may have to adjust the test plan maybe? The discussion this Wed should clarify what's possible in upstream.
This bug (its upstream counterpart) was discussed during virtual PTG session for Neutron today, and the decision was that this behavior - metadata not working by default for stateless SGs, requiring creation of a SG rule to allow returning traffic - is as intended and mimic what ML2/OVS implementation already does. (On the other hand, DHCPv6 stateless ICMP replies will be enabled by default - again, it will mimic behavior of ML2/OVS.) With that, I'm closing this bug. Test plans will have to be adjusted accordingly, specifically: 1. to validate metadata is not working without ICMP SG rule created; 2. metadata works with ICMP SG rule created. This behavior will also be documented in upstream api-ref documentation. (For metadata and dhcpv6 stateless.)