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

New secret syncing #385

Closed
wants to merge 14 commits into from
Closed

Conversation

erthalion
Copy link
Contributor

First implementation of idea to make the operator more transparent.


type MetaData struct {
cluster *Cluster
namespace string

Choose a reason for hiding this comment

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

namespace is unused

@coveralls
Copy link

coveralls commented Sep 12, 2018

Coverage Status

Coverage remained the same at 23.766% when pulling b44bf1d on feature/actions-for-secret-syncing into 9c75588 on master.


var NoActions []Action = []Action{}

type MetaData struct {
Copy link
Member

Choose a reason for hiding this comment

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

probably "ActionMetaData" reads better?


if hasNewName {
return util.NameFromMeta(event.NewSpec.ObjectMeta)
} else {
Copy link
Member

Choose a reason for hiding this comment

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

is this else really needed ? just leave the 2nd return on its own.


type Action interface {
Name() string
Validate() error
Copy link
Member

Choose a reason for hiding this comment

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

so the intention is to validate before applying but it is up to the interface user to make so ?


// if this secret belongs to the infrastructure role and the password has
// changed - replace it in the secret
updateSecret := (user.Password != string(action.secret.Data["password"]) &&
Copy link
Member

Choose a reason for hiding this comment

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

mustUpdateInfraRoleSecret?

msg = "Could not update infrastructure role secret for role %q: %v"
return fmt.Errorf(msg, action.secretUsername, err)
}
} else {
Copy link
Member

Choose a reason for hiding this comment

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

that's a bit confusing in a sense that if in one branch I see secret update, in the other branch I excpect to see logic describing what happens if a secret is not updated, and not the udpate of a secret of another type

@@ -200,6 +200,45 @@ func (c *Cluster) initUsers() error {
return nil
}

func CreateSecrets() []Action {
Copy link
Member

Choose a reason for hiding this comment

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

that deserves a comment because I'd expect this function to return sth secret-related and not simply nil

}

// TODO: mind the secrets of the deleted/new users
func (c *Cluster) PlanForSecrets() (plan []Action) {
Copy link
Member

Choose a reason for hiding this comment

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

it is worth commenting here what a plan actually means (sequence of actions i assume? ) It is not immediately obvious for a person w/o operator and DB background

@sdudoladov
Copy link
Member

@erthalion can you please add an overview of the idea so that other people can easier join reviewing ?


type MetaData struct {
cluster *Cluster
namespace string

Choose a reason for hiding this comment

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

namespace is unused

@erthalion erthalion changed the title [WIP] New secret syncing New secret syncing Oct 4, 2018
@erthalion
Copy link
Contributor Author

So, @zerg-junior @alexeyklyukin what do you think about this feature?

Copy link
Member

@sdudoladov sdudoladov left a comment

Choose a reason for hiding this comment

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

  1. during debugging is there a way to see a generated plan without applying it first ?
  2. this change needs some overview documentation to ensure we are all on the same page

}

func (c *Controller) validatePlan(plan cluster.Plan) (err error) {
for _, action := range plan {
Copy link
Member

Choose a reason for hiding this comment

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

i'd prefer to have all actions validates first and reported to the end user at once, to avoid re-running the validation just to discover an error after an error .

// build plan
actions := c.generatePlan(event)
if err := c.validatePlan(actions); err != nil {
c.logger.Errorf("Invalid plan: %v", err)
Copy link
Member

Choose a reason for hiding this comment

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

so we nevertheless apply the erroneous plan ?

}

func (action ActionSecret) Validate() error {
if action.secret.Data["username"] == nil {
Copy link
Member

Choose a reason for hiding this comment

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

do all the secrets handled by the operator always have the username field ?

@k1ng440
Copy link

k1ng440 commented Jan 19, 2019

@erthalion you might want to answer those questions above?

False = false
True = true
False = false
logger = logrus.New().WithField("test", "cluster")

Choose a reason for hiding this comment

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

logger is unused (from deadcode)

)

const (
superUserName = "postgres"

Choose a reason for hiding this comment

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

superUserName is unused (from deadcode)


const (
superUserName = "postgres"
replicationUserName = "standby"

Choose a reason for hiding this comment

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

replicationUserName is unused (from deadcode)

@sdudoladov
Copy link
Member

@erthalion @Jan-M what is our position on this change ? do we continue ?

@erthalion
Copy link
Contributor Author

Of course we need to continue.

@FxKu FxKu added this to the v1.2 milestone May 20, 2019
@sdudoladov
Copy link
Member

closed for now due to the lack of activity

@sdudoladov sdudoladov closed this May 31, 2019
@sdudoladov sdudoladov removed this from the v1.2 milestone May 31, 2019
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.

None yet

6 participants