►
From YouTube: Gateway API Meeting (APAC Friendly Time) 20210601
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
this
is
gateway.
Api
meeting
for
june
1st
go
ahead
daniel
you
we've
got
lots
to
cover
today.
B
Yeah,
you
bet
thanks
rob,
so
I
want
to
take
some
time
to
cover
gateway
class
optionality.
I
provided
a
reference
here
for
a
little
more
background,
262.,
but
a
quick
background
on
on
the
the
topic
at
hand
as
as
we
know,
most,
everyone
on
the
call
knows
gateway
class
is
a
cluster-scoped
resource.
B
B
The
common
configuration
is
expressed
through
parameters
ref,
which
is
a
reference
to
a
different
resource
that
describes
those
parameters
or
that
configuration,
and
that's
really
what's
at
the
heart
of
the
this
discussion
and
the
issue
that
that
I'm
drawing
attention
to
and
the
other
area
of
the
gateway
class
is
the
behavior
and
that
that's
really
specified
by
the
controller,
that's
responsible
for
reconciling
the
gateway
class
and
there
must
be
a
gateway
class
right.
We
can't
create
gateways
and
without
having
a
gateway
class.
B
And
so
you
know
the
issue
at
hand.
Is
you
know
for
one
of
the
issues
for
new
users
right
users
that
have
probably
been
using
ingress
for
a
while
and
not
necessarily
ingress
class?
You
know
to
go
from
interacting
with
a
single
resource
like
ingress
to
transition
into
gateway,
api
and
now
potentially
having
to
deal
with
up
to
three
resources
or
more
right,
so
our
gateway
class,
the
potential
crd
that
the
gateway
class,
references
and
the
gateway
and
then
one
or
more
route
resources.
B
B
B
B
B
Persistent
volume
and
persistent
volume
claims
can
reference
a
storage
class,
but
it's
not
required
and
and
so
again,
similar
to
ingress
with
with
our
storage
system
within
kubernetes,
there's
no
requirements
for
creating
a
persistent
volume
or
persistent
buying
class
and
referencing
a
storage
class.
A
B
Yeah,
and
by
no
means
am
I
an
expert
in
tvs
and
pvcs,
I
dug
into
the
documentation
for,
for
both
that
use
a
storage
class,
and
you
know-
and
so
my
understanding
is-
is
that
if
you
don't
specify
a
storage
class
for
a
pv,
the
pvc
that
you
know
that
it's
bound
to
must
also
be
classless.
So
from
a
pvc
standpoint,
if,
if
you
set
an
empty
string,
that
is
that
that
pvc
is
then
considered
to
be
of
no
storage
class.
B
So
so
there's
that
kind
of
requirement
between
the
pv
and
the
pvc
and
my
understanding
is
with
a
pvc.
If,
if
that's
not
defined
or
defined
as
an
empty
string,
then
this
the
behavior
will
be
similar
to
this
approach,
one
that
I'm
going
to
go
through
and
that
is
that
a
mutating
webhook
exists
to
essentially
create
the
storage
class
without
kind
of
any
user
intervention.
B
It
might
be,
you
know
it
might
be
up
to.
You
know
the
implementation,
maybe
it's
some
kind
of
auto
generated
uid,
something
like
that.
Okay,.
A
B
Again,
you
know
I
I
spent
time
looking
into
pvs
and
pvcs
just
to
understand.
You
know
how
the
storage
class
interacts
with
these
two
resources,
but
definitely,
if
there's
questions
that
I
need
to
follow
up
on
and
dig
down
deeper,
I'm
happy
to
do
that.
You
know
one
other
piece
of
prior
art
that
I
want
to
call
out.
Is
the
storage
class
itself
right?
B
You
can't
natively
describe
you
know
that
classification
of
gateway
or
storage,
it
has
to
point
to
some
other
resource.
That
really
is
responsible
for
describing
it.
A
A
If
I'm
remembering
this
conversation
correctly,
this
was
more
in
the
context
of
ingress
class,
but
obviously
gateway
class
had
the
same
conversation
while
the
same
bits
apply
and
the
idea
there
was
that
when
storage
class
was
created,
there
was
no
concept
of
crd,
so
there
was
no
better
way,
so
they
really
just
have
a
map
string,
string
inside
storage
class,
which
is
you
know,
essentially
just
as
useful
as
annotations
and
there's
no
great
way
to
validate,
there's
no
great
way
to
provide
feedback
on
whether
or
not
something
is
valid
or
used
or
etc.
A
C
I
guess,
like
they
regretted
doing,
that
is
what
I
we
heard
talking
to
storage
class.
So
I
guess
that's
one
data
point.
We
might
want
to
figure
out
again
digging
up
like
why.
The
other
thing
is
like
how
this
is
almost
like
working
around
the
kubernetes
type
system
to
get
a
sort
of
like
a
flexible
schema.
That's
also
checked.
A
C
A
ux
issue
almost
with
working
around
kubernetes
type
system.
It
would
be
good
to
like
distinguish
between
that
versus,
like
at
a
conceptual
level.
Let's
say
somehow:
we
improve
kubernetes
to
merge
those
two
together
like
is
there
something?
Apart
from
that,
I
guess
that
you
go
I'm
saying
like
yeah,
there's
the
fact
that
we
had
to
structure
that
way,
because
that's
how
kubernetes
api
machinery
works
versus
like
let's
say
we
ignore
that
there's
some
fundamental,
more
fundamental
issues
around
how
we're
modeling
things.
C
B
Know
I
think
it's
you
know
it's
natural,
for
you
know
the
storage
team
to
to
say
now
here's
some
of
the
challenges
you
know
with
the
approach
they
took
and
they
didn't
have
the
option
to
use
a
crd,
because
you
know
they're
living
with
that
decision.
Right
and-
and
you
know
we
could
easily
do
the
same
in
the
future.
At
some
point
where
we
say
well,
yeah,
you
know
we
get
the
benefits
you
know
of
of
not
having
you
know.
B
The
map
string
string
essentially
annotations
in
the
gateway
class,
like
the
storage
class
does,
but
it
comes
at
a
cost
in
the
sense
now
we're
managing
additional
resources
and
the
inner
relationships
between
those
resources.
And
so
you
know
every
decision
you
know
has
its
pros
and
cons
right.
B
So
that's
kind
of
the
you
know
the
background
a
little
little
prior
art
that
you
know
that
we
can
reference,
and
the
couple
approaches
that
I
documented
here
you
know.
The
first
approach
is
very
similar
to
what
the
storage
team
does
right,
where
we
make
gateway
class
name
optional,
and
if
it's
unset,
it's
considered
to
be
of
the
default
gateway
class,
and
so
I
think
this
would
make
gateway
class
very
similar
to
ingress
class
along
with
storage
class
right
and
here's.
You
know
an
example
gateway.
B
If
we
have
multiple
gateway
controllers
of
different
types,
we
get
into
this
race
condition
where
these
controllers
are
essentially
fighting
to
satisfy
that
gateway
right,
and
I
believe
this
is
done
by
ingress
class
and
storage
class,
and
that
is,
you
know
we
could,
you
know,
use
a
mutating
web
hook
to
eliminate
the
race
condition.
B
Another
option
here
that
doesn't
necessarily
eliminate
the
race
condition,
but
at
least
eliminates
the
the
loop
and
that
is
introducing
some
type
of
gateway,
ownership
status
field,
and
so
a
controller
would
be
responsible
for
for
reconciling
the
gateway
if
the
gateway
class
name
is
unspecified,
it
would
then
look
to
see.
Well,
it
has
a
controller
already
taken
ownership
by
reconciling
this
resource
it
and
that
would
be
again
reflected
in
some
new
status
field,
and
if
that
is
the
status
field
is
unset,
then
the
controller
takes
action.
B
Now
again,
multiple
controllers
could
be
taking
action
on
it
and
then
you
get
into
a
race
condition.
Who
sets
this?
You
know
status
field
first,
but
it
is
a.
You
know,
fairly,
simple
change,
that
that
does
prevent
the
continual
loop
race
condition,
but
this
option
here.
B
The
second
option
is
very
much
similar
to
ingress,
classing
and
gateway
class,
and
you
know
the
point
that
I
want
to
make
here
is
you
know
I
feel
like
this
improves
the
user
experience
for
parameter
list
gateways
rankings
just
create
a
gateway
and
and
because
no
there's
no
parameters
being
specified.
B
It
does
provide
a
you
know,
an
easy
user
experience.
I
think,
from
an
implementer's
standpoint.
There's
still
that
complexity.
That
needs
to
be
managed,
and
I
also
think
that
a
majority
of
the
production
use
cases
parameters
are
going
to
be
required,
because
you
know
the
way
that
gateway
api
was
designed
right.
It's
meant
to
be
extensible,
so
the
core
apis,
you
know
are,
are
not
as
expressive
as
most
implementations
required
right.
B
Have
another
approach
I
think
I
want
to
pause
for
a
second
and
and
open
it
up
for
a
discussion
on
the
first
approach.
A
Yeah,
and
so
I
like
the
idea
of
a
default,
a
defaulting
gateway
class,
and
I
think
we
can
really
copy
what
we
already
did
with
ingress
class
of,
I
think
it's
an
annotation
on
ingress
class
that
denotes
that
ingress
class
resource
is
the
default
for
the
cluster
and
I
think
that's
reasonable,
but
I
don't.
I
don't
think
that
this
solves
the
issue.
A
If
I
understand
the
issue
you're
really
trying
to
solve
here,
is
you
want
it
to
be
simpler
to
well
one
of
them
at
least?
Is
you
want
it
to
be
simpler
to
deploy
an
instance
of
say,
contour
or
any
other
implementation
of
this
api
within
a
namespace
and
not
have
to
have
that
cluster
scope
to
access?
So
you
can
think
of
nginx
ingress
this.
This
was
a
another
common
use
case
here,
where
nginx
ingress
very
commonly
was
able
to
just
deploy
a
single
instance
in
their
namespace.
A
That's
possible
with
ingress
right
now,
but
not
possible
with
gateway
is.
Is
that
one
of
your
use
cases
here.
B
Or
yes,
it
is,
and
to
elaborate
on
that,
I
just
feel
like
you
know,
simplifying
the
the
mental
model
for
for
users
can
go
a
long
way
by
not
requiring
gateway
class
all
right
to
to.
I
think
most
users
like
they
get
what
gateway
is
and
they
get
what
a
route
is
right
and
by
introducing
the
gateway
class
and
then
that
gateway
class
needs
to
refer
to
another
resource.
B
I
need
to
start
to
wrap
my
mind
on
how
all
these
things
work
and
that's
just
from
a
user
standpoint
right
and
that's
not
even
addressing
the
the
implementation
side
of
things,
and
so
you
know
my
and
what
I
express
here
in
approach
to
is
is
making
what
we
call
a
class,
how
we
classify
gateways
more
flexible
right,
that
we
don't
need
to
go
ahead
and
classify
a
gateway
or
gateways
using
a
gateway
class,
but
to
go
ahead
and
and
give
that
optionality
to
say.
B
Okay,
well,
you
know:
does
it
does
an
implementation
want
to
express
classification
through
a
a
config
map,
great
through
a
custom
resource?
Great,
or
do
you
want
to
use
what
we
typically
have
been
doing,
which
is
a
gateway
class
which
we
know
then
refers
to
another
resource
so
and
that's
really
what
what
this
option
too
is
about,
and
and
how
can
we
go
about
doing?
That
is
right
now
I
feel
like
the
the
the
or,
what
do
we
forget,
the
field
class
name
or
gateway
class
name.
B
That's
really
deviates
from
how
we
express
references
throughout
other
areas
of
the
api
right.
Everything
else
is
some
kind
of
ref
and
it's
it's
a
local
object,
ref,
for
example.
Right
you
know
we
did
expand
the
parameter
ref
recently
right,
because
that
parameter
rep
and
a
gateway
class
used
to
only
be
a
cluster-scoped
resource,
and
then
we
said
okay.
Well,
let's
you
know
have
the
ability
to
go
ahead
and
make
that
reference
either
name
space
or
cluster
scope.
So
a
lot
you
know
when
we,
when
I
share
this
gateway
class
reference.
B
I
looked
at
that
parameter,
reference
of
a
gateway
class
and
really
borrowed.
You
know
the
entire
concept
right
and
now
within
a
gateway.
You
know
you
actually
are
referencing
an
object
right
and
that
again,
that
object
can
be
gateway.
Class
could
be
a
config
map
could
be
a
custom
crd,
and
you
know
I
also
share
here
in
the
example
gateway
spec
for
this,
for
this
field
is,
we
could
have
different
support
levels.
So
if
we
want
to
go
ahead
and
say,
okay
gateway
class,
of
course,
is
core.
Do
we
put
config
mapping
core?
B
Maybe
maybe
not?
If
we
want
to,
we
say
it's
extended,
or
you
know,
and
all
other
basically,
you
know
crds
would
be
a
custom
conformance
level
and
again
the
gateway
class.
Reference
looks
just
like
the
parameter
reference
of
a
gateway
class
where
we
specify
a
group
kind
name
and
scope,
and
we
can
default
these,
like
we
do
in
other
areas
of
the
api
to
make
the
user
experience
of
of
a
gateway
class
reference
very
similar
to
what
the
experience
is
today
and
here's
what
it
would
look
like
right.
B
So
a
here's,
our
gateway
class
and
the
gateway,
and
instead
of
calling
out
the
gateway
class
by
name
now,
we're
we've
got
a
gateway
class
reference
and
we
have
the
name
example
gateway
class
and
again,
all
these
other
fields
are
being
defaulted
for
a
gateway
class.
B
You
know
and,
and
some
some
implementers
would
say
nope
you
know
I
want
a
kind
of
a
structured
schema,
I'm
going
to
go
ahead
and
express
my
classification
of
great
gateways
through
my
foo
kind
and
just
like
with
the
config
map,
my
gateway
class
ref.
Now
is
a
group
version
kind
along
with,
depending
if
foo
is
named
space,
which
it
is
in
this
example,
then
I
would
specify
the
scope
as
well.
E
B
So
it
would
be
essentially
similar
configuration
parameters
that
describe
that
classification
of
gateways
as
the
gateway
class
parameters,
ref
would,
and
so
the
config
map
could
be.
B
The
config
config
map
could
express
the
type
of
load
balancer
that
you
want
to
use
or
how
you
want
to
expose
your
network
endpoint
of
your
implementation,
so
I
may
say:
well
I
want
to
use
node
ports
to
express
or
to
expose
my
network
endpoints
of
my
load,
balancer
proxy
or
no,
you
know
what
I
want
to
use
some.
I
want
to
use
a
a
load
balancer,
not
a
node
port
or
I
want
to
use
you
know
if
it
is
a
load
balancer.
E
This
I'm
guessing.
These
are
the
kinds
of
parameters
that
you
don't
want
to
make
kind
of
like
intrinsic
parameters
like
of
the
gateway
class
itself,
because
then
you'd
have
a
gateway
class
for
each
environment.
Different
every
environmental
difference
would
be
a
different
gateway
class,
which
I
think
probably
seems
a
little
bit
like
you'd,
be
having
too
many
gateway
classes
for
all.
Those
permutations
is
that
is
that
accurate.
E
Yeah,
I
was
actually
going
to
ask
that.
Maybe
this
is
a
noob
question,
but
like
for
things
that,
like
do,
the
controllers
have
a
way
of
basically
having
like
intrinsic
parameters
like
if
you
have
two
gateway
classes
and
the
gateway
classes
themselves
comprise
of
all
the
functionality
of
that
class,
and
so
it
doesn't
require
parameters.
So
the
controller
understands
the
implicit,
these
implicit
characteristics
by
the
gateway
class
name
itself.
Is
that
a
possibility.
B
I
mean
it
probably
is,
but
I
would
see
like
based
on
the
gateway
class
like
name
like
I
would
see,
then
the
names
would
start
to
get
out
of
control.
Where
you
would
say
you
know:
okay,
it's
either
internal,
and
you
know
you
just
keep
kind
of
building
these
long
complex
strings,
trying
to
describe
that.
You
know
that
class
of
gateway
right
because
I'm
thinking
like
how
again
kind
of
just
going
with
the
network
endpoints
of
the
load
balancer
proxy.
B
You
know
in
a
bare
metal
environment,
it's
very
different
than
in
a
cloud
environment,
and
that's
why
I
gave
kind
of
a
node
port
versus
load,
balancer
example,
and
so
I
I
guess
you
know
I
just
could
see
that,
like
the
names
becoming
unwieldy
or
you
know
you
know,
we
just
need
a
way
to
express
those
implementation
or
environment
parameters,
and
you
know
this
same
example
that
I'm
going
through
was
was
was
an
area
of
discussion
early
on
and
that's
where
we
said
you
know
like
network
endpoint
type
like
that's
all
implementation
specific.
B
It
goes
in
the
parameters
ref
of
the
gateway
class,
and
I
mean
the
the
more
that
I've
been.
You
know,
implementing
the
gate,
the
apis,
the
more
I
just
I'm
saying
to
myself
like
what
value
is
a
gateway
class
really
providing
like
it
just
seems
like
it's
just
directing
it
to
another
resource.
So
if
it's
that's
what
it's
doing
right,
a
controller
string
to
say,
okay,
who
you
know
what
controller
can
reconcile
this
gateway
class
and
really
the
meat
of
it
is
really
this
reference
to
this
other
resource.
B
E
No,
that
makes
perfect
sense
and
just
to
like
show
an
example
so
like
we
have
four
gateway
classes
and
we
do
do
an
element
of
kind
of
what
you
talked
about,
which
was
like
we
have
a
gateway,
clas
internal,
an
external
one,
a
multi-cluster,
a
single
cluster
one
and
this.
But
that's
we've
kind
of
drawn
a
line
like
that's
as
far
as
we're
gonna
go
as
number
of
gateway,
classes,
more
characteristics
or
parameters
that
come
up
in
the
future
that
are
not
as
large
as
those
categories
we'll
use
parameters
for
that.
C
Sort
of
like
some
somewhat
like
syntactic
type
system
issues
which
is
basically
gateway
class,
could
be
like
inlined,
like
it's
just
a
reference
to
bounce
through
the
fact
that
we
can't
we
have
like
a
template,
parameter
basically
for
gateway
class
versus
like
how
many
gate
like
are
you
going
to
create,
like
100
gateway
classes
and
who's,
going
to
be
messing
with
them,
because
those
are
slightly
different
problems
like
if
you
look
at
mark's
example.
C
If
you
think
your
users
are
going
to
create
like
200
of
these,
in
which
case
they
will
interact
a
lot
with
the
machinery,
in
which
case,
like
all
the
ux
around
the
fact
that
it's
like
a
reference
that
bounces
somewhere
else
then
becomes
a
problem,
but
that's
different
than
just
the
fact
that
this
is
like
kind
of
ugly
right
now
and
you
can't
do
it
in
kubernetes
type
system.
So
that's
why
we
have
to
have
this
reference.
Bounce.
A
Is
that
yeah
make
sense
yeah?
I
think
I
I
I
I'd
echo
on
that
that
I
gateway
class
is
relatively
simple
in
concept
if
we
consider
it
a
primarily
informational
resource.
If
it's
something
that
users
look
at
and
here
are
the
kinds
of
gateways
I
can
deploy
provision
in
my
cluster,
that
seems
like
a
fairly
compelling
use
case
for
that
kind
of
global
discoverability,
where
I
think
we
really
start
to
run
into
problems
that
are
beyond
just
ux.
A
Is
that
use
case
of
deploying
a
namespace
scope,
implementation?
You
know
the
the
access
control
part
of
this,
where
it's
really
difficult
to
say
to
a
user
of
nginx
ingress.
Well
now,
if
you
want
to
deploy
enginex
ingress,
you
actually
need
to
be
able
to
deploy
these
cluster
scoped
resources
or
whatever
implementation.
C
It
is
yeah,
so
that's
like
a
third
consideration.
Almost
I
I
wonder
if
it
would
be
good
to
like
write
the
different
aspects
down
because
they
might
result
in
different
polls
in
terms
of
the
approach.
D
Who
who
sets
this
in
like
who
sets
the
gateway
class,
and
we
wanted
to
make
that
behavior
intentional
and
not
give
users
the
power
to
deploy
gateways
like
sort
of
application
developers
cannot
deploy,
gateways
right
and
like
if
we
do
a
reference
or
make
that
optional,
then
I
think
we
are
like
introducing
a
loophole
in
the
security
model
as
well
right
or
rather
changing
it.
If
it
not
a.
A
Loophole
yeah,
that's
it's!
Every
every
future
is
also
a
potential
vulnerability.
Something
like
that,
but
yeah
that
that's
a
concern.
It's
it's
hard
because
we're
coming
from
this
world
of
ingress
where
something
was
already
possible
and
we're
saying
hey.
You
can't
do
this,
this
concept
anymore,
which
is
a
difficult
cell,
but
anytime
you
open
up
those
bounds.
A
A
If
we're
saying
you
can
deploy
this
cluster
scope
and
you
don't
have
a
gateway
class
you're,
basically
saying
that
you
don't
have
cluster
scoped
access,
so
we
probably
shouldn't
let
you
reference
anything
in
any
other
name
spaces,
but
then
that's
like
this
other
set
of
documentation.
We
need
for
this
other
use
case.
A
I'm
not
saying
I'm
not
sure
how
I
feel
about
this,
because
I
I
have
internally
been
thinking
for
a
while
that
I
would
love
to
find
a
way
to
get
rid
of
gateway
class,
but-
and
I
even
had
that
earlier
pr
that
attempted
to
make
it
optional-
I
I
don't
know
how
to
do
it
safely,
like
what
you're
saying
harry
without
either
over
complicating.
You
know
providing
too
many
paths
too
many
different
variations
of
the
api
or
or
just
incred
introducing
security
concerns.
A
I
don't
know,
and-
and
I'm
glad
thank
you
thank
you
damian
for
starting
this
doc
and
and
this
discussion
yeah.
I
definitely
this
is
my
my
opinion.
I
definitely
like
the
idea
of
the
default
gateway
class.
I
think
that's
a
really
easy
sell
and
something
like
that,
you
know
comes
from
ingress
comes
from,
I
think
storage
class
has
it
sounds.
Like
storage
class
has
a
similar
concept.
I
think
that
that
we
should
do
that
yesterday.
A
You
know,
but
I
the
the
larger
picture
thing
of
if
we
can
make
gateway
class
optional,
like
the
resource
entirely
optional,
is
a
harder
question
and
I'm
not
sure
like
what
what
I'm
seeing
with
approach
2
is
it's
it's
almost
like
you're
referring
to
parameters
it's.
It
seems
like
you're,
you're,
skipping
the
gateway
class
step
and
referring
to
parameters
which
makes
sense,
but
it
I
think
that
could
result
in.
A
You
know
too
many
ways
to
do
things
again,
potentially
and-
and
I've
been
talking
for
a
while,
but
one
one
more
question
here
for
a
config
map
resource.
If
you
could
target
a
config
map
and
as
your
gateway
class
reference
and
multiple
implementation
supported
config
map
as
a
way
to
describe
gateway
class.
A
B
D
A
D
Mind
is
what
do
we
mean
by
a
gateway
class,
and
you
know
that
has
been
intentionally
left.
Vague
is
my
understanding,
because
it
can
mean
a
few
different
things
so
like
daniel
started
and
summarized
it
as
like
parameters
and
then
behavior
and
early
on
you
know.
Almost
a
year
ago
we
had
this
con
notion
of
that
you
could
have
gateway
classes.
That
would
be
same,
but
their
implementations
would
be
different.
D
So
sort
of
you
know
the
object-oriented
world,
where,
like
an
external
gateway
class
with
you,
know
some
common
behavior,
I
think
over
time
we
have
realized
that
that
it's
probably
very
hard
to
get.
There
is
my
view
of
the
world,
and
you
know
now
they
are
going
like
a
class
is
always
going
to
be
specific
to
a
controller
like
tightly
tied
to
a
controller.
A
A
I,
I
can't
imagine
a
world
where
gke
just
deploys
by
default,
this
generic
external
gateway
class,
but
as
an
example,
someone
as
a
user,
could
deploy
a
generic
gateway
class
called
external
in
each
of
their
environments
and
then
provide
their
own
custom
parameters,
controller
name,
etc
per
environment
for
consistency
for
their
users.
So
I
think
it's
still
a
compelling
use
case,
but
I
think
it's
primarily
compelling
for
the
really
large
organizations
that
make
up
a
probably
small,
tiny
percentage
of
users
of
this
api.
A
A
Of
cases,
sorry,
the
I
think
the
minority
of
cases
is
that
someone,
an
organization,
that's
deployed
in
multiple
environments,
actually
going
out
of
their
way
to
create
custom
gateway
classes
that
are
implemented
by
different
controllers
in
different
environments.
A
C
Right
they're,
like
totally
portable
yeah
yeah,
it
would
help
to
write
some-
I
guess
like
cujs
and
especially
given
light
of
some
security
related
things
that
we
were
thinking
of
recently
like
it's.
It's
also
helpful
in
that
to
look
at
like
okay,
if
you
and
if
you
allowed
such
and
such
then,
could
there
be
a
interesting
consequence
apart
from
enabling
it
to
see
you
jay
yeah,.
A
C
Alternatively,
if
it
didn't
have
that
notion
like
you,
would
have
to
actually
install
a
class,
for
instance,
because
it
didn't,
it
doesn't
work
like
that
in
some
ways,
it's
a
it's
a
gateway
class,
because
it's
a
cluster
global
thing
like
whoever's.
Implementing
that
controller
that
manages
it
has
to
take
into
account.
C
D
Yeah,
that's
that's!
That's
completely
fair
right
and,
like
that's,
probably
one
reason
where
why
we
are
discussing
this,
and
I
I
agree
to
that,
like
I
think
I
agree
to
the
simplification
of
it.
What
I
think
would
benefit
us
is
if
we
have
a
more
concrete
understanding
of
the
class
resource
itself,
because
that
way
we
can
sort
of
understand
like
what
is
the
value
it
brings
right
and.
C
Yeah,
I
think,
like
maybe
all
the
implementers
can
kind
of
lay
out
what
they
are
seeing
as
their
use
of
class.
A
I
guess
this
is
closely
related,
but
also,
if
you
envision
users,
configuring
params,
if
params
are
not
really
a
thing
if
params
are
maybe
because
if,
if
there's
no
real
parameters,
gateway
class
is
primarily
just
a
means
of
discoverability,
it's
it's
a
means
of
linking
a
gateway
to
a
controller
and
that's
it,
and
if
that's
all
we
really
care
about,
then
we
you
know,
then
maybe
that's
something
that
we
need
to
just
bump
down
to
gateway
itself.
A
But
if
there's
a
lot
of
configurability
at
gateway
class,
if
we're
seeing
people
really
dig
into
programs,
then
I
think
that's
pretty
compelling
like
one
thing
that
gateway
class
gives
us
is.
It
gives
us
this
way
to
attach
policy
at
a
higher
level
than
we
could
to
just
a
large
set
of
gateways.
For
example,
let's
apply
yeah.
C
C
C
Everything
else
conceivably
should
be
a
gateway
policy
decorator,
because
in
the
limit
like
you'll
have
users
who
complain
like
I
don't
you
know,
I
don't
want
to
have
to
bother
the
admin
to
configure
those
things.
Okay,
it's
like
take
all
those
I'm
not
saying
we
do
it,
but
like
basically
like
okay
push
those
all
out
to
the
gateway
policy.
You're
left
with
basically
things
that
only
the
admin
should
be
configuring,
and
that
is
basically
what
goes
in
gateway.
A
A
I
I
haven't
really
explored
this
in
detail.
It
may
be
a
terrible
idea,
but
just
thinking
that
many
people
coming
to
this
api
are
going
to
be
coming
from
ingress.
So
if
we
have
something
that's
familiar
to
ingress.
A
Opposite
we
did
so
okay,
so
maybe
an
option
again
is
something
that
I
explored
in
pr
was
a
controller
name
field
and
in
addition
to
a
gateway
class
name
field
and
one
or
the
other
you
know
like
I
either
just
want
to
say.
I
want
this
controller
to
manage
this
gateway,
and
I
just
want
to
take
all
that
controller's
default
settings
and
I
don't
have
a
specific
gateway
class.
In
my
in
mind,.
C
A
Right
exactly
and
the-
and
I
think
I
think
they're
they're
somewhat
separate
use
cases,
but
we
can't
get
to
namespace
scope
deployment
without
an
optional
gateway
class.
So
we
like
they're,
separate
ideas
somewhat,
but
we
need
to
tackle
both
of
them.
If
we
need
name
space
guild
deployment
now
it
could
be
valid
to
say
we
don't
we
don't
care
about
this
use
case.
A
We
recognize
ingress
did
this,
but
we
don't
need
it
here
and
if
that's
a
decision
we
want
to
make,
then
you
know
we
need
to
build
consensus
and
whatever,
but
it
it
sounds
like
there's
some
use
cases
here.
Damian
is
that
was
that
a
use
case
that
you
were
driving
for
here
or
was
it
just
more
simplifying
api.
B
I
mean,
I
think
the
the
driver
behind
this,
from
my
perspective,
is,
is
to
simplify
the
experience
and-
and
so
you
know,
with
this
approach
too-
I
guess
what
I'm
still
well.
I
guess
I
understand
with
pro
approach
to
it
sounds
like
the
biggest
concern
is
that
you
know
gateway
class
ref
could
be
different
references
to
different
types,
different
object
types,
and
now
it
becomes
more
difficult
to
understand
the
behavior.
B
It's
my
counter
to
that
was
again.
This
is
what
you
see
right
here
is
consistent
with
the
rest
of
the
api.
So
if
we're
saying
like
okay
there's
concerns
because
the
behavior
may
be
different,
maybe
I'm
not
understanding
it
because
to
me
this
is
consistent
with
the
rest
of
the
api.
So
if
we
have
concerns
with
this,
then
we
need
to
probably
sit
back
and
and
discuss
the
overall
approach
to
the
apis
of
using
the
style
of
group
version
time.
Reference.
A
I
think
what's
unique
here
is
that
we
already
have
a
class
model
in
in
kubernetes
and
when
you
and
the
class
name
model
is,
I
wouldn't
say
widely
used,
but
it
is,
it
is
what
I
think
is
the
most
relevant
prior
art
here
and
so
you're
right.
We
have
object
refs
all
throughout
this
api
and
every
other
kubernetes
api,
but
I
think
it
would
be
somewhat
unexpected
here.
Com
based
on
the
prior
for
the
class
model.
B
B
C
Yeah,
like
I
just
wonder,
is,
would
it
be
sufficient
to
just
add
that
kv
map
into
gateway
class?
So,
first
of
all,
I
think,
approach
one.
I
think
everyone
agrees,
so
we
should
just
do
it.
I'm
not
hearing
too
much
like
in
terms
of
like
a
pro.
I
don't
know
if
these
are
dif.
These
are
sort
of
disjoint
approaches.
It
feels
like
approach,
one
we're
just
gonna
do
so
maybe
we
should
just
am.
I.
A
Yeah,
I
agree
it
was
always
my
intent.
We
just
haven't
gotten
to
it,
but
I
I
think
it
makes
sense
to
copy
yeah.
C
So
we
should
just
write
down
that
yeah.
Probably
we
should
just
move
ahead
with
that.
One
approach
to
like,
as
I
was
saying
before,
like
we
should
distinguish
between
enabling
new
cujs
versus
trying
to
like
make
kubernetes
apis
suck
less.
C
So
I
kind
of
feel
like
the
first
category,
where
it's
just
like
trying
to
make
kubernetes
api
suck
less
is
like
a
bit
less
compelling
than
the
second
one
and
then
the
second
one,
because
once
you
make
a
change
and
all
these
new
cujs
spill
out
of
it
as
like
a
consequence,
we
need
to
be
very
careful
that,
though,
that
is
what
we
really
want.
I
guess
and
just
a
reference
to
that
mysterious
comment
about
security,
but
like
we
should
be
careful,
you
go.
D
D
Okay,
this
makes
sense,
gateway
and
gateway
class
were
like
historically,
we
have
thought
them
off
to
be
having
like
strong
relation
between
them
and
that's
why
we
didn't,
like
you,
know,
consider
an
extension
point
there
and
here
as
well,
like
you
know,
we
we
could
consider
making
like
the
syntax
better,
but,
like
the
extension
s,
I
guess
of
that
is
what
I
think
we
need
to
discuss.
If
we
want
to
change
this
to
a
reference
type.
A
Yeah
when
I,
when
I
look
at
option
two,
I
think
of
this
as
like
almost
like,
it's
a
pram's
reference
and
if
you
think
of
gateway
class,
doing
two
things
one
is
it
ties
it
to
controller
two.
It
links
to
params.
I
think
the
idea
of
a
direct
ref
from
gateway
to
params
is
sensible
and
it
almost
feels
like
overlapping
with
policy.
A
I
I
don't
know,
but
I
think
I
I
agree
with
most
of
the
comments
so
far,
just
that
understanding
the
problems
we're
trying
to
solve.
For
I
I,
when
I
see
this
issue,
I
automatically
go
back
to
the
namespace
scoped
implementation,
because
that
seems
like
a
really
concrete
problem.
But
what
I'm
less
clear
about
is
how
many
people
actually
want
that
and
if
there's
not
enough
demand
for
it.
C
C
Yeah
think
I
guess
you
could
but
like
since
the
ref
could
go
anywhere.
It
gets
quite
convoluted,
potentially
like
if
it
could
be
a
config
map
in
one
sense
and
then
like
this
other
thing,.
A
Yeah,
I
think
that's
a
key
point,
because
it
means
anything
that
we
do
cross
namespace.
We
probably
can't
do
without
some.
You
know
cluster
scope,
gateway
class
that
that
was
deployed
that
enable
that,
but
if
you
can
just
display
this,
deploy
this
namespace
scope
thing
that
can
do
all
the
things
I
I
don't
know.
Maybe
that's
a
naive
limitation.
I
know
there's
our
back
still,
but.
A
A
I
do
have
an
issue,
let
me
link
it
to
this
doc.
C
C
E
One
question
for
danian,
for
I
guess,
because
the
parameters
about
how
the
gateway
is
exposed,
like
node
port
service
load
balancer.
I
guess
those
will
pretty
much
be
required
for
every
use
case
like
there's
no
use
case
in
which
those
like
that
needs
to
be
specified
right.
So
they,
the
every
user,
needs
to
touch
the
parameters
file.
If
they're
deploying
like
a
gateway
class.
B
E
Yeah
and
then
does
that
also
require
the
user
to
create
the
a
unique
gateway
class
because
they
refer
because
they
have
their
own
unique
parameters
file.
Do
they
also
need
to
generate
a
gateway
class.
B
Yeah,
so
in
today's
contour
world
an
instance
of
a
gateway
class
represents
an
instance
of
contour
contour,
being
the
control
plane
right
and
then
a
gateway
represents
the
data
plane
so
right,
your
envoy
fleet,
and
to
be
able
to
support
different
classes.
B
Those
envoy
fleets
need
to
have
different
parameters.
You
know
now
you
just
kind
of
go
back.
If
you
go
to
like
the
contour
docs,
and
you
do,
you
see
like
there's
an
example
of
the
getting
started
guide.
It's
like
okay,
just
apply
this
yaml
manifest
and
it
does
all
the
magic
for
you
and
it's
like
oh
wow.
This
is
really
easy
and
simple,
and
you
know
great
way
to
kind
of
kick
the
tires
on
contour.
B
But
what
we
see
is
like
95
percent
of
the
users
like
they
just
kick
the
tires
on,
and
they
say
oh
gosh.
Well,
we
need
you
know
these
specific
load,
balancer
annotations
that
came
from
the
service
that
need
to
get
passed
down
to
the
service.
That
front
ends
the
the
envoy
fleet
and,
if
you're
going
to
run,
you
know
multiple
envoy
fleets.
They
need
to
be
listening
on
different
container
ports,
and
you
know
it's
all
these
different
permutations
that
we
have
to
deal
with
in
today's
gateway
api
world.
B
B
Yeah-
and
you
know
in
this
document-
I
say
user,
but
really
you
know,
I'm
not
changing
anything
I
mean
a
gateway
class
should
still
be
created
by
the
cluster
admin
and
and
then
the
parameters,
rep,
crd
or
config
map
would
also
be
managed
by
the
cluster
admin.
And
you
know
the
end
users
themselves,
just
you
know,
can
either
create
the
gateways
or
the
routes.
E
Yeah
right,
but
but
I
think
I
mean
you
raise
good
point
because,
like
90
of
the
new
users
who
they
may
be
a
service
owner,
they
may
be
a
cluster
admin
but
they're
just
trying
gateway
for
the
first
time.
Just
like
any
of
us
try
ingress
for
the
first
time
they
have
to
go
through
the
whole
thing
to
do
just
to
get
the
most
basic
example
up,
which
is
quite
a
bit
of
work.
B
Yeah
right
I
mean
you
go
from
a
and
right
now
within
the
contour
community,
we're
saying
okay
well
for
those
users.
Well,
that's
what
the
ingress
resource
is
for,
and
it's
going
to
continue
to
live
around.
It's
like
okay,
well,
we're
just
kicking
the
can
down
the
road
with,
in
my
opinion,
with
that
approach.
B
Right
and-
and
I
mean
how
I
mean
to
me-
the
the
reality
of
going
from
hey
look.
You
know
you
can
you
know,
but
this
example:
snippet
came
right
from
the
the
ingress
kate
stocks
right
to
go
from.
Okay,
wow,
okay,
this
works.
You
know
to
okay,
you
got
to
create
a
parameters
rough,
you
got
to
create
a
gateway
class.
You
got
to
create
a
gateway.
You
got
to
create
your
route,
I
mean.
B
Yeah
I
mean
the
default
the
defaults
like
if
you
again,
if
you
go
to
contours,
getting
started
guide
that
that
can
be
done
without
a
parameters
ref
for
gateway
api
right,
so
we
just
create
the
gateway
class
and
the
gateway
and
the
contour,
along
with
contours
data
plane,
which
we
know
is
envoy,
gets
spun
up.
I'm
using
a
load
balancer
all
that
stuff
right.
B
So
yeah
I
mean
again
that
works
for
the
kicking
the
tires,
but
you
know
we
then
look
at
the
real
world
on
the
contour
slack
channel
and
see
you
know.
Most
people
are
having
to
do
all
sorts
of
different
load,
balancer
annotations
or
use
different
way
to
expose
network
endpoints
for
the
envoy
data
plane,
and
I
mean
just
look
at
all
the
just
the
different
annotations
alone
for
a
particular
cloud
provider.
To
specify
right,
I
mean
aws
right,
a
million
different
things
that
can
be
customized
for
their
load
balancer.
C
B
No,
so
what
we
have
to
do
is
all
those
different
like
aws
elb,
like
what
load
balancer.
Do
you
want
to
use
nlb
classic,
you
know.
Do
you
want
it
to
be
an
internal?
Do
you
want
to
filter?
You
know
source
ip
ranges.
All
that
has
to
be
expressed
in
the
parameters
ref,
which,
again
for
us,
is
either
a
config
map
or
a
crd.
C
B
Right
so
when
we
create
a
service
that
front
ends
the
the
envoy
proxy
fleet
yeah
we're
basically
taking
that
and
then
translating
that
to
the
annotations
or
creating
the
service.
We
eventually
want
to
replace
the
service
that
frontends,
the
envoy
fleet
with
you
know,
with
gateway
api
on
that
end
right,
so
we
no
longer
create
a
service.
We
create
the
gateway
class,
a
gateway-
and
you
know
like
a
tcp
router,
for
example
right,
but
that's
kind
of.
B
C
I
think,
like
one
thing
that
would
be
useful
is
also,
I
think,
we're
over
time.
So
apologies
but,
like
you
know,
kind
of
getting
understanding
of,
and
it
would
be
great
if
you
could
drop
some
links
to
the
discussions
on
the
contour
is
to
understand
like
how
many
classes
people
are
ending
up
with
by
creating
because
of
this,
and
then
who
is
creating.
It
still
sounds
like
it's
the
admin
which
is
better,
I
guess
than
for
example,
rob's
use
case
of
like
everyone
can
kind
of
deploy
it
inside
a
namespace.
C
B
Yeah
yeah
and
I
don't
I
don't
see
tons
of
gateway
classes.
You
know
for
a
typical
multi-cloud
environment.
I
think
you
know
that's
where
we
get
into
maybe
a
dozen
classes
overall
right
where
they
have
like
an
internal
and
external
per
environment.
Right
and
let's
say
you
know,
large
enterprise
customers
like
okay,
I've
got
a
couple
cloud
providers
and
I've
got.
You
know
my
internal
and
environment
as
well,
and
so
you
know
for
each
cloud
provider,
I've
got
the
external
and
internal.
B
C
I
see
but
like
gateway
classes,
one
to
one
with
the
params,
so
at
least
that
is
it's
not
going
to
be
a
multiplicative
growth.
I
think
like
what
it
does
sound
like,
though,
is
that
the
getting
started
experience
is
not
super
smooth.
I
do
wonder
if
the
default
will
fix
some
aspects
of
it
sounds
like
it's
not
entirely
sufficient.
C
We
should
think
about
like
how
we
can
make
it
smooth.
Maybe
with
packages
like
a
helm
chart
it's
like
easier,
isn't,
isn't
that
how
contour
is
I
I
don't.
B
Know
like
well
we're
doing
it
with
an
operator,
and
so
you
know
the
kicking.
The
tire
is
getting
started,
isn't,
in
my
opinion,
so
much
the
the
issue
because
we
created
gateway
class
called
public.
We
create
the
gateway
which
creates
an
instance
of
contour
or
I'm
sorry
of
envoy.
The
gateway
class
creates
the
instance
of
contour.
B
You
know.
So
that's
not
my
opinion.
That's
not
an
issue.
It's
it's
again!
Those
users
that
are
now
saying,
okay,
cool.
We
keep
the
tires.
Well
now,
here's
our
environment
right.
We
need
an
internal
and
an
external.
The
external
needs
to
be
an
nlb.
The
internal
is
a
classic
load.
Bouncer.
The
internal
then
also
needs
a
filter
on
these
source.
Ip
ranges.
We
need
to
go
ahead
and
set
the
proxy
protocol
for
this
provider,
but
not
for
these
providers.
B
You
know,
there's
just
there's
a
lot
of
parameters
when
you're
dealing
with
each
of
the
different
cloud
providers
configuration
that
you
know
when
people
are
kicking
the
tires.
It's
just
like.
Okay,
great,
you
know
this
works
and
then
and
then
in
reality
kicks
in
and
it's
like,
they've
got
all
these
requirements
of
filtering.
You
know
source
ranges
providing
the
client
ip,
and
so
they
have
to
use
a
proxy
protocol
and
all
these
parameters
for
each
and
every
different
environment.
C
I
see,
but
let's
see
so
it
definitely
is
a
need
for
someone
to
edit
the
parameters
and
by
merging
it
into
gateway
class.
That
will
be
easier,
but
they
still
have
to
like
figure
out
all
those
parameters.
It's
not
and
that
doesn't
just
come
off
the
shelf,
although
you
could
say
the
operator
should
default
based
on
the
environment,
but
maybe
that's
not
detectable
from
your
operator.
B
B
We
can't
detect
like
what
lb
type
that
they
want
to
use
when
amazon
supports
three
different
lbs
right.
That's
just
one
example
there,
but
things
like
oh
you
know
is
this:
you
know:
is
this
amazon,
okay,
we'll
set
proxy
protocol,
but
again
there's
some
users
that
that's
even
hard
to
default,
because
there's
some
users
that
don't
care
about
whether
you
know
preserving
their
client
ip
or
not,
and
so
you
get
in
that
setting
where
it's
like
really
need
to
expose
us
because
they're,
you
know
it's.
B
C
I
see
yeah,
it
would
be
great
if
we
could
link
the
those
comments
in
here.
Yeah.
B
I'll
add
to
this
document
it
just
kind
of
talks
a
little
bit
about
you
know,
give
kind
of
just
like
an
implementation
example
using
contour.
A
All
right-
well,
I
think
we're
we're
past
time
here
but
yeah.
Thank
you.
Thank
you
for
the
great
discussion
here
and
yeah
I'll
I'll
follow
up
on
that
doc
as
well.
I
I
do
I'm
really
interested.
I
have
been
interested
in
a
while
in
finding
alternatives
to
gateway,
class
or
optional
ways
to
do
that,
but
understanding
the
problems
would
be
helpful,
so
yeah.
Thank
you
cool
all
right.
I
think.
That's
all
for
today
see
ya
right.