Hi All, Did i miss a proposal document including leadership and charter?
Sarah On Mon, Nov 7, 2016 at 2:41 AM, Tomasz 'Zen' Napierala < tnapier...@mirantis.com> 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 <jacks....@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-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/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 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/AA73440A-3ED2-4956-A9D3-0F92598E5B8B%40mirantis.com. > For more options, visit https://groups.google.com/d/optout. > -- 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.
