►
From YouTube: 20190508 - 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
to
the
Wednesday
May
edition
of
the
cluster
API
office
hours,
a
sub-project
of
state
cluster
lifecycle.
We
have
a
relatively
short
agenda
today,
so,
if
there's
anything,
you
want
to
cover,
go
ahead
and
add
it
into
the
agenda
document.
Let
me
go
ahead
and
post
that
in
the
chat
and
also
go
ahead
and
add
yourself
to
the
attending
list.
To
start
off
with
today
looks
like
it's.
You
Justin
with
the
cluster
API
accounts.
Yes,.
B
Sorry,
Coppola
money,
I
preempted
you
because
I
thought
this
should
be
very
quick.
It's
basically
a
heads
up
that
for
cluster
API
provider,
AWS
testing
we've
discovered
that
that
janitor
is
well
be.
There
are
twenty
Kappa
plus
two
api
provider
accounts
because
whoever
davidÃs
accounts
they
were
supposed
to
be
in
different
AWS,
but
there
are
twenty
logins.
They
were
supposed
to
be
in
sub
accounts
different
accounts
so
that
they
would
see
different
objects.
B
They
are
all
in
the
same
account,
so
basically
that
janitor
is
going
in
and
deleting
things
which
it
shouldn't
do
because
it
assumed
they
were
in
different
accounts.
It's
deleting
things
way
too
fast.
It's
affecting
cost
jobs
and
so
affecting
any
other.
A
diverse
job
in
it
is
also
in
theory
affecting
Kappa
Kappa
so
like.
If
you
run
to
capitis,
that's
it
for
too
quickly
that
would
interfere.
We
are
likely.
The
short-term
thing
is
that
we
will
probably
turn
off
the
janitor
I
guess
the
sweeper
so
that
it
the
boscoe's
janitor.
B
So
you
will,
we
have
a
sec.
We
have
a
fullback
janitor
that
runs
every
two
hours
and
you
will
like
to
see
our
resources.
That's
that
get
cleaned
up
only
after
two
hours,
if
you
meet
them
so
Jason
I
think
you
had
some
ideas
on
the
consequences
and
then
longer
term.
We
will
set
up
the
cap
accounts
in
separate.
B
We
have
a
logins
in
separate
of
us
accounts,
but
if
you
see
that's
a
proposed
plan
of
action
as
of
20
minutes
ago,
and
if
you
see
weirdness
that
could
be
well,
you
should
already
be
seeing
rip
ness
and
if
you
see
ongoing
weirdness
with
resources
continuing
to
exist
when
you
weren't
expecting
to
do.
That
would
be
why
so.
B
B
We
could
absolutely
say
all
the
periodic
sigh
think
it
would
suffice
to
just
disable
them
so
boss
cos.
Is
this
thing
which
Elise
is
one
of
those
accounts
for
the
duration
of
a
job?
And
after
that
job
is
returned.
It
goes
and
eats
everything
in
that
account
right.
The
problem
is
that
account
is
everything
in
all
of
e2e.
We
if
we
just
turn
off
the
cleanup
there,
anything
that
is
leaked,
always
he
still
be
there.
Next
time
we
have
the
sex
for
the
secondary
fullback,
we'll
come
in
and
get
it
in
a
couple
of
hours.
B
B
Management
issue
to
be
resolved
exactly
so
tight.
Today
it
is
a
CN
CF,
CN
CF
pays
for
it.
That's
not
gonna
change,
possibly
with
credits,
but
CN
CF
is
responsible
for
the
money
side
of
things.
They
are
also
coming
responsible
for
the
administration
of
those
logins
I.
Think
I
got
it
right.
This
time
we
can
take
over
the
administration
of
the
logins
and
generally
of
the
accounts
in
working
group,
kate's
infra,
but
it's
a
date.
We
have
not
had
that
and
it's
had
to
go
through
the
people
who
paid
a
bill
got.
A
Yeah,
so
I
I
don't
think
we
necessarily
need
to
worry
about
disabling
the
jobs
now,
but
potentially
because
I
don't
think
we're
doing
anything
special
for
naming
per
run.
We
may
end
up
getting
conflicts
if
multiple
jobs
run
at
the
same
time
and
we
may
end
up
with
some
weirdness
there.
So
if
we
do
see
that
then
we'll
just
go
ahead
and
we
can
disable
the
periodic
sand,
the
post
submits
for
the
AWS
provider
until
we
can
get
the
AWS
account
sorted
out.
B
B
B
A
D
So
trade,
the
corner
just
a
little
bit
easier
yeah
so
like
they
have
been
some
like
a
few
issues
like
because
the
zero-one-zero
release
of
copies
like
very
old
and
there's
like
a
few
bug
fixes,
especially
because
machine
deployment
is
broken.
They
were
too
far
back,
you
know
being
out
of
date
and
there
have
been
also
like
a
few
other
fixes.
B
E
E
This
is
mostly
that
at
some
point
in
the
conversation
in
the
data
model,
an
order
in
the
other
side
in
the
attention
mechanisms
seem
that
there
are
kind
of
assumption
that
the
workgroup
is
eesti
mechanisms,
but
actually
there
may
also
be
a
possibility
of
using
a
controller
base
station
mechanics
and
actually
the
the
bodies
are
used
to
be
careful.
I
mean
we
all
that.
E
Probably
there
is
a
slight
bias
to
thinking
that,
as
the
stench
mechanism
is
what
who
tried
to
fit
the
data
model
to
the
use
case
and
even
is
use
probably
very
likely,
the
wick
hook.
The
station
mechanic
will
be
probably
the
one
that
will
move
forward
because
they
wanna
be
more
developed
right
now,
just
to
be
careful
not
preventing
that
the
essential
mechanisms
baseball.
E
E
Means
that
as
much
as
possible,
they
could
provide
their
specific
information,
should
be
external
objects.
Reference
from
from
the
closer
API
objects,
instead
of
try
to
embed
it
stuff
for
the
provider
does
something
that
it's
already
new
mobile,
but
just
a
minor
worries.
Just
because
so
comments
is
like
you
written
between
mine
Satan,
it's
true
that
you're,
assuming
that
is
the
session
making.
But
but
if
not,
is
that's
only
not
I
I.
F
D
So,
even
that,
if
that's
true,
that's
where
I
just
presented
like
a
few
minutes
ago,
I
would
say
like
presenting
something
like
making
like
the
community
aware
of
like
what
we're
working
on
it.
It's
not
necessarily
a
bad
thing.
We're
not
trying
to
impose
things
on
the
community,
as
I
mentioned,
like
everything,
is
a
work
in
progress
right
now
and
we'll
reconvene
on
the
data
model,
extension
mechanism
and
all
the
other
levels
that
are
gonna
come
in
once
we
have
a
better
idea
on
what
we
desire
as
a
community.
D
A
I
think
something
that's
is
probably
important
to
point
out
here-
is
that
everything
that's
being
done
within
the
work
streams
today
is
all
leading
towards
proposals
that
will
be
brought
up
in
this
common
meeting
will
be
sent
out
to
the
entire
state
cluster
life
cycle
group
and
will
have
to
gain
consensus
from
the
community
before
those
proposals
are
actually
merged.
So
none
of
the
work
being
done
is
pretty
determinant
of,
what's
going
to
be
accepted
of
you
know
from
the
project
as
a
whole.
At
this
point.
G
It's
also
important
to
note
that
everyone's
going
to
make
mistakes.
This
is
V
1,
alpha,
2
and
we're
going
to
iterate.
So
if
we
make
a
mistake,
find
a
better
way
to
approach
things
at
a
alpha,
3
or
beta
1,
we
can
always
make
changes,
but
I
don't
think
we
should
also
I
think
we
should
also
be
careful
and
mindful
not
to
get
into
analysis
paralysis
either
right
at
this
project.
This
sub
project,
in
particular,
has
suffered
from
that
from
a
community
standpoint.
E
E
My
only
point
is
that
make
clear
to
all
that
this
is
not
either-or
at
the
end
should
only
be
one
mechanisms
that
as
much
as
possible,
we
should
support
both
of
them
and
even
if
the
reference
permutations
basic
work,
oops,
probably
some
providers
wants
to
implement
something
in
a
different
way.
It's
just
that's
why
I
think
that
this
is
more
like
a
data
model
related
issue
because
they
in
the
indie
web
in
the
extension
mechanism,
we
we
can
agree.
E
Oh
you
see
on
following
the
movie
workbook
and
that
that's
fine,
but
the
data
model
is
not
assuming
that
this
is
the
only
one
it
shows
up.
It's
fine.
The
reference
permutation
from
an
extension
is
based
on
well,
but
the
data
model
should
be
as
much
as
possible
support
both,
but
that
that's
what
I
think
is
is
it's.
A
notice
is
being
paralyzed
by
analysis
just
moving
forward,
but
just
keeping
in
mind
that
that
who
shows
up
or
both.
H
I
think,
like
the
concrete
request
that
that
Pablo
is
talking
about,
is
so
for
for
webhooks,
the
types
are
not
necessarily
CR
DS,
but
for
controllers
I
think
they
must
be
CR
DS.
So
if,
if
if
we
want
to
support
both,
even
if
we
do
the
webhook
as
the
reference
implementation,
perhaps
we
can
consider
you
know
defining
the
CR
DS,
but
the
webhook
implementation
obviously
won't
won't
use
them
as
such,
but
they'll
exist
and
there
will
be
they'll
be
available
for
for
controllers.
I
Everyone's
concerned
about
like
why
I
see
our
future
decisions,
these
are
not
there's
reason
to
believe
there's
reasonably.
We
should
be
concerned
about
like
assuming
the
goal
right.
That
said,
we're
also
talking
about
introducing
an
additional
controllers
so
like
a
full
plane,
could
be
an
additional
controller.
We're
not
saying
that
all
extension
mechanisms
are
votes,
so
so
I
don't
know.
I
feel
like
the
whole
discussion
about
what
books
is
a
little
bit
premature,
I'm,
not
sure
what
comp
reaction
we
want
to
get
out
of
it.
J
So
one
thing
that
potentially
could
be
useful
would
be
to
remove
any
references
in
the
data
bottle
that
are
in
there
right
now
about
extension,
configuration
and
things
that
assume
what
looks
or
to
your
PC.
For
that
matter
we
could
put
them
in
a
separate
spitballing
section
if
we
wanted
to
have
it,
but
you
know
I
will
echo
Jason
and
Vince
and
Tim.
This
is
not
meant
to
be
prescriptive
and
set
in
stone.
J
J
K
Think
the
other
concern
that
I
had
around.
That
is
not
just
the
configuration
stuff
which
makes
sense,
but
the
idea
that
that
would
be
the
reference
implementation
and,
if
the
point
of
redoing
a
lot
of
this
work,
is
to
be
able
to
share
more
code
between
implementations,
anything
that
relies
on
having
a
reference
implementation
with
a
particular
calling
pattern.
You
know
webhooks
rgr,
PC
or
whatever
is
going
to
end
up
being
something
that
can't
be
shared.
K
So,
if
I
would
have
to
build
a
REST
API
of
some
sort
in
order
to
integrate
with
the
new
version
of
cluster
API
provider,
then
I
mean
that
that's
all
extra
work
that
I
would
have
to
do
because
I
wouldn't
want
to
have
to
re-implement
the
whole
thing
or
fork
it
and
remove
all
the
webhook
calls
and
replace
them
with
something
else.
So
if
there's
some
way
to
consider
a
reference
implementation
that
is
not
assumed
to
be
based
on
calling
out
to
some
other
service,
then
I
think
that
would
be
I.
G
Think
I
think
there's
a
way
to,
depending
upon
your
requirements,
I
think
there's
a
way
to
have
your
cake
and
eat
it
too.
The
whole
system
is
based
upon
watches
and
watch
notification
event
hook.
Mechanism
is
a
way
for
you
to
get
that
same
signal
in
cluster
that
went
without
you
having
to
you
have
yet
another
CR
D.
So
I
think
this
should
be
part
of
the
proposals
for
the
extension
mechanisms
that
allow
that
to
take
into
account
in
that
particular
use
case
scenario.
G
But
again
it
should
all
be
all
about
user
stories
all
right,
so
the
caps
that
come
up
if
they're
missing
a
user
story
outline
the
user
story.
That's
the
most
important
aspect,
because
the
implementation
details
could
be
based
upon
the
user
story.
It
might
be
multiple
ways
so
that
we
can
accomplish
that
without
any
solution
a
year
or
so
should
be
before
we
even
have
the
user
stories
all
hammered
out.
So
again,
caps
will
come
into
place.
They're
gonna
be
vetted.
J
I
do
just
want
to
address
one
comment
you
made
about
reference
implementations,
forcing
things
we
want
to
split
this
into
what
is
the
preferred
chosen
extension
mechanism
or
mechanisms
and
that's
what's
important.
The
reference
implementations
will,
just
you
know,
use
whatever
the
the
mechanisms
are,
that
the
community
chooses.
K
Okay,
I'm
not
sure
that
really
alleviates
my
concern,
I
mean
I
I,
think
the
point
that
I
was
trying
to
make
is
if,
if
the
reference
implementation
assumes
calling
out
using
any
kind
of
mechanism,
then
how
much
of
that
is
actually
going
to
be
reusable
code
for
anything
that
doesn't
have
that
calling
pattern.
So.
J
The
the
reference
implementation
I'll
give
an
example
here:
a
possible
reference
implementation
could
be
a
cube
idiom
based
bootstrapper
for
setting
up
your
machine.
The
extension
point
is
I
need
to
get
my
machine
bootstrapped,
so
there
theoretically
could
be
a
controller
that
uses
a
web
hook
to
call
out,
or
there
could
be
a
controller
that
expects
to
keep
the
actuator
model
that
we
have
today.
J
But
the
common
code
is
the
fact
that
we
need
to
perform
this
action
of
bootstrapping,
and
so
you
know
if
cluster
API
decides
we're
gonna
do
web
hooks,
then
the
reference
implementation
will
be
web-based
if
it
decides
we're.
Gonna
support
web
hooks
and
CR
DS
then
doesn't
really
matter
necessarily
what
the
reference
implementation
looks
like,
because
if
you
want
to
do
CR
DS-
and
you
can
do
that
or
you
know,
whatever
the
chosen
mechanism
is
okay,.
K
The
bit
that
gets
swapped
out
from
the
reference
implementation
to
be
my
provider
specific
implementation
would
be
a
whole
unit
that
was
somehow
triggered
to
do
its
operation,
whether
that
be
by
it.
Knowing
what
events
to
watch
for
what?
What
changes
on
what
objects
to
watch
for
whatever
or
is
that
the
idea
I
mean
I,
I,
I,
guess
I'm
not
really
clear
on
what
we
mean
when
we
say
reference
implementation
when
I
hear
that
what
I
meet
what
I
think
of
as
like?
E
I
think
that,
just
today
we
have
a
conversation
that
probably
was
very
literate.
Eva
would
be
into
that.
We
were
basically
talking
about
this
issue
and
an
idea.
It
was
like,
for
instance,
the
karate
controller.
Would
you
create
a
cluster?
You
need
to
create
the
control
plane
and
you
need
to
follow
certain
steps,
and
the
idea
of
this
model
is
that
you
can
register
extension
by
their
work.
Hopes
for
certain
actions,
but
you
can
not
I
mean
it
is
empty.
E
The
processor
will
not
call
anyone,
because
there
is
no
work
who
registered
there,
but-
and
let's
bring
to
my
initial
point,
is
you
handle
all
these
objects
at
sea
or
die's,
and
you
create
the
object
and
you
have
a
controller.
The
controller
will
take
care
of
that
object
and
you
have
a
web
hoop.
You
take
this
object
at
you
pass
today
to
the
work
group.
So,
basically,
you
are
like
saying
for
this
specific
action.
I
have
a
workbook,
but
they
shouldn't
want
to
use
it.
E
You
want
to
provide
your
own
controller
base
implementation
of
that
action.
As
as
long
as
you
create
this,
your
D,
you
can
reuse
that
that
that
was
my
point,
that
we
should
try
to
use
everything
as
you
are
these
just
basically
because
it
couple
of
bookcases
so
neatly,
sorry,
I.
Just
that
my
point
is
a
probably
the
reference
fermentation
is
like.
We
agree
as
a
community
to
implement
certain
actions
collectively
and
say:
oh,
we
will
do
it
our
cook,
but,
for
instance,
in
the
bootstrap
case,
is
really
specific
case.
E
They're
already
implementations
in
other
projects
that
are
basins
here,
these
amino
send
to
implement
a
worker
based,
one
I
will
shoot
him.
I
would
have.
If
you
want
we
can
we
can.
We
can
do
it,
but
we
cannot
simply
use
the
other
one.
It's
not
that
either
or
it's
a
lot
of
flexibility.
If
we
follow
this
simple
pattern
of
creating
series
and
using
dynamic
registry
of
work
for
different
actions,
I
think
that
it
can
work
to
live
work
a
cobra
at
least
these
two
use
cases.
There
may
be
another
use
cases.
J
So
to
answer
your
question,
at
least
in
my
mind,
there
are
certain
aspects
of
cluster
API
that
are
not
swappable,
so
you
know
there
will
be
logic.
For
example,
the
cluster
controller
for
right
now
will
look
at
your
cluster
that
you've
created
and
if
it's
missing
a
finalizar
it'll
add
the
cluster
finalizar
to
it.
I
can't
imagine
anybody
really
wanting
to
change
that
logic.
I
mean.
Maybe
you
do,
but
presumably
that's
that's
common
logic.
So
to
me,
that's
not
reference
implementation.
J
That's
common
code
that
everybody's
going
to
use
the
swappable
aspects
are
when
you
get
to
infrastructure,
specific
tasks
or
bootstrapping
tasks
where
you
want
to
use
cube,
ATM
or
you
don't.
Those
are
the
things
where
some
of
those
will
have
reference
implementations
and
the
goal
is
to
define
what
are
the
common
parts.
And
then
what
are
the
extension
points
and
the
extension
points
would
be
things
like
bootstrapping
a
cluster
and
that's
where
you
there
may
be
a
reference
implementation
and
if
you
don't
like
it,
you
could
use
it
from
one.
K
You
know
like
my
system.
I,
don't
care
about
web
hooks,
particularly,
but
if
somebody
wanted
to
employ
a
cluster
building
on
top
of
what
I've
built
and
also
use
web
hooks
to
do
something
extra,
then
I
would
want
to
be
able
to
support
that,
even
if
I'm
not
using
them
to
do
my
implementation.
So
if
we
can
accommodate
some
of
that
sort
of
thing
where
it's
not
required,
but
it
like
Paolo
is
just
saying
you
know
it's.
It's
extra,
then
I
feel
like
that.
That's
going
in
the
right
direction
that
I'm
comfortable
with.
A
A
H
Yeah,
sorry,
and
now
the
bureaucratic
note
I
can
maybe
bring
this
up
in
a
different
meeting,
but
I
thought
I
forgot
about
it.
Basically,
I
guess
this
applies
to
a
accounted
every
bytes
for
the
whole.
You
know
for
the
Sagan
in
general,
I
think
there
are
at
least
two
ways
that
I
know
of
that
that
calendar
anybody
get
created.
One
is
directly
to
the
calendar
and
I
think
you
have
to
have
certain
permissions
to
do
that.
H
H
H
Is
that
that's
that's
one
of
the
drawbacks
is:
if
I'm
not
creating
them,
then
then
I
guess
the
a
the
other
thing
is
for
for
things
like
these
work
stream
meetings
are
are,
though,
you
know
they're
kind
of
ephemeral.
Are
they
also
going?
Are
they
supposed
to
go
to
you
know
through
the
PR
process,
and
all
of
that.