►
Description
Bi-Weekly Service APIs Meeting (APAC Friendly Time) for 20211011
A
All
right
we're
recording
it's
october
11
and
we've
got
a
few
things
to
get
through
first
off.
Well,
actually,
let
me
wait,
I
think
nick
said
he
was
going
to
join
on
the
changelog.
We
we
really
are
awfully
close.
It
feels
like
we've
been
on
the
edge
of
releasing
rc2
for
quite
a
while.
Now
I
got
a
little
bit
of
extra
unexpected
suggested
changes
which
I
think
are
were
positive,
but
those
have
all
been
merged
in
now.
A
I
think
it
should
be
good
for
too
right.
I
think
so.
I
I've
pinged
dan
and
tim
one
more
time
to
to
make
sure
that
they're
they're
good
with
this,
but
their
comments
on
the
signet
review.
Pr
makes
it
sound
like
they
were,
so
I'm
looking
for
that
final
final
bit
of
confirmation,
but
I
I
think
we're
good
to
go
here
and
again.
This
is
rc2,
so
I
think
we'll
be
all
right
yeah.
So
that's
that's
everything
for
rc2!
I'm
excited
to
get
it
out.
Thank
you.
A
B
A
Yeah
thanks
for
confirming
there
yeah
cool
thanks
for
all
the
help
with
getting
this
change
log
out
all
right,
so
I
wanted
to
revisit
this
doc.
That
is,
I
think
we
discussed
this
a
meeting
or
two
ago
about
gateway
api
versioning
and
what
what
it
means
once
we
hit
v1
alpha
2.
What
we're
doing
from
that
point
on-
and
I
think
most
of
this
was
fairly
non-controversial
until
we
got
to
this
section,
the
experimental
or
alpha
fields
or
whatever.
A
We
want
to
call
it,
and
so,
based
on
that,
I
went
through
and
went
back
and
chatted
with
jordan
and
daniel
just
to
come
up
with
other
ideas,
and
one
idea
which
I
think
may
be
my
favorite
so
far-
is
to
use
use,
take
advantage
of
crds
as
what
they
are
and
instead
of
trying
to
reimplement
feature
gates.
Instead
of
trying
to
build
our
own
custom
versioning
whatever
we
want
to
call
it,
we
could
release
different
versions
of
the
api,
which
sounds
a
little
bit
scary
on
the
surface.
A
It's
a
way
for
users
to
control
fairly
easily,
if
they're
using
our
experimental
fields,
it
gives
us
the
ability
to
add
and
remove
things
into
an
experimental
kind
of
state,
and
it
seems
like
a
fairly
straightforward
approach.
Instead
of
you
know,
if
you're
familiar
with
kubernetes
upstream,
you
have
this.
A
But
there's
there's
a
lot
to
unpack
in
that.
I
think
it's
a
relatively
simple
concept
that
I
may
not
have
explained
very
well
here,
but
I'm
I'm
interested
if
anyone
has
questions
or
thoughts
on
this
idea
of
instead
of
feature
gates
instead
of
different
api
versions
per
se.
Just
releasing
you
know
experimental
crds,
along
with
our
stable
track,
so
you
have
a
a
stable
track
and
an
experimental
track
of
this
api.
C
A
Yeah,
thank
you.
Yeah.
That's
exactly
the
idea
here.
It's
a
it's
a
way
to
test
out
new
features
which
we
really
do
need,
but
for
that
to
be
purely
opt-in
and
with
the
very
clear
understanding
that,
when
you're
using
an
experimental
version
of
any
crd
it
you
know
the
next
version
of
that
crd
could
remove
a
field
because
you're
in
the
experimental
world.
A
B
Yeah
I,
like
I'm,
plus
one
on
the
experimental
version
of
cid
as
long
as
yeah.
I
think
we'll
just
need
to
be
careful
about
how
we
write
the
contract
around
it
and
what
we
expect
implementers
to
do
and
that
sort
of
thing
yeah,
because
the
implementers
I
mean
the
cost
of
this
puts,
is
that
implementers
need
to.
B
A
A
The
absence
of
that
field
cannot
or
the
the
default
value
of
that
field
cannot
meaningfully
change
how
a
resource
is
interpreted
basically
and-
and
so
we
need
to.
We
need
to
have
very
clear
limitations
on
how
we
can
add
things
and
then,
similarly,
we
need
to
recognize
and
document
that
implementations
may
not
support
experimental
features
of
the
api.
You
know
this
is
this
is,
by
definition,
an
experiment.
A
This
is
something
where
we're
testing
out
to
see
if
it
makes
sense,
and
if
we
get
broad
support
and
broad
interest,
then
it
may
graduate
to
become
a
stable
field,
but
I
I
think
we
we
would
need
to
document
very
closely
that
these
really
are.
You
know
experimental
fields
you
that
both
both
experimental
and
stable
tracks
of
this
api
would
have
the
same
subset
of
fields
and
that's
all
the
stable
fields
and
experimental
ones.
A
Just
potentially
add
some
more
so
this
yeah
it
definitely
need
to
be
very
careful
with
how
we
present
this,
but
I
think
out
after
after
having
this
this
brief
discussion,
I
think
it
it
seemed
like
one
of
our
least.
You
know
probably
our
least
bad
option
out
there.
My
goal
in
presenting
it
here
today
is
I
wanted
to
get.
A
B
Yeah
yeah
yeah,
I
agree
agreed
it's
just.
I
was
talking
more
about
the
the
the
I
I
and
I
I
should
be
clear
that
yeah.
I
consider
that
that's
a
requirement
that
the
experimental
stuff
always
needs
to
be
an
additive
superset
of
the
fields
available
in
the
stable
api.
The
I
was
considering
more
about
how
we
would
actually
do
this.
It
feels
to
me
like
it
would
be
likely
that
we
would
do
this
with
a
different
api
group.
A
That's
that's
actually
a
good
distinction
in
this.
My
in
this
mindset
I
actually
planned
on
having
them
within
the
same
api
group.
So
basically
you
you
can
choose
to
install
external,
experimental
or
stable
apis,
but
they
don't
coexist
really
right.
Like
you,
you
only
really
have
one,
because
experimental
is
just
a
super
set
of
stable.
A
So
hopefully,
hopefully
it
makes
sense.
But
I
I
am
also
very
curious
what
kind
of
feedback
we
get
from
broader
sig
api
machinery
community.
I
think
what
I'm
going
to
do
is
send
out
an
email
to
the
mailing
list
sometime
soon
and
then
add
it
to
the
agenda
for
their
next
meeting,
which
I
think
is
around
a
week
away.
A
A
A
It
seems
like
we're
all
pretty
agreed.
I
haven't
actually
replied
to
this
one
myself,
but
I
agree
with
what
everyone
else
has
said
here
specifically
harry's
suggestion
that
it
could
help
just
to
standardize
on
these
options,
but
not
necessarily
be
too
prescriptive
about
how
they're
implemented
or
what
it
what
it
means
to
be
conformant,
but
just
standard
standardized
terms
for
for
specific
things,
such
as
min
tls
version.
A
B
I
feel
pretty
strongly
that
about
the
name
spacing
name
spacing
the
keys
here
for
stuff.
That
is,
implementation.
Specific
you
know,
might
want
like
the
ones
for
contour
will
be
project
contour
at
I
o
setting
name
or
something
like
that,
just
so
that
we
don't
end
up
with
people
sort
of
claiming
a
specific
name,
slash
behavior
in
the
short
version,
the
non-namespace
version.
I
think
the
non-native
space
version
should
be
part
of
the
public
api
for
gateway
apis.
A
A
Okay
and
the
last
thing
I
had
now,
this
will
be
a
quick
meeting.
I
think
this
is
just
rough
notes
of
the
things
I
had
in
mind
for
the
next
few
weeks
of
meetings
were
really,
you
know,
nearing
the
end
of
the
v1
alpha
2
cycle,
and
so
I
just
wanted
to
paint
a
broader
picture
of
what
I
had
in
mind
for
the
coming
weeks.
A
Conformance,
I
think,
is
really
going
to
be
a
big
topic.
Nick
you've
been
working
or
thinking
about
a
doc
on
conformance
profiles
that
overlaps
pretty
heavily
with
how
we
structure
our
conformance
tests,
but
I
really
want
to
have
some
you
know:
discussion,
documentation,
etc,
maybe
a
gap
around
these
kinds
of
concepts.
A
So
I
imagine
that's
going
to
be
a
fairly
big
theme
in
the
coming
weeks
and
then
there's
a
couple
features
that
we
really
started
discussion
a
few
a
month
or
two
ago
about
redirects
and
rewrites
and
l4
route
matching.
I
I'd
like
to
follow
up
on
those
discussions
and
see
if
we
can
include
them.
You
know
we
basically
said
well.
This
is
additive.
We
can
do
it
after
v1,
alpha
2.
A
C
A
A
A
Good
good
to
know,
yeah,
I'm
glad
there
are
more
people
interested
in
this.
I
think
one
of
the
questions
that
we're
going
to
have
here
is
whether
we
call
this
route
delegation
or
inclusion
right
there's.
There
are
some
use
cases
where
you
know
the
where
I
see
delegation
is
the
one
to
many
and
inclusion.
I
see
one
to
one.
Maybe
that's
not
the
right
use
of
those
terms,
but
I
think
that
fundamental
discussion
of
is
this.
A
Just
I
want
to
include
a
specific
route
or
I
want
to
include
you
know,
delegate
everything
under
foo
to
this
namespace
and
I
think
that'll
be
a
good
good
discussion
to
have
there
jeff
you
you
mentioned
you
have
a
specific
use
case
for
this
is
this
does?
Does
it
fall
into
one
one
or
more
of
those
categories?
I
was
describing
out
of
curiosity.
C
C
C
A
Yeah
that
that
makes
a
lot
of
sense
that
that
lines
up
with
our
initial
use
cases
with
this
and
it's
it's
good
to
have
an
another.
You
know
fairly
concrete
use
case
for
this
kind
of
feature,
so
one
more
reason
to
revisit
that
sooner
than
later,
great
any
other
topics
that
we
may
want
to
cover
in
the
coming
weeks.
Here.
A
Cool
okay!
Well,
I
will
leave
it
at
that,
then
I
know
it's
a
kubecon
week,
so
everyone's
probably
going
in
between
a
bunch
of
different
things,
but
thanks
for
the
great
feedback
and
discussion
on
this,
hopefully
we
can
get
rc2
out
awfully
soon
and
with
that
I
think
I'll
I'll
call
it
a
meeting
unless
anyone
had
anything
else.