►
From YouTube: Kubernetes SIG Multicluster 06 Oct 2020
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
Audio
give
it
two
more
minutes
for
everyone
else
to
show
up
sure.
I'm
going
to.
B
B
A
Okay,
three
minutes
in
let's
get
started
steven.
I
think
you
have
the
agenda
today.
B
Yeah
pretty
much
so
yeah,
so
we
started
a
while
back
scrubbing
the
use
case,
documents
and
yeah
while
discussing
the
cluster
registry
one,
but
we
didn't
really
get
into
the
cluster
set
one,
and
given
that
sort
of
the
parent
concept,
I
thought
it
was
worth
discussing
that
one,
perhaps
a
little
bit
more
and
also
discussing
whether
it
makes
sense
to
actually
merge
them.
A
Completely
agree,
looking
at
the
two
items
that
you
had
here,
though,
I
think
maybe
it
makes
sense
to
start
with
the
second
one.
Second,.
A
Yeah,
probably
so,
is
the
mcs
api
ready
for
external
use
with
the
v1
alpha
1
caveats.
Yes,
I
think
so
that's
from
my
perspective.
It's
been
ready
since
we
pushed
up
to
to
the
sigs
repo.
I
don't
know
if
anyone
disagrees
there
but
yeah.
I
think
we
are
with
the
v1
alpha
one
caveats
absolutely
and
then
you
know,
hopefully
we
can
start.
A
It
looks
like
we've
got
a
few
implementations
in
flight,
so
hopefully
we
can
start
narrowing
that
down
and
and
get
closer
to
beta
and
lift
those
restrictions,
but
but
yeah.
I
think
you
know
from
what
we've
seen
I
don't
I
don't
imagine
it
changing
drastically
in
the
near
term.
A
Awesome
yeah
feedback,
please
so
with
that,
let's,
let's
dive
in,
do
you
want
to
share
or
or
I
can
share-
maybe
yeah,
I'm
not
sure
yeah.
If
you
can
share,
I
might
just
be
sure.
Let
me
bring
up
the
right.
A
A
All
right
so
yeah
I'll
start
start
with
cluster
set.
Can
you
see
that
all
right,
yep
cool
yeah?
So
should
we
just
kind
of
go
through
and
and
talk
through
the
use
cases?
I
see
that
there's
already
some
comments.
A
We
probably
should
have
done
this
a
while
ago,
so
thanks
steven
for
adding
it
to
the
agenda,
so
I
think
the
first
couple
that
I
added
were
were
really
just
meant,
as
starters
kind
of
based
on
the
other
conversations
that
we've
had
in
the
sig
and
so
maybe
not
too
controversial.
But
but
it
looks
like
there's
some
good
comments
here,
so
I
think
the
first
one
was
kind
of
the
ownership
access
consistency.
A
This
is
this
is
really
just
kind
of
an
extension
of
what
we
kind
of
agreed
to
with
that
namespace
sameness
position,
statement
that
you
know
the
owner
should
own
their
namespace
and
all
of
the
clusters
in
a
cluster
set,
and
I
think
my
second
bullet
here
is
really
just
kind
of
a
corollary.
If
I
own
the
same
namespace
or
if
I
own
the
namespace
and
all
my
clusters,
then
I
want
to
have
the
same
access
in
those
clusters.
A
B
A
A
I
want
to
know
that
if
I
make
it
available
from
one
cluster,
I
can
do
so
from
any
cluster,
so
I
don't
have
to
think
about
like
which
cluster
I'm
in
and
am
I
right
to
expose
and
then,
as
a
consumer,
and
this
this
is,
I
think,
where
it'll
get
interesting
as
a
consumer,
I
don't
want
to
think
about
which
cluster
the
service
lives
in,
but
vishal
had
this
comment
here
about
supporting
the
option
for
a
consumer
to
select
a
particular
cluster,
and
actually
I
wanted
to
talk
about
that
a
bit.
B
All
yeah
also
the
the
points
that
have
come
up
and
some
of
our
discussions
of
this
and
the
first
one
I
guess
we've
already
talked
about
here
as
well-
is
having
some
idea
of
locality,
preferring
a
local
service
that
is
available.
A
A
Yeah
that
I
think,
makes
a
lot
of
sense,
but
so
I
guess
the
question
is:
is
that
does
that?
I
want
to
ask
this
differently?
Is
that
locality
related
to
cluster
the
cluster
itself,
or
is
it
more
about
where
the
cluster
is
located
like?
If
I
had,
if
I
had
two
clusters
that
were
co-located,
do
I
do
I
care
in
that
case
which,
where
my
traffic
goes
because.
B
Yeah
or
if
you
have
a
stretch
cluster
where
a
service
can
be
in
the
same
cluster,
but
in
a
different
geography
as
this
right,
for
example,
yeah
yeah,
there's
some
other
metric,
and
so
the
locality
aspect
isn't
really.
If
we
think
of
this
at
a
high
level,
it
doesn't
contradict
this
in
any
way.
B
The
the
consumer,
ideally
as
in
the
person
writing
the
application,
that's
or
microservice
or
whatever
that's
connecting
to
the
multi-cluster,
doesn't
want
to
have
to
think
about
the
where
the
service
is
right
and
where
the
services
and
how
that's
handled
is
a
really
an
implementation
detail.
B
I
think
so
before
we
address
vishal's
comment
right
from
the
consumer
perspective,
the
whoever's
providing
the
multi-cluster,
I
think,
should
just
do
the
right
thing
getting
the
default
case,
and
so
that
could
be
based
on
latency,
etc,
a
whole
pile
of
things,
but
the
consumer
doesn't
worry
about
that.
B
So
then,
vishal's
comment
is
about
some
use
cases
where
the
how
the
multi-cluster
is
set
up
or
well
more
accurately,
where
the
services
live
is
important,
and
this
is
this
is
really
related
to
scenarios
where
you
have
kubernetes
cluster
definitions
and
then
some
other
concept
of
a
cluster.
And
so
we
come
across
this,
for
example,
with
kafka,
setups
or
cockroachdb.
B
The
yeah
data
storage
has
to
have
some
its
own
idea
of
what
what
makes
the
data
safe
right.
A
Right
and
so
I
you
know,
I
can
look
at
this
from
a
cassandra
perspective,
because
I've
got
a
lot
more
experience
than
that.
Then
personally,
but
yeah
like
cassandra
is,
is
you
know,
zone
and
region
aware.
A
Or
rack
and
data
center
in
in
cassandra
terms,
but
but
yeah
they
like
it
knows
it
has
its
own
replication
semantics
but
as
as
a
consumer,
I
don't
know
that
I,
like
I
just
want
to
connect
to
the
cluster
more
than
I
want
to
connect
to
like
a
specific
subset
of
endpoints
is
like
with
with
cockroach.
Do
you
do
you
care?
A
Do
you
actually
care
which
nodes
that
you
are
talking
to,
or
is
it
that
cockroach
needs
to
internally?
Have
the
ability
to
address
address
certain
notes.
B
B
Certain
nodes-
and
this
this
might
actually
be
just
a
really
a
layering
problem
where
ultimately
we're
trying
to
do
and
well
multi-cluster
at
the
wrong
level.
B
Trying
to
you
know
trying
to
build
a
clustered
service
on
top
of
multicultural
service
when
it's
not
really
the
right
abstraction.
Perhaps.
A
Yeah
because,
like
I
guess
the
question
that
comes
to
mind
for
me
there
with
with
like
cockroach
or
some
other
distributed,
databases
like
I
assume
that
internally,
it
has
its
own
notion
of
of
where
nodes
are
located,
for
you
know
its
own
replication,
yeah
semantics,
and
so
does
it
care
about
the
service
that's
exposed,
or
is
it
just
that,
like
as
a
consumer,
do
I
care
where
those
nodes
are,
or
is
this
really
about
the
database
knowing
it's
or
that
you
know
whatever.
B
A
Okay,
that's
yeah!
No!
That's
that's
really
good
to
dive
into
because
that
actually
like
from
the
use
cases,
I've
seen
that's
kind
of
more
consistent
like
absolutely
the
pods
that
make
up
the
service
might
care
about
which
cluster
they're
located
in
or
or
I
guess
more
accurately
which
which
which
zone
or
region
they're
located
in.
But
but
I
don't
know
if
that
needs
to
actually
be
exposed
at
the
service.
B
Yeah
yeah
yeah!
That's
why
I'm
starting
to
think
as
well!
So
shame
if
you're
shy
wasn't
here,
but
yeah
yeah.
This
would
good
for.
A
For
follow
up
on,
you
know,
after
this
we
can
throw
a
comment
in
here
kind
of
summarizing
this
conversation
because
yeah,
what
I've
kind
of
seen
more,
is
if
you
like
the
use
cases
where,
where
people
really
want
to
access
a
service
in
a
particular
cluster.
A
At
that
point,
the
service
stops
feeling
fungible
and
maybe
maybe
it
actually
like.
Even
if
it's
the
same
quote
the
same
service,
you
know
running
the
same
application,
it's
actually
a
different
instance,
and
maybe
it
may
be,
then
it
needs
its
own
name.
A
B
Yeah
because
it's
not
equivalent
really
yeah
right
and
so
there's
nothing
to
stop
other
mechanisms
being
put
in
place
to
provide
more
specific
connectivity,
but
perhaps
not.
A
Much
cluster
right-
and
I
mean
like
honestly,
you
could
even
have
you-
could
have
multiple
services
selecting
the
same
pots.
If
you
wanted
to
create
this
different
access
pattern,.
A
On
the
on
the
other
side,
the
topology
side,
I
think,
you're
right,
I
think
doing
the
right
thing
is-
is
the
right
thing
and
like
as
a
consumer,
I
shouldn't
care.
You
know
it
should
just
happen,
and
this
is
actually
in
line
with
a
lot
of
conversations.
I've
seen
in
sig
networking
lately
about
topology
and
rethinking
and
there's
actually
a
cap
to
kind
of
build
support
for
this
so
and
and
for
that,
I'm
not
actually
sure
that
it's
multi-cluster
specific
at
all
like.
Even
if
I
have
a
you,
know
a
fairly
distributed
cluster.
A
I
probably
still
want
some
kind
of
intelligence
in
it
within
a
single
cluster.
Multi-Cluster,
just
of
course,
exacerbates
all
the
problems,
because
you're
you're
more
likely
to
have
interesting
topologies,
but
I
think
yeah
like
as
a
consumer.
Hopefully
I'm
not
concerned,
I
don't
have
to
say,
like
you
know,
don't
make
my
traffic
expensive
it
just
it.
A
But
yeah
the
the
addressing
is
really
interesting
and
I
think
you
know
we
should
we
should
keep
digging
into
use
cases
there,
because
I
I
keep
seeing
this
pattern
where
you
know
either
the
I
want
to
address
a
specific
cluster
use
case
becomes
is
actually
I
really
want.
Two
services
like.
A
A
And
I'm
I'm
curious
if,
if
we're
missing
something
there
and
if
there
are
use
cases
or
if
it
really
is
kind
of
these
two
camps,
which
would
be
great
because
it
means
that
we're
kind
of
already
covering
our
bases.
But
I
want
to
make
sure
that
you
know
we're
yeah
tracking.
B
Yeah
yeah
and
it's
yeah.
It
fits
in
with
what
tim's
being
saying
a
lot
where
the
network
layer
should
just
do
the
right
thing.
A
Cool
should
we
move
on
to
the
next,
the
next,
which
ones
which
are.
B
Mine
so
yeah,
so
I
wrote
as
a
service
winner.
I
want
the
option
to
expose
a
multi-cluster
service
externally
without
knowing
ahead
of
time
in
which
clusters
of
the
cluster
set
it
will
be
available,
and
I
want
to
support
informing
external
load
balancers
of
the
appropriate
cluster
to
use
internally
re-routing
requests
if
a
service
request
comes
in
to
a
cluster
where
it
doesn't
host
the
service,
and
so
this
is
sort
of
this
is
related
to
north
side
load
balancing,
but
yes,
in
a
sort
of
more
generic
way.
B
So
the
way
I
was
really
thinking
yeah,
so
I
wrote
it
just
underneath
another
way.
I
want
to
be
able
to
load
balance
across
a
cluster
set
and
access
exposed
services
within
the
cluster
set
from
any
ingress
in
the
cluster
set,
and
so
I
was
sort
of
thinking
with
that.
My
last
point
really
is:
ultimately,
I
want
to
be
able
to
think
of
a
cluster
set
in
the
same
same
way,
I
think
of
a
cluster.
A
Yeah,
that
makes
a
lot
of
sense.
Have
you
been
following
the
service
apis
work,
the
gateway
api.
A
Yeah
yeah
exactly
that's,
that's
exactly
it
because
they
have
so
I've.
I've
actually
been
going
there.
A
They
meet
on
thursdays
and
kind
of
making
sure
that
this
use
case
isn't
forgotten,
and
I
think
there's
there's
some
interesting
developments
there
that
that
will
hopefully
apply,
but
you
know
essentially,
the
idea
is
that
this,
this
new
gateway,
which,
which
is
you
know
the
new
ingress,
can
can
point
at
a
service
or
it
can
point
at
a
service
import
and
that
would
make
it
a
multi-cluster
yeah
or
a
consumer
of
the
of
the
multi-cluster
service
yeah.
I
think
this
is
a.
A
This
is
a
really
good
use
case
here
and
if
I
think
it
fits
well
like
if
we're
saying
that
a
multi-cluster
service
is
just
the
is
just
the
multi-cluster
abstraction
of
a
regular
service,
then
I
would
expect
that
I
can
do
with
it.
The
things
I
can
do
with
the
regular
service
and
ingress
is
a
key
key
feature
there,
but
yeah-
maybe
maybe
we
should
kind
of
get
get
some
of
them
to
to
loop
in
more
here
and
and
talk
about
this,
because
I
think
this
is.
This
is
clearly
a
use
case.
B
Bullet
yeah,
and
so
this
is,
it
sort
of
goes
to
yeah,
it's
similar
to
the
the
one
that
we
were
just
discussing
about.
Where
of
the
show's
comment
as
a
service
running
on
the
cluster
set,
I
want
to
control
whether
my
requests
are
handled
by
instances
in
the
same
clutter
or
a
different
one
for
replication
purposes,
for
example
and
yeah.
So.
B
This
really,
I
think,
maybe
we're
coming
from
the
submariner
angle,
we're
influenced
by
the
fact
that
we're
building
mcs
on
top
of
connectivity
instead
of
thinking
about
things
the
other
way
around,
and
so
you
know
we
see
we
probably
have
a
tendency
to
see
mcs
as
a
way
of
describing
connectivity
when
it
shouldn't
really
be
the
more
I
think
about
it.
A
Yeah,
at
the
same
time,
though,
I
do
think
connectivity
is
important,
so
the
way
I
think
about
it
is
more
like
mcs
should
should
be
about
describing
intent
and
probably
not
describing
connectivity,
but
we
need
to
make
sure
that
we
that
the
api
leaves
open
room
for.
For
you
know,
your
connectivity
needs
yeah
like
this
use
case
seems
like
this
is
a
very
valuable
use
case.
A
I
I
think,
they're
kind
of
revisiting
the
service
topology
api
and
this
kind
of
goes
into
what
I
was
saying
earlier,
like
the
reasoning
being
that
everybody
actually
wants
the
same.
The
same
configuration
in
the
service
topology
api,
so
making
you
specify
doesn't
make
a
lot
of
sense,
and
maybe
it
was
a
little
too
prescriptive.
A
And
you
know
didn't
let
an
implementation
be
more
creative
and
and
at
a
minimum
just
made
you
kind
of
specify
redundant
information.
B
A
Yeah,
although
you
know
I
know
that
submariner
has
that
ability,
but
I
wonder
if
that
needs
to
be
like
a
general
part
of
the
api
or
would
exposing
like
in
the
general
case
where
you
can't
just
make
cluster
ip
visible,
would
would
just
exposing
another
multi-cluster
service.
That
is,
you
know
like
us,
and
europe
would
that
solve
it?
Well
enough.
B
I
think
yeah
so
having
a
us
well,
two
different
service
exports
would
cover
cases
where,
just
distinguishing
between
the
service.
B
Yeah
so
non-imported
service
and
an
important
service.
A
Yeah
like
just
if
basically
can't
have
we
provided
enough
grammar
to
ex
to
describe
what
what
you
want
to
do
here
and
are
there
gaps
and
then
also
is
it
too
cumbersome
because
like
if
this
is
a
super
common
use
case,
then
you
know,
maybe
maybe
it
needs
revisiting,
but
yeah.
B
A
Okay,
well,
that's
good!
I
I
like
open
questions.
At
least
we
can.
We
can
discuss
them
further,
so,
okay,
cool
yeah,
let's,
let's
keep
keep
thinking
about
that
when
discussing
it,
I
you
know
have.
A
At
least
in
the
current
definition:
that's
this
is
maybe
a
good
motivator
to
to
formalize.
That
definition,
I
think
we
we've
kind
of
described
headless
in
the
cap,
but
and
a
little
bit
of
dns
the
bare
minimum
needed
to
make
it
functional,
but
we
we
have
not
finished
headless
and
we
haven't
finished
dns,
and
I
think
that
you
know
we
had
that
listed
as
a
graduation
to
beta
requirement.
But
I
think
we
should
kind
of
formalize
that
definition
and-
and
that
seems
like
a
like
a
fine
place
to
start.
A
B
Yeah
so
yeah,
that
was
just
the
more
I
thought
about
the
use
cases
and
both
documents
and
the
classical
registration
cluster
sets
and
how
they
fit
in
with
other
apis,
and
that
is
the
more
I
was
just
thinking
in
many
scenarios
that
cluster
set
is.
A
Yeah
yeah,
I
mean,
I
think,
that
my
model,
my
mental
model,
has
been
that,
like
a
producer,
probably
needs
to
care
where
things
are
deployed,
but
a
consumer
really
shouldn't
have
to
you
know
if
everyone
kind
of
does
their
job
correctly,
the
consumer
just
kind
of
like
if,
if
they're
outside
it's
it's,
you
know
north
south,
they
consume
by
ingress.
A
A
producer
can
figure
out,
you
know
capacity
and
various
clusters,
and
and
all
of
that
and
routing
and
the
implementation
can
make
sure
that
that
it's
not
too
expensive
to
use,
but
the
consumer
just
wants,
wants
a
service
name
and
they
want
it
to
stay
up
and
they
want
it
to
handle
their
load
yeah
exactly
so
yeah.
I
think
this
is
a
really
good.
This
last
bullet
is
a
really
good
thing
for
us
to
strive
for
here.
A
A
All
right
yeah,
so
stephen,
I
don't
know
if
you
want
to
kind
of
take
the
lead
here.
I
think
last
time
we
spent
talking
around
your
points
here.
B
Rethinking
well
the
the
need
to
rethink
many
of
these
at
a
higher
level,
less
prescriptive.
A
Yeah-
and
maybe
maybe
it
doesn't-
maybe
the
maybe
the
cluster
set
document
is
like
kind
of
a
vision
document,
and
this
is
this
is
more
specifically
about
mechanics
and
what
we
need.
A
I
do
think
with
you
know
some
of
tim's
comments,
last
time
and
and
paul,
and
I
have
have
had
some
chats
as
well.
I
I
kind
of
think
that
we
have
a
good
set
of
specific
use
cases
and
and
and
specific
things
here,
that
I
think
various
people
would
like
to
use
a
registry
for,
and
maybe
we
should
try
to
take
this
kind
of
the
same
way
that
that
we
did
with
multi-cluster
services
and
not
and
just
kind
of
define
the
common
api.
A
Versus
actually
trying
to
describe
like
enumerate
all
of
the
actual
uses
that
we
want
in
a
registry,
because
I
don't
know
that
every
registry
needs
to
support
or
every
use
case
needs
all
of
these
features.
But
what
is
the
you
know?
What
is
the
common
basis
that
we
can
build
on
that
that
we
want
everywhere.
A
Yeah
you
know
like,
like
the
the
first
one
I
put
down
here,
identification
that
one
seems
pretty
non-controversial,
but
if
we
actually
dig
into
cluster
id,
I
think
there's
a
lot
there
and
even
just
like
deciding
on
how
to
identify
a
cluster
like
the
simplest
case
is
I
have
you
know,
I
have
a
unique
name,
but
then
there's
the
question
of
like
how
do
we
verify
that
that
the
cluster
with
that
name
is
in
fact
that
cluster?
A
I
I
assume
in
that
there's
probably
some
kind
of
self-identification
that
needs
to
be
supported.
Like
you
know,
I
should
be
able
to
keep
cuddle,
get
cluster
id
and
and
understand
what
my
cluster
is
and
what
else
you
know
what
else
goes
in
that
id
does.
That
is
that
just
a
cluster
local
thing
does
that
contain
cluster
set
information?
Does
it
have
instruction
like,
I
think,
there's
a
lot
of
open
questions
that
need
to
be
resolved,
and
then
you
know
if
I
were
to
build
a
registry.
A
B
Especially
or
go
ahead,
yeah
the
basic
trap
for
this
one:
is
you
have
a
registry
and
a
cluster
drawings
and
disappears
and
a
cluster
claim
a
cluster
claiming
to
be
the
same
one
rejoins
how'd.
You
verify
that.
B
Yeah,
maybe.
A
That's
not
quite
the
same,
but
it
should
replace
it
right
yeah
so
that
we
need
that
notion,
and
then
you
know
the
there's
also
the
question.
I
think
there
was
in
that
cluster
id
doc,
but
like
user
friendly
labels
like
presumably,
I
want
to
be
able
to
name
my
clusters.
You
know
like
europe
and
us,
but
those
user-generated
names
and
uniqueness
are
not
friendly
constraints.
B
There's
actually
one
area
where
yeah
so
there's
actually
one
area
where
that's
important
and
for
users
and
we're
exploiting
that
in
submariner
clusters
have
unique
names
that
are
hopefully
vaguely
human
friendly
in
cube.
Configs.
A
Yeah
yeah
so.
A
Yeah
and
that's
yeah-
that's
that's
very
true,
so
you're
right
because
they
do
have
vaguely
human
friendly
names
but
yeah.
When
you
get
to
a
lot
of
clusters,
the
human
friendliness
starts
to
fall
off,
but
you
know,
and
then
there's
the
question
of
is
that?
Okay,
because
when
you
have
that
that
many
clusters
are
you
actually
identifying
like
as
a
user?
A
Are
you
manually
selecting
them
or
is
that
when
you're,
relying
on
some
form
of
registry
to
to
you
know,
select
a
subset
of
clusters
for
you
and
then
that
would
imply
to
me
that
this
cluster
id
should
probably
also
support
cluster
labels.
A
A
A
Just
as
a
note,
the
access
the
this
next
bullet,
I
added
I'm
actually
less
convinced
that
this
is
something
that
needs
to
be
defined
versus
just
supported.
A
You
know,
my
initial
thought
on
on
cluster
registry
is
that
it
should
provide
you
credentials,
but
I
wonder
if
like
if
that
is
actually,
if
the
way
that
that
happens
is
actually
generic
enough
to
that,
it
should
be
prescribed,
and
maybe
the
right.
The
right
answer
is
really
more
of
a
instructions
on
how
to
and
how
to
get
access.
A
So
some
kind
of
a
reference
to
a
credential
provider.
Instead
of
that,
you
could,
you
know,
pass
a
cluster
id
and
in
your
own
credentials,
instead
of
actually
storing
credentials,
and
I
think
that
to
me
that
seems
to
be
one
of
the
things
with
the
current
cluster
registry
that
that
doesn't
quite
sit
well
is
like
it's.
A
It's
got
the
notion
that
all
the
con
all
controllers
are
kind
of
equal
right
and
and
like
it'll,
give
you
access.
But
if
I
remember
correctly,
it
basically
gives
everybody
the
same
access.
B
B
B
A
Yeah
type
this
morning,
yeah
that
so
that's
I
think
you
know
we're
we're
coming
up
to
you
know
a
little
bit
of
time
left
I'm
happy
to
spend
the
rest
of
today
on
this
as
well,
but
I
I
wonder
if
we
shouldn't
you
know,
try
to
regroup
next
week
with
you
know
a
different,
a
different
look
on
on
on
this,
and
maybe
we
can
go
through
and
audit
these
docs
for
or
specifically
this
one
with
the
cluster
registry
and
kind
of
revisit
the
common,
the
common
patterns
that
we
want
to
support
and-
and
maybe
take
it
take
this
from
the
angle
of
you
know
what
should
that
registry
api
look
like
more
than
what
should
the
registry
do.
A
Because
these
are
all
very
valid
use
cases,
but
they
are
also
not
likely
to
be
used
to
all
be
used
by
any
given
consumer.
B
Nothing
that
jumps
out
right
now.
Well,
the
the
last
one
is
an
interesting
one.
What
information
lives
in
the
registers?
I
think
so.
That's
that's
another
angle
to
explore.
A
A
Yeah
actually
so
yeah.
I
so
maybe
I'll
add
a
another
follow-up
discussion
for
this
to
next
week.
Right
now
on
the
agenda
but
yeah,
this
is
a
good
one.
Maybe
we
should
try
to
think
about
what
information
lives
in
the
registry,
or
maybe
the
wording
that
I
would
use
is.
B
A
Yeah,
these
are
great
questions.
Maybe
we
should
take
a
stab
offline
at
you
know
coming
up
with
some
some
answers,
and-
and
maybe
this
is
use
cases
as
well.
I
like
I
really
like
that
we
that
we
started
with
use
cases
and
and
and
what
we
want
to
what
we
want
to
actually
be
able
to
do
with
this
registry,
because
I
think
all
of
these
points
above
really
frame
the
conversation
well
around.
What
that
eventual
api
could
look
like.
A
I
think
you
know
we
probably
have
enough
for
like
even
from
this
list,
for
things
that
external
consumers
want
to
query
in
a
registry.
I
think
you
know
certainly
with
submariner,
where
it
is
there's
probably
a
good
list
of
what
we
need
just
for
for
services.
A
This
last
one's
probably
hard
at
this
point
and
I
think
we'll
probably
just
develop
out
of
the
others,
but
I
think
this
is
this
is
a
good
amount
to
think
about,
and
then,
in
the
back
of
my
mind,
I'm
very
curious
honestly,
if
like
if
we
just
started
with
actually
final
like
revisiting
cluster
id,
you
know
picking
and
choosing
the
concepts
that
we
like
and
and
starting
there.
A
A
B
A
Cool,
I
think
that's
just
about
time
here.
Is
there
anything
else
anyone
wants
to
talk
about.
A
All
right,
well
I'll
I'll,
take
a
note
personally
to
kind
of
revisit
these
stocks
over
the
next
week
and
and
try
to
add.
A
Awesome
yeah,
I
encourage
everyone
to
to
chime
in
and
I'll
add
to
the
agenda
right
away,
but
thank
you,
everyone
and
thanks
steven.
This
is
this
is
a
great
conversation.
A
You're
welcome
awesome.
All
right
then
see
you
all
next
week.