►
From YouTube: 20190501 - 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
If
you
have
any
items
that
you
want
to
bring
up
today,
please
go
ahead
and
add
them
to
the
agenda,
and
also,
please
add
yourself
to
the
attendee
list
on
the
agenda
as
well
heading
the
link
to
that
into
the
group
chat
for
anybody's
attending
live
to
start
with.
The
first
item
on
our
agenda
is
around
creating
a
new
repository
for
a
cluster
provider
API
or
cluster
API
provider,
IBM
cloud
yeah.
B
B
So
currently
we
already
have
a
pro
tab
here,
but
currently
it
was
hosting
in
not
brother
and
sister,
who
is
quit
by
myself
and
can
read
the
prototype
for
seed
product
has
been
finished,
so
you
can
see
that
we
have
a
token
here,
so
that
and
the
other
one
does
afford
the
document
to
create
a
current,
a
stressor
on
IBM
cloud.
So
we
so
we
had
so
we
have
some
Shotaro
here
and
also
some
diagrams
and-
and
it's
also
including
some
picture
here.
B
B
So
how
the
gardens
such
as
we
have,
we
have
followed
the
code
of
conduct
and
we
also
have
a
lessons
following
the
Akagi
lessons
we
and
besides
all
the
contributors
had
sent
the
scenes
yet
yet
see
re
here
and
we
also
have
created
a
owner
fail
and
insisted.
We
have
included
are
the
owners
for
cross
api
and
the
class,
let's
echo
the
IBM
class.
So
we
have
all
the
owners
here
and
yes,
so
this
is
a
email
that
I
sent
to
comment.
A
steering
committee
and
beside
I
also
add
the
I.
B
Rashad
and
I've
got
some
comments
from
yes,
I
think
so
so,
actually
so
I'm
just
wondering
how
we,
how
we
can
move
forward
forces
to
create
a
new
rep
code
to
a
host
of
the
IBM
cloud
provider
for
Krantz,
API
and
besides,
I
also
got-
and
we
said,
I
also
got
a
notification
from
from
from
e
from
Nick
lucky
and
based
on
his
comments,
and
he
kaha
me
to
create
the
repo
of
Caesarea
IBM
coroner,
but
I
need
to
God
accrual
from
the
c-class
or
the
left
circle
here.
B
A
So
I
think
there's
a
few
different
overlapping
concerns
here.
One
of
them
is
to
get
a
repo
hosted
in
the
org.
You
don't
necessarily
have
to
get
approval
from,
say,
cluster
lifecycle.
The
sponsorship
from
Sega
VM
cloud
should
be
sufficient
for
that.
So
you
should
just
be
able
to
show
that
there
was
a
lazy
consensus
vote
taken
within
Sega
IBM
cloud
to
adopt
the
project,
and
that
should
be
enough
to
transfer
it
over.
A
B
B
A
A
C
Yeah,
so
that
was
me
I'm
near
in
community
and
was
looking
for
some
places
to
possibly
contribute
and
I
seen
conformance
tests
and
thinking.
That
might
be
a
good
way
to
both
get
more
a
test
beverage
and
kind
of
explore
some
of
the
providers
and
how
they're
working
and
get
more
of
a
baseline,
but
I
found
that
one
issue,
but
it
seemed
like
there
were
a
few
open
questions.
So
I
was
kind
of
curious
if
there's
been
previous
stuff
communicated
and
just
try
to
get
more
information.
If
there's
next
steps
that
I
can.
A
I
think
there
is
definitely
some
end-to-end
tests
were,
and
things
like
that
that
can
be
done
both
on
the
cluster
API
side
and
the
provider
side.
But
what
actual
conformance
testing
will
look
like
will
probably
be
highly
dependent
on
the
output
of
the
work
streams
that
are
currently
defined
for
Jason?
If
I
can.
D
Jump
in
there
I'm
pretty
involved
in
the
conformance
at
verdun.
One
of
the
things
about
conformance
in
particular
is
something
the
close
to
API
is
not
likely
to
be
subject
to
conformance
any
time
soon,
if
ever
so
it's
its
conformance,
is
only
non
optional.
Ga
features,
so
what
we're
we're
confirmes
could
relate
really
well
to.
This
would
be
the
ability
to
run
conformance
tests
against
clusters
created
with
different
providers,
but
that's
really
kind
of
outside
of
the
scope.
I
would
think
of
this
particular
effort.
A
So
if
I
understand
the
issue
correctly,
the
things
referencing
it's
around,
creating
conformance
tests
for
plus
for
API
in
particular.
So
if
you
saw
I,
was
go
ahead.
So
if
you
have
a
provider,
you
can
have
some
type
of
validation
day
informant
with
the
cluster
API
project.
Yeah
I
think
we.
This
is
a
general
problem.
D
Music
people
using
work
informants
and
we
need
to
switch
to
the
without
reaching
for
that
sort
of
thing
so
like
with
Luana
validations
API
we
may
have
mentioned
Suites
show
because
it
actually
prefers
the
ability
to
use
the
name.
Kubernetes
like
it's
got
a
lot
of
sort
of
significance
around
it,
as
opposed
to
this
particular
feature
works.
E
Yeah,
thank
you.
So
thank
you
for
that
definition,
because
I,
when
we
were
talking
about
conformance
I
was
I
was
going
to
what
you
were
saying
with
that.
That
is
a
special
meaning
and
I'm
piping
up
to
simply
say
the
easiest
way
to
think
about
conformance
to
me,
and
maybe
others
do
this.
Remember
those
Intel
Inside
stickers
that
used
to
come
on
computers,
conformance
connotes
kubernetes
inside.
If
you're
conformant,
you
can
put
a
sticker
on
your
distribution
that
says
kubernetes
and
it's
officially
conforming
kubernetes.
A
E
A
There's
a
distinction
here
too
and
I
think
one
of
the
things
we're
trying
to
define
is
us:
maybe
we
call
it
something
other
than
conformance,
but
similar
to
kubernetes
complements
what
cluster
api.
If
you
have
a
provider
or
a
managed
service,
or
something
along
those
lines
that
says
that
they
are
plus
I,
they
would
have
to
pass
this
test.
E
Also,
doesn't
that
kind
of
the
you
know
what
is
conform
at
close
to
API
if
it
can
produce
if
we
can
deploy
the
clusters,
I
mean
that,
what's
the
result
that
we
care
about
more,
maybe
I'm
wrong,
but
I
understand
the
distinction.
But
conformance
is
a
loaded
term
when
it
comes
to
testing
in
kubernetes
and
I.
Don't
think
that
your
I
don't
think
that
your
effort
at
the
distinction
is
going
to
have
the
effect
that
you
think
it
is
when
you
get
into
conversations
with
people
steeped
already
in
general,
conformance
testing,
yeah.
C
So
it
sounds
like
there
is
some
discussion
to
be
had
on
the
name
inside
and
this
at
least,
but
and
then
you
mentioned,
there's
probably
more
to
work.
That
could
happen
after
alpha
2.
Are
we
at
the
point
where
kind
of
most
of
the
set
up
for
implementing
the
actual
tests
was
already
there
and
available,
and
then
once
we
know
those
concrete
api's,
we
can
then
write
the
test
for
it.
I'm
just
wondering
if
there's
any
kind
of
initial
work
that
we
can
do
in
advance
upfront
now
any
of
that
yeah.
A
What
kind
of
this
validation
suite
or
whatever
we'll
call
it
looks
like
as
far
as
API
types
that
are
consumed
and
exported
the
other
ones
around
the
extension
mechanism.
So
how
is
the
provider
exposing
you
know,
access
to
itself?
That
would
be
another
part
of
this
validation.
So
until
we
know
what
that
extension
mechanism
is,
it's
going
to
be
a
little
bit
difficult
and
then
the
other
parts
are
around
node
lifecycle,
management
and
control,
plane,
lifecycle
management
and
without
having
some
more
concrete
nests
around
what
those
are.
F
Just
the
just
a
brief
thought:
actually,
maybe
maybe
one
thing
that
would
be
helpful
at
this
point.
While
we
talk
about
you
know,
potentially
a
new
API
and
a
data
model
unamerican
be
all
sorts
of
repercussions
based
on
that.
Would
it
be
of
interest
to
kind
of
define
an
abstract
provider
that
the
test
could
be
reading
for
that
it
could
serve
as
a
model
for
for
future.
A
Providers
so
we
already
have
kind
of
an
entry
sample
provider.
That's
based
on
kubernetes
and
docker
kind,
and
I
would
expect
that
you
know
one
that
allows
us
to
do
kind
of
more
generic
end-to-end
testing
in
the
cluster
API
project
itself,
but
I
would
expect
that
could
also
serve
potentially
as
an
example.
G
Related
to
this,
we
have
the
current
gift.
Book
has
instructions
to
create
a
new
provider.
There
are
portions
where
the
code
is
in
the
book
instead
of
the
referencing
code.
I
think
it
would
be
useful
to
have
an
example
provider
and
it
was
self-contained
so
that
you
could
get
both
the
reference
in
it
can
be
built
and
tested
independently
and
I
might
satisfy
the
yeah.
F
And
perhaps
I
mean
I'm,
actually,
I
was
actually
thinking
of
they
kind
of,
provided
that
it
would
be
quite
an
expensive
to
run
like
a
provider
of
source
that
wouldn't
actually
start
any
ATMs
or
containers
or
not.
They
wouldn't
assess
meet
demand,
only
looks
guys
say,
you
know
just
a
kind
provider
that
one
could
run
anywhere
and.
A
E
If
you
need,
if
you're
gonna
go
on
the
basis
or
the
foundational
concept
that
unique
kubernetes
to
run
these
providers
and
I've
kind
of
doing
some
work
that
you
don't,
but
if
but
if
I
think
that's
kind
of
the
accepted
idea
right.
So
if
you're
gonna
have
to
run
kubernetes
to
do
that,
I
mean.
How
are
you
running
that
together,
yeah.
F
There
are
various
other
things
ever
though
I
mean
I,
just
wonder
what
I'm
thinking
here
is
that
it
would
help
us
to
have
some
kind
of
way
to
to
validate
way
to
sort
of
to
to
have
a
better
API.
It
would
help
to
have
some
kind
of
tests
that
are
designed
to
be
purely
about
the
API,
and
we
know
we
really
have
side
effects.
Research
I
mean
that's
the
kind
of
thinking
that
led
me
to
do
this
suggestion
and
are.
E
Mean
I
see
what
you're
saying
sort
of
mocking
parts
of
the
controller
framework
or
parts
of
the
actuators.
My
only
problem
is:
is
that
once
you
start
doing
that,
I
think
you're
putting
so
much
effort
and
I
went
and
I
was
looking
at
that
too
recently
and
I
ended
up
just
saying
at
the
point
that
I'm
going
to
care
about
using
these
independently
or
the
actuators,
because
beyond
that,
you
have
to
mock
so
much
of
what
kubernetes
provides
just
you
should
use
kind
and
run
kubernetes.
A
H
No
all
right,
Vince
you're
up
first
with
the
data
memory
data
model,
the
shaping
a
little
bit
more.
We
added
some
like
yamo
and
just
like
to
kind
of
like
started
reasoning
about
like
what
the
types
will
look
like
and
how
the
relationship
between
them
it's
going
to
be
from
a
user
perspective.
I
reminded
that
we're
trying
to
build
types
like
if
they
don't
have
to
be
simple,
where
we're
not
trying
to
build
an
opinion,
a
tool
but
we're
trying
to
build
compostable
objects
that
can
create
powerful,
kubernetes
clusters.
H
So
if
you
do
have
time
to
do,
go
and
in
the
in
the
in
the
document
and
like
leave
comments
or
add
new
content,
we're
trying
to
kind
of
like
get
this
up
and
running
in
the
next
few
weeks
and
then
proceed
with
a
PR
which
is
going
to
be
kind
of
like
the
starting
of
like
the
new
data
types
and
how
it
going
to
be
defined.
And
there
is
also
like
some
new
data
types
that
have
been
added,
it's
kind
of
literally
the
extension
mechanism
which
will
be
filled
in
once
the
extension
mechanism.
I
Yep
so
we've
been
having
some
good
discussion
on
the
discuss
kubernetes
site.
It
would
be
great
to
have
more
people
following
along
there
and
then,
as
far
as
the
proposal
that
goes,
I
restructured
it
just
a
little
bit
to
sort
of
frame
the
problem
and
sort
of
what
what
exists
now
and
what
we
are
thinking
of
moving
to
and
the
pros
and
cons
of
each
of
those.
I
A
J
We
had
a
meeting
last
week,
and
so
we
decided
to
split
up
into
two
caps
to
start
off
with
what
is
on
image,
stamping,
so
image,
stamping
in
a
sense
of
building
things.
Like
am
I
some
decays
and
kikou
images
and
those
kind
of
things
we
have
a
draft
cap
in
which
you
can
put
your
comments.
I've
also
started
discuss
Fred.
If
you
want
to
have
longer
discussions
about
things
outside
did
google
dos
comment
thread
for
map
also
started?
J
We've
got
a
blank
template
to
fill
in
or
no
lifecycle
hooks.
So
what
kind
of
X?
In
terms
of
thinking
about
the
extension
mechanisms
which
parts
of
the
node
life
cycle?
Are
we
going
to
make
extensible
so
we'll
need
user
stories
for
those
and
just
start
thinking
about
how
to
make
that
work?
So
Tim's
gonna
be
trying
to
get
their
caps
into
shape
for
next
week.
K
Yes,
in
the
process
of
preparing
people
puzzle
dog
for
three
approaches
that
we
discussed
last
time,
some
of
the
approaches
how
to
handle
the
control
plane,
which
is
like
pod
based
control,
plane,
which
is
running
on
a
management
cluster
itself,
and
there
are
two
more
approaches
that
we
discussed.
One
of
them,
both
specifically
the
Debbie,
create
master
machines,
then
in
different
working
on
the
ready,
great
master
machines
and
one
was
ground,
manage
tremendous
cursors.
K
L
M
J
M
N
Was
gonna
say
in
general,
we
haven't
said
anything
broadly,
but
I
do
think
that
having
milestones
and
rough
deadlines
would
be
a
good
thing
to
do
so
like
if
one
of
them
is
setting
up
user
stories
and
we
have
a
deadline
for
that
and
then
getting
a
proposal.
Written
I,
don't
know
what
the
appropriate
times
could
be
given
everyone's
availability,
but
I
do
agree
that
trying
to
set
some
deadlines
would
be
useful.
So
maybe
at
the
the
next
meeting
for
each
work
stream,
they
could
individually
try
and
come
up
with
those
deadlines.