►
From YouTube: Kubernetes SIG Multicluster 2020 Oct 20
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).
C
D
Sure
yeah,
so
today
I
really
kind
of
wanted
to
revisit
a
cluster
id
an
older
proposal
from
last
year
that
some
of
you
probably
remember
that
basically
wants
to
introduce
some
kind
of
formalized
concept
of
how
we
how
we
identify
clusters.
D
So
let
me
share
shortly
here,
I'm
just
kind
of
thinking
back
over
the
conversations
that
we
had
about
cluster
set
use
cases
and
what
our
registry
could
look
like
kind
of
the
one
consistent
thing
that
that
came
out
of
that
was
that
we
really
need
a
way
to
identify
clusters
and
we
need
to
sort
out
what
what
that
actually
entails.
D
All
right
so
yeah
this.
This
is
a
bit
over
a
year
old
now,
but
I
think
we've
learned
a
lot
about
what
a
cluster
id
and
and
what
a
cluster
identity
actually
means.
Since
then,
I
don't
know
tim.
I
see
a
lot
of
you
here
paul
who
else
here
was
actually
involved
in
those
early
discussions.
C
I
I
think
I
thought
you
were
asking
for
people
that
weren't
me.
D
D
If,
if
nobody
else
here,
then
I
think
it
would
be
really
good
to
have
your
insight,
as
we
kind
of
talk
about
how
I
see
this,
because
there
are
a
lot
of
really
good
conversations
in
here
and
the
kind
of
the
key
points
that
that
pop
out
for
me
in
the
original
discussion
were
basically
the
concept
of
some
machine
generated
automatically
generated
uid
for
each
cluster.
D
C
So
go
ahead,
paul
I
was
just
going
to
say,
jeremy.
I
I
think
maybe
I
maybe
read
something
into
the
description
of
the
agenda
item
and
I
I
just
want
to
check
my
assumption,
which
is
that
I,
what
I
expected
is
that
you
would
maybe
be
like
through
this
conversation
walking
us
up
to
how
would
we
reference
like
using
the
cluster
id
as
a
coordinate
in
some
other
apis?
Is
that
is
that,
where
we're
going.
D
Yes,
yeah
or
what
that
actually
needs,
because
we're
kind
of
talking
about
the
registry
as
an
api
and
and
we
started
get-
we
got
a
little
deep,
I
think
into
use
cases
for
a
registry
and
it
and
and
a
bunch
of
different
use
cases
came
up
and
they
all
had
different
needs
and
a
cluster
id
is
kind
of
the
the
ones
central
thing
that
all
of
those
different
use
cases
had
in
common.
C
Yeah
and-
and
that
makes
sense-
and
I
think
there's
an
aspect
that
I
read
into
that
conversation
that
I
think
is
important
to
you
too
tim,
which
is
that
we
don't
want
to
like
standardize
around
necessarily
a
certain
implementation
of
a
registry
or
a
certain,
even
like
resource
level.
Api,
as
like
one
aspect
that
I
see
present
in
that
conversation
right.
A
Yeah
so
sorry,
I
I
was
gonna
reply
to
you
earlier
jeremy,
but
I
couldn't
find
my
tab.
I
lost
you
in
all
my
tabs,
but
I
found
you
now
the
so
I
think
what
you
just
said
paul
is
exactly
right.
I
think
we
want
to
define
the
semantics,
but
not
necessarily
the
api
of
the
group,
and
the
cluster
id,
I
think,
is
an
important
part
of
the
group
and
what
we
need
to
define
here
is
given
a
given
that
I
am
in
a
cluster.
A
How
can
I
learn
something
about
this
cluster
with
respect
to
the
larger
scope,
and
I
think
maybe
where
we
went
wrong
before-
is
that
we
over
focused
on
like
the
enforcement
parts
of
this,
like?
Maybe
we
can
get
away
by
simply
defining
a
crd
here
and
giving
some
strong
recommendations
for
how
to
use
it
well
and
then
trusting
that
you
know
site
operators
are
going
to
do
the
right
thing
right,
like
we
talked,
I
remember
going
round
and
round
and
round
about
well,
should
they
be
mutable
right?
Well,
you
know
what
I
think.
A
At
the
end
of
the
day,
we
can't
actually
practically
enforce
that
they
are
never
mutated.
So,
let's
just
document
that
they
really
should
never
be
mutated,
and
if
you
meditate
it,
you
break
it
and
you
get
to
keep
both
parts
and
like
a
good
operator.
Will
heed
and
a
bad
operator
won't
and
that's
true,
no
matter
how
many
roadblocks
we
throw
in
their
way
yeah.
C
And
I
so
I
I
I
hear
where
you're
coming
from,
I
guess
another
thing
in
my
brain
is
that,
like
it's
easier
to
loosen
restrictions,
then
tighten
them.
But
I
think
it's
important
to
keep
in
mind
that,
like
we,
when
we
talk
about
starting
with
x
or
y,
that,
like
there's,
no
reason
that
that
has
to
span
like
multiple
levels
of
maturity
like
we
could
have
a
cycle
of
start
with
something
fairly
loose
and
tighten
it.
Even
while
things
are
in
alpha
as
stuff
becomes
more
clear
right.
A
Totally
totally
and
and
look
for
like
I-
I
come
at
this
with
two
hats
on
right.
Part
of
it
is
my
community
hat,
and
I
just
want
to
get
something
done
because
I
hear
people
talking
about
it,
but
also
part
of
it
is
my
managed
service
provider
hat
where,
like
I
just
want
to
be
able
to
throw
some
information
into
the
cluster
in
a
way
that
I
can
verify
that
it
was
me
who
put
it
there
in
the
first
place.
D
We
also
have
quite
a
different
landscape,
I
think
than
when
we
last
talked
about
this.
Like
last
time.
I
think
there
were
a
lot
of
questions
about,
I
think,
a
few
times
in
this
dock.
The
concept
of
scope
like
unique
for
how
long
like
immutable
for
how
long
like
what
is
the
lifespan
of
a
cluster
id,
and
we
now
have
this
concept
of
cluster
set,
which,
which
is
a
new
thing
that
that
really
like
within
a
cluster
set.
I
think
you
need
uniqueness.
D
I
think
that
seems
like
a
pretty
straight
like
I
would
like
to
be
able
to
actually
uniquely
name
each
each
cluster
within
a
cluster
set.
That's
like
a
very
tangible
thing
that
we
didn't
have
before
I
want
to
uniquely
name
every
cluster
everywhere
in
the
universe.
Is,
is
a
much
harder
thing
to
kind
of
create
guidelines
around,
but
a
cluster
set
is
a
very
concrete
boundary
for
for
a
a
cluster
id,
and
it's
also
a
lifespan
too.
D
Like
the
name
of
a
cluster,
probably
shouldn't
change,
you
know,
within
the
span
of
its
membership
within
a
within
a
cluster
set
right,
so
that
I
think
I
think
we
have
some
things
that
make
it
easier
to
talk
about
now,
and
we
also
have
some
some
new
real
requirements.
Like
you
know,
multi-cluster
services
for
headless
services
at
least
kind
of
hand
waves
at
a
at
a
cluster
id
in
the
in
the
address
for
for
pods
and
a
headless
service,
and
so
okay.
D
D
But
I
absolutely
agree
that,
like
we
can
probably
just
give
good
recommendations-
and
I
don't
know
that
we
need
to
strongly
define
anything
here
except
you
know,
it
would
be
good
to
know
that
this,
like
there
is
a
cluster
registry
or
not
a
cluster
register.
D
Sorry,
a
cluster
id
for
each
cluster
in
a
cluster
set,
and
it
has
these
characteristics,
and
I
think
that's
where
I'd
like
to
get
to
as
a
starting
point,
so
that
we
can,
you
know,
look
at
what
a
registry
would
look
like
also
so
that
we
can
unblock
one
of
the
one
of
the
beta
requirements
for
for
the
mcs
api
as
well,
which
is
kind
of
figuring
out
like
how
will
this
look
going
forward.
F
But
I
think
we,
I
think,
an
interesting
part
to
that
is
thinking
about
this
in
a
cluster
set
context
which
obviously
we're
not
designing
we're
not
supposed
to
design
cluster
id
based
on
cluster
set.
But
if
we
can
document
the
expectations
you
know
like,
for
instance,
we
can
say
cluster
set
could
say
we
expect
cluster
id
to
be
unique
and
will
reject
connection
attempts
from
two
different
endpoints
with
the
same
cluster
id.
F
But
then,
on
the
other
hand,
if
a
cluster
disappears
and
comes
back
with
the
same
cluster
id
then
based
on
the
assumption
that
the
cluster
ids
are
immutable
and
have
a
long
life
span.
If
that
is
the
case
in
a
cluster
id
spec,
then
the
cluster
set
can
assume
that
a
new
cluster
with
the
same
cluster
id
as
a
previous
cluster
nearby
is
the
same.
A
B
D
Yeah,
this
doc
has
not
been
updated
and
since
probably
mid
last
year
from
what
I
can
tell-
and
I
wanted
to
revisit
it
and
have
a
discussion
today
and
my
plan
is
to
kind
of
come
back
with
a
new,
shorter
dock
that
just
kind
of
talks
about
the
things
that
that
now
we
can
really
wrap
our
heads
around,
because
we
have
some
real
use.
Cases.
D
I
think
aliases
may
need
to
be
part
of
it.
I
think
it's
hard
not
to
mention
that
as
long
as
the
cluster
id
is
oh,
it
depends
if,
if,
if
we
take
this
high
enough
level,
then
I
don't
know
that
we
need
aliases.
D
If
you
know,
if
we
don't
make
any
statements
about
how
the
cluster
id
is
is
generated
and
just
say
that
it
has
to
be
unique
within
a
cluster
set,
for
example,
an
immutable
as
long
as
the
cluster
belongs
to
a
cluster
set,
then
aliases
seem
a
lot
less
important.
I
think
aliases
were
born
out
of
the
idea
that
they
that
the
canonical
id
should
be
a
uid
and
should
be
machine
generated,
and
so
we
need
an
alias
too,
because
nobody
wants
to
type
a
quid.
A
I
mean
I,
I
still
feel
like.
We
probably
want
some
affordance
for
aliases.
The
question
is
whether
it's
actually
literally
defining
them
as
aliases
or
simply
saying
here
are
provider-specific
metadata,
and
some
implementations
of
registry
may
choose
to
have
aliases
that
allow
them
to
evolve
over
time
and
some
may
not.
D
Right
and
I
think
like
to
me,
you
can
always
have
an
alias
for
anything
whether
or
not
it
needs
to
be
encoded
in
the
spec
comes
down
to
whether
or
not
the
characteristics
of
the
alias
are
actually
important
to
using
the
the
core
spec,
and
I
think,
in
the
original
design,
it
seems
like
an
alias,
was
pretty
important
to
have
for
a
bunch
of
use
cases
of
actually
referencing
clusters.
D
If
we
do
go
with
this
approach,
which
I
think
we
should
of
kind
of
a
higher
level
should
or
should
handle
may
handle,
may
not
those
things
are
and-
and
we
kind
of
just
get
to
the
basic
characteristics,
then
I
think
an
alias
can
be
left
up
to
an
implement
and
up
to
an
implementer.
G
F
G
Oh
yeah,
if,
if
mii
the
us
case,
we,
we
also
have
using
a
class
id,
but,
for
instance,
we
are
using
like
thanos
to
to
to
gather
all
the
cluster
metrics
and
stuff
and-
and
I
think,
having
an
alias,
it
will
be
really
helpful
in
order
to
to
be
able
to
to
identify
which
kind
of
paths
are
the
metrics
that
they
are
coming
from
and
stuff
from
phenomenal
perspective.
It
sounds
very
useful.
A
So
maybe
maybe
the
right
first
step
is
to
sort
of
start
from
first
principles
and
see
if
we
can
really
rethink
the
requirements
so
like
that
the
last
one
was
a
really
good.
One
right
like
an
agent
in
the
cluster,
wants
to
know
the
clusters
name
so
that
it
can
decorate
metrics
with
the
cluster
name
right
and
and
just
like
try
to
collect
them.
Some
base
requirement
statements.
I
got
a
feeling
gut
feeling
here
that,
if
we
have
more
than
like
eight
or
ten
requirement
statements,
we're
probably
missing
the
boat
again.
G
C
Yeah,
I
think
I
think
we
should
also
play
back
decisions
that
we
make
around
this
into
our
our
ongoing
work
on
multi-cluster
services
and
work
api
as
tests
for
are
we
making
those
problems
and
api
construction
simpler?
Are
we
making
them
more
complicated,
etc,
etc?
D
Than
than
before,
when
you
know
it
seems
like
a
lot
of
the
use,
cases
were
were
fabricated.
Now
we
have
now
we
have
some
real
in-flight
projects
that
need
this.
D
Yes,
I
will
I'll
I'll
try
to
put
something
together
for
for
next
week.
D
C
D
Yeah,
I
mean
the
the
basic
thing
I'm
I'm
thinking
about
here
is
that
when
you
add
a
cluster
to
a
cluster
set
whatever
it
means
in
this
case,
because
we
still
have
to
talk
about
the
registry
concept
right,
but
to
be
a
member
of
a
cluster
set,
a
cluster
needs
a
unique
name.
That
is
a
valid
dns
label.
D
That's
that's
one
of
the
mcs
requirements
that
needs
to
live
as
long
as
the
cluster
is
a
member
of
that
of
that
cluster
set
and
yeah,
so
unique
and
immutable
as
long
as
the
membership,
and
can
always
be
used,
for
example,
by
mcs
headless
services
to
basically
insert
into
the
address
for
for
pods
backing
a
headless
service
in
that
cluster,
and
so
that
that's
that's
basically
it
I.
D
I
don't
know
that
things
like
globally
unique
you
know
beyond
the
cluster
set
and
machine
generated
are
necessarily
things
that
need
to
be
spelt
out.
I
think
there's
very
good
valid
use
cases
for
that,
but
I
think
that,
like
a
a
valid
dns
label,
kind
of
gets
close
enough
to
covering
any
kind
of
use
case.
You'd
want
you,
can
you
can
cram
a
lot
in
there
and
it
leaves
a
lot
of
flexibility.
D
D
Ids
or
names
and
and
that
can
be
left
up
to
left
up
to
an
implementation.
I
think
it
makes
sense
that
this
is
introduced
in
a
in
a
crd
that
lets
you
within
a
cluster,
see
what
cluster
you're
actually
in,
I'm
not
100
sure
that's
actually
necessary
in
the
mcs
use
case,
but
it
might
ease
a
few
implementations
and
it
you
know
it
seems
logical
that
once
we
have
this,
it
lives
somewhere
in
the
cluster.
So
you
as
a
cluster
you
can
see
who
you
are
yeah.
D
C
I
was
just
gonna
say
I
think
it.
It
makes
a
lot
of
sense
that
it's
discoverable
from
within
a
cluster,
so
that,
like,
if
you
have
a
an
agent,
that's
running
in
cluster,
for
concern
x,
that
that
agent
knows
how
to
self-identify
relative
to
the
hub,
maybe
and
other
discovery
use
cases
like
that.
D
I
also
think,
starting
with
the
crd
is
good
because
it
gives
us
a
place
to
you
know
if
we,
if
we
do
want
to
tackle
verification,
which
I'm
sure
will
come
up
at
some
point
as
long
as
there's
any
form
of
registry,
it
gives
us
a
place
to
store
whatever
information.
We
need
to
verify
that
a
cluster
is
who
it
says
it
is.
D
But
that's
that's
kind
of
the
the
super
short
form
and
where
I
plan
to
start
with
with
this
doc,
to
get
this
rolling
and
and
hopefully
we
can
keep
it
more
high
level.
You
know
I've
really
liked
the
way
mcs
is
focused
on
just
the
just
the
bare
minimum
that
we
actually
need
to
create
some
common
functionality
and
left
a
lot
open
to
implementation,
and
I
think
you
know
cluster
id
should
probably
do
the.
C
So
so
is,
is
that
what
you
wanted
to
cover
today?
Do
we
are
we
talk
through
for
that
for
now,.
D
I
think
so
yeah,
that's
that's
all
I
wanted
to
cover
and-
and
I
think
the
next
step
is
definitely
going
to
be
better
around
a
dock-
that
I'll
put
together
and
share
with
the
the
list.
C
Okay,
that
sounds
good
if
we're
talk
through
on
that
I'll
just
mention
that,
like
that
chojin
has
been
reading
some
comments
in
the
the
work
api
doc.
I
don't
know
if,
if
he's
here
today,
but
I
know
that
he
was
looking
at
those
and
thinking
about
them,
so
we
might.
We
might
have
an
update
to
provide
around
that
next
week.
D
C
Okey
doke
well,
thank
you,
everybody
and
I
guess
we'll
see
you
next
time
have
a
wonderful
afternoon.