►
From YouTube: Service APIs Office Hours 20200729
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
office
hours
for
service
apis
on
july
29th,
obviously
we're
well
at
least,
hopefully
still
trying
to
hit
an
august
sometime,
really
v1
alpha
when
release
so
we're
getting
awfully
close
to
that
looks
like
we've
got
plenty
on
the
agenda
today.
A
A
My
first
question
for
today
was
if
it
would
make
sense
to
try
to
merge
some
of
our
docs
and
final
proposals
into
a
single
dock,
and
this
sounds
kind
of
strange-
I
admit,
but
basically
right
now,
it
seems
like
it'd,
be
as
we're
looking
towards
v1
alpha.
One,
it
seems
like
it'd,
be
very
helpful
to
provide
a
straightforward
way
to
review
the
entire
api
and
comment
on
different
portions.
A
I
know
james
has
kind
of
alluded
to
this
before
it
would
be
helpful
if
we
had
groups
or
people
just
looking
through
the
api
top
to
bottom,
not
just
little
bits
here
and
there
and
an
idea
was
well
if
we
could
throw
this
off
in
a
way.
A
It
sounds
like
we're
going
backwards
again,
but
we
have
a
few
docs
that
are
kind
of
dispersed
and
we
have
what's
already
in
code
what's
already
in
code
and
what
we
expect
is
going
to
make
it
there
and
if
we
could
combine
all
that
into
a
doc,
I'm
thinking
it
might
make
it
easier
to
get
feedback
among
ourselves
and
even
maybe
from
some
others
that
haven't
looked
at
at
the
api.
A
A
Cool
well
I'll,
take
no
pushback
as
no
pushback
and
I'll
work
towards
that.
I'm
I'm
hoping
to
get
some
some
more
feedback,
and
also
I'm
hoping
that
having
it
all
in
one
place
will
make
it
easier
to
see
things
that
may
or
may
not
make
sense.
A
All
right,
well,
the
the
next
thing
I
had
on
the
agenda
was
our
dating
added
was
traffic
splitting
and
I
think
the
news
now
is
just
that
it's
merged
yeah,
it
looks
like
bowie
has
approved
that
so
congrats.
Thank
you
for
all
your
work
on
that
danian,
I
don't
know.
Is
there
anything
else
we
should
talk
about
here.
B
No,
I
don't
think
so.
Just
I
wanted
to
make
sure
it
was
on
the
agenda
because
I
thought
the
pr
was
ready
to
review
and
potentially
emerge.
So
thanks,
everyone
who,
who
reviewed
and
provided
feedback
and
especially
harry
you
rob
bowie
and
jeremy
and
others.
So
thank
you.
Okay,.
A
All
right,
I
just
wanted
to
go
through.
We've
had
a
few
pr's
come
up,
which
is
awesome.
I
just
want
to
make
sure
that
they
got
appropriate
attention
here.
Harry
opened
a
pr
to
correct
conformance
for
regex
support.
I
think
this
is
fine
harriet.
It
looks
like
you're
on
the
call.
Were
you
able
to
test
this
and
verify
that
this
works?
That
was
my
only
comment
on
this
one.
A
A
Right,
yeah,
yeah
now
the
crd
generation
looks
fine.
I
just
I
ran
into
some
strange
issues
before
with
the
combination
of
defaulting
and
required
values
where,
if
a
value
was
required
and
default,
the
default
would
not
happen
before
the
required
check.
I
guess
validation
must
happen
after
defaulting,
which
would
be
nice.
A
Because
you
know
what
I
would,
what
I
would
hate
here
is
for
this
to
effectively
become
a
required
field
which
is
not-
and
maybe
maybe
this
maybe
there's
just
no
way
around
it.
I
don't
know,
but
it
would
be
really
nice
if
that
default
could
actually
apply
before
we
got
this
validation.
A
A
Yeah
it
does
it
does
not
the
only
thing
I
was
concerned
about
what
and
I
it's
probably
a
non-issue
was
the
the
order
of
operations
ensuring
that
defaulting
happened
before
validation,
because
I
know
that
defaulting
does
not
happen
before
a
required
check.
A
Then
you
have
another
pr
that
pluralizes
matches
and
I
think
this
one
may
require
a
bit
more
discussion.
I
I
can't
remember
exactly
where
we
left
off
in
the
last
meeting,
but
I
know
there
was
a
lot
of
discussion
around
the
idea
of
ending
versus
oring.
A
C
Still
expect
some
discussion
on
this
one
here
as
well,
so
I've
tried
like
last
time.
I
think
it
was
not
clear
as
to
how
things
would
be
used
because
of
lack
of
documentation
and
that
google
talk.
This
is
from
the
actions
proposal,
so
what
I
did
was
I
actually
figured
out
like
just
let
me
write
down
the
google
docs
so
that
we
can
have
a
discussion
right
and
if
this
is
still
confusing,
we
should
definitely
avoid
it,
but
this
is
to
start
a
conversation.
A
Yeah
my
comment
here
is
just
I
I
think
I
was
in
the
minority,
but
I
actually
agree
with
this
approach,
though
I
I
also
don't
understand
the
full
consequences
of
it.
My
my
understanding
is
this
would
make
it
straightforward
to
match
multiple
paths
and
assign
them
the
same
forward
too.
Essentially,
whereas,
if
you
made
this
enhancing
match,
that,
obviously
would
not
you
an
and
for
this
kind
of
match
would
be
very
confusing.
E
A
A
A
A
E
Yes,
I
think,
is
there
an
example
where
it's
not
this,
because
you
could
this
example
can
be
very
easily
accomplished
without
doing
ever,
but
just
duplicating
the
block
above
it,
I
guess,
having
another
rule,
but
the
motivation
for
having
multiple
heavy
multiple
matches
via
list.
C
So
I
was
you're
breaking
out
I'll.
Try
to.
I
think
what
I
got
from
it
was.
What
is
the
motivation?
Is
this
the
current
example
the
use
case
or
something
else
here?
So
yes,
so
I
think
it
can.
You
can
duplicate
the
entire
rule
right.
The
http
route
rule
is
an
array
inside
http
route
resource
under
the
spec.
C
You
can
duplicate
it,
but
imagine
a
situation
where
you
have
set
up
a
forward
to,
and
you
also
are
using
you
know,
extension
points
to
define.
You
know
further.
You
know
something
like
actions
which
is
not
part
of
the
api
yet,
but
I'm
working
on
that.
So,
if
you
have
that,
that
leads
to
a
lot
of
duplication-
and
it
leaves
room
for
you-
know
errors,
because
that
that
will
be
manual
right.
You
could
template
it
out,
but
but
it
still
leaves
room
for
error.
E
C
A
Yeah
I
like
this
because
it
feels
like
it's.
It's
really
just
a
shortcut
that
you
know
it.
It's
not
fundamentally
changing.
As
far
as
I
understand
this,
this
isn't
fundamentally
adding
new
new
behavior
per
se
like
anything
new
that
implementation
needs
to
support
the
very
naive
way
of
way
of
implementing
this,
I
think,
would
just
be
to
split
each
of
these
matches
out
into
their
own
rule.
This
is
just
a
shortcut
to
that
to
that
kind
of
approach,
but
but
the
same
thing
could
be
communicated
right
now
in
the
current
api.
A
E
Yeah
bad,
so
the
things
the
things
I
get
scared
of
is,
if
it
results
in
a
multiplication,
but
this
one
is
like
having
any
of
these
things
under
matches
is
only
times
one
forward
two,
but
the
one
I
get
concerned
is
if
it's
like
n
times
m
and
then
in
the
underlying
thing,
you
have
to
kind
of
do
like
end
time
thing.
A
A
F
The
order,
so
the
global
order
for
matches
would
be
all
the
matches
in
the
first
rule,
followed
by
all
the
matches
in
the
second
rule
and
so
forth.
Is
that
correct.
C
A
All
that
is
a
great
question,
though
I
I
imagine
that
the
idea
of
rule
itself
is
going
to
ordering
is
potentially
going
to
matter
in
the
order
of
a
route
rule,
and
so
you
can
imagine
that
the
trip,
the
the
easiest
interpretation
of
this
would
be
each
mult.
Each
additional
match
just
translates
into
an
additional
route
rule
effectively
like
further
down
that
you
know
so.
The
first
match
is
the
equivalent
of
a
route
rule
at
that
index,
and
the
next
match
is
the
equivalent
of
a
subsequent
route
rule
at
that
index.
A
A
F
It's
kind
of
implicit
right
because
the
slice
of
matches
in
the
rule
are
all
conditions.
F
C
Yeah
I
mean
yeah,
so
essentially
I
mean
you
the
way
you
would
match
in
case
if
this
feature
was
not
present
and
the
way
you
would
implement
this
feature
is
essentially
duplicate
each
match
into
its
own
rule
right.
The
semantics
with
that
way
of
you
know,
implementing
multiple
matches
and
the
semantics
in
this
pr.
They
are
exactly
the
same.
A
That
is
a
really
good
point,
though
this
does.
This
does
potentially
complicate
conflict
resolution
here,
if
the,
if
the
interpretation
of
this
is
not
identical
to
the
interpretation
of
multiple
route
rules,.
F
Okay,
yeah
right
yeah.
I
think
I
think
you're
right.
I
think
it
is
okay,
so
I
guess
the
other
thing
that
the
other
issue,
that
the
other
thing
maybe
to
discuss
is
whether
we
should
do
these
sorts
of
yaml
minimization
changes
prior
to
getting
any
feedback
on
the
on
actual
people
on
from
usage.
After
the
release.
A
Yeah,
that's
a
good
point
this.
This
does
not
add
any
new
functionality.
This
just
potentially
makes
the
api
a
little
bit
less
verbose.
F
With
this
change,
I
think
it's
fine,
I'm
just
wondering
about.
I
think
when
we
get
when
people
start
using
it
we'll
probably
get
feedback
about
our
there's
a
lot
of
copy
paste
or
something
like
that.
C
Yeah,
I
mean,
I
think,
both
of
those
points
james,
you
raised
a
very
good
point
again.
C
We
still
haven't
talked
about
conflict
resolution
like
in
routes
or
you
know,
route
conflicts,
but
how
this
change
complicates
it
and
it
very
well
could
so
yeah
I,
if
I'm
fine,
either
way
we
merge
this
or
we
don't
move
this,
but
if
you
can
add
in
those
comments
into
the
pr,
this
is
just
something
that
you
know
we
can
reflect
back
on,
like
what
we
decided
and
why
we
decided
against
or
right.
F
A
So
one
one
little
bit
of
potential
conflict.
I
don't
want
to
say
this.
C
A
A
Okay,
yeah
this
makes
sense
to
me.
I
will
try
and
add
a
follow-up
comment
around
this
as
well
and
if,
if
anyone
else
wants
to
add
anything
here,
I
I
don't
have
a
very
strong
feeling,
one
way
or
the
other
as
to
whether
or
not
we
should
try
to
include
this
in
v1
alpha
one.
A
I
get
the
point
to
avoid
premature
optimization,
but
if
we
do
imagine
this
being
a
pain
point
yeah,
I
I
don't
care
too
much
on
this
one.
A
A
C
A
F
Yeah,
I
guess
the
the
implication
that
I
would
take
from
reading.
The
current
godok
is
that
I
should
apply
the
http
route
rules
in.
A
A
A
Yeah,
that's
a
that
is
a
good
point.
I
I
seem
to
remember
with
ingress.
We
ended
up
going
towards
most
specific
match
wins
in
this
case,
and-
and
I
think
especially
with
the
idea
that
multiple
routes.
A
A
Thing
I
was,
I
was
trying
to
wait.
Sorry
if
yeah,
basically,
what
I
was
saying
is:
if
you
merge
routes
and
multiple
route
objects,
you
don't
really
know
which
should
come.
First,
we
have
a
very
abstract
idea
of
ordering
at
least
with
the
selector.
A
E
I
don't
know
what
it
is
today.
That's
an
interesting
point
is
that
we
probably
should
try
not
to
impose
strict
ordering
just
because
I
don't
think
implementation
will
all
support
it.
E
Double
check,
though
one
interesting
thing
is
that
this,
the
best
matched
rule
is
also
interesting,
because
one
of
the
ways
to
implement
that
with
a
search
ordering
system
is
to
sort
it
by
best
matching
example,
infrastructure
ordering
and
then
systems
that
can
often
bite
on
top
of
that
and
do
so
themselves.
E
A
Forth
yeah
that
that's
good
feedback.
I
I
think
it
would
be
good
to
to
understand
that
as
well.
It
did
seem
like,
as
as
we
were,
going
through
the
the
ingress,
spec
and
updates
that
the
the
idea
of
most
specific
match
is
fairly
universal,
universally
implementable,
even
if
it
is
like
you're
saying
ordering
most
specific
match.
First
in
the
actual
implementation
yeah.
That's
that's
a
good
good
point.
A
Okay,
the
last
one,
the
last
ones,
are
both
from
jeremy.
It
doesn't
look
like
he's
here
today,
but
I'll
just
mention
these
briefly.
This
is
udp
route.
It
is
I
I
look
briefly.
It
appears
to
be.
You
know,
basically,
an
exact
copy
of
tcp
route
with
different
different
names,
but
but
generally
everything
else
behaves
as
he
would
expect
yeah.
I
I
don't.
I
I
think,
based
on
our
last
discussion
around
edp
route,
there
was
support
for
adding
it
because
it
was
so
similar
to
tcp
row.
A
So
I
don't
need
to
spend
too
much
time
on
this,
because
I
don't
think
jeremy's
here
but
I'll
just
so
you
know,
that's
that's
a
pr
that
is
ready
for
review
and
similarly
based
on
feedback
from
last
week
he
went
ahead
and
added
an
sni
match
for
tcp
route.
E
Change
go
ahead,
yeah.
My
question
for
this
is
that
do
we
want
a
pct
route
to
have
sni
concepts
or
just
have
an
smi.
A
E
A
E
G
E
Is
to
have
the
tcp
current
dcp
route
and
udp
valve
to
merge
them
into
like
some
plane
traffic
splitting
route
and
then
have
snr
that'll.
Be
this
whole
thing
instead
of
having
tcp
and
udp
route,
basically
the
same
thing,
although
we
need
to
talk
about
how
people
could
have
a
connection,
oriented
well,
balancing
features
and
youtube
would
have
a
pocket
load
balancing
features,
so
the
things
are
not
empty.
Actually
in
the
future,
if
you
can
see
like
where
they
could
be
going.
A
Yeah
yeah,
I
agree
with
that
last
comment.
I
feel
like
there's,
there's
more
room
for
tcp
route
and
udp
route
to
eventually
become
significantly
different,
or
at
least
support
significantly
different
functionality
in
the
future,
whereas
this
at
least
right
now
to
me
feels
like
something
that
can
just
be
tacked
on
top
of
tcp
route.
A
But
maybe
that's
naive.
I
don't
know.
F
I
guess
the
other
thing
about
that
brings
to
mind
about
the
tcp
route.
Having
an
sni
field
is,
can
we
make
it
more?
Can
we
make
it
follow
the
http
conventions
a
bit
more?
Would
that
make
sense
so
tcp
http
route?
Sorry,
I
misspoke,
I
mean
http
route
p
route.
Has
the
spec
the
host?
The
thing
expect
the
host
to
action
right
so
does
it
make
sense
to
apply
a
similar
structure
to
tcp.
F
F
Yeah,
so
this
is
so
here:
you've
got
the
host
name
at
down.
You've
got
the
host
name
down
in
the
match,
but
with
http
route,
you've
got
the
host
name
at
the
top
of
the
configuration
object,
hierarchy
so
they're
kind
of
swapped
around
with
regards
to
each
other.
F
Mean
so
so
the
structure
of
http
routes
is
you
start
with
a
host?
Then
you
start
with
a
you
start
with
an
optional
host.
Then
you
suck,
then
you
get
down
into
matches
and
rules.
Then
you
go
to
rule
and
then
match
so
would
it
make
sense,
for
I
don't
know
if
jeremy's
on
this
call,
but
does
it
make
sense
for
tcp
route
to
do
the
same
thing?
A
A
And
I'm
also
interested
in
in
bowie's
suggestion
here
of.
If,
if.
E
A
Even
belongs
on
tcp
route,
but
but
maybe
it
is
helpful
to
pull
it
at
the
very
least.
It
could
be
helpful
to
pull
it
out
of
match
and
up
to
a
top
level
now
to
clarify
you're
talking
about
top
level
being
route.
So
s
and
I
moving
from
match
to
route
to
route
rule.
Is
that
accurate
or
is
it
even
higher
level
on
the
tcp
route
stack
itself.
F
A
All
right
well
yeah,
I
don't
know
if
anyone
else
does
definitely
chime
in.
If
not,
is
there
any
any
other
thing
to
discuss
on
this.
A
One
okay,
great.
The
last
thing
that
I
wanted
to
cover
today
was
some
follow-up
around
conflict
resolution.
I
I've
I've
gotten
some
more
feedback
and
I've
spent
some
more
time
working
on
conflict
resolution
and
trying
to
spec
that
out.
This
is
a
remarkably
broad
topic
and
I
I'm
trying
to
find
the
right
scope
without
making
this
all
consuming.
A
But
I
added
a
few
questions
at
the
top
here.
The
first
one
of
note
is:
are
there
any
conflicts
or
will
there
ever
be
conflicts
that
cross
permission
boundaries?
I
I
can't
think
of
any
right
now,
but
the
idea
of
a
route
being
referenced
that
maybe
not
everyone
has
access
to.
I'm
not
entirely
sure
what
that
looks
like
yet,
but
it's
something
that
I
wanted
to
throw
out
there
in
case
anyone
thought
of
any
potential
conflict
in
this
api
that
could
also
involve
permissions.
A
Yeah
and-
and
I
will
say
there
is
something
related
to
our
round
name
spaces
thing
that
is
related
to
permissions,
but
I've
I've
got
that
later
on,
so
maybe
I'll
I'll
at
least
mention
this
here,
but
I
I'm
already
covering
this
one
and
then
a
a
broader
discussion
that
actually,
I
think
james
might
have
started
earlier
on
the
the
lifetime,
coupling
between
gateways
and
their
gateway
class,
and
this
this
issue
and
this
discussion
around
this
is
not
completely
what
I
want
to
talk
about,
but
it
provides
a
decent
decent
context
and,
as
I
recall,
the
the
suggestion
was
to
which
I
think
makes
sense
to
recommend
at
least
adding
a
finalizer
to
gateway
class
resources
that
would
prevent
a
gateway
class
from
being
deleted.
G
A
A
So
the
final
finalize,
our
approach
is
one
way
to
handle
that
another
way
to
handle.
That
is
to
somehow
tie
some
level
of
gateway,
class
information
to
the
gateway
itself,
so
the
gateway
can
be
self-sufficient
after
creation,
so
we're
this.
This
is
a
bit
of
a
change
in
thinking
that
may
not
make
sense,
but
that
background
is
also
at
least
or
that
idea
is
at
least
somewhat
motivated
by
other
potential
conflicts
that
we
could
run
into.
A
So
you
could
potentially
make
a
change
in
a
gateway,
class
parameter
or
even
gateway
class,
with
the
allowed
route
namespaces
that
would
potentially
break
or
significantly
disrupt
your
gateway,
which
again
feels
like
something
like
that
is
dangerous,
especially
if
it
could
apply
to
a
large
number
of
gateways
at
once.
F
A
Yeah
yeah
it
is,
it
is
a
very
real
potential
issue
there
as
well
there.
There
is
a
lot
less
guidance
in
that
api
as
far
as
what
should
or
should
not
be
done
and
very
minimal
guidance
around
conflict
resolution
and
and
I'd
say,
the
potential
and
obviously
this
is
going
to
be
different
per
implementation,
but
it
feels
like
a
potential
conflict
or
potential
disruption
could
be
even
greater
at
this
level,
because
this
api
could
potentially
be
controlling
even
more
resources,
potentially.
B
A
It
depends
on
your
ingress
implementation
and
your
gateway
implementation
and
what
those
map
to
and
whatever,
but
either
way,
yeah
you're
right,
there's
already.
E
Yeah,
to
give
some
context,
we
went
to
the
storage
folks
because
they
have
storage
class
to
ask
their
advice
on
this,
and
this
thing
is
exactly
what
they
told
us
to
that.
They
wish
they
did.
A
Yeah
the
the
idea
of
finding
some
kind
of
way-
and
this
this
admittedly
gets
really
messy.
I
don't
know
that
there
is
great
prior
art
here
other
than
that
you
know
wish.
They
took
this
approach
kind
of
thing,
but
the
idea
is
okay.
If
you
can
say
a
a
gateway
class
is
almost
more
template-like
than
anything
that
you
know
it.
The
gateway
created
from
a
gateway
class
is
contains
a
set
of
properties
from
the
gateway
class.
At
that
point,
in
a
sense,
that's
helpful,
but
it
it
comes
with
other
potential
negatives,
including.
A
A
F
E
A
F
So
I
might
have
got
the
wrong
end
of
the
handle
or
what
I
thought
you
were.
What
I
thought
you
were
saying
was
that
when
you
was
that
the
attributes
of
the
gateway
class
pinned
to
basically
snapshotted
and
become.
A
A
A
But
I
I
don't
know
the
right
balance
there,
because
I
know
if
we
go
too
far
that
side
then
gateway
class
starts
to
lose
its
meaning,
especially
if
it
changes
significantly.
A
You
have
multiple
gateway
classes
of
say
I
don't
know
external
load
balancer
class.
And
what
do
you
know
at
some
point?
Somebody
decided
it
shouldn't
actually
represent
an
external
load
balancer
and
they
flip
that
switch,
and
so
some
of
those
with
that
class
mean
one
thing
and
some
of
those
mean
something
else.
I
think
that's
a
really
extreme
example,
but
if,
if
we
went
too
far
with
this
kind
of
snapshotting
and
point
in
time
gateway
class,
meaning
we
could
end
up
there.
F
A
Yeah,
that's
that's
a
great
question.
You
know
in
a
sense,
I
I
feel
like
they're,
you
know
something
like
a
timeout
feels
relatively
mundane
and-
and
it
seems
like
the
kind
of
thing
that
at
least
in
some
cases
could
be
again.
This
is
so
implementation
specific,
but
I'm
assuming
a
number
of
implementations
will
be
able
to
make
that
change
without
any
kind
of
dramatic
breaking
destructive
effects.
F
But
you
can
also
break.
You
could
also
quite
easily
break
everybody's
virtual
hosts
all
at
once.
D
A
Yeah
yeah:
that's
that's
exactly
exactly
what
I'm
proposing
yeah.
E
One
interesting
point,
though,
is
that
if
you
have
to
do
that,
you
might
as
well
get
the
snapshotting
behavior
anyways,
because
you're
going
to
be
doing
it
kind
of
to
support
that
the
difficult
one
is
not
the
delete.
The
difficult
one
is
the
editing,
the
gateway
class,
I'm
fairly
certain.
There
are
going
to
be
parameters
that
are
extremely
awkward
to
edit
and
because
kubernetes
doesn't
doesn't
have
like
a
way
to
kind
of
corral
the
kind
of
edits
you
can
do
at
least
easily.
A
And-
and
you
know
maybe
to
take
this
one
step
further
it.
This
is
potentially
further
complicated
by
the
idea
that
most
of
the
parameters
we're
talking
about
are
likely
not
going
to
be
on
gateway
class
itself,
but
instead
on
the
parameters
resource
that
a
gateway
class
references
and
as
such,
those
parameters
could
be
any
number
of
things
that
may
not
actually
have
a
way
to
consistently
like
we.
A
We
would
be
a
top
level
gateway
class
parameter,
I'm
not
actually
sure,
and
then
that
could
have
a
place
in
gateway
configuration
as
well.
It
gets
a
lot
messier,
at
least
in,
in
my
opinion,
for
some
very
implementation,
specific
parameters
that
we
would
also
potentially
like
to
lock
in
place
at
creation
or
at
least
set
at
creation
and
then
have
those
stay
tied
to
the
gateway
and
not
the
gateway
class.
A
So
I
this
this
is
a
bigger
topic
and
as
as
I'm
thinking
about
it
more-
and
I
I'm
realizing
that
this
on
its
own,
although
it's
related
to
conflict
resolution,
is
likely
worthy
of
its
own
issue,
just
just
on
its
own,
because
there's
a
lot
of
potential
for
change
here,
yeah
I,
the
whole
gateway
class
is
great
except
the
life
cycle.
Conflict
resolution
is
pretty
difficult
to
to
manage.
A
Well
without
the
potential
for
disruptive
or
breaking
changes
or
yeah
like
like
bowie,
said
I
or
meant
in
chat,
you
can
always
make
everything
immutable
and
that
that
would
work
it's
just.
It
just
means
that
you
would
end
up
with
a
lot
of
gateway
classes
and
but
that
that
would
work
if,
if
a
gateway
class
is
forever
and
always
the
same
thing,
and
then
you
just
end
up
with
lots
of
gateway
classes
with
new
versions.
F
Yeah
my
attention
wandered
for
a
second
and
when
bo
made
a
comment
saying
this
is
what
the
storage
class
folks
told
us
to
do
given
their
experience,
could
you
remind
me
what
he
was
referring
to.
A
Okay,
yeah
sure,
so
this
so
storage
class
has
parameters,
storage
classes.
You
know
probably
the
best
example
of
something
like
long
live
that
is
at
least
somewhat
familiar
to
gateway,
class
and
storage
class
as
well
sig
storage.
A
I
can't
remember
who
we
specifically
talked
to
from
let's
say,
but
I
think
that's
odd
anyways,
he
he
recommended
or
well
he
mentioned
that
if
they
could
do
it
all
over
from
scratch,
it
would
be
nice
if
you
could
freeze
those
parameters
when
a
new
persistent
volume,
whatever
whatever
it
happens,
to
be,
maybe
whatever
whatever
the
equivalent
in
in
that
space
is,
is
created
that
those
parameters
are
stuck
with
that
pv
instead
of
the
the
weird
potential
state
changes
that
that
was
my
interpretation
of
that
conversation,
but
we
feel
free
to
correct
me
on
that
one,
but
it
again
it's
related
to
this
whole
thing
of.
E
Yeah,
I
think
we
can
talk
to
them
more
to
get
an
understanding,
but
I
think
right
now,
if
you
edit
the
storage
class,
the
behavior
is
just
kind
of
underspecified.
That
was
my
impression.
E
F
Oh
okay,
I
was
going
to
I
just
it
just
occurred
to
me.
That
upgrades
are
also
an
interesting
coin
case
for
this
for
in-cluster
ingressors,
when
you
upgrade
the
controller.
That
does
that
you
know
upgrading
the
controller
changes
things
right
to
your
gateway
class,
so
it's
no
longer
immutable.
You
might
upgrade
you
might
need
to
up.
You
might
have
to
upgrade
your
configuration
at
the
same
time,
but
you
certainly
don't
want
to
remove
all
your
gateways
in
order
to
have
to
do
that.
A
A
Which
is
great,
but
this
crd
is
going
to
be
implementation
specific,
this
parameter
crd.
So
you
know
we
can't
enforce
a
specific,
a
specific
pattern
here,
but
we
can
certainly
recommend
one.
E
Yeah,
I
think
it's
worth
talking
about
just
because
implementers
will
hit
this
right
away
and
we
should
have
some
advice
as
to
like
hey.
We
should
handle
it
like
this
or
maybe
like
one
or
two
choices,
especially
if,
like
we,
what
we
don't
want
is
to
kind
of
just
have
a
like
a
c
e
language
like
unit
you
know,
was
like
undefined
behavior,
where
it
just
kind
of
could
blow
up
in
very
strange
ways.
E
A
Yeah
I
mean
to
and
to
go
off.
I
think
it
was
mikaya's
idea
of
you
know
basically
setting
parameters
on
the
gateway
or
associating
them
with
the
gateway.
A
D
I'm
not
sure,
that's
quite
what
I
meant.
Okay,
I
I
was
saying
the
gateway
class
specifies
parameters.
The
gateway
can
specify
parameters
overriding
what's
in
the
gateway
class,
then,
if
you.
A
D
A
But
I
think
I
think
a
very
similar
idea
to
that
would
be
the
you
know
just
copy
those
defaults
and
and
set
them
on
creation
and
gateway
owners
can
then
override
them
with
whatever
custom
values
they
want
from
there
on.
E
There
are
languages
where
prototypes
are
well,
that's
different,
javascript.
A
A
So,
if
you
think
of
anything
else
that
you
think
you
should
add-
or
we
should
cover-
please
go
ahead
and
do
that
I've
added
a
few
things
since
the
last
time
we
talked
about
conflict
resolution,
so
there's
there's
plenty
that
could
use
feedback
here,
so
that's
it
for
today.
I
guess
I
know
we're
already
over
time,
but
thanks
to
everyone
for
the
great
conversation
and
feedback.