As of today it was not really possible to import variables twice with same name.
It was intended to for them to be unique per role, but according to code it never really was possible.
I’d like to make it possible, it brings a challange of override though.
Today’s possible actions on import (I’m leaving out obsolete, not of an importance here):
Add we can import variable with unique name only once globally
Update if we import variable with the same name from different role, we call it “Update” and only role assignment got updated, value, overriden value, value type stays the same
My proposed solution:
Add import of ansible variables uniquelly per role as originally intended
Update import of variable that changed it’s default value, but default haven’t been overriden by user
Override for variables that has overriden default by user
Question: Is override usefull?
Problem:
What is effectivelly going to happen, if the host has more roles, that have equally named variables, assigned? Are we ok, with random choice of variable that is going to win?
Variables import is an area that definitely needs improvements, thank you for looking into this!
I think override flag is useful, it allows you to add matchers. I cannot say whether overriding default value is generally useful, but foreman_openscap currently relies on changing the default value for foreman_scap_client_policies variable of the ansible role that configures foreman_scap_client.
If we currently add 2 or more roles with the equally named variables, they will clash. I do not think it is ok as it may cause misconfigurations and unexpected behavior. To prevent the clashes, we would need to make changes to the way we generate inventory. I am not familiar with the proxy side of things and how we pass things to ansible-runner, so I cannot really say what needs to be done there.
I think I’ve abused the same word for different think. I’m talking about new Override action (for sure it needs renaming) that should just override all the changes you’ve done to your variable and import it from the capsule.
I’ve checked that briefly, right now, one variable will just override the other. I am ok to implement whatever we agree upon, but I’m not sure what that should be.
Maybe some warning on the host form would be enough? Just to see what variables are clashing and what the actual value is going to be?
I think I’ve abused the same word for different think. I’m talking about new Override action (for sure it needs renaming) that should just override all the changes you’ve done to your variable and import it from the capsule.
Oh, I see. Importing new default value from smart-proxy might be useful in some cases. There is already a related issue.
Maybe some warning on the host form would be enough? Just to see what variables are clashing and what the actual value is going to be?
It would be enough for notifying users they have a configuration problem. The ultimate fix would be to make sure users can assign and run roles with variables that have the same name, because that is the reason they want to import them into Foreman in the first place.
