Skip to content
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

Closed
wants to merge 11 commits into from

Conversation

gdams
Copy link
Member

@gdams gdams commented Feb 9, 2018

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

@gdams gdams requested a review from bblondin February 9, 2018 00:11
@gdams gdams changed the title WIP: initial auto jenkins provisioning initial auto jenkins provisioning Feb 9, 2018
@gdams
Copy link
Member Author

gdams commented Feb 9, 2018

FYI https://ci.adoptopenjdk.net/computer/build-cloudcone-ubuntu1604-x64-1/ is an example of a node that configured using this playbook:

labels: linux ubuntu1604 x64 cloudcone x86_64 build ubuntu ubuntu16

TODO:

  • Add JDK7_BOOT_DIR, JDK8_BOOT_DIR, JDK9_BOOT_DIR.

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

@gdams gdams force-pushed the jenkins_auto branch 2 times, most recently from be81c6f to df6316e Compare February 9, 2018 03:51
- 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}}"
Copy link
Contributor

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"
Copy link
Contributor

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 @@
---
Copy link
Contributor

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 }} "
Copy link
Contributor

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

Copy link
Member Author

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 :)

@bblondin
Copy link
Contributor

bblondin commented Feb 9, 2018

This is great work, fully automating the Jeknins end of things

Copy link
Contributor

@bblondin bblondin left a 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

@gdams gdams force-pushed the jenkins_auto branch 2 times, most recently from 6a1550a to 5939bfb Compare February 9, 2018 20:32
@karianna
Copy link
Contributor

@gdams Have the hostnames been standardised so that this PR is safe to merge?

@gdams
Copy link
Member Author

gdams commented Feb 12, 2018

I'm going to leave this open until I've worked out how to set the java paths as vars

@gdams gdams changed the title initial auto jenkins provisioning WIP initial auto jenkins provisioning Feb 12, 2018
@gdams
Copy link
Member Author

gdams commented Feb 12, 2018

I've now added java paths for Ubuntu ONLY.

@gdams gdams added the ansible label Feb 25, 2018
@gdams
Copy link
Member Author

gdams commented Mar 3, 2018

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:
linux ubuntu1604 x64 cloudcone x86_64 test ubuntu ubuntu16

@smlambert
Copy link
Contributor

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.

@gdams
Copy link
Member Author

gdams commented Mar 4, 2018

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

@smlambert
Copy link
Contributor

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).

@karianna
Copy link
Contributor

karianna commented Mar 5, 2018

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.

@gdams gdams mentioned this pull request Mar 5, 2018
@jdekonin
Copy link
Contributor

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.

@karianna
Copy link
Contributor

karianna commented Jun 5, 2018

@gdams there's conflicts.

@gdams
Copy link
Member Author

gdams commented Jun 6, 2018

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

@sxa
Copy link
Member

sxa commented Sep 3, 2018

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?

@smlambert
Copy link
Contributor

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.

@karianna
Copy link
Contributor

karianna commented Sep 3, 2018

@smlambert Yep - I'm meeting George and John online tomorrow at 1900 UK time if maybe after that suits?

@sxa
Copy link
Member

sxa commented Jan 7, 2020

@karianna What was the outcome of that meeting in September 2018? ;-)

@karianna
Copy link
Contributor

@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.

@sxa sxa marked this pull request as draft June 1, 2020 19:30
@gdams gdams closed this Aug 25, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants