►
From YouTube: Kubernetes Federation WG sync 20180405
Description
See this page for more information: https://github.com/kubernetes/community/blob/master/sig-multicluster/README.md
A
B
C
Yeah,
partly
the
goal
of
this
meeting
is
to
plan
for
the
conference.
So
maybe
maybe
you
can
relay
that
to
him.
I
mean
it's
not
I,
don't
think
we're
just
gonna
talk
here,
one
and
done
the
plan
is
to
get
the
ball.
Rolling.
I
guess
have
milestones
for
the
next
at
least
six
months,
so
that
we
can
communicate
that
and.
B
Yeah
I
understand
that,
and
he
actually
has
put
that
item
about
different
verb
groups
or
difference
of
subgroups
off
the
seat.
As
in
we
need
to
decide
what
we
probably
need
to
plan
for
next
six
months
or
a
year.
So
that
is
basically
something
which
we
may
be
finishing
them
in
current
next
couple
of
weeks,
yeah
about
what
we
want
to
present
in
the
sig.
I
am
not
bigger
than
that
at
all
that
stuff.
Now
so
I'm
open
to
seditions
from
the
folks
in
the
making
today,
and
then
we
think
obably
take
over
from
there.
C
So
I
I
can
write
up
the
status
of
that
and
probably
one
one
slide
and
go
over
it.
On
the
Google
end.
We
have
this
cube,
MC
I,
CLI
tool.
We
have
a
separate
session
that
were
a
separate
session
at
tubecon
that
we're
going
to
talk
about
it.
So
there's
a
talk,
Greggy
Nikhil
we're
going
to
be
yet
again.
That's
another
quick
status
slide,
then
I
guess
the
top
ropes
to
Federation
and
that's
v1
and
v2,
and
what
how
do
we
want
to
present
v1
v2
I
just.
D
A
C
Most
so
far,
most
of
the
changes
have
done
into
the
I
guess
it's
the
ingress
GCE
side
of
things,
which
is
the
the
Google
implementation
of
ingress
and
right
now,
they're
working
on
a
CRD,
I
guess.
Unfortunately,
the
PRD
right
now
is
going
to
be
Google
specific,
like
it's
a
google
extension
because
it
configures
the
a
Google
parameter
from
the
load.
Balancer
I'd
like
to
have
a
better
schedule.
C
I
would
apply
to
any
ingress
implementation,
but,
as
you
know,
the
part
of
the
major
reason
ingress
is
in
beta
compared
to
all
the
Quora
that
all
the
other
core
API
is.
Is
that
there's
the
space
is
so
fragmented,
so
it's
kind
of
net
it's
on
GK.
It's
targets
on
the
Signet
working
right
now
to
try
to
standardize
ingress
to
possibly
have
an
ingress
v2,
but
for
this
audience
here,
but
unfortunately
we
don't
have
a
very
good,
generalized
story
to
share
right
now.
Okay,.
D
Pushing
cube
mci
in
that
direction
is
something
Google
is
still
interested
in
doing
we
kind
of,
and
forgive
me
if
I
missed,
like
a
status
update
in
cig
multi
cluster,
but
it
things
kind
of
went
dark
on
that
one
and
it's
been
a
while,
since
we
talked
about
it,
so
I
was
just
kind
of
wondering
overall,
where
it
stood.
I
don't
mean
to
derail
this
meeting,
though
so
I
think
that's
enough
information
for
now.
Thank
you.
Okay,.
C
B
That
is
a
pretty
space.
So
last
last
meeting,
which
was
yesterday,
we
I
remember
some
thoughts
were
floating
like
until
Wheaton.
We
do
probably
evolves
at
something
which
can
be
published
to
users
until
that
time.
Maybe
we
keep
if
the
documentation
main
point
is
because
there
is
documentation
existing
in
kubernetes
official
documentation
about
perdition
v1,
and
we
cannot
just
sort
of
remove
everything
from
there
and
do
a
lick
announcement
saying
that
we
do
not
no
longer
support
it
or
something
like
that.
B
Maybe
that
might
also
be
one
way
of
going
about
it,
but
one
thought
that
I
had
is
until
v2,
you've
all
said,
something
more
stable
and
something
which
can
be
presented
to
the
users.
We
sort
of
keep
the
status
quo,
saying
that
we
are
moving
towards
v2
and
that
is
work
in
development
and
we
no
longer
are
doing
any
active
development
on.
Even
that
might
be
one
standpoint
that
we
can
give
out
to
the
user.
So
the
community.
D
The
purpose
of
alpha
is
to
be
able
to
break
things
and
and
do
so
without
having
major
consequences
around
we
broke
some
agreement
to
support
something
or
have
backward
compatibility
or
ended,
so
I
I
think
in
a
minimum.
We
do
need
guidance
on
the
dock
site
on
kubernetes
io
anywhere
that
references
it
and
in
the
readme
Oh.
What
do
people
think
about
that?.
C
Yeah
I
mean
I
agree
to
be
specific,
I
think
the
readme
is
kind
of
fine-grained.
It
focuses
on
what
the
SIG's
efforts
are,
which
I
think
escapes
may
escape
the
the
kubernetes
user,
just
because
there's
so
many
SIG's,
it's
fine
to
have
something
that
reflects
what
we're
actually
doing.
But
my
main
pain
point
is
really
the
docs
site,
because,
like
right
now
we
just
had
a
110
release
and
one
nine
release,
and
these
are
two
opportunities
where
we
keep
reflecting
a
status
of
Federation.
That
is
really
not
what
the
where
the
implementation
stance.
E
Provide
a
good
pointer
at
the
top
level,
where
you
would
normally
have
found
Federation
and
just
say:
go
here
completely
off
the
dock
site
there
you
can
find
archived
docs
for
all
the
versions
for
people
who
are
still
wanting
to
play
with
the
Alfa
thing
and
an
explanation
as
to
what
what's
going
on,
but
but
the
current
status
quo,
where
any
user
who
discovers
the
dark
side
and
happens,
discover
the
Federation
docks.
Essentially,
they
will
not
understand
what's
going
on,
there's
not
enough
information
to
derive.
C
Okay,
I
tend
to
agree
as
well:
you're,
fun.
B
If
it
is
specified
explicitly
in
the
documentation
that
this
is
an
alpha
feature
or
that
kind
of
stuff,
then
users
would
have
a
problem.
So
my
suggestion
would
still
be
that
we
do
a
gradual
shift
to
rather
than
just
simply
archive
all
the
documents
or
I
mean
if
there
is
a
better
way
of
doing
that,
or
there
is
like
Maru
suggested
that
we
move
and
archive
to
some
location,
and
then
there
should
be
some
pointer
in
existing
docs
that
whichever
users
are
using,
that
ideally
should
refer
to
this
location.
A
E
A
E
E
If
I
pay
attention
to
this
I'm
in
trouble,
that's
that's
my
concern
because
I've
been
in
that
position
as
a
developer,
where
I've
stumbled
across
all
Doc's
via
google
search
and
not
recognized
that
oh,
this
is
for
an
old
release
and
doesn't
represent,
like
the
state
of
the
art.
I
would
like
to
avoid
developers
falling
in
that
trap.
I
think,
like
I
I
kind
of
get
that
we
don't
want
to
just
lose
people
because,
like
oh,
we
don't
have
a
solution
for
you
right
now.
E
B
Yeah
I
can't
really
like
this
idea.
What
you're
suggesting,
for
example.
Currently
there
is
no
explicit
disclaimer
like
this
in
majority
of
the
documentation
that
you
find
on
ok
company
to
start
I/o,
so
that
might
be
one
exercise
that
we
can
do
that
as
one
step
towards
migration
or
most
of
the
condition
dog
should
have
this
disclaimer
at
the
top.
That
this
is
an
alpha
feature,
and
we
don't
intend
to
support
this
in
future
and
we
would
be
migrating
to
v2
with
a
proper
link
through
very
exactly
the
development
of
v2
is
happening.
E
B
C
C
C
B
E
That's
I
think
that's
like
low-hanging
fruit,
so
we
can
get
an
explicit
warning
on
every
page
in
the
Federation
Docs
on
that
site.
That'll
give
us
to
figure
out
what
to
do
next,
like
how
easy
it
is
to
put
it
somewhere
else,
so
that
it's
not
actually
included
in
the
main
one
in
Docs,
but
at
least
users
will
have
a
clear
indication
of
what's
going
on
with
a
when
they
go
to
the
dogs.
E
E
Think
probably
a
brief,
succinct
message
like
Danger
Danger
and
then
maybe
a
link
to
something
that's
a
little
bit
more
informative
as
to
what
the
status
is.
I.
Think
that
makes
sense
to
me
and
maybe
dot
what
it
links
to
could
just
be
a
page
in
the
Federation
repo
that
just
documents,
history
of
the
status
yeah.
B
B
B
C
Right
so
I
think
there's
two
topics
there.
We
can
easily
summarize
the
other
efforts
that
we
talked
about
in
10
minutes
in
a
few
slides,
I
think
for
v2,
it's
important
to
message
to
community
lessons
learned
right
because
we're
showing
up
and
we're
saying,
there's
b1.
This
is
the
current
state
of
things
and
we're
working
on
v2
and
here's.
Why.
E
C
E
D
I
I
would
say
that
that
was
the
impetus
I
without
getting
to
astronaut
II
on
v2
I.
Think
another
point
is
that,
like
in
v2,
you
should
be
able
to
take
only
what
you
want
in
terms
of
if
you,
if
you
want
the
basics
of
putting
things
in
multiple
clusters,
you
can
take
that
without
taking
like
all
of
the
more
automated
parts
and
build
your
own,
automated
parts
or
just
not
use
automated
parts,
but
the
impetus
was
definitely
around
support
ability,
summation
of.
E
C
Okay,
I
certainly
find
out
mentioning
the
fact
that
I
mean
we're
building
v2
in
a
you
know:
kubernetes
environment,
where
there's
much
more
extensibility
mechanism,
there's
a
much
more
clear
path
in
terms
of
defining
what
the
core
api's
are
or
what's
been
called
nucleus,
as
opposed
to
core
I
mean
you
can
sprinkle
ideas
around
CR,
DS
I
feel
CR.
These
are
well
increasingly
well
accepted,
as
extension
mechanisms.
There's
a
you
know,
a
breadth
of
tools
like
cube
builder,
that
allow
easily
easily
composable
operators
and
I
mean
I.
E
I
mean
my
life
forward-looking
statement
for
Federation
v2.
Is
it's
going
to
be
entirely
crt-based
and
it's
going
to
support
the
federation
of
CR
DS?
So
the
only
reason
you
would
write
code
is:
if
you
have
one
special
behavior
like
scheduling,
but
in
terms
of
the
API
side
it
would
you
wouldn't
be
writing
code
at
all
I.
E
Mean
that
has
huge
advantages
in
terms
of
operational
a
because
then
you
just
need
you're
going
to
be
running
things
in
a
cluster
sure,
but
you're
not
going
to
have
to
have
a
separate
@cd
instance.
Not
gonna
have
to
use
aggregation.
You're,
not
gonna,
have
to
worry
about
any
of
that
stuff
stuff.
To
me,
that's
a
huge
one.
E
C
Okay,
I
guess
I
can
commit
to
let's
see,
kicking
off
that
set
of
slides,
I'll,
call
lesson
lessons
learned
and
leading
into
you
know,
V
to
what
you
call
before.
Looking
statement
distribute
that
sometime
late
this
week,
I
think
would
also
be
useful
not
just
for
messaging
outbound
from
the
sake
cube
con,
but
also
for
our
own
goals.
As
as
we
prototype.
V2
is
yes,
I
hate
to
plate
the
p.m.
C
B
C
B
Okay,
one
more
one
more
point:
does
it
make
sense
like
I've
only
a
week
or
two
ago
could
actually
give
a
small
demo
on
what
current
development
is.
We
might
actually
have
a
more
mature
than
you
or
a
more
workable
demo
by
Q
Khan,
so
that
might
be
also
possible.
I
mean,
if
that
makes
sense,
we
can
get
with
that.
Also,
some
time
can
you
spoon
me
to
functionality.
Okay,.
B
Yeah
so,
rather
than
what
it
does
now,
I
think
around
coupon
we
should
be
able
to,
for
example,
in
the
previous
coupon
I
think
the
Austin
won.
One
of
us
did
functionality
demo,
which
describe
the
cross-question
service
discovery
in
some
way
locally
I
mean
setting
it
up
locally,
so
something
similar
I
am
not
sure
if
we
will
be
able
to
complete
that
cross
social
service
system
part
by
them,
but
whatever
is
complete.
We
should
be
able
to
do
that.
C
B
D
C
But
it
seems
to
me,
based
on
this,
is
my
interpretation
of
what
the
real
value
of
this
work
is
so
far
in
v2.
It's
the
fact
that,
specifically
for
the
audience,
I
would
narrow
in
on
what
it
means,
what
overriding
means.
Typically,
it
means
that
the
end
user
does
not
have
to
write
any
code
to
control
that
behavior
that
we
will
have
a
api's
for
them
to
essentially
plug.
D
C
D
This
is
how
it
should
be
altered
in
a
specific
cluster
when
it's
placed
into
that
cluster,
and
these
are
the
clusters
where
it
should
be,
and
there
are
excuse
me,
those
present
is
as
API
groups
and
resources
that
are
very
clearly
demarcated
as
being
related
to
Federation
and
are
versioned
distinctly
from
their
v1
counterparts
and
kubernetes.
So,
for
example,
all
of
the
all
of
these
resources
that
we
talked
about
are
at
the
view
one
alpha.
D
One
level,
which
is
another
distinction
to
make
between
v2
and
v1,
is
that
the
versioning
that
we're
able
to
achieve
in
v2,
because
we
have
these
distinct
resources,
is
clearly
demarcated
as
being
the
version
of
the
Federation,
rather
than
being
potentially
bound
up
in
looking
very
much
like
vanilla
kubernetes.
Does
that
make
sense?
Yes,.
C
I
think
it's
useful
to
have
this
discussion.
Parts
of
this
I
understood
it's
good
to
hear
it
from
you
just
to
Risa.
Mirai's
I
see
it
as
the
kind
of
the
vagaries
of
workload.
Distribution
are
not
buried
in
annotations,
as
they
were
in
v1,
where
API
was
preserved,
as
is
distinct
resources
that
we
can
evolve
over
time,
yeah.
So.
D
D
C
So,
even
even
if
it's
not
demo,
Bo
I
think
what
we're
talking
about
now
is
something
we
can
definitely
speak
to,
so
that
that's
encouraging,
at
least
from
my
perspective
now,
I
guess
the
only
thing
that
we
need
to
kind
of
grip
on
as
we
were,
we
have
two
slots
there,
I
think
30
and
40
minutes.
Each
one
is
a
sig
update
that
can
be
fairly
generic
through
slides
and
I.
C
D
D
F
F
C
C
Been
having
a
discussion
for
the
last
ten
minutes
or
so
about
workloads
and
different,
how
they
differ
between
v1
and
v2
Lyndsey
plans
on
demoing
that
capability,
but
earlier
earphone.
You
also
spoke
to
services
specifically
class
across
cluster
service
discovery.
Is
that
something
that
you
think
you
would
want
to
demo
in
that
session
as
well.
B
C
C
C
C
D
D
D
D
I
think
that
I
think
it's
I
think
the
concept
exists,
so
that
you
know
you
have
to
write
something
down,
because
the
format
of
the
Charter
is
not
prescribed
in
any
way
but
I.
In
my
own
personal
opinion,
as
just
an
observer,
I
would
say
that
that's
the
main
importance
is
that
we
shouldn't
have
SIG's
that
have
no
definition,
yeah.
B
So
yeah
one
last
thing
so
who
all
are
going
to
be
there
and
this
mission
I
know
that
you
would
be,
and
I
saw
modules
and
his
name
in
one
of
the
presentations
you.