3 ms·

No and No. It's not about the complexity of it or being any worse/better than K8s. It's about the endless bugs and regressions and laundry list of stupid prob

No and No. It's not about the complexity of it or being any worse/better than K8s. It's about the endless bugs and regressions and laundry list of stupid problems caused by inadequate processes by OpenStack developers. For example, let's say you're running Cinder v3. Cinder 3.59. You want to get the volumes that you have attached to an instance, so you curl the API: /cinder/v3/<instance id>/attachments. You get a 404. You get a 404 because you didn't pass this header: "OpenStack-API-Version: volume 3.27". Because Cinder defaults to Cinder 3.01 behavior even when you're running 3.59. Attachments were only added in 3.27. So even though you're trying to curl a route that wouldn't even exist in 3.01 and you're running a version clearly later than 3.27, the API responds as if it's Cinder 3.01 unless you specifically tell it to do otherwise. And this is just one of the laundry list of stupid situations that I can remember off the top of my head. When the thing isn't otherwise failing all the time.

nyrikki 2y ago
That isn't a bug, that is correct behavior under their contract model (which I will admit isn't my favorite). It is common for message based systems for the target system to own the contract, and they have both the / and /v3/ endpoints that you can grab the version information from. This is documented BTW: https://docs.openstack.org/api-ref/block-storage/v3/index.html#list-all-api-versions https://docs.openstack.org/api-ref/block-storage/v3/index.ht... While I personally prefer the URL method, when versioning through custom headers, if you bump the API without that custom header, you will break way more than returning correct behavior for the minimum supported version, enforcing backward compatibility for API's is generally considered a best practice. Note: > If the OpenStack-API-Version header is not provided, act as if the minimum supported version was specified. https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html https://specs.openstack.org/openstack/api-wg/guidelines/micr... Once again, fully documented, expected behavior.

nyrikki 2y ago

That isn't a bug, that is correct behavior under their contract model (which I will admit isn't my favorite). It is common for message based systems for the target system to own the contract, and they have both the / and /v3/ endpoints that you can grab the version information from. This is documented BTW: https://docs.openstack.org/api-ref/block-storage/v3/index.html#list-all-api-versions https://docs.openstack.org/api-ref/block-storage/v3/index.ht... While I personally prefer the URL method, when versioning through custom headers, if you bump the API without that custom header, you will break way more than returning correct behavior for the minimum supported version, enforcing backward compatibility for API's is generally considered a best practice. Note: > If the OpenStack-API-Version header is not provided, act as if the minimum supported version was specified. https://specs.openstack.org/openstack/api-wg/guidelines/microversion_specification.html https://specs.openstack.org/openstack/api-wg/guidelines/micr... Once again, fully documented, expected behavior.