►
From YouTube: Kubernetes Federation WG sync 20180226
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
A
A
B
A
So
I
think
one
thing
that
came
out
of
the
last
discussion
was
that
Paul
and
Maru
I
certainly
have
a
totally
common
understanding
of
things
around
the
vocabulary.
What
a
federated
replica
said
actually
was:
did
you
guys
manage
to
talk
about
that
any
further
after
the
last
meeting,
Mary.
B
A
So
where
do
we
want
to
take
the
discussion
from
here?
So
it
seems
like
barring
the
what
may
be
a
vocabulary:
confusion
at
the
end
of
the
last
meeting.
It
seems
we've
got
reasonable
consensus
on
the
sort
of
breakdown
of
functionality
and
terminology
and
from
what
I
understand
Maru,
you
have
some
basic
code
that
that
at
least
provides
placeholders
for
the
various
API
types
that
we
have
roughly
agreed
upon.
B
Am
not
entirely
I
think
there's
some
still
some
open
questions.
Okay,
that
I
think
need
a
little
bit
of
further
discussion.
Some
of
them
are
simple.
Some
of
them
are
not
so
simple
when
we
started
two
simple
ones:
yeah,
it's
a
good
idea.
B
So
when
I
was
thinking
about
having
separate
resources,
this
is
problematic
from
a
propagation
perspective,
as
if
it's
a
single
resource,
then
I
know
that
I
have
all
the
information
I
need
to
propagate,
but
if
I
have
multiple
resources,
how
do
I
determine
that
the
the
state
in
the
system
is
complete?
Yes,
agreed
a
simple
like
sort
of
base
solution,
for
this
would
be
that
you
haven't
really
discussed
about
a
say,
a
federated
replica
set
having
references
to
placement
or
overrides
it's
just
kind
of
being.
There's
going
to
be
some
sort
of
associativity.
B
The
weak
associativity
to
me
is
kind
of
a
problem,
and
one
way
of
solving
that
most
things,
the
best
solution
would
be
having
object.
References
on
the
federal
graph
of
a
set
I'm
using
replica
set
just
example
to
apply
to
any
federated
type,
so
you'd
have
like
preference
ref,
and
it
would
be.
You
know
of
local
object,
graph
type,
which
rely
to
vary
the
kind
in
the
case
of
people
wanting
to
use
different
kinds
and
similarly
for
overrides,
and
maybe
even
for
scheduling
preferences.
It's
not
something
you
want
to
do.
B
Maybe,
as
Paul
should
probably
be
here
to
defend
not
having
this
strong
associativity,
because
it
implies
putting
putting
like
saying
out
that
this
this
generated
replica
set
will
always
like
it
has
these
fields,
whether
they
used
or
not,
which
is
potentially
something
we've
been
trying
to
avoid.
But
yeah
anybody
else
have
any
ideas
about
how
to
avoid
the
of
coordinating
across
types
other
than
stronger
societal,
yeah.
A
I
mean
I
I,
totally
agree
with
you
regarding
the
problem
statement
and
I
mean
one
way
of
doing.
It
is
just
to
ignore
that
and
say
well,
when
someone
creates
a
replica
set,
we
just
do
with
it.
Whatever
is
specified
in
terms
of
whatever
you
know,
scheduling,
preferences
or
overrides,
or
anything
else
are
currently
specified
and
if
that
set
changes,
if
the
user
is
like
in
the
middle
of
setting
all
of
the
plumbing
up,
then
we
just
sort
of
redo
it
again,
but
but
it's
pretty
messy
in
it
and
I.
A
Don't
really
think
that's
a
good
solution,
so
I
think
that
the
main
thing
that
you're
trying
to
solve
if
I,
can
kind
of
rephrase
its
the
problem
slightly-
and
maybe
you
can
agree
or
disagree
with
me-
is
that
you
want
to
make
sure
that
the
controllers
don't
start
acting
until
there
is
a
reasonably
complete
set
of
data
that
they
need
to
act
on
so
one
way
of
ensuring
that
is
to
say.
Well,
you
can't
create
the
federated.
A
You
don't
create
the
federated
replicas
set,
because
you
don't
have
the
references
to
the
things
that
you
need
yet,
and
you
only
create
that
wait
and
all
the
other
things
have
been
created
and
once
they
have,
then
you
have
references
to
them,
and
you
put
them
inside
that.
In
this
this
example
federated
replicas
set
or
not
one
way
of
ensuring
that
the
order
of
creation
is
is
sensible,
but
you
don't
really
need
the
references
to
I
mean
you
could
do
that
informally.
You
could
just
say
you
know
when
you
create
these
things.
A
First
create
all
of
the
scheduling,
placement
or
scheduling,
preferences
and
overrides,
and
whatever
else
might
apply
first
and
then
only
create
the
base
object.
The
federated
replicas
set
as
the
last
step
and
then
implicitly
the
controller
knows
that
once
the
replicas
set
gets
a
federated
replica
set
gets
created,
then
the
user
is
ready
for
the
controller.
To
start
acting
is
that.
A
Then
you
need
something
more
akin
to
a
join
which
could
be
a
label
selector,
for
example,
but
I
think
that's
someone
independent
of
the
ordering
problem,
which
is
we
don't
want
the
scheduler
or
we
don't
want
the
controllers
in
general
to
start
acting
until
they
have.
You
know
enough
information
to
act
on.
B
A
B
Right
so
there
are
there's
one
there's
another
possibility
for
restricting
propagation.
Until
some
dat
estate
has
been
mm-hmm
reached
and
I
I
think
it
has
to
do
with.
We
rely
on
a
list
of
clusters
that
a
resource
should
be
propagated
to
then,
as
long
as
that
lists,
the
clusters
doesn't
exist.
Nothing
when
you
propagate
it,
which
is
kind
of
like
a
if
you
fall
without
propagate
model,
which
is
not
really
beginning,
thus
far,
developments
in
light
of
what
we've
been
discussing
around
how
to
like
configure
provocation.
A
Yeah,
that's
that's
true,
I
mean
I.
Guess
there
might
be
other
stuff
that
I'm
just
trying
to
get
my
head
around
whether
whether
a
controller
so,
for
example,
if
there
isn't
actually
a
propagation
preference
I,
will
assume
we
might
have
a
default
which
is
like
sent
to
all
the
clusters,
and
so
the
controller
would
have
struggle
to
know
whether
the
user
had
just
wanted
the
default.
Maybe
propagations,
not
the
right
word.
B
A
But
we
still
do
have
the
option
I.
Think
of
just
saying.
Well,
you
know
once
the
replica
set
the
federated
replica
said,
object
gets
created.
We
assume
that
all
of
its
dependencies
exist
and
therefore
we
can
act
on
it
and
don't
want
us
to
act
on
it,
don't
create
it
yet
until
you've
created
all
the
other
stuff.
So
this.
B
I
guess
this
sort
of
ties
into
a
slightly
higher
order
concerned.
I
was
having
around
having
things
split
up,
which
was
how
to
coordinate
scheduling
with
propagation
I
mean
if
you'd
have
a
you
know,
kind
of
a
pipeline
where
it's
all
just
done
in
one
thing,
that's
one
thing,
but
that
may
be
limits
extensibility,
at
least
for
the
purposes
of
experimentation.
B
A
I
think
I
think
I
understand
your
concern
and
I
I.
If
I
do
understand
it,
then
I
agree
with
it
and
maybe
one
way
around.
It
is
the
same
similar
pattern
to
what
I
just
described
earlier,
which
is
that
we
have
specific
objects
that
need
to
exist
for
that
stage
to
continue
so
so
using
the
default
using
that
the
default
cluster
selection
example,
even
though
the
absence
of
a
cluster
selector
might
indicate
that
we
want
to
go
to
all
clusters.
A
The
scheduler
is
the
thing
that
needs
to
decide
that,
whether
that's
a
human
scheduler
or
a
software
scheduler,
and
until
it
has
decided
to
send
it
to
all
clusters,
they
won't
actually
be
a
directive.
Let's
call
it
a
cluster
replicas
set
to
tell
the
propagator
to
propagate
to
all
the
clusters,
so
the
propagator
will
basically
sit
there
waiting
for
someone
to
tell
it
to
propagate
to
all
clusters.
B
A
A
So
all
it
does
is
it
watches
for
those
types
and
when
new
ones
get
created,
it
interprets
that
as
a
work
queue
item,
and
does
it
think,
and
as
long
as
we
specify
that
clearly,
then
the
job
of
the
schedulers
is
clear
and
the
only
thing
it
creates
is
a
sequencing
dependency
which
in
eventually
consistent
systems,
is
potentially
a
bit
tricky.
You
know
the
user
thinks
they
created
their
scheduling
preferences
and
then
created
their
federated
replica
set.
But
the
scheduler
sees
that
in
a
different
order,
but
I
guess
no.
A
A
Yeah,
so
unless
there
are
any
objections,
let's
consider
that
a
decision
that
we
will
define
exactly
what
the
types
are
that
each
work
stage
workflow
stage
gets
triggered
by
and
those
will
be
explicit
things
and
in
the
API.
And
that
way
we
can,
you
know,
force
the
sequencing
of
what
is
essentially
a
workflow,
so
you
need
to
perhaps
you
know,
create
overrides
before
you
or
select
clusters
before
you
apply
overrides
per
cluster
before
you
propagate
to
the
underlying
clusters,
for
example.
B
B
That
teleport-
hey
sorry
about
that,
so
we
were
just
discussing
how
to
ensure
that
the
propagator
will
have
correct
state
when
it's
trying
to
make
a
decision
about
what
to
do,
and
the
consensus
was
unless
anybody
dissenting
opinions
please
speak
out,
but
that
the
propagator
would
be
gated
by
objects.
Things
like
you
wouldn't
actually
do
any
propagation
unless
the
propagation
resource
existed,
and
that
would
allow
time
for
a
scheduler
to
decide
on.
We
wanted
to
do.
B
They're
kind
of
below,
like
a
quittin,
is
going
to
write
up
something
that
kind
of
defines
what
the
workflow
is
going
to
be.
You
have
to
create
things
in
a
certain
order.
If
you
want
to
have
you
know
if
you
just
create
a
federated
resource,
it's
not
going
to
get
propagated.
If
you
can't
create
a
propagation
resource
for
that
resource,
it'll
be
propagated,
but
it
won't
include
overrides
or
what
is
the
other
one.
B
A
Yeah,
that
was
exactly
this
conversation.
How
do
we
and
I
think
yeah?
The
consensus
was
so
one
approach
is
actually
just
to
do
it,
even
if
you're
not
ready
and
then
fix
it
up
afterwards.
If
the
world
changes,
which
you
know
you
kind
of,
have
to
do
anyway
later
on
somebody's
gonna
update,
the
cluster
preferences
or
update
the
overrides
and
you're
gonna
have
to
you
know,
fix
everything
up,
but
it
seems
like
on
initial
creation.
You
want
to
avoid,
you
know
busy
work
and
creating
intermediates
that
weren't
really
intended
to
be
there.
Yeah.
C
And
I
can
also
see
there
being
at
least
a
use
case
for,
like
you,
you
might
only
want
to
do
the
propagation
if
there's
work
to
be
done
on
that
resource
so
like
you
could
potentially
have
that
release
or
the
propagation
resource
to
be
the
thing
that
gates
everything
even
like
on
Dave
you
as
a
starting
point
to
have
a
gate
like
the
initial
propagation
I
think,
makes
a
lot
of
sense.
Well,.
A
Well,
just
to
be
clear,
so
I
don't
think
that
was
the
conclusion
we
came
to.
The
conclusion
was
that
each
stage
each
of
these
stages,
whether
it's
scheduling
or
overrides
or
propagation,
each
one
would
have
a
well-defined
gating
API
object,
and
if
that
object
didn't
exist,
then
that
stage
would
not
kick
off
and
then
implicitly
each
of
those
stages
would
produce
a
new
API
object
and
which
would
then
trigger
the
subsequent
stages.
A
So
basically
nothing
would
happen
until
the
perhaps
the
cluster
selector
controller,
the
scheduler.
Let's
call
it
says:
oh
there
is
one
of
these
federated
replicas
sets.
It
doesn't
have
a
specified
cluster
selector,
so
I
am
going
to
assume
that
the
default
is
required
and
I'm
going
to
decide
to
send
it
to
all
clusters.
A
A
You
know
the
propagation
objects
which
then
tell
the
propagator
that
it
can
now
propagate
these
things,
to
the
clusters
that
were
selected,
etc,
and
if
you
want
to
stop
that
whole
change,
so
you
could
potentially
have
defaulting
all
the
way
down
that
chain,
but
at
least
it
makes
sure
that
the
sequence
of
events
is
correct
and
if
you
didn't
want
to
start
the
sequence
of
events
at
all,
you
just
wouldn't
create
the
Federated
replica
set
the
thing
at
the
head
of
that
chain.
Until
you
had
all
the.
B
Other
stuff
in
class.
Sorry,
you
need
to
have
an
override
I
guess,
I
conceived
if
it
kind
of
being
an
optional
thing.
If
you
didn't
provide
it,
no
overwriting
would
be
done,
and
the
suggestion
is
that
it's
kind
of
like
propagation
and
that
you
wouldn't
actually
do
anything
unless
you've
had
an
override
and
a
view.
Controller
responsible
for
setting
a
default
override
resource
for
a
federated
type
resource
before
a
propagation
would
commence.
Yeah.
A
A
I
agree,
and
there
needs
to
be,
there
is
a
logical
workflow
that
we
I
don't
think
we
can
kind
of
avoid.
You
don't
want
the
propagator
propagating
stuff
that
you
know
hasn't.
Had
the
clusters
selected
or
hasn't
had
the
overrides
applied
if
there
are
any
etc,
and
then
you
know,
having
to
gonna
read
propagate
everything
as
soon
as
those
objects
exist.
B
The
only
catch
with
this
I
think
is
is
there's
kind
of
a
tension
between
overrides
that
would
be
set
by
control
order
versus
provided
by
a
user.
So
if
I
wanted
to
very
you
know,
the
classic
example
uses
and
one
of
everything
image
across
clusters
for
a
replica
set
template
and
then
I'll
set
an
override
resource
for
the
replica
set.
But
then
the
scheduler
will
come
in
and
will
set
the
replica
count
values
for
link,
and
the
question
is:
is
that
okay
or
do
we
need
to
account
for
that
differently?.
A
I,
don't
know,
I
mean
I've
had
a
similar
thought
as
to
whether
we
want
to
be
able
to
have,
and
it
gets
back
to
the
many-to-many
relationship
thing
we
spoke
about
earlier.
You
know
other
some
overrides
that
get
created
by
the
user,
and
then
you
know
additional
overrides
that
get
created
by
controllers
or
policy
or
permissions
or
anything
else.
A
My
gut
feel
is
yes,
there
are,
and
then
the
question
becomes:
do
they
like
fight
with
each
other,
the
job
date,
the
same
actual
resource,
so
the
user
creates
a
overrides
resource,
maybe
and
then
controllers
like
add
to
it
or
subtract
from
it
or
do
whatever
versus
creating
their
own
and
then
having
the
override
or
kind
of
merge.
All
of
these.
You
know
that
the
user
specified
ones
with
the
system
specified
ones
in
a
in
a
well-defined
way
to
produce
the
overridden
resource.
C
I
guess
it's,
it's
probably
worth
thinking
about
the
use
cases
in
terms
of
do.
We
expect
there
to
be
a
use
case
that
we
want
to
be
able
to
support,
and
I
saw
see
no
reason
like
from
the
priors
not
to
be
able
to
do
this,
but
that
a
user
could
just
say
I
want
to
bump,
like
regardless
of
what
like
scheduler
resource
or
other
thing
is
programming.
This
API
I
want
to
make
sure
that
there
are
50
replicas
in
this
particular
cluster
is
that
is
that
a
valid
use
case.
A
Yes,
I
think
it
is
I
mean
it's,
it's
actually
a
use
case.
We
explicitly
support
at
the
moment
and
that
we
have
minimum
and
maximum
replicas
in
each
cluster
and
if
you
set
them
both
to
the
same
number,
you
have
precisely
that
replicas
in
a
given
cluster
and
it
does
seem
to
be
something
people
need,
and
that
is
something
I
would
like
us
to
support
it.
Yeah
I.
B
Mean
I
guess
that's
that's
a
little
bit
of
a
different
case.
I
mean
I
absolutely
need
to
support
that.
But
it's
like
the
difference
between
overrides
and
scheduling
preferences.
In
my
mind,
the
the
results
of
the
scheduling
preferences
will
be
scheduler,
just
decided,
overrides
I,
guess
I'm
fuzzy
on
whether
like
I
guess,
scheduling,
doesn't
I,
can't
think
of
examples
or
use
cases
where
overrides
interact
with
scheduling
in
a
weird
way.
Like
you
pretty
much
always
want
a
scheduling
decision
to
just
over
regular
user
set
because
the
user
provided
scheduling
preferences.
B
A
There's
a
fuzzy
area
there
where,
where
there
are
user
preferences
that
are
kind
of
all-or-nothing
in
the
sense
that
unless
you
can
give
me
fifty
replicas
in
that
cluster
I,
don't
want
anything
there,
because
it's
not
useful
to
me.
So
if
your
policy
says
that
that
I
only
have
20,
let's
say
Porter
there
or
that
I'm
not
allowed
to
do
something
rather
just
tell
me
that
the
my
request
has
failed
so
that
I
can
change
it.
A
You
know
pick
a
different
cluster
or
do
whatever
then
give
me
something
materially
different
than
what
I
asked
for,
which
is
not
useful
to
me
and
that
that
was
sort
of
the
thinking
behind
the
minimum
and
maximum
replica
thing.
Where
usually
the
the
preferences
are
they
sort
of
range
from
absolutely?
Unless
you
can
give
me
this
thing
as
a
minimum,
I
don't
want
anything,
but
but
if
you
could
give
me
more,
then
please
do
and
that
that's
where
the
minimum
and
maximum
stuff
came
from
and
I
think
those
kind
of
things
are
pretty
common.
A
It
happens
with
affinity
and
stuff
like
that
as
well
like
I
want
these,
you
know
my
master
and
my
slave
I
definitely
want
them
on
different
nodes.
If
you
put
my
master
and
slave
on
the
same
node,
then
you
may
as
well
not
give
me
anything
because
it's
not
useful
because
they're
both
failed
together,
but
I
also
don't
want
them
too
far.
Apart
so
make
sure
they're
in
the
same
cluster
somewhere,
there
absolutely
mustn't
be
on
the
same
node
and
they
absolutely
must
be
in
the
same
cluster.
A
B
Skye
I
think
all
of
what
you're
saying
is
completely
valid.
I'm
I
wasn't
really
intending
to
I,
wasn't
really
a
tenant
attending
to
sort
of
focus
on
the
decision-making
uh-huh?
Is
it
well
like
the
scheduling
or
policymaking?
That's
kind
of
something
that
has
to
happen.
I
was
just
focusing
on
like
the
overrides
which
to
me
are
like
the
outcome
of
either
user
decision
or
scheduling
or
policy
decision,
and
so
the
question
is:
do
we
need
to
separate
user
directives
from
the
outcomes
of
policy
or
scheduling.
A
Yes,
I
think
we
do
Foca,
amongst
other
reasons,
to
make
it
very
clear
which
is
which
you
know
it's
useful,
both
for
a
user
and
for
a
controller
to
know
that
this
is
what
the
user
asked
for,
and
this
is
what
the
policy
has
to
enforce
and
make
them
very
obviously
I
mean
they
don't
have
to
necessarily
be
separate
objects,
but
I.
Don't
think
that
that
the
one
should
overwrite
the
other
one
and
we
lose
information
about
what
the
user
asked
for
just
because
the
scheduler
decided
to
put
them
somewhere.
A
The
the
main
reason
I
mentioned
the
earlier
stuff
was
that
I
think
we
need
to
take
into
account
that
that
there's
a
point.
You
can't
just
override
things
that
users
asked
for
in
all
cases,
because
sometimes
that
makes
the
thing
that
the
end
result
completely
unuseful
to
the
useful
user
and
and
they
would
rather
have
a
failed,
a
API
call,
or
you
know
something
at
first
all
that
then
some
compromised
version
of
what
they
asked
for
I.
A
Their
preferences
have
to
be
able
to
specify
what
the
limits
of
you
know
the
what
what
their
constraints
as
we
just
kind
of
trouble,
exactly
what
they
would
be
comfortable
having
the
variety
or
scheduler.
You
know
change
or
work
within
certain
bounds,
but
outside
of
those
bounds
they
would
rather
have
a
failure.
So.
B
So
the
question
has
then
and
I
guess:
maybe
this
could
be
deferred
to
the
flow
topic,
but
I
mean
it
sounds
like
the
system
over
I
should
gate
propagation,
you
don't
propagate
a
resource.
Until
you
see
a
system
override
provided
by
something
I'm,
not
sure
a
user
override
is
required,
and
maybe
it
would
be
safe
to
go
if
a
user
override
was
not
provided.
B
A
A
Just
kind
of
musing,
the
propagator,
in
my
mind,
is,
is
only
going
to
propagate
precisely
what
it
gets
told
to
propagate.
So
when
it
gets
an
instruction
to
say,
put
this
precise
thing
with
this
precise
replicant
and
and
the
names
of
secrets,
and
whatever
else
put
it
in
this
cluster,
then
it
does
that
it
doesn't
do
anything
else.
So
there's
no
is
there's
very
little
scope
for
planning
as
to
whether
it
should
propagate
something
or
not.
It
either
gets
an
instruction
to
do
it
or
it
doesn't
yeah.
B
A
And
so
I'll
take
it
to
do
item
2
to
put
a
strawman
up
there
for
approximately
what
these
different
API
resources
look
like
and
who
creates
them
and
what
sequence
they
get
created,
there's
kind
of
a
logical
pipeline.
You
need
the
you
need
the
template
before
you
can
apply
over
I,
oh
yeah,
you
need
the
template
before
you
can
schedule
it
before
you
can
provide
overrides,
etc.
Probably
something
like
that
I
can
draw
that
up
in
a
diagram
put
some
strawman
fields
and
things
in
place.
A
A
A
So
maybe
the
policy
has
some
things
saying
you
can
only
go
into
these
clusters
and
maybe
the
quarter
availability
says
you
don't
have
quota
in
these,
and
you
know
these.
We
want
to
keep
them,
not
necessarily
a
separate
objects,
but
we
certainly
want
to
make
them
distinct
pieces
of
data
which
something
then
meshes
together
into
a
decision.
Is
that
yeah,
like
request
what
I
asked
for
and
what
I
got
are
separate
right,
yep
and
I?
Don't
even
know
that
the
strict
you
know
precisely
two
of
them
is
is
the
right
number.
A
It's
a
union
or
an
intersection
or
whatever,
but
once
you
have
more
than
one
you,
you
have
all
of
those
things
that
you
have
to
deal
with
so
I'm,
reasonably
comfortable
with
that
or
one
of
the
complaints
that
often
comes
out
where
you
do
these
kind
of
things
is
that
oh,
but
it's
not
well-defined
or
it's
confusing
to
the
user,
which
ones
are
more
important
than
others.
My
thinking
is
that
we
provide
a
system
that
can
cater
for
these
things,
and
then
you
know
we
can
always
provide
a
dumbed-down
set
of
restrictions.
A
That
say:
well,
you
know
for
this.
Like
beginners
cluster,
you
don't
get.
You
know
the
ability
to
create
different
priority
things.
You
only
get
one
of
them
and
it's
very
clear
to
you,
which
one
applies
etc
and
deal
with
it.
That
way,
rather
than
dumbing
down
the
system
at
the
primitive
level
that
we're
dealing
with
at
the
moment,
I'm.
B
Want
to
have
multiple
levels
of
orion's,
but
I
don't
really
want
to
generalize
it
to
end
levels
of
overrides,
at
least
not
yet
that
makes
sense
just
because
I
think
that
is
complicated
like
ultimately.
If
that's
what
we
need
that
for
sure,
let's
do,
but
in
the
near
term
I'd
rather
just
say
we
have
two
levels
and
that's
it.
A
I,
don't
have
a
violent
objection
to
that.
What
I
would
kind
of
encouraged
us
to
do
then,
is
to
sort
of
have
a
constant
in
the
code
that
says
number
of
override
levels
equals
two,
but
that
level
basically
goes.
You
know
for
n
equal
equals
1
to
n
and
is
currently
set
to
2,
but
by
you
know,
changing
that
to
50
in
the
future.
Everything
just
still
works
because
I
mean
intersecting
50
things
is
not.
You
know
fundamentally
more
complex
than
intersecting
two
things.
I
guess.
B
A
B
I
think
I
I
think
numerating.
These
cases
would
be
useful
for
me
because
I
don't
I'm
resistant
to
adding
the
complexity
of
an
arbitrary
number
without
concrete
reasons
to
do
so.
But
in
support
of
that
idea,
I
did
sort
of
want
us
to
discuss
what
form
the
override
resources
would
take
and
the
initial
conception
and
the
API
doc
was
that
it
would
be
strongly
typed
and
I.
Think
Paul's
had
some
ideas
about
how
that
could
be
more
generic
using
JSON
path
or
something
yeah.
C
B
The
reason
I
was
I
was
asking
Paul
to
sort
of
describe.
That
was
that,
if
we're
gonna
talk
about
sort
of
a
potentially
large
number
of
overrides
and
potentially
a
large
number
of
types,
those
overrides
would
apply
to
strong
typing
seems
problematic,
at
least
from
an
experimentation
point
of
view,
and
at
least
I
think
that
it
might
be
useful
to
have
this
kind
of
generic
override
mechanism
just
have
one
override
resource,
as
opposed
to
having
specific
resources.
Does
that
make
sense?
Yeah.
A
Yeah
I
think
I
think
I
understand
that
I
guess
the
one
caveat
I
I
can
think
of.
Is
that
I
think
there's
a
lot
of
value
in
being
able
to
validate
things
at
the
API
level.
So
so,
let's
say
some.
Let's
say
we
had
a
strongly
typed
override
and
it
had
you
know
a
bunch
of
fields.
Maybe
they
were
exactly
the
same
fields
as
the
template
has
with
exactly
the
same
types
and
you
can
validate
that
at
the
API,
and
you
can
say
yes,
your
your
override
specifier
is
valid.
A
We
know
it'll
work
at
run-time,
because
the
types
all
tie
up
and
it'll
result
in
a
valid
thing,
etcetera,
if
you
you
know
Center
basically
add.
If
there's
a
lot
of
possibility
for
sending
invalid
dips,
which
we
would
have
no
way
of
checking
whether
they
actually
could
ever
be
applied
and
then
potentially
they
fail
to
be
applied
down
the
line
somewhere.
And
then
it's
not
clear
what
we
should
do
about
that,
because
you
have
no
way
to
tell
the
user
etc.
So,
I
think
what
we're
talking.
B
About
could
be
validated
I've
had
some
limited
exposure
to
what
Paul
was
talking
about,
and
essentially
it
would
be
like
a
JSON
path
and
then
some
like
basically
a
JSON
or
call
that
includes
a
JSON
path
and
some
parameters
to
whatever
function
like
replace
or
or
whatever,
and
so
essentially
it
should
be
whether
it's
something
there's
already
existing
infrastructure
to
check
where
we
could
write
it.
A
mission
controller
to
check
it,
we're
not
talking
about
just
a
generic
blob
of
data.
It's
very
thick.
It's
basically
a
function
call
okay,.
A
C
B
Think
we
could
maybe
rely
on
where
this
kind
of
gets
into
the
other
question
I
had
about
overrides,
which
is
how
do
we
relate
them
to
the
resources
they
apply
to
and
if
we
were
to
use
like
a
local
Ralph,
you
could
maybe
supply
a
kind
without
a
name.
I,
don't
know
if
that's
reasonable,
but
that
could
have
solved
a
validation
problem.
In
any
case,
you.
C
Could
supply
a
kind
and
a
name
and
like
I,
think
I
want
to
spend
a
moment
on
one
thing
that
Quinton
said,
which
I
think
has
is
worth
like
driving
home
that
like
we
do
need
to
be
able
to
create
resources
out
of
order
because,
for
example,
if
you
have
like
queue,
if
you
pass
a
file
to
cube
controlled,
create
a
chef,
they
are
like
the
resources
in
that
file
aren't
necessarily
created
in
order.
So
we
have
to
be
able
to
support
creating
things
out
of
order
in
general,.
A
C
A
So
so
that
would
seem
like
a
I
mean
I
think
it
should
be
possible
to
create
them
in
order
it
should
be
popped.
It
seems
like
a
desirable
property
to
be
able
to
tell
cube
control,
to
create
things
in
a
particular
order,
because
there
are
cases
where
ordering
is
important
and
yeah
one
thing,
but
but
more
importantly,
we,
whether
you
use
cube
control
with
an
aggregated
file
or
any
other
way
of
doing
it.
You
definitely
need
to
be
able
to
create
things
that
apply
like
an
override.
A
That
applies
to
a
resource
which
doesn't
exist
yet
because
that's
as
per
our
previous
conversation,
one
of
our
mechanisms
for
gating
stuff
is
to
not
create
the
thing
that
kicks
off
the
pipeline.
So
for
that
reason
alone,
irrespective
of
cube
control
or
anything
else,
we
need
to
be
able
to
support
that.
A
C
A
Yeah,
so
I
can
I
can
go
through
afterwards
and
catch
up
the
notes
on
the
recording
based
on
recording
okay.
So
so
we've
we've
agreed.
We
got
these
workflows
and
we've
got
these
trigger
points
that
that
trigger
stages
in
the
workflow
and
we've
agreed
that
we
have
at
least
two
in
the
case
of
overrides
and
I
would
sort
of
be
inclined
toward
saying
N.
Where
n
is
two
until
we
can
show
use
cases
for
N
greater
than
2
I.
Think
that's
fine
and
we
have
agreed
that
there's
probably
some
priority.
A
B
Just
I,
we
know
we
touched
on
it
and
we
reduced
that,
but
I
don't
think
there
was
conclusion
in
my
mind
as
to
how
best
to
support
like
namespaces
is
a
simple
thing
that
just
or
container
and
you
just
create
them
on
the
you-
create
them
implicitly
on
the
number
of
clusters.
That's
one
thing,
but
in
terms
of
actually
providing
overrides
for
namespaces
I
guess
the
discussion
would
allow
for
that.
B
I
guess
maybe
I
guess
maybe
it's
not
as
confusing
as
I
was
thinking,
except
that
there's
there's
no
real
way
to
provide
template
like
if
I
have
a
federated
replica
set.
The
labels
and
annotations
on
the
federated
replica
set
do
not
necessarily
correspond
to
the
labels
and
annotations
in
the
template.
They
can
vary
in
the
case
of
a
namespace.
That's
a
little
bit
harder
to
achieve
because,
as
I've
been
thinking
about
it,
I
don't
see
how
we
do
a
namespace
template
unless
it's
just
a
one-to-one
relationship
with
namespaces
and
we'll
just
manually.
B
It's
just
more
challenging
to
have
a
federated
namespace
than
another
federated
resource,
because
namespace
is
implicitly
a
container
and
we
could
do
a
federated
namespace,
but
essentially
it
would
be
all
it
would
be.
Able
to
do
is
apply
like
I
guess,
the
the
meta
data
to
the
resource
that
was
propagated
well,.
A
So
so
a
namespace
at
the
moment
is
kind
of
two
different
things.
The
namespace
is
what
it's
called
it's
a
it's
a
space
for
names
which
allows
you
know
different
users
to
create
things
with
the
same
name,
but
they
just
put
them
in
different
namespaces
and
it's
also
become
a
kind
of
a
security
boundary
where
there
are
a
whole
bunch
of
implicit
restrictions
as
to
under
what
conditions
you
can
cross,
namespaces
and,
and
the
default
answer
seems
to
be
you
can't
and
and
I'm,
not
namespace
expert.
A
But
that's
that's
the
impression
I've
got
I,
don't
particularly
like
the
fact
that
they
mean
these
two
different
things:
spaces
for
names
as
well
as
security
boundaries,
but
be
that
as
it
may,
it
they
seem
to
be
quite
popular.
People
seem
to
understand
them
and
seem
to
use
them,
and
there
is
less
of
an
outrage
against
this
sort
of
dual
personality
than
I
would
have
expected
so
on.
B
B
Just
saying
like
the
difference
is
that
federated
replica
set
is
one
resource.
That's
just
a
template,
essentially
today
right
it
has
some
associated
resources.
A
namespace
is
a
first-class
thing.
It
actually
is
part
of,
like
controllers
that
say,
will
apply
to
the
Federation
Federation
API
from
the
cube
side,
like
our
back,
for
example,
you
can't
have
a
federated
namespace
standing
in
for
a
namespace
as
a
different
resource
and
so
to
provide
the
parameters
the
propagation
essentially
to
define
like.
What's
specifically,
you
want
to
go
into
the
cluster
separate
from
the
labeling?
That's
on
the
namespace.
A
That
is
a
different
I'm,
completely
confused.
So
maybe
I
can
tell
you
what
I'm
thinking
in
my
head.
When
you
talk
about
a
federated
replicas,
a
federated
namespace
and
and
then
maybe
the
confusion
will
become
clear,
so
so
I
think
you
have
namespaces
in
the
Federation.
So
so
you
you
can
create
federated
things.
A
In
the
example
we've
been
using,
federal
replicas
set
and
that
that
API
object,
which
lives
essentially
only
in
the
Federation
control,
plane
lives
in
the
namespace,
which
means
that
you
can
create
to
two
different
users
or
the
same
user
can
create
three
different
replicas
of
federated
replicas
sets
in
different
namespaces
in
the
Federation
control
plane
and
inside
each
one
of
those
is
a
template
that
says
you
know
mr.
controller,
please
go
and
create
a
replica
set
in.
A
You
know
the
clusters
that
I
specified
in
my
cluster
selector
with
the
overrides
I,
specified,
etc
and,
and
you
go
and
stick
that
into
each
cluster,
and
then
you
have
a
replica
set
in
each
cluster
and
there
may
be
some
kind
of
like.
Maybe
those
replica
sets
actually
need
to
be
in
a
namespace
named
the
same
as
the
namespace
that
the
federated
replica
set
was
created
in,
but
that's
that's
kind
of
an
artificial
veneer
I
mean
they
could
actually
be
created
in
completely
different
namespaces
and
you
could
even
override
the
namespace.
A
A
A
A
A
We
have
to
do
that
and
so
I
think
you
should
be
able
to
create
namespaces
in
the
Federation
control
plane,
which
are
different
than
federated
namespaces
and
a
federated
namespace
is
to
say,
I
want
this
namespace
created
in
all
of
these
clusters,
just
like
any
other
federated
thing
like
a
replica
set
or
a
conflict
map
or
a
secret
or
anything
else.
That's.
B
Fine
but
I
mean
to
me
it's
there's,
there's
there's
one
sort
of
namespace
for
namespaces
in
the
Federation
control
plane
and,
to
my
mind,
like
the
valve
one
of
the
values
of
the
Federation
of
using
an
API
for
Federation
mechanism.
Is
you
have
kind
of
validation,
of
the
sort
of
the
layout
of
your
resources
and
as
soon
as
you
start
having
a
different
mechanism
for
determining
the
name
spacing
and
the
clusters
from
the
API,
then
you
have
the
potential
for
conflict.
You
need
ways
to
resolve
it,
I'm
kind
of
like
well.
B
A
That
makes
sense,
I
guess
I
still
don't
quite
understand
your
concern
Maru.
So
maybe,
as
part
of
the
document
I've
offered
to
write,
I'll
I'll
include
in
that
the
namespace
stuff
and
and
maybe
you
can
shoot
holes
in
it
or
come
come
back
with
your
expression
of
where
you
see
the
complication,
because
I
guess
I
don't
see
it
yet.
Okay,.