►
From YouTube: Secrets Store CSI Community Meeting 2020-07-09
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,
kick
it
off
got
more
just
joined
us
Thank,
You
general.
Alright,
so
today
is
July,
9th
2020
and
welcome
to
the
inaugural
I'm
CSI
secret
store
community
call.
So
those
should
have
the
link,
if
you
don't
to
the
the
dock,
to
the
meeting
stock.
If
you
have
that
link,
go
ahead
and
just
add
yourself
as
an
attendee,
so
we
know
that
you
showed
up.
A
A
One
thing
I
will
say:
I
know
most
calls
are
about
30
minutes.
This
is
scheduled
for
an
hour,
I'm,
not
sure,
we'll
take
a
whole
duration,
but
with
that
said,
I'd
like
to
for
the
agenda
items
too,
let's
go
ahead
and
just
prioritize
things
that
need
community.
You
know
since
this
on
so
anyone
that
needs
to
kind
of
draw
up.
The
call
for
the
second
half
can
do
so
and
have
the
opinion.
Sir.
B
A
B
B
Sure
can
I
just
I'm
really
really
excited.
Thank
you
guys
so
much
for
joining
this
call.
I
know
this
is
a
long
time
coming,
so
I'm
just
really
really
excited
to
have
a
lot
of
the
contributors
as
part
of
this
call,
and
and
obviously
you
know,
with
more
providers
joining
just
hoping
that
we'll
get
more
momentum
and
a
lot
of
the
provider
work
as
well
as
the
driver
itself.
B
So
my
name
is
Rita
I'm
an
engineer
for
Microsoft
I
created
the
v1
version
of
this
solution,
and
you
know
with
help
from
sig
auth,
we
were
able
to
basically
donate
it
to
kubernetes.
Take
off
and
I
see
Moe
on
the
call
as
well.
So
thanks
for
joining
so
yeah.
So
with
that
I'll
hand
it
off
to
other
folks
on
the
call.
A
Awesome
I'll
go
next,
I.
Think
I'll
echo
the
sentiment
there
Rita
totally
excited
that
we
got
this
call
kind
of
off
the
ground
excited
about
the
innovation.
That's
going
to
be
happening
so
I'm
still
getting
I'm
when
the
senior
program
managers
here
at
Microsoft,
I
work
along
with
Rita
and
I,
basically
manage
and
help
with
what
we
call
our
secure
persona
project
so
CSI
being
one.
We
have
our
array
deeper
at
the
entity.
Gatekeeper
and
the
key
of
kms
will
be
kicking
off
here
soon.
So
totally
looking
forward
to
working
with
everyone
here
and
excited.
A
C
I'm
Tommy
I'm,
a
Google
I'm
working
on
a
one
of
the
plugins
for
the
Google
secret
manager,
I'm
sort
of
just
got
that
open
sourced
through
all
of
our
wickets
recently
and
I'm
starting
kind
of
implementation,
and
it's
looking
at
hopefully
getting
it
included
as
a
supported
provider
shortly
into
the
the
parent
project
here.
So
thanks.
A
B
E
I
can
go
next,
I
guess
my
name
is
Brian
I'm,
also
part
of
Microsoft.
Now
I
was
working
with
Aneesh
fellow
in
Rita
during
my
apprentice
program,
actually,
where
my
project
was
helping
with
the
sequence,
rotation
and
the
CSI
driving
as
your
provider,
so
I'm
pretty
excited
to
be
here,
especially
as
a
kind
of
coming
on
more
as
a
contributor
from
the
community
as
I
am
switching
teams
and
won't
be
working
with
them.
That's
a
part
of
my
job.
F
F
F
A
G
A
B
For
sure,
so
these
are
some
of
the
items
that
were
called
out
by
Hoshi
last
time.
While
we
had
a
quick
sing
before
we
had
a
community
call
set
up,
and
so
I
put
it
here,
just
to
make
sure
we
cover
them,
I
think
only
probably
the
last
three
items
are
provider
or
specific,
so
we
can
skip
them
until
those
folks
can
join
today
they
have
a
conflict
because
of
company
All
Hands.
So,
let's
start
with
the
first
item,
I
thought
it'd
be
good
to
have
especially
the
provider
folks
to
chime
in
on.
B
You
know,
let's
discuss
what
one
dot
Oh
looks
like
for
the
CSI
driver
and
then
I
think
there
was
also
questions
about
what
does
one
dot.
Oh
looks
like
for
a
particular
provider.
So
if
you
don't
mind
clicking
on
that,
we
can
maybe
open
up
that
doc
and
if
you
have
any
comments,
feel
free
to
added
to
the
doc
as
well.
B
Okay,
and
if
do
you
want
to
kick
this
off
yeah.
D
Sure
so
we
have
a
couple
of
data
wishes
open.
So
what
I
kind
of
did
was
go
through
that
and
also
considered
what
all
things
would
be
really
good
before
we
can
call
the
CSI
driver
stable.
So
the
first
and
the
foremost
thing
is
basically
performance
and
load
tests,
so
just
to
ensure
that
the
board,
latency
and
during
startup
is
not
affected
by
having
the
CSI
volume
mount
and
also
when
there
are
a
large
number
of
Ford's
deployed.
At
the
same
time,
then
the
driver
can
handle
all
the
concurrent
parts
coming
in.
D
So
we
have
a
database
for
that,
and
one
idea
around
that
is
to
be
using
cluster,
the
loader
to
run
the
test.
I've
run
some
tests
locally,
but
I
think
what
we
essentially
want
to
do
is
have
this
as
part
of
the
driver
pipeline,
so
that
every
time
we
could
probably
run
a
periodic
job
and
just
have
the
load
test
results
published
on
github,
so
that
users
can
see
and
they're
aware
of
how
well
it's
performant.
D
So
the
second
one
is
basically
the
complete
lifecycle
of
the
secret
or
key
mounted
in
the
pod.
So
today
the
driver
supports
fetching
the
contents
from
the
external
secret
store
and
mounting
it
in
the
pod,
or
also
sinking
that
kubernetes
secrets,
but
one
other
part
of
the
story
that
needs
to
be
covered
is
the
secret
rotation.
So
what
happens?
If
the
user
rotates
the
secret
in
the
external
secret
store,
then
the
driver
would
need
to
fetch
the
rotated
secret
and
then
updated
update
the
mount
content
and
all
the
pods.
D
D
The
fourth
one
is
end-to-end
coverage,
so
today
we
are
using
patch
to
run
tests.
We
are
doing
that
today
for
the
driver
with
Azure
provider
and
the
world
provider,
and
essentially
where
we
want
to
go,
is
try
and
use
something
like
gingko,
even
maybe
cluster
API
test
framework
so
that
we
it's
easier
for
new
users
as
well
as
external
contributors,
to
add
new
tests
to
our
repo,
and
also
we
can
ensure
that
every
feature
that
we
support-
that's
part
of
the
documentation,
is
thoroughly
covered
with
unit
tests.
D
So
the
fourth
one
is
basically
just
having
a
complete
end-to-end
coverage
for
the
driver,
also
making
the
end-to-end
test
framework
easier
for
new
users
to
add
to
it
and
the
first
one
is
end-to-end
test
coverage
for
providers
as
well.
So
one
of
the
criteria
for
being
a
provider
for
the
secret
sauce
ESI
driver,
as
documented
in
the
readme,
is
having
an
end-to-end
test
pipeline
as
part
of
the
driver
so
that
any
driver
changes
that
are
made
are
compatible
with
all
the
providers.
D
So
we
want
to
ensure
that
so
we
want
to
have
that
for
all
the
providers
and
have
tests
for
all
the
features
that
have
it
and
the
sixth
one
is
basically
the
CSI
driver
and
kubernetes
versions,
support
ability
matrix.
So
basically
we
just
want
to
document
if
there's
any
braking
changes
or
if
there's,
if
it's
not
backward-compatible.
D
Basically
we
want
to
document
our
matrix
say
in
which
version
of
the
driver
is
compatible
with
which
kubernetes
version
and
this
could
apply
for
providers
as
if
there's
any
breaking
change
in
the
try
worth
where
the
provider
is
no
longer
compatible,
then
the
providers
could
document
I.
What
is
the
minimum
supported
version
and
they
could
have
a
matrix
for
that
I
think
Peter.
Do
you
want
to
do
the
last
time
oh
yeah.
B
And
I
think
part
of
you
know,
marking
it
to
one
dot.
Oh,
we
should
have
some
documentation
or
recommendation
or
default
deployment
for
a
che
for
the
driver
to
make
sure
it's
highly
available
for
production
usage
and
last
but
not
least
also
we
should
do.
We
should
probably
do
a
security
audit.
I
know.
Cn
CF
offers
security
audit.
So
maybe
this
is
something
we
can
look
into
all
right.
Any
comments
or
feedback.
A
B
We
did
one
for
for
the
open
gate,
keeper
project
that
when
there's
the
review
itself
takes
about
a
week
and
then
maybe
if
there
are
issues
like
so
back
and
forth,
maybe
two
weeks
and
then
and
then
the
project
team
is
we'll,
take
the
report
and
then
fix
the
issues
identified.
So
maybe
there's
some
back
and
forth.
So
altogether,
maybe
a
month
a
month
month
and
a
half
okay.
A
B
H
C
The
pod
tooken
for,
like
google
token,
which
I
think
it's
a
pretty
similar
pattern
to
the
vault
off
story.
But
some
of
that
stuff
could
be,
could
I
see
sure
I
could
see
that
running
into
performance
problems
depending
on
what
the
targets
are
for
below
test
and
then
for
secret
rotation
like
yeah.
That
seems
like
a
pretty
critical
like
user
journey,
but
I
haven't
really
been
to
the
current.
Like.
C
D
A
D
Yeah
I
can
pick
I,
think
Rita,
but
the
next
one
is
basically
the
kubernetes
secrets,
Inc
reconciler
feature
so
as
part
of
the
last
least
0.08
11
for
the
driver.
One
of
the
most
requested
feature
was
after
the
contents
is
mounted
in
the
pod.
They
also
wanted
the
secret
contents
to
be
created
as
community
secrets,
so
they
could
use
that
from
secret
reference,
or
they
could
just
inject
that
as
environment
variables.
D
So,
with
the
last
release,
we
implemented
that
feature
and
with
this
the
PR
link
that
I've
posted
here
we
have
kind
of
a
design
that
particular
feature
to
have
a
separate
controller.
I'd
do
the
reconcile,
and
so
the
driver,
just
if
the
controller
is
still
part
of
the
driver,
but
the
node
publish
volume
just
mounts
the
contents,
and
then
we
have
a
separate
controller
which
reconciles
reads
the
mounted
contents
and
then
creates
kubernetes
secrets
from
those.
So
in
the
github
issue
there
is
a
link
to
the
design
dog
and
sorry,
not
in
the
PL
description.
D
D
But
essentially,
what
we've
done
is
we've
added
a
new
CID
called
secret
provider
class
pod
status,
so
once
the
node
publish
volume
is
successfully
completed,
the
CID
is
created
as
a
tracker
which
says
mounted
is
true
and
what
the
target
path
is,
and
we
have
reconciler
that's
watching
on
this
particular
custom
resource
and
every
time
a
new
custom
resource
comes
in,
it
goes
and
checks.
If
the
user
wants
secret
community
secret
objects
out
of
these
contents.
If
they
do,
then
it
creates
our
secret
and
it
adds
the
secret
provider.
D
C
I
D
The
controller
is
still
part
of
the
driver,
so
the
reconciler
is
still
part
of
it
driver
it.
Trans
is
a
separate
process,
but
the
node
publish
volume
only
mounts
the
contents
in
the
part,
and
then
it
just
creates
this
tracker
cut
CID
and
that's
it
and
then
it
responds.
This
is
back
to
cube
light
saying
the
node
publish
volume
was
successful,
and
then
this
recurred
a
counselor,
that's
constantly
watching
for
this
custom
resource.
D
It
detects
this
new
custom
resource
come
in
and
then
it
goes
and
checks
if
this
particular
for
our
board
spec
requires
the
contents
as
a
kubernetes
secret.
If
it
does,
then
the
reconciler
creates
the
community
secret
and
in
the
owner
reference
for
the
community
secret.
It
adds
this
tracker
CID
interval.
C
Okay,
so
it's
still
but
the
driver
calls
the
plugin.
The
plug-in
writes
the
secret
that,
like
the
drivers,
controller
process,
green
snake
and
then
it
was
the
right
to
the
kubernetes
secret.
Okay,
is
there
a
standard
file
path,
format
that
all
of
the
drivers
heard
the
plugins
are
expected
to
support
is
the
one
that
I
have
currently
is
slightly
different,
simple,
like.
C
C
D
The
secret
provider
class,
the
one
that
the
user
defines
has
certain
mandatory
fields
right
like
the
provider
and
then
parameters
and
other
and
within
the
parameters,
it's
a
more
gently.
Basically,
it
could
be
specific
different
for
each
provider,
how
they
put
all
our
keys
that
they
support
in
that
array
like
the
object,
file
path
or
the
name
object
type,
so
that
could
differ
between
each
provider,
but
the
CLD.
I
think
in
this
design
document
is
another
cid.
That's
creatorÃs
tracker.
B
Right
I
know
this
is
probably
the
most
ass
feature
ever
for
this
solution,
as
well
as
like
the
old,
deprecated
flex
volume
solution-
and
we
explained
many
times
like
hey.
This
is
not
the
most
secure
option
and
but
I
think
there
is
still
need
for
from
a
lot
of
users
to
sing
synchronize
and
store
them
as
kubernetes
secrets,
so
that
they
can
use
that
unsecure
Bonetti
secrets
in
their
applications,
and
that's
why
we
added
the
feature.
But
it's
optional.
F
Yeah,
just
it
seems
like
we
have
gone
full
circle
and
fully
regress
back
to
Hoover
any
secrets
which
have
this
bad
habit
of
not
being
very
secret.
Your
your
fantasy
of
production,
encryption
keys
are
available
to
your
ingress
controller
or
whatever
right
like
it's,
not
not.
It's
not
exactly
the
hope
of
this
ok,
yeah
I,
you
know,
I'm,
pragmatic
I,
understand
folks
need
functionality.
I
was
the
the
path
of
I'm
gonna
use
all
this
complicated
stuff
to
like
wire.
In
my
secrets,
yeah.
B
Absolutely
and
I
think
from
what
we
learned
from
users
who
are
asking
for
this
feature.
I
think
the
pattern
is
such
that
there
are
users
who
really
care
about
the
security
of
their
50
secret
content,
and
they
will
they
won't
opt-in
right,
like
they
would
just
go
with
the
default
behavior,
so
the
most
most
secure
way
right
out
of
the
box
and
then
there's
people
who
don't
really
care
about
that
because
they
have
their
own
encryption
for
SCD.
F
Don't
think
it's
an
unfair
ask.
It's
just
I
hope.
People
understand
that,
like
the
core
security
gets
lost,
is
just
the
wiring.
Is
there
so
yeah
if
your
revolt
is
the
source
of
truth
and
cool
wealth
retains
being
the
source
of
truth
and
everything
sort
of
follows
along,
but
you
lose
the
sort
of
the
aspect.
F
If
you
know
you
can
imagine,
if
you
don't
allow
exact
and
you
have
all
the
right
admission,
plugins
and
the
right
constraints
on
your
pods,
the
only
thing
that
can
ever
read
your
pod
is
the
couplet
I'm.
Sorry,
the
only
thing
that
can
read
the
secret
is
the
couplet
and
the
pot
that's
supposed
to
have
it
right.
C
Yeah,
it
would
be
nice
for
this
beauty
chart
to
be
installed
bolt
separately
or
like
roll
bindings
to
not
be
included
like
white
people
can
I
some
of
those
things.
Cuz
yeah
I
think
we
also
want
to
I
thought
that,
like
the
use
case
of
the
ink
reverse
controller,
like
could
only
use
environment
like
environment
cars
unless
was
a
good
way
to
like
I
understand
they
use
cases
in
life
they
end
up
wanting
to,
but
I
want
it
a
little
bit
harder
for
them
to
ball.
C
B
B
So
I
think
the
feedback
is,
you
know,
maybe
have
at
least
from
like
the
helm
chart
have
a
flag.
Does
this
hey?
Do
you
want
to
use?
Do
you
want
to
enable,
like
the
secrecy
sink
secret,
its
feature
right?
If,
if
so,
then
we'll
deploy
all
the
roles
and
role
bindings
to
get
more
more
elevator
privilege
right?
If
not,
then
the
operator
who's
installing
this
is
basically
saying.
I
would
never
want
this
driver
to
do
this
and
therefore
we
should
not
deploy
those
role
bindings.
C
E
So
some
of
the
issues
that
we've
noticed
and
came
across
with
this
specific
implementation
is
that
there
is
a
race
condition.
So
since,
let's
say,
if
you
have
50
pods
deployed
on
to
your
cluster,
that
means
that
there
will
be
50
different
pod
statuses
and
the
reconciler
looping
through
each
of
those
50
pod
statuses.
If
you
make
it
through
25
pods
and
those
if
you
make
it
through
25
pods
and
then
all
of
a
sudden.
E
Let's
say
that
the
reconciler
goes
out
then
you'll
have
half
of
your
pods
will
be
updated
with
the
correct
secrets
and
then
half
of
your
pods
will
not
be
updated
as
well.
So
that
can
cause
a
huge
issue
with
possibly
breaking
your
application
and
also
the
case
of
if
your
reconciler
just
goes
down
in
general.
Then
if
there
is
an
unthinking
between,
if
someone
needs
a
specific
secret
from
your
secret
store
to
connect
to
a
database,
and
that
can
cause
an
issue
if
they've
updated
that
secret
on
the
database,
then
how
do
you
like?
E
E
And
so
yeah
I
think
I
need
to
just
linked
up
this
design
doc
for
the
C,
chord
rotation
and
I
might
need
to
add
permissions
correctly
to
it.
So
let
me
know
if
you
can't
get
access
and
I
can
give
you
access
to
that
doc
as
well.
C
E
So
how
I'm
running
the
reconcile
at
the
meantime,
just
from
the
first
iteration,
is
through
an
interval.
So
it's
gonna
work
on
a
pole
of
let's
say:
Parbat,
charlie
five
minutes
where
it'll
build
up
and
call
that
provider,
so
the
actual
version
and
is
tracked
within
of
the
secret
provider
or
the
pod
status
CRT.
So
that
way,
it'll
know
what
are
like
what
pod
is
running,
what
version
of
a
secret?
C
Yeah,
this
is
just
one
of
the
kubernetes
features
that
I
think
is
being
discussed.
How
to
pass
pod
service
account
tokens
to
CSI
drivers,
and
it
also
includes
a
mechanism
for
so
for,
including
that
and
the
node
was
a
publisher,
yeah.
The
node
publish
volume
to
include
the
token
for
the
pod
and
an
option
to
remount,
where
I
think
it's
similar
to
the
was
just
mentioned
about
repeatedly
I'm.
C
Token,
it's
like
issued
by
kubernetes
and
then
we
trade
that
for
like
a
GCP
identity
and
right
now,
like
my
implementation,
has
me
calling,
like
the
create
token
against
the
kubernetes
service,
accounts
api.
In
regard
to
get
that
information,
where
this
would
be
helpful
to
have
that
as
part
of
the
node
event,
yeah.
B
This
is
great
thanks
for
thanks
for
pointing
to
this
and
and
I
do
see.
She's
mentioned
in
the
proposal
as
well,
G,
so
deep
so
with
the
change
with
the
proposed
change,
do
you
think
for
in
terms
of
you
know
the
change
in
your
provider
code?
F
I
forgotten
the
exact
state
of
that
do
we
ever
get
to
like
making
a
cap
we
have.
A
cap
is
like
moving
forward.
We're
gonna
actually
do
this
because
it
was
disgusting,
stay
got
the
say:
God
doesn't
own
sick
storage,
so
we
can't
like
make
them
do
it
you
can
ask,
but
unless
their
coats
and
they
they
have
to
sort
of
do
the
I
mean.
If
someone
wants
to
do
the
work,
I'm
sure
people
would
be
happy
to
review
and
stuff,
but
yeah
I
was
curious.
F
D
I
think
last
week
we
made
a
change
in
the
master
where,
basically,
we
are
trying
to
only
match
the
secret
provider
class
in
the
same
namespace
as
the
application
pod.
Just
because
it
follows
proper,
odd
back
and
that
way
we
ensure
that
a
user
who
is
limited
to
a
particular
niche.
This
cannot
access
from
another
namespace.
So
this
one
mold
PR
that
we
have
open
where
the
user
could
configure
the
secret
provider
class
namespace
to
a
different
namespace.
Basically,
it's
providing
the
user
with
an
option
to
do
that.
D
B
Yeah,
so
my
initial
thought
on
this
was
more
like
the
the
usual
are
back
pattern,
where
only
objects
in
the
same
namespace
cannot
access
objects
in
the
same
namespace
right.
So
if
we
were
to
deviate
from
that,
we
might
run
into
some
weird
behaviors.
So
that's
why
I
think
we
want
to
open
this
up
to
everybody
to
to
get
feedback.
D
So
today
the
user
creates
a
custom
resource.
The
secret
provide
a
class
where
they
provide
all
the
attributes
for
the
provider
specific
details,
and
then
they
reference
that
in
their
fault.
So
with
the
change
that
was
done
in
the
master
last
week.
What
we're
doing
is.
We
are
only
looking
up
the
secret
provider
class
with
that
name,
which
is
in
the
same
namespace
as
the
part
by
default,
and
this
PR
basically
is
just
adding
another
attribute
called
seeker
provide
a
class
namespace
which
the
user
could
define
to
be
something
else.
D
So
the
pod
is
running
in
cube
system
and
they
could
set
secret,
provide
a
class
namespace
to
default,
and
that
way
the
provider
would
just
the
driver
would
just
look
up
in
the
default
namespace,
because
the
user
provided
that
so
I
think
what
we're
trying
to
gain
the
feedback
is.
Is
this
something
that
we
want
to
support
because
I
think
in
case
of
PVCs?
D
F
F
I
mean
at
the
very
least
you
can
you
are
you
are
able
to
invoke
a
read
from
a
privileged
actor
in
a
namespace
that
you
may
have
no
like
access
to
at
the
theoretically,
I
mean
you
definitely
get
information
leakage
right,
like
you
could
even
discern
if
namespaces
exist,
based
on,
like
particular
error,
messages
used
to
be
when,
like
the
Kuebler
tries
to
reach
out
or
the
plugin
tries
to
reach
out
to
like
like.
If
you
only
have
access
to
one
namespace,
you
actually
don't
know
what
exists
out
there
in
the
whole
cluster.
F
F
The
sort
of
the
thing
I'm
trying
to
understand
is
like
should
something
like
that
this
class
be
a
foster,
scope,
object
and
you
don't
you
like.
You
refer
the
class
just
as
is,
and
it's
always
cluster
scoped
and
it's
always
shared
like
or
is
it
meant
to
be
namespace
and
maybe
theoretically,
there's
some
reuse,
like
basically
I'm
trying
to
think
of
like
does
this?
D
So
it's
meant
to
be
namespace
code.
That's
all
we've
been
doing
it
so
that
it
it's
just
in
one
particular
namespace
and
they
could
have
the
same
name
in
different
namespaces
so
like
the
cluster
admin
would
just
deploy
in
one
particular
namespace
and
I.
Think
going
along
those
lines.
It
does
not
make
sense
to
all
of
them
to
de-stress
and
the
trauma
different
namespace.
If
it's
going
to
be
named
space
code.
D
D
This
is
basically
like
the
user
defined
resource,
the
secret
for
weight
loss,
the
user
defines
it
and
the
default
behavior
from
the
driver,
as
it
looks
up
the
secret
provider
class
from
the
same
namespaces,
the
part,
but
for
this
PR
it's
basically
just
allowing
the
user
to
define
a
custom
namespace.
So
we
can
look
up
from
that.
Namespace.
A
F
Mean
to
a
certain
degree,
certainly,
you
could
have
a
workaround
where
you
have
a
controller
that
takes
some
namespaces
objects
and
just
minced
them
out
across
mashing
labels
like
this
or
the
entire
cluster.
So
you
could
certainly
work
around
this.
If
you
didn't
want
to
sort
of
have
to
manage
them,
her
name's
basement
just
a
controller
I
would
probably
lean
towards
like
if
this
was
like
really
requested
having
that
like
as
an
option.
So
that
way,
one
in.
B
A
A
B
A
A
All
right,
let's
take
silences.
Okay,
all
right!
Thank
you!
Everyone,
that's
showed
up
and
participated,
will
get
this
meeting
out
on
the
channel
here
soon
and
I
will
also
update
the
notes
that
I've
taken
in
the
doc
as
well.
All
right
have
a
great
rest
of
your
day
and
we'll
talk
to
you
in
a
couple
weeks.