-
Notifications
You must be signed in to change notification settings - Fork 10
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
Enforce repos only with full stack #314
Conversation
RPM installation automatically enabled the Elastic Stack repositories this collection will add to a host. But if you have another tool to manage your repositories, they might have other ids and names. So I added separate installation tasks. If `elasticstack_full_stack` is set to `true`, everything stays as it was. The task will forcefully enable the repository and then install the package. But if `elasticstack_full_stack` is set to `false` it will just ignore the repository and expect the package to be available. While working on this I found a different approach to choosing the correct version in the `beats` role. I couldn't afford to fix it all in a single PR so I opened #313 for this. fixes #312
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't it be better to have a variable to define the name of the repository?
With that the second "install" task is not needed anymore.
Default should be the name provided by the repos role. If someone wants to use another repository they can define it in this variable.
I just wanted to start implementing your proposed change @tbauriedel . BUT we already have a variable in the name of the repository (showing the release version). And using variables in variables isn't a great idea in Ansible. I would change the name of the repo but I guess the current setup is what makes upgrades through major releases easier. What do you think? Do you have an idea how to work around this? |
You could combine the variables to have one. But thats also just a "hacky workaround". I don't like the whole thing right now either. It's all very hacky. But I can't think of a better solution at the moment. |
That can only work with another extra task assembling the name when the value's empty. Because, if we allow to have arbitraty repo names then we can't make any assumptions about the nomenclature. |
RPM installation automatically enabled the Elastic Stack repositories this collection will add to a host. But if you have another tool to manage your repositories, they might have other ids and names.
So I added separate installation tasks. If
elasticstack_full_stack
is set totrue
, everything stays as it was. The task will forcefully enable the repository and then install the package.But if
elasticstack_full_stack
is set tofalse
it will just ignore the repository and expect the package to be available.While working on this I found a different approach to choosing the correct version in the
beats
role. I couldn't afford to fix it all in a single PR so I opened #313 for this.fixes #312