Configuration design: Definition of a Station's remote execution/management methods (Host)

[malex984]

Note: this is a separation of super-issue #13

Station: 4.1 I don't understand the practical purpose of making a distinction between "stations" and "hosts". It would seem simpler to merge both since as specified the relation is 1:1 anyway.

Station: 4.3 I assume the "type" key in host is used to classify the host (e.g. Unix, Windows, etc.) but that means there's an extra (hidden) layer that modifies the behavior of the system depending on the type of host. That adds complexity. Are we using that for anything? It would be better if the specific differences were specified in the configuration... for instance, if Windows systems use something other than ssh, then we can use a config key that specifies the remote execution mechanism.

[porst17]

Move all the things that are common to all power-on and access methods into the station.

I think, the type key is already obsolete and encoded in the definition of power-on method, access method, service definition and application definitions.

[malex984]

Alex said:

4.1 I don't understand the practical purpose of making a distinction
between "stations" and "hosts". It would seem simpler to merge both since
as specified the relation is 1:1 anyway.

Stations are top-level logical entities mostly for Dashboard (but they will of
course be used to generate low-level station configurations and for OMD configuration).

Hosts specify the low-level way to communicate and manage with
corresponding host for hilbert-cli-server.
Unfortunately we do not know all possible types of hosts and the means to
communicate and manage them yet. Some known types are visible in the
updated proposal revision.

They both are combined together since currently there is no reuse for
Host objects.

But it is possible to share them between Presets that can be easily
implemented as individual mappings similarly to the current Stations:.
See:
https://gist.github.com/malex984/59d2b62c5098eb1005100f9249719505#file-preset_testgui-yml

4.3 I assume the "type" key in host is used to classify the host
(e.g. Unix, Windows, etc.) but that means there's an extra (hidden) layer
that modifies the behavior of the system depending on the type of host.
That adds complexity. Are we using that for anything? It would be better if
the specific differences were specified in the configuration... for
instance, if Windows systems use something other than ssh, then we can use
a config key that specifies the remote execution mechanism.

Corrected in https://gist.github.com/malex984/59d2b62c5098eb1005100f9249719505#file-all_flat_update-yml

See also @4.1. Is it any better now?

[malex984]

Eric said:

Stations are top-level logical entities mostly for Dashboard (but they will of course be used to generate low-level station configurations and for OMD configuration).
Hosts specify the low-level way to communicate and manage with corresponding host for hilbert-cli-server.

I understand the conceptual difference, not the practical purpose. If the relation is necessarily 1:1 (a station doesn't have more than one host, or vice-versa) then separating it makes configuration more complex for no purpose other than expressing a conceptual difference the user might not care about.

Unfortunately we do not know all possible types of hosts and the means to communicate and manage them yet. Some known types are visible in the updated proposal revision.

You wrote

 - &GEN GEN: "Generic Host (no remote access). Supporting WOL"
 - &WIN WIN: "Windows Host (with SSH access). Supporting WOL"
 - &UX  UX:  "Unix/Linux (with SSH access). Supporting WOL"
 - &DM  DM:  "Virtualized Station via docker-machine. No WOL!"

then specifying "host type" is just adding an extra layer of opacity, when you could just have an explicit key "wol: yes | no", protocol: ssh | rexec. It only makes sense to "add an extra table" (host type) when there's a need to enforce correlation between several properties... but perhaps there might be a windows system with no WOL support, a non-win / non-unix with ssh, etc. and you'll end up adding ad-hoc types only for specifying every combination.

They both are combined together since currently there is no reuse for
Host objects.

But it is possible to share them between Presets that can be easily implemented as individual mappings similarly to the current Stations:.
See: https://gist.github.com/malex984/59d2b62c5098eb1005100f9249719505#file-preset_testgui-yml

If this is a way for a logical station to change to a different physical host I don't understand why we'd want this functionality or extra complexity.

[malex984]

1. Common shared part is address, which specifies a static (constant) network host address
2. We only support a single access method for now: SSH
3. detailed ssh settings may be optionally specified by ssh_options. Otherwise Server's Access DB is to be used. Ssh alias should be equal to address. See (Configuration design: Separate Access Management? #25) for details.
4. applied OMD host rules are to be specified by omd_tag. For example: no agent, agent on windows, agent on linux system without Hilbert-CLI-Station checks, agent on linux system with Hilbert-CLI-Station checks. It will be defined later on.
5. We only support WOL power-on method which requires station's MAC address (and maybe also address)