►
From YouTube: Kubernetes SIG Multicluster 20181023
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
A
A
There
was
some
review
from
steering
committee
members
that
felt
that
what
was
emerged
was
overly
specific
I
found
it
extremely
difficult
to
understand
exactly
what
level
of
detail
was
detail
is
required.
So
if
somebody
would
like
to
take
that
up
and
work
through
that,
I
think
that
would
be
fine
to
do,
although
I'm
personally
comfortable
with
the
state
that
it
was
in,
which
is
being
very
specifically
defined
around
existing
pieces
of
software
I,
wonder
what
others
think
about
that.
A
C
C
Because
they
have
that
in
their
charter,
and
but
on
the
other
hand,
you
don't
want
all
SIG's
claiming
to
be
responsible
for
everything.
In
which
case
you
know
there
are
multiple
SIG's
responsible
for
everything.
So
it's
a
question
of
getting
the
scope
narrow
enough
that
it
doesn't
overlap
too
much
of
other
SIG's,
but
also
broad
enough
that
it
catches
things
that
are
not
necessarily
currently
being
done.
C
A
A
A
The
next
thing
that
I
had
put
on
the
agenda
was
that
we
had
a
really
productive
discussion
in
the
last
sig
meeting
around
the
proposed
addition
of
something
called
clustered
credentials
to
the
cluster
registry.
Api
I
took
a
pass
through
that
pull
request
and
pushed
an
update
that
addresses
some
of
the
review
comments
that
folks
left.
A
The
biggest
thing
I
would
say
about
that
is
that
I
tried
to
add
a
lot
of
specificity
about
exactly
what
should
be
in
the
the
secret
key.
That's
referenced
to
contain
information
about
user,
so
I
I
wanted
to.
Let
folks
know
that
per
our
prior
discussion
I
had
done
that
and
then
also
we
have
been
kind
of
discussing
whether
it
wouldn't
be
more
useful
since,
like
the
the
concept
of
an
open-ended
thing,
that
you
will
somehow
use
with
an
arbitrary
cluster
seem
to
be
a
little
ambitious.
A
A
A
You
know
just
personally
speaking,
that
it's
kind
of
cringe
inducing
to
grab
large
conceptual
spaces
with
names,
so
I
just
thought
it
might
be
something
that
one
would
have
a
better
indication
what
the
API
actually
does
for
you
and
then
to
let
us
examine
you,
know
the
problem
space
without
feeling
like
we
have
to
solve
arbitrary,
open-ended
questions
as
I
think
we
were
kind
of
grappling
with
last
time.
Does
that
make
sense,
Christian
yeah.
B
A
C
Just
had
a
question
Paul,
and
so
so
stepping
back
from
the
specific
PR
to
the
problem
we
were
trying
to
solve.
So
the
problem
we
were
trying
to
solve
is
that
the
cluster
registry
as
it
stands
today
does
not.
It
enables
people
to
list
clusters,
but
it
doesn't
actually
enable
them
to
do
anything
beyond
that.
C
Al's,
like
a
cluster
credential
me
I,
can
understand
what
that
you
can't
sorry
that
cube
config
is
actually
more
than
just
credentials.
It
has
a
list
of
users
and
a
test,
a
list
of
clusters
and
various
other
things
in
it.
I
understood
that
argument
against
the
cube
config
based
cluster
credential
that
was
contradictory
to
the
API
design,
in
that
they
were
stuck
in
a
cube
config
that
did
not
fit
with
the
rest
of
the
API
that
was
proposed,
not
that
we
should
narrow
to
health
checking,
because
that
isn't
actually
what
we're
doing.
A
Yeah
and
in
Quinten
that
that
is
not
lost
on
me,
I
again,
I'm,
not
necessarily
suggesting
that
we
rename
the
API
I'm
I'm
wondering
if
bringing
some
specificity
to
it
and
if,
if
like
health,
checking,
isn't
the
right
dimension
of
that,
like
maybe
there's
some
other
name
that
we
can
arrive
on
that.
That
might
make
it
easier
to
talk
about.
A
So
we
can
address
that
dimension
by
adding
specificity
to
the
contents
of
that
cube.
Config
I
also
wondered
if
it
would
pay
to
like
Descamps
how
from
something
as
broad
as
cluster
credentials
as
something
that
might
you
know,
make
it
more
tractable
to
get
an
agreement
onto
something
and
that
we
could
use
in
a
future
more
general
API.
Does
that
make
sense.
A
C
Yeah
I
mean
we're
trying
to
solve
a
specific
problem,
which
is
enabling
people
to
connect
to
a
cluster,
and
we
should
use
the
name
that
is
representative
of
that.
There
may
be
others
problems
worth
solving
like
health
checks
and
other
things,
but
that
isn't
the
problem
that
we
set
out
to
solve
here.
Yeah.
B
A
C
D
We
did
the
link,
isn't
ducts,
which
you
had
a
thing
I.
C
A
So
if
you
head
on
down
to
line
one
nine
I'm,
sorry
203
I
will
just
call
folks
attention
to
the
more
specific
semantics
that
I
put
into
the
latest
version
of
this,
where
I
say
that
secret
RAF
is
a
credential
or
sorry
is
a
reference
to
the
secret
in
the
namespace
that
contains
a
cute
config
with
credentials
and
I.
Just
really
failed
at
writing
prose
here.
But
the
salient
point
is
the
secret:
must
have
a
key
name,
cute
config
that
contains
a
file
formatted
as
a
proper
subset
of
the
cube
config
file
format.
A
A
But
he
had
a
very
good
suggestion
or
interesting
idea
to
me
that
the
exact
semantics
would
be
that
you
took
the
single
user
entry
in
the
secret
here
and
used
that,
with
the
end
points
define
in
the
cluster
resource
to
construct
a
cute
config
file
to
use
to
access
the
cluster
and
I.
Think
that
addresses
some
of
their
like
concerns.
That
folks
rightly
had
during
the
last
cig,
kneading
about
the
level
of
detail
and
specificity.
But
I
wonder
if,
if
what
web
folks
think
about
that.
C
The
only
concern
I
would
have-
and
maybe
I
can
just
add
these
comments
to
the
PR
rather,
is
that
I'm
not
sure
that
there
is
a
well-defined
thing
called
the
proper
subset
of
a
cube
config
file?
So
it's
not
clear
what
exactly?
That
means.
If
someone
were
to
try
and
write
something
that
was
conformant
I,
don't
know
if
there's
a
good
spec
for
what
that
subset
is
because,
because
yeah
for
cube
config
but
other
than
that
I,
don't
I
think
this
is
the
right
direction.
B
A
A
Mean
the
basic
formulation
of
like,
for
example,
basic
auth
I'm,
pretty
sure
that
we
could
look
at
cube,
config
files
and
guess
that
right,
I
I
would
really
not
necessarily
want
to
solve
the
or
gate
on
having
a
formal,
acute
config
API.
So
to
avoid
doing
that,
I
would
be
definitely
open
to
having
a
well-defined
API
in
the
cluster
registry
for
what
was
expected
to
be
in
this
file.