►
From YouTube: Gateway API Meeting (APAC Friendly Time) 20210607
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
All
right,
we're
recording
this
is
june,
7,
2021
and
we've
got
lots
to
get
through
thanks
to
everyone
who
took
some
time
and
really
led
the
discussions
for
the
past
few
meetings.
A
I
don't
want
those
to
get
lost,
and
so
I
want
to
spend
a
little
bit
of
time
following
up
on
each
of
those
and
trying
to
understand
what
we
need
to
do
next
for
them
and
then
really
what
has
been,
I
think
most
obvious
to
me
is,
as
we've
spent
these
meetings
really
focusing
on
new
topics:
we've
developed
quite
a
backlog
of
issues
in
prs
that
have
gotten
neglected
and
haven't
had
any
meeting
time
to
really
discuss
them
properly.
A
This
is
in
no
particular
order,
but
I
did
want
to
make
sure
we
had
some
time
to
run
through
some
or
many
of
them.
If
you
have
one
on
this
list
or
don't
have
one
on
this
list,
and
you
want
to
move
it
higher
to
the
top
by
all
means.
This
was
really
just
a
random
assortment,
so,
as
always,
if
you
would
rather
something
get
covered
earlier,
just
move
it
up
the
agenda
yeah.
So
first
off,
I
am
looking
for
somebody
to
volunteer
to
lead
the
june
21
meeting.
A
That's
two
weeks
from
today,
I'm
going
to
be
out
of
office.
So
if
anyone
is
interested
in
leading
one
of
these
meetings,
there's
not
a
whole
lot
to
it,
but
just
leading
discussion
getting
an
agenda
together.
If
there's
not
already
one,
there,
no
pressure,
I
can
ask
again
next
week,
but
since
the
two
weeks
from
now
matches
up
with
this
specific
time
slot,
I
figured
I'd,
ask
here
first,
so
I'll
I'll,
throw
that
up
there
is
anyone
interested
in
taking
a
shot
at
this
two
weeks
from
today.
A
I
can
do
it
rob
sneak
awesome
thanks
nick
cool,
I
will
put
you
down
actually,
let's
just
add
it
not
sure
what
our
topic
will
be
yet,
but
we'll
get
there
so
cool
great.
Thank
you.
So
I
wanted
to
run
just
a
little
bit
through
previous
topics
and
next
steps.
So
first
off
we've
got
route
binding.
A
A
Maybe
that
has
an
impact
I
don't
know,
but
all
of
these
things
felt
like
they
were
all
leading
together
to
something
like
where
we
needed
to
take
a
step
back
and
try
to
understand
the
impact
each
of
them
would
have
like.
If,
if
we
really
wanted
all
of
these
concepts
to
come
together,
what
it
feels
like
they
all
affect
each
other
and
so
trying
to
solve
one
problem
without
keeping
in
mind
all
the
other
issues
or
goals.
We
have
here
felt
short-sighted.
A
So
I
I
think,
maybe
a
good
way
to
summarize
what
we've
discussed
so
far
is
route
should
have
an
easier
way
to
specify
the
gateways
they
want
to
bind
to.
So
there
there's
been
some
feedback
and
some
suggestions
that
as
a
route
owner,
you
want
to
choose
to
bind
to
a
specific
gateway,
and
that
is
relatively
complex
right
now
right
now,
our
model
is
very
much
gateway
to
route
and
so
potentially
providing
an
easier
path
to
flip.
A
Similarly,
a
route
should
be
able
to
forward
back
end
back
ends
and
other
name
spaces,
that's
one.
That
is
also,
I
think,
a
common
feature
request
here
and
very
related
to
route
should
be
able
to
include
routes
from
other
name
spaces,
because
if
we're
crossing
this
name
space
boundary
at
this
level,
we
we
need
to
be
very
aware
of
all
the
different
ways
it's
possible
and
ensure
we
have
include
appropriate
safeguards
at
each
of
these
levels.
A
So,
from
my
perspective,
all
all
of
these
concepts
are
closely
related,
and
finally,
the
last
thing
that
all
feels
like
it
fits
into
this
is
for
both
mesh
and
route
delegation
use
cases.
It
could
be
useful
to
have
a
more
generic
from
so
on
routes.
Right
now
we
have
route
stock
gateways
and
that
refers
to
the
level
up
in
this
deg
or
whatever.
A
You
want
to
call
it
right
in
this
graph
and
and
that
works,
but
as
we're
talking
about
well,
a
route
may
actually
be
included
by
a
route
so
that
the
thing
above
the
route
is
another
route
or
in
mesh.
What
you're
talking
about
is
the
route
may
be
referencing
a
workload
it
wants
to
apply
to,
but
the
the
thing
above
is
not
always
necessarily
gateway
and
maybe
there's
room
to
make
that
a
little
bit
more
generic.
A
Yeah,
so
these
are
my
thoughts
here,
I'm
interested
in.
If
anyone
else
has
been
trying.
You
know
thinking
through
this
trying
to
make
sense
of
how
all
these
different
ideas
jumbled
together,
I
started
just
some
scratch
thoughts
on
the
gateway
route,
binding
dock
at
the
bottom,
but
I
don't
have
anything
concrete
to
share
at
this
point.
It's
just.
A
This
is
something
that
I
feel
like
they're
all
related
and
in
my
mind
the
next
step
is
to
try
and
come
up
with
something
that's
a
little
bit
more
a
little
bit
broader
in
thought
than
just
any
individual
topic
here.
I
don't
know
anyone
have
thoughts
on
this.
B
I
have
a
thought,
so
one
one
thing
I
was
sort
of
thinking
about
was
trying
to
solve
this
with
yet
more
cids.
So
we
have
this.
We
have
this
problem
like
we're
trying
to
wedge.
You
know
security
model,
we're
trying
to
have
our
idea
of
a
security
model
and
I
think
the
things
we're
trying
to
solve
doesn't
fit
well
with
you
know
the
base
kubernetes
security
model,
so
we
have
gateways.
B
We
want
to
make
sure
the
gateways
don't
pull
anything
they're
not
supposed
to.
We
want
to
make
sure
that
resources,
people
who
own
resources
can
control
what
other
resources
pull
the
things
they
own
and
so
currently
we're
kind
of
putting
all
this
policy
into
the
into
the
core
apis.
B
But
maybe
that's
really
a
niche
user
case,
maybe
maybe
people
that
need
to
think
about
this.
You
know
serious
production
users,
which
you
know
who
are
going
to
think
through
the
issue,
we're
going
to
think
through
this,
and
maybe
we
don't
need
to
kind
of
push
this
complexity
onto
every
user.
B
So
I've
occurs
to
me
that
if
we
had
a
route
binding,
a
specific
route,
binding
cid
that
could
express
that.
Could
be
a
place
where
you
could
put
it
next
to
you,
could
put
in
the
namespace
next
to
the
resource
that
you
care
about
and
you'll
be
able
to
express
the
policy
that
you
wanted,
so
you
have
a
gateway
and
you
have
a
route
binding
policy
resource
next
to
your
gateway
and
that
rap
binding
policy
resource
would
say.
Okay,
this
gateway
is
only
allowed
to
bind
routes
from
these
particular
locations.
B
So
it's
not
in
your
face
the
whole
time
and
you
kind
of
have
a
lot
more
and
you
can
you
kind
of
have
one
one
crd,
which
kind
of
expresses
your
security
policy
and
independent
of
you
know
all
the
http
and
routing
and
application
level
things
which
you're
dealing
with
in
the
primary
crds
now
the
cost,
of
course,
is
okay.
It's
an
extra
crd
and
I
know
people
have
been
always
concerned
about
adding
extra
cids.
B
But
maybe
in
this
case
you
know,
the
cost
of
that
is
outweighed
by
the
benefit
of
moving
that
complexity
onto
a
onto
a
side
path.
A
Yeah,
that's
sorry.
I
got
my
unmute
shortcut
confused
with
me.
Yes,
anyways,
yeah,
that
I
really
like
that
idea.
I
I
want
to
sketch
it
out
or
or
if
you
had
more
concrete
thoughts,
if
you
want
to
sketch
it
out,
I
I
am
very
aware
that
any
of
the
route
delegation
or
route
binding
models,
we're
discussing,
add
significant
complexity
and
that
complexity
is
something
that
we're
talking
about.
A
Maybe
five
percent
of
users
really
taking
advantage
of,
maybe
maybe
less
I
who
am
I
to
say
the
percentage
of
users
that
will
use
a
feature.
Maybe
that's
something
we
can
sidebar
to.
I
think
it's
functionality
we
need
to
have,
but
if
it's
something
like
that,
we
say:
okay,
for
these
more
complex
use
cases
and
I'm
specifically
thinking
about
the
cross
namespace
binding.
A
I
don't
know
if
that's
where
you
were
going
with
that,
but
I
think
when
we
start
to
cross
those
namespace
boundaries,
that's
where
we
really
get
into
concerns
for
our
back
for
for
auth
in
general,.
B
A
B
I
think
I'd
be
okay
with
saying
like
okay,
the
default
is
the
ref.
Your
default
is
that
references
work.
You
know
based
on
your
controller,
whatever
your
controllers
are
back
is
so
if
your
controller
has
our
back
for
everything,
it'll
work,
but
then,
if
you
want
to
once
you
once
you
kind
of
start
locking
things
down,
then
you
then
you
add
policy.
It's.
I
think
the
thing
I
have
in
mind
is
actually
a
little
like
the
contour
tls
delegation,
cid.
C
Yeah,
so
so
to
for
those
of
you
who
haven't
heard
of
it,
I
was
about
to
say
the
same
thing:
contour
has
another
object,
called
tls
certificate
delegation.
What
that
does
is
if
you
refer
to
a
tls
certificate
using
a
namespace
and
the
hack
we
did
in
the
early
days
was
that
for
ingress.
You
could
just
refer
to
it
where
you
have
the
secret
name.
C
You
could
just
put
you
know,
namespace
slash
secret
name,
and
if
you
did
that
end,
then
contour
would
be
like.
Oh
that's
a
reference
in
another
namespace,
and
then
it
will
go
after
the
other
ministers
and
look
for
it
and
in
the
other
name
space.
There
also
needed
to
be
an
object
called
a
tls
certificate
delegation
that
was
a
separately
controlled
object
that
basically
just
had
a
thing
saying
the
tls
certificate
named.
C
You
know
there's
those
two
lists
that
gets
stored
in
the
secret
names,
whatever
may
be
used
by
namespaces
matching
this
spec,
and
so
that
was
like
that's
kind
of
the
opposite
way
that
you,
by
default,
you
can't
do
cross
namespace
things
and
you
can
opt
in
by
creating
this
thing
from
what
I
have
seen
about
like
other
folks
from
api
machinery
and
other
things,
I
feel
like
a
lot
of
the
security
related
people
and
the
api
machinery
related
people
are
very
reluctant
to
have
things
that
allow
you
to
cross
native
space
binder
boundaries
by
default.
C
I
think
that
almost
certainly
everyone
will
be
much
more
comfortable
if
the.
If
there
is
a
mess,
a
method
of
crossing
namespace
boundaries,
you
have
to
opt
into
it
and
that
you
know
it's
something
like
that
this.
C
If
you
wanted
to
have
a
separate
thing
to
do
that,
then
that
would
kind
of
make
sense
that
that
you
know
it
then,
because
then
the
person
who
owns
the
receiving
namespace
has
to
like
has
to
create
that
object,
and
that
means
that
you
can
are
back
those
objects
to
make
sure
that
only
people
who
should
be
allowed
to
should
be
allowed
to
create
the
reference
can
create
a
reference
as
well,
because
it's
a
separate
object,
and
that
is
so.
That's
the
the
the
this.
A
B
You
know
to
some
degree,
that's
a
quality
quality
of
implementation
issue.
So
by
default
you
would
you
might
say
that
you
fail
closed,
but
maybe
you
have
on
your
ingress
controller.
You
have
like
a
debug
or
development
flag
with
where
people
who
are
you,
know
running
a
liquid
kind
cluster
and
don't
want
to
deal
with
something
can
turn
that
on
and
say.
Well,
I
want
to
fail.
C
So
yeah,
I
think
that
sort
of
the
separate
binding
resource
thing
yeah
is
for
crossface.
References
covers
the
you
know,
referring
to
back
ends
in
other
namespaces,
the
referring
to
routes
and
other
namespaces
for
indicators
and
other
spaces
that
sort
of
thing,
but
it
doesn't
solve
the
problem
of
how
do
we
do
the
you
know?
How
do
we
specify
bindings?
C
Well,
as
in
it
doesn't
like
it,
doesn't
solve
the
problem
of
how
you
specify
it
like
you,
you
still
need
the
options
to
be
you,
don't
you
still
need
the
options
to
be
able
to
say?
Well,
you
want
to
select
all
things
by
selector
and
you
want
to
select.
You
know
things
that
are
in
a
list
of
namespaces
or
something
like
that,
like
you
still
want
to
be
able
to
do
that
right,
like
you,
don't
want
to
just
be
like.
C
B
Yeah
yeah,
you
want
to
be
able
to
specify
the
bunnings,
but
you
don't
need
about
it.
You
don't
need
to
have
the
bidirectional
handshake
anymore
right,
so
you
can
have
so
you
can
have
a
route
which
says
I
want
to
be
on
these
gateways,
which
is
one
way
of
finding
things,
and
you
can
also
have
a
gateway
which
says
I
want
these
routes,
which
is
a
separate
way
of
buying
things,
and
those
two
can
be
those
two
things
can
be
orthogonal.
You
don't
have
to
have
the
match
anymore.
A
B
C
Not
reducing
the
complexity,
then,
because
we're
adding
all
we're
doing
is
adding
another
layer
of
of
dual
directional
binding
right,
like
okay,
you're
still
going
to
have
dual
directional
binding,
because
you've
got
the
cross
product
of
being
able
to
refer
from
the
gateway
to
the
route
and
from
the
route
to
the
gateway.
And
now
you've
also
got
the
additional
cross
product
of
being
able
to
have
a
policy
from
the
referred
namespace
or
the
referring
namespace.
B
C
But
you've
still
got
to
think
about
the
cross
product
of
what
happens
when
you
use
all
of
them
right
like
because
some
people
are
going
to
some
people
are
going
to
say.
Well,
what
happens
when
I
do
you
know,
referring
from
the
namespace
I
had
a
namespace
b
is
like
you,
gateway
gateway,
a
gateway,
a
and
m
space.
A
refers
to
all
routes
in
name
space
b.
B
It's
added
because
what
this
is
exactly
the
case
that
we're
talking
about
the
question
is:
where
you
put
the
complexity,
do
you
put
that
directly
in
the
core
api
cids
and
express
it
in
every
place
where
things
can
be
found
or
things
can
be
referenced,
or
do
you
put
it
to
the
side
so
that
it
can
be
so
that
it
can
be
you
so
that
you
know
one
mechanism
can
be
used
in
multiple
contexts?
A
Yeah
and
I
I
think,
there's
a
path-
I
don't
want
to
get
stuck
too
long
on
this,
but
I
think
there's
a
path
where
a
binding
resource
is
like
like
what
we're
describing
here
is
something
that
allows
resources
to
describe
where
they
can
be
referenced
from.
A
So
we're
only
talking
about
one
side
of
that,
and
then
you
still
allow
that
selection
mechanism
from
gateway
to
select
whatever
and
if
it
can't,
if,
if
the
binding
resource
doesn't
doesn't
exist
in
a
namespace,
it's
trying
to
select.
We
have
the
same
issue,
but
at
least
we
have
created
a
generic
way
of
doing
that.
A
Instead
of
having
to
recreate
the
same
model
for
cross
name
space
references,
you
know
cross
namespace,
forwarding
across
namespace
inclusion,
all
these
different
things,
they're
very
similar
and-
and
I
think,
there's
some
value
there
in
a
generic
resource
that
can
communicate
that
yeah.
This
is
a
really
good
idea.
I
saw
a
couple
other
people
on
mute
momentarily.
Were
there
other
thoughts
on
on
this,
that
we
missed.
E
I
was
just
there's
a
couple
of
points
I
wanted
to
make,
and
one
was
that
you
know
the
the
use
case
with
the
permissions
and
such
could
be.
You
know,
in
some
cases
that
the
owner
of
the
gateway
is
only
going
to
approve
certain.
You
know
specific
routes
and
it
could.
E
It
could
be
in
the
other
case
where
it's
the
you
know,
this
owners
of
the
applications,
if
you
will
that
are
going
to
choose
which
gateways
they
bind
to
so
you
kind
of
have
to
support
both
models
and
I've
seen
both
I've
also
seen
where
the
the
distinction
is
between
namespaces.
E
E
That's
you
know
that's
kind
of
the
opposite
way.
We
should
be
doing
it.
A
Yeah
no,
I
agree
with
that.
That's
a
good
point,
we're
seeing
lots
of
different
use
cases
here
and
we're
trying
to
find
an
approach
that
can
be
as
generic
as
possible
to
support.
A
Well,
really,
all
of
those
use
cases
you
you
described
there,
while
also
still
being
simple
enough
to
work
for
the
simplest
same
namespace
use
kit.
You
know
you
know
we
don't
want
to
overly
complicate
the
same
name,
space
use
case
that
say
90
of
users-
maybe
maybe
it's
not
going
to
be
90
of
users,
but
a
chunk
of
users
end
up
using,
but
at
the
same
time
we
want
to
enable
all
those
advanced
use
cases.
A
C
F
C
Implementation,
it's
a
little
bit
like
what
we
have
now
in
contour.
Where,
for
the
http
proxy
thing,
you
can
specify
a
list
of
namespaces
that
can
have
the
the
root
http
proxy,
which
is
broadly
equivalent
to
gateway
for
some
things.
I
think
that
my
reading,
I
can't
remember
their
exact
discussions
about
it,
but
my
reading
was
always
hey.
C
G
That's
the
implementation
thing,
I
don't
think,
there's
any
rules,
I
mean
the
number
of
rules
we
put
around.
That
was
very
minimal.
A
Yeah,
I
I
think
my
thoughts
is
I
I
I
don't
think
we've
set
anything
in
the
spec
to
prevent
that
from
happening,
but
I
would
rather
provide
a
consistent
approach
that
works
across
all
implementations.
To
accomplish
that
and-
and
I
think
I
think
it's
possible.
B
C
C
Yeah
yeah
yeah,
so
I
mean
in
my
mind
in
my
mind.
The
way
that
you
do
you
handle
merging
gateways,
no
matter
where
they
are,
is
that
you
create
one
big
gateway
with
a
whole
bunch
of
listeners
and
a
whole
bunch
of
addresses,
and
as
long
as
there's
no
as
long
as
there's
no
conflicts
in
that
one
big
resource,
then
everything's,
fine,
so
conflict
resolution
behavior
is
important.
But,
aside
from
that,
it
doesn't
matter.
A
All
right:
well,
let
me
keep
on
going.
This
has
been
good
discussion
and
I
I
think
this
provides
a
really
good
follow-up
here
of
I
think
it
james.
It
may
have
been
your
idea
to
start
with,
but
yeah
a
really
good
idea
to
move
forward
with
this
on
the
on
the
other
proposals
here.
Are
there
other
follow-ups
that
we
should
be
working
on?
I
feel
like
this.
This
key
idea
of
policy
of
getting
binding
right
is
a
key
one,
but
are
there
other
areas,
we've
kind
of
gotten
stuck?
C
Before
we
move
on
one
of
the
things
I
just
wanted
to
say
was,
I
feel
like
this
is
this
feels
like
this
bonding
object,
we're
talking
about
feels
like
a
generic
generic
sort
of
reference
policy
object
and
because
and
that's
important,
because
it
actually
came
up
in
some
of
the
stuff
that
other
that
the
pr's
that
you
and
I
were
working
on
recently
rob
with
the
namespace,
the
host
name
selection
and
for
some
things
like.
C
If
we're
going
to
talk
about
it
like
this,
it's
actually
not
really
binding,
because
if
you
fail
a
binding,
that's
an
error.
If
you
fail
a
selection,
that's
not
an
error
right,
so
this
is
like
a
a
thing
that
influences
what's
what
what
references
just
are
valid
references
right.
So
it
means
that
from
a
route
you're
you
can
refer
to
another
route
or
to
a
service
or
something.
And
if
there's
this
binding
object
there.
C
That
just
means
that
it
can
put
the
route
in
or
out
of
the
list
of
valid
things,
that
of
things
that
are
selected
right
and
if
it
fails
selection.
Because
of
that,
that's
not
an
error.
That's
by
design
right
like
and,
and
that's
that
was
a
little
flip
that
I
needed
to
make
in
my
hand,
the
binding
is
actually
the
wrong
word
to
be
using
here,
because
binding
implies
that
it
should
succeed,
whereas
selection
does
not
imply
that
it
should
succeed
and
so
like.
A
Yeah
yeah,
that's
yeah,
okay,
good
call,
yeah
that
very
relevant.
Thank
you
for
tying
those
two
together
I'll
skip
over
gateway
class.
I
don't
see
damian
here,
but
he
had
a
good
presentation
in
doc
last
week
about.
If
there
were
ways
we
could
avoid,
or
at
least
make
gateway
class
optional.
A
That
was
a
good
discussion.
I
need
to
circle
back
and
actually
look
at
the
dock
again,
but
for
anyone
curious
it's
linked
up
here
and
it's
linked
in
the
the
previous
agenda
as
well.
A
What
I
want
I've
been
spending
a
lot
of
time,
thinking
about
policy
attachment
and
how
this
could
work
and
with
gke
and
gcp.
We
have
lots
of
different
potential
kinds
of
policy
we
might
want
to
attach,
and
some
of
that
is
represented
in
our
existing
backend
config
resource.
A
But
we
also
have
lots
more
that
we've
been
trying
to
make
sense
of
and
find
ways
that
we
could
attach
this
to
the
api,
but
we're
just
a
small
piece
of
this
puzzle
and
as
I'm
thinking
about
this,
I
was
curious.
If
other
implementations
here
have
been
thinking
about
kinds
of
policy,
they
may
want
to
attach
in
the
api
right
now
that
are
not
currently
supported
and
likely
don't
have
a
path
to
a
core
part
in
the
api
itself,
so
they're
not
portable
enough
that
they
could
be
within
the
api
I'm
just.
A
A
So
if
anyone
else
has
examples,
if
you
can
add
them
to
this
list,
if
you
can
what
whatever,
if
you
can
ping
me
or
in
the
main
slack
as
well,
whatever
works,
I'm
just
trying
to
get
a
broader
picture
of
what's
out
there
and
what's
what
we're
working
towards
so
that
we
can
find
some
kind
of
generic
policy
attachment
mechanism
that
that
works.
A
You
know
like
there's
somewhat
generic
concepts
of
retry
or
health
check
or
these
kinds
of
concepts,
but
I
know
there's
other
more
vendor
specific
policies
out
there
and
I
want
to
make
sure
that
we
can
provide
at
least
a
pattern
that
works
for
everyone.
So,
even
though
the
specific
policy
may
be
implementation,
specific
we're
attaching
it
in
the
same
way,
so
there's
consistency
among
implementations,
yeah.
I
don't
know
anyone
have
have
thought
much
about
this
already,
or
is
this
a
little
bit
too
far
out.
F
A
F
A
C
Yeah,
I
think
in
for
for
control,
we
had
the
same
thing
with
that
should
be
proxy.
We
have
a
number
of
policy
kind
of
things
that
are,
that
are
the
same
sort
of
thing,
you're
setting
some
config,
but
sometimes
you
want
the
config
to
flow
from
a
higher
level
thing
down
to
a
lower
level
thing
in
it.
So
it's
a
policy
in
my
mind.
C
That's
the
that's
the
thing
that
makes
it
a
policy
is
that
you
want
to
be
able
to
define
the
default
policy
at
a
higher
level
and
have
more
specific,
specific,
so
examples
of
that
are
load.
Balancer,
timeout,
retry
health
check,
all
the
stuff
that
harry
has
talked
about.
I
think
we
talked
before
about
how
the
timeout
one
is
like
one
of
the
hardest
ones
to
get
right,
because
everybody
does
that
differently,
and
so
I
think
timeout.
C
C
Sometimes
administrators
don't
want
app
developers
to
be
able
to
allow
infinite
client
request
timeout,
for
example,
but
also
then
you've
got
different
timeouts
that
may
be
implemented
by
different
data
paths,
and
you
know
some
people's
data
path
may
cover
this
much
of
a
timeout
and
then
other
people's
make
up
of
this
much
right
like
or
how
may
even
have
the
same
name
right
like
the,
and
so
I
think
timeout
policy
is
actually
one
of
the
best
ones
to
use
as
like
a
test
case,
because
because
it's
like
the
worst,
you
know
like
it's
got
like
the
least
amount
of
commonality
in
the
specific
details,
but
the
most
amount
of
common
commonality.
C
In
the
things
that
you
know,
everybody
wants
right
like
you,
everybody
wants
to
be
able
to
do
a
client
request.
Timeout
of
some
sort.
Everybody
wants
to
be
able
to
do
it
like
a
back
end,
timeout
for
proxies
and
stuff,
like
that,
you
know,
but
the
exact
details
are
almost
certainly
going
to
be
different,
so
you're
talking
about
the
same
thing
in
the
broad
strokes,
but
it's
not
the
same
thing
in
the
ways
that
matter.
C
You
know
the
yeah
and
load
balancer
policy
like
you
know,
round
robin's
weighted
list.
You
know
that
sort
of
how
do
you
bucket
your
connections,
all
that
stuff.
H
It
needs
to
be
able
to
attach
arbitrary
and
proprietary
policy
at
many
different
levels
right,
because
everyone
will
have
something
different
and
we
can't
anticipate
at
what
level
it
gets
attached
and
the
the
level
attachment
actually
plays
two
roles.
One
is
it
allows
an
implementer
to
attach
policy
at
you
know,
basically
any
resource.
You
know
any
part
of
the
resource
tree,
but
two
it
does
once.
If
you
add
that
in
an
override
ability
or
something
like
that,
then
you
now
have
a
trickle
down
policy
type
effect.
H
So
it
really
kind
of
plays
two
roles
in
in
yeah,
which
are
pretty
complimentary.
C
The
reason
I
said
earlier
that
the
thing
that
we
were
talking
about
earlier
was
relevant
is
that
if
we
want
to
be
able
to
have
this
sort
of,
you
can
attach
any
old
thing
policy.
Then
then,
basically,
because
these
are
kubernetes
api
objects.
You're
talking
about
needing
to
need
to
have
a
you
know,
a
object
reference
of
some
sort
which
is
going
to
include
like
a
gvk
or
gdr,
naming
them
in
a
namespace.
C
And
that
means
that
you,
the
problem
there,
is
that
everybody's
going
to
end
up
with
their
own
policy
objects
right.
But
if
you
have
a
mechanism
for
saying
like
not
only
do
you
need
to
do
gvk
or
gvr
then,
but
the
person
who
owns
the
policy
can
set
some
like
policy
policy
about
like
how
the
about
how
that
policy
should
be
used.
But
the
thing
is
that
is
then
a
selector
policy
right,
because
the
because
you're,
because,
where
you're
referring
to
a
policy,
you-
maybe
you
again.
C
This
is
the
exact
sort
of
thing
where,
if
you
just
have
a
name
and
namespace
like
you're,
probably
going
to
be
too
limiting,
because
people
may
want
to
say
like
I
want
to
have,
you
know:
10
different
policies
of
the
same
kind
that
you
that
the
controller
will
munch
right.
So
it
needs
to
have
the
same
mechanism
as
we
have
for
choosing
routes
or
gateways,
or
anything
like
that.
It
needs
to
have
this
like.
C
Basically,
this
again
is
the
same
sort
of
referred
like
the
same
sort
of
reference
that
we're
talking
about
for
for
gateways
for
routes.
For
that
bi-directional
mapping,
you
know
it's
the
same
mechanism
again,
you
know
you
need
to
be
able
to
have
a
solid.
You
need
to
be
able
to
have
same
name
space,
selector,
name
and
name
space
list
of
name
list
of
objects,
all
of
those
things
that
you're
going
to
need,
no
matter
what
you're
referring
to,
and
so
it
feels
to
me
like
if
we
can
solve
that
generic
problem
of
having
you.
C
This
is
how
the
gateway
api
does
references
and
to
other
objects,
and
then
that
means
that
means
that
you
can
just
use
that
for
for
the
policy
object,
you
can
use
that
for
route
objects.
You
can
use
that
for
gateway
objects
and
then-
and
you
know,
if
you
you
once
you
have
this
sort
of
falls
out
of
selection
behavior,
then
it
means
that
it'll
just
make
that
a
lot
easier
I
think
to
because
then
you
don't
need
to
have
policy
policy.
A
Yeah,
I
I
agree
with
that.
I
I
would
say
a
lot
of
what
we're
talking
about
for
policy
here
is
not
so
much
what
the
policy
includes,
but
like
you're
saying
how
how
it's
connected
and
and
that's
so
much
of
what
we're
struggling
with
in
this
api
is
how
we
connect
all
these
different
resources
in
a
way
that
makes
sense
in
a
way
that
users
can
understand
and
in
a
way
that
accomplishes
all
these
various
use
cases,
but
especially
for
policy.
When
we're
talking
about
you
know
and
crds.
A
We
want
a
consistent
way
to
do
that,
and-
and
let
me
let
me
transition
to
that
so
far,
I've
been
assuming
that
the
best
way
to
attach
policy
is
with
crs,
so
a
vendor
would
provide
their
own
cr,
crd
or
crds
that
describe
policy
that
they
support
and
that
could
be
attached
in
a
consistent
way
to
different
levels
of
this
api
alternatives
that
I
think
we've
considered
would
be
annotations
or
you
know
generic
map
string
inside
structs
inside
our
crs
themselves,
but
none
of
those
seem
great
and
and
until
inline
crds
become
a
thing.
A
It
seems
like
our
best
option
is
really
just
this
per
vendor
policy.
Crd
does
does
that
match
with
what
others
are
thinking
here
or
yeah.
C
For
me
it
does,
I
would
say
that,
as
part
of
this
api,
we
should
declare
like
a
a
general
shape
that
the
crds
need
to
be
able
to
fit
through
I'm
thinking
about.
Basically,
a
duct
typing
like
a
duck
typing
requirement
or
an
interface
requirement.
You
know,
like
your
your
policy.
C
Crd,
must
you
know
the
the
policy
cds
that
you
refer
to
must
have
a
status
that
has
the
follower
that
has
the
conditions
and
it
must
have
a
field
that
lets
you
do
this
and
it
must
have
a
field
that
lets
you
do
this
like
just
it
basically
just
outlines
the
general
shape,
and
then
you
can
say:
okay,
but
then
now
you
can
have
specific
stuff
under
this
bit
and
that's
all
up
to
you,
but
it
means
that
it
means
that
you
can
doctype
the
you
know
you
can
pull
the
configure
off
as
unstructured
and
then
duct
type
it
into
something
and
get
an
idea
about
what
it's
about
yeah
yeah
and
then
that
that
sort
of
you,
the
important
part
there
is
that
you
can,
if
you
require
like
a
specific
status
field
or
something
like
that,
you
can
use
that
to
say.
C
Is
this
relevant
to
me?
You
know
like?
Can
I
implement
this?
You
know
or
something
like
that,
yeah,
so
the
you
I
mean
you
can
do
that
with
the
kind.
Obviously,
but
there's
a
that
means
you
can
make
that
a
little
bit
more
generic.
You
know
like
if
you're
saying,
if
you
have
something
that's
like
policy,
describes
configuration
for
envoy,
then
anything
that
uses
envoy
as
data
plane
would
be
able
to
would
be
able
to
pick
up
that
policy
and
use
it.
C
Even
if
it's
not
your
policy
right,
like
yeah,
you
can
anticipate
that
it'll
probably
be
something
that
will
work
for
you
and
you
should
be
able
to
figure
it
out.
You
know
or
something
like
that,
like
you're,
just
having
just
basically
I'm
just
thinking
of
like
a
go
interface.
Definition
right,
like
you
know,
but
you
or
something
like
I
mean
a
little
bit
like
that.
It
also
mandates
some
fields
or
something.
A
That's
yeah
that
lines
up
exactly
with
what
I've
been
thinking
about,
which
was
at
a
enough
consistency
and
enough
of
a
guideline
here
where
we
could
make
a
cuddle
plug-in
that
could
understand
policy
from
any
vendor
and
represent
it
in
a
generic
way.
A
So
if
anyone
if
this
is
not
the
best
example,
but
if
anyone
is
familiar
with
debugging
css
back
in
the
day
and
and
running
through-
and
you
see
okay,
this,
this
specific
class
applies
here,
but
actually
there's
a
more
specific
style
definition,
and
so
this
this
little
thing
is
crossed
out
at
very,
very
helpful
and
and
if
we
can
make
our
policy
generic
and
that
well
consistent
enough
and
provide
a
well-specced
way
to
do
this,
then
I
think
you
can
use
the
same.
A
The
same
ux
to
understand
policy
that
has
been
applied
and
some
of
those
policies
may
be
core,
like
maybe
health
check,
is
that
example
of
a
policy
that
is
really
a
core
concept
that
is
broadly
supportable,
and
maybe
something
like
timeout
that
we've
already
established
is
unique.
Enough
that
does
not
you
know
is
something
that
is
is
always
going
to
be
vendor
specific.
But
at
least
that
way
you
can
have
the
same
experience
with
all
policy.
That's
attached
and
see.
Okay,
this
policy
plus
this
policy
are
attached.
A
These
are
just
goals
now,
but
I
just
I
wanted
to
have
this
conversation
to
better
guide
my
thoughts
here,
I'm
hoping
I
haven't.
I
haven't
put
this
together
yet,
but
I'm
hoping
one
of
the
next
two
day,
two
meetings
we
can
cover
policy
and
the
other
one
I
think
is
really
just
going
back
through
and
talking
about
connection,
maybe
it
maybe
it's,
this
route
gateway,
binding
plus.
You
know
that
cross
namespace
discussion
we're
having,
but
these
are.
A
These
are
the
topics
that
are
top
of
mind
for
me,
so
yeah
and-
and
with
that
I
know
I
I
mentioned
at
the
beginning-
that
we
are
struggling
to
find
enough
time
in
these
meetings
to
get
the
pr
and
issue
triage,
and
I
do
want
to
make
that
happen.
So
I
just
do
a
quick
run
through
a
lot
of
these,
I
think,
are
going
to
be
quick
and
easy
to
get
through.
A
A
If
not
I'll,
just
pull
this
one
in
oh,
I'm
not
signed
in
how
embarrassing
all
right,
let
me
I
will,
or
unless
someone
else
wants
to
add
an
final
lgtm
on
this
or
approve
on
this
one.
I
I
think
we're
fine
with
that
summary
of
out
of
tree
problems.
This
had
a
lot
of
discussion.
It
was
mostly
two
weeks
ago,
but
that
lined
up
with
a
meeting
day
where
we
didn't
really
have
much
time
to
discuss
this.
A
We
still
don't
have
a
lot
of
time
to
discuss
this,
but
this
is
really
just
trying
to
make
sense
of
where
we,
where
we
line
up
and
and
how
we
manage
crds
across
different
environments,
the
consensus
we
got
talking
with
api
machinery,
daniel
smith
and
some
others
was
that
this
is
really
the
future
of
kubernetes.
That
we
should
be
crds
are
not
perfect,
but
they
are
the
future,
and
this
is
this
is
what
we
should
be
doing.
I
know
we
talked
about.
Well,
maybe
we
could
go
in
free.
A
Maybe
we
could
do
these
other
things,
but
at
this
point
in
time
the
guidances
we
should
make
make
the
most
of
crds
and
help
make
the
path
easier
for
future
implementations
future
apis,
like
network
policy
folks,
are
following
the
same,
the
same
model
right,
and
so
there
will
be
many
others,
and
so
we
just
need
to
make
this
as
easy
as
possible,
well
as
easy
to
use
as
possible
and
provide
lots
of
feedback
to
api
machinery,
so
they
can
make
the
experience
better
going
forward.
A
F
A
That's
a
really
good
question
yeah,
so
so
we
added
them
here,
but
that's
probably
not
sufficient.
Let
one
of
us
it
can
be
you
or
or
if
you
don't
I'll,
follow
up
on
this
third,
but
I
I
think
if
you
ping,
daniel
or
antoine,
I
think
they're
the
most
involved
in
this
thread.
I
think
they
might
have
some
better
guidance
on.
A
F
A
C
I'd
also
be
hopeful
that
if
we
do
figure
out
something
with
that,
selectus
left
binding
thing
that
whatever
we
learn,
would
they
would
probably
be
pretty
interested
in
whatever
we
come
up
with.
They'd,
probably
be
pretty
interested
in
knowing
about.
A
Yes,
yeah
related
to
api
machinery.
It
has
come
out
that
we
really
should
be
moving
to
kxio.
I
already
had
some
decent
conversation
on
here,
but
kate's.
I
o,
as
an
api
group,
is
intended
to
represent
official
kubernetes
apis
that
are
headed
towards
some
form
of
stability.
A
I
think,
and-
and
I
kind
of
threw
this
in
here
at
this-
is
my
perspective
on
what
we're
hoping
to
accomplish
with
v1
alpha
2..
I
hope
this
matches
with
everyone
else's,
but,
from
my
perspective,
v1,
alpha
2
will
include
breaking
changes,
but
from
that
point
on,
at
the
very
least,
we
want
future
api
versions
to
be
fully
convertible,
so
you
can
go
back
and
forth
so
they
can
all
be
served
at
the
same
time,
and
ideally,
though,
not
guaranteed
no
breaking
changes.
A
A
So
that
makes
sense
to
me
with
that
said,
there's
an
earlier
slack
thread
that
anyone's
welcome
to
read
through
this
included
tim,
jordan,
antonio
and,
I
think
a
few
other
people
in
sig
network,
and
we
talked
about
it
a
bit
then,
and
then
I
followed
up
with
him
and
jordan
more
recently
and
it
does
sound
like
this
is
the
direction
we
should
be
going.
A
I
I
threw
out
a
few
different
names
here.
If
you,
if
you
feel
strongly
about
the
api
group,
we
try
to
move
to.
I
just
add
a
comment
here:
we're
also
trying
to
coordinate
with
the
network
policy
working
group
because
they're
really
trying
to
do
the
same
thing.
We
are
yeah.
That's
all
there
is
to
that,
but
just
a
heads
up
that
this
is
something
that
I
think
we
should
change
as
part
of
v1
alpha
2.
A
Cool,
let
me
keep
on
running
yeah.
We
just
have
all
kinds
of
api
machinery
things
today.
I
I
don't
my
kai,
you
are
on
this
call.
You
have
been
proven
right.
All
these
all
these
months
later.
Congratulations,
I,
I
think
correct
me
if
I'm
wrong,
but
I
think
you
are
the
one
who
suggested
that
we
use
resource
as
a
reference
instead
of
kind.
A
E
A
Yeah
and
it
it
does
seem
like
a
pr
relay
well,
a
very
related
pr.
I
think
he
was
involved
in
the
no.
Maybe
he
wasn't
involved
in
the
review
yeah.
He
was
so
anyways.
This
is
now
officially
as
of
12
days
ago,
or
maybe,
whenever
it
merged
yeah
12
days
ago,
officially,
guidance
now
that
object
references
should
use
resources
instead
of
kind.
A
A
Cool
just
a
heads
up-
this
is
a
this-
is
probably
a
pretty
easy
one
to
to
knock
out
if
anyone
wants
to
get
a
contribution
in
all
right.
Okay,
this
is
a
really
quick
one.
It's
hardly
worth
a
mention.
I
just
I'm
conformance
tests
have
the
least
exciting
thing
in
the
world,
but
they
are,
they
are
making
progress,
which
is
exciting.
I
I
have
started
a
separate
pr.
A
I
have
on
a
refresh
pr,
that's
a
516
that
works
and
uses
gateway,
api,
and
this
just
uses
standard
go
tests
and
it's
fine,
but
I
also
wanted
to
explore
something
that
was
similar
to
more
similar
to
ingress
controller
conformance,
which
meant
using
godog.
A
This
is
still
pretty
rough,
very
rough
yeah,
so
just
seeing
this
feedback
for
the
first
time
this
is.
This
is
really
meant
to
be
more
of
a
pr
to
say,
hey.
This
is
a
thing
that
is
being
worked
on,
but
there's
still
just
a
lot
to
do
here,
but
if
you,
if
you
want
to
look
at
it
high
level
and-
and
I
would
say,
there's
a
it-
it's
promising
is
what
I
would
say.
A
But
if
you,
if
you
have
strong
feelings,
what
I'm
trying
to
do
here
in
this
pr
is
show
both
how
standard
go
tests.
Look
alongside
go
dogs,
so
I'm
trying
to
reuse
as
much
code
as
possible
and
then
show
basically
the
two
options.
I
I've
been
hesitant
to
use
godog
because
I
think
it
adds
this
extra
layer
of
complexity
and
potential.
A
You
know
translation
and
debuggability
concerns,
but
I
wanted
to
give
it
a
fair
shake
and
the
way
I'm
doing
that
or
trying
to
do
that
is
just
children,
side
by
side
and
try
and
move
forward
with
whatever
makes
sense.
But
this
is
still
very
rough,
but
just
a
heads
up.
This
is
something
I'm
working
on.
C
A
Yeah,
so
the
the
general
pattern
in
all
of
these
is
similar
to
ingress
controller
conformance
in
the
sense
that
they
apply
some
manifests,
and
then
they
expect
a
certain
behavior
to
happen
so
right
now,
the
the
one
thing
these
tests
in
either
case
is
really
the
simplest
thing
to
test
it's
that
at
within
a
certain
period
of
time
a
condition
is
set
in
status.
A
That's
you
know
it,
but
ideally,
and
what
ingress
controller
conformance
already
does
is
it
makes
actual
http
requests
based
on
the
status
of
you
know,
ingress
status
sends
a
request
to
that
ip
etc.
A
So
that's
the
end
goal
here,
but
for
right
now
it's
just
testing
conformance.
The
way
that
I
ended
up
implementing
this
is
a
gateway
class
yaml.
Basically
it
it
in
these
tests
assume
that
you
have
a
gateway
class
called,
I
think,
gateway
conformance
in
your
cluster,
and
that
can
point
to
whatever
controller
you
want.
Whatever
params
you
want
and
all
the
tests
will
just
run
with
that
specific
class.
A
So
that
allows
you
to
provision
whatever
controller
implementation.
You
want
and
run
these
with.
That
said,
there's
there's
a
ton
of
work.
This
is
not
meant
to
be
a
final.
A
It's
just
meant
to
start
discussion
around
what
kinds
of
things
we
want
to
do
here
and
what
we
want
to
achieve,
and
and
if
there's
an
entirely
different
approach
that
someone
has
liked
for
conformance,
I'm
not
tied
to
any
either
of
these.
So
if
you
have
opinions,
this
is
a
great
time
to
to
get
them
in.
C
Yeah
yeah
thanks.
I
I
asked
because
you
know
we're
are
working
on
a
performance
suite
for
contour
as
well.
So
you
know
so
yeah
I'll
point
the
the
guys
who
are
working
on
that
at
this.
So
they
can
call
see
if
there's
any
cross-pollination,
we
can
do
there.
Yeah.
A
Yeah,
no,
I'm
interested
in
anything.
Do
you
know
what
what
technology
yeah
you're
using
right.
C
Now
I
think
we're
using
a
similar
sort
of
thing,
but
we're
not
using
we're
just
using
our
home
roll
thing,
okay
or
whatever
the
other
one
is
yeah,
okay,
one
of
the
other
frameworks
yeah.
So
I
think,
but
basically
the
I
think
the
guys
have
ended
up
writing
our
own
framework.
C
So
you
are
kind
of
income,
more
inclined
to
be
like
well,
if
we're
going
to
use
a
framework,
let's
use
one
that
someone
else
wrote
so
that
we
don't
have
to
do
all
the
work
but
yeah,
but
so
I've
been
yeah
they've
been
doing
their
thing
for
a
bit
and
I've
only
been
keeping
a
light
light
eye
on
it,
but
I'll
definitely
ping
them
with
this
and
see.
If
there's
some
cross-pollination,
we
can
do.
G
C
Would
guess
the
the
reason?
I
think
it's
a
really
good
idea
to
have
something
in
here?
That's
reasonably
standard!
Is
that
then
it's
a
good
way
for
controller
implementers
to
have
something
that
they
can
base
their
own
set
of
tests
off.
You
know
like
if
you
can
take
these
tests
and
then
like
add
another
set
of
tests,
that
test
your
implementation.
Specific
things,
that's
much
easier
than
needing
to
figure
out
how
to
build
the
list
grab
from
scratch.
Yeah
it's
hard
yeah.
A
For
sure
yeah
and
these
these
are
very
similar
in
scope
and
and
architecture
to
ingress
controller
conformance,
except
these
are
much
less
polished
so
but
we'll
get
there,
maybe
cool.
Let
me
we
really
don't
have
much
time
left,
yeah,
there's
there's
a
few
of
these
that
are
just
they.
They
feel
like
some
of
these
pr's
may
just
be
falling
off
or
or
need
just
another
ping.
So
let
me
follow
up
on
these.
After
the
meeting
I'll
just
ping,
the
prs
themselves.
C
A
Perfect
cool
and
for
next
topics
we
kind
of
already
discussed
this
I'll
see
how
things
go
for
me
this
week,
but
I
I
feel
like
these
are.
These
are
the
next
big
topics
in
my
mind,
it's
either
going
to
be
this
kind
of
follow-up
discussion
about
how
all
these
route
gateway
connections,
work
together
or
policy
attachment,
and
both
of
them
are
top
of
mind
to
me.
I
don't
have
a
strong
feeling,
as
as
far
as
which
should
be
our
next
meeting.
A
If
anyone
has
a
preference,
if
anyone
really
wants
to
be
part
of
that
discussion
or
lead
that
that
discussion,
let
me
know-
and
actually
nick,
if
you're
going
to
lead
the
june
21
one.
Let
me
know
there
if
you
have
a
preference
which,
which
topic
you
talk
about,
and
I.
C
Think
off
the
top
of
my
head,
I'm
hoping
that
by
then
I
I'd
like
to
actually
try
and
work
on
a
doc
about
the
you
know:
selection
policy,
thing
yeah
and
what
we're
trying
to
achieve
with
that
and
how
and
different
approaches
we
could
do.
C
I
think
the
james
idea
about
the
the
sort
of
the
control
object
is
a
good
one,
but
that
yeah
we
sort
of
need
to
be
like
we're
solving
a
generic
problem
here,
let's
set
it
out
as
a
generic
problem
and
say
and
sort
of
I'll
try
and
propose
some
sort
of
solution
there
so
yeah.
I
think
that
that
would
be
a
good
time
to
talk
about
that,
because
that
gives
a
couple
of
weeks
to
back
and
forth
on
a
dock
or
something
perfect
a
chance
to
present
that
so
yeah.
C
I
I'm
happy
to
put
that
there.
I
think,
whatever
discussion
we
have
about
that
will
probably
play
into
a
lot
of
the
other
things
we're
going
to
do,
because
it's
such
a
fundamental.
So
I
will
try
and
get
that
started
in
the
next
couple
of
days
so
that
we
can
have
some.
So
you
guys
can
have
something
to
talk
about
next
week
because
sorry,
I'm
not
getting
up
at
like
one
o'clock
in
the
morning.
So.
A
Good
all
right,
well,
yeah,
thanks
a
bunch
looking
forward
to
it
and
we'll
talk
to
some
of
you
next
week.