►
From YouTube: Kubernetes SIG Multicluster 20180227
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
Okay,
I
think
we
can
start
singing
readers
in
her
presence.
Normally
we
have
probably
four
five
minutes
into
the
meeting.
I
did
not
see
any
urgent
updates
by
any
specific
folks.
I
did
put
one
point
on
the
agenda,
which
was
maybe,
if
there
is
wider
presence
in
this
meeting,
there
might
be
some
short
update
which
can
be
given
about
the
Federation
API
or
the
bunch
of
discussions
that
has
been
going
on,
but
that
might
not
be
necessary.
A
B
A
D
A
So
last
two
weeks
we
have
been
working
on
it.
We
have
been
working
mainly
on
updating
some
functionality
to
be
fed,
so
there
were
some
pending
functionality
updates
that
were
needed,
which
are
around
our
BAC,
and
there
were
some
updates
where
the
arguments
to
the
to
be
fed
binary
itself
for
going
out
of
control.
So
we
have
been
working
on
command
country,
but
the
both
of
it
hasn't
reached
a
conclusive
state.
The
work
is
on
way.
A
We
have
been
working
on
updating
the
rendering
mechanism.
So
when
we
initiate
the
tradition
repo,
we
will
update
the
venturing
mechanism
as
Clyde.
There
has
mmmm
consensus
to
move
away
from
blight,
so
we
have
been
working
on
that
and
there's
a
PR
in
flight
which
successfully
updates
the
vendor
code
using
the
go.
That's
let's
go
lengths
official
death,
so
that
PR
is
already
in
flight
and
should
be
merged
within
a
few
days,
and
we
have
also
tried
to
handle
a
couple
of
issues
that
have
been
reported
in
past.
A
So
we
are
trying
to
bring
down
the
number
of
issues
that
are
there
already
existing
and
the
new
set
creeper.
So
we
have
been
successful
in
at
least
bringing
down
the
number
of
issues
by
10
in
last
couple
of
weeks.
We
still
have
close
to
150
plus
issues
where
many
of
them
might
not
be
relevant
now,
but
we
are
tackling
them
one
at
a
time.
C
We're
going
to
attempt
to
some
of
the
particularly
interested
parties
in
this
discussion
are
going
to
meet
later
today
to
discuss
this
and
to
see
if
it's
something
that
we
need
to
resolve
right
now,
if
it's
something
that
we
can
resolve
right
now,
if
it's
something
that
we
need
to
resolve
right
now,
there
was
a
thread
a
few
weeks
ago,
which
was
discussing
renaming
the
cluster
registry.
The
conclusion
of
that
thread
after
some
some
discussion
is
that
we're
going
to
rename
the
cluster
registry
to
the
API
service
registry.
C
B
E
C
Just
funny
yeah,
it
is
yes,
we
cycled,
through
a
number
of
different
potential,
naming
options
before
deciding
on
this
lesser
objectionable
one
compared
to
some
of
the
other
alternatives.
If
anybody
I
will
try
to
give
a
brief
rationale
and
sending
an
announcement
as
to
why
this
name
change
is
happening
brief,
it's
the
idea
is
that
the
cluster
registry,
as
it
stands
currently
doesn't
have
any
cluster
specific
fields
and
got
what
it
is.
Is
it
is
more
a.
C
C
C
That's
a
good
that
is
a
good
way
to
put
it.
We
expect
that
going
forward
as
software
evolves,
there
will
be
some
more
potential
specializations.
There
will
be
things
that
might
be
particularly
clusters
or
might
be
particular
to
sto,
API
servers
and
going
forward.
We
expect
that
there
will
be
some
evolution
made
potentially
in
third
party
read
or
see
RDS
or
in
some
other
way,
in
order
to
support
specific
things
for
clusters
and
specific
things
for
other
types
of
API
servers.
C
But
at
this
point
there
is
not
enough
of
a
usage
or
an
ecosystem
and
built
up
to
really
ever
the
other
go
at
defining
those.
So
that
is
something
that
we
will
keep
at
this
point.
The
API
serve
as
very
lightweight
and
simple,
and
let
the
innovation
happen
later
when
people
start
using
it
I
think
that's
probably
about
it.
There
will
also
be
some
work
done.
One
other
thing:
there
will
be
some
work
done
in
the
next
few
weeks,
hopefully
to
split
the
cluster
registry
or
the
API
service
registry
into
multiple
repositories.
C
C
This
decision
was
largely
to
help
make
vending
easier,
but
it
also
I
think
represents
a
more
sensible
split
of
the
components
of
the
repository.
It
should
make
it
a
lot
easier
for
people
to
vendor
in
the
API,
if
that
is
all
they
need
without
having
to
worry
about
different
tendencies
and
different
versions
of
their
different
dependencies
yeah,
and
so
that
is
mainly
why
that
work
is
being
done
and
that
should
hopefully
that
that
could
be
a
bit
cumbersome
and
complicated,
and
it
just
in
terms
of
logistics
and
organization.
C
So
there
will
probably
be
some
staging
to
that
work
where
it
starts
out
as
a
model
where
the
cluster
registry,
API
or
cluster
registry
repo
contains
the
majority
all
the
codes.
Still
the
code
is
reflected
out
into
the
other
repositories
and
then
in
the
future
we
can
migrate
to
a
model
where
those
repositories
are
imported
by
the
cluster
registry.
I
think
that's
all
I
have
off
the
top
of
my
head.
I
think
that's
I.
A
A
It
is
open
for
discussion
and
also
I
can
point
out
that
last
couple
of
meetings,
the
Sigma
teams
I
have
seen
that
there
isn't
very
specific
items
on
the
agenda
rather
than
sort
of
updating
about
the
specific
work
that
has
been
ongoing.
So
do
we
need
to
think
about
what
should
ideally
be
the
format
of
this
meeting
next
meeting
onwards
like
what
I
get
it
should
be
discuss
we?
C
I
mean
I
think
that
it's
worth
considering
at
this
point
I
think,
given
the
amount
of
work
being
done
in
the
Federation
workgroup
meetings.
I
expect
that
the
majority
of
the
larger
technical
discussions
are
happening
there
on
the
cluster
industry
side.
A
lot
of
the
technical
discussions
happen
over
emails,
which
then
are
filtered
down
either
into
smaller
meetings
from
people
who
are
interested.
E
For
me
personally,
this
is
Paul
from
Red
Hat
I'd
be
happy
to
I
would
be
happy
to
mostly
devote
the
Sikh
time
for
the
Federation
discussions
and
have
updates
on
other
things
as
needed.
We
may
want
to
evaluate
that
again,
and
maybe
in
a
few
months,
if
there's
a
lot
of
traffic
on
cluster
registry
or
something
else
in
the
cluster
I'm
sorry
multi
cluster
space.
E
B
So
Paul
I
think
if
I'd
rather
I
mean
I
think
we
can
put
Federation
stuff
on
this
as
time
permits,
but
I'd
really
not
make
this
the
official
time
in
place
for
that
working
room.
You
know
it's.
If
we
I
worried
that
there
it
would
end
up
pushing
out
other
things
if
they
come
up
yeah.
That
makes
sense,
especially
because
it
doesn't
even
meet
your
schedule.