-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
User guide: first take at documenting IrSO #493
User guide: first take at documenting IrSO #493
Conversation
f9ea033
to
436f879
Compare
- Which physical network interface will be used for provisioning? Without any | ||
configuration, Ironic will use the host cluster networking. | ||
|
||
- If you use a dedicated network interface, are you going to use the built-in |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A little bit confused about this: if we have multiple control plane nodes, should we make sure one interface on each control plane node has an IP address (which means one ironic per control plane node using that IP address)? Shouldn't that IP address be the same, or shouldn't we have a proxy?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The role of keepalived is to maintain the same IP address, regardless of which node is hosting Ironic. I'll try to clarify a bit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So the bottom line is: Make sure you have a usable IP address on the control plane node hosting ironic. It's possible to use keepalived for this.
Its clearer now, thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Very nice!
git clone https://github.com/metal3-io/ironic-standalone-operator | ||
cd ironic-standalone-operator | ||
git checkout -b <DESIRED BRANCH OR main> | ||
|
||
make install deploy |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In the future we should start publishing the output of kustomize build
as a release artifact so users can just do a kubectl apply -f [URL]
. This is fine for now though, no need to change!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I totally agree. Do we already do it for CAPM3?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it is part of how CAPI expects things to work. So it is published as infrastructure-components.yaml
on every release. That allows clusterctl init --infrastructure=metal3
to automatically find the latest and install it 🙂
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! So, we'll eventually need infrastructure-components.yaml
to include IrSO as well (once we switch to it by default)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Besides what is already mentioned by others, I don't see any major issues here. It is a solid first stab at documentation, thank you!
Signed-off-by: Dmitry Tantsur <[email protected]>
436f879
to
fb72493
Compare
Hopefully addresses all the comments. Also added information about versions. |
LGTM! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: lentzi90 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:
Approvers can indicate their approval by writing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
Signed-off-by: Dmitry Tantsur [email protected]