►
From YouTube: 2020-03-04 - 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
A
A
A
All
right,
let's
proceed
with
the
PSAs,
so
we
have
QP
essays
the
first
one
rc3
is
dropping
today,
probably
this
around
this
afternoon,
and
we
have
a
few
more
PRS
ongoing
and
if
you
have
anything
that
you
would
like
to
get
merch
feel
free
to
reach
out
like
we'll
try
to
make
that
happen.
The
gods,
your
rubies,
your
4
V
1
for
3,
it's
still
probably
happening
on
March
10th,
which
is
in
six
days.
A
C
C
Okay,
awesome
so
yeah
we
are
introducing
support
for
the
class
API
provided
for
the
class
notice
came
up
so
I
just
wanted
to
demo
that
quickly
today,
I
went
through
the
quickest
are
for
the
cluster
API,
so
I
got
a
class.
The
API
complains
class
they're
up
and
running.
So
we
can
see
here.
C
C
C
See
those
spots
being
created
because
there's
now,
if
not
enough
capacity,
we
see
that
the
autoscaler
already
triggered
a
scale
out.
So
it's.
C
I'm
getting
the
replica
number
for
the
Machine
Diploma
here
and
we
see
that
it
went
from
one
to
six,
so
you
should
be
able
to
see
all
those
machines
being
here
now
so
that's
happening
already
so
usually
been
free.
These
machines
would
become
nodes
in
the
cluster,
but
to
keep
it
sharp
I'll
just
go
around
and
you
need
the
workload.
So
we
can
see
the
autoscaler
cheating
the
scale
down.
C
C
C
C
D
E
C
Definitely
so
we
got
a
a
PR
in
place
that
it
was
there
for
a
while
we'd
recently
revived
the
the
forum
that
PR
and
we'll
be
discussing
here.
It's
in
the
cluster
API
community
I'm
also
with
the
cluster
autoscaler
community,
and
we
got
agreement
and
consensus
that
we
want
to
move
forward
with
that
PR.
So
the
next
steps
are
for
Philip,
basically
approval
from
the
autoscaler
side
of
things,
and
we
now
need
a
final
look
good
to
me
and
a
PR
from
the
cluster
API
side
of
things
so
yeah
it's
already.
C
He
already
share
some
feedback
there.
Hopefully
that
would
be
maps
like
this.
So
once
that
happens,
we'll
have
like
the
main
goal
now
is
to
have
something
like
one
common
place
for
everyone
who
is
interested
in
this
can
collaborate
and
we
can
work
together
so
after
habitat
mouse,
we
will
proceed
like
really
quick
with
follow
ups,
to
make
it
better.
A
C
So
come
on
in
the
PR
we
have
a
hard
coded
version
for
fewer
B
1
alpha
2,
but
that's
like
we
already
digested
up
some
feedback
on
there
and
once
we
got
in
math,
we
probably
put
a
follow
up
to
use
discovery
client.
So,
instead
of
having
the
version
hardcore
bit,
they
provided
us
should
be
able
to
find
the
latest
version
attainable
and
we'll
just
use
that
well.
A
C
B
E
F
Exactly
that's
why,
when
I
provided
feedback
on
the
PR,
I
didn't
consider
kind
of
the
hard
coding?
If
you
want
alpha
2
to
be
an
immediate
blocker,
but
rather
something
that
we
want
to
address
for
future
versions
and
I,
provided
some
other
feedback
too.
On
places
where
I
think
we
can
streamline
the
integration
to
avoid
potential
skew
between
at
least
foreseeable
versions
of
cluster
API
and
make
that
more
seamless.
G
Yeah,
so
this
is
kind
of
a
follow
up
to
the
demo
that
Alberto
just
gave
I
want
to
say.
Yesterday
we
had
we
had
kind
of
a
an
ad
hoc
meeting.
We
kind
of
started
to
organize
this
last
week,
but
mainly
talking
about
this
Auto
scale,
integration,
effort
and
I
think
Albert
are
kind
of
covered
most
of
what's
going
on
here.
G
You
know
we
have
good
consensus
from
the
upstream
autoscaler
community
there
just
kind
of
go
over
a
few
details
on
the
PR
we
put
up
there,
that's
linked
in
the
doc
here,
and
then
you
know
if
you
scroll
down
past
today's
meeting
in
the
notes
you
see,
we
took
some
notes
from
this
meeting:
I'm
not
going
to
go
through
the
whole
thing
we
brought
up.
You
know
a
bunch
of
the
issues
we
were
looking
at
in
terms
of
I
think
the
work
that
needs
to
be
done
with
autoscaler
and
then
kind
of
at
the
bottom.
G
We
had
some
action
items
for
things
that
we'd
like
to
do
next.
You
know
just
mainly
around
some
documentation.
It
needs
to
be
done
so
cleanup.
That
needs
to
be
done.
You
know
like,
like
was
noted.
The
hard
coding
of
the
API
types
you
know
there
are.
There
are
definitely
some
cleanups
that
should
happen
in
this
PR
after
it
goes
in
I.
G
Think
right
now
we're
trying
to
get
it
to
the
point
where
it's
good
enough
to
accept,
and
then
we
can
go
back
and
start
to
do
some
of
these
more
aggressive,
cleanups
and
I
guess
you
know
I.
Think
Alberto
did
a
great
job
of
covering
everything
really
I
see.
You
know,
I.
Think
Michael
wanted
to
talk
a
little
more
about
one
of
the
UX
issues
here.
So
I
don't
really
have
much
more
to
add,
but
I
will
kind
of
pass
it
over
to
Mike.
For
that.
H
Okay,
this
is
just
the
action
item
had
from
the
meeting.
So
basically
the
upstream
autoscaler
has
what
we
call
scale
from
zero,
so
you
can
show
it
hey.
I
want
to
scale
this
thing:
I
don't
have
any
nodes
in
it
yet,
but
whenever
it's
appropriate
go
ahead
and
scale,
it
does
that
because
it
makes
it
like
the
CPU
Ram
GPU
information
into
the
autoscaler
code
for
each
supported
cloud
provider.
So
it.
H
H
And
that's
how
it
determines
how
much
oriented
everything
it
has.
So
if
you
have
0
of
them,
it
doesn't
know
how
much
it
has.
So,
let's
figure
out
how
to
scale
from
0
knowledge
go
it's
a
pretty
common
feature.
Everybody's,
like
yeah
I,
want
to
scale
this
down
to
zero
overnight.
So
I,
don't
waste
money,
the
nollans
killer
doesn't
sleep
whatever,
so
there's
a
multitude
of
different
ways.
H
We
can
accomplish
this,
there's
probably
more
ways
than
what
I
mentioned
in
proposal
pull
request
the
key
takeaways
we
had
from
that
week,
where
we're
gonna
need
to
come
up
with
something
that's
going
to
pass.
Api
review
so
annotations
by
themselves
might
fly,
and
we
also
need
to
come
up
with
something
that
auto-scaling
people
are
going
to
want
to
agree
to
so
I
put
out
some
ideas
to
get
the
conversation
started:
I'm
not
too
attached
to
any
particular
idea,
but
I
think
they
all
would
work
from
a
technical
sense,
so
food
to
just
everybody.
H
I
H
E
H
So
here
the
autoscaler
right
once
you
have
a
machine,
it's
too
late,
cuz
that
machine's
already
there
so
the
but
the
autoscaler
needs
to
know
is
the
machine
set
level.
So
it's
kind
of
a
similar
idea,
but
instead
of
information
falling
from
the
provider
machine
to
machine
object
or
going
from
some
new
provider
controller
to
machine
soda
machine
appointment
or
dealing
both
of
those
places.
A
A
A
There
was
a
lot
of
back-and-forth
on
this
and
I
think
this
is
actually
a
good
place
to
start
like
if
you're
gonna
start
putting
your
thoughts
together
or
like
provide
feedback
on
like
what
this
proposal
like
inhales
I,
don't
know
if
one
needs
on
the
call,
but
they
also
expressed
interest
in
working
on
this.
Oh
yeah,
this,
like
in
general,
like
right
now
that
we
were
ending
up
the
0-3
cycle
so
like
it
is
actually
I
got
really
good
time
to
start
working.
A
proposal
for
the
next
cycle.
A
K
A
And
the
best
we
have
like
a
few
different
ways
to
go
about
this,
so
the
first
step
was
I
could
definitely
open
an
issue
and
I'm
sort
of
discussing
on
it.
If
there
is
enough
consensus
like
we
usually
move
to
a
Google,
Doc
first
and
then
to
a
PR
in
in
this
case
like
if
the
PR
is
already
up
so
I
would
suggest
like
to
keep
working
on
that
under
PR.
If,
if
you
feel
like
it,
there
like
a
might
be
better
to
move,
Google
Doc
or
like
in
another
place
feel
free
to
do
so.
A
K
A
A
Before
I
go
into
the
backlog,
grooming
I
think
we
actually
only
have
one
issue
open
that
needs
triage
and
that's
the
cluster
scalar
one.
Is
there
any
other
discussion
topic
on
things
that
people
want
to
talk
about?
I.
B
Would
raise
my
hand
except
I
can't
since
I'm
the
host
I
think
a
good
follow
up
on
James's
question
about
manage
clusters
and
what
you
were
just
saying.
Events
about
wrapping
up
zero
three
is
that
now
is
the
time
or
very
shortly
will
be
the
time
to
start
solidifying.
What
we
want
to
do
in
our
next
release.
We
do
have
a
roadmap
document
that
is
published
and
dense
is
gonna,
pull
it
up
here.
So
if
there's
stuff,
that's
in
the
roadmap
that
you
want
to
work
on
or
that
you're
interested
in,
please
take
a
look.
B
If
there's
stuff,
that's
not
in
the
roadmap.
This
is
a
draft
or
constantly
evolving,
at
least
so
there
may
be
github
issues
that
have
been
filed,
or
maybe
you've
got
stuff
in
your
head
that
you
haven't
filed,
yet
that
could
be
appropriate
for
our
next
release.
So
I
would
encourage
everybody
to
think
about
this
and
if
you've
got
proposals
or
ideas
that
you
haven't
filed.
A
All
right
so
in
terms
of
issues
there's
only
the
closer
autoscaler
from
zero
with
issues
with
the
master.
If
we
I
think
this
one,
we
could
probably
move
it
to
next
for
now,
Oh
like
set
it
next
to
them,
see
at
the
next
kind
of
grooming
backlog.
What
does
this
fit?
A
I'm
gonna
be
0
for
at
this
point
in
terms
of
rc3,
there
is
only
this
issue:
that's
open
machine
pool
to
experimental
and
the
there's
a
PR
up
already
for
this,
so
I
I
think
this
can
be
closed
soon
after
the
PR
has
emerged,
as
I
mentioned.
The
RC
will
happen
today.
If,
like
there
is
any
other
changes
that
we
wish
you
make.
Let's
try
to
make
that
happen.
For
the
end
of
the
day,.