Created attachment 1288291 [details] err msg Version-Release number of selected component (if applicable): 5.7.3.1 with RHOS 11 How reproducible: Always Steps to Reproduce: 1. Go COmpute -> Cloud -> Tenants 2. CLick Configuration -> Create CLoud tenant 3. Eneter name and click Save Actual results: Error message - 404 NOT FOUND (check attach) Expected results: Creation of cloud tenant initiated Additional info:
UPD. The similar error for tenant update
Created attachment 1290743 [details] evm.log
Please provide either Openstack catalog or Identity service endpoint. My suspicion from some tests is that Keystone public endpoint is using the version in its path "publicURL" => "http://192.168.1.1:5000/v3" which can't support v2.0 requests. If that's the case, identity endpoints should be version-less such as "http://192.168.1.1:5000"
After further tests, I can confirm the issue is because the OSP11 setup this is tested against has a Keysteone endpoint URL set to "http://192.168.1.1:5000/v3". Therefore the OSP11 Keysteone endpoint need to be fixed to "http://192.168.1.1:5000". And if the OSP11 setup is the default then a bug should be created against OSP11. In details, a "versionned" Keystone endpoint URL is forcing fog-openstack SDK to use API version 3. That cannot work because version 3 cannot serve v2.0 requests. In such case just listing the tenants triggers the following path to be submitted 'v3/tenants' which fails. Although Keystone server version 3 can handle both v2.0 and v3 request from a single endpoint. The path determines the version by prefixing the request with either 'v2.0' or 'v3'. This is why it's better to have Keystone v3 endpoint url to be version less. Unfortunately fog-openstack doesn't have a :openstack_endpoint_override variable to indicate to use a different endpoint than the one returned by the catalog. Also trying to change the path is not only *absolutely* not recommended by Openstack API usage practice but history has demonstrated how that is a *very* windly road but was necessary at time to work around various uses created by changes in Openstack APIs versions and also various inconsistent Openstack setup. So if a long term solution is needed then that would be to add a endpoint_override option.
Dear customer, The CloudForms team is reviewing the current CloudForms Bug(defect) backlog in order to target engineering efforts. We are closing any bugs for versions that no longer have an active errata stream or that have hit their age limit. We are committing to better management of the backlog as we move forward. If you have an bug that you are still able to reproduce on a current version of CloudForms please open a new bug. If you have any concerns about this, please let us know. Thanks and regards!