►
From YouTube: Kubernetes Federation WG sync 20180516
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
C
B
B
B
So
actually,
this
repo
Federation
DNS
repo,
contains
that
Vivaan
dns
providers
and
then
controller.
So
we
kind
of
developed
a
demo
which
was
basically
the
cross
process
service
discovery
demo.
Now
it
works.
It
is
refactored
based
on
v2
API
snow.
So
this
is.
This
will
force
that
Federation
DNS
controller
and
the
DNS
provider.
So
we
kind
of
decided
right
like
we
didn't
want
to
put
that
code
in
Federation
v2
and
it
kind
of
contains
the
provider
the
cloud
provider
stuff
so
and
then
also
like.
B
We
also
wanted
to
maintain
whatever
was
there
earlier
in
v1,
the
DNS
provider
stuff
and
going
on.
We
are
trying
to
move
it
to
delegate
this
programming
DNS
to
the
external
DNS,
so
that
would
be
happening
in
stages.
I
believe
so.
I
have
kind
of
pushed
one
now
ER
to
external
DNS
to
two
in
this
direction.
So
I
think
we
could
start
off
making
this
repo
into
the
officially
maintained.
Therefore,
for
Federation
sake,
so
I'm
little
unsure
about
all
the
process.
B
C
Yeah
calls
more
the
expert
on
what's
required
on
getting
a
repo
into
that
these
cigs
work,
I'm
kind
of
I
when
we
initially
talked
about
this
I,
wasn't
sure
whether
the
new
repo
is
gonna
be
required
or
whether
the
work
can
be
done
in
the
existing
Federation
repo.
Since
the
code
very
lives
there.
Is
it
like
ready?
C
A
C
B
So
we
kind
of
another
new
object,
called
DNS
multi
cluster
DNS
object
which,
where
I
am
raised
on
PR
and
also
where
that
object
is
containing
all
the
information
required
to
program
the
DNS
and
this
Federation
DNS
is
basically
controller,
which
monitors
that
object
and
programs
that
DNS
right
now
in
v1
kind
of
a
variant.
It
would
use
the
DNS
provider
library
from
Federation
v1
and
in
v2
it
will
basically
delegate
it
to
so.
We
have
an
option
right
now
to
go
ahead
with
v1
or
v2.
B
So
it
might
happen
in
stages
because
I
don't
see
happening
overnight,
because
there
could
be
some
issues.
So
we
didn't
want
to
lose
all
the
core
which
we
have
in
v1.
So
that's
why
it
is
still
maintained
the
Federation
DNS
right
now
it
will
be
a
container
image
and
everything-
and
also
there
is
a
chart
now
also
which
will
run
this
controller,
basically,
which
will
be
monitoring
this
multi
cluster
DNS
objects
and
programming,
the
DNS.
That's
the
job
of
that
controller.
B
C
B
And
also
right
now,
this
is
this
will
also
act
as
an
intermediate
in
the
future.
To
like,
we
have
a
multi
cluster
DNS
shall
be
object
and
you
need
to
give
that
information
to
external
DNS
in
the
format
of
endpoints.
So
somebody
has
to
be
converting
that
information
to
the
whatever
is
required
in
external
DNS,
so
either
we
could
maintain
that
in
addition,
v2
itself
or
in
this
rebel
okay.
C
You
know
I
think
what
you're
describing
sounds
and
I.
My
hope
would
be
that
eventually,
externally
announced
could
actually
understand
in
intermediate
representation
and
directly
and
Federation
v2,
which
is
yeah
represented.
But
as
you
say
that
who
knows
how
long
that'll
take
and
I
think
what
you're
describing
sounds
fine
as
a
way
of
moving
forward.
A
C
C
D
C
Is
kind
of
like
on
the
path
to
actually
moving
everything
the
C
or
D
have
to
do
some
research.
The
validate
validation
is
kind
of
a
sticking
point,
but
my
hope
would
be
is
that
we
can
clear
the
hurdle
of
getting
everything
into
C
or
D
and
release
an
alpha.
That
does
not
require
a
separate
API
server
or
at
C
D,
which
would
just
be
dramatically
simple,
simpler
thing
to
deploy,
maintain.
B
A
C
Think
I
prefer
to
focus
on
doing
things
as
simply
as
possible,
and
if
we
find
that
it
is
an
appropriate,
we
can
go
back
on
that,
but
I
mean
the
cost
will
be.
Oh,
we
have
to
generate
a
bunch
of
API
types,
but
the
actual
code
won't
change
the
way
that
the
code
is
being
restructured
to
support.
Crts
means
that
it's
using
the
dynamic
clients,
it's
not
hard
coding,
like
none
of
the
propagation,
is
actually
using
hard
coded
clients.
C
It's
all
unstructured
resources,
not
a
dynamic
client,
so
the
cost
of
switching
in
the
future
is
going
to
be
low.
That
makes
sense.
So
so,
to
my
mind,
it's
like
I
want
to
be
fault
on
you
lowest
cost
option
and
with
the
understanding
that,
if
we
do
need
to
switch
to
a
higher
cost
option
like
it's
mainly
an
operational
cost,
what
we're
talking
about
it
won't
be
prohibitive
to
switch
but
I.
Think
kind
of
assuming
we're
going
to
do
the
simplest
thing
kind
of
to
me.
C
C
B
I
think
you
know,
yeah
I
think
that's.
That
could
be
an
eventual
step
about
the
multiple
versions
but
I
think
yeah
going
moving
too
Ciardi
is
definitely
we
need
to
go
out
right,
right,
yeah,
yeah,
so
how
much
of
a
walk,
because
they're
like
how
we
can
make
the
transition,
like
you,
have
some
POS
already
right.
The.
C
Pr
is
up
that
hopefully
will
be
merging,
is,
is
basically
rewriting
the
propagation
to
work
with
configuration
versus
code
and
support,
C
or
DS.
The
next
step
is
like
the
one
stumbling
point
for
CRT
support
is
validation
and
we
use
hard
coded
like
when
we
use
hard
prototypes
instead
of
CR
DS.
We
get
a
certain
amount
of
validation
for
free,
because
the
API
machinery
will
accept
the
type
and
go.
Oh,
do
you
fit?
You
know
secret
b12,
you
actually
do
the
fields
match
up
to
the
values
or
as
they
expect.
C
Anyway,
my
creatives
better,
even
secret.
It's
validating
that
the
fields
are
like,
probably
like
I'm,
not
even
sure
if
it
does
membership
like
if
I
have
like
a
field
like
like
I'm
thinking
in
a
pod,
you
have
constants
like
image,
pull
always
that
kind
of
thing,
or
always
just
as
a
constant
I,
don't
actually
know
if
open
API
validates
that
correctly
I
guess
you're
going
to
find
out.
But
that's
really.
The
only
stumbling
block
like
the
propagation
stuff
is
working.
C
C
Anyway,
so
I
think
my
goal
here
is
reducing
the
complexity
and
the
user
experience
like
the
operational
cost
of
this
to
a
minimum,
because
that
seemed
to
always
be
a
barrier
on
Federation.
It
was
really
easy
to
have
things
go
wrong
or
to
have
people
not
understand,
but
if
it's
all
CRD
and
everybody
understands
the
ARD,
because
it's
well
understood
thing
outside
the
context
of
a
federation.
B
B
E
Google
has
been
working
on
that
initiative
and
they've
been
contributing
things
too,
like
cig
networking,
but
that's
kind
of
been
on
hold
and
we
probably
need
to
get
an
update
on
what
the
status
of
that
is.
But
the
idea
is
that
we
would
leverage
the
cube
MCI
work
to
some
more
English
Toleration
yeah.
B
E
E
But
we
were,
at
some
point,
gonna
be
receiving
some
docs
from
Google
regarding
possibly
what
what
that
API
might
look
like,
but
we
need
to
probably
touch
base
with
them
again
and
see
what
the
status
of
that
is.
But
I
believe
that
a
lot
of
the
work
has
been
happening
in
Signet
working
and
we
just
haven't
been
aware
of
it.
E
B
Okey-
and
there
was
one
more
point-
I
think
it
was
about
the
high
level
placement
primitives
me
to
say
right
now.
What
we
have
is
based
on
cluster
names
right
so
I
think
in
v1
at
least
we
had
something
like
label
based
cluster
selector
right,
so
either
shall
be
built
such
a
thing
on
v2
right
now.
Yes,.
C
C
C
Yeah
I
mean
to
me
I
think
that
the
near-term
goal
is
is
getting
to
C
or
D
and
getting
it
to
an
alpha,
so
people
can
actually
use
it,
weren't
necessarily
compiling
code
or
like
Burton's
developers,
I
think
selector
base
like
that
would
be.
That
would
be
something
some
people
would
want.
I'm
we
have
you
know,
scheduling
is
something
people
would
want,
probably
push-based,
sorry
pull
days.
B
C
C
I
guess
my
suggestion
would
be
is,
maybe
it
can
be
the
subject
to
the
design
doc.
Think
about
like.
What's
the
simplest
thing,
we
could
possibly
do
as
a
starting
point
and
not
saying
we
don't
want
to
solve
the
more
complicated
stuff,
but
probably
getting
something
done
is
more
important
than
getting
the
perfect.
E
In
the
context
of
clusters,
also,
the
federated
cluster
resource,
I
I,
just
think
in
like
sometime
in
the
future,
not
something
we
need
to
solve
now,
but
I
think
we
need
to
figure
out
the
story
behind
the
integration
with
the
cluster
registry
and
what
federated
clusters
do
versus
what
the
cluster
registry
clusters
do
and
like
how
status
is
reported
in
federated
clusters
right
now
status.
It
doesn't
exist
for
the
cluster
registry
cluster,
but
that's
sort
of
a
to
do
eventually
a
that
might
get
fleshed
out,
but
just
thinking
about
long
term.
C
Think
I
don't
know
I'm
not
too
concerned
long
term,
I.
Think
if
cluster
registry
comes
up
with
something
compelling
because
people
have
used
cases
the
you
know
provide
for
like
you
need
status,
you
need
to
understand.
You
know
what
the
health
of
the
cluster
is
or
whatever,
but
I
think
the
chances
of
that
converging
on
what
Federation
needs
in
the
air
travel.
Pretty
slim.
C
B
B
C
Ok,
so
yeah
I'm,
looking
forward
to
being
able
to
deploy
Federation
where
it
just
consists
of
apply
these
yeah
mole
to
create
CDs
and
to
launch
a
controller.
Then
you
got
to
join
us.
Please
tell
me
in
cubeguard,
but
but
at
least
running
Federation
getting
it
installed.
It's
actually
gonna
be
really
simple:
okay,.
C
B
Yeah
yeah,
yeah,
start
and
I
think
it
seems
like
a
very
good
use
case
for
federated
jobs,
and
probably
we
should
be
able
to
do
that
with
v2
right,
yeah
I,
don't
know
some
of
the
are
missing,
like
the
high
level
features
for
jobs
right
now.
It
can
just
do
overrides
right.
C
C
F
C
F
C
That
would
fail,
but
I
mean
you
have
to
understand
that
in
order
to
know
how
Federation
works
and
you
have
to
know
both
order
of
creating
these
resources
and
how
it
relates
to
how
chrome
engagement
work,
it's
a
lot
of
detail,
knowledge,
I,
think
but
I
don't
have
a
good
sense
of
how
to
really
simplify
it.
Without
having
him,
sir
I
mean
at
the
API
level,
like
I,
think
we
could
do
some
sort
of
like
web
out.
C
C
Yeah
I
agree,
I
agree,
actually,
no
I,
it
could
I
mean
if
we
have
validation.
That
was
smart
enough
and
you
tried
to
override
something
and
it
saw
that
the
resource
had
been
created
in
the
cluster
you're
trying
to
send
an
override
for
we
could
do
it.
I
mean
I,
know
it
sure
would
be
better,
but
it
would
be
possible.
How
can
you
update
any
multiple
field?
C
You
wouldn't
update
it?
You
would
essentially
have
to
like
I
guess.
My
suggestion
is,
if
you,
if
you
went
and
set
an
override
for
N
and
when
you
went
to
submit
as
the
API
the
API
we
go,
hey
that
resource
already
exists
in
this
cluster
I
can't
apply
the
override.
Without
you
know,
mm-hm
removing
the
job
from
the
cluster
and
reading
it,
which
may
or
may
not
be
desirable,
but
at
least
it
could
give
you
the
option
could
say:
hey.
You
can't
apply
this
override
because
the
office
already
created.
What
do
you
want
to
do?
F
C
Could
fail
the
update
and
say
if
you
want
this
update
to
happen,
you
have
to
remove
the
job
from
the
cluster
and
then
all
it
worked
and
you
that
at
that
point
you
can
decide
like.
Oh,
is
this
super
important
that
I
want
to
do
that
or
oh
I
guess
I'm
just
gonna
let
the
job
run
with
whatever
number
of
instances
it
have.
C
B
B
C
C
Yeah,
you
would
be
is
you
would
have
something
that
would
set
say
a
single
cluster
and
then
watch
the
status.
If
it
was
successful,
then
it
would
add
other
clusters,
but
it
wouldn't
actually
change
the
propagation
mechanism
at
all.
It
would
be
a
higher
order
thing.
There
just
use
the
primitives
to
program
the
propagation.
C
C
It,
to
my
mind,
like
the
separation
of
concerns,
is
something
I'm
really
trying
to
maintain
I'm,
not
saying
the
functionality
shouldn't
exist.
I
think
that
it's
definitely
valuable.
It's
been
something
that
people
have
asked
for,
but
I
think
mixing
things
together,
especially
like
yes,
some
people
might
want
this,
but
is
this
the
most
important
thing
and
we
want
to
make
the
thing
that
may
be
most
things
are
gonna
rely
on
more
complicated
for
the
use
cases
of
a
few
verses?
C
B
D
B
C
C
My
hope
would
be
is
that
the
simplest
stuff
can
remain
simple
and,
like
a
higher-order
thing,
that
I
think
you
could
have
a
higher
order
placement
resource
that
did
both
selector
based
placement
and
also
applied,
or
try
to
apply
rules
about
order
of
placement
or
like
how
that's?
How
do
you
describe
the
feature?
You're
talking
about?
C
Okay,
like
a
procedure
or
like
I,
don't
know
what
you
want
to
call
it,
but
something
like
that.
But
hopefully
there
could
be
kind
of
like
a
uniform
interface
up
top
over
time
like
if
initially
it
might
be,
a
good
idea
that
implemented
separate
resources
because
we're
not
necessarily
sure
how
things
are
going
to
evolve,
but
as
things
solidify
and
we
develop
good
solutions,
I
don't
see
why
you
couldn't
have
higher
order.
Things
collapsed
because,
frankly,
I
mean
the
lower
level
stuff
I'm,
seeing
less
and
less
reason
to
have
template
and
overrides
separate.
C
We
still
needed
a
generic
way
to
apply
overrides,
but
you
know
at
some
point.
It
might
make
sense
to
have
overrides
and
template
in
the
same
resource
just
to
reduce
the
complexity
for
the
user.
The
only
real
reason
we
need
to
have
it
separate
was
to
sort
of
give
us
room
to
evolve
and
also
potentially
have
different
like
to
be
able
to
have
selective
auerbach.
But
if
we
can
use
sub
resources
safer
overrides,
then
there's
no
reason
you
couldn't
have
them
existing
in
the
same
resource.
If
we're
happy
with
the
form
they're
taking.
C
B
B
What
we
mean
by
implement
the
push
reconcile,
especially
like
like
say
for
this,
for
this
feature:
for
example,
there's
replica
status
and
cluster
I
want
to
place
it
one
after
the
other
family,
pushing
through
all
the
clusters
and
if
I
had
to
implement
such
a
policy
right
right
now,
I
may
not
be
able
to
use
this
whatever
the
existing
thing
controller
right.
No,
you
would
be
I.
D
We
can
talk
about
this
offline,
like
I,
I,
sort
of
understand
this,
because
this
is
what
I
am
doing
in
the
in
the
shad
Yuling
resource
like
this
is
what
time
and
link
I
mean.
This
is
how
I'm
handling
it
I
think
that's
what
is
I
mean.
That's
the
whole
point
of
having
the
basic
here
and
the
higher
level
or
the
higher
order.
Api
is
and
controllers
for
them.
I.
C
C
C
D
C
Those
can
be
sort
of
handled
separately,
like
that.
You
know,
I,
think.
The
biggest
thing
for
me
is
the
separation
of
concerns
both
for
development.
You
know
for
maintainability
for
development
speed
and
also
just
limiting
the
amount
of
complexity
we
have
to
think
about
at
any
one
point:
I
found
it
very
difficult
to
work
with
v1,
because
whenever
we
had
to
make
a
change
to
something,
it
was
so
entangled
that
one
change
could
have
really
unexpected
consequences.
A
D
D
D
C
I
think
the
the
TLDR
for
me
was
that
there's
pr's
up
that
are
implementing
support
for
C.
Are
these
okay
I
expect
to
have
that
merge
by
the
end
of
the
week
and
that
kind
of
opens
the
door
for
the
next
step,
which
is
actually
moving
all
of
the
Federation
resources
to
see
our
DS,
so
my
goal
is,
is
basically
removing
the
need
for
an
API
server
as
a
precondition
for
going
releasing
an
alpha
and
that'll
be
also
in
concert
with
moving
to
the
C
or
D
version
of
the
cluster
registry.
C
D
Okay
makes
sense
so
about
CR,
DS
I
I.
Had
a
brief
look
at
one
of
your
PRS
I
haven't
actually
gone
through
the
code
that
you
submitted.
So
when
you
say
those
PRS
are
adding
support
for
CR
DS.
That
I
understand
is
that
they
would
be
adding
support
to
federate
any
given
CID
resource.
Am
I
right
or
correct.
C
Okay,
so
that's
kind
of
the
starting
point
and
getting
some
degree
of
understanding
of
series
and
then
the
next
step
is
just
moving.
Everything
to
CRT
that'll
also
be
I
mean
there's
an
investigation
required
around
validation,
but
if
that
can,
if
that
hurdle
can
be
cleared,
then
moving
to
C
or
D
will
also
imply
moving
off
of
the
API
server
builder
and
on
some
scoot
over,
but.
D
At
least
two
are
probably
all
terminal
right
like
rest
of
the
API
is
so
far
implemented
they
if
they
need
to
be
moved
as
CR
DS
to
an
existing
API
server
or
abdicated
or
joined
with
an
existing
a
case
that
I
don't
know
how
to
put
it,
for
example,
use
the
chaos
API
sever
and
just
run
the
Federation
as
CRD
resource.
All
of
these
API
is
a
CRE
resources
and
then
federating
CRE.
These
two
are
also
gone.
Alright,.
D
C
That
makes
sense
that
makes
sense,
and
it
also
means
that,
like
currently
all
of
the
templates
and
placement
and
override
resources
for
the
types
that
are
implement
already,
there
are
first-class,
the
API
types
and
in
order
to
sort
of
support,
CR
DS,
it
could
be,
you
know,
created
dynamically.
All
of
the
the
same
controller
had
to
be
moved
to
use
the
dynamic
client,
and
so
once
sink
controller
is
easily
mended,
Emma
client
and
it
doesn't
need
an
API.
Then
everything
can
be
a
CR
D.
C
So
it's
you
could
do
it
without
the
dynamic
client,
because
I
mean
the
Builder
will
generate
new
clients
tubs,
but
if
you're
using
client
stubs.
That
means
that
you're
you're
still
needing
adapters
right
as
though
so
the
move
to
the
dynamic
client
means
everything's,
a
c
rd.
You
don't
actually
have
any
special,
like
you,
don't
actually
code
behavior
to
support
a
tank
anymore,
and
so
the
the
next
step
after
this,
but
I
haven't
really
talked
about
this
far.
C
C
It'll,
be
a
controller
that
actually
generates
this,
the
seer,
the
primitives
as
seer
DS,
and
then
the
generation
and
configures
it.
So
what
I'm
suggesting
is
that
the
path
were
going
down
is
that
it
should
be
possible
to
federate
every
single
resource
in
an
API,
because
you
could,
you
can
have
a
controller
that
looked
at
the
discovery.
Endpoint
looked
at
every
single
type
made
sure
there
is
a
federated
or
Federation
resource,
description
or
resource
definition,
kind
of
like
equivalent
to
C
or
D,
and
then
some
other
controller
would
read
that
and
generate
the
primitives.
C
C
C
C
You
can
generate
a
CRD
for
attempt
for
a
template
and
for
and
you
can
use
gamal
to
create
resources
and
manipulate
them
in
the
API,
and
then
the
propagation
controller
would
wouldn't
need
any
specialty,
wouldn't
have
to
be
changed
like
you.
Can
it's
gonna
know
how
to
work
with
the
CRT
simply
on
the
basis
of
API
resources.
C
A
C
C
It
was
switched
to
the
dynamic
clients,
but
again
it
means
that
there's
no
such
thing
as
an
adapter
like
it
basically
treats
the
API
types
like
it's
almost
like
dark
typing,
but
on
the
level
of
API
resources.
As
long
as
it
has
a
template
field,
who
knows
what
to
do
it?
As
long
as
the
placement
has
a
cluster
names
field
knows
what
to
do
with
them
and
it
doesn't
need
like
a
hard-coded
type.
Unstructured
is
what
the
dynamic
client
uses
internally
and
it's
basically
just
a
map
of
interfaces.
C
It's
just
all
the
way
down
so,
but
all
I
have
to
say
is
that
the
goal
here
is
just
dramatically
like
making
everything
dynamic
yeah
so
that
we
don't
have
to
have
courage.
Is
the
port.
You
know
the
behavior
we
used
to
have
to
write
code
for,
like
all
the
adapters,
are
gone
at
the
end
of
this
of
this
PR
chain,
and
everything
is
just
defining
this
configuration
okay.
D
C
A
C
C
C
If
somebody
knows
some
other
thing
that
works
that
way
like
I'm,
not
on
arc
station,
I
don't
understand,
but,
for
example,
like
HPA
well
enough
to
know
that's
something
that
would
be
a
pattern
that
could
apply
that
as
well,
but
I
guess
I
should
say:
I've
been
pretty
excited
at
the
prospect
of
not
having
to
write
code
for
this
stuff,
because
you
know
remember
having
conversations
last
year
where
it
seemed
like
we
just
had
to
write
code,
and
so
we've
gotten
to
the
point
where
it's
like.
Oh
actually,
we
don't
have
to
write
code
yeah.
C
C
D
C
When
I
say
terrible,
I
mean
for
me
I'm
more
worried
about
just
getting
it
done,
then
it
maintainable,
so
I
would
say
maybe
terrible.
It's
kind
of
vague
I,
don't
think
the
code
that
I'm
writing
is
particular
than
maintainable
and
I
definitely
want
like
for
the
Alpha.
Maybe
I
don't
care,
but
once
we
start
thinking
about
going
beta
and
I'm
gonna
definitely
want
to
clean
things
off
and
make
it
so
that
it's
it's
concise,
its
documented
its
tested.
C
D
This
idea,
we
are
also
working
with
Nick
I,
think
we
did
talk
about
this
earlier,
that
the
mandate
to
us,
like
Shashi,
I
and
one
or
two
other
internal
folks,
is
that
if
we
are
able
to
drive
the
b2
with
some
feature,
parity
with
some
level
of
which
apparently
has
even
until
becomes
alpha,
then
it
will
be
a
beautiful
mess
right.
Yeah.
C
A
C
I
think
the
cost
of
prototyping,
where
there's
strong
separation
of
concerns,
I,
think
that's
acceptable.
If
we
were
recreating
Federation
v1
and
everything
was
just
tied
together,
it
would
be
like
it
would
be
impossible
to
actually
drive
it
to
a
position
of
quality,
all
right,
I
think
if
it
things
are
like
isolated,
you
can
take
a
little
piece
and
improve
the
quality
independent
of
everything
else
and
I
done.
I
think
we're
the
other
potential
arts.
You
succeed,
yep.
D
Anything
you
can
close
Nikki
yeah
one
more
thing.
Just
just
one
last
thing
see
the
updates
to
the
notes
can
be
done
by
anybody
actually
but
I'm,
not
sure
who
all
does
not
have
write
access
to
this.
Does
it
make
sense
to
give
write
access
to
the
mailing
list
that
sig
multi
cluster
the
movie
broke?
I
mean
I.