►
From YouTube: Kubernetes SIG Multicluster 2020 Oct 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
A
All
right,
let's
get
started
how's
everyone
doing.
B
A
All
right
awesome,
so
looking
at
the
agenda
today
looks
like
it's
me
with
the
cluster
id
proposal.
So
let
me
screen
share
here.
A
All
right
so
yeah,
based
on
last
week's
discussion,
I
wrote
out
kind
of
a
pass
at
at
what
cluster
id
could
look
like
and
basically
you
know,
there's
there's
a
great
doc
with
background
that
I
highly
recommend
that
everybody
read
that
I
linked
in
this
doc
and
this
one
is
linked
from
today's
agenda,
but
I
really
want
to
focus
on
on
the
concrete
use
cases
first.
A
So
I
think
the
the
real
tangible
use
cases
that
have
come
up-
you
know
in
the
last
little
bit
here
are
are
listed
here
and
basically
it's
it's
membership
in
general
and
and
and
what
a
cluster
means
in
a
cluster
set.
So
some
way
of
uniquely
identifying
a
cluster
within
a
cluster
set
multi-cluster
services.
You
know
as
the
as
the
project
that
we
have
right
now
that
that
really
does
need
this
for
specifically
for
headless
for
headless
dns
implementation,
but
within
a
multi-cluster
service.
A
Some
way
to
disambiguate
back-end
pods
diagnostics
was
a
good
point
that
came
up.
I
think
in
discussion
last
week.
Basically,
a
cluster
should
know
who
it
is
in
the
context
of
a
cluster
set
so
that
it
can
so
that
you
know
your
your
apm
solution
or
our
logs
metrics
can
tag
themselves
with
their
source
clusters
so
that
it's
easier
to
trace
where
problems
are
happening.
A
Verification
is
one
that
came
up
a
few
times
and
I
think
it.
You
know
there
was
some
good
discussion
about
it
in
the
previous
stock,
but
it
seems
like
we
should
allow
the
verification
of
a
you
know
of
a
cluster
and
and
who
it
really
is,
but
not
necessarily
define
what
that
needs
to
look
like.
So
whatever
the
implementation
is,
should
should
leave
that
open
and,
of
course,
the
ability
to
actually
join
a
cluster
set
or
change
cluster
sets
and
what
that
actually
means.
A
B
Yeah
just
for
the
stone
I
I
can
also
voice
it
like.
What's
what's
the
like
the
syntax
of
that
signature
field
supposed
to
be.
A
Because
I'm
not
sure
that
the
way
that
you
verify
that
membership
or
that
identity
will
be
consistent
across
platforms,
so
I
figured
it
made
sense
to
just
basically
say:
implementations
can
can
take
advantage
of
this
if
they
want
to.
A
C
Yeah,
I
my
so
I'm
not
a
crypto
expert
in
any
way.
So
my
first
instinct
is:
we
should
go
talk
to
the
off
people
who
have
lots
and
lots
of
experience
with
verified
signatures
and
they
can
describe
for
us
what
they
think
is
a
schema
for
verification
that
is
future
safe
or
as
future
safe
as
we
can
make
it
and
then
totally
defer
to
whatever
they
suggest.
C
B
Yeah
otherwise
I
would,
I
would
think,
like
there's
a
field,
that's
called
signature,
and
it
has
to
be-
I
guess,
a
string
or
something
like
that,
so
it
has
no
real
meaning
as
long
as
it's
as
as
the
format
is
not
defined,
as
the
format
is
like
domain,
specific
or
environment
specific
we
could
just,
we
could
basically
call
it
anything.
So
I
think
it
would
be
good
to
to
at
least
put
some
some
constraints
on
how
it
should
look
like.
A
Yeah,
I
I
agree
and-
and
I
think
tim
made
a
really
good
point-
I
mean
I'm
also
not
a
crypto
expert,
and
so
I
thought
about
trying
to
write
out
the
crd,
and
I
actually
so
I
didn't,
because
I
wanted
to
start
with
just
the
concepts,
so
we
can
agree
on
them,
but
I
think
that
somebody
other
than
me
should
define
what
the
signature
looks.
Like
is
basically
what
I'd
say
there.
Somebody
who
knows
this
area
much
better.
A
But
but
I'm
all
for
having
definition,
if
there's
a
good
future-proof
way
to
define
that.
A
Cool,
so
the
basic
concept
is
a
cluster
claim,
crd,
which
is
a
very
simple
new
resource,
with
a
name,
a
value
which
is
the
actual
claim
or
data
for
the
claim,
and
then
a
signature,
which
is
what
we
were
just
talking
about,
that
you
know
tb
to
be
specified
the
and-
and
currently
you
know
just
to
start.
A
I
think
there's
two
well-known
claims
that
that
came
to
mind
and
the
idea
behind
this
is
that
there's
that
this
is
a
cluster
scoped
resource
and
and
there
will
be
certain
values
that
you
know
every
cluster
in
a
multi-cluster
kubernetes
deployment
should
have,
and
then
there's
probably
some
additional
values
that
we
don't
need
to
necessarily
define
that
are
vendor
specific
or
or
tool
specific.
A
But
the
two
obvious
claims
to
me
were
basically
the
id
and
and
later
the
the
cluster
set.
So
the
id
is
a
clusters
identifier
within
a
cluster
set
or
beyond,
but
at
least
within
a
cluster
set
and
the
cluster
set
would
be
how
a
cluster
identifies
which
cluster
set.
It
belongs
to.
A
That's
a
that's
a
tough
one.
I
think
I
think
you
know
the
concept
absolutely
makes
sense.
A
Of
course,
obviously
having
a
unique
identifier
forever
is
great,
where
things
get
complicated
is
actually
mapping
that
back
to
to
the
id
with
you
know
the
potentially
less
unique
identifier-
and
you
know
this-
this
is
one
of
the
things
the
original
doc
touched
on
as
well,
but
global
unique
forever,
basically,
guarantees
not
human
friendly
yeah,
and
so
the
the
outcome
is,
you
have
a
your
human
friendly
string
needs
to
always
map
to
this
id
and
they
they
get
tied
together,
and
I
guess
the
human
friendly
version
can
change,
but
but
it
starts
getting
complicated
but
also
in
terms
of
you
know,
use
cases
like
yes,
tools
can
identify
the
clusters
uniquely
forever,
but
like
let's
look
at
the
diagnostics,
for
example.
A
A
C
A
And
that's
that's
actually,
the
my
only
hang
up
from
defining
it
yet
is
that
yeah?
That
conceptually
makes
makes
sense
to
me
for
sure,
but
I
can't
come
up
with
anything
that
isn't
vague.
That
really
needs
it
and
I
think
most
cases
could
be
solved
by
basically
just
watching
watching
the
id
that
is
mostly
or
rarely
mutable
right,
but
yeah.
Also
we
can,
we
can
add
it.
You
know
I
have
nothing
against
a
uuid
dot.
Case.Io
claim
existing
in
the
future.
C
A
Right
so
the
the
basic
concept
of
the
id
is
that
it
must
be
unique
within
a
cluster
set
for
as
long
as
the
cluster
and
and
immutable
as
long
as
the
cluster
belongs
to
a
cluster
set,
it
probably
should
be
unique
beyond
the
cluster
set
within
the
at
least
within
the
scope
of
expected
use.
So
try
to
make
this.
A
You
know
unique
within
your
company
or
especially
your
team,
but
try
to
pick
values
that
aren't
likely
to
collide
like
test
cluster
is
probably
a
bad
id,
but
my
specific
app
test
cluster
is
maybe
a
much
better
one.
It
may
be
globally
unique,
but
we
don't
want
to
define
that
due
to
you
know
the
fact
that
humans
probably
need
to
type
this
at
some
point
and
it
may
be
unique
beyond
the
span
of
the
cluster's
membership
in
lifetime.
There's
nothing
wrong
with
permanently
reserving
these
ids.
A
So
you
know,
if
I
could
sum
up
this
requirement:
it's
basically
it
should
be
mostly
immutable,
but
we're
not
going
to
specify
that
it
can't
change
ever,
except
within
the
context
of
a
cluster
set.
So
as
long
as
the
cluster
belongs
to
a
cluster
set.
This
is
within
that
cluster
set
absolutely
unique
and
immutable.
So
tools
that
need
to
work
on
multiple
clusters
in
a
set
can
rely
on
that.
A
And
then
the
the
only
other
real
requirement
is
that
it's
a
valid
dns
label
so
that
we
can
use
it
for
multi-cluster
services
and
it
makes
it
easier
to
know
that
it
will
be
able
to
show
up
in
other
resources
in
the
future.
A
A
Cool
the
other,
the
other
big-
and
this
is
maybe
a
little
less
obvious,
but
the
other
been
thinking
of
is
is
the
cluster
set,
and
this
would
be
the
the
actual
tie
between
a
cluster
and
its
set.
A
So
it
knows
where
it
belongs,
so
the
first
or
one
of
the
big
requirements
is
that
it
must
have
an
accompanying
cluster
id
claim
so
that
we
can
so
that
you
know
that
the
basically
this,
if
this
defines
membership
in
a
cluster
set,
this
requirement
guarantees
that
all
cluster
sets
or
all
clusters
in
a
cluster
set
have
an
id.
A
But
I
didn't
really
want
to
define
what
this
contains.
This
must
be
immutable
for
the
duration
of
a
membership,
but
what
it
actually
contains
it
could
be.
You
know
a
universal
cluster
set
id
that
that
identifies
that
cluster
set
everywhere
or
potentially
it
could
be.
You
know
the
a
link
between
the
identifier
of
a
link
between
that
cluster
and
the
cluster
set.
C
So
I'm
anxious
about
the
relationship
between
cluster
claims
right,
like
you
said
it
must
have
an
associated
id
like.
I
wonder
if
it
would
make
sense
to
find
a
way
to
fold
those
into
a
single
claim,
like
maybe
a
context
or
something
like
this,
is
your
id
in
the
context
of
a
cluster
set
and
context
for
many
claims
would
just
be
optional,
but
for
this
claim
to
be
part
of
the
requirement.
A
So
yeah,
I
thought
about
that
too.
So
my
first
pass
at
this
actually
just
had
one
like
singleton
cluster
id
resource
and
that
would
hold
basically
all
of
this
information,
but
I
guess
the
hang
up
there
is
that
an
id
can
an
id
is
actually
a
useful
concept
beyond
just
the
cluster
set.
You
know
for
the
diagnostics
things
like
that
and
for
the
other
things
that
we
were
just
talking
about,
that
we
might
want
to
uuid
for.
C
Just
typing
yeah,
but
so
I
I
don't
think
we
should
change
it
to
a
singleton
like
I've.
I've
tilted
at
that
windmill
with
the
api
machinery.
Folks
they're
not
trying
to
give
us
singleton
resources,
even
though
it's
correct
the
oh,
this
is
being
recorded
in
that
shoot,
daniel's
wrong.
I
don't
think
we
should
make
it
a
singleton,
I'm
I
I'm
again,
I'm
totally
thinking
out
loud
here.
I
like
the
idea
of
changing
cluster
id
into
a
set
of
claims.
C
I'm
I
was
thinking
of
this
particular
use
case
as
if
the
schema
for
claim
was
just
a
little
bit
more
robust,
then
the
only
well-known
one
that
we
define
right
now
is
cluster
id.
You
can
define
a
cluster
id
without
a
a
cluster
set
membership,
but
you
can't
define
membership
without
the
id
right.
The
membership
is
the
the
context
and
so
sort
of
by
definition.
Those
two
are
linked
in
that
way
and
then
we
can
add
in
a
uid
we
can
add
a
foobar.
A
So
so
here's
here's
where
to
me
that
starts
to
get
a
little
confusing
if
there's
there's
two
two
potential
cases,
so
the
first
one
is,
let's
say
I
have
let's
say
I
have
an
id
and
and
the
cluster
set
membership
and
and
the
idr
linked
right
and
I
start
out.
I've
got
a
cluster,
it's
not
part
of
a
cluster
set,
but
it
has
an
id.
A
A
C
C
A
Right
but
it,
but
it
is
now
telling
everybody
that
this
claim
has
changed,
and
I
guess
to
drive
this
home.
What?
If?
What?
If
in
my
organization,
cluster
identification
is
handled
by
by
authority
a
and
set
membership
is
handled
by
something
running
inside
the
set,
we'll
call
it
authority
a
30b,
so
each
claim
would
be
signed
by
somebody
else.
C
A
Well,
I
I'm
assuming
it's
a
subset
right
like
the
same
kind
of
thing
we
that
we
we
talked
about
with
with
namespace
sameness,
like
all
of
these
clusters,
need
to
be
run
by
some
authority,
so
maybe
that
top
level
authority,
my
company
owns,
owns
signing
cluster
ids,
but
the
cluster
the
the
cluster
set
itself
can
handle
cluster
sets
within
that
and
because
it's
operating
within
that
top
level
authority,
we've
got
this
id
or
we've
got
this
guarantee
of
of
uniqueness.
C
A
A
There
must
be
an
id
as
long
as
a
cluster
is
part
of
a
cluster
set,
and
there
must
be
a
cluster
set
claim.
As
long
as
a
cluster
is
part
of
a
cluster
set,
the
mutual
dependence
both
are
actually
dependent
on
the
state
of
membership
in
a
cluster
set,
not
on
each
other.
So
we
could
just
delete
that
line
and,
and
maybe
feel
better
about
this.
C
A
A
So
we're
saying
that
if,
if
I
want
to
build
something
that
relies
on
the
on
the
cluster
claim
spec,
then
I
can
trust
that
anytime,
my
cluster
belongs
to
a
cluster
set.
There
is
both
an
id
that
uniquely
identifies
the
cluster
within
that
cluster
set
and
a
cluster
set,
which
tells
me
which
clusters
that
I
belong
to,
if
ever
there's
a
state
where
that's
not
the
case,
then.
A
A
And
I
mean
at
some
point
since
we
can't
update
these
atomically,
there
will
be
a
brief
period
where
that's
the
case,
but
I
think
I
would
expect
that
tools
that
rely
on
both
values
fail
during
that
period
and
fix
themselves,
and
so,
if
they
both
don't
exist,
they
will
they
will
also
they
will
just
fail
as
long
as
as
one
of
the
one
of
the
claims
is
missing.
C
A
I
I
don't,
I
don't
like
it
to
be
honest,
I
think
you
know
reading
this
spec.
That
can
be
that
can
be
accomplished
by
like
leaving
a
cluster
set
and
joining
a
cluster
set,
and
you
get
all
of
the
same
guarantees.
A
A
C
I
haven't
read
the
entire
doc
in
as
much
detail
as
I
want,
but
you
answered
all
the
questions
that
I
had
so
far.
A
Okay,
cool
I'm
gonna
delete
this
codependency.
A
By
the
way,
sorry,
what
were
you
saying
tim.
C
I
was
gonna
say
to
everyone
else
this
this
shouldn't
just
be
a
conversation
between
jeremy
and
I.
B
A
I
think
the
other
big
kind
of
door
I
wanted
to
leave
open
was
additional
claims.
So
you
know
one
of
the
advantage
of
this
well-known
name
claim
approach
is
that
we
can
say
you
know.
Kate,
starrio
and
six
kate
stadio
are
are
reserved,
for
you
know
first
party
concepts,
but
there's
nothing
stopping
anyone
else
from
creating
their
own,
their
own
claims
for
their
own
tools
and
use
the
same
mechanism.
A
And
you
know
we'll
know
that
they
won't
collide
and
it's
responsible.
They
kind
of
divvy
up
their
own
domain,
but
but
this
can
also,
you
know
we
can
eventually
add
the
uuid
claim
we
can
add.
I
think
there
were
some
other
ideas
thrown
out
in
comments
yeah,
like
maybe
a
cloud
provider
or
another
provider,
specific
id
group
membership.
You
know
if
we
ever
do
go
into
what
is
like
a
a
subset
of
a
cluster
set.
Things
like
that
can
be
stored
in
claims,
but
any
other.
A
C
I'll
give
this
a
more
thorough
read
through
lately
later
today.
I
is
it.
Is
it
worth
writing
here?
Like
the?
Are
you
linked
to
the
old
doc?
I
guess
that's
fine,
never
mind
I
was
gonna
say.
Is
it
worth
writing
the
alternatives
considered
section,
but
but
we
did
yeah,
I
guess
it
like.
Do
you
want
to
maybe
open
a
thread
with
some
off
folks
and
see
what
they
think
about
their
verifiability.
A
Yeah
yeah,
I
think
that's
the
next
step
is
get
get
auth
folks
involved
and
and
then
maybe
start
drafting
up
what
the
crd
will
look
like
and
then
you
know
assuming
there's
no
major
concerns
coming
from
off.
Maybe
we
can
turn
this
into
a
cap.
B
I
have
one
question:
actually
maybe
you
already
covered
that,
but
I
missed
it-
is
there
examples
of
different
approaches
to
having
like
singletons
in
a
cluster
as
the
one
that
you're
proposing
here?
C
Many
have
tried
it.
I've
seen
I've
seen
it
attempted
a
few
times
either
it
usually
ends
up
breaking
down
into
something
that
doesn't
mean
singletons
in
the
end
or
they
just
pick
a
magical
name
and
they
say:
look
I'm
only
going
to
pay
attention
to
the
the
the
thing
named
default
or
the
thing
named
cluster
and
everything
else
will
be
ignored
or
they
stick
in
a
mission
controller
and
like
there
isn't
a
there,
isn't
a
canonical
pattern
to
singleton.
I
think.
A
Yeah
absolutely
yeah,
and
I
I
think
this
this
actually
creates
more
flexibility,
which
is
nice
but
yeah.
It's.
It
definitely
started
at
least
as
a
kind
of
working
around
the
fact
that
there's
no
good
singleton
answer.
A
A
A
All
right:
well,
then,
I
think
we
are
talked
out
for
the
week.
I
appreciate
the
input
thanks.
Everyone,
please
take
a
look
at
the
doc.
Add
comments,
you
know,
I'd
love,
I
love
more
feedback
and-
and
if
you
know
if
there
are
any
other
alternatives
too
we're
not
stuck
on
this
option,
of
course.
So
thank
you
all
and
have
a
great
week.