►
From YouTube: SIG Cluster Lifecycle - Cluster API 21-10-27
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,
everyone
and
welcome
to
the
classroom
office
hours
meeting
today
is
october
27
2021..
We
have
a
packed
agenda
before
we
start
just
a
couple
of
notes
like
we
do
have
some
meeting
etiquette.
If
you'd
like
to
speak
up,
please
use
the
reigns
and
feature
you
can
find
it
on
the
reaction
on
in
your
tomb
window
and
if
you
have
any
topics,
build,
please
feel
free
to
add
it
to
the
agenda.
A
You
need
to
join
the
sickle
child
life
cycle
group,
which
is
at
the
top
here
to
edit
and
let's
get
started
with
introductions.
Does
anybody
want
to
say
hi
before
we
start.
A
Nobody
all
right
seems
nobody
wants
to
introduce
himself.
So,
let's,
let's
get
going
psas
one
of
the
biggest
businesses
that
that
I
have
for
today
is
that
the
new
contributing
guidelines
and
policies
have
merged.
So
there's
a
couple
of
changes
that
we
put
in
here,
which
is
like
with
the
1.0
release.
We
haven't
updated
the
contributing
night
before
so
consensus.
A
Was
that,
like
you
know,
we
put
a
warning
that,
like
this
product,
doesn't
follow
like
the
go
guidelines
for
compatibility
requirements
for
one
point
x,
which
is
in
line
with
what
kubernetes
does
the
we
have?
We
we're
not
planning
major
releases,
but
we
plan
minor
and
patch
releases
going
forward.
A
We'll
have
many
more
minor
releases
than
patch
releases
and
patch
releases
will
be
only
patch
releases
so
like
there's
not
going
to
be
any
new
features
or
like
yeah
like
any
features
like
additions
or
new
feature
gates,
etc
in
patch
releases,
but
they're
all
like
reserved
for
miners.
Miners
can
also
include
breaking
api
changes
to
the
code
base,
but
the
api
in
terms
of
like
what
we
exposed
to
kubernetes
like
we'll,
follow
the
kubernetes
standards.
A
There's
like
comprehensive
application
policy
and
change
guidelines.
Not
everything
in
here
applies
so
we'll,
because
these
were
written
for
query
types.
So
we'll
follow
like
whatever,
like
we
didn't
think
on
a
case
by
case
basis
for
custom
resource
definition,
but
most
of
it
does
applies
like
I
would
say,
150
to
80
applies,
and
then
we
added
also
cli
guidelines,
which
is
like
we.
We
guarantee
the
same
as
the
price,
the
production
pulse
for
cli
flags
and
we'll
we'll
allow
breaking
changes
after
eight
months
or
two
releases.
A
One
of
the
biggest
things
that
we
have
in
here
now
is
supported
guarantees
and
we
have
actual
dates
on
when
something
is
end
of
life
and
we'll
stick
to
this
day.
These
days
were
picked
from
the
last
release
when
a
new
minor
release
was
introduced
as
an
example
that
released
1.0,
I
think,
was
six
months
before
this
date,
and
so
we
just
just
put
the
six
months
on
alpha
four
in
this
case
and
any
questions
of
our
before
and
move
on
to
the
rest
of
the
changes
that
we
have
here.
B
So
the
idea
is
that
we
want
to
make
it
easy
for
new
people
to
step
up
in
the
project
and
one
of
the
things
that
that
we
are
going
to
to
do
so
is
that
we
we
kind
of
divided
the
project
in
in
in
sub
areas
and
each
sub
areas
now
as
its
own
owners
file.
So
people
can
start
taking
responsibility
into
into
copy
by
basically
dealing
with
a
sub
part
of
the
project
and
non-data
code
base,
which
is
getting
huge.
C
A
Yeah,
that's
like
a
good
change
that
it
was
merged
right
or
not.
Yet
I
think
so.
A
I
think
that's
mostly
it
like
we'll
kind
of
decide
like
later
on,
like
what,
if
you
want
to
keep
six
months
going
forward
or
do
one
year,
it
just
depends
like
you
know
how
we
feel
about
it
right
now,
like
it's
just
set
to
six
months,
so
so
go
ahead.
D
Yeah,
the
other
thing,
I
guess
that
we
added
is
in
finding
things
that
need
help
right
above
we,
this
isn't
anything
new,
but
we
just
like
reiterated
that
if
you're
looking
for
work,
the
best
way
to
look
and
is
in
the
current
release
milestone,
so
we're
going
to
try
to
keep
the
milestone
have
like
all
the
stuff
that
is
prioritized
and
accepted
for
the
next
release
doesn't
mean
that
we're
committing
to
that
work.
D
It
just
means
that
we
think
that
would
be
good
work
to
do
for
the
next
release,
and
so
getting
that
work
done
depends
on
all
of
us,
picking
it
up
and
getting
it
done.
So,
if
you're
a
more
experienced
contributor-
and
you
not
necessarily
looking
at
good
first
issues,
the
next
step
to
look
is
the
milestone.
D
Yeah
and
then
also,
I
think,
alberta
added
a
note
if
you
can
scroll
up
it's
like
right
above
versioning
yeah
right
there,
yeah
alberto
added
a
note,
also
about
contributions
and
help
coming
in
the
form
other
than
code.
I
think
code
is,
you
know
great,
but
we
also
always
need
help
with
things
like
moderating
office,
hours,
issue,
triage
debugging,
flaky
tests,
etc,
and
so
all
of
that
is
really
appreciated.
If
code
is
not
your
thing,
we
welcome
your
help
in
any
way,
shape
or
form.
A
Awesome
this
is
super
exciting
and
I
think
it
will
show
as
the
health
of
the
project
like
and
matures,
and
we
onboard
new
contributors
over
time,
thanks
all
for
participating,
giving
feedback
on
this.
This
is
great
to
see.
We
probably
like
include
part
of
these
things
into
the
book
at
some
point
like
embedded
I'll
or
we're
going
to
appear
later,
unless
someone
else
wants
to
go
for
it.
E
D
Thanks
yeah,
so
I
guess
we
already
just
touched
on
that
briefly,
but,
as
fabrizio
mentioned,
there's
an
issue
open
about
creating
sub-areas
of
ownership
in
the
project.
So
what
we're
starting
with
right
now
is
the
docs
and
tests
and
then
also
have
like
a
few
for
like
the
core
controllers,
like
kcp
and
bootstrapper,
etc,
and
with
that
there
are
a
few
pr's
open
for
adding
several
folks
here
to
like
different
areas
of
ownership.
So
these
are
gonna
stay
open
for
a
week
for
lazy
consensus.
D
A
Awesome
thanks
folks,
and
thanks
for
stepping
up
as
well
to
alberto
and
stefan
and
nadir,
and
if
anybody
else
like
want
put
their
name
out
like,
please
feel
free
to
open
a
pr
and
also
like
to
read
the
contributing
guideline
on
like
how
to
to
step
up
and
like
what.
What's
expected
of
you
as
well.
A
So
for
the
open
proposal
like
it
seems
like
we
probably
need
to
at
some
point
like
revisit
the
things,
because
I
mean
this
is
like
a
not
zero
for
x
anymore.
It's
just
like
one.
All
of
all
of
it
will
be
in
one
point,
one
point:
one
in
a
one
point
x
release,
I
guess
so
like
we're
not
necessarily
targeting
anymore,
like
a
specific
release
for
it,
but
it's
more
like
when
it
gets
merged,
gets
implemented
and
then
like
it
will
be
put
out
in
the
next
x
release
right.
A
I
think
we
can
disassociate
like
a
proposal
from
necessarily
a
specific
milestone.
It's
more
like
about
like
the
time
frame.
You
won't
want
to
do
it.
So,
oh
does
anybody
disagree
with
that
like
before
I
remove
these.
F
A
Awesome,
okay
and
there's
a
bunch
of
things
in
here
and
like
we'll
talk
about
briefly
about
the
road
map.
Later,
oh
there's
like
a
lot
of
things
to
discuss.
So
why
don't
we
go
and
just
like?
Go
to
the
first
discussion
topics
define
you
have
the
first
two.
C
Yeah,
I'm
making
click
so
first
one
is
mostly
fi
and
we
did
a
little
debugging
session
last
week
on
friday,
just
to
show
how
to
debug,
enchanters
and
controllers
and
stuff
intelligent
and
there's
a
video
and
a
heck
empty,
how
to
reproduce
it
and
shout
out
to
nadir.
He
implemented
improvement
to
our
tilt
file
so
that
you
know
can
also
debug
controllers,
where
till
just
right
filled
up
and
some
connect
to
remote
stuff.
So
everything
pretty
easy
now,
so
just
try
it
out
and
guess,
fingers
somewhere.
C
If
it
doesn't
work
any
comments,
if
not
I'll
just
go
to
the
next
one.
C
Okay,
good
next
one
is
also
justify,
and
I've
opened
the
tracking
issue
for
the
cluster
class
patch
implementation.
There's
also
code
workflow
in
the
issue
linked.
C
C
For
mostly
for
for
the
fundamentation,
where
we
apply
the
patches
during
the
reconciliation
of
our
cluster
class,
and
we
did
a
code
walkthrough
for
that
one,
the
code
evolves
a
bit.
We
do
another
one
tomorrow,
just
leaving
it
slack.
So
if
someone
was
joined,
I'm
commenting
on
the
issue,
etc.
C
I
probably
create
a
few
more
issues
and
some
of
them
have
wanted
some
time,
maybe
this
week
or
next
week.
So
if
someone
wants
to
pick
up
the
work
or
just
follow
it,
that's
from
us.
A
All
right,
sono,
like
load
balance
endpoint
for
cluster
control
plane
using
plugins
like
cube.
H
Thanks
yeah,
I
gated
this
ticket
a
few
days
ago.
I
just
wanted
to
bring
this
up
here
to
apply
the
audience
and
get
some
feedback
see
if
we,
this
is
something
that
people
is
interested
in
or
maybe
not.
This
is
basically
to
expose
auto
scaling
as
a
feature
in
cluster
class.
H
That
would
have
two
different
parts.
One
is
to
expose
scalable
resources
to
the
auto
scaler.
So
basically,
that's
that's
the
easy
one,
basically
adding
the
mean
and
max
label
for
for
machine
deployments.
But
then
the
thing
that
I
think
is
probably
more
complicated
is
how
we
want
to
expose
the
cluster
autoscaling
itself.
So
for
these
labels
to
to
actually
means
something,
there
has
to
be
a
cluster
scalar
running
in
the
cluster.
H
So
guess
we
have
two
different
alternatives.
One
would
be
to
let
the
cluster
class
controller
to
run
a
deployment
that
would
run
and
manage
the
class
auto
scanner
autoscaler
binary
and
the
other
one
could
be
that
we
assume
that
that's
up
to
the
user-
and
you
know
we
only
expose
the
mi
and
max
labels
in
the
machine
deployments.
And
then
we
say
hey.
If
you
are
running
the
class,
auto
scaler,
that's
gonna
work,
that's
gonna
do
something,
otherwise
it
won't.
F
Right
I
mean,
I
think
this
is
a
cool
idea,
that
kind
of
falls
in
line
with
the
you
know,
including
the
machine
health
checker
in
the
cluster
class.
F
Like
I
think
these
are
that
I
had
this
question
a
similar
question,
like
you
know
how
extensible
is
the
cluster
class
gonna
be
for
life
cycle
type
operations,
and
I
think
you
know
you
hit
on
something
here
that
sounded
interesting
to
me,
alberto,
which
was
like
it
would
be
interesting
if,
if
like
in
the
cluster
class,
a
user
could
say
yeah,
I
want
auto
scaling,
or
maybe
they
want
some
special
feature
turned
on
and
then
have
the
ability
to
provide
a
manifest
that
could
be
associated
with
whatever
needs
to
be
deployed,
whether
that's
like
you
know
some
operator
or
the
actual
device
itself
or
something
I
mean.
F
B
First
of
all,
it
is
something
that
is
interesting,
but
I
I
see
a
slight
difference
between
with
machining
check.
Machine
check
is
a
core
type.
Autoscaler
is
kind
of
an
external
type.
B
Second,
I
think
that
if
you
look
at
the
problem
that
that
mike
was
talking
about
so
adding,
basically
an
external
component
which
is
related
to
the
cluster
life
cycle,
I
think
that
in
this
this
category
also
csi
and
cpi
fall
in,
and
so
maybe
at
least
at
first
level.
In
my
opinion,
the
auto
scaler
falling
into
another
topic,
which
is
the
cluster
add-on
topic.
I
opened
an
rfe
because
I
think
that
is
a
topic
for
the
roadmap
discussion
that
hopefully
we
will
have
later
in
the
meeting,
but
yeah
that's
my
opinion.
H
Yeah
that
makes
total
sense
to
me,
for
you
too,
I'm
not
opinionated
on
on
the
technical
implementation
for
this,
but
I
think
it's
a
feature
that
is
generally
very
appealing
to
users.
So
hopefully
we
can
find
a
way
to
make
it
easier
for
them
to
to
run
it,
but
yeah.
A
One
question
that
I
had
is
like:
what
are
we
trying
to
expose
the
on
the
machine
class
side
or
sorry
cluster
class
side
on
for
machine
deployments
here
like?
Is
it
just
like
the
min
and
max
parameters?
Thing
is
like
to
expose
something
that
doesn't
work.
If
you
install
something
else,
it's
not
a
great
user
experience,
so
I
would
expect
that
we
would
have
kind
of
a
way
to
just
say,
like
you
cannot
set
these
unless
you
install
something
else.
A
F
Mike
I
mean
I
guess
like
if
we're
just
talking
about
like
min
and
max
for
the
different
you
know
like
say
I
want.
I
want
to
have
this
machine
deployment,
and
I
wanted
to
have
this
min
and
max.
You
know
those
things
are
just
applied
as
like
annotations
to
the
you
know
from
the
auto
scaler
side.
That's
all
it
looks
for
so
that
it's
pretty
light
and
if
we're
talking
specifically
about
the
auto
scaler,
I
think
we
wouldn't
like
where
this
could
get
really
messy
is.
F
If
we
somehow
tried
to
include
in
the
api
a
way
for
users
to
deploy
the
cluster
auto
scaler,
because
then
that
gets
into
all
the
kind
of
mess
around
what
options
do
you
provide
to
the
auto
scaler?
What
are
those
kind
of
things,
so
I
think
like
focusing
it
only
on
the
cluster
api
side
of
things
probably
makes
more
sense
if
we're
going
to
expose
it
at
all.
A
A
All
right
nadir,
you
have
the
next
one:
stronger
provider,
contracts.
G
Yeah,
so
we've
been
doing
a
bunch
of
testing
downstream
and
some
things
have
emerged
hold
on.
Let
me
turn
my
video
on
yeah,
so
there's
two
ones
from
sig
windows,
which
is
around
I'll.
Take
that
one
first,
because
that
one's
slightly
easier,
I
guess
well,
no
they're,
both
annoying,
so
windows
needs
short
machine
names
and
that's
to
do
with
the
fact
that
when
you
join
a
machine
to
active
directory
in
windows,
it
uses
an
ancient
win32
api.
G
Even
though
active
directory
is
perfectly
fine
with
longer
names,
the
api
in
windows
isn't
so
there's
been
a
request
from
the
sort
of
sig
windows
lot:
jay
and
manly
to
essentially
have
shorter
machine
names.
Ultimately,
this
is
the
responsibility
of
the
provided
infrastructure
provider
to
create
a
machine
name
short
enough
on
that
required
infrastructure
that
would
work
for
windows.
G
G
I've
heard
this
a
lot
from
customers
and
there's
multiple
ways
you
can
do
do
this
there's
essentially
two,
if
you
think
about
there's
two
sort
of
ports,
there's
one
on
the
cluster
resource,
that's
most
often
used
by
the
infrastructure
provider
to
provision
the
load
balancer
and
then
that
load,
balancer
endpoint
port
will
be
the
one
that
is
specified.
G
You
can
also
change
the
local
advertising
port
for
the
api
server
running
on
the
individual
node,
and
each
of
the
providers
have
done
something
slightly
different.
G
Resphere
is
a
special
case
because
there
is
no
load
balance
construct,
so
the
only
way
to
set
that
is
through
the
control
plane
on
aws
kappa
will
respect
changing
the
port
on
the
cluster
resource,
but
assumes
the
api
server
running
on
instance,
is
going
to
continue
running
one
six,
four
four
three
and
on
azure
it
assumes
that
if
you've
changed
it
in
the
cluster
resource,
it's
also
changed
on
for
the
api,
71
node
and,
I
believe,
that's
done
by
design.
G
Although
I
would
like
some
from
the
capsi
lot
to
comment
on
that,
but
I
think
it's
to
do
with
the
hairpin
that
situation
or
the
lack
of
it
for
azure.
Basically,
it's
really
inconsistent.
It's
really
confusing
for
end
users.
It
was
also
confusing
for
us
in
vmware,
like
trying
to
design
a
thing
downstream.
G
We
need
better
consistency
for
that
for
the
api
74.
I
think
that
might
be
a
breaking
change
for
somebody.
So
we'd
have
to
be
pretty
careful
about
it,
so
I'll
just
leave
them
there
for
now,
and
I
think
that
kai's
immediate
vince's
bit
next.
I
It
seemed
great
yeah,
I
think,
like,
as
you
said,
nadir
like
api
server
port
seems
the
immediate
one
where
I
think
like
it
is
something
valid
across
all
of
the
providers
for
yeah
for
for
load
balancers,
at
least
in
some
of
the
providers
like
vsphere.
I
We
don't
have
like
we
don't
have
one
by
default.
So
if
there
are
any
contracts
that
we
want
to
make
there,
we
need
to
ensure
that,
like
it
is
something
that
you
only
can
opt
in
and
be
optional.
A
So
I
think
this
person
dbs
report
for
sure,
but
in
a
margin
or
not
like
I'm
interested
like
to
see
like
how
we
would
enforce
this
contract
going
forward
like
we
have
talked
about,
we
do
have
like
a
contract
version
in
there,
which
today
matches
like
our
own
api
version,
although
like
we
have
talked
about
it,
also
to
kind
of
split
it
out
like
in
in
its
own
versioning
number.
A
A
Would
this
goes
kind
of
into
what
we
said
in
the
past
like
we
talked
about
conformance
for
our
providers
like,
but
how
do
we
test
for
conformance
when,
like
we
might
not
be
able
to
run
necessarily
that
conformance
test
like
within
cluster
api,
like
we
could
do
like
something
like
kubernetes
does,
which
is
like
you
run
your
own
conformance?
A
You
give
us
the
results
and,
like
we
say
your
conformant,
but
it's
a
lot
of
effort
to
get
there
as
well,
so
maybe
like
we
could
consider
something
in,
but
within
the
test
framework
that,
like
make
sure
that,
like
all
the
box
are
checked
and
like
we
can
put
it
in
in
test
grid
and
make
sure
that
those
things
work.
But
we
need
to
strive
for
a
better
user
experience
which
is
consistent
across
all
providers.
A
I
Seen
yeah
one
note
for
for
conformance,
I
think
like
say
cloud
provider
has,
I
think
something
that
is
like
that
has
a
pretty
good
experience
at
least
developer
experience
for
maintainers,
which
is
basically
like,
like
conformance
jobs,
that
are
basically
implemented
by
the
providers
and
reported
like
through
just
grid.
I
don't
think
like
it
makes
sense
to
run
them
in
cluster
api,
proper.
G
Maybe
there's
another
kind
of
worm,
so
something
I
was
thinking
about
is
like
what
so
things
about
like
feature
gates
or
like
say.
Well,
maybe
what?
G
If
we
come
up
with
a
thing
in
cappy
and
it's
not
yet
implemented
by
infrastructure
provider,
it
might
be
some
good,
some
capabilities
mechanism
that
you
could
expose
to
say
and
then,
like
this
infrastructure
provider,
supports
this
feature
and
then,
if
it
doesn't
support
that
feature
and
you
try
and
use
it
in
the
cluster,
then
like
surface
that
as
an
error
like
it's
not
going
to
work,
because
it's
not
it's
not
supported
in
this
input
provider.
A
Yeah
that
goes
then,
like
into
the
capabilities
topic
which
is
like
do
we
are
parts
of
like
a
contract
made
optional
and
like
how
do
we
detect
that
and
tell
the
users
like
hey?
You
can
set
this
with
with
this
provider,
because
it
just
doesn't
support
right,
like
that.
That
could
be
like
one
of
the
things
codifying
all
of
these
requirements.
It's
gonna
be
tough,
honestly,
like
it
requires
a
whole
cap
and
proposal
process
for
sure.
B
I
I
only
have
a
comment
and
I
think
that
software
could
help
in
the
discussion
going
forward.
So
I
think
that
it
is
important
to
try
to
better
define
what
is
content
and
what
is
api
version.
So
I
think
that,
at
least
in
my
mind,
the
api
version
is
the
types
or
the
behaviors
that
kubernetes
offers
to
the
that
copy
offers
to
the
external
world.
B
Instead,
the
contract
is
the
the
type
and
the
fields
and
the
behavior
that
copy
expect
from
the
providers,
so
one
is,
is
from
copy
to
the
external
world,
the
other
is
between
providers
and
copy,
and
we,
if,
if
we
can
write
down
these
definitions
somewhere,
I
can
take
an
action
item.
This
will
help
discussion
going
forward,
at
least
if
we
agree
on
on
that
topic.
J
Yeah
so
quick
one
here,
so
I
put
in
a
an
amendment
to
the
proposal
and
a
pr
at
the
cluster
class
proposal
in
order
to
add
machine
health
checks.
So
what
I've
done
is
actually
included
the
spec
at
kind
of
multiple
levels
in
the
cluster
class,
so
it
can
be
defined
in
the
actual
cluster
class
and
that
will
be
created
for
each
cluster.
Stand
from
that
cluster
classes
as
a
way
of
currently
the
ux.
Is
you
create
clusters
using
your
cluster
class
and
then
for
each
cluster?
J
You
create
you
have
to
create
new
machine
health
checks
based
on
the
labels
or
whatever
this
lets.
You
create
it
all
at
the
same
time
using
the
reconciler
so
yeah.
So
if
people
can
take
a
look
and
review
it
and
come
out
with
ideas,
because
there's
a
couple
of
sticky
points
in
there,
so
yeah
that'd
be
good
thanks.
A
Awesome
thanks,
keeling
folks
would
definitely
like
to
look
at
this
one.
If
you
have
time
it
should
be
pretty
concise,
but
it's
like
87
edition,
oh
yeah.
This
would
be
great
to
definitely
add
it
to
cluster
class.
A
Before
we
go
to
roadmap,
I
think
sonos
here,
no,
no.
I
saw
that
before
okay,
so
some
folks,
like
talked
about
like
building
a
roadmap
and
in
the
past
like
what
we
have
done,
we
we
put
out
like
a
cfp.
A
I
guess,
like
kind
of
you
know
or
like
that,
rfc
time
frame
for
the
next
release,
the
current
release
will
be
1.1,
so
there's
still
time
to
like
have
changes
in
there,
although,
like
for
the
roadmap,
we'll
probably
want
to
look
at
like
a
couple
quarters
so
like
half
a
year
like
and
say
like.
Oh,
these
are
the
features
that
we
commit
to,
and
these
are
the
folks
that,
like
want
to
work
on
these
features,
we
can
even
extend
the
time
to
a
year
time
frame.
A
A
We
can
collect
all
the
work
streams
that
we
have
somewhere
and
we
could
have
like
a
couple
of
people
like
driving
it
and,
from
you
know,
different
different
companies,
and
some
of
these
changes
could
be
also
released
blocking
potentially,
especially
if
they're
breaking,
but
we
need
like
clear
code
freeze
or
like
proposal,
freeze
dates
and
timelines
for
the
next
release.
So
maybe
this
is
something
that
we
can
also
put
in
the
contributing
night
as
well.
F
Mike
so
I'm
just
given
that
we
have
a
really
diverse
community
here,
I
kind
of
wonder
if
yeah
we
shouldn't
have
some
of
these
brainstorming
sessions
and
then
and
then
almost
kind
of
do
like
some
sort
of
voting
among
the
community
to
see
like
what
what
are
the
most
popular
things
that
we
would
want
to
like.
You
know
elevate
on
the
road
map
or
something
that's
I
mean
that's
just
kind
of
what
occurs
to
me.
A
Yeah,
that's
definitely
an
idea
we
can.
We
should
definitely
collect
these
things
somewhere.
I
guess,
like
not
sure
necessarily
where
do
we
want
to
do
it
in
here
or
like
do
we
want
to
have
like
an
issue
to
collect
them?
It
seems
like
the
meeting
now
will
probably
be
a
good
place
for
it,
and
maybe
we
can
vote
it.
D
We
could
use
a
discussion
in
github
to
like
create
like
suggestions,
and
then
people
can
upload
the
ones
they
like.
So
we
can
track
that
and
who
uploaded
what
I
like.
The
idea
of
collecting
you
know
ideas
and
then
trying
to
see
which
ones
are
most
desirable
for
the
community.
A
Okay,
so
it
sounds
like
we
might
need
like
a
discussion
temp
like
can
we
have
one
of
those
or
I
think,
there's
also
like
a
way
to
do
forms
now
or
like
it's
in
beta
and
ghetto
right?
Oh,
I
meant
the
like
discussions.
Tab
in
the
repo
yeah
yeah.
I
meant
what
it
means
like.
I
saw
that
there
was
like
some
ways
to
define
some
yaml
where,
like
you,
could
just
inform
like
forms
on
discussions
or
issues,
I
need
to
look
at
it.
It
wasn't
bad.
A
I
don't
know
if
I
don't
know
if
it's
enabled
or
not,
but
it
would
be
a
good
way
to
say
like
okay,
you
want
to
have
this
like
what
is
it
like
a
new
feature?
Is
it
like
a
small,
you
know,
how
would
you
rate
it?
What
areas
does
it
affect?
Is
it
a
breaking
npi
change
yeah,
something
like
that
would
be
good
cool
yeah
and
let's,
let's
set
that
up,
and
we
should
definitely
like
update
this
page.
Does
anybody
want
to
take
that
action
item?
Oh,
I
have
two
answers.
B
B
So
we
kind
of
keep
the
detail
of
the
implementation,
detailed,
all
the
discussion
in
an
issue
and-
and
we
keep
the
summary
in
the
discussion
topic-
I
I
would
like
to
avoid
that
the
discussion
thread
becomes
the
usual
discussion
about
technical
stuff
implementation.
B
A
Yep
that
works,
which
just
put
like
a
kind
of
some
sort
of
process
form
in
there
and
make
sure
that
folks
are
set
up
for
success.
Still
hello.
K
Justino.
Thank
you.
There
is
a
discussions.
Format,
q,
a
which
kind
of
gives
you
stack
overflow,
like
voting
on
answers,
which
I
don't
know,
could
be
statements
flowing
into
the
discussion
and
you
would
at
the
same
time
enable
everybody
to
vote
on
those.
I
don't
know
if
it
makes
sense
for
this
format,
but
it
just
came
to
mind.
K
K
And
so
the
the
idea
on
the
the
feature
of
that
q,
a
thread
is
people
could
give
input
on
how
they
would
want
this
to
work
and
at
the
same
time,
you
could
vote
on
that
input.
A
Sure
I
mean
either
way
it
works
for
me
ss.
As
soon
as
we
have
a
process
like
it
would
be
great.
To
like
add
some
text
in
this
like
this
is
how
we
would
accept
new
ideas
which
will
then
you
know
like
we
create
an
issue
like
if
they
get
accepted
or
someone
can
work
on
them.
It
would
be
also
good
to
have
a
disclaimer
in
here
that,
like
ideas,
are
just
ideas,
unless
someone
picks
them
up
and
that's
like
we're
not
necessarily
committing
to
them
and
but
yeah
like
maybe
that's.
A
Silence
is
acceptance.
Anybody
want
to
take
on
just
updating
the
roadmap
document.
A
The
while
it's
working
progress,
we
should
update
it
now,
like
with
the
new
naming.
Well
I
mean
this:
is
you
know
it's
released
so
like
at
least
for
v1.
It
would
be
great
to
like
collect
everything
that
went
in
there
into
the
1.0
release
like
we'll.
Just
do
1.0
the
one
beta
one,
and
maybe
let's
just
also
remove
the
dates
that
just.
C
A
And
I
also
don't
know
if
we
need
this
to
be
honest
like
at
this
point
I
could,
or
we
can
just
link
to
the
to
the
issues
because,
like
otherwise,
we
double
track.
E
Yeah,
I
know
this
was
discussed
in
the
last
meeting,
so
I
want
to
bring
this
up
again.
How
do
we
want
to
proceed
with
kp
operator
development?
We
can.
Can
we
make
it
a
separate
project
with
its
own
repo
and
release
cycle?
That
does
not
depend
on
cost
api.
A
Yeah,
that's
what
originally
proposed
like
last
last
week
meeting
the
the
reason
it
was
more
likely
to
just
like
enable
like
your
folks
to
move
like
way
faster
than
like
what
we're
doing
today
with
the
pr
process,
especially
again,
given
that
we're
get
we're
getting
like
lots
of
prs.
But
you
know
then
like
this.
This
other
repo
could
then
be
merged
into
cluster
api.
A
Later
we
have
done
that
in
the
past,
with
capti
and
copy
k
as
well,
and
I-
and
I
know
maybe
like
that-
that
also
could
bring
a
little
bit
more
visibility
into
the
work,
because
it's
not
like
hidden
into
a
branch.
A
We
can
keep
documentation
and
like
if
we
wanted
to
like
in
the
cluster
of
a
book.
We
don't
we.
We
don't
necessarily
need
to
recreate
like
the
whole
pipeline
for
the
book
as
well.
I'll
leave
that
up
to
whoever
wants
to
maintain
it
like,
for
example,
you
and
other
folks
yeah.
B
I'm
definitely
a
plus
one.
I
think
that
the
the
current
model
is
not
something
we
are
happy,
and
I
think
that
also
the
contributor
are
not
not
happy
with
it.
So
if
this
can
helping
and
get
things
moving
faster
and
and
give
a
more
a
satisfying,
contributor
experience
and
definitely
plus
one,
my
only
comment
is
that
in
in
the
current
pr,
we
are
talking
about
integrating
the
operator
with
copy,
maybe
less
other
node.
Sorry
in
the
current
proposal
that
the
god
merger
we
are
talking
about
these.
B
If
we
move
the
work
in
another
operator,
I
see
these
kind
of
being
postponed
due
to
a
taking
a
a
logistic
problem.
So,
let's
just
have
updated
the
proposal
and
and
write
down
that
the
integration
with
copy
is
kind
of
shifted
down.
The
roadmap
as
soon
as
the
operator
is,
is
stable
or
in
unsettled
shape.
E
A
Yeah
that
works,
I
mean
the
other
files
on
the
reviewers
that
will
still
be
kept
somewhat
in
sync,
we'll
just
add
to
the
list,
and
so
we'll
probably
get
ping.
A
Awesome
so
let's
kick
off
the
process.
You
might
take
like
a
little
bit
to
create
the
reboot,
but
we
just
need
to
open
an
issue
in
kate's
community
five
room
correctly.
It's
one
of
the
kids
repos
that
has
the
issue
for
templates
to
create
a
new
repo
and
what
can
get
the
sponsored
like
through
some
cluster
lifecycle.
Of
course,
you
know
probably
so
you
still
have
your
endless.
Did
you
want
to
say
anything?
A
No,
okay,
robert
go
ahead.
L
Hey
everyone
can
hear
me,
yes,
cool
all
right.
So,
a
number
of
months
ago
we
went
with
the
cncf
and
we
had
the
cluster
api
turtle
added
to
the
cncf
store.
I
don't
know
if
you
guys
have
had
a
chance
to
go
out
and
buy.
G
L
They're
they're
awesome.
We
originally
had
opened
a
conversation
with
them
to
actually
see
about
adding
cluster
api
to
the
50
family.
So
if
you're
not
aware
of
50.
io
microsoft
donated
a
character,
a
php
application
that
gets
added
to
kubernetes,
they
didn't
have
sort
of
a
formalized
process
around
that
recently,
charlie
mann
joined
the
cncf
as
a
content
strategy
manager
and
has
taken
over
sort
of
stewardship
of
the
50
family
and
they've
started.
Adding
graduated
cncf
projects
into
that
family.
L
More
recently,
they
added
the
linky
the
lobster
and
I
think
I'm
getting
the
names
wrong,
but
like
hazel,
the
the
hedgehog
for
helm,
but
they
also
wanted
to.
There
also
are
open
to
the
idea
of
adding
a
character
representing
cluster
api
to
the
fifi
family
as
well.
So
I
wanted.
L
To
sort
of
help
figure
out
name
of
the
character,
the
graphic
design
of
the
character
and
sort
of
helping
to
get
the
necessary
community
consensus
to
basically
go
back
to
cncf,
to
say,
hey,
everyone
has
has
approved
of
sort
of
this
character
representing
cluster
api,
also
figuring
out
how
we
wanted
cluster
api
to
be
represented
if
it
would
just
be
in
a
book
like
the
other,
50
sort
of
representations
or
if
we
wanted
to
try
a
different
content.
L
So
really,
this
is
more
about
like
how
do
we?
How
what
is
the
best
way?
You
all
think
to
get
that
consensus?
Should
this
be
treated
almost
like
a
robot?
We
just
talked
about
using
github
discussions
that
sort
of
thing,
but
what
would
be
the
best
way
to
get
sort
of
a
consensus
around
a
name,
graphic
design?
I
I
was
making
the
assumption
we
keep
going
with
the
turtle,
but
maybe
people
decide
that
no,
we
don't
want
to
go
of
a
turtle
or
something
else,
but
I'll
pause
there
for
comments.
M
First
of
all,
I
think
this
is
great.
I
can
share
with
you
how
we
did
the
cuba
dm
logo
agreement.
We
basically
had
someone
prepare
designs
and,
first
of
all,
we
decided
to
collect
ideas
from
people
in
a
google
doc.
Like
a
few
paragraphs
of
text,
everyone
providing
like
how
does
the
character
look?
Maybe
you
can
even
link
to
an
image.
M
Of
course
we
have
to
be
careful
to
not
violate
any
copyrights,
but
basically
a
google
doc
is
a
good
start,
having
potentially
a
couple
of
categories,
which
is
everyone
giving
ideas
about
the
name
and
the
other
one
is
like.
How
does
the
character
look
like
with
an
idea?
B
A
Awesome
so
let's
start
the
the
world
doctor
just
to
collect
like
some
some
like
names
and
then
or
we
can
also
use
discussion,
the
q
a-
and
I
could
just
do
upload
I'll
leave
that
up
to
you,
robert
and
look
at
me
like
you,
won't
want
to
do
it,
but
yeah
thanks
for
driving
this
like
this
is.
This
is
great
and
it's
it's
awesome
to
see.
A
Any
other
last
minute
topic.