►
From YouTube: Kubernetes Federation WG sync 20180829
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
C
Sure
so
we
found
this
week
and
when
I
say
we
I
mean
I've,
Infante
and
Lindsay
really
spent
most
of
the
time.
On
this,
we
found
that
the
install
latest
yeah
mo
is
using
the
latest
tag
for
the
Federation
v2
image,
which
is
the
latest
release
version
and
the
yeah
mo
itself.
Is
it
actually
only
works
with
canary
tag
due
to
the
namespacing
changes
that
we
put
in
so
a
few
things
that
that
we
thought
should
be
discussed
today?
C
Probably
that
prow
gives
us
and
then
uses
that
cluster,
both
both
as
the
host
for
Federation
in
the
target
cluster,
so
that
we
can
take
one
cluster,
deploy
Federation
into
a
I
use
Federation
to
target
the
host
cluster
and
verify
that,
as
someone
would
deploy
it,
that
Federation
works,
I,
say
a
single
node
version
or
a
single
cluster
version
of
this,
because
we
don't
have
a
good
way
yet
with
the
testing
infrastructure
to
get
multiple
clusters
at
the
same
time.
As
far
as
I
understand
any
comments
or
thoughts.
D
C
Well,
I
think
it
probably
varies
so
so
there's
two
different
things:
actually,
let's,
let's
decompose
it
and
be
really
specific
one.
Yes,
we
should
make
sure
that
if
that
there
is
some
stable
way
to
use
the
latest
released
version
of
Federation
that
will
work
and
two
we
should
ensure
that
there
is
a.
A
C
A
Basically,
okay,
okay,
yeah
I
got
I
mean
if
I
think
like
that
I
get
too
many
options.
Let's,
if
I
ate
a
little
bit,
I
I,
remember
that
we
had
had
some
discussion
about
this,
and
we
did
conclude
that
we
will
maintain
one
branch
and
whatever
is
latest
in
filtration.
We
have
to
ensure
that
that
works
fine
with
some
X
version
of
K
test
either
it
could
be
the
latest
K
this
or,
for
example,
the
last
released
say:
1.91
KS.
Okay,
so
why
don't
we
it
keep
it
simplified
to
that?
A
Only
that
means
to
say
that
our
last
release,
version
of
hydration
was
0
dot,
0
dot
1.
It
might
not
work
today,
but
the
latest
that
we
have
right
now
should
work
with
a
particular
version
of
K
test,
which
probably
is
the
latest
release
version
of
campus
right.
So
if
we
find
I
mean
in
case
somebody
reports,
one
reason
for
us
to
release
a
new
version
might
be
that
somebody
reports
that
your
older
version,
older
release
version
0.0
that
one
is
not
working.
C
Yeah
I,
don't
disagree
with
you,
but
I'm
I
think
that
I'm
I'm
thinking
of
something
slightly
different
than
what
you're
talking
about
in
the
sense
that
that
there
should
be.
There
should
be
a
way
that
you
install
the
latest
released
version
right,
but
there
should
also
be
something
that
makes
sure
that
when
you
try
to
use
master
that
it
works
in
the
way,
in
the
sense
that
when
you
try
to
deploy
Federation
using
the
instructions
that
that
works
correctly.
So
does
that.
Does
that?
C
Do
you
see
my
point
or
Fon
that,
like
in
this
case,
we
have
instructions
that
use
the
install
latest
Gamal
and
that
installed
latest
yam
Allah
had
changes
for
the
pod
spec
to
run
Federation
that
were
dependent
code
changes
that
were
in
the
image
being
used,
and
in
this
case
the
install
latest
yeah
mo
was
referring
to
a
version
of
the
image
that
didn't
have
the
code
changes
because
we
haven't
done
a
release.
Yet
so
I
think
in
this
case
that
we
have
a
couple
options
for
something
tactical
to
fix.
C
A
Yeah
I
got
what
you
are
saying:
Paul
I
am
deferring
on
only
one
thing,
so
either
using
hell
or
some
mechanism,
for
example,
we
are
using
installed
laters
right
now.
That
is
deploying
the
latest
released
version
of
Federation
for
any
user.
Who
wants
to
try
it
out?
Ok
and
one
statement,
I'm
trying
to
repeat
it
again,
which
is
we
support
the
latest
release
version
on
a
given
K
test
version,
so
that
should
work.
If
that's
not
working,
then
we
have
a
problem
right.
D
A
Older
ones
that
we
have
release,
for
example,
Oh
dot
or
dot
one.
We
have
the
least
we.
We
found
a
problem
right
now,
because
there
is
some
mismatch
in
our
installed
latest.
We
are
not
using
the
correct
version
which
we
should
be
using
of
the
image
which
we
have
published.
The
portion
right,
if
he
corrected
here
that
should
be
sufficient.
I
did
not
understand
the
usage
of
what
you
were
pointing
at
using
another
job
to
verify
something
I
didn't
get
to
verify
what
so.
C
So
let
me
with
with
my
understanding
of
what's
in
your
head,
let
me
reformulate
the
statement
and
I
think
we
can
clear
the
mismatch.
So
in
this
particular
case,
install
latest
IMO
I
should
not
have
been
updated
right
like
in
the
sense
that,
if,
if
install
latest
IMO
is
at
this
point
going
to
be
the
way
that
you
install
the
latest
release
version,
then
that
should
remain
static
until.
C
Version
yep,
so
what
happened
is
that
we
made
some
changes
that
required
changes
to
install
latest
IMO,
but
we
didn't
update
the
image
that
that
yamo
file
is
actually
referring
to
so
I
think.
What
we
could
do
instead
is
I
have
something
that's
like
install
canary
dot,
yeah
MOU.
That
is
where
we
make
changes
that
are
going
to
roll
in
to
install
latest
IMO
during
the
next
release
and
have
the
instructions
to
you
know
to
try
out
Federation
B
in
terms
of
install
latest,
so
that
your
you're
using
a
released
version
but
for
development
flow.
A
B
A
C
Because
parameterizing
installed
latest
IMO
with
just
the
image,
doesn't
account
for
the
changes
to
the
yamo
file
itself,
so
so
say
that
we
release
version
X
and
we
make
a
change
after
we
release
version
X
that
changes.
What
has
to
be
an
install
in
the
installation
yeah
mo
we
should
have
a
place.
That
is
how
you
install
the
latest
unreleased
version
in
master,
and
when
we
do
a
release,
we
should
roll.
Those
changes
in
the
install
latest,
IMO
I
guess
is
what
I'm
proposing?
Does
that
make
sense?
Yep.
A
C
Ci-Flow
I
I
think
that
we
should
have
a
job
that
makes
sure
that
install
latest
keeps
working.
So
I
specifically
I
think
that
we
should
have
some
kind
of
CI
flow.
That
exercises
install
latest
yeah
mo
with
the
latest
release
version
and
make
sure
that,
like
no
breaking
changes
creep
into
that
yeah
mo
that
will
break
someone
trying
to
use
it
to
test
drive.
Federation.
C
A
C
And
then
the
final
point
here,
I
think
is:
should
we
release
0.2,
I
I
think
that
we
I
I
think
it's
arguable
that
we
should
since
we
made
we've
made
a
fair
amount
of
changes
since
urato
dot?
One
and
I
wondered
what
people
thought
about
that
I.
B
B
It's
both
I,
think
the
installation
and
while
working
properly,
is
definitely
a
first
requirement,
but
it
may
uncover
under
other
issues,
just
by
going
through
like
the
example
in
the
user
guide,
and
if
we
can
test
against
multiple
clusters
and
verify
it
works.
I
think
that's,
probably
a
good
smoke
test
to
make
sure
we're
ready
to
release
yeah.
C
My
concern
with
making
that
a
prerequisite
to
release
o
dot
o
dot
two
is
that
I.
Don't
think
we
have
any
good
options
for
automating
a
test
like
that
at
this
point,
which
is
why
I
was
thinking
that
a
test
of
Federation
as
deployed
by
that
by
install
latest
insuring
that
that
worked
correctly
with
a
single
cluster
is
probably
sufficient,
or
at
least
sufficient,
is
a
next
step
in
the
absence
of
a
ready-made
way
to
to
test
with
multiple
clusters
from
proud.
B
Yeah
that
I
mean
that's
pretty
similar
to
what
we're
doing
in
ete.
It's
just
that.
It
would
also
test,
like
the
main
entry
point
path,
which
I
think
would
be
good
to
do.
But
I
guess
the
reason
I'm
saying
that
I'm
saying
this
is
we
should
verify
at
least
manually
if
we
don't
have
an
automated
way
sure
that
would
be
ideal,
but
we
need
to
at
least
verify
it
manually,
because
I
think
it
can
potentially
uncover
issues.
B
C
B
Yeah
I
think
so
it's
just
that
it's
there's
still
potentially
another
issue
in
master
right
now,
beyond
just
the
install,
oh,
so
I
don't
think
we're
ready
to
release
a
dot
too.
Yet,
okay,.
C
Iii
see
I,
see
what
you're
saying
so.
I
am
saying
that
I
think
that
a
good
next
step
would
be
an
automated
test
with
a
single
target,
cluster
and
I.
Think
what
you're
saying
is
that
modulo
that
you
believe
that
there
may
still
be
another
issue
that
we
need
to
ensure
is
not
actually
a
bug
before
we
release
right
right.
B
Yeah,
that's
that's
fair
again!
If
it's
automated
great
until
then,
we
may
want
to
consider
doing
a
manual
smoke
test
against
at
least
two
clusters
or
running
through
the
user
guide
example,
but
as
a
first
step,
I
think
getting
yeah
an
automated
single
cluster
test
with
using
them.
You
know,
exercise
in
the
main
entry
point
would
be
a
good
goal
for
now.
So.
B
C
C
A
E
C
A
D
A
Yeah
I
think
you
should
think
of
the
complete
story.
I
think
there's
one.
We
are
still
in
progress
in
external
DNS,
so
probably,
if
that
is
merged,
then
we
have
a
complete
story.
Otherwise
it
could
be
like
we
have
a
types,
but
still
we
couldn't
program
the
DNS
records,
so
I
think
yeah.
Maybe
it
should
be
done
within
a
week.
Hopefully
I
think
we
can
ll
initiate
the
documentation
for
those
features.
Yeah.
A
B
A
There's
a
message:
Paul
is
lobby
for
a
minute.
Okay,
anybody
I
mean
if
somebody
else
caught
that
my
question
is
that:
is
it
possible
to
run
another
gentle
CI
job?
Against
the
same
that
for
that
we
have
which
could
basically
verify
that
install
a
test
against
a
single
tester
using
similar
mechanism
that
by
using
40
tweeters
right
now.
B
D
B
C
C
C
B
E
B
Updating
it,
which
means
the
user
guide,
still
works
as
long
as
we
revert
some
of
those
changes
that
went
in
and
we
sounds
like,
we
also
want
a
way
to
test
master,
possibly
with
a
new
install
master
MO
and
have
the
most
updated
changes
there.
That
can
be
used,
which
probably
won't
work
with
the
user
guide.
But
we
need
to
make
that
apparent.
My
yeah.
B
C
A
C
Yeah
I
think
that
makes
a
lot
of
sense
Shashi,
especially
as
we
like,
as
we
get
into
having
any
kind
of
web
hook
or
anything
that
needs
to
serve
TLS,
where
we're
going
to
want
to
have
something
more
than
than
just
like
a
static,
yeah
Mille,
because
we'll
need
mint
certificates
right
and
honestly
I
think
we're
we're
just
like
one
feature
or
one
could
change
away
from
needing
that.
So
I
I
personally
think
that's
a
sensible
way
to
proceed.
C
I
think
it
will
probably
be
a
good
tactical
thing
to
do
to
get
install
latest
working
again
and
also
as
a
tactical
thing
introduced
like
an
install
canary
or
something
but
yeah
I.
I
personally
think
it
would
be
a
good
idea
to
start
working
on
a
helmet
art
which
shouldn't
really
be
that
hard
to
do,
because
we
already
have
the
yeah
moles
represented.
Well,
we
just
need
to
turn
them
into
a
chart
and
parameterize
them
in
the
required
ways.
C
B
C
A
B
B
C
E
A
C
E
A
Okay,
that's
the
key.
Maybe
we
can
just
add
an
initial
version
of
an
chart
in
our
repo
which
works
for
zero
one.
They
revert
the
changes
in
install
or
latest
and
then
publish
that
to
report
our
triple
and
from
then
onwards
we
can
now
maintain
or
running
versions
in
our
repo
and
then
population.
Whenever
we
release.
E
E
A
A
E
C
Think
so,
okay,
so
Lindsey
Tolec
at
Red
Hat
has
done
some
prototyping
work
to
add
a
status
resource
that
collects
a
couple
fields
on
federated
replica
set
and
she
doesn't
have
a
pole
ready
yet
to
go
to
Federation
v2.
But
there
is
a
pole
to
my
fork
that
I
that
I'm
happy
to
share
one
sec
while
I
locate
the
lake.
C
B
just
to
be
really
crisp,
this
whole
request
adds
a
new
resource
called
federated
replica
set
status
whose
spec
is
essentially
empty
and
whose
status
contains
a
list
of
the
statuses
for
the
federated
replicas
that
that
is
deployed
in
each
current
cluster.
So
let
me
find
a
pointer
into
this
pull
request.
Cuz,
it's
pretty
big.
C
This
pull
request
doesn't
work,
yet
we
we
have
been
fighting
for
the
last
couple
days.
The
the
issues
that
we've
actually
just
talked
through
so
Lindsey
hasn't
had
a
good
working
baseline
to
use,
but
now
that
we
have,
we
have
this
identified
I
think
she's,
probably
about
one
worksession
away
from
having
something
working.
C
So
if
you,
if
you
take
a
look
at
what
the
changes
she
had
to
make
to
the
sink
controller,
were
it's
pretty
clear?
It's
pretty
clear
that
this
is
a
special
case
and
it
it
required
at
this
prototyping
stage
required
some
custom
code.
I.
Think
one
question
that
I
am
asking
myself
is
what
it
would
take
to
make
a
gin
like
a
reusable
federated
status
facility,
so
that
we
we
might
be
able
to
treat
status
as
something
that
has
parity
with
the
other
things
about
federated
type.
C
Config,
like
the
overrides
resource,
the
placement
resource
and
as
a
sibling
to
that
might
have
a
status
resource
that
we
could
have
a
controller
that
knew
how
to
transform
arbitrary
statuses
into
a
list
so
that
we
didn't
have
to
add
special
code
for
each
type
that
we
wanted
to
add.
Support
for
I!
Wonder
if
anybody's
thought
about
that
yeah
like
orphan
and
Shashi.
Have
you.
C
A
Discussed
actually
yeah
predicted
status
has
two
parts,
one
which
is
useful
for
a
user
and
another.
It
could
be
used
by
other
controllers
without
going
through
all
the
member
cluster,
like
monitoring
the
member
cluster
resources,
so
I
think
yeah
the
later
part,
which
you
suggested,
the
generic
solution
of
handling
the
status.
So
I'm
wondering
how
does
the
approach
of
like
status
into
the
Federated
type
confi
like
the
status
cookie
Oh,
similar
to
template
just
wrapped
around
the
types
of
status
into
there
as
a
list
yeah.
E
A
Yeah
I
think
that's
pretty
doable
I
think
that
would
be
very
useful
for
all
the
controllers,
who
want
to
know
the
status
of
the
resource,
those
clusters
and
then
maybe
they
could
be
some
specialized
status
like
we
want
to
give
consolidated
like
status
to
the
user.
Maybe
we
could,
instead
of
like
cluster
one
cluster,
two
as
a
separate
status.
C
So,
actually,
I
want
to
make
sure
that
I'm
not
making
an
assumption.
So
when
you
talked
about
like
the
difference
between
a
status,
that's
useful
to
a
user
and
a
status,
that's
useful
to
other
controllers,
it
sounds
to
me
like
the
status
for
other
controllers
is
a
list
and
the
status
that's
usable
for
users
is
like
a
projection,
a
superposition
of
all
the
statuses
in
that
list.
A
Actually
so
yeah
like
if
you
want
to
maintain
a
similar
compatibility
with
for
the
resource
in
cabana
tastes,
okay,
so
it
makes
sense
like
to
give
a
consolidated
view
to
the
user.
But
if
we
are
okay
to
make
that
distinction
like
42
times
fill
realness,
then
I
think
it's
the
same.
Stat
I
should
hold
good
yeah.
E
A
For
example,
we
have
defined
the
template
so
in
that
type
the
this
is
the
generic
status
which
will
reflect
for
a
given
federated
template.
For
example,
the
projected
replica
set
as
our
status
with
the
sink
controller
or
itself
updates
as
a
list,
the
specialized
or
aggregated
view
is
up
to
user
defined
type
or
a
high
level
controller
to
present
a
user.
So
it
need
not
be
I
mean
it
need
not
be
be
prerequisite
for
the
foundation.
As
of
now
let.
C
Me
make
sure
that
I
heard
you
right
or
fun.
It
sounds
like
you're
proposing
that
the
that
the
list
flavor
of
status
could
potentially
just
live
on
the
be
the
status
of
the
template.
A
C
A
Also
proposing
that
this
can
be
considered
as
part
of
the
lower
level
building
blocks
that
we
did
to
brainstorm
earlier,
so
we
have
three
fields
or
three
resources
and
there
is
a
sink
reconciler
which
basically
there's
all
this
reconciliation
to
political
esters.
Now
this
is
like
some
reconciliation
back
from
the
federated
clusters,
also,
so
this
portion
of
food,
which
updates
this
also
is
part
of
the
sink
controller
in
some
junk
fashion.
Mm-Hmm.