Enhancements: Workload API

Created on 20 Jul 2017 · 19Comments · Source: kubernetes/enhancements

Feature Description

One-line feature description (can be used as a release note): The core workload API (DaemonSet, Deployment, ReplicaSet, StatefulSet) have been moved to the apps group at version v1beta2.
Primary contact (assignee): @kow3ns
Responsible SIGs: apps
Design proposal link (community repo): NA
Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: @kargakis @janetkuo @foxish @enisoc @crimsonfaith91
Approver (likely from SIG/area to which feature belongs): @smarterclayton @erictune
Feature branch : https://github.com/kubernetes/kubernetes/tree/feature-workload-ga
Feature target (which target equals to which milestone):
- Beta release target (1.8)
- GA release target (1.9)

Create a new version in the apps group for the core workloads API.
When we advance the core workloads API (DaemonSet, Deployment, ReplicaSet, and StatefulSet) to v1, we want them to advance as a group and be (where possible) consistent. Prior to doing so, we would like to make any API incompatible changes. In particular we will

move DaemonSet to apps
remove the TemplateGeneration field of DaemonSet
change the StatefulSet ObservedGeneration from a pointer to an int for consistency.
remove the /rollback subresource of Deployment, or modify it such that the controller is not required to modify its own spec.
add a scale subresource for StatefulSet
review the API objects for consistency, and (where appropriate) make changes to bring them into alignment (modifying field names a necessary).
ensure that the defaults and validation are consistent and appropriate across all controllers.

We may find other incompatible changes that are required prior to promotion, and we would like to make them in this version, prior to releasing it. When the community is satisfied with the API surface, as contained in this version, and it is stable, we would like to promote all of the core workloads API to GA by moving the contained API to v1.

kinfeature siapps stagstable

Source

kow3ns

Most helpful comment

Now that workload controllers are in v1beta2, can this be closed?

mattfarina on 2 Oct 2017

👍2

All 19 comments

@kow3ns is this the final list of things being targeted for 1.8 or is there a meeting to discuss this ?

krmayankk on 20 Jul 2017

@krmayankk please read sig apps 1.8 planning doc. We discussed it in weekly sig-apps meeting https://docs.google.com/document/d/1LZLBGW2wRDwAfdBNHJjFfk9CFoyZPcIYGWU7R1PQ3ng/

janetkuo on 21 Jul 2017

👍1

Contacting @kow3ns to try and track down missing docs for 1.8 release.

jdumars on 15 Sep 2017

kow3ns on 15 Sep 2017

🎉1

Thanks so much @kow3ns

jdumars on 18 Sep 2017

Now that workload controllers are in v1beta2, can this be closed?

mattfarina on 2 Oct 2017

👍2

GA promotion plan from @kow3ns in #484:

We will promote the core workload controllers (DaemonSet, Deployment, ReplicaSet, and StatefulSet) to GA in the apps/v1 group version.
The previous implementations of these kinds in the apps/v1beta2 group will be deprecated. No kinds, in any group versions, are removed by this feature.
We intended to promote the apps/v1beta2 group in its entirety. We may make non-breaking changes with respect to selector immutability in the process.
We may deprecate or expand the use of Conditions across the API surface.

Also updated the first comment to include the plan to move to GA in v1.9

luxas on 7 Oct 2017

@luxas thanks

idvoretskyi on 10 Oct 2017

As raised in the linked issue we need to resolve whether daemonset provides at-most-1 pod semantics on nodes before we can promote it to GA. So putting a notice on the feature that we need to reach a decision on the implications before this can proceed.

smarterclayton on 12 Oct 2017

I'm not entirely sure this needs to be decided prior to GA, but if we think it does can we have this conversation at the next @kubernetes/sig-apps-misc meeting.

kow3ns on 13 Oct 2017

@smarterclayton @kow3ns should this happen at SIG Apps or SIG Scheduling? Since the issue has to do with how scheduling happens I would want to hash this out in SIG Scheduling. If I know when it's going to be discussed there I'd attend that meeting.

mattfarina on 13 Oct 2017

@mattfarina typically the controllers have been discussed in SIG Apps.

kow3ns on 14 Oct 2017

@kow3ns If I understand it right, the issue that needs to be discussed is kubernetes/community#977. I've been following that issue. We were thinking that SIG Scheduling needs to be involved due to the scheduling nature of the issue. That's the reason for the suggested change this time. Are we wrong?

mattfarina on 16 Oct 2017

@kow3ns I just read the discussion from the past several days. Things have moved since I last read an update. Since we have a SIG Apps meeting today we can see if there's time at the end to discuss if we have time. If not we can push it out to next week.

mattfarina on 16 Oct 2017

@kow3ns :wave: Please open a documentation PR and add a link to the tracking spreadsheet. Thanks in advance!