►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20220606
Description
SIG Network Gateway API Bi-Weekly Meeting for 20220606
A
It
is
june
6
and
we
have
a
lot
to
get
to
today.
It
is
the
gateway
api
meeting,
as
always
feel
free
to
add
things
to
this
agenda.
This
is
a
very
informal
meeting.
Sometimes
we
discuss
things
that
don't
have
a
lot
of
context.
A
So
please,
if
you
have
questions,
don't
hesitate
to
ask
them
you're,
probably
not
the
only
person
with
questions.
Some
of
us
have
been
working
on
this
api
for
a
long
time
and
forget
forget
things
so
yes,
for
with
all
that
said,
yes
always
always
appreciate
comments.
I
always
feel
like
you're
welcome
to
say
anything
you
might
be
thinking
here.
A
So
that
said,
let's
jump
right
into
the
v050
milestone,
because
that
is
you
know
top
of
mind
has
been
top
of
mind
for
a
while
really
working
on
getting
a
release
out
as
soon
as
possible.
Now
we
have
gotten
very
close.
I
added
one
thing
to
the
milestone,
but
otherwise
I
think
we
are
in
that
final
stretch
here.
A
The
first
thing
on
the
list
is
this
documentation
that
travis
is
adding,
which
I
really
appreciate
his
work
on
this.
This
is
a
great
set
of
documentation.
I
went
through
it
today
made
one
more
round
of
comments,
but
otherwise
I
think
it's
good
to
go,
but
I
don't
think
this
actually
blocks
a
release
candidate.
This
is
just
something
we
want
to
have
in
place
for
the
final.
A
Oh
five,
oh
release,
the
next
one,
this
one
we
do
need
to
have
before
we
cut
a
release
candidate-
and
this
is
something
has
taken
on-
I
I
know
her
time's
on
that-
doesn't
overlap
well
with
mine,
but
maybe
nick,
if
you're
around,
when
she's,
maybe
waking
up.
If
you
can
follow
up
with
her,
we
just
need
her
to
rebase
pr
the
1073..
A
A
B
Copy
of
the
thing
so
I'll
talk
to
her
about
it.
If
she's
not
gonna,
have
bandwidth,
then
I'll
I'll
pick
it
up
cool
okay,.
A
A
Apologies,
but
I
generally
just
have
like
an
hour
before
the
meeting
to
run
through
all
this
stuff
and
anyway
so
the
drive-by
reviews,
but
I
think
the
last
thing
that
was
left
open
on
this
one
was
this
validation
on
the
type
right,
and
I
I
suggested
hey:
can
we
just
have
like
some
combination
of
I?
You
know
like
clearly
well-defined
types
plus
domain
prefix
things
and
I
think
nick
you
are
concerned
about
the
potential
for
some
kind
of
you
know
backwards.
Compatibility
concerns
right.
B
Yeah,
so
the
the
reason
that
I'm
a
bit
concerned
about
this
one
is
that
so
the
the
validation,
the
api
server
validation
that
cube
builder,
gives
you
it
like.
B
It
doesn't
let
in
anything
that
doesn't
match
that
rejects,
and
so,
if
we,
if
we
then
want
to
add
another
like
extended
support,
single
name
like
ip
address
or
hostname
we're
gonna
have
to
change
that
validation.
B
Technically,
that's
like
a
version
break
and
a
harder
version
break
than
just
adding
a
few,
an
extra
one
to
it.
You
know
you're,
like
the
validation
changes,
are
far
more
likely
to
cause
problems
than
adding
an
extra
field
to
the
enum.
So
the
the
thing
that
I
had
proposed
was
to
say:
hey
this.
This
regex
should
accept
and
the
one
that's
there
accepts
either
a
bear
word
like
ip
address
or
host
name
or
a
domain
prefix
string.
B
B
B
You
know,
put
the
wrong
characters
in
and
then
the
webhook
handles
the
making
sure
that
you
that
the
constants
that
you
supply
either
one
of
the
two
constants
that
we
provide
currently
or
a
domain
prefix
string,
and
that
then,
that
then
that
means
that
the
process
of
adding
a
new
value
is
it's
not
an
emr
any
number
exactly
it's
effectively
an
enum,
but
you
add
a
new
constant.
B
You
add
that
constant
to
the
workbook
and
then
and
then
that
means
that
there's
no
like
spec
changes
is
like
a
web
hook,
change
to
add
a
new
value,
and
that's
what
I
like
about
doing
it.
This
way
is
that
is
that
the
like
you're,
not
making
as
many
changes
to
the
actual
spec
to
do
this.
So
it
means
that
once
say
once
we
go
to
ga
we're
not
gonna
for
this
field,
we're
not
gonna
need
to.
B
If
we
wanted,
we
can
safely
add
a
new
value
and
have
that
new
value
be
experimental
without
having
to
change
the
validation
in
an
experimental
way
like
so
so,
if
you
think
about
it,
if
we
want
to,
if
we
use
the
method
that
you're
talking
about
with
the
ip
address
the
hostname
and
then
we
want
to
add
a
new
value
to
the
validation
like
the
experimental
ones,
are
then
going
to
have
like
a
change,
validation
right,
and
I
just
I'm
really
reluctant
to
have
like
I
feel
like
the
validation
changes,
are
really
like.
B
A
You
know
I
I
completely
missed
your
distinction
there
between
like
when
I
was
looking
through
this.
I
I
missed
that
you
had
added
basically
what
I
was
asking
for,
but
just
pushed
it
to
the
web
book,
and
I
I
get
that
because
so
my
concerns
here
were
hey,
like
you're
gonna
end
up
with
people
using
things
they
should.
You
know
they'll
they'll,
just
agree
informally
on
these
other
things
or
you'll
get
all
these
typos.
A
B
I
kind
of
feel
like
it's
almost
worth
us
considering
moving
all
the
enums.
We
have
to
this
sort
of
pattern
yeah,
but
I
I
don't
think
that's
a
blocker
for
beta.
We
can
like.
We
can
change
that.
It's
technically
a
breaking
api
change,
but
I
don't
think
it's
going
to
be
that
big,
a
deal
to
change
that
as
long
as
we
keep
the
same
logic
in
the
workbook
like
the
behavior.
Won't
change,
it'll
be
where
the
validation
is.
A
Yeah,
so
I
yeah,
I
pulled
this
from
the
api
conventions
or
api
changes
docs
and
technically
we
we
have
left
enough
room
open
for
us
to
add
things
to
change
things
in
the
future,
but
that
doesn't
mean
it
like.
I
think
your
approach
is
still
the
best
and-
and
I
think
basically
what
my
all
I'm
saying
there
is.
I
think
we
have
room
to
do
exactly
what
you're
saying
transition
the
rest
to
a
web
hook
in
the
future.
Yeah.
B
Yeah
I
just
want
the
the
last
thing
I
wanted
to
add
here
is
the
other
reason
that
I
like
doing
this
in
the
workbook
is
I
want
the.
I
don't
know
if
it's
in
a
state
that
we
can
at
the
moment,
but
I
kind
of
want
the
validation
code
to
be
like
importable
and
usable
in
your
own
implementation
of
the
web
hook
and
then
eventually
the
goal
my
goal
is
to
have.
B
The
conformance
tests
include
basically
checking
that
you
have
the
doing
running
the
same,
so
we
have
a
bunch
of
unit
tests
in
the
validation
module.
At
the
moment,
I
want
the
the
conformance
to
run
basically
the
same
as
those
as
those
unit
tests
the
site
every
test
case
that
we
test
in
the
unit
tests
should
be
tested
in
the
conformance,
so
that
your
your
implementation
will
not
pass
performance
if
you
are
not
running
the
the
yeah.
I
agree.
C
A
Yeah
I
mean
nick
and
I
have
been
talking
a
bunch
any
any
other
opinions
on
this.
One.
A
Cool
I'll
take
that
as
consensus
but
yeah.
If
anyone
has
any
second
thoughts,
definitely
let
us
know
all
right.
Oh
there
was
one
more
thing
in
the
milestone
that
I
I
missed
out
on
here.
A
This
is
a
big
one,
so
I
had
created
a
discussion
earlier
that
the
more
I
thought
about
it,
the
more
I
was
concerned
that
in
the
future
we
would
have.
We
would
want
this
extra
level
so
right
now
we,
the
only
thing
we
have
is
beta
and
beta,
is
the
most
stable
thing.
Well,
you
know
that
we
can
think
of,
but
at
some
point
we'll
have
ga
and
we
may
want
to
further
differentiate
and
if
we've
already
used
stable,
to
describe
things
that
are
beta.
A
A
The
proposal
I
came
up
with
was
standard.
I
am
very
open
to
other
terms
here,
I'm
not
tied
to
that
specific
word,
but
the
main
thing
is
just
some
other
word.
That
is
something
between
experimental
and
stable,
so
I
have
a
pr
that
I
just
filed
a
few
minutes
before
this
meeting
that
that
makes
that
change,
but
I
am
very
interested
in
other
terms,
other
ideas.
It
looks
like
I
think,
there's
only
three
people
that
have
voted
on
this
so
far
so
and
I
think
I'm
one
of
them.
A
So
if,
if
others
have
opinions
any
term
that
you
prefer.
D
D
Right
that
works
for
me,
so
I
think
that.
A
A
Probably
oh
good
stuff
good
to
hear
okay.
Well
with
that
said,
it
seems
like
there's
pretty
wide
consensus.
Then,
if
anyone
has
time
to
just
do
a
drive
by
lgtm
on
this
one,
we
can
get
it
in
there's
a
couple
of
I
was.
B
Now
it
looks
like
there's
a
couple
of
inadvertent
usages
that
got
replaced
with
standard
I'll
call
it
out.
Thank.
A
You
thank
you
for
catching
those
cool,
the
the
danger
of
a
find
and
replace
all
right,
cool
next
up
shorter
term
than
v050.
I
really
am
hoping
to
get
a
rc1
out
this
week.
A
I
have
scheduled
some
time
to
chat
with
tim
tomorrow
he's
I
think,
our
last
remaining
api
reviewer
on
this.
That
needs
to
sign
off
and
once
he
signs
off.
I
want
to
cut
a
release
candidate
asap
ideally
this
week,
and
one
of
the
things
that
we're
missing
to
do
a
release
candidate
is
a
change
log,
so
open
question.
A
I'll
do
it
you're
the
best
shane.
Thank
you
so
yeah
I'll.
I
can
follow
up.
We
we
have
some
good
examples
of.
I
think
nick's
change
log
when
we
went
to
o4o
was
pretty
great,
but
that
there's,
I
think,
there's
a
pretty
small
change
set
this
time,
so
our
changelog
will
be
relatively
small.
So
I
guess.
B
The
in
my
mind,
in
my
mind,
the
the
big
things
to
do
with
the
change
log
is
just
to
make
sure
that
any
like
breaking
changes
are
called
out
with,
like
a
little
bit
of
explanation
as
to
why
we
did
it
and
that
sort
of
thing,
if
you
have
a
look
at
the
previous
one,
that's
what
I
that's.
What
I
tried
to
do
there
yeah.
G
So
as
someone
who's,
never
written
a
changelog
before
for
this
project,
and
possibly
shane,
also
falls
into
that
bucket.
I
know
that
there
are
on
the
pr's
those
little
like
you
know.
If
you
have
a
user
facing
change
listed
and
like
the
change
log
item
here,
does
that
get
like
gathered
together
automatically
anywhere
or.
A
There
is
some,
I
think,
there's
some
upstream
script,
so
we
basically
copied
that
from
upstream
kubernetes
repo,
and
I
think
they
have
tooling
around
that.
We
didn't
copy
that
tooling
at
all.
But
so
far
our
list
of
prs
has
been
pretty
small,
so
we'll
just
like
copy
and
paste
these
and
throw
these
together
in
a
change
log.
What
nick
did,
which
I
think
I
think
they've
started
doing
this
upstream
too?
A
Automation
would
be
very
welcome
there,
especially
if
we
can
just
copy
it
from
what
upstream
is
already
doing.
Yeah
good
call
that
that
was
definitely
something
that
I
think
we
always
wanted
and
just
never
got
to,
but
yeah,
and
it's
one
of
those
things
where
we
only
ever
notice
it
right
as
we're
about
to
release
and
as
we're
about
to
release
we're
at
like
full
capacity,
and
you
know
yeah
so
cool
yeah,
good
question.
Well,
so,
while
we're
talking
about
0.50
release
candidate,
you
know
a
release.
Candidate.
A
Still
gives
us
some
room
to
change
small
things
before
a
release,
but
we're
ideally
trying
to
keep
change's
post
release
candidate
very
tiny.
So
with
that
said,
is
there
anything
that
we
have
missed
in
this
release
or
anything
that
we
really
should
spend
a
little
bit
more
time?
Thinking
about
before
we
cut
a
release
candidate.
A
B
B
I
can't
think
of
anything
I
think
we've
got
everything
pretty
well,
but
so
I'm
not
I'm
happy,
I'm
happy
for
us
to
just
anticipate
that
there
won't
be
anything
and
then
wait
and
see
we
all
actually,
because
once
we
all
have
the
tagged
version
available,
then
we
can.
B
Then
we
can
actually,
you
know,
update
dependencies
and
stuff
and
flip
the
and
just
start
the
coding
process
to
actually
flip
the
whole
bunch
of
coding
that
we're
all
going
to
have
to
do
as
a
plant
is
to
actually
flip
to
using
the
v1
b1
types
right
like,
and
so
that's
the
reason
to
do
that.
The
main
reason
to
know
rc1
is
that
everyone
can
get
started
on
those
pr's.
Now.
A
This
but
okay,
this
is
a
really
good
question.
Well,
not
quite
it
wasn't
a
question,
but
it's
something
that
I've
I've
been
discussing
internally
and
I'm
imagining
others
are
too,
as
we
move
to
v050
we're
entering
a
new
phase
where
we'll
like
the
crds
are
going
to
have
v1
alpha
2
and
v1
beta
1
types
and
they're
going
to
be
identical.
A
A
But
we
haven't,
we
haven't
actually
said
that
anywhere
we
haven't.
Given
that
guidance,
it's
just
kind
of
you
know.
Well,
this
is
what
happens
in
that
stream.
I
can.
I
can
make
a
note
of
that,
but
does
anyone
have
any
reason
you
wouldn't
want
to
do
that.
B
Yeah,
I
think
we
can.
We
could
distance
some
stuff
with
that
with
the
storage
version
definition
in
the
in
the
crd
right,
like
yeah.
If
the
storage
version
is
v1,
alpha,
2,
then
then,
or
as
long
as
they
both
have
the
same
storage
version
between
the
two
different
crds
then
like
the
then
it
won't
matter
right,
like
you'll,
be
able
to
yeah,
then
kubernetes
will
handle
the
rest
for
you.
A
A
Yes,
yeah
yeah,
the
the
only
time
we
would
diverge
from
that,
or
at
least
the
only
time
that
we
diverge
from
that
in
upstream.
Kubernetes
is
when
you
do
a
rename
and
we
have
been
trying
as
as
much
as
possible
to
to
avoid
renaming
fields,
because
that
brings
in
conversion
web
hook
and
all
kinds
of
pain.
B
So
I
guess
that
the
larger
question
to
end
to
ask
there
as
well
is
at
what
stage
do
we
re
remove
the
do
and
do
we
remove
the
v1
alpha,
one
versions
of
resources
that
are
now
available
in
v1p
to
one
you
know
so,
for
you
so
and
the
same
goes
the
same
question
we'll
go
again
when
we
go
from
b
to
g
a
right
like
once,
we
once
gateway
goes
from
v,
1
b
to
1
to
v
1.
B
When
do
you
remove
the
v
1
beta
1
from
the
from
the
generated
set
of
v,
1
p
to
1
times
I
like
so
like
yeah?
I
guess
I
think,
like
it
kind
of
feels
to
me
like
that,
would
be
a
that's
a
like
a
minor
version
like
a
that
would
be
a
v060
thing
that
we
would
say:
okay,
yeah!
B
F
H
Are
there
other
standards
set
for
other
apis?
Could
we
just
follow
you
support
two
and
then
the
third
one
always
falls
off
the
ledge
or
where
do
we
have
to
come
up
with
our
own
policy.
A
We
that
yeah
that's
a
good,
a
good
question.
There
are
policies
in
upstream
kubernetes
that
I
think
we
should
try
to
follow
as
closely
as
possible,
but
they're,
you
know
we're
a
little
unique,
so,
for
example,
beta
apis
have
to
stay
around
for
three
minor
releases
at
minimum
after
a
after
it,
graduates
to
ga,
so
you
likely
all
are
very
familiar
with
the
pain
that
was
caused
by
ingress
v1,
beta
1
being
removed.
A
Sorry,
but
that
that
is
a
thing.
There's
been
a
lot
of
pressure
to
expedite
the
removal
after
three
releases,
instead
of
leaving
betas
around
forever.
I
don't
know
we.
We
have
some
wiggle
room
in
terms
of
how
quickly
we
remove
api
versions,
but
I
think
at
a
minimum,
we'd
want
to
match
what
oss
does
for
stability
in
in
terms
of.
If
an
api
is
beta,
it's
sticking
around
for
at
least
three
releases.
A
B
Yeah,
I
think
I
think
we
all
do,
but
I
think
we
we
need
to
like.
I
think,
there's
probably
an
issue
in
the
you
know:
leave
resources.
How
long
do
we
leave
resources
around
for
and
then
there's
you
know
yeah
like
what
do
we
do
about
about
the
resources
in
the
shorter
term?
B
Yeah
yeah,
I'm
I'm
a
proponent
of
if
it's,
if
there's
a
more
stable
version
available,
we
leave
them
around
for
a
while
and
then
remove
the
and
then
remove
the
versions
so
that
we
don't
have
I'm
not
a
proponent
of
leaving
them
there
forever.
I
think
that
it's
it's
too.
It's
going
to
be
too
easy
to
miss
moving
things
between
the
different
versions,
because
remember,
in
order
for
us
to
have
the
separate
things
we're
going
to
have
to
have
separate,
go
types
as
well
like
we're
going
to
have
to
have
separate
gotox.
B
You
can't
just
yeah,
take
the
go
types
and
you
know
like
we'll
have
to
have.
That
means.
If
we
keep
all
of
the
versions
around
favor,
we
will
have
three
copies
of
every
object
that
you
have
to
update
anytime.
You
want
to
update
one
field
which
is
up
yeah,
so
yeah
like
I,
I'm
not
a
proponent
of
living
around
forever,
because
of
just
because
of
that
yeah.
A
One
thing
that
I
and
I
think
that
makes
sense,
I
think
what
we
need
to
be
very
aware
of
is
we
want
implementations
of
this
api
to
be
able
to
support
a
wide
range
of
versions
right.
So
one
of
one
of
the
things
one
of
the
pain
points
that
was
caused
with
the
ingress
v1
beta
1
to
v1
migration,
is
that
it
was
hard
for
an
ingress
implementation
to
support,
say
a
range
of
four
or
five
kubernetes,
minor
versions,
which
is
a
pretty
common
desire.
A
B
You
should
be
using
the
most
recent
one
and
it
should
be
relatively
painless
for
implementations
to
upgrade
to
upgrade
to
the
most
recent
one,
and
they
should
just
be
doing
that
as
a
matter
of
course,
and
so
like
you
know,
it
should
be
reasonably
straightforward.
We
should
make
it
as
easy
as
possible
for
implementation
to
upgrade
so
that
then
we
can
can
be
a
bit
more
aggressive.
I
think
that's
what
we
should
aim
towards
practically.
B
A
That
makes
sense
any
any
other
thoughts
on
this
before
we
move
on.
A
Okay,
I'll
I'll
keep
on
going
then
matt.
I
want
to
get
to
your
question.
Make
sure
that
we
I
want
to
continue
with
this
release
discussion
for
a
little
bit
but
make
sure
that
we
get
to
it.
Maybe
you
can
add
it
to
the
to
the
doc
or
I'll,
just
try
and
circle
back
at
the
end
of
the
agenda.
A
Thanks
so
0.50,
that
is,
I
think,
weeks
out,
but
I
I
really
really
want
to
get
this
out
this
month
so
and
with
that
said,
if
we
get
an
rc
out
this
week,
let
it
sit
for
a
week
or
two
probably
a
couple
weeks
and
then
hope
for
a
final
release
after
that
that's
kind
of
an
ideal
timeline.
In
my
mind,
with
that
said
the
last
time
we
did
a
major
release.
You
know
we
we
had
some
announcements
around
it.
I
think
we
had
a
gateway
blog
post.
A
I
think
I
know
we
had
a
kubernetes,
I
o
blog
post.
I
am
curious.
Is
anyone
interested
in
writing
or
working
on
a
blog
post
for
this?
You
know
I.
I
can
pull
up
what
I
think
mark
wrote
this
for
us
last
year
and
everyone
kind
of
added
their
name
to
it
and
contributed
different
bits
to
it.
But
is
there
anyone
who's
interested
in
writing
up
a
blog
post
to
highlight
our
beta
release?
I'd
like.
A
Cool,
so
shane
has
volunteered
again
you're
the
best,
but
if
you
do
feel
overloaded,
definitely
let
let
anyone
else
help
out,
but
thank
you
for
for
taking
that
one
on.
I.
E
Think
I
should
be
good
at
this
point,
so,
although
I
I
I
think
it's
going
to
be
a
lot
of
looking
at
git
log
for
the
changelog
and
comparing
it
with
vr
yeah.
A
With
that
said,
do
we
have
any
additional
ideas?
Any
anything
else
that
we'd
want
to
do
as
part
of
the
you
know,
beta
is
a
pretty
significant
release
for
gateway
api.
You
know
we've
been
working
on
this
api
for
a
long
time
now
I
don't
even
know
know
how
long
but
you're
looking
at
nick
and
danian
and
whoever
else
was
was
back
in
san
diego
when
this
was
just
starting.
It's
been
a
while.
A
So
if
anyone
else
has
additional
ideas
for
how
we
can
you
know,
get
get
the
word
out
that
this
is
going
beta
very
open
to
that.
I
want
to
make
sure
that
that
this
is
spread
as
far
as
possible.
A
Cool
all
right
with
that,
let's
move
on,
I
think
travis
you
added
one.
G
Yes,
I
basically
wanted
to
do
a
check
the
room
in
the
course
of,
like
writing
the
rewrite
docs
it
can
compare
like
there
isn't
really
any
guidance
in
there
or
on
the
spec
as
to
like
whether
or
not
you
should
do
anything
with
configuration
that
can
create
a
redirect
loop.
So
if
the
input
of
your
redirect
is
the
same
as
the
output,
do
you
actually
return
that
as
an
implementation?
B
A
G
Yes,
I
mean
like
you,
won't
be
able
to
do
like
something
you
won't
be
able
to
like
check
like
a
chain
of
redirect
loops
so
like
if
it
goes
to
place
a
and
then
place
b
and
then
black
to
place
a
you
won't
be
able
to
text
that.
But
this
is
kind
of
the
simple
one
that,
like
you
know
in
the
course
of
configuring
things.
C
B
I
I
really
like
that
solution.
I
think
it's
a
it's
quite
elegant
and
I
think
that
it's
going
to
hit
the
things
that
people
really
care
about,
which
is
it
also
lets.
I
mean
one
of
the
things
that
we
want
to
end
up
with
is
say
for
the
inclusion
delegation
that
stuff
needs
to
be
composable
right,
like
you
need
to
be
able
to
just
specify
things
and,
and
the
idea
of
having
this
makes
the
copy
more
composable
in
that
you
know
it
doesn't
matter.
B
If
you
do,
if
you
do
a
rewrite
and
it
does
nothing,
then
it
does
nothing
right
like
that.
That's
yeah
and
the
rewrite
doesn't
actually
produce
an
output
and
any
difference.
Then
then
the
config
is
essentially
nothing.
Maybe
there's
some
stuff
that
we
can
look
at
later
about
surfacing
that
to
people
to
say,
hey
the
rewrite
that
you
put
in
here
doesn't
do
anything,
but
that's
like
not
as
important
as
just
not
having
it
doing
anything
to
start
with,
I
think
so,
yeah
I
really
like
it.
F
F
It's
like
kind
of
hard
to
prevent
a
loop.
In
that
case,.
B
Well,
yeah,
I
think
that's
why
I
think:
that's
why
travis,
if
you,
if
I
can
have
a
crack
at
explaining
a
trailer,
then
you
can
correct
me
if
I'm
wrong.
I
think
that's
what
travis
is
aiming
at
that
you
know
if
you,
if
you,
if
what
you
are
doing
with
a
redirect,
is
like
largely
the
same,
then
it's
a
no
op
or
something
is
that
right
or
I
don't
know,
travis.
G
G
Basically
all
you
probably
care
about
for
that
is,
like
you
know,
if
the
request
is
inbound
to
example.com,
redirect
it
to
https
in
the
way
that
redirect
filters
are
written,
there's
no
protocol
field,
so
you
can't
say,
like
you
know,
do
that,
but
if
it
is
going
to
https
already,
then
don't
do
that
it
only
just
has
like
you
know,
example.com
and
path,
and
such
so
like
technically,
the
next
inbound
requests
for
https,
according
to
like
the
actual
configuration
in
the
redirect,
should
still
be
redirected
back
to
https,
even
though
it's
already
there,
but
I
think
thinking
practice
you
don't
really
ever
want
to
do
that
for
that
type
of
redirect
or
for
even
one.
G
So
you
know
what
the
input
like
input
url
is
and
what
the
output
url
is
after
you
perform
the
transform.
So
if
you
just
check
those
and
see
that
they
are
equal
and
you
don't
actually
return
the
redirect-
you
just
proxy
onward.
F
G
Yes,
I
mean
this
is
a
if
you
have
an
implementation
that
where
that
is
actually
difficult
and
like
it's
both
the
case
that,
like
you
know,
you
can't
do
that
with
like
a
single
piece
of
configuration,
or
you
can't
do
kind
of
what
we've
done
in
the
past
for
some
things
where
you
like,
create
multiple
pieces
of
configuration
and
ultimately
satisfy
the
spec,
that's
kind
of
what
I'm
looking
for
here
to
see.
B
Got
it
yeah,
I
mean,
I
think
the
thing
to
remember
here
is
that
the
conformance
test
for
this
will
test
that
you
know
like
that.
You
end
up
with
the
desired
behavior
right
like
that.
You
that
you
try
to
go
to
http
to
http
and
you
get
redirected
to
https,
and
then
you
get
the
page
back.
The
specifics
you
don't
end
up
in
a
redirect.
B
Loop
right,
like
the
conformance
test,
should
help
with
ensuring
that
the
behavior
is
actually
what
we
expected
to
be
and
that
that's
the
point
of
the
components
test
riders
to
be
like
hey.
This
is
how
it
should
work,
and
you
should
see
the
flow
flow
like
this
and,
if
you're,
and
that
means
that,
if
your
implementation
can't
do
it
or
doesn't
do
it
by
default,
then
when
you
try
and
run
the
conformance
you'll
know.
G
G
Like
it
is
actually
a
moot
point,
I
think
in
gateway,
but
it's
like
the
just
the
easiest
example
of
like
this
is
a
very
easy
way
to
like.
You
know,
ignore
that
part
and
like
if
it
did
just
kind
of
you
know
if
they
were
both
on
the
same
like
dual
stack
listener
like
a
naive
invitation,
would
probably
not
be
what
users
want.
I
mean.
B
It
is
possible
to
have
you
remember
that
you
can
have
a
http
route
say
attached
to
all
the
listeners
in
a
gateway.
B
F
It's
like,
on
the
one
hand,
we
can
make
it
easy
for
people.
On
the
other
hand,
it
seems
like
it's
incorrect
in
some
ways
to
allow
basically
to
be
like
hey.
You
can
put
this
redundant
thing
in
there
and
like
technically
speaking,
if
you
were
bearing
very
strict,
you
would
just
get
this
like
loop
back
and
forth.
B
But
yeah
and
that's
that's
why
I
really
like
travis's
solution
in
that
in
a
https
case
like
the
the
the
config
that
you
have
when
you
translate
it
into
like
actual
data
plan,
config
means
that
if
you
get
a,
if
you
get
a
https
thing,
you
just
don't
clue
the
redirect
right
like
that.
This
is
about
you
know
you
can
say
hey.
B
The
intent
is
that
you
should
always
end
up
at
https
right,
like
the
redirect
means
that
you
redirect
https
and
we
can
say
well,
we
we
know
that
you
mean
when
you
say
that
that,
if
that,
if
that,
if
this
redirect
would
do
nothing,
then
don't
redirect
right
like
there's.
No
and
there's
no
reason
for
you
to
want
to
reiterate
this.
B
B
I
don't
want
to
like
it's
good
for
us
as
the
implementers
to
just
make
that
problem
go
away
right,
like
you
don't
have
to
care
about.
You
can
just
say,
put
this
thing
in
put
this
little
standard
of
config
in
and
attach
your
http
route
to
both
listeners
on
your
gateway
that
do
http
and
https,
and
and
that
your
problem
is
solved
right,
like
you,
don't
need
to
have
two
separate
ones.
B
I
think
that
it
is
mikael
said
in
the
chat
that
it's
work
around
to
avoid
creating
two
http
routes:
yeah,
it
is,
but
it
means
that
the
but
the
it
means
that
the
the
end
user's
experience
is
that
they
ask
for
the
thing
that
they
want,
and
then
we
take
that
and
give
them
what
they
need
right.
Like
you
know,
I
mean
like
to
make
that
want
to
show
up.
F
G
I
think
the
question
is
probably
maybe
more
like
you
know
that
abstract
comparison
of
like
does
url
string
equal
other.
Your
url
string
is
very
simple,
whether
that
exists
in
implementations
already
or
like.
If
there's
an
easy
way
and
implementations
to
do,
it
is
maybe
a
bit
more
murky.
I
think
actually
in
like
in
our
case
like
for
hp,
hps
redirects
that
definitely
is
implemented
that
way
like
it
will
not
loop,
but
for
other
types
of
redirects.
I
don't
think
we
actually
have
anything
to
catch
that
at
the
moment,.
A
Yeah
that
so
that
that's
my
concern
here,
I
have
to
be
have
to
be
very
careful.
You
know
the
way
I
think
of
this,
as
so
much
so
far,
everything
we've
required
in
spec
is
something
that
can
be.
A
You
know,
statically
computable,
right
and
the
way
to
do
this
statically
would
be
to
basically
take
what
is
one
http
route
and
split
it
up
right,
and
so,
even
though
it's
one
inbound
hp
route,
you're
splitting
that
up
into
do
this
for
http
request,
do
this
for
https
or
do
this
for
requests
on
this
hostname,
but
not
on
this
hostname.
You
know
you're,
basically
splitting
up
the
configuration
some
additional
way
and.
A
I
think
maybe
the
hardest
part
of
this
will
be.
Where
do
you
draw
that
line?
There
are,
without
a
doubt,
some
redirect
loops
that
will
be
possible.
That
would
be
near
impossible
to
detect
as
this
implementation.
There
are
others
like
you're
saying
that
are
going
to
be
very
easy.
F
A
F
We
just
need
to
be
careful
because
we
could
run
into
a
case
where
someone
actually
wants
the
thing
to
send
back
a
redirect,
even
though
it
seems
stupid
and
then
when
they
go
to
configure
it
they're
like
we're
like.
Actually
sorry
like,
you
really
meant
the
other
thing
we're
like
well,
but
that's
really.
F
B
B
That,
if
we
do
something
more
explicit,
what
we
have
now
is
for
the
use
case
that
I
say
I'm
like.
I
just
want
to
expose
my
service
on
https,
and
I
want
it
to
redirect.
Please
it'll
be
like
oh,
okay,
no
problems,
but
what
you've
got
to
do
is
you're
going
to
take
that
same
http
route,
duplicate
it
and
then
attach
it
to
the
http
listener,
because
you
can't
use
the
same
one
except
for
the
bit.
B
You
know
it's
making
it's
making
the
things
that
should
be
easy,
require
a
whole
extra
resource
just
so
that
we
can
do
these
things
that,
like
probably
like
that,
if
you,
if
you
are
wanting
to
do
it,
you
like
really
like.
Why
would
you
ever
like?
Why
would
you
ever
want
to
say
you
know
like
I
want
to
redirect?
You
know
things
that
come
into.
You
know,
slash
food
or
slash
bar
you
and
then
yeah,
but
then
you
and
I
want
to
redirect
things
that
go
to
slash
bar
like.
B
Why
would
you
ever
like
there's,
no
reason
that
you
would
want
to
to
redirect
a
matching
url
to
another
matching
url
right
like
because
it's
not
it's?
The
host
name
is
the
port.
It's
the
protocol,
like
it's
the
sorry,
the
protocol
indicator
in
the
uri
plus
the
path
right
like
there's.
No,
I
can't,
I
cannot
think
of
a
valid
use
case
that
you
would
ever
want
to
do
that
right,
like
and
no
client
is
going
to.
Let
you
do
that
right
like
and
then
so.
B
F
I
just
I
get
concerned
like
we
can
properly
define
it
in
all
cases,
not
the
simple
case,
like
probably
the
simple
case,
will
work
and
then
after
defining
it,
whether
or
not
every
implementation
can
kind
of
implement
it
with
the
same
semantics,
it
also
does
introduce
kind
of
this
like
asterisk.
In
like
if
it
maps
to
the
same
response,
I
guess
like
location
field,
then
you
should
do
nothing,
but
that
technically
like
how
do
you
define
that
strictly?
In
a
way,
that's
consumable
by
all
the
different
implementations.
G
So
I
think
at
this
point
it
sounds
like
there
is
enough,
like
you
know,
debate
on
it
to
be
had
so
I
think
I'll
probably
go
and
create
an
issue
at
this
point.
I
don't
know
someone
who's
been
around
the
community
longer.
Does
it
make
sense
to
just
create
a
plain
issue
for
that
or
go
into
like
a
gap.
F
G
Discuss
it
and
then,
as
far
as
the
doc
immediately,
I
guess
I'll
remove
that
musk
that
I
added
and
just
like,
leave
it
undefined
in
there
for
now.
So.
A
B
Totally,
I
think
there
was
a
comment
from
brian
that
his
concern
was
that
we're
trying
to
interpret
intention.
I
think
that
some
level
of
interpreting
intention
is
unavoidable
in
this
api.
The
whole
point
of
this
api
is
to
kind
of
like
kind
of
be
a
domain-specific
language
that
takes
your
intention
and
turns
it
into
data
playing
config,
and
so
there's
always
going
to
be.
B
You
want
you
as
opposed
to
needing
to
specify
the
underlying
data
config,
and
I
worry
that
I
guess
what
I'm
trying
to
say
here
is,
I
feel,
like
everybody
is
actually
wanting
not
to
have
a
redirect
loop
and
the
fact
that
there
might
be
a
redirect
loop
is
a
data
plane,
implementation
issue
right
like
and
that
we
should
and
that's
why
we
should
be
like
hey
you,
you
can
specify
this
here
and
if
it
would
produce
a
redirect
loop,
we're
just
going
to
make
it
because
there's
no
reason
why
you
would
want
to
do
that
and
that's
that's
why
I'm
mining
this
one
so
anyway,
we'll
talk
more
about
it
on
the
issue,
but
I
just
wanted
to
sum
up
my
my
view
of
the
conversation.
A
It
yeah
more
discussion
on
issue.
You
know
that
this
feels
like
something
that
if
it
is
currently
unspecified
it,
it
seems
like
something
in
the
future
could
be
added,
as
our
implementation
supports
this
experimental.
A
B
A
G
I'm
not
sure
yeah,
I
mean
like
it's
it's.
I
think
good
at
this
point
as
far
as
like
at
least
api
beta-ness,
and
that,
like
I
don't
think
this
would
require
an
api
change.
It
would
be
like
an
implementation
directive
so,
like
you,
wouldn't
actually
change
any
types
or
anything
you
just
say
like
if
you're
an
influencer,
you
need
to
do
this.
G
I
don't
know
whether
that
truly
falls
into
the
definition
debate
or
not,
but
at
least
it
is
a
distinction
and
then,
like
you
know,
if
we
end
up
like
you
know,
supporting
both
like
a
post
beta
thing
could
be
like
you
know,
by
default,
it
tries
to
protect
you,
but
if
you
expect
the
special
field
to
like
say,
don't
protect
me,
it
will
do
not
that
that's.
I
think
something
that
could
be
definitely
added
after
beta.
B
A
All
right
sounds
good.
I
think
that
is
the
last
bit
for
the
blog
post
and
o500,
and
yes,
we're
down
to
this
one
somebody
added
validating
web
book.
I
think
this
was
matt
right
from
chat.
A
Great
so
yeah,
maybe
a
bit
more
context.
H
Well
so
yeah,
like
everyone
rewind
to
that
first
pause
that
we
had.
Are
we
okay
with
invalidating
webhook
requirement,
and
so
I
was
just
rolling
over
in
my
head?
Are
there
alternatives?
I
know
there
will
be
pushback
who
knows
the
percentage
of
pushback
I've
I've
just
encountered
pushback
from
from
saying
there
must
be
web
hooks,
and
so
then
I
started
thinking
admission
plug-in.
What
are
the
requirements
for
admission
plug-in?
H
Is
it
an
alternative
that
we
could
provide
as
a
road
map
item
and
then
does
the
gateway
api
need
to
be
core
spec
for
for
that
to
be
admitted
into
the
api
server
or
what
or
what
have
you?
And
just
remember
that
you
know
I'm
fresh
off
of
reading
today
about
some
of
the
pod
security
admission
in
pod
security
standards.
So
I
was
kind
of
formulating
the
from
those
impressions.
A
So
here's
my
take
on
it-
I
am,
I
think
everyone
would
love
to
avoid
a
web
hook
if
possible.
It's
kind
of
right
now
feels
like
a
necessary
evil
of
dealing
with
web
hooks
with
with
crds.
A
A
Those
tests
should
not
ever
check
to
make
sure
that
validation
is
coming
from
a
web
hook.
They
should
just
check
that
when
I
try
and
do
this
invalid
thing,
I'm
prevented
from
doing
it
that
that
is
my
strong
preference.
I
know
with
gk
we're
planning
on
bundling
our
that
the
oss
webhook
validation
into
some
other
component
right,
so
it
will
be
the
same
oss
validation
code,
but
it's
not
going
to
have
the
same
deployment
mechanism
as
the
rest
of
you
know
as
what's
bundled
in
oss.
A
I
imagine
that
could
happen
other
places
too.
I
don't
want
to
be
too
opinionated
about
how
or
where
this
is
deployed,
just
that
this
validation
logic
runs,
and
so
that's
why
I
really
like
nick's
idea
here
of
let's
take
some
tests,
build
it
into
conformance
wherever
it
belongs
and
say
these
things
are
invalid
and
I
want
to
make
sure
your
cluster
tells
me
they're
invalid.
Does
that
so
I.
H
I
I
I
I
yeah,
I'm
not
opposed
to
that
at
all
I've,
I'm.
I
like
the
idea
of
having
a
separate
validation
tier,
I'm
just
thinking
about
in
non-controversially
thinking
about.
Are
there
alternatives
that
we
can
provide
people
that
have
particular
requirements
or
have
constraints
that
will
prevent
them
from
easily
adopting
a
web
hook
or
for
implementers
per
se?
That
will
be
adding
something
into
someone
else's
environment
that
they
don't
necessarily
have
control
over
that
then
there's
an
extra
deployment
step
to
say:
hey.
H
This
is
part
of
the
helm
chart,
or
this
is
part
of
the
deployment
spec,
or
this
is
part
of
the
operator
to
add
that
web
hook
in
there.
I
think
that's,
that's.
Those
are
acceptable
steps,
but
they
are
also
non-full
proof
right.
So
for
the
next
implementer
that
comes
in,
you
can
see
a
much
different
expression
of
the
api
because
they
they
fail
to.
They
fail
to
add
that
piece
or
they
fail
to
add
validating
web
hook
now.
Something
that
is
more
foolproof
would
be
an
admission
plug-in.
H
I
don't
understand
that
I
don't
understand
or
know
the
the
machinery
or
the
or
the
road
map
that
could
get
us
there,
but
I
think
that
could
be
something
that
we
think
about
for
the
future,
to
to
maybe
make
this
more
foolproof
and
to
establish
a
better
baseline
of
api
expression
and
implementation.
At
the
same
time,.
B
B
F
F
Having
spent
all
this
time,
our
group
has
kind
of
uncovered,
like
all
the
drawbacks
of
crds,
so
some
of
those
need
to
be
fed
into
the
api
machinery
like
sigs
and
be
like
hey.
You
told
us
to
use
all
these
crds
and
now
we
have
like
this
and
this
and
this
and
this
issue
which
one
of
these
is
like
the
fact
that
this
web
hook
may
or
may
not
be
installed.
H
H
F
A
Yeah,
I
I
think
this
is
worth
discussing
with
api
machinery,
as
I
think
others
have
mentioned.
There
are
other
apis
doing
the
same
thing
we
are,
I
think,
we're
we're
kind
of
the
first,
but
I
know
network
policy
is
coming
behind
us
admin,
network
policy,
subproject
and
then
storage
bucket
is
also
something
that's
coming
from
sig.
A
There
are
other
things
that
are
following
the
blueprint
that
we
have
basically
outlined
here
and
so
we're
going
to
be
the
first
to
run
into
these
issues
at
scale,
but
certainly
not
the
last.
So
if
we're
running
into
these,
we
should
be
making
noise
about
it
and
so
yeah.
I
appreciate
you
calling
that
out
and
if
there
is
some
kind
of
plug-in
mechanism
we
should
start
looking
in
or
if
there
could
be,
we
should
start
looking
into
it
soon.
H
Okay,
so
it
sounds
like
there's
a
lot
to
learn
here.
Definitely
something
I'm
interested
in.
I
will
just
start
researching
and
then
cool.
Let's
let
you
all
know
if
I
figure
anything
out.
Yeah.
A
B
On
the
problems
that
we've
had
with
cids
like
feel
free
to
hit
me
up,
I've
talked
a
bit
about
it
in
tougher
contexts,
but
yeah
like.
I
have
a
lot
of
thoughts
here
about
how
the
experience
of
doing
this
stuff
with
crds
yeah.
But
I
again,
I
think,
to
go
back
to
sort
of
the
the
cool
thing
that
I
don't
think
anybody.
B
On
but
just
for
the
recording,
you
know
like
the
the
key
part
here,
is
that,
like
it's
not
done
yet,
but
it's
definitely
on
my
big
to-do
list
is
to
have
the
the
conformance
for
the
any
gateway
implementation
is
going
to
ensure
that
that
something
doing
the
validation
is
running
and
that
and
the
whole
the
whole
idea
here
is
that
the
validation
will
be
included
in
the
release
bundle.
B
So
if
we
add
new
things,
we
will
add
new
validation
and
so
to
be
conformant
at
gateway,
api
v050,
you
will,
you
have
to
be
running
or
you
have
to
be
doing
the
same
level,
the
same
admission
as
is
included
in
the
v050
upstream
admission
controller
right
like
the
and
that
that's
the
that
sort
of
part
of
the
conformance
and
that
that
that
means
that
the
the
validation
is
also
version
right.
That's
what
I'm
going
to
try
yeah.
A
Cool
great
discussion
actually
jeff
were
you
about
to
say
something:
no,
okay,
any
last
things.
We've
got
like
two
minutes,
so
I
don't
have
time
to
really
open
all
the
pr's
and
issues,
but
is
there
one
or
two
that
I
should
focus
on
specifically.
A
A
Yeah,
I
think
I
think
we've
covered
everything
in
the
milestone
now.
A
B
Yeah,
the
big,
the
big
thing
that
we
need
to
we'll
need
to
move
back
to
once
we've
released
o50
and
everything
sort
of
settles
down
a
bit.
Is
that
we'll
need
to
go
back
and
and
look
at
the
inclusion
delegation
stuff
again,
but
that's
yeah,
we've
yeah!
We
need
to
get
a
050
out
first.
A
We've
got
two
big
gaps:
one
is
inclusion
delegation,
the
other
is
grpc
route
they're,
both
just
I
I
think
they're
approved
and
just
you
know,
waiting
for
o5o
to
get
out
to
unblock
them.
So
I'm
looking
forward
to
get
that
getting
back
into
both
of
those.
C
Yeah,
I
think,
there's
there.
I
don't
think
we're
quite
there
with
the
inclusion
delegation
because
of
some
assumptions
I
made
about
you
know
you
know
what
the
applied
configuration
is
versus.
What's
the
config
configuration,
so
I
definitely
need
more
people
to
review
it,
because
I
think
we
may
end
up
needing
to
change
some
things
in
order
to
allow
people
to
to
to
to
match
the
constraints.
The
some
of
the
different
implementations.