Build Farm Documentation Clarification

[Tom Moore]

Hi all,

I am a bit of a neophyte when it comes to ROS build server setup, so you'll have to forgive me if the answers to any of these questions are obvious.

For some background, I have provisioned machines as per the recommendations on this page. I have also created a private "fork" of the configuration repo as specified here.

My understanding is that after modifying the configuration settings for the master, slave, and repo servers, I will clone this configuration repository on each server and run the necessary configuration scripts, which will use the parameters I specified in those .yaml files and run whatever processes are necessary to configure and start Jenkins on each machine. Please let me know if I am mistaken.

Now, I am trying to work through the configuration settings, and have a number of questions on the instructions in the buildfarm_deployment documentation.

On all three:
jenkins::slave::ui_user and jenkins::slave::ui_pass are passed to the jenkins::slave puppet module. You may need to update them depending on your slave's security model. See:
https://github.com/jenkinsci/puppet-jenkins#slaves
https://github.com/jenkinsci/puppet-jenkins/blob/d2ceee61c1971256427dee11dd6472d30bf95228/manifests/slave.pp#L20-L21

First, I'm assuming puppet is a Jenkins module that will be installed via the setup scripts, correct? If so, where do we derive the username and password here? Are we making them up and just ensuring that they are consistent between machines?

This is the password for the slave to access the master
user::admin::password_hash
On the master this should be the hashed password from above
The easiest way to create this is to setup a jenkins instance. Change the password, then copy the string out of config file on the jenkins server.

For this, I just set up and ran a Jenkins server per their setup instructions, went through the configuration via the web front end, and then found the directory and file that contained of the username and hashed password in /var/lib/jenkins/users/<jenkins_admin_username>/config.xml. All of that was pretty straightforward, but it's not yet clear to me how this information is used when we run the setup script(s) on each machine. Is it using the same Jenkins instance I created? I'm assuming not.

autoreconfigure::branch
If you are forking into a repo and using a different branch name, update the autoreconfigure command to point to the right branch.

I'm assuming that this means that if our "fork" of the private configuration repo has a branch name that isn't 'master', we need to change it to whatever our branch is.

ssh_keys
Configure as many public ssh-keys as you want for administrators to log in. It's recommended at least one for root.
On the repo machine make sure there is at least one key for the jenkins-slave user matching the ssh private key jenkins::private_key provisioned on the master.

For the second bullet point, there is no parameter 'jenkins::private_key' specified in the server's common.yaml; I'm assuming it means 'jenkins::private_ssh_key'. In the default configuration file (server/common.yaml), there also appears to be a public key for the jenkins-slave user. Is that required?

Further down in the parameters that are specifically for master, we have:

credentials::jenkins-slave::username
The name of the credentials
credentials::jenkins-slave::id
A UUID for the credentials in the format 1e7d4696-7fd4-4bc6-8c87-ebc7b6ce16e5
credentials::jenkins-slave::passphrase
The hashed passphrase for the key. The UI puts this has in if there's no passphrase 4lRsx/NwfEndwUlcWOOnYg==
If you would like to modify these values from the default it will likely be easiest to boot an instance. Change the credentials via the UI, then grab the values out of the config file.

 

The description for the username isn't clear to me. Is this setting related to the jenkins::slave::ui_user setting? Is the passphrase for the jenkins-slave ssh key further down in the example configuration? Is using the default values acceptable?

Also, after a bit more digging, I found this page. The directions say

First you need to either fork the ros_buildfarm_config repository or create a repository containing the same configuration files.
Then you must update the configuration files:

It then lists a number of other configuration settings that aren't in the ros_buildfarm_config files in the repo, such as notifications and status_page_repositories. There are also several references to "entry point yaml." Is that simply referring to each common.yaml file?

Anyway, I think that's about it. Apologies for the tome.

Thanks,

Tom

[lu...@savioke.com]

Hi Tom!

I'm currently going through the same process so take my answers with some caution :)

On Monday, April 25, 2016 at 4:39:29 PM UTC-3, Tom Moore wrote:

Hi all,

I am a bit of a neophyte when it comes to ROS build server setup, so you'll have to forgive me if the answers to any of these questions are obvious.

For some background, I have provisioned machines as per the recommendations on this page. I have also created a private "fork" of the configuration repo as specified here.

My understanding is that after modifying the configuration settings for the master, slave, and repo servers, I will clone this configuration repository on each server and run the necessary configuration scripts, which will use the parameters I specified in those .yaml files and run whatever processes are necessary to configure and start Jenkins on each machine. Please let me know if I am mistaken.

Yes, that is what I'm doing.

 

Now, I am trying to work through the configuration settings, and have a number of questions on the instructions in the buildfarm_deployment documentation.

On all three:
jenkins::slave::ui_user and jenkins::slave::ui_pass are passed to the jenkins::slave puppet module. You may need to update them depending on your slave's security model. See:
https://github.com/jenkinsci/puppet-jenkins#slaves
https://github.com/jenkinsci/puppet-jenkins/blob/d2ceee61c1971256427dee11dd6472d30bf95228/manifests/slave.pp#L20-L21

First, I'm assuming puppet is a Jenkins module that will be installed via the setup scripts, correct? If so, where do we derive the username and password here? Are we making them up and just ensuring that they are consistent between machines?

Puppet is a tool for managing systems. I'm not puppet expert, but it's something similar to Ansible or Chef. Puppet is in fact the one that reads the yaml configurations and use those settings as input for the tasks that it runs. The tasks are in a different repository (https://github.com/ros-infrastructure/buildfarm_deployment).

For the jenkins::slave::ui_user / ui_pass  you can leave admin. It's the user that gets created in Jenkins. You will use this user to use the Jenkins web ui and, if I understood correctly, it's also used for some jenkins master - slave authentication.

 

This is the password for the slave to access the master
user::admin::password_hash
On the master this should be the hashed password from above
The easiest way to create this is to setup a jenkins instance. Change the password, then copy the string out of config file on the jenkins server.

For this, I just set up and ran a Jenkins server per their setup instructions, went through the configuration via the web front end, and then found the directory and file that contained of the username and hashed password in /var/lib/jenkins/users/<jenkins_admin_username>/config.xml. All of that was pretty straightforward, but it's not yet clear to me how this information is used when we run the setup script(s) on each machine. Is it using the same Jenkins instance I created? I'm assuming not.

The deployment scripts are run in the servers were you are setting up the buildfarm. The puppet scripts will install jenkins, set up the user accounts and take care of all the installation steps.

To generated the password hash I installed jenkins in my local computer (not the jenkins-master server) and got the hash. If you already installed jenkins and created the user in the jenkins-master server, I don't think that you'll have any problem.. Puppet should 'take over' your installation and adapt it to your needs.

 

autoreconfigure::branch
If you are forking into a repo and using a different branch name, update the autoreconfigure command to point to the right branch.

I'm assuming that this means that if our "fork" of the private configuration repo has a branch name that isn't 'master', we need to change it to whatever our branch is.

Yes. I did not test the autoreconfigure though. I've scripted the copy of the configuration and re run of the puppet scripts when I need to test some configuration change.

 

ssh_keys
Configure as many public ssh-keys as you want for administrators to log in. It's recommended at least one for root.
On the repo machine make sure there is at least one key for the jenkins-slave user matching the ssh private key jenkins::private_key provisioned on the master.

For the second bullet point, there is no parameter 'jenkins::private_key' specified in the server's common.yaml; I'm assuming it means 'jenkins::private_ssh_key'. In the default configuration file (server/common.yaml), there also appears to be a public key for the jenkins-slave user. Is that required.

Yes, I have the public key (which corresponds to the jenkins::private_ssh_key) listed, so that the jenkins user in the master can log in as jenkins-slave in the repo and slave box. This uses a jenkins plugin to copy the build artifacts over SSH, you might want to read how it is configured in the Jenkins system configuration to understand which authentications needs to work.

 

Further down in the parameters that are specifically for master, we have:

credentials::jenkins-slave::username
The name of the credentials
credentials::jenkins-slave::id
A UUID for the credentials in the format 1e7d4696-7fd4-4bc6-8c87-ebc7b6ce16e5
credentials::jenkins-slave::passphrase
The hashed passphrase for the key. The UI puts this has in if there's no passphrase 4lRsx/NwfEndwUlcWOOnYg==
If you would like to modify these values from the default it will likely be easiest to boot an instance. Change the credentials via the UI, then grab the values out of the config file.

 

The description for the username isn't clear to me. Is this setting related to the jenkins::slave::ui_user setting? Is the passphrase for the jenkins-slave ssh key further down in the example configuration? Is using the default values acceptable?

I have similar doubts with this one...

 

Also, after a bit more digging, I found this page. The directions say

First you need to either fork the ros_buildfarm_config repository or create a repository containing the same configuration files.
Then you must update the configuration files:

It then lists a number of other configuration settings that aren't in the ros_buildfarm_config files in the repo, such as notifications and status_page_repositories. There are also several references to "entry point yaml." Is that simply referring to each common.yaml file?

The ros_buildfarm is the second step. If I understand correctly, you are still deploying (configuring) the master/slave/repo computers. Once you have that more or less working, you need to adapt the files in the ros_buildfarm_config repo and then use the ros_builfarm tools.

Those tools will actually generate the Jenkins jobs that will do the job. This step is pretty complex also, as the scripts relay pretty heavily in the underlying infrastructure, so some things may not work with your deployment_config. Generating the jobs and then trying to run them I discovered many problems in my deployment config and also some limitations in what can be changed in the deployment configuration.

Best,

Lucas

[Tully Foote]

Hi Tom and Lucas,

Lucas, thanks for the answers. I've filled in a few more details below. 

Tully

Yes that should be jenkins::private_ssh_key. The public key is also required, since the master is actually going to launch a slave instance on itself via ssh. 

 

 

Further down in the parameters that are specifically for master, we have:

credentials::jenkins-slave::username
The name of the credentials
credentials::jenkins-slave::id
A UUID for the credentials in the format 1e7d4696-7fd4-4bc6-8c87-ebc7b6ce16e5
credentials::jenkins-slave::passphrase
The hashed passphrase for the key. The UI puts this has in if there's no passphrase 4lRsx/NwfEndwUlcWOOnYg==
If you would like to modify these values from the default it will likely be easiest to boot an instance. Change the credentials via the UI, then grab the values out of the config file.

 

The description for the username isn't clear to me. Is this setting related to the jenkins::slave::ui_user setting? Is the passphrase for the jenkins-slave ssh key further down in the example configuration? Is using the default values acceptable?

I have similar doubts with this one...

The username needs to match the user to which things like the ssh uploads are going to happen on the repository machine. It's likely you can globally replace jenkins-slave with a different username however we have not tested it at all. And I suspect that it is unlikely to work to try to use a different username on the slave machines vs the repository machine. The connections may expect the same username on both ends. 

 

 

Also, after a bit more digging, I found this page. The directions say

First you need to either fork the ros_buildfarm_config repository or create a repository containing the same configuration files.
Then you must update the configuration files:

It then lists a number of other configuration settings that aren't in the ros_buildfarm_config files in the repo, such as notifications and status_page_repositories. There are also several references to "entry point yaml." Is that simply referring to each common.yaml file?

The ros_buildfarm is the second step. If I understand correctly, you are still deploying (configuring) the master/slave/repo computers. Once you have that more or less working, you need to adapt the files in the ros_buildfarm_config repo and then use the ros_builfarm tools.

Those tools will actually generate the Jenkins jobs that will do the job. This step is pretty complex also, as the scripts relay pretty heavily in the underlying infrastructure, so some things may not work with your deployment_config. Generating the jobs and then trying to run them I discovered many problems in my deployment config and also some limitations in what can be changed in the deployment configuration.

Best,

Lucas

--
You received this message because you are subscribed to the Google Groups "ros-sig-buildfarm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ros-sig-buildf...@googlegroups.com.
To post to this group, send email to ros-sig-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/ros-sig-buildfarm/add40c95-543a-4b39-a423-2d63871a90a5%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Tom Moore]

Hi Lucas, 

Thank you very much for your time and assistance! ! I appreciate it.

-Tom

[Tom Moore]

Hi Tully,

Thank you! I'll update my config files with all of this information and see where it gets me.

-Tom