-
Notifications
You must be signed in to change notification settings - Fork 639
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: Ability to add custom labels to EE pods #242
Comments
I'd like to add to this request the ability to add custom annotations to the EE pod. With a custom annotation the EE could use the Hashicorp Vault agent injector to access secrets in Vault. |
Meanwhile I found that you can do this already by changing the pod definition in the tower instances Interface. |
@lukasertl thank you so much, that worked perfectly! |
Just for the documentation, here is a screenshot of how you extend custom labels to your Instance Groups --> edit the instance group ---> So I guess we already have a place for that in the AWX itself which allows more freedom than setting it on the spec itself. Are you good with this approach @RylandDeGregory? |
Hey @tchellomello I understand that this is possible, and I've gotten it working using this approach. But, telling me to go make a pod spec customization in the GUI is not the answer I wanted. This is squarely a code change, not a DB or UI change, and should be possible to set in the code that I use to deploy AWX. |
I hear you @RylandDeGregory. As this can be overridden by the webUI, this change would need to be coordinated with AWX as to what would happen when you have in both places. For now, leaving it open with |
Looks like I maybe hitting this issue too, our use case is we want to setup a dedicated nodepool in AKS, specifically for execution environments. So, we'd need the ability to configure all EE pods to use this label (and namespace) ideally via awx-operator. I think the solution listed here is great, we just need to take the next step to expose it to automation. |
This will allow us to control the default container group created via settings, meaning we could set this in the operator and the default container group would get created with it applied. We need this for ansible/awx-operator#242
@pabelanger for applying changes to the pod spec for the default container group (which is what gets applied to pods provisioned for jobs) I think we need something like ansible/awx#11395. I don't think any changes to the operator are necessary, as we can use Not 100% sure on the formatting we will need if it is multi-line From my reading, #676 would apply to the awx deployment pods themselves. That is probably a good use case but I don't think it solves your problem |
This will allow us to control the default container group created via settings, meaning we could set this in the operator and the default container group would get created with it applied. We need this for ansible/awx-operator#242
This will allow us to control the default container group created via settings, meaning we could set this in the operator and the default container group would get created with it applied. We need this for ansible/awx-operator#242 Deepmerge the default podspec and the override With out this, providing the `spec` for the podspec would override everything contained, which ends up including the container used, which is not desired Also, use the same deepmerge function def, as the code seems to be copypasted from the utils
This will allow us to control the default container group created via settings, meaning we could set this in the operator and the default container group would get created with it applied. We need this for ansible/awx-operator#242 Deepmerge the default podspec and the override With out this, providing the `spec` for the podspec would override everything contained, which ends up including the container used, which is not desired Also, use the same deepmerge function def, as the code seems to be copypasted from the utils
I am attempting to use AAD Pod Identity to grant my AWX environment implicit access to Azure Key Vault using a user-assigned Managed Identity. One of the requirements is that the pods be labeled with the name of the Managed Identity to use, like this:
The process works as expected, and I was able to validate by performing
kubectl label pod awx-pod aadpodidbinding=MANAGED_IDENTITY_NAME
, but AWX generates a new pod for each job. This prevents the authentication from working unless the EE pods can be created by the operator with that label.I understand that there are already variables that set pod labels for use in node selection, and we already have variables that control annotations for ingress resource definitions. My question is, can there be another AWX spec variable added to set custom labels on EE pods? I know that my ask is specifically about AAD pod identity, but I'm sure there are other use cases for user-defined pod labels.
The text was updated successfully, but these errors were encountered: