►
From YouTube: Service APIs Meeting (EMEA Friendly Time) 20200430
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
B
So
part
of
the
I
just
want
to
lay
out
the
sort
of
initial
ground,
and
then
probably
this
is
the
first
time
we've
really
talked
about
it,
some
of
the
threads
on
the
issues
it
I,
don't
expect
they're
like
resulting
today,
but
one
of
the
hopes
for
sort
of
the
new
structuring
of
gateway
is
that
we
could
in
someone
taking
note
I
can
add
them
up
here.
A
B
B
What
is
the
other
point?
No
import,
so
basically
the
different
flavors
of
service
exposure,
the
VIP,
are
not
there
other
kind
of
if
you
use
the
API
in
some
degree,
you'll
find
that
it's
very
strange
that
there
is
this
hierarchy
of.
If
you
have
a
it
goes
like
no
cluster
IP
cluster
IP
known
for
load
balancer,
and
if
you
take
a
look,
if
you
make
it
a
load,
balancer
actually
exposes
all
those
other
ones
as
well,
and
then,
of
course,
the
service
has
all
been
sync
mixed
into
it.
B
So
one
of
the
hopes
was
that
if
we
could
use
gateway
and
if
it
could
represent
l4
is
to
sort
of
be
able
to
be
couple
a
lot
of
that
stuff.
And
you
know
one
is
clearly
if
we
can
cover
l4,
it's
a
natural
place
for
talking
about
constructing
load
balancers
for
exposing
Oh
for
and
if
you
look
at
the
original
ingress
API,
it
actually
was
designed
someone
in
a
way
to
have
l4
as
part
of
it.
B
Now,
in
terms
of
the
sketch
there
were
a
couple
of
proposals,
there's
one
that's
the
words
like
penciled
in
in
the
repo
that's
checked
in
in
terms
of
okay,
you
have
gateway
which
is
going
to
talk
about
the
same
stuff
as
HTTP
and
then
for
protocols
that
have
additional
routing
such
as
s
and
I.
We
have
an
appropriate
route.
B
There
were.
There
was
some
discussion
about
how
the
route,
for-
let's
say
it's
just
like
your
TTP,
like
you,
just
expose
your
TCP
anyway.
Think.
Ok,
if
that's
where
you
would
define
that
which
ones
were
bound
and
then
the
statuses
seems
appropriate
that
you
allow
you
to
discover
what
virtuality
potentially
was
placed
on
it.
B
But
the
Ralph
C
me
a
little
bit
vestigial,
because
there
is
no
additional
routing
that
has
already
done
via
the
Gateway,
so
that
was
one
API
quark,
whether
or
not
it
would
just
be
pure
overhead
and
then
the
other
one
was
what
sort
of
additional
requirements
we
would
see
beyond
the
ones
that
we
already
had
to
address
or
have
thought
about
for
HTTP.
And
then,
with
that
kind
of
wide
open
topic,
we
can
open
it
up.
So
a
couple
of
ways
we
can
approach.
B
A
B
Extension,
I
guess
there's
not
much
description
of
it,
so
essentially
the
Gateway
would
either
point
to
so.
We
had
a
couple
of
just
wild
ideas
here.
One
of
them
is
that
question
would
be
what
would
go
into
a
TCP
e.
What
would
go
into
the
route
object
for
Q
or
TCP,
which
seems
like
not
that
much
but
then
again,
you
can
think
about
setting
such
as
session
affinity
or
attributes
of
TCP
that
don't
make
sense
such
a
gateway
level
right
like
attributes
about
the
protocol
itself.
B
So
we
may
want
a
resource
representation
for
those
kind
of
things
and
then
the
other
one.
That's
very
obvious,
is
for
TCP
process
and
I.
What
TLS
that
one
is
very
obvious,
because
there
is
an
additional
level
of
protocol
matching
now,
given
the
sort
of
TCP
specific,
like
let's
say,
session
affinity,
so
that
those
argue
or
having
a
resource
there,
and
then
we
should
be
much
a
very
small
resource
like
sparse
resource,
but
it
might
not
be
useless
like
completely
empty
he.
B
D
A
So
right
now
it
seems
like
the
biggest
gap
is
and
I
think
this
is
what
you're
talking
about
is
is
what
comes
after
gateway
like
we.
We
know
how
an
elf
for
Gateway
could
look
like,
but
we
don't
really
know
what
to
route
it
to
like
what
a
TCP
route
could
look
like
or
what
alternatives
we
could
use
to
link
to
actual
pods
or
endpoints
in
a
cluster
I
understand
correctly.
B
B
D
B
You
create
a
service
and
then
that's
it,
but
in
some
sense
we
are
moving
away
from
that
model.
Anyway,
if
we
wanted
to
be
more
calm
or
decoupled,
like
the
notion
is
that
you
create
a
service
and
that
they're
grouping,
and
then
you
would
have
something
else
that
decorates
that
sort
of
links
of
the
service,
that
is
how
that
service
is
exposed,
and
then
I
was
asking
around
at
the
time
service
was
created.
B
The
support
for
having
like
lots
of
different
objects
linked
to
each
other.
It
wasn't
very
good,
so
that's
why
there
was
a
push
to
kind
of
just
throw
it
into
the
same
resource,
but,
as
you
can
see,
the
current
service
object,
I,
don't
think.
As
a
say,
we
want
to
recommend
people
adding
lots
and
lots
of
stuff
there,
because
it
is
already
kind
of
very
complicated
and
sort
of
has
too
many
responsibilities.
B
D
Case
in
point
on
that
on
the
cluster
IP,
like
it
gets
kind
of
weird
like
what,
if
you
have
multiple
service
ports
right,
you
have
UDP
and
TCP
mixed.
Does
that
mean
that
the
gateway
has
has
a
listener
for
each
service
that
maps
to
a
route
for
that
service
port
like
what
would
that?
How
would
that
deconstruct.
D
Mean,
let's
just
say:
I
have
a
service
with
multiple
service
ports
and
I
want
to
express
the
cluster
IP
with
Gateway
like
if
cluster
P
was
a
gateway
class
I
would
I.
So
if
I
have
multiple
service
ports
and
ice,
so
my
service
is
exposed
to
multiple
ports.
Then
then,
presumably
any
multiple
listeners
on
my
gateway
right,
one
for
each
service
board.
B
Yeah,
so
we
have
a
notion
that
gateway
where
the
fact
that
you
write
is
a
request
of
the
system.
That's
how
it
actually
works
in
ingress.
Is
that
it's
sort
of
like
a
set
of
constraint,
that
of
what
you
care
about,
for
example,
if
you
don't
care
about
specific
IP,
you
can
leave
that
out
in
the
listener
block
and
that
would
the
controller
would
go
and
gonna
give
you
an
address.
That's.
B
B
D
B
A
B
C
There's
been
a
lot
of
like
voice
based
use
cases
with
UDP
and
and
and
how
that
works,
that
you
know
we've
looked
at
that
we're
just
required
more
expressiveness.
So
definitely
a
lot
of
the
kind
of
udp-based
things,
there's
all
kinds
of
quirks
that
need
to
fake
that
it's
been
a
little
weird
to
try
and
think
about
putting
that
on
to
the
service.
There's
just
no
other
place
to
do
it
so
like
with.
A
D
A
D
I
think
like
from
the
multi
culture
service
standpoint,
so
what
we
have
been
kind
of
exploring
is
stretching
the
like
the
service
concept
across
multiple
clusters,
and
it
seems
like
the
right
way
to
do.
That
is
not
to
just
overload
the
service
resource
because,
like
we,
don't
necessarily
want
every
multi
culture
service
to
appear
to
be
a
local
service
and
anything
using
the
service
API.
If
we
just
overloaded
it
would
for
for
imported
services
into
a
cluster
that
were
available
for
expose
from
other
clusters.
D
I,
don't
know
that
you
necessarily
want
to
just
make
them
be
automatically
picked
up
by
anything
that
that
supports
the
service
API,
but
at
the
same
time,
like
obviously
a
lot
of
the
functionality.
You'd
want
to
still
be
there
like,
like
a
cluster
IP,
and
so
the
current
kind
of
approach
we've
been
taking
when,
when
exploring.
This
has
been
like,
basically
create
a
new
resource.
That
looks
a
lot
like
service
and
duplicates
a
lot
of
functionality.
But
most
of
the
functionality
that
actually
needs
to
be
duplicated
is
really
more
in
line
with
a
gateway.
D
So
if
you
could
point
a
gateway
at
a
different
type
of
service,
equivalent
resource
that
that
could
be
awesome
like
if
there
was
a
way
to
basically
associate
like
really
really
what
I
think.
What
we
need
to
do
is
really
just
be
able
to
associate
a
gateway
of
class
cluster
IP
with
an
arbitrary
set
of
endpoints
that
without
having
to
create
a
service.
That
could
be
great.
So
there
was
another
resource
like
a
type
of
route
that
would
allow
that.
D
B
I
think
what
an
interesting
point
is
that
maybe
it's
okay
like
if,
if
our
aim
is
to
replace
some
parts
of
service
than
worrying
about
overlapping
service,
may
not
be
like,
maybe
expected,
because
that
is
kind
of
what
we're
trying
to
do
the
and
that
is
worth
like.
We
should
probably
just
write
that
down
as
it
is
okay
to
overlap
with
service,
knowing
that
we
are
trying
to
overlap
with
service
because
designing
around
the
surfaces
service.
Existing
service
surface
area
is
basically
not
the
end
goal
right.
B
D
Like
I,
think
that
makes
a
lot
of
sense.
There
might
be
a
us
question
like
if
you're
duplicating
fields
is
there
a
way
that
we
can
make
it
infer
from
service
if
they're
not
provided
at
least
to
start,
because,
like
service
hopefully,
will
be
replaced,
but
it
will
take
obviously
some
time
and
so
saying
like
if
you
want
to
use
gateway
with
the
service,
but
you
duplicate
everything
might
slow
adoption.
B
Yeah
we
had
some
discussion
on
Cygnus
I,
don't
remember
exactly
which
me
but
like
what
service
the
just
the
grouping
constructs
or
maybe
it
wasn't
like
that.
There's
been
some
other
conversations
but,
like
you
know
what
they
weight
limits
service,
it
just
talks
about
grouping
and
then
we
sort
of
push
all
the
network
associate
stuff
up.
I
think
that's!
What
you're
talking
about
Jeremy
is
something
similar
I
think
what
you're
talking
about
it
even
getting
rid
of
the
grouping
but
I'm
afraid
that
that
then
leads
to
the
same
service
like.
D
D
Think
the
grouping
makes
sense
like
service
like
that's.
What
service
describes
two
minutes?
It's
a
grouping
right
and
then
we've
also
stuck
a
bunch
of
gateway
type
concepts
on
it.
So
as
a
grouping
it
makes
sense.
But
if
all
it
was
was
a
grouping,
then
it
seems
like
we
could
relatively
easily
create
other
kinds
of
grouping
and
still
take
advantage
of
all
the
gateway
parts
as
as
now
gateways.
This
separate
thing,
yeah.
C
I
mean
I
think
that's
the
point
is
this:
the
service
is
fundamentally
about
grouping
and
there
are
more
types
of
burping
that
we
want,
especially
with
multi
cluster.
Fundamentally,
we
don't
want
to
get
rid
of
the
service
or
anything
like
that.
The
service
still
forms
the
function
of
grouping
and
that's
what
we
still
need,
and
maybe
the
service
needs
to
be
enhanced,
to
be
able
to
do
different.
C
B
B
Think
the
core
API,
it
is
what
it
is
like.
We
can't
really
change
that
behavior,
but
we
see,
though,
a
couple
of
things
they're
driving
this
one
of
them
is
that
we
do
see
lots
of
complaints.
That
service
is
overloaded.
We
do
see
lots
of
features
that
will
be
proposed
and
are
being
proposed,
for
example,
there's
a
recent
one
about
like
IP
protocol
instead
of
TCP
unity,
that
if
we
keep
trying
to
extend
the
service
resource,
it's
going
to
be
really
ugly
and
probably
very
hard
to
define.
B
The
third
thing
is
that
sort
of
gateway
is
intended
to
be
a
rev
of
some
aspects
of
service,
and
maybe
we
should
just
say
outright
that
hey,
it's!
B
So
people
who
use
service
can
still
use
service
right.
It's
still
exist
as
a
in
its
current
form,
but
if
you
need
the
flexibility,
you
need
to
sort
of
like
very
nuanced
exposure.
Like
let's
say
you
want
a
note
port,
but
nothing
else.
Could
there
be
a
gateway
way
to
say
that
using
service
just
as
a
grouping
mechanism,
and
then
we
kind
of
stitch
everything
together
that
way,
that
is
one
sort
of
API
migration
path.
B
So
the
thing
I
came
up,
I
think
in
puke
on
well
December
or
November
is
like
big
arch
was
talking
about
Novi
to
like
service
one
of
the
things
that's
like.
Should
we
do
a
service
be
to
and
then
clean
everything
up,
and
this
is
one
way
to
sort
of
do
a
v2
without
actually
removing
the
original
service
or
it
could
lead
to
a
V
to
a
service
that
is
just
grouping,
and
then
you
attach
at
the
gateway
and
so
forth,
is
that
that
make
that
no.
A
Maybe
a
follow
up.
Is
there
any
any
consideration?
Any
work
in
looking
at
a
l4
gateway
that
does
not
use
service
at
all
does
not
end
up
routing
service
has
its
own
selection
mechanism,
I
mean
we
I
mean
essentially
what
if
I
understand
it
right
now
we're
talking
about
maybe
using
service
as
a
selector
only
which
selectors
themselves
are
not
particularly
complicated.
I,
don't
know
yes,.
E
G
So
I
have
a
question
with
the
like,
using
gateway
for
like
instead
of
service
for
exposing
services
that
make
sense.
I
can
see,
you
know
how
it
relates
to
node
port.
You
know,
services
of
type
load
balancer
can
be
exposed.
We
are
gateway,
sure
the
internal
services,
so
cluster
IP
e
part
of
K
to
be
the
current
understanding
is,
you
know
you
use
gateways
exposing
in
cluster
like
in
Turkey
in
tracklist,
or
things
to
outside
world
does
like
this
in
cluster
traffic
or
in
cluster
communication.
B
So
I
think
the
in
out
of
cluster
is
a
little
bit
there
is
this
I
think,
unfortunately,
there's
like
kubernetes
comes
with
a
partial
networking.
Fpn
is
kind
of
model
where
there
are
certain
sort
of
requirements
that,
if,
if
the
cluster
IP
e
you
can
get
to
it
from
within
the
cluster,
but
there's
nothing
that
prevents
you
implement
the
in
cluster
IP
using
a
load
balancer
that
is
in
the
SDN
or
like
float
around
and
then
index.
B
In
that
way,
you
could
have
a
VM
that
live
that
somehow
able
to
reach
that
network
also
be
able
to
talk
to
the
cluster
IP
there's
no,
at
least
as
far
as
I
know,
there's
no
like
restriction
that
the
cluster
idea
is
somehow
inside
the
cluster
and
in
fact,
Cooper.
Nice
doesn't
really
talk
about
the
network
as
much
as
its
defined
if
things
can
be
reachable
and
then
how
they
can
behave.
B
B
It
can
work.
So
that's
where
the
in
out
of
cluster
distinction
is
a
little
bit
blurry.
The
other
one
is
that
I
we've
seen
also
people
route
internal
service
traffic
to
write
other
services
need
a
a
load.
Balancer
like
is
that
really
in
the
cluster
or
outer
cluster,
probably
not
great
distinction
there,
and
then
the
the
no
port
is
actually
no
port
doesn't
because
it
is
a
way
that
people
have
been
using
to
expose
their
services
to
outside.
So
in
some
times
it
is
a
form
of
gate
waiting,
so
yeah.
B
C
I
mentioned
one:
someone
brought
up
the
fact
of
weather
services.
Weather
grouping
could
be
done
by
Gateway
itself,
I
think
the
one
when
an
area
where
that
becomes
really
challenging
is
in
that
the
services
you
can
change
the
label
selector.
But
if
you're
doing
like
a
percentage
based
weight,
the
label
selector
is
basically
on
or
off
for
a
given
group
of
pods,
and
so
you
really
need
to
have
two
services
that
simultaneously
exist
so
that
the
Gateway
can
do
a
percent
weight
to
both
of
them.
At
the
same
time,
just.
B
F
If
we
think
about
gateway
from
a
networking
standpoint
or
it
would,
what
is
a
gateway
it's
to
allow
two
hosts
to
communicate
when
those
two
hosts
aren't
on
the
same
network,
they
can't
communicate
directly
all
right,
so
I
think
we
could.
We
can
leverage
that
meaning
of
of
a
gateway
for
service
api's
so
that
we
say
potentially
a
gateway
is
whenever
you
don't
want
to
pods
to
communicate
directly
with
one
another.
E
B
Right
mark
yeah
I
just
want
to
add
on
to
that-
is
that
this
is
also
a
natural
way
for
us
to
get
traffic
split
above
service,
because
if
you
push
traffic
split
into
service,
it's
sort
of
mixes
up
selection
with
and
then
you'd
have
to
have
like
some
kind
of
subsection
inside
service,
and
that
one
is
a
whole
topic
gate
of
itself,
but
it
it
seems
like
we
we
should
stop
at
like.
There
needs
to
be
an
atomic
level
at
some
point
where
you
stop
pushing
things
underneath
it.
A
A
A
A
I,
hopefully
this
is
better
yeah.
My
question
was:
if
we
could,
if
now
as
we're,
rethinking
how
service
interacts
with
everything
and
what
role
these
new
api's
play.
I
I've
always
thought
a
traffic
splitting
using
multiple
services
like
every,
like
as
an
example.
If
you
want
the
traffic
split
between
different
versions
of
an
app
or
something
like
you
know,
new
service,
every
time
that
feels
potentially
painful
and
I
don't
know
it
just
seems
like.
Maybe
this
is
an
alright
time
to
think
of
a
different
way
to
do.
A
B
B
Got
five
minutes
so
I
think
there
were
a
couple
of
threads.
Let's
go
through
the
note
we
should.
Probably
the
immediate
problem
is:
let's
just
walk
through
some
sketches.
There's
one
in
the
repo
I.
Don't
know
if
they
even
work,
we
should
figure
out
okay.
So
this
is
like
a
reasonable
idea
that
we
can
pursue,
and
then
we
can
sort
of
focus
on
a
couple
of
use
cases.
B
B
To
me
and
less
problematic
and
then
see
the
resource
model
work
and
then
the
longer-term
expiration
for
service
we
should
discuss
and
in
the
broader
Signet
work
about
putting
putting
that
statement
out
there
that
it's
okay
to
design
it
overlapping
service.
Knowing
that
you're.
A
But
yeah
that
makes
sense.
It
sounds
like
as
far
as
API
is
concerned
and
as
far
as
sketches
of
how
these
things
could
work.
The
answer,
while
leaving
missing
piece,
is
what
comes
between
gateway
and
service
and
so
I
guess:
I.
Don't
we?
We
have
a
proposal
for
a
TCP
route
which
is
right
now
I,
mostly
undefined
type
in
our
spec,
but
I
am
assuming.
That
is
one
of
the
key
items
we
need
to
flesh
out
as
we
as
part
of
any
example
or
someone.
Similarly,
a
UDP
route.
A
A
B
B
D
B
A
A
But
yeah
we
could
probably
use
more
issues.
I
had
thought
there
was
already
a
pull
request
or
issue
that
you
basically
added
and
proposed
a
TCP
route,
but
I
can't
find
that
anywhere
and
right
now
all
we
have
in
Tights
is
just
an
empty
TCP
rap
type,
so
we
have
the
type
it
just
doesn't
have
anything.
No.
B
Rob
I
think
that
is
a
good
issue
to
use
157.
We
can
probably
take
the
some
of
this
discussion
either
drop
it
in
the
comments
here
and
then
start
it
off
here
in
terms
of
like.
Oh,
this
may
overlap
with
service
and
whether
that's
okay
and
appoint
people
to
this
one,
at
least
for
that
initial
scoping,
yeah.