►
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
On
to
our
csi
secrets,
community
call
it
is
thursday,
may
13th
just
note.
This
call
is
under
the
code
of
conduct
for
the
cncf
and
with
that,
let's
go
ahead
and
kick
it
off
and
prior
to
us
going
into
the
agenda.
If
there's
anyone
new
that
wants
to
introduce
themselves
to
the
community,
please
go
ahead
and
do.
A
A
Okay,
all
right,
so
let's
go
ahead
I'll
be
moderating.
A
Does
anyone
feel
like
taking
notes
yeah?
I
can
help
okay,
thank
you,
english,
okay
and
let's
go
ahead
and
start
the
agenda
items
here.
So
I
don't
think
lucas
is
present
we'll
go
ahead
and
table
his
discussion
item
for
the
next
week,
but
it
is
interesting.
So
please
take
a
look
at
the
external
secrets.
A
Just
looking
at
this
repo
looks
pretty
interesting.
So
looking
forward
to
that
conversation
with
that
tommy
you're
up
and
we're
going
to
talk
about
the
aws
status.
B
Yeah,
I
just
want
to
make
sure
we
have
an
item
here
to
give
everyone
an
update
on
that
I
think
definition.
I
took
a
look
at
the
code
and
these
were
the
kind
of
like
seven
issues
that
popped
out
and
then
I
believe
there
I
don't
have
the
links
here,
but
there's
some
fears
in
progress
to
get
the
integration
test
set
up.
So
I
think
those
are
just
the
only
things
I'm
getting.
The
aws
provider
has
stood
resolving
that
issue.
A
C
I
think
the
interesting
scenario
is
for
all
the
providers.
Today
we
run
it
against
kind
cluster
and
then
we
use
auth
that
can
work
on
a
kind
cluster,
but
for
aws
providers
they
need
to
run
it
on
an
eks
cluster,
so
they
can
use
the
underlying
identity
for
auth
purposes.
So
in
the
pr
they
have
the
cluster
creation.
As
part
of
the
batch
test
suite
and
some
other
recommendation
based
on
review
that
we
added
was,
they
can
move
the
cluster
creation
to
a
script
and
do
that
before
the
batch
test.
A
All
right
thanks
national,
let's
see
busy
day
for
you
today,
tommy
next
up,
we
got
the
atomic
writer
optimization.
B
Yeah-
let's
see
this
was
brought
up
last
week
about
on
rotation
if
there
are
no
changes,
how
to
how
to
not
have
to
then
fetch
all
secrets
again,
I
think
this
was
brought
up,
because
the
aws
provider
has
a
way
to
look
at
secrets
in
a
more
lightweight
fashion
than
accessing
the
secret
to
determine
whether
or
not
it
has
been
changed,
and
there
was
one
of
the
issues
with
the
atomic
trader.
Is
that
to
make
any
updates?
You
have
to
provide
the
full
the
full
update.
B
And
so
I
I
provided
this
kind
of
like
summary
of
the
issue
here
and
my
proposal
is
that
to
continue
using
or
to
still.
B
That,
since
we're
not
using
it
yet
but
to
keep
the
atomic
writer
as
the
plan
going
forward,
but
that
a
way
to
implement
the
optimizations
is
to
if
there
are
no
changes,
you
can
just
return
empty
like
a
success
but
with
empty
files
and
nothing
will
change
and
that.
If
there
are
partial
changes,
though,
you
would
need
to
provide
still
the
full
view
of
the
mount
file
system.
B
And
then
I
think
in
some
other
distance
initiations
that,
like
providers,
can
still
do
their
own
caching
to
keep
values
around
if
they
wish.
But.
B
I
guess
my
position
here
is
that
I
would
rather
reuse
the
atomic
writer
than
trying
to
to
modify
it
to
support
kind
of
like
partial.
B
D
One
clarifying
question
on
that:
the
the
way
that
the
provider
would
know
that
nothing
has
changed
is
based
on
the
versions
given
for
what
already
exists
in
the
mountain
right.
So
it's
not.
It
doesn't
have
to
like
read
the
fire.
I
think
it's
just
based
on
like
the
the
versions
getting
passed
back
and
forth.
B
Yes,
I
think
I
looked
I
need
to
refresh
myself
here.
I.
B
Yeah,
because
I
think
it
was
it's,
it
can
be
difficult
to
know
whether
or
not
like
the
secret
provider
class
has
changed
depending
on
how
you're
writing
stuff
in
your
responses
but
yeah,
I
did.
I
had
a
little
section
here
on
detecting
changes,
and
I
I
do
one
description
of
how
you
might
detect
it
and
to
detect
secret
provider
changes.
B
But
yeah
the
it
can
kind
of
be
opaque
to
the
driver
depending
on,
since
I
think
at
least
like
the
gcp
one,
and
maybe
that
azure
one
two
just
write
back
the
the
secret
and
the
version
and
don't
write
back
any
information
about
the
paths
that
the
secret
was
in
the
so
yeah.
B
There
probably
could
be
some
feature
work
on
on
that
note,
taking
or
more
like
there
are
some
alternatives
of
like
you
know,
hey.
B
Including
versions
on
the
file
like
for
each
file
do
the
secret
and
version
and
they're
taking
like
that,
which
is
you
know
I
think
possible
currently,
but
there's
no,
you
know
explicit
direction
to
providers
on
how
to
do
that
or
how
they
should
so
it
couldn't
be
fair,
but
in
order
to
kind
of
make
forward
progress
on
removing
the
file
permissions
from
the
providers,
that's
my
my
initial
proposal.
B
Yeah,
so
if
people
could
just
take
a
look
at
that
and
leave
any
comments
that
they
might
have
and
then
the
next
one
is
also
part
of
the
atomic
writer,
I
got
the
the
pr
merged
that
vendors,
the
atomic
writer
unmodified,
except
for
comments.
B
B
But
just
would
like
some
some
soak
time
before
you
know
providers
go
all
in
on
that
to
make
it
more
explicitly.
Opt-In,
testing
to
like
beta
behavior.
A
E
Sorry,
just
real
quick,
I
just
want
to
make
sure
there's
like
we
capture
any
action
items.
So
specifically,
you
know
based
on
what
tommy's
saying,
should
we
open
issues
in
respective
provider
repos
to
make
sure
they
track
this,
or
do
we
want
to
make
sure
we
create?
You
know
specific
gating
issues
for
like
say:
zero,
zero,
zero
23
to
make
sure
we
capture,
you
know
certain
things
as
a
blocker
for
for
23
release.
C
E
E
Okay
cool,
so
it
sounds
like
all:
the
providers
are
doing
it
right
so
so,
if
one
of
the
providers
did
not
implement
it,
then
how
does
that
impact?
The
driver.
B
B
There
are
code
paths
that
be
like
deleted
once
all
of
the
providers.
So
first,
I
think
we
should
probably
open
an
issue
with
the
aws
one
just
so
that
we're
like.
B
And
that
they're,
you
know
on
track,
probably
to
get
you
know
included
before
yeah.
Hopefully
they
are
included
kind
of
postwar
this
so
yeah
proposing
creating
that
as
an
action
item
for
the
aws
and
then.
B
B
Yeah,
maybe
an
issue
tracking
on
the
driver
of
like
just
tracking
when
it
will
be
required
so
that.
B
Once
it's
it's
like,
I
guess
we're
gonna
like
implement
it
in
the
providers
as
optional,
then
implement
it
in
the
providers
as
default,
and
then
the
driver
makes
it
required.
B
If
the
providers
haven't
made
it
the
default,
then
it
just
kind
of
like
blocks
deleting
the
pass.
E
Right
right,
I
just
wanted
to
highlight
that
making
it
default
in
driver
is
sounds
like
it's
dependent
on
providers,
which
is,
it
makes
sense,
but
also
like
it
kind
of
sets
a
precedence
to
how
we
roll
out
features
and
drivers,
and-
and
this
codependency,
like
you
know,
is
this
okay
right
and
if
not,
how
do
we?
What
do
we?
What
do
we
think
is
the
right
way.
I
guess.
D
Yeah,
I
just
chairman,
say
from
the
vault
provider
point
of
view:
yeah.
We
definitely
want
to
have
at
least
one
release
where
it's
in
there
optional
and
then
one
release
where
it's
default
so
yeah
we
probably
want
to
have
at
least
two
releases
out
there
before
it
becomes
required
for
the
driver.
So
I
think
I
think
this
yeah.
It
sounds
like
that
can
fit
in
with
the
plan
outlined
here.
If,
if
that's
a
meaningful
to
everyone,
I
mean
we're
kind
of
vaguely
aiming
at
monthly
releases.
D
Are
you
what's
the
cadence
for
the
driver?
Is
it?
Is
it
just
as
the
milestones
become
complete,
or
do
you
have
like
a
time
cadence
as
well.
C
C
B
Considering,
I
think,
rita
you
and
anish
are
the
only
ones
that
have
done
their
releases.
I
believe
I
think
doing
it
more
than
monthly
might
be.
I
don't
know
that
we
have
the
capacity
to
do
more
than
monthly.
E
B
Okay,
well,
I
I
only
have
suggestion
permissions
on
the
dock,
so
I'll.
Let
someone
else.
F
Win
windows
containers
cuts
their
releases
on
the
second
tuesday,
I
believe,
of
the
month,
so
I
think
if
it
can
align
with
that,
you
can
also
pick
up
those
security
fixes.
D
And
then
node.21
is
the
first
version
that
supports
the
returning
contents
back
in
over
grpc
right.
B
Yes,
that
will
write
it
using
the
like
just
naive
file,
writer
and
the
merged
one.
It
has
a
tested
like
backwards
compatibility.
So
if
a
mount
is,
you
know
already
has
files
in
it
and
it
is
a
remount
call.
It
should
correctly
deal
with
that,
but
that
is
and
that
code
path
should
also
correctly
go.
If,
like
it
went
from
the
provider,
writing
it
to
the
driver.
Writing
it
with
the
with
the
atomic
writer.
E
Sorry,
can
you
just
repeat
that
for
notes,
notetakers
driver
writing
file
is
is
introduced
in
21
right,
but
we're
not
going
to
require
until
until
23
right.
E
B
D
Okay,
so
is
that
the
note
above
in
the
agenda,
is
that
what
you
meant
when
you
said
default
until
23.?
I
think
I
misunderstood
that
one.
C
D
C
The
default
for
the
provider,
I
think,
that's
probably
what
tommy
meant
right
like
provide
us,
implement
it
and
then
keep
it
as
an
optional
feature.
So
that's
what
we
did
for
azure
as
well
and
then
probably
test
with
the
optional
feature
flag
in
the
e3
and
then
at
the
next
release,
maybe
just
make
it
as
default
and
then
see
if
it
introduces
any
issues.
B
Yeah,
the
one
thing
I
didn't
want
was
providers
to
see
it
implemented
in
22
and
then
immediately
make
it
the
default.
B
A
A
All
right
that
takes
us
to
the
end
of
the
agenda,
but
hey.
I
do
want
to
shout
out
tommy
and
anish
for
this
session
at
kucon
I
heard
it
was
800
plus,
maybe
even
more
so
congrats
to
you
too,
on
that.
G
I
have
a
basic
question
to
ask:
maybe
someone
can
answer
why
we
never
had
like
a
release,
tag
zero,
one
zero
like
we
are
going
till
all
the
way
to
22
23
like
do
we
have
any
thought
behind
our
burgeoning.
B
Yeah,
I
think
we
have
the
an
issue
tracking
a
stable
release,
and
you
know
as
like
we're
just
still
working
towards
that
and,
as
you
can
see,
there's
like
still
things
in
flux
in
the
interface
between
the
driver
and
the
providers-
and
you
know
I
think,
before
we
go
stable,
probably
like
having
more
more
confidence
that
that
interface
isn't
gonna,
be
changing
as
rapidly
as
it
has,
because
we've
we've
switched
from
like
exec
providers
to
using
grpc
to
providers
to
yeah.
C
So
for
stable
release,
it
will
be
1.0,
so
the
idea
is
when
we
do
1.0.
Basically,
we
don't
introduce
any
breaking
changes,
so
we
don't
change
anything
between
driver
and
provider.
We
when
we
say
there
is
a
contract,
and
that
is
what
we're
going
to
abide
by
and
we
will
make
sure
that
it's
backward
compatible
and
then
also
it
involves
when
we
find
bug,
fixes
basically
patching
and
then
backforting
any
fixes
that
we
need
to
so
today
we
don't
backport
anything
if
we
find
any
bugs,
then
it's
basically
just
part
of
the
next
release.
C
E
I
think
brings
up
a
good
point,
though,
like
I
think
even
pre
stable
right.
Maybe
we
should
be
doing
like
maybe
like
zero
one,
zero,
zero,
two
zero,
allowing
us
to.
E
G
Yeah,
I
mean
the
the
way
I
was
assuming
the
the
semantic
versioning
was
or
the
way
I
was
following.
What
is
it's
like?
G
The
patches
are
okay,
but
then
we
release
a
certain
set
of
features
and
we
do
like
probably
zero
one
zero
zero
to
zero
things
like
that,
and
we
have
those
features
out
there
and
we
keep
on
testing
them,
and
I
mean
that
that
indicates
our
sort
of
a
major
feature,
release
or-
and
things
like
that
and
patches
will
of
course
do
along
with
them.
G
So,
like,
I
think,
probably
the
this
atomic
file
writer
probably
is
like
a
significant
big
feature
from
the
driver
perspective,
so
we
could
have
done
like
a
a
minor
version
upgrade
and
have
it
indicate
our
user
that
you
know
that's
that's
something
big
we
did
and
of
course,
then,
once
we
have
everything
stable,
we
move
to
one
zero
and
hopefully
we'll
stay
at
one,
as
I
said,
to
keep
the
backward
compatibility.
G
Yeah,
that's
why
I
was
curious.
I
mean
it's
all,
probably
just
following
some
sort
of
standards
or
guidelines,
so
I
was
curious.
What
we
followed
here.
B
We
yeah,
I
think
today
we
had
just
been
version
number.
It
goes
up
up
by
one
each
each
time
we
do
a
release.
We
didn't
that's.
E
B
Following
semantic
versioning.
F
E
Bring
up
a
really
really
good
point,
at
least
I
and
I'm
definitely
supportive
of
cutting
like
minor
versions
start
cutting
minor
version.
E
I
mean
we
have
experience
from
other
projects
where
we
can
leverage
the
same
pattern
for
pre,
stable
or
even
after
we
cut
stable
right
same
concept.
It
is
when
we
cut
a
release.
It's
it's
usually
the
minor
allowing
us
to
support
patches
and
cherry
pick
onto
previous
minor
releases.
E
We
just
haven't
talked
about
it,
because
this
is
something
that
we
said
was
blocking
stable,
right,
defining,
versioning
and
backward
compatibility
or
how
we
do
releases.
I
think,
there's
an
issue
for
this.
We
just
haven't
really
had
time
to
define
it.
Yet,
let's
I
I
again,
I
saw
some
thumbs
up
so
for
the
next
release
and
I
think
tommy
you're
cutting
that
right.
Maybe
you'll
do
the
honor
cutting
v01.
E
That
way,
we
could
have
release
branches
and,
and
do
like
chair
picks
for
any
hot
fixes
or
whatever
we
haven't
had
to
do
that
knock
on
wood
yeah.
So
what
do
people
think
about
like?
Do
it
on
the
next
release?.
C
G
F
G
Yeah-
and
we
do
have
our
crds
right-
I
think
they
all
are
in
alpha.
So
do
we
tie
those
version
upgrades
to
our?
I
I
mean
I
don't
I'm
just
throwing
it
out
like
what
what
sort
of
consideration
we
might
want
to
take
in
take
into
account.
E
E
A
All
right,
so
that
takes
us
to
the
end
any
other
discussion
items
or
comments.
B
I
think
we
should
continue
with
that
until
we
have
yeah
agreements.
B
On
oh,
I
do
think
that
yeah
anish
and
I
were
going
to
cut
a
release
on
monday,
so
I'm
going
to
try
try
to
do.
A
That
all
right,
okay-
so
that's
it
next
meeting-
will
be
on
the
27th.
We'll
push
lucas
item
out
about
the
external
secrets.
So
please,
if
you
got
time
from
now
until
the
next
meeting
just
take
a
look
at
that
repo.
So
we're
prepared
to
have
a
really
good
conversation
about
that
and
with
that
we
can
go
ahead
and
in
the
meeting.