[Question]: Rename `full_stack` variable - Please let us know your ideas

[widhalmt]

Ask a question

After extensive (offline) discussion while reviewing #314 @tbauriedel and I agreed that elasticstack_full_stack is confusingly named.

So calling all developers, users and all others: This variable should be true when one role inside the collection can rely on things being managed and named by other roles in the same collection. It's false when you want to interfere and manage some parts yourself.

It's easier to explain with an example: The repos role in the collection will create yum configuration to use the repositories of Elastic. There's a hardcoded name in the configuration. And package installation will use these names in connection with enablerepo to enable these very repositories. So elasticstack_full_stack: true.
But if your hosts can't reach Elastics repository servers and you configure your own repository mirror for yum to use, you can use arbitrary names. If the package installation then tries to enable the repos by name, the task will fail. So elasticstack_full_stack: false because the roles can't rely on the repo name being the hardcoded example from repos role.

Now it's your turn: How should we name the variable to cause less confusion?

[tbauriedel]

I thought about something like elasticstack_all_managed.
I don't quite like the name here either. But it is much more descriptive.

Correct me (I could be wrong), but each role in the collection should be independently usable.
Such "group variables" are used again and again. The whole thing works, but I don't think it's best practice.

In my opinion the role should have variables and these should be pre requirements. An example for this would be the elastic_repo. Define this and give it a default. If someone want to change it, he will have to change it in his playbook.

[ivareri]

Would this variable be needed if every common variable is defined in an extra role? (ref #286)

If it's still needed, something with managed in the name. (Ie: elk_fully_managed, elastic_all_managed, etc)

[widhalmt]

Ok, so two votes for managed I can live with that. Let's hear the others.

We will still need it, when #286 is closed. Maybe even more then before. @tbauriedel you're right and #286 should be the solution. We'll introduce something like "global" variables in an extra role named elasticsearch. So we could have elasticsearch_all_managed or something the like. Every role has to work on it's own. But you will need to set this variable to false so the role knows, it can't rely on information from the other roles.