--
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.
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.
Better yet, just don't implement the DeleteStrategy.
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 :)
--
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.
If this kind of resource is better implemented at a different
level that abandons some of the existing infrastructure, I've not
got that understanding yet.
As far as not installing various verbs, I'm not sure I've ever
explicitly chosen or not chosen to install them. I honestly have
no idea what mechanism is involved that they end up exposed or not
when building the apiserver that we do have.
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 :)
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/CAB_J3bb9zh3uD-GB_wNTUms5eyHGJ6Og6f6v%3D%3D4NkXsBGdUd-w%40mail.gmail.com.
Best regards,Stefan
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...@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...@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.
--
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-architecture+unsub...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-arch...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/26df07e1-320c-4bb0-8185-041711b8a816%40googlegroups.com.
Best regards,Stefan
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/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-m...@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.
--
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/CAB_J3bb9zh3uD-GB_wNTUms5eyHGJ6Og6f6v%3D%3D4NkXsBGdUd-w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
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/26df07e1-320c-4bb0-8185-041711b8a816%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-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/C908ED97-A636-4FC9-8530-87832DF5AFAC%40gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAEAFPY%2BAzTRiNq3%3DMm8Ei524fLEg%2BgGZfFNrsYc9BftLQjUiHg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CALbx6sZzcZKu6aESmbxKL3Ld9gNgLYyFHcAWyJ8Sy6WovqQhSA%40mail.gmail.com.
--
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-architecture+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CALbx6sZgg4%3DWQ4qD_qNrKscSL_xisaQajfnaH25h8%3DZ10DTdjg%40mail.gmail.com.
IIRC admission allows you to override the UID on create by injecting it into the request context. Though I am not sure you could do that for kube-system. Direct to ETCD is probably simpler.
On Feb 8, 2018 8:36 PM, "Jordan Liggitt" <jlig...@redhat.com> wrote:
> On Feb 8, 2018, at 8:23 PM, DL duglin <dug...@gmail.com> wrote:
>
> Is there an option to set the uid of kube-system namespace during init time?
No, uids are allocated at object creation time deep in storage.
> If we can do that, even going directly to etcd, that's ok - as long as its possible somehow.
That's what you would have to do
--
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-architecture+unsubs...@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CALbx6sZgg4%3DWQ4qD_qNrKscSL_xisaQajfnaH25h8%3DZ10DTdjg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
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-architecture+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAKT2rag3nKEkVfrh70EZW04d7eX%3DYQ8xrdXjv%3Do8sCD5VsX2OA%40mail.gmail.com.
We should probably have a test that verifies that you can set the UID via mutating webhook, or that you get an error if you try, preferably the latter--setting non-unique UIDs is a foot-gun: a good way to completely break your cluster subtly enough that you won't notice for quite some time.Either way it won't help on kube-system, since it must already have been created before you can even add in the webhook configuration. :)
On Sat, Feb 10, 2018 at 9:48 PM, Mo Khan <mo...@redhat.com> wrote:
IIRC admission allows you to override the UID on create by injecting it into the request context. Though I am not sure you could do that for kube-system. Direct to ETCD is probably simpler.--On Feb 8, 2018 8:36 PM, "Jordan Liggitt" <jlig...@redhat.com> wrote:> On Feb 8, 2018, at 8:23 PM, DL duglin <dug...@gmail.com> wrote:
>
> Is there an option to set the uid of kube-system namespace during init time?
No, uids are allocated at object creation time deep in storage.
> If we can do that, even going directly to etcd, that's ok - as long as its possible somehow.
That's what you would have to do
--
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-architecture+unsubs...@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CALbx6sZgg4%3DWQ4qD_qNrKscSL_xisaQajfnaH25h8%3DZ10DTdjg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
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-architecture+unsubs...@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.
I agree, would you like to file an issue to track this?
On Mon, Feb 12, 2018 at 11:02 AM, Mo Khan <mo...@redhat.com> wrote:
Seems like we should just remove the UID override completely. The only safe way to use it is to create a very random + long UID (since you cannot tell what UIDs you have used unless you are tracking it via an external system), so just let the system do it correctly for you.
On Mon, Feb 12, 2018 at 12:19 PM, Daniel Smith <dbs...@google.com> wrote:
We should probably have a test that verifies that you can set the UID via mutating webhook, or that you get an error if you try, preferably the latter--setting non-unique UIDs is a foot-gun: a good way to completely break your cluster subtly enough that you won't notice for quite some time.Either way it won't help on kube-system, since it must already have been created before you can even add in the webhook configuration. :)
On Sat, Feb 10, 2018 at 9:48 PM, Mo Khan <mo...@redhat.com> wrote:
IIRC admission allows you to override the UID on create by injecting it into the request context. Though I am not sure you could do that for kube-system. Direct to ETCD is probably simpler.
On Feb 8, 2018 8:36 PM, "Jordan Liggitt" <jlig...@redhat.com> wrote:
> On Feb 8, 2018, at 8:23 PM, DL duglin <dug...@gmail.com> wrote:
>
> Is there an option to set the uid of kube-system namespace during init time?
No, uids are allocated at object creation time deep in storage.
> If we can do that, even going directly to etcd, that's ok - as long as its possible somehow.
That's what you would have to do
--
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/CALbx6sZgg4%3DWQ4qD_qNrKscSL_xisaQajfnaH25h8%3DZ10DTdjg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
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.
Taking a step back -- anyone see any reason not to use UID as a cluster ID?
On Mon, Feb 12, 2018 at 11:18 AM Daniel Smith <dbs...@google.com> wrote:
I agree, would you like to file an issue to track this?
On Mon, Feb 12, 2018 at 11:02 AM, Mo Khan <mo...@redhat.com> wrote:
Seems like we should just remove the UID override completely. The only safe way to use it is to create a very random + long UID (since you cannot tell what UIDs you have used unless you are tracking it via an external system), so just let the system do it correctly for you.
On Mon, Feb 12, 2018 at 12:19 PM, Daniel Smith <dbs...@google.com> wrote:
We should probably have a test that verifies that you can set the UID via mutating webhook, or that you get an error if you try, preferably the latter--setting non-unique UIDs is a foot-gun: a good way to completely break your cluster subtly enough that you won't notice for quite some time.Either way it won't help on kube-system, since it must already have been created before you can even add in the webhook configuration. :)
On Sat, Feb 10, 2018 at 9:48 PM, Mo Khan <mo...@redhat.com> wrote:
IIRC admission allows you to override the UID on create by injecting it into the request context. Though I am not sure you could do that for kube-system. Direct to ETCD is probably simpler.
On Feb 8, 2018 8:36 PM, "Jordan Liggitt" <jlig...@redhat.com> wrote:
> On Feb 8, 2018, at 8:23 PM, DL duglin <dug...@gmail.com> wrote:
>
> Is there an option to set the uid of kube-system namespace during init time?
No, uids are allocated at object creation time deep in storage.
> If we can do that, even going directly to etcd, that's ok - as long as its possible somehow.
That's what you would have to do
--
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-architecture+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CALbx6sZgg4%3DWQ4qD_qNrKscSL_xisaQajfnaH25h8%3DZ10DTdjg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
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-architecture+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAKT2rag3nKEkVfrh70EZW04d7eX%3DYQ8xrdXjv%3Do8sCD5VsX2OA%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-architecture" group.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-architecture/CAEAFPYLhwJxyEtNYyDT3USx-t5v59DtjyZASD1iy8X6wHvg-Nw%40mail.gmail.com.To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-architecture+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-architecture@googlegroups.com.