►
From YouTube: Network Plumbing WG Meeting 2018-08-02
Description
Network Plumbing Working Group Meeting for August 02, 2018
A
All
right
recording
is
started.
This
is
the
network
plumbing
working
group
meeting
for
Thursday
August,
2nd
2018.
The
major
purpose
of
today's
meeting
is
to
go
over
some
quick
specs
updates.
Since
the
last
meeting
there's
a
couple
of
short
questions
and
I
think
we
can
probably
get
through
pretty
quickly
and
then
the
main
goal
again
is
to
basically
approve
of
the
spec.
If
we
all
think
that
it
is
sufficient
to
go
out
as
a
v1
again,
this
is
not
necessarily
the
end.
A
So
I
guess:
let's
kick
it
off.
From
last
week
we
had
a
couple
of
chair
not
last
week
two
weeks
ago,
in
the
mean
to
exclude
a
couple
of
changes.
The
first
one
was
a
fairly
major
change
from
the
namespace
of
the
annotations
and
objects.
We
decided
that
shorter
was
better,
and
so
we
used
the
k8s
abbreviation
instead
of
kubernetes
and
decided
to
update
the
spec
to
reflect
that,
so
that
that
change
has
been
made
and
also
I
added
a
example
of
config
list
in
the
Jason
scene.
A
So
beyond
that
see
the
next
item
in
the
agenda
was
there
were
some
requests
for
additional
CRT
short
object
names.
The
kubernetes,
CR
DS,
allow
you
to
define
some
short
aliases
or
short
names
that
you
can
use
when
referring
to
the
objects,
the
only
one
we
had
had
was
see
net
attached,
deaf,
just
kind
of
a
short
version
of
network
attachment
definition
and
so
I
think
Corral
and
Peter
had
asked
if
we
could
potentially
make
even
shorter
ones.
I
had
added
net
to
that
list,
but
I
think
Mike.
You
had
some
comments
on
that.
A
B
Met
deaf
is
the
problem.
Is
we
have
three
critical
concepts
in
there
or
if
you
leave
out
the
attachment,
it
sounds
like
you're
talking
about
the
definition
of
a
network
which
were
explicitly
not
so
I,
I'd
say
for
now
you
know:
net
attached,
def
is
about
as
good
as
we're
gonna
get
as
far
as
my
imagination
goes,
but
I'm
open
to
other
suggestions.
If
people
can
come
up
with
one
I,
don't
like
nad,
that's
got
a
slang,
meaning
I,
don't
think
we
want
I
have
been
able
to
think
of
other
sporter
ones.
A
Any
other
thoughts
would
it
be
acceptable
for
now
to
just
go
with
net
attached.
Def
I
mean
also
in
your
own
implementation
of
this.
If
any
of
you
are
writing
plugins,
you
can
obviously
add
anything
that
you
want
to
to
that
list.
The
specification
does
not
currently
limit
exactly
what
you
mean
what
you
can
do
with
it.
You
could
add
more
if
you
wanted
to.
C
D
C
C
A
I
will
record
that
decision
in
the
agenda,
doc
all
right
and
then
Peter.
You
also
brought
up
the
next
item,
which
would
be
to
make
the
CRD
parts
of
the
spec
optional.
If
you
want
to
kind
of
talk
about
that
or
explain
what
you
were
thinking
there
for
a
little
bit
while
I'm
typing
the
previous
decision
down,
that
would
be
great.
E
E
E
Okay,
I
guess
we
may
want
to
make
her
CRT
past
optional,
because
I
think
a
year
time,
yes,
I
mistaken
or
a
plug-in,
they
may
want
to
manage
their
the
network.
Information
and
their
customer
management
will
give
them
off
like
a
rapidity,
and
this
deity
may
not
have
meet
their
requirements
of
management.
E
A
Does
that
make
some
sense,
Mike,
I'm
I
think.
Basically
the
question
was:
can
we
make
he
would
like
to
make
the
CRD
object
optional,
but
they
still
want
to
use
the
status
and
the
selection
annotations,
but
not
necessarily
follow
exactly
the
same
object
so
in
the
selection
annotation?
That
would
be
the
same,
but
presumably
that
would
select
some
other
resource
that
may
only
be
known
to
that
plugin,
as
opposed
to
having
a
standardized
CRD
object.
A
D
A
B
E
B
C
I
mean
I
think
that
it's
probably
fine
to
say
that
it's
optional
to
do
that,
but
I
guess
kind
of
from
a
bigger
picture.
I
Peter
I'm
interested
to
hear
how
you
solve
that
and
how,
in
version
2,
maybe
we
could
expand
upon
this
idea
and
maybe
find
a
different
way
to
specced
fire
or
some
kind
of
decision
tree
on
how
you
know
an
implementation
might
choose
which
method
to
use
so
I
just
want
to
throw
that
out.
There.
E
A
Okay
I
mean
that
basically
sounds
like
if
everybody
else
agrees
and
Peter
agrees
that
maybe
we
could
plinth
this
particular
two
decision
to
v2
and
leave
the
speck,
as
is-
and
obviously
you
know
if
you,
if
your
plug-in
does
not
want
to
implement
or
chooses
not
to
implement
this
part.
That's
fine,
too,
does
that
everybody
sound
okay
with
that
particular
decision
to
discuss
this
again
for
v2
and
not
change
any
of
the
spec
language
around
this.
F
A
A
C
Absolutely
so
I'm
gonna
throw
in
chat
it's
also
in
the
it's
in
the
agenda.
The
gist
here
is
I,
went
and
took
our
kind
of
open
and
close
questions
from
the
bottom
of
the
doc
copy/paste
and
then
I
went
through
and
I
said,
hey
what's
the
stuff
that
you
know
kind
of
closed
for
sure
and
I
sorted
that
chaff
out
of
it.
I
then
had
like
a
few
things
that
were
kind
of
on
my
notepad.
C
That
I
had
chatted
with
people
about
so
I
just
put
kind
of
bullet
points
for
those
and
anyone
who's
interested
in
some
of
those
items.
You'll
see
they
just
don't
have
a
lot
of
sub
bullet
points
on
them
feel
free
to
flesh
them
out.
But
what
I
kind
of
thought
that
we
could
do
is
introduce
this
document.
It's
public,
you
guys,
can
go
and
edit
it
to
your
heart's
content,
put
whatever
you
want
in
there
and
then
you
know
at
some
later
date.
C
We
can
decide
to
kind
of
give
a
rundown
of
these
and
decide
haywood,
which
of
these
are
we
the
most
interested
in
for
version
two.
You
know
it's
like,
at
least
from
my
perspective,
I
think
in
some
of
the
most
recent
iterations
we
did
of
v1.
We
did
a
great
job
of
kind
of
you
know,
opening
the
door
to
creative
implementations
and
I.
Think
some
of
those
more
creative
implementations
may
be
of
interest
to
a
lot
of
people
that
were
involved
in
it
involved
with
you.
So
I'd
love
to
kind
of
expand
upon
those.
B
C
Definitely
need
to
get
those
on
there
yeah.
Certainly
you
know,
I
have
chatted
with
people
about
kind
of
resource
management
and
device
plug-in
considerations.
I
did
not
flesh
that
out
in
this
talk,
I'd
love
anyone
else
to
jump
in
and
flush
that
out,
but
as
far
as
service
mesh
I'm
definitely
interested
in
figuring
out,
where
there's
an
overlap
here
where
these
things
work
well
together,
but
I
certainly
would
defer
to
somebody
who
you
know
may.
A
B
A
A
G
A
A
All
right
next
agenda
item
is
to
Dan
Winship
I,
do
not
see
Dan
on
this
call,
but
I
guess
I
will
proxy
for
him,
and
this
was
kind
of
an
open
question
that
we
had
had
from
a
while
back
that
we
decided
to
punt.
His
question
was:
are
we
okay,
with
version
1?
Being
every
user
can
use
every
network
attachment
definition
assuming?
A
This
is
referring
to
some
of
the
access
control
that
we
had
talked
about
a
number
of
months
ago,
and
does
anybody
have
any
thoughts
about
that
I'm,
not
as
intimately
connected
with
some
of
that
stuff?
As
probably
some
of
you
are,
the
only
thought
I
had
there
was
to
add
some
quick
language
to
the
spec,
recommending
that
implementations
of
this
spec
add
some
kind
of
our
back
or
admission
controllers
to
you
know
if
they
wish
to
restrict
which
networks
pods
can
use
to
add
those
concepts
and
implementations
to
allow
that.
B
So
I
think
it's
fair
to
say,
III
kind
of
agree
with
you
know
the
sentiment.
Let's
get
something
done,
call
it
done
and
you
know
then
we
can
address
version
two
and
in
fact
maybe
it's.
You
know
we
go
to
version
one
Biss
and
so
on,
but
you
know
I,
like
that
line
under
what
we've
got.
I
think
that
the
fact
that
we've
got
objects
means
we've
got
kind
of
a
good
foundation
for
applying
our
back,
but
there's
not
quite
a
trivial
way
to
do
that.
B
A
A
You
know
having
some
kind
of
our
back
or
admission
control
their
language
in
the
spec.
That
does
that
so
I
guess
I
would
expect
that
if
the
implementations
want
to
do
that
that
they,
you
know
they're
not
specifically
prohibited
by
the
spec,
there's
no
language
in
it.
That
says
you
know
every
network
attachment
definition
must
be
available
to
everybody,
with
the
exception
of
the
default
cluster
Network.
So
I
think
you
know.
If
we
kind
of
leave
that
open,
then
that
should
be
sufficient
for
the
moment
and
implementations
that
want
to
do
this
can
do
it.
B
It
wasn't
obvious
to
me:
I
mean
I
I,
think
you
could
reasonably
argue
that
it's
implied
that
they
are
all
accessible.
So
if
you
want
actually
put
in
some
explicit
words
saying
they
might
not
necessarily
be
all
accessible,
the
implementation
may
restrict
access.
I'd,
be
fine
with
saying
just
that
much.
A
We
can
circle
back
around
and
take
a
look
at
the
language
that
I've
added
to
the
spec
and
then,
if
everybody's
happy
with
that
language,
I'd,
like
you,
know,
kind
of
general
agreement
or
voice
vote
or
whatever
that
we're
fine
with
the
specification
and
that
we
agree
and
then
we
will
send
v2
or
excuse
me,
V
one
off
into
the
sunset
as
a
complete
spec.
Does
that
so.
A
B
A
B
A
A
D
A
B
B
A
B
All
right
yeah,
if
you
make
it
2,
4
6
8,
we're
great
1,
1,
2
3
doesn't
work
so
well.
Okay,
next
one
section:
this
is
a
more
debatable
wording
thing
in
Section.
Four
point:
two
point:
one
rule
three
talks
about
C
and
IIF
name
being
generated,
but
the
preceding
section
says:
well,
maybe
actually
the
user
is
specifying
this,
the
if'
name.
So
I
was
just
thinking.
We
might
want
the
language
in
rule
three
to
be
a
little
more
clear
that
it's
not
contravening
what
said
proceeding
all
right,
good
point.
A
So
would
you
be
okay
with
wording
added
four
point:
three?
Okay,
so
just
for
the
record
point
three
currently
says
c
and
I
underscore
is
name
colon
generated
by
the
cni
delegating
plugin
for
given
attachment
dot.
Would
you
be
okay
with
see
here
CN
I
underscore,
if
name
:,
if
not
specified
in
the
network,
attachment
selection,
annotation
generated
by
the
CNI,
delegating
plugin
sure.
D
B
C
C
A
B
C
H
B
Look
at
the
whole
sections.
It's
alternate
alternate
readiness
method
right,
so
the
alternate
readiness
method
says
that
it
can
be
up
to
the
plug-in
to
hold
until
the
default
is
ready.
Okay
and
the
implementation,
our
our
implementation
of
our
better
plugin
or
whatever
has
the
option
to
not
hold
for
more
than
two
minutes
and
I.
Think
that's
in
contests
in
in
conflict
with
some
of
our
cell
hosting
scenarios,
where
the
you
know
the
couplets
are
there
more
than
two
minutes
before
the
default
network.
Is
there.
B
Concerned
about
a
timeout
right,
because
my
understanding
is
the
couplets
basically
spin.
Until
today,
right,
the
COO
is
spin
until
the
network's
ready,
no
matter
how
long
that
is.
So
my
suggestion
is
just
just
forget
about
the
timeout.
Just
stop.
They
wait,
wait
sit.
This
option
here
is
to
wait
until
it's
ready
period,
no
timeout.
C
C
What
I
did
was
I'm
like
I'll,
go
into
a
wait,
loop
and
I'll
just
wait,
X
amount
of
time
and
interval
until
two
minutes
is
reached,
and
then
you
know
be
good
to
go,
but
after
talked
to
those
guys
they're
like
man,
there's
an
exponential
back-off
gonna
be
a
nicer
solution
and
the
more
that
I
think
about
it.
The
more
I
had
liked
it
and
I
have
my
own
full
request
on
that
feature.
C
Blocked
over
this
and
there's
part
of
me
that
thinks
just
having
the
exponential
time
out
is
just
fine
and
it
can
just
wait
longer
and
longer
each
time
for
that.
In
my
particular
case,
I
feel
like
that
looks
better
feels
better,
so
I'm,
I'm,
okay,
actually,
and
maybe
even
I,
would
prefer,
in
my
own
case,
to
just
say
hey.
Why
not?
Why
not
just
let
this
go
on
until
until
it
happens,
because
the
bummer
is
right.
If
you
time
out,
then
somebody's
gonna
have
to
go
restart
those
pods
or
something
some.
A
hey.
D
C
A
B
G
A
C
A
Here's
what
I'm
going
to
do
I
will
update
the
specification
in
Section
six
one
two
and
simply
remove
the
language
around
well,
okay,
first,
what
I'll
do
is
I'll
read
what
it
currently
is
and
I'll
read
what
I
will
change
it
to
and
comments
on
that
appreciated.
It
currently
reads:
the
implementation
must
then
block
any
pod
network
attachment
detachment
operations
until
the
cluster
wide
default
network
is
ready
or
until
a
suitable
timeout
is
reached.
A
The
recommended
timeout
value
is
two
minutes
I'm,
proposing
that
we
change
that
to
the
implementation
must
then
block
any
pod
network
attachment
detachment
operations
until
the
cluster
wide
default
network
is
ready
period,
so,
in
other
words,
remove
the
or
until
a
suitable
timeout
is
reached.
The
recommended
time
of
values.
Two
minutes
we
just
chop
that
part
off
does
that
sound,
acceptable
plus
one
for
me
sounds.
D
A
D
A
So
circling
back
to
the
permissions
issue,
I
added
a
section,
seven
point:
four:
in
the
runtime
and
implementation
considerations,
section
titled,
restrictions
on
selection
of
network
attachment
definitions,
bipods
and
that
section
currently
reads:
implementations
are
free
to
impose
restrictions
on
which
network
attachment
definitions
can
be
selected
by
a
given
pod.
This
can
be
done
by
our
back
admission
control
or
any
other
implementation.
Specific
method
does
that
address
the
questions
we
have
around
permissions
in
our
back
or
should
we
change
that
language
in
some
way?
Well,.
A
A
B
A
B
I
think
this
is
explicitly
saying
the
implementation
gets
to
decide
that
in
some
and
they
specification
is
not
specifying
that
I
mean
that's
the
way.
I
read
the
language
that
they
were
l,
it
says,
implementations
are
free
to
impose
restrictions
which
clearly
implies
and
agents
do
not
have
to
impose
restrictions
and
also
implies
that
witch's
frictions
are
imposed
is
not
being
specified.
F
A
A
A
F
A
A
H
A
A
We
will
certainly
talk
about
a
v2
specification
and
talk
about
all
those
things
that
we
have
essentially
punted
from
this
specification,
but
I
think
we,
as
Mike
talked
about
earlier,
do
need
to
get
a
good
solid
base.
It's
obviously
not
going
to
be
perfect
for
everybody,
but
hopefully
we
can
continue
to
address
some
of
those
concerns
and
fine-tune
things
over
the
next
couple
of
months.
E
E
E
E
Okay
differently
from
CR
delegating
plugins
such
as
madhouse,
neither
is
a
snake
plug-in.
It
has
the
fourth
component.
It
had
four
components:
Neera
Neera
need
her
monitor,
neither
Eden
Anna,
neither
plug-in
and
eight
have
processes.
All
of
the
network
attachment
workflow.
The
this
diorama
showed
how
need
her
components,
interacting
with
each
other
and
the
kubernetes
components.
E
The
first
component
is
made
hermanita,
it
has
many
tenants
and
then
it
works
by
the
way
it
had
in
the
used.
Crd
to
stir
native
of
information
currently
near
Manila
also
allocates
IP
address
to
pod,
and
the
state
might
need
a
monitor
and
it
monitor.
What
is
the
creation
and
the
finishing
of
a
pod
a
way?
A
party,
the
created
the
money,
the
will
cater
the
event
remove
Cuba
API
server:
either
they
increase
the
port,
an
ignition
and
passive
water
networks.
E
The
porter
wants
to
attend
to
everything,
asks
Anita
manator
to
allocate
her
IP
address
to
the
product.
The
components
are
deployment,
take
on
master
and
the
other
two
components
are
need.
Aidan
and
I
need
a
plugin.
They
are
on
the
Noda
wing
when
the
product
is
the
landing
another
near
the
flooding
will
be
evoked
by
too
late.
E
The
plugin
does
the
forward
requests
to
neither
a
tent
and
the
18-wheeler
asks.
We
ask
near
monitor
for
IP,
address
and
other
necessary
information
for
the
product,
then
the
monitor.
Okay,
then
these
are
yeah
when
the
eating
her
theta
F.
He
and
other
information
from
the
monitor
made
a
will
to
the
real
attachment
work
program
or
creating
interfaces
right
him
float
about
and
attaching
the
interfaces
to
the
network.
Numerous
ways.
E
The
following
are
some
main
features
of
nature:
the
first,
the
first
one
is
that
a
test
words
for
the
native
network
of
modern
economists
follow
the
path
attached
to
a
class,
the
ride
network,
if
you
know
the
tundra,
stratify
network
administration
and
efficient
and
the
portrait
edge
to
multiple
networks,
and
that
created
the
related
MIT
for
interpreted.
Yet
this
is
the
trustor.
What
we
want.
E
Neither
also
supports
for
multiple
tenants
the
tenant
moves
to
the
numerous
ways
in
communities.
Tennis
can
share
public
and
share
a
public
network,
for
example
dirt
before
the
cluster
right
a
network.
They
can
also
have
their
own
improvident
networks.
A
tenant
had
private
a
network
is
isolated
from
other
tenants.
Probably
the
networks.
E
Neither
try
and
keep
our
IP
address
for
product
even
after
it
has
recreates
in
place.
That
means
if
the
UUID
of
the
Potter
doesn't
change
its
IP.
We
another
change.
Why
not?
One
example
is
that
April,
pod,
infra,
Nina
or
poster
cleaner
is
a
cuter
by
accident.
The
Prada
will
be
recreated
in
place.
In
this
case,
the
IP
will
not
change.
E
Neither
had
a
concept
over
IP
group.
We
have
a
Eutychus
that
users
want
to
return.
Some
specified
IP
address
for
the
application
we
can.
Stratify
did
Ivy
addressed
into
an
IP
group
opera
about
the
Chi
reference,
the
IP
group
in
its
network,
that
winter
selection
annotation
and
they
need
a
real
LAPD
I
addressed
from
the
product.
Only
from
that
IP
address.
E
E
E
E
Yeah
allow
other
introduction
to
later,
and
these
are
these
are
the
items
I
want
to
show
in
demo,
because
I
I'm
not
sure
if
my
environment
exists
ago,
so
I
recorded
the
demo
and
I've
alluded
to
it.
Harbor.
Let's
take
a
look
at
hate.
The
first
one
is
before
the
clouds
to
our
the
native
a
kind
of
stories.
A
E
B
E
E
A
A
All
right,
if
not,
let's
close
the
meeting
out,
thank
you.
Everybody
and
I
have
tagged
v1
of
the
specification
in
the
Google
Doc
changes.
I
have
also
saved
a
PDF
in
an
edible
copy
locally
and
I
will
send
those
out
to
the
mailing
list
and
investigate
where
we
can
post
those
online
so
that
we
have
a
more
permanent
and
accessible
record
of
the
view
in
spec,
as
we
have
approved
it.