►
From YouTube: Kubernetes SIG Multicluster Sep 20 2022
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
A
I
guess
you
went
on
a
vacation
hope
you
had
a
good
vacation
thanks.
I
was
like
two
three
weeks
ago:
yeah
just
just
a
break
from
the
hassle
of
everyday
work:
nice,
nice,
hey,
Hong,
Kong,.
A
A
B
Yeah
I
can't
see
yeah
yeah,
yeah
video.
It.
D
E
Yeah,
that's
it's
a
little
warm
for
me
to
be
honest,
yeah.
C
A
A
C
Why
don't
we
go
ahead
and
get
started
so
we
have
two
agenda
items
today.
The
first
one
is
follow
up
on
the
discussion
about
archiving
Cube,
fed
the
the
the
responses
to
the
threads
that
we
had
on
the
mailing
list
around
archiving
this
project
we're
basically
universally
supported.
C
C
That
is
an
action
item
for
Jeremy
and
I
to
do
after
this
meeting,
certainly
before
our
next
meeting,
but
we
wanted
to
give
a
thank
you
to
everybody
that
took
part
in
that
discussion.
Thank
you
to
everybody
that
helped
to
develop
cute,
fed
and
reiterate
with
books
that
archival
is
not
deletion.
C
If
anyone
is
currently
using
Cube
bed,
the
source
code
isn't
going
anywhere,
it
can
be
forked
you
can,
you
can
do
whatever
you
want
with
it.
So
I
think
the
the
one
thing
that
pardon
me
I
need
a
drink
of
water,
One.
A
C
All
right
that
was
quite
the
operation,
because
I'm
wearing
a
mask
but
I'm
all
hydrated,
now
so
I'm
good.
The
the
one
thing
that
we
wanted
to
give
some
treatment
to
is
that
there
was
one
of
the
themes
in
the
discussion
that
we
had
is
to
provide
guidance
for
folks
and
send
them
to
other
projects
that
are
in
the
same
functional
area,
I
think
between
Jeremy
and
I.
We,
we
are
a
little
concerned
about
providing
guidance.
C
That
appears
to
be
a
recommendation
from
the
Sig
that
we
don't
want
that
material
to
rot.
There
are
a
lot
of
old
materials
on
the
internet,
dealing
with
kubernetes
Federation
that
have
rotted
that
you
know
we
don't
want
to
add
to
the
noise
there.
C
So
what
we
were
thinking
of
doing
is
to
have
a
mailing
list
thread,
as
we'll
have
for
the
announcement
where
people
can
put
their
own
pointers
on
there
to
other
projects
that
are
in
that
functional
area
and
that
will
have
a
tombstone
commit,
as
the
last
commit
to
cube
fed
before
it
gets
archived
that
references
that
mailing
list
discussion.
So
they
have
maybe
more
of
a
living
document.
In
the
sense
of
we'll
have
this
thread
that
we
can
keep
having
discussion
on
on
provide
updates
to,
but
we
also
get
the
advantage
of.
C
We
don't
potentially
give
people
confusing
advice
that
may
rot
over
time.
That
appears
to
be
from
the
city.
I.
Think
that's
eof
for
me.
Jeremy,
do
you
want
to
say
anything
on
top
of
what
I've
said,
yeah.
E
I
think
I
think
you
you
kind
of
covered
all
of
it,
but
yeah.
The
the
real
thing
here
I
think,
is
that
we
just
don't
have
a
Sig
sponsored
replacement
for
cube,
fed
and
that's
okay.
We
we
also
want
people
to
be
able
to
discover
those
those
replacement
projects,
but
you
know
they'll
change,
there's
there's
many
of
them.
We
don't
necessarily
have
a
favorite.
So
this
is
a
you
know.
Paul
and
I
were
thinking.
E
This
just
makes
a
good
way
to
make
sure
that
they're
all
discoverable
without
kind
of
sending
the
wrong
message
about.
You
know
Sig's
dance
or
basically
like
our
understanding
of
these
projects.
But
really
you
know
I
want
to
thank
everyone.
Who's
contributed
to
cube
fed,
you
know,
has
helped
a
lot
of
people
it
clearly
it's
still
in
use
and
the
code's
not
going
anywhere.
So
this
isn't
a
statement
on
cubefed
as
a
whole.
E
It's
mostly
just
to
set
expectations
to
the
community
about
like
what
level
of
support
and
future
development
can
be
expected,
but
yeah
by
all
means,
if
you're,
if
you're
using
Cube
fed
keep
using,
keep
fed.
You
know
forkid
do
as
you
wish
with
it
like
it's
the
communities
project
and
it's
it's
not
going
anywhere.
C
Okay,
I,
don't
think
that
came
as
a
surprise
to
anybody.
I
don't
see
any
raised
hands.
So
why
don't
we
proceed
on
to
the
next
agenda
item
and
I?
Believe
that's
Peter,
Sherman
I
hope.
That's
a
acceptable
pronunciation
of
your
last
name
here,
hello.
B
B
And
I
I
see
I
think
we
I.
We
have
two
sincere
cncf
projects
now
and
one
of
them
you
might
know
kamada.
It's
increase,
increase
a
lot
of
the
concepts
from
the
group
fight,
as
mentioned
by
by
Jimmy
at
the
mail
group
and
his
side.
Camera
is
a
native
successor
of
a
cool
fight.
Should
we.
B
Yeah
so
the
way
I
had
some.
C
So
that
is
that's
a
great
question.
Let's
talk
about
what
that
looks
like
so
what
what
I
think
our
plan
is
currently
is
that
we
will
have
a
final
commit
that
goes
into
Cube,
fed
before
it's
archived
that
has
a
link
to
the
announcement
of
the
archival.
C
So
what
I'll
ask
you
to
do
is
when
that
announcement
goes
out
to
reply
with
the
information
that
you'd
want
people
to
have
about
karmata
and
any
other
project
that
you
felt
was
relevant,
and
that
will
be
the
way
that
we
let
people
discover
those
other
projects
so,
for
example,
I'd
rather
do
that
than
to
mention
any
project
explicitly
in
the
cube
pad
readme,
because
you
know
if,
if
the
passage
of
time
brings
things
like,
maybe
someone
gets
a
better
idea
that
and
makes
like
karmada
V2
or
something
that
we
don't
have
a
rotten
link,
that's
in
an
archive
project,
so
the
the
advantage
of
pointing
to
that
mailing
list
thread
is
that
we
can
update
and
say:
oh
hey,
there's
this
new
project
that,
if
you
like,
all
all
of
these
other
projects,
you're
really
going
to
love.
C
B
Yeah
there
will
be
a
announcement
mail
right.
Yes,
okay,
yeah.
C
Okay,
all
right,
sorry,
for
that
false
start.
Peter.
You
can
have
the
floor.
Peters
here
to
talk
to
us
about
stateful,
set
migrations
across
clusters.
It's
cap
3335!
If
I'm,
not
mistaken,
that's
right!
Go
ahead!
Peter.
Would
you
like
me
to
enable
screen
sharing
for
you.
D
I,
just
posted
a
link
to
the
cap
in
the
chat
and
I
think
we
could
just
talk
through
it.
There's
this
weird
bug
that
I've
got
in
the
past,
where
I
can't
talk
if
I'm
presenting
so.
C
Okay,
well,
that's
important,
so
check
check
the
chat.
If
you
want
to
see
the
link
go
ahead,
Peter.
D
Cool
yeah,
so
I'm
just
here
to
discuss
this
cap
and
bring
it
to
the
seg
leads,
and
our
our
goal
here
is
to
see
if
we
can
get
this
as
an
alpha
feature
in
126.,
so
high
level
asking
for
lead
opt-in
to
pursue
an
alpha
feature.
D
Some
of
you
may
have
seen
the
demo
that
Alexis
and
I
presented
back
in
July
for
sigma's
cluster,
which
was
using
this
cap
as
a
building
block
to
allow
a
staple
set
to
be
migrated
across
clusters,
and
so
we're
looking
for
Sig
multi-cluster
to
sponsor
this.
Even
though
some
of
the
code
most
of
the
code
is
in
Sig
apps
domain,.
A
D
C
The
you
mentioned
that
there's
that
there's
overlap
functionally
with
like
code
that
Sig
apps
currently
maintains.
Have
you
have
you
had
any
discussions
with
them
and
like
what?
What
kind
of
receptivity
have
you
gotten
on
the
idea
of
the
cap
from
Sig
apps.
D
Yes,
we
brought
this
to
six
apps
I,
think
it
it
was
in
June.
We
had
a
discussion
with
them.
Their
General
feedback
was
these
changes.
Don't
seem
that
controversial?
They
seem
rather
like
simple
in
terms
of
API
change.
D
D
I
think
their
main
feedback
was
regarding
the
use
of
this
cap
feature
in
isolation,
and
that's
where
the
same
multi-cluster
story
becomes
much
more
relevant.
This
kept
by
itself,
you
know
in
an
isolated
in
a
single
cluster
is
not
as
interesting
with
it.
There
is
this
use
case
of
migrating
across
namespaces,
which
is
captured
in
the
cap,
but
I
think
that
the
multi-cluster
story
is
much
more
compelling
in
terms
of
allowing
a
user
to
move
a
sample
set,
be
more
flexible
support,
multi-cloud.
C
And
you
were
looking,
your
goal
was
to
have
this
feature
at
Alpha
in
the
next
KK
release.
Is
that
right.
D
D
Is
pretty
pretty
soon,
so
that's
why
we're
discussing
it.
Yeah.
C
C
So
one
thing
that
I
want
to
personally
make
sure
of
is
that
we
don't
fail
to
observe
some
necessary
form
or
Community
Norm,
because
I
haven't
done
that
before
Jeremy
I,
don't
I,
don't
know
if
you
were
familiar
with
that
like
in
in
the
early
lifetime
of
six
I
was
very
active
in
a
number
of
other
cigs,
but
it's
been
quite
a
while.
So
what
I?
C
What
I'd
want
to
do
is
make
sure
that
I
personally
understood
everything
that
you
need
to
do
to
be
a
good
Community,
member
and
citizen
there,
but
like
I
it.
It
sounds
great
that
you've
already
spoken
with
Sig
apps
and
that
you've
got
buy-in
already
on
that
idea.
That
is
basically
my
my
only
reservation,
which
is
not
something
that
is
a
reason
not
to
do
things.
C
It's
just
a
reason
to
proceed
carefully,
knowing
that
you're
very
interested
in
getting
this
in
for
the
next
kubernetes
kubernetes
release,
Jeremy
I,
don't
know
if
you
have
any
thoughts.
You
want
to
add
around
that,
but
that's.
A
C
The
the
danger
for
me
is
like
unwittingly
doing
something
that
gives
you
a
false
start
or
you
know
like
pushes
you
to
the
next
release,
because
we
didn't
check
the
right
box
on
the
right
form
or
something
government.
E
My
understanding
so
from
what
I'm
getting
from
you
Peter,
please
correct
me,
is
basically
Sig.
Apps
is
kind
of
supportive
of
this
change,
but
they're
looking
for
they're
looking
for
a
strong
use
case,
and
basically
our
role
here
wouldn't
be
so
much
driving
this
change
in
Sega
apps,
because
that
would
still
be
on
six
apps.
It
would
be
to
basically
say
we
have
a.
We
have
a
real
Community
focused
use
case
for
this
feature
that
we
want
to
develop.
E
That
depends
on
this,
and
so
that
would
be
basically
us
saying
that
this
you
know
this
demo
that
we
saw
back
in
July
of
the
Staples
at
migration
is
something
that
Sig
multi-cluster
thinks
is
important
and
we
want
to
develop,
which
you
know
from
my
perspective,
I
feel
very
comfortable,
saying,
like
I
think
this
is
an
important
use
case
for
for
kubernetes
users
who
have
multiple
clusters.
We
started
addressing
this
with
multi-cluster
services,
but
that
very
much
focused
on,
and
we
even
said
at
the
time.
E
This
very
much
focuses
on
stateless
and
now
we're
introducing
stateful
to
the
story.
I
think
that
makes
sense.
We
depend
on
this
and
it's
basically
us
just
saying
here:
we
have
a
real
use
case,
so
say
gaps.
You
can
feel
good
about
this.
It's
not
just
some
feature
we're
putting
in
so
somebody
can
go
off
and
do
something
in
the
shadows
right,
that's
kind
of
that's.
My
interpretation
Peter.
Is
that
correct.
D
Yeah,
that's
correct,
so
I
think
yeah.
What
the
main
thing
like
requests
we're
asking
for
is
the
yeah
the
support
for
this
use
case
and
kind
of
the
you
know
if
we
do
get
any
pushback
from
cigaps
regarding,
like
you
know
this
feature
in
isolation
or
this
feature
not
being
extensible
or
something
like
having
sigmology
cluster
or
back
us
up
in
terms
of
like
the
the
larger
benefit
to
the
kubernetes
ecosystem.
E
Okay,
yeah,
that
makes
sense
to
me
this
sounds
different
than
like
last
time.
Paul
we
went
through
this
was
when
we
were
originally
thinking
about,
like
changing
Cube
proxy
with
MCs
yeah.
That
was,
there
was
more
pushback,
but
that
was
to
me
very
different.
That
was
us
actually
being
the
drivers
of
the
change
versus
just
like
piling
on
basically
as
use
cases
yeah.
E
Exactly
we
can
do
that,
that's
much
easier
stance
than
than
being
the
drivers,
and
you
know
I
feel
pretty
good
about
it.
I'm
excited
about
this.
This
kind
of
change,
I,
think
Paula.
You
and
I
have
been
discussing
for
a
while
about
like
next
big
initiatives
for
the
siggins,
yeah
and
stateful
was
definitely
on
that
list.
F
Just
I
wanted
to
go
ahead
to
pop
in
yeah
sorry
yeah
Act,
Your
Hand.
Yes,
thank
you.
I
just
wanted
to
pop
in
I
think
this
is
sort
of
circling
more
around,
like
Sig
apps
being
like
sponsoring
sick
from
the
perspective
of
the
release
process
and
release
cycle,
but
if
it
was
still
on
the
table
or
desired
for
it
to
be
Sig
multi-cluster
just
wanted
to
like
comment
some
on
what
Paul
you
were
saying.
F
I
have
some
experience
in
this
just
having
been
on
the
release
team
a
couple
times
of
what
the
obligations
are
of
the
Sig
regarding
like
submitting
for
the
enhancement
freeze,
making
being
kind
of
like
the
point
person
to
make
sure
that
the
code
freeze,
docs,
freeze
any
of
the
like
testing
issues
and
like
the,
where
is
it
prr
process
is
followed.
F
This
is
all
those
are
also
kind
of
shared
load
with,
like
the
release
team,
the
sub
teams
that
are
in
charge
of
each
of
those
individual
pieces
of
the
process,
but
as
like
the
Sig,
the
sponsoring
Sig,
then
there
are
there's
also
kind
of
like
a
shared
burden
of
that
I'm
here
too
so
yeah.
F
But
that's
kind
of
like
a
little
gist
of
like
some
of
the
concrete
things
that
I
think
we
would
be
obligated
to
help
with
if,
for
any
reason,
it
is
decided
or
desired
for
signal
multi-cluster
to
be
the
Like
official.
You
know
stamped
on
the
the
thing
folks
and
happy
to
share
more
of
my
experience
about
that
at
City
control
event.
A
D
Yeah
thanks
Laura,
yes,
I,
guess
what
I'm
hearing
is
you
know,
I
did
change
the
cup
over
to
be
under
sigmology
cluster,
so
I'm
kind
of
wondering
like
what
do
the
mechanics
look
like
you
know
is
is
like.
D
C
I
I
think
what
matters
the
most
to
me
personally
is
not
necessarily
which
Sig
is
indicated
on
here,
but
like
making
sure
that
someone,
authoritative
from
Sig
apps,
puts
a
comment
on
to
this
pull
request
for
the
cap,
making
sure
that
it's
clear
that
they've
seen
it
and
that
they're
supportive
of
it.
That
would
that
would
what's
my
gut
feeling
is
I,
don't
know
about
Jeremy
or
Aurora.
What.
A
E
And
the
owning
Sig
matters
as
much
as
the
fact
that
the
right
people
are
actually
looking
at
it
and
you
know
I
I
know
you've
tagged
the
correct
participating
sigs.
Let's
just
make
sure
that
we
have
representatives
from
those
sigs
as
approvers.
E
F
Yes
and
I
think
you
know,
I
mean
I'm
sure
variations
exist,
but
being
under
the
Sig.
Multi-Cluster
caps
implies
that
the
Sig
multi-cluster
chairs
will
be
the
ones
who
do
like
the
opt-in
for
enhancements.
Freeze
that
Peter
is
talking
about
so
I
think
that
step.
We
should
make
sure
we
know
who's
doing
that,
but
yeah
I
think
it's
for
since
it
since
anything
in
Signal
type
clusters.
F
Ultimately
Crossing
like
I've,
experienced
this
even
with
outside
of
krk
caps
here,
but
yeah
I
think
a
lot
of
transparency
in
this
group
and
on
the
pr
and
in
like
that
approvers
and
reviewers
Matrix
in
the
kept.yaml
of
like
who
actually
needs
to
sign
off
on
this
and
getting
attention
on
that
early
is
like
the
thing
that's
going
to
prevent
this
from
getting
like
gunked
up
and
then
yeah
I
think
it's
Jeremy
and
Paul
slash
I'm,
also
happy
to
help
into
is
cool
with
aligning
with
the
release
cycle
of
this
round
and
I'm
opting
this
into
the
enhancement
freeze
this
time,
then
we
can
totally
do
that.
D
D
Me,
you
know
getting
getting
opt-in
from
Sigma
multicluster
leads
and
then
you
know
we'll
work
on
driving
with
support
into
gaps
and
getting
visibility
from
this
folks.
E
Awesome
I
guess,
since
your
timeline
is
relatively
short,
I
will
volunteer
to
be
someone.
You
can
Badger
to
make
a
progress
and
get
things
done.
C
Do
we
know
what
the
does
anybody
happen
to
know
off
the
top
of
their
head?
What
the
actual
timeline
is
for,
having
this
enhancement
accepted
for
the
release.
E
Exciting,
it's
really
awesome
to
see
some
progress
in
this
area.
Yeah
I
can't
wait.
Let's
hope
we
can.
We
can
get
it.
C
Seems
like
we're
talked
through
for
now,
everybody
have
a
great
rest
of
your
Tuesday
and
Peter
and
I
think
it
was.
Was
it
Alexis?
We
can
reach
out
to
you
about
next
steps
on
tep,
3335.