►
From YouTube: Ambient Mesh WG Meeting 2023 01 04
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).
B
A
Yep
yeah:
can
you
zoom
in
by
like
125
percent
of
150?
It's
a
the
tax
is
a
little
small.
C
D
D
B
So
I
spent
my
Christmas
break,
who
sort
of
working
over
how
upgrades
are
going
to
work
in
the
ambient
space
and
particularly
I,
had
some
help
from
Stefan
at
weaveworks
works
on
the
flux
tool
and
has
helped
us
with
thinking
through
our
upgrade
processes
in
the
past
and
putting
out
some
best
practices.
B
Probably
the
most
important
part
of
this
document
is
going
to
be
the
requirements.
While
there's
a
lot
to
talk
about
in
ambient
upgrades,
this
document
tries
to
focus
very
specifically
on
how
the
waypoints
will
be
upgraded.
There
are
others
working
on
like
Z
tunnel
upgrades
and
things
like
that,
but
this
seemed
to
be
an
area
that
we
hadn't
spent
much
time
on
at
this
point.
So
also
this
is
real.
This
document
is
really
focused
on
the
the
fleet
perspective
rather
than
the
individual
Waypoint
being
upgraded.
B
What
I
mean
by
that
is,
if
I
have
a
huge
cluster
with
hundreds
or
even
thousands
of
waypoints
in
it,
how
do
I
move
all
of
those
waypoints
gracefully
from
version
a
to
version
B?
How
do
I
decide
when
each
Waypoint
upgrades
there's
another
equally
interesting
question,
which
is
when
I'm
upgrading
a
single
Waypoint?
How
do
I
do
so
in
a
controlled
and
safe
manner?
Is
there
a
way
to
like
say,
run
two
versions
of
one
Waypoint
and
traffic
shift
between
them?
That's
very
interesting.
B
We
should
definitely
look
at
it,
but
it's
out
of
scope
for
this
document
trying
to
keep
a
fairly
limited
scope
on
the
fleet
here,
so
just
for
requirements
and
I'll
go
through
them,
one
at
a
time
and
pause
for
questions,
because
these
are
fairly
important.
B
The
first
is
that
we
do
need
to
follow
best
practices
in
deploy
orchestrating
our
waypoints.
This
is
not
just
upgrading
but
running.
B
We
need
horizontal
plot,
Auto
scalers,
which
will
be
responsive
to
load
placed
on
the
Waypoint.
If
it's
getting
overloaded,
we
should
scale
up
and
add
more
instances
and
pod
disruption.
Budgets
are
another
best
practice.
Those
are
sort
of
brought
up
as
examples.
If
there
are
other
kubernetes
best
practices
for
running
a
deployment,
we
should
be
leveraging
those
as
well
and
probably
allowing
the
user
to
modify
them.
B
A
Okay,
I
I
think
from
my
perspective,
well
I'm
looking
at
Waypoint
upgrade
requirements.
I
guess
I
would
be
less
thinking
about
like
underlying
implementation,
right,
whether
we're
using
HPA
or
per
disruption.
Budget
I
would
be
more
thinking
about.
Okay,
I
should
be
able
to
decide
when
to
upgrade
my
Waypoint
that
should
be
independent
of
my
control
play
and
I
should
be
able
to
upgrade
my
Waypoint
without
causing
any
downtime
to
data
plane
traffic.
At
least
there
should
be
an
option
for
that.
So
I'm,
more
thinking
about
the
higher
layer,
user
requirements.
B
Yes,
so
some
of
these
further
requirements
will
get
to
that.
The
the
one
that
is
out
of
scope
is
the
the
remaining
available
through
the
upgrade
process.
That
is
a
valid
requirement
that
just
needs
a
separate
talk,
because
this
is
sort
of
focusing
on
the
fleet
perspective
when
to
upgrade
each
individual
Waypoint
in
a
fleet
of
waypoints.
It's
not
so
much
focusing
on
okay,
we've
decided
to
upgrade
Waypoint
X.
How
do
we
keep
it
available
through
the
whole
process
and
serving
traffic
that'll
be
a
separate
dock?
Does
that
make
sense?
Lynn.
A
So,
are
you
more
targeting
like
in
place
upgrade,
they
will
absolutely
be.
Downtime
is.
B
Just
agnostic
about
what
happens
to
an
individual
Gateway
as
it
upgrades
whether
that's
in
place
or
whether
they're
side
by
side
we've
got
a
we've,
got
to
have
a
separate
design
for
that.
B
What
this
says
is,
if
you
have
a
hundred,
how
do
they
all
get
upgraded?
Do
they
all
just
upgrade
whenever
you
upgrade
your
control
plane
or
is
there
some
more
fine-grained
control,
and
what
does
that
control
look
like?
Does
that
make
sense?
Okay,.
A
B
B
It
may
not
be
an
upgrade
that
changes
the
version
of
the
Waypoint
that
you're
running,
but
it's
an
upgrade
that
changes
something
about
that
orchestration
and
so
is
Tod
needs
to
be
sort
of
involved
in
that,
if
it's
going
to
be
dynamically,
creating
hpas
and
pdbs
on
the
user's
behalf
and
likewise
requirement
number
two,
you
know
these
are
probably
not
in
a
priority
order:
I've,
sort
of
buried
the
lead
here
and
I
apologize
for
that,
but
resource
requests
just
like
hpas
and
pdbs
customers
need
to
be
able
to
customize
the
resources
allocated
to
Envoy
within
a
single
instance
of
the
Waypoint.
B
That's
one
of
the
key
advantages
to
the
ambient
model
is
that
we
can
be
more
responsive,
we're
not
dealing
with
the
sidecar
model
where
configuring
resource
requests
has
to
be
done
globally.
Instead,
they
should
be
able
to
do
this
on
a
per
Waypoint
basis
right.
So
if
a
one-way
point
is
going
to
be
really
heavily
utilized,
give
it
a
ton
of
CPU
or
a
memory
or
something
like
that.
B
Third
requirement
by
default
and
this
one's
a
little
bit
controversial,
John
and
I
have
a
comment
thread
that
you
can
follow
to
to
sort
of
understand
the
discussion
there,
but
by
default
all
waypoints
must
upgrade
when
their
control
plane
does.
What
this
is
just
saying
is
like
if
I
don't
do
anything
to
customize
my
deployments
and
I
upgrade
to
istio
in
ambient
mode.
My
waypoints
should
also
get
upgraded
right
now
this
requirement
is
not
fulfilled.
B
So
if
you
deploy
ambient
today
and
get
a
couple
of
way
points
going
and
then
let's
say
you
do
a
minor
version
bump
on
the
on
the
ambient
you've
got
to
do
your
own,
because,
obviously
we
don't
have
any
releases
yet,
but
you
can
simulate
it
just
by
publishing
your
own
tag.
B
I
have
tags
ambient
and
ambient
two
that
I've
published
for
my
images
if
I
upgrade
istod
from
TAG
ambient
to
tag
ambient
2,
even
though
the
templates
upgrade
and
anything
else,
new
gateways
that
I
create
will
get
ambient
2
version
of
the
of
the
Waypoint.
However,
all
of
the
existing
gateways
will
stay
with
ambient
one
until
they
are
deleted
or
or
something
else,
and
that's
not
like
deleting
a
pod
that'd
be
deleting
the
deployment
forcing
it
to
be
recreated.
B
So
that's
not
ideal,
ideally
we'd,
like
sort
of
the
same
upgrade
process
that
istio
users
take
today
to
upgrade
all
of
their
mesh
I.
Think
it's
just
an
oversight.
You
know
a
lot
of
this
stuff
was
pulled
together
pretty
quickly
over
the
summer
and
was
not
necessarily
meant
to
be
production
quality.
So
this
is
sort
of
just
a
requirement
that
we
finished
getting
it
to
a
basic
production
quality.
E
A
Agree
by
default,
oh
Waypoint,
Master
upgrade
when
they
are
control
plane
does
I
think
that
potentially
could
be
an
option,
but
I
just
think
it's
super
dangerous
as
a
default
Behavior,
especially
you
are
introducing
downtime
to
the
Waypoint
upgrades.
Also.
B
B
A
B
B
A
F
Mean
it's
kind
of
like
five
cars
right
like
we
could
have
implemented
something
that
goes
to
your
sidecar
and
restarts
it
for
you.
We
could
do
something
like
that
for
waypoints.
We
didn't
do
it
for
sidecars.
It's
maybe
there's
different
reasons
to
do
or
to
not
do
it
for
waypoints.
B
Within
the
same
upgrade
operation
yeah,
that's
a
that's
a
good
comment,
Keith
that
the
control
plane
is
not
necessarily
the
right
timing.
Okay,
so
we
we
have
a
little
bit
of
further
discussion
to
go
on
defaults
and
exactly
what
the
default
behavior
is.
That's
not
really
essential
to
this
design.
B
We
can
come
up
with
a
different
default
if
we
like,
but
I'll,
go
ahead
and
move
forward
kind
of
taking
that
as
a
note
that
we'll
sort
of
come
back
to
once,
we
once
we
understand
what
our
capabilities
are,
we
can
discuss
what
other
defaults
might
make
sense
and,
of
course,
the
last
requirement,
which
is
the
the
one
that
is
probably
the
most
unique
from
how
istio
has
run
in
the
past,
is
that
users
must
be
able
to
run
different
versions
of
the
Waypoint
for
different
gateways.
B
Okay,
this
is
something
that
was
accomplished
previously
using
revisions
so
for
every
version
of
the
sidecar
or
of
a
auto-injected
or
pod
injected
Gateway
you
needed
to
have
a
different
revision
or
different
control.
Plane
running
this
would
be
look
probably
different
from
this,
although
the
requirement
is
a
little
bit
on
the
vague
side
and
then
again
whether
waypoints
can
stay
up
and
available
during
an
upgrade
of
an
individual
Waypoint
is
a
super
important
question
that
needs
a
whole
separate
dock.
It's
too
important
to
sort
of
tack
on
to
this.
B
One
I
think
they
should
be
for
for
what
it's
worth.
I
think
it
should
be
hitless,
but
just
need
other
space
to
work
out
that
question.
A
For
your
first
bullet
right
user
should
be
able
to
run
different
versions
of
the
Waypoint
for
a
different
Gateway.
Would
that
be
like
for
the
service
producer,
because
I
guess
I'm
having
a
living
mental
transform
hard
time
to
transform
Waypoint
for
the
Gateway
was
Waypoint
for
the
service
right?
The
producer
service.
A
It's
like
food
called
Spa
right
and
in
that
context,
Spa
is
a
producer
service
producer.
B
Okay,
so
when
you
define
a
Gateway
using
the
kubernetes
Gateway
API,
you
need
to
specify
that
it's
tight.
Sorry,
maybe
I,
should
add
a
clarification
to
this
document.
Okay,.
B
Confused
yeah
I
was
thinking
basically
only
the
ones
that
represent
waypoints
in
the
ambient
model.
I,
don't
know
if
we're
using
waypoints
the
same
way
for
Ingress
and
egress
and
ambient
I've
not
seen
a
design
on
that.
Yet.
B
So
the
this
paragraph,
I
won't
go
over
in
detail.
It
just
covers
why
today,
waypoints
don't
actually
upgrade
and
has
some
serious
typos
in
it.
Okay,
next
up,
the
naive
implementation
would
be
sort
of
the
default
that
we
already
sort
of
discarded
that
you
upgrade
is
DoD.
It's
going
to
go
through,
find
all
the
waypoints
and
upgrade
them
to
the
new
version
right
away.
B
A
B
Right,
okay,
I'm,
not
hearing
objections
there.
One
thing
that
I
explored
with
Stefan
is
better
get
Ops
control.
We
really
want
to
design
whatever
this
process
looks
like
in
mind,
with
best
practices
for
running
things
on
kubernetes
and
git.
Ops
has
emerged
as
a
pretty
serious
standard
in
that
space.
B
So
one
way
to
do
it
would
be
when
you
create
a
Gateway
object.
You
need
a
waypoint
deployment
that
that
corresponds
to
it
right,
one
way
to
fulfill
that
would
be
to
Define
that
in
git
Ops,
so
you
create
a
Gateway
in
git
and
then
in
git
automatically,
based
on
some
sort
of
git
Ops
workflow,
a
deployment
is
automatically
created.
What's
cool
about.
That
is
that
all
of
your
deployments
are
accessible
in
git.
Any
modifications
you
do
would
go
through
your
standard,
git
Ops
flow.
B
What's
not
so
cool
about
that
any
gateways
that
get
created
in
the
cluster
that
don't
exist
in
git
that
for
some
reason,
bypass
get
Ops,
which
happens
frequently,
don't
actually
get
deployments
associated
with
them.
They
don't
execute,
which
is
bad,
so
advantages
here
are
that
everything
exists
and
get
the
way
that
it's
supposed
to
disadvantages.
Are
that
that
the
cluster
is
less
responsive.
You
cannot
buy
Basket,
Ops
control
and
still
have
a
working
deployment
of
ambient.
B
The
last
alternative
here
is
the
one
that
I
would
recommend,
and
this
would
involve
adding,
probably
two
crds
to
control
an
upgrade
process
for
ambient
waypoints.
One
of
the
crds
would
just
represent
a
waypoint
template.
Today,
the
Waypoint
template
is
specified
as
part
of
the
sidecar
injector
config
map
sort
of
buried
deep
in
the
config
and
difficult
to
edit.
This
would
just
promote
it
up
to
a
first-class
citizen
that
we
can
have
many
of
with
different
names,
so
you
could
have,
and
these
names
would
be
customizable
by
the
user.
B
We
could
do
some
defaults
like
every
time
you
put
a
new
version
in
the
cluster.
We
write
a
waypoint
template
named
that
version,
but
they
could
create
their
own
templates
with
their
own
names,
for
like
high
performance
gateways
and
low
performance
gateways,
and
who
knows
you
know
what
sorts
of
customizations
they
want
to
apply
here,
but
these
are
just
names
templates.
B
Then,
a
given
Gateway
would
be
mapped
to
the
the
template
that
it
should
use
by
use
of
a
label
selector.
So
a
waypoint
selector
crd
would
just
be
a
label
selector
combined
combined
with
a
reference
to
a
template.
When
a
Gateway
is
created,
we
find
which
Waypoint
selectors
match.
B
Hopefully
only
one
or
maybe
we
need
to
add
priority
so
that
in
the
case
of
multiple
matches,
we
can
select
the
correct
one
and
have
deterministic
behavior
that
points
to
a
single
template
which
is
used
to
create
the
Waypoint
and
that
template
can
include
a
deployment
horizontal
pod,
Auto,
scalars
pdbs.
Whatever
is
needed
for
execution
there.
B
So
the
the
last
paragraph
here
walks
through
what
a
large
upgrade
might
look
like
for
a
user.
If
I
have
say
hundreds
or
thousands
of
waypoints
I
likely
would
have
one
template
for
version
a
and
one
template
for
version,
B
I'm
already
on
version
a
I
want
to
get
to
version.
B
I
would
advise
that
a
user
have
lots
of
Waypoint
selectors,
let's
say
10.
Maybe
they
would
call
them
waves
again.
This
is
totally
customizable
by
the
user,
but
just
showing
one
way
that
it
could
be
used.
B
So
when
you
upgrade
the
the
wave
one
Waypoint
selector
all
of
the
wave
one
waypoints
upgrade,
and
you
wait
some
period
of
time
to
see
if
wave
one
was
successful,
then
move
to
wave
two
gives
them
a
predictable
order
and
Cadence
throughout
all
of
their
mesh
in
which
these
upgrades
are
going
to
occur,
but
again
customizable
by
the
user.
If
they
don't
want
to
use
waves
If
instead,
they
want
to
go
namespace
by
name
space
or
something
else.
This
would
be
up
to
them.
B
I'm
not
so
sure
about
that,
like
there's
a
lot
of
Performance
Tuning
that
you
can
can
and
wish
to
may
wish
to
do
to
an
Envoy
proxy
that
they
may
want
to
do
through
templates
and
selectors
I
think
we
probably
ought
to
also
have
a
mechanism
to
override
that
using
annotations
so
like
this,
if
all
you
need
to
do
is
modify
Gateway
requests
for
one
or
sorry
resource
requests
for
one
Gateway.
B
F
F
You
have
templates,
which
you
can
select
so
the
default.
One
is
obviously
sidecar,
but
you
can
actually
add
a
custom
one
and
then
apply
multiple
templates
as
well.
So
you
could
say:
I
want
to
start
with
the
base
of
sidecar
and
then
add
my
extra
resource
template
right
and
then
you
also
have
a
nether
knob,
which
is
the
revision
which
normally
I
mean
in
theory.
F
You
could
have
like
the
latest
E
Studio
injected
and
set
an
older
version
based
on
template,
but
you'd
probably
select
first,
the
version
based
on
revision
and
then
your
customization
based
on
the
template.
The
thing
that
may
be
missing
is
the
ergonomics,
though,
because
it's
all
in
one
config
map.
You
know
one
shared
config
map
which
is
hard
to
modify.
If
you
know
you're,
not
an
admin,
but
a
lot
of
the
building
blocks
are
there
so
I?
F
The
other
thing
is
we
should
have
consistency
like
all
these
problems.
You're
talking
about
the
exact
same
ones
applied
to
gateways
too
even
Beyond
istio.
So
it
would
be
ideal
if
we
had
consistency
between
those
at
the
very
least
between
the
Eastview,
Gateway
and
waypoints,
but
if
we
can
find
a
common
ground
amongst
other
people,
that
would
be
awesome.
Obviously,
that's
a
much
bigger
ask,
though,.
F
Yeah
we
we've
talked
about
about
it
a
bit,
but
not
much
I
just
asked
again.
If
anyone
else
was
doing,
this
I
think
we're
the
only
one
that
has
customization
and
which
is
this
like
hacky
mechanism
with
Anna,
you
select
the
template
by
annotation
by
the
way
I
I
haven't,
got
a
responsibility
just
asked
for
like
10
minutes
ago.
So
we'll
see
if
there's
been
any
progress,
that
I'm
not
aware
of.
B
Thanks
so
I
see
a
whole
bunch
of
hands
raised,
suti
I
think
is
up
next.
E
Okay,
yeah,
so
most
of
the
istio
upgrades
are
mostly
in
in
place
upgrades.
So
I
was
just
thinking
as
in.
If
we
do
a
canary
upgrade
for
the
for
the
control
pane,
then
how
would
this
template
templates
would
actually
behave
and,
as
well
as
let's
say,
I
mean
you
think
about
as
an
area
which
is
like
after
four
or
five
revisions,
I
mean
it
will
mostly
become
very
complicated,
and
we
have
to
think
about
like
many
many
many
templates
here.
So
that
might
be
a
comparison.
E
The
second
thing
that
I
wanted
to
talk
about
is:
are
we
pushing
the
upgrades
down
to
the
users
and
when
we
say
users,
what
do
we
mean
the
applications
or
the
all
the
or
all
the
persons
who
are
actually
managing
the
platform?
So
what
who
are
the
actually
intended
users
here.
B
Those
are
excellent
questions.
Let
me
see
if
I
can
get
to
them
in
order.
If,
if
you
have
a
bunch
of
revisions
or
you
try
to
do
a
canary
based
upgrade
with
multiple
revisions-
and
you
are
explicitly
using
Waypoint
selectors
for
all
of
your
waypoints,
so
nothing
is
falling
back
to
a
default,
especially
since
we
we
don't
necessarily
have
consensus
on
what
that
default.
Behavior
should
be
that
revision
based
upgrade
will
not
affect
your
Waypoint
in
any
way.
As
far
as
execution
goes,
it
may
change
which
control
plane.
B
It's
communicating
with
based
on
what
revision
it's
a
member
of,
but
the
orchestration
the
deployment,
the
HPA
all
the
resource
requests.
Everything
like
that
would
be
unchanged
because
it's
defined
by
your
Waypoint
selector
and
template
the
only
time
those
parameters
would
change
is
if
either
the
selector
or
the
template
changed
well
or
actually
I'm.
Sorry,
one
other
one
other
scenario:
the
labels
on
your
gateway.
If
you
change
the
labels
on
your
gateway
such
that
it
matches
a
different
selector,
then
it
would
be
modified.
E
And
yeah
before
we
go
to
the
second
one,
I
mean
the
first
itself
makes
me
feel
that
there
are
so
many
moving
Parts
here
as
in
we
need
to
keep
track
of
many
many
crds
here
and
then
we
need
to
take
care
of
the
gateways.
We
need
to
make
sure
measure
that
if
you
change
something
on
the
Gateway,
it
also
gets
reflected
on
the
Waypoint.
So
so
those
are
a
little
concerning
to
me
yeah
and
it
might
be
difficult
for
a
normal
user
to
probably
keep
a
track
of
all
of
these
things.
E
B
B
Then,
when
you
upgrade
the
template,
everything
in
the
cluster
upgrades
what
I
would
push
back
on,
though,
with
regard
to
complexity
is,
is
there
a
compelling
user
story
that
we
can
tell
that
introduces
less
complexity?
If
there
is,
we
should
go
for
it.
B
It
sounds
like
we
don't
want
everything
to
automatically
upgrade
when
the
control
plane
does
or
maybe
suti
I,
don't
want
to
put
words
in
your
mouth.
Maybe
you
are
advocating
for
everything
to
automatically
upgrade
when
the
control
plane
does
what
what.
E
E
Are
the
older
control
pin
goes
away
cleans
up
all
the
other
waypoints
yeah,
the.
B
The
restart
semantics
that
we
have
today
with
sidecars
during
an
upgrade,
have
caused
a
lot
of
problems
for
the
project
throughout
the
years,
because
it's
not
declarative
if
you
upgrade
a
control
plane
and
then
leave
your
pods
running
for
say
three
months
and
then,
for
whatever
reason,
your
cluster,
you
have
some
node
change
and
a
bunch
of
PODS
restart.
All
of
a
sudden,
you
just
got
a
sudden
upgrade
of
a
whole
bunch
of
envoy
sidecars,
and
you
didn't
ask
for
that
upgrade
well.
B
You
did
you
asked
for
it
three
months
ago,
but
it's
very
difficult
for
the
user
to
connect
their
action
to
the
change
in
the
cluster.
So
I
wouldn't
necessarily
want
to
replicate
that
behavior
for
waypoints
I
think
that's
actually
a
problem
that
waypoints
solve,
rather
than
a
behavior
that
we
should
carry
forward.
Does.
E
D
So
I
think
I'm
next,
unless
it
and
you
want
to
go
first
I
I
think
it'll
be
a
bit
longer.
My
concern
is
in
history.
We
already
have
about
20
ways
to
do
things,
especially
around
the
install
and
in
reality
most
people
use,
help
to
install
stuff,
or
they
expect
some
managed
service
that
was
going
to
I
mean
things
will
automatically
happen
like
discuss
earlier
between
those
two
options.
Do
we
need
any
third
option?
Do
we
need
any
other?
D
You
need
to
create
a
gate
with
whatever
deployment
it
wants
without
caring
about
templating
and
configurations,
and
then
then
they
already
have
that
and
if
they
want
full
control,
they
can
just
use
Helm
charts
for
gateways
that
are
supported
and
are
identical
for
Waypoint
and
or
should
be
identical
between
Waypoint
and
Gateway,
because
there
is
nothing
different
between
them.
D
Except
one
is,
you
know,
deployed
by
namespace
and
may
have
an
extra
flag
to
have
the
age
Point
enabled
the
other
one
doesn't
have
H1
enabled
but
other
than
that
they're
exactly
the
same
thing
so
between
the
helm,
template
which
we
are
not
going
to
deprecate,
and
it's
probably
the
most
popular
and
provides
the
most
complex,
configurability
and
user
can
set
whatever
they
would
normally
set
with
Helm,
and
they
have
no
kind
of
confusion
and
because
it's
not
just
your
Waypoint
another
invented
way,
specifically
just
for
Waypoint.
D
It's
the
same
hand
truly
customer
as
well
as
they
had
for
whoever
and
all
other
application
is
so
that
Max
flexibility
and
the
other
one
which
again
is
your
support
for
quite
a
few
versions,
is
fully
automatic.
E-Stud
already
has
a
mechanism
to
create
deployments
and
configure
them
with
whatever
mechanism,
and
we
don't
change
anything.
There
is
no
reason
to
change
anything.
D
Because
it
will
be
super,
complicated
and
so
I
would
rather
initially,
this
was
the
first
few
releases
stick
with
the
two
options
that
we
have
and
later
on.
If
we
find
that
Helm
is
again
a
quick
find
in
the
first
few
years
ago
that
that
help
is
not
good
enough
and
we
need
to
invertise
your
cattle.
Then
we
can,
we
can,
you
know,
maybe
send
the
open
this
proposal.
B
So
with
the
helm
model,
just
to
make
sure
that
I
understand
what
you're
saying
cost
in,
if
you
go
directly
to
the
cluster
and
it's
in
Helm
mode,
you
create
a
Gateway,
a
kubernetes
gateway
crd.
It
will
not
have
a
corresponding
deployment.
You're
responsible
for
creating
your
own
using
help
is
that.
D
Just
like
we
do
today,
I
mean
today.
If
you
want
to
create
a
Gateway
in
a
namespace,
you
do
help
me
install
list
your
slash,
Gateway
and
do
whatever
you
want.
I
mean
it.
You
have
full
control.
You
can
create
separate
revisions,
you
can
you
I
mean
we
can
take
you
know,
divisions
upgrade
is
a
well-defined
process,
not
so
well
for
for
gateways,
but
still-
and
if
you
don't
I
mean
most
people
probably
will
not
bother
with
that.
D
Unless
they
want
full
control,
then
they
have
the
fully
automated
that
history
has
today
is
that
we
can
hide
completely
from
the
user,
basically
and,
and
that
also
allow
us
to
put
the
gateways
in
a
different
cluster.
Have
some
sort
of
manage
shared
gateways
do
all
kind
of
fancy
stuff?
That
is
not.
We
will
become
impossible
if
we
expose
templates,
because
your
proposed
that's
a
fundamental
flow
with
this
model
is
that
it
assumes
that
user
will
want.
The
will
still
want.
D
B
So
certainly
you
don't
have
to
use
Waypoint,
selectors
and
templates
if
a
pod
spins
up
that
matches
no
selector
and
you
don't
have
a
default
selector,
we
would
have
no
deployment
to
correspond
to
that
or
to
that
Gateway,
and
then
you
would
be
capable
of
scheduling
a
deployment
in
whatever
system
you
want.
You
can
run
it
on
vsphere
if
you
feel
like
it.
D
B
To
be
clear,
it
doesn't
already
work,
it's
not
already
supported
for
waypoints,
particularly
when
you
upgrade
this
Tod.
Nothing
happens
to
your
existing
waypoints.
They
never
change.
D
G
Yeah
I've
got
three
comments,
so
first,
this
is
solving
a
complicated
problem
and,
as
a
result,
it
appears
to
be
a
complicated
solution
which
makes
sense,
just
in
general
I'm
wondering
if
we
can
delay
adding
the
complexity
until
we're
further
along
in
the
development
process
and
have
a
better
understanding
of
what's
needed.
G
Like
I
I,
basically
agree
with
the
requirements
as
a
kind
of
GA
requirement
for
Waypoint
upgrade
yep
I'm
skeptical
of
our
ability
to
figure
out
what
the
best
ux
for
how
to
organize
the
crds
and
all
that
sort
of
stuff
is
going
to
be
today.
G
So
the
first
question
I
would
have.
Is
there
something
we
can
do?
That's
good
enough
for
an
alpha
release,
that's
much
simpler!
That
doesn't
lock
us
out
of
the
correct
solution
later
I.
Don't
know
the
answer,
but
that's
kind
of
my
like
first
broad
question:
I
can
keep
going
or
I
can
let
you
respond
well.
B
I
would
ask
you
know:
I
understand
that
there
is
some
complexity
here,
but
Waypoint
templates
already
exist
just
in
a
config
map,
there's
already
a
bunch
of
names
templates
and
there's
already
gateways
that
have
labels.
So
this
is
introducing
two
fields
in
a
very
small
crd.
I
have
a
hard
time,
envisioning
a
much
simpler
API
than
that.
G
B
From
a
ux
perspective,
leave
your
proposal
that
I
have.
The
idea
is
that
if
the
user
doesn't
understand
this
stuff,
they
perform
an
upgrade
their
waypoints
upgrade.
They
didn't
spend
any
time
thinking
about
Waypoint
selectors,
it
just
happens,
but
if
they
care,
if,
for
instance,
you
know
they're
in
a
huge
production
cluster
and
they
want
waves
or
they
want
different
tiers
of
service,
they
have
the
ability
to
set
that
all
up
with
just
this
two
field,
crd,
but.
D
If
they
want
to
set
tiers
and
whatever
they
probably
won't,
do
that
for
all
their
deployments,
using
CI,
CD
and
advanced
stuff,
and
they
want
full
controls,
you
want
to
update
their
app
in
the
name.
Space
update
the
Waypoint
I
mean
they
have.
They
want
to
have
full
quantity
and
that's
the
help
options
that
they
have
I
mean
it's
not
I,
don't
think
they
want.
Oh
for
easier
waypoints.
We
use
this
process,
but
for
my
application
and
for
my
configs
I
use
a
different
process.
B
So
the
the
they
do
use
cicd
extensively,
and
this
would
be
a
CI
CD
compatible
change.
It
works
with
helm.
What
it
doesn't
do
is
actually
create
the
deployment
itself
in
their
CI
CD,
because
oftentimes
in
a
cluster.
This
is
something
we
found
by
the
way
with
the
istio
git
Ops
demo,
that
or
that
we
sort
of
published
as
a
best
practice
back
in
May.
B
There
will
be
a
number
of
times
that
users
bypass
necessarily
get
UPS,
perhaps
they're
working
with
a
Helm
chart
that
simply
does
not
allow
them
to
modify
the
values
that
they
want,
and
so
a
Gateway
gets
created
dynamically
in
the
cluster.
In
that
scenario,
that
Gateway
would
just
never
run.
There
would
be
nothing
that
happens
corresponding
to
it
because
it
doesn't
exist
in
git.
B
G
That
make
sense.
Let
me
let
me
make
my
last
point,
because
I
think
this
plane
is
the
The
Meta
problem
that
we're
actually
talking
about
kind
of
an
original
sin
which
is
not
a
problem
with
this
proposal.
It's
a
problem
in
the
experimental
branch
is,
for
the
first
time
we're
using
sdod
as
sort
of
a
like
pod
deployment
management
thing,
and
it
it's
a
little
awkward
because
it's
kind
of
competing
with
kubernetes,
which
also
does
POD
management,
and
it
really
doesn't
make
sense
once
you
start
to
think
about.
G
People
have
got
kind
of
vendored
versions
of
istio
that
are
going
to
have
weird
vendor-specific
versions
of
wayplanes
that
are
going
to
need
their
own
stuff.
G
I
I
I
would
love
for
there
to
there's
this
I
would
love
I.
Would
love
for
istio
do
not
care
about
this
at
all,
but
we
also
need
behavior
that
works
reasonably
well
out
of
the
box.
So
I
don't
know
what
the
answer
there
is,
but
I
think
that
the
I
think
the
debate
you
and
Kosten
are
having
are
actually
fundamentally
caused
by
this,
like
attention.
B
Is
common
to
all
implementers
of
the
Gateway
API
if
you're
implementing
the
kubernetes,
Gateway,
API
and
you're
you're
running
it
in
kubernetes
I,
suppose
you
could
run
it
elsewhere.
You
will
have
this
problem.
You
will
need
to
respond
to
a
Gateway
and
cause
something
to
execute
somewhere
in
your
cluster.
A
B
F
A
C
F
It
also
effectively
requires
injection
I,
think
we
we
have
it,
for
you
know:
istio
gateways,
that's
kind
of
the
Legacy
option,
because
it's
before
the
whole
Gateway
API
but
I,
think
if
we
were
to
create
Easter
today,
we
would
probably
only
have
gateways
as
my
suspicion
so
I'm
not
sure
that,
now
that
we
have
a
clean
slate,
that
we
want
to
pull
back
in
the
helm,
install
option.
D
B
Yeah
I
I
worry
about
making
istio
less
responsive
to
the
user.
Like
this,
this
whole
concept
that
we've
had
in
gateways
forever
in
istio.
That
first
you
create
the
Gateway
object.
Then
you
need
to
also
create
a
matching
deployment
and
that
deployment
is
more
or
less
determined
by
the
Gateway
object
and
the
control
plane.
B
We,
we
sort
of
added
pod
injection
to
ease
that
a
little
bit,
but
you
still
have
to
create
the
deployment
to
have
the
pot
injection
I
think
what
makes
sense
from
the
user
is
that
we
don't
repeat
ourselves
right
or
we
don't
require
them
to
repeat
themselves.
If
you
create
a
Gateway,
the
Gateway
should
execute
the
way
that
you
specified.
You
should
need
to
think
about
how
or
why
Etc.
A
Yeah
there
are
something:
I
also
have
an
agenda
which
you
wish
you
to
get
to
Lee
Min
Sue
I
actually
was,
as
costume
was
thinking
saying
stuff
when
he
raised
hand
earlier
I
actually
was
thinking.
You
know,
how
does
the
user
deploy
Gateway
today
right
so
I?
A
So
that
would
be
obvious
if
people
need
Advanced
customization
such
as
resources
such
as
Target
disruption,
budget
that
you
mentioned
so
I'm
curious.
You
know,
would
that
be
a
reasonable
starting
point
for
people
who
needs
customization
without
introducing
additional
semantics
and
additional
templates
for
the
Waypoint.
B
So
I
don't
think,
there's
actually
any
way
to
disable
that
sort
of
customization
in
ambient.
The
bottom
line
is:
if
you
want
to
control
everything
and
do
everything
yourself
as
a
user,
you
can
schedule
your
own
Envoy
deployments
and
you
can
get
them
to
connect
to
sdod.
You
can
give
them
your
own
initial
config.
If
you
want
to
we're
building
a
solution
for
customers,
the
the
whole
idea
is
behind
istio.
Is
that
it's
Envoy,
but
you
don't
have
to
do
everything
right.
B
B
What
is
the
amount
of
control
that
we
want
to
give
to
users
and
flexibility
versus
how
much
should
we
do
for
them
and
make
the
right
decision
on
their
behalf?
I'm,
not
sure
that
there's
a
clear
and
obvious
answer
to
that
question,
but
it's
an
important
one
to
address.
A
B
Absolutely
I'm
working
I
was
hoping
to
have
a
demo
ready
for
everybody
this
morning,
but
it's
not
working
yet
so
I'll
continue
sort
of
honing.
This
I
would
love
especially
Lynn
to
continue
the
conversation
with
you
around
default
Behavior
and
to
understand
like
what
you
think
a
default
ought
to
look
like,
because
that
that
would
be
important
to
capture
and
I'm,
not
sure
that
I've
captured
all
of
that
here.
But
this
will
be
a
ongoing
effort
for
sure.
A
Okay
sounds
good,
so
if
there's
no
further
comments,
should
we
move
to
leave
me
next
yeah.
Thank
you.
So
much
Mitch.
C
Yep,
let
me
present
a
stock.
D
C
Yeah,
so
this
is
actually
a
follow-up
discussion
of
the
previous,
your
presentation
done
by
yossi
and
the
link
about
The
zetano,
L4
policy
yeah,
so
directionally.
This
is
a
consistent
with
the
existing
proposal
by
Yoshi,
underneath
I
just
proposed
an
alternative
API
representation
yeah,
which
I
think
is
probably
more
flexible
yeah.
So
so
the
idea
of
this
API
Proto
is
I.
Actually
modeled
based
on
the
existing
m-word
object
API.
C
Yeah
and
the
implementation
will
also
be
very
straightforward,
because
this
is
you
could
recursive
API
and
this
example
and
what
implementation
already
exists.
C
Api,
it
does
not
introduce
the
concept
of
rows
or
permissions,
so
it's
simply
the
Raw
matches
yeah
yeah.
Actually,
the
main
Proto
is
basically
yeah
I
copy
the
front
UC
stock.
So
this
is
consistent
with
what
we
already
have
and
instead
of
trying
to
model
it
just
based
on
the
existing
issue.
Accession
policy,
the
the
next
next
level
of
raw
match-
is
it's
basically
decoupled
with
the
control
plane
policy.
C
Yeah
I
I
have
an
example
of
how
we
translate
the
Easter
isolation
policy
into
this
L4
yeah
l40
tunnel
policy,
so
as
yeah,
so
the
yeah.
Basically,
the
benefit
of
having
this
product
is.
Why
is
the
it
has
a
simple
protocol?
However,
it
provides
the
maximum
flexibility
yeah.
It
provides
a
like
you
can
have
any
recursive,
ending
or
combinations
and
the
also
on
the
control
plane.
C
I
think
the
benefit
is
because
on
L7
we
are
going
to
use
the
M1
attack
and
it
will
be
nice
to
have
like
a
very
similar
implementation
in
the
control
plane
for
L4
event
for
L4
implantation
as
well.
So
this
will
allow
the
code
to
reduce
in
Eco
control,
plane
and
also
the
other
benefit.
Is
it
decouples
control
planning
policy
and
the
data
plane
policy
on
data
plane?
Basically
on
Z
tunnel?
C
You
don't
need
to
think
about
how
the
control
policy
will
look
like
is
simply
what
you
try
to
implement
is
you're
trying
to
have
in
the
end
or
combinations,
and
it
can
be
used
by
not
only
the
Eco
or
session
policy
but
can
be
used
by
any
policies.
For
example,
the
kubernetes
network
policy
or
any
other
policy
council,
is
based
on
ever
Outback.
C
Yeah
I'll
stop
here
and
yeah
see.
If
there's
any
questions.
D
C
C
A
Just
making
sure
we're
all
on
the
same
page
John
actually
have
a
very
most
recent
implementation,
I'm,
not
sure.
If
you're
looking
at
the
most
recent
one
Amy.
C
Yes,
yeah
yeah
I
actually
had
a
rough
brief
discussion
with
John
on.
A
C
Topic
as
well,
yeah
yeah,
so
I
I,
look
at
John's,
Proto,
I,
didn't
look
at
the
the
code
implementation,
but
I
I.
Think
my
understanding
is
the
current
portal
allows
the
maximum
is
the
three
levels
can
be
and
then
all
combinations.
C
So
if
there
are
some,
if
there
is
policy,
for
example,
I
just
give
one
example,
which
the
current
protocol
cannot
support.
For
example,
you
want
to
say
I
want
to
allow
allow
any
principle
except
or
yeah,
accept
the
principle
or
accept
the
principal
name
equals
to
one
two.
Three
and
the
IP
address
equals
to
something.
So
basically,
you
have
not
Then
followed
by
and
with
the
different
condition
principle
plus
IP
address.
F
F
C
F
If
the
control
plane
evolves,
which
I
have
never
heard
in
four
years,
anyone
suggesting
any
changes
to
it,
then
we
can
also
evolve
the
data
plan
API,
it's
yeah.
C
And
the
other
thing
is
sorry.
Let
me
finish.
Country
Syrian
policy
actually
support
four
level
of
and
on
combination.
So
if
we
just
limit
it
to
three
levels,
yeah
I'm
concerned
that
yeah.
If
there
is
the
name,
we
just
limited
Eternal
to
Easter
Obsession
policy,
not
for
other
policies,
I,
don't
know
if
that's
a
goal
or
just
supporting
is
the
organization
policy.
It's
still
it's
enough.
It's.
D
I
I
think
Network
policy
is
also
something
we
may
need
to
implement,
but
that's
perfectly
fine
and
they
don't
think
it's
limited
by
anything.
However,
I
completely
agree
with
John
I
mean
if
we
want
to
extend
each
year
with
any
other.
You
know
extra
policy.
We
need
to
have
a
proper
design
to
figure
out
what
we
want,
what
how
we
can
be
implemented
efficiently,
how
it
scales
you
know,
and
then
we
can
extend
the
Proto
with
whatever
is
needed.
What
is
the
minimum
change
to
extend
it?
D
The
current
problem
with
the
genetic
hardback
is
that
it's
very
difficult
to
optimize
I
mean
at
least
with
a
more
restricted
system.
We
can
use
the
better
algorithms
and
we
can
we
can
optimize
it
without
being
you
know,
having
to
implement
a
completely
flexible
genetic,
arbitrary.
D
To
I
don't
know
what
it's
simple
to
do
is
not
to
implement
naively,
but
it's
not
as
simple
to
implement
efficiently
I
mean
to
you
know
to
to
schedule
one
to
to
make
sure
that
everything
gets
is
done
with
minimum
allocation
and-
and
you
know
using
wait.
C
The
today
is
pretty
efficient
right,
I
think
we
have
done
extensive
performance
tests
also
on
envoys,
whatever
foreign,
so
yeah,
I
I,
don't
actually
think
the
performance
is
a
problem.
D
For
the
use
case
we
have,
which
is
basically
a
number
I,
don't
know
how
many
n
per
because
right
now
the
rules
are
applied
on
side
cut
and
sidecar
typically
only
implements
a
policy
selected
by
that
workload,
not
the
entire
namespace
or
in
the
case
of
gateways
entire
mesh.
D
They
have
a
lot
of
policies,
so
I
I
mean
the
point.
Is
it
can
be
good
enough
for
what
we
have
today,
but
I?
Don't
think
a
completely
genetic
expression.
Language
I
mean
with
infinite
flexibility,
can
be
implemented
as
efficiently
as
something
that
is
far
more
restricted
in
scope.
That's
my
my
hopes
up
current
one
yeah.
C
C
F
F
In
fact,
I
would
argue
it's
simpler,
given
that
it's
a
smaller
API
surface,
it
also
reuses
much
of
the
same
code.
It's
also
decoupled.
Like
it
I
agree,
it
is
not
as
fully
flexible
but
I.
Don't
think.
That's
a
benefit.
I
think
that's
actually
a
downside
of
an
API.
C
The
flexibility
I,
don't
think
it's
the
downside
right.
If
you
in
the
future,
you
want
to
involve
like
a
introduce
other
semantics.
We
want
to
support.
You
basically
need
to
change
both
control,
plane
and
data
plane.
F
D
Agree
with
John
I
mean
it's,
it's
it's
it's
it's
it's
cleaner,
simpler
and,
and
more
likely
to
to
to
to
to
to
to
be,
you
know
to
work
better
with
a
simpler
implementation.
No.
C
This
one
is
simpler
in
my
mind,
right,
it's
a
if
we
need
to
introduce
the
not
match
in
other
level
right
now,
the
only
not
matches
at
the
at
the
lowest
level
yeah.
Maybe
I
can
bring
up
the
other
product
yeah.
Then
it
will
be
difficult
to
change
the
protocol,
but.
F
C
C
F
C
F
C
Yeah
I
mean
the
current
one
definitely
can
y'all
can
can
translate,
can
convert
all
those
policy,
because
it's
designed
to
do
that.
Yeah
I'm,
just
saying
with
the
new
Proto,
is
actually
can
support.
Not
only
the
ECR
selection
policy
but
can
go
beyond
right.
F
So
I
guess
the
fundamental
question
is:
do
we
care
about
supporting
future
apis
beyond
the
Eco
RC
and
network
policy,
or
do
we
not?
If,
if
we
do
care,
then
I
agree?
We
should
do
this.
If
we
don't,
then
I
think
that
we
should
stick
with
the
current
one.
Yeah
I,
don't
know.
If
that's
does
everyone
agree
with
that
assessment,
or
is
there
more
nuanced.
A
I
yeah
I
would
just
say
not
at
the
first
pass
like,
for
instance,
we
haven't
how
many
users
do
we
have
to
say
we
need
the
enhancement
to
the
existing
layer
for
RC
policy
for
cycle
okay.
So
that's
the
first
question
we
ask
which
we
haven't
heard
many
users
I
think
it's
pretty
stable.
If
I
remember
correctly,
we
just
promote
that
to
stable,
so
for
ambient
I
mean
we're
doing
this
in
the
experimental
Branch
right
we
want
to
implement
the
existing
API
first
I
think
that's
has
always
been
a
lot
of
talk
priority,
meaning.
C
D
D
A
Can
you
can
you
maybe
link
some
reference
to
the
ceiling
policy
that
we
couldn't
support
in
or
what
translated
version
of
velocity
policy
so
that
we
have?
You
know
the
reference
we
can
refer
to.
C
A
Starting
point:
unless
you,
you
can
show
us,
like
showstopper
of
some
ceiling
policy,
that
we
just
couldn't
support.
A
All
right
thanks,
everybody
for
joining
I,
think
that
is
the
last
item
on
the
agenda
and
thank
you,
Mitch
and
Lily
for
presenting.