ansible,jenkins: smartos18 in ci and ci-release #1769
Conversation
| @@ -8,7 +8,7 @@ | |||
| # This depends on ansible being able to run curl locally, YMMV, if it doesn't | |||
| # work, try changing the local_action to a remote one: | |||
| # raw: curl -sL https://www.samba.org/ftp/ccache/ | |||
| local_action: command shell -sL https://www.samba.org/ftp/ccache/ | |||
| local_action: command shell curl -sL https://www.samba.org/ftp/ccache/ | |||
There was a problem hiding this comment.
removed in #1723, hopefully by accident, also I discovered that smartos is shipping with a recent enough ccache now so we don't even take this path for smartos18
There was a problem hiding this comment.
Was in #1735, and was unintentional, sorry, I was flailing around trying to get the wget to work.
There was a problem hiding this comment.
ohhh, yeah, been there with wget, sorry for your pain
| @@ -5,4 +5,5 @@ | |||
| # | |||
|
|
|||
| dependencies: | |||
| - { 'role': 'java-base' } | |||
There was a problem hiding this comment.
removed in #1723, just for debugging or speedup during dev hopefully
There was a problem hiding this comment.
It was removed because the dependencies were wrong. The task that depended on it needed to create some directory locations before it would be able to be installed.
There was a problem hiding this comment.
Instead, it was integrated into the task itself in the right place to satisfy ordering.
There was a problem hiding this comment.
So this is broken for the smartos install at least, it doesn't get java installed without it. How are we supposed to handle this now?
There was a problem hiding this comment.
There was a problem hiding this comment.
^--- that stanza should be hit, does it not get triggered on smartos?
There was a problem hiding this comment.
ah, here's the problem: that java-base inclusion is probably OK but it's too late because it comes after the service call service: name=jenkins state=restarted enabled=yes - so that's going to try and start jenkins but if there's no Java it'll fail, which is exactly where I was failing.
In my latest commit here, 436b080, I've removed it again from meta/main.yml and instead have moved up the include_role to just before the first startup (service) call. I don't have a bare host to test on but re-ran it on one of the smartos18 machines and watched the output and it appeared to do it in a workable order.
This isn't ideal IMO because an include_role in the middle of a set of tasks is going to get confusing for future debugging. It's probably technical debt we have to accept for now but some more refactoring is probably in order for jenkins-worker.
PTAL at latest.
There was a problem hiding this comment.
Your explanation makes sense to me, I ran into the issue on a fresh install, so didn't hit the restart problem.
There was a problem hiding this comment.
@rvagg thanks for figuring that out. My bad as I made the move in Sam's PR. Not sure why we did not see the failure when running ansible on the machine I had to make the change for but glad you have a single solution at least for now.
|
The old machines are running a little heavy, could we provision the new ones a little beefier (maybe 4 cores)? |
|
@refack in my versionselectorscript I've tightened the rules a little more, basically only smartos18 is going to be run for master+, maybe this will help matters? Post merge that graph will change to incorporate these new machines but they're still only 2-core ones, might be worth waiting to see though? |
Sure, no rush. Was just a "while you're there"... What I did notice is that for SmartOS 17 there seem to be a substantial difference between worker 1 and 2: |
|
smartos17-x64-1 and -2 are the same type, g4-highcpu-4G, but it doesn't really surprise me that there are differences. I'll try and remember to reprovision -2 soon, just not right now. |
Got the machines provisioned, won't be active until we get the versionselectorscript changes in place though.
Picked up a couple of strange removals from #1723, probably just typos or debugging changes /cc @sam-github.