►
Description
Service APIs Bi-Weekly Meeting (APAC Friendly Time) for 20211115
A
All
right
we're
recording
it
is
november
15th,
it's
gateway
api
meeting
and
we've
got
lots
to
get
through
first
off,
though
I
just
want
to
check
in
if
we
do
have
a
meeting
next
week,
that's
november
22.
A
that
is
a
week
from
today,
but
also
the
week
of
american
thanksgiving,
I'm
actually
not
sure
I'll,
be
traveling,
then
I'm
not
sure.
If
I'm
going
to
be
around
or
not,
I
haven't
decided
yet,
but
I'm
wondering
if
anyone
else
will
or
won't
be
around
if
this
conflicts
and
a
lot
of
people
will
be
traveling
now
do
have
a
handle
on
who
might
or
not
might
not
be
here.
C
A
Man
all
this
now
I've
got
to
figure
out
how
to
use
zoom
properly
boy.
That
is
a
good
tip.
Where
are
we
at
oh
there?
I
found
them.
Thank
you.
A
Okay
looks
like
a
bit
of
a
mixed
bag.
A
couple
no's
and
a
couple
yes's,
is
what
I'm
seeing
so
far
all
right.
Well,
I
I
am
a
bit
tempted
to
punt
on
this
and
and
just
leave
it
till
the
29th,
but
I'm
I'm
open
to
what
others
think
here.
I
think
I
think
there's
enough
people
that
won't
be
around
that
we
probably
don't
have
enough
people,
for
you
know
a
a
full
meeting,
but
I'm
open
to
what
others
think.
A
That
that
simplifies
that
let
me
bump
this
discussion
to
the
29th.
If
I
can
type
properly
and
just
say
no
and
I
I
can
take
that
action
item
to
go
ahead
and
cancel
the
meeting
on
the,
I
should
probably
update
the
website,
but
definitely
I
can
update
the
calendar
to
delete
it
cool
okay.
The
next
thing
I
wanted
to
go
through
was
just
a
beta
release.
Update
our
next
release.
As
far
as
we
can
tell
right
now
is
targeting
beta.
A
Sorry,
yes,
but
yeah,
it's
exciting
to
see
that
one
roll
out
and
then
I
tweeted
about
that
and
manuel
from
traffic
pointed
out
that
they
actually
already
support
v1
alpha
2
as
well,
so
awesome
that
we
already
have
a
couple.
A
I
know
istio
has
had
v1
alpha
2
in
tree
for
a
while,
but
the
release
that
includes
it
is
rolling
out
this
week,
so
that
will
be
our
third
contour
nick
I'm
guessing.
It
looks
like
you
put
january
for
that
yeah.
D
A
Great
and
for
gke
we,
we
know
it's
a
matter
of
weeks,
hopefully
a
small
number
of
weeks,
but
I
I
can't
I
would
hope
it
would
be
before
january.
But
I
can't
say
for
sure,
and
then
kong
looks
like
january
as
well
cool.
A
All
right
cool:
well,
that's
that's
exciting
that
one
of
our
criteria
for
graduating
to
beta
was
that
the
v1
alpha
2
api
was
broadly
implemented
and
it
seems
like
we
will
certainly
hit
that
criteria
so
exciting
to
see
this
increasingly
broadly
implemented.
A
Yeah.
The
next
part
of
the
graduation
criteria
for
beta
was
really
just
to
stabilize
and
finalize
our
validating
web
hook,
because
that's
becoming
kind
of
a
core
part
of
our
release,
and
so
based
on
that,
I
went
through
and
found
various
issues
that
had
the
that
were
targeted
for
the
web
hook
improvement.
A
A
few
of
these
are
notably
good.
First
issue
help
wanted
great
ones
to
work
on
if
anyone's
new
the
project
and
wants
to
help
out
these
are,
I
think,
well
defined
and
would
be
great
to
get
some
help
with
this.
One
is
a
is
a
little
trickier
I
because
it
requires
some
knowledge
of
kubernetes
organization
and
really
just
talking
to
people,
probably
in
test
infra
about
how
to
set
this
up.
I
think
harry
has
some
knowledge
of
how
this
works,
but
but
this
will
certainly
require
help
from
someone
of
just
gateway
api.
A
A
E
Me
the
other
day
about
that,
maybe
we
would
want
to
publish
a
a
helm
chart
with
gateway
api
cids
that
people
could
require
as
dependencies
for
their
stuff.
F
I
think
it's
kind
of
a
controversial
topics
that
I'm
not
familiar
enough
to
make
a
good
decision,
but
my
understanding
is
that
crds
in
helm
are
not
upgraded
ever
and
so
I
would
be
a
bit
concerned
about
publishing
a
chart.
That's
just
crds,
given
that
you
can't
actually
update
them,
but
I've
seen
in
a
lot
of
products
is
they
have
the
crds
applied
through
cube,
cuddle
and
then
the
rest
installed
through
helm?
E
C
We'll
be
doing
it
through
our
existing
home
chart.
C
B
G
D
G
D
Yeah,
like
I
think
that
that,
for
critical
system
services
you
know,
cert
manager
is
a
good
example
of
this.
The
the
complexity
around
having
a
web
book
installing
crds
crds
requiring
cluster
admin,
lots
of
other
things
like
that
sort
of
should
mean
that
we
should
sort
of
push
people
to
be
like
look
yeah.
If
you
want
to
be
doing
something
with
the
go
apis,
you
need
to.
D
You
need
to
be
aware
that
this
is
like
a
little
bit
more
than
you're
just
banging
out
banging
an
app
into
the
cluster,
and
you
need
to
think
about
a
little
bit
more
than
that,
and
the
best
way
to
do
that
is
to
sort
of
say
you
need
to
do
our
own
install
process
rather
than
just
providing
a
home
shop.
A
Yeah
that
makes
sense
that
matches
up
with
what
I
have
seen
a
number
of
people
say
I'll,
just
throw
out
another
bit
of
complexity
here
or
other
option.
I
know
for
gk,
we've
been
considering
and
or
planning
providing
gateway.
Api
is
kind
of
like
I
guess
you
could
call
it
a
clustered
add-on
kind
of
thing,
so
maybe
other
managed
kubernetes
platforms
will
do
something
similar.
I
I
don't
know,
but
that
may
be
another
way
that
crds
get
installed
in
kubernetes
clusters.
D
D
I
don't
want
to
the
only
words
I
can
think
of
are
a
cut
above,
but
that's
not
really.
That's
not
really
the
right
way
to
say
it.
You
know
like
we're,
we're
a
little
bit
more
trusted
than
than
your
regular
crd,
because
we
get
to
use
we
get
to
and
have
the
burden
of
using
the
communities,
api
group
and
so
like
there's
a
there's
sort
of
an
imprometer
that
says
this
is
a
bit
more
trusted
because
it's
the
upstream
he's
doing
it.
B
Yeah,
I
think
official
is
the
right.
I
is
the
world
right
because
we
are
an
official
kubernetes
crd
yeah
yeah,
so
we
like,
we
are
not
yeah,
so
I
think
it
need,
and
since
we
have
this
special
concept
of
multiple
implementations
and
being
out
of
tree,
I
think
we
will
have
to
figure
out
a
way
to
right.
We
need
external
help
in
on
this
right,
so.
A
Yeah
yeah
there's
there's
been
some
discussion,
obviously
with
api
machinery
and
architecture
around
versioning
and
how
we
handle
that
and
how
we
and
and
to
a
certain
extent,
because
it's
related
installation
but
yeah-
I
mean
the
the
answer
so
far
that
I've
heard
pretty
consistently
is
well.
Installation
is
a
cluster
admin
problem.
A
So
for
some
people
a
cluster
admin
is
your
managed
provider
for
other
people.
It's
the
person,
you
know
setting
up
the
cluster,
but
for
other
people,
it's
kind
of
this
other
layer
and
as
we've
already
discovered
with
gateway
api
roles
in
kubernetes
clusters
are
different
for
every
organization,
and
so
it's
hard
to
correctly
layer.
This,
but
probably
just
deserves
another
discussion
somewhere,
I'm
not
sure.
A
But
right
now
it's
it
sounds
like
if,
if
I'm
understanding
the
thread
from
everyone
else,
it
seems
like
the
yeah.
Thank
you
for
adding
some
notes
on
this.
It
seems
like
the
current
standard
is
to
install
crds
directly
from
our
repo,
with
coop
cuddle,
as
a
recommendation
as
a
prerequisite
for
using
any
of
these
implementations.
A
But
there
is
great
interest
in
something
better
than
that
or
improved
than
that.
A
B
Like
that,
like
you
know,
you
essentially
copy
it
over
you're
not
going
to
modify
it,
but
if
you
don't,
if
you
like
suppose,
want
an
aircraft
installation,
something
like
that.
A
Oh
yeah,
I
see
I
mean
it's
yama,
my
when
I
heard
vendoring
my
immediate
thought
was
that
not
just
copy
it
over,
but
also
make
modifications
which
is
a
bit
of
a
scary
thought,
but
if
you're
just
copying
it
over
verbatim
for
ease
of
installation,
then
that
seems
appropriate.
If
versioning
is
identical.
B
E
So
I
just
talked
a
link
to
a
little
toy
project
that
I
experimented
with,
which
can
do
what
which
can
do
vendoring
so
it.
Basically,
if
you
needed
to
do
that,
install
it
like
you
can
write
code
which
will
generate
the
yaml
from
your
gateway
api.
It's
just
it's
pretty
straightforward.
It's
just
a
little
bit!
Skanky
and
horrible.
D
I
I
kind
of
feel
like
it
is
nate
james,
but
I
kind
of
feel
like
this
should
be
one
of
the
things
that
we
that
we
should
solve
with
the
bundle
and
the
the
at
the
end
of
the
day.
What
we
should
end
up
with
is
a
to
install
the
gateway
apis.
You
install
this
yeah,
I
mean.
Maybe
we
have
to
do
cube
kettle.
D
D
As
part
of
that,
you
know,
one
of
the
things
I
was
thinking
was
like.
Maybe
we
need
to
standardize
on.
You
know
where
the
you,
where
the
valid
the
validation
webhook
runs
and
a
bunch
of
other
stuff
like
that,
so
that
you
can,
with
all
the
stuff
that
we've
been
talking
about
with.
D
Are
we
going
to
need
people
to
do
extra
validation
and
have
them
and
require
people
to
run
the
web
hook
or
whatever?
If
we
are
going
to
reply,
keep
it
or
run
stuff,
then
we
should
provide
a
standard
way
to
install
that
and
say
you
must
use
the
standard
way
to
install
it
or
something
like
that
or
you
should
at
least
use
the
standard
way
to
install
it.
C
I
think
we
have
to
be
sure
we
allow
for
the
fact
that
we're
going
to
be
coming
out
with
different
bundles
and
any
vendors
product
may
only
support.
You
know
up
to
version
x
of
the
bundle,
so
we've
got
to
make
sure
there's
allowances
for
for
people
to
install
the
bundle
that
they
support.
Not
you
know
so.
You
know
which
maybe
an
older
version
right.
D
So
yeah,
so
this
is
part
of
the
version
management
story
that
rob
has
been
working
on
right
like
that
that
we
need
the
way
to
be
like
you.
You
must
have
at
least
this
version
of
the
bundle
working
or
something
like
that
and
have
some
level
of
compatibility
between
bundles
or
something
like
that,
because
yeah
right
now,
you
can
only
have
one
version
like
because
it's
crds,
you
can
only
have
one
version
of
the
gateway
api
install
a
lot
of
per
cluster
basis
in
the
story
and
there's.
A
I
don't
think
anywhere
yeah
that
makes
sense
today,
and
I
I
agree.
I
think
you
are
kind
of
trapped
with
a
single
bundle
version
per
cluster
by
by
definition.
I
I
also
wanted
to
go
back
to
an
earlier
comment.
You
made
nick
about
a
standard
way
to
install
a
specific
bundle
and
that
being
a
recommendation,
I
think
that's
a
good
starting
point.
A
I
think
the
most
important
thing
for
us
to
define
is
what
a
valid
installation
looks
like
the
characteristics
of
a
valid
gateway,
api
installation,
and
then
it
would
make
sense,
along
with
that,
to
provide
a
means
to
reach
that
valid
installation
right.
That's,
but
but
I
think
the
most
important
point
is
just
defining
what
that
valid
installation
looks
like.
A
Yeah,
okay,
lots
of
good
discussion
here.
What
is,
I
think,
what.
D
Luann
has
a
has
some
stuff
in
the
chat
about
that
she
did
get
clone
mate
generate.
Make
install,
I
think,
that's
perfectly
fine
for
now,
but
the
what
we're
saying
is
that
we
should.
A
Yeah
like
right
now,
our
our
installation
instructions
completely
ignore
webhook
as
an
example,
which
is
something
that
we
can't
have
once
we
get
to
beta
and
sorry
when
you
were
about
to
say
something.
I
Yeah
I
just
wondering
if
it's
the
right
way,
you
know
I
just
go
to
the
github.
Did
a
git
chrome
do
you
know
make
general
make
install
and
I
can
see
that
all
this
grd
created
on
my
caster.
A
Yeah,
so
that
definitely
works
it's
it.
One
problem
with
that
approach
is
it
is
going
to
pull
the
latest.
Basically,
all
our
development
goes
to
the
master
branch.
So
as
soon
as
we
merge
something
again,
it
lands
on
master.
So
what
you're
going
to
get
with
the
git
clone
by
default
is
just
kind
of
head
kind
of
the
latest
non-released
code
we
have,
we
do
have
tags.
A
So
if
you
like,
checked
out
a
specific
tag-
or
I
think
john
mentioned,
a
one-liner,
coupe
cuddle
apply
based
on
a
github
tag
that
could
get
the
crds
that
were
released
at
version
0.4.0
and
that
might
be
a
little
bit
safer.
But
what
you
have
certainly
works,
and
it's
probably
recommended
for
development
when
you're
kind
of
wanting
to
work
with
the
latest
set
of
apis.
A
Great
well,
this
is
good
discussion
yeah,
so
there's
a
lot
we
could
follow
up
on
here.
I
does
anyone
want
to
james
you've.
Been
writing
a
lot,
and
you
raised
this
discussion.
Would
you
be
comfortable,
creating
kind
of
a
follow-up
issue
to
summarize
this,
and
then
we
could
go
from
there.
A
Great
thanks,
okay,
all
right!
So
next,
that's
webhook
and
again
if
anyone
wants
to
volunteer
to
help
out
with
webhook.
There
are
a
variety
of
issues,
including
a
couple
good
first
issues.
A
So
if
you
have
time
or
you
know
someone
who's
wanting
to
get
involved
in
open
source,
kubernetes
things,
this
is
a
great
opportunity
all
right.
Next
one
is
conformance.
One
of
the
graduation
criteria
for
beta
is
having
meaningful
conformance
tests
in
place.
I
just
kind
of
threw
this
out
here.
I
been
working
on
some
conformance
related
things
which
we'll
discuss
later,
but
this
is
basically
my
approximation
of
about
where
we
are
or
where
I
hope
to
be
today
for
conformance
and
then
really.
A
A
That
is
a
gap
that
shane
has
been
working
on
and
should
have
some
time
to
discuss
it
today
and
then
route
inclusion
delegation-
that's
bumped
to
our
next
meeting
jeff,
is
taking
that
on.
C
I'm
just
gonna
say
I'll
post
to
the
slack
shell,
the
proposal,
so
we
don't
have
to
we
you
know
by
next
week,
so
that
people
don't
have
to
wait
two
weeks
to
even.
A
Yeah
that'd
be
great.
Getting
getting
some
initial
discussion
and
review
before
we
meet
is,
is
always
helpful.
Cool.
A
A
Cool
okay!
Well,
if
you
think
of
anything,
definitely
let
me
know
I
have
started.
I
think
it
already
existed.
A
v1
beta
1
milestone
I've
added
a
few
more
things
into
that
milestone.
A
As
you
see
things
that
you
think
belong
in
v1
beta
1,
don't
hesitate
to
add
them
in
yeah.
We
can
go
from
there,
okay.
So
with
all
that
said,
let's
get
into
some
actual
gaps.
The
first
one
is
rewrites
and
redirects.
A
This
gap
has
been
going
on
for
a
while
now,
but
I
think
we
really
are
close
to
consensus
on
this
one.
I
hope
I
there
have
been
a
few
changes
since
last
week,
based
on
some
good
feedback.
A
I
I
trying
to
remember
exactly
what
changed.
I
think
this
is
a
significant
one.
The
the
absolute
path
modifier
has
not
changed
at
all
but
replace
prefix
match.
This
is
one
that
has
gone
through
a
variety
of
different
name
changes,
but
the
concept
has
been
fairly
consistent
throughout.
I
yeah
this.
This
is
now
just
called
replace
prefix
match.
A
Another
change.
That's
significant!
This
in
this
past
week
is
based
on
popular
feedback.
The
types
that
are
used
here
for
both
rewrites
and
redirects
are
shared,
so
the
path
modifier
types
are
basically
just
referenced
by
rewrite
and
redirect
so
we're
not
redefining
these
in
both
places.
I
think
that
is
a
better
solution
here.
A
This
is
based
on
a
discussion
I
had
with
harry
who
raised
a
good
point
that
request,
rewrite
could
and
in
some
implementations,
does
include
things
like
header
modification,
query,
param
modification,
a
variety
of
other
things,
whereas
my
purpose
for
this
filter
was
very,
very
much
tied
to
host
and
path
rewrite
which
felt
like
it
could
fit
more
neatly
into
the
url
rewrite
name.
So
overall
I'd
say
these
have
been
relatively
minor
tweaks,
oh
yeah,
one
other
thing.
A
I
have
also
provided
a
set
of
future
extensions
here,
so
basically,
two
of
the
other
most
common
kinds
of
path,
rewrites
I've
seen
are
based
on
prefix,
basically
providing
your
own
pattern.
So
right
now
the
proposed
prefix
path
rewrite
is
based
on
the
match.
A
That's
something
that
most
implementations
I've
written
above
can
support,
but
it
is
also
relatively
common
to
support
bringing
your
own
patterns,
so
you
match
on
slash
foobar
or
whatever,
but
the
pattern
you
actually
want
to
replace
is
only
slash
foo,
so
in
that
case
you
would
provide
your
own
pattern
and
substitution
and
similarly
for
regex
for
regular
expression.
A
I
the
same
thing:
you
provide
a
pattern
and
a
substitution,
so
these
are
again.
This
is
not
actually
part
of
the
proposal.
It
is
a
section
of
how
we
could
extend
this
in
the
future.
I'm
not
suggesting,
starting
with
all
these
different
types,
but
I
think
it's
a
pretty
natural
extension
point
yeah.
So
that's
that's
what
I'm
thinking
I
in
regards
to
rewrites
and
redirects
I've
gotten
a
ton
of
feedback
on
this
already,
but
I
wanted
to
give
one
more
option:
it's
very
easy
to
lose
track
of.
A
A
B
A
Great
okay,
well,
hey!
I
will
take
that
thanks
to
everyone.
I
know
this
is
taking
a
while
to
get
through
and
I
appreciate
the
all
the
good
feedback
throughout.
I
think
we've
we've
got
to
a
much
better
place
than
we
started
with
on
this
one,
so
cool
all
right.
The
next
one
I'll
hand
it
off
to
shane,
because
shane
has
really
been
leading
this
gap.
It's
7
35
focused
on
l4
traffic
matching
and
shane.
A
G
Yeah
so
since
last
week
the
two
big
changes
are
howard,
john,
had
requested
the
network
match
basically
looking
a
little
bit
more
like
a
gateway
address,
so
that's
in
the
spec
now
and
that
allows
you
to
say
address
type,
so
you
can
say
ip
or
a
named
address.
G
The
other
thing
is
even
though
the
original
issue
called
for
port
matching
rob,
and
I
talked
a
little
bit
and
I
was
kind
of
feeling,
weird
about
port
matching,
given
gateway,
listeners
and
kind
of
the
constraints
there
on
how
useful
it
was
actually
going
to
be.
It
seemed
like
rob
kind
of
felt
the
same
way,
so
I
pulled
them
out
for
now
and
put
them
in
the
alternatives
considered
something
to
consider
for
later,
mostly
just
to
keep
this
nice
and
small,
and
it
is
quite
small
now.
A
Cool
yeah,
I
think
this
is
really
great.
I
know
john
has
had
some
feedback
on
this
already
and
I
have
too-
and
I
think
I
I
think
this
is
really
close.
I
really
like
how
you've
kept
this
as
concise
as
possible
here
really
focused
on
the
goal
of
address
matching.
I
think
someone
either
in
this
pr
or
the
issue
before
it
had
commented
that
really
the
the
attributes
we
have
to
match
on
are
not
that
many
but
destination
and
source
address
are
very.
A
You
know
very
obvious
starting
points
here
and
to
me
this.
This
feels
valuable.
I
seems
like
something
that
could
be
broadly
useful
and
I
think
this
is
a
reasonable
way
to
represent
it.
I
think
the
addition
of
a
named
address
is
is
interesting.
I
know
there
are
a
variety
of
different
use
cases
out
here,
but
I
I
think
that
that
helps
make
it
potentially
more
useful.
You
know
some.
A
Some
providers
may
have
names
for
addresses,
as
we
already
have
in
the
gateway
the
concept
of
named
address,
or
I
think
there
are
some
providers
that
do
matching
on
like
a
service
name
and
translate
it
to
a
cluster
ip
as
a
rough
example.
So
I
think
there's
a
variety
of
potential
use
cases
for
named
address
yeah,
that's
I
I
like
this,
but
I
should
let
other
people
talk
about
what
they're
thinking
too.
G
Most
of
it
is
alternatives
considered
at
this
point
which,
which
I
think
was
just
you
know,
I
have
a
lot.
I've
had
lots
of
ideas
about
ways,
I'd
like
to
go
like
adding
sitters
and
stuff
as
a
type
address
type,
but
I
think
small
is
good
to
get
started.
This
is
gonna,
be
very
contentious
if
there's
too
much
in
it,
yeah.
D
Okay
yeah,
this
looks
really
great
to
me.
Shane
I,
and
I
think
I
agree
that
adding
cider,
adding
side
of
routing
and
stuff
in
will
be
not
we'll
probably
do
it
at
some
point,
but
you've
got
the
space
in
there
to
do
it
with
the
type
so
yeah,
that's
great
roger.
That.
G
G
C
Very
common
awesome
yeah
go
ahead,
it's
very
common
to
say
you
want
to
allow
traffic
from.
Maybe
you
have
a
specific.
You
know
external
clients
that
you're
gonna
allow
the
connections
from
or
calls
from,
and
so
you
hard
code
in
the
address
in
your
config
those
addresses
as
valid
sources.
So.
G
G
I
I'm
just
out
of
curiosity
what,
if
people
want
to
use
network
policy
on
top
of
this,
would
that
cover
the
source
address
part
to
say
you
know.
I
I
attached
a
network
policy
to
this
gateway
and
this
is
l4
gateway
and
my
network
policy,
you
can
specify,
in
the
network
policy
to
say
who
can
come
to
access
the
gateway
policy.
Would
that
achieve
the
same
result.
A
I
think
there's
a
couple
differences,
but
that
is
a
good
point.
There's
there's
definitely
similarities
between
the
two.
I
one,
unfortunately,
there's
not
a
clearly
defined
relationship
between
network
policy
and
ingress
or
gateway
implementations.
G
Yeah
I
mean
like
she
said
it's.
It's
definitely
like
you
could
kind
of
do
the
same
thing,
but
I
think
the
biggest
difference
is
well.
I
mean,
I
think,
if
conceptually
it's
like
network
policies,
constraints
that
could
conflict
with
these,
they
kind
of
could
conflict
with
anything.
If
you
block
ip
addresses
from
accessing
the
cluster,
it's
not
really
specific
to
how
you
did
your
matching
rules
for
a
tcp
route.
It
could
affect
any
network
traffic
in
the
cluster
right.
G
I
I
D
Yeah,
sorry
jack,
do
you
want
to
say
something.
C
I
was
just
gonna
say
I
mean
I
think
you
know
that
you
know
a
lot
of
people
will
want
to
do.
You
know
either
ip
reputation
or
go
geoip
based
filtering.
They
do
it
at
the
gateway,
as
opposed
to
some
other
layer.
So
that's
where
I
think
we
want
to
maybe
make
an
extension
in
this
that
relates
to
this.
D
Yeah,
it
definitely
makes
would
make
sense
that
we
would
want
to
do
something
like
that
at
some
point,
I
think
that
if
you're
going
to
do
gip
you're
going
to
need,
I
definitely
have
that
to
be
an
extension.
I
think
that
for
leon's
question
that
that
the
way
that
I
think
about
this
is
that
network
policy
acts
at
the
level
of
the
cni.
It's
like
you.
D
It
stops
traffic
from
getting
in,
but
it's
deny
only
right,
like
you
can't
do,
and
so
the
you're,
if
you're
using
network
policy
on
your
and
you're
on
a
cl
on
a
name
space
where
a
gateway
is
then
it's
going
to
stop
traffic
getting
to
the
gateway
to
some
extent,
and
that
depends
on
exactly
how
the
gateway
is
implemented,
but
like
that
in
the
in
the
most
likely
case,
you
know
you.
Your
network
policy
will
stop
traffic
from
getting
to
the
gateway,
whereas
the
thing
this
does
is.
D
D
I
don't
think
there's
much
more
space
aside
from
source
address
destination,
address
and
the
ports,
that's
that's
it
at
the
layout
for
level.
That's
all
you
can
do,
and
so
you,
if
we
did
add
if
we
do
at
some
point,
add
ports
in
then
that
will
be
that's
the
the
maximum
feature
service
that
layer,
4
traffic
matching,
can
have
roger
that.
A
Yeah,
that's
a
good
summary
great
okay,
so
this
is
9
32.
It's
a
good
discussion
already
here
encourage
everyone
to
add
some
more
comments
on
this
one.
It's
we
don't
have
that
many
pr's,
so
it's
not
too
hard
to
find,
but
yeah
thanks
again
shane
for
taking
this
one
on
and
hopefully
we
can
get
it
in
soon.
A
There's
you
know
at
mvp
that
I'm
proposing
now
of
where
we
can
start
with
this,
and
I'm
hoping
that
we
can
get
enough
information
enough
consensus
on
this
approach
that
I
can
take
it
back
to
a
pr
and
actually
start
working.
A
So
with
that
said,
I
think
the
nvp
is
simpler
than
what
I've
defined
above
first,
I
think
I
we
should
only
cover
core
features
with
these
tests.
To
start
like
that,
I
want
just
the
minimum
set
of
tests.
We
can
possibly
start
with
just
so.
We
can
agree
on
structure
on
where
everything
belongs,
and
then
we
can
add
tests
as
we
go,
but
I
just
I
want
to
get
some
conformance
test
checked
in
as
soon
as
possible.
A
I
and
what
I
think
that
looks
like
is
running
tests
against
a
specified
class
in
an
existing
cluster,
not
trying
to
spin
up
any
new
clusters.
Anything
like
that.
It
just
runs
with
a
class
name
against
a
cluster
that
already
exists
only
covers
the
core
features
of
the
api.
So
we
don't
a
lot
of
the
discussion.
A
Then
we
want
to
output
some
kind
of
structured
format
that
can
be
parsed
and
used
to
generate
reports
for
showing
conformance
the
reports
themselves
are
certainly
a
thing
for
later,
but
at
this
point,
just
having
some
kind
of
structured
format
in
json
that
represents
the
results
of
test
runs
will
be
helpful
and
you
know
where
possible.
We
do
want
to
share
code
and
structure
with
ingress
controller
conformance,
and
I
think
that's
really
it.
A
I
I
wanted
to
use
around
the
same
test
structure
as
defined
before,
except
I
don't
think
is
enabled
or
url
are
needed.
Yet
I
want
to
get
both
of
these
involved,
but
again,
I'm
just
trying
to
find
the
smallest
possible
set
that
we
can
start
with
so
yeah
that
that's
a
lot,
but
hopefully
also
not
that
much.
A
B
I
think
so
I
think
I
just
have
the
question
that
I
think
rob
we
discussed
is:
how
will
we
create
like
dynamic
gateway
resources
and
yeah?
If,
yes,
then,
do
all
implementation
support,
reconciling
gateway
resources.
A
Yeah
I
yeah
that's.
Thank
you.
I'm
scared
about
this
one,
because
I
think
this
is
going
to
make
conformance
more
challenging,
but
I
that
from
what
I
can
understand
right
now,
there's
a
chunk
of
implementations
that
don't
support
just
you
know
responding
to
arbitrary
gateway
creation
like
I
create
gateway,
foo
of
your
class,
and
you
can't
respond
to
it
that
that's
my
understanding
right.
There
are
some
implementations
that
basically
ship
with
a
pre-existing
gateway
or
that
the
gateway
is
part
of
the
initial
deployment,
and
then
routes
are
attached
to
that.
Does
that?
D
As
of
now
at
a
point
while-
and
I
think
I
feel
like
the
the
mvp
for
this
test,
so
it
should
be
that
you
pass
it
a
gateway
class
and
then
it
enumerates
any
gateways
in
there
and
runs
the
tests
against
each
of
them.
But
that
and
that
and
then
we
leave
automatic
gateway
creation
testing
for
later.
A
Yeah,
so
I've
been
talking
about
I've
been
thinking
about
that,
and
that
is
certainly
the
easiest
starting
point,
but
then
it
makes
me
wonder
what
what
does
that
standard
gateway?
Look
like
right.
You
know
what
what
if
one
implementation,
ships
with
a
gateway
that
listens
on
port
80
and
another
implementation
listens
on
port
8080.
You
know
an
arbitrary
example
right:
do
we
do
we
just
run
tests
against
every
or
what,
if
one
gateway,
only
supports
one
listener
where
others
support
two
listeners?
A
D
This
feels
to
me
like
there
should
be
enough
information
in
the
status
of
the
gateway.
To
tell
you
like
what
you
need
to
test.
You
know,
like
you
know,
how
do
you
get
to
the
gateway
status
should
have
enough
information
to
say
you
know
how
do
you,
what
address?
Do
you
go
to
what
path
do
you
go
to?
How
do
you
actually
test
the
the
thing
that
you're
talking
about
yeah?
D
So
if,
if
that's
not
the
case,
then
we've
missed
something
in
the
spec,
and
we
need
to
add
that
yeah,
because
that's
that's
what
you
want
to
end
up
with,
from
the
gateway
point
of
view,
from
a
user,
that
you
can
look
at
the
status
of
the
gateway
and
be
like
okay,
this
is
the
gateway
I'm
going
to
use.
D
How
do
I
get
my
request
to
my
app
and
so
like
in
the
sense
of
if
there's
multiple
listeners
it
should
just,
I
feel
like
it
should
just
be
like
nested
for
loops
right,
like
you
know,
for
each
gateway
enumerate
the
listeners
for
each.
You
know
enumerate
the
addresses
enumerate
the
listeners
for
each
of
those
then
then
run
another
then
run
another
set
of
tests.
You
know
like
that
test
the
test
that
those
things
are
doing,
the
thing
that
we
test.
G
I
agree
with
that
and
for
what
it's
worth,
we
like
we're
in
a
similar
boat
at
kong,
like
we're,
going
to
be
trying
to
have
gateway,
support
on
fibo
and
alpha
2
by
january,
but
that
doesn't
include
provisioned
or
managed
gateways
like
we're
focused
on
unmanaged
gateways,
because
that's
the
current
use
case
and
that's
the
only
thing
end
users
need
today,
but
we
also
like
our
controller,
also
does
actively
fill
out
the
spec
and
the
status
and
it
otherwise
operate
like.
G
A
G
B
I
think
I
think
we
need
like
this
is
a
sufficiently
complex
area,
but
one
way
we
could
simplify.
If
you
know
other
implementers
also
agree
is
we
can
start
with
something
like
we're
trying
to
chunk
it
down.
So
you
can
start
something
like
okay,
we
do
tests
for,
let's
say
http
route.
Port
80
is
plain
text.
Port
443
is
https
and
that's
like
we
standardize
on
a
gateway
resource
that
we'll
test
and
we
get
like
a
few
tests
in
there
and
then
we
start
as
we
start
adding
more
tests.
B
We
sort
of
add
them
in
like
standardized
ways
right,
which
is
something
that
implementations
can
expect.
I
think
as
they
you
know,
because
when
you
are
running
the
the
test
before
that,
you
will
have
to
set
up
like
for.
If
you
are
not
provisioning,
the
gateway,
provisioning
resources,
then
you
know
there
will
be
a
setup
phase
before
the
tests
right
and
then
implementations
can
account
for
these
like
okay,
this
is
the
gateway
that
is
expected
and
you
know
they
can
in
the
setup
is
already
configured
right.
B
Like
80
and
443,
just
initially,
that
would
give
a
good
feel
whether
this
could
work
or
not.
D
Yeah
I
mean,
I
think,
that
yeah
we
shouldn't
even
need
a
hard
code,
80
and
443
like
that.
That
stuff
is
in
the
spec
already
you
should
just
do.
Take
the
listener.
Take
the
type
you
know,
take
the
specified
kinds
or
the
the
kind
we
have
the
listener
type.
The
listener
type
tells
you
what
test
you
should
run
on
that
port.
So
if
you
set
for
some
unknowable
reason
set
443
to
be
http,
then
the
test
should
just
pick
that
up
and
support
it
because
it
doesn't,
it
doesn't
put
semantic
meaning
on
the
port
numbers.
D
A
A
C
Actually,
I
I
had
assumed
to
be
honest
that
the
test
itself
would
actually
configure
the
gateway
you
know.
So
it's
it's.
It's
creating
a
properly
farmed
configuration
sending
that
to
the
gateway
controller
and
then
validating
that
through
its
tests,
yeah
yeah.
A
That
that
is
the
approach
that
works
better,
for
you
know,
gk's,
implementation
and
and
some
implementations,
but
it
it
does
not
yet
work
for
it
sounds
like
at
least
kong
and
contour,
and
probably
others
jeff
from
what
from
what
it
sounds
like
you're
saying
it
sounds
like
your
implementation
does
support
basically
provisioning
arbitrary
gateways.
C
Yes,
yeah,
it
does
okay,
great
okay
and,
to
be
honest,
I
and
I
think
that
the
test
itself
should
be
creating
the
config.
I
mean
there's,
you
know
we
can
get
a
way
or
to
work
around
it,
but
because
that
tells
you
you've
got
a
properly
constructed
configuration.
G
Well,
for
what
it's
worth,
I
mean
there
was
a
large
dock
on
this
previously
by
john,
and
that's
actually,
I
think
in
there.
If
I
don't
know
if
it's
actually
in
there,
I'm
just
going
to
call
them
managed
and
unmanaged
gateways.
I
feel
like
that's
easy
enough,
like
there
was
a
lot
of
evidence
that
unmanaged
gateways
existing
gateways
that
it
would
then
put
a
gateway
on
top
of
was
common.
G
I
know
like
even
istio,
has
an
option
for
it,
so
I
think
we
should,
if
we're
going
to
have
the
option
like
if
we're
going
to
have
the
testing
framework
point
at
a
gateway
or
create
a
gateway.
I
think
it
should
just
be
optional,
whether
or
not
it
creates
the
gateway.
If
that's
something
that
like
what,
if
jeff,
for
instance,
you
don't
have
the
unmanaged
type,
so
it
doesn't
make
any
sense
for
you
to
do
all
the
provisioning.
G
Just
have
the
the
frameworks
have
the
option
to
set
up
either.
A
What
what
so,
what
I'm
hearing
is
really
two
things
here
that
one
for
you
know
these
kind
of
unmanaged
gateways
that
these
kind
of
implementations,
what
we
really
would
we
need
to
do
if
we
wanted
conformance
tests
to
run
against
them
is
we
would
need
to
basically
parse
pre-existing
gateways
and
run
a
set
of
conformance
tests
based
on
the
characteristics
of
those
gateways,
whereas
what
the
other
and
larger
chunk
of
conformance
tests
would
cover
would
be
things
like
say,
cross,
namespace
references
or
other
things
that
that
may
be
more
complex,
but
would
require
control
of
both
the
gateway
and
routes
you
know
like
be
able
for
conformances
would
be
able
to
provision
both
gateways
and
routes,
which,
I
think
is,
I
think,
everyone's
agreeing.
A
That's
kind
of
the
ideal
end
state
here
and
the
red.
The
the
questions
needs
to
be
in
intermediate
state
of
how
we
test,
implementations
that
are
are
unable
to
kind
of
handle
arbitrary
gateways.
C
So
I
was
thinking
sorry
I'll,
just
real
quick,
I
was
just
gonna
say
I
was
thinking
that
from
an
mvp
point
of
view,
it's
it's.
I
think
it's
harder
to
query
the
configuration
of
gateway
and
then
you
know
make
your
test
fit,
that
versus
actually
just
writing
out
the
config
to
the
gateway
and
testing
the
conformance
at
that
point.
So
that
was
that
was
the
other
piece
of
my
thinking
on
it.
D
I
kind
of
feel
like
it
feels
to
me
like,
if
you
have
a
thing
that
takes
a
gateway
pauses,
it
figures
out
what
the
features
are
and
then
runs
tests
based
on
that,
and
then
you
want
to
be
able
to
test
the
that
a
gateway
that
you
create
like
meet
a
certain
set
of
goals
that
that
you
need
the
first,
the
first.
If
you
have
the
first
one,
then
the
second
one
is
easy,
because
if
you
have
because
then
you
can,
you
add,
like
an
outer
loop
that
says,
create
gateways.
D
Look
like
this
then
run
the
other
tests
that
look
at
the
gateway
right
like
yeah
and
so
like
it
feels
like
they
they're
kind
of
the
you
can
you
could
do
it
as
the
the
if,
if
your
test
pass
the
gateway
and
look
at
what's
enabled
you
know,
and
ideally
in
my
mind,
this
is
why,
in
my
mind,
there
should
be
stuff
on
the
gateway
class.
That
tells
you
what
what
what
the
gateways
are
going
to
look
like.
D
D
I
feel
like
the
mvp
should
be
look
at
the
gateway
and
run
some
standard
series
of
tests
based
on
some
of
the
values
in
the
gateway.
Like
I
think
it's
you,
the
yeah,
that
that
should
help
that
should
get
us
started
and
then,
like,
I
think,
the
first,
the
first
test
we
had
should
be.
Can
you
serve
a
http
service
out
of
this
thing?
That's
it
no
fancy
stuff,
nothing
like
that's
the
that's
the
basic.
A
And
that's
it
yeah
for
for
context.
I,
the
the
original.
You
know
this.
This
goes
back
many
months
at
this
point,
but
my
initial
attempt
at
a
gateway
conformance
test
was
not
too
dissimilar
from
ingress
and
that
you
basically
define
a
yaml
scenario.
You
know
basically,
here's
here's,
some
here's
a
gateway
and
here's
a
route,
and
then
you
define
characteristics.
A
You
know
you.
You
expect
this
this
and
this
to
happen.
Based
on
that
and
and
those
are
very
easy
tests
to
write
and
fairly
easy
to
understand
what
you're
describing
is
certainly
much
more
flexible
in
the
sense
that
I
I
write
something
more
abstract
that
can,
you
know,
understand
the
gateway
and
then
run
a
set
of
tests
against
that
gateway
or
that
listener
based
on
how
that
gateway
is
configured.
B
It
sort
of
flips
flips
the
gateway
resource
ownership
right
so
then,
like
the
implementation
defines
the
gateway
and
then
implementation
can
opt.
You
know
I
want
to
run
these
these
tests,
because
I
don't
support
these
x
number
of
tests
right
now
when
we
could
like
do
something
as
dumb
as
you
know,
I
don't
know
having
an
annotation
for
for
testing
framework
or
you
know,
having
name
like
names
for
name
spaces
or
gateway
research.
B
A
Yeah,
and
just
just
so
I
can
understand,
is
this
something
that
will
be
you
know
kind
of
a
consistent
characteristic
of
these
implementations,
or
is
it
kind
of
a
temporary
thing?
A
G
We
will
have
an
implementation,
I
think
what
I
would
I
would
I'm
going
to
go
ahead
and
say
we
won't.
I
won't
say
we
will.
We
would
most
likely
have
an
implementation
of
managed
gateways
long
before
we'd
be
able
to
get
all
of
our
end
users
to
move
to
that
implementation
like
we'll,
have
the
unmanaged
option
around
for
a
long
time.
D
If
your
ingress
controller
can
do
the
managed
tests,
then
when
you
do
that
when
you
have
an
unmanaged
gateway
that
makes
it
in
past
the
validations
key
point,
then
then
the
same
test
and
stuff
should
apply.
A
G
H
D
Yeah
you're
right
yeah
I
mean
we
could
we
could,
if
you,
we
could
also
shortcut
this
a
little
bit
by
saying
when
you
want
to
run
the
conformance
tests
you.
The
test
includes
the
name
of
the
gateway
that
you
need
to
to
do
the
test
or
something
like
that.
And
then,
if
you
want
to
pre-create
those
gateways
so
that
they
match
then
great.
You
know
that
might
be
a
way
to
get
to
an
mvp
quicker.
You
know,
so
you
can
say
well
simple,
http
gateway.
D
Does
a
simple
http
request
with
no
fancy
shenanigans
and
then
then
you
run
the
simple
http
test
against
a
simple
http
gateway,
and
so,
if
you
want
to
do
the
tests
and
when
I
have
the
you
can
pre-create
all
the
unmanaged
gateways
with
the
right
names,
maybe
you
have
the
same:
unmanaged
gateway,
20
times
with
different
names
or
something
like
that.
A
Yeah,
I
hope
so
it's
it's
there's
just
so
many
different
ways
to
do
this
and
want
to
take
a
reasonable
approach
here.
So
let
me,
let
me
think
about
it,
some
more.
If
anyone
has
more
thoughts
on
how
we
can
structure
these,
definitely
let
me
know,
but
but
I'll,
try
and
have
something
out
this
week,
where
not
not
necessarily
a
test
pr,
but
just
more
thoughts
on
on
how
these
could
be
structured
yeah.
We
can
go.
C
Raw
just
before
we
end
james,
you
posted
something
for
the
next
meeting
of
you
know,
kind.
B
C
Discussion
issues
from
implementers.
I
think
it
would
be
great.
You
know,
like
we
have
a
list
for
ourselves.
You
know
a
console
team
of
the
things
that
we
found
that
are
challenging
or
open
to
interpretations.
So
maybe,
if
other
implementers
put
lists
like
that
together,
we
could
all
post
them
someplace,
and
I
don't
know
if
we
want
to
open
an
issue
or
do
it
in
slack
or
create
documents
and
then
just
show
the
links
to
them.
E
Yeah
since
I
I
opened
that
topic
to
get
other
people
to
do
work
I'll
take
on
the
work
as
well.
I'll
start
a
discussion
and
I'll
start
I'll,
create
a
discussion
topic
in
github
and
we
can
post
everything
there.
How
does
that
sound.
A
A
Yeah,
thank
you
great.
We'll
have
a
have
a
good
week
and
we'll
talk
to
you
actually
in
two
weeks.
Next
we're
canceling
next
week's
meeting
but
talk
to
everyone
on
the
29th
thanks.
Everyone.