►
From YouTube: Service APIs Meeting (EMEA Friendly Time) 20200803
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
We
are
recording,
it
is
september,
3.,
welcome
to
service
apis
meeting
for
september
3
and
welcome
to
september
everyone
we're
making
good
progress
here
for
those
of
you
who
were
at
office
hours
yesterday.
This
release
checklist
is
going
to
look
really
familiar.
It's
slightly
out
of
date.
I
think
some
of
these
pr's
have
merged
since
then.
Maybe
even
this
one
we'll
see
no,
not
quite
yet,
okay,
but
we're
making
good
progress
on
the
tls
front.
On
the
advanced
routing
front,
I
think
we're
almost
done
back-end
policy.
A
I
think
we're
almost
done
same
with
udp
route.
Most
of
these
you
know
all
all
of
these
have
pr's
at
this
point
and
they're
either
lgtm
very
close
to
it
so
yeah.
I
I
don't
want
to
spend
too
much
time
on
this.
I
think
I
think
we're
in
a
good
place.
A
What
I
did
want
to
cover
today
was
potentially
new
work,
and
that
is
based
on
some.
What
I
thought
was
really
helpful
feedback
from
tim
and
and
some
from
dan
as
well.
I
think
we've
already
responded
to
a
lot
of
dan's
feedback,
but
I
did
want
to
include
some
of
that
in
here
that
maybe
we
hadn't
properly
addressed
yet,
and
so
I
created
a
doc
that
should
I
think
everyone
should
be
able
to
see
this.
It's
linked
in
the
agenda
at
this
point
and
I
for
context.
A
Last
friday
I
went
through
this
api
with
tim
for
a
couple.
Hours
and
reviewed
top
to
bottom
got
some
really
good
feedback,
and
I
wanted
I
taken
some
notes
and
I
cleaned
those
up
and
tried
to
turn
them
into
kind
of
actionable
things,
and
there
are
as
much
as
I
started,
creating
issues
for
some
of
them.
There
are
just
too
many
small.
A
So
I
wanted
I
wanted
to
go
through
and
if
there
are
some
things
that
we're
all
in
consensus
on,
maybe
we
can,
you
know,
combine
a
few
fixes
into
a
single
pr,
but
anyways
with
that
said,
I
wanted
to
provide
just
a
bit
of
background
as
far
as
what
that
feedback
was.
A
So
this
is,
you
know.
A
lot
of
these
are
really
tiny
things,
but
I
thought
this
was
helpful.
I
know
I've.
I've
heard
this
from
tim
before,
but
I
haven't
been
thinking
about
it
as
I've
been
reviewing
code,
but
one
of
tim's
preferences
is
for
easier.
Api
reviews
type
should
always
appear
in
the
order,
their
reference
so
as
an
example,
gateway
includes
listener
and
a
variety
of
other
things.
So
in
the
gateway
file,
it
would
be
helpful
if
gateway
showed
up
first,
followed
immediately
by
listener,
followed
by
whatever
listener
references
and
so
on.
A
So
it's
easier
to
process
as
you're
reading
through
the
types
definitions,
I
did
create
an
issue
for
this.
The
concern
with
this
one
is
it's
going
to
create
a
lot
of
conflicts
so
yeah.
A
We
can
time
this
when
there
aren't
quite
as
many
things
in
flux,
but
if
you're
working
on
anything
new
just
keep
this
this
general
principle
in
mind
another
one
that
would
end
up
you
know
changing
a
lot
of
different
places
is
that
we
should
really
have
a
max
length
for
every
list,
map
or
string,
and
this
makes
a
lot
of
sense.
A
I
think
this
makes
sense.
It'll
take
a
while
to
get
every
potential
value
here
correct,
and
I
should
also
say
if
at
any
point
anyone
has
feedback
or
thoughts
definitely
interrupt
me
because
there's
a
lot
of
different
things
to
go
through
here.
A
Okay,
the.
B
Sorry
rob
I
was
just
gonna
ask
you
were
mentioning
like
issue
291
as
an
example.
You
wanted
to
hold
off
on
that
or
I'm
just
looking
at
these.
A
A
A
So
that's
a
good
clarification.
I
don't
think
there's
much
open
on
this
one.
Someone
can
correct
me
if
I'm
wrong
here,
but
this
is.
This
is
probably
a
good
example
of
something
like
you
could
start
on.
There's
I'll
say
if
you're
interested
in
contributing
this
is
a
bucket
list
of
things.
That
would
be
great
to
get
some
help
with
there's
there's
a
long
list
of
relatively
small
but
helpful
fixes
here.
B
Yeah,
that
sounds
great,
especially
just
getting
started.
So
thanks
for.
A
It
tim
tim
thought
that
the
defaulting
config
map
here
is
probably
not
a
great
idea
or
user
experience
for
extension
ref
and
the
rationale
was,
if
you
see
an
extension
ref
and
you
just
see
a
name-
it's
not
obvious
to
most
people
that
that
means.
Oh,
this
is
a
config
map
right
it
and
I
know
defaulting.
If
you're
you
know
it
will
eventually
show
up,
but
if
you're
looking
at
the
manifest
and
a
yaml
file
somewhere
as
an
example,
this
is
one
particular
instance
where
it
the
default,
doesn't
exactly
make
sense.
A
I
went
into
a
little
bit
more
issue.
I
actually
created
more
detail.
I
actually
created
an
issue
for
this
one,
and
the
idea
of
you
know
defaulting
to
a
config
map,
feels
different
than
defaulting
to
secrets
because
for
secrets
you've
got
you
know
as
an
example:
tls
certificates,
that's
almost
always
going
to
be
secret
ref
for
forward
two.
A
That's
almost
always
going
to
be
a
service
ref,
so
a
name
kind
of
sort
of
makes
sense
there,
I'm
not
as
sold
out
and
and
tim
wasn't
as
sold
on
the
idea
that
a
config
map
would
be
a
really
common
extension
point,
or
at
least
sufficient
of
being
a
default,
but
yeah
anyways.
A
So
if,
if
anyone
and
and
these
are,
these
are
just
feedbacks
that
doesn't
mean
it's,
you
know
if
these
are
just
pieces
of
feedback,
it
doesn't
mean
that
any
one
of
these
things
has
to
be
the
way
it
is
if,
if
anyone
wants
to
push
for
a
different
approach
here,
definitely
let
me
know
speak
up
whatever
the
the
next
bit
of
feedback
is,
you
know,
was
a
question
around
why
we're
using
resource
and
reference
types
and
the
standard
has
traditionally
been
kind,
and
I
think
I
don't
see
micah
on
this
call
I,
but
maybe
damian,
do
you.
D
I
remember
mikaya
making
reference
to
sun
yeah,
the
upstream
issue
that
had
a
lot
of
dialogue
around
when
it's
a
when
it's
a
reference
using
a
resource
as
opposed
to
kind
yeah.
I
don't
remember
the
details.
A
This
does
not
feel
standard,
yet,
even
if
it
is
technically
better,
I
I
believe
you
know
I
did
some
digging
to
try
and
find
the
source,
and
I
think
it
it
comes
back
to
this
david
eads-
commit
where
he
added
all
the
reasons
not
to
use
object
reference,
the
shared
object,
reference
type
and
specifically
says:
in
most
cases
the
dependency
is
on
the
group
resource
to
people.
Not
group
kind
kind
is
not
a
precise
mapping,
so
I
think
that's
reasonable,
but
I
don't
know
how
many
people
will
have
read
this.
A
So
if
we,
if
we
do
think
group
resource,
is
the
way
to
do
it,
then
we
should
really
document
why
and
that
it
is
a
pattern.
That's
yeah,
my
thoughts.
There
does
anyone
feel
strongly
one
way
or
another
as
far
as
the
group
resource
pattern
versus
group.
D
Cool
yeah,
I
mean
I'm
right
there
with
you.
I
know
to
I
mean
my
inclination
was
using
kind
just
because
it's
it's
natural
right.
It's
the
way
that
things
have
been
done
and
to
your
point,
even
if
using
the
resource,
is
technically
a
better
approach.
It
does
require
a
new
way
of
thinking.
So
so
is
there
an
issue
open
to
kind
of
look
at
that
again
and
decide
yeah.
A
D
Can
you
tag
mikaya
on
that
and
when
I
talk
to
him
I'll
I'll,
bring
it
up
and
yeah?
I
think
it's
worth
worth
discussing
some
more.
A
It's
amazing
he
has
a
one
named
github
handle
that's
yeah
cool,
then
this
is
really
related.
I
have
not
created
an
issue
yet
and
I
I
think
this
is
the
same
kind
of
idea.
I
tim
suggested
that,
instead
of
redefining
condition
every
time
we
could
just
use
the
meta,
v1
condition
type
that
seems
reasonable
to
me.
I
did
you
know
I
did
look
because,
obviously
the
reason
we're
not
using
the
standard
object.
Reference
is
because
of
that.
You
know
that
pr
that
says,
don't
use
this.
A
A
A
Yeah,
okay,
so
next
these
these
are
all
going
to
be
pretty
quick.
I
think
controller
spec
and
validation
should
line
up
with
ingress
class.
They
the
current
documentation,
current
godoc
around
the
controller
spec,
does
not
completely
line
up
with
ingress
class
and
related
to
that
dan
had
a
comment
that
it
wasn't
entirely
clear
to
him.
What
controller
actually
meant
there.
A
You
know
coming
from
the
previous
concept
of,
say,
ingress
class,
which
had
a
slightly
different
meaning
that
you
know
ingress
classed
annotation
that
is,
and
and
so
just
being
very
clear
in
our
documentation.
A
What
we're,
what
referring
to
controller
actually
means
it's
it's
fairly
limited
right
now,
so
there's
room
for
improvement
here
for
allow
gateway,
namespace
selector!
You
know
there
were
a
couple
bits
of
feedback.
He
was
you
know,
thinking
about.
Is
there
any
other
way?
We
can
do
this,
because,
obviously
this
feels
not
ideal.
We've
talked
about.
Potentially
quota
can't
find
a
way
to
make
that
work.
A
As
far
as
this
one,
and
at
the
very
least
he
was
asking,
can
we
come
up
with
a
shorter
or
simpler
name?
And
this
is
a
tiny
improvement,
but
now
that
we're
removing
allowed
route
name
spaces
from
here,
and
so
we
didn't
have
the
one
as
a
selector
and
wasn't
one
isn't
a
selector
problem.
B
A
Is
a
really
tiny,
tiny
change,
but
it
helps
a
little
bit
so
anyways.
That
was
one
small
update
there.
B
A
As
the
field-
and
we
should
be
using
gateway
class
name
that
matches
ingress
class,
name
storage,
class
name,
what's
used
elsewhere,
we
just
didn't
do
it
correctly
or
I'm
guessing.
It
was
probably
me
to
be
honest.
I
I
can't
remember,
but
I
created
pr
to
update
this,
to
match
everything
that
is
already
in
existence
in
kubernetes.
A
This
one,
I
think,
is,
is
also
a
really
easy
one
to
pick
up.
I
I
have
not
picked
it
up.
I've
not
created
an
issue,
but
on
the
listener
port
we
have
some
coup
builder
validation
that
has
a
min
max
and
then
exclusive
maximum
exclusive
minimum,
and
it's
kind
of
confusing.
A
Can
we
at
least
comment
what
the
actual
interpreted
range
from
this
validation
is
in
in
a
single
comment,
and
so,
if
anyone
wants
to
go
through
and
just
add
a
comment
here
explaining
what
these
bits
of
validation
actually
translate
to
in
terms
of
a
real
range,
I
think
that
would
be
helpful
more
of
a
abstract
thing
that
I
don't
have
a
good
answer
for
was
if
we
wanted
to
have
to
to
have
not
just
a
port
number,
but
a
port
name
for
srv
records.
A
A
So
in
yeah,
so
in
kubernetes
dns,
the
yeah.
I
had
to
look
this
up
as
well.
In
kubernetes
dns,
we
add
an
entry
to
dns
that
is
prefixed
with
the
port
name,
so
that
I
think
we'll
target
that
specific,
for
I
actually
don't
know.
E
B
A
E
A
A
Like
so
yeah
we
have
ip
and
we
have
named
address
and
named
address.
As
I
understand
it
is
interpreted
as
a
named
ip
address,
so
like
a
static
type
key,
but
it
is
not
actually
cname
or
dns.
Despite
the
what
it
might
sound
like.
A
Okay,
so
we're
getting
down
to
the
end
here
I
I
know
really
early
on
in
this
api
design,
we
had
considered
nested
routes.
The
idea
that
a
route
can
then
target
other
routes
which
can
then
target
other
routes.
I
I
think
we
still
have
room
for
that,
but
it
would
be
relatively
complicated
and
I
think
it's
fine
to
leave
for
post
v1
alpha
one,
but
it's
it's
worth
at
least
thinking
about
again
and
thinking
about
how
that
could
potentially
fit
in
in
the
future,
because
it
is
a
cool
idea,
at
least.
A
Tim
was
wondering
if
we
could
get
rid
of
the
regex
path
match
and
the
idea
was
you
know.
Any
implementation
that
can
handle
regex
would
probably
already
have
a
way
of
accomplishing
that
with
some
kind
of
custom,
prefix
or
format
or
whatever,
to
indicate
that
this
is
a
regex,
so
you
might
be
able
to
accomplish
that
just
with
an
implementation,
specific
approach.
A
I
I
can't
remember
what
our
reasoning
was
here.
I
I
maybe
it
was
just
ease
of
use
or
harry.
Do
you
remember.
E
Yeah,
so
I
think
the
the
purpose
of
having
like
specifically
regular
expression,
is
it's
in
an
interesting
space
where
we
can't
put
it
in
the
extended
space,
because
you
have
like
posix
and
pcre
largely
popular.
I
think
this
might
be
a
couple
of
more
engines
but
like
if
you
have
implementations
that
have
you
know
that
follow
one
of
those
engines,
then
you
could
still
have
some
amount
of
you
know
portability
right
so
having
that
regular
expression
type
is
sort
of
for
doc.
E
F
A
Yeah
and
that's
that's
what
it
is
right
now
and
I
I
know
I
like
I
tim-
was
not
sold
on
removing
it.
He
just
wanted
to
make
sure
we
had
clear
reasoning
for
having
it
and-
and
I
I
think
I
think,
the
the
balance
of
just
clearly
defining
that
each
implementation
may
use
a
different
flavor
of
regex,
and
so
this
isn't
fully
portable.
A
Okay,
cool
yeah,
the
tim
had
had
a
question
about
our
domain
match
type
and
and
just
how
loose
it
was
like.
Can
we
match
just
a
comm?
Is
that
valid
under
that
domain
match
type?
And
if
not,
we
may
need
some
clear
documentation
around
what
this
can
and
cannot
be
used
for.
A
A
When
you're
doing
any
kind
of
match
type
or
any
kind
of
type
like
this
at
all,
it
is
preferable
to
have
the
most
specific
first.
So
his
suggestion
was
to
have
exact
first
and
then
gradually
less
specific
types.
After
that
and
another
related
and
very
easy
addition
for
a
hostname
match,
it
only
makes
sense
to
validate
a
max
length
of
253,
so
yeah.
A
And
then
for
headers
he
had
some
really
good
questions
around
the
case
sensitivity.
A
So
you
have
a
you
know,
an
all
uppercase
version
and
an
all
lowercase
version,
and
they
both
match
different
values,
but
our
keys
are
meant
to
be
case,
insensitive.
That
is
currently
not
defined
anywhere,
and
it
would
be
good
to
define
or
maybe
we
need
to.
A
F
A
You
know
it
would
do
nothing
if
the
key
collision
is
not
actually
a
collision
like
it.
Well,
I
think
yeah.
A
F
A
E
F
A
Yeah
well,
it's
especially
confusing
because
you
know
this
is
going
to
get
parsed
into
a
map
and
maps
do
not
have
consistent
ordering.
Obviously,
and
so
you
can't
you
can't
you
know
like
when
you're
reading
a
file
when
you're
parsing
yaml,
you
can
base
this
on
order,
whereas
when
you're
iterating
through
a
map,
it's
probably
less.
A
A
One:
okay:
we
need
a
better
documentation
around
what
happens
when
match
doesn't
exist.
This
feels
reasonably
straightforward.
We
just
have
not
defined
when
there
is
no
default
match.
What
a
controller
should
do.
A
Then
the
you
know
one
more
thing:
I
know
we're
taking
a
lot
of
time
here.
Do
we
want
header
matching
to
be
in
a
list?
I
know
we've
already.
This
has
already
come
up.
I
think
he
may
have
suggested
it.
I
think
I
I
think
a
couple
other
people
have
suggested
this
as
well.
A
E
A
E
A
For
filters,
I
think
he
he
would
you
know
it
wasn't
entirely
clear
to
what
type
was
for
when
extension
ref
is
used.
Does
it
refer
to
just
is
the
type
just
extension,
or
is
it
referring
to
the
name
of
the
crd
that
is
being
referenced
or
is
it
you
know
we
could?
We
could
have
some
better
documentation
on
how
type
should
be
interpreted
in
this
use
case
I'll,
take.
A
Thank
you
and
the
other
one.
Another
conversation
here
was
around
ordering
the
idea
that
there
are
going
to
be
some
filters
that
need
to
be.
A
You
know,
executed
in
a
very
specific
order
by
some
implementations,
so
you
know
basically
making
it
very
clear
that,
and
I
think
we
already
do
a
reasonably
good
job
at
indicating
that
the
order
that
is
specified
in
for
filters
is
not
necessarily
the
order
that
implementations
will
choose,
but
maybe
an
example
of
what
that
might
look
like
or
or
just
a
little
bit
more
depth
into.
How
that
how
that
variation
could
be
introduced
would
be
helpful.
A
And
then
the
last
one
was
tim
mentioned
that
you
know,
I
think,
forward
to
filters
for
tcp
route,
just
kind
of
happened
accidentally
and
they
don't
necessarily
make
sense.
It's
because
the
idea
of
you
know
forward
two
is
a
type
that's
shared
by
tcp
route
and
http
route
and
separate
foot
filters
in
tcp
route
in
the
forward.
Two
really
just
didn't
seem
to
make
a
whole
lot
of
sense,
so
he
thought
well
why?
Why
don't?
We
just
have
different
forward
two
types,
four
different
routes.
A
I
I
think
that
makes
sense.
I
yeah
and
I
and
I
I
agree
that
filters.
I
I
can't
think
of
a
great
use
case
for
filters
inside
the
tcp
route
forward
to
specifically.
E
Yeah,
I
I
think,
generally
more
generally,
we
should.
We
should
only
add
filters
where
we
know
or
exp.
We
have
a
good
experience
of
how
they
will
be
used,
or
you
know
we
have.
D
E
A
Okay,
great
anyone
want
to
volunteer
to
to
follow
up
with
this
one.
A
Okay,
I'll
create
a
follow-up
issue
then,
and
let
whoever
wants
to
take
this
one
on
to
take
it
on.
A
Okay,
so
that
that
was
a
lot
of
feedback.
If
you
want
to
review
any
of
it
on
your
own
feel
free
this
doc
should
be
accessible
to
anyone.
I
not
all
of
these
are
going
to
have
a
follow-up
issue.
A
Just
I
know
we.
We
only
have
a
few
minutes
left.
I
wanted
to
highlight
one
pr
rather
selfishly,
and
this
is
one
that
we
we
I've
had
around
for
a
little
bit,
but
it's
become
a
lot
simpler
now
I
and
it
fixes
a
rather.
I
actually
haven't
updated
the
the
description
to
indicate
this,
but,
as
I
was
building
this
yesterday,
I
ran
into
a
rather
significant
bug
in
our
make
file
setup
and
at
some
point,
unfortunately,
we
removed
code
generation.
A
So
if
you
happen
to
remove
a
field
like
or
rename
a
field,
this
renames
a
field,
things
are
going
to
break
or
well
verification
is
going
to
fail
because
cogen
never
updated,
and
so
I
ran
into
that-
and
I
couldn't
understand
why
make
generate,
wasn't
making
a
difference
and
it
turns
out
that
we
removed
just
a
little
bit
too
much
here
so
anyways
this.
This
fixes
it.
I
have
a
follow-up
issue
that
I
created.
A
Oh
yeah,
I
have
an
issue
here,
so
we
can
fix
this
in
an
isolated
pr
and
that's
completely
fine.
For
me,
I
just
I
needed
to
fix
it
in
in
my
own
pr
just
because
and
this
pr
felt
really
reasonably
close
and
I
I
think,
there's
close
to
consensus
on
this
one.
So
if
anyone
wants
to
take
a
look
at
this,
if
there's
issues
we
can,
I
don't
mind
creating
a
separate
pr.
I
just
I
needed
to
fix
it
here.
Yeah.
A
A
Yeah,
that's
fine
and-
and
I
my
my
stretch
goal
here-
was
this
issue
here,
which
we
have
to
make
files
and
they're
they're
fine.
They
it's.
You
know
legacy
from
coop
builder
generation,
but
we
have
since
modified
our
make
files,
and
it's
not
entirely
clear
why
some
things
are
in
one
make
file
versus
the
other
make
file,
and
I
think
it's
time
that
we
just
merged
them
all
back
into
a
single
make
file.
A
A
Cool
yeah
and
then
I
you
know
we
only
have
a
just
a
few
minutes
left.
Oh,
it
looks
like
jeremy,
you
just
updated
your
udp
route.
Pr,
it
looks
like
yeah,
that's
something
I
need
to
rebase.
That's
amazing!
Thank
you.
Yes,
heads
up
for
everyone.
Re
rebasing
is
going
to
be
painful,
probably
jeremy,
how
painful
was
it
to
rebase?
After
all,
the
proto.
C
Stuff
had
been
removed,
substantially
less
painful,
of
course,.
B
C
A
Yeah
yeah,
okay!
Well,
that's
good
to
hear
yeah.
I
think
it
was
just
yesterday
that
the
pr
removing
all
our
proto-related
stuff
merged-
and
so
that
means
everyone's
going
to
have
to
rebase
once
but
after
that
I
think
rebases
are
going
to
become
less
common
and
definitely
less
painful.
A
So
something
to
be
excited
about
on
that
front.
I
know
this
already
has
approval.
I
think
it
had
an
lgtm
even
before
I'll
I'll,
take
a
look
right
after
this,
and
hopefully
we
can
get
it
in
thanks
thanks
for
another
rebates,
I
know
you've
rebased
a
few
times,
no
problem
cool
yeah.
I
I
don't.
I
don't
think,
there's
enough
time
to
really
get
into
any
one
issue
here,
so
I
am
leaning
towards
just
ending
this
just
a
couple
minutes
early.
E
E
F
F
F
And
it
feels
like
we
can
just
lttm,
you
know
after
the
discussion,
but
it's
true,
and
that
makes
it
easier.
Sometimes
I'm
looking
at
the
conversation-
and
it
looks
like
this
whole
conversation,
but
I
didn't
want
to
just
approve
it
but
like
in
the
lgbt,
I'm
going
to
kind
of
watch.
It.
A
Boy
all
right:
well,
thanks
everyone
yeah,
that's
a
a
good
question.
We
we
have
had
a
ton
of
prs,
come
in,
I'm
I'm
thrilled
with
that
and
excited
about
the
progress
we're
making
and
anyone
who's
interested
in
contributing,
especially
new
contributors.
Don't
hesitate
to
reach
out
on
slack
for
any
help.
I
know
our
dev
documentation
is
not
always
the
best.
E
A
Anyways,
but
thanks
so
much
for
everyone's
time-
and
I
hope
you
have
a
great
rest
of
your
week
and
or
weekend
talk
to
you
next
week,
thanks
youtube.