►
From YouTube: 20190424 - Cluster API Office Hours
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
We
have
a
relatively
light
agenda
today,
so
if
you
have
any
topics
that
you
want
to
cover,
please
go
ahead
and
add
them
to
the
agenda
and
also
make
sure
that
you
add
yourself
to
the
attendee
list
in
the
agenda
as
well.
I'm
going
to
go
ahead
and
paste
that
link
in
the
chat
for
people
who
are
following
along
live.
A
The
first
topic
on
our
agenda
today
is
I,
wanted
to
give
an
update
about
the
contributor
t-shirts
that
I
brought
up
a
few
weeks
ago.
We
do
have
those
getting
printed
out
if
you
were
able
to
get
your
name
on
the
list
and
you
will
be
in
Barcelona,
you
will
be
able
to
pick
them
up
from
the
VMware
booth
at
Barcelona.
A
Otherwise,
if
you
have
already
gotten
your
name
on
the
list-
and
you
give
me
your
address,
it
will
be
sent
out
directly
to
you
as
well.
Apologies
for
folks
who
weren't
able
to
get
on
the
list.
In
time.
We
had
a
deadline
for
giving
printing
done,
but
I
will
go
ahead
and
create
a
PR
today
for
the
cluster
API
repo
to
share
the
share
of
the
designs.
If
you
want
to
go
ahead
and
get
them
printed
up
yourself,
you
have
more
than
welcome
to
do
so.
A
B
So
the
PR
I
think
was
open
last
week
address
the
most
of
the
comments,
if
not
all
of
them.
This
morning
you
said
it's
like
a
reminder.
This
document
is
meant
to
be
as
a
staging
area.
It's
not.
They
make
all
the
use
cases
they're
like
we
possibly
will
have.
It's
meant
to
be
just
like
as
a
reference
for
the
caps
that
are
going
to
be
compiled
within
the
work
streams
and
then
kind
of
use,
cases
like
the
canal
and
like
match
matching
requirements
in
each
cap.
B
A
B
Better
model
has
met
already
twice
in
the
last
two
weeks.
We
are
halves
which,
like
folia,
synchronous
right
now.
The
proposal
document
is
where,
like
we're
kind
of
like
pushing
forward
as
a
reminder,
the
data
model
goal
is
to
produce
a
proposal
that,
like
will
delineate,
define
and
set
boundaries
between
types
at
the
current
one
and
the
new
one
that
we
want
to
introduce.
B
We
have
modeled
the
use
cases
across
all
of
them,
but
please
feel
free
to
add
more
use
cases
there
as
well
and
afterwards
we
will
probably
start
like
kind
of
modeling
some
llamo
and
try
to
get
like
a
little
bit
into
more
implementation
detail.
As
as
we
go
forward,
we
also
have
been
in
touch
with
API
reviewers
from
kubernetes
upstream,
so
the
proposal
will
be
reviewed
so
that
we
can
get
kind
of
like
on
the
same
page
and
get
more
eyes
on
it.
From
like
a
newcomer
perspective,.
C
We
had
a
kickoff
meeting
on
Thursday
and
very
mediately
naturally
understood
that
this
is
a
very
broad
topic
and
then
we
discussed
quite
some
items
which
could
be
in
scope
out
Skoob
so
for
details.
Maybe
you
can
check
the
document
with
the
minutest
document,
but
from
the
high-level
first
of
all,
we
discussed
that
very
basic
patient
that
how
how
to
deploy
all
also
very
pro
deploy
the
control
plane.
There
was
still
open
question
that,
because
the
looking
at
the
use
case
document
also,
we
had
we
had
other
approaches
proposed.
C
So
then
we
basically
narrowed
down
to
three
approaches
which
we
want
to
investigate
and
decide
which
could
be
or
which
or
if
all
of
them
would
be
in
a
good
enough
to
have
intercept
API.
So
the
approaches
were.
The
first
approaches
is
what
we
are
doing
right
now,
where
we
have
very
great
machines,
as
masters
envy
who's
the
controller
planes
there.
C
Then,
when
I
push
came
out
else,
we
could
have
a
management
cluster
which
can
host
the
control
plane
of
the
workload
clusters
and
the
third
approach
that
we
want
to
investigate
is
that
how
to
use
in
manage
services
in
the
cluster
API.
So
that
could
also
be
managed.
Services
like
if
you
want
to
foolishly
create
the
clusters
with
the
GK's
control,
plane
or
a
cache
and
so
on.
C
Then
we
also
discussed
how
to
auto
scale,
how
to
dynamically
auto
scale,
the
controller
and
components.
So
as
it's
clear
that,
probably
day
one
creating
the
deployment
underpin
is
always
easier,
but
maintaining
the
control
plan
when
more
and
more
approach
comes
in,
comes
harder
and
decided
that
probably
will
be
successful
as
as
part
of
the
design
dog
that
we
will
prepare.
So
it
was
more
or
less
it
probably
next
week,
new
level
have
one
more
meeting
follow-up
meeting
on
the
word
extreme.
Keep
it
updated
in
this
yeah.
D
We
basically
tried
to
enumerate
what
was
the
in
scope
and
meta
scope.
We
took
a
step
back
and
that
we
focused
on
behaviors
what
it
means
and
I
think
what
was
the
prominent
theme
I
kept
on
trying
to
reiterate
and
as
well
as
yoga
feedback
monsoon
was
that
immutability
in
so
I
think
for
the
most
part,
we
have
the
model
in
place.
What
constitutes
the
life
cycle
for
a
note,
and
what
we
need
to
do
this
week
is
determine
which
component
tree
and
what
things
are
in
scope
and
what
things
are
explicitly
otoscope.
F
E
C
Yes,
so
laughing
I
could
not
attend,
but
then
I
had
replace.
It
means
to
circulate
to
the
proposal
document
and
I
think
we
have
quite
some
time,
so
maybe
I
can
brief
a
little
bit
on
it.
So,
even
when
the
note
life
cycle
were
extreme,
we
could
not
find
a
spot
but
anyway,
so
so
that
there
is
also
an
open
issue.
F
C
So
I
created
a
proposal,
talk
on
that
and
maybe
I
can
take
this
chance
and
describe
a
little
bit
that
what
what
see
oral
idea
and
if
there
are
any
comments
or
situations.
So
there
was
also
nice
discussion
and
the
bottom
line
for
the
discussion
was
that
we
should
try
to
be
as
less
descriptive
as
possible,
and
so
the
idea
was
that
we
should
try
to
be
editing
and
not
be
authoritative
in
such
a
prose
like.
So,
if
you
read
the
proposal
talks
I.
C
What
I
have
tried
to
do
is
that,
basically
we
become
additive
in
a
way
that
when
you
create
the,
let's
take
an
example
for
the
things
when
we
create
a
taint.
We
we
propagate
it
till
the
node
objects,
as
it
is
as
it
should
be
for
all
respective
controllers,
from
the
machine
deployment
or
the
machine
set
controller
maintains
same
paint
across
all
of
the
node
objects
which
belongs
to
that
machine
set
and
while
creating
if
the
flow
is
pretty
simple.
While
updating
also
flow
is
pretty
simple.
C
If
user
go
sign
up
and
update
some
things
on
the
machine
set
labels
or
the
notation,
sometimes
you
can
quickly
update,
but
then
there
was
a
trick
in
deleting
such
information.
So
we
realized
that
if
user
has
let's
say,
and
also
to
add
that
if
user
wants
to
add
custom
levels
and
rotations
and
paints
on
the
node
object,
and
probably
we
should
not
mess
with
it.
C
So
it's
pretty
much
possible
that
certain
things
are
coming
from
the
Machine
controller,
but
there
are
then
there
are
also
things
which
user
has
directly
applied
to
the
node
object
and
might
not
really
be
willing
to
be
managed
by
the
higher
level
controllers
like
Mission
Control.
So
then
the
deletion
flow
become
a
little
bit
a
little
bit
tricky.
C
Well,
if,
in
the
past,
user
puts
that's
a
taint
expose
to
why
certain
effect
and
if
for
reason,
diseases
decides
to
eat
that
thing
from
the
machine
set,
and
there
is
each
case
well,
if
the
controller
restarts
or
controller
loses
the
state,
then
it
is
not.
You
know
not
really
a
good
way
for
us
to
decide
that
which
thing
was
really
clicked
by
the
user
and
how
to
go
ahead
and
delete
that
specific
paint
or
label
of
renovation
from
the
node
object.
C
D
Want
to
stop
here
for
a
second
heretic
like
you're,
buying
way
into
implementation,
detail
and
the
question
I
have
is
with
we
only
specified
Tate's
originally
as
the
initial
bootstrapping
element
that
is
required
to
literally
originally
quarantine
machine
on
entry
right,
we've
never
specified
the
notion
of
annotations
for
labels
explicitly
because
you
can
do
it
as
a
post
process
step
independently.
So
the
question
I'm
trying
to
understand
here
is
you
went
from
zero
to
implementation
without
the
user
story
of.
D
Why
why
we
would
go
through
and
explicitly
take
on
the
state
space
of
labels
and
annotations,
because
then
you'd
have
to
control
that
and
monitor
it
and
do
everything
else
that
is
required
from
a
respected
status
perspective.
So
what
is
you're
trying
to
accomplish
here
and
you
could
accomplish
externally?
Yes,.
C
So
this
actually
did
use.
The
story
actually
came
quite
something
that
on
the
discussions
here,
it
was
not
actually
figure
out
the
discussions.
The
idea
was
more
or
less
that
if
such
information
is
there
on
the
node
object
and
somehow
we
should
maintain
now,
if
you
mentioned,
probably
it
should
be
perfectly
fine.
That's
probably
a
taint
is
something
that
we
create.
C
Only
at
the
time
of
the
creation
and
probably
labels
renditions
could
be
something
that
user
might
want
to
add
later
by
our
controllers
and
expect
that
gets
the
pocketed
and
maintained
objects
and
I'm,
not
sure,
though,
but
the
question
the
main
use
case
was
that
that
we
we
somehow
ones
want
to
maintain
such
information
on
the
node
object.
Now.
D
That's
not
an
use
case,
though,
like
I
need
a
user
story
like
we
need
to
do
this
for
a
reason
X
like
just
because
we
have
it
there
or
have
the
capabilities.
That's
not
necessarily
a
user
story.
Houston
scenario,
the
user
story
and
use
case
scenario
is
that
it
tells
the
need
for
an
operator
that
we
couldn't
fulfill
otherwise
with
the
current
day
tomorrow.
C
But
then
it
does
happened
that,
because
of
scaling
up
is
scaling
down
at
some
point,
those
syllables
and
those
things
would
probably
be
lost,
so
a
user
is
saying
that
do
we
have
any
way
of
a
combination
of
this?
Why
are
these
machine
controllers,
which
can
maintain
such
information
on
the
node
object?
Each.
D
Team
makes
perfect
sense.
Okay,
I
can
totally
get
behind
Tate
for
initial
joining
in
skeleton
sputum
all
right
and
that
already
exists
in
another
tooling.
It's
the
the
labels
and
annotations
I
still
understand
the
user
story,
because
the
initial
taint
could
go
through
its
own
process
for
entry
right.
It's
it's
a
conflating
idea.
The
reason
why
I
was
not
put
in
other
tools,
so
I
want
to
make
sure
that
we're
explicit
about
understanding.
What
is
the
explicit
user
story?
C
C
Yes,
I
use
that
all
the
time
that
I
just
made
it
little
earlier,
sometime
back
and
then
mr.
template,
maybe
I,
will
migrate
this
on
the
template,
but
before
that
maybe
good
idea
to
actually
discuss
user
stories.
So
for
the
things
it
also
tied,
atop
the
user
story,
so
for
talented,
since
it
make
sense
for
labels,
it
could
be
more
about
the
equities
and
so
on,
but
let's
I
would
say
rather
dropped
it
first,
so
that
everyone
can
comment
on
it.
I.
D
F
A
F
Mean
I'm
happy
to
help
with
that
proposal.
I
think
we
do
have
a
similar
use
case.
I
mean
in
eks
control.
We've
implemented
an
ability,
a
feature
for
user
to
just
set
paints
and
labels
for
for
a
group
of
nodes
when
they
create
a
node
group,
they
can
set
labels
and
chains
for
that
group
and
those
are
pasta
and
s,
cubed
floods
and
obviously
they're,
not
recluse
elated,
and
we
don't
actually
take
no
groups
of
such
so
so
yeah.
F
D
Are
multiple
ways:
I
mean
the
taste.
One
is
well
established
right,
like
that's.
That's
been
talked
about
and
at
length
at
nauseam
upstream,
so
I
totally
get
that
the
the
labels
was
considered
controversial,
so
it
was
explicitly
I'm,
not
in
scope,
and
a
person
could
automatically
if
they
wanted
to.
They
could
apply
default
labels
by
having
the
image
creation
mechanism.
Whatever
that
may
be.
F
F
F
C
Ownership,
in
a
sense
machine
said,
I
guess,
has
to
be
labeled.
Selectors,
admit
I
said
because
selectors
as
a
different
level
that
which
machines
has
actually
the
labels
which
are
satisfying
and
based
on
that
electricity
sizes,
are
the
set
of
machines
which
should
be
under
that
one
particular
machine
sets.
And
then
the
owner
references
on
the
machine
points
like
to
the
Machine
set
right.