hosts/remote: add install_server_is_configured

Extend the install-server configuration functionality to have a boolean check
of whether the backend has an install-server configured at all. This is mostly
to make future changes smaller.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
database: add profile column to afe_host_queue_entries_table

Store the profile as a string in the database.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
frontend: add XMLRPC lookup of profile information from install server to get_hosts

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
frontend: add profiles parameter to job creation interface

When we get a new job from afe, we might also get a list of profiles to
go with the hosts, and need to pass this down into the HostQueueEntry
logic eventually.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
hosts: add installable_host class

Each host in a job may have a profile associated with it. This does not
seem to be really a component of what a SSHHost is, so create a new
sub-class, InstallableHost, of SSHHost which just adds a profile to the
parent object.

If the global_config specifies an install server URL, then we use
InstallableHosts rather than SSHHosts.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
autoserv: append profile selection to hostname parameter

I spent much time going back and forth trying to find the smallest
impact way to present installer server profiles to autoserv for control
file usage. Eventually, I decided that appending it to the hostname
makes sense, as it's a parameter of the host selection -- i.e., I want
UserW on HostX installed with ProfileY.

'#' is not a valid character in hostnames, afaik, so I think it should
be safe to use as a separator. Update the parse_machine to know about
this separator. Now, create_host() automatically puts in a profile
object, if the host is of type InstallableHost.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
frontend/afe: add current profile to host view

Now that we have a backend link between hosts and profiles, it makes
some sense to list the current value of the property in the View Host
tab.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
frontend/afe: add profile used to job view

Each HostQueueEntry in the database has a profile stored with it. Show
this in the Job View tab to indicate what profile was used in that job.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
frontend/afe: add listbox widget support

To facilitate profile selection in the Create Job view, we need to add a
new widget type. Currently, all widgets are assumed to be checkboxes.
Extend the createWidget API to take a type.

0 means checkbox
1 means listbox (technically as written any non-zero value means this)

This should probably be turned into a well-defined enum eventually.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
frontend/afe: add profile to host tables

In general, whenever we have a table of hosts, we should be able to show
some profile information. There are 3 cases that I think are worth
supporting:

1) No checkbox, No profile information (HostTable.java)
        Used on the Available Host sub-tab of Create Job
2) No checkbox, profile listbox (ProfileSelectTable.java)
        Used on the Selected Host sub-tab of Create job
3) Checkbox, current profile statically listed (SelectableProfileStaticTable.java)
        Used on the View Host tab
4) Checkbox, no profile information (SelectableHostTable.java)
        Kept for backwards compatibility/support

Add the corresponding classes as sub-classes of HostTable.

Populate the data appropriately in SelectionManager and show the data to
the end user.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
frontend/afe: add support for do_not_install profile

Insert a dummy profile name in the Python code so that the end user can
indicate no installation should occur before the job runs.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Fix unittests for server/base_utils.py

Signed-off-by: Lucas Meneghel Rodrigues <lmr@redhat.com>
autotest/cobbler: handle systems defined in autotest but not cobbler

If a system is defined or partially defined in autotest but not in
cobbler, we currently get errors in the UI. If a system has no platform
defined, the UI fails on the 'profiles' assignment. If a system does not
exist in cobbler, it fails on the 'current_profile' assignment. Handle
both cases by extending the condition upon which we use install_server
information.

Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>