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

Ensure client can delete a buildconfig with no associated builds, eve… #9657

Merged
merged 1 commit into from
Jul 8, 2016
Merged

Ensure client can delete a buildconfig with no associated builds, eve… #9657

merged 1 commit into from
Jul 8, 2016

Conversation

jupierce
Copy link
Contributor

@jupierce jupierce commented Jun 30, 2016

@bparees Fixes #8655

@bparees
Copy link
Contributor

bparees commented Jun 30, 2016

@jupierce if you put "fixes [issue link]" in your PR summary, github will auto-close the issue when the PR merges.

@bparees
Copy link
Contributor

bparees commented Jun 30, 2016

(there are some other syntaxes that work, but i think think "issue XXX" is one of them)

builds, err = reaper.oc.Builds(namespace).List(kapi.ListOptions{LabelSelector: buildutil.BuildConfigSelector(name)})
if err != nil {
return err
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you also need to check the deprecated label.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and, due to the truncation issue, you need to filter the results using the annotation value, like the rest of the code does, to determine if a build is really related to the buildconfig.

@bparees
Copy link
Contributor

bparees commented Jun 30, 2016

There is a bigger issue in this code that i'd like @csrwng to weigh in on... now that we are truncating the buildconfig label value, we can't just do straight selection using the buildconfig name, we also need to truncate the buildconfig name first, then filter the selection results using the annotation value.

@csrwng i thought you updated all uses of the buildconfig label(s), did this just get missed or is there a reason this didn't need to change that i'm not seeing? It looks like the code was updated (since it uses the annotation) but it's still doing the label selection using the full name. Does the label selection process itself truncate the value?

@bparees
Copy link
Contributor

bparees commented Jun 30, 2016

might be worth adding a test as well that ensures we delete only the correct set of builds when someone has created two buildconfigs with very long names, a set of builds associated with each, and then deletes one of those buildconfigs.

// Add deletion pending annotation to the build config
err := unversioned.RetryOnConflict(unversioned.DefaultRetry, func() error {
bc, err := reaper.oc.BuildConfigs(namespace).Get(name)
if kerrors.IsNotFound(err) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could not determine a reason for the special handling of not found. Any non-conflict error returned to RetryOnConflict appears to terminate retries immediately. The only effect of manually creating a NewNotFound seemed to be removing the "s" from the ultimate error message:
Error from server: buildconfigs "test" not found

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think there was a point in time at which we would still attempt to delete builds that were associated with the buildconfig, even if we couldn't find the buildconfig.

that behavior was recently changed such that we just error out if we can't find the buildconfig and do nothing further. So yeah, this logic is probably no longer needed.

@jupierce
Copy link
Contributor Author

jupierce commented Jul 1, 2016

@bparees Looks like the build config selector is truncated automatically during its instantiation.
https://github.com/openshift/origin/blob/master/pkg/build/util/util.go#L106-L108
https://github.com/openshift/origin/blob/master/pkg/build/api/util.go#L57-L62
Verified longs names are not problematic in my dev environment, but definitely agree that a test should be added.

@jupierce
Copy link
Contributor Author

jupierce commented Jul 5, 2016

The submitted implementation does not attempt to address the race condition between deletion of a build configuration by client A and triggering of a new build by a competing client B. Because of etcd-io/etcd#741 and the fact that OpenShift does not use quorum reads, we would need to redesign the buildconfig deletion process to use a controller/reconciliation loop to ensure deterministic cascading deletions.

If we are OK with the race window existing, we could requery associated builds after pausing the build config to reduce the window further (with a slight performance impact).

@bparees
Copy link
Contributor

bparees commented Jul 5, 2016

lgtm, can you add the test for long buildconfig names?

@bparees
Copy link
Contributor

bparees commented Jul 5, 2016

(i'm ok w/ the race window, given that we can't eliminate it completely i don't know if it's worth jumping through hoops to make it a little smaller)

@jupierce
Copy link
Contributor Author

jupierce commented Jul 6, 2016

@bparees Added test case for your perusal.

}
}
},
"output": {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you can make this buildconfig execute faster by leaving out the output so it doesn't have to push the resulting image anywhere.

@jupierce
Copy link
Contributor Author

jupierce commented Jul 7, 2016

[test]

expected: []ktestclient.Action{
ktestclient.NewGetAction("buildconfigs", "default", configName),
ktestclient.NewUpdateAction("buildconfigs", "default", makeBuildConfig(0, true)),
// Since tehre are no builds associated with this build config, do not expect an update
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sigh.. I'm coming from an IDE with spellcheck.

@bparees
Copy link
Contributor

bparees commented Jul 7, 2016

[testextended][extended:core(extremely long build/bc names are not problematic)]

@openshift-bot
Copy link
Contributor

Evaluated for origin test up to 22d2378

@openshift-bot
Copy link
Contributor

Evaluated for origin testextended up to 22d2378

@openshift-bot
Copy link
Contributor

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

@bparees
Copy link
Contributor

bparees commented Jul 7, 2016

@jupierce i deleted your builds and images test tags so we can see if we can get a clean run just on your new extended test.

@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/testextended SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin_extended/297/) (Extended Tests: core(extremely long build/bc names are not problematic))

@bparees
Copy link
Contributor

bparees commented Jul 7, 2016

lgtm
[merge]

@bparees
Copy link
Contributor

bparees commented Jul 7, 2016

known flake #9681
[merge]

@openshift-bot
Copy link
Contributor

openshift-bot commented Jul 7, 2016

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

@bparees
Copy link
Contributor

bparees commented Jul 8, 2016

flake #9444
[merge]

@openshift-bot
Copy link
Contributor

Evaluated for origin merge up to 22d2378

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.

3 participants