►
Description
Meeting agenda: https://docs.google.com/document/d/1ushaVqAKYnZ2VN_aa3GyKlS4kEd6bSug13xaXOakAQI/edit#bookmark=id.sx9vlhps99mn
A
Welcome
everyone
today
is
Wednesday
the
12th
of
July
2023,
and
this
is
the
cluster
API
project.
Meeting
cluster
API
is
a
sub-project
of
kubernetes
sigs
and
as
such,
we
follow
their
meeting
guidelines,
which
basically
means
you
know,
please
be
kind
to
everyone,
and
if
you'd
like
to
speak,
raise
your
hand
and
I
will
call
on
you
at
the
beginning
of
our
meetings.
B
A
All
right
anyone
else
going
in
three,
two
one:
okay,
let's
move
on
with
the
rest
of
the
meeting,
then
so,
let's
look
at
the
open
proposal.
Readouts
I
think
we
just
have
one
open
proposal:
I,
don't
know
Richard
or
Fabrizio.
Is
there
any
update
here
that
we
need
to
talk
about.
A
Okay,
thank
you
all
right,
then.
Moving
on
to
the
regular
discussion
topics,
Nawaz,
you
have
the
first
topic
with
the
Cappy
1.5.0
release.
Please
take
it
away.
D
Thank
you.
So
we
released
gappy,
V
1.5.0
release
candidate
one
yesterday
and
the
release
notes
are
there
mentioned,
underneath
it
thanks
to
all
the
community
and
the
contributors
for
their
amazing
contributions.
Just.
A
You
awesome
thanks
Nawaz
another
another,
great
release.
Here
all
right,
Killian
you've
got
the
next
topic
about
adding
a
release
writer
wrong.
Please
take
it
away
all
right.
E
Yeah,
so
this
relates
to
the
release
team
So.
Currently
there
are
three
lead
roles
on
the
release
team
and
then
a
bunch
of
other
team
members,
so
there's
a
release,
lead
CI
manager
and
a
Communications
manager.
So
this
adds
a
forked
role
that
we've
had
in
the
past
two
release
teams
in
today's
actual
position.
So
it's
a
release
writer.
E
So
there
are
certain
tasks
that
have
to
be
done
by
somebody
with
right
access
to
the
repo
which
is
like
creating
the
release,
tag,
creating
the
release,
branch
and
actually
publishing
the
release.
We
looked
at
ways
of
getting
around
this
didn't
find
anything
suitable,
yet
so
for
the
next
release
cycle,
the
1.6
release
cycle
I'm,
proposing
that
we
just
make
this
a
formal
position
but
make
it
as
lightweight
as
possible.
E
So
the
idea
here
is
that
the
release
writer
is
not
a
member
of
the
release
team
and
that
they
don't
have
to
attend
meetings.
They
don't
have
any
other
tasks
inside
the
release
team,
their
only
job
is,
they
should
be
available
on
release
days.
They
should
know
when
the
release
days
are.
E
They
should
be
in
contact
with
the
release
lead
to
do
these
mechanical
tasks
of
actually
writing
the
tags,
creating
branches
and
Publishing
releases,
so
yeah
it'd
be
good
for
if
we
get
more
eyes
on
this
for
from
people
who
are
in
the
release,
team
now
have
been
in
previous
release.
E
Teams
are
involved
with
releases
just
to
make
sure
that
this
is
suitable,
but
I
think
what
this
is
doing
is
just
making
concrete
what
we
already
had,
so
that
there
isn't
confusion
about
this,
we're
all
going
forward
and
hopefully,
at
some
point
in
the
future.
We
can
get
rid
of
this
all
together.
A
Okay
cool,
so
I'd,
say:
Cecile
has
got
her
hand
up.
Please
Cecile
go
ahead.
F
Yeah
I
think
it
sounds
good
to
me
to
formalize
what
we're
doing
right
now,
although
I
think
this
person
has
to
be
one
of
like
very
few
people
right,
it's
like
three
four
of
us
that
actually
have
access
to
push
tags,
so
it's
I
think
it's
hard.
If,
at
the
beginning
of
the
cycle,
these
people
might
not
know
that
they're
going
to
be
available
exactly
at
that
time
on
those
days
like
they
can
prioritize
being
available.
But
you
know
people
have
things
come
up.
F
Take
you
know
time
off,
so
it
might
be.
You
know,
but
actually
it
might
be
a
good
idea
for
them
to
if
they
can't
be
available,
find
a
replacement
now
that
I'm
thinking
about
it
so
that
we
can
make
sure
one
person
is
available,
but
I
think
the
best,
like
you
know,
ideal
scenario
would
be
like
you
said:
if
we
don't
require
those
people
anymore
and
I,
think
we
talked
about
as
a
release
test
for
last
time
having
a
automation
to
actually
create
the
tag.
F
E
I
will
say
that
myself
I'm,
not
sure
if
Joe
is
on
the
call.
We
took
a
look
at
this
during
this
release
cycle
automating
this.
There
are
technical
issues
that
aren't
will
say
insurmountable,
but
we
didn't
have
time
to
fix
them,
but
there's
the
biggest
issue
is
around
security
and
maintainability
of
this
release
process.
E
So
there
is
an
idea
that
we
would
be
able
to
create
the
tags
using
bit
of
action.
This
will
get
rid
of
a
gpg
key
that
we
use
currently
So.
Currently
we
use
the
gpg
key
to
assign
our
tags,
so
we
would
have
to
get
rid
of
that
or,
let's
create
a
bit
of
users,
there's
just
a
number
of
issues
with
it
that
I
think
we
can
pick
offline
but
yeah.
Definitely
The
Substitute,
so
online
484
there
under
the
responsibility
is
the
release.
E
Writer,
that's
the
one
thing
that
kind
of
have
to
continuously
do
is
make
sure
that
there's
a
substitute,
but
if
they're
not
going
to
be
available,
but
there
is
to
release
these
job
to
kind
of
give
them
a
heads
up
ahead
of
a
date
but
yeah,
like
you,
said,
I,
think.
Ideally,
we
would
want
to
get
rid
of
this,
so
it's
not
on
the
shoulders
of
so
few
people,
but
yeah.
There
are
just
Technical
and
security
challenges
to
make
getting
it
done.
A
Stefan
you've
got
your
hand
up.
Please.
G
Yep
was
agreed
that,
ideally,
we
were
automated
if
you
find
a
secure
way
to
do
it
in
a
maintainable
way
too.
Yes
to
get
this
automation
done,
but
independent
of
that
I
think
what
automation
brings.
G
Us
is
basically
that
we
can
probably
do
to
release
a
bit
more
async,
but
it
doesn't
remove
the
dependency
on
a
maintainer
because,
at
least
at
least,
if
we
don't
change
more
stuff,
because
as
of
today,
the
I
think
intentionally
need
maintainer
approval
to
promote
images
to
production,
and
that
also
has
to
happen
in
the
towards
the
end
of
the
release
process.
G
So
it's
definitely
more
convenient
if,
on
that
day,
the
maintainer
only
has
to
like
approve
one
or
two
PRS
versus
actually
I,
don't
know,
attack
it
push,
but
we,
but
just
automating
the
git
tag,
push
and
related
stuff
in
there
won't
mean
that
we
don't
need
a
maintainer
available
on
the
day
of
the
race.
H
So
I
think
yeah,
it's
it's
a
little
bit
more
than
just
tagging.
Tagging
is
step
one
right.
We
gotta
tag
the
release
for
a
pull
release.
We
actually
have
to
cut
a
branch,
then
the
image,
promotion,
PR
and
then
finally,
actually
updating
the
release
information
right.
So
there's
kind
of
four
four
things
that
a
a
maintainer
has
to
do
essentially
holding
our
hands
through
the
process.
I,
don't
know
what
all
we
can
remove,
what
all
we
can
automate.
H
We
did
look
into
the
tagging,
but
with
the
gpg
stuff,
the
the
kind
of
consent-
this
was
I,
we
don't
know
about
security
and
how
that
would
work
and
how
we
would
feel
about
that.
So
we
could
automate
the
tagging
probably
fairly
quickly,
but
then
the
rest
of
it
would
still
require
somebody
to
help
out
and
and
kind
of
be
available
was
was
the
thinking.
I
Yeah
I.
C
Yeah
we
discussed
a
lot
of
these
I
think
that
taking
a
step
back
is
fair
for
the
release
team
to
have
a
maintainer
around
when
there
is
a
release,
because
yeah
maintainer
can
help.
If
the.
If
there
are
issue
it
can
do
some
work,
the
less
the
better
but
I
think
that
is
fair
to
have
a
maintainer
in
charge
of
the
day
of
the
release
and
so
I
in
plus
one
to
get
it.
This
formalized
who
I
think
we
should
be
flexible.
C
There
will
be
a
maintainer
in
charge
if
he
is
not
available,
you
have
to
figure
it
out
another
month
dinner
to
be
around,
but
I
I
think
that
n
plus
one
maintain
it
at
the
end
are
responsible
and
they
bring
the
most
the
biggest
value
that
they
bring
is
expertise
that
can
help
during
release
so
definitely
plus
one.
For
me,
just
an
small
nibs
I
think
that
maintenance
charge
is
better
than
a
release.
F
Yeah
thanks
I
I
just
want
to
plus
one
Febreze.
Those
two
points
I
think
he
said
a
lot
better.
What
I
was
trying
to
say
I
think
it
makes
a
lot
of
sense
to
have
someone
who's
like
on
call
for
the
release,
but
I
still
think
we
should
still
try
to
go
and
try
to
make
the
release
team
have
all
the
permissions
and
like
access
like
access.
F
They
need
to
actually
do
things
in
the
release
because
I
the
goal
is
for
the
maintainers
to
be
able
to
get
out
of
the
way
and
so
that
the
releasing
can
actually
do
like
the
things
of
tagging
and
and
I
think
there
are
solutions
for
all
the
things
you
mentioned.
It's
just
that
we
have
to
figure
them
kind
of
one
by
one,
even
for
promotion
like
image,
promotion,
I
think
it
wouldn't
be
I
I
think
it'd
be
acceptable.
F
If
we
added
the
release
leads
to
the
owner's
file
for
images
in
the
image
promotion
repo
temporarily
during
a
release
cycle
even
better,
if
we
can
figure
out
an
alias
so
that
the
Alias
can
be
a
updated
without
changing
the
owner's
file.
But
anyways
now
I'm
getting
into
implementation
details
but
yeah
and
also
plus
one
to
changing
the
name
to
something
a
bit
more
like
you
know,
maintainer.
A
All
right,
it
seems
like
the
flow
of
hands
going
up,
has
slowed
down.
I
would
I
would
invite
everyone
to
leave
comments
on
this
PR
I
think
there's
been
a
great
discussion
here
and
with
that
said,
Joe
please
go
ahead.
Yeah.
H
I'm
so
sorry,
my
brain's
slower
than
most
so
adding
I
think
Cecilia
you
mentioned
giving
somebody
on
the
main
on
the
release,
leads
the
ability
to
add
the
tag.
Is
it?
Is
it
I?
I,
don't
I,
don't
know
GitHub
permission
well
enough,
but
like
can
they
also
have
permission
to
do
a
release,
but
maybe
not
right
directly
to
the
repo
like
is
that
is
it?
Is
it
that
fine
grain
like
if
those
two
are
kind
of
it,
I
think
that
helps
remove
a
lot
of
kind
of
the
ask
I
don't
know.
G
I
can
maybe
answer
so
I
think,
there's
probably
a
lot
possible
under
GitHub
side.
I
think.
G
The
only
thing
that
we
have
today
is
basically,
we
have
a
role
which
is
basically
right
access
to
the
repository,
so
you
can
push
ramcha's
text
I,
think
you
can
delete
branches,
but
you
can
push
branches
and
you
can
create
all
these
delete
releases,
all
that
sort
of
stuff,
and
then
we
have
like,
let's
call
it
full
Open
Access,
which
gives
you
literally
every
right,
International
repository,
which
also
means
you
see
the
settings
tap
and
can
change
configure,
hopefully
Nobody
Does
it
but
yeah.
G
I,
don't
know
how
much
is
possible
with
the
automation
that
is
behind
those.
Basically,
if
yaml
fights
defining
all
of
those
and
I
think,
then
there
is
tooling
behind
from
I,
don't
know,
probably
six
hundred
bags
or
something
to
sync
those
into
actually
GitHub
permissions.
G
So
we
would
have
to
take
a
closer
look,
what
we
can
do
there
and
how
Franklin
or
that
tooling
is
or
if
we
can
extend
the
totally
that
sort
of
stuff
or
we
can
basically
I
mean
we
have
admin
access
right,
so
we
can
configure
whatever
we
want,
but
that
wouldn't
be
defined
and
yeah.
It
wouldn't
be
defined
in
some
kubernetes
Community
repository
it
wouldn't
be
protected
by
the
normal
authorization
stuff.
It's
just
something
that
we
we
customized
for
ourselves.
So
maybe
an
option,
maybe
not
I,
don't
know.
A
Forecast,
you
add
your
hand
up.
Please.
J
Yeah
and
second
thing
kind
of
the
what
Stefan
said,
I
think
we
have
to
look
in
the
Upstream
kubernetes
I'm,
not
expert
at
all,
on
how
they
handle
that.
But
as
far
as
I
know,
they
have
a
dedicated
GitHub
team
like
with
members
called
release
managers
and
they
actively
like
they
take
turns
and
push
their
releases
for
patch
or
even
the
miner,
since
that
they
maintain
different
minor
releases,
so
2014
to
526.
So
they
do
it
in
turn.
A
All
right
cool,
thank
you.
So
if
there's
nothing
else
on
this
topic,
I
would
I
would
invite
the
Lively
discussion
to
continue
on
the
pr
please
and
I'm
not
seeing
any
more
hands
move
up.
So
we'll
move
on
to
the
next
topic.
Mike
and
Alex.
You
guys
have
a
topic
about
kubecon
Cappy
operator
talk.
Please
take
it
away.
K
Yeah,
thank
you:
okay,
yeah
I'm,
back
from
vacation
and
yeah.
So
yesterday
we
received
a
message
from
libamir
saying
about
the
possibility
of
applying
for
cubicon,
kubecon
and
Alex,
and
I
would
like
to
go
there
and
make
a
talk
about
cluster
API
operator,
and
please
tell
us
what
the
procedure
of
submission
and
what
we
should
do
from
our
site.
As
I
remember,
Elizabeth
mentioned
that
it
would
be
good
to
have
the
presentation
slides
ready
if
there
anything
else
needed.
L
So
we
had
a
discussion
about
this
during
the
sequence
life
cycle
meeting.
Basically,
the
cncf
is
limiting
the
amount
of
torque
slots.
We
have
for
six
projects
to
something
like
two.
So
essentially
you
are
requesting
that
you
take
one
of
the
slots.
L
We
can.
We
basically
have
to
decide
who
can
take
the
slot.
So
if
you
have
your
presentation
ready
for
us,
we
can
have
a
look
and
basically
the
sigleys
have
to
decide.
You
know
it's
a
Pity
if
something
doesn't
make
it,
but
that's
how
it
is
because
we
are
limited
so
I
know.
Minicube
also
want
to
send
the
talk.
Maybe
somebody
else
also
wants
to
so
we
have
to
ultimately
decide
what
is
the
most
interesting
soup
project
topic
for
us
to
submit.
L
A
Fabrizio
you've
got
your
hand
up.
Please.
C
I,
as
far
as
I'm
aware,
we
I
think
that
it
will
be
enough
to
have
a
concept
about
the
torque
is
not
necessary
to
have
the
the
fullest
life,
and
this
will
say
to
at
least
for
the
sequel
is
to
to
decide
the
other
option.
We
will
be.
We
submit
everything
and
we
basically
go
to
the
cncf
lottery,
but
yeah
I.
Think
that
makes
sense
what
lubomir
is
suggesting.
M
Just
one
clarification
on
what
mentioned
like,
so
we
already
submitted
two
talks,
but
for
sub-project
it
is
going
to
be
a
lottery.
That's
my
understanding,
so
I
would
submit
everything.
Sorry
if
we
have
like
another
talk,
we
should
just
submit
it.
Lubemere
like
and
then
basically
like,
let
the
feed
decide
which
ones
are
going
to
go
into
the
speaking
rounds.
L
I
think
last
time
for
Europe
we
submitted
some
talks.
They
kind
of
overlapped
us
some
projects
into
the
eyes
of
the
reviewers,
so
I,
don't
think
like
a
lottery
is
a
good
option
at
all
they,
since
they
basically
started
confusing.
What
is
a
store
project
and
what
isn't
so,
I
think
we,
it's
probably
better
for
us
to
just
filter
on
our
side,
because
we
actually
know
what
is
a
project
in
this
group
I.
M
Okay,
so
maybe
we
can
I
mean
we
should
have
probably
talked
before
like
this
when
I
post
the
message
it
was
like
a
few
weeks
or
a
month
ago,
or
something
so
we
went
ahead
submitted
it
I,
don't
know
if
we
can
retract
one
of
the
submissions
or
both.
M
L
L
For
the
sick
is
already
a
reserved
sword,
the
06
have
it
so
it's
guaranteed,
so
the
the
copy
deep
dive
apparently
is
already
like
a
show
project
slot
that
is
taken
again
like
we
speculate
on
two
as
a
total
number
of
Super
projects.
I,
don't
think
we
can
request
more.
They
are
really
hesitant
about
giving
us
more
than
that,
so
it's
like
we
have
to
bargain.
L
Basically,
so,
for
example,
I
see
now
our
proposals.
We
have
this
cluster
API
operator
as
well
sure,
maybe
that's
the
the
second
one
we
can
send,
but
also
I,
see
the
mini.
Cube
folks
have
and
want
to
have
a
talk
so
effectively.
We
have
like
some
projects
fighting
for
a
slot.
M
Okay,
let's
collect
this
I
mean
submission,
I!
Think
it's
relatively
soon,
so
we
need
to
decide
by
the
end
of
this
week.
K
Yeah,
so
from
our
side,
we
just
need
to
prepare,
slides
and
just
a
short
abstract
about
the
talk
and
we
will
send
it
to
the
slack
Channel.
I
A
C
A
Cool,
thank
you
Mike,
and
it
sounds
like
the
sieg.
Maybe
has
a
little
bit
of
organization
to
do
as
well,
because
this
Sunday
I
believe
is
the
deadline
for
maintainer
track
talks.
A
N
A
All
right,
thanks
next
on
the
agenda,
Killian
you've
got
a
topic
about
the
API
version,
V1
Alpha.
Three:
please
go
ahead.
E
E
Yeah
well
I've
brought
this
up
a
few
times,
but
in
1.5
the
V1
Alpha
3
API
version
will
no
longer
be
served
in
cluster
API
and
then
in
1.6
as
PR
open.
That
was
up
the
one
alpha
4
from
being
served.
So
these
API
versions
are
deprecated
they've,
both
been
deprecated
for
over
a
year
about
a
year
and
a
half
I
think
in
case
we
went
out
for
three
now
so
yeah.
E
So
this
is
just
a
heads
up
that
if
you
have
stuff
running
on
V10,
Alpha,
3,
V10,
Alpha
Four,
please
upgrade
and
please
test
to
make
sure
that
yeah.
But
your
projects
are
working
1.5
as
it
comes
out.
So
this
is
currently
the
state
for
V103
in
the
release
candidate
for
C
1.5.
So
if
you
test
ahead,
you'll
find
books,
so
in
the
first
in
V
1.5
it
will
be
possible
to
roll
this
back,
because
the
API
is
just
no
longer
served.
A
All
right,
Richard
you've
got
the
next
topic
with
a
Choose
Your
Own
Adventure
provision
of
production
cluster.
Please
take
it
away
thanks.
N
Yeah
very
quick
one
so
I'm
down
to
do
the
cheesier
and
Adventure
shown
next
week
on
Tuesday
with
Whitney
and
Victor,
basically
where
they
take
the
path
to
production
in
each
of
the
stages
that
they
pick
two
technologies
and
they
they
pitch.
N
A
Okay,
great
yeah,
I
hadn't,
I
hadn't,
heard
about
this
this
broadcast
before
it
looks
pretty
cool
so
yeah.
If
anyone
out
there
is
interested
in
getting
more
involved
in
this
or
you've
got
some
points
that
you
think
should
be
brought
up
during
that,
please
reach
out
to
Richard
in
slack,
and
if
you
want
to
really
get
involved,
it
sounds
like
maybe
there's
a
chance
for
you
to
appear
on
the
show
as
well.
So
please
reach
out
to
Richard
all
right.
A
Joe
you've
got
the
next
topic
with
a
call
out
for
a
CI
release.
Lead
please
take
it
away.
H
Yeah
so
sorry
Mr,
real,
quick,
we're
putting
together
the
release
team
for
1.6
I
think
we've
got
most
of
the
team,
but
we're
looking
for
somebody
to
take
over
as
the
release
lead
for
CI.
H
H
A
C
Just
stressing
on
what
Joel
is
cutting
out
the
sauce
for
getting
the
next
result,
it's
really
important
role.
It
is
a
role
where
you
can
learn
a
lot.
We
did.
We
already
invested
the
time
and
effort
in
recording
a
lot
of
how
to
sessions
we
as
a
maintainer,
We
Are.
All
we
will
be
always
available
to
help
people
to
ramp
up.
So
it
is
important
for
the
project.
It
is
a
good
opportunity
to
learn,
don't
be.
I
H
Sorry,
one
big
follow-up
to
that
parisio
I
think
you
mentioned
that
there
was
some
upcoming
infrastructure
changes,
possibly
for
end-to-end
tests
for
the
next
release
team
and
one
of
the
things
that
we've
done
for
the
next
team
is
the
ca
team
is
a
little
bit
bigger
than
typical.
H
So
there's
there's
a
good
number
of
folks
who
are
excited
to
be
on
the
team
and
help
out
there
as
well,
so
we're
kind
of
looking
for
the
lead
to
help
take
charge
and
run
with
it.
So.
A
And
I
guess
like
I
know
we're
talking
about
there'll,
be
like
lots
of
help
and
there's
good
support
and
everything
there,
but
you
know
for
anyone
who
might
be
watching
or
might
be
you
know
re-watching
this
or
something
you
know
becoming
a
lead
sounds
kind
of
challenging.
What
kind
of
you
know
what
kind
of
experience
or
background
might
someone
want
to
have
to
step
into
this.
H
Sorry,
I
I
think
I
could
possibly
answer
some
of
that,
but
not
all
of
it
I
think
some
some
knowledge
of
just
cntf,
stuff,
Cloud
infrastructure,
stuff,
just
general
leadership,
qualities
to
have
or
to
grow
into
some
Ambitions
there,
a
somewhat
I
wouldn't
even
say,
intimate
knowledge
of
of
cluster
API
itself.
Right,
as
as
the
lead,
you
can
help
remove
distractions
and
help
plan
and
and
the
other
things
that
would
go
into
the
leadership
role.
H
But
having
somebody
with
intimate
knowledge
would
be
a
huge
plus,
but
not
required
right.
So.
A
Okay,
great
yeah,
like
I
I,
just
wanna
I,
know
like
I've,
seen
a
lot
of
people
coming
around
the
kubernetes
community
looking
for
places
they
can
help
out
and
everything,
and
it
sounds
like
if,
if
you're
someone
who's
looking
to
kind
of
you
know,
take
on
a
little
more
leadership
or
looking
to
move
into
one
of
these
leadership
roles.
A
This
is
a
good
place
to
learn
about
that.
You
probably
do
want
to
have
some
cncf
knowledge
and
some
cluster
API
knowledge.
So
this
isn't
an
absolute
beginner
kind
of
thing
so,
but
it
a
great
opportunity
for
the
community.
Thank
you,
okay.
A
So
next
topic,
denil
you've
got
an
issue
here.
Please
take
it
away.
O
Yeah
I'm.
Sorry,
probably
it's
a
bit
out
of
context
for
this
meeting.
It's
just
a
simple
question
about
the
interest
in
community
towards
having
some
arbitrary
filters
for
cost
AP
resources
to
solving
cases
like
charging
the
management
of
the
resources
between
several
copy
of
installations,
and
whether
or
not
this
is
something
which
Community
is
looking
for,
because
during
a
discussion
it
seems
to
be
that
the
issue
should
go
or
the
importance
should
go
to
controller
runtime.
O
And
the
problem
is
here
that
it's,
it
relies
very
much
on
embedded
structures
in
machinery
and
the
maintenance
of
public.
Don't
want
cell
Expressions,
which
might
be
a
good
idea
to
plug
here,
to
support
such
a
feature
because
of
complexity,
concerns
and
the
questions
here.
Whether
or
not
is
it
like
a
typical
use
case
for
someone
to
try
it
out
in
their
cluster.
So
not
yeah.
Just
asking
Community
about
some
ideas
at
this
point
because
I
feel
like
it
might
not
be
possible.
A
Cool
good
question:
does
anyone
have
thoughts
about
this
that
they'd
like
to
respond
or
perhaps
further
questions.
K
C
Find
a
way
to
solve
this
problem.
I
think
that
mostly
having
multi
religa
filter
is
is
not
going
to
solve
this
problem.
Second,
that
there
is
a
good
discussion
and
comment
on
the
issue
about
the
fact
that
filter
and
not
enough,
because,
for
instance,
you
if
the
cache
is
not
filtering
with
the
same
criteria,
then
you
will
have
a
very
inefficient
users
of
memory,
because
you
are,
you
have
a
controller
that
is
going
to
Cache
everything,
even
if
you
are
reconciling
earlier
subset
of
it.
So
my
take
here
is
that.
C
C
Adequate
for
this,
but
the
issue
is
again:
crd
is
existing
only
one
time,
so
my
concern
is
that
we
build
something
inside
cast
API.
We
take
ownership
of
the
problem,
but
The
Primitives
are
not
really
there.
So
I
think
that
we
should
take
a
step
back.
Think
about
the
the
original
use
case.
Think
about
if
the,
if
kubernetes
self
is
adequate
for
it's
ready
for
this
scenario
or
not.
A
I
C
Yeah
we
we
before
I
I'm
talking
about
this,
because
because
before
we
in
cluster
cattle,
we
were
supporting
many
instance
of
Copy
in
the
same
cluster
and
we
decided
to
move
away
because
basically,
kubernetes
is
not
is
not
designed
for
these.
You
can.
You
can
have
many
instances
of
the
controller,
but
they
they
are
forced
to
share
the
same
version
of
the
crd,
and
this
is
not.
This
doesn't
work
well,
because
when
every
instance
of
the
controller
make
assumption
on
how
the
crd
are-
and
so
it
is
hard,
we
don't
have
test
coverage
for
this.
A
Thanks
for
the
explanation
like
this,
it
sounds
like
a
complicated
issue
here
to
unwind
yeah
and
it
looks
like
there's
been
a
good
discussion
even
as
of
today
on
this
issue.
So
I
guess,
if
others
are
listening
and
are
curious
about
this
topic,
you
know
please
visit
the
issue
and
and
leave
your
thoughts
there
and
you
know
yeah.
Maybe
this
is
something
we
can't
solve
in
cluster
API.
There
needs
to
be
a
more
systemic
kind
of
look
at
this.
A
G
At
this
point,
more
like
heads
up,
I,
think
so
Carlos
was
asking
today.
Basically,
if
there's
any
ongoing
work
about
this,
but
let
me
give
you
the
context
first.
So
cornice
is
basically
an
upstream
coordinator
that
decided
I
think
already
a
while
ago,
to
always
use
the
latest
go
minor
version
in
all
release
branches.
G
I
think
it's
the
same
industrial
API
even
worse,
because,
let's
say
kubernetes
is
already
releasing
with
with
12,
let's
say
with
eight
or
nine
numbers
of
support,
because
they
don't
perfectly
align
to
the
Go
version,
and
then
we
use
the
same
goal
version
as
Upstream
kubernetes
but
release.
Let's
say
a
month
later
or
two
or
three
months
later,
then,
probably
when
we
release
the
cluster
API
version,
we
have
maybe
half
a
year
of
goal,
support
so
I.
Don't
know
the
exact
technicalities,
but
we
definitely.
G
We
definitely
run
into
the
problem
that
our
goal
versions
are
running
out
of
support
during
the
time
when
we
support
a
specific
customer.
What
I
linked
here
is
basically
the
stack
fit
that
Carl
started
today.
So
I
think
the
discussion
is
just
getting
started
and
also
linked
to
Upstream
kubernetes
cap
I'll.
G
Take
a
closer
look
into
this,
but
I
think
we
should
probably
seriously
think
about
aligning
to
what
they're
doing
I
also
have
to
think
a
little
bit
about
how
or
if
this
affects
controller
runtime,
and
if
we
should
do
some
assembling
control,
runtime
I
think
the
main
thing
is
basically
the
in
apps
and
coordinators.
They
change
the
goal
version
with
which
they
compile
their
binaries.
G
So
the
release
artifacts
apis
circular
Dimensions
Etc,
et
cetera
they
are
compiled
with
a
certain
code
version
control
random,
doesn't
have
any
binaries
that
it
releases
it's
just
a
library,
so
it
could
be
that
for
controller
on
time
it
totally
doesn't
matter,
but
again,
industry
try
it
matters,
because
we
also
have
cluster
cuddle
and
controllers
that
will
be
released
so
yeah.
If
someone
is
interested
I,
don't
speak
up
now
or
follow
the
thread
or
I
guess
if
we
actually
want
to
make
it
happen,
there
will
be
an
issue
at
some
point.
A
C
Yeah
I
think
that
we
should
start
tracking
and
since
kubernetes
is
doing,
we
should
do
it.
What
do
we
we
can
do
is
to
try
to
highlight
what
is
the
impact
on
providers
if
we
buy?
If
we
do
this
in
copy,
if
we
make
this
clear,
then
I
think
that
we
can
speed
up
the
discussion.
So
what
happen,
if
copy
bumps
golang
version
in
Order
release
what
is
expected
for
provider
to
happen,
and
so
on
and
support.
G
Yeah
I
think
it
makes
absolutely
sense,
and
that
is
one
of
the
first
things
that
I
would
have
looked
for.
So
my
expectation,
given
that
kubernetes
is
doing
it
is
something
like
it
probably
only
affects
the
binaries
that
we
produce
and
if
someone
Imports
our
library,
it
doesn't
affect
them,
but
it
is
100,
something
that
we
have
to
confirm
because
I
mean
if
they
bump
in
Upstream
kubernetes.
Let's
say
the
independent
version
from
118
to
19
to
24
client
go
and
that
affects
everyone
that
uses
line
go
that
will
be
pretty
drastic.
G
So
my
my
suspicion
is
a
bit
that
it's
that
it
doesn't
impact
consumers
of
the
dependencies
of
the
libraries
basically
because
they
don't
bump
the
version
in
go
mod.
They
just
bump
the
version
with
which
they
compiled
everything.
If
I
cut
it
correctly
at
this
point,
but
yeah
100,
that's
the
thing
we
have
to
figure
out,
basically
does
it,
who
does
it
affect
and
also
how
are
providers
effect?
What
is
the
recommendation?
I
would
say
for
providers
if
they
should
do
the
same,
or
what
do
they
have
to
do?
A
Yeah
so
so
I
mean
it
sounds
like
it's
a
good
idea
in
general,
but
we
need
to
do
a
little
bit
of
legwork
to
make
sure
that
we
don't
leave
providers
behind
before
we
make
this
kind
of
change
or
start
doing
these
kind
of
back
ports
or
something
any
other
questions
or
comments
on
that
topic.
A
Okay,
I'm
not
seeing
anything
else
there,
so
that
is
our
regular
agenda.
We'll
move
into
the
provider
updates
now
so
for
kapiti
Christian.
Please
take
it
away.
I
No
I
just
wanted
to
give
the
feedback.
B105.0
beta
bonus
merged
in
Maine
for
Cafe
looks
good
so
far
and
rc.0
PR
is
in
flight.
So
yeah,
that's
basically.
A
Thanks
all
right
cool
thanks
for
the
update
Richard
had
a
drop
from
the
call,
but
he
wanted
to
announce
that
there's
a
capo
release
for
2.2.0
and
I.
Guess
he's
also
saying
no
one
is
dedicated
to
the
project
right
now
and
we're
in
need
of
new
reviewers
there
so
again
to
the
folks
who
might
be
watching
or
listening
or
watching
this
later
or
something.
If
you're
looking
to
get
involved,
the
Kappa,
which
is
the
the
AWS
provider
for
cluster
API,
could
use
some
help.
Please
take
a
look.
A
So
next
up
is
capoci
Joe.
Please
take
it
away.
H
Yep,
just
a
real,
quick
call
out:
we
continue
in
our
releases
or
in
112
now
sorry
12,
which
has
some
support
for
oke,
managed
clusters
and
things
of
that
nature.
But
the
other
thing
I
wanted
to
call
out
was
the
we
tested,
the
rc0
not
landed
any
code,
but
we're
able
to
test
it
real,
quick.
The
other
thing
I
definitely
want
to
call
out
here.
Real
quick
is
the
comms
team
for
release.
H
A
Very
cool
good
to
hear,
and
lastly,
cap
Z
Matt,
please
take
it
away.
P
Hey
thanks
Mike
just
want
to
let
people
know
we're
going
to
do
some
patch
releases
and
also
the
Pepsi
minor
release
today,
possibly
tomorrow,
if
we're
waiting
for
one
little
fix
and
then
we've
also
started
doing
the
Cappy
1.5
integration,
most
of
which
is
straightforward,
but
for
better
or
worse,
capsi
is
starting
to
lean
on
this
component
called
Azure
service
operator,
which
also
has
a
hard
dependency
on
controller
runtime,
so
we're
kind
of
stuck
until
they
upgrade
so
I
guess,
tldr
just
make
you
know
if
you
haven't
started
integrating
yet
definitely
give
it
a
shot,
because
there's
a
lot
of
work
to
do.
A
All
right,
thank
you,
and
that
brings
us
to
the
end
of
the
agenda
for
brisio.
You've
got
your
hand
out.
Please
yeah.
C
First
of
all,
thank
you
for
everyone
for
sharing
feeder
from
providers.
This
is
really
important
for
us
to
get
the
to
reach
confident
the
ga
date
yeah
I
Echo.
What
the
matter
was
saying,
given
the
changes
in
control
run
time,
this
copy
bump
requires
quite
a
bit
of
work,
so
the
sooner
you
start
the
better.
A
A
Not
upgraded
to
controller
runtime
what
Oda
15!
Please
start.