►
From YouTube: Gateway API Meeting (APAC Friendly Time) 20210524
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
Are
recording
this
is
may
24th,
2021
and
gateway
api
meeting
today
we're
talking
about
route
delegation
and
I'll
hand
it
over
to
steve
to
share
more.
B
Cool
all
right,
thanks,
rob
yeah,
so
I'm
hoping
to
just
be
able
to
facilitate.
I
guess
I'm
curious
what
other
folks
think
about
this.
So
I
work
on
contour
I
have
been
for
a
while,
so
I
can
help
give
a
perspective
as
to
how
contour
kind
of
look
to
address
this
problem
initially,
and
we
can
chat
about
sort
of
some
of
the
issues
that
came
out
of
how
contour
approached
it
from
from
users
yeah.
B
But
the
goal
here
is
to
come
up
with
a
way
to
have
routes
that
get
you
know
in
a
sense
delegated
and
that's
a
tough
word
to
use
because
it
has
different
meanings,
but
the
idea
is
to
have
you
know.
I
have
one
route
that
I
own
and
I
can
pass
another
piece
off
to
somebody
else
in
the
cluster,
and
that
means
that
the
the
part
that
gets
passed
off,
no
one
else
can
utilize
that
that
set
of
can,
I
guess,
conditions
are
badass.
B
What
contour
calls
it
but
set
of
route
match
criteria
right.
We
don't
want
to
be
specific
to
path
because
it
could
be
more
things
like
headers
and
different
things.
B
So
I
know
I
know.
John
howard
has
had
a
good
example
of
having
you
know:
iron,
slash
cats
right
just
to
be
very
simple,
and
then
someone
else
has
slash
dogs.
B
So
the
idea
is
that
you
know
if
someone
creates
slash,
slash
food
or
slash
dog
food
I'll,
make
this
a
little
bigger.
Then
you'd
never
have
a
collision.
You
never
have
to
go
with
the
logic
to
figure
out
who
wins,
because
because
we
have
some
other
mechanisms
in
place
to
help
manage
this
so
like
I
said
we
can
do
this
on
path.
Prefix.
B
B
B
So
I
guess
I'll
pause
here
for
a
second
do
folks,
I
guess
what
I
guess
I'm
leading
this,
but
where
do
y'all
want
to
go
from
here
in
terms
of
how
to
look
at
this,
I
have
the
what
contour
does
today
in
this
next
section
and
then
down
here,
I
pulled
out
some
of
the
solutions
that
folks
had
addressed
in
different
issues
that
we
could
also.
A
Discuss
I'm
interested,
maybe
maybe
first
we
can
go
through
what
contour
does.
I
think
that
would
help
give
some
context
on
what's
already
been
done,
and
maybe
anything
you've
learned
from
that
sure.
B
Sure
so
in
contour
we
initially
had
this
thing
called
ingress
route,
and
I
can
put
this
in
quotes
here.
Ingress
route
and
the
idea
of
ingress
route
was
that
it
was
to
solve
this
that
used
multi-team
kind
of
clusters
right
so
an
example
here
of
the
dogs
and
the
cats
right.
We
wanted
to
have
teams
self-manage
their
own
path,
prefixes
right.
So
if
I
give
the
the
dogs
team,
in
this
example
permission
to
go,
manage
slash
dogs,
no
one
else
in
the
cluster
can
manage
that
right.
B
They
can
fully
manage
that
that
path,
so
they
can
create
slash
dogs,
slash
you
know,
dog,
slash,
food,
slash,
dog,
slash
food,
slash
whatever,
because
they
have
permission
over
that.
If
anyone
else
in
the
cluster
would
would
try
and
take
that
path,
prefix
then
what
happens
is
is
contour
will
throw
an
error
and
say:
hey.
You
know
the
the
person
who's
trying
to
use,
it
doesn't
have
the
authority
and
it
kind
of
gets,
thrown
out
right
and
then
the
person
who
does
have
authority
will
still
still
route
traffic.
B
B
What
we
found,
though,
is
that
folks
want
a
map
on
more
than
just
path,
prefix
right
and
then
the
idea
of
delegating
a
header
or
delegating
a
dns
domain,
or
something
like
that
didn't
make
much
sense
right.
So
we
switched
the
idea
from
this
delegation
word
to
this
inclusion
word.
We
kind
of
flipped
it
over
around
the
other
way.
So
delegation
works
with
this
idea
that
you
have
a
child
route
and
that
child
route
gets
included
certain
things
right.
B
So
when
you
go
and
process
through
all
of
your
routes
in
the
in
the
dogs
and
cats
example,
I
can
tell
someone:
hey
the
the
routes
in
the
dog's.
Namespace
include
a
path
prefix
onto
every
route
into
that
namespace.
So
when
contour
goes
to
process
it
when
that
child
proxy
gets
processed,
it'll
take
its
conclusion.
So
in
that
example,
it'll
have
slash
dogs,
it'll,
get
appended
to
or
prepended
to
their
path,
and
they
can
go,
define
things
from
there
and
it
happens
with
headers
as
well.
So
what
you
end
up
with
this
idea?
B
Is
you
have
this
root
proxy,
which
is
where
you
define
your
your
domain
name
right,
so
there
can
only
be
one
root
proxy
for
a
domain
name
in
in
contour,
and
then
you
can
have
as
many
child
proxies
as
you
like
right.
So
each
child
is
either
does
not
specify
the
domain
name
or
it
has
this
inclusion
path
specified
across.
B
So
I
have
an
example
here.
I
guess
a
picture
would
have
been
better
and
I
probably
could
dig
one
up,
but
the
idea
here
is
that
this
is
my.
Let
me
push
this
down
a
little
bit
put
on
the
team
screen.
B
B
Now,
what
I've
done
is,
I
have
this
other
name:
space
called
child
now
in
the
child
name,
space,
I'm
defining
a
slash
right
and
what
happens
is
is
in
the
root.
I've
had
this
inclusion
mechanism,
so
I've
said:
hey
the
the
http
proxy
called
child
route,
which
matches
this
name
and
the
name
space
child
which
again
matches
they
get
the
conditions
blogged
and
the
conditions
in
in
contour
are
essentially
the
the
route
match
conditions.
B
So
when
this
goes
to
process
like
I
said,
it's
kind
of
like
an
include
and
c
or
something
where,
when
you
process
that
document
all
of
these
conditions
that
get
defined
here
that
are
included
will
get
stuck
onto
here.
So
essentially
any
request
to
slash
blog
will
map
to
this
resource
here
this
route,
because
of
how
this
inclusion
mechanism
happened
same
thing
here
with
slash
info.
So
if
I
define
slash
info
in
the
child,
it
actually
turns
out
to
be
slash
blog
info
again
because
of
that
inclusion
thing.
B
B
B
C
C
E
The
the
thing
that
we
changed
between
english
and
http
proxy
was
that
for
ingress
route
you
didn't
need
you
didn't,
have
this
like
pre-pending
behavior,
and
what
that
meant
was
that
the
ingress
route
sort
of
needed
to
know
where
it
was
going
to
be
included.
E
So
what
it
meant
was
that
you
know
for
for
this
child
http
proxy.
If
that
was
an
ingress
route,
all
of
the
past
in
that
would
actually
have
to
have
the
slash
blog
prefix
in
them,
and
if
that
didn't
match,
then
that
proxy,
then
that
ingress
rail
would
be
thrown
away.
The
reason
we
moved
to
this
one
is
that
this
makes
the
the
child
hp
proxy
composable,
so
you
can
import
it.
You
can
import
it
into
just
this
one
blog
or
you
can
import
it
in.
E
You
could
have
like
three
different
includes
and
imported
in
three
different
places
with
three
different
sets
of
conditions,
and
it
was
still
a
work,
and
that
includes
the
the
headers
and
all
that
sort
of
stuff.
C
One
question,
though,
the
what
is
the
request
look
like
going
out
to
the
service?
Is
it
stripped
down,
or
does
it
also.
E
End
up
with
slides
it
gets,
it
gets
the
full
path
yeah,
so
we
do
have
prefix
to
it.
Right,
though,
so
on
the
child
http
proxy,
for
the
service
for
each
of
these
routes,
you
can
put
a
prefix
rewrite
to
rewrite
the
stuff
that
you
get
back
to
back
to
slash.
If
that's
what
you
want
yeah
it's
a
service
too.
C
E
Yeah,
I
mean
again
it's
kind
of
intended
that
this
is
this
is
kind
of,
for
you
know
places
where
it's
kind
of
expected
that
people
will
that
there'll
be
some
level
of
person-to-person
communication,
not
just
by
that
api,
which
is
probably
yeah,
which
is
definitely
something
that
I
think
probably
could
use
some
improvement.
B
Are
you
so
you
guys
safe?
Do
you
have
any
yeah?
We
have
had
folks
do
this,
so
so
some
folks
have
done
like
blue
green
deployments
from
this,
so
you
could,
instead
of
swapping
out
the
services
down
here,
you
can
swap
out
where
things
get
included
to
that
was
sort
of
one
thing
and
then
another
thing
you
can
do
is
you
can
you
can
delegate
to
yourself
and
then
delegate
to
other
namespaces
as
well?
So
as
soon
as
this
child
has
has
permission?
B
In
this
example,
slash
blog,
you
know
they
could
then
delegate
off
or
include
off
to
another
namespace
for
another.
You
know
say
they
had
they
own.
This
team
owned
two
different
name
spaces,
one
for
blog
and
one
for
you
know
the
info
or
something
they
could
then
do
an
inclusion
from
themselves
to
another
namespace
that
they
own
to.
Then,
you
know,
keep
passing
off
that
their
own
permission
chain.
E
The
other,
the
other
thing
we
have
seen
used
is
for
the
for
cross
for
doing
the
cross
name,
space
secret.
Holding
so
say
you
create
a
root
hp
proxy
that
holds
the
master
tls
key
insert
for
this
with
the
secret
that
you
can
put
that
safely
off
into
one
into
sub
highly
restricted,
namespace
and
then
the
and
then
you
delegate
slash.
E
The
condition
is
just
slash
and
you
delegate
that
out
or
include
that
out
from
another
proxy
and
then
that
one
is
then
the
place
where
you
do
the
other
things
right.
So
you
can
build
a
bigger
hierarchy
and
that
that
then
lets
you
keep
the
secret
details,
secret
you're,
all
restricted
to
a
small
set
of
people
that
one
I
have
seen.
People
use
as
well.
A
E
It'd
be
end
up
being
a
whole
new
route.
I
guess
basically
it's
if
that,
if
that
fqdn
field
is
set
at
all,
no
that's
a
root
proxy,
and
if
you
define
a
subdomain,
then
then
you've
done
something
wrong
right.
Like
is
the
current
assumption,
not
not
to
say
we
couldn't
change
that,
but,
like
that's,
that's
how
it's
currently
designed
yeah.
G
And
so
so,
in
case
of
like
routing
conflicts
or
like
to
figure
out
what
is
like,
you
know,
use
the
user,
specify
slash
info
and
then
slash
blog
lives
and
another
resource
have
users
run
into
like
sort
of
figuring
out.
What
is
the
real
hierarchy
like
building
that
hierarchy
or
doing
debugging?
Has
that
been
a
problem
yet
or
not?
Really
yeah
yeah.
E
E
So
there's
two
parts
of
this
discussion
to
this
problem
number
one:
what
happens
when
two
bits
of
the
dag
tree
that
you,
because
it's
effectively
a
dag
that
you
build
of
different
of
the
includes
what
happens
if
two
of
them
are
the
same
or
they
conflict
yeah
and
then
the
other
thing
is:
how
do
you
tell
people
that
that
that
has
happened,
and
even
in
the
absence
of
any
problems?
How
do
you
tell
people
where
their
hp
proxy
has
been
included
and
with
what
prefixes
and
what's
and
what
conditions?
E
So
the
idea
there
was
to
just
do
some
stuff
in
status
like
have.
We
have
a
very
similar
construct
to
what
we
ended
up
with
with
listeners
for
gateway
where
the
listeners
sort
of
have
a
thing
in
there.
That
says
which
gateway
they
apply
to
the
my
idea
was
to
have
the
status.
E
Have
you
know
a
set
of
these
match
conditions
that
or
impose
conditions
with
a
thing
saying
this
is
where
the
this
is
the
domain
name
that
you've
been
included
under,
and
this
is
and
then
this
is
the
this
is
the
conditions
you've
got,
and
this
is
your
parent,
so
so
that
you
can
go
one
hop
up
and
then,
if
everybody,
if
everything
has
the
parent
thing,
then
you
can
use
that
to
build
a
tree
like
a
like.
You
do
with
owner
reference.
E
Probably
last
day,
okay
yeah,
okay
yeah,
but
so
it
is
built
so
that
it
can
handle
things
of
arbitrary
depth.
What
will
happen
if
you
try
and
there's
a
couple
of
things?
There
were
a
couple
of
nasty
things
that
came
from
that,
but
some
of
the
negative
effects
of
the
way
that
we've
designed
it
are.
We
can't
do
regex
matching
on
prefix,
because
when
you
do
otherwise,
when
you
include
you
can't
tell
which
ones
are
which
because
you'd
have
to
parse
the
rejects.
E
First,
you
can't
do
like,
and
even
globs
are
a
bit
dicey.
You
can
do
globs
where
it's
a
whole
path
segment,
but
you
can't
do
sub
like
subpass
segment,
vlog
clubs,
so
right
now
there
is
no.
You
can't
do
any
wild
card
matching
or
regex
matching
or
anything
like
that.
It's
all
exact
string
match
on
prefix
only
and
that's
because
it
interacts
really
weirdly
with
the
with
the
inclusion
mechanism.
E
Otherwise,
and
the
other
thing
that's
you,
can
you
run
into
weird
problems
about
when
you're
exactly
when
you
implement
it?
How
you
you?
Can
you
end
up
with
like
having
to
do
a
lot
of
parsing
walking
of
the
all
of
the
cube
objects
to
verify
that
everything
you
know
is
yeah
you
have
to?
You
basically
have
to
walk
the
tree
every
time
for
everything
until
you've
built
a
whole,
a
whole
bag
and
then
marked
everything,
that's
not
in
the
dag
as
orphaned,
yeah
and
yeah.
E
So
that's
the
other
thing
that
we
do.
Is
we
mark
yeah?
If
something,
if
something
is
not
a
root,
http
proxy
and
it's
not
included
by
anything,
then
it
gets
marked
as
orphaned
and
that
that
there
is
a
status
that
gets
set
to
say
you
know
your
thing
is
that
we
only
really
have
three
states
at
the
moment
we
do
have
some
conditions
and
stuff,
but
that's
the
sort
of
the
roll-up
states
are
valid
invalid
and
orphaned.
E
Valid
valid
effect
is
quite
close
to
what
we
ended
up
with
admitted,
where
it's
basically
like
this
is.
This
is
syntactically,
okay,
you
and
points
to
services
that
exist
and
all
that
sort
of
stuff,
but
it
doesn't.
We
don't
make
any
claims
about
ready
or
anything
like
that
as.
A
E
Yeah
you,
if
you
produce
a
set
of
conditions
on
on
a
sub
route
like
that
that
are
mutually
exclusionary,
then
we
just
then
we're
like
yeah,
hey,
that's
invalid
and
we've
worked
spend
some
time
working
on
there's
a
there's,
a
real,
it's
really
difficult
to
do
with
partial
validity.
E
We
throw
the
whole
thing
out
right,
so
it's
very
simple
to
implement,
but
it's
kind
of
a
sucky
user
experience,
because
if
someone
updates
and
we've
also
had
problems
where,
if
someone
goes
down
the
tree,
if
you
are
including
a
http
proxy
that
is
itself
invalid,
what
does
the
owning
one
do
right
like,
and
so
is
that
is
that
now
partially
invalid?
And
if
it's
partially
invalid,
does
it
get
thrown
out
like
how
far
up
does
the
invalidness
flow
right?
E
And
so
that's
the
other
thing
that
the
the
computing,
the
status
and
understanding
how
partial
validity
works
is
surprisingly
tricky
and
there
are
a
lot
of
weird
edge
cases,
and
so
you've
got
to
be
very.
You
have
very
clear
rules
which
we
didn't
have
at
the
start.
E
We've
sort
of
evolved
a
set
of
rules
that
kind
of
work,
but,
like
you,
need
to
have
very
clear
rules
about
what
what
errors
in
our
included
http
proxy
in
the
child
pressure
free
proxy
will
be
fatal
for
inclusion
and
what
won't
and
what
and
what
errors
are
sort
of
yeah
yeah
you
get
the
id.
E
Yeah,
the
way
that
contour
works
is
that
we
have
like
a
three-step
model,
there's
like
an
ingestion
step
where
you
take
kubernetes
objects
and
turn
them
into
a
data
model.
Then,
once
you
put
things
in
the
data
model,
then
the
data
model
is
mutated
into
envoy
conflict.
So
the
the
ingestion
step
mean
like
having
that
having
a
sort
of
the
the
sort
of
three-step
bit
means
that
we
can.
We
have
the
same
data
model
for
any
of
the
different
sort
of
kubernetes
objects.
E
We
support
so
whether
it's
ingress,
http
proxy
gateway
api,
all
of
them
get
you
get
sort
of
turned
into
this
intermediate
dag
because
it
is
a
dag
of
load,
balancer,
constructs
and
so
enter
into
the
intermediate
data
model,
and
then
the
change
from
that
data
model
to
envoy
is
a
completely
separate
operation.
I
mean
there's
some
leakage.
E
Obviously
there
usually
will
be,
but
you
know
we've
tried
hard
to
keep
your
sort
of
api
curtains
between
those
two
steps
to
stop
exactly
what
you're
talking
about
while
you're,
where
the
onboard
stuff
bleeds
out,
I
mean
for
hd
proxy.
There
absolutely
have
been
some
onboard
stuff
bleed
out
into
the
into
the
actual
api
around.
You
know
all
of
the
stuff
that
we
that
we
talked
about
it
for
gateway
api
has
been
really
hard.
E
Timeouts
retry,
behavior
health
checks
that
sort
of
stuff
like
you
know
the
proxyisms
have
cripped
in,
because
we
don't
intend
contour
to
ever
use
a
different
proxy
for
a
start
path.
H
No,
no,
I
think
I'm
I
was
on
meeting
before,
but
I
think
you
you
covered
the
thing
I
was
going
to
say.
C
Another,
the
stuff,
that's
in
the
middle-
that
one
has
to
be
a
very
simplified
set
of
features
like
anything.
That's
within
a
delegation
chain,
you
kind
of.
C
E
Yeah,
so
the
on
the
inclusion
stanza,
the
only
stuff
you
can
put
is
the
reference
to
the
object
and
the
set
of
conditions,
the
set
of
conditions,
the
actual
struct
that
implements
the
conditions
is
the
same
between
the
includes
and
the
routes.
So
it's
the
same
struct
the
same
thing.
E
So
it's
the
same
syntax,
but
you
can't,
but
on
routes
you
can
add
stuff
like
timeout
policy,
health
check
policy,
you
know
load
balancing
policy
that
sort
of
stuff,
but
you
can't
do
that
on
includes
right,
so
you
can't
enforce
a
load
balancing
policy
on
an
include
or
a
timeout
policy
on
it
right,
yeah,
but
there's
another
there's
other
ways
that
you
can
enforce
that
sort
of
stuff.
E
If
you
think
about
it,
the
the
the
dag
that's
built
here
is
not
actually
per
object.
It's
actually
sort
of
per
sub
part
of
the
object
right.
So
the
includes
is
like
a
pointer
to
another
object
and
the
routes
inside
any
particular
http
proxy
object
are
effectively
the
actual
thing
that
you're
implementing.
E
So
the
reason
we
called
it
an
include
is
functionally
what
you're
doing
is
you're
taking
the
route,
stands
up
out
of
the
child
http
proxy
and
dropping
it
into
the
root
one
right,
but
there's
a
little
bit
of
code
that
munches
the
conditions
for
you
and
stuff,
but
that's
effectively.
What
you
end
up
with
is
one
really
big
http
proxy,
that
has
a
whole
bunch
of
routes
with
different
with
conditions
that
have
sort
of
been
munged
a
little
bit
on
the
way,
but
so
there's
no.
E
It
doesn't
really
make
sense
in
that
model
to
the
the
conditions
on
the
include
are
actually
like
a
mutation
directive
for
when
you
include
the
the
child
http
proxy,
not
you're,
not
sort
of
terminal
things
in
themselves.
H
Yeah,
I
think
I
think
the
word
includes
is
a
purpose
because,
like
this,
isn't
these
aren't
routing
hops
like
you're,
not
you're,
not
describing
a
routing
graph
here?
What
what
you're
describing
is?
You
know,
configuration
fragments
and
that's,
I
think,
part
of
the
reason
why
you
know
that
includes
terminal
project
change
to
using
include
as
the
terminology
to
try
and
kind
of
emphasize
that
aspect.
I
I
was
just
gonna
comment:
I'm
I'm
a
product
manager
on
console
from
hashicorp,
so
not
contour,
but
we're
looking
at
some
of
the
same
issues
that
you've
brought
up
where
you
know,
like
a
net
ops
team
has
seen
where
app
dev
teams
try
to
create
policies
where
they
would
conflict
with
another
app
team,
and
so
something
like
this
prefix
addresses
that
also
where
they
wanted
to
find
some
things
at
you
know
that's
more
higher
level
of
administration.
I
If
you
will,
you
know,
net
ops
who
can
own
the
like
the
public
access
and
and
delegate
some
control
settings
to
an
app
dev
team,
and-
and
so
this
idea
of
having
you
know,
kind
of
a
parent-child
relationship
works
with
a
lot
of
the
scenarios
that
we've
seen
customers
running
into
and
needing.
E
Thanks
yeah,
I
think
the
thing
that,
as
steve
said
before,
one
of
the
big
limitations,
though,
is
that
the
hp
proxy
model
is
solely
dependent
on
people
to
do
the
initial.
The
the
who,
with
the
person
who
controls
the
the
parent
http
proxy,
has
the
responsibility
to
get
the
name
namespace
exactly
right.
We
didn't
put
any
facility
for
label
selection
or
anything
like
that
in
there,
but
partly
because
at
the
time
we
didn't
have
a
solution
for
what
we
would
do.
E
If
things
were
conflicting,
I
think
if
you
fix
the
conflicting
behavior
and
how
and
how
things
behave
when
they
conflict,
then
it's
much
easier
to
just
say:
okay,
yeah,
you
get
a
label
selection
stevie.
If
you
could
just
go
up
with
it
yeah
so
in
on
the
include.
Instead
of
having
a
name
and
namespace,
you
have
like
a
an
object
reference.
E
A
standard
kubernetes
object
reference
that
lets
you
do
a
gbk
or
or
just
name
sorry,
a
label
selector
rather
than
not:
okay,
but
a
label
selector
and
so
yeah,
and,
and
probably
you
would
end
up
with
a
similar
set
of
things
to
what
we
have
with
with
including
routes
from
gateways,
and
you
might
end
up
with
a
similar
bi-directional
thing.
E
B
B
We
have
had
users
suggest
that
maybe
like
a
first
in
wins
is
a
way
around
this.
So
instead
of
restricting
you
know
creating
these
at
first
and
having
to
pass
them
down.
That's
been
one
suggestion
from
folks.
I
just
you
know
like
I
got
there
first,
so
I
win
this
domain
and
I
can
then
configure
it,
but
we
haven't
had
a
good
solution
yet
other
than
that
to
work
that
out.
H
Yeah,
I
think
steve
brings
up
an
interesting
discussion
topic
here,
because
I
think
they,
the
security
model,
that
in
contour,
is
pretty
different
than
the
security
model
that
we've
been
thinking
about
in.
H
And
I
think
so
I'll
give
you
my
impression
of
the
contour
security
model,
and
people
can
can
correct
me.
So
basically,
you
can
think
of
being
creating
a
gateway
as
as
a
privileged
operation,
and
you
can
restrict
that
to
certain
namespaces
if
you
want
which
lets
you
like,
restrict
that
privileged
operation
to
you
know
particular
a
particular
role,
more
or
less,
but
then
privilege
kind
of
is
delegated
down
the
configuration
tree
right
so
you're
always
including
from
the
top
down.
H
So
you
always
have
this
idea
of
someone
at
the
root
of
the
hierarchy
is
more
privileged
and
then
includes
someone
lowered
down
and
that
and
effectively
that
privilege.
You
know
transfers
because
then
the
next
layer
of
the
tree
can
then
include
something
else.
Is
that
a
pretty
accurate
description.
E
E
Obviously,
this
is
like
not
a
two-dimensional
place
or
one
that's
multi-dimensional,
based
on
the
prefix
and
the
headers
you
set
and
a
little
but
yeah
but
like,
if
you
think
of
it
as
like
some
weird
multi-dimensional
space,
then
you
can
like
take
a
chunk
of
it
and
give
it
to
people
and
then
they
they
are
free
to
do
the
same,
to
further
subdivide
that
space,
but
they
can't
expand
outwards
from
what
from
what
the
person
who
owns
the
the
whole
space
has
given
us,
and
so
that
works
poorly.
E
If
you
have
people
who
are
like,
I
just
want
the
people
who
are
lower
down
in
that
hierarchy
to
be
able
to
magically
request
the
domain
names
get
created.
So
that
is
one
we
had
a
lot
of
where
I
think
we
had.
The
issue
is
called
http
proxy
design,
encourages
bad
life
cycle
management
or
something
like.
J
E
And
it's
like,
basically,
the
person
is
saying:
look
because
you
because
you've
designed
it
in
the
way
you
have
the
owner
of
the
of
the
root
http
proxy
has
to
manually
go
in
and
mutate
the
root
hp
proxy.
If
you
ever
have
any
extra,
if
you
ever
want
to
add
any
extra
includes.
So
if
you
have
30
things
that
you
want
to
add
and
10
are
coming
and
going
every
hour,
then
there
are
that
many
edits
on
the
rotation
proxy,
because
there's
no
dynamic
way
to
select
things
that
are
outside.
E
So
I
think,
if
you
use
a
selector,
then
then
the
then
you
need
and
you've
solved
like
you've
got
a
solution
for
the
config
resolution
problem.
Then
yes,
but
then
you
can
do
it,
but
the
solution
for
the
for
conflict
resolution
and
bond
and
sort
of
including
the
http
proxies.
Well,
actually,
I
suspect,
look
a
lot
like
the
the
solution
for
including
rouse
from
gateways
and
then
the
due
directional
finding.
We
have
that
sorry
steve.
I
cut
you
off
no.
B
No
you're
you're,
fine
yeah,
I
was
just
gonna,
say
yeah
this.
This
eliminates
the
need
for
complex
resolution
because
there
aren't
ever
conflicts
because
of
how
it's
passed
down.
So
that's
that
which
side
you
want
to
live
on.
Do
you
want?
You
want
to
have
a
more
structured
approach
which
eliminates
conflicts
or
a
more
flexible
approach,
which
then
causes
you
to
think
about
how
to
how
to
deal
with
those
conflicts
when
they
arise.
H
F
F
I
do
like
that
provides
more
first
class
of
basically
encoding
ownership
of
parts
of
the
website
and,
like
we
looked
at
ways
of
doing
this,
with
domains
on
gateway
in
which
you
would
just
basically
do
the
matching
per
listener
right,
and
so
you
could
use
the
listeners
as
a
way
to
effectively
have
domain
ownership.
But
it's
it
it's
a
bit
clutchy
and
it
only
is
subject
to
the
domain
itself
and
no
other
parts
of
the
header.
So
that
is
a
nice
aspect
of
it.
F
I
do
wonder
we
talked
about
kind
of
policy
and
you
know
having
the
policy
and
configuration
flow
down
the
ownership
of
it
flow
down
the
same
way.
I
am
interested
to
see
how
this
would
mix
with
some
of
the
service
policy
things
that
we
were
talking
about,
because
we,
we
could
add
a
similar
idea
of
attaching.
You
know
the
ability
to
touch
policy
at
the
gateway
at
the
route
at
the
service
and
allowing
overrides
be
configurable
from
the
top
down.
F
J
Or
multiple
levels
of
the
route
yeah,
so,
as
I
said
earlier,
I
think
the
policy.
E
Stuff,
the
way
that
contour
ended
up
doing
it
is
there
is
a
there's
effectively
only
really
two
levels
of
policy
that
you
can
do
number
one:
the
global
controller's,
config
file
policy
level.
E
So
we
allow
setting
of
like
some
timeout
policies
that
are
then
the
defaults
for
for
everything
that's
created,
and
then
you
can
set
policy
at
the
like
that
at
the
actual
route
level
inside
any
one
http
proxy,
but
because
of
the
way
that
include
works
and
it's
like
a
it's
like
you,
take
the
config
and
you
put
it
into
the
the
conf
of
the
object,
one
layer
up,
possibly
mutating
it
a
little
bit
it.
E
Doesn't
you
can't
sort
of
put
the
policy
on
the
mutation
right
now
you
because
again
we
were
worried
there
about
conflict
and
conflict
resolution
and
how
you
would
handle
conflicting
policies
at
different
levels.
So,
right
now
we
don't
have
the
intermediate
policy
step
that
you're
sort
of
talking
about,
especially
in
your
back-end
policy
mark.
I
don't
think
that
it's
it.
E
It's
not
unsolvable
in
something
you
couldn't
add
to
this
design,
but
it
wasn't
something
we
did
along
the
way
we
didn't
find
that
we
found
that
people
only
wanted,
so
the
really
wanted
they
only
really
wanted,
like
the
two
levels
of
configurability,
but
the
thing
they
wanted
is
to
be
able
to
is
to
be
able
to
override
and
do
set
limits
around
policies
again.
Timeout
policy
is
the
best
example
of
this.
E
We
originally
had
a
thing
that
would
let
you
set
a
default
client,
timeout,
client,
request,
timeout
and
then
in
your
http
route,
you
can
set
a
client
request,
timeout
to
whatever
you
want.
What
we
found
was
that
people
who
are
operating
a
shared
proxy
sharing
controller
in
like
one
big
one,
big
english
controller,
for
an
entire
cluster.
That
is
a
multi-tenant
one.
Sometimes
an
application.
Developer's
best
interest
is
for
there
to
be
an
infinite
client
request,
timeout
right
because
that's
easiest
for
them.
E
They
don't
have
to
worry
about
client
request
timeout
anymore,
but
what
that
happens
then,
is
that
that
screws
over
the
cluster
admin,
because
then
the
proxy
never
has
connections
trained,
because
all
of
the
connections
for
that
thing
are
infinite.
Client
request
timeout.
So
if
that
client
goes
quiet,
then
it'll
never
be
rigged
and
you
won't
get
the
connection
space
back.
So
you
end
up
with
a
memory
link,
so
what
people?
E
What
people
requested
us
to
do
is
to
find
some
way
to
make
that
to
you
to
say
you
can
set
the
client
request
timeout
to
anything
between.
You
know,
zero
seconds
or
two,
which
means,
or
one
like
some
arbitrarily
small
value
and
some
high
value
in
you
know
five
minutes
or
something
like
that.
But
you
can't
set
infinite.
You
know
until
you
can,
you
can
rule
out
infinite.
You
can
set
a
bounded
value,
but
you
can't
rule
out.
You
can't
do
infinite.
That
was
really
tricky
to
make
work
with
the
in
controller
thing.
E
So
what
we
ended
up
recommending
is
that
we
wrote
a
set
of
gatekeeper
policies,
policy,
templates
and
policies,
and
we
say:
look
if
you
need
that
sort
of
functionality.
Here's
the
run,
gatekeeper,
here's
the
stuff
that
will
help
you
and
that
gatekeeper
is
better
at
that
sort
of
operation
than
we
could
ever
be
just
use
gatekeeper
and
that
that
stops
us
needing
to
build
a
poor
copy
of
gatekeeper.
To
do
that
sort
of
admission,
control,
stuff.
A
I
just
I
know
where
we
have
around
20
minutes
left,
I'm
wondering
steve.
You
had
a
few
potential
solutions
that
you
suggested
below
I'm
wondering
if
we
can
cover
some
of
those
as
well.
B
Yeah,
I
think
I
pulled
out
two
of
these
from
the
different
issues
and
one
I
think
one
I
just
editor.
I
think
it
was
referenced
by
someone
like
james
or
someone
might
have
brought
it
up,
but
so
the
first
one
was
having
a
route
forward
to
another
route.
So
the
idea
was,
you
know,
you're
forward
to,
instead
of
forwarding
to
a
service,
it
could
forward
to
another.
B
You
know
http
route,
and
that
would
give
you
a
way
to
to
to
give
you
that
cycle.
I
think
this
was
the
issue.
B
Yeah
that
described
that
so
the
same
kind
of
thing,
like
kind
of
like
the
delegation
mechanism
or
the
inclusion.
I
think
you,
instead
of
define
the
criteria
to
forward
you,
would
just
pass
off
to
the
to
the
other
route.
I
B
I
B
Very
cool
yeah,
I
think-
and
I
can
make
you
added
some
things
I
just
lost
my
yeah,
so
it's
what's
nice
about
this.
Is
this?
Would
let
us
we
don't
have
to
create
new
objects
or
or
change
anything
in
the
spec,
just
for
short
of
allowing
the
the
forward
two
to
happen
to
another
route?
B
But
you
know
some
things
where,
like
the
routing
cycles
can
be
hard
to
detect,
we've
got
to
make
sure
that
when
you
do
a
forward
that
the
protocols
and
everything
line
up,
so
we
can't
you
know
route
from
http
to
tcp
or
something
like
that,
and
then
some
some
route
fields
may
not
make
sense.
When
you
include
things
so
like
what,
if
you
had
another
host
name
defined
on
a
different
route
that
differed
from
the
from
the
parent
resource,
how
would
you
handle
those
sort
of
conflicts?
C
C
E
Yeah,
I
think
I
think
that
one
needs
a
needs,
a
good
status
design
where
you
name
space
the
status
by
by
like
inclusion
chain,
somehow
yeah
and
that's.
That
was
what
I
was
proposing
to
do
for
http
proxy-
that
there's
like
a
a
status
that
tells
you
here's
how
you've
been
included,
but
it
needs
to
be
name
spaced
by
you
know
top
level
domain
or
something
like
that
by
the
fqdn
or
something
I.
E
Gateway
is
the
obvious
sort
of
place
to
put
that,
and
then
you
you'd
say:
oh
you,
you
get
it.
You
are
eventually
included
by
this
gateway
and
here's
the
here's,
something
that
lets
you
break
from
the
the
thing
back
up
the
chain,
probably
one
layer,
I'd,
say:
yeah,
probably
one
layer
is
all
you
really
want
to
do
there.
You
don't
want
to
have
like
a
full.
E
You
don't
want
to
tell
people.
This
is
all
the
places
you've
been
included
in
that
gateway,
but
yeah.
Maybe
I
don't
know
you
need
to
try
that
out
and
check
I'd
say.
Yes,
I
think
I
think.
E
H
E
All
of
the
issues
in
this
come
down
to
you
know
the
benefit
is
that
you
don't
have
to
change
the
api
a
lot,
but
you
take
in
all
the
complexity
that
comes
from
not
changing
the
api,
a
lot
and
put
it
onto
controller
implements,
but
there's
a
lot
more
complexity
like
the
api.
The
api
is
you're,
taking
the
complexity
out
of
the
api
and
putting
it
into
the
controller
right
like,
and
so
the
implementation
guides
and
stuff
like
that
wouldn't
need
to
be
far
more
complicated
to
to
explain
to
people.
E
Here's
all
the
things
you've
got
to
handle
to
handle
this
use
case,
whereas
I
think
the
other
ones
may
may
help
with
that.
A
little
bit
you
gotta
have
concrete
resolution.
Behavior
design
defined
you've
got
to
be
like
how
do
you
find
routing
cycles,
like
here's,
some
tips
on
finding
routing
cycles?
Here's
some!
You
know,
here's
some
tips
on
how
you
handle
this
this
this
and
this
you
know,
and
would
you
mandate
some
of
that
stuff?
E
I
don't
think
right
now
we
have
a
behavior
like
a
way
to
mandate
in
controller
behavior.
That's
not,
you
know,
implement
these
structures
like
or
that's
not
based
on
that
api.
There's,
no
sort
of
you
must
do.
Your
controller
must
behave
in
this
way.
That's
not
based
on
a
particular
field
in
the.
H
I
think
the
complexity
with
this
approach
is
that
you
need
to
replicate
the
bidirectional
handshake
that
routes
and
gateways
have
otherwise
it's
trivial
to
kind
of
circumvent
that,
so
this
is
just
a
matter
of
their
the
additional
complexity
right.
We
already
have
complexity
concerns
around
that,
and
then
you
kind
of
replicate
that
complexity
down
into
come.
Some
arbitrary
hierarchy.
A
Yeah,
it
seems
like
you,
you
almost
need
some
kind
of
more
generic
parent
concept
than
right.
Now
we
we
assume
parent
is
gateway,
whereas
with
any
model
like
this,
we
parent
could
be
route,
it
could
be
another
gateway,
it
could
be
gateway
via
route
like
you
could
have
status
still
be
by
gateway,
and
you
could
have
some
kind
of
via
this
route.
As
an
example
yeah
that
it's
gonna
add
some
complexity,
I
think
any
way
we
do
this,
but
yeah
that's
interesting.
A
I
I
think
one
one
other
tiny
note
I
think
we'll
cover
this
with
with
other
approaches
here
is
what's
been
raised
earlier
is
the
idea
that
wording
matters
a
lot
and
if
we
clarify
that
this
isn't
another
hot
and
we
use
a
word
like
include
instead
of
forward.
I
think
that
can
help
with
understanding
what
this
is
and
we,
I
don't
think
any
of
us
want
this
to
be
another
network
hub.
I
I'd
say
one
one
thing
that
that
we
do
with
consoles:
we
have
a
concept
of
a
virtual
service,
and
so
you
could
target
a
virtual
service
which
then,
that
service,
that
virtual
service
has
routing
and
writing
rules
and
and
policies
apply
to
it,
which
then
get
applied.
So
it's
a
chain
if
you
will,
but
it
breaks
it
up
a
little
bit
more.
It's
just
a
different
way
of
breaking
this
up,
but
it
provides
the
final
kind
of
the
same
type
of
capabilities.
I
guess
I'd
say.
H
I
For
the
way
we
do
it
right
now
is
it's
it's
defined
in
console
as
a
dns
name
or
a
service
name.
You
know
in
our
service
catalog
going
forward
where
we
we
may
break
that
up,
and
so
that
there's
a
little
more
flexibility
in
that,
but
that
that
is
the
name
in
our
service
catalog.
So
it's
not
a
dns
name,
necessarily
visible.
E
Externally,
so
in
so
to
brutally
simplify
that
I'm
sure
I'm
this
is
entirely
wrong,
but
maybe
it
might
be
a
little
bit
right.
Is
it?
Is
it
a
little
bit
like
using
external
name
service
in
kubernetes,
like
where
you
point
it
to
a
name,
and
maybe
that
name
is
external
and
maybe
it's
not
and
and
there's
like
and
then
something
else
handles
the
console.
I
Yeah,
you've
got
your
listener
and
it
you
know
at
some
point:
it
resolves
down
to
sending
traffic
to
a
service
right,
and
so
what
we've
done
is
we
have
a
virtual
service,
so
you
can
have
you
can
chain
where
you
know
one
listener,
you
know
forwards.
Traffic
to
you,
know
virtual
service,
a
or
virtual
service
be
based
off
of
your
matching
criteria
and
then
virtual
service
a
may
target.
You
know
another
virtual
service
for
doing
some
additional
processing.
I
You
know
maybe
you're
doing
blue
green
deployments
and
you
know
or
canary,
where
you've
got.
I
need
to
do
some
things
different
with
my
traffic
manipulation.
My
header
manipulation
when
it's
going
to
the
new.
You
know
the
test
version
of
the
application
versus
going
to
the
standard
current
production
version
right,
so
you
can
just
as
the
decision
tree
is
gonna.
I
What
do
I
need
to
do
at
now
that
I've
been
sent
to
now
that,
as
virtual
servers
a
I
receive
this
traffic,
then
virtual
service
a1
who's
under
it
has
the
same
kind
of
logic
going
through
it?
What
do
I
need
to
do
now
that
I've
got
this
traffic.
I
B
The
next
thing
that
rob
sort
of
hinted
at
was
was
taking
this
and
having
a
new,
a
new
type,
a
new
struct
that
we
can
define
so
instead
of
routing
to
itself
over
and
over,
which
can
you
know,
cause
lots
of
issues
we
can
define
a
new
type
which
would
explicitly
define
hey.
This
is
these?
Are
things
that
you
can
delegate
include
pass
off
whatever?
Whatever
name
you
can
stick
in
there
to
make
it
make
clear?
So
this
way
you
can,
you
know,
define
like
so.
B
If
you're
gonna
pass
off,
you
know
a
path
or
a
set
of
headers.
You
know
we
can
restrict.
You
know
domain
name,
maybe-
and
maybe
you
know
subdomain
for
gabriel's
case-
would
work.
It
makes
it
very
clear
what
you're
doing
so.
You
don't
have
to
you,
know
infer,
what's
going
to
happen,
because
you
can
explicitly
say
hey
this.
This
is
a
delegated
route.
This
is
you
know.
B
This
is
the
behavior
that
we're
looking
for,
but
downsides
of
this
is
that
you
know
we're
going
to
duplicate
code
and
you're
going
to
have
to
have
lots
of
extra.
You
know
work
in
your
in
your
controllers.
In
in
the
api
spec
to
help
redefine
some
of
the
same
things
over
and
over
and
over.
E
Yeah,
I
think
that's
why
I
put
the
yeah
that
will
require
a
delegated
x
route,
because
that
pattern
really
strikes
me
as
really
similar
to
what
they
ended
up
with,
like
with
in
federation,
where
you
end
up
with
like
a
federated
object.
You
end
up
with
a
federated
version
of
the
object
and
a
regular
version
of
the
object,
and
so
we'd
end
up
with,
like
a
delegated
version
of
any
routes
that
support
delegation.
E
I
mean
again
that
comes
back
to
the
benefits
that
it
makes
clear
which
routes
support
delegation,
and
it
means
that
the
logic
to
support
the
delegation
is
in
the
definition
of
the
delegated
route.
But
so
I
don't
think
you'd
be
really
able
to
do
a
delegated
tcp
route,
for
example
that
wouldn't
really
make
sense,
but
a
delegated
http
route
for
sure.
Maybe
a
delegated
tls
route.
C
E
H
Go
to
sorry,
it
is,
is
it
the
gateway
has
routes,
so
you
go
from
gateway
to
delegated
route,
and
then
the
delegated
route
in
references
to
a
route
is
that
so
a
delegated
route
is
always
apparent
of
a
http
route
or
a
tier,
or
something
like
that.
Yes,.
C
E
Probably-
and
so
the
other
thing
that
I
see
here,
though,
the
way
that
I
would
say
this
is
that,
if
you
do,
if
you
have
this
intermediate
object,
then,
when
you're
building
the
the
inclusion,
dag
the
route
objects
are
the
leaf
nodes
and
the
the
gateway
object
is
the
root
node
and
any
intermediate
nodes
have
to
be
this
new.
E
G
E
We
haven't
had
so
the
only
the
only
other
request.
I've
heard
is
from
gabe
to
do
like
a
subdomain.
But
aside,
but
aside
from
those
three
things,
that's
all
we've
ever
been
asked
for
and
even
then
something.
H
E
Yeah,
you
absolutely
can,
but
I
think
that
what
gabe
is
asking
for
is
being
able
to
approach
me
from
wrong
is
to
be
able
to
have
one
place
where
you
do
example.com,
and
then
you
and
then
you
hand
out
response
like
exactly
like
dns
delegation.
You
hand
out
responsibility
for
some
sub
domain
of
that
upper
domain
to
some
other
team,
that
right
guy.
E
B
H
H
E
Yeah,
I
think,
regardless
of
exactly
where
this
ends
up
being
implemented.
It's
definitely
a
request,
like
a
use
case
that
we
have
been
requested.
So
you
know
so
it's
relevant
to
the
discussion.
You
know
you
whether
or
not
we
end
up
doing
it.
I
don't
know,
but
but
it's
definitely
relevant
as
a
use
case,
and
that
was
a
question
that
harry
was
asking.
I
think
in
terms
of
actual
examples
is
that
path.
Prefix
is
absolutely
the
most
used.
E
Headers
is
less
but
still
used,
and
you
know,
as
I
said,
we
haven't
seen
much
easier
because
we
don't
have
the
dns
domain
functionality,
but
you
know,
but
but
the
dns
domain
functionality
absolutely
is.
You
would
address
some
of
the
use
cases
that
we
have
had
that
we
haven't
been
able
to
do
to
handle.
G
So
the
reason
I
ask
that
is
this
seems
to
be
a
very
targeted
problem
to
a
very
specific
protocol,
because
that's
the
most
like,
I
think,
used
protocol
so
like
we
should
think
about
from
from
a
solution
perspective.
We
should
also
have
something
very
targeted
to
solve
this
specific
problem.
E
Yeah,
I
think
I
think,
that's
pretty
fair,
that
you
know
like.
Is
this
only
a
problem
for
hd
to
appear
out?
Is
it
a
fair
question
to
ask,
and
if
so,
do
we
then
just
make
special
stuff
for
http
route
and
not
make
it
more
general
for
the
rest
of
the
api
and
that's
a
very
fair
question
to
ask,
because
I
don't
think
because,
if
you're
so
the
only
the
only
way
that
that
I
would
see
that
not
being
the
case
is,
if
you're
doing
the
dns
domain,
subdomain
then
tls
route?
E
G
E
Yeah,
I
think
I
think
it's
I
think.
One
thing
that
I
probably
missed
out
of
that,
though,
is
that
you
know
there's
not
as
many
people
using
the
include
functionality,
but
the
people
who
do
they
really
really
desperately
need
it.
You
know
like
if
you,
if
you
have
a
complex
enough,
you
case
that
you
need
this
functionality
like
it's
very
it
can
be.
You
they'll
need
it
for
a
lot
of
things.
E
A
E
About
their
exact
setup,
you
know,
but
you
know,
but
my
get
my
my
gut
feeling
is
that
it's
mainly
why
that
people
aren't
going
10
includes
deep
right.
Like
yeah,
you.
E
Know
they're,
maybe
going
one
or
two
and
then
they're
having
a
lot
of
root.
Hp
proxies.
B
Yeah,
just
two
minutes
left,
I
know
the
last
one
here
was
was,
I
think,
similar
the
first
one,
but
just
limiting
what
can
be
forwarded
to
by
by
defining
the
a
terminal
section
or
a
terminal
spot.
Yes,
you
can
only
have
so
many
levels
right
right
so
somewhat
very
similar
to
the
first
one.
So.
E
Yeah
so
I
mean
for
me:
I
think
that
the
feedback
that
we've
got
from
people
is
that
they
really
like
being
able
to
use
the
include
functionality
in
http.
You
know
like
that
is
we
have
definitely
got
feedback
that
people
like
that
to
have
some
sort
of
include
functionality.
So
I
think
my
feeling
is
that's
having
something
that
would
let
you
do
something
like
that,
even
if
it
is
only
for
http
routes
would
be
really
useful.
E
I
think
it's
a
very
fair
point
that
harry
made
that
maybe
this
is
only
a
http
problem
and
we
should
not.
You
know
like
warp
the
whole
api
to
solve
a
problem.
That's
http
only
you
know,
but
you
I
think
that
it
certainly
is
worth
asking
like
if
you're
going
to
do
something
like
this
for
a
tls
route,
how
to
work
and
what
would
it
look
like
like
it's
going
to
be
a
domain
name
delegation?
E
That's
all
we
do
so
you
know
it's
very
relevant
to
us,
but
and
so
you
know,
I'm
always
going
to
have
stuff
so
yeah
and
I
think
sorry,
I
think
yeah
we
all
gotta
go,
but
we
absolutely
need
more
discussion
on
this,
but
at
least
this
way
you
know
I
can
sort
of
we
can
sort
of
say
well
we're
all
startles
from
the
same
place
to
some
extent
yeah,
and
so
I
think,
that's
yeah.
E
A
Yeah
yeah
thanks
everyone.
This
was
an
awesome
discussion,
thanks
steve
for
getting
everything
set
up
for
this
and
great
doc
and
great
discussion
and
we'll
talk
to
everyone
next
week.
Take
care.