►
From YouTube: SIG Network Gateway API Office Hours 20200930
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
september
30.
This
is
office
hours
for
service
apis.
We
are
really
knocking
items
out
here
harry.
It
looks
like
you
had
a
couple
things
at
the
top
of
the
agenda,
starting
with
this
issue.
B
B
A
In
the
comment
below
is
a
good
one
that
this
would
certainly
complicate
any
kind
of
conflict
resolution.
D
A
Yeah,
I
mean
right
now
our
pattern
elsewhere,
where
we've
used
regex,
is
that
it
is
not
portable
and
it
depends
on
the
implementations,
regex
implementation.
B
A
Well,
yeah,
except
we
technically
do
have
a
regex
type
somewhere,
which
is
similar
to
implementation
specific,
but
maybe
slightly
different.
So.
B
E
B
Yeah
yeah,
I
mean
you
can
actually
use
engine
x
to
do
this
today.
You
can
also
do
I
think
you
can
also
use
kong
to
do
a
similar
thing
like
this
today
as
well.
So
you,
you
users,
want
like
this
in
addition
of,
like
whatever
they
want
to
do
with
regular
ingredients
like
this
is
a
very
specialized
use
case,
but
I
think
the
reason
I
added
it
in
here
was
like
we
don't
define
it,
so
it
would
be
like
an
undefined
api
surface,
and
if
somebody
wants
to
do
it,
they
can
do
it
right.
B
A
Yeah,
I
mean
there's
very
little.
We
can
do
with
what
we
have
with
just
keybuilder
tags.
A
A
F
F
That
one
makes
more
sense
just
because
it's
it
wasn't
ingress
and
we
added
it
and
it
seems
to
be
reasonably
limited.
I
think
we
can't
even
debate
whether
it
goes
in
alpha
or
we
just
tack
it
on
like
immediately
afterwards,
just
from
time
perspective,
but
this
one
is
pretty
complicated
because
it's
not
only
a
regex
with
a
capture.
Also
there's
a
substitution,
like
you
know,.
B
A
Think
we
I
agree
with
that.
I
I
think
it
would
be
good
to
add
some
kind
of
documentation
for
v1
alpha
1
for
hostname
just
so
it's
a
little
bit
more
clear
what
is
and
is
not
accepted.
A
A
F
A
I'm
going
through
our
milestone,
I
feel
like
we
just
keep
on
adding
things.
I
know
I
have
done
that
a
lot.
A
I
think
this
one
and
this
one
are
going
to
be
solved
by
the
api
cleanup
pr,
at
least
that's
the
intention
of
that
pr.
I
haven't.
I
opened
a
pr
just
this
afternoon
to
solve
this
one.
C
A
Good
lots
of
documentation,
ones
here,
yeah
at
some
point,
it
would
be
good
to
just
if,
if
anyone
is
is
feeling
like
they
have
a
bit
of
time
to
spare.
If
you
want
to
just
assign
yourself
to
one
of
these
issues,
please
do
by
all
means
these
documentation
pages
would
be
really
great
to
get
updated.
I
think
our
api
is
starting
to
stabilize
here.
F
Yeah,
can
we
figure
out,
if
it's
possible,
to
set
up
a
schedule
where
we
start
cutting
like
rc1
rc2
equivalents,
where
those
that
snapshot
is
something
that
we're
actually
going
to
send
for
reviewers
for,
like
an
overall
review.
D
A
A
Yeah,
I
think
that's
a
really
interesting
idea.
How
would
we
determine
that?
We
were
ready
to
you
know,
tag
a
release
candidate.
F
Like
what
about
this
week,
maybe
yeah
end
of
this
week.
A
Okay,
so
and
the
definition
of
a
release
candidate
would
really
just
be
tagging
a
commit
and
getting
up
right.
You
know
like
pushing
a
tag
up
that
is
b1
alpha
one
rc
one:
yes,
yes,
okay,
yeah!
That
seems
very
reasonable.
A
A
C
D
F
And
then
we
can
make
this
like
every
week
or
I
would
say
every
week,
let's
just
try
to
make
progress.
What
is
your
expectation
for.
F
Oh,
it's
just
a
snapshot,
so
people
can
look
at
basically
right
now,
it's
like
some
pieces
might
be
still
a
little
bit
to
do
or
not
cleaned
up.
I
would
say
for
the
rc
that
everyone
has
read
through
it
and
made
sure
that
there's
nothing
egregious.
That's
still
like
there's
like
some
dangling
to
do
somewhere
that
hasn't
been
committed
or
is
like
part
of
a
discussion
just
so
that
if
someone
wanted
to
read
it
front
to
back,
it
would
be
in
a
consistent
state.
E
A
To
me
at
least,
a
release
candidate
seems
like
it
could
be
a
helpful
way
for
anyone
that
is
starting
to
work
on
an
implementation
of
this
api.
It
seems
like
it
would
be
nice
to
have
just
a
release
candidate
to
base
that
off
of,
as
we
start
to
stabilize,
instead
of
just
some
kind
of
commit
hash
at
some
point
yeah,
I
don't
know.
A
Okay,
cool!
Well,
we
can
discuss
a
bit
more
tomorrow,
but
yeah
that
that's.
That
seems
like
a
great
idea.
A
Thank
you
all
right,
so
yeah
we've
got
a
few
things
for
documentation,
really
all
the
things
it
seems
like
more
documentation.
A
Have
we
have
we
resolved
this
already?
Maybe
we
haven't
some
of
these.
G
Hey.
Bravo.
Do
you
mind
finding
some
more
information
about
that
feedback?
Page?
It's
issue
three.
Three,
four
yeah
yeah.
C
And
so
the
feedback
a
little
bit
sorry
go
ahead,
you
got
it.
No,
don't
worry.
G
I
was
just
going
to
say
I
tried
to
make
an
issue
and
it
seemed
like
we
already
kind
of
had
that
general
flow,
and
I
started
going
down
the
path
of
like
trying
to
think
of
different
interesting
ways
that
we
would
want
to
track
things.
I
think
it's
probably
too
early,
but
I
guess
I
think
there
is
some
interesting
opportunities
to
like
auto
classify.
I
guess,
as
we
start
to
scale
up
from
gateway
all
these
different
route
types
like
on
the
triage
side
of
things
down
the
road.
G
C
A
Yeah,
no,
that's
a
great
question.
I
appreciate
you
asking
and
volunteering
to
take
this
one
on.
I
think
the
the
biggest
thing
is.
We
have
a
big
to-do
block
here,
so
removing
that
is,
you
know
a
great
a
great
starting
point.
We
already
have
issue
templates
on
github,
so
I
don't
think
we
really
need
to
recreate
those
issue
templates
here.
A
A
G
H
Rob
can
you
stay
there
for
a
second
and
yeah?
You
know.
I
know
we
discussed
this
a
little
bit
yesterday.
We've
got
overnight
instructor
last
week
where
we
talked
about
documentation
and
and
maybe
taking
a
step
back
and
just
kind
of
looking
and
assessing
kind
of
the
overall
structure
of
our
documentation,
and-
and
this
may
be
kind
of
a
good
example
here,
where
I
mean,
is
feedback
part
of
how
to
contribute
right,
I
mean
that
is
actually
a
way
to
contribute.
H
So
if
we
look
at
feedback
here
and
if
we
leave
it,
as
is
it's
gonna,
be
a
page
that
has
very
minimal
content.
If
we
now
click
on
how
to
contribute,
do
you
mind
clicking
there
really
quick
and
let's
just
see
what
we
have
there
community
I
mean
yeah.
Do
we
think
that
maybe
just
actually
taking
that
feedback
and
putting
that
as
a
section
on
how
to
contribute
to?
F
That
makes
sense
to
me
as
long
as
it's
discoverable
by
users,
so
we
should
just
make
it
at
the
very
top
yeah.
A
H
Yeah
yeah,
I
like
that
idea
into
bowie's
point
like
you
know,
making
it
very
clear
in
you
know,
in
the
user's
space
and
how
to
provide
feedback.
So
that's
a
good
idea
as
well.
A
Cool
okay-
well,
maybe
maybe
both
of
those
I
do
think
how
to
contribute.
Having
some
basic
information
here
about
giving
feedback
is
great
and
maybe
for
bonus,
points
a
link
up
top.
If,
if
it's
not
too
hard,
it's
been
a
while,
since
I
messed
with
this,
I
I'm
the
one
who
added
the
github
link
and
I
think,
but
I
can't
remember
it
seemed
not
too
bad,
but
it's
been
a
while
so
yeah.
G
Yeah
no
worries
could
just
I'll
probably
try
to
just
pile
that
all
into
that
same
one,
then.
H
H
Because
again
it
just
seems
like
maybe
with
all
of
our
eyes
on
this-
that
we
could
get
a
feel
of
the
current
structure,
makes
sense
and
and
that
kind
of
stuff
yeah.
I.
A
So
I
you
know
that
I
think
this
is
a
reasonable
first
start.
This
is
just
my
own
take
on
this.
It
does
feel
like
we
could
use
a
little
bit
more
of
an
introduction
here
than
we
have
right
now.
A
F
One
thing
that
was
interesting
was:
I
saw
that
we
have
examples,
I'd
like
to
figure
out
how
to
automatically
throw
them
in
the
cookbook.
Maybe
I
can
take
that
on
because
I
would
like
to
not
have
to
cut
and
paste
from
the
examples
back
to
the
cookbook
and
then
back
and
forth.
Yeah
right.
H
I
was
going
to
say,
and
instead
of
cookbook
I
mean,
is
it
just
maybe
examples,
and
then
you
click
there
or,
and
it
just
takes
you
to
the
examples
directory
of
the
repo
or
or
maybe
maybe
it
takes
you
to
the
examples
page,
and
we
have
kind
of
the
breakdown
of
the
examples
where
it's
like:
okay
for
http
route,
or
maybe
a
few
different
examples.
But
it
seems
like
we
already
have
those
examples
there
and
it's
just
a
matter
of
pointing
people
to
them.
Unless.
F
H
Standpoint
instead
of
calling
it
a
cookbook
just
the
examples
you
know
like
sort
of
right,
you
know
the
consistency
with
the
name
as
well
would
be
nice.
H
Like
you
know,
we
have
the
examples
section
and,
like
you
said
right,
we
kind
of
look
at
these
instead
of
just
pointing
everyone.
Hey
here's
our
examples,
as
you
mentioned,
bowie
is
like
we
on
the
doc,
sweat
page
we've.
H
You
know,
we've
got
an
examples
section
and
we
kind
of
look
through
here
and
say:
okay,
is
there
a
way
to
kind
of
group
these
and,
and
if
we
group
them,
maybe
it
makes
sense
by
like
a
gateway
class
gateway,
almost
like
a
user
workflow
example,
but
I
don't
know
I
I
do
think
the
more
I
think
about
it.
We
talk
about.
It
does
make
sense
instead
of
just
pointing
people
at
these
examples
of
we
have
some
texts
and
see
if
we
can't
maybe
organize
these
examples
into
a
few
example
workflows.
A
Yeah,
I
agree,
I
think
I
yes,
I
I
had
cookbooks
here.
I
do
think
I
prefer
examples.
This
is
a
tiny
thing
and
let
me
go
ahead
and
just
change
this.
A
H
And
if
bowie
said
he
was
taking
it
out,
I'm
not
sure
if
this
is
already
assigned
to
bully.
But
if
not
maybe.
F
D
A
A
Let's
see,
I've
already
got
a
pr
that
should
hopefully
solve
this
one,
all
right
james.
I
don't
know
if
we've
discussed
this
issue
yet
patch
types
for
conditions.
E
No,
I
don't
think
we
discussed
it
in
a
co
I,
so
this
is
the
annotations
that
you're
kind
of
supposed
to
put
on
condition
slices
to
make
them
work
like
maps
with.
So
you
get
one
condition
per
key
per
condition
type.
So
yeah.
I
think
you
pointed
out
on
the
review
that
this
doesn't
actually
change
the
cid.
E
So
that's
a
little
bit
interesting,
so
I
think
we
still
want
to
have.
We
want
to
have
the
same
semantics
we
want
to
have.
We
want
to
have
these
semantics,
but
I'm
not
sure
that
there's
a
way
to
enforce
that
through
cid
generation
or
whether
that
primary
kk
generators
do
something
different
yeah.
So
what
probably
is
requires
me
to
do
a
bunch
of
groveling
through
repos
and
to
figure
out
what's
what's
going
on.
H
Here,
yeah
nice-
and
I
saw
some
of
this
rob
with
your
api
cleanup
pr
where
it's
like
the
gateway
conditions,
have
these
annotations,
along
with
some
of
the
defaulting.
H
H
Well,
the
default
and,
and
having
some
of
these
other
annotations
that
james
points
out
here.
A
Yeah
I
mean
I,
I
think
this
is
good.
I
I
don't
you
know
the
the
concern
about
these
annotations
is,
if
they're
not
doing
anything,
it
might
give
the
appearance
of
effectiveness.
Even
if
you
know
there's
nothing
happening
behind
the
scenes
yeah.
I
don't
know
what
the
what
the
status
is
here,
but
and.
H
Yeah
I
mean
I'm
for
that
too,
like
if
they're
not
doing
anything,
then
then,
then
I
would
say:
let's
remove
them
off
of
the.
What
is
it
the
gateway
conditions?
I
guess
the
point
I'm
trying
to
make
is
just
like
having
that
consistency.
So
when
we
look
at
the
conditions
and
like
unless
there's
a
reason
why
they're
they're
not
consistent,
otherwise,
someone
may
come
across
and
say
well.
Why
is
you
know?
Why
does
this
condition
have
different
behavior?
You
know
gateway
status,
condition,
a
different
behavior
than
a
listener
condition.
E
You
know
so
I
think
these,
I
think
the
semantics
of
conditioned
slices,
I
agree,
should
be
the
same
everywhere
in
the
absence
of
any
way
to
enforce
those
semantics.
E
E
A
What
else
have
we
not
covered
yet
harry
this
regex's
support
for
path
and
header
matching.
B
Yeah,
I
think
it's
a
dark
update
that
I
have
to
get
around
to
okay.
This
was
also
I
yeah.
I
think
there
is
some
feedback
from
I
think,
tame
and
dan
as
well,
so
I
think
yeah
I've
got.
I
know
what
to
do
here.
I
just
haven't
got
around
to
it.
D
B
B
E
I
think
the
questions
were
around
module.
Vendoring,
okay,
john,
had
a
question
about
whether
mod
equals
vendor
was
what
we
actually
wanted.
I
think.
F
E
Had
a
question
about
whether
we
really
should
force
the
modules
to
be
populated,
not
sure
I
have
good
answers
to
either
of
those
apart
from
poking
at
it
a
bit
more.
The
problem.
E
With
the
vendor
directory,
is
that
ui
they
kind
of
have
it?
Well,
you
either
don't
have
it
or
you
have
it
fully
populated
or
you
have
it
out
of
sync
with
the
go
modules
right
right,
so
maybe
at
least
one
of
those
is
going
to
break
you
potentially
two
of
the
potentially
two
of
those
cases
are
gonna
like
not
work
for
different
people's
conflicts.
E
I
don't
know
about
read
link,
that's
just
how
I
do
it
so
boy,
that's
just
how
I
always
do
it
when
I
need
the
full
path
and
I
need
the
full
path
to
make
a
sim
link.
F
F
E
A
A
I
think
that's
all
for
what
what
we
have
left
in
b1
alpha,
one
at
least
right
now,.
H
H
It's
like
you
know
I
just
as
I
read
through
another
spec,
I'm
like
it
just
seems
like
it
reads
better
this
way,
even
though
you
know
match
would
still
be
a
plural,
and
I
appreciate
your
comment
and
it
looks
like
you
know,
there's
examples
for
using
matches
as
well
as
match,
but
I
wanted
to
open
up
for
a
quick.
A
Yeah,
I
I'll
just
echo
my
comment
earlier
that
I
don't
mind
this
change.
I,
the
idea
between
match
becoming
singular
is
that
it
feels
inconsistent
with
host
names
being
plural
right
above
it
and
hostname.
Singular
feels
especially
strange
to
me.
On
the
other
hand,
forward
two
is
an
example
of
something
that
is
singular.
That
also
is
the
name
of
the
list.
A
So
those
are
the
two
examples
I
I
could.
I
think
we
could
argue
one
way
or
the
other
in
the
route
type.
I
don't
feel
strongly
enough
on
this
one
to
argue
one
way
or
another,
but
I
I'm
also
very
open
to
feedback
or
thoughts
from
anyone
around
us.
B
B
Not
everything
takes,
if,
like
you
know,
effect
at
the
same
time
in
case
of
match
and
matches,
I
mean
matches
probably
give
you
like.
This
is
probably
my
brain
thinking
this
way,
but
matches
tell
me
that
each
and
every
match
is
independent
right,
the
like.
If,
since
in
the
example
we
have
right
now,
we
have
a
path
of
prefix
bar
right.
No,
that's
not
a
good
example.
The
next
example
we
have
right,
headers
of
exact
matching
and
then
a
path
of
prefix
match.
They
are
added
together.
B
A
That
is,
that
is
a
great
point,
the
the
distinction
between
whether
you
would
interpret
this
as
an
and
or
an
or.
A
H
No,
no,
I
think
I'll,
just
kind
of
let
this
sit
and
it's
obviously
not
pressing,
but
it's
just
something
that
caught
my
eye
and
wanted
to
open
it
up
for
discussion.
So
thanks
for
that
cool.
A
And
speaking
of
something
that
is
not
necessarily
pressing,
but
it's
interesting,
tim
got
a
chance
to
look
through
at
least
part
of
this
doc
again
and
so
he's
left
some
comments
on
our
pre-alpha
review,
but
it's
a
really
long
dock.
We
have
a
a
big
api.
It
turns
out.
I
think
it's
turns
into
40
some
pages,
one
of
the
things
that
came
up
pretty
quickly.
A
He
is
not
sold
on
even
the
revised
allowed
gateway
namespaces,
which
this
this
field,
or
this
concept
is
continuing
to
be
a
challenge.
He
is
trying
to
get
some
people
together
from
different
stakes
like
six
storage,
sig,
sega,
etc
to
to
get
their
perspectives
as
well
and
and
storage,
specifically
because
of
the
storage
class
firearm
so
ongoing
there,
but
the
the
these
were.
You
know
that
you
know
this.
These
are
the
comments
he
left,
what
what
was
it
friday
september?
28Th
yeah,
that's
friday,.
H
Rob
with
that
point
and
since
mikaya
is
on
last
time
we
discussed
this
there
mikhail,
didn't
you
kind
of
bring
up
a
different
approaches
using
yeah
our
back.
D
F
Okay,
yeah
there's
also,
apparently
you
can
do
this
with
quota,
but
not
with
this
specific
thing.
So
we
are
the
other
one
is
runtime
class.
Is
another
class
well
has
class
in
the
name,
but
that
one
is
in
signo,
so
it
seems
to
be
cross-cutting.
A
Yeah
yeah
and
there's
there's
been
recent
recent
discussions
in
sight
around
name
space
labels
and
their
security,
and
I
don't
know,
there's
a
lot
of
movement
in
this
space
and
no
one
seems
to
like
anything.
I
that's
that's
my
take,
so
I
don't
know
I
I'm
interested
in
in
who
we
can
get
together
and
what
kind
of
feedback
we
get
from
other
cigs
on
this.
E
A
E
With
if
with
tim's
suggestion
to
use
oper,
what
we
started
doing
in
contour
project
is
providing
examples
for
with
gatekeeper
configuration,
and
so
the
idea
is
that
people
can
install.
E
A
Yeah
I
mean
the
more
we
the
more
we
push
forward
on
this
and
then
push
back,
and
so
on
the
the
more
I
am
wondering
if
this
is
something
that
needs
to
be
part
of
the
one
alpha
one
like
it
is
a
a
good
concept,
but
this
field
does
not
have
to
be
implemented
by
us
like
this.
It
would
be
great
if
we
could
do
it
natively,
but
there
are
lots
of
web
book
implementations
like
gatekeeper
opa
that
can
solve
this
and
kind
of
leave
the
leave
it
as
someone
else's
problem,
at
least
initially.
F
That
easily
I
mean
I
don't
rob,
I'm
not
so
sure
about
that,
because
opa,
you
can
literally
do
anything.
Can't
you.
A
F
A
Yeah
yeah,
it
can
be
yeah,
it
can
be
some
other
capability.
What.
A
F
F
A
No
yeah
sure
I
agree
with
that,
and-
and
this
is
not
me
giving
up
on
this
field,
this
is
just
saying
that
you
know,
depending
on
what
on
what
we
get
in
terms
of
feedback
from
sega
from
storage,
from
whoever.
A
F
A
Well,
I
mean
even
you
know
upstream
even
alpha,
it
is
hard
to
make
huge
breaking
changes.
I
don't
know
I
mean
I.
A
H
I
was
gonna
say
if
it's
in
here
people
use
it
and
people
kind
of
build
their
mental
model
around
okay.
This
is
how
you,
how
you
secure
things
as
opposed
to
not
having
it
in
there
and
kind
of
leaving
it
open
for
like
out
in
the
wild
for
people
to
see
if
they
could
come
up
with
ideas
on
how
to
solve
the
problem
and
then,
as
there's
a
consensus
around
ways
to
solve
that
problem,
then
we
bring
it
in.
F
What
I
would
like,
though,
is
to
have
some
way
to
solve
the
problem
right
like
if
we
just
punch
it
completely,
then
there's
no
way
to
solve
the
problem.
So
if
we
have
some
simple
cookbook
that
we
can
follow
to
kind
of
solve
the
problem,
I
just
want
it
there
for
alpha,
so
people
are
able
to
play
with
it
and
kind
of
understand
it.
Otherwise
we
get
no
information
and
then
I
feel
like
that
is
sort
of
a
worse
result.
H
That's
reasonable,
as
we
keep
it
in
now
sounds
like
mikaya
is
making
progress
on
an
idea
that
right
using
our
back
that
we've
discussed-
and
we
think
is
in
you
know,
is
a
valid
approach
and,
let's
see,
if
you
know,
mikaya
is
able
to
get
to
a
point
that
we
can
really
assess
just
using
our
back
and
if
that's
the
case,
I
think
that
gives
us
a
little
more
flexibility
that
if
something
else
comes
along,
we
could
always
pivot
away
from
our
back
easier
right.
F
H
Yeah,
no
it's
I
I
yeah.
I.
F
H
That
idea-
and
you
do
bring
up
a
point,
that
it's
like
okay,
even
if
we
remove
it
down
down
the
road
I
mean
this
is
alpha,
and
so
you
know
implementers
are
just
gonna
have
to
expect
that
there's
gonna
be
potentially
some
big
changes
still
occurring.
A
A
A
There
there
are
a
few
other
comments.
I
don't
know
that
we
have
time
for
all
of
them
this.
This
is
one
interesting
one
that
we
should
add
some
kind
of
bullet
to
describe
how
we
would
support
additional
protocols.
A
A
And
yeah
there's
there's
a
bunch
more,
but
I
know
we
have
more
to
go
through
as
far
as
prs
and
issues.
So,
if
you
on,
if
you
want
to
look
through
these
comments
on
your
own,
I
linked
it
in
the
agenda
and
I
think
at
least
someone
else
is
looking
at
it
now
the
one.
So
I
I
added
a
couple
pr's
today,
I'm
not
anticipating
getting
through
all
of
them,
but
this
was
actually
this
specific
one
was
already
covered.
A
This
oh
yeah,
this
specific
one
was
added
based
on
some
of
the
feedback
that
tim
added
in
that
doc,
and
it
also
is
based
on
some
feedback
from
harry
of
only
same
namespace
being
less
than
ideal.
A
A
Selector,
maybe
that's
a
thing,
I
think
a
really
obvious
point
of
extension
that
I
almost
added
here
would
be
a
from
anywhere
option.
Technically
you
can
accomplish
that
with
from
selector
and
then
empty
selector.
So
I
left
that,
but
I
think
from
anywhere
is
a
very
obvious
next
step,
what
what
does
from
anywhere
mean
any
space.
F
A
A
A
Yeah
yeah
yeah,
so
that
that
is
that
change
this
and
another
pr
I
made
today
are
based
on
this
api
cleanup
pr,
there's
just
so
much
so
many
fields
changing
in
this
api
cleanup
pr,
I
didn't
feel
like
re-basing
on
top
of
it.
I
know
that
may
be
short-sighted,
but
because
of
that,
this
is
what
it
is
right
now.
I
think
the
api
cleanup
pr
is
super
close
to
getting.
F
F
D
A
This
this
actually
came
as
as
part
of
tim's
first
feedback,
where
he
suggested
adding
a
max
wherever
we
could
and
less
important
min
wherever
it
made
sense.
A
But
the
the
rationale
is:
if
you
don't
have
a
max,
you
don't
have
it's
very
hard
to
to
know
the
upper
limits
of
your
api
and,
to
you
know
a
really
obvious
glaring
example
is,
if
there's
no
max
on
strangling
then,
okay,
you
know
what
are
people
going
to
write
a
book
in
there?
You
know
like
what?
What
is
the?
What
is
that
limit
for
his
guidance?
A
As
I
remember
it
was
to
I
keep
it,
and
I
tried
to
write
this
in
in
the
doc,
where
I
summarized
that
first
feedback
I
got
from
him,
but
was
to
start
with
the
lowest
reasonable
limit
that
made
sense
within
you
know
within
reason,
because
you
can
always
expand
it.
That's
very
easy
to
do
in
a
backwards
compatible
way,
it's
much
harder
to
tighten
up
validation
after
the
fact
like
you
can't
go
from
max
items
of
8
to
max
items
of
4,
because
you're
going
to
break
some
user.
F
The
the
because
I
remember
we
had
to
deal
with
this
in
previously,
I
think
for
ingress,
so
you
can
always
expand
it,
because
even
if
your
cluster
got
upgraded,
someone
created
one
that
was
the
bigger
value
it
got
stored.
Let's
say
you
roll
back
when
you
pull
it
through.
It's
still,
okay,
like
that.
A
Yeah
I
mean
crd
validation
is
pretty
weak
to
begin
with
right,
I
mean
it
whatever,
but
what
what
this
requires
is
if
we,
if
we
upgrade,
if
we
increase
the
limits
in
the
future,
we
would
have
to
make
that
part
of
a
new
api
release
and
versions
would
have
to
explicitly
support
that
api.
A
A
There's
there's
an
extra
intermediate
release
in
between.
I
don't
think
that's
needed
we're
still
in
alpha,
but
the
important
thing
was
having
an
upper
limit
and
having
that
upper
limit,
something
that
was
unlikely
to
decrease.
A
Yeah
yeah
and
that
that's
fine
conditions.
This
was
a
relatively
low
number
I'll
agree.
I
think
we
had
some
level
of
consensus.
F
A
B
Yeah
and
to
add
to
that
in
some
places,
like
conditions,
is
a
good
example.
If
you
have
more
than
eight
conditions
for
the
end
user
experience
is
not
too
good.
You
know
you
want
to
limit
that.
So
that's
one
reason
to
to
have
smaller
limits
is
making
sure
that
if
users
are
using
a
certain
field
or
a
certain
config
and
if
they
are
trying
to
abuse
it
or
they're,
trying
they're
being
very
creative
with
it
and
that
you
there
is
a
use
case
that
we
didn't
account
for
right.
B
F
Okay
yeah,
I
do
agree
with
the
fact
that
we
should
limit
everything.
We
should
just
be
very
careful
about
just
not
making
it
like
way
too
small
yeah
yeah.
That
was
what
I
was
wondering
about-
is
that
when
we
carry
this
over
to
beta
ga,
it
will
definitely
become
an
issue
where
changing
the
limit
will
take
will
be
you
can't
just
do
it
in
one
release.
A
Yeah,
it's
that's,
that's
a
little
bit
interesting,
we'll
have
to
see,
but
I
think
for
alpha
at
least
I'd
rather
start
small
and
see
where
we
run
into
issues
and
not
just
assume
that
this
is
going
to
be
too
small
of
an
issue,
especially
with
conditions
like
more
than
eight
conditions
on
a
resource
seems
like
maybe
not
ideal,
but
I
don't
know.
B
Two
boys
questions,
so
I
have
a
question
maybe
spending
too
much
time
here,
but
you
can't
change
the
number
of
like
the
max
item
on
a
field
without
a
release.
Maybe
that's
true
for
k,
slash,
k,
but
custom
resources,
even
after
v1,
like
ga,
they
keep
on
adding
new
fields
right,
I
mean
that's
true
for
even
core
kubernetes
resources,
as.
A
Increasingly
16.
like
that,
that's
that
is
a
a
great
question
and
one
of
the
things
kubernetes
has
that
we
don't
have,
and
that
is
a
distinction
between
releases
and
api
versions.
So
what
happens
so?
This
kind
of
change
would
happen
through
multiple
kubernetes
minor
releases,
but
you
might
not
need
to
change
the
api
version.
A
You
would
you
would
just
kind
of
gate
it
in
one
and
then
gradually
let
that
capability
get
added
in
similar
with
new
fields.
We
don't
have
quite
the
same
model
here,
so
I'm
not
sure
what
that
looks
like
and
we
have
multiple
implementations.
If
we
had
a
single
implementation,
that
would
just
be
multiple
releases
of
that
implementation.
A
Yeah.
I
don't
know.
A
A
I
know
they
exist
and
we
should
we
should
try
and
learn
from
them.
I
don't
have
any
great
examples
right
now.