Re: new document: Declarative Application Management in Kubernetes

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

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.

[Jimmy Zelinskie]

Hi Brian,

I'd be happy to represent the interests from the CoreOS perspective.

We've built and contributed to many related projects and are very interested in helping guide this effort.

On Thursday, September 7, 2017 at 11:00:54 PM UTC-4, 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.

[Lucas Käldström]

I'm interested in starting to spec out the Addons API if we have enough quorum of other people to make that happen.

[Aaron Levy]

I would also be interested in exploring a similar process for managing upgrades + customizations of self-hosted clusters.

--
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/f2ec8e21-a56b-484b-8dee-f2e726a018c8%40googlegroups.com.

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

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited.

[ta...@appscode.com]

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

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.

[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

 

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

[ta...@appscode.com]

Thanks Brian. I have been also thinking about this based on our experience using Helm as a Kubernetes tools developer. I wrote a doc summarizing my thoughts on this. One additional idea in my doc is that instead of creating another "registry" for Kubernetes YAMLs, just do something simple like GO. Any git repo can be a registry with automated versioning via git. 

https://docs.google.com/document/d/10568IACIk_F1aeSFkuBiTzsP6gZg6h3S3oIWrebAAZQ/edit?ts=598247f2