[Other] SCS-0128 vs. SCS-0126

[fkr]

It came to my attention that in SCS-0128 we have these tempest tests regarding floating ips:

tempest.api.network.test_floating_ips.FloatingIPTestJSON.test_create_floating_ip_specifying_a_fixed_ip_address[id-36de4bd0-f09c-43e3-a8e1-1decc1ffd3a5]
tempest.api.network.test_floating_ips.FloatingIPTestJSON.test_create_update_floatingip_with_port_multiple_ip_address[id-45c4c683-ea97-41ef-9c51-5e9802f2f3d7]
tempest.api.network.test_floating_ips.FloatingIPTestJSON.test_floating_ip_delete_port[id-e1f6bffd-442f-4668-b30e-df13f2705e77]
tempest.api.network.test_floating_ips.FloatingIPTestJSON.test_floating_ip_update_different_router[id-1bb2f731-fe5a-4b8c-8409-799ade1bed4d]

(see here:

standards/Tests/iaas/scs_0128_e2e_testing/tempest-tests-non-admin.lst

Lines 141 to 144 in 2a52e2d

	tempest.api.network.test_floating_ips.FloatingIPTestJSON.test_create_floating_ip_specifying_a_fixed_ip_address[id-36de4bd0-f09c-43e3-a8e1-1decc1ffd3a5]
	tempest.api.network.test_floating_ips.FloatingIPTestJSON.test_create_update_floatingip_with_port_multiple_ip_address[id-45c4c683-ea97-41ef-9c51-5e9802f2f3d7]
	tempest.api.network.test_floating_ips.FloatingIPTestJSON.test_floating_ip_delete_port[id-e1f6bffd-442f-4668-b30e-df13f2705e77]
	tempest.api.network.test_floating_ips.FloatingIPTestJSON.test_floating_ip_update_different_router[id-1bb2f731-fe5a-4b8c-8409-799ade1bed4d]

)

The Draft Standard for Networking (SCS-0126-V1) actually says:

External Addresses
We define an external address as an IPv4 or IPv6 address that is accessible to a user of the SCS-compliant OpenStack API. For public clouds, external addresses MUST be either IPv4 public addresses or IPv6 global unicast addresses (GUA).

The CSP MUST offer allocation of external IPv6 addresses to user projects. The CSP SHOULD offer allocation of external IPv4 addresses to user projects.

(https://docs.scs.community/standards/scs-0126-v1-provider-networks#external-addresses)

From my understanding this makes IPv4 optional, while our tempest end-to-end test require IPv4.

I have the feeling we should solve this before SCS-0126 is stabilized and becomes part of a future certificate scope.

[fkr]

This was initially raised by @mrhopeman during the Yaook SCS Operator Hackathon. Thanks @mrhopeman!

[mbuechse]

From my POV, scs-0128 is a bit stricter than scs-0126, but both have to be satisfied, and they don't contradict each other. It's well possible that in a future version of scs-0128, the requirement for IPv4 will be dropped. I think there is no inherent need to couple the two standards.

[fkr]

If SCS-0126 states that IPv4 is optional, but SCS-0128 demands it, isn't that a conflict?
Then IPv4 is not optional, since I need it in order to satisfy SCS-0128.
In the discussion leading to SCS-0126 it was stated numerous times that demanding IPv4 is to be avoided.

[mbuechse]

If scs-0126 said no IPv4 was permissible, then this would be a contradiction, because no test subject could ever satisfy both scs-0126 and scs-0128. But as it stands, it's possible to satisfy both standards. In other words, if two standards include the same testcase, one as recommendation and one as requirement, then on the whole, it's a requirement. If your son says you SHOULD come on Monday and you wife says you MUST come on Monday, well, then you come on Monday. Where's the problem?

[fkr]

Maybe I oversee something, but SCS-0128 needs to pass. All tests we list in there need to pass.
If the tests require IPv4, IPv4 is mandatory, isn't it?

From what the community said in the discussion leading to SCS-0126 it was voiced that IPv4 should not become mandatory.

Imho we should evaluate the list of test cases we include in SCS-0128, since now it looks like we make IPv4 mandatory via SCS-0128, even though the intention of SCS-0126 was to not enforce IPv4.

[mbuechse]

From what the community said in the discussion leading to SCS-0126 it was voiced that IPv4 should not become mandatory.

Okay, now I get it.

Imho we should evaluate the list of test cases we include in SCS-0128, since now it looks like we make IPv4 mandatory via SCS-0128, even though the intention of SCS-0126 was to not enforce IPv4.

The thing is: IPv4 was already mandatory when scs-0126 was discussed, because OpenStack-powered Compute was already a requirement (albeit untested).

So, yes, we should probably discuss whether to relax scs-0128. But that is not a conflict for me, rather the second step in a two-step process.

[fkr]

Imho we should evaluate the list of test cases we include in SCS-0128, since now it looks like we make IPv4 mandatory via SCS-0128, even though the intention of SCS-0126 was to not enforce IPv4.
The thing is: IPv4 was already mandatory when scs-0126 was discussed, because OpenStack-powered Compute was already a requirement (albeit untested).

yes - but I'm very certain nobody was aware that IPv4 as a requirement "snuck in" via OpenStack powered compute.

So, yes, we should probably discuss whether to relax scs-0128. But that is not a conflict for me, rather the second step in a two-step process.

I concur.

[garloff]

I would support downgrading the tests (inherited from OpenStack Powered Compute) that require public IPv4 addresses to become RECOMMENDED.
I would not support dropping them entirely at this point in time. Too many apps (still) require it, so we want this to be tested and give an indication to app developers / app operators.

[fkr]

I would support downgrading the tests (inherited from OpenStack Powered Compute) that require public IPv4 addresses to become RECOMMENDED. I would not support dropping them entirely at this point in time. Too many apps (still) require it, so we want this to be tested and give an indication to app developers / app operators.

If this is the case, then I'd think it makes sense to have SCS-0126 state that IPv4 is recommended instead of using 'may'.
@garloff ?

(https://docs.scs.community/standards/scs-0126-v1-provider-networks#ipv4-allocation)