►
From YouTube: Kubernetes Federation WG sync 20180305
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
B
A
A
C
Said
it
was
we
last
meeting,
we
were
actually
discussing
the
workflow
and
API
structure
that
Quinton
published,
and
we
were
able
to
talk
about
some
of
the
comments
that
were,
and
maybe
the
result
and
one
specific
pointer
that
we
left
on.
While
we
finished
the
meeting
we
ran
out
of
time
in
the
previous
meeting
was
Quinton
and
Maru
probably
had
an
argument
over
what
should
be
the
exact
structure
that
we
should
use
of?
What
should
be
the
exact
base,
API
that
they
should
use
for
placement,
so
they'll
be
the
simply.
C
The
question
is
the
on
the
on
the
individual
object
or
a
separate
object.
It
is
done
to
one
map
to
each
editorial
source
or
it
should
be
a
label
based
selector.
So
that's
where
we
were
when
we
learned
of
the
panel.
So
do
we
want
to
continue
with
that
all
I
I
suggest
we
can
continue
like
Maru
already,
is
doing
some
basic
limitation
and
trying
to
keep
it
as
simple
so
that
the
higher
level
you
are
API
is
or
higher
level
resources
could
be
created
using
that
basic
limitation.
A
C
In
that
case,
actually
we
have
been
talking
about
the
same
same
point
so
saying
concepts
in
different
ways
of
different
formats
over
the
last
couple
of
meetings.
In
fact,
more
than
last
couple
of
should
we
spend
some
time
today
to
let
me
define
what
might
be
our
work
strategy
for
next
few
meetings
and
lets
you
meet
some
months.
A
Well,
I
think
I
think
if
we
want
to
discuss
the
document,
it
might
be
a
good
idea
if
it
might
be
a
good
good
idea.
Quentin.
Maybe
you
can
like
go
over
what's
in
your
document
and
we
can
all
kind
of
like
level
set
on
that.
I
have
read
the
document,
but
I
think
it
would
be
helpful
helpful
for
folks,
especially
those
like
that,
might
be
watching
on
YouTube
later
too.
If
if
we
can
do
maybe
like
a
10
or
15
minute
overview
of
what's
in
the
document,
are
you
up
for
that
Quentin
yeah.
D
Yeah
sure
I
would
be
happy
to
do
that.
We
can
just
kind
of
walk
through
it
and
answer
any
question.
Sometimes
it's
easier
to
answer
questions
and
have
discussions
around
what's
in
document
in
person
like
this,
rather
than
in
comments
in
the
side
of
the
dock,
sir,
let
me
present
it
and
we
can
step
through
it
and
if
anyone
has
comments,
questions
or
whatever
that
are
not
yet
resolved,
we
can
hopefully
do
that
today,
cool
I'll,
do
that.
How
do
I
present
here
give
me
one?
Second,.
F
D
D
So
I'm
not
quite
sure
where
his
preferences
lie
at
the
moment.
I
think
there's
some
value
in
having
a
propagation
controller.
That
is
so
simple
all
it
knows
how
to
do
is
take
a
set
of
things
that
are
supposed
to
be
propagated
to
specific
clusters
and
propagate
them
there,
but
I
can
also
totally
understand
the
need
to
you
know,
aggregate
together
some
of
these
theoretical
controllers
that
we
have
documented
here,
so
that
they're
HAP's
all
happen
in
one
process.
D
Okay,
so
the
three
logical
processes
that
are
in
visited
in
this
document
are
those
pick
pink
circles,
ellipses
I've,
provisionally
called
them.
Cluster
placement
template,
substitution
and
propagation
and,
logically,
you
can
think
of
those
as
three
separate
controllers
per
federated
type,
and
so
what
you
do
is
you
have
a
base
federated
resource
that
are
a
replica
set
generator
deployment.
Pick
your
favorite
federated
type
inside
there
is
a
thing
called
a
template.
The
template
is
nothing
other
than
a
kubernetes
type
modular.
D
Inputs
to
the
next
phase,
which
is
that
template
substitution
preferences,
those
objects
at
the
top
right
hand
corner
of
the
diagram,
and
those
could
contain
anything
from
you
know
substitute
the
cluster
name
in
here.
For
the
you
know
a
part
of
the
name
of
the
secret,
or
they
could
include
things
like
how
many
replicas
go
into
this
cluster
or
the
next
cluster
or
some
other
cluster
and
again
those
template.
Substitution
preferences
could
be
generated
by
a
human,
so
a
human
might
decide
that
I
want
20,
Club
twenty
replicas
in
u.s.
D
East
one
a
my
cluster
B
and
ten
replicas
in
some
other
cluster,
and
they
would
specify
those
in
the
template
substitution
preferences
and
they
might
also
have
decided
that
they
want
them
in
specific,
named
clusters.
My
cluster
one,
my
cluster,
two,
my
cluster
three
and
those
in
the
diagram-
are
called
cluster
placement
decisions.
So
those
two
inputs,
together
with
the
base
federated
resource,
go
into
a
template
substitution
procedure,
and
what
that
does
is
it
generates
a
concrete
set
of
actual
things
that
need
to
be
propagated
into
clusters,
so
they
have
all
the
substitutions
applied.
D
Obviously,
the
propagation
procedure
needs
to
know.
You
know
where
the
clusters
are,
how
it
authenticates
against
them,
and
all
that
kind
of
stuff
and
I've
called
that
propagation
config.
You
can
think
of
that
as
the
cluster
registry,
although
I'm
not
sure
that
it
contains
all
the
data
that
we
need,
but
conceptually
either,
that
is
the
cluster
registry
or
it
is
stuff
generated
by
reading
a
cluster
registry.
And/Or
wenting
it
in
some
way
and
then
for
the
potential
for
more
sophisticated
cluster
placement.
D
It
would
be
possible
to
to
propagate
the
the
actual
status
of
the
clusters
and
the
status
of
the
propagations
back
into
the
cluster
placement
scheduler.
So
what
that
would
enable
us
to
do
is
a
scheduler
could
know
that
by
reading
this
propagation
status-
and
maybe
that's
not
quite
the
right
word-
it
would
be
able
to
know
things
like
this.
D
Cluster
is
uncontacted
all
we,
the
authentication
tokens
that
we
have
for
another
cluster,
don't
work
and
we
consider
both
failures
or
we
tried
to
create
a
replica
set
of
a
thousand
replicas
in
this
cluster,
but
they're
not
getting
created.
There's
like
some
errors
in
that
cluster,
either
it's
out
of
capacity
or
we're
out
of
quota
or
something.
But
it's
not
it's
not
working.
So
in
which
case
the
cluster
placement
process
could
decide.
D
Maybe
to
change
its
placement
decision
and
put
those
things
in
some
other
cluster,
because
the
one
had
wanted
to
put
them
in
isn't
working
and
we
go
around
around
the
loop
and
we
could
call
that
a
reconciliation,
loop
plus
the
placement
attempts
of
the
template,
substitution,
propagation
and
then
the
feedback
loop
which
drives
that
whole
reconvert
and
the
recode
loop
is
totally
optional.
So
so
I
guess
the
pretty
important
part
of
this
diagram
is
the
fact
that
you
can
throw
away
quite
a
few
pieces
of
that
diagram
and
you
could
still
have
a
valid
workflow.
D
D
A
E
D
E
D
Yes,
yes,
entirely,
I
could
be
cluster
registries,
you
know
it's
busy
being
renamed
and
it's
not
entirely
clear
and
I
just
haven't
taken
the
trouble
to
figure
out
exactly
what's
in
there
today
and
what
might
be
there
in
future.
But
yes,
I
envisage
that
things
like
cluster
endpoints
and
their
authentication,
details,
etc.
Who
would
probably
be
contained
in
cluster
registry
which
so
like
it's
gonna,
be
renamed
to
something
else
and
would
form
what
is
labeled
as
propagation
configuration
at
the
bottom
left
of
the
diagram
got.
E
D
I
think
to
answer
that
I
think
we've
been
somewhat
slack
about
that
in
writing,
down
the
specific
attendees
at
every
meeting
and
we
could
be
better.
We
used
to
we
used
to
keep
a
log
of
exactly
who
was
here
and
who
wasn't
here
it's
little
difficult
as
the
numbers
grow
to
keep
that
accurate,
because
you
can
either
like
leave
everyone
to
fill
in
their
name
and
then
some
people
don't
or
you
can
will
in
the
standard
set
of
people,
usually
come
and
tell
somebody
should
the
ones
that
aren't
there
and
then
that
doesn't
happen.
D
E
D
And
whoever's
here
and
wants
to
be
shown
as
attending
can
can
fill
in
their
name
there.
But
to
answer
you
I,
guess
more
direct
question
about
what,
when
we
say,
consensus
was
reached.
What
do
we
actually
mean?
Generally
some
subset
of
the
people
who
are
physically
present
at
the
meeting
sort
of
form,
the
the
the
main
participants
in
the
conversation
and
a
folder
Vince
said?
Yes,
we
kind
of
agreed
this.
D
A
D
D
A
That's
how
I
understood
it
I
mostly
I,
was
thinking
about
how,
ideally
in
the
community,
we
get
to
lazy
consensus
as
like
the
de-facto,
though,
but
I
also,
don't
think
that
the
I
don't
think
we
have
a
major
issue
with
establishing
consensus
prematurely
in
these
meetings
yet
or
anything
like
that.
So
yeah
I.
D
Agree
but
yeah
and
and
I
think
there's
a
limit
to
you
know
we
can't
send
every
single
thing
that
we
did
minutiae
of
what
we
decide
or
don't
decide.
We
can't
sort
of
send
that
all
out
for
a
two-week
email
voting
exercise
that
I
don't
think
that's
practical,
but
certainly
major
decisions
like
you
know,
here's
this
document
we
want
to
like
ratify
this
as
being
the
consensus
view
of
the
working
group.
You
know
something
like
that.
I
would
definitely
want
to
send
out
for
community
consensus,
whereas
you
know
producing
this
document.
D
G
G
Makes
more
sense
if
I
try
to
translate
this
in
terms
of
who's,
watching
what
kubernetes
resources
typically
cuz?
That's
how
I
try
to
understand
how
the
other
controllers
work,
so
the
arrows
may
be
arrow
directions.
I
would
try
to
draw
differently,
but
I'd
have
to
invest
a
bit
more
time
in
the
document
itself,
underneath
where
I
think
more
resources
are
specified.
Sure
a.
D
Christian
just
to
be
clear,
I
think
all
the
all
the
watches
that
you're
referring
to
are
the
blue
arrows
and
the
direction
of
the
arrow
just
indicates
the
direction
of
propagation.
So,
yes,
the
the
watch
would
actually
be
initiated
in
the
opposite
direction,
but
when
the
watch
triggers
the
day
the
flow
is
in
the
direction
of
the
arrow.
Does
that
make
sense.
G
G
D
Is
the
that's
not
actually
a
list
of
clusters?
That's
the
actual
clusters.
So
that's
the
clusters
that
have
API
inputs
that
that's
the
the
real
things
the
propagation
config
I
think
is
what
you're
talking
about,
which
is
a
list
of
clusters
we
can
propagate
too
and
how
to
you
know,
connect
to
them,
etcetera,.
D
G
D
G
G
Yeah
I
think
it
I
think
it
makes
sense
in
terms
of
I
think
what
you're
saying
is.
The
only
difference
is
that
the
CI
CD
actually
I'm,
not
sure
it
seems
like
the
only
difference,
seems
to
be
what
these
store
of
the
authoritative
state
is
and
whether
that's
being
reconciled
by
something
kubernetes
like
whatever
that
state
changes.
D
Yes,
so
so
I
guess
in
my
mind,
when
I
drew
this
diagram,
I
envisaged
active
controller
so
long-running
things
that,
as
you
were
saying
earlier,
use
watches
to
trigger
actions.
So
the
template
substitution
thing,
for
example,
would
be
watching
cluster
placement
decisions
and
template
substitution
preferences,
and
when
they
changed
all
new
ones
were
created.
They
would
you
know,
process
them
and
produce
the
outputs
which
the
propagator
would
didn't
want
propagate,
but
that
isn't
typically
how
a
CI
cd5
line
works.
D
You
typically,
you
know
feed
the
stuff
actively
into
those
processes,
so
the
red
circles
would
probably
be
like
bash
scripts
or
something
in
the
CI
cd5
life.
Maybe
you
would
feed
the
output
from
one
pink
circle
directly
into
the
other,
the
next
being
circled,
I
guess.
One
one
thing
we
were
trying
to
achieve
here
is
to
try
and
standardize
on
the
intermediate
data
so
that
we
could
swap
out
the
pink
so
pink
ellipses
the
processes
procedures
when
we
wanted
to.
D
So
if
we
could
standardize
on
what
a
base
federated
resource
looks
like
what
a
cluster
placement
preference
looks
like
what
a
cluster
placement
decision
looks
like,
etc.
Then
the
tools
can
interoperate
much
more
easily
and
in
particularly
you
can
throw
away
some
of
the
tools.
If
you
don't
want
them,
so
you
can
have
humans
generate
cluster
placement
decisions
if
they
know
exactly
which
clusters
they
want.
They're
going
to
you
yeah.
A
Just
to
say
a
couple
more
words
on
that,
for
example,
like
propagation
I
can
also
see,
instead
of
like
having
an
active
push
model
of
a
pull
model
where
maybe
like
the
propagation
controller,
is
writing
something
into
a
git
repo
and
and
then
there's
a
controller
running
in
each
target
cluster.
That's
pulling
things
in
from
that
git
repo
and
doing
the
reconciliation.
A
D
The
point
is,
it
looks
at
so:
it
watches
substitution,
outputs,
somewhere
and
and
in
my
head,
was
like
in
a
in
an
API
somewhere,
but
that
could
be
a
git
repo
and
it
pushes
them
at
a
cluster
API
where
it's
running
is
kind
of
irrelevant,
so
that
could
be
a
pulled
propagator
or
a
push.
Propagator
is
a
I
guess
what
I'm
saying.
G
G
D
But
but
for
example,
this
somebody
would
need
to
tell
the
CI
CD
tool,
weather
or
spinnaker
whatever
it
is
like
which
clusters
to
put
something
in
to,
and
they
would
have
to
like
write
that
in
a
file
or
feed
it
into
a
command
line
or
something
correct.
And
is
there
any
attempt
to
like
define
what
that
looks
like
I?
Don't.
A
A
Another
complementary
goal
is
that
you
should
be
able
to
deliver
the
results
of
these
things
using
the
assembly
code
type
things.
If,
if
you
want
to,
you,
should
be
able
to
adapt
like
you
should
be
able
to
write
a
controller
that
propagates
these
yes
vinegar
or
cuba,
plier
or
whatever
other
medium.
You
choose
and
I
think
I
think
that
Christian.
Your
point
is
very
apt.
There
are
a
lot
of
things
that
have
like
and
have
overlapped
with
different
dimensions.
A
This
and
I
am
NOT
an
expert
once
in
a
career
at
all
personally,
but
I
think
I
think
the
goal
is
to
find
the
right
assembly
type
assembly
level
of
resources
so
that
we
can
have
folks
prototype
and
build
different
things
without
having
to
rebuild
the
entire
stack
since
I.
Don't
I
think
there's
so
much
breath
in
the
approaches
that
we
could
take
I
I
personally,
as
a
goal
want
to
enable
people
to
build
those
approaches
without
having
to
build
the
entire
stack
that
you
have
to
have
to
realize
those
things.
D
One
other
brief
comment,
Christian
said
so
this
is
not
I.
Don't
think
this
is
an
attempt
to
like
redefine
a
different
way.
This
is
just
an
attempt
to
like
define
to
put
down
on
paper
a
reasonably
general
way
and
if
beniker,
for
example,
or
any
other
group
have
already
done
this
and
have
an
equivalent
diagram,
looks
similar
or
different,
but
at
least
they've
defined
it
I
mean
that
would
be
useful
to
know
about
we're.
Just
not
aware
of
any
that
that
exists.
If
they
do,
please
point
them
out.
D
A
D
G
Yeah
I
need
a
bit
of
time
with
the
document.
There
seems
to
be
a
lot
of
comments
between
me
ruin
you
and
the
in
the
margins
are,
though,
are
you
guys
violently
agreeing
or
is
there?
Is
there
a
way
to
resolve
some
of
those
discussions,
because
it's
it's
a
lot
more
work
to
consume
the
document?
If
there's
that
much
silence
I
think.
D
G
F
D
A
E
E
D
D
D
C
A
What
I
think
next
meeting
should
be
if
folks
have
questions
or
comments
about
this
I
like
it
sounds,
for
example,
and
I
don't
want
to
put
Christian
on
the
spot
here
like
it
sounds
like.
Maybe
the
the
value
of
what
we're
doing
isn't
super
evident
at
first
glance
to
everybody.
So
I
think
like
this
is
a
good
presentation
of
the
concepts
in
this
document
and,
after
folks
have
a
chance
to
read
and
come
back.
We
can.
We
can
have
like
any
substantial,
substantial
questions
or
comments.
We
can
maybe
address
them.
C
Sounds
sounds
quite
logical,
but
see.
Let
me
put
my
point
of
view
I
see
as
the
outcome
of
all
the
discussion
that
we
have,
so
what
I
have
been
seeing
the
end
result
should
be
that
we
ideally
should
reach
consensus
or
or
should
be
able
to
define
some
base
level
at
eie
from
a
technicality
right
and
our
aspect,
which
might
say
that
if
you
want
to
add
then
on
the
results
or
a
different
source
that
it
should
ideal,
there
should
be
an
ID
inspector
or
like
that.
A
I
think
that
makes
sense
as
a
next
step
to
like,
if,
if
we
think
that
there's
value
in
the
idea
of
having
like
assembler
level,
resources
that
are
the
primitives,
that
the
higher-level
constructions
are
built
on,
it
makes
sense
that
before
we
talk
much
further
about
the
higher
level
ones,
that
we
agree
on
what
the
actual
low
level
building
blocks
are.
So
that
makes
a
lot
of
sense
to
me
and
I
hope
that
we
would
be
able
to
do
that
in
the
next.
A
couple
of
meetings.
D
F
B
D
Okay,
I
can
talk
to
that.
So
I
tried
to
unclutter
this
diagram
as
much
as
possible
to
make
it
comprehensible
and-
and
there
were
some
things
that
got
left
up
by
necessity.
For
that
reason,
but
yes,
I
think
that
there
are
different
kinds
of
deployments,
so
I
think
in
a
very
simple
example
case,
the
user
is
allowed
to
specify
exactly
where
they
want
their
things
and
the
propagator
propagates
them
there
and
there's
no
intervention
by
policy
or
anything
else,
and
maybe
the
user.
D
You
know
discovers
that
this
stuff
doesn't
get
propagated
correctly
because
they
don't
quote
true
in
the
clusters.
They
ask
to
put
the
things
in
or
they
don't
have
the
rights
for
some
other
reason,
although,
although
Federation
is
not
configured
correctly,
to
be
able
to
send
things
to
those
clusters
because
they're
not
in
the
cluster
cluster
registry
or
whatever,
but
but
that
would
be
a
perfectly
valid
use
case.
D
Another
valid
use
case
would
be
to
only
allow
a
user
to
specify
placement
preferences
on
the
top
left
of
the
diagram
and
then
have
an
administrator
specified
policy
quota
and
a
whole
bunch
of
other
things
which
then
get.
You
know
used
to
produce
concrete
cluster
placement
decisions,
and
that
would
be
you
know.
The
administrator
role
would
be
to
specify
those
those
additional
rules
that
the
user
doesn't
get
dismissed.