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.

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

deploy: enqueue configs on pod events #9953

Merged
merged 1 commit into from
Jul 24, 2016
Merged

deploy: enqueue configs on pod events #9953

merged 1 commit into from
Jul 24, 2016

Conversation

0xmichalis
Copy link
Contributor

Split from #9799

This commit is valuable on its own since we get a synced config status at all times.

@mfojtik @smarterclayton

@0xmichalis
Copy link
Contributor Author

cc: @deads2k

@deads2k
Copy link
Contributor

deads2k commented Jul 20, 2016

We're updating DC status based on this somewhere?

@0xmichalis
Copy link
Contributor Author

We're updating DC status based on this somewhere?

We now have dc.Status.Replicas (all running pods from all replication controllers), dc.Status.UpdatedReplicas (all pods from the latest replication controller), dc.Status.AvailableReplicas (all available pods), and dc.Status.UnavailableReplicas and the deployment config controller is updating those.

@deads2k
Copy link
Contributor

deads2k commented Jul 20, 2016

Seems like this code won't play friendly with pod adoption by RCs owned by the DC. You should choose which information is authoritative: pods or RCs. I think that it should be RCs.

@0xmichalis
Copy link
Contributor Author

Isn't there work happening upstream to disallow overlapping selectors?

On Wed, Jul 20, 2016 at 7:10 PM, David Eads notifications@github.com
wrote:

Seems like this code won't play friendly with pod adoption by RCs owned by
the DC. You should choose which information is authoritative: pods or RCs.
I think that it should be RCs.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#9953 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADuFf07c4l3qRMFEmKLmPnW-1cWPXcJyks5qXlaUgaJpZM4JQxVB
.

@deads2k
Copy link
Contributor

deads2k commented Jul 21, 2016

Isn't there work happening upstream to disallow overlapping selectors?

Adoption isn't the same as overlapping. Adoption is just picking up pods that match your selection criteria, not necessarily pods that are created by a different RC.

@0xmichalis
Copy link
Contributor Author

Don't you want your newly adopted pods to be reflected as quickly as
possible in your DC status?

On Thu, Jul 21, 2016 at 1:49 PM, David Eads notifications@github.com
wrote:

Isn't there work happening upstream to disallow overlapping selectors?

Adoption isn't the same as overlapping. Adoption is just picking up pods
that match your selection criteria, not necessarily pods that are created
by a different RC.


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

@deads2k
Copy link
Contributor

deads2k commented Jul 22, 2016

Don't you want your newly adopted pods to be reflected as quickly as
possible in your DC status?

I think that I want to have one source of truth for that information. What would you do if they disagreed? Sum of RCs gives you 10, sum of pods gives you 11.

@0xmichalis
Copy link
Contributor Author

I think that I want to have one source of truth for that information. What would you do if they disagreed? Sum of RCs gives you 10, sum of pods gives you 11.

The thing is that RCs lack AvailableReplicas so we can only get that info from pods or unless kubernetes/kubernetes#28381 is fixed upstream.

@deads2k
Copy link
Contributor

deads2k commented Jul 22, 2016

The thing is that RCs lack AvailableReplicas so we can only get that info from pods or unless kubernetes/kubernetes#28381 is fixed upstream.

Ok, can't say I'm excited about it. I'd like to come back and revisit this next release.

[merge]

@openshift-bot
Copy link
Contributor

[Test]ing while waiting on the merge queue

@openshift-bot
Copy link
Contributor

Evaluated for origin test up to a227c50

@0xmichalis
Copy link
Contributor Author

Ok, can't say I'm excited about it. I'd like to come back and revisit this next release.

In my TODO list to fix the upstream issue

@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/test FAILURE (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/6729/)

@0xmichalis
Copy link
Contributor Author

secrets [merge]

@0xmichalis
Copy link
Contributor Author

yum [merge]

@0xmichalis
Copy link
Contributor Author

#10002 [merge]

@openshift-bot
Copy link
Contributor

openshift-bot commented Jul 23, 2016

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/6786/) (Image: devenv-rhel7_4653)

@smarterclayton
Copy link
Contributor

[merge] #9490

On Sat, Jul 23, 2016 at 8:25 AM, OpenShift Bot notifications@github.com
wrote:

continuous-integration/openshift-jenkins/merge FAILURE (
https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/6774/)


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

@openshift-bot
Copy link
Contributor

Evaluated for origin merge up to a227c50

@openshift-bot openshift-bot merged commit 2b36721 into openshift:master Jul 24, 2016
@0xmichalis 0xmichalis deleted the requeue-on-pod-events branch July 24, 2016 10:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants