►
From YouTube: 20190925 - 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
and
welcome
today
is
Thursday
September
25th
2019.
This
is
the
weekly
cluster
API
office
hours
meeting
and
cluster
API
is
a
sub-project
of
sig
cluster
life
cycle.
If
you
are
not
familiar
with
the
meeting,
we
do
have
a
meeting
etiquette
section
at
the
top
of
our
meeting
notes.
Document
generally,
please
use
the
raise
hand
feature
of
zoom
and
I
will
do
my
best
to
make
sure
that
I
am
paying
attention,
as
as
you
do,
raise
your
hands
and
if
you
have
topics
that
you're
interested
in
discussing.
Please
add
them
to
this
document.
A
B
The
MIDI
notes
that
we
have,
and
there
are,
there
are
a
few
links
and
if
someone,
if
you
want
to
look
at
more
details,
but
the
first
thing
that
we
did
was
an
introduction
to
be
one
ounce
for
two
and
then
a
retrospective
and
I
tried
to
summarize
these,
because
there
were
a
lot
of
items,
and
these
are
kind
of
the
most
voted
once
so
one
when
well.
B
One
of
the
most
the
things
that
like
people
agreed
upon
is
that
the
foundation
v1
outfit
is
really
good
and
the
pace
of
progress
that
we
had
and
towards
the
end
of
the
release
was
astounding,
and
there
was
something
that
people
kind
of
like
give
a
lot
of
+1.
What
didn't
go
well
is
that
in
the
beginning,
we
had
a
lot
of
start
and
stop
spinning
our
wheels
and
the
products
was
really
slow,
and
this
was
mostly
who
here
was
involved
in
the
v1
a1
3
104
to
planning.
B
But
it
was
mostly
to
get
the
community
goals
and
the
scope
and
objectives
like
kind
of
like
in
writing
and
like
we
have
a
process
like
now
for
like
caps
and
feature
development,
and
another
thing
was
that
not
all
providers
were
able
to
motive.
You
went
out
for
two
at
the
same
time
and
pace,
and
this
came
up
like
kind
of
a
lot
during
the
face-to-face
which
was
we
had
like
a
festive
elements
like
a
which
kind
of
it's
one
of
the
pros
that
we
have
here.
B
What
should
we
keep
doing?
We
should
avoid
boiling
the
ocean,
and
this
is
something
that
kind
of
like
resonates
with
what
I
was
saying
before
that,
like
we
had
a
lot
of
stuff
and
stopped
in
the
last
iteration.
So
we
should
keep
this
in
mind
that
we're
working
on
alpha
releases
and
that,
like
every
one
of
us
like
wants
to
do
kind
of
like
everything
in
in
the
v1
release.
B
But
there
is
so
much
time
and
people
also
like,
like
that
we
have,
we
would
have
like
kind
of
like
open
forums,
maybe
cube
con
from
November
like
once
again
and
definitely
write
down
ideas
and
issues
and
something
that's
not
captured
here
was
to
start
also
doing
some
pocs.
So
it
folks,
like
wanna,
gives
you
something
and
present
it
like.
We
should
have
like
demos
and,
like
you
know
our
agenda,
so
that
people
can
kind
of
show
what
they
have
worked
on
for
us,
JP
I
started
doing.
B
We
should
definitely
start
and
continue
our
or
our
end-to-end
testing.
This
was
the
most
voted
issue
or,
like
actually
item
that
everybody
agreed
upon
like
I,
think
there
was
the
majority
of
people.
I
said
we
have
to
focus
a
lot
of
intent,
testing
and,
from
my
conversation
with
other
folks
as
well
like
it
was
clear
that
intent
testing
is
something
that
comes
up
a
lot
when
you
say
like
why?
Don't
you
align
class
API
and
what
will
make
it
better?
B
It's
having
like
the
signal,
they're
clustered
a
solid
and
I
enter
a
test
for
kubernetes
cluster
API
and
the
providers
are
in
place
definitely
more
emphasis
on
documentation.
We
have
some
action
items
coming
from
from
here
and
there
at
the
end
of
the
presentation,
but
documentation
is
really
lacking
today
as
well,
and
will
welcome
a
lot
of
contributors,
I'm
happy
to
onboard
new
contributors
as
well.
B
If
they
want
help
on
this,
we
for
the
first
time
in
d1
offer
we
push
the
quick
start
out,
which
was
an
improvement
when
we
had
before,
which
was
almost
sparse
documentation
in
different
infrastructure
providers
and
yeah
so
going
forward.
We
should
definitely
like
put
more
emphasis
on
this
release
more
frequently,
and
this
is
maybe
this
is
not
the
correct
wording
for
this,
but
it's
more
like
if
we
want
to
go
to
the
1
+
4
3
and
we
have
a
breaking
changes.
B
This
goes
back
on,
like
my
providers,
I
have
moved
to
be
one
of
the
two,
and
this
is
something
that
there
is
some
open
pr's
about
it
and
but
and
goes
back
to
more
emphasis
on
documentation,
which
we
kind
of
have
to
do.
A
lot
of
team
also
says
well
structured
release
processes,
and
that
goes
kind
of
in
here
and
I.
Think
Timmy
open
some
issues
yesterday
around
this
is
that
correct,
yep.
B
This
diagram
is
like
super
super
high-level
overview.
So
after
we
talk
about
the
retrospective,
it
was
clear
and
Tim
kind
of
like
a
druthers
on
the
whiteboard
and
try
to
do
a
really
nice
diagram
here
that
we
have
really
like
humane
consumers
for
class
API,
which
are
developers
from
one
side
and
operators
from
other
side
and
there's
not
just
one
over
areas
like
we
make
sure
to
say,
like
it's
plural,
because
there's
multiple
kinds
of
operators
as
well.
B
But
these
personas
kind
of
like
focus
on
different
sides
of
the
spectrum
of
what
we
have
to
improve.
For
example,
developers
want
a
better
release,
process,
onboarding
and
documentation
and
make
sure
that,
like
there
are
no
regressions
and
that
also
there
is
a
really
good
trust
in
execution,
and
this
specifically
goes
back
to
the
the
context
that
we
don't
have
and
to
the
failure
of
like
bringing
all
the
interface
providers
up
today
for
B
1
alpha
2
for
operators
like
we
kind
of
like
they
focus
on
the
usage
which
so
it's
like
more.
B
What
I
think
that
I
wanted
to
highlight
is
link
I'm,
not
gonna,
read
through
all
of
this,
but
that,
like
we
kind
of,
went
around
the
room
and
saying
like
how
everybody
was
using
cluster
API.
And
what
for
and
it's
clear
that
it's
like
a
few
teams
here,
like
there's
a
lot
of
like
folks
that
are
trying
to
deliver
coherence
service
so
like,
for
example,
measure
or
offer
clash,
API
sand
internal
solution
to
other
stakeholders.
B
So
this
is
more
like
I
mean
like
a
company
group
of
people
like
maybe
a
necessary
team
or
infrastructure
team.
Then
you
just
cluster
API
and
then
gives
it
out
to
like
other
people,
to
run
their
containers
and
manage
their
clusters.
And
then
there
is
like
a
lot
of
people
that
actually
like
mention
integrating
plus
for
API,
so
like
Gardener,
cop
Santos
and
Enterprise
PKS,
openshift
and
metal
clusters.
B
These
are
all
like
you
use
yourself
close
to
API,
but
they
have
a
slightly
different
use
case
as
in
like
it,
build
upon
plus
JP
ID
and
don't
necessarily
expose
it,
and
then
we
have
like
other
like
functions,
for
example,
build
clusters,
different
containers,
which
is
the
most
important
and
also
use
it
as
a
library.
It's
also
another
kind
of
like
pattern
that
I
have
kind
of
seen
like
in
the
in
the
notes
that
we
took
any
questions
so
far
cool.
B
He
was
do
a
really
good
job,
a
really
bad
job
at
this,
so
the
output
of
the
face
to
face
it
was
that
we're
kind
of
trying
to
get
like
some
proposals
out
and
at
the
top
of
the
document.
The
meeting
notes
that
that
we
have
there
is
kind
of
like
the
ongoing
you
wanna
four
three
proposal
and
there
is
control,
plane,
management,
cluster
upgrades
machine
pools,
the
remediation
conformance,
slash
testing
and
there
is
a
load
balancer
either,
which
I
believe
you
might
actually
go
out
of.
B
It
might
not
be
a
proposal,
but
I
think
Moshe
can
speak
to
that.
Even
more,
then
there
is
action
item
/
issues,
one
of
it,
which
is
to
move
the
cube
idiom
in
Dhaka,
provided
I'm,
free
and
I
have
a
like
an
item
on
the
agenda
to
talk
about
this
with
you
on
the
community,
and
this
is
mostly
focused
to
kind
of
improve
the
user
experience
but
also
allow
better
end-to-end
testing.
B
C
There
was
one
thing
that
was
missing
that
we
talked
about
that
was
to
upgrade,
and
we
there's
a
constraint
here
to
upgrade
to
the
latest
version
of
pou
builder.
It
wasn't
necessarily
recorded
in
the
notes
here:
we've
recorded
it
separately,
the
updated.
The
latest
version
could
lurk
a
C
or
DS
with
the
GA
and
there's
certain
feature
enablement.
The
constraint
is
that
for
one
for
B
went
off
of
three
we'd
pin
deployment
of
clusters
at
116
plus
then,
as
a
result,
yeah.
B
So
I
keep
talking
so
Chuck
open
an
issue
of
few
weeks
ago
at
the
leaf
to
bring
cap
the
incubation
provider
entry.
It
has
like
a
lot
of
context,
I'll
link
it
or
the
document.
So
the
reason
for
this
is
it
and
that
I
want
to
bring
this
up
is
because
there
is
a
lot
of
kind
of
worried
there.
B
Like
the
user
experience,
they
it's
not
the
greatest
which
is
not,
and
that
again,
like
the
entry,
investing
it's
kind
of
like
the
number
one
issue
that
everybody
agreed
upon,
that
we
have
like
a
little
coverage
so
bringing
these
doing
in
providers
entry
like
kind
of
favors,
for
the
cube
idiom
user
experience
and
for
the
doctor
provider.
It
will
allow
us
to
actually
test
this
in
CI
as
a
unit.
B
So
when
we
make
breaking
changes,
we
will
like
be
able
to
kind
of
like
get
all
the
latest
changes
that
we
have
for
a
release
and
kick
off
a
CI
job
and
test
all
of
these
three
providers,
as
as,
like
one
deployment
of
cluster
API,
and
it
will
also
set
expectations
and
I
believe
up
ad
in
the
document.
There
is
also
a
proposal
like
how
to
write
like
a
testing
framework
which
also
Chuck
is
working
on,
and
my
question
for
the
community
here
is
like:
are
there
any
is
there?
Are
we
worried
about
that?
A
B
D
In
like
I,
probably
have
the
person
that
was
I'm
most
likely
to
object
to
this
because
of
you
know
like
we
shouldn't
bring
your
a
DM
and
make
it
bless
it
in
any
way.
However,
I
think
that
that
is
outweighed
by
the
fact
that,
like
having
good
test
coverage
of
some
scenario
is,
is
very
important,
and
the
value
of
this
is
it
doesn't
have
external
or
significant
external
dependencies,
like
doesn't
end
on
a
cloud
provider.
So,
despite
what
people
might
believe,
I
am
actually
in
favor
of
this.
B
Thanks,
Justin
and-
and
yes,
there
like
I,
would
add
there
like
it's.
It's
not
that
just
we
want
to
move
code
around
it's
mostly
to
solve,
like
this
holistic
issue
of
like
and
end
this
thing,
but
also
we
will
make
sure
they're
like
along
this
process.
We
don't
break
the
conscious
that
we
made
if
you
ask
for
two
for
bootstrap
providers,
so
that,
if
there
are
external
force
to
provide
errs
today,
we'll
make
sure
that
that's
that
those
contracts
as
well
going
forward.
D
Have
I
am
supposed
to
look
at
this?
I
have
not
yet
looked
at
it
in
detail.
I
am
I,
I
will
endeavor
to
do
somebody
yeah.
We
should
probably
wait
for
Lee
to
talk
about
this.
It
might
be
one
that
we
actually
talk
about
more
in
the
cluster
API
general
meeting,
but
it's
it's
about
how
we
integrate
atoms
with
kuba
diem
I.
Think
he's
thinking
about
whether
there
are
any
particular
implications
for
cluster
API
I
can't
imagine.
There
are
predictor.
D
Yeah
I
think
the
only
the
most
likely
implication
would
be
like
sort
of
the
thing
we
discussed
about,
like
a
bundle
of
yeah
mole
files
or
a
bundle
of
llaman
objects
that
may
be
getting
bigger
and
how
we
feel
about
that.
Whether
we,
like
my
personal
view,
is
like
that's,
not
a
problem.
I
know,
I'll,
get
disagree
and
I.
Think
that's
great
I,
just
hate,
that's
I,
just
hate,
you
know.
That's
all
I.
E
Awesome,
hey
everyone,
so
I
wanted
to
talk
about
cluster
upgrades,
and
so
in
film
we
tried
to
get
names
to
figure
out
who
is
interested
in
working
on
cluster
upgrades
for
specifically
targeting
v1
and
alpha
3,
and
so
I
figured
I,
make
sure
to
mention
everyone
here.
So
the
folks
working
on
it
will
be
through
toy
from
New
Relic,
Matt
Dennison
from
New
Relic
nadir
and
then
myself,
if
you're
interested
in
working
on
this
problem
space,
definitely
tack
your
name
down
under
that
bullet
point
and
we
can
go
from
there.
So
I
created
a
survey.
E
E
Okay,
I'll
do
this
demo
in
a
second,
but
so
we'll
have
questions
like
you
know,
describe
what
contacts
you're
upgrading
our
clusters,
so
this
covered,
like
you,
know
whether
or
not
you're
in
infrastructure
as
a
service
product
conducting
cluster
upgrades
on
a
fleet
of
clusters.
If
you're
developer,
like
I'd
love
for
you
to
go
into
more
detail
about
like
what
you're
using
cluster
upgrades
for
and
in
which
context
architectural
diagrams
are
super
useful,
obviously
like
don't
release
any
proprietary
information,
but
if
but
anything,
you're
able
to
sort
of
like
anonymize.
E
If
you
are
updating
clusters
to
clusters
today
without
cluster
VP
and
like
I'd
love
to
understand
how
you're
doing
that
today
and
again,
if
you
are
doing
this,
let
me
know
what
pain
points
you
you're
experiencing,
and
this
is
this
first
section
is
the
wanted
to
this
is
like
without
cluster
or
API
in
the
context,
and
the
second
thing
is
more
detail
and
like
what
you're
expecting
out
of
a
solution
and
not
only
what
you're
expecting
but
like
why
you're
expecting
it.
So
what
I
mean
by?
E
Certain
upgrade
solution.
Look
like
definitely
fill
this
house
because
it's
it's
hard
to
understand
what
folks
want
and
why
they
want
it
without
it
without
more
information.
So
hope
you
fill
that
out
when,
when
it
comes
to
your
inbox,
let's
see
what
else
today,
okay,
so
I
was
working
on
updating
the
like
this
proof-of-concept
cluster,
a
great
tool
with
that
we
have
two
target:
B
1,
alpha
2
cluster
API
clusters.
I
didn't
pull
out
that
repo,
but
I
can
do
that
now.
E
E
E
E
E
So
here
you
can
see
that
the
state
for
this
old
control,
plane
machine
is
deleting,
and
this
is
actually
the
new
control
plane
machine
and,
if
I
restart
this,
what
you
can
see
for
this
status
is
that
this
instance
state
is
shutting
down.
I
won't
make
you
all
wait
for
this
machine
to
actually
shut
down.
But
what
happens
is
is
after
this
control
playing
machine
shuts
down,
then
the
controller
will
go
ahead
and
delete
this
presentation
of
that
node
and
then
later
on.
A
F
F
So,
let's,
let's
do
that
one
offline
in
an
asynchronous
manner
and
then
I've
got
the
next
item
so
I'll
just
keep
going
and
go.
I
would
like
to
add
one
of
the
of
the
reviewers
to
promote
a
maintainer
and
this
sort
of
gets
into
a
larger
topic
that
we
discussed
at
the
face-to-face,
which
is
sort
of
automating.
The
process
of
promoting
people
through
the
various
kubernetes
approval,
reviewer,
statuses
and
I.
F
Think
that's
something
that
I
also
need
to
do
for
the
project
in
general,
cab,
PK
and
also
the
project
cap
D,
but
there
is
one
particular
reviewer
that
that
I
would
like
to
promote
to
and
maintainer
so
I'll
open
a
PR
and
do
the
standard
one
wait
time
out.
If
anybody
has
any
comments
on
that,
please
feel
free
to
comment
on
the
PR.
It
is
not
open
yet,
but
I
will
add
it
to
this.
The
notes
here,
a
lot
of
link
to
the
notes
here.
One
by
opens.
A
Thanks
Chuck
just
echo,
we
will
be
doing
similar
PRS
for
promotions
for
cluster
API
and
Kappa
as
well,
and
this
is
something
that
we
do
want
to
be
doing
at
regular
intervals.
Essentially,
whenever
we
finish
it
release
and
start
a
new
one,
we'd
like
to
review
the
owners
files
and
make
sure
that
we
are
promoting
people
who
are
actively
involved
and
then,
if
there's
people
who
have
stepped
away
for
whatever
reason
we're
moving
them
until
they
have
a
chance
to
come
back
in
the
future.
A
The
next
one-
so
we
mentioned
this
very
briefly
at
the
beginning-
I-
have
filed
an
issue
as
a
result
of
the
discussions
from
last
week.
It's
a
face-to-face
to
propose
that
we
upgrade
to
v1
of
custom
resource
definitions,
which
has
the
side
effect
that
it
will
require
kubernetes,
116
or
newer
for
the
management
clusters.
This
is
not
for
the
workload
cluster,
just
a
mammoth
management
clusters.
G
Hi
yeah
I
do
mind.
Tools
is
in
the
middle
of
moving
to
a
hybrid
cloud
approach
with
kubernetes
right
now,
we're
deploying
things
on
prem,
with
ansible
and
in
the
cloud
with
terraform
and
want
to
move
to
a
more
kubernetes
as
a
platform
for
our
platform
approach
so
and
looking
at
the
stuff
that
we
need
to
build
to.
Do
that.
G
A
lot
there's
a
lot
of
overlap
between
the
types
of
CR,
DS
and
operators
that
we
are
specking
out
with
cluster
a
and
actually
there's
a
lot
of
tools
that
cover
parts
of
our
use
cases,
but
not
everything.
So
that's
kind
of
a
common
theme-
and
you
know
our
hope,
really
is
to
adopt
what
we
can.
That
will
be
around
long
term
that
that
meets
our
needs
and
build.
G
That
clusters
provide
to
the
application
developer,
because
there's
like
this
unfortunate
loose
coupling
between
I
need
a
run
in
a
kubernetes
cluster
that
offers
nodes
that
have
GPUs
on
them.
But
I
don't
want
to
actually
write
the
terraform
to
provision
nodes
and
do
all
this
stuff
so
really
enabling
us
to
approach
our
clusters
as
sets
of
resources
that
offer
specific
services
or
that
you
could
request
those
things
to
be
added
at
a
conceptual
layer
as
a
developer,
from
a
pool
of
things
defined
by
our
operations
team.
B
G
We
kind
of
come
at
everything,
with
the
approach
of
like
three
layers
of
application
platform
and
infrastructure
and
having
all
of
those
things
be
loosely
coupled
together,
so
that
model
doesn't
always
fit
with
every
tool.
We
want
to
use
so
trying
to
figure
out
how
to
how
does
this
fit
into
a
larger
space
of
being
able
to
integrate
with
a
whole
bunch
of
other
things,
as
one
of
the
things
that
were
we're
working
on
too
so
I
think
that's
that's
our
story.
B
Like
kind
of
on
the
side,
there
has
been
a
lot
of
things
that
broke
cup
G
like
because
we
didn't
have
like
good
enough
like
just
like
testing
coverage,
so
we're
working
on
that
and
then
this
end-to-end
testing
for
cap
G
for
kept
see
I
I've
been
working
with
CCO
like
a
lot
and
in
the
past
few
weeks
and
Steven
Augustus
to
bring
cap
C
2
V
1,
alpha
2.
She
made
really
good
progress
and
we
kind
of
like
stumble
upon
the
next
issue,
which
is
going
to
be
image
building
so
I.
B
H
So
yeah,
so,
in
addition
on
the
cap
seaside
we're
adding
a
we're
adding
a
meeting.
Finally,
so
the
meeting
will
be
the
week
of
I
want
to
say:
October
7th,
so
I'll
send
out
I'll
send
out
a
doodle
to
the
cluster
lifecycle
group.
If
people
are
interested
in
joining
that
meeting,
we're
we've
also
wired
up
some
of
the
stuff.
That's
required
to
do.
Do
automatic
image
fishing
for
the
cap,
C
repo,
so
we're
starting
to
to
get
closer
to
to
the
the
kappa
space
and
they
and
the
rest
of
the
providers.
So
thank
you
again.
A
C
We're
gonna
be
probably
have
to
go
through
not
today,
but
I
may
be
going
through
with
a
fine-tooth
comb,
a
bunch
of
issues
in
the
backlog
to
try
and
figure
out
where
they
fit,
especially
given
that
we're
gonna
have
other
people
spinning
online
and
whether
or
not
we
should
remove
them
so
they're
sending
in
bad
ones,
obviously,
but
that
we
should
triage
but
just
a
PSA
and
that
we're
going
to
we're
gonna.
Take
a
wrecking
ball
to
a
lot
of
issues.
So
do.
A
C
But
my
plan
is
to
a
lot
of
the
replies
to
go
through
a
lot
of
the
old
issues
and
items
that
we've
kind
of
had
hanging
out
forever,
and
you
know,
Vince
has
been
booking
me
and
I've
been
poking
Andy
and
I'm
starting
to
go
through
things
in
more
detail
that
we
should
probably
close
out
a
bunch
of
these
legacy
issues
that
you
currently
have
so
that
waiver
me.
Would
he
go
to
be
one
out
of
three?
We
have
a
concrete
backlog
and
burned
down
this.
A
Makes
sense
to
me
all
right,
so
we
have
let
me
just
refresh
to
make
sure
there's
nothing
new
to
on
milestone
cluster
API
issues.
First,
one
is,
please
add
a
version
command
for
cluster
cuddle.
I
totally
agree
with
this,
unless
we
actually
get
rid
of
it.
I
think
we're
talking
about
doing
so.
Tim
I'm
going
to
defer
to
you
on
this
one
in
terms
of
priority
and
milestone
same.
C
C
C
A
A
A
F
A
A
H
A
Thank
You,
Steven
and
yeah
up
at
the
towards
the
top
of
the
document.
We
do
have
the
ongoing
view
and
alpha
3
cups-
kappa
if
you
are
not
familiar,
stands
for
cluster
api
enhancement
proposal
and
we
have
machine
pool
cluster
upgrade
orchestration
with
the
survey
TVD.
As
we
mentioned,
there
will
also
be
a
proposal
DVD
and
then
a
couple
other
items
here
as
well
on
testing
and
control
plan
management.
A
C
C
Yeah
I,
just
actually
monaural
said
that
but
yeah
well
we're
good
to
set
them
out
for
that.
So
if
there
are
things
that
you're
interested
in
as
a
as
a
consumer
or
company
or
whatnot,
and
you
are
willing
to
resource
and
work
on
it,
this
list
is
not
necessarily
set
in
stone.
Please
write
a
proposal
or
open
an
issue
start
to
talk
about
it
and
as
community
we
can,
we
can
weigh
the
ability
to
get
it
done
within
the
p1l
through
timeframe.