Add previous-scale annotation for idled resources #10421
Conversation
|
LGTM |
|
lgtm |
|
@smarterclayton who is doing the api review? you / @deads2k / @liggitt / @jwforres ? |
| @@ -9,6 +9,10 @@ const ( | |||
| // objects associated with the idled endpoints | |||
| UnidleTargetAnnotation = "idling.alpha.openshift.io/unidle-targets" | |||
|
|
|||
| // PreviousScaleAnnotation contains the previous scale of a scalable object | |||
| // (currently only applied by the idler) | |||
| PreviousScaleAnnotation = "scale.openshift.io/previous-scale" | |||
There was a problem hiding this comment.
This name doesn't match what this is doing. When I scale an object, I don't get this value filled in. This looks tightly coupled to idling.
There was a problem hiding this comment.
Yeah, I would probably call this idling.alpha.openshift.io/previous-scale or something like that
There was a problem hiding this comment.
I can, but when I was talking to @smarterclayton, we were discussing the idea of making something like this automatically applied on scales in the future (and then have scale.openshift.io/xyz passed through the scale subresource so that it can act like a prototype API field, just like other objects), so using something like this would future-proof that somewhat.
There was a problem hiding this comment.
(although using scale.openshift.io instead of scale.kubernetes.io might complicate that somewhat)
There was a problem hiding this comment.
I can, but when I was talking to @smarterclayton, we were discussing the idea of making something like this automatically applied on scales in the future (and then have scale.openshift.io/xyz passed through the scale subresource so that it can act like a prototype API field, just like other objects), so using something like this would future-proof that somewhat.
I'm not really convinced that I'd like to use an annotation to remember previous state (see problems with the other kube attempts to use annotations to store history). I'm also not seeing a lot of value for "undo" in the general case. It seems like it would open us up to a new class of privilege escalation attacks if we had a controller that attempted to reconcile this annotation automatically.
I'd rather target the information that we want to preserve for its current usage.
@smarterclayton is there some more complete design that covers how we'd resolve the problems of history tracking annotations and privilege escalation attacks based on controllers watching annotations (think DC scaling existing RC, not scaling the current object)? Are you ok with scoping this to address our current, narrow need first?
|
Name needs updating and it would be nice to see a CLI usage demonstrating your intent, which I think is something like:
Other than the name, I'm fine with this. |
ack, will add tomorrow |
Thanks. There's probably a |
|
Edit on a resource is edit on scale, so what's the privilege escalation? Preserving the user's previous scale value is important - if the user has On Tue, Aug 16, 2016 at 5:18 PM, David Eads [email protected]
|
For idling, sure. No issue with this for idling. In the general case though, I don't see why I would try to build a scaling history |
|
Maybe I missed the context, but some status displaying recent scaling might On Tue, Aug 16, 2016 at 6:02 PM, David Eads [email protected]
|
Maybe, but I'd rather add it for a concrete reason, set in a way that makes sense, and get a name that makes sense. To be generally useful, you need to have the contract on the polymorphic scale endpoint change the annotation. This pull does none of those things. To be clear, we're arguing over an annotation name here, not the use in this narrow case. The annotation is set only by idling for a narrow reason, I think it deserves a narrowly scoped name. |
|
Also, scale on a DC does not edit the DC and without access to the rcs you can never reproduce the effect since you don't know the shape of the RC you're scaling by touching the DC. It's like a dc status. It's actually mucking directly with rcs. |
I believe it does, unless someone changed it since I added support for the |
|
Scale on a DC does edit the DC
|
Sure, that's a thing that requires an update in the future (and it's something I intend to work on, as it would be generally useful to be able to prototype scale API fields the same way we prototype the addition of fields to other API objects), but I mainly wanted to have something that was forwards compatible, so to speak. |
Narrow name for a narrow case. The general solution to a theoretical general problem that requires upstream API changes we won't pick for a general need we don't have is probably more than is worth picking up here. |
"idling.alpha.openshift.io/previous-scale" is perfect. It's scoped to its use, the name identifies who is setting it and it matches the behavior you'd expect when idling and unidling. "scale.openshift.io/previous-scale" is overly broad. It suggests that the scale operation is controlling this (it isn't). To make it behave as expected, you'd have to change the contract on the polymorphic |
|
We can always deprecate |
|
yeah, for the sake of moving this forward I'll just change it to the annotation suggested by @deads2k |
DirectXMan12
force-pushed
the
feature/idling-prev-scale
branch
from
36afd51 to
53aa583
Compare
|
lgtm [merge] |
|
[Test]ing while waiting on the merge queue |
DirectXMan12
force-pushed
the
feature/idling-prev-scale
branch
from
53aa583 to
13d4018
Compare
|
Missing quote in the cmd test. Fixed. |
|
[merge] |
|
continuous-integration/openshift-jenkins/merge SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/8206/) (Image: devenv-rhel7_4873) |
DirectXMan12
force-pushed
the
feature/idling-prev-scale
branch
from
13d4018 to
20ab280
Compare
This records the previous scale of an idled resource on idling. This is useful in situations where finding and loading the associated endpoints object would non-ideal (e.g. the web console).
|
@DirectXMan12 any real changes? |
|
@deads2k no, just rebased b/c there was a weird error in the console log of the tests about one of the files needing a merge. |
|
[merge] |
|
Evaluated for origin merge up to 20ab280 |
|
[test] for fun |
|
Evaluated for origin test up to 20ab280 |
|
continuous-integration/openshift-jenkins/test SUCCESS (https://ci.openshift.redhat.com/jenkins/job/test_pr_origin/8208/) |
This records the previous scale of an idled resource on idling.
This is useful in situations where finding and loading the associated
endpoints object would non-ideal (e.g. the web console).