►
From YouTube: Kubernetes SIG Storage 20180104
Description
Kubernetes Storage Special-Interest-Group (SIG) Meeting - 04 January 2018
Meeting Notes/Agenda: https://docs.google.com/document/d/1-8KEG8AjAgKznS9NFm3qWqkGyCHmvU6HVl0sk5hwoAE/edit#heading=h.25h6dn3vxd6i
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Saad Ali (Google)
Chat Log:
09:15:25 From jared : great work Luis and the rest of the CSI team!
09:15:31 From Luis Pabon : Sure: https://docs.google.com/presentation/d/1ErpRlih8CFx96twch3YuH6htsW4uj0adbxDJAow2L_g/edit?usp=sharing
09:16:23 From Luis Pabon : thanks Jared. Definitely a team effort
09:18:32 From Ian Chakeres : I’ll ping Jan offline and learn more about what is required for MountPropogation.
09:21:47 From Luis Pabon : CSI volunteers, you may want to add your github name and/or email
09:23:41 From sbezverk : I saw similar discussion happening in sig-network with regards to topology aware labels
09:30:58 From jared : saad/luis, do you see the CSI spec itself getting updated to add snapshotting at the spec level?
09:47:24 From hekumar : zetaab
09:52:17 From hekumar : https://docs.google.com/spreadsheets/d/1wbhJSE6Nzc7XvVjrVKHhJEleiAsUcHGR1t4VH4hWu9s/edit#gid=0
10:02:14 From Luis Pabon : Thanks all, I need to leave, but if you need me I will be on #sig-storage and #wg-csi
A
All
right
welcome
everyone,
happy
2018,
Happy,
New
Year
today
is
January
4th.
This
is
the
first
meeting
of
the
storage
special
interest
Nettie's
for
the
year
today
we
have
a
handful
of
things
on
our
agenda.
First
up
lewis
is
going
to
give
us
a
demo
of
CSI
working
with
kubernetes.
Then
we're
going
to
go
through
planning
exercise
for
1.10
release
of
kubernetes
for
the
storage
sig.
A
For
that
take
a
look
at
the
agenda.
There's
a
planning
spreadsheet.
If
there's
items
that
you
think
we
should
be
working
on,
feel
free
to
add
them
to
the
spreadsheet,
and
then
we
can
review
it
and
assign
folks
and
then
there's
a
couple
other
things
on
the
agenda
that
we
can
we'll
go
we'll
get
to
in
a
in
a
little
bit.
I'll
get
started
lluís
go
ahead
and
you
have
ten
minutes
well.
C
B
B
Second
I'm
gonna
give
just
a
extremely
high-level
overview.
How
CSI
works
for
those
who
are
new
to
it?
Csi
is
a
specification.
Is
the
contract
between
the
client
being
the
continual
orchestration
systems
and
the
plugins
which
are
then
there
to
manage
storage?
They
manage
attachment
attachment
mount
on
mount
identification
listing
of
volumes,
and
such
this
is
just
a
subset
of
the
operations
for
more
on
the
accrual
a
set
of
operations.
Please
check
out
the
CSS
specification.
B
This
is
a
image
taken
from
the
design
document
for
kubernetes
and
what's
gonna
I
just
wanted
to
bring
this
up.
I
notice
a
lot
here
to
show,
but
I
wanted
to
show
you
that
the
there's
a
multiple
parts
to
a
the
way
that
CSI
interfaces
with
kubernetes
kubernetes
doesn't
know
anything
about
CSI
and
CSI
drivers,
don't
know
anything
about
communities,
so
there's
a
set
of
helper
containers
that
are
able
to
kind
of
manage
that
bridge
in
between
there's
three
specifically,
one
is
called
the
external
attacher.
B
It
kind
of
manages
attachment
of
attachment
because
actually
and
actually
a
set
of
API
calls
from
the
G
RPC
for
this
years.
I
expect
second,
there's
the
external
provision
which
all
most
of
you
are
very
familiar
with,
and,
lastly,
there's
one
more
called
the
driver
registrar
which
communicates
with
the
CSI
driver
to
be
able
to
then
name
have
this
name
mapping
between
what
what
the
CIO's
have
as
a
name
for
the
node
and
what
the
CSI
driver
has
a
name
for
the
node
has
a
kind
of
that
mapping
which
means--
and.
D
B
Through
that,
through
the
demo,
but
I
just
kinda
want
to
give
you
a
big
picture,
how
that
works
again,
there's
a
lot
of
documentation
available.
We
have
the
spec,
we
have
a
qu,
a
project
in
github
which
has
houses
all
these
containers
and
their
sources,
and
then
we
also
have
the
channel
WG
as
CSI
in
slack.
B
You
can
come
in
there
and
ask
questions
and
we
can
definitely
help,
but
I
want
to
bring
one
up
here
is
called
the
CSI
documentation,
so
this
year
has
documentation
not
just
and
Hobby
set
up
your
kubernetes,
but
how
do
you
use
it
to?
You
know
how
to
write
drivers,
how
to
deploy
in
kubernetes
and
we're
gonna
go
to
the
Plunkett.
Let's
just
give
you
a
better
picture,
and
here
we
have
what
we
just
talked
about
it,
which
is
the
external
attacher,
the
extend
the
provisioner,
the
driver
register.
B
These
are
all
the
helper
phones,
the
helper
are
containers,
and
then
it
talks
about
how
to
set
them
up
it
talks
about
how
they
communicate
with
CSI
driver
and
such
okay.
So
we've
done
that.
Let's
continue
on
so
now
with
the
demo.
All
right.
Can
anybody
see
my
console
yep
is
a
font
large
enough
or
should
I
get
larger.
B
Okay,
it's
just
it's
good,
because
I'm
all
dumb
and
blind
nice
here
we
go
so.
The
very
first
thing
I'm
going
to
do
is
I'm
using
the
cube
up
from
when
Eddie's
gonna
have
to
set
up
these
systems
using
on
GC,
so
I
just
want.
Let
you
know
that
I
have
everything's
clean
I
have
three
nodes
and
a
master
and
I
can
show
you
what
these
are.
Aliases
kak
is
just
kuku
cuddle.
Kn
is
Q
cuddle
and
Q
system
namespace,
okay,
hot
so
I
can
show
you
this
everything's
running,
everything's,
fine,
okay!
B
B
Drivers
list
for
a
single
node,
so
I
cannot
deploy
it
on
every
node
and
have
it
just
work
for
any
part
to
force
it
to
go
in
a
sentence
in
the
same
node,
but
it
still
uses
the
same
concepts
of
CSI
and
I'll
still
go
and
show
you
how
it
works.
So,
let's
go
ahead
and
take
a
look
at
one
more
thing
before
we
continue
knows
and
I'm
going
to
put
everything's
gonna
go
into
this
note,
so
I'm
gonna
say.
B
B
For
this
node,
specific
them
and
I'm
bringing
this
stuff
specifically
because
I
want
CSI
developers
to
to
know
how
the
interaction
works.
So
once
this
host
path,
traffic
is
deployed,
DC
driver,
registrar,
psychic
Athena
will
actually
put
an
annotation
there
for
the
node
and
we
should
be
used
then
by
other
parts
of
the
kubernetes.
So
let's
first
check
out
the
host
path
and
see
how
this
works.
Host
paths
driver
first
I,
have
a
storage
class
everybody's
familiar
with
that,
and
this
tourist
class
has
a
provisioner
call
CSI
hold
on
okay.
B
We
have
a
service
account
on
creating.
We
have
a
set
of
cluster
row
bindings
for
our
back,
because
the
sonika
containers
need
to
be
able
to.
First,
the
external
provisioner
needs
to
be
able
to
create
and
delete.
Persistent
volumes
needs
to
watch
for
purses
important
claims.
Then
we
have
the
external
attach
our.
It
needs
to
be
able
to
watch
for
this
new
object.
Called
volume
attachments
volume
attachments
is
a
new
object
that
was
introduced
in
1.9
and
there's
a
lot
of
information
about
that
in
the
design
documentation.
B
So
we
can
skip
across
the
row
binding.
Let's
give
this,
and
here
is
a
stateful
set,
so
normally
what
you
would
do
is
that
you
create
a
part
with
your
psycho
containers,
yeah
attached
with
your
CSI
drive,
and
what
they
do
is
that
they
communicate
with
your
CSI
driver
over
a
UNIX
domain.
Socket
okay,
I'm
not
going
to
go
through.
Oh
four,.
B
Let's
so
just
learning,
you
know
that
this
I'm
not
gonna,
go
through
every
part
of
this.
This
is
all
documented
in
the
documentation.
I
just
want
to
show
you
now,
then,
that
demo
itself.
So
if
I'm
gonna
create
the
host
path
and
then
say,
get
hearts
and
there
it
is
running
okay.
So
now
we
can
go
back
to
the
edit
and
we
can
see
that
the
information
has
been
set
there,
and
this
information
means
that
this
CSI
driver
with
a
CSI
host
path
name
calls
this
node
by
that
name.
B
So
that's
all
working
I
mean
he's
drop.
It
just
try
working
so
now,
let's
say
get
stores
class.
There's
our
stores
class
right
there.
Let's
look
at
our
sample
pot,
persistent
blowing,
claim
using
the
stores,
class
post
path
and
that's
it.
This
is
all
the
same
as
everything
else,
so
you
can
see
here
and
so,
let's
create
that
which
is
all
normal,
a
workflow
for
creating
an
application
and
some
storage
Wow.
B
A
B
B
A
A
Okay,
so
I
pre-populated,
the
1.10,
a
spreadsheet,
with
some
of
the
items
that
were
incomplete
from
1.9
and/or
were
in
alpha
and
potentially
should
be
moved
to
beta
now,
so
we're
gonna
review
those
if
you
have
anything
else,
please
after
the
bottom
and
then
we'll
talk
about
them
when
we
get
to
them.
First
up
is
block
volume,
support
I,
imagine,
there's
additional
volume
plugins.
We
want
to
and
I'm
not
sure
whether
we
want
to
move
to
beta
or
not
Aaron
hi.
G
A
G
A
A
I
I
A
A
A
J
B
J
A
Sounds
good
and
in
the
meantime,
if
there's
folks,
who
are
interested
in
contributing
this,
is
the
time
to
step
up
and
take
ownership,
don't
be
shy.
There
are
folks
who
have
done
this
before
who
are
willing
to
help
you
with
the
process,
so
don't
feel
intimidated
if
you're
sitting
on
the
sidelines.
Thinking
about
whether
you
should
volunteer
or
not
next
up
is
the
CSI
volume
implementation
we've
been
having
separate
meetings
to
keep
track
of
things
for
CSI
our
last
meeting
on
Tuesday,
we
created
a
list
of
items
that
we
want
to
go
to
beta.
A
A
And
I
will
reach
out
to
you
and
we'll
do
assignments
tomorrow
morning,
I'll
set
up
a
meeting.
You
know
the
CSI
implementation
group
and
we'll
go
through
and
assign
these
items.
That
said,
realistically,
the
list
of
items
is
very
large
and
some
of
the
items
have
a
dependency
on
the
CSI
spec
itself,
meaning
the
changes
need
to
be
pushed
into
the
CSI
spec,
and
then
the
code
within
kubernetes
needs
to
be
updated,
so
realistically,
I
think
pushing
to
ADA.
A
This
quarter
would
be
a
stretch
for
now
we
can
keep
that
designation,
but
realistically,
it's
probably
going
to
remain
an
alpha
for
this
quarter
and
then
move
to
beta
the
following
quarter.
So
the
plan
is,
as
we
reassess
going
through
the
quarter,
we'll
continue
to
evaluate
whether
this
should
have
the
beta
or
alpha
label.
We'll
start
with
the
stretch
goal
of
trying
to
make
beta
this
quarter,
but
we'll
see
how
that
goes
again.
A
We're
looking
for
volunteers,
if
you
are
interested
in
helping
please
add
your
name
to
the
agenda
doc
and
I'll
reach
out
to
you
later
today.
Next
feature
is
generic
storage,
topology
solution
that
works
well
with
CSI
local
storage.
This
is
something
that
we've
been
wanting
to
do
for
a
while.
Currently,
the
volume
subsystem
in
kubernetes
hard
codes,
the
concept
of
zones
and
regions
for
to
cloud
providers,
AWS
and
GC
and
I
believe
a
sure
as
well
I'm,
not
sure.
A
But
what
this
means
is
that
it's
not
very
extensible,
it
doesn't
work
in
all
environments
and
we
need
to
do
a
better
job
here,
and
the
task
here
is
to
come
up
with
a
more
generic
mechanism
to
handle
any
arbitrary
topology
within
kubernetes,
such
that
an
arbitrary
volume
subsystem
can
provide
information
in
a
generic
way
about
where
volumes
are
provisioned
and
allow
kubernetes
to
use
that
information
when
it's
edge,
willing
workloads
and
vice
versa.
When
natives
want
to
influence
where
a
volume
is
provisioned,
it
should
be
able
to
do
so.
A
A
K
A
L
A
A
A
F
M
A
A
That's
a
good
question:
I
was
talking
to
Jing
about
this
yesterday.
You
know
she
said
it's
currently
out
of
tree.
It
works
nicely.
Do
we
really
need
to
pull
it
in
tree?
My
question
then
was
well.
How
does
in
arbitrary
storage
provider
implements
snapshotting
capability,
and
it
sounds
like
the
way
that
the
feature
is
currently
implemented.
A
This
is
the
same
problem
that
we
have
with
the
entry
volume
plugins
and
that
we
are
requiring
third-party
storage
vendors
to
come
in
and
modify
kubernetes
specific
code
to
make
they're
there
to
extend
it
to
Fred
for
add
capabilities
for
their
subsystem
and
that's
unmaintainable.
It's
our
difficult
to
test
and
that's
a
model
that
we
want
to
get
away
from.
So
then
the
next
question
is
well.
A
B
The
external
already
now
so
I
really
agree
that
we
need
CSI
to
to
somehow
maybe
that's
the
extension
since
I
have
snapshots,
but
I
just
still
don't
understand
why
it
needs
to
be
part
of
entry.
You
communities,
I,
would
suggest
that
instead
that
it
is
kept
externally
until
CSI
or
an
extension
of
CSI
has
snapshots.
That's.
A
A
good
point,
and-
and
that
may
well
be
the
case,
so
what
we've
noticed
with
both
external
attacher
external
provisioner
is
there
is
some
component
within
on
the
cubelet
kubernetes
side
that
needs
to
trigger
these
things.
In
the
case
of
the
volume
attached
or
there's,
a
volume
attachment
object
that
kubernetes
needs
to
create
so
they're
super
Nettie's,
they're
they're,
some
level
of
changes
that
we
still
need
to
make
if
we
can
get
away
with
absolutely
zero
changes
on
the
kubernetes
side
and
still
be
able
to
drive
towards
CSI
wonderful.
A
Okay,
so
is
there
anybody
who
wants
to
take
the
lead
on
working
on
snapshots,
I'm,
not
sure
what
jinx
availability
is
going
to
be
this
quarter?
She
is
going
to
be
working
on
some
capacity
isolation
projects,
so
she
may
be
able
to
help
guide
it,
but
I'm
not
sure.
If
she's
going
to
be
able
to
drive
it.
Is
there
anybody
in
the
community
who
wants
to
take
the
lead
on
it?
So.
A
J
A
A
D
A
M
Yes,
so
basically
we
just
want
to
implement
so
keep
cut
off.
Top
can
also
show
the
more
story,
just
like
secure
memory.
Okay,
so
I
think
there
are
some
changes
in
monitoring
apply
and
we
probably
need
to
work
on
the
new
metrics
server
to
what
is
part
and
next
week
we'll
talk
this
113
and
to
finalize
it
should
be
neat.
Then
this
color
is
okay.
A
A
M
A
M
A
O
A
A
A
F
I
A
All
right
encryption
of
empty
derp
I'm
going
to
leave
this
unassigned
for
now,
if
folks
want
to
work
on
it
and
later
in
the
quarter,
feel
free.
It's
a
nice
to
have
feature
that
we
have
resources,
for
we
can
jump
on,
supports
additional
default
flex
volume,
plug-in
directories,
so
I
think
currently
flex
volume
supports,
don't
forget
only
a
single
directory.
This
is
something
that
Jared
and
his
team
have
been
asking
for
a
while
I
got
drops
from
last
quarter.
Jared.
Are
you
still
interested
in
driving
this.
P
H
A
H
A
A
H
A
A
Okay,
next
item
is
dynamic,
max
volume
per
node
count.
This
is
something
that's
been
on
our
back
burner
for
quite
some
time.
There
is
a
maximum
number
of
volume,
plugins
volumes
that
the
scheduler
will
allow
per
node.
Currently,
it's
hard-coded,
so,
for
example,
for
GCE
persistent
disks,
it's
hard
coded
to
16
the
limit,
in
fact
that,
for
example,
and
vary
depending
on
the
size
of
the
VM.
It's
not
it's
not
strictly
hard-coded.
You.
A
True,
you
can
change
it
with
an
environment
variable,
but
that
makes
the
assumption
that
you
have
access
to
the
master
to
do
so,
which,
if
you're
running
on
gke,
you
don't
so
it's
it's
a
little
bit
painful
and
we
would
like
to
make
this
be
set
dynamically
so
that
when
a
node
starts,
it
should
report
for
his
volume
plugins
that
it
has
available
what
the
limits
should
be
in
the
scheduler
should
be
able
to
use
that.
Is
there
anybody
in
the
community
interested
in
helping
design?
This
thing
helped
design
a
version
of
this
last
quarter.
A
Next
item
is
flex
volume,
resize
support,
so
the
IBM
folks
reached
out
and
we're
very
interested
in
in
this.
So
flex,
volume
is
an
API
that
we
want
to
continue
to
support,
but
the
call
that
we
made
was
that
we
would
stop
extending
it
and
instead
focus
our
efforts
on
CSI,
but
the
flex
volume
or
the
IBM
folks
reached
out,
and
their
point
is
valid
there.
A
They
have
a
flex
volume
driver,
CSI
is
still
in
alpha
and
in
the
meantime
they
don't
want
to
be
blocked
out
from
features
like
this,
and
so
they
asked
for
a
just
one
feature
flex,
which
they're
willing
to
help
develop
an
ad
and
to
end
test
for,
and
it
sounds
like.
Zoo
is
going
to
be
working
on
this
from
the
IBM
site.
A
H
E
C
A
M
A
So
the
volume
reconstruction
code
attempts
to
try
to
recover
as
much
information
as
possible
from
the
volume
mount
path
actually
and
unfortunately
it
doesn't
have
enough
information,
and
this
causes
all
sorts
of
issues
in
our
system.
So
Jing
has
a
proposal
which
she
pasted
in
as
an
issue
which
would
overhaul
this
system
and
try
to
just
simplify
it.
To
say,
if
we
find
mounts
that
we
have
absolute
that
are
completely
orphaned,
we
have
no
indication
that
they
belong
to
any
existing
pod.
A
We
just
go
ahead
and
unmount
those
those
mount
points
as
well
as
do
reference
counting
to
ensure
that
any
global
mount
points
are
also
cleaned
up
as
well.
So
this
is
a
design
that
Jing
came
up
with
and
we're
looking
for
volunteers
in
the
community
to
help
actually
implement
it.
Jing
would
be
available
to
guide
you
and
to
show
you
where
the
code
is,
but
this
would
be
a
great
opportunity
to
touch
his
core
vol
code
for
anybody
who's
interested
any
volunteers.
A
M
The
previous
one,
so
right
now
it's
just
a
different
cloud
provider
like
have
different
behavior
of
windowed
I,
say,
shut
down
restart
and
there
are
still
some
issues.
I
think
he
wants
fix.
Some
a
dress
and
some
other
acts
endures
do
has
issues,
but
someone
I
think
right
now
is
trying
to
fix
it.
We,
we
kind
of
we
know
the
root
cause
of
this,
because
the
trial
provider
has
different.
Here.
One
note
is:
yeah,
failed.
Okay,
you
need
to
make
sure
this
character.
Yes
and.
H
K
This
problem
exists
and
it
used
a
list
in
here
of
ways,
but
AWS
be
fixed.
Last
quarter,
Center
someone
Zeta
as
Z
Z
ETA
V,
his
name
desta
his
good
app
handle
that
gays
trying
to
fix
it
for
cinder
right
now
and
it
potentially
might
exist.
You
know
the
plot
Roy.
It
is
two
different
league
on
how
the
shutdown
how
the
coracoid
handles
a
shutdown
knows.
Actually
so,
okay,.
A
So
we'll
track
it
first
endured
quarter
and
we
can
revise
this
to
add
more
volume
plugins.
If
the
need
arises,
yeah,
okay
can
either
Jing
or
himand.
Add
the
name
of
the
developer
who's
working
on
this,
please,
yes,
sure
I
know
a
lot
I
suppose
review
as
for
them
yeah
all
right.
So
the
last
item
here
is
improving
local
volume
at
watching.
So
the
background
here
is
that
there
are
four
major
methods
that
the
entry
volume
plugins
implement.
Provision
of
Volume
one
is
to
attach
a
volume.
A
The
next
one
is
mounting
device
and
the
final
one
is
actually
mounting
the
volume
to
the
pot.
The
different
difference
between
these
last
two
steps
is
mount
device
is
required
if
you
are
an
attachable
volume
plug-in
and
it
is
called
by
the
kubernetes
system
once
per
volume
per
node.
So
the
first
time
that
volume
gets
scheduled
to
the
node
is
triggered
and
for
things
like
GC
and
AWS,
it
results
in
a
global
mount
point
of
the
device,
the
ice
Guzzi
device
and
then
the
subsequent
mount
calls
are
called
every
time
a
workload
referencing.
A
That
volume
is
called
so
every
time
a
pod
referencing
that
volume
is
referenced
to
a
node,
the
mount
call
or
the
setup
call
is
called,
and
it
will
bind
mount
from
that
global.
Mount
point
to
the
final
mount
point.
This
works
very
nicely
for
volume.
Plugins
that
implement
the
attach
method.
The
problem
is,
there
is
a
set
of
volume
plugins
like
I
scuzzy,
where
there
is
no
concept
of
a
remote
attached,
but
they
do
have
a
concept
of
a
local
attached
and
so
to
work
around
this.
A
What
folks
were
doing
was
implementing
an
attached
earth
that
doesn't
know
op
and
then
implementing
mount
device
where
the
local
attaches
both.
So
the
suggestion
for
this
task
is:
let's
make
mount
device
a
separate,
optional
operation
that
can
be
implemented,
independent
of
the
the
attach
call
and
the
volume
plugins
like
I
scuzzy
that
have
no
need
for
attach.
They
don't
need
to
implement
the
full
factor,
just
a
mount
device,
and
that
will
result
in
cleaner
code
both
on
the
volume
plug
inside
and
on
the
kubernetes
side.
A
K
So
this
was
in
last
quarter
actually
and
we
have
full
request.
There's
no
need
this
is
not.
One
feature
is
like
I
think
we
can
take
this
as
bug
fixes
for
each
individual
test.
Each
individual
case
and
and
I
have
open
a
spreadsheet
that
I
already
sent
to
the
community
in
the
six
storage
mailing
list,
and
people
are
taking
putting
their
name
against
it,
that
against
them
and
and
I
want
to
be
able
to
take
ownership
of
it
and
implement
individual
volume
matrix
that
is
listed
in
that
document.
E
K
D
A
A
A
A
The
idea
here
was
that
there's
a
lot
of
folks
in
our
community
who
are
interested
in
helping,
but
don't
quite
know
where
to
start
and
Michael
Rubin
when
he
attended
a
Q,
Khan
kind
of
heard
a
lot
of
this,
and
he
suggested
what
you
know.
Let's
do
something
about
it!
How
about
we
have
a
introductory
session
outside
of
the
regular
meeting
that
this
group
holds,
which
is
just
a
onboarding
session,
or
a
class
of
sorts
where
folks
in
this
community,
who
are
veterans,
can
can
present
on
topics
that
are
obvious
to
folks.
A
Who've
been
working
on
this
for
a
while,
but
are
new
to
people
who
aren't
haven't
been
in
the
community.
So
in
our
last
meeting
it
sounded
like
everybody
was
on
board
for
this.
We
brainstormed
some
of
the
ideas
for
presentations.
Things
like
local
dev
environment
set
up
what
to
contribute.
What
does
the
sake
need,
help
with
and
appreciate
how
to
propose
and
add
new
features,
etc,
etc,
and
we
got
a
handful
of
folks
to
volunteer
to
do
presentations.
We
need
more
people
to
do
presentations,
given
the
memo
I
think.
G
G
A
Would
be
great,
it
sounds
like
there
is
the
need
for
to
afford
this
material.
So
the
next
steps
for
us
are
to
pick
a
date
and
pick
a
format
as
for
format.
I
was
thinking
just
another
one-off
meeting,
we'll
do
it
over
zoom,
we'll
record
it
and
publish
it
and
then,
as
for
date,
I
was
thinking
late,
late
January.
Does
that
sound?
Ok
to
folks.
G
Q
G
Q
That's
I
think
this
would
also
only
really
be
successful
if
we
have.
You
know
the
audience
that
it's
aimed
at
also
contributing
I
know
that
you
know
there
been
many
people
who
told
me
that
this
would
be
a
great
idea
at
UConn.
It
seemed
like
he
got
good
response
when
was
brought
up
last
week,
so
for
the
last
six
story:
painting
is
there
anyone
who
is
not?
Q
D
B
Q
Q
Q
A
L
Q
So
Chakri,
can
you
please
take
ownership
of
this
with
Jessie
mm-hmm,
maybe
make
sure
that
it's
very
clear
in
the
doc
yep,
because
people
are
a
you
know.
First
off
the
work
was
done
to
well,
which
means
that
you
know
everybody
wants
it
ASAP
and
there's
been
some
requests
from
people
about
having
a
PG
age,
somehow
in
1.8
and
then
I
think
there
is
also
some
confusion
over
it.
Also.
L
A
A
Q
Q
A
Q
A
Q
Q
Q
Can
do
that
yep
cool,
and
can
you
send
that
to
like,
maybe
me
or
Jesse
I
know
me
at
Google.
We
care
a
lot
about
this
for
communicating
this
internally,
but
if
other
people,
I
think
probably
should
be
looking
at
this
in
the
sink
so
maybe
send
it
to
sink
storage.
Okay,
cool!
That's
all
I
got.
Thank
you
very
much.