►
From YouTube: Gateway API Meeting (APAC Friendly Time) 20210518
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,
so
this
is
gateway
api
meeting,
the
last
15
minutes
of
koapi
meeting
for
may
18,
and
we've
been
going
through
cross
namespace
forwarding.
A
I
think
we
have
reached
a
rough
conclusion
on
their
consensus
on
5,
with
the
preference
not
to
introduce
any
kind
of
false
boundaries
here
due
to
them
potentially
creating
more
confusion
than
they're
worth,
but
we
do
want
to
follow
up
with
sig
api
machinery
to
make
sure
that
this
is
actually
a
reasonable
concept
and
also
want
to
work
with
the
network
policy
working
group
to
see
if
there's
a
way
that
we
can
provide
more
meaningful
restrictions.
Here.
A
B
Would
just
add
a
little
bit
to
what
danien
said
if
you
don't
introduce
a
first-class
mechanism
to
do
this,
implementations
will
add
second-class
mechanisms
right
they'll
either
introduce
a
new
type
which
represents
the
resource
or
their
use
external
name,
and
then
the
value
of
tools
like
gatekeeper
or
with
admission
controls
will
be
mitigated,
which
is
a
less
desirable
outcome
right.
So
there's
there's
an
extension
to
this
kind
of
confusion.
Point.
A
Just
to
clarify
what
you're
saying
is:
if
we
don't
introduce
a
way
to
forward
to
different
name
spaces,
people
are
going
to
do
it.
Anyways.
Okay,
I
was,
I
was
making
sure
that
was
the
thing
people
are
going
to
do,
anyways
other
than
you
know,
approach
1-4.
If
we
don't
implement
a
way
to
restrict
this
implementation.
B
D
A
Ahead
sure
sure
yeah,
I
think,
if
they,
if
they
just
tell
us
it's
the
worst
idea
in
the
world,
then
maybe
that's
time
to
reconsider.
But
I
I
agree
that
it
seems
pretty
sensible,
given
that
it's
already
possible
network
networking
is
a
little
unique
in
kubernetes
and
that
the
name
space
boundary
is
relatively
fake
and
and
certainly
does
not
matter
for
network
requests
right
outside
network
policy.
B
A
That's
that's
a
good
point.
Let
me
just
add
a
note
somewhere.
A
C
Rob
I
do
have
a
note
if
you
don't
mind,
while
you're
taking
notes
there.
I
think
bowie
brought
up
a
good
point
of.
We
need
to
be
very
explicit
in
the
like
the
documentation
of,
but
hey
you
know
when
you
do
this
namespace
stuff,
like
you
know,
use
it
your
own
security
risk
kind
of
thing
right.
You
know:
here's
a
link
to
network
policy,
here's
a
link
to
gatekeeper
and
use
with
caution.
So
I
think
we
need
to
be
really
explicit
with
that.
C
The
second
point
is
making
a
namespace
is
an
optional
field
for
service
name,
I
think,
is
really
straightforward
right,
because
we
know
service
is
a
is
named
space
scoped,
but
it
does
get
a
little
fuzzy
when
we
start
talking
name
space
for
back
end
ref
right
because
back
you
know,
couldn't
it
be
a
cluster-scoped
resource
or
do
we
go
ahead
and
say
we
just
don't
allow
cluster-scoped
resources
for
back-end.
A
D
I
think
this
is
like
one
of
those
kubernetes
original,
like
design
baked
in
to
make
this
distinction
between
a
cluster
scope
like
kubernetes,
could
have
chose
like
a
system
namespace
or
something
which
actually
it
does
have.
But
it's
going
to
be
hard
for
us
to
resolve
it.
It
it
basically
propagates
it
as
a
wart
to
this
level.
C
So
would
it
be
documented
that
if
we
like,
if
you
just
get
rid
of
namespace
here
in
your
example-
and
we
say
this
is
some
kind
of
object,
if
we
say
here's
the
object
kind
and
the
name
then
do
we
expect
it
to
be
in
the
same
name
space
as
the
http
route,
and
if
it
doesn't
exist,
then
would
the
implementation
then
need
to
see
if
it's
a
cluster
scope
or
no.
D
A
Yeah,
I
can't
think
of
many
cluster
scope
resources.
I
would
want
to
forward
to
obviously
there's
going
to
be
new
crs
that
I'm
unfamiliar
with
yeah.
I
think
I
think
it's
fine
to
say
that
it's
just
unsupported
right
now.
I
can
imagine
it's
a
relatively
trivial
and
backwards
compatible
change
to
allow
it
under
the
right
conditions.
A
C
D
The
service
import
you
might,
although
the
review
for
that
crm,
might
get
pushed
back
like.
Why
is
this
a
cluster
scope
thing
but
yeah,
maybe
yeah?
We,
let's
accumulate
the
use
cases
and
then
we
can
yeah.
It
seems
like
a
easy
thing
to
add,
although
I
wouldn't
make
it
super
easy
to
do,
because
it's
not
a
very
common
case.
I
would
expect.
C
A
Great
I'll
I'll
keep
on
moving.
Then
I've
got
a
few
follow-ups
on
this
and
I'll
try
to
take
the
discussion
here
and
pull
it
back
into
github
issues.
I
think
the
primary
one
that
we've
been
using
to
track
this
is
582
and
we
can
run
from
there.
A
The
other
thing
I
wanted
to
talk
about
is
our
issue.
Triage
there's
been
a
lot
of
movement
on
github
in
the
past
week,
actually
like.
If
you
go
back
through
you
know,
these
are
the
issues
that
have
been
at
least
updated
in
the
past
week,
and
so
thanks
to
everyone
for
keeping
track
of
things
there,
we
don't
have
enough
time
to
go
through
all
of
them.
If
anyone
has
issues
they
want
to
highlight.
This
is
a
great
time.
Otherwise
I
have
a
couple
in
mind
that
we
can
go
through.
E
A
Yeah,
I
think
you
had
a
good
summary
here
where
all
places
where
a
field
name
is
used
as
a
noun,
we
use
a
plural
value,
and
everything
where
that
is
a
verb
is
singular.
A
That
seems
like
an
intentional
difference
here
and
I
I
agree
with
this
consensus
that
the
naming
makes
sense
and
we
should
probably
document
it
in
implementation
guidelines,
but
I
don't
think
we
need
to
rename
this.
E
C
I
mean,
I
think
it
it
makes
sense
if
we,
if
we
have
you,
know
an
approach
right
now,
where
what
is
it
verbs
are
singular
or
nouns
are
plural,
then,
well,
we
can
stick
with
that.
I'm
playing.
A
A
All
right,
let's
see,
were
there
any
other
issues.
We
should
highlight
real
quickly.
A
I
think
if
we
do
it,
this
is
the
release,
because
this
is
the
release,
we're
making
so
many
I
I'm
I'm
anticipating.
This
will
be
the
release
of
breaking
changes.
There
might
be
more,
but
I
hope
not
so
getting
these
breaking
changes
well
documented.
I
think
it's
going
to
be
key.
A
I
am
very
open
to
a
kep
process.
I
think
I
was
the
one
who
suggested
it,
but
I
don't
want
to
impose
extra
process
if,
if
it
is
unnecessary,
but
I
I'd
be
open
to
to
starting
that
up.
D
A
For
this
yeah,
I
think
really
that
at
a
high
level,
what
I
want
is
most
of
our
features
and
decisions
end
up
having
docs
somewhere,
and
I
just
want
them
to
eventually
end
up
getting
checked
into
this
repository
instead
of
just
getting
lost
as
linked
from
an
issue
somewhere
and
then
maybe
the
dock
changes
or
goes
away.
I
don't
know
you
know
it's
much
easier
if
it's
checked
into
the
repo
to
understand
the
decision
and
rationale
behind
something
so.
C
Yeah,
hey
bowie
ping
me
if
you
have
a
pr
that
for
that,
because
I'm
thinking
in
a
couple
weeks,
I
present
the
the
optional
gateway
class
stuff,
and
maybe
I
maybe
I
could
just
follow
that
kept
process
for
that
talk
here
in
a
couple
weeks,.
A
Cool
all
right.
Well,
I
think
we
we
simply
don't
have
enough
time
to
get
through
everything
today.
But
let
me
just
highlight
this
one
last
thing
here:
I
I
I'm
not
sure
this
person's
name,
but
they
I
found
an
error
in
I
think
code
that
I
added
to
http
route.
I
added
the
optional
controller
field
to
status
and
it's
optional,
but
json
serialization
is
not
omit
empty.
A
This
is
a
really
trivial
thing
to
fix,
but
it
raises
the
question
of
what
we
want
to
do
for
any
additional
updates
to
v1
alpha
1
or
if
we
just
want
to
push
forward
with
v1
alpha
2
and
say
this
will
be
fixed
in
d1.
Alpha
2.,
probably
don't
have
enough
time
to
discuss
it
or
come
to
a
conclusion
on
this
on
this
call.
But
if
you
have
time
to
run
through
this
and
take
a
look
at
your
perspective,
I
would
appreciate
it.
C
Yeah
my
my
two
senses.
The
bar
needs
to
be
really
high
to
add
something
and
b1
alpha
one
and
yeah.
I
I
just
don't
see
this
as
being
a
high
enough
bar.
A
I
I
tend
to
agree
with
that.
I
really
we
want
everyone
to
be
writing
controller
field
anyways,
so
the
amid
empty
is
kind
of
the
optional
part
is
just
kind
of
okay.
Well,
you
really
should
write
something
there
anyways,
so
it's
none
of
that
completely
justifies
it.
It's
a
mistake,
but
I
don't
know
that
it's
a
high
enough
bar
either
to
port
it
back
yeah.
We
have
a
real,
easy
workaround
for
this,
so
it's
not
a
blocker
for
anything.
So
yeah,
no
worries
cool
good
to
know
all
right.
Well
with
that.
A
I
think
we're
done
for
today,
steve
thanks
for
volunteering
for
next
week's
topic
route
delegation
and
then
daniel
next
week
and
well
the
week
after
that,
you'll
be
talking
about
optional
gateway
classes,
so
cool
thanks.
Everyone,
great
feedback
today
and
we'll
talk
to
you
next
week,
thanks.