[Feature Request] output application credentials as clouds.yaml

[harmathy]

It would be nice to have the ability to output an application credential as ready-to-use clouds.yaml.

This would make automation so much easier, if you could for example just run something like:

osc identity application-credential create --current-user --ouput-clouds-yaml ./foo/clouds.yaml

and then use the clouds.yaml right away.

[gtema]

I was thinking already about some sort of connection editor, but that is tricky.
Also here the best approach is actually to still split the data between clouds.yaml and secure.yaml

Biggest issue is that since all commands are generated from openapi there is no way currently of adding such logic. The only possibility would be to add a new command. Is it something that is still ok from your pov?

[harmathy]

The only possibility would be to add a new command. Is it something that is still ok from your pov?

Yes, absolutely! That would also be just fine!

[dmbuil]

I did like this feature as well, and have been giving it a though for a while.
Would something like this work?

osc identity application-credential create-clouds -h

Create application credential and write clouds.yaml

Usage: osc identity application-credential create-clouds [OPTIONS] --name <NAME>

Options:
  -h, --help     Print help (see more with '--help')
  -V, --version  Print version

Path parameters:
      --user-name <USER_NAME>  User Name
      --user-id <USER_ID>      User ID
      --current-user           Current authenticated user (the default when nothing is given)

Body parameters:
      --name <NAME>                  The name of the application credential. Must be unique to a user
      --description <DESCRIPTION>    A description of the application credential's purpose
      --expires-at <EXPIRES_AT>      An optional expiry time for the application credential. If unset, the application credential does not expire
      --roles <JSON>                 An optional list of role objects, identified by ID or name
      --unrestricted <UNRESTRICTED>  Restrict whether the application credential may be used for the creation or destruction of other application credentials
                                     or trusts [possible values: true, false]

Output:
      --cloud-name <CLOUD_NAME>  Name of the cloud entry in the generated file(s) [default: openstack]
      --output-path <DIR>        Directory the clouds.yaml (and secure.yaml) is written into [default: .]
      --split                    Write the secret into a separate secure.yaml instead of clouds.yaml
      --overwrite                Replace an existing target file (or, combined with --merge, an existing cloud entry of the same name)
      --merge                    Merge the cloud entry into an existing target file. The file is rewritten: comments and formatting are not preserved

Connection options:
      --os-cloud <OS_CLOUD>                            
...

I dropped --secret, --id, --system, --access-rules to make the code somewhat shorter (and because they are a little niche).
On the other hand, the --split flag (to generate clouds.yaml & secure.yaml separately) is not default to keep the file generation simpler,

I am still tweaking a few things :)

[gtema]

Honestly speaking I was thinking more into the direction of piping the output of the creation to another command to prevent duplicating create command and have more control specifying which clouds.yaml, whether to split it into clouds/secure, etc. Maybe we could have hooks support for the output processing to do additional work.

[dmbuil]

Thanks for the feedback, @gtema . I think you're right, and honestly the piping direction solves the part of my approach that I disliked most: create-clouds hand-copies the request assembly of the generated create command, so every schema change upstream would need manual mirroring here forever. A consumer command avoids that entirely.

Concretely, I'd propose a hand-written command that reads the create response JSON from stdin:

osc identity user application-credential create --name deploy -o json \
   | osc config clouds add --cloud-name mycloud --split --merge

A few properties fall out of this design that I quite like:

1. The consumer needs no auth. The connection settings the entry inherits aren't in the create response anyway, so it reads them from the local config of the active cloud.
2. It works for existing credentials too (replaying a saved response, or passing id/secret explicitly), which the monolithic command could never offer, and it could later generalize to other auth types.
3. Most of my current approach survives: the merge/collision semantics, 0600 file handling, unit tests, etc. move over nearly unchanged. What gets deleted is exactly the duplicated create logic.

Even though, there are a couple of trade-offs:

1. The secret transits stdout in the piped form.
2. There's no preflight before the server-side create anymore. If the consumer fails, the credentials are still created.

On hooks: I like the idea, but I'd suggest treating it as a separate issue. This would be the only output processor so far and a concrete command gives us the pattern to extract hooks from if more use cases how up.

If that sounds reasonable, I thing I'd like your preference on: where should the consumer live? osc config clouds add is my strawman, but sin command of its kind, you may have a better home for it in mind.

[gtema]

I wanted to implement 'osc config' series of commands for editing yamls anyway, so why not

[dmbuil]

Thanks @gtema for the feedback. I went ahead and built it as osc config clouds add.

It lives in a new openstack-cli-config crate (cli/config), hand-written rather than generated, so the osc config namespace is there to hang the rest of the yaml-editing commands off later. It's always compiled in, not feature-gated, since it has no service dependency.

$ osc identity user application-credential create --name deploy -o json \
    | osc config clouds add --cloud-name mycloud --split

Added cloud mycloud to /home/me/.config/openstack/clouds.yaml
Added cloud mycloud to /home/me/.config/openstack/secure.yaml

The behaviour, in case any of it is not what you had in mind:

• No auth is performed. Connection settings (auth_url, region_name, interface, cacert, verify) are read from the local config of the cloud selected by --os-cloud.
• Input accepts both the bare -o json resource and the wrapped {"application_credential": {...}} API form.
• Merge is the default. Same-name collision errors out unless --overwrite.
• Nothing is written until everything renders — a failed run can't leave a half-written clouds.yaml.
• Secret handling: 0600 on any file carrying the secret (pre-existing ones hardened too), Zeroizing/ZeroizeOnDrop in memory.
• Path precedence reuses the SDK's find_clouds_file/find_secure_file.

PR with all of this, here #1888 :)