►
From YouTube: Gateway API GAMMA Meeting 20230117
Description
Gateway API GAMMA Meeting 20230117
A
As
always,
kubernetes
could
come
back
to
a
certain
effect,
so
please
treat
each
other
respectfully
and
with
that
yeah
we
can.
The
meat
notes
are
linked
in
the
invite
feel
free
to
add
your
name
to
those
two
attendees
and
we
have
an
open
Agenda.
So,
if
you're
free
to
add
any
topics,
you'd
like
to
discuss
to
the
agenda
and
we'll
go
through
that,
all
right
start
off
with
a
recap
of
last
meeting,
it's
pretty
brief.
A
Be
able
to
express
that.
So
we
had
a
discussion
about
that
and
there
were
a
couple
suggestions
that
came
out
of
that.
One
is
the
idea
of
some
kind
of
like
conformance
profile,
so
this
may
also
be
useful
for
differentiating
L4
from
L7
support
for
north
south
gateways,
as
well
as
being
able
to
split
out
gamma
into
a
separate
test,
Suite
potentially
so
that
was
one
of
the
like
more
near-term
ideas.
A
As
we
start
working
on
building
up
conformance
tests
for
gamma
functionality,
then
one
of
the
more
longer
term
ideas
that
seem
to
have
broad
interest
was
building
some
kind
of
machine
readable
way
for
implementations
to
advertise.
Their
feature
support,
so
one
suggested
path
was
doing
that
on
Gateway
class.
A
There's
also
some
discussion
around
potentially
being
able
to
do
that
in
a
more
general
purpose
or
abstract
way.
That
could
be
useful
to
implementations
or
projects.
Beyond
The
Gateway
guy
project,
similar
to
how
like
we
first
introduced
reference
Grant
for
our
purposes,
but
then
that's
starting
to
be
adopted,
no
more
broadly
for
I,
think
like
storage
but
yeah.
This
is
scheduled
for
further
discussion
in
the
Gateway
API
meeting
on
Monday
next
week.
A
A
This
is
something
that
is
not
a
current
goal
for
us
to
focus
on
The
Hope
is
kind
of
any
early
effort,
might
Channel
towards
the
open,
Telemetry
project
and
kind
of,
like
Give,
Them
Enough
wrong
way
to
see
what
comes
out
of
that
before.
We
endorse
any
kind
of
like
formal
adoption
of
that
spec
or
really
address
dedicate
any
kind
of
a
significant
attention
to
that
all
right.
A
I'll,
take
that
as
we
can
move
on
so
yeah
I
just
wanted
to
thank
everyone
for
the
discussion
we've
had
over
the
past
couple
weeks
about
the
here
are
the
genre
for
expanding
the
scope
of
gamma
rallying
to
include
client
or
consumer
defined
routing.
It's
the
namespace
boundaries.
Pr,
that's
linked
here
in
1493.,
I.
Think
that
we're
at
a
pretty
good
point
now,
where
we've
had
significant
discussion
we
seem
to
have
rough
agreement
on
this
is
something
that
many
implementations
can
support
in
some
capacity.
A
A
C
Namespaces
have
we
talked
at
all
about
more
advanced
matching
here,
so
another
thing
that
we
want
to
do
in
liquidy
is
when
we
have
a
consumer
namespace,
we
might
not
want
all
workloads
to
match
a
specific
route,
so
we
might
want
them
to
use
the
the
server
route
instead
or
the
server
to
find
route.
Have
there
been
any
conversations
on
this
topic?
I
know:
John
opened
up
an
issue,
but
I'm
just
curious
if
it
was
brought
up
at
all
in
in
the
meetings.
D
I
can
I
can
answer
a
bit
It's
relatively
controversial
issue,
because
consumer
consumer
overrides
many
industry.
We
support
them
and
we
support
them
for
quite
well
and
at
a
very
high
cost.
It
is
extremely
difficult
to
implement
consumer
overrides
without
having
a
consumer.
Sidecar,
which
has
you
know,
means
basically
running
an
extra
proxy,
which
is
a
hard
latency,
CPU
cost
and
so
forth.
So
it
will
be
very
useful
to
have
them
as
optional.
D
We
will
continue
to
support
the
main
issue
for
possible
future
because
of
record
compatibility
and
virtual
service,
but
we
are
hoping
to
reduce
the
use
of
client
overrides
to
minimum
necessary
and
to
identify
these
minimum
necessary
before
going
only
in
with
with
everything
I
don't
know.
If
link
Rd
has
any
plan
to
stick
with
sidecars,
whatever
or
or
if
you
guys
are.
D
Any
of
these
things
will
be
wonderful
to
to
prioritize
and
to
do
faster
and
to
kind
of
have
all
vendor
supports
them,
but
anything
that
strictly
require
a
sidecar
and
no,
there
is
no
reasonable,
fast
implementation.
That
is
only
without
the
client-side
card.
I
would
again
keep
it
optional
as
much
as
possible.
A
I
think
that
the
intent
of
this
would
be
to
avoid
any
kind
of
explicit
requirement
on
a
sidecar,
while
that's
certainly
one
model
which
many
messages
will
use
to
implement.
It
I
think
you
mentioned
like
in
namespace
scope.
Egress
Gateway
could
be
another
way
to
implement
it,
and
that
seems
I.
Don't
think
that
there's
anything
that
will
prevent
that
implementation.
E
E
E
There
is
a
substantial
difference
between
namespace
and
specific
pods,
because
if
you
have
a
namespace
gateway,
then
that
means
having
one
set
of
routing
rules
versus
having
potentially
infinite,
not
saying
we
shouldn't
do
it
just
to
clarify
that
that
concern
there,
but
I
also
think
you
know
we
can
potentially
have
optional
features
as
well,
certainly
for
the
short
term,
while
we're
in
super
experimental
mode,
just
kind
of
see
what
works
and
what
doesn't
in
istio.
In
particular,
we
did.
E
E
A
In
terms
of
like
what
are
some
of
the
higher
priority
things
for
y'all,
that
you
want
to
see
out
of
gamma
as
well
as
kind
of
like
an
open
call
for
any
volunteers
or
folks
interested
in
stepping
up
as
a
champion
to
take
on
any
of
the
remaining
tasks
in
this
Milestone,
which
we've
kind
of
collected
as
in
place
of
let's
say
rough
edges
before
gamma
is
quote
ready
for
a
wider
adoption,
or
if
there
are
things
that
are
not
covered
in
here
that
we
should
add.
Yeah.
E
F
A
F
A
E
F
G
Think
there
there's
a
couple
things
here:
one
absolutely
should
collaborate
as
early
as
possible,
but
I
think
what
lior
is
focused
on
up
front
is
just
taking
the
conformance
test.
We
already
have
and
finding
a
way
to
represent
the
results,
centralized,
reporting
and
I
think
what
Keith
is
working
on
or
John
or
somebody
is,
is
building
out
tests
for
for
mesh
and
I.
E
Yeah,
so
my
understanding
Keith's,
not
here
right
yeah,
so
Keith,
is
working
on
getting
kind
of
her
I
hate
the
word
framework,
but
like
the
test
framework
for
for
mesh,
so
that
we
can
run
mesh
tests
which
will
probably
present
himself
as
just
like
a
hello
world
test
and
then
I.
He
may
need
some
help
right
now
if
people
are
interested,
but
after
we
get
that
core
in
it
should
be
very
easy
to
distribute,
actually
writing
test
cases.
E
A
Cool,
well
that
that
sounds
like
great
work.
I'm
excited
to
see
that
happening
and
yeah.
It
sounds
like,
potentially
in
weeks,
we'll
have
kind
of
a
wider
open
area
for
folks
to
contribute
to
that
once
we
kind
of
like
get
the
groundwork
in
place,
so
that
that's
really
exciting
definitely
glad
to
hear
that
and
yeah
it'll
be
good
to
see
this
world
start
coming
together.
H
Wouldn't
so
I
need
to
understand
a
little
bit
more
about
ambient
mesh
and
you
know
what's
what's
involved
with
it,
but
wouldn't
that
be
at
a
point
where
you
already
have
a
proxy
running
on
that
node.
Like
isn't
this
the
little
past
like
I,
my
understanding
of
ambient
mesh
is
that
you
get
things
like
mtls
without
having
the
per
node
proxy,
but
as
soon
as
you
go
into
things
like
policy
or
just
you
know,
figuring
out
what
to
use
for
you
know
server
or
ride
or
something
don't
don't.
E
E
So
with
just
a
producer
Waypoint
process.
That
means
all
your
incoming
requests
are
going
through
it,
but
your
egress
requests
are
not
so
that
would
only
allow
producer
rules
right
in
our
experience.
Those
are
the
most
common,
the
most
important,
and
so
that
is
what
we're
focusing
on
as
both
like
we're
implementing
that
now
and
the
rest
later,
and
we
think
that's
what
most
people
will
use.
E
We
will
also
probably
add
the
kind
of
egress
Waypoint,
which
is
most
likely
actually
the
same
proxy
just
running
in
two
different
modes
simultaneously,
and
in
that
case
like
say,
you
wanted
to
have
a
consumer
override
that
I,
don't
add
the
timeout
or
something
if
we
apply
it
at
the
namespace
level.
That's
easy,
regardless
of
if
we
do
the
namespace
or
service
account
proxy
I
can
just
apply
it
to
all
of
those.
E
So
similar
issues
there.
If
we
were
to
say
like
you
can
override
only
at
the
service
account
level
and
we
decide
that
we're
never
going
to
do
like
namesace-wide
waypoints.
Maybe
it's
you
know
it's
a
different
story
that
would
kind
of
lock
us
into
took
a
kind
of
weird
API
and
then
lock
us
into
what
we
can
the
scope
of
the
Waypoint.
If
that
makes
sense,.
I
E
The
API
today
with
policies
like
there's
the
idea
that
you
know
some
policies
can
attach
to
Gateway
namespace
HTTP
route,
whatever
some
other
implementations
can
only
do
some
of
those.
So
it's
not
unheard
of
to
say
that
you
know
we
could
attach
these
policies
at
more
granular
levels
and
some
implementations
than
others
yeah.
D
Yeah
I
think
it's
important
to
to
the
model.
I
have
in
mind.
Is
that
every
time
you
have
policies,
L7
policies,
you
need
dual
seven
passing,
so
that
involves
having
a
Gateway
and
heading
overhead.
So
at
least
overhead
you
have
the
better
it
is
and
and
low
cost
lower.
You
know,
latency
increase
and
everything
else
so
and
and
also
more
opportunity
to
you
know,
have
a
larger
scale
that
scales
up
skills
down.
H
H
I've
been
messaging
mate
on
the
side
about
wishing
that
there
was
more
for
me
to
read
up
on
about
about
it.
I
feel
like
the
ambient
mesh
side
of
things.
There's
I'm
aware
of
like
a
few
things
that
have
been
helpful
to
read,
but
it
it's
still
something
that
I
want
to
understand
a
little
bit
more.
So
if
there
are
any
great
docs
that
maybe
I'm
missing
or
something
that'd
be
that'd.
I
And
we
also
have
a
istio
ambient
explained
book.
That
would
also
explain
some
of
the
questions
you
were
asking,
so
that
might
be
interesting.
We
are
in
the
midst
of
actually
refreshing
or
contents,
which
we
should
in
the
next
few
months
and
weeks
and
we're
probably
you
know,
provide
more
content
with
the
latest
development,
because
the
development
of
whipped
down
was
in
September,
so
it
was
a
little
bit
updated.
E
H
E
D
More
point
I
want
to
put
on
this
discussion,
I
mean
regardless
of
or
interested
in
ambient
or
similar
model.
One
thing
that
will
be
very
useful
to
explore
and
to
look
into
is
having
a
common
protocol
and
common.
You
know,
concept
of
security.
You
know
using.
We
are
using
this
age,
one
HTTP
to
connect
based
protocol,
which
is
also
standard
by
ATF
and
and
in
some
form,
and
having
interoperabilities
of
components
from
different
vendors
can
work
together.
So
it's
not
only
history.
D
Only
or
you
know
some
vendor
X
only
mesh,
but
you
can
have
some
parts
of
the
machine
clusters
using
one
vendor
and
common
protocols.
That
will
be
super
useful.
Regards
I
mean
you
can
keep
side
cards,
you
can
use
whatever
you
use,
but
it
will
be
useful
to
have
at
least
one
mode
where
everyone
is
using
HTTP,
2
and
and
streaming
over
HTTP
2,
plus
quick
in
future,
and
if
you
have
faster,
better
alternative
protocol.
H
A
Yeah
I'm
I've
been
following
this,
with
kind
of
like
vague
interest
for
the
multi-cluster
use
case,
basically
so
not
so
much
within
a
cluster,
but
I
I'm
curious
if
it
could
be
applied
to
a
different
scope
because
it
feels
like
we
have
similar
needs
of
like
President
securely
through
a
Gateway
and
then
having
some
the
cluster
actually
routes
off.
The
pods
like
with
a
waypoint-ish
type
thing.
It
seems
like
a
similar
use
case,
even
though
it's
a
different
scope.
D
Is
that
the
main
reason
I
mean
we
want
to
interpret
with
you
know
not
only
clusters,
but
you,
may
you
know
external
infrastructure?
Maybe
you
know
home
devices,
you
know
I,
don't
know
if
you
guys
are
familiar
with
the
matter.
Standard
I'm
very
excited
about
it,
and
and
it's
also
based
on
encryption
and
and
security.
So
what
was
that
matter?
The
foreign
devices?
E
Anyways
individually,
pretty
much
I've
been
I've,
been
looking
at
controllers
and
kind
of
one
of
the
issues
I've
had
is
we're
trying
to
be
very
granular
in
terms
of
something
changing
and
then
us
doing
work.
So,
for
example,
if
we
considered
a
simple
controller
that
kind
of
merges
pods
and
services
into
endpoints
like
a
service
annotation
changes,
a
naive
implementation
would
then
go
over.
You
reconcile
everything
related
to
that
service.
E
A
terrible
implementation
would
go
reconcile
the
entire
world
on
every
change
right
and
an
optimal
one
would
realize
immediately,
like
that's
totally
irrelevant,
skip
that
in
many
ways
it's
I
found
that
it
parallels
like
the
problems
that,
like
JavaScript
Frameworks,
do
of
like.
Okay,
like
this
field
change
like
what
do
I
need
to
go.
Re-Render
I'm,
just
wondering
is
anyone
like
solving
those
types
of
problems
in
their
controllers
or
thinking
about
it?
I
would
love
to
copy
something
instead
of
making
something.
E
Yeah
I
have
some
ideas,
but
yes,
okay,
the
kubernetes
react
framework,
isn't
coming
I,
actually
thought
about
writing
a
controller
in
react
to
see
you
what
it
would
look
like,
but
I
haven't
got
there
yet,
but
that
that
that's
actually
exactly
what
I'm
thinking
it's
like
similar
type
thing,
but
I
was
surprised
that
I
hadn't
seen
anything
like
it,
but
maybe
now
we
will
see
something
like
it.
If
I
get
around
to
getting
a
prototype.
H
B
Yeah
I'll
I've
got
some
thoughts
here.
It's
an
interesting
problem.
The
the
thing
with
react
is
that
it's
able
to
take
advantage
of
the
hierarchical
nature
of
the
Dom
for
stiffing
algorithm
and
that's
really
the
the
magic
of
of
how
react
able
to
be
so
performant
and
rendering
those
updates
for
just
a
single
resource
for
a
single
tree
of
resources
so
effectively
I.
Think
the
the
core
problem,
the
kubernetes
wrote,
is
to
build
a
tree
of
all
the
different
various
resources
and
and
dependencies.
B
If
you
wanted
to
use
the
react,
different
algorithm
or
create
a
a
new
algorithm
that
can
be
as
performant
and
efficient
with
objects
that
are
stored
in
the
kubernetes,
that's
kubernetes,
Cloud
native
I.
Guess
it's
a
very
interesting
problem
and
I
hadn't
thought
about
until
you
brought
it
up,
but
it's
very
fascinating.
E
D
Or
anything
like
that
can
help,
because
it's
a
problem
of
semantics
I
mean
if
any
smaller
change
somewhere
may
impact
arbitrary
things
that
we
don't
know.
You
don't
know
ahead
of
time
and
nobody
can
can
predict
what
will
change
an
annotation
on
the
field
will
have
required
to
change
in
other
parts
of
the
of
the
mesh
of
different.
D
You
know
different
controllers
or
different
things
that
that
need
that
field,
so
I
think
the
real
problem
is
Right,
amplification
and
and
how
to
avoid
it
by
you
know,
making
sure
that
the
leaves
get
the
changes
identical
as
I
mean
one
is
a
resource
that
is
changed
and
can
do
some
computation
locally.
If,
if
we
want
to
do
it
reliably,
because
anything
that
is
is
based
on
on
assumptions
about
tree
structure
or
any
structure
will
probably
fail,
some
Corner
cases.
E
Oh,
that
was
actually
one
of
the
motivations,
for
this
whole
discussion
is
that
in
istio
we
have
like
the
root
of
the
tree
and,
like
the
final
output
of
like
generating
XDS,
is
like
so
far
disconnected
that
we
try
and
put
these
optimizations
like.
Oh,
we
got
a
service,
only
annotations
change,
I
hope.
That
means
nothing
will
change
in
the
XDS.
So
let's
just
skip
it,
but
we
don't
actually
know
that.
It's
just
like
a
human
observation
that
could
easily
be
wrong.
H
E
A
I
I
guess
I
am
curious,
like
I
feel,
like
a
lot
of
information
is
probably
when
someone
similar
to
us
where
you
like
you,
have
the
like
gkv
from
things
like
reference
Grant.
So
you
have
some
way
to
query
like
I
guess.
The
difficult
part
is
like
kubernetes
controller
that
like
lets,
you
know
that
a
resource
changed
without
telling
you
like
past
State
and
current
state.
A
So
that's
what
kind
of
necessitates
the
read
the
whole
world
and
hope
that
performance
is
handled
as
best
as
possible
by
the
kubernetes
API
caching
layer,
rather
than
trying
to
like
build
and
save
State
internally,
but
yeah
I,
I
guess
I
I
could
see
a
way
to
have
a
more
local
caching
layer
of
some
sort
based
on
like
current
and
past
state,
but
I
would
require
like
abstraction
and
saving
a
lot
of
stuff
that
I
don't
know
how
beneficial
it
would
be.
Just
like
it.