►
From YouTube: Gateway API Meeting (APAC Friendly Time) 20210311
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
We
are
recording
it's
march,
10
2021
and
we
are
going
through
gateway
api
meeting.
We
have
a
few
things
to
cover,
but
mostly
this
is
going
to
be
pr
and
issue
triage
thanks
to
everyone.
There's
been
a
lot
of
pr's
and
issues
coming
in
over
the
past
week
and
I
think
we've
got
plenty
to
discuss
and
I
should.
I
should
note.
A
I
think
this
time
I
added
everything
to
the
agenda,
but
anyone
is
welcome
to
add
anything
to
the
agenda
at
any
point
so
feel
free,
even
during
this
meeting
or
you
know,
in
in
preparation
for
the
next
one,
if
there's
something
you
want
to
bring
up,
don't
hesitate
to
add
it,
but
one
of
the
things
that
I
think
is
top
of
mind
for
me,
and
probably
many
others
is
what
we
want
to
do
for
our
next
releases.
A
A
A
A
B
A
A
Yeah
it
it
requires
a
significant
effort,
it's
something
we
we
want
to
do
once
and
hopefully
only
once
I
I
think
I
would
like
so
here.
Here's
where
I'm
coming
from,
we
keep
on
getting
a
number
of
issues.
If
you
look
at
the
view
on
alpha,
2
milestone
it's
getting
fairly
large
in
that
what
we've
done
is
we've
anything.
That
is
a
breaking
change.
A
We
just
said:
well,
that's
v1,
alpha
2
and
we'll
punt
it
there
and
we
won't
handle
that
yet,
and
that
makes
sense
because
we
can't
do
breaking
changes
while
we're
still
in
v1
alpha
1.,
so
that
makes
sense
at
the
same
time.
What
that's
resulted
in
is
this
relatively
large
backlog
of
work
to
do
that's
just
whenever
we
get
to
v1
alpha
2..
So
at
some
point
we
need
to
solve
the
solve,
how
we
actually
start
developing
v1
alpha
2
features.
A
C
A
Yeah,
you
absolutely
can.
I
think,
where
that
gets
a
little
confusing
is
our
release
structure.
So
let's
say
we
release
v0.3.0
and
we
happen
to
have
v1
alpha
2
sitting
in
our
repository.
We
can
just
say:
well,
it's
not
ready
yet,
but
it
you
know
so
that
so
what
other?
What
I've
seen
some
others
do
is
split
things
out
into
different
branches.
A
So
you
we
could.
We
could
start
on
a
v1
alpha,
2
branch,
but
that
of
course
means
that
everything
you
add
in
v,
one
alpha
one.
You
need
to
make
sure
you're
bringing
it
across
to
v
one
alpha
two.
Alternatively,
we
can
have
a
v
one
alpha,
one
branch
and
then
main
becomes
v
one
alpha
two,
but
ideally
the
simplest
way
we
do
this
is
we
do
all
the
iterative
changes
first
and
then
we
just
switch
and
start
working
on
breaking
changes
towards
v1
alpha
2..
C
So
the
branch
wouldn't
I
guess
you'd-
have
to
handle,
merge
conflicts,
but
it
could
be
the
case
that
we
create
the
branch.
We
don't
bother,
reporting
over
the
v1
alpha
changes
and
then,
when
we
release
it,
we
just
merge
it
in.
Is
that
too
horrible
to
consider
or.
A
C
C
How
we
work
on
v1,
alpha,
2.
yeah.
It
feels
like
having
a
branch
is
probably
very
expensive
for
the
number
of
people
that
are
involved.
A
Yeah,
I
agree,
I
mean
what
seems
like
it
would
be
easiest
it
from
you
know.
Maybe
I'm
missing
things,
but
what
seems
like
would
be
easiest
is
work
on
these
last
round
of
additive
changes.
Bug
fixes
we
want
to
include
in
v1
alpha
1.
get
one
more
minor
release
out
of
v,
one
alpha
one
and
then
transition
to
v,
one
alpha
two
and
everything
in
main
men
is
building
towards
another
release.
That
includes
the
first
release
of
v1
alpha
two.
C
D
E
So
I
think
it
sounded
to
me
like
rob.
You
were
saying
cut
away
the
v
o
three
with
like
finish
off
all
the
additive
stuff
cutter
vo3o
then
get
started
on
v1,
alpha
2
and
then,
when
v1
alpha
2
is
ready,
cut
a
v040
that
one
of
the
change
log
notes
is:
we've
read
the
api
2v1
alpha
2.
D
A
Yeah
that
that
theoretically
is
possible,
I
think
so.
One
of
the
things
we
said
at
the
outset
is
that
v1
alpha
releases
may
still
break,
but
the
actual
api
version
would
only
include
additive
changes
in
bug
fixes.
So
we
we
would
release
additive
changes
to
v1
alpha
whatever,
if
you
want
alpha
1,
but
if
we
wanted
to
break
things,
we'd
release
a
new
api
version
that
would
be
v1
alpha
2.
and
this
matches
my
understanding
of
what
kubernetes
versioning
looks
like.
So
let's
say
we
release
a
v1
beta
1
in
kubernetes
upstream.
A
At
that
point
again,
my
understanding
is,
you
need
to
be
able
to
round
trip
everything
to
any
other
v1
beta,
2,
let's
say
or
v1,
whereas
between
v1
alpha
between
alpha
api
versions,
you,
you
do
have
some
flexibility
to
say.
Well,
I'm
just
going
to
drop
this
this
concept
or
rename
you
know
completely
break
this
part
in
my
next
api
release,
my
next
api
version.
So
I
don't-
and
I
could
be
wrong
here,
but
I
don't
think
that
it's
very
common
to
break
things
within
an
existing
api
version
and
that's
certainly
something
like
we
said.
A
A
C
A
Yeah,
I
think
that's
that's
a
key
point
right
that
as
an
implementer,
you
really
just
want
to
know
hey.
This
is
a
v1.
The
v1
alpha
1
api
exists
in
this
cluster.
I
can
trust
that
that
is
the
v1
alpha
one.
I
know
it
may
not
have
everything
I
think
it
has,
but
it
doesn't
have
just
completely
broken
things
that
that's
been
my
understanding
and
that's
certainly
what
we
kind
of
described
in
our
versioning
guidelines,
but
yeah
open
to
other
approaches
here.
D
D
C
My
general
take
is
that
when
we
go
beta,
all
of
those
get
sort
of
deprecated
pretty
quickly,
of
course
it
depends
on
your
users,
but
the
expectation
is
that
the
beta
will
just
supersede
all
alpha.
A
D
D
C
A
My
personal
preference,
and-
and
this
is
going
to
be
hard
to
get
right,
is
to
really
really
limit
the
number
of
alpha
releases.
I
really
want
by
the
time
I
release
v1
alpha
2.
I
really
want
to
make
sure
we
have
thought
about
every
breaking
change.
We
might
want
to
consider
and
have
it
somehow
incorporated
or
taken
into
account
in
that
api
version
we're
getting
to
a
point
where
an
increasing
number
of
implementations
and
users
will
be
using
these
apis
and
there's
not
going
to
be
a
a
large
appetite
for
breaking
changes.
A
A
A
So
we
need
to
find
the
right
balance
there.
You
know
you
think
of
kubernetes
apis,
it's
pretty
rare
for
them
to
stay
in
alpha
and
not
graduate
to
beta
within
a
year
kind
of
thing,
usually
you'd
say
two,
maybe
three
alpha
release
cycles,
which
may
just
be
one
or
two
off
apis
and
then
it
and
and
then
it
goes
to
beta.
A
So
if
we're,
if
we're
thinking
similar
timelines,
I
don't
not.
No
no
one
said
we
have
to
do
that,
but
that
would
be
somewhere
between
six
and
12
months
from
v,
one
alpha
one
to
v,
one
beta
one.
I
don't
know
if
we
can
achieve
that,
but
that
sure
would
be
nice.
D
Yeah,
I
think
the
point
I
was
just
trying
to
make.
I
think
I
think
we're
gonna.
I
think
it's
more
than
likely
that
we're
gonna
see
enough
issues
that
we're
gonna
have
to
cut
more
than
just
v1
alpha,
two
and
probably
more
than
just
v
one
alpha
three.
You
know
so
it
just
kind
of
comes
down
to
how
many
releases
all
right
are.
C
I
I
think
it
simply
has
to
be
explained
to
the
users
that
either
they
are.
They
should
be
okay
with
the
breaking
changes
and
only
supporting
1.5
versions,
essentially
using
it
in
the
south
estate
or
if
it
really
comes
to
that
there
has
to
be
some
other
strategy.
Maybe
cloning,
the
types
if
there's
more
stability
needed
into
a
different
api
group,
but
that's
not
part
of
this
project.
A
One
concept
that
could
help
us
going
forward-
and
we
don't
have
this
yet-
is
the
idea
of
alpha
fields
or
alpha
concepts
in
in
upstream.
You
can
gate
well,
new
fields
are
always
introduced
as
an
alpha
and
gated
and
default
off
kind
of
thing,
and
that
allows
you
to
just
remove
try
fields
out
on
a
stable
api
and
remove
them
in
the
future,
because
you
only
considered
them
alpha.
A
C
Yeah
my
general
take
is
that
I
wouldn't
be
I
we
should
be
cautious,
but
we
shouldn't
be
over
cautious
right,
like
there
is.
If
things
are
really
off,
we
still
have
even
for
ga,
apis
and
kubernetes.
There
is
still
a
path
to
get
it.
It's
just
it
takes
longer
and
more
work
needs
to
be.
C
A
Yeah,
it's
it's
all
about
setting
appropriate
expectations
and
I
think,
especially
in
v1
alpha
one
and
two
we
can.
We
can
set
clear
expectations
that
things
will
break,
but
if,
if
users
have
been
using
an
api
for
a
few
months,
let's
say
or
longer
and
have
gotten
used
to
it,
even
if
it
says
alpha,
they
may
not
believe
that
breaking
changes.
You
know
I
I
don't
know.
E
Mean
so
I
just
wanted
to
say
yeah.
I
think
that
the
key
thing
to
remember
here
that
the
that
the
primary
consumers
of
the
api
at
this
point
are
the
implementers
not
like
the
the
users
who
are
creating
things
are
running
pretty
early
and
it's
the
implementers
probably
who
are
going
to
pay
the
cost
of
breaking
changes
more
than
the
more
than
users
right
like
we
don't
have
that
many
implementations,
so
the
you
yeah.
E
That's
that's
what
I
was
trying
to
say:
it's
just
yeah,
it's
probably
the
implementers
that
are
going
to
pay
the
cost
right
now
and
for
the
next
little.
While
I
don't.
I
don't
see
a
lot
of
people
like
going
too
hard
on
actually
using
apis
for
reals
until
the
implementations
are
a
bit
more
solid
personally,.
A
Yeah,
no,
I
think
you're
right.
I
I'd
agree
with
that,
but
you
know
the
the
problem
that
we
keep
on
coming
to
is
we
won't?
We
won't
know
every
breaking
change
we
want
to
make
until
we
have
more
users
using
it
and
by
the
time
we
have
more
users
using
it,
we
will
have
breaking
changes,
are
harder,
yeah.
C
E
I
think
that
what
you've
all
been
saying
about
having
you,
having
like
keeping
the
alpha
until
we're
reasonably
confident
that
we've
got
that
the
api,
mostly
dialed
in,
is
like
that's
the
point
of
the
alpha
you,
but
it
would
certainly
be
good
to
be
able
to
move
the
sooner.
We
can
move
this
to
better
the
better,
because
that
sends
a
pretty
clear
signal
to
the
community
that
hey.
This
is
actually
worth
you
spending
a
little
bit
of
time,
having
a
look
at
yeah,
exactly
yeah.
A
Okay,
well,
it
sounds
like
we
have
enough
to
move
forward,
at
least
in
the
next
few
months,
and
that
is
that
we're
going
to
be
working
towards
a
0.3.0
release.
I
can
create
a
milestone
after
this
meeting
to
kind
of
track.
What
we
want
to
include
in
that
0.3.0
release
and
anyone
can
feel
free
to
add
things
that
they
think
would
make
sense.
As
part
of
you
know,
additive
changes
to
v1
alpha
1.
and
then
once
we're
comfortable
with
what
we
have
in
v,
one
alpha
one.
We
can
start
transitioning
towards
breaking
changes
for
v.
A
One
alpha
two-
and
I
know
I
added
this-
you
know
something
like
for
april
for
v1.
Alpha
2,
I
think
more
realistically
april
is
probably
a
reasonable
timeline
for
0.3.0.
I
don't
know.
Does
anyone
feel
that's
reasonable?.
A
I'll
take
silence
as
complete
agreement
as
always
cool
all
right.
Well,
there's
a
lot
of
pr's
and
we've
taken
a
lot
of
time
talking
about
release
timeline,
so
let
me
go
ahead
and
start
running
through
these.
I
tried
to
get
them
in
relative
order.
Last
time
we
went
through
issues
first
and
didn't
make
it
too
many
pr's,
so
flipping
the
order
around
this
time.
A
This
is
a
good
pr
that
I
think
we
may
have
talked
about
earlier,
but
I
wanted
to
revisit
it
because
I
don't
think
we
have
a
complete
conclusion.
Yet
this
is
a
a
good
catch
that
throughout
kubernetes
apis
empty
string
is
used
to
refer
to
the
core
api
and
currently,
in
our
api.
We
have
some
concepts
where
we
default
group
when
it's
not
specified
to
be
our
own
gateway,
api
group.
A
A
A
I
am
increasingly
thinking
for
lack
of
ambiguity.
Maybe
we
should
remove
our
defaults
to
the
networking
group
entirely,
but
I
am
open
to
other
feedback
on
this
one.
Does
anyone
know
of
prior
isn't
that.
C
Yeah,
that
seems
to
be
too
maybe
too
backwards.
Looking
because,
as
things
get
moved
into
the
respective
api
groups,
when
this
just
like,
let's
say
that
we
said
that
okay,
yeah
everything
just
reversed
support,
but
core
is
kind
of
frozen
so
from
here
on
out,
like
all
references,
would
just
have
to
refer
to
those
sets
of
objects
inside
core.
A
Yeah,
I
I
admit
that
a
core
reference
here
is
unlikely
to
be
useful.
I
I,
I
can't
imagine
a
time
where
anyone
is
going
to
let's
get
the
in
route
binding
selector,
where
anyone
is
going
to
want
to
reference
a
it.
Just
it
doesn't
make
sense.
You're
going
you
can't.
There
is
no
core
resource.
That
is
a
route,
and
I
can't
imagine
that
there
ever
will
be.
C
What
I'm
saying
is
that
like
we
should
be
careful
because
right
now,
there's
a
lot
of
types
in
core,
but
then
core
is
frozen.
So,
like
you
know
two
years
from
now,
most
types
will
actually
exist
outside
of
core
and
like
in
that
scenario,
looking
back,
then
it
doesn't
make
sense
to
just
kind
of
forcibly.
A
E
A
Right,
that
is
what
I
was
saying.
I
was
saying
we
could
require
this
field
and
and
remove
a
default
again.
This
would
be
a
breaking
change,
but
that
that
does
just
require
more
yaml
everywhere
and
more
explicit
references,
but
maybe.
C
It's
not
yeah.
Let's
follow
up
with
api,
it
just
feels
unnatural
to
force
default.
It's
like
we
should
be
careful
about
using
precedence
because
precedence
also
like
the
precedence,
was
set
because
everything
was
in
core
or
just
I
don't
know
if
it
was
intended
a
consequence.
It's
just
like.
If
everything
was
already
in
that
situation,
do
we
continue
it
or
the
sort
of
the
thought
process
behind?
It
was
simply
to
make
defaulting
a
natural
thing
that
makes
users
lives.
C
A
Yeah
yeah-
I
I
don't
know
on
this
one
I
can
try
and
follow
up
with
someone
in
api
machinery
to
see
how
strict
that
requirement
is.
I
I
don't
know
that
this
is.
This
is
a
messy
one
and
I
hate
to
go
too
far
away
from
that
precedent
that
isn't
upstream,
but
but
is.
A
C
E
Before
you
move
on
rob,
I
just
wanted
to
make
a
quick
suggestion.
I
think
it
is
possible
for
us
to.
There
is
another
way
to
work
around
this
and
that's
to
say
to
say
to
not
have
the
validation
stop
you
from
doing
using
the
empty
string
and
then
put
like
in
the
implementation
notes
to
say
you
know
to
just
mandate
that
an
empty
string
must
be
treated
as
the
core
api
you
like
you
can
punch.
E
You
can
punt
this
question
for
now
and
say:
if
we
don't,
you
know,
if
you
don't
mandate
it,
then
if
you
don't
empty
thing,
then
it's
the
core
string
to
keep
up
with
the
rest
of
the
things,
but
you,
but
the
default
value
will
be
the
will
be
the
the
yeah.
There
will
be
all
right.
Yeah.
The
networking
group
yeah.
A
Yeah,
I
thought
about
that
too,
and
that
may
be
the
best
solution.
What
made
me
hesitate?
There
is
so
that
would
require
making
group
a
pointer,
as
I
understand
it,
to
differentiate
the
two
and
then
what
you
end
up
with
is
at
least
someone
who's
interacting
with
this
from
yaml
perspective,
there's
a
pretty
fine
line
between
empty
string
and
pointer
when
you're
not
using
a
go
interface.
You
know
when
you're
not
using
go,
there's
a
pretty
fine
line
between
unspecified
and
empty,
and
so
for
them
to
have
such
significantly.
E
A
Cool
well
thanks
for
the
feedback
yeah
this
tricky
defaults
and
tricky
presidents
here
so
I
can.
I
can
follow
up
on
this
one
all
right,
implementations,
documentation.
I
think
this
already
got
merged.
I
added
this
yesterday
yeah.
So
thank
you
shane
for
seeing
this
through
lots
of
good
feedback
on
here,
and
I
think
there
were
a
few
follow-ups
for
different
implementations.
A
Okay,
cool!
Well,
if
I
guess
we
can
leave
it
to
those
implementations
to
clean
up
any
little
bits
they
want
to,
but
it
looks
like
this
is
a
great
start.
I
I
already
looked
through
the
implementation
stocks
on
the
site
and
excited
to
see
it
all
live
great
danny,
and
I
think
this
one
is
yours:
yeah
update
top
docs
for
fields
of
type
local
object
reference.
I
think
this
just
needed
a
bit
of
follow-up.
Oh
you've,
you
yeah,
I
I
haven't
paid
attention.
Is
there
anything
you
just?
D
Okay
and
then
there's
just
some
additional
information
there
on
line
112
about
certificate
authority,
reference,
meaning
that.
A
All
right
mark,
you
had
a
large
pr
here
that
probably
deserves
a
bit
more
discussion
in
this
meeting.
This
is
a
large
and
a
large
overhaul
of
the
main
page.
If
I'm
remembering
correctly,
let
me
go
down
to
the
deploy
preview
mark.
Maybe
do
you
want
to
give
a
little
bit
of
background
on
on
what
you're
thinking
for
these
changes.
F
F
This
api
has
multiple
resources,
and
it
tells
you
that
much,
but
you
don't
understand
really
what's
the
significance
of
that
until
you
get
to
the
this
really
describes
kind
of
why
the
role,
oriented
api
matters
and
shows
kind
of
the
the
different
responsibilities
by
the
roles
where
this
shows
that
you
know,
tls
certificates
could
be
configured
by
the
gateway
by
the
cluster
operator,
but
a
service
rollout
could
be
configured
entirely
by
the
developer,
who
owns
the
route
and
so
that's
kind
of
what
and
then
I
used
that
explanation
as
a
jumping
off
point
to
link
to
a
whole
bunch
of
different
topics
such
as
route
binding,
and
things
like
that.
F
I
I
realize
this
is
a
little
long
and
I'm
fine
to
trim
it
down,
but
I
do
think
it
is
important
to
provide
a
tangible
example
kind
of
like
on
the
the
home
page.
So
when
people
get
it,
they
understand
why
this.
You
know
why
this
increased
complexity.
F
A
Yeah
thanks
for
thanks
for
all
the
work
on
this.
I
I
really
love
this
diagram.
I
think
this
absolutely
at
least
this
diagram
and
the
content
around.
It
belongs
on
the
main
page,
because
to
me
it's
a
really
good
tangible
example
of
what
is
in
scope
for
this
api,
like
what
you
might
actually
use
this
for
and
what
the
different
resources
represent
right.
I
think
this
is
really
valuable.
A
I
like
that,
you
included
you
know
where
policies
might
be
attached,
how
you
know
traffic
splitting
across
namespace.
References
like
these
are.
These
are
all
things
that
are
relatively
new
in
this
api
that
are
cool
and-
and
I
think
this
is
a
compelling
introduction,
my
concern
going
through
it
like
I
really
like
this
getting
started
section
you
revamped
it
some,
I
you
know
start
with
api
overview,
user
guides,
etc,
links
to
gateway,
controller
implementations.
A
There
are
great
things
here,
but
I
think
this
may
be
getting
to
be
a
bit
long
like,
like
you
kind
of
already
said
like
it
may
take
a
while
for
people
to
actually
get
down
here
and
notice,
this
or
notice
the
getting
started,
and
I
think
a
lot
of
the
content
is
good,
but
maybe
not
all
of
it
belongs
on
the
main
page.
But
I
don't
know.
A
Yeah,
that
makes
a
lot
of
sense.
Any
anyone
else
have
any
feedback
or
thoughts
on
this.
F
A
All
right,
well,
the
next
one
is
a
fix
for
an
issue
that
I
had
created
earlier.
There
were
a
couple
small
pr's
that
came
in
that
fixed
this
issue
on
individual
fields,
so
we
were
not
consistently
using
pointers
for
optional
fields.
I
think
someone
from
k
native
found
this
out
as
they
were,
trying
to
use,
go
api
to
and
just
leave
fields
empty
and
that
did
not
work
as
expected.
They
were
being
set
as
empty
string,
and
that
was
validation
error.
A
I
think
that's
approximately
what
happened
so,
even
though
this
kind
of
worked
from
yaml
perspective,
it
did
not
work
for
liko
api,
so
I
created
an
issue
that
this
one
fixes
that
basically
says
we
should
be
using
pointers
for
any
optional
type.
That
is
not
a
map
or
a
slice.
A
I
believe
that's
the
correct
interpretation
here
so
this
api,
this
pr
goes
through
and
just
we
have
a
lot
of
pointers
now
I
want
to
make
sure
I
I
feel
like
I'm,
I'm
certainly
not
the
the
authority
on
this.
This
is
my
understanding
of
what
we
should
be
doing
based
on
the
api
guidelines,
but
if,
if
anyone
else
wants
to
maybe
danny,
I
know
you've
looked
at
these
guidelines
a
lot
too.
If
anyone
else
wants
to
confirm
that
this
understanding
is
correct,
be
good
to
make
sure
before
we
actually
merge
this.
A
A
G
A
Which
selectors,
yes,
you're,
you're
right,
you're,
absolutely
right!
Selector
is
a
tricky
one,
because
a
nil
selector
has
a
very
different
value
than
an
empty
selector
in
in
the
true
interpretation
of
a
label.
Selector,
that's
good.
A
Catch,
I
think,
yeah.
Let
me
let
me
run
through
here
and
run
and
look
at
any
other
label.
Selectors
that
changed
the
one
label.
Selector
that
changed
here
seems
rel
seems
appropriate,
because
this
can
only
be
specified
when
another
field
is
specified
and
when
it
is,
it
is
required
and
empty.
Isn't
you
know?
So
in
that
case
I
think
this
may
be
the
appropriate
change,
but
yeah.
Thank
you
for
reminding
me
about
selectors
and
their
weird
interpretation.
A
A
A
I
might
conflict
with
what
the
mark
with
mark's
pr,
I'm
not
sure,
but
this
this
looks
good,
an
actual
link
to
our
implementations.
Now
that
we
have
it
very
helpful,
changing
cloud
to
kubernetes
engine.
A
All
right,
I
think,
we're
into
issues
there's
a
few
of
these
steve.
Thank
you
for
raising
this
issue.
This
came
up
in
two
rather
long
slack
threads.
That
were
a
couple
weeks
apart,
and
I
think
most
of
us
have
commented
on
here
now,
maybe
steve.
Do
you
want
to
provide
your
current
understanding
of
what
we
should
be
doing
or
what
what
the
consensus
is
and
then
we
can
agree
or
disagree
on
that.
B
Yeah
for
sure
yeah,
so
I
I
had
a
question
implementing
because
the
port
was
optional,
but
I
I
think
looking
through,
and
that
was
done
so
I
was
chatting
with
with
daniel
offline
and
or
in
slack
in
other
places,
so
he
had
made
a
change
to
make
this
optional
and
then,
in
my
misunderstanding
of
how
this
worked,
he
mentioned
hey.
Maybe
maybe
we
should
undo
this,
but
thinking
about
it,
some
more
being
through
some
slack
threads
and
stuff.
B
You
may
want
to
define
the
port
there
differently.
So
I
think
it's
going
to
come
down
to
implementation
in
terms
of
what's
about
or
not
valid,
for
whatever
use
case
you
have,
if
you've
got
the
service
defined,
but
not
a
port
and
vice
versa.
So
I
think
I
think
actually,
as
is
it's
probably
fine,
we
can
close
this,
but
I'm
curious
to
see
what
other
folks
think
as
well.
So.
H
If
you
have
a
service
without
a
port,
what
does
that
mean.
H
B
A
B
A
Yeah-
and
I
think
I
think,
back-end
policy
that
makes
sense
because
back-end
policy
is,
I
want
to
apply
this
to
a
service
or
a
port,
and
I
make
a
service
or
a
back-end
with
one.
In
the
same,
I
guess
in
this
case,
and
in
that
case,
do
you
want
to
apply
it
to
all
of
the
service
or
just
a
specific
port
on
that
service,
or
that
back
end.
If
the
back
end
has
multiple.
D
H
D
Not
a
bad
approach,
I
I
guess
one
option
could
be
is
that
port
is
ignored
if
back
end,
reference
is
set,
so
port
and
kind
of,
as
john
was
just
mentioning,
is
really
only
for
service
name
and
backend.
Ref
is
used
when
you
want
to
use
something
like
a
back-end
policy.
H
Yeah
or
like
they
can
be
implementation
specific
right
because
back
in
ref
everything
there
is
implementation
specific.
We
don't
have
any
standard
things
to
refer
to,
so
maybe
they
use
sport.
Maybe
they
don't,
but
I
don't
really
know
what
we're
going
to
use
back
into
f4.
So
maybe
that
doesn't
make
sense,
but
I
could
imagine
a
port
potentially
being
useful.
There.
D
Is
like,
if
you
specify
a
service
name
or
if
we
alter
it,
to
be
service
and
within
the
service.
It's
the
name
of
the
service
and
the
port
of
the
service
like
to
me
that
just
thinks
like
okay
and
my
my
mental
models
like
okay,
we're
not
forwarding
to
a
service,
we're
not
forwarding
it
to
you
know
a
back-end
policy
to
do
something
else,
with
the
request
before
it
gets
forwarded
right.
If
you
want
to
do
something
else,
then
use
back-end
ref,
which
could
be
a
back
end
policy
and
again
we
either
put
port.
D
As
you
mentioned,
john
under
service,
we
rename
service
name
to
service
and
then
services,
the
name
of
the
service
and
the
port
of
the
service,
or
we
keep
port.
As
is
we
update
the
docs
to
say
that
it's
ignored
or
that
it's
only
used
when
service
name
is
specified
and
then
again
back
end.
Ref
could
be
something
implementation
specific
or
we
could
even
you
know,
or
it's
used
for
back-end
policy.
H
H
Said
about
the
back
end
like
forwarding
to
a
back-end
policy,
verse
forwarding
to
a
service,
and
this
may
be
like
my
service
mesh
bias,
but
to
me
I
always
thought
that
the
back
end
policy
is
just
like
the
server
configuring,
their
settings
and
the
route
just
sends
to
their
service.
They
don't
know
or
care.
H
If
that
has
a
back-end
policy
or
not,
they
can't
not
send
to
that
back-end
policy
like
that's,
not
something
that
you
can
configure
in
the
api,
because
that's
like
the
server-side
configuration
that
they're
setting-
and
it's
not
like
you
would
say
I
want
to
forward
to
the
service
or
the
back-end
policy.
You
just
say
I
want
to
forge
the
service
and
if
they
have
a
back-end
policy,
then
that's
used.
I
don't
know
if
that's
how
the
api
is
meant
to
be
used,
but
that's
how
I
interpreted
it
at
least.
A
That
matches
up
with
my
intent
as
well
back-end
policy
was
was
designed,
at
least
from
my
perspective,
as
as
something
that
was
basically
a
decorator,
something
like
that
augmented
service
or
other
kinds
of
back-end
resources
with
various
bits
of
policy
or
additional
information
that
applied
universally
to
that
specific
backend
or
set
of
backends.
A
So
you
know
some
some
basic
examples
of
something
like
that
would
really
only
be
applicable
to
that
that
specific
application-
let's
say,
regardless
of
what
gateway
or
route
was
talking
to
it,
and
routes
still
just
target
the
back
end
directly
and
back-end
policy
is
just
kind
of
some
extra
metadata
policy,
etc.
That's
associated
with
that
backend,
but
you
would
never
forward
to
a
backend
policy
that
that
was
my
understanding
and
intent,
and
I
think
that's
probably
where
some
of
the
confusion
is
coming
from
here.
D
Right,
and
if
that
is
the
case,
then
I
think
it
comes
down
to
what
do
we
do
with
port
right?
Do
we
change
service
so
that
it's
a
struct
and
within
service?
We've
got
the
name
of
the
service
and
the
port
of
the
service,
where
we
keep
it,
as
is,
and
we
just
update
the
docs
of
port
to
say
that
that
it's
ignored
or
only
used
something
along
those
lines
for
a
service
name.
A
At
least
that's
my
understanding
of
this
configuration
and
there's
there's
no
extra
port
in
backend
ref,
even
though
that's
confusing,
because
we
have
a
field
with
the
same
name
on
backend
policy
that
does
include
port.
This
one
does
not.
D
D
So,
look
at
the
look
at
the
route
and
it's
saying:
okay
forward
to
this
service
on
port
8443,
which
is
the
target
port
of
the
service
which
seems
like
it
could
actually
be
the
service
port
443,
but
then
go
up
and
look
at
right
because
we're
using
a
back
end
policy
here.
That
also
specifies
a
port,
but
it's
a
different
port
right
and
I
get
that
this
probably
looks
like
a
configuration
error.
D
A
This
is
an
example
where
we
really
could
use
a
good
diagram
explaining
the
relationship.
From
my
perspective,
we
have
two
resources
here
that
are
both
pointing
at
the
same
service
and
and
doing
different
things.
C
C
A
H
D
D
E
So
I
think
the
the
important
distinction
here
is
that-
and
it's
really
important
in
this
case-
is
that,
if
you
have
on
the
the
outside
of
the
service,
the
ports
are
80
and
443.
That
means
that,
if
you
need
to
construct
any
urls
like
say
on
automatic
redirect,
then
you
don't
include
the
port.
I
mean
the
thing,
because
the
fact
that
the
service
has
adm
443
on
it
actually
implies
that
the
urls
are
using
the
standard
ports
this.
This
came
up
for
me
when
I
was
doing
some
contour
stuff.
E
That's
the
main
reason
to
to
care
about.
What's
what
the
port
is
in
the
service,
I
think
that,
logically,
it
makes
sense
that
the
services
like
your
load,
balancer
are
making
air
quotes
here,
that
you
can't
see
but
the
and
how
your
implementation
references
that
load
balancer
is
up
to
it,
but
the
in
terms
of
the
the
traffic
path
you're
defining
is
that
you're
you're
saying
that
the
traffic
should
go
to
this
port.
On
the
like
again,
air
quotes,
load,
balancer.
E
Yeah,
so
I
think
that
it's
it's
important.
It's
a
really,
it's
a
subtle,
but
really
important
distinction
that
the
that
I
would
actually
you
to
be
honest
in
the
example
here.
I
would
actually
make
sure
there's
no
target
port
and
just
make
it
so
there's
ports
just
to
make
it
so
that
you
don't
have
to
have
this
discussion,
and
so
it's
a
bit
clearer
to
read.
E
I
think
in
practice,
probably
most
a
lot
of
people
that
will
end
up
using
a
tag
report
but
the
but
the
it
does
make
it
more
confusing,
because
then
you
have
to
understand
that
the
service,
in
this
case
the
service,
will
actually
do
the
sort
of
the
port
translation
for
you
from
port
to
target
port
and
that
the
fact
that
the
implementations
will
look
up
the
target
port
and
use
that
to
actually
forward
the
traffic
to
is
an
implementation,
specific
detail,
not
an
api
thing.
C
C
G
C
G
G
G
G
H
H
H
C
A
there
was
a
reason
to
this
madness.
Why
we
chose
number:
is
that
actually
resolving
all
of
these
flight
and
directions,
for
example,
to
the
name
of
the
port
and
then
from
the
port
to
the
target
port
and
the
target
port
to
the
container
port
on
the
pod?
If
that
actually
incurs
a
performance
penalty
and
a
scalability
issue,
so
we
were
trying
to
use
sort
of
the
absolute
like
numbers
and
to
avoid
those.
A
Yeah,
I
definitely
have
a
preference
to
targeting
the
port
number
and
I
think
it
also
is
relevant,
because
this
same
port
number
can
be
used
for
a
back-end
reference
as
well
as
the
so
instead
of
the
service
name.
So
if
back-end
reference
is
specified
instead
of
service
name,
the
same
port
field
can
apply.
A
And
I
know
we're
we're
way
past
time
here.
I
think
there's
a
couple
clear
follow-ups
here,
one
if
anyone
wants
to
volunteer
this
example
looks
like
it
could
use
some
cleanup.
I
like
the
ideas
to
definitely
change
this
port
that
is
being
targeted
to
443
and
optionally,
remove
these
target
ports.
So
we
don't
have
any
kind
of
confusion
here.
I
think
both
would
be
good
improvements
and
then
it
looks
like
we
probably
need
a
bit
more
discussion
on
the
issue
that
kind
of
started
this.
A
A
Okay,
great
yeah,
if
anyone
can
follow
up
on
this
issue
with
some
of
those
items,
that
would
be
great,
and
I
I
can
create
a
follow-up
issue
as
well
to
to
tackle
that
that
little
example
update,
but
I
know
we're
out
of
time.
So
thank
you.
Everyone
for
the
great
discussion
and
we'll
talk
to
everyone.
Next.