-
Notifications
You must be signed in to change notification settings - Fork 29
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
Add initial metal3 quickstart #99
Conversation
✅ Deploy Preview for edge-misc ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
The basic steps to install and use Metal<sup>3</sup> are: | ||
|
||
- Install an RKE2 management cluster | ||
- Install Rancher |
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.
Rancher isn't strictly a dependency atm, but if in future we want to enable rancher integration e.g via the turtles UI this will be needed, shall I remove this for now or leave it?
Would you mind if we went ahead and merged while in this state so we can review and edit in smaller chunks? I just did the same with my quickstarts for EIB and Elemental. |
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.
I think we should go ahead and merge this. That way we can more easily divide the work without having to deal with merging across branches
- Must support deployment via virtualmedia (PXE is not currently supported) | ||
- Must have network connectivity to the Management cluster for access to the Metal<sup>3</sup> provisioning APIs | ||
|
||
TODO we need a more detailed support matrix of vendors and BMC firmware versions. |
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.
Is this something that we inherit directly from upstream?
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 and no - we inherit the specific Ironic drivers that are enabled in our configuration, but that's not the same as having a validated support matrix from a product perspective.
credentialsName: controlplane-0-credentials | ||
``` | ||
|
||
Note the following: |
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.
Once we switch to asciidoc, this should be a admonition/callout block
In this mode the endpoint for the management cluster APIs is the IP of the management cluster, thus is should be either reserved when using DHCP | ||
or statically configured. | ||
|
||
TODO example of how to do this with NodePort, if we want to include it in the docs? |
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.
I think NodePort makes sense for single nodes and reduces the complexity for dev/test usage.
Yes that's fine with me, I'm happy to contribute further content as follow-ups but it will definitely be easier if we do it as a series of smaller changes. |
@agracey this is still WIP but wanted to push it up for initial review so we can collaborate