►
From YouTube: Kubernetes SIG Multicluster Feb 9 2021
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
C
C
Yeah,
that's
a
good
idea,
maybe
for
next
time
I
will
like
start
bringing
a
riddle
or
something
like
that.
That's
fine!
I,
like.
A
C
A
C
Okay,
we're
we're
three
after
now,
so
one
other
thing
besides
riddles
that
I
resolved
to
start
doing
is
introducing
these
meetings
so
welcome
everybody
to
the
february
9th
2021
meeting
of
sig
multi-cluster
laura,
I
think
you're
on
the
agenda
and
I
think
you're
the
sole
agenda
item
for
today.
Although
I've
got
one
other
little
update
that
I'll
give
at
the
end
around
the
work
api
stuff
so
laura
over
to
you.
B
Awesome
thanks:
can
I
get
some
screen
sharing.
B
Okay,
the
trivia
question
was,
who
is
the
historical
figure
that
king
richard
and
prince
john
from
robin
hood,
the
mother
of
king
richard
and
prince
john
from
robin
hood,
is
based
on
I?
I
could
not
get
this
one.
It
was
the
hardest
question
of
the
week.
You.
B
Exactly
right,
I
think
the
the
weekly
trivia
was
about
robinhood
because
of
the
the
wall
street
bets,
but
the
answer
was
eleanor
of
aquitaine.
B
C
C
B
Excellent,
so
I
want
to
give
an
update
about
cluster
id
and
in
particular
I
went
through.
I
made
a
new
pr
bumping,
the
diff
for
sections
that
needed
to
be
filled
out
to
try
and
get
to
implementable.
Then
I
also
tried
to
fill
in
as
much
as
I
could,
including
some
more
user
stories.
From
my
travels
to
talking
to
cluster
api,
I
went
to
see
sig
cluster
life
cycle
today.
B
Also
so
definitely
comments
encouraged,
but
I
also
wanted
to
take
the
time
today
to
give
opportunity
for
people
to
provide
input
about
some
of
the
majorly
unresolved
points,
especially
the
ones
that
I
didn't
feel
like.
I
could
like
totally
answer
on
my
own
and
then
confirm
the
next
steps
for
going
to
implementable,
which
is
my
major
goal
here
so
yeah.
B
I
think
everybody
on
the
call
has
already
seen
this
slide
a
million
times,
but
if
you
haven't
been
following
about
cluster
id,
this
is
the
background,
but
what
I
think
is
outstanding
on
the
pull
request
right
now,
which
again
there's
a
new
one
linked
down
here
and
I
have
it
open
and
over
on
the
side.
In
case
you
need
to
reference,
it
is
how
exactly
do
we
associate
an
id
with
a
cluster?
How
do
we
associate
a
cluster
with
a
cluster
set?
B
How
do
we
deal
with
previously
isolated
clusters
joining
a
cluster
set,
which
we
had
punted
on
quite
a
bit
before?
Can
we
or
should
we
recommend
or
enforce
that
people
don't
drop
arbitrary
json
as
the
value
to
a
claim
either
one
of
our
well-known
ones
or
a
claim?
Somebody
just
makes
themselves
and
what
are
we
going
to
do
about
the
effect
of
uuids
versus
human
readable
names
for
cluster
id
on
dns,
at
least
within
this
cap?
Do
we
need
to
address
it
within
this
cap
or
or
not?
B
It's
come
up
a
little
bit
in
the
prior
iteration,
so
this
is
kind
of
a
lot
of
things
and
I
do
have
individual
slides
here
with
my
takes,
and
I
would
like
to
go
through
them
one
by
one.
If,
if
we
can
and
take
a
take
opinions,
this
first
one,
how
do
we
associate
an
id
with
a
cluster?
I
did
put
about
this
in
the
pull
request,
which
is
maybe
sufficient,
but
it
actually
came
up
today
when
I
went
to
sid
cluster
lifecycle.
B
The
question
of
what
obligation
might
cluster
lifecycle
platforms
have
to
create
this
id?
Is
that
something
that
you
know
we
should
be
discussing
now
that
we
should
explicitly
call
out,
besides
the
the
fact
that
we
think
it
could
be
creative
cluster
local,
especially
for
using
cube
system
id
like
do?
We
need
to
specify
who's
actually
doing
that,
and
is
there
any
other
tooling
that
we
expect
would
actually
make
this
idea
cluster
creation?
So
that's.
A
I
think
you
know
in
reading
your
draft,
I
think
you've
done
a
good
job
of
kind
of
setting
up
the
obligation,
which
is
like
you're
obligated
if
your
customers
expect
to
be
using
the
cluster
id,
but
I
don't
think
you
know
we're
we're
mandating
we're
saying
you
know.
Ideally
this
this
id
would
eventually
exist
in
all
clusters.
That
seems
pretty
useful,
but
I
don't
think
we're
making
any
really
strong
statements
about
that.
So
I
think
you
know
our
answer
might
be.
A
You
know
no
answer
strong
suggestion
to
create
it,
but
no
no
mandates
and
then
in
terms
of
what
tooling
could
create
the
id.
I
think
we
we've
specifically
not
answered
that
right.
Right.
C
D
It
sorry
so
I
have
a
quick
question.
This
is
just
my
second
meeting,
so
maybe
I'm
just
catching
up
on
some
of
these
details.
So
the
idea
of
welcome.
Thank
you.
Thank
you,
the
idea
of
the
cluster
id.
This
is
the
same
thing
that
was
also
sent
out
as
a
survey
monkey
link
right
like
what
do
we
call
it
and
stuff
like
that
right,
yeah.
So,
yes,
the
notion
of
a
cluster
id
and
then
the
notion
of
cluster
sets
and
everything
is-
is
a
generic
thing
for
multiple
possible
multi-cluster
use
cases
correct.
D
B
Multi-Cluster
setup
and
relatedly,
for
example,
when
I
went
by
to
talk
to
cluster
api,
they
are
in
a
world
where
they
have
management
clusters
that
have
like
workload
clusters
for
cluster
api
and
that's
like
a
valid
use
case.
For
example,.
D
Got
it
all
right,
so
the
question
is:
if
you
have
multiple
clusters
and
some
of
them
may
be
in
existence
even
today,
how
do
you
assign
them
not
just
an
id
as
an
identifier
but
have
multiple
like
it
should
be
an
object
so
that
it
can
capture
multiple
different
configuration
details
of
what
the
cluster
has,
what
the
cluster
is
capable
of,
and
then,
if
multiple
clusters,
each
of
them
have
this,
you
can
put
them
all
together
as
a
set
of
clusters
and
then
do
other
interesting
solve
for
interesting,
multi-cluster
use
cases
after
that
correct.
B
I
think
mostly
correct.
I
got
a
little
lost
in
the
middle
there
about.
B
The
proposal
right
now
is
pretty
simple:
to
only
be
basically
the
name
of
the
cluster
which
our
official
recommendation
is,
it
should
probably
be
the
cube
system
namespace
uuid,
because
that
is
like
most
likely
to
be
globally
unique,
but
the
official
properties
that
we've
written
in
the
cap
don't
require
it.
Be
that
that,
specifically,
that's
just
our
recommendation
and
yeah.
The
actual
storage
is
just
the
crd.
That's
proposed
is
just
that
one
value
and
not
any
any
other
information
it
attached
to
like
that.
B
One
object,
and
then
the
cluster
set
would
also
be
just
a
simple
name
as
my
my
proposal
as
well
too,
but
I
think
one
thing
to
your
general
point
to
your
more
general
point
about
more
complicated
information.
We
do
leave
room
for
users
to
add
any
arbitrary
objects
into
the
same
cluster
claim
crd.
That
could
be
other
information
and
that's
kind
of
like
the
stop
gap
for
if
they
wanted
to
have
other
configuration,
but
we
just
described
like
the
minimal
thing
that
we
think
people
need
for
our
multi-cluster
use
cases
got
it.
G
B
My
guess
is
that
they
kind
of
serve
a
different
purpose,
but
I
do
know
that
one
of
the
things
that
attracted
cluster
api,
for
example
to
this
proposal,
was
as
a
admin
of
lots
of
clusters
that
are
being
created
through
cluster
api,
in
whatever
context
that
you're
in
you
can
just
do
a
quick
like
cube,
ctl,
git
cluster
claim
idkates.io,
and
you
know
where
you
are
and
that
it's
like
easy.
So
I
think
from
an
administrator
and
context
perspective
that
might
be
related,
but
I
think
for
the
multi-cluster
services
purposes.
B
E
I
think
the
idea
of
linking
it
to
contexts
is
is
interesting,
but
it
requires
some
active
process
to
either
fetch
all
of
the
ids
from
all
of
the
clusters
in
a
set
or
some
sort
of
gateway.
That
would
translate
those
into
actual
api
endpoints,
but
I
think
it's
an
interesting.
B
C
Sure-
and
I
was
of
course
joking
about
having
the
last
word,
but
so
I
I
think
to
me
the
the
primary
decision
that
we
should
make
is
like
you
absolutely
have
to
have
a
cluster
id
to
be
part
of
a
cluster
set
and
even
though
we're
agnostic
on
how
this
will
use
them,
we
don't
want
to
make
like
hard
dependencies
into
cluster
id
like
we
want
things
to
depend
on
cluster
id
cluster
set
is
like
kind
of
one
of
the
main
ideas
that
is
connected
with
this.
C
So
I
guess
the
question
is:
do
we
think
it
should
exist
before
you
join
a
cluster
set?
It
absolutely
has
to
exist
for
you
to
join
a
cluster
set
or
to
be
part
of
a
cluster
set.
I'm
I'm
hearing,
and
maybe
I
heard
it
wrong,
but
what
I
heard
so
far
is
that
we
think
it's
useful
to
have
before.
C
Is
that
accurate
like
it
should?
It
should
exist
to
be
the
most
useful,
just
naturally,
whatever
that
means.
B
C
Yeah,
I
I
think
I
agree,
and
so
my
gut,
like
my
kind
of
intuitive
version
of
what
I
think
that
would
mean,
is
that.
C
A
thing
that
might
be
useful
would
be
a
controller
that
initializes
it
from
the
the
the
namespace
of
the
or
sorry
the
uid
of
the
the
of
the
default
namespace.
Or
is
that
the
right
one?
Sorry
I'm
a
little.
C
So
a
controller
that
initializes
it
based
on
that,
I
think,
would
be
a
useful
piece
to
have,
and
maybe,
if
you
don't
want
that
behavior,
if
you
want
to
initialize
it
some
other
way,
you
can
disable
that
controller.
B
Yeah,
I
think,
to
combine
both
of
these
for
the
immediate
term.
I
think-
and
by
both
of
these
I
mean
what
jeremy
was
saying
earlier.
Maybe
we
don't
need
to
explicitly.
You
know
mandate
that
in
the
cab,
maybe
we
can
mention
it,
and
I
do
think
we
have
sort
of
consolidated
around
it.
Probably
existing
could
exist
before,
but
I
won't.
B
I
won't
plan
to
make
a
really
strong,
like
this
must
be
implemented
by
a
independent
controller
that
you
know
is
runs
before
this
or
runs
before
that
or
sid
class
or
cluster
life
cycle
managers
need
to
make
sure
that
they
make
this
cluster
id
blah
blah
blah.
I
don't
think
we're
that
far
yeah.
A
A
But
I'm
also
thinking
about
this
from
the
context
of
someone
who's,
you
know
got
clusters
and
or
they've
got
a
cluster
and
they're
just
entering
into
the
multi-cluster
world,
and
you
know
they've
ignored
everything
that
we've
ever
said
until
that
point,
and
so
you
know
we
give
them
the
easy
onboarding
so
like
the
mandate
that
it
must
exist
to
be
a
part
of
a
cluster
set
like
that's,
that's
the
must
and
then
but
it
should.
We
should
always
have
an
id.
C
Built
in
yeah
and
here's
a
little
here's,
a
little
brain
teaser
say
that
it's
built
in
yeah
on
the
on
the
theme
of
riddles:
here's,
here's
a
in
trivia
and
thought
puzzles,
here's
one!
So
if
we
get
it
built
in
what
does
it
mean
for
clusters
that
are
older
than
the
first
version
where
it
shows
up,
do
you
define
a
crd
and
use
it
that
way.
B
Yeah,
this
feels
kind
of
related.
Maybe
this
is
a
good
segue
into
I'm
skipping,
one
kind
of,
but
there's
these
there's
a
point
of
how
do
we
associate
a
cluster
with
a
cluster
set
and
also
how
to
deal
with
previously
isolated
clusters
joining
a
cluster.
B
E
D
So
how
what
would
the
sequence
of
events
be?
So
let's
say
I
have
five
clusters:
do
I
go
and
whether
it
is
manually
install
a
crd
or
run
a
controller
that
installs
a
crd,
and
that
creates
maybe
a
cr
in
each
of
these
five?
Let's
say
I
want
my
ultimate
objective.
Is
all
these
five
clusters
together
should
form
one
cluster
set?
D
So
do
we
go
ahead
and
one
way
or
the
other
install
a
cluster
id
cr
in
each
of
these
five
clusters
and
then
install
one
or
not
install
but
create
one
cluster
set
custom
resource
in
one
of
these
five
clusters,
or
do
we
create
the
cluster
set
in
all
five
questions?.
D
B
B
Yeah
only
the
first
part,
they
don't
know.
Who
else
is
that
stored
in
this
crd?
They
don't
know.
Who
else
is
there?
Oh.
B
Yeah-
and
this
is
the
the
words
I
have
used
basically
in
the
in
the
pr
right
now
to
describe
this-
is
basically
just
like
mcs
controller,
which
is
defined
in
the
mcs
api
as
something
that
has
knowledge
of
all
the
clusters,
but
could
just
be
a
person
running
cube.
Cuddle
should
figure
it
out.
Basically,
but
I
don't
know
if
we
need
to
be
a
bit
more
detailed
in
this
cap.
F
H
B
Yeah
we
have
purposefully
put
that
in
non-goals.
For
now
it
did
come
up
on
the
original.
Pr,
though-
and
I
think
we
talked
about
it
briefly
like
a
couple
weeks
ago-
or
maybe
it
was
even
in
the
end
of
december,
but
it
has
been
asked,
but
we
have
respectfully
declined,
I
think
for
now,
but.
A
I
think
we
actually
talked
about
this
a
few
times.
You
know
starting
back
with
multi-cluster
services
api
and
even
when
we
were
just
discussing
like
the
principle
of
namespace,
sameness,
yeah
and
since
since
the
properties
of
become
belonging
to
a
cluster
set
are
transitive.
Then
then
you
can't,
it
doesn't
seem
like
you
could
really
have.
A
cluster
belong
to
multiple
cluster
sets
without
kind
of
requiring
that
those
cluster
sets
are
one
cluster.
H
The
name
space,
sameness
angle
of
things
leading
to
that
yeah.
B
And
I
think
whenever
we
talked
about
it
most
recently
when
I
was
present,
we
kind
of
were
talking
about.
Oh,
if
we
think
of
this
as
like
the
venn
diagram.
Actually
it's
that,
like
you
know,
we,
we
filled
the
paint
until
both
sides
of
the
venn
diagram
they're.
Actually
just
the
same
group
now.
H
C
B
All
right
well
to
bring
this
back
to
the
current
point.
I
think
we
agree
that
there
is
some
mcs
controller
above
the
cluster
local
boundary,
who
needs
to
figure
out
stuff
about
whether
a
cluster
can
be
associated
with
a
cluster
set.
B
Is
there
any
more
conversation
about
any
more
specifics
of
how
we
want
to
deal
with
previously
isolated
clusters
joining
a
cluster
set?
I
think
you
know
if
the
cluster
id
is
really
like
unique
beyond
the
boundary
of
all
cluster
sets,
then
it's
easy,
but
since
we
don't
prescribe
that,
then
it's
possible
that
a
cluster
could
get
rejected
when
it
tries
to
join
a
cluster
set,
and
is
there
like
a
flow
we
think
is,
is
likely
or
relevant
here
that
we're
imagining.
C
Yeah,
I
think
that
I
think
that
we're
in
a
way
we're
kind
of
describing
some
of
the
cluster
set
behaviors
and
maybe
the
boundaries
a
little
hazy.
But
I
would,
I
think,
one
thing
that
we
could
define
is
what
happens
if
you
try
to
join
a
cluster
set
where
the
cluster
id
appears
to
already
be
in
the
set
right.
F
As
a
thing
that
we
could
try
to
solve,
I
think
that
is
a
case
that
covers.
C
Yeah,
I
do
think
that
another,
like
form
of
this
case
is
the
one
where
is:
is
the
one
where
cluster
id
is
part
of
the
kk
api
and
in
the
sense
that,
like
cluster
claim
or
cluster
fact
or
whatever
is,
and
what
does
that
mean
for
clusters
that
are
older?
If
the
answer
might
be
that
it
means
that
you
can't
use
it
like.
I
don't
know
that
that's
the
best
answer,
but
it's
an
answer
another
one
might
be.
C
You
know
like
we
could
publish
a
crd
and
a
controller
that
populates
that
crd
for
people
to
run
in
their
clusters.
So
that
seems
like
it's
a
related
question.
That's
very
much
in
the
neighborhood.
E
B
E
C
C
Could
it
could
check
for
that
and
populate
it
if
you're
already
using
the
crd,
you
upgrade
into
a
version
that
has
it
in
kk
populate
it,
there
have
the
one:
that's
in
kk
take
precedence,
and
maybe
if
we
want
to
just
like
absolutely
over
engineer
this
thing,
five
nines
of
over
engineering
it
could
it
could
like
self-destruct,
the
crd1
after
you
install
or
after
it
comes
online.
I
don't
know
something
like
that.
H
Yeah
we
did
something
similar
when
we
migrated
from
our
own
service
discovery
apis
to
the
mcs
apis.
So
we
had
a
controller
that
just
to
the
old
api,
whenever
an
object
was
created,
it
created
the
new
one
deleted
the
old
one
and
then
the
the
existing
well,
the
the
the
real
behavior
was
just
mapped
to
the
new
trd,
and
that
worked
quite
well.
H
So
old
code
could
create
well
yeah,
so
this
works
for
stuff,
that's
create
only
then
you
need
web
hooks
for
other
stuff.
Probably
that's
great.
D
A
I
don't
know
that
we're
actually
relying
on
any
specific
kk
behaviors
I
mean
there's
like
guaranteeing
that
it
always
exists
with
the
yeah
with
the
uid
of
the
cube
system.
If
we
wanted
to
be
that
prescriptive
seems
like
that
would
be
easiest
to
implement
entry,
because
what
you
can
do
with
with
kk
resources,
there's
a
lot
more
flexibility
than
crds,
but
I
don't
know
that
like
for
the
for
the
most
part,
I
mean
it's
such
a
simple
resource.
I
don't
know
that
it
really
needs
that
it
matters
yeah.
D
Is
there
any?
Is
there
a
precedence
on
something
that
originated
as
a
separate
thing,
but
the
controller
eventually
got
merged
with
the
core
kubernetes
components?
Because
if
we,
if
that
happens,
then
I
guess
this
problem
could
be
solved
right
where
it
starts
off
as
a
crd
and
controller
and
people
need
to
explicitly
install
those.
But
at
some
point
when
it's
mature,
the
controller
kind
of
code
starts
merges
with
the
rest
of
the
core
kubernetes
components.
D
E
No,
I'm
I'm
racking
my
mind,
but
I
I
don't
think
that
we've
done
that.
B
E
B
C
That's
sort
of
the
reason
why
crds
were
created
yeah,
so
not
not
exactly,
but
it's
sort
of
like
it's
it's
connected
with,
but
yeah.
D
C
Question
to
ask:
I
mean
yeah.
D
D
E
A
E
Api
server,
I'm
yeah
so
then
how's
it
upgraded.
When
the
new
api
server
comes
online,
it
sees
a
new
version,
but
then
you
have
multi
multi
instance
control
planes.
So
are
you
going
to
fight
over
it,
or
are
you
always
going
to
be
only
moving
forward
like
it
has
been
discussed?
There
are
some
bumps
that
haven't
really
been
solved
and
honestly.
B
E
A
Right
and-
and
I
think
actually,
this
is
one
of
the
reasons
why
we
dropped
that
approach
for
for
mcs,
at
least
for
now,
and
just
kind
of
went
straight
out
of
tree,
because
yeah
there's
some
open
questions,
but
it
it
does
seem
like
assuming
we
could
solve
those
questions.
You
know
that
that
would
solve
the
other
problems
with
with
traditional
kk
not
being
able
to
coexist
with
crds
and
whatnot.
C
Yeah,
I
think
so
tldr
my
position
on
that
is.
We
totally
could
do
that.
We
could.
We
could
try
to
be
the
driving
force
to
sort
out
within
sig
arch
how
to
handle
entry
crd
apis.
We
absolutely
could
do
that
or
we
could.
We
could
just
say
for
now,
as
one
other
possibility,
not
the
only
one,
but
another
choice
we
could
make
would
be
to
say
that
that
we're
just
not
going
to
worry
about
it
for
now
and
we're
going
to
concentrate
on
getting
something
into
an
alpha
state.
C
That's
an
entry
api
and
we
could
see
what
demand
there
is,
and
you
know
decide
if
we
need
to
handle
that
problem
in
the
future.
I
think
a
fall
back
could
be
that,
like
maybe
there's
a
maybe
there's
a
crd
version
that
you
can
run
in
older
clusters,
and
maybe
that
crd
version
like
is
sensitive
to
the
cluster
version
and
stops
working
and
tells
you
it
stops
working
when
it
it
finds
when
it
finds
the
entry
api,
but
we
kind
of
we.
C
You
know
we
sketched
out
some
of
those
precedent,
mechanics
what
they
might
look
like
in
in
our
discussion
here
today.
So
I
think
that
could
be
a
fallback.
My
gut
would
be
that
like.
If
we
want
to
solve
entry
crds,
that's
probably
a
much
larger
problem
space
than
what
we're
actively
working
on
and
I
would
be.
B
All
right:
well,
let's
table
that
one
for
now.
I
think
what
I'm
getting
from
the
question
about
how
do
we
associate
a
cluster
with
a
cluster
set
specifically,
is
I
think
this?
What
happens
if
you
try
and
join
a
cluster
set
where
the
cluster
appears
to
already
be
in
the
set?
Is
the
good
platonic
case
scenario
to
describe,
and
then
I
can
take
a
stab
at
it
and
then
maybe.
C
Yeah,
I
I
think
that
if
we
say
that
we're
going
to
focus
on
like
getting
something
intrigued
to
alpha
and
that
will
handle
older
clusters,
that
may
not
have
the
entry
api
in
the
future.
That
would
be
a
fine
thing
to
say,
but
it
absolutely
does
deserve
explicit
treatment
in
the
cap.
E
E
C
My
own
answer
to
that
off
the
top
of
my
head
is
that,
if,
if
it
is
a
crd
like
you
now
need
to
make
a
choice,
how
are
you
going
to
release
that?
Are
you
going
to
release
a
chart?
Are
you
going
to
release
a
bunch
of
yamls
like
how
are
you
going
to
release
it
and
what's
the
best
way
to
do
that?
C
That
has
the
widest
spread
of
people,
but
is
also
that
that
can
use
it
or
won't,
have
to
make
a
new
choice
in
order
to
use
your
installation
method
and
that
you
can
just
completely
short-circuit
that
question
by
being
in
tree,
but
yeah
my
own
top
of
the
top
of
the
head
gut
answer.
I
don't
know
if
that
makes
sense.
D
The
other
thing
that
also
comes
with
a
crd
is
the
entire
management
cycle
of
it.
So
this
installation
is
one,
but
then
you
also
have
to
make
sure
that
you
keep
up
upgrading
it,
especially
if
it
in
some
way
ties
to
the
kubernetes
version.
So
if
you're,
if
someone
upgrades
the
cluster,
then
you
also
have
to
make
the
same
make
sure
that
the
crds
and
the
controllers
are
upgraded
in
some
corresponding
fashion.
If
there
are
things
that
you
need
that,
and
then
it
just
adds
more
complexity.
D
D
E
So
I'm
not
sure
that
there's
going
to
be
much
by
the
way
of
activecontroller
here,
nor
much
by
way
of
schema
change
over
time
like
we're
intentionally
scoping
this
down
to
like
one
single
data
point
right,
so
some
of
those
issues
are
somewhat
mitigated.
Now.
Those
are
famous
last
words
and
it's
that's
never
blown
up
in
anybody's
face
before
I
there
is
there
isn't
a
good
migration
path,
like
other
than
just
saying,
like
the
alpha,
doesn't
work
anymore
and
don't
upgrade
your
cluster.
E
If
you
have
the
alpha
version
like
I,
I
don't
honestly
know
what
happens
if
I
install
an
api
group
as
a
crd,
and
then
I
upgrade
my
cluster
to
a
version
that
has
one
that's
a
built-in
like
that
upgrade
path,
I
think,
is
just
untrodden.
B
B
Now,
it's
like
crd
entry,
crd
concept,
two,
so
I
don't
think
we'll
100
solve
it
today,
but
this
is
some
good
notes
for
me,
and
hopefully
I
can
synthesize
this
together
to
address
this
concern
from
an
implementation
perspective.
B
Is
it
all
right
if
I
move
on
to
the
next
one,
unless
anybody
has
more
strong
guessing?
I.
C
Guess
the
only
thing
that
I'll
point
out
is,
I
think
I
think
this
is
like
the
choice
we
make
around.
This
is
important.
C
Whatever
choice
we
make
isn't
really
permanent
until
it
goes
to
something
more
mature
than
alpha
so
like,
I
think,
sometimes
also
when
you
make
that
like
choice,
you
immediately
are
like
I've
made
a
terrible
mistake
so
like
we
don't
need
to
to
overthink
it.
Maybe
we
can.
Maybe
we
can
do
a
poll
type
thing
and
see
what
people
find
most
appealing,
but
let's
just
remember
that
we
have
the
ability
to
like
reevaluate
any
decision
that
we
make
there,
so
it
let's
not
make
it
a
block
like
thing
that
blocks
us.
Okay,.
B
Okay,
cool
I've
got
two
more
questions
which
I
think
are
a
little
easier.
Can
we
or
should
we
recommend
or
enforce
that
people
don't
drop
arbitrary
json
as
a
value
to
a
claim
either
well-known
or
custom
user
claim.
B
So
I
think
we
think
these
will
be
short
comparatively
short
strings,
but
someone
else
brought
this
up
that
this
is
a
risk.
I
guess
with
our
very
general
schema.
B
So
I
think
there's
some
options
of
increasing
severity
here,
but
I'll
take
thoughts
on
this.
C
Well,
this
this
actually
connects
with.
Like
the
last
decision.
We
are
kind
of
circling,
so
if
we,
if
we
want
to
use
a
crd-
and
we
want
to
keep
the
the
like-
the
the
distribution-
pretty
easy
like
you
know,
ideally
we
have
like
a
couple
yamls.
If
we're
choosing
a
crd,
it
means
that
we
are
would
be
really
smart
to
stick
with
what
open
api
schema.
C
Validations
can
give
us
rather
than
having
to
have
an
emission
web
hook,
because
as
soon
as
you've
got
an
emission
web
hook,
you
got
an
api
service,
got
a
deployment.
You
got
a
service,
you
got
all
kinds
of
stuff.
C
So
if
we
want
to
have
like
the
as
the
severity
like
as
you
go
further
down
the
severity
spectrum
or
up
or
whatever
the
complexity
of
the
thing
also
will
tend
to
increase,
so
we
should
think
about.
Like.
Are
we
comfortable
with
what
crd
schema
validation
could
give
us.
A
Yep,
I
couldn't
agree
with
that.
More
also
in
terms
of
enforcing
like
not
dropping
arbitrary
json,
like
I
think,
having
arbitrary
json
in
a
claim
is,
would
be
gross
personally
and,
and
you
know
not
the
best
experience
for
someone
who's
like
listing
claims.
But
what
is
like?
What's
really
wrong
with
it?
You
know
if
it's
that
we
don't
like
it.
That's,
like
you
know,
there's
arbitrary,
json
kind
of
all
over
the
place.
A
People
stick
json
in
annotations,
like
I
think,
like
there's,
there's
valid
reasons
to
do
that,
and
it
solves
real
problems,
but
also
not
allowing
json
doesn't
allow
it
doesn't
prevent,
like
you
know,
base64,
encoded,
json
and
all
kinds
like
someone
can
find
if
they
want
to
stick
garbage.
E
A
They
can
work
around
it
and
json
is
cleaner
than
base64
included
json.
So.
B
B
C
E
I
wasn't
gonna
pin
that
on
you
paul,
but
but
you're
right,
it's
your
fault.
I
didn't
say
it
was
my
fault.
I
said
I
did
the
work.
I
I'm
pretty
sure
that
I
collaborated
in
that
mess
yeah.
E
But
I
I
agree
here:
I'm
not
sure
that
being
super
duper
restrictive
is
actually
going
to
be
helpful.
We
can
define
what
we
think
the
well-known
names
have
for
values,
but
at
the
end
of
the
day
you
have
a
resource
like
maybe
we
put
a
size
cap
on
it,
but
that's
probably
it
right.
B
B
Great
all
right,
and
then
the
last
one
I
have
here
is:
what
are
we
going
to
do
about
the
effect?
B
This
was
pulled
from
some
of
the
comments
on
the
prior
pr
of
uids
versus
human
readable
names
for
cluster,
for
the
cluster
id
specifically
and
in
particular,
people
were
worried
about
it
for
dns
and
at
least
within
this
cup
I
feel
like
we
could
say
it's
out
of
scope
for
this
one.
B
We
could
bring
up
that.
We
think
aliases
should
be
a
thing
later,
because
that's
come
up,
we
could
describe
aliases
in
more
detail,
and
then
I
have
some
questions
of
what
people
think
that
might
ever
look
like
if
we
were
talking
about
that
now,
but
I
don't
know
which
level
of
severity
we're
on
for
this.
A
One
would
skew
heavily
towards
saying
it's
out
of
scope
like
uids
are
not
the
most
human
friendly,
but
you
know
we.
We
do
leave
the
door
open
for
human
friendly
names,
but
aliases
are
a
whole
topic
and
everybody
has
their
own
opinions
and
I
think
like
we
should.
We
probably
do
need
to
discuss
that,
but
we
can
do
so
entirely
separately.
I
also
think
that's
a
big
part.
G
E
B
This
all
right,
so
I
continue
trudging
along
towards
implementable.
The
definition
of
implementable
is
that
the
approvers
have
approved
this
cup
for
implementation,
so
it
has
its
definition
in
it,
but
I
think
the
next
steps
I'm
going
to
update
the
pull
request
with
what
we
just
discussed,
I'll
solicit
and
wait
for
comments,
especially
around
this,
how
to
deal
with
previously
isolated
clusters
in
a
cluster
set
and
resolve
them
and
eventually
get
paul
to
approve
me.
B
And
then
this
is
a
bit
more
future
thinking.
But
I
think
this
is
where
we
would
be
going
after
at
some
point,
I'm
just
trying
to
queue
myself
up.
This
might
be
getting
a
little
ahead
of
myself
and
especially
since
we
were
just
talking
about
intrigue
so
much
so
maybe
this
isn't
even
worth
talking
about
now,
but
this
is
what
I
think
happens
after
that
at
some
point.
C
Yeah,
I
think
I
think
those
are
right.
I,
like
I,
like
the
the
reference
with
the
question
marks
and
profit
right.
I
think
we
got
a
lot
closer
to
implementable
today.
I
see
I
see
the
central
question
being.
Do
we
want
entry
or
out
of
tree,
and
one
thing
that
I'll
just
note
is
that,
like,
I
think
we're
writing
a
cap,
because
we
expect
this
to
be
entry
and
so
I've
kind
of
had
that
expectation
present.
C
My
gut
says:
that's
probably
the
best
way
but
like
maybe
maybe
we
can
all
chat
and
sing
multi-cluster
about.
How
do
we
want
to
make
that
decision.
C
F
C
B
C
B
Something
about
like
like
polling
or
some
sort
of
like
democracy,
about
this
too.
That
is
a
possible
route,
but
I
think
we
would
at
least
need
to
articulate
all
the
pros
and
cons
of
our
options
so
that
people
could
make
an
informed
decision.
E
A
Yeah
I,
but
I
also
want
to
call
out,
I
think,
last
time
we
discussed
this
too,
because
this
is
kind
of
a
hard
dis
decision
and
one
of
the
one
of
the
things
we
came
up
with
was
like.
If
other
people
want
to
use
it
like.
If
we
go
to
say
cluster
lifecycle
and
they
want
to
use
it,
then
entry
probably
makes
more
sense
and
laura.
You
went
to
say
cluster
life
cycle
and
they
want
to
use
it
right.
B
Yeah
I'm
happy
to
go
around
to
some
more
too
I
mean
I
did
get
that
some
names
of
other
cigs
that
maybe
would
be
interested.
I
need
to
check
my
notes,
but
if
we
want
more
info,
I
guess.
C
Okay,
I'll
throw
out
something
that
I
can
be
a
useful
way
to
provoke
a
response.
C
C
So
here's
the
method
is
sometimes,
if
I'm
trying
to
pick
between
two
things,
I
will
go
open.
My
internet
web
browser
and
go
on
over
to
random.org,
and
I
will
pick
one
of
the
coin
flips
and
I
will
flip
three
or
five
coins,
call
it
in
advance
and
that's
the
decision
and
sometimes
like
just
making
that
decision.
Even
if
it's
like
you,
just
let
atmospheric
noise
or
whatever
random.org
uses
to
see
their
number
generators
with
like
make
it
for
you,
people
suddenly
have
a
strong
opinion.
C
C
It's
super
quick.
The
the
work
api
repo
was
created.
I've
been
asked
asked
trojan
to
translate
his
doc
into
a
mark
down
there.
So
we
can
start.
You
know
adding
details
and
asking
ourselves.
Is
that
implementable
enough
to
to
put
some
code
behind
eof.