I'm happy to help from the CoreOS side. CoreOS docs and Tectonic make use of https://github.com/coreos/coreos-baremetal for bare-metal clusters of all sorts, but there are Kubernetes on bare-metal specific topics which would be interesting to discuss in a SIG.
On Monday, November 7, 2016 at 8:43:57 AM UTC-8, Joseph Jacks wrote: > > Awesome. Thanks, Tomasz! I added you to the SIG charter Google Doc: > https://groups.google.com/forum/#!topic/kubernetes-dev/Uu5bWhJ23II > > On Monday, November 7, 2016 at 5:41:21 AM UTC-5, Tomasz 'Zen' Napierala > wrote: >> >> I’m happy to help leading the SIG from Mirantis side. I would suggest to >> move the conversation to kubernetes-dev. >> >> Regards, >> >> >> > On 07 Nov 2016, at 01:48, Joseph Jacks <jack...@gmail.com> wrote: >> > >> > Excellent. Thanks everyone for chiming in. >> > >> > I count support from the overwhelming majority of folks here from the >> following organizations: Apprenda, Disney, Google, Mirantis, Intel and >> SoundCloud. Very excited to get this off the ground. >> > >> > I will personally co-lead this SIG from Apprenda's side with maybe one >> other rep. If someone would like to co-lead this SIG, please speak up! >> > >> > Please look out for another new note in kubernetes-users announcing SIG >> Bare Metal with a proposed time for our meeting to flesh things out further >> along with goals, etc. >> > >> > Thanks, >> > JJ. >> > >> > On Tuesday, October 11, 2016 at 7:45:47 AM UTC-4, Tomasz Napierala >> wrote: >> > 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 <timo...@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 <kuberne...@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 <remoh...@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-de...@googlegroups.com. >> > >>> To post to this group, send email to kuberne...@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-de...@googlegroups.com. >> > >> To post to this group, send email to kuberne...@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-de...@googlegroups.com. >> > > To post to this group, send email to kuberne...@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 developer/contributor discussion" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to kubernetes-de...@googlegroups.com. >> > To post to this group, send email to kuberne...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/kubernetes-dev/aec44d76-fa24-4a64-92bd-1b1a2529e61c%40googlegroups.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.
