►
From YouTube: Kubernetes SIG Multicluster Aug 9 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).
C
Yeah
I
got
I
had
some
weird
issues
with
my
headphones.
Connecting,
let's
see.
C
C
Okay,
all
right,
why
don't
we
go
ahead
and
get
started?
I
think
there's
there's
one
topic
on
the
agenda
and
it's
mine,
which
is
follow
up
on
the
discussion
that
we've
been
having
on
archiving
cube
fed.
I
have
just
recently
this
morning
posted
a
message
to
the
kubernetes
sig
multi-cluster
mailing
list,
with
the
the
the
readout
from
the
discussion
that
jeremy
and
I
had,
and
I
would
say
not
to
bury
the
lead
like
tldr.
C
We
are
currently
feeling
that
archiving
the
cube
fed
repo
is
our
best
available
option.
I'll
just
go
ahead
and
stop
there
and
you
know
see
if
there's
a
need
to
continue
talking
about
that
like
because
if
everybody
here
has
read
the
email,
then
I
don't
imagine
that
there
really
is.
C
B
A
Yeah,
I
would,
I
would
second,
that
I
think
the
decision
to
archive
and
any
potential
replacement
those
are
kind
of
two
separate
threads
like
we
could
have.
We
could
promote
other
projects
without
archiving
and
we
could
archive
without
promoting.
I
think
I
think
the
important
thing
is
to
send
a
message
and
make
it
clear
that
you
know
what
what
users
should
expect
in
terms
of
support
like
the
code's
never
going
away.
You
know,
I
think
paul
did
a
good
job
in
the
email
of
summarizing
things.
It's
still.
A
C
Yeah,
I'm
I'm
reading
through
the
the
comments
on
the
on
the
message
right
now.
It's
a
lot
of
plus
ones.
I
think
the
there
are
a
couple
questions
that
I'll
call
out
here,
which
is
one
is
from
david
bainbridge
who
says:
what's
the
support?
What's
the
approach
from
the
six
perspective
on
supporting
multiple
clusters,
including
scheduling
resources
across
multiple
clusters,
from
a
single
manifest?
C
C
All
of
the
experiences
I
have
personally
had
trying
to
solve
that
particular
problem
have
ultimately
introduced
high
amounts
of
friction
or
high
amounts
of
api
breaks
from
the
standpoint
of
shoving
behaviors
into
annotations,
really
trying
to
take
like
an
envelope
and
put
about
three
times
as
much
stuff
in
it
as
is
supposed
to
go
in
there.
C
At
this
other
house,
so
it
my
own
personal,
unfiltered
opinion
here,
I'm
just
not
sure
that's.
That
is
a
problem
that
needs
a
solution
in
the
sense
that
there
are
many
tools
that
people
are
re
are
already
successfully
using
to
do
elements
of
that
problem
in
ways
that
are
widely
used
today.
C
A
Yeah
kind
of
similar
ones,
I
think
I
think
it's
clear
that
there's
requests
for
the
sig
to
figure
out
how
to
how
best
practices
or
guidance
for
how
to
deploy
workloads
to
multiple
clusters.
I
I'm
kind
of
with
paul
I'm
not
sure
that
that's
necessarily
means
from
a
single
manifest.
I
think
the
other
thing
that
we've
seen
is
that
maybe
the
idea
of
you
know
generically
sharing
config
across
clusters
is
is
more
difficult
like
maybe
maybe
the
the
process
of
deploying
to
clusters
needs
more
more
object.
A
Awareness
like
the
way
we
do
we
deal
with
config
maps
might
be
significantly
different
from
the
way
we
deal
with
applications
the
so
I
think
this
space
in
general
still
needs
solutions,
but
I
kind
of
agree
that
you
know
getting
laser
focused
on
specific
paths
may
not
be
the
the
best
way
to
approach
this
and
there
are
a
bunch
of
solutions
being
developed
right
now.
A
So
I
think
we
we
probably
want
to
learn
from
them
and
see
what
the
remaining
gaps
are
versus
trying
to
trying
to
just
you
know,
enforce
standards
where
standards
may
not
be
that
necessary.
C
Yeah,
I
I
another
another
thing
that
I'll
just
share
really
quick
on
that
subject
is
that
I
think
that,
in
a
hypothetical
scenario
where
I
was
deeply
convinced
that
that
problem
needed
a
solution
and
that
that
problem
needed
a
solution
that
came
from
this
sig
that
I
would
view
it
as
one
of
the
last
problems
to
solve,
in
the
sense
that
if
you
want
to
have
an
some
technology
that
solves
the
problem
of
having
a
single
manifest
that
is
delivered
correctly
and
localized
correctly
to
an
arbitrary
number
of
different
kubernetes
clusters.
C
Probably
what
I
would.
What
I
would
want
to
do
is
feel
like
we
had
more
of
the
problem
space
of
like
the
actual
sub-problems
that
we
would
be
kind
of
bringing
together
at
that
level
before
we
tried
to
solve
that
that
problem
of
delivering
the
manifest
and
differentiating
them
by
cluster,
et
cetera,
et
cetera.
I
don't
think
that
we
have
enough
information
to
solve
that.
C
Yet,
for
example,
you
know
the
there's
any
number
of
subproblems
that
we
might
choose
to
tackle
and
that
we're
already
tackling
that
probably
hinge
or
are
hinges
that
you
know
an
eventual
solution
for
delivering
resources
could
could
swing
on.
For
example,
cluster
id
is
pretty
easy
to
imagine
that
you'd
want
more
certainty
on
cluster
id
as
a
useful
coordinate
for
addressing
differentiations,
and
maybe
you
want
some
kind
of
coordinate
for
like
a
zone
or
a
region
as
well
and
have
a
well-understood
meaning
of
what
that
is.
C
We
don't
have
those
yet
so
you
know
I
whether
or
not
I
personally
think
it's
something
that
the
si
sig
should
address.
In
any
case,
I
don't
think
that
we
have
enough
information
to
do
so.
Yet
my
own
opinion-
and
I
know
david-
isn't
here-
I'm
like
this-
isn't
the
end
of
the
discussion.
C
Honestly,
I
had
planned
to
send
that
message
about
a
week
earlier,
so
folks
could
have
more
time
to
digest
and
clear
their
schedules
and
everything.
This
isn't
the
end
of
the
discussion,
we'll
we'll
keep
comments
open
for
at
least
another
sig
meeting.
I
would
say:
don't
you
think,
jeremy.
A
A
This
is
this
is
the
way
where
we're
leaning-
and
I
think
you
know
paul.
You
said
in
the
email
that
you
know
after
some
period,
we'll
yeah
the
two
weeks
I
think,
makes
sense
and
then
we'll
we'll
actually
give
a
timeline
for
archival,
so
that
there's
there's
room
for
cleanup
and
and
all
that.
C
Yeah
I'll
make
sure
to
respond
to
david
about
his
question
that
he's
raised
so
that
it's
not
like.
Oh,
we
just
talked
about
that
in
the
sig
and
you
weren't
there
so
yeah.
I
think
I
think
that's
that's
one
of
the
big
ones
that
comes
out
of
the
responses
so
far.
C
There
is
also
the
represented,
I
think,
from
david
oppenheimer
about
the
the
question
that
mike
ing
raised
in
this
in
this
meeting
about.
Are
we
going
to
to
give
pointers
to
people
and.
C
We
can
give
pointers
but
like
when,
I
think
about
making
recommendations,
it's
extremely
hard
to
make
a
recommendation
in
a
vacuum,
because
so
many
people
have
deployed
kubernetes
in
so
many
different
ways,
not
in
the
sense
of
like
mechanically
how
they
were
deployed,
but
how
they're
managed
and
how
they're
treated
and
how
they're
thought
of
what
semantics
are
are
impressed
on
them.
How
tenancy
is
dealt
with?
I
I
do
not
think
that
we
have
enough
information
about
that
to
make
a
responsible
recommendation
for
people.
C
It's
it's
really
hard
to
make
good,
but
very
general
advice
right,
like
usually
the
best
advice
is
advice
that
comes
from
someone,
that's
familiar
with
the
details
of
whatever
situation
they're
advising
about
so
I
think
we
can
give
pointers,
but
I'm
I'm
less
interested
in
giving
general
advice,
because
I
think
it
would
be
very
hard
to
give
general
advice.
That's
also
useful.
C
C
B
A
B
Skin
in
this
game,
as
not
super
involved
in
cuphead,
but
I
think
definitely
like
reading
through
everything
on
slack,
I
think
this
you
know,
makes
sense
for
this
case
and
then
yeah.
B
I
agree
with
the
point
about
making
recommendations
being
very
difficult
without
more
information,
especially
if
it's
going
to
be
about
like
some
specific
third-party
thing-
and
I
don't
know
if
that's
yeah,
so
I
guess
I
agree
with
that,
and
then
I
think
if
we
were
to
at
least
provide
some
information
about
those
in
some
centralized
place,
there's
probably
like
a
way
that
we
would
need
to
articulate
that
and
that
maybe
would
be
the
furthest
it
would
go.
C
Yeah,
I
think
I
think
it
will
be
so
I
think
I
think
what
what
it
would
look
like
mechanically
if
we
keep
on
this
direction,
is
that
we'll
make
an
announcement
on
the
main
kubernetes
mailing
list,
as
well
as
on
the
sig
mailing
list,
and
that
announcement
when
it
comes
we'll,
have
a
timeline
and
an
accounting
of
exactly
what
does
it
mean
since?
C
Probably
not
everybody
is
familiar
with
the
with
all
of
the
details
of
what
does
archiving
mean
and
archiving
sounds
a
lot
like
a
destructive
action
when
it's
really
not
so
you
know
in
terms
of
like
keeping
with
the
values
of
our
community,
like
transparency
and
allowing
people
the
ability
to
plan.
I
think
that's
that's
what
things
would
look
like,
I
think,
there's
probably
it
would
be
good
to
have
a
tombstone
commit
go
into
cube,
fed
explaining.
C
You
know
why
it's
archived,
and
maybe
I
don't
think
I'd-
want
to
put
pointers
into
that,
but
I
think
they're.
We
can
at
least
have
a
like
a
brief
accounting
of
why
it's
archived
and
maybe
a
link
to
mailing
list
discussion
around
it
or
something
like
that.
B
As
formal
as
a
tombstone
and
permanent
you
know
or
like
as
an
artifact,
it's
hard
to
update.
C
A
Yeah
and
and
the
other
thing
with
pointers,
it
can
be
really
hard
for
future
readers
to
differentiate
between,
like
here's,
some
other
projects,
and
we
recommend
these
other
projects
right
so
and
then
we
run
into
the
issue
of
like
we.
We
don't
know
everything
that's
out
there
and
we
don't
want
to
overlook
anyone
just
because
these
are
some
we
know
about.
You
know
I
think
mailing
list
is
a
much
more
informal
way
to
gather
that
kind
of
information.
A
C
Happy
tuesday
and
I'll
just
mention
folks
that
I've
been
making
an
effort
to
make
sure
that
we
post
the
recordings
as
they
go.
We
should
be
up
to
date,
except
for
today,
which
we
haven't
finished,
recording
yet
I'll
make
sure
this
one
gets
up
thanks
a
lot
thanks.