Awesome! Thanks, Dalton. I'll add you to the doc. We had also previously added the CoreOS Bare Metal link you referenced.
JJ. > On Nov 10, 2016, at 12:18 PM, Dalton Hubble <dghub...@gmail.com> wrote: > > 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.
