►
Description
SIG Network Gateway API Bi-Meeting (APAC Friendly Time) for 20220124
A
A
A
A
I
don't
know:
there's
been
a
gap
around
this
there's
been
some
discussion,
but
I
don't
know
if
everyone
is
thinking
the
same
thing
I
am
for
this,
so
I
wanted
to
just
open
this
up,
describe
how
I'm
thinking
about
stable
and
experimental
channels
and
really
just
describe
how
I
think
these
are
supposed
to
work.
So,
from
my
perspective,
everything
we've
added
since
0.4.0
is
going
directly
to
experimental
channel
and
the
stable
api
is
going
to
be
identical
to
v1
alpha
2..
A
B
A
B
Yeah
so
hi
everyone
yeah,
I'm
back.
I
live
the
yeah.
I
agree
that
yeah,
it's
good
that
we're
pushing
the
beta
and
that
yeah
it's
going
to
look
exactly
like
v1
alpha
2.
I
think
I
don't
think
that
there's
anything
destructive
that
we
need
to
do
that.
Would
that
would
you
know
that
would
mean
that
we
need
to
do
a
v1
alpha
3..
That
would,
in
my
mind,
would
be
the
only
reason
to
consider
not
going
straight
to
beta.
B
A
C
I
think
we
need
to
give
some
love
to
the
web.
Okay,
the.
What
is
it
the
validation
webhook
a
little
bit?
I
don't
know
how
much
of
that?
Oh,
it's
yeah,
that's
that's
there,
but
if
there
is
any
other
validation
that
we
are
not
doing,
and
that
might
create
a
problem
for
us
in
future,
where
you
know,
like
users,
start
relying
on
something
like
an
unobserved
behavior
that
sort
of
sort
of
protection
like
we
that's
mostly
a
protection
for
both
aminos
and
the
user
yeah.
Something
yeah
is.
D
A
Every
implementation
can
choose
to
deploy
the
web
hook
as
as
they
want
or
not
so
there's
yeah,
there's
two
things
here:
one:
how
are
we
choosing
or
documenting
deploying
the
api
in
web
book?
We
we
have
documentation
that
says
that
api
and
web
hook
are
bundled
together
as
one
thing
and
they
they
combine
to
make
up
a
release.
A
So
you
can
install
the
crds
and
web
book
at
the
same
time.
So
if
you're
representing
a
managed
provider,
you
may
be
the
one
that
is
providing
an
option
that
hey
we'll
install
that
for
you
we'll
we'll
manage
the
api
version
and
web
hook
for
you,
but
that's
that's
just
one
side
of
it.
The
other
side
I
think
you're
describing
is
not
just
using
the
open
source
web
hook,
but
maybe
adding
on
some
additional
capabilities
to
it.
Is
that
what
I'm
hearing.
D
Yeah,
exactly
you
know,
imagine
you
know.
I
have
some,
let's
say,
for
example,
the
back
end
data
plane
supporting
this
is
on
external
low
balancer
right,
so
I
may
have
some
constraint
over
there.
I
need
to
validate
you
know
of
them.
You
know,
for
whatever
reason
you
know
you
have
gateway,
you
have
http
route.
You
have
targets
the
things
I
might
need
to
put
over
there.
It's
very
implementation
specific
you
know,
whatever
ratify,
may
not
be
applied
for
other
implementation.
A
Yeah,
that's
an
interesting
case.
I
can
say
for
gk.
We
haven't
run
into
that
yet,
but
I
could.
I
could
see
that
being
a
possibility.
We
do
plan
on
providing
an
option
for
users
to
have
us
manage
the
installation
of
the
web
book.
We
haven't
explored
at
this
point,
any
kind
of
addition
to
the
web
book,
but
I
can
see
that
being
a
potentially
useful
thing.
A
I
I
I
get
not
knowing
the
specifics,
but
especially
if
it's
some
kind
of
implementation,
specific
detail
where
you're
trying
to
provide
you
know
some
kind
of
immediate
feedback
to
a
user
if
they're
providing
some
kind
of
invalid
implementation,
specific
config,
I
don't
know,
does
that
sound
like
what
what
you
were
just
going?
Yeah.
D
B
B
D
Yeah,
I
think
right
now
I
haven't
thought
about
this.
Clearly,
at
least
in
my
current
poc,
it's
more
of
like
a
replacement.
I
would
like
to
have
the
all
these
modifications,
especially
somebody
tried
to
delete
the
gateway
or
delete
the
you
know,
gateway
class.
I
want
to
get
the
hook
back
to
my
own
controller.
B
D
B
So
and
and
so,
if
you're
not
using
the
upstream
web
hook,
and
we
like
change
the
upstream
web
hook,
then
you
might
end
up
being
in
conflict,
and
so
I
feel
like
a
probably
unwritten
thing
that
we've
said
at
the
moment
is
to
be
gateway.
Api
compliant.
You
must
be
running
the
the
validation
is
like
a
thing
that
we
haven't
written
down
anywhere.
B
I
don't
think
at
the
moment,
but
I
think
that
we
need
to
write
that
down
or
we
need
to
have
a
policy
about
what
do
we
do
about
the
web
hook
and
so,
like
we've
kind
of
assumed
everyone's
just
going
to
run
it,
and
I
think
your
points
are
100
percent
fair
and
it's
completely
fair
to
be
able
to
do
extra
stuff
on
top
of
the
workbook.
Oh.
B
Yeah
yeah
so
yeah,
so
I
think
that
that
that's,
I
think
that
we
don't
have
anything
written
down
to
tell
people
that
right
so
yeah.
I
think
in
the
example
you
talked
about
with
deleting
things
like
it
feels
like
finalizers
would
be
the
right
way
to
do
that,
but
rather
than
like
patching
the
web
hooks,
but
I
feel
like
it.
B
Validation,
that's
there
then.
I
think
that's.
That
is
definitely
a
useful
discussion
to
have
now
in
alpha
before
we
call
beta,
and
so
I
think
we
need
to.
We
need
to
make
sure
that
the
that
we
have
a
consistent
story
for
the
workbook
validation
as
part
of
the
move
to
beat
up
like
we
need
to
have
how
much
validation
do
you
need?
D
Yeah
thanks
for
pointing
this
out
I'll.
Take
this
note
back
a
note
to
myself.
You
know
for
the
implementation.
I
think
one
thing
I
was
not
sure
today
when
I
run
when
I
install
the
crd,
maybe
that's
my
problem.
I
don't
see
the
validation
web
hooks
being
installed.
Do
I
need
to
make
any
modification
to
I
mean
just
use.
The
upstream
webhook
was
not
clear
to
me.
What
does
being
it
seems
like
it's,
not
runny
you're.
A
Right,
you're
right,
the
right-
it's
not
clear
in
our
docs
right
now
at
all,
but
the
crd
installation
is
currently
too
far
separated
too
far
separated
from
this
the
web
hook.
Installation
we
say
you
need
both,
but
in
actual
docks
it's
not
clear
and
I
don't
think
we
have.
We
make
it
obvious
at
all
how
you
would
install
a
web
book.
D
Okay,
okay,
so
yeah.
That
was
a
confusion
part
and
that
then
I
went
ahead
using
because
I
was
using
cube
builder
to
bootstrap
my
controller.
Then
I
went
into
q
builder
instruction
to
say:
hey
here's,
the
way
how
you
create
a
web
hook,
that's
gummy!
So
come
confused.
You
know
and
and
the
second
part
about
the
using
finalizer.
I
I
that's
one
thing
I
find
I
don't
know.
D
Maybe
it's
my
understanding
of
finalizer
is,
if
I
have
a
finalizer
so
say
say:
for
example,
if
you
want
to
delete
a
gateway,
but
gateway
has
an
http
raw
attached
to
it.
I
can
add
in
the
final
logic,
say:
hey:
you
cannot
delete,
but
the
problem
is:
when
the
user
try
to
issue
a
delete,
you
know
when
you
use
a
coupe
ctl.
D
In
in
in
you
know,
you
know
that
when
I
say
ctrl
delete
gateway,
but
my
finalizer
hey,
you
cannot,
you
cannot
give
the
feedback
to
the
user
to
say,
hey,
you
need
to
delete
the
dependency
first
delete.
All
the
you
know.
The
the
backend
ref
to
the
this
http
route
is
basically
start.
How
do
I?
How
do
people
I
mean
this?
Is
my
user
perspective?
That's
why
I
say
if
I
have
a
web
hook,
I
could
capture
this
delete.
D
A
I'm
not
sure
the
best
way
to
handle
that
either
we
we've
relied
on
finalizers
for
a
number
of
our
things
like
cleaning
up
resources.
Cleaning
up.
You
know
cloud
load
balancers,
for
example,
and
it's
not
a
great
experience,
but
we
haven't
found
a
better
one.
Yet
I'm
interested
if
anyone
else
has
but
yeah,
at
least
for
us,
it
just
kind
of
holds
for
a
while
and
and
what
you're
saying
of
not
providing
obvious
or
useful
user
feedback.
D
D
It
also
like
I'm
giving
an
example
today
like
on
aws.
When
you
delete
a
vpc,
you
get
an
airbag
to
say:
hey
you
vpc,
or
have
some
instance.
You
have
dependency
resource.
Like
ez2
security
group,
go
clean,
those
things
up,
then
you
can't
delete
vpc.
That
will
work
so
similar
thing
like
this
for
for
gateway.
I
do
not
want
the
gateway,
if
I
say,
delete
gateway
without
any
warning.
Just
automatically
wipe
out
all
the
http
routes
referred
to
and,
more
rather
to
say,
hey,
don't
delete.
D
You
have
dependency
on
this
gateway,
which
I
think
the
finalize
I
cannot
use.
I
cannot
find
a
way
to
further
finalize
it
to
do
that.
You
know
finalize
a
return
to
say:
hey
just
return,
the
air,
so
you
cannot
do
it
and
the
user
who
was
doing
the
cube,
ctrl
d,
lead
gateway.
It
just
stopped
until
it
time
out.
B
Yeah,
I
agree
it
is
a
terrible
experience.
I've
had
that
happen
before
and
yeah.
You
also
run
into
the
fun
thing
where,
if
the
service
that
provides
your
finalizer
is
not
available,
then
your
thing
will
you're
the
legal
deadlock
forever.
There's
probably
some
questions.
We
could
ask
api
machinery
there
about
the
right
ways
to
do
that
sort
of
thing,
but
I
think
harry
put
a
good
thing
in
in
the
chat
to
to
remind
people
that
you
don't
only
have
to
have
one.
You
can
have
multiple
web
hooks
for
any
specific
object.
B
So
there's
no
reason
why
you
couldn't
use
the
upstream
one
to
do
like
the
basic
validation
that
we
provide
and
then
have
your
own
one,
that
does
that
does
like
this
sort
of
descendant.
You
know
directed
graph
checking
for
you
and
and
then,
as
you
say,
the
the
good
thing
about
the
the
web
book
is
because
it's
on
admission
you
get
that
immediate
feedback
to
the
you
can't.
C
And
rob
I
had
a
question
for
you,
like
you
mentioned
this
in
passing
before,
where
gke
plans
to
install
the
gateway
api.
Once
it's
a
data
for
users,
you
know
when
the
during
cluster
provisioning,
I'm
assuming
you
would
also
install
the
web
book
in
that
or
yeah
okay.
So
in
that
case,
if,
if
I'm
adding
logic
to
web,
that's
fine-
I
mean
that's
fine
as
long
as
whatever
I'm
validating
is
for
my
specific
use
case.
C
B
So
sorry,
you
wanna
get
first,
rob
no
go
for
it.
I
was
gonna,
say
yeah
that
feels
like
why
we
need
to
we
need
to.
We
need
to
have
very
clear
language
that
a
bundle
includes
a
web
hook.
You
must
include
and
run
this
web
hook
and
all
these
any
additional
web
hook
things
you
do
must
be
a
super
set
of
these
of
these
of
the
ones
that
we
provide.
A
C
C
C
B
I
think,
there's
probably
some
space,
maybe
where
you
might
be
able
to
say
hey,
you
can
import
the
code
from
from
the
upstream
web
hook
and
run
it
as
in
your
own
version
of
the
web
hook.
That
then
adds
extra
stuff
on
top
rather
than
running
two
separate
ones.
If
you
really
want,
but
like
we
recommend
just
running
two
separate
ones,
because
that's
kubernetes
is
designed
to
work
like
that.
Yeah
they're
probably
good
to
have
some
sort
of
escape.
A
Yeah,
I
agree,
I
think,
as
long
as
it
includes
all
the
same
and
that's
again
the
purpose
of
performance
tests
as
long
as
it
covers
the
same
functionality,
and
it
really
is
a
superset
we're
all
right,
ideally
you're,
just
running
the
oss
image
directly,
but
you
know
I
I
wouldn't
be
too
prescriptive.
I
think
our
current
oss
deployment,
config
just
has
a
you
know
how
it
generates.
A
Okay,
that's
that's
a
lot
of
really
good
feedback
and
action
items
to
go
forward
with
I'll,
try
and
create
some
tracking
issues
for
this,
and
I
don't
remember
if
we
already
have
a
milestone
but
I'll,
try
and
start
getting
that
together
for
this
and
and
if
anyone
has
time
and
cycles
to
try
and
help
out
with
making
this
better.
I
very
much
appreciate
any
contributions,
any
anything
else
on
web
hook
before
we
move
on.
F
A
B
A
Okay,
so
the
next
thing
on
here
is
just
api
changes.
I
I
think
we
may
have
all
the
gaps
in
that
are
in
scope
for
v1
beta1.
If
anyone
has
something
else
they're
thinking
about,
actually
there
is
one
in
triage,
so
maybe
there's
one
more,
I'm
not
sure,
but
I
I'm
not
aware
of
any
others
that
are
on
the
horizon.
If
anyone
has
something
that
they're
really
trying
to
get
in
to
v1
beta
1,
please
let
us
know
asap,
because
I
think
v1
beta
1
is
awfully
close
right
now.
A
I
should
also
highlight
that
everything
we're
doing
based
on
the
next
two
bullet
points
is
really
anything
is
going
into
experimental
first
and
then
eventually,
maybe
graduating
the
stable.
So
it's
not
like
it's
a
big
milestone
to
get
it
into
the
very
first
release
of
v1
beta
1.
that
there's
still
room
to
add
things
later.
This
is
just
again
the
first
release
of
v1
beta
1.
C
C
A
Very
understandable
and
it's
a
weird
part
of
the
api
because
we're
not
actually
releasing
any
policy
resource.
It's
just.
This
is
a
type
that
you
should
extend
to
create
your
own
resources
to
and
a
pattern
and
it
so
you're
right.
I
wonder
if
there's
some
guarding,
we
can
do
for
it
guarding
this,
maybe
not
the
right
word,
but
communicate
that
this.
This
concept
is
not
yet
been
done
it
I
I
don't
know
because,
because
you're
right,
I
don't
think
that's
an
area
that
we
have
any
real
usage
of.
A
B
We
don't
actually
say
anything
about
what
the
the
I'm
pretty
sure
we
said,
something
like
it
needs
to
have
this
field
and
this
field
in
this
field,
but
aside
from
that
you're
on
your
own,
so
I
feel
like
this.
This
is
one
where
yeah
some
guards
and
a
work
example,
maybe
like
a
trivial
example
that
you
could
do
anyway
with
the
api
that
you're,
like
that's
like
here's,
how
you
would
do
this
with
polis
with
the
policy
engine
or
something
like
that
might
might
be
the
way
to
go
like
something.
B
A
trivial
example
that
any
proxy
could
implement
would
seem
to
be
something
good.
I
mean
you
know
the
obvious
one
that
we
talked
about.
A
lot
was
timeouts,
but
it
turns
out
that
you
can't
use
the
same
timeouts
across
everybody,
because
everybody
does
it
different
right
so
yeah.
If
we
can
find
something
that
everybody
does.
That's
you
know
that's
you
know
that
might
be
worth
like.
B
Maybe
something
like
limiting
like
something
about
hdb,
rather
than
attached
to
a
gateway
or
just
some,
some
other
like
something
where
you
you
take
some
like
relatively
obvious
thing,
and
you
do
a
policy
for
it,
so
that
then
there's
a
work
example
of
that
somewhere.
That
might
that
should
help
people
understand
what
we're
trying
to
achieve
with
the
with
the
api
yeah
yeah.
B
That's
a
mike
just
put
in
the
chat
enforcing
a
tls
min
version
was
one
policy
that
they
were
looking
implementing,
that
that
one
is
almost
certainly
going
to
become
going
to
be
possible
across
every
across
every
proxy
implementation
and
that
having
a
worked
example
of
like
here's,
how
you
implement
that,
maybe
even
considering
including
that,
as
like
part
of
a
upstream
api
to
be
like
the
example.
The
canonical
reference
example
might
be
good,
but
and
making
it
like
implementation,
specific
support
or
something
like
that.
B
But
yeah
having
an
example.
I
think,
would
really
help
people
here,
because
I
get
it
because
I
spent
like
two
or
three
days
like
at
the
time,
like
reading
figuring
out
how
it
works,
but
like
I
can
totally
get
that
if
you
haven't
spent
two
or
three
days,
reading
the
the
gaps
and
understand
parsing
it
and
understanding
why
you
would
use
this
at
all,
then
it
might
be
a
bit
imperative.
C
C
B
A
Naming
things
is
awful,
I
I
get
the
overlap
and
I
I
think
it's
unfortunate,
but
I
don't
know
I
can't
think
of
a
good
alternative
right
now
for
names.
I
I
think,
carrie
what
you
may
have
been
asking
for
is
like
do.
We
have
any
meaningful
usage
and
feedback
for
reference
policy
like
as
one
of
your
initial
questions,
and
I
I
need
to
spend
some
time
going
back
through,
but
I
think
I
actually
do
have
more
meaningful
feedback
on
this.
A
But
that's
that's
just
you
know
the
one
you
know,
probably
not
enough,
I'm
interested
in
if
others
have
implemented
this
yet
again.
If
this
is
a
new
concept,
I
think
we've
gotten
good
feedback,
it's
being
implemented
or
concepts
like
this
are
being
implemented
by
others.
I've
gotten
some
interest
in
the
community
about
using
reference
policy
for
other
use
cases.
A
B
Yeah
referencing
go
ahead
this
at
this
at
this
point.
At
this
point,
like
I
think,
all
of
the
feedback
we're
gonna
get
is
from
implementers
or
early
adopters.
I
need
to
check,
but
I
I'm
pretty
confident
that
that
ck
implemented
a
reference
policy
for
contour
and
if
so,
I
can't
remember
if
he's
done
it
or
not,
but
it
should
be
trivial
to
do
to
use
reference
policy
to
do
the
same
thing
as
our
old
tls
certificate
delegation
does
for
http
proxy.
B
I
mean
the
reference
policy
is
basically
a
more
flexible
version
of
the
tls
certificate
delegation
thing
that
we
have
in
history
proxy
phrase.
So
in
terms
of
the
general
constructs,
I'm
pretty
confident
that
we're
that
we're
in
the
right
that
we're
headed
in
the
right
direction
with
the
reference
policy,
it's
gonna,
be
little.
Details
like
you
know
like
stuff
like.
Oh
the
the
front
name,
space
was
optional
and
stuff
like
that
really
fixed.
That's
gonna
trip
us
up,
not
the,
I
think,
not
the
broadcast
concepts,
but
I
think
that
the
name
is
yeah.
B
Even
retro
strategy
is
probably
it's
probably
slightly
better
than
reference
policy,
because
there's
no
overlap
with
another
thing.
That's
totally
different
that
we
talk
about
yeah
it.
I
think
that's
that's!
The
problem
is
that
we're
we've
got
two
things
that
are
going
to
be
called
x
policy
reference
policy
is
one
of
them
and
it's
completely
different
and
implemented
using
a
completely
different
mechanism
than
you
know.
Your
custom
timeout
policy
that
would
that
have
a
very
similar
name.
C
Yeah,
I
think
we
should
just
collect
this
rob
a
little,
because
probably
the
api
user
will
ask
us
that
you
have
had
some
like
at
least
multiple
people
looking
at
it.
Like
other
resources,
I
think
we
have
had
enough
people.
You
know
implementing
that
if
you're
reasonably
confident
this
one
there
have
been
definitely
talks
about
it,
some
references
to
it,
but
but
not
enough.
A
B
A
And,
and
also
I'd
say
along
with
that,
although
it
was
not
the
initial
intent
of
this
conversation
finding
a
way
to
communicate
the
stability
of
our
policy
attachment
model
because
it
has
not
been
used
yet
as
well,
it's
not
a
it's,
not
a
crd.
It's
not
exposed
in
the
same
way,
but
maybe
we
need
to
be
a
little
bit
cautious
in
how
we
document
that
model.
I'm
not
sure.
A
A
A
One
of
the
things
that
is
going
to
change
with
v
1
beta
1
is
that
we're
going
to
have
really
no
difference
between
v
1,
beta
1
and
v
1
alpha
2,
and
I
expect
that
will
continue
indefinitely.
So
our
way
of
representing
that
is
going
to
get
a
little
messy
we're
not.
I
can't
imagine
having
separate
docs
for
v1
beta
1
and
b1
alpha
2.,
maybe
at
some
point
we
have
separate
docs
for
different
bundle
versions.
A
I'm
not
sure
what
I
think
shane
was
the
the
pioneer
of
this.
This
is
our
first
documentation
that
is
regarded
as
this
is
an
experimental
feature,
but
actually
I
realized
after
we
got
this
in
that
we
should
really
start
with
experimental
feature
to
be
released
in
0.5.0,
because
our
docs
in
in
some
cases,
are
getting
ahead
of,
what's
actually
released.
A
That's
another
thing
that
hard
to
find
the
right
balance
so
anyway.
This
is
this
is
how
we're
currently
representing
experimental
features,
there's
room
for
improvement
improvement.
So
I
think
this
is
a
good
start.
I'm
glad
that
we
have
a
starting
point
for
experimental
features.
Thank
you
shane
for
adding
this.
It's
like
yeah.
A
I
I
completely
missed
it
with
rewrites,
and
so
we
need
some
work
on
that
and
some
work
on
just
explaining
what
experimental
and
stable
mean
in
this
context,
and
then
the
other
thing,
I'm
thinking
about
very
very
much
is
v
one
alpha.
One
dots,
I
think,
with
our
transition
to
v
one
beta
one,
we
may
be
nearing
a
point
where
we
can
either
remove
or
mostly
hide
v
one
alpha
one
documentation.
A
B
If,
if
we
changed
the
website
to
be
a
bit
more
like
the
upstream
cube
website,
where
you
know,
the
docs
are
sliced
at
the
very
top
of
levels
by
the
by
the
version.
If
we
do
that
via
the
bundle
version-
and
we
have
like
a
basically
a
separate
version
of
the
docs
for
each
bundle
version-
that's
like
updating
the
docs
as
part
of
the
bundle
version,
all
that
sort
of
stuff.
That
means
that
you
pick
your
final
version
and
then
you
get
the
docs
that
are
appropriate
for
that
right.
B
So
the
0.4.1
docs
will
still
have
everyone
else
for
one,
because
it's
kind
of
still
around
and
so
it's
still
available,
but
it's,
but
it's
not
available
on
the
most
current
version
right
and
that
that's
that's
going
to
be
good,
because
it's
similar
to
what's
upstream
in
kubernetes
and
and
it
gives
us
the
way
to
handle
this
sort
of
stuff
going
forwards,
and
then
it
means
that
we,
if
you
pick
the
0.6.0
thing,
then
we
can
remove
the
experimental
tags
in
that
one
and
say
in
0.5.1.
This
is
experimental
in
point
6.0.
B
This
is
not
experimental
right
like
to
do
that.
Probably
we're
going
to
have
to
do
the
similar
sort
of
thing
to
what
the
upstream
does
and
have
like
use.
One
of
the
tools,
the
hugo
tools
that
lets
you
have
like
versions
of
the
thing,
and
it
makes
like
a
branch-
and
you
know,
there's
a
whole
bunch
of
shenanigans
to
make
that
actually
happen.
But
I
feel
like
that
would
be
the
the
desirable
end
goal,
because
then
that
would
solve
a
few
of
these
problems
and
make
the
website
a
bit
easier
to
navigate.
B
A
I
agree,
I
think
that's
that's
been
in.
You
know
something
that
we
knew
we
had
to
get
to
eventually,
and
this
may
be
the
forcing
function
you
know
getting
to
a
third
api
version.
That's
going
to
be
a
much
better
user
experience.
I
think
it
means
a
last.
I
checked
it
was
difficult
or
impossible
to
do
with
make
docs
on
a
current
structure.
A
A
A
Yeah,
I
agree
cool
okay,
well
I'll.
If
anyone
has
good
contacts
and
sig
docs
it'd
be
great
to
have
a
discussion
with
them
around
how
we
can
structure
this,
it
does
seem
like
hugo
is
pretty
widely
used,
but
yeah.
Anyone
who
can
help
would
be
very
appreciated
with
that.
I
want
to
just
open
this
up.
Is
there
anything
else
that
I
haven't
listed
here
that
we
should
be
thinking
about
when
it
comes
to
v?
One
beta
one.
D
D
D
D
I
have
a
http
http
route
inventory
route.
I
have
two
version,
one
on
one
cluster,
one
on
the
other
cluster.
You
know
two
classrooms
may
have
two
different
versions
right.
I
have
running
kubernetes
1.21,
second
one,
maybe
around
1.22
but
and
a
two
cluster
both
have
a
client.
You
know
I
may
have
a
client
one
in
cluster,
one
need
to
act,
references
this
inventory,
http
route
or
two
back
end.
I
also
can
have
another
version
of
a
client.
D
E
So
that
that's
an
interesting
point
one
one
ask
I
have
is:
can
you
write
it
down
like
in
a
diagram?
Because
I
don't
know
if
everyone
caught
all
the
relationships
there
there's
two
things
which
is
one
right
now
in
terms
of
you
know
the
kubernetes
community.
There
is
one
cross
cluster
notion,
which
is
the
multi-cluster
service.
So
that's
why,
for
the
most
part,
the
only
kinds
of
references
that
we
talk
about
are
just
to
multi-cluster
service.
E
So
my
general
thinking
is
like
we
should
ask
that
question
but
kind
of
more
broadly,
and
if
it's
the
case
that
sig
multi-cluster
kind
of
says
like
well,
we
don't
care
like
you,
you
guys
can
kind
of
figure
out
a
semantic
yourself.
Then
then
we
kind
of
then
we
can
talk
about
solving
it,
just
in
gateway.
I
just
I
hesitate
to
like
do
something
specific
for
gateway.
E
Although
we
did
have
questions
like
hey
what,
if
we
can
do,
cross-cluster
references
which
gets
back
to
the
original
point
like
what
about
cross-cluster
resource
references
in
general,
like
what
kind
of
is
there
a
general
pattern,
we
should
be
following
yeah
and
the
thing
about
multi-cluster
service
is
that
it
has
a
notion
of,
like
you,
have
a
bunch
of
cooperating
clusters
in
the
same
administrative
domain
and
one
service
in
one
cluster.
If
it's
exported
is
the
same
as
this,
the
other
service
that's
being
exported,
it's
because
there's
very
little
configuration
on
service.
B
A
B
Chain
in
my
I
have
been
away
for
a
month
and
I'm
reviewing
my
github
notifications
and
I
I
got
about
seven
or
eight
comments
to
even
went.
Save
I'm
gonna
come
come
back
to
this
one
later
because
it
looks
it
looks
interesting,
but
it
looks
like
it
needs
quite
a
bit
of
parting.
I
do
appreciate
the
document,
the
images
that
you
put
in
yeah.
I
might
I
might
hit
you
up
to
talk
about
that
one,
a
little
bit
more.
I
feel
like
it
does.
B
G
A
Yeah
I
wish
I
wish
there
was
a
a
good
way
to
represent
this
for
all
implementations
and,
and
there
was
a
consistent
way
but
yeah
that
issue.
I
I
dug
into
it
too,
and
I
I
was
underwhelmed
by
or
overwhelmed
maybe
by
the
the
different
configs
available
across
different
implementations.
I
looked
at
and
there's
you
know,
there's
some
things
that
look
similar
on
the
surface,
but
the
details
are
different
and
then
there's
others
that
they
support
all
things
but
x.
A
G
Yeah
policy,
we
you
and
I
talked
about
this,
but
the
policy
seems
like
I
have
to
get
back
to
it,
but
that
might
be
the
way
we
have
to
do
it
just
since
we're
it's
so
complex
and
we're
running
low
on
time
and
because
of
the
variance
and
how
everybody
implements
this,
but
I
do
think
it's
gonna,
it's
gonna
be
something
later
down
the
road
we're
gonna
be
like
man.
I
really
wish
we
could
have
had
a
way
to
do
that.
C
C
You
want
to
do
any
kind
of
balance
load
balancing
between
them.
That's
all
that
has
to
be
a
policy
resource.
We
discussed
this
at
length
and
that's
where
we
have
policy
resources,
so
we
do
allow,
for
you
know
like
okay,
you
want
to
do
weighted
load,
balancing
or
least
connection
or
whatever
you
can
do-
that
all
vendor
or
implementation
specific
load
balancing,
and
that
is
considered,
not
a
workaround,
but
solution
that
we
have
designed
for.
C
The
second
thing
is
okay,
you
have
multiple
services
and
you
can
only
do
weighted
load
balancing
between
those
which
is
not
really
load
balancing,
but
we
designed
it
for
canary
right,
like
can
airing
traffic.
That
was
the
only
use
case
that
we
had
in
mind
now.
Load
balancing
across
these
two
different
services
is
an
advanced
kind
of
use
case
that
if
we
try
to
show
it
in
the
api
doing
it
in
a
implementation,
agnostic
fashion
is
not
going
to
work
based
on
whatever
we
have
read
so
far
in
so
many
different
implementations
right.
C
B
I
think
the
thing
I
was
going
to
add
there
was
that
I
think
it's
important
to
remember
that
for
for
the
generalized
policy
mechanism,
we
kind
of
want
to
again
it's
not
in
the
docs,
but
in
my
mind,
a
lot
of
what
we're
talking
about
here
is
actually
going
to
be
most
of
the
policy
stuff.
A
lot
of
the
time
is
about
the
data
plane,
not
about
the
control
plane.
If
you
have
a
separation
between
them,
so
it's
about
what
proxy
you're
using
or
what
what
method
you're
using
to
do
this.
B
Then
then,
you
have
like
a
envoy
load
balancing
strategy
rather
than
a
you
know:
contour
low,
balancing
strategy
right
because
the
load
balancing
strategy
is
going
to
attach
in
a
similar
way
and
have
the
same
options
based
on
the
the
data
plane,
not
on
the
not
on
the
the
actual
controller.
That's
implementing
it
for
a
lot
of
people.
G
B
I
mean,
I
think,
that
it's
probably
still
worth
like
it
feels
like
policy
is
the
right
thing
to
make
because
of
the
the
likely
difference
in
the
strategies
and
stuff
like
that
like
it
would
be.
If
you
didn't
do
policy,
you
had
something
like
where
you
picked
a
low
bouncer
strategy
in
the
in
the
upstream
api.
B
What
would
happen
is
that
you
would
have
specific
values.
It
would
be
like
a
string,
probably
that
had
specific
values
that
were
core
and
specific
values
that
were
implementation,
specific,
which
we've
done
in
like
which
might
be
a
which
might
be
a
viable
option
right,
but
but
then
it
doesn't
also
allow
you
to
do
the
other
more
complicated
stuff
that
you
were
talking
about
with
low
balancing
between
routes
or
load,
balancing
between
targets,
as
opposed
to
just
load
balancing
across
back
ends.
B
B
We
missed
this,
and
so,
let's
be
100
sure
that
if
we're
going
to
say
that
we'll
be
like
well,
we
thought
about
it
the
best
we
could
at
the
time-
and
you
know
and
yeah,
we
made
a
mistake,
but,
like
you,
we
all
we
all
can
smell
the
idea
that
maybe
maybe
there's
a
mistake
to
be
made
here.
Let's
put
a
bit
of
effort
in
and
make
sure,
and
do
our
best
to
be
that
we
don't
miss
something
obvious
so.
G
A
I
I
did
really
like
the
idea
that
nick
kind
of
mentioned,
just
briefly
there-
maybe
there's
still
room
for
sharing,
but
it's
you
know
on
a
per
underlying
implementation
level
like
maybe
you
can
share
per
nginx.
You
know
we
have
a
generic
thing
that
here
are
all
nginx
capabilities,
or
maybe
that's
maybe
that's
a
bad
idea.
I
don't
know
but
or
maybe
I
misunderstood
what
you
were
saying,
but
I
I
am.
I
am
somewhat
interested
in
this
idea
that
maybe
there's
subsets
of
implementations
that
can
still
share
config.
B
A
Sorry,
the
big
thing
that
we
that
bit
us
with
ingress
is
that
when
you
add
something
you
can't
can't
change
the
behavior
of
existing
config,
so
your
app!
Basically,
you
have
to
default
to
either
completely
empty
and
whatever
you
add,
is
forever
optional
and
the
empty
config
is
just
unknown
implementation,
specific
whatever,
which
is
probably
fine
here,.
E
But
it
does
I'm
just
thinking
like
this
is
if
this
is
like
an
advanced,
it's
a
difference
between
ingress,
which
is
everyone's
expecting
some
sort
of
behavior
and
their
expectation
was
wrong
versus,
like
an
advanced
knob
that
people
who
really
want
it
will
add
it
and
then
expect
a
particular
behavior.
So
I
don't
know
like
I
have
to
look
at
the
proposal
in
detail,
but
I'm
I'm
trying
to
gauge
like
do.
We
need
to
solve
it
now
or
me.
Is
there?
Is
there
more
time
to
like
get
to
a
conclusion.
A
Okay,
okay,
you
go
wrong
all
right,
so
yeah.
I
know
I
know
we're
at
time,
so
I
do
want
to
move
along,
but
I
think
there's
room
to
at
least
track
that
this
discussion
happened
and
where
we
landed.
Maybe
that's
in
the
gap
issue
or
anyway,
but
yeah
that
there
was
good
discussion
here
today
and
I
think
we
should
just
track
that
and
note
it
down
somewhere.
A
The
last
thing
I
well:
okay:
we
are
going
to
run
out
of
time,
we've
already
briefly
covered
timeline.
We
have
an
idea
of
blocker,
so
I
want
to
move
very
quickly
on
to
pr
issue
triage
to
at
least
mention
these.
I
have
a
pr
out.
That's
just
adding
the
conformance
test.
There
was
an
initial
conformance
test
vr
that
merged
and
I
split
out
some
additional
performance
tests
into
a
follow-up.
A
That's
just
sitting
there.
If
anyone
has
some
time
to
take
a
look,
I
could
use
a
set
of
review
and
then
the
other
one
that
has
had
significant
conversation
is
the
idea
of
section
name
on
routes.
I
I
think
work
so
far.
A
lot
of
the
pushback
has
been
that
there's
been
significant
pushback.
Just
on
the
idea
of
adding
this
right
now,
but
I'm
interested
in
what
others
think
so
that's
pr9
996.
This
is
our
gap.