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

feat(cmd): add db's user list #1019

Merged
merged 5 commits into from
Nov 17, 2023
Merged

Conversation

curzolapierre
Copy link
Member

@curzolapierre curzolapierre commented Nov 13, 2023

List

$ scalingo database-list-users --help
NAME:
   scalingo database-list-users - Print database's users

USAGE:
   scalingo database-list-users command [command options] [arguments...]

DESCRIPTION:
   List the users of a database

   Only available on [postgresql elasticsearch influxdb]

   Example
     $ scalingo --app myapp --addon addon-uuid database-list-users

OPTIONS:
   --app value, -a value  Name of the current app (default: "<name>")
   --addon value          ID of the current addon (default: "<addon_id>")
   --region value         Name of the region to use
   --help, -h             show help

Delete

$ scalingo database-delete-user --help
NAME:
   scalingo database-delete-user - Delete a database's user

USAGE:
   scalingo database-delete-user command [command options] user

DESCRIPTION:
   Delete the given user of a database

   Only available on [postgresql elasticsearch influxdb]

   Example
     $ scalingo --app myapp --addon addon-uuid database-delete-user my_user

OPTIONS:
   --app value, -a value  Name of the current app (default: "<name>")
   --addon value          ID of the current addon (default: "<addon_id>")
   --region value         Name of the region to use
   --help, -h             show help

Create

$ scalingo database-create-user --help
NAME:
   scalingo database-create-user - Create new database user

USAGE:
   scalingo database-create-user command [command options] user

DESCRIPTION:
   Create new database user

   Only available on [postgresql elasticsearch influxdb]

   Examples
     $ scalingo --app myapp --addon addon-uuid database-create-user my_user
     $ scalingo --app myapp --addon addon-uuid database-create-user my_user --read-only

OPTIONS:
   --app value, -a value  Name of the current app (default: "<name>")
   --addon value          ID of the current addon (default: "<addon_id>")
   --read-only            Create a user with read-only rights (default: false)
   --region value         Name of the region to use
   --help, -h             show help

Fixes #1018

@curzolapierre curzolapierre self-assigned this Nov 13, 2023
@curzolapierre curzolapierre marked this pull request as ready for review November 14, 2023 11:20
Copy link
Contributor

@yohann-bacha yohann-bacha left a comment

Choose a reason for hiding this comment

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

nice job! some small issues, but nothing too serious

}.Render(),

Action: func(c *cli.Context) error {
if c.Args().Len() != 1 {
Copy link
Contributor

Choose a reason for hiding this comment

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

issue: in this case, an error should be returned. the exit code 0 means the operation was done successfully, which is not the case here

Copy link
Member Author

@curzolapierre curzolapierre Nov 16, 2023

Choose a reason for hiding this comment

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

Well the logic we implement in our CLI is more an error meaning CLI itself has failed to do something.
Here we succeed to print the help command because the number of argument is not expected.
It may be debatable, but for the sake of consistency with the rest of CLI, I'll leave it like that.

Copy link
Contributor

Choose a reason for hiding this comment

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

wtf you're in fact right, but that is weird.. i really thought that there were a client that pointed this behaviour, and that we should handle it differently. this should return an exit code 1, but you are right : consistency is more important

cmd/databases.go Outdated Show resolved Hide resolved
db/users/utils.go Outdated Show resolved Hide resolved
db/users/create.go Outdated Show resolved Hide resolved
db/users/create.go Outdated Show resolved Hide resolved
scErrors "github.com/Scalingo/go-utils/errors/v2"
)

var ErrDatabaseNotSupportUserManagement = errors.New("Error: DBMS does not support user management")
Copy link
Contributor

Choose a reason for hiding this comment

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

issue: not a fan of making a constant of an error, as we never do this anywhere in our code. we often have a same base error such as "user cannot be fetched", but we do not factorize them

Copy link
Member Author

Choose a reason for hiding this comment

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

as we never do this anywhere in our code

Not true, just in this repo I can see some, in addition, we usually do it for two main reason:

  • use the constant (preferably a typed) to compare an error
  • avoid duplication

In this case it's the latter we're interested in

Copy link
Contributor

Choose a reason for hiding this comment

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

just in this repo I can see some

not really sure about that one as I never saw one in my peregrinations in all our go code. in fact, i like the idea that we centralize our errors, and then identify them more easily. though, i see this more as a consistency issue. if we do this here, we should do it every where errors are duplicated.

this is, though, not blocking

return false, scErrors.Wrap(ctx, err, "get the addon to check user management support")
}

for _, supportedAddon := range supportedAddons {
Copy link
Contributor

Choose a reason for hiding this comment

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

praise: i like the simple use of plurals and singular in a foreach

return nil
}

isPasswordGenerated := false
Copy link
Contributor

Choose a reason for hiding this comment

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

issue (blocking?): the password generation logic is made backend sided. do we want to handle it on the client side?

Copy link
Member Author

Choose a reason for hiding this comment

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

I agree, the reason of this check here was to return error has early has possible. This means if the username is incorrect there is no need to continue the process (i.e. password, confirmation)
But WDYT?

Copy link
Contributor

Choose a reason for hiding this comment

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

well that could have remove some complexity client sided, but this isn't really an issue and is not blocking, do as your heart wishes

func askForPassword(ctx context.Context) (string, string, error) {
fmt.Printf("Password: (Will be generated if left empty) ")

bytePassword, err := term.ReadPassword(int(os.Stdin.Fd()))
Copy link
Contributor

Choose a reason for hiding this comment

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

issue: no need to specify the type of the variable via its name

Suggested change
bytePassword, err := term.ReadPassword(int(os.Stdin.Fd()))
password, err := term.ReadPassword(int(os.Stdin.Fd()))

}

fmt.Printf("\nPassword Confirmation: ")
byteConfirmedPassword, err := term.ReadPassword(int(os.Stdin.Fd()))
Copy link
Contributor

Choose a reason for hiding this comment

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

issue: same, no need for specifying the type in the variable name

Copy link
Contributor

@yohann-bacha yohann-bacha left a comment

Choose a reason for hiding this comment

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

well the last nitpicks are not enough to block my approval, so LGTM! nice job

@curzolapierre curzolapierre merged commit 9b80d09 into master Nov 17, 2023
5 checks passed
@curzolapierre curzolapierre deleted the feat/1018/db_user_management branch November 17, 2023 14:47
Copy link

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[MAINTENANCE-WINDOWS | STORY-150] Database user management
2 participants