►
From YouTube: Kubernetes SIG Multicluster 20180828
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
B
A
A
It
looks
like
from
a
steering
committee
that
Tim
Sinclair
asked
us
to
be
more
specific
I
feel
like
that
is.
That
is
difficult
to
do,
without
being
so
specific
that
we
include
just
a
list
of
projects
rather
than
a
list
of
areas,
I'm
wondering
what
what
people
think
about
this
I'm
wondering
if
folks
have
had
a
chance
to
look
at
the
pull
request
yet,
and
he
talks
about
this
I've
dumped
it
into
the
chat.
B
C
So
I
have
the
cluster
registry.
Cluster
object
has
been
sitting
for
quite
a
while
I
think
at
this
point
it
seems
like
it
seems
like
it's
at
a
point
where
I
would
like
to
start
to
move
it
to
beta
I,
haven't
the
thing
that
I
haven't
gotten
as
much
community
feedback
or
much
feedback
from
people
about
having
used
it
and
I.
Think
at
this
point
it
might
just
be
necessary
to
move
it
to
the
next
phase
of
API
development
and
then,
hopefully,
more
people.
C
The
announcement
of
it
going
beta
and
the
fact
that
it
is
beta
will
convince
more
people
to
see
it.
I
don't
know.
There
was
I
think
an
issue
that
Ivan
and
I
had
discussed.
I
can't
remember
offhand
what
that
was
if
there
was
something
in
particular
that
we
had
discussed
that
would
prevent
us
from
moving
into
beta
today.
Ivan.
Do
you
recall
what
that
was.
D
C
E
D
E
A
E
Would
that
be
I
mean
it
sort
of
seems
weird
if
we
have
to
cluster
objects,
it
would
superficially
suggest
that
maybe
those
fields
should
have
been
in
a
cluster
registry
I'm
just
you
know,
I,
don't
know
anything
much
about
either
of
them,
but
it
seems
to
motivate
that
we
might
be
short
of
information
in
the
cluster
registry.
Yeah.
A
I
think
that
the
I
am
personally
fine
with
there
being
two
different
resources.
I
I
have
wondered
to
myself
whether
we
ought
to
pull
the
resource
that
in
Federation
we
call
federated
cluster
into
the
cluster
registry
itself
and
call
it
something
like
cluster
connection,
because
there's
and
please
folks,
familiar
with
Federation
correct
me
if
I'm
wrong,
I,
don't
believe,
there's
anything
specific
to
Federation
about
the
federated
cluster
resource.
A
It
just
adds
a
secret
reference
that
contains
the
author
information
and
it's
something
that
anybody
that
wanted
to
use
the
cluster
registry
would
likely
have
to
add
in
their
own
projects.
I.
Don't
think
cluster
necessarily
ought
to
have
a
reference
to
auth
information,
because
you
could,
you
could
potentially
have
a
one
cluster
record
and
then
two
different
author
credentials
that
people
may
independently
want
to
use
with
it.
A
So
it
doesn't
seem
like
a
huge
problem
to
me
that
there
are
two
from
resources,
but
I
haven't
wondered
whether
we
ought
to
pull
it
in
to
the
cluster
registry
and
to
just
circle
back
to
the
original
discussion
topic
of
this
thread.
I
am
NOT
certain
whether
there
anybody
actually
wants
the
off
loofah
filled
in
cluster
registry.
Is
anybody
actually
using
that,
for
example,
on
this
call
that
can
that
can
say
what
they're
using
it
for
I.
E
A
Right
now,
Clinton
there
there
is
no
such
notion
actually
in
the
cluster
of
registry
itself
and
that
that's
basically
the
federated
cluster
resource
in
Federation,
and
hence
my
thinking
about.
Should
this
be
something
more
general
that
like
if
you
want
to
actually
make
a
connection
to
a
cluster,
and
you
want
to
store
that
information
in
an
API
resource
somewhere.
Should
that
be
part
of
a
cluster
registry?
That's
that's
the
question
I'm
examining
in
my
head.
It's.
C
An
interesting
question
I
mean
I,
think
the
issue
that
the
cluster
registry
runs
into
and
trying
to
express
this
idea
of
giving
you
information
to
authenticate
to
a
cluster
is
that
kubernetes
doesn't
have
a
good
machine,
readable
way
of
giving
that
information.
The
the
landscape
of
authentication
methods
is
so
large
and
so
potentially
complex,
but
there
is
no
good
representation
of
that
programmatically.
That
I
can
then
point
some
library
to
so
it
ends
up
becoming
this.
This
general
looking
field
that
becomes
very
domain-specific.
C
So
if
you're
running
a
multi
cluster
set
up
by
this
company.
Well,
then
this
is
how
these
fields
are
used,
and
this
is
the
info
you
have
to
know
for,
as
if
you're
running
this
different
multi
clusters,
if
you're
running
Federation-
and
this
is
how
you
would
use
those
fields-
it's
unfortunate
that
there's
not
a
generic
generalizable
generic
way
to
express
that,
but
that
isn't
really
a
problem
of
the
cluster
registry
itself
and
necessarily
fixed
unless
kubernetes
has
that
I
think
for
a
cluster
to
be
able
to
express
that
information,
but.
E
My
clusters,
but
I
have
to
have
credentials
for
those
clusters
somewhere
else
and
I
need
to
know
which
ones
to
use
for
which
clusters,
which
seems
to
imply
that
I
need
a
different
registry
of
clusters
and
credentials
which
seems
contradictory
to
needing
cluster
registry
in
the
first
place,
I
mean
please
please
correct
me
if
I'm
wrong,
but
how
could
I
possibly
use
cluster
registry
without
having
another
registry
of
clusters
somewhere
with
the
credentials
in
them?
Yeah.
A
E
A
One
is
a
secret
reference
that
points
to
a
secret
that
holds
acute
config,
so
Jonathan
in
terms
of
like
in
terms
of
finding
the
right
way
to
express
the
authentication
mechanisms
that
you
would
need.
I
would
say
at
a
bare
minimum.
Acute
config
seems
like
the
lowest
common
denominator.
Since
you
can,
you
can
give
a
cute
config
to
a
client
and
have
it
produce
a
client
according
to
that
treatment,
that's
fair
and
we
could
potentially
I
guess,
as
as
we
find
different
authentication
methods
that
people
want
to
use.
A
C
That
is
true.
Authentication
info
was
one
of
the
big
hopes
for
it.
It's
also
one
of
the
it's
one
of
the
unfortunately
most
difficult
issues,
because
the
I
mean
the
kubernetes,
especially
for
people
who
don't
trust
the
kubernetes
api
layer
to
be
a
safe,
secure
store
for
clusters
becomes
extremely
cumbersome
to
use
the
cluster
registry
to
reference
credentials.
E
C
E
I
need
to
go
to
this
key
store
somewhere
and
pull
this
key
out
and
then
use
it
to
whatever
yeah
I
mean.
That
bet
seems
to
make
a
lot
of
sense
to
me,
and-
and
maybe
one
of
those
places
is
going
to
the
cluster,
go
to
the
secret
and
you'll
find
it
there,
and
if
people
don't
like
using
secrets
in
kubernetes,
then
they
can
put
it
somewhere
else.
C
That
was
generally
the
thinking
that
is,
that
was
the
reasoning
behind
the
original,
often
thought
that
was
also
their
reasoning
behind
the
move
to
have
the
auth
info
field
as
it
stands
today,
B
to
object
references
one
for
credentials
that
a
user
would
use
or
users
would
use
to
access
or
a
way
to
get
credentials
that
users
would
use,
but
also
a
credential
for
controllers
that
wanted
to
access
the
cluster.
Yeah
makes
sense.
It.
E
A
E
A
E
I
agree
to
be
clear:
I'm
not
motivating
for
doing
that,
I'm
just
I'm,
just
trying
to
figure
out
in
its
current
format.
The
cluster
registry
provides
something
at
the
expense
of
a
reference
to
a
cluster
registry
cluster.
It
provides
one
thing
which
is
an
API,
endpoint
and
and
the
cost
benefit
there
is
not
clearly
positive.
E
A
A
And,
and
often
put
it
be
really
specific
about
it,
I'm
just
gonna
don't
be.
The
link
into
the
chat
here
is
described
as
containing
public
information
that
can
be
used
to
authenticate
to
and
authorize
with
this
cluster.
It
is
not
meant
to
store
private
information
like
tokens
or
client
certificates,
and
cluster
registry
implementations
are
not
expected
to
provide
hardened
storage
for
secrets.
A
We
might
want
to
get
more
specific
about
what
that
actually
means
reading
it
I'm
not
sure
that
you
know
without
some
history
on
the
project
I'd
be
able
to
tell
what
info
is
supposed
to
be.
It
really
seems
like
it's
more
metadata
about
the
authentication
mechanisms
that
the
cluster
might
use
more
than
anything
else.
D
D
Yeah
I
think
you're
I
I,
think
I
mean
the
original
intent
of
this
was
never
to
store
credentials
as
part
of
the
cluster
resource.
It
was
always
to
have
made
of
data
like
you
mentioned,
and
some
sort
of
indication
on
where
you
could
go,
get
the
actual
offing
for
the
for
the
cluster
that
you're
wanting
authenticate
with.
E
E
E
A
C
A
I
mean
again,
I
I
would
be
very
curious
to
know
if
anybody
is
actually
using
the
off
info
field,
we're
not
using
it
in
Federation
and
and
so
honestly.
Jonathan
I
was
kind
of
hoping
that
you'd
pipe
up
about
that,
because
I
had
the
impression
that
the
cluster
registry
is
being
used
as
part
of
gke
on
Crenna,
at
least
like
it
I
think
I
can
be
excused
for
thinking.
That
might
be
the
case
and
I
wondered
if,
if
that's
something
that
Google
has
a
use
case,
around
I
mean.
C
I
think,
if
Google
is
doing
it,
the
problem
that
Google
would
run
into
is
the
fact
that
the
often
faux
field
does
not
reference
a
secure
secret
storage,
which
makes
it
very
cumbersome
for
us
to
use
it
I'm.
Not
at
this
point,
I'm,
not
quite
up
on
what
the
precise
plan
is
for
how
we
plan
to
use
that
field
in
the
cluster
registry
object.
I
know
that
it's
not
actively
being
used
today.
A
In
that
case,
I
think
that
I,
it
would
be
a
good
idea
to
make
a
pole
that
removes
it
and
see
if
anybody
complains
like
in
this
in
the
sense
that
not
that
we
would
merge
this
pull
request,
but
like
just
just
making
the
full
request
that
removes
that
field
could
probably
shake
some
folks
that
may
be
using
it
out.
Yeah.
E
Yeah
I'm
still
struggling
to
understand
how
how
people
would
practically
use
the
cluster
registry
for
anything
without
having
to
build
something
which
is
pretty
close
to
a
cluster
registry.
On
top
of
it
like,
like
Federation,
has
done
and
saying
that
as
a
criticism
I'm
just
saying
it
sounds
like
we
need
a
bit
more
before
it
can
be
a
useful
thing
and
it's
moving
in
the
right
direction.
A
I
would
be
happy
to
make
a
poll
also
that
adds
like
a
cluster
connection.
Resource
is
what's
essentially
the
same
as
federated
clustering
Federation
today
and
see
if
we
can
get
some
attention
that
way
and
get
it
get
some
kind
of
signal
from
folks
and
maybe
watching
the
project
that
yes,
this
is
a
useful
thing
or
no
I,
don't
think
it
is
I.
Think.
C
E
E
C
That
has
been
a
problems.
The
project
from
the
beginning,
I
think
the
reason
the
reason
at
least
I
shied
away
from
that
is
because
the
way
to
make
hat
work
that
gets
something
out
today
is
to
tell
people
to
source,
to
store
secrets
with
credentials
in
their
clusters,
which
isn't
necessarily
a
good
or
a
scalable
solution
for
a
general
case.
E
Is
that
are
you
thinking
of
secrets
that
are
accessible
to
everyone?
I
mean
the
model
in
my
mind,
and
this
is
without
having
thought
about
it
anywhere
near
as
much
as
you
would
be
that
each
user
would
have
their
own
secrets
in
their
own
namespace
or
wherever
their
secure
place
was.
That
would
have
references
back
to
the
cluster
registry
and
then.
C
E
D
E
So
so
the
other
way
seems
intuitively
sensible
to
me,
and
maybe
that
solves
your
problem,
which
is
that
you
know
all
of
those
things
could
be
in
different
places.
They
could
be
in
different
namespaces
and
have
different,
are
back
rules
on
them,
etc
and
the
user
would
go
get
their
secrets
from
wherever
their
place
was,
and
all
the
ones
that
had
references
back
to
the
cluster
registry
would
be
useful.
D
Yeah
I
guess
the
only
thing
is
you
wouldn't
necessarily
have
a
canonical
way
of
getting
those
secrets.
They
would
have
to
be
like
application-specific
and
then
it
would
have
a
pointer
back
to
the
cluster
as
opposed
to
I
want
this
cluster
I.
Don't
know
how
to
authenticate
to
it,
but
it
has
a
canonical
way
of
providing
that
information
to
me
and
then
you
can
go
about
your
business.
Well,
the
point
I
get
your
point.
I
do
see
how
the
back
reference
is
technically
the
way
we
should
do
it
well.
E
One
way
to
I
mean
so
the
one
problem
with
what
I
suggested
was
that
the
secrets
themselves-
one
they
don't
typically
have
a
back
reference
in
them
at
the
moment
because
they're
standalone
secrets-
and
secondly,
you
know:
where
would
you
go
and
find
them?
Which
namespaces?
Should
you
look
in
and
all
that
kind
of
stuff?
E
And
then
you
know,
obviously,
if
you
didn't
have
access
to
the
credential
provider,
you
wouldn't
be
able
to
get
the
credentials
and
the
credential
provider
could
be.
You
know
either
secrets
in
someone's
namespace
or
an
external
LDAP
server
or
whatever
mechanism
and
config
map
could
refer
to.
You
know
different
external
credential
providers,
I
apologize
for
chiming
in
from
the
side,
because
I
haven't
been
involved
in
these
discussions.
But
thirdly
difficult
thing.
E
D
It
at
one
point:
there
was
also
interest
in
the
API
machinery,
folks
I
believe
wanting
to
adopt
the
API
endpoint
piece
of
the
cluster
itself,
and
it
sounds
like
what
I'm
hearing
is
that
we
we
really
need
an
API
endpoint
as
part
of
the
cluster,
and
we
sort
of
need
this
other
piece
right
that
some
sort
of
made
a
data
potentially
with
some
off
info
or
made
a
data
on
where
to
get
that
off
info.
So
it's
almost
like.
D
We
need
a
larger,
like
cluster
registry
resource
that
actually
maps
to
clusters
and
off
the
info
information,
whether
that's
cluster
connection
or
something
else.
But
we
can
probably
all
agree
that
the
API
endpoint
piece
is
definitely
a
useful
place
to
have
just
in
cluster
alone
and
potentially
gets
adopted
in
a
more
global
kubernetes
way,
such
as
in
API
machinery.
E
D
Yeah
yeah,
it
almost
seems
like
a
higher-level
sort
of
like
registry
concept
that
contains
within
it.
You
know,
cluster
and
off
info
information,
and
that
registry
could
be
like
a
multi,
a
multi
cluster
registry
sort
of
thing,
and
you
have
individual
clusters
with
secrets
and
config
map
to
reference
those
particular
clusters.
Yeah.