►
From YouTube: Kubernetes SIG Multicluster 2020 September 1
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
B
A
A
A
Do
we
have
herman
here.
A
A
A
Yeah,
I
don't
know
it
doesn't
look
like
we
have
herman
here
yet
who
is
going
to,
I
think,
present
the
multi-cluster
robot
project.
C
C
Okay,
maybe
we
give
it
a
few
minutes
for
herman
and
maybe
in
a
couple
minutes
we
can
just
like
talk
about
some
of
the
use
cases
that
are
in
cluster
registry
doc
and
maybe
herman
can
demo
in
second
half,
if
he's
not
on
by
then
sound
okay.
C
All
right:
well,
why
don't
we
just
go
ahead
and
and
talk
about
some
of
those
use
cases
that
are
in
that
dock.
I
know
that
you
put
a
couple
in
there,
jeremy
stephen.
I
saw
that
you
put
one
in
there
too.
I
dropped
one
in
there
and
we
can
just
keep
in
mind
that
maybe
we're
time
boxing
that
for
now
you
know
if
herman
winds
up
showing
up
yeah.
That
sounds
good.
Do
you
want
to
share
it
or
yeah?
C
A
So
yeah,
I
think
the
first
couple
I
kind
of
put
in
as
as
conversation
starters
in
that
dock
and
they're,
really
just
things
that
we've
talked
about
a
lot
in
the
evolution
of
multicluster
services.
A
The
primary
one
is,
I
think,
the
the
most
straightforward
thing
in
a
cluster
register,
which
is
identification
so
or
at
least
it
sounds
the
most
straightforward.
So
in
the
past
there
was
a
lot
of
talk
around
a
cluster
id
concept
and
what
that
could
look
like
in
various
requirements.
A
I
think
that
may
have
been
happening
before
we
really
had
specifics
goals
or
specific
goals
that
we
want
to
accomplish
with
that.
So
now,
now
we
do
with
multi-closer
services
and
there's
there's
a
couple
straightforward
ones
like.
Obviously
I
need
a
unique
identifier
for
for
a
cluster
for
to
for
me
to
know
how
to
reference
it
and
then
with
mcs.
We
kind
of
saw
the
evolution
of
of
the
need
that
it
be
a
valid
dns
label.
A
So
there's
a
requirement,
but
beyond
that,
I
think,
there's
a
lot
of
room
to
figure
out
what
that
could
actually
look
like,
but
to
have
a
cluster
registry.
It
seems
like
you,
probably
need
some
kind
of
cluster
id,
but
I
I
want
to
make
it
clear
that
that
may
be
separate
from
the
previous
cluster
id
concept
and
and
some
of
the
ideas
there.
Although
I
think
there
was
a
lot
of
good
thought
that
went
into
that
as
well
and
then
the
other
thing
I
think
is,
is
also
pretty
straightforward,
which
is
access.
A
You
know,
if
you
have
a
cluster
register,
you
want
a
way
to
actually
use
that
to
gain
some
kind
of
access
to
to
each
cluster
in
the
registry
with
some
set
of
permissions.
But
I
think
steven
do
you
wanna.
Do
you
wanna
talk
about
the
ones
that
you
added,
because
I
think
that
gets
a
little
more
interesting.
D
Yeah,
so
I
sort
of
ripped
off
yours,
jeremy,
editor
on
access
control,
but
thinking
about
things
that
we've
been
wondering
about
in
in
submariner
as
well.
So
as
a
cluster
state
owner,
I
want
to
know
who
or
what
can
access,
cluster
information
and
add,
update
or
delete
clusters
from
the
clutter
sets.
D
So
that's
basically
just
thinking
about
well
general
access
control,
but
what's
it
can
be
actually
useful
for
then,
as
a
controller
developer,
I
want
a
way
for
each
of
the
clusters
in
my
cluster
set
to
access
the
cluster
registry
and
yeah,
and
so
this
is
right.
So
this
is
the
inverse
of
euroaxis
point
above
and
here
this
is
more
so
thinking
about
high
availability
as
well
in
terms
of
the
cluster
registry.
D
If
the
cluster
registry
moves
around,
then
we
need
to
ensure
that
all
the
clusters
in
the
cluster
set
can
always
access
the
cluster
registry,
and
so
that
might
mean
so.
I
don't
think
it
should
involve
providing
access
to
all
the
potential
cluster
registry
hosts
to
all
the
clusters
in
the
cluster
set,
but
it
does
mean
finding
some
way
of
passing
credentials
around
in
a
secure
way.
C
Works
so
I
was
just
going
to
ask
a
question
about
that
is
I
suspect,
from
like
my
previous
context
on
this,
that
on
that
second
bullet,
that
you
put
on
there
steven
that
there
might
be
a
number
of
people
that
have
something
that
they
would
word
that
way,
but
it
might
be
different
from
someone
else.
So
I
wonder
if
you
might
be
able
to
maybe
add
some
more
details
around,
like
the
specific
use
case
facing
you
at
this
point.
D
Yeah,
so
this
is
based
on
a
submariner
really
where
we
have
a
broker,
which
is
effectively
a
cluster
registry.
D
D
Any
member
of
the
cluster
set
can
become
the
broker.
The
only
requirement.
D
A
So
I
guess
another
question
on
that,
so
that
that
explanation
makes
a
lot
of
sense.
But
conceptually
I'm
kind
of
wondering
like
in
this
case
is
the
broker
just
happening
to
play
two
roles.
Is
it?
Is
it
really
so
much
that
each
cluster
needs
to
access
the
cluster
registry
or
that
the
the
cluster
registry
needs
to
provide
each
cluster
with
access
to
to
the
broker,
which
happens
to
be
the
same
thing
in
this
implementation,
but
but
may
not
be.
B
D
This
old
federation
model,
whereas
we
have
it's
all
going,
the
other.
A
Way
around
so
so
in
my
in
in
the
few
items
I
had
actually
I
didn't-
I
didn't
really
specify
that
or
or
how
that
would
work
at
all
to
me,
the
cluster
registries,
the
only
the
only
thing
that
is
absolute
or
seems
absolutely
obvious
in
all
cases
for
the
cluster
registry
is
that
it
needs
some
way
of
providing
access
to
clusters.
I
don't
know
that
it
actually
needs
to
ever
connect
to
those
clusters
right.
A
It
can
just
be
a
essentially
a
store
of
credentials
and
addresses
for
for
clusters,
probably
with
some
other
metadata
that
that
we
need
to
figure
out,
but
I
don't
know
that
it
necessarily
needs
to
talk
to
each
cluster.
You
know
that
you
know
we
there's
some.
A
B
A
Api
and
obviously
with
federation,
then
you
do,
but
I
don't
think
that's
that's
a
property
of
the
registry
itself.
So.
C
I
think
just
to
call
out
something
that,
like
jeremy,
you
touched
upon,
I
suspect,
there's
probably
like
two
broad
categories,
at
least
of
like
how
people
think
about
something
that
they
would
call
cluster
registry,
and
maybe
one
category
might
be
it's
sort
of
like
a
shared,
well-known
location
to
write
things
down,
but
it
doesn't
necessarily
have
any
behavior
itself
or
has
very,
very
minimal
behaviors
itself
and
absolutely
like
it's
it's
not
in
this
document
yet,
but
another
kind
of
well
might
be
getting
there
touch
it
in
some
ways,
but
another
kind
of
bin
of
how
I
would
see
people
seeing
cluster
registry
is
that
might
mean
to
them
both
the
like
sort
of
a
super
set
of
the
first
category,
where
the
extra
content
is
like
I've
got
a
way
to
push
content
to
each
cluster.
C
That's
registered
or
I've
got
a
way
to
pull
content
into
each
cluster.
That's
registered,
that's
you
know,
scheduled
or
coordinated
in
terms
of
the
registry.
If
that
makes
sense
so
like
work,
api
might
be
an
example
of
one
it's
a.
I
just
call
it
out
because
it's
a
gray
area-
and
it's
like
one
of
the
the
key
differences
that
that
is
evident
to
me
and
how
people
think
of
it
from
the
past.
C
D
Your
broker
case
this,
the
sort
of
the
former
the
broker
is
just
a
that's
just
crds
in
a
kubernetes
cluster
somewhere
and
there's
no
no
behavior
in
it.
It's
just
data,
but
that's
actually
so
jeremy,
that
your
point
about
the
access
credentials.
That's
that's
something
interesting.
I
hadn't
thought
about
having
the
access
credentials
in
the
cluster
registry
itself,
yeah
that
would
simplify
things.
A
lot.
C
So
going
back
to
that
one
about
credentials
in
the
registry,
there's
there's
a
it's
one,
it's
another
one
of
the
use
cases
that
I
think
seems
to
make
sense,
but
gets
harder.
The
more
you
think
about
it.
So
when
we
say
access
credentials,
do
we
mean
cluster
route?
Do
we
mean
by
service
account?
C
Do
we
really
mean
a
token?
Do
we
really
mean
credentials
exactly?
What
do
we
mean
and
for
who
to
do
what.
C
So,
for
example,
the
way
we
captured
it
here
like
access
credentials,
I
think,
might
mean
to
some
folks.
It
might
mean
literally
you've
got
like
cluster
root
credentials
hanging
out
in
a
registry,
and
it
might
also
mean
to
someone
else
like
there's
a
flow
that
I
can
do
to
request
the
permissions
that
I
need,
and
maybe
I
get
a
service
account.
C
So
I
think
it's
totally
okay
at
this
point
to
have
like
the
level
of
detail
that's
in
here,
but
I
think
part
of
being
successful
in
building
something
that
will
like
fill
a
need
for
people
is
to
get
very
detailed
about
what
exactly
that
means
to
people-
and
you
know
just
just
like
we
all
have
different
perspectives.
There's
probably
some
things
also
that
some
people
might
say.
I
need
this
and
other
people
might
say.
I
could
never
do
that,
because
I
have
a
security
problem
with
with
it
or
whatever
makes
sense.
A
Yeah,
I
I
mean
to
start,
I
think,
probably
requiring
that
this-
that
there's
something
out
there
that
gives
root
to
every
cluster
is
maybe
not
the
best
place
to
start,
but
I
think
it
would
be
good
to
have
people
add
their
use
cases
absolutely
here,
because
I
mean
obviously
that's
what
this
doc
is
all
about,
but
specifically
for
for
credentials
and
and
what
they're
looking
to
do
like
steven
it
sounds
like
you've
got
some
specific
needs
there
versus
trying
to
decide
what
what
the
right
answer
is
for
that
kind
of
thing.
D
Well,
yeah,
we
didn't
really
start.
I
don't
think,
but
that's.
D
It's
just
it's
just
saying:
yeah
we
want
to
have
it,
so
I
guess
this
is
already
attaching
to
some
of
the
design
assumptions,
but
assuming
a
non-passive
cluster
registry,
then
we
probably
need
to
deal
with
setups,
where
the
cluster
registry
can
contact
the
clusters,
but
not
necessarily
the
other
way
around
and
the
opposite,
which
is
also
related
to
your
point,
paul
yeah.
C
You
know
one
thing
that's
related
to
that
is,
and
I
I
tried
not
to
dump
every
use
case,
I'm
aware
of
in
here,
but
it
it's
kind
of
coming
up
is
the
concept
of
wanting
to
understand
it's,
maybe
not
a
health
check,
it's
maybe
more
like.
When
was
the
last
time
I
was
able
to
heartbeat
from
a
registered
cluster
to
the
hub
in
a
kind
of
active
situation
like
the
second
bin,
where
it's
more
than
just
a
passive
list.
B
E
Right,
yeah
paul
when
you,
when
you
mentioned
you,
know
health
checks
and
stuff.
I
thought
about
the
work
that
I
don't.
I
don't,
of
course,
I'm
new
to
this
group
and
I
haven't
you
know
ramped
up
on
that
context,
but
the
work
done
by
virtual
cubelets
in
order
to
do
multi-cluster
that
way
right
because
it
very
much
does
sound.
Like
you
know
what
else
has
health
checks
right
nodes
have
health
checks
so
clusters
as
nodes
would
also
seem
like
it.
It
fits
that
that
use
case.
C
Yeah,
I
think
that's
a
good
analogy.
You
want
to
know
which
nodes
in
your
cluster
are
available
and
what
their
status
is.
It
makes
sense
that
you
want
to
understand
this.
The
overall
status
of
a
cluster
that
you
had
registered.
E
Yeah,
like
I
guess,
if
we
were,
I
mean,
of
course,
if
we
were
to
design
or
or
rethink
this
cluster
registry,
we
should
you
know,
compare
it
to
the
existing
work
of.
I
guess
how
other
people
have
looked
at
multi-cluster
services
or
multi-cluster
topologies
virtual
cubelet
definitely
does
seem
like
something
that
people
have
been
exploring
and
like.
C
Yeah,
I
think,
there's
also
probably
there
will
be
sort
of
analogs
or
precedents
that
we
can
look
to
for
patterns
around
how
things
work
in
cube
that
we
might,
you
know,
analogize
into
the
registration
concept.
C
Absolutely.
We
should
keep
an
eye
on
that
one
richard
while
you're
talking
and
you
got
a
hot
mic.
Do
you
want
to
talk
about
your
excuse
me,
your
use
case?
That's
in
the
stock.
E
Yeah
sure,
so
I
guess
this
really
came
from
our
you
know.
You
know
calling
back
to
my
presentation
a
couple
weeks
ago
about
how
you
know
the
idea
that
an
application
developer,
if
if
they
need
to
shouldn't,
should
be
sort
of
abstracted
away
from
the
cluster
topology
and
that
that
has
its
roots
and
sort
of
like
designing
a
good
blue-green
experience
for
a
cluster
rather
than
individual
workloads
and
what
that
would
look
like.
E
So
if
I
choose
to
or
under
certain
specific
circumstances,
like
blue
green,
I
would
want
to
be
able
to
provide
that
experience
where
a
developer
never
has
to
worry
about
the
ground,
shifting
underneath
their
feet.
But,
of
course,
as
an
sre
or
as
a
as
a
cluster
engineer.
I
also
would
like
those
those
knobs
and
dials
that
I
can
then
automate
on
top
of.
So
those
are
those
seem
like
they're
they're
in
conflict
with
each
other.
E
But
of
course
the
cluster
developer
is
the
one
providing
the
experience
for
the
application
developer.
So
I'm
just
thinking
about
how
we
can
sort
of
harmonize
that
service
to
service
communication
or
perhaps
even
service
discovery
through
a
cluster
sort
of
cluster
registry.
And
I
guess,
by
extension,
service
registry.
A
Yeah,
so
I
think
I
think
that
there's
a
lot
there,
I
think-
and
I
think
there's
some
really
good
points
the
so
that
I
I
it's
kind
of
sounds
like
there's
two
separate
things
right,
there's
that
service
registry
concept.
So
you
know
I
just
want
to
talk
to
a
cluster
that
runs
this
service
and
then
there's
the
the
idea
that,
as
you
know,
an
application
developer.
I
want
to
talk
to
the
cluster
I'm
supposed
to
be
talking
to
right
now.
A
You
know,
regardless
of
of
state
of,
for
example,
a
blue
green
upgrade
so
but
then,
obviously
as
as
sra,
I
want
to
talk
to
actual
clusters,
so
maybe
there's
some
way
of
like
label
selection
on
on
clusters,
like
that
that
we're
looking
for
here.
C
I
wonder
as
sort
of
a
meta
point
like
does
it
actually
help
us
to
have
multiple
documents
for
this,
or
should
we
just
make
this
one,
the
dumping
ground
for
now,
and
we
can
sort
of
bin
them
and
categorize
them
later?
What
do
people
think.
A
I
think
a
single
doc
is
probably
easier,
especially
this
one's
getting
some
traction
now
and
yeah.
You
know
it
seems
like
that
the
cluster
set
itself
as
a
concept
and
and
some
form
of
of
registry
are
are
going
to
be
pretty
coupled.
So
if
it,
if
you
don't
need
any
knowledge
of
other
clusters,
there's
probably
still
some
uses
for
cluster
set,
but
I
I
would
bet
that
most
most
real
cluster
set
use
cases
require
some
knowledge
of
other
clusters.
E
Yeah,
I
also
agree
because,
like
especially
because
we're
trying
to
collect
use
cases,
you
know-
I
guess,
cluster
set.
The
differentiation
between
cluster
set
and
cluster
registry
would
require
someone
to
understand
what
the
difference
is
between
the
cluster
set
and
the
cluster
registry
is.
While
we
can
really
be
rejecting
our
our
concepts
and
our
abstractions
to
fit
their
use
case
rather
than
the
other
way
around.
C
Okay,
do
we
want
to
did
we
want
to
keep
talking
about
richard's
use
case
right,
see
stephen
you've
added
you've
added
a
couple
of
that
health.
D
Yeah
well,
I
was
just
thinking
stuff
based
on
what
the
one
that
you
just
started
about
health
as
well
yeah.
I
agree.
The
cluster
registry
cluster
set
distinction
is
perhaps
a
bit
early
in
the
process
for
just
recording
use
cases
so
yeah
on
the
health
on
the
health
side
of
things,
and
so
this
is
also
blurring
the
distinction
between
registry
and
set.
D
I
guess,
but
I
think
it's
important
for
clusters
to
be
aware
of
the
health
available,
the
ability
of
the
cluster
registering,
which
is
the
opposite
of
your
point,
and
I
also
think
it's
valuable
to
try
to
keep
this
up
the
same
properties
we
have
in
networking
with
control,
pins
and
data
planes.
If
the
cluster
set
is
the
data
plane
and
the
cluster
registry
is
the
control
plane
if
we
lose
the
control
plane.
Ideally,
the
data
plane
should
still.
C
So
drilling
into
that
first
bullet
steven,
how
would
you
expect
to
surface
in
a
registered
cluster
the
availability
of
the
registry?
Would
you
see
that
as
something
that
that's
more
programmatic
or
does
it
have
api?
D
I
I
was
thinking
more
along
the
lines
of
programmatic
rather
than
api.
So
actually,
I
was
thinking
of
you
know
something
like
actually
synchronizing
the
data
so
still
with
the
mindset
of
a
passive
registry
synchronizing
the
data-
that's
in
the
registry
and
using
something
like
draft-
or
you
know
the
community
to
the
user
election.
C
C
Yeah
or
or
being
able
to
present
in
a
ui,
maybe
like
the
like
unplugged,
like
emoji
or
graphic
yeah,.
A
I
I
I
think,
I'm
I'm
stuck
on
the
wording
a
little
bit.
I
think
it's
just
that
we
you.
You
want
the
ability
to
be
aware
of
the
health
availability
of
the
cluster
registry
in
general.
It
seems
like
whether
that's
from
some
external,
like
a
ui
or
or
from
one
of
the
clusters
themselves,
is
not
not
entirely
relevant
right.
C
Switching
gears
a
little
bit
to
the
second
one,
because
it's
kind
of
kind
of
related
to
like
the
one
of
the
one
of
the
things
that
I
heard
repeatedly
from
folks
in
the
past
about
federation
was
the
perception
and
I
think
it's
valid,
based
on
what
was
implemented
in
the
past
of
like
the
the
cluster
hosting
federation.
As
a
single
point
of
failure-
and
I
read
stephen-
I
read
your
second
bullet
point
here
about
surviving
unavailability
is
connected
with
that.
C
How
would
you
expect
to
survive
the
unavailability?
I
think
there's
kind
of
two
different
scenarios
right.
You
go,
maybe
go
offline
for
a
period
of
time
and
it
comes
back
like
it
blips
or
it
fails,
and
maybe
you
already
know
where
it
will
fail
over
to
like
you-
have
a
comma
delimited,
url
field,
for
it
tell
me
more
about
what
you
imagine.
C
D
Right
so
yeah,
so
time
is
so.
The
second
case
is
a
bit
simpler.
If
the
that's
more
about
replicating
the
registry
and
choosing
another
primary,
basically,
the
the
former
one
is
a
bit
harder
and
so
leads
into
split
brains
and
things
like
that.
So
if
a
single
cluster
so
just
to
go
back
to
sort
of
the
use
case,
if
I
have
an
exported
service
inside
a
cluster
set,
I
want
to
continue
to
be
able
to
use
it,
even
if
the
registry
is
gone.
D
So
that's
that
seems
fairly
simple,
because
once
this
exported
service
has
been
created
and
represented
in
whatever
the
appropriate
ways
in
each
client
cluster
cluster,
then
if
the
registry
goes
away,
that
information
is
still
there.
The
only
danger
is
to
become
stale.
D
But
then,
if
the
information
becomes
still,
presumably
the
target,
endpoints
will
stop
responding,
and
so
that
sort
of
settles
itself,
and
that
also
takes
care
of
the
completely
disconnected
cluster
scenario.
Because
the
completed
disconnect
the
cluster
cluster
won't
be
able
to
contact
the
registry,
and
it
also
won't
be
able
to
contact
any
exported
services
from
any
other
cluster.
D
And
those
were
the
the
two
main
use
cases.
We
had
to
solve
other
use
case,
which
is
a
bit
of
a
pathological
networking
scenario
where
a
cluster
set
has
a
little
balancer
on
top
of
it,
and
we
want
to
be
able
to
root
around
failures
and
provide
access
to
services
and
cluster
say
in
cluster
b,
going
through
cluster
a
because
little
bouncer
can
no
longer
talk
to
cluster
b.
So
that's
that's
a
bit
of
a
sort
of
sub
case.
D
D
But
yeah
yeah
you're
the
two,
the
two
points
you've
added
some
capture.
What
I
was
thinking
of
pretty
much.
E
That
suggests
to
me,
like
there's
some
sort
of
cache
of
information
on
each
cluster,
and
I
guess
you
would
sort
of
incur
the
performance
that
cached
information
and
all
of
its
pros
and
cons
as
well.
Is
that
sort
of
what
you
were
getting
at
yeah.
E
D
I
think
I
think
in
some
ways
so
the
the
cluster
registry,
so
we
haven't
really
even
thought
about
what
the
clutch
registry
contains.
Is
it
just
a
catalog
of
clusters
in
the
cluster
sets
and
access
credentials,
or
is
it
more
than
that
exported
services
etc?
Or
do
clusters
swap
services
with
each
other.
D
A
Yeah,
it
seems
like
staying
more
minimal
is,
is
better
and
just
really
focusing
on
these
use
cases
if
it
turns
out
that
it
make
that
it
makes
sense
to
to,
for
example,
roll
in
some
multi-cluster
service
functionality
and
and
tracking
services
like
maybe
that's
something
that
we
could
eventually
get
to,
but
that
seems
like
we're
getting
way
ahead
of
ourselves
there
and
and
also
starting
to
force
force
implementation,
which
we
really
didn't
want
to
do
with
with
multicultural
services
and
like
even
some
of
the
conversation
we
had
there.
A
I
think
it
is
like
what
I'm
really
hearing
there
is
that
if,
if
you
build
something
on
that
uses
the
cluster
registry
for
connectivity,
would
it
be
enough
to
say
at
least
to
start
that
you
want
to
make
sure
that
if
the
cluster
registry
goes
away,
any
any
services
that
are
using
credentials
from
that
registry,
for
example,
can
still
use
those
credentials.
So
it's
not.
You
know
a
single
point
of
failure.
A
D
Yeah,
that's
really
what
I
want.
I
want
to
avoid
registered
being
a
sport
yeah.
A
A
Yeah
users
should
now
assume
that
and-
and
you
know
maybe
like
maybe
an
implementation
that
uses
cluster
registry
should
actually
handle
its
own
availability.
But
we
just
want
to
guarantee
that
credentials
will
still
work.
C
B
Boy
howdy,
I
there's
there's
a
lot
going
on
here
and
I
apologize
if
I'm
a
bit
contrarian.
B
I
think
the
cluster
registry
topic
is
like
the
least
interesting
thing
that
we
can
talk
about,
because
I
think
no
user
should
ever
care
about
the
cluster
registry.
There's
some
set
of
admins
who
care
about
it,
but
the
vast
majority
of
people
who
are
going
to
engage
with
kubernetes
aren't
going
to
ever
see
or
think
about
the
cluster
registry,
and
so
I
think
it's
I
think
it's
a
distraction
a
little
bit
and
when
we
start
talking
about
well,
we
haven't
decided
which
model
we're
going
to
use
for
multi-cluster
services.
B
I
think
we're
actually
missing
the
the
thing
that
I
liked
best
about
jeremy's
multi-cluster
services
proposal
was,
it
doesn't
dictate
any
of
that,
and
I
I
I'm
just
worried
that
we
will
spend
a
lot
of
time
rabbit
holing,
on
how
multi-cluster
registry
should
work
and
what
api
it
should
provide
and
how
the
credentials
live
and
we're
making
assumptions
that
don't
actually
help
anybody.
B
I
think
we
don't.
We
haven't
explored
implementations
enough
to
try
to
standardize
on
it
and
things
like
credentials,
which
was
just
the
last
topic
like.
I
can't
make
any
guarantees
about
credentials
because,
hopefully
you're
getting
short-lived
credentials
right.
So
whatever
you
pulled
out
of
whatever
api
implements
your
cluster
registry,
hopefully
that
credential
doesn't
last
more
than
a
half
hour,
and
so
if
the
cluster
registry
goes
away
like
in
some
worlds,
you're
going
to
have
a
huge
problem.
In
other
words,
maybe
you've
got
eternally
lived
credentials
and
I
feel
bad
for
you.
B
C
The
in
what
I
heard,
I
just
want
to
make
sure
that
I
heard
you
correctly
is
it
sounded
to
me,
like
you,
think,
cluster
registry
is
kind
of
a
strange,
attractor
distraction
type
topic.
B
Yeah
I
mean
put
yourself
in
a
user's
point
of
view
right,
I'm
using
a
cluster
and
I
want
to
engage
with
multi-cluster
services.
I
don't
want
to
care
about
the
clusters
in
the
cluster
set.
I
don't
want
to
think
about
where
my
cluster
registry
is
one
of
the
things
that
is
really
elegant
about
the
multi-cluster
services
design
is,
I
don't
have
to
think
about
those
things
because
they're
just
represented
in
my
cluster
right
and
via
the
endpoint
slices
and
the
service
imports
and
whatever
and
whatever
other
functionality
we
build.
B
B
To
be
sure,
it's
important
to
figure
out
if
we
want
to
write
portable
controllers,
how
are
those
controllers
going
to
iterate
the
set
and
how
are
those
controllers
going
to
get
their
credentials
into
the
constituents
or
if
those
controllers
are
in
cluster,
how
do
they
get
con
credentials
or
connectivity
right?
I
think
paul.
You
amazed
the
issue
here
about
you
know
not
being
able
to
dial
how
do
they
get
connectivity
between
those
clusters?
B
A
B
B
C
So
in
terms
of
like
framing
tim
just
for
for
clarity-
and
probably
this
is
something
that
I
should
have
done
to
frame
the
conversation
when
we
kicked
it
off
today
like
we
are
we're
not
really
here
in
this
discussion
to
shift
our
focus
as
a
group
on
to
this
as
like
an
ongoing
thing,
but
it
is
something
that's
come
up
in
the
last
few
meetings
and
and
in
general,
we've
kind
of
touched-
the
topic
over
the
last
few
months.
C
So
this
is
maybe
more
of
like
a
an
exercise.
I
think,
to
start
recording
things
that,
like
people
might
think,
are
important
in
the
community
as
we
make
progress
on
what
I
think
you
would
refer
to
as
the
more
interesting
parts
of
like
multi-cluster
services
and
work
api,
etc.
So
I
I
don't
want
us
to
take
a
laser
focus
on
cluster
registry
at
this
moment,
but
I
think
that
we'll
we'll
be
kind
of
working
backwards
into
into
finding
over
the
next.
C
You
know,
I
don't
know
six
months,
whatever
some
medium
term
amount
of
time
near
term
medium
term
amount
of
time
into
a
desire
for
some
shared
primitives.
So
I
I
explicitly
want
to
like
say
to
everybody
that
I
don't
think
that
standardization
is
a
goal
for
us
right
at
this
moment.
It's
more
like,
let's,
let's
think
about,
recording
what
people
have
thought
about
in
connection
with
the
term
and
as
we
go
forward
see
which
of
those
things
wind
up
being
actual
fits
to
the
problems.
B
Sure-
and
I
don't
mean
to
come
off
as
negative
nancy
here,
like
it's
an
interesting
topic
and
it's
actually
sort
of
very
difficult
to
steer
away
from
diving
deep
on
this
topic,
because
I
have
a
suspicion
that
we're
mostly
infrastructure,
nerds
here
and
the
infrastructure
for
the
infrastructure
is
even
more
interesting.
B
But
I
I
I
really
want
to
focus
on
the
things
that
bring
value
to
end
users
and
how
different
implementations
will
make
different
trade-offs
around
value
propositions
right-
and
this
is,
I
think
this
is
like-
I
said-
a
distraction
from
from
that
goal.
E
Yeah
yeah,
I
just
wanted
to
to
sort
of
speak
to
you
know
the
topic
that
tim
brought
up
so
at
our
company.
We
have,
basically
you
know,
application
developers.
So
in
my
point
I
say
you
know
as
an
application
developer
as
an
sre,
but
that's
I
guess,
sort
of
analogous
to
you
know
as
an
end
user
and
as
a
as
a
controller
developer.
E
So
when
I
come
into
this
conversation,
I
think
of
really
three
three
layers
where
an
end
user
is
certainly
you
know,
and
I'm
always
thinking
about
what
the
end
user
will
will
see
in
terms
of
what
resource
they
define
or
or
stuff
like
that.
E
But
I
I
in
my
experience
it's
also
a
very
personalized
or
or
opinionated
way
of
of
serving
that
customer
group,
the
best
right
so
like
as
a
as
a
controller
developer,
I
write
specific,
unique
apis
and
controllers
to
to
serve
what
they
need
and
then,
of
course,
when
I
turn
around-
and
I
you
know
need
some
sort
of
maybe
abstractions
to
build
on
there's
that
third
layer
of
where
you
know
that
infrastructure
for
me
to
build
a
platform
to
serve
my
users.
I
guess
that's
sort
of
my
perspective.
C
E
Right
so
basically,
the
way
I
see
it
is
that
there
are
three
layers
of
users.
There
are
end
users,
there
are
controller
developers
and
then
there
are
underlying
abstractions
in
which
these
developers
develop
on
for
their
users.
E
C
So
that's
a
really
good
question.
Here's
here's,
my
version
of
that
is,
is
that
I
think
that
our
conversation
in
like
in
the
past
in
general,
has
sort
of
mixed
those
different
concerns
together.
I
hoped
that
we
eventually
can
get
to
the
point
where
the
those
layers
are
like
evident
in
our
conversation,
and
maybe
they
they
have
names
that
we
all
share
for
them,
so
that
we
can
be
very
clear
about
like
what
are
the
actual
use
cases
that
people
have
for
the
different
layers.
Does
that
make
sense.
E
E
Of
of
my
company
architecture
or
not
architecture,
but
hierarchy.
C
Yeah-
and
I
think
that
is
that
that
would
be
great
content
to
put
in
here,
and
maybe
we
need
to
just
find
like
a
better
name
for
this
document
than
than
the
one
it
has
presently,
but
I'm
I'm
definitely
interested
in
that
type
of
information
too.
Just
speaking
for
myself,.
E
And
we
actually
have
some
sort
of
I.
I
actually
have
some
sort
of
like
internal
like
documentation
that
I've
already
written
for
myself,
that
I
can
share
for
certain
inspiration
and
as
a
skeleton
for
these
personas
as
well.
C
That
would
be
fantastic.
I
I
let's
call
on
the
raised
hands
and
then
we're
we're
actually
over
time
or
running
up
on
the
hour.
So
probably
we'll
we'll
be
winding
this
down.
After
that,
stephen,
I
think
yours
went
up.
First,
go
ahead.
D
Yeah,
so
I
I
I
agree
with
richard
so
the
way
when
I
was
filling
in
the
use
cases
in
both
documents.
The
way
I
was
thinking
of
this
is
that
the
registry
document
is
more
about
what
I
need
to
think
of
as
a
controller
developer
and
perhaps
as
a
network
administrator
as
well.
So
you
know
with
the
the
red
hat
openshift
bias
of
seeing
everything
with
operators.
D
So
there's
the
operator
that
does
the
automation,
but
that
also
provides
the
status
and
the
classified
document
was
perhaps
more
interesting
to
me
but
more
complicated
to
think
about,
because
it's
more
about
the
concept,
and
so
it
still
combines
two
of
richard's
layers.
In
my
mind,
the
concepts
that
we're
thinking
of
and
how
cluster
sets
are
useful
for
end
users,
and
but
I
agree
with
him.
Man,
users
shouldn't
care
at
all
about
the
registry
side
of
things.
A
A
A
You
know,
we'd
already
talked
about
namespace
sameness,
and
I
think
that
one
that
one
has
has
a
lot
of
consensus,
but
but
you
know
I
started
the
first
item
I
added
here
was
cluster
id,
because
that's
the
one
specific
need
that
came
out
of
mcs,
and
it's
really,
it
seems
like
a
registry
related
concept
because
having
a
unique
id
for
each
cluster.
A
Storing
that
in
some
registry
makes
sense,
but
it
really
doesn't
need
a
registry.
We
just
want
a
unique
id,
and
so
is
that.
Does
that
actually
make
sense
to
standardize?
I
mean
it
seems
like
if,
if
every
mcs
implementation
is
going
to
have
some
unique
id,
maybe
we
can
make
we
can
make
certain
guarantees
around
characteristics
of
that
id
and
how
that
actually
gets
derived.
So
maybe
that
becomes
something
that
kubernetes
clusters
have
just
in
general.
A
But
if
that
were
the
case,
then
is
that
even
actually
necessitating
a
a
registry
or
is
it
just
a
tool
you
could
later
use
for
some
operator
to
build
a
registry
so
starting
with
the
personas,
I
guess
my
tl
dr
starting
with
the
personas,
I
think
is-
is
a
good
place
there,
and
what
do
we
really
want
to
get
out
of
this.
C
Yeah,
I
wonder
so
I
think
starting
with
personas
is
a
really.
It
would
be
a
great
idea.
C
How
about
I
just
plumb
something
in
here
for
personas
into
this
document,
so
we
don't
wind
up
with
a
sprawl
of
documents
and
folks
can
just
brain
dump
on
personas
in
there
does
that
work,
yeah.
A
C
Great
that
sounds
great
yeah,
okay,
personas
in
use
cases
so
I'll
I'll
plumb.
That
in
I
think
we're
about
at
time
now
and
I've
got
a
a
hard
start
for
my
next
thing
at
at
the
half
hour,
so
I
personally
have
to
drop
now
tim.
I
saw
a
comment
just
going
to
the
chat.
Did
you
want
to
verbalize?
It.
B
Sorry,
I
I
just
wanted
to
say
on
cluster
id.
I
think
cluster
id
is
one
of
the
the
things
that
we
do
understand
fairly
well
now,
as
we've
had
a
bunch
of
different
implementations
of
stuff,
and
everybody
comes
back
to
needing
it.
But
what
if
we
can,
can
we
define
cluster
id
the
same
way?
We
define
multi-cluster
service
like
within
a
cluster.
This
happens,
and
that
is
your
multi-click.
B
That
is
your
your
cluster
id
and
how
that
came
to
happen
is
undefined,
at
least
for
the
moment
like,
for
example,
you
get
a
crypto
signed,
an
object
with
a
crypto
signature,
from
a
ca
that
you
trust
and
how
that
came
to
be
is
out
of
scope
and
that
that
gives
you
your
cluster's
id
and
then
all
the
sort
of
ripple
of
of
implications
there
right
refreshing
certificates
and
and
revocation
and
all
those
other
things
we
can
go
and
address
the
semantics
of
it.
B
A
A
If,
if,
if
I'm
using
this
tool,
what
can
I
actually
expect
in
a
cluster
like
what
what
things
can
I
count
on
and
we've
done
that
with,
I
think,
to
good
effects
so
far
with
with
multi-cluster
services,
if
you're
using
an
implementation,
here's
the
behavior
you
can
count
on
and
if
you're,
using
a
a
cluster
id
implementation,
you
have
a
provider.
Here's
here's!
What
you
can
count
on!
Here's
how
you
would
find
it
all
of
that.
I
think
that's
a
great
place
to
start.
B
C
Okay,
I've
got
a
I've,
got
a
drop,
I
guess
jeremy,
you
and
I
should
reach
out
to
herman
and
see
if
we
can
reschedule
his
time
for
a
future
meeting.
C
Okay
and
please
folks,
right
into
the
agenda
doc,
if
you
have
things
you'd
like
to
discuss
next
time
and
we'll
see
you
then
thank
you.
Everybody.