►
From YouTube: Gateway API GAMMA Meeting for 20221129
Description
Gateway API GAMMA Meeting for 20221129
A
All
right,
hello,
everybody
Welcome
to
the
November
29th
instance
of
the
Gateway
API
gamma
meeting.
We
have
an
agenda
today,
I'm
going
to
share
my
screen,
so
you
can
see
it
and
today
I
will
remember
to
pull
up
the
size
and
shrink
the
window
a
bit.
So
folks
will
be
able
to
see
so
yeah.
We've
got
a
couple
of
things.
As
many
of
you
know,
we
didn't
meet.
A
All
of
you
should
know
we
didn't
meet
last
week
because
of
the
holiday,
but
to
recap
from
meeting
before
last
week,
I
wanted
to
close
the
loop
on
John's
PR
for
namespace
boundaries.
Flynn
told
us
to
Heckle
him
if
he
didn't
review
it,
but
I
see
some
comments
from
him
on
here.
So
you've
saved
yourself
from
the
heckling.
B
A
I
will
choose
not
to
Heckle
if
you
just
have
to
heckle
the
chat,
but
yeah
we've
got
a
lot
of
of
great
comments
on
this.
I
will
be
fully
transparent,
that
between
a
week
of
PTO
that
I
took
last
week
and
catching
up
on
mail
and
everything
this
week.
I
have
lots
of
good
bit
of
context
on
this,
but
I
do
think
that
we
have
General
agreement
on
Direction.
A
It
seems
like
a
lot
of
folks
are
asking
for,
in
enhancement
on
a
couple
of
things
where
hey
we
want.
The
the
two
from
dichotomy
seems
to
be
the
the
big
thing
people
are
asking
for
service
buying
against
and
the
service
projection.
Alternative
approaches
were
brought
up
and
this
kind
of
Falls
in
line
with
another
topic
on
the
agenda
today,
but
you
know
they're,
like
there's,
been
a
couple
other
people
for
that
personality
as
well
it.
A
A
Now
versus
previously,
we
had
a
lot
of
consensus
before
it
seems
that
as
we've
got
as
we
spread
the
word
to
the
community
some
more,
there
may
be
some
less
consensus
at
this
point
and
that
might
be
worth
considering.
I
don't
want
a
bike
shed
for
bike
shedding's
sake,
but
if
you
have
more
information
as
we've
kind
of
explored
the
limits
of
the
approaches
that
we've
that
we've
taken
it
might
be
worth
reevaluating.
So
I'm
going
to
continue
to
read
up
on
this
get
John.
A
A
C
It
seems
like
there's
General
consensus
that
this
is
a
problem
we
should
solve
and
potentially
at
least
some
consensus,
that
this
is
fine
for
now.
I,
don't
think
anyone
myself
included
thinks
this
is
the
best
option,
though
so
I
don't
know,
I
mean
I'm
fine
like
going
with
this
for
now
and
then
trying
to
iterate
on
it
or
spending
a
bit
more
time.
You
know
before
we
merge
anything
talking
about
it,
but
the
consensus
I've
got
and
I
asked
asked
a
few
other
people
that
hadn't
give
given.
C
B
D
To
summarize
this
John
and
correct
me
if
I'm
like,
if
I've
got
this
way
wrong,
but
I
think
that
the
key
part
here,
the
key
part
of
all
of
this
verbiage,
is
that
you
only
one
route
applies.
You
know
like
if
there's
a
the
question
that
I
had
was:
what
happens
if
there's
a
a
HBO
bound
to
you
know
a
consumer
route
bound
to
a
service
and
there's
and
then
there's
you
know
one
that
doesn't
live
in
the
same
namespace
and
then
there's
a
producer
out
as
well.
D
What
happens
and
the
you
the
trdr
here
is
only
the
consumer
requires
I.
Think
that
Aspen
says,
like
I,
suspect
that
that's
not
gonna
fly
in
the
long
term,
like
we
all
think,
but
like
this,
this
sort
of
will
at
least
get
let
us
get
started
on.
Something
and
I
think
that
at
this
point,
practice
is
more
important
than
Perfection.
D
You
know
getting.
Something
done
is
better
than
than
arguing
about
what
we
should
get
done
anymore
and
so
I
think
I.
Think
Keith.
You
alluded
to
the
fact
that
you
know
there
were
some
questions
from
in
the
API
review
about
sort
of
his
binding
to
serve
as
a
good
idea
and
I
think
that
yeah,
like
I,
you
know
all
the
reasons
why
I'm
kind
of
about
it
and
I
think
that
none
of
those
reasons
have
changed
but
I.
D
D
It's
all
clearly
marked
as
experimental.
We
are
experimenting
if
you're
going
to
experiment
at
some
point
you
have
to
move
from,
go
Duncan
experiments
to
actual
physical
experiments
or
they're,
not
physical,
but
you
know
I
mean
but
actual
experiments
yeah.
You
can't
just
do
thought,
experience
forever
and
I
think
that's
the
point
that
we're
at
now.
A
Yeah
well
said:
I've
I've
been
kind
of
on
the
fence
on
this
and
I
know
myself,
I've
got
a
I
didn't
have
a
bias
towards
Perfection,
which
is
a
very
painful
bias
to
have
at
times
and
yeah
you
what
you
said
really
resonates
and
I'm.
You
know
inclined
and
happy
to
use
the
forward
momentum
that
we
have
on
this
and
just
kind
of
say,
Park
those
reservations,
I'm
glad
we
have
it
here
in
code
review
to
refer
to
and
we
can
iterate
and
do
something
different
for
now.
A
I
think
that's
to
to
just
to
piggyback
I.
Think
that
the
the
fact
that
we're
not
having
to
change
this
the
HTTP
route
resource
is
helpful
in
this
experiment,
because
there's
we
don't
have
to
deal
with
deprecating
one
set
of
changes
or
moving
fields
or
anything
like
that.
We
are
just
adding
semantics,
and
so
this
is
the
perfect
time
to
kind
of
be
slightly
Reckless,
with
the
kind
of
with
the
approach
that
we're
taking,
because
there's
less
to
have
to
undo.
D
So
I
think
that
the
last
thing
I
want
to
say
is
I
think
that,
as
you
said,
not
modifying
HTTP
route
is
one
of
the
biggest
advantages
of
doing
this
not
needing
to
have
another
resources
of
funding
resources.
Something
like
that
is
another
big
advantage
of
it.
So
let
us
it
lets
us
sort
of
play
with
the
behavior
a
little
bit
without
needing
to
go
down
a
deep
sort
of
design
rabbit
hole
on
like
what
would
a
binding
resource
look
like
or
what
would
a
a
mesh
route
resource?
D
Look
like
or
something
like
that
right,
like
you
know,
the
you
I
I
think
that
it's
not
possible
to
add
a
formula
to
to
parent
ref
because
of
the
implicit
assumptions
encoded
in
the
fact
that
the
current
HTTP
ad
is
built
for
Gateway
and
the
from
is
anywhere
I.
Don't
think
that
we
could
really
easily
make
That
explicit
without
substantially
changing
the
contract
and
I
really
don't
want
to
do
that,
because
people
are
already
using
HTTP
route
for
Ingress
a
lot
and
so
yeah
so
like
I,
think,
that's
like
I
said.
D
I
think
the
fact
that
we're
not
changing
HTTP
right
is
a
very
big
deal
and
I
think
that
that
that
we
should
strongly
contraindicate
any
any
changes
to
hit
to
http
right,
because
that's
a
that's
a
relatively
fixed
API.
Now
right
like
it's,
it's
beta,
it
is
heavily
implemented.
We
can't
change
that
now,
not
without
like
big
shocks
to
the
resting
system.
D
A
Yeah
that
makes
sense
to
me
it's
going
to
be
interesting
as
far
as
HTTP
route
goes
because
it
feels
like
you
know.
We
had
an
open
question
of.
Can
we
use
the
same
routing
resources
to
configure
everything,
and
it
feels
like
more
and
more
about
answer
might
be?
No
as
we
need
to
do
more,
things
like
it
would
be
great
to
be
able
to
delegate
everything
to
The
Binding
resource,
but
I
suspect
that
we
may
run
into
some
some
issues
there
as
well.
D
A
I,
after
you
know,
looking
at
the
feedback,
people
are
asking
for
or
the
feedback
inside
the
feedback.
We
think
the
things
people
are
asking
for
the
current
use
of
the
current
HTTP
route
resource
with
parent
ref
and
an
Ingress
use
case.
It
doesn't
feel
like
it's
sufficient
for
all
of
the
granular
control
people
are
looking
for
from
mesh.
A
I
think
I
agree
like
I,
said,
I
think
it's
very
like
we
there's
stuff
we
could
probably
do
with
as
far
as
pushing
some
of
the
functionality
and
logic
Into
The
Binding
resource,
but
we
I'm
just
kind
of
saying
that
that
was
an
early
question
in
gamma
of.
Can
we
do
everything
in
the
same
HTTP
route
resource
and
it's
looking
like?
No,
not
everything
there
are
enough.
A
You
know
sufficiently
enough
use
cases
where
we're
going
to
break
the
bound
to
http
route,
so
we're
going
to
need
something
else
and
I
just
kind
of
just
preparing
ourselves.
For
that
reality
and
like
just
wanting
to
help
people,
you
know
anybody
who
might
be
worried
about.
Oh
that
gamma
fail.
No,
we
it
hasn't
failed.
The
mission
is
still
there.
A
E
My
question
is
really
to
always,
when
you
add
resources
to
make
sure
that
gamma
is
there
something
that
is
specific
to
gamma.
That
requires
us
to
add
them
to
gamma
and
they
do
not
apply
to
gateways,
because
a
lot
of
the
things
that
we
may
need
are
very
likely
to
be
common
with
with
Gateway
authorization.
B
B
E
Just
going
to
say
it's,
it's
not,
nothing
is
off
the
table,
but
should
be
a
very
high
bar
and
and
should
be
very
well
Justified
that
and
also
evaluate
it
if
whatever
you're
describing
does
not
apply
to
gateways,
because
gateways
also
have
similar
needs
in
many
ways,
I
mean
from
before
your
example.
It's
kind
of
also
specific
to
gateways
anyway,
I
think
we're
in
agreement
we're
just
using
different
words,
but
I
think
we
are
fine.
A
Yeah
I
have
to
sum
it
up.
I
think
that
the-
and
this
is
the
benefit
of
gamma
being
so
close
to
Gateway
API-
is
that
we
start
with
Gateway
API
and
using
the
same
resource
like
that's
our
starting
point
rather
than
innovating
something
separate,
and
if
we
need
to
divert
well,
we've
got
documentation
and
justification
for
reasons
for
the
given
those
reasons
that
people
can
look
back
on,
but
you
know
I
think
I
word
it.
We
worried
it.
A
Similarly,
in
the
original,
like
goals,
get
of
gamma,
where
we
is
literally
opposites
back
to
back,
where
we're
not
going
to
create
new
resources
such
as
the
second
query,
new
resources,
but
also
not
going
to
force
functionality
into
a
Gateway
API
resource.
If
we
do
need
to
break,
we
have
to
balance
both
of
those
things,
but
we
always
start
with
trying
to
use
the
same
resource
and
when
we
find
the
constraints
we
put.
A
Okay,
well,
I
missed
the
the
meeting
where,
in
the
in
the
the
actual
Gateway
API
meeting
where
this
was
discussed.
But
I
was
a
part
of
the
API
review
meeting.
It's
very
informative,
very
I
learned
a
lot
from
what
Tim
and
and
Cal
look
at
when
they
were
viewing
apis.
It
was
fascinating
and
we
had
like
a
small
section
toward
the
end
to
talk
about
the
gamma
API
specifically
and
Tim.
A
Tim
Hawkins
had
a
lot
of
a
lot
of
questions
as
I
assumed
he
would
and
the
you
know
the
some
of
the
notes
specifically
are
here
in
this
documentary
too
in
the
agenda.
But
what
was
what
I
wanted
to
kind
of
talk
about?
Is
this
the
second
Point
here
where
there
is
some
work,
some
potentially
related
work
happening
already,
Upstream
in
KK
and
kubernetes
kubernetes,
repo
of
a
of
a
cap
to
potentially
decouple
the
service
resource?
A
We've
talked
here
in
the
past
multiple
times
about
how,
if
you
want
to
use
service,
but
it's
so
dang,
coupled
with
all
these
with
multiple
concerns.
It's
a
it's
a
overload,
a
resource,
it
does
DNS,
it
does
endpoint
management,
it
does
service
Discovery.
In
some
sense,
as
far
as
membership,
and
so
in
the
past,
when
meshes
have
tried
to
add
functionality
to
networking
it
used
to
service
resource
to
do
all
those
various
things
and
the
first
point
that
Tim
and
Cal
said
was
wait.
A
A
Is
there
a
way
we
can
maybe
make
this
more
harmonious
with
the
kubernetes
domain
model
of
what
resources
are
responsible
for
what
parts
of
provisioning
and
he
talked
about
some
potential
work
around
a
kind
of
like
I
forget
the
word
he
used,
but
like
a
shadow
service
or
like
an
empty
service
that
didn't
have
any
endpoints
and
all
it
did
was
Reserve,
that's
the
word.
It
just
reserved
an
IP
address
a
stable
IP
address
so
like
the
kind
of
the
inverse
of
a
headless
service.
A
If
you
will
and
then
could
that
be
enough
for
a
a
mesh
to
bind
to
and
the
endpoints
could
be
Rewritten
or
to
you
could
create
your
own
Phantom
endpoints
like
the
mesh
could
start
creating,
endpoints
or
whatever
in
the
cluster,
to
be
consistent
with
it.
Now,
there's
some
concerns
around
okay.
Well,
how
do
you
get
some
of
the
load
balancing
policies
in
there?
Maybe
maybe
that
can
be
there?
A
Think
that
you
know
the
work
that
we've
done
shows
that
the
community
wants
it
enough
that
there's
enough
of
a
use
case
of
desire
for
us
to
work
together
on
this
and
and
to
kind
of
do
this
right
to
to
quote
Nick,
who
often
says
this,
you
could
usually
get
one
chance
to
make
get
to
break
the
fundamental
assumptions
of
your
user
and
I.
Would
love
I
I
think
this
is
the
chance
to
do
that.
B
A
Tim
said
that
there
that
Antonio
is
he
called
it.
Antonio
is
kept.
I
did
some
digging
and
couldn't
find
a
specific
kept
already.
There
I
found
one
that
was
kind
of
similar
I'm,
not
sure
if
there
it's
somewhat
old,
I,
think
maybe
a
couple
years
a
year
or
two,
the
pr
has
been
out
there.
So
I'm,
not
no
I,
don't
know
if
there's
been
talk
about
pivoting
that
kept
or
or
what
but
I
I
need
to
chat
with
Antonio
to
see
what
the
status
of
that
is.
E
I,
don't
think
that's
a
problem
for
us,
I
mean
we
until
it's
ready,
we
go
with
service
and
when
it's
ready
it's
the
same
pattern,
I
mean
we
attach
to
whatever
it
is
they
Define?
So
we
are
perfectly
aligned.
Nobody
likes
service
too
much.
We
don't
understand
that,
but
practically
speaking
was
the
next
year
or
so,
we'll
have
to
deal
with
it.
A
A
If
you've
got
thoughts
here
or
desire
to
and
or
desire
to
invest
in
this,
then
let's
continue
to
have
these
conversations.
Tim
wanted
to
continue
to
have
these
conversations
so
I
want
to
know
who
you
know
who
can
be
in
that
room
and
the
second
thing,
oh
I,
guess
I
said
the
second
thing
which
was
just
to
you
know,
get
people
involved
and
get
ideas
out
there.
A
B
A
G
D
Sorry
I
didn't
mean
to
I,
didn't
mean
to
make
things
weird.
Just
sometimes
sometimes
sometimes
people
use
the
you
know.
I
am
unmuting
my
video
as
a
means
to
say
you
know,
hey
I
would
like
to
say
something
so
yeah
I'm
here,
yeah
cool,
that's
awesome
and
that's
also.
Okay,
sorry
I
should
probably
maybe
Keith
that's
a
thing
that
we
should
say
at
the
start
of
the
meeting
like
feel
free
to
have
your
feel
free
to
have
your
video
on
or
off
as
you
wish.
D
B
D
B
Up
to
backing
up
to
splitting
service
out
and
such
yeah
I
think
that
that
would
certainly
be
an
interesting
thing
to
talk
about.
Lord
knows,
there's
other
stuff
that
we've
been
kicking
around
at
buoyant
talking
about
policy
versus
routing
which
I
do
not
believe
I
can
talk
about
coherently
today,
but
there
are
bits
of
that
that
are
are
certainly
raising
questions
about
all
right.
So
is
the
service
efficient?
B
A
B
A
A
A
A
We
take
the
one
with
the
most
information
in
most
cases,
but
want
to
chat
about
it
here
or
if
you
want
some
time
to
steal
on
it,
the
pr
is
in
the
chat
but
yeah.
If
you
want
to
chat,
I'll,
say
it
here
now.
If
you
want
to
talk
about
it,
then
raise
your
hand
or
use
the
raise
hands,
function
and
geomass
the
queue
so
go
ahead.
Nick.
D
Yeah
so
I
would
say
my
my
gut
feeling
would
be
that
if
we're
gonna
have
some
sort
of
priority,
it
should
be
more
specific.
But
it's
less
specific.
That's
generally
a
pretty
good
sort
of
guideline
where
he
more
specific
is
like
fire
up.
The
stack
so
like
HTTP
out
beats.
Tls
route
beats
TCP
around
a
new
DP
route.
You
did
TCP
route
and
udprout
are
relatively
orthogonal,
so
maybe
you
can
have
some
different
rules
about,
but
then
both
of
them
being
allowed
on
the
same
service
but
yeah.
A
I
actually
did
some
digging
and
even
though
I
it's
not
documented
anywhere,
but
the
code
in
kubernetes
actually
does
prevent
you
from
having
hold
on
before
I
say
that
I'm
going
never
mind
ignore
that
I'm
going
to
go
back
and
like
look
at
that
again,
because
I
thought
that
TCP,
okay,
you
can't
find
two
TCP
ports
to
the
same
number.
That's
what
that's!
What
the
the
rule
is.
A
D
B
E
D
E
What
I
meant
is
the
protocol
itself
that
you
know
that
you
know
your
DPM
is
all
kind
of
of
discoveries,
and-
and
that's
not
it
because
you
know
in
HTTP
response,
you
have
a
header
specifying
that
HTTP
3
is
supported
and
then
client
can
update.
So
we
don't
necessarily
need
API
level
support,
because
the
protocol
itself
can
handshake
one
versus
two
and
then
via
headers,
indicate
three
supports.
So
Protocols
are
also
way
to
indicate
this
without
ppis
being
too
specific,
and
especially
since
API,
even
if
apis
say
HTTP
3.
D
A
E
I
would
I
would
rather
say
that
HTTP
is
common
and
it's
up
to
protocol
to
negotiate
the
version
and
find
a
different
solution,
because
it's
very
useful
for
the
HTTP.
You
know
from
from
a
technical
perspective.
There
is
nothing
preventing
HTTP
3
to
be
used
and
we
don't
want
to
confuse
people
about
that.
Http
3
is
not
supported
for
whatever
reason
UDP.
We
can
say
that
you
know.
E
B
I
agree
with
the
comment
on
1492
to
the
tune
of
I.
Don't
think
any
of
the
measures
deal
with
UDP
right
now,
so
they
don't
deal
with
HTTP
3,
either
yeah,
and
now
all
that
said,
I'm
totally
on
board
with
the
idea
that
an
HTTP
route
is
by
definition,
more
specific
than
atls
route
or
UDP
route
or
a
TCP
route.
So
I'm
completely.
B
E
A
Yeah
some
Makaya
in
the
chat
says
that
the
real
estate
specify
TCP
UDP.
Yes,
that
is
really
helpful
in
the
for,
like
context
propagation,
on
the
controller
side
for
Gateway
for
mesh,
it's
we
don't
have
listeners
on
a
Gateway.
So
it's
slightly
less
slightly
more
difficult
to
my
point
earlier
when
it
comes
to
the
service
or
maybe
make
that
point
actually
a
service
resource.
There's
no
I,
don't
believe,
there's
even
an
app
protocol
for
H3
at
the
moment
or
quick.
I
The
certainly
an
Iana
standard
for
the
protocol
name,
so
that
should
be
an
unambiguous
right.
I
mean
the
fact
that
people
are
using
HTTP
1.1
right,
like
we
should
actually
adapt
Iana
as
the
Baseline
and
then
some
affordances
for
some
Legacy
things
that
people
have
used
in
the
past,
specifically
HTTP
one
one
on
HTTP
10.
But
that
should
be
it.
A
Okay,
that's
that's
fair!
So,
okay,
I'm
I'm
fine
with
that
I'm
I'm,
now
placing
myself
in
influence
camp
where
I've
got
some
concerns
about
letting
the
protocol
in
or
letting
HTTP
route
for,
UDP
I
think
that
could
get
dicey,
but
I.
Don't
think
we're
far
enough
along
to
care
too
much
about
that
right
now.
A
So
yeah,
if
you've
got
other
thoughts,
take
a
look
at
the
at
the
get
I
don't
know
if
John's
gone,
but
I'll
I'll
follow
up
with
him
afterward
and
just
kind
of
give
the
yeah
just
see.
If
we
can
get
those
precedence
rules
in
the
in
the
Gap
and
I
think
that's
PR
will
be
good
for
Mayan
to
deal
with
conflicts.
A
All
right
moving
on
to
the
the
agenda
yeah
want
to
check
in
on
the
Milestone
here,
so
we
do
have
a
a
gamma
milestone
for
HTTP
routes
to
Market
as
ready
for
leaders
to
try.
Ideally,
this
would
be
finished
and
released
in
070
of
okay.
Api
Target
is
mid
to
yeah
mid
yeah
about
middle
of
of
next
at
the
first
half
of
next
year.
Ideally
q1,
but
you
know
holidays,
and
things
are
always
tricky,
though.
A
A
A
Will
deal
here's
something
that
I
don't
think
we've
done
it
in
a
little
while
we've
got
some
I.
Think
I
see
a
maybe
a
couple
of
new
faces
here.
If
you
want
to
come
off,
mute
and
introduce
yourself
and
let
us
know
you
know,
while
you're
here,
where
you're
from
what
you're
interested
in
then
please
feel
free
to
do
so.
H
Yeah
I'll
go
hello,
everybody,
my
name
is
cage.
Kelly,
hey
I
have
a
nobody,
so
I'm,
just
a
systems
engineer
from
the
Midwest
I've
been
interested
in
the
box
and
what
now
for
the
past
couple
years
and
finally
got
my
way
into
kubernetes
kind
of
gig
and
we're
using
istio
in
somewhere
to
bring
all
their
documentation,
I
thought
about
API
Gateway
into
the
get
on
pages
and
then
found
Candace
meeting
all
the
other
meetings-
and
you
know
I'm
really
interested
in
this
stuff.
So
I
thought
I'd
join.
F
Hi
I'm
I'm,
Liam
I
I
joined
two
weeks
ago,
but
I
didn't
say
anything
I
work
at
tetrade
I.
We
work
on
kind
of
distributed
SEO
and
some
other
stuff
around
there,
and
mostly
here
just
to
keep
an
eye
on.
What's
going
on,
to
see
how
we
can
kind
of
use
the
stuff
and
make
sure
that
our
stuff
is
going,
the
right
direction,
cool.
H
J
Guys
Gabrielle
here
from
Brazil
I'm,
just
some
end
user
guy,
watching
what
what
kind
of
things
are
happening
in
kubernetes
API
and
six
projects
I've
been
trying
to
keep
updated
about
the
things
happening
here
and
I'm
on
the
company
I
work
for
use,
console
as
a
service
mesh,
and
we
are
implementing
Gateway
API
provided
by
console
right
now,
so
I'm
just
watching
where
things
are
going
and
keep
updated.
Thank
you.
Cool.
D
A
We
love
end
users,
I
really
appreciate
you
all
doing
this
and
taking
the
time
to
come,
chat
with
us.
We
really
value
your
opinions
and
points
of
view.
So
you
know,
don't
don't
be
shy
if
you
see
a
doc
and
you
say
that
doesn't
seem
quite
right
or
I
use
it
this
way
or
ooh.
We've
got
this
really
cool
use
case.
Please
share
that
with
us.
We
would
love
to
to
have
your
point
of
view
and
get
some
feedback
on
the
things
that
we're
trying
to
build.
G
Yeah
definitely
I
I
joined
two
weeks
ago,
but
that
was
the
other
time
slot.
So
I'll
introduce
myself
I'm
Thomas
Eckert
I
cut
my
camera
off
because
I
was
eating.
Dinner.
Didn't
want
to
subject
to
you
guys
to
that.
You
you,
folks,
to
that
and
I
work
on
the
console.
Api
Gateway
at
hashicorp,
so
I
work
with
Mike
Morris
Mike
is
out
today.
A
A
Yeah,
so
we
initial
draft
of
the
HTTP
route
get
that
Mike
Morris
put
through.
There
was
some
language,
but
I
have
the
services,
but
we
stripped
it
out
because
we
felt
like
it
was
a
bit
confusing
and
didn't
want
to
leave
anybody
on
the
wrong
path,
and
so
the
you
know
this
issue
with
creative
kind
of
track,
the
you
know
clarifying
language
and
just
to
kind
of
figure
out
what
how
what
do?
A
We
think
about
Hitler
Services
I
thought
about
this
this
on
and
on
a
bit,
and
it's
been
a
decent
amount
of
time
today
and
I.
Think
I
I've
got
a
gut
feeling
that
I
kind
of
want
to
share
and
get
a
some
feedback
on
just
to
make
sure
that
I,
don't
you
know,
haven't
completely
lost
it
I've
got
it
in
a
different
tab
here.
Here
you
go
so
you
know
my
gut
feeling.
There's
questions
about.
Okay,
should
parent
ref
be
for
headless
Services,
the
parent
must
be
the
staple
set.
A
Should
it
be
something
different
and
my
kind
of
POV
is
like
the
helpless
Service,
sorry
that
the
parent
web
should
be
the
service,
like
that's
consistent
from
an
API
perspective,
even
the
kubernetes
networking
perspective,
even
though
it's
a
pod
IP
like
the
service,
The
Headless
service
selector,
still
collects
the
end
points.
We
want
that
to
be
the
thing
you
know,
binding
to
that's
being
binded
being
bound
to
there.
We
go
implementations
in
general.
A
My
personal
preference,
because
one
I
think
undefined
behavior
is
a
can
be
a
forcing
function
away
from
people
doing
things
and
two
I
I
think
that
different
implementations,
depending
on
the
data
plane,
might
have
the
ability
to
do
some
more
complex
matching
and
and
tracing.
Or
what
have
you
so
I?
Don't
know.
That's
just
my
gut
check
and
now
Flynn
and
Nick
have
lined
up
to
tell
me
why
I'm
wrong
so
go
ahead.
B
B
B
B
So
it
makes
me
quite
nervous
to
declare
that
to
be
a
deliberately
undefined
problem.
John
also
pointed
out
in
the
chat,
the
the
actually
I
guess:
that's
not
the
one
in
the
chat.
I
saw
it
on
there
someplace,
but
the
the
issue
where,
if
you
have
two
different
headless
services
that
both
end
up
mapping
to
the
same
set
or
an
overlapping
set
of
endpoints,
then
your
life
can
get
really
complex
too.
So
I'm
nervous
about
calling
that
undefined.
B
B
D
Ahead
Nick,
so
all
I
was
going
to
say
was
that
we
already
have
a
way
to
talk
about
undefined
behavior
in
the
Gateway
API.
We
call
it
implementation
specific
support
that
clarifies
the
thing
that
Flynn
was
saying
about
how
about
portability
between
implementations,
things
that
have
implementation
specific
support.
You
can
do
them
whatever
way
you
like,
but
you
cannot
Port
them
between
implementations.
B
D
I
Yeah
then,
coming
back
to
your
point
about
policy,
if
I
was
reading
between
the
lines,
I
would
say
you
were
inferring
that
there
was
going
to
be
policy
from
a
security
perspective
attached
to
a
service
and
obviously
right
if
we
were
doing
that
with
headless
services.
That
would
cause
ambiguity,
to
say
the
least.
A
A
Also,
personally,
fine
in
thinking
I'll
have
the
services
implementation,
specific
I,
don't
think
we
lose
too
much
by
doing
that,
the
alternative
is
to
is
to
say,
should
implementation
should
maintain
kubernetes
Behavior
like
as
a
baseline,
which
I
think
most
do
anyway,
but
for
the
overlapping
Edge
case
we
say
that
that
is
undefined,
slash,
implementation,
specific
and
implementation.
May
forbid,
it
is
another,
you
know,
is
something
another
dimension
of
that
problem
as
well.
D
A
H
B
A
Do
we
have
strong
opinions
about
maintaining
about
saying
that
implementation
should
maintain
kubernetes,
Behavior,
first
hateful
set
or
sorry
for
Hitler
Services
and
then
just
making
the
edge
case
implementation
specific
or
do
you
think
all
hit
the
service
functionality
should
be
implementation
specific
and
the
key
here
I
think
is
Nick.
Pointing
out
is
going
to
be
conformance
tests.
D
Yeah,
so
that
is
the
defining
thing
about.
The
different
levels
of
support
is
how
conformist
tested
they
are.
Implementation
specific
is
defined
as
there
are
no
conformance
tests
for
this
extended
is
there
are
conformance
tests,
but
you
don't
have
to
run
them
and
core.
Is
there
you?
You
have
to
run
these
conformance
tests.
B
I,
don't
know
what
is
sorry
go
ahead,
I,
that's
not
a
hill
upon
which
I'm
willing
to
die.
That's
just
the
you
know.
My
gut
feel
is
that
my
gut
feel
is
that
there's
enough
stuff
there
that
it
would
be
easy
to
find
that
we're
painting
ourselves
into
a
corner
a
little
bit
too
early
and
if
we
say
implementation
specific
at
the
beginning,
then
it
gives
us
more
of
an
opportunity
to
play
with
it
and
see
how
it
falls
out.
C
C
A
Either,
painting
yourself
in
a
corner
argument
is
interesting
because
I
think
because
so
from
my
perspective,
the
reason
for
not
making
everything
implementation
specific
at
the
outset
and
oh
wow,
we
are
nearly
out
of
time,
but
my
thought
process
on
on
that
was
just
trying
to
maintain
the
user.
Experience
of
oh
I
put
a
mesh
on
on
my
cluster.
A
Now
my
Hitler
services
are
all
acting
up,
and
so
that's
why?
Maybe
it's
a
should,
but
I'm
also
sensitive
to
the
fact
that
not
every
mesh
that
wants
to
be
conformed
with
Gateway
API
at
any
point
in
time
can
can
do
that.
You
know,
can
handle
that
so
yeah
extended
at
the
would
be
the
I
wouldn't
say
it's
core,
but
extended
might
make
sense
for
that.
B
D
I
mean
I,
think
that
things
that
were
implementation
specific
would
have
a
very
hard
time
ever
becoming
core,
because
the
implementation
specific
stuff
is
going
to
stick
around,
but
it
an
implementation
specific
like
a
specific
implementation,
could
become
extended
by
having
conformance
tests
and
sort
of
be
the
Blessed
way
to
do
it.
And
then
so
you
know
like
there
is
an
extended
behavior
that
you
don't
have
to
open
opt
into,
and
you
can
still
do
the
old
implementation,
specific
behavior.
D
A
Yes,
thank
you,
okay,
for
bringing
that
up
so
yeah,
we'll
continue
to
discussion
on
this
and
asynchronously
I'll,
try
and
remember
to
post
a
slap
message,
or
at
least
get
something
in
the
agenda
for
it,
but
thank
you
all
for
attending
next
Tuesday
at
8.
A.M
time
everybody
take
care.
Thank
you.
Thank.