►
From YouTube: Kubernetes SIG Multicluster 2021 Jun 01
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
Hope
everybody
in
the
u.s
had
an
enjoyable
extra
day
off.
A
C
C
A
I
actually
spent
part
of
this
weekend
with
my
nephew
who's
he's
one
and
a
half.
I
guess
he's
almost
two
now
and
he's
not
talking
so
much
about
trucks
yet,
but
he
was
miming
the
garbage
truck
a
lot,
so
I
think
it
it
just
keeps
happening.
A
Although
you
know
I
never
get,
I'm
never
never
ceased
to
be
surprised
by
people's
ability
to
get
hung
up
on
names,
so
we'll
find
something.
C
Cool
I
wanted
to
revisit
thanks
for
jeremy,
also
for
reminding
me
about
this
alpha
graduation
blocker
for
the
cluster
id
cap,
about
whether
we
want
to
allow
cluster
ids
to
be
subdomains,
which
I
interpret
to
mean
have
dots
in
them.
This
cup
this
I
dug
up
the
commit
that
had
the
conversation
from
the
past
pull
request
on
it,
where
this
got
put.
So
I
will
actually
drop
this
in
the
chat.
C
If
people
want
that,
though,
I'm
not
super
sure
that
zoom
chat
allowed
me
to
put
the
whole
thing,
but
also
just
briefly.
C
This
top
one
is
the
conversation
by
paul
and
feel
free
to
expand
more
paul,
but
basically
that
we
suspect
that
people
might
want
to
use
a
subdomain
here
instead
of
just
a
label
and
that
you
were
okay
with
expanding
to
your
subdomains
later,
but
tim
felt
that
expanding
would
be
a
breaking
change,
and
if
we
have
use
cases,
we
should
talk
about
it
sooner
rather
than
later
so
kind
of
want
to
open
the
floor.
C
If
people
have
opinions
on
that
or
or
feelings,
if
they
themselves
might
want
their
cluster
id
to
be
something
like,
I
don't
know,
west
dot
banana,
that's
not
a
great
example,
but
if
someone
has
a
better
example,
too
I'd
be
interested
and
paul.
Do
you
maybe
want
to
speak
anymore
to
your
suspicion
as
well?
B
I
mean
so
like
here's,
I
I
think
one
of
the
things
in
my
head
when
I
wrote
that-
and
I
think
tim's
got
a
great
point-
was
that
secret
keys
couldn't
originally
have
a
dot
in
them
and
we
like
we
had
very
or
I'm
sorry
I
may
be
misremembering
this.
It's
been,
it's
been
quite
a
while,
like
tldr
modular,
the
details,
secret
keys,
for
example,
used
to
have
extremely
restrictive
names,
and
people
didn't
want
that.
So,
like
they've
they've
been
relaxed
over
over
time
and
in
general.
B
My
bias
is
therefore
to
like
you
know
not
not
solely
because
of
that,
but
in
general
my
bias
is
toward
like,
let's,
let's
keep
as
many
doors
open
as
we
can,
but
let's
also
not
like
make
things
so
like
featureful
that,
like
we're
putting
the
cart
before
the
horse,
so
I
do
agree
with
tim,
though,
and
I
think
he
makes
a
good
point.
I
think
my
preference
would
be.
B
A
D
I'm
pretty
sure
we're
going
to
use
this
in
cluster
api,
like
it's
going
to
line
up
with
the
way
cluster
api
talks
about
clusters
and
those
don't
have
dots
in
them
in
interesting
use
in
the
usage
of
it
that
I'm
familiar
with.
But
I
shouldn't
speak
for
all
of
cluster
api.
I
should
maybe
only
speak
for
one
implementation.
A
A
B
Yes,
I
you
know,
I
think
I
think
it's
very
possible
but
like
I
also
feel
strongly
like,
we
should
avoid
building
for
things
that
we
think,
but
that
no
one
has
said,
because
it's
easy
to
think
that
x
or
y
thing
will
happen,
and
then
it
doesn't
happen.
So
I
you
know,
I
think
that
I'd
I'd
love
to
have
the
the
reason
for
going
the
route
of
allow
it
to
be
a
sub
domain.
Be
that
a
lot
of
folks
said
that
it
would
be
much
more
useful
to
them
as
a
concept.
B
If
it
could
be,
and
then
we
could,
we
could
figure
out
how
to
handle
that
from
a
backward
compatibility
standpoint.
At
that
time.
C
We
can
talk
to
them
or
find
them
yeah
find
get
a
lead
on
who
there
talked
about
this,
so
I
can
at
least
ping
in
slack
or
on
the
mailing
list
and
then
follow
up
some
more
on
that
too,
and
see
if
there
was
already
some
research
on
this
project.
C
Yeah,
I
think,
that's
a
great
lead.
Anybody
else
have
feelings,
one
way
or
the
other.
C
I'm
hearing
a
trend
towards
like
double
check
with
cluster
api
lore
and
then
but
we're
kind
of
trending
avoid
sub
domains.
If
we
don't
have
anything
concrete
so
that
it's
most
generally
useful.
C
C
A
We're
aware
that
this
might
be
a
problem,
but
I
guess
one
concern
is:
if
we
go
with
a
label,
we're
probably
stuck
like,
I
guess
alpha
de
beta,
we
could
change
it,
but
but
beyond
that,
probably
not
right,
because
to
what
what
gabe
said,
you
know
which
resources
that
you
would
derive
from
the
cluster
id
can
can
take
labels
right
and
which,
which
or
which
can
take
sub
domains,
is
something
we
would
need
to
solve
and
and
some
things
would
start
breaking.
C
C
D
C
D
C
Cool,
well,
I
think
I'll
still
follow
through
a
little
bit
to
see
if
there
is
more
to
that
yeah
emotional
feeling
about
it,
but
yeah
that's
interesting
to
know
because
they
definitely
had
to
have
considered
it.
C
And
I
maybe
it's
all
in
everybody's
brains
right
now,
but
it
does
seem
that
there's
kind
of
a
known
set
of
resources
that
cannot
handle
this,
and
I
can
you
know
just
confirm-
and
I'm
sure
plenty
of
those
we
want
to
be
able
to
derive
from
in
the
future
is
the
concern
here
that
I'm
hearing
drive
to
you.
I
guess.
C
All
right
well,
this
is
good,
helps
me
with
this
part,
we'll
follow
up
with
cluster
api,
a
little
bit
more,
we'll
write
in
the
dock
that
we
are
trending
towards
staying
sub
domains.
We
know
that
this
will
be
a
breaking
change
for
x,
usages,
which
I
can
cross
confirm
and
in
the
future.
If
we
do
need
to
change
that
between
alpha
and
beta,
then
we
need
to
solve
that
problem.
Then.
A
C
D
I
yeah
I
was
like
going
back
and
forth
about
how
much
to
talk
about
this.
I
was
hoping
to
be
a
little
more
prepared,
but
I
figured
I
would
still
talk
at
people
for
a
couple
minutes
and
then,
if
the
conversation
isn't
useful,
we
can
end
it.
So
I
had
some.
D
I
got
some
good
feedback
on
my
pr
last
week
from
folks
and
I
think
the
most
substantial
one
was
sort
of
like
sensitivity
about
what
to
call
things
and
the
the
reluctance
to
like
introduce
a
new,
a
new
named
thing
like
capital
t
thing,
which
I
completely
get
so
like
stepping
back
a
bit.
D
I
was
trying
to
think
through,
like
what
are
the
guarantees
that
we
want
to
ensure
like
what
do
we
want
to
be
make
sure
is
true
across
various
implementations
that
might
be
weaker
than
the
current
definition
of
a
cluster
set,
but
still
like.
That's
like
the
sensible
thing
that
we
want
to
ensure,
and
so
I
took
a
crack
at
writing
something
down,
and
I
guess
I
should
probably
paste
that
in
there
rather
than
saying
it
poorly
but
yeah.
D
I
wanted
to
sort
of
like
get
initial
thoughts
from
this,
and
if
the
reaction
is
positive,
then
I
can
like
make
pr
changes
based
on
it.
So,
okay,
so
like
I
was
thinking
through
like
invariance,
like
system
and
variance
like
what
what
needs
to
always
just
be
true,
and
so
I
think
it's.
This
weaker
form
is
like
a
set
of
name
spaces
in
a
set
of
clusters
and
making
a
statement
about
that.
Those
two
sets
so
specifically
like
for
any
pod
in
any
of
those
namespaces.
D
The
set
of
service
imports
that
it
can
reach
shouldn't
depend
on
which
cluster
the
pod
is
deployed
to,
and
then
so,
that's
sort
of
like
the
consuming
side
of
the
invariant,
and
then
the
publishing
side
of
the
invariant
or
the
exporting
side
is
similar
like
for
any
service
export
in
the
namespaces.
D
That
you're
talking
about
that,
you
can
sort
of
scale
it
down
just
to
a
set
like
a
well-defined
set
of
name
spaces
but
like
cluster
set,
becomes
this
sort
of
like
simple
case
where
this
invariant
holds
for
all
namespaces,
but,
like
I
said
yeah
we
could
we
could
have
an
implementation.
That's
sort
of
like
has
a
smaller
set
of
name
spaces,
for
which
this
is
true
or
various
sets
that
are
for
which
this
is
true,
but
those
sets
don't
interact
with
one
another.
D
C
A
So
we
had
a
good
chat
last
week
and
I
guess
does
this
in
your
mind:
does
this
still
kind
of
fit
that
model
of
from
a
like
from
a
consuming
cluster
set
consumer
standpoint?
It's
it
still
kind
of
looks
like
the
original
concept
of
a
cluster
set,
at
least
for
all
the
namespaces.
I
have
access
to
or
yeah
that's.
D
What
I
was
shooting
for
is
like
for
the
namespaces
I
have
access
to
and
like
there's.
Also
this
like
transitive
closure
of
namespaces
hosting
services
that
I
might
consume.
So
I
might
not
be
able
to
like
do
any
kubernetes
api
operations
against
those
name
spaces,
but
I
can
still
like
dns
resolve
and
tcp
connect
to
things
in
those
namespaces.
D
If
there
was
a
good
word
to
talk
about
it,
it
was
like
the
reachability
I
guess
or
like
the
connectability
of
those
things,
and
if
you
just
like,
do
the
transitive
closure
of
everything
that
I
can
connect
to
or
that
my
the
things
I
can
connect
to
can
connect
to
then
that's
the
set,
which
might
not
be
a
full
all
the
name
spaces.
But
it's
like
that's
the
unit
that
I
think
makes
sense
and
it
like
minimizes
surprise.
It
basically
prevents
surprise
for
app
developers
when
they're
when
they're
moving
their
their
pods.
A
Or
services
around
yeah,
I
think
this
is
there's
a
lot
of
context
here.
I
think
from
that
conversation
last
week
that
may
be
hard
for
other
people
to
yeah.
A
Okay,
no,
it's
tough,
because
we
we
spoke
about
this
for
half
an
hour
and
then
wrote
it,
and
then
I
think
in
that
context
these
concise
invariants
make
a
lot
of
sense,
but
but
I
guess
the
goal
as
I
see
it
is
that
for
anyone
who
operates
in
some
set
of
name
spaces,
their
experience
is
like
the
cluster
set
as
we've
been
kind
of
defining
it.
Where
a
namespace
is
a
namespace
and
you
know
namespace,
and
this
applies
across
all
the
clusters
in
that
set.
A
But
as
someone
who
only
has
access
to
a
subset
of
namespaces
in
a
cluster,
it
is
acceptable
if
the
cluster
set
that
I
see
doesn't
actually
apply
across
all
clusters
that,
like
some
platform
administrator,
is
managing
basically
the
world
beyond
my
name,
spaces
isn't
really
relevant
to
me.
It's
is
my
interpretation.
D
B
D
D
A
Well,
I
think
so
to
me.
I
think
permissions
is
kind
of
part
of
that
like
if
I
have,
if,
if
I
have
namespace
admin
on
for
a
given
namespace
in
clusters,
a
b
and
c
and
not
in
cluster
d,
then
for
this
to
hold
true,
I
would
have
to
have
no
access
to
cluster
d.
A
Wait?
Why?
Because,
if
I,
because,
basically
that
would
imply
that
like
if,
if,
if
the
namespace,
if
somebody
else
had
that
namespace
in
cluster
d,
then
we've
kind
of
broken
this.
This
invariant
right.
D
D
D
Right
so
I
think
maybe
my
answer
for
that
is
like
we
shouldn't
just
say,
like
you,
can't
have
access
to
anything
else
on
d,
I
think
it
it
needs
to
be
like
the
isolation
like
the
the
administrator
or
the
cluster
might
be
set
up
so
that
you
don't
have
the
ability
to
look
up
or
connect
to
things
in
that
other
name,
space
in
d.
A
Okay,
I.
D
Need
to
try
to
wrap
my
head
around
this
a
bit?
Okay,
maybe
so
let
me
go
make!
This
is
not
like
yeah.
Let
me
try
to
write
this
down,
and
so
then
the
feedback
can
be
more
structured.
I
recognize
doing
this
like
verbally.
Is
it's
hard
yeah?
It's
good
planting
the
seed,
though
okay
yeah.
B
So,
where
I
was
where
I
was
coming
from,
gabe
was
like,
if
I
understood
how
you
had
characterized
your
use
case,
I
I
felt
as
though
there
was
a
a
use
case
like
there
was
a
property
like
in
how
you
characterized
your
use
case
that
originally
motivated
this
whole
thing.
C
B
D
D
Okay,
well,
thanks
for
listening
to
me,
ramble
that
was,
that
was
helpful.
B
D
B
Okey-Doke
well
sounds
like
we're
at
the
end
for
today,
thanks
everybody
for
coming
and
we'll
see
you
next
time.
Everybody
have
a
great
week.