-
Notifications
You must be signed in to change notification settings - Fork 74
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
Update Readme adding placeholders for AWS and other install options #41
Conversation
What should I as a reviewer review here? I'm not sure what problem this is solving, who the new intended audience is and hence why the structure is like this. Is there a ticket this belongs under? Proposal: If you're taking over #36 then:
|
charts/posthog/values.yaml
Outdated
@@ -14,7 +14,7 @@ image: | |||
pullPolicy: IfNotPresent | |||
|
|||
# -- Cloud service being deployed on. Either `gcp` or `aws` or `do` for DigitalOcean | |||
cloud: "gcp" | |||
cloud: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is not a README change.
@@ -17,16 +17,6 @@ metadata: | |||
kubernetes.io/ingress.global-static-ip-name: {{ .Values.ingress.gcp.ip_name | quote }} | |||
{{- end }} | |||
{{- end }} | |||
{{- if (eq (include "ingress.type" .) "alb") }} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why remove this as part of README changes?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
being lazy ... because I was looking into this as I was writing up the minimum values files, but I can make it a separate PR.
charts/posthog/README.md
Outdated
### How can I connect to my ClickHouse instance? | ||
|
||
- Get the IP via `kubectl get svc` | ||
- Get the IP via `kubectl get svc --namespace posthog` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change is wrong: Other commands here don't encourage specifying the namespace. Users can also specify any namespace they'd like - --namespace posthog
varies from one to the other.
# Note that this is experimental, please let us know how this worked for you. | ||
|
||
cloud: gcp | ||
ingress: | ||
hostname: "posthog.yourcloud.net" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why? Without this users won't be able to access their cluster.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same, this is part of the required config that I moved up to install
# Note that this is experimental, please let us know how this worked for you. | ||
|
||
cloud: gcp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why? Without this this yaml file does not work.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is gcp specific, I moved that part up to the minimal required configuration within install section, the sizing stuff is otherwise is platform agnostic.
## Upgrading the chart | ||
|
||
```console | ||
helm repo update | ||
helm upgrade -f values.yaml posthog posthog/posthog | ||
helm upgrade -f values.yaml --timeout 20m --namespace posthog posthog posthog/posthog |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Re upgrade timeout: Why is it needed? Timeout is needed during initial install since clickhouse-operator takes a while to setup. This is not the case with upgrades.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't slow migrations take longer than 5min sometimes (what about clickhouse version upgrades)?
charts/posthog/README.md
Outdated
``` | ||
|
||
Create a `CNAME` record from your desired hostname to the external IP. | ||
|
||
### Setting up email |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Structure-wise this is awkwardly placed. This should be under the configuration
section as everything else.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure this is kind of optional, so happy to move.
|
||
```console | ||
helm repo add posthog https://posthog.github.io/charts-clickhouse/ | ||
helm repo update | ||
helm install -f values.yaml --timeout 20m posthog posthog/posthog | ||
helm install -f values.yaml --timeout 20m --create-namespace --namespace posthog posthog posthog/posthog |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why install in a namespace by default in the instructions here.
I think we can assume the users who want separate namespaces will know how to do so. Encouraging to do so by default:
- increases command complexity, the amount of flags you need to specify when installing
- It makes debugging anything on the cluster more complicated.
If you're installing on a shared cluster, sure that makes sense. However I don't think we should encourage it here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think if we always use a namespace it works the same way for everyone being on a shared cluster or not. It's also much easier for us to say just nuke the whole namespace with everything in it without needing to verify they are only running Posthog there first. There's an easy command for kubectl to be in a specific namespace, so you don't need to provide this argument every time. That said I don't feel strongly about this, just figured it could make our lives easier in the long run.
charts/posthog/README.md
Outdated
helm install -f values.yaml --timeout 20m --create-namespace --namespace posthog posthog posthog/posthog | ||
``` | ||
|
||
Where the `values.yaml` has the following minimum content: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This structure is kind of bad and needs to evolve as we support more deployment options.
We now have install section which gives some overview of configuration and then a separate configuration section. As a reader if I have a question I can't follow the structure to find what I'm looking for anymore.
I'd recommend keeping all of configuration in one place and linking to relevant sections instead. As-is this just makes the flow harder to follow.
It'd be great to prepare the AWS instructions first though as once we have them a clearer structure might fall into place in a clearer way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The way I saw it is "Configuration" is optional stuff, this in here is mandatory (so the user needing to go down to the configuration section added complexity for most folks, who just wanted to make the simplest thing run which I believe is the majority). I'd love if we didn't need it, but I haven't seen a way we could make the chart work with default values for multiple deployments. I looked into it and then only needing 1 value (cloud being the only required setting through values.yaml or --set cloud=gcp
or --set cloud=aws
), but being able to enable/disable nginx,certManager was tricky based on other values in the yaml sadly.
56c4e89
to
26f14a7
Compare
Still wip, but going to separate out per platform like Karl suggested. |
The readme currently was focused on GCP, tried to make it cover more ground + various nits. Will try to do the actual deployments on GCP and AWS too & document further (and add a bit more details for DO setup where I have manually deployed to already).