►
From YouTube: Kubernetes SIG Multicluster 12 June 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).
B
A
A
Okay,
why
don't
we
go
ahead
and
get
started?
Folks!
Welcome
everybody
to
the
july
12
2022
sig,
multi-cluster
zach.
I
think
you
have
something
on
the
agenda
around
cube,
fed.
Why?
Don't
you
go
ahead
and
I'll
go
ahead
and
enable
screen
sharing,
because
I'm
pretty
sure
somebody
on
the
agenda
may
have
a
deck.
C
Okay,
so
should
I
talk
now.
C
Okay,
okay,
nice
to
meet
you
all
and
I'm
zach
from
and
guru
and
group
hybrid
cloud
producting,
and
I
want.
I
would
like
to
talk
about
my
agenda
yeah,
that
was
about
cuphead.
Our
team
is
building
first,
I
would
like
to
have
a
brief
introduction
to
our
team.
What
are
we
doing
and
what's
up,
what
are
we
doing
with
kubefed?
Okay
and
our
team
is
building
cloud
native
paths
to
help
our
customers
run
and
operate
their
apps
on
multi-cluster
cloud.
They
currently
include
public
cloud.
C
Private
cloud
and
sooner
would
be
extend
to
hybrid
code
and
cube
fed
is
the
underlying
layer
we
use
for
multi-cluster
kubernetes
resource
management,
and
we
have
been
using
cryptfeld
for
over
two
years
as
father
cole
yeah.
So
you
know,
confed
is
still
somehow
active
at
that
time
and
we
don't
have
many
third-party
choices
at
that
time.
You
know
like
now.
Now
we
have
many
other
third-party
choices,
and
now
our
products
are
widely
used
across
50,
more
than
50
companies
around
the
world
in
production.
C
So
it
definitely
won't
be
easy
for
us
to
switch
to
some
other
solutions.
So
let
alone
cube
fed,
is
well
suited
to
our
case.
Now
in
general,
our
product
will
manage
several
large
clusters
rather
than
many
small
clusters
like
each.
We
do
not
use
this
case,
so
the
push
model
of
cube
fed
is
descent
for
us.
I
think
for
now
yeah.
C
So
this
is
why
we
would
like
to
help
keep
the
maintenance
of
cube
fed,
because
we
are
still
actively
using
it
in
production
and
we
are.
We
would
like
to
use
it
in
the
near
future.
Yeah
and
the
next
I
would
like
to
share
is
some
internal
enhancements
of
our
team
to
to
to
the
fed.
If
you
are
interested
you
can
you
can
hear
that
yeah,
the
first
one
is
called
placement
mask.
C
C
So
in
this
case
we
have
to
propagate
some
annotations
to
the
service
yeah.
So
we
introduce
a
propagating
annotations
annotation
on
the
federated
type
conflict
and
this
tells
coupe
which
annotations
to
propagate
and
and
which
to
retain,
and
we
also
support
wild
cards.
So
we
make
this
configuration
very
flexible
and
this
is
well
fit
in
our
use
case
yeah
and
speaking
of
this
feature
recently,
I've
also
found
many
people
have
need
to
customize
the
publication
and
retention
rules
of
federated
resources.
C
So
that's
all
about
my
sharing
about
the
fed
and
finally,
I
would
like
to
talk
about
the
maintenance
of
the
project.
Yeah
I've
been
watching
and
contributing
to
this
project
over
a
year.
So
I
think
I
have
some
knowledge
about
the
current
maintenance
state
of
the
compat.
C
We
have
some
I've
seen
three
core
maintenance
of
goodbye.
Now,
maybe
some
some
of
you
have
have
already
known
them.
They
are
hector
ironfan
and
jimmy
dyson.
No,
and
for
now
I
can
always
see
our
fans
still
keep
an
eye
on
this
project,
but
just
and
I
you
know
and
jimmy
addressing
jimmy
addressing
releases,
occasionally
you
know
addressing
releases
but
yeah
and
hector
seems
to
be
disappeared
from
this.
C
The
project
for
some
time
and
I've
been
reached
out
to
him,
and
you
know,
since
he's
no
longer
working
at
this
iq
and
there's
no
big
impact
to
keep
him
working
on
this
project.
You
know
detailed
q
is
using
q
pad,
but
now
actually
not
that
I'm
not
at
digital
iq
yeah.
C
So
he
just
told
me
help
the
project
as
much
as
I
can
okay.
So
I
also
tried
to
reach
out
to
jimmy,
but
get
no
response.
So
I
don't
know,
what's
the
what
his
condition
is
yeah
so
so
this
project
is
really
in
nearly
archived
situation
if
there's
no
active
maintainer
to
draw
in.
So
that's
why
I'm
here
and
advocate
myself
to
take
the
responsibility
of
the
project,
and
this
is
not
only
because
our
team
is
doing
this
yeah.
C
I
was
just
I've
still
seen
many
people
around
there
using
the
project
and
want
to
make
it
better.
An
evidence
is
that
there
are
still
new
prs
issues
and
sex
talks
on
this
project.
So
there's
actually
people
around
here
using
this
project
and
keep
unit
yeah.
So
I
think
this
project
still
has
some
mentality
and
I
would
like
to
keep
that
yeah.
C
So
that's
all
about
my
introductions
and
some
sharings
and
now
I
would
like
to
know
your
thoughts
yeah,
our
illustrious
chairs
and
about
this
project,
and
if
I
keep
the
maintenance
of
the
project,
what
do
you
expect
me
to
do
with
it?
There's
some
rules
or
suggestions
yeah,
that's
what
I
would
like
to
know
about.
Yeah.
E
So
so
I
can
chime
in
here
paul-
and
I
have
been
discussing
this
a
lot
because
you
know
it's
very
clear
that
people
are
still
using
cuphead.
You
know
we
see
questions
come
up
in
slack.
I
think
the
the
other
thing,
that's
very
clear,
is
like
there's
been
some
activity,
but
the
project
has
clearly
slowed
over
the
past
couple
years
and
like
the
idea
of
having
someone
come
in
and
step
up
and
maintain,
it
is
awesome.
E
I
guess
we
just
want
to
make
sure
that
we're
very
clear
about
the
status
of
the
product.
If,
if
the
project
is
still
gonna,
make
a
lot
of
forward
moves,
that's
that's
great.
E
It
is
kind
of
a
you
know,
it's
probably
a
big
commitment.
I
think
the
biggest
thing
for
us
is
just
making
sure
that
the
community
is
clear
on
the
stance
like
is
this
in
maintenance.
C
E
E
I
think
paul,
please
chime
in
if
you
disagree
or
or
agree
with
anything,
I'm
saying,
but
I
think
the
big
thing
for
us
is
just
making
sure
that,
like
people
asking
questions
in
slack,
know
that,
like
you
know,
this
is
a
good
place
to
come,
get
answers
or-
or
you
may
not
get
an
answer,
and
so
it's
more
like
a
maintenance
project
and
just
so
they
can
set
expectations
accordingly.
A
Yeah,
I'm
I'm
glad
that
I'm
glad
to
know
zach
that
you're
interested
in
maintaining
it.
I
think
you
know,
jeremy,
makes
some
good
points.
I
will
say
that
I'm
thinking
carefully
about
what
my
decision
tree
looks
like
here,
and
one
thing
that
I'll
mention
is
that
I
I
don't
think
it
would
be
great
for
anybody
if
cube,
fed,
wound
up
being
sort
of
half
alive
with
only
one
maintainer.
A
You
know
I
I
act
what
you
say
about
wanting
to
enrich
the
project
and
that
you've
been
using
it,
but
I'm
I'm
still
trying
to
think
about
what
my
own
decision
tree
is,
and
you
know
what
the
best
thing
for
both
the
people
that
are
using
cube
fed
now
and
the
people
that
may
want
to
maintain
cube.
That
is,
I
don't
have
a
clear
answer
that
I
can
give
you
right
now,
but
I'm
glad
that
you
came-
and
you
know,
spoke
to
us
today
about
it
jeremy.
A
I
think
you
and
I
probably
need
to
keep
talking
about
this
offline
so
that
we
can
be
on
the
same
page.
It
bears
some
consideration
agreed.
C
Yeah
yeah,
I
agreed
to
well
paul,
says:
actually,
actually,
we
lack
of
some
contributors
to
this
project
yeah
and
now,
if
I
try
to
maintain,
join
the
maintenance
of
the
project-
and
I
think
says
currently
mainly
I
and
our
plan
will
maintain
we'll
keep
the
maintenance
of
this
project
and
we
will
surely
need
more
maintenance
if
we
want
to
make
it
more
active
yeah
and
I
think.
C
Yeah
yeah,
maybe
I
I
could
ask
my
co-workers
to
see
if
they
would
also
like
to
help
the
maintenance
of
the
compare,
so
that
we
have
more
power
to
to
do
this.
Yeah
and
another
thing
is
that
actually,
I
think
now
it's
now
state
is
maybe
it
doesn't
need.
Many
of
many
can
make
many
contributing
forces
to
keep
that,
because
the
issues
and
the
prs
is
not
not
very,
very
rich,
like
other
other
active
projects,
and
it's
just
keep
a
a
p,
a
piece
maintain
peace
maintain
state
yeah.
C
We
we
have,
we
have
issues
made,
maybe
one
or
two
a
week
and
prs,
maybe
several
amounts,
and
so
we,
so
I
don't
think
we
need
too
much
maintainers
to
to
keep
the
to
keep
the
project.
F
C
I
think
maybe
two
or
three,
but
also
okay,
to
this
project
of
this
of
current
state.
I
think
if
we,
if
we
would
like
to
make
some
big,
make
some
big
future
recently
yeah,
then
a
small
group
of
maintainers
is
also
enough.
I.
E
Think
yeah
I
I
think
it
might
also
be
a
little
bit
of
a
circular
thing
so
and
paul,
and
I
probably
need
to
discuss
and
figure
out
what
the
decision
tree
looks
like
and
we
can
follow
up
with
you,
but
one
concern
is
like
there
aren't
very
many
issues
right
now,
because
the
project's
been
very
relatively
stale,
and
so
you
know
it's
people
don't
see
a
lot
of
activity.
They
don't
you
know
it
steers
people
away.
If
it
started
picking
up
again
and
getting
more
contributions,
I
would
expect
that
more
issues
would
follow.
E
So
you
know
active
projects,
get
more
interest.
It
seems
like
a
relatively
safe
assumption
so,
like
I
think,
if,
if
I
look
back
at
you
know
some
of
the
conversations
we've
had
about
this
in
the
past,
I
think
the
the
big
thing
is
that
the
the
status
quo
is
probably
not
good
for
the
project
right
now,
because
right
now
it's
this
confusing
state
where
it
doesn't
get
a
lot
of
contributions.
It
doesn't
get
a
lot
of
attention.
C
E
You
know
the
code's
never
going
to
go
away,
but
I
think
what
we're
seeing
right
now
is
that
cuba's
kind
of
in
a
very
confusing
limbo,
where
it's
it
has
some
attention.
It's
clearly
not
like
you
know,
shelved
like
people
are
using
it,
but
it
also
doesn't
have
enough
attention
to
really
serve.
You
know,
newcomers
and,
and
some
of
the
folks
who
are
who
are
running
into
issues
with
it.
E
A
Here's
here's
overall.
What
I'll
add
is
that
it's
pretty
clear
to
me
that,
like
the
state
cube
fed
is
in
now
is
not
one
that
should
continue
and
in
the
sense
that
it's
sort
of
half
alive
right
like
it's,
it's
clearly
not
completely
dead.
It's
still
in
our
sig
yaml
right,
but
it's
it's
not
receiving
a
lot
of
energy
and
attention,
and
I
I
don't
think
that's
good
for
us.
It
certainly
muddies
the
water
on
what
is
sigma
multi-cluster
doing.
A
A
Where
do
we
want
it
to
go
right
like
what
states
are
ideal
and
a
state
where
it's
a
healthy
project
that
has
you
know,
contributors
from
a
number
of
different
companies,
et
cetera,
et
cetera,
like
healthy
project,
state
or
archived,
like
it's
clear
that
one
of
those
is
much
easier
to
achieve
than
the
other,
so,
as
jeremy
said,
like
nobody's
at
risk
of
losing
access
to
the
code?
But
if
I
think
about
the
the
states
where
we
can
feel
like
there
isn't
something
that
needs
attention
on
it.
A
But
I
tell
you
what
jeremy,
I
think
you
and
I
need
to
take
an
action
item
to
like
make
our
decision
tree
and
we
probably
need
to
put
a
date
on
it
because
you
know
cube
fed,
has
been
in
this
state
for
some
time
and
it
it's.
The
presence
of
it
being
in
the
state
is
something
that
I'd
like
to
to
put
to
bed
in
one
way
or
another.
C
A
A
Yeah
all
right,
thank
you.
Zach
laura
you're
up
next.
D
Hi
I'm
going
to
share
my
screen.
B
I'm
shocked,
I'm
shocked,
I
know
visual
aids.
I.
D
Have
a
few
visual
aids
okay,
so
I
wanted
to
bring
up
something
very
something
specific
about
the
about
api,
and
this
came
up
from
a
conversation
I
had
with
tim
hawkin,
who
was
even
in
the
call
today
hello,
but
this
is
about
the
well-known
cluster
of
property
idks.io
and
just
to
give
a
little
bit
of
background
and
also
remind
everybody
for
the
mcs
api
and
for
the
cluster
id
caps,
which
are
related
projects
that
are
both
in
alpha
status.
D
Right
now,
I'm
tracking
the
beta
blockers
in
this
document
here
which
I've
linked,
including
all
the
various
histories
too
so
happy
to
give
like
any
other,
more
general
update
or
refer
to
any
of
this,
but
the
section
that
I'm
specifically
talking
about
right
now
is
this
item
about
id
case.io
and
then
one
more
just
reminder.
D
Intro
thing
not
intro,
but
like
reminder
thing,
I
guess
about
what
I'm
even
talking
about
is
that
in
the
cluster
id
cap
there
is
this
definition
of
a
cluster
property
crd
and
there's
this
definite,
a
very
specific
definition
of
a
cluster
property
of
the
name
id.case.io.
That
has
some
certain
restrictions
written
in
the
standard
and
this,
at
least
for
the
purposes
of
its
partner
kep,
the
mcs
api.
The
goal
is
to
use
the
value
of
id.casio
in
potentially
various
things,
but
right
now,
dns
for
multi-cluster
services.
D
So
all
that
background
is
to
say
that
I
was
talking
to
tim
I'll,
make
this
oops,
that's
how
I
make
it
bigger.
This
is
how
I
make
it
bigger.
I
was
talking
to
tim
about
this,
and
we
were
discussing
from
an
api
review.
Perspective
is
id.case.io
too
strict
of
a
name
for
a
this
cluster
property.
Should
we
go
with
something?
D
That's
more
like
a
variant
and
some
you
know
I'll
kind
of
just
like
mention
all
these
things
here,
because
this
is
this
is
what
it
boils
down
to,
but
even
though
this
name
is
in
cluster
property,
which
itself
is
in
the
sig
multi-cluster
sponsored
crd,
the
crd
does
have
this
really
sort
of,
like
general
sounding
api
group
name.
If
someone
was
just
looking
at
like
this,
you
know
this
cube.
Cuddle,
get
cluster
property
id
case
io,
like
it
kind
of
sounds
like
pretty.
D
You
know
serious,
but
it
does
have
some
specific
restrictions
on
it
from
the
cap
that
are
tied
to
our
goals
of
using
it
in
mcs,
and
potentially
people
will
use
it
in
cases
that
those
restrictions
do
not
align
with
or
think
it's
bigger
than
it
is,
and
it
is
possible
that
this
about
api
could
be
used
in
the
future
for
different
types
of
id
so
like
there
could
be
other
variants
of
id
that
might
be
used
for
certain
types
of
logs
or
might
be
used
for
some
other
project
altogether.
D
But
there
was
a
lot
of
resistance
to
a
one-size-fits-all
approach,
which
is
why
we
went
into
a
crd
why
this
was
like
a
sigmc
crd
in
the
first
place,
but
now
that
all
the
naming
and
stuff
has
shaken
out
just
looking
at
it
straight
as
it
is.
Maybe
this
word
is
still
a
little
too
strong,
so
that's
the
at
it
as
I
understand
it,
tim
feel
free
to
jump
into.
If
I
missed
anything
just
because.
D
Was
mostly
between
you
and
I,
but
I
wanted
to
get
some
perspectives
from
this
and
it's
particularly
timely
because
folks
have
been
coming
up
to
me
talking
about
wanting
to
use
the
crd,
and
I
want
to
make
sure
that
they're
using
the
right
name,
I'm
going
to
skip
jeremy
to
tim,
because
I
asked
him
first.
F
Sorry
so
yeah
for
everybody
else.
This
came
as
I
was
looking
at
things
that
are
still
alpha
and
what
would
we
need
to
do
to
make
them
go
beta,
and
even
I
had
paged
out
the
context
of
sorry,
my
doorbell
just
rank.
I
paged
out
the
context
of
it
being
specific
to
a
cluster
set
and
I
was
trying
to
figure
out
how
to
use
it
without
being
in
a
cluster
set
and
realized
that
I
couldn't
do
that,
and
so
it
felt
like.
E
I
think
this
makes
a
really
good
point,
the
I
wouldn't.
I
don't
think
we
want
to
scope
it
so
narrow
that
it's
mcs
id.
That
seems
like.
E
D
E
Because
mcs
relies
on
cluster
set,
it
can't
be
bigger
and
it's
just
mts
so
like
maybe
it's
the
mcid
or
something
it
is
a
bummer
that
we
can't
make
this
or
that
it
seems
like
there's
friction
to
making
this
the
one,
because
kubernetes
is
really
missing,
that
this
is
like
a
a
big
gap,
but
if
we
can't
address
it
at
least
saying
like
mcid,
maybe
like
in
the
multi-cluster
context,
this
is
the
id
so
that
we
can
at
least
say
that
all
the
multi-cluster
stuff
should
use
it.
F
You
know,
I
think
I
I
think
we
can
still.
I
think
we
can
still
win
the
day
in
the
larger
context,
but
we
need
to
show
that
it's
actually
useful
and
valuable
and
that
the
schema
works
and
doing
so
in
our
own
context
seems
like
the
safest
thing
to
do
it.
We
can
define
the
id
dot
case
that
I
o
and
say
this
is
intrinsic
to
the
cluster
and
it
doesn't
change
to
the
life
cycle
of
the
cluster,
and
then
you
know
boost
it
as
something
that
people
should
use.
F
We
could
use
it
in
gke,
for
example,
right
as
an
existence,
proof
and
take
the
risk
on
it
ourselves,
and
I
think
if
we
can
show
like
actually
it
is
useful
and
you
can
do
cool
things
with
it.
Then
we
have
a
stronger
argument
for
bringing
it
into
core,
although
at
that
point
maybe
it's
a
sail.
Chip.
A
So
sorry
go
ahead:
laura
I'll
go
after
chess.
D
I
still
agree.
There
may
be
reasons
why,
like
having
opening
for
variants,
might
be
relevant.
But
can
you
speak
a
little
bit
more
to
like
what
of
the
you
mentioned
that,
like
the
restriction,
was
that
it
needs
to
be
part
of
a
cluster
set,
and
I
think
there
are.
I
think
there
is
also
something
that
maybe
we
should
clarify
in
here
too
about
this
about
if
it
needs
to
actually
be
like
it
has
restrictions
when
it
is
within
a
cluster
set.
D
C
A
The
root
issue,
so
here's
here's
my
statement
of
what
I
believe
the
issue
described
is,
which
is
that
the
the
the
name
sounds
more
general
than
the
actual
semantics
applied
to
it
are,
and
the
semantics
are
strongly
correlated
with
cluster
sets
right.
A
I
think
I
think
it
makes
sense
here's
what
I
offer,
as
you
know,
a
way
to
soften
or
contextualize
the
name.
What
if
it
was
like-
and
I
know
people
won't
like
this-
so
you
just
know
that
before
I
say
construction,
I'm.
D
A
And
it's
cluster
set
id
like
that
is.
D
C
A
My
offer
to
provoke
the
right
name
being
offered,
but
the
the
point
is
to
to
correlate
with
cluster
set
within
the
name
so
that
it's
clearly
linked
with
that
concept.
What
do
people
think
about
that?.
F
Trying
to
combine
can
it
be
a
dot
like
id
dot.
Cluster
set
dot
case
that
I
like
do
we.
I
don't
know
if
I
forget,
if
we
set
up
rules
for
this
but
like
it
seems
you
know,
we
do
something
similar
when
we
govern
label
names
within
google
right,
we
have
a
repo
where
people
can
claim
names,
so
they
don't
step
on
each
other
and
it's
delegated
this
way.
D
We
also
need,
like
I
don't
know,
because,
like
it's,
not
the
id
of
the
cluster
set
and.
D
We
get
like
if
the
cluster
sets
ideas
on
this
side.
That's
just
too
much
yeah
things
need
to
be
on
the
right
side
of
something
you
know.
Let's
not
do
that
yeah,
don't.
E
Sure
I
I
think
the
model
makes
a
lot
of
sense
just
looking
back
like
we,
we
wanted
id
to
be
like
immutable
for
the
life
of
a
cluster.
There's
just
no
way
to
do
that.
That's
that
was
the
the
problem
like
there's
no
way
to
bootstrap
crds
at
cluster
creation
and
make
them
immutable.
E
So
so
we
couldn't
make
strong
statements
like
that,
because,
because
they
boiled
down
to
like
please
respect
this
everywhere
and
without
giving
a
mechanism
to
to
make
it
doable,
that
seems
seems
difficult,
and
you
know
I
think
we
could.
We
could
get
away
with
some
trust
there
if
there
was
a
way
to
bootstrap
crds,
but
there's
just
no
way
to
actually
say
like
this.
Cluster
doesn't
function
until
this
until
the
id
is
set.
E
So
there's
no
way
for
us
to
say
you
can
rely
on
this
id
being
there,
which
means
all
implementations
need
to
be
able
to
handle
changes,
even
if
they're
not
supposed
to
happen,
because
there
will
always
be
at
least
one
change
from
no
id
to
an
id,
and
I
think
that
gets
really
that
gets
messy,
so
yeah
paul
you're
right,
like
everything
is
please
don't
break
this,
but
in
this
case
like
we
just
there
is
no
mechanism
to
give
you
like.
F
D
One
other
variation
of
this
is
all
of
this
in
this
cap
is
very
like
how
this
acts
during
a
cluster
set,
there's
potentially
a
version
where
we
also
provide
information
of
how
this
acts,
when
it's
not
part
of
a
cluster
set,
and
also
when
it
like
transitions
in.
If
we
think
we
can
future
proof
that
enough,
for
this
name
or
for
a
variant,
that's
less
narrow
than
the
ones
we
were
just
discussing.
D
I
don't
know
if
that's
the
best
idea,
and
it
also
overlaps
a
lot
with
where
we
got
real
stuck
before
when
we
were
like.
Let's
put
this
in
kk,
so
I'm
kind
of
scared
to
open
that
up,
but
just
wanted
to
mention
that
as
a
as
a
route
too,
that
we
address
more
on
the
side
of
what
are
the
uniqueness
lifespan
and
content
restrictions
when
it
is
and
isn't
in
a
cluster
set.
Instead
of
changing
the
name.
E
E
Yet
I
agree
with
the
idea
that
maybe
we
talk
about
the
universal
id
and
we
just
go
ahead
and
implement
it
somewhere
and
you
know,
take
a
bet
on
it
and
see
if,
if
it
gains
traction,
that
might
be
an
easier
way
to
to
show
that
it's
useful
instead
of
having
a
theoretical
conversation,
because
the
the
cluster
set
side
of
things
is
not
theoretical.
Like
we've
got
clear
use
cases
we
know
we
need
it.
The
global
id
is
definitely
theoretical.
I
think
everybody
agrees.
E
It
would
probably
be
good,
but
you
know
there's
tons
of
different
ideas
about
what
format
it
should
take
and.
A
I
hope
that
you
won't
have
nightmares,
I
would
say
it's
probably
not
worth
the
nightmares,
but
I
see
someone
else
looks
like
they
want
to
talk.
H
I'm
on
the
aws
aws
team
and
actually
working
on
a
cluster
id
implementation,
so
I
was
wondering
if
I
could
kind
of
ask
a
question
along
the
same
lines.
Oh
with
the
cluster
id.
I
just
wanted
to
get
your
guys
opinion
on
who
should
create
it.
Should
it
be
a
customer?
Should
it
be
automated?
I
don't
kind
of
want
to
see
what
your
stance
is
on
that.
D
Yeah,
so
we've
definitely
from
the
perspective
of
the
standards
we
standard,
we've
left
it
open
and
also
from
the
perspective
of
the
standard
we
kind
of
soft
pushed
cube,
namespace
uuid
more
so
on
the
like,
really
awesome
as
a
cluster
id
or
our
best,
the
best
idea
in
kubernetes
to
date
of
making
a
good
permanent
cluster
id,
but
the
oh.
D
We
there
was
lots
of
discussion
at
that
time
that
that,
like
is
super
sucky
for
dns,
because
humans
don't
want
to
write
uuids,
and
so
we
always
knew
that
that
was
kind
of
like
not
great.
For
the
real
use
case.
We
were
designing
like
the
narrow
use
case
we
were
designing,
for
which
was
mcs's
dns,
at
least
like
in
gke.
D
That's
right
now,
based
on
something
that's
user
specified
that
ends
up
being
usually
very
similar
to
what
that
user
specified
as
their
cluster's
name.
So
then
it's
more
human-friendly,
it's
more!
What
they?
What
they're
used
to
and.
H
Okay,
oh
yeah.
That
makes
sense
if
we
were,
if
that.
H
Sorry,
hello,
no,
I
can't
better
so
yeah
if
it
was
the
customer.
Let's
say
that
did
do
it
at
what
point
do
they
define
it?
Is
it
like,
I
guess,
before
the
let's
say,
controller
would
start
and
let's
say
yeah.
D
Yeah
with
that
yeah,
so
when
the
the
in
our
case
not
specified
anywhere
by
sig
mc,
I
believe
on
purpose
is
the
idea
of
a
cluster
registry
or
something
that
like
knows
about
all
the
clusters
that
are
part
of
a
cluster
set
also
in
the
mcs
api.
It's
very
like
there's
an
mcs
controller
that
knows
about
everybody
and
we're
not
describing
exactly
what
it
is.
D
So
in
general,
like
in
the
submariner
case
in
the
gke
case,
it's
at
registration
of
the
cluster
to
the
cluster
set
through
whatever
that
implementation
specific
cluster
registry
is.
That
is
when
this
value
is
set.
That
is
then
used
later
in
dns.
D
Cool
okay,
so
what
I
heard
from
all
of
this
was
we
recognize
and
respect
the
issue
of
needing
variations
in
id,
maybe
forever
and
definitely
in
the
short
term,
because
we
already
know
it
was
too
hard
to
make
a
universal
id
from
prior
times.
So
we
need
to
come
up
with
some
name
that
we
don't
hate.
That
isn't
id
case.
I
o
because
that's
too
intense
and
that
maybe
what
I
can
put
to
in
the
kep
or
somewhere
is
that
we,
like
reserve
id.kates.io
for
future
use.
D
I
mean
we
also
like
already
have
the
privilege
of
anything
that
ends
in
kate's.io,
but
I
can
kind
of
move
that
explicitly,
because
I
think
at
least
from
this
discussion
we
believe
here
that
if
we
give
something
the
about
the
dot,
about.kates.io
slash
cluster
property
name
id
dot,
kate.o
people
are
going
to
interpret
that
as
the
unique.
Definitely
this
cluster
name
forever,
and
so
we
should
prepare
for
that
eventuality.
G
A
D
Yeah,
okay
cool!
Well,
I
can
I'm
very
good
at
making
surveys,
though
this
is
probably
a
trending
on
the
most
boring
sir
naming
survey.
I've
ever
come
to
because
I
feel
like
it's.
I
mean,
maybe
I'm
just
not
very
imaginative,
but
I
feel
like
it's
really
got
to
be
something
really
close
to
this
or
you
know
we
don't
have
that
much
wiggle
room.
E
Part
of
me
laura,
you
know
this
that
still
wishes.
We
called
it
super
cluster,
but
you
know,
but
maybe
I
don't
know,
maybe
we
can
just
send
out
on
the
forum
like
a
spreadsheet,
with
some
ideas
give
people
a
week
to
add
their
ideas
and
then
we
can
send
it
a
survey
for
the
you
know
any
you
know
the
the
ones
that
seem
most
intuitive,
something
like
that
yeah.
I
I
imagine
this
one
can
go
pretty
quickly
because
I
agree
we've
yet
to
see
a
single,
interesting
suggestion.
E
But
you
know
that's
where
crowd
sources.
D
And
this
is
like,
since
the
original
problem
was
like
interpreting
it
wrong
from
just
what
I
can
see
in
this
with
the
smallest
amount
of
context.
It
can't
be
something
cute.
You
know
it
needs
to
be
something
you
understand
immediately
as
immediately
from
just
this
word,
so
we're
really
restricted
here
and
how
cute
we
can
be
yeah.
D
Yeah,
it
doesn't
harsh
my
vibe
at
all
to
ask
on
the
mailing
list-
and
I
know
it's
this
one's
a
hard
brainstorm,
because
it's
so
specific,
but
I'm
happy
to
take
some
more
ideas
and
you
know
get
people
to
chew
time
to
chew
on
it
at
least
or
something
instead
of
just
unilaterally
decreeing
here.
So
that's
fine.
E
Cool
what
should
we
time
box?
Oh
maybe
a
week
on
the
spreadsheet,
so
we
can
send
it
a
survey.
D
Yeah
yeah
yeah,
I
think
I'll,
send
it
right.
After
this
and
and
then
we
can
do
a
week
on
the
spreadsheet
a
week
on
the
survey
and
then
we
can
have
this
wrapped
up
by
next
meeting.
D
A
E
Thanks
everyone
thanks
zach
thanks,
laura
see
you
on
the
forums
in
a
couple
weeks,
all
right
see
ya.
Thank
you.