►
From YouTube: Kubernetes SIG Multicluster 2021 Mar 30
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
A
Okay,
this
might
be
who
we
get
for
now.
A
Okay,
this
one
records
automatically
all
right:
welcome
everybody
to
tuesday
march
30th,
2021
meeting
of
kubernetes
multi-cluster,
laura,
I
think,
you're
dominant
on
the
agenda
today.
Why
don't
you
take
it
away?
Aha,
thank
you.
B
C
B
Here
we
are
all
right,
so
I'm
looking
at
the
agenda
so
a
couple
updates
of
the
various
projects
I
am
working
on
so
for
cluster
id.
I
went
to
sig
architecture
last
thursday
to
talk
about
the
crd
to
crd
or
not
to
crd
conversation.
So
we
had
a
very
good
conversation
there's
if
you're
part
of
the
sig
architecture
which
I'm
not
on
this
account,
google
group,
you
can
read
the
notes
and
the
agenda.
B
So
in
one
of
these
open
an
editor
there
we
go
and
in
the
speaker,
notes
down
here,
there's
a
bunch
of
notes
of
what
we
talked
about
there
as
well,
but
tldr
we're
gonna
proceed
with
the
sigs
repo
crd.
If
you
recall
from
before,
we
were
kind
of
like.
Should
we
put
this
in
core
kubernetes
or
what
should
we
do,
and
that
was
the
discussion
conclusion
from
sig
architecture
and
in
particular,
there's
some
work
going
on
to
provide
a
way
to
bootstrap
crds
on
cluster
start.
B
So
that
sounds
potentially
interesting
to
us
as
a
lot
of
our
kind
of
waffling
from
a
like
implementation
perspective
on
this
was
that
crds
were
difficult
to
kind
of
like
make
built-in
or
ubiquitous.
So
this
is
kind
of
a
project
working
towards
making
that
possible
in
the
future,
so
I'll
be
following
along
on
that,
but
this
unblocks
us
for
our
purposes
now
on
cluster
id,
so
was
talking
to
paul
a
little
bit
about
the
pull
request
earlier
today.
B
Particularly
one
of
the
contentious
points
that
we
had
discussed
two
weeks
ago
was
whether
or
not
to
include
serve
records,
so
they're
kind
of
the
arbiters
for
that
we
had
identified
at
that
meeting
as
well,
so
I'm
going
to
actually
talk
to
them
about
it.
I
will
say:
I've
been
talking
to
some
people
individually
and
people
have
been
on
the
side
of
including
them
to
keep
parity
with
the
existing
specs.
B
So
you
can
take
a
look
at
this
there's
a
bunch
of
words
about
some
of
the
rationale
that
we
had
discussed
for
various
things
too
so
definitely
feel
free
to
give
it
a
look,
and
let
me
know
if
my
prose
is
representing
our
conversations
properly,
but
this
is
where
I
think
conversation
about
multi-cluster
dns
should
happen
going
forward
on
this
pull
request
and
yeah.
Those
are
all
the
updates
happy
to
take
any
questions
or
talk
about
anything
else,
but
just
wanted
to
make
sure
everybody
knew
what
was
going
on.
A
A
Decisions
to
make-
I
don't
know,
I
don't
know
that
we
necessarily
want
to
like
take
up
a
lot
of
time
in
this
meeting,
but
I
think
we
can.
We
we've
definitely
got
like
five
or
ten
minutes
that
we
can
spend
on
workshopping
stuff
with
yeah
the,
like
conclusion
being
provided
by
like
a
survey.
I
think
that's
worked
out
well
for
us,
but
I
don't
know
what
what
do
people
think
about
that.
B
Yeah
and
first
I
for
some
notes-
we
did
talk
about
this
a
little
bit
in
the
past.
I
guess
20
days
ago,
these
were
some
potential
contenders.
B
If
I
recall
the
the
strongest
like
point
that
was
made
about
this
was
to
maybe
keep
make
sure
the
word
cluster
was
in
there
somewhere
to
to
make
it
feel
like
it's
about
clusters.
B
Obviously,
the
kind
also
has
like
the
resource
has
the
name
cluster
property
too,
so
maybe
that
is
sufficient
as
well
so
yeah.
I
just
wanted
to
bring
that
up.
These
were
some
that
were
talked
about
before,
but
does
anybody
feel
like
really
good
or
bad
about
any
of
these
api
group
names
or
something
else.
D
Do
we
anticipate
other
non-cluster
properties
coming
along?
I
mean,
if
cluster's
already
in
the
name
of
the
resource
itself,
then
you
know
having
it
in
the
name
of
the
api
group
is
a
little
redundant
and
if
we
expect
this
to
expand
to
other
type
properties,
then
using
something
like
properties
only
would
be
helpful
to
give
other
people
a
launching
point.
B
Yeah,
I
think,
since
the
schema
for
a
cluster
property
is
like
very
open
by
design,
I
think
we
think
a
lot
of
things
that
people
might
come
with
up
with
in
the
future,
we'll
stick
with
the
cluster
property
resource.
B
B
To
what
is
the
word
that
I'm
looking
for.
B
Signatures,
yes,
thank
you.
We
had
talked
about
signatures
at
one
point
so
that
a
cluster
property
could
have
some
other
metadata
associated
with
it
somehow,
either
as
another
cluster
property
resource,
with
a
different
name
or
as
a
different
kind
altogether.
But
I
think
you
know
I've
only
had
a
few
like
sort
of
back
channel
conversations
about
that
and
we
think
the
cluster
property
schema
is
probably
good
enough
for
that.
So
there
wouldn't
be
another
kind,
but
I
can't
like
totally
rule
it
out.
You
know.
C
A
C
C
I
was
just
gonna
say
I
don't
know
if
it
like.
I,
I
don't
see
another
kind
right
now,
but
I
don't
you
know
I.
I
don't
think
we
can
say
yet
that
there
won't
be
one
I
do
think
like
properties.kates.ios
seems
pretty.
You
know
open
and.
B
C
But
but
also
fits
fits,
what
we
need
clusterproperties.clusterproperties.cast.io
seems
pretty
redundant
and-
and
I
don't
think
we
should
go
with
id.k.o,
because
I
think
we've
kind
of
already
seen
cases
where,
like
yes,
our
primary
use
is,
is
cluster
id
and
and
cluster
set
id.
But
you
know:
we've
we've
kind
of
left
it
open
for
other
kinds
of
properties
as
well.
So
I
wouldn't
want
to
say
that
it
has
to
be
identification.
A
That's
my
two
cents.
I
gotta
say
it
is
my
own
suggestion.
So
of
course
I
like
it,
but
how
does?
How
does
this
sound
to
you
all.
D
B
I
like
it,
like,
I
think,
it's
cute
without
being
too
cute,
and
then
we
don't
have
like
properties,
properties
properties
like
back
to
back
to
back.
So
you
know
that's
a
nice
flavor
part,
but
what
I'm
hearing
is
that
we
should
vote
right.
A
I
think
I
like,
I
honestly
think
it
would
be
good
to
have
like
I'd
love
to
know
any
any
other
sources
of
or
any
other
ideas.
A
I
don't
really
want
to
like
introduce
another
time
delay
but,
like
you
know,
they're
easier
to
just
feel
like
you
made
a
good
choice,
one
time
than
to
try
to
rename
I
don't
know.
What's
what
are
people's
appetites
for
soliciting
names
on
the
list
for
the
group.
C
I
I
think
we
really
should
just
so.
We
know
if
we've
kind
of
done
it.
I
think
we
should
share
the
ones
that
we're
thinking
about
and
just
see.
If
anyone
wants
to
chime
in
with
additional
ideas,
and
then
you
know
we
could
decide
if
we
want
to
go
with
like
a
an
actual
survey
or
if
we
just
want
to
pick
out
of
what
comes
back.
C
D
C
I
I
think
that
would
be
a
good
way
to
finish
it
honestly.
If
we
don't
want
to
like
go
with
the
full
survey
for
this,
when
we
once
maybe
first
we
send
out,
we
say
hey
if
you
have
any
other
ideas,
let
us
know,
but
this
is
kind
of
what
we're
thinking
and
then
and
then,
after
that,
we
could
do
like
a
lazy
consensus.
Just
you
know,
blast
out
that
we're
gonna
go
with
about
and
and
unless
anybody
objects
strongly
in
the
next
week,
we'll
we'll
call
it
kid.
A
A
C
Yeah,
so
this
will
be
super
short,
but
I've
posted
a
draft
of
the
annual
report.
As
paul
said,
if
anyone
wants
to
take
a
look,
I
think
there's
a
couple.
Questions
still
open
that
we
need
to
fill
in
around
kind
of
metrics
and
contributions
that
I
still
need
to
pull,
but
take
a
look
comment
on
the
pr.
If
you
have
any
feedback
once
I
fill
out
the
rest
today
or
tomorrow,
I'll
send
this
out
to
the
to
the
list
as
well,
but
yeah
annual
bookkeeping.
C
A
What
were
the
highlights?
Did
you
feel.
C
Well,
lots
of
lots
of
good
changes.
I
think
you
know
cube
fed's
still
going
strong.
C
Work,
api,
mcs
and
cluster
id
are
all
you
know,
relatively
new
in
various
stages
and
and
chugging
along,
which
is
great.
You
know
the
overall
highlight
to
me,
I
think,
is
more
consistent
contribution
and
participation
than
we've
seen
in
a
long
time
over
the
last
year.
It's
it's
pretty
awesome
and
you
know
it
was
last
year
right
that
we
moved
to
weekly
meetings
instead
of
instead
of
bi-weekly
and
we've
had
like
a
pretty
decent
agenda.
It
seems
every
week
it's
really
really
cool
to
see.
A
Yeah,
I
think
I
think,
that's
very
close
to
my
own
feeling
as
well.
Thanks
for
writing
that
up,
I
appreciate
it.
C
Yeah
no
prob
and
anyone
who
who
wants
to
weigh
in
it's
it's
open.
You
know
I've
I've,
I've
gotten
it
started,
but
everyone's
feedback
is
welcome.
B
I
think,
besides
the
metrics
point,
which
seems
kind
of
like
a
hard
data
thing,
a
lot
of
the
open
questions
are
about
like
contra,
contributor,
onboarding
and
and
like
contributor,
outreach
and
stuff,
and
maybe
this
is
getting
ahead
of
ourselves,
because
I
know
you
all
just
said
that
there's
been
a
good
trajectory
since,
like
it
being
pretty
quiet
before,
but
is
there
any
like
plans
for
that
that
have
been
discussed
or
like
hanging
out
in
your
brain
that
should
be
represented
either
on
this
annual
report,
or
just
like
generally
known
to
the
group.
C
I
think
the
you
know
the
the
honest
answer
is
we
probably
just
need
to
do
a
better
job
there
in
terms
of
you
know,
reaching
out
to
get
more
people
on
board?
I
know
I've
had
a
few
conversations
with
some
other
groups.
I
was
telling
paul
earlier
today
that
you
know
some
istio
folks
will
probably
drop
by,
because
they've
got
some
questions
about
some
new
use
cases
around.
C
How
we
could
maybe
do
leader
election
in
multi-cluster,
which
sounds
like
a
pretty
interesting
problem,
but
I
don't
know
that
we
have
a
good,
you
know
blast
except
for
kubecon,
to
get
people
involved,
and
I
think
you
know
we've
seen
in
the
past
after
kubecons
we
see
some
uptick,
but
we
could
probably
do
more
outreach
and
I'll
I'll.
Add
that
full
statement
to
the
report
as
well.
A
Yeah,
I
think
I
I
think,
like
the
progress
that
we've
made
in
the
last
year,
is
setting
us
up
for
more
people
to
have
a
feeling
like
they
have
a
stake
in
what
happens
in
sigmulti
clusters.
So
you
know
there's
I
I
feel
very
happy
about
like
what
I
think
can
happen
in
the
next
12
months.
A
But
definitely
kubecon
is
a
good
good
place
to
broadcast
stuff
yeah.
C
C
B
Just
I
was
gonna
say
like
this
is
kind
of
top
of
mind
to
me
because,
like
I
go,
hang
around
with
a
lot
of
other
cigs
these
days
to
say
like
hey,
it's
sick,
multi-cluster
what's
up,
and
I
definitely
don't
have
any
like
call
to
action.
Usually
that's
like
hang
out
with
us
and
I'm
not
sure
that
that's
the
greatest
forum
in
the
the
like,
you
know,
agenda
item
that
I
usually
am
taking
along,
which
is
to
get
feedback
on
something
we're
working
on
internally.
But
I
think
to
like
paul's
point
like.
C
Yeah
and
I
think
we're
seeing
what
we
kind
of
hoped
would
happen
is
now
now.
We've
got
some
some
new
projects
that
people
are
poking
around
with
and
we're
seeing
some
additional
use
cases
kind
of
naturally
develop
around
the
problems
that
you
face.
C
Now
that
you've
got
you
know,
you're
figuring
out
how
to
deploy
workload
across
clusters
or
your
you
know,
consuming
services
across
clusters
now,
there's
there's
all
kinds
of
other
problems
like
leader
election
that
show
up
when
you
start
doing
that-
and
you
know
hopefully
that'll
kind
of
lead
into
a
nice
explosion
of
life
for
us
and
and
new
new
problems
to
solve.
A
Absolutely
well,
it
sounds
like
we're
through
the
agenda
today.
A
Okay:
well
thanks
for
the
write-up
and
thanks
for
the
the
readout,
laura
and
jeremy,
and
we
will
see
you
all
together
next
time.