Plans to support kubectl apply kind of api in client-go

[krma...@gmail.com]

Kubernetes resources are expanding. It would be nice to be able to build applications that can use client-go to update all the set of k8s resources no matter what, declaratively by just doing client-go.Apply() or client-go.Update().

Is that something in the works ? Any issues or pointers to follow ?

A common set of api across all workload resource types may also be helpful , which do the following:-

- update

- was the update successful ?

- is the update complete and successfully applied

Thoughts from the Kubernetes team ?

Cheers

-Mayank

[Brian Grant]

On Mon, Nov 6, 2017 at 11:17 PM, <krma...@gmail.com> wrote:

Kubernetes resources are expanding. It would be nice to be able to build applications that can use client-go to update all the set of k8s resources no matter what, declaratively by just doing client-go.Apply() or client-go.Update().

Is that something in the works ? Any issues or pointers to follow ?

Only via actual API support:

https://github.com/kubernetes/kubernetes/issues/17333#issuecomment-336732731 

A common set of api across all workload resource types may also be helpful , which do the following:-

- update

- was the update successful ?

- is the update complete and successfully applied

Agreed that determining success/failure would be useful. It's discussed a little here, but there's no proposal yet:

https://docs.google.com/document/d/1cLPGweVEYrVqQvBLJg6sxV-TrE5Rm2MNOBA_cxZP2WU/edit#heading=h.edrnxxvhcni2 

Thoughts from the Kubernetes team ?

Cheers

-Mayank

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/0f457e81-1643-47d3-96a0-ba779e8cdcb5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Clayton Coleman]

There’s a recent request from some Ansible folks to support “what changed” in apply (which is a standard convention to capture the distinction between change and no change).

The first approximation is an exit status code, but its possible that we want a flag for apply that returns structured and versioned json (like an api.Status object).

Anyway, please read the attached docs and comment - making apply work with api extensions correctly is a big deal for things like service catalog

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To post to this group, send email to kuberne...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAKCBhs45d%3D_0783C7AkS0m3%2BoahpgHUBo%2BXqpEd5He%2Bd9MB5gQ%40mail.gmail.com.

[krma...@gmail.com]

Thanks Brian and Clayton

I will read through the docs and comment there. Some more questions and comments:-

- Which sig owns this feature ?  How can i follow progress on this feature  ?

- little more context. we have a bunch of k8s yaml files which we apply using client-go so as to be able to easily track errors and display better information when resource apply fails(this wont be easy with kubectl apply) . We have to write a lot of code to figure out which update failed or successfull and add new code as and when the yaml files have new k8s resources to be added. We also have to write additional code to determine if the deployment is ready or is still in progress. i saw some code here https://github.com/kubernetes/kubernetes/blob/master/pkg/kubectl/rollout_status.go#L66 and https://github.com/kubernetes/kubernetes/blob/master/pkg/kubectl/rollout_status.go#L38 

 I feel like all of this code can also be moved to client-go for at least determining the status of the resources ? If it makes sense, let me know and i can make a  PR for it 

- Another question, why doesnt Status field of Deployment and StatefulSet and other similar resources, support a single field which tells us if the Deployment is complete or is still progressing ? Why does the consumer of these objects have to determine this by looking at all these fields like generation, observedGeneration, replicas, availabledReplicas, UpdatedReplicas etc ? There is only way to interpret the completion and its not customizable, so why not expose a single field which says if its complete or not . Let me know if it makes sense or not ?

Cheers
Mayank

On Tuesday, November 7, 2017 at 5:46:11 AM UTC-8, Clayton Coleman wrote:

There’s a recent request from some Ansible folks to support “what changed” in apply (which is a standard convention to capture the distinction between change and no change).

The first approximation is an exit status code, but its possible that we want a flag for apply that returns structured and versioned json (like an api.Status object).

Anyway, please read the attached docs and comment - making apply work with api extensions correctly is a big deal for things like service catalog

On Nov 7, 2017, at 2:35 AM, 'Brian Grant' via Kubernetes developer/contributor discussion <kuberne...@googlegroups.com> wrote:

On Mon, Nov 6, 2017 at 11:17 PM, <krma...@gmail.com> wrote:

Kubernetes resources are expanding. It would be nice to be able to build applications that can use client-go to update all the set of k8s resources no matter what, declaratively by just doing client-go.Apply() or client-go.Update().

Is that something in the works ? Any issues or pointers to follow ?

Only via actual API support:

https://github.com/kubernetes/kubernetes/issues/17333#issuecomment-336732731 

A common set of api across all workload resource types may also be helpful , which do the following:-

- update

- was the update successful ?

- is the update complete and successfully applied

Agreed that determining success/failure would be useful. It's discussed a little here, but there's no proposal yet:

https://docs.google.com/document/d/1cLPGweVEYrVqQvBLJg6sxV-TrE5Rm2MNOBA_cxZP2WU/edit#heading=h.edrnxxvhcni2 

Thoughts from the Kubernetes team ?

Cheers

-Mayank

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To post to this group, send email to kuberne...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/0f457e81-1643-47d3-96a0-ba779e8cdcb5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michail Kargakis]

We expose a condition for tracking progress - see
https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#progressing-deployment
for more info.

>
> Cheers
> Mayank
>
>
> On Tuesday, November 7, 2017 at 5:46:11 AM UTC-8, Clayton Coleman wrote:
>>
>> There’s a recent request from some Ansible folks to support “what changed”
>>
>> in apply (which is a standard convention to capture the distinction
>> between
>> change and no change).
>>
>> The first approximation is an exit status code, but its possible that we
>> want a flag for apply that returns structured and versioned json (like an
>>
>> api.Status object).
>>
>> Anyway, please read the attached docs and comment - making apply work with
>>
>> api extensions correctly is a big deal for things like service catalog
>>
>> On Nov 7, 2017, at 2:35 AM, 'Brian Grant' via Kubernetes
>> developer/contributor discussion <kuberne...@googlegroups.com

>> <javascript:>> wrote:

>>
>> On Mon, Nov 6, 2017 at 11:17 PM, <krma...@gmail.com <javascript:>> wrote:
>>
>>> Kubernetes resources are expanding. It would be nice to be able to build
>>>
>>> applications that can use client-go to update all the set of k8s
>>> resources
>>> no matter what, declaratively by just doing client-go.Apply() or
>>> client-go.Update().
>>>
>>> Is that something in the works ? Any issues or pointers to follow ?
>>>
>>
>> Only via actual API support:
>>
>> https://github.com/kubernetes/kubernetes/issues/17333#issuecomment-336732731
>>
>>
>>>
>>> A common set of api across all workload resource types may also be
>>> helpful , which do the following:-
>>> - update
>>> - was the update successful ?
>>> - is the update complete and successfully applied
>>>
>>
>> Agreed that determining success/failure would be useful. It's discussed a
>>
>> little here, but there's no proposal yet:
>>
>> https://docs.google.com/document/d/1cLPGweVEYrVqQvBLJg6sxV-TrE5Rm2MNOBA_cxZP2WU/edit#heading=h.edrnxxvhcni2
>>
>>
>>
>>>
>>> Thoughts from the Kubernetes team ?
>>> Cheers
>>> -Mayank
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>>
>>> "Kubernetes developer/contributor discussion" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>>

>>> email to kubernetes-de...@googlegroups.com <javascript:>.

>>> To post to this group, send email to kuberne...@googlegroups.com

>>> <javascript:>.

>>> To view this discussion on the web visit
>>> https://groups.google.com/d/msgid/kubernetes-dev/0f457e81-1643-47d3-96a0-ba779e8cdcb5%40googlegroups.com
>>>

>>> <https://groups.google.com/d/msgid/kubernetes-dev/0f457e81-1643-47d3-96a0-ba779e8cdcb5%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .

>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>>
>> "Kubernetes developer/contributor discussion" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>>

>> email to kubernetes-de...@googlegroups.com <javascript:>.

>> To post to this group, send email to kuberne...@googlegroups.com

>> <javascript:>.

>> To view this discussion on the web visit

>> https://groups.google.com/d/msgid/kubernetes-dev/CAKCBhs45d%3D_0783C7AkS0m3%2BoahpgHUBo%2BXqpEd5He%2Bd9MB5gQ%40mail.gmail.com
>>
>> <https://groups.google.com/d/msgid/kubernetes-dev/CAKCBhs45d%3D_0783C7AkS0m3%2BoahpgHUBo%2BXqpEd5He%2Bd9MB5gQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .

>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Kubernetes developer/contributor discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kubernetes-de...@googlegroups.com.
> To post to this group, send email to kuberne...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/kubernetes-dev/43a3945f-91ab-4ea9-a394-47cc479468a6%40googlegroups.com.

[krma...@gmail.com]

Hi Michail

I am aware of the conditions. For e.g for the deployment, it shows Available, Progressing, and ReplicaFailure. I think seeing the appearance of Progressing could be interpreted as started, but disappearance or not presence of that condition is not same as Deployment completed. Available only means minimum replicas are available, which means replicas-maxUnavailable are available right ? Let me know if my understanding is wrong here. 

Can i interpret the presence of "Available" condition, to mean all desired replicas are available. In general having one condition showing start and complete of Deployment and StatefulSet would help a lot.

Cheers

Mayank

[Michail Kargakis]

Progressing with a Reason=NewReplicaSetAvailable can be interpreted as
a complete Deployment. Mentioned in the doc I linked in my previous
comment.

On 11/13/17, krma...@gmail.com <krma...@gmail.com> wrote:
> Hi Michail
> I am aware of the conditions. For e.g for the deployment, it shows
> Available, Progressing, and ReplicaFailure. I think seeing the appearance
> of Progressing could be interpreted as started, but disappearance or not
> presence of that condition is not same as Deployment completed. Available
> only means minimum replicas are available, which means
> replicas-maxUnavailable are available right ? Let me know if my
> understanding is wrong here.
>
> Can i interpret the presence of "Available" condition, to mean all desired
> replicas are available. In general having one condition showing start and
> complete of Deployment and StatefulSet would help a lot.
>
> Cheers
> Mayank
>
> On Monday, November 13, 2017 at 1:32:20 AM UTC-8, Michail Kargakis wrote:
>>

>> On 11/12/17, krma...@gmail.com <javascript:> <krma...@gmail.com

>> https://groups.google.com/d/msgid/kubernetes-dev/43a3945f-91ab-4ea9-a394-47cc479468a6%40googlegroups.com.
>>
>>
>> > For more options, visit https://groups.google.com/d/optout.
>> >
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Kubernetes developer/contributor discussion" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to kubernetes-de...@googlegroups.com.
> To post to this group, send email to kuberne...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/kubernetes-dev/eea0da95-e249-4c6c-942d-ef6faabc525a%40googlegroups.com.

[krma...@gmail.com]

Thanks Michael, from the text ,quoted from the link:-

Type=Available with Status=True means that your Deployment has minimum availability. Minimum availability is dictated by the parameters specified in the deployment strategy. Type=Progressing with Status=True means that your Deployment is either in the middle of a rollout and it is progressing or that it has successfully completed its progress and the minimum required new replicas are available (see the Reason of the condition for the particulars - in our case Reason=NewReplicaSetAvailablemeans that the Deployment is complete).

Ok i will test to see if this minimum replicas or all replicas. But looking at three different status fields to figure out if Deployment is complete is odd and also confusing, because the combination Type=Prrogressing, Status=True and Reason =NewReplicaSetAvailable, none of them seem to suggest they are talking about a complete deployment.

If that is the cause should kubectl rollout_status.go code be just changed to only look at conditions and reasons  to figure out if rollout is complete ? 

Having a single field for these things will be less confusing imo.

-Mayank

[Brian Grant]

+relevant SIGs

Re. simple success/failure status: It's more complicated than one might think.

Some of the relevant issues:

https://github.com/kubernetes/kubernetes/issues/7856

https://github.com/kubernetes/kubernetes/issues/34363

https://github.com/kubernetes/kubernetes/issues/30698

Re. apply ownership: SIG CLI and SIG API Machinery.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/ee6b1257-e17f-4b0f-a000-d5b7a14227bd%40googlegroups.com.

[Clayton Coleman]

We had this same problem for TemplateInstances in OpenShift, we wanted to let people wait after a declarative apply until all the objects were "ready" - it tied back to the need for some sort of "wait" command / api semantics, and we opted for a very simple hardcoded list of conditions until we could settle on a correct pattern in Kube.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/ee6b1257-e17f-4b0f-a000-d5b7a14227bd%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAKCBhs4S6LEbqyS_x5HGEagNNoniW21CtAX%2B-Vif-44-Z8n8Hw%40mail.gmail.com.