►
From YouTube: Kubernetes Federation WG sync 20180221
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
So
last
three
meetings:
we
actually
have
been
talking
about
placement
I'm,
not
sure
if
we
have
a
real
resolution
for
the
same
in
terms
of
the
API
I,
try
to
update
something
something
as
a
as
something
which
can
have
us
move
forward
as
an
example
in
the
agenda
notes.
A
B
Think
I
think
that's
kind
of
will
similar
to
my
thinking.
I,
don't
know
that
there's
a
point
in
having
a
cluster
placement
thing
like
just
a
list
of
clusters
should
be
enough,
but
the
idea
that
there's
an
authoritative
list
of
clusters,
I
was
kind
of
wondering
they
should
be
on
the
resources
separate,
but
it
probably
should
just
be
on
and
any
sort
of
higher-level
mechanisms
for
determining
placement
can
just
boil
down
to
the
he
kind
of
provides
a
easy
integration
point
for
any
other
way
of
determining
where
things
should
go.
Correct.
A
Only
only
issue
I
think
I,
just
admitted
before
the
meeting
I
see
that
this
is
that
we
we
have
discussed
about
different
users
or
different
access
level,
users
expressing
intent,
and
if
our
back
control
the
resources
are
there
which
can
mitigate
that,
then
it
is
fine.
Otherwise,
it's
sort
of
a
Penticton
resolution
would
be
one
resolution,
so
both
men,
user
and
a
normal
user
can
update
the
same
field
which
does
not
release
all
what
probably
not
you
mentioned.
You
know,
thinking
by
having
our
tech
base
the
access
control.
B
B
Unless
we
have
an
admission
controller,
which
is
possible
I
guess
like
maybe
at
some
point
we
can
explore
whether
controlling
access
to
the
field
level
with
an
admission
controller,
is
preferable
to
having
to
maintain
a
separate
resource
that
is
administrative
or
viajar
back,
but
I
mean
there
I,
don't
I,
guess
I.
All
I
would
say
is
that
I
don't
really
have
a
good
sense
of
which
is
preferable,
but
both
are
possible.
So
I
don't
think
doing.
This
precludes.
C
D
D
D
Yeah
I
I
have
I
share
your
thoughts.
I
think
it's
possible.
I
have
some
concerns
that
if
we
choose
to
put
them
inside
the
object
too
soon
becomes
easier
or
more
difficult
to
call
them
out
later
or
is,
if
we
choose
to
put
them
outside
the
object
to
start
with,
and
then
only
promote
things
into
the
primary
object
once
we're
kind
of
sure
that
we
got
it
right
a
bit
like
the
arguments
around
status,
I
think,
which
we
also
said.
Well,
you
know,
there's
different
kinds
of
statuses
and
we're
not
quite
sure
what
we
want.
D
C
B
Have
a
slightly
different
view,
I
think
in
the
case
of
status,
where
there's
some
question
as
to
what
ultimately
users
are
going
to
want
I
think
in
this
case
we
need
a
list
of
clusters
indicating
which
clusters
this
research
should
go
into.
So,
to
my
mind,
it's
less
about
kind
of
credit,
typing
different
forms
know
what
we
want.
I
think
the
this
is.
This
is
the
fundamental
primitive
of
deciding
on
placement,
how
you
arrived
at,
that
is
completely
variable
and
having
it
outside
that
users
make
sense
to
me.
B
The
question
here
is
a
little
bit
different,
because
it's
really,
how
do
we
want
to?
How
do
we
enable
protection
of
that
data
mission
controller
if
it's
in
the
resource
to
the
our
back
or
something
else?
So
there
would
be
an
admission
controller
if
it's
outside
the
resource,
so
I'm
not
saying
that,
like
there
isn't
value
to
having
it
outside,
just
that,
it's
a
slightly
different
area.
Yeah.
D
Yeah
I
can
I
can
buy.
That
argument.
I
think
I
think
there
are
potential
implementations
where
this
stuff
is
not
actually
persisted
anywhere
and
doesn't
even
feature
in
the
API,
for
example,
cases
where
the
user
isn't
allowed
to
specify
precisely
which
clusters
they
want
to
stuff
in.
They
can
only
specify
you
know
cluster
selectors
and
then
policy
and
availability
and
other
things
determine
where
they
end
up
and
where
that
is
bundled
in
with
the
so,
where
the
scheduling
and
propagation
might,
for
example,
be
bundled
into
some.
D
Consolidated
controller,
it
may
well
be
that
it
doesn't
explicitly
expose
that
information
and
so
having
it
mandatorily
part
of
the
object
might
not
be
what
we
end
up
wanting
in
the
future.
So,
for
example,
today
that
is
the
case
so
that
the
controller
doesn't
actually
explicitly
persist
anywhere,
where
it
decided
to
put
the
objects.
D
C
B
I
I:
don't
really
think
that
the
issue
is
experimenting
with
different
flavors,
it's
more
just.
Maybe
you
want
it
written
down.
Maybe
you
don't,
but
I
guess:
I'm
I
can
make
sense.
Well,
both
of
you
were
saying,
make
sense.
I
mean
I'm
kind
of
like
I,
think
having
an
authoritative
form
for
our
placement.
Like
just
a
list
of
clusters
when
I
say
placement,
everybody
like
list
of
clusters
to
me
is
just
the
primitive
that
any
placement
determining
mechanism
would
boil
down
to
for
the
propagation.
If
there
was
to
be
some
sort
of
shared
causation
mechanism.
D
Be
care
I
totally
see
your
side
of
the
argument
as
well
and
I'm.
You
know
not
saying
we
won't
end
up
with
the
stuff
in
the
objects,
but
it
doesn't
feel
like
we
know
exactly
what
it
should
look
like
yet
or
what
our
back
rules
should
apply
to
it.
I
mean
the
other
thing
that
just
came
to
mind
actually
is
if
you
decide
that
you
want
to
put
a
bunch
of
resources
in
the
same
set
of
clusters,
again,
it's
kind
of
useful
to
have
that
outside
of
any
one
of
those
resources.
D
You
can
say
this
is
the
placement
decision.
These
are
the
clusters.
I
decided
to
put
all
of
these
different
resources
into
because
they
all
need
to
be
together,
and
that
would
be
kind
of
difficult
and
or
duplicated.
If
you
ended
up
having
to
like
copy
that
information
into
every
one
of
those
objects
individually,
I'm
not
saying
that's,
you
know
the
only
or
best
implementation
I'm
just
saying
that
we
would
have
that
possibility
if
we
kept
it
outside
and
we
went
kind
of
preclude
that
possibility
of
least
stuck
it
inside
the
objects.
Now.
A
I
also
have
a
point
here
that
it
doesn't
matter,
we
keep
it
inside
the
object
or
outside,
but
what
I
am
looking
at.
It
is
at
one
authoritative,
one,
authoritative
information
which
can
reflect
the
current
state
of
the
object
or
current
state
of
where
the
object
is
plates
based
on
how
it
should
be.
Probably
a
controller
hasn't
seen
the
move
to
transfer
the
object
to
a
cluster.
A
But
this
is
what
the
controller
should
do,
what
it
could
be
compared
with
respect
to
the
Preferences
annotations
that
we
use
against
particular,
for
example,
applica
set
object
in
v1
Federation,
so
if
you
update
it
or
anybody,
for
example,
a
controller
itself
updates
it
or
a
user
updates
it.
But
it's
one
information
of
one
set
of
information
which
is
being
updated.
It
could
be
inside
the
object
or
outside
the
object,
but
it
should
be
a
one-to-one
information.
That's
what
I'm
trying
to
illustrate
here.
A
C
I
do
want
to
point
out,
though,
that
like,
if
you
want
to
express
some
notion,
that's
like
here
are
the
weights
across
these
clusters
in
the
schemes
that
we've
been
talking
about
so
far,
those
sound
to
me
like
higher
level
things
that
program,
the
primitives
and
the
I
think
we're
still
at
the
stage
now,
where
we're
trying
to
find
what
the
right
primitives
are.
So
we
should
remember
that
higher
level
things
are
gonna
program,
these
most
likely
yeah.
D
I
was
gonna,
make
a
similar
Khan
comment
and
I'm,
not
even
yet
convinced
that
the
record
of
where
a
an
automated
scheduler
flic
decided
to
place
a
set
of
objects
need
be
the
same
as
the
place
where
we
record
that
a
user
wants
to
put
a
set
of
objects
into
a
specific
set
of
clusters.
And
then
it
might
sound
little
bit
kind
of
pedantic.
D
But
the
kind
of
API
that
you
would
want
to
expose
to
user
would
probably
use
things
like
cluster
names
and,
or
you
know,
labels
on
the
cluster
saying
you
know
cluster
a
cluster
because
to
see
where,
as
a
lower-level,
primitive
might
actually
use
like
new
IDs
and
have
very
specific
in
representations
which,
which
would
you
know,
be
suitable
for
consumption
by
a
propagator,
for
example,
but
may
not
be
suitable
for
expression
by
a
user.
Yeah.
A
Yeah,
what
I
mean
to
say
is
like,
as
all
you
mention,
that
it
is
like
two
different
levels
of
limited,
so
the
high-level
ones
can
probably
program
the
simpler
ones
too.
So
the
simplest
form
is
what
I
am
looking
at,
which
should
be
one
or
we
can
decide
that
simplest
form
is
sort
of
a
level
above
in
hierarchy
rather
than
having
just
the
question
is
as
the
simply
simplest
form,
but
probably
the
simplest
form
should
be
one
and
that
maybe
can
be
programmed
by
rest
of
the
high
level
primitives
and
all.
A
D
Yeah
make
sense:
where
do
we
think
we
want
to
put
things
like
replica
counts,
I
mean,
presumably
once
the
schedule
of
being
a
human
or
a
piece
of
software
has
decided
to
propagate
something
into
a
bunch
of
clusters.
In
many
of
the
interesting
cases,
it
has
something
like
a
replica
count
associated
with
it,
like
a
specific
number
of
replicas.
D
This
is
that
is
that
status,
or
is
that
the
other
calling
of
a
scheduling
decision
I
mean
in
either
case
it
seems,
like?
We've
already
decided
that
birth
status
and
output
of
a
scheduling
decision
should
not
be
part
of
the
object.
My
question
is
this
cluster
placement
thing
that
you
have
highlighted
on
the
screen
here.
That
is
presumably
the
output
of
a
scheduling
decision,
be
that
yeah.
A
D
But
but
that
so
we
when
I
said
part
of
a
scheduling
decision
that
might
have
been
a
human
who
made
that
the
scheduling
decision
but
I
guess
my
point
is:
do
we
keep
it
that
simple,
so
I
said
so?
First
of
all,
I
think
we
we've
already
decided
that
what
you
have
highlighted
at
the
moment
is
it's
not
part
of
the
object.
So
in
the
previous
discussion,
you
just
decided
to
keep
it
outside
of
the
object
for
a
variety
of
reasons.
D
So
the
second
question
is:
do
we
have
a
very
simple
one
like
that
that
only
has
clustered
names
and
would
be
useful
for
a
limited
set
of
objects
like
secrets
of
conflict
maps
and
whatever,
but
would
not
be
useful
for
replica
sets,
for
example,
where
you
would
have
to
have
a
specific
set
of
replicas
who
recorded
some
more
have
maybe
have
that
in
a
separate
object,
or
do
we
put
that
in
this
common
I?
Think.
A
C
C
A
There
are
two
things
that
we
are
discussing
about
right,
so
I,
remember
remember.
This
has
been
discussed
earlier,
so
there
is
a
federated
version
of
the
replica
section
and
that
this
is
just
like
a
replica
set
specifies
the
prototype,
because
the
federated
version
of
the
replica
site-specific
can
specify
the
total
replicas
and
leave
partial
replicas
completely
optional,
and
then
the
shell
Allah
decides
all
equal
partitioning
decides
that
X
number
of
replicas
going
to
and
template
would
give
a
preferred
number
of
replicas
per
cluster.
A
C
So
I
think
that
we
we
had
initially
sort
of
thought
of
all
of
these
is
potentially
different
resources.
I
do
think
that
there
is
potentially
a
lot
of
value
in
a
generic
concept
of
what
an
override
is
so,
for
example,
like
if
a
generic
override
was
more
like
a
patch
like
strategic
patch,
that
you
can
apply
to
an
object
that
lets.
That
kind
of
is
a
hedge
against
future
API
changes.
C
So,
for
example,
you
could
write
a
strategic
patch
that
would
change
the
replica
count
without
having
to
plumb
the
knowledge
of
like
replica
count
as
a
concept
into
that
object
that
the
more
that
we
talk
about
that
that
feels
like
kind
of
the
right
angle,
to
model
overrides
on.
Does
that
answer
your
question
fun.
A
What
I
was
actually
trying
to
point
out
is
that
there
are
three
places
replicas
can
be
specified.
So,
for
example,
if
we
talk
about
a
federated
replica
set,
we
can
say
a
federated
replica
set
needs
to
have
ten
replicas
and
no
other
information
specified
right
as
part
of
federated
Topeka's
expect
itself.
Then
we
are
talking
about
cutting
a
template
for
each
replica
set
that
is
per
cluster
replica
set
inside
this
ready
to
duplicate
right.
So
there
also,
you
can
specify
the
template
replicas.
C
The
the
the
replicas
count
on
the
Federated
replicas
set
would
be
sort
of
the
template
replicas
count
and
if
you
want
to
specify
a
higher
level
concept
like
total
number
of
replicas,
that
is
that
that
would
be
specified
by
a
resource
that
can
controls
a
scheduler
that
handles
making
sure
that
the
total
replica
count
converges
on
50,
for
example,
or
10
or
whatever
does
that
make
sense.
Okay,.
D
D
It's
technically
feasible,
of
course,
I'm.
Just
not
sure
that
it's
what
anybody
will
want
I
think
most
users
will
want
to
be
able
to
be
able
to
limit
and
predict
what
they're
buying
what
they're,
what
they're
using
within
you
know.
They
might
not
want
to
specify
a
specific
number,
but
they
at
least
want
to
be
able
to
place
clear
bounds
on
it,
and
this
the
way
it
works
today
seems
like
a
pretty
clear
way
of
doing
that,
and
and
it's
consistent
with
for
whatever
it's
worth.
C
D
I
think
I
know
what
you're
saying
and
I
think
I
know
a
reasonable
potential
solution.
Okay,
so
I
think
the
two
different
classes
of
problems,
so
so
I
think
one
valid
use
case
is
I,
want
a
total
of
50,
replicas
and
I
want
to
be
able
to
that
somewhere
and
another
valid
use
cases
I
want
fifty
replicas
in
every
cluster.
I
think
the
latter
of
those
two
is
relatively
uncommon,
but
but
let's
leave
that
as
yes,
it's
a
valid
use
case
and
we
should
accommodate.
D
It
seems
like
by,
if
I
don't
care,
how
many
total
replicas
I
get
I
could
just
leave
that
out
of
the
specification
of
the
parent
of
the
schedule,
sorry
federated
replica
set
and
if
I
wanted
it
in
every
cluster,
it
seems
like
the
most
logical
place.
To
put
it
will
be
in
the
template
because
that
templates
gets
propagated
to
every
cluster
so
for
150
in
every
cluster,
then
I
put
inside
my
template.
Replicas
count
equals
50
and
I,
don't
put
anything
in
the.
D
What
I'll
call
the
parent
object
that
a
federated
replica
set
or
what
I
do
is
I
use
overrides
what
would
have
been
called
overrides
to
make
sure
that
every
time
it
gets
propagated
to
any
cluster
they
override
for
that
cluster
specifies
that
it
must
be
50
and
I
think
either
of
those
two
solutions
could
be
fine.
Does
it
make
sense.
C
So
let
me,
let
me
say
what
it
is
in
my
head
and
let
me
see
if
this
makes
sense
to
other
folks.
I
I
think
that
the
mismatch
that
we
have
on
vocabulary
is
that
when
we
have
as
I
as
I
said
a
couple
conversational
beats
ago,
that
like
in
my
own
mind
that
federated
replica
set
is
the
template
and
other
resources
for
overrides
and
other
resources
for
our
another
resource
for
overrides.
C
There's
another
resource
for
placement
and
Quinten
I
think
the
way
you've
been
thinking
of
federated
replica
set
is
as
a
scheduler
type
resource
where
you
provide.
This
is
the
total
number
of
replicas
that
I
want,
and
maybe
you
can
say
as
part
of
that
and
spread
it
across
these
clusters,
maybe
with
weights
but
I.
Think
I.
Think
the
mismatch
is
one
that,
like
we've,
been
using
the
same
word
to
refer
to
constant
concepts
that
are
at
different
levels.
Does
that
make
sense.
D
Yeah
I
guess
I
guess
my
confusion
is
when
you
say
federal
replicas
said
is
a
template.
It
has
a
thing
explicitly
called
a
template
inside
it
and
then
it
has
stuff
outside
of
that
template.
Does
that
make
sense?
Yes,
so
maybe
whoever's
projecting
here?
Could
you
scroll
up
to
the
thing?
That's
called
a
federated
grip
like
a
certain
there.
We
go
I
want
yeah
somewhere
on
there.
D
D
So
I
think
it's
worth
getting
to
the
bottom
of
of
this
and
coming
to
some
common
understanding,
so
I,
my
preference
for
this
thing
that
is
on
the
screen
in
front
of
us
and
it's
explicitly
called
a
template,
is
that
bears
a
strong
resemblance
that
to
what
actually
gets
propagated
into
each
cluster
after
some
override
process.
So
some
information
in
that
template
gets
fairly
mechanically
overwritten
by
some
template
mechanism
or
some
override
mechanism
and
then
gets
propagated
to
the
cluster.
But
outside
of
that
there
is
other
user
requirements.
D
For
this
thing
and
one
obvious
potential
one
would
be
the
total
number
of
replicas
now
that
need
not
be
in
this
federated
replica
set
object.
It
may
be
somewhere
else,
for
example,
we've
specified
I
think
like
propagation
preferences
or
gauging
preferences
or
whatever
and
I'm
totally
fine.
With
that
and
I
think
some
of
these
things
we
might
put
inside
this
federated
replica
set
object,
but
outside
of
the
template
and
others,
we
might
factor
out
into
separate
objects
like
scheduling,
preferences,
etc.
A
This
thing
is
I
mean,
as
for
the
document,
I
think
that
was
understanding
that
you
rotated,
that
total
number
of
replicas
can
be
specified
as
an
addendum
kind
of
a
thing,
an
additional
in
information
lack
of
which,
for
example,
what
we
are
thinking
is
that
only
if
only
the
federated
API
object
is
specified,
then
it
should
be
sufficient
for
an
implementer
to
ensure
that
some
form
of
some
form
of
distribution
or
replication
across
all
clusters
can
happen
and
rest
of
the
other.
For
example,
placement
or
shine.
B
B
A
scheduler
may
not
actually
have
the
ability
to
control
a
number
of
replicas
for
some
people
that
might
be
sufficient
because
they
have
a
small
number
of
clusters
and
it
doesn't
vary
dynamically
right
and
if
I
have
a
higher
order
use
case
where
I'm
actually
going
to
require
scheduling
and
I'm
gonna
have
to
worry
about.
You
know
if
I
add
on
the
clusters,
is
my
replica
count
gonna
balloon
because
I
haven't
set
it
up
with
downs
on
it.
You're
gonna
have
a
scheduler,
so
you
need.
C
B
Use
cases
and
they're
there
layer
alone
as
long
as
you
keep
the
things
separate
as
soon
as
you
start
putting
everything
everywhere,
it's
like
what's
what's
responsibilities
and
if
I'm
not
using
a
scheduler.
What
is
this
to
me?
It
gets
confusing
for
the
simple
cases
and
then
it's
kind
of
a
balance
because
it's
kind
of
like
well.
If
we
don't
put
it
there,
that
it's
more
complicated
for
the
more
complex
use
cases,
but
I
would
argue
keeping
things
as
simple
as
possible
is
preferable.
B
C
A
If
you
look
at
it
from
this
point
of
view
and
want
to
adjust
that
more
prominently,
then
I
guess
I
guess
the
point
that
I
am
making
holds
more
weighted.
Whereas
if
you
talk
about
the
segregation
of
concerns
and
completely
delineating
the
scheduling
concern
from
the
specification
all
the
templating
concern,
then
I
think
you
are
right
about
it.
So.
D
B
D
B
D
D
B
D
And,
and
that
might
be
an
argument
for
Murray
the
argument
you
just
made,
which
is
that
the
the
template
is
precisely
the
fields
in
the
template,
are
precisely
defined
by
what
a
kubernetes
replica
said
is
so
we're
not
even
gonna
argue
about
what's
in
there
and
what's
out
of
there
it's
exactly
it
could
be
Nellie's
replica
set,
in
which
case
you
know.
Arguably
that
comment
at
the
top
that
says:
there's
no
correlation
between
a
version
of
a
federated
resource
type
and
its
kunos
equivalent
is
maybe
not
valid.
D
B
D
C
I,
can
I
interject
quickly,
so
here's
the
mismatch
that
I
think
that
we've
been
having
actually
there's
two
parts,
so
one
the
Spector,
replicas
I
think
should
come
out
of
this
document
and
that's
the
first
part.
The
second
part
is
that
the
primitives
er
templates
are
Reds
and
placement
and
when
I'm
gonna
since
I
have
red
hair.
At
this
moment,
I'm
gonna
use
red
marker
to
represent
my
brain
and
when
I've
been
talking
about
federated
replica,
set,
I'm
thinking,
template
right
and
I.
C
Think
quittin,
an
orphan
well
I
want
to
speak
for
everybody.
I
think
Quentin
has
been
describing
his
I'm
gonna
put
putting
in
blue,
because
I
think
you're
wearing
a
blue
shirt
in
your
in
your
avatar
on
slack.
So
when
Quentin
has
been
describing
better
a
to
replicate
a
set
that
it's,
this
higher
level
thing
here
and
I
think
you
can
totally
build
a
resource
like
this.
C
That
would
have
the
template
and
it
would
have
the
total
replica
count
and
maybe
some
other
information,
while
my
preferences
or
weights
and
a
controller
watches
this
resource
and
creates
these
primitives.
So,
in
my
mind,
that
means
that
we
don't
actually
have
Quentin.
It
was
white.
Your
shirt
is
white,
but
I
don't
have
a
white
marker,
so
okay,
I,
don't
think
we
actually
have
that
much
of
a
mismatch.
D
D
D
B
B
So
the
fact
that
it
breaks
those
things
out,
it's
almost
like
the
things
at
the
bottom.
Those
are
the
primitives
we
need
to
Cabrini's,
but
I,
don't
understand
what
the
controllers
doing
to
create
them.
I
kind
of
see
them
as
being
again
at
CD
red
by
a
controller
and
then
Gannett
listed
cluster
is
figuring
out
what
resource
to
put
in
which
clusters.
D
D
Now
because
we
can't
come
to
conclude
agreement
will
have
not
yet
come
to
agreement
on
what
as
status,
scheduling,
preferences,
overrides,
etc,
etc.
Look
like
for
any
given
type.
We've
decided
to
pull
these
out
in
two
separate
things
and
we've
created
a
separate
API
object,
called
federated
replica,
set
scheduling,
preferences
or
whatever
it's
called,
and
status,
etc,
etc.
But
I,
don't
think
I
think
there's
all
still
basically
clustered
around
this
central
concept
of
a
federated
replica
set.
D
B
D
C
C
D
A
C
Into
this
one
I
thought
of
it
more
as
like.
This
might
be
a
view
that
you
provide,
or
a
virtual
resource
or
something
else
where,
like
a
particular
opinionation
of
how
these
should
relate
to
together,
is
encapsulated
so
that
if,
if
I
come
in
and
I'm
like,
you
know
again,
there's
a
template
here.
I
get
that
there's
a
total
replica
count,
but
I,
don't
like
this
I,
don't
like
that.
That
I
can
make
my
own,
like
Paul
replica
set
that
has
the
exact
stuff
that
I
want
that
differently.
Programs.
These.
B
B
B
B
An
ad
placement
could
be
agnostic,
but
the
requirement
for
federating
something
would
be
I,
have
a
resource
and
then
I'll
create
a
federated
version.
That
includes
that
as
a
template
and
then
I
will
either
you
know,
provide
an
adapter
into
the
existing
State
Controller
I'll
write
my
own
controller
to
figure
out
how
to
treat
those
resources
in
relation
to
the
clusters,
the
department
Federation,
and
so
the
idea
does
that
make
sense.
Yeah
I'm.
B
B
Their
special
case,
if
you
had
a
new
type
that
needed
to
be
scheduled,
you'd,
have
to
implement
support,
for
that
might
be
a
scheduling.
Preferences
you'd,
have
to
add
support
to
a
scheduler
to
know
what
to
do
with
it.
How
to
treat
the
underlying
resources
like
there
there's
when
there's
kind
of
the
general
case,
where
I'm
talking
about
simple
propagation
and
I
don't
mean
to
do
scheduling,
I,
don't
need
to
figure
out.
B
You
know,
clusters
specific
overrides
on
resource
specific
basis,
and
that
can
be
you
know
we
could
probably
have
cogeneration
to
cover
that
case
when
it
comes
to
scheduling
I,
don't
think
there
is
any
general
purpose
solution
for
that,
at
least
not
in
my
experience
like
working
with
you
know,
replica
sets
deployments
jobs
HPA.
Those
all
seem
to
be
special
cases
that
require
special
support.
D
A
A
D
D
Overrides,
etc,
and
then
the
thing
on
top
of
that
which
you
drove
through
at
the
top
right-hand
corner
is
the
interchangeable
thing,
and
that
is
you
know
you
can
build
higher
levels
on
top
of
those
primitives,
but
the
primitives
are
relatively
well
defined
and
Static.
My
thinking
I
think
was
the
other
way
around,
which
is
that
the
thing
at
the
top
is
kind
of
well
defined,
maybe
not
the
internals
of
it.
D
C
B
My
conception,
like
in
terms
of
the
primitives
I,
think
having
a
canonical
representation
of
over
eyes
and
a
canonical
representation
of
placement,
and
you
know,
as
we've
discussed
just
a
list
of
clusters
and
the
canonical
representation
of
like
the
base
template
to
me.
That's
kind
of
the
core
of
it,
whether
or
not
it's
represented
in
resources
or
not
just
having
the
conception
I
mean
my
my
idea
is,
if
you
had
you
know
overrides.
However,
you
just
one
way
to
do
it
and
placement
one
way
to
do
it.
B
Whether
it
be
like
selector
based
placement
or
selector
based
overrides,
like
things,
it
could
be
whatever
people
walk,
but
if
it
was
so
it
all
boiled
down
to
that,
then
you
wouldn't
have
to
change
your
propagation
mechanism
to
support
some
new
way
of
defining
a
higher
order.
Definition
of
these
concepts
right.
B
B
A
B
I
guess
the
only
difference
for
me
is
when
you
talk
about
a
template,
I
think
a
federated
resource
that
contains
like
template
field.
To
me,
that
kind
of
is
the
template
and
I.
Don't
really
see
much
value,
you
varying
not
like
I'm,
not
saying
someone
couldn't,
but
to
me
that's
kind
of
a
base
primitive
that
we
wouldn't
really
change
in
the
same
way
of
it
like
overrides
placement
would
be
base
permit.
Ups,
so
template
to
me
is
federated
replicas
are
federated
whatever
if
it
can't
be
type
agnostic,
the
other
two
baby
Kathy
you.
C
B
C
It
was,
it
was
something
I
draw
on
the
board
and
we're
trying
to
like
draw
the
primitives
and
then
add
higher-level
concepts
and
see
where
they
fit
on
the
diagram
and
I
was
trying
to
figure
out
where
I
thought
templates
should
actually
go.
Is
the
primitive
or
is
it
a
higher
level
thing
and
I
realized?
C
Now
that
we're
actually
talking
through
this
very
question,
so
I
I
think
that
I
would
be
okay
if
template
is
not
the
distinct
thing,
if
we
want
to
just
say
that
federated
replicas
set,
for
example,
is
the
template-
and
maybe
we
like
can
eventually
fold
some
additional
notions
into
that
I.
Think
that's
totally
fine
I.
D
I
have
some
concerns
about
that,
because
I
think
we're
just
skirting
what
is
a
fundamental
kind
of
disagreement
on
things
in
the
sense
that
I
think
we
have
this
notion
of
a
federated
replica
set,
which
is
you
know
the
collective
thing
that
we
can
propagate
into
optical
clusters
and
I.
Don't
think
that
is
the
template
that
is
used
to
generate
the
thing
into
the
clusters.
I
think
those
are
two
different
things
and
I
don't
want
us
to
confuse
so
I
would
rather
be
very
explicit
and
and
actually
have,
and
we
can.
D
We
could
just
as
well
use
the
kubernetes
api
itself
and
say
you
create
a
replica,
and
you
say
this
is
the
replica.
So
it's
got
all
the
spec
fields
and
everything
else
that
a
normal
curve
in
that
is
one
has.
And
if
you
want
to
propagate
something
like
that
into
more
than
one
clusters,
you
can
just
research
it
by
name
and
that's
that's
that
that
is
your
template.
And
then
you
have
this
other
thing,
which
is
to
say
I
want
to
propagate
that
thing
into.
D
It
does,
but
it
contains
a
lot
more
than
that,
conceptually
and
and
that's
what
I
want
us
to
be
very
clear.
So
if,
if
in
your
mind,
it
is
just
the
template,
then
I'd
rather
just
call
it
a
template
and
put
it,
and
if
you
don't
like
it
being
I
mean
right.
Now
it
is,
is
a
Field
Op.
Federated
replica
set
is
called
template,
and
that
is
what
I
believe
to
be
the
template,
but
I
believe
there's
a
head,
a
lot
of
other
stuff.
B
D
B
D
Murray
I,
just
I,
just
had
a
thought
which
I
helped,
which
I
hope
might
clarify
things.
If
I
could
just
say
that
quickly,
it
might
help
a
lot.
So
in
kubernetes
we
have
a
replica
set
right
and
it
has
a
bunch
of
properties
like
how
many
replicas,
complement
or
maybe
deployments
better
exampled
has
how
it
gets
rolled
out,
all
those
things
and
inside
it.
B
So
as
it
just
levels
of
abstraction
like
the
overrides
and
the
placement
or
related
to
the
federated
replica,
set
ie
they're
agreeing
things
as
a
whole
versus
applying
specifically
to
the
template
like
exactly
right,
I
agree
with
on
I'm,
not
actually
sure
what
question
you're
answering
though
I
mean
it
I
totally
agree
with
it,
but
I'm.
There's.
D
What
I'm
stirring
is
that
I
want
to
make
sure
that
we
don't
have
something
which
we
call
a
federated
replica
set,
as
in
the
document
explicitly
today
and
the
field
in
inside,
there
called
the
template,
which
we
explicitly
have
in
the
document
which,
if
you
look
at
kubernetes
replica,
set
or
deployment
they're
different
things.
They
mean
very
clear
things
and
in
my
mind
they
had
meant
very
clear
things
in
our
discussions.
But
Paul
is
I.
Think
of
the
opinion
that
they
mean
the
same
thing.
So
just
conflating.
B
Think
we
I
think
I
guess
I
can
see
your
concern.
I
mean
today
because
of
this
desire
to
break
things
apart.
There
has
been
you
know
all
of
federated
route,
because
that
contains
at
the
moment
in
the
prototype
I've
been
working
on,
is
a
template
so
calling
it.
The
template
is
like
a
shorthand
for
the
thing
that
carries
the
template,
but
I
think
I,
don't
think
I'm
confused
about
the
fact
that
a
federated
replica
set
really
is
the
federated
replica
set
overrides
and
placement.
B
C
C
B
Sense
I,
my
concern
would
be
that
I
think
initially,
the
goal
is
to
break
things
apart
to
allow
sort
of
experimentation
but
I
write.
Do
you
take
the
point
that
at
some
point,
if
we
determine
that
a
specific
form
would
be
easier
for
these
are
easier
to
maintain
easier
to
document?
You
know
collapsing
things
together,
I
think
naming
a
template
kind
of
fixes
it
in
place
and
says
this
is
the
template
and
that's
all
it
ever
is
and
I
think
it
could
potentially
be
more
I
guess
like
to
be
the
overrides.
B
B
Like
I
said
via
selectors
is
the
example
that
I
come
up
with,
but
in
terms
of
like
what
specific
values
specific
clusters
are
going
to
get,
it
seems
like
a
property
of
a
federated
replica
set,
but
I'm
not
I'm,
not
saying
we
need
to
do
that
immediately.
I'm,
just
saying
like
we're
doing
this
separate
and
then
we'll
see
where
it
makes
sense
to
collapse,
it
down
we're
denormalizing
and
maybe
it
makes
sense
to
normalize,
for
you
know,
usability
or
performance
or
any
other
thing.
I
just
prefer
to
avoid
sort
of
fixating
on
its
current
form.
D
I
would
be
more
in
favor
of
actually
pulling
the
thing
that
is
currently
called
template
out
of
there
and
explicitly
calling
it
replica,
set
template
and
having
it
be
precisely
the
same
schema
as
a
kubernetes
replica
set,
and
then
we
can
have
their
confusion
and
then
it
will
never
get
any
fields
other
than
what
is
in
a
kubernetes
replica
set,
and
everything
else
goes
in
this
parent
object,
which
I
would
propose.
We
call
federated
replica
set
which
which
does
all
of
the
things
that
maroon
justice
bribed
and
then
we
can
have
no
misunderstandings.
I
think.
C
I
think
that
sounds
very
reasonable
if
it's
better
to
call
it
replica
set
template.
That's
fine
in
my
mind,
that's
kind
of
what
the
thing
I've
been
thinking
of
is
and
I
I
think.
Actually
we
don't
really
have
a
mismatch.
We
just
had
a
mismatch
on
vocabulary,
because
I
basically
agree
with
when
everybody
else
has
said.
C
I
I
do
think
that
the
these
primitives
as
distinct
things
are
very
useful,
so
that
if
someone
is
like
hey
I,
don't
I
don't
like
something
about
what
federated
replica
set
is
I
can
build
another
flavor
of
it
without
reinventing
all
of
the
rest
of
the
stack,
but
I
have
absolutely
no
qualms
in
a
vacuum.
If
we
have
like
a
high
degree
of
consensus
about
what
we
think
federated
replica
set
looks
like
that,
we
should
have
that
that
we
could
have
an
object
that
has
those
elements
in
one
place.