Skip to content
This repository has been archived by the owner on Sep 30, 2020. It is now read-only.

Documentation of long-term managing capabilities #61

Closed
aholbreich opened this issue Nov 15, 2016 · 9 comments
Closed

Documentation of long-term managing capabilities #61

aholbreich opened this issue Nov 15, 2016 · 9 comments
Labels
documentation help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed.

Comments

@aholbreich
Copy link

Maybe this is only documentation issue...

But for me it appears to be unclear if this project is meant to support created kubernetes cluster over time or just initial provisioning.
If it is meant to be long term support i miss a docuimetnation (wiki?), that states clearly what to do i common situation like scaling to new number if nodes or another management stuff.

Lucky, there is propably not so much, but still worth to document it clear in detail for those who not involved in this project so much - but just want to use it. Or step before, get idea of it.

@aholbreich aholbreich changed the title Manging capabities Documentation of long-term managing capabilities Nov 15, 2016
@pieterlange
Copy link
Contributor

This project is definitely geared towards full cluster lifecycle issues - initializing takes the most effort right now so it gets the most attention.

We should add a cluster lifecycle management document which describes various runbook scenarios, though i feel like most of those things should happen automatically soon (like manually scaling up (&down) a cluster)

@mumoshu mumoshu added the help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. label Nov 17, 2016
@mumoshu
Copy link
Contributor

mumoshu commented Nov 17, 2016

I'd definitely like to add that kind of documentation to kube-aws.
I'm afraid I can't work on it shortly though and therefore the help wanted label 🏷
In the meantime, I'd like to encourage everyone to contribute by pull requests with a documentation describing various scenarios in managing kube-aws created clusters.

@aholbreich
Copy link
Author

@mumoshu first why not use wiki tab of this repo... as main documentation... Community can easily contribute to it.

@h0tbird
Copy link

h0tbird commented Dec 5, 2016

+1 for adding extra workers to the initial cluster.

@mumoshu
Copy link
Contributor

mumoshu commented Dec 6, 2016

@aholbreich We're maintaining docs in git because we don't want to diverge our documentations and wiki doesn't allow reviews.

I personally like GitHub wiki. However, currently, everything under the Documentation/ directory is published to https://coreos.com/kubernetes/docs/latest/kubernetes-on-aws.html after each final release of kube-aws. Therefore using wiki in kube-aws means we need to maintain diverged docs for coreos.com and wiki, which is what we want to avoid as there are no dedicated maintainer(s) just for docs.

Also AFAIK wiki doesn't allow reviews or pull requests before updating. I'm not yet sure how I could efficiently maintain a wiki which I can't handle when/how/by whom it is updated.

Everything is possible if I could have infinite time and/or more contributors/maintainers but in the mean time, as a primary maintainer, I'd rather like to focus on merging pull requests, tackling big refactorings, implementing new features, in order of priority, because these are what (I believe) only a maintainer can do right now.

Regardless of our current situation, I'd definitely like to have more documentation in kube-aws hence the help wanted label.
If anyone is willing to maintain our documentation in any way, or willing to share other maintenance works, I'd appreciate it!

tyrannasaurusbanks pushed a commit to tyrannasaurusbanks/kube-aws that referenced this issue Sep 14, 2018
…eaws-funcmaps-within-customfile-templates to hcom-flavour

* commit 'decba92d22683cf3a093dc1c5b3882b04ff1f126':
  Use kube-aws texttemplate Parse so we have access to its funcmaps.
@fejta-bot
Copy link

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

@k8s-ci-robot k8s-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Apr 20, 2019
@fejta-bot
Copy link

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

@k8s-ci-robot k8s-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels May 21, 2019
@fejta-bot
Copy link

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

@k8s-ci-robot
Copy link
Contributor

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
documentation help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed.
Projects
None yet
Development

No branches or pull requests

6 participants