►
From YouTube: Kubernetes SIG Cluster Lifecycle 20190327 - 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
A
So
if
you
have
any
items
that
you
want
to
bring
up,
please
go
ahead
and
add
them
to
the
agenda
before
there's
two
topics
since
I
have
a
feeling
they'll
take
a
little
bit
to
get
through,
and
the
link
to
the
agenda
document
is
already
in.
The
group
chat
if
you
are
attending
live,
and
the
first
item
that
we
have
not
related
to
those
large
items
is
from
Alberto
on
Cluster,
API,
conformance,
come
and
edy
test
suite.
A
B
Yes,
cool
yeah,
so
since
we
are
we've
been
recently
discussing
about
the
roadmap
for
the
project
and
all
this
stuff,
I
wanted
to
bring
this
atom
and
understand
was
the
medium
and
long
term
plan
for
the
end-to-end
testing
and
what's
the
the
corona
state
up
stream
today.
One
thing
that
I
that
I'd,
like
to
see
at
some
point,
is
to
have
an
end-to-end
test
suite
that
kind
of
measure.
B
If
provider
is
clustered
API,
conformance
or
not
so
in
a
sense
we
could
run
the
same
and
to
enter
suite
against
any
provider
in
a
kind
of
cloud
of
Gnostic
wait.
So
validating
seems
like
when
I
scale
up
or
two
on
a
machine,
a
machine
set
I
get
or
a
machine
deployment.
I'll
get
I,
get
new
machines
and
new
nodes
into
this
running
cluster,
or
you
know
things
that
should
apply
to
any
provider.
A
So
I
know
today
we
have
a
minimum
level
of
ete
testing
on
the
cluster
api
of
repository,
which
I
don't
know
the
level
of
coverage
of
it
today.
But
theoretically
could
test
kind
of
the
common
controller
objects
like
around
machine
sets
and
machine
deployments
things
like
that,
but
we
don't
have
any
type
of
conformance
test
suite
so
to
speak,
to
be
able
to
run
around
the
actual
provider
implementations,
but
that
does
sound
like
some
that
we
would
want
to
track
on
kind
of
that.
What
is
cluster
API
doc?
B
Okay,
yeah:
that's
that's.
One
of
the
reasons
that
I
wanted
to
bring
it
up
is
because
I
think
it
makes
it
would
make
sense.
Since
we
are
discussing
about
all
these
new
features
or
futures,
though
that
we
wanted
the
project
to
to
support
so
as
we
decide
which
one
we
want
to
support,
it'll
be
nice
to
make
sure
that
we
plan
for
having
an
end-to-end
testing
for
each
of
them.
A
I
was
helping
provide
some
support
for
a
user
in
the
cluster
API
channel
around
the
GCP
provider,
and
it
looks
like
the
GCP
provider
has
fallen
kind
of
into
a
state
of
disrepair
and
I
worry
about
the
optics
of
that.
So
I
wanted
to
find
out
kind
of
what's
the
support
plan
for
the
GCP
provider
and
what
what
other
people
in
the
state
can
do
to
kind
of
help
out
with
that.
Is
that
something
that
you're
aware
of
Justin
I.
C
A
C
A
Can
definitely
see
that
the
other
question
that
I
have
is
there
seems
to
be
some
kind
of
alignment
that
we've
been
working
on
with
some
of
the
providers.
As
far
as
like
trying
to
more
align
kind
of
the
different
provider,
specific
types
and
and
behaviors,
is
there
any
interest
to
kind
of
do
that
with
the
GC
pay
provider
as
well,
or
is
the
kind
of
current
approach
kind
of
set
in
stone,
I.
C
Absolutely
think
we
should
declare
those
to
find
those
behaviors
I
I
would
personally
hope
that
most
of
them
are
most
of
the
challenging
ones.
I
hope
would
be
at
the
machine
developing
machine
set
level,
but
yes
like
around.
When
do
we
delete
machines
and
things
like
that
I
think
we
should
I,
don't
know
if
it's
possible
have
a
conformist
type
of
test
for
it,
but
we
should
define
rules
just
to
like
this
is
what
we
think
it
should
be
regardless
and
I
didn't.
C
D
Go
ahead.
Oh
sorry,
I
just
want
to
add
the
current
eg
test
that
not
intended
to
actually
test
against
like
conformist.
So
the
the
issue
brought
up
by
Alberto
is
to
basically
want
to
make
sure
the
provider
impatiens
is
compiling
these
their
design.
We,
we
agreed
all
so
the
current
existent,
but
not
then
now
initially
anyway.
Think
about
that.
So
I
think
there's
this
brought
up
a
new
new
category
of
test
P.
Do
you
test?
That's
that's
what
I'm
trying
to
say
here.
E
E
Maybe
like
I
guess
for
the
prior
comment,
like
at
least
speaking
for
my
perspective,
her
red
hat,
like
I,
feel
like
we
should
have
IDI
test
Suites
at
each
individual
layer
of
the
overall
cluster
attack
framework,
so
that
we
don't
have
to
so
that
we
manage
these
things,
understand
them
more
at
a
granular
feature
level.
I
guess
but
yeah
I'd
be
happy
to
work
with
that
as
we
get
through
the
lettering
discussion.
C
Yeah,
we
can
definitely
that
I
think
there
was
a.
There
was
a
bunch
of
pairs
that
went
in
recently
my
claim
or
Pierre's
proposed
recently,
and
actually
some
of
them
are
probably
better
discussed
at
this
level
at
the
cluster
API
level.
So,
for
example,
one
of
the
ones
that
comes
to
mind
is
I,
don't
sound
silly,
but
do
you
need
a
V
in
the
kubernetes
version
right,
and
it's
like
that
to
me-
is
there's
a
first
of
all
at
something.
We
should
all
agree
at
the
cluster
API
level.
C
We
expect
them
to
be
correct
and
so,
for
example,
I
would
guess
the
kubernetes
version.
We
will
tolerate
a
V
or
a
not
V,
but
we
might
also
want
to
put
a
URL
in
there,
and
so
we
don't
want
to
like
do
the
current
permutation,
which
just
removes
any
non
numeric
characters,
but,
on
the
other
hand,
there's
also
a
PR
out
there
for
like
on
GCP.
C
You
have
to
like
declare
a
disk,
your
your
boot
disk
and
it
automatically
adds
the
boots
if
it
isn't
there,
but
that
comes
from
sort
of
the
Machine
deployments
yeah
mo,
and
do
we
believe
that
yeah
mo
file
to
be
correct,
or
are
we
going
to
try
to
modify
it?
So
that's
that's
why
I
didn't
like
as
I
sort
of
punted
on
some
of
those
PRS
as
being
too
hard,
I
I.
Think
we
already
plans
on
them
past
me
when
I
also
want
to
be
honest,
but.
A
G
F
We
have
four
issues
left
for
Cathy.
Three
of
them
are
dogs
which
I
think
David
is
assigned
to
it.
We
have
the
only
last
feature
that's
gonna
go
in,
which
is
the
Machine
sets
support
for
the
finding
specific
machines
when
it's
going
down.
I.
Think
part
of
this
will
be
fixed
with
a
fear.
That's
in
flight,
which
is
the
next
item
on
the
agenda,
which
is
the
leap
policies
for
machine
sets.
So
the
idea
is
like
to
merge
this
I.
F
Don't
know
if
there
was
a
there
was
an
issue
with
the
baseball
files
getting
deleted,
but
I'm.
Ok,
emergeny
and
I
fix
it
afterwards.
If
it
was
a
mistake,
if
we
don't
get
like
some
sort
of
thing
from
the
owner
of
the
PR
I,
don't
like
next
opposes
the
call
other
than
that
we
have
default
sync
interval
that
has
changed
to
10
minutes
from
10
hours.
This
will
require
providers
to
actually
update
their
own
main
function.
F
A
Yes,
so
I
know
that
we
are
planning
on
releasing
the
AWS
provider
after
the
cluster
API
released.
However,
currently
the
release
process
for
cluster
API
does
rely
on
a
Googler
today
to
be
able
to
push
the
images
to
the
tree.
See
our
bucket.
Is
that
something
that
you
might
be
able
to
help
us
out
with
on
Friday
Justin.
C
I
can
help
you
out
with
it.
I,
don't
know
whether
I
have
the
bits,
but
if
not
I
can
try
to
track
down.
Who
does
and
yes,
I
will.
I
will
happily
do
that
we,
but
we
have
a
plan
to
get
off
this
as
well,
which
so
like
CMC
from
structure.
But
yes,
sorry
in
the
meantime
I
can
we
can
make
do
the
manual
approach.
F
A
G
Thanks
Jason,
so
before
we
get
into
that
again,
I
did
want
to
just
talk
about
the
doodle
poll
for
potential
additional
meeting
times.
We
clearly
can
use
the
rest
of
this
our
to
go
over
the
skills
and
requirements,
but
we
also
have
several
votes.
We
have
nine
people
who
said
they're
available
for
an
hour
immediately
following
this
meeting
and
I'd
be
happy
to
have
anybody
who's
available,
join
Thank,
You
Vince
for
putting
the
doodle
link
in
the
chat
there.
G
So
if
it,
if,
if
people
are
good
with
continuing
on
beyond
the
end
of
the
hour
for
this
one,
we
can
just
keep
going
other
than
that.
The
next
most
votes
is
for
tomorrow
at
2:00
p.m.
eastern
US
time,
and
then
we
have
another
group
of
nine
who
can
do
Friday
at
1:00
p.m.
Eastern.
So
there
are
other
times
as
well
that
have
slightly
lower
participant
counts,
but
I
will
leave
it
up
to
the
group
to
to
decide.
You
know
when
what
makes
the
most
sense,
but
for
right
now
or.
G
It
does
not
have
to
be
this
week,
but
I
at
least
wanted
to
get
a
session
at
least
one
session
sometime
between
today
and
Friday
beyond
what
we
are
talking
about
in
the
office
hours
time,
but
yeah.
We
will
definitely
put
up
another
doodle
for
next
week
and
I
can
cover
the
entire
week.
Just
a
reminder.
The
goal
is
to
try
and
come
to
an
agreement
on
the
requirements
by
next
Friday
April
5th.
So
as
many
sessions
as
we
need
and
as
people
can
participate
in
would
be
fantastic.
G
G
But
I
do
think
that
looking
at
requirements
is
a
good
first
step
and
then
once
we
get
those
nailed
down,
we
can
move
on
to
what
I
think
is
probably
a
lot
more
interesting
and
contentious
to
everyone
which
is
talking
about
what
are
the
eight
guys
look
like?
What
is
the
data
model
look
like
and
so
on.
G
G
I
I
We
I
think
can
safely
make
an
assumption
that
all
of
our
machines
will
have
at
least
one
network
interface,
and
so,
rather
than
embedding
that
sort
of
thing
down
in
that
provider
config
where,
if
you
want
to
integrate
with
something
other
than
the
HTTP
for
IBM,
every
single
provider
has
to
implement
it.
We
can
bubble
that
up
to
the
top,
so
I
think
there's
a
few
things
like
that.
That
right
now
are
buried
in
provider
config
that
can
be
bubbled
up
to
the
tablet.
I
G
G
I
You
know
all
of
our
machines
will
need
some
sort
of
what
most
of
our
machines
should
at
least
support
some
sort
of
network
time
protocol
right
so
that
we
can
otherwise
certificates.
You
can
have
issues
or
certificates,
I.
Think
there's
sort
of
like
certain
bootstrapping
things
at
the
at
the
machine
level
that
that
we
need,
in
order
to
be
able
to
reliably
set
up
a
control,
plane
and
I.
I
Think
that
those
things-
and
you
know
those
are
just
a
couple
that
are
now
the
IP
apiece
that
you
can
set
up
interface
configurations
and
the
entity
P
configuration
but
I'm
sure,
there's
others
that
I'm,
just
not
thinking
of
right
now
that
we
I
just
wanna
I,
don't
think
there's
a
we
need
to
nail
them
all
down
here.
I
just
want
to.
I
F
One
common
I
have
them.
This
is
like
it
sounds
like
this
should
probably
go
down
in
design
guidelines,
because
it's
like
a
product
of
like
what's
gonna,
come
out
later,
because
even
right
now,
like
we
don't
know
like
what
actually,
what
functionality
will
have
across
providers
that
we
can.
Actually,
you
know
make
a
generic
there's
a
few
examples,
but
I
think
we
might
go
into
many
details
which
are
like
implementation,
specific,
but
I.
Think
it's
completely
fine
to
say
as
a
design
guideline,
and
we
want
operation
that
could
be
Derrick
to
live
in
foster
API.
F
I
Something
that
makes
sense
if
you
go,
does
I
get
my
look,
but
when
we
actually
design
the
API
rate,
I
want
to
make
sure
that
there's
places
the
item.
One
is
the
one
I'm
most
familiar
with,
and
the
reason
is
that
there's
no
reason
why,
if,
if
you
want
to
get
your
IP
addresses
from
something
other
than
the
HTTP
like
from
either
an
in-house
IPM
service
or
from
a
third-party
IPM
service,
then
that
way
providers
have
to
re-implement
that
right.
We
can
make
one
implementation
that
handles
that
and
all
the
providers
don't
have
to
I.
H
Sure
why
it's
I
found
an
NCP
of
any
concern
here.
I
most
things,
I
worked
with
it,
those
things
just
come
out
of
the
box
you
take.
For
example,
you
take
an
ion
and
a
me
in
Amazon
running
started
as
an
ec2
instance,
and
and
if
you
haven't
Evie
server,
there
will
work
and
they'll
be
DHCP
and
all
that
happening
behind
the
scenes.
If
your
environmental
may
be
something
like
I'm,
not
entirely
sure
how
come
this
is
considered.
A
cluster
API
concern.
H
I
Considered
an
is
layer
functionality,
so
in
Amazon
case
yeah,
there's
no
need
in
most
cloud
cases.
Frankly,
there's
no
need
for
any
of
this,
but
in
the
omron
cases
there
are
different
item
systems
that
in
integrate
with
there
are
a
lot
of
financials,
won't
allow
you
to
run
the
HVP.
They
don't
like
broadcasts
on
our
network.
So
there's
there's
not
cloud
use
cases
as
much
as
on-prem
use
cases
that,
where
these
things
come
into
play
and
there's
known
as
it's
a
it's
a
sort
of
optional
place
within
the
API.
F
H
F
H
F
E
I
guess
I
think
this.
This
concern
called
out
an
item
I
had
when
we
still
described
like
what
is
the
cluster
API,
so
I
feel
like
the
the
granular
details
that
we
were
just
discussing.
They're
kind
of
calling
out
like
a
question
I
have,
which
is:
do
I,
use
the
cluster
API
to
create
and
update
a
cluster,
but
do
I
not
use
it
to
do
ongoing
administrative
tasks
to
the
cluster
and
I.
Think
some
of
the
options
that
we
might
struggle
with
when
it
comes
to
boundaries
are
like
is
the
cluster
API.
E
E
X
because
I
think
it
kind
of
pre
judges
or
pre
labels
like
what
that
API
need
is,
and
it
sounds
like
in
the
prior
discussion.
It
sounds
like
there's
common
style
API
operations
that
are
required,
which
are
frankly
potentially
had
a
completely
different
scope
and
like
a
cluster
or
control,
plane
action.
So
morning,
like
from
a
terminology
standpoint,
when
we
discuss
requirements,
should
we
discuss
them
at
their
lair
rather
than
the
project
name.
J
I
think
the
the
key
here
is
part
of
the
functional
requirements
is
like
you
would
almost
break
them
down
into
goals
and
non
goals
that
one
thing
that
managed
that
is
the
best
part
of
any
document
that
I've
read
so
far.
That's
been
updated
in
the
new
kept
structure
has
been
the
explicit
non
goals
and
if
we
say
that
the
boundary
lines
are
drawn
here-
and
we
stop
at
this
point-
that
explicitly
states
to
the
consumers
that
we
don't
we're
not
going
to
take
on
these
other
wrongs.
J
G
There
or
not
I
think
there
is
a
little
bit
of
a
danger
with
non
goals
in
that
they
potentially
can
influence
the
design
of
the
system
in
a
way
that
you
know.
While
something
is
a
non
goal
like
you
would
potentially
try
and
design
away
from
a
non
goal
so
that
you
don't
support
that
case
and
so,
for
example,
if
you
look
at
the
original
cap
for
close
to
API,
one
of
the
non
goals
is
provisioning
infrastructure
unrelated
to
kubernetes
clusters
being
a
general
terraform
like
system
and
I.
J
Yes
or
no
I
think
that's
a
it's
a
pretty
broad
supposition.
There's
there's
a
lot
of
just
getting
it
working.
It
was
hard
to
meet
one
up
on
one
and
but
I
think
we
can
refine
I.
Think
the
whole
purpose
of
this
conversation
is
to
refine
the
statement
and
and
I
still
think
non
goals
are
good.
Nothing
will
change
me
for
swimmy
from
that
opinion,
but
the
refining
them
is
totally
for
your
game.
So
that
way,
it's
more
explicit
versus
less
and
less
it
maybe
can
find
where
the
boundary
lines
are,
but.
B
E
Me
just
I'm
capturing
the
discussion
that
happened
on
the
dock
and
so
like
in
some
discussions.
We
talked
about
I
just
want
to
know.
Like
do.
I
use
the
cluster
I've
tried
to
backup
and
restore
my
cluster
I
used
to
foster
a
pod
to
do
at
CD.
Backups,
like
is
this
an
administrative
API
for
my
cluster
or
just
a
bootstrapping
and
upgrade
API.
J
Specifically,
scope
to
my
psyche,
remote
management
and
everything
has
always
been
in
that
vein
right,
so
that
lifecycle
management
includes
deployment
the
initial
deployment
and
upgrade
and
update
in
adding
and
removing
within
that
scope.
But
the
actual
management
administration
has
never
been
in
scope.
E
C
C
A
cluster
you've
got
to
be
used
in
isolation
and
someone
that
is
running
a
kubernetes
cluster
will
have
to
do
these
tasks
and
I
think
it's
great
to
think
about
what
those
tasks
are
and
how
the
stuff
that
we
determined
to
be
in
scope
for
our
projects
can
interact
well
with
whatever
those
things
are
and
where,
where,
for
example,
we
say-
oh
well
see
a
key
rotation
is
out
of
scope
for
for
this
cluster
API,
we
can
be
like
well.
We
should
also
mention
that,
and
that
should
be
a
separate
project
somewhere.
C
Maybe
under
communities-
maybe
not,
but
there
has
to
be
other
API
and
there
are
some
API
switch.
We
want
to
work
very
well
with
like,
for
example,
cluster
autoscaler
and
there's
some
API
switch.
It's
probably
less
tight,
but
like
there's
less
of
a
dependency
in
more
of
a
yeah,
it
should
just
basically
like
we
hand
that
over
to
that
other
project
or
some
other
project
to
be
determined.
It.
J
E
I
think
there's
a
lot
of
interest
from
a
variety
of
folks
who,
like
we
just
pick
on
machine
management,
that's
the
one.
We
brought
up
like
there's
a
significant
pain
point
today
for
people
that
want
to
run
kubernetes
clusters
off
a
variety
of
cloud
platforms
to
have
to
manage
golden
images,
manage
the
equivalent
cloud
platform,
scaling
group
concepts
and
then
only
have
specific
concepts
in
the
cluster
autoscaler
support
on
particular
cloud
providers
like
essentially
like
scaling
based
on
cost
we're
like
I,
think
across
the
community
like
when
I
am
looking
to
engage
gear.
E
I'm,
looking
at
like
thinking
from
a
cluster
autoscaler
integration
perspective
having
an
API
to
address
machines
that
are
under
management
of
a
cube
like
API
like
I,
want
those
features
in
that
machine
API
to
support
the.
What
are
now
very
cloud
specific
feature
is
carried
in
the
upstream
autoscaler
project
and
so
and
and
those
things
are
it's
a
different
way.
You
look
at
the
composability
question
like
I.
Don't
know,
explain
when
you're
talking
about
composability
what
your
inputs
and
outputs
are
but
like
that
assumes
no
input
right.
E
That
doesn't
assume
that
that
machine
was
created
with
a
particular
install
tool
as
an
example.
Instead,
it's
just
trying
to
have
a
general-purpose
API
framework
to
manage
scale
groups.
That's
cloud
agnostic
and
I.
Don't
know
I,
don't
wanna
speak
for
other
parties
that
are
on
the
call,
but
this
is
the
tension
exists
in
the
project.
J
Entirely
possible
that
we
break
apart
what
is
cluster
API
and
what
is
the
machines
API
and
have
two
separate
functional
requirements
that
are
independent?
I
mean
if
we
had
two
bits,
it'll
be
broken
part
as
two
independent
version.
Api
is
there's
nothing
that
prevents
them
from
being
composable
in
homage
yeah.
E
I
agree
all
right
and
then
it's
just
a
matter
of
figuring
out
which
administrative
attacks,
administrative
tasks
you
want
to
take
on
at
each
layer,
and
just
for
my
fair
comment
like
when
we
were
saying
what
is
cluster
API
like
it'd,
be
good
to
know.
Is
it
my
input
to
do
administrative
actions
or
not?
And
it
seems
like
we're,
not
quite
sure
the
boundaries
here,
but
we
could
probably
talk
through
a
number
of
like
what
are
the
common
administrative
snares.
C
Think
what
you're
saying
makes
a
ton
of
sense
and
whether
or
not
it's
in
scope
we,
we
should
not
make
it
impossible
to
rotate
your
CI
key
right.
So
if,
if
there
is
a
list
of
things
maybe
like
talking
about
it
in
person
is
not
the
most
efficient
way
but
like
if
there
is
that
list
of
tasks
that
are
potentially
related,
let's
put
them
in
a
doc
and
be
like.
Yes,
it's
out
of
scope,
but
here's
how
it
would
or
it's
not
something
we
probably
want
to
support.
J
I
think
the
whole
the
whole
premise
behind
everything
that
the
six
supports
is
composability
in
defining
the
boundary
lines
of
where
one
tool
ends
and
another
begins,
because
conflating
the
scope
has
proven
detrimental
across
a
number
of
projects
in
some
of
the
ecosystem
and
they're
also
eventually
needs
to
fragmentation
of
post
projects.
And
that's
part
of
the
whole
reason
like
I
wrote
that
blog
post
is
that
we
want
to
prevent
to
the
uber
API,
and
then
we
do
all
things
poorly
and
then
it
causes
fragmentation
with
inside
of
the
ecosystem.
E
E
K
I
think
we
are
I
would
like
I
would
like
to
add
a
little
bit
here
so
from
the
administrative
perspective,
right
I
think
this
was
discussed
sometime
back
in
again
before
be
also
making
chip
Khan
right.
So
if
you
look
at
the
ecosystem
right
now,
we
already
have
tools
to
manage
one
clusters
of
clusters
of
clusters
and
so
on
right
we
have
mini
Cuban,
cops
and
all
over
the
smaller
place.
But
then
the
question
come.
We
shan't
came
that
the
real
challenge
is
managing
really
hundreds
of
clusters.
K
K
G
L
L
L
L
You
know
how,
if
I
have
a
tool
like
like
this
cluster
bundle,
then
how
do
I?
How
do
I
sort
of
split
that
you
know
do
I
do
I
have
to
change.
You
know
it
is
it
is?
It
is
the
sort
of
that's
the
tool.
That's
bluntly:
that's
putting
the
add-ons
and
the
core
components
together.
Is
that
just
you
know
design
that
we
don't
want
to
support,
or
you
know
what
what
do
we?
What
do
we?
What
do
we
think
about
add-ons,
and
maybe
Justin
can
can
can
add
some
thoughts.
C
Clarifying
thing
which
is
Ora,
the
bumble
doesn't
require
you
to
have
one
bundle.
So
I
think
this
is
an
important
thing
to
discuss,
but
we
could
have
a
bundle
for
api's
our
KCM
scheduler.
If
you
wanted
to
and
then
another
bundle
for
add-ons.
So
it's
not
it's
not
required
that
there
is
one
goober
bundle,
so
it
doesn't.
It
doesn't
dictate
an
answer
here,
but
I
think
this
is
an
important
question.
We
should
figure
out
yeah.
L
I
guess
I'm
as
you
imagining
as
an
end-user
right
I
want
to
deploy.
Like
my
my
right,
my
dreams
scenario
right
is
to
be
able
to
say:
oh
I've
got
this
this
cluster,
which
is
you
know,
really
a
configuration
of
all
my
you
know
all
the
little
knobs
that
I
want
tune
in
a
certain
way
and
all
these
sort
of
software
that
I
wanted
to
play,
maybe
including
things
like
some
kind
of
service.
You
know
service
broker
mesh
or
who
knows
what
you
know
as
a
cluster
administrator?
That's
sort
of
my
that's
bad.
L
That's
that's
everything
that
I
think
of
as
a
cluster
and
I
want
to
go
to
some
API
and
just
say
you
know,
give
me
this
now,
of
course,
if
we,
if
we
scope,
plus
your
API
down,
then
our
answer
would
be
look.
You
know
take
some
of
your
configuration
and
pass
it
to
cluster
API
and
then
once
that
you
know
once
enough
things
are
sort
of
up
and
running,
then
take
the
rest
of
your
configuration,
passed
it
to
coop
cuddle
right,
and
maybe
that's
okay.
A
L
A
A
Then
we
can
look
at
potentially
expanding
out
the
scope,
but
I
don't
think
we
want
to
bite
off
additional
kind
of
like
head
on
management
at
this
point,
but
we
do
have
an
item
not
fully
worded
out
to
think
about
kind
of
cluster
kind
of
required
add-ons
such
as
C&I
providers
and
things
like
that
yeah.
So.
E
Maybe
just
can
you
define
what
you
think
that
set
is
just
because
I
know
there's
a
meeting
on
April
5th
with
a
separate
ad
on
projects,
project
meeting,
I,
guess
but
like
it
sounds
like
it
sounds
like
cluster
API
has
an
end
user
who
once
operations
cost
is,
would
you'd
need
the
nsq
proxy
and
and
the
CNI
or
you
would
not?
What
is
your?
What
is
the
set?
You
think
that
is
in
school.
A
So
I
mean
to
proxy
and
DNS
those,
at
least
for
standard,
like
kind
of
run-of-the-mill
cluster
API
we're
getting
those
today
from
deploying
using
cube
ATM.
The
only
thing
that
we
don't
provide
that
is
kind
of
needed
for
deployment,
because
you
don't
have
DNS
running
until
you
have
a
CNI
provider
is
currently
CNI.
Maybe.
C
Maybe
so
this
is
where
maybe
we
can
apply
Tim's
composability
rule.
If
this
is
something
that
we
can
provide
a
mechanism
to
allow
to
be
added
outside
of
the
cluster
API
I,
you
reference
a
manifest
that
includes
that
we
reference
an
add-on
operator,
you
reference.
Whatever
else
you
want
to
reference
and
therefore
we
don't
have
to
build
it
into
cluster
API,
maybe
that's
sufficient
and
motivating.
C
This
is
like
one
of
the
mistakes
we
made
in
cops
is
we
were
unable
to
bring
up
an
API
server
without
a
CNI
provider
and
DNS,
and
so
we
had
to
bake
those
in
and
baking.
Those
in
proved
to
be
a
lot
of
work.
So,
like
that's,
why
I
cups
managers
yeah?
That's
the
that's
the
real
reason
like
that.
The
first
reason
why
helps
manages
CNI
providers?
Maybe
it's
a
decision.
Maybe
it's
not,
but
it's
certainly
a
ton
of
work.
Mike,
oh
I,.
A
C
It
somebody
else
maintains
that
that's
beneficial
as
long
as
we
have
that
integration
point
which
I
serve
I,
think
what
they're
it's
point
is
right
as
long
as
we
have
a
way
that
we
don't
make
it
impossible
to
install
cube,
unison,
cube
proxy
and
CNI
and
I
think
that
that's
a
nice
way
to
draw
the
boundary
we've
defined
a
nice
interface
or
I.
Don't
know
it's
an
input
or
an
output,
but
an
interface
point
and,
and
we've
made
it
possible
to
create
a
great
system.
But
we
haven't
blown
our
scope
either.
M
M
A
There's
anybody
like
the
goal
would
be
able
to
be
able
to
ideal
you'd,
be
able
to
spin
up
a
cluster
without
having
to
use
a
predefined
kind
of
cluster
CTL
tool
you
should
be
able
to
use
like
the
goal
is
that
other
kind
of
installer
projects
or
cluster
management
projects
could
also
adopt
cluster
API,
so
you
could
potentially
run
say,
cubic
horn
and
get
a
cluster
API,
providing
cluster
or
cops
and
the
same
thing
you
wouldn't
have
to
use
the
cluster
API
provided
binary
to
use
the
project.
Okay,.
M
G
H
G
G
Allow
me
with
like
one
bit
of
yeah
mole
to
say:
I'm
gonna
get
my
minimally
functional
cluster
with
15
deployments
and
pods
added
to
it,
and
what
Jason
suggested
is
that
we
define
that
minimally
functional
cluster
and
call
it
a
day
for
now,
and
we
can
continue
to
discuss
this
over
time,
but
at
least
as
we
mature
from
v1
alpha
ones
of
e
1,
alpha
2
as
part
of
this
requirements
discussion
anything
beyond
a
minimally
functional
cluster.
However,
that's
defined
is
out
of
scope
for
this
next
effort.
All
right.
Thank
you.
N
G
Don't
know
that
we
can
reasonably
answer
that
question
until
we
have
a
better
sense
for
the
requirements
that
we
all
agree
to
and
then
the
won't
break
things
out
into
the
teams
working
on
the
feature
caps,
but
I
mean
we.
We
need
a
an
agreement
of
requirements.
We
need
a
plan
for
how
we
can
break
that
down
into
into
different
releases
and
I.
Don't
have
an
answer
for
that
today.
I
do
see,
Derek
has
his
hand
up
a
sheet.
It
will
follow
up
before
we
go
over
to
Derek
no.
N
G
E
Present
a
model
that
maps
to
the
cluster
API
and
then
your
point
on
saying:
cluster
API
is
just
a
minimal
set
of
functioning.
If
you
got
a
key
cluster
like
a
feel
like
those
may
be
in
conflict,
because,
let's
say
we
here
at
Red,
Hat
go
and
modelled
Equestria
cow
in
front
of
our
open,
shipped
environment
like
if
our
install
includes
monitoring
out
of
the
box,
like
is
that
I
guess
I
would
be
worried
to
say
that
we
are
in
violation
of
like
the
spirit
of
the
cluster
API.
E
O
G
G
Okay,
so
we
have
about
five
minutes
left
in
the
office
hours.
I
am
happy
to
continue
with
anyone
else.
Who
is
interested
in
continuing
the
discussion
beyond
the
top
of
the
hour,
whether
it's
on
this
student
or
a
different
one.
So
that's
it
recently
for
another
five
minutes,
any
other
specific
things
that
anyone
wanted
to
bring
up.
H
Yeah,
just
from
this
de
special,
it
seems
like
we
kind
of
need
a
little
bit
of
structure
and
try
to
scoop
particular
sections
and
layers
in
here.
It
seems
like
we're
talking
about
all
sorts
of
different
things
in
this.
So
far,
we
even
explored
all
the
different
routes
and
I'm
not
sure
this
is
best
use
of
everyone's
time.
H
So
I
think
it
would
be
helpful
if
we
could
kind
of,
like
you
know,
discuss
some
basic
use
cases
and
agree
on
those
and
then
extend
beyond
that
into
some
details
there,
and
once
we
have
that
done
Denis
who
can
find
ourselves
in
a
slightly
better
place,
because
right
now
we're
gonna
put
him
into
all
sorts
of
different
heritage.
It's
simply
little
challenging
to
to
grasp
great
game.
P
H
For
example,
right
sort
of
like
there
are
discussions
about
cloud
providers
and
ayahs
features
and
stuff
and
on-prem
use
cases,
but
they're
also
like,
but
then-
and
there
is
also
a
lack
of
discussions
around
like
we
haven't-
touched
at
all
on
how
prostrate
guide
maps
out
to
it
too.
Like
poofy
providers
such
as
the
Kiev
Jiki.
H
J
Perhaps
how
does
the
Sun
as
a
strawman
to
get
going
here
is
please
review
the
document
and
please
add
your
details
to
the
doodle
and
Andy
will
try
to
follow
up
the
time
for
us
to
actually
go
through
the
document
in
detail.
But
the
purpose
of
going
through
the
function
requires
is
not
to
dive
so
deep
into
the
details
of
the
leads
of
particular
things,
but
to
pop
up
at
a
high
enough
level
that
we
capture
what
is
where's
the
goals
and
what
are
the
non
goals
for
the
iteration
for
being
one
alpha
2?
J
We
could,
we
could
potentially
go
into
the
details
and
get
lost
in
inspecting
your
belly
button
lint
for
the
next
like
10
days
easily.
But
the
objective
of
this
effort
is
to
concretely
summarize:
what
are
we
going
to
try
to
do
from
a
high
level
perspective?
And
what
are
things
are
going
to
say?
This
is
a
demarcation
line.
This
is
where
cluster
API
stops
or
the
machines,
if
you
want
to-
and
this
is
where
other
tools
begin-.
G
Thanks
Tim,
so
yes,
I
would
propose
that
we
adjourn
now
everyone
please
take
time
to
read
the
document.
Add
your
comments
as
Tim
suggested.
As
of
right
now,
the
doodle
is
showing
24
hours
from
now
2:00
p.m.
Eastern
Time
as
the
most
popular
convenient
time
for
everybody,
but
we
can
continue
to
discuss
when
over
slack
or
email,
but
for
right
now
it's
looking
like
two
p.m.
Eastern
Time
tomorrow.