Comment 6 for bug 1770835

I am receiving the same issue as well and can provide clarity.

I'm running this all with a focal-ussuri undercloud.

I have followed this process:
1. create new openstack project, tenant network with external router gateway to a floating-ip network.
2. Grant a user Admin and member privileges to the project.
3. Login as that user and create a focal ubuntu VM with an associated FIP
4. add inbound ssh rule in security group default
5. Generate application credentials in Horizon:
  In Horizon as that user under that project in top project selection menu:
  Click Identity -> Application Credentials -> Create Application Credentials
  Name something useful like: afreiberger-juju-credentials
  Multi-select Admin and member roles
  Click Create Application Credential, and save the ID and Secret for use later.
  download novarc for user (not app credentials) to put on jumphost

On the jumphost in the project (after setting up any necessary proxies),
6. sudo snap install juju --classic; sudo snap install openstackclients
7. source the project novarc
8. juju add-cloud openstack
answer prompts as:
openstack
<enter>
<enter>
access-key
<enter>
<enter>
n
9. add credentials:

ubuntu@jumpbox:~$ juju add-credential openstack
This operation can be applied to both a copy on this client and to the one on a controller.
No current controller was detected and there are no registered controllers on this client: either bootstrap one or register one.
Enter credential name: afreiberger-juju-credentials

Regions
  RegionOne

Select region [any region, credential is not region specific]: <enter>

Using auth-type "access-key".

Enter access-key: <id of credential>

Enter secret-key: <copied secret from earlier>

Enter tenant-name (optional): afreiberger-tenant

Enter tenant-id (optional): <enter>

Enter version (optional): <enter>

Credential "afreiberger-juju-credentials" added locally for cloud "openstack".

10. Run bootstrap:
juju bootstrap openstack openstack

# expected results are a new VM is deployed and bootstrapping occurs.
# Actual results are in the description of this ticket.

It appears that the issue Florian noted in comment #2 was that in their environment, they could get the access-key style juju credentials to work if they used a v2 endpoint instead of a v3 endpoint.

However, the issue in juju or it's upstream dependencies is that if using keystone v3 and application credentials, the URI must be /v3/auth/tokens, but the URI being accessed by the juju client's openstack methods for token generation via access-key is actually hitting a 404 /v3/tokens URI.

I believe the link to the openstack API was Florian demonstrating that the tokens API is not present under /v3/tokens.

It is my opinion that juju should very much support v3 keystone access-key authentication, as user-pass based authentication is prone to expiration and constantly changing passwords. Application credentials are the proper way for software clients to interact with the Openstack API. It does appear the juju client does not currently support a functioning way to use access-key credentials against a v3-only Keystone deployment. V2 endpoints are no longer available in modern Openstack, so the workaround Florian found seems no longer applicable.