►
From YouTube: Kubernetes SIG Multicluster 20180116
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
Yeah,
so
today
on
agenda,
there
is
nothing
very
specific,
except
there
was
a
pending
item
since
a
couple
of
weeks
that
cause
I
think
Gotham
is
working
on
the
sto
and
he
would
want
to
talk
a
little
about
what
they
are
doing
and
what
a
little
overlap
they
might
be.
I
have
a
small
update
on
Federation
in
what
we
are
doing
and
if
there
is
any
update
about
cluster
I,
just
really
can
have
that
also
I
believe
Jonathan
is
there.
C
D
Looking
at
moving
the
API
for
its
beta,
what's
that
so
necessary
to
do
that,
we're
going
to
write
up
the
results
of
that
and
then
when,
when
that's
actually
more,
we
will
share
that
with
the
sig,
not
necessarily
expecting
comments
more
sort
of
FYI,
but
or
is
anything
we
share
out
what
to
say.
People
are
totally
welcoming,
so
we're
not
going
to
block
on
sync
comments
for
these
things
since
they're
not
really
they're,
more
sort
of
like
flushing
out
the
vials,
we
had
already
decided
on
together
in
the
States,
making
new
milestones
or
something.
C
C
Yeah
about
Federation,
we
have
been
discussing
about
the
API
in
the
tradition,
verbs
of
which
happens
on
Wednesdays
same
time.
Apart
from
that,
we
have
been
working
on
some
issue,
fixes
the
PR
star
there
against
the
depo
and
after
much
discussion
and
the
talks
with
testing
frog
is
and
all
we
sort
of
concluded
that
this
relieves.
We
zero
just
to
keep
it
simple
for
the
users,
so
that
this
release
maps
to
the
k8s
1.90
is,
and
so
far
we
haven't
seen
any
breaking
changes
in
chaos
api.
So
whatever
head
of
fourth
edition
is
there.
C
Yes-
and
I
see
a
good
amount
of
attendance
over
here
so
in
last
verb
group
saying
there
was
a
question
raised
about
backward
compatibility
so
right
now
we
are
sort
of
saying
and
for
future
we
are
saying
that
federation
won't
be
only
forward
compatible.
For
example,
if
we
save
undersigned
or
zero
release,
it
will
be
compatible
with
kate,
s1,
dot,
9.0
or
future
releases,
but
wouldn't
support
any
of
the
previous
ones.
That
means
that,
with
this
release
of
position,
users
we'll
be
able
to
fight
rate
the
older
version
of
kata
slashes.
C
E
Just
to
be
clear,
if,
on
that,
they're
two
version
compatibility
questions,
the
one
is:
what
do
we
owe
do?
We
remain
backward
compatible
with
the
previous
Federation
API,
which
was
essentially
the
kubernetes
api
and
and
the
other
one
is
which
what
versions
of
kubernetes
clusters
are
we
able
to
fit
a
rate
across
with
the
new
version,
and
so
could
you
just
clarify
which
of
those
yeah
so
I.
C
Verify
a
little
more
so
currently,
if
we
see
that
until
component,
if
Edition
was
maintained
with
inside
k8s,
the
Federation
release
was
being
done
over
the
K
which
theaters.
So
there
are
two
or
two
points
here.
One
is
maintainability
of
those
older
releases,
so
they
are
anyways
maintained
and
finishing
release
also
has
maintained,
but
there
was
no
claim
earlier
that
we
made
that,
for
example,
Federation,
which
is
released
as
part
of
component
is
1.8
will
certainly
be
compatible
with
kubernetes
cluster
1.7
and
kubernetes
cluster
1.6.
C
B
E
Were
talking
about
backwards,
compatibility
of
api's
and
I
just
raised
the
point
that
there
yeah
there's
a
distinction
between
backwards
compatibility
with
previous
Federation
api's,
as
opposed
to
backwards
compatibility
with
different
version
clusters
that
could
be
federated
with
the
new
system.
So
if
funds
disappeared
in
the
meantime,
maybe
I'll
just
talk
briefly
about
that.
So
I
think.
C
E
The
they're
kind
of
related
to
where
you
are
in
time,
I
guess
but
I
mean
concretely.
If
you
have
Federation,
let's
call
it
version
a
supports.
You
know:
kubernetes
clusters
version
one
then
at
some
point,
kubernetes
latest
release
is
gonna.
Go
to
one
point.
Ten
and
Federation
release
is
going
to
go
to
version
B
and
there
has
to
be
some
reasonable
way
to
get
from
Federation
Gazette
version
a
with
kubernetes
clusters,
1.9
and
Federation
version
B
with
kubernetes
version
clusters.
One
point
Tim,
let's
say,
and
that
cannot
be
a
an
atomic
transaction.
F
In
serial
I
think
I
mean
we've
had
discussions
about
this
and
I
think
the
outcome
of
that
was
that
Federation
can
only
reliably
be
forwards
compatible,
so
Federation,
any
given
version
can
support,
like
1.9,
for
example,
should
be
able
to
support
1.9
1.10
1.11
have
as
long
as
the
kubernetes
api
is.
You
know
some
reasonable
guarantee
of
backwards.
Compatibility
Federation
can
rely
on
that,
but
it
doesn't
go
the
other
way.
F
E
It
does
and
I
well
so
so.
Firstly,
I
think
that's
probably
ok
in
the
sense
that
we
say
you
have
to
upgrade
all
of
your
clusters
before
you
can
upgrade
Federation
and
I.
Think
that's,
ok,
I,
don't
think
it's
ideal
and
I
think
that
it's
potentially
feasible
to
do
better
than
that.
It's
saying
that
I
don't
think
that
is
the
case
with
kubernetes.
For
example,
the
modes
I
don't
think
have
to
be
strictly
ahead
of
the
control,
the
rest
of
the
control
plane,
but
I'm,
not
Hampton,
sure
I
think
there
is
some
degree
of
backwards.
F
Compatibility
there
like
there's
this
kind
of
a
different
scenario
like
the
notes'
versus
like
the
way
that
Federation
works.
If
you
add
a
new
field
like
it's
backwards,
compatible
somebody
with
an
old
API
and
basically
will
get
whatever
default
behavior.
That
field
represents,
but
it
doesn't
really
work.
The
other
way
like
if
I
have
a
newer
version
and
I
have
a
new
feel
that
I
populated
in
Federation
and
then
it
gets
propagated
to
an
old
cluster
that
doesn't
have
that
feel
behavior
well.
F
E
C
Yeah
I
I
did
make
it
back
and
I'm
sorry
I'm,
not
sure
that
I
lost
you
guys
so,
but
I
got
these
two
points
like
after
what
whatever
discussion
happened
so
yeah.
This
talk
has
happened.
That
Federation
can
remain
forward
compatible
to
some
X
versions,
which
is
not
defined
as
of
yet,
and
we
can
certainly
take
this
upgrade
scenario
as
case-by-case
message
basis.
If
that
kind
of
a
scenario
comes
in
and
we
face
a
problem,
we
probably
might
attack
that
problem
at
that
point
of
time,
rather
than
continuously
discussing
about
the
same
stuff,
yeah.
C
D
B
I
just
wanted
to
share
that
right
now.
The
cluster
registry
API,
is
cluster,
scoped
and
I
think
there
are
a
couple
reasons
why
it
will
be
likely
that
we
changed
the
existing
80
API
to
be
namespaced.
So,
for
example,
a
cluster
scoped
cluster
is
cluster
resources,
not
useful.
If
you
want
to
differentiate
the
auth
credentials
used
in
four
different
users
of
the
cluster
registry
API.
G
Answer
down
here:
I'm
Gotham,
I'm
from
the
environments
group
and
just
to
I'm,
not
quite
sure
how
familiar
folks
are
with
this
I
will
give
a
one-liner
on
what
is
does
sto
is
basically
a
platform
to
allow
that
allows
services
to
communicate
with
each
other
and
irrespective
of
where
they
are
on,
so
it
could
be
any
cluster,
any
cloud
environment.
It
could
be
running
on
Prem.
It
could
be
running
against
multiple
kinds
of
registries,
so
queue
parodies
is
not
the
only
service
registry
that
we
talk
to.
G
We
talk
to
console
Eureka
and
a
bunch
of
other
Cloud
Foundry
and
a
bunch
of
other
registries
as
well.
So
the
reason
I
thought
this
was
important
for
us
is
because
this
quarter
we
want
to
roll
out
sto
for
multi
cluster
communities,
and
there
are
basically
three
concepts
or
there
are
three
areas
that
I
would
like
to
discuss
on
the
first
one
is
very
simple:
it's
using
the
communities
cluster
registry.
G
G
Missionary
server
that
we
talk
to
in
the
configuration
of
that
will
be
configuring,
other
registries
like
console
or
Eureka
or
Cloud,
Foundry
itself,
etc.
So
we
will
try
to
keep
it
as
clean
as
possible.
We
will
not
try
to
you,
know
Merc,
you
know,
and
even
if
it
gets
to
that,
will
definitely
communicate
with
you
guys
saying
that
hey
you
know
we
want
to
put
annotations
and
again
we'll
be
using
the
standard,
annotation
method
for
extending
kubernetes
cluster
style
registry.
G
G
This
one
is
that
you
have
so
I'm
not
quite
sure
how
many
how
familiar
people
are
with
sto,
but
what
we
do
is
we
have
a
component
called
as
pilot
that
talks
for
multiple
registries,
and
that
is
one
mode,
so
we
might
be
talking
to
multiple
Kuban.
It
is
registries
and
getting
the
information
and
exposing
it
to
services
within
that
particular
environment.
G
The
second
mode
is
where
we
basically
talk
to
what's
known
as
a
remote
registry,
and
that's
where
one
pilot
talks
to
another
pilot
and
that's
just
the
means
for
sharing
service
endpoints
more
or
less.
We
are
not
basically
sharing
anything
else,
but
that's
what
we
are
doing
and
that's
that's
the
second
piece
that
I
thought
you
know
might
be
of
interest
to
this
community.
G
The
third
piece
deals
with
DNS,
because
when
a
service
is
exposed
in,
let's
say
a
remote
registry,
we
are
forced
to
sort
of
create
the
DNS
entries
for
that
local
environment
and
right
now
we're
just
basically
keeping
that
as
an
interface
will
be
using
cube
DNS
for
cube
environments,
but
it's
not
quite
clear
whether
we
will
be
supporting
other
environments
that
do
dns
and-
and
that
is
still
an
open
question.
But
for
this
quarter
we
are
focusing
on
cube,
be
honest,
sharing
of
end
points
across
pilots
and
using.
D
A
G
He
answer
is
yes,
this
is
so
I.
Don't
want
to
use
the
word
flat
network
I.
Think
I've
used.
That
sort
of
you
know
very
liberally
in
the
document,
but
we
are
trying
to
move
away
from
what
we
call
is
flat
fact
work,
because
it
just
creates
a
lot
of
confusion
for
people
at
Cisco
and
a
bunch
of
other
places
where
they
have
pushback.
G
G
Now
you
get
to
basically
put
in
things
like
you
know,
exposing
whips
which
are
sort
of
you
know
egress
ingress
lips,
which
are
very
tailored
to
the
source
and
destination
network,
and
we
have
not
yet
gotten
there
yet,
but
that
is
really
for
q2
and
q3.
Is
where
we'll
be
addressing
that
in
fact,
I
think
at
the
end
of
q1,
you
should
be
able
to
see.
G
C
G
G
E
G
C
G
From
from
one
is
to
a
perspective,
these
are
basically
canonical
services,
so
there
may
be
a
namespace
service,
for
example
in
humanities,
and
they
may
be
just
another
service
and
console,
but
they
would
still
be
the
same
mesh
service.
So
what
we
are
trying
to
do
is
rationalize
it
at
a
mesh
level
and
have
a
consistent
set
of
policies
for
services
across
the
mesh,
irrespective
of
the
environment
or
container
orchestration
workload
orchestration.
Any
of
these.
You
know
clouds,
for
example,
or
whether
it's
a
fountain.
Does
that
sort
of
answer
your
question?
Yes,.
E
G
That
is
correct.
We
are
not
in
the
business
of
orchestrating
workloads.
That
is
I.
Hope
I
have
answered
your
question
on
that
yeah,
so
we
are
not
in
the
business
of
like
spinning
up
VMs
or
orchestrating
workloads,
or
any
of
that
we
are
depending
on
whatever
existing
mechanisms
already
exist
and
we'll
be,
you
know,
heavily
working
with
the
Kuban.
It
is
team
to
make
sure
that
you
know
that
works
for
us.
I.
Think.
G
C
C
Yeah
I
actually
had
one
question,
but
I'm
not
sure
if
we
want
to
tread
those
waters
right
now,
how
much
of
an
overlap
does
sto
and
and
project
like
whatever
multi
cluster
Federation
would
have
and
I
mean
I
I'm,
not
pointing
it.
Only
to
you
bottom
I
think
it's
I'm
just
pointing
this
question
through
maybe
get
some
pointers
from
know.
G
G
Remember
at
the
end
of
the
day
we
are
talking
about
SEO
services
and
SEO
services
can
be
a
group
of
services,
and
communities
could
be
anywhere
else.
So
as
long
as
you're,
on
the
same
page
of
as
to
how
these
endpoints
get
exposed,
I
think
we
should
be
good,
but
okay,
so
so
I
think
we
are
fine.
Then
I
don't
see
any
major
problems
like,
for
example,
if
you
have
got
workloads
that
go
across
multiple
plus
one
right
and
there
is
let's
say
part
of
the
same,
so
you
have
a
even
today.
G
If
you
guys
are
planning
to
do
things
like
you
know,
multi
cluster,
suppose,
if
you're
basically
saying
that
you're
going
to
expose
endpoints
from
one
cluster
into
another
cluster,
and
these
are
totally
destroyed
clusters,
then
then
there
might
be
things
that
you
need
to
talk
about
and
there
might
be
some
little
small,
Oh
11:04
I'm,
not
too
worried
about
it.
But
we
need
to
keep
an
eye
out
I.
F
Wouldn't
expect
that
going
forward
we're
gonna
try
to
have
things
too
tightly
coupled
anyway,
I
mean
the
existing
service
discovery
mechanism
is
dns-based.
The
nice
quality
of
that
is,
it's
not
really
dependent
on
the
network
that
you
you're
using
pretty
particular
cluster.
It
just
makes
things
IP
accessible
if
they
are
happen
to
being
you
know,
if
they
have
that
connectivity
already
so
I
mean
having
that
sort
of
agnostic
solution
versus
something
that's
very
specific
to
the
network.
It's
defined
for
requester
I
think
those
are
totally
different
problem
really
and.
G
That
is
correct.
I!
Don't
want
to
mark
it
up
this
discussion
too
much,
but
I
just
want
to
point
out
that
DNS
is
just
our
first
level
of
discovery
and
mostly
to
address
legacy
applications.
But
once
we
get
to
the
resolution,
through
the
proxies
or
through
the
side,
cars
the
side,
cars
will
actually
be
able
to
make
much
much
richer
decision
on
how
routing
should
take
place.
G
So,
for
example,
we
will
be
able
to
say
that
a
we
need
10%
of
our
traffic
to
go
to
version
1
10%
to
go
to
an
experiment
and
remaining
80
percent
to
go
to
the
rest
of
the
fleet.
So
you
can
do
those
kind
of
things
based
on
attributes
of
the
endpoints
and
that's
what
we're
going
to
be
demonstrating
by
the
end
of
this
quarter.
G
G
C
H
A
E
G
Makes
perfect
sense-
and
you
know
that
that's
pretty
much
what
we
are
trying
to
aim
for
hybrid
anyways,
where
you
can
have
different
sort
of
operators-
and
you
know
like
kubernetes,
could
be
one
set
of
operators
and
similar.
You
could
have
operators
for
on
Prem
and
for
other
registries.
That's
how
we
arrange
it
anyways,
so
it
it
falls
perfectly
in
line
with
what
you
just
described.
C
So
if
there
is
any
point
in
talking,
there
is
any
update
which
might
be
relevant
to
useful
for
people
who
could
not
attend
that.
That
is
fine,
otherwise
I
just
kept
it
because
it
was
there
in
notes
from
last
two
three
meetings
and
last
two
key
meetings
did
not
have
that
amount
of
attendance.
As
today's
one.
A
Updates
two
instances
of
city
updates
at
cube
card.
One
had
a
few
questions
asked.
This
theme
was
basically
people
wanting
to
understand
where
we
were
headed.
So
people
clarified
that,
but
people
generally
wanted
to
us
to
have
a
better,
more
informative
presence,
at
least
on
the
kubernetes
website,
to
be
able
to
identify
particular
use
cases
because
we
presented
some
use
cases.
Some
some
people
in
the
audience
could
relate
to
them,
but.
A
A
A
G
A
E
Yeah
I
guess
one
brief
thing
to
add
to
that
is
that
they,
it
seemed
like
their
one
of
their
priorities
was
to
kind
of
move
ahead
as
fast
as
possible
with
the
work
they
were
doing
and
they
were,
if
I
can
paraphrase,
am
a
little
concern
that
you
know
doing
it
in
the
context
of
the
sig
might
slow
them
down.
So
if
we
do
want
them
to
work
here,
I
guess
we
need
to
figure
out
how
to
not
hold
them
up.
B
I'm
not
sure
that
we
can
necessarily
do
anything
to
enable
any
particular
vendor
I
mean
there's,
there's
a
trade-off
right
like
you
can.
If
you
want,
you
can
build
your
own
thing
and
you
can
cross
your
fingers
and
hope
that
other
people
find
it
compelling
or
you
can
try
to
collaborate
right
and
run
the
risk
that
consensus
building
takes
time.
I
think
there's
like
technical
things
that
you
can
do
to
work
around
this,
but
it
seems
to
be
my
own
experience
like
part
and
parcel
for
doing
open-source.
B
A
B
C
C
A
Yeah
I
mean
I
note
that
the
last
Federation
working
group
meeting
was
quite
lively
and
extended
beyond
just
Federation
topics.
So
for
those
who
come
at
the
cig
meeting,
we
try
to
give
a
general
update,
but
I.
This
update
is
not
as
as
specific
as
technically
inclined,
as
at
least
from
what
I
remember.
The
last
two
Federation
working
group
meetings
have
been
now.
E
C
D
Yeah
I
assume
that
you
should
be
able
to
I.
Don't
know,
I
mean
I,
think
I'm,
not
sure.
If
you're
able
to
record
the
meeting,
if
there's
no
host
presence,
I
think
Christian
has
been
going
pretty
regularly,
which
kind
of
updates
that,
because
then
meanwhile,
machine
and
rock
you
run
as
opposed
to
do
the
recording
but
I'm,
not
necessarily
certain
what
happens
if
there
is
no
host
president
yeah.
I
It's
it's
currently
being
recorded
and
for
zoom
I
by
the
way.
Yes,
hi,
I'm,
Nick
and
I'm
here,
like
quite
like
I've,
been
here
for
just
a
little
while
and
I'm,
just
starting
with
with
kubernetes
now
Federation
about
anyway.
So
for
the
zoom,
you
can
set
up
the
meeting
so
that
it
automatically
starts
recording
and
you
can
also
set
it
up
so
that
you
can
start
without
a
host.
So
in
that
case,
whoever
logs
in
the
meeting
will
start
and
it
will
start
recording
automatically
and
then
the
host
Webber
has
scheduled.
D
D
That
was
a
concern
that
I
don't
know
if
there
are
legal
ramifications
around
having
the
meeting
automatically
record
it
when
people
join
without
having
some
sort
of
disclaimer
before
hand
up
like
this
meeting
is
always
being
recorded,
they
don't
know
if
that
is
actually
a
problem,
I
know,
and
what
I've
seen
that
either
it's
was
talked
about
in
documents
we've
always
mentioned
hey.
This
meeting
is
being
recorded
almost
immediately
after
clicking
the
record
button.
So
I
don't
know
if
there's
any
issues
or
have
automatically
recording
them,
I
would.
E
Suggest
I
think
that
the
the
strong
recommendation
to
all
SIG's
in
under
the
kubernetes
organization
is
that
that
all
the
sig
meetings
are
recorded
and
I
think
we
can
put
it
at
the
head
of
the
the
meeting
discussion
in
minutes.
I
mean
if
we
can
get
zoomed
to
you
know
start
off
the
meeting
by
saying
this
one
is
recorded.
I
think
all
the
better,
but
even
if
that's
not
possible,
I
would
be
comfortable
going
ahead.
Auto
recording
and
you
know,
as
best
we
can.
E
D
C
D
D
C
I
F
Well,
the
the
qualification
there
is
that
previously
all
development
was
centralized
and
that
would
have
been
reasonable.
But
today
you
have
at
least
Federation
and
cluster
registry,
and
that's
probably
going
to
grow.
I
would
say
that
coding,
we're
kind
of
in
a
phase
where
there's
a
lot
of
planning
for
kind
of
the
next
phase,
and
so
the
amount
of
coding
that's
going
on
is
less
there's
more
planning
and
design.
That's
going
on.