-
Notifications
You must be signed in to change notification settings - Fork 288
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
Rufio options #6741
Rufio options #6741
Conversation
Skipping CI for Draft Pull Request. |
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## main #6741 +/- ##
==========================================
+ Coverage 71.78% 71.97% +0.19%
==========================================
Files 531 532 +1
Lines 41295 41590 +295
==========================================
+ Hits 29642 29934 +292
+ Misses 9993 9982 -11
- Partials 1660 1674 +14
☔ View full report in Codecov by Sentry. |
@@ -381,8 +382,20 @@ func (f *Factory) WithExecutableBuilder() *Factory { | |||
return f | |||
} | |||
|
|||
// ProviderOptions contains per provider options. | |||
type ProviderOptions struct { |
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.
this allows us to add more options in the future without continually breaking the WithProvider
function signature.
0c29f39
to
070196a
Compare
@jacobweinstock Is this awaiting the rebase since the other PR merged? |
This allows us to not have to import Rufio. Rufio uses controller-runtime v0.15.0 (and soon v0.16.2). EKS Anywhere use v0.14.2. Upgrading EKS Anywhere means all other dependent libraries will need upgraded too. This is not feasible at the moment from a time perspective, there are too many to update. For example: capv, capc, capd, abhay-krishna/cluster-api, aws/etcdadm-bootstrap-provider, etc. Signed-off-by: Jacob Weinstock <[email protected]>
Signed-off-by: Jacob Weinstock <[email protected]>
CSV and yaml unmarshalling and writing secrets from the hardware.Machine RPC options were updated and added. This sets the stage for allowing the Rufio RPC provider options to be pulled in. These options will all come from env vars. Signed-off-by: Jacob Weinstock <[email protected]>
This plumbs through non empty options from hardware.Machine to v1alpha1.Machine. Signed-off-by: Jacob Weinstock <[email protected]>
The "Machine" in BMCMachineOptions didnt provide any additional value over just BMCOptions. Signed-off-by: Jacob Weinstock <[email protected]>
This enables passing env vars instead of cli flags. Will be used for BMC secrets.
Adds cli flags for all bmc options. The flags are hidden by default but the cli mechanism we use also makes them available as env vars. The dependencies factory is updated with a new func parameter for provider options that will allow future modifications without breaking the fn signature. the cmd/eksctl-anywhere/cmd/flags pkg was renamed to be singular. It was named similar to the pflags library but with "a" for anywhere. The csv reader was modified to take in bmc options so that the options can be added during a Read. Signed-off-by: Jacob Weinstock <[email protected]>
Signed-off-by: Jacob Weinstock <[email protected]>
Signed-off-by: Jacob Weinstock <[email protected]>
Signed-off-by: Jacob Weinstock <[email protected]>
TinkerbellBMCCustomPayload and TinkerbellBMCCustomPayloadDotLocation. Signed-off-by: Jacob Weinstock <[email protected]>
070196a
to
77f0b4e
Compare
Sorry, yes it is. Just rebased. Thanks! |
/retest |
@@ -87,21 +90,147 @@ func toRufioMachine(m Machine) *v1alpha1.Machine { | |||
// TODO(chrisdoherty4) |
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.
Oops 🤦🏻
} | ||
|
||
// NewCSVReader returns a new CSVReader instance that consumes csv data from r. r should return io.EOF when no more | ||
// records are available. | ||
func NewCSVReader(r io.Reader) (CSVReader, error) { | ||
func NewCSVReader(r io.Reader, opts *BMCOptions) (CSVReader, error) { |
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.
Are the BMC options not per hardware? I'm also giving thought to BMC options not being present at all in the hardware input (CSV) but we set this anyway?
@@ -27,6 +28,74 @@ type Machine struct { | |||
BMCUsername string `csv:"bmc_username, omitempty"` | |||
BMCPassword string `csv:"bmc_password, omitempty"` | |||
VLANID string `csv:"vlan_id, omitempty"` | |||
|
|||
// BMCOptions are the options used for Rufio providers. | |||
BMCOptions *BMCOptions `csv:"-"` |
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.
How does a user specify the opts? This looks like (though probably isn't) the options can't be specified in the CSV?
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.
Correct, you cannot set these via the hardware csv. They are all set via env vars only.
I left some inline comments but broadly I'm not clear how this is meant to work. Do we expect all hardware to use the same settings? What happens if we want to plumb through different settings per hardware as supported by Rufio? |
Thanks. |
Understood. I don't think there's anything in the 'interface' to configuring this that would prevent future expansion: does that sound accurate? Specifically, we're not adding anything to the hardware CSV and we're just offering a bunch of CLI/ENV options for configuring a single rpc endpoint - does that sound right? |
flags.MarkRequired(createClusterCmd.Flags(), flags.ClusterConfig.Name) | ||
func tinkerbellFlags(fs *pflag.FlagSet, r *hardware.RPCOpts) { | ||
aflag.String(aflag.TinkerbellBMCConsumerURL, &r.ConsumerURL, fs) | ||
aflag.MarkHidden(fs, aflag.TinkerbellBMCConsumerURL.Name) |
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.
What's the reason for hiding these?
I am OK with the env/cli variables. Curious if we thought about including these in the cluster config somehow? Historically there's been a strong preference for using the cluster config and this seems like something that could feature on the datacenter config?
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.
What's the reason for hiding these? These are what i would consider advanced options and not something I would recommend we clutter a cli help message with.
Curious if we thought about including these in the cluster config somehow? Yeah, i did consider it. The concern i have for adding to the cluster config is that i believe we don't understand enough about how/if/when customers will use this functionality. I would prefer to hide it like i did and learn more before adding it to the cluster config where deprecating feels a lot more difficult.
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.
Great points, agreed.
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.
The inline comment on cluster config vs use of CLI/env vars should probably be circulated some.
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: jacobweinstock 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 |
Signed-off-by: Jacob Weinstock <[email protected]>
New changes are detected. LGTM label has been removed. |
Signed-off-by: Jacob Weinstock <[email protected]>
Signed-off-by: Jacob Weinstock <[email protected]>
Signed-off-by: Jacob Weinstock <[email protected]>
/retest |
/test eks-anywhere-cli-attribution-presubmit |
/test eks-anywhere-cli-attribution-presubmit |
Issue #, if available:
Description of changes:
This incorporates Rufio options per machine. The only options currently supported are for the Rufio/bmclib RPC provider. All options are configurable via env vars and cli flags.
Testing (if applicable):
Documentation added/planned (if applicable):
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.