Very nice improvement with only one play and using the variables in the inventory file. I'm sure, there is another nifty solution to the pain to add the variables to every host in the inventory. Eager to continue with this great course. Thank you, Jay! 🤛
Learning Ansible right now with the RH294 program, and they actually recommended declaring host-specific variables in another host_vars folder. Just throwing this out there, not judging. Great work.
Thank you Jay! Really enjoying this series. Watching your videos and following along with all this cool stuff makes me feel like someday I might be able to become a system administrator.
this is an excellent demo using the generic package module across various distributions when the package names vary. good job! keep sharing more. i'm surprised to see a demo using nano for YAML. VIM is a lot more flexible and better suited for YAML imo. I haven't watched the other videos yet (and plan too), perhaps you explained why you use one over the other. Not judging here, just commenting. thanks for sharing this series.
Its a lot easier for someone to follow along step by step if he is using nano. Vim basically requires its own tutorial. Totally overkill for the scope of this series.
there is an ansible_distribution_version == 'Ubuntu' in the first play that will never get matched. It should just say ansible_distribution == 'Ubuntu'
Why is it that the "update_cache" parameters was left in the yml file and it's not a valid parameter for the package module yet ansible didn't fail ? Does ansible just silently ignores invalid parameters ? Can we force it to display at least a warning ?
Dear Jay, so far I love your video, the only point so far is that I didn't get how we can familiarize ourselves with Ansible commands. How do you know what you should use? I hope in the next video I can see it. Anyway thank you.
I can't find the update_cache parameter for the package module. Is it some kind of hidden parameter which actually works? Great video and the whole series by the way. Thank you!
I expect this consolidation of tasks / plays to change the previous behaviour because of this missing parameter. While the old plays would have updated the packages in case of incoming updates, this module probably won't update any already installed package. This might or might not happen because of the missing documentation ¯\_(ツ)_/¯
So when you consolidate update cache and install package in the same task, does the update cache get executed first or does the install? Or does it depend on the order in which we write it in the playbook?
How come the code still run correctly, for example at 4:30, when you used ansible_distribution_version == "Ubuntu" (which is wrong). You can see the inconsistency in the file when both "ansible_distribution" and "ansible_distribution_version" refer to "Ubuntu" (the latter should have referred to the version number like 18.04 instead). Same with "CentOS".
Yes correct and for that reason it skips the task for all hosts, as it doesn't meet the requirements. It should refer both the "ansible_distribution" variable. Probably, Jay didn't undo the changes when he tried to inform us that we can be very specific, as we can target e.g. CentOS but only specific versions e.g. 8.0.4 etc.
That's correct, I noticed it was only on the update_cache section it skipped, I did that myself over the CentOS section and obviously it didn't work, not to blame Jay, he clearly showed before an example of both options, I remembered it the hard way after seeing it fail. He probably missed the fact that the update_cache section skipped and didn't fix it at the moment.
I have added apache_package to inventory file but still when i execute the playbook it says variable is undefined.. i included debug task to see if variable is picked from inventory file.. it is showing variable is not defined.. how should i solve this issue
in this video and the previous one, you actually made a little mistake on the first task, you used "ansible_distirbution_version" instead of "ansible_distribution"
we decreased tasks from 6 to 2 as we could see in the results we see 2 instead of 6 now so now if one task fails , how could we find out which of these three failed (as it only shows 2 fields : the name and status ok or skipped or failed)?
