Skip to content

Add a Stripe settings secret to server #10308

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

Merged
merged 1 commit into from
May 31, 2022
Merged

Add a Stripe settings secret to server #10308

merged 1 commit into from
May 31, 2022

Conversation

jankeromnes
Copy link
Contributor

@jankeromnes jankeromnes commented May 27, 2022

Description

Add a Stripe settings secret to server, in order to provide the secret key for API calls.

Related Issue(s)

Fixes #

How to test

  • Builds without payment should succeed (and not have a Stripe volume mounted on server pod)
  • Build with payment should succeed, and have the Stripe volume mounted:
$ kubectl describe pod server-5995b76459-llfwg
[...]
Volumes:
[...]
  stripe-config:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  stripe-config
    Optional:    false

Release Notes

NONE

Documentation

  • /werft with-clean-slate-deployment
  • /werft with-payment=true

@jankeromnes
Copy link
Contributor Author

jankeromnes commented May 30, 2022

Whoops, server is in CrashLoopBackoff due to:

Error: ENOENT: no such file or directory, open '/stripe/settings'

🤔

@jankeromnes jankeromnes force-pushed the jx/stripe-secret branch 2 times, most recently from 3008967 to ce76080 Compare May 30, 2022 10:07
@jankeromnes
Copy link
Contributor Author

jankeromnes commented May 30, 2022

Aha, maybe it's because payment is disabled? Let's try:

/werft run with-payment=true

👍 started the job as gitpod-build-jx-stripe-secret.4
(with .werft/ from main)

EDIT: Nope, that wasn't it -- still crash-looping.

@geropl
Copy link
Member

geropl commented May 30, 2022

@jankeromnes Does not have the volume mounted:
image

Possible reasons:

  • in the werft scripts, are we using the correct version of the installer (e.g., the one from this branch build?)
  • somehow the modification did not pan out (debug: print config.yaml - would be nice to have in werft in general!)
    🤷

@jankeromnes
Copy link
Contributor Author

jankeromnes commented May 30, 2022

Aha, good point! 🎯 Many thanks @geropl. Will re-trigger Werft with the config from my branch.

EDIT: Re-triggered like so:

$ kubectx dev
Switched to context "dev".

$ werft job run github gitpod-io/gitpod:jx/stripe-secret -j .werft/build.yaml
gitpod-custom-jx-stripe-secret.0

https://werft.gitpod-dev.com/job/gitpod-custom-jx-stripe-secret.0

@jankeromnes
Copy link
Contributor Author

jankeromnes commented May 30, 2022

Stripe secret successfully mounted! 🎉

$ kubectl describe pod server-5995b76459-llfwg
[...]
Volumes:
[...]
  stripe-config:
    Type:        Secret (a volume populated by a Secret)
    SecretName:  stripe-config
    Optional:    false

(Also, Chargebee still works. ✅)

Now testing a build without payment...

@jankeromnes
Copy link
Contributor Author

jankeromnes commented May 30, 2022

Without payment, server crash-loops with:

Unable to load ChargebeeProviderOptions from: /chargebee/providerOptions

and

Error: ENOENT: no such file or directory, open '/stripe/settings'

EDIT: I see that the Chargebee error is just a warning, while the Stripe error is the one that makes server crashloop.

However, when payment is disabled (for example in Self-Hosted), I think it would be much nicer to not even try to load Chargebee or Stripe secrets, as opposed to trying + failing + logging (potentially confusing) warnings about payment-related stuff.

Attempting to fix this like so:

Screenshot 2022-05-30 at 16 25 45

@jankeromnes
Copy link
Contributor Author

jankeromnes commented May 30, 2022

Alright, seems to work fine now! 🎉

Without payment

https://werft.gitpod-dev.com/job/gitpod-build-jx-stripe-secret.6 Build succeeded ✅

Logging in works ✅ / No payment UI ✅ Volume is not mounted ✅
Screenshot 2022-05-30 at 16 55 30 Screenshot 2022-05-30 at 16 56 20

With payment

https://werft.gitpod-dev.com/job/gitpod-custom-jx-stripe-secret.3 Build succeeded ✅

Logging in works ✅ / Payment UI is there ✅ Volume is mounted ✅
Screenshot 2022-05-30 at 17 06 49 Screenshot 2022-05-30 at 17 11 19

@jankeromnes jankeromnes marked this pull request as ready for review May 30, 2022 15:12
@jankeromnes jankeromnes requested review from a team May 30, 2022 15:12
@github-actions github-actions bot added team: delivery Issue belongs to the self-hosted team team: webapp Issue belongs to the WebApp team labels May 30, 2022
Comment on lines +197 to +206
Name: "stripe-config",
VolumeSource: corev1.VolumeSource{
Secret: &corev1.SecretVolumeSource{
SecretName: stripeSecret,
},
},
})

volumeMounts = append(volumeMounts, corev1.VolumeMount{
Name: "stripe-config",
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
Name: "stripe-config",
VolumeSource: corev1.VolumeSource{
Secret: &corev1.SecretVolumeSource{
SecretName: stripeSecret,
},
},
})
volumeMounts = append(volumeMounts, corev1.VolumeMount{
Name: "stripe-config",
stripeConfigVolumeName = "stripe-config"
// ...
Name: stripeConfigVolumeName,
VolumeSource: corev1.VolumeSource{
Secret: &corev1.SecretVolumeSource{
SecretName: stripeSecret,
},
},
})
volumeMounts = append(volumeMounts, corev1.VolumeMount{
Name: stripeConfigVolumeName,

Because they need to match, they should reference the same variable.

@@ -208,8 +216,9 @@ func configmap(ctx *common.RenderContext) ([]runtime.Object, error) {
ImageBuilderAddr: "image-builder-mk3:8080",
CodeSync: CodeSync{},
VSXRegistryUrl: fmt.Sprintf("https://open-vsx.%s", ctx.Config.Domain), // todo(sje): or "https://{{ .Values.vsxRegistry.host | default "open-vsx.org" }}" if not using OpenVSX proxy
EnablePayment: chargebeeSecret != "",
EnablePayment: chargebeeSecret != "" || stripeSecret != "",
Copy link
Member

Choose a reason for hiding this comment

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

Why put this behind payment? Can we not enable this by default? I'm assuming the secret we have would only go into a test mode of stripe anyway so there's no risk enabling. This would also help remove yet another config option.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think we want to enable anything Stripe-related in Self-Hosted, where payment is disabled.

Copy link
Member

Choose a reason for hiding this comment

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

That makes sense. However, currently the stripe config is in experimental mode and only configured for preview. That alone should be enough for it to not be deployed in self-hosted. Am I missing something?

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 actually the other way around, right? I.e. we set EnablePayment to true if either the chargebeeSecret or the stripeSecret is set. 💭

Copy link
Member

Choose a reason for hiding this comment

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

Okay, that makes more sense. Would it make sense to separate them then? We may want to keep Chargbee enabled, but disable Stripe.

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 the code makes sense as-is. "enablePayment" is a legacy field that we should aim to remove when we kill the chargbee integration. Until we're there, and especially in the context of this PR, it make sense to keep it.

Might make sense to try and remove it from the config surface altogether (and only keep it internall where it make sense) in a separate PR.

@geropl
Copy link
Member

geropl commented May 31, 2022

However, when payment is disabled (for example in Self-Hosted), I think it would be much nicer to not even try to load Chargebee or Stripe secrets, as opposed to trying + failing + logging (potentially confusing) warnings about payment-related stuff.

@jankeromnes in Self-Hosted neither stripe nor chargebee files are configured, so this is a non-issue. But am ok with the if (payment && stripeFile) pattern. 👍

Copy link
Contributor

@corneliusludmann corneliusludmann left a comment

Choose a reason for hiding this comment

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

Approving changes in self-hosted owned file install/installer/pkg/config/v1/experimental/experimental.go to unblock this pull request. 🛹

Copy link
Member

@geropl geropl left a comment

Choose a reason for hiding this comment

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

👍

@roboquat roboquat merged commit 92e2e72 into main May 31, 2022
@roboquat roboquat deleted the jx/stripe-secret branch May 31, 2022 08:10
@jankeromnes
Copy link
Contributor Author

jankeromnes commented May 31, 2022

Many thanks @geropl @easyCZ and @corneliusludmann for the quick & very helpful reviews! 💯

@jankeromnes in Self-Hosted neither stripe nor chargebee files are configured, so this is a non-issue. But am ok with the if (payment && stripeFile) pattern. 👍

FYI I added the payment check because in this Pull Request, when I disabled payment, both Chargebee and Stripe sections failed because of not being configured (Chargebee logged a warning, but Stripe caused a crash).

I assumed this would be the same behavior in Self-Hosted -- if I'm right, when you install Self-Hosted, you'll get a warning about Chargebee not being configured. (Not really a big issue though.)

@roboquat roboquat added the deployed: webapp Meta team change is running in production label Jun 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
deployed: webapp Meta team change is running in production release-note-none size/M team: delivery Issue belongs to the self-hosted team team: webapp Issue belongs to the WebApp team
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants