►
From YouTube: Service APIs Meeting (APAC Friendly Time) 20200507
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
A
D
B
Ip
address,
which
can
represent
either
any
ipv4
or
ipv6
address,
and
we
have
a
name
address
type
here.
I
just
gave
a
one
use
case
of
name
address,
so
I
wonder
how
we
want
to
represent
like
a
do
stack
person,
and
the
second
thing
is
whether
name
address
is
a
common
enough
feature
that
we
should
add
it
here.
C
B
A
A
A
C
C
E
C
C
Common
enough
use
case
that
people
don't
want
to
delegate
on
the
same
host
name,
but
we
can
open
it
up
and
see
how
people
want
this.
The
alternative
is
to
well
couple
alternatives.
One
is
to
try
to
define
some
loser,
meaning
which
may
we'll
make
validation
hard,
or
we
just
say
this
is
up
to
the
implementation,
to
kind
of
handle
conflicts.
I.
C
It's
let's
go
to
the
first
one,
so
the
first
one
is
that
is
it
the
case
that
people
will
want
to
delegate
to
sort
of
like
split
HTTP
routes
based
on
the
same
host,
name
or
multiple
routes,
because
in
that
case,
then
sort
of
validating
out
the
conflicts
doesn't
make
sense.
The
issue
you
have
there
is
whether
or
not
to
how
to
resolve
sort
of
duplicate,
halves
and
I.
C
B
C
C
If
you've
locked
this
one
out,
then
you
would
end
up
having
only
to
support
the
multiple
virtual
hosts
model
rather
than
the
more
inclusive
model,
but
I
think.
If
we
go
into
the
more
inclusive
model,
then
it's
we
probably
can't
say
much
about
how
conflicts
will
be
resolved
if
there's
a
conflict
other
than
the
fact
that
if
there's
an
implementable
conflict
in
may
not
you
can
get
some
status
that
if
there's
a
calm,
but
it
can't
work.
B
C
The
consequences
of
allowing
versus
disallowing
and
then
how
we
could
sort
of
really
clearly
specify
what
a
conflict
is,
so
even
at
the
very
outside
it's
like
how
to
even
detect
it.
If
you
have
wildcards
some
forms
of
well
cards
is
trackable,
but
if
you
get
any
wildcards
beyond
a
certain
like
sort
of
Express
ability,
then
it
just
becomes
intractable
anyways
like
the
whole
point.
F
I
think
we've
mostly
been
focusing
on
determining
when
you
have
a
conflict
and
it's
important
to
also
figure
out
the
semantics
for
what
happens
when
you
have
a
conflict
like
you,
don't
want
someone
to
be
able
to
create
an
HTTP
route
that
invalidates
an
existing
HT
to
be
router
breaks,
someone
else,
so
you
need
some
kind
of
conflict
resolution
as
well.
That's
an
important
piece,
yeah.
C
A
C
Know
yeah
that's
kind
of
what
I'm
thinking,
because
unless
you
restrict
the
kind
of
host
names
you
can
express
extremely
tightly.
It's
usually
you
just
add
a
little
like
one
or
two
things,
and
then
it
just
becomes
quite
hard
to
figure
out.
If
there's
a
conflicting
thing
or
not
so
the
one
that
is
tractable
is
I,
think
the
one
that
goes
with
the
TLS
and
which
is
you
just
have
one
wildcard,
and
it's
only
for
a
single
domain
label
and
I.
C
D
A
D
C
Also
goes
I
think
there's
another
issue
about
when
let's
say
someone
upload
some
config
and
it
becomes
a
conflict
like
what
happened.
It
was
a
discussion
about
that
as
well.
So
probably
this
whole
thing:
if
there's
no
uniqueness
constraints,
then
as
a
bad
aspect
of
it
just
link
all
those
things
together.
D
A
Sounds
good
I
guess
we
should
keep
on
moving
spent
and
I.
Don't
have
a
lot
of
time
here.
So
this
last
one
remover
clarified
the
behavior
of
the
default
field
and
they
should
be
routes
back.
B
It's
default
for
I
mean
what's
the
meaning
of
default,
is
default
for
no
host
match
or
default
days
for
any
non
match,
and
also
one
a
gateway
has
multiple
HTTP
routes
with
multiple
defaults.
How
do
we
handle
such
a
case
or
to
address
the
front
to
simply
remove
default
answer
like
for,
for
when
there's
no
and.
A
C
After
after
yeah,
if
you're
going
to
look
into
sort
of
uniqueness
constraint,
probably
like
everything
falls
out
from
some
decisions
at
the
top,
so
we
could
probably
link
all
these
together
and
it
sounds
like
mostly
unique
extrange
might
be
hard
to
satisfy
so
based
on
that,
then
sort
of
this
would
be
tied
to
that.
So
if
we
link
those
two
issues
together
and
then
in
the
follow-on
kind
of
describe
sort
of
the
consequences,
maybe
all
of
these
can
kind
of
just
get
solved
all
at
once.
A
C
G
G
And
just
the
other
day,
I
started
to
spend
some
time
on
this,
and
I
felt,
like
I,
ran
into
a
blocker
in
the
sense
that,
if
we're
saying
that
for
TLS
connections,
the
associated
route
type
or
you
know,
TLS
connections
would
be
associated
to
a
TCP
route
right.
We're
never
going
to
have
a
TLS
connection
that,
let's
say,
gets
terminated
by
the
Gateway,
and
then
we
do
something
with
an
HTTP
road
is
the
way
that
I
frame,
that
is
my
understanding,
correct
or
am
I
wrong.
There
you're.
G
D
C
That
was
the
did.
We
did
no
one
make
that
change.
I,
think
we
we
talked
about
in
terms
of
routing
there
would
be
or
TLS
only
like
plain
old
TLS
and
you
don't
care
about
the
bytes
on
the
stream.
But
you
do
care
about
routing
on
the
S&I
basis
that
in
make
sense
to
have
a
route
object
that
matches
those
SMI
hosts.
G
G
C
D
That's
about
all
about
TCP
and
TLS
and
SNI
based
routing,
and
what
do
I
think
damian
is
talking
about.
Http
has
been
chopped
so
here.
If
you
look
at
the
top,
we
have
TCP
base
traveling
with
TLS
SMI
based
routing
with
pls
termination
and
gave
on
TLS
sni
base
jumping
without
tcp
term.
You
should
be
just
essentially
SN
I'm,
not
pleased
routers,
and
what
I
think
Damien
is
saying
is
incorrect,
mean
grounding
is
an
HTTP
route
directly.
G
G
G
Right
right,
I
mean
it's.
Your
I
sent
I
based
routing
right,
I
mean,
let's
just
call
it
pass
through
till
us
pass
through.
Is
that
that
bottom
bottom
checkbox
right
right,
I,
guess
I'm
looking
more
at
when
we
have
to
terminate
the
TLS
connection
at
the
gateway
right
and
then
we're
gonna
forward
it
to
some
back-end
via
I
would
think
just
TCP
routing.
G
Yes,
and
that
was
the
direction
I
was
going
and
so
I
said.
Okay,
this
is
my
understanding
and
then
I
looked
at
TCP
route
and
that's
like
okay,
that's
really
nothing,
but
scaffolding
and
so
I
feel
like
I
feel,
like
you
know,
TLS
has
a
blocker
for
us
to
go
ahead
and
spend
the
time
to
say:
hey,
let's
really
spec
out
what
a
TCP
route
is
in
order
to
go
ahead,
then
plug
in
the
TLS
bits
where
we
need
to.
Are
you
following
me
now?
Does
that
make
sense?
Yeah.
C
Yeah,
so
how
would
you
express
basically
number
two
and
number
three
on
this
story
like?
Would
you
in
TLS,
for
example,
one
of
the
so
one
suggestion
I
don't
know
if
it's
in
here
is
that
for
number
three,
you
would
write
the
Gateway
without
sni
and
then
write
a
SNI
route
on
the
back
end,
because
you're
not
actually
terminating
and
then
for
number
two.
You
would
write
the
TLS
as
the
gateway
and
then
the
routing
would
be
just
a
TCP
route.
G
Yeah,
let
me
do
this.
Let
me
I,
didn't
I,
didn't
look
at
this
issue.
I'm
gonna,
pull
it
up
and
take
a
look
at
it
because,
like
I
said,
I
actually
started
to
kind
of
you
know
put
together
a
PR
to
move
TLS
forward,
and
then
it
got
to
a
point
where
I'm
like
okay
I
need
to
I
need
to
really
understand
what
we're
doing
with
the
TCP
route
object,
because
right
now,
it's
nothing
but
scaffolding.
G
E
E
C
C
G
Just
to
say
really
briefly,
so
what
I'm
gonna
do
my
to
do?
Is
I'm
gonna
spend
some
time
looking
into
this
96,
whatever
cross
references,
there
are
whatever
else
is
in
here
and
then
maybe
just
start
putting
together
like
a
kind
of
a
skeleton
PR
to
just
you
know
and
try
to
put
it
the
other
as
chunks.
I'll,
probably
you
know
work
on
one
little
checkbox
here
at
a
time
so
yeah.
Whoever
else
wants
to
take
part
in
this,
let's
just
make
sure
we're
syncing
up
with
each
other
yeah.
C
C
On
sort
of
like
API
objects
that
might
not
live
in
a
centralized
location.
So
if
you
look
at
the
multi
cluster
surfaces
design,
it
sort
of
has
definitions
in
more
than
one
kubernetes
control
plane
and
then
you're
trying
to
merge
all
those
services
together.
So
that
is
an
interesting
thing
that
came
up
is
like
we
eat
right
now
we
have
a
single
cluster
control,
plane
viewpoint
and
we're
putting
traffic
split
in
a
centralized
place.
C
How
does
that
interact?
If
you
were
defining
services
across
multiple
control
planes
and
wanted
to
shift
traffic?
You
know
potentially
in
multiple
company
locations,
so
I
wanted
to
raise
that
as
potentially
another
angle
to
kind
of
consider
in
all
of
this
I
know,
it's
unfortunate,
like
we
already
talked
about
traffic
split
as
a
sub
for
C
or
D,
and
then
kind
of
moving
it
in
I
also
wanted
to
put
that
data
point
out
there,
and
probably
it's
worth
looking
at
some
aspects
of
the
multi
cluster.
C
Proposal
as
well
just
understand
like
because
a
lot
of
these
sort
of
gateway,
it's
like
Gateway,
may
in
the
fullest
extent
of
time,
like
encompass
not
just
a
single
cluster
but
multiple
clusters,
and
what
that
would
mean
because
it
would
be
a
shame
to
have
to
redesign
another.
Let's
say
like
load
balancing
primitive
to
handle
that
case
or
we
have
to
sort
of
wedge
the
two
together.
So
that's
mostly
like
a
like
a
design
consideration
that
we
should
sort
of
look
into
a
little
bit.
You.
G
G
Yeah
I
mean
I,
don't
know
anything
about
it,
but
I
would
I
mean
I
would
think
that
would
there
be
from
a
multi
closer
standpoint,
a
separate
resource
like
a
multi
cluster
service,
or
something
like
that.
That
would
then
load
share
those
requests
across
different
clusters
and
then
within
the
cluster
news
now
using
the
gateway
class
gateway.
G
E
Yeah,
so
that's
kind
of
exactly
what
we're
in
the
middle
of
trying
to
figure
out
right
now,
it's
basically
how
much
so
we've
got
like
a
draft
multi
cluster
service,
API
and
I.
Don't
wanna
spend
too
much
time
talking
about
that,
but
I'm
actually
blasted
out
to
the
Signet
mailing
list
a
bit
ago,
but
we're
trying
to
figure
out
to
how
much
we
can
replace
of
the
resources
that
we're
creating,
especially
on
the
consumption
side
with
with
gateway.
C
Yeah,
so
that
was
also
kind
of
like
there
is
this
natural
analogy
to
describing
your
like
front-end,
like
the
you
know
where
traffic
is
going
into
with
the
same
issue
and
of
resources,
but
then
in
the
multi
cluster
case,
you
might
end
up
having
sort
of
descriptions
that
are
not
necessarily
centralized
in
all
cases.
So
that's
where
the
it
may
have
an
effect
on
traffic
split.
A
C
Yeah,
it's
an
interesting
use
case
in
that
people
who
have
multiple
clusters
tend
to
want
to
do
rollouts
locally,
yeah
I,
don't
know
it
like
it
may
be
that
it's
actually
the
most
natural
to
put
in
that
centralized
place.
So
that
may
be
something
that
you
know
it
boiled
it
down
and
it
becomes
a
centralized
thing,
but
it
is
in
a
multi
cluster
control
plane
case.
It
is
possible
that
it
is
a
distributed,
configuration
I.
B
A
Yeah,
that's
that's
very
interesting,
yeah
cool
I
mean
and
I
guess.
One
other
note
would
be
if
route
I
mean
it's
all
about
trying
to
define
where
things
would
live
in
a
multi
crystal
world
like
wouldn't
route,
become
per
cluster
instead
of
global,
because
that's
another
way
to
accomplish
this
kind
of
thing,
but
obviously
that
gets
messy
too
yeah
I'll.
B
C
Yeah,
so
that's
I
think
we
should
have
a
conversation
on
so
there's
definitely
lots
of
advantages
to
centralizing
it
and
then
there
are
definitely
interesting
sort
of
like
rollout
related
aspects
to
the
decentralized.
So
you
know
it
might
be
that
you
know
some
aspects
or
centralized
and
some
aspects
are
distributed
and
that's
not
it's
not
like
a
black
and
white
kind
of
separation
like
we
may
find
that,
for
example,
waiting
might
be
distributed,
or
it
is
all
centralized
or
you
know
so.
C
E
A
This
forwarded,
it
seemed
you
know,
I'd
hate,
for
us
to
be
stuck
too
long
on
what
we
do
for
traffic
split.
Well,
we
try
to
figure
out
the
bigger
Multi
cluster
picture,
but
obviously
I
would
rather
not
get
it
completely
wrong
and
be
incompatible
with
the
multi
cluster
scenario.
Is
there
a
way
that
we
can
have
more
of
a
conversation
with
people
that
are
working
towards
multi,
cluster,
I,
guess
and
I?
Don't
know,
yeah.
C
I
think
again,
let's
go
back
to
use
cases
so
there's
the
definite
traffic
split
use
case
is
like
canary
right,
I.
Think
that's
like
the
biggest
one,
the
but
canary
across.
What
is
the
question
like
canary
across
you
know
different,
like
lust
like
attributes
like
location
and
cluster
or
canary
across
like
services.
It
feels
like
those
are
two
axes
that
are
not
entirely
linked
up
together
and
if
we
can
sort
of
sketch
out
what
that
looks
like
I
think
we
can
sort
of
understand
it
a
little
bit
more
or
or
yeah.
C
C
C
G
C
A
E
So
I
think
we
had
some.
You
know
on
the
multiplexer
service
side.
There's
some
open
questions
about
like
how
much
is
exposed
through,
like
there's
a
multi
plus
to
service
a
single
thing
or
is
a
multi
cluster
service,
something
that
like
has
information
about
where
it
came
from
and
so
yeah
I
think
there's
a
few
different
ways
to
look
at
it.
You
know
you
could
you
could
have
waiting
be
part
of
part
of
the
I
guess
the
the
exported
services
that
become
that
multi
cluster
service.
E
You
could
have
it
potentially
be
exposed,
like
you
know,
at
the
gateway
or
a
level,
and
it
references
parts
of
that
multi
cluster
service
I
think
that's
kind
of
what
we
need
to
figure
out
where
that
should
go,
I
mean
if
it
was
an
opaque
saying
it
would
be
really
hard
to
do
any
kind
of
traffic
splitting.
That's
for
sure,
yeah.