Skip to content
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

Remove authentication requirement for launchpad init #7

Merged
merged 3 commits into from
Nov 4, 2022

Conversation

LucilleH
Copy link
Collaborator

@LucilleH LucilleH commented Nov 3, 2022

Summary

This is the first step towards removing auth requirement for most commands, starting with init.
Screen Shot 2022-11-03 at 11 53 19 AM

Screen Shot 2022-11-03 at 11 47 37 AM

Screen Shot 2022-11-03 at 11 48 08 AM

How was it tested?

cli-build
launchpad logout
launchpad init

Is this change backwards-compatible?

Yes

@ipince
Copy link
Contributor

ipince commented Nov 3, 2022

This seems less "remove auth from init" and more "provide a way for oss-launchpad users to upgrade into commercial launchpad".

I thought the former was already done (I didn't notice we were calling auth.Identify(), but we can just remove it). The latter seems like a new feature, which is nice.

@LucilleH LucilleH marked this pull request as ready for review November 3, 2022 19:22
@LucilleH
Copy link
Collaborator Author

LucilleH commented Nov 3, 2022

This seems less "remove auth from init" and more "provide a way for oss-launchpad users to upgrade into commercial launchpad".

I thought the former was already done

I thought so too. Apparently not 🤷‍♀️

Copy link
Contributor

@ipince ipince left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm I don't know if I like where this is going. Left some comments. Might be worth talking in person


clusterNames := []string{}
for _, c := range clusters {
clusterNames = append(clusterNames, c.GetName())
}
// In case user wants to log in and use a jetpack managed cluster.
clusterNames = append(clusterNames, jetpackManagedCluster)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but, now we may have both jetpack-cloud and Jetpack managed cluster as options, which doesn't make sense.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why don't we remove the Jetpack managed cluster option and then just indicate which clusters are jetpack-managed from the list of clusters we already have?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because if a commercial user is not logged in, we won't have the full set of clusters. By selecting Jetpack managed cluster we will drop them in the login flow, knowing that they are not OSS users.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we won't have the full set of clusters

but we will, because they were (likely) previously merged into their kubeconfig

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we do have a full set, then they can simply select it from the previous question. I'll give you a full demo

return nil, errors.WithStack(err)
}
// Get all the cluster names again.
clusters, err := cmdOpts.ClusterProvider().GetAll(ctx)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm... i think this kind of breaks the oss experience.. which im actually OK with, but want us to be aware of the breakage.

In OSS, GetAll() will only ever return what's in your kubeconfig. so.. let's say you have clusters A and B. Then the prompt will be:

What cluster?
> A
  B
  Jetpack managed cluster

And then if you select Jetpack-managed cluster, we will try to show you jetpack-managed clusters, but there won't be any because we're on OSS.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, in that case we skip the second question of displaying the jetpack-managed clusters, and ask them to run launchpad cluster create

}

// If no jetpack managed cluster exist, we default the answer to the only option available.
if len(clusterNames) == 1 {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what if len(clusterNames) == 0?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Bad code. Updated

@LucilleH LucilleH requested a review from ipince November 3, 2022 20:48
Copy link
Contributor

@ipince ipince left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@LucilleH LucilleH merged commit 5897818 into main Nov 4, 2022
@LucilleH LucilleH deleted the lucille--auth branch November 4, 2022 23:23
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants