A key to hold the "business unit" for resource tagging in Testing Farm
Description
As of now, the following is needed to propagate an optional business unit tag to Testing Farm, to tag provisioning resources for better accounting granularity:
tf_extra_params:
environments:
- settings:
provisioning:
tags:
BusinessUnit: foo
Can Packit add a key for this value, and take care of propagating it to Testing Farm?
tf-business-unit: foo
Benefit
- UX improvement - as a project owner, all I want is to communicate a single piece of information. To do so, I need to add (or copy & paste) 6 lines of YAML, and I need to know the special tag name.
- implementation details leaking - the name of the tag, even the fact this information is communicated to TF via a tag, are implementation details of Packit and TF integration. If the tag name changes, all affected projects would need to update their settings. If the channel used to propagate this information changes, all affected projects would need to update their settings.
Importance
Not a blocker, but the current option looks way too much like a workaround.
What is the impacted category (job)?
Testing Farm tests, General
Workaround
- [X] There is an existing workaround that can be used until this feature is implemented.
Participation
- [ ] I am willing to submit a pull request for this issue. (Packit team is happy to help!)
Hi @happz !
Thanks for creating the issue!
I hope this is the last TF option we need to implement manually... Actually, that's why we've introduced tf_extra_params ...;) But I agree would be easy to do and can simplify this.
(As discussed internally, we can't decide this value automatically. Maybe use a default constructed from the project's URL, but this info is already sent with the payload so it can be used on the TF part.)
Since there is a workaround and it's a one-time action, I don't promise anything but we can guide you to implement that if you want to speed this up.
What's needed:
- [ ] Add the option to the schema. Similarly to other options.
- [ ] Add the config value to the payload
Oh, and an idea. We can enforce this for people using internal TF, WDYT? (edit: On the other hand, we can't easily check that it's the correct one..;)
Still relevant but not high priority. If someone wants to give it a look we can help.