Plugins » Discovery

Currently, Discovery plugin leverages Edit Host form to do provisioning. This brings various problems and the code is difficult to maintain. This ticket aims to refactor discovery to use new form for manual discovered host provisioning.

Current problems:

1. Monkey-patching is be used in order to use the form from core.
2. The code depends on Edit Host core form, changes there usually breaks Discovery.
3. Unable to edit/change Organization/Location fields when Katello plugin is installed.
4. The form exits incorrectly on Cancel.
5. Most users only assign Hostgroup and optionally edit Network configuration.

Possible solutions:

A) DISCOVERY PROFILE

We can introduce Discovery Profile model that defines the following items:

• associated hostgroup
• hostname pattern
• organization and location
• network configuration
• [x] edit host before provisioning

The network configuration needs to be flexible so Profile can be used directly (attended provisioning) or via Rule (unattended provisioning). Instead of rewriting networking part of the New/Edit Host, we should come up with something else which is more flexible: #13847.

We shoud also provide a mechanism not to initiate provisioning immediately using a flag, this will be used in interactive (attended) provisioning when user want to do some per-host fine tuning (e.g. editing network configuration for a single host). Since we simple open an existing Edit Form URL from Discovery, no defacing will be required for this.

Hostgroup and hostname pattern will move from Discovery Rules to Profile and they will be linked together, so Profiles are used in both unattended and attended provisioning.

Advantages: Using the same model for both attended and unattended provisioning. Possibility to use scripted network configuration for both as well.

Disadvantages: Two forms are required in order to do interactive provisioning with networking configuration change.

B) EXTEND NEW HOST FORM

Instead using Edit Host, we can simply use New Host form if we extend it in core to accept "default parameters". Discovery needs at least:

• hostname
• network configuration

Alternatively, we can send just list of facts instead particular form items, so in that case the New Form controller action can do import_host_from_facts to build network configuration for the form.

This solution must be implemented together with getting rid of STI (#13848) since discovered hosts must not exist as a host record (otherwise there will be a conflict). New model DiscoveredHost will be created to hold facts and associated subnet (as a fact perhaps). The model can be very simple and we will not be creating new Foreman Host at the discovery time, we will just keep the facts.

We will use Facelets to extend Foreman Host with discovery subnet and also DiscoveredHost which will hold facts even after host was provisioned. It will be very useful to be able to access discovered facts after host was provisioned (currently we have a hack to keep all facts starting with discovery* - all the others are deleted). And of course we need a reference to DiscoveryRule as well via Facelet.

Workflow:

• host is discovered
• subnet is detected
• organization/location is assigned (? maybe we won't need that at this stage)
• DiscoveredHost record is created
• user clicks on Provision
• New Host form is rendered
• once submitted, discovery orchestration hooks reboots/kexec