AppController - statefull app deployments

[pigmej]

Description

AppController will allow to work with statefull applications that involve many components (openstack for example) more easy and more native. AppController will understand dependencies between kubernetes objects and therefore it will create them in correct order.

kubernetes/kubernetes issue: kubernetes/kubernetes#29453

cc @kubernetes/sig-openstack @kubernetes/sig-apps

Progress Tracker

• Before Alpha
  • Write and maintain draft quality doc
    • During development keep a doc up-to-date about the desired experience of the feature and how someone can try the feature in its current state. Think of it as the README of your new feature and a skeleton for the docs to be written before the Kubernetes release. Paste link to Google Doc: DOC-LINK
  • Design Approval
    • Design Proposal. This goes under docs/proposals. Doing a proposal as a PR allows line-by-line commenting from community, and creates the basis for later design documentation. Paste link to merged design proposal here: PROPOSAL-NUMBER
    • Initial API review (if API). Maybe same PR as design doc. PR-NUMBER
      • Any code that changes an API (/pkg/apis/...)
      • cc @kubernetes/api
    • Identify shepherd (your SIG lead and/or kubernetes-pm@googlegroups.com will be able to help you). My Shepherd is: replace.me@replaceme.com (and/or GH Handle)
      • A shepherd is an individual who will help acquaint you with the process of getting your feature into the repo, identify reviewers and provide feedback on the feature. They are not (necessarily) the code reviewer of the feature, or tech lead for the area.
      • The shepherd is not responsible for showing up to Kubernetes-PM meetings and/or communicating if the feature is on-track to make the release goals. That is still your responsibility.
    • Identify secondary/backup contact point. My Secondary Contact Point is: replace.me@replaceme.com (and/or GH Handle)
  • Write (code + tests + docs) then get them merged. ALL-PR-NUMBERS
    • Code needs to be disabled by default. Verified by code OWNERS
    • Minimal testing
    • Minimal docs
      • cc @kubernetes/docs on docs PR
      • cc @kubernetes/feature-reviewers on this issue to get approval before checking this off
      • New apis: Glossary Section Item in the docs repo: kubernetes/kubernetes.github.io
    • Update release notes
• Before Beta
  • Testing is sufficient for beta
  • User docs with tutorials
    • Updated walkthrough / tutorial in the docs repo: kubernetes/kubernetes.github.io
    • cc @kubernetes/docs on docs PR
    • cc @kubernetes/feature-reviewers on this issue to get approval before checking this off
  • Thorough API review
    • cc @kubernetes/api
• Before Stable
  • docs/proposals/foo.md moved to docs/design/foo.md
    • cc @kubernetes/feature-reviewers on this issue to get approval before checking this off
  • Soak, load testing
  • detailed user docs and examples
    • cc @kubernetes/docs
    • cc @kubernetes/feature-reviewers on this issue to get approval before checking this off

FEATURE_STATUS is used for feature tracking and to be updated by @kubernetes/feature-reviewers.
FEATURE_STATUS: IN_DEVELOPMENT

More advice:

Design

• Once you get LGTM from a @kubernetes/feature-reviewers member, you can check this checkbox, and the reviewer will apply the "design-complete" label.

Coding

• Use as many PRs as you need. Write tests in the same or different PRs, as is convenient for you.
• As each PR is merged, add a comment to this issue referencing the PRs. Code goes in the http://github.com/kubernetes/kubernetes repository,
  and sometimes http://github.com/kubernetes/contrib, or other repos.
• When you are done with the code, apply the "code-complete" label.
• When the feature has user docs, please add a comment mentioning @kubernetes/feature-reviewers and they will
  check that the code matches the proposed feature and design, and that everything is done, and that there is adequate
  testing. They won't do detailed code review: that already happened when your PRs were reviewed.
  When that is done, you can check this box and the reviewer will apply the "code-complete" label.

Docs

• Write user docs and get them merged in.
• User docs go into http://github.com/kubernetes/kubernetes.github.io.
• When the feature has user docs, please add a comment mentioning @kubernetes/docs.
• When you get LGTM, you can check this checkbox, and the reviewer will apply the "docs-complete" label.

[smarterclayton]

Generally we prefer to only open features once we have rough consensus from one or more SiGs and a workable proposal. Since you've already started an issue, we can converse and discuss the feature proposal there and then come back and reopen this later. Adding a proposal describing your use cases to the issue is a good next step.

Thanks!

[pigmej]

@smarterclayton I was instructed by @idvoretskyi (sig-openstack lead) to do it that way.

[idvoretskyi]

@smarterclayton we have discussed that with @pigmej and I've proposed him to open the new feature as the soft deadline for 1.4 features is today.

I feel this feature useful in the scope of Kubernetes-OpenStack integration, so I'm advocating to reopen it to continue working on it. Other SIG's are welcome for further discussion.

cc @philips @aronchick to discuss it.

[aronchick]

If the SIG is good, then I'm good. @smarterclayton - were there some
specific concerns?

On Fri, Jul 22, 2016 at 8:08 AM, Ihor Dvoretskyi notifications@github.com
wrote:

@smarterclayton https://github.com/smarterclayton we have discussed
that with @pigmej https://github.com/pigmej and I've proposed him to
open the new feature as the soft deadline for 1.4 features is today.

I feel this feature useful in the scope of Kubernetes-OpenStack
integration, so I'm advocating to reopen it to continue working on it.
Other SIG's are welcome for further discussion.

cc @philips https://github.com/philips @aronchick
https://github.com/aronchick to discuss it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#42 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AADIdZ4qDqJES9WS-O342oMK1ymrtogSks5qYNz2gaJpZM4JSzwl
.

[philips]

@idvoretskyi @pigmej Thinking through the spirit of the consensus building I don't think this feature has met the bar. I think generally SIG consensus can be documented a few different means:

• Mailing list discussion
• Notes from a SIG meeting
• Issue or proposal that gets buy in

Right now it appears we have one other person from the SIG and a very young issue (kubernetes/kubernetes#29453) talking about this feature. I agree with closing this issue on those grounds. Lets try and get a bit more documentation on what this feature is and the problems it might be solving for folks before proceeding with a new feature.

[idvoretskyi]

@philips, thank you for clarifying. We will handle it within the SIG-OpenStack and I'm asking @kubernetes/sig-apps to support it.

I'm expecting to reopen the issue later, after clarifying within the SIG(s). Also, I'd like to reserve an exception for adding it to 1.4 after the criteria will be met.

[idvoretskyi]

@philips @aronchick I'd like to propose to define the criteria for submitting the "feature" with more details, I suppose, not all the Kubernetes community members are completely aware of it.

[bgrant0607]

Since this is discussing the meta-issue of how features should be used, I'll comment here.

Please be aware that SIG buy-in may not be sufficient for all features. For example, API changes require approval of API owners, and entirely new APIs must meet a higher bar.

I also commented on this specific proposal on kubernetes/kubernetes#29453.

[erictune]

I can't tell if you are saying that you have someone in line to implement
it, or if you are asking sig-apps to find someone to implement it.
People should file feature issues once they have high confidence they have
found people who will implement (and support for some period) the feature.

On Fri, Jul 22, 2016 at 9:22 AM, Brian Grant notifications@github.com
wrote:

Since this is discussing the meta-issue of how features should be used,
I'll comment here.

Please be aware that SIG buy-in may not be sufficient for all features.
For example, API changes require approval of API owners, and entirely new
APIs must meet a higher bar.

I also commented on this specific proposal on kubernetes/kubernetes#29453
kubernetes/kubernetes#29453.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#42 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AHuudiUBbZ75E5pmkb55CSnAwUL94r_uks5qYO47gaJpZM4JSzwl
.

[pigmej]

@erictune We ( @kubernetes/mirantis ) do have team to implement and support that. This is part of our contribution to k8s world.

[erictune]

Great, thanks for the clarification.

[pigmej]

@erictune sorry that it wasn't clear from the start.

[idvoretskyi]

Reopening the feature request.

@kubernetes/mirantis have presented the feature demo at the @kubernetes/sig-apps meeting, have received the positive feedback and a "green light" to move forward.

@pigmej please, update and fill the necessary fields in the Progress tracker.

[sarahnovotny]

per the feature burndown meeting today: this will land in kubernetes-incubator first and be promoted based on the criteria in - https://github.com/kubernetes/community/blob/master/incubator.md

[idvoretskyi]

@sarahnovotny we have discussed the ability to make this feature available in Kubernetes codebase and have decided to continue working with the feature implementing. To extend the feature functionality and make it tightly bound with Kubernetes codebase we have decided to continue the development of AppController in Kubernetes 1.5 scope.

[numbsafari]

Is the goal to replace kubernetes/helm with whatever is worked on here? Or is this merely orthogonal/related to what tiller does?

[erictune]

I had a user ask on slack today whether he/she should wait for AppController or use something else, after seeing this issue,

I think that shows there is a cost to having issues in the feature repo for ideas which are still at the concept stage.

[pigmej]

Speaking about this issue, I'm closing this one, because for now we're not joinning k8s core. AppController development will be continued at https://github.com/Mirantis/k8s-AppController, we will prepare design docs etc to discuss it with Kubernetes audience (we had some meetings on sig-apps). AppController will have 3week release cycle (we're going to form more formal roadmap etc in near future, and publish it on our repository)

@numbsafari (sorry for late reply), it's not going to replace helm, we're currently looking and searching for possible areas of cooperation between AppController and Helm.

[pigmej]

I forgot to click "close and comment" instead of "comment".