►
From YouTube: 20190716 Multi-tenancy Working Group Meeting
Description
Working meeting to begin the design of the Tenancy CRD v2.
B
Okay,
my
name
is
Adrian
I
work
at
Google
and
as
I
think.
A
lot
of
you
know
yeast
was
having
is
stepping
away
from
this
work
because
he
is
moving
to
another
team
and
I've
been
talking
to
him
and
David.
Often
hunger
about
stepping
in
so
I'll,
be
looking
at
doing
some
work
in
this
area
over
the
next
couple
of
months
and
just
starting
to
figure
out
what
I
want
to
work
on.
B
C
D
Hey
I'm
Chris
Gordon,
just
really
this
is
my
first
call
as
well:
you're,
more
lurking
and
just
trying
to
absorb
and
learn
at
my
company
Acquia
we're
cloud
based
and
also
starting
to
move
into
the
realm
of
eks
on
Amazon.
So
just
trying
to
more
about
card
multi-tenancy
in
general.
How
to
secure
that
so
hanging
out
here,
cool.
E
No,
not
really
I
just
started
a
new
project
board
that
we
can
add
tasks
to
I
know
people
were
asking
in
the
kubernetes
slack
channel.
If
we
could,
you
know
as
a
result
of
this
meeting
like
add
some
tasks
there,
that
people
can
pick
up
and
run
with
between
meetings,
so
I
think
that's
a
great
place
to
do
it.
If
you
need
any
help
with
that
I
can
you
know,
let
me
know,
but
yeah
I
think
we're
good
to
go.
Also.
E
A
A
And
so
yeah,
so
I
think
I
think
we'll
just
want
to
kind
of
dump
down
to
a
brain
dome
of
things
that
people
liked
and
didn't
like
with
v2
our
v1
and
just
kind
of
a
discussion
and
kind
of
started,
breaking
up
some
tasks
and
then
I,
guess,
Tasha
and
I
can
go
in
and
add
those
to
github
later
and
then
people
can
start
choosing
our
sign-in
to
themselves
is.
B
A
I
think
it
may
be
wanted
really
POC
and
I
think
that
I
mean
if
I
mean
there's
nothing
to
say.
We
can't
reuse
a
lot
of
e1
I.
Think
part
of
the
the
push
to
v2
was
also
because
EC
was
stuck
in
a
way.
We
didn't
have
someone
else
who
you
know
wrote
all
the
code
around,
so
that
was
I,
think
part
of
it
as
well
and
then
I
know
tom
is
I,
think
you
he's
been
working
on.
A
A
B
B
With
these,
we
briefly
one
is
that
it's,
it
seems
quite
monolithic
and
I
think
that
there
are
people
like
there's
some
discussions
here
about
like
10
in
verses,
10
and
namespace,
but
I
think
I'd
even
go,
maybe
I
stuff
further
than
that,
and
when
I
look
at
10
in
the
in
space,
I
asked
this
question
on
the
slack
Channel
last
night,
which
was
there
are
lots
of.
It
seems
like
the
the
purpose
of
having
a
tenant
namespaces
to
have
a
way
to
set
up
a
namespace
pre-populated
with
a
bunch
of
objects.
B
Typically,
policy
objects,
but
there's
a
bunch
of
people
out
there
who
are
already
trying
to
do
this
in
different
ways.
It
doesn't
seem
like
it's
necessarily
a
concept:
that's
tied
to
tenancy
and
so
I'm
wondering
is
there
some
kind
of
other
project
for
templating
or
Auto
populating
names
faces
or
sets
of
objects?
Even
like,
in
the
extreme
version,
it
could
be
like
a
mini
version
of
helm
or
something
like
that.
B
Is
there
something
else
that
we
could
make
use
of
instead
of
building
it
ourselves
and
so
make
this
a
composable
solution
on
top
of
other
standards
or
help
drive
those
if
they
don't
exist.
That's
one
question:
the
other
question
I
had
was
that
it
seems
like
we're:
we're
not
just
defining
a
bunch
of
features,
we're
defining
a
new
concept
in
the
kubernetes
ecosystem,
which
is
called
tenant
and
I
was
I'm
a
little
bit
wary
of
defining
you
whole
new
concepts
like
that
and
I
was
wondering
what
happened.
B
Yes,
we
had
this
as
a
proposal
somewhere
as
well,
which
is
hierarchical
namespaces,
and
he
thought
that
that
was
infeasible,
but
I
kind
of
like
the
again
I
wanted
to
explore
that,
with
with
the
controller
kind
of
implementation
of
basically
allowing
different
namespaces
to
point
to
each
other
as
parents
and
automatically
copying
objects
through
that.
This
is
kind
of
based
on
on
a
Google
specific
product
called
Anthes.
Config
management,
I,
don't
know
if
anyone's
looked
into
it,
but
it's
a
similar
kind
of
idea.
B
Where
you,
you
set
up
a
hierarchy
of
namespaces
and
then
objects,
the
card
back
optics
get
copied,
and
so
that
avoids
adding
this
new
top-level
concept
called
tenant
because
you're
still
just
based
on
namespaces,
it's
more
adding
a
feature
to
an
existing
primitive.
So
there's
sort
of
kind
of
the
two
ideas
I
wanted
to
explore.
Yeah.
A
And
so
that
that
second
thing
that
you
were
discussing
with
the
kind
of
the
hard
phone
namespaces
it
kind
of
it
seems
like
the
federation.
V2
stuff
is
doing
something
similar
to
that,
but
mostly
focused
across
cluster
yeah.
A
A
My
so
my
understanding,
I
have
I
mean
I
read
the
initial
proposal.
I
haven't
really
checked
back
in
a
couple
of
months,
but
it's
it
to
my.
My
takeaway
was
that
you
could
have
kind
of
a
master
or
a
driver
cluster
that
you
could
have
one
or
more
or
all
namespaces
synced
across
multiple
clusters,
so
you
could
set
our
back
and
all
that
and
they
would
kind
of
propagate.
Now
that
was
that's
my
understanding
of
what
they
were
shooting
for.
G
B
Both
cases
things
are
being
copied
around,
but
yeah
they're
they're
certainly
related,
and
it
might
be
worth
keeping
an
eye
on
it.
But
that's
another
I
should
say
that's
another
good
reason
to
maybe
stick
to
an
established
constructs
like
namespaces
as
opposed
and
be
careful
about
adding
a
new
concept
called
tenon
because,
for
example,
cubes
or
Federation
already
works
based
off
of
namespaces.
We
wouldn't
want
to
have
to
go
back
and
try
to
read
jig
it
to
work
with
tenancy
as
well.
B
A
Yeah
I
think
the
big
issue
that
we've
kind
of
discussed
in
the
past
is
you
know
this.
You
know
it's.
It's
changing
some
core
things
with
cookies
right
now,
so
hierarchical
namespace
is
in
general
right.
So
we've
talked
to
some
of
the
API
machine.
You
know
they're
other
folks
in
cig
architecture,
about
this,
and
in
a
lot
of
it
is,
is
more
so
a
question
of
whether
or
not
the
the
work
is
worth
the
reward
I'm
for
some
of
this
yeah.
B
A
So
I
mean
the
the
the
issue
with
that,
though,
then
is
right
handling
our
back
between
the
hierarchical
namespaces.
You
have
to
basically
implicitly
implement
barback
yourself
right.
B
I,
don't
believe
that
that's
the
case,
so
that's
why
the
the
method
would
be
to
copy
the
are
back
objects.
I
would
be
the
job
of
of
the
controller.
The
hierarchical
controller
is
that
you
would
have
it
would
have
lists
and
certain
kinds
of
objects
that
get
copied
from
parents
to
children.
So
examples
might
be
our
back
optics
quota
objects.
B
Secrets
would
be
another
useful
one,
and
so
it's
if
one
of
those
objects
appeared
in
a
parent
namespace,
it
would
automatically
be
copied
to
the
child,
which
would
of
course
have
the
the
in
the
case
of
our
back
would
have.
The
effect
of
anybody
who
has
any
permissions
in
a
parent
namespace
would
automatically
get
those
permissions
in
the
child
as
well
as
soon
as
the
object
is
synced.
A
Okay
and
so
then
the
any
other
common
I
guess
gotcha
for
a
lot
of
these
things
with
from
a
tenant
perspective
and
not
so
much
for
this.
But
you
know
cluster
roles
and
cholesterol
by
needs
to,
or
are
kind
of
tied
to
in,
like
names
facing
right
so
and
there's
it's
always
you
can
get
all
or
you
can
get
none
and
that's
that's
what
your
choices
but
I
guess,
but
more
specifically
right.
So
you
know
you
generally
have
to
specify.
A
So
you
can't
really
copy
down
a
cluster
or
a
bun.
You
basically
have
to
edit
it
to
add
namespaces
if
you're
gonna
edit
to
the
parent
and
then
you
know
copy
it
down.
So
then
it
yeah
so
I
totally
get
it,
and
this
is
yes,
I
think
something
that
we've
kind
of
gone
done
internally
as
well,
but
it
after
a
while
it
does
seem
like
you're
reimplemented,
a
lot
of
things
that
should
already
exist.
Anyone
else
have
a
feedback
or
anything
I
guess
along
those
lines
that
they
want
to
discuss.
C
So
this
is
Chris
I.
Think
one
of
the
things
I've
struggled
with
as
I've
tried
and
trying
to
go
to
speed
with
the
background
of
the
multi-tenancy
effort,
is
sort
of
what
are
the
guarantees
we're
trying
to
provide
people
right,
I
mean
there's
a
certain
upper
bound
to
what
Barry's
container
technologies
can
provide
and
different
ones,
give
you
different
potential
isolation
models,
but
I'm
curious.
A
So
I
mean
I,
guess
I
think
it.
That's
that's
been
a
from
like
a
historical
perspective,
a
huge
issue
with
this
working
group
is
because
everyone
is
here
for
a
different
reason.
So
I'm
selfishly
here
because
we're
we're
bare
metal
and
we
have
to
be
bare
metal
and
we
can't
really
split
up
multiple
kubernetes
clusters.
Without
you
know
charging
our
customers,
you
know
an
extra,
you
know
a
couple
hundred
thousand
dollars.
So
for
us
it's
it's
more.
So
you
know
improving
our
product
and
so
giving
a
you
know.
A
B
H
It's
like
one
of
the
crux
of
the
problems,
especially
since
CRD
API
is
iterating
so
quickly,
and
you
have
things
like
conversion
webhooks
now
that
need
to
be
shared
by
multiple
versions
and
so
now
which
controller
or
which
API
server
and
now,
services
that
you
have
to
create
a
proxy
to
connect
to
the
correct.
These
are
all
critical
issues
with
that,
so
they
ate
kindly
solution
at
the
namespace
level.
You
really
amazing,
but,
as
you
mentioned
before,
all
the
issues
with
API.
H
I
A
A
I
A
I
see
I'm
not
aware
of
any
I,
don't
know
if
that
falls
in
the
purview
of
our
work.
Working
group
or
not,
but
I
I
mean
I
talked
to
some
of
the
API
machinery,
people
at
Barcelona
lot
about
our
working
group
and
what
we're
trying
to
accomplish-
and
they
didn't
seem
to
be
a
whole
lot
of
of
current
work.
They've
discussed
it
and
they
talked
about
it
and
it's
a
future
thing,
but
I
don't
think
it's
a
priority.
I
guess
is
my
understanding.
I
Yeah
I
kind
of
agree
that
it's
it's
kind
of
at
a
scope
of
the
project.
The
the
work
group,
but
it's
also
beneficial
to
the
work
group-
is
that
something
like
we
can
report
to
the
sister
work
groups
that
hey.
We
need
these
things
or
we
would
benefit
from
these
things
so
that
they
can
prioritize
them.
I.
B
A
And
that's
that's
been
a
lot
of
the
kind
of
the
mindset
from
a
lot
of
the
people.
I've
talked
to
especially
an
API
machinery,
of
it's
a
lot
of
really
deep
changes
to
handle
some
of
this
stuff
and
then
just
not
convinced
that
it's
worth
the
reward,
because
you
know
the
use
cases
for
for
them,
don't
meet
it.
So
yeah
I
think
we
just
need
to
make
the
use
case
or
chip
in
and
opens
and
PRS
and
kind
of
start
working
towards
that
or.
B
A
B
Training
just
a
related
comment
like
as
I've,
been
trying
to
get
up
to
speed
on
this
I
I
have
some
idea
of
some
of
the
multi-tenancy
use
cases.
There
is
a
doc
that
we've
been
connecting
with
the
critical
user
journeys
in
these
cases,
but
they're
to
me
they
were
all
pretty
abstract.
They
didn't
have
a
lot
of
well.
This
cost,
like
this
organization,
wants
this.
B
That
I
find
has
been
missing
from
the
docs
that
I've
been
reading,
and
so
they
get
a
few
really
specific
ones.
I've
actually
started
my
own
just
working
doc
and
all
of
things
that
I've
been
able
to
find
from
people
from
past
recordings
of
these
meetings
or
from
talks
at
at
cubic
on,
like
the
the
collide,
talk
and
stuff
like
that,
and
it's
something
I'm
feeling
to
share
that.
But
would
that
be
interesting
to
anybody
else?
For
the
most
people.
B
A
B
A
B
A
Yeah
anyway,
so,
yes,
I,
think
yeah
we
could
put
those
there
of
what
use
cases
we
want
sorry
I
lost
money
and
what
what
people
I
guess
are
hoping
to
get
out
of
this
and
I
guess:
I
assume
part
of
the
v-2
just
design
discussions,
people
jump
in
here,
I've
kind
of
looked
at
and
seen
in
the
v1
Docs
and
the
other
two
an
asset
or
the
demo
and
stuff
that
you
seen
since
you've
have
done.
A
Sanjeev
did
a
few
of
them
at
barcelona
that
are
out
on
youtube
as
well
that
I
might
be
helpful
to
look
at
so
I
guess
from
here
that's
kind
of
what
we're
trying
to
discuss
up.
What
are
the
next
steps
you
want
to
take
with
me?
What
didn't
we
like
with
v1-
and
you
know?
How
can
we
start
doing
this
without
you
know,
starting
those
kind
of
core
changes
to
allow?
For
you
know,
namespaced.
A
A
F
F
F
So
having
this
cluster
scoped
creation
was
was
ideal,
I
think
there'll
be
some
other
use
cases
for
that,
maybe
again
they
have
a
storage
on
a
PV
that
they
want
to
be
able
to
leverage.
So
they
can
make
a
TV
with
their
NFS
storage
kind
of
like
Specht
up
there,
and
then
they
can
consume
that,
but
I
try
to
think
about
the
right
way
to
capture
requests
for
what
happens
in
each
namespace.
F
What
happens
at
the
tenant
level
and
I
think
those
are
the
two
challenges
about
usability
both
from
the
tenant
perspective
and
the
cluster
admin
perspective
about
what's
allowed
in
each
of
those
cases
and
for
the
most
part
the
namespace
scope
objects
are
kind
of
irrelevant.
They
don't
really
have
an
implication
on
the
long
term
on
the
overall
cluster,
but
how
those
cluster
scoped
objects,
get
created
and
modified
I
think
will
be
the
responsibility
of
the
cluster
I'd
been
doing
that
and
I
don't
know.
F
If
the
right
way
is
these
request
objects
that
go
in
there
I'm,
not
a
huge
fan
of
the
request.
Objects
that
need
to
be
request.
Object
in
the
design
dock
for
yeah
yeah
Brian
has
one
of
those
tabs
the
second
tab.
There
was
this
idea
of
an
Eames
namespace
request
that
would
then
get
approved
by
a
cluster
admin.
F
I
F
So
the
way
I
was
doing
is
with
role
bindings
sort
of
an
admission
webhook
to
allow
or
not
allow
a
certain
person
to
create
a
tenant,
namespace
or
not
based
on
their
membership
of
the
group
specified
inside
of
kubernetes.
Now,
that's
not
done
yet,
but
that's
kind
of
the
branch
I'm
working
on
a
repo.
That's.
F
I
B
A
So
yeah,
so
that's
and
that's
kind
of
another
I
guess
good
point
to
bring
up
is
we've
we've
kind
of
not
you
know
we
haven't.
We
haven't
put
a
hard
line
that
we
have
to
use
communities
native
things
that
we've
kind
of
said
that
you
can.
You
can
implement
a
part
of
this
I
guess
working
group
to
is.
This
is
how
you
can
implement
a
tenant
yourself.
We
can
provide
some
series,
but
then
we
say
you
need
to.
A
And
so
because
I
mean
we
don't
want
to
say
you
have
to
use
OPA
or
you
have
to
use
this
because
then
that
doesn't
really
help
anyone
if
they
can't
use
that,
for
whatever
reason
so
and
that's
I
guess
another
kind
of
issue
with
the
working
group
in
general
is
it's
it's
a
very
broad
saying
that
we're
trying
to
just
solve
here
so
so
yeah.
So
people
have
ideas
around
that.
A
You
know
key-keeper
specifically
and
what
it
can
help
do
and
what,
where
it
would
be
beneficial
to
use
it
there
or
you
know,
just
regular
old
are
back.
You
know
what
we're
you
know,
the
bandages
pros
and
cons,
etc
and
because
I
mean
I
think
for
v2.
We
want
to
get
much
more
closer
to
a
an
actual.
You
know
usable
the
solution.
A
A
B
F
F
A
I
know
that's
just,
but
I
mean
it
at
the
same
time,
if
we
can
I
mean
if
we
can
leave
the
are
back
constructs
to
our
back
and
just
facilitate
the
templating
and
copying
down.
That
adrian
is
mentioning
they
can
give
this
kind
of
what
we
need
without
having
to
do
a
lot
of
real
implementation.
I
would
think
yeah.
B
A
B
Yeah
I
guess
the
only
thing
as
I
said
at
the
beginning
I,
would
you
want
to
be
a
little
bit
wary
about
building
in
a
templating
solution
into
the
tenant
operator
or
tenant
controller?
Whatever
you
want,
we
want
to
call
it
if
we
can
make
use
of
something
else.
That
would
be
awesome
or
you
can
read
it
ourselves,
like
I,
think
one
one
outcome
of
this
might
be
hey.
We
write
three
separate
controllers
and
install
these
together
and
that's
our
recommended
flow.
But
if
you
want
to
just
use
one
of
them,
that's
fine
too.
A
B
A
B
A
I
We
could
have
some
control
over
name
space,
where
name
space
actually
had
the
concept
of
a
tenant.
Then
we
could
reuse
the
tent
the
name
space
object,
but
we
really
don't.
We
need
to
generate
namespaces
with
stuff
like
Tennant
name,
slash
the
namespace
name,
that
the
user
chose
so
having
a
separate
object
that
we
can
do
our
back
with
and
and
manage
by
itself.
I
think
is
gonna
make
a
lot
easier.
Yeah.
A
I
Both
to
register
a
tenant
namespace,
you
need
some
place
to
register
that
object.
If
there
was
a
namespace
for
the
tenant,
that
would
give
a
logical
place
to
put
our
back
rules
on
it
and
to
have
those
those
namespace
tenant
named.
Space
objects
exist
and
rather
than
being
cluster
wide,
they
could
be
pertinent.
A
So
so,
basically
you,
you
know
the
chicken
an
egg
right,
seeing
you
to
namespace,
and
then
you
deploy
your
tenancy
Rd
and
then
from
there
in
that
tenant,
namespace
and
then,
in
that
same
to
that
namespace
or
that
namespace
with
a
tenant.
You
create
your
tenant
named
Stacy
or
die's
that
generate
sub
namespaces
that
are
are
created
and
then
inherit
from
the
parent.
Correct
yeah,
especially.
I
So
so
like
I,
the
cluster
at
admin
would
create
a
tenant
for
user
Joe
or
tenant
Joe,
and
it
would
go
create
a
namespace
for
that
that
tenant,
where
they
could
register
as
many
tenant
named
space
objects
as
they
wanted.
And
then,
if
each
of
those
would
go
launch
a
namespace
particular
to
that
request.
How.
B
Just
I
guess
what
I'm
saying
is
so
I've
got
a
tenant
called
division
like
the
division,
a
and
then
inside
division,
a
I,
create
you
know:
Group
1
group,
1
and
group
2
and
then
inside
Group,
1
and
group
2
I,
try
team
one
and
Team
two.
If
I'm
in
admin
on
division,
a
do
I
have
those
same
privileges
and
all
of
those
other
names
faces
that
I
created.
A
So
they
kind
of
have
our
back
for
everything
and
they
they're
the
ones
that
can
create
cluster
wide
term
resources
etc
and
there's
a
tenant
admin
and
they
are
the
people
that
created
or
have
been
given
access
to
to
administrate
to
the
tenant,
and
so
they
can
create
new
tenant
namespaces
and
they
can
adjust
the
are
back
for
that
tenant,
etc,
etc.
And
then
the
tenant
users
and
the
tenant
users
exist
within
a
10
inch,
either
one
or
more
named
faces,
but
they
they
don't
have
any
ability
to
I
guess,
alter
the
tenant
left.
B
A
A
I
think
that
makes
I
mean
that's
kind
of
a
general
goal.
Right
is
we
want,
you
know
a
lot,
so
one
of
the
biggest
use
case
that
we
hear
is
really
just
for
a
lot
of
people
want
from
a
deaf
perspective.
Is
they
want
to
have
developers
want
to
deploy?
You
know
a
either
a
subset
or
all
of
the
type
of
production,
but
they
don't
want
to
be
tied
to
one
name
space,
because
in
production
they
run
in
multiple
namespaces,
and
so
that's
kind
of
what
the
concept
of
we've
been
going
with
is.
J
A
J
B
A
J
A
J
A
A
That's
yeah:
that's
it's
kind
of
out
of
our
purview,
basically,
so
that
the
persona
that
we
have
right
is
that
that
would
be
a
cluster
admin
tasks
because
they
have
the
ability
to
create
cluster
wide
resources
and
and
so
yeah.
That's
so
so
nothing
that
we're
creating.
For
me,
you
can
be
any
resemblance
of
like
a
hard
multi
tendency
with
the
Coke
and
Pepsi,
because
there
still
needs
to
be
a
single
admin
of
the
cluster.
That
is,
you
know,
facilitating
that
and
yeah.
You
can't
have
two
different.
A
A
B
Like
if
this,
if
the
work
we're
doing
here
were
to
succeed,
like
my
wildest
dreams,
you
would
get
so
many
people
using
this
stuff
for
tenants
for
multi-tenancy
that
who
are
not
even
beginning
to
use
it
now
that
it
would
generate
that
demand
to
take
other
things
that
are
currently
cluster
scoped
and
move
them
to
be
namespace.
Scoped
yeah.
A
J
About
things
like
CNI
level,
segregation
right
we've
been
playing
with
having
calico
have
different
cools,
in
example,
and
locate
the
poles,
the
different
names
places
of
the
pen
and
a
gets
allocated
from
pool
X
and
10
and
B
from
home,
Y
and
so
forth.
Is
that
even
in
threat
to
anybody
else
or
you
guys,
don't
care
about
that.
A
A
The
answer
to
your
question
is,
we
would
say
if
you
need
this
type
of
network
segregation
or
if
that's
something
that
you
use
case
here
are
some
examples
or
this
is
how
you
would
recommend
configuring
it,
but
we're
not
really
we
don't
want
to
advocate
or
dictate
a
very
strict.
This
is
what
about
tenon
is,
and
you
have
to
do
this,
because,
if
you
don't
fit
into
that,
then
you
walk
away
and
we
can't
improve
so,
but.
B
J
G
J
B
I
think
that's
the
most
important
thing
that
we're
doing
here
like
over
and
above
any
one
feature,
is
we're
defining
this
new
concept
of
tenant
or
in
in
my
ideal
world,
I
suppose
an
extension
of
namespaces
which
can
use
to
implement
a
tenant.
Because
once
you
have
that
concept,
then
you
can
hang
as
many
different
features
off
of
it
as
you
want
like
pre-populated,
namespaces
or
or
some
kind
of
like
tenant,
wide
resource
quota
that
spans
more
than
one
namespace.
A
Yeah
and
so
one
of
the
things
that
I've
I've
advocated
for
and
not
a
lot
of
people
agree
with
me,
but
I
think
I
think
of
a
tenant
more
so
as
if
you
just
think
of
like
a
POSIX
folder,
it's
nothing
more
than
kind
of
a
contract
that
you
can
put
permissions
around
and
then
the
namespaces
are
the
files
within
it.
That's
to
me
the
ideal
and
then
we
can
add
stuff
to
it.
A
Ok,
so
I
mean
we
have
about
you,
know
five
or
so
minutes
left.
We
haven't
really
come
up.
We
come
up
with
a
few
tests
to
look
at,
but
nothing
that
should
get
started.
Ten.
You
know
in
from
implementation
perspective,
do
we
want
to
kind
of
just
recap
it
does
anyone
have
specific
things
that
they
want
to
start
kids
working
on,
I
know
aging,
you
probably
you
were
gonna,
look
at
EC's
code
and
see
what
we
can.
A
Yeah
I
think
we
want
to
nail
down
in
design
and
and
kind
of
so
we
need
to
kind
of
see
what
b1
we
want
to
carry
over
and
and
what
from
b2
will
want
to
change
and
I
guess
really
just
gonna
make
any
sort
of
progress,
even
if
it's
just
creating
some
some
issues
for
teamwork,
that's
required
and
we
have
I
mean
we
have
a.
We
can
we
have
a
good
jumping-off
point
from
v1,
so
I
don't
think
we
need
a
whole
lot
from
the
neighborhood
is.
J
A
So
tenant
namespace
was
not
a
part
of
the
one
that
was
one
of
the
kind
of
suggestions
that
we
had
and
a
more
than
a
few
people
have
kind
of
brought
up
this
as
well
I'm,
so
Ted
a
namespace
is
kind
of
a
new
concept,
the
tenant,
C
or
D,
because
it
doesn't
a
namespace-
has
a
lot
of
stuff
zoomed
into
it
to
to
kind
of
control
the
entirety
of
the
tenant.
So
we're
definitely
gonna
need
some
changes
within
the
namespace.
A
So
some
of
the
design
work
that's
needed
is
to
see
what
fits
where
and
in
how
that
will
work
and
then
start
defining
the
the
controllers
for
both
of
those
here
at
ease,
and
then
you
know
the
I
think
was
Kate
Fox
they
had
mentioned.
You
know
a
parent
namespace
where
these
c
or
DS
are
deployed
and
kind
of
controlled
from
Ann
Arbor
perspective
Accenture.
Well,.
B
F
B
A
F
F
H
F
I
think
this
goes
to
the
extensibility
that
you
guys
are
talking
about.
That's
an
example
where
maybe
the
tenant
resource
quotas,
an
additional
operator
I,
think
it'd
be
great
to
have
some
sort
of
logging
switch
in
your
tenant
so
that
you
could
specify
a
sport
index
that
you
need
to
do.
But
you
need
to
send
logs
to
it.
F
F
A
Okay,
so
couple
of
minutes
left,
we
have
some
tasks.
We
need
to
lock
down
and
design
so
I.
Think
after
this
you
know,
keep
adding
to
this
and
we'll
kind
of
clean
it
up
and
make
it
into
an
actual
proposal
and
then
we'll
start
creating
some
github
tasks
to
start
knocking
this
down
and
we'll
open
it
up
for
the
for
people
to
request.
Just
note
that
if
you
do
want
to
take
the
mines
and
github
tasks,
you'll
have
to
open
a
PR
to
join
the
organization.
A
A
And
yeah
I
mean
I
could
post
a
link
to
that
as
well,
but
yeah
anything
else
that
people
want
to
discuss
before
we
go.
We
have
a
minute
left,
I.
Think
we've
only
we've
just
discussed
a
lot
and
we
have
a
decent
idea
of
what
we
want.
It's
just
we
don't
know
suspected.