►
From YouTube: Kubernetes SIG Multicluster 2021 Aug 24
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
C
I
am,
and
it
used
to
make
it
really
easy.
When
I
tried
to
share
it
would
say:
do
you
want
to
clean
post,
but
let
me
see
unless
anybody
knows
off
the
top
of
their
head.
C
All
right:
well,
I
guess
we'll
get
started
now.
It's
four
minutes
after
our
block,
so
welcome
everyone
to
the
sig
multi-cluster
meeting
for
tuesday
august
24th
and
laura.
It
looks
like
you've
got
our
agenda
today.
So
take
it
away.
A
Okay,
okay,
hi
everybody.
I
have
two
updates.
One
is
kind
of
logistical
but
exciting
stephen
and
I
are
giving
a
talk
for
kubecon
about
multi-cluster
services.
The
the
title
is
here
b:
services
beyond
the
multi-cluster
boundary
with
multi-cluster
services.
A
So
we
have
our
recording
for
it
due
september
7th
and
we
thought
it'd
be
fun
if
we
could
have
a
virtual
audience
so
that
we,
you
know,
feel
the
energy
of
the
the
internet
tubes
but
anyway,
so
everybody
is
invited
to
come
to
a
zoom
meeting
just
like
this,
but
next
tuesday,
at
on
august
31st.
So
same
time
and
stephen
and
I
are
going
to
record
our
talk
and
then
you
can
use
the
tada
emoji
afterwards.
A
If
you
want
so
yeah,
but
we
would
really
appreciate
if
people
came
out
because
that
would
be
fun.
So
I
added
a
little
calendar,
invite
there's
a
zoom
link
on
there.
I
originated
the
zoom
link
from
a
zoom
account.
I
have
so
it's
not
like
the
sig
multi-cluster
one.
So
just
that's
not
fake.
That's
real!
So
yeah
anything
else.
Steven.
A
A
I
sent
it
out
for
some
approvals
and
got
one
lgtm
and
then
sent
for
another
approval
from
sig
network
and
we
started
discussing
more
about
ptr
records,
so
I,
as
always
prepared
some
slides
which
cleared
my
head
about
it
as
well.
I
will
mention
that
kind
of
the
tldr
like
feeling
I'm
getting
is
that
maybe
we
don't
want
to
specify
anything
super
specific
about
ptr
records
for
multi-cluster
dns,
but
I'm
going
to
explain
the
situation
a
little
bit
too
and
remind
us
of
what
the
conversation
was
about
from
the
past.
A
If
you
have
an
ip
and
you
want
to
know
what
a
cns
name
is,
you
could
ask
for
the
ptr
record
and
the
situation
and
talking
to
some
different
people
about
when
this
is
useful
in
practice,
is,
if
you
have
some
unknown
ip
address
and
like
some
request,
a
response,
log
and
you're
a
human,
and
you
want
to
know
something
about
it,
and
you
want
to
look
at
its
human,
readable,
dns
name
and
hopefully
infer
something
about
where
that
or
sorry
where
the
ip
address
is
from,
and
some
interesting
points
in
the
mcs
case,
and
also
just
the
general
kubernetes
case
for
mcs.
A
The
services
that
we
support
are
for
in
cluster
set
pod
pod
communication.
So
similarly,
there
shouldn't
be
some
like
wildly
external
unknown
ips
and
a
request
or
response
that
we
need
to
get
a
pti
record
for,
but
it
could
potentially
be
a
different
ip
than
you
requested
so
like.
A
If
I
tried
to
piece
together
the
history
of
what
ptr
records
are
generally
useful
useful,
for,
I
would
say
that
for
people
who
love
dns
and
humans
who
like
to
read
dns,
it's
a
dns
friendly
way
to
get
some
metadata
about
ip
and
then
one
kubernetes
wrinkle
about
that
is
that
in
a
kubernetes
world
for
kubernetes
managed
dns.
This
data
and
more
is
also
retrievable
from
the
api
server
like
you
need
to
know
what
an
ip
address,
what
back-end
it's
associated
with,
but
possibly
lots
of
people
and
our
clients
do
like
dns,
reverse
lookup.
A
A
At
the
time
I
didn't
like
super
know
what
ptr
records
were
useful
for
in
kubernetes,
and
this
is
kind
of
like
the
the
pieces
I
can
get
of
what
I
think
they're
useful
for
generally
and
in
this
case,
and
then
there's
a
bunch
of
slides
back
here,
where
I
tried
to
do
the
thought
experiment
of
if
we
had
a
ptr
record
either
some
of
the
ones
we've
talked
about
in
the
past
or
like
potentially
something
else
we
could
invent
like
what
would
they
be
and
what
would
they
be
good
for
and
maybe
I'll
hold
off
on,
like
going
through
all
of
them,
but
just
like,
as
a
really
brief,
like
explanation
of
what
these
look
like,
I'm
imagining
again
from
this
situation,
where,
like
you,
the
only
reason
you
a
human
want
to
use.
A
Your
ptr
record
is
because
you
made
a
request
with
one
dns
name
or
ip,
and
you
got
back
like
a
a
request
by
some
other
dns
name
or
ip
somewhere
in
in
your
logs.
So
there's
a
bunch
of
little
thought
experiments
here
of.
Oh,
if
you
wanted
to
look
up
the
dns
name
for
this
request,
ip
address.
If
the
result
was,
for
example,
dummyservice.dummynamespace.svc.cluster.local.
A
Which
is
a
possible
case,
we've
discussed
in
the
past
for
a
ptr
record,
then
in
my
opinion,
that
means
that
you
didn't
get
any
helpful
information.
I
guess
from
the
fact
that
you
could
do
this
and
the
reason
I
tried
to
have
all
these
little
thought
experiments
was
to
figure
out.
Is
there
like
a
really
strong
case
for
mcs
as
a
standard
mandating
a
certain
format
for
a
ptr
record,
or
is
there
and
all
the
way
on
the
other
side
of
the
spectrum?
C
A
C
I
I
am,
I
think,
I'm
in
the
camp
of
of
not
specifying
ptr
records
unless
there's
strong,
pushback.
B
Yeah
yeah,
I
was
just
wondering
if
there
are
ptr
records
for
local
cluster
local
services.
C
B
C
C
C
C
Right
exactly
so
so
you
would
get
I
mean
we
would
have
to
decide
what
you
get,
but
it
wouldn't
be
clear
and
you
should
you
should
definitely
get
the
cluster
local
name.
Otherwise,
you'd
be
breaking
the
service
api,
but
then
you've
got
this
interesting
behavior
where
nip
resolves
to
different
things,
depending
on
where
you
make
the
requests.
I
think
all
of
this
sounds
very
messy
to
me.
Yeah.
B
Well,
it's
only
a
factor
if
there
is
a
dummy
service,
but
then,
for
example,
on
other
other
scenarios,
you
could
have
an
implementation
where
the
you
directly
use
the
target,
pod
type
p
address
and
the
other
cluster,
and
then
what
you
get
back
isn't
going
to
depend
entirely
on
the
mcs
dns
service
right
yeah.
C
Yeah,
I
think
I
mean
the
other.
The
other
point
here
too
is:
if
we
define
ptr
records,
then
we
are
stuck
with
whatever
definition
we
come
up
with
and
it
sounds
like
this
is
going
to
be
challenging.
If
we
don't
define
them,
we
can
always
define
them
later.
C
A
Okay,
yeah,
that
is
kind
of
where
it's
been
like
dancing
around
in
the
other
like,
as
this
has
been
discussed
like
on
pr's
and
like
dm'ing
other
people,
too,
is
anybody
else
on
the
call
having
a
want
to
share
or
have
a
thought
or.
A
Cool,
okay,
so
yeah.
Basically,
I
agree
that
it's
quite
complicated
and
there
doesn't
seem
to
be
any
clear
advantage
to
make
a
rule
about
it,
especially
right
now
and
potentially
like
at
all,
or
at
least
like,
within
the
bounds
of
the
thought,
experiments
that
I've
had
thus
far
so
all
right.
A
Well,
the
rest
of
this
conversation
is
probably
going
to
hash
out
on
the
pr
so
feel
free
to
interject
there
or
anybody
if
you
want
to,
but
I
did
want
to
get
some
live
convo
and
make
sure
that
people
knew
that
this
was
going
on.
Basically
awesome
and
yeah,
I
mean
that's,
that's
it
for
that
one
and
that's.
My
last
topic
also.
C
Okay,
cool
well,
thank
you
laura!
Is
there
anything
else
anyone
wants
to
discuss
this
week.
B
Yeah,
I
just
wondered
in
terms
of
meeting
logistics,
the
invite
that's
in
everybody's
calendar
features,
both
the
zoom
call
and
the
google
meet
link.
C
Oh,
that
is
not
super
helpful.
Okay,
I'll
talk,
I
think
paul
owns.
C
C
All
right
well,
thank
you.
Everyone,
thanks
for
for
coming,
and
thanks
laura
for
for
presenting.
I
do
love
the
idea
of
having
a
virtual
audience
for
the
keep
talk.
I
think
it'll
really
help
kind
of
make
things
a
little
more
lively
right
now
and
in
this
strange
world
in
which
we
all
live,
so
you
know
anyone
who
can
attend.
Please
do
next
tuesday.