I have users that want to run Spark or a Gluster management service that have basically requested this extra level of control to set local min/max replica boundaries for their resources where they wanted to prevent operator changes to replicas.

cc @erictune

I am not a fan of this feature. It would add API complexity and seems cumbersome. I think there are much more important issues with the controllers that we need to tackle if we're going to spend API review bandwidth.

@bgrant0607 - my response echoed your sentiment, but I got a fair amount of push-back from three distinct user communities looking to support Spark, Gluster, and a mobile application scenario.

At it's core the request is asking to have a way to prevent users from harming themselves. User's can harm themselves any number of ways, so I get the complexity/cumbersome argument may not be worth it for all workloads.

Any objection to the concept via annotations on the objects in question, and enforcement via some optional admission controller? If it gets broad adoption, then we could revisit when more bandwidth is needed?

We are running into a number of places where the dev/person who wrote the app has these restrictions, but the operator doesn't likely know. It looks to me like a dev/ops split. Allow dev to keep ops from doing things to hurt themselves.

I think @eparis nailed the interaction exactly. The application writers are often the ones applying/suggesting these limitations for the deployer/operator. It should generally be possible for the operator to override (at a config level) separate from the scaling operation itself.

It's usually not enough to do min/max. We'd need to do cut outs - an etcd
pet set should probably only be allowed to exist at scales 3, 5, or 7.

On Fri, Sep 30, 2016 at 2:16 PM, Dan McPherson notifications@github.com
wrote:

I think @eparis https://github.com/eparis nailed the interaction
exactly. The application writers are often the ones applying/suggesting
these limitations for the deployer/operator. It should generally be
possible for the operator to override (at a config level) separate from the
scaling operation itself.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#33843 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_pxnI6rZvk6j6LcVo2-6elzyUMqkaks5qvVHpgaJpZM4KLR_D
.

ack: enforcing odd numbers is a reasonable request

I share some of Brian's concerns as I've mentioned before. I think this
tends to be more of a requirement for pet sets (which was documented in
the original proposal but is not currently in the critical implementation
path). Ultimately the expectation that the person doing the scaling
doesn't understand what is being scaled is somewhat difficult to enforce,
even if it's not unreasonable when dealing with white box deployed software.

This most frequently comes up for things that are "stateful" - I can only
have 1 of something, but nothing prevents me from setting it to 2 or more.
I would argue the database case is best solved by PV, and the "I'm using a
PVC with RWO but based on RWM and it scales up and breaks me" case is best
solved by not allowing a PVC with RWO to be mounted in two locations (this
has been discussed under the pet set fencing and storage locking
discussion, and applies to local persistent storage and users performing in
place upgrades on the same node).

On Fri, Sep 30, 2016 at 9:52 PM, Derek Carr notifications@github.com
wrote:

ack: enforcing odd numbers is a reasonable request

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#33843 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABG_p-J8Ws36jScRP0FD0y_ABLtm32Y5ks5qvbz2gaJpZM4KLR_D
.

cc @erictune

Also, enforcing an annotation would break autoscaling, and autoscaling
a pet set should be possible, so an enforcing admission controller
needs to at least take that into account and prevent abuse / bugs /
unexpected behavior.

On Oct 11, 2016, at 10:15 PM, Clayton Coleman ccoleman@redhat.com wrote:

It's not enough to do odd numbers though - 3,5,7 may be valid but
others are not. A few systems require 3n+1. Also, does zero count,
or is it a potential exception?

I think this is a requirement to be leveraged against petsets, not
against general resources, and should be solved there, not across all
scalable resources.

A much simpler option might be a "scale protection", like the "delete
protection" we discussed previously. An annotation which clients respect
as "the caller suggested not scaling this". That makes this less of an API
problem than a UX problem.

On Tue, Oct 11, 2016 at 7:25 PM, Clayton Coleman ccoleman@redhat.com
wrote:

Also, enforcing an annotation would break autoscaling, and autoscaling
a pet set should be possible, so an enforcing admission controller
needs to at least take that into account and prevent abuse / bugs /
unexpected behavior.

On Oct 11, 2016, at 10:15 PM, Clayton Coleman ccoleman@redhat.com
wrote:

It's not enough to do odd numbers though - 3,5,7 may be valid but
others are not. A few systems require 3n+1. Also, does zero count,
or is it a potential exception?

I think this is a requirement to be leveraged against petsets, not
against general resources, and should be solved there, not across all
scalable resources.

This needs to be triaged as a release-blocker or not for 1.5 @smarterclayton @derekwaynecarr

not blocker.

thanks @eparis

@derekwaynecarr Is it appropriate to move this to the next milestone or clear the 1.5 milestone? (and remove the non-release-blocker tag as well)

Moving to 1.7 as late to happen in 1.6. Feel free to switch back if this is incorrect.

Any progress on the scale selector ?

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

Prevent issues from auto-closing with an /lifecycle frozen comment.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle stale

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or @fejta.
/lifecycle rotten
/remove-lifecycle stale

This kind of policy should be implemented outside the workload controllers.