Adding new API objects

24 views
Skip to first unread message

Jan Safranek

unread,
Aug 10, 2018, 9:38:21 AM8/10/18
to kubernetes-si...@googlegroups.com
There are rumors that new internal (k8s.io/api) API objects should be
added as CRDs. Is it true? Do we have any documentation / guidelines
around that?

We have some documentation and tribal knowledge how to add "traditional"
API objects and I haven't found anything for CRDs as Kubernetes API.
There are plenty of docs and examples how to use CRDs for external
controllers, I need the internal ones (controller-manager + kubelet).

I identified some gaps between CRD and current API in
https://docs.google.com/document/d/1gbBCU7o72Y-gQnPA38kWqEAd9yBtCPqrG2MmxZyPiw4/

It does not look *that* scary, still it's scary enough considering there
are 3 weeks until code slush. Another question is what gaps did I miss.

Daniel Smith

unread,
Aug 10, 2018, 1:00:49 PM8/10/18
to Jan Safranek, kubernetes-sig-architecture
On Fri, Aug 10, 2018 at 6:38 AM Jan Safranek <jsaf...@redhat.com> wrote:
There are rumors that new internal (k8s.io/api) API objects should be
added as CRDs. Is it true? Do we have any documentation / guidelines
around that?

What do you mean by "internal"?
 
We have some documentation and tribal knowledge how to add "traditional"
API objects and I haven't found anything for CRDs as Kubernetes API.
There are plenty of docs and examples how to use CRDs for external
controllers, I need the internal ones (controller-manager + kubelet).

I identified some gaps between CRD and current API in
https://docs.google.com/document/d/1gbBCU7o72Y-gQnPA38kWqEAd9yBtCPqrG2MmxZyPiw4/

I left some comments.
 


It does not look *that* scary, still it's scary enough considering there
are 3 weeks until code slush. Another question is what gaps did I miss.

--
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/892365ec-93a6-ea41-8abb-9487aab8051b%40redhat.com.
For more options, visit https://groups.google.com/d/optout.

Tim Hockin

unread,
Aug 10, 2018, 2:36:16 PM8/10/18
to Jan Safranek, Kenneth Owens, kubernetes-sig-architecture
On Fri, Aug 10, 2018 at 6:38 AM Jan Safranek <jsaf...@redhat.com> wrote:
>
> There are rumors that new internal (k8s.io/api) API objects should be
> added as CRDs. Is it true? Do we have any documentation / guidelines
> around that?

MOST new APIs are being steered towards CRD. Part of it is to keep
the core growth down. Part of it is actually directional - we'd like
to see even Pod move to a CRD when it is ready. By starting now, we
can build up a body of experience and pressure to make CRD better.

That said, it's sort of the beginning. We have lots of experience
with operators and CRDs + controllers. This shouldn't be THAT
different.

> We have some documentation and tribal knowledge how to add "traditional"
> API objects and I haven't found anything for CRDs as Kubernetes API.
> There are plenty of docs and examples how to use CRDs for external
> controllers, I need the internal ones (controller-manager + kubelet).

Controller manager and kubelet can implement controllers for CRD APIs.
That's not a problem. We do need to build best-practices, as you
pointed yesterday in a different thread, regarding who loads the CRD,
how to handle cases of the CRD disappearing, rollbacks, etc. We can
work to solve those holistically for everyone.

ISTR Ken volunteered to help lead this. :)

> I identified some gaps between CRD and current API in
> https://docs.google.com/document/d/1gbBCU7o72Y-gQnPA38kWqEAd9yBtCPqrG2MmxZyPiw4/

Will take a look and comment.

> It does not look *that* scary, still it's scary enough considering there
> are 3 weeks until code slush. Another question is what gaps did I miss.

Understood. We're not trying to punish anyone, but we have to start somewhere.

Thanks, Jan.

Brian Grant

unread,
Aug 13, 2018, 1:19:19 PM8/13/18
to Tim Hockin, K8s API Machinery SIG, jsaf...@redhat.com, Kenneth Owens, kubernetes-sig-architecture
+K8s API Machinery SIG for visibility

--
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.

Tim Allclair

unread,
Aug 15, 2018, 5:31:59 PM8/15/18
to Brian Grant, Tim Hockin, kubernetes-sig...@googlegroups.com, Jan Safranek, Kenneth Owens, kubernetes-si...@googlegroups.com
@Ken - How would you like to follow up with this? Should we schedule a meeting for QA, or would you prefer a email thread or doc?

Is there a canonical place we should be putting these new CRD APIs? Another repo? k8s.io/api? An arbitrary directory (k8s.io/kubernetes/pkg/kubelet/api)?
Also, is there an existing PR I can copy the boilerplate from?

Tim Allclair

unread,
Aug 15, 2018, 6:33:45 PM8/15/18
to Kenneth Owens, Brian Grant, Tim Hockin, kubernetes-sig...@googlegroups.com, Jan Safranek, kubernetes-sig-architecture
This seems orthogonal to alpha fields? I'd prefer to tackle it in parallel, since I'm blocked on it and we're fast approaching code freeze. But I also want to respect the bandwidth of our API reviewers.

On Wed, Aug 15, 2018 at 2:44 PM Kenneth Owens <owe...@google.com> wrote:
I'll compose a doc with some notes to frame a discussion and send to the mailing list. Do we want to approach this now or wait until we figure out alpha fields. I don't want to over utilize the bandwidth of interested participants. 
Thanks,
     -Ken

Jaice Singer DuMars

unread,
Aug 15, 2018, 6:49:13 PM8/15/18
to tall...@google.com, Kenneth Owens, Brian Grant, Tim Hockin, kubernetes-sig...@googlegroups.com, jsaf...@redhat.com, kubernetes-sig-architecture, kubernetes-a...@googlegroups.com


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


--

Jaice Singer DuMars

Open Source Governance

+1 (206) 371-2293

601 N. 34th St., Seattle WA 98103

Reply all
Reply to author
Forward
0 new messages