►
From YouTube: 20190904 - 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
Hello
today
is
Wednesday
September
4th
2019.
This
is
the
cluster
API
office
hours.
Cluster
API
is
a
sub-project
of
CID
cluster
life
cycle.
As
always,
we
do
have
meeting
etiquette.
Please
use
the
raise
hand
feature
if
you'd
like
to
say
something.
Please
add
your
name
to
the
attending
list
and
if
you
have
any
items
for
the
agenda,
please
feel
free
to
add
them
down
here
at
the
bottom
and
we
will
go
ahead
and
get
started
so
some
PSAs
we
have
draft
releases
of
cluster
api
0.2,
which
is
the
first
v
1
alpha
2
release.
A
There
is
a
fairly
serious
bug
that
was
identified
and
fixed
yesterday,
and
that
is
one
reason
that
we
have
not
published
the
zero
to
zero
release.
We
will
be
doing
0
2.1
shortly.
We
also
need
to
have
some
getting
started
guides,
so
that
is
another
reason
that
we
have
not
officially
published
the
release
yet,
but
the
images
are
out
there
again
will
have
an
updated
cluster
api
released
shortly.
A
We
have
similar
drafts
for
the
cubm
bootstrapper
as
well,
and
we
are
working
on
updating
the
cluster
api
book
using
a
new
technology
called
md
book
and
there's
an
open
flow
request
to
make
that
change.
So
if
you
have
not
taken
a
look
and
you're
interested,
please
do
so
and
as
I
mentioned,
we
are
still
working
on
some
getting
started
documentation
if
you're
interested
in
helping
with
that.
We
would
certainly
appreciate
that-
and
you
can
talk
to
to
any
of
us
about
that
as
well.
A
B
C
D
E
G
H
Yeah
I
can
go
so
I.
Have
it
you're
open
to
add
the
types
for
V
1
alpha
2,
but
we
put
a
hold
on
that
and
I'm
working
on
making
some
end-to-end
tests
work
for
pure
gates.
Before
we
start
moving
towards
me.
1
alpha
2
awesome.
A
And
the
upgrade
tool
I
know
we
still
have
an
open
issue
to
support
v1
alpha,
2
and
amy.
Chen
is
going
to
be
putting
together
an
initial
plan
for
what
the
changes
will
look
like
and
start
working
on
that
either.
Hopefully
this
week,
all
right
before
we
move
on
to
the
next
agenda
items.
Does
anybody
have
any
additional
comments
or
questions
on
the
provider?
Statuses.
A
C
D
It's
not
even
like
I'm
sure
the
information
is
there,
but
making
sure
it's
visible,
I
think
Vince's
work
on
the
documentation
and
I
think
it'll
probably
be
easier
to
keep
up
to
date.
Now
we'll
go
a
long
way
to
do
that,
but
making
sure
this
stuff
is
visible
and
and
how
to
use
this,
especially
given
that
there's
multiple
locations
now
for
the
way
we
do
customized.
So
there's
at
least
two
places
where
we
have
to
keep
those
versions
in
sync,
when
it
was
just
one
before.
C
F
Tim,
it
sounds
like
a
convention
for
just
a
basic
Cappy
layer.
So
that
way,
if
somebody
installs
some
Rando
provider,
you'd
have
some
way
of
detecting
compatibility,
I,
think
cluster
ad
and
what
bacon
defaults
like
Jason
was
saying.
So
that
way
the
out-of-the-box
experience
is
consistent.
But
if,
if
somebody
does
a
DIY,
there's
some
checks
or
balances
in
the
system
to
enable
detection
of
whoops
wrong
version.
A
B
So
today,
I
put
together
just
a
list
of
the
behaviors
of
the
bootstrap
provider,
who
Vidya
and
I
would
love
to
start
writing
some
tests
around
these
things.
Some
tests
may
already
exists
for
these
behaviors,
but
generally
I'd
like
to
try
to
avoid
regressions
in
this
miss
controller.
So
I
think
this
would
be
a
really
cool
place
for
people
to
get
involved
if
they're
looking
for
ways
to
get
involved
with
any
of
the
cluster
API
providers.
D
D
Said,
like
improved
user
experience,
behaviors
that
threw
me
off
like
I
didn't
know
that
seemed
more
feature
related,
so
I
said.
Okay,
can
we
talk
about
user
experience?
I
I
see
what
you
mean
now,
though,
so
yeah
I'll
follow
these
issues.
I
just
wanted
to.
Let
you
know
to
resolve
them
and
remove
that.
So
we
don't
got
it
I,
don't
confuse
others
thanks
Andrew.
A
F
A
I
A
No
thanks
I
got
it.
So
if
you
do
have
any
proposed
agenda
topics,
please
feel
free
to
add
them
to
that.
Second
link:
I
think
we
can
certainly
and
should
communicate
asynchronously
about
this
leading
up
to
the
face-to-face.
It
is
a
two-day
meeting
and
a
overall
purpose
is
to
talk
about
alpha-3
and
do
planning
for
that.
But
if
there's
additional
time
we
can
talk
about
other
things
as
well.
So
please
take
a
look
at
that
document.
If
you
can.
D
I
had
questions
for
Tim.
Thank
you
about
clustering.
A
cluster
ADM
I
was
wondering
what
the
general
status
of
that
was,
and
maybe
that
will
be
discussed
at
the
off-site.
But
you
know
I
noticed
that
you,
cat
B,
didn't
implement
it
for
the
V
1
alpha
2
draft,
because,
based
on
what
I
saw
with
Kappa,
it
was
sort
of
an
as-needed
situation.
We
didn't
need
it
me
on
what
we
were
doing
with
generate
and
that
I
wasn't.
F
D
A
A
D
D
A
A
A
So
if
we
look
at
issues
with
no
milestone
everything's
assigned
so
the
way
that
we're
tracking
things
now
is,
if
there
are
issues
that
we
want
to
do
in
the
0-2
series
for
B
1,
alpha
2,
we
add
them
to
the
0
to
X
milestone
and
then,
if
there's
things
that
are
more
of
a
long-term
vision
or
we
don't
necessarily
know
if
we
want
to
do
them
right
away,
we
put
them
in
next.
So
if
you
are
looking
for
something
to
work
on,
we
do
have
42
bouken
issues
in
the
0
to
X,
milestone.
I
A
F
I
think
we
should
do
a
flag
day
for
a
bunch
of
these
anything.
That's
a
feature
should
probably
be
punted.
As
you
know,
we
went
out
for
two
gets
released
and
we're
not
going
to
make
those
changes
and
B
what
happen
to
and
like
I
want
to
start
to
get
us
to
the
point
where
we
have
strict
adherence
to
policy
where
we
say
feature
back.
F
J
One
day
asked
about
the
face-to-face,
so
there
there
are
some
topics
that
I
think
we'll
all
want
to
talk
about,
for
instance,
control,
plane,
management
or
handling
add-ons
anyway,
there's
a
whole
list
and
what
I'm
wondering
is
I
think
I
see
each
of
these
discussions
as
having
two
parts.
First,
we
need
to
define
the
problem
well
and
second
right.
A
That's
a
really
good
idea,
and
it
certainly
does
not
need
to
be
or
probably
should
not
be
complete
proposals.
So
just
to
pick
on
one,
for
example,
like
control,
plane
management,
I
think
we
could
probably
write
up
one
or
two
paragraphs
explaining
the
problem
statement,
as
you
suggested
and
socialize
that
with
this
group
prior
to
the
face-to-face
just
so,
people
have
a
shared
understanding.
I
think
that's
a
really
good
idea.
Why.
A
A
F
A
Well,
why
don't
we
go
through
them?
We
have.
We
have
time
so
we'll
go
from
oldest
to
newest
here
this
one's
been
around
for
a
while
at
a
cap
for
a
number
of
concurrent
deletion
calls
and
machines
that
controller
nobody's
gotten
around
to
doing
it.
So
I,
don't
know
in
terms
of
importance,
I
mean
it's
listed
as
long-term
and
we
basically
it
had
been
in
the
zero
to
milestone,
but
given
its
age
and
priority,
we
planted
it
and
said
it's
not
a
release,
blocker
and
just
moved
it
into
zero
to
X.
A
F
A
A
I
know
we
have
at
least
one
other
issue
somewhere,
whether
it's
in
Kathy
or
Kappa,
to
do
validating
web
hooks
and
I
think
it
would
be
nice
to
to
get
those
into
the
zero
to
release
stream.
But
it's
certainly
not
the
end
of
the
world.
Given
that
we've
lived
with
this
from
day,
one
pretty
much
so
I'm
guessing,
we
could
probably
just
go
to
next
on
this
one.
A
I
A
All
right,
so
this
should
be
excluding
cluster
:
re
I
know:
we've
talked
about
this
one
before
this
was
some
sort
of
logic
that
got
dropped
as
part
of
a
refactoring.
That
was
it.
We've
we've
discussed
it
before
in
terms
of
bringing
it
back,
but
nobody
seems
to
know
if
it's
a
problem
or
really
remember
much
about
it.
J
A
Thanks
Tim,
that's
typing
and
talking
at
the
same
time
we're
hard
already,
let's
just
clear
out
some
bees
make
and
user
experience,
transparent
paints
and
labels.
I
definitely
think
that
if
we
do
anything
here,
it's
gonna
end
up
being
a
behavioral
change.
So
I
think
this
needs
to
go
to
long
term.
And
next
do
you.
C
H
A
E
There's
also
something
if
things
came
up
with
a
set
of
labels
that
are
allowed
to
apply
has
changed.
It's
been
restricted
and
so
cops,
for
example,
is
moving
to
a
central
controller
to
apply
those
labels
for
compatibility
reasons,
and
perhaps
we
should
just
bite
the
bullet
and
with
that
same
controller
and
cluster
API
or
a
similar
controller,
I
should
say.
A
D
D
Andy,
my
basic
feeling
on
this
is
having
done
it
recently,
that
the
there's
not
a
lot
of
work
to
implement
scaffolding
or
to
create
it.
It
will
be
frustrating
to
keep
it
up
to
date
or
maintain
older
versions
of
it
or
having
some
migration
path,
as
well
as
there's
value
and
actually
implementing
it
from
scratch.
A
C
Of
the
problems
we've
seen
in
the
past
with
that
too
is
there's,
ends
up
being
a
lot
of
Find
and
Replace
that
you
end
up
needing
to
do
with
the
scaffolding,
and
it
ends
up
being
it's
not
all
the
same
casing
and
you
know
it
ends
up
being
you
know,
it
ends
up
causing
difficulty
for
people
that
are
implementing
it.
So
when
we
initially
did
that
with
people
in
alphab
one,
we
would
end
up
having
to
help
a
lot
of
people
fix
those
copy-and-paste
replace
errors
when
they're
going
through
the
implementation.
A
D
But
I
would
much
rather
see
is
some
very
lightweight
mock
or
example,
that
is
actually
part
of
the
test
process.
It
doesn't
do
much
at
all,
except
that
if
the
example
breaks
because
of
some
dependency,
then
that
would
be
caught
so
that
we're
ensure
that
that
very
lightweight
thing
is
always
up
to
date.
We.
I
D
D
Maybe
we
could
do
this,
and
Michael
actually
had
a
lot
of
great
thoughts
on
this,
so
it
would
be
like
taking
Michaels
ideas
and
then
encapsulating
them
in
a
template
right
and
there,
and
there
honestly,
maybe
some
way
to
write
the
template
in
such
a
way
that
you
could
then
test
that
as
part
of
test
III,
don't
know
to
be
quite
honest,
I'm
past
the
point
of
being
as
sit
in
this
yeah.
That's
always
the
problem
right.
You
know
it's
over
set.
The
point
of
needing
it
is
invested.
A
D
I
A
A
Alright,
let's,
let's
revisit
my
issues
about
permanent
failures?
I,
don't
recall
if
we
came
to
a
consensus
on
this
one,
which
is,
if
you
have
a
server
or
a
virtual
machine
or
whatever
is
backing
your
your
cluster
API
machine
and
that
thing
goes
poof
or
freezes
or
fails
and
whatever,
for
whatever
reason,
I
think
it
would
be
nice
to
set
the
error,
reason
and
error
message
on
the
machine
and
just
consider
it
failed
and
we
can
have.
You
can
either
take
manual
action
to
remediate
by
deleting
the
machine
and
creating
a
replacement.
A
You
could
write
a
controller
that
looks
for
failed
machines
and
have
it
delete
the
failed
ones.
I
think
I
need
to
go
back
and
in
review
what's
in
here.
But
if
you
have
additional
comments,
please
take
a
look
because
I
think
this
is
something
that
we
should
try
and
get
firmly
documented
in
the
repository
as
soon
as
possible.
A
C
A
A
Right
move
to
next
enable
optional
use
of
local
kubernetes
api
connection
in
node,
ref
controller,
so
in
at
the
tail
end
of
alpha
1
and
carried
forward
into
alpha
2.
We
we
require
a
cute
config
secret
to
check
the
health
status
of
nodes
in
the
target
clusters,
and
this
is
a
request
to
allow
the
use
again
of
in
cluster
config
instead
of
trying
to
use
the
secret
and
certain
setups.
So
I
actually
was
thinking
about
this.
A
The
other
day
and
I
thought
that,
if
you're
doing
a
pivot
that
it
might
be
nice
to
have
a
speck
field
on
the
machine
that
indicates
if
it
should
be
doing
if
it
should
use
the
cube,
config
secret
or
if
it
should
try
and
do
in
cluster
config,
so
I
think
we
could
probably
I
need
to
write
this
comment
down.
But
I
think
we
could
probably
could
accommodate
this
with
a
like
field.
I
A
C
The
biggest
issue
right
now
is
that
the
way
that
the
code
works
today
is
it
basically
just
copies.
The
first
error
message
or
a
reason
that
it
encounters
into
the
parent
object
and
the
reason
why
I
filed
this
issue
is
is
over
time,
as
we
add
additional
types
of
providers
looking
at
control,
plane,
management
and
other
pieces,
we're
potentially
going
to
want
to
have
to
bubble
up
and
summarize
multiple
errors
and
different
components
got.
A
A
A
I
A
A
We
obviously
have
a
lot
of
different
providers
and
none
of
them
lived
inside
the
cluster
API
repository.
So
as
an
end
user
or
a
potential
end
user.
Would
you
want
to
come
to
the
cluster
API
documentation
and
see
examples
for
how
to
spin
up
a
WSB
sphere
as
or
Google
etc
right
from
within
those
documents?
Or
would
you
want
them
to
be
links
to
documentation
for
the
individual
providers.
C
A
Yeah
I
can
appreciate
that
I
think
what
should
be
in
the
cluster
api.
Proper
documentation
is
a
description
on
clusters
and
machines
and
the
other
core
aspects
of
the
data
model,
and
then
we
probably
should
have
links
to
the
various
provider
infrastructure
providers
for
doing
getting
started.
Setups,
Liz,
I
think.
C
A
C
D
I
think
that
I
think
that'll
get
naturally
better.
You
know
and
I'm
just
one
representing
one
provider,
but
as
we
talked
about
documentation
just
now,
you
know.
Is
more
providers
come
up
to
V
1
alpha
2?
It
would
be
you
know,
even
even
if
it's
simple,
as
here
are
the
three
places
that
you
need
to
make
sure
that
you're
using
V
2
of
this
V
1
of
this-
and
here
are
the
strings
that
you
use
like
that
was
very
much
like
having
it.