►
From YouTube: Secrets Store CSI Community Meeting - 2022-03-31
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
welcome,
it
is
march
31st
2022,
and
this
is
our
bi-weekly
csi
secret
store
a
call.
As
a
reminder,
this
call
falls
under
the
cncf
code
of
conduct
if
you're
not
familiar
with
the
code
of
conduct.
Please
visit
our
upstream
repo
and
view
the
code
of
conduct
file
and
that
will
give
you
all
the
information
on
how
to
interact
and
participate
in
these
meetings.
A
A
If
not,
I
think
dan,
you
have
the
only
item
on
the
discussion
and
with
that
I
will
open
the
floor
to
you
and
there'll
be
a
link,
and
let's
talk
about
the
sync
sync
options
with
the
demo,
so
it
looks
like
you're
going
to
give
us
a
demo
today.
Is
that
right.
B
Yes,
I'm
hoping
having
some
weird
internet
issues
today,
but
if
I
can
share
my
screen
and
everybody
can
see
it,
I
think
we'll
be
in
good
shape.
Okay,
let
me.
A
Bump
you
up
here
to
be
able
to
share
okay,
let's
see,
do
I
have
to
rejoin,
you
should
have
share
permissions.
If
not,
let
me
know,
and
but
I
believe
I
have
given
you
the
power
to
do
so.
B
B
B
Are
broadcasting
go
forward
awesome,
so
I
guess
I
could
just
bring
in
the
pr
real
quick
if
and
if
you
haven't
seen
yet
phil
and
I
have
been
kind
of
having
a
little
brainstorming
session
to
kind
of
expand
on
the
sinkhole
thing
that
I
was
working
on
a
few
months
ago.
B
But
the
the
idea
now
is
to
have
some
more
functionality
that
builds
on
top
of
just
this
one
boolean
value,
particularly
targeting
the
the
format
that
the
secrets
mounted
in
and
the
one
that
we're
discussing
was
was
json
since
the
aws
secrets
manager
mount
secrets
as
json
objects.
So
the
idea
was
to
take
all
the
key
value
pairs
from
the
json
object
and
then
sync,
those
into
a
single
kubernetes
secret
and
another
bit
of
discussion
we
had
was
addressing.
B
How
do
we
make
this
provider
agnostic
such
that
any
secrets
manager
can
mount
secrets
in
json
and
the
driver
will
be
able
to
handle
it?
And
the
first
thing
that
came
to
my
mind
was
the
fact
that,
if
you
don't
specify
which
key
in
the
secret
that
you
want
for
the
vault
provider,
it
just
sends
the
full
json
object,
including
all
the
metadata,
and
you
have
to
get
the
secrets
by
targeting
the
data.data
nested
object.
B
B
Or
if
you
don't
include
this
field,
then
it
just
syncs
everything
from
the
top
level
but
yeah
and
then
also,
if
you
have
like
multiple
secrets
that
are
mounted
as
json
objects,
each
one
of
those
will
become
its
own
synced
kubernetes
secret,
with
multiple
key
value
pairs.
B
B
So
I
have
a
vault
server
and
provider
running
locally
with
this
database
secret
and
it
has
two
key
value:
pairs,
username
and
password,
and
the
goal
is
to
take
into
consideration
the
fact
that
if
we
don't
specify
a
secret
key
in
the
the
object
parameters
in
the
spc
that
we
can
take
advantage
of
the
fact
that
it's
mounted
as
a
json
object
and
sync
each
of
those
key
value
pairs.
B
So
just
for
the
sake
of
kind
of
just
targeting
those
database
credentials
we'll
take
out
jwt
off
as
well.
Okay.
So
from
this
configuration
we
can
expect
that
the
pods
gonna
have
three
secrets
mounted.
C
C
Yeah,
like
it
sounds
like
you're
gonna,
like
the
sync
option,
is
gonna
read
that
file
and
then
sync
that
as
a
secret
like
where's,
the
link
between
the
object's
name
and
the
and
what
is
being
synced
gotcha.
B
So
that's
a
byproduct
of
the
sinkhole
feature
since,
like
with
regular
secret
object,
data
like
we
can
manually
specify
what
the
secret
name
is
going
to
be
and
link
it
to
the
object
name
and
like
these.
When
we're
manually
setting
it
can
be
different
names
but
like
if
we're
syncing
it
all,
you
have
to
sacrifice
the
ability
to
name
your
say,
name,
your
secrets
differently
from
the
object
name,
so
the
sinkhole
will
take
whatever
is
listed
in
the
object
name
and
make
that
the
name
of
the
secret.
C
Okay,
so
the
secret
name.
There
is
both
the
name
of
the
secret
that
it's
going
to
create
in
in
kubernetes,
and
it
is
the
name
of
the
file
that
it's
going
to
use
to
sync
right:
okay,.
A
B
A
B
When
sync
all
is
true-
yes,
okay
and
I
can-
I
can
go
into
more
detail
on
that,
because
I
did
want
feedback
on
one
of
the
ways
I
handled
doing
that,
especially
with
the
with
the
nesting
of
the
secret
and
further
into
the
file
system.
B
B
So
yeah
you'll
you'll
see
the
naming
come
up
here
so
sinkhole's
true
and
it's
the
name
of
the
secrets
based
on
the
object
name
and
if
we
start
nesting,
we
need
to
handle
like
that.
Slash
we've
got
to
change
it
to
be
hyphen
separated,
or
at
least
that's
how
I
handled
it.
B
So
we
have
those
two
secrets
there,
and
then
we
have
db
creds
and
then
I'll.
Just
let's
show
that
we
have
two
key
value
pairs
in
a
single
secret.
Those
are
targeted.data.data
and
then
the
other
two
will
just
be
the
one
secret
each
so
oops.
B
Yeah,
so
for
the
password
we
just
have
the
one
key
value
pair
and
then
the
same
would
be
true
for
for
username
and
the
the
the
rest
of
the
examples
are
pretty
much
the
same.
So
I
don't
feel
like.
I
need
to
go
over
all
of
them,
but
those
were
like
the
the
the
main
features
added
with
sync
options.
C
Could
I
see
the
the
secret
provider
class
because
I
guess
I
missed
what
was
happening
with
the
does
the
I
thought
when
you
showed
the
database,
one
like
object,
name
or
no
sorry
to
do
like
the
database
username
does
that
have
a
data.data
field
within
it
that
first
secret?
B
C
It
so
to
the
driver
that
first,
like
the
objects
right
there,
I
should
pick
out
the
database
username
right
and
then
put
it
into
a
file
called
database.
Slash
username!
Yes,
right
is
the
json
path
right
like
like,
but
that
file
on
disk
is
just
gonna,
be
username.
It's
not
gonna,
be
a
json
formatted.
B
Okay,
got
it
yeah,
so
these
two
fields,
format
and
json
path-
are
like
they
do
follow
the
hierarchy
here.
So,
like
the
top
level
format,
option
will
be
inherited
by
everything
listed
in
objects
unless
specified
within
this
secrets
list.
B
C
Okay,
okay,
so
sink
all
meant
sync
all
three
of
those
individual.
But
then
you
had
more
specific,
hey
for
the
db
creds
object's
name
treated
as
a
json
file
with
the
json
path.
B
And
this
plain
text
at
the
top
level
that
wasn't
needed:
that's
the
default,
just
being
verbose
for
the
sake
of
the
example.
D
This
looks
good
right,
like
I'm
on
a
high
level.
I
have
two
comments
right.
So
one
is,
I
think,
as
part
of
this
feature,
we
are
adding
two
things.
One
is
we
are
providing
an
option
facing
call
like
that's
what
I
thought
was
the
initial
pr,
but
then
also
the
line
27
to
30
in
the
spc
is
basically
adding
something
like
templating.
So
as
a
user,
I'm
giving
a
template
to
say
like
hey.
This
is
what
the
structure
of
my
secret
is.
B
Yeah,
like
I'm
sorry
I
want
to,
I
want
to
make
sure
I'm
understanding
your
question.
Can
you
can
you
say
it
again?
Yeah.
D
That's
the
first
feature,
but
the
second
feature
that
you
are
adding
in
this
pr
is
from
line
number
26
to
30
in
the
secret
provider
class
you're
also
providing
an
option
to
template
it.
Basically,
the
user
is
telling
you
what
the
structure
of
the
secret
is
like
it's
a
json
and
then
what
the
fields
are,
and
they
only
want
to
extract
a
single
field
from
that
secret
when
they
want
to
sync,
they
don't
want
to
sync
the
entire
json,
so
you're
providing
an
option
for
them
to
like
give
a
template
and
then
do
that
right.
C
D
B
D
I
mean
if
we
have
to,
we
can
right
like
so
the
reason
I
actually
wanted
to
say
it's
two
different
features
is
so
that
we
separate
it
like
if
we
want
to
implement
it,
because
templating
is
something
that
I
think
would
be
nice
for
users
to
have
like.
This
is
the
same
thing
that
aws
provided
had
requested
right,
like
even
for
them
like
when
users
downloaded
today,
they
just
have
like
a
huge
json
blog
that
they
download
from
secrets
and
then
when
they
want
to
sync
it
as
kubernetes
secret.
D
B
D
Yes,
so
like
they
basically
can
parse
through
the
secret,
and
then
they
split
that
into
different
values,
and
then
today
they
send
that
as
different
files,
because
the
driver
only
understands
individual
files
when
it
sinks
a
secret
like
it
doesn't
actually
look
into
it.
So
that's
what
aws
does
like,
so
they
are
doing
it
at
their
provider
level,
and
then
I
think
at
that
point
we
said
we
might
think
about
it
at
the
driver.
D
So
if
we
want
to
add
it
like,
I
would
say,
let
me
split
this
into
two
separate
things
like
sync:
all,
as
is
is
okay
like
it
makes
it
easier
for
users
to
configure
they
just
do
sync
call,
and
the
behavior
is
exactly
same
as
what
it
is
today
and
then
the
templating
can
be
a
whole
new
feature
on
its
own,
which
is
more,
which
is
more
different
types
that
we
support.
C
Okay
yeah,
I
was
going
to
say
that
the
like
the
json
path
thing
that
you
did
there
seems
useful
without
the
sinkhole
like
so
like.
I
can
see
that
being
like
independently
useful
feature
and
so
like
tying
it
to
sync
all
seems
like
it
would
be
more
restrictive
on
on
its
use,
but
I
could
see
right.
E
You
wanted
to
say
something:
no,
actually,
I
was
just
gonna
ask
like
for
this,
the
third
one
that
we
are
thinking
right.
This
particular
one
the
db
credits
like
so
are
you
forming
this
json
file
while
writing
it
to
the
mount
or
how
does
that
gets
created.
B
E
So
I
think
yeah,
that's
what
I
was
trying
to
understand.
So
this
is
the
response
that
we
get
from
the
vault
like
by
default
or
by
design
for
a
site
so
probably
yeah.
We
yeah.
I
think
then,
having
that
that
templating
would
make
sense,
because
then
we
can
figure
it
out.
How?
How
can
we
how
we
can
make
this
thing
as
generic
as
possible.
B
E
B
Got
it
I
don't
know
how
google
or
azure
send
secrets
do
they
have
an
option
for
json
or.
D
I
mean
we
just
get
whatever
is
there
and
then
whatever
is
how
whatever
format
it's
stored
and
then
just
send
it
in
plain
text
right
and
then
like
there's,
no
format
format,
it's
just
like
a
text
and
then
we
offer
different
encoding
options
if
it's
required
at
least
from
azure
perspective.
D
But
if
the
user
defines
a
particular
type
in
the
template,
then
the
expectation
is
that's
the
format
of
the
data.
If
they
say
json,
we
can
basically
assert
it's
json
by
just
doing
it
on
marshall,
on
ligma
our
marshal
on
the
data
right
and
then,
if
the
data
type
validation
fails,
then
we
just
add
it
out
there
saying,
like
hey,
look,
you
told
me.
E
Yeah,
I
mean
that's,
that's
what
I
was
sort
of
trying
to
think
like
when
we
do
that
data
dot
data.
We
are
kind
of
expecting
it
to
be
in
this
format
and
then
what?
If
it's
not-
and
you
know
how
we
can
handle
those
scenarios.
E
E
E
Oh
so
the
json
part
take
the
full
james
path.
Query
then,.
B
Because,
like
I
also
have
this
other
secret
jwt
auth,
the
example
there
was
like
for
that,
because
I'm
not
specifying
the
dot
data.data.jsonpath
like
you
get
request.
Id
is
a
key
value.
Pair
release.
Id
is
a
key
value,
pair
release
duration
and
you
get
all
these
at
the
top
level
as
their
own
key
value
pairs
within
the
secret.
C
C
Is
my
my
major
comment
there
so
that
like
because
I
could
see
wanting
to
do
that,
but
not
needing
to
like
having
to
specify
one
option
just
to
get
the
other
option
to
work
could
be
confusing
so
yeah.
I
had.
D
Is
around
the
naming
so
like?
If
you
have
the
nested
paths
today,
I
think
you're
just
converting
the
slash
to
hyphen
right
so.
C
B
D
Yeah
I'm
saying
if
there's
no
nesting
right
like
for
the
first
one
you
have,
so
you
can
send
the
12
line
12,
which
is
just
database,
slash,
username,
and
then
let's
say
that
there
is
another
secret
which
is
not
nested.
So
the
object
name
is
just
username.
Okay,
our
database
hyphen
username.
So
like
that's
just
the
object
name,
so
there's
no
nesting
in
the
second
one.
D
C
I'm
following
yeah,
I
think,
there's
also
like
I
don't
think
underscores-
are
allowed
in
kubernetes
secret
names.
So
there's
a
few
a
few
things
on
the
the
mapping
of
like
the
file
name
to
the
secret
name,
where
I
think
implicit
conversion
may
be
dangerous
or
like
we
may
want
to
allow
more
explicit
mapping.
C
So
that,
like
if
the
user
knows
that,
there's
going
to
be
a
conflict,
they
can
explicitly
choose
how
to
resolve
that
themselves,
rather
than
kind
of
just
having
an
implicit
behavior
right.
D
Yeah,
don't
like
the
tricky
thing
is:
if
we
do
some
kind
of
conversion
like
this
right
now,
the
user
has
to
rely
on
that
conversion.
So
at
any
point
so
because
whatever
we
provide
here
is
what
they're
actually
going
to
be
using
as
environment
variables
and
all
that
in
their
pods
right,
so
they're,
basically
going
to
reference
this
kubernetes
secret
and
then
they're
going
to
reference.
That
particular
key
and
say
like
give
me
this
as
an
environment
variable
in
my
pod.
D
So
whatever
we
do,
the
conversion
here
is
actually
like
a
contract
that
we
are
telling
users
that
this
is
how
we're
going
to
do
it
and
at
some
point,
if
we
decide
to
change
it,
that
becomes
like
a
major
breaking
change,
because
there's
no
way
we
can
make
that
backward
compatible
like
if
we
start
with
a
hyphen
and
then
let's
say
tomorrow
we
just
say
like
hyphen
doesn't
work.
We
want
to
make
it
hard.
B
D
B
Well,
I
mean
I
I
like
what
you're
saying
before,
like
the
idea
of
being
able
to
be
specific
for
secrets
that
the
user
knows
were
are
going
to
conflict
because,
like
I'm,
imagining
for
the
most
part
like
the
user
should
be
able
to.
B
If
the
user
understands
the
functionality
that
like
they
should
be
able
to
name
these
in
a
way
that
wouldn't
create
conflicts
but
like
there
should
probably
also
be
a
way
that
allows
them
to
be
more
specific
and
have
more
control
for
those
like
special
cases
where
they,
where
they
need
it,
which
this
current
implementation
doesn't
take
into
consideration.
So,
like
yeah,
I
think
I
think
that's
like
worth
wrestling
with
for
for
a
bit
see
if
I
can.
D
Yeah,
but
I
mean
this
is
really
good
like
I
think
the
demo
is
great
and
like
we
talked
about
rightly
splitting
this
into
two
features,
I
think
the
templating
thing,
as
is
adds
a
lot
of
value,
and
then
we
can
start
with
what
you
have
as
a
separate
pr
and
then
like.
We
can
build
on
top
of
that
to
expand
the
template
so
yeah,
I'm,
like
my
recommendation,
would
be
that
we
split
this
into
two
different
things.
D
Like
sync,
all
I
think
like
there's
still
certain
areas
that
needs
to
be
hashed
out,
but
the
template
thing,
if
you
split
it
into
a
separate
vr,
I
think
like
we
can
have
a
broader
conversation
on
if
we
want
to
change
any
of
the
apis
and
like
how.
D
I
think
that's
something
that
a
lot
of
users
have
requested
before.
I
think
it
might
make
sense
to
add
it
to
the
driver
now
like
now
that
you
actually
have
a
path
going.
A
D
C
D
D
For
now
and
that's
fine,
so
I
mean
I
would
think
of
it
as
just
moving
it
from
there
to
here,
with
making
changes
to
what
we
think
is
the
right
way
to
do
in
the
apis
and
then
aps
aws
just
use
that
and
say
like
okay.
We
don't
want
to
do
without
when
the
driver
is
already
doing
it
and
we
just
choose
what
the
driver
has.
Okay.
D
Like
I
think,
that's
the
format
we've
been
following,
like
anything,
that's
immediate
or
we
think,
helps
one
provider
and
we
tell
the
provider,
you
can
start
it
like.
That's
the
format
we've
been
doing
right,
like
providers
usually
supported
in
their
own
way,
and
then,
if
there
is
a
bigger
value
to
it,
then
I
think
we've
been
adding
it
to
the
driver,
like
even
updating
the
secret
product
class
to
add
a
field
to
support
it
or
basically
moving
the
feature.
A
Okay,
so
that
will
actually
I'll
just
share
how.
A
So
that
takes
us
to
the
end
of
discussion
topics.
C
A
Yeah,
just
I
want
to
pause
real
quick
because
looks
like
we
do
have,
member
from
the
community
and
we'd
like
to
just
do
quick
introductions,
hello,
ramy
or
rami.
Welcome
to
the
call,
would
you
like
to
do
a
quick
intro
for
yourself.
F
Sure
this
is
raymie
abraham.
Actually
I
was
attendance
last
week
again
just
oh.
A
A
A
Okay,
all
right
we're
gonna
go
through
some
of
these
issues.
Was
there
one
an
issue
you
wanted
to
focus
on
that
was
listed
here.
D
I
think,
from
the
last
time
we
discussed-
probably
the
first
two
are
the
new
ones
like.
I
think
we
discussed
in
906
last
time,
so
yeah.
A
Yeah,
I
know,
did
we
get
any
consensus.
D
So
the
good
thing
was
this
user
also
tagged.
Basically
the
reason
that
we
don't
allow
it
right.
So
when
we
were
actually
moving
the
project
from
ds
labs
to
cigar
sub
project
like
we
had
to
go
through
this
code,
audit
from
six
store
agent
cigar
and
then
the
recommendation
from
sig
storage.
Is
that
gets
secrets
and
then
writes
to
it?
We
should
only
make
it
read
only
and
not
allow
users
to
go
edit
it.
D
I
think
I
mean
my
opinion.
Is
we
still
don't
allow
it?
We
shouldn't,
because
the
driver
also
relies
on
those
secrets
written
in
the
mount
for
syncing
as
kubernetes
secret,
and
if
there
is
a
bad
actor,
they
can
basically
go
and
update
the
secret
file
in
their
part,
which
can
cause
us
to
update
kubernetes
secret
with
a
bad
value
that
could
affect
other
services.
C
Sorry,
I
just
posted
a
thing
going
against
what
you
just
said:
where
there
is
a
feature
request
asking
to
be
able
to
like
delete
files,
which
I
think
read
write
would
be
needed
in
order
to
to
do
that,
but
yeah.
I
I
think
there
is
a
trade-off
there.
It's,
I
think,
hard
to
hard
to
really
analyze
the
the
trade-off
of
whether
or
not
it's
better
to
like
open
up
the
risk
but
like
like
making
the
files.
C
Deletable
is
useful
for
workloads
that
want
to
consume
the
secret
load
them
into
memory
and
delete
them
so
that,
like
future
things
can't
like
a
file
path,
traversal
vulnerability
or
whatnot
can't
leak
the
secret
so
like.
I
think
there
is
a
security
argument
that
can
be
made,
that
being
able
to
delete
the
files
is,
is
good.
E
We
allow
like
at
least
azure
coder
allows
to
set
the
file
permissions
right,
so
wouldn't
that
solve
this.
C
C
We
don't
have
a
way
of
changing
the
file
ownership,
which
is
a
separate
bug
so
like
even
if
you
can
set
the
file
permissions,
you
still
have
to
be
root
in
order
to
like
it,
it's
all
still
owned
by
the
root
user
and
group.
The
files
written.
A
Okay
looks
like
we're
still
probably
in
need
of
a
little
more
discussion
around
this
before
we
have
something
concrete
to
go
forward
on.
D
C
Okay,
that
might
be
a
good
thing
for
us
to
ask
is:
do
they
say
why
they
want
to
write.
D
In
this
issue
here,
no,
I
think
in
this
the
previous
one,
if
you
scroll
again.
D
E
Yeah
app
updating
secrets.
I
think
there
were
some
users
who
asked
like.
Can
the
driver
update
the
secrets,
I'm
not
sure
if
they
had
the
same
same
thought
behind
behind
that.
B
C
May
be
something
where,
like
it's,
you
get
like
a
very
privileged
user
account,
and
then
you
use
that
one
to
then
assume
an
identity
of
a
less
privileged
account,
and
you
want
to
write
the
less
privileged
secret
right
click
instead
of
the
root
one
that
it
might
be
some
but
like.
It
would
be
interesting
to
see
the
actual
code
that
is
blocked
by
this,
so
that
we
can
better
understand
it.
C
D
Well,
I
think,
like
I
mean
from
what
I
understand
they're,
not
writing
it
to
keyword
or
anything
right,
so
they
basically
just
want
to
parse
the
file
and
then
like
maybe
edit,
the
file
to
do
something
else
and
then
just
consume
the
file
that
way
so
probably
like
they
have
like
a
unit
container
or
something
that
will
go
and
modify
it.
And
then,
when
their
actual
application
comes
up,
it
will
use
the
modified
file.
A
D
A
D
Benefit
of
this
is
they
basically
still
do
file
system
stuff?
They
don't
have
to
implement
any
cloud
provider
specific
way
to
get
the
secret
so
like.
If
they
have
the
same
file
stored
in
keyword
and
google
secret
manager,
they
don't
have
to
go
and
implement
the
api
right
they
can.
They
can
still
rely
on
the
file
system.
D
It's
probably
like
that,
one-off
step,
that
they
want
to
do
something
with
that
secret
like
remove
things
or
add
new
things
in
the
json,
so
they
can
consume
it
in
their
app,
but
yeah
I
mean
we
can
ask
them
what
really
the
use
case
is
like.
Why
do
they
need
it
to
be
read
right
like
what,
specifically
that
they
want
to
do?
D
D
A
Okay,
we
can
just
reach
out.
A
A
D
D
D
But
once
we
do
this,
I
think,
like
there's
one
additional
step
that
we
need
to
add
in
our
provider
doc
for
setup,
like
I
think,
when
we
had
initially
returned
the
dock,
for
the
providers
like
the
credentials
were
stored,
manually
provided
and
then
it
was
created
by
the
testing
for
on
call
and
then
we
used
to
consume
it.
But
we've
moved
to
a
pattern
where
you
create
a
gcp.
A
google
secret
manager
instance
add
your
secrets
there
and
then
just
use
like
syncing
to
sync
it
to
the
cluster.
D
Yeah,
I
don't
see
anything,
maybe
next
week,
monday
or
tuesday,
we
can
actually,
I
I'll,
send
out
a
zoom
link.
I
think
we
can
all
get
on
a
call
just
to
see
what
we
want
to
add
for
1.2,
like
we
added
one
feature,
but
I'm
thinking
we'll
go
through
all
of
it
add
it
to
the
milestone
and
assign
folks
for
each
of
it.
So
we
can
set
a
date
for
when
we
want
to
do
one
or
two
so
I'll
post
a
link
on
the
channel
and
then
like
anyone,
who's
interested.
A
Are
these
tagged
for
1.2.
D
No,
I
mean
that
that's
not
for
1.2,
like
it's,
not
a
blocker,
I
I
wouldn't
say
it's
not
it's
just
adding
it
like,
so
they
are
after
that
is
done,
and
it's
working
like
probably
the
next
step
for
us
all
of
us
is
to
go
and
do
a
code
audit
on
the
provider's
code
to
see
like
similarly
how
we
did
for
aws
right.
Let's
go
look
at
it.
A
A
Okay,
let's
go
ahead
so
our
next
meeting,
I
think
that's
going
to
be
april.
14Th
two
weeks
from
now
and
we'll
see
everyone
there
on
april
14th.