►
From YouTube: Secrets Store CSI Community Meeting - 2021-09-02
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
Okay,
hello,
everyone
thank
you
for
joining
our
csi
secret
store.
Community
call
today
is
september,
2nd
2021
and
just
as
a
reminder,
this
call
does
fall
under
the
cncf
code
of
conduct.
A
If
you're
not
familiar
with
that,
please
visit
the
repo
and
look
up
the
code
of
conduct
document,
I
always
say
be
kind
to
each
other
and
you'll
do
fine
all
right.
We
got
a
a
small
set
of
agenda
here
so
like
I'll,
let
you
go
and
then
don't
know.
If
anyone
else
wants
to
talk
about
anything
else,
we
could
use
the
remainder
of
the
time
to
look
through
any
particular
issues
and
or
pr's
to
discuss.
A
But
with
that
let's
see,
I
can
probably
do
double
duty
now,
since
it's
a
small
agenda
so
I'll
take
on
the
notes
or
if
anyone
has
an
affinity
to
do
notes,
that's
fine
but
I'll
go
ahead
and
take
it
on
with
that.
Nelec
I'm
gonna
hand
it
over
to
you.
You're
gonna
talk
about
the
possible
implementation
of
edes.
B
Okay
cool,
so
we
have
this
one
issue
where
we
want
to
implement
the
automatic
full
integration
test
for
our
sizing
images.
So
what
we
today
currently
do
is
when
we
have
a
release
where
we
first
publish
the
images
to
staging
docker
registry
and
then
promote
them
to
production
one,
but
we
never
test
this
staging
images
that
we
create.
We
just
go
ahead
and
create
our.
I
mean
we
go
ahead
and
publish
the
production
images
and
then
just
create
a
rules.
B
So
I
was
looking
into
this
implementation.
So
one
thing
I
noticed
is
or
one
straight
implementation
for
this
could
be
like
once
our
published
job
or
that
push
image
job
is
completed.
We
can
trigger
another
job
which
can
run
our
a
tweet
test,
but
pro
does
not
have
ability
to
run
test
or
trigger
test
after
completion
of
another
test.
So,
like
let's
say,
I
cannot
put
a
trigger
on
that
push
image
for
a
job
to
trigger
another
job
which
supposedly
run
e2e
test
for
us.
B
B
So
couple
implementation
we
thought
so
first
one
was:
we
can
just
create
a
post
submit
job
and
we
can
run
that
on
the
release
brag.
So
when
the
release
is
merged,
we
can
probably
just
check
for
whether
the
image
is
available
or
not,
and
once
the
image
is
available,
we
can
continue
on
testing
or
do
do
our
e3
test.
So
that's
like
an
option
one,
but
it's
sort
of
a.
B
We
are
essentially
doing
a
polling
over
there
so
like
when
the
job
triggers.
What
we
can
do
is
so
we
have
at
that
point.
We
have
already
updated
our
newer
tag
into
our
make
file.
So
all
we
have
to
do
is
just
kick
the
job
and
then
keep
on
pulling
the
registry
with
the
right
image
tag,
and
once
that
poll
is
successful,
if
you're
able
to
pull
the
docker
image,
then
just
go
ahead
and
run
the
test
or
the
other
way.
B
What
we
can
do
is
what
this
is
actually
suggested
is
we
can
just
have
a
github
action,
and
once
this
push
image
job
is
completed,
we
can
go
and
kick
that
github
action
manually
and
that
action
will
essentially
run
our
intuit
test,
and
once
that
is
successful,
we
can
just
go
ahead
and
create
a
release.
B
So
I
think
both
of
this
approach
sounds
good.
I
mean
anyways
like
the
trigger
would
have
been
super
good,
but
since
that
is
not
possible,
I
am
not
leaning
towards
any
of
the
the
like.
There
is
no
favorite
implementation
for
safe
from
my
perspective,
but
just
wanted
to
take
the
community's
opinion
as
to
what
what
all
thing
might
be
a
good
way
to
go
forward.
C
Yeah,
I
am
leaning
towards
the
github
action
just
because
we
don't
have
to
poll,
and
then
it
can
be
user
initiated
and
like,
and
it
also
gives
us
the
flexibility
that
we
can
run
it
any
time
right
like
we
design
it
in
such
a
way
that
the
image
is
configurable
like
we
can
also,
like,
maybe
run
it
against
release
or
like
at
any
given
time.
We
can
cut
rc's
and
run
against
it.
C
So
I
feel
like
we
can
give
the
registry
name
and
the
tag
as
as
the
variables
for
the
pipeline
and
then
we
can
trigger
it,
and
then
it
would
only
run
against
the
e2e
provider.
So
no
overhead
of
running
against
each
provider
with
the
staging
image.
D
Yeah,
I
think,
there's
another.
I
think
it
might
be
another
bug
about
like
release
candidate
releases.
D
There
could
be
something
here
where,
like
we
build
staging
images
much
more
frequently
and
use
the
staging
images
in
the
mls
like
release
candidate,
so
like.
D
I
guess
it
doesn't
really
help
with
like
the
release
process,
but
doing
something
like
just
the
e2e
provider
et
test
on
staging
images
like
with
like
a
periodic,
proud
job,
but
maybe
that
doesn't
really
solve
the
specific
release.
Workflow
problem
so.
C
D
Yeah,
like
I
guess,
if
we
are
building
the
staging
images
and
testing
them
like
using
this
image
of
staple
the
staging
images
in
sha
like
daily
or
something,
then
we
could.
We
could
make
our
release
process
just
be:
promoting
the
staging
image
to
the
prod,
like
not
rebuilding
a
new
image
as
part
of
the
release,
but,
like
our
releases,
take
yesterday's
staging
like
which
should
have
been
tested.
Something
like
that.
But.
B
B
That
would
work
because,
like
we,
we
pretty
much
do
the
release
in
a
single
shot
right
like
we,
we
have
a
release
branch.
We
merge
our
origin,
upgrade
to
the
release
branch
that
essentially
kicks
and
creates
the
staging
image,
and
then
we
go
go
on
and
create
the
release
right
after
it
or
promote
the
images
to
write
after
it.
So,
like
I
mean,
and
either
we
can
have
periodics
like
too
frequently,
I'm
not
sure
if
that's
a
right
way
to
do
it
per
se.
B
But
if
we
have
the
periodics
on
the
on
the
schedule
that
we
have
today,
we
will
have
to
sort
of
do
like
create
staging
images
today
and
do
release
tomorrow.
Something
like
that
just
to
have
it
yeah.
D
I
guess
what
I'm
thinking
is
like
we
could
make
it
less
involved
for
the
released
person,
but
make
it
like
take
longer
right
where
it's
like.
D
Maybe
it's
you
know
it
does
take
a
day
or
two
days
to
do
the
release,
but
it's
just
like
fewer
involved
steps,
but
I
I
I
think,
I'm
fine
with
whatever
you're
proposing
it's
just
throwing
out
like
a
alternate
universe.
B
Yep,
okay,
I
think
I
think
I
like
the
idea
of
bit
of
action
and
the
the
idea
of
running
it
on
demand
for
any
kind
of
image
tags
per
se.
It's
manual,
but
I
mean
that's
okay,
like
that's
the
best
option
we
have
today.
I
guess.
A
B
Sorry
I
didn't
get
that
fill
it.
A
C
A
All
right
now
like
do
you
have
enough
to
go
on,
do
have
we
figured
this
out
or
is
that.
B
Yeah
yeah,
I
mean
sure
I
think
I
think
the
general
consensus
is
we
can
go
on
with
a
greater
action
approach.
C
B
Makes
sense
I'll
put
the
same
two
options
there
and
maybe
just
summarize
our
discussion.
What
we
have
today
in
the
call.
C
A
B
Actually,
there
is
one
pr-
maybe
I
can
quickly
talk
about.
This
is
about
yeah
the
first
one
724
provider
support
metrics,
so
we
are
listing
what
different
features
are
supported
by
different
priorities.
If
you
can
scroll
down,
I
just
have
just
tagged
like
a
different
folks
for
working
on
the
individual
provider.
So
if
everybody
can
confirm
whether
this
looks
good
or
not
or
you
know,
if
you
have
to
make
any
changes,
that
would
be
helpful.
C
Yeah,
maybe
also
post
it
on
slack
and
then
I
tag
tom,
and
I
mean
everyone
like
tom.
B
A
C
Then
the
sinkhole
one
we
we
haven't
reviewed
it
yet,
but
we
will
review
it
post.
The
1.0
like
it's
a
new
feature
so
like
it,
won't
be
introduced
before
1.0,
but
post
1.0.
We
can
review
it
and
then
add
that
in
the
next
release,
okay,
awesome.
A
That
sounds
good
to
me.
Yeah
I
was
gonna.
Ask
so
are
we
on
track
here?
Will
1.0?
Will
that
happen?
This
20
this
month.
C
A
D
A
Think
that's
all
we
have
I'll
update
the
notes
on
here,
just
open
it
up
anything
else.
Anyone
wants
to
mention
or
discuss
commental.
A
Okay,
take
silences
now
all
right.
Our
next
meeting
will
be
in
two
weeks,
so
that'll
be
september,
16th
I'll
go
ahead
and
get
this
recording
posted
and
out
on
the
slack
channel,
and
with
that
we'll
go
ahead
and
just
close
out
the
meeting
hope
everyone
has
a
safe
holiday
weekend
for
labor
day
and
we'll
see
you
in
a
couple
of
weeks.