At Kubecon, I have talked to many users, I had several stories about engineers who are trying to get internal adoption but the overall complexity was too high to convince their team/company.
The sig-cluster-lifecycle initiated Kubeadm to dramatically simplify the installation and cluster-management. Being approved, discussed and developed from/with the sig members, kubeadm is a success and reaching its goals.
I would like to see a similar project on the App side.
Writing application configuration isn’t easy, over the year several new resources appeared and it’s going to continue (for the good).
To get something simple as a web-app, users have to write many and long yaml files: ‘deployment.yaml’ / ‘svc.yaml’ / ‘ingress.yaml’ / ‘network-policy.yaml’ / ‘configmap.yaml’ / ‘secret.yaml’, ‘db-deployment.yaml’, ‘db-pvc.yaml’, ‘db-secret.yaml’ …..
On top, there is NO tooling(auto-completion/static-analysis...) to help users.
Template only based solutions are failing to solve this issue, in fact it adds more complexity to gain re-usability.
Brian initiated a discussion about Declarative application configuration on sig-apps (is there already a prototype?) and several projects are in development:
OpenCompose (Red Hat) - Yaml
Kube.libjsonnet (Heptio) - Jsonnet
Kubecfg (Bitnami) - Jsonnet
Kpm (Coreos) - Jsonnet (not in active dev.)
Helm (Deis / community) - Yaml (templating only)
They are all trying to do the same with different (or not so different) approaches and instead of continuing separately I would like to see a converged effort, to work and design it as a group.
How can we progress on this topic ?
Antoine
--
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/CADkr4xk4%2Bxgx%3DHBoLLeDfYT2Cii8YMPm5XxMN7Dr9wsgKhtcew%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsubscribe...@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/CADkr4xk4%2Bxgx%3DHBoLLeDfYT2Cii8YMPm5XxMN7Dr9wsgKhtcew%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-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/CAB6D_VdgD1%3DxmteArscswOkCtmzqMvhR6UrxoJ%2B%3DuYst5D_Ftg%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAB6D_VdgD1%3DxmteArscswOkCtmzqMvhR6UrxoJ%2B%3DuYst5D_Ftg%40mail.gmail.com.
--
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/CAKCBhs5D4ywp-MK%2BBGVKxJefwz%2BAfhsAcFs_REaOxwTQ10ch6g%40mail.gmail.com.
> They are all trying to do the same with different (or not so different)
> approaches and instead of continuing separately I would like to see a
> converged effort, to work and design it as a group.
>
>
> How can we progress on this topic ?
Our (i.e., Heptio's) approach has been to:
- pilot the `kube.libsonnet` solution with a set of partners who each have >10kloc of Kubernetes configuration already written, and
- to reach out to stakeholders of related projects to build assent that the goals Antoine mentions are worth pursuing, and to see where collaboration makes sense
I think it is not controversial to say that none of the solutions Antoine mentions is going to be a silver bullet for all use cases (certainly this is true of `kube.libsonnet`), which is why (2) is an important goal for the group.To this end, we met with Rick Spencer (who I am CC'ing here) and his team at Bitnami last week to begin the formation of a sort of "coalition of the willing" to address these pain points. We've also talked to Pradeep Battacharya (who works on OpenCompose), Fedor Korotkov (who has a Kotlin DSL[1] for the Kubernetes API), and we've reached out to William Butcher (who works on Helm).
Speaking only for myself, it seems to me that this is already fertile ground for collaboration. To me, people seem more interested in solving the problem than in promoting themselves, so I am optimistic that we can find a way to direct these efforts productively.
In my experience, these conversations do seem to go better when there is a specific technical artifact to discuss, and so my proposal for how to move forward is for individual teams to continue the ongoing consolidation effort, and then regroup in with sig-apps when more concrete progress has been made. In particular, I think it's worth blocking time off to talk specifically about the consolidated effort to build a solution that addresses these problems in the sig-apps meeting -- I'm happy to do this myself, or to have anyone in the "coalition" do it instead.Let me know what you all think -- I'm happy to talk more if people have input.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAKCBhs5D4ywp-MK%2BBGVKxJefwz%2BAfhsAcFs_REaOxwTQ10ch6g%40mail.gmail.com.
--__Transcribed by my voice-enabled refrigerator, please pardon chillymessages.
On top, there is NO tooling(auto-completion/static-analysis...) to help users.
Template only based solutions are failing to solve this issue, in fact it adds more complexity to gain re-usability.
Brian initiated a discussion about Declarative application configuration on sig-apps
(is there already a prototype?)
and several projects are in development:
OpenCompose (Red Hat) - Yaml
Kube.libjsonnet (Heptio) - Jsonnet
Kubecfg (Bitnami) - Jsonnet
Kpm (Coreos) - Jsonnet (not in active dev.)
Helm (Deis / community) - Yaml (templating only)
They are all trying to do the same with different (or not so different) approaches and instead of continuing separately I would like to see a converged effort, to work and design it as a group.
How can we progress on this topic ?
Independent of the initial syntax / generation approach, a common declarative deployment flow could also be built. We need one for addon management, if nothing else, and Box has an implementation that they could perhaps open source.
One of the most important decisions in SIG cluster lifecycle was deciding what use case to focus on initially. kubeadm focused on simplifying the "getting-started experience" for building clusters from small numbers of pre-existing nodes. Work on other use cases continued in parallel, with kops, bootkube, kube-aws, kube-up, kargo, etc., though we do need to figure out how to unify at least some of these efforts at some point.In this area, Open Compose and kube.libsonnet similarly seem to be targeted at different use cases.
One of the most important decisions in SIG cluster lifecycle was deciding what use case to focus on initially. kubeadm focused on simplifying the "getting-started experience" for building clusters from small numbers of pre-existing nodes. Work on other use cases continued in parallel, with kops, bootkube, kube-aws, kube-up, kargo, etc., though we do need to figure out how to unify at least some of these efforts at some point.In this area, Open Compose and kube.libsonnet similarly seem to be targeted at different use cases.I'm not sure this chasm is as wide as you seem to think. Both projects attempt to lower the skill floor of getting started with Kubernetes; OpenCompose accomplishes this by creating a new, higher-level API that maps to the Kubernetes API, while `kube.libsonnet` accomplishes this by making the Kubernetes API easier to deal with as it exists. In fact I will go one step farther, and say that I think the goal of creating a higher-level API is actually benefitted by strong templating primitives.
On Tue, Apr 4, 2017 at 10:53 PM, <gus...@gmail.com> wrote:On Wednesday, 5 April 2017 04:50:27 UTC+2, Brian Grant wrote:Independent of the initial syntax / generation approach, a common declarative deployment flow could also be built. We need one for addon management, if nothing else, and Box has an implementation that they could perhaps open source.It's almost trivially obvious, but I have https://github.com/anguslees/kubecfg-updater fwiw. It is literally a shell loop that updates a git checkout and then runs kubectl apply. Improvements / suggestions for what more needs to be done are welcome.(Note this simple approach works in my case partly because I add explicit namespace declarations to all my (generated) json - and enforce this in a unittest)Earlier in the workflow I use jsonnet, some wrapper tools to expand the jsonnet, and do various client-side schema-validation, etc tests. The review side is driven by github and jenkins. I can try to publish / shrink-wrap some of that if people think any of it sounds useful to reuse.- Gus--
__Transcribed by my voice-enabled refrigerator, please pardon chillymessages.
--
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/CAKMv2xyZjLwxAvrOx_LzKy0iNHhnrLE_5Hu8cKi-NG8BrcUSjQ%40mail.gmail.com.
On Tue, Apr 4, 2017 at 11:11 PM, Alex Clemmer <al...@heptio.com> wrote:One of the most important decisions in SIG cluster lifecycle was deciding what use case to focus on initially. kubeadm focused on simplifying the "getting-started experience" for building clusters from small numbers of pre-existing nodes. Work on other use cases continued in parallel, with kops, bootkube, kube-aws, kube-up, kargo, etc., though we do need to figure out how to unify at least some of these efforts at some point.In this area, Open Compose and kube.libsonnet similarly seem to be targeted at different use cases.I'm not sure this chasm is as wide as you seem to think. Both projects attempt to lower the skill floor of getting started with Kubernetes; OpenCompose accomplishes this by creating a new, higher-level API that maps to the Kubernetes API, while `kube.libsonnet` accomplishes this by making the Kubernetes API easier to deal with as it exists. In fact I will go one step farther, and say that I think the goal of creating a higher-level API is actually benefitted by strong templating primitives.I was specifically referring to stated goals:OpenCompose:The main goal for OpenCompose is to be easy to use application/microservice definition that developers can use without learning much of Kubernetes concepts. It should be very easy to write a simple application definition and from there on the tooling takes over.kube.libsonnet:pilot the `kube.libsonnet` solution with a set of partners who each have >10kloc of Kubernetes configuration already written
On Tue, Apr 4, 2017 at 10:53 PM, <gus...@gmail.com> wrote:On Wednesday, 5 April 2017 04:50:27 UTC+2, Brian Grant wrote:Independent of the initial syntax / generation approach, a common declarative deployment flow could also be built. We need one for addon management, if nothing else, and Box has an implementation that they could perhaps open source.It's almost trivially obvious, but I have https://github.com/anguslees/kubecfg-updater fwiw. It is literally a shell loop that updates a git checkout and then runs kubectl apply. Improvements / suggestions for what more needs to be done are welcome.(Note this simple approach works in my case partly because I add explicit namespace declarations to all my (generated) json - and enforce this in a unittest)Earlier in the workflow I use jsonnet, some wrapper tools to expand the jsonnet, and do various client-side schema-validation, etc tests. The review side is driven by github and jenkins. I can try to publish / shrink-wrap some of that if people think any of it sounds useful to reuse.- Gus--__Transcribed by my voice-enabled refrigerator, please pardon chillymessages.
--
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+unsubscribe...@googlegroups.com.
To post to this group, send email to kubernetes-sig-apps@googlegroups.com.
Work on other use cases continued in parallel, with kops, bootkube, kube-aws, kube-up, kargo, etc., though
we do need to figure out how to unify at least some of these efforts at some point.
Continuing work in parallel is essential, each tool are exploring different paths which is great to get a better view.
Independent of the initial syntax / generation approach, a common declarative deployment flow could also be built.
Yes, both(configuration / management) are parts of the project
In this area, Open Compose and kube.libsonnet similarly seem to be targeted at different use cases.
They target different use cases but in my opinion are complementary.
if we agree on some technical designs and approaches, they can be developed separately and still be merged nicely on the user side
random example:
# Higher level API (opencompose / kubectl generator like)
svc, ingress, deployment = createService(image: “myapp”, port: 80, domain: “myapp.example.com”)
# Extend if necessary (kube.libsonnet like)
deployment.readinessProbe + probe.Http(port: 80, delay: 30, period: 10)
some kind of round table where we can discuss what problems we were trying to solve, and how our efforts to dates did or did not help achieve that effort. Perhaps, from that, we could extract the commonality in goals and approaches, and this could inform the next step in terms of writing code?
Sounds great ! thanks to propose it
(generally between 9am and 10am PT works well across timezones)
--
Antoine
Work on other use cases continued in parallel, with kops, bootkube, kube-aws, kube-up, kargo, etc., though
we do need to figure out how to unify at least some of these efforts at some point.Continuing work in parallel is essential, each tool are exploring different paths which is great to get a better view.
Independent of the initial syntax / generation approach, a common declarative deployment flow could also be built.Yes, both(configuration / management) are parts of the project
some kind of round table where we can discuss what problems we were trying to solve, and how our efforts to dates did or did not help achieve that effort. Perhaps, from that, we could extract the commonality in goals and approaches, and this could inform the next step in terms of writing code?
Sounds great ! thanks to propose it (generally between 9am and 10am PT works well across timezones)
On Tue, Apr 4, 2017 at 11:11 PM, Alex Clemmer <al...@heptio.com> wrote:One of the most important decisions in SIG cluster lifecycle was deciding what use case to focus on initially. kubeadm focused on simplifying the "getting-started experience" for building clusters from small numbers of pre-existing nodes. Work on other use cases continued in parallel, with kops, bootkube, kube-aws, kube-up, kargo, etc., though we do need to figure out how to unify at least some of these efforts at some point.In this area, Open Compose and kube.libsonnet similarly seem to be targeted at different use cases.I'm not sure this chasm is as wide as you seem to think. Both projects attempt to lower the skill floor of getting started with Kubernetes; OpenCompose accomplishes this by creating a new, higher-level API that maps to the Kubernetes API, while `kube.libsonnet` accomplishes this by making the Kubernetes API easier to deal with as it exists. In fact I will go one step farther, and say that I think the goal of creating a higher-level API is actually benefitted by strong templating primitives.I was specifically referring to stated goals:OpenCompose:The main goal for OpenCompose is to be easy to use application/microservice definition that developers can use without learning much of Kubernetes concepts. It should be very easy to write a simple application definition and from there on the tooling takes over.
kube.libsonnet:pilot the `kube.libsonnet` solution with a set of partners who each have >10kloc of Kubernetes configuration already written
Hi Alex,I appreciate you looping me in. I think perhaps a good first step is a meeting of the minds in terms of what people have developed so far. To that end, Gus (added to To:) is working this week to move his jsonnet library to a Bitnami repo, and then write some kind of blog post to go along with the documentation.
--
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/CAKMv2xyTmaWuCUZjFUHdVm7Tzpjgo7V8ra_TkTrhDEJiXWXx5w%40mail.gmail.com.
Same here, I won't be at DockerCon. I can dial in as well.Pradeepto
On Fri, Apr 7, 2017 at 9:59 PM, Alex Clemmer <al...@heptio.com> wrote:
I won't be there but I'm happy to dial in.On Fri, Apr 7, 2017 at 9:25 AM, Rick Spencer <ri...@bitnami.com> wrote:On Thu, Apr 6, 2017 at 4:51 AM, Pradeepto Bhattacharya <prad...@redhat.com> wrote:Hi,On Thu, Apr 6, 2017 at 6:18 AM, Antoine Legrand <antoine...@coreos.com> wrote:
some kind of round table where we can discuss what problems we were trying to solve, and how our efforts to dates did or did not help achieve that effort. Perhaps, from that, we could extract the commonality in goals and approaches, and this could inform the next step in terms of writing code?
Sounds great ! thanks to propose it (generally between 9am and 10am PT works well across timezones)
Sounds great! We would love to be part of this round-table. Would be awesome if we can get this done sooner than later. How does sometime next week sound for all who would like to attend this? Please note, I am in IST (GMT +5:30).I bet that some or many of us may be at DockerCon the week after next, and therefore some of us could meet face to face and dial in others for such a discussion. Thoughts?--__Transcribed by my voice-enabled refrigerator, please pardon chillymessages.
--
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 kubernete...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAKMv2xyTmaWuCUZjFUHdVm7Tzpjgo7V8ra_TkTrhDEJiXWXx5w%40mail.gmail.com.
--Pradeepto Bhattacharya
Same here, I won't be at DockerCon. I can dial in as well.Pradeepto
On Fri, Apr 7, 2017 at 9:59 PM, Alex Clemmer <al...@heptio.com> wrote:
I won't be there but I'm happy to dial in.On Fri, Apr 7, 2017 at 9:25 AM, Rick Spencer <ri...@bitnami.com> wrote:On Thu, Apr 6, 2017 at 4:51 AM, Pradeepto Bhattacharya <prad...@redhat.com> wrote:Hi,On Thu, Apr 6, 2017 at 6:18 AM, Antoine Legrand <antoine...@coreos.com> wrote:
some kind of round table where we can discuss what problems we were trying to solve, and how our efforts to dates did or did not help achieve that effort. Perhaps, from that, we could extract the commonality in goals and approaches, and this could inform the next step in terms of writing code?
Sounds great ! thanks to propose it (generally between 9am and 10am PT works well across timezones)
Sounds great! We would love to be part of this round-table. Would be awesome if we can get this done sooner than later. How does sometime next week sound for all who would like to attend this? Please note, I am in IST (GMT +5:30).I bet that some or many of us may be at DockerCon the week after next, and therefore some of us could meet face to face and dial in others for such a discussion. Thoughts?--__Transcribed by my voice-enabled refrigerator, please pardon chillymessages.
--
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+unsubscribe...@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/CAKMv2xyTmaWuCUZjFUHdVm7Tzpjgo7V8ra_TkTrhDEJiXWXx5w%40mail.gmail.com.
--Pradeepto Bhattacharya
Following up on this thread,I have PMed with a few folks here and we have set out a call for 9am PST time tomorrow (April 25th). We scheduled it to be on a hangout. We scheduled it around the available of a few people's specific schedules, but we are happy to have anyone else interested join us, of course. I will set the hangout to be public.Please let me know if you would like to attend or have any other suggestions. We will follow up here with the notes from the call just in case others are interested.Cheers, Rick
On Fri, Apr 7, 2017 at 12:54 PM, Pradeepto Bhattacharya <prad...@redhat.com> wrote:
Same here, I won't be at DockerCon. I can dial in as well.Pradeepto
On Fri, Apr 7, 2017 at 9:59 PM, Alex Clemmer <al...@heptio.com> wrote:
I won't be there but I'm happy to dial in.On Fri, Apr 7, 2017 at 9:25 AM, Rick Spencer <ri...@bitnami.com> wrote:On Thu, Apr 6, 2017 at 4:51 AM, Pradeepto Bhattacharya <prad...@redhat.com> wrote:Hi,On Thu, Apr 6, 2017 at 6:18 AM, Antoine Legrand <antoine...@coreos.com> wrote:
some kind of round table where we can discuss what problems we were trying to solve, and how our efforts to dates did or did not help achieve that effort. Perhaps, from that, we could extract the commonality in goals and approaches, and this could inform the next step in terms of writing code?
Sounds great ! thanks to propose it (generally between 9am and 10am PT works well across timezones)
Sounds great! We would love to be part of this round-table. Would be awesome if we can get this done sooner than later. How does sometime next week sound for all who would like to attend this? Please note, I am in IST (GMT +5:30).I bet that some or many of us may be at DockerCon the week after next, and therefore some of us could meet face to face and dial in others for such a discussion. Thoughts?--__Transcribed by my voice-enabled refrigerator, please pardon chillymessages.
--
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-...@googlegroups.com.
To post to this group, send email to kubernete...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAKMv2xyTmaWuCUZjFUHdVm7Tzpjgo7V8ra_TkTrhDEJiXWXx5w%40mail.gmail.com.
----Pradeepto Bhattacharya
You received this message because you are subscribed to a topic in the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kubernetes-sig-apps/cRpBZHZsnOo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kubernetes-sig-...@googlegroups.com.
To post to this group, send email to kubernete...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAE_Xj4PUHNL3QN65duYy%3Deb%2BKQgtDTepFFx7B9%2BYL_qH98YNug%40mail.gmail.com.
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/CAKMv2xyTmaWuCUZjFUHdVm7Tzpjgo7V8ra_TkTrhDEJiXWXx5w%40mail.gmail.com.
----Pradeepto Bhattacharya
You received this message because you are subscribed to a topic in the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kubernetes-sig-apps/cRpBZHZsnOo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kubernetes-sig-apps+unsub...@googlegroups.com.
To post to this group, send email to kubernetes-sig-apps@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsubscribe...@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/CAKMv2xyTmaWuCUZjFUHdVm7Tzpjgo7V8ra_TkTrhDEJiXWXx5w%40mail.gmail.com.
----Pradeepto Bhattacharya
You received this message because you are subscribed to a topic in the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kubernetes-sig-apps/cRpBZHZsnOo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kubernetes-sig-apps+unsubscribe...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsubscribe...@googlegroups.com.
To post to this group, send email to kubernete...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAKMv2xyTmaWuCUZjFUHdVm7Tzpjgo7V8ra_TkTrhDEJiXWXx5w%40mail.gmail.com.
--Pradeepto Bhattacharya
--
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/2239d566-cb90-4e47-b0df-aa976ab8ec51%40googlegroups.com.
+SIG Service Catalog, which is trying to address some of these challenges
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/2239d566-cb90-4e47-b0df-aa976ab8ec51%40googlegroups.com.
--
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/CAKCBhs6rv2D8p0VhS8ftvjubONA3c%3Dr1qjU4aSp2CqZqVRBBNA%40mail.gmail.com.
Just as a reminder to everyone, it's 0900 PST / 1200 EST on https://hangouts.google.com/hangouts/_/bitnami.com/k8s-config?authuser=0
2. We will strive to create a jsonnet library that can be used to create an accessible first time use experience, but that can be also expanded to support complex customer deployments. The way to accomplish this is by always building from the Kubernetes API.
1. Design and build a jsonnet library that is easy to use and understand and get started, but is demonstrably easy to expand all the way to the K8s API. This wills tart with a phase to compre individual projects and agree on the general approach.(Gus, Alex, John, Pradeepto, Antoine)
4. Packaging jsonnet itself for distros.(Gus/Debian, Pradeepto/RPM)
>> 1. Design and build a jsonnet library that is easy to use and understand
>> and get started, but is demonstrably easy to expand all the way to the K8s
>> API. This wills tart with a phase to compre individual projects and agree on
>> the general approach.
>> (Gus, Alex, John, Pradeepto, Antoine)
>
> A jsonnet library for Go? Or a library of base clases for Kubernetes?
A Jsonnet library for Go. The terminology around having "base classes"
in the Jsonnet library comes from the fact that Jsonnet uses (and I
say this with love) the hipster OOP idea of a _mixin_.
On Tue, Apr 25, 2017 at 4:31 PM, Brandon Philips
<brandon...@coreos.com> wrote:
> On Tue, Apr 25, 2017 at 2:06 PM Rick Spencer <ri...@bitnami.com> wrote:
>> 4. Packaging jsonnet itself for distros.
>> (Gus/Debian, Pradeepto/RPM)
>
> What about homebrew, etc?
Hi everyone,
At Kubecon, I have talked to many users, I had several stories about engineers who are trying to get internal adoption but the overall complexity was too high to convince their team/company.
The sig-cluster-lifecycle initiated Kubeadm to dramatically simplify the installation and cluster-management. Being approved, discussed and developed from/with the sig members, kubeadm is a success and reaching its goals.
I would like to see a similar project on the App side.
Writing application configuration isn’t easy, over the year several new resources appeared and it’s going to continue (for the good).
To get something simple as a web-app, users have to write many and long yaml files: ‘deployment.yaml’ / ‘svc.yaml’ / ‘ingress.yaml’ / ‘network-policy.yaml’ / ‘configmap.yaml’ / ‘secret.yaml’, ‘db-deployment.yaml’, ‘db-pvc.yaml’, ‘db-secret.yaml’ …..
On top, there is NO tooling(auto-completion/static-analysis...) to help users.Template only based solutions are failing to solve this issue, in fact it adds more complexity to gain re-usability.
Brian initiated a discussion about Declarative application configuration on sig-apps (is there already a prototype?) and several projects are in development:
OpenCompose (Red Hat) - Yaml
Kube.libjsonnet (Heptio) - Jsonnet
Kubecfg (Bitnami) - Jsonnet
Kpm (Coreos) - Jsonnet (not in active dev.)
Helm (Deis / community) - Yaml (templating only)
They are all trying to do the same with different (or not so different) approaches and instead of continuing separately I would like to see a converged effort, to work and design it as a group.
How can we progress on this topic ?
Antoine
Generating yamls is great and we have have tool for that; very simple yaml files with placeholder and a bit of SED. So any of these approaches would be a big step forward but also require a bigger learning curve.
Use case: In this particular project i needed to replicate application stacks across different clusters to achieve a private version of the multi tenant stack. So we needed a tool to keep most of the yamls the same, with small differences in things like ENV vars. Every environment has a 'manifest' that describes the branch/commit/tag of each container in the stack. CI/CD propagates a commit from the testing manifest to the staging and then prod manifests, when tests succeed.
In my experience, the generating of the files happens infrequently, at the beginning of a new part of the stack. I don't mind doing 'some' manual work to set up a config that works across all the different clusters. What I need multiple times a day is a way to take this manifest and compare it to the cluster and update what is necessary. We do this with an 'apply.rb' that interrogates the cluster for the current state, compares with the manifest and deploys a new container if needed. TODO also take yaml changes into consideration and kubectl apply those.I was trying to find out if any of these tools take this extra step or is that something out of scope?
On Tuesday, April 4, 2017 at 4:27:11 PM UTC+2, Antoine Legrand wrote:Hi everyone,
At Kubecon, I have talked to many users, I had several stories about engineers who are trying to get internal adoption but the overall complexity was too high to convince their team/company.
The sig-cluster-lifecycle initiated Kubeadm to dramatically simplify the installation and cluster-management. Being approved, discussed and developed from/with the sig members, kubeadm is a success and reaching its goals.
I would like to see a similar project on the App side.
Writing application configuration isn’t easy, over the year several new resources appeared and it’s going to continue (for the good).
To get something simple as a web-app, users have to write many and long yaml files: ‘deployment.yaml’ / ‘svc.yaml’ / ‘ingress.yaml’ / ‘network-policy.yaml’ / ‘configmap.yaml’ / ‘secret.yaml’, ‘db-deployment.yaml’, ‘db-pvc.yaml’, ‘db-secret.yaml’ …..
On top, there is NO tooling(auto-completion/static-analysis...) to help users.Template only based solutions are failing to solve this issue, in fact it adds more complexity to gain re-usability.
Brian initiated a discussion about Declarative application configuration on sig-apps (is there already a prototype?) and several projects are in development:
OpenCompose (Red Hat) - Yaml
Kube.libjsonnet (Heptio) - Jsonnet
Kubecfg (Bitnami) - Jsonnet
Kpm (Coreos) - Jsonnet (not in active dev.)
Helm (Deis / community) - Yaml (templating only)
They are all trying to do the same with different (or not so different) approaches and instead of continuing separately I would like to see a converged effort, to work and design it as a group.
How can we progress on this topic ?
Antoine
--
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/76163ae9-3213-4466-baa9-3b3bec1654b1%40googlegroups.com.
Generating yamls is great and we have have tool for that; very simple yaml files with placeholder and a bit of SED. So any of these approaches would be a big step forward but also require a bigger learning curve.Use case: In this particular project i needed to replicate application stacks across different clusters to achieve a private version of the multi tenant stack. So we needed a tool to keep most of the yamls the same, with small differences in things like ENV vars. Every environment has a 'manifest' that describes the branch/commit/tag of each container in the stack. CI/CD propagates a commit from the testing manifest to the staging and then prod manifests, when tests succeed.In my experience, the generating of the files happens infrequently, at the beginning of a new part of the stack. I don't mind doing 'some' manual work to set up a config that works across all the different clusters. What I need multiple times a day is a way to take this manifest and compare it to the cluster and update what is necessary. We do this with an 'apply.rb' that interrogates the cluster for the current state, compares with the manifest and deploys a new container if needed. TODO also take yaml changes into consideration and kubectl apply those.I was trying to find out if any of these tools take this extra step or is that something out of scope?
On Tuesday, April 4, 2017 at 4:27:11 PM UTC+2, Antoine Legrand wrote:Hi everyone,
At Kubecon, I have talked to many users, I had several stories about engineers who are trying to get internal adoption but the overall complexity was too high to convince their team/company.
The sig-cluster-lifecycle initiated Kubeadm to dramatically simplify the installation and cluster-management. Being approved, discussed and developed from/with the sig members, kubeadm is a success and reaching its goals.
I would like to see a similar project on the App side.
Writing application configuration isn’t easy, over the year several new resources appeared and it’s going to continue (for the good).
To get something simple as a web-app, users have to write many and long yaml files: ‘deployment.yaml’ / ‘svc.yaml’ / ‘ingress.yaml’ / ‘network-policy.yaml’ / ‘configmap.yaml’ / ‘secret.yaml’, ‘db-deployment.yaml’, ‘db-pvc.yaml’, ‘db-secret.yaml’ …..
On top, there is NO tooling(auto-completion/static-analysis...) to help users.Template only based solutions are failing to solve this issue, in fact it adds more complexity to gain re-usability.
Brian initiated a discussion about Declarative application configuration on sig-apps (is there already a prototype?) and several projects are in development:
OpenCompose (Red Hat) - Yaml
Kube.libjsonnet (Heptio) - Jsonnet
Kubecfg (Bitnami) - Jsonnet
Kpm (Coreos) - Jsonnet (not in active dev.)
Helm (Deis / community) - Yaml (templating only)
They are all trying to do the same with different (or not so different) approaches and instead of continuing separately I would like to see a converged effort, to work and design it as a group.
How can we progress on this topic ?
Antoine
--
You received this message because you are subscribed to a topic in the Google Groups "kubernetes-sig-apps" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/kubernetes-sig-apps/cRpBZHZsnOo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to kubernetes-sig-...@googlegroups.com.
To post to this group, send email to kubernete...@googlegroups.com.
On Sat, Apr 29, 2017 at 3:45 PM, <al...@cobrowser.net> wrote:Generating yamls is great and we have have tool for that; very simple yaml files with placeholder and a bit of SED. So any of these approaches would be a big step forward but also require a bigger learning curve.We have kubectl commands that help with generating manifests (kubectl run, kubectl expose, kubectl autoscale, kubectl create {deployment, configmap, and others}. I would love to see more contributions on that front.
--
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/4261b54d-ef9c-4788-99b2-da1644648d90%40googlegroups.com.
the emergence of configuration languages on top of k8s config
the proliferation of tools
IMO it's worth thinking if the tools
Essentially kubegen uses a simpler format for manifests. Use can update the source with any extra fields, then re-run kubegen and check-in the output.
Regarding Jsonnet, I find that it's model is really neat, but it's yet another syntax for someone to learn and it's not a simple one, it can easily get quite ambiguous and too abstract for someone to understand what particular implementation actually does.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsubscribe...@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/4261b54d-ef9c-4788-99b2-da1644648d90%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-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/CAB6D_Vc2yw9u6snJdTzwJEprOfJfCgGEUKsReidekeGY0kJwDg%40mail.gmail.com.
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 kubernete...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/4261b54d-ef9c-4788-99b2-da1644648d90%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-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 kubernete...@googlegroups.com.
the emergence of configuration languages on top of k8s configI think tools like kubegen / opencompose are a declarative alternative to 'kubectl run ...', 'kubectl create configmap..' they capture most newcomer usecases.
the proliferation of toolsSome of them are taking similar path and overlap, this is one of the goal of this thread, gathering effort.
IMO it's worth thinking if the toolsMore than the tooling, we should think of the (declarative) configuration that users will face and how they can iterate and share it.I'm convinced that we can bridge simple use-cases and complex ones.
Speaking the tooling and workflow management, it could done by kubectl, a TPR controller, tiller / tiller-like server-side, helm client (via plugins)... and more.Essentially kubegen uses a simpler format for manifests. Use can update the source with any extra fields, then re-run kubegen and check-in the output.It looks very close to OpenCompose, maybe you can share ideas with them.
Regarding Jsonnet, I find that it's model is really neat, but it's yet another syntax for someone to learn and it's not a simple one, it can easily get quite ambiguous and too abstract for someone to understand what particular implementation actually does.
I agree, I think we should keep jsonnet configuration obvious, simple and close to yaml/json.
Only a subset of its features should be exposed to users.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.
To post to this group, send email to kubernete...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/4261b54d-ef9c-4788-99b2-da1644648d90%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-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.
To post to this group, send email to kubernete...@googlegroups.com.
Premature standardisation would be really bad idea right now :)
Perhaps we could try figuring out what the subset is and attempt implementing just that in Go.
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/4261b54d-ef9c-4788-99b2-da1644648d90%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-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 unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsubscribe...@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/4261b54d-ef9c-4788-99b2-da1644648d90%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-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-apps+unsubscribe...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAB6D_Vc2yw9u6snJdTzwJEprOfJfCgGEUKsReidekeGY0kJwDg%40mail.gmail.com.
--
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/CADkr4x%3D1XJ3UZOG-OShky8-yM2TtiaDVR3FgN%3DbrPsswzWKKiA%40mail.gmail.com.
FWIW, some (fairly arbitrary) non-K8s examples:Azure Resource Manager Jenkins example:
Mesosphere Universe Jenkins example:
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.
To post to this group, send email to kubernete...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/4261b54d-ef9c-4788-99b2-da1644648d90%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-apps" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-sig-...@googlegroups.com.
To post to this group, send email to kubernete...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAB6D_Vc2yw9u6snJdTzwJEprOfJfCgGEUKsReidekeGY0kJwDg%40mail.gmail.com.
--
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-...@googlegroups.com.
To post to this group, send email to kubernete...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CADkr4x%3D1XJ3UZOG-OShky8-yM2TtiaDVR3FgN%3DbrPsswzWKKiA%40mail.gmail.com.
--
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-...@googlegroups.com.
To post to this group, send email to kubernete...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-sig-apps/CAKCBhs65q7XjhRaetaVJhLVK1DZ6VTMsBNTWaYRHruX%3DDfOYbg%40mail.gmail.com.