►
From YouTube: Kubernetes Federation WG sync 20180124
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
A
A
C
C
C
C
Overrides
are:
is
the
concept
of
enabling
certain
fields
to
be
differentiated
in
such
a
way
that
they
eventually
vary
in
some
cluster
and
we're
agnostic
at
this
level
of
just
like
talking
about
what
things
are
about?
How
that's
done,
whether
those
whether
that's
a
selector
or
some
other
mechanism
selection,
seems
to
be
the
one
that
people
identify
with
a
lot.
C
So
that's
what
that
one
is
placement,
then,
is
which
member
clusters,
a
resource
or
set
of
resources,
should
exist
in
and
Greg
Harmon
I
think
you're
on
the
call
I
think
you
had
some
questions
about
this.
So
if
you
want
to
call
those
out
and
we
can
clarify
them,
that
might
be
helpful
for
other
folks,
too
sure.
C
So
I
try
to
draw
a
picture
that
related
these
things.
Let's,
let's
talk
about
the
difference
between
those
after
we
just
kind
of
go
over
what
each
one
was
and
we'll
see.
If
we
can
sort
that
out
so
we're
on
placement
placement
is
which
clusters
does
a
resource
belong
in.
So
placement
is
like
the
knowledge
that
you
want
to
put
deployment
X
in
clusters.
A
B
and
C
propagation
is
now
that
you
know
where
things
need
to
go.
C
How
do
they
get
there
so
like
propagation
refers
to,
like
maybe
you're
running
a
controller,
that's
actively
reconciling
and
putting
actively
putting
resources
into
clusters,
or
maybe
you're
running
some
kind
of
controller
that
dumps
things
into
a
git
repo.
That's
something
like
cube.
Applier
then
pulls
in
and
reconciles.
But
it's
like
propagation
is
basically
the
transport
mechanism
and
and
surrounding
concerns,
so
like
push
versus
pull
active
versus
passive
reconciliation
status
provides
the
next
one
is
status,
and
that
refers
to
what
we
all
think
of
as
status
in
kubernetes
ap
is
the
reason
that
it's
separate.
C
The
reason
that
it's
separate
is
that
we
do
not
necessarily
all
we're
not
all
necessarily
going
to
have
the
same
idea
of
status
and
there's
examples
in
the
stock
that
we
can.
We
can
look
at
when
we
drill
into
it,
but
from
our
prior
discussions
in
this
working
group,
it
seems
like
there's
at
least
two
different
schools
of
thought,
for
what
status
should
look
like
where
and
it's
probably
a
spectrum
where,
on
one
end
of
the
spectrum,
there's
a
camp
of
I
just
want
to
see
some
status
as
I.
C
C
The
idea
that,
like
I,
would
like
to
see
all
the
different
statuses
of
all
of
these
different
resources
in
the
different
clusters
in
such
a
way
that,
like
I,
don't
have
to
drill
into
each
cluster
to
see
the
status
information
like
some
kind
of
status
aggregation,
and
we
have
been
thinking
that
it
might
be
to
to
avoid
a
situation
where
we
feel
like.
We
have
to
agree
on
every
element
of
these
things.
C
It
might
be
useful
to
think
of
status
as
being
separate
resources
so
that,
if
I
have
status
flavor
a
that
I
identify
with
and
want
to
use
and
Greg
has
status,
flavor
B
that
he
identifies
with,
which
is
different
than
my
own
idea.
We
don't
necessarily
need
to
agree
and
like
and
I
can
implement
our
own
different
flavors
of
resources
to
show
these
different
flavors
of
status,
and
then
the
last
one
is
scheduling
and.
C
So
there's
kind
of
a
conceptual
overlap,
but
we've
been
trying
to
tease
out
that
these
things
as
distinct
concepts
and
figure
out
how
they
relate
to
one
another.
So
I'm
gonna
stop
talking
now
because
I've
been
talking
for
a
little
bit
any
any
questions
about
these.
Before
we
take
a
look
at
this
picture,
this
lovely
elegant
diagram,
which
I
have
inserted
into
the
into
the
document
there.
E
Consider
scheduling
to
be
considering
the
state
of
the
Federation
API
and
the
member
clusters
and
determining
like
dynamically
placement
and
overrides
propagation
is
considering
template
placement
overrides
to
determine
what
a
given
resource
for
a
given
cluster
should
appear
as
and
then
looking
at
the
member
clusters
to
determine
whether
they
match
and
if
not,
then
updating
them.
So.
E
Yeah
so
that
I
mean
this,
isn't
necessarily
how
the
implementation
would
work.
I
mean
you
could
have
these
things
kind
of
conjoined,
but
the
logical
separation
is
just
intended
to
have
like
this
is
the
responsibility
of
scheduling
is
determined
dynamically
placement
and
override
values,
whereas
propagation
is
really
about
figuring
out
what
to
propagate
and
whether
it
needs
to
be
propagated.
E
D
E
D
E
D
A
C
Well,
let
me
drop
this
link
into
the
chat
and
make
sure
that
people
can
follow
on
their
own
screens,
since
that
might
be
easier
to
see
so
I
tried
to
like
relate
these
things
to
one
another
in
like
a
visual
way
and
the
left
starting
at
the
left,
which
I
think
it's
like
the
most
kind
of
basic
thing.
Is
you
have
some
way
to
specify
a
template
right?
C
That's
that's
universal,
whether
that's
and
and
template
here
is
just
a
placeholder
for
the
concept
of
you
have
some
base
description
of
a
resource
that
should
go
into
multiple
clusters.
It
occurs
to
me
that
the
cluster
registry
isn't
on
this
diagram.
Maybe
I
can
throw
this
into
a
diagram.
Editor
people
think
the
diagram
is
useful
and
add
that
in
but
the
most
basic
concept
is
you
specify
some
resources
right
so.
C
When
and
that's
kind
of
in
its
own
swimlane,
the
next
swimlane
is
about.
How
does
that
resource
get
like
like
the
the
description
of
which
clusters
that
should
be
in
which
is
placement,
and
also
how
that
resource
should
be
differentiated?
If
at
all,
when
it
goes
into
some
clusters,
which
is
overrides,
we
put
those
in
the
same
swimlane,
because
they're
they're,
they're
kind
of
they're
very
closely
related,
and
it's
certainly
possible
that
in
some
like
in
some
views,
they're
similar
and
maybe
they
wind
up
getting
conflated.
C
But
while
we're
just
agreeing
on
the
view
of
the
problem
space,
we
want
to
keep
them
separate.
So
that's
kind
of
the
next
layer,
and
after
these
first
two
layers
walking
left
to
right.
You've
got
information
about
which
resources
are
going
to
be
in
which
clusters
and
their
final
forms
after
overrides
are
applied.
Like
all
that
information
is
described
in
those
first,
two
columns
on
the
left
and
after
that,
there's
the
question
of
how
do
they
actually
get
into
the
clusters
and
that's
propagation.
C
So
propagation
is
something
that
somehow
is
reconciling
the
information
in
those
other
two
columns
into
the
member
clusters
of
a
federation
and
since
that's
sort
of
the
description
of
the
the
very
basic
elements
of
the
story.
When
we're
talking
about
this,
these
multi
cluster
use
cases
and
federated
api's.
Let's
stop
there
before
I
just
talk
and
talk
and
talk
and
I
wondered
if
people
think
so
far.
The
diagram
is
useful
to
relate
these
things.
D
Anybody
else,
I
was
wondering,
is
it
I
was
saying:
sometimes
it
might
make
sense
to
have
placement
and
overrides
sort
of
together
like
it.
If
what
you're
putting
somewhere
is
like
it's
like,
if
you're
like
tearing
something
and
like
you
know
where
you're
putting
it
and
the
values
like
oh
I,
just
wanted
to
like
a
little
bit
of
traffic
there,
like
those
really
certain
hand,
things
I'm
a
little
worried
about
having
them
like
developed
separately
or
evolving
separately,
yeah.
E
Mm-Hmm
all
that,
let's
consider
like
if
I,
have
an
override
and
it's
like
replicate
count
equals
zero.
That's
kind
of
an
indication
could
be
indication
that
I
don't
actually
want
that
replica
said
in
that
cluster,
but
I
could
also
treat
that
is
I
want
that
replica
set
in
that
cluster,
with
a
replica
count
of
zero
versus
placement,
which
is
I,
want
it
in
hand
versus
I.
D
E
Goal
here
is
to
allow
these
things
to
evolve
independently,
and
if
someone
wants
to
implement,
you
know
a
different
type
of
placements,
then
we
don't
want
to
be
prescriptive
and
prevent
them
from
doing
it.
So
it's
not
saying
that
there
won't
be
a
default
implementation
that
is
sort
of
one
way,
but
by
keeping
them
separate,
we
leave
the
door
open
for
someone
swapping
that
piece
out
and
without
having
to
swap
the
whole
system.
D
E
F
So
this
is
more
an
effort,
not
mostly
an
effort
to
just
pull
those
logical
pieces
apart
and
and
enable
people
to
either
do
what
the
current
implementation
is,
which
is
put
them
all
in
one
big
fat
controller
or
break
it
up
into
pieces
and
then
I
presume
a
user.
Could
you
know,
use
the
same
API
to
to
interact
with
Federation
but
choose
the
operator
of
that
Federation
control
plane
could
decide
which
controllers
to
plug
in
to
make
all
that
happen.
C
You
know
yep
and
there's
also
a
possibility
that,
like
say,
for
example,
we
chose
to
implement,
as
a
group
chose,
to
implement
like
resources
that
align
pretty
closely
to
this
decomposition.
There's
also,
no
reason
why
you
couldn't
implement
something
in
front
of
all
of
this.
That
hid
it
from
users
or
implement
like
a
thicker
API
in
front
of
this.
That
might
just
generate
other
api's
I
think
that's
make
sense.
E
To
me,
that's
kind
of
a
critical
distinction,
I
mean
kilburn.
Eddy's
is
kind
of
the
same
way
where
I
don't
think
the
kubernetes
api
is
particularly
user
friendly,
but
it's
the
primitives
that
a
lot
of
people
to
build
more
use
api's
on
top
it
has
everything
you
need.
You
can
structure,
something
that
you
know
does
works
the
way
you
want.
That
is
more
suited
to
your
use
cases
and
that's
kind
of
the
same
goal
here.
I.
C
Just
realized
that
I
have
a
local
kubernetes
cluster
that
is
taking
resources
away
from
my
video
conferencing.
So
I
got
some
super
compressed
audio
that
I
couldn't
quite
make
out,
but
I
I
think
what
I
could
understand
from
it
and
it
was
played
at
like
3x
speed,
I
think
that
I
agree
with
it
yeah.
So
the.
C
C
Orphan
and
Maru
may
like
as
just
total
examples
in
the
the
view
that
I'm
getting
of
the
list
of
people
in
this
this
room
may,
like
you
know,
maybe
your
fun
wants
X
or
Y
flavor
and
Marie
wants
Z
or
the
first
letter
in
on
beyond
zebra,
which
I
can
never
remember,
flavor
and
probably
different
flavors
appeal
to
different
people.
So
maybe
there's
multiple
implementations
of
status.
C
Disambiguate
things
Greg,
so
let
me
know
this
makes
sense
to
you.
So
here's
my
analogy
for
scheduling
like
as
a
human
being
I
can
be
a
scheduler
like
you
could
not
implement
anything
in
the
scheduling
box
and
have
me
at
my
battle
station,
watching
the
status
of
clusters,
a
B
and
C
and
saying
I
need
to
keep
the
the
total
replica
count
for
this
deployment
at
50
across
those
clusters.
C
So
I
see
that
I'm
at
10
in
cluster,
a
and
I'm
in
I'm,
at
5
in
cluster
B
and
I'm
only
at
20
in
cluster
C,
so
I'm
going
to
alter
the
overrides
and
change
the
replicas
and
those
clusters.
That's
me
being
a
scheduler
so
like,
but
I
think
the
idea
is
like
yeah.
They
overlap
and
at
least
in
my
own
mind,
scheduling
is
like
something
that's
kind
of
higher
level:
that's
reprogramming
overrides
and
reprogramming
placement.
C
C
D
C
B
Sounds
to
me
also,
like
maybe
scheduling,
is
like
a
conceptual
way
or
a
box
for
the
the
feedback.
Loop
there's
always
existed
in
Federation,
it's
like
making
that
feedback
loop
explicit
rather
than
having
it
be
implicit
up.
Oh
yeah,
there's
a
status
and
it
updates
the
placement,
no
there's
a
status
that
feeds
into
a
scheduler
and
the
scheduler
is
the
one.
That's
updating
the
placement.
I
think
that,
for
me,
I
think
that's
useful,
but
definitely
useful
to
conceive
of
it
that
way,
because
it
makes
it
just
a
bit
more
yeah.
D
C
Say
that
you
had
a
resource
that
was
like
replicas
are
deployment
deployment
scheduler,
and
you
say
you
might
program
that
resource
by
saying
in
this
cluster
selector
across
this.
The
clusters
in
this
selector
and
keep
the
total
replicas
counted
50
and
then
the
controller
that
backs
that
resource
could
generate
placement
and
overrides
that
would
implement
that.
D
C
E
D
E
E
Increase
the
overrides
I
mean
the
scheduling
component.
If
you
had
a
scheduling
component
determining
your
replica
count
per
cluster,
it
would
depend
on
the
scheduling
configuration
you
provided
and
the
state
of
the
clusters
that
it's
monitoring
I'm,
not
sure
that
answer
your
question
or
my
speaking
in
cross.
D
E
Yes,
potentially,
if
like
if
say
you
had,
you
wanted
20
replicas
across
your
two
member
clusters
and
the
capacity
in
one
of
your
clusters
prevented
there
being
an
equal
balance,
so
you
couldn't
actually
do
ten
in
each.
You
could
only
do
eight
one
if
you
said
I
wanted.
You
know
20
total,
then
the
scheduler
would
say
well.
I
have
to
increase
this
one
to
twelve
to
mean
to
meet
that
constraint.
So
I
would
think
that
if
you
were
running
a
scheduler
or
whatever
manually
defined,
overrides
you'd
set
would
be
superseded
by
anything.
E
The
scheduler
decided
I
mean
really.
There
wouldn't
be
much
point
in
setting
a
manual
override
if
you
were
using
a
scheduling
component
to
control
it,
but
the
explicit
requirement
to
have
a
scheduling
preferences
resource
associated
with
the
given
template.
That
would
be
the
only
reason
the
scheduler
would
act.
So
if
you
did
not
have
that
scheduling
preferences
or
some
sort
of
default
configuration
that
said
scheduled
me,
even
if
I
don't
have
that
resource,
then
chances
are.
You
would
just
respect
the
manual
override
if
one
existence,
so
it
gives
the
user
flexibility
if
okay.
B
You
that
sounds
to
me
like.
If
we
look
at
the
the
the
other
things,
the
template,
the
placement,
the
overrides
it
sounds
like
the
scheduler
is
kind
of
an
add-on
component
to
a
basic
Federation.
You
could
run
a
Federation
without
a
floor
if
you
just
run
a
Federation
that
has
templates
placements
and
overrides
defined,
and
it's
not
at
all
doing
anything
active
with
status
results,
so
I
think
it
makes.
It
makes
sense
to
me
now
why
the
scheduler
is
outside
of
the
swim
lanes,
because
it
really
seems
like
it's
almost
in
the
st.
B
E
I
think
it's
useful
to
think
about
that
conceptually
there's
nothing
stopping
someone
from
just
internalizing
that
and
not
actually
exposing
that.
But
at
least
this
gives
a
logical
model
that
can
be
used
for
both
something
that's
where
it's
explicit
separated
out
and
when,
where
it's
implicit
and
just
on
you
know,
pipeline
of
some
kind,
I
mean
for
me.
I
I,
think
of
I
can
think
of
a
use
case
where
all
I
want
to
do
is
copy
the
same
resource
to
every
cluster.
E
I'll
just
mirror
copies
and
all
I
need
is
the
template
and
then
I
want
to
be
able
to
have
a
per
cluster
variation
and
ie
templates
and
overrides.
And
if
I
want
placement
you
know,
then
I
can
actually
decide.
You
know
things
go
to
cluster
or
not
need
a
templated
placement,
and
so
it's
kind
of
composable
and
I'm.
Maybe
it
would
make
sense
if
user
just
wanted
to
have
the
simplest
possible
system.
They
just
wouldn't
use
a
given
piece
like
I.
E
F
Yeah
that
makes
reasonable
sense
to
me.
One
comment
that
I
guess
we
should
perhaps
just
bear
in
mind
is
on
the
one
extreme.
We
have
an
API
which
is
you
know
you
specify
you
create
a
single
thing.
Let's
call
it
a
federated
replica
set,
for
example,
and
inside
there
is
all
the
information
that
all
of
these
components
would
need,
possibly
some
of
those
areas
optional
so
like.
F
If,
if
I
didn't
want
to
do
overrides
or
didn't
want
to
do
placement,
then
you
know
the
section
that
specifies
how
to
do
overrides
or
placement
would
just
be
missing
in
a
given
creation
and
then
possibly
the
controllers
that
do
that
stuff
would
also
be
missing.
So
that's
on
the
one
end
of
the
spectrum.
We
could
have
take
that
approach.
On
the
other
end
of
the
spectrum.
F
We
could
end
up
with
the
situation
where
we
have,
you
know
a
large
number,
let's
say
five
or
six
or
seven
API
objects
which
collectively
cause
the
desired
end
result.
So
we
could
have
a
you
know,
a
template
thing,
and
then
we
could
have
a
placement
directive
thing
and
we
could
have
a
scheduler
I'm
talking
about
API
objects
now,
and
we
could
have
to
specify
like
six
of
these
things,
to
have
it
work
properly
and
I.
F
Think
that
would
potentially
make
the
world
more
complicated
than
the
people
who
want
to
use
the
full
functionality
you
want
and
I
guess.
Maybe
an
analogy
might
be
so
in
kubernetes.
At
the
moment
you
have
replica
sets
and
you
can
just
create
one
of
them
and
it
tells
you
you
know
it
specifies
how
many
of
the
replicas
you
want
and
the
properties
etc.
And
then
you
know
one
step
up
from
that.
F
E
I
think
the
goal
wasn't
to
say:
yeah
we
want
all
these
API
objects.
It
was
more
to
have
a
degree
of
separation
so
that
potentially
we
could
have
like
an
alpha
phase
where
different
sort
of
implementations
of
a
given
concept
were
kind
of
attempted
implemented,
tested
discarded,
but
probably
with
the
eventual
goal
of
like
cleaning
it
up
and
optimizing
it
for
actual
use.
Maybe
the
one
caveat
being
I
think
there
at
least
the
sort
of
thought
process
I
have
our
on
placement
and
I.
E
Think
we've
had
discussions
about
this
is
that
it
might
actually
be
useful
to
have
that
separate,
because
then,
if
you
had
say
give
an
application
that
you
wanted
to
deploy
to
a
set
of
clusters,
you
could
have
placement
directives
that
apply
the
label
selector
or
something
rather
than
having
to
define
that
in
every
single
resource,
but
certainly
for
things
that
have
direct
relationships
like
status.
Like
overrides,
like
scheduling
preferences,
it's
less
clear
than
having
those
separate
over
the
long
term
will
actually
have
value.
Does
that
make
sense.
C
So
Quentin
I
also
think
that
I
I
dent
off',
I
and
empathize,
with
what
you're,
saying
and
I
have
been
thinking
of,
like
I,
guess,
I
I
guess
I
already
mentioned
this
a
little
bit
ago,
but
just
to
expand
on
it,
like
I,
also
think
that
it
would
be
possible
to
have
like
a
simpler
API,
conceptually
like
say,
say
that
we
did
wind
up
implementing
API
resources
that
like
aligned
with
these.
Let's
see
it
looks
like
six
boxes
and
we
wind
up
with
six
API
resources.
C
F
Yeah
yeah,
that's
that's
an
absolutely
valid
observation
and
and
I
had
a
similar
thought.
Actually
a
little
earlier
when
we
were
talking
about
you
know
propagation
and
these
kind
of
things
I
could
imagine
a
lower
layer
underneath
what
we've
been
talking
about
here,
where
you
just
create
a
normal
kubernetes
object
in
the
Federation's
control
plane
with
specifier,
for
which
cluster
you
wanted
to
go
to
and
it
it
goes,
and
does
that
and
then
some
of
these
higher
level
abstractions
we
build
on
top
of
that
basic
stuff,
and
some
people
might
just
use
the
basic
stuff.
F
C
Yeah
so
I've
had
a
similar
thought.
The
difference
in
the
thought
that
I've
had
would
be
like
you
can
put
that
you
can
also
so
I
think
you're
right
like
that
is
definitely
one
possibility.
I
think
you
can
also
put
it
at
the
other
end.
So,
like
you
can
you
can
stick
a
facade
like,
oh
I,
guess
I'm
not
sharing
my
screen.
It
doesn't
really.
E
Mean
I
put
in
two
suggestions
and
it
seemed
like:
maybe
you
prefer,
the
the
union
of
the
results
and
tauren
who's,
not
sure
if
he's
on
the
call,
but
he's
responsible
for
integration
with
OPA
the
policy
engine,
he
was
kind
of
concerned
at
the
use,
maybe
of
selectors,
for
defining
what
you
were
applying
placement
to
and
I.
Think
I
kind
of
if
I
understand,
is
concerned
correctly.
It's
that
if
you're,
if
you're
automatically
applying
using
policy
to
define
placement,
maybe
a
selector
is
not.
It's
not
cannot
good
enough
for
lack
of
a
better
term.
E
C
While
I'm
thinking
about
it,
I
realized
that,
like
policy,
is
actually
not
reflected
on
this
on
this
diagram
and
I
think
it
might
be
really
profitable
to
have
like
either
have
a
breakout
session
or
I
I
have
I,
don't
want
to
mispronounce
the
person's
name
that
you
mention
Meru
or,
but
perhaps
it
would
be
like
good
to
have
a
session.
A
group
session
like
just
on
policies
and
like
open
policy
engine
I,
think
it's
called
or
open
policy
agent.
I
am
NOT,
confident
that
I
actually
understand
all
of
what
that
can
do.
E
A
tldr
on
that
which
is
given
a
resource
with
specific
labels.
You
define,
like
you,
kind
of
translate
those
labels
into
placement
directives.
So
I'm
you
know
I'm
supposed
to
be
going
into
or
like
I'm
on
some
critical
function
and
all
critical
functions
have
to
be
done
in
the
country
that
my
company
is
located
in,
and
so
you
translate,
you
know
the
cluster
selector
to
make
sure
that
it's
going
into
clusters
with
those
characteristics
that
make
sense.
E
I
thought
that's
what
it
is
today,
I'm,
not
saying
that
I
certainly
think
it's
profitable
would
be
profitable
to
have
a
discussion
with
him
and
engage
him
in
this
brainstorming.
It's
more
that
like
as
far
as
the
current
state
of
Federation
and
what
policy
does
it's
I
believe
it's
strictly
about
placements
I
was.
C
Going
to
ask
whether
so
I
I've
looked
at
the
the
expression
language
that
you
can
use
to
describe
policies,
and
it
looked
to
me
in
the
examples
that
I
looked
at,
that
it
was
mostly
dealing
with
placement.
But
I
haven't
wondered
to
myself
whether
there's
like
another
facet
of
policy
that
that
might
deal
with
like
amount
of
workloads
that
you
can
run
in
particular
places
which
I
guess
ultimately
comes
back
to
placement.
E
I
mean
I
think
it
could.
It
could
be
that
you
enforce
any
kind
of
administrative
oversight
like
you
could
say
all
you
know
things
in
this
country
of
this
type
have
to
use
this
image
right,
like
there's
all
kinds
of
different
things
you
could
apply
I'm
just
in
today
it
seems
like
it's
very
specifically
targeted
at
placement,
but
I
could
see
it
being
expanded
and
probably
the
same
argument.
I
think
the
only
thing
is
like
placement
is
the
only
one
so
far.
E
We've
said
oh
well,
it
might
make
sense
to
have
a
placement
apply
to
multiple
resources
and
just
larger
to
do
so.
I,
don't
think,
there's
any
concern.
You
know
with
an
override,
that's
specifically
tied
to
a
single
resource
like
that,
should
just
work
but
I'm.
Sorry,
Greg,
we're
getting
away
from
your
question.
I
want
to
make
sure
that
you're
satisfied
with
the
answer,
or
you
know.
D
E
So
I
I'm
thinking
I
mean
I
I
commented
on
the
doc
and
hopefully
we
can
get
feedback
from
Turin,
but
maybe
it
makes
sense
to
have
kind
of
two
flavors
where
you
know
you
can
specify
a
selector
or
an
object.
Reference
like
one
or
the
other
and
at
least
gives
a
little
bit
more
specificity
and
less
room
for
error.
E
If
you
don't
so,
a
selector
allows,
you
to,
you
know,
apply
to
multiple
resources,
but
then
it
you
know
if
it's
label
based,
then,
if
a
user
has
access
to
the
research,
they
can
change
the
labels
and
effectively
change
how
the
policies
apply.
But
if
it's
a
direct
object,
reference
and
the
user
doesn't
have
the
ability
to
change
the
placement
like
it's
they're
not
allowed
to
do
that,
then
they
wouldn't
be
able
to
override
or
change
the
administrative
intent.
Does
that
make
sense?
Well.
E
Kind
of
is
I
mean
we're
not
really
I,
think
that's
kind
of
a
separate
discussion
we
kind
of
want
to
enable
you
want
to
enable
administrators
to
apply
our
back
policy
to
this
API
in
a
useful
way.
We're
not
really
digging
into
it
yet
because
we
kind
of
want
to
nail
down
what's
required
to
just
drive.
You
know
the
whole
thing,
but
it
is
certainly
in
our
we
want
to
be
able
to
have.
E
E
Or
right
I
mean
the
mandatory
would
be
the
mandatory
nature
would
simply
be
an
admission
controller.
That
was,
you
know,
being
like
configured
via
policy
to
apply
certain
placement
directives
and
then
the
mandatory
would
be
preventing
like
anybody.
But
someone
who
is
an
administrator
from
changing
that
and,
like
I
said
it's
it's
kind
of
out
a
band
from
what
we're
talking
about
here.
The
only
real
concern
is:
if,
if
the
Association
is
be
a
selector,
then
it
might
not
be
capable
of
forced
so.
C
One
question
that
I
have
and
I'm
curious
to
know
if
anybody
off
on
this
call
happens
to
know
the
answer
to
this
is
whether
so
I
believe
in
the
current
Federation,
the
policy
integration
is
implemented
as
an
admission
controller.
Does
the
admission
controller
ever
reject
things
and
say
the
policy
forbids
you
from
placing
this
workload
where
you
said
it
should
be
placed.
A
C
A
C
F
Like
that
I
had
a
quick
comment
about
the
water
we
want
to
deal
with
next
I
was
going
to
suggest
that
we
try
and
at
the
appropriate
time.
So
at
some
point,
we're
going
to
feel
like
we've
got
a
reasonable
consensus
of
the
overview,
these
boxes
on
the
diagram,
etc,
and
perhaps
the
granularity
of
the
API,
etc
and
I
think
it
would
be
really
useful
to
be
able
to
carve
off
pieces
that
we
can
actually
make
a
semi
final
decision
on.
F
So
people
can
start
coding
without
having
the
risk
of
us
coming
back
and
saying:
oh
we've
changed
our
minds
on
that
and,
and
the
other
failure
mode
might
be
that
we
just
keep
on
talking
about
these
things.
Until
we've
reached
consensus
on
every
little
detail
before
we
can
start
writing
code.
So
there
was
a
long
run.
The
quiet
way
of
saying
I
think
we
should
prioritize
like
carving
up
pieces
that
can
be
done
soon
and
get
going
on
them.
Yeah.
C
I
think
that's
a
very
good
point.
Quentin
one
thing
that
comes
to
mind
as
immediately
actionable
would
be
like
status.
I,
don't
I,
don't
think
you
need
like,
like
status,
could
very
well
be
useful
in
a
independently
of
all
of
the
rest
of
this
stuff,
and
I
also
will
just
share
that,
like
I,
think
I.
Think
iteration
is
king
and
I.
C
So
there
shouldn't
be
anything
really
standing
in
our
way
from
trying
to
see
what
do
these
things
look
like
if
we,
if
we
get
try
to
do
like
a
very
simple
limited
implementation
scope
to
like
secrets,
config
map
and
deployments
for
example,
or
secrets,
config
map
in
replica
set
I
I
personally
have
spent
a
lot
of
time
in
the
last
like
15
months
or
so
feeling
in
another
problem
domain
like
I,
was
blocked
by
analysis
paralysis.
A
lot
of
the
time,
so
I
am
all
about
trying
to
make
progress
by
iteration
and
I.
C
C
So
we're
almost
at
time
for
today,
one
thought
I
have
had
is
that,
like
if
people
are
really
interested
in
making
rapid
progress,
we
probably
ought
to
talk
more
frequently
than
once
a
week.
I
would
I'm
actually
going
to
be
traveling,
I
think
next
Monday.
But
how
do
folks
feel
about
having
another
session,
maybe
sometime
in
the
next
week
before
the
next
working
group
meeting?
If
we
want
to
try
to
identify
areas
to
prototype.
C
A
And
before
we
break
out,
I
was
listening
to
all
this
conversation
about
the
functional
blocks
or
whatever
does
it
make
sense
to
segregate
these
in
something
light,
which
is
a
static
information
and
other
is
something
which
is
dynamic
or
live.
For
example,
scheduling
is
already
secluded
out
that
it
is
dynamic.
I
think
propagation
also
has
some
where
there
could
be
a
active
reconcile,
stuff
or
actual
controller
which
is
looking
for
objects
in
the
cluster
and
reconciling
the
detail,
or
it
might
be
one
time
capacity
will
apply
kind
of
stuff.
A
E
E
So
separating
out
like
specifications
from
controllers
and
controllers,
having
like
different
types
like
make,
you
say
likes
being
doctor
reconciler
versus
just
generating
configuration.
Those
are
definitely
sort
of
different
areas
of
if
you
worked
in
independently.
That's
what
you're
talking
about
okay.