►
From YouTube: Gateway API Meeting (EMEA Friendly Time) for 20200920
Description
Service APIs Meeting (EMEA Friendly Time) for 20200920
A
I
know
this
still
looks
pretty
similar
to
where
we
were
before,
but
man,
all
all
the
prs
that
we
have
remaining
at
this
point
feel
awfully
close,
and
I
I
believe
harry
has
has
updated
his
pr
in
response
to
feedback.
I've
updated
a
couple
of
mine.
I
think
we're
we're
super
close
on
what
the
the
few
that
are
left
here.
So
then
we
really
are
starting
to
get
into
documentation
and
and
all
this
other
stuff
and
and
well,
I
am
here.
A
A
Yesterday,
in
office
hours,
we
went
through
and
tried
to
identify
areas
that
were
really
lacking
in
our
docs
and
so
I've
added
you
know
some
of
these
are
easier
than
others.
I
think,
as
an
example,
facts
is
going
to
be
pretty
straightforward
feedback.
Maybe
even
more
straightforward
cookbooks
could
be
split
out,
I'm
not
sure,
but
you'll
notice,
that
all
of
these
are
part
of
the
v1
alpha
one
milestone.
A
It
looks.
You
know
the
the
sad
thing
about
using
this
milestone
is.
It
looks
like
we're
only
62
complete,
but
that's
of
course,
because
we
only
started
using
this
relatively
recently,
but
we
have.
We
have
already
knocked
out
a
bunch
of
things
that
were
on
this
list,
but
if
you're
looking
for
things
to
do,
this
is
a
good
starting
point
or,
if
you're,
just
wanting
to
track
progress.
A
This
is
also
an
alternative,
yeah
and
and
if
something
feels
like
it
should
be
in
this
milestone,
yeah,
I
think
harry
james
bowie,
myself
can
all
add,
remove
stuff
here
whenever
so
anyways
yeah,
that
that
is
the
milestone.
It
does
not
mean
much
of
anything,
it's
mostly
just
for
our
purposes
of
tracking
our
progress
here,
yeah.
Okay,
so
that's
our
progress
on
v1
alpha
1..
We've
got
a
couple
updates
on
pr's
that
I
want
to
get
through
in
issue
triage
and
some
questions.
A
B
I
was
just
going
to
ping
you
on
slack
and
see
you
know,
try
to
get
an
understanding
of
who
is
responsible
like
at
red
hat
and
kong
for
the
actual
productization
of
gateway,
and
you
know
how
how
the
companies
are
announcing
it
and
what
collateral
we're
building
for
tutorials
and
stuff,
like
that.
One
of
the
pieces
here
is
similar
to
kind
of
how
ingress
had
a
bunch
of
examples
on
on
the
kubernetes
website.
I
think
it
does
make
a
lot
of
sense
to
have
a
generic
gateway
example
to
show
what
the
spec
looks
like.
B
But
since
there's
no
reference
to
implementation,
it's
not
actually
possible
to
do
it,
and
then
we
would
have
you
know,
pointers
or
sections
for
all
the
implementations
that
exist
in
which
you
can
use
it
for
that
implementation,
and
so
that
was
kind
of
the
idea
of
how
we
would
handle
it
on
the
website
and
where
users
would
go
to
actually
try
this
out.
But
obviously
I
want
to
you
know,
reach
out
to
other
companies
involved
and
see
what
their
actual
implementation
plans
are.
So
we
can
figure
out
what
what
the
best
way
to
do.
B
A
A
That's
great
awesome.
Well,
one
of
the
the
next
thing
I
had
on
the
agenda
here
was
just
so
some
of
you
may
have
noticed.
I
threw
out
a
pr
last
night
after
our
office
hours.
That
was
really
just
a
whole
bunch
of
api
cleanup
and
actually
let
me
let
me
start
there.
I
don't
want
to
review
this
pr
quite
yet,
but
just
to
give
you
an
idea
of
the
scope
of
this
pr.
A
It's
just
a
bunch
like
it's
probably
too
many
things,
but
everything
just
kind
of
felt
looped
together
and
if
I
change
one
all
of
these
in
individual
pr's,
they'd
always
be
conflicting
with
each
other,
so
adding
min
and
max
length
everywhere,
removing
that
required
tag
because
we
were
inconsistently
using
it
in
some
places,
and
I
haven't
seen
it
many
others,
so
it's
inferred
it
doesn't
have
any
real
meaning.
So
I
just
removed
it
updating
the
default
fields
to
no
longer
be
optional.
Thank
you.
A
I
think
it
was
damian
who
showed
how
to
do
that
properly.
Thank
you.
It's
much
better
it.
I
realized,
as
I
was
so
the
examples
were
broken,
which
seems
to
happen
all
the
time.
We
really
do
need
some
kind
of
test
for
that
with
that
said,
as
I
was
updating
the
examples,
I
realized
that
we
updated
the
forward
two
for
http
route,
but
none
of
the
other
routes
so
where
we
once
had
consistency,
we
didn't
so
I
fixed
them
to
be
consistent
again.
A
So
relatively
tiny,
well,
lots
of
changes,
none
of
them
on
their
own
are
massive,
but
combined
they're
a
lot
of
api
cleanup.
So
with
that
said,
this
whole
experience
got
me
thinking
about
a
few.
Well,
a
couple
things
in
our
api
and
what
really
got
me
thinking
was
looking
at
the
examples
of
forward
two.
It
felt
it
felt
less
than
ideal
right
and
I'm
I
know
like
I
I
approved
this.
A
I
it
made
sense
at
the
time
we
we
switched
action
to
forward
two
to
forward
and
forward
to
you
to
forward
sorry
forward
two
to
two,
and
this
was
the
end
result,
but
it
feels
like
we
have
a
lot
of
kind
of
extra
weight
here
that,
especially
for
the
default
case,
feels
less
than
ideal.
I
I
don't
know
so
I
was
wondering
if
there
was
so,
I
was
wondering
if
there
was
any
appetite
for
flattening
this
structure
a
bit.
I
think
one
of
the
easiest
potential
ways
to
flatten
this
is
first
off.
A
D
A
D
A
So
based
on
that,
I
wanted
to
go
to
what
I
had
proposed
in
back
end
policy
without
realizing
that
it
actually
was
different
than
what's
in
forward
to
so.
In
back
end
policy,
we
have
a
back
end
ref
and
that
back
and
rep
is
group
resource,
name
port,
whereas
in
all
our
forward
two
targets,
we
have
a
target
ref
which
has
group
resource
name
and
then
at
the
same
level
as
target
ref,
not
inside.
We
have
poor
and
weight
and
to
me
that
feels
like
yeah.
B
A
Right
yeah,
I
mean
the
argument
is:
if
we
end
up
having
you
know,
a
thousand
different
fields
as
part
of
a
ref
in
the
future,
then
maybe
that's
less
than
ideal,
but
for
right
now
the
x,
like
we
have
so
many
levels
here
it
just
it.
You
know
for
this.
It
makes
our
simple
use
case
even
like
the
forward.
Two
split
feels
weird
and
then
forward
two
target
ref,
all
the
way
down
just
do
we
need
all
that
yeah.
C
A
Yeah,
so
that
that's
my
next
thing,
so
we
split
forward
to
it
so,
okay,
there
was
an
action
here
and
the
action
included
forward
two
and
extension
ref
and
what
we
ended
up
doing
is
renaming
action
to
forward
renaming
forward
two
to
two
and
leaving
the
extension
ref
in
there.
So
what
that
means
is
we
have
forward
two
and
we
have
forward
extension
ref,
it's
all
it's,
so
we
wouldn't
need
that
extra
level.
A
If
we
could
move
the
extension
ref
to
say
I
don't
know
where
somewhere
else
or
yeah
that,
like
that,
that
was
going
to
be
my
mind.
I
don't
know
if
this
is
exactly
where
you
were
going,
but
my
next
question
was
going
to
be:
can
we
somehow
merge
those
because
target
ref
feels
awfully
similar
to
extension?
Ref,
like
it's
just
a
resource,
a
pointer
to
an
arbitrary
resource
somewhere.
A
F
And
that
is
where
my
thinking
was
going
as
well,
so
I
mean
having
target
ref
the
reason
of
having
target
ref
is
because
we
want
to
support
multiple
types
in
there,
so
that
itself
is
an
extension
point.
That
should
be
good
enough
and
if
somebody
just
wants
a
single
one,
they're
most
welcome
to
use
just
a
single
target.
Riff.
B
A
A
A
Cool
I,
if,
if
there's
no
pushback
to
this
I'll
I'll,
create
a
pr-
and
I
mean
it's
fine,
if
once
you
see
the
pr
you
don't
like
it,
that's
fine!
We
we
can
deal
with
that,
but
as
as
long
as
it
seems
reasonable
at
this
point
I'll
at
least
start
in
that
direction,
because
I
think
there's
some
room
to
simplify
this.
F
One
concern
that
I
have
is
like
the
thing
we
discussed
initially,
where
you
know
target
ref
is
a
pointer
and
like
what
is
the
upstream
guidance
on
there.
There
is
some
confusion
there,
so
as
long
as
we
can
sort
that
out
to
make
sure
that
we
have
a
unified
api,
where
people
are
not
getting
surprised
that
so.
C
C
Is
there
a
possibility
to
collapse
that
as
well?
I
know
hosts-
or
I
know
this
kind
of
started
off
with
a
lot
of
the
look
and
feel
of
ingress.
But
am
I
missing
something
is:
is
there
an
opportunity
there
that
we
can
just
go
ahead
and
say:
okay
now
that
host
name
is
pluralized
or
we
don't
even
need
host
names
anymore
and
hosts
is
plural
and
or
what
am
I
missing
there
that
maybe
I
just
don't
see
on
how
we
could
collapse
hosts
and
and
our
host
names
into
hosts.
A
That
is
a
fantastic
question.
I
I
have
to
pull
up
the
the
types
do.
Does
anyone
remember
offhand
if
we
have
anything
else
left
in
spec,
besides
hostname,
so
we
have,
we
have
hdb
route
host,
and
this
is
it's
literally
just
okay.
So
the
idea
is
that
you
can't
you
can't
have
a
list
of
spec,
so
it
just
like
spec
can't
be
a
list,
so
you
need
some
attribute
here
to
okay
yeah
I
mean
this
is
confusing.
C
A
Would
it
would
it
be
terrible
to
and
again
this
is
a
change
from
ingress,
but
to
just
flatten
this
out
one
level
as
well
and
say
that
each
route
is
basically
a
single
http
route
host
and
that
can
include
multiple
host
names
and
rules
for
those
host
names.
And
if
you
want
to
specify
a
different
set
of
host
names,
you
just
use
a
different
route.
C
A
F
A
A
A
F
A
A
F
A
A
So
right
now
we
have
hosts
which
is
http
route
host,
and
this
has
everything
that
we
care
about.
I'm
just
saying
we
turn
this:
oh
yeah,
yeah
yeah.
He
writes
back,
that's
it
this.
This
becomes
spec
and
we
get
rid
of
this
all
the
time
entirely,
like
this
extra
level
of
listing
feels
unnecessary
to
me,.
D
C
F
C
A
A
C
F
C
A
Yes,
all
right
sounds
good.
Well,
thanks
for
the
feedback
here,
I
think
this
one.
This
will
be
a
good
improvement.
Yeah
appreciate
it.
Okay,
the
the
next
one-
and
I
I
I
maybe
I'll
just
do
it
as
a
fun
slack
poll
or
something
for
this
one,
but
I'm
I'm
curious.
One
of
the
bits
of
feedback
I
got
from
tim
is
that
defaults
were
confusing
to
him
in
object.
References
like
well
we'll
go
right
back
to
this
animal.
He
to
him.
It
wasn't
clear
what
name
referred
to
you
know.
A
In
this
example.
Okay,
sure
we've
got
service
in
the
name,
so,
okay,
that
kind
of
makes
sense,
but
it's
it's
not
intuitive
to
a
user.
Exactly
what
this
is
I
so.
I
already
made
the
change
because
I
think
it's
very
obvious
for
extension,
ref
that
no
one
knows
extension,
ref
is
config
map
and
config
map
probably
isn't
going
to
be
the
most
commonly
used
extension
point.
I
don't
think,
but
this
is
at
least
somewhat.
You
know
reasonable
in
the
sense
that
almost
everyone
is
going
to
target
a
service
here.
A
F
F
A
A
Okay,
that's
that's
it.
I
encourage
everyone
and
now
that
examples
are
about
to
be
up
to
date
again
to
take
a
look
at
them
and
and
see
if
there
are
other
any
other
glaring
monsters
in
there
that
that
feel
just
not
quite
right.
Anyways,
there
have
been
some
updates
here.
It
looks
like
harry's.
Pr
is
actually
the
most
recently
updated.
So
let's
run
through
this
one.
If
you've
got
time
what
what
has
changed.
F
D
F
F
Relied
so
that's
that's
the
other
part
buoy
that
I'm
trying
to
correct
is
it's
going
to
be
route
policy
under
that
you
have
a
certificate
key
and
then
you
allow
a
disallow
right,
because
we
want
to
manage
more
fine-grained.
Allow
disallow
policies.
So
that's
why
it's.
The
grout
policy
itself
is
a
struct.
D
F
E
F
A
A
I
still
need
to
respond
to
comments,
but
I
have
actually
updated
it,
so
both
should
be
good
to
go
now,
but
with
that
said,
I
want
to
spend
most
of
the
rest
of
the
time
on
this
pr.
If
it's
okay
and
I
specifically
wanted
to
run
through
every
min
max
I've
added
here
and
get
some
kind
of
consensus
on
if
these
minimum
and
maximum
values
are
meaningful,
they
may
not
be
so
if,
if
especially,
if
maximums
are
too
low,
that
would
be
great
feedback
to
have
or
if
they're
too
high.
A
A
A
A
A
Actually
I
don't
think
I
want
a
min
of
one
here,
so
this
is
the
number
of
forward
two
objects
in
this
list.
I
think
men
should
be
zero
right.
Can
you
oh?
No?
This
is
a
forwarding
to
target
so
this
right.
Okay,
so
we
want
at
most.
We
want
at
least
one
if
you've
gotten
this
far.
If
you
have
actually
defined
a
forward,
is
16
too
many.
Like
I
mean,
do
you
want
to
split
traffic
beyond
between
more
than
16
ever.
F
A
A
A
F
F
A
I
mean
the
our
general
idea
has
been
to
start
with
a
reasonably
low
value,
with
the
idea
that
we
can
extend
it
as
a
use
case
bumps
into
it.
If
you
know,
if
we
say
that
you
can
have
up
to
256,
then
there's
some
kind
of
built-in
assumption
that
implementation
should
test
up
to
256
listeners
just
to
ensure
that
it
works.
A
F
A
A
F
C
F
B
B
A
Yeah,
I
I
think
we
just
haven't
run
into
those
yet,
but
as
an
example,
253
seems
to
be
the
standard
limit
and
I've.
I've
used,
253
everywhere,
because
almost
everywhere,
not
just
for
host
names,
because
a
kubernetes
core
validation
uses
is
dns,
subdomain
validation
for
so
many
fields
like
just
a
ton
of
fields,
and
that
includes
this
max
length
of
253,
so
like
resource
names,
are
253
characters
long
at
most,
so
that
that's
where
I
got
this
from
along
with
obviously
host
names.
A
F
A
A
Okay-
well,
I
I
know
we're
just
about
out
of
time
here,
but
I
wanted
to
at
least
introduce
this
and
and
give
everyone
a
chance
to
at
least
you
know,
suggest
higher
limits
for
things
that
don't
make
sense.
One
of
one
of
the
examples
here
is
okay.
This
needs
to
be
increased.
The
listeners
needs
to
be
increased
and
I
can
make
that
note,
but
I've
also
limited
the
number
of
conditions,
and
I
think
that
may
be
a
controversial
one.
F
A
Cool,
I
will
update
this
as
well,
and
I
know
we
have
hit
time
but
yeah.
If,
if
you
have
any
other
thoughts,
there's
a
lot
more
limits.
I've
added
here,
as
you
can
see,
we're
just
a
fraction
of
the
way
through
this
pr,
but
I
just
wanted
to
get
some
of
the
high
level
things
like
listeners
and
forward
two
targets
out
of
the
way
at
east
yeah.
Thanks
thanks
for
the
great
feedback.
A
There
are
a
couple
more
prs
that
I
think
are
close
to
ready
now
and
if
you
have
time,
definitely
take
another
look
at
them.
I'll,
try
and
update
comments
as
well
later
later
today,
and
I
will
make
a
follow-up
pr
to
flatten
this
all
out.
I'm
excited
about
simplifying
these
routes
and,
if
you're
looking
for
ways
to
contribute
a
reminder
that
there
are
a
whole
bunch
of
new
issues
here,
we're
starting
to
move
into
a
time
where
we
really
need
documentation
to
be
better.
A
A
Yeah,
I
think
that's,
I
think,
that's
great,
but
if
you
see
other
issues
that
you
feel
like,
we
really
should
address
by
v1
alpha
one
there's
a
decent
chance.
We
just
missed
it.
We
just
missed
adding
it
so
definitely
go
ahead
and
you
know
ping
any
one
of
the
maintainers
that
are
ping
on
the
issue
and
say:
hey.
Should
this
be
part
of
v1
out
for
one.