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

Upgrade operator sdk + a few fixes #8

Merged
merged 22 commits into from
Jun 3, 2022
Merged

Upgrade operator sdk + a few fixes #8

merged 22 commits into from
Jun 3, 2022

Conversation

paullaffitte
Copy link
Contributor

This PR contains work from various PR from our fork at Enix. Here is a changelog:

  • Use lpass status to validate re-login and disable logout command πŸ› οΈ
  • De-hardcode namespace in helm chart πŸ› οΈ
  • Upgrade operator-sdk from 0.8.1 to 1.5.2 πŸŽ‰
  • Upgrade golang from <1.13 (before go modules are the default) to golang 1.17 πŸŽ‰
  • Upgrade crdVersion from v1alpha1 to v1 πŸŽ‰
  • Start building the operator binary inside the Dockerfile with multi-stage build instead of doing it outside before copying it πŸŽ‰
  • Fix missing required namespace in ClusterRoleBinding πŸ› οΈ
  • Add flag (and helm value) to define a template for secrets names πŸŽ‰

donch and others added 21 commits April 7, 2022 17:46
Namespace is handled by helm and should not be hardcoded
Use of lpass status to validate re-login and disabling logout command
Remove unneeded id from secretName
echo  | docker login -u paullaffitte
Error: Cannot perform an interactive login from a non TTY device
if err != nil || "" == string(out) {
// sometimes returns error: "Error: HTTP response code said error" even if the credentials are valid
return fmt.Errorf("verify credentials, unable to login: %s", err)
_, err := sh.Command("lpass", "status").Output()
Copy link
Member

Choose a reason for hiding this comment

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

out of curiosity, any performance issues for doing this i.e. skipping the logout?

Copy link
Contributor

Choose a reason for hiding this comment

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

Hi, i didn't spot any performance issues, but in our use-case, we need to sync hundreds of secrets, with the logout activated, we get banned from Lastpass.
We didn't try to Log in at each secret synchronisation, but we'll probably get banned too from Lastpass.

Copy link
Member

Choose a reason for hiding this comment

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

Fair enough!

}
log.Printf("Succesfully logged in")
return nil
}

// Logout using lastpass-cli
func Logout() {
// lpass logout --force
Copy link
Member

Choose a reason for hiding this comment

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

i would probably keep the implementation and comment lastpass.Logout() in here - No point in keeping the method around otherwise

Copy link
Contributor

Choose a reason for hiding this comment

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

I think it will be ok πŸ‘ Thanks

Copy link
Member

Choose a reason for hiding this comment

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

I'll look into it πŸ˜‰

MetricsBindAddress: metricsAddr,
Port: 9443,
LeaderElection: enableLeaderElection,
LeaderElectionID: "e9330328.edgelevel.com",
Copy link
Member

Choose a reason for hiding this comment

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

what is e9330328 for?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This part of the code was generated by Operator SDK, it's just a random ID to ensure it's unique I guess.

[]Reporter{printer.NewlineReporter{}})
}

// var _ = BeforeSuite(func(done Done) {
Copy link
Member

Choose a reason for hiding this comment

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

were these tests auto-generated?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, they were

return &corev1.Secret{
ObjectMeta: metav1.ObjectMeta{
Name: cr.Name + "-" + secret.ID,
Name: secretName.String(),
Copy link
Member

Choose a reason for hiding this comment

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

i haven't used it in a while, just wondering about potential regressions, do you have an example of how it was looking before cr.Name + "-" + secret.ID compared to now?

Copy link
Member

Choose a reason for hiding this comment

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

I think I remembered why I did this, would there be any potential issues with secret conflicts? See example in the readme example-lastpass-8190226423897406876

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The secretName variable comes from a go template. The default template used to generate the secret name is the following one {{.LastPass.ObjectMeta.Name}}-{{.LastPassSecret.ID}}, so it replicate the old behavior and should not introduce any breaking change. After this change I get by default names like the following lp-cred1-7726733720672245904.

Copy link
Member

Choose a reason for hiding this comment

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

Thanks for clarifying this!

imagePullPolicy: Always
{{- if ne .Values.secretNameTemplate "" }}
args:
- --secret-name-template={{ .Values.secretNameTemplate }}
Copy link
Member

Choose a reason for hiding this comment

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

what is this exactly for?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This is the go template I talked about above. The default one is {{.LastPass.ObjectMeta.Name}}-{{.LastPassSecret.ID}} in order to avoid breaking changes. Setting the secretNameTemplate value in helm chart allows to override this value.

@niqdev
Copy link
Member

niqdev commented May 25, 2022

@paullaffitte I'm really grateful for the help here! Amazing work, thanks!

A couple of things

  • would there be any issue if I upgrade the chart to helm 3? are you actually pointing to the chart currently in the repo?
  • I'll definitely update the release process to use GH actions
  • do you mind if I ping you directly or involve in reviewing PRs in the future?
  • Please consider creating a separate PR adding yourself or Enix as contributors in the README!

Thanks again for contributing to the project! I'll wait for your feedback in the comments and then I'll merge the PR

@paullaffitte
Copy link
Contributor Author

You're welcome, it's always a pleasure to help open-source projects πŸ™‚

We tried our best to answer your above questions.

And to answer your last message:

  • We already use helm 3 so it's totally fine to upgrade the chart.
  • Nice!
  • Sure, If I can be of any help.
  • We will do it, thanks πŸ™‚

@niqdev
Copy link
Member

niqdev commented May 30, 2022

Hi, I haven't installed go and operator-sdk in a while, I'm updating the doc and I was trying to build your repo/branch first and I realized that there were some simple issues to fix in the makefile e.g. replace go get with go install, which led me to look into the dependency versions...

Was there any concern in bumping to the latest operator-sdk version, i.e. 1.21.0 cos of too many breaking changes, or it just happened that you did this a while back and the version went forward? Don't get me wrong, I'm just trying to understand your changes πŸ˜…

The main reason for asking this is because I need to fix the CI and install the right version of the operator etc., that's all!

@paullaffitte
Copy link
Contributor Author

Hi, the makefile was generated by operator-sdk, what is the issue with go get ?

Concerning operator-sdk version, we upgraded it for some reasons, and we just had no reason to upgrade to the latest version, so to save time I stopped at the first version meeting our requirements. But I think it's completely fine to bump the version until the latest one. Our reasons were the following:

  • We want to build everything from inside the docker image (instead of building locally and then copy the file into the image).
  • We want to upgrade at least to the first "stable" version (1.0.0 or above) see below why.
  • We want to use crds version v1 instead of v1beta1 (since operator-sdk 1.0.0).
  • v1.5.0 is the first version where PROJECT config version 3-alpha is deprecated in favor of version 3. Some files in version 3-alpha seem to not exist anymore so it seems to be impossible to install and use operator-sdk between 1.0.0 and 1.5.0.
  • We want to use go modules by default (since golang 1.13) and use it's latest available version if possible (1.17).

Why we wanted to upgrade to at least v1.0.0

One of our goals where to be able to upgrade easily the operator in the future.

When upgrading your version of Operator-sdk, it is intended that post-1.0.0 minor versions (i.e. 1.y) are backwards compatible and strictly additive. Therefore, you only need to re-scaffold your operator with a newer version of Operator-SDK if you wish to take advantage of new features. If you do not wish to use new features, all that should be required is bumping the operator image dependency (if a Helm or Ansible operator) and rebuilding your operator image.
https://sdk.operatorframework.io/docs/upgrading-sdk-version/

Now that all of this is done, the remaining upgrades should be easier and faster than the previous ones.

@niqdev
Copy link
Member

niqdev commented Jun 3, 2022

Thanks for all the details, that was very helpful! I'll let you know when I release the image with your changes πŸš€

@niqdev niqdev merged commit aa5913b into edgelevel:master Jun 3, 2022
@niqdev niqdev mentioned this pull request Jun 3, 2022
8 tasks
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

4 participants