►
Description
Meeting notes https://docs.google.com/document/d/1ushaVqAKYnZ2VN_aa3GyKlS4kEd6bSug13xaXOakAQI/edit
A
Welcome
everyone
today
is
Wednesday
the
1st
of
March
2023,
and
this
is
the
cluster
API
project.
Meeting
cluster
API
is
a
sub-project
of
kubernetes
sigs
and
as
such,
we
follow
their
their
meeting
guidance,
which
basically
means
if
you'd
like
to
talk.
Please
raise
your
hand
and
I
will
call
on
you
and
otherwise
in
general,
please
treat
each
other
as
you
would
expect
to
be
treated
or
explicitly.
Please
be
kind
to
each
other.
A
So
at
the
beginning
of
every
meeting,
we'd
like
to
take
a
little
time
to
welcome
our
new
attendees.
So
if
this
is
your
first
time
at
the
meeting,
or
maybe
your
first
time
in
front
of
the
community,
please
feel
free
to
unmute
and
introduce
yourself
or
raise
your
hand.
I
will
go
quiet
for
a
few
seconds
here
and
give
people
a
chance.
B
Hi,
all
if
I
might
do
you
hear
me
well
yeah,
so
thank
you
very
much.
My
name
is
Muhammad
I'm,
a
Consulting
engineer
at
Souza
and
I'm
here
today.
My
first
time
in
this
meeting
happy
to
join
you
all
and
have
to
you
know,
have
to
know
you.
My
idea
today
was
to
present
you
a
new
project.
I
mean
a
few,
a
new
provider
for
copy
called
for
rk2.
So
it's
a
a
control,
plane
and
bootstrap
provider
for
rk2
and
I'll
be
demoing
its
search,
Alpha
First,
Alpha
version.
B
C
Hi
everyone,
my
name,
is
Musa,
so
this
is
my
not
the
first
time,
maybe
second
time
I've
joined
because
I
was
busy
on
other
meetings.
So
today,
I've
just
started
from
the
first,
as
the
meeting
starts,
but
yeah
I've
recently
started
looking
a
cluster
API
because
I'm
building
another
tool
which
automate
a
lot
of
deployments
on
the
Clusters
using
their
apis,
but
I'm
very
keen
to
now
introduce
that
cluster
API
because
I'm
very
impressed
with
the
the
way
it's
been
built
and
just
started.
C
Looking
at
so
looking
forward
to
work
with
the
community
and
hopefully
I
can
contribute
as
well,
because
I'm
just
really
new
to
the
golang
but
yeah
I
would
love
to
contribute
as
well
in
the
open
sources.
That's
something
I'm
just
trying
to
go
through
the
code
as
well
as
much
as
I
can.
So
that's
basically.
So.
Thank
you.
A
Awesome,
that's
that
sounds
amazing.
Musa
welcome
aboard
and
you
know,
there's
a
lot
of
great
resources
in
our
slack
channel.
So
if
you're,
if
you're
new
and
trying
to
understand
the
code
or
looking
for
advice,
I
would
definitely
recommend
reaching
out
in
the
cluster
API
slack
channel.
It's
a
great
resource.
A
All
right,
I
am
not
seeing
any
other
hands,
go
up
so
give
folks
another
second
here.
If
anyone
would
like
to
say
hi,
okay,
we'll
move
on
to
the
next
part
of
the
meeting.
So
next
we
usually
go
through
our
open
proposal.
Readouts
I'm,
not
sure
that
we
have
any
at
this
time.
There
are
no
open
proposals.
I
don't
know
is.
Is
there
anyone
here
who'd
like
to
speak
about
the
stale
proposals.
A
E
E
This
was
down
to
a
patch
in
the
Git
Version
used
in
the
golang
Builder.
So
we
use
goal
line
the
golang
image
to
build
copy
for
releases,
but
we
don't
use
it
in
other
places.
So
we
didn't
catch
this
issue
just
until
right
at
release.
So
this
is
the
fix
it's
just
PSA,
because
I
guess
some
providers
might
have
similar
build
processes
might
run
into
the
same
issue
next
week
or
whenever
so
yeah
just
watch
out
for
it.
E
A
F
B
B
So
yeah,
basically
I'm
presenting
today
a
a
new
provider
for
for
copy.
The
idea
behind
it
is
that
it
will
help
using
copy
to
deploy
rk2
clusters.
If
you're
not
aware
what
rk2
is
rk2
is
a
a
kubernetes
distribution
created
by
originally
by
Rancher.
The
idea
behind
it
is
that
it's
a
data
center
oriented
kubernetes
cluster
type
distribution
that
is
based
on
k3s,
so
container
d,
that
is
fips
compliance
and
has
an
is
security
oriented
okay.
B
So
the
idea
behind
that
provider
is
that
it
it
has
to
like
this
will
make
it
possible
to
deploy
arcade
to
types
of
clusters
using
copy,
so
we
developed
for
a
short
while
a
first
version,
and
we
had
since
a
couple
of
days
our
first
Alpha
version,
which
is
a
pre-release.
So
it's
not
yet
production
ready,
but
it
should
work
for
test
environments
in
an
acceptable
way.
So
you
can
take
a
look
here
at
the
I.
Can
I
cannot
actually
show
exactly
the
link?
B
Oh
okay,
so
yeah
github.com,
Rangers
sandbox
and
cluster
API
provider
rk2,
and
there
you'll
find
the
the
release
with
the
release,
notes
and
the
assets
for
cluster
for
clusters
here.
So
the
idea
today
is
that
I
would
show
you
very
fast
how
that
interface
is
relatively
easily
with
with
cluster
still
so
here
I'm
on
a
my
WSL
machine
and
I'm,
going
to
show
you
the
content
of
the
slash
cluster
API,
you
see,
I
have
a
the
config
file
for
cluster
CDL.
B
B
B
So
you
see
that
I'm
in
dot
cluster
Dash,
API,
class.tml
and
I
have
here
for
configurations.
The
first
two
are
for
our
provider
here,
so
the
rk2
provider.
You
see
that
the
rk2
provider
is
actually
two
providers,
it's
the
control
plane
one
and
the
bootstrap
one
so
to
deploy
the
control
plane
and
the
worker
parts
of
the
cluster.
B
And
then
you
will
see
that
I
override
the
the
docker
provider
and
the
AWS
provider,
and
that's
because
basically
there
are
some
small
issues
related
to
how
these
infrastructure
providers
work,
and
we
can
talk
about
a
little
bit
later,
but
basically
I
needed
to
override
that
with
my
own
Forks.
Okay.
So
if
I
use
that
do
a
simple
cluster
CTL
in
it,
cluster
CTL
in
it
with
bootstrap,
set
to
rk2
control,
plane
set
to
arcade2
and
infrastructure
set
to
Docker
that
would
install.
For
me
the
I,
don't
know
what
I.
B
B
B
That's
why
we
are
using
the
forks
as
I
mentioned
the
for
the
these
are
two
different,
actually
small
issues.
The
cap
d,
one
is
related
to
the
fact
that
the
infrastructure
provider
relies
on
a
health
check
for
the
load
balancer
container,
that
is
standard
HTTP,
but
expects
Anonymous
query
of
the
health
check
endpoint
for
the
API
server.
B
Okay,
on
the
different
nodes.
The
problem
is
that
with
rk2,
we
have
deactivated
Anonymous
of
like
Anonymous
querying
of
the
health
check
endpoint.
So
that
does
not
work.
So
we
need
to
basically
create
an
issue
on
the
cap,
D
provider
upstream
and
probably
contribute
that
to
like
do
a
pull
request
to
also
accept
other
types
of
other
types
of
and
of
health
checks.
Yeah,
that's
what
I
meant.
So
that's
for
the
cap,
D1
for
the
Kappa
One
or
the
AWS
one.
It
has
more
to
do
with
security
groups.
B
Basically,
rt2
relies
on
custom
port
to
do
node
registration
for
new
nodes
and
the
security
groups
are
not
configurable,
unfortunately,
in
the
Kappa
provider.
So
we
basically
need
to
add
that
Port
either
manually,
which
is
not
very
interested,
interesting
or
Fork,
the
AWS
provider,
to
add
that
Port
right
now,
however,
we
already
have
so
which.
A
B
F
B
I'm
opening
this
issue
here,
ability
to
customize
Security,
Group
rules
on
the
cluster
API
provider,
AWS
and
basically
yeah.
It
asks
to
be
able
to
add
security
rules
to
the
different
security
groups
that
are
generated
automatically
just
to
give
to
give
the
possibility
to
to
configure
you
know
additional
bootstrap
providers
such
as
zakai
2,
for
example,
so
this
is
being
worked
on,
but
it's
not
yet
it's
not
yet
done
so.
B
In
the
meantime,
if
you
would
like
to
use
this
provider,
please
go
ahead
and
use
our
own
fork
for
that.
This
is
also
documented
in
our
readme
page
for
now
yeah.
So
my
message
here
after
this
is
that
you
know
we
would
like
to
contribute
this
provider
to
the
Upstream.
Six
in
a
I
would
say
a
near
future
if
that's
possible,
so
in
order
to
achieve
that,
we
will
need
to
stabilize
it
to
test
it
and
I'm
here
to
basically
core
call
for
help
and
contributions.
B
A
G
But
we're
kind
of
wanting
to
push
for
is
that
reviewers?
What
what
we're
asking
for
is
that
reviewers
would
try
to,
with
their
best
effort,
add
that
area
of
change
at
the
time
of
Landing,
the
pr
ultimately
I,
think
the
goal
is
going
to
be
later
to
automate
this
and
hopefully
ask
our
reviewer
our
our
the
people,
cutting
the
pr
to
do
this
for
us,
but
I,
don't
think
we're
in
that
stage.
G
A
G
Am
not
aware
of
one
right
now,
so
I
can
tell
you
what
we
currently
do
and
if
somebody
has
a
better
better
way
to
do
this,
please
let
me
know
we
keep
a
list
of
the
old
PR
or
the
old
releases
open
and
make
best
guesses
as
to
what
the
name
should
be
so
I
think
the
idea
is
to
somewhat
enumerate
the
list
somewhere.
I,
don't
know
if
that's
going
to
be
officially
in
a
doc
or
where
we
should
put
that.
But
that
is
something
we've
talked
about.
A
A
G
I
think
that's
an
amazing
idea.
We
I
don't
think
we've
officially
discussed
any
of
that.
The
the
first
steps
is
to
be
the
lazy
developer
and
ask
others
to
do
the
work
for
me
and
then
we'll
put
the
Automation
in
at
some
point.
I,
don't
know
what
that
looks
like
yet,
but
I
think.
That's
an
amazing
idea.
H
Oh
yeah,
no
worries
I
was
just
gonna
say,
like
I
know
that
right
now,
Kathy
has
these
like
emojis
to
help
like
triage
or
categories
and
I.
Think
our
release
notes
automation,
automatically
categorizes
based
on
those
emojis
as
prefixed,
but
in
other
repos
and
kubernetes
and
kubernetes
six.
What
I've
seen
a
lot
is
using
the
labels
and
we
already
have
those
labels
available
in
Cappy
already
because
we're
part
of
kubernetes
six.
H
So
we
have
those
like
kind,
slash
labels,
so
kind
teacher
kind,
bug
Etc,
which
can
give
like
a
predetermined
list
to
choose
from
which
might
be
a
bit
easier
than
telling
people
like
just
choose
an
area,
and
then
you
kind
of
have
to
interpret
which
one's
the
same
as
which
one.
And
what
are
the
categories,
which
is
a
suggestion.
G
No
yeah
that
I
mean
that
I
think
that's
a
great
idea.
So
do
you
mind
real
quick
going
to
the
release
notes?
I
know
the
next
topic
will
be
on
that
as
well,
but
yeah
that'd
be
perfect
So
for
anybody
not
aware
kind
of
what
we're
looking
for
here
right
is.
If
you
scroll
down
a
little
bit,
you
see
we
have
like
cluster
class
colon
developer
experience
colon,
so
we're
we're
kind
of
just
lifting
this
from
from
kind
of
the
existing
structure
of
release
notes.
G
H
Yeah,
so
it
really
has
to
match
whatever
automation,
we're
using
to
make
the
release
notes.
So
right
now,
Kathy
uses
the
Emojis
and
the
automation
that
it
uses,
but
I
know
that
release,
notes,
tool
or
there's
a
really
sense
tool
in
kubernetes
which
uses
the
kind
labels
so
I
guess
it
doesn't
make
sense
to
use
the
kind
labels
unless
we're
also
using
the
automation
that
generates
the
most
otherwise
it'd
be
pretty
manual.
But
yeah.
H
A
H
I
Yep
I
just
want
to
clarify
that
we're
busy
talking
about
two
different
dimensions.
Right
so
I
mean
one
thing
is:
do
we
do
the
icon
thing
for
bug
feature
whatever
or
I
will
start
using
those
labels
which,
essentially,
for
these
sites,
are
using
the
current
release,
not
tool
that
we
have
from
which
comes
from
I,
don't
know,
controller
tools,
Cupid
or
somewhere,
or
are
we
using
abstract,
coolers
and
even
independent
of
that
Dimension?
I
We
still
have
the
topic
about
in
which
area
of
our
code
base
does
this
prb
long
or
in
which
areas
I
think
we
have
a
lot
of
PRS,
which
are
probably
touching
like
I
guess
three
to
ten.
If
you
do
some
cross-cutting
stuff,
but
that
might
actually
be
easier
with
labels,
I
mean
if
you
touch
like
four
different
parts
of
the
code
base,
and
you
just
add
four
labels,
that's
easier
than
trying
to
add
four
prefixes
to
a
PR
title.
G
A
J
Yeah
I
was
just
about
to
mention
that,
regarding
the
second
dimension
that
we
are
looking
at,
we
have
an
areas
label
which
would
be
more
appropriate
in
this
case,
because
it
could
help
specify
okay,
this
PR
touches
cluster
class
area
or
runtime
SDK
area
and
so
on,
but
yeah
it's
covered
in
chat
and
people
Browder.
So.
A
K
A
Right
that
was
my
impression
is,
like
the
kubernetes
main
repos
doing
this
as
well
like
it's
adding
these
labels,
based
on
where
you
know
where
the
files
are
landing
that
are
changing
it.
So
it's
you
know
this
one's
in
the
test,
directory
and
I.
Think
that's
the
kind
of
automation
we're
talking
about
here,
where,
if
you,
if
you
touch
something
in
One
Directory,
we
could
have
it
automatically
add
some
of
these
labels,
like
that
I
think
that
would
be
really
cool.
Yeah.
G
H
A
G
A
I
A
A
A
J
They
just
want
to
announce
that
and
the
one
for
a
the
one
for
beta
tag
has
some
of
the
changes
have
some
of
the
big
changes
that
are
going
into
the
14
release
with
regards
to
kcp
remediation
and
variable
Discovery
and
in
place
provocation.
So
if
provided
folks
want
to
champ
on
it
and
basically
have
a
look
and
see
there,
we
now
have
a
beta
tag
that
people
can
start
taking
a
look
at
the
next
justify.
J
I
A
A
Okay,
I'm
not
I'm,
not
seeing
any
hands
growing
up,
but
I
will
Echo.
This
comment
from
chat.
You
know
the
release
team
is
setting
a
high
bar
for
all
future
release
teams,
so
yeah
I
I
totally
agree
with
that
all
right.
So
that
brings
us
to
the
end
of
our
regular
discussion
topics.
So
we'll
move
on
to
the
provider
updates
now
and
Richard's
got
something
for
cap
G.
So
please
Richard.
K
Yeah,
just
a
quick
one.
We
are
going
to
do
a
new
release
of
cap
G
next
week
1.3,
and
this
is
going
to
have
the
first
support
for
gke
in
there,
but
I
post
that
it's
it's
going
to
have
a
minimal
set
of
functionality,
initially
so
post
that
we're
looking
for
people
to
help
out
fill
out
the
the
functionality
in
gke,
both
in
terms
of
the
API,
but
also
in
the
testing
and
stuff
like
that
to
make
it
Rock
Solid,
because
it
will
be
experimental
initially.
So
yeah
expect
that
next
week.