►
Description
Kubernetes Storage Special-Interest-Group (SIG) Object Bucket API Standup Meeting - 17 May 2021
Meeting Notes/Agenda: -
Find out more about the Storage SIG here: https://github.com/kubernetes/community/tree/master/sig-storage
A
Present
a
json
structure
in
in
a
string.
B
So
so
so
help
me
understand
exactly
what
we're
trying
to
do
here
so
so
for
s3
in
your
example
effect
allow
action,
s3,
put
object
resource
that.
A
B
Like
yeah,
I've
seen
some
of
these
because
the
the
netapp
api
mimics
s3
quite
closely,
and
we
actually
support
exactly
this
syntax
for
some
reason
without
the
version
yeah.
So
I
I
guess
I
guess
what
I
question
is
like.
Do
you
need
this
level
of
granularity
in
cozy
like
I
would
have
presumed
that
that
what
you
want
is
to
just
say.
Well,
you
you
know
buckets
you
create.
You
have
basically
root
access
to
or
whatever
you
know,
the
equivalent
of
root
accesses
and
bucket
land.
B
You
know
you,
you
created
the
bucket,
you
you
own
it.
You
can
do
everything
to
it
and
then
there
would
be
some
lower
levels
of
access,
like
maybe
read
only
maybe
maybe
access
to
a
subsection
of
a
bucket.
I
don't
know
what
that
exactly
looks
like,
but
yeah
so
do
we
need.
A
A
B
Well,
so
I
I
don't
know
if
I
believe
that
so
so,
like
much
like,
we
have
a
brownfield
backdoor
for
people
who
already
have
buckets
that
they've
created
and
they
just
want
to
use
them.
B
Couldn't
we
do
the
same
for
bucket
accesses
and
say:
look
you
know
if
you
already
have
a
bucket
access
that
you've
crafted
in
your
vendor-specific
way
that
that's
that's
beyond
the
capability
of
cozy
to
manifest,
and
you
just
want
to
use
it
shouldn't.
I
just
be
able
to
create
a
bucket
access
that
refers
to
it,
an
identity
that
already
exists
and
then
just
bind
that
to
a
bar
and
say
you
know,
go
nuts
this!
This
br
will
give
you
what
you
want
and
it's
it's
sort
of
it's
a
brownfield
bar.
Basically.
B
What
I'm,
what
I'm
getting
at
is
like
the
default
case.
The
green
field
case
is
like
I'm,
creating
the
buckets
inside
inside
kubernetes
right,
so
so
I'm
managing
the
bucket
life
cycle
through
kubernetes
so
like.
If
I'm
doing
that,
do
I
need
to
have
all
these
special
rules
or
do
I
just
want
to
create
buckets
and
then
have
basically,
you
know.
A
B
Yeah
yeah,
so
I'm
not
credentia,
credential
minting
is
an
essential
function,
but
I'm
saying
like
the
the
most
important
credential
minting
function
is
like
the
maximal
permission,
credential
right,
where
you
say
this:
credential
can
do
all
of
the
things
to
this
particular
bucket,
which
which
was
also
created
through
cosy,
and
so
we
implicitly
trust
the
guy
that
is
asking
for
access
because
he
created
it
right.
There's
no
reason
to
deny
the
creator
any
any
level
of
access.
That's
bad!
B
A
A
Kubernetes
actually
yeah.
You
might
want
to
have
why?
Okay,
so
maybe
I'm
over
engineering
here,
so
I'm
looking
forward
to
your
response
to
this.
But
what?
If?
What?
If
you
know,
there's
a
there's,
a
organization
right
policy?
That's
like
you
can
you
know
you
can
you
can
write
data,
but
you
know
don't
delete
it
like
you,
disallow
deletes.
B
So
like
that,
that
could
be
that
could
be
it's
a
bucket
access
class
parameter
right
like
worm,
yeah
or
yeah.
A
A
There's
some
policies,
it's
an
access
policy.
Like
again,
I
I'm
not
entirely
sure
if
I'm
over
engineering
with
this
question,
though
in
the
sense
it's
already
going
into
a
niche
use
case
by
coming,
bringing
up
this
example
right.
B
So
in
the
volume
world
we
don't
go
anywhere
near
here
like
we,
we
have
very
simple,
you
know,
there's,
there's,
there's
read,
write
volumes
and
there's
read
only
volumes
and
there's
redirect
and
there's
read,
write
once
and
regret
many
and
like
and
that's
it
like.
We
don't
get
into
like
you
can
read
these
subdirectories
and
you're
allowed
to
delete
these
files
and
yeah.
A
B
A
Is
different
from
object,
storage,
api?
I
don't
think
we
can.
It's
like
comparing
apples
and
oranges
here,
because,
with
with
with
drives
or
file
systems,
you're
you're
talking
only
locally,
you
don't
have
multiple,
parallel
accessories
from
different
nodes
as
the
norm
in
in
this
case,
this
is
the
norm
and
and
access
policies
are,
you
know,
like
my
my
concern
is,
would
we
be
restricting
people
who
were
already
using
object,
storage
buckets
from
from
doing
what
they
could
already
do?
Well,.
B
That's
why
I'm
saying
like
no
matter
what
we
do.
The
ability
to
have
like
a
brownfield
bucket
access
seems
to
make
sense
right,
like
if
you
already
have
something
you've
constructed
that
you
just
want
to
use
and
cozy
isn't
powerful
enough
to
have
made
what
you
want
like
you
should
just
we
should
grant
you
the
ability
to
just
use
the
pre-existing
thing,
like
your
credential,
that
you
have
say,
oh
use,
this
credential,
don't
let
cozy
mess
with
it.
We're
just
going
to
use
it.
A
B
But
but
but
my
problem
is,
is
that
like,
if,
if
what
we're
trying
to
do
is
create
consistency
across
implementations,
then
this
this
has
to
be
fully
specified
at
the
rpc
layer.
We
need
to
say
like
this.
This
is
what
is
this
is
the
format
of
a
specification
and
everybody
who
implements
feature
x
must
support
this
format.
A
A
That
is
it
really
inconsistent,
though,
because
all
we're
saying
is
the
bucket
access
class,
which
is
an
admin
defined
resource.
So
we
we've
said
that
with
admin
defined
resources
we
can
have
inconsistencies.
Bucket
access
clause
is
what
would
have
this
and
we're
saying
we'll
just
pass
it
along
as
an
opaque
string.
So.
B
A
B
A
B
B
C
It's
not
only
the
structure,
some
storage
systems
may
I'm
just
looking
at
the
screen
here.
You
have
this
condition
field
where
the
string
equals
function.
So
you
want.
If
one
vendor
implements
so
aws
implements
string,
equals
and
another
one
does
not,
then
they
still
need
to
be
able
to
raise
an
error
so
to
say.
C
It's
probably
natural,
it
goes
beyond
that
and
if
we
say
aws's
schema
is
the
right
one,
and
we
saw
I
mean
that
we
that's
the
canonical
one
and
we
somehow
turned
that
into
an
open
api
spec,
to
which
some
or
you
know,
a
ghost
truck
to
which
this
field
must
adhere.
Then
it
still
doesn't
necessarily
mean
that
all
drivers
implement
this.
B
Well,
so
so
this
is
what
I'm
trying
to
get
to
is
that
like
either
either
we
want
to
have
a
standard
that
everyone's
conforming
to
or
we
don't
and
if,
if
we
don't,
then
there's
got
to
be
a
prettier
way
to
sort
of
take
the
opaque
stuff
and
and
pass
it
pass
it
through
or
provide
it
to
the
to
the
driver.
Having
I
mean
just.
B
A
It's
vendor
specific.
Already
I
mean
we
don't
expect
interoperability
for
an
s3
specific.
You
know
access
policy.
This
is
this
is
aws
specific
accessibility.
I
wouldn't
even
say
this
is
specific,
but
I
guess
what
I'm
getting
at
is
like.
There
should
be
an
out
of
the
box
default
that
works
everywhere.
A
B
To
be
able
to
create
a
bucket
access
class
right,
you're,
forcing
me
to
understand
this,
because
I
I
should
be
able
to
create
a
bucket
access
class
that
has
nothing
in
it.
That
just
says
this
is
the
name
of
a
bucket
access
class,
it's
empty,
and,
and
that
means
I
get
full
control
of
all
my
buckets
like
you
know
it
or,
or
something
like
that
right.
B
A
B
Know
I'm
just
if
you
look
at
like
the
volume
case
like
you
can
create
an
empty
storage
class.
The
storage
class
has
literally
nothing
in
it.
You
can
create
a
pvc
and
on
the
vast
majority
of
kubernetes
clusters,
unless
they
have
extremely
weird
configurations
out,
will
pop
a
volume
that
you
can
read
and
write
to
right,
like
that's
just
the
default
and.
A
I
want
to
well
that's
the
default,
but
there
are
some
drivers
which
need
something
like
wait
for
first
consumer
and
they
won't
work
without
it.
I
mean
I
I
think
I
think
so
you
know
so.
Let's
say
I'm
a
vendor
and
I'm
shipping
my
cosy
driver
right.
It's
it's
reasonable.
To
expect
me
to
have
a
bucket
access
class
defined.
That's
the
default.
A
B
B
For
my
workload
or
not-
and
I
go
read
the
docs
and
I'm
like
okay,
I
need
to
create
a
bucket
class
and
I
need
to
create
a
bucket
access
class.
I
need
to
install
this
sidecar
and
this
stuff,
so
I
mean
I'm
figuring
it
out
and
it's
like
okay
and
then
I
want
to
be
able
to
create
a
bucket
request
and
then
I
will
pop
a
bucket
that
I
can
use
and.
A
A
B
A
A
Was
hard
if
if
you
don't
have
a
empty
default.
B
And
and
then,
of
course,
yeah.
If
you
want
to
have
ways
to
tweak
it
and
and
go
down
the
rabbit
hole
of
complex
configurations
like
there
should
be
ways
to
do
that.
But
I
feel,
like
we've
created
a
situation
where
you,
you
have
to
understand
the
language
of
policies,
at
least
for
your
driver
to
even
create
a
bucket
class
or
bucket
access
class.
That
does
anything
at
all
and.
A
This
wasn't
that
responsible
on
the
on
the
vendor,
we're
saying
the
vendor
will
go
through
the
trouble,
but
as
the
user,
you
just
use
the
default
that
the
vendor
gave
you.
Unless
you
want
to
get
more,
you
know
advanced
and,
and
then
you
can
go
and
edit
these
policies.
Okay.
Okay,
so
I
don't.
B
Maybe
we
need
to
just
like
experiment
some
and
propose
some
things,
because
because
you're
right,
like
as
a
vendor
like
we
were
implementing
cozy
two
weeks
ago,
and
we
got
to
this
bucket
access
class-
and
we
said
you
know
what
the
hell
is
this
and
we
just
skipped
it.
We're,
like
you
know
what
we're
gonna,
throw
this
in
the
trash
and
do
our
own
thing
and
and
it'll
work
anyways
and
right.
That's
that's
what
we
ended
up
with.
To
be
honest
with
you.
B
A
Like
I
said
some
policies
that
I
brought
up,
but
no
I'm
I'm
I'm
convinced,
so
so,
let's
see
what
we
need
to
come
up
with
solutions.
I
I
understand
the
problem.
We
may
come
up
with
solutions.
A
There
has
to
be
talking
about
storage
classes.
The
reason
the
empty
was
valid
was
because
storage
classes
came
after
csi,
came,
storage
classes,
predate
csi,
I'm
pretty
sure
it
was
the
other
way.
Look.
There
have.
B
Dynamic
provisioners
needed
storage
classes.
There
was,
there
was
a
period
of
time
when,
like
you
had
to
create
your
pvs
manually
and
then
the
bind
controller
would
bind
them,
then
dynamic
provisioners
were
invented
where
you
could
just
create
a
pvc
when
there
was
no
pv
and
something
would
see
that
and
go
create.
A
pv
and
the
storage
class
was
used
by
that
mechanism,
and
I
know
this
because
netapp
had
a
dynamic
provisioner
before
csi
existed
and
it
used
storage
classes.
A
B
A
The
question
is
like,
maybe
because
I
was
trying
to
say
that
storage
classes
have
this,
maybe
only
because
they
came
later,
you
know
where
they
love
defaults,
but
since
you're
starting
from
scratch,
you
know
it's.
It's
like
saying
bucket
request.
It's
like
saying
we
don't
have
the
concept
of
an
empty
bucket
request.
Isn't
isn't
it
fair
to
say
that
we
don't
have
the
concept
of
an
empty
bucket
access
class
or
a
bucket
class?
And
I
know
where
you're
coming
from
you're
saying
there
should
be
a
default
set
of
access
policies.
B
Maybe
not
maybe
not
empty,
but
like
there
should
be
a
one-liner
that
I
can
put
in
there.
That
says,
give
me
full
control
of
my
buckets.
That
means
the
same
thing
on
every
on
every
implementation,
so
that,
if
I
never
want
to
learn
the
details,
I'm
not
forced
to
right
that
we're
trying
to
lower
the
the
the
bar
to
adoption
to
say
you
know
if
you
want
to.
If
you
want
to
be
an
idiot
and
just
create
bucket,
you
know
copy
paste,
some
bucket
access
class
you
found
on
the
internet.
B
A
A
B
B
B
Well,
full
control
full
access
yeah,
but
but
what
I
was
trying
to
say
is
like
I
think
that
we
need
some
some
basic
level
like
that,
that
is
implemented
across
all
of
them
and
then
yeah.
And
then
I
don't
have
a
problem
with
like
opaque
extensions
to
that.
But
we
need
to
to
decide
like
you
know
where
we
want
to
draw
the
line
between
what
is
what
needs
to
be
supported
across
the
board
and
then
where,
where
you're,
going
off
into
vendor
vendor.
A
A
B
C
C
B
Yeah
yeah,
no,
I
you
know
yeah.
It
should
be
full
data
access,
the
ability
to
create
and
delete
and
list
and
read
in
you
know,
iterate
over
objects
in
the
bucket,
but
yeah
not
necessarily
manage
the
bucket
life
cycle,
because
that's
kubernetes
job,
where
that's
cozy's.
A
B
Well,
I
I
don't
want
to
like
decide
on
terms
right
now,
where
I'm,
where
I'm
going
is
like
when
you're
writing
the
documentation
for
this
right,
like
you're,
writing
the
documentation,
that's
going
to
face
the
kubernetes
you're
going
to
say
here.
Is
you
know
your?
The
page
is
titled
bucket
access
classes,
how
to
create
a
bucket
access
class?
B
Okay
in
order
to
create
bucket
access
requests,
you
need
a
bucket
access
class
and
it
needs
to
have
a
name
and
it,
and
then
it
has
the
following
fields,
and
then
these
are
the
fields
that
are,
you
know
well
defined,
and
this
is
what
they
mean,
and
these
are
you
know
you
can
have
this
value.
You
can
have
this
value.
You
got
a
document
such
that
the
guy
reading.
That
page
knows
what
he's
going
to
get.
B
No
matter
what
and
then
you
have
another
section
that
says
like
these:
are
the
opaque
parameters
in
the
bucket
access
class
go
read
your
vendor's
documentation
to
understand
what
to
put
here,
right
and
and
because
that's
how
it
is
for
storage
classes,
right
storage
classes
have
a
bunch
of
stuff
where
kubernetes
tells
you
what
the
field
means
with
certainty
and
then
there's
another
section
that
says
these
are
the
these.
Are
the
parameters.
A
That
are
you
know.
Posix
is
simpler
than
object
api,
but
actually
that
what
nicholas
nicholas
of
vienna
I'm
not
sure
what
said
what
they
said
makes
me
think.
So,
if
it's
only
data
operations,
can
we
actually
model
it
like,
like
forget,
forget
all
these
other
things,
but
if
it's
only
data
operations
like
put
object,
get
object,
list
objects.
A
If
it's
only
those
three
things
can
we
model
it
like?
Can
we
actually
have
a
real
structure
and
then,
if
someone
wants
to
override
it,
like
you
said
they
can
override
it
like
you
can
have
a
simple
policy
or
an
advanced
policy,
or
something
like
that.
I'm
just
throwing
out
ideas
out
there.
Okay,
so
you
like,
I
want
everyone
to
participate
and
tell
me
what
what
they
think
like.
I.
A
Yeah
this
is
all
optional,
but
but
in
object
storage,
I
think
it's
fair
to
say
across
all
providers
the
the
common
set
of
operations
that
that
you
know
that
we
can
model
is
like
put
object,
get
object
and
list
object
and
delete
objects.
Those
these
four
so.
A
We're
getting
to
oh
okay
yeah,
should
we
should
we?
Should
we
actually
model
them?
Should
we
actually
go
down
that
route,
because
earlier
the
reason
we
didn't
is
because
it
seemed
like
every
every
vendor
had
their
own
format
and
their
own
level
of
granularity,
but
but
I
think
these
be
four
base.
Operations
are
fair
to
model,
I
think
there's
nothing
wrong
with
it,
and
and
then
we
can
have
an
advanced
mode
where
you
know
people
can
throw
in
these
opaque
strings
and
have
that
go
through.
B
B
My
inclination
would
be
to
not
do
it
and
to
leave
it
undefined,
but,
like
whatever
decision
you
make
that
that
bubbles
up
to
the
grpc
spec
like
let's
say
we
decide
to
make
it
all
opaque
right,
not
to
model
any
of
this
stuff,
then
the
grpc
spec
is
just
a
map
string
string
that
says
these
are
vendor
defined,
strings
you're,
going
to
get
what
the
admin
put
in
there
and,
like
that's
the
end
of
the
documentation
right.
We
wouldn't
try
to
provide
examples
or
encourage
people
to
use
one
thing
or
another.
B
We
would
just
say
this
is
just
a
carbon
copy
of
that
parameters,
field
in
the
bucket
access
class
and
it
gets
passed
down
to
grant
access,
and
you
know
you
as
the
vendor
go
nuts
with
how
you
want
to
implement
it
and
because
cosy
either
has
to
be
opinionated
or
not.
And
I
feel
like
we're
in
this
gray
area,
where
we're
sort
of
suggesting
you
do
it
a
certain
way,
but
then
we're
not
actually
enforcing
it,
and
it.
A
A
B
Well,
yeah,
but
if
we
make
it
a
map
string
string,
then
we
would
change
the
docs
to
say
this
is
just
the
opaque
parameters
from
the
bucket
access
class,
and
that
would
be
the
end
of
it.
We'd
have
no
examples,
it
would
just
be
whatever
you
want
and
then,
similarly,
on
the
kubernetes
api
side,
the
controller
that
consumed
bucket
access
classes
would
enforce
no
special
semantics
on
those
fields.
It
would
just
copy
them
straight
in
without
looking
at
them.
B
If
they're
really
opaque
right,
because
that's
the
question
is:
if
they're
opaque,
you
don't
get
to
look
at
them,
you
don't
document
what
they
should
contain.
You
just
say
it's
an
opaque
string.
We're
copying
it
from
here
to
here
and
then
there's
other
fields
where
you
say
this
is
not
opaque.
This
has
meaning,
and
then
you
have
to
be
able
to
document
what
that
meaning
is,
and
I
like
the.
A
B
A
B
B
So
so
we
like
for
our
example,
we
had
to
create
an
empty
config
map
or
a
config
map
full
of
garbage
and
put
the
name
of
it
in
there,
even
though
we
were
just
going
to
ignore
it
and
like
that
kind
of
hurdle
is
going
to
leave
a
bad
taste
in
implementers
mouths
and
new
users
mouths,
because
they're
going
to
say
like.
Why
did
I
create
an
empty
config
map
to
do
this?
Like
I
just.
C
I
didn't
want
that.
I
just
wanted
the
default.
You
know
suggestion.
Why
don't
we
move
this
aside
for
cozy
wonder
text?
What
ben
said
before
is
we
could
have
the
the
policy,
the
policy
string,
so
you
want
inside
the
parameters
that
you
get
from
a
bucket
access
class
and
get
them
passed
into
the
the
driver.
B
B
Yeah
yeah,
I
mean
I'm
saying,
create
a
bucket
access
class
that
has
no
parameters
other
than
some
opaque
ones
that
we
don't
say
anything
about,
and
then,
if
vendors
end
up
putting
really
complex
strings
in
those
in
those
parameters
to
implement.
You
know
the
semantics
you're
talking
about
and
because,
because
users
are
demanding
it,
then
we
can
go
survey,
all
the
vendors
and
say
hey.
What
are
you
guys
doing
about
access
parameters
like?
B
B
Class
then
well,
because
you
know
you
might
want
to
have
like
a
read-only
access
class
and
a
read,
write
access
class
and
you
might.
B
It
anyways
right
now
it's
not
useful
so
right
right,
but
but
you
can
add
what
the
same
question
about
storage
classes
like.
Why
do
you
want
to
have
two
different
storage
classes
if
you're
going
to
get
a
volume
at
the
end
of
the
day?
The
answer
is
because
people
use
the
opaque
parameters
of
the
storage
classes
to
make
like
fast
storage
and
slow
storage
or
like
highly
reliable
storage
and
cheap
storage.
B
You
know
people
people
decide
what
menu
options
they
want
to
create
and
they
achieve
it
by
manipulating
the
the
opaque
parameters
after
reading
their
vendor
docs,
but
only
after
they've.
You
know
gotten
over
the
hurdle
of
creating
the
empty
one
and
getting
the
default
behavior
and
they're
happy
with
it
and
then
they're
getting
more
sophisticated
and
they
come
back
and
they're.
Like
oh
wait,
I
don't
want
all
my
volumes
to
be
the
same.
I
actually
want
different
kinds.
B
B
B
Yeah
so
yeah,
okay,
okay,
so
I
feel
like
we're
getting
to
a
better
place.
So
so
so
the
initial
version
is
really
simple
and
easy
to
understand
and
also
easy
to
use
and
implement.
So
vendors
trying
to
write
drivers
won't
be
scratching
their
heads
users
trying
it
for
the
first
time
won't
be
scratching
their
heads.
The
worst
possible
case
is
maybe
you
feel
like
this.
Isn't
I
don't
have
enough
control,
but
like
that's
a
good
problem
to
have
right
if
they're,
using
it
and
they're
complaining
about
not
having
enough
control,
is
better.
A
B
They're
not
using
it
absolutely.
A
A
Value
from
okay,
we
don't
have
time
how
about?
Let's
do
this
so
we'll
actually
go
ahead
and
make
the
update
for
this
and
hold
that
thought
until
thursday
for
the
return
value.
Or
is
it
a
really
quick
conversation?
I
think
I
think,
with
the
return
value
you're
asking.
Why
do
we
have
a
path
if
you're
only
going
to
bring
credentials
back
right,
basically
yeah?
It.
B
Was
well.
B
B
B
A
So,
like
those
are
okay,
okay,
so
this
yeah
there's
the
okay.
So
we
need
to
define
the
downward
api
actually
because
there's
this
yeah.
B
B
So
I
mean
whether
it's
right
or
not
is
a
separate
question,
but
like
at
least
you
know
with
certainty
what
fields
are
going
to
be
present
and
what
they're
going
to
be
named
and
where
they're
going
to
be
written
and
then
and
then
you
need
to
wire
it
all
the
way
through
to
this
thing,
so
that
when
the
driver
returns
the
various
fields
like
they're
in
some
structure,
that
can
be
so.
So
you
can't
like
me,
you
know,
put
things
in
the
wrong
name,
field
or
omit
fields
or
something
like
because.
A
B
B
Can
quibble
about
what
that
structure
looks
like
and
what
fields
are
supposed
to
be
internet,
but
I
I
think
that
there
has
to
be
a
a
spec
and
it's
gonna
be
protocol
specific
like
for.
If,
if
you
asked
for
s3,
you
know
that
you're
going
to
get
these
five
things
every
time,
no
matter
what?
Maybe
you
get
some
extra
stuff?
Maybe
you
know
maybe
there's
a
room
for
extensions,
and
although
I
don't
like
that,
I'd
rather
just
have
you
know
you
get.
A
These
five
things
and
nothing
else,
that's
fair
enough,
yeah
yeah.
So
so
you
know
the
plan
was
always
to
get
into
the
download
api
after
alpha,
but
I
don't
think
it
matters.
We
shouldn't
be
putting
ourselves
into
that
right.
Now
we
use
a
arbitrary
json
structure
and-
and
you
know,
we've
been
having
talks
about
actually
defining
the
api.
This
is
a
good
time
to
actually
start
doing
that.
So,
let's
start
with
the
first
change:
let's
remove
the
policy
actions
config
map,
like
you,
said
I
don't
think
it
adds
much
value.
A
B
Okay,
absolutely
yeah,
because
the
downward
api
is
what
matters
and
this
just
has
to
plug
into
it,
and
and
I'm
sure
there
will
be
fiery
conversations
about
what
that
downward
api.
But
it's
a
good
thing:
it's
it's!
The
most
important
thing
is
getting
that
right.
A
Yeah
yeah,
okay,
so
this
is
a
good
plan.
Let's
go,
let's
go
fix
the
you
know
we'll
go
fix
that
you
know
like.
I
encourage
all
of
you
to
make
pr
so
ben.
If
you
want
to
make
a
pr
get
started
with
this,
totally
encourage
it,
we
we
could
use
more
hands
on
the
project.
A
More
people
looking
at
it
and
coming
up
with
good
suggestions,
are
also
totally
welcome.
Just
like
what
we're
doing
right
now
so
yeah
someone
wants
to
take
it
up.
Someone
who
wants
to
counter
you
know
who
wants
to
take
a
much
more,
a
prominent
role
in
in
maintaining
the
cozy
repositories
and
the
projects.
A
I
think
you
know
we
need
to
do
a
little
bit
more
like
marketing
like
thing
where
you
know,
we
write
more
blogs,
we
talk
about
on
twitter
and
and
that
that'll
bring
quite
a
bit
of
people,
so
we
should
get
started
on
that
again.
We
were
thinking
we'll
do
it
once
alpha
hits
and
all
that,
but
I
I
you
know
we
can
get
started
with
some
of
them
even
before
us,
like.
Maybe
when
we
publishing
the
blog.
A
You
know
that
you
know
on
on
something
like
new
stack
or
kubernetes
or
io
can
wait
until
alpha,
but
like
putting
things
on
twitter
or
writing
about
it
in
your
own,
personal
blogs
need
not
wait,
yeah
yeah!
So,
let's,
let's
get
started
that
way
by
thursday
I'll
create
a
new
twitter
account
and
you
know
I'll
come
and
let
you
know
what
it
is,
and
I
encourage
all
of
you
to
follow
it
and
also
start
tweeting
with
some
particular
hashtag
we're
all
plugged
into
the
kubernetes
community.
A
So
when
we
tweet
the
kubernetes
community
is
going
to
look
at
it
and
then
you
know
slowly
grow
from
there.
We
can
even
add
some
hashtags
for,
like
clouds
or
aws
s3,
or
something
to
get
more
people
interested
in
this.
I
think
twitter
is
going
to
be
one
of
the
main
ways
in
which
we
get
more
people
interested.
A
Because
our
entire
community
is
there
like,
like
tim
hawking
to
everyone,
tim
hawkins,
was
tweeting
about
the
api
review,
while
he
was
doing
it.
Oh
awesome,
I
got
live
update
about
how
it
was
going
from
there
rather
than
like
directly
talking
him
now.
He
was
not
happy
about
the
format
about
how
much
detail
was
in
there,
and
I
don't
blame
him.
It's
okay.
A
I
mean
it
was
the
last
minute
and
it
I
don't
even
blame
us
because
again
we
got
the
review
done
on
the
last
day,
which
is
difficult
to
kind
of
get
it
right
so
anyways
so
anyway.
So
so
we'll
we'll
go
along
the
path
that
we
just
decided
on
and
thursday
we'll
focus
on
defining
a
downward
api
and
a
little
bit
of
twitter
stuff.