►
From YouTube: Gateway API GAMMA Bi-Weekly Meeting for 20220920
Description
Gateway API GAMMA Bi-Weekly Meeting for 20220920
A
Everyone
today
is
the
September
20th
instance
of
the
gamma
meeting,
unless
you're
like
in
Australia
in
case
I,
think
it's
the
September,
21st
I,
don't
know
time
zones
are
weird
today,
I'm
looking
at
the
rondalk
actually
go
ahead
and
add
your
name
to
the
attendees
section
of
the
agenda,
and
please
remember
that
this
meeting
is
governed
by
the
kubernetes
code
of
conduct
and
make
sure
that
you
are
nicely
making
this
a
safe
space
for
everybody
to
be,
as
we
are
discussing,
I
think
I
didn't
mention
it
yet.
A
But
if
you
have
agenda
items
you'd
like
to
have
a
success
today
go
ahead
and
add
it.
We
currently
have
a
fairly
light
agenda,
but
I
imagine
that
we
will
be
discussing
things
for
a
for
a
while.
A
A
Flynn
mentioned
something
mentioned
about
the
some
two
large
slack
threads
that
were
that
that
are
in
the
Gateway
API
Channel
I
just
want
to
take
a
step
back
and
and
kind
of
reiterate
kind
of
the
way
that
we're
hoping
to
to
to
do
to
do
work
here
in
gamma
and
contributing
up
to
Gateway
API
I'll.
B
Probably
point
out
I
think
those
were
two
really
useful:
slack
threads.
Yes,
yes,
a
lot
of
reading
wow.
A
Yes,
it's
a
lot
of
context
and
the
reason
I
want
to
bring
this
up
is
not
because
it's
a
fun
point.
It's
not
because
these
those
slack
threads
were
off
base
in
any
sort
of
way
or
unnecessary.
Again
again,
those
were
very
useful
information,
but
kind
of
as
a
matter
of
of
I,
guess,
I,
guess,
focus
and
and
reiterating
our
goals.
A
You
know
everything
that
we
are
proposing
here.
As
far
as
talking
about
service,
binding
or
or
method
presentation
things
like
that,
it's
all
within
the
experimental
channel
of
of
Gateway
API
and
to
a
further
extent
we
are
hoping
to
you,
know
to
to
move
quickly.
We
set
that
kind
of
the
outset
of
this
lack
of
buttercream
experiment
with
a
gamma
and
we're
hoping
to
you
know,
like
I,
said,
move
forward
quickly
and
to
iterate
on
on
the
different
approaches
and
so
I.
A
This
has
been
my
limbs
as
far
as
working
on
this,
but
I
think
that
most
will
agree
with
me
that
if
we
get
to
a
point
where
it
doesn't
make
sense
to
continue
in
the
same
approach
that
we've
been
working
on,
then
we
will
pivot
to
something
that
does
make
more
sense.
A
A
What
I
you
know
and
cautious
of
as
as
a
lead
of
gamma,
is
that
we
don't
get
so
caught
up
in
making
something
perfect
that
we
don't
end
up
making
anything
at
all.
There
will
always
be
another
degree
of
another
Edge
case
to
add.
On
another
thing,
you
could
just
write
an
API,
but
I
I
just
want
to
acknowledge
that
you
know
we
all
write
software
for
a
living.
A
C
As
probably
the
person
who
spent
the
most
time
objecting
to
things
on
the
on
the
grounds
that
they're,
not
API,
design
sure
like
100,
agree
like
we
need
to,
we
need
to
get
something
done
and
try
try
using.
It
would
be
better
than
spending
too
much
more
time
arguing
about
what
it
should
be.
A
Agree:
I
do.
C
D
B
One
of
the
prevailing
questions
about
one
of
the
prevailing
questions
that
showed
up
often
in
those
slack
threads,
was
to
the
tune
of
right.
So
is
the
point
of
gamma
to
be
capturing
a
common
API
for
things
that
people
are
already
doing
versus
the
point
of
gamma
to
be
coming
up
with
new
things
that
people
should
be
doing
and.
B
You
know,
I
could
personally
probably
argue
either
side
of
that
particular
question,
but
I'm
leaning
towards
API
for
things
people
are
already
doing
and
as
part
of
that
I'm
leaning
towards
recognizing
that,
even
if
we
think
the
way
the
application
developers
think
about
kubernetes
is
broken,
it's
the
way
they
think
about
it,
and
it's
the
way
they're
going
to
continue
to
think
about
it
and
so
approaching
this
from
the
perspective
of
how
are
people
thinking
about
these
resources
also
feels.
C
C
Have
to
be
yeah,
it
doesn't
have
to
be
right
now,
right,
like
you
know,
you
can
re-educate
people
a
bit
about
things.
That
was
what
we
had
to
do
with
Gateway
right,
like
it's
a
pretty
big
change
from
Ingress
to
Gateway.
C
C
I
have
worries
about
making
the
API
like
extensible
by
doing
stuff
in
some
of
the
ways
that
we've
been
talking
about,
but
I
don't
think
that
I
should
be
the
one
that
gets
to
be
like.
No,
you
can't
do
that
right.
So
yeah.
B
I
think
we
should
just
you
know,
give
you
the
objector
in
Chief,
title
Nick
and
just
just
go
ahead
and
formalize
that
shall
we.
C
Yeah
sure
sure
I
can
I
can
handle
that
so
so
one
other
thing
I
should
be
clear.
On,
though,
is
one
of
the
reasons
I've
been
objecting
about.
This
is
some
of
this
stuff
is
that
I'm
I
have
had
to
get
an
API
past
the
Upstream
API
machine
reviewers,
and
a
lot
of
the
objections
I
am
making
are
the
ones
that
they
will
make.
C
So
you
know
like
be
be
aware
that,
like
you
know
that
you're
gonna
need
to
make
good
cases
for
some
of
the
stuff
that
you're
talking
about,
if
it's
not
if
it
doesn't
fit
in
under
the
API
guidelines,
then
you're
gonna
need
to
have
a
really
good
reason
why
it
doesn't.
Okay,
that's
where
we
are
going
to
need
to
do
that.
Sorry,
you
know
like,
and
but
you.
A
It's
a
good
call
out
there
I'll
just
this
popped
into
my
into
my
head
because
of
some
some
reading.
I
was
doing
the
past
couple
of
days.
Chris
Nova
had
a
article
about
imperfect
systems
and
inevitability
of
imperfect
systems
and
there's
a
quote
in
there
that
more
Plus
Engineering
teams,
but
I
think
is,
is
has
consequence
for
what
we're
doing
here.
A
So
it's
kind
of
similar
to
a
point
that
Flynn
I
think
made
a
second
ago
to
you,
know
Design
Systems,
for
the
army
that
you
have
not
for
the
Army
necessary
that
you
want,
and
you
know
there
are
a
lot
of
things,
I,
think
that
if
we
could
go
back
to
kubernetes
pre-pre
pre
1.0,
if
we
could
change
some
things
and
we
could
other
than
we
would
but
For
Better
or
Worse
like
there
are
lots
of
people
depending
upon
the
API
as
it
stands,
and
there
are
patterns
for
using
those
things
and
we've
got
to
design
for
the
army
of
of
implementations
that
exist
today.
A
At
least
it's
my
perspective
doesn't
mean
that
we
should
that
we
should
just
completely
forget
about
correct
this.
I
I
appreciate
a
lot
of
the
objections
that
Nick
has
raised
because
I
think
it's
important
to
talk
about
them
and
to
go
through
that
process
of
weighing
something
that
might
be
more
technically
correct
versus
something
that
might
have
a
smoothie
experience.
A
Trade-Offs
are
the
name
of
the
games.
What
we
do
so
I
value
that
exercise,
but
I
also
think
that
it's
important
to
remember
that
users
aren't
imperfect
in
their
CI.
Cd
pipelines
are
imperfect
and
you
know
are
likely
going
to
be
imperfect
and
they're
going
to
be
any
in
number
of
imperfections
that
exists
in
the
consuming
systems
and
that's
something
that
we
need
to
be
aware
of.
A
Any
other
thoughts
comments
before
we
go
to
the
next
topic.
A
All
right,
Mike
you've
got
the
floor
with
a
proposal.
F
All
right
so
yeah,
I
guess.
Over
the
past
weeks,
we've
gone
through
We've
shared
the
each
group
mesh
finding
get
proposal
document
thanks
and
I've
gone
through
recently
and
tried
to
clean
up
some
of
the
existing
comment.
Threads
tried
to
clarify
some
of
the
goals
and
non-goals
suggestions
that
seem
to
have
mostly
reached
consensus,
and
after
discussing
with
Keith
and
John
as
the
code
weeds,
we
want
to
propose
to
move
forward
with
the
direct
finding
to
Service
at
with
the
parent
rough
field.
F
We
want
to
acknowledge
that
the
like
other
proposal
that
has
strong
consideration
is
interested
in
new
resource
mesh
service
or
something
similar,
but
there's
a
couple
reasons
why
we
think
that,
even
though,
like
it
may
be
a
little
bit
controversial,
we
think
to
kind
of,
like
the
balance
of
the
trade-offs,
lends
itself
more
towards
the
direct
finding
to
service.
F
So,
to
start
with
kind
of
like
one
of
to
like,
if
I
kind
of
like
Flint's
point
was
that
we
think
this
most
accurately
reflects
how
users
conceptually
think
of
the
way
that
Services
relate
to
each
other
in
the
mesh
correctly
and
then
also
from
the
user
perspective.
This
was
the
most
direct
way
to
support
a
transparent
proxy
implementation.
F
F
It
would
potentially
introduce
a
lot
more
layers
of
abstraction
and
make
it
harder
to
reason
about
where
that
configuration
is
happening,
and
then,
finally,
one
of
the
nice
benefits
of
this-
is
that
it's
flexible,
where
it
does
not
require
any
immediate
changes
to
http
root.
It
does
not
require
us
to
figure
out
how
to
do
experimental
fields
on
HTTP
root,
and
it's
extensible
such
that.
F
So
yeah
I've
gone
through
into
the
document
and
I'm
currently
working
on
adding
some
of
the
context
to
the
mesh
service,
I
I
think.
Ultimately,
the
issue
that
message
is
trying
to
solve
is
an
upstream
concern
with
an
overloaded
service
resource
and
really
the
best
long-term
way
to
solve.
That
is
probably
an
upstream
cap
and
the
approach
that
we're
proposing
with
direct
binding
Service.
It
would
minimize
the
churn,
but
not
foreclose
the
possibility
of
us
moving
to
something
like
that
if
it
has
promise
and
traction
stream.
So
that's.
F
It's
a
high
level
summary
of
kind
of
like
where
we're
at
where
we
landed.
Why
and
I
want
to
first
just
take
questions
from
Flynn
and
then
from
the
Rob
Louis
and
new
neighbor
room.
F
Making
this
into
a
actual
Gap,
rather
than
just
a
Google
doc,
so
it
would.
It
would
I'll
open
an
issue
in
the
Gateway
API
repo
assign
a
actual
Gap
number
to
this
thing
and
bring
it
back
to
the
Upstream
Gateway
API
weekly
meeting.
B
Yeah
for
the
record,
I
need
to
read
this
more
carefully,
since
my
life
has
been
a
little
complex
for
me,
the
last
couple
of
weeks,
but
on
the
face
of
it
I
would
say
yeah.
Let's
do
it,
bearing
in
mind
everything
that
we've
been
talking
about
just
recently
about
the
perfect
being
the
enemy
of
the
good
and
wanting
to
kind
of
nail
something
down
that
we
can
all
play
with
and
really
see.
Okay,
how
does
it?
How
does
it
help
us
or
how
does
it
hinder
us.
B
E
G
I
think
I'm
next,
so
I
just
wanted
to
understand.
I
I
I
should
back
up
a
second
and
say
I
am
excited
to
see
progress
here
and
I
I
agree
with
everyone
can't
let
the
perfect
be
that
enemy
of
good.
Here
we
just
should
move
forward
with
something
with
that
said,
I
am
curious.
You
know
right
now,
I
think
you're
describing
a
parent
ref
of
a
service,
and
you
know,
theoretically,
a
parent
ref
could
be
some
other
thing.
G
One
of
the
things
I've
thought
of
and
I'm
imagining
others
is
what,
if
the
parent
ref
is
a
gateway
at
some
point,
but
that
is
intended
for
mesh
consumption
or
the.
How?
How
do
you?
How
do
you
make
sense
of
that?
How
do
you
how.
G
Like,
let's,
let's
just
go,
you
know
years
down
the
road
and
imagine
that
we
have
a
Gateway
class
cluster
IP,
yeah
Let's,
and
if
we
do
that,
you
know
any
number
of
reasons
that
you
may
want
to
have
a
different
kind
of
parent
ref.
Another
idea
service
import,
other
things
like
that.
How
do
you
know
that
the
parent
ref
is
like
this
route
is
for
mesh.
F
So
yeah
like
one
of
the
things
that
we're
not
proposing
to
implement
yet
but
could
be
a
way
to
help
disambiguate
that
in
the
future,
if
needed
is
adding
a
second
paragraph,
So
Right
Now
paragraph.
It
accepts
multiple
references
to
or
multiple
object
references
you
can
define
a
refer
to
a
surface
and
a
ref
to
a
mesh
representation
object.
If
we
find
that
to
be
necessary.
F
That
also
like
I
think
it
would
be
helpful
to
like,
in
the
context
of
thinking
about
mesh,
Gateway,
implementations
or
service
or
import
like
what
are
the
specific
use
cases
that
they
are
intended
to
model
and
how
like,
what's
the
role
that
HTTP
replaced
in
that
so
yeah?
It
is
like
yeah,
obviously
like
there's.
Definitely.
F
H
Yeah
I
was
just
gonna,
say,
I
kind
of
agree
with
just
nice,
not
with
what
Rob
said
like
I
do
think
that
one
we
should
make
some
forward
progress,
so
I'm
perfectly
fine
with
going
with
this
for
now,
but
I
was
actually
hoping
to
bike
shed
a
bunch
on
like
now
that
we
have
agreement
that
we're
going
to
attach
to
the
service
as
like,
a
concept
which
is
a
huge
agreement
to
have
well
I
mean
tentative
agreement
but
sure,
like
the
actual
syntax
of
that,
like
that's
easy,
just
gonna
throw
up
a
dock,
have
10
options.
H
You
know
bike
shut
the
hell
out
of
it
and
vote
on
it
whatever,
and
we
don't
necessarily
need
to
block
on
that.
But
I
think
we
could.
You
know
reasonably
resolve
that
in
a
short
period
of
time
it
might
be
useful.
H
We
could
certainly
go
with
this
and
then
do
that
afterwards,
though
you
know
you
could
lay
all
the
concerns
like
like
Rob
said
of
you
know
what,
if
what,
if
the
line
becomes
more
blurred
between
match
and
Gateway,
what
gateways
represent?
You
know,
services
that
type
of
thing
there's
also
kind
of
future.
Looking
things
like
okay,
we
need
to
represent
a
hostname
like
how
do
we
do
that
now
right?
H
So
there's
all
sorts
of
things
that
are
relevant
and
I
was
hoping
to
have
written
that
Doc
before
I
came
here,
but
now
I
can
just
talk
about
it.
Conceptually
so
I
was
I
was
hoping
to
write
that,
but
maybe
I'll
do
that
afterwards
and
we
can
go
over
it
later.
E
D
Just
so
I
think
the
important.
D
Here
is
that
parent
ref
will
be
what
we're
attaching
to,
and
service
is
probably
the
most
common
and
the
most
important
to
move
forward
with
and
later
on.
You
know,
vendor
specific
or-
or
you
know
we
can
attach
to
other
things
like
Gateway
class
like
like
I
was
mentioning
we
can
attach
to
you
know.
Whatever
else
we
we
finances
in
a
stateful
set
is
one
important
case
that
we
need
to
address
at
some
point,
but
just
like
we
did
with
HTTP
route
versus
TCP
route
and
other
things
I
mean
it's.
D
One
is
kind
of
moving
forward
because
it's
very
common
and
very
useful
and
the
others
can
you
know,
kind
of
lag
a
bit
behind
and
wait
for
vendors
to
to
think
more
about
what
other
pattern
reps
Maybe,
but
the
important
thing
is
parent
Drive
is
objects
that
that
the
route
is
attaching
to
and
is
no
longer
the
mesh.
So
we
we
will.
If
we,
if
we
ever
need
to
support
multiple
meshes,
we
may
need
an
alternative
way
to
indicate
that
a
particular
route
belongs
to
a
particular
mesh
I
think.
H
Yeah,
so
a
couple
of
questions:
first,
one
is
I
just
want
to
make
sure
I'm
understanding,
The
Proposal
correctly,
so
routing
is
going
to
be
done
based
on
the
coop
DNS
name
of
the
service.
That's
referenced
from
the
parent
ref
is
that
right?
H
Yes,
is
any
other
information
within
the
service
going
to
be
used
or
just
the
DNS
name,
for
it.
F
I
should
add
a
section
to
be
more
explicit
about
the
behavior
if
backend
requests
are
not
defined,
it
may
default
to
sending
traffic
to
the
backend
to
like
the
endpoints
of
the
parent
rough
service.
I
should
add
that.
H
And
then
one
one
other
thing,
so
one
use
case
that
I've
seen
people
have
for
meshes
is
having
multiple
meshes
within
their
system,
so
they
might
have
like
a
a
prod
Mash
staging
Mast
staging
mesh
Dev
mesh
right
and
within
the
control
plane.
They
keep
them
sort
of
fenced
off.
H
So
certain
data
playing
clients
will
do
sort
of
wild
card
queries
and
they'll
get
all
listeners
corresponding
to
a
particular
scope.
I,
don't
see
any
mechanism
within
this
proposal
for
sort
of
sensing
things
off
into
one
domain,
whether
it's
prod
staging
Dev
is
there
any
way
that
you
would
recommend
doing
that,
because
the
issue
that
I
could
see
is
now.
You
have
sort
of
a
blast
radius
of
an
entire
kubernetes
cluster
rather
than
a
particular
configuration
scope.
D
Yeah
and
and
I
think
we
discussed
it
in
the
past,
and
we
agree
to
postpone
this
discussion
about
how
we
fragment
or
have
multiple
measures
until
later
point
and
it's
articular
to
this
I
mean
there
will
be
a
mechanism
issue
as
a
sidecar
import
I
mean
there
are
mechanisms
to
do
it
without
being
tied
to
Route.
It
doesn't
have
to
be
in
HTTP
route
itself.
B
H
I
see
okay,
I
I
will
do
that
cool
I
also
I
should
have
followed
up
on
the
service.
Dns
name
I
mean
there's
sort
of
a
suffix
implicit
to
Kube,
DNS
right
so
I
guess.
That
means
that
it's
not
possible
to
configure
an
arbitrary
hostname
is
that.
F
Correct,
yes,
that's
that's
intentionally
out
of
scope
of
this
proposal,
I'm
considering
that
or
we're
concerning
that
as
like
egress
functionality
to
basically
like
redirect
to
arbitrary
host
names,
that's
good.
A
I
think
I
do
have
a
slight
concern
on
that
front
as
far
as
a
custom
trust
domain
custom.
Trust
me
not
the
right
word,
but
like
a
custom
suffix
because
there
are
I
know
of
you
know,
run
into
it
several
times
of
customers
who
have
like
a
accordion
s,
rule
to
to
redirect
cluster.local
to
something
else.
F
Yeah
yeah
I
got
what
you're
saying
and
costumes
comment
in
chat.
Yeah,
I
I
think
that
would
just
be
easily
to
be
explicit
or
like
don't
hard
code,
cluster.local
like
it.
If
it's
reconfigured
to
something
support
that
reconfiguration.
Basically,
the
intent
is
that
it
will
work
with
transparent
proxy
for
existing
kubernetes
DNS
references
in
the
vanilla
cluster.
However,
that
may
be
configured
and.
C
One
of
the
one
of
one
of
the
you
know:
I,
don't
want
to
be
the
objection
you
got
but
like
one
of
the
things
that
I
think
is
really
important
here.
Is
that
the
is
to
remember
is
that
having
anything
keyed
off
an
unstructured
string
inside
a
field
inside
a
resource
inside
kubernetes
is
a
it's
a
really
bad
API
spell
right,
and
our
hostname
is
an
unstructured
string
right
like
having
to
impute
structure
on
like
onto
a
string
to
make
it
stretch
it
like
effectively.
C
Structured
is
a
really
bad
idea
right
like
and
that's
that's
why
I
have
been
always
been
like
no
don't
use
hostname.
Is
that
that's
the
sort
of
the
rule
that
I'm
taking
that
from?
Is
you
need
to
pull
that
data
apart
and
structure
it
somehow
and
then
use
the
structured
data
as
the
thing
that
you're
taking
off
not
the
unstructured
button,
yeah
so
and.
F
E
That
back
teeth.
A
Yeah
and
cost
and
service
system
chat
before
I
can
get
my
hand
up
fast
enough,
but
as
far
as
the
hostname
field,
that's
on
HTTP
route
is
that
in
in
scope
for
for
this
proposed
change
as
kind
of
a
secondary
and
what
a
semantics
around
it.
If
so,
is
it
a
secondary
match?
A
F
I
will
say
that
it
is
explicitly
included
as
an
or
case
as
like
War
handling
so
like
it
should
not
extend
the
scope
of
what
that
HTTP
route
targets.
I
am
open
to
considering
it
as
an
and
case
to
narrow
that
scope
I'm,
not
as
familiar
with
that.
If
somebody
else
is
interested
in
contributing
that
functionality
to
this
proposal,
but
yeah
I
think
just
I
want
to
avoid
focusing
on
on
the
egress
cases,
kind
of
the
intent
care.
H
F
H
It
was
and
I
I,
don't
think
this
is
non-controversial.
Is
that,
like
apparent
ref
of
service
means
that
we're
matching
on
traffic
to
that
service?
Now?
What
does
that
mean?
Exactly?
H
H
So
if
we
were
to
say
that
the
paragraph
service
means
that
we're
actually
going
to
match
the
cluster
IP
and
that's
how
we
know
that
it's
actually
going
to
the
service
and
the
hostname
is
still
completely
valid
right.
A
typical
use
case
you're
not
going
to
match
on
it
becomes
just
a
header
match,
essentially
typically
you're
not
going
to
do
a
header
match
on
top
of
that
for
the
host
header.
H
H
The
matching
logic
in
the
actual
proxy
is
fairly
straightforward
and
I
believe
some
implementation
is
already
doing
exactly
this
today,
but
I
think
that's
what
makes
sense
to
me,
but
at
the
very
least,
we
need
to
be
very,
very
explicit
on
you
know
what
this
actually
means
like
at
one
time.
Eventually
that'll
be
a
conformance
test,
but
in
the
short
term,
as
part
of
the
gap.
F
E
Yeah
so
I
have
comments.
I
know,
you
know
at
least
what
I
hear
about
my
customers
like
multi-class,
is
here
everyone
multi-class
on
multicaster
right.
You
know
when
people
recommend
you
know
you
want
to
serialized
architecture,
you
want
to.
You,
don't
want
the
one
class
to
go
in
infinitely
right.
So
how
do
we
deal
with
this?
I
mean?
Is
our
API?
This
is
going
to
be
for
looking
at.
Is
it
works
in
the
multitask?
Okay.
H
Yeah
my
opinion-
and
maybe
this
hasn't
been
about
clearly
but
when
at
any
point
where
we
say
service,
we're
not
talking
just
capital
S
service,
but
we're
talking
about
general
service
representations
of
which
their
service
and
service
import
as
part
of
kubernetes.
Already-
and
you
know,
vendors
may
have
custom
ones,
but
the
service
in
part
service,
import,
part
already
kind
of
takes
care
of
the
multi-cluster
right.
That
would
allow
matching
on
you
know:
multi-cluster
services.
E
E
Know
have
the
example,
you
know
I
think
that's
my
I.
F
Think
I
think
that's
a
really
good
question
and
by
like
initial
I
think
it
would
be
good
to
explicitly
add
that
as
part
of
the
step
too,
just
like
how
that
could
be
implemented.
So
I
think,
like
my
initial
consideration,
is
service.
Import
is
a
perfectly
valid
back-end
ref
to
be
able
to
redirect
traffic
following
the
service
import
rules
which
I
I
believe
oh
God
I
forgot
the
exact
implementation,
but
like
targeting
service
rep
should
be
able
to
forward
traffic
to
either
to
that
reposition
representation.
Yeah
implemented
yeah
instance.
F
Sorry,
oh
God,
to
the
instance
of
that
service
within
the
cluster
or
if
it
does
not
exist
within
the
cluster
to
a
different
cluster
in
the
cluster
set
based
on
how
that
service,
import,
DNS
results,
I
think
is
what
it
should
do,
I'm
a
little
fuzzier
on.
If
service
import
should
be
allowed
as
a
parent
ref,
because
I
think,
like
the
typical
case,
is
the
service
owner
who
is
like
producing
that
service
should
be
configuring
to
be
configuring.
E
B
A
couple
of
things
one
of
them
is
I,
have
been
trying
to
keep
up
with
notes
on
this
discussion.
Thank
you,
Mike
in
particular.
You
might
want
to
take
a
look
at
that
and
see
if
I
badly
misrepresented
anything.
B
It
definitely
feels
to
me
reasonable
to
be
able
to
support
having
one
back-end
graph
of
a
service
and
one
being
a
service
import
to
split
traffic
across
clusters.
If
you
want
to
do
that,
it
also
feels
completely
reasonable
to
me
that
the
host
name
should
end
up
being
a
header
match
for
the
authority
of
an
HTTP
request.
B
E
Cool
cool
yeah,
just
a
quick
thing
coming
back
to
the
parent
Point
service
import
is
the
thing
that
causes
the
bit
to
be
allocated
in
the
cluster.
E
C
All
of
the
other
discussion
aside,
it
really
does
feel
like
the
thing
that
I
have
got
the
most
out
of
all
of
this
discussion
to
be
like
is
the
really
the
importance
of
the
distinction
between
the
front
end
and
the
back
end
of
the
service
resource,
the
kubernetes
service
resource
capital,
S,
and
the
other
thing
is
about
the
distinction
between
the
producer
and
the
consumer
of
any
particular
service.
Lowercase
s,
meaning
an
application
right
like
those
are
the
two
like.
C
B
I
was
also
going
to
say
that
kind
of
along
that
line,
the
the
discussion
about
hostname
in
the
other
sense,
where
you're
trying
to
figure
out
how
to
deal
with
egress
I
think
is
going
to
be
really
interesting
in
the
near
future.
Yeah
so
I
feel,
like
the
egress
case,
is
yeah
there's.
There
are
too
many
cases
that
I've
run
across
of
people
who
want
to
use
either
the
Ingress
or
the
mesh
to
talk
to
things
that
are
outside
of
the
cluster
and
so
I
think
we
should
tackle
that
at
some
point
soon.
F
Yeah
yeah
we're
not
egress
cases,
but
we're
already
running
into
that
with
constant
implementation
of
services
off
the
cluster
within
the
mesh.
So
yeah
there's
definitely
concern
for,
unfortunately,
not
at
some
point,
but
thankfully
not
in
this
immediate
scope.
Yeah.
C
One
thing
that
I
would
suggest,
though,
that
you
make
sure
you
include
in
the
Gap
is
that
you
split
out
what
types
of
service
of
the
kubernetes
service
resource
can
be
used
as
a
parent
right.
Can
you
use
an
external?
Can
you
use
a
load,
balancer
Services,
apparently
yeah.
C
So
I
think
those
those
are
just
like
I,
don't
really
mind
like
again
I'm
not
going
to
object
to
any
of
this,
because
I've
done
enough
objecting,
but
but,
like
I,
think
it's
really
important
to
call
out
like
to
make
something
implementable.
That
is
really
important
to
call
out
which
things
should
be
con,
like
which
things
are
valid
parent
Rifts
and
which
ones
we're
going
to
be
like.
C
That
will
never
be
a
thing
that
one
might
be
a
thing,
but
it's
too
hard
and
we're
going
to
do
it
later,
but,
like
I,
think
cluster
IP
is
the
obvious
one.
Where
yeah.
We
all
understand
that
that's
probably
the
one
we're
mostly
talking
about,
but
the
other
ones
are
ones
where
you
just
need
to
make
a
call
now,
definitely
out
of
scope
or
in
scope
or
deferred.
G
Cool
I
just
wanted
to
understand
just
I
think
we've
had
this
conversation
in
the
past
and
I've
lost
track
of
what
the
conclusion
was.
But
is
there
ever
a
goal
for
the
same
route
to
apply
to
a
gate
like?
Would
you
ever
have
a
Gateway
and
a
service,
and
the
same
set
of
parent
rests
for
the
same
route
with
the
intention
of
the
same
routing,
configuration
is
used
for
both.
B
F
So
that
case,
I
would
hope
could
eventually
be
implemented
through
basically
some
form
of
Route
delegation
of
interoperability
between
the
north-south
Gateway,
API
and
Gamma.
So
if
a
service
that
is
defined
as
a
back
end
ref
on
a
HTTP
route
that
is
bound
to
a
Gateway,
if
that
service
also
has
an
HTTP
root,
referencing
it
as
a
parent
ref
to
configure
a
mesh
split,
then
yeah.
F
You're
about
30
a
little
bit
so
like
that
is
a
possibility
that
is
listed
as
a
May
in
this,
rather
than
trying
to
have
a
single
route
buying
to
two
different
things:
foreign.
G
Okay,
yeah,
that's
a
good
answer.
I'll
I
think
that's
all
I
had
I
just
would
emphasize
here
that
it
seems
like
we
should
have
a
very
narrow
starting
point
with
a
lot
of
maybe
as
extension
points
because
there's
so
many
different
directions:
yeah
yeah.
A
So
I
raised
my
hand
before
Rob's
question
and
now
I
can't
stop
thinking
about
Rob's
question
so
I've
effectively
forgotten
what
I
was
gonna.
Ask.
Oh,
oh
I,
remember
I
put
this
in
the
chat.
Do?
Is
there
a
a
list
of
acceptable,
backend,
ref
kinds
and
Upstream
Gateway
API,
and
if
so,
can
we
lean
on
that
for
Gamma,
or
can
we
or
maybe
for
parent,
wrap
or
background
for
some
sort?
A
It
just
feels
like
there
are
perhaps
now
three
different
cases
for
service
a
service
type
resources
use
and
I
can
imagine
it
being
confusing
for
user
to
be
like.
Oh,
you
can
use
a
node
Port
service
here,
but
not
here,
but
not
here.
A
So
that's
probably
worth
a
chart
somewhere
fully
like
a
matrix
fully
showing
when
each
type
of
service
kind
or
service
type,
two
distinct
things
showing
when
those
are
appropriate
for
which
field
do
we
have
to
let
that
Upstream
that
we
can.
We
can
kind
of
add,
and
if
not,
is
it
worth
creating
something
like
that
in
the
for
the
Ingress
case.
C
I
think
in
the
in
the
backender
field
we
say
it
defaults
to
service.
But
aside
from
that,
there
are
no
rules
right
like
and
anything
other
than
service
is
implementation,
specific
support.
C
So
you
know
that
that's
the
sort
of
the
rules
we
have
right
and
so
yeah.
That's
that's
why
I
called
the
made
the
call
out
about
types
you
I
know
for
you
when
I
was
maintaining
Contour
like
we
specifically
ruled
out
having
external
name
types
of
services,
backend
refs,
because
it's
concerning
for
that
use
case,
but
like
there's
nothing
that
stops
you
doing
that
right,
like
there's.
No,
we
haven't
written
any
rules
like
that
into
the
spec.
D
So
I
raised
the
same
problem
on
on
Gateway
subsets
in
history.
We
have
you
know
the
traffic
splitting
and
you
know
very
frequent
case
of
of
upgrading.
Do
we
want
to
have
any
restrictions
on
on
the
reasonable
service
with
labor
selector?
D
Do
we
want
to
restrict
that
backend
refs
are
subsets
of
that
particular
service,
which
would
mean
that
it's
a
strict,
you
know
traffic
split
for
that
particular
service.
Or
do
we
want
to
allow
the
backend
reps
to
be
completely
arbitrary
destinations
and
only
allow
you
know
arbitrary
restriction,
arbitrary
destinations
if
there
is
no
selector?
So
do
you
want
to
add
another
additional
field
or
some
way
to
indicate
that
the
semantics
of
traffic
split
versus
arbitrary?
D
D
But
do
we
want
to
explicitly
select
it
to
to
be
explicit
in
the
API
either
by
you
know,
putting
a
condition
if
it
has
selector
or
not
or
some
explicit
field?
Or
do
you
want
by
default
to
be
always
arbitrary,
because
in
as
an
implementation,
it's
sometimes
it's
good.
If
we
have
the
user
intent
to
be,
you
know
a
traffic
split,
because
it
has
impact
on
how
we
we,
we
we,
you
know
kind
of
implement
it
and
how
we
I.
B
Don't
know
yeah
I
think
I'd
personally
lean
towards
not
dictating
policy
at
that
level
and
if
the
user
wants
to
use
it
as
an
A
B
split,
as
opposed
to
it
like
like
a
B
in
the
sense
of
oh,
do
the
users
like
this
implementation
better
than
this
implementation
versus
load,
balancing
traffic,
split
versus
canaries,
I?
Think
all
that
stuff
is
fair
game
and
we
should
allow
it.
G
Yeah
I
I
think
just
kind
of
piling
on
to
to
that
I
think
I
agree
with
that
approach
that
you
never
know
what
kind
of
service
might
exist.
You
know
one
of
the
examples
I've
heard
of
is
a
selected
a
service.
You
know
in
in
front
of
two
actual
services
with
selectors
for
the
version
that
seems
valid
to
me,
taking
a
step
back.
G
What
I
originally
raised
a
hand
for
was
the
idea
of
what
services
are
supported
in
which
cases
and
it
feels
like
what
we
really
are
looking
for-
is
a
set
of
characteristics
right,
so
a
service
that
has
a
front
end
going
back
to
nixcom
everyone's
comment
about.
You
know
a
service
that
has
a
front-end
a
cluster
IP
assigned
to.
It
is
really
all
that
we
could
have
as
a
parent
ref
and
then
as
a
back-end
ref.
G
We
need
just
a
set
of
endpoints
and
external
name
doesn't
really
qualify
for
that,
but
most
other
things
do
we
do
need
to
write
that
down
somewhere,
but
yeah.
E
E
File
names,
yes,
maybe
I
should
say.
F
Cool
so
I
I've
dropped
a
handful
of
to
do
notes
into
the
middle
of
the
service
resource
parent
Rush
approach.
I
will
follow
up
on
those
after
the
speaking
and
there's
a
few.
That
I
would
definitely
appreciate
some
help
with
such
as
the
specific
types
of
service.
If
somebody
feels
to
add
in
a
paragraph
or
bullet
points
on
those.
B
C
I
would
guess
the
last.
The
last
thing
that
I
wanted
to
call
out
as
just
being
a
thing
to
keep
in
mind,
is
to
be
really
is
to
make
sure
that
we're
I
think
it's
better
to
be
extremely
arbitrary
about
like
who
owns
what
you
know
like
making
it
so
that
you
can
only
attach
the
services
HTTP,
router
and
service
that
are
attached
have
to
be
in
the
same
namespace.
Don't
try
and
be
clever
with
cross
state
and
I
suppose
references
yet
just
be
really
like
this.
C
All
this
whole
system
has
to
be
all
in
the
same
namespace
and
a
story
no
cross
thanks
to
no
support
to
start
with,
because
doing
class
things
is
very
difficult,
really
tricky
and
nasty,
and
so
just
make
it
be.
All
of
these
things
have
to
be
in
the
same
namespace
specifying
a
namespace
other
than
the
namespace.
That
one
of
them
is
in
is
is
an
error.
B
I
think
that
next
steps
for
who's
creating
the
pr
clearly
that
sounds
like
Mike
I
can
do
it.
Yeah
foreign,
the
pr
goal
of
whether
it
emerged
quickly
and
iterate
or
iterate
on
the
pr.
C
I
I
think
in
terms
of
like
admin
stuff,
it
feels
fine
to
me
to
get
the
get
to
an
implementable
State,
not
an
accepted
state,
so
that
then,
like
people
can
Implement
things.
Okay
be
like
hey.
This
is
experiment,
it's
implementable
and
experimental,
and
that
way
people
can
like
try
it
out
and
see
how
it
goes,
because
this
doesn't
need
a
lot
of
changes
to
http
route.
C
Biggest
advantage
of
the
the
pro
ship
that
we're
proposing
here
is
that
we
don't
need
to
do
like
field
level
or
resource
level
changes
to
to
or
already
existing
go
API
resources
right,
like,
let's
put
it,
make
the
putting
this
to
implementable
and
then
having
it
be
like
okay.
Now,
everyone
have
a
crack
at
this
and
see
how
you
go
is
a
like
feels
to
be
to
be
like
effective.
It
lets
us
do
like
a
podcast
of
how
this
will
work,
but
Community
block
right
like
and.
C
A
big
win
personally
for
me,
like
I,
didn't
I,
don't
want
to
go
too
far
down
this
road,
but
one
of
the
things
we
need
to
discuss
at
some
point
is
when
we
actually
do
end
up
releasing
things
for
this.
We
need
to
discuss.
Do
these
things
live
in
the
same
API
Group
as
the
Gateway
API
thinks,
because
maybe
they
shouldn't
right,
like
they're,
going
to
be
different
things
so.
E
C
I,
don't
that
decision
that
question
should
not
be
answered,
discussed
or
answered
right
now.
I
just
wanted
to
put
that
in
your
head
for
something
that
you
need
to
think
about,
so
that
we
can
talk
about
it
later,
but
making
this
marking
this
is
implementable,
not
you
know
accepted
or
whatever
the
state.
The
exact
state
of
the
Gap
is
means
that
you
know
people
can
iterate
quickly.
It's
accepted
that
this
is
like
a
way
experimental.
Even
this
is
a
more
experimental
than
experimental.
F
Cool
yeah
that
sounds
really
good
to
me
and
yeah,
just
like
for
concrete
things
like
the
questions
that
were
raised
in
this
meeting.
To
kind
of
like
give
clarification
on.
Are
we
thinking
about
this?
Are
we
not
Are
there
specific
constraints
that
we
should
add?
That
kind
of
stuff
is
really
helpful
and
I
definitely
do
want
to
include
that
in
kind
of
like
the
get
PR,
the
things
I
don't
want
to
do
is
like
reopen
bike.
Shutting
on.
Is
this
the
right
approach
at
all.
C
Look
as
the
primary
Devil's,
Advocate
Chief,
objective
guy
right,
like
I,
feel
like
I
can
definitive
say.
C
You
know,
I
am
ceasing
to
be
objective-in-chief
for
now,
and
you
know
in
the
interest
of
trying
something
out
and
seeing
what
works
and
what
doesn't.
E
Thanks
I
had
a
lot
of
help,
so
Keith
next
steps.
A
Yeah,
so
Don's
com,
maybe
made
me,
want
to
put
this
bug
out
in
folks
ear.
You
know
we
mesh
representation
and
service
binding
were
kind
of
our
top
level
goals
in
the
short
term.
To
try
to
get
knocked
out.
A
It
sounds
like
with
the
match
representation
with
sorry,
with
the
service
bonding
approach
that
we've
taken,
there's
not
yet
a
need
for
a
mass
representation
resource
which
might
even
be
counted
as
a
win.
Less
less
competition
to
have,
but
I
want
folks
to
start
thinking
about.
What
do
you
want
to
tackle?
Next
I
can.
Speaking
from
my
use
case,
we
have
a
pretty
big
need
around
policy,
specific
authorization
policy,
we're
migrating
from
SMI,
and
so
there
is
currently
a
gap
around
that
in
the
state
of
the
specs.
A
So
that's
I
like
to
spend
some
time
doing.
That.
I
also
believe
that
we
might
maybe,
at
the
point
once
this
Gap
gets
accepted,
that
we
can
start
doing
parallel
streams
of
work
which
is
very
exciting
so
start
thinking
about.
You
know
what
sorts
of
things
you
need
to
see
from
gamma
slash
Gateway
API,
to
really
implement
this
for
your
implementation
and
bring
those
to
the
next
meeting
or
actually
I'll
scratch
that
put
them
in
slack,
and
we
can
start
you
know
seeing
where
folks
have
have
investment
from
there.
G
Hey
yeah,
mine
is
really
short.
I
mentioned
this
in
the
meeting
yesterday,
but
there's
a
contribute
Summit
at
kubecon
we're
hoping
to
get
a
chance
to
meet
with
everyone
in
person.
Talk
through
some
of
these
things
do
some
brainstorming
whatever.
So,
if
you
can
make
it
we'd
love
to
see
you
if
you're,
not
an
org
member
yet,
but
you
want
to
make
it
reach
out
to
one
of
us
maintainers
and
we
can
help
get
you
there.
G
C
Approve
people
who
want
to
become
all
members
and
that
fulfills
the
two
separate
organizations
requirement
so.
C
Probably
yeah,
so
there
are
two
days
pre-events
I
know:
lots
of
people
have
other
events
on
those
those
days.
My
experience
with
the
contributor
Summit
has
been.
It
is
by
far
the
most
useful
thing
that
I
do
at
coupon
by
far
and
in
terms
of
like
actually
getting
work
done
and
learning
about
like
what's
actually
happening
in
Upstream
Cube.
So
you
know,
if
you
are
in
this
call,
I
would
strongly
encourage
you
to
do
your
best
to
try
and
come
to
the
computer
Summit.
A
Rob
I
think
I
saw
something
on
the
API
meeting
yesterday
and
I
may
have
just
missed
it,
but
did
we
get
a
talk
to
the
API?
Get
a
talk
submitted
that
we
can
be
looking
to
attend
our
current
trip,
Summit
yeah.
G
We
formally
submitted
a
couple
things:
one
is
just
a
hour-long
working
session
and
the
other
is
a
talk
about
our
experience.
Developing
crds,
that
kind
of
stuff
so
and
others
are
welcome.
If
you
have
more
ideas,
I'm
sure
we
can
get
time.
C
A
All
right
thanks,
strange
I,
think
I
started
moderating
this
and
then,
and
then
Mike
did
a
really
smooth
job
of
trying
to
stepping
in
there
and
managing
everything
so
appreciate
it,
and
thank
you,
Flynn
for
working
on
notes
and
keeping
our
our
minutes
up
to
date
really
appreciate
the
effort
and
all
the
discussion
as
well
love
working
with
you
all.
We
will
be
meeting
again
on
the
27th
at
8,
A.M
Pacific.
Thank
you
and
you
all
have
a
great
rest
of
your
weeks.