►
From YouTube: Kubernetes SIG Multicluster July 11 2023
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
A
I
think
that
you
have.
You
should
have
screen
sharing,
enabled
if
I'm
not
mistaken,
but
let
me
know
if
you
don't.
A
I,
don't
even
see
where
the
security
settings
have
moved
to
actually.
D
E
A
Okay,
I
may
need
to
rejoin.
B
Got
it
okay,
I?
Don't
we
don't
actually
have
a
deck
preparer
where
we
have
the
proposal?
Dock,
that's
linked
to
the
calendar
and
we
share
it
in
the
kubernetes
slack,
there
were
a
bunch
of
discussions
that
took
place
in
the
Google
Doc
and
we
felt
like
it's
better.
We
would
just
go
off
on
the
Google
Doc
and
then
talk
about
those
discussion
points
so
before
I
get
started.
B
B
Okay,
let
me
let
me
get
started
so
we're
proposing
to
introduce
the
cluster
inventory
API
and
in
a
high
level
overview
is
in
the
community
right
now
in
the
in
the
wild
public.
There
are
a
bunch
of
multi-cluster
projects.
You
know
we
have
ocm
commodity
cluster
net
Fleet
managers
and
we
all
the
fun.
B
We
all
have
a
concept
of
this
cluster
inventory
cluster
cluster
registry,
but
there's
not
a
standardized
API
so
which
makes
it
hard
for
the
Downstream
project,
consumers
to
consume
and
we're
hoping
that
we
can
come
together
in
a
community
effort
to
Define
such
centralized
cluster
inventory
API
and
then
with
that
established
with
the
with
the
fields
well
understood
where
you
can
make
it
easier
for
consumers
to
to
adopt
this
API
and
use
it.
B
So
again,
you
know
we
have
a
bunch
of
projects
that
each
have
their
own
sort
of
cluster
inventory
API
yet,
but
if
we
are
trying
to
achieve
the
achieve
the
similar
goals,
you
know
we
want
to
show
the
the
status
of
the
Clusters.
You
know
show
some
data
show
some
data
about
the
the
Clusters
and
then
when
we,
when
each
of
us,
go
to
projects
and
go
like
hey,
which
would
be
interesting
in
adopting
this
API.
But
what
the
common
feedback
seems
to
be.
Oh,
but
this
is
not
a
central
API.
B
If
we
adopt
one
particular
project,
we
have
to
add
some
abstract
layer
and
maybe
have
to
adopt
another
project,
and
it's
just
not
a
feasible
for
the
third
party
consumers.
B
So
with
that
in
mind,
we
would
like
to
introduce
the
cluster
inventory
API,
which
really
gives
a
foundation
API
for
this
multi-cluster
management,
and
it
can
be
used
for
you
know,
for
the
for
multi-cluster
workload,
scheduling.
Obviously
you
you
know
which,
which
cluster
have
the
resources
to
to
perform
workload,
and
you
can
delegate
the
workload
towards
that
cluster
and
then
for
for
git,
Ops
tools.
Again,
you
know
similar.
B
It
allows
them
to
have
a
list
of
cluster
inventory
and
then
they
know
which
cluster
they
can
connect
to
and
deploy
the
github's
yamo
Memphis
on
onto
that
cluster
and
then
there's
some
other
use
case,
such
as
like
operation
tools
and
then
Expo
explosives
apis
to
different
Cloud
vendors,
and
then
it
it
provides
a
vendor
agnostic
integration
for
for
external
tools
and
I
think
Mike.
Added
this
part.
B
The
cluster
manager,
implementation
for
grouping
clusters
for
MCS
API
cluster
sets
feel
free
to
jump
in
at
any
time.
If
you
have
questions
or
comments,
I'm,
like
I'm
I'm,
do
you
want
to
touch
up
on
this
right
now
or
I
can
come
back
later.
B
Got
it
and
the
one
of
the
main
goal
of
this
presentation
is
we
want
to
get
more.
We
want
to
get
this
cluster
inventory
API
proposal
out
there.
We
want
more
collect
more
use
cases
from
the
customers,
I
mean
from
from
the
consumers,
the
more
consumers
that
show
interest
in
this
cluster
Game
Room
toy
API
the
better,
because
it
will
help
easier
for
us
to
shape
the
API,
and
then
we
can
figure
out
more
details
and
come
to
agreement
on
some
of
the
centralization.
B
So
so
one
of
the
the
immediate
question
is
we:
with:
in
the
community
there
was
a
cluster
registry
API
project
and-
and
that
has
been
archived
and
the
immediate
question
was
okay-
why?
Why
did
that
archive?
And
then
why
are
we
proposing
this
new
cluster
inventory
API
now?
So
one
of
the
reason
it
was
archived
it.
It
didn't
really
have
enough
adopters
and
consumers
and
So
to
avoid
that
mistakes.
You
know
we.
B
We
bought
a
bunch
of
adopt
adopted
projects
that
will
contribute
to
the
cluster
inventory
API
and
shows
the
commitment
to
this
project
and
willing
to
continue
to
build
towards
it
and
and
actually
use
it
instead
of
leaving
it
in
sort
of
like
archival
States.
C
B
C
The
reasons
it
was
archived
sorry
I
hope
you
can
hear
me
I'm
stuck
on
the
train.
One
of
the
other
reasons.
There's
archived
is
because
I
don't
think
it
was
a
clear,
consistent
set
of
things
Beyond,
just
a
list
of
different
things
that
we
wanted
to
get
a
cluster
registry
between
projects
and
I.
Think
that's
why
there
wasn't
adopters.
C
Is
it
I
mean
here?
It's
awesome,
a
bunch
of
different
products
together,
I
think
that's,
that's
a
group
starting
point
versus
the
last
one,
but
how?
How
is
that
really
different
now
do
we
know
that,
like
there's
a
lot
of
lists
in
this
I'm
like
we
want
to
share
status,
we
want
to
show
Health
but
I.
Think
for
me,
what
stood
out
is
the
the
points
that
really
need.
C
Clarification
are
like
what
does
Health
mean
in
a
consistent
way
such
that
it
can
be
consumed
by
all
of
these
projects
and
they're
all
happy
with
it.
What
is
useful
status
is
that
is
I,
think
a
deceptively
tricky
question.
B
Got
it
so
so
we're
hoping
we're
hoping
that
they're
there's
four
party
projects
that
will
come
out
and
then
saying
this
is
what
we
what
we
we
want
out
of
this
clustering
API
cluster
inventory
API,
for
example,
where
you
said
how
to
define
the
health
status
and
then
we
can
come
to
a
quorum
and
then
we
can.
Actually,
you
know
when
we
propose
API.
We
come
to
a
conclusion
and
then
come
to
substantialization.
B
So
that's
why
I
think
it's
important
that
we
already
have
you
know
a
couple
projects
are
willing
to
work
together
and
then
we
come
to
sort
of
agreements.
So
at
the
very
least
we
satisfy
some
some
of
the
consumers
requirements
already
and
and
I
think
that
that's
a
really
fair
point
and
I
think
that's
something
that
we
we
need
to
keep
working
on
on
this,
let's
say:
inventory:
API
we're
just
actually
getting
the
the
consumer
specifics
of
what
they're
looking
for.
B
So
we
can
really
help
shape
the
the
API
and
to
have
the
right
specifications.
C
C
B
F
I
think
I
saw
one
iteration
of
this
document
that
actually
did
propose
like.
Why
would
people
try
to
use
it?
Why
would
it
be
beneficial
and
one
of
the
use
cases
where
it
would
be
beneficial
is
trying
to
build
a
a
project
that
wants
to
install
across
multiple
clusters
or
put
its
add-on
across
multiple
types
of
multi-cluster
solutions
and
doesn't
want
to
have
to
write
one
for
carmana
one
for
cluster
net,
one
for
each
of
the
varying
ones?
F
C
So
I
think
that's
really
good,
like
that.
I
think.
Clearly
that
is
part
of
what
we
want
unless
you're
ready,
there's
a
list
of
ways
to
access
clusters,
but
then
I
think
when
we
go
to
the
next
level,
there's
still
a
lot
of
open
questions.
I'm
not
saying
like
that's
like
that
is
I
think
a
good
direction
to
explore,
but
some
of
the
questions
that
come
up
are
like
okay.
So
if
I
wanted
to
schedule
across
multiple
clusters,
what
do
I
need?
I
need
to
know
that
my
cluster
has
opacity.
C
What
does
capacity
mean
right
like
it's?
Not
a
number
I
think
it
is
often
thought
of
as
a
number,
but
it's
not
just
one
number
like
there's
my
potentially
there's
my
arm
capacity
and
my
x86
capacity.
C
There
might
be
my
GPU
capacity.
It
might
be
my
GPU
of
a
certain
kind
of
capacity.
Those
are
the
kind
of
questions
that
that
come
to
mind
where
I
think,
like
picking
a
use
case
like
that.
That
example
is
a
really
good
way
to
kind
of
enumerate.
The
like
next
level
questions.
A
So
one
of
the
things
that
that
I
felt
that,
like
cluster
registry
is
a
project
like
the
previous
project
named
a
cluster
registry
within
the
Sig
really
had
a
Miss
on
is.
A
There
was
really
no
good
answer
to
the
question.
I
installed
this
registry
crd
and
the
the
cluster
registry
I,
don't
think-
and
I
may
may
not
be
remembering
this
exactly
right,
but
I
don't
think
there
was
any
code
that
we
ever
wrote
around
it.
It
was
basically
just
a
custom
resource
definition,
and
so
it's
like
all
right,
well
I,
installed
this
cluster
registry
crd.
Now
what
and
there's
like
no
consensus
even
on
what
that
next
step
should
be
so
I
I.
A
Think
that
your
your
document
that
you're
sharing
has
a
lot
of
great
ideas
in
it.
What
I
think
would
be
profitable
for
you
all
to
think
about
is
when
someone
asks
you
I
installed,
the
cluster
inventory
API.
What
do
I
get
out
of
it
like?
What's
the
first
answer
that
you
give
them
that
demonstrates
tangibly
that
there's
something
there
worth
using
and
that
it
has
a
specific
and
clear
purpose.
B
So
currently
the
cluster
inventory
API,
it's
you
know.
As
David
alluded,
it
was
meant
to
be
a
foundation
API
that
we
can
continue
to
expand
on
we're
really
hoping
that
you
know
we
once
we
have
this
cluster
API,
we
can
continue
to
build
on
it
on
top
with
something
like
placement,
and
maybe
the
work
API
to
Leverage.
So
I
will
say
right
now.
B
If
we
have
the
cluster
inventory
API,
because
the
work
API
project
already
is
in
the
in
the
sick,
I
will
say
now
you
can
leverage
the
work
API
to
pick
the
cluster
that
you
want.
I
mean
you.
You
have
to
specify
cluster
cluster
inventory
cluster
inventory
that
you
want,
and
then
it
will
deploy
the
workload
there
and
then
it's
a
little
bit
of
future
growth
with
way
in
the
middle.
We
would
really
like
to
introduce
the
the
aspect
of
placement
so
without
without
the
cluster
inventory.
B
I
think
it's
hard
to
to
do
the
placement
and
the
placement
is
about
picking
which,
which
cluster
inventory
to
to
do
something,
whether
it's
to
view
or
deliver
some
workload
or
do
some
other
actions
on
and
I
think.
That
is
what
we're
trying
to
do:
we're
trying
to
build
a
a
foundation
layer,
so
we
can
continue
to
build
on
top
of
it
David
do
you
want
to
expand
on
those.
F
Yeah
I
was
gonna,
go
like
specific
in
concrete
right.
So,
looking
at
this
and
saying
what
is
why
would
something
outside
of
the
karmada
project
care
about
this,
or
why
was
something
outside
the
open
cluster
management
project
care
about?
This
is
a
very
fair
question
and
I
think
being
able
to
show
sort
of
the
I'll
say
four
core
apis.
F
You
can
build
out
of
the
combination
of
those
things,
a
way
to
distribute
work
across
multiple
clusters
and
say
I
want
this
here
and
that
there,
with
decisions
around
the
around
things
like
label,
selection
or
cluster
properties
and
anti
or
like
anti-matching
with
something
like
taints,
and
so
the
question
becomes
how
big
a
slug
would
the
Sig
like
to
see
at
the
same
time
right?
Is
it
a
case
where
build
all
the
pieces
out
and
show
this
is
how
given
just
the
cluster
inventory
that
a
project
says
here's
my
cluster
inventory.
F
D
A
David
I
I
take
your
points.
What
I
was
really
coming
at
was
not
that
I
think
that
we
need
to
see
like
those
four
essential
building
blocks.
A
What
I'm,
what's
in
my
head,
is
that
you
know,
without
without
an
essential
use
case
that
like
demonstrates
the
value
without
those
additional
building
blocks
this
this
starts
to
feel
very
much
like
cluster
registry
2.0,
where
we've
got
a
crd
and
we've
it's.
It's
really
not
clear
what
an
essential
thing
that
you
can
do
if
you've
just
got
that
crd
and
almost
nothing
else
to
R
like
scheduling
and
placing
workloads.
A
That's
a
that's
a
very
high
value
and
high
impact
use
case
to
have,
but
like
it's
it's,
it
also
brings
in
a
lot
of
other
pieces
right.
So
what
I
think
what
I
think
I'm
kind
of
poking
at
here
is
I.
Think
the
cluster
inventory
API
as
a
concept
gets
stronger.
If
there's
a
controller
that
you
can
run
that
at
least
heart
beats
into
it,
so
that
you
can
get
like
a
a
view
of
your
Fleet
at
some
very
low
level
of
granularity
without
doing
a
whole
lot
else.
I.
A
I
think
other
opportunities
would
be
if
we
can,
if,
if
we
have
projects
that
are
lined
up
so
that
we
can
say,
you
know
at
at
some
point
that
if
you
install
this
and
you're
running
carmata
and
you
let
karmada
know
where
the
API
is
all
your
stuff
from
carmadas
just
going
to
start
showing
up
there
and
all
your
stuff
from
open
cluster
management
is
just
going
to
start
showing
up
there.
A
Then
it
gets
a
little
bit
more
clear
that
that
there's
a
useful
direction
that
it
can
head
in,
but
I
think
what
we
want
to
avoid
is
a
an
experience.
It's
like
there's
a
crd
there
there's
nothing
that
integrates
with
it.
F
Yeah
I
guess
I,
guess
that's
why
I
was
bringing
up
like
that
road
map
that
that
road
map
of
you,
you
have
the
inventory
and
you
move
from
the
inventory
to
the
idea
of
placement
decisions,
and
then
you
mix
in
the
idea
of
work
to
be
able
to
distribute
work
into
those
clusters.
That
is
the
concrete
next
step
and
the
question
that
I
have
is
just
how
much
of
that
needs
to
be
built
out
before
taking
the
first
step,
because.
C
F
C
Open
period
is
actually
a
different
language.
Is
this
about
actually
building
a
like
a
generic
cluster
inventory
that
can
be
used
for
all
sorts
of
multi-cluster
things,
basically
yeah?
What's
your
industry
2.0,
or
is
this
actually
just
a
instead
a
common
API
for
work
replacement
that
all
of
these
are
open
source
projects
again
soon
like
are
we
standardizing
the
work
API
Armada
apis
and
the
cluster
registry
is
just
a
bypass
of
that
or
a
byproduct
of
that.
F
I
think
being
able
to
demonstrate
that
next
level
of
value
of
like
what,
as
as
someone
who
wants
to
work
across
multiple
clusters,
why
would
I
bother
using
this
thing?
Is
the
question
that
I
would
want
to
answer
because
otherwise
like
how
am
I
going
to
convince
Argo
CD
to
use
it,
for
instance,
and.
F
In
saying
you
know
what,
if
you
interact
with
this
higher
level
API,
then
the
these
four
projects
will
just
distribute
your
workload
for
you
and
it
will
report
status.
F
The
way
that
you
expect
I
think
that
would
be
a
compelling
reason
to
come
and
use
this
project
and
make
it
notably
different
than
a
previous
attempt,
and
if
it's
just
a
matter
of
like
making
concrete
like
here's,
the
here's,
the
next
step,
it's
not
like
a
theoretical,
we're
building
it
and
hoping
we
have
something:
it's
we're
building
it,
and
then
this
is
the
next
step
to
take
that
will
interact
and
I
will
bring
these
two
other
pieces
together.
F
That's
certainly
doable
and
I
can
see,
saying
like
that's
the
threshold
like
you
have
to
have
a
working
thing
where
someone
could
say:
yeah
I
get
a
unit
of
value
out
of
this,
because
yeah
I
do
agree.
Otherwise
you
end
up
in
a
situation
where
well
great,
you
built
a
cool
thing,
but
why
would
I
bother
spending
my
time
to
integrate
with
it.
C
Or
or
equally
concerning
is
the
we
we
end
up
with
a
crd
that
appears
really
useful,
but
ends
up
being
like
still
a
like
product
specific
set
of
key
value
pairs
with
no
real
consistency.
That's
kind
of
my
big
concern,
like
the
concept
to
me,
makes
a
lot
of
sense.
It
seems
like
something
that,
like
intuitively,
the
community
should
have.
F
That
we
will
get
more
standardization
once
we
demonstrate
a
unit
of
value
where
someone
would
actually
have
something
that
spans
across
right.
If
you
don't
have
any
mechanism
to
span
across
it's
just
as
easy
for
you
as
someone
trying
to
to
code
the
different
multi-cluster
solutions
to
say
well
I'm
going
to
go
to
this
one,
it
works
this
way
and
I'm
going
to
code
to
that
one
and
it
works
this
other
way.
F
But
but
once
you've
had
that
unified
thing,
you
can
see.
Oh
here's,
the
value
that
I
get
as
someone
who
wants
to
work
on
top
of
this
and
now
I
need
these
contributors
like
come
on
guys,
come
up
with
some
sort
of
standard
on
on
how
you're
going
to
name
what
you
have
available
here.
C
F
I'll,
let
somebody
else
answer
that
I
have
I'll
let
someone
session
first
and
then
I
do
have
an
opinion.
Yeah.
D
I
think
we
thought
about
that,
and
that's
kind
of
the
purpose
of
this
inventory
is
we
try
to
get
to
a
point
that
everybody
can
agree
with
one
standard
every
project
has
its
own
Viewpoint.
So
that's
that's
kind
of
the
main
purpose
of
having
this
class
inventory,
so
we
can
have
one
standard
one.
The
the
short
answer
is
clearly
it's
not
easy
to
for
everyone
to
agree
to
conforming
to
one
project.
D
That's
why
we
have
this
this
proposal
so
that
we
can
actually
converge,
and
that
is
this
standard
that
we
had.
We
discussed
for
almost
three
months
on
the
nitty-gritty
details
on
every
Fields.
What
is
needed?
What
is
useful,
so
this
is
kind
of
the
product
of
trying
to.
A
So
maybe
maybe
we
can,
we
can
examine
the
same
question
a
slightly
different
way
so
like
say
that
say
that
this
cluster
inventory
API
proposal
is
accepted
into
the
Sig.
What
specific
things
are
which
open
source
projects
going
to
build
that
use
it?
That
can
become
part
of
that
future.
Read
me:
that's
like
all
right,
I
installed
the
crd.
What
do
I
get
now
like
what
what
questions?
What
answers
to
that
question
are
going
to
be
built
if
this
were
accepted.
D
Yeah
the
fleet
Fleet
manager,
I,
can
represent
fleet
manager,
fleet
manager
project
definitely
is
going
to
implement
or
use
this
cluster
inventory
that
that
part
I
can
yeah.
D
B
I
also
mentioned
in
the
beginning:
we
have
commitments
from
the
the
four
formation
projects
that
will
use
it,
and
we
also
reach
out
to
the
Argo
communities
and
they
are
also
interested
in
and
I
think.
Besides
these
projects,
I
mean
I,
think
Steven
can
talk
about
it
as
well,
even
in
summer
winners
and
other
other
projects
too,
they
all
have
a
concept
of
cluster,
but
everyone
is
doing
it
a
little
bit
differently
with
maybe
inaugle
CD,
it's
towards
a
secret
and
I
think
a
lot
of
based
on
the
feedback.
B
A
lot
of
a
lot
of
projects
are
looking
for
something
like
this
in
the
sick,
but
there
there
is
no
centralization,
so
they
each
of
them
will
come
up
with
their
own
way
and
and
going
back
to
oh
sorry,
for
going
back
to
your
being
usefulness,
do
you
think
this
project
will
actually
help
with
if
we
have
a
reference
implementation
controller
for
the
cluster
inventory,
because
I
think
I
think
Ryan
was
saying
he
was
interesting
not
to
like,
if
there's
a,
if
there's
a
like
at
least
provide
some
heartbeat
or
or
some
some
simple
status,
yeah.
A
A
How
do
you
demonstrate
the
usefulness
of
this
like
very
low
level
building
block
without
having
to
have
the
entire
house
built
already
around
it
within
the
Sig?
Okay?
So
there's
a
couple
different
ways
that
we
could
do
that
one
is.
We
can
build
something
that
people
themselves
deploy
specifically
to
make
this
inventory
API
useful.
A
Another
would
be
if,
if
this
proposal
was
written
as
these
four
projects
want
to
all
do
these
three
things
and
they
think
the
priorities
are
number
one
is
X
number
two
is
why
number
three
is
z
and
we
want
to
build
this
API
together,
so
that
we
can
then
immediately
build
these
use
cases
on
top
of
it.
I
think
that's
very
different
right
than
than
saying
it.
You
can
then
do
blah
versus
saying
we
want
this,
so
that
we
can
do
blah
right
is,
is
pretty
different
in
the
second
formulation
it.
A
It
would
allow
you
all
to
make
a
claim
that,
in
that
you
know
essential
document
of
the
readme
in
the
the
root
directory
of
the
repo.
That
you'll
create,
is
what
happens
next
right?
What
happens
next?
Is
you
know
if
you're
a
user
of
one
of
these
four
projects,
then
you
get
some
use
case
that
automatically
gets
representation
in
this
API
as
soon
as
you
install
it
and
let
them
know
where
it
is
so.
Does
that
make
sense
like
Jeremy,
you
and
I
have
talked
about
this
a
lot?
A
C
Yeah
I
I
see
that,
as
the
compelling
thing
no
I
also
see
that
actually
is
what
kind
of
plan
except
we've
got
four
projects
coming
in
here
that
are
saying
we
want
to
build
this
API
and
we're
all
going
to
use
it
to
me
that
is,
and
we're
going
to
use
it,
because
we
want
to
have
that
portability
and
consistency.
That's
super
compelling
makes
a
lot
of
sense
and
I
think
Paul
lines
up
exactly
with
what
you
and
I
have
talked
about
in
the
past.
In
this
area,
like
yeah,
we
get
that
standardization.
C
We
prove
legitimacy
by
the
fact
that
these
products
all
use
it
and
I
think
naturally,
these
four,
especially
because
it's
these
four
that
people
know
about
are
using
are
using
the
standardization.
C
The
fifth
one
is
going
beautiful
right,
like
that's
super
bealling.
For
me,
a
lot
of
the
concerns
and
I've
covered
these
in
the
docket
more
around,
like
specifics,
like
I,
think
we
say
things
like
tracking
the
cluster
status.
That
is
not
clear
to
me
that
we
actually
really
have
a
detail
on
what
that
status
should
be
or
what
health
means
or
what
capacity
means,
because
like
right
now,
we
show
in
the
like
in
the
ammo
but
like
there's
10
CPU
available,
but
that
doesn't
like
you
know,
speaking
from
the
gke
side.
C
10
CPU
is
not
a
useful
stat
like
it
could
be
on
basic
workloads
because
I
don't
know
what
those
CPU
are
and
they're,
not
interchangeable.
Right
like
there's
10,
good
CPU
and
10
incompatible,
CPU,
there's
10
I
perform
the
CPU
and
there's
Japan
and
local
on
a
CPU
and
his
workloads.
They
don't
want
to
neither
one
of
them
I.
C
Don't
we
need
to
Define
that
in
a
lot
more
detail,
I
think
health
is
kind
of
similar,
like
not
every
aspect
of
the
cluster
needs
to
be
running
at
100
for
another
workload,
the
function
just
fine
right.
C
A
Jeremy,
your
audio
is
breaking
up
very
badly.
D
A
C
C
D
D
A
You
so
I
I
think
you
all
have
a
good
opportunity
right.
Like
you've
got
you,
you
have
the
advantage
over
the
you
know
the
previous
cluster
registry
project,
in
that
there
are
already
people
solving
these.
These
problems
in
different
projects,
you're
already
talking
with
one
another
right,
if
you
could,
if
you
could
agree
on
a
feature
that
you
all
wanted
to
build
into
your
project
into
each
of
your
projects,
that
is
going
to
work
correctly.
As
soon
as
you
install
cluster
inventory,
API
I'm,
like
Point
those
different.
F
I
have
a
concrete
suggestion
for
what
those
are
just
throwing
out.
You
know
if
I
looked
at
it
and
said
what
would
bring
other
people
in
I
think
being
able
to
look
and
say
these
are
the
selection
criteria.
I
have
positive
and
negative
selection
criteria
Focus
around
perhaps
cluster
properties,
I
know
that
was
one
that
came
up
previously
or
or
the
notion
of
taints
that
will
be
filled
in
by
a
project
by
whatever
logic
that
project
has
for
saying.
I
have
a
thing
would
make
it
possible
to
build
a
later
step.
D
F
I
think
that
would
be
very
high
value
and
if
the
four
groups
can
agree
on
that,
it
would
imply
the
next
step
and
give
a
lot
of
confidence
for
people
who'd
be
looking
at
building
on
top
right
because
it
was
so
like
this
is
what
comes
next
and
we've
made
it
possible.
Here's
the
criteria
that
you
can
see:
here's
the
health
of
the
cluster
because
you're
going
to
want
to
select
on
that
and
the
and
the
selection
criteria.
B
A
A
You
know
the
cluster
inventory
proposal
without
winding
up
in
a
situation
where
it's
just
cluster
registry-
repeat
right,
so
like
I'm
I
am
not
suggesting
that
you
make
changes
to
software
before
you
have
the
name
figured
out
or
the
repo
created,
but
having
a
compelling
plan
that
results
in
hey,
we
get
these
actual
concrete
use
cases
that
people
are
going
to
build
as
soon
as
they've
got
the
the
crd
defined
to
build
against
it
gets
it
gets
a
lot
easier.
D
To
two
things:
actually,
on
the
fleet
manager
side,
we
could
even
start
with
a
reference
implementation.
The
only
problems
we
don't
notice
are
the
exact
definition.
If
there's
there,
we
could
even
start
with
the
use
in
the
in
the
in
the
sick
repo.
We
can
actually
even
you
know,
reference
implementation
there
and
we
are
going
to
use
that
in
our
real
repo.
If
that
will
make
it
more
compelling,
and
the
other
thing
is
I
think
Thomas
has
a
question.
He
has
his
hand
raise
up
for
a
while.
G
Yes,
thank
you.
I
just
want
to
speak
to
potential
use
cases
and
I
wanted
to
plus
one
what
David
had
said,
which
is
essentially
the
use
case
we're
interested
in,
which
is
the
basically
scheduling
between
multiple
clusters
and
taking
into
consideration
everything
from
dates
and
tolerations
affinities
and
anti-afinities.
G
In
my
ideal
world.
This
would
support
basically
being
able
to
mirror
the
entire
kubernetes
scheduler
design.
That's
used
to
schedule
between
nodes
for
picking
which
clusters
are
available
right
and
so
I
just
want
to
plus
one
that
as
being
a
use
case,
that
Ico
is
a
lot
of
value
and
it's
actually
the
use
case
that
even
drew
me
to
this
Stig
in
the
first
place.
So
that's
all.
D
Every
every
project
that
is
behind
this
has
whatever
what
Thomas
was
saying.
We
all
are
building
this
type
of
capacities
capability
with
various
degrees,
but
the
common
denominator
is
that
cluster
inventory
the
the
unit.
Like
kind
of
the
note
right
in
the
kubernetes,
we
don't
have
a
representation
of
node
common
nodes.
So
this
is
the
exact
reason
we
want
to
have
a
standard
representation
of
a
cluster.
D
So
all
our
schedules
can
be
based
on
that.
That.
C
Makes
sense
to
me
I'm
sorry,
if
I
drop
off
again
I'll
try
to
be
right.
There
I
think,
as
a
primary
goal
makes
a
lot
of
sense.
I
think
the
original
description
was
was
more
generic.
C
We're
building
a
platform
for
scheduling
is
a
very
specific
and
I'm.
Sorry,
if
it's
changed
it
now
for
another
day,
we're
building
impactful
for
scheduling
this
very
specific
goal.
It
makes
a
lot
of
sense.
B
God
of
Paul
thank
you
and
and
Jeremy
for
that
feedback
and
wine
as
well
so
I
think
I.
Think
going
back
to
Wine
I
mean.
B
I
think
you'll
be
it'll,
be
great.
If
we
have
again
all
the
projects
come
together
and
then
clearly,
Define
in
in
our
own,
in
our
own
repos
or
website
or
somewhere,
that
we
we're
trying
to
build
a
we're
trying
to
have
a
common,
a
common
API
where
we
can
use
to,
as
as
what
Jeremy
said,
we're
trying
to
build
a
platform
for
for
scheduling
and
not
maybe
not
necessarily,
we
need
the
code
yet,
but
at
least
it
needs
to
each
of
our
individual
projects
should
mention
this
point
like
we
should
have
a.
B
We
should
have
a
issue
or
enhancement
where
you
know
we're
gonna,
adopt
this
we're
planning
to
adopt
this
common
API,
and
then
that
is
what
gonna
enable
the
users
to
be
able
to
maybe
even
switch
Switchback
back
and
switch
from
one
platform
to
another
in
in
maybe
some
migration
scenarios
so
that
if
they
have
the
cluster
inventory,
they
can
use
ocm
or
fleet
manager
or
kamada
or
whatever
it's
all.
It's
all
going
to
work
seamlessly.
B
Does
that
make
sense?
Well,
you
know.
D
Yeah,
it's
the
building
blocks
where
we
we
have
this
Pro
kind
of
conundrum
or
chicken
egg
problems.
We
cannot
get
the
entire
entire
stack.
The
placement
decision
scheduling
everything
together.
If
we,
then
we
have
to
do
the
step
baby
steps,
so
the
baby
steps
start
from
the
standardized
cluster.
Hopefully
we
can
show
the
community
that
this
is
the
roadmap
and
that's
the
the
value
of
providing
this
small
piece
that
doesn't
by
itself
may
not
have
tons
of
value,
but
we
have
this
Roman.
Without
this
we
we
cannot
get
stuck.
B
Okay
so
So,
based
on
the
feedback
from
the
from
Germany
and
Paul
and
David,
and
anyone
else
so
I
think
our
next
step
is
for
our
projects
to
to
sort
of
create
that
world
map
and
then
we'll
come
back
in
the
proposal
here
and
list
the
clear,
clear
goal
as
what
Jeremy
suggested
and
then
also
answer
some
of
the
questions
and
bring
in
the
some
of
the
questions
regarding
on
the
specific
of
the
fields
such
as
the
capacity
that
example
that
Jeremy
mentioned,
and
then
after
We
examined
the
proposal
again.
B
Are
there
any?
Are
there
any
other
which
we
just
would
like
to
ask?
Are
there
any
other
suggestions
or
feedback?
We
can
really
push
this
cluster
inventory
API
repo
to
be
sort
of
created
in
the
sick,
so
we
can
start
implemented.
We
just
want
to
know
what
are
some
of
the
besides
the
the
mentioned
points.
What
other
things
that
can
really
help
push
this
forward.
D
B
Honkai,
do
you
have
any
any
comments
or
any
feedback,
because
I
think
I
think
we?
Basically
when
fulfur
our
discussion,
we
went
through
all
the
most
of
the
proposal
and
there's
still
some
work.
That
needs
to
be
done
and
we'll
we'll
we'll
keep
appending
to
it,
but
Hong,
Kai
or
anyone
else
or
any
other
feedback.
E
D
B
I
would
I
would
just
like
to
mention
that
I
I
think
the
community
also
has
been
asking
for
some
type
of
multi-cluster
scheduling
capability
and
they
and
they're
looking
at
the
sick
and
then
I
know
we
we
archived
the
Q
fed
wifely
so
but
I
think
there's
I
think
there's
a
lot
of
Demands
for
this
scheduling
capability
for
multi-clusters.
So
we
we
really
like
to
meet
the
community
demand
and
try
to
build
towards
and
enhance.
B
This
is
another
reason
or
why
we're
starting
with
this
sort
of
a
foundation
block
for
cluster
inventory
as
well.
C
This
is
intriguing,
it's
just
a
very,
very
hard
problem
right,
and
so,
if
we
can
solve
it,
amazing
and
I
think
a
lot
of
the
points
Paul
is
made
just
if
we
could
really
kind
of
de-scope
and
focus
on
what
is
the
immediate
value
of
the
specifics.
It's
going
to
be
a
lot
easier
to
see
in
the
future.
B
B
I,
don't
really
have
oh
there's
someone
with
the
hands
up.
Oh
no,
okay,
I,
don't
have
anything
else.
Anyone
else
have
anything.
They
want
to
share.
Mention
feedback.
E
B
Yep,
that
sounds
great
I
for
sure
will
will
each
project
will
go,
create
some
type
of
mobile
map,
that's
related
to
this
this
proposal
and
then
we'll
we'll
come
back
with
a
enhanced
bubble,
so
yeah.
A
All
right,
well,
I,
think
that
was
it
for
the
agenda
today,
thanks
for
presenting
and
we'll
look
forward
to
seeing
more
iterations
on
this
work
in
the
future.