►
From YouTube: Kubernetes SIG Cluster Lifecycle 20180718 - Cluster API
Description
Meeting Notes: https://docs.google.com/document/d/16ils69KImmE94RlmzjWDrkmFZysgB2J4lGnYMRN89WM/edit#heading=h.8nb4w63jh60f
Highlights:
- Official azure provider
- Issues for new contributors
- Vote on creation of https://github.com/kubernetes-sigs/cluster-api-provider-aws
- Congrats on creating https://github.com/kubernetes-sigs/cluster-api-provider-openstack!
- Multiple implementations for each provider in the same repo?
- Vote on creation of https://github.com/kubernetes-sigs/cluster-api-provider-gcp
- Rename ProviderConfig to ProviderSpec
- Update on the PR backlog
- Discussion of how to get kubeconfig for a cluster (ssh or not)
- Alpha exit criteria
- Introduction to new folks from Redhat
- Packet provider
- Provider Implementers Office Hours
A
B
Doing
a
yes
sure,
so
I
I've
been
working
on
this
for
the
past
about
a
month
or
two
here
at
platform.
9
and
it's
I
wouldn't
call
it
mature,
but
there's
some
good
functionality
in
it
at
the
moment,
with
the
ability
to
take
in
those
machine
and
cluster
specs
and
actually
create
resources
in
Azure
and
I
have
working
controllers
for
those
and
I'm
just
interested
interested
in
knowing.
A
Do
you
have
any
objections
to
so
I?
You
know
we
have
a
couple
of
agenda
items
coming
up
about
creating
the
provider
repos
for
different
implementations
right,
so
Jason's
got
an
issue
about
AWS
and
I've
got
one
for
Google
and
I
put
something
on
there
that
Tim's
created
one
in
the
last
week
or
so
for
OpenStack.
Do
you
have
any
objections
to
seeding
a
cluster
API
provider,
Azure
repo
from
the
existing
platform,
nine
code
and
then
sort
of
jumping
on
that
bandwagon?
When
you
guys
do
have
bandwidth.
D
So
we,
as
we
discussed
before
we'd
like
to
have
at
least
two
people
that
have
committed
to
working
on
the
project,
we're
firmly
from
two
organizations:
I,
don't
know
that
we
can
commit
to
working
on
that
in
the
timeframe
that
would
qualify
as
being
like
we're
working
on
that,
like
I
said
in
six
months,
we're
gonna
work
on
that
I
mean
I,
can't
I,
don't
know.
What's
gonna
happen
in
six
months.
A
E
C
Hey
guys,
this
is
my
new
is
Ashish,
and
this
my
first
time
joining
this
meeting.
I
was
curious
to
know
if
there
are
like,
if
there
aren't
like
open
issues
or
chunks
of
work,
that
I
can
pick
up
as
an
individual
and
work
on
in
my
spare
time
and
and
make
contributions
aren't
as
part
of
any
particular
organization,
but
as
just
a
developer.
A
Yes,
so
there
is,
if
you
go
to
the
cluster
API
repo
and
search
for
issues
with
the
Help
Wanted
table,
you'll
see
a
number
of
there.
Ten
right
now,
ten,
if
open
issues,
I'll
post
a
link
into
the
meeting
notes
where
people
have
said
like
here's
something
we
want
to
do,
but
I
don't
have
the
bandwidth
to
do
it.
If
someone
else
wants
to
come
pick
it
up
and
then
there's
also
another
label
called
good
first
issue,
which
is
maybe
a
better
place
for
sort
of
new
contributors
to
get
started.
A
So
there
are
a
number
of
those
in
the
main
clustering
API
repo,
if
there's
a
specific
environment
or
platform
you're
interested
in
working
on.
As
we
start,
sharding
off
things
like
open,
Sakon,
AWS
and
GCP
will
have
similar
lists
of
sort
of
first
issues
and
Help
Wanted
issues
in
each
of
those
repositories
as
well
so
I
face
it,
links
to
both
those
in
the
meeting
notes
which
is
linked
in
chat.
A
If
you
didn't
see
that
otherwise
I'll
link
it
again
and
go
ahead
and
take
a
look
at
those
and
see
if
there's
there's
somewhere,
you
want
to
get
started.
I
will
note
that
as
an
individual
you've
only
just
like
sign
the
CLA,
if
the
CNC
f
before
any
of
your
code
can
be
accepted.
So
you
want
to
make
sure
you've
checked
that
box.
C
C
A
All
right
so
back
to
Michael's
question
so
I
think
the
the
question
here
is
I
think
we
should
start
the
conversation.
We've
there.
A
number
of
issues
open
in
the
cluster
API
repo
for
creating
the
new
sort
of
provider,
specific
repositories
I
go
ahead
and
create
one
of
those
for
a
sure
and
we'll
see
if,
if
we
sort
of
meet
the
bar
of
having
sufficient
to
ownership
to
have
a
sig
sponsored
repository,
okay,.
B
A
B
F
A
Crick's,
so
that's
one,
which
is
jason,
has
an
action
item
which
is
sort
of
a
follow-on
from
yesterday's
see
closer
lifecycle,
meeting
about
transfer
of
ownership
to
to
Racing's
for
the
cluster
API
provider,
AWS
repository,
which
is
currently
in
his
personal,
a
personal
repo
one
of
the
requirements
for
us
as
a
sig
to
create
a
new
repository,
is
to
have
a
vote
via
lazy
consensus
that
we
actually
want
to
take
ownership
of
this
repository
Jason.
Do
you
want
to
say
any
other
words
before
we
initiate
voting.
H
Yeah,
the
only
thing
I'll
say
is
right.
Now
the
repo
is
just
bare
bones:
skeleton
implementation
of
the
provider,
there's
no
real
implementation
code
there,
it's
just
enough
to
basically
spin
up
a
no
op
cluster
controller
and
machine
controller,
and
the
goal
is,
is
because
there
have
been
multiple
kind
of
POCs
from
different
organizations
for
an
AWS
provider.
I
wanted
to
see
make
sure
that
we
can
kind
of
agree
upon
a
design
spec
before
we
kind
of
go
forward.
H
That
way,
we're
not
just
picking
one
of
the
existing
implementations
as
kind
of
the
starting
point
and
then
right
now
the
owners
file
and
the
owners
aliases
file
is
pointing
to
the
stakeholders
that
I've
identified
so
far.
So
if
there's
anybody
else,
that's
interested
in
collaborating
on
this
or
has
currently
been
working
on.
Something
please
reach
out
to
me
so
that
we
can
get
you
involved
as
well.
A
Thanks,
so
I'm
gonna
do
what
we
did
yesterday
and
the
saklesh
lifecycle
meeting
and
please
put
a
+1
or
abstain
or
put
a
minus
1
into
chat
for
our
lazy
consensus,
folks
for
adopting
the
cluster
API
provider
AWS
and
we'll
let
that
run
for
a
couple
minutes.
So
people
have
a
chance
to
open
up,
chat
and
vote
they
want
to.
In
the
meantime,
gonna
go
on
to
the
next
next
thing,
I
put
in
here
for
dims,
which
was
since
last
meeting.
B
A
Of
applause
and
thank
him
very
much
for
figuring
out
the
path
for
doing
that
and
sort
of
getting
the
ball
rolling,
I
think
it's
made
it
a
lot
easier
for
the
rest
of
us
to
make
progress,
and
so
I
just
wanted
to
thank
Tim's
and
also
point
people
in
that
direction.
If
you
are
interested
in
contributing
to
an
open
stack
implementation,
please
head
over
there
and
start
working
on
it
and.
H
E
Met
a
question
I,
don't
people
can
hear
me
about
if
we
assume
is
it
controller
gonna
be
tied
to
a
particular
like
bootstrap
tool
like,
for
example,
cube
ATM,
so,
for
example,
if
there's
one
that
uses
cube,
EDM
and
one
that
doesn't
use
cube,
ATM
are
those
gonna
make
two
separate
controllers
and
two
separate
repos
or
one
or
two
controllers
in
one
repo?
Or
do
you
have
any
ideas
about
how
that
might
be
structured.
D
A
Yeah
I
think
we've
tried
to
say
in
the
past,
as
we'd
like
to
you
know,
put
all
the
AWS
code
in
one
repo
and
there
can
be
multiple
implementations
in
that
repo,
but
it
would
be
nice
to
kind
of
keep
it
together.
We
can
share
vendor
dependencies
on
AWS,
client,
libraries
and
so
forth.
You
know
that
may
not
end
up
working
in
practice.
I
think
that
may
be
idealistic,
but
I
think
we
should
start
there
and
see
if
it
works.
E
H
H
E
I
think
I
think
it
did
I
think
we
can
I
think
that
is
a
great
position.
I
don't
have
any
objection
to
it,
and
I
was
more
just
worried
about
like
getting
the
name
right
now
for
where
we
intend
to
be
so
it's
it
is
what
we're
calling
it
a
controller
ahead
of
us
and
not
controller.
Yes,
cue
video,
which.
A
A
A
So
that's
the
goal
we'll
see
how
it
works
in
practice,
but
I
think
we
should
definitely
start
with
that.
That
n
decided
mine,
agree,
sweet
all
right,
I'm
gonna
move
this
next
one
back
up
because
it
seems
like
the
first
lazy
consensus
vote
has
finished.
So
we'll
do
the
second
consensus
vote,
which
is
sort
of
an
alignment.
The
same
thing
that
jason
said:
I've
created
a
seed
repository
for
cluster
API
provider.
A
So,
like
the
other
one,
we're
gonna
do
another
sort
of
lazy
consensus
vote,
we'll
paste
yeah
the
same
sturdy
thing
in
here
there
we
go
and
go
ahead
and
vote
on
that
if
you'd
like
to.
While
we
move
on
to
the
next
thing,
which
is
Daniel
P
our
number
for
14,
we
talked
about
this
a
little
bit
last
week,
so
perfect,
all
that
weren't
here
do
you
want
to
give
a
little
background,
but
then
we'll
try
to
actually
get
a
resolution.
Sure.
I
Yeah,
the
the
turn
of
it
is
that
a
cluster
API
started
with
a
provider
config
and
then
later
provider
status
was
added,
and
then
you
know
looking
back
at
the
typical
kubernetes
api
convention,
there's
a
airing
of
specs
and
status.
So
I
just
wanted
to
raise
the
question
of
whether
we
want
to
you
know,
update
the
original
name
and
change
from
provider
config
to
provider
spec.
Since
that
would
be
more
consistent
with
you
know.
The
kubernetes
api
is
conventions.
A
A
Just
want
to
make
sure
that
that
there
was
some
precedent
for
that
and
we
weren't
going
to
be
setting
a
precedent.
It
sounds
like
it
stutters
a
little
bit
to
me
when
I
think
about,
like
you
have
machine
spec
with
providers
back
underneath
it,
but
as
long
as
other
people
are
already
doing
that,
that
seems
fine.
D
D
A
So
component
config,
it's
like
a
kind
of
like
it
can
evaporate
where
it's
just
a
data
value,
it's
not
something
that
has
sort
of
desired
and
actual
State
right,
so
it
doesn't
really
have
a
status.
It's
just
a
blob
of
configuration
and
I
think
that
the
the
reason
we
named
it
provided
config
in
the
first
place
is
we
intend
it
to
be
the
same
way.
You'd
have
a
a
spec
for
a
machine
which
says
the
machine
should
look
like
this
and
then
here's
a
blob
of
configuration
inside
of
that
spec.
A
That
sort
of
defines
up
that
spec
is
now
I.
Do
agree
that
the
naming
is
kind
of
confusing,
because
we
have
machine
spec.
We
have
machine
status
and
under
machine
status
we
have
provider
status
right
which
so
then
the
naming
starts
to
become
confusing,
so
I
think
Daniels
right
that,
like
in
terms
of
history
kind
of
it
made
sense.
But
now
the
naming
is
out
of
sync
and
I
have
no
objections
to
sort
of
bring
that
naming
back
in
sync
at
this
point,
I
think
that
you
know
functionally
for
most
people.
I
A
F
Agree
we
should
change
and
then
I
just
want
to
kind
of
mention
that
a
little
bit
later
we're
talking
about
moving
API
to
alpha.
So
if
we
are
going
to
be
changing,
API
field
names
now
is
definitely
the
time
to
do
it
and
in
the
future,
once
we
move
to
alpha
or
need
to
be
a
little
more
weary
about
making
changes
like
this.
A
Know
him
soon?
Yes,
you
probably
listen
to
the
rest
of
the
meeting
before
starting
up
here.
Excellent,
alright.
So
next
I
just
wanted
to
give
a
quick
update
on
the
PR
backlog.
I
went
through
last
night
or
yesterday,
I
guess
and
tried
to
merge
a
bunch
of
stuff
and
other
people
to
merge
a
bunch
of
stuff.
We're
now
down
to
six
open,
PRS
I
believe
that
only
one
of
them
is
under
like
super
active
development,
which
is
the
validate
cluster.
I
saw
a
bit
from
that
last
day.
A
A
Closing
those
as
well
I
did
want
to
go
an
update,
I
think
I'm,
trying
to
do
a
little
a
better
job
of
grooming,
the
PR
backlog,
so
I
think
dimness
newer
might
have
been
on
the
hook
to
set
up
the
auto
assignor
I
haven't
seen
that
kick
in.
Yet
so,
in
the
meantime,
I'm
trying
at
least
once
a
week
to
go
through
my
cat
pass
and
make
sure
we're
keeping
the
queue
moving
so
happy
for
anyone
else
to
help
with
that.
Also
people
want
to
jump
on
that
and
try
to
keep
it
moving
as
well.
A
Let's
see
so
next
this
this
I
found,
while
going
through
issues
yesterday
about
the
so
just
to
jump
ahead
a
little
bit.
We
have
an
issue
about
alpha
exit
criteria.
I
started
going
through
the
list
of
things
in
the
Alpha
milestone
and
I
found
two
issues
that
DIMMs
asked
if
they
were
dupes
and
I
think
that
they
are
not
actually
dupes,
they're,
actually
sort
of
suggesting
two
alternative
solutions
for
getting
the
yeah.
A
Basically,
the
cube
config
from
a
deployed
master,
and
so
one
of
them
is
you
know
right
now
we
have
this
provider
specific
ssh
code.
We
should
make
that
provider
independent
and
you
know
maybe
use
like
the
golang
ssh
library-
is
to
actually
implement
ssh
to
fetch
keeping
thing
and
the
other
suggestion
is.
We
shouldn't
use
SSH
at
all.
We
should
figure
out
a
different
way
to
extract
this
thing.
I
think
we
obviously
I
don't
think
we
should
do
both
right.
A
We
should
pick
one
direction
and
move
forward
that
one
direction
and
and
have
providers
implement
the
same
thing
especially
was
SSH.
That's
going
to
become
sort
of
a
part
for
the
providers
to
implement
in
SSH
and
and
the
other
issue
Quran
says,
he's
not
sure
how
to
do
without
SSH,
but
he
thinks
we
shouldn't
use
SSH.
So
I
wanted
to
bring
this
up
and
see
if
people
had
thoughts.
We
don't
necessarily
need
a
resolution
during
this
meeting,
but
I
wanted
to
get
in
front
of
people
to
start
people's
brains.
E
E
A
That's
true,
so
I
think
what
we
need.
So
if
you
think
oh,
what's
in
the
cube
config,
we
need
the
endpoint,
so
the
IP
address
once
you
have
that
you
can
potentially
try
to
make
a
connection
to
get
the
serving
cert
and
hopefully
the
CI
cert,
and
then
we
also
need
client
credentials.
So
it's
it's
the
endpoints
to
actually
make
that
request
and
the
client
current
role
is
to
make
the
request
successfully
are
still
two
things.
We
need
to
extract.
G
F
One
of
the
things
we
had
talked
about
when
Robert
when
we
first
started
talking
about
how
to
solve
this
problem,
I
think
last
year
was
coming
up
with
some
sort
of
proprietary
protocol,
maybe
over
G
RPC
using
TLS.
That
would
allow
it
a
bootstrapped
machine
to
access
act
as
a
server
that
we
could
push
cert
material
and
the
endpoint
for
the
API
server
and
have
a
static
binary
that
the
Machine
bootstraps
wid.
A
F
J
One
problem
with
the
stage
or
this
approach
is
that
you
have
to
have
network
connectivity
to
the
nodes
and
in
some
cases,
when
they're
behind
that
will
get
mapped
or
some
other
means
and
the
controller
needs
to
help
network
access,
and
especially
if
you
are
like
a
bastion
just
ordered
not
to
do
SSH
for
more
secure
environments.
I'm,
not
sure
how
this
thing
can
work.
K
Yes,
so
I
think
specifically
when
the
worker
machines
are
in
the
private
network
and
controllers
are
running
outside,
then
it
becomes
really
a
problem.
How
do
you
SSH
into
it-
and
you
know
Moulton
already
mentioned
it-
would
go,
and
this
you
know
and
so
on,
but
one
of
the
way
could
be
generating
the
cloud.
Config
or
cloud
I
need
kind
of
configuration,
ed
the
master
took
at
the
controller
level
and
while
you
put
strapping
the
machine,
we
can
just
inject
that
and
then,
while
injecting.
K
We
would
know
that
the
cloud
config
knows
what's
the
end
point
of
the
PS
or
what
are
the
necessary
certificates.
What
is
a
good
script
token?
All
of
the
information
that
you
could
provide
anyone
when
there
are
other
configurations
for
the
machine
you
can
just
feed
those
thing
in,
but
I
am
not
sure
whether
it
will
be
supported
by
a
larger
set
of
operating
systems,
but
most
of
so.
H
I
think
the
main
problem
there
is
that
gives
you
input
to
the
machine,
but
it
doesn't
give
you
the
output
of
kind
of
the
bootstrap
machine,
particularly
the
cube
config,
that's
generated
from
spinning
the
cluster
up
and
I
hate
to
say
it.
But
one
option
that
we
have
there
is
to
actually
pre
generate
the
cluster
CA
and
pre
generate
the
admin
cube,
config
and
pass
that
into
the
cluster.
Create
is.
A
That
it
sounded
to
me
like
that's
what
hardik
was
proposing,
which
was
basically
generate
generated
externally
and
push
push
it
in.
You
know
via
something
like
cloud
in
it,
because
then
we
have
a
copy
of
it
that
we've
handed
off
instead
of
trying
to
get
it
back
right
instead
of
different.
It's
also
in
a
similar
sense.
What
Chris
was
saying:
it's
just
a
difference
of
how
we
push
it
in
which
is
if,
if,
instead
of
letting
Q
Badman
generate
or
whatever
is
running
on
that
machine
generate
that
thing
that
you
have
to
then
extract.
A
G
G
A
G
F
Yeah
and
I
don't
have
a
good
technical
way
of
getting
that
binary
on
to
the
server
other
than
you
know,
baking
it
into
the
image
or
you
know,
making
that
an
implementation
detail
that
we
don't
care
about,
but
again
yeah
it's
kind
of
six
in
one
half
of
those
in
any
other.
We
still
need
to
figure
out
how
to
get
that
on
the
server
as
well.
In.
A
Terms
of
difference
between
SSH
and
G,
RPC
I
think
the
issues
that
that
heartache
in
Martin
we're
talking
about
with
connectivity,
probably
apply
equally
to
both
of
those
G
RBC
I
think
has
a
clear
security
when,
in
terms
of
being
a
lot
more
restrictive
in
terms
of
what
you
can
do
over
that
connection,
but
we
may
still
end
up
with
problems
where
we
can't
actually
initiate
that
connection.
If
we're
in
one
of
these
situations,
where
you
have
a
bastion
or
a
trampoline
or
some
sort
of
NAT
system
in
between
you
and
the
node,
sorry.
E
It
was
actually
a
really
interesting
PR
into
cops
recently,
which
is
not
specific
to
cops
in
any
way
which
is
sort
of
trying
to
find
a
more
secure
alternative
to
the
xiulet,
a
certificate
bootstrapping
which
actually
has
you
know
obvious
parallels.
What
we're
talking
about
here
and
that
did
you
use
a
server
component
and
a
client
component
I
think
it
was
actually
raisin
Jason
and
rest
instead
of
G
RPC,
but
we
could
easily
like
look
at
that.
E
I'd
love
to
get
that
out
of
cops,
and
it's
great
that
it's
in
cup,
so
I
left
a
bit
like
you
know.
Have
it
not
be
specific
to
cops
right
that
it's
a
fairly
high
complexity,
piece
that
it
is
very
reusable
one
not
specific
to
cops
at
all,
and
that
would
then
establishing
that
so
basically,
Chris's
suggestion
that
we
have
a
a
well-defined
protocol
that
can
do
some
of
our
actions
that
we
want
to
do
like
passing
around
credentials
like
bootstrapping
certificate
chains.
I
think
makes
a
ton
of
sense.
K
Maybe
our
previous
discussion
about
having
multiple
implementations
for
different
use
cases
for
a
single
cloud
provider
right.
This
is
very
clear,
brings
in
there.
So
if
you
have
different
use,
cases
such
as
SSH
or
sis
no
SSH,
then
cube
EDM
versus
generic
way
of
doing
it
and
stuff
like
that,
then
maybe
that
mean
that
then
the
over
previous
conversation
makes
more
sense.
Then.
A
Yeah
I
think
one
of
the
things
was
this
is
as
James
mentioned.
This
is
related
to
one
of
the
sort
of
generic
function,
so
we
want
to
get
rid
of
to
make
cluster
cuddle
not
have
to
be
vendored
the
way
it
is
today,
and
so
we
we
do
want
to
have
a
way
to
at
least
part
of
the
temp
to
this
information
right.
So
I.
Don't
think
that
cluster
cuddle
cares
about
the
entire.
You
can
think,
although
it
can
be
wrong.
Maybe
it
just
cares
about
the
IP,
although
I
guess
that's,
that's
probably
sufficient.
A
J
Right
now,
you
you
can
generate
for
every
single
machine
a
boost
up
talking,
for
example,
and
this
is
the
only
thing
and
the
IP
address-
of
the
server
to
to
get
together
to
the
minions
presidentials.
So
it
can
boost
up
itself.
So
I
mean
doesn't
basically
two
things
that
you
need
for
a
successful
booster
and
you
can.
You
can
generate
per
machine
credentials
as
well
with
which
the
real
booting
and
because
you
have
full
control
over
the
life
cycle
of
that
machine.
E
E
I
am
certainly
in
favor
of
proceeding
the
that
that
is
what
cops
does
and
I
think
the
cop
says
is
sort
of
by
mistake,
because
we
have
to
store
it
somewhere,
persistent,
so
we
store
an
s3,
we
create
it,
we
put
in
s3
and
then
then
masters
actually
pull
it.
I
know
that
she
pulled
it
from
s3
I.
Don't
that
does
seem
like
a
simpler
workflow
than
spinning
up
a
machine
where
it
creates
a
certificate
which
we
then
extract,
but
at
any
stage
I
might
fail
and
we're
not
exactly
sure
where
it
say
all
right.
I
H
A
Think
you
have
a
really
good
point,
though,
because
I've
one
of
the
struggles
right
now
with
Cube
admin
trying
to
do
H
a
is,
if
you
have
multiple
masters,
how
do
you
actually
distribute
the
certain
material
across
this
machine
securely
right
and
systems
like
cops,
get
around
this
because
they
are
an
actor
at
a
higher
level?
That
is
a
lot
you
know
able
to
say
here.
My
true
master
machines
put
the
material
in
those
three
machines
know
whether
it's
the
s3
or
you
know.
H
And
I
can
speak
to
that
a
little
bit
the
weight.
The
way
that
we're
trying
to
do
the
EDD
cluster
management
4-h,
a
right
now
is
in
queue
bottom-
is
to
run
commands
against
that
that
first
at
CD
pod
to
be
able
to
query
data
about
it
and
then
join
additional
nodes
to
that
cluster.
So
you
don't
have
to
kind
of
proceed
and
transfer
that
data
around
we.
We
extract
it
from
the
running
pod
and
run
run
commands
against
that
running
pod.
I
Yeah
III
think
it's
true.
You
don't
have
to
proceed,
but
you
do
at
some
point
you
you
have
to
whether
you,
whether
you
generate
whether
you
generate
the
the
C,
a
certain
key
I,
guess
doesn't
matter.
You
could
do
it
at.
Let's
say
that
first
master
of
that
first
CD
member,
but
eventually
you
have
to
pull
that
out
and
transfer
that
and
I.
If,
if
we're
going
to
need,
I
had
to
see
that
you
know
if
the
orchestration
layer
is
going
to
need
to
have
a
you
know
copy
of
that.
A
All
right,
I
think
I'm
going
to
call
it
on
this
discussion.
For
now
we
have
15
minutes
left
and
a
few
more
agenda
items.
I,
don't
wanna
bring
this
up.
I
think
we've
had
a
really
good
discussion
about
it.
Hopefully
people
you
know
walk
away,
and
this
keeps
sort
of
turning
in
the
back
of
your
minds.
Maybe
we
can
come
back
to
this
in
a
week
or
two,
let's
see
if
anybody
has
any
brilliant
ideas.
A
The
next
thing
I
found
an
issue
that
had
been
open
quite
a
while
ago
about
been
during
kubernetes
gratis
into
the
cluster
API
repo
I
thought.
We'd
discuss
this
during
a
meeting,
but
I
couldn't
find
anything
in
notes.
So
I
want
to
bring
it
up
briefly
here
and
see.
If
anybody
wants
to
eat
this
issue
open
up,
we
can
agree
to
close
it.
A
J
A
A
Tim
I
added
a
couple
of
comments
here
that
I
wanted
to
dig
into
with
them,
but
I
don't
see
him,
so
maybe
we
maybe
we
can
discuss
that
part
next
week,
but
the
the
main
takeaway
here
is,
if
you're
interested
in
when
we
might
have
an
alpha
release
or
how
you
can
help
get
us
to
an
alpha
release
faster.
Please
take
a
look
at
this
issue.
Rob
put
down
a
couple
of
different
requirements,
some
of
which
we've
met
by
now
and
others.
A
We
haven't
and
then
also
a
link
to
a
milestone
for
github
issues,
and
there
are
currently
19
open,
github
issues
in
the
milestone.
The
idea
is
to
burn
that
down
to
zero
before
we
say
we're
ready
to
cut
it
release
it's
a
little
bit
circular,
because
the
eggs
are
criteria.
Issue
is
in
a
milestone,
so
it
can't
actually
be
zero
unless
we
actually
close
eggs
of
criteria.
One
two,
but
the
idea
is
basically
all
the
other
things.
The
milestone
are
things
that
we
think
we
need
to
do
before
we
can.
A
F
A
I,
don't
I
saw
an
issue
last
night
about
that
I
know
we
discussed
it
last
week.
We
should
make
sure
there's
an
open
issue
and
we
we
should
probably
put
that
into
the
milestone
that
we
should
figure
out.
We
should
we
do
figure
at
least
whether
we're
gonna
do
that
for
alpha.
In
addition
to
start
thinking
about
the
long
term
path,
right,
it'll
be
a
chunk
of
work
to
sort
of
move
us
back
right,
yeah.
G
A
A
Sure
we
can
adopt
that
one.
Let's,
let's
change
the
the
title
of
it.
I
think
the
title
right
now
is
sort
of
states.
The
goal,
which
is
we
want
to
be
using
more
recent
version
of
kubernetes
I,
think
it
might
be
easier
for
people
to
to
find.
If
we
also
say
like,
should
we
should
we
update
using
API
server
builder
or
social
series
and
I'll
add
that
to
the
milestone.
A
L
Hey
hello,
can
you
guys
hear
me?
Yes,
cool
yeah,
so
my
name
is
Albert
I
work
at
Red
Hat,
so
yeah
basically
just
wanted
to
show
up
here
to
say
hello
and
communicate
that
we
are
investing
efforts
on
the
classical
API
area.
So
we
are
happy
to
help
on
anything
relevant
so
just
to
give
some
context
a
Red
Hat.
We
develop
the
AWS
actuator,
which
is
kind
of
open
ship
as
Pacific,
and
we
just
started
to
work
on
making
it
more
generic.
L
So
we
are
definitely
happy
to
work
with
Jason
and
the
other
folks
interested
in
the
AWS
actuator.
So
I
guess
for
the
very
short
term
I
guess.
We
would
like
to
make
sure
that
there's
a
clear
path
to
start
to
collaborate
on
initial
design.
Spec,
yes
James
from
mentioned
before,
so
we
can
kick
up
the
discussions
and
start
to
materialize
in
Cena
in
a
common
repository.
M
D
N
A
Yep
awesome
welcome.
We
appreciate
having
you
guys,
join
I'll,
put
up
the
same
message.
I
said
to
a
sheet
earlier.
You
guys
can
search
the
repo
for
the
Help
Wanted
issues
to
find
places
where
people
have
have
already
sort
of
practically
said
like
these
are
things
to
jump
in
on
and
then
also,
if
you
look
at
the
Alpha
milestone,
those
are
things
that
I
think.
A
As
a
group,
we
should
try
to
focus
on
trying
to
burn
down,
so
we
can
cut
a
release
and
there
gonna
be
some
mechanics
there
about
like
how
we
kind
of
release.
What
does
that
look
like,
etc,
as
we
get
closer
that
we're
definitely
gonna
need
some
some
people
to
jump
in
and
help
with.
So
we
appreciate
having
you
guys,
join,
thank
you
and
last
but
not
least,
Edie.
We
got
six
minutes
for
you
to
talk
about
the
back
of
a
fighter.
O
Thank
you.
This
is
ed,
though
MIDI
from
packet
I'm,
looking
at
getting
a
scope
of
work
and
scaffolding,
information
and
requirements
and
specifications
to
do
a
provider
of
a
packet.
The
CN
CF
CI
work
is
done
at
packet
as
part
of
those
CN
CF
cluster,
which
is
hosted
at
packet.
So
there
could
be
potentially
an
internal
CN
CF
news
case,
pretty
much
right
away
for
that
for
the
work
of
that
code.
O
I
don't
have
any
code
ready
to
commit,
but
it
seemed
like
a
proper
idea
to
open
up
an
issue
in
the
cluster
API
rebo,
so
cluster
API
431
is
that
issue
and
I
would
welcome
anyone
who
shares
this
interest
to
collaborate
there.
We
can
collaborate
on
that
or
on
any
of
multiple
other
slack
or
communication
channels.
Thanks.
A
O
O
Hippie,
hacker
and
Lucia,
and
the
rest
of
the
bulk
who
I
have
been
have
been
added
and
have
done
quite
a
bit
of
work
to
do
bare
metal,
provisioning,
a
packet
I,
don't
know
the
distance
between
what
they
have
done
and
what
the
provider
cluster
API
provider
spec
is.
So
there
may
be
some
existing
work
that
could
be
leveraged
for
future
work.
Okay,.
O
A
O
A
O
A
A
Yes,
although
that's
going
to
take
early
when
we
put
the
meeting
ends,
so
it's
like
it's
probably
a
better
place
all
right
with
that
we're
just
about
out
of
time
thanks
their
own
for
coming
and
we'll
see
you
guys
all
again
soon.
Thank
you.
They
won't
see
you
on
the
net
thanks
Robert
right,
everyone.