Resize verb

[pweil-]

Making a local PR to make sure I'm not way off track with this.

This is an attempt to address: kubernetes#1629

Note: this is doing relative resizing right now, if it is on the right track I will add absolute resizing as noted in the comments of kubernetes#1629.

[pweil-]

@derekwaynecarr @smarterclayton - do one of you have time to make sure I'm not going off in the wrong direction with this?

[derekwaynecarr]

I don't like the pattern here because it makes it too easy to circumvent admission control / quota (which I will link to my changeset tomorrow am).

I would at least prefer a pattern where a runtime.Object implemented a resizable interface. That way you get an object, call resize on object, and then ideally find a way to go through normal update pattern in rest handler.

If you have 15 minutes tomorrow would like to synch on why I prefer that over what is here, demo how I am enforcing quota, and go from there?

Sent from my iPhone

On Dec 17, 2014, at 2:41 PM, Paul [email protected] wrote:

@derekwaynecarr @smarterclayton - do one of you have time to make sure I'm not going off in the wrong direction with this?

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

[pweil-]

@derekwaynecarr that would be awesome. If we can discuss the appropriate implementation I'd love to have this ready for a formal PR before the break.

[smarterclayton]

We don't want to put interfaces on value objects really

On Dec 17, 2014, at 7:10 PM, Derek Carr [email protected] wrote:

I don't like the pattern here because it makes it too easy to circumvent admission control / quota (which I will link to my changeset tomorrow am).

I would at least prefer a pattern where a runtime.Object implemented a resizable interface. That way you get an object, call resize on object, and then ideally find a way to go through normal update pattern in rest handler.

If you have 15 minutes tomorrow would like to synch on why I prefer that over what is here, demo how I am enforcing quota, and go from there?

Sent from my iPhone

On Dec 17, 2014, at 2:41 PM, Paul [email protected] wrote:

@derekwaynecarr @smarterclayton - do one of you have time to make sure I'm not going off in the wrong direction with this?

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

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

[smarterclayton]

To clarify, resize is a verb and an optional interface on rest storage

On Dec 17, 2014, at 7:10 PM, Derek Carr [email protected] wrote:

I don't like the pattern here because it makes it too easy to circumvent admission control / quota (which I will link to my changeset tomorrow am).

I would at least prefer a pattern where a runtime.Object implemented a resizable interface. That way you get an object, call resize on object, and then ideally find a way to go through normal update pattern in rest handler.

If you have 15 minutes tomorrow would like to synch on why I prefer that over what is here, demo how I am enforcing quota, and go from there?

Sent from my iPhone

On Dec 17, 2014, at 2:41 PM, Paul [email protected] wrote:

@derekwaynecarr @smarterclayton - do one of you have time to make sure I'm not going off in the wrong direction with this?

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

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

[derekwaynecarr]

I rash on my interface on resource. What I really don't want is multiple code paths to do an update above rest storage tier. So if we introduce a resize function, that is cool, but it should go through the same code path that is ultimately shared by rest handler update. If that means get the object, call a resizer that knows what field to modify, and then call the same code flow as rest handler update, then I am fine. Hope that makes sense.

Sent from my iPhone

On Dec 18, 2014, at 9:42 AM, Clayton Coleman [email protected] wrote:

We don't want to put interfaces on value objects really

On Dec 17, 2014, at 7:10 PM, Derek Carr [email protected] wrote:

I don't like the pattern here because it makes it too easy to circumvent admission control / quota (which I will link to my changeset tomorrow am).

I would at least prefer a pattern where a runtime.Object implemented a resizable interface. That way you get an object, call resize on object, and then ideally find a way to go through normal update pattern in rest handler.

If you have 15 minutes tomorrow would like to synch on why I prefer that over what is here, demo how I am enforcing quota, and go from there?

Sent from my iPhone

On Dec 17, 2014, at 2:41 PM, Paul [email protected] wrote:

@derekwaynecarr @smarterclayton - do one of you have time to make sure I'm not going off in the wrong direction with this?

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

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

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

[derekwaynecarr]

A resize is an update, it should go through the update code path on APIServer/RESTStorage.

There may be some special logic to do before it goes through that code path, but it needs to go through a common code path at APIServer tier.

Implementation of a resize is done by some intelligent bit of code that knows to

1. foo = RESTStorage.GET(name)
2. foo.size = newsize
3. call APIServer.Update(foo)
   a -> which calls RESTStorage.Update(object)

I basically want to avoid introducing code paths for updates that are not going through the same update flow.

If resize is implemented in a pattern as above, I am fine.

Thanks,
Derek
----- Original Message -----
From: "Clayton Coleman" [email protected]
To: "pweil-/kubernetes" [email protected]
Cc: "Derek Carr" [email protected]
Sent: Thursday, December 18, 2014 9:44:24 AM
Subject: Re: [kubernetes] Resize verb (#1)

To clarify, resize is a verb and an optional interface on rest storage

On Dec 17, 2014, at 7:10 PM, Derek Carr [email protected] wrote:

I don't like the pattern here because it makes it too easy to circumvent admission control / quota (which I will link to my changeset tomorrow am).

I would at least prefer a pattern where a runtime.Object implemented a resizable interface. That way you get an object, call resize on object, and then ideally find a way to go through normal update pattern in rest handler.

If you have 15 minutes tomorrow would like to synch on why I prefer that over what is here, demo how I am enforcing quota, and go from there?

Sent from my iPhone

On Dec 17, 2014, at 2:41 PM, Paul [email protected] wrote:

@derekwaynecarr @smarterclayton - do one of you have time to make sure I'm not going off in the wrong direction with this?

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

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

---

Reply to this email directly or view it on GitHub:
https://github.com/pweil-/kubernetes/pull/1#issuecomment-67494736

[smarterclayton]

I don't know that I agree - let's have the discussion in the other issue though.

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

A resize is an update, it should go through the update code path on
APIServer/RESTStorage.

There may be some special logic to do before it goes through that code path,
but it needs to go through a common code path at APIServer tier.

Implementation of a resize is done by some intelligent bit of code that knows
to

1. foo = RESTStorage.GET(name)
2. foo.size = newsize
3. call APIServer.Update(foo)
   a -> which calls RESTStorage.Update(object)

I basically want to avoid introducing code paths for updates that are not
going through the same update flow.

If resize is implemented in a pattern as above, I am fine.

Thanks,
Derek
----- Original Message -----
From: "Clayton Coleman" [email protected]
To: "pweil-/kubernetes" [email protected]
Cc: "Derek Carr" [email protected]
Sent: Thursday, December 18, 2014 9:44:24 AM
Subject: Re: [kubernetes] Resize verb (#1)

To clarify, resize is a verb and an optional interface on rest storage

On Dec 17, 2014, at 7:10 PM, Derek Carr [email protected] wrote:

I don't like the pattern here because it makes it too easy to circumvent
admission control / quota (which I will link to my changeset tomorrow am).

I would at least prefer a pattern where a runtime.Object implemented a
resizable interface. That way you get an object, call resize on object,
and then ideally find a way to go through normal update pattern in rest
handler.

If you have 15 minutes tomorrow would like to synch on why I prefer that
over what is here, demo how I am enforcing quota, and go from there?

Sent from my iPhone

On Dec 17, 2014, at 2:41 PM, Paul [email protected] wrote:

@derekwaynecarr @smarterclayton - do one of you have time to make sure
I'm not going off in the wrong direction with this?

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

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

---

Reply to this email directly or view it on GitHub:
https://github.com/pweil-/kubernetes/pull/1#issuecomment-67494736

---

Reply to this email directly or view it on GitHub:
https://github.com/pweil-/kubernetes/pull/1#issuecomment-67495555

[smarterclayton]

Breaking my own suggestion - the ability to resize should be limited to different people than the ability to update. I should be able to resize without being able to change the other attributes of a replication controller.

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

I don't know that I agree - let's have the discussion in the other issue
though.

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

A resize is an update, it should go through the update code path on
APIServer/RESTStorage.

There may be some special logic to do before it goes through that code
path,
but it needs to go through a common code path at APIServer tier.

Implementation of a resize is done by some intelligent bit of code that
knows
to

1. foo = RESTStorage.GET(name)
2. foo.size = newsize
3. call APIServer.Update(foo)
   a -> which calls RESTStorage.Update(object)

I basically want to avoid introducing code paths for updates that are not
going through the same update flow.

If resize is implemented in a pattern as above, I am fine.

Thanks,
Derek
----- Original Message -----
From: "Clayton Coleman" [email protected]
To: "pweil-/kubernetes" [email protected]
Cc: "Derek Carr" [email protected]
Sent: Thursday, December 18, 2014 9:44:24 AM
Subject: Re: [kubernetes] Resize verb (#1)

To clarify, resize is a verb and an optional interface on rest storage

On Dec 17, 2014, at 7:10 PM, Derek Carr [email protected] wrote:

I don't like the pattern here because it makes it too easy to circumvent
admission control / quota (which I will link to my changeset tomorrow
am).

I would at least prefer a pattern where a runtime.Object implemented a
resizable interface. That way you get an object, call resize on object,
and then ideally find a way to go through normal update pattern in rest
handler.

If you have 15 minutes tomorrow would like to synch on why I prefer that
over what is here, demo how I am enforcing quota, and go from there?

Sent from my iPhone

On Dec 17, 2014, at 2:41 PM, Paul [email protected] wrote:

@derekwaynecarr @smarterclayton - do one of you have time to make sure
I'm not going off in the wrong direction with this?

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

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

---

Reply to this email directly or view it on GitHub:
https://github.com/pweil-/kubernetes/pull/1#issuecomment-67494736

---

Reply to this email directly or view it on GitHub:
https://github.com/pweil-/kubernetes/pull/1#issuecomment-67495555

[derekwaynecarr]

I am fine with that.

I am just saying that the code path after the policy check (which you are handling diff with new verb), needs to go through same Update step internally.

We should not start introducing 10k new ways things can update. An update is an update is an update. We should introduce alternatives on how to do targeted updates that get around certain policy checks if needed, but internally, an update is an update is an update ;-)

----- Original Message -----
From: "Clayton Coleman" [email protected]
To: "pweil-/kubernetes" [email protected]
Cc: "Derek Carr" [email protected]
Sent: Thursday, December 18, 2014 10:22:45 AM
Subject: Re: [kubernetes] Resize verb (#1)

Breaking my own suggestion - the ability to resize should be limited to different people than the ability to update. I should be able to resize without being able to change the other attributes of a replication controller.

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

I don't know that I agree - let's have the discussion in the other issue
though.

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

A resize is an update, it should go through the update code path on
APIServer/RESTStorage.

There may be some special logic to do before it goes through that code
path,
but it needs to go through a common code path at APIServer tier.

Implementation of a resize is done by some intelligent bit of code that
knows
to

1. foo = RESTStorage.GET(name)
2. foo.size = newsize
3. call APIServer.Update(foo)
   a -> which calls RESTStorage.Update(object)

I basically want to avoid introducing code paths for updates that are not
going through the same update flow.

If resize is implemented in a pattern as above, I am fine.

Thanks,
Derek
----- Original Message -----
From: "Clayton Coleman" [email protected]
To: "pweil-/kubernetes" [email protected]
Cc: "Derek Carr" [email protected]
Sent: Thursday, December 18, 2014 9:44:24 AM
Subject: Re: [kubernetes] Resize verb (#1)

To clarify, resize is a verb and an optional interface on rest storage

On Dec 17, 2014, at 7:10 PM, Derek Carr [email protected] wrote:

I don't like the pattern here because it makes it too easy to circumvent
admission control / quota (which I will link to my changeset tomorrow
am).

I would at least prefer a pattern where a runtime.Object implemented a
resizable interface. That way you get an object, call resize on object,
and then ideally find a way to go through normal update pattern in rest
handler.

If you have 15 minutes tomorrow would like to synch on why I prefer that
over what is here, demo how I am enforcing quota, and go from there?

Sent from my iPhone

On Dec 17, 2014, at 2:41 PM, Paul [email protected] wrote:

@derekwaynecarr @smarterclayton - do one of you have time to make sure
I'm not going off in the wrong direction with this?

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

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

---

Reply to this email directly or view it on GitHub:
https://github.com/pweil-/kubernetes/pull/1#issuecomment-67494736

---

Reply to this email directly or view it on GitHub:
https://github.com/pweil-/kubernetes/pull/1#issuecomment-67495555

---

Reply to this email directly or view it on GitHub:
https://github.com/pweil-/kubernetes/pull/1#issuecomment-67500692

[smarterclayton]

I think resize is a special case of update, which means policy should require that new verbs either reduce to generic behavior (watch is get, resize is update), or we try to cram them into one verb but with field specific behavior (??? yuck ???)

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

I am fine with that.

I am just saying that the code path after the policy check (which you are
handling diff with new verb), needs to go through same Update step
internally.

We should not start introducing 10k new ways things can update. An update is
an update is an update. We should introduce alternatives on how to do
targeted updates that get around certain policy checks if needed, but
internally, an update is an update is an update ;-)

----- Original Message -----
From: "Clayton Coleman" [email protected]
To: "pweil-/kubernetes" [email protected]
Cc: "Derek Carr" [email protected]
Sent: Thursday, December 18, 2014 10:22:45 AM
Subject: Re: [kubernetes] Resize verb (#1)

Breaking my own suggestion - the ability to resize should be limited to
different people than the ability to update. I should be able to resize
without being able to change the other attributes of a replication
controller.

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

I don't know that I agree - let's have the discussion in the other issue
though.

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

A resize is an update, it should go through the update code path on
APIServer/RESTStorage.

There may be some special logic to do before it goes through that code
path,
but it needs to go through a common code path at APIServer tier.

Implementation of a resize is done by some intelligent bit of code that
knows
to

1. foo = RESTStorage.GET(name)
2. foo.size = newsize
3. call APIServer.Update(foo)
   a -> which calls RESTStorage.Update(object)

I basically want to avoid introducing code paths for updates that are not
going through the same update flow.

If resize is implemented in a pattern as above, I am fine.

Thanks,
Derek
----- Original Message -----
From: "Clayton Coleman" [email protected]
To: "pweil-/kubernetes" [email protected]
Cc: "Derek Carr" [email protected]
Sent: Thursday, December 18, 2014 9:44:24 AM
Subject: Re: [kubernetes] Resize verb (#1)

To clarify, resize is a verb and an optional interface on rest storage

On Dec 17, 2014, at 7:10 PM, Derek Carr [email protected]
wrote:

I don't like the pattern here because it makes it too easy to
circumvent
admission control / quota (which I will link to my changeset tomorrow
am).

I would at least prefer a pattern where a runtime.Object implemented a
resizable interface. That way you get an object, call resize on object,
and then ideally find a way to go through normal update pattern in rest
handler.

If you have 15 minutes tomorrow would like to synch on why I prefer
that
over what is here, demo how I am enforcing quota, and go from there?

Sent from my iPhone

On Dec 17, 2014, at 2:41 PM, Paul [email protected] wrote:

@derekwaynecarr @smarterclayton - do one of you have time to make
sure
I'm not going off in the wrong direction with this?

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

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

---

Reply to this email directly or view it on GitHub:
https://github.com/pweil-/kubernetes/pull/1#issuecomment-67494736

---

Reply to this email directly or view it on GitHub:
https://github.com/pweil-/kubernetes/pull/1#issuecomment-67495555

---

Reply to this email directly or view it on GitHub:
https://github.com/pweil-/kubernetes/pull/1#issuecomment-67500692

---

Reply to this email directly or view it on GitHub:
https://github.com/pweil-/kubernetes/pull/1#issuecomment-67501705

[pweil-]

Another suggestion for implementation that eliminates the interface and instead uses a helper function that would go through the api server. The new resize verb handler and other code paths can then use the helper. The helper would be responsible for policy checking in this scenario:

 func Resize (obj, newSize) {         
      //cast to metadata interface
      //check policy
      //switch on the object type
      //call a function that knows how to deal with the specific object type
 }

 func resizeReplicationController(obj, newSize){
      //shouldn't be called directly or policy check needs to occur here
      //set the replica count
      //call apiserver.Update
 }

[smarterclayton]

I don't know why we would have helpers. The logic for resize is totally encapsulated inside the RESTStorage or the command client, and we already have a construct for generic resize from a client side (which deals with REST verbs, not code).

The generic resize is RESTHelper.Resize(namespace, name, -1), which tries to POST to ////op/resize, and fails if it doesn't exist. That's why it has to be a generic verb, since the POST structure has to be the same across multiple resource types.

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

Another suggestion for implementation that eliminates the interface and
instead uses a helper function that would go through the api server. The
new resize verb handler and other code paths can then use the helper. The
helper would be responsible for policy checking in this scenario:

 func Resize (obj, newSize) {
      //cast to metadata interface
      //check policy
      //switch on the object type
      //call a function that knows how to deal with the specific object
      type
 }

 func ResizeReplicationController(obj, newSize){
      //set the replica count
      //call apiserver.Update
 }

---

Reply to this email directly or view it on GitHub:
https://github.com/pweil-/kubernetes/pull/1#issuecomment-67502469