►
From YouTube: Kubernetes SIG Multicluster 20180410
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
There
are
some
items
on
that:
gender,
the
first
one
I
think
wintered
it
for
this
week,
back
it's
about
creating
a
Sig
Carter.
So
all
and
I
had
some
discussions
on
this
and
we
did
intend
to
initiate
writing
a
charter.
Most
of
it
in
our
current
sedition
is
that
there
are
two
major
portions
to
this.
One
is
defining
the
vision,
mission
mission
and
the
Charter,
and
the
second
portion
is
defining
roles
and
responsibilities
for
the
sake,
so
the
first
portion,
more
or
less
seem
to
be
reverting
off.
B
What
already
exists
on
the
sig
page
currently
in
community,
the
second
portion,
which
is
about
defining
the
roles
and
responsibilities
I
think
we
have
them
defined
to
some
extent,
but
we
probably
need
to
formalize
the
same
on
the
similar
lines
to
four
other
six
or
the
example.
That
has
been
said
by
the
steering
committee,
so
I
think
we
really
taking
this
forward
and
1
1
PR.
Is
there
I
I
apologize
for
the
PR
to
take
it
forward?
B
F
Okay
sounds
good
everyone.
One
very
brief
suggestion
was
that,
rather
than
get
stuck
on
this
stuff,
we
have
a
bunch
of
people
doing
a
bunch
of
things
today
and
we
should
just
write
those
down
and
say
these
are
the
roles
in
the
sink,
and
then
you
know
if
we
want
to
change
that
or
if
we
want,
if
people
start
doing
different
roles,
we
can,
you
know,
amend
it
from
there,
but
rather
than
going
into
a
lengthy
process
of
deciding
who
wants
to
do
what
to
the
future
etc.
F
B
So,
as
I
mentioned,
the
Charter
has
two
major
portions:
one
is
about
the
mission
statement
or
what
the
sick
collectively
is
working
towards,
or
what
is
the
goal
of
the
sick,
those
kind
of
things,
so
those
are
already
there
on
the
readme
I
think
they
are
well
explained,
and
it's
it's
more
or
less
just
putting
it
at
a
different
place,
probably
in
a
different
childhood
or
MD,
or
something
at
that
and
there's
a
PR
which,
which
Paul
did
already
raised
towards
that
towards
that.
The
second
portion
of
that
is
defining
the
roles
and
responsibilities.
B
So
currently
only
the
cygnets
are
defined
or
cygnets
are
assigned.
The
steering
committee
example
of
the
same
thing
suggests
small
roles
on
probably,
for
example,
they
they
suggest
that
would
be
a
lead
whose
managerial
lead,
our
technical
lead.
That
kind
of
stuff.
Probably
we
don't
need
all
those
fine-grained
roles,
so
as
s
Quinton
suggested,
we
can
just
list
down
a
few,
a
bunch
of
three
four
roles
that
people
have
as
part
of
that
chapter
of
Emily
itself.
I
think
that
should
be
good
to
go
as
of
now.
B
F
E
F
We
put
some
confidence
into
the
lure
some
kind
of
come
into
the
next
each
item
on
the
roadmap.
To
give
that
level
of
detail.
I
agree,
we
don't
want
to
promise
things
a
year
out
and
then
change
our
minds
in
six
months
time
and,
of
course,
people
thing
but
I
think
it's
useful
to
sit
down
think
hard
about,
given
what
we
know
today.
What
we
would
like
to
work
on
for
the
next
12
months
and
write
it
down
and
publish
it
and
say
to
the
best
of
our
knowledge.
E
E
E
E
F
No,
that
makes
perfect
sense.
Google
has
a
reasonably
successful
thing,
called
okay,
ours
objectives
and
key
results,
and
they
have
annual
ones
and
quarterly
ones
and,
and
they
typically
check
in
on
those
around
about
quarterly,
it
depends
on
the
team,
etcetera,
but
I
think
you
know.
Unless
anyone
has
a
better
proposal,
it
sounds
like
pretty
much
what
you're
describing
set
a
12-month
plan
and
then
have
like
every
three
months.
Chickens
on
that
plan,
and
you
know
roundabouts
release.
F
You
know
either
before
or
after
the
release
or
something
seems
like
a
good
place
to
you
know
sync
up,
and
so
here's
where
we
are
or
now
and
perhaps
you
know,
extend
the
12
month
plan.
You
know
after
three
months
you
only
have
nine
months
of
runway
left.
So
maybe
that's
the
right
time
just
say:
well
we're
gonna,
you
know,
adjust
the
runway
accordingly,
every
three
months
yeah.
E
F
Absolutely
I
mean
the
thing
that
triggered
it
was
this
announcement
by
the
PM
guys,
but
I
think
it.
You
know,
irrespective
of
what
they
want,
and
the
fact
that
cube
cons
coming
up
I
think
we
have
a
very
big
gaping
hole,
which
is
that
we
don't
have
a
like
a
medium
to
long
term
plan
written
down
anywhere,
and
that's
not
the
right
thing
to
be.
B
F
We
should
just
double
check
the
deadlines,
I
think
I
think
the
PM
guys
are
wanting.
You
know
some
stuff
written
down,
but
by
some
dates,
so
they
can
put
stuff
together
for
cube
con
and
we
shouldn't
miss
the
that
fire.
You
know
a
few
days
for
no
good
reason,
so
if
we
need
to
shorten
it
from
two
weeks
to
one
week
or
whatever
we
should
do
whatever
we
need
to
do
to
fit
into
that
timeline.
I,
don't
remember
what
the
proposed
timeline
was,
but
let's
check
it
today:
okay,.
D
B
I
guess
there
are
two
different
things.
One
is
what
we
basically
need
to
talk
at
UConn
and
tell
about
other
sig
and
all
that
stuff.
The
other
is
that
we
have
a
plan
somewhere
as
written
were
suggesting.
There
is
a
template
of
okay,
that
kind
of
stuff
put
up,
so
we
actually
had
a
backlog
sheet
which
had
been
a
running
sheet
since
almost
two
years,
which
completely
got
outdated.
B
F
Well,
there
are
multiple
uses
here,
so
just
looking
through
the
email
from
sig
p.m.
they
actually
asked
us
to
give
them
a
road
map
by
April
force,
which
is
last
week
Wednesday.
Also
so
we're
a
bit
overdue
for
that.
Besides,
that
you
know,
many
of
us
are
gonna,
be
it
cube
con
and
it
would
seem
to
make
sense
to
get
together,
and
you
know
talk
about
stuff
and
so
doing
that
in
the
absence
of
a
road
map
seems
not
like
a
good
idea
either.
F
So
I
think
we
should,
rather
than
you
know,
spending
two
weeks
booking
a
road
map
together.
We
should
just
do
it
this
week
and
send
it
in,
and
hopefully
that's
not
too
late
for
p.m.
product
management
and
I
can
assist
with
that.
If
anyone
wants
my
help,
mm-hmm
I
mean
of
that.
So
the
three
main
sub
projects
are
MCI,
plus
the
registry
and
Federation
right.
This
there's
nothing
major
other
than
those
three
and
MCI.
F
If
I
understand
correctly,
has
a
sort
of
roadmap,
I've
certainly
seen
it
referenced
by
Nikhil
in
the
sense
of
what
they
plan
to
do
in
the
future
and
support
clouds
other
than
Google
etc.
Does
anyone
is
there?
Is
anyone
here
who's
directly
involved
in
the
MCI
project
that
can
comment
on
how
far
away
they
are
from
having
a
12-month
plan.
F
F
You
know
don't
have
three
or
four
bullet
points
saying
this
is
what
these
you
know.
One
or
two
people
plan
to
do
in
the
next
12
months
is
totally
reasonable.
It's
nothing
that
the
nothing
and
then
the
other
one
is
obviously
cluster
industry
and
Jonathan.
You
seem
to
indicate
if
you
already
have
something
approaching.
F
F
Yeah
and
the
Federation
stuff,
similarly,
I
think
we
have,
you
know
most
of
the
of
the
meet
there.
We
just
need
to
format
it
into
something
that
is
consumable
as
a
road
map,
perhaps
with
some
release
targets
on
each
item,
so
I
can
I
can
certainly
team
up
with
whoever
else
is
interested
and
get
that
out
by
the
end
of
the
week.
B
We
have
some
priority
items
with
the
Travis
perspective
in
view,
so
we
put
that
out
and
meru
up.
All
you
can
put
out
whatever
is
that
hats
trial,
TV
perspective
the
words
Federation
b2
or
whatever
you
want
to
call
it,
and
we
can
merge
the
both,
maybe
reassign
the
priorities,
and
that
might
be
are
at
least
midterm
short
long
term
plans
and
there's
a
symbolical
or.
B
What
what
I
was
trying
to
say
is
that
we
would
have
some
items
which
Huawei
is
more
interested
in
doing
in
short
term
long
term.
Abode
I
mean
far
long
term.
We
also
don't
have
a
clear
vision.
Anyways,
you
would
also
have
from
Red
Hat's
perspective.
What
is
important
to
you,
as
of
now
at
least
for
six
months
or
for
coming
six
to
eight
months
kind
of
stuff.
I,
don't
know
about
long
term.
If
you
have
clear
vision
of
what's
gonna
be
alpha
here,
Dortmund,
but
both
of
these
items.
D
E
Know,
as
Quinn
mentioned,
there's
a
big
spreadsheet
for
stuff
that
we
proposed
to
work
on
before,
and
there
you'll
be
interesting.
You
go
through
that
again
and
see
what's
still
relevant,
like
the
timeline
to
a
year.
My
head,
I,
I,
can't
think
of
anything
that
would
take
long
but
it'll
be
a
useful
process.
Anyway.
Okay.
G
D
B
G
G
G
F
Yeah,
that
sounds
great
thanks
for
putting
that
together.
Christian
I
think
super
useful,
save
everyone
a
lot
of
trouble
yeah.
We
can
sign
up
to
basically
get
the
Federation
part
of
that
in
shape
I
think
for
this
week,
and
then
we
can
just
send
a
link
to
this
to
the
PM
guys
and
say
this
is
where
our
roadmap
is
slide.
Number
so
and
so
I
think
that
works
well.
F
And
I
guess
they're,
maybe
it's
worth
just
having
a
quick
look
at
who's.
Doing
multi
cluster
related
things
at
Q,
Khan
Europe
in
a
few
weeks
time
and
they're,
fun
and
I
am
others
have
about
three
or
four
talks
that
were
accepted.
I,
don't
know
if
anyone
else
has
talks
that
have
been
accepted
to
Q
Khan
related
to
any
of
the
work
here.
F
G
C
C
C
Essentially,
we
have
to
and
choose
coping
options
with
a
third
compromise
option.
You
can
have
the
cluster
object,
not
yet
namespace
scope
include
Nettie's
terminologies
to
be
cluster
scopes,
but
I
think
somebody
else.
It
might
have
been
the
new
pointed
out
that,
technically
for
this
convicts,
we
can
think
of
it,
not
someone
who's
like
cluster
scope,
but
as
a
global
scope.
That
is
a
scope
that
is
outside
of
a
namespace
and
it
not
divided
up
in
constraint
into
namespaces.
We
can
have
the
clusters
at
a
namespace
scoped.
C
In
that
case,
the
clusters
would
live
in
a
namespace
like
config
maps
and
other
communities
objects.
The
alternative
is
that
we
can
have
both
of
these.
We
can
have
one
object,
which
is
cluster
scope
and
we're
object
which
of
namespace
codes.
This
would
be
otherwise
exactly
the
same
object
simply
with
the
difference
that
one
has
a
namespace
field
that
is
set
and
the
other
one
does
not
accept
namespace
for
lack
of
consensus
on
this
is
blocking
moving
us
to
beta.
This
is
something
we
want
to
actually
decide
before.
C
C
One
point
that
comes
into
this
discussion
is
the
idea
of
stand-alone
versus
aggregated
in
the
cluster
industry,
so
the
current
cluster
registry
can
be
deployed
either
as
a
stand-alone
API
server,
the
kubernetes
style,
API
server
that
just
presented
in
cluster
API
and
is
not
at
all
connected
to
a
clusters,
API
server
or
in
an
aggregated
mode
in
which
the
cluster
registry
API
server,
is
run
and
is
aggregated
to
the
main
cluster
API
server
in
standalone
mode.
You
can
only
access
clusters
at
this
endpoint
in
aggregated
mode.
C
You
can
access
clusters,
along
with
the
other
kubernetes
api
at
this
endpoint.
The
scare
quotes
here
are
because,
as
the
cluster
registry
moves
to
a
custom
resource
definition,
instead
of
an
API
server,
it
will
not
technically
be
an
aggregated
api,
but
it
will
be
a
custom
API
that
is
installed
either
into
a
kubernetes
cluster
api
server,
which
is
analogous
to
a
aggregated
mode,
or
that
will
be
installed
into
a
hypercube
binary
that
is
running
independently
and
likely
as
a
pod
in
the
cluster,
in
which
case
it
will
be
running
in
a
standalone
mode.
C
This
is
important
because
the
way
when
the
cluster
objects,
when
the
cluster
Industries
stand
alone,
the
concept
of
main
spaces
has
less
mixing
with
the
concept
of
clustering
main
spaces
in
a
regular
kubernetes
cluster
than
when
the
cluster
registry
is
aggregated.
So
when
you
install
a
cluster
CRD
into
another
kubernetes
cluster,
that
has
existing
objects,
the
concepts
of
name
spacing
becomes
a
bit
more
complicated
and
it
becomes
a
bit
confusing
and
more
difficult
to
manage
so
non
namespaced
is
a
current
model
of
how
the
cluster
registry
is
object.
This
cluster
object
the
Scopes
this
mimics.
C
Think,
more
importantly,
in
the
aggregated
sense,
when
you
have
main
spaces
that
have
meanings
within
the
cluster
also
now
have
meanings
within
the
cluster
registry
and
the
semantic
confusion
between
those
two
different
concepts
that
are
merged
into
one
is
I.
Think
that's
the
potential
to
be
quite
high
and
to
cause
problems.
The
main
one
of
the
main
problems
with
non
namespace
scoped,
and
what
sort
of
led
us
to
consider
how
namespacing
originally
was
that
you
can't
enable
off.
You
can't
authorize
users
to
access
a
subset
of
clusters
in
a
non
namespace
cluster
registry
very
easily.
C
You
can
tell
them
they
can
access,
they
can
read/write
all
the
clusters
or
they
can
read/write
none
of
the
clusters.
This
is
the
way
to
mitigate
this
is
to
run
multiple
independent
instances
of
the
cluster
registry.
Independent
API
servers
we
each
have
their
own
authorization
rules
names
based
so
name
spacing,
is
a
much
more
common
pattern
for
kubernetes
objects.
C
We
would
most
the
proven
any
object
or
namespace.
The
kubernetes
guidance
for
objects
says
that
it
recommends
to
use
a
namespace
object
unless
there
is
a
compelling
reason
not
to
so
it
is
the
default.
It
allows
fine-grained
permissions
on
some
types
of
clusters.
Another
benefit
is
that
it
supports
multi,
tenant,
kubernetes
platforms
as
a
service
or
natively.
C
Unfortunately,
some
of
the
negatives
that
come
of
this
federating
namespaces
or
main
space
objects
requires,
or
at
least
heavily
suggests,
the
introduction
of
a
nested
namespace
concept
in
aggregated
mode,
which
is
something
that
kubernetes
does
not
currently
support
you.
Imagine,
for
example,
you
have
name
space.
Cluster
registry
lives
in
a
cluster,
and
now
you
want
to
federates
name
space
into
clusters.
Well,
how
do
you
define
what
name
spaces
federated
and
how
that
namespace
should
be
federated,
which
clusters
that
should
be
federated
to
when
those
clusters
also
live
in
namespaces?
C
C
Think
the
general
I,
my
expectation,
would
be
that
you
would
not
propagate
cluster
objects
into
the
underlying
clusters,
but
I
don't
necessarily
know,
there's
nothing
that
prevents
that
from
happening
given
the
model,
but
I.
Don't
think
that
will
happen,
because
that
has
the
expectation
at
the
underlying
clusters
themselves
or
have
a
cluster
registry
object,
enabled
wish
and
I
think
the
semantics
of
that
seem
odd
to
me
that
you
would
sink
information
about
other
clusters
down
to
each
of
those
clusters,
though,.
E
So,
regarding
Federation
of
namespaces,
my
experience
prototyping
might
be.
Is
that
there's
like
having
a
federated
namespace
and
a
namespace
resource
just
adds
tremendous
amount
of
confusion
like
it
was
confusing
for
me
as
a
developer
and
I
think
it
would
be
very
hard
to
communicate
to
users.
So
that
was
the
first
point.
Is
that
I
mean
Federation
be
to
a
namespace
as
a
namespace
as
a
namespace?
E
The
way
that
you
define
whether
it's
propagated
or
not,
is
whether
its
contents
are
propagated
or
whether
it
has
an
explicit
placement
resource,
but
there's
no
such
thing
as
a
federated
namespace.
It's
simply
like
illogical
concerns,
and
the
second
point
was
the
way
that
v2
is
sort
of
designed.
You
don't
just
take
an
arbitrary
object
and
federated.
You
have
to
define
a
template
in
order
to
sort
of
have
basis
for
doing
that.
So,
if
you
have
a
resource
of
any
kind,
you'd
have
to
create
like
a
template
in
order
to
actually
Federated.
E
G
G
E
At
present,
in
order
for
any
resource
to
be
federated,
it
has
to
be
in
a
namespace.
I
haven't
really
gone
as
far
as
considering
like
what
I
would
it
take
to
federated
namespaced
resource,
and,
presumably
it
would
it
would.
It
would
revolve
around
placements,
like
you
would
define
a
template
and
that
wouldn't
be
namespace.
You
define
placement
and
that
wouldn't
be
namespace,
and
this.
E
E
Essentially,
a
one-to-one
mapping-
there's
no
like
oh
I,
have
this
like
layout
in
my
Federation
API
and
I'm
gonna
have
a
different
layout
in
the
underlying
cluster.
You
could
do
that
and
that
might
have
power
in
some
circumstances,
but
it
also
could
get
super
complicated
and
we're
just
trying
to
keep
it
as
simple
as
possible
from.
G
G
F
About
to
make
a
similar
comment,
Christian
I
think
we
might
be
going
off
into
the
weeds
a
little
bit
here,
water,
it
worrying
about
how
to
federate
clusters.
I
think
I.
Think
the
more
common
use
case
for
clusters
is
just
having
a
registry
of
them
so
that
we
know
what
the
possible
places
are
to
fill.
Er
eight
other
things
too.
But
what
I
am
a
little
concerned
about
is
the
fact
that
if
I
understand
Jonathan
correctly,
we've
kind
of
hit
an
impasse
here,
where
we
can't
make
a
decision-
and
that
makes
me
worried.
F
Is
there
any
compromise
we
can
make
just
to
make
a
decision,
so
we
can
actually
move
forward
and
then
expend
like
like,
for
example,
only
provide
names
based
ones
for
now
and
then
expand
it
to
non
namespace
ones
later,
or
vice
versa.
Just
so
that
we
can
actually
continue
to
make
forward
progress
rather
than
being
stuck
I.
E
Think
it's
a
pretty
simple
thing
to
to
to
change
now,
because
I
mean
really
it's
like
you
do
am
I
using
a
resource
for
the
clients,
names
based
or
not.
It's
it's
more
like
for
for
longer
term,
if
I'm
a
user
and
a
certain
interaction
that
I'm
used
to
and
suddenly
it's
different
I
think
like
as
much
is
it
to
me.
I
think
it
makes
sense
to
just
name
spacer
by
default,
put
it
into
the
system
namespace
and
just
be
done
with
it,
and
that
just
allows
a
lot
more
flexibility.
E
It's
kind
of
a
little
bit
hokey
the
way
that
namespaces
work
at
the
client
level,
because
it's
like
having
a
default
namespace
like
I,
think
that
can
confuse
and
trap
up
a
lot
of
people,
but
that's
kind
of
just
the
nature
of
how
cube
namespaces
work.
If
you
don't
understand
that
you
know
you
have
a
default
namespace
when
you're
performing
operations,
you're
kind
of
hosed
anyway,.
C
C
Are
mechanically
exactly
the
same,
but
are
conceptually
different,
so
you
imagine
I
have
some
a
cluster
turbidities
cluster
that
has
a
namespace
cluster
object
and
I
have
three
namespaces
for
my
three
different
regions
that
my
clusters
live
in
well
once
ago.
Those
namespaces
don't
have
any
meaning
in
the
cluster
themselves,
and
yet
it
is
now
possible
to
install
workloads
into
these
resources
and
have
things
in
these
resources
that
don't
have
real
meaning
within
the
cluster
itself,
because
the
cluster
is
not
necessarily
within
that
region.
C
The
clusters
in
a
particular
zone
within
that
region,
potentially
this
seems
like
a
very
confusing
mismatch
to
me.
I
think
that
was
the
the
the
second
negative
that
I
had
suggested
here
for
namespace
the
Quintin
you
had
mentioned
as
they're
compromised.
So
in
essence,
the
compromise
solution
we
had
thought
about
was
that
we
just
have
both
versions
of
the
API
right
out
the
gate.
C
The
plus
of
this
is
that
it
does
requires
us
to
not
actually
make
a
decision
right
now.
I
am
pretty
well
I
dislike
this
I
think
more
than
the
other
options
because
it
opened.
It
has
a
lot
of
negatives.
In
my
opinion,
it
opens
the
door
or
the
API
is
to
diverge
the
fact
that
we
have
two
differently
scope.
The
versions
of
the
same
API
means
that
we
overcome
the
initial
step
of
breaking
into
two
separate
things
that
now
have
the
potential
to
evolve
in
different
directions.
Almost
please
learn
to
keep
them
the
same
right.
C
So
I
think
that
you
can
have
them
technically
be
pointing
at
the
same
thing
right
now,
but
we've
set
a
precedent
that
in
case
of
a
decision
where
we
can't
agree,
we've
scored-
and
that
makes
it
very
easy
later
on
to
look
back
and
say:
oh
yeah,
we
can't
come
in
on
this.
We
wanted
this
group
of
people
want
do
this,
so
we
fork
I,
think
it's
hold.
E
On,
though
I
mean
fundamentally
we're
talking
about,
like
you
know
the
speken
status,
so
I
could
I
just
don't
see
why
those
couldn't
be
shared
in
common
and
yeah.
You
would
have
the
Oder
type
being
have
all
the
code
generation
for
a
namespace
that
I'm
not
names
based,
and
you
generate
two
different
things,
but
the
actual
implementation
would
be
shared
and
I.
Don't
I
think
that
would
forestall
the
possibility
of
divergence.
I.
E
C
Think
the
thing
that's
keeping
this
from
diverging
is
not
the
technical
fact
that
there
are
is
one
shade
implementation.
It
is
the
high
level
facts
that
we
actually
have
one
implementation
and
that
there's
a
there's,
a
substantial
barrier
and
burden
on
somebody
to
say,
I
want
to
go
and
do
this
other
thing
and
make
it
be
there
been
approved
model
or
is
in
essence,
now
we've
sweet.
C
If
we
agree
to
do
both,
we've
sanctioned
this
court,
and
now
somebody
can
take
one
or
the
other
moving
in
a
different
direction
and
has
an
easier
time
moving
that
and
bringing
the
burden
of
community
behind
them.
By
being
able
to
point
back
to
the
previous
decisions
of
work,
I
think
it
makes
it
and
I
think
it
makes
it
politically
easier
to
continue
to
diverge
the
API
than
it
is.
If
there
is
one
version
of
the
API
I.
F
Don't
have
a
strong
opinion
either
way,
but
but
what
I
can
tell
you
is
that
I
think
not
making
progress
and
not
releasing
a
beta
API
is
worse
than
any
of
the
bad
outcomes
that
I've
heard
for
the
alternatives.
So
my
suggestion
would
be
to
pick
one
of
the
three
alternatives
that
you
have
on
the
table
right
now
and
you
could
do
that
with
a
simple
vote
or
something
and
accept
that
not
everybody's
gonna
vote
for
the
same
alternative,
but
that's
better
than
not
going
forward
at
this
point
that
that's
my
advice,
I'm
not
so.
G
F
G
I,
don't
think
we
impasse
I.
Think
we
just
need
to
do
is
like
do
what
we've
done
in
the
past
before
is
take
the
time
focus
on
it
in
a
more
you
know,
just
gonna
have
a
session
in
a
more
focused
way
to
hit
this
I
know
that
Tim
feels
very
strongly
about
this
decision
too,
and
I
think
that
you
know
he
said
he's
willing
next
week
from
Hawkins.
So
he
feels
strongly
about
this
also,
so
we
can,
you
know,
I,
think
what
we
need
to
do,
for
this
is
have
a.
G
We
have
all
these
out-of-band
Federation
meetings
and
I
think
that
they're
wonderful
and
that
they're
allowing
for
focus
and
expertise.
It
looks
like
we
should
have
just
one
out-of-band,
the
cluster
registry
meeting,
where
we
discussed
this
and
other
items,
and
we
then
are
able
to
illis
the
problems
that
were
trying
to
solve,
and
the
last
time
I
heard
about
this-
that
the
real
issue
was
making
sure
that
it
was
compatible
and
that
OpenShift
had
a
feasible
solution
to
working
towards
it
when
I
I
think
Paula
you
on
the
line.
G
So
when
I
talked
to
Paul
about
this
and
I
may
be
misrepresenting
it,
which
is
why
I
think
we
need
to
make
sure
that
we
have
a
meeting
where
Paul
Tim
and
the
people
work
on
the
cluster
registry.
Together
the
question
he
had
as
I
understood
it
wasn't
that
namespacing
was
the
right
thing
to
do
as
much
as
he
felt
boxed
in
a
little
bit
by
openshift
implementation.
G
So
I
think
that
we
we
need
to
make
sure
that
we're
doing
what's
right
and
simple
for
the
users
and
then
on
top
of
that,
finding
of
what
we
can
do
to
make
this
work
with
open
shift
and
I
think
those
are
almost
like
two
separate
questions
and
that
that
should
be
our
focus.
I
think
it
is
doable
I,
don't
think
it's
impossible
and
I
don't
think
it's
an
impasse.
G
I've
I've
never
seen
an
impasse
in
kubernetes
I
think
that
we
all
work
together
and
try
to
come
up
with
the
the
right
decision
and
since
the
project's
really
started
that
that
has
been
one
of
the
guiding
lights
and
principles
of
what
we
do
and
so
to
sort
of
say
that
it's
too
hard
to
work
through
it
to
me
feels
like
we're.
We're
taking
a
step
back
of
what
makes
kubernetes
great.
G
G
So
really
you
know
in
preparation
for
that
meeting
if
everybody
could
just
kind
of
focus
on
their
use
case
and
bring
that
to
the
table,
that
I
think
that'd
be
and
I
think
it
would
be
good
too.
If
we
can
figure
out
who
the
owners,
the
stakeholders
and
the
opinion
holders
are.
So
we
know
exactly
what
the
impact
to
it
is
and
that'll
also
help
us
know
who
needs
to
be
there
but
I.
You
know
the
last
I
remember
hearing
about
it.
G
Isn't
that
there's
a
that,
we
think
the
users
will
be
better
served
by
a
namespace
I
believe
the
idea
was
we
have
all
this
legacy
machinery
around
and
then
how
do
we
make
it
work
with
that
machinery
and
to
me
that
isn't
enough
of
a
justification
to
do
something
where
we
want
to
make
users
lives
easier.
So
the
question
to
me
is
that
this
is
my
belief,
which
is
why
I
think
we
need
this
time
is
set
up.
G
What
we
think
is
going
to
be
best
for
the
user
and
then
figure
out
whatever
adapters,
that
we
need
for
the
legacy
space
right,
and
this
is
where
I
think
the
the
vote
fails
and,
for
example,
I'll,
give
that,
as
an
example,
I'll
say
we
left
this
out
to
community
as
a
question.
Everybody
started
chiming
in
including
a
lot
of
people
had
no
context
about
what
cluster
registry
was
and
by
far
the
opinion
was
well
everything
else's
name
space.
G
So
what's
the
issue
just
through
a
name
space
on
which
you
know
if
that
goes
to
the
votes.
Of
course,
we
end
up
putting
a
name
space
and
we're
not
sure
that's
the
variance,
I
think,
there's
I
think
there
needs
to
be
context
and
background
in
this
I
actually
thought
myself.
A
lot
of
this
is
from
my
own
ideas
and
in
ignorance,
where,
when
it's
question
first
came
up,
I
said
name
space.
G
Everything
is
good
that
helps
us
to
I,
get
so
involved
in
multi-tenancy
right
now,
and
then
I
learned
more
about
the
problem,
we're
trying
to
solve
and
the
shortcomings
of
doing
it.
That
way,
and
so
I
think
that
you
know
at
this
point,
I
remember
Tim
in
the
morning,
I
was
talking
to
him
and
he
was
also
feeling
the
same
way
he's
like
we
got
a
name
space
and
then
he
also
learned
more
about
the
problem.
G
You
know
the
context
and
then
he
came
back
to
me
and
said:
Oh,
Mike,
I'm,
sorry,
so
every
time
we've
broken
it
down
to
people.
So
far,
we've
come
to
that
conclusion
and
I
believe
Paul
may
be
in
that
camp
too.
But
may
be
constrained
by
the
machinery
of
OpenShift,
so
let's
alright
do
what's
great
for
the
user
and
then
let's
try
to
figure
out.
You
know
how
we
then
make
this
work
in
our
ecosystem
as
two
separate
pieces
and
I
think
we
can
do
both
I
mean
impasses
I.
E
Think
that
having
a
discussion
offline
is
impaired,
my
take
on
Paul's
sort
of
slant
is
a
little
bit
different
than
yours,
and
that
is
that
we're
really
lacking
here
is
filtered
list
and
launch,
and
so
maybe
we're
in
a
multi-tenancy
scenario
where
some
clusters
we
want
visible
to
some
users
and
not
others
and
namespacing
today,
is
the
only
way
to
accomplish
that.
If
we
have
a
global
cluster
resource,
we
just
at
least
people
who
have
direct
access
to
the
API.
E
There's
no
way
to
have
that
be
selective.
I
was
thinking,
though,
that
maybe
we
solve
that
by
simply
requiring
a
client
like
a
front-end
that
can
be
selective,
which
case
you.
You
know
anybody
who
wants
just
global
cluster
resource
and
everybody
can
see
everything
gets
what
they
want,
and
then
you
have
a
secondary
filtering
thing
in
front
of
that
for
users
that
require
that
sort
of
thing,
but
Paul
would
have
to
China
and
I
haven't
discussed
that
specifically
with
him,
but
at
least
I
think
does
that
give
you
some
insight
into
here?
It.
G
G
E
C
Right,
so
it
sounds
like
we're
in
agreement
that
we
need
to
have
follow-up
later
with
a
meeting.
We
can
take
an
action
item
to
set
up
that
meeting
with
people.
If
anyone
is
particularly
interested,
please
let
us
know
I,
don't
think
we'll
send
out
the
invite
to
the
entire
state
unit
in
an
attempt
to
keep
it
focused.