►
From YouTube: Kubernetes SIG Network 20170518
Description
Kubernetes SIG Network Meeting May 18th, 2017
B
Awesome
so
I
think
that
the
first
item
we
want
to
talk
about
today
is
Network
policy
being
the
kind
of
major
feature
we
were
targeting
for
1-7.
There
been
some
issues
raised
much.
Hopefully
everybody
saw
that
on
the
PR
for
that
about
our
use
of
the
namespace
for
enabling
and
disabling
Network
default
deny,
and
it
looks
like
we're
going
to
need
to
rethink
how
that
part
of
the
proposal
goes
to
GA,
so
I
think.
D
D
B
B
C
C
C
Are
there
steps
in
between
here
and
a
finished
thing,
so
the
discussion
on
the
PR
identified
six
or
seven
different
possible
ways
to
fix
this,
ranging
from
like
a
global
flag
that
would
activate
our
policy
for
the
entire
cluster
all
the
way
down
to
having
a
second
API
resource.
That
was
a
sort
of
policy
switch
that
you
could
put
in
the
namespace.
Once
you
put
one
of
these
in
your
namespace,
then
network
policy
is
activated
yeah,
so
we
have.
We
have
a
lot
of
options
here.
The
second
part
of
it
is.
C
We
have
only
a
couple
of
weeks
really
before
the
code
freeze
for
one
seven
and
we
need
to
decide
what
is
actually
achievable
between
now
and
then
no
matter
what
we
choose.
This
is
going
to
be
an
API
change
and
implementation
change
and
all
of
the
implementers
who
hopefully
are
here
I,
don't
want
to
make
everybody
mad
scramble
to
try
to
be
compatible
with
it
in
the
last.
E
E
F
I
I
mean
I
lean,
I
lean
towards
getting
it
GA.
If
we
can
agree
a
semantics
that
we
don't
think
is
hugely
Elbrus,
a
semantics
changing,
we
think,
is
not
hugely
endless
on
people
and
the
reason
why
I
lean
towards
that
rather
than
pushing
out
another
release
is
because
you
know
increasingly,
the
question
that
will
happen
to
answer
in
the
field,
for
users
is
okay.
How
do
I
migrate
if
I'm
using
this
now?
How
do
I
migrate
when
it
goes
to
GA
and
the
longer
along?
F
We
leave
it
in
beta
with
this
uncertainty
that
the
harder
that
becomes
and
the
more
people
who
are
actually
using
this
beta
feature,
who
might
have
to
go
through
some
kind
of
dual
provisioning
phase
during
the
upgrade,
so
I
think
I
think
there's
a
cost
of
the
community
for
as
leaving
in
beta
and
I.
Think
if,
as
the
network
implementers,
we
can,
you
know
we
can
scramble
for
a
couple
of
weeks
to
avoid
that
cost.
Then
I
think
that's
what
we
should
try
and
do.
F
E
E
B
So
one
of
the
things
that
I
liked
about
option
six,
which
was
that
you
know
you,
don't
have
this
global
flag
at
all
and
when
pods
are
selected
by
network
policy,
they
automatically
get
a
default
deny
was
that
it
didn't
prevent
us
from
then
adding
of
their
switches
down
the
road.
So
you
could
still
add
a
per
namespace
or
a
cluster
cluster
default
deny.
That
would
then
affect
everybody,
but
we
could
still
go
without
adding
a
new
API
resource
or
trying
to
shim
something
in
somewhere
that
make
sense.
Yeah.
G
H
Think
I
offered
the
the
very
same
opinion
I
think
I
would
not
I
would
not
continue
with
the
namespace
NAR
with
the
annotating
the
namespace,
because
if
you
cannot
make
that
work,
users
will
start
assuming
that
it
will
be
a
namespace
study
and
we
can
know
about.
We
not
cannot
backer.
So
if
you
don't
have
a
good
solution
now,
we
should
not
set
up
the
like.
H
It
says
this
has
a
bad
example
right
now:
option
6
is
I,
think
straightforward
to
implement
for
everybody
in
relatively
say,
but
assume
this
is
at
least
somebody
is
that
I
assume
everybody
has
some
form
of
this
in
their
body.
I
know
the
mentor,
I
notice,
automation
ones
have
this
option.
6
also
does
not
exclude
option
7
later
on
I,
given
you
freedom,
the
option
set
up
for
in
flip
switch,
so
it
option
fixes
you
start
enforcing
as
soon
as
you
have
to
first.
H
The
first
policy,
though
option
7
would
be
F
applied,
which
could
say
always
whitelist
or
always
not
polish.
It
up
right
then
so
option
6
does
not
exclude
option.
7
I,
think
option.
6
is
safe
option.
7
is
safe
as
well
continuing
with
an
annotated,
namespace
is
kind
of
dangerous,
because
we
we
solve
lots
of
issues
in
make
on
how
to
get
it
work,
48,
and
unless
we
have
that
as
a
converse,
you
have
a
good
idea
how
to
stop
it.
It's
dangerous
to
make
users
use
that
so
sort
of
our
flag,
yeah.
F
I
think
I
think
I
think
I
agree
with
that
yeah
and-
and
at
this
point
that
if
we
go
with
the
option
6,
then
we
we
have
the
flexibility
to
add
on
additional
layering
that
whatever
scope
we
decide,
we
want
to
do
it
later,
whether
it's
a
namespace
or
globally
or
or
some
other
object
to
control
the
default.
Yes,.
F
F
C
H
Have
one
more
question
regarding,
if
you,
if
we
move
to
the
now
policy
GA
most
likely,
this
has
already
been
discussed
but
like
if
we
introduce
stuff
like
cider
later
on
right
now,
in
the
ingress
rule,
we
have
the
from
and
the
port
or
connected
with
an
aunt.
If
we
later
on,
extend
that
to
something
like
a
cider,
obviously
we
cannot
do.
We
cannot
continue
doing
an
aunt
all
the
fields.
Right
then,
like
the
port
would
need
to
map
the
from
aunt
the
cider,
like
it
avails
work.
C
C
E
E
C
H
C
C
C
Overall,
if
you
look
at
the
list
of
links
that
endowed
every
meet
one
of
the
worst
actors
in
fact,
look
at
the
number
of
bugs
we
have
often
clinically,
if
you
look
at
the
number
of
feature,
requests
that
come
in
support,
requests
that
come
in.
We
are
very
near
the
top
of
the
list
for
every
category,
with
all
the
documentation
and
the
help
requests
that
come
in
around
networking.
There's
a
lot
of
Help
Wanted
while
doing
a
good
enough
job
of
all
of
these
basic
things
that
we
should
be
doing.
C
I
fully
acknowledge
networking
is
probably
the
most
convoluted
twisted
subsystem
in
the
entire
kubernetes
ecosystem,
but
that
doesn't
mean
we
get
to
do
a
bad
job
of
documenting
ourselves.
So
this
is
not
blaming
anybody
or
if
explaining
anybody
is
blaming
me
so
I
think
concretely,
here's
what
I'm
proposing
we
should
take
topics
like
multi
network
and
we
should
relegate
them
to
the
mailing
list.
The
mailing
list
is
archived
and
is
browsable
and
searchable
in
ways
that
the
video
hangouts
are
just
not
I,
think
we
should
leave
highly
contentious
technical
discussions
for
the
mailing
list.
C
We
should
use
the
video
call
to
break
log
jams
when
we
need
to,
but
I
think
the
discussion
should
happen
on
the
nameless
I
understand
that
that's
painful
and,
like
everybody
already
gets
enough
email
trust
me
I,
understand,
but
I
think
that's
a
better
place
to
put
it
I
think
what
we
should
be
doing
on
this
call
is
more
tactical
I
think
we
should
have
a
list
of
bugs
features,
documentum,
etc
that
we're
working
on,
and
this
should
be
a
check-in
meeting.
How
are
things
going?
What
other
issues
have
come
up?
C
Are
we
on
track
to
hit
our
goals
for
the
quarter?
We
don't
we
don't
actually
have
goals
for
this
quarter,
except
GA
network
policies
like
there's,
not
really.
We
never
wrote.
Okay,
ours
or
you
know,
plans
for
what
we
were
going
to
push
into
one
seven
everybody
sort
of
operated
independently.
I
would
like
to
fix
that.
C
I
understand
that
this
means
some
of
the
discussion
around
multi
network
sort
of
twisting
and
I
feel
bad
for
that
we
should
take
it
to
the
main
list.
I
think
it
is
so
contentious
that,
if
not
going
to
resolve
itself
between
now
and
the
end
of
the,
but
it
could
suck
all
the
oxygen
out
of
our
room
and
so
I
would
much.
C
C
It
would
be
great
if
we
make
me
sense
better
and,
as
we
come
into
the
end
of
this
release
and
start
looking
at
the
1-8
cycle,
I'd
like
to
do
this
at
the
very
beginning,
call
out
a
spreadsheet
or
a
list
of
all
of
the
things
that
we
think
we
are
working
on,
that
we're
committing
to
all
the
things
we'd
like
to
get
help
on
and
make
it
a
very
tactical
release
and
see
how
that
works.
For
our
sake,
I've
been
talking.
Somebody
yell
at
me.
I
C
C
I
Think,
at
least
sig
note
operates
in
that
regard,
where
maybe,
if
they're
going
to
have
a
technical
discussion,
it's
it
is
slightly
caught
time
boxed.
But
the
majority
of
the
discussions
happen
in
potentially
external
work
groups,
which
might
not
be
the
best
from
manageability
standpoint
sometimes,
but
the
meetings
are
fairly
fluid
and
stuff
is
kept
on
track
for
for
release
and
they
get
a
lot.
C
Done
yeah
and
storage
is
very
similar.
Storage
has
a
very
sort
of
project
manager,
II
feel
to
their
meetings
they
check
in
on
bugs
and
Docs
and
those
sorts
of
things,
and
they
get
a
lot
done
and
they
don't
have
a
whole
lot
of
storage
flakes
left
and
their
tests
are
pretty
good,
and
you
know
these
are
places
where
we're
sort
of
falling
down.
C
All
right
well,
if
nobody's
going
to
complain,
I
mean
I'll.
Let
it
sit
I'll,
write
this
up
and
send
it
to
their
mailing
list
as
a
more
documented
and
searchable
place
since
I'm
marking
for
mailing
lists.
But
if
nobody
is
going
to
object
to
it,
then
maybe
Dan,
Casey,
Christopher
and
I
can
pull
together.
Maybe
I'll
get
some
extra
food
from
Google
and
like
go
through
our
bug,
lists
and
like
let's
nominate
ourselves,
say
ten
bugs
between
now
and
the
end
of
this
quarter
that
we
really
want
to
try
to
tackle.
C
Some
of
them
are
probably
people
already
working
on,
but
we
don't
know
about
it,
and
some
of
them
are
probably
things
that
we
should
throw
on
to
our
heat
just
to
try
to
get
some
user
phasing
bugs
back
on.
What
do
you
guys
think
willing
to
take
other
volunteers?
They
don't
want
to
put
them
a
whole
cig,
triage
process,
okay,
okay,
so.
J
C
E
A
C
So
like
open
up
the
Signet
work
label
for
per
issues
on
the
main
repo
and
like
up
to
both
the
ones
that
you
think
are
the
most
important
or
comment
on
the
one
you
have
context
on
or
if
you
find
some
that
are
dupes
suggest
that
they're
dupes
right
the
more
eyes
will
make
light
work
of
this.
You
know
this
is
a
low-level
commitment.
If
you've
got
a
half
hour
free
between
meeting
scrub
cloud,
bugs
right
just
go
look
at
them.
It
makes
sense.
C
Also,
if
you
find
issues
that
aren't
tagged
with
sig
network,
say
so
like
message
me
or
at
me
on
the
issue
so
that
I
or
Dan
or
somebody
can
tag
them
properly.
I
tried
to
find
all
the
other
like
area
tags
and
make
sure
they
were
all
tagged
as
sig
network,
but
it's
entirely
probable
that
I
missed
them.
If.
C
Yes,
yeah.
We
have
multiple
area
tags
which,
if
you
can
break
it
down
even
further
than
that's
great.
We
also
have
a
separate
DNS
repo,
we're,
probably
DNS
bugs,
should
be
filed
against
that.
At
this
point,
yeah
please
like
help.
This
is
a
place
where
everybody
can
pitch
in
and
do
just
a
little
bit
of
work
will
go
a
long
way.
B
Test
likes
yes,
so
also
at
the
top
of
the
cig
meeting
notes
and
in
the
I've
also
put
them
in
the
spreadsheet.
We
have
a
tab
for
flakes
that
are
labeled
as
against
sig
Network,
and
there
are
quite
a
few
of
these
over
there
13
open
at
the
moment.
Quite
a
few
of
them,
I've
been
open
since
December,
so
quite
a
ways
back.
B
C
C
I'm
going
to
take
a
room,
I'm
willing
to
take
two
months
if
it
hasn't
record
since
the
one
six
launch,
we
should
probably
just
nuke
it,
and
if
it's
really
there
it'll
come
back
expansions
and
then
the
ones
that
are
left
will
be
the
actually
important.
One
and
I'd
also
like
to
point
out
like
I
know
doing
eee
work
is
not
sexy,
but
it
is
hugely
impactful.
C
You
know
when
we,
when
we
spent
the
time
to
make
the
tests
I
mean
faster,
with
respect
to
like
services,
in
particular
the
the
time
it
took
for
each
PR
tests
to
run
went
down
by
like
ten
minutes
so
like
it'd,
be
a
huge
impact.
If
you
can
go
through
these
tests
and
actually
find
places
that
are
wasting
time
or
find
flakes
and
get
rid
of
places,
we
have
to
end
up
rewriting
the
tests
or
just
even
going
through
and
looking
at
the
output
of
a
test
run
and
fixing
up
the
log
messages
before
human-friendly.
B
C
I
I
C
C
D
C
C
G
C
C
B
Yeah
I
think
I
think
probably
the
first
thing
is
for
me
to
just
have
a
go
through
and
and
prune
out
the
obvious
dead
ends,
and
then
I
was
thinking.
It
might
make
sense.
If
you
know
these
people
have
this
volunteer.
Take
oh,
we
organized
and
signed
one
one
issue
each
to
perf
like
each
probably
starting
with
the
ones
that
are
most
recently
occurring.
B
M
B
So
maybe
it
makes
sense
for
me
to
first
ping
the
people
that
have
been
assigned
to
those
and
see
if
they're,
actively
investigating
I
suspect
for
a
large
number
of
them.
The
answer
there
is
no
should
we
have
maybe
like
a
kind
of
mini
quote,
unquote
working
group
with
the
people
who
just
just
volunteered,
and
we
can
chat
on
on
a
slacker
or
out-of-band
about
how
we
want
to
split
these
up.
Mainly.
D
A
C
I
might
throw
out
a
little
bit
about
the
governance
process
before
it,
so
many
or
some
of
you
may
know
that
there's
been
some
halle-loo
about
formalizing
the
Commodities
project
governance,
so
myself
and
a
number
of
other
people
have
been
around
for
a
long
time.
I
had
been
sitting
down
over
the
last
couple
of
weeks
to
hammer
out
sort
of
a
proto
Constitution
and
there's
two
main
things
that
we're
focusing
on.
C
The
first
is:
how
do
we
formally
elect
sort
of
a
steering
committee
for
the
project
overall,
and
the
second
part
of
it
is
to
formalize
what
it
means
to
be
a
sig?
What
authorities
does
it
say
you
have
or
responsibilities
of
the
CM?
We've
got
a
lot
of
these
things:
sort
of
written
down,
they're,
not
really
formal
enough
and
they're,
not
really
enforced
enough,
and
one
of
the
concepts
that
is
emerging
from
this.
C
What
I
think
we
need,
though,
in
order
to
really
make
it
formal
is.
We
need
somebody
to
stand
up
as
sort
of
the
chair
of
that
working
group.
Who
is
the
point
of
contact
for
the
v6
work
and
maybe
to
write
down
a
very
short
like
one
paragraph
statement
of
like
what
is
the
objective
and
bounds
of
the
working
group?
I
need
to
be
six
people
here,
I.
L
A
C
L
N
C
That'd
be
great,
just
like
literally
like
one
paragraph
like
what
are
we
trying
to
do
and
so
that
it's
not
an
unbounded
thing
and
we
will
hopefully
have
some
processes
in
place
where
you
can
actually
post
this
information.
So
somebody
who
is
new
to
the
community
could
sort
of
go
shopping
for
what
working
groups
are
active
and
what
are
they
doing?.
A
N
A
N
N
A
B
A
B
A
K
A
Quick
note
on
the
stay
nice
def,
partly
because
of
the
CNCs
discussions
for
C&I,
but
also
because
we've
been
talking
about
it
for
a
while.
We
moved
all
of
the
CNI
plugins
into
a
separate
repo
called
de
plugins
repo
and
they
will
get
removed
from
the
main
CNI
repo
and
that's
an
attempt
to
keep
all
the
plugins
in
one
place
and
kind
of
split
out
the
spec.
So
the
spec
can
be
versioned
independently
at
the
plugins
in
a
much
better
way.
So
just
a
heads-up
to
anybody
who's,
relying
on
CNI
plugins.
A
M
C
C
Think
there
is
defined
criteria
at
this
point.
There
has
to
be
I
would
say
making
stuff
up
on
the
spot.
There
has
to
be
enough
traffic
on
a
particular
topic
to
warrant
having
a
label,
so
v6
seems
pretty
clear.
There's
going
to
be
a
long
series
of
four
requests
over
the
course
of
the
next
couple
releases
that
one
seems
obvious,
C&I,
possibly
I,
don't
know
how
many
bugs
there
are
related
to
our
CNI
implementation
in
the
main
repo.
A
C
Is
it
sufficient
to
say
component
cubelet
an
area
or
a
cig,
Network
I,
my
feeling
is
for
now
probably
okay,
it
could
be
a
problem
if
we're
losing
stuff
and
I'm
I
can
happily
agitate
for
more
labels.
We
just
did
a
big
culling
of
labels,
because
there
was
a
lot
of
labels
that
we've
never
used
or
only
used
once
or
twice.
M
C
C
C
So
on
the
topic
of
loci
I
think,
and
we
still
don't
have
a
really
solid
position
in
one
way
or
the
other
I
would
continue
to
say.
We
should
bring
that
to
the
mailing
list
to
discuss
specifically
use
cases
and
really
focus
on
concrete,
real
use
cases
that
we
can
bring.
As
example,
the
things
to
discuss
Tim.
A
C
C
N
C
A
That
I
can
Evo's
aren't
directly
I
mean
they're
related,
obviously,
but
I
think
v6
can
be
tackled
separately.
Anything
that
we
might
do
in
the
future
for
multi
network
would
obviously
include
multiple
IP
addresses
for
each
Network.
If
that's
how
things
shake
out
so
I
think
we'd
have
that
solved
either.
C
Way,
yeah
I
think.
The
interesting
thing
is
if
we
solve.
If
we
do
enough
plumbing
for
the
API
to
allow
dual
stack,
we
will
actually
have
done
a
lot
of
good
stuff
for
the
multi
network
problem
without
actually
having
tackled
the
contentious
part
like
those
are
the
obvious
parts
that
you
need
to
support.
Multiple
address,
yeah.