I'm starting to think thge CH6 gradiung script has something against me. I can't work out why it thinks several of the checks fail.
Taking a few of them in order. The site.yml 'failure' When i execute the site.yml playbook, it works fine. e.g.
The 'missing' or faulty copy task... My original did the right thing. But used
so thinking the grading script was being a bit pedantic, I went back and copied (Via copy & paste) the solution. It still claims a fail.
Maybe it was checking the commit message... So I updated somethign else and used a commit message 'Lab updates'. Still a fail.
I'm almost at a loss. Burning through the hours without being able to work out what the grading script wants, when it apparently doesn't even want the canned solutions.
It also doesn't like my refactoring for the httpd package installs...
But then it also doesn't like a copy of the canned solution...
I'm clearly missing something obvious.
Accepted Solutions
Ahhh...
There seems to be two assumptions
1. The lab will be completed in 1 session perhaps?
2. You won't make any typos and your resulting playbook will run through completely without errors on the first execution.
IIRC I did the lab start. Did some edits. Then (As usual in my day) I had to go do some real work. Everything got shutdown. Somewhere (Possibly) after an initial run of site.yml that struck an error in a builtin config... My favourite at the moment appears to be using path: in ansible.builtin.copy instead of dest:
If that error is in the handler, then the first time you run it, the haproxy config is done. And the playbook errors on the handler.
However... The second (And subsequent) times you run it. The haproxy config is not changed. Thus the handlers don't get called. And because the servers were rebooted, there's no files in /tmp that the handlers would have left the first time around. And the playbook succeeds
You can duplicate this easily. Just make an error in the handler (e.g. the above. replace dest: with path: in the copy). It'll fail. Fix it, and run again, and the handlers don't execute. Because the config didn't change.
This explains why site.yml fails in the grading but continually succeeds at the command line. When the grading runs, it removes the haproxy packages & config.
It then does some stuff, and runs the playbook, which fails (Error in the handler). You then run it yourself because of course it ran fine last time you ran it, and it runs fine again. You can do that ad-nauseaum because only the grading removes the haproxy packages & config from servera.
I'm at a loss however why the grading told me the refactoring of the apache package installs hadn't been done. Because after fixing the handler, the grading for the refactoring now gets a PASS.
So, the solution was obvious and easy. But only if you know the mechanism of how the gradings and the labs work and spend some time running through it in your head and watching the grading process... e.g.
It would be nice to have an easy way to reset the environments so each time you run your playbooks it's starting from a known point.
Ahhh...
There seems to be two assumptions
1. The lab will be completed in 1 session perhaps?
2. You won't make any typos and your resulting playbook will run through completely without errors on the first execution.
IIRC I did the lab start. Did some edits. Then (As usual in my day) I had to go do some real work. Everything got shutdown. Somewhere (Possibly) after an initial run of site.yml that struck an error in a builtin config... My favourite at the moment appears to be using path: in ansible.builtin.copy instead of dest:
If that error is in the handler, then the first time you run it, the haproxy config is done. And the playbook errors on the handler.
However... The second (And subsequent) times you run it. The haproxy config is not changed. Thus the handlers don't get called. And because the servers were rebooted, there's no files in /tmp that the handlers would have left the first time around. And the playbook succeeds
You can duplicate this easily. Just make an error in the handler (e.g. the above. replace dest: with path: in the copy). It'll fail. Fix it, and run again, and the handlers don't execute. Because the config didn't change.
This explains why site.yml fails in the grading but continually succeeds at the command line. When the grading runs, it removes the haproxy packages & config.
It then does some stuff, and runs the playbook, which fails (Error in the handler). You then run it yourself because of course it ran fine last time you ran it, and it runs fine again. You can do that ad-nauseaum because only the grading removes the haproxy packages & config from servera.
I'm at a loss however why the grading told me the refactoring of the apache package installs hadn't been done. Because after fixing the handler, the grading for the refactoring now gets a PASS.
So, the solution was obvious and easy. But only if you know the mechanism of how the gradings and the labs work and spend some time running through it in your head and watching the grading process... e.g.
It would be nice to have an easy way to reset the environments so each time you run your playbooks it's starting from a known point.
