►
From YouTube: Kubernetes SIG Multicluster 2021 April 13
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
We'll
give
it
until
about
three
after
for
folks
to
trickle
in.
B
B
All
right,
so
it
is
three
after
let's
get
started
hello.
Everyone
welcome
to
the
april
13th
weekly
meeting
for
sig
multi-cluster.
It
looks
like
laura.
You
have
the
floor.
A
Thanks
all
right,
so
I
want
to
go
through
a
few
points
from
stuff
going
on
with
the
dns
work
and
then
just
do
a
quick
call
out
about
what's
up
with
cluster
id.
A
So
regarding
dns
for
anybody
who
doesn't
know,
this
is
about
multi-cluster
dns,
so
there's
a
proposal
I
actually
probably
should
have
put
it
in
here,
but
I'm
typing
in
chat.
Sorry,
I
can't
do
two
things
at
once.
Apparently,
okay
and
there's
also
linked
a
specific
slide
with
some
background
on
it
to
you
so
I'll.
A
Add
those
to
the
agenda
notes
as
well,
but
the
sort
of
ongoing
conversation
is
happening
in
a
is
available
to
happen
in
this
pull
request
which
I'm
happily
taking
comments
to,
but
I
also
stopped
by
sig
network
two
weeks
ago
to
talk
to
them
as
well,
and
in
particular
I
asked
them
these
questions,
which
had
been
kind
of
bumping
around
from
conversations
here
at
signal-type
cluster
in
elsewhere,
the
sort
of
most
important
one
that
I'm
kind
of
going
to
bring
a
couple
points
up
today
and
then
leave
it
a
little
bit
open
for
discussion
or
just
even
advice
about
where
I
should
take.
A
This
next
is
whether
we
should
even
include
srv
records.
So
when
I
went
to
sig
network
there
were
a
couple
known
use
cases
of
srv
records
that
people
brought
up,
so
one
of
them
is
for
active
directory.
Another
one
which
had
also
been
brought
up
by
people
at
state.
Multi-Cluster
is
voip
and
then
also
about
lcd
cluster
bootstrapping.
A
So
I
did
a
little
bit
of
light
research
into
these.
I
have
a
bit
of
a
tldr,
definitely
open
to
people's
opinions
on
or
their
experiences
with
these,
I
think
the
one
I
understand
the
least
is
how
active
directory
uses
srv
records.
A
I
don't
know
if,
if
all
the
super
specifics
of
each
of
these
individually
is
worth
talking
about
or
hashing
out,
maybe
it
is
maybe
it's
not
I'm
open
to
that.
I
think
fundamentally,
my
open
question
at
this
stage
is:
are
for
these
use
cases
or
any
other
ones
that
we're
worried
about
for
now.
A
Are
the
existing
srv
records
from
cluster
local
dns
in
the
cluster.local
zone
sufficient
for
them,
and
should
we
take
that,
as
you
know,
the
the
tip
to
like
drop
srv
records
from
the
multi-cluster
dns
proposal,
or
not
so
I'll
pause
there
in
case
there's
any
immediate
feelings
based
on?
I.
B
Would
I
would
think
that
that
open
question
that
the
existing
cluster
local
implementation
is
probably
fine?
I
think
these,
if
I
remember
correctly,
were
examples
of
use
cases
that
people
are
already
running
on
kubernetes
using
server
records,
so
so
that
would
suggest
that
just
copying,
what's
what
happens
for
cluster
local
services
is
probably
the
right
move.
B
A
B
I
would
think
that
if
you
wanted
a
multi-cluster
active
directory
deployment,
for
example,
you
probably
need
multi-cluster
records.
A
A
So
yeah
but
yeah,
so
what
I'm
hearing
from
you
is
that
probably
yes
enough
these
are.
This
is
enough
motivation,
I
think,
since
we
were,
I
was
originating
from
a
point
of
oh.
Maybe
we
don't
need
srv
records
because
people
don't
use
them
and
then
obviously
they
are
used
in
these
cases
and
then
I
think
what
I'm
hearing
is.
If
these
cases
like
we
should
allow
for
people
to
deploy
these
cases
on
multi-cluster
and
therefore,
if
they
depend
on
srv
records,
we
also
need
to
include
srv
records
in
multi-cluster
dns.
That's
what
I'm
hearing.
B
A
A
Cool
okay,
then
I
will
right
now
the
this
tab.
This
pull
request
leaves
in
all
the
stuff
about
the
srv
records,
so
there
are
it's
already
still
in
here,
so
I
just
won't,
remove
it
but
still
open
to
people
taking
a
look
as
well.
A
A
Otherwise,
I'll
just
move
on
to
the
next
quick
update
so
for
cluster
id
there
is
a
poll
open
until
this
friday
for
the
name
of
the
api
group,
I
think
I
haven't
filled
it
out
here
yeah.
So
this
is
what
it
looks
like.
So
there's
some
background
info
here
here
to
explain
the
situation,
and
these
are
the
options
there's
like
a
ranking,
so
please
feel
free
to
put
in
your
two
cents.
There,
I'm
leaving
it
open
until
friday,
and
that
will
also
help
inform
a
little
bit
about.
A
We
have
opened
a
sigs
repo
for
the
implementation
to
go
right
now.
It's
named
after
one
of
these
specifically,
but
we'll
just
change
it.
If
you
know
the
the
if
it
falls
out
that
way,
you
know
like
if
the
ranking
is
different
and
also
we'll
be
going
through
api
review
with
sig
architecture.
Since
we
are
using
the
kate's
I
o
space.
So
I
think
it's
possible
that,
for
whatever
other
reasons
we
may
need
to
diverge
from
the
community
ranking,
but
we'll
definitely
use
that
as
the
basis
for
making
the
decision.
A
If
there's
no
other
restrictions,
so
yeah
just
wanted
to
call
that
out
and
that's
what's
going
on
there.
I
think
paul
was
still
going
to
give
a
look
to
the
pull
request.
So
I
can
ping
him
too,
but
there
I'll
throw
in
the
link
to
this
too,
if
anybody
hasn't
had
the
link
to
the
cluster
id
request,
as
it
is
right
now,
if
you
want
to
give
that
a
look.
B
Okay,
well
super
short
agenda
this
week.
Does
anyone
have
anything
else
they
want
to
discuss.
B
All
right,
then,
I
think
we
may
just
have
a
very
short
meeting
this
week
thanks
everyone
yeah,
please,
please
fill
out
that
that
poll,
so
we
can
decide
an
apa
group
and
and
move
forward
with
with
cluster
id.
B
Great,
thank
you
laura
and
thanks.
Everyone
have
a
great
week.