►
From YouTube: Kubernetes Federation WG sync 20180205
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
B
Communicates
that
the
result
of
that
decision,
the
annotation
indicating
placement,
for
example,
so
I
think,
would
be
helpful
to
like
to
set
it
and
make
sure
like
what
would
it
ideal
cause
the
implementation
for
a
federation?
Look
like?
Is
it
just
placement?
Is
there
something
else
that
make
sense?
At
least
it's
a
starting
point?
B
C
I
mean
I
guess.
My
comment
was
specifically
around
placement
that
I
left
on
the
dock,
but
obviously
things
like
authorization
come
into
play,
both
authorization
at
the
Federation
level,
as
well
as
like
propagation
or
whatever.
You
want
to
say,
Federation
of
like
authorization
and
the
underlying
clusters,
but
I
feel
like
those
are.
Those
are
maybe
picked
big
topics
and
we
don't
want
to
necessarily
kind
of
tied
them
all
off
at
once,
unless
the
nice
folks
feel
strongly
about
them.
D
Kind
of
mixed
on
that
I
must
be
honest.
I
think
that
this
what's
the
right
word,
authorization
authentication
issue
in
the
context
of
controllers
in
general,
acting
on
behalf
of
some
party,
keeps
rearing
its
head
and
keeps
and
D
railing
conversations,
and
so
I
guess
we
we
can
punt
it
for
now,
but
we're
gonna
have
to
figure
out
our
position
on
it
sooner
rather
than
later.
C
D
Know
whether
such
dark
exists
and
the
form
in
which
I
know
of
the
problem
is
basically
that
you
know
the
user
with
its
Tokyo,
his
or
her
token
comes
in
through
the
front
end
and
creates
something
usually
and
then
quite
often,
there
are
automated
components
that
then
execute
that
thing.
But
the
automated
components
do
not
actually
act
as
that
user.
They
act
as
basically
super
user,
and
they
to
make
things
even
worse.
They,
they
don't
even
necessarily
always
know
who
they're
acting
on
behalf
of
God.
D
Assumption
that
the
admission
control
or
when
the
user
creates
the
thing
whatever
it
is,
make
sure
that
all
of
the
consequences
of
creating
that
thing
are
kind
of
allowed,
and
then
the
controllers
assume
they
can
just
do
whatever
they're
told
to
do
without
checking
anything.
But
that's
my
understanding
of
the
of
the
problem
and
I
can
envisage
you
know
namespaces
to
some
extent
resolve
this,
because,
as
long
as
the
damage
is
limited
to
namespace
and
that
that
can
sort
of
mitigate
the
problem
but
doesn't
seem
to
actually
solve
the
problem,
be
interesting.
D
D
That
makes
sense,
so
maybe
we
should
we
should
bring
it
up
with
singles
and
say:
look,
you
know,
what's
the
situation
what's
the
plan
and
then
we
can
use
that
as
a
kickoff
point
to
say.
Well,
if
this
is
the
plan,
you
know
these
are
the
ways
in
which
the
plan
does
or
does
not
work
for
our
use
cases
how's
that
sound
that's.
B
To
me
that
there
needs
to
be
two
places
to
do.
Placement
I,
don't
know
that
we
just
picked
the
resource
and
we
just
do
it.
The
way
it
is
today
or
the
resource
will
have
like
a
placement
field,
and
it
could
be,
you
know,
selector,
based
or
whatever,
but
and
then
there's
sort
of
the
ability
to
have
a
separate
placement
resource.
So
you
can
Kalai
placement
be
some
sort
of
way
resolving
if
they
both
define
placement
does.
D
B
A
B
D
B
A
C
So,
just
to
echo
what
erson
said,
maybe
there's
a
component
that
is
responsible
for
remediation
right,
a
reconciliation
policy
changes,
so
you'd
want
to
be
able
to
at
least
have
visibility
into
what
workloads
need
to
be
moved.
But
maybe
you
want
to
go
a
step
further
and
have
them
moved
automatically
and
so
you'd
want
to
at
least
have
that
logic
factored
out
of
the
admission
controllers
that
it
could
be
so
that
it
can
be
reused
by
like
that
kind
of,
like
remediation
engine
I.
A
B
It
it's
more
like
if
some
like
the
I'm,
giving
you
a
concrete
example,
but
it's
really
like
I
need
to
make
a
placement
decision
on
this
resource.
Where
do
I
put
that
decision
and
so
whoever's
making
it
whenever
they're
making
it
there
has
to
be
a
way
of
discovering
where,
if
it's
not
on
the
resource
itself
and
I,
I,
guess
I,
don't
see
there
being
a
good
way
to
make
that
work
with
the
selector.
B
D
D
E
D
D
An
aside
that
document
I
actually
looked
for
it
the
other
day
and
it's
gone
from
the
repo.
Somehow
it
disappeared
in
the
migration
of
various
documents
around
and
I
found
it
in
a
fork
of
our
original
repo
and
somebody
else's
github
account.
So
we
can
go
and
pull
it
back
out
of
there,
but
yeah
I.
Don't
have
anybody
know
where
it
went
or
why
it
went
there.
D
C
B
B
Like
maybe
admin
Paul,
if
you're
only
making
placement
decisions
based
on
placement
resources,
then
maybe
the
admission
controller
would
simply
target
the
placement
rather
than
the
resources.
That's
like.
Okay,
you
have
a
selector.
You
know,
I
want
to
target
all
applications
in
some
place
and
then
you'd
have
you
know,
set
of
clusters,
be
a
selector
direct
object.
Reference
I
mean
what
about
having
an
admission
controller
or
some
other
mechanism
like
managing
placement
resources,
instead
of
actually
miss
Bradley?
Does
that
make
sense,
yeah.
C
I
think
that
that
could
work.
It
raises
questions
in
my
mind
about
how
you
make
dynamic
placement
decisions,
though,
like
so,
if,
if
the
placement
decision
that
you're
or
you're
trying
to
enforce
a
placement
decision,
that's
a
function
of
like
the
incoming
workload
or
the
incoming
resource,
how
do
you
do
that?
It
would
be
kind
of
you'd
have
to
probably
create
these
placement
objects
on
the
fly.
I
would
imagine
so
I
guess
there's
some.
We
would
need
to
like
work
through
that,
but
in
my
mind
that
sounds
a
little
bit
scary.
C
So
today,
in
Federation,
100
or
whatever
we're
calling
it
there's
an
admission
controller
that
can
be
configured
to
call
out
to
a
do
an
HTTP
endpoint,
and
so
it's
totally
decoupled
from
the
the
policy
engine
that
implements
the
placement
policy.
So
it
executes.
Basically
a
web
hook
call
and
then
it
gets
back
a
set
of
annotations
or
patches
to
apply
to
the
to
the
resource
and
created
yeah.
C
Sure
so
I
mean
that's
up
to
the
policy
engine
right
so
like
in
the
case
of
OPA.
You
basically
supply
the
full
extent
of
the
the
resource
being
created.
So
if
it's
a
replica
set,
you
get
the
entire
replica
set
object
as
input
to
the
policy
and
then
the
rules
that
the
policy
engine
uses
to
make
the
placement
decision
can
can
evaluate
over
that
yeah.
E
D
I
can
talk
to
that.
Perhaps
I
think
I
understand
what
you
what
you're
asking
Pole.
So,
let's,
let's
for
the
moment,
just
ignore
policy
and
just
I
think
it'd
be
useful
for
everyone.
Just
have
a
common
understanding
of
how,
like
a
replica,
set
controller,
puts
things
into
clusters
at
the
moment,
so
it
received
a
an
API
object,
a
replica
set
which
may
or
may
not
have
annotations.
D
Those
annotations
can
specify
either
very
specific
placement
requirements.
For
example,
put
this
in
cluster
a
or
put
this
new
cluster
B
and/or.
It
can
receive
less
specific
things
like
put
the
stuff
in
European
clusters
or
put
the
stuff
in
PCI
compliant
clusters,
and
if
it
receives
the
latter
kind,
it
then
goes
and
does
what
it
needs
to
do
and
places
them
by
whatever
you
know,
hard-coded
algorithm
it
might
have
just
matching
labels
etc.
D
If
it
receives
the
mauvais
kind,
then
it
finds
out
what
the
current
status
of
the
world
is
and
compares
that
with
the
desired
status
and
then
essentially
does
whatever
changes
need
to
be
made.
So
if
there
is
a
cluster
in
a
US
region
and
or
rather
a
piece
of
the
replica
said
in
the
US
region
and
the
requirements
state,
that
must
only
be
neo
regions,
it
will,
in
a
removed
from
the
US
region
placed
in
the
EU
region.
E
D
So
mission
controller
is
not
required
for
any
of
this
stuff.
What
the
admission
controller
allows
is
to
have
explicit
configurable
policy
that
would
determine
how
that
happens
and
the
way
that
it's
implemented
today
is
that
it
does
this
evaluation
at
admission,
control
time
and
then
over,
writes
essentially
overrides
the
annotations
on
the
object
based
on
the
outcome
of
the
policy
decision.
That
way,
the
controller
doesn't
need
to
make
you
know
hard-coded
and
configurable
decisions
about
where
to
put
things.
D
E
E
C
Yeah
I
think
I
think
that
what
the
I
think
that
what
you're
asleep
saying
and
what
the
current
proposal
suggests
could
be
made
to
work
I,
just
it
seems
it
seems
kind
of
complicated
to
require
basically
like
dynamic
creation
of
placement
resources
to
control
placement
of
individual
resources,
whereas
today
you
simply
specify
that
the
placement
directly
on
the
resource,
it's
unclear.
Why
I
would.
C
B
And
they
have
a
placement
resource
that
selects
them
based
on
label
like
a
people's
food
or
whatever,
and
then
the
placement
decision
would
be
done
in
math.
I
could
be
applied
to
that
one
placement
resources,
you
know
select
only
these
clusters
I
think,
does
that
I
guess
I'm
having
trouble
understanding.
Why
that
wouldn't
work
but
I
get
like
you're
concerned
of
dynamically
creating
them,
and
what,
in
what
case,
would
you
need
to
dynamically
create
placement
resources
in
the
case
we're
like
they're?
They
don't
exist.
B
C
Yeah
I
mean
yeah
I,
don't
know
what
the
new
API
looks
like
so
yeah.
So
you're
saying
that,
like
the
new
API
is
that
you
have
like
a
collection
of
resources
being
created
or
updated,
and
you
want
to
and
then
you
would
just
create
a
new
place
for
you
just
it's
like,
yet
it
other
resource
on
the
side.
That
is
the
placement
resource.
D
Detective
for
a
moment,
so
so
I
think
what
you're
saying
is
that
typically,
these
things
would
be
created
at
approximately
the
same
time
and
though,
and
therefore
they
could
be
sort
of
viewed
as
but
what
the
API
doesn't
actually
provide.
That
says
you
can
create
these
things
in
any
order
and
any
one
of
them
arrives
any
of
the
other
ones
may
be
missing
or
not
updated.
Yet
you.
B
Know
I'm
not
suggesting
that
there's
some
dependency
on
time
of
creation,
I
guess
the
mom
I
had
whether
it
makes
sense
or
not
would
be
that
there
would
be
like
a
default
placement
resource,
maybe
for
namespace
it
would
be
like
send
all
the
things
to
all
the
clusters
and
so
many
resources
resource
you
created
that
namespace
would
automatically
again
that
propagation.
For
that,
sorry,
that
that
placement
resource
associated
with
them
and
if
there
needed
to
be
more
specific
behavior,
you
would
create
a
new
placement
resource
that
specifically
selected
like
just
this
subset.
B
You
have
modified
the
existing
one
or
whatever
the
goal
of
like
when
you're
applying
policy.
Consider
the
resources
just
consider
the
placement
resource
you're
saying
given
these
characteristics,
or
these
like
that
are
being
selected
for,
like
you,
have
to
be
able
to
parse
the
resource
selector.
Given
these
resources,
what
policy,
what
placement
policy
should
be
applied
and
then
construct
the
appropriate
like
cluster
selector
or
list
of
clusters
or,
however,
that's
the.
B
Like
a
burden,
because
then
you,
you
know,
you
are
there
and
if
you
want
to
provide
specific
placement
for
specific
resources,
you
have
to
start
creating
these
resources.
You
don't
just
get
it
as
part
of
the
resource.
I,
don't
know
whether
that's
worth
it
or
not,
I'm
just
this
is
just
kind
of
like
proposing
a
way
it
could
be
done,
feel
free
to
poke
hole
or
ask
questions
where
I'm
being
completely.
C
Yeah
I
mean
I
think
that
this
goes.
This
goes
back.
I
think
Paul
was
kind
of
asking
this
initially,
which
is
like.
What's
the?
What
are
the
use
cases
here
that
we're
trying
to
solve
and
I
guess
like
if
the
big
one
is
that
you
wanna
be
able
to
supply
or
provide
per
namespace
control
of
replacement,
then
I'm.
C
Seemed
it
seems
like
that's
what
the
current
one.
Oh
sorry,
so
good
I'm,
just
gonna
say
that
that
seems
like
what
the
current
proposal
is
is
targeted
at.
It
doesn't
deal
with
like
cluster,
you
know
or
like
cluster
scope
or
where
we
want
a
federation
scope
placement
so
much.
It
doesn't
really
talk
about
how
you
have
like
how
you
resolve
conflicts
and
so
on,
or
at
least
you'd
have
to
pick
something
and
so
on.
So.
C
E
I
guess
one
thing
that
is
dancing
around
in
my
brain
over
here
is
that
it's
probably
like
two
different
views
of
this
and
I'm,
not
sure
if
I've
been
thinking
about
them
correctly,
so
I
think
one
of
them
is
where
a
user,
and-
and
this
is
probably
the
way
that
I
was
thinking
about
this
last
week.
We're
in
this
in
mental
model-
one
like
you
might
have
a
placement
resource
and
a
user
would
be-
would
create
that
resource,
so
the
user
might
create
a
placement
resource.
E
It
says
this
replica
set
goes
into
clusters,
X,
Y,
&,
Z
and
policy.
Thinking
about
it
as
like,
an
admission
controller
would
say:
sorry
user.
It
can't
go
into
cluster
C
because
that
particular
replica
set
has
a
label.
That
means
that
it
has
to
be
only
in
environments
that
are
compliant
with
this
particular
law
and
only
and
B
are
in
there.
E
That
means
that
they
require
this
type
of
compliance
and
put
them
into
only
the
clusters
where
that
are
compliant
with
that
thing,
and
so,
instead
of
the
user
having
to
say,
put
resource
X
in
cluster,
a
and
B
that
the
policy
might
just
watch
for
watch
all
the
resources
and
say
hey,
there's
a
new
one
that
I
govern
and
I'm
gonna
say:
okay,
well,
I'll
put
it
I'll
make
a
placement
that
is
the
compliant
placement
with
the
policy
that
I
know
about
and
I
wonder.
If
those
make
sense
to
people
as
like.
E
D
On
top
of
that,
and
some
other
deciding
entity
says
this
app
is
a
financial
app
and
it
needs
to
go
into
fika
compliant
or
whatever
the
compliancy
requirements
are
clusters,
so
it
then
essentially
overlays
that
set
of
requirements
and
the
end
result.
Is
you
end
up,
ideally
with
stuff
in
in
clusters
which
are
both
you
know,
spreading
the
right
countenance
and
compliant
with
whatever
the
regulations
are
now
subsequent
to
that
I
think
there
is
a
simpler
requirement.
D
D
Because
I
think
what
you
end
up
with
is
something
that
probably
doesn't
do
what
the
user
wants.
You
know
if
the
user
says
I
wanted
in
a
B
and
C,
but
then
there's
a
policy
that
says
you
can't
put
them
in
a
B
and
C
because
of
whatever
the
policy
is
you
probably
just
end
up
with
a
nonworking
application
and
and
to
have
it
working?
You
need
to
have
some.
You
know
fairly
sophisticated
automation
in
the
system
that
says.
D
Well,
you
said
you
wanted
a
B
and
C,
but
I'm
gonna
put
them
in
D
and
F
because
of
policy,
and
then
the
user
says.
But
what
the
hell?
That's,
not
what
I
wanted
etcetera
etcetera.
So
you
kind
of
rabbit
hole
and
one
solution
to
that
problem
might
be
to
say:
if
you
want
a
B
and
C,
you
just
get
it
and
you
don't.
You
know
those
flavors
of
clusters,
don't
get
policy
and
don't
get
anything
more
than
being
able
to
put
stuff
in
a
B
and
C.
D
If
you
want
policy
and
and
higher
level
control
of
where
your
stuff
goes,
because
you
don't
want
to
have
to
keep
track
of
you
know
this
month,
it's
a
B
and
C,
and
next
month
it's
C,
C
and
D,
and
every
month
deployer
has
to
go
and
like
decide
where
to
put
their
stuff.
Because
the
clusters
have
moved
or
changed
or
being
turned
down.
D
E
D
E
And
so,
if
you,
if
you
use
the
like
the
manual
control
policy
or
the
manual
control
flavor
of
placement,
maybe
you
just
have
to
be
very
careful
that
you
configure
it
to
do
the
things
that
are
compliant
with
the
rules
that
you
actually
like
as
a
business
not
to
comply
with
and
at
the
other
end
of
the
spectrum.
Maybe
there
is
something
that
you
program
at
a
higher
level
and
say
put
these
workloads
into
the
places
where
the
policy
says
that
they
should
go,
and
maybe
that
could
generate
the
manual
flavor
and
reconcile
those.
D
Yeah
I
guess
the
only
caveat
to
that
would
be
that
you,
you
could
have
the
explicit
placement.
You
know,
I
want
a
B
and
C,
but
you're
explicitly
giving
up
automated
high
availability,
because
you
know
if
the
policy
says
you
can't
do
that.
Then
your
thing
just
doesn't
work
and
or
if,
if
it
means
you
turn
down,
you
start
your
app
like
your
app
doesn't
run
anymore.
Mm-Hmm,
there's
no
like
fancy
system
that
is
going
to
making
that
run
because
you're
specific
about
what
you
wanted
and
all
we
can
say
is
no.
E
Which
document
is
that
the
the
brainstorming
one
I'm
putting
a
link
to
it
here?
It's
the
whiteboard,
drawing
that
has
the
like
template
placement
overrides
propagation
related
to
one
another,
and
in
terms
of
like
that,
drawing
I
almost
am
seeing
policy
as
like
in
alternative
in
the
swim
lanes
or
in
the
column
that
placement
in
overrides
is
in
there,
like.
Maybe
you
specify
placement,
or
maybe
you
specify
policy
and
the
outcome
of
like
those
either
one
of
those
is
something
that
can
express
where
things
should
go
in
some
way.
D
Because
it's
worth
noting
that
that
the
problem
we
just
outlined
is
not
actually
specific
to
policy
it,
it
occurs
with
availability
as
well.
So
if
you
said,
I
want
my
stuff
in
a
B
and
C
and
there's
a
VNC
screen,
and
only
if
you
give
the
system
the
ability
to
override
your
choice
and
put
them
in
D
and
F,
because
that's
where
this
capacity
do
you
get
a
working
system
and
the
same
applies
to
quota
and
other
such
things.
G
C
I'm
just
I'm
wondering
now,
if
there's
like
a
middle
ground
here,
where
you
have
this
relatively
simple,
her
namespace
placement
object
that
could
exist
and
it
would
make
it
easy
for
people
to
control
placement
with
a
fairly
like
coarse-grained
deep
spell,
but
then
you've
also
had
the
ability
to
specify
the
placement
or
propagation.
Maybe
it's
better
word
for
it
on
the
individual
resources.
That's
effectively
what
exists
today
right
you
can
on
an
individual
resource.
C
C
B
Your
mind
well
I,
think
I
think
it
is
just
because
it's
like
I
was
like.
Oh
you
could.
You
could
have
the
policy
engine
applying
to
placement
resources
then
I'm
like
well.
How
are
you
gonna
do
that?
Even
if
there's
you
know,
label
selection
going
on
what,
if
you're,
not
defining
a
label
that
the
underlying
resources
are
defining
cause
you
know
like
it
just
becomes
a
really
complicated,
so
I
mean
when
I
was
originally
thinking
about
this
a
really
long
time
ago.
B
B
Maybe
one
like
that.
Just
like
I
guess
for
me
are
they're
having
it
being.
A
direct
field
is
one
option
which
would
kind
of
mirror
what
the
Federation
v1
does
today
and
I
think
that
would
be
one
way
to
do
it
and
another
way,
B
to
have
a
separate
resource
that
was
like
directly
related
and
the
only
advantage
of
having
a
separate
resource
that
was
very
like
he
was
per
resource
placement,
not
like
her
namespace
or
using
a
selector.
B
The
only
advantage
of
that
is
they
needed
to
control
it
with
something
like
our
Belk
and
you'd
be
able
to
prevent
people
from
changing
and
who
weren't
allowed
to
change
it.
But
you
could
equally,
you
know,
created
an
admission
control
that
would
control
things
at
the
feel
field
level
so
either
way.
My
my
thinking
is
that
we
probably
need
something
applies
to
curry
source
soap.
D
There's
this
I
think
we
might
be
making
it
more
complicated
than
it
needs
to
be
so
so
we
have
the
set
of
requirements
that
the
user
that
the
application
administrator
specifies,
whatever
their
requirements
are,
which
may
be
specific
or
generic
specific
example
we've
been
using,
is
Class,
A,
B
and
C
generic
is
like
Europe
or
PCI
compliant
or
whatever.
Then
we
have
the
outcome
of
the
placement
decision
by
the
system
which,
in
the
case
of
a
specific
cluster
selection,
can
either
be.
D
You
know
that
that
set
of
clusters-
or
you
know,
maybe
policy,
overrode
it
and
said
we
decided
not
to
put
it
anywhere,
because
the
request
was
not
compliant
of
policy
or
in
the
more
general
case,
the
placement
decides
that
it
goes
into
particular
clusters.
But
that's
not
that's
distinct
from
what
the
user
asked
us
for
and
I
think
is
specific
to
particular
resources.
D
D
Well
so
then
you
have
a
separate
requirement,
which
is
that
I
want
the
secret
to
be
in
the
same
cluster
as
this
replica
set,
and
that
I
think
is
a
different
constraint
and
then
then
you
know
the
schedule
is,
for
those
two
different
things
have
to.
You
know
take
into
account
that
this
thing's
already
in
the
other
cluster,
so
I've
got
to
put
it
there
or
or
I
have
to
fail.
Oh
I
have
to
move
the
other
thing
to
the
same.
So
there's
a
proximity
requirement.
B
D
C
It
is
important
to
point
out
that,
if,
if
the
policy
engine
and
the
policy
author
defined,
for
example,
an
annotation
or
a
label,
or
something
like
that,
like
a
group
ID
or
something
that
the
policy
could
enforce,
that
proximity
constraint
right,
like
the
existing
system,
is
flexible
enough
to
allow
both
the
application
to
specify
that
intent.
That
proximity
requirement
and
then
the
policy
engine
should
be
capable
of
performing
that
right
when
it
when
it
makes
the
place
of
decision
a.
A
B
B
D
D
D
Of
proximity
requirements
I'm
on
the
one
end
of
the
spectrum.
There
is
placement
very,
very
close
to
this
thing,
or
this
other
set
of
things
like
on
the
same
node
and
then
on
the
other
extreme.
There
is
placed
me
as
far
away
as
possible
from
this
other
thing,
because
I'm
I'm,
the
backup
database,
so
put
me
on
a
different
continent
kind
of
thing.
We're.
D
H
A
D
I
D
D
D
Okay,
we
do
have
everyone
here
and
we
have
another
ten
minutes.
If
we
wanted
to
I
promised
at
the
last
meeting
that
I
would
publish
the
paper
on
labels
as
first
class
objects,
which
I
did
last
week
and
has
gathered
lots
of
feedback
across
the
spectrum
we
could.
We
could
have
a
quick
look
at
that
if
anybody
wants
to-
or
we
can
next
time,
I
think.
D
D
E
D
D
Cannot
you
know
real
able
nodes
or
real
able
pods
to
get
around
the
intention
of
whatever
the
policy
is
so
right
now
the
only
way
to
know
label
something
is
to
have
right
access
to
that
thing,
and
then
that
fact
that
you
have
right
access
to
that
thing,
which
might
be
a
pod
or
a
node
or
replica
set,
also
gives
you
that
ability
to
label
it
with
anything.
You
want
to
label
it
with
and
that
may
influence
what
label
selectors.
D
It
is
subject
to
so,
for
example,
a
controller
that
says
I
want
to
you
know,
consider
some
pod
to
be
part
of
a
replica
set
may
get
confused
if
you
label
your
pods
with
a
label
that
is
consistent
with
that
replica
set
and,
to
some
extent,
namespaces
kind
of
aim
to
get
around
this
problem
by
saying.
Well,
you
know
you
typically
only
have
access
to
stuff
in
your
namespace
and
what
you
do
in
there
is
your
problem,
but
that's
the
general
space
of
the
problem.
D
So
the
document
describes
it
in
a
little
more
detail
and
there's
a
ton
of
comments
down
the
right-hand
side.
There's
an
appendix
trying
to
kind
of
catalog
all
of
their
recognized
challenges
that
people
or
problems
that
people
see
with
us
and
perhaps
try
and
brain
solutions
and
there's
a
very,
very
nascent
detailed
use
case
description
for
places
where
this
might
be
necessary
and
or
desirable.
D
E
D
E
It
sounds
like
a
valid
application
that
for
sure
there
are
at
least
like
two
or
three
other
areas
that
want
similar
things
and
just
whole
disclosure.
Having
had
people
asked
me
for
capabilities
in
like
like
that
in
other
areas,
I've
done
some
asking
to
the
API
Machinery
gods
about
it
and
so
far
it
like
the
response
that
I've
gotten
that's
actually
like
affected
the
design
that
we've
gone
with.
D
Yeah
I've
heard
similar
concerns
and
and
other
concerns
about
all,
but
namespaces
are
great
and
the
current
labeling
scheme
is
great
and
don't
change
it
and
whatever
and
I
think
that's
totally
reasonable.
I
haven't
put
written
it
explicitly
in
the
document,
but
I
fully
envisage
that
this
could
be
implemented
totally
outside
of
core
and
as
an
optional
thing.
D
So
imagine
a
Ciardi
called
labels
and
Ciardi
called
label
attachments,
which
you
know,
has
two
pointers
one
to
the
label
and
want
a
thing
that
it's
attached
to,
and
these
are
totally
outside
of
core
and
all
controllers
and
api
machinery
is,
can
be
completely
oblivious
to
these
things,
but
that
it
would
be
possible
to
write
a
controller
that
would
be
able
to.
You
know,
give
you
a
list
of
pods
with
these
secure
labels
attached
to
them
and
they
would
have
semantics
which
more
strong
and
well-defined
than
the
current
labeling
or
namespace
scheme
and
more
flexible.
D
E
This
are
the
people
that
created
the
project
thing
so
I'm,
hoping
that
maybe
there's
something
out
there.
That
contains
elements
of
a
general
solution,
but
I
think
you're,
right
I
think
there
could
be
other
ways
around
that
and
that
I'm
getting
to
the
point
where
I
have
so
many
people
asking
me
for
a
way
to
do
this,
that
if,
if
there's
not
an
easy
way
to
modify
the
API
machinery
to
do
it,
I
think
we
should
figure
out
another
easy
way
that
can
be
like
a
temporary
hedge
yeah
is.
E
So
I
think
that's
part
of
it
one
one
thing
that
seems
to
be
entangled
with
it
is
watch
semantics
like
if
you
have
a
an
ACL
that
gives
you
access
to
read
access
to
read:
let's
call
it,
like
instance,
X
of
resource
Y,
and
then
you
you
do
a
watch
on
on
resource
y
or
I'm.
Sorry,
you
do
a
watch
on
resource
Y
and
you
get
events,
for
instance,
X
of
that
resource,
and
then
your
Akal
changes
so
that
you
no
longer
have
access
to
it.
What
happens?
Do
you
just
stop
getting
watch.
D
D
So
what
I
can
briefly
employ
you
all
to
do
is
if
you
think
this
is
a
good
idea,
please
vocally
state
so
on
the
document,
because
otherwise
it
will
be
drowned
out
in
people
who
are
saying
that
it
is
a
good
idea.
So
don't
just
say
that
to
me
put
it
in
the
document
and
say:
I
think
this
is
a
very
worthwhile
thing
to
think
about
or
the
words
you
use
poll
I'd
appreciate
that
very
much.
A
D
E
A
E
So
I
guess
one
question
and
I
know
we're
a
little
over
who's.
This
now
and
I'll
start
an
email
thread
about
it
so
that
we
can
discuss
it
there
do
should
we
continue
having
this
meeting
on
Monday
I
think
it's
useful
to
get
as
much
bandwidth
as
we
can.
We
have
Federation
working
group
on
Wednesday
and
then
we
have
every
other
week
the
Tuesday
multi
cluster
meeting.
Should
we
should
we
have
another
Monday
meeting
next
week,
and
maybe
we
can
talk
about
that
on
Wednesday
I.