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

Improve oc cancel-build command #8509

Merged
merged 1 commit into from
May 2, 2016

Conversation

mfojtik
Copy link
Contributor

@mfojtik mfojtik commented Apr 14, 2016

This is rework of the oc cancel-build command, following the 'options' style @smarterclayton introduced for start-build and other commands already.

It also adds more functions and control over cancelling builds, following this PR: #8453

More specifically:

  • You can now cancel multiple builds:

oc cancel-build ruby-build-1 ruby-build-2 ...

  • You can now cancel all (new, pending, running) builds created from build config:

oc cancel-build bc/ruby-build

  • And you can also select what builds you want to cancel:

oc cancel-build bc/ruby-build --state=new

The last example is basically a command that will cleanup the build queue, allowing the next created build to be first executed (@bparees).

@smarterclayton PTAL.

@mfojtik
Copy link
Contributor Author

mfojtik commented Apr 14, 2016

[test]

// BuildConfigBuilds return a list of builds for the given build config.
// Optionally you can specify a filter function to select only builds that
// matches your criteria.
func BuildConfigBuilds(c client.BuildInterface, name string, filterFunc buildFilter) (*buildapi.BuildList, error) {
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 borrowed from serial builds PR and will be re-used there :-)

@mfojtik mfojtik force-pushed the cancel-build branch 2 times, most recently from 62cd88d to 474a27e Compare April 14, 2016 10:29
@jhadvig
Copy link
Member

jhadvig commented Apr 14, 2016

@mfojtik 👍
@jwforres might by worth to think about batch build cancellation in the /builds page, with some checkbox logic

@jwforres
Copy link
Member

Yeah we have been thinking about batch delete as well.
On Apr 14, 2016 6:32 AM, "Jakub Hadvig" notifications@github.com wrote:

@mfojtik https://github.com/mfojtik [image: 👍]
@jwforres https://github.com/jwforres might by worth to think about
batch build cancellation in the /builds page, with some checkbox logic


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#8509 (comment)

@deads2k
Copy link
Contributor

deads2k commented Apr 14, 2016

Why would I have a --from instead of accepting the resource/name format like every other command making my choice based on that information?

@Kargakis

@mfojtik
Copy link
Contributor Author

mfojtik commented Apr 14, 2016

@deads2k I think it will make it harder for users to support that format, think of:

oc cancel-build bc/foo build/bar-1 foobar-1 --state=new

What will this do? Cancel all builds created from bc/foo, then cancel build/bar-1 and then cancel foobar-1 that might be BC or build?...

Also buildConfig is not a build and the command is cancel-build, not cancel build config.

@bparees
Copy link
Contributor

bparees commented Apr 14, 2016

This is related to #5193

Note that this is proposing slightly different behavior than described in the issue (this PR would cancel all builds for a BC, whereas in the issue we discussed only canceling if there's just a single build running for the BC). I think what's proposed here is ok/better though (behavior wise. i agree with @deads2k that the syntax should be more like cancel-build bc/foo)

@liggitt
Copy link
Contributor

liggitt commented Apr 14, 2016

Agree on cancel-build bc/foo syntax. We do similar things for rsh dc/foo where we find the pod connected to the thing you asked to rsh into

@bparees
Copy link
Contributor

bparees commented Apr 14, 2016

What will this do? Cancel all builds created from bc/foo, then cancel build/bar-1 and then cancel foobar-1 that might be BC or build?...

for backwards compatibility, if no resource type is specified, you must assume it's a build. just like "oc logs" assumes you provided a pod name.

@mfojtik
Copy link
Contributor Author

mfojtik commented Apr 14, 2016

@liggitt @bparees does oc cancel-**build** buildconfig/foo sounds right to you?

@bparees
Copy link
Contributor

bparees commented Apr 14, 2016

@mfojtik it's not ideal, but it doesn't sound totally wrong. after all, "oc start-build" takes a BC....

@mfojtik
Copy link
Contributor Author

mfojtik commented Apr 14, 2016

@bparees I see, actually I looked on start-build and it is accepting both as well :-) OK, I'm surrendering :)

@liggitt
Copy link
Contributor

liggitt commented Apr 14, 2016

Take the thing they gave you and find a build logically connected to it you can cancel. Makes sense to me.

@mfojtik mfojtik force-pushed the cancel-build branch 2 times, most recently from ec20874 to 81dbcf5 Compare April 14, 2016 13:14
@mfojtik
Copy link
Contributor Author

mfojtik commented Apr 14, 2016

@liggitt @bparees @deads2k updated, I like it more now :)

@0xmichalis
Copy link
Contributor

We do similar things for rsh dc/foo where we find the pod connected to the thing you asked to rsh into

Not yet, but in progress. #8279

@mfojtik mfojtik force-pushed the cancel-build branch 3 times, most recently from d4bff9d to 35e2947 Compare April 15, 2016 09:46
@mfojtik
Copy link
Contributor Author

mfojtik commented Apr 15, 2016

[test] seems like a flake in integration (failed to pull image)

@mfojtik
Copy link
Contributor Author

mfojtik commented Apr 15, 2016

@Kargakis @bparees can I have review pls? :-)

"github.com/openshift/origin/pkg/cmd/util/clientcmd"
)

const (
cancelBuildLong = `
Cancels a pending or running build
Cancels a pending, running or new builds
Copy link
Contributor

Choose a reason for hiding this comment

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

s/builds/build/

@0xmichalis
Copy link
Contributor

What will this do? Cancel all builds created from bc/foo,

I thought we would support canceling the latest but cancelling all of the builds for that bc also makes sense.

then cancel build/bar-1 and then cancel foobar-1 that might be BC or build?...

cancel-build supports builds currently so we would continue to resolve single arguments to builds.

if err != nil {
return err
if len(o.State) > 0 && !isStateCancellable(o.State) {
return kcmdutil.UsageError(cmd, "The '--state' flag has invalid value. Must be 'new', 'pending' or 'running'")
Copy link
Contributor

Choose a reason for hiding this comment

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

oxford comma

@smarterclayton
Copy link
Contributor

I'm provisionally ok with the experience you describe, but given deployments has a bunch of stuff recently just want to be sure.

@0xmichalis
Copy link
Contributor

Cancelling all cancelable builds for a bc makes sense to me. We cannot have the same experience in deployments because there should always be one cancelable deployment. But even in the case there are more than one active deployments (can happen in the upstream controller), we should be able to cancel them all at once. Either way, multiple deployments means all but the latest are rolling out their pods to the latest.

@mfojtik
Copy link
Contributor Author

mfojtik commented Apr 27, 2016

@bparees @smarterclayton @Kargakis fixed test, I think we are good to merge after tests pass.

@mfojtik
Copy link
Contributor Author

mfojtik commented Apr 27, 2016

@smarterclayton is there anything we can do with travis flakes on import ordering? maybe disable the check for now till we fix it? :)

@mfojtik
Copy link
Contributor Author

mfojtik commented Apr 27, 2016

[test]

@smarterclayton
Copy link
Contributor

We probably need to just fix it.

On Wed, Apr 27, 2016 at 5:10 AM, Michal Fojtik notifications@github.com
wrote:

@smarterclayton https://github.com/smarterclayton is there anything we
can do with travis flakes on import ordering? maybe disable the check for
now till we fix it? :)


You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
#8509 (comment)

@mfojtik
Copy link
Contributor Author

mfojtik commented Apr 28, 2016

seems like jenkins hate me today... [test]

@mfojtik
Copy link
Contributor Author

mfojtik commented Apr 28, 2016

[test]

(Error: image cache/mysql:pullthrough not found flake)

@mfojtik
Copy link
Contributor Author

mfojtik commented Apr 28, 2016

[test] ?

@mfojtik
Copy link
Contributor Author

mfojtik commented Apr 29, 2016

[test]

(integration flake)

@mfojtik
Copy link
Contributor Author

mfojtik commented May 2, 2016

@smarterclayton @bparees any final comments?

@mfojtik
Copy link
Contributor Author

mfojtik commented May 2, 2016

(actually I would prefer to merge the run policy PR first)

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

Evaluated for origin test up to a37693a

@bparees
Copy link
Contributor

bparees commented May 2, 2016

@mfojtik still lgtm.

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

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

@mfojtik
Copy link
Contributor Author

mfojtik commented May 2, 2016

[merge]

@openshift-bot
Copy link
Contributor

openshift-bot commented May 2, 2016

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/merge_pull_requests_origin/5784/) (Image: devenv-rhel7_4078)

@openshift-bot
Copy link
Contributor

Evaluated for origin merge up to a37693a

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.

9 participants