►
Description
Service APIs Bi-Weekly Meeting (APAC Friendly Time) for 20211213
A
A
I
don't
know
it'll
be
a
relatively
lightly
attended
meeting,
but
I
think
we
have
at
least
five
people
that
can
make
it.
So
I
think,
as
long
as
we
have
agenda
items,
I
think
it's
worth
meeting
them,
because
our
two
meetings
after
that
will
be
cancelled,
we've
already
agreed
to
cancel
december
27
and
january
3.
A
So
this
will
be.
This
coming
meeting
will
be
our
last
meeting
of
the
year.
With
that
I
wanted
to
highlight
this
upcoming
release
patch
release.
There's
I
think
it
was
john.
Actually
that
pointed
out
this
bug-
and
thank
you
for
catching
this,
but
essentially,
when
we
added
reference
policy,
we
missed
how
important
omit
empty
was
leaving
omit
empty
accidentally
in
this
json
tag
meant
that
you
could
omit
namespace
entirely
and
that
really
had
no
meaning.
A
It
was
an
invalid
configuration
and,
based
on
that,
I
think
we're
considering
this
a
bug
fix
and
not
an
api
change
so
so
much,
even
though
it
is
technically
also
an
api
change,
but
because
there's
not
really
a
valid
interpretation
of
an
empty
namespace
here.
I
think
this
is
an
acceptable
patch
and
I
also
think
it's
it's
important
to
try
and
get
it
out
before
we
go
to
beta.
A
So
for
those
reasons,
I'm
proposing
a
0.4.1
patch
release
this
matches
up
with
our
versioning
guidelines
roughly
and
how
we
described
releasing
new
versions.
But
this
is
you
know,
a
non-traditional
kind
of
bug
and
bug
fix
and
that
it
does.
It
is
backwards,
incompatible
yeah,
so
that
that
is.
That
is
the
thing.
There's
been
some
discussion
on
the
initial
issue
for
this,
which
is
963
or
sorry
962.
I'll
get
the
the
numbers
right
eventually,
but
that
that's
where
this
is
coming
from
and
yeah.
I
think
james.
A
I
didn't
respond
to
your
comment.
I'm
not
sure
if
james
is
on
this
call,
yet
I
don't
see
him
but
yeah.
It
does
unfortunately
mean
that
you
could
leave
it
blank,
so
I
don't
think
any
of
us
really
realized
that
when
it
got
in-
or
at
least
we
certainly
didn't
catch
it,
but
this
adjusts
that
so
this
is
suggesting
that
we
go
through
the
full
release
process.
Just
so
we
can
fix
this
one
bug.
A
There
was
another
bug
that
was
annoying
that
I'd
like
to
include
in
this
patch
release,
but
that
other
bug
didn't
seem
to
justify
a
patch
release
on
its
own.
But
now
that
we
have
two,
it
seems
worth
cutting
a
release
for
so
I've
just
kind
of
got
these
all
in
order
here,
I
seems
like
so
far.
I've
got
a
few
lg
tms
on
the
the
bug
fix,
and
once
we
get
the
bug
fixing
and
the
versioning
guidelines,
we
can
go
ahead
and
actually
cut
a
release.
A
So
yeah
that
that's
all
I'm
thinking-
and
I
should
I
should
also
clarify
that
I'm
thinking
of
I've,
I've
created
a
new
release,
0.4
branch,
which
mirrors
kubernetes
upstream.
So
this
release
is
really
just
all.
You
know
these
two
patches
on
top
of
the
0.4
0.4.0
release,
we're
not
trying
to
cut
master
as
0.4.1
we've
added
a
lot
more
to
to
our
main
branch.
A
Cool
all
right,
I
will
keep
on
running
then,
but
that's
that's
4.1.
If
you
have
any
any
final
thoughts.
I
do
let
me
know,
but
I
would
personally
love
to
get
this
out
this
week.
I
I
know
we've
got
holidays
coming
up.
As
you
can
see,
we've
got
a
couple
meetings
that
are
going
to
be
canceled
and
not
too
long.
A
I'd
love
to
get
this
particular
patch
release
out
sooner
than
later,
just
so
that
we
don't
have
it
looming
over
us
in
the
new
year,
rather
cut
this
and
then
immediately
shift
focuses
back
to
odot,
5.0
and
beta
so
yeah
with
that,
let
me
hand
it
over,
I
think
ciao
I
saw
you
on
the
call.
Chow
has
proposed
a
new
gap
for
port
matching.
A
This
corresponds
with
an
issue
that
I
think
john
had
raised
last
week
and
we
have
roughly
vaguely
talked
about
port
matching
in
other
contexts
before,
but
this
is
specifically
adding
port
matching
or
port
concept
to
routes
which
maybe
ciao
I'll.
Let
you
describe
the
specifics
of
what
you're
thinking
here.
B
Yeah
sure
so
our
team
is
working
on
a
traffic
management
service
where
servicemen
is
one
of
our
most
important
use
case
and
we
are
using
gamer
api
as
our
interface
on
kubernetes
and
that's
the
background
and
we
find
that
port
matching
is
a
useful
feature
that
we
want
and
it's
missing
in
giveaway
api
today.
So
hence
the
proposal
and
the
purpose
of
now
is
to
add
a
new
viewport
to
two
paragraph
for
destination
port
matching.
B
So
when
the
route
specified
a
port
in
the
parent
rough,
it
means
the
rock
only
applies
to
the
port
specified
there.
And
there
are
a
few
alternatives.
We
that
we
consider
like
adding
port
match,
that
it
gets
struck
into
into
all
routes,
and
we
find
it
doesn't
really
make
sense
for
ingress
use
case.
B
A
Well,
yeah,
thank
you
for
bringing
a
stamp
together
I'd.
I
chatted
with
ciao
a
bit
before
this
about
how
how
we
could
potentially
structure
this
and-
and
you
know
I
I'm
biased-
that
I
think
this
is
a
a
sensible
approach
that
both
makes
sense
to
ingress.
A
You
know
for
ingress
use
cases,
but
also
enables,
I
think,
a
key
use
case
for
mesh
routing.
I
think
this
is
a
you
know,
a
reasonable
approach
I
can
see
you
know.
I
think
this
example
here
of
you
know
a
user
wanting
to
say
I
want
to
expose
my
application
on
port
80,
and,
and
so
they
don't
need
to
know
or
anything
like
that,
they
they
can
just
you
know
they
can
just
say
hey.
A
I
want
to
attach
to
this
gateway,
listening
on
port
80
or
port
443
or
whatever
it
happens
to
be.
That
seems
like
it's
a
useful
concept.
A
I
do
hate
to
complicate
parent
ref,
but
this
feels
like
a
a
pretty
sensible
way
to
to
add
in
this
functionality
I'm
interested
in
what
others
think,
though,
I'm
really
especially
interested
in
yeah
harry,
but
also
interested
in
shane.
Since
you've
specifically
mentioned
you,
you
had
briefly
explored
port
matching
here
in
your
address
matching
gap,
so
interesting
feedback
from
everyone.
But
with
that
open
it
up.
A
I
think
that's
just
as
valid
you
know,
I
think
it's
it's
analogous
to
not
specif,
not
specifying
a
section
name
on
parent
ref
and
that
it's
it's
valid,
so
in
the
sen
in
the
sense
of
gateway.
That
means
I
just
want
to
bind
to
the
entire
gateway.
A
A
Yeah,
that's
a
that's
a
good
question.
I
think
again
it
would
be
similar
to
a
section
name
that
that
is
missing,
like
that.
This
has
very
similar
semantics
to
a
section
name,
and
so,
if
you
specify
a
section
name
that
does
not
exist
on
the
gateway
per
se,
I
think
we
already
have
status
conditions
like.
I
think
it's
an
invalid
reference.
I
I
forget
the
specifics,
but
I
I
think
we
would
have
to
treat
this
similarly,
so
it's
basically
an
invalid
parent
ref.
A
C
Okay
and
then
the
third
thing
that
I
wanted
to
ask
is
the
destination
port
part
is
a
bit.
I
haven't
read
this,
but
when
I
was
just
looking
at
this
during
this
meeting,
it's
a
bit
confusing.
Is
it
destination
of
the
gateway
destination
port
on
the
gateway
or
the
upstream
hub?
A
B
No,
no
good
you're
right
so
yeah
where's
the
destination
of
the
traffic.
A
In
that
case,
and
and
it's
somewhat
clarifies
that
here,
but
I
I
there
it's
vague
enough-
that
yeah
we
should,
we
should
add
a
bit
more
detail
there.
That's
a
good
point.
A
Yeah,
that's
a
that's
a
good
question.
You
know,
I
I
think
section
name
is
a
bit
more
precise
than
port
port
is
a
more
generic
way
of
referencing
a
listener
on
a
gateway
port.
Just
basically
says
I
don't
care
what
listener.
As
long
as
it's
listening
on
80,
whereas
section
name
says
I
want
the
specific
listener
that
it's
a
it's
a
really
tiny
difference.
A
I
I
would
you
know
my
you
know,
I
think,
if
you,
if
we
go
through
the
the
goal
of
this
or
introduction,
I
think
this
is
a
field
that
is
primarily
driven
by
a
you
know,
a
mesh
routing
use
case,
and
it
it's
nice
that
it
also
has,
you
know,
a
reasonable
and
understandable
meaning
for
for
ingress,
but
it
certainly
does
overlap
with
section
name
for
sure,
and
that's
that's
unfortunate
here.
Go
ahead.
Buddy.
F
F
A
Yeah,
that's
that's
a
good
point.
I
you
know
to
go
back
to
the
the
section
name
original
proposal
which
I
think
came
from
me.
I
know
at
that
point
in
time.
The
the
idea
was
that
section
name
was
the
the
simplest
possible
thing
we
could
we
could
think
of
at
the
time,
but
that
we
were
open
to
expanding
it
with
more
capabilities.
A
I
think
the
the
idea
at
the
time
that
had
specifically
come
up
was
some
form
of
selection,
which
we
thought
was
too
complicated,
but
that
there
there
was
still
room
left
to
kind
of
expand
the
upwards
attachment
specification.
I
guess
the
the
parent
ref
specification,
and
I
look
at
that.
I
look
at
this
as
kind
of
a
a
an
extension
of
that,
but
yeah
like
you're,
saying
boy.
I
think
you
I
think
we
should
document
clearly
when
you
would
want
to
use
one
versus
the
other.
G
And
I
have
a
question
towards
ciao
is
and
summing
the
mesh
for
your
use
case.
The
parent
ref
is
not
pointing
to
a
gateway,
object
or
pointing
to
some
other
sdo
object
or
I'm
am
I
missing
something
totally.
B
G
B
A
Yeah
I
just
yeah,
that's
completely
right
and-
and
I
would
say
the
section
name
could
be
useful
for
any
mesh
that
you
know
is-
is
segmented
in
any
any
kind
of
meaningful
way.
You
know
that
some,
I
think
there
are
some
meshes
out
there,
that
segment
by
different
networks
different,
and
so
you
may
want
to
say
I
want
to
attach
to
this
mesh
on
a
specific
network
or
on
a
specific
yeah.
A
Again
I
don't
know
the
specific
implementations,
but
I
think
there's
space
for
implementation,
specific
use
cases
of
section
name
on
non-gateway
resources,
but
the
only
thing
we've
defined
for
section
name
in
a
consistent
like
core
way
is,
is
really
that
gateway
what
it
means
on
a
gateway.
G
G
B
Yes,
for
our
crd,
we
don't
section
name
is
not
meaningful
in
our
security.
A
Cool
well
yeah,
I
think,
there's
a
there's
been
some
great
feedback
on
this
already,
I'm
trying
to
make
sure
I
didn't
miss
anything
in
chat,
also
yeah.
I
think
I
think
this
is
everything,
but
please
definitely
add
comments
to
this
to
this
gap
I
or
bowie
did
you
have
any
additional
thoughts
here.
F
A
Yeah,
I
think
that
port
matching
is,
is
a
fairly
common,
well,
a
very
common
capability
that
you
would
want
for
mesh
routing
and
child.
I
think
you
would
know
better
than
me
on
that,
but
I
think
that's
important
for
your
use
case
right.
B
Yeah
and
two
to
one
boy's
question:
we
can
certainly
use
a
section
name
to
for
point
matching,
but
that
will
complicate
the
validation
on
on
section
day.
B
There
was
a
proposal
earlier
to
set
to
use
to
use
the
to
set
port
number
in
in
section
900
paragraph
and
that's
one
of
the
one
adoption
as
well.
F
B
H
Having
both
of
these,
both
section
name
and
port,
makes
sense
to
me
from
perspective
of
consoles
implementation
of
this,
like
I'm
seeing
port
as
basically
promoting
something
that
could
potentially
be
encoded
into
a
string
in
implementation
specific
way
in
section
name,
but
promoting
like
a
common
config
up
to
a
more
explicit,
more
like
first
class
interface
and
reserving
section
name
for
like
the
things
that
could
be
more
implementation.
Specific.
A
Yeah,
that's
actually
a
really
good
way
to
describe
it
that
I
I
like
that
take
on
it.
You
know
I
did.
We
briefly
discussed
this
this
concept.
Last
week
there
was
the
issue
that
kind
of
inspired
this.
This
gap
was
discussed
last
week
and
I
I
think
the
you
know
at
least
I
think
both
of
these
alternatives
were
discussed
in
that
issue,
and
I
think
you
know
the
of
the
discussion
that
that
existed
there.
A
I
think
there
was
just
some
level
of
discomfort
with
the
idea
of
overloading
section
name
to
basically
be
used
for
an
end
to
be
used,
for
you
know
something
that
is
as
common
and
well
understood
as
a
port.
You
know
port
number
yeah
that
yeah
that
that's
basically
the
the
background
I
can
think
of
on
this,
but
I
I
like
mike's
description
here
as
well.
I
think
that's
a
good
way
to
describe
this
proposal.
A
Awesome
well,
hey
thanks
for
the
the
good
discussion
on
this
and
thanks
again
to
ciao
for
getting
this
gap
together
here.
A
So
I
guess
rob.
A
Yeah,
I
don't
think
we
have
consensus
yet
I
I
would
like
some.
I
would
like
to
get
some
discussion
going
on
this
gap
itself.
I
you
know
there
are
a
few
people
out
of
today's
meeting,
but
you
know
if
it
seems
like
there's
at
least
some
support
for
this
gap,
and
so
I
you
know
if,
if
you
like
this
idea,
just
please
comment
on
on
the
pr
would
be
good
to
hear
other
use
cases
for
this
yeah
yeah,
I
think
like
it,
would
help.
F
If
we
add,
we
have
some
use
cases,
but
it's
it's
like
if
we
can
add
it
to
this
to
just
kind
of
describe
it
because,
as
as
you're
reading
it,
it
kind
of
puts
those
things
in
your
mind.
F
A
Yeah,
I
think
I
think
it
is
at
least
potentially
useful
for
for
ingress
use
cases
but
like
like.
I
do
think
this
is
a
more
generic
way
to
attach
and
maybe
even
easier
to
understand
way.
But
it
is
really
an
alternative
to
section
name
for
ingress
and
that
could
add
some
confusion,
but
yeah.
A
Okay,
well,
yeah.
I
think
what
we
need
then,
from
this
is
really
just
some
some
additional
conversation
on
the
gap
itself.
It
sounds
like
there's
a
bit
more
detail
that
we
can
add
to
the
gap,
but
also
just
some
review
comments.
Thoughts
on
this
process
would
love
to
get
this
in
well
and
to
make
a
decision
on
this
sooner
than
later,
but
you
know,
especially
with
with
holidays
around
the
corner,
but
yeah
thanks
thanks
a
bunch
ciao
for
for
starting
this
process
off.
D
A
Cool
all
right.
Well,
that's
that's
a,
I
think,
a
decent
transition
into
the
next
item.
I
wanted
to
discuss
today
and
that's
at
some
point.
We
need
to
define
a
cut
off
for
new
features
in
o50.
A
I
know
we
want
to
get
to
o50
relatively
soon.
We
want
to
release
a
beta
early
next
year
I
and
at
some
point,
if
we
want
to
get
to
beta,
if
we
want
to
cut
that
release,
we
need
to
stop
adding
new
features
and
start
working
on
cutting
another
release,
as
we
saw
last
time
with
ofuro.
It
takes
a
while
to
get
the
final
approval
from
our
sig
network
reviewers
in
upstream,
and
so
we
we
need
to
add
some
buffer
time
for
that
as
well.
A
So
really
what
I,
what
I'm
trying
to
do
with
this
item
is
just
run
through
the
gaps,
I'm
aware
of
try
and
understand
current
status
and
maybe
at
the
same
time
try
and
set
some
kind
of
goal
or
target
date
where
we
want
guests
to
either
be
in
or
consider
them
cut
off.
From
this
release,.
A
So,
first
off
the
the
main
gaps
of
this
release
so
far
have
been
redirects
and
rewrites
that
one
is
fully
merged
fully
in
that
will
be
included
in
the
next
release
unless
we
have
any
strong
reservations,
but
that
is
that
is
it.
Shane
has
led
the
address
matching
the
gap
has
merged.
I
think
shane
correct
me
if
I'm
wrong,
but
I
think
you're
about
to
start
on
the
implementation
of.
E
A
Cool
great
thanks
and
then
the
other
two.
The
final
two
here
are
much
earlier
in
the
stage
here.
One
is
port
matching.
We
just
discussed
that
today
gap
is
proposed
and
we're
we're
moving
and
finally
is
route.
Inclusion
where
there's
a
a
draft
document,
but
this
one
feels
like
it
may
be,
not
quite
as
far
as
along,
at
least
for
the
complexity.
It
might
add.
A
I
think
that
it
feels
like
to
me
address
matching
is
for
sure
going
to
get
in
the
gap
has
merged
we're
not
that
far
off
from
an
implementation,
poor
matching,
we
don't
have
consensus
on,
but
there
is
a
gap
and
it
is
potentially
smallish,
and
so
maybe
we
can
get
this
one
in
and
route.
Inclusion
is
one
that
I
am
I'm
not
not
as
certain
about
jeff.
I'm
not
sure
I
don't
see
jeff
on
this
call.
A
So
I
I'm
thinking
that
this
one
may
end
up
missing
the
line.
The
cut
line
for
o50,
but
I
you
know
I'm
just
trying
to
get
a
feeling
from
others
here
does.
Does
this
seem
like
an
appropriate
cut
line?
If
we,
you
know
like,
when
should
we
try
to,
you
know,
have
all
gaps
in
and
ready?
For
you
know,
implementations
in
and
ready
for
sig
network
review.
A
That's
a
that's
a
pretty
broad
question,
but
I
I
think
right
now
what
I,
what
I,
what
I'm
seeing
is
that
we'll
for
sure
get
these
top
two
in
and
we
might
get
port
matching
in.
But
I
think
we
need
to
aim
to
have
this
all
ready
for
review
or
api
finalized
early
january.
A
All
right,
well,
I
will
I'll
add
an
issue
or
discussion
to
to
follow
up
on
this
one,
but
I
at
my
current
perspective,
I
think
route
inclusion
may
be
at
risk
of
dropping
off
this
release.
A
Yeah,
okay,
well,
it
sounds
like
there's,
there's
not
too
much
of
an
opinion
on
that.
But
again,
if
you
do
have,
if
you
do
have
strong
opinions
on
what
we
should
or
shouldn't
include
in
our
next
release
or
if
you
really
want
to
push
for
something
like
getting
in,
definitely
let
let
me
or
anyone
else
know
final.
Finally,
I
wanted
to
do
just
a
quick
survey.
What
kubernetes
clients
are
we
using
for
implementations?
A
I
I
I've
been
working
on
conformance
tests
and
recently
moved
to
the
controller,
runtime
client
and
I
was
actually
blown
away
by
by
how
much
better
it
was
than
dynamic,
client
and
you
know
almost
better
than
generated
client,
but
I
I
was
just
curiou
in
that.
That's
just
my
my
own
personal
experience,
but
I'm
interested
in
of
of
other
implementations
out
there
have
we,
you
know,
is
anyone
using
the
client
we're
generating
or
it
you
know,
are
using
dynamic
client
anything
else.
I
We
use
controller
on
time
for
the
implementation.
We
used
the
generated
client
just
for
tests,
but
we
made
the
move
to
controller
runtime
earlier
this
year
as
a
whole
for
our
ingress
controller,
and
so
everything
gateway
has
been
implemented
on
that.
A
No,
no,
that's
it
so
I
I've
actually
been
the
the
link
I
have
is
work
in
progress
for
a
con
conformance
test
here,
but
anyway,
what
I'm
using
the
link
did
not
take
me
where
I
wanted
to
go,
but
where
I
I'm
using
a
controller,
runtime
client
for
conformance
tests.
So
that's
specifically
why
I
was
wondering
you
were
you
mentioned
using
generated
clients
specifically,
so
I
was
curious
if
I'd
missed
some
potential
benefits
there.
A
Yeah
yeah,
that
makes
sense,
okay,
and
it
seems
like
in
chat
a
couple
more
for
controller
run
time
and
yeah.
Okay
sounds
like
everyone's
moved
to
controller
runtime
awesome
all
right!
Well,
that's
easy
enough!
It
makes
me
wonder
I
it
does
sound
like
there's
at
least
one
use
case
still
for
our
generated
client,
but
it
does
make
me
wonder
if,
if
so
many
people
are
moving
to
controller
runtime,
if
we'll
need
to,
you
know,
continue
generating
our
client
forever.
I
I
could
foresee
it
being
useful
for
some
of
our
end
users
in
time
we
at
least
I'm
at
least
aware
of
like
one
group,
that
for
our
for
our
internal
crds
right
uses
our
go
client
our
generated
client
for
our
own
crds.
I
So
I
would
hate
to
think
that
we
would
stop
generating
the
client
for
gateway
upstream,
but
at
some
point
it's
just
going
to
become
part
of
the
whole
system.
Anyway,
right,
yeah
yeah,
that's
fair,
so
maybe
it
doesn't
matter
because
it'll
just
transition
and
happen
anyway.
At
some
point.
A
I
Yeah,
so
I
guess
this
isn't
like
huge
or
anything.
I
just
wanted
to
kind
of
run
this
by
some
people,
so
implementing
routes
of
some
time
has
been.
You
know
mostly
good,
and
I
had
this
conversation
with
nick
last
week,
where
he
kind
of
encouraged
me
to
bring
this
one
up
at
the
meeting
today.
But
let
me
gather
my
thoughts
just
a
bit,
so
the
long
and
short
of
it
is
having
three
different
objects.
I
All
with
references,
chained
references
to
each
other
is
a
little
bit
more
complicated
than
say
the
normal.
Like
one-to-one
object
reference.
It
will
have
like
one
object
that
references
another.
So
now
you
have
three
and
kind
of
the
trio
is
required
to
know
at
any
given
point
whether
or
not
in
the
case
of
routes,
a
data
plane,
configuration
should
exist
for
one
of
them.
So
like
http
route,
you
have
to
have
that
plus
the
gateway
plus
the
gateway
class,
and
there
has
to
be
kind
of
you
know.
Just
basically
is
it
supported.
I
Call
it
an
edge
case,
but
I
did
actually
run
into
it
while
testing,
so
it
was
kind
of
easy
to
run
into,
but
given
the
three
different
references,
there
was
kind
of
this
bug
where,
if
you
rapidly
deleted
a
gateway
and
a
gateway
class
at
the
same
time,
but
didn't
touch
the
http
route,
you
ended
up
with
this
situation,
where
the
logic
could
lose
track
of
whether
or
not
it
was
ever
supported,
because
in
controller
runtime
you'll
get.
I
We
have
like
watches
for
the
hdp
route
controller,
also
watch
gateway
and
gateway
class
right
if
one
of
them
updates
it's
fairly,
simple
to
say:
okay,
is
this
supported
so
on?
And
then
you
go
off
and
you
roll
a
reconciliation
for
that
object
so
that
it
can
be
updated
appropriately,
whether
that's
actually
starting
to
include
it
or
excluded
from
the
data
plane
configuration.
I
I
So
I
talked
with
nick
about
this
a
minute
but
a
bit
because
I
actually
was
looking
at
reference.
Implementations-
and
I
found
that
like
actually
there's
a
couple
of
places
where
other
people,
I
think,
have
the
same
problem,
and
I'm
just
wondering
if
people
have
dealt
with
this
in
any
specific
ways
we
don't
have.
I
I
don't
have
a
pr
up
for
this,
quite
yet
within
our
within
our
own
code
base,
because
I'm
still
kind
of
experimenting
with
it,
but
we
kind
of
have
this
approach
right
now
that
at
least
works
in
testing
of
which
is
really
heavy-handed
if
a
gateway
ever
updates
reconcile
basically
all
of
the
http
routes,
to
make
sure
that
you
don't
orphan
one
because
of
the
chance
that
you
won't
be
able
to
tell
whether
it
was
ever
supported
and
there's
limitations
like
the
http
route.
I
Statuses
like
the
parent,
ref
statuses,
can
only
do
so
much
because
you
can
still
kind
of
get
into
this
situation.
I
think
when
a
gateway
changes
in
particular,
where
you
wouldn't
really
know
things
can
get
out
of
sync.
So
so
far
it's
just
seemed
better
to
just
be
like
all
right
well
reconcile
the
world,
but
I
don't
really
want
to
make
a
pr
for
that,
because
it
seems
so
heavy-handed.
I
So
hopefully
I
didn't
talk
too
much
and
people
can
actually
understand
what
I
was
getting
at
here,
but
I'm
wondering
if
other
people
have
had
and
nick
kind
of
pushed
me
because
he
said
you
know
this
was
interesting
to
him
too.
He
said
you
know,
I
wonder
what
other
people
are
running
into
in
this.
In
this
regard,.
F
I
I
Then
the
controller
will
pick
that
up
and
put
that
in
the
data
plane
and
then
in
our
case,
and
so
that's
sitting
in
the
data
plane
and
traffic
is
routing
to
it
through
the
actual
gateway.
I
If
the
gateway
and
gateway
class
both
get
updated
rapidly,
so
that
they
wouldn't
be
linked
to
each
other
anymore
or
deleted
it
can
the
in
controller
run
time
you
don't
have
like
you,
you
don't
get
a
watch
of
an
object,
but
then
also
get
a
snapshot
of
like
another
object.
At
the
exact
same
time,
you
have
to
do
a
get.
Basically,
you
have
to
go
reference
that
object
by
object.
Reference
that
object
could
be
gone.
I
That
object
could
be
changed
in
the
case,
a
gateway
class
when
you're
trying
to
reference
it
to
http
routes
in
this
kind
of
three-way
reference.
It
was
the
bug
that
was
coming
up
was:
oh
okay.
It
can't
tell
that
this
was
a
supported,
http
route
and
it
doesn't
reconcile
it
now.
Obviously,
if
the
http
route
itself
ever
updated
again,
it
would
get
removed
from
the
data
plane,
but
it's
so
that's
why
I
kind
of
call
it
an
edge
case.
It's
very
technical
in
that
you
would
have
to
never
update
the
http
route.
F
F
We
did
kind
of
try
to
abstract
it
a
little
bit
to
make
it
so
that
when
you're
doing
the
query,
you
construct
a
query
object
rather
than
just
explicitly
going
and
just
like
listing
everything
with
the
goal
of
potentially
later
optimizing
that
but
right
now
it
just
passes
through
directly
and
just
grabs
everything
just
to
make
sure
we
don't
lose
anything.
I
I
I
A
I
Yeah,
that's
kind
of
the
point
of
this
is
like
there's
going
to
be
an
optimum
algorithm
for
this
or
a
heuristic
so
where
I
just
like
to
not
be
in
left
field,
while
there's
a
better
way
to
do
it
and
wondered
if
anybody
had
already
solved
it.
But
if
not,
I
think
I'm
going
to
continue
to
try
to
think
on
this.
I
So
and
then
I
guess
the
long,
the
the
down
the
road
there
maybe
make
a
dock,
and
we
can
all
talk
about
it
again
after
I've
had
some
more
time
to
kind
of
dig
in
because,
like
I
said,
I
just
started
kind
of
running
into
this,
so
I
haven't
had
a
ton
of
time
to
dig
into
it.
Yet.
A
You
know
this.
This
seems
like
just
the
perfect
use
case
of
github
discussions,
which
you
pioneered
yeah
so
yeah,
I
put
it:
okay,
cool
yeah,
I'm
interested
in
yeah.
I
know
not.
Every
implementer
is
on
this
call
right
now,
so
I'm
interested
in
what
others
think
as
well.
J
Cool
all
right.
Well,
I
think
that's
that's
all
for
this
one
unless
there,
unless
anyone
else
want
to
chime
in.
A
Cool
all
right
next,
one
I
want
to
go
to
is
charisma.
You
have
a
pr
for
validating
hp
route
filters.
J
I
think
that
is
awfully
close.
What
what's
the
current
state
on
it.
D
Yeah
I
pushed
up
a
commit
yesterday.
D
And
made
some
changes
that
that
change
that
you
do
suggested.
So
all
that
remains
is
that
I
remove
the
deep
equal
because
I'm
doing
rdd
equal,
but
the
problem
is
that
they
did
equal.
D
No,
I
mean
the
the
equality,
the
comparison,
the
yeah,
the
comparison
equal
equal
that
one
depending
on
it,
works
depending
on
the
fields
of
the
struct,
and
the
problem
is
that
some
fields
are
are
arrays
or
pointers
or
maybe
like
a
type,
a
concrete
type.
I'm
not
sure,
but
the
problem
is
that
it
didn't
work.
When
I
was
rolling
the
test,
that's
why
I
realized
that
some
had
to
use
the
people.
A
Yeah
I
yeah
I'd
also
assume
that
you
wouldn't
need
deep,
deep,
equal
here,
yeah,
I'm
I'm
interested
in
the
tests
that
failed
or
anything
like
that.
I
can.
I
can
try
and
help
out
figure
out
what's
going
on
there
yeah
weird
but
yeah.
Otherwise.
I
think
this
this.
You
know
I
agree
with
james
here
this
lg
this
looks
great
other
than
that
that
one
last
thing
at
least
based
on
the
last
time
I
looked
at
it
yeah
thanks
for
thanks
for
taking
this
one
on.
D
Yeah
yeah,
it's
been,
it's
been
big,
but
I've
learned
a
lot
so.
A
All
right,
the
last
one
and
this
one
I
don't
think
anyone
who's
been
involved
in
the
conversation
is
on
this
call.
So
I
may
leave
this
one
out,
but
I
wanted
to
come
back
with
to
this
pr
at
some
point,
I
that
there
was
a
pr
that
suggested
that
we
should
consider
term
termination
a
valid
combination
with
tls
route.
A
I
this
had
a,
I
think,
a
discussion
that
was
mostly
between
james
and
jeff
on
this
one
or
harry
as
well,
but
yeah.
It
looks
like
none
of
the
people
that
are
that
were
that
involved
in
this
discussion
are
on
this
call,
so
I'll
hold
off
till
the
next
meeting
to
dig
into
this
one
yeah
just
hold
up,
but
this
is
this
is
a
pr
that's
kind
of
sat
on
untouched
for
a
while.
A
I
just
like
to
reach
some
consensus
on
it
one
way
or
the
other,
and
that's
that's
all
that's
I
think
that's
the
only
recent
issues
prs,
etc.
I
think
we've
covered
everything.
Anyone
have
any
any
open
topics
they
want
to
raise
in
the
last
few
minutes
here.