►
From YouTube: Kubernetes SIG Federation 20170501
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
Okay,
we
had
record
in
busines
second
get
started,
so
we
have
a
lot
of
lot
of
things
on
the
agenda
today
and
Jonathan,
and
also
second
email
about
doing
some
specific
design
interviews,
but
I
have
sort
of
an
unordered
I'm
in
this
chair.
We
can
go
to
them.
I
want
to
just
a
bit
cluster
selected
because
we
had
a
meeting
about
it.
Last
week
and
I.
Don't
summarise
on
the
like
summarize
our
discussion,
so
I
think
we
did
agree
that
there
is
a
framework.
A
C
When
we
move
forward
past
annotations,
we
have
the
opportunity
to
say
you
know
convince
kubernetes
that
they
need
to
put
a
federation
metadata
field
on
object,
meadow
so
that
all
objects
just
will
inherit
that,
but
there's
no
equivalent
mechanism
to
provide
status
across
all
objects
and
I
would
argue
that
we
do
actually
want
to
be
able
to
track
status
of
like
how
we
resolve
conflicts
say
between
policy
and
users
intent
that
sort
of
thing.
So
just
that,
even
though
yes,
it's
possible,
we
do
go
per
resource.
I.
C
A
I
really
wonder
types
say
that,
but
is
still
not
clear
to
me:
why
does
that
enforce
a
separate
resource?
Let
your
discuss
us
because
nothing
like
even
in
this.
So
if
you
had
like
an
extension
object
there
itself,
we
can
have
both
spy
considers,
so
they
whatever
feels
the
user
sense.
They
are
in
the
spec
of
that
extension
object
and
there's
the
status
for
this
problem
also.
C
A
C
I
guess
I'm
in
principle:
I'm
I,
don't
like
that
idea,
just
because
it
means
every
single
resource.
You
have
to
define
our
own
type
for
it
and
that's
just
for
cube,
but
also
I
mean
I'm.
Looking
at
extending
this
to
support
Oregon
and
that
means
we'd
have
to
have
anybody
wants
to
federate
anything
how
to
define
your
own
custom
type
yeah.
So.
A
D
Also
Mauro
to
answer
I
mean
to
address
your
concern:
does
it
does
it?
Does
it
solve
your
problem
if
we
build
a
mechanism
to
actually
have
some
sort
of
a
generation
mechanism
or
copying
mechanism
to
copy
all
the
feeds
from
kubernetes
to
Federation
and
always
keep
them
up
to
date
like
like
the
same
way,
we
run
updates
kids
today,
I
mean.
C
I
think
it's
do
me
wrong.
It's
a
solution.
I
just
think
it's
definitely
not
the
most
simplest
solution
and
I'm
always
like
that
would
be
my
preference
for
something
that
didn't
have
a
lot
of
overhead
and
customizing.
The
types
seems
it
seems
like
overhead
to
me.
That's
the
only
way
we
can
do.
It
then
sure,
but
I
would
vote
for
trying
to
see
if
we
can
maybe
use
a
separate
object
versus
specific
Federation
type
per
resource
or
what
afetr,
but
that
yeah
in
exams
yeah.
A
C
A
Awesome
next
item
my
hand
on
the
designs
of
spirited
jobs
and
what
didn't
hear
because,
like
we've,
been
sort
of
punting
it
a
lot
I
just
wanted
to
make
sure
people
have
reviewed.
Is
there
enough
feedback?
I
was
looking
at
the
dot,
it
looks
fairly.
Small
I
haven't
looked
at
it
in
detail,
I
don't
see
January
here,
but
I
wanted
to
make
sure
this
and
Scott
adapts
reviewers,
and
is
it.
F
A
B
A
G
Is
question
here:
I
reviewed
the
document
in
quite
a
bit
of
detail
and
I.
Think
all
of
those
issues
I
mean
they
might
not
actually
have
the
resolve
button
clicked,
but
all
of
the
questions
people
have
asked
but
I'm
aware
of
have
been
answered
and
I,
don't
think,
there's
much
contentious
if
any
contentious
stuff
left
in
the
design,
but
I'm
reasonably
comfortable.
If
we
move
ahead,
if
anyone
wants
to
have
a
look
at
them
comments,
they
obviously
welcome.
But
it's
featured
quite
a
bit
of
review
already.
C
C
Think
it's
I'm,
hoping
one
point:
seven
will
be
able
to
move
jobs
over
as
well,
so
I
guess
my
expectation
would
be
if
we
do
merge
this-
that
probably
it's
going
to
be
refactored
before
the
end
of
the
cycle.
Just
so
we're
not
adding
a
whole
bunch
more
duplicated
code,
like
all
the
other
controllers,
yeah
I,
totally.
C
C
G
A
G
A
G
E
G
C
Talked
about
this
last
week
and
the
I
think
we
kind
of
determined
that,
like
watching
all
pods
is
a
poor
way
to
accomplish
the
goal
of
being
able
to
know
when
a
replica
set
has
not
been
able
to
schedule
enough
pods,
yeah
and
rather
than
watching
all
pods.
It
should
be
possible
to
look
at
the
replica
sets
and
they
don't
schedule
an
out
free
sources.
You
can
check
the
pod
status
to
see
why
so
you
don't
have
to
watch
pods
to
do
that.
Yeah.
G
E
G
G
A
G
A
A
F
B
G
And
I
we
decided
that
it
was
going
to
be
a
tall
order
to
get
that
into
one
seven
but
I'd
like
to
like
us
to
get
very
close
to
getting
it
in.
In
one
seven
at
least
you
know
have
all
the
code
written
and
it
seems
to
me
like
we
could
we
can
get
pretty
close
to
getting
it
in
one
seven
and
maybe
even
squeeze
it
in
as
opposed
to
you
know
only
you
have
a
goal
of
having
a
design
document
by
the
one
seven
deadline,
which
of
anything
would
be
particularly
good
outcome
for
that.
C
G
C
Think
my
only
can
modern,
oh
I'm,
just
kind
of
thinking
about
the
implications
of
getting
access
to
all
cluster
objects.
Assuming
you're
talking
about
any
resource
that
the
Federation
control
plane
has
access
to
I'm.
Just
wondering
like
I'm
thinking
of
differential
off
like
I
have
the
ability
to
do
something
in
the
Federation
control
plane
and
then
the
Federation
control
plane
means
access
to.
The
underlying
clusters
may
be
greater
than
what
I
have
to
be
able
to
do
its
work,
and
the
individual
clusters,
like
is
that
it
actually
is
that
issue
come
up
at
all.
G
G
What
is
it
watching?
The
underlying
clusters,
all
that
kind
of
stuff
and
I,
think
that
we
can
resolve
in
the
design
document.
I
agree
with
you
that
the
permission
stuff
is
interesting,
but
in
a
sense
it's
not
much
different
than
all
the
other
permissions
questions
that
we
have
that
Nikhil's
busy
working
on
at
the
moment.
My
expectation
is
that
we
will
use
exactly
what
Nikhil's
working
on
in
parallel,
which
looks
like
it's
panning
out
to
be.
You
know
some
sort
of
separate
or
lower
ization
enforced
in
each
cluster
for
each
user
of
the
Federation.
G
So
you
know
Bob
tries
to
list
all
of
these
pods
across
all
clusters
and
he
doesn't
have
permission
to
miss
pods
in
you
know.
Xyz
cluster
there's.
Definitely
a
question
about
how
do
you
handle
that
error?
How
do
you
communicate
to
the
user
that
they
have?
They
can't
actually
see
all
the
pods.
They
can
only
see
the
pods
in
the
clusters,
which
their
permission
them
agree
that
those
are
you
know
interesting
questions
to
answer,
but
I
think
other
than
those
edge
cases.
We
can
get
pretty.
C
Far
with
the
rest
and
I
think
the
kind
of
case
I
was
more
worried
about
was,
like
you
know,
maybe
one
user
is
federating
secrets
and
another
user
is
not
really
permitted
to
see
those
they
can
just
consume
them
or
their
resources
can
consume
them
or
something
like
that.
But
when
you're
right,
it's
largely
separable.
When
you
talk
about
caching
and
like
I,
don't
know
just
if
there
are
people
from
sig
off
here,
they'd
probably
be
getting
goosebumps
by
now,
mmhmm.
G
Yeah,
no,
the
plan
is
not
to
do
caching
in
the
first
iteration
just
to
be
clear
and
yes,
there
are
some
some
other
questions
to
be
answered.
I,
don't
believe
many
of
them
are
are
specific
to
this
feature.
There
are
actually
general
Federation
or
questions
which
are
being
resolved
in
parallel
and
I.
Think
we
should
perhaps
be.
C
Afraid
I
have
not,
as
promised,
been
able
to
review
that
yet,
but
maybe
I'll
start
on
our
today
and
actually
make
some
progress,
but
at
the
same
time
I
think
that
the
outcome
of
the
discussion
last
week
around
doing
design
review.
You
know
all
in
alternating
weeks
and
in
this
meeting
I
think
anything
is
significant.
The
staple
sets
arguably
sets
the
criteria
should
be
reviewed
kind
of
as
a
group,
and
maybe
we
can
have
primary
reviewers
that
try
to
dig
a
bit
deeper
to
be
able
to.
G
B
G
A
C
Post
I
mean
socializing
design
to
a
wider
group,
means
that
as
many
stakeholders
as
possible
get
to
participate
at
the
same
time
when
it
comes
to
like
shepherding
like
PRS
through,
you
need
someone
who's
really
dedicated
at
a
lower
level
to
be
able
to
push
it
and
communicate
with
the
author,
etc.
So
we're
not
replacing
individual
design
with
group
design
we're
augmenting.
Okay,.
E
By
the
time
we
get
to
the
design
review.
I
want
to
understand
the
design
and
just
be
talking
about
the
concerns
I
have
because
that
would
make
that
half
an
hour
really
useful.
That's
when
we're
all
together,
we
can
talk
about
things
quickly,
resolve
things
rather
than
just
learning
what
the
design
is.
Yeah.
G
I've
totally
agree,
I
think
a
large
room
of
people.
You
haven't
greater
design
in
any
detail
yet
and
are
coming
up
with
questions
that
have
already
been
discussed
and
resolved
elsewhere.
It's
not
necessarily
productive
use
of
everyone's
time.
I
do
I.
Do
agree
that
not
everybody
has
time
to
you
know
read
through
the
details
of
every
design.
I
mean
one
option
we
could
have
is
well
well
to
that.
I
can
think
of
that
might
make
sense.
One
is
to
request
that
every
design
has
an
executive
summary
at
the
beginning,
which
doesn't
go
into
great
detail.
G
You
don't
have
to
read
the
ten
page
design
document
or
whatever
it
happens
to
be,
but
at
least
in
in
one
or
two
paragraphs
you
can
get
a
pretty
concise
explanation
of
how
it
works
with
the
key
points.
You
know
this
being
creates
these
things
down
the
line
clusters
authorizations
handle
like
this.
These
things
are
watch.
This
is
cash.
This
is
not
cashed,
etc,
and
then
you
know
all
the
detail
further
down.
That's
one
possible
approach
and
maybe
look
through
those
executive
summaries.
You
know
two
minutes
three.
Four
minutes
per
feature
in
this
meeting.
G
Another
option
is
to
have
a
separate,
dedicated
design
review
meeting,
but
not
all
the
review
happens
in
documents,
but
but
there's
actually
an
explicit
presentation
by
the
author
and
anyone
is
interested
in
that
specific
design.
Can
you
know,
spend
half
an
hour
or
whatever
and
I
would
suggest
that
a
prerequisite
for
that
is
that
the
people
attending
must
have
actually
read
the
entire
document.
I.
G
C
Make
oh
no,
no,
it
was
like
you'd
have
the
opportunity
to
get
forewarning
like
next
week.
We're
going
to
review
this
and,
depending
on
you
know
how
much
time
would
be
required.
Maybe
we
could
do
more
than
one
a
given
session,
but
people
would
come
prepared
and
actually
participate
in.
You
know
more
or
less
a
formal
design
review.
Okay,.
G
C
C
G
G
E
I
think
we
might
have
to
do
at
least
two
a
week
for
at
least
for
now
I
mean
if
we
can
see
how
that
works.
If
it's
really
not
working,
if
there
are
major
issues
that
aren't
being
resolved
in
the
meetings
or
just
not
finished,
then
we
we
might
have
to
adjust
or
schedule
or
reviews.
If
we
think
we
need
them,
but
I
guess
you
can
try
it.
Maybe
next
week
try
to
and
see
what
happens.
So
I'm
good
to
me.
E
Okay,
so
I'm
going
to
update
that
I've
made
a
spreadsheet
and
sent
it
out
with
I'll.
Go
update
that
so
it's
the
other
week,
I
already
put
the
Federation
API
object,
Federation
attributes
on
the
api's
as
something
to
review,
but
that
was
really
just
because
it
was
Friday
afternoon
and
I
wanted
to
put
something.
If
there's
things
that
we
think
are
more
important.
You
in
society
Ruggiero
sex
week
for.
G
E
F
Quick
comment
about
the
design
document
so
that
two
things
are
always
in
progress:
federated
expiating.
Maybe
that's
because
that's
how
doing
process
of
the
demon
through
that
or
is
that
something
we
listed?
The
phone
has
been
working
on
it
for
a
while
and
Quinton
has
done
a
very
extreme.
Our
chain
has
turned
up
30
teachers
at
News,
loves
it
yeah
and
there's
one
more
actually
which
the
resource
quota
thing
so
that
we
haven't
published
the
design.
F
E
G
F
A
B
H
G
Question
three
down:
the
axis
are
the
ones
that
are
unlikely
to
make.
One
serum
is
dumb
and,
as
we've
extensively
reviewed,
I'd
like
us
to
get
to
that
one
reasonably
soon
and
then
fatal,
clip
and
HDA
have
been
through
well,
I
think
HPA
effect,
yeah
I
think
both
of
those
have
actually
been
through
fairly
extensive
public
review.
G
I,
don't
know
how
many
people
in
this
group
got
involved
in
those
reviews,
but
but
certainly
people
are
Clayton
and
marching
from
HPA,
and
these
guys
with
him
extensively
involved
in
in
both
of
those
because
say
we
should
review
them
here,
but
yeah.
They
are
not
unseen
to
the
public
in
case.
That
is
the
impression.
F
A
G
Full-Size
NHPA
yeah,
it
sounds
reasonable.
I,
don't
think
it's
a
little
bit
clearer.
I
think
staples
is
an
HPA
that
the
implementation
will
probably
go
ahead
anyway.
In
the
meantime,
seeing
as
it's
being
reviewed
by
other
community
members
and
myself,
but
but
we
can
certainly
go
back
and
and
make
adjustments
after
the
review
here.
A
G
G
G
G
G
A
A
A
B
Which
is
something
for
cut
up
an
ingress
and
the
GLB
see
kubernetes
controller
person.
Here's
we're
camping
some
issues.
Issues
only
show
up
when
many
concurrent
ingress
objects
are
created
and
deleted
within
a
project
in
the
precondition
project,
and
there
see
should
be
resolved
sometime
early
this
week,
at
which
time
we
should
move
to
officially
enabling
the
priests
and
it's
nice.
A
Okay
for
big
contradiction:
yes,
so
I
I
guess
I
can
discuss
this
more
next
week
when
I
take.
Is
it
going
to
show
hopefully
a
few
demos
and
shows
how
even
external
people
can
look
at
logs
and
during
bill
computation,
and
once
we
have
that,
then
we
can
set
it
up.
I
guess
at
this
point,
I'm
is
doing.
We
do
have
a
given
that
we
want
the
competition
and
we
have
swallowed
gist.
So
now
it's
just
about
setting
it
up.
A
Okay,
sure
you
don't
have
anything
else.
B
B
G
B
G
B
D
Hi
it's
here,
I
had
a
couple
of
things.
Actually,
I
was
working
on
later
election
for
control
manager,
so
I
was
little
lost
on
the
cluster
predicted
cluster
selector
yeah,
so
so
I
I
would
I
think
design.
Most
most
of
it
is
complete
I
believe
so
the
implementation
wise
I,
think
is
there
anything
blocking
there.
White
is
not
moving.
You
mean
design
for
lead.
A
Election
or
for
clusters
of
it,
let's
just
Alisa
yeah,
we
were
just
discussing
it
earlier
and
yeah
we
do.
What
for
now,
we
want
to
move
forward
with
the
validation.
Here
is
a
purge,
but
we
do
want
to
resolve.
Oh,
like
the
second
item,
filtration
specific.
Actually,
so
we'll
do
it
generally
follow
this,
and
if
so,
we
will
move
forward
and
then
has
a
pl
which
is
interview,
and
hopefully
is
that
can
be
moist
enough,
so
that
would
unlock
okay.
D
A
D
D
F
D
G
H
A
G
I
saw
that
feedback
I
all
I
saw
was
problem
statements
as
opposed
to
proposed
solutions.
Yes,
those.
A
C
A
C
C
Let
me
talk
about
this
last
week,
like
just
the
idea
of
just
you
know,
the
user
can
have
a
different
user
per
cluster
that
has
whatever
access
it
needs,
but
the
idea
that
you're,
like
you're,
trying
to
synchronize
who's
accessing
Federation
with
who's
like
specific
users
that
are
accessing
the
underlying
clusters,
like
what
are
the
use
cases
around
that
because
I
know
people
want
something.
But
it's
not
clear
to
me
what
problem
not
solving
given
just
how
much
complexity
is
involved
so.
A
One
of
the
problems
of
unmuted
leaving
and
delaying
this
they
using
predation
would
have
access
to
little
in
multiple
namespaces
and
many
resources,
but
one
user
has
access
only
to
like
I
said
redeployments
only
colleague,
resources,
but
because,
if
sedition
is
using
its
own
identity
to
talk
to
the
underlying
cluster,
he
can
escalate
his
privileges
by
using
Federation.
But.
C
A
So
that
was
another
feedback
record
and
I
don't
see
tail,
but
yeah
I'd
find
another
issue
for
discussing
an
alternate
implementation
where
we
would
use
namespace
code
service
accounts.
So
right
now,
Federation
uses
one
single
credentials
to
talk
to
each
lesson,
but
that
single
credential
is
for
all
namespaces
on
that
cluster
and
yeah.
This
is
one
of
the
idea
that
Khaitan
also
suggested
that,
rather
than
using
per
user,
we
do
move
by
namespace
service
accounts
can't.
C
E
C
Can
be
named
pods
in
a
cluster
li,
you
can
only
access
a
pod
named
foo.
So
but
there's
a
problem
with
that
is
is
like.
Then,
it
kind
of
sets
up
a
chicken
or
egg
problem
where
the
federation
control
plane
needs
to
know
what
it
has
access
to,
but
its
federating
what
it
has
access
to,
and
how
does
it
set
up
the
roles
like
you
almost
sets
up
like
a
you
need
one
mechanism
in
the
Federation
control
plane
that
sets
up
the
expected
access
rules
it's
going
to
require.
C
A
I
mean
I
do
use
using
like
the
authorization
with
the
definition
level
is
way.
So
if
a
user
only
has
access
to
some
specific
deployment,
if
the
admin
in
shows
that
the
authorization
rules
are
saying
that
a
tradition
level
also,
this
is
the
same
authorization
that
they
can
only
create
lead
deployments,
but
not
secrets.
Then
it
would
work.
But
in
this
case
the
underlying
clusters
are
sort
of
trusting
Federation
and
ensuring
that
their
same
authorization
rules
sync
their
clothes,
and
this
would
do
it
easier
with
federated
I
back.
A
A
E
A
One
of
the
others
feedback
was
also
yeah
right
now
the
underlying
clusters
have
to
trust
Federation
for
authorization
in
the
new
impersonation
model.
They
still
have
to
trust
it
to
perform
the
light
authentication
because
then
only
they
are
looking
personating,
the
right
user.
So
there
is
still
some
trust
in
models,
even
in
impersonation.
G
C
Authenticating,
the
problem
isn't:
isn't
the
trust,
though
it's
the
level
of
access,
so,
if
I'm
giving
full
access
to
my
class
by
an
underlying
cluster,
that's
what
people
are
worried
about
versus
Confederation
control
plan
has
full
access
to
selective
namespaces
and
outside
of
that.
That
has
zero
access
and
therefore
those
like
those
other
namespaces
can't
be
earth
by
some
sort
of
random
Federation
issue.
A
E
Israel,
let's
try
to
be
my
cute
cuddles
correctly,
getting
the
resources
and
not
doing
some
buggy
thing
where
a
user
is
getting
somebody
else's
credentials.
I
mean
it's
not
exactly
the
same
problem,
but
it's
a
similar
problem
of
until
the
user
is
like
walking
up
and
knocking
on
the
door
directly
and
providing
their
own
credentials
and
verifying
themselves
directly
if
they
have
any
tool
in
the
middle.
That's
what
could
have
a
bug
which
could
cause
an
escalation
privileges.
G
Yes,
but
one
of
the
proposals
yeah
not
one
that,
but
that
I
think
is
the
most
sensible
and
which
I
think
addresses
many
of
these,
but
I
just
want
to
make
sure
we're
not
talking
past
each
other.
So
my
understanding
of
Makela
feedback
was
but
the
concern
about
that
problem.
That
proposal
was
that
you
know
Bob
goes
to
Federation
and
says:
please,
you
know
do
stuff
in
cluster
X.
G
G
A
A
G
G
G
Is
the
problem
we
want
to
solve?
Please
tell
us
what
you
would
like
us
to
do.
Do
you
want
us
to
use
impersonation,
because
previously
you
told
us
you
did,
and
now
you
tell
us
you
don't.
Would
you
like
us
to
use
the
other
propose?
The
other
mechanism,
whereby
short
use
to
Perkins
are
issued
to
the
Federation
to
act
on
behalf
of
a
user
for
a
limited
period
of
time
or
a
limited
number
of
Quays
or
some
some
other
similar
thing.
G
Or
do
you
want
us
to
do
something
else,
but
but
tell
us
what
you
want
to
do
and
we'll
do
that
I.
Don't
personally
have
a
strong
feeling
about
any
of
these
things.
I
just
want
us
to
kind
of
get
over
the
circle.
Where
you
know
we
come
up
with
a
proposal.
They
say
you
can't
do
that
do
this.
Instead,
we
come
up
with
a
counter
proposal
proposal
based
on
what
you
got.
Let
me
get
told
you
bumped,
you
bet
either
it.
C
Was
creeping
and
why
they're
pushing
back
and
it's
not
just
oh,
this
is
not
you
know
a
good
way
to
do.
We
want
to
see
that,
like
the
issue
with
impersonation
is
how
do
you
know
who
to
impersonate
a
like
you
to
impersonate?
They
don't
have
field
level
like
access,
control
and
kubernetes,
so
acceleration.
Don't
you
get
that
either?
So
it's
basically
last
person
who
touched
it
their
permissions
decide
how
it
gets
federated
and
that's
kind
of
problematic,
yeah,
good.
A
A
C
Saying
it's
kind
of
like
it's
a
precondition
for
deciding
how
we're
going
to
interact
with
the
underlying
clusters
is:
what's
the
level
of
granularity
for
authorization
we
can
actually
achieve
with
kubernetes
today,
which
is
why,
like
I,
think
namespaces
are
kind
of
a
natural
way
to
do
it?
You
can
specify
our
back
roles
on
a
per
resource
basis,
if
you
name
them
if
you're
explicit,
but
it
doesn't
really
generalize
to
the
type
of
automation.
Federation
is
doing
yeah.
A
G
Just
to
go
back
to
that
previous
comment,
we've
only
got
four
minutes
left
Merle,
but
but
I
guess
I
did
totally
understand
the
problem,
so
user
a
creates
resource
X
and
it
gets
that
that
operation,
the
creation
of
that
object,
gets
propagated
down
to
the
cluster,
as
whatever
user
X
maps
to
in
that
cluster
right
now,
a
user
B
updates
object,
X
and
that
update
gets
propagated
to
the
cluster
as
whatever
in
the
context
of
whatever
user
B
is
in
that
cluster.
So.
C
G
C
G
G
C
Is
this
is
kind
of
like
like
in
auth
world
I
created
the
object?
Maybe
there's
something
wrong
with
the
object
and
somebody
else
comes
along
and
doesn't
really
look
at
the
object
carefully,
but
updates
a
field,
and
there
are
access.
Permissions
are
higher
than
the
initial
user
and
so
it'll
be
federated
with
the
secondary
users,
permissions
and
I'm.
Just
saying
I'm
not
saying
that's
like.
Oh,
it's
going
to
be
a
problem.
I'm
just
saying,
there's
kind
of
like
it's
potentially
a
problem
and
if
you
care
about
authorization
anyway,.
A
I
think
they're
two
distinct
purposes.
The
first
minute
they've
been
batch.
Those
of
this
and
in
batching
we
have
the
problem
that
Malou,
stating
that
if
one
user
created
it
but
didn't
have
the
permission
to
create
it
in
and
the
ring
under
a
cluster,
but
the
second
user
just
updated
it
and
he
has
the
authorization
to
create
as
well
and
if
we
batch
both
of
them
together
and
send
the
update
as
the
second
user,
this
will
go
to
submerging
does
have
the
problem
that
Romero
is
stating,
but
the
other
proposal
is.
A
C
Subject
into
detail
right,
like
you're
talking
about
actually
tracking
version,
so
you're
going
well
beyond,
where
kubernetes
today
guys
and
that's
kind
of
money,
consider
a
time
not
saying
it
can't
be
done
things.
We
decide
to
go
down
that
road,
we're
diverging
from
how
kubernetes
works
today
and
wanted
squared.
C
Federation
I'm
talking
about
the
fact
that
Federation,
the
Federation
control
plane
basically
builds
on
a
lot
of
I
mean
it
uses
kubernetes
the
API
server.
Now
that
behaves
and
you're
saying
well
we're
going
to
do
this
and
that's
kind
of
outside
the
scope
of
the
kubernetes
api
server
and
we're
just
going
to
support
it
ourselves
and
I'm
going.
Maybe
they'll
get
better
eventually
like
field
level,
access
control,
that
kind
of
thing
I.
A
C
A
If
we
change
that,
we
diverge
from
the
kubernetes
model,
yes,
and
it
is
going
to
be
a
big
change
and
yeah
I
agree
access,
but
like
maintaining
sort
of
log
of
which
feels
updated,
which
we
was
objected
by
each
user
and
we
can
go
in,
but
it
won't
just
be
HP.
If
you
consider
Maps
it's
going
to
be
like
each
key
in
that
map,
let's
say
I
and
this
participant.
C
An
object
like
you
can
just
use,
keep
track
of.
Like
you
know,
this
is
a
project.
I
mean
object.
Versioning.
Is
it
saying
in
most
databases
that
you
use
and
we
can
use
something
like
that
I'm
just
saying
like?
How
are
we
going
to
track
it?
How
we're
going
to
you
know
you
kind
of
have
to
store
it
because
a
watch
is
not.
You
know
if
you
lose
connection
and
you
missed
a
version
today,
you
just
basically
lose
that
detail.
C
C
So
I
mean,
like
I,
said
my
my
conception
is
I.
Don't
think
we
want
to
go
down
that
road
I
think
we
want
to
concentrate
on
less
granular
authorization,
so
we
can
just
avoid
the
problem
unless
there's
a
specific
use
case
that
requires
this
capability,
because
it
kind
of
seems
to
me
it's
a
little
bit
like
gold
plating.
We
want
this
would
be
really
nice
to
have.
This
would
be
a
great
feature,
but
it's
going
to
be
super
complicated
and
keep.
A
Going
to
be
super
complicated,
but
I
do
think
that
we
have
a
valid
contiguous
kids
to
be
able
to
do
this.
So
I
wanting
to
do
this,
and
the
uses
in
fact
like
I
as
a
team
or
as
an
individual,
have
access
to
multiple
clusters
and
I
should
just
be
able
to
use
hydration
without
asking
admins
of
those
clusters
to
trust
Federation
force.
A
To
give
it
some
special
piping,
created
special
service
account
for
Federation
or
give
it
impersonation
powers
or
anything
like
I,
have
access
to
multiple
slesin
and
I
should
just
be
able
to
use
position
and
those
who
are
cells.
First
me
and
position
will
use
my
credentials
to
talk
to
those
in
the
registers,
so.
C
These
pastors
have
no
conception
of
haiku
I
mean
a
permission.
Model
is
important
there.
If
you
have
a
permission
model
that
would
allow
that
I
think
today,
that
would
work
like
I
can
set
up
my
own
personal
Federation,
the
Federation
two
clusters
that
I
don't
actually
admin
I,
give
it
access
control,
but
that
I
think
the
limiting
the
limiting
factor
today
is
that
we
don't
really
have
a
conception
of
federating
to
a
parcel
cluster.
We
just
assume
we
have
full
global
access.
No.
A
C
Is
it
okay,
so
the
namespaces,
maybe
I'm
I,
was
under
the
impression,
after
talking
to
David,
that
if
you
were
to
restrict
access
to
an
underlying
cluster
to
specific
namespaces
like
how
would
watches
work,
I
want
to
watch
all
secrets
and
everywhere
and
I
don't
have
permission
to.
I
only
have
permission
to
do
that
and
use
namespaces,
and
it
seemed
to
me
he
suggested
that
the
only
way
to
do
that
would
actually
be
to
watch
the
namespaces.
You
have
access
to
and
not
all
namespaces
so
I
have
access
to.
C
Maybe
just
maybe
I've
missed
some
detail,
or
maybe
you
know
there's
a
way
to
do
that,
but
I
like
the
way
that
watches
and
lists
work
in
kubernetes.
It's
not
particularly
granny,
where
it's
kind
of
like
all-or-nothing
or,
if
you
know
I,
can
do
a
namespace
or
everything,
but
like
doing
only
the
things
I
have
access
to
I,
don't
think
that
works
today.
Maybe
we
just
need
to
confirm
that
that
makes
them
yes,
so.
A
Yeah,
that's
a
good
point.
So
when
you
give
conditioners,
as
I
said,
you
can
restrict
it
to
liquid
so
just
to
namespaces.
But
the
way
our
controller
code
is
written,
it
tries
to
set
up
watch
on
all
link,
switches
and
I,
don't
know
if
it
has
authorization
only
or
two
namespaces.
They
get
watch
notifications
only
for
those
tune
instances.
It
just
feels
like
and
doesn't
get
any
notification
any
watch
notification
at
all
and.
J
C
It's
kind
of
like
you,
it's
more
expensive.
If
you
have
a
lot
of
namespaces
you're
watching
suddenly
have
a
lot
more
work
to
do.
Potentially
you
have
a
lot
more
open
connections,
so
I'm
not
saying
I'm,
just
I'm,
not
sure
it's
a
general
like
we
just
want
to
watch
namespaces
individually,
because
some
people
maybe
want
to
have
access
to
everything
and
then
it's
more
expensive
for
them.
So
it's
kind
of
something
we
have
to
explore.
A
Okay,
yeah,
that's
a
good
point
which
I
can
look
into,
but
we
do
want
to
make
sure
that
even
it
so
in
my
proposal,
I'll
have
little
single
identity
and
user
identity
in
this
single
identity.
Would
the
Federation
gets
an
identity
which
it
always
uses
to
send
mutations
to
the
line
classes?
You
should
be
able
to
respect
that
to
specific
namespaces.
We
do
want
to
suppose
that
and
the
other
is
where
it
uses
user's
identity
and
in
that
case,
Federation
will
be
restricted
to
whatever
user
is
restricted.
G
C
Not
sure
I
agree
just
because
we
have
we
have
a
constrained
like
set
of.
We
have
a
constrained
problem
right.
We
have
kubernetes
we're
using
kubernetes.
We
can't
really
go
too
far
beyond
the
bounds
of
what
it
already
implements,
and
so
we
just
pick
up
a
solution
that
doesn't
take
that
into
consideration
we're
likely
to
come
up
with
what.
G
A
G
Atomic
transaction
sure
sure
no
no
I
understand
that
there
might
be
some
challenges
there.
I
mean
kubernetes
does
not
actually
grant
field
level
permissions
yet
so,
to
some
extent,
that's
worrying
about
things
in
the
future.
You
can
either
create
an
object
or
not,
and
you
can
either
update
it
or
not,
and
as
long
as
we
do
a
creation
operation
as
the
correct
user
and
a
update
operation
is
the
correct
user.
Today
we're
as
secure
as
kubernetes.
G
G
And
if,
in
the
future
they
create
field
level
permissions,
where
you
can
update
field
X,
but
not
field
Y,
then
we
need
to
do
the
equivalent
thing
in
Federation
to
you
know:
80
bet,
but
I
personally,
in
it
I
mean
we
should
speak
to
your
code.
That
seems
like
a
really
difficult
thing
to
do,
given
the
status
of
our
back
and
like
that
will
be
a
big
long-term
change
to
kubernetes.
G
So
I
can't
see
it
happening
like
in
1.8
and-
and
we
should
you
know-
be
involved
in
that
discussion
if
it
is
going
to
happen
and
figure
out
how
to
deal
with
it,
but
there
you
know
there
are
many
examples
of
things
that
may
or
may
not
come
down
the
line
in
communities
that
we
will
have
to.
You
know
deal
with
as
well
all
the
other
clients,
quite
frankly,
of
a
little
bit
just
a
client
already
cluster.
It
changed
to
field
level
access.
Well,
then,
those
clients
all
going
to
have
to
do
those
times
pretty.
C
Unlikely
that's
going
to
happen
at
all.
To
be
honest,
just
the
way
that
that
CD
is
structured
doesn't
make
that
easy
as
much
as
people
want
to
invent
a
relational
database
on
top
of
a
blob
store.
I,
don't
understand
what
you
what
you
meant
by
that
Norman
I
mean
that
xcd
I
mean
you.
You
have
more
experience
with.
You
know
that
type
of
thing
I
mean.
C
Presumably
@cd
is
modeled
after
what
people
think
they
know
about
something
like
Chevy
but
like
kubernetes,
is
kind
of
like
growing
all
of
these
niceties
that
you
would
normally
have
like
in
relational
database
land.
Like
you
know,
field
level,
access
control,
which
kind
of
involves
like
say,
a
more
fixed
idea
of
a
schema,
and
so
we're
kind
of
like
building.
G
C
Sure
it
doesn't
it
doesn't,
though,
because
I
mean
yeah,
you
can
do
everything
at
the
API
server,
but
fundamentally
there's
kind
of
constraints
on
what
you're
doing
if
the
underlying
data
store
is
completely
oblivious
to
that,
especially
when
you
get
into
things
like
object,
versioning
I'm,
just
saying
to
me:
it's
like
there's
certain
assumptions
baked
into
how
things
are
working,
and
you
know
there's
only
so
far
that
it's
malleable
breaking
a
lot
of
those.
So.
A
G
Speculating
that
that
we
should
check
with
the
people
considering
these
things,
but
it's
not
an
hour
back
at
the
moment
and
it
seems
like
a
big
change.
So
it
seems
like
a
reasonable
test
of
assumption
that
it's
going
to
take
a
while,
and
we
should
verify
that
with
the
OAuth
guys-
and
that
was
the
impression
I
got
speaking
to
the
are
back
people
like
a
month
ago,
in
which
case
at
least
figuring
out
something
that
works
from
the
current
model
now
would
be
useful.
Yes,.
A
C
A
C
And
my
my
interactions
with
the
off
guys
kind
of
mirrors,
your
experience
Quentin,
but
it's
not
going
to
happening.
I
mean
it's
not
it's
not
in
the
near
term
and
seeing
the
reason
I
was
bringing
up
like
how
at
CD
is
kind
of
how
it
functions.
You
know,
maybe
at
the
API
server
is
nominally
independent,
but
from
a
realistic
perspective,
the
cost
of
implementing
field
level
access
control
would
be
considerable
in
terms
of
performance.
A
Yeah
right
right
so
I
think
I.
You
do
have
a
sort
of
a
clear
path
for
signals
like
who
to
impersonate,
have
toddlers
created
created
by
user
and
the
one
who
last
updated
it,
but
we
still
need
to
figure
out
how
to
weather,
impersonate
or
use
the
connections
or
ask
say
God,
for
this
is
another
way
of
doing
it.
Yeah.
G
B
G
B
G
B
G
J
G
Let's
focus
on
something
that
is
at
least
as
secure
as
kubernetes
and
then
worried
about
scalability
and
how
we
make
that
you
know
scale
to
large
numbers
of
clusters
or
large
numbers
of
users
or
whatever
what
there
might
be,
and
that
might
be
a
face
to
you
know,
maybe
maybe
a
secure
implementation
like
doesn't
scale
beyond
some.
You
know
ten
clusters
and
ten
users,
or
something
and
I
would
be
like
reasonably
okay
with
that.
If
you
want
security,
this
is
where
we
are
scalability
wise
and
we're
working
on,
including
that
so
plan.