AndreasF
Cadet
Cadet
  • 196 Views

Difference between course guide and video/best practices

Jump to solution

I just have watched a video for the first time, and I have noticed, that the best practices mentioned by the presenter and the best practices on the Ansible website differ a lot from the content of the course book.

The most noticeable detail is that in most of the examples and exercises in the training material, FCDN is almost never used. Further the video recommends putting "when", "register" and the like before the actual module, while in the course guide this is consitently not the case.

Of course, I don't expect an immediate fix, but I suggest to incorporate the best practices in the training material (everywhere).

I am very happy, that I did not neglect the video this time, as I got many useful tips (unfortunately more than from the course guide)!

1 Solution

Accepted Solutions
Travis
Moderator
Moderator
  • 181 Views

@AndreasF -

So I would hope the course guide is using the FQDN everywhere now. I'm guessing there are a few spots it might be off still, if that is the case, please submit a support ticket from RHLS and it can be addressed with the next course update. 

In terms of differences between videos, course guides, and Ansible upstream ...

  • We have multiple versions of the RH294 Ansible course. The most current one is based on RHEL9 and AAP2.2 in which FQCN should be used for Ansible modules
  • RHLS has some additional videos and content that might be newer/older based on subscription levels
  • Upstream Ansible isn't fully controlled by Red Hat so Best Practices there might not always match what the current best practices are and also keep in mind that best practices and recommendations on what to do can change over time.

https://redhat-cop.github.io/automation-good-practices/

https://github.com/redhat-cop/automation-good-practices

Red Hat does maintain some best practices for Ansible, but those aren't always updated. I've given the GithubIO page as well as the source and you can see that some items haven't changed in years, and some are a few months old.

The videos are always great as you have an instructor that can add to content that isn't in the book and our live courses are even better as I teach a ton of Ansible courses and I'm constantly updating my demos and providing new guidance based on questions and scenarios that participants pose during the delivery. 

Bottom line, not everything can be covered in a self-paced course (especially reading a course guide) and Best Practices are guidelines that people come up with. One of the more important things I stress is in the DO374 is coming up with "Best Practices" and a team working agreement for your office / team / whatever where you all agree to developing Ansible playbooks in a certain way (where to store variables, where to put play and task directives, where to place handlers in the playbook, where to put module/task options) and stick with it. Everyone is going to have preferences, but if you can pick something the entire team can agree on, do that.

I personally work with teams and I like the conditions at the bottom of a module for a task so the (when, register, loop) are all at the bottom. I also insist as well as the rest of the team to always have state (even though it has a default and can be left out) that way people know what is intended and future changes to the module don't break your playbook.

Travis Michette, RHCA XIII
https://rhtapps.redhat.com/verify?certId=111-134-086
SENIOR TECHNICAL INSTRUCTOR / CERTIFIED INSTRUCTOR AND EXAMINER
Red Hat Certification + Training

View solution in original post

2 Replies
Chetan_Tiwary_
Moderator
Moderator
  • 181 Views

@AndreasF Thank you for your feedback - I will document this feedback and forward this to the concerned team for consideration. Thank you for your time and feedback !

 

@jmeegan_rhls  for visibility. 

0 Kudos
Travis
Moderator
Moderator
  • 182 Views

@AndreasF -

So I would hope the course guide is using the FQDN everywhere now. I'm guessing there are a few spots it might be off still, if that is the case, please submit a support ticket from RHLS and it can be addressed with the next course update. 

In terms of differences between videos, course guides, and Ansible upstream ...

  • We have multiple versions of the RH294 Ansible course. The most current one is based on RHEL9 and AAP2.2 in which FQCN should be used for Ansible modules
  • RHLS has some additional videos and content that might be newer/older based on subscription levels
  • Upstream Ansible isn't fully controlled by Red Hat so Best Practices there might not always match what the current best practices are and also keep in mind that best practices and recommendations on what to do can change over time.

https://redhat-cop.github.io/automation-good-practices/

https://github.com/redhat-cop/automation-good-practices

Red Hat does maintain some best practices for Ansible, but those aren't always updated. I've given the GithubIO page as well as the source and you can see that some items haven't changed in years, and some are a few months old.

The videos are always great as you have an instructor that can add to content that isn't in the book and our live courses are even better as I teach a ton of Ansible courses and I'm constantly updating my demos and providing new guidance based on questions and scenarios that participants pose during the delivery. 

Bottom line, not everything can be covered in a self-paced course (especially reading a course guide) and Best Practices are guidelines that people come up with. One of the more important things I stress is in the DO374 is coming up with "Best Practices" and a team working agreement for your office / team / whatever where you all agree to developing Ansible playbooks in a certain way (where to store variables, where to put play and task directives, where to place handlers in the playbook, where to put module/task options) and stick with it. Everyone is going to have preferences, but if you can pick something the entire team can agree on, do that.

I personally work with teams and I like the conditions at the bottom of a module for a task so the (when, register, loop) are all at the bottom. I also insist as well as the rest of the team to always have state (even though it has a default and can be left out) that way people know what is intended and future changes to the module don't break your playbook.

Travis Michette, RHCA XIII
https://rhtapps.redhat.com/verify?certId=111-134-086
SENIOR TECHNICAL INSTRUCTOR / CERTIFIED INSTRUCTOR AND EXAMINER
Red Hat Certification + Training
Join the discussion
You must log in to join this conversation.