►
From YouTube: Service APIs Meeting (EMEA Friendly Time) 20200611
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
june
11.
and
we've
got
a
couple
things
on
the
agenda
both
from
bowie,
but
I
think
I
have
a
little
bit
of
context
at
least
on
this
first
one,
because
we
did
discuss
it
a
little
bit
yesterday
and
actually
it
looks
like
bowie
just
showed
up,
but
foe
wanted
to
discuss.
B
A
Oh
no
worries
yeah
so
service
apis.
A
B
Right
yeah,
I
I
so
this
is
like
I
did
this
jotted
down
this
pretty
fast,
but
these
feel
like
plausible
things
that
we
can
attain
for
v1
alpha
1,
if
we
really
focus
right
now
on
nailing
down
some
basics,
so
clearly
gateway
class
and
its
semantics
for
interoperation
between
controllers
and
the
security
model
that
we
have.
So
I
think
those
were
had
significant
discussions.
Even
we
have
a
dock
that
is
checked
in.
B
It
seems
like
we
understand
at
least
the
model
that
we're
proposing
right
now,
so
this
would
be
good
to
get
into
the
one
alpha
ones
to
have
people.
Try
it
out
and
see
in
actuality.
Does
it
make
sense,
two,
several
sort
of
basic
applications
to
kind
of
make
sure
that
the
schema
that
we
have
set
up
works
with
enough
flexibility
across
these,
so
clearly
http,
https
and
then
also
tcp.
So
I
know
there's
a
sketch
on
tcp.
B
B
We
can
put
it
in
I'm
just
trying
to.
If
we
have
to
drop
something,
then
we
can
drop
it
like.
I
want
to
be
very
minimal
just
to
make
it
so
that
we
can
get
something
early,
but
udp.
D
B
If
it
looks
just
like
tcp
great,
if
we
have
to
drop
something,
I'm
sorry
but
udp
is
probably
on
that
list.
B
Yeah,
so
I
I
expect,
probably
there
won't
be
much
difference.
It's
just
like
if
you
had
to
choose
among
your
children.
Well,
that's
a
bad
example.
You
can't
use
a
lot
of
children
so
access
to
features.
So
this
is
again
something
where
we
just
throw
darts
out
there
to
outline
sort
of
what
we
think
how
things
could
work,
but
we
don't
have
to
like
do
everything.
For
example,
you
don't
have
to
do
like
every
feature
under
the
sun.
B
You
just
do
one
that
is,
for
example,
one
of
these,
like
quote,
unquote
filters
to
know
how
to
do
the
class
of
filters.
We
don't
have
to
do
all
of
the
different
load,
balancing
algorithms.
We
could
do
traffic
splitting.
Actually,
I
think
this
one's
major
enough
to
be
on
its
own
to
understand
how
the
class
of
traffic
splitting
and
sort
of
splitting
between
services
will
work
same
thing
here.
I
have
service
level
configurations
such
as
timeouts
right.
B
We
could
do
and
just
focus
on
one
of
these,
but
then,
after
doing
that,
we
would
probably
understand
the
cl
that
class
of
configuration
as
well
I'm
going
fast.
So
you
can
interrupt
me
at
any
point
implementability.
B
We
just
need
to
make
sure,
and
then
thankfully
we
have
folks
here
who
have
varying
different
infrastructures
depend
on
is
we
have
gateway
implementations
that
are
going
to
be
merging
them
into
quote?
Unquote
single
proxy
infrastructure,
but
really
you
could
have
multiple
proxies.
It's
just
that
you
have
this
concept
of
merging
versus,
like
the
sort
of
provisioning.
B
B
That's
an
interest,
something
that
we
seem
to
have
a
good
grasp
on,
at
least
in
this
current
proposal
and
then
finally,
the
status
and
conditions
is
one
of
those
things
that
you
cannot
really
have
super
concrete
things
until
you
settle
on
some
of
this,
but
definitely
the
first
iteration.
We
should
throw
out
probably
an
excessive
amount
of
status
and
conditions
just
to
see
how
that
feels.
B
If
there's
going
to
be
scalability
issues
there,
because
this
is
something
that
is
currently
very
lacking
in
the
ingress
api
and
we
would
like
to
improve
on
so
I
put
for
v1
alpha
2.
It
looks
like
we
did
talk
about
in
the
initial
proposals
talking
about
delegation
inclusion.
It
seemed
like
a
good
idea.
We
just
haven't
had
any
time
or
discussion
on
it.
So
that's
why
I'm
feeling
like
that
is
for
v1
alpha
2.
B
That
is
interesting,
and
I
think
we
should
continue
the
conversation,
but
probably
for
v1
output
2.
We
would
be
able
to
get
like
concretely
into
what
it
takes
to
do
that
I'm
going
to
stop
here.
I
would
love
to
hear
feedback
on
kind
of
this
general
set.
If
something
is
hugely
missing
things
we
can
cut,
which
is
always
useful.
A
Thanks
for
getting
this
together,
I
think
it's
really
useful
just
to
see
how
relatively
close
we
are
to
something
that
could
be
frozen
out
of
e1
alpha
one.
I
think
to
me
when
I
look
at
this
list.
The
biggest
gap
I
see,
at
least
in
terms
of
what's
checked
in
to
the
repo
would
be
any
kind
of
l4
support,
so
that
seems
like
an
area
we
should
focus
on,
maybe
they're.
You
know
it
we're
also
already.
A
You
know,
thanks
to
dania
and
harry
working
on
ways
to
solve
this,
so
I
think
we're
close,
but
this
this
is
great
too,
to
bring
back
some
focus.
B
Yeah,
like
please,
speak
up,
if
you,
your
favorite
thing
is
not
in
here
or
you
feel
like.
If
we
go
to
v1
alpha
one,
it
would
if
we
go
to,
we
want
alpha
one
without
it,
and
then
we
have
to
add
it
in
later
that
it
will
be
a
huge
rework
which
is
fine.
Like
that's
perfectly
fine,
you
know
for
you.
Maybe
the
outfit
too
will
look.
E
E
Of
these
service
levels,
especially
when
we
start
combining
this
matrix
of
features
and
functionality,
I
think
we
just
need
to
make
sure
that
we
really
have
an
understanding
of
that
and
we
have
a
clear
definition
of
the
service
levels
and
especially
when
we
start
combining
different
things
together.
Okay,.
B
B
F
Yeah,
this
is
something
that
nick
raised
internally
the
other
day
because
you
know
with
with
tcp.
We
have
proxy
protocol
and
you
have
a
bunch
of
application
layer
stuff.
But
maybe
I
don't
know
if
udp
apps
have
tend
to
have.
F
B
Yeah,
that's
a
good
point.
The
the
class
of
udp
applications
I
know
of
are
just
like
real
time
streaming
and
then
maybe
the
quick
protocol
there
are-
and
maybe
one
of
these
like
broadcast
ones,
but
that
doesn't
make
sense
for
this
api.
I
think,
although
it's
an
interesting
idea
to
think
about,
it,
would
be
good
to
understand
what
udp
applications
we
should
be
looking
at
yeah
a
lot
of
them
and
that
like
whether
or
not
people
will
even
really
what
they
want
to
do.
B
F
Yeah
for
for
quick
there's,
a
a
quick
lb
rfc
for
load
balancers,
which
I
haven't
read,
but
we
might
have
to
all
read
it
and
understand
what
you're
supposed
to
do
with
load.
Balancing.
F
B
Yeah,
so
that's
probably
why
it
it
got.
I
was
thinking
it
would
get
pushed
off
to
v1
alpha
2.
E
B
That's
a
good
question.
I
would
like
to
do
another
session
focused
on
tcp
to
see
if
we
can
get
it
to
a
level
that
we
are
more
comfortable
with
it.
So
that
is
a
very
good
point.
B
The
reason
I
put
it
in
there
is,
I
kind
of
want
to
have
something
else
aside
from
hdb,
so
another
proposal
would
be
this
tls
flight
stream.
I
don't
know
what
you
call
the
tls
connection
based
thing,
which
that
feels
also
similar
to
tcp
so
generally
for
b1
alpha
one.
B
D
B
E
Well,
you
know
I
mean
I
agree
with
that
and
I
just
call
it
out
as
like
a
stretch
goal
because
I
feel
like
if
we
get
to
a
point
where
we
say
you
know,
we
feel
like
pretty
much
everything's
there,
but
we're
still
discussing
you
know
tcp
or
tls
byte
stream.
E
I
just
I
just
feel
like
a
lot
of
implementers.
If
not
all
implementers
are
hitting
the
pause
button
waiting
for
this
v1
alpha,
1
cut
to
start
implementation
and
I
feel
like
even
without
tcp
or
some
know,
udp
tls,
byte
stream
from
an
implementation
standpoint.
There's
a
lot
that
a
lot
of
momentum
we
as
implementers
can
achieve
and
there's
a
lot
that
we
can
learn
from.
So
no
doubt
if
we
have
tcp
or
tls
bytestream
it'd
be
great
to
have.
B
That's
true,
so
that's
a
very
good
point:
how
about
we
we
schedule
a
deep
dive
on
the
tcp
and
for
next
session.
B
One
thing
is,
I
just
put
this
question
is
like
what
are
the
unknowns
that
we
kind
of
need
to
figure
out
to
make
that
decision,
and
for
each
of
these
I
think
we'll
just
start
basically
probably
having
more
meetings.
B
I
know
everyone
loves
meetings
is
not
the
solution
so
given,
if
folks
are
comfortable
with
this
set,
probably
you'll
see
I'll
just
start
pinging
on
slack
and
trying
to
coordinate,
to
see
who
wants
to
dive
in
and
just
really
create
the
bar
that
the
minimal
set
like
specifically
concretely
for
each
of
these
items,
but
then
we
can
just
iterate
on.
C
Awesome
yeah
I
raised
tcp,
you
know
because
and
udp
is
personal
concern,
but
yeah
any
other
alternative
if
we
could
get
it
in
to
bowie.
To
your
point,
I
think
that
would
be
great
to
just
have
something
to
guarantee
that
this
isn't
actually
becoming
an
http.
Only
api.
A
I
think
that
may
be
it
on
the
stock,
so
I'll
move
on
to
the
next
next
agenda
item,
which
was
service
decorators,
also
from
bowie,
so
I'll
lay
I'll.
Let
you
give
a
bit
of
a
background
here.
B
So
this
one,
we
probably
don't-
have
enough
time
to
go
over
the
full
dock.
What
I
kind
of
want
to
highlight
is
basically
that
harry
had
this
really
good
write-up
on
service
apis
and
the
stock
is
mostly
just
to
give
space
for
people
to
kind
of
jot
down
their
notes.
You
should
be
able
to
edit
it
by
the
way
or
make
suggestions,
so
everyone
feel
free,
and
we
just
threw
some
straw
man
sort
of
thoughts
as
to
how
to
do
service
level
configuration.
B
So
there
is
that
this
diagram
basically
shows
that
you
know
what
is
the
problem.
The
problem
is
basically
configuring.
Attributes
of
this
red
link
here,
most
implementations,
we're
talking
about,
are
proxies,
proxies
need
to
reach
out
to
the
service.
B
There
are
properties
of
that.
We,
you
know
the
thing
that
it's
reaching
out,
such
as
protocol
like
dls,
that
includes
authentication,
I
guess
algorithms,
on
how
to
load
balance
between
the
endpoints.
What
the
retry
behavior
is,
I
put
mirroring
here.
We
put
mirroring
in
another
place
in
the
api
as
well,
but
you
know,
potentially
you
could
do
mirroring
here,
but
not
clear
how
to
help
check
the
service.
B
How
to
do
timeout
and
keep
alive,
so
questions
is
one.
How
do
you
represent
this
like
a
very
basic
level?
Two-
and
this
is
germane
to
the
mirroring,
is
when
does
it
make
sense
to
do
it
at
the
service
level
versus
the
route
level?
B
And
I
put
a
little
note
here
like
the
proposal
here
is
all
about
service
level,
but
for
specific
items
they
may
not
make
sense
to
do
in
this
style.
The
third
question
which
came
up
in
the
sidecar
istio
discussion,
but
it's
we
should
may
be
just
punting
that
for
now
is
who
will
control
the
configuration.
B
So
there
was
this
interesting
point
that
I
think
harry
or
someone
brought
up
that
a
lot
of
times.
People
are
writing
these
gateway
route,
definitions
to
override
the
service
owners
default
configuration
because
it's
like
you,
use
the
proxy
in
some
ways
to
like
fix
things
up.
So
how
will
that
be
represented
in
our
api?
Do
we
do
it
using
the
same
mechanism
that
the
service
author
would
do,
but
you
just
overwrite
just
like
literally
overwrite
their
object
or
was
there
some
kind
of
merging?
B
So
this
is
like
a
more
advanced
use
case.
I'll
briefly,
go
over
kind
of
what
some
straw
man
examples
and
then
we
can,
you
know,
try
to
like
shoot
it
down
and
propose
better
ones.
B
One
of
the
things
that
seems
natural
is
to
basically
have
sort
of
like
orthogonal,
decorator
resources-
and
here
I
say
by
use
case,
because
this
is
sort
of
like
a
very
extreme
version
of
this.
Where
here
you
have
a
service
and
then,
if
you
want
to
talk
about
timeouts,
you
would
have
a
timeout
policy.
B
B
So
you'll
notice
that
http
retry
has
no
validity
for
I'd,
say
tcp,
it
will
be
ignored
and
then,
of
course,
there's
some
base
defaults.
But
if
people
don't
have
these
objects,
it
seems
like
that's
just
an
infrastructure,
dependent
thing
and
then
the
fourth
note
is
that
you
don't
have
to
necessarily
orthogonalize
everything
completely
like
you
could.
Potentially,
if
we
have
enough
portable
things,
just
like
stick
it
into
the
one
resource
and
this
and
then
there's
some
way
to
associate
this
thing
to
this
thing,
the
easiest
is
just
to
use
it.
B
The
same
name,
same
name,
space,
they're,
associated
more
complicated
things
are,
you
can
use
references
which
I
have
here
and
that
seems
like
a
natural
way
to
kind
of
extend
service
without
actually
extending
service.
B
There's
the
question
my
second
question
of
like
what
should
be
in
here,
so
I
have
just
a
bunch
of
basically
copied
over
from
the
top
and
then
I
do
talk
about
overrides
a
little
bit,
but
you
can
just
treat
this
as
kind
of
fairly
speculative
and
then
finally,
there's
a
interesting
point
at
the
end,
which
is
sort
of
like
a
almost
a
philosophical
one
is
what
constitutes
a
service
versus
a
route
so
and
in
some
sense,
as
a
group,
we
just
need
to
make
a
decision
on
this.
B
It
almost
feels
like
in
that,
when
you
create
a
new
service
versus
reuse,
a
service,
but
do
something
else
to
sort
of
split
it
into
different
configurations.
What
do
I
mean
by
this?
Let's
say
you
have
a
workload
and
you
have
a
service
on
that
workload
and
let's
say
you
wanted
to
have
two
different
kinds
of
load:
balancing
configurations
for
that
that
workload
you
create
two
services
or
do
you
only
have
one
service
and
then
you
somehow
in
some
other
mechanism
like
distinguish
these
two
algorithms.
B
Please
read
through
this
issue
first,
because
this
thing
is
like
an
excellent
summary
of
kind
of
like
the
space
and
then
just
comment
on
this
and
add
your
own
proposals
as
well.
I
put
in
a
google
doc
because
it's
much
easier
to
deal
with
than
sort
of
like
having
people
comment
on
the
github
issues
and
then
the
comments
get
out
of
date
and
can't
read
it
anymore
and
that's
it
so
we're
almost
that
time.
F
Did
you
think
about
doing
a
selector
to
match
the
to
find
the
service
that
the
decorator
decorates.
B
Oops
yeah,
I'm
adding
that
selector
from
decorator
to
service
is
that
the
direction
you
want
to
go.
F
Yeah
yeah,
that
seems
like
that
seems
like
a
kind
of
kubernetes
net.
It
seems
like
a
pretty
common
combinations
way
of
connecting
document
connecting
cids,
creating
resources.
A
Would
these
kinds
of
crds
be
within
the
scope
of
service
apis
like
are
these
things
that
we
want
to
eventually
cover
in
a
v1
alpha?
I
don't
know
what
number
or
is
this
more
just
separate
but
related.
B
I
think
at
least
the
portable
ones
definitely
are
in
scope,
because
we
are
talking
about
how
to
do
timeouts
and
so
forth,
and
if
we
can,
I
would
love
to
get
this
into
b1
alpha
one
just
so.
B
People
can
try
it
out
and
see
if
this
kind
of
schema
is
usable
by
users,
because
a
lot
of
the
feedback
for
some
of
these
apis
that
have
like
lots
of
little
resources
everywhere,
is
that
the
user's
a
one
they
don't
know
how
to
discover
it
and
then
two
like
it's
kind
of
pain
in
the
butt
to
manage.
So
that's
what
I'm
thinking
is
that
when
we're
talking
about,
for
example,
health
checks,
like
that's
a
common
one,
that
comes
up
like,
oh
you
want.
B
Seems
also
portable,
it
should
definitely
be
in
scope
now.
There's
an
interesting
side
note
is
that
this
definitely
allows
you
to
have
easy
easy
way
to
have
like
custom
stuff.
In
that
you,
we
have
to
say,
there's
some
design
structural
interface
or
something
that
these
decorators
have
to
follow.
And
then,
if
you
follow
that,
then
we
can
sort
of
tell
the
user
some
generic
way
that
these
things
will
be
used.
But
some
of
these
resources
may
be
totally
custom
to
the
implementation.
A
Yeah
that
makes
sense
that
makes
sense
yeah,
I'm
just
I
can
see
this
turning
into
a
large
number
of
crds
if
we
keep
them
all,
really
tiny,
which
has
its
own
benefits,
I
suppose,
but
also
yeah.
I
guess
we'll
just
have
to
see
what
the
right
balance
is
between
number
of
crds
and
just
one
huge
crd
that
contains
all
the
config.
B
B
I
yeah
so
I
just
wanted
to
highlight,
like
this
is
sort
of
like
an
open,
open
type.
I
forget,
like
it's
like
you,
know
and
see
when
you
have
the
brace
and
like
you
can
add
to
the
class,
which
is
nice
for
extensibility,
but
I
mean
realistically,
if
we
are
having
a
portable
set,
we
would
just
consolidate.
D
F
Maybe
if
you
think
there's
a
use
case
for
overripe
for
context
dependent
policy,
so
I
haven't
read
the.
F
D
F
Set
out
these
decorators
for
a
service,
but
is
there
a
use
case
for,
for
you
know,
wanting
to
tune
the
time
out
to
different
values,
depending
on
how
the
service
is
used
in
a
route.
B
Yeah,
that's
that's
sort
of
my
my
question
here
is
that
what
configuration
makes
sense
at
the
service
level
versus
the
route
level
and
how
many
use
cases
are
going
to
be
that
you
want
very
extremely
granular
and
then
the
other
question
would
be.
D
So
in
my
mind,
I'm
thinking
that
these
decorators,
whatever
we
end
up
with
they,
need
to
be
associated
with
service
if
a
route
wants
to
not
follow
that
policy.
So
this
is
the
client,
the
client
and
server,
and
the
server
is
the
service
and
the
client
is
in
our
case
the
gateway
right,
because
gateway
is
making
a
call
to
the
service.
D
D
D
What
happens
is
you
can
do
that
at
you
know,
from
a
networking
in
a
kubernetes
standpoint,
you
can
easily
do
that,
but
there
is
so
much
that
is
built
on
top
of
services
that
everything
above
breaks
down.
So
you
know
if
you
have
alerting
setup
on
services
that
causes
issues,
because
now
you
have
to
set
up
that
on
multiple
services,
so
somebody's
dashboard
now
does
not
have
the
complete
picture
or,
as
some
other
integration
breaks
down.
So
that's.
Why
make
keeping
an
abstraction
of
the
service
as
is
remains?
D
A
That
raises
an
interesting
question
from
me
too.
I
I'm,
I
I'm
curious.
What
the
difference
is.
You
know
if
we
think
of
our
roles,
our
personas
here,
as
you
know,
I
think
harry
was
mentioning
that
you
have
a
service
owner
that
may
be
different
than
the
person
configuring
the
route,
and
if
I
understood
that
correctly
and
and
I'm
I
know
in
our
security
model
right
now,
I
think
that
we
say
the
application
developer
owner.
A
A
F
I
think
there's
definitely
a
use
case
for
that,
like
we,
you
see
people
who
are
doing
who
are
hosting
a
large
number
of
domain
names
with
within
a
cluster
and
for
those
kind
of
use
cases
you
could
easily
see
that
the
infrastructure
operator
owns
the
route
and
the
user.
The
application
developer
owns
only
the
service,
and-
and
this
would
give
the
way
for
an
application
developer
to
to
tweak
how
the
routing
layer
talks
to
the
service.
Without
you
know,
having
to
own
the
route
object
itself.
D
And
and
to
answer
the
second
question:
rob
you
had
around
overriding?
It's,
it's
observed
less,
you
know
if
you
have
a
very
expensive
endpoint,
which
is
called
very
often
you
want
a
different
timeout
behavior
or
you
know.
Maybe
you
are
an
e-commerce
shop
and
you
want
a
longer
time
out
on
the
checkout
or
something
like
that.
So
that's
where
those
one-off
cases
where
these
things
come
up.
A
B
The
the
problem
that
services
always
has
multiple
ports.
Yes,.
D
Yeah
this
is
this
is
something
that
I
was
wishing
to
avoid,
but
I
mean
you
cannot
avoid
for
so
long,
but
this
is
another
problem
that
keeps
coming
up
where
we
specify
by
the
way
I
mean
kong,
has
this
sort
of
decorator
pattern
right
now,
but
it's
option
two
that
do
yes,
I
like
it.
So
it's
referenced
by
an
annotation
and
every
once
in
a
while.
We
do
have
users
who
run
multiple
ports
on
a
service,
and
then
they
complain
that
the
same
configuration
is
applied
to
both
both
ports.
B
B
The
but
it
is
very
much
yeah,
unfortunately,
because
service
has
multiple
ports,
it
makes
it
has
plural
eyes
and
kind
of
made
everything
that
hangs
off
of
it
have
to
deal
with
it.
B
Okay,
so
any
more
thoughts,
please
chew
on
this
and
put
your
suggestions
here
as
well.
D
Oh
one
question
that
I
had
was:
I'm
not
super
familiar
with
the
multi-cluster
story.
That's
going
on.
So,
if
someone,
I
think,
poe
and
rob
you
are
familiar
with
that.
If
we
can
just
make
sure
if
this
doesn't
break
anything
in
that
area,
that
would
be
like
whatever
we
need
to
consider
that
area
like
how
it
works
in
the
scenario.
B
That's
a
good
point.
I
did
think
about
it,
or
at
least
that
issue
did
come
up
when
I
was
looking
at
this
again,
but
definitely
I'm
gonna
add
a
how
does
multi-cluster.
A
All
right:
well,
I
think
that
brings
us
to
time.
Thank
you
to
everyone
for
showing
up,
really
helpful
meeting
and
we'll
talk
to
you
next.