►
Description
Service APIs Bi-weekly Meeting (APAC Friendly Time) for 20211018
A
A
We
want
the
same
kind
of
approval
of
sub
sub
project
owners
plus
kept
reviewers
that
we
got
for
v1
alpha
2..
We
we
put
conformance
tests
as
a
blocker
on
beta.
We
want
at
least
some
conformance
tests
in
place.
We
want
the
validating
web
hook
ready
to
go.
I
guess
we
didn't
actually
say
it
needs
to
be
used,
but
I
think
that
is
maybe
implied
here
and
then.
Finally,
what
we
want
users
to
actually
be
using
this
api
and
deploying
apps
with
it.
A
This
stops
short
of
saying
that
it
needs
to
be
used
in
production,
but
it
needs
to
be
used
by
users
that
aren't
just
the
implementers
of
the
api
yeah
that
that's
the
list
right
now.
Does
anyone
think
of
anything?
Can
anyone
think
of
anything
we
should
add
to
this
list
or
change
in
this
list
that
we
really
want
to
have
in
place
before
we
got
to
beta.
B
A
That's
that's
a
good
question.
I
think
it's
difficult
to
ask
for
that
because
I
I
know
at
least
with
with
gke,
and
I
guess
every
every
product
is
different,
but
it's
hard
for
us
to
ship,
a
project
that
we
call
production
ready
without
a
non-alpha
api
or
it's
it's
challenging.
I
don't
know-
maybe
maybe
it's
I
don't
know
the
ins
and
outs
here.
So
I'd
have
to
dig
back
into
this,
but
it's
hard
to
say
you
know,
usually
when
you
say
alpha
api
you're,
not
saying
oh,
go
use
this
in
production
tomorrow.
A
C
B
A
B
Yeah
I
mean
it
doesn't
have
to
be
by
one
implementation
right,
even
yeah
like
like,
overall,
if
you're
like,
and
if
some
narrow
parts
are
missed
out.
That's
probably
okay
from
an
api
backwards
compatibility
thing,
but
I
do
agree
that
it
is
going
to
be
very
challenging.
The
api
is
broad
enough,
so
yeah.
A
Okay,
cool
well
yeah.
Thank
you.
So
just
a
reminder
it's
linked
in
here,
but
we
have
a
cap
associated
with
gateway
pi
and
so,
if
you're
ever
looking
for
what
we're
hoping
to
get
into
you
know
to
to
reach
beta.
That
is
that.
Is
it
also
one
of
the
things
that
I've
been
thinking
about
a
fair
amount,
as
we
finally
got
to
v1
alpha
2
approval?
A
Many
of
you
who
were
involved
in
this
process
probably
noticed
that
there
was
kind
of
a
lot
of
back
and
forth
of
you
know
it.
It
wasn't
as
official
efficient
of
a
review
process,
as
I
think
many
of
us
would
have
liked.
You
know
we
basically
had
two
separate
groups
of
reviewers.
We
had
our
own
internal
maintainers
and
then
kubernetes
api
reviewers
and
it
was.
It
was
somewhat
challenging
to
manage
the
the
reviews
between
the
two
groups
and
get
everyone
on
the
same
page.
A
A
So
if
anyone
else
has
been
thinking
about
this
same
problem-
or
you
know
ways
to
improve
the
release
process,
I'd
be
very
interested.
I
don't
have
any
any
great
suggestions
right
now,
but
just
throwing
that
out
there
if
anyone
else
has
been
thinking
about
this.
I'd
really
appreciate
thoughts,
comments
whatever.
A
And
with
that,
let
me
keep
on
moving
conformance
tests.
This
is
I
one
of
I
think
our
our
biggest
focuses
has
to
be
with
v1
alpha
2.
That
is
as
I
as
I
just
mentioned,
that
is
a
requirement
to
get
to
beta
that
we
have
at
least
some
conformance
tests
in
place
this
I
took
some
notes
that
came
from
just
a
chat
I
had
with
bowie
a
while
ago
now
just
about
how
we
might
want
to
structure
conformance
tests,
and
this
this
is
really
meant
to
be.
A
A
As
you
know,
a
set
of
ideas,
we
could
maybe
guide
our
discussion
around
conformance
with
so
ideally,
if
we
have
a
conformance
framework,
the
cli
should
again
run
tests
against
any
specified
class
in
an
existing
cluster
and
what
we're
starting
to
get
into
the
trickiness
of
this
kind
of
conformance
testing
is
we're
going
to
want
or
need
a
way
to
select
extended
features
because
we
know
okay,
we
can
start
with
running
conformance
tests
against
everything
we
consider
to
be
core
and
say:
okay.
Well,
everyone
needs
to
support
core.
A
We
can
just
focus
on
core
conformance
tests
and
that's
a
good
starting
point,
but
when
we
start
to
get
into
extended
feature
sets
we're
going
to
need
some
more
thought
and
effort
in
this.
I
know
nick
has
separately
mentioned
that
he's
been
thinking
about
concept
of
conformance
profiles,
and
that's
that's
really
related
to
this,
and
that's
the
idea
that
at
least
my
my
understanding
of
what
a
conformance
profile
would
be
is
really
just
describing
the
features
your
gateway
class
supports
and
that
and
that's
not
like
we.
A
Maybe
we
have
categories,
and
then
we
need
to
outpour
output,
some
kind
of
structured
format,
so
that
we
can
generate
reports
and
show
conformance
across
different
controllers,
different
implementations
and
then
of
course.
Finally,
we
have
to
keep
this
all
in
the
context
of
ingress
controller
conformance,
which
is
our
ingress
conformance
test
suite.
A
That
does
things
a
different
way,
there's
a
pr
that
I
have
that
that
started
kind
of
based
on
that
and
and
shifts
things
things
a
little
bit,
but
we
just
need
to
keep
that
in
mind.
We
either
need
to
have
a
similar
structure
to
what
is
already
being
done
or
pull
ingress
along
with
us
into
whatever
new
direction
we
go.
A
I
don't
want
to
go
through
every
little
detail
here.
Everyone
can
can
read
through
this,
but
this
is
just
a
rough
vision
for
what
conformance
testing
could
look
like.
I
I
know
others
are
thinking
about
this.
I
know.
Obviously
nick
has
been
putting
some
thought
into
conformance
profiles,
but
if,
if
anyone
else
has
opinions
on
how
conformance
tests
should
be
structured,
feedback
is
very
welcome
here.
A
This
is
again
just
to
start.
I
think
this
is
something
that
we'll
probably
have
to
transition
into
a
gap
at
some
point,
but
just
wanted
to
throw
something
out
there.
While
I
had
some
some
rough
notes,
thought
process
any
any
thoughts
or
strong
feelings
about
conformance
testing
structure.
Anything
along
these
lines,
I.
C
Have
questions
yeah,
yeah?
Okay,
if,
if
we,
you
know
I'd,
say,
for
example,
if
we
have
two
different
kind
of
gateway
class,
one
more
like
l7
ish
one
l4
each,
you
know
we'll
have
two
different
kind
of
controller.
How
does
it
work?
Does
that
mean?
If
I
only
do
l7,
does
that
mean
it's
not
conformed
or
is
it's
could
I?
How
does
it
work
if
I
just.
A
A
Yeah
yeah,
so
the
there
there
has
been
some
interaction
between
the
two.
What
we're
testing
is
largely
similar.
What
we're
trying
to
test
between
ingress,
controller,
conformance
and
gateway
conformance
is
that
yaml
or
some
kind
of
kubernetes
manifests
are
applied,
and
I
send
requests
to.
You
know,
give
an
endpoint
and
status
on
said
resource
and
it
works
as
expected.
That's
a
rough!
A
A
There
there's
many
opportunities
to
share
code
logic,
whatever
I'm
not
saying
they
that
everything
needs
to
be
the
same,
but
it
would
be
a
wasted
opportunity
if
we
let
them
live
in
their
own,
completely
unique
bubbles
without
sharing
any
kind
of
the
maintenance.
Overhead
I
don't
know
is
that.
Does
that
make
sense.
D
A
D
A
Yeah,
let
me
let
me
do
that
yeah,
oh
I'll,
update
that
good
point
thanks,
yep
all
right!
Well,
I
think
that's
enough
for
conformance
unless
anyone
else
has
has
comments-
and
I
can
move
on
from
here-
all
right
cool.
So
the
new
feature
is
that
this
is.
This
is
going
to
be
a
recap
of
last
week,
but
the
new
features
that
we've
talked
about
post
v1,
alpha
2,
are
redirect
and
rewrite
l4
route
matching
and
route
delegation
and
inclusion.
A
I
know
that
there
are
issues
for
all
of
them.
This
is
this
path
rewrite
and
redirect
gap
is
the
only
one.
I
know
that
is
actually
a
gap
right
now,
so
it's
the
furthest
along
in
the
process,
but
I
know
we
we
at
least
have
tracking
issues
for
the
other
ones.
So
this
one
because
I've
already
written
a
gap
for
it.
I
am
very
happy
to
just
continue
this
along.
A
This
is
really
just
more
of
a
reminder
that
I
think
this
is
open
for
review
again.
I
think
we
were
close
to
consensus
on
this
one.
Just
it
didn't
make
the
cut
before
v1
alpha
2.,
so
yeah.
This
one
is
close.
If
anyone
wants
to
take
another,
look
at
it,
if
you
have
opinions
about
rewrites
and
redirects,
this
is
a
gap
that
I
think
is
is
going
to
be
one
of
the
first
ones
that
we
can
get
moving
in
this
next
cycle.
A
The
next
two
both
have
tracking
issues,
and
I
don't
think
anyone
is
actively
pushing
forward
on
either
of
these.
We
have
ideas.
We
have
discussions
on
github,
but
there's
there's
a
lot
of
people
here
and
I
wanted
to
open
this
up.
Is:
is
anyone
interested
in
leading
the
efforts
on
on
either
of
these
discussions?
D
E
A
Cool
yeah-
okay,
that's
great
and
I'll
just
add
myself
here,
just
I
I
can.
I
can
chat
after
with
with
anyone
here,
but
I
think
we
just
need
to
find
the
tracking
issues
here
and
there's
there's
probably
artifacts
for
both
of
these
either
in
discussion
in
in
there-
or
maybe
I
think,
there's
probably
docs
associated
with
these.
So
if
you,
if
you
want
any
help
trying
to
pull
any
of
that
information
up,
I
can
I
can
find
it
but
yeah
great
to
have
more
people
involved
on
these.
A
Great
okay,
the
last
thing
we
just
have
one
issue
that
I
noticed
if
I
missed
anything
else,
let
me
know,
but
there's
really
only
one
issue:
that's
coming
we've
kind
of
been
in
a
slow
period
as
we
waited
to
get
v1
alpha
2
out
the
door,
but
the
one
issue
that
came
in
is
created
by
me
in
this
case
and
it's
how
and
when
are
we
going
to
deprecate
a
v1
alpha
1?
We
hadn't
been
particularly
clear
on
this
and
there's
mixed
opinions.
A
Some
saying
that
you
know
alphas,
don't
really
have
any
kind
of
deprecation
guarantee
any
any
kind
of
long-term
support.
Basically,
the
idea
that
you
can
deprecate
them
at
any
point
and
or
remove
them.
I
I'm
not
sure
I
think
harry
you.
You
were
more
comfortable
with
waiting
until
we
released
another
version
of
the
api
before
removing
v1
alpha
one.
Is
that
correct.
B
I
mean
we
can
be
less
methodical.
I
don't
know
if
that's
the
right
word,
but
at
least
like
with
other
versions.
I
think
it's
important
to
keep
like
you
know
abortion
back
around,
because
that
helps
with
migrations.
You
know
mostly
people
are
take
forever
to
migrate,
and
that's
that's
why
I
think,
like
you
know
having
one
just
keeping
it
around
helps,
you
know
probably
don't
add
to
anything,
but
just
just
for
migration
purposes.
It
helps.
A
Yeah,
that's
fine!
I
I
think
it's
it's
fine
to
leave
around
for
for
a
while.
I
I'm
not
sure
the
exact
I
think
one
of
the
most
natural
points
to
remove.
It
may
be
the
next
minor
release
that
next
minor
release
may
be
alpha,
maybe
just
another
bump
on
v1
alpha
2,
maybe
beta,
I'm
not
sure
what
the
next
minor
releases,
but
that
that
may
be
the
most
natural
thing,
but
I
I
think
it
sounds
like
there's.
A
A
D
F
A
Yeah,
that's
a
good
question.
I
would.
I
would
really
really
love
to
avoid
alpha
three,
that's
my
hope
and
goal.
Personally
I
I
I
am
very
interested
in
getting
to
beta
sooner
than
later,
because,
like
as
we
were
mentioning
earlier
in
the
call
for
for
gke,
it's
it's
much
easier
to
launch
a
product.
If
we
have
a
beta
api
as
opposed
to
an
alpha
api
I'd,
imagine
we're
not
the
the
only
ones
with
this
limitation.
You
know
what
we're
doing
right
now
without
api
is
in
alpha.
A
So
we
can't
you
know
as
much
as
I'd
love
to
go
to
beta
tomorrow.
We
do
kind
of
need
to
wait
for
implementations,
to
catch
up
and
to
really
have
users
feedback
on
v1
alpha
2..
I
think
the
only
thing
I
can
think
of
that
would
cause
us
to
go
to
v1
alpha
3
is
if
we
get
significant
feedback
that
something
like
we
did
in
v1
alpha
2
is
sufficiently
wrong,
broken,
confusing,
etc,
and
we
need
to
make
some
kind
of
breaking
change
before
we
go
to
beta.
A
A
and
and
then
I
I
think
at
that
point
we
can
really
get
a
better
feel
for
when
beta
is,
is
possible
in
reality,
like
it's,
it's
hard
to
find
that
you
know
it's
like
a
chicken
and
egg
problem
here
of
you
can't
get
tons
of
users
until
you
launch.
You
know
a
stable
product
that
people
can
use
in
production,
but
then
you
know
it
once
you
do
that.
A
You
can't
make
the
changes
that
you
really
want
to
make
based
on
that
feedback,
so
yeah
this
this
unfortunate
cycle
with
that
said
yeah
I
feel
like-
and
this
is
just
me
talking-
you
know
with
without
much
thought
here,
but
it
seems
reasonable
to
at
least
expect
at
least
a
couple
implementations
of
this
api
v1
alpha
2
specifically
and
some
users,
and
at
least
some
basic
feedback
from
those
users
on
the
api,
and
even
if
that
feedback
is
yeah.
This
is
this
is
fine.
A
D
Yeah,
so
we've
got
these
these
three
items
that
we've
identified,
as
you
know,
for
post
v1
off
to
you
know
to
be
working
on
here.
Are
we
do
we
want
to
get
these
into
beta
or
is
this?
Are
we
happy
to
take
the
one
alpha
two
and
see
if
we
get
any
feedback,
then-
and
you
know,
if
there's
no
feedback
or
nothing
major,
then
push
that
directly
to
beta.
A
Yeah,
that's
a
that's
a
good
question.
I
so
I
think,
there's
there's
two
separate
somewhat
separate
tracks
here.
I
think
we
can
at
least
discuss
design
for
these
without
necessarily
committing
to
getting
them
into
v1
alpha
2.
You
know
without
committing
to
a
a
brand
new
release
for
that,
but
I
think
it's
it's
helpful
to
at
least
discuss
the
design
around
these,
but
I
I
agree
with
well.
I
guess
you
weren't
saying
this
directly,
but
we
don't
necessarily
need
to
get
these
in
to
v1
beta
1
and
it's
potentially
it's
likely
a
faster
path.
A
So
need
to
find
the
right
balance
there,
I'm
not
sure
how
tied
we
are
to
any
one
of
these
features.
I
know
we
have
feature
requests
for
all
of
them,
but
I
guess
it
comes
down
to
a
prioritization
of
how
quickly
do
we
want
to
get
to
data
or
how
much
do
we
want
to
rush
these
features
in,
and
I
I
don't.
I
personally
don't
have
a
clear
answer
on
that
yet,
but
I
I
would
really
be
interested
in
what
others
in
the
community
are
thinking
here
as
well.
E
E
A
A
Yeah,
so
basically,
I
think
what
what
shane
is
describing
here
is
and
what
I
was
thinking.
My
interpretation
of
that
anyways
is
a
month
or
a
timeline
where
we
we
need
feedback
on
the
api
and,
if
you
know,
if
we
haven't
received
any
any,
you
know,
suggestions
for
changes
or
haven't
addressed
any
you
know
kind
of
feedback.
By
february.
Let's
say
we
are
going
to
take
the
api
and
cut
a
beta
based
on
that
state
of
the
api
kind
of
thing.
E
Yeah
I
mean
it's,
it's
all
kind
of
just
trying
to
get
people
motivated
right
now
right
because
for
all
being
real
real.
If
somebody
came
in
and
marched
and
was
like
wait,
there's
this
devastating
thing
and
we
all
agreed
with
it
I
mean
but
yeah.
I
think
I
think
the
idea
is
to
try
to
just
kind
of
put
something
in
mind
so
that
we
can
all
kind
of
have
a
date
in
mind
when
we
need
to
really
be
done.
D
D
A
So
I
think
we
will
get
some
good
feedback
coming
in
in
that
in
that
time
frame.
But
then
you
know
if
it's
mid-november
and
then
you've
got
thanksgiving,
etc,
probably
probably
the
earliest.
We
could
do
anything
substantial
would
be
january.
I
think
so
yeah.
I
agree
that
february.
I
would
I
really
wouldn't
want
to
go
much
past
february.
A
Maybe
we
can
do
a
little
bit
earlier,
but
yeah.
Let
me
let
me
spend
some
time
thinking
through
exactly
exact
timeline
there
and
it
does
sound
like
there's,
there's
lots
of
interest
in
getting
to
beta,
which
is
great
to
hear,
and
since
that
seems
since
that
seems
to
be
a
pretty
broad
priority.
I
think
we
should
prioritize
that,
and
I
can.
I
can
write
something
up,
maybe
about
really
how
we
balance
getting
a
new
release
out
with
the
desire
to
talk
about
and
work
on,
these
potential
editions
of
the
api.
D
If
you
will,
and
so
we
may
not
have
a
huge
amount
of
end
user
feedback,
but
certainly
as
implementers
we've
got,
you
know
a
lot
of
us
that
are
taking
a
look
at
this
and
looking
at
how
to
do
it.
So
I
I
think
that's
a
pretty
positive
aspect
to
this
and
and
I'd
be
really
surprised.
If,
if
you
know
we
get
through
this
and
go,
oh
man
there's
something
we
really
overlooked
or
something's
really
hard
to
do.
G
A
Yeah,
I
I
think,
you're
right,
I
really
hope
you're
right,
I
I've
been
really
really
thrilled
to
have
all
everyone
working
together
on
this,
and
you
know
I
I
hope
our
combined
efforts.
I
mean
that
the
end
result
is
fairly
straightforward
to
to
use
and
we
haven't
missed
anything
too
obvious
in
the
process.
A
A
C
A
A
Okay,
well
yeah,
but
it's
cool
to
see
the
the
increased
the
increased
attention
and
interest
in
gateway
api,
and
I
actually
I
didn't
even
know
that
we
were
going
to
be
mentioned
in
a
keynote
but
happy
to
see
the
project
getting
a
little
bit
more
attention.
As
we
go
yeah
anything
else.
We
should
discuss.