Cluster ID API

[Morgan Bauer]

Hello,


In the past I was seeking guidance on approaches to establish a cluster
identifier that could be used to tell to different clusters apart.


I have gone forward with an implementation. I would like to get some
feedback on what you can see below.


The links below are for a short 5 minute discussion and demo.


Currently is installed as part of service catalog API Group, it can be moved.

Once the apiserver and controller are installed and the ID resource is automatically provisioned and set up with a random value.

API machinery can't prevent it from being deleted. I do not currently see a way to implement this without changes in API machinery.

Validation can prevent changes and enforce the singleton by only
allowing one specific name. This is a storage layer function, and is probably the inappropriate place to do this for production. Some API machinery changes may be needed to do this at a higher REST layer.

Discussion on how we can manually set it in theory by controller flag,
or by setting the object before the controller starts.


First link should be a downloadable, second is youtube

https://ibm.box.com/s/znkz2n3hnhcep2rat04q3n0tn9wev1bk

https://www.youtube.com/watch?v=eqI0JqCmxug



I can attend a meeting if further discussion is required, or we can raise it in a service-catalog meeting if that is more helpful.

Thank you

[Stefan Schimanski]

Just to be clear about your setting:

- you are in an aggregated apiserver, this is not CRD based

- you are asking for a way to forbid deletion of objects, but not via RBAC, but through the implemented registry for the resource.

> API machinery can't prevent it from being deleted. I do not currently see a way to implement this without changes in API machinery.

I guess you have tried implement a special Delete method returning a "Cannot be deleted" 40x error?

  https://github.com/kubernetes/kubernetes/blob/2452afffe09e1ced9487e5a701beb1443a92b741/staging/src/k8s.io/apiserver/pkg/registry/rest/rest.go#L147

Best regards,

   Stefan

--
You received this message because you are subscribed to the Google Groups "K8s API Machinery SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-machinery+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-api-machinery@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-api-machinery/eac255e2-db7e-a35f-c754-4abdf5715b21%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Smith]

Better yet, just don't implement the DeleteStrategy.

Best regards,

   Stefan

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-machinery+unsubs...@googlegroups.com.

To post to this group, send email to kubernetes-sig-api-machinery@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-api-machinery/eac255e2-db7e-a35f-c754-4abdf5715b21%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "K8s API Machinery SIG" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-machinery+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-api-machinery@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-api-machinery/CAFtQ%3DdoN5qXrJ1%3DnA05juxDrecg-Mz%3DmdLxA3oN70syuxmaU_A%40mail.gmail.com.

[Stefan Schimanski]

On Thu, Feb 1, 2018 at 5:35 PM, Daniel Smith <dbs...@google.com> wrote:

Better yet, just don't implement the DeleteStrategy.

Depending on whether he uses the generic registry code. But for this special purpose resource maybe that's reasonable.

 

[Daniel Smith]

If you don't want DELETE to ever be an option, then the verb shouldn't installed for the path. Otherwise the OpenAPI spec will be lying to users. Probably POST, PUT, PATCH & WATCH shouldn't be installed either, if it is a system generated immutable read-only informational resource.

I will also admit I'm not super excited about having a singleton resource like this, but that's the nice thing about aggregated APIs / CRDs-- nobody has to be on board for you to experiment :)

Something we're thinking about lately is how to make the control plane "latch" at correct versions, CRDs, aggregated apis, and feature flags. This is likely going to involve some sort of coordination between apiservers in the storage layer. This coordination point would be a natural place to record a unique cluster ID. (It may not be exposed to users directly from there, of course!)

[Christian Bell]

On Thu, Feb 1, 2018 at 9:23 AM, 'Daniel Smith' via kubernetes-sig-multicluster <kubernetes-si...@googlegroups.com> wrote:

I will also admit I'm not super excited about having a singleton resource like this, but that's the nice thing about aggregated APIs / CRDs-- nobody has to be on board for you to experiment :)

Experimentation is great. But let's face it -- this is a lot of work to retrofit a per-cluster UUID that should have been made available from day 0 ;-).

[DL duglin]

big +1 - I was really surprised we didn't already have a UUID we could leverage.

-Doug

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To post to this group, send email to kubernetes-si...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CABnu8_4ojQ1cPWHLkhDKUvesb0kjN9Dp3SNPtxTcJwAJc-%2BysA%40mail.gmail.com.

[Morgan Bauer]

On 1/31/18 11:16 PM, Stefan Schimanski wrote:

Just to be clear about your setting:

- you are in an aggregated apiserver, this is not CRD based

- you are asking for a way to forbid deletion of objects, but not via RBAC, but through the implemented registry for the resource.

Yes.

> API machinery can't prevent it from being deleted. I do not currently see a way to implement this without changes in API machinery.

I guess you have tried implement a special Delete method returning a "Cannot be deleted" 40x error?

  https://github.com/kubernetes/kubernetes/blob/2452afffe09e1ced9487e5a701beb1443a92b741/staging/src/k8s.io/apiserver/pkg/registry/rest/rest.go#L147

I had not seen that code before. At a glance, I'm not sure where we have access to that interface to implement/override the behvior or what it currently even is. My understanding is the only thing exposed at the level I have access to is the RESTDeleteStrategy, which is already 'kubernetesy' and has no implementation beyond "is this an object?". I'll take a more in depth look, but further pointers on how to access that Deleter interface would be helpful.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-m...@googlegroups.com.
To post to this group, send email to kubernetes-sig...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-api-machinery/CAFtQ%3DdoN5qXrJ1%3DnA05juxDrecg-Mz%3DmdLxA3oN70syuxmaU_A%40mail.gmail.com.

[Morgan Bauer]

As far as I understand it, it is the generic registry code. Not sure what the other options are.

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-api-m...@googlegroups.com.
To post to this group, send email to kubernetes-sig...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-api-machinery/CAFtQ%3DdoPnva145jdSRgXp_smCNFeQ43dJVP8c8LzP-WkcYNevA%40mail.gmail.com.