►
From YouTube: Kubernetes SIG Network 20161020
Description
Kubernetes SIG Network 2016-10-20 meeting audio recording
B
So
over
time,
so
this
Tim
for
background,
so
one
of
the
things
we've
been
working
on
in
the
node
team
is
a
runtime
abstraction.
So
once
upon
a
time,
qubit
was
very
docker
centric.
In
fact,
it
still
is,
and
the
bits
of
information
about
how
to
use
docker
and
docker
abstractions
we're
sort
of
sprinkled
all
over
the
code
base
as
any
good
organically
grown
software
would
do
and
we're
realizing
more
and
more
that
people
want
to
run.
Different
kinds
of
runtimes
is
rocket.
B
There's
hyper,
there's
at
least
a
half
dozen
others
that
we're
tracking
that
people
want
to
do
on
top
of
Cooper
Nettie's.
So
we
are
building
an
abstraction
called
the
container
runtime
interface.
Despite
the
fancy,
three-letter
acronym
is
not
sort
of
on
the
same
scale
as
CN.
I,
it
is
not
proposed
to
be
a
universal
standard
for
all
containers,
etc,
etc.
It's
really
just
a
bridge
between
cubit
and
a
separate
plug-in
that
lets
us
manage
runtimes
the
obviously
the
first
run
time
that
we're
supporting
as
we
port.
This
API
is
dr..
B
B
So
it
became
clear
that
at
some
there's
need
to
be
some
way
for
the
plug-in
side
of
this
link
to
be
able
to
do
networking
functionality
and
so
much
debate
and
it
still
sort
of
goes
on.
But
the
current
decision
is
that
the
networking
responsibility
goes
to
the
plug-in
and
not
too
cute,
'let
proper.
What
this
means
is.
B
We've
got
some
PRS
in
flight
now
that
are
going
to
be
adding
an
extra
level
of
indirection
in
between
cube,
lit
and
some
of
the
network
logic,
so
that
the
CNI
driver
itself
is
called
from
the
the
piece
of
code.
That's
called
docker
shim
now
and
as
we
crystallize
that
implication
that
will
sort
of
turn
into
a
library
that
other
plugins
can
use
if
they
want
to
do
CNI
support,
but
they
don't
have
to.
B
They
can
do
their
own
thing
if
they
want
to,
because
this
point
was
debated,
relatively
hotly
I
thought
it
was
worthwhile
to
bring
it
up
here.
So
if
people
here
see
these
sort
of
PRS
and
are
moving
things
around,
they
can
understand
some
of
what's
going
on.
That
said,
the
goal
is
to
get
CRI.
The
API
definition
to
alpha
in
15
feel
like
we're
pretty
close
to
that.
B
A
B
Doctor
sham
is
going
to
be
in
process
but
still
communicated
with
over
GRDC.
That's
only
for
ease
of
development
as
we're
going
through
the
early
stages
of
this
implication
is
that
over
time
they
will
be
out
of
process
with
separate
processes
that
you
can
get
for
me.
As
you
know,
he
nerves
as
separate
things
that
are
completely
distinct
from
the
Cooper
Nettie's.
To
point.
A
B
B
Executable,
no
there's
no,
no
current
date
that
we
want
to
commit
to
and
truth
be
told
it
may
be
that
if
dr.
is
the
vastly
dominant
platform
that
we
just
leave
the
doctor
one
linkedin,
because
we
have
to
bow
and
sort
of
simplify
deployment
to
as
flexibility,
so
having
into
fall
things.
That
decision
hasn't
really
been
made.
Yet.
Okay,.
B
This
time
right
correct,
there
are
no
changes
needed
for
plug-in
authors.
It
does,
however,
emphasize
the
need
for
all
of
this
stuff
that
we
currently
do
in
cube
net
all
the
things
that
wraparound
C&I
to
either
become
part
of
si
ni,
AI
e
hijos
ports
or
to
become
a
part
of
cube.
'let
that
is
really
truly
generic
across
all
plugins,
which
I
don't
actually
have
a
good
example
of,
or
to
just
be
jettisoned
pretty.
Okay,.
A
And
small
update
on
the
CNI
side
of
things
there
I
think
there
is
general
consensus
around
moving
most
of
these
things
towards
CNI
as
additional
bits
of
CN
I
configuration
and
as
plugins
in
CN
I,
first
party
plugins,
essentially
distributed
in
the
CNI,
repo
and
I,
think
there's
a
couple
bugs
still
open.
You
know
I
think
we
had
talked
well.
You
were
there
last
week
last
meeting
for
it
too,
but
we
had
talked
about
the
sort
of
templating
proposal
or
whatever
was
talking
about
in
one
of
those
bugs.
A
C
B
Eric
I,
yes,
so
the
question
I'll
proxy
frames
is
I,
don't
care
me.
We've
been
having
some
conversations
here
about
how
reliable
do
we
think
communities
is
and
how
comfortable
are
we
with
our
test
coverage
and
what
level
of
debt
have
the
different
things
taken
on
in
order
to
get
where
we
are
today,
and
we
thought
you
know
it
might
be
interesting
to
sort
of
survey
all
of
the
cigs
to
get
a
sense
of
those
things.
How
good
do
we
think
our
tests
are
like?
B
How
confident
are
we
that,
as
people
change
things
that
the
fundamental
networking
right?
Why
do
we
believe
that,
and
thank
you
feel
like
we've
got
significant
debt
that
we
need
to
pay
down
sorts
of
questions.
I,
don't
know
that
they
can
necessarily
be
answered
here
in
the
form
of
a
call,
but
I
think
it
would
be
interesting
to
start
in
danger.
B
A
B
I
agree
with
that
integration
and
end-to-end
tests
I
think
there's
a
lot
of
corner
cases.
Historically,
cumin
Eddie's
has
been
really
good
at
writing
tests
to
cover
weirdo
corner
cases
and
not
great
tests
for
recovering
the
normal
cases,
and
so
it
might
be
interesting
for
us
to
try
to
organize
an
effort
to
fix
up
some.
The
testing
in
the
16
cycle.
B
This
is
something
that
the
the
storage
sake
did
actually
really
well
they're,
going
through
right
now,
where
they,
they
had
some
very
frank
conversations
about
the
level
of
test
coverage,
around
storage
and
the
more
sunlight
you
put
on
that
more
scared,
everybody
gets
and
so
they're
getting
a
lot
of
changes
right
now,
fixing
up
tests-
and
it
actually
is
looking
really
good.
So
we
might
want
to
do
something
similar.
D
D
So
one
thing
I
wanted
to
potentially
run
by
you
guys
is
we're
trying
to.
We
have
a
bunch
of
tests,
but
it's
not
really
clear
who
is
working
on
who
is
interested
in
which
tests
oftentimes
it
could
be
potentially
maybe
just
one
team
may
be
multiple
teams,
and
so
something
we
are
trying
is
creating.
We
have
like
a
spreadsheet.
We
previously
try
to
identifying
individual
owners
for
tests
and
we're
not
super
certain
that
that
is
working
super
well.
D
So
what
I
would
like
to
ask
the
networking
sig
is
too
we
created
a
spreadsheet
and
you
guys
have
a
you
know.
Tab
on
that
spreadsheet,
for
the
sig
networking
team
is,
if
you
guys
could.
However,
you
want
to
go
through
and
list
one
list
tests
that
you
think
are
interesting
for
your
say
and
then
the
hope
is
that
over
time
we
can
make
it
easier
to
windows,
are
having
problems.
I,
get
that
information
to
you
more
quickly.
So.
A
I
did
take
a
quick
skim
over
that
particular
spreadsheet
that
you
would
sit
in
the
link
and
at
least
the
ones
that
are
tagged.
Networking,
as
well
as
some
of
the
service
ones
are
probably
very
relevant
to
this
group.
You
know
it's
like
the
pod
to
pod
node
to
node,
make
sure
you
can
transfer
data
through
the
service.
You
know
their
release.
The
number
of
those
that
looked
like
they
were
relevant
for
us.
D
Right
yeah
I
assume,
yes,
I.
Think,
let's
see
so
let
me
share
my
screen
here
for
a
second
and
so
their
spreadsheet
and
which
is
different
than
the
github
CSV
file
that
will
eventually
integrate
this,
but
I
guess
what
I
would
like
to
ask
is
for
you
guys
to
go
through
on
the
cig,
networking
and
sort
of
just
briefly.
You
know
look
over
all
of
these
and,
if
ya,
obviously
I
think
the
ones
that
say
networking
are
going
to
be.
D
You
know,
I'd
assume
that
for
the
networking
ones,
you
would
definitely
say
yes,
maybe
namespaces
aren't
interesting,
so
say
no
if
there.
If,
while
looking
at
these
any
of
these,
are
interesting
to
you
in
particular,
you
know-
maybe
you
could
put
your
actual
name
and
we'll
make
sure
that
that
information
is
recorded,
because,
right
now
we
have
a
bunch
of
random
assignments
which
we're
trying
to
identify
or
we're
trying
to.
You
know,
get
rid
of
and
minimize
random
assignments
and
yeah.
D
So
you
know,
but
potentially
I
wouldn't
I
suspect
that
I
mean
I
suspect
that
there
are
more
than
these.
You
know
twenty
test
cases
in
our
ed
sweet.
That
is
that
are
applicable
and
are
potentially
interesting
to
you.
So
if
that's
the
case,
I
indicate
that,
and
if
not
that's
also
interesting,
you
know
feedback
for
us
as
well.
Yeah.
A
D
Right
yeah,
I
will
share
that
out
with
the
sig
and
then
probably
I
don't
know
if
this
I
suspect
this
sig
is
probably
not
the
most
efficient
place
to
this.
Video
chat
is
the
best
way
to
iterate
over
that,
but
yeah
I'll.
Give
that
to
you
guys
in
you
know.
Maybe
can
you
take
a
look
at
it
this
you
know
next
week
or
two
and
get
back
to
me
sure
sounds
good
right.
D
D
There
I
mean
the
code
is
all
going
to
be
in
the
Cougar
Nettie's
repo
somewhere
and
I'll
start
an
email
thread,
and
if
there's
you
know
you
should
I
guess
probably
the
easiest
ways
is
their
search
for
it,
but
we
don't
I,
don't
think
we
have
any.
You
know
the
wrong
description
of
what
each
of
them
are
doing
like
yeah.
It's.
D
E
D
So
essentially,
you
know
if
you,
if
you're
familiar
with
I,
guess
how
most
of
the
EDS
there's
going
to
be
unit
tests,
which
is
going
to
be
a
cooper
Nettie's
of
path
and
then
there's
other
ones
or
ETS.
We
use
this
things
like
you
know,
win
and
it
and
etc,
and
that
gets
a
compiled
into
a
a
test
case
name.
So
if
you
see
a
test
case,
failure
on
test
grade
or
whatever
it's
the
same
rows
that
are
in
test
grid,
I.
F
D
A
H
H
That
people
like
us
can
run
to
make
sure
that
we're
implementing
all
the
network
functionality
as
expected
and
completely
and
correctly
so
that,
instead
of
writing
all
of
our
own
tests
to
check
that
networking
in
the
communities
clusters
turn
right.
You
have
some
tests
already,
which
we
can
just
run.
An
Aphrodite
cluster
has
been
brought
up.
B
In
some
fashion,
absolutely
we
have
a
bunch
of
tests
that
I
believe
are
labeled
as
conformance,
and
you
should
be
able
to
run
those.
If
you
didn't
figure,
they're
testing
docks,
it
you'll
explain
to
you
how
to
run
specific
tests
or
pestilence
it
a
CAG,
and
if
you
just
run
tests,
they're
tagged
as
conformance
you
should
be
able
to
just
run
that
part.
H
B
H
B
I
H
B
H
Just
just
a
note,
I
don't
think
that
the
networking
tests,
which
there
are
quite
a
number
of
good
ones
that
were
merged
in
the
past
couple
months,
but
there
are
actually
part
of
the
controller
okay
you're
running
it
you're.
Looking
for
the
networking
tag,
specifically,
you
may
be
in
addition
to
conformance,
but
if
you
just
run
conformance
you're
not
going
to
get
the
connectivity
tests.
A
J
Hello:
everyone,
my
name,
is
a
relief,
a
little
I
take
care
of
networking
stuff
at
rancher
labs,
a
quick
one
liner
about
rancher.
We
provide
a
platform,
a
company
platform
for
running
containers,
so
the
issue
that
I
wanted
to
bring
up
today
is,
like
you
know,
we
use
CNI
for
providing
networking
for
our
Cuban
Utley
solution,
as
well
as
for
Cathy,
which
is
our
own
scheduler,
and
we
want
I
wanted
to
know
like
what
is
the
plan
for
supporting
houseboat
both
on
the
few
black
side,
as
well
as
the
cnx
I,
not
sure.
J
A
A
At
least,
I
think
the
direction
I
would
go
with
it
is
trying
to
move
that
into
C&I,
so
that
your
C
and
I
plug-in
could
then
either
wrap
a
host
port
plug
in
and
get
information
automatically
freaky
blit,
or
that
you're
plugging
could
just
call
that
stuff
directly.
Okay,
yeah
there's
no
concrete
specification,
there's
just
kind
of
general
ideas
right
now.
In
fact,
you
make
the
upstream
stuff
for
C&I
work
in
the
way
that
we
want
to
work
for.
B
A
Yes,
so
there's
a
group
of
CN,
I
maintain
errs
from
various
companies
and
there's
regular
I,
think
bi-weekly
meetings
of
that
maintain
a
group,
but
there
aren't
necessarily
any
public
CNI
meetings
that
you
know
kind
of
like
this
group,
where
there's
a
cig
or
anything
like
that
for
I,
think
that
project.
But
that
said,
there
is
both
a
ir
c
channel.
I
think
there's
going
to
be
a
slack
channel
pretty
soon
for
C&I
as
well.
Ok,
so
yeah
any
any
and
all
questions
they're
definitely
welcome
contributions,
walking
as
well.
A
A
The
core
issue
there
is
that
coo
burnetii
is
encoded
as
sort
of
docker
ism
from
a
while
ago,
where
you
could
have
a
port
that
the
container
exposes.
Actually,
we
mapped
on
the
host.
So,
for
example,
you
could
contact
the
host
on
port
80
and
they
would
actually
using
iptables
magic
forward
that
to
a
particular
container
IP
address
with
a
completely
different
port
number.
So.
B
A
Alright,
if
there
aren't
any
more
questions
about
support,
stuff,
I
will,
in
the
meeting
summary
when
I
send
out
the
recording
link
as
well.
I
will
try
to
go
find
those
issues
that
relate
to
post
port
from
both
the
CNI
in
the
community's
perspective
and
paste
those
in
to
follow
along
if
they
weren't
too.
Some
of
them
were
pasted
in
the
channel
ready,
okay,
excellent
I
know
there's
a
couple
but
yeah
it
looks
like
Casey's
got
the
best
when
you're
the
big
ones
for
communities
there.
Okay,
so
multi-tenancy
follow-up
from
the
auth
sig.
A
There
was
a
meeting
yesterday
where
I
think
a
bunch
of
people
from
the
net
sig
we're
on
the
auth
call.
They
discussed
a
lot
of
stuff
without
security
and
something
or
other
first
and
then
we
got
onto
the
tendency
stuff,
and
my
recollection
from
all
that
is.
The
action
item
was
that
David's
was
going
to
create
a
google
doc.
That
would
have
two
sections,
the
first
being
use
cases
for
tendency
and
the
second
being
what
everybody
thought.
Their
definition
of
tendency
was
or
what
their
definition
of
a
tenant
was.
It
wasn't
David.
F
The
doc
and
sent
it
to
clayton
who
it
exists,
Clayton
Coleman,
who
would
expressed
interest
in
it,
just
to
look
it
over
before
we
send
it
out
to
the
signaling
list.
If
there's
anyone
else
who
wants
to
take
a
look,
I
mean
it's
like
two
paragraphs
long,
it
says:
here's
a
doc
filling
that
answered
to
the
two
questions
that
you
just
very
very
accurately
summarized
and
that's
it.
It's
very
freeform,
there's
not
much
to
review,
but
since
Clayton
had
had
expressed
interest
in
it,
I
wanted
to
send
it
to
him
to
see.
F
I
F
There
was
a
so
I
am
just
getting
up
to
speed
on
multi-tenancy
and
while
I
took
a
bunch
of
notes
on
the
discussion,
I
am
not
sure
that
I'm
in
a
good
position
to
to
summarize
it
I
mean,
I
think
I
think
there
was
there
was.
You
know
some
some
discussion
about
the
different
perspectives
on
multi-tenancy
coming
from
the
off
and
networking
areas
and
interest
in
trying
to
build
stuff
using
a
layered
approach
being
keeping
the
core
stuff
minimal.
F
A
Yeah
I'm,
not
a
problem
and
just
off
the
top
of
my
head,
I
recall
two
things:
first,
there's
a
lot
of
discussion
about
simplicity
of
network
policy
and
trying
to
make
the
simple
things
simple
or
try
to
keep
the
simple
things
simple,
and
you
know
I
I
tried
to
answer
that,
but
I'm
not
sure
that
I
had
a
very
good
answer
there,
because
you
can
certainly
jump
down
into
the
weeds
with
our
current
network
policy
model.
And
you
know
anybody
else.
A
If
you
recall
the
past
discussions
better
than
I
do
please
jump
in,
but
you
know
I
think
we
were
sort
of
assuming
that
most
people
wouldn't
be
programming
network
policy
directly,
that
that
would
be
somehow
made
easier
and
simpler
by
tools
and
utilities
kind
of
on
top
of
the
raw
network
policy.
That
would
make
things
easier,
at
least
or
you
know,
even
automated
translation
from
some
other
kind
of
policy
Janelle.
Our
policy
I
also.
K
What
one
thing
I'll
add
to
from
that
I
took
away
from
the
call
the
other
day.
There
seems
to
be
an
expectation
of
egress
policies
and
I.
Think
people
are
kind
of
scratching
their
head
as
to
why
Network
policies,
sort
of
don't
already
have
egress
policies,
and
we
could,
you
know,
don't
need
to
go
and
revisit
that.
That
was
one
thing
that
I
took
away
from
the
call.
B
I
B
B
A
Just
like
to
echo
crystal
that
to
my
impression
was
that
in
general,
people
seemed
to
think
there
was
some
kind
of
larger
concept
the
namespace
required
and
that
that
would
allow
multiple
namespaces
to
sort
of
be
owned
or
available
to
a
single
tenant
and
that
the
concept
also
somebody
talked
about
it
in
chat.
The
concept
of
mapping
that
tended
to
namespace
121
is
not
really
flexible
enough.
So.
B
K
E
Inspired
to
politeness
by
other
recent
events,
so
I,
actually,
my
instinctual
response
to
chris's
remarks
are
exactly
the
opposite,
but
I'll
save
those,
as
was
mentioned
earlier
too
till
after
we
get
some
more
requirements,
but
I'll.
Just
summarize,
I
I'd
like
to
see
how
much
we
can
I'd
like
to
see
if
we
can
meet
the
requirements
without
introducing
a
new
concept
or
rather
leveraging
the
ideas
of
our
back.
The
other
thing
I
wanted
to
say
is
I.
Think
I
heard
someone
say
a
few
minutes
ago.
E
That
name
spaces
are
not
necessarily
connected
to
the
network
concept
of
tenancy
and
that
kind
of
intersects.
With
a
fault
I
have
when
I
think
about
multi-tenancy,
I
tend
to
put
the
issues
in
two
big
buckets:
there's
the
API
access
and
there's
network
access,
but
my
problem
is
I,
don't
know
which
bucket
to
put
dns
in
so
I
also
list
the
NS
separately
and,
if
you're,
not
thinking
about
dns,
you
probably
ought
to
because
it
looks
a
little
bit
like
api.
It
looks
a
little
bit
like
network.
B
B
A
B
B
So
as
of
now
in
head
I
I
made
in
a
false
assertion
that
changing
the
way
we
denote
optional
would
actually
really
hard
and
then
Mickey
came
along
in
one
afternoon
fixed
it.
So
what
we
should
be
able
to
do
now,
I
haven't
tried
it.
Yet
what
we
should
be
able
to
do
is
remove
the
be
omid
empty
on
those
slice
fields,
and
then
it
should
preserve
the
semantics
that
we
want.
Once
we
remove
that
omit
empty
from
the
tag
it
will
differentiate,
know
from
empty
slice.
B
Now
we
need
to
make
sure
the
implementation
is
all
respected,
because
historically
it
didn't
work
but
I
think
that
should
work.
So
it
would
be
awesome
if
somebody
I'm
looking
at
k,
see
if
he
has
for
bandwidth.
Could
you
actually
go
out
and
try
that
and
if
so,
send
the
pr
to
just
remove
those
three
optionals
I
think
it's
three
slips
three
such
fields
that
we
care
about
yeah.
B
A
B
B
K
C
Done
with
it
or
policy
now
so
here
are.
This
is
Rudra
here,
sorry
just
joining
in
from
open
concave
up,
so
we
are
planning
to
release
the
network
policy
are
probably
in
the
next
couple
of
months.
One
question
that
I
wanted
to
bring
God
was.
There
is
no
notion
of
service
that
we
are
noticing
in
in
the
selection
mechanism.
I
think
that
was
overall
what
we
were
looking
at
in
terms
of
feedback,
so
maybe
I'll
write
up
more
and
send
it
out
on
the
hunting
budget.
Sure.
E
So
I
have
a
question
for
the
assembled
wisdom.
The
thing
that
I've
wondered
most
about
is:
what's
our
answer
regarding
intermediaries
that
obscure
the
address
of
one
side
or
the
other
arm.
Maybe
would
it
be
reported
to
productive
here
or
an
email
to
have
a
survey
of
the
existing
implementations
of
what
approach
they
take
to
that.
B
Yes,
I
mean
that
happen.
I
think
it's
worthwhile
to
look
at
it's
a
fair
question.
Certainly,
we've
spent
time
looking
at
how
to
dis
me,
eight
IP
address
mess
and
that
should
go
beta
in
15,
but
I
know
that's
not
as
possible
on
other
platforms.
So
I
would
like
to
see
more
of
what
problem
people
are
having
with
this
and
the
impact
it
has
on
network
policy,
we're
also
looking
at
things
we
can
do
automatically
to
sort
of
build
an
idea
of
identity.
B
B
Like
who's
within
a
cluster
who's
talking
to
whom
and
what
notion?
Could
you
use
for
identity
so
he's
working
on
a
model
around
the
service
accounts
and
trying
to
figure
out
if
there
was
a
way
that
I
could
automatically
figure
out
which
service
account
is
talking
to
me
from
within
a
cluster?
So
I
can
do
things
like
intracluster
rate
limiting
and
something
like
that.
E
B
A
google
person,
I
believe
it
was
Louis
and
they
are
they've-
got
some
ideas
around
stuff
that
they'd
like
to
bring
forward
from
the
sort
of
Google
way
of
managing
API
is
internally
and
it
you
know,
identity
matters
and
so
I
think
we're
coming
to
that
point.
Now,
when
we
have
to
start
thinking
holistically
about
identity
through
the
system.
Okay,.
A
A
Requires
all
of
the
network
plug-in
drivers
and
Cooper
Nettie's
to
affirm
that
they're
ready
for
network
operation
and
that
has
not
filtered
down
yet
each
CN
I
plug
in
but
and
I
think
there
was
some
agreements
in
that
discussion
that
at
some
point
in
the
future,
we
should
make
Network
plugins
say
yes,
I
am
ready
and
then
clear.
The
network,
readiness,
node
condition
for
nodes.
Is
that
something
that
the
priming
writers
on
this
call
would
be
okay
with
at
some
point
in
the
future,
obviously
with
some
further
coordination.
So.
A
Yeah,
I
don't
know
I
mean
I
haven't,
thought
too
much
about
implementation
of
that
yet
and
how
data
might
get
back
from
sea
and
I
to
the
two
giblet,
but
certainly
I.
Think
the
best
approach
would
be
some
way
of
getting
error
status.
General
error
status,
reporting
back
to
Cuba
through
CNI,
as
opposed
to
making
each
plug
and
go
out
in
your
clear
condition
in
the
API
server
itself.
A
A
So
currently
there
is
that
node
Network
ready
condition
that
gets
set
and
currently
it
only
gets
set
for
GCE,
and
that
requires
that
something
clear
that
condition
before
any
pods
will
be
scheduled
on
the
note
and
it's
set
for
GCE
and
it
is
set
on
cube.
Let's
start
up
when
the
see
when
routes
are
required,
sort
of
the
cloud
routes
thing.
The
issue
is
that
not
every
plug-in
requires
cloud
routes
to
be
usable
in
the
canonical
case,
for
that
is
cube
net,
because,
of
course,
cuban
doesn't
know
anything
about
multiple
nodes.
A
It
just
is
basically
a
local,
plugin
and
I.
Think
the
original
problem
was
that
cube
net
qubit
was
saying
it
was
ready
to
accept
pods
before
all
the
cloud
routes
were
set
up
and
so
pods
would
get
scheduled
on
the
node
and
they
wouldn't
be
able
to
do
anything
so
I
think
in
the
14
cycle
it
was
added
that
cube,
lit,
would
say,
I'm
not
ready
yet
and
then
the
route
controller,
when
the
route
controller
was
had
actually
added.
A
All
the
cloud
routes
for
those
nodes
would
then
clear
that
condition,
but
because
not
all
the
plugins
actually
care
about
Claude
routes
that
they're
sorted
required
there
and
I'm
trying
to
think
it
was
Justin
Justin,
be
I.
Think
yep
proposed
to
expand
that
AWS
as
well,
so
that
both
GCE
and
AWS
would
set
that
not
ready
condition
and
keyboard
startup.
But
the
problem
there
is
that
that
condition
is
really
about
cloud
routes.
B
J
A
I
mean
currently
the
uses
of
actual
network
plugin,
not
ready.
Our
cube
net
needs
to
get
the
pod
cider
before
it
can
do
anything.
So
that's
one
case
where
it
would
be,
it
would
leave
that
condition
and
then
be
able
to
clear
it
once
it
has
the
pod
cider
and
then
CN
I
plug
in
actually
would
be
able
to
report
ready
when
it
finally
has
configuration
available.
A
But
the
thing
is
neither
of
those
conditions
are
dependent
on
cloud
routes,
sure
which
is
what
initially
cleared
that,
but
hey,
basically
all
I'm
all
I
wanted
to
get
was
you
know
some
gauge
from
the
plugin
authors?
If
network
readiness
conditions
that
are
specific
to
the
plug-in
itself
would
be
useful.
B
Know
who's
coming
to
cube
com,
I
am
I'll,
be
there
a
seat,
12
people
of
their
cameras
off
that
was,
I
I,
guess
I.
She
ain't
made
that
a
rhetorical
question
I
think
he
spoke
about
this
before
and
resolved
not
to
hold
a
meeting
but
to
hold
a
ball
for
a
you
know:
beer
with
friends,
sort
of
thing,
as
opposed
to
actual
work,
which
sounds
fine
to
me.
This
can
be
plenty
of
actual
work
that
we
I
agree.
K
K
B
B
E
B
Sure
that
the
buff
track
will
be
on
the
same
days,
usually
they
would
either
be
like
in
the
evenings
before
or
after
any
reception,
or
something
like
that.
Okay,
so
let
me
let
me
check
that
sarah
and
I
will
see
if
I
can
propose
a
day
great.
I
want
to
throw
one
more
topic
out
before
we
run,
I
had
sort
of
mentioned
somebody
had
asked
if
they
could
join
the
sig
network,
github
team
and
there's
all
these
weird
github
akal
issues
could
have
been
part
of
the
org
to
join
teams
in
the
orion.
B
We
don't
really
want
to
add,
like
a
thousand
people
to
the
org,
so
one
of
the
suggestions
that
came
up
was
to
make
a
phony
github
account
whose
email
address
would
be,
in
our
sake,
mailing
list
and
forward
everything
from
Team
signet
work
on
to
the
mailing
list.
The
counter
to
this
is
it's
going
to
make
it
harder
to
filter
for
anybody
who's
on
both.
A
A
B
B
Any
other
topics
today,
I
have
none
Oh
home
fries
I
wanted
to
talk
to
a
quick
about
code,
freeze
anybody
who
is
working
on
things
that
they
want
to
get
in
a
make
sure
you're
tracking
in
the
features
repo.
If
it's
substantial
and
be
be
aware
that
the
code
freeze
is
in
three
weeks
and
if
you're
expecting
reviews
from
me
it's
time
to
start
bothering
the
heck
out
of
me.