►
From YouTube: Kubernetes SIG Multicluster 2021 Apr 27
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
A
All
right
we'll
give
it
a
few
minutes
I'll.
Just
let's
see.
A
Just
let
everybody
know
I've
got
a
time
box
this
one
to
30
minutes.
Unfortunately,
jeremy's
unable
to
join
so
we'll
just
have
to
time
box
the
meeting
to
30
minutes
today.
B
B
A
A
All
right
laura,
I
think
you
can
go
ahead
and
get
started
now
I'll.
Just
I'll.
Do
my
little
intro
welcome
everybody
to
the
tuesday
april
27
2021,
meeting
of
sig
multi-cluster
and
laura
has
both
of
the
agenda
items
today.
Laura.
B
Take
it
away.
Thank
you,
okay.
So
there's
kind
of
two
points
I
wanted
to
talk
about
today,
but
really
the
first
one
is
the
the
major
one
about
an
update
for
just
the
general
alpha
to
beta
graduation
plan
and
jeremy.
I
like
liaise
with
jeremy
about
this
because
he
can't
be
here
today.
So
if
there's
more
conversation
about
this
later,
especially
if
jeremy
wants
to
put
in
any
two
cents
for
anything,
that's
discussed,
then
we
can.
B
You
know,
do
this
more
than
just
today,
but
I
wanted
to
give
kind
of
a
little
update,
so
I'm
gonna
present
these
slides
like
this
and
just
kind
of
go
through
a
little
bit.
B
So
I
put
a
bunch
of
background
here,
especially
for
people
who
maybe
are
new,
but
kind
of
the
important
thing
I
want
to
say
is
that
I
think
we've
made
a
lot
of
updates
between
the
for
these
points
for
alpha
beta
graduation.
B
So
I
want
to
update
everybody
kind
of
give
you
my
two
cents
of
where
I
think
everything
stands
determine
any
next
steps
for
any
open
items
and
then
in
particular
one
of
the
things
we
could
discuss
now
or
at
least
open
the
floor
for
is
anything
else
we
may
or
may
not
want
to
put
in
this
beta
to
ga
graduation
spot,
because
that
defining
that
is
one
of
the
criteria
for
beta
graduation
as
well.
B
B
I
have
some
sort
of
questions
for
so
I'm
going
to
have
that
slide
shortly,
so
we
can
discuss
and
then
these
two
I
kind
of
saved
for
the
end,
but
maybe
we
want
to
discuss
these
as
well,
so
I'm
going
to
go
through
them
by
category
here,
first,
the
ones
that
I
think
are
done
or
like
complete
or
on
track.
B
So
one
item
is
detailed:
dns
spec
for
multi-cluster
services,
so
I
think
this
is
soon
to
be
done
on
track.
There's
a
pr
it's!
I
can
link
it
again,
but
it's
also
in
prior
agenda
notes
and
that's
currently
in
the
status
of
getting
reviewer
approval.
We've
been
talking
about
it
a
bit
here.
We
went
and
talked
to
sig
network
too.
So
I
think
that's
very
close,
so
I
think
that
one's
on
track
for
network
policy
either
resolved
or
explicitly
ruled
out.
This
one
is
explicitly
in
the
non-goal
section.
B
So
this
one's
finished,
a
formal
plan
for
a
standard
cluster
id
and
the
kep
for
cluster
property
was
the
plan
is
the
plan.
So
I
consider
this
formal
plan
part
done
here
and
then
finalize
the
name
for
the
super
cluster
concept.
This
also
has
been
done
previously.
It's
now
cluster
set-
and
I
just
did
a
quick,
triple
check
and
super
cluster
is
not
mentioned
anywhere
right
now.
B
So
before
I
go
to
the
next
one,
is
there
any?
You
know
secret
beef
with
any
of
my
perspective
here
of
thinking.
These
are
basically
complete
or
on
track
in
the
way
that
I've
said.
B
Yeah
we
made
a
sigs
repo
and
then
I'm
going
to
throw
in
sort
of
like
an
alpha
version
of
it.
Once
we
formally
move
this
kept
to
implementable,
there's
one
more
sort
of
cleanup
of
the
cluster
claim
words
to
cluster
property
to
do
there
and
then
the
other
thing
that
had
kind
of
slowed,
that
from
to
implementable,
was
that
finishing
up
the
api
group,
at
least
the
selection.
From
the
community
perspective,
though
it
is
pending
api
review,
since
it's
a
kates
dot,
io
locale,
so
yeah
did
that
answer
the
questions.
C
Yeah
actually,
who
who's
doing
the
api
review
was
that
me
did
I
get
to
sign
that
and
just
miss
it.
B
C
B
C
B
A
I
was
just
going
to
say
like
just
to
surface
the
a
little
bit
more
of
the
context
there,
like
part
of
the
discussion
that
we
had
in
cigarch,
was
around.
If
we
choose
to
have
a
crd
like
how
will
it
be
loaded
since
this
particular
one
is
a
case.io
subdomain
right
and
the
your
connection
with
nikita
was
over,
she
had
some
like
api
machinery,
ideas,
type
of
things
in
process
for
how
that
could
be
done
with
crds
right.
C
B
I
see,
I
think,
maybe
there's
two
ways
we
can
think
about
that,
because
I
think
that
we
can
kind
of
put
in
the
bucket
of
if
you
are
mcs
api
compliant.
You
need
to
have
loaded
the
crd,
because
it's
a
dependency
of
being
mcs
api
compliant
and
that
kind
of
puts
it
on
implementers
of
any
mcs
controller.
B
And
then
I
think
there
was
our
separate
interest
in
having
this
generally
available,
which,
from
the
cigars
sagar
discussion,
was
highly
dependent
on
this
work,
that
is
about
bootstrapping
crds,
which
is
still
tbd
and
not
really
not
something.
We
are
directly
working
on
right
now,
as
a
sig
to
from
a
control
perspective,
I
guess.
A
C
Of
it,
they're
going
to
also
take
the
requirement
of
well
if
you're,
using
cluster
lifecycle,
you
have
to
install
this
crd
and
we
will
eventually
hit
a
conflict
where
they
need
version
x
and
we
need
version
y
and
the
user
is
the
one
who
gets
screwed
and
that's
what
I
want
to
avoid.
So
I
would
say,
for
this
is
all
about
alpha
beta
right.
B
B
C
A
Is
that
fair
yeah,
I
think
that's
fair,
and
I
also
think
it
might
be
educational
to
like
have
have
it
initially
start
in
alpha.
As
a
crd,
it
might
give
us
good
data
for
like
what
kind
of
problems
shake
out
around
bootstrapping
crds
that
maybe
like
we
aren't
aware
of
yet,
but
I
would
definitely
say
that,
like
as
a
beta
criterion
it
we
have
to
feel
like.
We
know
the
implementation
shape
at
the
level
of
built-in
versus
crd.
C
A
C
C
B
C
Maybe
we
can
can
we
can
we?
I
know
nikita
is
going
through
some
crap
right
now.
Maybe
we
can
ping
that
ping
nikita
and
see
if
she
has
any
updates
or
something
that
we
can
read
before.
We
make
a
call
on
this.
I.
A
Would
I
would
say
like,
even
if
so,
even
if
there's
a
fully
formed
implemented
idea
for
bootstrapping
crds
like
I
would
still
like
some
burn-in
time
for
us
to
like
see
how
that
works
in
practice
during
an
alpha,
it
seems
like
the
kind
of
thing
that
there
could
just
be
so
many
like
things
that
come
out
of
the
woodwork
when
you
shine
the
light
on
it.
So
that's
that's
sort
of
where
my
head
is
at.
C
A
B
Okay,
so
what
I'm
hearing
is
to
plan
to
have
an
alpha
period
for
cluster
property,
where
it
is
a
crd,
which
was
the
advice
that
we
got
from
sig
architecture
when
last
we
went
in
that
process
determine
if
there's
anything
about
bootstrapping,
the
crd
that's
problematic.
If
we
leave
it
on
the
mcs
side
and
also
simultaneously
I'll
talk
to
nikita
and
keep
that
line
of
communication
open,
and
then
we
probably
will
discuss
again
both
from
the
mci
going
from
beta
to
ga
and
also
about
cluster
property.
Going
from
alpha
to
beta.
A
Yeah,
I
sort
of
wonder
if
we
need
to
choose
like
a
temporary
name
for
the
first
version
of
the
crd
that,
like
we,
we
know,
isn't
the
name
that
we
would
ideally
choose
to
accommodate,
for
if
we
do
turn
it
into
a
built-in,
we
can
do
that
while
it's
in
alpha
and
take
advantage
of
that
backward
incompatible,
change
do-ability,
while
it's
in
alpha,
I
don't
know
tim.
What
do
you
think?
Do
you
see
what
I'm
getting.
C
I
do
it's
sort
of
hacky,
but
I
get
what
you're
going
at
without
with
the
level
of
uncertainty.
Here,
that's
not
not
the
worst
idea.
I've
heard
you
propose
paul.
B
B
Cool
all
right,
so
I've
got
some
action
items
of
connecting
with
some
people,
and
I
think
this
non-permanent
api
group
idea
we
can
run
with
and
also,
I
think
it
will
overlap
when
I
submit
for
api
group
or
sorry
api
review.
C
B
Cool
okay,
I'm
gonna
move
on
for
now
on
this
one
just
so
I
can
give
the
rest
of
the
update,
but
I
will
circle
back
on
all
of
that
next
time.
B
Okay,
so
back
to
this
is
a
mcs
api.
Alpha
beta
point
here
about
api
groups,
since
we
were
just
talking
about
api
group
confusing,
but
one
of
the
items
in
alpha
to
beta
for
mcs
api
is
that
the
api
group
for
the
mcs
api
is
chosen
and
approved.
So
all
the
examples
in
the
cap
and
the
sig's
repo
itself
itself
are
multicluster.cates.io.
B
So
I
think
this
is
okay.
This
kind
of
predates
me,
but
unless
there's
any
drama
about
this
one,
I'm
going
to
consider
this
one,
possibly
okay
and
then
the
other
point.
Sorry.
B
So
we
were
just
talking
about
whether
it
should
be
tied
to
a
specific
cluster
property
status
and
or
api
maturity
stage.
So
I
think
that's
potentially
one,
and
then
I
also
pulled
out.
B
I
noticed
in
the
constraints
section
for
the
cap
that
there's
some
sort
of
vague
terminology
about
like
we
should
integrate
with
dual
stack
when
it's
figured
out
and
we
should
integrate
with
service
topology
api
when
it's
figured
out-
and
I
don't
know
if
we
want
to
make
that
something
explicit
about
a
beta
to
ga
graduation
point
and
also
how
we
should
proceed
next
steps
for
those.
C
That
is
a
great
point,
so
dual
stack
is
beta
in
mainline,
so
we
we
really
should
think
about
what
we
want
to
do
with
dual
stack.
C
C
C
A
C
C
C
Sure
and
I'm
happy
to
give
you
the
I'm
happy
to
give
you
the
update.
You
know
offline
at
your
convenience
about
what
we
what
the
decisions
were
in
sig
network.
I
have
all
the
context.
Awesome.
B
Great
besides
those
two
is
there
anything
on
top
of
mind
that
we
should
be
thinking
about
to
include
in
our
beta
to
ga
graduation
for
mcs
api,
specifically
as
a
reminder,
the
current
ones
are
scalability
performance,
testing,
understanding
impact
on
cluster
local
service
scalability
and
cluster
id
defined,
with
at
least
one
other
multi-cluster
use.
C
Case,
I'm
just
trying
to
think
about
what
other
changes
were
happening
in
c
network.
There
are
some
changes
around
terminating
endpoints
that
we
should
at
least
look
at.
B
C
B
Stuff:
okay,
if
anybody
else
has
something
but
between
you
know
outside
of
this
meeting,
feel
free
to
ping
me
on
slack
or
anything
too
or
comment
somewhere,
and
I
will
route
it
to
everybody
else.
B
Show
the
rest
of
the
update
two
items
that
I
think
are
basically
ready
to
work
on
either
soon
or
now.
There's
one
about
e
to
e
test
exist
for
mcs
services.
There's
a
little
bit,
there's
a
sort
of
dis
disjoint
between
what
is
referred
to
in
the
kep
as
things
that
we
should
cover
and
what
is
actually
covered
right
now.
So
there's
some
more
work
that
could
go
on
there
and
then
I
don't
think
we're
it's
connected.
I
don't
even
know
the
process
by
which
to
connect
it
to
running
on
ci.
B
So
maybe
we
need
to
do
that
step
at
some
point
too,
and
then
there's
also
a
point
that
there's
at
least
one
mcs
dns
implementation.
So
the
dns
multicluster
dns
proposal,
as
mentioned
on
the
first
like
complete
on
track
items,
is
almost
done
and
will
be
updated
in
the
mcs
api
readme
itself.
I
think
the
plan
is
to
implement
it
in
core
dns
and
if
people
have
interest
in
working
on
that
at
some
point,
that
will
be
ready
to
work
on
soon
so
put
it
on
your
radar.
B
And
then
this
was
something
that
jeremy
brought
up
and
he
didn't
want
to
miss
it.
If
we
had
a
long
discussion
about
it,
so
I'm
just
gonna
open
the
point,
and
then
we
can
talk
about
it
more
next
time
too,
but
there
are
two
items
in
the
beta
blockers
that
say:
q
proxy
can
consume
service,
import
and
endpoint
slice
and
implementation
strategy
defined
and
approved,
and
for
cube
proxy
can
consume
service,
import,
endpoint
slice.
B
There's
a
thinking,
emoji
question
here
about
whether
we
agree
that
whether
this
should
still
be
included
or
is
this
an
implementation
detail,
not
something
that
we
actually
require
as
a
specification
of
like
this
is
what
makes
the
mcs
api
done.
For
example,
right
now
we
have
implementations
that
use
dummy
services
to
get
cube
proxy
to
interact
with
things,
and
one
pro
is
that
if
we
don't
make
this
an
explicit
point
of
the
specification,
then
there's
no
restriction
on
cluster
version
for
that
being
compliant
with
the
fully
specified
mcs
api.
B
So
I
understand
this
point:
implementation
strategy
to
be
directly
related
to
figuring
out
how
to
interface
with
q
proxy.
So
there's
basically
an
open
point
here
of,
should
we
like
remove
these,
so
I
am
interested
in
taking
a
temperature,
but
if
we
have
a
long-standing
discussion,
then
I
want
to
make
sure
jeremy
can
be
included
too.
B
Okay
cool-
I
saw
some
nodding,
so
that
seems
positive,
but
maybe
it
was
just
understanding
nodding.
So
we
can
table
this
one
for
now,
but
think
about
this
between
now
and
next
time
and
then
we'll
get
jeremy
in
here
too.
So
we
can
all
discuss.
But
this
is
the
you
know,
kind
of
proposal
here
about
these
two
items
and
yeah
there's
a
random
smaller
thing
that
I
read
that
we
could
change
them
some
pros,
but
other
than
that.
I
think
we're
clean.
B
Cool,
so
that
is
the
update.
I
will
see
the
floor
unless
there
are
any.
A
B
Questions
I
have
plenty
of
action
items
to
take
and
then
I
will
come
back
with
another
update
to
the
update
next.