►
From YouTube: SIG Network Gateway API Bi-Weekly Meeting for 20220829
Description
SIG Network Gateway API Bi-Weekly Meeting for 20220829
A
All
right,
it
is
august
29,
2022,
welcome
to
the
gateway
api
community
meeting.
We've
got
a
few
things
on
the
agenda
today
to
get
through
a
lot
related
to
status,
some
supported
versions,
things
and
also
a
couple
gaps
thanks
to
everyone
who
made
it
out
just
a
few
reminders
before
we
get
started
one.
This
is
a
kubernetes
community
meeting,
which
means
we
follow
the
kubernetes
code
of
conduct.
Among
many
things,
that
includes
just
be
nice
to
each
other.
Nothing
too
crazy.
A
Also.
We
want
this
to
be
open
to
anyone
to
participate,
feel
free
to
ask
questions,
say
anything
at
any
point
and
definitely
add
things
to
the
agenda.
If
you
see
something
like
that,
you
would
like
to
discuss
that.
Let's
get
going
first
up
next
week
is
a
u.s
holiday
for
many
of
us
that
are
based
in
the
us,
and
so
I
know
I
won't
be
at
a
community
meeting.
A
I
would
suggest
that
we
cancel
the
next
meeting
if
anybody
wants
to
be
around
they're
welcome
to
meet,
but
barring
that
I
think
I'll
go
ahead
and
cancel
anyone
opposed
all
right,
I'll
run
with
that.
Next
up,
I
think
we've
got
nick
nick
made
a
lot
of
progress
on
this
conditions
and
status
work.
I
thank
you
for
taking
the
time
to
try
it.
I
know
it
had
kind
of
been
circling
and
we
we
had
a
bunch
of
different
issues
and
so
trying
to
summarize
it
is
a
monumental
task.
A
So
thank
you
for
taking
that
one
on.
I
don't
know,
do
you
want
to
run
through
any
part
of
that
discussion
here.
B
Yeah,
I
think
so,
if
you
scroll
down,
if
everyone
could
have
a
look
at
this,
I
won't
go
through
the
specific
things
now,
but
I
do
want
to
go
over
the
general
things.
B
B
B
If
we're
gonna,
I
think
if
we're
gonna
have
attached,
we
should
lean
into
attached
and
say,
like
you
know,
that
gateway
is
attached
to
the
gateway
class,
that
they're
a
part
of
right
and
so
then
the
cloud,
the
the
condition
on
the
gateway
that
says
this
has
been
accepted
by
the
gamer
class
shouldn't
be
accepted.
It
should
be
attached
because
it's
and
that
way
it's
using
the
same
concept
over
and
over
again,
like
I'm,
not
I'm
not
100
percent.
Weird
to
that
one.
C
B
C
B
So
I
think
that
we
really
need
to
get
this
done
as
soon
as
possible,
get
it
synchronized
and
harmonized
across
everything
and
yeah,
and
I
think
the
other
stuff
that
I've
got
in
there.
I
think
that
yeah,
we
should
definitely
mandate
the
use
of
observed
generation.
Now
I
think
I've
talked
about
this
in
some
other
stuff
before,
but
every
kubernetes
object
has
a
metadata
generation
field
that
is
auto-incremented
by
the
api
server
when
the
spec
is
changed.
B
So
every
time
you
change,
the
spec
generation
field
gets
incremented
and
if
anything,
changes
the
spec
so
having
the
conditions,
struct
has
a
field
called
observe
generation
which
is
intended
to
be
used
for
any
time.
You
put
an
update
to
the
condition
in
there.
You
set
the
observed
generation
field
to
the
generation
at
the
time
that
you
saw
the
resource.
What
that
means
is
if
the
resource
is
changing
rapidly
or
if
it
change.
B
You
know
it
means
that
there's
a
stat
built
in
stillness
check
on
the
on
the
condition,
and
so
I
think
that
the
only
reason
I
I
think
I
haven't
confirmed
this
by
checking
with
api
machinery,
but
I
think
the
only
reason
that's
not
mandatory
is
that
it
wasn't
mandatory
to
start
with,
and
you
know,
and
nobody
wants
to
go
back
and
change
such
a
core
part
of
the
api,
because
that's
painful
for
like
no
not
really
much
gain,
but.
B
Not
to
use
it
the
other.
C
B
B
They
are
true
in
the
happy
case
that
are
summary
conditions
that
tell
you
you
need
to
look
at
something
else
on
the
resource
or
go
somewhere
else
to
get
more
information,
so
you
should,
by
checking
those
two
things
you
should
know
if
the
resource
that
you
control
is
like
reconciled
to
by
the
controller
and
then
if,
if
it
is
ready
to
pass
traffic
ready,
has
a
whole
bunch
of
issues
really
has
a
whole
bunch
of
issues,
but
that
we
need
to
also
discuss.
A
I
just
one
question
related
to
all
of
this.
I
I
appreciate
and
agree
with
your
idea
of
observed
generation
here
as
like
something
like
we
should
enforce,
probably
having
conformance
etc.
A
One
of
the
things
that
I
don't
think
we've
ever
provided
consistent
guidance
on
is
what
we
do
on
those
kind
of
intermediate
updates
of
a
route
was
programmed.
We
updated
the
route
and
then
it
needs
to
be
programmed
again.
Just
you
know
like
let's
say
we
have
a
programmed
condition.
Is
that
something
we
say
should
say,
stay
true
and
just
not
increment
observe
generation
until
it's
true
again
with
the
new
observed
generation,
or
do
we
go
true
false
true.
B
And
you're
saying
so,
you're
saying
you
you
have
you:
have
you
have
a
route
that
is
that
has
been
reconciled
or
you
know
attached
or
whatever,
and
it's
it's
successful,
everything's
good
make
a
change
to
that
route
and
then
the
and
then
you
take
and
then
you
need
to,
does
it?
Does
it
flip
back
to
false
while
like
while
you,
while
you're
in
the
process
of
making
the
change,
is
that
right,
yeah
yeah?
B
So
I
think
I
think
that
it's
one
of
those
things
where
we
almost
need
to
define
it
in
sort
of
time-based
terms
and
say
if
it's
longer
than
this
time,
you
need
to
do
it.
You
don't
want
to
do
too
many
updates
to
the
api
server
for
no
reason,
but
at
the
same
time,
if
it's
going
to
take
five
minutes
to
for
the
infrastructure
to
be
provisioned,
then
you
kind
of
want
to
know
that
it's
been
accepted
so,
like
I
think
it's
almost
like.
B
D
A
B
Yeah
so
yeah
like
I
said
this
like,
as
you
have
said,
there's
a
lot
there's
a
lot
to
this.
If
you
have
a
look
at
that,
the
spreadsheet
that
I
linked
down
the
bottom,
I
sort
of
went
through
every
resource
and
every
condition
and
every
reason
like
what
is
this
for
like
like
mike,
did
earlier
yeah,
and
so
I
think
you
know
there's
quite
a
few
questions
in
there.
You
know.
Should
this
be
changed
yeah,
so
I
saw
yeah
and
yeah.
B
I
really
appreciate
what
you
did
before
mike.
It
really
got
me
started
on
thinking
about
this.
I
think
we've
actually
done
a
lot
of
what
you
had
listed
in
that
original
that
original
issue,
but
yeah
the
more
that
we've
done.
The
more
I've
realized.
That's
the
more
I've
noticed
the
stuff.
B
That's
not
done
keith
to
answer
your
question
in
the
chat:
there's
no
strong
guidance
around
positive
polarity
conditions
versus
negative
polarity
conditions
when
we've
asked
api
machinery
before
they've
sort
of
been
like
nope
we're
not
making
any
statements
about
that
right.
So
the
you
it's
my
my
personal
opinion
is
that
you
should
have
a
small
number
of
positive
polarity
conditions
to
serve
as
like
flags
that
you
can
check
to
tell
you
obvious
things.
Ideally,
it
should
be
one
probably,
but
I
think
our
api.
B
Enough
that
we
probably
need
to
just
to
tell
the
difference
between
config.
D
D
B
Yeah,
I
think
it's
kind
of
it's
a
little
funky,
because
the
thing
that
that
need
a
lot
of
the
time,
the
thing
that
we
should
be
updating
the
ready
status
is
the
thing
that
should
be
managing
the
other
conditions
as
well
mm-hmm.
So
so,
like
it's
going
to
be
what
it
did,
the
conditions
are
not
really
for
the
controller
to
do
generally
they're
they're
for
people
therefore
they're
for
humans
to
look
at
rather
than
to
be
programmatically
consumed
in
the
past.
B
D
So
we,
in
fact
like
should
not
do
that,
because
I
think
we
have
at
the
moment
some
stuff,
like
you
know,
basically
like
generate
all
the
like
inspect
all
the
possible
error
conditions
first
and
add
them
to
the
condition
list
and
at
the
end,
go
through
those
to
say
like
okay
is
anything
blocking
me
from
becoming
ready?
If
no,
then,
I'm
ready,
if
not,
then.
B
B
One
thing
that
rob
and
I
have
sort
of
disagreed
a
bit
about
on
is
like
if
we
should
add,
if
we
should
mandate
that
all
of
the
conditions
are
added,
I
tend
to
lean
in
the
case
that
all
of
the
conditions
should
always
be
present,
because
that
means
that
you
can
always
know
the
full
status
of
the
resource.
B
That's
how
the
core
kubernetes
ones
work
like.
If
you
look
at
node,
it
has
a
ready
condition
and
then
a
bunch
of
specific
error
conditions
like
there's
a
problem
with
docker
there's,
not
enough
memory.
You
know
those
sort
of
things,
and
so,
if
any
of,
if
any
of
those
are
true,
the
ready
one
is
going
to
be
false,
but
you
have
the
ready
one
to
be
like
do.
I
need
to
look
more
at
this
node
and
so.
B
Here
are
from
stuff
like
mode
and
pod,
about
where
the
conditions
I
feel
work
pretty
well.
A
Yeah
and
to
clarify
I'm
not
necessarily
against
conditions
always
being
present.
What
I'm
against
is
negative
conditions
always
being
present
where
you
have
this
double
negative
in
your
healthy
state
of
you
know
like
unhealthy,
equals
false
as
a
condition,
and
that
just
doesn't
feel
right
to
me
yeah,
but
that's
rather
arbitrary.
B
B
I
I
think
the
for
the
positive
polarity
conditions
is
really
important,
as
mike
mentions
that
we
have
the
the
like
the
positive
polarity
ones,
but
I
think,
as
it
all
comes
down
to
the
naming
right
like
it
all
comes
down
to
like
if
the
names
of
the
negative
polarity
conditions
are
some
error
is
present
like
you
like.
I
think,
and
the
error
is
very
clear,
like
I
think,
detached
false
is
like
a
bit
weird
because
it's
a
very
clear
way,
better
way
to
say
detached
false,
which
is
attached
true,
right
like
but
but
like.
B
B
Yeah
so-
and
I
I
think
keith
you
mentioned
about
yeah
yeah,
I
think
conflicted
is
one
the
way
that
it's
yeah
it's
hard
you
mentioned
about
yeah,
I
would
say,
be
extremely
careful
about
using
conditions
as
a
state
machine.
The
read
go:
go
and
read
the
section
and
api
conventions
on
on
conditions
like
four
or
five
times.
B
It's
very
pithy,
it's
a
bit
difficult
to
pass,
but
it
is.
It
has
so
much
pain
and
suffering
distilled
into
that
into
those,
for
you
short
paragraphs
that
I
think
is
really
worth
like.
Take
it
and
make
it
part
of
you,
man.
E
B
But
I
do
think
that
doing
something
about
this
should
block
o60
and
trying
to
clean
this
up
as
far
as
possible,
because
it's
going
to
be
a
breaking
change.
We
only
want
to
do
when
I
minimize
the
number
of
ranking
changes
so
I'll,
be
spending
a
bunch
of
bandwidth
on
trying
to
tidy
this
up
and
get
something
sorted
out
here
in
terms
of
the
next
steps.
B
I
kind
of
posted
that
initial
summary,
because
I
just
wanted
to
get
some
people
to
plus
one.
You
know
some
of
the
things
and
tell
me
if
any
any
of
that
stuff
is
way
off.
If
everyone's
in
agreement
with
the
general
stuff,
I
will
start
the
process
of
writing
up
a
gap.
A
small
gap
may
not
be
that
small
but
I'll,
but
in
that
gap
I'll
be
that
I'll
be
very
specific
about
the
changes
I
want
to
make
like
I'll
have
the.
I
think
we
should
do
this
in
general.
B
The
you
know
we
need,
like
you,
know,
stuff
like
we
need
to
change
detached
to
attached
and
we
need
to
do
this,
and
this
field
needs
this
updated
and
this
fields,
and
is
this
updated
so
that
there's
a
big
to-do
list
of
stuff
to
do
so?
Then
we
can
burn
it
down
as
quickly
as
possible.
So
I
think.
C
B
A
Without
opening
up
too
much
of
a
rabbit
hole
here
as
far
as
the
transition
plan,
you
know,
I
think
what
we're
proposing
here
is
adding
new
conditions
and
eventually
removing
some
of
the
existing
ones
like
replacing
or
renaming
some
of
the
conditions
that
exist
today.
B
I
don't
know
I'm,
I
kind
of
I
mean
part
of
me
kind
of
says
it's
gonna.
What
what
we
do
is
gonna
break
implementations
anyway.
It
may
be
better
to
have
a
hard
break
and
be
like
guess
what
there's
no
getting
around
you've
got
to
update
these
things
to
to
be
conformed.
You
just
got
to
go
and
update
them
now
like
like
it
like
it,
sucks
absolutely,
and
I
I
feel
bad
about
doing
that,
but
I
feel
like
it's.
B
If
we
don't,
it's
like
all,
we're
doing
is
pushing
that
can
like
one
release
down
the
road,
rather
you're
gonna
have
to
update
you're
gonna,
have
to
make
things
and
also,
if
you
think,
about
how
to
confirm
how
to
write
the
conformance
tests.
How
are
we
going
to
write
the
conformance
test
to
be
conformant
if
we
don't
have
only
one
way
to
set
the
status
right?
That's
that's
going
to
really
suck
for
the
conformance
tests.
A
Yeah,
I
know
to
clarify
what
I
was
suggesting
was
to,
and
I
don't
even
know
I
was
suggesting
it,
but
specifically
to
still
have
conformance
tests
just
check
for
the
new
conditions
that
we
recommend,
but
somewhere
in
the
documentation,
implementation
guidelines
say
you
may
want
to
also
set
this
old
thing
for
anyone
that's
going
through
the
upgrade
process.
I
don't
know
if
it's
worth
that
effort.
B
About
that
and
leave
that
up
to
implementation,
orders,
yeah
and
say
like
this.
C
E
A
Cool
all
right,
thank
you
again
for
taking
this
one
on
looking
forward
to
gap
on
this
one
yeah.
Is
there
any
additional
feedback
or
help
you
could
use
from
us
between
now
and
again
or.
B
Yeah,
if
people
could
just
have
a
look
over
that
that
big
comment,
I
know
it's
a
big
comment,
but
if
there's
anything
that
you
don't
like
like
in
this
case,
I'm
gonna
take
silence
or
lack
of
comments
as
complete
agreement
with
what
I've
written
there.
So
if
you
don't
like
that,
then
you
better
say
something:
it's
what
I'm
saying,
because
otherwise.
B
B
So
I
really
there's
not
we're
burning
time.
You
know
the
time
is
ticking
before.
A
I
I
wanted
to
ask
a
couple
follow-ups,
one
on
reference
grant.
I
remember
seeing
this
and
then
I
forgot
to
follow
up
on
it,
but
you
suggested
a
condition
on
reference
grant
and
reference
grant
is
one
of
those
confusing
resources
that
doesn't
have
a
clear
owner
it
like,
if
we
add,
condition
there,
who
publishes
who's
responsible
for
writing.
That.
B
E
B
The
reference
grant
is
granting
reference
access
to
right
and
but
the,
but
I
think
it
should
be
the
condition.
The
the
controller
that
is
implementing
the
reference
grant
needs
to
you
know
needs
to
mark
that
condition
as
syntactically
valid
or
like
you
know.
Yes,
this
is
referring
to
a
kind
that
I
support.
C
B
You
know
or
something
like
that.
That's
that's
the
main
thing
there
is.
It
just
needs
to
have
a
space
for
you
to
say
this
is
going
to
work
right
like
and
you
don't
otherwise.
The
only
way
that
you're
going
to
know
whether
or
not
the
reference
grade
is
doing
anything
is
by
sort
of
poking
at
things
and
seeing,
if
you
know,
is
by
other
conditions
on
other
non-related
resources
right
like
otherwise
the
only
way
you're
going
to
know
the
reference
point
of
work
for
a
secret
is
working.
B
B
A
B
A
Would
this
be
another
like
controller
name,
name,
space
thing
where.
A
B
E
B
To
ensure
that
it's
that
the
condition
stuff
is
safe
is
that
its
namespace
by
controlling
unfortunately
yeah
like
it,
would
be
nicer
if
there
was
another
way
to
do
that.
But
I
don't
think
there
is
in
our
use
case.
A
B
You're
right
that
it
needs
to,
we
need
to
ensure
that
that
stuff
is
there.
It
also,
it
does
feel
like.
There
are
kind
of
a
lot
more
things
piling
up
where
it's
feeling
increasingly
to
me
like
we
need
a
dedicated,
implementer's,
guide
kind
of
page.
That
has,
you
know
extremely.
A
E
Yeah
my
concern
was,
I
came
in
halfway,
so
maybe
it's
the
actual
message,
but
it
sounds
like
you're
saying
that
for
all
gaming
classes
within
one
controller,
they
need
to
report
status.
The
same
way.
A
Within
one
controller,
so
this
is
in
the
context
of
reference
grant
and
the
idea
of,
if
we
add
conditions
to
reference
grant,
how
do
we
name
space?
That
and
the
idea
was
we
throw
in
controller
name
on
condition,
and
my
comment
was
we
just
need
to
make
sure
that
anything
that
is
shared
under
a
single
single
controller
name
is
guaranteed
to
have
the
same
understanding
of
that
resource
or
any
resource
like
that.
E
D
A
No
you're
right.
I
need
to
double
check
in
how
we
represent
our
controller
name.
I
can't
remember
if
we
have
two
separate
ones
or
one.
There
are
two
underlying
controllers.
E
E
A
Cool
okay,
I
think
that's
it
for
this
one,
any
last
thoughts.
A
All
right
I'll
move
on
next
one
is
mine,
just
going
back
to
the
supported
versions.
Discussion
from
before
this
is
one
where
I
again.
Actually
this
is
related
to
gke.
Oh
everything
has
been
resolved
cool,
but
there
was
a
discussion
here
about
a
proposal
I
had
to
commit
to
supporting
the
most
recent
five
kubernetes
versions
in
kubernetes,
minor
versions.
A
Rationale
for
that
is
I
we
already
discussed
this
in
the
last
meeting,
so
I
don't
want
to
go
too
far
into
it,
but
the
rationale
was
really
just
trying
to
provide
a
consistent
experience
and
ensure
that
we
don't
we
don't
go
back
to
that
same
painful
transition
that
we
had
from
ingress,
v1
beta
1
to
ingress
v1,
basically,
where
you
can
have
one
controller
that
supports
the
latest
api
and
supports
the
vast
majority
of
kubernetes
users
yeah.
A
It
seems
like
we
have
gotten
some
consensus
here
more
recently
over
the
past
few
days
towards
supporting
five
versions,
but
I
know
that
was
somewhat
controversial
in
the
last
meeting,
so
I
wanted
to
bring
this
back
up
again
and
give
anyone
a
chance
to
voice
any
hesitation
towards
this.
This
is
a
big
commitment
that
affects
the
future
of
the
api,
any
decision
we
make
here
we
could
regret
in
the
future.
A
Like
shane
mentioned,
it
is
harder
to
go
down.
You
know
like
once
we
say
we're
going
to
support
five
versions.
It's
going
to
be
pretty
difficult
to
say
in
the
future.
Oh
actually,
we
only
want
to
support
three,
so
just
throwing
that
out
there.
A
I
think
this
is
something
that
reflects
the
reality
of
kubernetes
today,
the
reality
of
where
users
are
and
also
you
know
what
I
referenced
a
few
popular
ingress
implementations
that
are
supporting
five
or
more
kubernetes
versions
today,
and
I
think
there
are
more
that
I
didn't
reference,
but
anyways
any
any
thoughts
or
hesitations
here.
B
A
B
Oh
okay,
so
michael
t
were
originally
in
there,
the
lts
working
group.
It
took
us
a
long
time
to
agree
that
three
was
a
good.
It
was
a
good
policy
for
upstream,
and
so
I
was
like.
Why
do
something
different
upstream?
Three
should
be
good
enough
for
anyone
famous
last
words,
the
and
so
but
yeah.
I
think
rob's
point
about
the
fact
that
you
know
having
the
crds
not
be
too
dependent
on
version
on
the
versioning
sort
of
means
that
we
can
say.
C
B
We
support
five
and,
but
practically
it'll
probably
be
much
more
than
that.
It'll
work
on
on
many
versions,
the,
but
the
the
reason
for
it
to
have
a
line
in
the
scene
at
all
is
so
that
if
the
crd
spec
itself,
not
the
spec
that
we
write
for
our
crds
but
the
spec
for
the
custom
resource
definition,
resource
gets
updated.
Then
that's.
B
This
is
how
long
we're
gonna
have
to
wait
before
we
can
start
using
before
we
can
start
using
that
stuff
and
the
the
big
feature
here
is
the
cell,
the
evaluation
language
that
can
basically
replace
a
lot
of
the
logic
that
we
have
in
the
web
hook.
It
would
be
really
nice
to
be
able
to
to
how
to
use
this.
B
You
know
without
having
to
have,
and
that
would
mean
that
we
may
not
need
to
have
an
ambition,
workload
anymore,
which
would
be
great
right
like
much
easier
people
have
people
not
have
to
do
that,
but
but,
as
rob
says
you
the
as
the
as
the
cl
the
presence
of
the
ceo
stuff
in
the
crd
sort
of
ages,
then
we
should
eventually
we
should
be
able
to
adjust.
We
should
be
able
to
implement
it
in
a
safe
way.
B
Once
the
that
sort
of
five
period
has
has
happened,
then
we
can
just
start
flipping
things
over
and
pulling
code
out
of
that.
It
just
means
we've
got
to
wait,
you
know
which,
at
the
end
of
the
day
for
a
spec
like
this
is
not
the
end
of
the
world
in
you.
I
think
we're
we
do
want
to
minimize
the
braking
changes.
So
that's
why
I
was
persuaded
in
the
end,
even
though
I
was
very
strongly
three
versions
of
stuff.
E
A
I
I
realized
after
and
I
appreciate
that
that
feedback
I
realized
after
I
hadn't
heard
anything
from
anyone
on
the
gamma
side
any
of
the
gamma
maintainers,
and
this
could
affect.
A
E
I
think
I
I
saw
a
point
in
the
pr
about
supporting
more
kubernetes
versions,
means
we're
able
to
only
support
the
latest
version
of
spec
and
that's
that
that's
a
pretty
big
win.
E
In
my
opinion,
I
I
was
also
in
the
three
versions
camp
previously,
but
I
think
once
I
saw
that
point,
I
kind
of
moved
over
to
the
to
the
five
side,
because
once
you're
making
that
compromise,
you
can
be
a
lot
more
strict
about
merging
the
spec
and,
speaking
from
the
gamma
use
case,
I
I
like
the
potential
of
that
to
be
able
to
to
iterate
on
on
the
spec
with
personal
gateway
api
and
whatever
we
figure
out
with
gamma
and
not
have
to.
E
You
know,
have
that
traditional
n
minus
two
version
support
and
be
able
to
just
kind
of
with
the
compromise
truck
here.
So
I
change
that's
mine,
that's
my
personal
opinion.
A
Great
yeah
that's
good
to
hear,
and
I
should
give
a
little
bit
more
background
on
that
idea,
because
it
is,
it
is
key.
The
idea
of,
if
we
support
five
trailing
kubernetes
versions.
What
that
means
for
at
least
gke
is
that
we
can
say
when
a
new
version
of
api
is
out.
We
can
just
roll
it
out
to
our
fleet.
A
We
don't
need
to
say
this.
You
know
stable,
channel,
regular
channel,
etc.
Has
this
older
version
of
api
and
then
our
controller
needs
to
support
this
wider
range?
We
just
say
this
version
is
out
it's
on
our
fleet,
and
it's
done
so
that's
really
compelling,
and
I
imagine
that
will
be
the
case
for
many
other
kubernetes
platforms,
users,
etc,
and
so,
although
it
does
mean
it's
slower
for
us
to
adopt
compelling
new
things
like
ceo,
I
think
it's
a
net
win
in
terms
of
simplicity,
to
adopt
and
implement
this.
A
Okay,
I
will
take
that
as
good
to
go.
If
I
can
remove
the
hold
on,
I
don't
think
I
added
a
hold
on
this
one,
so
I'll
remove
that,
and
if
anyone
feels
like
adding
an
lg
dm,
we
can
go
from
there,
but
I
think
we're
good
to
go
on
this
one.
A
Okay,
next
one
is
back
to
neck
back
end
properties.
B
Oh,
not
this
guy,
again,
okay,
so
yeah,
I
basically
I
just
wanted
to
call
out.
I
think
this
one's
actually
pretty
close,
I
think,
mark,
had
some
sort
of
good
comments
about
how
you
remember
to
keep
into,
to
take
into
account
the
you,
the
the
camera
distinction
between
the
front
end
and
the
back
end
of
the
service,
but
I
think
I
think
I
have
been,
as
I
said
there.
B
I
I
think
that
the
the
ingress
usage,
the
english
gateway
api
usages,
basically
only
only
really
think
talk
about
the
back
end
of
the
service.
They
don't
need
the
front
end,
because
the
routes
are
the
front
end
right,
like
the
the
routes.
B
But
that's
the
only
thing
that
you
care
about
in
terms
of
naming
and
that's
the
point
of
the
rest
of
the
gateway
api,
and
so
you
know
like
I
I
mean
if,
if
I
think
maybe
I
just
need
to
rewrite
the
y
section
to
sort
of
make
it
clear
that
this
is
all
about
the
the
stuff
that
the
english
that
the
ingress
needs
and
the
stuff
that's
tightly
bound
to
the
back
end.
B
B
Yeah
so
shane
sort
of
mentioned
that
he
would
prefer
to
merge
this
one
as
provisional
and
then
come
back
and
change
it
later.
That's
kind
of
where
I
am
too,
but
I
will
do
a
quick
pass
over
the
over
the
y
section,
I'm
just
to
make
sure
that
I've
made
clear
that
this
is
talking
about
the
so.
B
So
the
the
load
balancing
example
I
need
to
make
clearer
because
it
actually
that
the
reason
I
included,
that
is,
that
it's
a
very
critical
distinction
in
my
mind,
is
that
when
you're
talking
about
load
balancing
properties,
there
are
two
places
in
which
you
want
to
set
load,
balancing
properties
on
the
front
end
and
on
the
back
end
right,
like
yeah
and
in
the
case
of
the
front
end
for
the
for
the
ingress
gateway
api.
That
front
end
is
effectively
at
the
route
level
you
want
to
be
able
to.
B
You
know
you
want
to
be
able
to
load
balance
between
routes
or
between
rules
and
routes,
as
opposed
to
the
back
end
one,
which
is
that
when
you
actually
make
a
decision
to
route
to
a
back
end,
you
need
to
know
which
endpoint
out
of
that
back
end
to
be,
and
so
there
are
different
places,
and
there
are
reasons
why
you
might
want
to
have
different
load,
balancing
algorithms
at
different
levels,
but
the
ones
that
we're
talking
about
in
this
are
the
ones.
How
do
you
pick
an
endpoint
out
of
a
set
of
endpoints?
E
Back
ahead,
no
I'm
done
I
I
I
agree
with
that
clarification
and
in
general,
I've
read
this.
This
I'm
not
sober,
but
I
tend
to
agree
with
shane
as
well.
Not
nothing
here
seems
to
be
too
objectible
and
would
love
to
see
this
get
merged
and
work
on
some
more
of
the
implementation
details
because
being
like
selfishly
from
a
from
a
gamma
perspective.
E
That's
where
I'm
really
interested
to
see
what
the
kind
of
what
the
parity
is
going
to
be
between
what
we're
talking
about
with
like
service
binding
and
the
spec
and
properties,
there's
a
lot
of
stuff
to
figure
out
there,
but
yeah
at
a
high
level.
All
this
sounds
good
to
me.
A
Yeah,
I
just
echo
what
others
have
said
here.
I
think
this
is
just
about
good
to
go
being
well,
I
mean
anyone,
I
think,
would
add
an
lgtm
to
this.
I
think
you
just
want
to
do
one
more
round
of
of
cleanup
and
then
I
think
any
of
us
will
lgtm
it.
B
Cool
I'll
I'll,
bring
you
to
the
channel
or
something
when
I'm
done
with
the
round.
B
Or
you
can
just
check
it
tomorrow,
your
time
if
you
check
tomorrow,
first
thing
when
you
come
in,
I
should
do
that.
A
Okay,
next
one
is
we're
on
to
triage
now
cool,
so
I
wanted
to
cover
this
gap.
We
ran
out
of
time
last
week,
but
this
is
sam's
car.
I
believe
they're
kept
on
response.
Header
filtering
well,
a
header
for
response
filter
for
response.
Headers
get
there.
It
seems
very,
it
seems
like
this
is
in
a
really
similar
state
to
others
as
well
and
in
the
sense
that
this
is
awfully
close
and
there's
nothing
terribly
controversial
left
in
this
one
I
sanskar
asked
in
slack
earlier.
A
I
think
it
was
yesterday
my
time
at
least
a
couple
things
that
have
come
out
of
this
that
are
kind
of
broader
issues.
One
is:
can
we
do
this
at
a
higher
level
like?
Can
we
do?
I
think
candace
might
have
raised
this
specific
feature
request,
but
can
we
just
say
I
want
all
responses
within
this
namespace
or
from
this
gateway
or
whatever
to
have
this
header
added
or
removed
or
whatever
it
is.
This
has
a
section
in
the
proposal,
but
it's
probably
something
that
could
be
a
separate
gap.
A
I
tend
to
agree.
I
think
mike
mentioned
in
slack
as
well,
that
this
is
just
something
that
can
be
a
future
gap
future
work.
It
doesn't
need
to
block
this,
the
other
one
I'm
less
familiar
with.
I
think
this
was
also
a
feature
request
from
candace
and
I
didn't
completely
understand
it
in
a
bit
that
I
looked
at
it,
but
I
think
it
was
the
idea
to
conditionally
modify
it's.
This
comment,
anyways
yeah,
so
if
it's
maybe
candace,
you
can
probably
explain
it
better
than
I
can.
C
Do
I
remember
this?
Well,
I
think
this
had
to
do
with
if
we
wanted
a
value
to
be
returned
that
was
dependent
on
some
activity
that
happened
in
the
back
end,
so
not
a
hard-coded
value,
which
is
the
you
know.
That's
that's
what
he's
doing
here
as
a
hard-coded
value,
but
a
value
that
was
determined
by
something
happening
at
the
back
end.
B
C
B
C
D
D
Is
there
essentially
like
some
side
channel
the
proxy
has
to
the
specific
back-end
application
that
I'd
be
able
to
use
to
infer
that
value,
because
outside
like
headers
in
the
body
and
like
the
body
gets
into
a
whole
other
mess,
I'm
not
really
seeing.
Where
else
we
like
get
the
additional
values
from.
B
So
yeah
I
mean
unless,
unless
you're
talking
about,
are
you
talking
about,
say?
Okay,
backend
says
something
in
its
response.
The
response
goes
through.
The
proxy
hits
the
client.
The
client
sends
something
back
in
its
request
and
then
like
on
the
second
turn
around.
You
use
something
about
some
some
part
of
that
loop
to
set
another
one
like,
but
it
feels.
C
B
As
travis
said
like
it
feels
like
to
me
the
only
place
where
you
have
to
communicate
that
information
is
the
headers
in
either
the
request
or
the
response
direction,
but
yeah.
B
I
don't
like
I'm
not
sure
where
you
could
take
that
variable
from
in
general,
we've
tried
to
make
the
resources
completely
independent,
so
you
can't
like
set
a
variable
in
a
gateway
and
have
it
accessible
in
the
in
the
route,
because
the
because
you
want
the
the
route
to
be
able
to
attach
to
any
old
gateway
that
may
or
may
not.
C
If
someone
developed
the
application
separately
and
someone
developed,
you
know
in
someone
specified
the
filters
separately
or
or
if
let's
say
that
the
application
developer
doesn't
have
responsibility
or
doesn't
have
access
to
change
the
filters.
C
How
would
they
then
be
able
to
get
programmatic
information
back
in
a
response
header
this
would
this
would
make
it
so
that
they
couldn't?
I
was
actually
expecting
there
to
be
a
way
to
programmatically
change
this
based
on
something
that
would
happen
and
based
on
activity
in
in
the
application.
On
the
back
end,
I
was
surprised
to
see
it
hard-coded
here
to
tell
you
the
truth.
B
E
Isn't
it
I?
I
could
be
missing
some
of
the
nuance
here,
but
it
seems
like
it's
fairly
common
in
apis
to
allow
variables
in
headers.
I
know
envoy.
Has
it,
for
example,
I
send
a
link
there.
I've
seen
google
load
balancer,
has
it
as
well
and
in
these
cases
they're
really
just
doing
like
a
variable
interpretation
of
you
know.
I
mean
in
onboard
this
case.
It's
these
percent
sign
things.
I
think
it's
a
different
format
in
google,
for
example.
E
E
That
does
sound
kind
of
scary
because,
like
we're
saying
that
they
could
set
whatever
header
they
want,
but
at
the
same
time
like
it
also
is
pretty
straightforward.
If
you,
you
know
obviously
onward
implementation,
they
would
set
this.
You
know
if
you
see
downstream
remote
address,
replaced
with
the
downstream
remote
address,
just
an
idea.
If
we
wanted
to
do
that-
and
we
actually
already
do
that
he's
just
we
if
we
don't
want
to
do
that,
we
should
say
that
don't
do
that.
A
Is
is
this
the
kind
of
thing
that
you
were
describing
it
just
you
know,
and
no
one
header
value
and
you
just
want
to
interpolate
it
with
some
kind
of
variable
type
thing
like.
Is
that
yes,
okay,
that
so
I
I
know
the
same
thing,
you
know
this.
This
kind
of
thing
is
broader.
A
You
know
it
can
be
used
for
matching,
it
can
be
used
for
a
variety
of
things,
and
I
think
to
me
this
feels
like
something
that
is
not
completely
prevented
by
this
get
you
like
it
feels
like
future
extension,
could
work
to
add
this
kind
of
capability
yeah.
Thank
you
for
that
this,
this
reference
that
that
that
helps,
I
don't
know
any
any
other
thoughts.
A
C
I
think
it
could
be
added
in
the
future,
but
I
think,
like
john
mentioned,
that
we
could,
we
could
say
that
it's
being
added
being
considered
for
the
future
and
not
possible
in
this
release.
E
E
I
don't
I
don't.
I
haven't
gathered
that
from
my
right
so
far,
but
if,
if
there's
not
anything
explicitly
preventing
that,
then
I
feel
like
I
might
not
be
wrong,
but
I
feel
like
that's
probably
implementation
specific.
Like
john
mentioned
the
envoy
nginx
google,
whichever
your
proxy,
can
have
those
kinds
of
behaviors
that
users,
if
they're
tied
to
that
proxy
gateway,
whatever
they
can
utilize
that
functionality
and
then
the
spec
of
api
can
modify
the
behavior
at
a
future
time.
E
But
if
this,
if
the
gap
as
it
stands
does
prohibit
that
behavior,
then
technically,
like
john
nominal,
implementations
may
be
like
non-conforming
kind
of
by
accident.
So
I
do
think
that
if
we
just
need
to
make
sure
that
the
get
is
prohibited,
we
probably
are
in
a
pretty
good
spot
to
come
back
later
and
codify
the
exact
behavior.
No,
it's
my
perspective
anyway.
A
B
B
It
does
make
a
bit
of
an
any
pattern
in
that
it'll
mean
that
there's
a
big
gotcha
if
you
move
from
a
gateway
implemented
by
envoy
to
a
gateway
implemented
by
another
proxy
that
doesn't
support
the
percent
encoding
and
you're
using
the
percent
encoding
for
setting
those
values,
then
you
would
end
up
screwed
but
yeah,
but
like
it
makes
it
seems
like
the
the
idea
of
programmatically
setting
the
value
of
a
header
at
the
proxy
layer
based
on
the
value
of
some
other
header
is
pretty
common,
like
you
know,
pretty
much,
I
think
most
most
proxies
have
the
ability
to
do
that,
and
so
I
guess,
is
that
that
feels
to
me
like
it
might
be.
B
Why
you're
a
bit
surprised
candice
is
that
most
of
the
proxies
could
do
it
already.
Why
would
we
not,
and
so
I
think
in
my
mind
the
in
my
mind-
I've
generally
tended
to
er
on
the
side
of
let's,
let's
be
specific,
and
but
I
think
in
this
case
it's
probably
fine.
It's
just
that.
B
C
A
While
we're
on
this
gap,
are
there
any
other
things
we
should
talk
about?
I
tried
to
read
through
a
lot
of
this
feedback,
but
there
are
a
lot
of
comments
and
I've
likely
missed
some.
So
I'm
aware
of
the
two
that
sanskar
mentioned
in
slack
as
kind
of
that
the
larger
themes
of
things
that
haven't
been
resolved,
but
if
we
resolve
those
and
merge
this
is
there's
something.
We've
missed
that
we
should
make
sure
to
address.
E
E
John
brought
up
that
a
lot
of
the
things
that
applied
to
response
headers
in
the
skip,
but
luckily
pi
requests
as
well
is:
do
we
do
we
want
to
have
any
kind
of
promise
of
compatibility
between
the
two
in
the
spec,
or
do
you
want
to
leave
them
independent.
A
A
A
And
it
would
have
the
same
behavior
for
request
and
response
header
modification
that
doesn't
seem
like
it's
necessarily
a
blocker
on.
Well,
I
I
basically,
I
don't
want
to
make
a
gap
around
response.
Header
modification
have
to
update
the
request-
header
docs,
but
yeah.
I
agree.
We
need
some
kind
of
follow-up
here.
E
I
mean
even
even
generally,
as
far
as
parity
between
response
header
request,
header,
they're,
separate
yeah,
they're,
separate
resources
so
that
they
should
be
independent,
but
you
know
oftentimes,
there
might
be
kind
of
a
goal
of
keeping
them.
A
Oh
got
it
yeah.
I
think
that
will
come
naturally
with
this
proposal,
because
the
proposal
is
to
use
the
same
api
type
and
just
a
different
name
for
it,
but
it
could
be
worth
explicitly
stating
that
as
a
goal
too,.
B
Yeah,
I
think
I
agree
that
I
think
the
the
two
things
that
you've
called
out
there
are
the
two
other
things.
I
think
it's
actually
a
really
good
in
some
ways.
It's
a
really
good
usage
of
the
policy
attachment
and
a
really
good
example
of
how
you
would
use
policy
attachment.
I
think
that
every
time
people
mention
policy
attachment
some
part
of
me
sort
of
makes
a
ouch
face,
because
I
don't
think
I've
done
it.
B
When
I
wrote
that
I
don't
think
I
did
a
good
enough
job
of
explaining
it
clearly
because
you
it
seems,
like
you,
there's
a
lot.
B
And
I
don't
think,
there's
enough
examples
there
to
be
sort
of
been
clear
as
to
how
it
all
works,
like
I
think
candace
you
mentioned
in
one
of
the
things
about
defaults
and
overrides,
and
you
I
think
that
that
that's
one
of
the
the
key
things
that
makes
ball
assessment
useful
in
my
mind
and
you
if
that
and
so
that
that
needs
to
be
like
exceptionally
well
explained,
yeah
and
the,
and
so
I
think
yeah
I
definitely
I
it's
been.
B
List
for
a
while
to
sort
of
go
over
that
page
again
and
redo
it,
but
it's
sort
of
moving
up.
I
guess,
but
I
think.
C
B
C
B
Of
gateway,
api
resources,
gateway
class
gateway
routes,
services,
secrets,
and
so
the
point
of
a
policy
attachment
is
to
allow
you
to
attach
something
at
the
gateway
level
that
will
then
interact
with
things
in
the
rest
of
the
in
the
rest
of
the
thing
and
that's
what
the
default
part
is
for
the
depaul
the
default
one
is
to
allow
you
to
say
in
this
case
add
add.
B
But
don't
but
but
the
default
implies
that
you
can
override
it
at
the
right
level.
So
if
you
add
a
default
header
at
the
gateway,
then
you
can
add,
then
it's
allowed
to
add
and
to
add
that
same
header
at
with
a
different
value
at
the
route
level,
whereas
if
you
do
override
it's
like
yeah,
I'm
the
administrator
and
I
get
to
tell
you
what
to
do-
and
you
know
you
can't
change
this.
B
So
if
you
want
to,
you
know,
add
hscs
or
some
other,
like
you
know
some
other
security
thing,
then
you
can
say
no,
you
can't
you
don't
get
to
change
that,
and
so
that's
the
idea
behind
the
defaults
on
the
rights,
for
example,
but
yeah
like
obviously
that
is
you
the
fact
that
that
I
mean
that's
not
the
first
time
I've
heard
that
question
says.
E
B
I
haven't
done
a
good
enough
job
of
writing
that
documentation
to
be
possible
by
people
who
are
not
me
so
yeah.
I
need
to
redo
that.
A
Yeah
I'll
share
lots
of
responsibility
on
that
policy.
Attachment
could
could
use
some
better
documentation,
so
any
any
volunteers
are
very
welcome
to
yeah
next
up
on
this,
I
think
this
is
mark's.
A
Get
oh,
it's
merged
nevermind.
This
is,
I
copied
the
triage
from
last
week
and
great
a
couple
are
already
resolved
and
we
already
talked
about
1282.
A
So
I
think
that
leaves
us
with
one
left,
and
this
was
a
comment
by
travis.
I
think
I
think
you're
on
the
call
yeah.
Maybe
you
can
summarize
better
than
me.
D
Yeah,
what's
the
quick
summary
of
this,
so
we
have
to
like.
Basically
we
want
to
make
it.
You
know
a
conformance
thing
for
what
the
order
of
headers
is,
when
you
add
them,
or
remove
them
or
replace
them
or
whatever,
and
I
think
that
one
simple
way
to
do
this
is
that
there's
basically
you
know
the
rfc
standard
for,
if
you're,
providing
multiple
values
for
the
same
header
that
you
just
do
it
into
csv.
D
So
if
we
just
enforce
that,
you
have
to
like,
you
are
not
allowed
to
say
like
add
header,
xfu,
red
and
then
add
header,
xfu,
blue,
and
then
you
know
as
many
x2
ads
or
sets
as
you
want.
You're
just
only
allowed
to
do
any
given
header
name
once
and
you
have
to
provide
all
the
different
values
that
you
want
with
it
in
that
csv
format,
and
that
allows
us
to
basically
say
that
you
know
we
don't
need
to
worry
about
the
order
of
multiple
ads.
A
D
D
A
Yeah,
that's
okay,
that
that's
what
I
was
asked.
What
I
meant
to
ask
about,
were
you
proposing
here
that
we,
basically
only
let
a
value,
be
add,
set
or
removed
once
per
filter
kind
of
thing,
so
it
could
only
have
one
operation
handled
happen
to
it.
D
B
D
Sense
to
like
so
I
guess
you,
you
have
to
choose
the
oh
yeah,
because
I
guess
at
least
going
from
the
example
of
our
implementation.
I
know
I
think
we
have
the
other
way
around
where
we
we
cannot
choose
like
our
order
of
operations,
but
that
is
something
that
the
spec
has
to
do
regardless.
D
B
D
B
D
D
The
other
half
of
that
is
like,
I
don't
think
it
like.
The
only
thing
that
I
think
this
like
doing
that
version
limits
you
from
doing
is,
if
you
wanted
to
actually
allow
rfc
violations,
which
you
know
you're
in
http
lan,
so
those
may
be
quite
prevalent
in
some
cases.
But
if
you
wanted
to
actually
like
allow
it
to
say,
like
you
know,
two
ads
actually
gets
you
two
instances
of
the
ad
added
header
in
the
request
that
goes
upstream
and
it's
up
to
upstream
to
like
concatenate
them
which
something
they
require.
B
I
definitely
recall
a
number
of
applications
where
contra
had
people
being
like
our
app.
Does
this
extremely
busted
non-rfc
compliant
thing?
Why
doesn't
contour
support
it
and
I'm
like
and
make
me
tap
the
rfc
yeah?
But
I
I
think
my
my
preference
is
that
you
know
in
general
we
should
be
like
hey,
no
we're
going
to
do
what
the
rfc
say
and
if
you
want
to
do
something,
that's
not
rf
compliant.
Then
you
know
look
out
to
you,
but
we'll
see
you
around
have.
B
Exactly
yeah
exactly
yeah
so
yeah.
I
I
really
appreciate
really
appreciate
that
I
not
gonna
lie.
It
took
me
three
reads
through
to
pause
to
pass
this
because
it's
been
a
long
time
since
I
went
that
deep
into
header
mechanics
but
yeah.
I
think
that
what
you're
saying
is
very
reasonable.
A
I
know
we're
we're
past
time
here.
This
does
not
to
me
feel
like
something
that
needs
a
gap,
but
if
anyone
is
open
travis,
I
you've
written
a
lot
here,
if
you're
open
to
translating
this
into
basically
an
api,
spec
change
or
update.
I
think
that
would
be
easiest
to
reason
through
and
review.
E
The
other
person
on
the
call
tokers
was
against.
B
However,
we
also
need
to
ensure
that
we
keep
movement
on
this
so
yeah,
I
think
yeah.
I
propose
some
sort
of
lazy
consensus
period
where
we
say:
hey
we're
gonna,
I
mean
hey.
C
A
Yeah
cool
all
right.
Well,
thanks
so
much
we
are
past
time,
but
thanks
for
the
great
conversation
and
travis,
if
you
don't
mind
following
up
on
that
issue,
thank
you
for
great
comments
already
and
I
think
we'll
cut
it
there
all
right
thanks.
Everyone.