[kubernetes-users] Re: Bare Metal SIG

[Sandeep Srinivasa]

On Nov 29, 2016 10:40 PM, "Justin Garrison" <
justin.garri...@disneyanimation.com> wrote:

I think the smaller focus is why sig aws and sig openstack already exist.
They are trying to focus on the implementation of that specific platform
and not abstract or long term cluster management.


precisely. and i would argue that bare metal poses an even bigger
platform-specific challenge.  How do you build a cluster without depending
on VPC/ELB/EBS, etc.

If sig-aws has a reason to exist, then so does sig-metal. People who use
the cloud have (justifiably)  no interest in mechanics that will be
mandatory in bare metal - like choice of load balancers, networking across
data centers, etc

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" 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.

Re: [kubernetes-users] Re: Bare Metal SIG

[Rob Hirschfeld]

Just for clarity: there are TWO SIGs here: cluster-lifecycle and cluster
ops.

Lifecycle is focused on kubeadm development that impact future releases
(Tuesday meetings)
Cluster Ops is focused on operational concerns (including metal) around
current releases (Thursday meetings)



On Tue, Nov 29, 2016 at 9:11 AM Justin Garrison <
justin.garri...@disneyanimation.com> wrote:

> Everyone interested in the bare metal sig should also join cluster
> lifecycle. No questions IMO. But I think the sigs have different goals.
> Cluster lifecycle from my experience (I've only joined a few calls) is more
> abstracted towards best practices and maintaining a cluster. There are
> occasionally topics around specific deployments or user experience problems
> but I don't think cluster lifecycle should try to focus on the minutiae
> that a environment specific SIG should focus on. I also don't want bare
> metal to focus on cluster hygiene or long term maintenance.
>
> I think the smaller focus is why sig aws and sig openstack already exist.
> They are trying to focus on the implementation of that specific platform
> and not abstract or long term cluster management.
>
> On Monday, November 28, 2016 at 8:42:24 PM UTC-8, Rob Hirschfeld wrote:
>
> Cluster-lifecycle is not about ops.  they are building configuration tools
> and the maintainer of kops is there.
> Cluster Ops is a different SIG.  Is that the confusion?
>
> I don't know how to be any more inviting - we have an existing SIG where
> we talk about running clusters on cloud AND metal using multiple tools.  We
> document architectures and best practices.  We are about to focus on
> upgrades and conformance tests.  Join if you want.
>
> On Mon, Nov 28, 2016 at 10:35 PM Sandeep Srinivasa 
> wrote:
>
> actually the bigger point is that sig-cluster-lifecycle is NOT the  bare
> metal sig or at least that's the impression one gets generally.
>
> we'll go anywhere where we can find help ;) for now Kargo is seemingly the
> place that'll take us in!
>
> On Nov 29, 2016 09:59, "Rob Hirschfeld"  wrote:
>
> Kargo was an earlier Ansible set and did a good job.  I used it for the
> v1.2 release,
> Of course, the Kargo channel will position that way!
> Are you suggesting that the Bare Metal SIG is really the Kargo SIG?
>
> On Mon, Nov 28, 2016 at 10:26 PM Sandeep Srinivasa 
> wrote:
>
> hi Rob
> Thanks for trying. And i will probably join cluster ops.
>
> But I hope you will ACKNOWLEDGE that this situation already exists. If you
> search on slack as early as yesterday evening,  the #kargo statement was
> reiterated.
> You may be right technically in claiming other ways exist... but this is
> the way that the community has *already * begun to shift.
>
> Regards
> Sandeep
>
>
>
>
> On Nov 29, 2016 09:46, "Rob Hirschfeld"  wrote:
>
> Sandeep,
>
> 1) we are dividing efforts.  Why don't you TRY joining Cluster Ops before
> forking it.
> 2) Kargo or KOPS is absolutely NOT the only tool.  Cluster Ops
> specifically explores multiple appoaches.  There are many ways to do this
> and they have different reasons.
>
> I simply don't understand the push to not even try to join.
>
> Rob
>
>
> --
> Rob Hirschfeld
> RackN.com, CEO & Founder
> @zehicle, 512-773-7522
>
> --
> Rob Hirschfeld
> RackN.com, CEO & Founder
> @zehicle, 512-773-7522 <(512)%20773-7522>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Kubernetes user discussion and Q" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/kubernetes-users/i3XTbJvLj38/unsubscribe
> .
> To unsubscribe from this group and all its topics, 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.
>
-- 
Rob Hirschfeld
RackN.com, CEO & Founder
@zehicle, 512-773-7522

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" 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.

[kubernetes-users] Re: Bare Metal SIG

[Justin Garrison]

Everyone interested in the bare metal sig should also join cluster 
lifecycle. No questions IMO. But I think the sigs have different goals. 
Cluster lifecycle from my experience (I've only joined a few calls) is more 
abstracted towards best practices and maintaining a cluster. There are 
occasionally topics around specific deployments or user experience problems 
but I don't think cluster lifecycle should try to focus on the minutiae 
that a environment specific SIG should focus on. I also don't want bare 
metal to focus on cluster hygiene or long term maintenance.

I think the smaller focus is why sig aws and sig openstack already exist. 
They are trying to focus on the implementation of that specific platform 
and not abstract or long term cluster management.

On Monday, November 28, 2016 at 8:42:24 PM UTC-8, Rob Hirschfeld wrote:
>
> Cluster-lifecycle is not about ops.  they are building configuration tools 
> and the maintainer of kops is there.  
> Cluster Ops is a different SIG.  Is that the confusion?
>
> I don't know how to be any more inviting - we have an existing SIG where 
> we talk about running clusters on cloud AND metal using multiple tools.  We 
> document architectures and best practices.  We are about to focus on 
> upgrades and conformance tests.  Join if you want.
>
> On Mon, Nov 28, 2016 at 10:35 PM Sandeep Srinivasa  > wrote:
>
>> actually the bigger point is that sig-cluster-lifecycle is NOT the  bare 
>> metal sig or at least that's the impression one gets generally. 
>>
>> we'll go anywhere where we can find help ;) for now Kargo is seemingly 
>> the place that'll take us in! 
>>
>>
>>
>>
>>
>> On Nov 29, 2016 09:59, "Rob Hirschfeld"  
>> wrote:
>>
>> Kargo was an earlier Ansible set and did a good job.  I used it for the 
>> v1.2 release,
>> Of course, the Kargo channel will position that way!
>> Are you suggesting that the Bare Metal SIG is really the Kargo SIG?
>>
>> On Mon, Nov 28, 2016 at 10:26 PM Sandeep Srinivasa > > wrote:
>>
>>> hi Rob
>>> Thanks for trying. And i will probably join cluster ops. 
>>>
>>> But I hope you will ACKNOWLEDGE that this situation already exists. If 
>>> you search on slack as early as yesterday evening,  the #kargo statement 
>>> was reiterated. 
>>> You may be right technically in claiming other ways exist... but this is 
>>> the way that the community has *already * begun to shift.  
>>>
>>> Regards 
>>> Sandeep 
>>>
>>>
>>>
>>> On Nov 29, 2016 09:46, "Rob Hirschfeld"  
>>> wrote:
>>>
>>> Sandeep,
>>>
>>> 1) we are dividing efforts.  Why don't you TRY joining Cluster Ops 
>>> before forking it.
>>> 2) Kargo or KOPS is absolutely NOT the only tool.  Cluster Ops 
>>> specifically explores multiple appoaches.  There are many ways to do this 
>>> and they have different reasons.
>>>
>>> I simply don't understand the push to not even try to join.
>>>
>>> Rob
>>>
>>>
>>> -- 
>> Rob Hirschfeld
>> RackN.com, CEO & Founder
>> @zehicle, 512-773-7522
>>
>>
>> -- 
> Rob Hirschfeld
> RackN.com, CEO & Founder
> @zehicle, 512-773-7522
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" 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.

[kubernetes-users] Re: Bare Metal SIG

[Sandeep Srinivasa]

actually the bigger point is that sig-cluster-lifecycle is NOT the  bare
metal sig or at least that's the impression one gets generally.

we'll go anywhere where we can find help ;) for now Kargo is seemingly the
place that'll take us in!




On Nov 29, 2016 09:59, "Rob Hirschfeld"  wrote:

Kargo was an earlier Ansible set and did a good job.  I used it for the
v1.2 release,
Of course, the Kargo channel will position that way!
Are you suggesting that the Bare Metal SIG is really the Kargo SIG?

On Mon, Nov 28, 2016 at 10:26 PM Sandeep Srinivasa 
wrote:

> hi Rob
> Thanks for trying. And i will probably join cluster ops.
>
> But I hope you will ACKNOWLEDGE that this situation already exists. If you
> search on slack as early as yesterday evening,  the #kargo statement was
> reiterated.
> You may be right technically in claiming other ways exist... but this is
> the way that the community has *already * begun to shift.
>
> Regards
> Sandeep
>
>
>
> On Nov 29, 2016 09:46, "Rob Hirschfeld"  wrote:
>
> Sandeep,
>
> 1) we are dividing efforts.  Why don't you TRY joining Cluster Ops before
> forking it.
> 2) Kargo or KOPS is absolutely NOT the only tool.  Cluster Ops
> specifically explores multiple appoaches.  There are many ways to do this
> and they have different reasons.
>
> I simply don't understand the push to not even try to join.
>
> Rob
>
>
> --
Rob Hirschfeld
RackN.com, CEO & Founder
@zehicle, 512-773-7522

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" 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.

[kubernetes-users] Re: Bare Metal SIG

[Rob Hirschfeld]

Kargo was an earlier Ansible set and did a good job.  I used it for the
v1.2 release,
Of course, the Kargo channel will position that way!
Are you suggesting that the Bare Metal SIG is really the Kargo SIG?

On Mon, Nov 28, 2016 at 10:26 PM Sandeep Srinivasa 
wrote:

> hi Rob
> Thanks for trying. And i will probably join cluster ops.
>
> But I hope you will ACKNOWLEDGE that this situation already exists. If you
> search on slack as early as yesterday evening,  the #kargo statement was
> reiterated.
> You may be right technically in claiming other ways exist... but this is
> the way that the community has *already * begun to shift.
>
> Regards
> Sandeep
>
>
>
> On Nov 29, 2016 09:46, "Rob Hirschfeld"  wrote:
>
> Sandeep,
>
> 1) we are dividing efforts.  Why don't you TRY joining Cluster Ops before
> forking it.
> 2) Kargo or KOPS is absolutely NOT the only tool.  Cluster Ops
> specifically explores multiple appoaches.  There are many ways to do this
> and they have different reasons.
>
> I simply don't understand the push to not even try to join.
>
> Rob
>
>
> --
Rob Hirschfeld
RackN.com, CEO & Founder
@zehicle, 512-773-7522

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" 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.

[kubernetes-users] Re: Bare Metal SIG

[Sandeep Srinivasa]

hi Rob
Thanks for trying. And i will probably join cluster ops.

But I hope you will ACKNOWLEDGE that this situation already exists. If you
search on slack as early as yesterday evening,  the #kargo statement was
reiterated.
You may be right technically in claiming other ways exist... but this is
the way that the community has *already * begun to shift.

Regards
Sandeep



On Nov 29, 2016 09:46, "Rob Hirschfeld"  wrote:

Sandeep,

1) we are dividing efforts.  Why don't you TRY joining Cluster Ops before
forking it.
2) Kargo or KOPS is absolutely NOT the only tool.  Cluster Ops specifically
explores multiple appoaches.  There are many ways to do this and they have
different reasons.

I simply don't understand the push to not even try to join.

Rob

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" 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.

[kubernetes-users] Re: Bare Metal SIG

[Rob Hirschfeld]

Sandeep,

1) we are dividing efforts.  Why don't you TRY joining Cluster Ops before
forking it.
2) Kargo or KOPS is absolutely NOT the only tool.  Cluster Ops specifically
explores multiple appoaches.  There are many ways to do this and they have
different reasons.

I simply don't understand the push to not even try to join.

Rob

On Mon, Nov 28, 2016 at 9:58 PM Sandeep Srinivasa 
wrote:

>
>
> On Nov 29, 2016 02:43,  wrote:
>
>  There is plenty of time and attention to bring up these issues in a
> collaborative way there.  I don't see a need for a dedicated SIG and
> believe that the duplication is distracting for the community.
>
> I'm at re:Invent this week if anyone wants to talk 1x1
>
> Rob
>
>
> hi Rob,
> i will lean towards a separate SIG here and concur with Joseph. While on
> the surface, it seems that there is no need for a dedicated SIG, the
> reality is already different.
>
> For example, the implementation of load balancers has all the different
> cloud providers.. but no metal implementation. I agree it is easier to hook
> into cloud providers than haproxy/nginx...but it has been pretty hard for
>  us to find documentation or help. Similarly the proposal for source ip
> preservation does not deal with non cloud use cases. (Check the bug for the
> load balancing umbrella issue and the source ip preservation proposal)
>
> Additionally, I found out pretty recently that the
> recommended orchestration tool for metal deployments is kargo... while for
> cloud is kops.  This was repeated to me many times on the slack along with
> the advice that i should ask on the #kargo channel if I had questions on
> metal deployments.
>
> So the sig already exists in a manner of speaking - its #kargo. Its just
> not very easy to discover or create an agenda around.
>
> just my $0.02
>
> Regards
> Sandeep
>
> --
Rob Hirschfeld
RackN.com, CEO & Founder
@zehicle, 512-773-7522

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" 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.

[kubernetes-users] Re: Bare Metal SIG

[Sandeep Srinivasa]

On Nov 29, 2016 02:43,  wrote:

 There is plenty of time and attention to bring up these issues in a
collaborative way there.  I don't see a need for a dedicated SIG and
believe that the duplication is distracting for the community.

I'm at re:Invent this week if anyone wants to talk 1x1

Rob


hi Rob,
i will lean towards a separate SIG here and concur with Joseph. While on
the surface, it seems that there is no need for a dedicated SIG, the
reality is already different.

For example, the implementation of load balancers has all the different
cloud providers.. but no metal implementation. I agree it is easier to hook
into cloud providers than haproxy/nginx...but it has been pretty hard for
 us to find documentation or help. Similarly the proposal for source ip
preservation does not deal with non cloud use cases. (Check the bug for the
load balancing umbrella issue and the source ip preservation proposal)

Additionally, I found out pretty recently that the
recommended orchestration tool for metal deployments is kargo... while for
cloud is kops.  This was repeated to me many times on the slack along with
the advice that i should ask on the #kargo channel if I had questions on
metal deployments.

So the sig already exists in a manner of speaking - its #kargo. Its just
not very easy to discover or create an agenda around.

just my $0.02

Regards
Sandeep

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" 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.

Re: [kubernetes-users] Re: Bare Metal SIG

[Ben Kochie]

Load balancers for bare metal are the same as load balancers for cloud
providers.  There's not really anything different.

On Mon, Nov 21, 2016 at 7:46 AM, Sandeep Srinivasa 
wrote:

> Very very needed!
> I would argue that k8s is the kind of disruptor that would replace the ROI
> of something like AWS with cheaper hardware. I can completely see people
> building  OVH clusters on k8s that is much cheaper but almost as reliable
> as AWS.
>
> However, bare metal has heavier lifting involved - for example the load
> balancers for bare metal dont exist. I have this bug on documentation
> needed for ingress architecture on metal (https://github.com/
> kubernetes/ingress/issues/17).
>
> I dont consider myself very qualified... but this is essential and
> blocking for us.
> Thanks!
>
> --
> You received this message because you are subscribed to the Google Groups
> "Kubernetes user discussion and Q" 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.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" 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.

[kubernetes-users] Re: Bare Metal SIG

[Sandeep Srinivasa]

Very very needed!
I would argue that k8s is the kind of disruptor that would replace the ROI 
of something like AWS with cheaper hardware. I can completely see people 
building  OVH clusters on k8s that is much cheaper but almost as reliable 
as AWS.

However, bare metal has heavier lifting involved - for example the load 
balancers for bare metal dont exist. I have this bug on documentation 
needed for ingress architecture on metal 
(https://github.com/kubernetes/ingress/issues/17).

I dont consider myself very qualified... but this is essential and blocking 
for us.
Thanks! 

-- 
You received this message because you are subscribed to the Google Groups 
"Kubernetes user discussion and Q" 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.

[kubernetes-users] Re: Bare Metal SIG

[Joseph Jacks]

I just posted this in 
kubernetes-dev: 
https://groups.google.com/forum/#!topic/kubernetes-dev/Uu5bWhJ23II

On Monday, November 7, 2016 at 11:13:48 AM UTC-5, Sarah Novotny wrote:
>
> 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 <
> tnapi...@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  
>> 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  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 
>> > > 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 
>> > >> 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:
>> > >>>
>> > >>> 

[kubernetes-users] Re: Bare Metal SIG

['Sarah Novotny' via Kubernetes user discussion and Q]

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

[kubernetes-users] Re: Bare Metal SIG

[Tomasz 'Zen' Napierala]

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

[kubernetes-users] Re: Bare Metal SIG

[Joseph Jacks]

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  
> 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  > 
> > 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  > 
> >> 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-users] Re: Bare Metal SIG

[Ihor Dvoretskyi]

Tim,

Following this logic, in Kubernetes Community only SIG-Networking,
SIG-Storage, SIG-Scale and SIG-Scheduling should exist, but we know that
the number of the current SIG's is much bigger.

I would suggest placing SIG-Bare Metal aka SIG-On-prem in the single line
with SIG-AWS, SIG-Azure and SIG-OpenStack - these SIG's are not managing
directly the most crucial parts of Kubernetes, but their role is incredibly
important in the specific areas that they cover.

On Mon, Oct 10, 2016 at 5:56 PM Tim St. Clair  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 
> 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 
> > 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 

[kubernetes-users] Re: Bare Metal SIG

[Justin Garrison]

Yes please! Only concern is this would spin off to start including SIGs for 
each cloud environment. I think it would be very hard to justify why this 
is needed over intricacies when running in AWS/GCE/Azure/etc. or even 
on-prem with VMware/OpenStack

With that being said, we'd also need to make sure the scope is limited to 
Kubernetes. Bare metal environments are far too broad to try and address 
many of the possible topics I could see being asked. Some of the topics I 
would suggest we avoid is

   - What hardware should I buy/is supported
   - What OS should I use
   - How do I provision $OS to $HARDWARE
   - What load balancer should I use

Rather I think this SIG could have benefit from people sharing experience 
with generic setups not in a public cloud (on-prem VMs, Raspberry pi 
clusters, etc.) as well as it could help surface limitations and problems 
users should expect along the way. Most documentation is targeted toward 
kube-up/kops which obviously don't apply but some newer tools do (kubeadm).

Maybe the SIG could be called on-prem instead of bare metal to cover more 
use cases and setups that all have similar limitations in my experience.

On Friday, October 7, 2016 at 8:56:36 AM UTC-7, 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 user discussion and Q" 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.