►
From YouTube: SIG Gateway API GAMMA Bi-Weekly Meeting for 20220823
Description
SIG Gateway API GAMMA Bi-Weekly Meeting for 20220823
A
A
A
B
To
clarify
I,
don't
think
any,
or
at
least
this
year
is
not
intercepting
by
based
on
hostname.
Everyone
is
interested
as
far
as
I
know
interested
based
on
the
owner's
IP
address,
because
you
know
the
application
is
making
a
DNS
requests
by
itself
and
then
it
is
also
an
IP
and
that's
what
we
intercept.
I
don't
know
if
other
vendors
have
a
different
solution,
but
I'll
be
curious
to
know.
B
A
I
apologize
I
was
having
a
little
bit
of
audio
issues
on
my
end,
I
think
the
I
think
the
big
takeaway
between
what
I
heard
and
what
you
said
in
the
chat
is
that
DNS
is
typically
implicit
and
translating
that
host
into
IP
address
and
that
people
aren't
typically
intercepting
on
hostname,
which
I
I,
misstated
I.
Don't
think
people
are
intercepting
based
on
hostname,
but
hostname
is
used
to
like
match
traffic
as
far
as
client
server.
Things
like
that,
so
yeah
sounds
like
we're
good
to
keep
that
implicit.
C
Else
so
it
sounds
to
me
like
I
mean
the
way
I've
been
thinking
about.
It
is
that
the
one
of
the
biggest
things
that
you
want
out
of
a
service
mesh
is
the
ability
to
Define
to
Define
relationships
between
services
or
routing
between
services
in
terms
of
services,
identity
like
I'm,
using
the
word
identity
in
a
slightly
fuzzy
way,
but,
like
you
know
like
in
terms
of
like
what
you
call
the
service,
you
want
to
be
able
to
use
some
name
for
the
service
and
say
you
know,
allow
traffic
from
service,
8
or
7B.
C
D
C
C
Things
where
you've
got
to
say
you
know
allow
this,
you
know
allow
like
a
cider
or
something
like
that,
but
like
in
general,
I
think
one
of
the
biggest
things
you
want
is
to
be
able
to
not
have
to
worry
about
the
IP
address
details
and
be
able
to
let
the
infrastructure
sort
that
out.
But,
like
that's
one
of
the
biggest
reasons
you
want
to
have
a
service
mission
right.
C
C
Identity
are
probably
going
to
be
related,
they
don't
have
to
be,
but
if
you
are
doing
it,
they're
going
to
be
closely
related
right
like
because
you
don't
have
to
do
workload
identity,
we
can't
say
it
must
be.
This
is
that
way,
but
but
it,
but
it's
possible
that
they
could
be
costing
you
I
mean
yeah.
B
C
Yeah,
like
I,
said:
I,
don't
I
well,
I,
guess
what
I'm
trying
to
say
here
is
I
feel
like
talking
about
it
as
a
service.
Identity
just
means
that
we
have
space
later
to
talk
about
that
yeah
I,
don't
think
we
need
to
solve
it
right
now,
but
I
think
we
just
need
to
make
sure
one
of
the
one
of
the
things
I've
learned
from
doing
the
main
API.
Is
it's
good
to
make
sure
that
you
leave
space
for
problems?
C
C
You
know
like
let's
you
know,
let's
call
this
the
services
identity
that
includes
you
know,
certainly
some
sort
of
name
for
it,
which
will
be
a
DNS
name
and
then,
and
then
it's
up
to
the
implementation.
What
you
do
with
the
naming
I
mean
facilium
right,
like
psyllium,
has
its
own
set
of
like
odd
ID,
like
like
uids
for
for
things
that
your
new
IDs
for
pods.
C
B
Agreement,
that
is,
we
are
not
Reinventing,
DNS
ipam,
address
allocations
or
other
things.
In
most
cases,
I
mean
we
may
double
their
if
necessary,
for
external
or
for
some
stuff,
but
we
still
rely
on
on
ipam
and
Cube
DNS
effectively
for
for
a
gamma
okay.
As
long
as
you
have
agreement
on
this
I
think
it
simplifies
the
problem
of
it.
A
C
Yeah
I
think
I
think
that
we
are.
We
are
certainly
going
to
be
service
based
I.
Think
yeah,
like
like
I,
said
that,
like
I've
said
before,
I
think
that
there's
that
they're,
just
the
split
between
the
front
end
and
the
back
like
the
conflating
of
the
front
end
and
back-end
concerns
in
the
current
service
object,
means
that
we
might
have
to
do
something
clever
there.
But
like
are
we
going
to
end
up
basing
it
around
that
service
object?
Absolutely
I
mean
it's
the
it's
the
object
right
like
it's.
C
The
thing
called
service
right,
but
I
think
that
we
need
to
be
really
clear
that
it
may
be
that
we
have
to
bind
things
to
like
to
some
intermediate
thing
or
something
like
that
to
make
the
to
make
that
split,
clear,
because
I
think
that
is
the
that
split
between
front
end
and
back
end
is
most
likely
to
be
the
thing
that
burns
Us.
In
my
mind,.
C
B
A
So
what
I'm
hearing
is
but
I,
think
I'm,
hearing
and
parsley
from
this
conversation
is,
it
doesn't
sound
like
we
need
to
create
any
Gap,
yet
just
making
sure
that
we're
careful
about
keeping
DNS
implicit,
not
Reinventing,
DNS
and
ipam,
and
keep
everything
service
Centric.
Even
if
we
have
logical
or
intermediate
intermediate
representations
of
that
front-end
back-end
duality
of
the
service.
C
I
I
would
write
it
down
as
keeping
everything
service
lowercase
s,
Centric,
not
uppercases,
so
it
just
just
to
be
clear
that,
like
you
know,
I
I
think
that
we
again
this
is
terminology
that
we
need
to
be
really
careful
about,
because
I
think
that
the
the
uppercase
service
means
the
literal
resource
kubernetes
service,
and
if
we
used
a
lowercase
service,
then
we're
talking
about
the
general
concept
of
a
service
I.
Think.
C
A
My
my
headset's
been
causing
me
grief
for
the
past
two
weeks
and
I'm
about
ready
to
check
into
the
ocean,
so
yeah,
so
I
agree
with
what
I
heard
from
Nick.
As
far
as
with
lowercase
service
I
think
I
was
trying
to
strike
a
balance
between
what
costan
said
like
we're
not
looking
to
recreate
the
service
resource.
A
A
Okay,
so
next
thing
for
us
to
to
talk
about
is:
is
the
mesh
representation,
Gap
and
I've
gone
through
and
added
some
more
detail
here
already
had
it
up
I
copied
over
the
approaches
from
the
exploration
dock,
because
now
that
we've
got
I
forget
the
number,
but
the
the
main
kind
of
service
mesh
goes
get
the
merge.
That
gives
us
the
what
and
the
why
and
I
think
we
are
need
to
move
full
steam
ahead
into
the.
A
How
so
and
I'd
like
to
spend
I'm
conscious
of
other
people
who
might
have
agenda
items.
So
if
you
have
a
Virginia
item,
please
let
me
know,
but
I
love
to
spend
some
time
secretly
talking
through
some
of
these
some
of
these
approaches
and
try
to
get
some
clarification
on
on
where
this
get
needs
to
go.
A
What
are
our
winners
as
far
as
or
what
are
the
Front
Runners
as
far
as
approaches
here
and
do
we
have
any
approaches
that
are
kind
of
non-startered
for
anybody's
implementation,
I'm,
not
making
any
final
decisions
here,
but
just
trying
to
get
a
signal
from
the
community
of
what
makes
sense.
Does
that
sound
good
everybody
solid?
A
So
I
don't
read
this
entire
thing,
but
basically
I
always
struggle
to
write
to
me
and
these
tldrs,
because
they
kind
of
seem
obvious
but
like
if
we're
going
to
is
to
do
mesh
with
Gateway
API
we'd
need
a
way
to
represent
mesh
and
your
API
so
goals
here.
I
want
to
provide
a
consistent
way
to
represent
a
mesh,
get
your
API
and
there's
a
comment.
A
good
comment
asking
about
the
scoping
of
this
to
one
mesh
I.
A
Think
scoping
this
to
a
single
mesh
makes
sense
at
this
juncture,
because
the
multi-mesh
you
can
be
a
natural
extension
of
a
single
mesh
use
case
representation
should
allow
implementations
to
refer
to
Ingress
gateways,
for
example,
Contour
or
H2
Ingress
Gateway,
as
mesh
resources
for
the
purposes
of
mtls
or
route
generation.
There's
a
lot
of
confusion
about
this.
It's
gone
through
a
couple
iterations.
It
wasn't,
as
it
wasn't
very
clear.
So
might
not
be
clear.
So,
let's
talk
about
it.
A
Basically,
what
I
meant
for
this
goal
is
that
you
know
a
lot
of
meshes.
Take
istio,
for
example,
have
a
kind
of
bundled
Ingress
Gateway,
that's
a
maybe
a
wrapper
around
Envoy
or
are
on
the
proxy,
or
what
have
you
and
those
are
kind
of
like
first
class
mesh
resources,
they're
they're
programmed
by
the
control,
plane
and
and
things
of
that
nature.
A
We
need
to
keep
that
in
mind
and
not
assume
that
the
I
guess
lower
case
Gateway,
the
Ingress
Gateway
data
plane
not
not
assume
that
that's
going
to
be
a
separate
instance
from
the
mesh.
The
mesh
should
be
able
to
burn
to
understand
the
Ingress
Gateway
and
that's
kind
of
what
I
put
here.
Mini
mesh
implementations
integrate
with
various
kinds
of
gateways,
whatever
scheme
we
use
for
Metro
presentation
should
not
prevent
messages
from
continuing
to
operate
in
this
way.
A
B
Yeah,
so
it's
all
the
problem
is
it's
not
only
that
Easter
has
both
a
Gateway
and
a
mission
implementation,
and
we
want
the
ux
to
be.
You
know
good
for
people
to
use
both,
but
it
also
raises
the
interrupt,
which
is
you
know,
keep
discussing,
and
it's
not
the
scope
for
the
first
phase,
but
eventually
have
to
happen.
Is
that
you
know
if
you
have
a
gateway
and
the
mesh,
the
Gateway
should
be
able
to
communicate
with
the
mesh.
B
A
B
C
So
I
think
I
think
there's
two
there's
two
things:
firstly,
that
they
need
to
not
break
each
other
like
on
the
implementation
level,
but
also
they
need
to
be
consistent
on
the
API
level.
Right,
like
the
the
Gateway
API,
the
game
API,
as
used
for
Ingress
needs
to
like
not
be
fundamentally
contradictory,
with
the
Gateway
API,
as
used
for
mesh
right,
like
I,
mean
I.
Think
I
feel
like
that
should
go
without
saying,
but
one
of
the
things
I've
learned
from
writing
a
spec
for
like
three
years.
C
C
A
I
really
think
that
that's
gets
at
the
heart
of
what
I
was
trying
to
represent
here,
but
I
went
through
a
very
convoluted
way
of
trying
to
say
it.
So
I
might
just
delete
this
since
it
seems
to
create
more
questions
than
answers
and
it'll
be
in
history.
If
we
ever
need
to
go
back
and
get
it
any
other
comments
on
that
typical.
A
So
again,
the
idea
here
is
that,
even
though
the
implementation
of
the
implementation
of
mesh
representation
should
allow
for
gateways
and
measures
to
coexist
and
not
break
at
the
implementation
and
API
levels,
we
also
shouldn't
assume
in
the
SEC
or
implementation
that
well
Prospect.
We
shouldn't
even
the
spec
that
a
Gateway
exists
or
is
included
within
any
kind
of
mesh,
and
that
includes
sidecars.
We
also
shouldn't
assume
that
slide
car
is
the
topology
that
the
proxies
are
going
to
be
delivered
through.
A
A
C
I
think
I
actually
saw
another
one,
it's
not
in
the
standard
cap
one
but
but
a
another
thing
that
yeah
just
marked
a
download.
Let's
just
mark
them
down
as
deferred
goals
and
say
you
know,
we
will
consider
this,
but
just
not
now
solid
yeah
multi-cluster
and
what
we
do
about
multi-meshes
in
one
cluster
are
a
problem
for
later,
like
I,
I,
agree,
I,
I,
agree
costing
you've
raised
this
a
couple
times
and
I
100
agree
that
it
is
a
problem.
C
We
need
to
ensure
that
we
don't
stop
happening
or
we
deal
with
at
some
point
but
I
feel
like
we
should
deal
with
the
easy
case
first,
which
is
there's
only
one
implementation
installed
in
the
cluster,
and
then
we
deal
with
the
hard
case
later.
What
happens
if,
if
you
try
and
install
but
let's
try
and
install
too
some
some
of
that
may
fall
out
from
designing
the
the
like
status
flows
and
stuff
like
that
for
for
whatever
resources
we
end
up,
building.
E
That's
kind
of
what
my
hope
is
that
we
just
intentionally
make
it
so
that
we're
not
having
like.
Oh
this
is
globally
configured
or
something
like
that.
So
the
same
way
that
Gateway
API
references,
controller
name
for
things
like
I
think
we
could
follow
similar
patterns
so
that
we
leave
design
space
for
the
future.
There.
C
D
B
You
have
completely
different
I
mean
it's
somehow
common
to
have
you
know
a
cluster
and
run
workloads
for
completely
different
organizations,
customers
whatever,
and
each
of
them
is
completely
separated,
different
route
of
trust.
They
cannot
talk
with
each
other,
they
are,
you
know,
have
tight
control
like
the
namespace
hierarchy
and
kubernetes
in
some
way.
A
A
Kind
of
fall
within
the
scope
of
deployment
model
and
the
kind
of
the
Upstream
defer
to
goal
an
upstream
get
I
see
Upstream
I'm
overloading
Upstream,
but
in
the
previous
step
that
we
just
merged
in
sounds
like
multi-tenant
Falls
more
on
that
deployment
models,
story
and
kind
of
inherently
it's
implicitly
a
deferred
goal,
so
it
might
not
I
mean
I!
Guess
let
me
can
include
it
because
we
include
once
a
cluster
multimaster
management
here.
C
A
C
E
B
C
A
C
C
B
A
Okay,
if
there
are
no
other
comments
on
that,
I
really
like
to
start
talking
about
the
approaches
section.
This
has
been.
This
is
kind
of
where
the
the
gamma
you
know
initiative
started
with
a
bunch
of
folks
on
the
mesh
side
want
to
say
how
could
this
work
and
the
this
was
I?
Think
these
four
different
approaches
are
kind
of
what
we,
how,
as
far
as
we
got
when
it
comes
to
brainstorming,
how
this
might
be
represented
in
Gateway
API.
A
The
other
another
approach
would
be
to
use,
create
a
new
mesh
and
a
mesh
class
resource
where
this
would
be
kind
of
a
one-to-one.
A
more
accurate
one-to-one
representation
of
how
Gateway
and
Gateway
class
are
used
where
mesh
class
represents
a
type
of
a
type
of
mesh.
So
you
know
maybe
one
mesh
class
would
be
istio
and
other
mesh
classes,
osm
or
psyllium,
and
then
users
would
instant
a
mesh,
the
plasticity
namespace.
A
Possibly
you
know
cluster
right
or
whatever,
and
then
things
are
bind
to
the
to
the
mesh
resource
and
then
another
option
similar.
You
do
the
same
thing
as
the
this
mesh
mesh
class,
but
just
reuse
Gateway.
So
there's
more
details
here
and
we
can
chat
about
those
but
I
wanted
to
and
Nick,
maybe
maybe
about
to
say
what
I,
what
I'm?
A
C
I
guess
I
just
wanted
to
I
just
wanted
to
say
my
experience
with
the
go
API
the
thing
that
is
kind
of
a
general
thing.
The
thing
that
the
my
experience
with
the
go
API
has
taught
me
is
that
that
object,
that
kubernetes
resources
that
have
too
many
behaviors
or
have
or
don't
have
extremely
distinct
uses
like
cause
problems.
You
know
like,
if
you
think
about
service
the
resource
it
does
a
lot
of
stuff
and
the
more
stuff
that
it
does
that
are
not
like
that
are
not
entirely
distinct
or
that
overlap
the
harder.
C
C
I
think
the
use
case
of
the
mesh
is
close
enough
to
the
case
that,
to
the
Gateway
case,
like
the
the
concepts
are
similar
and
close
enough,
but
at
the
same
time,
different
enough,
if
we
don't
use
different
themes
is
going
to
be
very
confusing
and
very
hard
to
understand
and
too
magic
is
the
sort
of
and
I
guess.
That's
that
if
I
were
to
someone
I've
just
set
up
in
two
words,
I
would
say:
beware
Magic,.
A
E
Sure
so,
like
I,
think,
one
of
my
initial
questions
is
wondering
like
what
the
role
of
mesh
class
is.
I.
Think
that
like
mesh
is
like
a
concrete
implementation,
makes
a
lot
of
sense
and
from
the
Gateway
API
I
by
understanding
is
that
for
some
implementations,
Gateway
class
maps
to
like
a
physical
load,
balancer
or
different
types
of
load
balance,
or
something
like
that
for
software
defined
implementations
of
the
Gateway
API.
It's
not
a
particularly
meaningful
abstraction,
at
least
for
us.
It
feel
like
it
hasn't
been
so
yeah.
E
B
Thank
you
completely
agree
with
the
mesh
class,
but
you
know
we
agreed
to
differ
the
multiple
meshes.
So
that's
where
project
will
come
in
I
completely
agree
that
that
it's
useful
to
be
very
explicit
and
to
have
you
know
kind
of
explicits
here
these
for
things
that
are
different,
so
mesh
class
mesh,
for
example,
if
you
use
mesh
to
select
the
namespaces
workloads,
that's
that's
a
very
reasonable
thing,
but
I
just
want
to
make
sure
we
don't
create
too
many
resources
and
too
much
user
overhead.
B
D
D
B
A
Yeah,
so
there
are
I
forgot
to
to
add
this,
but
in
the
original
documents
there
are
a
lot
of
good
examples
on
what
this
would
look
like.
So
no
mesh
mesh
class
direct
attachment-
and
these
are
kind
of
like
walking
through
the
flow
of
what
it
looks
like.
So
you
do
a
Helm
install
cool
mesh,
which
would
be
a
specific
mesh
implementation
that
would
install
a
mesh
class
resource
describing
the
mesh
automatically
within
the
helm
chart.
A
And
then
you
create
a
mesh
resource
to
enable
the
mesh
in
the
namespace
and
then
at
that
point
the
HTTP
HTTP
service
enabled
and
some
you
know
this
may
enable
some
implementation,
specific
behavior
like
encryption
or
Telemetry
or
whatever,
there's
no
like
Gateway
API.
Given
that
your
your
did,
we
deploy
the
service
and
this
gets
into
like
service
attachment.
A
A
One
question
that
I
have
as
far
as
mesh
class
that
my
gut
is
telling
me
to
punt
on
is
perhaps
mesh
class
represents
different
versions
of
different
implementations
and
when
and
when
you
go
from
version
A
to
B,
you
create
a
new
mesh
class.
I
am
I'm
even
just
saying
that
I'm,
like
that's
a
lot
of
a
lot
of
stuff,
to
try
to
figure
out
for
this
initial
Sprint.
A
C
It's
hard
to
understand
in
my
mind
why
it
would
be
namespaced
I,
like
the
it
feels
like
the
what
you're,
using
the
mesh
resource
there
for
is
really
like
enable
this
namespace
for
the
mesh
and
the
mesh
is
actually
being
described
by
the
mesh
class
in
the
example
that
you've
got
there.
So
this
is
the
question.
Well,
I
would
ask,
is
why
not,
then
you
know
just
make
the
mesh
cluster
scodes
that
lets
you
do
the
that
lets.
C
You
sort
of
have
some
rules
around
like
what
you
having
multiple
meshes
and
stuff
like
that
have
to
be
distinct
and
they
need
a
different
config,
a
few
things,
and
if
you
want
to
upgrade
to
a
new
version,
maybe
you
handle
it
within
a
separate
cluster
scope,
mesh
resource,
and
then
you
have
some
other
resource
that
handles
the
like,
or
some
a
selector
or
some
other
way
that
you
like
that.
You
then
enable
the
enable
the
mesh
on
a
per
workload
basis
or
enable
it
on
all
of
them.
C
I
put
it
in
the
chat.
Sorry,
it
cost.
When
I
see
you
on
me,
I
promise
I'm
gonna
hand
over
your
SEC,
the
the
the
way
that
I
think
of
the
Gateway
class.
Is
it's
the
it's
the
sort
of
description
of
the
implementation
plus
it's
concrete.
So
it
can
be
useful
for
a
single
employee
like
it's
possible,
for
a
single
implementation
to
handle
multiple
Gateway
classes.
C
C
I
think
yeah
I
think
you're
right
yeah,
so
maybe
labels
does
have
a
lot
of
especially
namespace
levels.
Have
a
very
big
security
blast
radius.
You
know
giving
people
giving
someone
namespace
label
access
effectively
gives
them
cluster
admin,
because
you
can
privilege
escalate
into
cluster
admin
from
no
space
access.
C
To
the
table,
okay,
so
I
would
Draw
my
thing
about
label
like
label
based
labeling,
my
name
spaces,
but
the
but
I
think
the
question
that
the
other
question
I
asked
still
stands
like
like
in
my
mind
like,
even
if
you
have
multiple
meshes
in
a
cluster.
What
you're?
Really
what
you're
talking
about
using
like
a
namespace
mesh
resource,
is
really
enable
the
mesh
enable
the
already
existing
mesh
in
this
namespace,
and
so,
but
so
I
think
that
you
should
call.
We
should
call
that
something
else
like
that.
B
C
Like
you
know
like,
and
that
that
that
that
didn't
really
makes
the
the
mesh
so
but
but
I,
think
mesh
class
is
actually
a
misnomer
right,
like
you're
you're,
it's
You've,
Really
Got,
a
mesh
right
like
you've,
got
a
service
mesh
right
like
it's,
not
you're,
not
having
multiple
service
meshes
within
the
mesh
class,
which
is
what
the
name
class
implies.
Right,
like
that.
B
And
generation
you
have
so
even
if
you
may
have
different
I
mean
you
have
Easter
pregnancy.
If
you
have,
is
your
streak
mode?
You
have
different
version
of
History,
so
it's
even
if
you
have
a
single
implementation,
you
have
variations
that
at
Global
level
have
different
settings
and
you
may
want
to
control
the
namespace.
Has
this
particular
setting?
Is
this
other
one.
C
So
I
guess
what
I'm
saying
is
I
feel
like
we
need
to
be
careful
about
using
the
the
suffix
class,
because
the
suffix
class
implies
that
it
is
a
bucket
for
holding
a
more
important
resource.
That
is
another
resource
right
like
so,
if
we're
going
to
call
it
mesh
class
like
that
implies
that
the
important
resource
is
actually
the
mesh.
That's
the
pattern
that
is
used
elsewhere
is
that
storage
class
is
a
is
a
descriptor
of
like
how
you
instantiate,
like
storage
units
right.
C
You
know,
Gateway
classes
as
a
descriptor
of
how
you
instantiate
gateways
and
an
English
class
is
a
descriptive
how
you
instantiate,
ingresses
and
so
like
what
I'm
trying
to
say
is
like
that.
The
mesh
is
inherently
like
a
multi-name
space.
Almost
cluster
level
theme
right
like
because
the
whole
point
of
it
is
to
describe
communication
across
like
a
large
chunk
of
the
of
the
cluster
or
the
whole
cluster
right,
like
you
know,
if
you're
going
to
have
you
know
again,
this
does
come
into
the
if
you're
going
to
have
multiple
meshes.
C
But
if
you're
going
to
have
multiple
meshes,
the
things
that
run
the
meshes
have
to
have
a
effectively
cluster
close
to
Cluster
admin.
Permissions
right.
They
have
to
have
extremely
wide
range
permissions
and
and
like
they
need
to
be
able
to
create
lots
of
stuff,
not
just
like
a
data
path.
I
think
that
what
I'm
trying
to
say
is
yeah,
so
you're
cool,
okay.
C
C
This
is
a
this
is
an
argument
about
semantics,
I
think
but
like
that,
I
think
that
in
this
case
the
semantics
yeah
like
a
a,
are
really
important
because
the
mesh,
because
the
class
suffix
has
a
very
strong
imputation
that
that
I
don't
think
that
what
we're
talking
about
kind
of
like
follows,
and
that's
that's
what
I'm
trying
to
say
like
we
don't
want
to
bring
people's
bring,
what
people
the
way
that
people
expect
things
to
work
into
a
thing
where
it
doesn't
work
in
exactly
the
way
you
expect
again.
Magic.
B
I
mean
but
I
mean
the
conclusion,
but
not
in
the
premise
I
mean
in
terms
of
behavior
I
mean
in
Gateway
class,
but
I
don't
know
if
the
name
is
right.
Talking
about
class
either,
but
in
Gateway
Class
A
Class
represents
you
know
both
an
implementation
and
a
particular
set
of
behavior.
You
have
internal
internet
egress
cluster.
B
Global
and
so
forth,
so
it's
how
it's
different
from
from
from
from
what
how
Gateway
is
used,
I
mean
have
a
mesh
class
which
or
storage
class
whatever,
which
defines
a
particular
trans
and
instantiated.
That's
what
we
are
doing
in
a
namespace
for
the
workload
is
that
namespace,
we
instantiate
with
provision
whatever
is
necessary,
also
to
selection,
because
again
a
mesh
in
the
Gateway,
both
of
them
select
some
workloads
that
will
happen
to
have
the
properties
of
divided
by
the
class.
C
Right,
like
in
the
in
the
case
of
Gateway
class,
like
we
kept
the
Gateway,
we
used
the
Gateway
class
name
because
I
I
think
you're,
probably
right,
you
sort
of
said,
like
hey,
the
Gateway
class
name
is
kind
of
not
you
know,
I
think
we
kept
that
for
the
for
the
correspondence
with
Ingress.
You
know
because
Ingress
English
class
Gateway
class,
like
that
was
the
that
was
that
was
easy
for
people
to
understand,
but
I.
C
B
Just
a
quick
answer:
I
mean
I,
don't
particularly
care
about
how
the
mesh
class
is
called,
I,
think
bike.
Shading
names
is
probably,
but
because
a
lot
of
people
not
interact
with
it
too
much,
but
whose
names
and
send
people
photo
names
and
sort
them
order,
or
whatever
is
typically
done
to
resolve
bike
shooting.
Because
again,
you
will
never
find
consensus
on
how
to
name
things
or
how
to
what
colors
to
use
and
other
stuff
like
that.
But
important
is
to
agree
is
that
we
have.
B
You
know
something
that
is
cluster
level,
that
defines
implementation
and
variant
of
the
implementation,
something
that
defines
your
orbit.
And
if
we
have
an
argument
on
that,
then
it's
just
a
matter
of
you
know,
picking
random
names
and-
and
you
know,
trying
to
roll
a
dice
or
selecting
my
vote
or
whatever
other
criteria.
A
Just
about
to
make
that
joke
so
I
think
that
more
so
than
takashi's,
Point
more
so
than
the
naming
I
think.
The
important
thing
here
is
to
make
sure
that
we
represent
what
we
want
to
represent
in
the
cluster
that
the
concepts
behind
this
are
solid.
Naming
can
come
later,
but
I
think
we
need
to
come
to
consensus
around.
What
do
we
need
to
represent
as
far
as
resources
in
the
spec
when
it
comes
to
different
meth
behaviors,
like
you
mentioned,
SEO,
strict
mode
and,
and
things
like
that
honestly
to
me.
A
A
Also
Leary,
is
that
a
word
I'm
also
wary
I'll
use
that
word
of
creating
a
resource
that
will
just
lead
to
a
lot
of
annotation
proliferation
and
I
feel
like
thinking
about
this
more
I
I
do
feel
like
having
a
mesh
having
two
resources
and
having
one
that's
supposed
to
be
some
sort
of
description
of
of
different
behavior.
For
a
mesh
starts
getting,
it
starts.
A
Those
are
again
within
a
kubernetes
cluster,
but
there's
typically
services
and
services.
Our
services
are
necessarily
scope
to
a
namespace
and
so
having
this
Gateway
class
gives
you
kind
of
another
layer
which
should
describe
con
Behavior,
but
with
a
mesh.
That's
looking
at
the
entire
cluster,
all
the
different
namespaces.
It
feels
like
that.
The
extra
step
feels
like
it's
going
to
be
more
tempting
and
distracting
than
than
useful.
A
It
sounds
like
most
folks
here,
at
least
are
pretty
good
with,
like
are
pretty
agreed
upon,
like
not
reusing
gateway
gateway
class,
so
those
kind
of
options
go
out
the
window
and
Sanskrit
we're
starting
to
narrow
on
an
option,
or
two
and
I'd
like
to
kind
of
throw
up
the
possibility
of
let's
get
those
two
options
codified
in
in
a
gap,
and
you
know
this,
let
me
make
sure
I
have
a
bad
habit.
I'm,
not
sharing
things
completely
I'll
open
this
up
to
everybody
can
edit
and
let's
start
like
working
on
this.
A
To
get
this
get
submitted
because
from
here
I
think
it's
going
to
become
having
this
mesh
representation
get
finished
it's
going
to
make.
The
next
conversation
are
going
to
be
the
harder
conversation
around
binding,
easier
and
so
the
more
time
we
give
ourselves
for
The,
Binding
conversation
I,
think
the
better
go
ahead.
Rob.
D
Yeah
I
just
wanted
to
suggest
something
like
that.
I
know.
We
spent
a
very
long
time
in
the
early
days
of
Gateway
deciding
what
belonged
in
a
route
and
what
belonged
in
the
Gateway
and
what
belonged
in
a
Gateway
class
and
the
way
I
remember
it
is
we
eventually
tried
to
list
out
here
are
the
capabilities
we
want
to
represent
and
without
naming
the
resources
we
tried
to
like
get
them
into
buckets
of
things
that
work
together,
and
can
you
fit
them
all
in
one
bucket?
Can
you
fit
them
in
two?
D
Can
you
fit
them
in
three?
You
know
whatever
it
is.
That
may
be
a
useful
exercise
here.
I
know
we
can
get
really
caught
up
in
naming
and
it
seems
like
most
of
us
don't
care
that
much
about
the
name,
but
just
so
much
about
the
capabilities
and
where
they,
where
they
live.
Maybe
that's.
You
know
just
to
build
on
your
suggestion
there
of
of
having
presenting
multiple
options.
Maybe
those
options
are
presented
without
names.
C
Yeah
all
those
names,
all
those
names
have
lowercase
names
that
don't
imply
the
name
of
kubernetes
like
that
lets.
You
kick
the
naming
thing
until
you've
actually
figured
out
what
fits
into
each
bucket,
yeah
I
would
also
say
the
other
thing.
The
other
thing
to
remember
is
there's
personas
in
the
API
for
a
reason
to
get
API
for
a
reason.
We
should
also
consider
bucketing
the
resources
by
which
Persona
controls
them.
B
Do
we
have
enough
consensus
about
you
know
having
something
like
mesh
class
and
something
like
mesh
enrollment
or
whatever
you
want
to
call
it
I
mean
want
to
select
the
workloads
and
want
to
select
the
implementation
of
the
presence,
implementation,
and
then
debate
spends
the
time
debating.
How
do
you
attach
a
route
to
my
name?
Basically,.
A
C
A
A
So
if
we
cannot
solve
that,
I
mean
the
status
quo
already
exists
for
mesh
implementations
like
we're
not
going
to
we're
not
going
to
attempt
to
lose
functionality
by
not
putting
namespace,
enrollment
or
or
workload
enrollment
into
this.
So
I
did
want
to
call
that
out.
Sorry
to
cut
you
off
kind
of
costume.
B
Semi
also
don't
need
the
image
class
because
that's
also
deferred
to
have
water
permission,
implementation
or
different
versions,
and
it's
also
kind
of
over,
which
is
actually
very
good,
because
we
can
defer
this.
The
naming
for
this,
and
you
know
just
focus
on
the
on
the
first
phase,
which
is
how
do
you
attach
around
to
the
something.
C
We
can
defer
the
exact
design
of
that,
but
we
can
say
hey
the
way
that
you
would
describe
how
that
how
that
theme
work,
how
that
mechanism
worked,
would
belong
in
the
in
the
mesh
config
at
the
mesh
config
level.
Right
like
that,
that
you
know,
and
that's
that's
what
Rob
is
talking
about,
is
that
you
want
to
think
about
the
capabilities
and
whether
or
not
you're
building
them
right.
Now
you
want
to
think
about
what
level
they
belong
at
right,
so
deciding
so
setting
the
mechanism
by
which
people
can
enroll
their
workloads.
C
But
the
capability
then
belongs
to
the
person
who
owns
the
mesh
coffee
yeah
and
then
that,
arguably
you
want
the
application
developer
to
then
be
the
person
who
actually
does
the
workload
enrollment
right
like
and
that
then
that
then
suggests
designs
that
involve
not
giving
them
all
back
to
label
name
spaces
and
a
bunch
of
other
stuff
like
that.
But
but
they're
capable
the
levels
of
the
K,
the
personas
who
the
capabilities
belong
to
then
is
the
thing
that
really
you
know
like.
B
Yeah
I
I
see
your
point,
I
mean
if
you,
if
you
want
to
represent
a
group
of
workloads
that
have
a
set
of
policies
attached,
then
it
may
be
a
good
ways
of
of
the
measure
of
mesh
I
mean
it's
not
going
to
be
used
for
enablement.
It
will
actually
be
used
as
a
way
to
group
workloads
and
to
attach
politics
to
that
group
of
workloads.
What's
the
purpose
of
policy
overrides,
you
know
where
to
attach
the
hardback
and
so
forth,
so
I
I,
I,
I,
I
I,
see
your
point.
I
agree
with.
C
I
think
like
I,
wasn't
exactly
trying
to
say
that,
but
I
see
where
you're
going
like
the
point
that
I
was
trying
to
make
was
like
in
order.
I.
Think
that
Rob's
point
about
like
how
you
design
the
system.
This
is
you
take
write
down
as
many
capabilities
as
you
think
of
as
you
want
the
overall
API
to
be
able
to
handle
right,
like
you
know
that
that
user
stories
thing
that
you
have
in
the
in
the
the
sort
of
mesh
definitions,
Gap
is,
is
a
really
good
example.
C
Here,
right,
like
you
like
you,
you
want,
you
want
those
to
sort
of
the
sorts
of
things
and
then,
and
then
you,
you
sort
of
take
those
and
you
bucket
them
into
their
personas
and
say:
okay,
This
one
belongs
to
the
cluster
administrator
You
Know
This
one
belongs
to
the
to
the
application
developer.
This
one
belongs
to
the
so
I
mean
technically
we
have
three
roles
right:
the
infrastructure
administrator,
the
cluster
administrator
and
a
application
developer
I
feel
like
most
of
this.
C
C
Mesh
in
general
doesn't
expand
past
the
scope
of
the
cluster
itself
right,
unlike
Airways,
which
often
involve
provisioning
stuff
outside
the
cluster,
and
so
that's
another
reason
why
we
had
the
three
layer
structure
there,
where
we
don't
have
it
here,
but
like
because
the
the
two
personas
you're
talking
about
are
really
you
know,
cluster
administrator
and
the
the
cluster
administrator
and
the
application
developer.
Not
the
infrastructure,
you're
going
to
say
the
person
who
Provisions
the
cluster
in
any
outside.
A
So
so
yeah
Shane
point
out
in
the
chat
that
we
are
over
time.
So
I
want
to
thank
everybody
for
showing
up
great
discussion,
I'm,
going
to
kind
of
create
a
message
in
slack
to
kind
of
catapult
the
kind
of
the
work
on
on
the
Gap
in
this
in
the
scuba
doc
to
eventually
get
something
submitted
in
the
pr
but
love
the
thoughts.
If
you've
got
thoughts
that
are
just
overflowing,
you
want
to
put
them
somewhere.