►
From YouTube: Kubernetes SIG Apps 20180402
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Welcome
to
kubernetes
sigit
apps
for
april
second
2018-
and
I
am
matt
fraina
I'll
be
chairing
today,
and
so
the
first
thing
I'll
do
is
I'll
share
into
the
chat
here.
The
meeting
minutes
and
notes
that
we
take
every
week
and
with
that
we
do
have
one
announcement,
and
that
is
that
kubernetes
110
came
out
last
week
now.
Normally
we
would
have
a
retrospective
after
that.
A
Jace
has
kindly
come
in
for
quite
some
time
and
done
that,
unfortunately,
he's
not
able
to
make
it
today
or
for
the
first
several
Monday's
this
month,
we're
working
on
finding
somebody
else
or
hoping
to
have
a
retrospective,
maybe
next
week
that
we're
going
to
have
this
week.
Instead
of
that,
we're
going
to
have
a
demo
and
we've
got
some
discussion
topics
for
this
week,
and
so
with
that
Ivan.
Are
you
on
to
talk
about
eff
Nord?
Is
that
how
you
pronounce
it.
B
B
I
so
we're
kind
of
looking
to
get
some
feedback
from
the
cig,
apps
team
here
and
provide
any
you
know,
feedback
or
any
sort
of
comments,
we're
looking
to
sort
of
see,
possibly
maybe
helm
version,
three
integration
in
the
future
or
various
different
directions.
We
could
take
this
stuff,
but
for
now
I'll
just
kind
of
go
quickly
and
show
you
sort
of
an
existing
setup
that
we
have
for
workloads
across
multiple
clusters.
B
B
So
let
me
clear
my
screen
and
do
that
again,
so
you
can
see
we
have
both
of
these
clusters
now
that
are
registered
and
available
to
handle
workloads.
So
if
we
go
ahead
and
describe
them
scroll
up
a
little
bit
here,
you
can
see
that
the
u.s.
east
cluster
is
ready
and
similarly
down
here,
we
can
see
that
the
US
West
cluster
is
ready.
B
So
there's
a
set
of
configurations
in
this
directory:
I
won't
go
into
all
of
them,
but
I
will
go
in
and
describe
replica
sets
as
one
of
the
more
interesting
examples.
So
we
currently
support
distributing
more
clothes
for
namespaces
the
resources
that
we
support
are
namespaces,
config,
Maps
secrets
and
replica
sets
and
also
deployments,
but
we'll
just
show
replica
sets
in
this
demo
here.
B
Getting
some
people
so
a
question:
okay.
Yet
so
this
resource,
basically
embeds
the
kubernetes
replica,
set
resource
inside
of
it
inside
of
its
back.
Here
you
can
see
we
have
a
template
field
and
all
of
these
fields
should
probably
look
familiar
they're
just
replica
subfields,
and
we
want
to
specify
that
we
want
three
replicas.
We
have
some
W
dummy
labels
that
we
specify
there
and
the
nginx
container
image.
B
So
we
also
have
a
resource
type,
new
resource
type
called
federated
replica
set
override,
and
basically
what
this
does
is
allow
you
to
override
certain
parameters
in
your
base.
Replica
set
template
here
on
the
left,
and
so
what
we
can
override,
for
example,
is
that
in
the
US
east
cluster
we
want
to
specify
five
replicas
instead
of
the
three
that
we
specified
there
on
the
left.
B
So
this
resource
type
allows
us
to
basically
override
some
of
those
parameters
and,
lastly,
I'll
show
you
placements
again.
These
are
all
four
replicas
sets
and
this
one's
called
federated
excuse
me
up
on
top
your
federated
replica
set
placement,
and
this
one
allows
you
to
sort
of
provide
rules
on
where
you
want
your
resource
to
be
propagated.
So
here
we
are
specifying
that
we
wanted
to
propagate
in
the
cluster
names,
US,
east
and
us
west.
B
These
other
resources
are
similar,
we're
going
to
basically
propagate
them
to
both
the
US
East
and
the
US
West
clusters
and
override
just
some,
for
example.
Config
maps
and
secrets
will
override
just
some
basic
data
inside
of
that
inside
of
that
resource,
but
I
will
only
show
replicas
sets
in
more
detail
just
in
the
interest
of
time.
So
let's
go
ahead
and
create
all
of
these
resources.
B
So
now
that
those
are
created,
we'll
go
and
drill
down
into
each
of
the
clusters,
excuse
me
into
each
of
the
clusters
just
to
see
how
the
resources
were
propagated.
So
this
fancy
for
loop
here
will
just
loop
through
both
clusters,
and
this
particular
case
will
just
get
the
namespace
test
namespace
to
see
that
it's
propagated
to
both
clusters.
B
And
we'll
do
secrets
as
well.
You
can
see
test
secret
here
in
both
clusters
and,
lastly,
show
replicas
sets-
and
this
is
probably
the
more
interesting
one,
because
you
can
quickly
see
that
when
we
specified
five
replicas
in
the
US
east
cluster
and
the
west
cluster
got
the
three
replicas
that
we
had
in
the
base
template.
B
So
that
kind
of
shows
how
you
can
override
a
parameter
on
a
per
cluster
basis
and
provide
a
separate
value
for
that
field.
So
now
I'll
transition
to
show
how
you
can
move
all
the
resources
from
one
cluster
to
another,
and
we
can
do
that
by
editing
the
Federated
namespace
placement
resource.
We
had
called
the
namespace
test
namespace
if
you
recall
a
little
bit
earlier,
and
so
if
we
edit
this
resource,
we
can
basically
remove
the
US
east
cluster,
save
that
and
all
the
resources
will
move
away
from
the
US
east
cluster.
B
Since
the
names
since
we
no
longer
want
the
namespace
there
and
I
won't
show
you
all
of
the
resources,
but
I'll
at
least
show
you.
The
replica
sets-
and
you
can
see
here-
that
there
are
no
longer
any
replica
set
resources
in
this
cluster
in
the
US
east
cluster.
The
other
resources
are
similar,
but
I
won't
go
into
each
of
those
just
in
the
interest
of
time.
So,
similarly,
if
we
want
to
scale
them
back
on
to
the
US
east
cluster,
we
can
go
ahead
and
re-edit
the
federated
namespace
placement
resource.
B
So
you
can
see
here
that
the
fan
or
prototype
handles
the
workload
by
allowing
you
to
join
couple
clusters
in
this
case
to
run
workloads
against.
It
allows
you
to
specify
the
resource
types
that
you
want
propagated
as
well
as
some
overrides
that
allow
you
to
provide
different
values
across
different
clusters
and
then
placement
rules
that
allow
you
to
dictate
where
you
want
that
resource
to
be
propagated.
So
that
concludes
this
demo.
C
D
A
No
great
demo-
and
this
is
one
of
the
questions
I
know
I've
been
wondering
about-
is
when
you
get
into
the
multi
cluster
world.
What
are
the
best
ways
to
to
do
this
and
I'd
seen
the
first
version
of
the
Federation
control,
plane
and
I
know
there
are
folks
who
will
manage
it
on
their
own
as
part
of
their
CI
tooling
and
say
do
something
to
this
cluster.
Do
something
to
this
other
one
and
manage
it
themselves,
and
so
it's
neat
to
see
this
come
along.
Thank
you
for
coming.
E
Crd
and
things
like
that
that
provide
like
more
a
higher
level
view
of
what
an
application
is,
and
it
looks
like
I
mean
we're.
Gonna
have
to
maybe
evolve
that
in
lockstep
with
say,
gaps
to
make
sure
that
it'll
suit
our
use
cases
as
well
or
at
least
participate
I'm,
not
saying
you
have
to
do
what
we
want
to
do,
but
we
definitely
wouldn't
want
to
have
to
reinvent
this.
Do
it
on
our
own?
You.
F
I
have
a
question
he
maybe
I,
missed
it
in
the
demo.
I
was
distracted
in
the
middle
of
it.
At
one
point,
have
you
thought
about
progressive
rollout
of
changes
across
clusters.
E
F
Yeah,
it's
just
gonna
suggest
that
a
common
pattern
is
to,
for
example,
deploy
changes
to
a
staging
environment
first
and
then
do
changes
progressively
depending
on
how
many
clusters
you
have,
it
might
be
one
cluster
at
a
time
or
it
might
be
a
production
carry
even
in
the
same
cluster,
and
then
you
know
progress
as
you
get
increased
confidence
rollout,
faster
and
faster,
potentially
across
the
remaining
clusters.
If
you
have
enough
of
them
for
that
to
matter,
I
would.
C
Say
it's
definitely
in
scope.
I
wouldn't
say
that
we
spent
a
huge
amount
of
time
thinking
about
it
yet
because
getting
to
the
point
where
we
feel
like
the
API
constructions
for
the
basic
pieces
that
you
just
saw
are
the
right
things
to
move
forward
and
think
more
about
has
basically
been
the
story
up
until
now.
Okay,.
F
C
That's
timely
that
you
mentioned
that
the
formulation
of
overrides
right
now
is
like
minimal
just
to
illustrate
the
concept
we
had
talked
about,
potentially
using
strategic
patch
merges
of
format
for
expressing
them
in
the
future
and
just
to
circle
back
to
earlier.
In
this
beat
of
the
conversation,
one
of
the
one
of
the
other
goals
here
is
to
make
it,
since
we
all
have
a
lot
of
different
opinions
and
different
tools
that
we
prefer
to
use
I.
C
One
of
our
goals
is
to
make
it
so
that
you
can
use
this
set
of
API
soar
patterns
with
a
number
of
different
propagation
mechanisms.
So,
for
example,
what
we
saw
here
today
is
like
an
active
push
reconciler.
It
should
be
possible
to
plug
in
something
like
cuba,
pliers
the
propagation
mechanism
in
the
long
term,
since
we
don't
expect
people
to
agree
on
all
things
in
this
very
meta
problem.
Space
and
I.
C
A
C
C
A
D
A
C
A
Right,
thank
you
all
right,
so
want
this.
Please
head
over
to
sig
multi
cluster
I
may
end
up
being
one
of
the
people
over
there
now,
and
so.
With
that
we'll
move
on
to
the
next
topic.
There
was
a
proposed
developer
tools,
working
group
that
came
out
on
the
kubernetes
dev
mailing
list,
there's
a
link
to
it
in
the
meeting
minutes,
and
so
there
was
quite
a
lengthy
discussion
on
here.
A
G
G
So,
hey
everyone
so
I'm
pretty
new
to
the
kubernetes
world,
and
this
is
my
first
egg
apps
community
group,
so
I
joined
the
container
tools
scene
here
at
Google
and
we
just
recently
released
scaffold
and
when
we
released
it
a
whole
bunch
of
people,
pinged
us
and
wanted
to
talk
about
it
and
wanted
to
hear
things
about
a
road
map
and
what
we
were
thinking
etc.
And
we
and
I
was
told
about
these
working
groups
and
the
cig
apps,
and
we
have
several
tools
that
spanned,
multiple
SIG's
and
so
it
was
proposed
to
hey.
G
We
should
create
a
working
group,
so
we
have
some
more
people,
technical
and
product
discussions
around
these
tools
and
so
I
think
that's
our
main
goal.
Is
we
not
only
want
to
show
off?
You
know
what
everyone
is
building
and
we
just
really
want
to
drive
discussion
and
and
see
where
we
can
work
together
and,
hopefully
not
you
know,
creating
the
same
things
and
things
so
I
think
I,
don't
know
if
Matt
on
my
team-
and
it
has
some
strong.
It
has
some
opinions
about
about
how
we
could
make
this
working
group
successful.
G
A
Okay,
no,
no!
That
makes
sense.
So
let
me
ask
this
so
we
wanted
to
have
some
discussions
or
did
Matt
want
to
say
something.
A
Is
there
somebody
else
who
wanted
to
chime
in
No
okay,
so
you
wanted
to
have
deeper
discussion
around
some
of
the
tools
in
this
space
and,
if
I
understand
it
right,
you
talked
about
scaffold,
draft
telepresence,
we've
flux
and
mini
cube
and
tools
like
that.
What
kind
of
questions
and
discussion
so
so
one
of
the
things
and
I'm
actually
glad
joe
beta
is
here,
because
we
were
looking
at
the
scope
of
what
is
working
group
supposed
to
do
and
if
you
look
at
it
for
those
of
you
don't
know
the
context.
A
If
you
go
look
at
SIG's
right,
like
cig,
apps
and
sega
architecture
on
the
rest,
there's
an
immense
amount
of
governance
document
documentation
on
this,
and
when
it
comes
to
working
groups.
It's
like
a
paragraph
long
we
discovered
last
week,
there
had
been
there's
been
a
lot
of
talk
on
it
and
we
have
a
lot
of
underlying
community
assumptions
on
what
should
be
there.
But
the
reality
is
it's
only
about
a
paragraph
long
in
our
governance,
and
so
we've
been
talking
about
how
do
work
in
groups
form
when
do
they
go
away?
A
You
know
so
I
see
sig,
there's
a
cluster
lifecycle
because
of
mini
cube,
sig
apps
because
of
things
like
draft
and
scaffold
tend
to
fall
under
that,
and
so
we've
got
a
couple
of
SIG's
there.
That
would
be
maybe
the
sponsoring
SIG's
kind
of
thing,
and
then
we
look
at
the
goal.
So
it's
discussion
to
facilitate
diving
into
just
the
deeper
technical
things
around
what
people
need
the
problems
are
having
yeah.
I
think.
H
H
What
is
that
the
things
that
developers
want
and
need
out
of
tooling
that
helps
them
be
more
efficient
with
kubernetes
as
they
develop
and
I
think
there's
a
broad
range
of
things
that
are
there
right
now
we
have
tools
that
implement
various
pieces
of
that
and
kind
of
trying
to
figure
out
what
is
the
the
umbrella
set
of
requirements
and
where
can
people
apply
effort
to
to
make
those
things
kind
of
all
stitched
together
into
a
nice
story?
So.
D
B
So
a
little
background
on
me:
I've
worked
on
many
key
but
worked
on
scaffold,
and
so
basically,
these
meetings
have
kind
of
been
going
on
at
hawk.
So
far
so
I
mean
for
the
last
year,
we've
had
a
sink
with
Red,
Hat
and
other
folks
interested
in
many
people
like
stuff.
So
we've
been
talking
about
you
know:
should
we
support
multi
cluster?
The
developers
need
multi
cluster.
B
What
the
the
image
which
we
should
use
is
for
our
PM's,
like
all
sorts
of
questions
like
that
that
don't
really
fit
into
sig
apps,
they
don't
really
fit
into
a
cluster
lifecycle
that
much
and
then
with
scaffold.
We
we've
seen
that
there's
even
there's
a
lot
more
questions
in
this
space.
You
know,
including,
like
so
we've
been
talking
to
Microsoft
reddit,
like
all
these
companies,
have
approached
us
I'm
wanting
to
talk
about
this
in
these.
B
These
discussions
have
not
been
that
have
been
private,
but
they
haven't
been
discoverable
to
the
larger
community,
and
we
want
to
find
a
way
that
we
could.
We
can
consolidate
this
and
defragment
on
these
conversations
a
little
bit
so
I
mean
we
in
in
questions
in
products
like
scaffold
and
in
draft
we're
talking
about
I
mean
what
does
the
community
need?
Do
they
need?
You
know
some
sort
of
generation
of
these
manifests.
Do
they
need
file
Watchers?
Do
they
need?
You
know
hot
reloading?
They
need
IDE
integration.
A
There's
a
question
in
the
chat
here
for
everybody
and
it
Matt
butcher
asked
it
it
says,
but
why
is
cig
apps
not
the
place
for
this.
A
Yeah,
like
so,
we've
got
the
weekly
meeting,
so
we've
got
the
mailing
list
in
the
discussion
topics
and
we've
been
talking
about
the
whole
developer
and
DevOps
space
for
a
very
long
time.
Just
to
give
context
I
mean
that
was
one
of
the
original
reasons
that
this
sake
formed
which
to
talk
about
that
tooling,
that
sits
on
top
of
kubernetes
and
deals
with
developer
and
operations.
And
how
do
you
deal
with
those
apps
in
kubernetes?
How
do
you
operate
them
in?
How
do
you
build
them?
A
How
much
of
the
kubernetes
config
files
should
be
exposed
to
the
end-users
and
different
kinds
of
end
users?
If
you
actually
go
look
at
our
stuff
that
we've
presented,
we
talked
about
app
developers
and
app
operators
and
how
we're
trying
to
understand
their
needs
and
meet
their
needs.
Some
of
the
tools
that
are
now
part
of
kubernetes
then
a
whole
bunch
of
the
tools
that
are
not
part
of
kubernetes
that
we
also
regularly
discuss,
and
so
the
question
is:
is
we've
been
having
a
lot
of
this
discussion
here?
A
There
was
keep
all
of
this
in
cig
apps,
and
so
now
it's
approach
and
it's
and
for
us
who've
been
doing
this
for
a
very
long
time.
The
question
is:
should
you
know,
should
this
still
be
part
of
sig
apps?
If
not,
why
not
and
and
those
kinds
of
details-
and
so
that's
kind
of
a
bit
of
the
context,
because
this
conversation
has
come
up
and
as
the
community
who's
been
around
has
said,
we
should
just
continue
to
have
this
here
and
so
does.
H
That
mean
mean
that
it.
This
is
the
only
place
where
we
can
discuss
this.
Is
this
one,
our
block
and
share
it
with
all
the
other
topics
that
are
in
seg
apps
or
or
is
it
just
to
say
that
we
should
have
conversations
outside
that
are
also
public
but
then
bring
them
back
in
a
ten
minute
summary
slot,
like
that's
the
partner
I,
don't
know,
and
about
insig
apps
out
of
sagat's?
What
is
it?
What
does
that
mean.
A
So
cig
apps,
if
I,
understand
the
governance
structure
here,
because
it's
this
is
all
governance
related
to
kubernetes-
is
an
organizational
unit
that
schedules
meetings.
Can
own
code
has
a
certain
governance
structure
to
it,
because
that's
one
of
the
things
now
being
laid
down
within
kubernetes
is
a
lot
of
governance
structure.
But
from
a
pragmatic
side
it's
just
the
organizational
unit
and
you'll
see
we
already
have
regular
sub
meetings
for
various
topics.
Things
like
helman
charts
are
good
examples
of
that.
A
We've
also
had
one-off
meetings
that
we'll
just
meet
around
different
topics
and
we're
not
the
only
shake
to
do
this.
I
know
things
like
Service,
Catalog
sake
and
I.
Think
Paul
can
probably
discuss
this
more
has
had
one-off
meetings
throughout
the
week
and
sometimes
regular
meetings
on
the
same
topic
repeatedly
to
dig
down
deeper
into
these
kinds
of
issues
right
and
and
they
can
use
the
same
meeting
creds.
A
A
F
So
I
think
you
know
just
use
examples
from
a
couple.
Other
cases,
the
classic
cluster
life
cycle,
has
a
number
of
dedicated
meetings
for
its
sub
projects.
It
actually
incorrectly
calls
some
of
those
things
working
groups,
but
really
they're.
Just
sub
projects
like
the
cluster
API
meets
cops,
has
office
hours.
Comedian
has
office
hours
things
of
that
nature,
so
that's
totally
fine
as
work.
F
What
I
consider
kind
of
a
more
legitimate
working
group
example
there's
the
resource
management
working
group,
which
is
a
collaboration
amongst
signal,
SIG's
scheduling
and
sig
auto-scaling,
and
they
actually
report
back
through
sig,
note
mailing
lists
and
such
as
their
convention.
So
there's
kind
of
precedent
for
that
as
well,
to
have
kind
of
a
home
sig
just
for
to
simplify
coordination
and
make
sure
that
people
stay
in
the
loop
there,
but
it's
been
a
while,
since
I
did
involved
with
that,
so
I
don't
know
how
much
they
directly
circulate.
F
Information
amongst
the
other
SIG's
involved
versus
their
own
form.
I
think
they
don't
actually
have
their
own
mailing
list
where
a
number
of
the
other
working
groups
do.
So
we
don't
have
a
consistent
pattern.
Currently,
I
think
you
know
if
you
from
based
on
what
Dick
said,
I
think
one
of
the
primary
concerns
is
just
making
sure
that
there
is
enough
time
and
based
on
comments
of
some
of
the
other
people
on
the
thread
they
want
to
have
a
space
where
they
don't
have
to
sit
through.
F
Maybe
other
topics
that
they're
less
interested
in
so
I
think
the
you
know
in
terms
of
logistics
of
getting
this
started.
I,
don't
know
governance.
Wise
I
wouldn't
expect
this
group
to
actually
have
any
code
in
kubernetes
eventually,
so
it
doesn't
really,
you
know,
wouldn't
make
sense
as
a
sig
itself.
For
example,
a
number
of
their
chat
messages
going
on
their
chat
about
multiple
work
groups
or
multiple
SIG's
being
interested
I.
Think
Matt's
original
example
was.
F
He
actually
came
from
kind
of
the
cluster
lifecycle
space
where
the
topics
became
less
applicable
generally
applicable
this
cluster
life
cycle.
So
that's
where
it
kind
of
grew
from
that
direction
and
I
guess.
The
Eric
Veda
had
said
that
the
sig
testing
and
contributor
experience
may
also
be
interested
in
they
built
their
own
multi
cluster
mechanism
for
for
testing,
and
they
might
be
interested
in
that
so
I
don't
know.
F
E
So,
right
now
the
the
the
the
sig
apps
read
me:
I,
don't
see
a
charter
there
and
I,
don't
know
where
y'all
are
at
in
terms
of
thinking
around
charter,
but
the
readme
says
covers
deploying
and
operating
applications
in
kubernetes,
which
is
really
very
different
from
deployment
from
developing
applications
that
are
targeted
at
kubernetes.
Now,
there's
a
ton
of
overlap
here,
obviously,
and
I
think
that
that
we
see
a
kind
of
overlap
between
operating.
E
You
know
stuff
on
kubernetes,
developing
stuff
for
kubernetes
describing
stuff,
that's
like
with
app
def
across
these
things,
I
think
one
of
the
things
that
I
think
a
lot
of
folks
are
struggling
with,
and
this
is
something
that
crosses
that
across
the
SIG's
is
how
do
we
actually
take
this
large
sort
of
like
hairball?
That
is,
you
know,
developing
deploying
operating
all
that
stuff
and
start
teasing
apart
the
different
layers
so
that
we
can
actually
build
an
ecosystem
of
tooling
and
concepts
around
this,
and
so
am
I
am
I
at
least
reading
this.
E
A
A
It
used
to
be
much
more
developer,
focused
and
developer
friendly,
and
so
that
is
one
of
those
things
when
I
went
back
and
I
read
that
the
other
day
I
caught
my
attention
wait
a
minute
we
haven't
watched
this
in
a
while,
so
I'll
go
back
and
we're
gonna
update
that.
But
then
there's
also
the
question
of
how
much
of
the
developer,
tooling
and
flow
is
supposed
to
be
in
scope
for
kubernetes
right.
A
So
one
of
the
things
that
we
talked
about
with
kubernetes
is:
we've
got
the
kubernetes
core
and
that's
the
official
thing
and
right
here
we're
talking
about
a
whole
bunch
of
tools
that
are
not
part
of
kubernetes.
Now
in
cig,
apps
we've
traditionally
gone
out
and
branched
into
those
things,
even
though
they're
not
an
official
part
of
the
kubernetes,
and
so
the
question
of
scoping.
A
Also
raises
how
many
of
these
conversations
should
be
facilitated
in
part
of
kubernetes
on
the
books,
because
you
know
we're
talking
about
a
whole
bunch
of
sub
projects
that
aren't
really
sub
projects
of
kubernetes
and
we're
talking
about.
You
know
it's
kind
of
the
whole
thing
of
should
my
ide,
you
know
talk
to
the
new
tools
and
the
Linux
folks.
Should
they
be
facilitating
these
conversations,
and
so
yes,
Joe.
E
D
E
I
think
that
that
actually
makes
the
case
for
a
working
group
more
than
anything
else,
because
a
working
group
cannot
hold
code
really.
What
it
is
is
just
a
place
for
folks
to
get
together
and
talk
about
this
stuff
and
I
agree
that
these
things
aren't
part
of
kubernetes,
proper
and
I.
Don't
think
you
know,
I
think
it's
great
that
we're
seeing
an
explosion
of
tools
that
exist
outside
of
kubernetes
I.
Think
providing
the
right
forum
for
folks
to
get
together
understand
you
know,
build
understanding
interoperability
that
makes
a
ton
of
sense
around
that
stuff.
A
Group,
so,
a
while
ago,
when,
when
I
asked
about
the
same
thing
with
the
ecosystem
working
group,
in
that
the
feedback
that
I
generally
got,
was
we're
talking
about
a
lot
of
things
that
are
not
part
of
kubernetes.
And
so
therefore,
is
it
kubernetes
responsibility
to
facilitate
those
conversations
that
are
at
a
much
higher
level
than
kubernetes
itself
right
and
so
I'm
curious.
A
If
there's
a
difference
in
thinking
now
out
of
y'all,
especially
those
of
you
who
control
and
manage
the
scope
of
kubernetes
and
what
should
be
in
and
discussed
wire
notice,
I'm
just
trying
to
get
to
clarifying
questions
here,
and
that
was
just
like
four
or
four
and
a
half
months
ago.
So
I'm
kind
of
curious
on
the
clarity
of
thinking
around
this.
When
this
topic
came
up
last
time,
I,
don't.
E
Remember
the
topic
before
I
I
I
would
be
supportive
of
kubernetes
providing
a
home
for
discussions.
I
think
we've
been
very
liberal
in
terms
of
doing
things
like
creating
slack
channels
for
four
sub
projects.
I
think
work
for
community
projects
and
I
think
the
the
the
repository
rethink
stuff
that
Brendon
led
where
there's
this
idea
for
was
associated
projects
also
is
a
way
of
sort
of
enabling
the
community
without
trying
to
necessarily
own
it.
So
that's
my
great
day,
okay,.
A
F
F
The
CNC
F
landscape
is
is
very
interesting
and
the
other
example
I
would
I
just
wanted
to
bring
up
was
Big
Data,
where
you
know
obviously
spark
this
bark
side
of
the
integration
is
not
in
kubernetes
proper,
but
you
know
if
there
are
mechanisms
that
in
communities
that
need
to
be
evolved
in
order
to
support
that,
that's
where
code
would
live
in
and
kubernetes,
although
I
don't
think
that
cig
is
actually
going
to
own
any
code
in
communities
proper.
So
it's
definitely
the
case
that
we're
kind
of
skirting
the
edge
in
a
number
of
areas.
A
So
the
question
is:
why
isn't
sig
apps
the
right
place
for
this?
If
the
conversation
has
already
been
happening
here
and
and
I
know
no
number,
the
folks
who've
come
in,
this
is
actually
your
first
meeting,
and
so
the
question
is
is
if
we
have
the
conversation
here
and
it's
been
going
on
here
and
we've
got
the
time.
Why
is
this
not
the
place?
Matt,
you
raised
your
hand,
yeah.
B
I'm
using
the
features
too
so
I
guess
I
just
want
to
say
that
I
guess
historically,
a
lot
of
the
discussion
has
I
mean
obviously
I.
Think
both
of
us
come
from
a
bit
of
a
bias
background.
You
know
you
kind
of
hostessing
that
the
gaps
meanings
and
me
working
out
some
of
these
developer
tools.
I
would
say
that,
from
my
point
of
view,
historically,
a
lot
of
the
discussion
has
not
happened.
B
It's
a
gaps,
you
know
I'm,
not
a
regular,
say
gasps
contributor,
but
I've
worked
on
a
lot
of
these
developer
tools
and
you
know
of
these
developer
tools
and
in
meetings
that
actually
happened
outside
of
say
gap.
So
I'm
not
sure
how
much
has
actually
happened
in
see
gaps.
I
know
there
have
been
a
lot
of
demos
here,
but
I
I'm,
not
sure
if
a
demo
is
is
equal
to
kind
of
the
deeper
discussion
that
we're
trying
to
target
with
this
working
group.
I
So
so
this
is
Richard
show
us
I
work
with
telepresence
and
forge
and
we've
had
a
conversation
with
Matt
and
and
I
would
echo
what
Matt
said:
we've
had
pretty
extensive
conversations
with
a
bunch
of
other
folks
from
other
organizations
just
around
adopting
tooling.
That,
for
various
reasons,
didn't
seem
like
it
fit
on.
Sega's
will
be
certainly
a
demo
telepresence
on
the
stick.
A
call
I
think
it
I'm
totally
supportive,
actually
reporting
out
or
giving
updates,
because
I
think
communication
is
good.
I,
don't
think,
there's
any
objection
to
that.
I
The
other
thing
I'd
point
out
is
that
with
the
working
group
I
think
the
target
persona
is
very
clearly
the
developer
and
operational
concerns.
I
think
would
not
be
in
scope,
I
think
with
sig
apps,
it's
a
little
more
hazy
around.
You
know
if
you're
deploying
an
application,
there
are
stakeholders
from
an
Operations
standpoint,
as
well
as
a
development,
standpoint
and
I.
I
J
One
thing
I
wanted
to
point
out:
everyone
seems
to
be
focused
on
the
first
sentence
of
the
app
special
interest
group
blur.
The
second
sentence
is
we
focus
on
the
developer
and
DevOps
experience
of
running
applications
in
kubernetes,
so
traditionally
we
always
have
kind
of
had
this
community
we're
focused
on
everything
from
design
to
decommission
right.
The
value
has
been
that
you
get
perspectives
from
a
diverse
set
of
people
with
different
backgrounds
right
and
it's
insightful
having
someone
with
primarily
and
operations.
Experience
give
you
the
operations,
perspective
and
impact
on
your
developer,
tooling.
J
To
me,
at
least
that
being
said
like
to
me,
the
value
proposition
for
this
new
working
group
is
that
we
want
to
take
an
hour
of
time
every
week
and
bring
together
multiple
SIG's
and
have
a
conversation
that
focuses
just
on
the
developer
tool.
The
thing
about
it
is
the
people
who've
been
contributing
this
conversation
for
a
couple
of
years.
J
You
know
I
want
to
make
sure
that
their
voice
is
also
heard
inside
of
this
working
group,
and,
if
that's
going
to
be
the
case,
they're
gonna
have
to
you
know,
come
and
participate
if
they
want
their
voice
to
be
heard
and
give
an
extra
hour
of
time
of
their
time
every
week.
So,
like
my
main
thing
is
what
is
the
output
of
this
group
going
to
be?
J
If
we
do
it
like,
if
we're
asking
people
to
give
an
extra
hour
of
time
every
week
to
participation,
have
their
voice
heard
help
shape
the
direction
of
developer
tooling
in
the
community
in
general?
What
is
the
output
of
the
working
group
going
to
be
that's
going
to
make
it
worthwhile
like?
Is
it
going
to
be
a
recommendation,
a
set
of
best
practices?
H
Do
you
guys
want
to
first
output
of
a
first
meeting
would
definitely
be
figuring
that
out
what
we
know
so
far
is
there
are
a
lot
of
people
interested
in
this
one
topic,
and
so
we
want
a
space
to
kind
of
talk
through
what
what
does
it
mean
to
have
output?
What
is
the
output
of
a
group
like
this?
What
does
the
tooling
space
look
like?
What
kind
of
buckets
do
we
have
for
different
tools,
like
all
that
kind
of
definition,
still
has
to
happen,
I
think
and
I'm
not
going.
F
J
Wanted
to
say
one
more
thing:
I
guess,
then.
My
only
concern
is
that,
because
it's
so
vague
about
what
the
output
is
going
to
be
at
this
point,
if
we
just
keep
doing
working
groups
every
time
we
want
to
have
the
key,
do
we
need
to
have
a
working
group
every
time
people
want
in
the
community
want
to
get
together
and
have
a
conversation
on
an
ongoing
basis?
Is
that
something
that
actually
requires
governance?
Like
I
mean
that's
a
fair
question?
Legging
them
it's?
J
If
you
want
to
have
a
conference
call
on
a
weekly
basis,
that's
I,
don't
see
why
we
have
to
do
that
if
it,
if
it's
something
where
we
want
to
bring
the
community
together-
and
you
know,
there's
going
to
be
output
to
some
sig
there's
going
to
be
action
items
we
need
to
track
it.
We
need
the
governor's
around
it.
Then
it
makes
a
lot
of
sense
to.
But
if
it's
not
that,
then
you
know
do
we
want
to
do
this
every
time
somebody
wants
to
get
it
together
and
have
an
ongoing
talk.
Yeah.
H
And
I
think
that
one
one
main
goal
of
ours
is
to
not
be
exclusionary
right.
We
want
to
have
as
many
people
who
want
to
participate
with
this
level
of
depth
in
this
conversation
as
possible
to
be
participants
in
it.
So
we
don't
want
to
like
go
off,
have
a
call
with
two
or
three
people,
and
then
you
know
that's
it.
We
want
to
have
it
be
as
part
of
the
community
as
as
much
as
it
can
or
as
much
as
make
sense.
But
it's
it's
seeming
difficult
to
find
that
balance.
Well,.
D
Thank
you,
so
I
just
want
to
give
context
two
things
one,
you
know
a
lot
of
this
is
a
little
bit
hazy,
because
we
don't
have
a
lot
of
definition
around
what
a
working
group
is
and
why
you
created
and
and
all
that
and
just
been
working
on
that
so
I
hope
in
the
future.
This
becomes
a
more
clear
and
well-defined
conversation
and
then
on
the
sig
ops
perspective.
D
You
know,
I
helped
co-found
see
gaps
with
Matt
like
a
few
years
back
I
also
work
on
developer,
tooling,
I,
work
on
draft
I
work
on
home
and
some
other
things
so
I
wanted
to
say,
like
you
know,
as
someone
who
helped
bring
this
group
together,
the
original
intention
was
to
get
to
a
place
where
we
could
talk
about
developer
tooling.
But
the
thing
is
the
bits
and
pieces
weren't
in
place
at
the
time.
This
was
so
far
back.
We've
been
working
on
kind
of
setting
the
foundation
to
actually
get
to
this
point.
D
To
talk
about
developer,
tooling,
things
like
like
mini
cue
point
around
the
workloads,
API
wasn't
stable.
There
were
all
these
bits
and
pieces.
People
don't
really
know
how
to
do
CS
you
need
well,
did
you
know
having
a
hard
time
defining
cube
res
manifests,
and
all
of
these
things
have
gotten
a
lot
easier,
so
we're.
Finally,
at
a
place
where
we
can
have
the
conversations
like
around
developer
tooling,
and
we
have
been
having
those
conversations
and
say,
gaps
and
I
agree.
There
should
be
more
focus
on
it.
D
I
really
passionate
about
this
space
I
would
love
to
talk
more
about
it,
but
it's
that's.
We're.
We've
set
the
foundation
here
to
talk
about
this
particular
thing
and
we're
we're
finally
hearing
now.
We
it
feels
like
we're,
trying
to
break
off
or
kind
of
go
in
a
different
direction
and
I
agree
like
with
Ken,
like
the
scope
of
this
say,
would
would
be
very,
very
narrow
if
we
took
away,
but
that
particular
piece
of
what's
a
cop,
says:
Brian
houses
finger
arrays
so
like
I've.
F
Always
seen
one
screen
at
a
time,
so
someone's
on
the
other
screen
speak
up
now.
Anyone
now
okay,
so
I
just
wanted
to
make
a
proposal.
It
sounds
like
the
leaders
of
the
gaps
are
saying
they
believe
it's
in
scope
and
they're
willing
to
dedicate
time
to
the
topic.
People
in
the
work
group
said
when
I
asked
on
the
thread
said
they
think
they'd
started
an
hour
every
other
week.
Does
sig
apse
want
to
donate
an
hour
every
other
week
to
the
discussion?
F
F
Because
I
think
what
you
know,
what
I
keep
hearing
is
one
of
the
main
concerns
is
that
there's
not
adequate
time
or
too
many
other
topics
and
certainly
looking
at
the
past
agendas.
I
think
some
of
the
perception
came
from
that,
like
you
know
it
take
potentially
weeks
or
longer
to
get
demos
scheduled,
and
there
was
a
lot
of
time
spent
on
stand-ups.
But
if
that's
you
know,
if
they're
willing
to
make
space,
it
seems
like
there's
no
harm
and
just
trying
that
so.
E
Think
making
sure
that
this
is
a
place
where
we
can,
you
know
redefine
the
lines
is,
is
I,
think
an
important
thing
and
I
think
that's
one
of
the
that
might
be
one
of
the
drivers
for
why
folks
were
so
intent
on
a
working
group
is
to
have
a
little
bit
of
a
clean
slate
in
terms
of
exploring
the
solution.
Space.
A
Yeah
I
definitely
agree
with
the
the
whole
safe
space
and
if,
if
sig
apps
is
not
people
don't
feel
it's
a
safe
space?
Please
come
let
us
know,
because
that
is
never
our
intent.
We
always
want
to
see
new
shiny
things
here
and,
if
you're
not
comfortable
talking
to
the
co-chairs
of
sig
apps,
please
reach
out
to
one
of
the
other
people
on
the
steering
committee
and
say:
hey
I
want
to
pass
this
on
and
I
know.
They'll
pass
it
on
to
us.
A
I
do
want
to
say
one
other
thing
before
we
get
into
something
like
another
working
group.
I
would
really
like
to
see,
and
so
here's
my
pitch
to
you
and
I've
already
pitched
this
to
Aaron
and
some
of
the
others
that
before
we
get
another
working
group,
let's
get
updated
docs
on
that
working
group,
so
they
can
be
held
accountable
to
that
from
the
steering
committee.
That's
my
only
thing.
I
would
say
that,
no
matter
how
we
do
this
I
know
say,
gaps
would
be
willing
to
either
include
time.
A
We
could
try,
including
time
in
our
say,
gaps,
meetings
and
I'll,
be
happy
to
sit
down
with
Kim
or
anybody
else
on
figuring
out
those
agendas
and
and
whatnot
to
make
sure
that
it's
a
good
starting
point
and
if
not
I,
know
we'd,
be
happy
and
having
subgroups
that
have
the
sig
apps
credentials.
And
we
can
upload
the
videos
because
we
like
to
record
every
especially
for
demos
and
stuff
like
that.
In
order
to
get
this
stuff
online.
B
One
thing
I
would
add
is
that
I
think
we
would
be
happy
to
take
an
hour
every
other
week
and
and
start
working
on
like
scoping.
You
know
that
week
to
developer
tooling,
but
I
also
think
it
might
be
worthwhile
to
I
mean,
as
we
were,
setting
up
this
working
group.
You
know
just
knowing
kind
of
what
had
gone
on
its
the
gaps
and
reading
the
Charter
it
was.
It
was
unclear
that
this
was
really
in
scope
and
coming
from
our
world
it.
You
know
it
didn't
seem
like
it
was
at
all.
B
Otherwise
we
would
have.
You
know,
brought
it
up
much
earlier
instead
of
on
the
thread,
but
you
know
just
kind
of
finalizing
I
know
you
guys
are
working
on
it
now,
but
you
know
finalizing
what
exactly
is
in
scope
force
a
gap,
you
know
is
mini
Q
part
of
the
gaps.
You
know,
there's
a
local
cluster
development.
You
know
they
see
ICD
and
scope
for
the
gaps
you
know
just
so
that
we
we
have
a
better
idea
of.
B
You
know
what
fits
in
where,
right
now
it
seems
you
know,
I,
don't
know
if
we
could
effectively
have
a
group
that
focuses
on
both
the
developer
and
the
operator,
because
I
feel
like
these
are
very
distinct
user
stories
in
the
community's
world.
A
I
would
suggest
that
the
next
steps
would
be
to
look
at
when
we
I
would
suggest
doing
it
as
part
of
say
gaps
and,
but
that's
also
partly
me
saying:
don't
do
any
new
working
groups
until
the
working
group,
documentation
and
charter
and
governance
stuff
is
in
better
shape
than
it
is
than
a
single
paragraph.
I
would
suggest
in
say,
gaps
were
happy
to
donate
time.
This
and
I'd
be
happy
to
get
on
the
phone
to
organize
the
future
meetings
on
that
going
forward
to
look
at
how
do
we
fit
it
in
I?
A
A
So
I
would
like
the
opportunity
to
try
to
incorporate
this
into
sig
apps,
and
if
that
doesn't
work,
we
can
look
at
breaking
it
off
into
its
own
meeting
or
whether
it
makes
sense
as
a
working
group
you,
what
do
folks
I
got
a
bunch
of
plus
ones
before,
but
I
think
there
was
a
little
bit
of
pushback
too.
So
I'm
not
sure
what
folks
are.
Are
you?
Okay?
If
we
try
that
well,.