►
From YouTube: Gateway API Office Hours 20201007
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
Welcome
to
office
hours
for
service
apis.
We
are
really
getting
down
to
the
end
of
this.
I
think,
and
on
that
note
I
think
today
will
be
the
day
we
hit
our
rc
out
our
first
rc,
maybe
our
only
rc
for
alpha.
I
don't
know,
and
as
part
of
that,
we
should
go
through
our
alpha
release
checklist,
I
think,
like
I
haven't
updated
this
in
a
while.
I
know
our
milestone,
maybe
be
is
more
up
to
date.
At
this
point
yeah.
Let's
take
a
look
here:
real
quick.
A
We've
got
a
few
things
still
left
here.
As
far
as
actual
pull
requests,
I
think
we're
pretty
limited,
though
we
have
this
pr
for
listener,
condition
types,
and
I
think
james,
you
add,
you
have
one
more
pr
you'd
like
to
get
in
around
conditions,
and
this
is
for
positive
states.
I
forget
exactly
what
what
up
what's
left
on
conditions.
A
A
B
A
B
That's
a,
I
don't
think,
that's
a
blocker
for
writing
the
release
like
because
implementations
can
always
add
their
own
reason.
It's.
C
B
I
think
adding
a
reason
for
when
the
condition
is
you
know,
is
a
successful
state.
Just
standardizing
that
is
is
useful
and
helpful,
but
we
can
ship
alpha
one
without
it.
A
Cool
and
a
lot
of
these
that
are
left
are
kind
documentation.
It
looks
like
james,
you
have,
you
have
fixed
or
you
have
a
pr
to
fix
this
one
already.
Oh,
yes,
that's
right,
because
it
was
fixed
in
a
separate
pr
that
you've
since
closed.
Thank
you.
B
A
Yeah
makes
sense.
Well,
this
looks
really
straightforward.
I
know
I've
seen
this
before
it's
unused
it'd
be
great
to
have
it
fixed.
Does
anyone
have
any
problem
with
me
just
getting
this
in
now.
A
A
All
right,
so
that's
the
one
alpha
one,
but
let's
talk
about
the
thing
that
I
brought
up
earlier
james
and
I
had
a
discussion
around
this
pr.
It's
listener
condition
types
and
it
seems
to
at
least
somewhat
contradict
what
we
had
originally
proposed
as
guiding
principles
for
conflict
resolution.
A
B
Sure
so
I
think,
maybe
a
month
ago
or.
B
We
talked
about
the
we
had
talked
about
the
conditions
of
vocabulary
and
I
felt
like
we
had
consensus
around
that
people
seemed
to
feel
that
most
of
the
error
cases
were
covered.
So
this
is
my
pr
for
applying
that
into
into
the
api.
B
So
when
I
came
down
to
it,
I
noticed
that
there
was
a
lot
of
there
was
some
not
a
lot
of,
but
there's
some
cases
in
http
routes,
specifically
where
the
kind
of
the
error
handling
is
pretty
vague
for
us.
So
you
know
we
have
things
language
like
if
the
referent
can't
be
found,
the
invalid
routes,
status,
condition
on
any
gateway
will
be
true.
B
Okay,
so
invalid
routes,
sort
of
becomes.
This
resolved
ref
invalid
routes,
condition
in
this
new
vocabulary,
maps
to
the
resolved,
refs
condition,
condition
type.
So
the
resolve
refs
has
a
reason.
B
B
Do
you
raise
this
condition
and
then
like
what
it's
not
very
specific
about
what
a
controller
should
actually
do
so,
basically,
as
a
like
a
general
blank,
easy
to
describe
generally
easy
to
describe
easy
to
implement
easy
to
understand
policy,
what
the
language
I
added
here
is
that
if
you
can't,
when
you
can't
resolve
stuff
in
a
route,
the
controller
should
flag
that
in
a
resolved,
refs
condition,
and
it
should
say
I
dropped
the
routes
as
the
reason
and
then
the
route
should
be
dropped.
B
So
there's
a
summary
in
it's
basically
a
list
of
pros
and
cons
in
the
comment
and
the
bottom
which
which
I
summarized
from
the
slack
thread.
Where
rob
and
I
kind
of
went
back
and
forth
on
this
from
one
point
of
view-
dropping
a
whole
route.
We
had
this
principle
that
we
should
that
update
should
break
as
as
little
as
possible.
B
So
I
mean
from
with
my
language
lawyer
hat
on-
I
I
think,
there's
a
fair
bit
of
wiggle
room
in
that
within
that
principle,
because
we
could
define
as
little
as
possible
with
a
fair
degree
of
latitude,
but
I
think
dropping
a
whole
route.
B
Is
you
know
a
larger
error
case
than
dropping
part
of
a
route,
but
on
the
other
hand,
the
semantics
of
dropping
a
whole
route
fairly
straightforward
to
reason
about,
whereas
the
semantics
of
dropping
part
of
the
functionality
of
a
route
are
kind
of
less
so
so
now
we
also
have
these
diff
these
cases,
where
different
references
seem
to
be
you.
You
could
argue
that
different
references
are
important
in
different
ways.
B
So
dropping
a
mirroring
target.
You
know
some
sites
may
be
okay.
With
that
I
mean
you
can
construct,
thought
experiments
where
oh
mirroring
really
matters
for
some
business
reason.
It's
super
critical,
but
in
general
I
think
it's
reasonable
to
assume
that
mirroring
is
less
important
than
say
the
reference
for
a
match
and
then
we
get
into
the.
But
then
once
we
go
down
this
path,
we
end
up
with
well
different.
Different
references
and
different
kinds
of
references
within
the
http
route
have
different
error
cases.
B
B
So
if
we
just
silently
said
everything's
okay,
then
everything
would
be
okay,
but
the
status,
but
the
actual
fundamental
status
of
the
infrastructure
wouldn't
match
the
spec,
and
that
seems
bad
to
me
because
it's
pretty
it's
pretty
misleading
the
only
way
you
know
that
it's
not
working
is
by
having
you
know,
good
operational
visibility
into
what
ought
to
happen.
I
feel
like
the
api
when
the
api
doesn't
do
what
you
asked
it
to
do.
It
should
surface
that
somehow,
but
we
don't
actually
have
a
way
to
surface
that.
A
Yeah,
that's
a
that's
a
really
good
background
and
I
I
feel
like
this
is
an
unnecessarily
complex
issue
to
solve
correctly.
A
I,
the
the
one
side
of
this
is
that
you
risk
breaking
things
more
than
necessary,
as
as
an
example,
somebody
has
an
extension
rep
somewhere
that
doesn't
matter
too
much,
but
somebody
somewhere
else
in
your
cluster
deletes
the
resource
that's
pointing
to
and
then
every
route
that
is.
You
know
pointing
to
that
that
thing
that
doesn't
matter
that
much
for
whatever
reason
breaks
that
that
feels
bad,
but
I
can't
think
of
a
good
way
around
that
be
like
what
james
has
already
said
is
the
most
consistent.
E
B
E
Thing
and
you're
exposing
that
route.
It's
the
security
problem
right
now,
right
so
hard
to
it's
hard
to
know
how
much
that
referent
matters
or
not.
B
B
In
the
in
the
list,
I
was
saying
that
we
can
construct
a
thought
experiment
for
each
reference
where
it
does
matter,
so
I
think
that's
an
example
of
that,
so
you
can
always.
I
think
any
one
of
us
on
on
this
call
have
seen
enough
different
deployments,
where
we
could
probably
imagine
some
use
case
where
some
particular
reference
in
you
know
some
something
some
particular
reference
is
going
to
actually
crucially
matter
in
some
way.
A
A
I
think
james
idea
there
was
well
what
if
that
mirror
is
for
auto
logging,
and
you
absolutely
need
that
for
compliance
well,
okay
and
and
similarly
for
forward
two
I'd
argue
well:
okay,
let's
say
that
you
have
multiple
forward
two
targets
and
you
only
lose
one
of
them
and
maybe
it's
only
your
canary
target
is
an
invalid
reference.
Do
you
want
to
drop
all
of
your
traffic,
but
you
don't
know
like
obviously
we
have
no
way
of
knowing
which
one
has
become
invalid,
so
yeah.
I.
B
So
on
the
chat
harry
raised
the
idea
of
using
events
to
address
this.
I
don't
have
much
experience
with
events,
but
maybe
someone
else
has
some
perspective
on
that.
E
Events
are
not
easy
to
use
the
last
time
I
used,
but
it's
been
a
while
this
is
sort
of
half
baked
and
like
the
machinery
around,
it
is
not
complete,
but
that's
another
way
to
raise.
Okay,
if
something
is
invalid
and
if
you
know
status
is
not
the
right
place
to
raise
that
the
events
are
sort
of
logs
for
that
specific
resource.
A
A
Is
going
to
be
relatively
visible,
you
know
someone
who
debugs
clusters.
On
occasion,
you
know
one
of
the
things
that
is
easy
to
look
for
when
you
get
into
a
namespace
is
events
for
that
game
space?
What
happened
here
and
so
publishing
an
event
in
the
same
name,
space
as
a
route
or
gateway,
whatever
it
happens,
to
be,
could
help
provide
some
visibility,
some
more
visibility
than
simply
a
status
condition
on
a
route
or
a
gateway
yeah.
A
C
Everything
is
choppy.
Can
you
hear
me
all
right.
C
So
I'm
reading
this
dropping
hole,
wrap
works
against
our
principles
or
updates
to
break
as
little
as
possible.
One
thing
that's
interesting
here
is
we
don't
mention
the
any
statefulness.
C
C
B
Should
you
remove
the
working
route
altogether
or
should
you
keep
the
working
route
and
drop
the
previous
update?
No,
that's
not
totally
clear
to
me.
I
I
think
the
latter
is
kind
of
what
you
want,
because
that's
the
one
that
makes
that
was
the
one
that
leaves
you
in
a
consistent
state.
B
So
if
you
kept
the
previous
version
of
the
route
programmed
into
the
infrastructure
and
then
and
then
raised
an
error
on
the
new
version
of
the
route,
then
it
feels
like
you:
don't
have
a
good
way
to
it
feels
like
you're
again.
Your
spec
is
then
inconsistent
with
your
infrastructure
state
in
a
sort
of
semi-permanent
way.
C
B
Yeah
I
mean
I
can
imagine
implementations
doing
different
things.
I
suppose,
but
it
really
depends
on
you
know.
Does
your
implementation
have
enough
state
to
be
able
to
know
that
this
has
happened,
because
you
can
say
that
we
you
could
I
mean
you
could
argue.
You
could
reason
that
okay,
the
dropped
routes,
you
know
I
I
resolved
ref
and
I
dropped
the
route.
B
C
C
F
B
Would
you
then
withdraw
the
route?
Arguably,
so
the
route
can
be
broken
after
the
fact
by.
A
A
The
the
whole
idea
of
let's
take
the
authentication
example
is
a
great
idea.
Great
example:
let's
say
someone
deploys
a
route,
it
works,
but
they
forgot
authentication
and
so
there's
panic
and
they
deploy
this
new
authentication
thing,
but
it
but
their
authentication
module
filter
whatever
it
is,
is
broken
and
the
reference
doesn't
work.
C
That
one
seems
less
of
an
issue
because
they
they
deployed
something
that
was
insecure
and
let's
say
they
like
fell
asleep
and
then
realized
like.
There
was
the
time
where
everything
worked,
but
there
was
going
to
be
authentication
and
the
fact
that
they
were
panicking
and
applying
it
later
and
then
somehow
that
update
didn't
work.
It
doesn't
like
it
didn't
work.
It
didn't
work
anyway,.
A
Yeah
to
clarify
I'm
actually
I'm
arguing
for
breaking
things.
I
I
am
arguing
for
the
idea
that
you
you
would
not
want
to.
Let
things
continue
to
work
in
that
situation
and
and
instead
you
should
just
try
and
be
consistent
with
the
desired
state,
even
if
the
desired
state
is
invalid
and
then,
if
the
desired
state
is
invalid,
then
just
drop
the
route,
but
don't
try
to
do
anything
clever
view
on
that.
C
C
C
It's
an
interesting
thing
to
explore,
and
why
could
you
have
a
partial,
partially
working
thing
along
resource
values
actually
like?
If
you
discard
a
whole
route,
you
could
either
understand
that
and
work
with
it
and
be
okay
with
that
as
a
like
a
boundary
for
working
as
a
natural
one,
because
you
can
change
things
atomically
inside
of
the
motor
out
resource.
But
you
can't
do
it
across
multiple
resources.
A
No,
I
think
what
you're
describing
is
just
that
we'd
be
treating
the
route
as
a
failure
boundary
which,
which
seems
entirely
reasonable
to
me,
that
you
know
it's
one
reason
that
we,
you
can
have
so
many
routes
that,
if
you
screw
up
one
route,
the
rest
of
your
routes
will
continue
to
work.
D
C
Like
one
thing
that
you
could
say-
and
I
don't
know
how
confusing
this
would
be-
is
that
if
the
implementation
allows
for
preserving
the
old
state
as
long
as
possible,
like
you
could
say
that
they
made
enough
before
out
and
then
it
didn't
take
effect,
it
starts
spitting
out
conditions
saying
this
route
is
wrong.
I
kept
the
old
stuff,
but
this
is
like
indeterminate
right
now.
You
need
to
fix
it.
A
A
But,
but
I
think
you
know,
the
goal
for
right
now
is
just
making
sure
that
what
this
pr
commits
to
is
a
reasonable
starting
point
at
least
reasonable
enough
for
rc1.
And
I
I
think
the
consensus
that
I'm
hearing
is
that
this
probably
is
that
this
is
a
good
starting
point
and
if
we
need
to
adjust
it
we're
starting
from
kind
of
the
most
restrictive
option,
and
we
can
eventually
add
more
advanced
capabilities.
On
top
of
this.
If
we
need
to.
C
B
I
think
danian's
suggestion
of
there
being
some
sort
of
degraded
status
is
interesting
to
explore,
and
that
could
be
something
that
we
could
put
on
on
the
route
itself
in
the
in
the
route
status,
conditions
for
some
gateway.
B
Yes,
so
on
the
route,
so
so
the
problem
is:
is
that
on
the
gateway
we
have,
you
know
the
gateway
has
like
lots
of
routes
and
yeah,
it's
kind
of
syntactically
awkward,
there's
not
really
a
good
way,
a
good
syntax
to
say,
hey,
I'm
on
the
gateway
to
say
I
had
a
problem
with
a
specific
route.
There's
no
good
way
to
do
that
at
the
moment,
but
on
the
route
we
have
the
route
status,
which
is
status,
conditions
keyed
by
kid
by
their
parent
gateway.
B
So
we
could
put
that
on
the
route.
We
could
put
some
sort
of
degraded
condition
on
the
route
itself
and
then
you'd
be
able
to
list
routes
and
say:
oh
this
route,
you
know
route
a
is
degraded
on
gateway
b,
and
that
would
be
my
reason
there.
A
A
D
B
A
A
I
think
this
does
match
the
conditions
we
talked
about
before
in
the
vast
majority
of
you
know.
Discussion
we
had
today
is
is
what
I
think
is
is
important.
It's
about
what
we
do
when
something
becomes
invalid.
A
I'm
I'm
not
hearing
a
lot.
I'm
I'm
also
not
hearing
a
lot
of
anyone
calling
for
pause
on
this
and
I'm
and
I
would
be
fine
if
someone
wants
to
hold
off
on
this
and
wait
until
we
do
x,
y
and
z.
That's
fine!
A
D
A
A
A
Yeah
definitely
the
next
one
is
yeah
rc
one
just
just
to
get
a
feel
for
you
know
among
working
group
among
all
of
us
does
it
feel
reasonable
to
you
know
we
get
that
pr
in
and
tag
an
rc1
for
for
this
this
alpha
or
is
there
anything
else
that
feels
significant?
That
feels
like
we
should
try
and
squeeze
in
as
well.
E
A
I
forgot
that
one
hadn't
made
it
in
yet.
Thank
you.
I
think
this
is
super.
Super
close.
This
has
an
lgtm
and
just
looking
for
another
another
sandy
check.
I
guess.
A
Yeah
yeah,
yeah,
danian
or
or
james
or
or
bowie,
or
anyone.
If
you're
able
to
take
a
look
at
this.
I
think
I
think,
we're
probably
all
on
the
same
page:
okay,.
A
B
This
is
related
to
the
google
doc
that
you
posted
as
well
rob.
A
No,
no,
that
that
is
a
massive
massive
one.
This
good
question,
so
this
one
is
a
relatively
tiny
iteration.
A
A
A
But
that's
a
that's
a
great
segue!
Thank
you.
Let
me
let
me
get
into
this
one.
I
sorry
for
anyone
who
looked
at
this
pr
initially,
I
realized
like
an
hour
after
this
issue.
Sorry,
like
an
hour
after
I
created
this
issue,
that
my
second
link
that
was
supposed
to
link
to
the
dock,
linked
to
some
to
the
security
model,
which
was
not
helpful,
so
it
actually
links
the
doc.
Now.
A
Last
week
I
kind
of
tried
to
summarize
all
the
options
we
talked
about
as
a
working
group,
and
I
tried
to
get
some
feedback
from
other
sigs.
I
talked
to
antoine's
and
api
machinery,
mike
denise
from
auth
and
sod
from
storage
storage
being
relevant
because
of
storage
class
and
similar
restrictions.
That
they've
tried
to
implement
and,
of
course,
tim
because
he's
had
a
lot
of
feedback
and
did
not
like
the
initial
approach
that
I
proposed
here.
So
that's
that's
the
background
for
this
doc.
A
I
I
had
a
starting
point
here
and
then
expanded
further
based
on
feedback.
I
got
it
and
I
think,
there's
some
comments
that
have
been
added
since
I
released
this.
I
also
sent
this
out
for
anyone
who's
on
the
sig
network
mailing
list.
I
sent
it
out
on
sig
network
this
afternoon
as
well
just
to
try
and
broaden
the
net
and
get
as
much
feedback
as
we
possibly
can
it's
the
the
feedback
I've
gotten
so
far
is
generally.
A
This
is
a
common
problem.
We
are
not
the
only
ones
trying
to
solve
this,
but
there
is
not
an
amazing
solution
out
there
right
now
and
so
there's
interest
that
you
know
like
sod
and
sick
storage.
A
They
need
to
implement
something
very
similar
for
something
they're
working
on
and
so
they're
watching
this
closely
as
well
and
yeah
anyway,
that
that
is
the
background
here.
This
is
a
large
dock.
I
don't
know
that
we're
going
to
get
through
all
of
it
today
we'll
see,
but
I
I
outlined
five
different
approaches
here,
some
of
which
will
seem
very
familiar
to
everyone
here
and
some
will
be
somewhat
new
yeah.
A
So
with
that,
I
gave
a
little
bit
of
background
for
people
who
may
be
less
familiar
with
service
apis,
but
this
is
probably
all
fairly
familiar
to
us,
and
then
I
went
through
five
different
approaches,
and
I
you
know
one
is
one
we've
already
considered,
which
is
the
namespace
selector
or
list
option
another
one
is
kind
of
the
follow-up
that
mykaya
has
had
been
initially
suggested
and
been
working
through,
a
poc
of
which
would
be
to
find
a
way
to
use
our
back
with
this
storage
class
and
service
type
load.
A
This
is
not
something
we're
going
to
solve
at
least
not
yet-
and
you
know
you
can
solve
this
with
a
policy
agent
like
opa
and
gatekeeper,
so
that
those
are
the
the
various
approaches
I
have
outlined
here
feel
free
to
question.
Any
of
I
tried
to
give
like
a
really
high
level
summary
of
each
of
these
categories.
I
don't
know
how
meaningful
this
summary
is,
and
I
don't
know
how
accurate
my
attempts
at
summarizing
user
complexity
and
prior
art
are
but
definitely
add,
comments,
add
thoughts
whatever
this.
A
A
B
That's
sort
of
consistent
with
your
initial
research
that
multiple,
multiple
other
projects
need
something
similar
so
yeah
when
that,
when
you're
in
a
situation
where
multiple
projects
need
sort
of
one
thing
and
then
one
of
them
goes
out
and
trailblazers
that
one
trailblazing
project
is
going
to
be
it's
going
to
get
burned
by
its
trailblazing
right,
because,
what's
yes,
it's
very
likely
to
happen
is
something
everyone's
going
to
look
at
that
one
project:
oh,
what
did
they
do
and
now
we
can
use
their
experience
to
do
quite
the
right
thing
or
something
common,
and
then
that
one
project
has
to
figure
out
how
to
transition
from
its
special
case
to
the
general
case,
yeah.
D
A
So
his
suggestion
is
to
find
some
other
component
wherever
possible
and
delegate
that
responsibility
there
and
he
he
mentions
opa
and
the
number.
You
know,
policy,
agent,
type
approach
and
a
number
of
other
potential
options,
like
you
know,
gateway
class
grant,
whatever
it
happens
to
be
so
that
that's
some
great
feedback
from
antoine
just
on
these
different
options
as
a
whole,
but
with
that
I'll
get
into
the
ones
that
we're
most
familiar
with
our
current
implementation
is
one
a
which
is
a
namespace
selector
on
gateway
class.
A
We're
probably
reasonably
familiar
with
this,
and
we
looked
into
how
we
could
limit
the
enforcement
of
this
to
gateway
creation.
But
again
this
this,
you
know
we.
I
got
some
feedback
from
multiple
people
that
when
you,
when
you're
trying
to
do
something
like
this
and
the
feedback,
is
not
immediate
that
results
in
a
poor
user
experience
which
we
already
know,
and
it
suggests
that
maybe
you're
not
using
the
right
mechanism.
A
So
with
that
said
that
you
know
we
could
potentially
do
this
with
validating
webhook.
But
there's
lots
of
push
back
around
anything
with
a
validating
web
hook,
because
it
would
involve
cross
resource
validation
and
be
racy,
and
so
then
we
said,
oh
hey,
why
don't
we
do
this
whole
provision
gateway,
club
provision,
gateways,
tracking
and
gateway
class
status,
and
this
works
to
a
point,
but
may
still
may
not
be
quite
as
ideal
as
we'd.
Like
the
the
concern
raised.
I
think
this
was
from
tim.
A
If
I'm
remembering
conversations
correctly
is
that
there
really
could
be
use
cases
of
thousands
of
gateways
trying
to
use
the
same
gateway
class,
and
should
we
ever
run
into
that
this?
You
know
this
pattern
does
fall
apart.
So
yeah,
I
don't
know
how
common
they
are,
but
it
is
certainly
a
possibility.
A
I
I
tried,
you
know
a
simpler
variation
of
that,
which
would
be
using
a
pattern
that
we
have
already
for
the
gateway
route
relationship,
and
this
would
be
you
know,
kind
of
a
namespaces
field
with
allow-
and
you
know
the
same
kind
of
enum
here
and
potential
for
a
selector
as
an
option
that
may
or
may
not
be
simpler,
but
there's
a
second
part
of
this.
A
That
suggests
that
we
could
rely
on
gateway
status
instead
of
gateway
class
status,
which
you
know
I
I
had
initially
argued
against,
because
it
it
seemed
less
secure.
But
I
think
it
was
mike
from
sigoff
pointed
out
that
if
you
are
an
admin
and
namespace,
you
can
only
grant
access
to
permissions.
You
already
have
so
as
long
as
you
restrict
access
restrict
who
gets
the
ability
to
update
gateway
status.
A
It
could
still
be
relatively
secure
to
take
this
approach,
and
that
would
solve
that.
Last
problem
I
talked
about
with,
which
is
the
limitation
in
number
of
gateways
that
could
be
stored
in
a
single
list
and
gateway
gateway,
class
steps
and
the
last
one,
because
there's
been
a
whole
lot
of
conversation
in
the
community.
A
About
namespace
labels
and
namespace
selectors
and
how
we
want
to
move
forward,
and
so
this
is
the
the
exact
same
thing
as
above,
but
we
could
use
a
list
instead,
the
the
problem
with
a
list
is
obviously
it's
more
difficult
to
do
a
large
to
select
a
large
number
of
namespaces.
A
So
I
imagine
if
we
did
a
list,
we
would
probably
also
want
to
support
a
selector
yeah
anyways.
So
that's
a
summary
of
all
the
variations
of
that
first
approach.
That
is
most
similar
to
what
we
have
right
now,
any
any
comments
or
thoughts
on
on
this
section
of
approaches.
A
A
Yeah
yeah,
I
agree
with
that.
You
know
and
that's
I
I
tried
to
capture
this
with
with
saying
you
know
this
as
much
as
this
is
as
a
new
concept.
It
may
be
one
of
the
easier
ones
for
for
users
to
understand.
A
At
the
same
time,
it
is
potentially
more
work
than
most
the
rest
of
the
implementations
for
than
most
of
the
other
options
for
controller
implementations,
but
yeah.
This
is
a
simple
api
that
does
not
require
you
know
recreating
all
the
things,
but
at
the
same
time,
I
think
to
go
back
to
something
that
james
said.
A
If
we
do
take
an
approach
like
this,
we
risk
being
the
ones
that
that
tried
the
one
thing,
and
then
you
know,
storage
or
whoever
else
does
it
the
right
way.
Next
time
we
have
to
catch
up
to
them.
If
this
approach
doesn't
work
for
storage
or
whoever
else
crosses
the
same
pattern,
next
yeah,
I
don't
know
and
to
be-
if
it's
not
already
clear,
I
don't
have
a.
I
don't
have
a
final
answer
here.
A
This
is
more
just
meant
to
get
some
feedback
and
some
thoughts,
and
this
is
definitely
not
something
that
we'll
figure
out
before
rc
one.
I
just
yeah
wanted
to
write
everything
out
and
and
get
some
feedback
here
and
some
discussion
going
so
the
next
one
is
our
back.
We,
we
are
all
familiar
with
our
back.
That's
the
way
you
do
authorization
in
kubernetes
right.
I
I
think
one
of
the
things
I've
thought
about
this
more
as
I've
been
just
discussing
this
with
others.
A
I
I
came
back
to
this
idea
of
I
think-
and
I
know
I
I've
said
things
contradicting
this
in
the
past,
but
I
think
what
we
really
want
here
is
a
where,
instead
of
a
who,
I
I'm
very
open
to
feedback
on
this,
but
I
think
it
I
think
it
feels
more
natural
to
describe
where
a
gateway
class
can
be
used.
A
Then,
who
again?
Who
can
use
a
gateway
class
that
that's
my
idea?
I
don't
have
a
great
list
of
rationale
or
reasons
why.
I
think
that-
and
I
am
open
to
feedback
on
that,
but
our
back
of
course
does
feel
most
natural
when
it
is
tied
to
a
subject.
A
a
user
service
account
whatever
than
a
object
like
a
namespace.
B
Our
back
feels
like
good
for
things
like
maybe
automated
deployment
systems
or
those
sorts
of
things,
so
you
can
say
that
all
your
deployment
system
is
able
to
make
gateway
to
this
class.
But
normally
you
know,
other
users
are
maybe.
D
A
Yeah,
I
I
would
agree
with
that,
and
so
I
tried
to
lay
out.
This
is
heavily
borrowing
from
maikai's
original
proposal
here.
A
A
That
I,
that
did
not,
I
don't
know
it
didn't,
feel
very
natural
and
the
the
feedback
I
I
can't
remember
if
it
was
from
mike
or
tim
was
similar
that
it
just
it
didn't,
feel
quite
right
and
then
the
feedback
on
granting
rules
directly
to
subjects.
You
know
more
to
the
who
you
know
it
felt
like
the
appropriate
use
of
our
back,
but
it
didn't
feel
appropriate
for
this
use
case.
A
If
that
makes
sense-
and
I
tried
to
I
tried
to
copy
this-
is
a
some
feedback
I
got
from
mike
that
I
have
tried
to
add
here,
but
just
it,
the
idea
of
using
our
back
here
did
not
feel
like
a
good
idea.
A
Essentially,
you
know
this.
This
does
not
work
well
with
the
kubernetes
authorization
model,
and
although
we
have
used
the
use
verb
before,
notably
in
pod
security
policy,
they
ended
up
moving
away
from
it,
because
it
was
a
common
point
of
confusion
and
frustration.
A
So
the
the
feedback
I
got
here
from
mike
was
that,
although
this
technically
works,
it
may
set
us
up
for
more
problems
down
the
road,
more
user
confusion,
and
we
already
have
a
a
example
of
this
being
tried
and
moved
away
from
so
yeah
that
that
was
my
summary
on
our
back.
Does
anyone
have
any
additional
thoughts
or
any
feedback
on
these
different
approaches
here?.
F
A
No,
I
know
I
I
it
seems
to
depend
on
who
you're
talking
to
here.
As
far
as
how
much
of
an
issue
it
is,
I
know
I
got
some
pushback
from
jordan
when
I
had
it
explained
this
potential
approach,
just
that
you
know
anytime
you're
doing
cross
resource
validation.
A
You
would
you
would
run
into
this
kind
of
issue
where
you
have
the
potential
for
racy
outcomes,
but
you're
completely
correct
that
the
same
issue
seems
to
apply
to
our
back
and-
and
I
I'm
not
clear
what
the
difference
is,
but
that.
D
A
I've
had
a
similar
thought.
I
really
should
try
and
clarify
that
with
with
someone
else
as
well.
C
A
Yeah,
I
I
mean,
I
think,
you're
right,
I
I
think
you're
right.
I
think
I
need
to
to
push
back
on
on
that
and
and
pull
in
some
more
people
from
sigoth
just
to
to
understand
the
difference
between
how
this
is
implemented,
for
something
like
our
back
or
even
quota
or
any
other
kind
of
model
like
this
and
a
web
book.
A
C
Yeah,
although
I
mean
you
could
say
that's
a
non-issue
because
why
would
someone
do
that?
But
it's
like
the
the
most
reliable
one
most
likely
to
not
have
a
book
and
then
the
second
must
be
like
okay
and
then
utilizing
and
he's
like
that,
relies
only
on
a
very
specific
piece
of
state
and
then
it's
like
looking
at
multiple
resources,
so
it
does
introduce
more
reliability
issues.
D
A
A
Okay,
well,
I
know
you
know
that
we
we
are
not
through
and
we
will
not
get
through
this
today.
So
I
I
am
not
going
to
try
and
take
on
the
next
thing.
Yet
there's
there's
a
few
other
things
in
the
stock.
I
think
we
may
have
enough
time
to
to
follow
up
in
tomorrow's
meeting
here.
In
the
meantime,
if
you
have
time
to
to
take
a
look
at
this,
this
doc
add
any
comments
or
feedback.
A
That
would
be
highly
appreciated.
There's
a
lot
of
different
ideas
going
around.
I
I
personally
don't
see
a
single
front
runner
right
now,
but
I
yeah
I.
I
would
love
to
to
hear
what
everyone
else
thinks
yeah
with
with
that
said,
I
think
we're
we're
close
to
a
cut
for
rc
one.
A
I
will
try
and
get
that
out
today
if,
if
anyone
has
time
in
the
next
say
20
minutes,
you
know
immediately
after
this
meeting
to
take
one
final
look
at
this
pr,
please
do
and
we
can
try
and
get
any
you
know
any
adjustments
or
changes
in
otherwise
I'll
plan
on
pulling
this
one
in
and
and
cutting
a
release
candidate.
A
Cool
all
right,
we
are
at
time.
Thank
you,
everyone
for
great
feedback
today,
and
we
will
talk
to
everyone.