►
From YouTube: Gateway API GAMMA Bi-Weekly Meeting for 20220830
Description
Gateway API GAMMA Bi-Weekly Meeting for 20220830
B
Hello:
everyone
welcome
to
the
august
30th
gateway
api
gamma
meeting
as
regularly
wonder
the.
B
And
we
have
an
open
agenda
that
is
like
linked
in
the
meeting
notes.
So
if
there
are
any
topics
you
would
like
to
discuss,
please
feel
free
to
add
an
item
to
the
meeting
notes
section
and
also,
please
add
your
name
to
the
attendees,
so
we
can
keep
track
of
who
is
coming
to
these
games
and
using
that
for
future
in
considerations
of
planning
the
alternating
time
slots
or
consolidating,
perhaps
all
right
so
yeah.
I
guess
the
first
thing
that
we
have
on
the
agenda
today
is
depth
1291.
B
So
this
is
focusing
on
mesh
representation.
I
guess
also
as
a
reminder.
We
did
successfully
merge
the
first
gap
1324
on
higher
level
mesh
goals.
B
Yeah,
so
if
you
want
to
take
a
look
at
that
to
see
what
we've
gotten
so
far,
that
would
definitely
help
inform
kind
of
like
what
we're
trying
to
prioritize
for
the
next
set
of
resources
that
we're
trying
to
get
in
yeah
and
to
kind
of
recap,
the
discussion
that
we
had
during
the
last
meeting.
B
On
the
other
time
slot,
we
had
a
few
proposed
approaches
for
mesh
representation,
and
there
was
pretty
solid
consensus
on
moving
the
two
proposals
for
reusing
gateway
into
abandon
so
moving
forward
with
an
approach
that
is
not
one
of
those.
B
Basically,
the
kind
of
consideration
was
that
it
could
be
confusing
having
a
bloody
scope,
kind
of
like
unclear,
useless
patterns
and
also
would
be
potentially
an
awful
fit
for
some
of
the
non-side
part
meshes.
So
we
have
three
options
remaining
for
proposed
approaches.
B
I
added
a
new
standalone
mesh
resource
based
on
some
of
the
discussions
we
had
during
last
week
and
tried
to
capture
some
of
the
context
around
why
that
may
be
preferable
to
using
mesh
class
or
mesh
class
and
mesh
split
then
also
added
an
api
section
to
try
to
start
moving
forward
towards
an
actual
spec
for
this
resource,
like
what
fields
should
actually
have
and
yeah
I'll
turn
it
over
to
keith.
If
there's
anything
that
you
want
to
introduce
at
this
point.
C
Yeah,
let
me,
for
clarity's
sake,
go
ahead
and
start
sharing
my
screen
just
so
you
can
see
the
exactly
sorry.
Oh
no
you're
good.
Actually
do
you
mind
sharing
your
screen,
because
I
I'm
your
host.
That's
probably
easier.
C
There
we
go
yes,
so
yeah
mike
appreciate
the
work
that
you
that
you've
done
there.
That's
really
awesome.
I
I
like
the
move
to
start
thinking
about
api
for
the
semester
this
this
mesh
resource.
It's
time.
C
My
train
of
thought
there
but
yeah
you,
you
summarized
the
last
the
last
meeting.
Well
I
I
guess
what
I
want
kind
of
just
if
I
want
to
say
that
I'm
what
I'm
forgetting
the
exact
wording
of
is
I'd
like
to
to
move
quickly
on
this
and
use
this
form
to
discuss,
implementations
or
not
implementations,
but
discuss
any
like
deal
breakers
or
pieces
of
design
you'd
like
to
see
in
and
just
try
to
kind
of
collapse
toward.
Oh,
that's
what
it
was.
C
How
do
we
feel
about
possibly
moving
this
get
right
to
implementable?
I
there's
a
similar
a
get.
That's
doing
that
with
response.
Header
might
not
want
to
do
that
just
because
this
is
a
newer
piece
of
configuration,
but
I
did
want
to
throw
that
idea
out
there.
I
think
the
sooner
that
folks
can
start
iterating
on
something
like
this,
the
better,
and
so
it
might
behoove
us
to
try
to
shoot
for
implementable
size
gap
to
begin
with,
so
that
folks
can
get
some
feedback
quickly.
C
C
I
know
you
still
need
to
double
check
some
of
those
definitions
unless
shane
or
somebody
else
knows
them
off
the
off
topic
of
their
head,
but
there
might
be
a
rule
saying
that
preventative
implementable
for
something
like
gamma,
in
which
case
I'm
totally
fine,
but
I
didn't
want
to
throw
that
out
there
and
ask.
C
Oh
you're,
good
I've
had
issues
with
my
headset,
so
it
might
be
me.
I
was
wondering
if
there's
a
possibility
of
moving
something
like
this
mesh
representation
straight
to
implementable
because
of
all
the
different
things
that
depend
on
it.
But
I
also
recognize
that,
because
of
the
kind
of
experimental
nature
of
gamma
that
we
might
not
want
to
do
that.
D
D
D
F
What
exactly
would
you
implement
with
this
resource?
First
of
all,
second,
I
thought
last
time
we
agreed
that
this
is
kind
of
deferred
and
we
don't
have
an
agreement
on
the
name.
So
remember
that
discussion
is
this.
Resource
is
for
representing
multiple
meshes
and
we
agreed
that
multiple
meshes
is
not
really
what
we
want
to
tackle.
First,
because
we
don't
really
have
a
lot
of
things,
and
second,
is
that
we
need
to
have
some
process
to
agree
on
a
name,
because
some
people
prefer
mesh
class.
Some
people
prefer
much.
F
Some
people
may
prefer
other
names,
so
I
I
would,
I
would
hold
on
first
of
all
proposing
it
anti-directly
on
a
name
and
second,
maybe
implementable
should
be
stuff.
That
is
not
different.
I
mean,
if
you
understand
my
my
concern
here,
there's
nothing
you
can
do
with
this
resource.
I
mean,
yes,
you
put
a
resource
and
what
happened
next.
F
There
is
no
way
to
determine
what
resources
will
use
this
mesh
and
then,
if
we
use
one
which
is
annotation
or
something
like
that,
we
already
the
implementers
already
have
a
way
to
to
use
it.
So
I
don't
really
see
the
practical
use
of
this
resource,
in
particular
I'll
understand,
to
move
http
route,
for
example,
to
implementable.
F
B
F
B
One
part
of
your
question:
I
tried
in
the
doc
there's
three
options
listed
under
approaches
for
kind
of
like
trying
to
like
articulate
the
difference
between
naming
something
mesh
versus
mesh
class
and
whether
that's
like
one
or
two
different
resources.
So
there's
three
options
there.
We
don't
have
consensus
on
one
of
those,
in
particular
being
the
thing
that's
decided
yet,
but
we're
hoping
to
get
to
that
soon,
and
this
is
specifically
on
the
high
level.
B
I
have
a
mesh
to
point
to
my
cluster,
where,
like
leaving
the
design
space
open
but
explicitly
not
trying
to
do
like
this
is
how
you
represent
multiple
meshes.
This
is
how
you
do
anything
like
that,
so
this
is
intended
to
just
at
this
time
represent
a
single
mesh.
That's
the
use
case
that
we're
trying
to
prioritize
but
kind
of
without
we're,
closing
expanding
on
that
in
the
future.
B
To
your
next
point
about
kind
of
like
services
and
http
roots
like
that,
is
in
a
different
gap
that
will
be
a
different
gap
that
is
not
intended
to
be
covered
by
the
scope.
This
is
just
I
am
deploying
seo.
I
am
deploying
console
whatever
it
may
be,
and
this
is
kind
of
my
global
configuration
or
like
cluster
operator
level,
concerns
for
how
that
should
happen.
F
B
Yeah
I
mean,
I
think
that
does
nothing.
I
think,
that's
a
great
thing
to
add
a
section
to
this
gap
of
like
what.
What
does
this
mean?
What
are
the
responsibilities
of
like
what
should
happen?
If
you
see
this
resource
in
a
cluster,
a
controller
should
do
it
and
should
perhaps
parse
the
config
from
parameters
ref
and
apply
that
to
an
installed
mesh
configuration
like,
I
think,
being
explicit
about
what
that
intended
functionality
is,
would
be
really
helpful
to
add,
but.
F
In
order
to
have
a
controller
to
install
the
mesh,
if
I
install
the
mesh,
I
have
the
parameters
already,
so
it's
kind
of
redundant
things
in
the
first
place
I
mean
for
mesh
class.
There
is
maybe
some
purpose,
but
I
don't
I
mean
it's
I
I
would.
I
don't
know
if,
if
if
we
want
to
spend
the
time
by
changing
on
the
name
of
this,
do
nothing
object.
That's
fine,
probably
because
it's
mostly
harmless
but
and
then
the
important
one
would
be
that
the
other
one
which
is
which
selects
the
enablement.
F
So
the
one
where
you
can
put
this
workload
specifier
and
which
is
permanent
space
and
then
select
that
that
may
be
more
useful
in
the
performance
implementers.
But
I'm
not
going
to
object
to
this
because
again
it's
it
doesn't
do
anything.
It's
not
harmful
but
except
the
name,
maybe
because
it
affects
the
other.
E
F
B
Yeah,
so
so
I
think
there's.
Actually,
there
is
a
similar
pattern
in
the
north
south
gateway
api.
That
has
that
use
case
as
well
like
one
of
the
deployment
models.
Is
configuring
resources
which
have
already
been
provisioned
as
opposed
to
an
and
different
model,
is
actually
provisioning
resources
from
professionally
underlying
hardware
like
or
software
from?
What
is
the
point
there
yeah,
so
I
I
I'll
see
hands
right,
so
I'll
turn
it
first
to
keith
and
then
to
john.
C
Yeah,
so
I
think
one
of
the
areas
of
confusion
here
is-
and
we
talked
about
this
a
bit
in
the
last
meeting,
but
there's
kind
of
two
different
approaches
to
to
going
about
this,
and
at
least
two
different
approaches
we
talked
about
and
at
a
high
level,
they're
the
single
resource
use
case
and
the
double
resource
approach
and
the
the
single
resource
approach
seemed
to
be
where,
if
I
remember
correctly,
there
seemed
to
be
some
light
consensus
heading
towards
a
single
resource
approach,
forgetting
names
gateway,
class,
mesh
class.
C
Whatever?
What
have
you
the
from
what
I
remember.
The
idea
was
that
you
could
have
two
resources
kind
of
you
know
with
the
typical
kubernetes
parlance
of
say,
a
storage
class
and
a
persistent
volume
where
one
is
describing
the
one
resource
describing
kind
of
the
blueprint
of
the
thing
being
instantiated,
and
the
important
thing
is
that
second
resource,
which
represents
the
actual
thing,
the
other
one.
The
other
approach,
the
single
resource
approach,
which
is,
if
I'm
understanding,
reading
mike's
api
design,
that
mesh
standalone
mesh
option
correctly.
C
C
There
is
some
it's
hard
to
see
the
usefulness
of
that
resource
until
you
start
thinking
about
things
like
deployment
models
and
versioning
and
things
of
that
nature,
but
I
wouldn't
say
that
that
resource
is
is
useless,
even
if
you
exclude
our
deferred
goals
of
deployment
models,
multimedia
etc,
because
what
that
allows
you
to
do
is
even
when
doing
something
like
service
binding
you're
able
to
to
show
ownership
of
of
that
mess.
C
You're
able
to
do
some
kind
of
discovery
of
meshes
quote
unquote
or
of
a
mesh
that
exists
on
a
cluster,
but
I
do
sympathize
that
it's
it's
a
bit
confusing,
because
to
my
knowledge,
not
many
meshes
have
something
like
this
already.
The
only
the
closest
thing
I
can
think
of
actually
is
the.
C
I
believe
now
discouraged
issue
operator
approach
where
you
would
create
a
instance
of
seo
operator
and
the
operator
controller
would
read
that
resource
to
something
like
that.
C
Oh
kuma
seems
to
have
a
concept
of
that
as
well,
so
I
think
there's
definitely
uses
for
it
in
over
time
and
I
hope
to
discuss
this
perhaps
in
this
gap,
but
over
time
it
would
be
awesome
to
see
you
know
what
kind
of
where
the
separation
would
be
between
the
implementation
specific,
like
mesh,
config
kind
of
resource
versus
this,
this
general
gateway
mesh
resource.
So
I
said
a
lot
of
things.
Hopefully
that
didn't
make
things
more
confusing
I'll
turn
over
to
john.
H
Yeah,
I
was
going
to
say
I
don't
know,
I
think,
kind
of
a
lot
of
overlap,
but
it's
almost
hard
to
decide
how
we
represent
the
mesh.
If
we
don't
know
why
we're
representing
it
yet
like
if
we
you
know
in
the
service
mining
stuff
we
talked
about
originally,
we
had
some
examples
where
the
route
directly
referenced
a
mesh,
and
if
that's
something
we
want
to
do,
then
it's
it's
useful.
H
I
think
to
have
a
mesh
object,
even
if
it
largely
doesn't
do
anything
like
gateway
class,
doesn't
really
do
anything
except
for
give
a
gateway
somewhere
to
point
to
right,
and
so
you
know
if
we
go
down
that
route,
that
mesh
makes
a
lot
of
sense.
If
we
end
up
having
routes,
not
really
actually
refer
to
the
mesh
at
all,
then
this
whole
kind
of
standalone
mesh
object
that
doesn't
really
do
that.
Much
is
probably
less
valuable.
So
I
don't
not
necessarily
the
same
like
we
need
to.
H
You
know
completely
stop
this,
but
it
is
helpful
like
before
we
make
a
final
decision.
I
think
it
would
be
useful
to
know
how
we're
going
to
use
it
as
well.
Probably.
H
E
G
Okay,
okay,
so
I
can
give
you
a
little
bit
more
context
how
we
use
the
measuring
dose
in
kuma,
so
yeah.
We
actually
have
mesh
readers,
which
means
that
you
can
segment
your
like
call
mesh
into
multiple
meshes
and
then
have
a
mesh
specific
configuration.
So
all
the
policies
are
bound
to
a
specific
mesh
and
so
on
right.
G
So
we
have
this
multi
tenancy,
which
is
like
lifted
at
both
main
spaces
and
also
we
carry
this
concept
of
lights
are
outside
of
kubernetes,
so
I
mean
if
a
mesh
would
not
have
this
kind
of
multi-tenancy
right,
that
you
need
to
group
things
into
specific
measures,
and
I
kind
of
agree
that
it's
a
bit
useless
to
have
this
kind
of
resource.
A
What
happened
for
the
multi-cluster
use
case?
Let's
say
if
I
have
class
a
class
to
b
belong
to
mesh
one
and
class
to
c
and
cluster
d.
F
A
Yeah
as
a
cluster,
a
right
which
class
which
mesh
I
belong
to
do
I
belong
to
measure
one
I'll
be
on
to
mesh
two.
As
as
the
organization
I
have
two
meshes,
I
have
four
clusters,
so
I
do
need.
As
a
you
know,
I
mean
the
cluster,
a
I
don't
need
to
say
yeah,
I'm,
I'm
part
of
you
know
I'm
going
to
use
mesh
one
or
I'm
going
to
provide
service
to
mesh
one
as
a
distinguishing.
It's
not
like
you
know,
they're,
multiple.
As
my
organization,
I
have
multiple
measures.
B
I
guess,
as
a
as
a
way
to
like
try
to
this
forward,
wouldn't
it
be
helpful
to
instead
of
focusing
on
concrete,
like
stack
stuff
at
this
time,
to
focus
on
a
section
of
like
what
is
the
purpose
of
this,
and,
and
maybe
that
ends
up
deferring
this
and
we
like
circle
back
to
the
like
service
binding
mesh
thing
first,
if
that,
if
the
usefulness
of
this
is
directly
dependent
on
that,
but
at
least
I
hope
to
kind
of
like
get
these
ideas
into
one
place,
that
does
that
seem
like
a
reasonable
thing
that
would
help
with
this.
C
I
I
I
answer
your
question
mike
I
so
we
seem
to
be
in
this
interesting
spot
where
we're
trying
to
create.
You
know
two
very
foundational
principles
of
of
how
we
buy
services
to
to
to
routes
and
mesh
simultaneously
yeah
circular
dependency
chain,
and
I
think
that
so
two
things
that
I
think
would
be
useful
here.
C
One
I
want
to
clarify
the
meaning
of
a
deferred
goal
for
a
bit,
because
I
think
that
there
is
you
folks
might
disagree
with
me
here,
but
I
think
there's
value
in
understanding
that
a
deferred
goal
may
be
a
use
case,
while
not
digging
into
implementation.
Details
of
said,
deferred
goal
the
the
purpose
of
deferring
certain
goals
in
that
high
level
gap
was
to
try
to
prevent
us
from
solving.
C
You
know
from
doing
a
bunch
of
of
scope
creep
and
trying
to
boil
the
ocean
and
solve
too
much
at
one
time.
That
doesn't
mean
that
those
aren't
things
that
we
need
to
eventually
get
to.
So
if
we
say
okay,
we're
going
to
need
something
to
represent
this
represent
this
mesh,
even
though
the
details
of
how
we
go
about
or
for
the.
If
we
need
something
represent
this
mesh,
it
comes
in
once
a
cluster
case.
Even
the
details
of
how
we
represent
said
mesh
might
be
deferred.
C
I
think
they
still
need
to
make
sure
there's
space
in
the
api
to
go
about
doing
that,
to
to
kind
of
take
some
phrasing.
So
I
want
to
say
that
about
the
verticals.
The
second
thing
is,
I
I,
I
think,
I'm
gonna.
C
I
might
go
back
on
myself
here,
because
earlier
I
I
felt
like
it
was
time
to
get
into
api
design
for
this
resource,
but
as
we're
talking
about
it,
that's
circular
dependency
point
it's
very
difficult
to
have
these
as
two
separate
conversations,
so
I'm
I'm
wondering
if
perhaps
having
narrowed
down
some
of
the
metric
presentation
approaches,
and
we
kind
of
have
this
core
thing
of
what
is
that?
What
should
this
thing?
Do?
C
It
almost
seems
like
the
service,
binding
is
might
be
the
more
foundational
gap,
and
it
might
be
more
useful
to
shift
to
to
that
at
least
for
a
bit
and
kind
of
do
this
spot
iteration
of
both
until
we
eventually
see
a
convergence
yeah.
So
I
apparently
I'm
really
good
at
like
asking
questions
and
not
answering
them,
and
I'm
gonna
do
that
here
and
let
other
folks
with
their
hand,
raised
weigh
in.
F
Oh
sorry
so
yeah
to
answer
to
what.
F
I
think
that's
super
useful.
I
mean
I
that's
how
I
see
the
mesh
resource
being
used
as
well,
but
it
seems
that
the
spec
here
is
more
like
a
gateway
class,
where
it's
a
cluster-wide
resource
that
has
the
implementation
pointer
to
implementation
and
configuration
for
the
implementation
is
not
the
one
we
select.
F
I
I
think
robots
or
someone
mentioned
last
meeting
that
we
should
define
first
the
concepts
we
want
without
putting
names
to
them
and
one
of
them
being
the
class
or
kind
of
the
implementation
configuration
which
is
a
pair
cluster
resource
specific
to
the
measurement
to
the
cluster
admin.
And
then
there
is
a
one
we
discussed
about
enablement.
F
I
I
I
I'm
very
confused
about
what
what
was
the
intent
of
this
mesh
object
in
in
respect,
because
when
I
read
the
doc
it
seems
like
it's
it's
a
cluster
why?
That
means
specifies
an
implementation,
not
the.
I
want
this
namespace
to
use
workloads
in
these
things
just
to
use
this
mesh,
the
second
one.
I
think
it's
probably
for
useful
and
probably
should
do
it-
I
mean
when
it
last
meeting.
F
It
was
considered
that
it
should
be
deferred,
but
that's
not
a
bad
thing
to
to
explore
now,
but
I'm
not
completely
against
it,
but
just
trying
to
understand
which
one
you
you
have
in
mind.
B
So
I
those
are
both
options
that
are
captured
as
two
different
possible
approaches
in
in
this
document.
Currently
one
is
having
mesh
as
a
namespace
resource
to
configure
enrollment.
The
other
is
the
cluster
scope
resource
where
the
operator
configures
enrollment
through
a
namespace
selector,
or
something
like
that.
So
there's
ux
options
for
like
how
it's
implemented,
but
it's
a
similar
goal
of
representing
the
mesh
and
defining
how
services
are
allowed
to
join
it
from
the
cluster
operator
perspective.
E
To
me
the
thing
that
okay,
let
me
back
up
first
off
keith
to
your
question
about.
Perhaps
we
should
shift
over
and
look
at
service
bindings
for
a
little
bit.
I'm
interpreting
interpreting
that,
as
perhaps
we
should
look
at
the
concept
of
how
we
associate
services
with
meshes
and
routes,
and
things
like
that.
I
think
that
was
a
good
thing
to
look
at
with
respect
to
the
mesh
discussion.
E
I
don't
know
show
of
hands
or
something
how
many
people
feel
that
it's
particularly
critical
in
the
short
term
to
support
running
more
than
one
mesh
simultaneously
in
a
cluster,
and
the
reason
I
ask
is,
I'm
not
sure
I've
ever
seen.
Anybody
actually
do
that
ever
at
all,
full
stop.
I'm
sure
that
somebody
must
have
there's
enough
discussion
around
it
that
I
figure
that
perhaps
other
people
have
found
this
to
be
more
meaningful
than
I
have,
but
I've
literally
never
seen
anybody
do
it.
I've
never
heard
anybody
discuss
it.
G
E
F
So
if
you
have
enablement,
then
it
is
possible
already
to
have
two
of
them.
So
it's
kind
of
you
know
each
measures
its
own,
but
let's
not
worry
about
it.
That's
the
last
thing
to
solve
right
now.
First,
we
need
to
have
one
implementation
and
then
we
can
worry
about
how
to
migrate
to
the
second
one
right.
E
I
wasn't-
I
wasn't
here
last
week
the
week
before
that
I
thought
that
that
point
about
a
route
being
from
mesh,
not
gateway,
was
still
under
discussion,
but
but
that
being
said
yeah,
I
agree
that
it
sounds
like.
It
definitely
sounds
desirable
to
be
able
to
make
that
distinction.
C
Yeah,
I
agree,
and
I
thinking
back
to
your
point.
I
think
that
the
I
mean,
if
that's
the
problem,
we're
trying
to
solve
is
how
to
distinguish
a
route
or
how
to
say
that
route
is
for
mesh,
not
gateway.
We're
already
talking
about
how
about
the
routing
api
and
how
we're
and
now
we're
binding
things,
and
that
probably
seems
like
a
more
appropriate
place
to
have
that
conversation.
E
B
Working,
it
might
be
helpful
to,
instead
of
trying
to
like
block
on
getting
this
merged
first
before
moving
on
to
service
binding
to
try
to
work
on
them
in
parallel
towards
convergence.
Trying
to
add
a
section
on
like
the
ux
of
this
mesh
object
in
terms
of
understanding
how
it
would
or
could
be
used
and
also
how
it
would
or
would
not
interact
with
other
methods
of
deploying
a
mesh,
whether
that
be
an
operator,
whether
that
be
a
helm
chart
or
whatever.
It
is.
B
How
one
could
express
configurations
through
this
object
versus
that
that
kind
of
existing
pattern
and
then
try
to
shift
focus
back
over
towards
the
like
service,
binding,
http,
root
kind
of
discussion,
because
that
seems
to
be
what
necessitated
like
the
direction
I
was
going
is
what
necessitated
the
creation
of
this.
So
if
we
can
move
that
forward,
then
that
might
help
it
to
make
it
more
evident.
What
purpose
this
place
is.
Is
that
a
reasonable
kind
of
recap
of
where
we're
at.
B
I
I'm
behind
on
chat.
Is
there
anything
in
chat
that
is
worth
bringing
up
at
this
point.
F
I
I
think,
we're
starting
to
discuss
the
the.
How
do
you
attach
http
route
to
the
machine?
I
think
that
that
was
kind
of
the
reason
why
the
mesh
was
introduced
in
kind
of
the
where
so
parent
ref
in
http
routes
should
refer
to
something
other
than
gateway
in
order
to
be
bound
to
the
mesh,
and
we
need
to
introduce
this
mesh
object.
Just
for
the
sake
to
have
something
to
put
in
par
and
ref.
Can
we
put
some
magic
value?
Can
we
put
the
service
itself?
F
Can
we
leave
it
blank
because
it
seems
that
to
make
progress
for
implementation
would
be?
You
know
the
most
important
thing
would
be
hey.
I
have
an
http
route,
I
know
http
route
is
specified.
I
know
how
it
should
work.
How
do
I
make
it
work
for
the
mesh.
A
A
B
Yeah,
I
agree,
I
think
those
concerns
are
really
helpful
for
thinking
about
it
and
I
think
that's
also
kind
of
compatible.
We've
seen
a
cluster
scope
role
for
deploying
a
mesh,
then
app
developers,
control,
granular
router
for
their
services
that
they
own.
B
Well,
all
right,
I
I
can
take
the
lead
on
trying
to
add
a
section
to
the
message:
representation
depth
on
the
like.
What
is
the
purpose
of
this
object
and
also
just
like
I
don't
have
all
the
answers.
I
would
love
to
hear
from
other
implementations
about
how
it
may
or
may
not
contract
with
different
deployment
models,
including
substances.
Would
you
use
a
parameters,
ref
configuration
object
or
not
because
it
sounds
like
even
for
gateway
api.
B
B
I'm
unsure
if
the
existing
service
binding
gap
or
if
we
need
to
start
a
third
dock
for
the
like
http
route
to
mesh
binding.
But
it
sounds
like
like
that's
where
we'll
try
to
like
async
collaborate
on
figuring
out
how
to
start
getting
more
of
that
kind
of
hook
together.
B
Next
item
on
the
agenda:
keith,
you
got
a
question
about
usefulness
of
this
time.
Slot.
C
Yeah
and
right
before
I
go
into
that
by
the
way
do
I
do
I
sound
better.
I
had
some
folks
have
some
issues
hearing
me.
Do
I
sound
so
far
so
good,
okay,
awesome,
okay,
so
one
thing
I
wanted
to
add
is
I
just
put
the
link
to
the
mesh
service
binding
gap
in
the
zoom
chat.
So
that's
a
good
place
to
start.
C
I
wrote
it
initially,
but
spent
most
of
my
time
on
my
presentation
would
love
folks
to
contribute
their
perspectives
on
that
on
that
gap
and
try
to,
of
course,
add
my
own
as
I
get
time
but
yeah
as
far
as
my
agenda
item
on
the
usefulness
of
this
time
slot
so
just
wanted
to
get
a
pulse
for
you
know
how
folks
are
finding
this
useful
this
alternating
time
slot
thing
useful.
This
is
our
third
meeting
at
this
time
slot.
C
I
believe,
we've
been
meeting
with
gamma
for
about
a
month
a
little
bit
more
and
are
there?
Are
there
people
here
who
wouldn't
be
able
to
make
it
to
these
meetings?
If
we
didn't
have
this
early
time,
slot
do
folks
folks
prefer
the
5
or
the
3
pm
pacific
time
time
slot.
C
E
B
E
C
Sorry
I
missed
a
lot
of
what
was
just
said.
I
I
realized
that
the
spottiness,
with
my
with
my
sound,
was
due
to
my
internet
connection.
There's
some
cut
fiber
in
my
neighborhood,
so
I
missed
like
all
what
just
said,
but
based
on
the
notes,
it
seems
like
a
lot
of
east
coast.
Folks
prefer
this
time
slot
it's
a
bit
more
difficult
for
for
the
west
coast,
man.
I
can
sympathize
with
that.
Is
there
oh
did.
I
did.
I
miss
a
question
that
somebody
asked.
B
Oh,
just
just
mostly
try-
and
we
can
ask
this
in
slack
as
well,
but
just
trying
to
get
a
better
sense
of
if
there
are
folks
in
europe,
for
instance,
who
would
be
unable
to
attend
these
meetings
at
all
if
we
move
away
from
this
time
slot
or
if
we
move
this
an
hour
or
two
later,
if
that
would
unduly
impact
folks
further
east
who
may
wish
to
attend
this.
B
Yeah
I'll
capture
some
notes-
and
I
can
put
something
in
slack-
some
feedback
on
this,
but
in
general
it
sounds
like
it's
nice
for
us
folks,
east
folks,
to
have
this
time
slot.
But
it's
definitely
difficult
for
west
coast.
H
E
C
Awesome,
I
appreciate
the
feedback
and
I
know
the
shane.
I
think
you
have
the
agenda
item
a
couple
weeks
ago
about
this
part,
the
possibility
of
this
time
slot
for
the
regular
gateway
api
meeting.
This
is
feedback
help.
D
D
So
my
point
just
being,
and
then
I
picked
on
flynn
my
point
just
being
still
not
sure
like
how
much
cross
meeting
like
how
many
people
are
actually
going
to
go
to
both
kind
of
thing
and
how
many
people
would
start
showing
up
if
we
had
an
earlier
gateway,
one
we'll
keep
looking
at
it.
But
it's
it's
interesting
to
note
that
a
lot
of
people
like
this
time
slot
for
this
meeting.
E
The
gateway
api
meetings
I
went
back
after
the
first
time.
Shane
was
mocking
me
for
not
being
there.
I
went
back
and
was
checking
out
the
calendar
and
yeah
the
gateway.
Api
meetings
are
largely
impossible
for
me
right
now,
because
either
they're
conflicting
with
family,
stuff
or
they're,
conflicting
with
the
onboard
gateway
meetings
or
they're
conflicting
with
this.
So
or
maybe
it's
just
this
and
not
the
onboard
gateway,
but
logistically
yeah
the
gateway
api.
E
I
would,
I
would
certainly
look
into
it.
Yeah,
it's
okay,.
D
B
Differentiating
between
subject
matter
focus
versus
time
zone
focus
of
it's
possible.
Some
folks
are
just
interested
in
gateway
for
mesh,
and
that's
why
it
makes
sense
for
them
to
join
this
meeting
and
not
the
general
gateway
api
i1.
At
this
time,.
E
D
D
E
C
Or
even
start
innovating
ways
to
streamline
that
as
opposed
to
trying
to
avoid
it.
I
think
they're,
probably
some
so
many
smart
people
working
what
we
work
on
they're,
probably
ways
to
make
things
go
smoother.
If,
if
we
want
to
accept
that
reality,
but
I
I'm.
C
Absolutely
and
I
for
one
really
enjoy
you
know
having
folks
who
are
able
to
spend
more
time
and
focus
on
these
in
these
meetings,
since
it's
not
a
inconvenient
time
slot
like
like
with
family,
stuff
or
folks
in
in
central
europe,
I
mean
the
the
name
on
the
calendar.
Is
the
emea
friendly
time
slot
and
I
really
like
the
contributions
and
attendance
of
folks
there
as
well?
So
that's
just
that's
my
two
cents,
but
again
we
really
appreciate
all
the
feedback
there.
C
If
you've
got
other
feedback,
feel
free
to.
Let
us
know
in
slack
or
ping
me
directly,
if
you
don't
feel
comfortable,
saying
it
publicly,
but
yeah
really
love
all
the
feedback
from
folks
on
these
meeting
times.
B
All
right,
so
I
have
one
last
question
before
we
wrap
up
it's
our
decision
on
kubecon
in
person.
I
remember
there
had
been
some
discussion
about
trying
to
gather
tuesday.
I
think
like
pending
the
service
meshcon
schedule.
D
So
we
got
a
couple
minutes
left
and
there's
nothing
else
to
go
over
right.
F
D
I
don't
think
we
necessarily
need
to
talk
about
it
right
here
right
now,
but
I
would
like
to
dig
in
a
little
bit
deeper
on
the
idea
of
like
how
to
poc
when
gapping,
because
it's
made
me
think
that
that
would
be
a
good
thing
to
kind
of
have
provisions
for,
on
the
other
hand,
if
we
just
need
to
get
your
thing
to
implementable
and
like
start
building
the
thing
and
say
that
it's
you
know
part
of
the
actual
experimental
api,
that's
potentially
fine
too.
I
don't
want
to
get
in
your
way,
but.
B
D
E
D
D
D
That's
kind
of
what
I'm
just
I'm
just
thinking
about,
but
end
of
the
day.
We
have
the
provision
for
experimental
if
everybody's
in,
if,
if
nobody's
like,
opposed
to
us,
saying
that
something
that's
still
provisional
can
be
an
experimental,
then
that's
all
we
need
that's
all
the
runway.
We
need
to
start
building
something.
E
D
E
D
We've
never
really
exercised
the
idea
of
having
something
that's
like
provisional
and
we
might
really
change
everything
about
it,
getting
published
as
something
that
people
could
potentially
like
the
the
the
side
effect
of
experimental
right
now
is
that
even
though
it
could
change
most
people
are
implemented
or
not
most
people.
There's
lots
of
implementations
going
on
into
experimental,
so
that
kong
we're
implementing
as
much
of
experimental
as
we
possibly
can
right.
So
it's
just
it's
not
something.
D
Let's
just
call
it
that
how
many
people
in
here
are
gonna
like
as
soon
as
something
hits
experiment
like
if,
if
we
were
to
do
it,
that
way,
I
mean:
is
everybody
in
here
ready
to
start
implementing?
That,
like
is
everybody
here?
Ready
just
wants
to
start
experimenting
once
we
have
like
real
apis
and
stuff
like
that
written
down?
Is
it
or
is
everybody
what's
the
appetite
for
like
jumping
right
on
top
of
this
stuff
as
soon
as
it
hits
the
ground
versus
waiting
a
little
while
and
seeing
what
shakes
out.
F
It's
actually
far
better
to
have
implementations
going
parallel,
because
that
that's
how
we
find
out
problems
with
implementation
and
with
the
specification
for
the
server
it
was
kind
of
the
same
thing.
Vendors
moved
along
with
with
the
spec,
but
I
wanted
to
point
that
http
route
is
not
experimental,
I
mean
it's
a.
We
may
disagree
about
how
to
call
the
parent
ref,
but
everything
else
it's
pretty
stable.
You
know
it's
better
and-
and
you
know
parent
is
part
of
the
specification.
F
It's
just
we
may
differ
and
what
we
put
there,
but
everything
else,
policy
attachment
and
pretty
much
all
other
aspects
of
the
specifications.
I
think
we
have
more
or
less
consensus
that
are
going
to
reuse
what
is
defining
gateway
api,
so
we
could
have
almost
complete
functional
implementation.
I
think
there
are
a
few
already
so.
D
C
That
sounds
cool
to
me.
I
do
want
to
call
out
to
constant's
point
I
this
is
a
game.
Is
an
interesting
initiative
here
because,
like
any
like
60
to
70
of
what
we're
working
on
here
is
semantics
around
things
that
are
separately
versioned.
So
http
route
is
already
at
a
certain
level
of
stable
versus
experimental
and
alpha
beta
gaps,
runner
implementable,
et
cetera,
but
what
we're?
What
we're
changing
you
know
in?
In
some
cases,
it'll
be
really
nice,
but
in
some
cases
we
might
not
even
be
adding
fields.
C
We
might
not
be
changing
resources,
we're
just
adding
semantics
on
how
these
things
should
be
interpreted,
and
it's
almost
like
because
of
the
kind
of
how
we're
trying
to
move
with
gamma
like
it's
almost
like
there
there's
a
it's
a
temptation
to
version
those
separately
or
even
intentionally,
but
like
that's
a
negative
connotation,
but
like
there's
the
ability
or
the
thought
to
maybe
version
those
separately
than
the
actual
resources
around
which
we're
defining
semantics.
I
think
that
sentence
makes
sense,
but
to
take
the
http
route
case.
You
know,
let's
say
we.
C
We
use
parent
ref
to
refer
to
a
service
that
for
binding
is
that
experimental
or
is
that
should
does
that?
Go
straight
to
stable,
because
http
route
is
stable,
does
gateway
api
even
have
a
mechanism
to
distinguish
the
two.
C
It
feels
like
that's
where
the
get
process
plays
in
because
got
provisional,
provisional,
implementable,
etc
for
the
status
of
that
gap.
But
I
don't
know
if
you've
got
like
experimental
to
change
point
experimental,
implementable
gaps
for
semantics
on
top
of
stable
resources
that
that
that
matrix
gets
a
little
funky
when
trying
to
talk
about
like
deprecation
and
api
compatibility,
promises
and
such
so.
It's
a
weird
state
to
be
in.
F
It's
not
so
funky
I
mean
the
gateway
api
defines
vendor
extensions.
That's
pretty
much
what
everyone
would
do.
I
mean
it's
a
vendor-specific
policy.
It's
a
vendor
because
parent
ref
it's
any
resource.
If
it's
a
vendor
resource,
then
it's
a
legitimate
extensions,
maybe
a
bit
abusing
the
concept.
But
it's
not.
You
know
unforeseen
by
the
specification.
B
I
think
it
definitely
is
easier
if
it
points
to
a
thing
that
is
in
an
experimental
channel
and
like
has
its
own
gap,
then
yeah
but
yeah.
I
don't
think
it's
blocked
by,
like
you
said,
like
though
there
is
that
vendor
specific
kind
of
our
implementation
specific
out
so.
B
E
It
does.
It
does
feel
a
little
bit
strange
to
me
to
think
about
the
case
where
you
have
something
running,
you
decide
to
install
a
gamma
mesh
into
a
cluster
that
say:
didn't
have
a
mesh
beforehand.
It
would
feel
strange
to
me
to
suddenly
go.
Oh
now,
you
have
to
change
the
version
on
all
of
your
existing
http
routes
to
be
able
to
play
with
this.
E
B
E
I
think
we
kind
of
have
to
I
feel
like
there
may
very
well
be
cases
where
we
need
to
balance
that
against
oh
we're
about
to
change
the
semantic
in
a
way
that
will
surprise
people,
but
I
don't
know
what
those
cases
are
yet.
I
just
feel
like
some
of
them
are
likely
to
come
up,
and
you
know
not
wanting
to
change
the
cluster's
configuration
does
not
for
me
necessarily.
B
All
right:
well,
I
think
that's
about
our
time.
I
will
wrap
it
up
there
thanks
for
participating
everyone,
and
hopefully
we
can
try
to
iterate
on
these
stocks.
In
the
meantime,
before
the
next
meeting.
C
I'll
post
the
mesh
service
binding
dock
in
slack
with
a
kind
of
short
blurb
about
what
you
want
to
do
with
it.