►
From YouTube: Gateway API Meeting (APAC Friendly Time) 20210217
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
We
are
recording
all
right
welcome
to
gateway
api
meeting
for
february
17..
We
have
got
a
lot
of
interesting
content,
I'm
looking
forward
to
seeing
it
looks
like
both
how
istio
is
planning
on
using
these
apis
and
contour
as
well,
really
interested
in
seeing
the
different
approaches
here,
but
before
we
get
into
that,
I
wanted
to
highlight
release
big
thanks
to
harry
for
getting
this
out.
A
We
have
finally
made
it
to
0.2.0.
This
is
the
first
time
that
we've
made
a
release,
an
incremental
release
after
our
v1
alpha
1
release.
This
continues
to
use
the
v1
alpha
1
api
version,
but
it
represents
a
point
in
time
set
of
incremental
updates
that
will
be
easier
to
reference.
Everything
is
entirely
backwards
compatible.
This
is
entirely
additive
or
bug
fixes,
or
these
kinds
of
things
there.
There
is
a
change
log
here
that
should
provide
more
information
yeah.
A
A
So
this
provides
a
little
bit
more
stability.
I
think
we
had
contributions
from
just
about
everyone
to
get
this
release
out.
So
thank
you.
I
feel
pretty
good
about
it.
Any
questions
about
this
release
strategy.
I
know
it's
a
a
little
bit
strange
to
have
both
this
semantic
versioning
and
api
versioning
and
have
them
be
a
little
bit
different
does.
Does
this
make.
A
Sense
silence
is
great
all
right.
Let
me
see
this
is
the
the
test
of
all
the
things
it
looks
promising.
All
right,
I
can
see
slides.
Let
me
hopefully
everyone
else
can
too.
Let
me
see
what
happens
if
I
present
this
okay
did
that
break
everyone's
view
of
my
screen.
A
A
Oh
okay,
all
right!
Well
we're
just
going
to
do
somewhat
larger
there.
We
go
okay,
we'll
run
with
this
john
I'll
I'll
hand
it
over
to
you,
and
just
let
me
know
when
you
want
to
move
on
to
the
next
slide
yeah.
We
still
can't
see.
A
B
If
we
can't
share
it,
it's
probably
fine.
Most
of
the
slides
are
about.
I
yeah
I
made
them
for
unrelated
purposes
and
kind
of
shoehorned
the
side,
cars
or
a
service
mesh
stuff
in
it.
So
we
can
just
talk.
A
We'll
try
one
more
time.
Are
you
seeing
anything
when
I
share
this
black
wow?
How
so
when
I,
when
I
went
to
present
okay,
that's
fine,
okay,
yeah,
I'm
not
gonna
question
it.
We
can
look
at
the
slides
individually,
then,
and.
A
B
Okay,
yeah
I'll
just
get
started,
then
so
yeah
so
quick
background.
I
I
work
on
east
geo
and
in
easter
we
have
both
an
ingress
and
a
service
mesh
using
the
same
apis
which
are,
if
you're
not
familiar,
there's
a
gateway
api
which
is
loosely
related
to
the
gateway
api
here
and
the
virtual
service
api,
which
is
kind
of
like
the
routes.
B
So
they
have
a
similar
model
somewhat,
and
so,
as
we've
been
implementing
the
service,
apis
we've
been
looking
into
whether
we
can
or
how,
how
or
whether
it's
possible
to
represent
service
mesh
traffic
using
these
apis
as
well,
because
today,
an
easter
user.
They
have
one
api
that
controls
both
ingress
and
mesh,
and
so
if
we
are
to
push
users
to
use
the
the
new
gateway
apis.
B
So
we've
been
looking
into
this
a
bit
and
I
don't
have
any
concrete
designs
here
yet
I
just
want
to
get
some
early
feedback
and
I
was
also
curious
about
others.
I
know
like
kong
and
traffic
both
have
sibling
mesh
projects,
so
I
was
wondering
if
any
of
those
have
thought
of
this
as
well.
B
Here
we
go
yeah,
you
can
skip
all
the
stuff
unless
you
want
an
intro
to
the
api
and
go
down
to
like
slide
15,
I
think
15.,
all
right,
maybe
14,
actually
sure
yeah.
So
basically,
the
idea
of
the
service
mesh
is
it's
actually
very
similar
to
ingress
in
many
ways
like
we
still
have
some
proxy,
that's
in
between
the
client
and
server
and
it's
still
doing
all
the
same
type
of
stuff,
but
generally
the
ingress
case.
B
There's
one
gateway
and
you
go
from
you
know
the
client,
which
is
generally
external
to
the
cluster,
to
some
gateway,
which
does
all
the
routing
load,
balancing,
tls,
et
cetera,
and
then
it
forces
some
back
end
in
the
mesh
case.
It's
much
more
common
to
have
client
in
the
cluster,
and
then
we
go
through
two
hops
of
proxies,
one
attached
to
the
client
and
one
attached
to
the
server
before
we
reach
the
other
destination,
but
ultimately
they're
doing
very
similar
things,
and
so
we've.
B
You
know,
because
that
we
thought
that
we
could
represent
these
with
the
same
api
potentially.
So
if
you
have
the
next
slide
in
east
geo
today,
we
have
this
virtual
service
definition
right,
and
so,
if
you
wanted
to
find
something
at
an
ingress,
you
would
specify
in
the
gateways.
This
is
like
the
ingress
gateway
and
say
our
host.
Is
you
know
our
external
domain
like
helloworld.example.com
and
then
for
internal
traffic?
B
You
just
change
the
gateway
name
and
probably
also
the
host
name
as
well
to
define
here's
what
happens
when
I
send
a
request
to
the
hello
world
service
in
the
default
namespace
and
then
all
the
configuration
is
the
same.
So
that's
just
some
background
on
how
it
works
in
istio.
I
think
the
main
challenge
is,
if
you
go
to
the
next
slide,
that
we
are
trying
to
overcome
in
getting
mesh
traffic
modeled
with
the
gateway.
Api
is
first,
there's
a
lot
more
gateways
to
manage
so
or
more
specifically,
there's
more
proxies
to
manage.
B
The
answer
there
is
not
clear
to
me
yet,
but
there's
certainly
more
things
to
manage,
whereas
in
an
ingress
case
you
typically
have
maybe
one
ingress
pod
running
or
maybe
a
few
here,
we're
talking,
you
know,
potentially
thousands
and
so
how
we
interact
with
things
is
potentially
different,
because
if
we
had
to
make
a
thousand
getaway
classes
a
thousand
gateways,
you
know
things
can
get
kind
of
out
of
hand
there
for
the
user.
B
The
other
one
is
that
we
have
this
notion
of
consumer
and
producer
and
overrides,
which
is
a
lot
more
important
generally
on
ingress.
You
just
have
like
your.
If
I'm
the
hello
world
developer,
I
set
up
my
rules
for
how
to
reach
hello
world.
I
set
up
the
gateway
on
how
to
expose
it
and
everything's
done
by
by
myself,
because
the
clients
are
generally
external
and
they
can't
configure
anything
but
inside
the
mesh
we
have.
B
B
So
if
I'm
the
hello
world
service,
I
may
define
that
I
use
the
round
robin
load
balancing
policy,
but
another
client
doesn't
have
to
listen
to
that
right,
they're,
free
to
use
their
own
load
balancing
policy,
and
we
allow
them
to
actually
override
settings
on
the
server
side.
So
today,
that's
not
exactly
clear
how
that
will
be
modeled
by
the
gateway
api
and
the
other
one
is
that
ingress
is.
Is
opt-in
like
if
you
just
set
up
an
empty
ingress
controller
in
all
implementations?
B
I
know
it
will
do
just
return,
nothing
or
404s
for
everything
for
mesh.
We
generally
have
it
just
drop
in
place
and
transparently
proxy
everything,
and
so
we
implicitly
have
routes
to
all
services
in
the
mesh.
So
we
also
need
to
have
some
way
to
represent
this
implicit
behavior
in
the
gateway,
because
or
in
the
gateway
apis.
B
Since
again,
we
don't
want
people
to
have
to
define
a
thousand
routes
like
in
order
to
onboard
their
their
applications
into
the
mesh
we
want
it
to
just
be.
You
know,
checks,
unbox,
somewhere
or
install
some
configuration
knob,
and
then
they
get
their
sidecar
proxy,
which
they
can
then
incrementally
add
more
and
more
features,
but
everything
continues
working
out
of
the
box.
B
So
that's
the
main
things.
I've
we've
come
across,
I'm
starting
to
think
about
this
a
bit
on
how
we
can
model
these.
I
don't
have
anything
concrete
to
like
design
review
right
now,
but
hopefully
in
the
near
future.
We
will
so
I
was,
I
guess,
wondering
if
anyone
has
any
questions
feedback
on
this.
If
anyone
else
is
thinking
about
this
problem
or
anything.
A
This
is
a
relatively
small
question
in
the
grand
scheme
of
things
here,
but
this
is
just
another
reminder
that
of
course,
istio
has
a
gateway
resource
that
is
not
the
same
as
the
gateway
api
gateway
resource.
I
I
I
know
that's
going
to
be
confusing
for
users.
Have
you
thought
about
like?
I
can't
remember
where
we
landed
on
that
it
sounded
like
there
would
be
a
different
way.
You
had
a
different
short
name
or
something
for
istio
gateways.
B
Yeah
we
do
have
a
different
short
name
for
now.
We
also
like
in
our
documentation.
We
always
refer
to
it
as
the
kubernetes
gateway
api
and
then
anywhere
we're
talking
about
them
together.
We
also
refer
to
ours
as
like
the
easter
gateway,
we
may
need
like
a
better
one.
That's
like
a
different
color
on
the
website
or
something
I
don't
know,
because
it
is
very
confusing,
but
I
don't
know
we'll
we'll
find
a
way
yeah.
That
makes
sense.
A
B
Yeah,
like
the
left
side,
we
do
have
experiment
experimental
support.
The
right
side,
I
mean
technically
it
works
because
of
the
implicit
behavior
I
mentioned,
but
you
can't
actually
configure
anything
so,
okay,
yeah.
A
Questions
asking
in
chat:
if
there
are
any
areas
api
could
focus
on
for
side,
car
use
cases.
I
don't
know
john.
You
probably
have
some
perspective
here.
B
Yeah,
I
think
so
right
now.
I
I
don't
think
we
have
a
clear
idea
of
exactly
how
we
want,
like
the
api
resources
to
map
to
like
the
physical
proxy
resources
and
how,
like
things
are
set
up.
B
I
don't
really
know,
but
I
think
that's
really
the
first,
the
first
step
and
then
hopefully
like,
ideally,
some
of
the
other
meshes
out
there
would
would
also
be
involved
in
this
because
I
don't
want
like
if
we
do
what
I
described
as
a
creative
representation
of
the
api,
where,
like
you
know,
a
special
annotation
or
something
even
more
implicit
means
like
mesh
or
something,
then
that's
not.
It
loses
a
lot
of
the
benefits
of
portability
right.
B
B
I
think
that
east
geo
in
general,
compared
to
other
measures,
there's
nothing
that
unique
about
it
in
terms
of
this
problem,
I
think
that
the
biggest
thing
is
more,
that
we
have
a
deeper
integration
with
mesh
and
ingress
together
in
the
same
api,
whereas
others
either
have
a
different
ingress
implementation
or
different
apis
from
what
I've
seen.
I
could
be
wrong
there,
but
fundamentally
that
I
guess
that's.
I
suppose
that
would
change
if
everyone
adopts
the
gateway
apis.
B
A
Yeah,
this
is
really
interesting.
Definitely
you
know
we've
covered
a
lot
for
ingress.
I
think
that's
still
primarily
what
we're
aiming
for,
but
this
is
interesting
because
there
there
is
a
lot
of
overlap
here
so
interesting
to
see
what
you
find
and
if
any
other
projects
have
been
thinking
of
these
apis.
The
same
way
is
well,
we
can
do
ingress,
but
we
could
also
do
more
because
yeah
interesting,
okay
yeah.
I
guess
any
any
other
questions
I
missed
yeah
I'll
I'll
leave
it
there.
Then
I.
A
Danian
or
steve,
do
you
want
to
go
through
contour
and
what
what
you're
working
on.
C
C
Guess
I
should
have
tried
the
screen
sharing
before.
Why
isn't
my
mac,
letting
me
share
my
screen.
C
Here
it
is
okay
hold
on
one.
Second,
I
think
I
got
it.
A
No
worries-
and
I
don't
mind
if,
if
my
screen
share
works
again,
I
don't
mind
running
through
docs
too,
whatever
whatever's
easiest
for
you.
C
Oh,
I
have
to
looks
like
I
have
to
quit
and
reopen
to
allow
screen
sharing
for
my
mac.
Let
me
do
that
and
bounce
right
back
here.
Cool
sounds
good.
C
C
Worst,
oh,
my
gosh,
you
gotta
be
kidding
me.
Let
me
clean
this
up.
Okay,
I
think
I'm
in
a
place
where
I
can
start
to
have
a
conversation
with
everyone.
Thanks
for
your
patience,
so
I
think
the
first
thing
you'll
see
here
is
the
gateway.
Api's
implementation
actually
spans
across
two
components:
the
primary
component
contour,
as
well
as
a
new
component
called
contour
operator
and
feel
free
to
click
on
either
of
these
designs.
C
C
An
envoy
damon
set
all
the
other
child
resources
that
are
necessary
for
instantiating,
a
contour
environment
like
the
config
map
that
contour
uses
to
configure
itself
secrets
to
secure
the
communication
between
these
two
and
for
those
that
are
unfamiliar
with
contour.
Just
think
of
you
know,
contour
is
a
a
control
plane
for
envoy
and
contour
supports
and
implements
apis,
such
as
the
ingress
api,
there's
also
a
custom
resource,
http
http
proxy,
that
contour
supports
and
it
newly
supports
the
gateway
apis.
C
But
again,
as
I
mentioned
going
back
here,
it's
not
going
to
support
all
the
gateway
apis.
It's
really
meant
to
be
a
layer,
7
component
or
a
layer.
7
implementation,
and
so
it's
going
to
be
watching
the
layer,
7
or
the
route
types
and
specifically
the
layer,
7
route,
types,
http,
proxy
or
http
route,
a
tls
route
and
so
forth.
C
C
And
what
else
here
do
I
want
to
mention
again
feel
free
to
kind
of
look
at
the
details.
We've
spent
quite
a
bit
of
time
going
through
the
design
for
contour,
as
well
as
contour
operator,.
A
C
C
B
C
B
C
It
would
also
have
another
arrow
for
the
http
route
and
tls
route
that
it's
watching
for
these
and
then
programming
right,
programming
envoy
here
right
so.
C
C
So
here
here
is
the
config
map
to
configure
contour
and,
and
so
when
contour
starts
up,
it's
going
to
be
looking
for
gateways
in
this
namespace
name.
This
now
currently,
the
contour
operator
would
like,
according
to
this
diagram
here
right,
it's
going
to
be
watching
for
these
gateways
and
then
it
would
program
the
config
map
to
say,
hey,
I
found
a
gateway
named
foo
and
namespace
bar.
C
If
I
had
a
block
that
showed
the
operator
here,
they're
going
to
be
interfacing
with
the
operator
to
manage
the
infrastructure
right
and
it's
the
app
developers
who
really
don't
care
about
all
these
details
right,
they
just
want
to
look
at
their
gateway
class
and
say:
oh,
you
know,
I
want
to
create
an
internal
or
a
public-facing
route,
so
I'm
gonna
go
ahead
and
create
a
route
that
references,
a
particular
gateway.
C
So
you
know
that's
kind
of
that
division
here
right.
So
if
we,
if
we
drew
kind
of
a
line
here
that
says
okay
operator,
is
up
here,
managing
these
components,
interacting
with
platform
providers
and
platform
operators,
and
then
it's
you
know
it's
the
application
developers
that
will
just
be
dealing
with
their
route
resources,
and
then
you
know
we
spent
a
lot
of
time
just
trying
to
find
okay
where's
that
dividing
line.
C
How
does
the
operator
and
contour
interact
with
each
other
and
again,
I'm
I'm
diving
into
the
operator
design,
there's
also
the
design
on
the
contour
controller
itself
and
both
reference
each
other
and
their
relationship
so
feel
free
to
take
a
look
at
the
design
specs
and
give
us
feedback.
I
definitely
would
appreciate
different
sets
of
eyes
on
the
approach
that
we're
taking
here.
B
Yeah,
I
was
really
interested
in
the
use
of
the
the
operator.
I
I
was
thinking
about
this
a
lot
with
the
eco
implementation
as
to
whether,
like
does
a
gateway,
instantiate,
an
envoy
deployment,
or
does
it
just
reference
an
existing
one?
I
was
curious.
B
C
So
let
me
address
your
first
question.
So
a
gateway
is
an
instance
of
a
contour
environment
right,
so
no
gateways
means
no
functioning
contour.
No
envoy
daemon
set
all
that
stuff
right,
and
so
you
need
to
create
a
gateway
and
a
gateway
again
is
an
instance
of
contour
without
gateway
apis.
That's
what
this
contour
crd
was
all
about
right.
The
operator
look
at
the
crd
and
say:
oh,
I
need
to
go
ahead
and
and
create
a
contour
environment.
C
What
we've
done
now
is
we've
added
a
field
to
the
crd
that
basically
tells
the
operator
hey,
don't
go
provisioning,
a
contour
environment
just
because
this
crd
exists
right,
so
it
we
added
some
logic
there.
So
now
the
contour
operator
basically
says
okay
contours
here
and
it's
referencing
a
gateway
class.
C
So
this
contour
is
invalid
until
the
reference
gateway
class
exists
and
that
I
val,
I
then
validate
this
gateway
class
and
this
gateway
class
references,
this
contour
so
right
now,
there's
kind
of
that
bi-directional
relationship,
it's
something
that
we're
still
iterating
on
to
see.
If
that
is
the
right
approach
or
not,
but
that's
what
we've
settled
on
for
the
time
being.
C
So,
there's
now
that
kind
of
relationship
between
the
gateway
class
that
we
know
points
to
crd
and
then
the
crd
actually
references
the
gateway
class
and
that
allows
the
operator
to
supply
some
status
and
say
hey
these
two
components:
reference
each
other
they're,
both
valid
so
they're,
ready
to
use,
go
ahead.
Anyone
who
wants
to
create
a
gateway
create
a
gateway
right
and
this
person
up
here
this
platform
operator
says:
okay,
let
me
create
this
gateway.
Contour
operator
sees
it
and
says
a
gateway
means.
I
need
to
go
ahead
and
create
a
contour
environment.
C
B
My
first
one
was
the
second
was
it
like.
Do
you
require
users
to
use
the
operator
to
use
the
apis?
Because
I
correct
me
for
a
wrong,
but
I
don't
think
you
need
the
contour
operator
to
use
contour
today
right.
C
Correcting
correct
and
correct,
so
you
don't
need
the
operator
to
use
contour
today.
If
you
go
to
project
contour
getting
started
right,
you
have
a
few
options
before
up
until
recently,
it
was
just
this
quick
start
right.
It's
so
you
know
we
maintain
this
rendered
manifest
that
I
think
I
showed
you
somewhere
around
here
right
so
see
here
examples,
so
this
rendered
manifest
is
just
an
easy
way.
Like
an
all-in-one,
you
know
manifest
that
can
be
used
for
the
getting
started
in
111.
C
We
added
support
alpha
support
for
the
operator,
and
so
yes,
you
need
the
operator
to
support
gateway
apis.
C
The
plan
is
that
we
also
provide
an
option
b
for
users
that
don't
want
to
use
the
operator
and
there's
going
to
be
some
type
of
limitation
there.
So
it's
something
that
we're
still
some
of
the
details
are
still
working
through
steve
is
steve
slocus
on
the
call
who
has
been
a
contour
maintainer
for
a
long
time.
Steve.
Do
you
want
to
add
anything
to
this
topic.
E
Yeah
yeah,
I
mean
the
operator
isn't
required.
You
could
just
create
the
so
today,
like
you
to
spin
up
contour,
you
just
need
to
deploy
contour
and
then
envoy,
an
envoy
is
set
with
a
type
load
bouncer.
So
if
you're
in
some
sort
of
environment
that
can
read
that
type
load,
balance
or
service
type
load
bouncer,
then
you
know
it'll
all
link
up
so
in
gateway
api
you
just
have
to
create
the
gateway
and
then
tell
contour,
hey
I'm
using
this
gateway.
E
So
I
guess
we've
decided
that
one
gateway
maps
to
one
instance
of
contour,
so
you
can't
have
you
know
three
different
gateways
all
being
configured
by
one
instance
of
contour.
In
that
example,
you'd
have
to
have
three
different
installations
of
contour,
but
yeah
you
should
totally
be
able
to
either
use
the
operator
if
you'd
like
to
or
not
or
if
you
don't
want
to.
You
know,
you're
not
required
to.
C
Yeah,
I
think
the
challenge
we
get
to
using
gateway
apis
with
contour
alone
that
we've
discussed
is,
is
you
can
go
ahead
and
create
an
instance
of
all
right
of
a
gateway,
but
there
needs
to
be
some
kind
of
active
controller.
That
is,
you
know,
supplying
status
for
the
gaming
and
so
on
and
so
forth.
So
so
it's
just
something
to
keep
in
mind
as.
B
Yeah,
that's
really
useful.
I
think
I
I
didn't
fully
understand
it
without
the
gateway
was
one-to-one
with
the
envoy
deployment.
So
you
expect
then,
like
all
the
tls
stuff
would
be
done
at
the
at
the
route
level.
I
would
imagine,
and
then
we
can
see
how
it
looks
or
I
guess
it's
not
necessarily
like
you'd
have
one
centralized
gateway
that
could
have
pls
settings
right,
but
if
you
need
to.
C
Yeah
and
we
yeah
so
from
an
operator's
standpoint,
we
follow
the
the
same
process
that
the
quick
start
follows
where
a
job
gets
created
that
creates
secrets
for
contour
and
envoy
that
are
used
by
contour
and
envoy
for
securing
that
communication
between
them.
C
C
A
How
much
do
you
think
that
people
will
use
multiple
like
a
single
gateway
to
represent
a
large
set
of
domains
and
tls
for
them
or
they'll,
just
run
lots
of
different
gateways
and
instances
of
contour?
You
know
one
per
domain,
approximately.
E
I
think
in
the
history
of
control
we
typically
see
just
like
an
external
instance
that
gets
deployed,
and
everything
runs
through
that.
Okay,
usually
when
there's
more
than
one,
the
the
the
use
case
is
typically
an
an
external
one
and
an
internal
one.
So
like
hey
native,
does
this
they'll
have
like
an
external
ingress
controller
and
then
an
internal
one
to
do
different
types
of
routing?
But
you
know
other
folks,
depending
on
their
needs,
there's
always
always
different
needs,
so
they'll
have
different.
E
A
Yeah
now
that
that
makes
sense
so
that
I
think
what
I'm
what
I'm
hearing
from
this
is.
This
will
be
a
good
use
case
of
kind
of
larger
gateways
like
gateways
that
contain
a
lot
of
config
and
we'll
just
need
to
make
sure
our
api
handles
those
use.
Cases
well,
and
I
think
a
lot
of
implementations
will
be
having
similar
logic.
It's
just
good,
too
good
to
see.
D
Rob
this
actually
brings
up
a
point
we
were
discussing
earlier
this
week
for
the
gke
gateway
controller,
about
route
isolation
and
making
sure
that
the
sharing
of
gateways
is
safe.
D
We
were
just
kind
of
identifying
all
the
areas
and
like,
for
instance,
one
is
obviously
just
merging
in
conflicts
which
is
specified
by
the
api,
but
there's
probably
details
within
each
implementation.
That
will
kind
of
be
more
specific
than
the
what
the
api
says
and
then
also
misconfigurations
for
making
sure
that
a
misconfiguration
or
any
kind
of
configuration
on
one
route
can't
prevent
the
reconciliation
of
other
routes
and
then
also
kind
of
eventing
and
status.
D
One
example
would
be
like
a
quota
for
a
certain
resource
has
been
reached,
which
is
something
that
probably
the
route
owner
needs
to
know
that
you
know
why
their
route
isn't
getting
applied,
but
also
is
something
the
gateway
owner
needs
to
know,
because
they
probably
have
the
power
to
go
and
change
quotas
for
the
project,
or
something
like
that.
So
that's
something
that
is
probably
good
for
discussion
at
the
same
point.
It's
definitely
more
of
an
implementation,
specific
thing,
but
it
does
affect
all
of
us.
A
C
No
no
problem
at
all,
so
I
just
wanted
to
run
through
really
quickly.
I've
got
a
kind
cluster
running
on
my
laptop,
so
you've
got
a
single
control,
plane,
node
worker
node,
I'm
actually
running
the
operator
locally.
As
I
mentioned,
I
actually
just
got
this
working,
maybe
an
hour
plus
ago,
and
so
let's
go
ahead
and.
C
C
So
again,
the
crd
is
exposing
kind
of
infrastructure,
specific
information
right
since,
since
this
environment
is
going
to
be
running
locally,
I
expose
node
ports
on
my
laptop
instead
of
creating
a
service
of
type
load
balancer,
for
example
right.
So
this
is
where
we
get
into
network
publishing.
Details
see
here
gateway,
class
right,
pretty
basic
refers
to
this
contour
crd,
and
then
we
program
the
operator
to
look
for
this
specific
controller
string
to
manage
gateway
classes
by
this
name.
C
A
A
C
You
know
that's
that's!
What
we
came
up
with
is
is
that
without
a
gateway
class
reference,
it
tells
the
operator
that
it
is
not
operating
in
gateway,
api
mode
and
says
when
and
so
when
gateway
class
reference
which
by
default
doesn't
exist.
Okay,
that
would
tell
the
operator,
okay,
I'm
not
operating
in
gateway
api
mode.
So
I
need
to
go
ahead
and
act
on
this
contour
by
creating
a
contour
environment
by
having
the
gateway
class
ref.
C
C
Make
sense
cool
all
right,
so
we
see
by
creating
the
gateway,
class
gateway
and
contour.
We
actually
now
have
contour
and
envoy
running
okay
awesome.
So
now,
let's
create
a
sample
application.
C
It's
all
standard
right,
a
deployment,
that's
being
used
to
manage
the
card,
app
a
service
and
then
here's
what
we
really
care
about
is
the
route.
C
No
longer
have
the
route
and
we
no
longer
have
the
app
can't
hit
the
app
anymore.
So
that's
it.
I
mean
not
not
all
that
fancy,
but
we've
got
something
working
now
and
still
a
lot
to
iterate
on
and
prove,
but
we've
got
that
first
benchmark
of
something
working.
A
That's
really
cool
awesome
to
see
I
have
to
ask
you
know:
you've
worked
through
this
api,
a
lot
you've
implemented.
Most
of
it,
it
looks
like,
were
there
pain
points
that
that
came
up
where
things
didn't
feel
natural
or
felt
like
they
could
be.
C
You
know
some
of
the
pain
points
we've
already
addressed,
as
you
know,
rob
you
know
not
being
able
to
reference
a
space,
scoped
crd
for
a
gateway
class
about
that
was
an
issue
and
I'm
glad
to
see
that
we
were
able
to
work
through
that
actually
pretty
quickly
too,
so
that
that
was
really
nice
say
right
now,
that's
probably
the
biggest
thing
that
stands
out.
I
would
say
the
other
area
is
still
just
you
know,
trying
to.
C
But
it's
like
okay,
when
we
have
this
stitching
together
of
resources,
is
you
know
having
to
supply
the
correct
status
based
on
the
different
relationships
and
what's
the
status
of
those
relationships,
and
so
that
kind
of
dependency
graph
between
the
two
and
properly
reflecting
status
for
each
of
those
resources
is,
is
still
something
that
that
I'm
working
through.
A
Yeah
that
makes
a
lot
of
sense.
I
think
exactly
what
you're
saying
the
relationships
and
making
sure
status
is
consistent
is
going
to
be
a
challenging
part
of
the
api
and
the
less
fun
part,
because
you
can
get
everything
working
without
that,
and
so
you
can
get
to
your
your
demo
state
everything
works
and
then
all
the
less
fun
things
yeah.
A
But
this
this
is
really
cool.
I'm
excited
to
see
this
come
together.
Do
you
do
you
have
any
idea?
I
think
last
last
you
mentioned
maybe
april.
May
you
might
have
something
ready
for
general
public
use
case
for
this.
C
Yeah
I'll,
let
steve
keep
me
in
line
here
if
he
thinks
otherwise,
but
you
know
we've
been
really
cranking
away.
It's
it's
why
you
know
I've
been
pretty
silent
in
in
the
gateway
api
community,
because
I've
been
so
focused
on
the
implementation,
but
we
cut
one
v113
next
week
next
wednesday
or
thursday.
I
think
it's
24th
and
I'm
hoping
to
have
these
prs
that
enable
all
this
functionality
that
I
showed
you
by
that
time.
C
So
so
yeah
that'd
be
great,
I
mean
it'll,
definitely
be
you
know,
early
adopter,
experimental
use,
but
at
least
something
that
people
can
start.
You
know
have
a
snapshot,
release
that
people
can
start
playing
around
and
and
giving
us
feedback
steve.
Do
you
want
to
add
anything
there.
E
No
yeah
we,
what
daniel
just
showed
was
we
we
just
merged
a
pr
that
gives
you
initial
support,
for
you
know,
routes
and
such
there's
a
lot
to
go
with
in
terms
of
we
don't
have
status,
updating
and
those
sort
of
things
so
lots
of
to
do's
throughout
the
code,
but
yeah.
C
E
C
Yeah
113
next
week's
experimental
use,
and
then
you
know
we
release
every
month,
so
I
would
see
big
big
changes
between
113
and
114,
but
again
at
least
113.
It
gives
someone
that
gives
users
the
ability
to
just
start
kicking
the
tires,
giving
us
feedback
and
so
forth.
A
That's
awesome
cool,
looking
forward
to
trying
that
out
yeah
any
other
comments,
questions
about
this
implementation.
B
Yeah
one
thing
that
I
find
kind
of
interesting
is
that
the
I
think,
there's
three
implementations
that
I
know
of
at
least
traffic
contour
and
ecgo
and
while
we're
all
using
the
same
apis,
we
all
have
different
ways
that
the
user
interacts
with
those
to
achieve
the
same
thing.
B
So
like
the
the
routes
I
think
are
very
portable
but
like
in
the
traffic
case,
they
obscure
the
gateway
is
even
existing
at
all
right.
The
user
just
sees
routes
in
the
contour
case.
The
gateway
is
kind
of
one
to
one
with
this
actual
deployment,
so
they
generally
have
one
gateway.
I
would
imagine
for
most
cases
and
then
east
geo.
We
have
potentially
like
multiple
gateways
that
were
merging
together,
that
is
associated
with
one.
You
know
actual
envoy
deployment.
B
A
There
a
comment
from
bowie
and
chat
that
that
was
on
purpose
and
nature
of
ingress
implementations.
I
I
think
it's
it's
good
to
point
out
and
good
to
keep
it
keep
an
eye
on.
I
know
next
week
we
want
to
go
through.
I
think
mark
might
go
through
what
we're
planning
for
gke
for
these
apis
and
maybe
we'll
start
to
see
some
overlap
between
all
these
different
implementations.
A
I
know
when
I
first
looked
at
traffic.
I
thought
that
they
really
obscured
gateway
away,
but
I
think
I
I
misunderstood
that,
and
it
was
more
just
a
you
know:
they're
they're,
hiding
it
in
their
helm
chart,
but
it's
not
that
gateway
resources
themselves
are
ignored
entirely.
A
So
I
think
I
think,
there's
maybe
less
differentiation
than
it
seems,
but
that
specific
point
you
made
john
about
gateway,
merging
like
whether
there's
a
a
single
instance
of
an
implementation
per
gateway
or
a
instance
of
an
implementation
for
all
gateways
of
let's
say
a
certain
class
or
maybe
multiple
classes.
I
imagine
that's
going
to
have
a
fair
amount
of
variation
yeah
that
that's
a
good
point
good
to
keep
an
eye
on
it
anyway.
A
Cool
all
right,
let
me
there
were
a
couple
things
left
on
the
agenda
and
I
know
we're
just
about
at
times,
so
I
want
to
make
sure
that
we
have
time
to
cover
these,
hopefully
well
brief.
Segway
is
my
screen
share
actually
working
again.
I've
had
very
mixed
luck
with
this
yeah.
A
A
I
think
we
have
enough
here
that
we,
you
know
it
seems
like
v1,
alpha
2
is
inevitable
and
as
we're
getting
these
initial
implementations
out,
the
door
really
want
to
make
sure
that
we
keep
these
kind
of
breaking
changes
in
mind,
but
maybe
even
more
importantly,
I
understand
any
changes.
Any
changes
we
need
to
make
based
on
initial
user
feedback.
A
That
would
be
more
significant.
I
think
most
of
these
are
relatively
small.
You
know
very
easy
to
convert
back,
you
know
back
and
forth,
but
I
I
feel
like
there's
more
lurking
out
there
that
we're
unaware
of
right
now.
A
You
know
this
year
at
least
maybe
this
summer,
but
soon
so
I
don't
want
to
just
have
an
api
that
stays
in
alpha
forever,
so
identifying
any
kind
of
breaking
changes
soon
in
the
next
month
or
two
will
be
really
helpful.
So
we
can
prepare
for
a
release
with
those.
A
So
I
don't.
I
don't
know
that
we
have
enough
time
to
work
through
each
one
of
these
in
this
meeting,
but
just
a
reminder
that
we
do
have
this
breaking
change
label.
We
do
have
the
v1
alpha
2
milestone.
A
A
So
just
be
aware
of
that,
and
please,
if
you
think
of
anything
that
we
should
change,
that
would
be
a
breaking
change.
The
sooner
we
can
start
processing
it.
The
better.
A
And
the
next
one
I
wanted
to
dig
into
a
bit
is
a
relatively
significant
change
to
our
docs
generation.
Our
docs
have
been
hosted
on
github
pages.
If,
for
any
of
you,
I
think
everyone's
made
some
kind
of
contribution
to
our
our
site.
Now,
probably
our
docs
specifically
and
it's
a
pain
you
have
to
run
a
local
docs
generation
to
convert
everything
into
html.
A
In
addition
to
that,
we
ran
into
this
unfortunate
thing
where
there
was
no
way
to
redirect
from
our
old
github
pages
url
to
our
new
github
pages
url.
A
Unfortunately,
we
should
have
made
this
change
this
adjustment
to
go
to
gateway
ap,
to
use
this
kind
of
sub
domain
before
we
made
the
change,
because
then
we'd
have
redirect
capabilities
and
more,
but
that's
what
I'm
working
on
now.
So
this
will
give
us
a
lot
more
advanced
functionality
in
our
docs.
A
I'm
really
looking
forward
to
it.
I
if
you
want
this,
is
really
similar
to
other
kubernetes
repositories
where
netlifybot
automatically
builds
and
previews
your
docs
pages
for
you.
So
this
pr
is
almost
ready.
I
could
use
more
eyes,
but
one
of
the
things
I
want
to
highlight
is
I
we
now
have
these
fun
things
down
here.
A
Most
importantly,
this
deploy
one.
If
you
click
on
the
details
for
it,
it
shows
you
a
preview
for
that
branch.
For
that
pr
of
exactly
what
your
documentation
looks
like
you
can
see
that
probably
our
most
complicated
thing
is
our
reference
documentation,
which
fortunately
works.
Just
fine,
I
you
can
see
believe
it
or
not.
We
brought
search
back
because
we
no
longer
have
to
deal
with
conflicts.
A
So
if
anyone
has
time
to
take
a
look
today,
that
would
be
great
I'd
love
to
get
this
out
this
week.
I
would
love
to
have
a
better
domain
and
more
control
over
this
and
a
better
development
process.
A
So
yeah.
I
think
that's
all
on
this
one.
We
are
at
time,
so
I
don't
want
to
take
any
more
of
your
time,
but
yeah.
Please
take
a
look
this
afternoon.
If
you
have
time-
and
thanks
so
much
for
taking
the
time
to
run
through
these
introductions,
both
john
danian
steve
of
what
contour
and
istio
are
doing,
and
I
think
we'll
try
and
get
something
caught
on
next
week
for
what
what
we're
trying
to
do
for
gke
as
well.
A
So
we
can
look
through
that
that
approach
as
well
and
yeah-
I
think
that's
all
for
this
week.
So
thanks
to
everyone
for
coming
out
talk
to
you
next
week,.