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

Update Readme adding placeholders for AWS and other install options #41

Merged
merged 4 commits into from
Jul 15, 2021

Conversation

tiina303
Copy link
Contributor

@tiina303 tiina303 commented Jul 8, 2021

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).

@macobo
Copy link
Contributor

macobo commented Jul 9, 2021

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:

  1. Assign it to yourself - since we're distributed keeping what we're working on clear is really really important.
  2. write up the instructions wholesale, e.g. under the issue
  3. We'll consolidate them into the README either together or I can own it :)

@@ -14,7 +14,7 @@ image:
pullPolicy: IfNotPresent

# -- Cloud service being deployed on. Either `gcp` or `aws` or `do` for DigitalOcean
cloud: "gcp"
cloud:
Copy link
Contributor

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") }}
Copy link
Contributor

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?

Copy link
Contributor Author

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.

### How can I connect to my ClickHouse instance?

- Get the IP via `kubectl get svc`
- Get the IP via `kubectl get svc --namespace posthog`
Copy link
Contributor

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.

charts/posthog/README.md Outdated Show resolved Hide resolved
# Note that this is experimental, please let us know how this worked for you.

cloud: gcp
ingress:
hostname: "posthog.yourcloud.net"
Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

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.

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 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
Copy link
Contributor

@macobo macobo Jul 9, 2021

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.

Copy link
Contributor Author

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)?

```

Create a `CNAME` record from your desired hostname to the external IP.

### Setting up email
Copy link
Contributor

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.

Copy link
Contributor Author

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
Copy link
Contributor

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.

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 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.

helm install -f values.yaml --timeout 20m --create-namespace --namespace posthog posthog posthog/posthog
```

Where the `values.yaml` has the following minimum content:
Copy link
Contributor

@macobo macobo Jul 9, 2021

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.

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 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.

@tiina303
Copy link
Contributor Author

Still wip, but going to separate out per platform like Karl suggested.
We could consider changing the guide to start without having a hostname specified as folks might run into issues and things are faster if they don't need to figure out how to access it & wait for DNS to update etc. Then step 2 is securing it.

@tiina303 tiina303 merged commit 684c3d6 into main Jul 15, 2021
@tiina303 tiina303 deleted the readme-placeholders branch July 15, 2021 17:21
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

2 participants