►
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
This
meeting
follows
the
cncf
code
of
contract,
so
that
basically
means
be
nice
to
each
other
and
let
me
post
a
link
to
the
agenda
in
the
chat
and
if
you
want
X,
if
you
want
edit
access
to
the
agenda,
please
join
the
mailing
list
linked
at
the
top
of
the
doc,
and
you
should
be
able
to
edit
the
document.
A
B
C
Here,
Hello
nice
to
meet,
you
actually
I
think
it's
not
my
first
meeting
but
I'm
not
going
here
frequently
yeah
currently
I
work
in
your
Relic
and
we
are
experimenting
with
cluster
API,
not
expecting
we
used
in
production
a
lot
and
our
plans
are
to
automate
installation
and
maintenance
of
cluster
API
components
and
therefore
I
started
contributing
to
Cluster
API
operator.
We
are
going
to
discuss
it
today.
Alex
created
several
topics
about
that
yeah,
it's
nice
to
be
here
with
you,
yeah
thanks.
A
I'm
I
don't
see
any
new
hands
waste.
Okay,
then
open
proposal
readouts.
There
is
only
one
proposal
about
I
guess
this
is
the
managed
kubernetes
proposal.
Jack.
Is
there
any
date
on
this.
D
Not
a
lot
of
change
from
last
week,
I
think
I've
addressed
all
the
open
comments,
so
just
waiting
for
responses
from
folks
just
a
normal
process
is
chugging
along.
E
A
I,
don't
see
any
answers
great.
Moving
on
to
the
discussion
topics.
First,
one
the
release
team.
You
have
a
first
one.
F
So
yeah,
hey
everyone.
We
have
released
Cappy,
1.4.3
and
1.3.8
yesterday
and
I've
listed
in
the
release,
notes
in
line
to
that
statement
over
there
and
we
have
Cappy
1.5
beta
coming
up
on
June
27th.
A
Awesome
great
job
on
the
patch
releases
and
waiting
for
the
beta
tag.
Thank
you
release
team
for
all
the
great
work,
any
questions.
Does
anyone
have
any
questions
on
this.
A
G
Yeah,
hey
everyone,
so
this
topic
is
by
me,
but
and
overall.
So
our
folks
who
are
interested
in
this
and
if
you
feel
like
there
is
something
you
want
to
add,
just
feel
free
to
do
it
so
on
Monday
we
had
our
first
Community
call
and
wanted
to
give
an
update
on
what
what
happened
and
also
we
have
couple
things
I'd
like
to
discuss
today.
So
first
of
all,
we
released
a
new
Alpha
release.
We
fixed
a
lot
of
box,
did
a
lot
of
optimizations.
G
Now
it's
in
much
better
State
when
it
was
previously,
and
also
we
were
discussing
a
couple
interesting
things
during
the
call,
and
one
of
them
was
that
David
proposed
what
if
we
use
helm
to
install
KP
providers
using
operators,
so
KP
operator
already
supports
Helm,
so
you
can
there's
a
Helm
chart
rate
you
can
deploy
it
with
Helm
and
David
said
what?
G
If
we
make
some
templates
and
you
can
pass
some
arguments
to
helm
and
it
will
also
create
some
gappy
providers
in
a
similar
way
like
like
you
can
do
right
now
with
cluster
CTL,
you
can
initialize
a
management
cluster
with
a
single
command.
So
what
if
we
can
do
the
same
with
gapy
operator
to
have
a
relatively
similar
experience
and
wanted
to
ask
what
people
think
about
this.
A
I,
don't
see
any
handspace
Alex.
Is
there
like
an
issue?
Is
there
a
tracking
issue
where
people
can
comment
on
if
people
who
are
interested
invested
not
join
the
meeting
and
so
on,
so
they
can
take
a
look
at
the
notes
and
go
back.
G
H
A
Okay,
Jack.
D
A
D
Yeah
thanks,
hey
Alex,
so
I
noticed
there
that
this
is
specified
that
this
installs
Cappy
providers
does
this
also
install
copy
itself?
Is
this
a
way
to
create
a
management
cluster
from
scratch.
E
D
Cool
cool,
so
one
of
the
potential
use
cases
is
essentially
a
crd
that
acts
as
a
Cappy
installer
that
you
can
Helm
install
onto
a
kubernetes
cluster
to
bootstrap.
So
it's
essentially
doing
what
cluster
CTL
does.
Yeah
cool
sounds
fun.
I
Yeah
a
couple
of
questions,
my
camera
doesn't
work.
I
will
try
to
fix
it
later,
but
so,
first
of
all,
when
we
go,
we
want
to
get
restart
provider.
As
of
today,
we
rely
on
provider,
basically
building
the
publishing
some
manifest
and
and
maintaining
those
Manifesto
clusterities,
so
that
that
means
that,
if
you
want
to
to
I,
think
that
we
are,
you
don't
want
to
maintain
a
chart
for
all
the
providers
by
yourself.
But
you
expect
that
the
provider,
publish
and
charts
is.
G
Coming
true,
so
not
exactly
sorry,
if
I
wasn't
clear,
so
KP
provider,
sorry
KP
operator
provides
you
a
set
of
crds
like
we
call
them
just
providers
versus
core
provider,
infrastructure
provider,
bootstrap
provider,
similarly
to
Cluster
CTL,
and
you
can
apply
the
crds
on
your
management.
F
G
I
G
A
I
I
think,
let
me
say
at
the
end
the
operator
is,
is
looking
forward
to
solve,
to
make
it
easier
for
copy
to
work
with
githubs.
I
C
Yeah
and
also
yeah,
we
need
to
create
a
list
of
providers.
We
want
to
support
this
way
like
Kappa,
kab,
Z,
I,
don't
know
what
else
cup
G
and
so
on
and
technically,
as
I
understand,
we
just
need
one
to
prepare
like
a
quick
start
solution
that
allows
to
deploy
the
whole
infrastructure
copy.
C
All
providers
quite
easily
with
one
comment,
maybe,
instead
of
Helm,
we
can
just
create
a
short
script
for
that
I,
don't
know
just
to
install
everything,
because
besides
we
also
need
to
deploy
a
search
manager,
for
instance,
it's
a
requirement
for
operator
to
work.
C
We
can
include
it
in
this
Helm
chart
as
well.
It's
possible,
but
I,
don't
want
to
make
Helm
chart
like
super
complex.
That
supports,
like
almost
everything.
Maybe
we
can
keep
it
a
little
bit
more
gradual
I,
don't
know.
C
C
A
At
10
in
follow-up
questions,
oh
I
see
Stefan
as
a
question.
Oh
not
a
question
in
the
comment,
which
is
maybe
it's
an
option
to
just
consume
some
cert
management
chart
as
a
dependency
for
the
operator
and
chat.
I
Yeah
I
kind
of
agree
with
Stefan.
Let
me
say:
if
we
have
to
be
declarative,
everything
should
be
declarative,
so
we
should
not
have
a
scripts
or
CLI.
Otherwise,
we
kind
of
yeah
we
we
fall
back
in
the
same
problem
that
we
added
with
Caster
cutter.
Second,
with
regards
to
the.
I
To
the
point,
hunting
operators
of
the
alternative
in
cluster
cutter
in
the
docks
I
would
like
to
see
a
demo
first
just
to
understand
where
we
are
etc,
etc.
I
This
would
be
will
help
me
to
understand
how
to
judge
my
only
concern
is:
is
I,
don't
have
a
I'm
not
against
this
I'm
happy
to
have
a
model
to
give
more
option
to
our
user
I'm
just
a
little
bit
concerned
by
the
state
of
the
book
and
the
quick
start
specifically,
which
is
already
over
complex
and
with
30
provider
listed
and
stuff,
like
that,
so
not
a
poster
that
we
have
just
to
find
a
smart
way
to
do
it.
J
I
was
just
gonna
say:
yes,
it
seems
like
there's.
Openness
I'd
be
happy
to
help
in
terms
of
the
doc
design
layout
of
what
that
could
look
like
I
just
think
you
know,
Cecile
brought
up
a
while
back
about
having
a
Helm
chart
for
Cappy
and
I.
Think
we
should
be
having
two
different
options
here
and
and
also
we
need
to
make
it
more
discoverable.
So
I
could
help
with
that.
J
But
the
other
thing
I
was
going
to
say
is
in
terms
of
the
argument
of:
do
we
have
each
provider
have
their
own
Helm
chart
I
would
be
more
of
a
fan
of
having
the
operator
have
the
option
to
have
the
different
providers
have
the
health
chart
and
having
it
built
in
and
then
having
the
providers
infrastructure
providers.
You
know
contribute
as
as
desired
to
that
location.
J
I
mean
the
existing
operator
already
supports
all
the
existing.
You
know
cluster
CTL
provider,
values
I
think
so
you
have
to
like
go
look
that
up
to
find
out
what's
the
the
value
that
you
specify
to
get
it
installed,
so
it
just
makes
sense
to
me
to
have
something
integrated
and
of
course,
every
provider
is
going
to
have
something
slightly
different.
J
So
I
think
there's
a
way
that
you
could.
You
could
have
placeholders
or
other
things
there
and
allow
people
to
contribute.
So
that
way
we
don't
have
you
know
30
different
home
charts
and
things
like
that.
A
Thanks
for
that
David
does
anyone
have
any
questions,
any
follow-up
items.
A
A
Oh
so
someone
added
this
issue
in
the
comments
and
I
linked
it
in
the
doc.
Is
this
the
right
issue?
If
folks.
C
A
Awesome,
oh
great,
so
if
anyone
has
any
follow-up
questions
or
want
to
discuss
this
further
be
square,
then
start
probably
discussing
on
the
issue
itself.
I,
don't
see
any
other
hands
raised
for
briza.
You
have
the
next
one.
I
Yeah,
so
this
is
a
follow-up
of
last
week
demo,
so
we
merged
a
memory
provider,
the
the
first,
let
me
say,
Port
of
code
from
the
repository
where
we
were
developing.
We
were
prototyping
this
we
measured
in
copy.
I
So
the
the
idea
is
that,
since
this
is
it
a
bunch
of
code,
we
are
going
to
accept
feedback
and
follow
up
in
fixes,
even
if
the
the
things
it
is
still
merged.
We
opened
an
issue
with
the
where
we
are
tracking
all
the
stuff
that
we
still
have
to
do,
and
I
also
proposed
a
doodle
in
order
to
have
a
session
where
I
can
basically
make
a
code
word
rule
for
this
provider
and
show
everyone
how
we
implemented
it
if
they
are
interested.
A
So
please
take
a
look
at
the
initial
PR
and
let's
find
a
time
that
works
for
most
people.
Does
anyone
have
any
questions
comments,
concerns.
A
No
I
don't
see
any
answers.
Moving
on
to
provider
updates,
Kappa
Richard.
E
Yep,
hello,
everyone
yeah,
so
we
released
version
2.1.4.
Today
it's
got
a
couple
of
minor
fixes
in
it
and
also
if
you
did
upgrade
to
2.1.3,
there
is
a
fixing
for
the
built
binaries.
Some
people
have
problems
on
Alpine,
so
yeah.
If
you,
if
you
pull
into
that
bucket,
feel
free
to
up
upgrade
today.
E
A
It
awesome
thanks
Richard
and
that's
on
the
new
release.
B
Yes,
that's
me
sorry,
I
forgot
to
add
my
name.
I
just
wanted
to
drop
a
quick
note
that
we've
moved
the
in-class
typing
provider
to
kubernetes
six.
Now
it
lived
at
the
Telecom
org
before,
but
now
it's
finally
in
kubernetes
six.
A
A
Thank
you
Jacob
for
that
Richard
again.
E
Yeah,
this
is
a
about
a
new
provider.
Cap
quok
I
think
it's
quite
a
good
name,
but
really
I
was
bored
one
day
and
I
saw
that
clock
wanted
a
Cappy
provider
for
their
project,
so
I
did
start
to
to
build
it.
But
then
someone
reached
out
on
slack
and
said
they
were
interested
in
building
the
provider
for
quack.
So
we
sort
of
agreed
it.
E
It
could
be
used
as
a
learning
exercise
and
how
to
to
build
an
infrastructure
provider.
So
really
it's
just
a
a
shout
out
to
people
that
are
interested
in
building
providers,
but
what
a
more
guided
or
mentored
approach
feel
free
to
to
help
out
on
this
project
or
ping
me
happy
to
guide
people
through
I
know,
there's
there's
a
couple
of
people
that
already
wanted
to
to
do
it
more
as
a
mentored
approach.
So.
A
E
Also,
if
you're
just
interested
in
clock
go
check,
it
out
never
play
with
it.
A
Yeah
great
also
I
believe
the
you
did
a
kubecon
talk
on
how
to
build
new
providers
right
so
that
and
I
think
that
talk
is
already
Linked
In
The
Cafe
book.
So
if
folks
are
interested
in
how
to
start
building
a
new
Cappy
provider,
that's
a
great
place
to
start
looking
at.
E
Yeah,
that's
right
there.
This
isn't
the
same
GitHub
org
as
well
as
that
walkthrough
awesome.
A
That's
it
for
provided
updates.
Does
anyone
have
any
questions,
comments,
concerns
or
does
anyone
want
to
add
any
topic?
Last
minute.
A
K
Sorry,
so
how
does
this
the
the
Quark,
basically
as
compared
to
the
cube
Mark
provider,.
E
Pretty
much
the
same
same
thing,
you
know
once
you've
seen
book,
which
is
which
is
a
project
an
upstream
project.
It
doesn't
require
a
back-end
cluster
either.
So
I
guess
that's
one
major
difference
and.
K
H
Here
is
more
of
a
virtual
way
to
scale
yep.
Okay
makes
sense.
A
Awesome
any
more
questions.