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 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.