►
From YouTube: 20190418 - 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
A
We
will
go
to
the
introduction
once
again
and
then
just
discuss
briefly
the
proposal
working
document,
so
this
work
stream
was
created,
possibly
one
of
the
one
to
define
high-level
types
for
cluster
API
boundaries
requirements
and
their
use
cases.
We
have
a
proposal
working
working
document
that
I'm
linking
by
now
in
the
chat
it
you
can
take
a
look
at
it.
This
is
the
cap
template
which
was
kind
of
like
prefilled
with
a
bunch
of
text
it's
open
for
edit,
if
you
don't
have
edit
access.
Please
join
this
sake.
Cluster
lifecycle,
Google
Group.
A
A
The
extension
is
important
for
this
work
stream
as
well,
given
that
we
need
to
define
those
extension
points
for
the
types,
but
we
want
to
make
sure
to
just
keep
the
extension
mechanism
as
a
black
box.
So
we
say
there
is
an
extension
mechanism
and
this
these
are
the
extension
points
that
we
want
to
offer
for
these
types.
B
I'll
just
comment
on
that
that
I
definitely
an
on
board
with
that
mentality.
In
that
approach,
however,
an
important
part
of
data
modelling
often
is
considering.
How
is
this
data
going
to
be
used,
in
particular
when
you're
designing
API
we're
doing
both
here?
So
I
think
this
is
a
fine
approach
for
now,
but
I
suspect,
as
these
two
groups
come
closer
to
some
kind
of
consensus
on
the
path
forward,
the
black
box
will
be
opened
up
and
revealed.
A
Yes,
hopefully
that's
gonna
happen
like
when
we
know
which
you
know
extension
mechanism.
The
community
wants
to
adopt.
Excuse
me,
but
yes,
I
do
suspect,
that's
going
to
happen
and
we
can
always
extend
the
proposal.
So
one
thing
that
we
we
made
sure
in
the
cap
template
is
kind
of
like
state
that
we
want
to
always
merge
early
right
like
even
if,
in
two
weeks
we
have
a
proposal
up
and
that
proposes
merged
like
nothing
stops
us
from
like
open
a
new
PR
and
update
updating
that
s
like
we
have
more
meetings
and
more
discussion.
A
C
A
Given
that
like
we
know
that
we're
gonna
have
data
model
and
we
know
that
we're
gonna
have
an
extension
mechanism
and
we
also
know
that
when
I
manage
kubernetes
clusters,
I
do
expect
that
we
go
one
layer
in,
but
we
know
yet
writing
yeah
all
documents,
for
example,
which
can
probably
happen
after
like
the
goals,
non
goals
and
requirements
are
set
so
that
we
know
what
we
want
to
achieve.
And
then
from
that
we
can
probably
start
writing
some
implementation
details
and
like
right,
yeah
more
like
API
that
we
want
to
offer
and
so
on.
A
Okay,
so
if
there
are
no
any
more
questions,
I
think
the
work
stream
is
good
to
go
in
terms
of
just
collaborating
a
synchronously
on
the
document,
which
will
also
let
other
folks
that
cannot
attend
this
synchronous
meetings,
kind
of
leave
comments
or
edit.
The
document
as
we
go
I
will
be
starting
working
on
it,
like
kind
of
more
full
time,
probably
tomorrow
or
next
week.
But
I
do
expect,
like
kind
of
in
the
next
two
weeks,
to
make
a
good
progress
on
it
and
move
to
probably
a
PR
afterwards.
B
Can
we
talk,
maybe
briefly
just
about
at
least
what's
the
plan
forward
in
terms
of
identifying
the
goals
and
the
non
goals
here,
at
least
for
me
when
I
look
at
this
datum
all
proposal,
doc
I'm
just
not
sure
how
to
engage
with
it
or
how
I
should
be
contributing
from
a
standpoint
of?
Are
we
trying
to
describe
the
existing
state
of
the
data
model
and
then
make
changes
from
that?
Are
we
trying
to
reinvent
and
re-engineer
what
already
exists?
A
That's
a
very
good
question,
so
this
document
should
be
kind
of
a
little
bit
of
both
I
would
say
so
from
one
from
one
side.
We
wanna,
like
you,
know,
understand
like
what
we
have
today
and
we
want
to
start
from
there
and
try
to
understand.
A
So
to
answer
your
question:
yes,
we
need
to
have
the
goals
and
on
goals.
I
do
suspect
that
we
will
follow
and
kind
of
like
even
copy
the
ones
that
we
have
for
the
product
as
a
whole,
given
that
those
like
still
need
to
be
kind
of,
you
know
respected,
and
we
need
to
use
the
statement
and
goals
document
that
we
have
in
cost
recovery
as
a
foundation
for
this
work.
A
Can
we
make
that
kind
of
more
like?
Can
we
bring
more
logic
upstream
for
the
load
balancers?
Just
to
give
an
example:
I'm
not
nothing,
that's
the
solution,
but
that's
what
I
would
expect
this
community
could
do,
but,
yes,
like
I,
definitely
like.
We
should
start
from
the
cold
goals
for
the
proposal.
I
do
agree
and
if
you
have
spare
cycles,
please
do
add
anything
to
it,
then
other
focusing
Oh,
obviously
comment
or
leave
suggestions.