►
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).
B
A
A
D
E
B
F
G
A
E
Yeah
so
last
week
we
released
0.012
for
the
csi
driver.
There
were
a
few
notable
improvements
that
we
added
basically
a
separate
reconciler
controller,
and
that
would
create
the
secrets
instead
of
having
the
secret
creation.
As
part
of
the
note
published
volume
and
one
of
the
major
bug
fixes
that
we
had
was
basically
honoring
the
context
when
invoking
the
provider.
E
Cubelet
has
a
context
timeout
of
about
2
minutes
3
seconds
when
trying
to
mount
the
volume
and
when
invoking
the
provider
we
were
in
setting
the
context.
So
we
added
that
so
that
if
the
provider
doesn't
respond
within
that
stipulated
time,
then
the
mount
would
actually
fail
and
then
it
would
be
retried.
The
next
time.
E
Also
with
0.012,
we
deprecated
an
old
option
of
configuring,
the
volume
attributes
as
part
of
the
pod
spec-
and
this
has
been
added
in
the
release,
notes
and
I
think
tommy
added
for
google
provider
plugin
and
they're
already
using
secret
provider
class,
but
for
hashicorp.
Maybe
we
also
need
a
doc
update
just
to
remove
references
of
providing
the
values
in
the
prospect.
E
Yeah
also
with
this
release,
we
switched
to
using
the
gci
repo
for
hosting
the
images
before
previously.
It
was
in
docker
hub.
But
now
we
have
moved
to
gcr
and
the
way
it
works
is
there's
a
docker
directory
in
the
driver,
repo,
where
we
update
the
image
version
and
once
the
image
version
is
updated.
A
B
A
C
B
A
B
A
E
Yes,
okay,
I
did
that
right.
So
in
0.0012,
like
I
said
previously,
we
fixed
the
issue
by
setting
the
context
for
the
provider
calls.
Let
me
see
if
I
can
find
it
here,
so
what
we,
what
I
was
thinking
was:
maybe
we
can
also
try
and
propagate
the
context
time
out
to
the
provider
so
that
the
provider
can
just
automatically
use
the
con
user
context
with
that
particular
deadline
and
when
it
makes
calls
to
it,
the
external
secret
store
right
now
for
the
azure
provider.
E
What
I've
done
is
I've
added
a
default
context
timeout
in
the
provider,
but
there's
no
way
to
configure
that,
but
if
we
can
do
that
through
the
driver,
we
basically
need
to
add
another
flag.
Apart
from
the
four
flags
that
we
already
support,
that
would
just
be
context
timeout
equal
to
and
then
the
driver
would
determine
what
the
timeout
should
be
and
just
invoke
the
provider
with
that.
E
H
E
Right
so
I
mean
there
was
an
issue
on
a
user
had
posted
on
slack.
What
they
were
seeing
was.
The
provider
call
was
basically
timing
out
and
it
turned
out
that
the
issue
was
they
had
a
network
policy
configured
on
the
cluster
because
of
which
there
was
no
egress
traffic
and
there
was
no
context
in
the
exact
exact
command
used
to
call
the
provider.
So
what
happens?
E
So
then,
the
next
time
when
cubelet
tries
to
recall
the
driver
for
node,
publish
it
checks.
If
the
volume
is
already
mounted
and
then
if
it
is
already
mounted
it
does
not
remount.
So
then,
it
just
responds
back
saying
it's
already
mounted
and
because
of
that,
the
pod
starts
up
without
the
file
in
the
path
and
if
they
are
using
the
sync
secret
feature,
then
the
secret
does
not
get
created,
because
no
publish
volume
did
not
create
that
in
the
old
release.
E
So
what
we
did
as
part
of
this
pr
is
exec.command
all
we
just
switched
to
using
exec.commandcontext
so
that
we
include
the
cubelet
context
in
the
provider
call
and
if
the
context
times
out,
then
the
process
is
kill
and
then
there
is
a
context
context
timed
out
error.
So
in
that
case
we
successfully
unmount
and
then
the
next
time
the
driver
invokes
the
provider.
We
remount
the
whole
thing.
E
G
E
Is
that
pretty
much
the
only
action
right?
It
is
so
I
mean
the
provider
usually
invokes
like
a
lot
of
external
calls
right
and
then
it's
always
easier
to
embed
the
context
in
that
with
the
timeout,
so
that
it
responds
back
within
the
time
otherwise,
most
of
the
times
it's
just
context
or
background,
and
the
call
just
came
on
and
the
process
is
clear.
E
E
But
again
it's
using
the
kubernetes
client,
rather
than
just
running
batch
commands.
So
the
pr
in
this
are
switches
to
using
ginkgo,
but
it
still
continues
to
use
cube
city
I'll,
apply,
cube
city
will
create
and
tutorial
commands.
Basically,
it's
just
doing
an
exit,
dot
command,
and
I
just
want
to
bring
this
up
so
that
we
can
have
a
discussion
on
what
we
think
would
be
the
right
way
to
move
the
e
to
e
test
suite
to
a
different
framework.
E
B
E
C
C
B
I
mean
so
maybe
maybe
the
asses,
like
maybe
folks,
on
the
call-
could
take
a
look
at
this
pr
and
chime
in
kind
of
do
a
comparison
between
what
we
have
with
the
bath's
edes
and
this
pr
and
see
which
one
you
would
like
to
work
with.
It's
actually
a
good
way
to
to
see
you
know
if
this
actually
enhances
the
contributor
experience.
B
B
A
E
E
C
Yeah,
I
think
I'll
I'm
still
reviewing
the
the
rotation,
which
is
like
the
next
thing.
That's
yeah.
I
think
I
just
want
to
keep
this
in
mind
because
it
will
save
our
plug-in.
Our
plug-in
has
to
get
the
surface
count
for
the
pod,
and
that
takes
a
number
of
round
trips
and
a
number
of
like
permissions
and
stuff
that
this
would
save
so
just
making
sure
that
they
kind
of
can
converge
in
the
future.
B
E
C
E
But
I
believe
he
has
a
branch
which
has
the
changes,
so
maybe
the
next
time
you
can,
I
mean
I
think
we
probably
have
to
go
down
that
route,
because
the
kept
like
I
said
is
probably
only
count
going
to
come
up
in
120,
but
also,
if
there's
a
way
possible.
We
need
to
design
it
in
such
a
way
that
when
the
120
comes
and
121
onwards,
we
could
just
have
users
move
to
using
that.
Instead
of
having
the
overhead
on
the
driver
for
the
rotation.
G
I
noticed
there
was
like
a
an
issue
a
day
or
two
ago.
It's
like
hey.
What's
the
status
of
this
project
and
so
yeah,
I
did
want
to
make
clear
that
it's
we
kind
of
want
to
get
it
to
a.
I
don't
know
longer
long
term,
like
what
the
steady
load
of
of
you
know
resource.
We
will
apply
like
how
how
tracking
will
be,
but
we
definitely
want
whatever
is
there
to
be
a
stable
production
usable
like
within
the
capabilities
we're
offering
they're
solid,
and
so
that's
our
immediate
term
goal.
B
Thanks
yeah,
that
makes
sense.
I
recall
you,
you
were
talking
about
cleaning
up
the
implementation
a
bit
along.
You
know
a
while
back
so
yeah.
This
is
probably
a
good
time
to
do
that.
If
there's
anything
you
need,
you
know
in
terms
of
integrating
with
the
latest
csi
release
and
any
integration
or
issues
you
see,
please
definitely
reach
out
to
the
team
here.
I
guess
we'll
definitely
want
to
address
any
of
the
integration
issues
you
see.
G
Yeah,
I
think,
as
I
recall
most
of
the
most
of
it
was
fairly
like
literally
like
cleaning
things
up
and
like
stabilizing.
There
was
one
open,
almost
design
level
decision
that
was
hanging
out
there.
I
think
you
and
I
had
both
commented
on
like
sort
of
I
can't
remember
the
detail
it
had
to
do
with
where
a
secret
was
rendered,
because
you
have
the
secret
name
and
then
the
value
within
the
secret
and
there's
like
multiple
ways
to
like
denote
what
you're
fetching
and
where
it's
going.
G
B
Right
right,
I
think
how
you
want
to
present
the
metadata
or
this
you
know
the
the
parameters
that
users
can
provide
in
in
the
secret
provider
class
is
up
to
the
the
provider
right
as
long
as
you
know.
Obviously,
we
will
need
to
update
the
e
to
e,
make
sure
we're
testing
the
right
objects
now
right
and
the
the
right
behavior
the
updated,
behavior
and
notify
users
with
the
the
changing
behavior
in
the
next
release.
B
I
think
it
would
be
helpful
to
you
know
similar
with
the.
Similarly
with
the
driver
release
planning
like
it
might
be
helpful
to
also
do
that
for
each
of
the
providers,
so
that
at
least
people
know
like
hey.
This
is
the
scheduled
release
and
here's
what's
coming
that
way,
it's
more
visible
to
users.
C
C
B
B
B
E
B
B
G
B
Yeah
speaking
of
the
google
provider,
I
think
what
I
would
love
to
eventually
do
is
have
like
a
like
a
table
here
in
the
reap
me
that
has
all
the
providers
and
then
and
then
like
a
check
mark
next
to
all
the
capabilities
as
well.
So
people
can
see
like
okay,
which
feature
is
available
in
which
provider
and
then
a
link
to
like
say,
example
or
readme,
or
something
right
like
that
would
be
super
helpful
for
users.
B
C
C
B
A
E
Issue
up
really
quick,
I'm
not
gonna!
In
the
last
community
meeting,
we
discussed
about
optionally
installing
the
ability
to
sync
kubernetes
secrets
right
like
in
helm,
so
one
thought
around.
That
was,
if
we
do
do
that,
and
do
we
enable
it
by
default
and
just
provide
a
knob
for
users
to
disable
it,
or
do
we
disable
it
by
default
and
if
they
need
it,
they
explicitly
need
to
enable
it,
because
one
concern
with
disable
disability,
disabling
it
by
default,
is
when
users
install
it
with
helm.
B
E
Sync
secret
is
not
enabled
and
then,
when
they
try
it
out,
it's
going
to
fail
and
then
they
probably
will
have
an
issue
open
and
then
they'll
after
we
tell
them
that
you
need
to
set
this
flag
to
enable
that
feature.
Then
they
might
try
that.
But
so
I
think
what
do
we
think
is
the
best
way
to
do
that.
E
C
C
My
concern
was
that
this
feature
allowed
you
to
copy
secrets
to
kubernetes
secrets,
but
that
could
be
like
an
escalation
of
privilege
or
like
you
might
not
want
your
secrets
copied
into
like
a
durable
storage
that
isn't
your
like
fault
or
key
vault
or
gcp,
and
it
gives
the
driver
permissions
over
your
secrets
to
like
read
and
write
all
secrets
in
the
cluster
which
you
might
not
want
to
grant
to
this
for
some
reason.
So
that
was
just
kind
of
why
I
filed
the
issue
and
started
looking
into
it.
B
B
This
was
requested
by
a
lot
of
users
because
they
didn't
want
to
change
their
application
code
to
read
from
a
file
a
lot
of
applications.
You
know
the
12-factor
pattern
right.
They
actually
just
use
like
environment
variables
and
they're
they're
used
to
like
read
from
kubernetes
secrets
or
or
whatever
right.
B
G
If
I
could
a
question,
I
just
as
I
don't
know
kind
of
think
about
this
just
now,
yeah
that
sort
of
rounding
down
to
off
by
default
seems
like
intrinsically
the
right
way,
I'm
a
little
I'm
not
quite
following
the
backwards.
Compat
like
we
don't
have
secret
syncing
now
right.
So
what
what's
the
backwards?
Compat
issue.
B
So
so,
currently
the
key
vault
provider
is
the
only
one
that
supports.
The
syncing
aspect,
however,
feature
is
on
the
driver
right,
so
right
now
we're
basically
trying
to
turn
it
on
and
having
it
configurable
in
the
driver,
so
that
so
that
there
is
a
way
to
opt
in
and
opt
out
and
the
current
behavior
is
we
give
elevated
privilege
to
the
driver
assuming
that
users
want
that
feature
on
right,
which
is
problematic.
So
this
is
why
tommy
is
looking
at
making
it
configurable.