Missing parameters for token.create_or_update_role

[bendem]

A bunch of restrictions are now available for token roles that aren't supported by hvac yet:

allowed_policies_glob
disallowed_policies_glob
token_bound_cidrs
token_explicit_max_ttl
token_no_default_policy
token_num_uses
token_period
token_type

[briantist]

Hi @bendem , welcome back! Thank you for opening this issue. Are you working on or interested in posting a PR, or is this up-for-grabs?

[bendem]

I'm not working on this at the moment no.

I have been wondering if it would make sense to use add some kwargs to vault methods to avoid blocking users when hvac is lagging behind on new parameters. I have implemented something similar in the ansible module we use on top of hvac, but I don't think I'll have time to look into hvac for the following weeks.

TerryHowe/ansible-modules-hashivault@6cffb8d
TerryHowe/ansible-modules-hashivault#445

Another solution I was thinking about that would allow hvac to keep validating parameters would be to use kwargs, but delegate to stubs generated from the OpenAPI spec (https://developer.hashicorp.com/vault/api-docs/system/internal-specs-openapi). This would make updating much faster and could even be automated so that hvac is always up to date with the latest vault API.

[briantist]

Partially resolved by #842

---

I'm not working on this at the moment no.

No worrieds thanks anyway for reporting it.

I have been wondering if it would make sense to use add some kwargs to vault methods to avoid blocking users when hvac is lagging behind on new parameters. I have implemented something similar in the ansible module we use on top of hvac, but I don't think I'll have time to look into hvac for the following weeks.

TerryHowe/ansible-modules-hashivault@6cffb8d TerryHowe/ansible-modules-hashivault#445

Thanks, the main thing I would be concerned about with an approach like that is doing meaningful testing. In units we can mostly just check to see if those parameters are passed through the methods, but in integration tests we probably want some awareness of what parameters mean so we can test those. It also means we would lack documentation.

We could still go back and these as explicit parameters as we find them, but with a workaround, those reports may never come either.

I might also be misunderstanding the solution somewhat.

I guess my current feeling is that I'd rather add parameters more intentionally and have it be clear what the library intends to support. It does mean we can lag behind (especially if we're lacking in contributors and maintainers) but I'm hoping to solve for that with more participation: #994

btw I haven't used those Ansible modules, but I do also maintain the community.hashi_vault collection that's included in the Ansible package: https://github.com/ansible-collections/community.hashi_vault

Another solution I was thinking about that would allow hvac to keep validating parameters would be to use kwargs, but delegate to stubs generated from the OpenAPI spec (https://developer.hashicorp.com/vault/api-docs/system/internal-specs-openapi). This would make updating much faster and could even be automated so that hvac is always up to date with the latest vault API.

This is possible, but I think it would represent a pretty large change in the structure of hvac and I don't think we have the contributor base to see it through at the moment. To me it also has some of the same concerns around testing. Still, it might be something that acts well as a supplement if it can be implemented that way.

I heard about a possible python library being built from the ground up to do this for Vault (auto-generated based on API spec), but I'm not involved in that and don't know if it was ever started or what the status is.

---

Please feel free to submit either of these suggestions as separate proposals that could be discussed independently:
https://github.com/hvac/hvac/discussions/categories/ideas