►
From YouTube: Kubernetes SIG Storage - Bi-Weekly Meeting 2023-01-26
Description
Kubernetes Storage Special-Interest-Group (SIG) Bi-Weekly Meeting - 26 January 2023
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
Moderator: Xing Yang (VMware)
A
Hello,
everyone
today
is
January
26
2023.
This
is
the
kubernetes
storage
seek
meeting.
Today
we
are
going
to
go
over
1.27
planning
spreadsheet,
and
then
we
do
have
a
couple
of
issues
the
issue
and
then
there's
a
design
review.
A
So
if
you
are
working
on
a
enhancement,
make
sure
that
the
enhancement
issue
has
the
lead
opt-in
label,
if
it's
not,
please
pin
one
of
the
Sig
leads
and
also,
if
you
want
to
opt
in
for
blog,
create
a
place
for
the
pr
against
this
website.
Kubernetes
website
repo
and
let
the
cichlids
know
so.
Let's
move
on
to
this
spreadsheet.
B
I
opened
a
PR
for
it,
and
I
am
working
on
updating
the
enhancement,
but
there
is
a
bit
of
a
what
to
say:
question
mark
for
the
feature
itself,
because
the
quality
of
service,
the
enhancement,
depends
on
the
apis
that
is
going
beta
in
this
release
and
they're,
proposing
changes
into
this
proposing
changes
into
allocated
resources
and
resize
status,
API
Fields.
So
if
we
do
make
those
changes,
I
think
this
is
something
we'll
have
to
discuss
afterwards
or
on
Monday
CSI
implementation
meeting.
If
this
feature
can
go
beta.
B
Yeah,
but
this
other
question
is
like
I,
don't
know
if
qas
the
quality
of
service
enhancement
will
go
Alpha,
we
just
don't
know
so,
but
we
have
to
decide.
C
A
B
Sure,
if
you
do
men
end
up
making
the
changes
to
the
API
to
accommodate
like
any
thing
either
from
qos
or
something
of
them,
I
think
we'll
have
to
still
keep
it
in
Alpha
for
One
More
release,
if
like
following
the
kubernetes
practices,
yeah.
C
D
A
Thank
you
next
one
is
the
issues
related
to
assuming
volumes
among
points
of
these
two
working
on
this
is
a
bug
fix
which
is
Jane
here
she
needed.
B
A
A
Next,
one
is
a
boring
group,
API
yeah,
so
the
CSI
is
back
is
being
reviewed,
I
think
then
have
reviewed
it
and
then
I
think
James
is
reviewing
now
and
he
has
some
comments
so
yeah
so
we'll
need
to
get
those
resolved
and.
A
Think
that
looks
like
the
two
main
thing
is:
why
is
this
ready
to
ready
to
ready
use
field,
whether
we
needed
a
group
of
like
I'm
now
thinking
if
we
don't
have
that
we
may
have
some
trouble?
If
we
first
report
success
and
then
report
a
failure,
we
don't
really
it
looks
a
little
weird.
Basically,
the
image
of
the
process
sounds
like
a
little
confused
now.
If.
E
A
And
there's
another
issue,
which
is
the
secrets?
Are
you
okay?
If
we
don't
have
the
voting
Secrets,
because
right
now,
I
don't
have
a
concrete
example
of
someone
actually
needing
it.
It's
humble
says:
if
they
don't
really
need
it,
so
I
want
I'm
thinking
the
secrets.
Might
it's,
although
they
they?
You
know
they
have
this
providing
secret,
but
it's
maybe
does
not
mean
everybody
has
a
different
Secrets.
It's
just.
They
need
to
pass
that
into
that
call.
A
E
F
Think
also
that
app
might
have
some
cases
for
per
volume
secrets
too.
A
Well
then
Ben
you
can
you
know
you
have
an
example
of
using
different
secrets,
but.
D
E
Well,
so
so,
when
I
was
still
at
NetApp
that
there
was
the
use
of
Secrets
for
the
purpose
of
encryption
like
it
wasn't
necessary
for
for
just
ordinary
functioning.
But
if
you
wanted
to
have
encrypted
volumes
yeah
you
would
need
the
secrets
and
then
I'm
trying
to
think
through.
Would
that
matter
at
snapshot
time
Maybe.
A
A
F
Worth
just
it
might
just
be
worth
poking.
Somebody.
A
F
A
Can
you
find
out
yeah.
A
Can
you
can
you
talk
because
it'd
be
better
for
you
to
ask
anybody
than
me,
you
actually
have.
A
I
can
also
ping
him
and
just
see
if
he
has
anything.
If
we
remove
the
volume
Secrets.
If
he
has
any
concerns,
he
didn't,
he
didn't
say
anything
about
the
secrets
at
all.
So
I
doubted
he
has
any
problem
with
that.
But.
E
A
Before
we
designed
them
did
anyone
complain
about
that?
I
have
never
heard
anyone
reporting
to
me.
They
have
a
problem
with
the
secrets
for
Lister
again.
C
A
E
E
I
would
have
to
guess
it
was.
It
was
Port
works,
okay,.
A
So
so,
let's,
let's
find
out
yeah
if
they
don't
have
I
mean
because
as
a
jam
was
saying
that
can
be
maybe
can
be
added
later.
If,
if
you
need
it
right,
so
it's
not
like.
We
can
not
add
that
later.
A
I
just
but
I
think
James
was
like
okay.
If
you
know
pews
and
complainers
stick
with
everywhere.
If
there
is
no
need,
then
what
you
would
want
it
I
mean
we
need
to
find
someone
who
actually
asked
for
it,
because
otherwise,
you
know
why
we
want
to
build
something.
Nobody
is
really
asking
for
that.
That
was
the
main
main
thing.
A
A
Yeah,
so
let's,
let's,
let's
just
see,
let's
at
least
chat
with
poor
works
and
NADA
at
least
to
you-
know,
check
this
one.
If
none
of
them
need
it
and
I,
don't
know
I
I,
don't
don't
know.
If
I
have
enough
evidence
to
tell
James,
we
definitely
need
it
right.
He
was
like.
Can
we
table
it
for
later?
So
so,
let's
get
back
to
this
one.
Let's
just
ask
them
questions,
okay,
yeah!
So
those
are
I.
Think
those
are
the
two
main
main
thing.
A
A
Okay,
and
and
and
also
I,
updated
the
cap
Michelle.
If
you
can
take
a
look
because
you
know
we
dropped
a
lot
of
things,
it
looks
sounds
good
yeah.
Thank
you
all
right
and
that's
this.
A
Okay,
the
next
one
is
provision
volumes
from
Cross
namespace
snapshot
PVC.
We
keep
this
thing
Alpha
right.
So
oh
Michelle,
you
want
to
up
even
give
an
update
on
this
one
yeah.
F
So
we
there
is
one
of
the
criteria
for
going
to
Beta
was
we
need
to
figure
out
or
remove
the
reference
Grant
API
into
a
like
sick
off
home,
and
so
the
cap
for
that
is
under
discussion
now,
but
I
think
we'll
who
are
pretty
much
have
to
wait
for
that
to
progress
before
we
can
go
to
Beta
And
I
think
there
were
a
couple
more
items
that
still
needed
it
to
be
implemented,
like
I,
think
the
e2e
tests,
and
also
the
the
populator
Library
update
and
so
I
think
takafuni
is
working
on
that.
A
Next
one
is
the
Cesar
volume
health.
This
is
the
Matrix
one.
Still
the
E2
test
is
still
work
in
progress.
I
have
not
got
an
update
from
Ryan
yet,
and
next
one
is
a
change.
Block
tracking
is
Yvonne
on
the
call,
so
we
have
been
discussing
this
one
in
the
data
production.
One
group,
because
last
time
the
the
aggregated
API
approach
got
rejected.
So
now
we
are
going
back
to
look
at
the
the
rest
approach
again.
A
A
Still
some
some
questions
that
we're
still
need
to
continue
to
discuss
how
how
to
implement
it.
This
way.
A
A
F
Production
Readiness
review:
oh
okay,
so
it's
it's
part
of
when
you
create
a
cap
there
they
have
the
cap
template
and
the
prr
template
is
also
there.
It's
there's
a
bunch
of
questions
on
like
you
know.
What
is
what
slis
and
metrics
do
you
have
any
playbooks
and
you
know
how
does
like
upgrade
and
rollback
and
stuff
work.
A
You
yeah,
so
if
you
have
a
cat,
then
make
sure
that
you
have
that
that
section
filled
out
by
I
think
it's
the
second
I
believe
so
this
deadline.
A
E
A
Is
update
the
pr
yet
or
is
still
working
on
it.
A
Yeah
I
think
he
said
he
will
try.
Alpha
awesome.
A
A
F
A
F
Asked
deep
to
take
a
look
at
this
I
think
deep
left
some
feedback
already:
okay,.
H
Yep
there
has
been
no
update,
I
want
to
update
the
Gap
soon
ish
and
send
it
to
prr.
A
Oh
I
do
have
a
question,
so
you
you
have
this
new
issue
for
the
Reconstruction
right.
Is
that
do
we
track
it
here?
What
what
are
we
yeah.
A
A
Okay,
so,
hopefully
okay,
so
we
need
to
get
a
read
so
who
is
going
to
how
far
to.
A
You
can
probably
help
review
this
as
well
right,
okay,
so
this
is
this.
Does
it
doesn't
need
a
API
review
this
one.
F
F
A
H
A
All
right,
sorry,
where
are
we
oh
did
I
think
we
missed
something
we
I
was
like:
okay,
I
think
I
missed
this
one
note:
expansion,
secret
I,
think
humble
said,
humble
said:
the
the
test
will
be
ready
by
Monday
business
and
then
CSM
migration.
So
we
have
a
few
items
just
for
removing
entry
code.
C
On
this
yeah
I
mean
I
I,
guess
you
can
put
my
name
here.
It's
we
can
say
as
a
cloud
provider.
We
are
looking
for
volunteers
to
help
us
with
this.
Okay,
yeah.
D
A
And
then
I
think
the
next
one
is:
let's
do
this
that
one
Andy
is
working
on
this
I
think
he
already
has
a
here.
It
has
a
PR.
A
And
because
you
file-
okay,
not
ready
yet
save
RBD,
so
so
humble
said,
he's
going
to
take
a
look
and
see
if,
if
he
can
do
this
for
basically
beta
in
1.27,
so
so
he
will.
Let
us
know
next
week.
A
And
next
one:
what
works
is
immigration
I
checked
with
Oksana,
but
she
has
not
got
back
to
me.
She
said
she.
She
will
take
a
look
but
I'm,
not
sure.
D
A
A
A
A
The
ga
okay
I'll-
just
let
me
just
skip
this
okay,
so
next
one
quality
of
service
for
volumes
so
mad
sunny.
You
want
to
give
a
review
I'll,
give
a
update
on
this
or.
C
Yeah,
if
we
have
a,
we
were
figuring
on
discussing
things
here,
I
think
it
is
probably
unlikely
that
we'll
have
a
cap
for
this
to
be
Alpha
in
127,
but
we
should,
you
know,
make
it
a
provisional
cap
to
cycle
and
I
I
think
I
mean
so
far.
We
found
the
main
thing
is
actually
this
coordination
with
the
recovery
from
the
expansion
failure,
so
we
could
probably
focus
on
resolving
that
anyway.
That
was
our
idea.
If
other
people
think
we
could
make
it
in
127
as
Alpha.
B
Yeah
I'll
review
that
one
and
let's
talk
about
the
yeah
building
the
concerns
on
a
Monday
meeting.
Okay.
A
All
right
next
one
is
efficient,
long
time
handling
of
FS
group,
so
Jonathan
yeah.
G
Right
so
I
don't
have
any
updates
this
week.
I
still
have
some
changes
to
make
to
the
cap.
I
just
need
to
find
the
time
to
follow
up
on
that.
A
Okay,
another
thing
is:
is
this
a
design
in
1.27?
It's.
A
You
do
this
design
I
think
we
talked
about
this
next,
one
robust
will
be
manager,
reconstruction
and
the
next
one
down
graceful,
nosha
I
think
it's
yeah
wait
for
One
release,
so
we'll
keep
looking
at
the
E3
test,
and
next
one
is
a
each.
B
Robust
doesn't
even
have
any
concern
of
this
feature
going
to
Beta
like
like
we
are
gonna
try
but
I'm
just
trying
to
do.
A
B
F
A
So
that
yeah
see
just
to
yeah.
But
if
it's
already,
you
basically
added
the
code
in
what
1.26
1.25
the.
H
Reconstruction
most
of
the
code,
okay
in
the
Gap,
you
need
this
to
promise
some
metrics,
so
it
will
be.
This
will
be
new
code.
Okay,.
A
H
A
A
I
think
only
six
weeks
has
a
edit
permission,
but
you
can
comment.
If
you
add
a
comment,
then
we
can
accept
it.
Okay,
because
in
the
past
I
think
that's
a
the
it
was
like
by
accident.
Something
got
deleted,
that's
why
then
we
changed
the
commission
initially
there
was.
This
was
like
added
up
about
everybody.
E
A
F
A
Right:
okay,
okay,
address
issue
TVC
created
by
staple
said,
will
not
be
Auto
removed.
This
one
is
already
beta
already
met,
so
do
we?
Are
we
doing
anything
or
it's
targeting
beta?
Oh,
yes,
Oh
I
thought.
Okay,
I,
don't
know.
I
saw
how
I
thought
this
is
already
beta.
C
No,
it
it
okay.
C
Okay
yeah,
just
at
the
11th
hour,
it
should
go
beta
in
now.
There
is
some
tests
issues
because
of
a
lot
of
the
crowd.
Jobs
no
longer
have
a
default
storage
class,
which
has
made
a
lot
of
the
state
full
set.
End-To-End
tests
like
okay.
A
H
Since
when
it
was
released
and
since
when
it
was
bound
and
so
on
so
I
will,
capis
is
going
to
be
published
soon-ish,
hopefully
this
week
and
it's
like
quite
a
simple
feature:
I
will
add
the
fields
so.
A
Yeah,
don't
forget
that
second
favorite,
second,
is
the
prr
ready
for
remediate.
A
No
come
back
here,
so
there
are
two
cups
here.
Let's
see
the
first
one
is
three.
Seven.
Five
one
is
okay,
so
this
is
the
company
it's
falling
before.
A
Yes,
sorry
I
forgot
I
actually
saw
this
haircut
distracted,
but
let
me
okay,
so
let
me
add
your
name
there.
Let's
see,
what
do
you
want
to
do
a
season
AWS
EBS
great.
Thank
you.
Eddie
yeah,
thanks
for
reminding
yes.
A
A
Okay,
so
so
Sunny,
you
added
this
one
here
right.
D
A
Yeah
yeah,
we
can
just
ask
people
to
review
the
review,
the
cap,
I
think
or.
C
Perhaps
really
useful
to
like
it
seems
the
most
critical
thing
is
the
recovery
from
expansion
decision?
Would
it
be
worthwhile
talking
about
both
of
those
issues
now.
B
I
was
told
to
say
that
this
API
does
proposes
changes
shows
the
changes
in
the
allocated
resources,
but
it's
not
showing
what
I
think
we
are
also
changing:
resized
status
field
and
when
I
looked
at
it,
it
didn't
show
the
what
is
how
that
is
being
changed.
C
Yeah,
so
the
idea
is
I
think
with
the
so
the
allocated
resources
field
and
the
status
would
not
change
right
because
that's
just
a
map
and
then
the
idea
yeah.
So
it's
yeah
as
as
mentioned
here
so
instead
of
having
a
so
as
I
have
understated
standard.
The
resize
status
field
is
basically
maps
to
the
capacity
in
the
allocated
resources.
C
So
it
seems
like
a
general
way
to
have
a
status
would
be
to
have
a
map.
That's
parallel
to
allocated
resources.
You
know
and
then
has
an
entry
using
the
same
key.
So
in
the
case
of
resize
it
to
be
the
capacity
and
then
for
the
qos
stuff,
there
would
be
a
status
for
the
corresponding
resources.
You
know
iops
or
throughput.
B
Yeah
just
trying
to
pull
so
that's
already
allocated.
Resources
is
already
a
map
right
yeah,
so
that
doesn't
need
any
change
such
as
I
understand
it.
Correct.
C
Yeah
so
so,
currently,
there
is
a
a
resize
status
and
I
guess.
The
thing
is
like,
as
we
add,
more
resources,
the
kind
of
you
know.
If
we
have
a
resize
status
field,
then
each
new
resources
get
that
gets
added
will
have
to
add
a
a
a
new
status
field
for
itself,
which
is
kind
of
a
pain,
and
so
it
seems
like
it
would
be.
C
I'm
not
General
to
have
the
sort
of
operation
status
field,
be
a
map
as
well,
and
that
makes
it
a
lot
easier
to
extend
it.
C
F
Guess
Shing,
if
you
go
back
to
that
the
code,
this.
A
C
A
D
C
B
Okay,
that
makes
sense
to
me,
there's
a
one
more
thing
like
when
we
did
this
design.
We
also
followed
a
little
bit.
What
part
resizing
was
doing
and
I
just
want
to
like
take
a
look,
what
they
are
doing,
because
yeah,
if
they're,
also
doing
something
similar
or
like
what's
was
so.
That
is
something
I
want
to
like.
We
also
take
a
look
whether.
B
F
And
I
guess
the
other.
The
other
suggestion
I
have
in
the
cap
itself
is
I.
Think
I.
Guess
it
was
this
actual
change.
Wasn't
it
really
clear?
So
if
in
the
cup
you
can
actually
add
like
the
type
definition,
the
proposed
type
definitions
and
the
changes
I
think
that
would
help
yeah.
B
It's
it's
not
clear
that
what
change
we
are
proposing
to
resize
status,
yeah
and
the
application,
and
the
second
thing
is
that
we'll
have
to
probably
involve
someone
from
API
and
the
people
who
maintain
quota
code,
which
is
kind
of
very
hairy
and
tricky.
So
it's
like
yeah
because
we
are
proposing
new
Fields
into
the
quota.
B
B
And
like
today
morning,
not
today
morning,
yesterday
yeah
so
the
quota
has,
and
we
have
to
figure
out
that
can
the
iops
and
throughput
be
replenished
to
the
end
user
to
the
user.
Will
they
wish
like?
Are
we
proposing
that
they
can
be
reduced
or
just
increased.
C
No,
they
think
they
need
to
be
able
to
go
both
directions
because,
at
least
for
us,
some
of
our
customer
use
cases
is
for
like
doing
cost
optimization.
C
B
Okay,
yeah
I
mean
that.
B
That
is
kind
of
like,
obviously,
it's
challenging,
but
we
have
to
figure
out
like
do.
We
want
to
like,
like
have
a
flow
of
how
it
will
look
like
like
like
something
that
we
did
for
recovery
and
so
that,
like
how
will
it
flow
through
like
when
the
quota
is
replenished
and
when
the
user
reduces
size?
When
something
is
in
progress,
it
is
going
to
flow
exactly
like.
Besides,
we
expect,
or
there
will
be
changes.
C
I
expect
it
will
be
the
same
I
mean
because
we
have
the
basic
thing
that,
like
the
user,
is
going
to
make
requests
in
the
PVC,
so
then
it'll
be
in
a
pending
State,
then
we're
going
to
figure
out
after
we
make
the
call
to
the
cloud
provider
whether
the
iops
was
granted
or
not,
and
so
I
I
think
that's
the
same
as
resize
I
think
it's
a
great
idea
to
document
that
flow
more
explicitly.
F
B
F
Guess
I
would
maybe
in
terms
of
reviewing
this
I,
would
maybe
take
it
in
two
phases.
One
is
first
like
review,
the
user
experience
and
the
apis,
and
you
know
at
least
make
sure
we
come
to
agreement
on
that
and
then
the
next
steps
would
be
to
like
dig
into
a
detailed
design
exactly.
You
know
how
it's
going
to
flow
between
the
various
components.
D
So
so
in
the
in
the
cap
there
is
a
simple
flow
just
for
the
initial
reveal.
So
if
you
want
to
take
a
look
there.
I
Oh
yeah,
sorry
I,
didn't
see
anything
in
the
cap
to
address
current
providers
that
are
that
have
iops
and
throughput
in
storage
class.
Today.
C
Yeah
I
thought
that
that's
a
good
point,
so
the
the
way
that
we're
planning
on
doing
this
in
gcp
is
that
what
we
have
in
the
storage
class
is
called
something
like
provisioned
iops
on
create
to
make
it
explicit
that
it's
just
something
to
be
referred
to
at
creation.
Time
and
you
know,
could
be
changed
in
the
future
and
I
think
that
sort
of
seems
like
the
right
semantics
for
a
storage
class
in
general,
because
I
mean
you
know.
Just
in
terms
of
the
you
know
how
stuff
works.
C
F
I
guess,
though,
I
think
we're
I,
guess
or
thinking
about
like
a
migration
paths,
because
I
guess
eventually
even
specifying
it
in
the
PVC
that
could
be
used
for
provisioning
too,
initially
or
in
the
future.
C
F
C
B
We
have
like
requests
or
bugs
to
scale
the
iops
when
the
disk
is
resized,
at
least
for
EBS,
for
example,
because
so
iops
isn't
per
GB,
so
the
total
iops
should
change
when
the
this
goes
bigger.
B
So
my
point
is
like
for
that
stuff
like
what
do
we
expect
if,
if
like
right
now,
we
could
scale
iops
without
this
proposal
like
as
long
as
we
go
to
EBS
driver,
which
is
the
code
to
scale
the
iops
based
on
the
research
request?
So
how
do
we
like,
if
any
driver
is
doing
that?
Currently,
what
do
we
expect
that?
How
do
we
do?
We
expect
that
driver
to
say
that
okay
I
have
scaled
iops?
Will
it
be
recorded
or
like
it's
just
there?
It's
just
internal
implementation
detail.
We
don't
care.
C
I
guess
to
me
that
feels
like
an
internal
implementation
detail
like
already,
we
don't
really
Define
what
a
provisioned
iops
is
and
I
could
see
like
if
some
providers
Define
the
provisioned
iops
absolutely
and
other
providers
Define
it
in
terms
of
iops
per
gig,
like
I,
think
all
of
the
quota
type
stuff
kubernetes
does
would
work
the
same
way
right.
You
still
have
a
limit
and,
depending
on
your
provider,
sometimes
it's
per
gig.
C
Sometimes
it's
absolute
yeah,
and
so,
like
the
the
actual
interpretation,
is
cloud
provider
specific
and
not
necessarily
something
that
kubernetes
is
aware
of,
like
I'm,
definitely
hesitant
to
like
Plumb
in
additional
flags.
That
say,
you
know
like
exposed
to
kubernetes
details
like
if
the
cloud
provider
automatically
scales
or
not.
That
just
seems
like
a
can
of
worms
that
we're
not
really
going
to
be
able
to
get
it
clean
solution
to.
F
I
guess
the
defining
you
know
sort
of
defining
how
the
error
handling
should
be
reported
in
terms
of
those
error.
Cases
like
if
somebody
tries
to
adjust
the
iops
without
adjusting
capacity.
But
the
you
know
back
end
only
supports.
B
C
C
F
C
I
C
It
is
this
kind
of
weird
weird
case
now,
where
it's
kind
of
a
semi-validated
map.
B
F
B
D
G
C
B
So
yeah
it
generally
gets
validated
other,
like
similar
other
enormous,
get
validated
like
this,
but
I
guess
we
are
not
validating
it.
I,
don't
remember
if
we
are
violating
resource
name,
but
okay,
so
yeah.
That
bit
has
to
be
like,
because
if
you
are
going
to
add
vendor
things-
and
it
brings
up
the
whole
question
about
whether
it
will
be
how
it
will
be
like
Kota
and
all
that
work,
because
the
way
I'm
seeing
is
like
throughput
iops
is
there's
a
corresponding
field
in
quota.
But
if.
B
F
Think
it
would
be
good
to
have
a
section
somewhere,
I,
don't
know
if
there's
already
a
section
here
about
like
sort
of
the
pros
and
cons
of
like
first
classing
a
provisioned,
IO
concept
and
like
what
things
we
could
do.
If
it
was
a
first
class
concept
versus
what
things
you
would
not
be
able
to
do.
If
it
was
a
third
party
thing.
F
C
Me
if
I
could
just
dig
into
that
a
bit
more,
so
the
way
a
quota
works
is
it's
also
just
a
resource
list.
I
thought
so
you
know
like.
If
we
open
it
up,
would
it
be
reasonable
for
people
to
add
azure.io,
slash
tunable
to
a
quota
as
well,
and
just
as
long
as
this
tunable
thing
is
a
number
where
you
know
it
gets
bigger
and
smaller
and
can
be
compared
against
a
quota?
Does
everything
work
or
is
there
some
some
cases,
I'm
missing?
Where
that
that
could
possibly
break
break
things?
E
Does
the
quota
system
allow
a
like
a
flat
limit,
not
like
not
a
not
a
limit
to
the
sum
of
all
of
the
values,
but
just
to
limit
that
every
value
must
be
less
than
x,
no
matter
how
many
there
are
I'm
thinking
for
for
things
that
scale
with
size
like
iops
per
gigabyte,
you
might
want
to
say
your
quota
is
100
iops
per
gigabyte
periods.
You
can
always
ask
for
100
hours
per
gigabyte
or
less,
but
nobody
ever
adds
up
all
the
iops
per
gigabyte.
You've
asked
for
because
that's
a
nonsensical
number
yeah.
B
C
B
Yeah
also
like
the
API
team,
might
have
something
to
say
about
like
yeah,
about
extending
resource
quota
with
vendor
specific
strings
that
way,
I
don't
know
because
they
have
like
they
have
different
kind
of
resources.
Like
countable
resources
like
you,
you
can
set
a
quota.
Oh
I
want
have
five
PVC
and
there's
a.
There
are
other
resources
which
are
counter
definitely
like
a
differently
like,
like
storage
like
two
gigabyte
or
like
it's
so
so
we
stood
will
have
to
be
kind
of
mindful
of
that.
B
And
if
we
also
had
vendors
vendor
the
this
Fields,
then
how
will
the
research
so
research
status
will
be
a
map
and
it
will
be
also
like
a
wild
card
like
not
wild
card
but
like,
but.
C
Yeah
so
so
I
I
think
the
idea
there
is
then
you
like,
if
you
have
as
your
dot
IO
tunable
in
your
resource
you'll,
have
that
same
key
in
your
allocated
resources
and
then
the
same
key
in
your
status
and
like
the
thing
that
the
that
we're
going
to
Define
in
the
API
is
that
those
keys
are
going
to
match.
And
then
the
status
you
know
is
going
to
go
through
a
flow.
But
we
aren't
going
to
and
an
enumerate
the
possible
keys.
F
I
think
I
think
it
might
be.
The
this
comment
here
I
think
is
mostly
just
to
say
that,
like
I,
don't
think
the
comment
here
is
to
say
we're
gonna
explicitly
like
support
and
facilitate
the
any
like
custom
resources,
right,
I.
Think
it's
just
to
say
it's
more
of
like
a
alternative
right.
If
somebody
wants
to
implement
their
own,
then
they
could
do
it.
But
in
terms
of
like
this
proposal
and
like
the
controllers
and
the
whole
flow,
we're
only
gonna
be
looking
at
these
first
class
keys.
C
So
I
I
thought
there
was
one
part
of
validation
or
something
that
actually
did
enforce
a
subset
of
keys
and
I.
Think.
A
A
Running
out
of
time
actually
so
we
can
continue
talk
about
this
Monday
or
I,
otherwise,.
C
Yeah
I
think
that
sounds
good
to
me.
I'm
super
happy
that
there's
so
much
interest
here.
I
think
the
one
thing
is
is:
are
we
okay
with
delaying
the
recovery
from
resize
expansion
graduation
to
Beta
in
order
to
change
the
status.
B
C
A
Make
a
decision
whether
we
want
to
delay
this
on
Monday,
then
yeah,
and
then
the
the
rest
of
those
I
think
either
bring
it
up
next
in
the
next
meeting,
or
maybe
some
of
those
can
also
be
on
the
next
Monday
or
Wednesday's
meeting
yeah.