►
From YouTube: 20190415 - Cluster API - Data Model breakout
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
So
the
goal
of
this
meeting
is
to
talk
about
post
API
data
types,
so
high
level.
What
they're
gone
the
boundaries
are
the
requirements
and
link
in
their
use
cases
for
folks
that
are
not
familiar
with
the
current
structure
forecast.
Api
Koscheck
is
split
into
two
different
high-level
types,
so
we
have
machine
and
cluster
and
we
have
two
controllers
for
the
machines
machine
sets
and
machine
deployments,
and
we
also
offer
machine
classes.
A
A
A
A
What
I
thought
that
came
out
of
the
other?
The
other
proposal
was
a
cluster
as
being
an
umbrella.
So,
right
now
the
cluster
object
of
type
is
considered
optional
in
some
providers
and
some
providers.
Instead
use
labels
to
identify
the
cluster
of
like
machines
and
what
the
cluster
controller
should
do,
we're
thinking
about
having
the
cluster
object,
it's
kind
of
like
an
umbrella,
so
that,
like
it
would
kind
of
like
span
and
like
a
b.length,
do
all
the
other
getter
types.
A
But
more
specifically,
the
cluster
should
also
offer
some,
like,
from
my
us
point
of
view,
offer
a
high
level
type
where
you
could
create
like
your
cluster,
where
you
can
scrub
your
cluster
and
you
can
have
one
type
kind
of
to
own
many.
If
that
makes
sense,
and
we
can
achieve
that
with
like
remote
references
or
owner
references
on
the
types
and
but
that's
more
implementation,
but
just
to
give
a
nice
question.
B
A
B
A
The
control
planning
is
kind
of
easier,
so
like
right,
right
now,
there's
a
little
repetition
for
setting
up
a
control
plane,
for
example,
yes
provider.
We
have
a
label
that
defines
this
machine
is
a
node
or
a
control
plane,
and
we
we
cannot
offer
at
this
point
like
high
level
mechanism,
for
example,
for
control,
plane,
upgrades
or
like
generic
control.
A
Plane
management,
and
this
is
also
expressed
very
well
in
the
requirements
which
it's
like
they
define
some
boundaries
in,
like
what
cost
API
should
be
able
to
do
and
so
having
having
a
control
plane
as
like
high-level
object.
It
will
not
only
allow
close
JPI
to
offer
kind
of
more
out-of-the-box
features
for
control,
plane
management,
but
in
the
future,
for
example,
when
like
we
will
have
to
support
like
that's
the
ADM,
we
can
further
like
kind
of
take
a
step
like
in
in
that
direction
to
kind
of
like
use.
A
Also,
these
other
tools-
and
the
other
thing
that
was
mentioned
was
external
control
plane.
So
if
you
have
a
control
point
that,
like
it's
not
managed
by
cluster
API,
but
you
want
to
use
close
to
API
to
manage,
know
the
cross
providers
and
you
just
want
to
join
those
nodes-
the
control
plane,
the
control
plane
type-
can
offer,
for
example,
like
a
cube
config.
A
C
B
One
thing
that
would
help
me
with
this
proposal
would
be
defining
like
what
use
cases,
I,
guess,
I'm
kind
of
unfamiliar
with
the
use
case
document
like
what
use
cases.
This
would
solve
like
what
what
the
existing
implementation
like
sort
of
fails
to
achieve
in
in
in
like
the
direction
we
want
to
head
so.
A
B
A
In
but
we
shouldn't
use
the
propose
that
we
brought
it's
like
a
starting
point
for
this
discussion,
I'm
curious
to
hear,
if,
like
others,
have
any
other
opinions,
especially
around
the
cluster
being
like
an
umbrella
and
also
offering
like
a
top
like
kind
of
like
we
got
a
top-down
approach,
but
imagine
the
user
experience
being
a
being
something
like
hey
I
want
to
cluster.
This
is
my
cluster.
This
is
my
unique
llamo,
for
example,
and
I
can
describe
everything
in
here.
C
Vinson
I
have
the
it's
not
really
accepted
to
do.
What
you
say
is
more
opportunity
with
the
previous
column
regarding
the
use
cases,
because
the
requirements
was
translated
into
a
document
in
the
repository
proposal,
but
the
use
cases
so
far
I
think
it
happened.
Immediate
ever
seed,
like
an
external
document
and
in
one
of
the
meeting
we
discuss
idea,
I
think
was
kind
of
was
help
women,
but
more
or
less
the
common
idea
that
we
should
like
to
try
to
keep
a
reference
from
the
use
case
and
just
to
keep
the
conversation
in
place.
C
Should
we
at
some
point
preview,
this
seascape,
because
at
this
point
there
are
many
use
cases
where
are
still
able
like
out
of
the
scope?
Another
less
that's
implying
there
are
not
like
finish,
but
the
thing
that
I'm
going
to
cover
say
clean
up.
These
have
a
kind
of
official
needs
of
references
cases
just
for
the
sake
of
saying
these
requirements
is
because
of
this
case
a
OB
I
think
that
would
be
very
a
food
not
right
now.
A
So
if
you
mention
the
use
case
for
me,
note
that
we
filled
in
so
we
discussed
that
last
week
that
we
will
PR
that
use
case
document
inside
the
Reaper
and
then
as
work
streams,
make
progress,
jep's
or
closer
API
enhancement.
Proposals
will
take
out
the
use
cases
that
make
sense
for
that
cap
and
put
put
them
like
pretty
much
move
them
over
if
they
make
sense.
I
hope
that
answered
your
question.
I.
A
So
this
PR-
it's
probably
gonna-
get
merge
this
at
some
point
this
week,
unless
there
are
any
more
updates
to
be
done,
but
it
adds
in
into
the
docs
slash
proposal
the
kind
of
like
the
template,
but
there
is
a
template
there,
but
also,
it
will
add
the
scope
and
objective
for
this
project.
The
idea
is
to
have
also
dog
slash
use
cases
that
which
is
like
a
war.
D
D
A
Yes
or
no
so
today,
actually
the
cluster
uptick
is,
it
is
optional.
The
problem
is
that
it
is
creating
fragmentation
across
providers.
So,
for
example,
one
provider
will
define
clustering
machines
and
the
problem
that
we
have
seen
a
lot
is
that
the
cluster
at
this
point
in
time
it's
kind
of
like
an
overloaded
type,
given
that
it
also
manages
the
infrastructure
and
you
also
manage
network
resources,
for
example,
it
up
gets
right,
balancers.
D
Guess
my
guess:
okay,
how
opinionated
do
we
want
so
so
there's
the
cluster
API,
which
defines
these
basic
resources
and
there's
controllers
that
manage
those
and
things
like
machine
controller.
That's
going
to
be
provider
specific
I!
Think
already
today,
machine
deployment
is
not,
which
is
great,
the
that's
built
on
top
of
other
api's
and
and
so
with
cluster.
If
we,
if
we
say
we
breaking
into
this
infrastructure
or
control,
clean
or
different
pieces,
what
are
the
API
is
between
those
things
and
and
which
controllers
can
be
swapped
out?
And
how
do
we?
D
How
do
we
keep
it
clean
like
it
was
done,
I
think
with
machine
and
machine
deployment
that
you
don't
want
to
bake
in
too
many
opinions
to
the
specification,
because
the
individual
provider
of
saying
cluster
controller
is
going
to
want
to
put
their
opinions
in
that
in
that
kind
of
deployment.
That's
what
I'm
trying
to
get
out
yeah.
A
And
I
think
that's
it's
a
really
good
in
question,
and
it's
also
one
of
the
goals
that
we
want
to
provide
like,
for
example,
some
some
isolation
between
the
types
but
I
think
the
answer
to
your
question
is
extension
mechanism.
Work
stream
will
actually
like
achieve
the
extensibility
you're.
Looking
for
okay
from
a
tie
perspective,
you
mentioned
it
like
you,
don't
see
you
you
kind
of
like
you
want
to
use
like
these
types
as
composable,
but
this
should
not
be
interlinked
and
I
do
agree.
One
thing,
though,
that
it
was
confusing.
A
A
Then
it's
very
clear
that,
like
these
machines
are
part
of
this
cluster
at
this
control
planes,
part
of
this
cluster
and
then
from
a
user
perspective.
I
might
be
able
to,
for
example,
have
one
single
speck
where
I
could
and
just
bring
for
me
here.
What
I
could,
for
example,
describe
my
cluster
that
I
want
submitted
to
cluster
yeah
in
Kosrae.
P
I
would
create
those
links
for
me.
D
E
A
question
here:
you
are
the
resources
like
machines
and
so
forth
makes
sense
without
without
having
a
cluster
in.
If
yes,
then,
then,
under
what
circumstances,
what
would
be
cases
where
you
have
a
machine,
but
you
wouldn't
have
a
cluster
yeah
I
understand
that
you
probably
needs
to
create
some
sort
of
flexibility
and
abstraction
to
chill
out
the
providers
to
provide
their
own,
but
the
we
was
even
with
it
yeah,
and
there
was
some
consensus,
the
machines
or
machines
s
would
exist
if
we
don't
have
the
the
cluster
I.
D
Think
the
the
the
the
scenario
I'm
thinking
of
is
that,
as
a
provider
of
a
distribution
that
I
may
decide
that
the
way
that
the
open
source
community
is
defined,
cluster
isn't
doesn't
fit
with
the
way
I
want
to
deploy,
kubernetes
and
so
I
I
would
still
like
to
be
able
to
use
the
other
valuable
things
like
the
machines
and
the
machine
controllers
would
not
necessarily
be
forced
to
adopt
the
cluster
object
itself.
It's
not
that
that
that
has
much
meaning
without
it.
It's
that
I
may
want
to
provide
my
own
alternate
I.
F
Think
this
is
I
think
this
is
particularly
pronounced
because
in
the
machine
object
space
because
the
you
may
just
want
to
use
machine
objects
for
provisioning
things
of
our
clusters
or
you
may
have
in
one.
In
our
case
you
may
be
adapting
the
machine
pieces
and
then
working
on
adapting
the
cluster
API
as
well.
G
G
A
A
Is
it
one
give
like
every
like
right
now,
for
example,
the
clusters
I
was
mentioning
like
you
have
to
create
things
in
a
certain
way
right,
which
I
believe
that's
the
main
limitation,
so
I'm
going
to
see
if
you
see
other
limitation,
they
you
mention
you
here,
because
one
thing
that
I
would
like
to
say
is
the
tightly
coupled
the
components
that
we
have
for
machines
control
plane
to
the
cluster,
because
they
are
at
the
end
of
the
day.
They
are
part
of
a
cluster.
E
Also,
wouldn't
it
the
having
loose
coupling
assist
in
additional
levels
of
fragmentation
which
might
not
be
beneficial
to
everybody
click
you
know
long
term.
That's
just
one
way.
I
guess
concerns
if,
because
having
kind
of
set
limited
set
of
ways
of
how
you
accomplish
things
kind
of
helps
solidify
this
approach,
just
write
them.
So
that's
just
additional
question:
if
I
may.
H
Sorry
can
I
go
so
with
this
loose
coupling.
It
will
also
help
in
interacting
the
cluster
independently
like
if
we,
if
we
don't,
have
loose
coupling,
there
are
approaches.
Now
there
are
installers
which,
which
will
need
to
adapt
like
rebase,
which
will
need
to
be
base
and
change
the
whole
system
at
the
start.
So
if
we
have
moose
coupling
installers
or
the
provisioners
can
adapt
the
cluster
area
incrementally
step
by
step
like
first
the
machines
and
then
in
next
phase,
the
control
plane
or
the
cluster
level.
I
We
need
to
try
to
be
methodical
when
we
go
through
this
list.
You
know
I
felt
this
third
by
actually
identifying
what
our
goals
are.
I
know
we
have
some
high
level
goals
or
requirements.
I,
don't
think
they
necessarily
explain
how
we
should
see
here,
because
we
have.
This
is
that
discussion
regarding
a
cluster
object.
It
leads
the
dozen
times
of
the
last
18
months
and
part
of
the
reason
for
this
meeting
and
new
structure
is
to
see
if
we
can
actually
drive
some
resolution
to
these
issues.
I
Make
are
actually
the
right
ones
at
this
point,
but
long
term
I'm
going
for
I
think
it's
important
that
we
assume
additional
semantics.
The
lack
of
additional
high-level
semantics
limits.
What
kind
of
tooling
can
build
you
build
on
top
of
the
cluster
API
so,
for
instance,
that
we
have
no
semantics
around
the
control
plane,
because
we
save
your
in
pieces
where
you
cannot
manage
the
control
plane.
That
means
that
all
Tyler
Perry
little
tuning
cannot
manage
the
control
plane
because
the
cluster
API
provides
no
semantics
right.
I
So
so,
in
recap,
the
two
points
are
I
think
we
might
want
to
identify
our
goals
and,
like
one
goal,
I'd
suggest,
is
to
enable
higher
level
semantics
to
enable
semantics
for
higher
level
to
lean
right
neck
and
be
justified,
these
Union
requirements
or
use
gates
in
stock,
but
then
also
that
we
go
through
this
and
try
to
be
really
diligent
about
not
inflating
multiple
issues
and
just
look
at
each
type
and
the
problem.
It
attempts
to
solve
to
the
extent
possible
without
referendum,
problems
that
may
be
sold
by
other
faiths.
D
A
synchronously
over
the
next
few
weeks,
but
I
think
that
was
a
really
good
point
and
that
what
that
translates
to
to
me
is
understanding
lately,
like
you
mentioned
the
use
cases
and
the
use
cases
for
each
individual
type,
which
will
dictate
the
API
that
that
type
has
to
expose,
and
so
you
know
it's
those
api's
that
end
up
being
the
contract
between
the
types
as
well.
So
I
think
that
understanding
the
real
use
cases
is
probably
the
only
way
to
get
there.
A
Perfect,
so
for
next
steps,
I
think
I'll
send
a
new
document
about
with
the
cap,
template
and
we'll
start
like
adding
use
cases
I'll
go
to
the
existing
use
cases
dog
and
try
to
link
them
the
one
that
already
existing
and
please
do
join
the
the
sake
group
to
have
edit
access
give.
Given
that
I'll
give
it
a
text
to
the
whole
sake,
so
you'll
be
able
to
contribute.
D
J
So
I
would
say
today
the
biggest
value
in
the
cluster
object
is-
and
this
is
only
recently
as
a
maybe
like
a
month
and
a
half
two
months
ago,
at
the
most,
when
we
start
adding
the
remote
object,
references
and
the
owner
references,
it
gave
you
the
ability
to
kind
of
handle
like
cascading
deletion
of
the
cluster
longer-term.
The
real
value
that
I
see
for
the
cluster
object
is
really
being
a
single
point
within
cluster
API
to
go
to
to
rationalize
about
the
clusters.
J
So,
ideally,
I
would
love
to
see
certain
types
of
status
get
bubbled
all
the
way
up
to
the
cluster
object,
so
that,
as
an
operator,
if
I
want
to
be
able
to
sit
there
and
introspect
the
health
or
or
status
of
my
clusters,
I
should
be
able
to
start
with
the
cluster
object,
to
see
like
kind
of
an
aggregated
state
of
that
cluster.
So
to
speak,
and
then
only
have
to
dig
into
the
different
components
of
the
cluster.
J
D
And
I
suppose
in
any
in
any
distribution
we
I
guess
we
all
think
in
cotton.
We
all
think
with
the
concept
of
a
cluster
today.
It's
that
there's
a
defined
meaning
of
more
or
less
communities.
For
that,
so
there's
going
to
be
all
those
infrastructure
resources
we'll
mentioned
earlier
are
often
gonna
be
on
a
per
cluster
basis.
So
having
some
record
of
there's
a
cluster,
and
these
are
the
things
associated
with
it-
makes
sense.
D
I
guess
I'd
like
to
understand
more,
if
it's
possible
to
build
more
semantics
and
therefore
more
value
into
that
or
if
that's
just
going
to
be
a
non-starter
because
it
puts
too
much
opinion
in
the
the
spec
and
I
guess
it
comes
back
to
those
use
cases.
C
That
I
always
have
been
working
with.
They
recently
came
to
the
same
situation.
They
came
to
a
different,
comes
that
I
want
to
miss
up,
but
the
constantly
the
completion
will
be
similar
to
go.
Jason
said
they
realized
that
they
need
an
answer.
Yes
to
have
the
status
and
some
end
points
to
magnetic
Gloucester
and
actually
was
interesting
because
they
had
this
object
and
now
they
were
are
considering
using
for
even
cluster.
They
are
not
badly
managed.
You
know
they
are
not
creating
you
see
they
they
they
got
to
the
prior.
C
C
You
can
get
estates
and
this
really
useful
when
you
have
a
large
infrastructure
to
a
station
set,
you
have
for
the
state
to
their
and
you
can
know
which,
based
on
this
concept
of
the
end
points
you
can
know
which
actions
you
can
not
only
making
this
cluster
felices,
you
don't
have
access
to
the
control
play
for
whatever
reason
you
don't
have
this
access
point,
I'm,
sorry,
city
endpoint,
and
you
do.
You
can
have
the
credential
for
access,
and
so
she
is
quite
useful
for
tooling.
C
A
One
thing
that
outright
I
want
to
try
to
avoid
is
having
machines
so
like
lose
that
like
in
the
future,
we
might
we
might
one
at
like
a
member
on
the
scope
and
that's
ok,
but
at
this
point
in
time,
would
they
decide
to
manage
communities
clusters
in
the
cluster
will
kind
of
tied
up
all
this
resources
together
and
provide
a
better
UX
right?
That's
that's
one
thing
that
we're
missing
at
this
point
in
cluster
API
is:
how
do
we
streamline
UX
across
providers?
A
The
the
idea
is
that
the
clusters
I
could
could
do
that
right
in
the
fullness
of
time,
could
could
offer
that
streamline
UX
for
users
and
also
developers,
it's
like
when
we
create
a
new
provider
today.
The
cluster
type
that
we
have
today
is
kind
of
overloaded
has
like
a
lot
of
meaning
to
it
and
like
or
like,
as
it's
really
undefined
what
it
should
do
and
what
I
shouldn't
do.