►
From YouTube: Service APIs Office Hours 2020722
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
as
office
hours
for
July
22,
and
it
looks
like
we've
got
plenty
to
talk
about
now.
I'll
get
started
actually
Jonathan.
It
looks
like
here
on
the
call
hi
you'd
mentioned
in
slack,
that
maybe
we
should
look
at
supporting
other
protocols
and
you
referenced
this
doc.
Do
you
want
to
give
us
a
bit
of
a
background
on
what
on
this
proposal,
yeah.
B
But
the
the
TLDR
is
the
cladding
world
is
optimized
for
HD,
which
is
which
is
awesome
and
important
that
if
you're
trying
to
build
you
know
high
performance
Heist,
you
know
high
scalability,
reliable
services
with
other
types
of
protocols.
It
becomes
a
little
bit,
dicey,
ya,
end
up
rolling
a
lot
of
your
own
things
and
working
around
the
built-in
primitives
and
so
I've
thought.
B
Hey
I've
been
hearing
about
the
the
new
services
work
and
I'm
super
curious
and
then
I
said
there's
office
hours
I
was
like
hey,
may
raise
awareness
and
see
if
there's
anyone
who's
interesting,
this
topic
or
maybe
I,
can
help,
contribute
and
drive
the
the
direction
in
in
subsequent
releases,
and
so
what?
When
I
say,
new
protocols?
You
know
HTTP
HB,
2,
HT
ry1
in
IO
team.
It
would
be
co-op
or
MQTT
in
gaming
or
there
might
be
some
other
sort
of
game.
B
State
protocols
in
telephony
might
be
with
RTC,
so
kind
of
reeling
back
to
my
TL
DR.
This
doc
is
a
is
a
collaboration
with
a
bunch
of
different
folks,
including
some
contributors
to
different
projects
across
the
CN
CF
landscape,
as
it
relates
to
specifically
networking
type
stuff
workload
and
just
surveying
a
particular
project
that
might
be
really
relevant
or
I
spec
or
a
kept
and
say
hey.
This
would
actually
improve
things
because
it
does
XY
and
Z,
or
this
project
is
not
prioritizing.
B
Non-Hp
protocols,
that's
cool
and
you
know
let's
keep
track
of
that
kind
of
thing,
and
so
I
rambled,
probably
probably
under
than
I
planned
on.
But
one
I
just
want
to
bring
this
awareness
of
alternative
protocols
and
there's
a
growing
interest
among
different
different
verticals
and
industries
and
seeing
if
there's
something
relevant
here
and
to
look
at
and
and
can
maybe
even
contribute
use
cases
for
the
evolution
of
the
services.
Api.
A
Yeah
thanks
for
that
background,
that's
it's
very
helpful
and
and
I
know,
like
we've
already
discussed,
that
the
scope
for
v1
alpha
one,
who
likely
won't
include
any
of
these
additional
protocols
but
I,
think
it
I
think
it's
useful
to
at
least
be
thinking
about
how
server
safety
eyes
could
potentially
support
more
protocols.
Then
we,
you
know,
then
just
the
basic
TCP
UDP
HTTP
https.
You
know
the
very
basic
protocols
that
we've
had
initial
designer
support
for,
if
you
mentioned
here
further
down
in
the
dock,
some
references
to
SMI
some
references
to
envoy.
B
It's
sort
of
this
incremental
sort
of
like
life
of
a
packet.
If
you
will
for
Googlers
in
the
room
like
myself,
you
know
if
you're
building
a
like
a
service,
mesh
implementation
and
you
want
to
have
observers,
observability
or
circuit
breaking
or
even
just
you
know,
integration
it.
He
often
aussie
layer
of
a
particular
service
mesh,
specific
calling
out
ongoing
and
SMI.
B
There
are
explicit
points
of
extension,
I
think
that's
the
general
theme
I've
been
picking
up
on
and
I
think
it
was
the
right
theme
of
make
the
HTTP
protocol.
You
know,
rock-solid,
have
a
bunch
of
custom
functionality
around
HTTP
and
then
leave
some
breadcrumbs
where
the
minority
protocol
implementers
can
go
ahead
and
hook
it
into
so
so,
for
example,
in
envoy
they're,
moving
towards
a
model
where
you
can
extend
through.
B
You
know,
webassembly
modules,
but
those
modules
can
kind
of
do
any
sort
of
logic
you
might
be
able
to
do
if
you
were
to
customize
the
superfast
code
base
that
allows
you
to
implement
observability
for
a
particularly
unique
protocol,
deploy
that
with
a
an
off-the-shelf
and
build
an
envoy.
You
know
your
enterprise,
supported
package,
etc.
B
So
it's
sort
of
that
spectrum
of
it's
actually
in
the
spec
and
here's
a
thing
we
want
to
spec
out
and
they'll
be
part
of
some
implementation,
or
it's
truly
just
extension
points
that
we
leave
up
to
the
implementer
to
figure
out
how
to
do
it
and
that
that's
also
true
in
other
projects
or
components
right
like
even
on
the
the
current
ingress
implementation,
doesn't
really
care
what
protocol
it
is.
But
there
are
some
conveniences
and
and
sort
of
annotation
temptations
are
wrong
word,
but
things
you
can
write
into
the
animal
file
that
says
hey.
B
A
You
know
that's
really
helpful
and
I
think
we.
We
would
probably
have
a
good
parallel
here
with
the
SMI
implementation,
you're
you're,
referring
to
the
air.
You
know
the
pattern
they
have
of
traffic
specs
being
a
one-to-one
mapping
with
protocol
would
be
very
similar
to
our
route
CRD
right
now,
which
we
have
a
TCP
route,
an
HTTP
route,
and
it
so
far
has
been
a
one-to-one
mapping
to
protocol
and
I.
A
Think
there's
space
and
I
think
that's
intentional
to
allow
custom
routes
in
the
future,
but
I
don't
know
how
I
don't
know
how
what
would
spec
that
well
actually
I'm
pretty
sure
we
have
not
spec
that
out.
It's
certainly
unwritten,
but
it
seems
like
something
like
that
would
be
fairly
easy
to
create
your
own
route
types
and
make
them
work
with
this
API
yeah.
B
Yeah
this
is
this
is
really
helpful.
Awesome,
oh
yeah
and
James
just
posted
an
example
for
this
am
I
spec
and
here's
actually
helping
out
in
this
Lac
group
that
yeah
there's,
there's
probably
the
the
foundation
and
some
of
the
cement
has
laid
down.
But
probably
details
have
to
be
worked
through
and
you
know
I'm
happy
to
contribute
more
examples,
and
maybe
even
some
concrete
ones
as
we
work
through
our
own
future
architecture.
If.
D
B
Sorry
about
that
I'm,
actually
not
an
expert
on
how
the
routes
are
implemented.
I
just
been
bringing
up
with
within
the
SMI
group.
A
E
A
F
A
specific
data,
I
do
recall
was
a
couple
months
ago
and
there
is-
or
there
should
still
be,
an
issue
in
the
SMI
spec
repo
that
talks
about
this
kind
of
overlap
between
us
and
my
spec
and
service
api's,
so
yeah
I
mean
Jonathan
is
probably
worth
digging
that
recording
up
I
could
find
it
I'll
send
it
to
you,
but
I'd
also
look
into
that
issue
and
I'm
gonna.
Look
for
that
as
well
and
post
it
in
the
chat
here.
If
I
could
find
it.
D
Where
we
are
today
in
in
the
listener,
in
the
gateway
listener,
with
regards
to
you,
know
it
extending
the
protocols
is
that
the
protocol
type
feel
is
it's
fixed.
There's
only
four
possible
values
there
today,
HTTP
https,
TLS
and
TCP,
and
we've
I,
think
there's
an
issue
and
we've
talked
about
making
those
making
that
you
know
allowing
arbitrary
protocol
type
strings
in
there,
which
could
be
something
useful
for
you
know
the
IOT
protocol
Suites,
the
other
extensibility,
is
the
routes
and
the
route
binding.
D
Experience
back
to
their
working
group
and
see
how
it
went
for
IOT
and
getting
protocols
that
layer
on
top
of
one
of
the
four
fundamental
protocol
types
you
could
do
it.
You
could
do
a
similar
sort
of
thing.
So
if
you
know
that
you
know
some
protocol
runs
over
over
TCP,
then
you
could
set
the
protocol
type
to
TCP
and
then
you
would
find
a
route
selector
with
whatever
you're
you
know.
Upper
layer
protocol
is
semantically.
B
And
I
think
that
that
makes
a
lot
of
sense
from
a
implementers
perspective
like
you
want
to
have
a
solid
layer
for
basis,
so
you
just
implement
the
layer
7
protocol
interesting
enough.
A
lot
of
the
protocols.
Are
you
pee,
pee,
on
the
IOT
side
on
the
gaming
side
and
the
telephony
side,
so
that
there
might
be
a
gap.
D
Yeah
I
think
definitely
there's
a
lot
of
interest
in
adding
UDP
to
the
fundamental
protocols
I've
at
least
for
me.
I,
don't
have
that
really
any
operational
experience
to
have
a
strong
point
of
view
about
what
the
semantics
of
that
would
look
like
and
I
expect
that
you
really
want
to
use
UDP
protocol
mental
UDP
protocol
type
in
conjunction
with
a
route
protocol
type
which
brings
in
those
session
based
semantics
or
protocol.
That
says
what
you're
actually
doing
with
with
UDP
UDP
packet
forwarding
by
itself
is
not
necessarily
that.
A
D
Point
that
might
be
I
mean
it
might
be
sufficient
just
to
say:
okay,
we
add
UDP
to
the
protocol
type
and
then,
if
you're
gonna
use
this,
then
you
need
to
then
the
controller
needs
to
understand
the
relationship
between
the
protocol
type
and
specific.
You
know
wrap
bindings
that
get
selected
for
that
yeah.
A
D
So
just
for
background,
but
the
reason
we
do
have
like
a
fixed
protocol
type
is
so
that
we
can
have
meaningful
spec
language
about.
However,
two
hosts
layer
onto
this
thing,
because
if
it
was
all
completely
abstract,
then
you
wouldn't
necessarily
be
able
to
say
accept
anything
about
how
TLS,
HTTP
and
HTTPS
concepts
wouldn't
really
exist.
A
A
A
Well,
that
works
out
well,
because
the
last
part
of
this
I
wanted
to
go
through
conflict
resolution
and
I.
Imagine
this
being
almost
like
a
a
working
session.
I
don't
know,
but
I
have
a
doc
that,
hopefully,
is
a
decent
starting
point
here
around
conflict
resolution.
Obviously
I
am
very
interested
in
trying
to
get
I
think
we're
all
interested
in
trying
to
get
AV
1
alpha
1.
Release
of
this
API
out
and
conflict
resolution
is
one
of
the
things
on
that
list
that
we
wanted
to
have
well-defined
as
part
of
a
initial
alpha
release.
A
A
I've
added
a
lot
more
potential
conflict
scenarios
and
I
wanted
to
spend
some
time
just
working
through
each
of
these
potential
conflicts
in
a
relatively
informal
way
and
seeing
if
the
proposed
solution,
I
have
suggested,
makes
sense,
and
maybe
more
importantly,
trying
to
identify
conflicts
that
I
haven't
listed
yet
because
I
know
they
exist.
I
know
this
is
a
an
incomplete
list,
but
yeah
it's
a
starting
point.
A
So,
first,
the
guiding
principle
is
the
one
that
we
identified
before
that
I
think
just
about
everyone
was
in
agreement
with
was:
let's
prefer
to
not
break
things
that
are
already
working,
I,
think
that's
a
brilliant
first
principle,
then
I've
added
that
we
want
to
provide
a
consistent
experience
when
conflicts
acure
occur.
So
even
if
it
may
not
be
something
that
makes
people
happy
per
se
at
least
it
makes
sense.
At
least
it's
consistent,
and
you
can
understand
why
a
decision
was
made
and
maybe
even
more
importantly,
it's
consistent
between
implementations.
A
I
think
this
is
a
really
old
non-controversial,
guiding
principle
and
I
just
wanted
to
have
that
in
here,
because
it
seems
to
be
a
theme
that
will
come
through
in
all
of
these
different
conflicts,
but
before
I
go
any
further.
Do
those
principles
make
sense?
Is
there
anything
that
I
should
have
had
here
as
a
as
another
potential
theme.
A
A
There
are
some
implementations
where
say
cloud
this
will
a
gateway
will
represent
a
load
balancer
likely
a
cloud
load,
balancer
and
so
DNS
is
going
to
point
to
a
specific
IP
and
you
don't
have
probably
quite
the
same
issue
with
this
conflict,
but
there
are
a
number
of
use
cases
where
it
may
not
be
that
clear
and
so
I
propose
the
solution
that
may
or
may
not
make
sense,
obviously,
first
off
if
there
is
one
match
that
is
more
specific
than
the
other.
That
should
always
be
given
precedence.
A
I
think
that
just
makes
sense,
but
if
both
of
these
not
only
match,
but
they
match
identically
like
the
the
actual
match
is
identical
equally
specific,
my
idea
was
that
precedent
should
be
given
to
the
oldest
gateway
based
on
creation.
Timestamp
I
know,
there's
been
a
lot
of
issues
trying
to
identify
what
was
most
recently
changed,
which
might
be
ideal,
but
going
with
something
like
the
oldest
resource
is
going
to
give.
A
So
we
do
have
access
to
creation
timestamp.
So
if
we
can
use
that
as
a
as
a
matter
of
giving
precedence
to
the
older
resource,
I
think
that
makes
sense
here
and
then
finally,
if
both
have
equivalent
creation
time
stamps,
if
you
get
another
tie
there,
one
thing
that
we
know
will
always
be
unique.
Is
the
namespace
/name
combination
for
a
resource,
so
my
suggestion
was
to
give
precedents
based
on
alphabetical
order,
based
on
that
namesake
namespace
name
string
that
that
is
a
real
stretch.
A
That
is
not
particularly
intuitive,
but
it
is
consistent
and
that
should
resolve
any
potential
conflicts.
I
can't
think
of
anything
going
past
that
set
of
conditions
data-
that's
maybe
a
little
weird,
does,
does
that
order
of
operations
seem
to
make
sense,
specifically
the
oldest
creation
time
stamp.
F
Yeah
I'm
in
favor
of
the
oldest
creation,
timestamp
I,
do
question
whether
this,
if
both
gateways
have
equivalent
creation
time,
stands
to
use
the
namespace
name
as
opposed
to
just
throwing
an
error
just
trying
to
understand
like
how
applicable.
That
would
be
that
you
know
that
a
user
would
actually
want
to
use
the
gateway
that
has
that's
listed
first
in
alphabetical
order
and
I
think
it
may
cause
more
harm
than
good
as
I
guess.
What
I'm
trying
to
say
so.
A
A
My
hope
is
that
we
never
get
to
this
if
both
have
equivalent
creation
time
stamps.
That
does
seem
like
a
bit
of
a
stretch,
but
you
know
it
could
happen.
I,
don't
I,
don't
know,
I
get
that
that
last,
it's
probably
not
desired.
Behavior
I'm,
just
trying
to
think
of
the
least
bad
option
here
you
know
I
I
hate
the
idea
of
okay.
This
is
invalid.
That's
just
not!
Let's
just
consider
both
gateways
broken
listeners,
I.
F
F
In
this
scenario,
we're
basically
saying
is
that,
although
gateway
2
is
created
old
or
was
created
after
gateway,
1
and
and
was
working,
just
fine
I
go
into
gateway
to
one
and
accidentally
add
the
same
host
name
and
now
gateway
2
stops
that
host
name
stops
working
for
gateway,
2
and
it
works
for
gateway.
1.
A
Yes,
unfortunately,
I
think
that's
the
case
because
gateway
one
happens
to
be
older.
In
that
case,
I
I
can't
think
I
hate
that
outcome,
but
I
I
can't
think
of
a
reliable
way
to
diff
based
on
last
updated
time
and
not
just
have
a
really
confusing
and
inconsistent
experience
and
I
think
the
only
other
alternative
is
to
just
consider
them
both
invalid,
which
breaks
everything
consistently.
So
it.
F
F
And
I
think
that
would
be
the
last
option
is
just
to
you
know,
break
everything
like
he
said
that
one
guiding
principle
but
I
do
feel
like
most
of
the
time
it's
like
a
user
goes
in
and
and
it's
like
that
last
updated
or
the
latest
change
is
the
incorrect
change
and
so
I
you
know
I.
It
does
seem
like
okay,
this
this
approach
here
that
you're
proposing
is
he
has
it
better
than
breaking
everything,
but
I
do
think
it's
actually
could
cause
more.
You
know
undesired
consequences,
even
though
it
doesn't
break.
E
A
So
I
think
the
the
complicated
fact
as
far
as
I
know,
there's
not
a
great
way
to
know
what,
when
the
breaking
change
was
added
and
especially
like,
if
you
have
a
long-running
controller,
you
can
try
and
remember
that
state.
But
if
a
controller
is
starting
up
fresh
or
have
to
restart
for
some
reason
and
just
has
to
view
the
state
as
it
knows
it,
it
feels
like
it
would
be
very
difficult
to
drive
that
information
to
understand
what.
What
introduced
the
the
braking
behavior.
D
D
You
can't
have
your
controller
start
up,
inspect
an
envoy
and
then
match
that
state
back
to
what
you
what
you
see
in
in
CID
resources,
so
you
can
keep
track
of
it
internally,
while
you're
running
and
do
the
right
thing,
but
then,
when,
if
you
have
to
restart
you
control,
then
you've
lost
or
state
something,
and
you
can
end
up
in
this
sort
of
situation.
Yeah.
A
And
that's
I
think
that's
another
case.
We
would
want
to
avoid
in
that.
That
kind
of
goes
back
to
the
second
guiding
principle.
I
have
here
providing
a
consistent
experience
when
conflicts
occur
and
trying
to
do
something
like
that's
not
going
to
rely
on
temporary
state
trying
to
do
something
like
that
is
something
that
can
persist
over.
We
start
with
it
without
any
kind
of
temporary
state
stored
by
the
implementation.
D
A
A
A
A
Yeah
well,
I'll
leave
I'll
leave
that
up
there
for
further
comment,
but
that
that
is
a
great
point.
Okay
and
then
the
next
one
is
a
is
incredibly
similar
to
this,
and
it's
before
I
go
further
Damian
were
you
gonna,
say
something:
yeah,
okay,
gateway
listeners
within
a
gateway
both
match
the
same
hostname.
So
this
is
very
similar,
but
it's
saying
instead
of
spread
across
multiple
gateways,
this
is
within
the
same
gateway
see.
So
it's
not
based
on
gateway,
name.
A
We
could
potentially
handle
this
with
validation.
If
we
want,
we
could
say
that
host
names
must
be
unique
within
a
gateway.
Wait
well
with
yeah
within
a
gateway
listener.
Host
names
must
be
unique
or,
alternatively,
how
we
could
do
some
weird
conflict
handling
or
finally,
we
could
take
James
potential
solution
here
of
just
if
there
are
multiple
listeners
with
the
same
host,
assume
round-robin.
D
E
A
D
A
D
It
that
there
are
ways
to
specify
it
with
which
you'd
expect
would
generate
an
error.
There
is
a
there
is
a
condition:
port
conflict.
The
listeners
which
you
could
say
that
these
you
can
kind
of
spin
the
arrow
flip
the
air
around
and
say:
oh,
you
know
actually
conflicting
on
hostname.
You
specify
two
host
names
there
for
you.
Those
host
names
are
conflicting
on
port,
but
maybe
it's
better
to
have
a
more
specific
thing.
Error
to.
A
And
that's
yeah
what
I
would
recommend
and
I
have
some
caught
some
potential
conflict
resolution
recommendations
below
that
rely
on
a
web
hook
as
well
and
I.
Think
we
at
the
very
least
we
need
to
provide
I,
think
it
would
make
sense
to
have
a
common
set
of
code
for
this
I
think
any
time
you
try
to
deploy
validating
web
hook.
It's
a
little
bit
messy,
at
least
in
my
experience,
and
you
know
getting
TLS
everything
else.
F
F
James
described
with
exposing
an
application
via
HTTP
and
HTTPS
I
think
he
could
also
do
the
same
where
you
say
you
know
it's
nice,
GP
app,
but
I
expose
one
chord
for
one
reason:
another
port.
For
another
reason:
it's
probably
less
common,
but
I,
don't
know
what
you
guys
think
about
also
including
court.
A
So
yeah,
sorry,
sorry,
is
how
I
interpret
what
you're,
suggesting
here
and
I
think
it
makes
sense
is
host
name
should
be
unique.
You
should
never
have
the
same
host
name
for
same
values
of
protocol
and
port,
but
you
could
have
the
host
name
with
a
identical
court
and
different
protocol.
As
an
example.
Well
know
that
that
doesn't
make
sense,
you
want
all
three
to
be
yeah.
A
D
So
so
from
the
spec
we
have
listeners
are
compatible
if
all
the
following
conditions
are
true:
they're
vertical
fields
are
HTTP
or
all
their
protocol
fields
are
HTTP
or
TLS.
Their
host
name
fields
have
a
match
other
than
any.
There's
like
three
rules,
but
I
generally
I
think
you're
right.
We
should
it'll
be
great
to
have
something
validate
a
common
component
to
actually
validate
these
rules
so
that
all
these
end
up
doing
roughly
the
same
thing.
A
A
A
My
naive
initial
proposed
solution
was
very
similar
to
it
as
the
solution
I
proposed
above,
which
gives
press
it
in
to
most
most
specific
first
I,
think
that
always
wins,
and
then,
after
that
oldest
and
then
after
that
alphabetical,
but
I
am
especially
less
convinced
that
alphabetical
makes
sense.
I,
don't
know
about
the
round-robin
between
matching
routes
that
that
may
also
be
strange.
A
D
I
don't
know
I
definitely
I
definitely
agree
with
you
that
about
validation,
because
I
think
you're,
right,
I
think
you're
right,
but
earlier
in
the
pipeline,
you
you
catch
you
can
you
can
catch
the
error?
The
better
off
the
whole
system
is
yeah,
so
I
think
when,
when
I
had
been
when
I
was
taught
when
I
was
thinking
originally
thinking
through
the
conflicts,
I
I
wasn't
thinking
about
it
really
in
terms
of
a
validation.
I
was
thinking
you
more
in
terms
of
a
controller,
doing
doing
this
validation
after
the
fact
yeah.
D
A
A
You
maybe
maybe
that's
a
clear
way
of
stating
that
but
multiple
routes
could
both
conceive
it
a
conceivably
match
the
same
request
and
they're
both
equally
specific
either
they
both
have
a
hostname
match
and
a
path
match,
or
they
both
have
a
nil,
hostname
and
just
a
path
match
whatever
it
happens
to
be.
If
they
are
equally
specific,
it's
less
clear
what
to
do
here.
A
You
could
just
round
robin
and
say:
well:
they
they
equally
match
that
certainly
fits
the
principle
of
don't
break
things
that
are
worth
King,
just
whatever
my
an
original
proposed
solution
was
you
know
if
they
are
equally
specific,
just
send
traffic
to
the
oldest
route,
but
that
can
result
in
breaking
things.
Unexpectedly,.
A
But
it's
it's
arguable
right
because
you're
breaking
things
unexpectedly,
but
with
with
everything,
if
you
only
break
things
halfway,
then
it
just
potentially
takes
longer
to
notice.
Why
are
half
of
my
requests
going
bad
like
it's?
Not
all
my
requests
got
broken,
but
half
of
them
are
now
broken.
What
did
I
change
and
you
know
I
I?
Guess
you
can
figure
it
out?
Oh.
A
D
E
A
There
may
be
some
things.
Some
extension
points
that
as
an
example
we
can't
validate,
because
we
can.
We
can't
consistently
prevent
extension
points
from
existing,
but
they
may
not
be
valid
for
every
implementation.
So
maybe
this
comes
into
play
there,
where
there's
some
implementation,
specific
things
that
are
not
valid
for
that
on
that.
Well,.
D
A
Okay,
so
the
next
one
is
one
of
the
things
that
I
referred
to
as
being
entirely
valid.
Multiple
gateways
to
far
get
the
same
route.
I
think
that
is
entirely
valid.
I
did
want
to
cover
it
because
it
could
be
seen
as
a
potential
conflict,
so
we
probably
at
least
need
some
documentation
around
this
being
a
valid
and
expected
use
case.
And
additionally,
though,
this
I'm,
not
as
sure
about
we
may
want
to
consider
some
way
to
communicate
on
a
route
which
gateways
have
selected
that
route
and
are
currently
using
that
route.
A
My
concern
with
any
kind
of
status
condition
like
that
is
it's
really
hard
to
garbage,
collect
that,
without
always
having
an
omnipresent
view
of
every
route
in
a
cluster
and
consistently
dipping
them.
I
feel
like
that.
You
know
like
if
a
route
selector
changes
and
the
controller
happened
to
be
down
or
something
like
that
I
maintaining
this
gets
messy.
A
All
right,
so
the
next
one
I
wanted
to
cover
was
a
gateway
class.
These
are
these
are
messy.
These
have
always
been
messy
and
confusing
and
I
apologize
as
the
person
who
pushed
for
leaves
being
added
to
begin
with,
there's
two
gateway
class
fields
that
are
really
authorization
fields
more
than
anything
allowed
gateway
namespaces
and
allow
the
route
namespaces.
A
A
Potential
solution
would
be
to
change
their
behavior
significantly,
so
that
they
would
only
apply
as
gateways
are
being
created.
They
would
be
more,
dare
I,
say,
are
back
like
or
authorization
like
and
that
they
because
their
their
authorization
type
fields.
They
refer
to
be
what
can
be
done
at
that
point
in
time,
so
where
you
can
create
gateway,
namespaces
gateways
which
namespaces
can
have
gateways
created
with
this
gateway
class
that
gets
messy.
It
assumes
that
gateway
class
is
immutable.
I
think
it
is
I.
A
A
A
A
A
D
A
Exactly,
and
so
you
would
have
to
if
you
made
this
change
in
behavior,
you
would
also
have
to
rename
the
field
or
redock
ument
field
or
something
to
make
it
clear
that
this
is.
This
affects
new
gateways.
That's
it
one
of
the
one
of
them
really
dangerous
things
about
this
field,
as
it
exists
right
now,
and
it
hasn't
SPECT
right
now,
as
it
can
have
disastrous
impacts
like
it.
It
is
potentially
the
most
destructive
field.
We
have
right
now
where,
if
someone
just
messes
that
up
a
little
bit,
they
can
completely.
A
You
know
if
it
were
followed
to
the
speck
right
now.
It
would
completely
invalidate
every
gateway
using
that
class
just
if
they
accidentally
made
one
change
and
I.
Don't
think
that's
really
the
intent
of
the
field.
I
think
the
intent
of
a
field
like
this
is
to
prevent,
where
gateways
of
a
certain
class
can
be
created,
and
so,
if
you
prevent
creation,
it's
really
quite
simple:
to
go
through
and
check
where
gateways
are
using
this
class.
A
And
if
you
change
that
in
the
future,
you
can
go
through
and
clean
up
those
gateways
on
your
own
time
and
a
safer
way,
if
you
really
don't
want
gateways
and
all
these
other
names
places
with
this
class,
but
allowing
that
to
happen
based
on
a
single
field.
Change
in
one
place
feels
especially
dangerous
and
and
I.
Think
this.
This
same
concept
kind
of
applies
to
a
lot
of
gateway
class
concepts.
The
potential
blast
radius
of
changes
to
gateway
class
is
significant.
F
So
if
I
wanted
to
turn
down
a
gateway
in
this
use
case,
if
I
wanted
to
turn
down
to
Gateway
actually
have
to
remove,
you
know,
let's
say
it's
just
kind
of
reverse
order.
You
know
remove
any
of
the
routes
removed
the
Gateway
and
then
I
can
go
and
update
the
date
weight
class
and
remove
the
allowed
namespace
that
I
was
using
for
that
particular
gateway.
That
would
be
allowed
right.
So.
A
That's
that
is
what
currently
would
be
needed
to
do
it
safely
in
the
current
spec.
What
I'm
talking
about
here
is
removing
any
changes
like
making
this
field
only
affect
future
creations
of
gateways,
and
so
it
changing
this
field
does
not
invalid
and
validate
any
existing
gateways
under
this
proposal
that
that's
what
I'm
trying
to
avoid
that's,
what
I
think
is
really
dangerous
here,
if
you
can,
by
changing
one
field,
invalidate
a
huge
line
of
gateways,
I
feel.
A
So,
no
so
sorry,
if
you
can,
you
can
change
that
at
any
point,
but
all
it's
going
to
do
again
with
this
new
proposal
is,
it
would
affect
future
creation
of
gateways.
That's
it.
It
would
not
invalidate
anything
existing,
so
you
can
change
that
immediately
and
it's
safe.
It
just
means
no
one
knew
no
one
can
create
a
new
gateway
outside
of
these.
This
updated
more
restrictive
list.
Gateway
expenses-
that's
all
it
does.
It
doesn't
invalidate
anything
existing.
A
Yeah,
it's
it's
very
possible
to
do
garbage
collection
or
whatever
else,
to
to
automate
that
I,
just
I
really
hate
for
that
to
be
a
gateway
specific.
You
know
for
that
change
to
be
part
of
our
API.
To
basically
have
a
single
change.
Have
such
a
huge
blast,
radius
and
control
impact,
but
yeah
so
I
know
I,
know
we're
we're
really
over
time
here,
but
thank
you,
everyone
for
the
feedback.
Here.
It's
been
really
helpful.
I'll
try
and
get
some
updates
in
I.