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: allow cert-manager annotations on ingress based on environment variables #86

Closed

Conversation

cloud-j-luna
Copy link
Member

This PR allows cert-manager annotations on ingress based on environment variables.

Copy link
Contributor

@boz boz left a comment

Choose a reason for hiding this comment

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

Looking great

cluster/kube/client.go Outdated Show resolved Hide resolved
cluster/kube/client_ingress.go Outdated Show resolved Hide resolved
@cloud-j-luna cloud-j-luna requested a review from boz February 22, 2023 19:17
boz
boz previously approved these changes Feb 27, 2023
Copy link
Contributor

@boz boz left a comment

Choose a reason for hiding this comment

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

🚀

cluster/util/environment.go Outdated Show resolved Hide resolved
Copy link
Contributor

@boz boz left a comment

Choose a reason for hiding this comment

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

Just a note that it's generally preferable to use a framework for reading environment variables. This or cobra+viper are good options.

@cloud-j-luna cloud-j-luna requested a review from boz February 27, 2023 20:12
Copy link
Contributor

@boz boz left a comment

Choose a reason for hiding this comment

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

🚀

@anilmurty
Copy link

from sig-support: @troian holding off merging this until he's confident about the code base from the changes for API refactor and 0.24 network upgrade

@troian
Copy link
Member

troian commented Apr 11, 2023

@cloud-j-luna rebase it on to gpu branch. we will merge it there first

@cloud-j-luna cloud-j-luna changed the base branch from main to gpu April 12, 2023 10:01
@cloud-j-luna
Copy link
Member Author

@troian rebased in to gpu there are some checks failing regarding commit message but as the commits get squashed it shouldn't be a problem, right?

@troian
Copy link
Member

troian commented Apr 12, 2023

@cloud-j-luna the gpu branch will not be squashed. the check is failing as commit message needs to be formatted with conventional commits spec.

@cloud-j-luna
Copy link
Member Author

@cloud-j-luna the gpu branch will not be squashed. the check is failing as commit message needs to be formatted with conventional commits spec.

I meant this PR to be squashed

@troian
Copy link
Member

troian commented Apr 12, 2023

yeah, however, the commit message is taken from PR.
there are other tests failing too

@cloud-j-luna cloud-j-luna force-pushed the luna/tls-cert-manager branch from 85a1083 to f629b8f Compare April 12, 2023 16:21
@cloud-j-luna cloud-j-luna force-pushed the luna/tls-cert-manager branch from f629b8f to 69740f6 Compare April 12, 2023 16:22
@troian troian changed the title Allow cert-manager annotations on ingress based on environment variables fix: pre-allocate environment variables map Apr 12, 2023
@cloud-j-luna cloud-j-luna changed the title fix: pre-allocate environment variables map feat: allow cert-manager annotations on ingress based on environment variables Apr 12, 2023
Copy link
Member

@troian troian left a comment

Choose a reason for hiding this comment

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

I gave it a little thought and a few things must be addressed.

  • tlsEnabled should also account if deployment requested issuing TLS certificate, it does not have to be mandatory
  • all the changes need tests, including e2e

cluster/mocks/client.go Outdated Show resolved Hide resolved
cluster/kube/client_ingress.go Outdated Show resolved Hide resolved
@@ -66,11 +67,20 @@ func kubeNginxIngressAnnotations(directive ctypes.ConnectHostnameToDeploymentDir
}
}

switch env["AKASH_PROVIDER_ISSUER_TYPE"] {
case "cluster-issuer":
result[fmt.Sprintf("%s/cluster-issuer", certManager)] = env["AKASH_PROVIDER_ISSUER_NAME"]
Copy link
Member

Choose a reason for hiding this comment

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

  1. it looks like we don't need both AKASH_PROVIDER_ISSUER_TYPE and AKASH_PROVIDER_ISSUER_NAME and call it AKASH_PROVIDER_CERT_ISSUER
  2. AKASH_PROVIDER_CERT_ISSUER should be defined in the provider env section
  3. env["AKASH_PROVIDER_ISSUER_NAME"] may return "" if env is not set

Copy link
Member Author

@cloud-j-luna cloud-j-luna Apr 14, 2023

Choose a reason for hiding this comment

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

  1. We need both as the resulting label is different. This will also help in the future if we want to automate per-deployment/account issuers.

Copy link
Member

Choose a reason for hiding this comment

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

what are the values of both env variables in this case?

Copy link
Member Author

Choose a reason for hiding this comment

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

In this case it would be AKASH_PROVIDER_ISSUER_TYPE = "cluster-issuer", AKASH_PROVIDER_ISSUER_NAME would be whatever the provider chose as the cert-manager ClusterIssuer name on the cluster. By default the name is letsencrypt as the default issuer is Let's Encrypt.

Copy link
Member

Choose a reason for hiding this comment

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

By having letsencrypt value, the code in the provider can deduct, that issue is cluster-issuer ?

Copy link
Member Author

Choose a reason for hiding this comment

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

it can't thus the cluster-issuer in the annotation, so the provider knows that its a ClusterIssuer called letsencrypt rather than a namespace scoped issuer called letsencrypt as well

Copy link
Member

Choose a reason for hiding this comment

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

if workload asks the provider to issue a certificate wouldn't it always be the cluster-issuer?

Copy link
Member Author

Choose a reason for hiding this comment

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

Depends on the provider configuration. For now only cluster-issuer are allowed for providers, but the client_ingress.go is ready to work with namespaced issuers.

result[fmt.Sprintf("%s/cluster-issuer", certManager)] = env["AKASH_PROVIDER_ISSUER_NAME"]
break
case "issuer":
result[fmt.Sprintf("%s/issuer", certManager)] = env["AKASH_PROVIDER_ISSUER_NAME"]
Copy link
Member

Choose a reason for hiding this comment

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

comment from section above applies here as well

@@ -98,6 +100,7 @@ func NewClient(ctx context.Context, log log.Logger, ns string, configPath string
ns: ns,
log: log.With("client", "kube"),
kubeContentConfig: config,
env: util.EnvironmentVariablesToMap(),
Copy link
Member

Choose a reason for hiding this comment

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

env variables must be validated for values and then read into dedicated struct fields

Copy link
Member Author

Choose a reason for hiding this comment

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

Here is a direct conversion from the environment variables to a map[string]string. I can make validations but after this call. To have more fine-grained error handling on unexpected values.

Copy link
Member

@troian troian Apr 14, 2023

Choose a reason for hiding this comment

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

we would rather want to see dedicated struct fields instead of env converted to map. map is useful as intermediate store in some circumstances (like converting data to json). Go is a strict type of language and we use as much of it.

client instantiation is the last step where all configuration values must be validated

I'm not sure what To have more fine-grained error handling on unexpected values. means. If there is an unexpected configuration client should exit with error.

Copy link
Member Author

Choose a reason for hiding this comment

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

It means we know the context in which the usage gave an error. Having a struct makes absolute sense! I'll change the code to support such configuration rather than environment variables

Copy link
Member

Choose a reason for hiding this comment

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

We treat an error as an error, it is really hard to chase configuration errors on the fly.

  1. the client must not interact with env variables, configs etc, the only way for it to receive configuration is thru a parameter to NewClient.
  2. Each environment variable must have a corresponding cli flag for it. That's why using env within the client breaks it.
  3. Using environment variables inside implementation complicates writing unit tests.

remove environment variables from the client completely and use struct fields as values during annotations init.
I'm still unsure if using two different vars is the correct way to do it. if the workload going to use ns issuer then it has nothing to do with the cluster

@troian troian deleted the branch akash-network:gpu April 17, 2023 15:29
@troian troian closed this Apr 17, 2023
@troian
Copy link
Member

troian commented Apr 17, 2023

apparently gh closes PRs if base branched merged, you’ll have to reopen it.

@cloud-j-luna
Copy link
Member Author

apparently gh closes PRs if base branched merged, you’ll have to reopen it.

I have to open a new PR, to which branch do you want me to merge to? This branch is rebased on the gpu branch.

@troian
Copy link
Member

troian commented Apr 18, 2023

to the main

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.

4 participants