new document: Declarative Application Management in Kubernetes

[Brian Grant]

This document is a follow on to my previous document, Whitebox COTS application management, and to my SIG Apps presentation on this topic (followup discussion thread).

A publicly viewable link:

https://goo.gl/T66ZcD

Members of kubernete...@googlegroups.com and kubernete...@googlegroups.com should be able to comment.

This document discusses common configuration use cases and pitfalls of common approaches, such as parameterization, in more detail. Goals, requirements, motivations, and so on are also discussed in the document. 

It contains some proposals relating to kubectl, Helm, and potentially other tools.

The central idea is that a toolbox of composable configuration tools should manipulate configuration data in the form of declarative API resource specifications. This should be the core building block upon which more sophisticated deployment mechanisms should be built.

I'd be happy to talk about this at SIG Apps and/or SIG CLI, but there was a lot more to say that could fit into a single hour-long presentation, so I thought I'd start with the document.

[Brian Grant]

Following up.

+ kubernetes-sig-cluster-lifecycle since this could be used for add-on representation

+ kubernetes-sig-api-machinery since we need to extend the OpenAPI spec and some other client-oriented mechanisms

Several people have expressed interest in this proposal. We plan build a standalone prototype to hash out remaining details and try it on some real examples, including some user applications and some cluster add-ons. If you'd like to participate, let me know. If we get enough people across the 4 relevant SIGs, it may make sense to form an official workgroup.

Beyond the prototype, the approach presented in the document builds upon mechanisms we've been building into the API, CLI, and other parts of the system for the past 4 years and shows how they can be used in conjunction. Hopefully this will motivate work to flesh out those mechanisms, fix bug and rough edges and inconsistencies, make them compatible with our API extension mechanisms, and so on.

On Mon, Aug 21, 2017 at 11:30 AM, Brian Grant <brian...@google.com> wrote:

This document is a follow on to my previous document, Whitebox COTS application management, and to my SIG Apps presentation on this topic (followup discussion thread).

A publicly viewable link:

https://goo.gl/T66ZcD

Members of kubernetes-sig-apps@googlegroups.com and kubernetes-sig-cli@googlegroups.com should be able to comment.

[Vic Iglesias]

I'd like to participate by trying to port a subset of our charts (of varying complexities) to this methodology.

On Thu, Sep 7, 2017, 8:00 PM Brian Grant <brian...@google.com> wrote:

Following up.

+ kubernetes-sig-cluster-lifecycle since this could be used for add-on representation

+ kubernetes-sig-api-machinery since we need to extend the OpenAPI spec and some other client-oriented mechanisms

Several people have expressed interest in this proposal. We plan build a standalone prototype to hash out remaining details and try it on some real examples, including some user applications and some cluster add-ons. If you'd like to participate, let me know. If we get enough people across the 4 relevant SIGs, it may make sense to form an official workgroup.

Beyond the prototype, the approach presented in the document builds upon mechanisms we've been building into the API, CLI, and other parts of the system for the past 4 years and shows how they can be used in conjunction. Hopefully this will motivate work to flesh out those mechanisms, fix bug and rough edges and inconsistencies, make them compatible with our API extension mechanisms, and so on.

On Mon, Aug 21, 2017 at 11:30 AM, Brian Grant <brian...@google.com> wrote:

This document is a follow on to my previous document, Whitebox COTS application management, and to my SIG Apps presentation on this topic (followup discussion thread).

A publicly viewable link:

https://goo.gl/T66ZcD

Members of kubernete...@googlegroups.com and kubernete...@googlegroups.com should be able to comment.

[Michael Goodness]

+1

I'm working on a port of the alb-ingress-controller chart that makes use of the tools available today.

[Alexis Richardson]

I am interested in this, and some of our team are @weaveworks.  Please include me initially, and I can involve others over time.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-apps@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/6b97988b-43cc-4cf8-8333-61c20fd1a62f%40googlegroups.com.

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

[Brian Grant]

On Mon, Sep 25, 2017 at 4:57 PM, <ta...@appscode.com> wrote:

I would like to be involved in this project from AppsCode. Is there any formal WG planned yet?

It will be discussed in Wednesday's SIG CLI meeting.

https://github.com/kubernetes/community/tree/master/sig-cli

https://zoom.us/my/sigcli

9am Pacific

 

On Thursday, September 7, 2017 at 8:00:54 PM UTC-7, Brian Grant wrote:

Following up.

+ kubernetes-sig-cluster-lifecycle since this could be used for add-on representation

+ kubernetes-sig-api-machinery since we need to extend the OpenAPI spec and some other client-oriented mechanisms

Several people have expressed interest in this proposal. We plan build a standalone prototype to hash out remaining details and try it on some real examples, including some user applications and some cluster add-ons. If you'd like to participate, let me know. If we get enough people across the 4 relevant SIGs, it may make sense to form an official workgroup.

Beyond the prototype, the approach presented in the document builds upon mechanisms we've been building into the API, CLI, and other parts of the system for the past 4 years and shows how they can be used in conjunction. Hopefully this will motivate work to flesh out those mechanisms, fix bug and rough edges and inconsistencies, make them compatible with our API extension mechanisms, and so on.

On Mon, Aug 21, 2017 at 11:30 AM, Brian Grant <brian...@google.com> wrote:

This document is a follow on to my previous document, Whitebox COTS application management, and to my SIG Apps presentation on this topic (followup discussion thread).

A publicly viewable link:

https://goo.gl/T66ZcD

Members of kubernete...@googlegroups.com and kubernete...@googlegroups.com should be able to comment.

This document discusses common configuration use cases and pitfalls of common approaches, such as parameterization, in more detail. Goals, requirements, motivations, and so on are also discussed in the document. 

It contains some proposals relating to kubectl, Helm, and potentially other tools.

The central idea is that a toolbox of composable configuration tools should manipulate configuration data in the form of declarative API resource specifications. This should be the core building block upon which more sophisticated deployment mechanisms should be built.

I'd be happy to talk about this at SIG Apps and/or SIG CLI, but there was a lot more to say that could fit into a single hour-long presentation, so I thought I'd start with the document.

--
You received this message because you are subscribed to the Google Groups "kubernetes-sig-cluster-lifecycle" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-cluster-lifecycle+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-sig-cluster-life...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-cluster-lifecycle/668a08b3-1c85-423a-939c-b052841934f4%40googlegroups.com.