►
From YouTube: SIG Network - Gateway API GAMMA Meeting 20221108
Description
SIG Network - Gateway API GAMMA Meeting 20221108
A
Hi
everyone
good
morning
afternoon
or
evening
as
it
may
be-
welcome
to
the
November
8th
meeting
of
Skateway
API
is
gamma
working
group
as
always
kubernetes
code
of
conduct
rules
are
in
effect,
so
please
treat
each
other
respectfully
and
with
that,
let's
get
on
to
the
reading,
it
is
an
open
Agenda.
So
the
meeting
node
stock
should
be
linked
in
the
media.
Invite
anyone
feel
free
to
add
a
topic
that
you're
interested
in
talking
about,
and
also
please
add
your
name
to
the
list
of
attendees.
C
A
A
Checking
out,
there's
gonna
be
a
lot
of
interesting
excitement
about
Gateway,
API
overall
and
yeah
I
just
wanted
to
specifically
call
out
the
admin,
Network
policy
talk
and
the
liquidity
off
Z
talk
as
both
being
potentially
relevant
to
kind
of
future
direction
of
gamma
offices
that
things
I.
Don't
think
that
the
videos
are
up
yet,
but
I
believe
they
should
be
on
those
talk
links
eventually
when
they
get
there
and
yeah.
A
We
also
have
some
good
discussions
with
our
stick:
multi-cluster
folks,
they're
kind
of
looking
for
the
next
wave
of
projects
past
the
current
MCS
API
work,
so
that
may
be
an
average
collaborate
on
for
things
as
we
start
looking
at
like
off
cluster
multi-cluster
and
other
such
concerns.
So
that's
another
thing
to
keep
an
eye
on
for
the
future.
A
A
If
you
totally
work
the
boiler
put
stuff
for
starting
to
write
some
meaningful
to
get
my
performance
tests
without
spending
too
much
time,
Reinventing
the
wheel
on
that
kind
of
stuff,
and
we
have
a
milestone
for
tracking
implementation
Readiness
for
gamma
there's
a
handful
of
tasks
in
there
that
basically
came
out
of
comment
threads
in
the
original
Gap
I
was
working
on
that
has
now
been
merged.
So
that
is
kind
of
like
where
we're
tracking
next
steps
for
like
officially
marketing
this
as
hey.
A
A
So
the
way
to
get
around
it
to
specify
Services
paragraph
is,
you
will
have
to
explicitly
set
the
empty
string.
As
the
group
it's
not
ideal.
We
agreed
that
it
should
not
be
a
blocker
for
Alpha,
but
is
definitely
something
to
take
a
closer
look
at
as
a
blocker
for
beta,
and
we
also
want
to
kind
of
escalate
it
up
to
I
think
it
was
a
API
Machinery
group
to
try
to
like
see
if
other
people
are
having
similar,
weird
ux
issues
with
this.
A
E
A
A
D
First
off
my
apologies
for
the
delay
on
that
one,
the
linkery
folks
were
at
kubecon,
and
then
we
had
a
company
all
all
hands
after
that.
So
things
have
been
a
little
strange,
the
last
couple
of
weeks,
but
we
did
in
fact
get
together
with
some
of
the
Linker
D
maintainers
and
go
over
1426
with
a
relatively
fine
tooth.
Comb
and
mate
will
keep
me
honest
here
because
he's
on
the
call
as
well
but
I
think.
D
F
F
I
actually
totally
agree
with
you.
I
think
I
want
to
say
Alpha,
but
I,
don't
I,
don't
know.
I
had
a
good
check,
I
think
every
restriction
in
there
I
wanted
to
lift
as
well
and
I
just
wanted
to
get
it
merged
first,
so
then
I
sent
follow-ups,
removing
a
lot
of
them.
I
haven't
got
to
all
of
them.
Some
have
openpr's
because
there's
things
to
work
out,
but
I
totally
agree
with
you.
The
one
about
namespaces
I
think
is,
is
tricky.
D
It
was
pretty
clear
that
they
were
intended
as
temporary
I
wanted
to
bring
it
up,
mostly
just
in
the
sense
of
it
felt
like
the
sort
of
thing
that
we
might
want
to
actually
try
to
to
rephrase
as
yeah.
If
you
have
an
implementation
that
that
this
will
make
easier
go
for
it.
But
if
you
have
some,
you
know
existing
thing
where
you
want
to
to
relax.
These
then
go
for
that
too.
That
was
kind
of
where
I
was
where
I
was
going
on.
That.
F
Yeah
I
generally
agree.
My
only
concern
would
be
if
we
just
leave
things
unspecified,
then
we'll
go
do
different
things,
so
I
would
prefer
if
we
just
specify
them
ASAP
and
then
we're
on
the
same
page
on
how
they
should
work
because,
like
if
we
just
say
like
you,
can
do
cross
namespace
stuff
like
well.
What
does
that
mean
right?
Yeah,
I'm.
D
D
Yeah
and
I
completely
with
you
on
that
one
yeah,
the
specific
thing
and
I'll
go.
You
know
we'll
we'll
comment
on
the
PR,
but
the
specific
thing
with
namespaces
is
that
in
Linker
D
land
there
are
things
that
we
want
to
add
where
the
actually
things
that
we
already
have
in
place
for
some
of
this
stuff,
where
the
provider
of
a
service
should
be
able
to
specify
a
particular
set
of
policy,
but
the
consumer
might
actually
want
to
also
specify
a
more
restrictive
policy,
like
the
provider,
might
say
something
like.
D
Oh
it's,
okay,
if
you
do
a
10
second
timeout,
then
the
consumer
really
should
be
able
to
say
things
like.
Actually,
no
I
want
to
use
a
two
second
timeout,
because
that's
the
way,
my
clients,
that's
the
way,
I
roll
and
being
able
to
specify
those
with
things
in
multi
in
you
know,
with
a
route
in
the
provider's
namespace
and
also
my
route
in
the
consumer's
namespace
turns
out
to
work
really
well
for
us,
but
thank
you
for
the
pr
I
will
go.
Take
a
look
at
that
afterwards
and
off
we
go.
A
D
Behavior
and
I
should
also
point
out
that
Mike
I
think
the
scope
of
1426
was
pretty
much
spot
on
I
think
that
was
you
know.
That
was
what
needed
to
be
put
down
so
that
we
could
move
forward
with
it.
I
think
it
was
a
great
plan,
but
yeah
it
was.
It
was
very
interesting
to
sit
down
and
really
start.
You
know
start
digging
into
it
with
some
of
the
maintainers
and
kind
of
go
like
oh
yeah,
we're
gonna
we're
gonna
get
ourselves
into
trouble.
If
we
try
to
follow
this
exactly
I.
A
Think
that
we
would
probably
have
similar
concerns,
we
just
haven't
gotten
to
that
stuff
implementation.
Yet
so
yeah
definitely
appreciate
the
like
folks
that
are
starting
to
take
a
look
at
like
what
it's
gonna
take.
What
this
this
kind
of
feedback
is
great
and
definitely
like
yeah.
It
was
written
with
like
what's
the
most
conservative
small
thing
that
we
can
get
in
and
then
what
is
safe
to
remove
yeah.
D
In
general,
there's
stuff
going
on
in
Lincoln
right
now,
where
using
language
from
gamma
a
lot
of
linkerty's
history
is
focused
on
being
able
to
set
policy
and
take
action
at
the
provider's
side
of
what
happens
with
the
proxy
and
unsurprisingly,
people
want
to
be
able
to
take
action
at
the
consumer
side
as
well,
and
so
there's
a
lot
of
stuff
going
on
in
Lincoln
right
now
that
focuses
around
okay.
How
do
we
separate
these
two?
How
do
we
make
it
possible
for
people
to
configure
and
still
be
able
to
explain
it?
A
Yeah
I
I
think
that's
great
Alex.
It
sounds
like
Castillo
has
very
similar
concern
so
having
at
least
like
two
significant
implementations
that
may
have
like
different
implementation
details
and
concerns
both
working
in
on
this
problem.
I
think
we'll,
hopefully
get
us
to
a
good
place
where
it
should
be
broadly
implementable,
so
yeah
definitely
appreciate
y'all
I'll
take
a
close
look
at
it.
F
When
we
talked
about
it,
it
happens
every
time
so
like
do,
implement
it
or
some
version
of
it
or
look
at
it
closely,
but
don't
get
attached
because
you
or
someone
else
will
certainly
find
an
issue
and
will
have
to
change
it.
So
we're
kind
of
in
the
time
period
we're
like
all
hands
on
like
all
in
on
it,
but
be
willing
to
back
off
right.
G
Nobody
responded
to
the
discussion
so
I
guess
we
should
probably
talk
about
it.
A
little
bit,
I
was
kind
of
hoping
for
like
a
show
of
hands
which
it
seemed
like
there
were
plenty
of
thumbs
up
so
I.
Take
that
as
kind
of
a
show
of
hands
that
people
care
about
this
like
being
able
to
potentially
to
express
this
in
terms
of
like
Gateway,
API
or
rather
apis
within
Gateway
API,
but
the
idea
that
you
could
have
a
mesh
that
would
go
across
across
multiple
clusters,
like
I'm,
representing
Kuma.
G
Yeah
I'm,
aware
of
a
few
that
do
so
one
thing
I'm
stuck
on
is
you
know
how
that
looks
in
the
future,
like
some
kind
of
like
what
the
semantics
are
for
that
and
in
Kuma
we
are
interested
actually
we're
interested
in
having
a
mesh
resource,
full
disclosure.
We
are
interested
in
having
a
mesh
resource
and
we
would
be
interested
in
being
able
to
somehow
attach
to
or
decorate
that
mesh
resource
in
a
way
that
you
could
say
this
needs
to
be
a
part
of
this
mesh
which
goes
across
clusters
and
curious.
D
G
G
Are
other
reasons
we
already
have
a
mesh
resource
and
one
of
the
things
that
we're
looking
at
potentially
wanting
to
do,
which
plays
in
with
what
Gateway
API
has
already
provided
for
Ingress,
is
using
a
mesh
resource
potentially
in
Gateway
that
you
can
then
post
and
then
receive
an
actual
deployment
of
a
mesh.
It
doesn't
have
the
same
impact
as
Gateway,
because
in
Gateway
you
may
want
to
create
multiple
gateways
and
in
mesh.
G
Creating
multiple
meshes
is
something
that
I
think
we'll
have
to
deal
with
in
time,
but
it
doesn't
have
the
same
there's
not
as
much
of
that
in
mesh
land
you're
not
going
to
have
as
many
clusters
with
multiple
meshes
to
put
on
them.
That
said,
the
way
we're
headed
right
now
we're
kind
of
almost
avoiding
multiple
message
mesh
with
some
of
the
direction
that
we're
headed
with,
like
the
prototypical
stuff
that
we're
we
even
just
talked
about
like
the
HTTP
route,
stuff
and
I.
Think
that
probably
isn't
something
that
we
should
do.
G
I
think
we
should
basically
try
to
create
a
isolation
around
meshes
instead
of
having
it
be
like
HTTP
route
attaches
to
a
service.
Every
mesh
is
going
to
now.
You
know
pick
on
pick
up
on
that
and
implement
it.
I
really
like
the
semantics
of
saying
this
needs
to
be
attached
to
this
map.
This
mesh
needs
to
serve
this
something
semantically
there
and
then
it
kind
of
that's
that's
like
totally
overloading
the
original
point,
but
also
when
you
want
to
have
a
master
join
another
mesh.
G
Another
cluster,
the
mesh
resource,
be
at
the
center
of
that
say
something
like
here's
an
attachment
to
a
mesh
in
another
kubernetes
cluster
or
something
like
that
attachment
might
not
be
the
right
word,
I'm
sure,
I'll
say
the
word
that
everybody
hates
over
and
over
again
join.
Attach
everybody
will
hate
every
word,
but
that's
the
that's.
The
idea,
if.
D
D
A
G
A
Enough
yeah,
so
I
think
there's
a
lot
of
like
prior
art
in
the
space
of
like
folks
that
have
tried
previous
variations
of
multi-cluster.
Things,
including,
like
pharmaceutive
console,
has
supported
multiple
clusters
within
a
single
console
deployment
in
one
way,
and
now
we're
exploring
a
different
path
forward
for
that
I
think,
like
Cube
feds
like
another
example
of
a
specific
model
that
was
tried
for
something
yeah
yeah.
D
A
D
H
A
A
G
G
E
Yeah,
maybe
I
can
give
the
example
how
we
you
know.
We
have
a
one,
a
POC
today
AWS,
so
we
use
Gateway.
You
know
you
can
interpret
Gateway
as
a
mesh,
so
you
define
a
Gateway
or
Define
a
match
object
if
we
have
op
mesh
object
available.
The
next
thing
when
we
do
is
on
each
cluster.
You
specify
you
know
the
HTTP
route.
You
just
say
you
want
to
attach
to
which
Gateway
so
Gateway
of
mesh
is
Spam,
multiple
cluster,
which
means
there's
no
kubernetes
cluster
boundary.
E
We
need
every
HTTP
route,
every
part
concealed
that
you
are
within
the
map,
but
you
cannot
access.
The
only
way
you
can
access
is
through
policies.
Just
like
you
know
anything
on
AWS.
You
can
see
S3
bucket,
but
you
won't
be
able
to
see
the
each
other's
bucket.
You
know
right,
so
that's
how
we
treat
it.
So
you
can
Define
multiple
cluster
attached
to
the
same
Gateway,
the
Gateway.
A
D
I
think
Daniel's
question
in
chat
is
interesting.
Are
we
still
talking
about
multi-cluster
or
an
install
mechanism,
and
the
problem
here
is
or
a
problem
here-
is
that
yeah
some
of
those
operations
blur
that
distinction
in
some
ways,
because
the
multi-cluster
thing
might
be
another
operation,
but
I
also
think
that
Keith
has
been
waiting
very
patiently
and
yes,
perhaps
Keys
should
talk
or
maybe
he's
been
waiting
impatiently
but
quietly
I.
Don't
really
know.
I
No,
no,
it's
it's
good
I
think
we
have
kind
of
you
know.
Initially,
multi-cluster
and
mesh
enablement
and
stall
mechanisms
were
explicitly
cut
from
scope
from
what
gamma
was
trying
to
do.
When
we
did
our
I
forget
the
get
number,
but
our
first
Gap
that
we
did
with
our
goals
and
things
of
that
nature
didn't
you
know,
didn't
have
anything
to
do
with
multi-cluster.
I
The
I
think
we
one
thing
on
top
of
my
mind,
is
you
know
we
start
talking
about
installing
a
mesh
or
adding
a
another
cluster
to
a
mesh?
We
start
remove.
We
start
blurring
a
line
I
think
between
where
Gateway
API
is
I.
Think
for
the
for
the
most
part,
talking
about
routing
and
such
and
I,
don't
know
how
I
feel
yet
about
that
being
a
part
of
Gateway
about
that
being
a
part
of
gamma.
G
I
G
Will
like
create
a
load
balancer
for
you
if
you
create
a
Gateway
underneath
the
hood,
so
that's
outside
the
cluster
but
same
concept,
so
the
operational
component
of
Gateway
API
is
an
intentional
one.
The
the
intention
that
the
resource
like
Gateway
is
for
operators
to
like
set
up
the
things
that
then
under
the
hood,
the
developers
or
people
that
aren't
operators
ultimately
are
then
setting
up
the
routes
to
that
is
an
intentional
distinction,
one
that
I
would
like
to
see
in
the
mesh
side
of
things.
I
So
I
need
to
double
check
my
understanding
on
that,
but
to
kind
of
go
back
to
the
multi-cluster
piece,
I
I
think
I
tend
to
agree
with
what
others
are
saying
in
chat
where,
like
installing
the
control
plane
should
not
be
a
part
of
the
spec,
but
to
go
to
the
multi-cluster
conversation.
I
do
want
to
Echo
what
Mike
was
has
been
said
earlier
that
we
need
to
be
very
specific
about
what
what
these
operations
are,
because,
as
we've
seen,
it
can
turn
very
quickly
into
oh
I
want
to
make
this.
I
D
G
I'm,
actually,
okay,
with
the
idea
that
it
doesn't
need
to
beat
into
that.
It
almost
sounds
like
at
least
the
first
reaction.
Is,
we
probably
don't
have
a
general
way?
Basically,
Gateway
API
is
trying
to
find
the
union
of
like
programming
these
things
right
like
like,
describing
these
things
between
all
implementations.
If
every
implementation
in
this
room
is
like
I,
don't
really
feel
like
I
could
describe
that
in
the
same
way
as
you,
then
we
shouldn't
do
it.
D
D
Okay,
go
ahead,
on
the
other
hand,
the
operation
of,
if
you
have
cluster
a
and
cluster
B-
and
you
know
that
both
of
them
are
running,
you
know
already
have
a
control
plane
installed.
The
operation
of
linking
those
two
together
into
a
multi-cluster
thing
feels
like
something
that
could
be
in
scope
Maybe
not
today,
but
that
that
does
not
feel
miscoped
to
me.
That
feels
like
an
operation
that
makes
sense
in
a
fair
amount
of
fair
amount
of
ways.
D
G
G
D
D
D
I
I
believe
yeah.
We
talked
about
a
little
bit
here
at
the
beginning
and
having
a
mesh
resource
be
the
center
point
of
that.
In
my
experience
you
know
osm
we're
working
on
like
an
MCS
API
and
most
MCS.
You
know
controllers
whether
it's
your
cloud
provider
or
Submariner
or
carmada,
there's
typically
like
an
imperative
step
that
needs
to
happen
in
order
to
do
a
join,
maybe
there's
Secrets
being
in
exchange
between
the
two
clusters
and
that
that
experience
feels
like
it
could
be
smoother.
I
You
yeah
should
not
yeah
my
opinion
is
not
social
justification.
I
think
that
their
routing
should
stay
the
main
justification
for
apis
and
Gateway
API,
but
I
do
think
that
there
is
I
agree
with
the
point
that
you
made
earlier
Shane
that
there's
just
something
semantically
crisper
about
having
a
HTTP
route
be
bound
to
this
service
with
any
particular
mesh.
I.
Think
that
that
feels
clean.
I
I
F
I'm
just
gonna
say
it
like
it's.
It's
tough,
because
I
think
this
whole,
like
connecting
multiple
clusters
thing,
is
a
real
problem
that
a
lot
of
things
have
not
just
mesh
right,
but
I
would
caution
that
I
think
it's
a
very
hard
problem.
That
is
the
type
of
thing
that
it's
like
getting
consensus,
not
just
with
people
in
this
group,
but
then
also
like
all
the
multi-cluster
efforts,
potentially
in
kubernetes,
which
is
just
like
a
massive
uphill
battle.
G
Yeah,
fair
I
think
the
I
think
it's
a
hard
problem
to
solve,
to
implement,
but
I'm
becoming
more
and
more
convinced
and
as
I'm
focused
more
on
the
operational
side
of
mesh
and
like
how
that
relates
to
gamma
and
Gateway
API.
And
why
I'm,
even
talking
about
the
stuff
like
how
operations
would
work
with
potentially
an
API
that
all
of
us
implement,
it
seems
like
it
seems
like
the
workflow
of
like
Jane,
the
developer
or
Jane.
The
operator
flynna
like
that
deploys.
G
The
developer
Julia
we'll
start
with
Julie
the
operator
deploys
a
mesh
under
the
onto
her
kubernetes
cluster
on
these
namespaces.
That
is
something
semantically,
I
think
all
of
us
can
do
and
like
that's
easily
describable
in
human
words,
maybe
that's
something
that
we
should
be
able
to
describe
in
gamma
apis
and
then,
additionally,
once
you
have
a
mesh-
and
that
is
a
thing
for
Julia
the
operator
potentially
like
that
semantically
makes
sense
to
Julie
the
operator.
G
I
have
a
Kuma
mesh
and
I
have
an
istio
mesh
and
I
have
a
go
on
so
on
and
so
forth,
be
able
to
say,
I
need
to
attach
this
mesh
to
one
in
another
cluster
I
think
semantically
that
could
be
made
very
simple
to
describe.
The
implementation
is
potentially
horrendous,
but
but
the
the
basic
description,
the
union,
where
every
every
mesh
can
do
this
or
most
meshes,
can
do
this.
Maybe
it
would
be
extended,
I
think
it's
there
I
think
the
the
we're
not.
G
A
B
A
A
A
Some
projects,
like
MCS
API,
have
like
very
explicit
statements
around
like
what
equivalencies
are
expected
across
clusters
and
how
those
should
be
enforced.
You
also
end
up
with,
like
a
do.
You
have
a
single
primary
cluster
where
stuff
is
applied
or,
and
then
like,
dependent
or
secondary
clusters
versus
like
two
independent
clusters
that
expose
services
to
each
other
through
some
other
connection
method.
So.
H
B
G
Yeah
cool,
it's
it's
it's
about
this
separation,
so
that
Jane
and
Julia
do
not
or
Julian
do
not
have
to
worry
about
this.
From
implementation
to
implementation.
Julian
is
used
to
the
idea
of
I
go
I
have
I,
have
Kuma
I've
deployed
a
mesh
I've
linked
it
to
a
did,
I
say
kumakuma
elsewhere,
like
I,
think
I
I
think
I
understood
what
Mike
just
said
I
to
me.
It's
it's!
G
Maybe
maybe
just
let
me
rephrase
what
I
heard
Mike
just
so
that
you're
you're
concerned
that
okay,
we
can
describe
that
in
English,
something
that
works
between
different
implementations
and
I
suggested
that
it
means
it's
mostly
just
an
implementation
details
problem
right,
you're,
suggesting
that
no,
the
there's
no
way
for
all
of
these
implementations
to
fully
automate
from
a
basic
like
a
general
like
from
the
union
of
instructions.
We
can't
all
fully
automate
that,
because
the
there's
too
many
complexities
and
too
many
differences
and
implementations,
is
that
what
you
were
saying.
A
G
A
A
D
H
H
You
know
how
do
I
talk
to
this
service
and
that's
why,
in
the
chat,
I
I
said,
I
prefer
something
like
a
trust
domain
resource,
because
what
from
what
I
can
tell
the?
What
really
is
one
of
the
defining
features
of
service
measures?
Is
the
encryption
right
and
the
the
encryption
context.
So
you
need
to
know
a
few
bits
in
order
to
talk
to
a
service
that
is
in
a
service
mesh
right,
you
might
have
to
go
to
through
a
specific
Gateway.
H
You
might
have
to
trust
a
specific
certificate
or
a
root
certificate,
and
that's
sort
of
that's
something
that
I
would
see
as
maybe
interesting
for
for
Gateway
API,
to
establish
these
sorts
of
interactions
between
different
vendors,
because
I'm
not
sure.
If
standardizing
on
things
like
you
know
how
do
we
span
or
mesh
across
multiple
clusters?
H
G
That
being
able
to
find
the
union
of
like
working
on
the
operational
side
of
thing
is
something
that
I'd
like
to
see
happen
in
gamma
Keith
I'd
like
to
specifically
ask
you
about
this,
because
you
seemed
I
think
most
what
I
got
from
most
people
I
think
in
this
conversation.
So
far
most
people
were
like.
Maybe
maybe
we
could
talk
about
like
doing
Ops
kind
of
stuff.
G
You
really
don't
want
to
have
to
deal
with
Ops
in
this
API,
something
that
you
can
like
that
users
can
bring
from
mesh
to
mesh
and,
like
I,
know
how
to
do
these
operations
because
they
all
Implement
gamma
and
it
all
so
they
all
do
these
operations
with
the
same
API
is
that
accurate
did
I
miss
you're
muted.
Just
so,
you
know.
I
Yeah
I'm
sorry
I,
wasn't
saying
anything.
I
was
just
thinking,
I,
think
for
me,
it's
not
as
strong
as
I
don't
want
to,
but
I've
got
a
pretty
big
hesitation
towards
doing
Ops
in
the
API,
because
I
mean
part
part
of
it
comes
from
SMI
experience
and
the
experience
trying
to
kind
of
codify
traffic
metrics
yeah.
So
we
tried
to
do
traffic
metrics,
which
was
somewhat
opsy,
standardize.
I
Most
of
the
hesitation,
I
guess,
comes
from
kind
of
my
my
vision
for
ServiceMaster
Technology
Long,
like
long
term
and
how
I
see
customers
wanting
service
meshes
to
to
be
usable.
The
short
version
of
that
is
I
think
there's
still
a
ways
to
go
on
on
some
of
that
and
I'm
I'm
wary
of
attempting
to
standardize
too
early
because
I
don't
think.
We've
seen
the
end
of
of
operations
for
service
mesh
and
I
worry
that
too
much
standard.
I
I
But
at
this
juncture
with
how
with
how
young
gamma
is
relatively
and
with
the
variety
of
ways
that
there
are
to
join
a
mesh,
I
think
that
you
know
istio's,
Ambience
I
think
that's
still
somewhat
of
an
open
question,
Lynn
or
John,
or
someone
can
correct
me
and
tell
me
I'm
wrong,
but
yeah
I
I,
don't
feel
it's
not
that
I
don't
feel
the
need
yet
I
feel
I.
I.
I
Think
I
rather
thought
the
community
might
be
better
served
by
enduring
the
pain
a
bit
longer
so
that
that
pain
might
produce
more
Innovation.
I,
don't
know,
that's
very
future.
Looking
and
I
am
happy
to
be
proven
wrong,
like
I.
Don't
want
to
to
block
this
if
we
have
sufficient.
If
enough
people
feel
like
that's
something
they
want
to,
they
want
to
work
on
that.
We
need
it
now,
but
yeah
that
that's
kind
of
my
plb
on
it
I.
G
G
Period
like
because
we
have
limited
time,
we
want
to
get
something
that
works,
and
we
need
to
have
that
forward.
Momentum,
I'm,
coming
from
a
perspective,
slightly
different,
where
it's
like
I'm
a
little
worried
that
we're.
If
we
put
too
much
momentum
in
that
direction,
we
will
miss
the
opportunities
for
something
that
we
we
have
in
Gateway
API
today.
Like
one
thing,
that's
a
little
I,
don't
know!
Maybe
it's
not
odd,
but
just
did
anybody
have
their
hand
up
by
the
way.
I
don't
want
to
take
the
mic
too
long.
G
It's
just
one
thing:
that's
kind
of
interesting
is
like
seeing
Kuma
deployed
and
then
ultimately
seeing
us
create
a
Gateway.
So
kubernetes
has
an
API
Gateway
that
we
can
create
to
create
an
Ingress
Gateway
it'll,
create
an
Envoy
proxy
it'll,
come
up
and
then
it'll
allow
you
to
get
Ingress
traffic
into
the
into
the
mesh,
but
not
have
anything
similar
for
like
the
mesh
to
do
those
kinds
of
Ops
on
the
mesh
like
just
for
the
game.
G
Just
for
that
one
piece
right:
you
can
do
that
kind
of
like
have
an
API
that
describes
like
operational
things
that
you
want
to
have
done
to
supplement
the
mesh,
and
so
it's
not
the
end
of
the
world
or
anything.
But
that's
that's
today
and
it
just
I'd
love
for
users
to
be
in
a
place
tomorrow,
where
you
know,
I
have
gone.
I've
gone
from
all
these
different
I
have
tried
all
the
different
implementations
of
mesh.
G
Let's
just
say
you
know
istio
and
Kuma,
and
you
know,
let's
just
let's
just
go
with
that
for
now,
just
because
that's
what's
in
my
head,
but
like
I've
tried
both
of
these
and
at
least
to
get
started
and
to
like
do
the
basics.
It
works
the
exact
same
way.
For
me,
that's
the
promise
of
kubernetes
right,
that's
what
the
kubernetes
API
is
trying
to
promise
at
the
end
of
the
day
is
that
you
don't
have
to
learn.
You'll
eventually
have
to
learn
it.
G
As
you
dig
deep
you'll
always
have
to
get
into
the
nitty-gritty.
There
will
always
be
a
Gateway
configuration
that
you'll
have
to
potentially
plant
on
top
of
a
Gateway
resource.
That's
only
for
this
type
of
thing
and
you
get
into
like
crds,
but
the
the
general
starting
out
experience
that
we
can
all
do
the
same
thing
everywhere.
G
I
I
think
that's
a
really
good
point,
and
it's
it's
one
that
I
absolutely
sympathize
with.
You
know,
I,
think
that
these
points
in
time
and
the
history
and
evolution
of
software
are
very
important
and,
like
I,
think
this
is
absolutely
appropriate
time
to
be
figuring
out.
Okay.
What
are
we
going
to
miss
if
we
don't
have
this
conversation
right
now,
I.
I
I
That's
part
of
the
the
reason
why
there's
so
much
excitement
behind
it,
because
the
users
are
wanting
standardization,
but
I'm
also
hesitant
to
start
codifying
something
like
when
you,
when
you
start
when
you
see
a
mesh
resource
in
a
DOT
KH
dot
io
on
the
group
that
that
means
something
and
I,
don't
know
that
that's
the
spot
for
the
the
standardization
that
you're
looking
for
for
the
specification
that
that
we're
looking
for
does
that
make
sense.
Yep.
G
This
conversation,
I
I,
hope
every
I
hope
people
don't
feel
completely
opposite
for
me
has
been
very
good
I,
don't
think!
I
have
much
more
to
bring
to
this
conversation,
except
that
I
need
to
take
this
and
take
some
time
and
think
about
this,
some
more
and
then
come
back
with
the
next
iteration
personally.
A
Yeah
I
think
there's
kind
of
like
what
Keith
was
alluded
to
if,
like
there's
a
lot
of
innovation
that
is
currently
happening
in
this
space,
where
people
have
looked
at
what
was
tried
in
the
past
couple
years,
figured
out
kind
of
like
what
worked
well
from
that.
What
didn't
work
well
and
are
like
currently
exploring
that,
like
next
iteration
and
I,
don't
necessarily
think
that
we
Nest
we
might
have
space
right
now
to
like
build
a
thing
that
exists.
G
H
D
Cool
I
think
I
should
probably
point
out
that
I
am
not
I'm,
not
opposed
to
the
idea
of
having
something
that
makes
declarative
Ops
simpler,
I
would
like
for
it
to
be
easier
to
be
conformants
without
I.
I
would
like
it
to
be
simpler
to
have
an
implementation.
That's
conformant!
Without
doing
that,
you
know
I'm
not
going
to
say
that
I
think
we
should
get
rid
of
it
entirely.
Does
that
make
sense.
D
There
are,
there
are
organizations
in
the
world
that
have
not
yet
brought
their
their
operations
up
into
the
fully
declarative
model
and
closing
those
organizations
out
from
being
able
to
use
a
conformant
implementation.
Bothers
me,
I
think
that
that
is
less
of
a
concern
in
2022
than
it
was
in
2017.
2018
right
people
are
right,
are
certainly
more
accustomed
to
the
whole,
get
Ops,
declarative,
buzzword,
fully,
buzzword,
compliant
things
fully.
D
G
D
It
but
yeah
there
are,
you
know
you
backing
up
to
my
four-person
startup
thing.
You
know
where
yeah
it.
It
would
be
a
good
thing
to
be
able
to
allow
people
to
go
through
and
quickly
spin
up
something
try
it
do
it
for
experiments.
Do
it
for
point,
you
know
for
proof
of
concept,
Etc
without
being
forced
to
go
in,
and
oh
I
got
to
do
a
proof
of
concept.
Let
me
hook
everything
into
my
Argo
workflow,
first
or
whatever
right.
You.
G
G
Absolutely
be
like
we
want
to
set
the
standard
you
need
to
come
meet
this
standard.
You
know
in
the
real
world,
there's
a
really
delicate,
Balancing
Act,
where
you
do
a
little
bit
of
that
yeah.
You
can't
do
too
much,
or
else
people
won't
adopt
the
the
the
new
standard.
They
won't
make
it
a
standard.
It
will
become
defunct.
So
yeah,
that's
that's
The,
Balancing
Act,
we're
like
just
on
the
edge
of
right
now
we're
on
a
knife's
edge
with
and.
A
Well,
I
guess
at
that
I'm
gonna
try
to
tie
off
this
conversation
and
we
have
a
couple
minutes
left.
I
know
this
was
a
handful
of
new
folks
on
the
call.
If
anybody
who
has
not
introduced
himself
before
wants
to
take
a
moment
to
introduce
themselves
to
the
group,
let's
do
that
in
the
last
couple
minutes
we
have
before
we
try
this
often.
C
Hi
I'm
David
lenrow
from
lumio
and
just
dropping
in
to
understand.
What's
going
on
here,
we
have
sort
of
a
proprietary
service
mesh
for
bare
metal
and
virtual
machines,
and
you
know
would
like
to
interface
with
kubernetes
systems
in
general,
and
we've
been
looking
at
problems
with
having
to
do
it
for
15
different
service
mesh
implementations
and
would
love
to
find
out
that
this
is
the
solution
and
that
you
know
I
can
help
us
get
it
right
in
some
way.
B
B
D
G
B
H
I
guess
I
should
introduce
myself
my
first
time
here,
I'm
Daniel
from
Red
Hat,
and
we
build
openshift
service
mesh,
which
is
basically
istio,
plus
a
few
plus
a
few
bits
here
and
there
we
do.
Multi-Tenancy
is
one
of
the
things
that
we
add.
We
also
have
our
own
multi-cluster
thing,
which
is
called
Federation
which,
where
you
have
multiple
trust
domains.
H
G
I
Question
quick
question:
as
we
get
like
30
seconds,
is
the
new
people
want
to
comment
on
this
time
slot?
So
we
alternate
time
slots
for
the
gamma
meetings.
Does
this
times?
Do
you
find
this
time
slot
useful?
Would
you
prefer
the
one
at
I
think
3
P.M
Pacific
time?
Would
you
be
able
to
we're
trying
to
get
some
feedback
on
how
the
how
the
alternating
time
slots
are
helpful.