►
From YouTube: 2018-12-11 Crossplane Community Meeting
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
Okay,
the
recording
is
started.
This
is
the
December
11th
2018
crossplane
community
meeting
the
first
meeting
of
the
project
here.
So
this
is
an
exciting
day
for
us.
This
is
a
not
the
normal
time
that
we'll
be
running.
This
meeting
normally
we'll
be
running
it
at
9
a.m.
every
other
Tuesday,
but
we
have
changed
it
to
8
a.m.
this
meeting.
A
Only
so
we're
not
conflicting
with
the
the
cube
con
keynotes
today,
all
right
and
there's
a
question
in
the
chat
from
Trevor
about
there
are
recordings
being
posted,
so
we
have,
they
will
be
uploaded
to
YouTube
and
we
have
a
specific
cross,
flane
channel
that
we'll
be
uploading
them
to
and
in
the
agenda
doc.
Here,
there's
a
link
for
the
recordings
of
past
meetings.
It'll
take
you
to
that
playlist!
It's
currently
empty,
since
we
haven't
had
any
of
the
the
meetings
yet,
but
we'll
start
uploading.
A
Those
after
every
meeting,
pretty
I
do
that
for
the
rook
project
committee
meeting
too
and
I
I'm
pretty
consistent
on
it,
so
they'd
normally
get
uploaded
the
day
of
the
meeting,
ok
cool!
So
let's,
let's
get
to
move
a
whole
bunch
of
windows.
Out
of
the
way
here
for
me
to
see
I,
don't
think
you
guys
see
them
on
your
side,
but
yeah.
Ok,
let's
go
ahead
and
get
started
on
the
agenda
here.
So
this
is
a
the
first
meeting
here.
So
I
wanted
to
welcome
everyone
to
do
the
project.
I'm.
A
Definitely
we're
all
very
excited
about
the
reception
so
far-
and
you
know
this
is
very
much
so
a
community
driven
project,
so
it
is
incredibly
important
to
us.
You
know
to
you,
know,
have
feature,
ideas
and
feedback,
and
you
know
decisions
about
project
direction,
all
that
stuff
to
be
very
much
driven
by
the
community
and
the
demand.
We
want
this
project
to
go
into
a
direction
which
will
serve
many
people.
Well,
so,
let's,
let's
talk
about
who's
on
on
the
call
here,
it's
do
a
little
bit
of
an
introduction.
A
B
C
A
A
E
A
B
A
Awesome,
are
you
what's
the
project,
so
you
guys
working
on
it.
Red
Hat
right
now,
we're.
A
A
A
One
thing
that
I
wanted
to
call
special
attention
to
is
that
at
11:40
this
morning
there
is
going
to
be
a
talk
from
Ilya,
who
is
the
third
maintainer
on
the
crossplane
project,
and
so
he's
going
to
be
giving
a
very
interesting
talk.
You
could
just
tell
that
from
the
title
itself
of
clusters
is
cattle
wrangling
clusters
not
just
nodes,
so
that'll,
be
at
11:40
and
it'll
have
a
nice
full
live
demo
of
crossplane
in
action?
That's
the!
A
A
A
So,
a
week
ago
today,
exactly
we
could
go
at
8:00
a.m.
last
Tuesday.
We
first
made
the
with
live
with
the
project
made
it
public
and
you
know,
showed
off
our
recent
hard
work
to
the
world
in
this.
So
that
was
the
v01
milestone,
which
was
you
could
really
think
of
it
as
a
proof
of
concept.
This
kind
of
laid
the
foundation
of
some
of
the
core
ideas
in
the
project.
A
In
kind
of
cots
that
groundwork
laid
with
some
of
the
you
know,
introductory
features
of
being
able
to,
you
know
enable
workload
portability
across
multiple
cloud
providers
of
Amazon
and
Google
and
Microsoft
Azure,
and
you
know,
schedule
workloads
and
their
resource
dependency
is
such
as
the
database
and
make
sure
that
it
does.
My
internet
connection
is
unstable,
so,
hopefully
I'm
not
cutting
in
or
out.
Nice
learn
good
Gary,
awesome.
A
Awesome,
yes,
and
then
you
know
laid
out
the
project
structure,
the
the
CI
pipeline,
the
release
pipelines,
you
know
all
the
user
documentation,
so
that
was
you
know
getting
that
project
as
a
proof
of
concept
out
to
the
world.
So
we're
already
started
on
the
next
milestone,
which
is
the
B
0.2
milestone,
and
this
the
focus
of
this
milestone
here
is
going
to
be
about.
You
know
what
taking
cross
plane
to
the
next
level
to
be
able
to
start
running
real-world
applications.
A
So
we're
really
excited
that
we
are
going
to
start
working
on
the
effort
and
the
support
that
it
would
take
to
run
gitlab
as
an
application
on
cross
plane.
You
know
get
lab,
has
a
number
of
dependencies
like
post,
crests
and
I
believe
Redis
as
well,
that
we're
gonna
be
adding
support
in,
and
you
know
more
robust
and
reliable
orchestration
for
more
complicated
applications
and
workloads
like
that.
A
B
B
B
E
A
So
in
the
investig--
one
milestone
that
was,
you
know
the
example
application
that
we,
a
stateful
application
that
we
implemented
is
working
and
it
was.
It
was
a
good
basis
to
start
with,
because
its
dependencies
are
somewhat
limited.
It
really
just
needs
a
my
sequel
database,
which
all
the
major
cloud
providers
you
know
have
their
own
managed
service,
my
sequel
instance.
So
it
was
a
good
stateful
application
to
get
started
on
as
a
nice
bite-sized
chunk
to
take
a
take
on
I.
A
A
A
That's
a
great
question:
I
think
that
you
know
I,
don't
know
a
whole
lot
about
WordPress
specifically,
but
you
know
that
gets.
It
does
that's
kind
of
an
interesting
question
because
that
starts
getting
into
some
more
of
the
you
know.
Interesting
features
and
real-world
scenarios
form
ie
why
you
might
want
to
be
using
multiple
cloud
providers
in
the
first
place
in
that
multi-site
facet
user.
You
were
just
talking
about
there.
That's
that
starts
getting
really
interesting.
E
Okay,
I
mean
I've
worked
with
WordPress
for
a
long
time,
just
not
not
in
a
very
complex
scenario.
Some
my
own
personal
websites,
just
a
business
site
and
a
personal
blog,
but
I
just
think.
Maybe
he's
kind
of
fleshing
out
some
of
those
scenarios
might
help
to
provide
context,
for
you
know
how
to
actually
run
production
workload.
E
A
I
think
that's
a
great
idea,
Trevor!
That's
that's
a
great
idea
if
you
have,
if
you
know,
if
you
have
some
more
specific
details
about
some
of
those
scenarios,
feel
free
to
open
an
issue
on
them.
So
we
can
kind
of
track
that
and
be
able
to.
You
know,
pull
that
into
the
milestone
or
drive
some
more
of
the
potential
like
the
early
design
work
too,
because
a
lot
of
that
stuff
sounds
like
that.
A
Would
that
would
involve
or
require
some
bit
more
thinking
and
design
work
to
kind
of
lay
that
foundation
for
what
are
the
what's
the
machinery
and
what
are
the
the
reusable
components
and
features
inside
of
crossplane?
That
would
be
need
to
be
built
to
start.
Enabling
features
like
that.
So
capturing
that
in
the
issues
list
would
be,
would
be
awesome
if
you
think
about
that
more
okay.
E
Cool
I
had
one
other
thing.
I
wanted
to
mention
as
well,
which
is
definitely
on
a
different
topic,
is
just
around
documentation,
so
comparing
and
contrasting
to
something
like
terraform,
so
somebody
who's
new
to
cross
the
line
might
come
in
and
look
at
it
and
be
like.
Oh,
are
you
guys
building
the
same
thing
as
terraform
and
why
should
I
use
cross
plane
instead
of
Tara
forms,
or
maybe
just
some,
comparing
contrast
between
those
tools
and
potentially
of
the
tools
in
the
ecosystem?
What
do
you
think
about
that.
A
Yeah,
that's
that's
a
fantastic
idea.
I
think
that's
a
really
important,
especially
for
new
projects,
to
kind
of
be
able
to
quickly.
It
serves
two
purposes
for
me.
One
is
that
you
know
to
kind
of
be
able
to
kind
of
share
some
of
the
concepts
with
the
community
that
may
be
familiar
to
them
to
kind
of
get
them
on
board.
A
It
is
so
because
it
kind
of
starts
talking
about
you
know
how
it's
similar
or
different
to
some
of
the
other
projects.
So
this
is,
you
know,
buried
as
an
appendix
in
the
you
know,
massive
design,
an
architecture,
vision
document,
but
I,
don't
think
that
it
would
be
a
bad
idea
at
all.
To
perhaps
add
that
too
you
know
and
to
our
frequently
asked
questions
section
of
the
main
documentation,
it's
so
it's
more
accessible
because
I'm,
not
sure
you
know
an
average
user
that
comes
to
the
site,
I'm,
not
sure
how
many
of
them
are.
A
As
you
know,
some
of
these
questions
are
very
important,
such
as,
what's
up
with
the
popsicle,
but
you
know
answering
those
other
questions
about
you
know
how
does
it
compare
to
terraform
or
you
know
the
AWS
service
operator,
and
things
like
that?
That
would
be.
That
would
be
good
addition,
I
think
Trevor.
If
you
want
to
capture
that
and
I
get
hub
issue
to
that,
be
more
than
welcome.
B
I
think
this
discussion
is,
we
should
probably
have
this
discussion
here,
but
it
some
of
them
might
spill
over
to
the
work
community
as
well.
For
this,
specifically,
he
says
I
know,
there's
a
full
request
that
Luke
started
for
adding
buckets
to
crossplane,
so
we're
likely
get
that
into
crossplane
first
and
then
figure
out
how
to
how
to
get
work
to
implement
that
interface.
B
A
That's
that's
a
great
point.
Bassam
I
think
you
know
the
the
focus
so
far
has
been
about.
You
know
how
you
know
entry
inside
of
the
crossplane
project.
How
do
you
manage
cloud
provider
resources?
But
there
is
absolutely
an
amazing
opportunity
there
to
manage.
You
know
to
do
a
better
job
or
more
complete
job
of
managing
on-premises
local
resources
as
well,
which
Brooke
does
a
fantastic
job
of
so
you
know
kind
of
defining
out
further.
A
You
know
what
that
interface
looks
like
in
how
you
know
other
projects
and
other
provisioners
can
can
integrate
in
with
crossplane
in
order
to
on
demand
provision
or
mayonnaise
those,
these
abstractions
of
resources
that
we've
defined
in
Cross
Plains,
such
as
buckets
or
databases
and
message
queues,
etc.
All
of
that
I
heard
talk
that
there
may
be
a
bit
of
a
live
demonstration
of
that
later
this
week
at
cube,
con
we'll
see
we'll
see
how
the
rest
of
this
week
goes.
A
Okay,
so
let's
let's
go
ahead:
I
think
we
kind
of
talked
about
the
the
mouse
Ted
this,
the
VCR.
That's
you
milestone
right
now
is
essentially
the
roadmap
that
we
just
talked
about.
So
you
know,
as
we
were
going
along
on
delivering
on
the
0.2.
You
know
real
world
application
theme.
It
will
keep
tracking
issues
here.
It's
yeah
we'll
keep
track
of
all
the
issues
here
in
the
0.2
milestone
in
the
0.2
project
board.
A
All
right
so
look
some
of
the
community
topics
here.
I,
it's
I've
got
way
too
many
windows
that
are
in
my
way
ghosts.
It
looks
like
Trevor
added
this
one
here
about
you
know
being
experienced
with
with
go,
laying
and
starting
with
documentation
and
Trevor,
though
what
I
would
definitely
say
to
that
is
that
you
know
that
there's
there's
a
lot
of
opportunity
to
ramp
up
on
this
project.
A
So
you
know
learning
a
little
bit
more
about
go
as
a
language
and
you're
working
on
smaller
pull,
requests
and
kind
of
expanding
your
experience.
There
is
something
that
no
we're
happy
to
support
and,
and
you
know
Florida
can
you
know
help
you
grow
on
that
as
well.
So
and
it's
very
community
driven
and
very
you
know
very
collaborative
community
around
here.
A
A
That
came
from
Luke
are
about
implementing
bucket
support.
You
know,
abstracting
what
a
bucket
is
and
being
able
to
have
a
portable
definition
that
you
know,
allows
you
to
provision
buckets
across
cloud
providers,
that's
one
of
the
pull
requests
and
then
he
also
adds
custom
columns
to
are
the
output
for
are
the
custom
resources
that
model
you
know
the
various
cloud
provider,
resources
and
infrastructure
and
abstractions
on
those.
A
So
when
you
do
a
cubic
control
kit,
instead
of
just
getting
the
name
in
the
age
which
is
the
default
for
custom
user
sources,
you'd
get
all
these
more
in.
In
Stritch,
columns
like
what
the
status
is.
If
it's
an
about
you
know,
if
it's
bound
to
another
resource,
if
it
hasn't,
he,
you
know
conditions
or
failures
and
such
though
that'll
be
a
great
improvement
to
the
user
experienced
at
Lucas
working
on.
A
Okay,
so
I
think
that's
all
the
agenda
items
that
we
had
for
this
very
first
meeting
of
the
crossplane
community,
so
I
will
open
the
floor
if
anybody
else
wants
to
bring
up
a
topic.
That's
not
in
the
agenda
document
that
we
can
definitely
talk
about
that
right
now.
If
you
want
to
otherwise
we
can
get
going
to
the
to
the
cube
con
keynotes
yeah.
E
I,
don't
know
if
you
guys
are
all
familiar
with
PowerShell,
but
it's
kind
of
Microsoft
programming,
language
that
replace
TV
scripts
for
any
kind
of
Windows
automation
and
it's.
It
was
open
source
and
cost
platforms
back
in
August
2016
and
one
of
the
one
of
the
cool
things
about
the
PowerShell
plumbing
is
that
it
actually
takes
care
of
a
lot
of
the
formatting
and
the
output
of
different
objects
that
are
emitted
to
the
command
line.
So
I
mean
it
certainly
doesn't
have
to
be
like
a
goal
of
ours.
E
A
So
that's
that's
something
that
I
would
need
to
process
a
little
bit
and
I
wonder
you
know
how
well
that
would
work
in
a
you
know:
a
really
portable
ecosystem,
that's
targeting
a
lot
of
different
environments
and
what
that
integration
story
would
look
like
if
it
would
be
something
that's
manageable
when
you're
bringing
in
a
lot
of
different
targets
and
providers
and
other
ecosystems.
So
I
have
to
think
more
about
that
Trevor.
But
that's
interesting
to
bring
up.
B
E
A
E
Golang
but
I
was
actually
thinking.
More
of
our
power
shows
more
of
kind
of
a
front-end
interface
for
console
interactions
right
so
for
any
kind
of
administrative
action,
so
they
think
about
instead
of
using
coop
CTL
to
do
like
soup
CTL
commands,
you
could
actually
use
a
PowerShell
interface,
it
emits
objects
and
you
can
tap
object
into
other
commands
and
things
like
that.
So,
rather
than
working
with
kind
of
a
sexy,
you
know
bash
console
you'd
actually
be
working
with
objects.
Inside
of
a
PowerShell
module
to
do
cross,
plane
management
operations.
A
Definite
thank
you
for
suggesting
that,
because
it's
that's
not
something
I
had
thought
of
myself.
You
know.
One
of
the
in
you
know
important
tenants
so
far
of
the
cross
plane
project
is
this
convergence
upon
the
kubernetes
api,
where
you
know
it's
a
you
know
the
declarative
management
style
of
the
objects
in
cross
plane
and
just
like
all
the
built-in
objects
of
kubernetes,
where
you
got
a
declare.
What's
what
you
want
the
objects
to
state
you
want
to
get
them
to,
but
not
necessarily
how
that
happens,
and
so
that
integration
is
very
tightly.
A
You
know,
coupled
and
supported
in
the
kubernetes
ecosystem
and
with
tools
like
cube,
control
and
I
would
really
have
to
think
about
how
you
know
power
show,
but
it
would
be
able
to
fit
in
that
effectively
because
that's
a
very
new
idea
for
me
that
would
require
some
processing.
On
my
on
my
end,
you.
A
Cool
I,
like
I,
like
your
all,
all
your
ideas,
Trevor
I,
definitely
appreciate
your
enthusiasm
and
motivation
that
you're
bringing
to
the
project.
That's
super
super
helpful,
cool
and
I,
see
I
see
what
you're
saying
in
the
chat
is
as
well
so
yeah.
That's.
If
there
was
some
more
details
about
that
would
is
definitely
interesting.
C
C
The
first
question
that
I
have
is
is
crossplane,
at
least
in
the
initial
releases.
Is
it
responsible
for
creating
manage
services
in
multiple
clouds,
meaning
either
say
if
I'm
a
developer?
I
would
like
to
create
a
particular
managed
service,
like
my
sequel,
in
in
the
cloud
provider
of
my
choice,
or
rather
is
it
going
to
be
like
I'll?
Have
my
sequel
database
where
I
want
couple
of
notes
to
be
created
in
Azure
and
one
node
or
three
to
other
nodes
be
created
in
AWS
or
some
other
problem,
because
that
actually
stops
the
managed
service?
A
So
I
believe,
then,
the
if
I
understand
your
question
correctly
that
it's
you
know
the
goal
there
is
to
use
those
managed
services
from
the
cloud
providers.
You
know
they
come
with
an
SLA.
They
are,
you
know
reliable.
They
have
their
feature-rich,
so
be
no
crossplane
in
a
you
know:
extensible,
affordable
and
extensible
way
of
modeling
those
cloud
provider
managed
services.
I
I
think
is.
Is
the
goal
here
to
be
able
to
consume
those
managed
services
in
an
abstract
and
portable
way
and
getting
all
the
benefits
of
those
managed
services?
C
A
Yeah,
that's
a
good
question.
I
mean
that
gets
to
you
know
when
you're
trying
to
you
know
manage
resources
that
span
across
clouds.
If
you
want
to,
you
know,
have
some
sort
of
connectivity
or
you
know,
backup/restore
or
a
replication,
or
something
like
that.
That's
spanning
across
clouds
and
the
you
know
the
having
this
cross
plane,
which
is
a
single
control
plane.
A
That's
spanning
all
of
those
things,
then
that's
when
you
can
get
the
interesting
automation
and
lot
smart
logic
and
the
controllers
they
could
be
managing
that
for
you,
but
on
an
individual
service
basis
of
you
know
what
the
details
are
of
inside
the
managed
service
of
you
know.
Aws
is
RDS
that
implements
my
sequel
for
you.
You
know
be
hands-off
from
that.
A
You
know
let
that
man
into
service
do
what
it
does
good
on
that
individual
scope,
but
when
it
spans
a
broader
scope
of
these
services
needing
to
talk
to
each
other
across
cloud
providers
under
cross
regions,
and
that's
where
the
management's
smarts
of
crossplane
will
really
start
coming
into
play
in
that
level.
I
think.
E
E
A
That's
that's
a
good
question.
I'm,
you
know,
there's
been
nothing,
that's
been
done
or
talked
about
really
in
crossplane
itself,
but
that
kind
of
gets
to
you
know
in
general,
when
you
are
running
a
kubernetes
cluster
or
a
control
plane,
that's
you
know
running
on
top
of
or
using
resources
of
that
kubernetes
cluster.
You
know
having
some
more
of
those
advanced
management
practices
in
place
like
using
the
sed
operator
to
backup
the
entity
state
and
replicate
that
somewhere.
Is
that
something
that's
important
to
do?
A
Address
if
Brooke
does
Trevor's
that
you
asked
I,
don't
necessarily
see
it
at
the
in
a
specific
topic
we
were
just
talking
about
of
you
know
best
practices
for
running
the
kubernetes
cluster
and
the
API
server
in
the
backing
at
CDs
state
I,
don't
necessarily
see
you
know
where
rook
fits
into
there
at
that
point.
A
Yet
beyond
you
know,
besides
what
the
already
the
upstream
kubernetes
best
practices
are
for
running
a
production
cluster
that
you
know
the
the
that
are
already
in
place
there
and
then
another
thing
is
that
you
know
it
could
cross
plane
as
it's
control.
Plane
can
run
anywhere.
The
Quran
DS
is
running,
so
you
could
already
be
using
a
managed
kubernetes
service,
as
your
is
your
foundation
for
the
control
plane
for
cross
plane,
which
may
already
have
you
know
an
SLA,
and
you
know
behind-the-scenes
management
to
backup
of
an
upgraded
prop.
A
You
know
and
all
that
sort
of
stuff
for
your
clusters
so
that
it's
already
hands-off
you
don't
have
to
worry
about
it
yourself.
So
you
don't
have
to
roll
your
own
kubernetes
cluster
to
being
able
to
be
running
across
plane.
You
could
use
just
reuse,
a
managed
service.
That
already
has
you
know
a
team
taking
care
of
that
for
you
I.
A
This
point
of
time,
not
for
a
single
think
of
as
a
single
spanned
instance.
No,
you
can
create.
You
know
two
different,
my
sequel,
databases
that
are
independent
and
or
in
any
cloud
you
want,
but
there's
not
yet
a
concept
of
being
able
to
say
hey
for
this.
You
know
database
resource
I
want
it
specifically
to
span
multiple
providers.
We
don't
have
that
concept
implemented
or
supported
right
now,.
F
F
You
know
either
the
kubernetes
level,
where
there's
dynamic,
provisioning
already
or
higher
up
say
it
looks
at
to
abstract
it
a
little
bit
across
different
object
providers
and
now,
in
my
view,
cross
plains,
even
the
layer
higher
than
that,
where
you're
concerned
with
workloads
in
SLA
s.
So
I
just
wondered
what
the
community
thought
is
on
the
architectural
place
for
buckets
vision.
A
Yeah
and
so
I'm,
not
sure
I
think
my
connection
was
cutting
out
a
little
bit,
so
I
missed
some
of
that,
but
I
think
pretty
sure.
I
got
the
overall
concept
from
from
what
you
were
saying
there
and
so
and
I
don't
know
if
you've
gotten
a
good
chance
to
look
at
yet
of
how
database
provisioning
is
done
in
crossplane
right
now.
A
But
you
know
that
kind
of
I
think
is
going
to
serve
as
a
really
good
model
for
in
general
how
resources
can
be
dynamically
provisioned
in
an
abstracted
way,
where
the
application
that
all
it
really
needs
is
a
bucket,
let's
say,
and
so
from
that's
gonna,
be
the
experience
from
the
application
developer.
But
then
behind
the
scenes
you
know
you
have
the
administrator,
who
defines
certain
classes
like
bucket
classes
of
you
know.
This
particular
class
will
be
provisioned
by
you
know
rook
or
SEF,
or
this
particular
class
here
will
be
provisioned
by
Amazon.
A
You
know
s3,
and
so
it's
a
very
similar
concept
to
what
you
see
with
upstream
kubernetes
dynamic
provisioning
of
volumes
where
you
have
a
storage
class
and
you
have
a
persistent
vol-plane.
Those
concepts
are
very
similar
here
and
we've
done
that
implemented,
that
for
databases
and
I
see
a
lot
of
crossover
there
of
extending
those
concepts
to
how
buckets
would
work
as
well.
So
I
see
you
know
Rick
and
Steph
as
being
a
provisioner
of
the
bucket
type
and
the
abstract
request.
You
know
a
resource
claim
from
an
application
developer.
A
D
D
Have
to
send
you
guys,
we
have
a
design
doc
that
we're
still
kind
of
touching
up
a
bit.
I
am
curious.
How
are
you
guys
representing
how
are
y'all
getting
the
data
for
the
buckets
into
pots,
because
that's
the
the
one
kind
of
pain
point
for
us,
where
we're
still
kind
of
figuring
out
like?
Should
we
use
a
config
map,
multiple
config
maps
package
it
in
a
secret?
What
are
you
all
doing?
Yeah.
A
What
right
now,
with
the
pattern
that
we've
established,
is
for
getting
you
know
connectivity
for
to
back
to
the
application
to
its
resource
that
it's
requested
is
in
secrets.
So
they're,
you
know
the
endpoint,
the
you
know
credentials
those
will
get
stored
into
a
secret
and
then
the
pod
can
reference
that
that
secret,
for
you
know
to
extract
out
their
credentials
that
it's
needs
that
secret
gets
placed.
You
know
applied
to
the
namespace
at
that
application.
B
D
A
D
One
other
question
I
had
this
is
something
haven't
really
figured
out
yet
and
that's
how
to
handle
bucket
policies.
So,
if
I
have
multiple
keys
in
one
namespace
and
Jains,
some
contrived
example:
I
have
like
a
web
sorted
out
front
end
pod.
That
I
only
want
to
have
read-only
access
to
a
bucket.
That's
in
my
namespace,
how
do
you
represent
the
the
binding
of
a
bucket
policy?
That
is
how
you
access
credentials
being
like
read-only
into
this
bucket.
B
That
that's
also
something
that
we're
doing
at
the
usage
level.
So
one
of
the
things
that
we're
looking
at
is
both
people
of
binding
policy.
That
tells
just
like
say
if
a
system
bombs,
where
you
can
say
this
thing
can
be
bound
as
read-only
a
read/write
or
you
know
all
those
things
and
then
on
the
consumption
side,
that
the
user
can
also
specify
the
kind
of
access
mode
they
want
to
the
resource.
So
it's
still
it's
still
fairly
early.
But
those
are
those
are
some
of
the
concepts
that
that
we're
kind
of
building
around
this.
D
B
Let's
collaborate
on
this
I
think,
let's
figure
out
where
it
falls
in
which
project
which
repo
all
our
stuff
and
then
maybe
get
a
design,
a
shared
design
documents
in
place
and
then
figure
out
how
to
go,
make
it
happen.
I
think
it's
a
cool
scenario.
By
the
way,
if
we
can
show
a
bucket
working
against
rook,
you
know
all
the
objects
towards
blood
and
rip,
and
also
working
against
cloud
providers,
object,
storage,
all
being
consumed
from
work
Lord
that
would
be
a
killer
demo.
Oh.
B
D
A
Already
cool,
so
that
sounds
like
a
good
place
to
go
ahead
and
wrap
up
the
first
meeting
here.
This
is
a
very
productive
inaugural
community
meeting.
So
thanks
to
everybody
who
was
able
to
join
today
and
we'll
do
this
again
in
two
weeks,
no
actually
I
think
two
weeks
from
now
is
Christmas
Day.
So
we're
probably
gonna
cancel
that
one
I
don't
think
there'd
be
too
many
people
around,
but
we
will
definitely
get
it
going
again
in
the
new
year
and
we'll
see
everybody
at
cube
con.
A
You
know
for
in
the
hallways
and
stuff
talk
to
us
and
that's,
let's
keep
working
together
sounds.