►
From YouTube: Service APIs Meeting (APAC Friendly Time) 20200730
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
we're
recording
this
is
service
api's
meeting
for
july
30th,
notably
our
last
meeting
in
july,
and
I
know
we-
we
are
still
hopeful
at
least
I'm
still
hopeful
that
we'll
get
an
elf
out
sometime
in
august.
A
The
good
news
is
in
the
past
week
we
have
moved
two
of
the
items
in
progress
to
completed
that
was
traffic
splitting
and
tcp
route.
So
thanks
to
everyone
for
contributions
on
that
front,
I
think
we're
also
making
good
progress
towards
advanced
routing
and
tls
config
and
hopefully
even
conflict
handling,
semantics.
A
And
I'm
not
I'm
not
as
aware
of
what's
happening
on
service
level,
config
or
clean
up
for
status
and
conditions.
I
know
I
know
that's
when
I
just
kind
of
threw
on
damian
because
he
happened
to
be.
He
happened
to
have
an
issue
open
for
it
or
a
pr
open
for
it,
but
yeah.
I
think
I
think
we're
making
good
progress
here
and
still
hopeful
that
we
can
get
an
elf
out
soon.
A
But
on
that
note
something
that
I
brought
up
briefly
in
office
hours
yesterday
is
that
it
would
be
really
helpful
to
have-
and
I
know
this-
this
feels
like
we're
going
back
in
time
a
little
bit
but
to
have
a
single
doc
as
a
means
of
accepting
api
review
from
both
ourselves
and
anyone
else.
We
can.
A
I
know
I
know
tim
is
interested
in
doing
a
review
and
I
know
it
would
also
be
helpful
for
us
internally
to
do
a
full
review
and
since
we
already
have
everything
checked
into
the
code
base,
it's
harder
to
do
a
review
of
everything
there
so
kind
of
a
review
of
all
our
existing
apis.
A
A
So
yeah,
that's
a
that's
something
I've
assigned
to
myself.
I
don't
think
it'll
take
too
long
to
to
get
a
doc
together,
but
does
it
does
anyone
have
any
any
thoughts
about
that?
Does
it
seem
like
a
reasonable
way
to
do
a
full
api
review?
Is
there
a
better
way
to
have
open
up
this
api
for
review
before
we
hit
alpha.
B
I
don't
know
if
there's
a
better
way,
but
I
think
this
is
a
good
step
and
I
think
that
we'll
get
a
nice
bit
of
polish
out
of
it.
A
Great
appreciate
that
yeah-
that's
that's,
definitely
my
goal,
so
hopefully,
hopefully
we
can
get
some
great
feedback
here.
Next
up,
I
just
added
a
few
pr
issue,
things
for
triage,
one
of
them.
I
created
myself,
and
this
is
actually
a
bit
of
a
follow-up
again
from
some
discussion
around
conflict
resolution
and
discussion
around
gateway
class
and
how
that
interacts
with
gateway.
A
I
started
to
get
scared,
as
I
looked
at
gateway
class
of
the
impact
that
changes
at
that
level
could
have
as
an
example.
If,
if
you
change
something
like
a
gateway
class
like
allowed
route
namespaces
to
be
something
that
was
somehow
invalid
or
selected
less
namespaces,
you
would
invalidate
a
large
number
of
routes
for
all
gateways
that
were
using
that
class.
A
So
you
know
my
my
real
concern
here
is
the
blast.
Radius
of
gateway
class
is
potentially
massive,
instead
of
affecting
say,
a
single
gateway.
You
have
the
potential
to
affect.
You
know
every
gateway
that
happens
to
be
using
that
class
in
your
cluster,
and
I
have
similar
concerns
about
the
parameters
that
they
reference.
So
a
lot
of
a
lot
of
my
thoughts
here,
kind
of
merge,
those
two
together
gateway
class
and
the
parameters
that
either
are
included
in
that
resource
or
referenced
by
it.
So
just
that
I
am
kind
of
referring
to
both
here.
A
A
A
A
It
is
problematic,
because
I
can
imagine
with
this
scenario-
we
would
have
just
huge
numbers
of
gateway
classes
over
time
and
that
could
get
messy.
There
are
certainly
ways
that,
as
an
implementer
as
someone
using
this
api,
you
can
clean
that
up.
You
could
transition
all
your
gateways
to
a
new
gateway
class
and
then
get
rid
of
the
old
one,
but
it's
messy-
and
I
know
most
people
or
many
people
do
not
like
the
idea
of
immutable
resources
in
kubernetes
because
it
seems
to
go
against
the
whole
idea
of
declarative
apis.
A
The
next
idea
I
had
was
why
don't
we
create
treat
gateway,
class
and
params
as
templates,
so
this
is
essentially
saying
okay,
so
when
you
create
a
gateway,
all
everything
associated
with
that
gateway
class
is
now
applying
to
the
gateway
we
make
a
copy
of
it.
We
do
something
like
that.
We
make
a
copy
of
everything
associated
with
the
gateway
class
at
that
point
in
time,
and
then
those
are
now
separate.
So
it's
really
just
a
template.
A
This
is
also
safe,
but
the
potential
downside
here
is
that
multiple
gateways
are
going
to
have
the
same
gateway
class
name,
but
that
gateway
class
could
mean
wildly
different
things
if
the
gateway
class
has
evolved
over
time.
So
at
that
point,
gateway
class
is
not
even
the
right
name
for
this
resource.
A
It's
it's
more
a
gateway,
proto
or
some
other
such
thing,
and
then
another
option
would
be
embed
versions
or
revisions
within
a
gateway
class.
This
one
seemed
just
yeah
really
complicated,
but
the
idea
of
we
gateway
class
and
embed
those
versions
within
a
single
resource,
and
if
you
want
to
make
a
change,
you
create
a
new
version
of
parameters
of
whatever
it
happens,
to
be
inside
this
resource
and
when
referencing
gateway
class.
You
reference
not
just
the
name
but
also
a
version.
A
This
works,
but
it
results
in
what
would
potentially
be
a
very
messy
resource,
and
I
can't
think
of
any
prior
art
here
and
then
my
final
idea
was
well.
We
could
just
say
this
can
break
things,
but
we
can
trust
users
not
to
break
things.
You
know
that
we
don't
love
any
of
the
options
above
we
can't
think
of
anything
better,
and
maybe
the
answer
is
trust
users
not
to
break
things
yeah.
A
That's
that's
a
high
level
overview
of
my
thoughts
on
this,
but
I
am
super
interested
in
any
feedback
or
ideas
around
this
that
anyone
else
might
have,
because
I
know
it's,
I
don't
love
any
of
these
ideas.
A
Yes
and-
and
andrew's
comment
is,
is
a
great
one
and
I'll
cover
that.
Just
briefly,
we
have
talked
to
the
folks
at
storage
at
six
storage
and
they,
as
I
recall
they
pro
they
wish
they
had
done
something
closer
to
templatizing
or
or
something
like
that-
the
kind
of
point
in
time
reference,
but
right
now
it
is
not
well
defined,
as
I
understand
it,
so
it
depends
on
the
implementation
as
far
as
how
this
is
treated
so
yeah,
that's
a
whole
lot
of
background.
D
C
Like
we're
thinking
about
scenarios,
because
it's
like
unknown
unknown
yeah,
it's
hard
to
like
predict
how
to
actually
design
a
solution
around
it,
so
no
this
is,
can
you
know
something
in
my
opinion?
Can
wait?
You
know
even
alpha
2
3,
very
much.
You
know
towards
the
beta
thing
rather
than
right
now,
but
you
know
this
is
very
important
from
you
know:
a
user
experience
perspective
yeah.
E
A
Yeah,
so
you
know
obviously
I'm
thinking
about
it
from
a
perspective
of
google
cloud
where
we
might
have
parameters
or
or
something
that
would
require
us
to
spin
down
and
spin
up
new
infrastructure,
as
as
an
example
right
that
that
is
not
everyone's
use
case.
But
I
imagine
there
are
other
things
that
could
potentially
result
in
breaking
or
disruptive
changes.
E
A
good
point
go
ahead:
yeah,
maybe
some
of
those
things
could
just
go
in
the
gateway.
Maybe
we
can
say
gateway
class.
We
can't
have
fields
that
would
be
destructive
if
mutated,
maybe
that's
an
option.
If
you
know,
if
we
can
figure
out
a
solution
for
allowed
namespaces,
maybe
we
can
generally
say
avoid
putting
fields
in
gateway
class
if
they.
A
Yeah,
I
think
I
think,
that's
good
guidance
as
well.
I
mean
what
what
I
keep
on
running
into,
and
I've
already
somewhat
covered
as
the
allowed
fields
that
we
currently
have
in
gateway
class
that
I
proposed
have
also
gotten
really
annoying
and
really
potentially
destructive.
A
I
do
think
they
provide
value,
but
maybe
the
answer
is
try
to
look
at
at
different
options
like
I've
already
proposed
a
different
option
for
allowed
gateway,
namespaces,
it's
less
less
clear
for
routes,
but
maybe
if
we
just
focus
on
on
that
specific
issue,
maybe
it
is.
It
is
a
rare
issue
beyond
that,
maybe
there
aren't
so
many
breaking
changes
within
gateway
class.
C
Another
question
to
that
is
how
many
changes
are
not
easily
reversible
like
if
you
do
change
something-
and
you
know,
one
thing
would
be
not
like
running
something
like
which
deletes
all
secrets
in
your
cluster
right,
like
that's,
like
a
really
really
big
large
blast
radius
right.
But
in
this
case
it's
like
it
seems.
E
D
C
Yes,
yeah.
Okay,
I
think
there
might
be
situations
where
you
know
that
there
will
be
some.
You
know
not
easily
reversible
changes
like
if
changing
something
in
the
gateway
class
results
in
actually
you
know
not
renewal
of
search
or
maybe
you
know
something
gets
deleted.
Something
right.
I
don't
have
a
good
example
of
like
an
irreversible
change
that
could
happen
or
a
change.
That
requires
a
lot
more
manual
work
later.
B
I
think
there's
kind
of
a
number
of
dimensions
to
this
and
we
can
talk
about
their
parameters
which
are
defined
in
gateway
class
and
we
can
think
about
what
they
mean.
E
B
Think
you're
allowed
random
spaces.
Right
is
the
big
one,
so
we
can
define
behavior
for
that.
If
you
say
this
is
what
we
think,
but
everything
else
is
everything
that's
controller
specific
is
you
know
it's
by
definition
out
of
out
of
scope
and
you
can't
require
params
to
be
immutable.
You
can
just
say
hey
it's
a
good
idea
and
in
the
same
way
you
can't
you
can't
require
controllers
to
make
changes
to.
You
know,
implement
changes
in
an
operationally
safe
manner.
A
A
We
should,
though,
if
we
were
focused
on
anything,
it
would
be
finding
a
better
solution
for
allow
root
namespaces,
because
those
are
around
namespaces,
because
those
are
very
very
tied
to
this
api,
at
least
providing
guidance
for
what
should
be
done
there
there
if
it
changes
on
the
fly
but
yeah
that
that's
that's
great
feedback.
A
Okay,
the
next
one
that
is
new,
is
a
simple
pr
from
james.
I
I'd
like
to
I
like
the
logic
here.
James
is
there
much
to
say
about
this?
One.
B
Not
too
much
I,
I
was
actually
reviewing
one
of
harry's
pr's
and
I
saw
that
we
have
in
the
mat
in
the
http
rap
match.
We
have
header
match
type,
but
it's
just
path
type.
So
both
of
these
fields
are
telling
us
how
to
do
the
match,
so
it
seemed
reasonable
to
follow
the
same
naming
convention.
B
B
So
we
have
a
string
cons,
a
string,
alias
type
alias
for
address
type,
but
we've
got
named
address
type
and
this
address
type
from
that
adjust
type,
and
I
think
it
would
be
more
canonically
go
if
we
just
called
if
we
dropped
the
type
string
from
the
names
of
the
constants.
So
instead
of
having
pathmatch
type
exact,
we
just
go
pathmatch
exact,
for
example.
B
A
Yeah
yeah,
that
makes
a
lot
of
sense
for
things
like
path
match
or
header
match
that
are
very
unlikely.
To
you
know,
path
match
is
not
a
term
that
we're
going
to
use
for
other
things
where
it
may
get
a
little
messier
is
something
like
address
type
where
I
don't
think
that's
going
to
be
a
big
deal,
but.
D
B
Yeah
we
so
we
have
so
that
this
shows
up
in
a
few
of
the
different
constant
names.
So
we
have
you
know:
tls
protocol
type,
tcp
protocol.
D
B
B
I
think
I'm
responsible
for
adding
most
of
these
so
clearly
I've
had
different
ideas
about
about
this
at
different
times.
In
my
life
right.
B
Makes
sense
I
did
do
a
quick
whip
through
the
kubernetes
code
base
and
in
general,
where
I've
seen
these
kinds
of
constants.
The
type
string
is
omitted
from
the
constant
name.
A
Yeah
yeah,
I
mean
that
makes
sense.
I
I
don't.
I
don't
have
a
a
strong
feeling
either
way,
but
a
more
concise
name
probably
helps
here.
So
so
I'm
fine
with
that.
One
thing
I'll
say
just
on
this
pr
in
general,
this
matches
header
match
type,
the
the
naming
that
we
already
have
for
header
match
type
well,
but
it
does
mean
we're
starting
to
deviate
even
more
from
the
ingress
b1
api,
where
we
do
have
a
concept
of
just
path:
type,
not
past
match
type.
A
I
don't
think
that's
a
significant
deal
and
we
are
already
starting
to
support
different.
You
know
I
mean
this
api
is,
is
already
significantly
different
than
the
ingress
api
by
design.
So
I
don't.
I
don't
think
that
needs
to
be
a
blocker
here.
It's
just
it
just
a
note
that
it
does
differ
from
the
ingress
api,
but
I
I
think
this
is
probably
clear
and
it
does
match
what
we
have
for
header
already.
So.
C
At
this
pr,
this
seems
to
be
good
james,
so
thanks
for
making
it.
E
A
C
A
A
A
A
Yeah
and
and
yeah
I'll
say
again:
if
anyone
feels
motivated
some
kind
of
ci
job
that
just
tries
to
apply
these,
create
these
crds
in
a
cluster
and
then
apply
our
examples
would
go
a
long
way.
Defining
these
little
inconsistencies.
A
A
Before
I
get
into
just
a
few
follow-ups
around
conflict
resolution,
were
there
any
pr's
or
issues
or
anything
that
we
should
discuss
as
part
of
this
meeting
today,.
F
Yeah,
actually,
I
think
so.
I've
got
two
open
right
now
for
s
and
I
and
udp,
and
maybe
we
should
start
with
the
s
one,
but
on
each
james
and
harry.
Both
have
good
comments
that
are
probably
worth.
F
B
D
B
I
don't
know
whether
you
it
depending
on
how
people
end
up
using
this,
then
we're
forcing
people
to
do
to
go
through
the
hostname
match,
which
is
really
only
a
tls
thing
and
maybe,
if
you're
not
using
tls,
you
still
have,
but
even
if
you're,
not
using
tls,
you
still
have
to
pay
the
cost
of
thinking
about
going
through
those
those
structures.
B
An
advantage.
Is
you
get
this
extension
ref?
I
did
ask
someone
internally
who's
implementing
this
for
l4
about
whether
this
extension
ref
would
be
useful.
I
didn't
get
a
strong,
yes
or
no,
it
seems
like
a
maybe
you
could
use
it.
F
F
A
So
we
we
discussed
this
briefly
in
office
hours
yesterday
and
unfortunately
it
looks
like
bowie's
not
here,
but
he
one
of
his
bits
of
feedback
was
that
maybe,
instead
of
adding
s
and
I
support
tcp
route,
we
could
you
look
into
an
sni
route.
E
B
F
A
I
I
feel
like
a
lot
of
the
recent
decisions
here.
Oh
looks
like
always
here
now.
A
lot
of
the
recent
decisions
here
have
have
had
a
very
similar
feeling
of.
There
is
technical
merit
with
either
of
these,
and
it
is
hard
to
find
a
compelling
reason
to
choose
one
over
the
other
but
bowie
since
it
looks
like
you're
on
a
call
now.
Did
you
wanna
just
mention
your
thoughts
about
maybe
using
sni
route
here
instead
of
tcp
rap.
C
I
have
one
question,
though
we
have
been
adding
extension
revs
quite
a
bit
in
some
places.
Like
you
know,
we
don't
even
know
if
we
need
to
add
extension
ref,
but
we
are
adding
because
the
previous
resource
had
it
right,
and
so
you
know,
because
http
route
had
it
we
added
some
place
and
which.
C
The
consistency
is
good.
I
totally
appreciate
that
in
an
api,
but
I
do
have
one
concern
and
I've
been
thinking
about
is
adding.
You
know
extension
points
anywhere
in
apis
without
having
a
good
understanding
of
how
they
can
be
used
and.
C
Can
be
exploited
seems
a
little
risky
right
like
having
extension
point
but
making
sure
you
know.
This
is
how
we
intend
you
to
you
know
we
we
want
you
to
use
it
right
in
these
certain
ways
and
we
probably
won't
be
able
to
come
up
with
an
exhaustive
list
but
sort
of
giving
an
extension
point
of
direction
right
rather
than
people
assuming
you
know.
D
D
E
C
A
I
think
that's
a
good
thing
to
even
include
you
know,
I
think,
that's
probably
forward
looking
to
to
a
v1
alpha
1
release
of
this
api.
It
you
know,
even
even
though
I
think
we're
saying
b1
alpha
1
we're
not
offering
backwards
compatibility
things
can
change.
Things
can
break,
it's
still
always
going
to
be
easier
to
add
things
to
an
api
than
to
remove
them.
A
Even
if
we're
promising
breaking
changes
or
suggesting
breaking
changes
will
happen,
it
is
definitely
easier
to
add
things
as
they're
requested
than
to
remove
them,
even
though
we
don't
know
for
sure
that
you
know
they're
they're
completely
unused,
so
so
I
get
that
and-
and
I
think
even
that
this
this
concept
makes
may
may
go
beyond
just
extension.
Ref,
though
extension
ref
is
probably
the
most
obvious
use
of
this
of
things
that
we've
added
to
the
api
that
we're
not
entirely
sure
how
they'll
be
used.
A
You
know
we,
we
have
maybe
very
rough
ideas
for
how
you
might
add
extensions
at
this
point.
Yeah,
that's
a
that's
a
good
question.
A
At
the
very
least
I'll
add
it
to
my
doc
or
to
our
doc
for
v1
alpha
1
release,
because
I
think
that's
something
we
need
to
answer
as
part
of
api
review.
Are
there
things
in
the
api
that
we
have
right
now
that
we
could
live
without
that?
Does
it
is
that
a
is
that
an
appropriate
interpretation
of
what
you
were
saying,
harry.
C
E
A
So
just
some
examples
of
how
it
could
be
used.
E
A
And
bowie
it
looks
like
your
audio
is
working
here
just
well
while
you're
here
did
you
want
to
comment.
I
know
you
had
thoughts
on
potentially
an
sni
route
here.
Instead
of
adding
s
to
tcp
row.
D
Yeah,
it's
it's
either.
I
also
made
a
note
on
the
chat
in
case.
My
audio
is
completely
messed
up
is
that
we
are
starting
in
the
process
of
just
reaching
out
to
some
of
the
main
api
reviewers
just
to
kind
of
book
time
on
their
schedule,
for
when
we
get
closer.
This
is
the
good
note.
The
the
sni
route
I
think
like
since
we
call
it
tcp
route
like
tcp,
is
a.
D
A
It
sounds
like
bowie
what
you
you
would
be:
okay,
with
a
single
route
accomplishing
both
of
these
things,
just
potentially
with
different
naming
or
would
you
rather
have
two
different
route
objects
here.
D
Yeah
yeah,
like
one
thing,
is
like:
maybe
we
don't
focus
too
much
on
the
name
right
now
and
just
kind
of
put
the
things
that
we
think
will
go
in
there
and
then
evaluate
it.
I
think
in
the
final
form
we
shouldn't
call
it.
We
shouldn't
call
things
with
s
and
I
and
t
on
this
concepts
tcp
route,
because
the
name
feels
not.
A
Yeah,
that's
helpful,
so
if
it
were
up
to
you,
would
you
rather
have
this?
Have
s
and
I
hold
off
on
sni
until
we
created
a
new
route
or
add
it
here
and
think
about
a
rename
or
splitting
it
out
later.
D
D
B
Sorry,
if
we
have
a
separate
cid
resource
that
would
do
sni,
are
there
any
practical
use
cases
for
that
supporting
the
alpn
protocols
as
well,
because
I
know
I
mean
I
know
you
can
split
traffic
on
the
lpn
protocol
technically,
but
is
there
any
real
world
use
case
for.
E
D
E
B
Also
so
tls
lets
you
specify
the
protocol,
so
you
could
run
http
and
I
don't
know
ftp
or
http
and
some
game
server
over
tls
on
the
same
port
and
select
the
back
end
using
the
protocol.
You
would
say:
oh
I'm
asking
for
h2
or
I'm
asking
for
my
game
protocol
and
you
you
could
route
that
to
different
services.
E
Yeah,
that's
what
I
mean.
I
mean
you
have
a
server
and
you
use
alpn
to
connect.
Well,
if
you're
doing
a
grpc,
client
use
alpn
to
say
I
want
http
2.
and
if
you're,
just
a
regular,
rust
client,
you
want
http
1,
you
you
well,
I
guess
you
omit
the
alpn
and
you
just
get.
You
just
send
a
regular
http.
One
request.
B
A
Yeah,
we
haven't
talked
a
whole
lot
about
alpn,
but
that
that's
also
I
thanks
for
for
bringing
that
up,
and
I
know
we
don't
have
really
any
time,
but
I
at
least
wanted
to
mention
that
this
is
something
that
came
up
in
conflict
resolution
of
this
question
I
added
here.
Do
we
need
to
support
multiple
pro
like
further
down
there
was
this
idea
of
protocol
was
going
to
be
unique
for
host
and
port.
A
But
I'd
say
you
know
if,
if
we
want
to
use
this
api
to
communicate
the
protocols
supported
or
to
suggest
that
this
is
listing
on
and
protocols,
then
I
don't
know
that
we
can
require
that
host
port
and
protocol
combinations
are
necessarily
unique.
You
could
have
multiple
protocols
on
the
same
host
port
combo.
B
B
A
All
right,
well,
is
there
anything
else
we
should
discuss
today?
I
think
we
are
at
time,
if
not.
A
All
right
well,
thank
you,
everyone
for
the
for
the
help
and
discussion
around
this.
This
has
been
great
and
we'll
talk
to
you
all
next.