►
From YouTube: Secrets Store CSI Community Meeting - 2021-09-30
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
All
right
well,
thank
you.
Everyone
today
is
september
30th
last
day
of
the
month.
This
is
our
bi-weekly
secret
store,
csi
call.
As
a
reminder.
This
call
is
governed
by
the
cncf
code
of
conduct.
If
you're
not
familiar
with
those
terms,
please
check
out
the
code
of
conduct
markdown
on
the
repo,
as
I
always
say,
if
you're
respectful
to
each
other
you'll
do
fine
all
right,
I'm
gonna,
hit
and
moderate.
If
someone
wants
to
take
notes,
we
got
a
pretty
pretty
short
agenda.
A
I
don't
see
any
announcements
being
made,
so
with
that
elect,
we
can
jump
right
into
your
pull
request.
So
you
wanna
go
ahead
and
talk
about
it.
B
Yeah,
so
this
is
just
I
wanted
to
follow
up
on
the
pr
so
we're
trying
to
put
this
stock
metrics
together
for
all
the
providers
and
what
features
they
provide.
So
I
think
there
were
just
two
outstanding
point
with
this
one:
with
the
ball
provider,
where
we
are,
we
wanted
to
confirm
whether
rotation
is
supported
or
not,
so
I
think
we
suggested
to
add
a
test
so
that
we
can
holistically.
B
You
know
validate
the
e2e
scenario,
whether
it's
being
rotated
or
not
in
the
with
the
provider,
even
though
it's
like
a
driver
feature,
so
I
think
tommy
created
pr
for
the
world.
Thank
you
tommy
for
that.
So
with
that,
I
think
we
are
good
on
walls
once
that
pr
is
merged.
We
can
say
that
vault
is
rotation
enabled,
so
that
should
be
good.
The
other
thing
is
aws,
so
unfortunately,
I
have
not
received
any
response
from
the
aws
folks.
B
Yet
so,
and
it's
been
a
while,
I've
tried
to
reach
them
on
slack
and
the
pr
as
well.
So
I
think
what
I'm
trying
to
suggest
here
is
maybe,
with
whatever
knowledge
we
have,
we
should
just
go
ahead
and
merge.
It
if
we
don't
receive
any
response,
and
if
there
is
any
change,
we
can
always
come
back
and
open
a
pr
and
fix
that.
What
what
does
everybody
think
about
it.
C
Yeah,
I
think
that's
fine,
because
we
tried
reaching
out
to
them
on
slack
dm
and
on
github
issues,
but
I
think
they
haven't
looked
at
it
in
a
long
time.
So
I
think
that's
fine,
like
we
have
a
lgtm
from
three
providers
and
then
for
what
we
know
from
aws,
we'll
just
go
ahead
with
it.
They
do
have
rotation
tests
and
all
that
in
our
test.
Suite
already
so
we
know
it
rotation
works,
so
we
can
just
go
through
our
test
suite
to
see.
C
D
Yeah,
I
agree
just
whatever
we
have
tests,
for
we
say
yes,
this
works.
B
Cool
yeah
I'll
try
to
close
out
this
week
with
test
and
other
stuff.
A
All
right,
thanks
intellect,
let's
see
next
up
nish,
we'll
talk
about
the
graduation
of
the
api
from
v1
alpha
to
be
one.
C
Yeah,
so
this
was
the
outcome
of
our
call
with
cigar
yesterday,
so
I
added
a
retroactive
depth
to
the
cigar,
called
just
to
get
more
reviews
and
eyes
on
it
so
that
it
can
get
merged,
and
then
we
can
cut
a
1.0
release
and
then,
when
we
had
the
convolution
one
thing
that
came
up
was
right.
Now
our
crd
apis
are
in
v1
alpha.
C
One
and
cigar
was
strongly
suggesting
that
we
move
from
v
1
alpha
1
to
v,
1
or
v
1
beta
1,
so
that
we
don't
have
to
rely
on
an
alpha
api
when
we
are
in
a
with
a
stable
release.
So
they
were
recommending.
We
do
this
before
we
call
the
project
stable,
and
I
wanted
to
add
a
item
here
just
to
see
what
folks
think
I
think
the
recommendation
on
the
call
was
just
to
go
to
v1.
C
So
I
wanted
to
see
if
we
have
consensus
on
that,
because
with
skipping
v,
one
beta
one
and
just
going
all
the
way
to
v
one
or
do
we
wanna
go
through
the
process
and
go
from
v
one
alpha
one
to
v,
one
beta
one,
even
with
data
we're
still
providing
an
api
contract.
Where
we're
saying
we're
not
we're
no
longer
going
to
break
api,
it's
still
going
to
be
backward
compatible
with
anything
that
we
had.
C
D
My
my
vote
would
be
to
directly
to
v1.
I
don't.
I
think
it
would
be
more
churn
and
I
don't
think
would
be
likely
to
learn
anything
additional
by
marking
a
v1
beta1
since
yeah
we
haven't.
I
don't
think
we've
changed
the
crd
definition
in
quite
a
while
so
yeah.
I
just
don't
think
that
there'd
be
much
benefit
to
doing
the
v1
beta
1.
C
So
I
couldn't
find
any
specific
process
which
says
you
have
to
go
through
the
the
graduation
phase
of
beta
and
v1.
I
think
it
typically
depends
on
the
project
how
they
want
to
do
it
right,
like
you,
want
to
go
to
beta
and
then
see
feedback
and
probably
decide
that
this
is
what
you
want
for
v1,
but
I
think
our
v1
alpha
1
has
been
very
close
to
v1
for
a
long
time.
It's
just
that.
We've
never
changed
any
of
the
fields,
because
the
mandatory
fields
are
pretty
less
like
what
we
have.
C
Okay,
yeah,
so
even
with
v1
or
v1
beta1
right,
like
any
new
fields
that
we
add
going
forward
it
just
shouldn't,
it
should
not
break
the
existing
id
right.
So
as
long
as
we
do
that,
so
we've
been
doing
that
even
today,
like
we've
added
new
fees,
it's
not
like
we've
gotten
rid
of
any
fields
before,
but
as
long
as
we
maintain
that
compatibility,
we
should
be
fine
like
in
the
future
as
well.
D
How
could
this
be
a
part
of
1.0.0
release.
B
Yeah,
I
think
I've
seen
some
few
messages
actually
in
our
flag
channel
as
well
people
asking
about
the
same
question.
So
maybe
we
can
update
that
as
well.
A
Thank
you.
Okay,
thanks
anish,
all
right,
that's
it!
I
just
want
to
just
make
an
announcement
here
that
our
next
call
falls
during
the
week
of
kukan
north
america,
so
we'll
go
ahead
and
cancel
the
meeting
for
the
october
14th
and
then
we'll
resume
the
meeting
after
that.
A
So
that's
it
on
the
agenda.
If
we
want
any
issues
on
in
the
repo
or
any
pr's,
anyone
wants
to
either
highlight
or
make
comments
on.
C
So
I
opened
a
github
issue
based
on
all
the
issues
that
we
were
facing
last
week
with
the
tests,
so
that
was
7.50
so
yeah.
The
first
issue
actually.
C
So
that
the
idea
was
today,
we
are
running
all
our
tests
on
the
default
pro
cluster,
which
is
part
of
google
infra,
which
means,
if
there's
any
issue,
that
we
want
to
debug.
Irrespective
of
that
issue,
then
we
still
won't
be
able
to
get
access
to
it
right.
So
we
have
to
work
with
the
on
call
test
and
for
on
call
when
they
get
time
and
only
then
we'll
be
able
to
look
at
it.
So
there
is
another
cluster
which
is
the
kubernetes
and
for
probable.
C
So
we
should
look
at
moving
all
our
test,
jobs
to
this
cluster,
probably
after
the
1.0
just
so
that
we
have
that
that
base
covered
and
then
whenever
we
need
to
debug,
we
can
still
do
but
the
last
week's
issue
with
test
infra.
I
think
the
fix
has
been
rolled
out
to
all
the
regions
now,
so
we
probably
can
remove
the
ip
table
fixed
at
a
later
time,
just
to
make
sure
that
the
fix
is
valid.