Thanks for your pull request.

It looks like this may be your first contribution to a Google open source project, in which case you'll need to sign a Contributor License Agreement (CLA) at https://cla.developers.google.com/.

If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check the information on your CLA or see this help article on setting the email on your git commits.

Once you've done that, please reply here to let us know. If you signed the CLA as a corporation, please let us know the company's name.

@smarterclayton - commit 2 contains updates for almost all the feedback given today. I still need to sync with Dario on the selectors, the refactor for the new etcd layout took longer than expected.

@jszczepkowski

@pweil- @smarterclayton What's the urgency of this issue? I assume you need this in Openshift now/soon?

Possible general approaches to enable you to move faster:

• Put the code into Openshift initially and upstream post-1.0
• Put the code into your fork of Kubernetes and upstream post-1.0
• Create a new API prefix that can be versioned independently, so we could keep it in alpha/beta while promoting the rest of the API to v1
• Schedule an API review meeting via hangout to get API approval at least

We've reprioritized this a bit to get security account / security context sorted out (what Paul is going to be working on soon).

I think we can leave this in discussion state until that work gets closed, unless there is someone else actively looking to push it.

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

@pweil- @smarterclayton What's the urgency of this issue? I assume you need
this in Openshift now/soon?

Possible general approaches to enable you to move faster:

• Put the code into Openshift initially and upstream post-1.0
• Put the code into your fork of Kubernetes and upstream post-1.0
• Create a new API prefix that can be versioned independently, so we could
  keep it in alpha/beta while promoting the rest of the API to v1
• Schedule an API review meeting via hangout to get API approval at least

---

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

@pweil-
Will it be possible to finish this review and merge this PR soon? We are working on autoscaling in Warsaw, and we want to start some development regarding autoscaling of pods in the near future. It will be greatly helpful for us if this PR is merged, so we can build on abstractions defined here.

Regarding API, I think we should create a new API prefix for autoscaling for now (item 3 from #5492 (comment) by @bgrant0607). We don't want to modify v1 API as autoscaling will not be a part of v1. Later, when autoscaling is ready, we may reconsider this decision and merge our autoscaling API with the main API.

CC @tkulczynski @fbalejko

@jszczepkowski - I will talk with @smarterclayton about what needs to be cleaned up to get it in a state that can be merged or at least handed over if it will help with the work you're doing since it low priority for me right now.

Full disclosure: I should point out that there is a fairly large (intentional) gap in the statistics storage. As in, it was not defined in the proposal.

All of the concerns I had are probably best resolved with an actual implementation prototype and discussion.

On Apr 2, 2015, at 12:53 PM, Paul notifications@github.com wrote:

@jszczepkowski - I will talk with @smarterclayton about what needs to be cleaned up to get it in a state that can be merged or at least handed over if it will help with the work you're doing since it low priority for me right now.

Full disclosure: I should point out that there is a fairly large (intentional) gap in the statistics storage. As in, it was not defined in the proposal.

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

@jszczepkowski based on the comment above there is no more clean up to be done. I think the easiest way to keep this going would be to have you cherry-pick the current commit and continue on with the types. I'm assuming we don't want to merge the types until there is a working prototype. If there is anything that would make this easier then please let me know and I'll do my best to get it done ASAP.

Can one of the admins verify that this patch is reasonable to test? (reply "ok to test", or if you trust the user, reply "add to whitelist")

If this message is too spammy, please complain @ixdy.

@pweil- @smarterclayton What's your current timeline for horizontal auto-scaling?

We were hoping to make a push for shortly after 1.0 to define the core types and start prototyping.

On May 21, 2015, at 8:13 PM, Brian Grant notifications@github.com wrote:

@pweil- @smarterclayton What's your current timeline for horizontal auto-scaling?

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

Closing in favor of #12087