►
From YouTube: Gateway API Meeting (APAC Friendly Time) 20210203
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
All
right
welcome
to
service
apis
meeting
for
february
3..
We
have
a
relatively
light
agenda
today,
so
I
think
we'll
have
plenty
of
time
to
get
through
everything
I
wanted
to
start
off
with
just
another
reminder.
Last
week
we
brought
up
the
idea.
I
think
bowie
had
filed
an
issue
early
last
week
and
we
discussed
it
at
the
last
meeting
about
potentially
renaming
the
project.
A
The
initial
suggestion
was
gateway
apis
since,
following
through
with
that
the
thread
it
transitioned
to
gateway
api
and
a
bit
more
conversation
on
there.
I
went
through
and
sent
it
out
to
signet
mailing
list.
There
hasn't
been
a
lot
of
feedback,
but
we
have
what
we
have
gotten
has
been
positive.
A
I
I
also
have
an
agenda
item
tomorrow
at
sig
network
community
meeting
to
bring
this
up
to
the
larger
group
there
I,
but
before
we
go
any
further,
I
wanted
to
give
an
opportunity
for
anyone
here
to
voice
opinion.
Does
this
seem
like
a
reasonable
change?
Is
the
name
change
just
painful
at
this
point?
Are
there
better
names?
Should
we
just
not
bother,
etc?
B
Hey
rob
it's
nick.
I'm
back!
Welcome!
Yeah
thanks
yeah!
I
really
like
it.
I
think
it
makes
more
sense.
It's
a
bit
less
confusing
for
people
cool.
A
That's
great
to
hear
yeah.
That
seems
to
be
the
the
constant
thread
we're
getting.
I
mean
what
what
we'd
seen
internally
as
we'd,
you
know,
had
some
users
testing.
This
is.
They
would
naturally
refer
to
this
as
the
gateway
api
just
because
they
were
using
the
gateway
resource
right.
So
I
I
think
this
will
be
a
a
good
change
in
something
like
that
is
easier
to
to
map
the
resources
to
the
name
and
also
a
unique
name
in
the
kubern,
relatively
unique
name
in
the
kubernetes
ecosystem.
A
It
seems
like
we
have
support
in
upstream
at
this
point,
so
this
I
I
created
pr
that
adds
this
cap.
Obviously
cap
is
half
of
the
battle.
The
other
half
is
actually
getting
an
implementation
in,
but
this
would
be.
This
would
add,
an
optional
namespace
param,
an
optional
namespace
field
to
the
parens,
ref
and
ingress
class,
and
it
seems
like
we
have
enough
buy-in
here
that
it's
likely
reasonable
to
also
work
towards
the
same
thing
for
service
apis.
C
That
is
correct
and
I've
got
a
pr
that's
on
hold,
so
I
can
go
ahead
and
update
that.
But
do
we
want
to
wait
for
this
cat
to
merge
before
yeah.
A
I
think
that's
reasonable.
The
the
kept
deadline
is
feb
9.
I
think
it's
tuesday,
if
I'm
remembering
correctly
so
this
has
already
had
at
least
an
lgtm
and
seems
reasonably
close.
A
There
are
some
interesting
comments
in
here
that
I
want
to
surface
in
a
little
bit,
but
I
think
I
think
this
is
reasonably
close,
so
I
would
say
once
this
merges,
we
should
try
and
fit
this
in
to
service
apis
as
well
or
maybe
gateway
api.
By
that
point,
let
me
actually
jump
ahead
here
and
add
this.
I
think
this
would
be
a
good
addition
to
try
and
get
in
as
part
of
a
0.2.
A
This
also
brought
in
so
I
made
the
mistake
of
doing
what
we're
doing
in
service
apis,
which
is,
unfortunately,
it
turns
out.
Not
what
the
api
conventions
say.
We
should
do.
A
I
so
in
my
mind,
namespace
as
an
empty
string
was
indistinguishable
from
being
empty
or
no,
and
so
I
said
well,
we
don't
need
a
pointer
that
that's
been
our
logic
in
service
apis,
but
I
was
correctly
correct
it
here
that
the
api
conventions
dock
does
make
it
very
clear
that
we
should
be
using
pointers
for
any
optional
field,
even
if
they
are
not
strictly
necessary.
D
C
Like
there
is
just
one
piece,
that's
missing
that
that
we're
doing-
and
that
is
the
defaulting
unless
I
missed
it
in
the
conversation
it
seems
like
okay,
we
unless
I'm
missing
something.
If
you
want
to
pull
up
the
code
to
me
when
a
parameter
is
optional
and
we're
not
defaulting,
we
are
using
a
pointer,
but
it's
when
we're
saying:
okay,
we're
not
specifying
the
parameter
is
optional,
so
it's
required
and
it's
we're
using
the
empty
json
tag.
C
A
I
came
from
how
we
handle
fields
that
have
defaulting
implemented
with
crds,
because
there's
not
really
a
similar
concept
like
you,
don't
have
a
default,
annotation
it
in
core
types,
but
that
does
that
does
seem
like
a
very
significant
difference.
A
So
maybe
maybe
an
action
item
out
of
this
is:
we
need
to
have
some
kind
of
even
internal
api
conventions
for
this
project,
which
are
basically
this,
but
in
addition
that
that
clear
that
clear
definition
that
when
we
have
a
default
value
specified,
we
should
not
be
using
a
pointer
type,
because
the
field
is
not
optional.
We
don't
consider
the
field
optional.
At
that
point,.
C
A
C
Say
when,
when
we're
using
coup
builder
defaulting
or
api
defaulting,
it
would
be
a
bug
if
there
is
the
plus
optional
tag.
So
it's
probably
worth
you
know
doing
a
quick.
You
know
audit
of
the
code
for
now,
let's
start
off
with
just
that
plus
optional
tag
and
just
verify
like
if
it's
optional,
we
shouldn't
have
a
default
and
we
should
have
the
json
omit
mt
yeah
and
it
should
be
a
and
it
should
be
a
pointer
right.
A
C
A
I
think
I
think
we
should,
I
think
we
have
grown
enough
as
a
project
that
it
would
be
good
somewhere
in
our
documentation.
We
have
like
developer
documentation.
That
says
we
follow
the
kubernetes
api
conventions,
plus
these
other
things
that
are
slightly
unclear
from
the
kubernetes
api
conventions,
which
right
now.
The
only
thing
I
can
think
of
is
the
specific
example
of
how
we
handle
fields
with
a
default
value.
C
Yeah,
let
me
let
me
work
on
a
pr
that
upstate
updates
the
documentation,
like
I
said,
I'll,
go
through
and
audit
all
the
optional
fields
and
make
sure
that
we're
not
defaulting
and
that
we
are,
including
that
it's
a
pointer
and
we've
got
the
empty
json
tag.
A
Cool
awesome,
thank
you,
the
other,
the
other
takeaway
that
I
thought
was
interesting
from
the
discussion
on
this
cap.
I
think
harry
brought
this
up
is
that
this
cap
actually
requires
a
change
to
the
type
right
that
we're
using.
Let
me
actually
look
at
the
files
change
because
that'll
be
easier
to
understand,
but
we
actually
have
to
change
from
typed
local
object
reference
to
an
entirely
new
object
reference
struct.
A
Apparently
I
messed
up
indentation
whoops,
but
this
this
is
what
we
had
to
switch
to,
and
this
is
a
breaking
go
api
change
it,
and
so
there
was
some
conversation
about.
Is
that
something
that
we're
okay
with
inside
kubernetes
and
the
yeah?
I
think
yeah
harry
you
brought
this
up
and
it
sounds
like
this
is,
although
not
ideal,
something
like
that
is
acceptable
and
something
like
we
have
seen
multiple
times
in
minor
kubernetes
releases.
A
The
the
reason
I
bring
this
up
is
because
we
had
in
in
our
service
apis
project
decided
not
to
make
breaking
it.
Go
api
changes
until
v1,
alpha
2..
A
E
E
I
think
it's
okay
to
like
follow
up
stream
right
and
break,
go
api
changes,
although
we
should
minimize
as
much
as
possible
right
but
yeah,
it
should
be
okay
to
do
it.
A
Yeah
yeah,
so
that
we
had
one
pr.
I
think
it
was
actually
from
you
that
that'll
bring
up
later.
That
was
a
breaking
go
api
change
and
we
just
put
a
hold
on
it
until
v1
alpha
two,
but
I
think
we
can
revive
that,
based
on
the
feedback
here,.
B
And
probably
renaming
things
is
a
breaking
change
as
well,
so.
A
Yeah,
but
I
think
renaming
things
is
a
breaking
yeah
renaming
things
as
a
breaking
api
change.
Regardlessly,
but
renaming
go
types
is
acceptable
or
maybe
that's
what
you
were
saying
like
we,
yes,
yeah
yeah,
yeah,
exactly
cool
and
so
okay-
and
I
I
just
added
this
note-
I
just
took
this
cap
on
because
I
wanted
to
see
it
get
in,
but
I
and
I
don't
have
to
own
this-
this
is
a
relatively
straightforward
kept.
It
is
adding
an
optional
field.
A
I
mean
it's,
there's
a
little
bit
more
to
it
than
that,
so
if
anyone
else
is
interested
in
contributing
to
kubernetes,
this
is
a
cap
that
I
am
I'm
not
tied
to.
So
if
anyone
wants
to
volunteer
for
this,
I'm
happy
to
hand
it
off.
So
just
let
me
know
if
you're
interested
in
it
yeah
I
will.
I
will
warn
anyone
that,
despite
this
being
a
single
field
edition,
it
will
be
a
four
release.
Cap
anytime,
you
add
a
field
the
way
it's
future
gated
everything
like
that.
It
does
it's.
A
A
At
the
last
meeting,
we
agreed
that
we
could
release
a
0.2.0
release
of
the
api
sometime
in
the
first
half
of
february
and
we're
in
february
hurrah.
That
means
we
basically
have
10-ish
days
to
hit
this
target
so
based
on
that,
I
wanted
to
revisit
some
of
the
things
that
we
could
potentially
target
for
this
release.
A
I
think
a
key
one
is
just
that
pr.
I
was
talking
about
earlier.
It's
a
relatively
small
change,
but
it
it
basically
inlined
the
route
forward
to
type
which
I
I
think
that's
a
you
know.
Instead
of
duplicating
this
everywhere,
an
inline
seems
to
make
sense
to
me.
B
Isn't
that
what
the
lava
lamp
was
saying
that
that
it's
better
to
cop
it's
better
to
actually
copy
them,
rather
than
inline
them.
B
D
B
I
think
the
trade-off
there
is
that
if
you
don't,
if
you
don't,
if
you
do
inline
them,
it
means
you
can't
change
them
anymore.
Right,
like
the
closer
we
get
the
stable,
the
more
upstream
stuff
that
you've
inlined.
You
can't
do
anything
with
it,
because
it's
because
then
it's
breaking
api
change,
and
so
using
the
upstream
one
using
the
upstream
one
lets
you
like
piggyback
off
any
stuff,
that's
added
to
the
upstream
one,
but
it
means
that
you
can't
add
anything
of
your
own.
You
can't
change
it
without
being
bringing
api
change.
A
Yeah,
that's
an
interesting
point.
I
I
think
this
is
yeah,
so
I
I
think
we
should
reach
some
kind
of
consensus
here.
A
What,
as
I
remember
this
and
harry,
feel
free
to
correct
me
on
this,
but
my
understanding
here
is:
we
have
a
generic
route
forward
to
type
that
we're
using
for
every
route
except
for
http
route
and
the
reason
we're
not
using
it
for
http
route
is
because
http
route
has
filters,
so
we
have
one
additional
field
in
this
type,
and
so
what
what
harry
did
with
this
pr
was
working
towards
with
this
pr
was
inlining
that
kind
of
shared
set
of
fields
that
every
forward
two
should
include
and
then
you'd
still
be
able
to
add
fields.
A
On
top
of
that,
because
it's
an
inline
type
right,
so
we
still
have
the
same
core
across
every
route
we
just
are
able
to
add
things.
Is
that
where
you
were
going
with
this
harry.
E
Yeah
that
sounds
about
right.
Tim
actually
raised
our
concern
here
that
if
we
are
embedding
types,
we
should
ensure
that
that
generic
type
makes
sense
in
all
cases.
D
E
A
Yeah,
I
think
in
this
case
it
makes
sense
to
either
not
share
forward
to
type
at
all
and
and
just
re-implement
this
for
every
single
route,
type
or,
alternatively,
do
what
we're
doing
here
and
share
the
base
set
of
fields
for
every
forward
two
in
each
route
and
then
build
on
that
with
additional
fields
as
we
see
fit
per
route.
A
I
I
don't
know
I
I
get
that
it's
a
slippery
slope.
B
I
think
it's
pretty
reasonable
as
long
as
there's
a
yeah.
Probably
we
probably
need
some
documentation
there
to
say
you
for
the
for
the
inlined
thing
to
say
this
structure
is
in
lines.
Don't
add
fields
to
it
like
unless
you've
checked
that
it's
that
it
is
that
those
fields
are
required
for
every
usage
of
the
inline
struct
yeah,
or
something
like
that.
A
Yeah
yeah,
because
I
mean
you
can
see
what
we're
removing
here.
It's
the
service,
the
back
end,
ref,
the
port
and
the
weight,
and
thus
far
this
has
been
kind
of
the
shared
baseline
of
forward
two.
It
is
interesting
to
try
and
think
of
a
forward
two
that
could
potentially
not
include
any
of
those
fields,
but
I'm
not
aware
of
any.
I
I
would
say
we.
We
should
be
very
careful
with
adding
anything
to
a
type
that
is
shared
across
resources.
B
A
Well,
you're,
you
added,
wouldn't
conformance
test
fail
it.
Oh
right,
yeah
people
made
changes
here.
I
don't
know
that
our
conformance
test
wouldn't
necessarily
test
our
types.
Our
api
types
would
they.
It
would
be
testing
behavior
of
controllers.
B
A
Yeah
that
makes
sense
okay.
Well,
just
at
the
very
least,
I
think
we
can
unhold
this.
That
doesn't
mean
we
should
do
it,
but
it
does
mean
we
should.
We
should
revisit
conversation
on
this
and
and
try
to
make
sure
that
what
we're
doing
here
either
makes
sense
or
doesn't
make
sense
and
close
it,
but
we're
no
longer
blocked
on
this
being
a
breaking
change
for
the
go
api,
all
right,
so
pull
476.
A
All
right,
the
other
thing
that
I
I
wanted
to
add.
I
think
damian
you're
looking
into
this,
but
just
to
make
sure
that
we
are
actually
using
pointers
consistently
for
optional
fields.
A
I
feel
like
we
may
have
missed
that
in
at
least
one
place,
but
I'm
not
sure
the
other
thing
that
I
think
would
be
a
nice
stretch
goal
though
this
is
a
a
significant
amount
of
work,
I'm
sure,
but
it
seems
like
it
would
be
nice
if
we
did
move
forward
with
this
rename
to
actually
try
and
get
the
rename
in
place
as
part
of
this
v0.2
release,
because
then
it
just
it
makes
it
much
easier
to
target
gateway
api
at
0.2.0
and
the
transition
becomes
relatively
straightforward.
A
And
similarly,
the
namespace
params
ref,
I
think,
is
something
that
will
happen
at
least
we'll
get
the
kept
merged
in
before
we
need
to
make
a
release
for
ingress
class
before
we
need
to
make
a
release
for
0.2.0.
So
I'd
like
to
get
that
in
as
well.
Is
there
anything
else
we
can?
Think
of
that
should
go
in
to
o.2
that
I
haven't
mentioned.
E
Here
I
mean
doc,
changes
don't
necessarily
need
to
need
to
be
like
included
in
there,
but
I
think
we
have
like
two
or
three
good
pr's,
that
if
we
can
bundle
it
with
it,
you
know
it
provides
sort
of
a
forcing
function
to
get
us
to
review,
and
you
know
finally,
merge
it
in
web
hook
is
another
one
where
we
like
it's
pretty
early
on,
but
if
we
could
actually
get
to
it.
That
would
be.
A
Yeah,
I
think
I
think
both
web
hook
and
and
conformance
tests
are
things
that
can
kind
of
continue
to
iterate
outside
of
the
normal
release
cycle
at
this
point,
but
it
would
be
nice,
it
would
be
nice
and
it
does
feel
awfully
close.
I
I
went
ahead
yesterday
and
actually
installed
the
web
hook
and
it
feels
relatively
close
there.
There
was
an
issue
related
to
a
a
logging
config
change
recently,
but
you
know
things
like
the
cert
were
automatically
provisioned
and
it
it
seemed
like
it
was.
A
It
was
awfully
close,
so
I
chris
was
wasn't
able
to
had
a
conflict
for
this
meeting,
but
I
know
he's
still
working
on
it
and
I
think
we'll
be
close
to
getting
that
in
yeah
great
points.
Okay,
anything
else
for.
A
V0.2
all
right.
Well,
I'm
going
to
move
on
then
to
this
awesome,
little
gist,
that
mate
put
together,
he's
he's
new
to
service
apis
gateway,
api,
whatever,
and
really
really
appreciate
this.
He
he,
I
wrote,
wrote
out
some
feedback
on
this
route,
binding
relationship
that
I
thought
would
be
really
helpful,
so
maybe
I'll
just
hand
it
off
to
mate
and
you
can
provide
you
know,
as
you
read
through
this,
what
you,
what
you
thought
of,
as
you
were,
trying
to
understand
this
api.
F
Right,
hello,
everyone
super
excited
to
speak
and
to
meet
y'all.
So
this
is
my
second
service
api
meeting
and
in
the
first
one
there
was
a
lengthy
conversation
on
the
gateway
and
route
relationship
documentation,
and
I
think
it
was
towards
the
end
that
rob
suggested
people
who
are
new
can
can
offer
some
feedback,
and
you
know,
since
I'm
new
and
eager
to
participate.
I
thought
I
could
give
it
a
try,
so
I'm
just
gonna
cut
straight
to
the
chase
here
I
do
want
to
say
before.
F
I
start,
though,
that
I'm
fairly
inexperienced.
So
I
just
graduated
from
university
and
I
don't
work
with
with
kubernetes
in
my
day-to-day,
so
I
thought
you
know
if
I
can
understand
the
documentation,
then
most
people
who
will
work
with
this
probably
will
get
it
so
yeah.
It
took
me
about
30
minutes
to
go
through
the
through
the
whole
documentation
and
to
just
kind
of
wrap
my
head
around
the
concepts.
F
Without
you
know,
hearing
about
gateway
classes
or
or
route
objects
before
the
thing
that
stood
out
to
me,
the
most
as
being
confusing
was
was
the
route
binding
section,
and
I
think
the
issue
that
I
I
kind
of
found
here
is
that
the
first
few
sentences
confused
me
a
little
bit
about
what
the
relationship
between
a
gateway
and
a
route
is
the
way
I
first
understood
it
is
that
a
gateway
object
would
would
define
routes
as
part
of
a
spec,
so
it
actually
took
me
took
me
a
while
to
to
kind
of
find
out
that
that's
not
the
case.
F
I
even
went
to
the
to
the
api
docs,
the
actual
code,
documentation
to
see
how
the
spec
is
defined.
This
made
it
a
bit
harder
for
me
to
just
kind
of
follow
through
with
the
provided
example
and
gateway
and
route
relationships
that
were
outlined.
So
it
was
all
just
just
a
bit
lost
on
me,
but
I
think
the
summary
did
a
great
job
at
explaining
everything
in
simpler
terms.
F
So
my
main
feedback
for
this
point
was
that
probably
the
route
binding
section
can
just
be
simplified
a
little
bit
just
by
rewriting,
what's
in
the
summary
to
be
the
introduction
and
and
to
set
the
scene-
and
I
think
to
this
point
one
of
the
comments
in
the
pr,
because
I
just
went
to
look
at
the
pr
after
reading
through
the
documentation.
F
One
of
the
comments
was
that
a
more
top
to
bottom
approach,
first,
explaining
how
a
gateway
selects
a
route
and
how
a
route
exposes
itself
and
then
finally,
what
binding
means
would
be
a
bit
more
beneficial
and
in
a
way
I
kind
of
agree
with
that,
because
after
reading
through
it
all,
I
think
binding
to
me
made
sense
just
at
the
end,
and
even
now,
I'm
still
a
bit
confused.
But
basically
what
what
it
means
to
me
is
that
a
route
exposes
itself
and
a
gateway
selects
it.
F
So
that's
kind
of
how
you
would
would
define
binding
as
a
relationship,
and
I
think,
that's
kind
of
what
I
came
up
with
when
it
comes
to
rod
binding.
If
rob,
can
you
please
scroll
down?
F
The
next
section
was
the
was
the
actual
route
selection,
and
I
think
this
is
where
the
where
the
debate
took
place
in
in
last
week's
meeting,
I
think
most
of
it
was
related
to
the
selector.
In
all
honesty
to
me,
the
section
was
pretty
straightforward.
Both
this
and
the
route
expose
up
section
to
me.
Both
of
them
were
pretty
straightforward.
I
could
understand
everything.
That's
that's
in
there.
F
I
think
if
I
did
have
to
be
to
be
nitpicky
the
selector
definition
that
we
had
on
there
kind
of
threw
me
off
a
little
bit
just
because
there
was
a
lot
of
name
space
name
space
definitions
involved
in
there
just
talking
about
name
spaces
a
bit
too
much,
but
I
think
the
the
one
thing
that
worked
for
me
with
the
example
is
that
the
label
selector
is
kind
of
a
kubernetes
concept
that
everyone
who
would
probably
work
with
this
type
of
stuff
would
would
know
so
to
me.
F
It
actually
made
it
easier
to
make
this
association
and
in
in
last
week's
meeting,
I
think
somebody
mentioned
that
the
way
we
have
that
exposed
label
in
the
example
might
throw
people
off,
but
I
think
to
me
it.
It
actually
worked
the
other
way
around
it.
It
helped
me
understand
a
bit
better,
exactly
what's
being
targeted
by
the
selector,
so
a
route
in
this
case
and
how
everything
comes
together,
so
yeah
really
great
work
on
on
the
examples.
F
I
don't
know
how
the
documentation
looks
before
before
this
was
added
in,
but
I
think
the
addition
of
examples
definitely
helped
and
then
I
think
that's
kind
of
the
that's
kind
of
the
gist
of
it.
I'm
definitely
forgetting
a
few
things,
but
all
in
all,
I
think
additional
examples
are
not
going
to
hurt,
but
I
know,
probably
you
know,
being
a
bit
more
conservative
in
documentation
and
trying
to
emphasize
stuff
more.
F
You
know,
having
extra
examples,
might
just
take
a
bit
from
that
and
and
provide
a
bit
of
clutter,
but
all
in
all,
I
think
the
main
point,
the
main
struggle
that
I
had
personally
was
just
kind
of
defining
this,
this
binding
relationship-
and
I
think,
if
we
do
a
better
job
at
first
of
of
setting
the
expectations
of
what
binding
means,
it's
going
to
help
down
the
line,
to
really
synthesize
for
the
examples
and
get
everything.
D
As
I
say,
thank
you
for
the
feedback.
This
is
yeah.
This
is
really
good.
It's
really
good
to
have
a
new
user
go
through
it,
so
we
can
understand
kind
of
what
what
things
we've
assumed
here,
a
couple
things.
So
I
was
kind
of
just
gonna
pull
the
group.
I've
noticed
a
couple
different
patterns
about
how
users
want
to
think
about
their
like
the
relationship
between
routes
and
and
gateways.
D
There
is
one
customer
I
talked
to
that.
Basically,
they
wanted
to
it's
kind
of
about
who
should
own
the
mappings
of
gateway
to
route
and
there's
one
infrastructure
team
that
basically
they'll
have
a
couple
different
gateways
and
they
wanted
to
the
infrastructure
team
wanted
to
own
the
mapping,
so
they
decide
which
routes
which
bind
to
which
gateway.
D
D
Maybe
that
might
be
a
useful
example
to
start
with
to
kind
of
talk,
discuss
like
what
are
the
relationships
between
the
infrastructure
team
and
the
app
team
and
where
the
boundary
is
on,
how
much
the
app
team
controls
or
doesn't
control
that
might
put
this
in
context
better.
But
I
wanted
to
see
if
everyone
else
kind
of
sees
it
that
way
as
well.
B
I
was
gonna
say:
we've
definitely
had
requests
for
that
sort
of
thing
on
contour.
So
I
think
it's
that
you
know
so.
For
some
teams,
the
the
infrastructure
team
absolutely
wants
to
be
the
only
ones
who
get
to
say
which
things
map
which
things
bind
to
the
gateway
and
for
some
teams
they
want
it
to
be
magic
so
that
the
people
people
who
are
creating
rounds
can
just
bind
anything
they
like,
and
we,
I
think,
we've
done
a
good
job
in
designing
the
api
that
you
can
do
that.
F
You
no,
I
just
wanted
to
say
that
what
you
said
mark,
I
think
this
would
help
me
visualize
it
a
bit
better.
Just
you
know,
thinking
of
the
experience
I
had
today,
I
think
that
would
be.
That
would
be
a
good.
D
Idea,
okay,
cool!
I
will
yeah
I'll
come
up
with
just
a
little
bit
the
discussion
about
kind
of
you
know,
relationships
about
teams,
an
organizational
structure,
and
we
can
slide
that
in
and
say
I'll
I'll
send
over
pr
and
definitely
ccu
on
there
for
feedback.
Once
I
get
that
ready,
probably
the
next
couple
weeks.
A
Cool
this
is
awesome
yeah.
Thank
you
so
much
mate.
This
is
exactly
what
we
need.
I
I
know
that
I
I
felt
we
were
struggling
with
getting
route
binding,
correct
and
then,
even
if
we
had
it
correct
explaining
it
well
enough
and
mark
helped
a
lot,
but
just
getting
some
some
fresh
eyes
on
this
and
and
getting
this
great
written
feedback
on
what
what
might
still
be
confusing,
has
been
very
helpful.
So
yeah
thanks
a
bunch
and
and
welcome,
welcome
as
well.
Thank
you.
F
And
for
my
pleasure,
cool.
A
All
right,
let's
move
on
to
just
a
couple
last
last
things,
one
one
thing
came
in
slack
this
morning
asking
if
we
wanted
to
provide
a
standard
set
of
metrics
as
part
of
this
api
spec,
and
in
this
case
it
was,
I
think,
jonathan
who
who
mentioned
it.
I'm
not
sure.
If
he's
on
this
call,
I
don't
see
him,
but
he
had
specifically
asked
if
we
wanted
to
have
you
know
metrics
for
for
things
like
I
don't
know
a
number
of
successful
requests,
that's
he.
A
He
specifically
referred
to
smi
metrics
and
the
spec
that
is
included
there,
for
I
think
they
have
five
standard
metrics
that
they
include
as
part
of
the
spec.
I
know
we've
had
some
offhand
discussion
about
potentially
including
metrics.
Here
it
feels
a
little
bit.
I
don't
want
to
say
out
of
scope,
but
not
not
our
primary
focus
to
me,
but
that
doesn't
mean
it
shouldn't.
You
know
it
doesn't
mean
it
needs
to
be
out
of
scope.
A
A
A
To
go
to
go
a
bit
further
hurry,
I'm
not
sure
if
you
were
about
to
say
anything
but
to
go
a
bit
further
this
or
go
ahead.
Sorry
harry
no.
A
Okay,
yeah
this.
This
was
specific
to
auto
scaling
right
and,
if
you,
if,
if
as
an
example,
implementations
of
this
api
provided
sufficient
metrics,
you
know
and
in
a
standardized
enough
way,
you
could
provide
much
more
meaningful,
auto
scaling
based
on
those
kind
of
consistent
metrics.
A
So
so
that
is
a
compelling
reason
to
think
about
something
like
this,
but
I
you
know
we
obviously
have
a
lot
to
focus
on
on.
You
know
as
part
of
this
api
design.
I
don't
want
to
lose
focus
unless
this
is.
You
know
a
really
compelling
area
to
to
work
on
in
the
next
few
months.
B
Feels
to
me
like
it
might
be
useful
at
some
point,
but
it's
pro
it's
way.
It's
down
the
list
past
a
lot
of
other
stuff,
yeah
yeah.
A
B
I
guess
the
other
thing
I
would
say
is
that
it
feels
to
me
like
if
we
did
implement
this,
it
would
like
it
would
be
one
of
the
outer
layers
of
conformance
like
yeah.
You
know,
anyway,
you
know
like
you're,
not
going
to
have
this
in
the
core
yeah.
I
agree
and
it
feels
to
me
like
we
should
focus
sorry.
B
We
should
fill
out
the
call
yeah
the
call
before
we
start
worrying
too
much
about
putting
optional
stuff
in.
Is
there
anything
else.
E
Yeah
what
we
could
do
is
we
do
want
implementers
to
sort
of
play
around
in
that
because
custom
conformance
area,
so
we
should
definitely
encourage
implementers
to
try
building
something
in
at
least
one
implementation
and
then
just
so
that
other
implementers
can
keep
an
eye
on
that
and
see.
Okay,
if
that's
of
value,
you
know
they
can
sort
of
mirror
that
or
then
you
know
that's
how
we
can
get
more
and
more
things
into
the
extended
and
core.
A
Right
you're
saying
that
that
this
api
leaves
plenty
of
room
for
kind
of
implementation,
specific
experimentation
that
can
eventually
lead
to
additions
to
core.
A
Yeah
that
makes
sense
good
point
all
right.
Let
me
let
me
move
on
to
pr
and
issue
triage.
I
we
don't
have
a
whole
lot.
Oh
that's
cool
that
has
come
in
in
the
past
a
little
bit
other
than
the
pointers
that
I
already
addressed:
the
change
to
a
repo
name
and
yeah.
What
do
you
know
schedule
of
the
next
intermediate
release?
A
I
can
say
I
personally
have
been
pretty
distracted
with.
You
know,
kept
freeze
in
upstream
and
hope
to
get
more
more
involved
in
this
and
make
some
more
concrete
contributions
in
the
next
couple
weeks.
But
with
that
said
there
there
are
a
couple
things
that
have
potentially
gotten
stuck
this
pr.
A
I
don't
think
anyone
is
on
the
call
for
this
one
we've
discussed
it
previously
and
I
think
our
our
last,
our
our
last
consensus
here
is
that
we
just
are
hoping
for
something
that
could
be
as
portable
as
possible
and
not
tied
to
any
one
implementation
and
I'm.
I
don't
think
there
have
been
many
updates
since
that.
A
Then,
for
the
other
one,
the
route
status
godox,
I
think
this
one
is
damian
remind
me,
oh
yeah,
you
just
commented
on
this.
What
what's
the
current
status
of
this?
I
I
lost
track
of
it.
C
Yeah
I
had
a
chance
to
go
through
the
comments,
and
what
I
settled
on
is
that,
instead
of
defaulting
a
gateway
status,
condition
for
the
different
supported
route
types,
we
just
update
the
documentation
godox
to
state.
You
know
an
empty
gateway
list
for
route
status
indicates
the
route
has
yet
to
be
admitted.
So
that's
that's
the
update
that
I
did
to
this
pr
and
that's
where
we're
at.
A
Do
you
do
you
think
as
a
follow-up,
it
makes
sense
to
require
at
least
one
condition
to
be
set
in
this
kind
of
route
gateway
status,
struct.
What
sorry
yeah
I've
got
to
look
at
the
diff
again,
but
inside
route
gateway
status
there
is
a
gateway,
ref
and
a
list
of
conditions,
a
slice
of
conditions.
A
B
A
Right
it
like
to
me,
it
doesn't
make
sense
to
ever
have
an
entry
in
this
list
with
just
a
gateway
ref
and
no
conditions
that
that
feels
entirely
wrong,
so
adding
a
validation,
a
min
length
validation
feels
like
it
would
go
along
with
this.
Well
because
I
know
your
initial
goal
here
here
was
to
provide
a
meaningful
default,
so
we
didn't
end
up
with
a
lack
of
status
here.
A
B
I
would
say
if
we
do
that,
though
it
should
above
where
you.
If
then
it
does
add
that
then
then
it
needs
to
have
the
thing
there
saying
you
know
the
minimum
condition
is
the
admitted
condition
like
a
condition
of
type
admitted,
yeah
yeah.
That
makes
sense
to
me
so
yeah.
A
C
Okay,
I
could,
I
could
just
go
ahead
and
update
this
to
add
those
changes
as
well.
I
think
that
makes
sense.
A
Awesome
thanks
yeah,
just
just
ping
me
whenever
you've
done
that,
because
I
know
I
I've
been
a
bit
slow
to
review
this
pr.
So
I'll
follow
up
pretty
quick.
A
Cool
you
have
conformance
tests.
I
I
do
intend
to
revisit
this.
I've
had
some
offline
discussions.
I
discussed
this
more
with
alejandro
and
folks
from
ingress
controller
conformance
repository
as
well,
because,
obviously,
my
initial
take
on
conformance
tests.
Although
similar
and
although
sharing
some
code,
I
inherently
did
not
use
godog,
so
it
used
a
slightly
different
framework.
It's
just
to
use
vanilla
go
tests,
it
is.
A
A
Yeah
we'll
see,
but
I
want
to
at
least
provide
examples
of
what
this
looks
like
again.
Just
vanilla
go
test
and
then
separately
with
with
a
framework
like
go
dog
like
what
we're
using
for
ingress
controller,
conformance
and
see.
If
there's
some
middle
ground,
we
can
we
can
reach
here.
These
approaches
are
fairly
similar,
so
I
don't
think
it's
going
to
take
a
lot
of
effort,
there's
just
some
cogen
and
additional
work
with
godog
that
I'll
need
to
work
through,
but
not
much
in
the
way
of
updates.
A
Beyond
that.
I
think
there's
plenty
of
work
that
I
could
do
to
clean
up
this,
and
I
appreciate
the
comments
and
initial
feedback
on
that,
but
just
as
an
update
here,
I'm
I'm
actually
also
in
parallel
to
this
exploring
another
approach
that
would
use
godog.
I
I'm
still
not
completely
sold
on
it,
but
I
want
to
at
least
show
what
that
would
look
like
yeah
and
if
anyone
has
any
strong
feelings
on
how
to
structure
conformance
tests,
I'm
certainly
all
ears.
A
But
cool
and
then
the
next
one's
editorial
pass
over
api
docs.
I
this
one
has
gotten
stuck,
I'm
not
sure.
I
know
we've
had
a
lot
of
conversation
on
this.
One
james
ended
up
pulling
out
and
simplifying
a
great
deal
of
this
pr,
but
I
think
there's
still
a
little
bit
left.
A
I
think
this.
This
pr
has
gotten
a
little
stale.
A
Unfortunately,
the
the
the
fundamental
conflict
in
this
pr
is
just
whether
we
want
to
prioritize
sane,
looking
godok
or
reasonable,
looking
markdown
right,
and
so
one
of
the
one
of
the
very
frustrating
problems
with
the
current
documentation
generator
is
that
if
you
specify
something
like
as
simple
as
an
asterisk,
it's
going
to
it's
not
going
to
escape
that
for
markdown,
and
so
you
end
up
in
this
fun
place
where
you
get
bold
content
in
random
places,
which
is
it
and
it
just
doesn't
make
sense
right,
and
so
this
pr
as
it
exists
right
now,
replaces
asterisks
in
godok.
B
Does
does
that
mean
that,
if
we're
going
to
prioritize
the
godox,
which
I'm
100
fine
with
then
doesn't
that
mean
that
what
we
we
probably
should
just
stop
supplying
the
the
types
themselves
on
the
thing
and
just
have
a
pointer
to
the
godox.
B
I've
appointed
a
package.go.dev
yeah,
which
is
going
to
pass
that
stuff
properly
anyway,
and
then
you,
rather
rather
than
having
that
embedded
in
our
website,
like
just.
A
Yeah,
no,
I
mean
that's
a
good
point.
It's
it's
frustrating,
because
there
are
some
really
nice
things
about
the
generated
reference
docs
I
mean
it
it.
It
does
structure
things
very
nicely
and
it
does
embed
in
our
in
our
code
quite
well
in
our
in
our
website.
Quite
well,
it's
just
these.
These
kind
of
relative
edge
cases
where,
where
it
starts
to
get
get
frustrating
to
to
deal
with.
B
Yeah,
I
I've
been
using
them
a
lot
as
a
reference
rather
than
using
the
the
go
packages
themselves
or
the
go
down.
B
As
well,
it's
because
it's
easy
to
read
and
it's
easy
to
jump
around,
but
but
yeah
it
is
yeah
yeah,
because
it's
less
it's
just
the
just
the
details
of
what
points
to
what
it's
much
more
useful
for,
if
you're
not
used
doing,
go
implementation
and
you're
doing
a
yaml.
Maybe
just
how
do
I
write
the
yaml.
A
A
I
wish
we
could
find
a
way
to
update
the
generator
to
escape
special
characters,
but
I
recognize
that
is
a
significant
amount
of
work
or
I'm
assuming
it
is
I'm
not
that
familiar
with
the
generator
we're
using,
because
you
know
whenever,
given
a
choice,
I'd
always
prefer
to
just
have
both
but
right
now,
if
it's
a
decision
between
breaking
godox
or
breaking
our
reference
docs,
I
I
would
rather
not
choose
either
I'd
rather
fix
the
generator,
but
I
I
know
that's
not
not.
A
E
B
That
makes
sense
to
me,
I
mean
we
are
still
alpha.
We
do
have
time
but
yeah.
I
would
say
that
we
should
consider
it
a
reason
reasonably
close
to
a
hard
requirement
to
have.
B
You
know
to
have
the
either
the
generator
fixed
or
to
not
have
the
things
on
there,
because
it
is
confusing
at
the
moment.
In
some
ways,
these
edge
cases
are
weird
and
make
it
less
readable.
A
I
guess
I
guess
what
we
need
as
a
follow-up
out
of
this
is
some
kind
of
investigation
in
how
difficult
it
would
be
to
escape
these
characters
in
the
code,
gen
well
doc,
reference
doc
generation
and
related
to
that.
If
we
can't,
if
we
deem
that
too
difficult,
then
you're,
probably
right,
we
should
just
link
to
godox
directly
until
we
can
fix
the
degenerated
docks,
because
because,
as
as
useful
as
they
are,
it
is
unfortunate
that
some
of
these
edge
cases
render
so
poorly.
A
A
Okay,
yeah
I'll
I'll,
go
ahead
and
add
a
follow-up
comment
on
this
one.
Just
to
try
and
summarize
what
we
said
here.
A
Yeah,
okay,
I
think
that's
just
about
all
the
web
hook.
I've
already
covered.
That's
awfully
close.
I
added
a
few
more
comments
for
chris
test
this
out
and
it
feels
really
close.
We've
gone
through
deduplicating
types
and
I
think
we've
gone
through
the
recruit
request,
retry
attributes
recently
enough.
A
A
As
I
imagine,
a
lot
of
us
are
working
on
implementations
for
this
api,
but
we
also
in
the
not
too
distant
future,
need
to
start
thinking
about
additions
to
the
api
again
things
that
are
currently
notable
additions,
such
as
request
reach,
retry
and
timeout
that
this
pr
initially
targeted
back
in
the
day.
A
So
I
you
know,
I
don't
know
that
we
need
to
focus
on
them
quite
yet.
I
think
there's
plenty
to
do
on
conformance
and
web
hooks,
but
if
you're
thinking
about
gaps
in
the
api
that
really
should
be
filled
soon,
I
think
we
should
start
to
transition
back
to
that
additive
phase
soon
yeah,
I
I
think
that's
all
I
have
are
there
any
any
opens.
It
looks
like
we
blew
through
the
time
anything
I
missed
to
cover.
B
I
just
had
something
I
wanted
to
ask
yeah:
that's
I've
got
the
contoured
service.
Api's
implementation
design
is
almost
done
once
we've
got
our
design
dock.
For
that
up.
Do
you
want
me
to
just
drop
into
the
channel?
Should
I
come
and
talk
about
it
here?
What
would
you
allow
me
to
do?
B
B
Yeah
that
we
do
have
a
tracking
issue,
so
I
can
link
to
that
as
well,
but
yeah
but
I'll
I'll.
Send
you
all
the
design
doc
once
I've
got
it
once
I've
got
our
design
accepted
in
what
we're
going
to
do
yeah
and
then
I
will
come
along
for
another
next
meeting
of
this
and
yeah.
B
Yeah
I'll
yeah
I'll
post
it
in
the
channel
as
soon
as
it's
done
great
thanks.
A
All
right,
well,
I
think
that's
all
for
today
have
a
great
rest
of
your
wednesday
and
we'll
talk
to
you
on
github
slack
wherever
and
next
week
as
well
have
a
great
one.