►
Description
Meeting of Kubernetes Storage Special-Interest-Group (SIG)
PVC DataSource Design Discussion 26 August 2019
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Saad Ali (Google)
A
Okay,
recording
share
screen
again,
okay,
so
currently,
this
is
what
datasource
looks
like
inside
your
PVC
object.
You
can
specify
the
kind
of
data
source
that
you
want
and
the
name
of
that
data
source
and
the
API
group
that
it
belongs
to,
and
the
nice
thing
about
this
mechanism
is
that
it's
extensible
in
that
you
could
define
an
arbitrary
kind
of
CR
D
and
that
can
become
a
new
type
of
data
school
today
for
alpha.
We
currently
only
support
two
data
sources.
One
is
snapshot
and
the
other
is
PVC
which
is
used
for
volume.
A
A
Now,
for
the
immediate
term,
we
are
planning
to
move
both
snapshots
and
cloning
to
beta
and
in
doing
so,
we're
going
through
and
reviewing
the
API
for
both
snapshots
and
cloning.
And
one
of
the
things
that's
come
up.
Is
this
kind
of
data
source
API,
and
is
this
the
way
that
we
want
it
to
look
going
forward?
A
What
is
the
benefit
here,
but
the
benefit
here
is
primarily
a
around
being
able
to
dynamically
set
the
data
source,
so
you
can
examine
you
can
think
of
a
concrete
example
as
I
want.
The
latest
snapshot
whatever
latest
means,
and
so
you
can
imagine
that
there
would
be
a
controller.
That's
running
that
IMP,
the
policy
of
like
figuring
out
what
the
latest
snapshot
is,
and
it
can
go
ahead
and
inject
the
data
source.
So
now
from
that
volume,
data
source
is
a
separate
standalone
object.
A
You
could
feed
this
controller,
some
sort
of
policy
that
says,
please,
you
know,
generate
data
source
objects
based
on
blah,
blah,
blah
and
it'll
spit
out.
These
volume,
data
source
objects
and
your
PVC
itself
never
needs
to
be
modified.
All
it
needs
to
do
is
point
to
a
data
source
like
my
PVC
data
source,
and
if
that
data
source
doesn't
exist,
provisioning
will
wait
for
that
data
source
to
exist,
and
if
we
don't
do
this,
if
we
leave
everything
in
line
the
way
to
implement
this
would
be
maybe
using
an
admission
controller.
A
A
A
Please,
you
know
prove
something
by
this
name
that
subscribes
by
this
policy,
and
the
name
would
be
my
PVC
datasource
and
the
policy
is
created
with
the
latest
snapshot.
So
it
basically
monitors
for
PVC
objects
with
a
data
source
that
is
that
matches
and
when
it
matches
it'll,
go
ahead
and
provision
that
and
assign
it
based
on
the
current
latest
volumes.
B
C
C
B
C
B
A
A
You
know,
pick
up
the
latest
and
then
I
was
roughly
like
it
could
be
based
off
of
just
the
data
source
name.
If
the
data
source
name
exists,
then
it
goes
off
and
creates
a
volume
data
source
based
off
that
name,
but
it
could
get
more
fancy
and
we
could
have
like
a
provisioning
object
for
that
controller.
Yeah.
B
I,
like
the
use
case,
I
just
I,
don't
see
how
this
proposal
gets
you
there,
because
all
this
says
is
now
now.
I
can
put
a
data
source
with
the
name
and
I
have
to
do
all
the
legwork
of
writing,
a
controller
that
can
turn
that
name
into
a
volume
data
source
using
some
magic,
and
it's
like
well.
If
what
you
really
learned
was
that
have
another
CRT,
which
is
does
what
you
want?
I.
A
Yeah
good
point,
so
what
you're
saying
is
that,
instead
of
basically
removing
in
line
altogether,
what
you
do
is
what
we
do
with
pod,
PV
and
PVCs
right.
We
allow
volumes
to
be
defined
in
line
as
well
as
as
a
PVC
and
so
you're
saying
that
in
this
case
you
could
provide
a
data
source
in
line
as
a
volume
snapshot
or
PVC,
or
you
know,
out-of-band
as
a
separate
standalone
object
as
well.
D
My
question
is
to
Ben's
is
why
wouldn't
we
just
integrate
data
source
as
a
field
as
part
of
cloning
that
leverages
the
control
provisioner
with
it,
so
that
vendors
can
implement
smart
technologies
for
their
storage
types
to
do
whatever
that
is
so,
let's
say,
I
want
to
have
my
data
source
is
another
volume
and
I'm
on
a
homogenous
storage
type.
I
would
be
able
to
leverage,
possibly
if
you
do
technologies
to
create
the
new
copy
to
make
that
happen.
D
A
A
Like
ideally,
I
mean
it's
possible
that
you
could
do
it
in
both
like
you
could
make
datasource
in
line
and
and
as
a
separate
standalone
object.
I
think
my
gut
feeling
would
be:
let's
not
do
that,
because
looking
back
on
in
line
volumes
versus
PVCs,
ideally
we
should
have
just
you
know
gone
with
PVCs
to
begin
with.
So.
B
A
D
E
B
C
B
A
A
E
A
One
of
the
the
the
benefits
of
this
approach
is
that
I
think
it
works
nicely
with
the
get
ops,
workflow,
meaning
one
of
the
things
that
we
want
to
do
ultimately,
is
you
should
be
able
to
check
in
the
state
of
your
cluster,
ideally
in,
to
get
and
be
able
to
recreate
it
if
your
cluster
is
nuked
for
some
reason
and
recreated
from
what's
checked
in
to
get
now.
This
is
where
it
gets.
Tricky
is
with
data
source,
because
you
can
imagine
a
pod
in
PVC
object
that
described
how
a
application
should
be
run.
A
They
define
the
compute
as
well
as
the
storage
requirements
for
an
application,
but
that
application,
the
data
that
it
requires
could
be
it's
valid
for
the
application
to
start
with
an
empty
volume
or,
with
you
know,
some
initial
snapshot
as
a
start.
Starting
point
now,
if
you,
you
know
start
off
with
just
an
empty
data
data
source.
A
There
exists
a
data
source
and
the
data
source
is
named.
You
know
my
PVC
data
source,
and
so
then
provisioning
will
know
to
always
block
until
that
data
source
exists.
You
could
have
that
data
source
point
to
empty,
for
example,
and
say
initially
it's
going
to
be
empty,
but
at
some
later
point
you
could
choose
to
replace
that
with
a
new
snapshot,
a
different
snapshot,
and
in
that
way,
basically,
you
have
this
nice.
A
G
C
A
C
A
Yes,
right
so
I
mean
so
that
is
the
case,
so
everything
that
we
add
starts
off
as
a
new
CR
D,
which
is
what
we
did
with
the
snapshots,
which
is
what
we
did
with
a
lot
of
the
CSI
objects
that
we
needed,
and
then
it
turned
out
that
for
specific
use
cases
so,
for
example,
the
CSI
ones
the
CR
DS
just
weren't
sufficient,
and
they
made
an
exception
to
allow
that
back
entry
I'm.
Getting
that
we're
gonna
follow
the
same
path
with
this.
A
C
If
it
does
end
up
back
entry,
I
think
that
actually
is
is
a
detriment.
I
think
that
limits
the
flexibility
feature,
but
the
other
thing
that
I'm
still
not
I,
don't
understand
how
so
so,
because
again,
if
I
ever
want
to
change
something
or
add
anything
custom
or
anything
outside
through
the
CRT
of
my
own
I'm.
Now
you.
A
C
C
A
So
that's
a
good
question,
so,
if
you
think
about
how
that
would
work
with
the
inline
model,
what
that
means
is
that
you
somehow
you
need
to
be
able
to
dynamically
inject
into
your
inline.
What
your
data
source
is
before
you
deploy
it.
So
you
want
to
make
this
mutable
as
basically
that
exactly
the
trick
or
not
even
mutable,
just
independently
defined
okay,
so
that
I
could,
for
example,
define
a
PVC
and
say
it
has
a
data
source
and
then
that's
you
know
it's.
A
The
the
provisioner
is
going
to
hold
off
on
provisioning
it
until
that
data
source
exists
and
that
data
source
then
defines
kind
of
you
know
it's
empty
or
it's
a
it's
a
snapshot
or
it's
a
whatever.
It
is
the
details
about
that
data
source
versus
like
having
to
do
all
of
that
together
in
one
place
at
one
time,
so.
H
Sad,
the
one
area
that
I
get
a
little
bit
concerned
about
what
the
extra
level
of
abstraction
would
be
around
the
declarative
model
and
what
we
think
might
happen.
So
what
happens,
for
example,
I
think
we
can
all
say
that
the
data
source
gets
populated
at
provision
time.
Basically,
and
that's
it,
what
happens?
What's
the
expectation
if
somebody
modifies
what
that
data
source
yeah.
A
That's
a
good
question,
so
I
would
treat
it
exactly
like
we
do
with
storage
class,
which
is
that
it
is
a
provision.
Time
parameter
once
you
provision
your
volume,
the
storage
class
information
is
used
and
then,
if
your
storage
class
mutates
for
any
reason
you
know
that's,
it
doesn't
affect
the
volume.
That's
already
provisioned
and
I.
H
B
B
A
We're
gonna
have
to
do
that
anyway.
You
know
because
you
could
have
and-
and
we
already
do
have
data
source
on
the
PV
object.
I
believe
we're
gonna
want
to
retain
that
simply
to
say
it
once
we
decouple
data
source
from
the
volume
provisioning,
whether
the
P
via
actually
has
been
filled
with
a
data
that
it's
supposed
to
be
filled
with,
but.
B
A
That's
the
goal
is
that
you
could
have
you
know
a
very
specific
type
of
populate
er,
that's
specific
to
you
that
is
independent
of
the
storage
system.
That's
doing
provisioning
or
it
is
part
of
it
either
way
and
now
the
fund
that
that's
a
whole
separate
discussion
on
how
data
populate
errs
are
gonna
work.
We
have
some
designs
that
John
and
I
have
been
working
through
and
other
folks
happy
to
discuss
that.
But
let's
leave
that
out
because
it's
a
pretty
huge
design,
discussion,
I.
D
E
J
A
Way
that
I
imagine
it
is
like
this
becomes
a
hook
that
other
controllers
can
be
built
on
top
of
right.
So
if
you
are
something
that
knows
how
to
populate
a
github
repos
volume
data
source,
you
can
look
for
volume,
data
sources
that
correspond
to
two
to
two
that
type
and
then
you
can
handle
it
as
appropriate
for
you,
and
then
we
can
provide
a
set
up
standard
kind
of
controllers
or
sidecars
that
can
do
the
complicated
heavy
lifting
like
the
the
heavy
lifting
in
a
data.
A
So,
as
far
as
I
imagine
the
the
we
provide
that
heavy
lifting
controller
common
code,
and
then
somebody
who
wants
to
build
this
logic
could
then
just
implement
a
small
shim.
That's
as
here's
how
to
fill
you
know.
I
have
a
program
that
knows
how
to
fill
a
volume
with
data
as
long
as
I
provided
and
I
pair
it.
With
this
heavy
lifting
logic
you
know,
I
can
I
can
basically
provide
a
data
populate
ER
and.
A
It
basically
what
I'm
thinking
about
in
terms
of
policy
is
that
it
becomes
a
layer
on
top
once
we
have
concrete
objects,
around
data
source
and
then
data
source
points
to
further
concrete
objects
like
volume
snapshot
or
a
CR
D.
For
your
particular
data,
populate
or
type,
you
could
build
a
policy
on
top
of
that
that
basically
acts
on
those
objects
as
appropriate.
A
So
so
you
can
imagine
for,
like
volume
snapshot,
you
could
have
a
volume
snapshot
policy
controller
that
knows
how
to,
for
example,
age
out
volume,
snapshots
over
time
or
delete
them
or
whatever
you
need
to
do.
That
would
be
another
stand,
stand
alone,
controller
that
knows.
Oh
I
operate
on
volume,
snapshot,
objects
and
I,
you
know,
can
can
have
some
mechanism
to
say
these
are
the
ones
that
I
care
about
and
here's
my
policy
that
kind
of
thing
it's
it
seems
it
just.
C
A
C
A
C
E
Undertakings
ray
so,
but
that
started
with
populate
data
populate
er
and
then
he
thought.
Okay,
for
that.
We
also
need
that,
for
we
can
we
can
use
that
for
going
to
snapshot
or
other
data
sources
mm-hmm.
If
we
don't
really
need
to
worry
about
data
popular,
then
we
don't
really
need
those
tanks,
gotcha.
C
A
What
I
wanted
to
close
on
and
we're
at
the
end
of
the
hour
I
should
have
booked
an
hour
instead
of
30
minutes.
But
what
do
you
folks
think
I
wanted
to
get
a
feel
for
the
room,
so
the
cons
here?
The
drawback
is
that
if
we
go
down
this
path,
we're
going
to
be
delaying
clones
and
volume
snapshots
for
another
quarter.
Both
of
those
are
planned
to
go
to
beta
this
quarter.
A
I
A
A
B
D
B
A
So
the
alternative
I
was
thinking
about
was
an
admission
controller
approach
where
you
can
imagine
like.
Instead
of
the
controller
spitting
out
a
volume
data
source
object,
it
would
manipulate
the
PVC
object
at
creation
time.
So
a
PVC
object
gets
created.
You
have
a
controller
monitoring
these
and
then
it
injects
a
data.
B
A
Is
that
we
kind
of
have
to
make
a
decision
on
the
PVC
object
as
a
whole
right?
So
if
we
decide
that
we're
gonna
do
in
line
or
not
in
line
that's
a
big
decision
and
the
I
don't
think
we
can
cut
it
both
ways
and
say
we're
gonna
do
both,
because
if
we
go
down
the
separate
object
route,
we
would
need
to
modify
the
in
internal
controllers
to
say,
I
recognize
that
this
is
a
separate
object
and
that
the
volume
provisioning
Pat's
need
to
wait
for
it
to
yet
exist.
That
kind
of
thing,
yeah.
C
When
I
was
a
Gris,
that's
definitely
a
concern
and
an
issue.
What
I
was
wondering,
though,
is
given
that
fact
and
then,
given
the
fact
that
we,
what
we're
looking
at,
is
actually
fairly
fairly
close
in
terms
of
user
user
API
facing
user
facing
API
I
am
wondering
if
this
is
something
that
could
actually
be
worked
on
on
top
of
what
we
already
have
in
approached
it
that
way
as
a
new
feature.
You
know
what
I
mean
to
supplant
this
one
I,
don't
know
if
that's
worth
it
or
not.
What.
C
A
I
A
Was
two
releases,
but
let's
we
can
double
check
that,
so
what
we
could
say
is
that
we
allow
snapshot
and
clone
to
move
forward,
as
is
and
immediately
put
out
a
deprecation
notice
to
say,
the
way
that
data
source
is
going
to
be
done
is
going
to
be
changed
in
the
cup
of
releases.
Please
be
aware
of
that.
The
only
reason.
C
A
I
A
I
A
I
B
Off
until
you
get
it
right,
yeah
I
I
just
wanted
to
throw
out
that
it
Michelle
you
mentioned
something
about
templatized
PVCs
and
how
this
data
source
field
would
be
impacted
when
there
templatized
such
as
in
a
stateful
set,
and
that
seems
like
a
question
worth
answering
before
going
forward
because,
because
that
will
affect
either
either
one
of
these
approaches
yeah.
What.
C
A
Yeah
I
mean
I
can
imagine
that
you
could
have
a
templatized
data
source
name,
and
you
know
you'll
have
data
source
flu
food,
two
three,
four
that
automatically
get
created
by
the
are
the
the
name
gets
injected
into
the
PVC
by
the
stateful
set
controller,
and
then
you
have
to
provide
some
mechanism
to
be
able
to
create
those
objects.
Somehow,
whether
you
do
that
manually
or
you
have
a
controller
that
generates
those
objects
based
on
like
monitoring
the
stateful
set
objects.
K
A
I
B
C
L
K
A
B
A
Honestly,
like
I,
we
started
thinking
about
this
like
last
week
when
we
were
reviewing
the
snapshot
API
like
thinking.
Okay,
is
this
ready
to
go
to
beta,
and
then
you
know
initially,
it
was
the
get-ups
workflow
that
caught
me
off
guard,
which
was
like
you
know.
If
we're
expecting,
users
to
you
know
be
able
to
check
in
what
is
going
to
go
into
their
cluster,
how
are
they
going
to
manage
data
source
with
that,
and
so
from
that
it
was
like
okay.
A
If
we
can
break
apart
the
data
source
into
a
separate
object,
then
you
can
leave
your
pod
in
PVC
objects
as
the
unmodified
immutable
attraction
to
github,
and
you
know
you
could
have
some
other
something
else
that
will
automatically
create
these
objects
and
I
haven't
thought
through
exactly
what
those
controllers
would
look
like.
Yeah.
K
C
A
Is
that
in
order
you
have
to
basically
at
when
you
create
your
PVC
object?
You
have
to
know
what
the
data
source
is
all
right.
So
that
means
that,
along
with
your
definition
for
your
workload
for
how
you
define
an
application,
you
will
required
if
it's
inline,
to
dictate
what
the
data
source
for
that
application
is
as
well.
A
The
data
source
itself
could
be
a
CR
D,
but
there's
no
holding
off
on
provisioning
right.
If,
if
we
don't
build
this
logic
in
as
a
first-class
separate
object,
what
that
means
is
that,
as
soon
as
that
volume
is
provisioned,
it's
going
to
start
it's
going
to
immediately
start
provisioning,
and
so,
if
you
have,
for
example,
a
you
know,
a
snapshot
and
you
want
to
be
able
to
do
dynamic
snapshot
provisioning
like
there's
no
way
for
you
to
say,
hang
on.
Let
me
hold
off
on
provisioning
until
I've
made
this
decision,
but.
E
B
B
A
So
I
mean
another
way.
Out
of
this
is
they're,
going
back
to
kind
of
the
suggestion
that
Ben
had
at
in
earlier
in
the
call
which
was
we
have
the
inline
data
source
and
I
might
be
misrepresenting
what
you
said
then,
but
you
have
an
inline
data
source
for
planning
to
make
it
generic,
so
you
could
have
an
arbitrary
data
source
in
the
future.
A
Now
it
is,
the
benefit
would
be
of
that
approaches.
Velocity
we
don't
block
snapshot
or
clone;
they
can
continue
to
move
at
the
pace
that
they're
moving.
The
drawback
is
fragmentation.
We
now
provide
two
ways
of
doing
the
same
thing
and
as
a
user,
it
gets
confusing
like
Oh,
should
I
be
providing
this
inline
or
external,
and
then
it'll
be
up
to
somebody
else
to
educate
the
user
on
which
one
they
should
do
and.
B
Then
I'm
still
very
confused
about
that.
The
other
part
of
this
discussion
that
we're
not
having,
which
is
how
you
implement
these
other
data
sources
and
what
that
actually
means
and
looks
like
because
I
think
that
actually,
why
I
don't
know
how
much
impact
it
has
on
this
decision
of
whether
to
have
another
level
of
indirection
or
not
but
yeah.
L
J
A
E
B
E
A
G
A
A
That's
kind
of
the
point
with
kubernetes
right
is
that
you
declaratively
define
what
the
state
of
your
cluster
looks
like,
and
so
your
cluster
should
be
able
to
go
away
and
you
should
be
able
to
recreate
it
from
scratch
from
from
scratch
and
get
what
you
want.
But
everything
that
you
have
for
your
cluster
should
be
defined
in
some
sort
of
llamo
somewhere
that
you
can
check
in
to
get
and
and
that's
kind
of
the
the
get
ops
workflow
with
kubernetes.
But.
A
So
what
you're,
assuming
here,
is
that
your
decoupling
definition
of
the
data
source
from
from
from
what
you
have
checked
in
so
your
your.
What
you
have
checked
in
is
your
application
and
how
what
the
requirements
for
your
application
are,
and
then
you
can
make
a
run
time
or
deployment
time
decision
about
what
your
data
source
is
going
to
be
without
having
to
modify
any
of
your
Yam.
Well,
that
defines
what
your
application
should
look
like.
How
is.
A
Just
take
in
everything
please
yeah
and
you
can
do
that,
but
the
problem
is
that
that
injection
basically
requires
you
to
have
order
of
operations
concerns
right.
So
if,
if
you
have
some
controller,
that's
going
to
populate,
for
example,
I
want
the
latest
snapshot.
You
could,
you
know,
have
some
input
to
that
controller.
Some
CR
DS
that
that
say,
hey,
please,
you
know,
create
this
data
source
and
then
on
your
PVC
object.
You
can
say
I'm
going
to
require
a
data
source,
here's
the
name
of
the
data
source.
A
B
A
B
A
D
Can
I
can
I
ask
a
kind
of
a
leading
question
side
is:
what's
driving
this,
the
get-ups
code
is
configuration
capability,
or
is
this
driving
it
from
a
deficiency?
We
see
in
storage
because
I'm
trying
to
understand
like
we're.
Looking
at
this
from
like
a
hybrid
cloud,
Multi
cluster
storage
capability
long
term,
is
that
what
we're
trying
to
get
to
and
trying
to
get
get
into
the
get-ups
model,
since
you
mentioned,
that
particular
is
something
else.
I
mean.
A
A
That's
a
decision
that
I
can
make
when
I,
when
I
create
the
application
in
the
llamó
for
that
application,
and
then
at
a
later
point
when
I
do
the
deployment
I
can
then
make
the
decision
about
what
that
data
source
is
going
to
be.
Is
it
going
to
be
empty
or
is
it
going
to
be
a
snapshot,
or
is
it
going
to
be
something
else?
If
we
have
it
in
line,
we
can't
really
do
that,
because
you
can't
check
in
your
PVC
object.
You
have
to
mutate,
your
PVC
object.
B
A
With
the
data
source,
though,
is
that
you
could
you
could
you
know
to
cuddle,
apply
your
pod
in
PVC,
and
if
the
data
source
object
is
separate,
the
provisioner
knows.
Oh,
there
may
be
a
data
source
here,
I'm
going
to
hold
off
on
provisioning
until
that
object
exists,
and
so
it
aligns
nicely
with
that
kind
of
declarative.
Api
model
of
there
is
no,
you
know,
order
of
operations,
you
can
cube
cuddle
apply
all
of
your
yamo
and
the
wrong
thing
won't
happen.
A
C
A
No,
if
you
do
it
in
line
the
problem,
is
that
before
you
deploy
your
PVC
object,
you
need
to
make
that
decision
right
yeah.
So
if
you
deploy
your
PVC
object
without
mutating
it,
it's
gonna
provision
empty
versus.
If
I
provision
it
with
pointing
to
a
data
source
object,
it
will
hold
off
on
provisioning.
I
mean.
B
K
K
K
C
A
C
No,
no,
no
you're
misunderstanding,
so
so
what
so?
The
way
it
works!
That's
the
way
it
works
today,
correct
right!
So
that's
already
in
place.
We
already
we
already
handle
that
the
concern
here,
my
understanding,
for
example,
in
the
github
workflow,
which
which
we
don't
actually
have
yet
but
the
example
there
makes
total
sense
because
you
don't
necessarily
want
to
go
down
to
the
to
the
plug-in
in
provision
of
volume.
If
you
don't
have
anything
ready,
that's
what
you're
saying
right.
A
A
Snap,
shots
of
volumes
that
you
created
and
you
have
the
code
for
a
checked
in
somewhere,
the
pod
definitions,
the
PVC
definitions,
and
then
you
decide
to
do
a
rollback
and
because
you
know
something
bad
happened
to
your
current
occasion.
That
would
involve
just
nuking
what
currently
exists
and
then
creating
a
read
read:
appoint
whatever
you
have
checked
in
to
get
as
well
as
a
volume
source
that
says
this
is
a
snapshot
that
I
want
to
use.
I
guess
the
counter-argument
that
I'm
hearing
is
well.
A
If
you
need
to
create
another
object
to
represent
the
data
source
and
that
object
is
not
checked
in
to
get
then
why
not
just
say
the
PVC
itself
is
not
checked
in
to
get
yes.
The
challenge
with
that
is
that,
well,
you
can't
not
check
in
your
PVC
because
it
defines
what
your
application
is
and
that
needs
to
be
defined
somewhere,
like
you
can't
say,
but.
D
D
A
A
A
A
A
A
Ok
well,
I
think
consent.
Let's
have
a
more
discussion,
have
more
discussion,
there's
like
three
plus
ones,
one
two,
three
four
minus
ones.
A
bunch
of
zeros
important
thing
to
keep
in
mind
is
that
the
deadline
is
fast
approaching
the
29th
or
for
snapshots
in
volume
cloning
for
1.16,
if
you
want
to
move
it
to
beta.
So
let
me
do
this.
My
tomorrow
looks
crazy,
but
maybe,
tomorrow
morning,
9:00
to
10:00
a.m.
Pacific
time
would
that
work
for
folks
for
a
follow-up
discussion,
I.