►
From YouTube: Gateway APIs Meeting (APAC Friendly Time) 20210816
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,
it's
august,
16.
we've
got
lots
to
get
through
today.
This
is
the
gateway
api
meeting.
Let's
start
off,
I
added
a
bunch
of
things
to
the
agenda,
as
always,
but
feel
free
to
add
suggest
anything
throughout.
This
is
just
what
I
what's
been
on
my
mind
as
we're
getting
awfully
close
to
v1
alpha
2
release.
A
First
off
on
friday,
we
met
with
the
sig
network,
reviewers
and
kind
of
gave
them
an
intro
to
the
api,
and
the
review
process
has
begun
if
anyone's
interested.
There
was
some
somewhat
interesting
feedback
on
that
intro
call.
So
I
can.
I
can
share
I've
recorded
as
much
as
I
remembered
anyways
of
that
I
can
share
that
recording
for
anyone
who's
interested,
but
the
review
process
has
begun
it's
on
pr
780..
A
A
It's
not
it's,
not
great
I'll,
have
to
rebase
a
bunch,
but
it
does
make
for
a
much
cleaner
review
surface
than
any
of
the
alternatives
I
found.
So
yeah,
that's
that's!
What
we're
working
with
there's
been
some
good
discussion
already,
but
I
expect
that
will
continue
to
grow
over
the
coming
week
or
more
depending
on
how
this
goes.
A
I
you
know
it's
been
hard
to
keep
track
of
all
the
changes
that
have
merged
in
we
just
kind
of
got
everything
in
and
then
handed
it
over,
which
is
great,
I'm
glad
we're
at
this
point
already,
but
it
would
be
good
to
kind
of
second
check
our
own
work
and
make
sure
that
what
we're
doing
actually
makes
sense-
and
finally,
michael-
and
this
may
be
optimistic-
is
to
release
v1
alpha
2
in
two
weeks
or
less
so
really
what
I'm
hoping
to
get
out
of
that
is
a
release
this
month,
but
I
know
that
it's
it's
a
fool's
game
to
try
and
predict
when
a
review
will
be
complete.
A
So
this
is
just
my
optimistic
hope
and
we
can
do
whatever
we
can
to
make
that
possible,
but
we
can't
control
the
speed
of
reviews.
So
that's
that's
just
the
the
timeline
I've
been
hoping
for,
but
again
we'll
see
yeah
any
questions
about
this
review
process
at
all.
A
Cool
all
right
keep
on
running,
so
I
tried
to
write
down
a
list
of
priorities.
If
this
is
something
that
we
agree
on,
I
can
try
and
document
it
in
an
issue
or
set
of
issues,
but
I
wanted
to
at
least
have
some
things
that
I
feel
like
are
required
for
us
to
cut
a
v1
alpha,
2
and
others
that
would
be
nice
to
have,
but
aren't
completely
required
the
first
one
we
might
as
well
get
into
it.
A
Nick
has
done
some
awesome
work
to
version
our
docs
and
in
addition
to
that,
I
think
you've
also
really
simplified
our
source.
So,
instead
of
having
everything
version,
you
just
have
a
few
pages
version
which
I
think
is
going
to
be
a
lot
easier
to
maintain.
A
B
Yeah,
so,
basically,
when
I
was
looking
at
the
docs
trying
to
figure
out
how
the
best
way
we
could
do
like
better
versioning
after
a
while,
I
said
like
well.
Most
of
this
stuff
is
the
same
between
the
versions
and
in
fact
some
of
the
files
were
actually
sim
linked
between
versions.
B
So
I
was
like
well,
why
not
take
those
out
and
put
those
as
top
level
nav
and
then
make
it
easier
to
find
where
things
are,
and
so
we've
done
something
like
this
for
contour
and
have
you
know
like
just
the
reference
part?
Is
the
version
part.
The
part
that
actually
changes
per
version
is
the
version
part
and
it's
kind
of
worked.
Okay,
I
think
there's
definitely
better
ways
you
could
do
this,
but
not
without
substantially
changing
the
like
the
docs
workflow.
B
You
know,
we'd
have
to
move
to
a
more
advanced
tool,
like
you
know,
a
hugo
or
something
else
that
does
a
more
advanced
like
with
the
chem
version
of
the
entire
site,
which
is
like
what
cube
does
this
is
kind
of,
ironically
enough,
a
proxy
for,
for
you
know,
a
more
substantial
change
is
trying
to
make
what
we've
got
usable
rather
than
you
know,
build
a
thing
that
actually
does
the
real
thing
that
we
need.
D
Makes
sense,
especially
since
we
are
not
going
to
probably
be
maintaining
the
v1
alpha,
1
guides
yeah
it
just
like.
We
should
just
keep
those
guys
up
to
date
to
the
latest
version.
B
So
yeah
that
makes
sense
to
me
I
mean
I,
I
kind
of
wanted
to
make
to
sort
of
leave
it
there.
As
a
point
in
time
was
the
reason
why
I
left
the
guides
there,
but
yeah
it
would
make
sense
to
move
the
guides
out
as
well.
Maybe
yeah,
like
I
mean
they're,
really
the
the
thing
that
is
critical,
that's
version.
B
This
is
the
api
spec
right,
but
some
of
the
other
stuff
is
so
version
specific
that
you're
going
to
need
to
update
it
substantially
and
so
being
able
to
have
when
it
comes
time.
For
you
know,
one
beta
one
being
able
to
leave
v
one
alpha
two
docs
there
as
the
current
version
and
have
the
v
one
beta
one
docs
proposed
or
unreleased
as
like
we've
got
here,
means
that
you
can
be
working
on
the
you
can
have
the
docs
for
the
upcoming
version
be
visible
without
them
being
the
canonical
docs.
D
D
A
Yeah,
I
mean
there's
no
reason
we
couldn't
change
the
guides
after
this
release.
It's
just
something
that
I
don't
think
we
will
do.
This
still
allows
for
that.
So
yeah,
I'm
really.
B
E
Doesn't
the
doesn't
having
it
versions?
This
way
also
give
us
the
advantage
that
you
can
look
at.
A
A
F
Hey
nick
just
one
question
with
the
sidebar:
is
that
ordered
by
the
order
that
it
shows
up
in
the
yaml.
B
No,
so
it's
actually
manually
ordered
via
the
make
doc
still
yaml.
So
that's
that's!
A
hundred
percent
yellow
is
not
generated
like
it's
manually
specified
in
that
in
that
yeah,
okay
file.
F
B
Yeah,
so
I
I
went
backwards
and
forwards
on
doing
that,
but
yeah
that
makes
total
sense
yeah
to
have
the
stable
version,
be
the
the
the
top
the
not
top
one.
A
B
Sense,
yeah,
no
problem,
so
that
makes
sense
and
then
yeah.
Obviously
that
means
that
when
we
eventually
are
ready
to
start
when
we
start
working
on
future
versions,
we
can
do
the
same
thing.
Just
put
put
it
down
below
marked
as
unreleased
or
something
like
that.
And
then
then
we
can.
You
know,
make
changes
to
those
docs
and
have
them
be
visible
on
the
public
site
without
having
to
do
a
deploy,
preview,
yeah,
yeah,
and
if
you
can
just
click
on
the.
B
I
did
a
little
bit
of
tidying
up
with
the
enhancement
proposals
section
if
you
just
click
on
that
for
a
sec.
So
I
moved
the
sort
of
process
dock
from
the
contributing
section
to
here.
So
you
get
like
an
overview
of
like
what
we're
trying
to
do
here
and
then
you
can
see
the
approved
gaps
in
the
yeah
in
that
little
drop
down,
so
that
there
was
an
overview
page
rather
than
just
going
in
straight
into
the
first
gap.
A
Yeah,
that's
a
really
nice.
I
missed
this
change,
but
this
is
a
great
one,
actually
yeah.
The
gap.
Template
feels
a
little
out
of
place
here.
Maybe
we
don't
need
this
anymore.
A
B
Yeah
and
then
so,
if
you
go
to
contributing
as
well,
I
did
there
was
a
bit
of
duplication
between
the
enhancement,
tracking
and
backlog
page
and
the
enhancement
proposal
section,
but
I
wanted
to
leave
them
there
so
that,
if
you're
looking
at
contributing
as
like,
how
does
that?
What
are
we
trying
to
do
with
this
enhancement
tracking
thing?
So
there's
quite
a
bit
of
duplication
between
those
two
pages.
But
again
I
didn't
want
to
do
a
big
docs
rewrite
at
the
same
time
as
changing
all
of
the
structure.
B
So
I
thought
I'll
keep
it
to
just
messing
with
the
structure
mainly
and
keep
the
actual
docs
changes
to
a
minimum
and
make
it
a
bit
easier
to
review.
We
can
come
back
and
fix
that
later.
If
you
want.
H
I,
like
everything,
I'm
just
the
only
thing
I
worry
about
is
burying
the
guides
a
little
bit
too
much
okay
in
the
reference,
if
we
just
pull
up
the
guides
as
a
as
a
mainline
one,
because
that's
for
like
a
new
beginner,
which
is
the
easiest
place
for
them
to
go,
to
see
how
it
works.
B
Okay,
mate:
do
you
want
me
to
maybe
I
should
swap
it
so
the
guides
is
first,
but
the
guides
is
the.
If
the
guys
is
first
in
the
list,
then
when
you
click
into
reference
you'll,
it
like
expands
out
the
sections
to
get
to
the
first
page
in
the
list,
so
that
makes
sense,
yeah
yeah.
That
makes
sense.
Then
that
means
that
when
you
click
on
reference,
you'll
go
to
v1
alpha
one
guides,
and
then
you
can
see
that
there's
guides
and
lines
and
stuff,
and
then
you
can
go
in
there.
D
A
I
think
that's
actually
a
good
idea.
I
think
that
both
api
types
and
spec
are
very
clearly
referenced,
but
guides
could
have
a
very
similar
section
to
this.
That
is
just
you
know,
version
two,
but
just
yeah
that
that's.
I
G
B
H
Right
I
was
saying
like
do
do
all
these
things
belong
in
reference,
because
I'm
just
looking
at
the
existing
things,
we've
taken
basically
api
types,
the
current
reference
folder
and
guides
and
then
put
it
all
into
the
under
reference.
A
B
I
think-
oh
god
yeah,
I
was
gonna,
say
yeah.
I
think
that
what
rob
was
saying
makes
actually
makes
sense.
You're
100
right
mark
that
we'll
pull
I'll
pull
the
guides
out
into
another
top
level
thing
so
it'll
be
overview,
guides
reference,
contributing
blah
blah
blah
I'm
under
guides.
There
will
be
a
v1
v1
alpha,
1
and
v1
alpha
2.
same
as.
B
Yeah
and
then
and
then
the
guys
will
just
have
the
the
what
they
have
now,
but
you
know
it
will
go
straight
to
the
getting
started
page.
So
that
way,
when
you
click
on
guides,
you
go
straight
to
getting
started
for
the
current
stable
version.
A
Cool
this
is
awesome,
excited
to
get
this
one
in.
A
We
can
get
in
great
okay
cool
the
next
one
on
the
list
is
v1
alpha,
2
docs.
There
are
a
few
things
that
I
think
almost
entirely
guides
that
we
just
have
not
updated
for
v1
alpha
2,
yet
I
think
shane
you've,
you've
volunteered
to
take
on
most
of
these
is
that
correct
yep.
All
right
did
you
want
okay,
awesome,
great,
so
yeah
these
they're
excited
to
get
these
updated.
A
B
A
That
the
next
one
is
772.
This
is
the
pr
that
I've
been
working
on
for
for
a
bit.
I
was
really
just
trying
to
get
ahead
of
what
I
imagined
our
api
reviewers
were
going
to
find
and
and
find
issues
with.
Specifically,
there
were
a
lot
of
places
where
we
really
could
have
tightened
up
validation,
so
this
is
kind
of
moving
them
to
shared
types
that
have
shared
validation,
that
a
pattern
we've
done
in
number
of
places
just
trying
to
to
do
that
elsewhere.
A
This
introduces
that
it
also
tries
to
get
rid
of
any
kind
of
unbounded
lists
by
adding
max
length
same
with
unbounded
strings,
all
these
kinds
of
things
just
trying
to
make
sure
that
we
have
a
max
length
for
as
many
things
as
possible,
basic
validation
and
the
other
thing
that
I
wanted
to
point
out
in
this
pr.
That
is
of
note,
is
there.
Is
this
new
invalid
examples
directory
that
is
used
in
that
in
our
basically
e
test,
run
where
we
have
a
verify
examples?
A
This
runs
through
everything,
tries
to
apply
it
and
make
sure
there's
an
error
so
make
sure
our
validation
catches,
something
it's
really
really
basic
in
terms
of
functionality,
but
hopefully
that's
you
know
it's
certainly
better
than
nothing,
and
it
makes
sure
that
our
validation
is
at
least
somewhat
working,
so
yeah
that
that's
the
gist
of
this
pr
there's
been
some
good
feedback
on
this
one.
Already.
I've
got
some
work
locally
that
I
will
try
to
get
in
later
today,
but
yeah.
A
If
you
have
any
thoughts,
let
me
know
I
I'm
hoping
to
get
this
updated
soon.
A
A
First,
we
need
help
translating
the
existing
v1
alpha,
1
examples
to
v1
alpha
2.
there's
a
number
of
examples
that
have
been
translated
but
I'd
say:
that's,
maybe
a
third
of
our
total
examples
and
we
need
the
rest
of
those
examples
to
to
also
be
in
our
v1
alpha
2
example
set.
I
don't
think
this
is
going
to
be
too
bad,
but
I
think
this
will
be
a
very
good
experience
just
to
show
to
validate
the
api
changes.
A
Cool-
and
this
is
really
the
la
this
one
and
the
last
one
well
actually
all
of
these
are
pretty
related,
but
I
I'm
looking
for
someone
who's
interested
in
writing.
The
change
log
for
v1,
alpha
2..
This
could
correspond
with
any
of
the
bottom
three
here,
but
that
doesn't
have
to.
A
But
actually
let
me
go
through
all
three
of
these
and
then
we
can.
We
can
get
an
idea
of
who
wants
to
volunteer
here.
So
one
a
changelog.
J
About
I'm
sorry,
I
mean
about
translating
the
examples
from
the
we
were
for
one
to
rewire
for
two:
are
you
referring
all
the
examples
under
the
the
root
directories?
We
have
those
routine
gateway
and
also
we
have.
We
want
iphone
2
there.
So
we
have
examples
directory.
A
Yeah,
thank
you
for
clarifying,
so
we
have
all
these
examples
here.
Well
back
in
policy
is
a
bad
one
because
it
won't
translate,
but
as
an
example,
we've
got
this
one,
which
is
a
gateway,
class
gateway
and
route,
and
you
can
see
that
we're
using
the
old
api
version,
and
you
can
also
see
that
we're
using
this
kind
of
route
selector
to
select
routes.
A
Yeah,
that's
that's
a
good
question.
Unfortunately,
the
only
test
cases
we
have
right
now
are
just
enough
to
make
sure
that
what
we
have
in
examples
is
valid.
Ammo
like
it
it's
a
valid
resource,
so
you
can
install
it
and
it
will
work,
but
we
we
don't
have
anything
that
goes
further
than
that,
and
actually
you
know
ensures
that
a
controller
will
consider
it
valid.
We
just
know
that
it
will
pass
our
crd
validation.
A
That's
all
so
more
would
be
great,
but
until
then
we've
kind
of
had
to
rely
on
our
judgment
and
code
review,
which
I
know
is
not
a
perfect
art
here.
J
A
Right,
yeah,
that's
a
good
yeah,
so
as
we're
defining
our
crds,
we
we
add
those
little
annotations
like
in
that
previous
pr,
I
was
showing
there's
things
like
max
link.
There's
things
like
regex
validation.
Those
are
the
kinds
of
things
that
are
validated
every
time
you
try
and
install
a
route
or
a
gateway
or
anything
else.
A
B
Yeah,
I
think,
and
to
go.
I
think
the
question
I
think
the
question
you
asked:
sorry,
I'm
not
sure
if
I'll
say
anything
about
jimin
the
that
you
know
can
we
can
we
test
the
the
the
examples
actually
do
what
they're
supposed
to
do.
That
would
be
amazing
if
we
could
do
that,
but
I
think
the
problem
is
that
right
now,
because
we're
defining
the
spec
for
what
implementations
we'll
have
to
we'll
have
to
implement
no
one's
going
to
have
implemented
it
yet
for
us
to
be
able
to
test
against
anything.
J
B
Yeah,
I
think
also
looking
at
that
the
rob
the
other
thing
we
should
do
is
we
should
actually
we
should
just
move
the
example
thing
to
be
completely
version.
There
should
be
no
unversioned
examples.
G
But
great.
B
Yeah
yeah,
if
you
want
to
note
that
down
there
but
yeah,
so
I
think
that's
and
if
anyone
else
wants
to
help
with
that
more
than
more
than
happy
to
have
other
people
take
files
like
maybe
do
the
first
restructure
and
then
you
know,
might
leave
the
files
there
and
then
you
and
then
other
people
can
pick
them
up.
It's
a
great
way
to
learn
how
the
api
works,
like
looking
between
the
two
versions
and
and
need
to
figure
out
the
right
way
to
do
things.
B
No
problem
yep
so
I'll
I'll
get
a.
What
I'll
do
then
is
I'll
structure
it
so
that
the
initial
pr
will
just
move
everything
into
the
version
directories
you
and
then
they'll
be
I'll.
Just
do
a
quick
initial
pr
there
to
do
that
and
then
once
we
get
that
one
in
then
we
can.
Then
we
can
sort
of
assign,
assign
the
files
to
each
other.
We
can
agree
which,
but
which
person
which
people
do
which
files
and
then
like
separate
vrs.
A
Awesome
great,
I
yeah
that
that's
awesome
and
yeah,
just
the
the
other
things.
I
think
that
we
really
need
to
you
know
have
in
place
before
v1.
Alpha
2
release
are
that
change
log,
some
kind
of
documentation
and
or
a
blog
post.
I
think
this
could
be
the
same
content
that
describes
the
key
changes
between
v1
alpha,
1
and
v1
alpha
2..
A
I
I'm
not
sure
again
on
where
we
want
to
put
this,
but
this
seems
like
it
would
be
good
content
as
anyone
who's
interested
in
the
api
and
then
finally,
looking
for
someone
who's
interested
in
actually
leading
the
v1
alpha
2
release
process
this
last
one
specifically,
we
need
at
least
one
maintainer
involved
so
far.
A
I
think
harry
and
myself
have
released
versions
of
the
api,
but
very
happy
to
have
someone
else
be
the
one
to
click
the
buttons
do
the
do
the
formal
process
to
actually
release
a
version
of
the
api.
A
So
if
there's,
if
there's
any
volunteers
interested
in
this
one
as
well,
so
those
are
three
things
that
all
feel
pretty
related.
But
if
there's
any
volunteers
for
any
of
them,
I'd
love
to
hear.
B
So
I
don't
want
to
jump,
I
don't
want
to
take
away
from
anyone
else,
but
if
no
one
else
is
willing
to,
I
am
the
yeah.
This
is
my
primary
focus
for
the
next
little
bit
anyway,
so
may
as
well.
A
Sorry
to
clarify
for
for
all
of
these
or
for
one
specific
one.
B
A
A
Let's
see
where
we
go
and
okay
great
and
I
this
if
we
if
we
do
end
up
doing
a
blog
post
here,
we
we
obviously
need
someone
to
to
lead
the
process
on
this
and
and
and
help
write
it
out.
But
it
feels
like
another
one
that
could
be
collaboratively
authored
by
you
know
a
bunch
of
us
but
yeah,
I
think
that's
does
this.
Does
this
list
make
sense?
Is
there
anything
we're
missing
here
that
that
feels
like?
We
need
to
get
it
in
for
release.
I
guess
I
I
should
also.
A
I
think
it's
kind
of
it
goes
without
saying,
but
we
need
this
actual
approval
to
get
in,
but
otherwise
is
there
anything
else
that
anyone
can
think
of.
J
A
A
I
I
don't
know
nick
since
you're
restructuring
it,
you
might
may
have
an
idea,
but
I
also
think
we
need
something
on
the
kubernetes
website,
potentially
the
kubernetes
blog
to
describe
these
these
changes
in
this
progress.
At
least.
I
think
that
would
be
helpful.
H
Does
our
does
netflix
support
a
blog
post
format?
I
guess
we
could
use
any
old
page
and
just
put
a
date
on
it.
It
becomes
a
blog
post.
H
H
Then
yeah,
I
think
it
makes
sense
to
have
a
a
blog.
I
mean
it
does
it.
It
allows
the
project
to
provide
kind
of
point
in
time.
Communications
to
the
community,
which
I
think
is
helpful
and
all
it
would
require,
was
to
add
a
new
page
that
has
dates
on
it
and
yeah,
and
I
think
that's
v1,
alpha
2
is
definitely
notable
enough.
I
think
to
have
another
korean
blog
post.
There's.
H
Definitely
I
don't
know
if
anyone
else
knows
this,
but
we
did
find
out
that
that
was
the
number
one
blog
post
for
like
30
days
running
on
the
kubernetes
io
site.
So
I
think
there's
definitely
like
appetite
for
it.
I'm
happy
to
take
my
name
out
of
the
running,
since
I
did
the
last
one.
That
leaves
the
opportunity
for
someone
else
to
do
the
kubernetes
one.
A
That's
awesome,
I
I
feel,
like
I
heard
that
once
and
I
completely
forgot
that
we
were.
We
had
that
kind
of
usage
or
views
on
that
blog.
J
A
Cool
yeah-
and
I
guess
I
guess
we'll
leave
that
open
for
a
little
bit
since
it's
going
to
be
one
of
our
the
later
things
we
do
I'm
well,
I
don't
know,
but
I
I
will
say
you
did
a
great
job,
obviously
on
the
first
blog
post.
So
if
no
one
else
is
interested,
I'm
very
happy
to
still
have
you
involved,
but
I
know
I
know:
you've
got
a
million
things
on
your
plate,
so.
D
A
Okay,
yeah,
that's
that's
all
I
had
on
this
required
for
release
section
here.
The
other
thing
that
I
think
is
really
nice
to
have,
and
maybe
nick
I
don't
know
if
you
want
to
talk
about
this
more
you've
been
you'd.
Mention
that
you,
you
might
have
someone
you
know,
come
in
and
take
a
look
at
our
docs
content
as
a
whole
and
provide
suggestions
on
how
we
can
improve
it.
B
So
now
I
need
to
check
in
with
the
celeste
so
celeste
hogan
from
the
cncf
she's,
one
of
the
cncs
like
paid
tech
writers.
She
coordinated
a
doctor
view
for
contour.
That
was
amazing,
and
so
I
asked
her
if
we
were
allowed
to
use
that
as
a
process
as
well,
and
she
was
like
I
don't
know,
but
in
short
the
eventual
answer
was
yes,
so
she
said
that
she
was.
B
You
know
it's
holiday
season
in
the
u.s
she
was
away
and
so
she's
going
to
look
at
it
when
she's
back
so
I'll.
Just
follow
up
with
her
it'll
be
good.
If
I
could
get
a
bunch
of
these
docs
improvements
in
beforehand
and
get
her
to
review
like
the
stuff
that
we've
a
slightly
better
version
of
the
doc
site
rather
than
you
know
them
the
let's
be
charitable
and
say
post
a
child
for
organic
growth
we
had
earlier
and
so
yeah.
B
I
think
that's
that's
what
I'd
like
to
definitely
do
that.
The
other
thing
I'd
like
to
do
for
the
main
page
is,
I
think,
a
while
ago
I
put
a
sort
of
summary
of
what
the
objects
were
for
what
I
thought.
We
should
say
the
objects
before
into
the
channel
that
got
pretty
broad
agreement.
So
I'll
also
do
a
pr
about
that
one.
B
The
sort
of
I'd
like
that
to
be
early
on
in
the
sort
of
user
journey
of
using
the
site,
but
there's
a
thing
that
says
we
anticipate
you
know
the
the
the
very
the
core
types
of
route
objects:
here's
what
they're
intended
to
be
used
for
and
how
you
use
them
and
the
differences
between
them,
because
I
think
that's
one
of
the
things
we
really
poorly
explained
in
a
moment,
and
I
know
that
when
I've
got
queries
about
gateway
api
lots
of
people
are
like.
B
B
If
you
read
carefully,
but
there's
nothing
up
front,
that
sort
of
says
stuff,
that's
stuff,
and
I
think
we
just
need
to
make
some
of
those
things
more
explicit
which
will
save
us
all
implement
as
both
implementers
and
and
maintainers
and
contributors
to
this
project.
A
lot
of
time
and
effort.
I
think.
A
Yeah,
that's
that's
awesome.
I
am
excited
for
all
these
improvements
to
get
in
yeah.
Okay,
this
this
one
thing
I'll
I
I'm
gonna,
be
I
I
volunteer
to
take
this
one
on,
because
I
I
think
I
wrote
the
initial
security
model
docs
and
what
you
said
about
organic
growth
is
definitely
true.
This
is
very
much,
unfortunately,
just
something
that
feels
very
outdated
now
and
confusing
and
and
anyway
it
that
that
whole
page
needs
some
cleanup.
So
I
can
work
on
that.
One
yeah
awesome
cool
yeah.
A
I
think
that's
enough
of
that.
The
other
things
I
wanted
to
highlight
here
were
just
signet
pr
review
follow-up.
So
far,
just
cal
has
given
feedback
at
least
last
time.
I
checked,
but
he
had
some
good
questions
on
here
that
I
thought
were
worth
broader
discussion,
so
yeah,
let's
get
into
them
one
of
his
one
of
his
is,
I
think,
very
related
to
discussions
we've
had
before.
A
I
couldn't
find
a
good
reference
for
those
discussions,
but
the
concern
that,
with
gateway
class
and
parameters
ref,
if
anything
about
the
gateway
class
changes,
it's
unclear
what
happens
to
the
gateway,
we've
kind
of
left
that
open
and
maybe
more
open
than
we
need
to.
I'm
not
sure,
and
so
his
question
is
really
about
how
we,
how
we
avoid
that
kind
of
massive
blast
radius.
I
guess
right,
so
you
can
imagine
if
a
gateway
class
changes,
references
invalid
parameters,
something
like
that.
A
Does
it
blow
away
all
your
gateway
gateways
that
are
based
on
that
gateway
class?
I
know
we've
had
at
least
some
discussion
around
treating
gateway
class
as
a
template,
and
I
think
that's
a
rough
summary
of
what
we're
planning
to
do
with
gke's
implementation,
in
the
sense
that
the
gateway
class
affects
the
gateway
as
the
gateway
is
being
created,
and
then
that
relationship
is
basically
gone
like
if
the
gateway
class
changes
it
does
not
affect
the
gateway.
From
that
point
in
time,
on,
I
don't
know
is
anyone
else.
A
B
For
contour,
we
were
originally
planning
on
having
the
that
have
like
a
config
object.
We
were
in
the
process
of
working
on
a
con,
contour
config
object
for
for
the
contour
operator,
and
so
we're
basically
just
going
to
use
that
same
object
as
a
reference
in
there.
I
think
that,
because
we've
changed
the
design,
that's
no
longer
valid.
B
B
You
know
the
I
mean
we
can
explicitly
say,
look
you
know
we
can.
I
think
that
we
could
say
it
as
we
make
recommendations
for
what
this,
how
this
flow
should
work.
But
it's
you
know
their
shoulds,
rather
than
must,
I
think,
is
probably
the
best
way
to
go
about
it.
H
Yeah
at
least
like
when
we
went
when
we
got
to
implementing
it,
the
having
it
be
a
reconciled.
Object
would
be
so
challenging
just
to
implement
for
us
and
also
the
damage
it
could
create.
It
just
didn't
seem
like
there's
any
benefit
to
it
like
nobody
would
want
to
use
it
in
that
way.
So
yeah,
that's
where
it
felt
like
okay.
Well,
is
this
a
is
this
part
of
the
spec
to
say
that
it's
not
a
reconciled
object?
It's
only
a
template,
so
yeah.
A
B
I
actually
need
to
check
what
we're
currently
doing
the
the
rest
of
the
team
has
been
working
on
working
on
some
of
this
stuff,
while
I've
been
focusing
on
the
api
itself,
so
I
need
to
check
before
I
100
but
yeah,
so
I
think
having
it
as
a
template
sounds
reasonable
to
me.
A
B
C
Would
be
the
proper
terminology?
Yes,
I
think
the
only
concern
I
would
have
is
if
we're
making
it
implementation.
C
You
know
implementers
having
the
choice
of
how
do
they
behave
then
it
could
be
confusing
for
users
that
might
be
used
to
api
sp,
the
gateway
api
spec
and
using
it,
but
you
know
for
some
reason,
they're
working
with
a
different
implementation
or
something
and
and
they
could
really
screw
themselves
up
if
one
implementation
is
different
from
the
one
they're
used
to
yeah
great
I'm
not.
B
C
It's
so
dramatic
of
a
difference
whether
it's
you
know
one
way
or
the
other,
that
it
would
really
invite
somebody
unintentionally
creating
disaster
in
a
sense,
if
they've
changed
from
one
implementation
to
another.
B
I
mean
we
could
we
could
say
it's
up
to
you,
how
you
do
this,
but
you
must
not,
you
know,
do
a
fully
full
reconciliation
loop
on
these
parameters
refs
or
we
we
could
just
say
you
must
treat
this
as
a
creation.
Temp,
create
creation,
time
template
and
you
at
least
and
then
carefully
manage.
If
you
are
going
to
do
changes
on
it,
then
you
should
be
extremely
careful
with
them,
because
the
blast
radius
is
very
big
or
something
like
that.
D
B
Why,
like
we
can
probe
for
our,
for
you,
know,
use
cases
and
stuff
like
that
and
understand
if
you
know
how
you
know
why
why
people
would
not
do
that,
like
I,
I
agree
with
bowie,
like
I'm
kind
of
not
sure
what
people
are
doing
yet,
so
I
don't
want
to
kind
of
reluctant
to
do
must
yet,
but
I
agree
that
it's
terrifying,
the
idea
of
having
a
fully
reconciled
object.
F
F
Inside
on
the
implementation
side,
at
least
for
envoy
kind
of
a
natural
approach,
is
to
look
at
all
your
stuff.
Look
at
all
your
cids
generate
the
envoy
proxy
and
smash
box
object
and
then
smash
it
down.
If
you're
not
keeping
state
about
what
you've
already
generated,
then
how
would
you
implement
a
template
approach.
A
Yeah
I
mean
that
is
the
problem
that
that
that's
we've
gone
to
great
lengths
to
try
and
keep
some
basic
sense
of
state
in
gke
to
avoid
this,
but
that
that's
a
good
point,
that
is
a
problem
with
requiring
templating
behavior,
is
that
you
need
to
understand
what
point
in
time
you
and
what
set
of
parameters
you
use
to
configure
a
gateway.
K
Yeah,
I
was
just
going
to
say:
I
mean
one
possible
solution.
Is
that
things
that
are
dynamic
that
are
say
for
envoy,
like
part
of
xds,
you
actually
consider
to
be
like
policies
that
are
kind
of
dynamically
attached
to
the
gateway
and
only
use
gateway,
class
parameters
for
say
configuring,
the
actual
deployment
of
envoy
itself.
K
So
for
us,
I
don't
think
we're
planning
to
use
gateway
class
at
all
so
far,
but
I
think
we
would
be
closer
to
that
pattern
and
that
may
somewhat
solve
that
issue.
I
it
really
depends
where
you
want
to
put
the
configs.
I
guess,
but
then
it's
kind
of
like
gateway
class
is
like
your
deployment,
template
sort
of,
and
then
everything
else
is
kind
of
dynamic
policy.
B
That's,
I
think,
that's
a
good
way
to
put
it
that
if
we're
talking
about
it
being
a
template,
it's
like
a
it's
a
deployment
template
for
the
gateway,
and
then
that
makes
it
more
sense.
I
do
think
james
that
your
point
is
100,
fair
about
on
the
way
that
that
the
the
obvious
way
and
speaking
as
someone
who
you
know,
maintains
a
controller
that
works
in
exactly
the
way
you
described.
B
You
know
it's
actually
a
bit
of
an
any
pattern.
I
think
that
you
to
have
a
controller
that
just
takes
things
and
you
know,
builds
a
state
and
then
jams
that
whole
state
down
to
envoy
every
time.
I
think
that
has
created
problems
for
contour
yeah
and
it's
better
to
keep
some
state
and
do
incremental
xds
and
a
bunch
of
other
stuff
like
that.
So
yeah.
B
F
B
Yeah,
yes,
I
think
you're.
I
think
that
that's.
That
is
a
good
comment
for
you
to
put
down
rob.
I
think
that's.
A
Okay,
I
will
run
with
that
feel
free
to
add
comments.
This
is
obviously
linked
in
the
agenda
and
I
I've
been
trying
to
follow
up
on
the
various
comments
in
this
pr,
but
definitely
if
you're
interested
there's
some
good
comments
and
good
good
things
to
to
get
people
thinking.
So
if,
if
you
have
any,
if
you
want
to
help
out
in
responding
to
these,
that's
always
appreciated
too.
A
Okay,
the
next
one
that
I
thought
was
was
kind
of
interesting.
Is
this
confusion?
I
had
never
really
thought
of
it
as
being
a
confusing
distinction,
but
the
confusion
between
the
addresses
on
a
gateway
and
the
host
name
on
a
listener,
and
especially
now
that
we
have
an
address
of
type
hostname
on
the
gateway
where
we
allow
for
that
inside
spec
and
this
leading
to
some
form
of
confusion
about
what
the
purpose
of
each
field
is.
And
I
don't
think,
we've
clearly
distinguished
that
in
the
docs.
D
A
About
the
abstract,
I
mean
honestly,
I
I
think
this
is
really
just
meant
to
solve
the
use
case
of
a
a
certain
cloud
that
the
provider
that
exposed
their
load
balancers
via
hostname
cname,
instead
of
a
ip
address.
D
Okay,
we
should
just
explicitly
say
that
and
point
to
other
examples.
I
think
then
ingress
also
end
up
in
this
situation.
Yeah
they
did
okay
yeah,
then.
B
That
should
be
resolved
yeah
I
mean,
I
think.
The
the
difference
between
the
the
difference
between
the
two
fields
is
that
the
addresses
field
is
is
like
yeah,
as
you
say,
rob
it's.
It's
a
request
for
the
outside
address
of
the
gateway
and
the
the
host
names
on
listeners
are
about
routing
discrimination.
How
do
you
you
know?
How
do
you
route
requests,
or
you
know,
connections
to
the
to
the
routes
behind
the
thing
and
choosing
between
different
routes?
A
Yeah
yeah,
that
makes
sense
I
I
can
see
the
confusion
of,
should
I,
if,
if
I
want
this
domain
this,
this
hostname
foo.com
to
be
associated
with
my
gateway,
should
I
put
it
in
spec.addresses
because
and
then
rely
on
something
like
external
dns,
to
pick
that
up
and
make
that
a
reality,
you
I
think
you
could
interpret
that
as
a
possibility
based
on
our
current
spec,
even
though
I
don't
think
that
was
the
intent.
B
Yeah,
I
think
it
actually
is
it's
actually
one
of
the
things
that's
probably
worth
us
is
talking
more
to
the
external
dns
maintainers
about
how
they,
how
they
are
considering,
making
things
work
with
gateway
and
how
we
think
it
should,
because
that's
going
to
be
a
big
part
of
how
people
use
this
api
yeah
external
dns
insert
manager
are
the
two
obvious
things
that
we
need
to
make.
The
experience
nice
and
smooth
agree.
A
Okay,
I'll
keep
on
going.
That's.
Let
me
I'll
make
a
note
to
follow
up
with
some
external
dns
maintainers
as
well.
On
that
one,
the
last
one
was
about
protocol
confusion.
I
didn't
get
enough
time
to
really
look
into
this
one.
This,
I
think
yeah.
It
is
the
last
comment
on
the
pr
and
the
the
confusion
was
basically
about
the
the
mixed
concepts
here.
The
idea
that
we
have
both
hp
and
tls,
which
could
be
over
tcp
or
hdp,
and
trying
to
make
sense
of
all
of
that.
D
A
F
So
I
feel
like
also
people
coming
from
sig
network
are
going
to
have
a
very
you
know:
they're
used
to
network
concepts
right
they're
used
to
thinking
about
things
in
terms
of
like
layered
layered
protocols,
so
smashing
different
layers
together
is
going
to
be,
it
is
going
to
feel
is
going
to
feel
strange
to
them.
B
Yeah,
I
think
that
it
definitely
it
definitely
warrants
a
better
explanation.
In
my
mind,
it's
something
like
this
is
actually
a
syntactic
sugar
for
for
sort
of
choosing
the
classes
of
routes
that
that
can
be
attached
here.
Like
that's
really
what
the
protocol
field
is.
It's
like
a
syntactic
trigger
for
saying.
B
I
D
F
F
I
think
the
problem
here
is
that
if
you
once
you
try
to
carefully
delineate
everything
across
you
know,
protocol
layers,
things
aren't
in
practice,
delineated.
F
Clearly
I
agree,
and
then
you
also
get
this
explosion
of
complexity,
which
proxies
don't
actually
do
like,
like
trying
to
tell
people
like
getting
people
to
configure
things
in
terms
of
oh
here's,
a
tcp
and
the
tcp
goes
up
to
some
http,
and
then
you
know
we
might
as
well
just
be
configuring
nginx.
At
that
point,.
D
B
F
F
With
that-
and
it's
also
about
how
to
you
know,
terminate
that
traffic
in
and
then
how
to
send
the
request.
So
it's
about
those-
maybe
that's
one
of
the
reasons
why
it's
kind
of
difficult
to
describe,
because
it's.
F
B
I
think
that's
a
pretty
good,
that's
pretty
good
hack,
but
I
agree
with
harry
that
I
think
part
of
the
confusion
is
that
that
we're
that
we
have
the
you
know
we
have
all
of
these
things
about
yeah,
about
different
types
of
routes
and
what
different
types
of
routes
do.
What
that
are,
if
you've
been
using
the
api
for
a
while,
are
pretty
clear,
but
we
don't
like.
B
I
said
we
don't
explicitly
say
that
stuff
very
well
and
that's
why
I
think
yeah
the
table,
the
table
that
I
was
talking
about,
maybe
that
maybe
that
needs
to
go
in
here
as
an
explanation
for
carl.
But
but
we
need
to
have
that
as
one
of
the
first
things
you
see
is
like,
so
you
can
create
all
these
different
types
of
route
objects
and
here's
what
we
intended
to
be
used
for
he's
really
important.
A
Yeah
agreed
that
that
could
really
help
make
this
a
little
bit
easier
to
understand.
I'm
going
to
leave
this
as
a
note
for
bowie
to
follow
up,
but,
of
course
anyone
else
is
also
welcome
to
chime
in
here
on
the
thread
or
as
a
pr.
D
A
Okay,
one
thing
that
I
just
remembered
in
slack
before
we
end
this
meeting.
There
was
a
question
in
slack:
there's
a
thread
on
there
about
which
implementations
are
planning
to
support
v1,
alpha
2
and
v1,
alpha
1
like
are
there
any
implementations
out
there
that
are
planning
to
support
both
api
versions
at
the
same
time
or
are
implementations
going
direct
to
v1,
alpha
2
and
dropping
v1
alpha
1.?
K
I
did
have
have
one
thought:
east
geo
is
going
to
do
whatever
everyone
else
does,
but
would
it
make
sense
to
kind
of
release
alpha
2
internally
to
controllers
and
then
give
us
like
a
week
or
two
to
maybe
that's
way
too
short,
but
to
kind
of
put
together
our
view,
one
alpha
to
support
and
then
go
publicly
announce
it
so
that
people
can
actually
try
it
out
once
we
release
it
or
I
guess
that
could
just
be
the
blog
post
and
stuff
that's
kind
of
publicizing
it.
A
Yeah
I
had
thought
about,
you
know
specific
to
a
blog
post.
It
would
be
really
nice
if
there
were
at
least
a
couple
implementations
that
people
could
go,
try
it
out
with
right
away.
I
think
we're
awfully
close
to
having
something
that
could
qualify
as
a
release
candidate.
At
least
I
you
know,
I
I'm
hoping
that
we're
not
going
to
have
like
huge
massive
changes
as
a
result
of
this
sig
network
review,
but
I
I
could
get
on
board
with
something
more
formal
than
that.
Even
I
don't
know
what
others
think.
B
B
A
That
yeah,
that
that
sounds,
I
think,
that's
a
really
reasonable
step.
At
this
point,
I
I
look
back
at
v1,
alpha
1
and
I
think
we
had
to
release
candidates
before
we
actually
cut
v.
One
alpha
one-
and
it
seems
like
a
similar
concept
here-
would
make
sense.
B
A
Cool
okay!
Well,
I
think
that's
perfect,
perfect!
All
right!
Well,
thanks
everyone!
I
think.
That's
it
for
today
see
you
in
slack
and
github
and
wherever
else
and
thanks
to
everyone
for
the
discussion,
cheers.