►
From YouTube: WG Multi-Tenancy Bi-Weekly Meeting for 20220208
Description
WG Multi-Tenancy Bi-Weekly Meeting for 20220208
A
I'm
here
to
record
now:
okay,
I
believe
we
are
recording
so
hi
everybody.
Welcome
to
the
february
8th
meeting
of
the
multi-tendency
working
group.
I
am
playing
the
part
of
t
of
tasha
today,
I'm
adrienne
and
I'll
be
driving
today.
So,
as
we've
been
discussing
before
we
hit
record
the
agenda
today
is
to
talk
about
adding
a
section
on
multi-tenancy
best
practices
and
projects
to
the
kubernetes
website.
There
is
an
issue
open,
it's
three
one,
four,
seven,
nine
and
we've
got
a
couple
of
people,
ranjith
and
jeremy.
A
B
Sure
yeah
happy
to
do
that
and
yeah
jeremy
thanks
for
reaching
out.
I
know
we
had
chatted
over
slack
and
I
had
you
know
kind
of
pointed
you
to
the
working
group.
So
thanks
for
reaching
out
and
following
up
on
that
yeah,
let
me
share,
I
think
adrian
you
might
have
to
give
me
permission
to
share
somehow.
B
All
right,
let
me
try
there,
we
go
that
works
yeah.
So
the
background
behind
this
is,
you
know
one
of
the
things
we
were
discussing.
I
think
it
was
late.
2021
is
you
know
so
we
had
within
this
working
group.
We've
had
a
few
projects
that
were
built,
some
of
them
have
graduated
and
you
know
kind
of
found
newer
homes
within
different
cigs.
B
So
the
question
was:
what
do
we
do
next
and
where
are
we
with
multi-tenancy
right
and
the
general
feeling
was
there's
still
a
lot
of
interest?
There's
still
a
lot
of
questions
around
multi-tenancy,
especially
for
new
new
users,
two
communities
and
there's
perhaps
you
know,
although
there's
there's
several
tools
now
available,
there's,
perhaps
a
lack
of
guidance
in
the
official
docs
on
multi-tenancy.
B
B
I
think
the
last
you
know,
output
like
documentation
type
output,
we've
had
as
a
group
was
the
the
paper
we
published
and
there
have
been
a
few
blog
posts
in
the
past
that
I
linked
in
here.
So
so
really.
This
was
just
to
kind
of
see
the
idea
and
get
feedback,
and
it
seems
like
the
docs
team
likes
the
idea.
They've
approved
it
for
triage.
B
So
now
the
it
sort
of
ball
is
back
in
our
code
to
start
work
on
this
to
propose
an
outline
fill
in
some
sections
and
decide
what
should
be
in
the
docs
and
what
should
not
right.
So
the
process
for
docs
is
just
like.
I
guess
it's
everything's,
driven
through
git.
We
would
do
a
proposal
when
we're
ready.
What
we've
found
is
that
it's
much
easier
to
collaborate
first
in
a
google
doc
and
get
you
know,
get
discussions
and
comments
and
feedback
there.
A
A
There's
lots
of
different
types
of
isolation,
there's
no
one
right
answer,
and
so
we're
trying
to
give
some
sort
of
guidance
that
is
general
enough,
but
also
useful,
rather
than
just
like.
Oh
understand
your
use
case
and
plan
accordingly.
So
yeah
I
like
the
idea
of
starting
at
google
docs.
Sorry,
I
haven't
done
that
myself,
like
I've
kind
of
wanted
to,
but
I've
got
a
bunch
of
other
things
going
on,
including
hnc
itself.
So
I'm
the
original
author
of
agency
in
the
maintainer
so
yeah,
so
maybe
jeremy
ryan.
C
C
First,
as
a
container
specialist
helping
folks
adopt,
eks
aws's
managed
kubernetes
service
and
helping
them
design
for
multi-tenancy,
where
that
was
warranted
and
also
helping
them
determine
whether
they
needed
hard
or
soft
multi-tenancy
or
the
extent
to
which
they
needed
to
isolate
tenants
and
oftentimes.
We
would
present
them
with
a
variety
of
different
options.
C
The
ranches
can
talk
about
his
work
with,
with
with
sas
organizations
like
isvs
who
are
developing
sas
solutions,
I'm
a
as
specialist
and
now
as
a
developer
advocate.
I
primarily
work
with
with
with
customers
who
have
multiple
groups
sharing
a
cluster,
so
they
they
don't
necessarily
need
the
the
hard
or
harder
tendency
that
a
sas
organization
might
and
so
we've
got.
You
know
a
couple
of
different
perspectives
on
the
line.
A
D
Yeah,
no,
absolutely
and-
and
you
know
I
work-
you
know.
First
of
all,
I
work
at
aws
in
this
team
called
database
sas
factory
so
where
yeah
so,
where
I
work
with
customers
or
you
know,
isps
other
building,
sas
applications
and
one
of
the
you
know.
First
thing
that
comes
up
is
okay.
How
do
we
build
good?
You
know
good
efficient,
multi-tenant
solutions
right
so,
especially
the
ones
that
are
building
on
top
of
are
using
containerized
workloads
or
have
containerized
workloads.
D
They
have
kubernetes
folks
that
know
kubernetes
right,
so
they
they
come
to
us
and
ask
us
okay.
How
do
we
build
good
multi-talent
solutions
and
we,
like
jeremy,
said
yeah,
so
we
talk
about
this
whole
notion
of
hard
multi-tenancy
and
soft
multi-tenancy
right
so
hard
being
you
provision,
you
know
isolated,
independent
clusters
right
for
your
tenants,
but
at
some
point
for
these
sas
customers
it
becomes
highly
cost
prohibitive
right,
so
they
they.
You
know
they
cannot
like.
D
You
know
we
could
use
open
source
solutions
as
well,
and
you
know
how
do
you,
how
do
you,
you
know,
use
or
take
a
single
eks
or
kubernetes
cluster
and
share
that
among
multiple
tenants
right
and
when
you
do
that?
What
are
the
different
considerations
that
you
have
to
make
so
that
their
workloads
are
isolated?
D
You
know,
there's
no,
like
one
tenant
shouldn't,
be
able
to
access
a
different
tenants
data
or
servers
a
lot
of
considerations
around
those
like.
How
do
you
use
things
like
network
policies,
network
plugins
to
secure
their
workloads
when
it
gets
to
when
it
gets
to
sharing
a
single
clusters
across
from
multiple
tenants,
so
I've?
D
A
Cool
that
sounds
awesome
because,
as
always
jim
has
heard
me
go
off
about
this
a
lot
about
like
getting
the
difference
between
sas,
multi-tenancy
and
and
and
team
multi-tenancy,
let's
say
or
devops
multi-tenancy
yeah.
That
sounds
really
cool.
So
in
that
case
I
think
the
is
the
next
step,
jim
just
to
start
the
dock
and
right.
A
I
think
that
you
might
have
some
input
here
as
well.
I
think
the
next
thing
is
to
start
the
dock
and
start
talking
about
what
we
want
to
do
and
then
maybe
reiterate
and
figure
out
like
where
exactly
it
lives
in
the
website
and
like
there's
a
chance,
it
needs
to
be
split
up
into
multiple
docs
or
something
like
that,
but
maybe
just
start
a
doc
and
say
like
this
is
what
we
want
to
say
because
we've
said
like
bits
of
it
in
our
blog
posts
over
the
past
two
years,
yep.
B
Yeah,
no,
that
that
sounds
like
a
good
next
step
so
happy
to.
I
can
start
a
doc
and
you
know
give
out
access
to
everybody
in
the
working
group,
and
that
way
you
know
the
first
step
would
be
if
we
draft
up
an
outline
and
at
least
kind
of
have
a
general
sense
of
what
we
want
here
now,
some
of
the
obvious
things
like
because
this
would
be
kubernetes
talks-
I
mean
here
we
focus
mostly
on
kubernetes
concepts.
What's
allowed,
I
think
there
are.
B
You
know
some
cncf
guidelines
on
how
to
reference
projects
both
cncf
projects,
as
well
as
third-party
projects.
We
can
add
a
section
where
people
can.
You
know
contribute
that
with
some
you
know,
disclaimers,
etc.
Things
like
that,
but
the
main
the
main
goal
here
is
to
say:
what
can
you
do
with
kubernetes
what's
possible?
What's
not,
and
I
think
then
give
some
guidelines
to
you
know
again
based
on
like
whether
it's
hard
or
soft
or
the
type
of
clusters
as
a
service
or
namespaces
as
a
service.
A
I
can
because
I
don't
think,
there's
a
ton
of
stuff
for
like
there's
quite
a
lot
of
stuff
now
for,
like
the
team,
multi-tenancy
yeah,
there's
not
a
fun
out
there
for
sas
multi-tenancy.
There
was
a
proposal
at
in
san
diego,
I
think
for
something
called
arc,
and
they
I
I
it's
it's
out
there,
it's
open
source,
but
I
think
I
I
have
a
very
hazy
understanding
of
sas
factory.
I
did
look
into
it
once
upon
a
time.
A
I
think
that
it's
kind
of
like
that,
but
there
aren't
a
lot
of
options
since
certainly
nothing
that
I
know
of
in
this
cncf
umbrella,
although
of
course
you
just
won
a
person
using
an
agency
for
that
too,
but
yeah
so
so
yeah.
I
think
that
it
would
be
fine
to
sort
of
reference
other
projects,
especially
if
it
doesn't
look
like
an
endorsement
we
could
just
say
like
would
be
great
if
we
could
get
at
least
two
examples
for
everything
like
loft.
We
don't
have
any
contributors
from
last
year.
A
C
Yeah
yeah
and
we've
we've
done
that
with
the
eks
best
practices
guide.
We
have
a
section
on
multi-tenancy
in
there
and
we
do
reference
solutions
from
third
parties
like
like
loft.
It's
not
meant
to
be
an
endorsement
yeah.
It's
really
meant
to
help
customers
who
have
requirements
that
can
be
met
by
those
solutions,
options,
yeah
options.
A
E
F
This
is
andrew,
so
in
the
document
are
we
going
to
talk
about
the
crd
level
kind
of
details
or
more
than
that
or
higher
than
that?
So
what
do
you
mean?
The
crd,
all
right?
Oh
god.
What
do
you
mean
by
that?
Okay?
So
so,
for
instance,
in
that
in
this
document,
are
we
going
to
describe
particular
crds,
because
so
so
we
are
not
so
so.
This
is
slightly
different
with
you
know.
Other
standard
documents
are
talking
about
building
apis
right.
F
A
A
Okay,
if
you're
in
this
category
go
look
at
virtual
clusters
or
you
know,
if
you're
in
this
direction
go
look
at
hnc,
go
look
at
satisfactory
as
like
something
like,
I
think,
that's
because
the
crds,
like
the
the
actual
api,
I
think,
is
too
low
level,
especially
jim.
I
think
we
said
this
was
going
to
go
into
the
concepts
area
right
the
website
yeah,
so
I
don't
think
you
usually
get
into
api
details.
There.
F
A
A
A
F
We
most
likely
trying
to
reflect
some
of
the
code
adding
more
ntn
tests,
and
this
is
for
virtual
cluster
and
for
caption
we
are
trying
to
make
sure
we
are
going
to
have
a
release.
I
mean
the
to
set
up
the
roadmap
stuff.
This
that's
action,
items
that
we
have
for
now
and
we
are
not
going
to
have
any
plantation
for
kubecon
eu,
but
maybe
we
are
going
to
yeah.
We
are
thinking
about
something
for.
F
It's
what
your
class
is
just
very
you
can't
you
can
call
it
as
a
very
specific
technology,
but
I
mean
from
this
from
the
solution
perspective
I
would
say:
caption,
I'm
not
going
to
go.
I'm
not
going
to
call
virtual
class
as
a
solution,
I'm
going
to
call
happiness,
a
solution,
but
technology
you
can
create
very
crosstalk
that
that
has
not
conflict.
In
my
opinion,
okay,.
A
F
B
Yes
or
no,
you
know
so
yeah
there
hasn't
been.
You
know
too
many
updates.
I
know
mac
who's
on
the
call
it
has
submitted
some
cleanup
and
other
enhancements
for
the
benchmarks.
I'm
curious
to
know
you
know
how
folks
are
using
if
and
how
folks
are
using
the
benchmarks
what
they
would
like
to
see.
I
think
there's
a
couple
of
issues
in
the
repo,
but
I
would
like
to
get
more
feedback
and
we
can
you
know,
plan
next
steps.
H
B
Yeah
so
the
test
previously
we
because
this
was
sort
of
a
mono
repo
across
several
projects.
So
we
were
not
at
doing
automated
benchmark
tests
for
every
commit,
or
things
like
that,
but
now
that
I
think
both
hnc
and
virtual
cluster
capian
have
moved
out
of
this
repo.
Perhaps
we
can
revisit
that
and
add
in
the
benchmark
tests
to
run
on
a
pr.
A
Configuring
all
that
stuff
was
a
giant
pain,
but
we
documented
how
we
did
it
on
agency.
So,
okay,
hopefully
you
can
just
go
to
the
bottom
of
the
agency
repo
and
it's
got
like
all
the
links
to
all
of
our
configs
and
that
might
help
you,
including
how
to
set
up
kind
on
the
pr
in
the
in
the
post-submit
system.
So
you
can
do
an
end-to-end
test
on
a
on
a
kind
cluster
which
is
really.
E
B
So
I
shared
shared
the
link
in
chat,
and
you
know
so.
This
is
there's
a
within
the
multi-tenancy
git
repo
there's
a
section
for
the
benchmark.
So
this
has
you
know,
I
think,
when
we
were
discussing
this,
we
had
come
up
with
two
two
levels
of
tests
and,
based
on
that
there's
you
know
a
series
of
about
14
plus
each
one
of
these
checks.
The
ones
which
are
not
linked
are
pending
implementation.
The
other
ones
have
been
completed.
B
B
A
Okay
and
in
hnc
land,
so
there's
actually
a
fair
amount
of
work
going
up
and
we've
also,
I
track
the
weekly
downloads
of
the
client.
I
don't
bother
to
track
the
weekly
downloads
of
the
manifest
for
people
to
install
things
on
their
clusters
because
I
feel,
like
people
might
just
be
reapplying
the
same,
manifest
to
the
same
cluster
often,
but
we've
hit
a
new
record
of
something
like
what's
that,
maybe
800
or
so
weekly
downloads
of
the
client.
A
So
lots
of
people
are
out
there
downloading
the
hierarchical,
namespace
client
so
that
they
can
work
with
them,
which
is
cool.
We
got
a
new
contributor
from
norway
telecom
and
we're
basically
continuing
our
maybe
march
is
the
wrong
term,
but
our
ample
towards
1.0,
like
people,
are
using
it
in
prod
now
and
so.
Basically,
0.9
was
supposed
to
be
the
last
pre
1.0
release.
A
We
basically
decided
to
add
basically
two
features:
one
of
them
is
label
propagation,
so
you
could
add
a
label
to
a
namespace
and
have
it
propagated
to
all
of
the
sub-name
spaces.
I
did
it
with
annotations,
and
so
that's
mainly
got
in
gone
in
there's
a
couple
of
usability
improvements
that
we
could
make.
But
I
don't
know
if
those
are
critical
for
1.0.
A
We
might
just
call
that
feature
beta
in
1.0
and
we
are
currently
deciding
whether
or
not
to
enable
leader
election
before
we
go
to
1.0
as
well,
because
it's
not
a
trivial
thing
to
enable
on
hnc
due
to
the
the
slightly
non-standard
way
that
it
works
internally
and
that's
about
it.
So
we've
got
some
new
contributors
working
on
that
kind
of
stuff.
We've
we're
seeing
good
adoption.
A
Red
hat
just
wrote
an
article
about
us
which
is
pretty
cool,
and
so
I'm
hoping
that
we
will
be
able
to
release
1.0
if
we
decide
to
get
leader
election
is
I'm
not
gonna?
I'm
not
gonna
predict
if
it'll
be
in
the
next
month.
If
we
don't
decide
to
do
leader
election,
probably
in
about
a
month
or
so
we'll
just
declare
1.0,
because
we
got
ricardi
using
it.
Norway
telecom,
looking
at
onboarding
at
least
one
other
that
I'm
not
sure
if
I'm
allowed
to
say,
but
they
they're
all
up
for
slack.
A
So
you
can
check
them
out
so
at
least
one
other
large
company
that
are
that
are
using
it
and
so
yeah.
That's
things
are
looking.
Things
are
kind
of
plugging
along
well
for
agency
right
now,
beyond
that,
I
don't
anticipate
there
being
a
lot
of
new
features.
Hmc
by
design
is
supposed
to
be
a
pretty
well
contained
piece
of
machinery,
and
so,
while
I
certainly
expect
us
to
add
features
from
time
to
time,
the
one
that
we
keep
on
getting
a
request
for
its
hierarchical
quota.
A
So
we
might
have
that
one.
But
beyond
that,
I'm
not
anticipating
a
lot
of
new
features.
Really
these
propagated
labels
and
annotations
were
the
last
one
that
we
got
a
lot
of
requests
for
beyond
quota,
so
quota
might
come
post
1.0,
but
but
up
until
then,
I
think
that
that
we
can
release
1.0
without
that.
So
that's
entry
for
agency.
B
A
It's
on
the
table,
it's
like
we've
got
something
for
it
in
gke
and
and
we
could
use
the
same
techniques
there's
nothing,
there's
no
magic
to
it.
The
the
fun
bit
of
magic
was
basically
discovering
that
we
could
hook
into
rather
than
watching
every
possible
resource,
that's
monitored
by
quota.
You
can
actually
just
monitor
the
quota
object
itself,
because
what
happens
is
to
actually
use
some
quota
kubernetes.
A
The
api
server
will
actually
try
to
modify
the
status
of
the
quota
object
itself
and,
if
that
fails,
it
will
actually
block
the
submission
of
the
object,
whether
it's
a
pod
or
or
a
crd
or
anything
else,
and
so
that's
the
trick
that
we
use
is
we
just
put
a
web
hook
on
the
quota,
object
and
blocked
updates
to
the
status
if
we
didn't
like
it.
So
that
means
that
there's
only
only
one
type
of
object
that
you
need
to
that.
You
need
to
watch
instead
of
all
of
them.
A
So
that's
the
trick
that
we
use,
and
so
I've
always
been
open
to
somebody
adding
it
to
hmc
using
the
same
kind
of
techniques
that
we
did.
But
I
decided,
but
I
don't
think
anybody
thinks
that
we
need
to
hold
up
1.0
for
that.
There's
only
people
ask
about
it
a
lot,
but
very
few
people
have
actually
labeled
it
as
a
blocker
to
adopting
it,
whereas
we're
getting
more
questions
for
things
like
is
it
highly
available?
A
Is
it
approved
for
production
like
it
with
the
current
feature
set?
I
think
the
answer
to
that
is
now
yes,
so
I
think
we
should
go
ahead
and
not
wait
for
another
major
feature
like
that
to
go
in,
especially
one
which
we
have
proven
can
actually
be
implemented
in
a
separate
controller.
It
doesn't
need
to
be
part
of
the
core
condition.
B
Okay,
that
makes
sense
all
right.
You
have
one
one
other
question
I
had,
and
I
think
we
briefly
talked
about
it
previously
was
with
pod
security
admission
coming
around
right
with,
I
guess,
which
allows
namespace
based
pod
security
levels
to
be
defined,
seems
like
there
will
be
a
greater
push
to
having
finer
grain
name
spaces
even
for
like
a
microservices
style
app
which
becomes
a
natural
fit
for
hnc
right.
A
Unfortunately,
I've
not
looked
into
that,
but
it
is
a
reasonable
point.
Maybe
you
and
I
can
sync
on
slack
honestly.
I
hope
I
I
wrapped
my
head
around
pod
security
policies
and
now
they're
gone
and
I
haven't
really
looked
into
the
new
one.
I
think
my
main
job
is
as
a
software
developer,
not
as
a
kubernetes
administrator.
So
I
don't
know
that
much
about
the
about
the
replacement
but
yeah.
Maybe
we
can
sync
later
and
talk
about
that.