►
From YouTube: Service APIs Meeting (APAC Friendly Time) 20200409
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
A
Good
to
know
all
right
and
I
should
also
mention:
Bowie
has
not
disappeared,
he's
just
out
of
office.
I
should
be
back
next
week
and
then
you'll
hear
more
from
him,
but
anyways
so
I
guess
we
can
get
started
here
with
issue
48,
which
is
Dan
Ian's
bit
to
talk
about
I,
don't
know:
do
you
want
to
walk
us
through
this
sure.
C
D
D
I
hope
to
be
a
part
of
this,
but
is
we're
using
the
listener's
extension
object
reference
to
just
put
a
service
there
to
bypass
the
need
for
the
route
entirely,
since
it
doesn't
really
sort
of
work
well
with
l4
routes
today,
anyway,
and
so
it
can
live,
it
can
be
a
long-lived
aspect
of
if
you
have
a
controller
that
reads
this,
because
if
the
extension
is
just
a
service,
ref
then
dude
and
get
the
ports
and
everything
you
need
from
there.
That's
not
ideal,
but.
A
C
E
C
B
So
I'm
just
updating
the
issue
with
this
comment,
but
pretty
much.
Every
ingress
controller
has
a
way
to
specify
the
target
port
when
you
want
to
send
traffic
to
a
service.
So
it
seems
like
one
approach
we
could
do
here
is
to
just
do
a
quick
survey
of
what
existing
ingress
controllers
do
and
if
we
like
any
of
those
options
that
we
can
play
into,
they
proposal
for
the
spec.
Now.
A
B
B
B
It
used
to
be
the
annotation,
but
we
found
that
people
using
the
API
would
you
maybe
as
a
documentation,
but
we
found
people
would
have
issues
with
labeling
putting
the
label
on
the
wrong
object.
So
what
it
seems
like
it
wasn't
a
very
intuitive
solution
for
people.
We
had
to
kind
of
type
out
quite
a
few
issues
where
it's
like
it's
not
going
there
but
and
we
put
the
label
on,
but
it
was
on
the
proxy
object
not
on
the
service
object.
Labeling.
The
service
object
didn't
seem
like
a
natural
API
for
for
people,
yeah.
B
B
Feel
differently
about
it
and
it
might
have
different
discoverability
properties.
C
C
D
C
C
F
C
D
Do
we
handle
that
use
case,
so
I'm
gonna
suggest
it
actually
shouldn't
be
an
HTTP
rather
at
all,
and
it
you.
You
also
start
encoding
parts
of
the
service
spec
into
your
routes,
which
you
may
or
may
not
want
to
do,
but
it
and
again
this
is
something
I'll
talk
about
later,
but
I
could
bring
it
up
now.
D
But
if
you
want
to
loop
back
to
this,
but
but
basically
my
my
suggestion
is
gonna-
be
that
if
you
take
a
route
that
always
starts
with
TCP
I
would
actually
just
remove
the
port
from
the
listener
altogether,
like
my
other
PR
said,
add
ports
remove
the
port.
Haven't,
have
the
routes
start
with
a
TCP
route,
then
that
could
have
a
that.
D
Has
your
port
as
your
ingress
in
your
egress,
your
your
forward
to
basically
your
your
listener
port
and
your
target
port,
and
then
that
would
then
also
forward
to
the
HTTP
route,
or
maybe
even
tell
us
before
that,
if
that
makes
sense,
so
you
have
wrap
because
routes
forward
to
other
objects,
but
I
don't
see
any,
and
it
seems
to
me
that
the
and
that's
part
of
what
the
document
I
linked
is
like
the
implication
would
be
they
forward
to
other
routes.
Polly,
don't
over
incumbent,
don't
over
encumber
the
HTTP
route.
E
Comment
in
students,
we
have
explicit
four
to
pretty
much
everywhere
so
and
we
have,
if
the
services
station
as
a
single
port,
then
we
assume
that
it's
optional.
You
have
to
specify
it,
but
it
has
not
force
me
to
put
what
explicitly
and
the
precepts
which
we
have,
what
kind
of
routing
based
on
what
based
on
SMI
and
it
gets
very
confusing
if
it's
not
explicit.
E
A
And
if
we
did
have
a
you
know
going
back
to
the
the
simple
idea
of
a
target
port
on
a
route
in
general.
If
that
route
is
then
referencing
a
service,
then
you
have
this
target
port
referencing,
the
service
port,
which
then
has
a
separate
target
port
for
the
endpoint
itself.
So
you
have
a
few
steps
in
between
potentially
but
yeah
I
mean.
D
So
when
it
does
reference
a
service
and
there's
always
going
to
be
some
double
encoding
of
data,
as
long
as
the
service
is
ever
at
the
end
of
this
because
they
inherently
are
gonna
have
some
of
the
same
information,
at
least
at
this
time.
It's
like
the
service,
ports
and
endpoints.
You
could
have
I,
don't
know
how
people
feel
about
this.
D
I
know
people
have
mixed
feelings,
but
the
target
port
could
be
int
or
string,
and
so,
instead
of
encoding,
the
Vout,
the
numerical
you
say
well,
I
know
it's
gonna
be
HTTP,
so
I'll
say
it's
HTTP
and
then
I
can
look
that
up
at
the
end
of
this
chain.
I,
don't
know
I,
don't
need
to
encode
the
numerical
value
because
I
know
somewhere
along
this
route
chain.
Presumably
it's
the
termination
point
at
the
leaf
like
I.
Can
I
can
look
up
what
the
actual
numerical
value
is.
D
If
something
ends
in
a
service
and
a
service
as
a
service
port
of
HTTP
and
it's
like
8080
and
my
TCP
route-
has
a
target
port
of
HTTP
I
had
to
then
follow
the
Ford's
to
find
that
that
value,
and
it
would
the
only
reason
you
wouldn't
double
encode.
It
would
be
to
have
that
TCP
route
be
more
portable
right
to
say,
like
I,
don't
actually
know
what
my
target
port
is.
I
need
to
look
that
up,
but
that
way
I
can
reuse
this
TCP
routes
depending
and
for
multiple
services
potentially,
but.
C
D
C
D
C
E
E
D
E
Automation
is
in
many
cases
this
whole
thing
goes
to
gateways,
secret
gateways
and
multiple
proxies
level
of
proxies,
and
sometimes
it
has
to
be
routed
by
you
know
what
kind
of
metadata
means
it's
not
entirely
IP
and
to
end.
Everyone
is
source
port
destination
port,
for
example,
user
SMI
headers
throughout
is
a
gateways
to
do
all
kind
of
crazy
stuff.
So
having
an
explicit
series
construct
that
allows
us
to
extend
it
with
other
routing
mechanism,
probably
will
help
in
many
cases
here.
A
A
D
Right
thanks
so
I
literally
just
spent
the
last
I
think
12
minutes.
Writing
this
I've
been
meaning
to
write
it
all
day,
but
something's
dumped
on
my
lap
last
Monday
and
said:
oh,
can
you
have
it
done
by
the
end
of
April,
so
I
discovered
services,
API
v2
last
Friday
that
quickly
had
to
read
all
about
it.
So
I
guess
a
at
the
top
I'm,
not
an
unbiased
observer,
I
kind
of
love
this.
It
really
meets
our
needs
almost
too
well.
The
old.
D
That's
why
I
called
this
api's
b204
Boogaloo,
because,
while
I've
been
looking
at
it,
I've
kind
of
realized
that
it's
almost
l7
centric
to
a
fault
and
it
almost
discourages
anything
to
do
with
l4
and
in
some
cases,
just
out
now
prevents
it
without
violating
the
model
that
you've
defined
so
I.
This
is
not
nearly
complete.
Like
I
said,
I
just
was
jotting
this
down
as
a
weight
or
and
I
what
I'm
trying
to
say
here.
D
This
is
all
kind
of
based
on
the
two
issues
I've
linked
there,
but
so
the
first
thing
and
the
taxonomy
of
load
balancers.
It's
become
clear
to
me
that
there's
actually
not
an
agreement
on
what
a
load
balancer
is
I
was
talking
with
Nick
early
my
morning
to
him
this
morning,
because
I
know
he's
not
gonna
be
around
for
a
few
days
and
he
didn't
think
I
was
online
when
he
sent
me
an
email
and
offered
Chapo
you're
offering
while
I'm
awake.
D
He
won't
do
that
again,
there's
an
hour
of
his
life.
You
won't
get
back,
but
I
mentioned
that
what
I've
seen
in
the
service,
v2
API
very
much
falls
on
line
with
what
I
call
the
EOB
model
where
the
load
balancer
has
this
IP
address
and
listens
on
one
or
more
ports,
and
that
was
partially
informed
by
the
that
PR.
Where
I
said
hey,
we
should
add.
Multiple
ports
to
a
listener.
Well
should
always
be
eighty
right
because
we
defined
the
protocol.
D
So
when
I
first
looked
at
the
service,
v8
v2
API,
there
was
a
conflict
in
the
listener
port
field.
That
is
clearly
a
single
value,
but
the
documentation
indicated
more
than
one
port.
So
that's
why
I
found
that
PR,
but
when
I
looked
at
that
well,
the
docs
are
probably
right
and
to
me
the
listener
was
very
clear.
Like
you
got
an
address,
you
got
more
than
one
port,
that's
a
virtual
server,
that's
a
front
end
right,
and
so
so
a
gateway
has
more
than
one
listener.
D
That
makes
sense
a
gateway
to
the
load
balancer
and
it
has
more
than
one
front
end
or
virtual
server.
I
get
it,
but
it's
become
clear
that
we
don't
necessarily
have
reconcile
between
those
two
models
and
by
the
way,
I
probably
make
sense
to
kind
of
go
through
the
whole
thing
and
look
back
with
any
questions
just
because
I
think
it
becomes
clear
clear
how
I
think
this
all
relates
to
l4.
If
you
want
to
scroll
down,
I
mean
I'm
happy
to
entertain
questions
along
the
way.
D
D
Like
I,
really
love
I
mean
I,
really
appreciate
the
simplistic
elegance
there,
but
I
was
just
pointing
out
that
I
think
some
clarity
is
needed
because
and
I
realized,
where
our
disconnect
was
when
he
and
I
were
talking
when
I
say
control,
plane,
I,
don't
mean
the
thing.
I
don't
mean
the
low
balance
or
control
or
running
occurrence
I
mean
that
there
are
two
ways
that
load
balancers
our
provision,
typically
from
the
cloud
and.
D
On-Premise,
it's
not
divided
between
the
two,
but
there
are
these
two
models.
Right.
One
model
assumes
that
the
control
plane
used
to
provision
and
configure
the
load
balancer
would
be
the
same
and
I'm
talking
about
things
like
AWS
you'll,
be
in
a
sixties,
API
and
even
Abhi's
controller
VM.
So
you've
got
one
one
control
plane.
One
API
endpoint
that
you
can
say:
hey
I,
need
a
new
load.
Balancer.
Give
that
to
me
now,
I'm,
not
saying
what
that
load.
D
Balancer
is
with
respect
to
the
first
section
right,
whether
that
is
a
thing
that
kind
of
multiple
virtual
servers
or
there.
It
is
a
virtual,
that's,
not
important,
but
how
I
interact,
how
the
gateway
class
interacts
with
this
thing
is
right,
so
in
in
all
these
three
cases,
you've
got
a
single
API.
Endpoint
in
the
Gateway
class
can
say,
give
me
a
load
balancer
based
on
my
prescribed
configuration
so
every
time,
there's
a
new
gateway
resource
that
points
to
this
class.
D
So,
for
example,
I
mean
Hugh
cider,
as
the
configuration
I
need
a
load
balancer
that
can
that
can
give
me
a
addresses
from
this
range
great,
but
the
other
type
is
something
like
H,
a
proxy
middle
OB,
where
you
don't
really
have
a
a
static
control
plane
for
for
configuring
them.
You
don't
even
have
a
control
plane
into
you,
provision
it
in
the
first
place
and
then
the
control
plane
for
configuring.
The
load
balancer
is
the
load
balancer.
D
So
imagine
your
CPI,
a
cloud
provider
interfaces.
This
I
need
I
need
a
load
balancer.
Maybe
the
the
service
has
an
annotation
that
says
well.
This
is
the
load
balancer
to
which
it
belongs,
or
if
it's
not
one,
create
one
but
whatever,
but
it
could
just
create
a
listener
right.
It
could
just
create
this
listener,
see
ID
and
you
might
have
a
gateway
out
here.
D
Maybe
you
promote
listeners
and
demote
routes
from
the
Gateway
into
the
listener,
and
the
reason
for
this
is
because,
if
you
do
that,
then
you
don't
have
to
define
ports
on
listeners
at
all,
and
this
is
I
think
actually.
This
is
why
I
end
with
this,
because
it's
it's
overly
prescriptive,
nl7,
right
and
I
was
thinking.
How
do
I
make
it
and
I
think
the
best
way
to
demonstrate
this
is
I
try
to
do
into
implementation
of
TCP
route,
because
I
needed
one
and
I
didn't
want
to
have
a
private
type.
So
it's
like
okay!
D
Well,
let's
put
my
money
where
my
mouth
is
and
I
need.
I
want
to
be
involved
with
this:
let's
contribute
back
right
and
I
I've
been
involved
with
kubernetes
for
a
while,
like
a
cluster
API
and
cloud
provider
and
other
things
not
not
totally
brand-new,
but
again,
this
very
new
to
this.
So
my
issue
with
TCP
route.
If
you
look
at
the
PR,
it
works
really
well,
when
it
you
have
TCP
plus
TLS,
because
then
you
can
very
much
by
the
way.
Mimics
they
CTP
route
and
down
to
the
the
layout
right.
D
D
And
so,
if
you
break
it
apart
like
that
and
put
the
the
list,
the
the
route
selector
on
the
listener,
it's
sort
of
actually
I
think
it
it
drives
towards
that
elegance.
That
I
think
you
already
do
so
well
for
l7
and
I
just
want
to
enable
it
for
l4
and
there's
probably
a
dozen
better
ways
to
do
it
than
this.
But
this
was
sort
of
again
like
I'm
talking
really
fast
because
a
lot
of
sleep.
D
E
D
But
there's
even
an
I
didn't
know
about
this
issue
before
I
filed
the
TCP
route,
PRI
follow
an
issue
for
reference
and
poll
of
TCP
route
and
then
I
filed
a
PR
for
it,
and
my
issue
is
X
raft.
I
guess
from
your
meeting
yesterday
and
I
wish.
I'd
have
seen
this
there's
an
issue
for
a
bytes
stream
route
and
it
has
three
use
cases:
essen,
TLS
termination,
TLS,
bathroo
and
no
TLS
I
mean
I.
D
Wasn't
the
only
one
thinking
of
this
somebody
else
said
yeah
we
need
one
with
no
TLS
and
that's
literally
what
that
PR
did.
But
when
you
remove
TLS,
there's
no
way
to
map
listeners
to
routes
and
by
the
way,
it's
because
you're,
relying
on
something
in
your
l7
payload
protocol
payload
with
HTTP.
They
should
be
headed
a
m--
to
map,
and
you
know
the
concepts
talk.
Y'all
wrote
it
right,
but
that
that
is
completely
absent.
When
you're
dealing
with
all
TCP,
you
have
a
port
but
I.
D
E
D
If
it's
and
that's
why
I
brought
up
the
Gateway
like
what
is
what
is
this
scope
of
a
load
balancer,
because
if
a
scope
of
a
load
balancer,
it
means
that
there
should
be
a
single
IP
address
so
like
a
gateway
is
a
virtual
server.
Now
that
not
a
load
balancer
like
in
a
multiple
virtual
servers,
then
that
works
right.
That
works,
because
then
you
can
have
routes
at
the
gateway
level.
But
if
the
Gateway
has
multiple
virtual
servers,
because
it's
a
little
balancer,
that's
multiple
virtual
service
that
doesn't
work
at
all
in
it.
D
B
I
think
that
if
you
go
back
up
from
the
dark
you
look
at
the
taxonomy
of
load,
balancers
I
think
like
for
me,
I
think
that
the
two
items
you
have
they're
not
really
different.
It's
just
a
matter
of
it's
just
a
matter
of
organizational
boundaries
in
these
two
models
right,
so
ELB
is
like
a
load
balancer
that
someone
met
that
someone
manages
and
the
nsx
T&H
a
proxy
model
is
like
well,
okay,
so
I'm
the
person
that
manages
that.
D
The
control
planes
issue
is
separate
than
the
taxonomy
of
load.
Balancers
I
think
you
might
be,
can
confer
I'm
conflating
them,
but
the
the
taxonomy
of
load
balancer,
is
a
specific.
Let
me
see
if
I
can
simplify
further
right
or
for
my
own
I
need
probably
didn't,
communicate
it
well.
There's
a
load
balancer
have
a
single
IP
address
with
multiple
ports
or
does
a
load.
Balancer
have
some
sub
construct
where
the
IP
address
exists
and
that's
where
the
ports
are,
because
the
routes
should
be
bound
to
whatever
owns
the
IP.
B
There
is
no,
as
far
as
I'm
aware,
there
is
no
requirement
for
anything
called
a
load
balancer
to
have
a
single
IP
different
infrastructures.
Will
you
know
slice
they're,
seeing
in
many
different
ways
some
providers
will
use.
You
know
anycast
IPS,
which
will
choose
a
balancing
and
you
can
think
of
the
terminology.
Load
balancer
is
kind
of
used
at
a
variety
of
different
levels.
Right
so
I
take.
D
D
You
know
I
agree
with
you,
but
I
think
what
your
talk
I,
think
what
you're
talking
about
is
this
a
virtual
server?
If
you
look
at
many
different
load,
balancers
a
front-end
or
a
virtual
server
I
mean
I
we're
using
any
IP.
In
fact
right
and
with
an
H
a
proxy,
you
would
have
multiple
bind
statements
with
multiple
front
ends
in
each
one
of
those
is
what
you
could
call
that
a
little
balance,
because
that
front
end
is
gonna,
have
back
ends,
but
I
could
also
say
that
H,
a
proxy
itself
is
the
load
balancer.
F
D
Important
distinction
because
the
routes
have
to
be
bound
to
the
front
end
and
if
the
front
end
isn't
is
the
listener
is
that's
another
way
to
say?
Is
the
front
end
the
listener
or
the
front
end
the
Gateway
to
today,
because
the
way
you've
got
routes
that
the
front
end
is
the
Gateway.
But
you've
also
got
addresses
on
the
listeners
which
make
those
look
like
the
the
front
end.
E
E
A
user
because
sorry,
no
one
else,
areas
have
any
content
of
confusion
and
the
names
are
not
very
clear
but
from
a
user
point
of
view,
it's
very
clear
I
mean
they
want
to
have
a
request,
go
into
a
particular
IP
that
they
know
and
they
control
a
particular
port.
Like
my
sequel,
port
and
all
they
care
about.
Is
that
somehow
we
make
it
happen?
Make
that
if
the
requests
go
to
this
port
and
in
this
address
it
flows
where
they
wanted
to
go
I
totally.
D
Agree:
I
totally
agree
it
shouldn't
matter
to
the
user,
but
you
can't
make
it
happen
if
the
routes
are
on
the
Gateway
and
in
the
gateway
is
subject
to
multiple
IP
addresses,
because
the
routes
like
a
TCP
route
shouldn't
have
to
know
about
the
IP
address,
because
the
route
should
be
portable
and
be
able
to
port
so
many
downstream
things.
Otherwise,
the
route
is
specific
and
at
that
point,
that
piece
of
information
should
be
moved
to
the
listener,
because
it's
actually
part
of
the
listener
construct.
F
D
D
F
F
So
the
way
one
could
see
possibly
is
you
have
one
gateway
for
a
one
IP
address.
You
know
the
implementation
being
on
load
balancer
of
some
kind.
We
can
keep
us
back
on
the
site
for
now,
so
we
have
gateway
one
gateway
to
and
the
routes
that
associate
with
these
gateways,
implicitly
assume
that
they
are
receiving
traffic
from
those
IP
addresses
right.
I
would.
D
E
E
C
D
I'm
saying
that's:
that's
the
problem,
though,
like
semantics
matter,
when
you're
trying
to
understand
this
and
there's
a
bunch
of
contradictory
information,
so
the
gateways,
the
gateway
status
doesn't
have
an
IP.
It's
got
listeners
and
listeners,
look
like
front
ends
or
virtual
servers
because
of
the
way
everything
is
written
in
document
today.
If
you,
if
you
wanted
to
make
this
look
like
something
that
is
familiar,
the
Gateway
itself
should
have
one
or
more
IP
addresses,
and
the
listener
should
just
be
ports
like
that.
D
B
B
Talking
about
virtual
servers
and
trying
to
get
the
technology
clear
in
it
and
we
I
think
a
lot
of
us
went
through
a
similar
process
that
you're
experiencing
now
Andrew
I.
Think
originally,
when
the
original
proposal
I
think
people,
people
were
thinking
of
gateway
in
in
a
way
that
I
think
traditionally
use
you
see
like
a
virtual
server,
so
I
think
Gateway
is
probably
the
closest
thing
that
you
can
mentally
map
to
to
a
virtual
server
in
the
sense
of
like
httpd
or
nginx.
B
D
C
I
yeah
and
I
added
that
sorry
do
I
just
want
to
give
some
background
before
is
I
added
this
link,
because
this
virtual
host
concept
that
we
discussed
I
guess
about
a
month
ago.
There
was
some
discussion,
I
think
around
the
issue
that
you're
presenting
here,
and
that
is
how
do
we
support
TCP,
because
currently
you
know
we're
using
layer.
C
Seven
constructs
to
be
able
to
have
a
you
know,
a
gateway
forward,
that
traffic
to
the
appropriate
route
and
TCP
doesn't
have
those
l7
semantics,
and
it
was
a
brief
discussion
we
had
and
what
it
was
around.
Was
you
know
what?
If,
since
since
we
can't,
you
know,
use
these
look
all
seven
constructs
for
TCP
what
if
we
were
able
to
take?
C
What
are
we
were
able
to
take
that
request
and
basically
do
a
look-up
on
the
IP
and
say?
Oh,
this
IP
belongs
to
foo.example.com,
and
this
gateway
has
a
configured
domain
of
example.com,
and
this
is
so
we're
almost
taking
that
layer.
Seven
information
right
that
request:
that's
coming
in
and
say:
oh
this
is
you
know
this
is
TCP
performing
a
TCP,
binding
action
and
I
need
some
kind
of
l7
information.
C
D
D
You
said
that
adhere
to
I
forget
which
RFC
it
was,
but
with
the
exception
that
it
does
not
allow
like
P
addresses
I
remove
that
because
there
may
not
be
an
F
QD
in
here
it
may
only
be
IP
addresses
and
so
like
yeah,
yeah
and
I
didn't
know
if
that
was
cific
like
a
requirement
for
the
spec,
but
I
didn't
see
that
anywhere
else.
C
E
E
We
need
to
be
reflect
and
I
think
focus
is
only
placed
with
one
approach:
I,
don't
care,
which
one
and
a
related
problem
is
that
the
user
may
have
an
existing
IP
from
a
pool
or
whatever
that
you
want
to
specify
here
once
this
gateway
to
be
a
scientist
IP
and
that
we
need
to
be
again
listener
gateway
somewhere
needs
to
be
specified.
So
why
one
way
or
another
psyches
will
be
part
of
the
replace
that
missing
then
it's
about
probably
and
then,
if
they
can
be
matched
and
they
can
be
used
in
his
API.
D
D
Think
of
a
gateway
as
your
virtual
server
right,
you
didn't
say
those
words,
but
that's
what
I
heard
and
if
that's
the
case,
then
I
think
it
makes
sense
to
have
like
you
have
a
one-to-one
relationship
on
a
listener
with
an
eye
with
an
address
and
a
a
port
and
I
think
that
has
to
change
right
like
the
addresses
should
either
be
on
the
gateway
construct
or
like
that.
That's
where
that
one-to-one
relationship
and
that's
throw
me
off,
does
that
make.
B
Are
going
to
be
able
to
support
that,
and
some
are
not
gonna,
be
able
to
support
that
right.
So
I
think
it's
specified
as
optional
in
in
the
comments
there,
but
we
could.
We
probably
should
make
that
I.
Think
there's
probably
work
to
do
in
in
exposing
different
features
that
different
implementations
can
can
support
in
the
API,
because
clearly,
like
not
a
clearly
that
that
feature
is
easier
for
a
cloud
provider
to
implement
than
someone
doing
on
premium
for
structure.
So.
D
D
D
Except
that
goes
back
to
the
Gateway
being
the
virtual
server
and
I
would
say.
Well,
then,
why
had
the
address
on
the
listener
at
all?
When
does
it
ever
make
sense,
Devin
listener,
with
an
address
and
a
single
port
that
makes
the
Gateway
look
more
like
the
load
balancer
with
multiple
virtual
servers,
I
guess,
I'm
struggling.
D
It
so
if
you
think
about
it
that
way,
then
if
you
want
to
have
a
load
balancer
that
says,
I
have
an
IP
address
of
1
2,
3,
4
and
I'm.
Listening
on
ports,
80,
81
and
82
right,
so
you're
gonna
have
a
gateway
with
3
listeners
they're
each
gonna
have
an
address
of
1
3,
3
4
and
the
only
difference
is
one
of
them's
got.
A
record
of
81
is
gonna,
be
81.
E
But
the
ones
that'll
be
confusing.
I
mean
service
with
what
this
typically
design
you
connect
to
I
equal
import,
it's
kind
of
already
flapping
as
a
client
and
as
a
user
mind,
so
I
deal
with
multiple
ports.
It's
also
confusing
for
many
users,
because
what's
how
many
different
services,
you
don't
have
same
singing
well.
D
E
D
D
E
D
D
C
D
E
D
D
A
D
For
me
like
well
I,
guess
it's
up
to
the
I'm
gonna.
Do
my
magic
anyway.
Do
you
think
I'd
say
it's
up
to
the
controller
I
mean
yeah.
I
would
say
that
your
protocol
should
probably
be
specific
to
your
port
and
you
might
want
to
port
construct.
I
know
you
probably
don't
like
that,
but
yeah
or
just
say:
if
you
have
multiple
ports,
then
you
have
to
assume
it's
TCP
or
something
like
that.
D
I,
don't
know
it
still
doesn't
solve
the
real
issue
and
in
fact,
in
fact
that's
why
I
like,
even
without
this
change,
I
still
doesn't
help
because
totally
I
have
to
just
drop
the
service
into
the
extension
because
I,
don't
you
know
why?
Because
of
what
denyen
was
saying
earlier,
there's
no
port
mapping
I
have
to
go
to
the
service
for
the
port
mapping
today
anyway.
D
D
D
Tell
me
like
I,
did
this
just
to
organize
my
thoughts
for
this
call.
I
think
this
is
probably
not
nearly
as
helpful
as
issues,
and
maybe
what
would
be
helpful
to
me
is
if
people
who
do
know
what
they're
doing
here
could
take
a
look
at
this
and
just
out
of
comments,
say:
hey
I
think
we
should
create
an
issue
called
this
for
this,
or
this
isn't
an
issue.
I
want
to
make
sure
that
the
issues
that
get
created
makes
sense
to
be
created,
and
it's
not
just
like
one
bit.
D
A
That
sounds
good,
yeah,
I
guess
anyone
who's
on
the
call
has
ideas
or
ways
these
could
be
translated
to
issues,
leave
comments
or
just
thoughts
in
general.
This
seems
like
a
good
starting
place.
What
we've
done
for
other
proposals
of
this
scale
before
is
we've
started
in
Docs
and
had
a
bunch
of
comments
and
then
transition
to
issues
as
it
made
sense
so
and.
D
A
No
thanks
for
sharing.
There
was
one
issue
that
we
didn't
have
enough
time
for
with
dannion,
but
I
want
to
at
least
mention
the
idea
which
I
think
if
we
can
push
this
to
the
next
meeting,
but
just
so
we're
thinking
about
it
and
we
have
come
prepared.
The
question
has
been
proposed
if
we
could,
instead
of
we
creating
traffic
split
use,
what
was
in
SM
I
already
defined,
but
I
don't
want
to
go
too
far
down
that
since
we're
already
out
of
time
yeah
we
just
pumped
up
to
next
week,
all.