-
-
Notifications
You must be signed in to change notification settings - Fork 101
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
WIP initial auto jenkins provisioning #192
Conversation
FYI https://ci.adoptopenjdk.net/computer/build-cloudcone-ubuntu1604-x64-1/ is an example of a node that configured using this playbook: labels: TODO:
I feel that this can be merged without the JAVA dirs for now and they can be manually added, I will work on automating this at a later date |
be81c6f
to
df6316e
Compare
- name: SSH into the Jenkins and excute the jenkins-create-node.sh script | ||
become: false | ||
# TODO fetch a var instead of hard coding linux | ||
local_action: command ssh -o StrictHostKeyChecking=no jenkins@ci.adoptopenjdk.net "/home/jenkins/.jenkins/jenkins-create-node.sh {{ inventory_hostname }} {{ ansible_host }} /home/jenkins linux,{{os}},{{arch}},{{provider}},{{ansible_architecture}},{{type}},{{ansible_distribution|lower}},{{ansible_distribution|lower}}{{ansible_distribution_major_version}}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These should be vars
jenkins@ci.adoptopenjdk.net --> {{ Jenkins_Username }}@{{ Jenkins_Server }}
/home/jenkins (x2) --> /home/{{ Jenkins_Username }}
--- | ||
- name: Check if machine exists in jenkins | ||
uri: | ||
url: "https://ci.adoptopenjdk.net/computer/{{ ansible_hostname }}/api/json" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be a var
url: "https://ci.adoptopenjdk.net/computer/{{ ansible_hostname }}/api/json" -->
"https://{{ Jenkins_Server }}/computer/{{ ansible_hostname }}/api/json"
@@ -0,0 +1,15 @@ | |||
--- |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
##################
# Jenkins_Master #
##################
@@ -17,7 +17,7 @@ | |||
# Script must exist on Nagios Master | |||
# | |||
- name: SSH into the Nagios Master and excute the Nagios_Ansible_Config_tool.sh script | |||
local_action: command ssh -o StrictHostKeyChecking=no root@{{ Nagios_Master_IP }} "/usr/local/nagios/Nagios_Ansible_Config_tool/Nagios_Ansible_Config_tool.sh {{ ansible_distribution }} {{ ansible_architecture }} {{ inventory_hostname }} {{ ansible_default_ipv4.address }} " | |||
local_action: command ssh -o StrictHostKeyChecking=no root@{{ Nagios_Master_IP }} "/usr/local/nagios/Nagios_Ansible_Config_tool/Nagios_Ansible_Config_tool.sh {{ ansible_distribution }} {{ ansible_architecture }} {{ inventory_hostname }} {{ ansible_host }} " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nagios will require the IP address of the client machine
Which out it, Nagios will not be able to find the client machine by unresolvable hostnames
abc123.adoptopenjdk.net
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ansible_host is the IP address that is set in the yml inventory :)
This is great work, fully automating the Jeknins end of things |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to go
6a1550a
to
5939bfb
Compare
@gdams Have the hostnames been standardised so that this PR is safe to merge? |
I'm going to leave this open until I've worked out how to set the java paths as vars |
I've now added java paths for Ubuntu ONLY. |
I'm going to bring @smlambert into this conversation because I want to make sure that the testing team is happy with the labels that are generated by this PR. I know that there was an issue that Shelley raised about standardising them but I'm not sure if this schema will work. An example test machine would have the following labels: |
Yes, we have started using some of the labels discussed in #93, particularly our Jenkins scripts look for sw.os.xxx, and hw.arch.xxx. Thanks @gdams for noticing that I had added those labels manually to the previous 2 x86-64_linux machines we have for test. The reason I need/want the standard naming is so that downstream CI servers and these AdoptOpenJDK servers (ci.adopt and ci-jck.adopt) align in a labelling strategy, and we can directly reuse the Jenkins collateral from AdoptOpenJDK. The more alignment we have, the more people we can bring to the AdoptOpenJDK project, as the work here is then directly reusable. |
thanks for that @smlambert. Is the above schema that I mentioned going to be accpetable for you or am I going to need to change it? Basically I am going to either have to modify all of the test jobs or all of the build jobs |
I think we should get final agreement on #93 and have all machines following the agreed upon schema, I can help update what ever build jobs would need it. I also am suggesting we rethink how we are using the machines, and whether we should consider having them configured for dual purpose, see #199 (comment) If the requirement is as @karianna says "each type of build does need to run on an identical host for consistency and auditability", then build machines can be statically allocated, but to avoid them sitting idle, all but one of each platform of build machines could be labelled as ci.role.test and ci.role.build, so that when they are idle, they go into the pool of machines available to test jobs (keeping 1 as exclusively ci.role.build, is the cheap way of ensuring builds never wait for tests to finish, though there are also Jenkins plugins that will prioritize certain jobs over others, that could be combined for a hybrid usage story). |
I think we can loosen the requirement of identical host as long as the libraries (native or otherwise) that we build with are identical. If we deviate from that, then we need to make that clear to the end user (again that might be acceptable. |
Can we please have this as a role that is enabled via option and not on as a default? There are users that would like to consume these scripts and not have to add to a jenkins server. |
@gdams there's conflicts. |
I think that this was being closed in favour of https://github.com/AdoptOpenJDK/openjdk-jenkins-helper but I'll let someone confirm that before closing |
Hmmm hadn't seen that repo (catching up on old PRs just now) @karianna @smlambert Can we do something with this, possibly in light of George's comment from about 3 months ago? |
I think it is worth having an infra call about this, so we can discuss requirements & options. There are varying approaches and opinions, and It will be good to converge. |
@smlambert Yep - I'm meeting George and John online tomorrow at 1900 UK time if maybe after that suits? |
@karianna What was the outcome of that meeting in September 2018? ;-) |
Hmmm, yes well. Let's have a new call between @gdams and @smlambert on this one. @gdams - If it's trivial you might as well solve the merge conflict and address @jdekonin's comment as well. |
This probably shouldn't be run until we have standardised our hostnames as it could create a load of rogue jenkins nodes that we probably wouldn't want