Ironic Standalone Operator

[dtantsur]

This design proposal discusses ironic-standalone-operator: provides a
motivation for its creation, describes its goals and outlines the
current design and features, as well as the plans for the nearest
future.

Signed-off-by: Dmitry Tantsur [email protected]

[metal3-io-bot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[MahnoorAsghar]

Similarly, how does provisioningInterface, provisioningIPAddress and provisioningMACAddress sound?

[dtantsur]

There is a potential for confusion here. We call "provisioning network" a dedicated network for the PXE and other provisioning traffic. Ironic can work without it, and the variables work regardless of whether you have a "provisioning network".

Maybe I'm overthinking it? Would like more opinions here as well.

[dtantsur]

If we do decide to change this, I'd rather rename the whole "networking" sub-field into something like "provisioningNetwork" to avoid duplicate prefixes.

[MahnoorAsghar]

But the rest of the sub-fields seem unrelated to the provisioning network (like dhcp and external ip)?
How would the interface, ipAddress and macAddresses fields work if there is no provisioning interface?
(I am not too familiar with ironic's networking, so just trying to understand the expected behaviour)

[dtantsur]

DHCP is very-very much related to the provisioning network: it's DHCP on the provisioning network. ExternalIP is not directly related indeed, maybe we'd need to move it out then.

How would the interface, ipAddress and macAddresses fields work if there is no provisioning interface?

There must be a provisioning interface, but it can be on some existing network rather than an isolated provisioning network. Confusing, I know. This is why I'm pondering our usage of "provisioning" here.

[Rozzii]

I would also say to not use "provisioning", on Bare Metal Life Cycle management level the name "Provisioning Network" makes sense but if we just talk about an ironic instance not that much. Everything Ironic does with the machine goes through the provisioning network, ofc he BMC might have it's own separate network but ipxe, dhcp, bootp, http image server, IPA - Ironic communication they all happen in the "provisioning" network but from Ironic perspective it is simply "the Network".

[MahnoorAsghar]

Sounds good!

[hardys]

There is an additional complexity to consider if we're going to support mariadb combined with persistent volumes, when the mariadb version changes you either have to ensure clean shutdown of the container or enable some kind of backup/restore workflow due to the mariadb checks around versioning for the redo log - see here for example.

This can likely be resolved with with pod lifecycle hooks, or perhaps some kind of job pre/post upgrade but it's additional complexity which I don't think we currently consider in the community deployment examples.

[dtantsur]

Very good point, thank you!

[Rozzii]

/approve

[Rozzii]

/lgtm
From my perspective it is fine given that you will address the comments.

[Rozzii]

/hold
Just holding to avoid someone putting approve on it while my lgtm is active and merging it

[kashifest]

Thanks a lot @dtantsur few questions/nits inline

[kashifest]

Just for my understanding what prevents us from enabling TLS unconditionally for ironic itself?

[dtantsur]

Well, nothing really. We'd need to decide if we want to use a CertificateSigningRequest (and require a manual approval) or just generate a self-signed certificate. Opinions?

[Rozzii]

I guess the end goal would be to have an integration with cert-manager as in most K8s environments cert-manager is handling the certificates.

[dtantsur]

My only worry about the manual step (approving the cert request). Is it also considered standard?

I mean, in the situation when the admin has not provided any certificate via the secret.

[kashifest]

I can approve it already and hold can be taken back when the reviews are addressed
/approve

[metal3-io-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kashifest, Rozzii

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [kashifest]
• design/OWNERS [Rozzii,kashifest]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[Rozzii]

/lgtm
@dtantsur feel free to remove the hold if you feel the time is right.

[Rozzii]

/lgtm

[MahnoorAsghar]

LGTM

[dtantsur]

@kashifest do you feel like your comments have been (at least mostly) addressed? The TLS one is probably the only outstanding (and we can discuss it later if you wish).

[kashifest]

@kashifest do you feel like your comments have been (at least mostly) addressed? The TLS one is probably the only outstanding (and we can discuss it later if you wish).

I am fine with this as is. We can continue the TLS discussion as you suggested.
/hold cancel