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.

Sign up for GitHub

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

Jump to bottom

Move node affinity from annotations to api fields #35518

Closed
rrati opened this issue Oct 25, 2016 · 6 comments
Closed

Move node affinity from annotations to api fields #35518

rrati opened this issue Oct 25, 2016 · 6 comments
Assignees
@rrati
Labels
sig/scheduling Categorizes an issue or PR as relevant to SIG Scheduling.
Milestone
v1.6

Comments

@rrati
Copy link

rrati commented Oct 25, 2016

Moving the node affinity implementation out of annotations and into api fields, and from alpha->beta, should be done piecemeal to ensure functionality and sanity. I would propose a process first porting the implementation/tests before attempting to promote from alpha->beta. Porting would entail:

  1. Remove the node affinity implementation in annotations and do not bother with backwards compatibility. Worrying about backwards compatibility for an alpha feature will needlessly complicate the implementation.
  2. Implement node affinity in api fields.
  3. Port tests.

Once functionality has reached parity with the annotation implement, promote from alpha->beta.

@kubernetes/sig-scheduling
@timothysc timothysc added the sig/scheduling Categorizes an issue or PR as relevant to SIG Scheduling. label Oct 25, 2016
@timothysc
Copy link
Member

@davidopp This morning @rrati and I conversed about doing a 2-part conversion to leverage #34508 , and aim for alpha-beta in 1.6.

Thoughts?

@timothysc timothysc added this to the next-candidate milestone Oct 25, 2016
@aveshagarwal aveshagarwal mentioned this issue Oct 25, 2016
Closed
12 tasks
@davidopp
Copy link
Member

Can we move this discussion to #25319 ?

BTW I didn't fully understand your proposal. It sounds like you are proposing to remove the alpha annotations before any replacement is available. If so, that seems bad. I'm also unsure about not giving people one version where we support both alpha and beta, so that they have a chance to migrate.

@rrati
Copy link
Author

rrati commented Oct 26, 2016

I'm proposing a 2 step process for the migration. Step 1 is to change from annotations to api fields but keep the feature in alpha. Once we have verified equivalent functionality using api fields that existed using annotations then we can promote from alpha->beta.

I'm also suggesting we not attempt to support/maintain compatibility for the annotations version. Part of step 1 should be removing the annotations implementation completely. It's an alpha feature and annotations have issues so lets rip off the band aid. Trying to support both would, imo, be needlessly complicated.

@rrati rrati mentioned this issue Oct 26, 2016
Open
9 tasks
@aveshagarwal aveshagarwal mentioned this issue Oct 27, 2016
Closed
@davidopp
Copy link
Member

Just to make sure I understand what you're proposing:

  1. Change from alpha annotation to alpha API field
  2. Do a minor release
  3. Change from alpha API field to beta API field
  4. Do a minor release

Would you break compatibility twice in this scheme? (Break the people using alpha annotations when you do step 1, and break the people using alpha API field when you do step 3.) It would be better to only break people once.

It's still not clear to me why you are concern about going directly from alpha annotation to beta API field?

@rrati
Copy link
Author

rrati commented Oct 31, 2016

I am trying to reduce the number of moving parts. Rather than convert from annotation to api fields and add changes needed to get from alpha->beta, I'm suggesting to separate the two steps. It doesn't necessarily mean each step results in a release with those changes. I'm just suggesting the work be done in 2 steps (ie 2 separate commits or sets of commits).

@davidopp
Copy link
Member

Ah OK, yes, that seems reasonable. I thought you wanted separate releases.

rrati pushed a commit to rrati/kubernetes that referenced this issue Nov 30, 2016
[scheduling] Moved node affinity from annotations to api fields. kube…
9511a4f 
…rnetes#35518
rrati pushed a commit to rrati/kubernetes that referenced this issue Nov 30, 2016
[scheduling] Auto-generated file updates from moving node affinity from
c7701c9 
annotations to api fields. kubernetes#35518
rrati pushed a commit to rrati/kubernetes that referenced this issue Nov 30, 2016
Moved node affinity from annotations to api fields. kubernetes#35518
2379bc2
@rrati rrati mentioned this issue Nov 30, 2016
Merged
@timothysc timothysc modified the milestones: v1.6, next-candidate Dec 9, 2016
rrati pushed a commit to rrati/kubernetes that referenced this issue Dec 13, 2016
[scheduling] Moved node affinity from annotations to api fields. kube…
1b47ff9 
…rnetes#35518
rrati pushed a commit to rrati/kubernetes that referenced this issue Dec 13, 2016
[scheduling] Auto-generated file updates from moving node affinity from
e93fc40 
annotations to api fields. kubernetes#35518
rrati pushed a commit to rrati/kubernetes that referenced this issue Dec 15, 2016
[scheduling] Moved node affinity from annotations to api fields. kube…
83365d6 
…rnetes#35518
rrati pushed a commit to rrati/kubernetes that referenced this issue Dec 15, 2016
[scheduling] Auto-generated file updates from moving node affinity from
170a439 
annotations to api fields. kubernetes#35518
rrati pushed a commit to rrati/kubernetes that referenced this issue Dec 16, 2016
[scheduling] Moved node affinity from annotations to api fields. kube…
91931c1 
…rnetes#35518
rrati pushed a commit to rrati/kubernetes that referenced this issue Dec 16, 2016
[scheduling] Auto-generated file updates from moving node affinity from
11c577f 
annotations to api fields. kubernetes#35518
k8s-github-robot pushed a commit that referenced this issue Dec 16, 2016
Merge pull request #37299 from rrati/node-affinity-api-fields
9bc98e2 
Automatic merge from submit-queue (batch tested with PRs 38730, 37299)

[scheduling] Moved node affinity from annotations to api fields. #35518

Converted node affinity from annotations to api fields

Fixes: #35518 
Related: #25319
Related: #34508

**Release note**:
```release-note
Node affinity has moved from annotations to api fields in the pod spec.  Node affinity that is defined in the annotations will be ignored.
```
berryjam pushed a commit to berryjam/kubernetes that referenced this issue Aug 18, 2017
@berryjamcoding
[scheduling] Moved node affinity from annotations to api fields. kube…
5f6ad35 
…rnetes#35518
berryjam pushed a commit to berryjam/kubernetes that referenced this issue Aug 18, 2017
@berryjamcoding
[scheduling] Auto-generated file updates from moving node affinity from
b4e8469 
annotations to api fields. kubernetes#35518
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@rrati rrati

Labels
sig/scheduling Categorizes an issue or PR as relevant to SIG Scheduling.
Projects
None yet
Milestone
v1.6
Development

No branches or pull requests
4 participants
@rrati @timothysc @davidopp @k8s-github-robot