Having thought about this more I can define 3 separate areas that we can talk about. Each area can also divided into Foreman and Smart Proxy.
Database modeling
Smart Proxy
We want a way to store this relation in the database. In the opening RFC there is a model.
From what I know about deployments is that in most cases there is 1 host which runs the Smart Proxy. There are some cases where they are load balanced. In some cases it doesn’t run on a (managed) host.
The implication is that a host can have 0 or 1 Smart Proxy (through the InfrastructureFacet). From that it also follows that a Smart Proxy has 0 to n Hosts.
To me this sounds correct. In my experience it matches with how those are treated in practice. I am assuming that all these values will just be foreign keys.
Foreman
In practice Foreman typically runs on a single host, but my feeling is that in the community it’s more common to load balance a Foreman instance than a Smart Proxy instance. That means you can have n hosts run a Foreman instance. Of course these hosts don’t have to be self managed so it can also be 0 hosts.
This effectively means that you can have 0 to n hosts which are a Foreman host. Those may or may not have a Smart Proxy as well.
The proposal is to store this in an InfrastructureFacet on the host. However, it doesn’t specify how the host will be marked. Will it be a boolean (marked implies that) or store the Foreman instance UUID.
Management of relations
For both relations you can choose how to manage them. There are several options:
- Manage by hand. Arguably the most correct but also the most tedious.
- Manage via fact imports
- Manage via some other way.
Note that there may be multiple way of managing it.
Automatically managing Smart Proxy to Host relationships
The proposal is to add an instance ID. I think this adds a lot of complexity while there already is something to identify the Smart Proxy (common name on the client certificate).
Another thing that came to my mind is systemd’s machine-id. Perhaps that’s easier to correlate with facts.
Both have their flaws as well so at this point I’m not sure what’s the most reliable way of doing this.
Automatically managing Foreman relationships
Implementation detail: I saw that the instance ID was written as a database setting while writing out the fact statically. This means they can easily go out of sync. It also means that if you don’t use Puppet to continuously run the admin can go into settings, change the instance UUID but then run the installer again and reset it to the old instance UUID.
I think it would be better if it was implemented as a dynamic fact. Reading something from Foreman is usually slow if you need to initialize rails so it may be better to read out a file somewhere.
To prevent the admin from changing the instance ID, it can be written to settings.yaml
. This makes values read-only from the UI/API.
Combining these 2 (implement fact by reading settings.yaml
) might be an issue with file permissions though.
Other notes
Something that I haven’t seen in this discussion is how to clean up entries. If a host report comes in without the fact, does it remove the relationship? What if you run Ansible and it doesn’t report the right facts but also have Puppet running which does?