►
From YouTube: Network Plumbing WG Meeting 2018-06-07
Description
Network Plumbing Working Group meeting for June 7, 2018
A
All
right
recording
is
started.
This
is
the
network
plumbing
working
group
meeting
for
Thursday
June,
7th
2018
I
will
paste
the
agenda
duck
into
the
zoom
chat
just
in
case
people.
Don't
have
it
there.
It
is
okay,
spec
updates.
From
last
time,
I
updated,
Mac
requests,
IP
request
an
interface
request
in
the
spec
to
clarify
exactly
how
those
should
be
treated,
and
let
me
try
to
share
my
screen
really
quick
and
I
can
just
run
over
those.
A
Can't
everybody
see
my
screen
looks
good,
ok,
so
what
I
did
is
I
filled
out
the
IP
request
and
Mac
request
in
your
face
request,
actually
also
added
some
notes
on
what
the
type
should
be
just
to
try
to
tighten
up
spec
stuff
and
then
notes
about
validation
as
well.
For
all
of
these,
you
know,
for
example,
the
key
must
have
valid
ipv4
v6
addresses
in
them
and
then
notes
on
how
the
implementation
should
translate
those
into
the
cni
args.
A
Cni
argh
don't
have
to
be
honored
by
plugins,
and
so
if
we
want
to
make
sure
that
IP
requests,
Mak
requests
are
honored
by
the
plug-in
they
the
implementation
is
going
to
have
to
verify.
After
the
call
comes
back
that
the
Mac
and
IP
were
actually
set,
it
doesn't
actually
need
to
I
think,
go
into
the
containers,
network,
namespace
and
figure
that
out,
but
I.
Think
it's
probably
enough
just
to
check
that
the
C
and
I
wrote
results.
A
So
hopefully
that
makes
sense
for
people
the
same
thing
for
Mack
request,
except
for
the
fact
that
Mack
request
is
not
currently
in
the
conventions
document.
So
we
kind
of
have
to
make
that
up,
but
I
think
Tomo
Fumiya
is
working
on
adding
a
plug-in
that
would
honor
that
and
then
last
bit
was
interface
request.
A
That
was
not
present
in
the
meeting
last
time,
but
we
talked
about
it
and
thought
it
was
a
good
idea,
so
I
added
a
section
for
that
and
that's
basically,
we
just
need
to
take
interface
request
and
make
that
the
cni,
if
name
environment,
variable
when
running
that
particular
scene
I
can
fig
was
so
that
is
it
for
those
set
of
spec
updates.
There
were
one
or
two
more
changes,
but
they
weren't
really
material.
B
A
Right,
okay,
cool,
so
I
think
that
was
one
of
the
bigger
things.
The
respect
changes.
The
other
big
issue
from
last
time
was
how
to
handle
thick
plug-ins
for
versioning
and
capabilities,
and
it
turns
out
that
port
I'll
just
switch
agenda
back
here
yeah.
So
it
turns
out
that
just
having
the
plug-in
name
as
part
of
the
definition
doesn't
really
work
so
well,
because
then
we
don't
know
what
version
the
plug-in
is
or
what
capabilities
it
has,
so
that
we
can
pass
host
ports
or
those
kinds
of
things
to
any
of
those
plugins.
A
So
I
think
the
best
thing
that
I
came
up
with
was
just
removing
Specht
up
plugging
entirely.
That
would
work
for
some
cases,
but
it
doesn't
really
work
for
any
plugins
that
are
version
larger
than
zero
one
zero
of
the
cni
spec
and
then,
instead,
you
would
write
as
a
network
interface.
Scuse
me
a
network
object
creator.
A
Minimal
Jason,
snippet,
I
guess
in
the
spec
dot
config
and
you
just
wouldn't
put
in
any
network
name,
and
then
we
would
expect
the
implementation
to
insert
the
network
name
into
the
Jason.
Before
calling
any
of
the
plugins
in
the
that
CNI
configure
config
list
did
anybody
else
have
any
other
ideas?
Does
this
seem
like
a?
Are
there
better
ways
to
do
this.
C
A
A
Network
object
for
every
single
namespace
in
cube,
and
you
know
maybe
an
admission
controller
or
something
like
that.
That
would
then
create
a
namespace
object.
So
there
excuse
me
a
network
object
for
every
namespace
when
that
namespace
got
added
or
deleted,
and
then
basically,
you
just
forward
on
that
name
to
open
shift
and
an
open
shift
would
do
the
right
thing
with
it.
That's
kind
of
the
example
I
mean
it
would
also
be
useful
for
plugins
that
define
the
network's
outside
of
the
system.
A
If
there's
like
some
kind
of
controller
that
creates
a
cube
network
every
time
an
external
network
is
created,
and
then
you
know
that
that
was
kind
of
the
idea.
Basically,
that
you
know,
instead
of
carrying
a
ton
of
information
about
CNI
stuff
in
the
external
entity,
would
be
responsible
for
matching
up
the
networks.
Okay,.
C
A
One
example,
I
can
think
of
was
I,
think
in
either
the
last
Signet
work
meeting
or
two
ago
or
in
one
of
the
research
management
meetings.
I
think
it
was
Peter
from
Red,
Hat
demo'd
and
his
ovn
plug
in,
and
that
was
using
device
plug
in
and
not
Malta's.
But
what
happened
there
was
that
he
had
a
demon
watching
ovn
and
whenever
somebody
added
a
logical
switch
to
ovn,
he
created
a
new
network
in
kubernetes
with
the
CRD,
and
then
you
could
attach
pods
to
that
logical
switch.
A
A
D
A
There's
some
some
kind
of
section
for
that,
so
I'll
figure
it
out
and
then,
if
people
want
to
see
the
changes
that
have
been
made
to
the
specification,
you
can
do
that
pretty
easily
through
Google
Docs.
If
you're
not
already
aware
of
how
that
works,
unfortunately,
zoom
is
covering
up
the
bits
that
I
need.
Maybe
I
can
go,
do
that
and
I'm
not
signed
in
so
maybe
I
know
not
sending
so
I
can't
do
it
so
anyway,
sorry
but
yeah.
A
C
So
the
validation
part
is
like
maybe
alloting
the
network
object
when
the
information
is
passed
by
mulches
and
then
we
do
the
validation,
I'm
thinking
of
doing
a
watcher
kind
of
thing
in
the
ECD
controller
which
will
watch
it
so
particular
Network
objects.
Whenever
you
do
cubes
it
will
create
a
network
of
chat.
Indeed
to
do
the
validation
or
something
I,
don't
know
whether
it's
a
feasible
solution
but
I
see
sound.
A
And
I
did
add.
This
doesn't
directly
address
your
issue,
but
there
was
a
good
point
brought
up
in
the
comments
on
the
dock.
There
is
now
the
ability
to
validate
custom
resource
definitions
and
so
I
added
some
bits
to
the
CRD
specification
itself
to
at
least
validate
that
the
fields
are
correct
that
obviously
doesn't
validate
inside
the
field.
So,
like
the
config,
we
wouldn't
be
able
to
validate
the
JSON
string
string
inside
the
spec
dot
config
property,
but
at
least
we
are
able
to
have
kubernetes
automatically
validate
the
object
itself
for
us
now.
A
A
And
it
I
mean
again:
it's
automatic,
you
just
add
a
validate,
not
stanza,
validate
section
or
validation
section
to
the
bottom
of
the
CRD
definition,
yeah
mo
and
then
kinda
list
the
properties
so
I
added
that
to
the
document
section
3.1.
If
anybody
cares
to
go
check
that
out,
but
yeah
I
don't
know
of
any
other
good
ways,
you
could
do
maybe
an
admission
controller
or
something
like
that
to
corral
to
see
when
that
comes
in
and
validate
it
and
then
reject
it.
Yeah.
C
A
That's
a
good
point:
the
open,
API
v3
schema
stuff
that
cube
uses
to
validate
I,
don't
believe,
has
that
capability
to
look
that
deeply
into
the
fields?
I
could
be
completely
wrong,
but
when
I
was
looking
at
it,
it
looks
like
you
can
just
validate
the
field
type.
So
like
string
or
integer,
or
something
like
that,
I
mean
you
can
do
like
min
max
that
kind
of
stuff,
but
I,
don't
think
and
go
too
much
further
in
so
we
may
be
stuck
with
a
admission
controller
or
something
like
that.
E
D
The
only
downside
there
is
just
that
it's
you're
not
gonna,
get
immediate
feedback
at
the
CLI
when
you're
dumping,
those
in
with
like
cute
control,
create
this
thing
or
whatever
right.
You'd
have
to
go
to
another
place,
yep
sure,
but
you
could
get
definitely
getting
the
output
from
it
there
and
I
could
let
you
give
you
a
report
saying
like?
Oh,
these
aren't
valid.
So
there's
definitely
something
to
that.
I.
E
G
I
have
a
one
console
about
the
once.
The
thick
problem
found
that
the
user
input
the
wrong
network
attachment
llamo,
but
how
we
notify
this
information
to
users.
Is
they
also
challenging
to
me
because
the
thick
probably
author,
other
program
is
we
could
not
put
the
standard
where
overkill
the
cube
control
output?
So
maybe
we
need
to
add
the
additional
field
in
the
to
store,
be
our
current
status
of
a
network
attachments,
not
the
network
status.
G
G
A
The
way
that
I
would
wear
the
current
state
of
affairs
would
be
that
the
implementation
like
Malta's
or
whatever
would
fail
the
entire
pod
network
if
one
of
them
couldn't
be
attached-
and
it
should
ideally
return
some
kind
of
error
message
that
would
then
be
sent
to
cubelet
and
cubelet
would
put
that
into
the
pot
events,
something
you
could
do
cube
CTL
described
pod
foo
and
it
would
show
you
you
know
the
specific
error
that
Malta
stood
returned.
But
that's
not.
It
doesn't
work
very
well
because
there's
not
a
lot
of
ver
information.
A
A
A
Well,
I
mean
that
kind
of
ties
into
the
corrals
next
point,
which
was
logs
I,
mean
I,
think
something
that
could
help
that
quite
a
bit
would
also
be
logs
from
the
implementation
of
this
specification.
That
would
have
more
verbose
information
about
what
might
be
going
wrong.
Do
you
want
to
talk
a
little
bit
about
what
you
mean
with
logs
girl,
yeah.
C
So
I
was
thinking
that
most
of
the
time
whenever
that
is
the
error
happens
right.
We
have
to
go
to
the
cubelet
logs
and
see
there's
the
information
so
yeah.
It's
not
the
ideal
way
like
each
and
every
time
you
will
go
and
see
the
operative.
If
the
IP
address
a
it's
full
or
IP
addresses
place
matching
with
the
final
network.
Sometimes
the
final
we
throw
error.
C
Sometimes
some
other
plugins
will
throw
that
the
entire
part
creation
will
be
stopped
in
multis,
so
I'm
thinking
whether
we
should
have
a
proper
kind
of
logs
like
the
multis
can
generate
like
whatever,
currently
the
it's
generated
by
the
cube
logs,
so
which
is
easy
to
read
for
the
uses
of
so
that
they
just
can
go
there
and
see
so
for
this
particular
pod
when
it's
created
and
what
is
a
error
statement,
some
of
this
is
throwing
out.
So
it's
just
for
the
debugging
issues.
C
A
I
mean
it,
it
would
be
I,
think
addition
or
PR
to
see
and
I
like
Lib,
C
and
I,
and
some
of
the
other
core
bits
and
package
for
CNI
to
have
more
logging
information
so
that,
like
Malta's
or
something
else,
could
maybe
pass
in
some
kind
of
log
interface
and
then
see
and
I
would
direct
its
Devon
for
info
messages
to
that
interface
and
then
most
could
do
whatever
it
wanted.
With
those
like
write
them
on
the
disk
or
something
like
that.
H
A
G
Sure
one
questions
about
the
roles
today.
At
that
time
there
you
are
wondering
that
the
we
could
add
the
some
standard
they
configure
for
a
logging
file.
I
mean
that
not
the
motifs,
the
ones
we
add
the
log
somewhere
thrush.
They
believe
CNI,
that
rock
was
in
the
config
file.
The
we
put
groaning
amethyst,
also
their
lips
CNI
water,
CNI
lost,
goes
into
the
one
file,
a
modest
incorrect.
A
C
G
Yes,
so
a
currently
I'm
just
thinking
about
the
the
implemented
some
logo
functionality
in
the
mother's
I
mean
that
the
mothers
have
additional
or
fields
for
configuration.
I'm,
India,
Barbara's
role
was
something
like
that
and
then
they,
we
I'm
thinking
about
to
put
everything
and
the
Bubba
strokes
in
the
this
rogue
file.
But
today
yeah
I
am
so
the
missing
the
raga
functionality
is
not
only
the
mouth
is
also,
they
are
live,
see
an
IRA
Chrystia.
You
know
current
EDA.
G
G
G
A
I
think
it'd
definitely
be
worth
bringing
up
in
CNI
itself.
If
you
have
any
ideas
about
how
it
should
work,
you
know,
I
mean
first,
maybe
raise
an
issue
in
the
CNI
project
and
say
you
know.
This
is
something
that
we
can
work
on
and
make
better
and
then
dump
any
ideas
you
have
in
there
or
even
better,
like
PRS,
or
something
like
that.
Ok.
C
Yeah,
maybe
right
because
in
the
cubelet
we
used
the
same
ad
lib
right.
So
in
this
case
the
cubelet
will
be
alive
the
overall
process.
So
whenever
we
pass
information
to
the
cine
lips,
I
seen
a
lib
can
could
able
to
generate
the
logs,
because
if
you
put
it
in
multis
multis
each
and
every
time
which
generates
our
logs
whenever
we
invoke
that.
So
that
will
be
a
lot
of
information.
Actually.
E
C
G
E
C
E
C
E
C
I
put
something
in
the
dog:
maybe
try
to
come
up
with
some
ideas.
Last
week,
I
was
trying
to
do
some
prototype
and
that
one
then
it
stucks
to
meet
a
lot
of
information
each
and
every
time
whenever
a
Maltese
is
throwing
the
log.
So
I
was
thinking
it's
too
much
information.
Rather
it
should
be
user
friendly
that
anyone
can
read
and
understand
the
stuff,
maybe
I'm
doing
it
wrong.
Maybe
I
can
put
my
ideas
in
the
documentation,
and
people
can
comment
it
and
we
can
make
it
in
better
shape.
G
C
They
can
pick
up
any
pluggable
models
to
implement,
or
you
guys
saying
that
we
should
have
some
kind
of
unified
way
of
doing
multiple
networking,
because
whenever
you
talk
with
someone,
they
always
ask
this
question
guys.
This
is
like
ABC
options
are
there,
which
is
option
you
going
to
say
like
they
ask
me
the
solution
which
is
option
usages
then
I
always
thumb
that
okay,
you,
what
is
your
recommend
I,
will
generally
ask?
What
is
your
equipment
then
I
still
like
get
this?
C
Is
you
recommend,
then
you
can
use
this
option
if
this
is
your
recommend,
for
example,
if
you
want
to
use
service
load
balancing
in
points,
then
I'll
say:
ok
in
network
service
mesh
is
a
good
option,
so
someone
says
I
don't
need
services
that
I
just
need
additional
networking.
It's
a
private
network,
then
I
will
say:
ok
use
the
meta
plugin,
not
the
reference.
C
So
we
caught
like
few
feedbacks
but
from
both
the
resource
management
working
group
and
also
from
the
network
sync
group
as
well.
So
we
are
currently
working
on
this
o.
So
when
people
ask
me,
what
is
a
solution,
right
are
usually
confused
like
what
I
can
tell.
Actually,
because
there
are
so
many
solution,
you
can
do
the
solution
much
better
in
different
pluggable
models.
So
I,
just
wondering,
like
of
you,
guys,
thinks
that
these
people
cease
and
you
guys
think
that
is
opportunity
for
PCs
to
come
forward
and
unify
the
solution.
D
May
be,
a
good
idea
is
to
I
mean
I'd
love
to
see
more
of
the
people
that
have
these
different
solutions
get
together,
because
I
feel
like
what
we've
started
here
is
like
a
really
good
building
block
towards
making
something
standard
and
then
because
it's
like
you
know
when
the
other
consideration
and
we've
had
today
between
validation
and
logging
and
stuff,
like
that.
These
are
all
really
good
considerations
for
the
user.
D
But
kind
of
a
really
good
part
of
what
we're
doing
here
is
that
it's
going
to
improve
user
experience
for
people
right.
So
it's
like
they
go
to
and
learn
a
way
to
attach
multiple
networks
to
their
pods
and
the
technology
behind
the
scene
changes,
but
their
experience
of
using
it
doesn't
necessarily
have
to
change
right.
They
just
have
the
same
annotations,
so
anyways
I
feel
it
could
be
really
good
if
we
can
get
more
of
those
people
involved
and
like,
for
example,
like
cube
Tron.
Is
that
Petters
thing
again
that
is
yeah?
D
Okay
cool
so
like
he
gets
involved
in
talks
about
it,
and
you
know
I
at
least
personally
I'm
more
to
learn
about
network
servers
mesh,
but
you
know
sometimes
I.
Look
at
that
and
I
wonder
I'm
like
oh.
Could
they
make
a
reference
implementation
of
r-spec
with
what
they
have?
Maybe
they
could
be
compatible
with
it
as
well
stuff
like
that.
H
The
one
common
I've
got
on
it
generally
is
that
so
we're
a
vendor
and
we'll
be
sent
a
lots,
different
customers
to
be
running
there,
we're
hoping
to
sell
lots
of
different
customers,
you'll
be
running
their
own,
largely
running
their
own
kubernetes
systems,
and
the
worry
I've
got
is
if
it
becomes
too
fragmented.
If
it's
not
consistent,
then
we'll
be
able
to
sell
the
same
software
at
all.
H
These
people
will
be
able
to
use
the
same
helm,
charts
all
that
kind
of
stuff
and,
if
everybody's,
using
the
same
CRD
specification
and
the
same
annotations
and
so
on.
Well,
that's
fine
that
that
alleviates
that
concern,
but
I
am
a
bit
concerned
that
it's
all,
it's
all
a
bit
too
fragmented
that
the
environments
are
going
to
differ
in
lots
of
subtle
little
ways
and
in
particular,
of
the
two
that
I'm
most
familiar
with
the
certain
network
servers
mesh
where
I've
followed
better
reading
and
with
the
river
concept
which
I've
been
playing
with
and
try.
H
D
A
Yeah
I
feel
basically
the
same
I'm,
hoping
that
you
know
we
can
kind
of
at
least
create
a
version
one
base
that
people
can
start
implementing
with
this.
You
know-
maybe
obviously
not
everybody's
gonna
do
it,
but
if
we
can
kind
of
get
some
critical
mass
around
the
specification-
and
hopefully
it
works,
for
you
know
at
least
50
or
60,
or
something
percent
of
some
of
the
use
cases,
and
then
we
can
just
kind
of
build
from
there.
Obviously,
it's
not
going
to
work
for
everybody.
A
It
may
not
work
for
network
service,
miss
these
cases
immediately,
but
once
we've
gotten
to
a
point
where
you
know
it's
out
there
and
it's
being
used,
we
can
definitely
keep
improving
it
to
handle
some
of
those
use.
Cases
and
I
think
you
know,
I
mean
I,
see
a
lot
of
the
same
people
on
a
lot
of
the
same
calls
sig
network-
and
you
know
this
call
and
some
of
the
network
service
mesh
stuff
as
well
so
I
think
there's
a
lot
of
interaction
going
on.
A
A
I
will
copy
and
paste
the
list
of
names
that
people
have
come
up
with
for
what
the
network
object
should
be
called
to
the
top
of
the
spec
document,
and
then,
if
people
just
want
to
go
through
that
list
and
indicate
if
they
have
preferences,
let's
just
kind
of
get
to
a
order
list
of
possible
options
for
the
network,
object,
name.
So
I.
A
H
That
is
by
just
writing
some
code
that
will
effectively
fill
in
the
endpoint
objects
by
scanning
the
kubernetes
api,
finding
what
input
object
exists
and
what
what
IP
addresses
they
have
in
the
different
networks
and
which
is
all
fine
I,
was
just
curious
if
there
was
a
expectation
that
there
was
going
to
be
any
further
work
in
that
area.
If
anyone
else
was
going
to
be
doing
anything
about
setting
up
DNS
and
creating
services
for
things
that
are
not
in
the
main
network,
I.
D
Haven't
personally
thought
about
that
one
very
much
but
I
think
you
should
definitely
keep
in
touch
and
let
us
know
how
it
goes.
You
know
I'm
interested
in
your
use
case
and
you
know
kind
of
interested
to
see
what's
there
and
maybe
you
know,
there's
a
potential
to
collaborate.
You
know
if
it's
appropriate
to
come
in
to
you
know
the
plug-in
itself
etc.
You
know
I'm
not
exactly
sure.
Yeah
yeah
definitely
keep
us
posted
that
very,
very
least.
H
That
so
I
was
thinking
simply
thinking
of
scanning
for
port
annotations.
Oh
I
know
that
won't
scale
and
I
know
that
what
I'm
thinking
of
doing
is,
frankly,
writing
a
bit
of
a
keep
I'm
good
to
get
my
demo
working.
So
we
can
do
so.
We've
got
something
we
can
wave
around
and
then
think
about
what
the
right
way
of
doing
it
is,
and
the
hacky
thing
I'm
gonna
do
in
the
short
term,
isn't
very
interesting,
I'm
thinking
more
a
little
more
about
well,
what
is
the
right
answer
going
forward?
I?
D
I'm
with
Dan
I
think
thinking
about
adding
that
to
the
network
status
annotation
the
results
object
as
I
like
to
call
it
might
might
be
worth
thinking
about,
and
it
might
be
something
that's
like
a
little
bit
cleaner
in
the
future
to
to
scan
through
I'm,
not
sure
about
the
scale
and
I
know.
Mike
has
brought
up
some
issues
with
scaling
the
results
object
previously,
but
anyway,
it's
definitely
something
to
think
about,
but
yeah
good
luck
with
the
demo.
That's
the
way
they
gotta
start
anyways.
H
Keep
you
guys
posted
I,
don't
think
it'll
take
a
little
while
I
think
before
we've
actually
put
very
much
more
together
than
we
currently
have,
which
is
very
limited.
But
it's
certainly
from
from
the
point
of
view
of
our
software,
where
we're
getting
a
lot
of
ourself
career,
running
containers
for
the
first
time
and
putting
together
the
infrastructure
to
manage
it,
and
so
there's
that
on
top
and
then
there's
multi
network
as
well.
A
A
H
H
A
So
I
mean
you
guys
been
working
on
this
for
a
while
and
I
seem
to
recall
you
had
one
of
the
proposals
last
year
for
how
the
stuff
would
integrate
into
the
cube
API.
So
I'm
really
curious
to
see
what
you
guys
come
up
with
and
some
of
the
stuff
that
you've
been.
You
know
working
on
for
the
past
couple
of
months
here,
because
I
think
this
figuring
out
how
all
this
stuff
fits
in
is
probably
one
of
the
next
steps
that
this
group
should
explore.
D
H
I
hadn't
got
as
far
as
thinking
about
that
at
all.
Really,
the
only
thing
I
was
thinking
of
was,
if
I
can
get
a
lookup
of
the
IP
address,
we'll
see
that
they're
in
a
different
subnet
they're
from
a
different
network
that'll
be
good
enough
for
what
we're
doing
you're
quite
right.
That
does
mean
you
might
be
able
to
find
a
service
that
you
can't
access.
Yeah,
I'm!
Think
that's
what
you
do
at
that
point.
You
write.
H
A
That
was
one
of
the
sticking
points
with
upstream
and
we
kind
of
went
around
with
a
couple
of
options.
One
option
was
creating
a
completely
new
object,
called
multi
network
endpoint,
or
you
know
something
like
that,
so
that
existing
clients
would
not
be
exposed
to
endpoints.
They
couldn't
actually
access
and
only
new
clients
that
were
updated
to
know
about
multi
network
stuff
would
be
able
to
see
them
or
would
know
to
look
for
those
and
I
mean
that's
still
a
viable
option.
H
C
Well,
not
the
advantage
of
using
what
Peter
said
it's
a
kind
of
brownfield
model,
so
you
don't
need
to
develop
something
Dan
said
like
creating
our
own
C
or
D
net
endpoints
right.
If
you
go
for
that
the
point
we
can
do
it
a
bit,
it's
completely
a
Greenfield.
You
have
to
do
everything
on
your
own,
which,
which
already
kubernetes
is
doing
so
it
kind
of
a
very
thick
controller
or
something
the
maintaining
such
a
code
is
something
like
you
maintaining
kubernetes,
so
that's
kind
of
difficulties.
C
It
has
the
Peter
said
it's
a
kind
of
hacky
way
that
you
can
easily
achieve
the
stuff.
What
you
want
to
do,
but
the
thing
is
that,
because
I
worked
on
this
service
end
points,
it's
like
I
explored
how
to
do
this
hacking.
It's
there
is
a
lot
of
ways
to
you
can
do
the
hacking
is
actually
within
the
community
services.
So
you
can
create
your
own
end
points
as
within
the
services
or
you
create
the
end
points
us
using
Python
client
code.
Kubernetes
client
go
API,
so
it's
possible
to
do
those
stuff.
C
H
B
A
I've
done
some
investigation
before
and
it's
non-trivial
amount,
I
mean
I.
I,
can't
say
you
know,
lines
of
code,
it
didn't
seem
overwhelming,
but
it
you
know
I
mean
it's
basically,
endpoints
controllers
service
controller,
the
proxy
deals
pretty
heavily
with
services
and
endpoints.
Obviously,
but
a
lot
of
us
you
know,
may
or
may
not
be
using
Q
proxy
for
that
functionality.
B
I
think
the
real
problem
is
that
it
just
starts
bleeding
over
all
over
quickly.
Like
I
could
imagine
you
know
that
we
define
a
more
general
kind
of
service
that,
for
example,
it
gives
more
control
over
what
goes
into
DNS,
and
but
you
know
now
we
have
yeah
ask
about.
Okay,
people
are
implementing
other
proxies
and
actually
a
lot
of
things
use
services
I
feel
a
lot
of
things.
Use
services
right,
there's,
ingress
user
services.
A
Know
I
mean
that
said
it
might
be
a
good
idea
just
to
start
you
know
with
if
somebody
wants
to
look
into
the
multi
network.
Endpoint
object
direction,
just
to
start
by
doing
that
and
then
creating
a
controller
that
does
the
same
thing.
I
mean
I
feel
like
you
know,
we
don't
have
to
solve
the
entire
thing,
but
if
we're
just
looking
for
research,
just
starting
small
and
trying
to
figure
out
what
that
is,
then
going
from
there.
B
B
So
I
mean
one
testimonial
I'll
give
is
at
IBM
in
our
VM
type
stuff.
We
have
a
habit
of
giving
to
attachments
to
every
VM
one
on
a
public
network
and
one
on
a
private
network,
and
it's
as
far
as
what
goes
into
DNS.
It's
a
little
bit
hellacious
the
I
actually
not
very
satisfied,
but
what
seems,
but
what
gets
done
apparently
is
for
a
given
DNS
name.
B
You
know
it
gets
either
public
or
private
address
and
someone
is
making
a
choice
which
one
goes
in
as
in
a
given
different
under
different,
a
given
domain,
and
we
could
model
that
kind
of
thing
give
control
over
what
goes
into
DNS.
And
similarly,
you
know
we
could
do
the
same
kind
of
thing
would
give
control
or
what
goes
into
the
end
point
end
points.
H
Think
that's
a
good
idea.
I
think
we
might
we'll
probably
start.
Certainly
from
my
perspective,
we'll
start
with
something
pretty
basic
and
robust,
and
then
we'll
look
at
it
and
say:
given
this
model,
how
would
we
improve
it
so
that
we
get
a
more
add
more
generally
useful
case,
I
suspect
as
soon
as
we've
actually
spun
spun
something
up
and
tried
a
bit
real
traffic
through
and
see
what
see,
what
breaks
and
what
doesn't
that'll
that'll
tell
us
some
interesting
things.
H
Yes,
that's
right,
I,
don't
think
I've
actually
blocked
by
that.
Just
now,
because
I
think
realistically
I'm
away
for
a
bit
in
July
and
I've
got
several
I've
got
several
other
things.
I
need
to
do
along
the
way
before
you
get
to
worrying
about
the
the
detailed
networking
setup.
So
I'm,
not
it's
not
blocking
me
for
quite
some
time
and
by
the
sound
of
it
you're
going
to
have
that
available
within
I
know:
I,
don't
put
words
in
your
mouth.
When
do
you
reckon
that's
likely
to
be
available?
I.
C
H
H
C
E
C
C
E
A
J
C
I
just
want
to
precautious
that
I
don't
know
like
it
should
be
acceptable
by
the
kubernetes
sikh
community.
Actually,
maybe
we
can
find
some
other
solution
be
instead
of
changing
the
cubelet
I
was
thinking
some
other
solution.
We
can
go
forward
because
chaining
the
cubelet
is
never
going
to
happen.
So
that's
what
I
think
the
I.