►
From YouTube: Service APIs Meeting (EMEA Friendly Time) 20200723
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
Record
this
is
service
apis
meeting
for
july
23..
A
I've
got
a
few
things
on
the
agenda
and
before
we
get
too
far
into
this,
I
just
wanted
to
provide
a
quick
recap
of
what
we
discussed
in
office
hours
yesterday.
Jonathan
barry
had
a
great
background
on
and
and
rationale
for,
supporting
more
protocols
than
we
currently
do,
obviously
not
for
v1
alpha
1,
but
he
presents
some
great
use
cases
for
additional
protocols
and
how
we
might
want
to
keep
them
in
mind.
A
He
shared
the
stock
in
slack
and
had
a
a
great
bit
of
background
yesterday
as
well
around
this.
The
link
is
in
the
agenda
as
well
as
slack,
so
I
I
recommend,
taking
a
look
at
that.
I
don't
think
this
is
anything
we
want
to
try
and
include
for
v1
alpha
1,
but
I
think
it's
worth
at
least
keeping
this
in
mind
as
we're
thinking
about
implementation,
making
sure
that
we
have
extension
points
for
additional
protocols
and
then
the
the
second
thing
that
we
spent
a
great
deal
of
the
meeting
on
was
conflict
resolution.
A
This
is
a
dock
that
I
shared
yesterday
and
we
still
have
some
things
that
we
haven't
covered
here.
So
if
we
have
time
I
may
come
back
to
this
later
on
today,
but
we'll
just
see
how
the
discussion
goes,
but
with
that
I
think
james
has
the
first
thing
on
the
agenda,
which
is
an
issue
he'd
raised
and
I'll
hand
it
over
to
him
to
give
a
little
bit
more
background
here.
B
Good
morning,
yes,
this
is
something
we
have
someone
in
vmware
implementing
some
parts
of
the
spec,
but
for
different
reasons:
they're
only
implementing
the
l4
part,
so
this
is
using
gateway
sort
of
as
an
alternative
to
service
type
load
balancer.
B
So
the
question
was:
is
that
you
know
conformant,
I
I
think
so,
but
there's
not
really
any
language
in
the
spec.
That
kind
of
you
know
spells
that
out
clearly,
and
so
I
wondered
what
people's
general
opinion
was
and
whether
we
would
need
maybe
specific
some
kind
of
capabilities
or
some
kind
of
specific
errors
for
these
sorts
of
implementations.
A
Yeah
thanks
for
raising
that
issue.
That's
really
interesting
and
a
great
point.
I
imagine
there
will
be
plenty
of
implementations
that
only
support,
l4
or
l7,
and
and
maybe
it
could
be
further
defined,
as
some
implementations
will
only
support
a
subset
of
protocols
whatever
that
happens
to
be,
and
in
that,
in
that
case
it
almost
feels
like
we
need
to
take
our
initial
concept
of
conformance
and
further
scope.
A
It
like
most
of
the
same
things,
apply
around
conformance,
but
some
may
be
protocol
specific,
and
if
those
are
protocols,
you
know
like
some
way
to
say
that
this
implementation
is
compliant
with
service
apis
for
the
following
protocols.
A
C
I
will
say
this
is
somewhat
related
to
the
the
versioning.
The
implementation
version
that
we
discussed
a
couple
weeks
ago.
In
that
I
I
feel
like
this
is
about
how
how
to
communicate
to
the
user,
which
things
are,
which
fields
are
supported
and
which
are
not,
and
then
making
that
a
standard
part
of
the
spec
in
in
which
how
that
is
communicated.
A
Good,
I'm
sorry
I
hadn't
thought
of
that
connection
at
all,
but
that's
a
that
is
a
good
point.
We,
it
would
be
helpful
to
have
that
kind
of
consistent
communication
of
this
implementation
supports
these
specific
features.
C
Yeah,
like
there
are
now,
I
know
we
kind
of
have
the
distinction
between
core
features,
extended
features
and
custom
features,
I'm
guessing
that
for
the
core
features,
that's
required
like
just
to
be
part
of
the
spec,
and
this
would
probably
then
be
for
all
the
extended
features.
Things
like
you
know.
C
Weight
might
not
make
sense
for
some
cloud
load
balancers
a
lot
of
them,
don't
support
it
and
how
is
that
communicated
in
a
sys
in
a
structured
way
and
it
kind
of
goes
beyond
just
error
signaling,
because
air
signaling
is,
it
will
error
out
when
you
go
to
apply
it,
but
maybe
there's
a
way
for
it
to
you
know
you
look
at
a
spec
to
just
get
a
spit
out
of
which
fields
are
supported
or
not
by
looking
at
a
certain
gateway
class,
or
maybe
the
gateway
class
communicates
that
in
some
way,
I'm
not
sure.
A
Yeah
yeah,
that
makes
sense,
and
I
think
what
we're
saying
is
even
beyond
just
core
and
extended.
There
are
things
that
we
have
so
far
considered
core
like.
I
think
both
http
route
and
tcp
route
are
considered
core,
but
I
think
what
james
is
saying
here
is:
you
may
want
to
consider
an
implementation
compliant
if
it
only
supports
one
of
those,
but
just
add
some
kind
of
clarification
that
it's
compliant
at
a
specific.
B
A
C
Well,
it's
just
really
about
the
ability
to
communicate
that
what
type
of
routes
are
supported
right.
You
have
a
gateway
class,
maybe
a
layer,
4
gateway
class
that
is
able
to
communicate
that
it's
only
supported
with
a
tcp
row
and
now
with
an
http
route,
and
so
that's
one
type
of
support
that
it
can
communicate.
Another
one
is
the
fields
within
those
objects.
C
A
Yeah,
so
do
we
do
we
think
we
need
something
beyond
our
current
core
and
extended
model
like
it
sounds
like
just
that
is
probably
insufficient.
A
Well,
this
this
is
a
an
interesting
issue
and
would
encourage
anyone.
Who's
interested
to
add
a
comment,
add
their
thoughts.
I
think
this
at
least
having
a
plan
here
would
be
very
helpful
as
part
of
our
v1
alpha
1
goals.
I
know
I
know
we
have
not
scoped
conformance
into
v1
alpha
1,
but
I
imagine
that
we
would
at
least
want
to
have
some
kind
of
concept
of
what
is
considered
a
what
would
be
considered
conformant.
B
A
Yeah,
that's
a
good
question,
I'm
not
I'm
not
sure
you
know,
because
so
many
storage
classes
are.
Are
you
know
different
in
in
ways
yeah
that
that's
a
good
question
I'll
have
to
look
into
that.
A
All
right:
well,
I
will
I'll
keep
that
in
mind
and
please,
if
you
have
thoughts,
go
ahead
and
leave
a
comment
and
if
there's
any
any
prior
art
here
that
would
be
great
to
reference
as
well.
A
I
I
wanted
to
move
a
little
bit
into.
I
guess
a
continuation
of
pr
and
issue
triage
here.
There's
a
couple
pr's
that
have
made
it
in
that,
I
think,
are
pretty
close.
Oh,
it
looks
like
a
danian's.
Traffic
split
is
closer
okay,
yes
I'll
I'll,
follow
up
with
that
as
well.
Awesome
all
right,
so
jeremy
filed
this
tcp
route.
Pr
and
it's
gotten
some
great
feedback.
So
far
I
and
the
last
time
that
I
checked
it
looked
like
there
was
general
agreement
on
this
and
we
have
an
approve.
A
A
Yeah,
so
that
that's
one
potential
suggestion
here,
but
that
that
could
be
done
as
a
follow-up
jeremy
did
you
have
any
thoughts
on
this?
It
seems
like
it's
either
ready
or
just
about
ready.
D
To
me
yeah,
I
that's
my
take
is
that
some
they're
very
good
comments
and
we
should
do
them
in
the
follow
up.
It
feels
ready
to
me
because
there's
some
of
these
some
of
the
comments
need
more
discussion.
I
think,
then
you
know
the
basics
are.
Are
there.
B
Hey
jeremy,
with
the
sni
field,
was
that
intended
to
do
to
be
for
implementing
tls
pass
through
in
the
way.
D
Seductive
it
was,
it
was
intended
mainly
for
matching,
which
is
what
I
think
a
couple.
Other
docs
had
kind
of
mentioned,
but
it
was
mainly
in
there
because
we
had
mentioned
a
few
times
and
I
wanted
to
start
a
conversation
and
the
feedback
was
let's
hold
on
that
conversation,
which
I'm
also
good
with.
B
D
Clarify
yeah,
I
I
didn't
actually
expect
that
to
merge
with
this
I
just
figured
it
would
be
good
to
kind
of
call
out.
Do
we
want
to
do
that,
but
I
know
your
comment
was
valid.
Like
we're
already
discussing
that
in
listeners,
I
suppose
root
match
it
might
make
sense
as
well,
because
we
can
because
the
listener
can
have,
can
match
multiple
names
right,
but
that
should
probably
be
left
for
a
follow-up
anyway.
D
A
Cool
great
well
yeah,
if
there's,
if
there's
no,
no
hesitation
for
any
anyone,
I'm
happy
to
add
the
final
lgtm
and
just
get
this
one
in.
D
Awesome
one
one
related
question:
do
we
want
like
a
udp
route.
A
Would
that
would
that
look?
I
don't
know
that
we've
discussed
in
detail.
What
that
would
look
like.
Do
you
imagine
it
being
very
similar
to
tcp
route?
I
do
yeah.
D
Yeah,
I
think
I
mean
I
basically
think
it
would
be
an
exact
copy
of
tcp
route
as
as
committed
right
now.
D
D
Right
now
it,
but,
but
until
we
add
sni
right,
it's
only
actually
matching
on
some
some
extension.
So
an
udp
route
could
be
the
same,
but
yeah
it
would
be
like
matching.
Doesn't
I
don't
know.
A
Yeah
I
mean
I
don't
feel
strongly
about
this
one.
The
only
little
bit
of
hesitation
I
have
is.
I
know
that
harry
and
damian
have
been
working
towards
a
number
of
changes
towards
this
concept
of
route
actions
and
that
may
result
in
changes
being
needed
to
not
just
tcp
route.
Well,
not
just
a
http
route,
but
maybe
tcp
route.
D
My
gut
would
be
that
those
changes
would
either
not
apply
or
they
would
apply
in
the
exact
same
way
for
most
of
them.
So
maybe
it's
not
too
much
extra
effort,
I'm
I'm
also
like
yeah.
I
don't
know
I
could
I'd
be
happy
to
put
up
a
pr
for
that
and
we
can,
you
know,
discuss
it
or
I'd,
be
happy
to
wait
if
we
think
that's
better
as
well.
A
E
With
the
with
the
udp
route,
would
it
make
sense,
jeremy
after
you
create
the
pr
maybe
to
post
something
on
the
mailer?
Just
because
it's
a
topic
that
hasn't
been
discussed-
and
I
don't
know
if
maybe
a
pr
would
get
enough
attention-
that's
why
I
maybe
mentioned
referencing
it
on
the
on
the
mailer
just
to
get
maybe
some
input
from
people
that
wouldn't
necessarily
be
flagged
by
the
pr
yeah.
That's
a
good
idea
I'll!
Do
that
yeah
good
idea
thanks.
I
appreciate
that.
A
E
A
I
I
think
this
isn't
a
pretty
good
spot,
but
I
I
like
jane's
suggestion
here,
so
I
don't
think
there's
anything
to
do
as
a
follow-up
here
other
than
just
remind
anyone
if
they're
interested
in
this
specific
bit
of
copy
or
documentation
to
take
a
look
and
make
sure
it
makes
sense
to
them.
A
But
I
I
think
I
think
this
makes
sense
here
and
the
last
one
is
going
to
be
a
larger
one
which
is
damian's
update
around
traffic
splitting
I
saw
I
saw
that
you
had
pushed
an
update
here,
but
I
wasn't,
I
hadn't
actually
gotten
a
chance
to
take
a
look
at
it.
Yet
danian
is
this
ready
for
another
round
of
review.
E
It
is,
and
just
a
little
background
for
others,
and
as
you
can
see
this,
this
has
been
around
for
a
while
and
and
as
of
last
week,
the
actions
proposal
was
reviewed.
We
got
feedback
and
the
action.
The
actions
proposal
consists
of
multiple
sections
to
it,
and
one
of
the
sections
was
around
pluralizing
the
forward
to
target
and
the
consensus
that
I
walked
away,
or
I
walked
away
with
the
consensus
that
the
feedback
last
week
was
that
this
makes
sense
to
do.
E
There
were
still
some
questions
about
other
parts
of
the
proposal
and
I
think
rob
you
specifically
have
spent
time
digging
into
this
pr
a
few
months
ago
and
felt
like
it
was
at
a
good
place.
But
then
we
paused
it
to
kind
of
look
at
kind
of
the
actions
more
holistically,
and
so
what
I
had
to
do
is
just
kind
of
go
back.
E
There's
a
bunch
of
merge
conflicts
that
I
fixed
and,
as
you'll
see
in
here,
it's
removing
a
lot
of
stuff
because
we're
essentially
getting
rid
of
one
of
the
api
types,
the
traffic
split
api
type
and
so
yeah
long
story
short
it'd
be
helpful
to
get
some
eyes
on
this,
because
I
imagine
that
there's
gonna
be
an
another
merge
conflict
here
in
the
near
future
if
it
doesn't
get
merged
and
it's
kind
of
a
pain
in
the
butt
to
fix
the
merge
conflicts.
With
this
one.
A
Yeah
you're
completely
right
about
those
merged
conflicts
being
annoying.
I
I
yeah.
I
immediately
noticed
this
diff.
It
took
me
a
second
to
remember.
We
have
a
traffic
split
api
type
currently,
which
obviously
is
not
an
intended
thing
going
forward.
A
So
I'm
glad
that
you've
you've
taken
the
effort
to
remove
that
here
and
also
it
seems
like
this
change
is
now
like
you're,
saying
just
pluralizing
forward
to
and
adding
weight
as
a
forward
to
target
right.
E
And
I
think
right
here,
line
300
that
you're
seeing
here
is
probably
where
we
need
the
closest
eyes
on
is
you
know
specifically
313
to
315?
You
know,
does
that
make
sense
and
how
we
deal
with.
If
you
know,
only
one
target
ref
is
specified
that
we
ignore
the
weight,
since
we
really
don't
need
the
weight,
since
it's
just
a
single
target
right
and
if
multiple
target
refs
are
specified
without
weight.
E
So
I
didn't
include
that
use
case
because
I
didn't
want
to
potentially
over
complicate
the
pr,
but
maybe
if
we
have
time
that
could
be
something
worth
discussing,
would
it
make
sense
to
just
include
a
default.
E
Well,
so
in
the
default,
so
the
use
case,
let's
say:
we've
got
three
target
refs
and
target
rough.
One
is
a
weight
of
30.
target.
Ref
two
is
the
way
to
70,
and
then
we
say,
let's
say
a
default
is
one,
so
the
third
one
isn't
specified
and
it's
just
one.
So
it
would
basically,
you
know,
get
one
percent
of
the
traffic
roughly
right,
yeah.
A
Yeah-
and
I
think
that's
fine,
because
as
long
as
you,
I
wouldn't
want
a
default
just
to
be
implied
with
the
controller
implementation,
but
as
long
as
we're
using
an
actual
crd
default
here,
so
that
one
it's
it's
well
documented
in
two.
Whenever
they
view
the
route
they'll
see.
Oh,
this
has
a
weight
of
one
or
you
know
like,
because
it
will
actually
be
an
attribute
that
is
set.
E
That
yeah,
okay,
good,
rob
or
or
jeremy,
if
you
wouldn't
mind,
just
making
a
note
there,
either
in
the
pr
line
315,
because
I'd
like
before
pushing
another
commit
that
addresses
that
use
case.
I'd
like
to
give
others
a
chance
to
take
a
look
as
well
and
yeah,
I'm
sure
like
them
not
to
have
to
go
through
the
same
feedback.
A
Great
this
is
exciting.
I
am
glad
to
see
progress
on
this
and
I
I
agree.
I
think
this
was
the
the
one
part
that
I
think
everyone
agreed
on
with
the
actions
proposal
we
discussed
last
week,
and
so
it's
great
to
see
it
actually
translated
into
implementation
so
quickly
so
great,
and
I
know
you've
been
sitting
on
this
pr
for
a
long
time.
So
thank
you
for
your
patience.
Yeah.
E
No
worries.
Well,
you
know
we
went
to
that
part
where
it's
like
hey,
let's
hit
the
pause
button,
let's
look
at
how
a
lot
of
these
different
actions
come
together.
So
I
think
that
was
smart,
that
we
did
that
and
now
that
you
know
we've
come
to
consensus
on
this.
I
definitely
want
to
get
it
get
it
merged
because,
like
I
said,
it's
kind
of
a
pain
in
the
butt
to
deal
with
the
merge
conflicts
so
yeah
awesome.
I
appreciate
the
feedback
like
I
said
I'll.
A
Okay.
Are
there
any
other
pr's
or
issues
that
we
should
cover
here?
A
I
wouldn't
have
anything
yes,
and
I
noticed
I
ran
into
this
personally
as
well
that
cogen
as
it
exists
right
now.
I
think
it's
specifically
the
proto
stuff
is
broken
when
you're
not
inside
gopath.
I
think
that's
that
that
the
the
the
real
scope
of
this
is
go
path
related
right,
like
if
you're
using
gopako
modules
and
happens
to
still
be
in
go
path.
It'll
work,
it's
just
if
you're
outside
of
the
expected
path.
It
won't
something
like
that.
A
Yeah,
but
I
it
looks
like
john,
you
are
aware
of
this
at
least.
F
Yeah,
I
I
briefly
looked
into
it
and
I
struggled
to
to
fix
it.
I
didn't
dedicate
a
bunch
of
time,
but
if
someone
does
know
off
the
top
of
their
head,
that
would
be
useful.
If
not,
I
can
dig
into
it
some
more.
A
Yeah
yeah:
this
is
one
of
those
classic
things
where
it
works,
because
I've
been
using
go
so
long
and
I'd
well,
not
so
long,
but
whatever
I
just
have
all
my
stuff
and
go
path
that
it
didn't.
Even
I
didn't
even
run
into
it
until
I
heard
from
someone
else
that
wasn't
necessarily
using
gopath
the
same
way
but
yeah
so
yeah
that
that
makes
sense.
A
Okay!
Well,
I
I'll
move
on
because
there's
a
lot
that
we
could
cover
in
this
conflict
resolution,
but
I
wanted
to
just
because
we're
ideally
a
month
or
so
out
from
a
v1
alpha,
1
release.
A
I
wanted
to
go
back
through
this
this.
I
think
we
can
almost
safely
move
to
completed
traffic
splitting.
I
think
we're
about
to
move
to
completed
conflict
handling,
we're
getting
a
lot
of
progress
on
and
we'll
go
there
next
damian.
I
I
assigned
you
because
you
had
a
pr
around
cleaning
up
status
and
conditions,
but
I
don't
know
that
this
is
really
exhaustive
of
the
status
and
conditions
a
bit,
and
I
guess
this
is
more
related
to
polarity.
A
So
I
I
didn't
need
to
volunteer
you
for
this.
If
you'd
rather
not
take
this
on,
but
you
just
happened
to
get
this
because
you
were
working
in
the
vicinity
of
this.
E
Yeah
no
yeah!
Let
me
let
me
pick
that
back
up.
Okay,
as
you
know,
as
I
mentioned,
I
was
gonna
focus
on
getting
that
traffic
split
pr
back
in
shape,
and
so
I'd
like
to
the
the
time
I
do
have
I'd
like
to
make
sure
that
gets
in
which
I
think
we're
in
a
good
space
for
that
so
yeah.
A
Great
thanks
and
I
know
bowie's
been
doing
some
work
around
service
level
config
and
he
has
a
doc
that
we
talked
through
in
a
previous
meeting
that
I
can't
remember
when
it
looks
like
we
haven't
gotten
a
ton
of
comments
on
it.
I.
A
That
just
took
a
while
to
load.
So,
yes,
we
should,
I
believe,
he's
still
working
on
that,
but
I'll
thank
him
afterwards,
just
to
be
sure-
and
that
leaves
tls
config,
which
I
know
harry
had
been
doing
some
work
around.
A
So
maybe
I
don't
want
to
be
too
optimistic
here,
but
maybe
this
could
actually
happen
sometime
in
august,
we'll
see,
but
I'd
like
to
keep
on
pushing
towards
that
goal.
I
know:
bowie
has
created
a
project
board
with
a
v1
alpha
1
milestone,
but
I
think
we
need
to
change
the
permission.
So
more
people
can
actually
modify
that
board
because
it
may
just
be
him
right
now,
but
we
will
get
this
more
organized
and
I
think
we're
not
too
far
away
from
an
initial
alpha
release
here.
A
We
made
it
through
a
lot
of
these
yesterday
and
office
hours
I
just
kind
of
as
more
of
a
a
working
session.
I
wanted
to
highlight
some
of
them.
We
don't
need
to
go
through.
We
obviously
don't
have
time
to
go
through
all
of
them
in
the
final
10
minutes
of
this
meeting,
but
I
think
there
are
some
that
could
be
could
be
relevant
and
we
have
a
some
people
that
weren't
in
office
hours
that
I
wanted
to
get
some
broader
feedback
from.
A
So
one
of
the
discussion
points
that
actually
went
the
direction
I
didn't
anticipate
was
I
had
thought
that
at
least
in
some
cases
gateway
listeners,
both
matching
the
same
host
name
could
result
in
a
conflict.
A
And
they
both
have
listeners
matching
example.com.
I
had
at
least
initially
assumed
that
that
would
be
a
conflict
that
we
would
want
to
either
consider
invalid
or
prevent
in
some
way.
That's
it.
You
know.
I
raised
the
point
that
okay,
maybe
this
is
not
as
much
of
an
issue
for
implementations
that
correspond
with
you,
know,
say
a
cloud
load
balancer
and
you
can
just
point
dns
at
whatever
you
want
and
it
will
resolve
itself
maybe,
but
I
I
had
thought
there
would
still
be
potential
conflicts
elsewhere.
A
I
think
it
was
james
who
mentioned
well.
If
you
did
run
into
this
situation,
it
may
actually
be
desirable
to
just
round
robin
between
the
two
gateways.
Instead.
A
I'm
going
to
go
ahead
and
assume
that
silence
means
that
nobody
thinks
this
should
be
a
conflict.
I
I
will
look
for
some
broader
feedback
here.
What
I'm
really
trying
to
avoid
is
not
treating
something
as
a
conflict.
That
really
is
an
issue
for
a
certain
subset
of
implementations,
and
if,
if
there
are
some
implementations
that
really
cannot
handle
this
I'd
hate
to
not
at
least
provide
a
consistent
way
for
them
to
to
deal
with
this,
but
it
may
be
that
everyone
can
either
can
can
handle
this
in
some
way.
That
is
relatively
consistent.
A
A
very
similar
concept
was,
if
you
have
gateway
listeners
within
a
gateway
that
both
match
a
hostname,
and
I
think
the
option
there
that
we
thought
made.
The
most
sense
was
actually
validate
uniqueness
of
the
host
name,
protocol
and
port
combination,
and
that
would
because
you
can
obviously
match
the
same
hostname
if
it's
going
to
be
a
different
port
or
protocol,
but
at
least
for
if
you
have
the
same
host
name
protocol
import.
A
We
do
want
to
prevent
that
so
adding
some
kind
of
validation
around
that
can
prevent
this
conflict
from
ever
being
an
issue,
and
I
should
go
back
up.
I
didn't
really
cover
the
guiding
principles
here,
but
from
before
we
really
want
to
prefer
not
to
break
things
that
are
already
working,
and
if
we,
if
there
is
a
conflict
that
we
can't
prevent
with
validation,
we
want
to
provide
a
consistent
experience.
A
A
You
would
hate
to
have
that
happen,
so
just
providing
a
consistent
experience
when
conflicts
occur
and
then
providing
clear
path,
whether
it's
in
status
or
whatever,
some
clear
communication
which
path
has
been
chosen
in
a
conflict
resolution
and
then
probably
the
most
standard
and
generic
concept
out
there.
A
A
So,
yes,
those
were
the
guiding
principles.
I
identified
this
doc
by
the
way
is
open
to
not
just
comments
but
editing.
So
if
there
are
additional
conflicts,
you
think
of
please
add
them
here.
If
there
are
additional
additional
options
for
how
we
could
resolve
an
issue,
please
add
them
to
any
specific
issue.
I've
identified
here,
yeah
anything
that
you
might
think
about
here.
A
A
One
of
the
things
that
I
think
is
going
to
get
messy
and
maybe
could
use
a
little
bit
more
discussion
is
if
there
is
some
portion
of
a
route
that
is
invalid.
Well,
other
routes
are
valid
for
the
same
gateway,
and
so
I
think
I
think
we
know
that
we
want.
A
A
But
I
I
am
very
open
to
feedback
here.
If
anyone
has
ideas
around
what
that
might
look
like
that'd
be
great
yeah,
I'm
trying
to
think
we've
only
got
a
few
minutes
left.
A
Of
course,
I
added
the
the
use
case
here
of
multi
multiple
gateways
targeting
the
same
route,
which
I
think
is
valid,
but
we
could
use
some
better
communication
around
that
and
okay,
this.
This
was
a
a
large
topic
that
I
likely
don't
have
enough
time
to
cover
here,
but
I'm
proposing
a
relatively
significant
change
to
allowed
gateway.
Namespaces
I've
thought
about
it
a
lot.
This
was
a
a
change
that
I
initially
proposed
and-
and
now
I
hate
it-
so
you
know
here
we
are
but
allowed
gateway.
A
The
way
it
is
currently
spec
is,
if
you
change,
which
namespaces
are
currently
allowed,
what
what
is
mostly
written
is
any
gateways
outside
of
those
namespaces
would
immediately
become
invalid
and
should
no
longer
be
implemented,
which,
obviously,
if
you
mistakenly
change
a
selector
in
this
case,
you
would
end
up
with
just
a
really
messy
situation
of
taking
all
the
things
down,
and
obviously
it's
really
messy
for
an
implementation
to
make
that
change.
A
So
my
proposal
here
is
to
do
away
with
this
concept
and
and
make
it
instead
a
something
that
is
validated
on
create,
so
you
can
still
limit
where
gateways
are
created
with
a
given
gateway
class,
but
that's
it
this.
This
only
applies
to
where
gateways
can
be
created
of
that
class.
A
So
that's
something
we
can
handle
in
validation.
You
get
really
good
user
feedback
and
then
admins.
If
they
really
want
to
clean
up
old
resources
old
gateways,
they
can
do
it
intentionally
and
in
a
safe
way,
so
they
would
intentionally
remove
gateways
instead
of
accidentally
changing
allowed
gateway,
namespaces
and
obliterating
all
their
gateways
unintentionally
or
accidentally.
A
That's
that's
a
fairly
significant
change,
though,
and
I
would
like
some
more
eyes
and
feedback
on
this
proposed
change
because
it
is
yeah.
It
is
significant.
A
G
G
G
A
Okay,
well
it
it
sounds
like
this
is
a
reasonable,
reasonable
approach
to
to
go
further
with
I'll
say
that
one
of
the
high
level
things
that
themes
I'm
getting
out
of
this
is,
we
really
should
have
some
kind
of
validation
web
hook.
Some
of
the
validation
I'm
proposing
here
is
more
complicated
than
we
can
get
out
of
crd
validation.
A
E
Rob
can
we
talk
a
little
bit
more
about
the
loud
gateway
name,
spaces
yeah.
I
just
want
to
make
sure
I
understand
yeah
what's
going
on
so
what
you're
proposing
is
that
when,
let's
say
we
create
a
gateway
class
and
we
specify
a
lot
of
gateway,
namespaces
and
specify
the
namespaces,
that
gateways
can
be
created
right.
G
A
No,
no,
the
contrary,
you
can
make
you
can
change
that
whenever
you
want
it's
just
not
going
to
affect
existing
gateways,
because
right
now
the
really
scary
ramification
of
this
attribute
is
changing.
It
could
invalidate
a
huge
list
of
gateways,
and
that
feels
very
destructive
and
against
the
concept
here
of
prefer
not
to
break
things.
E
Yeah,
no,
it's
it's
a
good
use
case
that
you've
kind
of
uncovered
here
so
yeah.
I
agree
that
is
just
too
destructive
to
allow.
A
All
right,
well,
yeah
that
this
has
been
very
helpful
feedback
again,
if
you
think
of
any
any
other
things
that
could
potentially
conflict.
Even
if
you
don't
have
potential
solutions
for
them,
please
add
them
to
that
doc
or
if
you
have
feedback
on
any
of
the
proposed
solutions
or
some
of
them
that
just
have
a
few
different
options.
A
I
would
love
to
get
some
more
feedback
in
that
talk,
but
yeah
we
are.
We
are
actually
past
time,
so
thanks
so
much
to
everyone
for
their
for
their
time
and
excited
to
see
this
project
moving
along
have
a
great
rest
of
your
week.