►
From YouTube: Kubernetes SIG Cluster Lifecycle 20190403 - Cluster API
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
April
3rd
edition
of
the
cluster
API
office
hours,
adding
a
link
to
the
chat
right
now
for
the
people
attending
real-time.
Please
go
ahead
and
add
your
name
to
the
attendee
list
and
if
you
have
any
items
that
you
want
to
bring
up
on
the
agenda,
go
ahead
and
please
add
them
there
as
well
to
start
off.
A
Today
we
have
an
announcement
that
we
have
finally
released
b1
alpha
one
last
Friday
we
cut
the
official
0.10
release
of
cluster
API,
so
that's
been
a
little
over
a
year
in
the
making.
So
congratulations
and
thank
you
to
everybody
who
helped
make
that
happen.
It's
been
a
long
road
and-
and
we
finally
hit
that
milestone.
B
So
fir
many
other
for
a
while,
oh
that
we
want
as
much
stamping
providers
need
to
do
this.
There
is
always
the
option
to
exit
out,
but
when
the
gimmick
or
its
kind
of
dedupe,
the
problem
set
that
exists
across
a
number
of
different
for
both
of
creating
a
a
canonical
tool
for
image
stamping
and
we
open
this
issue
a
while
ago.
B
Basically,
if
you
look
at
across
the
providers,
there
are
several
different
things
that
are
being
done,
so
what
I'm
gonna
try
to
do
in
the
next
week
or
so
is
to
create
a
spectra,
further
work,
as
we've
mentioned
time
before
that
we've
read
this
several
times
in
the
past,
but
it
is.
It
is
clearly
out
of
scope
for
cluster
API,
but
it
is
also
close
to
API
as
a
primary
consumer.
B
So
it's
possible
that
for
in
duration,
have
it
live
with
the
cluster
API
repository
until
we
get
enough
eyeballs
on
it
enough
for
in
some
place
that
it
can
live
on
its
own.
Oh
so
I
wanted
to
give
a
PSA
that
if
you
were
to
be
involved
in
the
requirements
and
document
stuff,
please
hit
me
up.
Unpack
and
I'll
get
us
a
spec
going.
C
B
Include,
no,
it
might
be
the
default,
but
it
doesn't
mean
that
you,
it
won't
allow
folks-
and
we
will-
you
know
a
lot
of
folks
to
do
whatever
they
want
to
do.
We
do
want
to
make
it
easy
for
the
common
use
case
so
standard
the
follow
the
standard
like
rubidium
mantra,
which
is
like
make
it
super
easy
for
the
80%
use
case,
but
also
allow
that
20%
use
case
to
have
a
clean
exit
strategy.
C
D
It's
just
so
so
I
think
Dan's
getting
at
is
we're
talking
about
building
images
which
could
be
either
from
without
environment
or
an
on-premises
environment
depending
and
he's
wondering
about
the
case.
What,
if
we
actually
have
no
way
to
fix
it,
can
we
still
like
what
do
we
do,
and
so
one
answer
is:
don't
use
the
packager.
Another
answer
is,
and
this
could
be
a
requirements
that
we
have
when
we
have
a
packin
discussion.
D
B
B
E
Yes,
thank
you,
so
this
actually
came
up
via
APR
I,
don't
know
if
the,
although
the
pr
is
here
but
the
seems
really
trivial,
it's
bear
with
me
because
I
think
it
goes
to
a
broader
point.
The
kubernetes
version
has
specified
in
if
I
recall
correctly,
the
machine
machine
machine
set
there's
a
debate
about
whether
it
should
have
a
V
in
the
front
of
it
and
I
think
we
currently
require
it
not
to
have
a
V
in
front
of
it.
E
So
that
would
be
one
but
14.0
as
opposed
to
v1
14-0,
and
if
you
type
v1
14.0
doesn't
like
the
scripts
don't
work.
The
question
is
whether
we
want
this
arises
in
a
number
of
places.
Similar
sort
of
things
arise
in
a
number
of
places
in
terms
of
sanitization
or
normalization
of
inputs
and
I
guess.
The
question
is:
do
we
want
to
four
so
I?
F
E
And
open
stacked
like
needs
something
else
entirely
so
I
feel
like.
This
is
something
we
should
agree
at
the
top
level
and
as
I
see
it,
the
options
are
that
we
are
fairly
liberal
and
we
accept
either
V
or
not
V
and
just
normalize,
or
that
we
implement
validation
and
are
strict
and
require
you
to
specify
without
the
V.
If
that's
one,
we
want
I,
can't
remember
and
doesn't
really
matter
what
it's
either
without
the
V
or
with
the
V.
E
Whatever
we
choose
will
require
one
particular
form,
the
trade-off
being
in
my
mind,
I
don't
show
there
other
options,
so
the
trade-off
being
in
my
mind
whether
if
we
are
liberal
and
we
accept
V
and
not
V,
then
every
other
consumer
of
the
API
will
also
have
to
have
the
same
normalization
logic
or
as
if
we
are
strict.
They
will
not,
but
it
is
a
little
harsher
on
users
and
but
if
we
have
a
web
hook
that
enforces
validation,
it's
not
in
the
world.
So
that's
what
I
wanted
to
sort
of
raise
to
sort
of.
A
G
E
E
D
Yeah
I
feel
like
these
should
be
optional
and
almost
all
code
that
I've
seen
written
because
December
standard
that
is
not
allowed
B.
When
the
user
passes
a
B,
which
is
people
readies
in
order
to
use
a
simple
library
it
is
compliant
it
has.
You
have
to
write,
set
a
code
to
drop
the
beam,
and
you
have
to
do
that.
E
H
Think
this
might
be
something
that
would
be
better
discussed
as
part
of
the
mini
caps
for
the
features
once
we
get
into
V
1
alpha
2
after
the
goals
and
requirements
and
use
cases
refinements.
I
would
love
to
see
this
in
a
common,
singular
default
implementation
that
can
work
across
all
providers.
All
infrastructure
providers
so
would
be
ok
if
we
recognize
that
we
need
to
solve
this,
but
make
sure
we
do
it
as
part
of
the
new
kept
process.
E
Right
I
think
that's
fine,
I
think
that
is
also
a
fair
thing
to
write
on
the
PR
I
wanted
to
have
something
to
respond
to
there.
I
think.
That's
a
good
idea,
I
think
I
think
this
actually
arises.
I
think
they're
like
three
or
four
that
were
similar.
This
was
the
sort
of
simplest,
so
reason
about
I
think
right,
all
right,
whether
I
remember
he
was
but
yeah
I
think
that
I
think
what
your
prose
makes
a
ton
of
sense
on
me.
A
H
All
right
thanks,
Jason
you,
and
so
as
I'm
assumed.
Most
of
you
are
aware.
We
have
two
documents
now,
one
for
goals
and
requirements
and
a
second
one
for
use
cases.
We
would
strongly
like
to
be
able
to
get
lazy
consensus
agreement
on
the
goals
and
requirements
within
the
next
two
days
by
Friday
and
I
would
encourage
everyone
to
go
review.
H
G
H
B
Also
recognize
that
this
is
an
update
and
I
fully
expect
that
over
time
we
we
will
approach
what
we
all
agree
is
consensus.
So
if
we
update
now,
it
seems
totally
reasonable
that
we
might
want
to
modify
our
update
in
the
future.
But
this
gives
us
some
guide
rails
to
probably
for
the
conversations
that
we
have.
D
D
D
E
H
I
would
I
think
I'd
be
okay,
removing
it
when
I
originally
wrote
it.
It
was
an
attempt
to
say
something
along
the
lines
of
if
I
have
a
machine
represented
in
cluster
API,
and
that
translates
to
an
ec2
instance,
for
example,
and
that
ec2
instance
gets
terminated
for
whatever
reason
I
want
to
make
sure
that
that
gets
rectified.
And
so,
if
it's
an
understanding
that,
as
you
said,
David
we're
doing
operators
and
that's
implicit
and
inherent
to
reconciling,
because
it's
declarative
API
is
and
that's
the
way
that
this
API
space
works.
H
D
H
F
F
Comment
Andy
both
does
more
than
the
warning
I
think
that
is
probably
more
important
that
relating
the
use
cases
to
the
requirement
that,
as
you
said,
a
anyone
who
has
a
use
occasion
take
care
of
that,
but,
as
we
will
actually
move
to
work
on
the
requirements,
it
would
be
important
to
know
which
these
cases
this
requirement
belongs
to
just
to
have
a
context.
You
know.
So
there
is
a
requirement,
but
the
reason
use
case
sometime-
it's
not
obvious
I
did
a
station
Mimi.
We
are
only
capturing
the
initial
idea
of
this
requirement.
F
So
I
know
I,
don't
know
how
to
solve
this
problem,
but
my
spirit
doesn't
the
problem
that
you
have
required.
We
didn't
know
Nicole.
What's
the
cost
to
contact
with
that
requirement?
Word
is
requirement,
came
from
just
solo
to
refine
the
requirement
more
specific
detail
so
because
we
have
a
bunch
of
requirements
so
that
something
that
worries
me
I,
don't
know
how
to
solve
it.
Honestly
I
saw.
I
F
That's
what
I
have
done
also
that
that's
what
I
used
to
do
also,
whether
they
do
this,
but
it's
it's
harder
to
do.
Was
we
have
this
lot
of
work
mostly
because
now
we
we
need
to
ask
people
to
to
do
the
binding
more
more
than
the
use
case
to
the
requirement,
try
to
look
for
the
requirements
and
ties
to
the
use
case.
The
other
way
back.