►
From YouTube: Gateway API GAMMA Bi-Weekly Meeting for 20230314
Description
Gateway API GAMMA Bi-Weekly Meeting for 20230314
A
A
Hello
and
welcome
to
the
March
14th
meeting
of
the
Gateway
API
gamma
initiative,
as
always,
kubernetes
credit
conduct
rules
for
an
effect,
so
please
treat
each
other
respectfully
and
with
that
we
have
an
open
agenda
today
feel
free
to
add
a
topic
that
you
want
to
discuss
to
the
meeting
notes-
and
please
add
your
name
to
the
list
of
attendees
so
that
we
can
keep
track
of
who
is
able
to
attend
these,
particularly
as
we
continue
to
have
the
two
sessions
at
different
time
zone
compatibilities
all
right,
I
guess
we
should
probably
start
with
recap
of
last
meeting.
A
I,
unfortunately,
did
not
protect
the
notes
this
time,
but
one
of
the
things
that
has
been
discussed
recently
in
both
gamma
and
the
Gateway
API
meeting.
More
broadly,
is
the
complexity
of
policy
attachment.
A
So
this
is
something
that
Nick
has
been
working
on
a
proposed
direct
policy
attachment
as
a
simpler
form
of
and
is
actively
soliciting
feedback
right
now.
So
there
is
a
I
believe
PR
link
here,
and
at
least
one
concrete
proposed,
like
first
class
use
of
it
for
timeouts,
so
I
think
the
timeouts
Gap
is
dependent
on
kind
of
the
direct
mode.
A
Is
my
understanding-
and
there
was
discussion
of
other
potentially
like
first-classing
things
like
retries,
was
I,
think
another
one
that
could
be
applicable
to
move
out
of
the
external
complex
policy
attachment
into
first
class
things
provided
by
Gateway
API,
so
yeah,
just
kind
of
a
call
for
feedback
definitely
would
like
to
get
some
eyes
on
this,
particularly
from
the
mesh
perspective.
A
I
know
that
we've
had
a
handful
of
Gateway
implementations,
I'll
look
into
this
already,
but
definitely
now
would
be
the
time
if
you
love
policy
attachment
if
you
hate
policy
attachment,
if
you
have
other
wildly
different
ideas.
A
The
other
one
another
talks
was
we
had
a
presentation
on
multi-cluster
or
service
networking
models.
So,
if
there's
a
lot
that
feels
like
it's
starting
to
happen
and
this
kind
of
leads
to
the
next
topic
of
the
doc
that
Opera
put
together
of
kind
of
like
the
convergence
of
Gateway,
API,
gamma
and
various
multi
multi-cluster
use
cases,
including
the
MCS
API,
so
their
the
presentation
and
the
doc
are
somewhat
related,
even
though
they
were
independently
authored
and
originated.
A
But
this
is
definitely
a
topic
that
it
would
be
good
to
get
some
perspective
on
from
gamma
folks.
I
know
from
the
console
perspective
that
we
definitely
are
interested
in
exploring.
How
do
we
Bridge
across,
like
groups
where
that
sameness,
guarantee
of
MCS
is
not
applicable?
A
So
that's
into
that
in
this
presentation,
in
terms
of
like
cross-cluster
set
networking
models
and
in
Rob's
dock
that
they're,
specifically
so
much
of
how
we
handle
routing
to
cross
cluster
services.
So
that's
definitely
directly.
A
To
gamma
and
would
love
to
get
a
perspective
from
other
mesh
implementations
on
how
it
makes
sense
to
approach
that
and
then
yeah
Shane
heard
a
bit
on
conformance
profile
updates,
which
will
be
important
to
unblock
us
from
being
able
to
hopefully
use
one
of
those
for
gamma
conformance
tests.
So
definitely
appreciate
that
work
and
keep
an
eye
on
that
as
it
that
develops
so
I
think
that
should
cover
the
recap
from
last
time.
A
Yeah
are
there
any
other
things
that
folks
want
to
bring
up,
or
should
we
just
get
into
the
agenda
then?
At
this
point.
A
Also,
thank
you
for
taking
notes.
Whoever
was
capturing.
The
recap
stuff
definitely
appreciate
that.
A
All
right
so
yeah
I
had
a
chance
to
chat
with
Flynn
and
basically
the
focus
of
what
we're
trying
to
figure
out.
We
should
link
the
actual,
concrete
issue
here
and
send
again.
Milestone
is
trying
to
figure
out
patterns
for
Gateway
to
mesh
interaction
and
how
that
routing
should
happen.
So
the
like
concrete
use
case
here
is
a
mesh
service.
A
A
What
we're
trying
to
figure
out
is
how
should
or
should
not
or
could
possibly
a
Gateway
respect
those
kind
of
routing
rules,
and
basically,
we
have
two
primary
options
with
like
some
nuance
and
other
like
ux
possibilities,
but
the
two
like
primary
ways
of
routing
from
a
Gateway
is
endpoint
routing,
where
the
service
is
representative
of
a
bucket
of
endpoints
and
the
Gateway
routes
directly
to
those
back-end,
endpoints
or
front-end
routing,
where
the
Gateway
would
route
to
in
many
cases,
particularly
for
like
cross
vendor
compatibility,
the
cluster
IP
of
the
service,
and
then
the
mesh
would
be
responsible
for
seeing
an
incoming
request
to
that
cluster
IP
and
applying
mesh
rules.
A
At
that
point,
some
more
integrated
messages
may
choose
to
collapse,
those
into
a
single
step
and
resolve
them
in
the
Gateway
itself.
But
it's
effectively
mesh
aware
routing
in
some
way.
So
we.
C
A
Yes
yeah,
so
this
is
something
we
definitely
struggle
with
sort
of
our
initial
idea
way
back
before
we
drive
to
the
dock,
and
what
was
that?
Oh
of
course
it
makes
sense,
tough
to
get
away
respect.
My
shrouding
rules
turns
out
that
adds
the
complexity
of
implementation.
It
adds
some
potential
difficulty
for
crossfender
Solutions,
but
just
enforcing
only
endpoint
routing,
as
kind
of
was
The
Proposal
that
was
drafted
into
this
doc.
That
I
really
should
get
linked
in
here
interesting
craft.
A
So
that
proposal
was
basically
to
only
route
from
the
gateway
to
a
service
by
endpoint
routing,
even
if
it
has
gamma
routes
defined
for
it,
and
some
of
the
difficulty
with
this
I,
both
fun
and
I,
have
had
conversations
with
Engineers
on
our
team,
so
console
and
liquor
D
about
how
this
is
often
an
unexpected
ux
for
mesh
users.
A
There
are
certainly
performance
benefits
to
routing
directly
to
the
endpoints
regarding
directly
at
endpoints
is
often
fine
in
smaller
deployments
too,
where
you
have
your
gateway
operator
and
your
mesh
service
owner
are
either
the
same
person
or
on
the
same
small
team
in
larger
distributed
deployments,
it
can
become
more
valuable
to
be
able
to
kind
of
like
split
those
roles,
following
kind
of
the
Gateway
API
design
of
having
a
role
oriented
pattern,
so
that
kind
of
brought
us
to
like
looking
at
prior
art
of
what
what
have
existing
Ingress
controller
implementations
done
to
handle
this
and
then
we're
in
the
process
of
thinking
that
the
initial
Hope
was.
A
A
So
we're
working
on
kind
of
ironing
out
personas
use
cases
like
specific
scenarios
that
we
want
to
be
able
to
support
and
have
an
idea
of
how
they
would
be
implemented
with
one
model
or
the
other,
and
then
hopefully
using
that
to
drive
us
towards
some
sort
of
ux
and
actual
API.
That
allows
this
to
be.
Configurable
is
kind
of
the
hope
we
do
not
have
a
strong
determination.
Yet
of
should
one
be
required,
and
one
optional
should
both
be
optional
and
select.
A
One
should
one
be
default
and
the
other
opt-in.
We
haven't
already
gotten
that
far
yet
other
than
that.
It
seems
that
there
is
a
desire
to
have
flexibility
of
some
sort
here,
because
brushes
have
different
goals
and
different
expectations
from
their
users
and
kind
of
little
like
elephant
in
the
room.
Part
is
that
this
isn't
just
about
Gateway
to
gamma
this
front
end
versus
back
end.
Endpoint
routing
has
come
up
in
at
least
like
three
or
four
other
places
in
Gateway
API.
A
So,
even
if
we
don't
attempt
to
address
all
of
those
in
the
stock,
it's
at
least
worth
pointing
out
potential
implications
and
user
expectations
for
how
things
should
work,
because
this
has
similar
issues
with
like
consumer
and
producer
HTTP
route,
layering
or
merging.
A
It
has
similar
implications
for
across
cluster
routing.
For
the
doctor,
Rob
wrote
I'd
start
a
comment
Thread
about
MCS
service
Imports
as
a
back
end
and
how
this
would
apply
to
a
situation
like
that
and
then
from
at
least
conscious
perspective,
there's
also
kind
of
like
the
outside
cluster
set
outside,
like
sameness
group
routing.
So
for
us
it's
to
a
peer
where
there's
not
that
Assumption
of
sameness.
A
That's
pretty
clear,
at
least
from
our
perspective
that
we
basically
treat
that
similar
to
an
Ingress
where
you,
because
you
don't
have
any
kind
of
like
replication
or
awareness
of
what
those
rules
are
on
the
calling
side.
You
basically
like
have
to
apply
them
at
that
Ingress
Point,
rather
than
pushing
them
up.
Oh.
B
A
C
I
actually
have
a
question
for
some
of
the
istio
folks,
since
I
assume
we
have
semester
folks
on
the
call,
is
istio
capable
of
routing
to
the
service
front
end,
or
is
it
only
capable
of
routing
to
the
endpoint
IP?
And
if
it's
only
capable
of
routing
to
the
endpoint
IP?
Is
it
capable
of
putting
in
a
header
with
the
original
name
of
the
service
to
which
it
was
trying
to
route.
E
D
I've
I've
got
some
istio
experience
in
another
life.
I
can
might
be
able
to
help
here
so
for
for
most
of
the
route
to
get
excluding
Hitler,
Services
stateful
sets
and
those
kind
of
use
cases.
My
current
understanding
is
that
istio
routes
to
the
service
IP,
oh.
C
D
Believe
that's
the
case.
Most
everything
that
I've
seen
in
istio
is
is
service
IP
routing,
except
for
the
Headless
service
piece,
and
that's
really
everything
istio
is
a
host
header
like
istio
class,
is
host
header
based
routing
rather
than
service
IP,
with
with
service
IP
being
kind
of
the
the
the
fallback.
E
I
must
correct
you
a
bit
so
we
capture
my
cluster
IP,
meaning
that
the
DNS
resulted.
E
C
E
Ipe
but
then
we
route
to
support
IEP,
so
so
zen
zen
EDS
takes
place
and
then
way
out
to
the
to
the
actual
destination.
Ip.
However,
with
with
ambient
things,
are
a
bit
well,
I
kind
of
are
the
same
to
some
extent,
in
the
sense
that
that
we
captured
by
cluster
iip,
because
I
suppose
everyone
is
capturing
backrest.ip,
but
they
sent
us
a
waypoint
which
is
much
closer
to
a
cluster.
It
could
be
a
cluster
VIP
or
it
could
be
an
IP.
E
So
in
the
new
world
you
are
I
mean
we
are
actually
going
to
route
to
a
VIP,
which
is
a
commander
cluster
IP
could
be
for
for
waypoints,
but
in
classic
EQ
we
we
still
Route
2
to
the
actual
endpoints
and.
C
B
E
Ahead
also
behave
in
two
different
ways:
I
mean
if
you
have
a
waypoint
General
how
to
do
that
to
the
cluster
to
the
to
the
Waypoint.
If
you
don't
have
Waypoint,
then
we
we
fold
I
mean
what
can
we
do?
I
mean
before
we
go
directly
to
the
endpoints,
so
we'll
support
both
modes
and
we
also
have
a
more
I,
don't
know
if
you
heard
about
the
composite
Gateway,
it's
called
in
istio,
so
we
have
many
cases
of
energy.
E
Next
we
have
the
Google,
Global
load,
balancer
and
other
gateways
that
exist
in
front
of
istio,
and
we
need
them
to
be
used
with
with
istio.
So
the
way
it
works
is
if
you
have
rules
that
are
compatible,
so
you
don't
have
any
any.
So,
let's
say
gamma
API
in
use
and
the
Gateway
is
capable
of
enforcing
everything.
E
What
matters
is
if
I
have
an
authorization
policy,
it
must
be
respected.
Someone
must
enforce
it
so
either
both
Gateway
and
gamma
understands
authorization
policies
in
place
and
respect
them
or
if
they
are
not,
then
they
need
to
to
to
forward
to
someone
who
can
if
it
makes
sense,
because
in
reality,
users
do
not
care
really
how
it's
happening.
It
may
be
a
bit
slower
if
they
have
to
go,
but
at
the
end
of
the
day,
don't
forget
that
initially
you
need
to
have
mtls
certificates.
E
How
do
you
get
ntls
certificate
if
both
the
Gateway
and
these
two
are
using
same
identities
and
no
problems?
They
can
go
through
directly
with
each
other?
Otherwise,
you
need
to
go
to
some
intermediaries.
That
is
adding
the
mtla
certificate
and
for
the
other,
question
about
header
again
depends
on
the
version
for
istio
classic
with
sidecars.
Obviously
we
had
a
header,
but
it's
a
pretty
ugly
one.
It's
a
protobuf
encoded
in
a
header,
yeah,
okay.
We
are
moving
away
from
that
in
ambient.
E
It's
a
baggage
header,
but
we
may
also
kind
of
make
some
changes
because
it's
too
complicated
to
parse
for
TCP.
We
have
the
prefix
a
protobuf
at
the
beginning
of
the
of
the
stream
to
include
the
information,
because
we
also
have
to
deal
with
TCP
ambient.
We
are
doing
HTTP,
connect
and
I,
don't
know
how
how
it's
typical
internally,
we
call
it
H1,
actually
based
overlay
network,
but
it
it
treats
TCP
system
as
https
HTTP
2.
So
everything
is
tunnel
over
HTTP
2.
F
E
Are
some
rfcs
as
well
and
Firefox
Roman
and
all
the
browser
supports
this
protocol?
So
it's
a
more
or
less
standard,
all
three
other
vendors
to
adopt
this
protocol
to
interoperate,
with
with
not
only
with
this
year,
but
with
a
lot
of
infrastructure
that
is
I'm
squid
and
a
lot
of
other
other
components
are
using
the
same
protocol.
So
and
in
this
case
both
TCP
and
HTTP,
have
the
header
and
and
again
we
are
trying
to
use
a
standard
defined
headers,
whatever
exists,
X4
and
other
things.
B
C
E
E
Sandwich
where
you
have
the
Gateway
sandwich?
Well,
it's
not
completely
it's
half
sandwich
in
this
case,
but
there
are
other
cases
where
you
have
Ingress.
E
Yes,
is
that
body
deployment
strategies
that
any
implementation
would
use
I
mean
if
you,
if
you
are
in
a
network
where
the
lower
level
is
doing
like
in
in
Z
tunnel,
you
know
what
ambient
in
ambient
case
you
have
the
security,
mtls
and
everything
handled
by
by
by
a
lower
layer
and
any
Gateway
implementation
should
be
able
to
be
intercepted
or
if
they
know
they
can
get
certificates
and
and
applies
the
rules
and
they
can
bypass
the
interception
and
go
directly.
C
E
E
Important
to
to
focus
on
on
on
user
experience
and
expectation
for
particular,
mandatory
and
and
I
raised
it
before,
we
probably
need
some
indication
of
which
policy
attachments
are
mandatory
or
or
kind
of
hard
like
authorization
and
which
are
kind
of
optional.
Soft
I
mean
if
you
happen,
to
have
X
implementations
and
please
send
some
headers
or
Telemetry,
or
do
some
some
vendor
specific
I
mean
soft
policies
that
would
be
ignored
by
an
implementation
and
and
still
not
have
to
do
to
go
to
an
extra
hope.
C
Actually,
this
has
been
helpful
because
one
of
my
concerns
about
what
are
my
concerns
as
Mike
and
I
were
talking
was
okay.
Are
we
coming
up
with
something
that
will
work
great
for
linkerty
and
that
won't
work
for
istio
at
all,
and
it
sounds
a
lot
like.
Actually,
this
should
work
out,
okay
for
istio,
and
that
actually
makes
me
feel
quite
a
bit
better,
because
I
don't
really
want
to
come
up
with
something
that
won't
work
for
istio.
E
Not
necessarily
is
the
best
experience,
not
necessarily
you
know
easy
to
set
up
or
or
the
most
efficient,
but
we
had
to
integrate
with
a
lot
of
components.
I
mean
we
had
customers
who
have
to
use
squid
as
an
egress
Gateway.
We
have
components
that,
obviously
we
need
Google
components
to
integrate
with
these
two.
So
we
are
spending
a
lot
of
time
to
make
sure
we
interoperate
and
we
simplify
I,
mean
that's
a
Colombian
is
to
have
a
standard
protocol
that
hopefully
others
will
adopt.
For
you
know
TCP
over
http.
E
Yeah,
but
if
not
again,
we
can
make
it
work.
Probably
we
have
so
many
options
that
I
don't
have
no
doubt
that
we
can
make
anything
work.
The
question
is:
if
the
user
will
be
happy
with
the
result
and
and
understand,
what's
happening,
it's
much
bigger
problems,
implementation.
E
Is
that
the
best
default
and
the
easiest
to
implement
and
most
intuitive
and
but
optimization,
if
someone
is
able
to
you,
know
check
all
the
policies
verify
that
they
are
implemented?
Is
that
Gateway
implementation
and
everything
will
be
respected
perfectly
free
to
optimize.
But
the
conceptual
model
should
still
be
that
if
you
have
a
VIP
that
may
not
be
even
in
cluster,
because
we
have
the
concept
in
ambient
of
managed
waypoints,
where
some
multi-tenants,
whatever
external
component,
happens,
to
implement
the
function
of
the
Waypoint.
E
C
E
C
If
they
happen
to
be
from
the
same
vendor,
then
there
probably
are
a
lot
of
ways
that
they
can
optimize
and
that
I
think
is
probably
not
a
bad
thing,
but
I
think
it's
important
that
it
should
work
in
an
unsurprising
way
if
they
are
different.
Vendors,
too.
D
Now
I
think
this
is
good
work
I
think
you
know,
anytime,
that
you
know
you
go
into
something
with
one
assumption
and
then
you
look
at
a
little
bit
closer
and
you've
got
a
a
different
takeaway.
That
means
that
you've
hit
yourself
lots
of
trouble,
so
I
really
appreciate
the
work
that
you've
done
there,
so
I
guess
for
for
if
our
goal
still
is
to
get
gamma
in
070,
what
needs
to
happen
next.
B
I've
got
a
lovely
segue.
What.
C
A
lovely
segue
into
the
0.7.0
Milestone
checkup,
that
was,
that
was
elegantly
done
Keith.
What
are
the
dates
around
0.7.0?
Is
it?
Is
it
far
enough
out
that
it's
reasonable
to
try
to
get
all
of
this
stuff
into
zero
to
seven,
to
zero,
still
and
I
apologize,
because
I
should
have
that
date
right
in
the
top
of
my
head,
but
my
brain
is
full
I'm.
Sorry.
D
I
think
this
was
discussed
yesterday,
Rob
or
Shane.
Do
you
want
to
hop
in
and
give
some
some
feedback
here.
G
Oh
yeah
we're
trying
to
do
we're
trying
to
do
that
prior
to
I'm,
actually
in
the
middle
right
now,
literally
right
now
of
trying
to
get
the
v062
release
out
the
patch
release
out,
we.
B
G
V070
to
be
right
before
kubecon
Amsterdam,
so
you
should
see
some
things
moving
out
of
there
soon
kind
of
we'll
kind
of
shave
it
down
a
little
bit
and
have
a
follow-up
release
for
some
of
the
bigger
things
that
we
don't
think
will
make.
It.
C
Yeah
sorry
I'm
thinking
about
all
the
other
stuff
I
have
to
get
done
before.
Coop
got
an
Amsterdam,
it's
difficult
for
me
to
see
my
way
clear
to
committing
to
having
this
bit
of
interoperability
done
significantly
before
kubecon
Amsterdam,
which
is
not
the
answer
I
would
like
to
give
but
I
think
it's
the
honest
answer.
If.
G
B
G
C
Would
feel
a
lot
I'd
feel
a
lot
better
about
that
personally,
because-
and
let
me
emphasize
this-
is
my
personal
opinion-
I
have
not
talked
to
anybody
else
about
this
et
cetera,
et
cetera.
My
personal
opinion
is
that
it
feels
a
little
silly
to
try
to
formalize
gamma
without
talking
about
the
way
the
service
mesh
and
the
Gateway
interact
with
each
other,
and
so
it
feels
just
as
a
practical
matter.
It
feels
like
it
might
be
smarter
to
Target
that
at
a
0.8
that
happened
shortly
after
kubecon.
A
I
I
think
we
can
basically
get
the
rest
of
this
ironed
out
like
it
could
be
possible
to
one
of
them
is
just
I
have
no
time
to
put
it
into
an
actual
PR
and
the
other
one
was
the
testing
plan
that
was
kind
of
dependent
on
having
the
performance
stuff.
So,
like
I
hope,
we
have
a
good
idea
of
like
what
needs
to
happen
for
those,
and
those
could
happen
in
time.
A
But
yeah
I,
don't
think
that
we'll
have
this
figured
out
in,
like
an
experimental
Channel
ready
to
use
State
yeah
exactly
before
the
zero
seven
zero
release.
E
Yeah,
the
first
silly
question
about
sorry:
if
it's
completely
stupid,
how
would
a
user
know
what
version
it
is
and,
and
what's
the
implementations
I
mean
if
you
have
zero,
if
there
is
any
changes,
the
CRT
is,
do
we
need
to
detect
or
or
how?
How
would
someone
knows
the
version
that
it's
active
in
a
cluster.
H
Every
crd
has
an
annotation
on
it
that
gives
you
the
bundle
version,
so
that
would
be
a
way
to
no.
But
of
course,
our
goal
is
to
ensure
that
every
change
we
release
would
be
backwards
compatible,
so
I,
you
know
the
goal
is
certainly
to
for
it
not
to
matter
significantly
to
implementations.
But
yes,
if
you
check
The
annotation
on
the
crd,
that
should
give
you
a
good
idea.
E
But
if
I
feel
feel
decided,
let's
say
you
have
used
your
ex.
That
is
matching
a
particular
implementation
or
version
of
the
crd
and
the
crd
is
updated
to
a
newer
version
of
that
is
an
extra
viewed.
Is
you
will
have
to
ignore
it
because
it
doesn't
know
about
it?
So
how?
What
is
the
recommended
way
for
implementation
of
of
the
API
to
deal
with
the
CR?
Because
here
this
updated
understand,
independent,
can
be
update
independently
of
the
of
India
Gamma
or
get
implementation
in
the
cluster
and.
H
I
mean
that's
really
the
only
thing
we
can
do.
We
can
recommend
it
is
useful.
I
think
the
the
recommendation
would
be
if,
if
an
implementation
detects
a
newer
version
of
crds
than
it
supports,
it
could
find
some
way.
I,
don't
know
what
to
to
warn
that
the
version
of
crd
is
installed
is
newer
than
the
version
it
knows
about.
H
I
think
that
that
seems
like
it
needs
more
of
a
formalized
thing,
so
yeah
that
that's
worth
worth
filing
an
issue
for
for
a
bit
more
discussion.
You
know
we.
We
definitely
have
a
means
to
understand
what
version
of
the
API
is
installed,
but
we
don't
have
any
kind
of
formal
guidance
on
what
you
do
with
that.
H
Yeah,
you
know
I
I,
know
people
really
don't
like
Gateway
class
and
gateway
gateway,
Club,
a
lot
of
people,
don't
love
interacting
with
Gateway
class,
but
my
my
gut
reaction
would
be
that's
where
this
belongs.
You
know
someone
puts
a
Gateway
class,
they
say
oh
hold
on
this.
Implementation
only
supports
you
know
an
older
version
of
crds
or
it
doesn't
know
about
X
new
features.
That
seems
like
the
place
to
add
it.
H
I,
don't
know
what
that
means
for
mesh
I
I
forget,
do
we
does
Gateway
class
have
a
place?
Do
we
have
any
kind
of
cool.
B
F
C
Clear
about
that
I
was
going
to
emphasize
so
Rob
a
little
while
ago
said.
Some
things
of
a
tune
of
the
hope
would
be
that
these
crds
would
be
Backward
Compatible
as
we
release
further
versions
and
I'm
gonna
call
back
to
a
talk
that
Rob
did
for
what
was
a
contributor
day
at
kubecon
in
Detroit
I,
believe
it
was.
C
C
H
H
Yeah
but
but
I
think
I
think
what
cost
and
said
is
a
good
point
that,
even
though
we
said
backwards
compatible,
we
can
still
add
new
Fields
Oh
yeah
and
when
we
add
new
fields,
we
need
some
way
for
implementation.
Snow,
hey.
There
could
be
new
things
in
here
that
I
don't
know
about.
E
E
C
And
so
forth.
Well
that
was
yeah.
Sorry.
It
took
me
a
second
to
parse
how
to
to
figure
out
how
to
parse
the
different
uses
of
the
word
Gateway
in
there
Daniel
Linker
d2.13
will
support
using
HTTP
route.
To
be
specific,
it
will
support
using
HTTP
route
to
describe
routing
within
the
mesh,
but
Linker
d2.13
will
not
include
a
lingerty
Ingress
controller,
so
it
will
not
understand
the
Gateway
resource
nor
the
Gateway
class
resource.
C
D
No
worries
I
think
one
piece
on
this
interrupt
on
this
backwards.
Compatibility
thing
that
could
be
helpful
is
to
make
versioning
on
the
website
a
little
bit
clearer.
So
there
is
I
I
feel
like
I'm
stepping
into
a
conversation
that's
already
been
had,
but
just
wanted
to.
D
You
know
just
make
it
known.
You
know,
there's
a
you
know
a
GitHub
like
icon
thing
in
the
top
right
corner
of
the
Gateway
API
website.
D
It's
unclear,
you
know
clicking
that
takes
me
to
the
GitHub
page,
but
at
any
point
in
time
it's
unclear
what
version
of
the
documentation
I'm.
Looking
at
it's
unclear
to
me,
you
know
what
is
this
documentation
part
of
oh
061?
Is
there
yet
to
be
released?
A
070
contents
on
the
docs?
How
do
I
look
at
previous
version
of
the
docs
to
make
sure
if
I'm,
on
an
older
version?
D
How
do
I
get
that
previous
version
to
make
sure
the
contract
I'm
using
to
just
view
the
contract
that
my
implementation
is
using
I
think
that
could
go
a
long
way
towards
helping
users
to
and
implementations
rather
in
addition
to
that,
to
make
sure
that
they're
aware
of
what
their
contract
is.
C
H
Yeah
I
I
will
Echo
that
this
has
been
a
long,
a
long
term
goal
for
ages.
I
know,
we've
discussed
it
in
the
past
and.
B
H
I
I
think
everyone's
agreed.
We
wanted
and
no
one
has
had
time
to
do
it.
It
is
way
more
complicated
than
it
seems.
Wow
I,
don't
know
about
way
more
complicated,
but
it's
more
complicated
than
it
seems
on
the
surface.
Obviously
we
can
look
at
kubernetes
upstream
and
they
figured
out
version
Docs.
We.
H
Figured
out
version
docs,
the
the
closest
thing
we
we
did
is
back.
In
the
day
we
we
had
a
way
to
differentiate
between
our
V1
Alpha
One
and
our
V1
Alpha
two,
and
we
had
two
separate
sections,
but
since
then,
we've
just
all
our
docs
have
just
always
tied
to
the
latest,
so
I
think
realistically
what
we
should
do
a
better
job
of
and
what
is
easier
is
when
we're
referring
to
something.
We
should
make
it
clear
what
version
it
was
introduced
in
that's
something
we
can
do
without
versioning
all
of
our
docs.
H
That's
also
something
like
Upstream
does
that
could
go
a
long
ways
instead
of
just
this
is
standard.
Now
this
is
standard
in
X
release.
Oh.
D
That
sounds
like
a
great
opportunity
for
some
Community
wanted
great
first
issue
kind
of
work
for
people
who
want
to
start
contributing
game,
API
of
being
a
part
of
the
contributor
ladder
find
just
finding
out
where
things
are
introducing
crop
referencing
and
submitting
PRS.
There's
a
lot
of
a
lot
of
good
work
to
be
done.
There.
D
I'll
I'll
take
an
action
item
of
actually
creating
a
parent
issue
for
this,
and
anybody
who
wants
to
to
go
gallivanting
through
our
docs
I'll.
Do
it
if
I
have
some
time
but
yeah
any
I'll,
create
a
parent
issue
and
share
in
this
lock
as
well,
so
that
folks
are
aware
of
it.
Cool.
H
A
All
right
so.
A
A
D
So
sorry
go
ahead,
I'm
torn
because
I
I
think
most
of
me
leans
towards
what
I
think
Phil
was
about
to
say
that
you
know
it.
It
feels
weird
to
have
a
gamma
spec
without
the
the
interface
like
the
handoff
boundary
is
like
designed
between
that
being
said,
this
is
a
draft
spec
and
I.
Think
one
of
the
things
that's
important
for
us
to
continue
doing
as
gamma
in
with
kubecon
EU
coming
up.
D
There's
a
good
time
to
talk
about
really
important
things
for
us
is
to
make
sure
we
continue
to
talk
about
what
we're
doing
to
continue
to
push
this
forward,
not
because
of
well
not
just
because
of
like
marketing
and
things
like
that,
but
because,
when
you're
trying
to
create
a
spec,
you
need
to
continue
to
make
people
aware
of
it.
I
say
this
as
a
maintainer
when
you're
when
you're
creating
a
spec,
you
have
to
contain
any
people
aware
of
it
so
that's
top
of
mind
and
that
they
are
coming
to
you.
D
You
know
to
seed
questions,
to
see,
features
and
things
that
that
they
want
to
see
in
that
spec.
So
you
know
a
release
would
help
that
I'm,
not
sure
release
that
justifies
the
means.
We
can
still
talk
about
this
at
kubecon
without
a
without
a
full
release
or
talk
about
it
anytime,
without
a
a
release
to
find
yeah
I'm
a
bit
torn
I
I,
probably
lean
towards
not
releasing
it
and
then
use
kubecon
to
say,
and
the
upcoming
release
and.
D
To
use
that
language,
whether
it's
like
an
imminent
kind
of
thing
to
continue
to
keep
people
talking
about
it,
what
do
others
think.
A
So
I
guess
like
so
this
is
we're
not
like
do
we
want
to
so
like,
even
if
we
wanted
to?
This
is
kind
of
a
question
for
like
Rob
and
Shane
probably
would
gamma
get
through
a
API
review
if
this
is
marked
as
a
TBD
currently
unknown,.
H
You
know
what
we
should
probably
do
is
we
should
run
gamma
through
our
API
review
for
070,
not
as
something
like
we're
actually
targeting,
but
it's
not
like.
Like
hey,
we
would
like
some
initial
feedback,
so
we're
not
completely
shocked
by
what
you
tell
us
and.
D
D
H
I
mean
I
if
I
remember,
it
was
something
that
you
know
so
to
be
clear.
The
way
that
we
usually
do
this
is
we
will
set
aside
sometime
at
the
beginning
of
the
API
review
process,
with
whatever
reviewers
can
make
it
last
time
was
Tim
and
Cal,
and
at
that
point
we
tried
to
we
had
a
few
maintainers
there.
It
was
I,
think
Shane,
Mike
Keith,
my
son,
I
I,
don't
know
I
know,
but
I
couldn't
make
it
to
that.
One.
Okay,.
H
Some
subset
of
people
were
there
to
basically
present
what
we
thought,
and
this
was
to
be
clear,
clear.
This
was
just
a
for
the
sake
of
the
reviewers
you're.
Looking
at
this
huge
set
of
thousands
of
lines
of
changes,
here's
a
high
level
overview
to
get
you
started.
This
was
not
a
let's
review
the
whole
thing.
This
is
just
an
introduction
to
what
we're
trying
to
get
through
this
time.
H
This
is
only
an
hour
long
and
we're
trying
to
cover
everything
in
the
release.
So
it
is
not
you
know
it's
not.
You
know
a
time
for
exhaustive
feedback,
but
it's
a
time,
for
you
know
gut
check
like
does
this
make
sense
to
you,
or
should
we
go
back
to
the
drawing
board
I'd
love
to
try
that
again,
I
think
kind
of
what
Keith
is
saying
he's
saying
here
is
we
got
some
really
high
level
feedback
and
a
desire
to
talk
more
so
coming
back
to?
It
is
probably
worthwhile.
G
B
G
I
think
not
yet,
given
the
light
touch
that
we've
done,
but
you
know
it's
if
you're
going
if
you're
gonna,
if
we're
gonna
take
that
approach,
I
mean
I'm
kind
of
in
a
weird
position
now,
because
I'm
also
a
chair
so
like
I,
have
right
and
I
think
that
we
can
come
up
with
those
suggestions.
But
I
think
that
you
will
be
waiting
a
while.
C
C
What
might
you
recommend
we
look
harder
at
instead,
because
we
have
I
think
we
do
have
some
options.
I
think
that
I
personally
kind
of
feel
like
most
of
those
options,
are
probably
dependent
on
things
like
you
know
the
multi-sider
thing
and
possibly
separating
the
front
end
from
the
back
end
and
a
whole
bunch
of
you
know
much
much
longer
time
frame
sorts
of
efforts
and
it
doesn't
feel
practical
to
pin
everything
on
things
that
are
not
going
to
be
resolved
for
the
next
year
or
so
yeah.
G
To
be
clear,
not
saying
we
don't
do,
service
I
was
more
thinking.
We
don't
have
anything
different
to
say
yet,
including
something
else
or
I
think
good
answers
to
why
it
has
to
be
service.
If
we're
not
there
yet,
then
it
might
not
be
worth
doing
this
exercise
just
yet
gotcha,
especially
right
around
kubecon
time
or
right
before
it,
because
the
response
time
is
going
to
be
very
slow
right
before
gun
time
for
everything.
G
So
that's,
that's
kind
of
my
thinking
is
like
let's
have
some
really
firm
answers
on
why
it
must
be
service
like
I'll
write
up
on
that.
You
know
something
to
really
point
at
and
say.
This
is
why
we
have
to
do
it
this
way
or
not,
and-
and
you
know
an
alternative
is
considered
and
have
that
before
the
next
round
is
what
I
think.
C
Okay,
John
also
just
pasted
in
chat
the
idea
that
hey
you
know
we
could
go
and
create
something
that
explicitly
refers
to
a
cluster
IP
and
isn't
called
a
service,
which
is
an
interesting
thought
that
we
should
at
minimum.
Consider
as
an
alternative
and.
I
D
C
Actually,
certain
that
binding
only
to
service
is
not
the
right
way
to
go,
but
I'm
also
pretty
certain
that
at
this
particular
moment
we
don't
have
a
lot
of
reasonable
other
options,
as
you
know
like
at
this
particular
point.
If
we
don't
allow
binding
to
service,
it's
not
clear
how
we
move
forward.
So
you.
D
Know,
I
I,
don't
I,
don't
disagree,
I
think
what
we
have
is
it's
just
it's
a
pure
like
race
condition.
We
we
are
trying
to
create
a
spec,
but
the
only
thing
available
in
realistically.
D
You
know
not,
including
you
know,
even
when
the
when
the
cap,
the
multiple
service
side
or
cat
gets
merged,
it'll
be
Alpha
like
I'm,
pretty
certain
that's
going
to
be
off
and
that's
going
to
take
a
while
to
get
presentation
to
do
and-
and
so
you
know
we're
looking
at
you
know
a
year
or
so
of
of
not
having
anything
else.
So
in
the
meantime,
we
have
to
do
something.
G
I
agree
and
I
think
that
that
something
is
it's
time
to
start
getting
people
to
commit
to
trying
out
an
experiment,
a
prototype
of
these
things,
the
Gap,
the
development
of
the
gap,
or
rather
the
spec
and
so
forth,
going
forward.
We
can
only
talk
about
it
so
much
like
some
real
practical
things
for
people
to
actually
try
I
mean
we
have.
You
know
we're
getting
there,
but
I'm.
Just
saying
like
reinforcing
that
I
think
we're
at
that
point.
We
need
something.
G
E
There
is
a
proposal
to
have
a
destination
to
be
a
service
import,
and
if
we
go
that
way
with
the
MCS
integration
or
whatever,
then
obviously
it
will
mean
that
mesh
can
also
attach
to
a
service
import.
So
it's
not
going
to
be
service
only
but
service
and
service
import
and
as
we
go
with
egress
and
other.
E
You
know,
kind
of
custom
names
like
arbitrary
host
names,
not
cluster
local
across
they
said
local,
we'll
probably
need
to
introduce
another
resource
similar
with
SEO
service
entry,
where
you
can
define
basically
arbitrary
names
as
part
of
the
mesh,
and
that
will
also
be
some
place
where
we
attach
so
I.
Don't
think
we
we
definitely
are
not
only
because
service
import
is
already
on
the
table
and
I'm
sure
egress
will
also
be
on
the
table
pretty
soon
for
custom
names.
E
So
the
question
is:
is
service
only
one
that
is
forbidden.
We
cannot
attach
to
it,
but
we
can
attach
to
everything
else,
but
that's
again,
not
something
we
can
do.
I
mean
it's
not,
but
but
starting
to
attach
to
other
things,
service,
import
and
something
like
service
entry
would
probably
be,
but
would
a
good
way
to
solve
this
problem
and
also
we
really
need
to
start
discussing
egress
and
and
custom
names.
D
Last
thing,
I
want
to
say,
is
I
think
that
this
conversation,
everything
we
just
talked
about
in
the
last
five
minutes-
that's
the
doc.
We
showed
to
API
reviews,
I.
Think
I,
think
that's
the
conversation
of
rebinding
to
this
logic
that
this
this
thing
describe
this
thing
that
we
that
our
ballot
binding
targets
and
talk
about
the
different
ones
that
we'll
start
with
and
then
how
we'll
add
support
for
others
and
maybe
deprecate
others
moving
forward.
D
I
think
that
is
the
Delta
for
API
review
and
I'll
I
can
take
a
stab
at
writing
something
up
on
that.
So
whoever's.
A
Saying
that
would
be
great
I
fully
agree
with
that
I
think
kind
of,
like
the
one
ask
I
would
have
of
API
reviewers
or
like
a
broader
Sig.
Network
is
kind
of
like
what
Flynn
said.
Look
what
are
the
things
we
should
be
looking
at
we're
one
work
stream,
which
is
largely
been
focused
on
our
project.
I
know,
there's
been
other
stuff
happening
with
splitting
up
service.
It
would
be
great
to
get
more
detail
about
what's
in
progress.
Currently
what
has
been
tried?
A
F
C
F
A
A
Thank
you
so
much
everyone
take
care
and
have
a
good
rest
of
the
day.