►
From YouTube: Ambient Mesh WG Meeting 2023 02 15
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
All
right,
so
first
up
is
Eton
and
Lynn.
B
Does
not
here
I
guess
by
the
way
I
haven't
been
able
to
move
it
to
our
istio
Community
Drive,
mainly
because.
A
I
I'm
working
on
reclaiming
the
that
account,
but
I
have
not
heard
back
from
the
the
Google
internal
tool,
so
I'm
gonna
paint
them
again.
A
Meanwhile,
let's
see
maybe
I
can
actually
move
this
over
to
the
Community
Drive.
B
All
right
yeah,
so
this
is
a
proposal.
That's
trying
to
I
think
it's
a
kind
of
a
related
to
what
John
was
presenting
the
the
other
week
last
week
about
multi-cluster.
B
So
this
proposal
we
have
a
requirement
of
the
producer
service,
which
is
also
called
server
service,
who
wants
to
expose
itself
as
a
single
global
hostname
so
using
an
example
of
my
server.
That
is
your
dial
as
a
host
name
and
today,
to
do
that.
B
Sorry
multinos
needs
I
apologize
for
that
today.
To
do
that,
they
typically
would
specify
a
service
entry.
Well,
they
would
specify
the
host
name
and
the
and
the
and
then
the
poster
resolution
and
you're
using
workouts
to
lecture
to
select
some
of
the
local
local
application
foreign.
B
So
what
we
are
proposed,
so
this
problem,
so
still
in
the
problem
section,
this
problem
is
getting
a
little
bit
more
complicated
in
many
of
our
user,
would
not
only
create
a
service
entry
to
declare
their
Global
host.
They
would
also
apply
routes
policy
such
using
virtual
services
in
this
example
to
combine
that
apply
a
route
policy
on
top
of
that
Global
host,
my
server.incio.io,
for
instance.
B
Yeah,
so
that's
basically
how
it
works
today.
So
what
we
asked
is
there
a
hint
sorry,
I
thought
you
see,
yeah.
C
C
B
All
right
so
so
the
requirements
is
essentially.
How
do
we
bring
this
particular
same
function
to
allow
producer
site
service
to
declaw
a
global
hostname
onto
ambient?
Well
user
can
still
using
similar
API
as
today.
Is
there
another
hand.
B
Yeah
and
one
of
the
other
requirements
is
users
should
be
able
to
do
this
for
single
cluster
if
they
choose
to
declare
a
global
host
name
or
they
should
be
able
to
do
so.
If
their
services
spare
multiple
cluster,
they
should
be
able
to
decloud
the
same
Global
hostname
for
multiple
clusters,
and
this
should
be
supported
regardless,
whether
they
are
using
isolated
control
play
or
they're
using
Shield
control,
plane.
B
So
we're
at
this,
what
we
are
proposing
is
I
I.
Think
you
guys
recall.
Last
week,
Kevin
from
our
team
proposed
istio
DNS
solution
right,
so
we're
proposing
to
leverage
the
issue
DNS
solution
to
have
the
easier
DNS
to
resolve
the
the
customer
hostname
my
server.co.io
to
a
whip
and,
and
then
the
client
Z
tunnel
can
figure
out
the
potential
Next
Step.
B
So
the
potential
Next
Step
could
be
a
waypoint
proxy
if
the
server
has
a
waypoint,
proxy
and
and
the
way
to
explicitly
to
bind
we're
proposing
to
the
way
to
exclusive
to
find
a
global
host
to
a
waypoint
can
be
through
similar
way.
That
John
has
been
socializing
in
the
community
layer,
7
RC
policy,
how
the
layers
MRC
policy
can't
bind
to
a
waypoint
proxy.
So
we
we
believe
it
could
be
done.
B
Similarly,
for
my
API
perspective,
where
users
can
just
put
in
the
parent
ref
and
then
refer
to
one
or
more
particular
Waypoint,
they
want
they
want
to
bind
This
Global
hostname
too
yeah.
So
that's,
essentially
what
we're
proposing
I
think
is:
go
ahead.
C
So
I
I
mean
I,
I
looked
I
looked
at
John
also
before
and
I
look
at
his
proposal
and
similar
proposals.
It's
it's
an
areas
that
I'm
particularly
interested
in
it
may
help
a
lot
to
split
this
into
two
or
three
different
sub
proposals.
I
mean
one
for
DNS
and
that's
already
separated
I.
Believe.
Yes,.
C
C
Yeah,
so
we
can
discuss
them
separately,
but
but
the
main
thing
is
is
in
in
your
proposal
and
how
you
configure
it
it's
a
bit
different
from
from
what
I
would
do
or
I
would
like
to
see.
Normally
if
we
use
ambient,
probably
Waypoint
will
be
required
for
this
case
and
the
normal
way
to
configuration
ambient
to
begin
with
a
Gateway
object
using
kubernetes
Gateway,
where
you
can
specify
hostname
already.
You
can
specify
the
IPS
well
I
believe
we
can
relatively
easily
do
the
equivalent
configuration
with
the
service
center.
C
So
we
don't
need
the
verbose.
You
know
service
entry
destination,
all
the
other
stuff.
We
can
derive
it
only
from
from
okay
to
expect
and
that's
how
Gateway
is
supposed
to
work.
I
mean
if
your
space
specify
example.com
as
a
gateway.
A
vendor
should
be
able
to
create
the
DNA
Centric
get
certificates.
Do
whatever
is
necessary
to
to
make
it
happen.
B
Yeah
I
think
I
understand
what
you
were
proposing
so
and
let
me
just
replay
it
back,
just
making
sure
I
am
the
same
way,
you're
saying
so.
Basically,
you
are
saying
instead
of
extending
our
existing
service
entry
API
in
this
case,
user
will
be
specified
a
Gateway
resource
and
that
Gateway
resource
would
be
able
to
declare
a
global
hostname,
which
today
it
is
and
potentially
that
Gateway
resource
would
bind
to
a
particular
Waypoint,
because
today
the
Gateway
is
not
explicit,
I
guess
a
Gateway
resource.
B
Today
you
can
specify
a
reference
which
the
references
typically
Ingress
Gateway,
but
in
this
case,
could
potentially
bind
to
a
waypoint
proxy.
B
C
C
B
Do
anything
the
only
thing
I'm
not
sure
is,
with
the
work
of
selector
be
covered
through
the
Gateway.
C
No,
but
you
don't
need
to
work
on
Center,
because
because
second
riff,
so
that
that
goes
to
http
routes
and
backendrive,
because
again
you
you
have
a
waypoint
example.com
is
a
DNS
name
bound
to
the
Waypoint.
But
it's
not
necessarily
one
service
that
will
respond
to
this.
You
may
have
slash
admin
going
to
one
service.
I
mean
that
that
limitation
is
a
current
model,
that
you
bind
the
hostname
to
a
single
service,
but
with
a
waypoint
you
bind
the
hostname
to
the
Gateway
and
the
Gateway
routes
as
necessary.
B
C
B
C
How
about
we
solve
it
with
Waypoint
first,
because
that
would
be
the
most
common
use
case
and
for
S7
probably
have
other
policies,
and
we
may
at
some
point
optimize
it.
So
if
you
don't
have
any
other
policy-
and
you
have
a
single
yeah
host
names-
definitely
don't
make
sense
for
ll4,
but
it
is
possible
to
optimize
it.
So,
in
some
cases
where
there
is
no
policy,
no
routing,
no
nothing.
E
B
Okay,
so
maybe
that's
there's
a
lot
of
agenda
on
today's
topic.
That's
I
think
about
what
costan
is
proposing
as
a
a
slight
difference:
semantics
offline
and
and
then
we
can
come
back
to
the
group.
E
Would
you
mind
on
the
on
the
dock?
No
I
I
just
want
to
make
sure
I,
don't
forget
if
you
could
just
oh
yeah,
if
you
just
commented
on
the
doc
that
that
would
be
really
helpful.
So
we
have
so
we
just
have
it
written
down.
E
A
C
C
But
one
last
moment
there
is
still
a
discussion
about
how
he
verifies
the
DNS
ownership
or
permission
to
use
the
example.com
in
that
particular
namespace,
and
that
is
tied
to
I
mean
it's
a
more
generic
problem
than
this.
It's
not
okay,
I
mean
it
may
be
something
you
need
to
do
the
gateways.
It
may
be
some
things
that
we
can
use
to
to
to
assign
stun
DNS
stands
for
the
certificate.
So
no
one
is
your
clients
can
talk
with
that.
So
there
is
it's
a
it's
a
pretty
interesting
discussion
independently.
E
B
Okay,
cool
yeah
constantly
you
should
have
permission
to
comment.
Please
share
your
thoughts
there,
but
thanks
for
you
know
raising
this
with
that,
Francis
I
think
we
are
ready
to
pass
to
the
next
topic.
Given
this
like
topic
today,.
F
Yep
hi
everybody,
let
me
see
so
I-
have
a
PR
app.
That
allows
adds
some
sort
of
internal
extension
points
for
Z
tunnel,
allowing
you
to
kind
of
customize
things
on
the
data
path,
and
we
wanted
to
see.
We
wanted
to
make
sure,
obviously
solo
made
sure
that
this
proposal
works
with
our
use
cases.
We
want
to
save
this
other
members
in
the
community
that
want
to
take
a
look
and
make
sure
it
it
works
with
their
use.
Cases
do
keep
in
mind
that
this
is
not
a
user-facing
API.
F
F
G
I
think
I
took
a
quick
look
at
it,
I
mean
it.
It
looks
generally
fine,
it's
pretty
simple
and
all
that
I
think
my
my
big
concern
is
that
extensibility
is
a
big
topic
and
you
know
I
I
think
we
as
a
as
a
group
really
aren't
sure
what
the
requirements
are
for
it.
G
Yet,
as
far
as
like
you
know
what
Advanced
capabilities
we
might
actually
want
to
do,
and
whether
or
not
this
API
is
going
to
be
sufficient,
you
know,
and
and
if
we
get
down
the
road
and
find
that
it
isn't
sufficient
for
some
reason,
and
if
we
have
to
implement
something
else,
then
we
start
to
layer
on
different
extension,
Point
mechanisms
and
it
starts
to
become
you
know,
kind
of
crafty
and
and
potentially
problematic,
I
I.
G
Think
for
now
my
my
feeling
is
that,
like
yeah,
it's
pretty
simple
and
maybe
for
now
until
more
teams
start
to
you
know,
put
together
their
their
requirements
that
that,
maybe
you
guys
just
kind
of
like
maintain
your
own
Fork
and
and
kind
of
kind
of,
do
it
there
for
now,
because
you
know,
as
you
go
forward,
you
might
actually
find
new
requirements
for,
for
extension,
points
as
well.
G
So
so
you
you
can
grow
that
internally
and
and
maybe
maybe
somewhere
down
the
road
we
can
actually
put
together
a
you
know
like
a
design
dock
for,
for
how
extension
should
should
be
done.
Does
that?
Does
that
make
sense.
F
So
my
counter
argument
to
that
is
what
I
said:
I
kind
of
see
it
like
like
the.
If
you
look
if
you've
done
Android
development,
then
you'll
know
that
the
internal
interface
that
Envoy
uses
for
implementing
filters
there's
no
backwards
compatibility,
guarantee
there
right
and
as
a
vendor.
It's
kind
of
your
responsibility
to
keep
up
with
master.
F
So
I
think
this
gives
us
the
flexibility
that
you
know.
If
we
do
this
and
find
out
that
we
made
a
mistake,
I
I,
don't
think
we
need
to
be
concerned
on
creating
backwards,
incompatible,
changes
right,
I,
don't
think
we
need
to
have
this
code
kind
of
be
maintained
in
Legacy
format
and
guarantee
compatibility
to
all
backwards
version,
because
it's
not
a
user-facing
API.
G
Api
but
extension
is
a
big
topic
and
I
think
a
lot
of
people
will
have
opinions
like
I
I,
think
I,
don't
think
a
PR
is
the
right
way
to
even
approach
this
topic,
I
think
like
a
RFC,
slash,
design,
doc,
where
you
know
it's
going
to
take
a
while
to
to
get
consensus
on
on
what
this
sort
of
thing
should
even
be,
but
yeah
I,
don't
think
a
PR,
as
maybe
the
right
first
step,
John.
D
Sorry
I
thought
tonight
go
ahead.
Yeah
I
was
gonna
kind
of
agree
like
essentially,
what
we're
adding
here
is
the
ability
to
like
this
pier
doesn't
benefit
users
right.
It
benefits
vendors
and
we're
trading
off
complexity
of
the
project
for
Simplicity
on
vendors,
which
is
something
that's
oftentimes,
a
good
trade-off
to
make,
but
given
that
there's
only
that
there's
multiple
vendors
that
are
interested
in
ambient
and
so
far
this
only
helps
one
vendor
it.
It's
not
clear
that
this
is
the
right
time
to
make
that
trade-off
right.
H
Which
is
I
think
to
say
that
we
are
all
interested
in
having
an
extensibility
mechanism.
But
maybe
you
want
to
take
a
little
bit
more
time,
understanding
our
own
requirements
and
designing
it
before
pushing
up
to
master.
C
Yeah
I
was
going
to
say
almost
the
same
thing,
but
with
with
a
Twist,
maybe
I
think
it's
highly
desirable
to
have
an
extension
mechanism
that
prevents
what
we
did
in
this
qrd,
where
and
in
HBO,
where,
basically,
we
just
crammed
a
lot
of
stuff
that
is
kind
of
specific
and
and
experiments
of
work
into
one
binary.
C
So
I
think
it's
super
valuable
to
plan
at
some
point
to
have
an
extension
mechanism,
but
I
completely
agree
that
it
needs
more
thinking
and
and
definitely
needs
some
stronger
backward
compatibility
because,
whatever
is
doing
is
not
necessarily
the
best
example
in
terms
of
you
know:
kind
of
making
banking
changes
and
creating
problems,
so
we
should
be
committed
to
it.
C
We
should
be
very
clear,
like
there
was,
was
interfaces
and
and
all
those
apis
I
actually
think
the
process
used
by
was
I
mean
a
lot
of
those
CPS
is
very
close
to
what
we
should
for
as
well,
because
you
you,
if
you
expect
multiple
vendors
to
use
it,
you
have
to
have
some
respect
for
them
in
terms
of
you
know
not
requiring
them
to
make
those
changes.
I
C
J
So
I
get
I,
get
the
the
kind
of
impulse
to
try
to
have
something.
That's
more
kind
of
formally
designed
I'm,
also
wondering
if
there's
a
way
that
we
can
caused
it
to
happen.
On
a
like,
more
concrete
timeline
and
I'm,
specifically
wondering
like
for
the
aviatrix
folks,
I
mean
it
sounds
like
solo
has
kind
of
a
sense
internally
of
what
kind
of
extensions
they
want
to
do.
J
I
I
can
say:
Google
is
probably
going
to
maintain
a
fork
or
we're
certainly
not
anywhere
close
to
knowing
what
kind
of
extensions
we
want
to
do.
But
I'm
wondering
if
the
avatrix
folks
have
a
sense
of
when,
when
they'll
have
some
resolution
on
that,
because
if
it's
like
okay
aviatrix
in
the
next
month
or
two
is
going
to
know
what
kind
of
extensions
they
want
to
do
and
then
maybe
those
are
the
two
big
vendors
that
might
want
to
do.
J
Extensions
and-
and
we
can
have
YouTube
talk
and
come
up
with
a
design-
and
maybe
this
this
patch
ends
up
merging
in
two
months
or
something
like
that.
That
feels
like
a
better
situation
than
kind
of
indefinitely,
causing
any
extension
mechanism.
So
that's
that's.
My
question.
Thought.
H
That's
a
very
fair
response
like
we
don't
want
to
hold
things
up
indefinitely,
certainly
Nathan
I'll.
Let
you
weigh
in
on
this
too,
but
my
gut
says
two
months
is
about
right:
that
we
should
be
able
to
have
a
pretty
concrete
recommendation.
F
C
So
you
know
what
what
feature
are
you
trying
to
hook?
That
cannot
be
done
in
my
investment?
Is
it
something
that
the
customer
wants,
or
is
it
a
proprietary
stuff
that
you
want
to
add
I
mean
because
that
would
be
the
best
place
point
to
create
a
hook
when
one.
I
C
C
D
Makes
it
less
compelling
it's
one
thing
if
someone
was
pitching
this
because
they
want
to
interact
with
say,
like
custom,
Google
features
or
something
that's
clearly
vendor
specific.
But
if
your
motivation
is
to
optimize
the
data
path,
which
is
something
that
everyone
would
benefit
from
and
you're
keeping
that
in
your.
F
C
First,
one
now
and
and
it's
very
legit
I-
don't
think
it's
it's
not
anything
wrong
with
a
vendor
doing
optimizations,
but
but
again,
I
highly
doubt
that
only
this
hook
will
allow
you
to
do
optimization.
You'll
get
to
Fork
it
anyway,
and
I
can
bet
that
it
will
not
be
sufficient
to
have
only
this
hook.
If
you
want
to
do
real,
optimization,
so
I'm
all
for
vendors
optimizing,
but
some
realistic.
You
know
yeah.
H
H
You've
all
were
happy
to
work
with
you
and
find
where
our
interests
overlap
and
come
up
with
an
extensibility
framework
cost
on
your
right
that
this
will
result
in
either
a
fork
or
or
certainly
a
private
repository
for
extensions
on
either
of
our
parts,
but
even
in
the
case
of
a
fork
having
those
hook
hook,
points
be
somewhat
more
stable,
more
predictable
and
designed
for
that
interaction
should
mean
that
the
cost
of
maintaining
those
Forks
is
reduced.
With
John
to
your
point,
we
would
intend
minimal
complexity
for
other
users
as
a
result.
B
All
right
we're
so
called
back
on
this
topic
in
two
months.
Mitch
I
think
you
are
next
is
right.
Yes,.
C
H
Can
you
all
see
the
API
proposal
dock
here.
H
All
right
so
the
background
on
this.
About
a
month
ago,
we
had
some
conversations
around
how
Waypoint
upgrades
would
happen
and
when
we
would
decide
to
upgrade
in
a
waypoint,
and
the
decision
at
the
time
was
to
use
something
very
consistent
and
similar
to
what
we
have
inside
car
mode.
That
is
that
tags
and
revisions
will
control
what
version
of
the
Waypoint
is
running
the
same
way
that
tags
and
revisions
control.
What
version
of
the
sidecar
is
running,
with
the
exception,
of
course,
that
a
waypoint
is
an
actual
deployment.
H
So
there's
a
little
life
cycle,
differences
there,
but
overall,
something
very
consistent,
look
and
feel
upgrading
from
one
to
the
other
should
be
very
consistent.
We've
got
that
partially
implemented
today
in
the
ambient
branch
in
particular.
What
was
implemented
so
far
has
been
that
it
didn't
used
to
be
the
waypoints
upgraded
at
all.
You
can
upgrade
into
a
control
plane,
and
it
would
just
see
that
the
waypoints
exist
and
leave
them
be
now.
It
will
upgrade
them
to
the
new
version.
H
If
you
make
any
changes
to
the
way
point
template
those
will
automatically
be
pushed
out
so
that
that's
looking
pretty
good,
we
need
a
little
bit
there's
a
little
bit
left
to
do
that.
I've
not
taken
on
right
away
in
terms
of
tags
and
revisions
and
I'll
get
into
why
here
so
tags
and
revisions
are
a
concept
from
sidecar
model
by
which
each
of
our
control,
plane
versions
has
a
unique
name
called
a
revision
and
each
workload
through
either
namespace
labels
or
workload.
Labels
is
going
to
opt
into
a
revision
or
a
tag.
H
A
tag
is
just
think:
a
Sim
link
to
a
revision,
it's
an
alias
which
makes
things
a
little
bit
easier.
Let's
say
you
have
revisions,
1.2
and
1.3.
You
might
have
tags
first,
wave,
second
wave
third
wave.
Fourth
wave,
you
are
going
to
adjust
those
tags,
one
at
a
time
to
point
to
review
from
reversion
one
two
now
up
to
version
one
three
which
will
cause
things
to
upgrade.
H
The
relationship
of
revisions
and
tag
is
represented
here,
and
this
DOD
has
a
revision.
Today,
a
tag
is
actually
ephemeral.
There
is
no
tag
resource
in
istio.
You
can't
Cube
cuddle
get
tags,
we
have
an
istio
control
command
for
creating
listing
and
updating
tags,
but
what
it
actually
creates
in
the
cluster
is
a
mutating
web
hook,
and
the
reason
for
this
is
that
mutating
web
hooks
are
how
we
create
sidecars
today.
So
it
was
a
very
natural
way
to
represent
both
tags
and
revisions
in
sidecar
mode.
H
As
we
imagine,
moving
forward
to
ambient
Mode
mutating
web
hooks
will
no
longer
be
required
for
a
transitionary
period
where
a
user
has
side,
cars
and
waypoints
they'll
be
required,
but
as
soon
as
the
user
no
longer
wants
to
use
sidecars
or
if
we
have
a
green
field,
installation
which
strictly
uses
waypoints,
there
will
be
no
reason
to
have
no
technical
reason
to
have
this
mutating
web
hook
config
in
the
cluster.
H
As
a
matter
of
fact,
it
represents
something
of
a
security
concern
for
a
lot
of
our
users,
and
we
would
actually
need
to
be
running
the
server
side
of
the
web
hook
within
istiod.
In
order
to
not
break
stuff,
it
would
do
nothing
but
still
that's
extra
resources.
So,
ideally,
we
would
like
to
not
have
this
mutating
webhook
config
as
soon
as
sidecar
mode
is
disabled.
H
Additionally,
if
you're
using
gitups,
which
is
you
know
something
that
we
want
our
users
to
do
more
and
more
looking
at
your
git
repo,
it's
very
difficult
to
see
what
tags
or
revisions
exist.
They
exist
as
mutating
web
hook.
Config
objects,
which
are
quite
large
I've,
actually
got
an
example
down
here.
This
is
one
of
our
mutating
webhook
configurations
that
you
might
actually
the
the
secret
part
wouldn't
be
stored
in
git,
but
it's
huge-
and
this
is
just
one-
this
represents
I-
believe
one
tag
I'd
have
to
go
and
check.
H
What
are
we
representing
here?
Yes,
the
default
tag.
This
is
really
unwieldy
to
edit,
if
I
wanted
to
say,
take
this
tag,
which
is
pointing
at
a
certain
revision
and
point
it
at
another
revision.
It's
not
clear
how
I
would
do
that.
The
the
truth
is,
you
can
use
the
istio
control
command
to
do
that,
but
that's
not
necessarily
super
compatible
with
our
get
Ops
load
of
operation,
we'd
like
to
be
able
to
just
go
and
edit
this
file
to
modify
it.
H
To
that
end,
my
proposal
is
that
we
create
a
tag
crd.
The
tag
crd
has
three
Fields
name
revision
and
auto
name
space.
The
naming
of
this
last
field
probably
could
use
a
little
bit
of
improvement
and
that
inside
car
mode,
when
we
have
these
tags,
we
use
it
to
create
mutating
webhook
configs
on
the
Fly.
H
When
we
are
not
using
sidecar
mode,
those
mutating
web
hook,
configs
would
not
be
created,
but
the
the
upside
is
that
in
either
mode
in
order
to
change
what
revision
a
given
pod
is
a
member
of
you
can
update
the
tag
object
and
that
will
get
executed,
whether
it's
for
waypoints
or
for
sidecars
I'll.
Give
John
has
raised
security
concerns
about
this
proposal.
In
particular.
Today,
users
can
create
the
mutating
webhook
config
using
Helm,
rather
than
allowing
sdod
to
do
so.
That's
not
the
default
Behavior
by
default
is
DoD.
H
Has
the
permission
to
create
mutating
web
hook
configs,
but
some
of
our
more
security
conscious
users
are
uncomfortable
with
that,
so
they
disable
that
and
create
the
mutating
web
Hook
configs
by
hand.
So
my
proposal
is
that
we
carry
that
mode
forward,
allowing
users
who
don't
want
to
use
this
tag
API,
but
instead
want
to
handcraft
webhook
configs
to
still
do
so.
Moving
forward
for,
like
a
high
security,
sidecar
mode,
all
other
modes
would
automatic
or
would
allow
use
of
the
tag.
Api,
Costa
and
I
see
you've
got
a
question.
Yeah.
C
Is
a
whole
revision
proposal
was
not
necessarily
original.
It
was
based
on
what
K
native
is
doing
and
what
Easter
itself
is
doing
for
version
and
traffic
shifting,
and
it
was
done
because
history
is
kind
of
the
control
plane
and
it
was
most
convenient
and
easiest
way
to
do
it,
but
not
necessarily
the
best,
because
we
already
have
apis
exposed
to
do
traffic,
shifting
HTTP
route
and
and
so
we
could
achieve
almost
the
same
result
using
the
existing
apis
and
putting
a
Gateway
in
front
of
his
qid,
which
is
also
used
for
other
purposes.
C
C
D
I
think
I
mean,
regardless
of
whether
I
agree
or
not
back
in
the
day,
revision
really
meant
what
you
connected
with
XDS,
but
now
it
means
a
bit
more
right,
like
we
have
a
specific
Vision
actually
going
and
writing
deployments
for
the
waypoints.
D
So
just
having
a
Gateway
doesn't
solve
that
problem,
because
it's
the
opposite
direction
of
communication,
E
Studio
D,
is
deciding
whether
it
should
take
some
action
in
the
cluster.
Now
it
could
go
and
read
those
HTTP
routes
and
kind
of
reverse
it.
Instead
of
reading
this
tag
potentially,
but
it's
not
just
as
simple
as
it
used
to
be,
where
you
know
you
just
have
to
control
traffic
to
East
2D
apologies.
C
C
Misunderstood
this,
the
Gateway
would
be
for
Z
tunnel
itself
and
for
for
proxy,
less
and
other
use
cases
I
mean
the
waypoints
are
clearly
managed
by
Studio
D
stud
who
is
winning
the
election
will
definitely
be
able
to
do
whatever
it
was,
and
we
don't
need
an
extra
API.
For
that
I
mean
whatever
rollout
for
sqd
is
done.
D
C
H
So
Gateway
class
specifies
that
this
is
an
istio
ambient
Gateway
or
a
waypoint.
It
does
not
specify
which
version
of
istio
that
is
present
in
the
cluster
will
control
that
particular
Waypoint.
Why.
H
Another
reason
is
that
you
would
need
to
go
and
change
the
name,
the
Gateway
class,
on
every
Gateway
that
you
own
in
order
to
perform
an
upgrade,
which
is
not
what
we
want
to
do
here.
That's
the
whole
purpose
of
tags.
H
Exactly
this
proposal,
it
has
it'll,
have
a
label
just
as
existing
workloads
do
okay.
B
B
C
C
Logics
that
we
need
to
have
in
sqld
to
be
able
to
you
know.
Yes,
you
have
a
preference
for
for
the
old
version,
but
when
you
upgrade
this
to
a
d
once
it
removes
all
these
qrds,
the
new
one
needs
to
take
over.
So
there
is
a
mix
of
you
know.
How
do
you
control
where
it
goes,
and
how
do
you
control
who
instantiate
and
and
upgrades
so
your
idea?
How
do
you
do
this
upgrade?
C
H
C
I
I'm
not
saying
which
it's
a
better,
it's
a
very
good
design.
That's
what
we
have
done!
It's
it's!
What
we
recommend
to
our
user
to
do
for
their
own
application
is
I'm,
saying
that
we
need
to
be
a
bit
more
flexible
and
less
strict
about
a
lot
of
pizza
mistakes
we
did
with
the
web
hook
and
with
the
fixed
URL,
so
istio.
This
should
have
some
flexibility
to
take
over
a
waypoint
and
and
win
the
election
and
do
code
wise
management,
instead
of
being
very
strict
to
the
labels.
H
H
That
being
said,
we
can
still
very
much
do
that
with
this
existing
tag
proposal,
and
we
can
do
that
with
sidecars
as
well.
There's
we
can
have
that
be
consistent
across
ambient
and
sidecar
mode
and
istio
without
too
much
difficulty.
H
H
Okay,
you're
suggesting
we
don't
the
the
yeah
we'd
have
to
discuss
the
sidecar
side
of
it.
I
mean
those
are
going
to
be
around
for
quite
a
long
time
and
we
do
expect
users
to
need
to
have
smooth
transitions
where
both
sidecars
and
ambient
live
side
by
side
for
an
extended
period
of
time.
So
some
degree
of
consistency
will
be
required,
but
we
can
debate
exactly
what
degree
of
consistency
that
is.
C
H
Yeah
yeah,
so
so
maybe
I've
been
on
Craigslist.
That's
what
this
proposal
is
intending
to
do.
We
need
a
way
to
represent
tags
for
waypoints.
That
is
not
mutating.
My
books,
ambient
should
not
have
mutating
web
hooks
by
default.
So
this
proposal
is
that
we
create
a
tag
crd
so
that
we
can
continue
using
that
same
logic
of
tags
and
revisions
without
needing
to
rely
on
web
hooks
for
ambient.
B
So,
given
the
time
maybe
custom
you
and
a
couple
of
other
people,
we
should
review
offline
because
I
think
only
John
reviewed
the
proposal
and
then
maybe
image
you
want
to
bring
back
to
the
workbook
meeting
next
week
as
well
to
cover
the
cycle
perspective,
and
then
we
can
rediscus
this
again
on
the
ambient
meeting
to
focus
on
this
ambient
portion.
Okay,.
C
Yeah
and
I
think
John
has
an
open
PR
to
to
make
some
changes
to
remove
the
web
hook.
Injection
I
was
just
reviewing
it
so
after
he
merges
it's
fairly
to
be
slightly
different.
D
Yeah
just
to
be
clear,
the
web,
the
Waypoint
code,
was
modeled
based
on
this
proposal
and
now
my
PR
is
moving
the
normal
Ingress
gateways
to
follow
that
same
Waypoint
code.
So
it
is
aligned
with
the
proposal
not
in
opposing
it,
but.
B
H
H
C
H
For
what
I
would
love
to
see
Carson
is
is
what
the
alternative
looks
like,
because
today
it's
represented
as
a
mutating
hook
and
I.
Think
you
and
I
both
agree
that
it
shouldn't
be
represented
as
a
mutating
web
hook,
an
ambient.
It
needs
some
representation.
So
we
should
talk
about
what
that
looks
like
okay,.
B
Okay,
great
yeah,
good
discussion.
We
still
have
one
more
topic,
I'd
like
to
move
to
next
Ben
I.
Think
you
are
here.
K
Yeah
in
this
comment
on
this
should
go
ahead
and
share
it
or
we'll
talk
through
it
yeah
it's
the
ambient
cni
approach,
I'll
go
ahead
and
share
that
I.
Guess
right.
So
this
is
kind
of
you
know,
based
off
of
the
Pro.
The
proposed
PR
I
think
Intel
has
out
to
add
evpf
based
redirection
to
ambient.
K
That
makes
sense.
I
guess.
The
thing
that
this
is
trying
to
talk
about
is
to
kind
of
discuss
the
approach
for
how
we
integrate
that
with
the
existing
cni
plug-in.
We
have
to
make
sure
that
we're
thinking
about
the
implications
of
that
the
current
approach,
I
believe
bakes,
the
ebpf
frogs,
which
are
kernel
space
c
programs
into
the
C
of
I
binary
right
so
that
and
again
right
from
wrong
Daniel.
The
way
it
works
now
right,
we've
got
a
cni
binary.
K
We've
got
a
cni
David
set
which
got
these
binaries
to
the
node,
and
then
those
binaries
you
know
are
hooked
into
the
cni
interface
and
actually
respond
to
containerdy
events
and
actually
mutate.
The
underlying
networking
stack
accordingly
right.
So
right
now
that
cni
plugin
just
does
IP
tables
right.
It
does
iptable
space
redirection
for
both
ambient
and
sidecar.
K
If
we
add
Epp
after
the
mix,
it
might
do
a
third
thing
which
is
evpf
only
for
ambient
I
believe
is
the
current
constraint.
I,
don't
think
we're
intending
to
support
ebpf
for
sidecars
right
now,
it's
an
entirely
so
essentially
it's
an
entirely
parallel
form
of
like
node
level.
Networking
stack
manipulation
that
exists
in
the
same
cni
plugin,
and
so,
while
that
might
make
sense
to
some
degree,
I
think
there's
some
concerns.
We
have
around
baking
the
actual
kernel
Space
Program
code
into
that
binary,
which
also
has
IP
tables.
K
Basically
right.
You've
got
two
parallel.
Networking
Stacks
one
of
those
networking
Stacks
has
now
has
kernel
space
code
baked
into
the
same
binary
and
changing
that
becomes
impossible.
Without
you
know,
patching
the
entire
cni
plugin,
potentially
messing
with
the
IP
table
stuff
or
whatever
else
right.
You
can't
just
change
the
progs
themselves,
the
kernel
space
stuff.
If
you
have
to
rev
the
kernel
space
stuff
and
replace
them,
you
want
you
know
whatever
else
you
want
to
do
there.
That
starts
to
affect
the
whole
cni
binary.
K
Even
if
you
don't
care
about
edbs
because
you're
not
using
ambient
or
you
don't
care
about
evf,
because
you're
using
IP
tables
or
whatever
it's
all
bound
to
cut
in
one
binary
and
becomes
kind
of
coupled
in
that
way,
so
that's
kind
of
what
I
wanted
to
talk
through
is
like.
K
Maybe
we
do
something
different
there,
such
that
at
least
the
kernel
space
progs
are,
you
know
not
packaged
in
the
cni
binary,
in
a
way
that
you
can't
change
them
without
shipping
a
whole
new
CMI
battery,
which
would
include
iptables
ambient
and
non-ambi
at
cni?
That's
kind
of
what
we're
talking
through
here.
There's
a
couple
of
approaches
right,
like
realistically,
like
I,
think
the
original
intent
was
to
avoid
creating
an
entirely
separate,
cni
plug-in
right
like
that,
would
be
the
really
really
formal
way
to
do
it
right.
K
You
have
one
istio
cni
plug
in
for
iptables,
and
you
have
one
for
ebpf
and
they're
chained,
using
the
cni
plugin
infrastructure
that
becomes
kind
of
a
burden
to
maintain
right,
because
then
you've
got
two
cni
plug-ins,
and
maybe,
if
you
don't
care
about
EPF,
you
don't
need
to
install
the
second
one.
But
if
you
do
need
to
support
both
scenarios,
you
have
to
install
both
and
they
can't
interact
in
weird
ways,
and
we
have
to
maintain
that
Upstream
that
sucks.
That
seems
like
it
sucks
to
me.
K
The
other
option
is
you
know
the
singular
CMI
plug-in
which
right
now,
like
I,
said
it
bakes
the
evpf
products
into
the
binary,
which
is
a
little
problematic
from
our
perspective,
because
then,
suddenly
the
cni
plug-in
has,
like
you
know
it's
bound
by
kernel
version
constraints
right
those
kernel
side,
progs
are
tied
to
specific
curl
versions
right.
So
if
I
want
to
say
use
a
specific
kernel,
API
I
have
changed
the
product
that
won't
change
anything
about
the
cni
plug-in.
K
It
won't
change
how
the
cni
plugin
interacts
with
the
EVPs
stuff
in
kernel
space,
but
I
can't
swap
out
the
progs
without
changing
you
know,
without
replacing,
without
essentially
patching
or
maintaining
patch
against
the
whole
cni
plug-in,
and
the
CIA
plugin
starts
to
inherit,
like
kernel
version
constraints
that
are
only
applicable
to
the
EVPs
side
of
things.
But
since
the
evdf
and
IP
tables
are
all
shared
in
the
same
plugin,
it
gets
to
be
a
little
messy
or
it
conceptually
could
get
a
little
messy.
So
that's
kind
of
why
we
want
to
talk
through.
D
D
Yeah
my
concern
is,
it
just
doesn't
seem,
like
any
other
reasons
to
split
it
are
compelling
and
they
add
cost
to
split
it.
You
know,
okay,
it's
like
there's
different
kernel
versions.
We
need
to
test.
That's
fine,
it's
just
as
easy
to
make
two
plugins
as
it
is
to
make
two
BPF
programs
or
one
plug-in
that
has
a
if
statement
in
the
BPF
program.
D
You
know
it
just
there's
a
reason
that
we
have
the
monolith
in
East
2D
right.
It's
because
while
there's
some
small
benefits
of
microservices
and
ultimately
in
a
product
like
Easter
but
just
adds
complexity,
it's
pretty
standard
practice
to
embed
EPF
programs.
In
the
thing,
that's
installing
them,
it
just
doesn't
I,
don't
see
any
real
benefits
of
this
massive
decoupling
and.
K
I'm
not
saying
I'm
not
saying
that
we
wouldn't
have
a
program,
that's
installing
the
evpf
product
that
was
saying
that
the
cni
plugin
itself
would
just
run
the
installer
program
as
opposed
to
it
also
being
the
installer
program
and
also
having
all
of
it
tied
together.
One
thing
which
is
a
little
weird
I
grant
you,
but
it.
K
K
Bsd
is
compatible
with
Apache
2,
so
I
think
we're
okay,
baking,
that
into
the
cni
plugin,
which
is
Apache
generally
speaking,
but
yeah,
but
again
it
makes
it
difficult
to
tweak
or
replace
those
prongs
without
patching
or
maintaining
patches
or
forking
the
whole
cni
plug-in
just
to
make
just
to
change
kernel
side
stuff,
which
the
CMI
plug-in
doesn't
strictly
care
about
right.
Obviously,
our
applicant
really
needs
to
do
is
attach
some
progs
to
fix
hooks.
That's
it.
K
K
I
know,
but
like
there's,
no
actual,
reason
why
the
cni
binary
should
need
to
change
for
that,
since
it
is
not
coupled
right,
there's
no
coupling
there
and
we
we
can
create
coupling
because
it's
easier
to
distribute
but
like
again
like
if
I
want
to.
You
know
if,
if
I
want
to
support
something
in
a
kernel
version,
that's
not
what
the
CMI
plugin
supports
like.
D
K
So
I
agree
that,
like
we
don't
have
that
constraint
elsewhere,
but
here
we
do
right,
we're
we're
actually
loading
things
into
the
kernel
that
depend
on
specific
kernel
versions,
having
specific
apis
in
place
and
that's
unique
so
far
for
us,
even
the
IP
tables
approach
doesn't
have
that
constraint.
It's
like
kernel
modules
right
in
a
way.
K
So,
like
that's
a
concern
for
you,
you
know
we
would
like
to
be
able
to
change
that
without
having
to
you
know,
do
the
whole.
We
would
like
to
easily
swap
those
things
out
without
necessarily
having
the
whole
CI
plug-in,
inherit
those
constraints
or
be
tied
to
those
things
or
have
you
know,
knock
on
effects
from
kernel
versions
or
whatever
anyway,
that
that's
the
thing
comment
on
it.
We
don't
have
to
come
to
the
decision
right
now,
but
like
that's
kind
of
where
we're
at
with
it
and
again
yeah.
B
I
Yeah
yeah,
so
from
my
point
of
view,
so
firstly,
the
current
ebpf,
the
the
kernel
version
requirement,
is
really
low,
so
it
means
you're
concerned.
You
just
mentioned
from
my
point
of
view:
it's
not
a
problem
because
we
are
not
using
very
new
kernel.
Bpf
helper
function
here
so
on
this
one
point
on
the
other
part
is,
you
know,
actually
currently
the
CI
code.
We
pick
in
the
cppm
program
here,
but
it
actually
has
a
clear
separation
here,
so
user
can
using
flag
to
control
whether
they
want
to
use
the
iptables
ibpm.
K
K
Even
if
they
don't
care
about
the
IP
table
side
right,
they
can't
change
the
EVPs
side
without
shipping,
all
the
thing
or
doing
the
whole
thing
and
as
far
as
the
kernel
versions
right
like
again,
like
yeah,
like
in
your
bar
you're,
using
some
you're
using
some
kernel
apis
that
allow
us
to
have
that
lower
bound
of
the
420
or
whatever,
which
you
know.
K
We
may
even
know
this
works,
that's
not
LTS
but
whatever,
but
we
can't
but
like
if
we
wanted
to
use
some
of
the
faster
kernel
apis
in
our
ebbf
frogs,
then
that
suddenly
affects
how
we
test
that
whole
CMI
plug-in,
even
if
it
doesn't
change
anything
about
how
the
CMI
plugin
interacts
with
evf
or
what
what
it's
doing
right.
It
doesn't
matter
right.
That's
an
implementation
detail
of
the
product
itself.
We
can't
change
that
without
changing.
K
You
know.
The
actual
cni
plugin,
which
maybe
you
don't
even
like,
has
iptables,
is
doing
other
things
and
maybe
you've
already
been
using
that,
but
it's
all
bound
together,
so
it
kind
of
becomes
something
we
have
to
be
concerned
about
right.
Like
now,
the
cni
plugin
has
a
kernel
version,
support
itself
right
that
we
have
to
deal
with.
I
Yeah
but
but
the
problem
here
is,
you
know
if
you,
for
example,
up
with
your
ebpm
program
to
a
newer
version.
If,
even
if
you
split
it
out,
it
means
you
need
to
test
the
your
simulator
outage
version
here
right,
but
if,
if
you
I
mean
if
we
make
it
into
the
CI
binary,
but
if
you
don't
touch
it
I
mean
you
doesn't
touch
the
ebpn
part,
because
there
are
already
a
flag
here
to
to
control
you
to
switch
by
option
to
the
other.
I
So
it
means,
if
you
do
not
upgrade
ebpf
or
you
don't
have
the
need,
then
you
don't
need
to
to
touch
the
CI
binary.
So
it's
not
a
problem.
I
mean
if
even
if
you
split
out
in
terms
of
the
kernel,
you
know,
if
you
upgrade
your
BPI
ebvm
program
to
the
newer
BPI
helper
it
it
also
needs
your
work
to
you
know,
build
your
new
stability
version
binary
right,
so
it
doesn't
solve.
K
The
problem,
if
you
split
out
the
ebpf
frogs
in
their
installer
and
do
that
binary,
then
you're,
just
testing
that
ebpf
installer
binary
against
different
kernels.
You
don't
have
to
test
the
whole
CMI
plugin
right
and
it's
easier
to
replace,
just
or
twiddle
the
progs
in
that
plug-in
right
without
shipping,
your
own
Forks,
cni,
SEO,
cni,
Plugin
or
whatever
else
right.
So
like
that's.
The
other
question
is
like.
If
you
want
to
change
the
progs,
how
do
you
do
that?
K
That
is,
that
is
one
of
the
options
to
ship
your
own
cni
plugin,
but
that
that
just
shipping,
your
own
CMI,
plug-in
just
because
you
want
to
change
one
of
the
progs
in
a
way
that
doesn't
affect
the
CMI
plugin
seems
kind
of
gross,
but
I
also
again
like
that
could
be
a
sales
answer
right
that
we
don't
care
ship,
your
own
cni
plugin,
you
know
go
away
like
that
is
that's
valid,
like
that's
fine,
but
like
that's
kind
of
why
I
propose
this
because
I
think
there's
a
middle
ground
here
of
maybe
we
just
don't
bake
those
kernel
side,
those
kernel,
those
kernel
space
programs
into
the
CMI
plug-in.
K
K
D
K
J
Let
me
just
throw
in
there:
I
haven't
read
the
documents
this
might
be
in
there,
but
I
think
some
specific
examples
of
a
situation
like
what
the
before
and
after
of
this
picture
was
implemented.
Yeah.
That
would
help
like
I
I
could
imagine
it
actually
being
useful,
but
I
I,
think
I,
think
we're
kind
of
jumping
to
conclusions
about
I'm
I
think
I'm
jumping
to
conclusions
about
how
how
this
would
impact
the
ux
that
aren't
particularly
compelling
but
I
think
you
have
ideas
that
are
more
compelling
than
the
ones
in
my
head.
D
I'll
be
one
minute:
I
just
want
to
give
an
update
on.
What's
happened
in
the
past
tour
I.
Don't
know,
however,
many
weeks.
So
there
was
a
big
change
from
quat
recently
that
fixed
a
bunch
of
issues
and
kind
of
refactored,
the
XDS,
based
on
all
the
discussion.
We
had
the
previous
few
weeks
about
how
policies
attach
it's
still
not
100
done,
but
this
morning
we
got
most
of
the
policies
back
in
for
a
while,
like
obviously
policy
and
whatnot.
D
Was
it
working,
so
the
current
State's,
pretty
good
we're
still
working
on
finalizing
like
using
the
actual
apis.
We
agreed
upon.
The
other
thing
is
that
we're
starting
the
upstreaming
process?
D
So
if
you
see
PRS
or
laid
upstreaming
or
any
PRS,
really,
please
review
them
so
that
we
don't
end
up
with
like
three
different
Forks
that
we
try
and
keep
in
sync.
You
know
the
faster.
These
things
get
converged
the
better
for
everyone.
So
that's
it.
A
Thank
you
anything
else,
folks.