Add support for 'osc stop|label' from upstream #1944

0xmichalis · 2015-04-28T13:09:22Z

[vagrant@openshiftdev sample-app]$ osc label svc/mysql2 app=sql
NAME      LABELS    SELECTOR                            IP               PORT(S)
mysql2    app=sql   deploymentconfig=mysql,name=hello   172.30.228.100   41/TCP
[vagrant@openshiftdev sample-app]$ osc stop svc/mysql2
services/mysql2

cc: @smarterclayton @bparees (https://trello.com/c/XxiMNEHv/553-add-support-for-osc-stop-label-from-upstream-codefreeze)

smarterclayton · 2015-04-28T14:00:53Z

pkg/cmd/cli/cmd/wrappers.go

+	# Shut down all resources in the path/to/resources directory
+	$ %[1]s stop -f path/to/resources
+`
+	cmd.Long = fmt.Sprintf(longDesc, fullName)


Reaper needs to be implemented for DeploymentConfig

You can do that in a follow on pull, but I don't want to expose stop for osc until that works.

No problem, I'll work on it here.

@smarterclayton fyi after the latest change in stop code we can use osc stop as is since if the passed resource doesn't implement the Reaper, stop will fallback to delete (https://github.com/GoogleCloudPlatform/kubernetes/blob/e1256c08027748c4a0dc8078f1f8db5afb673923/pkg/kubectl/cmd/delete.go#L112).

Regarding the implementation, DC first has to support the Resizer and then the Reaper. How are we going to implement those since DC is OpenShift-specific resource and we need to make that change in Kubernetes?
https://github.com/GoogleCloudPlatform/kubernetes/blob/e1256c08027748c4a0dc8078f1f8db5afb673923/pkg/kubectl/stop.go#L51
https://github.com/GoogleCloudPlatform/kubernetes/blob/e1256c08027748c4a0dc8078f1f8db5afb673923/pkg/kubectl/resize.go#L92

Well, maybe I'm wrong about the resizer but still...

----- Original Message -----

+Examples:
+

Shut down foo.

$ %[1]s stop replicationcontroller foo

Stop pods and services with label name=myLabel.

$ %[1]s stop pods,services -l name=myLabel

Shut down the service defined in service.json

$ %[1]s stop -f service.json

Shut down all resources in the path/to/resources directory

$ %[1]s stop -f path/to/resources
+`

cmd.Long = fmt.Sprintf(longDesc, fullName)

Well, maybe I'm wrong about the resizer but still...

Resizer I believe has an abstraction as well that goes into the Factory. There are other issues with Resize though, which is that currently deployments aren't preserving resize and it's not clear whether the deployment configs value for replicas should be used. For now, Resizer resizing the current dcs/deployment would be most correct.

0xmichalis · 2015-04-30T08:37:00Z

Will hold on to this until the next Kube rebase. Then it can be merged w/o implementing the Reaper for dc.

0xmichalis · 2015-05-07T11:26:24Z

This still needs to implement the Reaper but for doing that dcs first have to implement the Resizer and then resizing down to zero is all this will take.

smarterclayton · 2015-05-07T13:16:32Z

For a DC, the resizer should find the most recent (highest deployment number) rc associated with that deployment, and apply resize to that deployment. Can you make that change?

On May 7, 2015, at 7:26 AM, Michail Kargakis [email protected] wrote:

This still needs to implement the Reaper but for doing that dcs first have to implement the Resizer and then resizing down to zero is all this will take.

—
Reply to this email directly or view it on GitHub.

0xmichalis · 2015-05-07T13:21:38Z

For a DC, the resizer should find the most recent (highest deployment number) rc associated with that deployment, and apply resize to that deployment. Can you make that change?

I will give it a go.

0xmichalis · 2015-05-14T14:11:47Z

I've updated this PR to work with the resizing PR. Merged both of them in a test branch and:

[vagrant@openshiftdev sample-app]$ osc get dc
NAME               TRIGGERS                    LATEST VERSION
php-55-centos7     ConfigChange, ImageChange   0
ruby-hello-world   ConfigChange, ImageChange   1

[vagrant@openshiftdev sample-app]$ osc resize dc ruby-hello-world --replicas=3
resized

[vagrant@openshiftdev sample-app]$ osc describe dc ruby-hello-world
Name:       ruby-hello-world
Created:    About an hour ago
Labels:     <none>
Latest Version: 1
Triggers:   Config, Image(ruby-hello-world@latest, auto=true)
Strategy:   Recreate
Template:
    Selector:   deploymentconfig=ruby-hello-world
    Replicas:   1
    Containers:
        NAME            IMAGE               ENV
        ruby-hello-world    library/ruby-hello-world:latest 
Deployment #1 (latest):
    Name:       ruby-hello-world-1
    Created:    about an hour ago
    Status:     Running
    Replicas:   3 current / 3 desired
    Selector:   deployment=ruby-hello-world-1,deploymentconfig=ruby-hello-world
    Labels:     deployment=ruby-hello-world-1,deploymentconfig=ruby-hello-world
    Pods Status:    3 Running / 0 Waiting / 0 Succeeded / 0 Failed
No events.

[vagrant@openshiftdev sample-app]$ osc get pods
POD                              IP        CONTAINER(S)       IMAGE(S)    HOST                           LABELS                                                            STATUS    CREATED            MESSAGE
deploy-ruby-hello-world-1wdk5w   1.2.3.4                                  openshiftdev.local/127.0.0.1   <none>                                                            Running   About an hour      
                                           deployment         testimage                                                                                                    Running   292.471209 years   
ruby-hello-world-1-3wuye         1.2.3.4                                  openshiftdev.local/127.0.0.1   deployment=ruby-hello-world-1,deploymentconfig=ruby-hello-world   Running   33 seconds         
                                           ruby-hello-world   testimage                                                                                                    Running   292.471209 years   
ruby-hello-world-1-oaj7s         1.2.3.4                                  openshiftdev.local/127.0.0.1   deployment=ruby-hello-world-1,deploymentconfig=ruby-hello-world   Running   33 seconds         
                                           ruby-hello-world   testimage                                                                                                    Running   292.471209 years   
ruby-hello-world-1-pkr4z         1.2.3.4                                  openshiftdev.local/127.0.0.1   deployment=ruby-hello-world-1,deploymentconfig=ruby-hello-world   Running   33 seconds         
                                           ruby-hello-world   testimage                                                                                                    Running   292.471209 years   

[vagrant@openshiftdev sample-app]$ osc stop dc ruby-hello-world
[vagrant@openshiftdev sample-app]$ osc get pods
POD                              IP        CONTAINER(S)   IMAGE(S)    HOST                           LABELS    STATUS    CREATED            MESSAGE
deploy-ruby-hello-world-1wdk5w   1.2.3.4                              openshiftdev.local/127.0.0.1   <none>    Running   About an hour      
                                           deployment     testimage                                            Running   292.471209 years   

[vagrant@openshiftdev sample-app]$ osc describe dc ruby-hello-world
Name:       ruby-hello-world
Created:    About an hour ago
Labels:     <none>
Latest Version: 1
Triggers:   Config, Image(ruby-hello-world@latest, auto=true)
Strategy:   Recreate
Template:
    Selector:   deploymentconfig=ruby-hello-world
    Replicas:   1
    Containers:
        NAME            IMAGE               ENV
        ruby-hello-world    library/ruby-hello-world:latest 
Deployment #1 (latest):
    Name:       ruby-hello-world-1
    Created:    about an hour ago
    Status:     Running
    Replicas:   0 current / 0 desired
    Selector:   deployment=ruby-hello-world-1,deploymentconfig=ruby-hello-world
    Labels:     deployment=ruby-hello-world-1,deploymentconfig=ruby-hello-world
    Pods Status:    0 Running / 0 Waiting / 0 Succeeded / 0 Failed
No events.

smarterclayton · 2015-05-14T14:14:38Z

pkg/cmd/cli/cmd/wrappers.go

@@ -13,6 +13,64 @@ import (
 )

 const (
+	stop_long = `Gracefully shut down a resource by id or filename.


stopLong and stopExample

0xmichalis · 2015-05-14T14:32:49Z

I didn't actually delete the dc. Fixed.

smarterclayton · 2015-05-14T14:41:49Z

hack/test-cmd.sh

+[ $(osc describe bc/ruby-helloworld-sample | grep acustom=label) ]
+echo "label: ok"
+osc stop svc/ruby-helloworld-sample
+osc delete all -l app=dockerbuild


Verify the dc was deleted in your test case

Was about to do that

smarterclayton · 2015-05-14T20:19:34Z

Travis is failing

0xmichalis · 2015-05-15T12:32:51Z

[test]

openshift-bot · 2015-05-15T12:35:38Z

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

0xmichalis · 2015-05-15T14:25:37Z

re[test]

smarterclayton · 2015-05-16T14:32:55Z

Failing due to

deploymentConfigs/database
replicationControllers "database-1" not found
!!! Error in hack/test-cmd.sh:402
  'osc get rc/database-1' exited with status 1
Call stack:
  1: hack/test-cmd.sh:402 main(...)

might be a race introduced by your changes

smarterclayton · 2015-05-16T21:29:10Z

The race should be fixed by #2294

0xmichalis · 2015-05-18T09:15:45Z

The deployment pod isn't deleted when stopping a dc... Looking at it.

smarterclayton · 2015-05-18T12:20:05Z

That's the responsibility of the deployment controller.

On May 18, 2015, at 5:15 AM, Michail Kargakis [email protected] wrote:

The deployment pod isn't deleted when stopping a dc... Looking at it.

—
Reply to this email directly or view it on GitHub.

0xmichalis · 2015-05-18T12:55:51Z

It seems like the deployment controller will delete the deployer pod only when the deployment is successful. Does the replication controller have a status at all when it's deleted by a cli command? Should we change its status to complete before deleting it (can we even do that?) so that the deployer controller can delete the pod or should we just go on by manually deleting it?

smarterclayton · 2015-05-18T13:34:15Z

----- Original Message -----

It
seems
like the deployment controller will delete the deployer pod only when the
deployment is successful. Does the replication controller have a status at
all when it's deleted by a cli command?

The deployment controller will try to start it again, which we don't want.

Should we change its status to
complete before deleting it (can we even do that?) so that the deployer
controller can delete the pod or should we just go on by manually deleting
it?

We shouldn't be changing anything on the RC - that's the responsibility of the deployment controller to manage, and it's likely we'd end up having code in two places. I'd prefer that we not be deleting it from the CLI.

Reply to this email directly or view it on GitHub:
#1944 (comment)

0xmichalis · 2015-05-18T14:02:24Z

@smarterclayton this is ready for merging. The error on Travis is fixed here: #2308

0xmichalis · 2015-05-18T14:42:19Z

Re deployer pod, opened a separate issue to track it down: #2316

smarterclayton · 2015-05-18T15:01:20Z

pkg/cmd/cli/cli.go

 	cmds.AddCommand(cmd.NewCmdLogin(fullName, f, in, out))
 	cmds.AddCommand(cmd.NewCmdLogout("logout", fullName+" logout", fullName+" login", f, in, out))
+	cmds.AddCommand(cmd.NewCmdNewApplication(fullName, f, out))


Why did you reorder these? The order is significant, and is intentional. Please revert the ordering.

I am not sure of the previous order but now the commands are alphabetically sorted in two groups: OpenShift-specific and Kubernetes wrappers.

We don't want that. The order is intentional, most used commands followed by lesser used commands.

----- Original Message -----

cmds.AddCommand(cmd.NewCmdLogin(fullName, f, in, out)) cmds.AddCommand(cmd.NewCmdLogout("logout", fullName+" logout", fullName+" login", f, in, out))

cmds.AddCommand(cmd.NewCmdNewApplication(fullName, f, out))

I am not sure of the previous order but now the commands are
alphabetically sorted in two groups: OpenShift-specific and Kubernetes
wrappers.

Reply to this email directly or view it on GitHub:
https://github.com/openshift/origin/pull/1944/files#r30515535

hm, for what it's worth (not much i'm sure) i think alphabetic makes more sense. if i'm trying to scan for the usage of a command i know the name of, it's easier to find if the list is alphabetical. and if i don't know the name of the command i'm looking for, i still may have guesses which are going to lead me to navigate the list in an alphabetic search.

i don't really see the value in having the most common ones at the top, given that the whole list is going to be displayed anyway (in fact you could argue the most common ones should be at the bottom since that's what's going to be front and center after someone runs osc)

----- Original Message -----

From: "Clayton Coleman" [email protected]
To: "openshift/origin" [email protected]
Cc: "Ben Parees" [email protected]
Sent: Monday, May 18, 2015 1:34:59 PM
Subject: Re: [origin] Add support for 'osc stop|label' from upstream (#1944)

cmds.AddCommand(cmd.NewCmdLogin(fullName, f, in, out)) cmds.AddCommand(cmd.NewCmdLogout("logout", fullName+" logout", fullName+" login", f, in, out))

cmds.AddCommand(cmd.NewCmdNewApplication(fullName, f, out))

We don't want that. The order is intentional, most used commands followed by
lesser used commands.

----- Original Message -----

cmds.AddCommand(cmd.NewCmdLogin(fullName, f, in, out))
cmds.AddCommand(cmd.NewCmdLogout("logout", fullName+" logout",
fullName+"
login", f, in, out))

cmds.AddCommand(cmd.NewCmdNewApplication(fullName, f, out))

I am not sure of the previous order but now the commands are
alphabetically sorted in two groups: OpenShift-specific and Kubernetes
wrappers.

Reply to this email directly or view it on GitHub:
https://github.com/openshift/origin/pull/1944/files#r30515535

Reply to this email directly or view it on GitHub:
https://github.com/openshift/origin/pull/1944/files#r30529266

The organization of the main help is going to be like "git help". Ordered by function and utility. The group boundaries will be based on the order.

----- Original Message -----

cmds.AddCommand(cmd.NewCmdLogin(fullName, f, in, out)) cmds.AddCommand(cmd.NewCmdLogout("logout", fullName+" logout", fullName+" login", f, in, out))

cmds.AddCommand(cmd.NewCmdNewApplication(fullName, f, out))

hm, for what it's worth (not much i'm sure) i think alphabetic makes more
sense. if i'm trying to scan for the usage of a command i know the name of,
it's easier to find if the list is alphabetical. and if i don't know the
name of the command i'm looking for, i still may have guesses which are
going to lead me to navigate the list in an alphabetic search.

i don't really see the value in having the most common ones at the top, given
that the whole list is going to be displayed anyway (in fact you could argue
the most common ones should be at the bottom since that's what's going to be
front and center after someone runs osc)

----- Original Message -----

From: "Clayton Coleman" [email protected]
To: "openshift/origin" [email protected]
Cc: "Ben Parees" [email protected]
Sent: Monday, May 18, 2015 1:34:59 PM
Subject: Re: [origin] Add support for 'osc stop|label' from upstream
(#1944)

cmds.AddCommand(cmd.NewCmdLogin(fullName, f, in, out))
cmds.AddCommand(cmd.NewCmdLogout("logout", fullName+" logout",
fullName+"
login", f, in, out))

cmds.AddCommand(cmd.NewCmdNewApplication(fullName, f, out))

We don't want that. The order is intentional, most used commands followed
by
lesser used commands.

----- Original Message -----

cmds.AddCommand(cmd.NewCmdLogin(fullName, f, in, out)) cmds.AddCommand(cmd.NewCmdLogout("logout", fullName+" logout", fullName+" login", f, in, out))

cmds.AddCommand(cmd.NewCmdNewApplication(fullName, f, out))

I am not sure of the previous order but now the commands are
alphabetically sorted in two groups: OpenShift-specific and
Kubernetes
wrappers.

Reply to this email directly or view it on GitHub:
https://github.com/openshift/origin/pull/1944/files#r30515535

Reply to this email directly or view it on GitHub:
https://github.com/openshift/origin/pull/1944/files#r30529266

Reply to this email directly or view it on GitHub:
https://github.com/openshift/origin/pull/1944/files#r30530444

can we sort within group boundaries? please? :)

No :) See "rhc help" for what you're going to get :)

----- Original Message -----

cmds.AddCommand(cmd.NewCmdLogin(fullName, f, in, out)) cmds.AddCommand(cmd.NewCmdLogout("logout", fullName+" logout", fullName+" login", f, in, out))

cmds.AddCommand(cmd.NewCmdNewApplication(fullName, f, out))

can we sort within group boundaries? please? :)

Reply to this email directly or view it on GitHub:
https://github.com/openshift/origin/pull/1944/files#r30530947

This commit adds two commands from Kubernetes: stop and label. While label was rather trivial to import in OpenShift, for stop to be fully functional deploymentConfigs had first to implement the kubectl.Resizer interface (work on the Resizer can be found in #2158) which is a prerequisite for another needed interface, kubectl.Reaper (work on the Reaper can be found here).

smarterclayton · 2015-05-18T23:27:36Z

LGTM [merge]

openshift-bot · 2015-05-18T23:30:23Z

continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pull_requests_origin/2248/) (Image: devenv-fedora_1564)

openshift-bot · 2015-05-18T23:30:23Z

Evaluated for origin up to 633b1b9

Merged by openshift-bot

smarterclayton reviewed Apr 28, 2015
View reviewed changes

0xmichalis changed the title ~~Add support for 'osc stop|label' from upstream~~ [WIP] Add support for 'osc stop|label' from upstream Apr 28, 2015

0xmichalis mentioned this pull request Apr 28, 2015

osc get selector filtering not working #1940

Closed

0xmichalis changed the title ~~[WIP] Add support for 'osc stop|label' from upstream~~ Add support for 'osc stop|label' from upstream May 5, 2015

0xmichalis mentioned this pull request May 11, 2015

Support osc delete deploymentcontroller/foo --cascade #2043

Closed

smarterclayton reviewed May 14, 2015
View reviewed changes

adellape mentioned this pull request May 14, 2015

Add docs for osc label|stop openshift/openshift-docs#332

Merged

smarterclayton reviewed May 18, 2015
View reviewed changes

openshift-bot pushed a commit that referenced this pull request May 19, 2015

Merge pull request #1944 from kargakis/bundle-stop-and-label

10b4cfe

Merged by openshift-bot

openshift-bot merged commit 10b4cfe into openshift:master May 19, 2015

0xmichalis deleted the bundle-stop-and-label branch May 19, 2015 07:29

Add support for 'osc stop|label' from upstream #1944

Add support for 'osc stop|label' from upstream #1944

Conversation

0xmichalis commented Apr 28, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Shut down foo.

Stop pods and services with label name=myLabel.

Shut down the service defined in service.json

Shut down all resources in the path/to/resources directory

0xmichalis commented Apr 30, 2015

0xmichalis commented May 7, 2015

smarterclayton commented May 7, 2015

0xmichalis commented May 7, 2015

0xmichalis commented May 14, 2015

Choose a reason for hiding this comment

0xmichalis commented May 14, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

smarterclayton commented May 14, 2015

0xmichalis commented May 15, 2015

openshift-bot commented May 15, 2015

0xmichalis commented May 15, 2015

smarterclayton commented May 16, 2015

smarterclayton commented May 16, 2015

0xmichalis commented May 18, 2015

smarterclayton commented May 18, 2015

0xmichalis commented May 18, 2015

smarterclayton commented May 18, 2015

0xmichalis commented May 18, 2015

0xmichalis commented May 18, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

smarterclayton commented May 18, 2015

openshift-bot commented May 18, 2015

openshift-bot commented May 18, 2015