►
From YouTube: Kubernetes Federation WG sync 20180314
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).
C
D
D
D
Failing
that,
I
would
suggest
we
focus
on
trying
to
come
to
some
consensus
on
an
agreed-upon
approach
to
v2
of
the
API
and
implementation
and
identify
any
specific
sticking
points.
I,
don't
think
we're
ever
gonna
be
at
a
point
where
we
have
us.
You
know
detailed
arc
where
we
have
validated
that
everything
is
perfect
or
everything
is
implementable,
as
described,
but
I
think
we
need
to
at
least
say
this
is
what
we've
agreed
upon
and
we
will
adapt
it
as
need
be
during
the
implemented.
D
E
Maybe
an
alternative,
take
I
mean
my
focus
and
Ivan's
focus
has
been
on
prototyping
and
trying
to
learn
things
that
influence
the
design
from
that
and,
to
my
mind,
I
think
that's
been
sort
of
a
good
there's
been
learning,
that's
come
out
of
that,
and
my
hope
would
be
is
that
we
follow
a
similar
approach
for
iterating
on
the
design.
The
idea
that
we
would
finalize
or
formalized
like
a
design
and
and
then
we're
just
going
to
run
with
that.
E
D
Sorry,
that's
too
many
negatives
that
we
start
doing
the
detailed
design
and
development
possible,
apparently
now,
rather
than
waiting
to
kind
of
reach,
clue
closer
consensus
if
I
can
prove
that
way
or
more
detailed
consensus.
I
think
we're
at
a
point
now,
where
you
know
modular
some
terminology
and
those
kind
of
things
which
are
reasonably
easy
to
change
as
we
go.
We
can
actually
start
building
stuff
soon
and
detail
design
and
build
of
you
know
specific
API
types
and
specific
controllers,
etc,
and
that
we
can,
as
you
say,
iterate
on
those
as
we
go.
D
C
E
D
D
Okay,
sorry
I
haven't
actually
some
of
these
comments.
Just
came
in
in
the
last
hour,
while
I
was
commuting,
so
I
haven't
had
a
chance
to
digest
all
of
them,
but
I
think
they're,
probably
whoa,
there's
a
whole
bunch
of
green
here,
not
quite
okay.
Somebody
added
all
this
stuff,
not
totally
sure.
Oh,
it's
poor,
okay,
I'll
read
through
that
offline
doesn't
look
in
conflict
with
anything.
That's
currently
in
the
dock
or
in
my
head,
I.
E
E
D
Don't
personally,
what
I
would
like
us
to
do
is
aim
to
at
the
end
of
this
meeting
modular
the
additional
feedback
that
you
want
to
provide
by
Monday
identify
the
things
that
may
be
the
most
contentious
in
this
document
and
see
if
we
can
resolve
that
now
today
in
the
next
45
50
minutes
such
what
you
know
on
bond
about
let's
say
Wednesday
next
week
we
can
say
this
is
broad
consensus
that
we
reach
and
we've
been
holding
on.
The
basis
of
this
yeah
go.
E
Ahead,
I
guess,
I
I
would
hope
that
we
could
have
a
consensus
on
what
like
like
to
me.
I
guess,
I'm
mentally
blocked
by
the
idea
that
this
dock
is
somehow
authoritative.
Then
this
is
what
people
need
to
go
and
do
work
and
I
mean
I'm,
going
off
and
prototyping
stuff
and
I'm
kind
of
curious.
Why
that
isn't
something
that
people
can
do
as
well
like
it
kind
of
needs
to
be
some
sort
of
basis?
Cop
for
for
understanding
like
these
are
the
common
elements
we're
working
with.
E
E
So
I
mean
it
see
what
I'm
not
talking
about
final
work.
I
guess,
that's.
My
point
is
like
let's
go,
do
a
rough
prototype
of
this
and
see
what
we
learn
and
come
back
and
then
like
to
me
that's
more
of
an
iterative
process
and
having
this
doc
being
the
thing
I
know
it's
not
necessarily
what
you're
intending
I'm
just
saying
my
sort
of
impression
is:
we
need
a
doc
and
we
need
to
be
authoritative
and
we
can't
do
work
until
that's
true,
for
what
I
would
like
is
to
have.
D
Enough
detail
that
we
have
discussed
and
agreed
upon
so
that
we
can
go
and
build
something
which
we
can
incrementally
change.
You
know
as
our
thinking
changes,
but
that
does
not
need
to
be
thrown
out
the
window
and
rebuilt,
because
I
thinking
has
changed
so
much
that
whatever
prototype
we
build
is
is
kind
of
so
far
away
from
where
we
want
to
be
that
that
it
is,
you
know,
only
useful
for
tip
trying
out
things.
I
mean
I
would
like
us
to
start
actually
building
something
that
ultimately
becomes
v2
and
I.
D
E
Where
is
your
concerns
stemming
from
like
that?
We
would
be
moving
forward
and
prototyping,
and
then
that
would
somehow
not
converge
on
something
useful,
because
that's
I
mean
my
to
be
the
the
prototyping
effort
that
I've
been
working
on
is
more
about
de-risking
like
this
exercise
in
getting
something
supportable
in.
E
D
Need
requirements
and
we
do
any
high
level
architecture
and
it's
easier
to
discuss
and
agree
upon
that
in
a
document
with
diagrams
and
things
than
it
is
to
dive
through
PRS
and
code
I.
Think
so.
So
that's
that's
what
this
aims
to
be
here:
rough
agreement
on
the
requirements
and
the
high
level
architecture
and
design
and
such
that
we
can
go
and
build
detailed
designs
and
implementation
that
are
consistent
with
that
or
where
they
need
to
be
inconsistent.
D
We
can
then
go
back
and
say:
okay,
we
thought
we
could
do
this
this
way,
but
actually,
when
we
went
to
try
and
design
it
in
detail
and
implemented,
it
turns
out
there
was
a
bit
of
a
flaw
in
our
thinking,
so
we're
gonna
adjust
our
thinking
and
put
that
down
in
the
document
as
the
adjusted
thinking
and
move
on,
as
opposed
to
kind
of
going
around
around
in
circles.
So
yeah
I
think
we're
actually
on
the
same
page
murder.
Then
I,
don't
think
we
have
any
differences
in
thinking
there.
Okay.
E
So
so
two
things
that
come
off
that
off
my
head,
one
was
I'm
almost
wish.
There
were
lying
numbers
in
this
document.
There's
sections
hopefully
that'll
help.
Let
me
see
if
I
can
so
in
in
the
fully
automated
case
section
where
maybe
number
okay
number
floor
in
that
section,
there's
a
specification
in
the
deployment
of
replicas
being
300
and.
E
I
guess
I'm
kind
of
my
conception
is
that
that
would
be
ideally
part
of
sort
of
scheduling,
preferences,
sort
of
leave
room
for
people
who
want
straight
replication.
They
wouldn't
have
a
replicas
field
to
confuse
them.
The
template
would
be
authoritative
and
then,
if
you
were
just
wanting
to
schedule
replicas
across
clusters,
in
the
you
know
the
dynamic
or
automated
way,
you
would
have
a
scheduling
preferences
resource
that
would
allow
you
to
specify
the
total
number
that
you
wanted.
Yeah.
D
D
D
D
D
E
Mean
I
mean
that's
kind
of
my
thinking,
I'm,
not
trying
to
say
everybody's
thinking
that
way,
and
it's
anybody
else
want
things.
Placement
preferences
is
a
better
that
the
only
reason
I
would
guess
it's
a
little
bit
fuzzy
like
whether
it's
placement
or
scheduling
I,
don't
think
I'm
too
strong,
I'm
just
kind
of
trying
to
understand
why
it
appears
like
this
in
the
doc.
I
think.
E
E
D
I'm
comfortable
with
that,
anyone
else
wants
to
chime
in
or
agree
or
disagree,
yeah
3
2.
Otherwise,
we'll
go
with
that.
I
guess.
The
main
point
that
I
think
we
need
to
be
clear
on
is
the
distinction
between
what
is
being
called
up
to
now
placements
get
preferences
which
we're
now
renamed
scheduling,
preferences,
the
distinction
between
preferences
and
decisions.
D
E
I'm
probably
makes
sense
to
revisit
the
discussion
around
the
term
substitution
and
I.
Think
I
have
a
little
bit
of
a
clearer
idea
of
why
I'm
resistant
to
that
term.
Okay,
I
think
that
we
had
a
we
had
previous
discussions
where
you'd
have
like
I
mean
the
term
template
is
maybe
leading
as
well,
but
like
I
have
a
template
and
one
point:
we
discussed
the
idea
of
having
like
actual
substitution
variables
that
appear
in
the
template,
and
then
you
would
have
over
our
substitution.
E
Don't
think
that
there's
a
clear
argument
for
overrides
and
not
limited
sort
of
example,
but
I
was
I,
was
thinking
about
the
current
approach
that
I've
been
taking
is
simply
I
provide
a
field
for
a
cluster,
and
that's
just
is
this
simple
like
override
or
substitution,
when
I
start
talking
about
like
JSON
patches
and
the
potential
to
say,
take
a
list
of
things
and
add
to
it?
Take
a
list
of
things
which
leave
from
it
as
JSON
patch
allows.
Then
substitution
starts
to
be
a
little
bit
like
less
clear
of
a
good
term.
E
D
Yeah
I
totally
understand
that
point
and
I
actually
totally
agree
with
it,
and
you
know
I
think
is
somewhat
important,
but
as
long
as
we
use
something
that
we
all
agree
has
a
particular
meaning,
and
ideally
that
meaning
should
not
be.
You
know
too
far
away
from
the
sort
of
diction
dictionary
definition
of
what
that
meaning
is
I.
Think
we're
fine
I,
totally
agree
with
you.
The
thing
that
I've
been
calling
substitution
is
not
simple.
Variable
substitution
of
atomic
variables
substitution
might
be.
D
You
know
it
might
be
that
it
could
be
yeah,
but
but
the
user
might
have
said
you
know,
I
didn't
specify
any
container
or
set
of
containers,
or
you
know
any
other
bunch
of
things
in
the
template
and
and
what
I've
called
substitution,
which
might
not
be.
The
right
word
would
be
substituting
that
you
know
blank
space
with
a
list
of
things
whether
we
call
that
you,
you
actually
came
up
with
quite
a
good
word
a
few
moments
ago,
which
just
slipped
my
mind
as
an
alternative
to
substitution.
D
Yes,
you
called
it
something
else
and
I
can't
think
of
a
word
now.
The
only
objection
I
have
to
the
word
override
is
is
that
it
explicitly
has
fairly
strong
connotations
and
I.
Think
I
put
the
dictionary
definition
in
somewhere
of
you
know.
Somebody
wants
something
and
something
else
completely
overrides
that
so
so
it
says.
No,
you
can't
have
that
you,
you
get
these
other
things
instead
and
there's
a
whole
bunch
of
examples.
D
In
the
dictionary
of
you
know,
rulers
overriding
the
desires
of
whatever
the
minions,
etc
and
I
think
that's
kind
of
exactly
the
opposite
of
what
we're
trying
to
express
here.
What
we're
trying
to
say
is
here's
a
broad
set
of
preferences,
and
the
template
is,
is,
you
know,
essentially,
is
conceptually
part
of
the
users
preferences
and
the
substitution
or
whatever
this
other
word
is
that
you
came
up
with
that,
might
be
better.
D
Alright,
so
unless
we
can
think
of
a
better
one,
so
to
be
clear,
the
word
scheduling
in
the
stock.
Sorry,
the
word
substitution
in
this
document
is
used
more
broadly
than
simple
variable
substitution,
and
maybe
we
should
we
can
either
replace
that
word
with
a
better
word,
the
one
that
you
used
earlier
or
we
can
just
define
the
word
that
we
use
substitution
as
to
exactly
what
it
means.
It
doesn't
just
mean
substitute.
You
know
dollar
X
with
some
number.
D
E
D
Think
we
actually
agree
what
thing
I
think
we
agree.
What
we're
talking
about
here,
we're
just
looking
for
the
right
word.
So
how
about
we
just
go
flying
I'll,
think
of
a
better
word
and
you
can
think
of
a
better
word
and
we
can
use
whatever
the
best
of
those
two
is
I.
Don't
think,
there's
a
disagreement
on
the
thing
about
replacement.
E
D
D
E
Okay
will
so
just
a
minor
point
of
the
sort
of
dichotomy
between
preferences
and
decisions.
I've
been
just
considering
like
where
the
decisions
is
kind
of
implicit,
so
I
would,
if,
like
in
my
current
way
of
thinking,
I,
would
have
like
a
placement
preference.
Then
I
would
just
have
like
place
by
resource.
So
there's
no
like
decisions
is
that,
like
are
you
thinking
that
it's
necessary
to
have
explicitly
placement
decision
like
as
a
resource
name,
I'm
differentiated
for
the
purposes.
D
D
If
you
have,
you
know
two
variants
of
substitution,
the
one
being
the
preference
is
the
other
one
being
decisions
and
then,
if
you
use
the
word,
substitution,
you're
kind
of
referring
to
both
of
them
and
if
you
use
one
of
those
specifically
but
I,
don't
I
don't
feel
super
strongly
about
it.
So
if
you
want
to
remove
the
word
decision
from
there
and
say
that
substitution
preferences
begets
actual
substitutions,
that's
fine,
I
guess.
D
D
D
C
I
had
couple
of
wines
of
questions
which
I
wanted
we
better
discuss.
For
example,
I
am
not
very
clear
on
if
this
particular
workflow
or
the
workflows,
which
are
represented
in
the
diagram-
a
are
sort
of
correlative,
for
example,
for
the
reference
implementation
that
we
do
in
the
community,
or
that
is
one
of
the
implementations
that
we
will
decide
on
and
there
are
multiple
possible
boss
flows.
C
For
example,
I
I
wrote
one
coming
here,
saying
that
there
is
a
possibility
that
you
don't
have
different
other
resources,
aka
social
placements
differential
placement
decisions
and
all
those
things
are
not
there.
Only
based
by
this
will
be
source
and
temperatures
there
and
propagation
config
is
there?
Should
that
be
sufficient
for
somebody
to
implement
a
complete
workflow
using
whatever
mechanism
difference
to
might
might
be
active
controllers
or
something
some
model?
I
think
that's
a
I
think
that's
a
valid
question.
D
And
I
think
off
the
top
of
the
head
of
my
head.
The
answer
is
that
if
you
want
your
code
and
API
is
to
kind
of
coexist
with
others
that
other
people
have
built,
you
need
to
have
some
kind
of
rendezvous
points
for
those
different
pieces
of
code
and
and
currently
those
rendezvous
points.
Are
these
API
objects?
If
you
wanted
to
imp-
and
let's
say
a
single
controller
that
did
all
of
this
stuff
and
had
you
know
one
set
of
inputs
which
perhaps
encompass
all
of
cluster
preference
placement
preferences
template
substitutions
propagation
configuration?
D
All
of
that
you
know,
maybe
you
put
that
in
some
other
third-party
resource.
That's
called
something
completely
different
and
you
implement
a
single
controller
that
takes
all
of
that
as
input
and
you
know,
does
a
either
a
reconciliation,
loop
or
a
once-off
workflow.
Then
I
think
you
can.
You
know,
nobody's
going
to
stop
you
from
doing
that,
but
but
it
means
that
nobody
else's
propagation
controller
or
anything
will
work
well.
D
Nobody
else's
template,
substitution
or
scheduler
will
work
with
your
code
or
with
your
objects,
and
if
you
do
want
to,
you,
know,
allow
other
alternative,
schedulers
or
template
substitution
mechanisms
or
policy,
plugins,
etc,
that
those
external
agents
at
the
top
right
of
the
document.
Then
then,
you
need
to
kind
of
adhere
to
this.
This
thing
that
that's
my
thinking
at
least,
does
that
make
sense.
D
C
So
if
I
am
thinking
clearly
and
what
I
have
understood
so
far,
is
that,
as
a
result
of
all
this
exercise
that
we
are
doing,
we
would
ideally
converge
to
a
particular
API,
spec
and
probably
some
other
controller
implementations
also.
But
the
main
point
of
convergence
would
be
the
API
spec
for
all
these
objects
and
that
we
should
be
be-all
or
whoever
is
implementing.
You
should
have
a
common
I.
D
For
that
they
can
either
enhance
the
generic
thing
and
say
we
need
to
enhance
it
in
order
to
support
this
new
type.
You
know
iterated
HPA
or
whatever
it
happens
to
be,
or
they
can
augment
it
with
some
other
stuff.
For
that
time,
which
is
you
know
only
useful
for
that
type,
and
therefore
we
do
some
like
special
stuff
for
that
time
that
that's
sort
of
the
direction
I'm
thinking
of
in
its
one.
D
Other
brief
comment
to
sort
of
go
back
a
little
bit
is
that
the
the
implementation
v1
that
we
currently
have
going
back
to
your
previous
command
earphone?
Basically,
it
has
custom
preference
placements
cluster
placement
preferences,
template
substitution
preferences
and
what
else
and
yeah
it
has
all
of
that
in
contained
in
annotations
on
the
base
type,
and
it
also
updates
the
base
type
with
with
what
we've
called
propagation
status
here.
So
you
can
see
you
know
how
many
of
your
replicas
are
running,
etc.
D
So
that
is
an
instance
of
what
you
mentioned
earlier
is
sort
of
a
non
conformant
implementation
of
the
cementation
yeah,
but
I
do
think
that,
to
the
extent
that
we
want
to
make
this
flexible
and
allow
people
to
customize
their
schedulers
or
do
fancy
template
substitution
and
implement
you
know,
policy
enforcement,
etc.
I
think
we
do
need
to
have
a
reasonable
standard
that
that
people
can
plug
all
those
things
into,
and
this
the
intention
of
this
document
is
to
kind
of
agree
on
the
high
level
architecture
and
design
of
that
cool.
C
C
One
implementation
could
be
that
that
the
objects
would
not
be
propagated
into
the
places
at
all.
The
other
implementation
could
be
that,
in
the
absence
of
gesture
placement
references,
the
default
behavior
is
that
they'll
be
propagated
to
all
the
objects,
because
this
particular
object
is
missing.
That
means
it's
a
default
behavior
of
the
implementation,
but
it
just
propagates
to
all
that.
Yeah.
D
D
Could
go
either
way,
I
mean
what
I
do
know.
Is
that
if
you
don't,
if
there
are
no
cluster
placement
decisions,
nothing
will
be
substituted
into
the
templates
and
therefore
the
templates
at
the
substitution
outputs
looking
at
the
document
will
not
exist
unless
somebody
puts
them
there
manually
and
therefore
propagation
won't
happen
because
it
doesn't
have
its
in
place.
D
But
what
happens
if
so,
maybe
that
would
be
a
useful
discussion
like
what
exactly
happens
if
there
are
five
stacks
of
blue
cards?
Sorry,
six
decks
of
blue
cards
and
diagram,
starting
with
top
left
cluster
placement
preferences.
Cluster
placement
decisions,
template
substitution,
preferences,
substitution,
outputs
and
propagation
config.
So
a
valid
question
would
be
for
each
one
of
those
stacks
of
cards.
How
is
the
system
expected
to
behave
if
it
doesn't
exist?.
C
Let
me
put
a
little
perspective
to
the
question
so,
for
example,
sake.
Exactly
ask
me
that
as
implementers
or
a
reference
implemented
in
open
source
should
be
defined
as
part
of
this
exercise
that
we
are
doing,
because
we
are
trying
to
come
at
consensus,
should
we
define
that
users
who
interact
with
whichever
implementation
of
this
API
ideally
gets
a
consistent
experience
right
or
my
answer
was
I
have
a
different
opinion.
My
answer
was
that
I,
really,
we
should
actually
is
the
implementation
of
the
API,
defines
what
the
user
behavior
is.
C
A
C
D
Let
me
just
finish
for
a
second
murder
sure,
and
if
you
want
something
different
than
that,
you
need
to,
and
and
and
this
will
have
to
get
to
the
specifics
of
the
arrows
in
the
diagram.
But
but
in
principle
you
need
to
write.
There
needs
to
be
some
kind
of
piece
of
code
that
generates
the
necessary
things
to
make
the
workflow
proceed
or
a
user
has
to
add
the
missing
bits.
D
So
cluster
placement
preferences
are
actually
only
a
requirement
for
scheduling,
and
so,
if
you
don't
have
a
scheduler
and
it
doesn't
need
to
proceed,
you
don't
need
any
of
those
and
the
default
is
use
it
if
the
user
doesn't
provide
them.
The
default
is
that
plus
the
placement
scheduling
won't
happen,
which
seems
to
be
stable,
however,
caveat
there.
Is
that
the
output
of
cluster
placement
is
not
a
requirement
for
temporal
substitution
because
it
template
substitution
can
take
a
base,
federated
resources
in
put
a
cluster
placement
decision
and
a
template.
D
Substitution
preference
and
the
workflow
can
proceed
from
there.
So
if
you
have
those
three
things,
template
substitution
will
happen
by
default.
If
you're
missing
substitution
preferences
or
cluster
placement
decisions,
which
I
think
we
call
whatever
something
different,
then
the
in
template
substitution
won't
happen,
and
if
you
want
it
to
happen,
you
need
to
create
those
things
or
have
a
piece
of
software.
It
create
the
default
versions
of
those
things
for
you.
E
Think
I
I
think
that
what
you're
describing
makes
entirely
it
makes
sense
when
you
have
a
scheduler
involved.
If
you
weren't,
involving
scheduler
I,
think
the
minimum
requirement
is
a
template
and
a
placement
decision,
and
not
necessarily
a
as
you're
calling
substitution
preferences
and
I'm
kind
of
thinking
more
a
little
bit
lower
level.
I
would
say
like
substitution
decision.
E
The
reconciler
that
I
have
been
working
with
basically
well,
it's
a
substitution
output.
By
the
way
I
mean
that
the
idea
of
template
substitution
to
me
I'm
having
a
little
you
know,
I.
Sometimes
they
can't
hold
two
things
in
my
head,
but
for
a
given
cluster
like
an
irreconcilable,
Oscar
I
say
get
object
for
cluster
and
I'll
pass
the
template
the
placements
and
the
overrides
or
substitution
resource,
and
that
will
return
our
an
object
or
it
won't
actually.
E
No,
in
this
case,
it's
just
always
returning
an
object,
because
the
decision
like
the
placement
is
actually
considered
before
sorry
so
that
get
object
for
cluster.
It
basically
just
requires
the
template
and
the
overrides.
If
you
don't
have
overrides
there's
nothing
required
like
you
can
still
just
provide
the
template.
Sorry,
if
there
like,
you,
can
generate
the
resources
it
should
appear
in
the
cluster
without
the
overrides.
In
the
case
of
not
using
a
scheduler
I.
E
Think
we've
discussed
that
when
you
have
a
scheduler,
you
kind
of
require
that
that
new
substitution
decision,
or
whatever
appears
just
because
otherwise
you
don't
know
that
scheduling
has
been
performed,
but
without
a
scheduler.
You
really
just
need
a
placement
and
a
template
here.
You
know
what
do
I
want
to
put
in
and
where
do
I
want
to
put
it,
but.
D
Something
has
to
tell
that
so
I
think
you,
you
do
have
a
template
substitution
procedure
in
your
mind,
so
there
there
is
a
step
where
you
take
a
template
which
is
on
the
far
left
of
the
diagram,
and
you
take
a
cluster
placement
decision
which
is
I,
want
this
cluster
a
B
and
C,
and
you
then
produce
something
that
needs
to
get
propagated.
In
the
case
of
a
B
and
C,
you
produce
three
different
things:
each
one
needs
to
be
propagated
to
a
different
cluster.
Just
one
quibble.
E
E
E
D
The
top
right
hand
corner
the
template
substitution
preferences.
I
can't
remember
if
I'd
defined
that
in
any
better
detail
in
the
in
in
the
document.
But
the
intention
there
was
like
something
that
tells
that
pink
box
called
or
that
pink
elliptical
template
substitution.
How
to
apply
cluster
placement
decisions
into
the
template
and
produce
an
output.
D
D
C
D
D
Okay,
so
so
let
me
just
be
clear:
sorry,
I'm,
rambling,
a
bit
here.
So
this
is
the
paragraph
I'm
talking
about
here.
Template
substitution
preferences
are
defined
to
be
a
set
of
rules,
defining
how
and
what
values
are
substituted
into
templates
on
a
per
cluster
basis.
For
example,
if
cluster
is
cluster
a
then
images,
blah
and
replicas
is
blah
or
if
selected
cluster
has
label
region
equals
Europe
and
the
secret
to
use
is
BA.
So.
E
E
D
Actually,
this
this
top
right
hand
thing
came
out
of
your
preference
I
believe
that
you
specified,
which
is
that
you
want
to
be
able
to
customize
the
thing
that
gets
propagated
into
each
cluster.
I
think
there
was
more
than
so.
One
of
the
obvious
things
is
the
number
of
replicas
that
goes
into
a
given
cluster.
Could
change
your
cluster
and
I
thought
I,
understood
that
you
know
configuration
might
change
per
cluster
and.
D
Yeah
things
like
secrets
or
any
any
data
associated
with
the
thing
being
propagated
might
be
different
depending
on
the
cluster
yeah,
and
is
your
thinking
that
that
that
is
simply
like
every
cluster
has
a
name,
and
that
name
is
like
embedded
in
either
the
secret
name
or
the
configuration
name
or
anything
else
that
gets
propagated
into
the
cluster
I
thought
it
will
know
more
than
that.
So.
E
A
E
Way
and
it
used
like
a
selector
and
my
thinking
and
I
think
Paul's
thinking
sort
of
evolved
since
then,
so
that
we
treat
some
selector
based.
Associativity
is
a
higher-order
thing
and
propagation
only
focuses
on
a
resource
that
consists
of
cluster
named
substitution,
values,
cluster
name,
substitution
values,
and
there
would
be
a
controller
if
the
user
wanted
to
have
this
behavior
be
more
dynamic.
E
D
So
I
think
we've
uncovered
a
fundamental
misalignment
of
understanding.
It
though
so
maybe
I
can
describe
my
understanding
and
we
can
see
if
we
can
come
to
some
common
agreement.
So
the
the
thinking
encapsulated
in
this
diagram
is
that
the
propagation
mechanism,
the
bottom
left-hand
ellipse,
does
nothing
other
than
take
specific,
explicit,
kubernetes
resources
and
propagate
them
to
clusters
and
any
template
substitution
that
is
required
to
generate
those
things
that
need
to
be
propagated.
The
clusters
happens
in
the
previous
step,
called
template,
substitution
and
so
the
propagator
that
the
propagation
procedure
at
the
bottom
left.
D
There
is
not
doing
any
template
substitution,
it's
taking
already
substituted
templates
and
just
pushing
them
into
clusters.
So
it
knows
like
how
to
get
to
that
cluster.
What
what
credentials
to
use
to
connect
to
the
cluster?
You
know
what
the
API
endpoint
of
the
cluster
is,
and
it
just
takes
that
thing
and
pushes
it
there
all
close
it
so
that
propagation
mechanism
could
actually
be
something
outside
of
the
Federation
could
be
like
sitting
in
the
cluster,
for
example,
but
conceptually
it
does
exactly
the
same
thing.
E
E
With
it
right,
so
it's
not
it's
not
like
an
actual
what
I
mean
in
the
key
it
talks
about,
like
consumes
procedure,
generates
a
pair
resource,
we're
talking
about
an
API
resource
that
just
sort
of
exists
in
space,
not
the
one.
That's
been
serialized
to
like
any
API
where
you'd
watch
it
or
anything
like
that,
is
that
the
differentiation.
D
E
Sense,
I,
don't
quite
understand
what
you
mean
so
if
I
was
to
like,
if
I'm
looking
at
go
code
and
I'm
like
you
know,
secret
equals,
you
know
core
v1,
secret
and
I
define
this
like.
Basically
it
an
instance
of
a
secret
as
a
variable
but
I
haven't
see
realized
that
I
haven't
gone.
You
know,
client,
don't
create
or
anything
like
that.
You.
E
So
that's
sort
of
the
differentiation
I'm
trying
to
make
is
that
the
substitution
outputs?
Are?
They
don't
exist
in
the
API
they've
been
created
like
they
represent
the
form
of
the
resource
that
we
want
to
exist
in
the
underlying
cluster
and
the
propagation
mechanism
will
create
it,
but
there's
no
intermediate
step
where
it's
serialized
and
then
the
propagation
mechanism
will
read
it
out
of
the
API.
So.
E
D
E
Yeah
I
mean
I
think
that
the
the
utility
in
sort
of
defining
template
placement
overrides
sort
of
dumb
resources
that
are
composed
the
propagation
mechanism,
and
it
could
be
that
it
generates
configuration
for
cube
applier.
It
could
be
that
it's
kind
of
similar
to
the
federation,
v1
reconciler,
but
it
would
consume
any
of
those
Becca's-
would
consume
those
objects
and
then
send
the
form
that
was
desired
to
the
clusters
that
were
requested
and
just
to
me
that
it
satisfies
the
property
of
being
composable.
E
Because
then
you
can
have
arbitrary
ways
of
deciding
overrides
or
substitutions
or
placement,
and
you
can
have
arbitrary
ways
of
deciding
how
to
take
the
composed
resources
and
do
something
with
them
and
I
guess.
The
attention
might
be
because
I'm
not
really
thinking
so
much
from
the
automated
level.
At
this
point,
I'm
trying
to
sort
of
do
a
sort
of
a
bottom-up
reimagining
of
this
but
I
I,
guess
when
I
think
about
it,
I
don't
see
why
you
couldn't
have
a
scheduler
that
did
automatic
scheduling.
E
It
would
boil
down
to
these
resources
and
then
have
a
propagator
like
because
to
me,
propagation
doesn't
seem
entirely
simple.
There's
all
kinds
of
corner
cases
and
gushes
and
I'm
not
sure
having
multiple
implantation
zuv
the
same
thing
makes
sense:
I
mean
I'm,
not
saying
it's
I
mean
people
can
do
whatever
they
want,
but
it
you
know
if
we
have
a
propagator,
that's
effective
at
communitary
types
and
can
handle
all
the
corner
cases.
E
It
means
that
there
could
be
more
focused
on
you
know,
getting
a
really
good
scheduler
implementation
in
place
or
are
getting
integration
with.
You
know
cloud
resource,
orchestration
and
there's
something
like
that,
rather
than
you
just
treat
the
propagator
as
a
given,
and
you
can
do
like
more
stuff
on
top
and.
D
I'm
not
sure
I
mentally
digested.
All
of
that,
but
I
guess
in
the
background.
I
was
thinking
that
we
have
at
least
three
proposed
propagators
at
the
moment.
I
think
one
is,
you
know,
cute
control,
so
cute
control
could
basically
best
script,
a
very
thin
bastard,
wrapped
around
control,
which
could
read
a
bunch
of
resources.
Out
of
you
know,
github,
which
would
be
a
substitution
outputs
and
push
them
into
the
clusters
or
pull
them
into
the
clusters.
So
so
people
have
described
such
a
thing
as
being
desirable.
D
Then
we
have
something
more
akin
to
the
current
replica.
Sorry,
the
current
Federation
implementation,
which
is
an
active
controller,
long-running
thing
which
is
watching
an
API
and
either
pulling
or
pushing
things
into
a
cluster,
and
then
we
have
more
of
a
sort
of
a
one-off
workflowy
type
thing
which
might
be
spinnaker
or
something
else
which,
similarly,
you
know,
one
of
the
final
phases
is
to
push
things
into
clusters.
So
I
think
I
think
the
that
there
is
a
clear
requirement
to
have
more
than
one
kind
of
propagator.
D
E
D
Should
you
and
I
take
this
offline
and
and
talk
about
it
today
and
tomorrow,
and
then,
hopefully,
we
can
still
like
finalise
stuff
by
Monday,
which
was
then
because
it
seems
I
think
we're
roughly
on
the
same
line,
and
if
you
can
hang
around
on
this
call
and
be
happy
to
stick
around
here,
everybody
else
wants
to
leave
now.
I'm
sure
some
of
them
are
gonna,
get
kicked
out
of
rooms,
so
they
will
leave
anyway.
Let's
do
that.
E
E
My
thinking
is
that
all
of
these
propagation
mechanisms
haven't,
like
the
common
element,
is
still
all
like
I
need
to
know
the
base
representation
which
clusters
the
research
that
you're
in
and
some
sort
of
way
of
defining
per
cluster
variation.
So
I
have
standard
ways
of
representing
all
three,
then
any
positive
just
to
be.
D
E
Yeah
I
guess,
but
there's
two
sort
of
layers
to
this
one
is
something
that
is
so
simple
that
it's
don't
like.
It
doesn't
require
any
processing
or
intelligence,
and
there
isn't
really
a
need
for
providing
special
capabilities,
because
it's
just
the
lowest
level
primitive
for
allowing
per
cluster
variation.
E
And
if
you
want
something
more
complicated,
you
can
have
a
layer
on
top
of
that
that
generates
that
base
level
representation
out
of
whatever
you
want,
and
so
my
my
conception
is
that
I
want
to
sort
of
have,
because
the
propagation
mechanisms
will
tend
to
be
the
more
or
the
reconciler
words.
They'll
tend
to
be
like
what
everybody
will
be
having
in
common,
even
if
there's
three
different
versions,
those
that's
kind
of
like
that
has
to
be
rock-solid
that
can't
be
buggy
or
error
prone
or
whatever
that's
the
shared
piece.
E
E
Let's
call
it
like
a
substitution
decision
just
to
be
parallel
with
like
how
we've
described
temp
reference
like
placement,
preference
versus
placement
decision,
I
kind
of
think
it
the
same
way
of
like
substitution,
I,
think
of
substitution,
preference
which
could
be
selector
based
or
you
know,
more
dynamic
versus
a
substitution
decision,
which
is
cluster
named
value.
That
should
appear
in
the
template
for
that
cluster.
If
I
separate
those,
then
the
propagation
mechanisms
can
just
work
on
the
decisions,
the
placement
decision,
substitution
decision
and
template,
and
then
everything
else
can
be
handled.
You
know
arbitrarily.
E
C
C
E
Will
be
an
API
resource
but
I'm
the
reason
I'm
a
little
bit
confuses
and
the
document
substitution
outputs
appears
to
be
like
if
I
had
a
like
a
federated
replica
set
and
its
placement
in
a
substitution
resources
and
I
would
actually
generate
substitution.
Outputs.
That
would
be
essentially
like
a
replica
set.
It's
a
cumin
that.
D
Editor
and
why
and
where
is
actually
already
unless
somebody
removed
that
there
is
actually
a
cluster
filled
in
that
metadata
of
every
kubernetes
resource,
just
as
a
as
an
FYI,
so
in
that,
assuming
that
that
has
field
is
not
yet
being
removed,
would
I
think
there
was
some
talk
about,
perhaps
removing
it
that
that
thing
that
is
currently
called
a
substitution
output
could
be
precisely
a
kubernetes
resource
like
zero
difference.
So.
E
A
E
If
I
have
a
namespace
food,
I
mean
I,
wish
I
had
a
white
word
for
this,
but
if
I
have
namespace,
foo
and
I
have
replica
set
federated
replica
set
X
in
that
namespace.
If
I
was
to
be
federating
into
that
namespace,
because
I've
joined
that
cluster,
like
I,
would
have
a
like
for
each
cluster,
I
would
have
a
namespace
or,
and
I
would
have
it
a
replica
set
that
represented
the
form
that
I
wanted
to
appear
in
whatever
member
cluster
and
I.
E
Guess
you
could
do
it
if
you
name
things
like,
if
you
had
some
sort
of
name
form
that
would
differentiate
it
from
the
resources
you
actually
want
it
to
run.
But
the
conflict
for
me
is
that
this
may
be
a
functioning
cluster,
and
so,
if
I
create
a
replica
set,
even
if
I
name
it
something
you
need
to
differentiate
from
the
actual
workload
I
want
to
run
like
to
me.
It
adds
a
lot
of
potential
for
confusion,
because
I
have
a
federated
replica
set.
I
generate
replica
sets
in
the
same
name.
D
I
guess
my
thinking
was
that
the
you
know
down
in
the
brass
text:
implementation
details
the
stuff
that
Federation
stores
is
actually
stored,
currently
in
a
different
HDD
than
the
stuff
that
the
host
kubernetes
cluster
stores
and
stuff
in
now,
I'm
not
saying
we
have
to
do
that
in
future.
But,
logically,
that's
like.
D
D
Now,
okay,
we
actually
create
a
thing
called
a
replica
set
in
the
Federation
API
and
it
has
could
have
precisely
the
same
name
namespace
and
could
be
identical
to
a
replica
set
in
the
host
cluster,
and
there
would
be
no
name
clashing
and
it's
very
clear
that
one
is
a
Federation
thing
and
it's
called
replica
set
and
it
is
logically
a
federated
replica
set.
It
has
exactly
the
same
name,
a
name
space
as
a
replica
set
in
the
host
cluster,
but
that
doesn't
cause
any
implementation
problems.
D
However,
I
agree
with
what
you're
saying,
which
is
that
in
future
implementations
that
not
may
not
be
the
case,
so
all
of
these
things
could
be
actually
sitting
in
the
same
it
CD
in
the
same
logical
API
surface,
and
we
would
have
to
use
some
other
mechanism
to
distinguish
these
two
potentially
identically
named
things,
and
maybe
API
groups
is
that
thing.
Maybe
there
are
lots
of
different
api
groups,
but.
E
Essentially,
that
would
imply
like
to
me
that
gets
into
the
same
problem.
We
have
today
of
confusion
over
which
API
surfaces
kubernetes
and
which
is
federated,
so
the
scheme
I've
been
sort
of
working
with
is
that
the
federated
resource
has
a
name.
You
know
it's
there's
no
like
if
you
create,
if
you
create
a
replica
set
in
in
that
namespace,
because
you're
you're
propagating
it
to
the
same
cluster
and
the
replica
set
controller
is
going
to
run
that
workload,
and
so
it's
not
just
a
matter
of
differentiating
things
that
are
going
into
different
clusters.
E
D
Know
a
lot
more
work
so
that
problem
I
mean
I.
Don't
disagree
with
you.
I
I
typically
agree
with
the
problem.
I
guess
I
just
don't
see
that
it
is
such
a
big
problem
in
the
sense
that
we
seem
to
have
many
different
ways
to
make
sure
that
the
kubernetes
replica
set
controller
in
the
host
cluster
does
not
like
read
our
stuff
and
think
it
needs
to
do
something.
If.
E
D
D
C
D
E
D
That
why
is
to
make
to
answer
your
question
the?
Why
is
to
make
propagation
as
simple
as
possible
so
that
it
can
have
a
very
focused
intention,
which
is
to
take
like
actual
kubernetes
resources,
modular
being
maybe
in
a
different
egg,
a
group
but
but
they're
conceptually
exactly
what
needs
to
go
into
a
cluster
and
propagating
them
they're,
as
distinct
from
taking
a
set
of
cluster
placement
decisions
and
some
other
logic
that
decides
how
those
you
know
perform
some
form
of
what
you've
been
calling
overriding
and
what
I've
been
calling
substitution
and
what
we
were.
D
D
They
would
have
to
either
use
both
of
your
things
in
the
same
or
throw
them
both
away
and
re-implement,
better
and
I.
Think
that's
fine,
so
I
think
we
have
a
way
forward
here.
I
think
you
can
do
what
you
want
to
do.
What
I
understand
you
want
to
do,
but
I
don't
think
that
that
needs
to
be
the
only
way
to
do
it.
D
I
think
having
separate
procedures
for
doing
the
template,
substitution
and
the
propagation
is
fine,
and
if,
if
we
want
to
be
able
to
swap
out
the
two
pieces
independently
of
each
other,
they
need
to
have
some
rendezvous
point
in
between
and
that
is
currently
called
substitution.
Outputs
which
everyone
has
suggested,
we
call
kubernetes
resources,
which
I
think
is
a
good
idea.
E
I,
don't
think
that
I
have
enough.
Okay,
so
I
will
say
that
what
you're
saying
is
completely
valid
as
an
approach
to
doing
things.
I,
don't
think
I
have
enough.
I
haven't
internalized
this,
so
I,
don't
know
what
the
gotchas
are
or
like.
Basically,
not
the
gosh
the
pros
and
the
cons.
Mm-Hmm
I've
been
kind
of
working
from
a
slightly
different
perspective.
I
don't
think
I
could
say.
This
is
something
that
I
would
be
supportive
or
not.
Okay,
run
away
until
I
have
time
to.
A
E
D
D
D
D
D
Because
I
think
that
is
pretty
fundamental
here,
if
you
don't
want
to
generate
all
these
intermediate
bits
and
pieces-
and
you
just
want
to
write
one
piece
of
software
that
does
all
of
this
stuff
or
we,
you
don't
need
some
of
this
stuff,
but
your
single
process
implements
all
the
stuff
you
need
like,
for
example,
substitution
and
propagation
I.
Think
that
should
be
totally
fine.
With
the
caveat
that
it's
an
all-or-nothing
thing,
so
people
cannot
swap
out
the
propagation
part
of
it
easy
unless
they,
unless
you
have
a
flag.
D
That's
on
your
controller
that
says
like
don't
do
propagation,
but
that,
but
then
it
needs
to
like
output,
the
stuff
that
somebody
else
needs
to
propagate
somewhere.
Somehow
and
and
that's
the
the
bottom
righthand
loose
back
of
things
in
the
diagram,
but
I
can
I
can
add
specific
wording
to
the
document
to
describe
that.
I
think
it's
perfectly
valid
use
case
and
I
think
it
needs
to
be
explicitly
spelled
out.
E
Right,
I,
don't
yeah
I
mean
there's
no
logical
reason,
I'm,
worried
or
concerned
like
what
you're
suggesting
is
perfectly
they're
all
I'm,
just
I'm
more
worried
about
the
implement
implementation,
concerns
and
kind
of
to
me.
Part
of
this
is
ensuring
that
it's
scalable
like
if
I
want
to
support
a
bunch
of
new
types
that
someone
is
implementing
I
want
not
to
be
attractive.
All
problem
and
I
also
want
the
user
experience
of
like
troubleshooting
or
working
with
the
system
to
be
as
straightforward
as
possible.
Yeah.
D
So
I
think
one
of
the
first
things
I
would
like
to
do
and
I
think
I
can
sign
us.
Our
company
up
to
this
is
to
produce
at
least
one
reference,
implementation
of
a
sort
of
most
complex
version
of
what's
described
in
this
document,
or
at
least
one
complex
type
and
I
think
deployment
seems
like
the
most
sensible
one
of
those
and
and
and
hopefully
that
will
uncover.
D
E
Does
I
kind
of
think
that
that's
working
in
a
really
there's
just
that's
a
big
problem
space
when
we
talked
about
doing
deployments
and
being
able
to
do
Bluegreen
deployments
across
clusters,
that's
kind
of
in
an
active
area
of
research,
so
my
only
concern
with
that
would
be
that
it
it's
trying
to
solve
one.
Maybe
too
many
things
at
once.
It's
like
we're
trying
to
prove
something
out,
but
we're
also
trying
to
pioneer
a
way
of
doing
cross,
bus
or
Bluegreen
deployments
I'm.
E
D
F
E
D
E
Reason
it
was
done.
That
way
is
because
you
didn't
want
to
create
a
bunch
of
accounting
like
resources.
That
would
do
the
accounting
required
and
he
was
proposing
just
to
use
replica
sets
to
do
that.
But
I
think
then
now
that
you
can
create
your
own
resources,
there's
definitely
better
ways
to
do
that.
Yeah.
E
D
Yeah
I
think
we
can.
We
can
tackle
that.
Maybe
we'll
factor
out
some
of
the
more
difficult
pieces
to
later
and
do
the
easier
bits
first
I
think
that's
totally
awesome.
So
it
looks
like
we're
almost
ready
to
work
around
closed
modular,
your
inputs
by
Monday
and
not
closed
in
the
sense
of
we
won't
take
any
more
inputs
but
closed
in
the
sense
of
we're.
Actually
gonna
go
and
build
the
stuff
now
or
produce
detailed
designs
and
build,
and
and
it
would
be
a
valid
if
someone
comes
back
and
says
no,
that
design
is
bad.
D
It
will
be
a
valid
response
to
say.
Well,
it's
consistent
with
what
we
agreed
upon
in
the
document
so
either.
We
agree
that
it
is
consistent
and
move
forward,
or
we
agree
that
it
invalidates
the
document
in
some
way
and
then
we,
for
example,
if
someone
starts
implementing
something
Disgaea
discovers
that
what's
described
in
the
document,
is
not
tenable
and
therefore
comes
up
with
an
alternative
approach.
D
E
I,
don't
think
is
really
something
we
design
like
we'll
have
suggestions
will
have
approaches
but,
like
hope,
are
the
whole.
The
hope
my
hope
is
if
we
can
make
this
sort
of
a
framework
for
implementing
Federation
like
things.
Hopefully
we
can
encourage
participation
and
I
get
your
point
that
we
need
to
actually
have
some
framework
for
people
to
work
within,
and
it's
not
there
yet
I.
Just
don't
want
to
stray
from
like
avoiding
being
too
prescriptive.
I
guess
that's
my
god.
Yeah.
D
If
you
implemented
a
combined
template
substitute,
ER
and
propagator,
you
could
not
generate
substitution
outputs
and
we
described
that
in
the
document
and
that's
a
valid
implementation
of
this
general
architecture
and
in
addition
to
that,
you
can
define
defaulting
or
implement
defaulting
of
some
of
these
other
API
objects.
For
example,
cluster
placement
preferences,
like
are
not
required
and
the
procedure
can
come
continue
without
them,
etc
and
put
those
in
words
so
that
it
is
clear
this.
D
This
implementation
is
consistent
with
the
architecture
and
this
implementation
is
not
consistent
and
maybe
I'll
actually
put
some
concrete
examples
of
consistent
and
inconsistent
ones.
Nobody
is
going
to
like
prevent
anyone
from
implementing
an
inconsistent
implementation,
but
it
will
be,
you
know,
explicitly,
inconsistent
and
therefore,
or
give
any
of
the
important
will
not
necessarily
give
the
purported
benefits
or
features
of
the
general
architecture.
Cool
sounds
good.
F
C
The
phone
that
is
so
IV
actually
saying
that
we
can
have
one
place
where,
where
the
spec
is
a
pH
specimen
or
can
be
converging
into
it,
could
be
any
location
like
it
could
be,
an
external
that
will
turn
in
the
power
whatever
body
and
implementation
of
procedures
or
the
workflow
could
be
anything
better.
Yeah.
D
That's
a
valid
question:
I
I
kind
of
been
pondering
it
I
agree.
We
need
to
decide
on
that
soon,
like
probably
on
Monday
two
options.
It
came
to
my
mind,
which
both
have
pros
and
cons
the
one
is.
There
is
now
a
procedure
where
you
can
get
a
sig
approved
repository
in
forget
where
the
actual
I
think
there's
an
organization,
kubernetes
organization,
separate
from
the
core
one
which
has
a
bunch
of
repos
and
as
long
as
you
get
sig
approval,
you
can
create
a
sig
owned,
renew
repo
in
there
that
are
good
little
pig
yeah.
D
E
D
Agree
with
you,
it
has
the
benefit
that
we
sort
of
have
a
grandfathered
in
thing,
which
is
like
the
official
kubernetes
Federation,
and
it
seems
like
that
might
be
a
good
place
to
work
where
a
reference
implementation
of
this
might
end
up.
I
agree
that
it's
not
I,
don't
think
we're
there
yet
so
so
I
think,
maybe
as
a
future
step
if
there
was
a
reference
implementation
in
that
repo.
That
was
part
of
like
the
kubernetes
organization.
E
We
don't
want
to
maintain
that
till
I
know
I
mean
I,
guess
my
proposal
would
be
what
we're
going
to
maintain
it
somewhere
right.
So
we
have
dollops.
That's
the
thing.
The
new
API
server
builder
stuff
obviates
the
mean
the
whole
climate.
It
is
that
it's
enabling
a
multi
repo
future
of
kubernetes
and
if
we
cling
to
the
existing.
D
D
A
E
D
E
D
Your
helping
set
up
a
new
repo.
So
so
can
we
get
to
the
side
now
that
we're
going
to
create
a
new
sig
Leste
repo
in
the
new
celeste
kubernetes
organization,
and
that
we're
gonna
use
that
as
the
location
for
the
reference
implementation
we'll
call
it
that
maybe
which
is
not
the
you
know
the
be-all
and
end-all,
and
only
one,
but
it
is
at
least
a
reference
implementation
of
the
architecture
of
which
they
might
be
any
number
of
variants,
which
are
what
reference
implementations
is.
E
A
E
C
Yeah
I'm
so
sorry
for
interruption
too.
My
intention
was
to
at
least
like
we.
We
did
talk
about
that
where
we
exactly
converge
and
we
converge
at
the
speck
of
the
yes.
My
intention
is
sort
of
keeping
the
speck
of
the
API,
at
least
at
one
place,
whichever
place
that
might
be
I'm
not
suggesting
anything
specific
like
it
should
be
there
in
a
particular
type
over
there,
but
but
at
some
common
place,
and
we
all
sort
of
converged
to
that
API
spec
and,
for
example,
in
this
document
in
the
workflow
and
the
diagram.
C
If
you
see
there
are
probably
six
different
API
A's
resources
being
represented
over
here,
so
we
have
definition
a
converged
definition
of
these
resources
over
there,
and
if
that
happens,
then
we
can
have
reference,
implementations
or
single
difference
implementation
which
we
all
will
converge
on
of
the
controllers.
That
was
my
intention.
Ii,
yes,.
D
I
totally
agree
with
your
phone
and
and
I
would
yeah
I
would
like
us
to
see
to
see
the
end
result
of
this
exercise
be
at
least
the
precisely
those
two
things
so
API
specs
that
people
can
go
and
implement
and
write
controllers
against
and
such
things
and
reference
implementation
for
the
envisaged
controllers,
which
is
which
need
not
be
the
only
implementation
or
anything
but
but
I.
Think
specs
without
reference
implementations
are
notoriously
unsuccessful,
so
we
need
at
least
one
reference
implementation,
maybe
more
and
to
answer
your
previous
question.
D
D
Curious
actually,
what
that
name
stands
for
all
means:
Federation
new
order
or
something
something
like
that
eyes.
But
yes,
I
think,
let's
use
as
much
of
that
as
we
can
and
and
hopefully
that
can
expedite
you
know
putting
stuff
into
this
reference,
Rico
and
similarly
I
think
we
can
probably
take
pieces
out
of
the
existing
Federation
and
reuse
them
as
well.
D
D
Awesome
all
right,
let's
wrap
it
up,
then.
Can
we
see
each
other
on
Monday
and
feel
free
to
I
think
we're
cool
man.
They,
like
the
the
day,
we're
going
to
like
stamp
this
thing
and
say
this
is
what
we
provisionally
agreed
on
modular
changes
in
the
future,
based
on
the
implementation
cool
thanks,
guys,
okay,.