nebari-dev / nebari-dev/nebari-docs
[DOC] - Add explanation for choosing to deploying Nebari on an "existing" kubernetes cluster
Nobody has claimed this yet.
- Dominant language
- No language data
- Stars
- 21
- Forks
- 40
- Avg merge
- 19h 50m
- Merged PRs (30d)
- 6
Description
Preliminary Checks
- This issue is not a question, feature request, RFC, or anything other than a bug report. Please post those things in GitHub Discussions: https://github.com/nebari-dev/nebari/discussions
Summary
Comment:
I think we need to pick a better catch-all term for this kind of installation, or split it into separate "pre-existing" and "local" installation types. Users with pre-existing k8s infra are probably of a very different type than users who want to trial Nebari with a local install.
This probably means adding an additional how-tos page, at minimum... keeping the current (stub) how-tos/nebari-local.md, and adding a new `how-tos/nebari-k8s.md', say.
Even if they're functionally the same set of instructions (seems unlikely to me? a local install seems likely to be very different from an on-k8s install), the k8s user set is probably going to need a lot less assistance than the local-install user set.
Response:
The local installation is a pre-existing one as well because you need to create the Kubernetes ecosystem using Mikikube and then deploy Nebari inside the virtual node. But I agree that installing on a pre-existing Kubernetes cluster should go to a different how-to as well because it's restricted to what cloud provider or where the cluster is currently hosted/built-in, as well as the security policies already present in the target infrastructure.
Steps to Resolve this Issue
Decide the best way to resolve this - choose better naming conventions, add more details, add separate docs for each types ???
And then do it
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading how-tos/nebari-local.md and the discussion from nebari-docs PR #45. Compare the existing local-install guidance with the needs of users deploying to an existing Kubernetes cluster, then determine whether naming changes, additional detail, or a separate how-tos/nebari-k8s.md page is appropriate. Done means the installation types and their requirements are clearly distinguished.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- kubernetes
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100