I'd like to see the group, version, resource reference in ScaleRef properly handled by the HPA controller. Right now, its assuming that it can convert statically from Kind to Resource, which is wrong.

@deads2k could you please elaborate? I'm not sure whether I understand your comment.

@deads2k could you please elaborate? I'm not sure whether I understand your comment.

Take this code as a for instance: https://github.com/kubernetes/kubernetes/blob/master/pkg/client/typed/generated/extensions/unversioned/scale_expansion.go#L37 . It's not actually mapping from a Kind to a Resource. That function just tries to run a ToLower, pluralize, and hopes for the best. Since registration can happen with any name, that only works by luck.

You've also not explicitly called out the need to respect the apiVersion field (which might be a 1) version, 2) group, 3) group/version). That's also required, along with some sort of migration to handle the partially qualified cases which you've got today, since they don't seem to be required to specify apiVersion. @bgrant0607 wants to require a fully specified "group/version" in that field. I'd like to allow the common case of "group" and allow version to be negotiated so I don't have to perform a data migration. Of course, that negotiation requires requires more logic too.

On top of those items, the variants of Scale that we have, mean that an internal client has to perform a discovery check on scale subresource to find the Group/Version to use for the external conversion. The discovery doc today simply says Scale which doesn't have enough information now that we're exposing scale under api/v1/namespaces/ns/replicationcontrollers/foo/scale.

@kubernetes/rh-cluster-infra @liggitt anything big still missing from the list?

Did we ever resolve the UX question around users not being able to see the current target in autoscaling/v1 if they use a default value? Is there a way to disambiguate between "I want the default CPU value" and "I don't want CPU autoscaling" (and perhaps I forgot to put in any other type of autoscaling)?

@piosz what is the status of this issue?

@piosz has previously indicated that everything needed for 1.3 here is already done, so I'm going to remove the 1.3 milestone. If the entire issue is finished, then he can close it.

Re-adding milestone. The status is:

• the last PR is in flight Added hpa/v1 generator to kubectl autoscale #26775
• not sure whether there is any way to deprecate API; @lavalamp any thoughts
• issues raised by @deads2k are not a blocker for this, creating separate issue

Yeah, you give notice in release notes that it's deprecated as of now, and
I think we can turn it off in 1.4--have to check if we need to give one
cycle or two. Certainly if there's any difficulty in clients switching to
using the new endpoint now, though, we'd need to give them until 1.5.

On Fri, Jun 3, 2016 at 4:54 AM, Piotr Szczesniak notifications@github.com
wrote:

Re-adding milestone. The status is:

• the last PR is in flight Added hpa/v1 generator to kubectl autoscale #26775
  Added hpa/v1 generator to kubectl autoscale #26775
• not sure whether there is any way to deprecate API; @lavalamp
  https://github.com/lavalamp any thoughts
• issues raised by @DirectXMan12 https://github.com/DirectXMan12 are
  not a blocker for this, creating separate issue

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

@lavalamp thanks for clarification. I added release note to #25279. The inital plan was to:

• introduce HPA in autoscaling/v1 in Kubernetes 1.2
• migrate internal components to use autoscaling/v1 objects in Kubernetes 1.3
• remove HPA in extensions/v1beta1 in Kubernetes 1.4

So I'm planning to remove HPA in extensions/v1beta1 in 1.4

That sounds fine. People will need to run the upgrade object script before
step 3.

On Tue, Jun 7, 2016 at 7:06 AM, Piotr Szczesniak notifications@github.com
wrote:

@lavalamp https://github.com/lavalamp thanks for clarification. I added
release note to #25279
#25279. The inital plan
was to:

• introduce HPA in autoscaling/v1 in Kubernetes 1.2
• migrate internal components to use autoscaling/v1 objects in
  Kubernetes 1.3
• remove HPA in extensions/v1beta1 in Kubernetes 1.4 So I'm planning
  to remove HPA in extensions/v1beta1 in 1.4

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

Last PR is merged #26775, so closing the issue.

@lavalamp is there any info that users need to run the upgrade script? AFAIR it was already specified in release notes for 1.2.

They just need to run it, it should automatically do everything right.

On Sat, Jun 11, 2016 at 11:21 AM, Piotr Szczesniak <notifications@github.com

wrote:

Last PR is merged #26775
#26775, so closing the
issue.

@lavalamp https://github.com/lavalamp is there any info that users need
to run the upgrade script? AFAIR it was already specified in release notes
for 1.2.

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