Hi, Naturally, in such complex ecosystem there will be some overlaps and we already have them. SIG-Apps is a good example, where there is a lot of overlap and at the same time this group is making great job. There is no single component which SIG-Apps covers, it’s not “organic” SIG, but rather group concentrated on certain use cases. Still, it’s one of most productive SIGs in my opinion.
I see on-prem/bare metal SIG with similar role. We are getting feedback from many enterprises that it is extremely hard to have bare metal requirements accepted into kubernetes codebase. We need to remember that after stabilisation period, bare metal use case will be one of the the biggest vehicles for kubernetes adoption, similarly as we’ve observed with other projects (e.g. OpenStack). SIG bare metal would be here to ensure support for those particular cases. For now user experience of running on bare metal is far from being pleasant, and we want it to be perfect. I understand that from business perspective for some companies here this is the last case to support, but we need to be open community and help others engage without hurting core functionality. We cannot discourage people, but rather provide medium to get their cases covered, with proper scrutiny from experts. How could it be organised? I think SIG on-prem would need to take holistic view on bare metal support, work on proposing concrete solutions and then proceed with them through “organic” SIGs like node, storage, networking. There were some individual efforts already, but without SIGs backing them, it is already extremely hard, as I mentioned before. To wrap up, in Mirantis we hope to have this SIG helping our big customers to make their requirements visible and to get proper attention. As a side note recent sprawl should make as think if current governance model is ideal. I think it might be a sign of frustration that many areas are not getting proper attention. At least this is what I hear from different people. Regards, > On 10 Oct 2016, at 16:56, Tim St. Clair <timoth...@gmail.com> wrote: > > Right now this is quite confusing for folks (sig-sprawl), and at some > point we need a rationalization of the SIGs to ensure that there is > enough lead coverage, and to ensure that SIGs have the ability to > execute against a well established charter. > > What is ambiguous, is there are already several sigs that cross over this > topic: > > - Networking > - Storage > - Scale > - Scheduling > ... > etc. > > So where exactly would the responsibilities lie, such that we can > ensure timely execution, and decrease overlap? > > -Tim > > > On Fri, Oct 7, 2016 at 2:07 PM, 'David Oppenheimer' via Kubernetes > developer/contributor discussion <kubernetes-...@googlegroups.com> > wrote: >> It seems that we're on a path to end up with separate sets of SIGs to cover >> use cases/deployment environments, vs. technologies. I'm not sure whether >> that's a good or bad thing. >> >> >> >> On Fri, Oct 7, 2016 at 11:57 AM, Reza Mohammadi <remohamm...@gmail.com> >> wrote: >>> >>> We're also interested to participate. We've created a "Bare-Metal CoreOS >>> Cluster Manager" which boots CoreOS on machines through PXE, and we're using >>> it to provision new machines and add them to our kubernetes clusters: >>> >>> https://github.com/cafebazaar/blacksmith >>> https://github.com/cafebazaar/blacksmith-kubernetes >>> >>> Bests, >>> Reza >>> >>> On Friday, October 7, 2016 at 7:26:36 PM UTC+3:30, Joseph Jacks wrote: >>>> >>>> Hi All, >>>> >>>> >>>> At Apprenda, we have many large clients, OSS efforts and product >>>> initiatives underway to improve the operational experience of running >>>> Kubernetes on bare metal. I thought it would make sense and be useful to >>>> create and start leading a SIG for this area specifically as we are >>>> extremely interested in contributing our ideas, code and best practices >>>> with >>>> the community to improve the usability, documentation, implementation >>>> approaches and standards around designing, deploying and operating >>>> Kubernetes clusters on metal -- specifically in physical private data >>>> center >>>> environments. >>>> >>>> >>>> I see a fair bit of intersection with Cluster-Lifecycle and Cluster-Ops >>>> SIGs, but given the complexities and specific challenges here, it jumped >>>> out >>>> to propose this. >>>> >>>> >>>> A few questions: >>>> >>>> How can we outline objectives of the SIG? >>>> >>>> Use case definitions >>>> Outline problem areas and challenges with existing upstream UX >>>> Major differences in deploying and running on-prem/bare metal vs. on >>>> public cloud compute VMs/instances >>>> ... >>>> >>>> 2. Who is interested in collaborating here? (I know CoreOS has some >>>> exciting projects in this area) >>>> >>>> 3. Anything I am missing? >>>> >>>> >>>> Best, >>>> >>>> JJ. >>>> >>>> >>>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Kubernetes developer/contributor discussion" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to kubernetes-dev+unsubscr...@googlegroups.com. >>> To post to this group, send email to kubernetes-...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/kubernetes-dev/2b4f496e-a802-48b9-8bfc-ed9ae12af58f%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 developer/contributor discussion" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to kubernetes-dev+unsubscr...@googlegroups.com. >> To post to this group, send email to kubernetes-...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/kubernetes-dev/CAOU1bzeDZfs-VUCgoXLzt%3DmkxmmdhK3_u_yprfctYh3aW-Vh0A%40mail.gmail.com. >> >> For more options, visit https://groups.google.com/d/optout. > > > > -- > Cheers, > Timothy St. Clair > > “Do all the good you can. By all the means you can. In all the ways > you can. In all the places you can. At all the times you can. To all > the people you can. As long as ever you can.” > > -- > You received this message because you are subscribed to the Google Groups > "Kubernetes developer/contributor discussion" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to kubernetes-dev+unsubscr...@googlegroups.com. > To post to this group, send email to kubernetes-...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/kubernetes-dev/CALM%2Bqp9Wdsowp5keRcY4Ok_JWwgDUnBxbMFM-ffVa6Z2ke0i8g%40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. -- Tomasz 'Zen' Napierala Kubernetes Engineering - Poland -- You received this message because you are subscribed to the Google Groups "Kubernetes user discussion and Q&A" group. To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-users+unsubscr...@googlegroups.com. To post to this group, send email to kubernetes-users@googlegroups.com. Visit this group at https://groups.google.com/group/kubernetes-users. For more options, visit https://groups.google.com/d/optout.
