►
From YouTube: Service APIs Meeting (APAC Friendly Time) 20210621
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
A
Okay,
so
this
this
whole
proposal
comes
from
an
idea
that
james
said
a
couple
weeks
ago
that
that
we
could
have
a
that.
We
could
have
a
thing
that
would
that
was
an
extra
resource
that
would
that
would
help
us
control
across
native
space
references
and
who
can
who
can
create
them.
Sorry,
who
can
control,
like
which
persona
should
be
able
to
sort
of
control
the
the
use
of
resourcing
across
native
space
references.
A
So
one
of
the
things
I
was
trying
to
go
with
here
was
to
to
really
make
this
so
that
a
it
works
like
a
lot
of
other
existing
kubernetes
objects,
with
selections
and
b
to
sort
of
remove
the
language
that
we
currently
have
around
binding.
At
least
to
me.
I
feel
I
thought
the
binding
is
kind
of
an
operation
that
should
succeed,
whereas
I
think
that
it's
much
more
acceptable
for
a
selection
to
select
an
empty
set
than
it
is
for
an
object
to
fail
to
bind
an
object.
A
Failing
to
bind
is
an
error,
and
the
selection
of
an
empty
set
is
not
an
error.
So
that's
where
one
of
the
things
that
I
went
into
in
the
terminology
down
there
but
yeah.
A
So
the
in
terms
of
the
the
sort
of
broad
goals
is
you
we
want
to
have
it
so
that
whoever
owns
an
object
is
the
person
who
is
who
can
control,
whether
or
not
that
object
can
be
referenced
across
namespaces
and
also
whether
or
not
that
object
can
reference
across
namespaces
and
then
yeah
just
making
that
a
separate
resource.
A
So
I'm
not
100
on
the
name.
I've
you,
I
sort
of
went
backwards
and
forwards
on
a
few
things,
but
I
think
selection
policies
feels
like
the
best
option
to
me
right
now.
I
wanted
to
also
be
able
to
use
the
same
mechanism
for
for
that.
We
ended
up
the
prior
art
with
contours
tls
certificate
delegation,
which
allows
a
secret
to
control
the
owner
of
a
secret
to
control
where
it
can
be
referenced
in
other
things,
so
that
you
can
use
a
secret
that
you
don't
own.
C
A
Yeah
makaya
raises
the
point
that
yeah,
that
this
is
a
very
general
proposal.
As
I
worked
on
this
I
felt
like.
Maybe
something
like
this
would
be
would
be
useful
more
broadly
in
kubernetes,
but
I
didn't
want
to
go
too
far
too
fast.
I
wanted
to
get
everyone
here
to
have
read
over
it
before
before
I
yeah
talked
about
anything
so
yeah,
thanks
for
kai
for
jumping
ahead
a
little
bit.
A
A
Of
there's
a
bunch
of
little
details
that
are
really
important
there,
and
but,
but
I
want
to
have
a
look
at
the
examples
first
here
is:
you
know
this
is
sort
of
what
the
most
simple
one
I
can
think
of.
This
is
a
selection
policy
that
selects
http
routes
in
the
blog
namespace
and
allows
references
from
an
gateway
named
external
in
the
external
namespace.
A
Now
the
the
from
and
two
stanzas
have
yeah
I'll
show
you
the
structs
in
a
bit,
but
the
all
of
these
references
allow
reference
either
directly
by
name
or
by
a
selector,
and
so
in
the
case
of
the
from
two
ones.
They
are
a
very
general
reference,
so
they
allow
reference
by
name
and
namespace,
specifically
or
by
selector
on
either
of
those
things.
Obviously,
if
you
select,
if
you
have
a
selector,
and
you
also
specify
a
direct
reference
in
the
same
stanza,
then
the
director
will
win
the
now.
A
The
second
example
I
had
was
an
outbound
selection
policy
for
gateways.
This
would
be
like
a
guard
rails
for
people,
editing
the
gateway
to
make
sure
that
you
don't
make
a
typo
or
something
like
that
and
yeah.
This
one
in
this
case
this
is
the
inverse
of
the
previous
one.
So
this
is
the
this
allows
the
x,
the
gate,
the
external
gateway
in
the
external
namespace,
to
make
references
to
http
routes
in
the
blog
namespace.
A
So,
yes,
yes,
that
that's
the
no
that's
not
the
from
that's
the
the
like
owned
objects
of
this
of
this
selection
policy,
so
the
tricky
part
I
had
here
was-
and
I
think
you
can
see
it
more
in
one
of
these
ones
down
here.
No,
I
haven't
got
it
so
this
one.
A
Actually,
oh
sorry,
I
just
feel
like
I've
made
a
mistake,
yeah
so
there's
so
the
http
route
allows
is
allowing
routes
from
gateways
to
the
http
route
and
the
gateway
selection
policy
is
allowing
select
routes
from
the
gateway
to
the
http
route.
Now.
The
reason
why
I
didn't
just
make
these
the
same
is
that
this,
if
you
made
it
the
same,
then
you
could
kind
of
arbitrarily
select
anything
in
the
cluster
to
control
from
any
from
any
namespace.
A
By
having
this
object,
stanza
not
have
a
namespace
and
and
demand
that
you
select
things
in
the
local
namespace
that
helps
deliver.
The
sort
of
you
have
to
own
the
object
and
be
in
and
own
the
namespace,
where
the
object.
E
A
And
I
would
certainly
see
that,
in
the
case
of
say,
a
http
route
that
does
the
the
sort
of
delegation
or
inclusion
thing
that
we've
talked
about.
A
A
So
I
don't,
I
can't
remember
if
that's
a
union
or
intersection
or
some
combination,
so
the
idea
being
that
you
can
yeah,
you
can
specify
multiple
selection
policies,
for
you
know
a
single
object
and
that
that
they
will
all
apply.
A
Yeah
exactly
I
don't
see
any
other
way
to
do
that
with
a
cid
that
could
apply
to
the
same
thing,
multiple
times
yeah,
unless
we
sort
of
had
some
sort
of
conflict
resolution
behavior.
But
that
puts
you
in
a
different
problem.
Space
steve
asked
a
couple.
Stifloka
asked
a
couple
of
good
questions
that
I
realized
I
hadn't
addressed.
Is
this
enabled
by
default
for
same
namespace
references?
A
If
you
wish
to
create
a
cross
namespace
reference,
then
you
must
have
a
selection
policy
at
the
destination
at
the
roof.
The
referent
end
that
allows
at
the
at
the
very
least
that
allows
it
I'm
not
100
sold
on
whether
or
not
we
need
to
have
an
outbound
one
and
an
inbound
one
or
just
an
inbound
one.
I
kind
of
feel
like
just
an
inbound
one
as
like
a
requirement
for
making
a
crosstalk's
first.
A
A
Example
exactly
that
that
was
one
of
definitely
one
of
my
definitely
one
of
my
goals
is
that
you
shouldn't
need.
This
is
an
advanced
use
case
object.
You
shouldn't
need
anything
to
do
basic
stuff
agreed.
D
Do
we
see
that
as
something
that
may
be
needed
or
not,
or
is
it
implicitly
assumed
that
the
type
is
sufficient
to
kind
of
have
the
user
narrow
that
down?
I
know
that
we
only
have
like
very
few
kinds
of
referencing
yet,
but
this
is
like
pretty
generic
and
it's
not
attached
to
the
specific
field
which
it
is
today
in
the
spec.
A
I
did
have
a
bit
of
a
think
about
that,
but
I
couldn't
really
see
too
many
use
cases
for
saying
you
know
like
you
can
refer
to
it
with
listeners,
but
not
with
anything
else
or
something
like
that
like
once,
you
select
a
client,
you
I
feel
like
that's,
probably
enough,
I'm
happy
to
be
corrected.
There.
D
So
it
would
be
interesting
to
see
like
because
this
is
a
little
bit
subtle.
I
guess
even
in
just
future
versions
of
the
api
like
if
someone
adds
something
that
references,
another
thing,
would
we
run
into
any
problems?
Would
it
be
obvious
that
you'd
have
to
deal
with
this
in
some
way.
A
So
I
mean
that
that's
sort
of
the
general
position
I
mean,
maybe
maybe
we
might,
if
we
did
do
the
the
other
types
of
policy
objects
that
that
martin
robert
talking
about
then
maybe
we
might
not
want
to
have
these,
but
I
don't
know-
maybe
maybe
it's
useful-
to
have
the
selection
policy
for
the
policy
references
as
well
to
say:
well,
this
policy
can
only
be
referenced
by
these
namespaces
or
something.
G
D
Yeah,
I
think
this
works
right
now,
but
if
it,
if
it's.
G
Some
confusion
because
references,
they
just
mean
a
lot
of
different
things.
Right,
like
a
listener,
referencing
to
a
route
is
kind
of
different
than
like
a
policy
referencing
to
a
resource
to
apply
policy
to
it.
So
that's
kind
of
like
implied
here
in
just
like
what
kind
of
resource
is
referring
to
what
other
kind
of
resource
I
would
hate
to
make
it
more
complex
and
have
to
like
put
specific
field.
That
is
doing
the
reference
in
here,
because
that
would
just
I
feel
like
make
this
too
complex,
but
yeah.
D
Yeah
yeah,
maybe
it's
like
too
much
in
the
future,
I'm
just
thinking
this
is
I'm
trying
to
think
of
like
what
is
the
difference,
because
semantically
they're
very
much
the
same.
But
that
is
one
thing
that
is
different
between
the
two
proposals.
D
E
A
Yeah,
I
think
that
it's
probably
relevant
to
just
quickly
show
you
the
the
go
struct
for
this.
For
the
two
and
the
from
references
I
tried
to
be
again,
I
was
being
pretty
generic
with
the
names
here,
because
I
I
did
think
that
maybe
it
might
be
more
useful
in
things.
So
this
is
just
an
object
set
reference.
I
named
it
that
to
distinguish
it
from
a
standard
object,
reference
which
refers
to
things
by
the
typed
object
reference
which
refers
to
things
by
jvk,
plus
name
and
namespace.
A
In
our
case,
we've
got
gvk,
plus
name
plus
namespace,
plus
a
selector
for
the
objects
and
a
selector
for
the
namespace,
with
the
intent
there.
Being
that
you
can,
you
can
refer
to
things
either
by
name
and
namespace
directly
or
by
selector
for
one
or
the
other,
so
you
can
select
things
from
a
specific
namespace,
but
with
a
selector,
so
you
could
say
all
routes
with
you
know
app
equals
external
from
the
blog
namespace.
A
That's
that's
expressible
with
this
object
as
it
stands,
and
so
and
I
did
spend
a
lot
of
time,
thinking
about
the
sort
of
the
empty
and
null
behaviors.
So
because
I've
made
the
empty
and
the
null
behavior
different,
I'm
I
know
that's
like
not
great,
but
in
this
case
I
thought
it
was
really
relevant
so
that
you
can
make
the
the
the
way
the
fields
work.
A
If
you
have
the
empty
value
match
everything,
and
although
you
match
nothing,
then
it
means
that
you
can
then
the
the
object
works
as
like
a
increasing
discriminator,
as
bowie
said.
So.
The
more
thing
you
specify
here,
the
the
more
tightly
your
match.
You
match
a
specific
thing.
A
Yeah
the
og
label
selected
work,
so
actually
I'm
not
100
sure.
I
need
to
check
the
exact
behavior.
A
Yeah
yeah.
I
need
to
check
that
and
make
sure
that
it
is
the
same,
but
I
feel
like
this
is
definitely
like
the
most
usable
I
could
come
up
with,
because
then
that
means
that
you
can
do
stuff
like
it
might
be
reversed.
A
Is
it
okay?
If
it
is
then
yeah?
If
it's
if
it's
the
other
way,
then
it's
not
it's
not
the
end
of
the
world.
It
doesn't
really
matter
which
one
we
pick,
but
the
intent
being
that
you
want.
I
wanted
it
to
be
able
to
be
to
do
something
like
this,
where
this
is
actually
the
an
approximation
of
the
functionality
of
the
tls
certification,
so
it
selects
objects
of
that
are
secrets.
D
A
Asking
for
us
to
make
that
more
general.
It
was
more
just
that,
as
I
was
doing
this,
I
realized
that
the
controlling
that
that
object,
controls
how
you
can
reference
another
another
object,
and
so
I
was
like
well,
it's
the
same.
It's
the
same
problem
that
we're
dealing
with
with
controlling
how
a
gateway
can
reference
a
route
or
controlling
our
right
route
can
be
referenced
by
a
gate
by
gateway
as
well
or
how
a
route
can
you
know
reference
another
route
for
inclusion
and
so
yeah?
A
That
was
why
I
saw
the
football,
and
I
know
that
people
have
people
definitely
want
this
sort
of
feature
where
you
keep
the
you
know
for
tls
secrets,
people
want
a
feature
where
you
can
keep
the
secure
that
key
pair
for
your
main
company
website
in
a
place
where
not
many
people
have
access
to.
But
you
can
say
this
object
you
this
object
that
describes
the
ingress
that
is
on
that
site
needs
to
use
the
the
keypair
for
the
for
the
for
the
site.
F
D
It
feels
like
this
is
close
to
sort
of
like
that
simplicity
that
we
want.
We
just
need
to
probably
add
like
a
a
chunk,
not
large,
of
like
hey
and
in
the
future
if
we
needed
to
discriminate
it.
D
Perhaps
this
is
how
it
would
go,
because
basically,
this
is
like
pulling
out
the
policy
from
each
of
the
different
places
and
putting
in
one
place.
But
then
the
context
right
now
is
like
100,
clearer,
because
there's
just
only
one
place
that
the
resource
could
possibly
do
references,
but
in
the
future
you
could
conceivably
encounter
a
situation
where
the
fact
that
was
pulled
out
meant
that
we
lost
that
context.
A
Yeah
yeah,
that's
what
you're
saying,
and
I
don't
disagree.
As
I
said
the
point
of
this.
The
point
of
this
was
to
sort
of
raise
the
idea
and
seek
feedback.
So
I'm
not
saying
it's
finished
yeah,
so
I
think
like
he
did.
I
did
the
ghost
strucks
just
because
that
was
the
easiest
way
for
me
to
understand
how
this
is
right.
D
Yeah
this
is
not
a.
This
is
not
like.
I'm
not
it's
not
like
negative
on
the
proposal.
I'm
just
saying
that
we
should
discuss
it
just
to
understand
it,
and
then
it
seems
reasonable
that
that's
okay,
it's
it's
a
design
choice
like
could
someone
recycle
this
in
another
context?
Probably
not,
we
would
probably
say:
don't
do
that.
D
Could
there
be
multiple
contexts
in
which
you
want
different
policies?
Look
at
the
api.
I
don't
think
that
exists
today,
so
that
would
be
unique.
I
see
dave
has
or
david
has
this
yeah
yeah,
oh
man,
someone
use
all
capital
letters
and
then
like
okay,
so
kyverno
yeah.
We
also
have
to
discuss
how
this
interacts
with
like
super
complicated
policy
description.
I
guess
in
just
speaking
off
top
my
head,
like
you.
Probably
this
is
the
minimum
that
we
need
to
express
just
to
get
the
api
off
the
ground.
A
Yeah
agreed,
I
think,
john
john,
you
got
your
hand
up,
sorry
feel
free
to
go.
H
Yeah
one
thing
like
I've
been
trying
to
think
how
this
would
be
used
by
users
and
I'm
a
bit
confused
on
like
why
we
have
kind
of
like
this
mix
now
of
inline
references
and
the
separate
resource,
and
I
think
it's
really
confusing
because
now,
like
I
have
my
selector
and
it
says:
hey
select
route
view
equals
bar
and
then
suddenly
it's
not
selected,
and
I
have
no
idea
why,
and
I
guess
someone
set
up
a
selection
policy
and
now
I
actually
have
two
ways
to
configure
the
selection
and
I
need
to
make
sure
they're
both
in
sync
and
I
need
to
you
know
comprehend
both
of
them.
H
It
seems
fairly
complicated,
especially
when
it's
not
the
only
way
like
it
seems
like
we're
going
to
have
inline
selectors
like
we
have
today,
and
we
can
have
an
external
policy,
that's
kind
of
binding
routes
and
gateways
or
in
the
future
routes
and
policy
objects.
But
I
have
kind
of
this.
Hybrid
model
seems
like
it's
a
bit
confusing.
A
I
think
that's,
I
think,
that's
pretty
fair
yeah
as
I
went
backwards
and
forwards
on
whether
to
like
rationalize
a
bit
more
about
exactly
how
this
worked.
But
one
of
the
points
that
was,
I
feel
like
the
rough
rule
I
have
in
my
head
for
this-
is
that
that
the
the
gateway
api
currently
has
like
a
descending
security
context.
Right,
like
they're,
the
there's
like
an
infrastructure
operator.
A
I
don't
know
what
their
name
is,
but
there's
like
the
person
who
owns
the
cluster,
the
person
who
owns
the
can
the
the
gateway
class
and
then
the
person
who
runs
the
application
and
so
like
having
the
references
from
the
this
is
like
a
way
for
the
person
who's
lower
down
the
rrp
to
sort
of
push
back
on
the
person
who's
higher
up
to
some
extent,
I
think,
but
the
it
is
confusing.
D
I
have
a
question
so
for
sure
you
need
to
control
references
to
you.
This
one
also
controls
what
you
can
reference.
A
Seems
straightforward,
but
yes
you're
right,
you
can.
You
can
put
controls
around
yourself
to
say
you
and
I
see
that
being
being
listed
as
yeah
sort
of
being
being
used
as
guide
rails.
You
know
to
be
like.
D
To
me
towards
john's
point
is
because
is:
are
we
missing
because
I
guess
like
the
maybe
maybe
it's
just
a
renaming
like?
Maybe
it
should
be
called
reference
policy,
because
the
thing
that
we're
missing
right
now
is
a
way
to
say:
you're
referencing
me
and
no
no,
like
don't
do
that,
like
you
can't
reference
me,
but
your
selectors
going
out
is
already
like
fairly
clear.
I
guess
like
do.
We
need
another
policy
overlaid
on
top
of
that.
A
Yeah,
I
think
that's
a
fair
point.
You
probably
probably
don't
now
that
I
think
about
it.
I
was
probably
yeah
classical.
I
was
deep
in
the
thing
I'm
like.
Why
wouldn't
you
do
it
both
ways,
but
I
think
that
the
I
knew
that
both
of
those
points
are
fair,
that
of
the
it
probably
makes
sense
to
remove.
E
A
Actually,
initially
using
the
two,
because
it's
like
a
reference,
it's
a
reference
to
the
secret,
but
but
I
think
john
made
the
point
that
yeah
like
this
is
you.
It
should
be
that
the
secret
is
allowed
to
be
referred
from
name
spaces
and
so
you're
right
there
there's
no
real
reason
why
this
needs
a
two.
A
I
could
we
could
just
take
the
two
out
and
just
have
the
allowed
references
is
you
know,
inbound
references
only,
and
that
would
make
this
much
simpler
to
understand,
and
so
in
that
case,
in
that
case
john,
to
answer
your
earlier
question,
it
seems
like
the
rule
would
be
this.
This
is
like
a
yeah.
I
think
james
selected
suggested
to
me
out
of
band.
You
know
the
reference
policy
might
be
a
better
name,
I
think
that's
probably
good,
but
then
yeah.
This
is.
A
This
is
a
thing
to
control
what
before
and
the
owner
of
an
object
to
control
what
may
reference,
what
may
reference
them,
and
so
it's
a
reference
policy
and
it
says
for
these
objects
only
the
things
that
I
say
may
reference
them,
and
so
that
means
that
then,
the
the
difference
between
the
binding,
that's
the
thing,
that's
on
a
gateway
is
that
it's
selecting
objects
and
then
the
route
is
the
route.
Is
the
reference
policy
allows
you
to
remove
your
thing
from
selection.
A
I
A
A
A
D
So
when
you
install
by
default,
so
I'm
assuming
that,
if
you
don't
have
one
of
these,
then
the
selection
policy
is
same
name
space.
I
guess
implicitly,
yes,
okay
and
then,
if
you
let's
say
you
had
a
gateway
and
it
said
it
selected
all
namespaces
and
then
some
other
user
came
along
and
just
created
a
route.
So
then
that's
fine,
because
the
gateway
wouldn't
be
allowed
to
select
that
one
and
then
the
route
owner
would
have
to
create
explicitly
create
a
policy
in.
A
Definitely
and
so
yeah.
That
is
definitely
an
example
I
should
put.
I
should
put
in
there
to
say
this
is
the
this
is
how
we
see
the
flow
working
for
you,
for
that,
for
that
sort
of
use
case
is
that
you,
as
the
route
owner,
have
to
opt
into
being
included
into
it
into
a
gateway.
A
A
G
Hand,
consistency
which,
which
parts
of
the
existing
gateway
and
ralph
referencing
is
this
replacing?
Is
it
effectively
all
of
it
like?
There
are
no
more
references
in
the
gateway
and
the
route?
No.
A
The
gateway
will,
the
gateway
will
still
select
routes,
and
I
had
a
look
at
using
the
same
struct
that
I
use
here,
but
it
doesn't
work
because
it
has
the
I
I
need
to.
I
spent
a
little
bit
time
looking
at
it,
but
I
was
100
sure
I
wanted
to
get
people's
feedback
before
I
went
back
and
went
too
far
into
it.
What
I
think
we
should
do
is
if
we
decide
to
do
this.
A
We
re-evaluate
the
gateway
selection,
like
the
actual
stanza
that
we
use
for
selection,
because
I
think
some
of
the
stuff
about
you
know
same
name
space
and
all
that
sort
of
stuff
may
be
redundant
with
this.
But
it
depends
on
the
exact
behavior
we
define
here,
but
the
the
standard
that
we
have
on
the
routes
that
allows
it
to
select
a
gateway
is
redundant
once
we
have
this
and
we
should.
We
can
remove.
E
That
yeah,
I
think
that
that
one
is
like
exactly
this
right:
exactly
yeah
yeah
yeah.
A
So
it's,
I
think,
if
you
think
of
the,
if
you
think
of
the
things
as
a
hierarchy
with
the
gateway
sort
of
referring
to
the
routes,
and
in
the
case
that
we
do
do
inclusion,
then
routes
referring
to
routes
you
in
each
case
the
downward
one
is
a
selection
that
would
be.
That
is
a
stanza
inside
an
object,
but
the
upward
one
is
a
like
is:
is
this
select?
Is
this
reference
policy
that
would
allow
that
allows
the
the
downward
object
to
sort
of
say?
No,
I
don't
want
to
be.
A
And
so
in
places
where
we
have
other
things
like
that,
we
can
also
use
this,
and
one
thing
I
didn't
have
time
to
put
in
here
was
that
there
we
you
we
could
have
it
be
that
new.
I
mean
one
thing
that
I
did
consider
originally
was
violating
that
a
little
bit
and
making
it
be
that
your
gateway
classes
could
choose,
could
have
some
method
to
say
that
only
certain
gateways
could
be
there.
But
I
think
that
in
this
way
it
would
actually
be
less
confusing,
rather
than
using
this.
A
D
Yeah,
I
think,
like
I
mean
you,
could
have
a
clusters
reference
policy,
yeah
thingy,
to
address
that
one,
the
yeah
we
ran
it.
We
we
would
run
into
the
same,
like
we
just
said:
oh
opa,
dot,
dot,
dot.
A
Yeah-
and
so
I
mean
like
one
of
the
things
I
like
about
this-
is
it
allows
you
to
get
you
know
if,
if
we
mandate
that
controllers
do
this,
then
it
allow
it
gives
you
like
a
fair
chunk
of
the
functionality
that
you
would
want
from
a
gatekeeper
instead
of
gatekeeper
templates
for
the
gateway
api,
but,
like
mandates,
is
part
of
the
thing.
D
Like
you
know,
it's
like,
oh,
it's
possible,
have
fun
kind
of
design
where
the
user's
just
left,
with
like
okay,
then
like
what's
next
yeah
versus
this,
which
seems
to
be
more
aligned
with
ux.
A
Yeah,
and
so
the
thing
that
I
like
about
this
is
that
it
puts
the
you
it
sort
of
puts
the
control
across
namespace
references
solely
in
the
control
of
the
person
who
is
being
referenced.
The
referent,
and
I
think
that
that
has
been
a
that
has
been
a
general
problem
for
kubernetes
for
a
while
and
so
yeah
like
I'm,
not
gonna
lie
after
I've
been
thinking
about
this
for
a
while.
A
D
A
Yeah
so
this
I
mean
this,
this
allows
us
to
go
into.
This
allows
us
to
go
sort
of
and
spike
out
this
thing
and
then,
if
we
do
end
up
taking
it
to
your
machinery,
then
we
can
say
well
hey,
we
did
it
in
go
api
and
it
worked
like
this
yeah.
So
I
guess
I
feel,
like
we
sort
of
explained
a
fair
chunk
of
it.
Does
anyone
else
have
any
thoughts.
G
It
it
does
make
one
kind
of
common
use
case
a
little
bit
more
difficult,
so
where
you
send,
we
have
a
very
self-service
model
and
you
have
several
gateways
available,
like
shared
gateways
available
to
use
right,
and
so
this
is
good.
This
is
a
pattern,
that's
like
what
like
cloud
run
or
something
or
like
they
have
it
where
they
have
like
an
internal
one,
an
external
one
and
they're
both
available
to
use
like
in
that,
in
this
case,
it
would
require
both
the
like.
G
A
In
the
case
that
you're
talking
about
mark
like
one
of
the
things
that
I
wanted
to
and
the
reason
I
was
a
bit
picky
about
the
the
matching
behavior
was
that
I
wanted
you
to
be
able
to
create
a
you
know,
a
wide-open
selection
policy
that
says
like
any
route
in
this
namespace.
A
You
can
use
it
from
wherever
I
don't
care
yeah,
and
so
I
mean
I
agree
that
having
to
create
that
for
this
sort
of
really
base
like
relatively
basic
use,
case
kind
of
sucks,
but
the,
but
I
don't
see
any
other
way
unless
you
have
some
sort
of
bullying
in
the
gateway
which
then
makes
the
implementation
ridiculously
hard
to
understand.
G
Yeah,
I
don't
know
it
was
it
felt
like
some
of
the
early
feedback
was
that
if
there
was
no
nothing
on
the
route
that
indicated
which
gateway
it
would
match
with
that,
people
would
not
who,
if
whoever
is
deploying
the
route
would
not
have.
You
would
not
assume
that
you
know
they
would
be
bound
with
a
gateway
or.
A
D
A
I
mean
one
of
the
good
things
about
the
all:
about
having
routes
be
able
to
choose
any
gateway
is
that
it
means
that
you
can
really.
You
can
move
gateways
around
really
easily,
like
you
can
provision
a
new
gateway
check,
that
route
sort
of
showed
up
on
the
new
gateway
and
then
de-provisioned
the
old
one
at
an
infrastructure
level
without
the
owners
really
knowing
or
caring.
A
I
mean
there's
other
ways
to
do
that
when
you're
selecting
them
as
well
but
but
like
that
would
be.
The
thing
that
I
would
want
is
if
you're
gonna
turn
through
gateways
a
lot
for
some
reason.
Then
then
that
would
be
a
really
a
nice
way
for
the
professionals
not
to
have
to
care
too
much.
A
Are
there
risks
to
that?
Aside
from
that
absolutely
yeah
in
the
same
way
that
yeah
there
is
for
any
of
this
stuff.
C
D
G
A
It
is
an
advantage,
and
the
the
other
thing
that
I
like
about
this
is
that
we
don't
have
to
mutate
the
route
type
again.
If
we
do
do,
if
we
do
inclusion
or
like
a
route
to
route
reference,
we
don't
have
to
have
then
a
special
another
special
stanza
in
there
to
say
to
control
the
you
know
to
control
whether
whether
routes
can
reference
can
be
referenced
by
other
routes.
You
have
a
again
in
the
route
to
route
case.
A
A
The
you
do,
and
do
you
even
reflect
this
stuff
in
status?
You
I
think,
it's
to
some
extent.
It
feels
reasonable
to
me
that
if
you
select
a
set
of
things
and
then
one
of
the
things
is
for
some
reason
not
eligible
you,
you
you,
as
the
selector
might
want
to
not
select
all
might
want
to
know
about
it,
but
the,
but
the
other
side
of
that
is
that
you
need.
We
need
to
control
that
really
carefully
to
make
sure
that
you
don't
end
up
with
like
spurious
references
to
all
sorts
of
shenanigans.
A
D
Yeah,
I
see
this
an
interesting
way
like
how
would
you
debug
this,
because
it's
kind
of
like
firewall
rules
like
let's
say
you
had
a
gateway
and
a
selected?
It
had
an
open
selector
and
then
everyone
had
like
deny
policies
like
clearly,
if
you
just
said:
okay
log,
every
single
deny
thing,
then
you'll
just
get
this
giant
list
of
everyone,
and
that
just
sounds
seems
pretty
overwhelming.
A
Yeah-
and
so
I'm
not
100
sure
about
that-
this-
that
definitely
needs
more
thought.
As
part
of
making
this
a
real
proposal,
there
needs
to
be
a
good
sort
of
walkthrough
of
the
flow
of
how
troubleshooting
this
will
work.
Yeah,
that
is
100
not
included
at
the
moment
by
design,
because
I,
just
until
the
details
are
nailed
down,
it
is
too
there's
too
many
things
to
think
about.
A
E
C
A
C
I
wonder
if
this
came
up
when
we're
talking
about
the
in
the
gateway
api.
The
way
a
route
can
refer
to
a
gateway,
I'm
wondering
for
the
migration
use
case.
It
seems
like
the
problem.
Is
you
let
the
user
reference
a
gateway
by
name,
whereas
really
you
want
to
allow
the
user
to
reference
by
a
label
so
that,
if
you
do
need
to
migrate
from
one
gateway
to
another,
you
just
add
the
label
you're
using
on
the
old
gateway
to
the
new
gateway?
A
So
the
the
route
selector
definitely
has
the
ability
to
do
that
right
now,
but
it's
not.
I
think
you
need
to
change
some
things
around
to
do
it
again.
The
reason
why
I
designed
this
object
set
reference,
although
I
guess
really
should
be
called
typed
objects
that
reference,
but
is
that
you
can
use
a
selector
for
either
name
the
object
themselves
or
namespace,
as
well
as
the
the
name
and
namespace
with
the
intent
being.
You
can
do
exactly
that,
but
it's
it's
then
kind
of
up
to
the
user.
A
D
A
D
Yeah
we
had
discussions
with
people
and
they
wanted
both
in
different
situations
like
some
people
wanted
to
be
able
to
audit
a
list
of
things
and
then,
of
course,
you
have
that
migration
use
case,
in
which
case
they
didn't
want
to
be
involved
and
they'll
just
use
a
label.
A
Yeah
exactly
so,
that
was
why
I
thought
it
was
it's
probably
better
to
to
allow
the
to
allow
this
specific
one,
and
you
know,
maybe
we
just
note
that
you
know
hey
if
you,
if
you
want
to
be
able
to
migrate
things,
having
having
this
be,
a
selector
is
probably
makes
makes
some
of
the
cases
easier.
I
C
G
We
yeah
we
actually
all
the
public
docs
right
now
yeah,
so
they
all
use
the
label
selector
and
at
least
amongst
our
users,
that
we
that's
what
we've
been
seeing
them
do
kind
of.
What's
in
the
dark
is
what
ends
up
being
the
example
that
everyone
does
anyways.
A
C
D
C
D
A
A
You
know
when,
when
you're
doing
the
reference,
when
you're
actually
calculating
the
references,
you
calculate
the
you
have
a
cache
of
all
of
the
of
the
you
know
the
poll,
these
policies,
whether
we
call
it
reference
policy
sure-
and
you
know
when
you
you,
when
you're
referring
to
an
object,
you
you
then
just
run
through
you,
you
go
through
your
cache
and
say:
does
anything
exclude
you
know,
does
any
does
any
reference
policy
exclude
that
reference
and
that
it
feels
like
it
has
been
reasonably
clean
to
implement
that
in
that
way,
I
think,
if
you
do
anything,
I
mean
I
in
in
my
ideal
world.
A
I
think
that
in
the
at
the
end
of
the
day,
we
would
have
this
done
by
api
server.
Right
like
this.
This
object
would
be
an
api
server
logging
to
be
a
core
object
and
it
would
control
any
cross
name
space
reference
between
any
two
objects,
and
in
that
case,
then
it
would
just
be
done
by
the
api
server
for
you
right,
like
yeah
or
something
like
that.
But.
F
A
But
they
like,
at
the
end
of
the
day,
I
think
it
comes
down
to
the
kubernetes-
has
a
like
a
namespace
based
security
model.
Right
like
it's,
not
you.
I
mean
yes
namespace
and
resource,
but
like
the
the
most
the
largest
surface
area,
that
most
people
see
for
like
access,
control
and
things
like
that
and
is
on
a
per
name
space
basis
and
so
having
something
that
that
helps
you
work
with
cross.
Namespace
references
seems
to
really
fit
well
with
that.
C
D
I
know
that
we
discussed
a
cute
cuddle
plug-in,
which
seems
like
probably
like
it
sounds
like
given
how
crd
support
is
going
probably
is
like
required
that,
like
like
for
debugging
of
these
accesses,
it
feels
like
it
would
have
to
live
in
that
plug-in
and
then
for
that
to
actually
be
successful.
It
has
to
be
that
all
implementations
kind
of
have
a
similar
behavior.
A
A
B
Well,
I
think
I
think
this
is
a
good
breakdown.
It's
definitely
an
interesting
concept,
as
mikaya
mentioned
earlier,
it's
applicable
beyond
gateway
api,
so
it'll
be
interesting
to
see
if
what
kind
of
feedback
you
get
from
from
what
is
it,
the
api
machinery
or
whatever
group
that
you
would
kind
of
take
this
to
to
get
greater
feedback.
B
Yeah,
I
think
what
I've
shared
with
you
and
what
we've
discussed
in
the
past
is
just
the
additional
crd
is
you
know
for
the
simple
use
cases,
maybe.
J
That's
yeah
and
that's.
A
That
was
why
I
wanted
to
make
it.
That
was
definitely
a
thing
I
was
thinking
about,
and
that
was
why
I
made
it
so
that,
for
the
simplest
use
case
for
the
for
the
you
know,
everything
in
the
same
name,
space
use
space.
You
do
not
need
to
touch
this,
and
I
think
that
should
be
really
strong
with
all
that.
For
the
you
know,
for
the
hello
world
use
case,
you
don't
need
to
use
this
object
at
all
and
as
long
as
everything
is
in
the
same
name
space,
then
by
default
everything
will
work.
A
A
Essentially,
you
select
the
objects
that
the
the
policy
applies
to
and
the
references
that
are
allowed
to
it
so
where
things
may
refer
to
it
from
and
can
I
get
any
thoughts
on
names
it
feels
like.
D
I
I
agree
with
you
yeah
and
yeah.
That
sounds
great
and
also
just
if
we
could
add
to
the
discussion
of
like
yeah.
We
understand
it's
removal
from
the
context,
but
that's
okay,
because
dot
dot,
yeah.
A
And
certain
discussion
of
the
happy
past.
A
Two
or
at
least
saying
I'm
specifically
not
discussing
how
exactly
how
the
troubleshooting
would
work
yet
because
we
need
to
get
more
of
the
design
done
or
something,
but
it
should
just
mention
that
we've
discussed
that
that
feels
like
everything
we've
discussed
so
far.
I
will
add
that,
to
the
meeting
notes
to
the
agenda
sort
of
add
this
sort
of
broad
feedback
immediately,
but
with
that
I
think
we
are
we're
three
minutes
over.
So
unless
anyone
else
has
anything.
E
Excellent,
oh.
A
And
so
bowie
feels
like
it
looks
like
your
gap.
Thing
is
almost
at
a
place
where
it's
ready
to
go
so
I'd.
Happy
habit
for
this
to
be.
You
know
one
of
the
first
ones
to
go
for
if
your
policy
pr
gets
merged.
D
Yeah
the
one
note
about
the
gap,
I
think
not
too
many
people
on
this
call
so
I'll
announce
it
again.
Next
time
is,
the
idea
is
for
it
to
just
kind
of
preserve
information,
because
I
know
that
updating
and
the
whole
workflow
with
git
is
like
quite
awful
for
feedback.
D
A
Yeah
yeah
and
so
yeah
before
we
can
before
we
say,
but
when
we
say
yes,
this
is
decided,
then
we
take
whatever's
in
this
dock
and
basically
turn
it
into
a
gap.
Yeah
yeah,
yeah,
okay,
yeah,
I'm
happy
for
this.
If
this
does
go
ahead,
then
I'm
happy
for
this
to
be
the
first
thing,
but
it
goes
through.
Okay,
cool
yeah,
okay,
everyone
thanks
very
much.
Thank
you
very
much
for
listening
this
proposal.
We
really
appreciate
your
time
and
I
will
talk
to
you
all
soon.