-
Notifications
You must be signed in to change notification settings - Fork 66
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
Move join to its own pkg #1726
Move join to its own pkg #1726
Conversation
🤖 Created branch: z_pr1726/Jaanki/move_join |
This is still in WIP and not ready for review at all.A lot of work is still pending. |
#1724 is adding more code to join so we'll need to take that into account here. |
🎉 Great news! Looks like all the dependencies have been resolved: 💡 To add or remove a dependency please update this issue/PR description. Brought to you by Dependent Issues (:robot: ). Happy coding! |
@@ -69,6 +71,10 @@ var joinCmd = &cobra.Command{ | |||
clientProducer, err := client.NewProducerFromRestConfig(clientConfig) | |||
exit.OnError(status.Error(err, "Error creating the client producer")) | |||
|
|||
networkDetails := getNetworkDetails(clientProducer, status) |
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 find 2 issues with this:
- I strongly believe that
cmd/subctl
should just strictly becobra
stuff and nothing else. - we are expecting
pkg/join
to know*CIRD
before hand. Sojoin
is not smart enough to figure out these details. Any third part code usingjoin
would also have to pre-determine these values and can't reply onjoin
.
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.
Where should survey
-based code reside? The library itself can’t rely on that, since it can’t expect to have any way to interact with an end-user.
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 find 2 issues with this:
- I strongly believe that
cmd/subctl
should just strictly becobra
stuff and nothing else.
By cobra
stuff I assume you mean processing arguments and prompting the user. That's what this code is doing. We call network.Discover
here in order to determine if we should prompt the user for any CIDRs if one is not provided.
- we are expecting
pkg/join
to know*CIRD
before hand. Sojoin
is not smart enough to figure out these details. Any third part code usingjoin
would also have to pre-determine these values and can't reply onjoin
.
They can by simply calling network.Discover
. But they don't need to do this. If the CIDRs aren't provided then the operator controller will determine them via network.Discover
.
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.
survey-
code should reside here. It should ask for CIDR here. join
should network.Discover
, get the CIDR and warn users if it is not same as user-specified adn update the ServiceCIDRAutoDetected
accordingly. But I see you removed that field completely. So I guess, it won't make sense to just warn the users if the provided and detected values won't match.
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.
survey-
code should reside here. It should ask for CIDR here.join
shouldnetwork.Discover
, get the CIDR and warn users if it is not same as user-specified
That's what we're doing here. It would be wasteful and unnecessary to perform network.Discover
twice during subctl join
. We don't currently have any other users of this API so I think it's reasonable at this point to assume the caller has done their due diligence wrt the CIDRs, if they provide them. We can always revisit based on feedback if we ever do have another user. Also the operator does this same check and logs a warning anyway.
adn update the
ServiceCIDRAutoDetected
accordingly. But I see you removed that field completely. So I guess, it won't make sense to just warn the users if the provided and detected values won't match.
ServiceCIDRAutoDetected
was used to pass an empty CIDR to the operator if it was auto-detected and was really unnecessary.
pkg/join/join.go
Outdated
"k8s.io/client-go/kubernetes" | ||
) | ||
|
||
func SubmarinerCluster(brokerInfo *broker.Info, options *Options, clientProducer client.Producer, |
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.
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 am leaning towards 1. It joins a cluster (to a broker or to a clusterSet) or lets go overboard with a 4th option join.ClusterToBroker
.
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.
It depends on one's perspective and preference. join.ClusterToBroker
would be the most complete. @skitt do you guys have any strong preference?
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.
Remembering Java, I like 1, because it names the result we’re after; the caller shouldn’t care that joining a cluster means joining a broker. However since Go doesn’t have polymorphism, and we’re explicitly passing in a broker.Info
, ClusterToBroker
makes sense to me — if we end up having other variants which don’t use a broker, we’ll say ClusterToSomethingElse
.
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 makes sense. We'll go with ClusterToBroker
. I think with just Cluster
, it could be interpreted as "joining to a cluster" instead of "joining a cluster to something".
... and decouple cobra stuff Signed-off-By: Janki Chhatbar <[email protected]>
Signed-off-by: Tom Pantelis <[email protected]>
...instead of in join.SubmarinerCluster since it's obtained from user input. This also preserves the current behavior where we prompt the user for the cluster ID if the CLI argument is invalid. Subsequently we can then pass in a client.Producer rather than a restconfig.Producer to join.SubmarinerCluster improving reusability. Signed-off-by: Tom Pantelis <[email protected]>
...where it always checks and reports failed requirements but only fails the join if the ignoreRequirements flag is false. Also log the failures to the status reporter instead of fmt.Printf. Signed-off-by: Tom Pantelis <[email protected]>
The new implementation changed the behavior to first ask the user if they want to discover/autodetect the CIDR if it wasn't provided. If the user chooses no then it prompts for the CIDR. Otherwise if it's not autodetected, it fails. Changed it to preserve the existing behavior in the cmd front-end where if the CIDR is provided by the user, use it. Otherwise, if the CIDR wasn't autodetected, prompt the user for the CIDR. The library function, join.SubmarinerCluster, simply passes the CIDRs as is to the Submariner CR and assumes the caller has determined them appropriately or left one or more empty to let the operator controller discover it. Signed-off-by: Tom Pantelis <[email protected]>
...as advertised instead of whether or not there are any gateways. Signed-off-by: Tom Pantelis <[email protected]>
The join cmd front-end already handles most of the work by retrieving the worker nodes, prompting the user etc so it may as well do the last part (nodes.LabelAsGateway) instead of passing params to join.SubmarinerCluster to do it. A third-party client could also easily handle the labeling via the functions provided by the nodes pkg. Signed-off-by: Tom Pantelis <[email protected]>
...with deploy.Submariner as only a subset of WithJoinOptions fields apply. Signed-off-by: Tom Pantelis <[email protected]>
...with deploy.ServiceDiscovery as only a subset of WithJoinOptions fields apply. Signed-off-by: Tom Pantelis <[email protected]>
Signed-off-by: Tom Pantelis <[email protected]>
Signed-off-by: Tom Pantelis <[email protected]>
🤖 Closed branches: [z_pr1726/Jaanki/move_join] |
... and decouple cobra stuff
Signed-off-By: Janki Chhatbar [email protected]
Depends on #1724