Start the "login" sequence from "okteto namespace" if needed #919
Conversation
Codecov Report
@@ Coverage Diff @@
## master #919 +/- ##
==========================================
+ Coverage 33.47% 33.54% +0.07%
==========================================
Files 67 67
Lines 5398 5386 -12
==========================================
Hits 1807 1807
+ Misses 3441 3429 -12
Partials 150 150
Continue to review full report at Codecov.
|
* Accept single string as command in the okteto manifest Signed-off-by: Pablo Chico de Guzman <pchico83@gmail.com> * Remove unneeded check from marshalling Signed-off-by: Pablo Chico de Guzman <pchico83@gmail.com>
| analytics.TrackNamespace(err == nil) | ||
| return err | ||
| }, | ||
| } | ||
| cmd.Flags().StringVarP(&oktetoURL, "url", "u", "", "Okteto URL (optional)") |
There was a problem hiding this comment.
I find that adding this paramater to namespace makes the command more complicated to use.
anyone that doesn't understand the internal implementation is going to be confused by why this parameter is here.
I've been looking around at other tools, and it seems like the pattern of login being separate from the actions is pretty common. I think it's easier to understand when commands only do one thing.
If you feel strongly about having login here, I'd not have the param and then ask the user for the URL (defaulting to okteto cloud).
There was a problem hiding this comment.
I see this just as a mere shortcut and it mainly helps reduce the steps to bring users to development from the UI. Currently, the jump from deploy to development takes around 5 - 6 steps when onboarding a new user, back and forth from the UI to the CLI. In the end, the screen to guide users to developments looks like this:
On a big screen, you even have to scroll to see the okteto up which is the main command in this sequence... And I really believe we need to do something to reduce this friction.
Users starting the process from the UI can benefit from copy/pasting the command with all the needed information to start the process. Just like I do when I'm going to clone a Github repo and don't care about the URL, or when configuring a GKE cluster using the gcloud CLI... to name a couple of examples.
I think a good start is to launch the login process whenever it is needed to remove an extra step. In Okteto Cloud this parameter is not even necessary. It will only be needed if you copy/paste the command from the UI in a Okteto Enterprise installation...
So, I do feel strongly about having login here for this reason. I am however open check the idea of prompting the user asking for the URL, like you suggest. But think that this is just optional for the flow initiated from the UI and in Okteto Enterprise.
There was a problem hiding this comment.
I'm also open for ideas to simplify the path to development if you have any.
As you know, I'd even go for a more aggressive simplification: a single command that helps the user all the way from the CLI. Which will mean to automatically log in, switch namespaces, and clone (if needed) before doing the up. But I know you guys are not very fond of this idea...
There was a problem hiding this comment.
@pchico83 @rlamana I don't think that bundling commands is a way to simplify the use of okteto. I think this PR makes the namespace command more complex than before. Bundling commands adds complexity to the surface area of the command too. Now the developer needs to understand that okteto namespace can also login if she's not logged in, so she might want to pass the URL in case she's not.
Pretty much every developer tool I can think of went in the direction of having single use commands, and failing: docker, heroku, terraform, pulumi, snyk. There's no way to pass your credentials during a docker pull, for example. It just fails. These companies and tools have spent a lot of effort and research on this topic, so there's a reason why they went on this direction.
There was a problem hiding this comment.
If you want to keep the behavior of prompting for login, that's fine, but I would not expose it via a parameter.
There was a problem hiding this comment.
@rberrelleza how would you expose it?
There was a problem hiding this comment.
Use runs okteto namespace $NAME like today. If the user is not logged in to okteto cloud, it gets a prompt, where we ask if the user wants to login, ask for the URL (defaulting to cloud), and we do the login action and then if successful, the namespace activation.
We can do the same in create/delete namespace. And we should probably mention in all those commands that the action requires an okteto cloud / okteto enterprise account.
There was a problem hiding this comment.
@rberrelleza LGTM. @rlamana ?
Signed-off-by: Pablo Chico de Guzman pchico83@gmail.com
Eliminates one step from getting started guides