►
From YouTube: Kubernetes SIG Network 20170112
Description
Kuberentes SIG Network 2017-01-12 meeting
A
Right
we
are
now
recording
and
with
that
I
had
recorded
that
I
think
the
past
three
meetings
and
they
are
now
posted
on
YouTube
and
the
crew
benetti's
channel.
However,
I've
only
posted
the
audio
of
those
meetings,
although
I
do
still
have
video.
So
what
I
wanted
to
throw
out
the
group
was
that
making
sure
that
that's
okay
to
post
video-
and
if
you
don't
want
a
video
of
yourself
on
youtube,
then
maybe
just
keep
your
camera
off.
A
B
A
C
A
Okay
yeah,
my
the
reason
I
put
that
on
the
agenda
was
that
they
would
spend
some
movement
I,
think
Makos
posted
a
host
for
plugging,
hosted
elsewhere,
and
so
maybe
that's
something
interesting
to
look
at.
But
then
there
also
seems
that
there's
some
movement
on
the
kinase
act
in
with
some
of
the
people
working
the
docker
same
parts
as
well.
A
D
So
so
this
is
me
not
I'm
not
have
to
be
walking
on
the
gawker
stem
and
basically
the
doctor
shim
needs
some
checkpointing
in
order
to
reliably
create
and
teardown,
not
even
basically
reliably
use
CN
I
plug
in
so
I
have
a
proposal
open
and
still
in
discussion
and
I'm,
trying
to
put
up
a
I'm,
also
putting
up
the
installation,
try
to
hype
it
up
together
and,
let's
see,
what's
what
else.
I'm
is
and
also
find
out.
This
I
don't
have
a
like
a
workable
CNI
host
for
plug-in,
but
still
for
the
cube
net.
A
The
440
okay
from
some
of
the
issues
that
I
dread
it
seemed
like
well
long
ago.
There
is
discussion
about
splitting
up
host
port
responsibility,
half
between
the
runtime
and
a
half
between
the
sea
and
I
plug
in
itself.
I,
don't
know
where
we
landed
on
that,
but
I
think
you
were
pursuing.
Having
that
split
I,
wonder
if
maybe
you
be
an
okay
idea
to
keep
or
to
put
most
of
that
in
cna
or
into
the
CNI
plugin
for
host
ports
or
if
you'd
rather
keep
some
of
that
inside
the
12.
So.
B
The
argument
for
the
split
was
most
C&I:
plugins
are
short-lived
and
have
no
long-running
anything
right
right
and
your
lips
port
mapping,
even
in
the
iptables
mode
of
height
of
host
port
mapping.
You
really
want
something
long
live
to
hold
that
port
open
so
that
nobody
can
no
other
process
can
open
the
port,
and
so
the
decision
at
the
time
was
yeah.
We
want
to
deal
with
that.
I
would
be
fine
to
make
that
I
mean
if
it
is
properly
the
cmi
responsibility
right,
yeah.
A
So
the
one
plugin
that
does
not
do
the
shortlist
thing
entirely
as
a
dhcp
plugin
in
CA
and
that
kind
of
spawns
a
single
process,
client
on
the
first
run
of
the
dhcp
plugin
and
then
uses
RPC
to
send
requests
to
that
client
back
and
forth.
So
the
current
can
maintain
some
states
and
other
things
like
that
across
the
lifetime,
the
plug-in
run.
Someone
thought
that
I
had
was
that
may
be.
A
A
host
for
plugging
could
work
the
same
sort
of
way,
the
first
time
that
it
would
run
and
kind
of
spawned
that
executable
and
then
send
requests
back
and
forth
to
allocate
that
host
port
and
keep
it
open
on
the
host
side
before
actually
sets
up
container.
So
that
might
be
at
a
future
enhancement
there.
If
we
want
to
move
that
fully
into
see
and
I
and
get
returns
out
of
the
business
of
this
entirely
I.
E
F
B
Don't
have
a
requirement
on
it.
The
requirement
is
rather,
the
semantics
is:
if
we
don't
hold
it
open,
then
some
other
user
could
open
it
and
then
wonder
why
their
program
doesn't
work
at
all
right,
and
so
it's
sort
of
a
polite
thing
to
do
to
say,
like
I'm,
actually
consuming
this
port,
so
I'm
going
to
consume
the
port
for
real.
It's
not,
it
would
be
not
critical.
If
we
didn't
do
that,
I
think,
but
I
think
the
right
thing
to
do
is
make
us
to
make
a
scene.
I
driver
and
I
want.
A
C
Yeah
I
think
I
think
I
agree
that
it
feels
like
the
responsibility
of
the
CNI
side
of
this
interface.
I
might
question
where
it
should
fit
and
the
road
map
in
terms
of
implementing
this,
so
is
this
MVP.
First
first
iteration
and
kind
of
with
that
question
comes:
do
we
have
a
good
sense
of
how
much
work
this
is
going
to
be
cat?
Is
this
something
that
we
can
consider
as
a
1.6
feature
or
the
saw
1.7
feature.
A
B
Can
we
might
turn
our
attentions?
We
have
a
PRS
for
just
second
server
in
order
to
get
its
really
working,
we
need
the
check
pointing
in
CRI,
but
we
also
need
to
agree
on
the
chaining
proposal
right
now
and
we
need
to
define
what
the
plumbing
is
for.
How
do
we
pass
those
parameters
down
into
a
OS
port
plugin?
Yes,.
A
So
we
had
a
CNN,
a
terrorist
discussion
earlier
this
week
and
kind
of
decided
on
the
approach
for
the
chaining
stuff,
which
I
did
update.
That
PR
then
did
a
repo
with
those
changes.
So
I
think
that
PR
right
now
kind
of
reflect
the
thoughts
of
the
CNI
maintain
errs
and
the
two
things
that
does
remove
are
pulling
the
eye
Pam
stuff
out
into
a
separate
block,
and
it
also
implements
doing
bottom-up
calling
of
network
lists.
A
So
the
reason
for
the
Iban
change
was
that
it
would
interact
as
well
with
dhcp
at
the
moment,
but
it's
also
something
that
we
think
we
can
do
backwards
compatible
in
the
future.
As
in
we
start
with
this,
we
start
with
embedded
ipam
in
the
network
locks,
and
then
we
could
at
some
future
point
pull
the
I
pan
plugins
out
into
their
own
separate
blocks
top-level
fairly,
easily
I
think
so
we
figured
start
small
get
larger,
but
I
think
that
this
will
work
for
most
cases
right
now.
A
B
Right
I
will
reread
that
PR.
Let
me
give
us
the
ability
to
run
multiple
plugins
and
sequin
yep,
how
about
the
passing
of
host
ports
2
p-9,
like
by
filling
it
will
basically
modifying
host
ports
as
part
of
this
t,
nine
teacher
set,
and
so
we
should
just
add
an
n
bar
or
something
that
is
those
port
mapping
that
we
expect
I
would.
E
So
at
the
moment
we
have
in
in
the
official
CNI
plugins
the
ones
that
exist
in
that
repo.
There
is
exactly
one
special
field
and
I'm,
not
sure,
that's
actually,
even
in
the
spec
or
it's
just
in
the
host
local
documentation
to
say
there
is
this
one
field
to
set
the
IP
I.
Think
that's
the
only
kind
of
precedent
we
have
four
for
this
kind
of
thing
and
you
definitely
need
to
check
whether
that's
in
the
swag
there's.
B
A
there's
a
difference
between
the
special
fields
that
are
in
the
JSON,
which
are
interpreted
on
a
per
plug-in
basis
and
the
parameters
that
are
passed
from
the
wrong
time
to
the
plug-in
on
the
deck
for
passing
environment
variables
and
are
effectively
standardized
right.
There's
a
bunch
of
the
bar
stuff.
E
Yeah,
I
think,
was
embarrassed.
Images
have
those
things
so
and
I'm
not
sure
that
who
supports
obviously
falls
into
that
set,
but
there's
a
there's,
an
extension
mechanism
in
the
arcs
in
the
environment,
fields,
which
is
this
article
ammeter,
but
there's
also
a
corresponding
args
field
in
the
the
network,
configuration
which
can
be
used
as
well.
So.
E
It
no
so
I
think
single.
That
is
something
that's
in
that
falls
into
the
sea,
mi
spec,
as
it's
really.
I
think
that
some
things
that
there
happens
to
be
one
field
like
that
at
the
moment,
which
is
the
IP
field,
which
can
be
an
arg
for
the
one
plug-in
host
local
plugin,
and
so
that
has
become
a
kind
of
convention
and
we
can
try
and
establish
a
similar
convention
for
plugins
are
going
to
host
port
setup.
E
A
B
A
A
A
B
E
E
Go
love
the
pr
isn't
necessarily
right,
yeah,
fair
enough!
Very
mr.
Casey
can
can
I
just
double
check.
I
didn't
quite
follow
everything
that
a
minute
was
saying
on
the
the
plan
on
Cuba
Nettie
side
so
as
I
understand
it
with,
we
have
this
CR
icing
and
the
doc
ashim
sitting
behind
CRI
and
the
doctor
shim
is
using
CNI
to
do
its
networking
minute.
You
also
mentioned
cube
net.
Are
you
saying
that
you're
intending
to
current
cube
net?
E
D
E
B
E
So
I
mean
this
is
probably
just
showing
I.
Don't
fully
understand
that
the
CRI
plans
so
me
as
a
user
using
the
cube
'let
in
1.6
I'll
have
a
choice
of
using
CRI
or
or
using
the
existing
thing
that
there
is
at
the
moment
right
now
and
we're
saying
that
this
post
port
mechanism,
with
the
information
passed
over
the
cna
interface
as
a
user
I,
should
be
able
to
use
that,
whether
I'm
using
CRI
or
not
yes,
yeah,
okay,
cool,
looks
good.
C
B
B
There
exists
or
will
or
could
exist,
implementations
of
services
and
service
bits
where
the
packets
actually
arrive
at
the
destination
machine
with
the
Vic
intact,
and
the
network
policy
API,
as
currently
spect
lists
the
subject
of
the
policy
as
a
pod
selector.
So
the
obvious
thing
to
do
when
I'm
using
quoting
fingers
aren't
obvious.
The
obvious
thing
to
do
would
be
to
take
that
pom
selector,
expand
it
to
a
set
of
Cod's
extract.
The
IP
addresses
and
write
some
firewall
rules
based
on
those
IP
address.
B
If
the
service
VIP
is
intact,
that
will
not
match
any
of
those
policy
address
and,
as
such
network
policy
will
not
work
correctly.
With
that
service
interval,
notation
and
I
think
that
this
is
a
valid
services,
implementation
and
I
guess
maybe
that's
up
for
debate,
but
I
I
feel
like
it's
valid
and
as
such,
we
need
to
think
hard
about
what
the
right
answer
is
with
respect
network
policy
like
I
feel
like
we
might
need
meat
guide
change
so.
C
Tory
I
have
that
kind
of
thought
about.
This
briefly,
is
that
there
isn't
a
requirement
that
all
network
all
of
the
implementations
work
with
all
service
implementations
or
any
you
know,
C&I
implementation
and
there's
nothing
fundamentally
about
the
spec
that
would
prevent
this.
You
know
the
service
implementation
you're
talking
about
from
working
with
network
policy.
It's
just
that
the
way
people
have
implemented
it
today
might
not
well.
B
There
was
a
really
good
counter
to
that
which
is
brought
up,
which
said
given
a
pod
selector
I
can't
actually
figure
out.
All
of
the
IP
addresses
that
I'm
supposed
to
allow
into
this
machine
without
accidentally
opening
the
door
to
other
two
other
services
right.
If
you
have,
if
you
have
pod
services
there,
superset
selected,
you
can
end
up
opening
those
pods.
When
you
didn't
mean
to.
B
C
B
G
And
also
kind
of
related
to
this
in
the
validation
I've
been
I
filed
yesterday.
It
realized
that
if
you
have
a
string
as
the
port
for
a
network
policy
that
does
suppose
be
matched
against
container
port
definitions
on
the
odds,
meaning
each
pod
in
the
namespace
could
be
accepting
the
same
policy
on
a
different
port
turns
out.
G
E
G
You
would
have
to
match
the
traffic's
going
both
into
and
out
of
yes,
so
in
openshift,
current
multi-tenant
stuff,
pre
network
policy,
we
do
all
of
the
policy
checking
going
into
services
and
then
assume
that
everything
coming
out
of
a
cute
proxy
has
already
been
validated
and
so
can
just
be
accepted.
There
are
some.
F
B
B
Alright,
here's
an
example,
so
you
have
pod
a
which
has
an
address
a
and
it
has
labels
label,
one
label
cool
right
and
we
have
pod
B,
which
has
only
label
one
and
I
have
a
service
which
is
based
on
label
one.
So
the
network
policy
which
selects
babe
pods
are
based
on
sorry
the
network
policy
selects
label
to.
In
order
to
do
the
pod
selector.
We
have
to
then
go
up
to
the
services
and
say
show
me
all
of
the
services
that
include
this
pod,
which
would
include
both
pods,
a
and
B.
F
Not
going
to
quit
I
understand,
certainly
that
a
service
may
have
more
endpoints
than
a
certain
policy
applies
to,
but
I
thought
you
were
talking
in
this
thread
about
an
implementation
that
is
still
filtering
adjacent
to
each
pod.
So
for
each
pod
you
can
say
what
are
the
relevant
services
for
this
pod
and
include
their
VIPs
in
the
allowable
destination,
addresses.
F
B
All
right
I
sent
it.
I
hope
I
didn't
hope
that
wasn't
offensive
I,
don't
we
don't
use
all
to
hear,
but
I
do
think
we
need
to
think
about
it.
What
if
any
API
changes
we
can
make
so
going
back
to
changing
instead
of
a
pod
selector
having
it
be
a
service
name
or
a
service,
local
object.
Rest
would
be
I,
think
clearer,
and
the
existing
implementations
would
have
a
relatively
simple
transformation
to
make
it
work.
B
F
Well,
I
would
like
to
argue
that
maybe
that's
the
right
solution,
based
on
analogy
to
the
way
things
have
been
working
for
the
previous
very
long
time.
Right
I
mean
in
a
lot
of
the
world,
there
are
four
simple
user
level
proxies
and
load.
Balancers
people
write
firewall
rules.
Knowing
the
package
are
going,
you
know
what
pretty
explicitly
the
case
of
packages
for
risking
like
are
going
to
back
end
differently,
and
you
know
people
can
live
with
that.
It
Maps
fairly
directly
to
implementations,
might
actually
be
the
best
solution
to.
F
G
B
I
think
if
I
think
at
that
point
you
do
the
obvious
thing
if
you
specify
a
pond
selector
you're
allowing
traffic
from
those
pods,
if
you
can
do
better
than
that,
like
bully
for
you,
but
I,
think
it's
not
reasonable
to
expect
it
to
magically
work
in
all
implementations.
If
you
wanted
to
apply
policy
to
a
service,
you
have
to
specify
the
surface
and
actually
I
would
say
the
vast
majority
of
cases.
People
should
be
specifying
services
and.
G
F
F
Right
on
that
other
question,
the
previous
one
I
think
we
ought
to
allow
the
source
to
be
independent
of
the
implementation
so
and
I
that
not
necessarily
disagreement,
but
I
want
to
be
really
clear
right.
It
is
a
challenge
because
if
you
want
the
source
to
be
independent,
the
implementation
needs
to
work
reasonably
for
all
the
implementations.
F
B
G
I'm
I,
that
if
they
want
to
accept
connections
either
to
heat
service,
IP
address
or
directly
to
the
pod
IP
address,
then
they
can
just
specify
teacher
for
Network
policies,
one
allowing
to
the
service
and
one
allowing
to
the
pause
and
if
they
don't,
then
they
just
that's.
Why
I
want
any
other?
Well.
F
Again,
I
look
at
it
again,
first
off
with
it
to
find
the
semantics
of
the
input
to
the
API.
So
if
so
the
question
there
is,
if
you
write
some
policies
that
apply
to
a
service,
so
you're
our
policies
applies
to
services.
Another
policy
that
applies
to
some
pods.
Are
they
combined
with
and
or
or
we
define,
that
pictures
of
the
source
network.
G
F
What
I
that's
the
answer?
I
would
recommend
I'm
glad
to
see
you
assumed
it
without
even
take
either
the
question.
Now
we
get
to
the
implementation,
if
it's
in
or
the
implication
is
that
if
a
user
creates
a
network
policy
that
only
speaks
to
the
pod
that
only
one
policy
that
addresses
the
pods
and
not
the
service,
then
that
tells
me
that
I
think
I
mean
the
my
interpretation
I
mean
maybe
I'm
just
down
one
rut.
F
My
interpretation
would
be
that
if
the
sender
sends
a
packet
with
destination
equals,
edris
that
would
be
allowed
in
the
sender
sends
a
packet
with
destination
equals
server
Smith
it
would
not
be
allowed,
which
is
a
property
that
our
current
implementation
would
combine
with.
Coop
roxy
is
impossible
to
implement.
H
G
C
G
F
G
K
K
K
The
signatory
meetings
are
generally
quite
focused
on
L
tree
stuff
and
below
I
was
wondering
it,
but
you
know
there's
a
number
of
different
topics
that
I
sent
out.
The
group
recently
so
much
have
engendered
more
conversation
than
others.
Whether
this
is
in
fact
the
right
audience
or
for
this
subject,
I'm
pretty
sure
there
are
plenty
people
out
there
and
care
a
lot
about
this
stuff.
I'm
just
not
sure
that
either
they're
aware
that
this
board
exists
or
that
rare
for
not
finding
ways
to
bring
them
to
the
table.
You
know
we're
all
the
ingress.
A
B
Think
that
would
be
really
useful,
because
I
think
I
mean
we
have
been
very
focused
on
the
lower
end
of
the
stack
and
there's
I.
Think
significant
work
to
do
and
I
know
Louie
and
his
team
here
have
been
trying
to
get
some
community
buy-in
on
some
ideas
and
I'm
just
guilty
as
anybody.
But
we
haven't
been
real,
responsive
in
terms
of
getting
meaningful
feedback
which
I
guess
one
could
argue,
is
tacit
approval
to
do
whatever
that
you
want,
but
not
really
right.
I'm.
K
Going
to
feel
like
going
and
shooting
all
the
Buffalo,
so
you
know
absent
any
feedback.
You
know
it
will
remain
these
spaces
and
anything.
You
know
anything
interesting
that
anybody's
going
to
do
won't
happen
in
turn
30
resource
or
an
annotation
effectively,
which
is
not
necessarily
ideal,
given
no
more.
At
least
one
I
think
the
real
use
cases
are
an
idea
I'm
not
covering
people's
real
news
cases,
but
I
have
some
experience
in
this
area.
K
F
F
A
There
is
an
original
one
that
was
on
December
nineteenth
proposal
for
better
ingress
routing,
and
then
there
is
another
thread
that
showed
up
this
week:
cocos
for
better
ingress.
Reading,
alternative
expression,
I
put
a
link
to
the
first
one
for
Lewis
in
the
dock,
the
agenda
doc,
but
not
the
second
one,
because
his
name
wasn't
attached.
You
pop
the
thread
like
just
hang
the
thread
and
off
of
the
top
yeah.
A
D
K
The
altar
of
it,
martinelli
and
I
have
talked
about
it
a
couple
times.
It's
just
a
different
expression
of
the
same
thing
in
some
sense
solo.
You
know,
I,
don't
necessarily
agree
with
some
of
the
expression
in
Martin's
document,
but
ensure
they're
the
same,
and
he
would
be
quite
happy
it.
One
or
other
of
the
solutions
came
to
fruition.
Ok,.
B
What
I'm
going
to
happy
to
finger
into
the
room?
Yeah,
please
just
talk
them
to
the
top
of
the
thread
and
everybody
look
in
the
mailing
list
for
these
threads
and
try
to
make
a
little
time
they're,
actually
not
that
bad
to
read
and
see
when
get
some
feedback
or,
if
you're,
in
an
order
to
like
red
hat,
where
you
have
people
who
are
probably
interested
in
it.
K
B
B
B
I
read
over
Georgia
doctor
I
had
a
bunch
of
questions,
and
that
was
before
Christmas
I
have
an
actual
circle
back
Santa
made
up
I
mean
I
feel
like
this
is
in
full.
In
some
sense,
I,
don't
feel
some
built-up
pressure
to
do
it
right
now,
but
if
you
know
somebody
has
the
needed
to
scratch
this
inch,
then
this
is
what
open
source
is
about
right.
F
G
F
A
I
This
is
a
job
now
I
I've
been
in
getting
involved
with
some
of
the
your
use
cases
on
the
field
on
how
how
things
have
been
working
with
never
quadratics
and
everything
in
every
would.
This
sig
has
been
pretty
thing
so
I
haven't,
come
back
and
joined
the
coop
little
bit
again
and
try
to
bring
in
some
of
the
use
cases
really
use
cases
and
I
have
leave
from
GV.
I
I
But
what
we
want
is,
in
this
particular
use
case,
probably
three
to
four
networks
and
this
service
that
gets
created
any
service
that
is
created
be
able
to
specify
that
I
am
a
service
which
wants
to
address
a
particular
network
and
that
network
is
not
predefined
in
the
cluster.
Is
it's
more
like
to
see
and
I,
so
we're
talking
a
little
bit
of
mess?
I,
don't
know
if
anyone
else
have
sought
so
this,
but
these
are
kind
of
the
requirements
and
I
can
specify.
I
B
That
sounds
particularly
complicated:
I
hadn't
considered
the
services
and
multiple
networks
being
distinct
from
each
other
case.
The
cash
for
one
clarification,
Rudra
yeah,
you
said
network
interfaces
be
able
to
join
multiple
networks.
Do
you
see
the
need
for
sort
of
dynamically
joining
a
pod
to
networks
like
docker
does
allow,
or
is
it
aqua,
sadly,
to
find
that
know.
I
So
far
is
it
is
at
birth
and
saying:
I
want
three
interfaces
and
each
interface
has
a
one-to-one
mapping
to
each
Network
and-
and
maybe
the
order
is
important
and
maybe
daughter
is
not,
but
that
kind
of
only
depends
on
how
we
figure
out
the
services.
Now
let
when
I
create
a
service,
how
do
I
specify
that
my
endpoints
are
going
to
be?
You
know
that
second
network,
or
the
second
interface
in
some
way
or
third
one,
but
we
have
no
way
of
specifying
I,
even
have
my
kind
of
his
fellow
muddy
right.
A
A
First,
how
do
you
know
which
gnite
network
files
get
applied
to
which
pod
and
then
second
only
one
CNN
network
file
could
theoretically
get
applied
to
a
pod
and
the
ordering
was
not
defined,
but
if
we
have
chaining,
you
could
technically
specify
this
particular
chain
gets
applied
to
a
pod
and
that
chain
can
include
a
whole
bunch
of
things.
Don't
don't.
I
I
I
That
is
not
a
big
problem
because
of
them
comes
on
your
controller
site
when
we
have
an
inbuilt
controller
which
is
looking
at
these
pots
doing
this
pot
silica
from
the
service
and
then
populating
endpoints
and
it's
just
speaking
of
the
first
type,
is
that
it
ever
imagines
and
stuff
and
then
probably
stand
guard
up
from
there
all
lot
of
youth
kids.
If
I
say
how
do
I
even
specify,
which
is
my
end
point,
you
know,
I
have
three
interfaces,
not
just
because
I
like
what
one
number
two
number
three,
but
they
have
different
meanings.
I
One
is
probably
a
data
control
Network
and
if
I
create
a
service
actually
supposed
to
be
a
management
layer,
Network
kind
of
a
service,
then
then
it
needs
to
pick
up
that
particular
network.
In
that
particular
interface
needs
to
be
addressed.
In
those
end
point:
where
do
all
these
controllers
will
live?
Are
we
going
to
modify
the
existing
service
controller
with
some
new
fields?
I
Are
we
going
to
have
multiple
controllers,
where
you
specify
a
service
and
say
by
the
way,
go
and
attached
to
that
Network,
and
but
only
that
particular
controller
will
be
activated,
because
that
control
it
is
meant
for
that
network.
I,
don't
know
what
the
answer
is,
but
I
may
have
a
lot
of
I.
Don't
know
what
the
right
answer
is
and
then
it.
B
Me
stop
you
there
I,
you
clearly
have
put
some
thought
into
it
already.
Let's
can
we
get
you
to
review
Georgie's
dock
and
start
working
with
him
to
sound
out
those
cases,
because
I
think
it
made
it
much
more
complicated
I
mean
in
a
good
way,
and
so
we
should
start
to
work
out
the
details
of
those
I.
Don't
think
it's
impossible
to
solve.
I
I
do
still
think
it's
inevitable.
So,
let's
just.
I
L
Do
you
see
me
yeah?
Ok,
so
we
we
solve
it
in
a
slightly
different
way.
Very,
very
similar
use
case
for
the
dip
is
asking,
so
what
we
define
as
a
template
will
be
defining
a
total.
Yes,
that's
where
we
define
like
two
or
three
interfaces
of
ports
which
are
associated
with
a
different
part,
and
then
we
specify
a
service
camp.
We
specify
the
kind
of
service
it
is
right
and,
as
the
pod
or
amine
were
on
clearing
up
on
what
kind
of
deployment
will
like
that
gets
deployed.
L
That
bootiful
gets
associated
with
them
and
portable
specifies
that
there
is
a
service
instance
of
this
council
which
really
be
utilizing
right
and,
and
that
is
how,
because
the
service
that
boat
couple
has
three
or
two
depending
one,
then
it
went
to
the
phrase
left
it
right
network
which
ever
met
with
your
master
suite.
So
that's
how
the
association
in
a
group
of
one
created,
and
hence
the
solicitor
typical
this
is
this-
is
how
we
are
deploying,
in
fact,
we
probably
be
giving
you
a
devil
within
a
month
or
so
with
the
test.
L
This
is
how
we
are
dealing
with
multiple
networks,
multiple
forms,
multiple
services
and
killing
them
all
together
to
the
sum
of
the
distribution.
So
I
will
have
not
looked
at
enjoy
be
staffing
and
evening
themselves.
I
intend
to
review
it,
and
I
can
work
with
you
offline,
and
we
can
possibly
discuss
with
these
cases.
As
we
know,
it.
B
Sounds
great,
maybe
you
can
write
up
what
you're
doing
to
you
in
that
thread.
Yes,
okay,
look
at
this
yep
cool
we've
got
like
six
minutes
left
we
wanted
to
talk
about.
Doc's
would
respect
the
16
release,
so
I
went
through
our
docks,
page
and
I
searched
for
all
the
words
I
could
think
of
related
to
networking
and
I
pulled
out
what
I
thought
were
the
important
docs
I
sent
them
to
the
mailing
list
today
are
sent
to
be
on
the
agenda
thread.
There
was
a
couple
in
there
that
when
I
reread
them
was
like.
B
A
Yeah
that
sounds
reasonable.
I
took
a
look
at
all
those
docs
too,
and
my
general
impression
was
that
the
things
that
deal
with
services
were
actually
pretty
good
and
which
may
be
completely
wrong,
but
the
doc
said
dealt
with
the
kind
of
the
lower
level
networking
stuff
now
looking
plugins
network
policy
and
the
general
networking
thing
could
probably
use
a
much
larger
overhauled.
The
services
docks.
Yes,.
B
What
I
found
with
services
and
services
is
out
of
date.
There
was
a
bunch
of
stuff,
but
the
biggest
problem
with
all
of
these
docs
read
like
engineering
docs,
yep
or
encyclopedias,
and
which
it
does
not
make
for
great
user
facing
documentation
right.
So
I
only
got
the
response
from
the
docs
people.
While
we
were
in
this
meeting.
So
I
would
actually
proposed
in
the
last
few
minutes
here
that
we
don't
go
off
in
a
sign
docs
to
people.
C
B
Take
the
action
item
to
get
one
of
the
docs
people
to
join
us
next
time,
we'll
give
them
the
first
saved,
15
or
20
minutes
to
explain
and
maybe
show
us
some
of
the
examples
of
these
three
styles
of
Doc's
that
they've
been
working
on,
and
then
we
can
take
the
existing
docs
that
we've
identified
here
and
any
others
that
people
find
please
do
go
hunting
and
break
those
up
into
these
sorts
of
headings
that
we
want
to
do
cool
yep
all
right.
Any
other
agenda
item
well.
M
Week
we
have
I
comment
that
I
made
I,
don't
know
if
this
is
the
right
fig,
whether
it
belongs
to
come
across
cutting,
but
essentially
it's
most
applicable
to
the
multi-tenant
scenario,
where
your
time
with
the
final
roster
by
namespace
and
I've,
gained
as
policies
really
many
spaces,
don't
interact
with
each
other
or
even
share
the
information,
because
you
can
technically
do
this.
With
a
network
policy
publish
build
an
information
leak.
B
I
think
this
is
the
right
thing,
although
there's
going
to
be
some
crossover
to
what
David
driving
this
the
life
cycle
anyway,
one
of
the
guys
here
is
just
started.
Spinning
up
some
more
research
into
multi-tenancy,
proper
and
I'm,
not
sure
which
thing
he's
actually
operating
under
the
auspices
of
but
I
think.
Definitely
it
affect
us.
I
thought.
B
Its
takeoff,
okay,
that
makes
sense.
Thank
you
for
remembering
so
multi-tenant
dns
is
definitely
on
the
radar
for
the
multi-tenancy
discussion.
If
you
want
to
move
it
forwards
in
the
discussion
like
we
want
to
talk
about
it
in
a
smaller
sense,
maybe
we
can
put
that
on
the
agenda
for
next
time.
I'm
actually
now.