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

Refactor Build Controller to use Informers #14289

Merged
merged 1 commit into from
Jun 15, 2017

Conversation

csrwng
Copy link
Contributor

@csrwng csrwng commented May 23, 2017

Collapses the build and build pod controller into a single controller using informers

@csrwng
Copy link
Contributor Author

csrwng commented May 23, 2017

[test]

@csrwng
Copy link
Contributor Author

csrwng commented May 23, 2017

@bparees I'm still working on unit tests, but wanted to get this up sooner than later; ptal

Copy link
Contributor

@bparees bparees left a comment

Choose a reason for hiding this comment

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

my main concern is around the possibility of re-introducing races when updating the build status reason/message fields.

eventBroadcaster.StartRecordingToSink(&v1core.EventSinkImpl{Interface: v1core.New(params.KubeClientExternal.Core().RESTClient()).Events("")})

buildListerUpdater := buildclient.NewOSClientBuildClient(params.OpenshiftClient)
buildDeleter := buildclient.NewBuildDeleter(params.OpenshiftClient)
Copy link
Contributor

Choose a reason for hiding this comment

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

is there a good reason that NewOSClientBuildClient{} doesn't include implement Delete itself, rather than us having a separate buildDeleter{}?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Nope, we can certainly change that

}

<-stopCh
glog.Infof("Shutting down build pod controller")
Copy link
Contributor

Choose a reason for hiding this comment

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

build controller.

return nil
}

func shouldIgnore(build *buildapi.Build) bool {
Copy link
Contributor

Choose a reason for hiding this comment

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

godoc

return update, nil
}

func (bc *BuildController) handleNewBuild(build *buildapi.Build, willBeDropped bool, pod *kapi.Pod, podErr error) (*buildUpdate, error) {
Copy link
Contributor

Choose a reason for hiding this comment

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

godoc

return bc.createBuildPod(build)
}

func (bc *BuildController) createPodSpec(originalBuild *buildapi.Build, ref string) (*kapi.Pod, error) {
Copy link
Contributor

Choose a reason for hiding this comment

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

godoc

@@ -0,0 +1,46 @@
package build
Copy link
Contributor

Choose a reason for hiding this comment

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

filename: podcreationstrategy.go

otherwise i'd expect this to create builds, given the package it's in.

case build.Spec.Strategy.CustomStrategy != nil:
pod, err = f.customBuildStrategy.CreateBuildPod(build)
case build.Spec.Strategy.JenkinsPipelineStrategy != nil:
return nil, nil
Copy link
Contributor

Choose a reason for hiding this comment

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

it should be an error if we get here.

rbac.NewRule("get").Groups(imageGroup, legacyImageGroup).Resources("imagestreams").RuleOrDie(),
rbac.NewRule("get", "list", "create", "delete").Groups(kapiGroup).Resources("pods").RuleOrDie(),
rbac.NewRule("get", "list").Groups(imageGroup, legacyImageGroup).Resources("imagestreams").RuleOrDie(),
rbac.NewRule("get", "list").Groups(imageGroup, legacyImageGroup).Resources("secrets").RuleOrDie(),
Copy link
Contributor

Choose a reason for hiding this comment

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

group looks wrong for secrets?

@@ -7,8 +7,7 @@ import (

builddefaults "github.com/openshift/origin/pkg/build/admission/defaults"
buildoverrides "github.com/openshift/origin/pkg/build/admission/overrides"
buildclient "github.com/openshift/origin/pkg/build/client"
buildcontrollerfactory "github.com/openshift/origin/pkg/build/controller/factory"
buildcontroller "github.com/openshift/origin/pkg/build/controller/build"
Copy link
Contributor

Choose a reason for hiding this comment

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

is there a compelling reason not to fold this whole file into build_controller.go?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

this is part of @deads2k's recent change to the build controller. I believe this is a pattern we want to following going forward?

Copy link
Contributor

Choose a reason for hiding this comment

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

hm. it looks weird to me, but i'll ignore it for now.

Copy link
Contributor

Choose a reason for hiding this comment

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

Eventually we want to push this wiring down into sub-repos, but it wasn't a primary objective and we don't have a solid interface yet. Right now, the it would create really strange interdependencies.

@@ -754,7 +754,6 @@ func startControllers(oc *origin.MasterConfig, kc *kubernetes.MasterConfig) erro

// no special order
if configapi.IsBuildEnabled(&oc.Options) {
oc.RunBuildPodController()
Copy link
Contributor

Choose a reason for hiding this comment

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

i'd like to understand why this block is special, instead of handling the buildconfigchangecontroller in the for loop above.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

the loop above is for the new style of controllers (where they live in an array and initialized via a function in that array) (ala kube). We have not yet changed the config change controller to initialize in that way.

Copy link
Contributor

Choose a reason for hiding this comment

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

got it.

@csrwng
Copy link
Contributor Author

csrwng commented May 24, 2017

@bparees please take a look at the last commit. I addressed your comments and changed the way we handle details updates from the pod to use annotations. I really don't like the potential for races on the build phase/reason/message. I'd rather have the build controller be the only one that can update those.

Copy link
Contributor

@bparees bparees left a comment

Choose a reason for hiding this comment

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

couple nits but i like it and thanks for the speedy turnaround!


return update, nil
}

// handleNewBuild will check whether policy allows running the new build and if so, creates a pod
// for the build and returns and update to move it to the Pending phase
Copy link
Contributor

Choose a reason for hiding this comment

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

s/and/an/

}
if _, ok := build.Annotations[buildapi.BuildPodRequestedMessageAnnotation]; ok {
update.setMessage(build.Annotations[buildapi.BuildPodRequestedMessageAnnotation])
}
Copy link
Contributor

Choose a reason for hiding this comment

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

cool, i like this!


newBuild.Annotations[api.BuildPodRequestedPhaseAnnotation] = string(phase)
newBuild.Annotations[api.BuildPodRequestedReasonAnnotation] = string(reason)
newBuild.Annotations[api.BuildPodRequestedMessageAnnotation] = message
Copy link
Contributor

Choose a reason for hiding this comment

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

godoc needs updating w/ this behavior change.

@csrwng csrwng force-pushed the build_controller branch 4 times, most recently from a65f31b to 46ed2ab Compare May 24, 2017 16:45
@csrwng
Copy link
Contributor Author

csrwng commented May 24, 2017

Updates made, new annotation constants will require @openshift/api-review

@csrwng csrwng force-pushed the build_controller branch 2 times, most recently from d03414f to 8b2a09b Compare May 25, 2017 00:49
@csrwng csrwng changed the title [WIP] Refactor Build Controller to use Informers Refactor Build Controller to use Informers May 25, 2017
@csrwng
Copy link
Contributor Author

csrwng commented May 25, 2017

[test]

@csrwng
Copy link
Contributor Author

csrwng commented May 25, 2017

@bparees still don't have a clean test. Latest run has one extended test failing...
Optimized image builds should succeed as an admin [Conformance]
there's also an integration build that failed, but succeeded in previous runs ... more like a flake
TestProjectLifecycle

@openshift-bot openshift-bot added the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 25, 2017
@openshift-bot openshift-bot removed the needs-rebase Indicates a PR cannot be merged because it has merge conflicts with HEAD. label May 25, 2017
@csrwng
Copy link
Contributor Author

csrwng commented May 25, 2017

[testextended][extended:core(builds)]

@csrwng
Copy link
Contributor Author

csrwng commented May 26, 2017

Flakes #14368 #13980

@csrwng
Copy link
Contributor Author

csrwng commented May 26, 2017

Just realized I didn't tag the entire team... apologies. @openshift/devex ptal

@csrwng
Copy link
Contributor Author

csrwng commented Jun 5, 2017

@openshift/api-review bump

@bparees
Copy link
Contributor

bparees commented Jun 11, 2017

add the code comment and i think it's ready for merge. feel free to put the tag on yourself after you add the comment.

@csrwng
Copy link
Contributor Author

csrwng commented Jun 11, 2017

Removed special case for pending transition
[merge][severity:blocker]

t := true
pod.OwnerReferences = []metav1.OwnerReference{
{
APIVersion: "v1",
Copy link
Contributor

Choose a reason for hiding this comment

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

must be build.openshift.io/v1
`

Copy link
Contributor

Choose a reason for hiding this comment

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

t := true
pod.OwnerReferences = []metav1.OwnerReference{
{
APIVersion: "v1",
Copy link
Contributor

Choose a reason for hiding this comment

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

@mfojtik noted that this needs to be buildapiv1.SchemeGroupVersion

@csrwng
Copy link
Contributor Author

csrwng commented Jun 12, 2017

Thx @mfojtik and @bparees. Code updated.

@csrwng csrwng force-pushed the build_controller branch 2 times, most recently from 6036be8 to 71846a9 Compare June 12, 2017 15:07
@csrwng
Copy link
Contributor Author

csrwng commented Jun 12, 2017

rebased and fixed compile error with ImageStream informer

@csrwng
Copy link
Contributor Author

csrwng commented Jun 12, 2017

Fixed unit test to use generated informer for ImageStreams

@csrwng
Copy link
Contributor Author

csrwng commented Jun 13, 2017

Flake #13984 on extended test

@csrwng
Copy link
Contributor Author

csrwng commented Jun 13, 2017

[testextended][extended:core(builds)]

@openshift-bot
Copy link
Contributor

Evaluated for origin testextended up to 3091d6a

@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/testextended FAILURE (https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin_extended/613/) (Base Commit: 0ab5ccf) (Extended Tests: core(builds))

@smarterclayton
Copy link
Contributor

[test]

@openshift-bot
Copy link
Contributor

Evaluated for origin test up to 3091d6a

@smarterclayton
Copy link
Contributor

[merge]

@openshift-bot
Copy link
Contributor

Evaluated for origin merge up to 3091d6a

@openshift-bot
Copy link
Contributor

openshift-bot commented Jun 15, 2017

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_request_origin/1003/) (Base Commit: eb50c84) (Extended Tests: blocker) (Image: devenv-rhel7_6361)

@openshift-bot
Copy link
Contributor

continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_request_origin/2254/) (Base Commit: 811a267)

@openshift-bot openshift-bot merged commit 7ddec43 into openshift:master Jun 15, 2017
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.

7 participants