►
From YouTube: 20190730 Kubernetes Multi-tenancy Working Group
Description
Full agenda: https://docs.google.com/document/d/1fj3yzmeU2eU8ZNBCUJG97dk_wC7228-e_MmdcmTNrZY/edit#
Jim Bugwadia to present on Kyverno (kyverno.io): The specific Kyverno feature we are discussing is the ability to generate configurations when a namespace is created.
- https://github.com/nirmata/kyverno/
- https://docs.google.com/presentation/d/1CnBFvqJMxqYNdFj8mOc1JbE37_dCWP37Vklu5Wl5Tr4/edit?usp=sharing
Sanjeev Rampal - update on work streams
- Tenancy v2 CRD
- Tenant Controller doc: https://docs.google.com/document/d/1PkV7y_GHU_RfL2y8W-tLa98UnHuierkixXz-5uwKjMA/edit#heading=h.5vii875b7qm0
- Hierarchical Namespace: Adrian (Google) has some ideas to implement here and will present soon, waiting on final sign off to be able to talk about detailed design
- Virtual Clusters based approach: Similar to Rancher KV3, proposing analysis of KV3 vs virtual cluster
Call for super specific multi-tenancy use cases - add yours here!
Financial Services User Group: Security Profile request: we have two “best practices” profile docs in rough draft/incomplete form, contributions welcome:
- Single user: https://github.com/kubernetes-sigs/multi-tenancy/pull/28
- Multi-tenant cluster: https://github.com/kubernetes-sigs/multi-tenancy/blob/master/docs/profiles/profile-soft-multitenancy-s1.md
A
Okay,
hi
everybody
and
welcome
to
this
week's
multi-tenancy
working
group
meeting
it's
Tuesday
July
30th.
Today
we
have
a
pretty
packed
agenda.
Jim
is
going
to
present
on
chi
ver
know
and
he
his
team
has
been
working
on
a
feature
that
gives
you
the
ability
to
generate
configurations
when
a
namespace
is
created.
So
he's
gonna
talk
to
us
about
that
and
I
guess
get
some
feedback
he's
already
presented
it
to
the
policy
group
and
we'll
talk
more
about
the
tenancy
v2
CRD
work.
B
Right,
thank
you,
okay,
so
let
me
quickly
share
it's
also
you're
with
me
and
I'm,
on
audio
through
shootings
computers,
so
you're
with
me,
shootings,
ow
and
also
Shivdasani
the
two
of
the
contributors
on
Capano.
So
like
Tasha
I
mentioned
we
presented
at
the
policy
workgroup
last
week,
and
you
know
one
of
the
feedback
items
was
to
check
in
that.
You
know
what
the
work
going
on
on
multi-tenancy
because
of
some
of
the
features
and
things
whatever
talking
about.
B
So
just
you
know,
quick,
quick
introduction,
and
you
know,
there's
also
some
questions
on
the
message
forums
in
terms
of
the
relation
of
policies
to
multi-tenancy
etcetera.
So
at
least
we
can
share
our
kind
of
viewpoints
on
that
and
get
some
feedback,
but
just
to
start
with,
you
know
why
why
policies
at
all
right?
So
of
course
configuration
management
remains
a
vast
and
complex
topic
in
communities
and
anything
we
can
do
to
make
that
easier
for
operators
helps.
So
that
was
one
of
the
main
motivations
for
policy
management
and
Kivar,
know
and
I'll
talk
about.
B
There's
also
use
cases
for
updating
and
generating
configuration
rights
about
generating
entire
resources
or,
in
some
cases,
to
be
able
to
mutate
resources
and
change
things
as
they're
being
admitted
into
certain
namespaces
or
certain
clusters.
So
why
Kivar?
No
you
know,
and
how
does
it
compare
to
some
of
the
other
projects
out
there?
So
first
off,
we
did
not
want
to
invent
any
new
language.
I
mean
you're
sort
of
come
up
with
the
new.
B
You
know
full-fledged
general-purpose
type
of
policy
engine
right,
so
the
goal
here
was
to
make
it
easier
for
kubernetes
administrators
operators,
as
well
as
users
to
be
able
to
define
manage
policies
in
communities,
so
that
is
not
just
authoring
the
policies
and
writing
the
policies,
but
also
being
able
to
see
the
results,
apply
them
to
kubernetes
resources
in
a
very
flexible
manner,
etc.
Right
and
the
other
thing
we
wanted
to
do
from
the
beginning,
is
we
didn't
wanna,
you
know
kind
of
have
a
limited
set
of
types
we
want.
We
wanted.
B
So
what
giver
know
is
not,
and
we
don't
you
know,
we
wanted
to
make
sure
that
we're
not
trying
to
sort
of
take
this
in
a
direction
where
for
what
it's
not
intended
to
be.
So
it's
not
a
general
purpose
policy
engine
like
I
mentioned
where
some
of
the
other
projects
like
OPA
are
they're
not
trying
to
introduce
a
new
language.
So
the
idea
and
the
constructs
are
really
more
to
to
introduce
something
like
you
could
think
of
like
tools
like
JQ
or
even
customize.
To
some
extent
they
provide
some.
B
You
know,
like
some
value,
add
features,
but
without
completely
requiring
or
having
a
steep
learning
curve
for
community
soft
waiters
and
like
I
mentioned,
we
didn't
want
to
be
tied
to
a
particular
API
or
version
schema.
We
wanted
this
to
be
schema-less
from
from
the
beginning,
so
let's
take
a
look
at
what
Guevara
does
and
what
it
looks
like
you
know
in
action,
so
in
terms
of
the
high-level
view,
so
we
have
a
policy
engine
and
that
takes
resources
from
different
triggers
right
and,
of
course,
the
main
ones
being
the
mutating
validating
webhooks.
B
We
also
listen
to
there's
a
controller
which
listens
to
namespace
creation
and
I'll
talk
about
that
a
little
bit
more,
but
then,
as
things
flow
through
the
policy
engine,
the
outputs
are
validated
resources
and
these
would
be
annotated
and
in
terms
of
saying
that
policy
as
validated
or
mutated
those
resources,
there
would
be
events
that
would
flow
out
of
the
policy
engine.
So
these
go
into
resources,
as
well
as
the
policy
CR
DS
and
violations,
which
today
are
a
sub
resource
of
the
policy
CR
T,
but
could
be.
You
know,
a
full-fledged
resource.
B
That's
something
they're
trying
to
get
feedback
on
and
decide
on.
It's
really
at
a
high
level.
This
is
how
the
policy
engine
works,
but
then,
let's,
let's
take
a
look
quickly
at
what
a
policy
looks
like
in
kvarner
right.
So
the
basic
structure
is,
policies
consist
of
a
set
of
ordered
rules
and
rules
can
select
one
or
more
resources
and
each
rule
can
either
generate
mutate
or
validate
configuration
right
so
fairly,
simple
structure.
We
we
don't
have
in
the
rules
are
ordered,
so
they
are
applied
in
order.
B
But
of
course,
as
the
you
know,
bad
books
sort
of
are
also
sequence,
that
sequencing
would
apply
first
so
and
then
you
know
any
anything,
of
course
any
changes
that
the
policy
engine,
what
we
do
for
the
generate
portion
is
done
after
the
resources
are
created.
It
doesn't
apply
through
the
box
right,
so
that's
handled
slightly
differently,
but
the
structure,
as
you
can
see
in
you
know
the
text
and
the
ammo
it's
fairly
simple.
You
can
select
one
or
more.
B
The
resource
block
allows
you
to
select
based
on
types
based
on
wildcards
based
on
you
know,
also
namespaces,
and
then
once
you've,
selected
or
or
label
selectors
right.
So
it's
a
standard
label
selector,
once
you've
selected
a
resource
to
operate
on
the
structure
of
the
policy
depends
on
whether
you're
trying
to
do
and
something
like
a
mutate
or
a
validate,
or
you
know
if
you're
trying
to
generate
configurations
so
for
the
mutate.
B
You
know
the
does
two
two
flavors
one
is
using
adjacent
patch,
so
somewhat
difficult
to
write
this
path,
but
you
know
very
precise
and
what
it
can
do
so
that
that's,
you
know
always
available
and
then
the
flavor
it
seems
a
little
bit
simpler
to
use
and
maybe
more
popular
is
using
an
overlay
style,
much
like
customized
right
so
you're,
basically
just
declaring
it
the
intent
of
what
you
want.
Your
policy
to
do
using
yamo
and
you
are
then
able
to
you
know,
apply
that
either
an
immediate
or
validate
so.
C
B
So
it
doesn't
again
like
we
have
no
sort
of
the
type
of
client
we're
using.
Underneath
is
the
dynamic
client
and
we
haven't,
you
know
tied
it
to
any
fixed
set
of
resources
on
purpose,
of
course,
by
design
to
be
able
to
select
any
CRT
or
even
types
that
we're
not
aware
of
for
that
cluster
right.
Okay,.
B
B
If
you
we
have
something
called
anchors
where
the
din
at
this
overlay
within
the
yam
will
fragment,
if
you
specify
the
parentheses
on
the
key,
what
that
checks
is
basically
if
that
key
exists
or
it
validates,
and
then
it
will
select
the
rest
of
the
contents
right,
so
it
will
apply
the
rest
of
the
content.
There's
also
slightly
it's
like
very
on
that
for,
if
not
defined,
so,
if
a
key
doesn't
exist,
then
you
can
take
some
logic
or
apply
some
logic.
B
B
Similarly,
the
validator
is
also
extremely
simple.
With
you
know
the
couple
of
things
we
support
your
patterns
to
match
and
select.
So,
for
example,
this
is
showing
a
wild-card
pattern,
just
using
very
standard
again
sort
of
pattern,
matching
the
Reg
x-type
operators
and
then,
if
you
want
to
do
comparisons,
there's
you
know,
operators
that
would
apply.
Of
course,
four
equals
not
equals
greater
than
etc
so,
but
you
know
fairly
again
fairly
straightforward
for
somebody
who's
familiar
with
the
resource
constructs
to
write
these
policies
for
generate,
which
is
you
know
with
like
Tosh
I
mentioned.
B
We
are
also
one
of
the
comments
or
questions
that
came
up
in
the
in
the
policy
work.
Group
discussion
was
other
than
namespaces.
Would
it
be
interesting
to
support
other
create
triggers
and
that's
of
course,
very
possible?
We
just
want
to
understand
the
use
cases
a
little
bit
better
before
we
add
you
know.
That
is
a
feature.
B
So
just
to
kind
of
summarize
what
a
policy
looks
like
you
know,
so,
there's
validate
meet
a
generate,
the
valid
mediate
will
be
patches,
and/or,
the
overlay
style
with
a
few
kind
of
decorations
for
conditional
logic
and
the
validate
also
like
will
support
the
same
conditionals
and
in
addition
to
that
wildcards
and
operators,
the
generate
can
operate
on
inline
data
or
can
clone.
Basically,
you
can
copy
from
an
existing
namespace
and
existing
resources.
So
the
idea
there
would
be
you
set
up.
B
So
some
more
advanced
flows
and
we're
kind
of
thinking
about
these
and
again
would
love
to
get
feedback
and
thoughts
and
yeah
I
mean
it
is
possible
to
generate
configs,
and
then
you
know
the
mutate
policies
would
apply
to
them,
of
course,
as
they
go
through
the
admission
controller.
So
what
you
would
like
to
see
if
there's
use
cases
for
that?
If
that
means
to
be
formalized
more
also,
it
is
possible
to
generate
policies
for
certain
namespaces.
B
If
that's
interesting,
right
and
there
to
you
again,
would
like
to
know
what
what
exactly
the
use
cases
would
be
so
discussion
we
had
with
the
policy
working
group
which
is
interesting
right.
So
we're
not.
You
know
the
first
ones
to
write
a
policy
engine
and
we
probably
won't
be
the
last
right,
so
there
will
be
other
and
there's
need
for
policies
in
different
languages
as
well,
so
seems
like
there's
enough
common
constructs
that
any
such
policy
engine
but
require
and
would
be
interesting
to
consider.
B
You
know,
can
some
of
this
all
of
the
kubernetes
specific
machinery
and
the
outputs,
the
inputs
and
outputs.
Is
there
interest
and
sort
of
value
in
standardizing
this
right
so
and
then
allowing
policy
engines
to
be
written
or
plugged
in
as
required?
So
that's
something
you
know
again
we'll
explore
with
other
groups
as
well,
but
would
like
to
hear
your
feedback
on
that
and
just
quickly
covering
our
roadmap.
So
we're
not
GA
yet
we're
not.
B
We
haven't
reached
100,
but
one
of
the
main
features
which
I
think
would
also
be
of
interest
to
some
of
your
use
cases
as
supporting
queering
of
in
cluster
data
right.
So
existing
configurations
we're
also
looking
at
you
know,
performance
and
optimization.
So
we
need
to
give
some
benchmarking
profiling
and
tuning
there.
I
talked
about
the
other
generate
triggers
we're
kind
of
thinking
about
what
else
can
be
used,
and
then
you
know,
another
interesting
question
is
as
we're
generating
config.
Is
there
a
need
for?
Is
it
pretty
much
static
config?
B
Is
there
a
need
for
some
parameters
or
templating
type
of
mechanisms
to
be
supported
right?
So
that's
also
a
question
which
we
have
you
know
we're
open
to
feedback
and
inputs
there
so
and
really
kind
of
coming
back
to
policies
and
multi-tenancy
right
is
the
interesting
thing
here
is
if
you're
looking.
B
It's
really
that's.
That's
all
I
had
in
terms
of
the
presentation,
there's
a
lot
more
examples
and
it's
extremely
simple
to
apply
and
use
in
your
local
or
any
cluster.
So
do
you
try
it
out,
give
us
the
feedback,
but
let
me
stop
here
and
see
what
the
five-seven
feedback
and,
if
you
have
any
other
questions,
hey.
E
B
So,
just
to
kind
of
recap:
I
touched
on
some
of
the
points
to
the
presentation,
but
quickly.
To
recap:
you
know
it's
our
use
of
dynamic
types
of
you're,
not
it's
not
kind
of
going
for
a
specific
set
of
types
that
we
support
and
gatekeeper
as
we
currently
from
what
we
saw.
It's
fixed
it
in
terms
of
the
resources
it
supports.
C
C
It
does
look
like
it's
easier
to
get
started.
I
just
said
to
interns
that,
when
working
on
gatekeeper-
and
it
is
tricky
to
get
started
on
right
now-
it's
very
powerful,
but
it's
it.
If
they're
all
you're
trying
to
do
is
set
it
overlay.
I
can
see
that
being
complicated.
We
were
able
to
adapt
it
to
generic
structures,
though
okay.
F
C
G
G
B
Yes,
certainly
again,
you
know
are
I,
think,
there's
huge
benefits
to
standardizing
the
inputs
and
outputs
and
sort
of
allowing
some
flexibility
in
terms
of
its
reg
or
other
languages
like
overlay
style
or
even
you
know
known
languages,
to
be
used
to
describe
or
to
write
policies.
So
yeah
I
would
love
to
explore
that
further.
Let
me
know
if
you
know
if
there
are
like
you
mentioned
some
contacts
on
the
gatekeeper
project
happy
to
reach
out
and
explore.
G
My
kind
of
tenants,
I'm,
using
a
helmet
or
for
tenant
essentially
to
stand
up
the
resources
for
them
and
it's
more
than
just
a
role
binding
and
a
couple
other
things.
It's
a
an
ingress
controller
and
and
some
other
like
software
II
things
but
I
stamp
out.
So
there's
kind
of
a
templating
aspect
to
it,
but
there's
also
a
lifecycle
management
aspect
to
it.
So
over
the
life
cycle
of
a
namespace
I
might
need
to
be
able
to
upgrade
the
were
involved
for
that
tenant
on
their
behalf.
G
F
Yeah
there's
a
couple
of
other
aspects
to
the
life
cycle
as
well
so
like
if
you
were
applying
policy
at
deploy
time
and
the
policies
change
over
time.
So
there's
an
audit
function
where
you
can
sort
of
know
that
things
that
what
things
that
have
been
deployed
previously
would
now
be
outside
of
policy
and
there's
also
from
a
cluster
manager
or
even
a
tenant.
F
B
No
great
great
points,
so
we
do
have
some
mechanisms
to
address
both
of
those
so
for
existing
resources.
So
let's
say
you
introduce
a
new
policy.
One
thing
you
can
do
with
Carano
is
you
can
first
introduce
it
in
just
audit
mode,
so
it
will
only
it
will
scan
through
the
existing
matching
resources
and
report.
It
also
reports
on
the
mutate
rules.
It
will
report
anything
that
doesn't
match
so
this
way
it
basically
creates
a
set
of
violations
that
you
can
talk
to
the
resource
owners
etc
and
try
to
get
addressed.
B
You
can
then,
of
course,
flip
it
to
enforce
mode,
but
it
does
not
impact
existing.
We
don't
change
existing
running
resources,
but
at
that
point
it
will
start
blocking
our
resources
that
do
not
match
that
are
coming
in
the
other
aspect
of
you
know
being
able
to
try
this
offline.
So
we
do
have
a
CLI
which
we
are
working
on.
Where
you
can,
without
applying
a
policy
you
can
you
can
the
CLI
can
take
a
cluster.
It
needs
a
doctor,
an
API
controller,
just
sir,
like
good
config
or
some
some
mechanism.
B
F
Up
so
their
only
other
question
I
had
is
the
ability
to
look
up
so
having
different
tenants
may
have
different
stuff
like
different
that
the
generate?
Will
the
policies
in
the
done,
particularly
the
generate,
may
actually
look
quite
different
for
different
tenants
and
being
able
to
look
that
up
for
something
else
or
or
even
just
in
a
policy
like
I'm
making
this
up?
B
Yeah
would
love
to
understand
that,
and
you
know,
maybe,
if
there's
a
documented
use
case,
because
I
think
that
would
be
very
interesting
for
us
to
explore
is
like
what
it's
like
you
mentioned.
There
are
two
possibilities:
right,
one
is
looking
up
data
which
is
configured
in
the
cluster
elsewhere
or
you
know.
The
other
option
is,
of
course,
matching
something
in
the
incoming
resource
itself
so
between
and
we
can
do
the
latter.
B
F
A
G
So
one
more
general
thought
there's
a
danger
of
coming
up
with
a
domain-specific
language
and
then
more
pouring
more
and
more
features
into
it
and
growing
a
general
language
into
it.
Over
time
and
like
you
see
it
with
like
chef
and
puppet
and
things
where
they
started
off
with
something
that
looks
like
a
mole
and-
and
they
eventually
give
up
and
just
embed
all
of
Ruby.
G
A
B
Yeah
yeah
totally
totally
agree
with
that
right
and
that's
something.
We've
discussed
a
few
times
too,
because
there
were
some
features
where
we
were
ourselves
tempted
to
say
well,
can
we
just
write
some
JavaScript
or
can
be
you
know
some
other
Python
or
some
other
language
and
for
the
processing
part
of
it
right,
but
so
far
you
have
it
just.
You
know
yeah
mole
again
with
a
few
kind
of
additional
syntax.
It
seems
to
cover
most
of
the
use
cases,
but
you're
absolutely
right.
B
A
E
Yeah
this
is
a
I
I.
Don't
have
anything
prepared,
I
just
want
to
give
a
two-minute
update
here
so
really
the
main
threads
of
activity
that
we
are
focusing
on.
For,
let's
say
the
next
three
months
is
number
one
having
the
updated
version
of
the
tenant
controller
CRT,
which
we
are
sometimes
calling
is
the
v2
version.
E
The
logical
flow
of
that
CRT
is
very
similar
to
the
prior
one,
but
the
key
things
are
a.
It
will
be
implemented
differently
using
cubed
root,
for
example,
and
Sophie
from
Alibaba
has
kind
of
started
off
the
scaffolding.
For
that
so
he's
gonna
kind
of
put
some
structure
there
and
then
eventually
other
folks
will
also
be
able
to
add
contribute
code
or
reviews
and
so
on.
So
that's
on
the
tenant
controller
implementation.
Of
course,
there's
continued
to
be
design
discussions
which
are
being
captured
in
the
tenant
controller
dock,
so
I
think.
E
Last
time
there
was
some
discussion
about
changing
the
way
the
namespace,
templating
works
and
so
on.
But
the
overall
philosophy
of
the
tenant
controller
is
still
pretty
much
what
we
had
in
a
v1
but
we'll
have
more
meetings
in
which
we'll
go
into
more
details
of
the
tenant
controller,
know
workflows.
E
Other
areas,
so
Adrienne
from
Google
has
been
initiating
some
activity
around
hierarchical
namespaces.
If
we
had
some
thoughts
on
this
in
the
past,
but
Adrienne
feels
like
it's
got
some
similar,
similar
ideas
to
implement
that.
So
we
look
forward
to
hearing
more
from
that
on
that
from
him
in
the
next
next
couple
of
meetings.
I'm.
C
E
So
these
are
sort
of
the
main
activities
of
work.
Some
folks
are
kind
of
taking
a
little
bit
of
a
lead,
but
ready
these
are
again
open
to
all
of
us.
So
we
should
have
more
updates
on
that
in
the
coming,
so
I
just
wanted
to
kind
of
give
a
brief
update
to
those
who
may
not
be
familiar
as
to
where
are
the
areas
of
focus
and
and
and
what's
kind
of
happening
on
some
of
these
main
threads.
So
that's
all
I
have
for
now
we'll
have
more
on
these
incoming
meetings.
A
back.you,
Tasha
cool.
A
C
I
only
joined
the
group
two
weeks
ago,
old
meeting
notes
looked
at
some
videos
from
from
past
conferences,
just
to
get
a
like
a
sense
of
really
concrete
stories
that
users
have
been
trying
to
go
through
with
with
multi-tenancy.
What
kind
of
problems
are
they
running
into?
Is
it
problems
with
managing
the
complexity
of
configuration?
C
Is
it
problems
with
security,
workload,
ISIL
and
stuff
like
that,
because
there's
a
whole
wide
range
of
things
that
people
want
so
rather
than
trying
to
generalize
I
was
really
trying
to
get
as
specific
as
possible
associate
each
story
with
the
name
of
a
customer
or
a
user,
and
and
maybe
a
very
rough
categorization
between
sort
of
DevOps
teams
on
one
side
and
sort
of
assassins
on
another
side.
Those
seem
to
be
the
two
main
kinds
of
tenants.
C
So
I
started
a
doc
last
two
at
the
last
meeting,
I
just
dumped
it
into
the
end
of
the
tenants.
Here
you
be
doc
and
I've
just
got
taken
that
out
put
it
into
it.
You
doc
and
I've
added
a
link
to
the
meeting
notes
and
I'll
also
add
that
to
the
slack
and
so
my
request
to
everybody
who
is
on
the
call
is,
if
you
have
an
interesting
use
case
with
regards
to
tenancy
that
you
don't
already
see
there
on
the
dock
I.
Can
you
just
add
it?
You
just
make
it
as
concrete.
C
As
you
can
say,
we've
got
five
groups
of
about
10
people
to
each
or
something
like
that.
They
each
use
two
namespaces
as
much
detail
as
you
feel
comfortable
sharing
or
if
you
see
somebody
else
that
does
something
very
similar
to
you.
You
can
just
add
something.
It's
a
say:
yeah
be.
This
is
also
the
kind
of
problem
that
I
have
that
would
be
solved
so
again,
I'll
send
that
out
on
the
slack
Channel
after
this
meeting,
and
yet
this
is
just
a
request
for
everybody
to
to
chime
in
and
add
what
they
can.
A
And
so
we
do
have
rough
drafts
of
both
of
those
in
our
repo
and
I
would
like
to
encourage
everyone
to
take
a
look
and
kind
of
give
your
feedback.
I
do
have
some
feedback
I
need
to
incorporate
into
the
single
tenant
profile,
but
both
profiles
are
definitely
up
for
review.
What
both
of
them
are
incomplete,
so
I
wanted
to
encourage
everyone
to
take
a
look.
A
What
will
be
cool
is
once
we
have
agreement
upon
best
practices
for
both
single
and
multi
tenant
clusters,
then
we
can
start
taking
this
to
other
working
groups
and
sakes
and
getting
their
feedback
on
it
and
then
trying
to
as
a
community
agree
that
if
you
configure
your
cluster
in
this
way,
then
we
agree
that
this
is
I
secure.
You
know
secure
cluster
using
just
kubernetes
as
it
is
today
without
needing
to
without
things
like
going
in
and
rebuilding
the
API
or
anything.
A
So
once
we
have
that,
then
we
can
start
talking
about
things
like
building.
Crd
is
an
automation
that
would
then
you
could
then
install
on
a
cluster
and
see.
Is
my
cluster
currently
configured
to
be
secure,
and
it
also
opens
up
opportunities
for
us
to
do
things
like
work
with
the
conformance
team
to
add
a
conformance
suite
that
would
be
for
a
secure
cluster
on
both
single
and
multi
tenant,
so
yeah,
that's
that's
up
for
grabs
links
are
in
our
agenda,
doc,
which
you
can
always
get
to.
A
I
I
sort
of
know
wise
question
retention.
It's
Daniel
I,
just
it's
my
first
time
meeting
adjourned
would
be
the
best
way
to
ramp
up
on
the
subject
which
I'm
very
interested
in
instead
of
mega
connection
of
material
that
Jim
presented
about
policies
to
other
nodes.
What
sort
of
diagram
that
you
recommend
yeah.
A
A
I
A
Yeah
yeah
I
got
you,
so
some
of
that
is
some
of
the
CDs
that
we
have
been
talking
about
is
the
idea
of
having
a
namespace,
C
or
D
and
a
tenancy
CRD,
and
so
how
would
you
automate
the
creation
of
these
objects,
as
you
are?
Creating
them,
and
so
policy
becomes
a
very
useful
thing
to
be
able
to
attach
to
namespaces
as
you're,
creating
them
in
order
to
configure
them
to
be
multi-tenant.
E
I
A
E
I
also
want
a
second,
yes
yeah,
sorry,
so
it
I
want
a
second
Adrienne's
call
for
continuing
to
have
more
use
cases.
In
particular,
one
key
point
that
I
I
I
feel
like
we
still
need
a
little
bit
more
consensus
on
is
some
fundamental
assumptions
we
are
making
in
the
current
tenant
controller
designs,
for
example,
is
it
vital
for
a
tenant
to
include
multiple
namespaces?
E
That
is
a
key
factor
that
I
would
like
to
have
us
agree
on,
because
that
influences
a
lot
of
the
the
implementations
of
all
of
these
things
right.
If
a
tenant
is
always
one
namespace,
that's
a
whole
different
thing
than
it
can,
and
that
has
multiple
namespaces.
So
just
a
second
Adrienne's
call
for
use
cases.
If,
in
particular,
you
could
mention
your
need
for
tenancy,
a
tenant
took
our
multiple
name
spaces
as
well
as
a
few
other
topics.