►
From YouTube: Kubernetes SIG Multicluster Nov 1 2022
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
A
B
C
All
right,
yeah
technical
difficulties,
but
I
am
in
and
the
screen
sharing
should
be
enabled
sweet.
A
My
screen
just
got
weird,
but
okay:
I
wanted
to
take
a
little
bit
of
time
to
do
a
little
kubecon
recap
debrief,
especially
from
the
stuff
that
was
specific
about
sigmc,
so
that
it's
on
the
record.
You
know,
and
also
maybe
we
can
talk
about
how
that
affects
some
new
stuff,
that
we
want
to
get
started
on,
especially
I
think
as
related
to
like
contribex
a
little
bit,
because
that
was
a
topic,
but
I
will
get
to
that
when
I
get
to
that.
A
If
that's
cool
and
yeah.
So
there's
some
notes
here
from
both
10
24,
which
is
when
we
had
a
meeting
at
the
contributor
Summit
with
I.
Don't
know
like
20
something
maybe
people
to
talk
about
a
couple,
different
topics
and
we
had
sort
of
a
split
between
people
who
wanted
to
talk
about
networking
people
who
want
to
talk
about
coordination.
So
I
want
to
go
over.
That
notes.
A
Those
notes
a
little
bit
because
I
think
that
is
very
topical
and
will
probably
inform
some
of
the
other
stuff
they
want
to
do.
And
then
I
do
want
to
highlight
that
on
10
28.
That's
when
the
intro
and
deep
dive
was
streamed,
at
least
when
I
checked
yesterday,
they're
not
on
YouTube
yet,
but
when
it
is
I'll
slide
that
in
there
so
that
people
can
take
a
look
and
then
I
did
Link
in
the
slides
as
well,
and
basically
I
made
myself
a
few
little
notes.
A
Here
of
what
I
think
the
larger
topics
or
kind
of
like
the
pull
out
topics
were
to
me
from
again
kind
of
everything.
That's
down
here
in
1024,
there's
like
lots
of
words
of
things
that
were
discussed
that
maybe
doesn't
make
a
ton
of
sense.
But
I
felt
like
these
sort
of
two
things
came
out
of
the
networking
breakout
and
then
Jeremy
I.
Don't
know
if
you
have
anything
to
add
on
from
the
coordination
breakout,
because
I
wasn't
I.
A
Wasn't
there
on
that
side
and
then
I
want
to
talk
a
little
bit
about
what
some
people
said
about
contribex
and
like
how
to
contribute
to
and
sigm
C
or
even
how
to
like
participate
in
the
in
the
calls.
A
So
I
want
to
figure
out
if
there's
any
changes
we
want
to
make
there
as
well.
So
just
a
quick
recap
of
these
two
that
were
talked
in
about
in
the
networking
breakout.
One
thing
that
came
up
a
lot
was
how
to.
A
Really
how
to
modify
or
have
some
flexibility
in
the
cluster
set,
guarantees
related
to
being
like
trusted
together
or
the
strongest
expression
of
their
trust
together
is
the
concept
of
namespace
sameness
and
one
potential
variation
of
how
this
that
such
a
thing
might
be
achieved
was
to
have
a
sort
of
different
concept
of
how
clusters
set
to
Cluster
set
interacts
with
each
other.
A
That,
maybe
is
not
a
strong
sounding
so
that
there
could
be
like
a
weaker
link
and
one
of
the
like
big
use
cases
that
was
talked
about
was
when
there's
not
some
centralized
Administration,
for
you
know
the
entire
Fleet
of
clusters
that
may
be
comprised
of
several
different
teams
that
can
manage
their
own
sort
of
trust
domain,
but
they
can't
make
as
many
guarantees
about
other
people's
clusters,
but
they
still
might
need
services
from
them.
A
So
that
was
a
discussion
point
and
I'll
pause
here
in
case.
There's
some
reaction
right
now,
but
that
was
like
a
a
pretty
main
discussion
point
I.
Do
think
that
you
know
that
the
question
of
like
namespace
sameness
and
how
it
truly
applies
has
come
up
a
couple
different
times.
A
It's
certainly
something
that
makes
MCs
at
itself
as
like
valuable
and
predictable,
as
it
is
so
sophisticating
it
more
has
its
own
trials
and
tribulations.
You
know,
but
this
was
the
latest
installation
of
kind
of
asking
that
type
of
question.
A
Okay,
cool,
so
yeah
I
will
segue
into
this
topic,
which
is
was
also
talked
about
in
the
networking
side
of
the
table,
which
was
basically
about
the
gamma
initiative,
which,
let
me
see
if
I
can
find
the
well
I.
Think
I
have
a
reference
in
here
somewhere
this
one
just
to
remind
us
of
what
this
is.
A
So
there
is
not
a
effort
within
Gateway
API
called
gamma
I,
don't
know
what
this
stands
for,
but
anyways
that
is
about
making
Gateway
API
as
it
is,
as
the
project
of
Sig
Network
and
all
the
service
meshes
converge
together,
at
least
at
the
level
which
Gateway
API
you
know
has
jurisdiction
over
and
right
now,
in
terms
of
maturity
of
this
project.
A
There
are
there's
one
cap
basically
about
how
a
service
mesh
should
be
referenced
in
Gateway
API,
that
kind
of
sought
to
make
the
minimal
amount
of
Gateway
API
like
API
changes
and
then
there's
another
work
in
progress
cap
about
how
service
meshes
should
opt
in
to
sort
of
Legacy
service.
Mesh
behavior
in
terms
of
service
Discovery
versus
more
granular
types
like
MCS
provides.
A
So
that's
really
topical
and
interesting
to
us
and
the
larger
future.
Next
projects
view
is
to
provide
some
sort
of
conformance
testing
Suite,
so
that
Gateway
API
implementations
can
make
sure
that
they're
following
including
the
service
meshes,
and
so
that's
that's
what
is
kind
of
going
on
over
there
and
some
of
it
intersects
with
us
and
about
our
like
overarching.
A
You
know
kind
of
interesting
space,
MCS
takes
about
bridging
a
gap
between
single
cluster
services
and
then
like
a
whole
service
mesh,
so
yeah,
so
that
came
up
so
I'll,
just
like
reiterate
that-
and
maybe
I'll
drop
in
here
too,
that
they're
those
two
caps
that
I
mentioned
from
gamma
initiative,
but
there's
some
energy.
You
know,
especially
from
the
gamma
folk
and
Sig
Network
too,
have
have
this
more
broadly
known
and
also
its
overlap
with
this,
you
know,
keep
the
conversation
going.
B
C
Things
that
came
up
when
we
met
up
was
that
we've
as
a
Sig,
we've
kind
of
been
over
trained,
potentially
on
networking
and
I.
Think
for
a
very
good
reason,
because
in
multi-cluster
you
need
to
solve
networking
before
you
can
really
do
much
else,
but
it
was
great
to
kind
of
talk
about
the
higher
level
issues
and
I.
C
Think
in
our
conversations,
the
big
categories
that
came
up
were
kind
of
kind
of
two
buckets,
so
one
was
like
actually
coordinating
like
getting
config
and
workloads
into
clusters
and
the
other
bucket
was
enforcement
policy.
So
there
were
some
interesting
questions
raised
like
how
do
you
actually
deal
with
with
like
mismatching
kubernetes
versions
in
your
cluster
set
and
crds
being
different?
Each
clusters?
You
know
we
talk
about
namespace
sameness.
C
Well,
you
know
no
matter
how
good
your
role,
that
is,
for
it
for
at
least
some
period
of
time,
there's
going
to
be
different
versions
in
each
cluster
within
your
cluster
set,
and
so,
if
you're,
you
know
tell
if
we're
trying
to
communicate
to
you
know,
an
application
owner
that
living
within
a
namespace
in
any
cluster
in
their
cluster
set
is
should
be
the
same,
but
there's
the
reality
of
you
know
at
least
temporary
misalignment.
How
do
we
figure
that
out?
C
I
think
another
question
that
came
up
that
I?
You
know
in
the
coordination
side
that
comes
up
every
once
in
a
while
is
like
what
does
a
multi-region
I
would
control
plane
look
like?
C
Is
that
actually
a
multi-region
cluster
personally
I?
Don't
think
it
is
because
you
know
when
you
spread
your
STD
replicas
across
regions.
Things
get
really
interesting,
but
clearly
we
do
need
some
kind
of
multi-region
controller,
or
at
least
something
that
can
be
deployed
multi-regions.
So
some
some
sub
set
of
functionality
came
up
as
kind
of
an
open
question,
and
the
last
thing
that
came
up
is
maybe
the
Sig
could
could
do
a
better
job
of
writing.
You
know
tutorials
for
people
getting
started,
for
you
know
how
do
I
use.
C
A
Yeah
I
think
good
psych
way
to
the
topic
of
contribex
because
definitely
like
there
are
a
lot
of
new
faces
at
the
meet
and
greet
for
the
contributors
Summit
for
Sig
multi-cluster,
but
like
well.
A
First
off
it
was
a
great
opportunity
for
us
to
be
like
hey
what
would
make
it
easier
for
you
to
contribute,
and
they
were
very
helpful
to
indicate
that,
like
our
existing
projects
are
kind
of
confusing,
at
least
in
terms
of
how
they're
supposed
to
be
used,
how
they're
supposed
to
be
used
in
conjunction
with
other
things,
I
think
that's
come
up
here
too
about
like
we
can,
you
know,
say
in
the
sick
meeting
that,
like
best
practices
Gateway
for
north
south
and
MCS
or
east
west,
but
without
enough
you
know
examples
or
articulation
of
that
outside
of
there.
A
It's
not
super
clear
and
then
even
from
the
contributing
standpoint
there
was,
you
know
like
one
of
the
kind
of
long-standing
issues
for
MCS
has
been
working
on
some
of
the
end-to-end
tests,
but
there
was
interest
and
like
if
there
was
a
sort
of
Deep
dive
on
how
that
works,
and
then,
in
any
case,
that's
relevant.
A
If
we
want
people
to
use,
if
we
want
implementations
to
use
them
as
conformance
tests,
which
is
the
idea,
then
like
the
people,
need
to
know
how
it
works,
so
at
least
for
that
specific
one
in
the
short
term,
like
I,
put
a
q
for
the
next
one.
To
talk
about
that,
interestingly,
gamma
API
is
actually
having
this
exact
same
question
about
conformance
tests
so
like
we're
all
doing
the
same
thing
at
the
same
time
but
yeah
there
was
basically
this
like
lack
of
like
documentation
and
then
there.
A
The
other
point
was
not
enough.
Other
topics.
Besides
networking,
even
though
there's
appetite
for
this
coordination
category,
it's
not
talked
about
a
lot,
and
you
know
I
think
that's
just
a
matter
of
like
what's
on
the
agenda,
but
I
think
we
can
yeah.
Maybe
this.
A
On
the
first
hand,
this
is
a
call
to
everybody
of
how,
like
a
lot
of
people,
want
to
talk
about
that
and
bring
their
use
cases,
and
we
can
make
sort
of
more
fertile
ground
for
that
I
think
by
maybe
like
pre-scheduling
some
like
specific
day.
A
That's
like
coordination,
takeover
or
tap
takeover
or
whatever
for
a
meeting
and
like
get
the
word
out
a
little
bit
on
the
mailing
list,
so
people
know
to
show
up
and
bring
their
use
cases
instead
of
it
being
kind
of
like
reactive
to
what's
topical
of
the
week
on
someone's
mind.
A
So
that's
an
idea
there
and
then
one
thing
I
wanted
to
bring
up
here
in
this
category
is
on
the
point
of
lack
of
documentation,
tutorials
Jeremy
you're,
just
talking
about
the
readme
or
putting
some
documentation
in
the
GitHub,
which
is
great
people,
were
talking
about
how
Gateway
API
has
this
cute
little
Sig's
website?
That's
like
really
user
friendly
and
and
give
some
broader
info
and
I
expect.
Some
I
actually
already
know
that
some
of
the
gamma
work
is
encapsulated
in
here
and
I.
A
Don't
know
if
this
is
I,
don't
think
we
have
the
bandwidth
to
do
this,
something
like
this
right
now
or
Alone
for
our
sub-projects,
but
I'm
wondering
if
this
is
like
even
a
direction.
We
want
to
go
because
this
is
kind
of
I
feel
this
is
kind
of
a
larger
question
of
like
for
things
that
are
out
of
tree.
A
Where
does
their
like
documentation
go,
and
then
even
more
meta
for
things
that
are
out
of
tree
that
interact
together
like
Gateway,
API
and
MCS,
where
you
need
to
turn
both
of
them
on
to
get
the
full
experience
like?
How
do
we
connect
the
dots
there
just
outside
of
just
in
our
separate
little
implementation,
docs
or
outside
of
maybe
our
individual
Sig
docs,
or
something
like
more
together.
C
The
idea
of
of
having
like
a
sigmc
website
where
we
can
make
things
a
little
more
discoverable
than
reading
random
readies,
sprinkled.
C
You
know
I
think
that's
something
we
could
publish
on
both
on
both
sites
but
yeah.
This
is
part
of
definitely
part
of
an
open
question
of
how
to
out
of
tree
things,
get
visibility,
yeah
I
personally,
like
the
Gateway
API
website
and
would
not
be
opposed
to
using
it
as
a
template.
Yeah.
C
Yeah
yeah
Mike
agree
100.
C
Centralized
discoverability
ability
for
would-be
end
users
is
a
deaf
big
benefit
that
is
more
needed
with
energy
work
yeah.
So
I
think
this
is
something
we
can
take
a
look.
It's
maybe
getting
started
in
the
next
few
weeks.
Let's
see
what
what
we
can
do
and
what
content
we
can
put
there.
But
if
anyone
is
interested
in
maybe
we
can
send
a
blast
out
to
the
Forum
too,
but
anyone's
interested
in,
like
just
writing
out
some
getting
started.
C
Tutorials
that
would
be
really
cool.
Yeah.
A
Well,
okay,
yeah
I.
Think
probably
we
need,
like
the
scaffolding,
the
skeleton
which,
hopefully
we
can
just
like
savagely
clone
Gateway
API
The
Knowing,
some
Gateway
people
are
in
this
call
right
now
you
have
been
warned
but
yeah
I.
Think
then
there's
a
place
that
even
like
you
know
to
our
question
before
of
like,
can
some
people
write
some
tutorials
or
that
you
know
that?
That's
like
a
opportunity?
A
If
we
are
in
the
mood
for
not
a
readme
lifestyle
but
more
of
a
website,
lifestyle
than
I
think
we
can
initiate
the
scaffolding
so
that
there's
somewhere
for
people
to
put
in
yeah
and
Mike
also
mentions
in
the
chat
that
it's
a
good
on-ramp
for
new
contributors
to
get
more
engaged
in
a
ten
thousand
percent.
Agree
that
that's
the
case
so
I
think
that
helps
achieve
some
of
our
contribbeck's
goals.
A
So
yeah,
so
that
was
like
the
recap.
From
my
perspective,
at
least
for
like
the
Sig
multi-cluster
Hangouts
did
I
miss
anything
glaring,
Jeremy.
A
Yeah
I'll
mention
that
scrolling
down.
There
are
other
topics
in
here
with
some
notes,
especially
like
things
that
were
kind
of
ongoing
projects
that
I
just
wanted
to.
You
know
mention,
but
we
weren't
like
heavily
discussed.
A
So
some
of
those
notes
are
in
there
and
then
just
to
separate
other
sort
of
thing,
not
from
the
conversations
that
were
specific
to
Sig
and
see
like
not
the
meet
and
greet
for
sigmc,
but
just
like
around
the
conference.
I
personally
was
looking
for
a
lot
of
like
talks
about
that,
at
least
like
mentioned
multi-cluster,
you
know
to
see
what's
going
on
and
I
did
feel
like
there's
some
interesting
stuff
coming
out
of
controller
runtime
and
the
operator
SDK.
A
So
there's
a
talk
about
that.
That
was
by
some
red
hat
folks
and
was
like
ultimately
about
ocm,
I
think,
like
fundamentally
at
least
multi-cluster
part
of
it.
The
talk
was
kind
of
about
something
broader
than
just
multi-cluster,
but
there
was
some
sort
of
like
that.
That
service
needs
to
provide
a
like
multi-cluster
control
plane.
A
Basically-
and
there
were
some
ideas
in
there
about
both
how
to
deal
with
your
existing
controllers
and
also
like
what
that
means
for
any
like
sort
of
cluster
registry
or
sort
of
centralized
broker
type
thing,
so
yeah
I
think
that
might
be
some
fertile
grounds
for
discussion
in
the
future
too,
and
something
that
yeah
I'm
happy
to
facilitate
and
follow
up
on,
either
in
the
slack
or
or
as
an
agenda
topic
for
people
who
are
interested
in
the
multi-cluster
control
plane
and
like
coordination,
question,
I'm
sure
work.
A
So
yeah
those
were
my
hot
takes.
This
has
been
hot,
takes
with
Laura
kubecon
hunt
takes
thank
you
Laura
yeah,
so
but
that's
what
yeah
that's
what
I
kind
of
wanted
to
cover
today
and
then
hopefully
this
can
give
us
some
fertile
ground
for
kind
of
like
the
next
set
of
work.
B
C
Thank
you,
Laura
looks
like
that's
our
agenda
for
today's.
Unless
anyone.
C
All
right:
well,
thanks!
Everyone
we'll
see
you
soon
and
on
slack
cool.