►
From YouTube: Kubernetes SIG Multicluster 31 May 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).
D
C
All
right
we'll
wait
a
moment
and
then
we'll
get
started.
C
All
right,
why
don't
we
go
ahead
and
get
started?
Welcome
everybody
to
the
tuesday
may
31st
2022
meeting
of
kubernetes
multi-cluster.
I
believe
we
have
one
entry
on
the
agenda
today
and
that
is
from.
B
B
Okay:
okay,
at
the
last
meeting
mike
president's
proposal
about
how
to
sync
status
for
the
work
api
and
there
is
another
solution
in
the
proposal
that
adds
a
standard
field
to
to
the
status.
B
Here
today,
I'm
going
to
share
some
information
from
camara
system.
It.
B
B
B
Okay,
before
the
before
we
talk
about
the
work
api,
I'm
going
to
introduction
command
system
commander
is
the
kubernetes
management
system
that
enables
run
and
enables
you
to
run
workloads
to
to
across
multi
clusters.
B
B
Okay,
here
is
the
kamala
architecture.
The
architecture
of
a
commander
is
very
similar
with
the
communities
the
kamada
api
server
now
built
based
on
coupe
api
server.
So
that's
the
that's.
The
reason
why
camada
compatible
with
kubernetes
native
apis
and
camara
extends
the
api
by
both
crd
and
aggregated
api
server.
B
The
the
commander
takes
scheduler
responsibility
to
schedule,
workloads
to
memory
clusters
for,
for,
for
example,
deployment
might
be
propagated
to
member
two
class
y
and
class.
Two
after
the
the
scheduled
decision
made
by
commander
scheduler,
the
controllers
will
put
that
put
the
workloads
to
a
namespace.
We
called
execution
space.
Each
cluster
owns
one
execution
space
it
in
space
and
after
that,
the
execution
controller
which
mode
like
the
postman
will
applies.
The
workload
to
the
memo
cluster.
B
Here
is
a
core
concept
of
camarader.
First,
the
result
template
let's
take
a
deployment
as
an
example.
After
we
apply
applied
deployment
to
commander
control
plane,
there
will
be
no
poles
created.
B
We
we
treat
the
deployment
as
a
temp
template,
as
mentioned
before,
commander
accents
the
apis
by
crds,
such
as
the
provoking
policy
resource
funding
and
override
policy
and
the
work
api
comes
from
the
kubernetes
sigmoid
cluster.
B
The
propagation
policy
defines
the
skating
rules
about
how
to
and
how
and
where
to
apply
the
resource,
template
and
the
research
binding
used
to
hold
the
scaling
results
for
each
resource
template
and
the
override
policy
defines
the
rules
about
how
to
override
the
result
template.
For
example,
the
image
registry
might
be
different
for
each
clusters.
B
B
That's
let's
hold
on
for
a
moment
any
question
here
for
the
commander
introduction.
B
B
B
B
You
can't
see
that
the
status
nodes
is
is
different
with
the
combinated
kubernetes
development
status.
It's
just
the
fragment
of
the
status
here.
The
question
is:
how
do
we
know
how
many
fields,
or
which
fields
should
be
put
into
the
status
for
each
kind
of
a
combinated
resource
of
crds.
B
B
Actually,
the
the
status
functionality
is
just
one
of
the
functionalities
of
a
resource
interpreter.
Eight
there,
the
interpreter
status.
We
call
that
a
web
a
function,
a
function
yeah,
it
helps
to
grab
status
for
any
kind
of
resources.
We
we
defined
a
reflect
status
interface
and
we
can
embrace
the
the
interface
for
each
combinated
resources.
B
A
B
Example
of
the
conflict,
the
con
the
configuration
example
of
the
resource
interpreter
webhook
people
can.
B
Yeah
any
questions
from
here.
B
Okay,
the
the
future
of
a
result
interpreter
we
are
going
to
to
try
some
things
like.
B
E
So
so
kind
of
in
the
in
the
helpful
flow
diagrams
you
had
a
few
slides
ago.
This
kind
of
interpret
status.
Am
I
right
in
thinking
that
its
purpose
is
simply
to
sort
of
propagate
the
status
back
from
the
child
clustered
to
the
work
custom
resource
yeah?
Yes,.
A
E
B
E
I
guess
I'm
just
wondering
is
the
is
the
is
the
goal
to
get
the
status
all
the
way
back
to
the
original
resource?
That
was
that
was
applied
to
the
carmada
api
server,
or
is
it
just
to
propagate
status,
to
the
work
custom
resource.
B
Yeah
a
good
question:
I
get
height
the
here.
I
go
back
to
the
previous
previous
slice.
Here
we
are
talking
about
the
interpreter
status
age
focused
on
managing
the
status
from
mining,
cast
memory,
cluster
to
work,
object,
yeah,
this
interpreter
status,
and
after
that
we
also
have
other
functionalities.
B
E
B
Okay,
let's
move
on
here
is
yeah.
I
think
it's
the
last
slash
here
and
my
question
is:
is
how
do
you
think
the
the
solution
and.
A
I
would
like
to
ask
what
do
you
think
about
so
we
we
like
the
fact
that
we
should
have
more
flexibility
in
the
work
api
proposal
to
hold
other
fields
such
as
the
the
wire
type.
So
in
the
proposal
right
now,
kijang
mentioned
that
will
fall
back
to
a
wall
string
and
if
you,
if
you
go
back
to
the
pr
the
so
what
do
you
think
about
that?
A
So
the
the
reason
we
want
to
fall
to
fall
back
to
wash
string,
and
so,
while
extension
is
because,
echoing
what
the
api
machinery
maintainer
mentioned,
while
extension
as
documented
right
now,
it's
it
says
it's
supposed
to
hold
the
complete
kubernetes
object
with
the
api
version
and
kind
fields,
so
we
feel,
like
the
y
extension,
might
not
be
the
right
type
to
hold
to
our
object
so
at
the
at
the
bottom.
If
you
scroll
to
near
the
bottom,
I
think.
D
A
B
My
concern
is
the
the
rules
about
how
how
to
and
how
how
to
collect
the
status
status
for
for
a
resource
should
not
define
in
the
work
api,
because
the
work
api
is
a
specific
object
for,
for
example,
you
can
define
a
rule
for
deployment,
but
I
don't
think
the
rule
should
be
put
into
the
work
object
in
in
different
work
objects.
A
Yep,
I
think
we
we
discussed
that
in
the
pr
as
well.
We
mentioned
that,
instead
of
having
the
rules
hard
coded
defined
in
the
work
option,
we'll
have
a
reference
to
a
another
object,
so
in
the
work
it'll
be
just
we'll.
Just
have
a
pointer
to
that
up,
object
reference
to
that
that
rule
or
policy
that
defines
what
status
to
capture
but
going
back
to.
Let's
say
we
have
the
rule
capture,
and
then
you
mentioned
that
you
would
like
us
to
store
more
more
values
outside
of
integer
string
and
boolean.
A
B
Actually,
I
act
as
articular
example
from
shoojin
and
she
gives
a
get
example
here.
I
think
the
the
it
might
be
looks
looks
like
a
little
bit
ugly,
no
fun.
A
Yep
but
the
interpreter
of
these
resources,
or
this
the
cr
is
usually
machine.
It's
not
meant
for
users
to
consume
right
is
that
is
that.
B
Agree
that
yeah
the
work
api
should
not
be
intended
for
user
to
to
to
to
to
consume,
but
if,
if,
if
people
debug
on
it,
it
is,
for
example,
it
could
control
get
the
work
object.
A
A
This
is
supposed
to
hold
the
complete
kubernetes
object
with
the
api
version
and
kind
so
that
that
is
our
only
concern
here,
because
in
the
in
the
work,
api
spec,
it
does
have
the
manifest
view
and
that
manifest
field
is
a
wire
extension,
but
that
actually
holds
the
complete
kubernetes
object,
and
here
we're
proposing
we're
only
returning
the
the
status
part
I
mean,
and
the
status
is
not
a
complete
object
right.
So
that's
that's.
Where
we're
a
little
bit
stuck
on,
I
guess
so.
A
We
would
love
to
hear
more
feedback
from
the
outside
community,
because
because
of
this,
this
topic
paul,
do
you
have
any.
B
C
So,
specifically
around:
let's
talk
about
the
piece
that
had
the
field
referencing
a
lua
script.
Can
we
do
that
really
quick?
I
think
that
was
one
of
the
last
slides
that
you
showed
this
is
why
yeah
so
one
thing
that
wasn't
clear
is
whether
status
interpreter
was
in
work
api,
or
is
this
in
a
layer
that
exists
in
karmata.
B
This
status,
integrator
structure
is
now
is
in
our
proposal.
We
haven't
implicit
and
implemented
it.
B
So
and
but
I
I
suppose
the
the
configuration
should
be
should
be
done
by
some
some
apis
like
like
this.
We
define
a
rule
about
how
to
collect
the
status
from
the
minecraft
memo
cluster
for
a
resource
yeah.
That's
the.
B
Yeah,
I
think,
for,
for
example,
we
can
specific
a
rule
for
for
deployment.
C
C
B
Yeah,
I
I
want
a
if
we
can
work
out
a
common
api.
I
think
I'm
okay
to
put
it
in
the
work
api.
C
Okay
sounds
like
it
sounds
like
it
doesn't
necessarily
have
an
intended
home,
yet
in
general,
here's
what
I
think
this
this
resource
is
for.
I
only
have
a
few
minutes.
I've
gotta
I've
gotta
stop
at
five
after
unfortunately,
but
I
I
it
sounded
to
me
like
this
resource,
was
to
characterize
a
reusable
piece
of
configuration
that
knew
how
to
unpack
the
status
from
something
that
was
delivered
by
work
and
return
a
a.
I
think
it
was
a
manifest
status.
C
Yes,
okay
with
the
goal
being
to
and
and
this
touches
a
question
that
was
asked
earlier,
just
to
make
sure
that
I
understood
the
goal
of
doing
this
is
to
surface
the
status
if
it
is
desired
to
do
so
surface
the
status
of
resources
deployed
by
a
manifest
work
into
the
into
the
manifest
status
field
of
a
manifest
work
right.
C
There
were,
for
example,
I
want
to
say
that
there
were
issues
raised
about
turning
config
map
into
or
using
configmap
as
a
template
that
would
have
similar
semantics
to
the
the
scripting
field
called
retention
lua
in
this
example.
It's
definitely
something
that
I
would.
I
would
spend
a
little
time
trying
to
understand
the
prior
art
and
discussions
on
semantics
of
putting
any
kind
of
code,
type
of
content
or
script
type
of
content
into
a
field
like
that
yeah.
C
That's
probably
the
thing
that
jumps
out
at
me
for
now.
I
don't
know
if
anybody
else
like
had
a
had
a
light,
come
on
on
their
dashboard,
seeing
the
embedded
lua
there,
but
that
was
one
thing
that
jumped
out
to
me
in
general.
I
think
it
makes
sense
that
manifest
work
would
encapsulate
you
know,
being
able
to
understand
the
status
without
having
to
go
out
to
the
remote
cluster.
C
One
thing
that
was
raised
previously
that
I
didn't
see
represented
here
today,
was
about
the
configuring,
the
frequency
of
the
updates
and
fidelity
of
the
status,
so,
for
example,
if
if,
for
example,
we
would
expect
to
represent
every
single
status
change
like
watch
event
by
watch
event,
that's
a
very,
very
different
level
of
qps.
C
C
C
You
know
like
what
the
api
constructions
are
to
capture
the
transformations,
because
in
a
sizable
deployment
where
you
know
you
forget
about
scale
of
number
of
clusters
for
a
moment
like
in
in
a
deployment
where
there
are
large
numbers
of
resources,
the
qps
required
to
reflect
their
status
could
absolutely
become
one
that
might
significantly
compromise
the
scale
that
manifest
work
could
be
used
at
and
normally
I
would
expect
that,
for
example,
there
are
different
parts
of
the
lifetime
of
a
resource
deployed
by
manifest
work,
where
different
levels
of
granularity
for
status
updates
are
required.
C
So,
like
one
other
thing
to
throw
out
there,
around
qps
management
would
be
that,
if
I
think
of
a
deployment,
there
are,
for
example,
different
parts
of
that
deployment's
lifetime,
where,
when
we,
when
we
initially
created
deployment,
we're
frequently
very
interested
in
the
status
for
the
next
five
ten
minutes
or
until
you
know
the
the
number
of
replicas
we
desire
become
available
after
after
which
we're
probably
not
going
to
look
at
that
status
every
moment
for
some
amount
of
time
right.
C
So
I
think
it
would
be
worth
characterizing
patterns
of
qps
use
to
encompass
things.
Like
we're
probably
most
most
interested
in
the
status
of
a
deployment
after
the
spec
changes,
or
it's
initially
deployed
right,
I
think
that
would
certainly
be
information
that
would
help
on
help
folks
understand
what
the
you
know.
What
the
the
steady
state
qps
patterns
look
like
that
are
important
to
understand.
As
we
talk
about
the
api
constructions,
unfortunately,
I've
got
to
stop
now.
C
You
are
all
welcome
to
keep
going
through
the
end
of
the
time,
but
I
need
to
drop
at
this
moment
thanks
a
lot
rainbow
mango
for
for
coming
and
presenting
today.
B
A
A
B
A
A
But
I
think
in
the
in
the
proposal
we
mentioned
that
the
word
api
will
have
a
object
reference
to
the
rule,
so,
for
example,
if
if
we
were
to
use
status
input
interpreter
it
will
it
will
point
at
the
status
interpreted,
so
that
leaves
it
a
little
bit
more
open.
Okay,.
B
So
how
about
let's,
let's
look
together
to
try,
work
out
the
congregation
and
the
congregation
api
defines
how
to
how
to
sync
the
status
and
yeah.
We
also
put
the
two
qps
thing
in
in
the
configuration.
F
B
Okay,
let's
assume
that
we
are
gonna,
be
we
are
gonna,
be
have
a
new
api
yeah
so
back
to
the
the
proposal,
how
to
define
the
the
the
status
thing
still.
B
Yeah
now
how
to
show
the
status
what's
your
opinion
now?
Is
this
very
acceptable?
Yeah
ignore
the
the
the
field
type?
We
can
change
to
something
like
bad
slash.
A
I've
I
feel
like
we
so
leaving
it
as
a
bite,
slice
or
leaving
as
a
war,
might
be
a
bit
too
open.
I
feel
like
if
we
have,
if
we
have
the
predefined
fields,
that
we
specific
the
type
of
the
of
the
status
that
may
be
a
little
bit
safer
in
terms
of
security,
but
we
do
have
the
the
wall
by
to
fall
back
upon.
A
So
something
like
what
kujang
suggested,
I
feel
like
that
might
be,
might
be
a
better
approach
where
it's
up
to
the
the
the
consumer
of
the
api,
if
they
want
to
use
a
user
type
for
safety
or,
if
they're
willing,
to
give
up
some
of
the
security
and
use
a
more
open
type
such
as
bytes
or
wire
or
something
else.
A
Because,
because
on
the
on
the
status
part,
it's
it's
actually
returning
from
a
from
a
cust
from
a
cluster
back
to
the
centralized
or
hub
location.
So
we,
which
we
kind
of,
want
a
little
bit
of
security
around
that,
unlike
the
work
spec,
which
is
defined
from
a
centralized
location
and
propagate
down,
where
we
can
be
more
open
and
say,
hey
here's,
the
wall
extension
for
the
whole
object,
because
this
is
coming
back
from
we.
This
is
returning
back
from
a
member
cluster.
A
We
feel
like
it's
better
for
security
if
we
have
some
type
of
type
definition
to
ensure
that
you
know,
maybe
the
data
is
not
too
big
against
a
malicious
actor,
for
example.
A
So
that's
why
I
think
kyojin
and
minkam,
and
some
of
the
folks
mentioned
that
we
should
have
some
type
defined,
but
we
also
allow
for
the
a
little
bit
more
open
if
the
consumers
of
the
api
is
willing
to
have
that
risk.
A
Stefan,
do
you
have
any
any
opinion
about
that?
F
As
well,
no
not
not
right
now,
no
I'd,
I'm
still
discovering
this
I'd
have
to
think
about
it,
a
bit
more
but
yeah.
It
does
feel
like
I
I
I
tend
to
be
a
bit
wary
of
wide
open
apis
that
just
allow
anything.
F
A
B
Think
that
ring
the
string
here.
What's
the
difference
between
the
stream
we
and
then
the
raw
students,
the
the
extension.
B
A
A
I'm
I'm
okay
with
the
bite
slice.
Can
you
can
you
mention
that
in
the
in
the
in
the
comment
to
kyujen
and
then
see
what
his
feedback
is?
A
B
A
A
So
on
this
proposal,
where
it's
currently
defining
the
rules,
I
guess
we
we're
gonna
change
it
to
a
reference
to
something
else
and
then
and
then
okay,
and
do
you
want
this
proposal
to
also
include
that
new
api?
Or
do
you
want
to
make
another
another
proposal,
or
how
do
you
want
to
approach
that
both
okay
to
me?
A
B
B
A
Sure
I
just
want
to
make
sure
that
we
also
take
care
of
the
qps
as
well,
because
it
seems
like
that
is
something
that
paul
mentioned
that
have
a
really
good
point
about,
as
well
as
the
the
lifetime
of
the
status
return.
I
guess
that's
not
not
a
qps,
because
that's
that
is
so
paul
mentioned
an
interesting
point
where
we're
only
probably
interested
in
the
status
after
a
spec
change
after
a
certain
time
period,
we
might
not
need
to
continuously
watch
it.
A
So
maybe
we
have
to
take
care
of
that
too,
whether
it's
in
the
qps
or
maybe
like
another
field
or
like
a
life
like
how
long
it
lives
for
that
type
of
that
type
of
field.
B
Okay,
mike,
I
think
that
the
meeting
is
no
no,
no
time
left.
I
think
again.
B
Okay,
I
name
questions
from.