Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

RFC: cobbler: support installation of hosts via koan #471

Open
clebergnu opened this Issue · 2 comments

3 participants

@clebergnu
Owner

This is a request for comments!

I believe that some users may have machines that can not boot from the network, may not have reliable remote power control but still would like to use the provisioning support that autotest offers via cobbler.

Currently:

  • Remote power control is used to reboot the machine to be provisioned.
  • Network boot is used to offer a configuration that will make the system actually boot either from local disk or from a kernel and initrd (to be fetched via tftp) that will trigger the actual installation.

What could be done:

  • Remote power control cannot be completely replaced by software, but, if the machine is reachable over SSH, autotest can try to reboot it gracefully.
  • The switch from the regular boot entry, that is, your day to day [kernel, initrd and arguments] to an [kernel, initrd and arguments] suitable for installation can be done via koan.

Does that sound useful at all?

Resources:

@clebergnu clebergnu was assigned
@lmr
Owner

It does, though I would like to understand the arch better...

@ddefolo

@clebergnu and @lmr,

I was about to send out an RFC in this area that touches potentially closely on this one; however, I'm not sure if you are talking about the same thing.

Item 1: a Koan based test to install VMs

I have a test type that more less takes a dictionary of VMs and profiles in the control file like the example below (with some optional fanciness to support deriving the VM name from a macro (which only makes sense if teams have used a VM naming convention that includes the vm hostname):

'''python
## ACTION NEEDED: Fill in the info on the VMs you wish to install below.
# note: The @@VMHOST@@ macro (if used) will automatically be replaced
# with the name of the VM host this job is running on. Use this
# if the vm host was selected using a label (and you can't pre-
# determine the name of the host
vms_to_install = {
'@@VMHOST@@-vm1.cce.hp.com': {'profile': 'rh7.0_alpha2_srv_x86_64-kvmhost'},
'@@VMHOST@@-vm2.cce.hp.com': {'profile': 'fed17_x86_64'},
'@@VMHOST@@-vm3.cce.hp.com': {'profile': 'rh6.3_ga_20120613.2_srv_x86_64'},
'@@VMHOST@@-vm4.cce.hp.com': {'profile': 'fed16_x86_64'}
}
'''

For me the macro feature is nice because it allows me to use a label to schedule my job to pick any VM host and then install the above specified cobbler profiles on vms 1-4 on that host.

The way the test works is it schedules a job to run on a VM host and then goes through a workflow of:
1) use cobbler xml_rpc to change the system settings for the vms_to_install to refer to the requested profile
2) use virsh commands are used to wipe past references to the requested vms_to_install
3) call koan with syntax similar to what @clebergnu refers to in the above Reinstallation.html link
4) do some basic verification that the install was ok (e.g. is the VM accessible via ssh)

Item 2: Teach autotest how to change cobbler profile for a system w/o doing re-install

This is necessary for item 1) in the test I noted above so that autotest can change the profile for each VM but not actually do anything to reboot the VM. Currently server/hosts/remote.py has a routine called machine_install() which first changes the profile and then triggers a reinstall. My proposal is to just split out the profile modification into its own method so that control files and/or tests can have entries like this in them:

'''python
# switch the profile on cobbler server
vmobj = hosts.create_host(vm, initialize=False)
vmobj.modify_profile(profile='some cobbler profile')
'''

Item 3: Create a test or host method similar to my item 1 that uses koan to install a host (not a VM)

I think this what this RFC was initially talking about; however, I think the point of setting the appropriate profile in cobbler prior to making the koan call might not be needed as this style of call allows koan to select the profile to install:

koan --server=cobbler.example.org --replace-self --profile=name

The alternative is that autotest changes the profile (as per item 2 above) and then invoke koan via:

koan --server=cobbler.example.org --replace-self --system=name

Beyond that, I would need a couple other things clarified for this item:

  • Would having koan installed on the host be something that is a prerequisite of this test/method or would installing it be something this test/method would install?

If the latter, how would you recommend we install koan? To date I've always just installed koan via RPM; however depending on the version of python on the host you need to install different versions of koan. If we were to follow a similar model I could see adding multiple koan tarballs or sources to the autotest tree for it to install (after probing for the python version).

My preference would be to just list it as a prerequisite so we don't need to worry about it.

If sounds like what you were thinking of let me know and I can start working on finalizing things to meet the intent of this RFC. If this sounds like something completely different let me know and I can start a separate RFC on my ideas.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.