►
From YouTube: Kubernetes Federation WG sync 20180718
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
Oh
actually
sure
what
we're
intending
to
talk
about
today,
we've
already
met
a
couple
times
this
week.
I
don't
see
anything
on
the
agenda,
so
he
did
say.
No
sorry,
not
sure
she,
her
phone,
sorry
what'd,
she
say
he'd
be
joining
shortly,
but
I
don't
know
if
he
has
any
particulars
that
were
intending
to
talk
about
I.
A
A
And
I
will
say,
for
my
part,
I
mean
some
of
this
alpha'
discussion.
You
know
focusing
on
priority
is
all
well
and
good,
but
part
of
me
thinks
that
the
real
important
thing
is
actually
getting
people
to
use
it
like
find.
Huawei
has
priorities
that
they
want
done
and
read.
You
know,
house
priorities,
we
want
time,
but
I
mean
ultimately
from
my
point
of
view.
A
A
B
A
B
D
B
Sure
so
so
we
have
this
tradition,
vns
I,
don't
have
any
right
up
right
now
so,
but
we
have
some
issues
which
have
been
created.
So
the
idea
being
like
there's
a
reddish
appearance
related
code,
which
we
want
to
maintain
outside
the
Federation
me
to
Ripple,
so
that
Federation
b2
will
be
kind
of
umbrella
kind
of
Faribault,
from
where
we
want
to
do
a
release
or
Federation.
B
So
Federation
DNS,
ideally
should
not
do
any
package
dependence
in
to
partition,
v2,
so
I
think
we'll
be
using
a
Cooper
builder
and
defining
the
types
required
for
partition
DNS
independently
in
that
repo
and
defining
the
features
are
implementing
the
features.
So
this
could
be
kind
of
a
pattern
for
other
features
going
forward.
So
that's
one
step
not
to
depend
on
a
foundation
we
do
so.
B
Currently
there
is
one
type
CRE
that
like
multi
cluster
service,
DNS
type,
which
is
in
tradition
v2
as
of
now
so
for
that
type,
if
it
has
been
split,
like
type
is
in
addition,
v2
and
the
feature
actually
is
enough:
Federation
DNS
repo.
So
we
are
going
to
move
that
particular
part
to
make
it
easy
and
then
I
think
most
all
of
you
are
going
to
make
it
official
repo,
so
I'm
little
unsure
about
that
process.
Right
now,
yeah
we'll
try
to
figure
that
out,
yeah
and.
A
What
are
to
be
the
integration
with
I
mean
I.
Guess
that
there's
a
piece
here
that
sort
of
is
common
between
like
Federation
and
multi
cluster
is:
is
there
any
eye
towards
moving
that
into
may
be
its
own
repo,
so
it
would
be
shared
having
Federation
and
multi
cluster
being
separate
repos
from
wrong.
What
I'm?
What
I'm
talking
about
is
like
federated
cluster
and
the
cluster
controller?
We
seem
to
be
common
elements
and
also
I
mean
federated
service.
A
A
D
A
D
I
think
that,
like
there
are
probably
steps
that
we
can
do,
it
sounds
like
I
personally
need
to
read
up
a
little
bit
more
on.
Like
the
controller
part,
that's
in
Federation
v2,
but
like
the
the
model
that
Shashi
and
I
were
kind
of
discussing
exploring
is
when
we're
like
features
exist
in
independent,
like
repositories
and
and
Federation
is
like
the
umbrella
where
you
go
to
get
them
all
like
into
one
another,
with
versions
that
will
work
together,
so
yeah
I
think
there's
additional
exploration,
work
that
needs
to
be
done,
but
one
thing
I.
B
E
A
D
I
would
say
if
it
essentially
outweighs
the
trouble
of
having
separate
repos
of
water
spectrum
of
folks
that
are
sitting
collaborating
on
parts
of
it.
I
do
think
in
this
particular
case,
Joshy
I,
wonder
if
you
and
I
need
to
like
write
something
up
about
what
oh
and
make
sure
we
fully
covered
like
what
we
think
the
transformations
are
on
paper
to
make
sure
that
we're
actually
doing
right.
F
D
To
me,
work
on
I
think
I
think.
The
answer
is
that,
like
I
won,
I
think
it's
easier
to
iterate
on
smaller
pieces,
and
these
are
just
my
own
subjective
opinion
here.
D
So
if
we
build
a
single
repository
that
has
doodles
of
features,
I
tend
to
think
that
the
the
people
that
will
want
to
collaborate
with
us
are
only
going
to
be
people
that
want
all
of
this
and
that
people
might
be
turned
off
by
a
single
group
that
has
a
whole
slew
of
different.
That's
my
subjective
opinion.
It
has
borne
out
with
a
couple
books
that
I
talked
to
the
community,
but
I'm
just
one
person
with
my
own
experiences.
F
Why
I
say
this
is
because
there
is
a
big
benefit
in
doing
stuff
inside
the
same
repo
in
terms
of
usage
of
especially
dependencies
and
tests.
So
all
the
integration
tests
see
to
attest
that
we
are
building
they
can.
They
would
be
useful.
We
remain
inside
the
same
repo,
but
if
you
are
trying
to
build
up
something
parallel
or
something
I
mean
maybe
a
small
functionality,
but
maybe
somewhere
else,
then
you
have
to
build
the
same
CI
system
same
integration
test
equally
test
there.
A
Mean
we
we
need
to,
we
need
to
split
the
dependencies
in
a
way
that
makes
sense
so
that
we
can
consume
it
from
multiple
memory
pose,
but
I
think
I
I
think
it's
worth
it
like.
This
is
this
is
Direction
core
cube
is
going,
and
I
really
would
prefer
that
we
don't
kind
of
continue
down
a
path
that
is
kind
of
deemed
like
non-productive.
A
F
Okay,
I
mean
I'm,
not
saying
I
I'm,
not
seeing
as
I
said
earlier,
I'm
not
objecting
to
doing
this
I'm
just
sort
of
putting
out
my
thoughts
like
these
are
the
thoughts
that
came
to
my
mind
and
when
I
actually
gave
up
you
thought
about.
If
we
want
to
move
that
tradition,
a
multi-class,
a
DNS
API
externally,
and
then
you
have
to
probably
test
it
out
or
do
something
so
that
it's
releasable
right
now,
I
guess
she
just
did
some
basic
stuff
so
that
a
controller
could
be
run
from
that
separate
repo.
B
I
kind
of
agree
that
there
is
quite
a
lot
of
common
code
like
like
the
safe
retreat
and
informa,
which
might
be
need
to
be
used
in
of
the
repose
and
the
CI
again
I.
You
need
to
build
saya
for
each
step.
Oh,
and
there
is
a
release
management
over
it.
I
don't
think
we
should
not
get
burned
like
we
should
not
get
done
with
this
operation.
D
Well,
let
me
ask
this
question
this
is:
does
anybody
think
that
we
conclusively
know
the
right
way
to
do
this,
because
I
don't
think
that
we
do
I
do
think
that
in
the
case
of
Federation
DNS
like
me,
you
can
have
like
an
odd
situation
as
Joshy
is
like
observe
earlier
than
this,
meaning
that,
like
API,
is
in
one
place
and
the
actual
features
in
another
I
think
that
we
should
put
them
in
the
same
place.
D
The
Federation
be
to
repository
is
like
the
same
place
that
makes
the
most
sense
for
them
to
live
until
we
can,
at
least
until
we
can
take
a
look
at
untangling
like
dependencies
like
federated
Informer,
federated
cluster,
etc.
That,
like
are
the
essentials
that
you
would
need
to
build
other
other
know
about
other
features
or
Federation
beat.
It
doesn't
make
sense
to
like
eight
Federation
DNS
and
put
it
into
Federation.
Beat
you
the
next
step.
F
F
A
A
I
mean
that
to
me
that's
kind
of
in
the
near
term:
that's
because
we
have
generated
clients
and
that's
not
a
long
term
like
that's
going
away,
because
that
it
would
have
to
continue
to
vendor
would
be
the
API
over
the
longer
term.
So
I
think
I
think
there's
a
good
case
to
be
made
that
the
API
be
separately
venerable
I
mean
I've,
had
discussions
with
Jonathan
about
cluster
registry
that
like
when
we
were
initially
trying
to
vendor
it
into
Federation
b2,
it's
like
wow.
This
is
really
painful.
A
Is
there
a
way
we
could
do
this
better
and
the
suggestion
was
well
get
a
repo,
it's
just
the
API.
Just
like
you
have
cube
API,
then
you
could
vendor
that,
and
you
wouldn't
wouldn't
get
amazing
stuff
that
you
don't
actually
need
and
I
kind
of
think
that's
the
direction
we
want
to
go
versus
I,
just
stuck
everything.
D
D
I
agree,
I
think
it's
weird
that
the
controller
that
backs
this
feature
isn't
in
the
same
place
as
the
API
and
that's
what
is
overall,
informing
my
motivation
that
the
end
goal
should
be
one
where,
like
the
different,
the
different
functional
areas
that
have
like
discrete
features
are
in
separate
repositories
that
are
independently
useful.
So
people
don't
feel
like
they
have
to
accept
the
whole
system,
if
they're
only
interested
in
one
piece
and
that
the
integrations
between
them
are
like
are
developed
in
a
project.
D
A
Although
I
mean
the
things
that
are,
in
one
rate,
lower
I
mean
they're
logically
isolated,
like
the
idea
that
oh
everything
has
to
be
in
the
same
repo,
because
they're
all
somehow
related
like.
If
your
goal
is
making
things
independently,
consumable
I'm,
not
sure
why
you
want
to
stick
everything
in
the
same
repo
and
actually
think
that
yeah.
D
My
point
in
inputting
them
into
the
same
repo,
was
a
response
to
the
fact
that
there
is
this
like
shared
set
of
infrastructure
resources
that
you
you
just
brought
up
as
the
reason
not
to
pull
it
all.
The
way
out.
I
was
thinking
that
as
an
interested
special
step,
so
that
we
can
keep
the
whole
implementation
in
one-one
place.
While
we
examine
what
would
it
take
to
make
those
shared
pieces,
independent
I.
A
D
I'm,
having
trouble
understanding
how
you
would
want
to
arrive
on
it
on
the
future
I
described
where
Multi
cluster
DNS
is
independently
useful,
then
I'm
hearing
don't
don't
combine
Federation
DNS
into
Federation
v2
as
a
next
step
and
then
also
hearing.
Don't
don't
move
the
stuff
it's
in
Federation
v2
into
Federation
DNS.
So
at
this
point,
I'm
suggestions
for
what
the
next
steps
might
be
for
us
to
know
what
to
do.
I.
A
A
A
D
That's
exactly
what
what
I
was
suggesting
as
like
a
next
step,
so
that
we
could
get
the
feature
into
a
single
place,
which
I
think
is
desirable
and
determine
at
that
point.
Do
we
need
to
extract
the
shared
pieces
that
are
like
federated
cluster
etc
into
a
separate
dependency
that
both
Federation
v2
and
multi
cluster
DNS
or
Federation
DNS
can
use.
G
G
So
the
next
question
is:
how
do
we
get
there
and
it
seems
like
for
some
of
the
components
federated
DNS,
for
example,
we're
already
halfway
there
in
that
it
is
in
its
own
repository
it
vendors
in
the
stuff
that
it
needs,
which
happens
to
be
a
big
glob
of
the
entire
repository
of
Federation,
be
true,
but
that's
a
hopefully
a
temporary
situation,
but
it
is
self-contained
in
that
it.
It
has
its
own
API
its
own
controller,
and
it
depends
on
various
things
in
Federation.
B.
Is
that
accurate.
G
G
Maybe
the
next
steps
are
to
identify
what
we
consider
to
be
the
independently
reusable
pieces
that
are
currently
all
housed
in
Federation
v2
off
the
top
of
my
head.
That
would
seem
like
each
of
the
API
objects
that
we
have
each
of
the
controllers
that
we
have
and
each
of
the
reusable
libraries
that
we
have
things
like
clients
in
API
clients
and
DNS
libraries
and
caching
there
was
a
one
of
them
was
mentioned
earlier.
I
figured
what
it's
called
federated
Informer
I
think
it
is
so
those.
E
G
Kinds
of
things
seem
like
independently
reusable
libraries
and
it
seems
like
we
would
like
to
put
each
one
of
those
in
their
own
repo
and
have
it
independently
at
least
unit
testable
and
then
have
a
place
where
we
can
pull
so
pull
these
things
together
into
coherent
features
or
products.
If
you
like,
yeah.
D
A
G
D
And
I
may
not
stick
on
how
we
get
there
I
think
they're
an
arbitrary
number
of
right
ways
to
do
it.
If
people
are
open
to
open
to
looking
at
what?
What
are
the
right
things
to
do,
that
evaluation
beats
you,
then
we
extract
and
then
bender
back
in
the
Federation
view
and
also
multi
cluster
demoness
I.
Think
that
would
be
a
great,
very
ready
awesome.
F
Yeah
and
about
this
I
have
one
counter-argument
to
this
like
I,
don't
clearly
think
that
putting
all
the
pieces
like
you
have
a
feature,
for
example,
multi-class.
The
DNS
is
one
feature:
sync
controller
is
one
feature
or
sync
loop
or
sync
mechanism
is
non
feature
all
that
stuff
into
its
own
repo
has
its
own
overhead
and
I,
don't
see
segregating
that
out
into
its
own.
G
E
G
If
you
don't
have
a
you
know,
a
fairly
strict
enforcement
of
removing
unnecessary
dependencies,
so
the
question
becomes
I
believe
is
the
cost
of
actually
putting
them
in
their
own
repo
and
running
their
own
unit
or
testing
infrastructure,
and
you
know
permissions
on
the
repo
and
whatever
other
overhead
there
is
associated
with
it
with
a
repo.
Does
that
justify,
or
is
that
justified
by
the
fact
that
the
dependencies
between
the
repos
are
more
easily
kept
strictly
well-defined?
G
A
And
I
think
for
me
that
sorry,
I
think
the
answer
is
yes
and
my
my
reasoning
is
that
maintaining
like
this
separation
is
key
to
I,
think
enabling
third
party
contribution,
because
if
we
ever
bring
in
the
same
repo,
it's
very
easy
to
allow
integrations
within
that
repo
without
even
thinking
about
it.
Yeah.
It's.
C
A
One
more
thing:
I
should
say
that
this
is
kind
of
the
goal
that
we're
looking
towards
I'm,
not
saying
we
have
to
hit
it
immediately,
it's
more
like.
If
we
keep
this
in
mind,
and
you
know,
decisions
that
could
go
one
way
or
the
other
are
made
on
the
side
of
we're
gonna
try
to
separate
these
things
out.
A
You
know,
hopefully,
before
too
long,
eventually
we'll
get
there
and
I
think
you
think
there
is
risk
involved
in
this
approach
and
I
think
Iran
is
concerned
about
the
testing
is
probably
the
one
that
is
foremost
in
my
mind
and
I
I,
just
I
mean
not
too
concerned
that
we'll
be
able
to
solve
it
because,
like
I
said,
the
wider
cube
community
is
kind
of
facing
the
same
challenges.
So
there's
a
lot
of
smart
people.
Thinking
about
how
to
do
this,
we're
not
we're
not
alone.
D
So,
for
me,
I
I
think
that
the
like,
as
you
you
put
very
eloquently,
Quintin
I,
think
we
have
a
shared
like
idea
of
what
we
think
should
happen.
But
my
read
of
like
the
uncertainty
in
the
room
is
really
one
around
like
we're,
not
certain.
If
the.
If
the
the
additional
overhead
of
multiple
repos
is
worth
it
and
I
I
think
be
I,
think
I
would
be
okay
if
we
decided
that
we
want
to.
Since
we
don't
yet
have
like
a
you
know,
specific
requests.
D
G
Yeah
I
agree
with
that.
I
think
I
would
prefer
not
to
you
know,
stop
the
train,
while
we
figure
out
how
to
pull
things
apart
and
put
them
in
there
in
repose.
We've
done
that
in
the
past
before
and
held
things
up,
one
one
approach
that
might
work
well
is
to
say
whenever
anybody
wants
to
reuse
a
piece
of
what's
in
Federation,
B,
first
of
all,
I
think
we
should
I
think
up
front.
We
should
just
make
a
list
of
what
we
believe
the
independently
reusable
components
are
yeah.
C
G
Presumably
you
don't
need
all
of
Federation
v2
you
actually,
after
you
know
some
subset
of
these
things
and
then,
as
part
of
that
exercise,
we
pull
those
those
pieces
out
and
so
that
they
can
be
independently
vendored
and
that
unfortunately,
put
some
of
the
burden
on
the
person
wanting
to
reuse
the
stuff,
which
is
which
is
not
ideal,
but
hopefully
that's
doable.
The
other
quick
question
I
had
was
so
sure
she
now
has
concrete
experience
with
operating
an
independent
Reaper
being
the
Federation
DNS
stuff
federated
DNS.
How
big
is
that
overhead
I
mean
you
have?
B
To
answer
that
I
do
feel
I.
This
water
is
gonna,
be
too
big,
because
you
need
to
come
up
with
your
own
CI
infrastructure.
Then
you
need
to
think
about.
How
are
we
going
to
plant
this
at
least
artifacts,
like
you're,
going
to
your
separate
container,
and
then
that
should
be
deployed
and
consumable
by
user,
and
also
like
a
for
a
user,
for
example,
if
he
wants
both
of
them?
B
Okay,
now
you
need
to
depend
on
both
or
oppose
vendor
in
both
that
oppose,
and
try
to
use
that
so
I
do
feel,
there's
a
lot
of
override
in
maintaining
it
in
multiple
repos,
okay,
so
maintaining
a
team
in
a
single
rapport
reduces
that
warrant
Lord.
So
that's
where
community
started
so
it
became
too
big
for
the
other
tools
to
support.
That's
why
we
tried
segregating
function
domain
so,
but
I
believe
Federation
is
a
lot
less
compared
to
what
kubernetes
was
so
I
do
think
at
the
moment
the
trade-off
could
be
like
maintaining
it.
B
G
That
makes
sense.
Yeah
I
mean
that's
a
very,
very
pertinent
observation,
so
kubernetes
the
whole,
the
kubernetes
project
has
thousands
and
thousands
of
contributors
and
and
I,
don't
know
the
exact
number,
but
hundreds
of
commits
every
day,
Federation
v2,
even
if
you
take
all
of
the
bits
together
has
you
know
six
or
something
contributors
and
substantially
less
than
hundreds
of
commits
per
day,
thoroughly
delude
ourselves
into
believing
that
it
is
the
same
size
problem.
G
G
I,
don't
want
to
take
up
too
much
of
the
meeting,
but
but
just
sure
she
to
get
a
sense
of
how
big
that
effort
is
so
so
you
you
run
the
you've
developed
the
federated
DNS
stuff
and
you've
essentially
run
the
repo
in
the
sense
of
just
CIC
stuff
and
releases
and
testing
oh
yeah
documentation,
whatever
is
as
a
percentage.
How
much
of
your
time
is
spent
building
the
DNS,
the
federated
DNS
code
versus
the
overhead
of
running
that
repo?
B
G
Just
to
be
clear,
I'm
I'm
not
totally
convinced
that
that
that
that
overhead
needs
to
be
borne
by
federated
DNS
controller,
so
I
would
I
would
not
necessarily
jump
it
to
the
conclusion
that,
let's,
let's
assume
in
a
world
where
we
have
split
Federation,
v2
up
into
20
repos.
So
there's
you
know
one
for
each
API
group
or
API,
and
one
for
each
controller
and
one
for
each
library,
etc.
I'm,
not
sure
that
every
one
of
those
should
be.
E
G
I
think
that
I
mean
I
would
call
those
component
tests
so
takes
federated
DNS.
As
an
example,
if
I
had
some
tests
that
built
a
federated
DNS
controller,
you
know
generated
a
couple
of
API
objects,
that
it
depends
upon
and
verify
that
it
generates
the
right
DNS
records
that
that's
the
kind
of
testing
I
would
imagine
that
that
that
repo
would
have,
as
opposed
to
you,
know,
connecting
to
a
bunch
of
well.
B
G
If
that
isn't
the
job
of
the,
what
we
can
call
the
integration
repo
or
that
this,
this
repo
that
Paul
referred
to
earlier,
which
which
pulls
in
all
the
dependencies
to
produce
a
what
I,
would
call
a
product
and
maybe
Federation
b2,
is
a
probably
various
flavors
of
it.
But
one
can
imagine
having
a
repo
which
pulls
in
all
the
dependencies,
all
the
different
controllers,
that
it
needs
for
a
functioning
Federation,
v2
control,
plane
and
tests.
That.
B
D
D
H
D
B
Unlike
before
that,
like
presumption
right,
so
we
were
talking
about
like
for
a
user
to
be
independently
consumable
right,
so
mostly
if
it
is
a
single
loophole.
So
when
we
do
something
like
a
code
level
imports
right,
it
won't
import
all
the
things
right.
Only
the
go
packages
am
I
correct
right,
like
user
still
can
do
wholly
part
import
just
the
packages
they
need
like
just
the
EPS,
they
need
so
I
I,
don't
think
it's
a
difficult
stuff,
but
instead,
if
you
have
too
many
repos,
so
I
think
that
that
might
come
at
you.
Yeah.
D
We
I
don't
I,
definitely
think
we
do
not
want
to
mini-me
purrs
I.
Tell
you
what
it
sounds
like
the
action
item
here
is
Shashi
and
I.
Maybe
you
and
I
can
like
pair
up
and
let's
look
at
everything.
That's
like
a
in
Federation
v2
in
in
multi,
clustered
DNS
and
like
do
it
right
up
on
on
extracting
shared
pieces
and
what
it
would
look
like
at
the
end,
and
then
we
can.
B
B
D
G
I,
don't
know
how
many
people
are
aware
of
the
email
thread
that
happened
yesterday
on
this
topic,
so
maybe
I
can
just
give
a
very
brief
overview,
so
we
have
at
least
one
person
who's
very
keen
to
actively
contribute
from
China
and
I
would
like
us
to
have
more
of
those
over
time.
It's
extremely
difficult
for
people
in
India,
China,
Australia,
etc
to
attend
a
meeting
that
is
held
at
the
current
time
because
it's
close
to
the
middle
of
the
night
for
them.
G
So
one
proposed
improvement
to
that
would
be
to
shift
the
current
meeting
to
hours
earlier.
It
has
the
explicit
disadvantage
that
people
on
the
west
coast
in
the
US
would
have
to
attend
at
7:30
a.m.
I'm,
one
of
those
people
I,
don't
have
a
problem
with
that,
but
I
can't
speak
for
the
rest.
I
think
Meru
is
here
as
well.
I
don't
know
what
his
feelings
are
on:
7:30
a.m.
G
the
the
exact
day,
I
think
we
can
make
flexible
because
it
would
make
it
happen
before
any
other
kubernetes
meetings
and
I
would
just
point
out
that
you
know
people
who
are
very
actively
involved
in
the
development
of
the
project.
Obviously,
there
their
opinions
way
heavier
than
those
who
may
just
be
listening
in,
because
presumably
they
could
listen
in
on
a
video
recording
at
any
time
that
suits
them.
G
So
right
now
we
seem
to
have
you
know
somewhere
in
the
order
of
four
to
six
active
participants
in
these
meetings,
and
we
have
a
an
additional
one
wanting
to
join
from
China.
So
the
aim
is
to
try
and
make
make
something
that
works
well
for
all
of
those
people.
Two
of
the
four
to
six
active
participants
at
the
moment
are
in
India,
and
it
is
what
time
is
it
there
now
11
p.m.
something
like
that.
F
G
E
E
G
Great
there
is
another
alternative
which
is
to
have
two
meetings,
one
at
a
time
that
is
convenient
for
people
in
the
more
westerly
time
zones
and
one
that
is,
it
I'm,
more
convenient
to
there's
two
time
zones.
My
past
experience
is
that
that
doesn't
work
very
well.
If
you
have
half
the
people
attending
half
the
meetings
and
the
other
half
attending
the
other,
half
it's
not
worth
the
trouble
I
would
I
would
favor
one
way
everybody
can
attend,
even
if
it's
not
ideally
convenient
for
everyone
cool.
So
we
haven't
heard
any
objections.
F
G
G
D
F
Thank
you
one
last
thing
before
we
log
off
so
far,
we
haven't
done
an
announcement
of
the
release.
We
actually
did
cut
out
the
release
last
week,
so
we
have
early
stage,
but
we
haven't
made
any
announcements.
So
if
nobody
else
is
planning
to
send
the
mail
or
to
the
common
man
in
this
like
signal
future
and
maybe
electricity,
then
I'll
do
it.