Servers are the basic resource of bare metal in the Metal Controller Manager. These are created by PXE booting the servers and allowing them to send a registration request to the management plane.
An example server may look like the following:
apiVersion: metal.sidero.dev/v1alpha1 kind: Server metadata: name: 00000000-0000-0000-0000-d05099d333e0 spec: accepted: false configPatches: - op: replace path: /cluster/network/cni value: name: custom urls: - http://192.168.1.199/assets/cilium.yaml cpu: manufacturer: Intel(R) Corporation version: Intel(R) Atom(TM) CPU C3558 @ 2.20GHz system: family: Unknown manufacturer: Unknown productName: Unknown serialNumber: Unknown skuNumber: Unknown version: Unknown
A an installation disk is required by Talos on bare metal.
This can be specified in a
apiVersion: metal.sidero.dev/v1alpha1 kind: Server ... spec: accepted: false configPatches: - op: replace path: /machine/install/disk value: /dev/sda
The install disk patch can also be set on the
apiVersion: metal.sidero.dev/v1alpha1 kind: ServerClass ... spec: configPatches: - op: replace path: /machine/install/disk value: /dev/sda
In order for a server to be eligible for consideration, it must be
This is an important separation point which all
Servers must pass.
Server is accepted, no write action will be performed against it.
Thus, it is safe for a computer to be added to a network on which Sidero is operating.
Sidero will never write to or wipe any disk on a computer which is not marked as
This can be tedious for systems in which all attached computers should be considered to be under the control of Sidero.
Thus, you may also choose to automatically accept any machine into Sidero on its discovery.
Please keep in mind that this means that any newly-connected computer WILL BE WIPED automatically.
You can enable auto-acceptance by passing the
--auto-accept-servers=true flag to
Once accepted, a server will be reset (all disks wiped) and then made available to Sidero.
You should never change an accepted
Server to be not accepted while it is in use.
Because servers which are not accepted will not be modified, if a server which
was accepted is changed to not accepted, the disk will not be wiped upon
Sidero can use IPMI information to control
Server power state, reboot servers and set boot order.
IPMI information will be, by default, setup automatically if possible as part of the acceptance process. In this design, a "sidero" user will be added to the IPMI user list and a randomly generated password will be issued. This information is then squirreled away in a Kubernetes secret in the
sidero-system namespace, with a name format of
<server-uuid>-bmc. Users wishing to turn off this feature can pass the
--auto-bmc-setup=false flag to
IMPI connection information can also be set manually in the
Server spec after initial registration:
apiVersion: metal.sidero.dev/v1alpha1 kind: Server ... spec: bmc: endpoint: 10.0.0.25 user: admin pass: password
If IPMI information is set, server boot order might be set to boot from disk, then network, Sidero will switch servers to PXE boot once that is required.
Without IPMI info, Sidero can still register servers, wipe them and provision clusters, but Sidero won't be able to reboot servers once they are removed from the cluster. If IPMI info is not set, servers should be configured to boot first from network, then from disk.
Sidero can also fetch IPMI credentials via the
apiVersion: metal.sidero.dev/v1alpha1 kind: Server ... spec: bmc: endpoint: 10.0.0.25 userFrom: secretKeyRef: name: ipmi-credentials key: username passFrom: secretKeyRef: name: ipmi-credentials key: password
Server resource is not namespaced,
Secret should be created in the