►
From YouTube: Ambient Mesh WG Meeting 2023 04 26
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
Me
a
second
yeah
go
ahead.
If
not
I,
can
we
don't
have
any
agenda
job?
Maybe
it
was
well
for
you
to
quickly
give
a
update
to
the
community
about
the
ambient
XDS
Evolution,
because
I
believe
there
are
some
updates
on
the
dock
just
to
highlight
folks
and
then
maybe
we
should
have
a
coupon
update
for
folks
who
went
to
Cube
car
and
then
Nathan
I
know
you
have
a
DNS
for
Ambience.
Are
you
ready
to
discuss
that
today.
B
A
E
D
Yeah,
so
we
talked
about
this
a
while
back
since
then,
we've
made
a
few
changes.
One
is
we
have
this
new
API
principles
section
which
is
instead
of
protobufs
kind
of
talking
about
what
problems
we're
trying
to
solve?
Why
we're
doing
things
the
way,
we're
doing
them
and
just
kind
of
General
explanation
in
English
of
the
API,
so
I
don't
know
if
it
probably
doesn't
make
sense
to
go
over
them
all
here.
D
This
is
useful
if
we
want
to
do
something
like
say:
oh
the
waypoints
at
example.com,
for
example,
and
we
just
reach
it
that
way,
I
think
it's
some
major
changes,
there's
a
lot
of
like
subtle
changes
as
well,
but
those
are
kind
of
the
the
larger
changes
I'm
happy
to
go
into
more
details
about
anything.
Anyone
has
questions
about
or
if
not
folks
can
review
the
doc
more
offline.
D
B
G
Yeah
so
I'm
I'm
trying
to
understand
what
functionality
this
design
would
unlock
for
ambient
were
we've
already
got
a
branch
cut
for
Alpha,
I,
think
or
we're
in
the
process
of
Branch
cut
for
Alpha
on
ambient,
and
these
changes
are
not
yet
in
place.
So
what
what
would
change
from
a
user
perspective
once
we
implement
this
design?
Yeah
it's
at.
D
B
D
B
D
H
D
D
H
D
D
Actually,
that's
probably
good,
because
I
think
the
uad
may
be
hard
because
we
may
represent
one
workload
like
what
if
it
was
a
workload
entry.
But
now
it's
a
pod
or
something
then
has
a
different
uid.
But
maybe
those
are
supposed
to
be
the
same
thing
or
service
is
more
likely
like
we
have
multiple
clusters,
so
I
yeah
I'm,
fine
with
that.
I
D
D
D
J
F
I
B
J
So
that
was
one
because
user
feedback,
the
other
one
would
just
you
know,
questions
we
had
that
panel
and
there
are
a
couple
of
people
asking
if
istio
will
be
able
to
make
cert
rotation
easier
and
questions
about
ambient
things
like
that
and
then
I'll.
Let
Mitch
talk
about
the
folks
that
we
ran
across
about
tags
and
revisions,
but
yeah.
That's
kind
of
my
that
was
my
experience.
Justin.
A
J
But
yeah
I
I
threw
out
a
couple
of
numbers
like
a
year
two
years
as
far
as
support,
and
they
were
that
was
fine
with
them,
but
I
mean
it's.
It's
definitely
a
a
problem
that
that
makes
sense
right.
As
your
Fleet
scales,
you
have
to
coordinate
those
upgrades
across
across
them.
It
does
take
a
considerable
amount
of
time,
and
so
it
was
I
think
it
was
less
the
releases
they
didn't
seem
like
they.
They
didn't
say
they
needed
like
the
newest
features.
It
was
more.
J
A
J
B
J
G
We
did
hear
from
two
particular
users
who
volunteered
that
they
very
much
need
an
upgrade
API.
Each
of
these
users
are
in
production
with
istio
for
several
years
now,
and
they
manage
their
clusters
through
git
Ops,
so
getting
command
line.
Access
to
kubernetes
is
just
not
an
option
for
these
users.
They
are
currently
really
using
not
tags.
G
But
revisions,
which
is
a
very
similar
API
tags,
are
essentially
just
an
alias
two
revisions
but
talked
about
how
difficult
it
is
to
understand
a
pull
request
where
a
revision
is
changing
because
a
revision
is
codified
as
a
mutating
web
hook,
config
it's
somewhere
in
the
neighborhood
of
150
lines
of
yaml.
That
really
only
expresses
a
very
small
concept,
which
is
that
this
revision
of
istio
exists
and
it
has
a
revision
name.
G
So
they
expressed
an
interest
in
seeing
a
way
to
upgrade
their
clusters
that
did
not
involve
using
any
istiocuddle
tooling
and
that
did
not
involve
having
large
mutating
web
hook
configs.
Now,
of
course,
they
didn't
specifically
ask
for
a
tag
crd,
they
weren't
proposing
Solutions,
but
there
was
some
strong
signal
that
we
that
you
know
we
needed
to
improve
the
user
experience
here.
I
see
a
couple
hands.
H
There's
nothing
special
about
the
studio.
Nothing
should
be
special
about
this
DND,
so
I
was
going
to
I
I
I've
been
spending
some
quality
time
with
with
Argo
and
and
some
other
tools
and
and
I
was
trying
to
do
a
prototype
with
with
this
studio
as
well.
I
would
look
forward
to
opinions
and
feedback
on
if
this
is
acceptable,
but.
G
Yeah
on
the
XDS
side,
we've
had
demos
a
few
times
in
the
past
of
doing
something
like
an
Argo
rollout
or
a
flagger
rollout
moving
progressively
our
XDS
traffic
from
one
version
of
sdod
to
the
next
I
think.
There's
a
lot
of
value
there
there
that
doesn't
solve
the
problem
of
Waypoint
scheduling,
but
it
does
it.
You
know
it's
part
of
the
upgrade
process,
that's
relevant
to
the
conversation
yeah.
H
H
H
D
G
That's
a
great
question,
so
an
upgrade
API
would
be
a
way
to
programmatically
indicate
that
a
certain
set
of
proxies
need
to
move
from
one
version
to
another.
Those
could
be
sidecar
proxies,
they
could
be
Waypoint
proxies,
but
in
our
what
we've
called
in
the
past
Canary
or
revision
and
tag
based
upgrade
process,
you
have
an
intermittent
state
where
some
of
your
proxies
are
of
one
version
and
some
are
of
another
version.
Users
need
a
way
to
Signal
when
proxies
should
move
from
one
version
to
the
next.
D
D
G
Yes,
so
for
most
of
our
users,
the
number
of
namespaces
that
they
have
or
if
they're,
using
workload
labels,
is
it's
not
really
possible
to
change
the
labels
across
all
of
the
namespaces?
These
upgrades
are
things
that
should
be
carried
out
by
the
cluster
administrator,
who
often
doesn't
even
have
the
right
access
to
individual
application
name
spaces.
If.
G
D
J
B
D
H
D
H
Kit
Argo
doesn't
use
in
place
upgrades
they
do
a
traffic
shifting
using
you
know
either
history
API
so
come
API,
or
something
like
that.
So
it's
they're
using
exactly
the
same
mechanisms.
We
are
using
and
the
same
mechanisms.
We
recommend
users
to
do
for
their
own
workloads
or
they
do
Canary
and
and.
F
H
J
B
E
H
Distributed
revision
and
then
use
HTTP
route
and
standard
apis.
You
can
do
it
either
manually
or
because
Hardware
is
just
automating
HTTP
route,
so
it's
automating
shifting
sitting
weights
projected
in
the
mouth
and
it
also
looks
at
Prometheus
to
figure
out.
If
you
start
having
errors,
then
it's
it's
automatically
rolling
back,
but
other
than
that.
D
H
J
D
B
D
E
B
D
B
B
H
G
H
G
Also
potential
for
better
integration
with
Argo
and
other
git,
Ops
providers
or
Waypoint
scheduling,
and
basically
the
the
functionality
would
be
to
remove
Waypoint
scheduling
from
runtime
functionality
of
the
control
plane
and
move
it
into
your
gitups
so
that
you
create
a
Gateway
you
see
or
a
Gateway
resource.
You
know
in
git,
Ops
git
Ops
then
has
some
sort
of
customized
script
Helm
script,
something
along
those
lines
that
results
in
the
scheduling
of
a
waypoint.
It's
actually
a
much
better
experience
for
git
Ops
users.
G
H
That's
not
entirely
accurate
I
mean
the
reason
we
prefer
the
Gateway
class
controller
to
automate.
It
is
because
we
want
to
preserve
this
option
to
merge
gateways
and
deployments,
create
deployments
that
are
shared,
create
deployments
of
the
cluster
have
vendor,
provided
you
know,
multi-ten
on
gateways
that
take
care
of
of
the
implementation,
so
we
do
not
want
to
have
users
believe
that
there
is
a
deployment
running
in
class
with
a
particular
name.
That's
a
control.
H
G
I
see
so
anyways
I
I
didn't
really
mean
to
re-kick
off
the
discussion
of
tag
apis
Etc
only
to
say
that
we
did
get
some
decent
feedback
from
users
in
istio
and
production
that
there's
a
lot
of
pain
with
the
current
situation,
both
for
sidecars
and,
of
course,
looking
forward
for
ambient
again.
That
doesn't
necessarily
mean
that
the
crd
solution
is
the
one
that
we
have
to
pursue,
but
there's
certainly
interest
on
the
part
of
our
users
and
seeing
this
pain
solved.
B
H
H
D
I,
don't
think
anything's
not
really
covered.
I
mean
a
lot
of
the
questions
and
excitement
about
ambient,
of
course,
mostly
because
that's
what
the
new
thing
yeah
I,
just
whatever
I
said
as
well,
so
there's
a
lot
of
people
that
were
just
said:
yeah.
We
use
Easter
for
three
years
in
production,
it's
good!
H
F
B
E
E
Yeah
I
think
most
of
it's
probably
been
covered.
The
one
thing
I
didn't
hear
and
interesting
that
Keith
heard
it
was
the
upgrade
frequency
because
that's
always
been
sort
of
you
know
something
that
we
come
back
to
every
so
often
and
I
know.
There's
some
talk
about
it
again,
so
that
that
was
interesting.
I
hadn't
heard
that
there
ambient
certainly
heard
a
lot
about
ambient
a
lot
of
questions.
You
know
ones
are
coming
out,
starting
to
see
some
comparisons
with
the
other.
The
other
projects.
E
So
that's
good
I
will
make
a
comment
that
I
thought
one
of
the
interesting
presentations
I
went
to
was
the
one
just
before
the
panel
I
think
it
was
two
people
from
solo
yeah
talking
about
the
the
minor.
You
know,
differences
that
you,
you
may
see
with
ambient
right
versus
the
sidecars
and
basically
because
we
have
a
waypoint
versus
you
know
a
proxy,
the
sidecar
proxy
of
both
the
client
and
server
side.
So
I
thought
that
was
interesting.
I
mean,
if
you
think
about
it.
B
Yeah
I
guess
for
me,
I
think
you
guys
all
said
it
all.
You
know
lots
of
excitement.
I
guess
you
probably
also
see
the
announcement
from
psyllium
about
psyllium
mesh.
So
if
not
was
checking
out
because
there's
a
interesting
enough,
every
single
ambient
session
or
it's
real
session
I
go
there
are
audience
ask
about
how
Salim
integrates
with
ambient
there
are
people
ask
about.
You
know:
do
I
need
ambient.
If
you
still
am
provides
layer,
7
psyllium
provides
everything.
I
need
so
pretty
much.
B
H
Yeah,
I
might
think,
is
you
know
if
celium
provides
Ambience,
that's
wonderful,
more
implementation,
it's
validates
the
concept
but
calling
it
mesh
I
think
we.
We
really
need
to
figure
out.
What
is
what
a
mesh
means
and
what
are
the
requirement
for
something
to
be
called
a
mentioning
compatibility
is
a
gamma
some
set
of
core
features,
because
every
Link
Card
is
also
a
mesh.
Everyone
has
a
mesh
and
it's
confusing
for
users.
J
Yeah,
it
was
interesting
to
me
that
that
psyllium
now
has
psyllium
service,
mesh
and
psyllium
match,
which
are
two
different
things,
but
speaking
of
compatibility,
you
know
there
are
a
couple
of
complications.
I
had
we
actually
talked
about
this
in
gamma
yesterday
as
well,
where
we
discussed
potentially
in
some
time
in
the
future,
expanding
gamma
from
this
statement,
API
to
being
more
to
be
able
to
tackle
other
things.
J
B
C
C
Noise
yep
thanks
great
thanks.
You
can
probably
just
scroll
down
a
bit
the
background
section.
I
think
is
you
know.
Most
of
us
are
pretty
aware
of
I
just
did
it
put
it
in
there
for
context,
basically
what
we
did
in
istio,
so
if
you
scroll
down
to
the
kubernetes
requirements,
so
this
whole
dock
really
is
just
a
requirements
document
just
to
kind
of
capture.
You
know
what
what
the
behavior
we
want
is.
C
So
if
you
scroll
down
to
the
bottom
of
the
requirements,
there's
like
a
few
kubernetes
requirements
just
want
to
call
them
out
yeah
there
we
go
yeah,
so
just
with
respect
to
kubernetes
and
kubernetes
MCS,
and
this
kind
of
reflects
some
conversations
that
we've
had
with
cost.
In
that,
basically,
we
should
just
respect
kubernetes
and
the
way
kubernetes
does
things
as
much
as
possible.
So
that
means
cluster
local
will
just
be
cluster
local.
C
If
you
ask
for
the
cluster
set
local,
which
is
then
CS
hosting,
then
then
you
get.
You
know
the
the
the
bips
for
the
cluster
set
host,
so
I
think
nothing
surprising
there.
It's
just
basically
behaving
as
kubernetes
would
behave
so
that
that's
that's,
probably
the
only
add-on
from
basically
you
know
specific
requirements
we
had
for
for
istio.
C
So
if
we
scroll
down
to
the
the
end,
the
design
ideas
as
far
as
deployment
we've
kind
of
settled
on
this,
this
thing
should
basically
be
built
as
a
part
of
the
zetella
process.
We
had
considered
using
istio
agent
alongside
it
and
we
we
decided
against
it
for
for
a
variety
of
reasons,
and
it
simplifies
the
architecture.
C
As
far
as
building
Z
tunnel
I
think
we'll
we
want
to
accommodate
platform
provided
DNS,
so
so,
in
other
words,
we
could
we
want.
We
want
this
entire
feature
to
be
a
build
option
of
of
Z
tunnel.
So
you
can,
you
can
get
a
z
tunnel
without
DNS
or
with
DNS
I
think
by
default
DNS
would
be
enabled,
but
but
you
can
always
build
G
tunnel
without
it.
So
I
I
think
that's
pretty
much
it
if
you
know
feel
free
to
peruse
the
doc.
H
Well,
I'm,
I'm
I
think
it's
it's
a
it's
a
great
idea
and
I
complicated
doing
it
in
Seattle
is
probably
the
best
and
using
the
cash
that
joining
the
building
with
all's,
IPS
and
everything
workable
Discovery
services
and
your
stuff,
so
that
was
kind
of
the
main
reason.
I'm
no
longer
a
fan
of
his
new
agent
doing
DNS.
H
C
C
H
Yeah
I
mean
you
know.
The
reason
why
I
think
DNS
is
securing
DNS
is
important,
because
the
security
model
is
based
on
secure
TNS
and
your
Genesis
compromised
so
forth,
but
I
see
many
platforms.
Support
are
having
secure,
DNS
and
they're
all
kind
of
efforts
to
integrate
with
Upstream
DNS
servers.
So
it
may
not
be
a
blocking
sink,
at
least
for
for
the
mainstream
platform
that
that
require
DNS
to
other
means.
B
H
One
more
question
on
DNS
I:
don't
know
if
document
is
clear
or
if
we
under
one
controversial
topic
is
if
we
are
going
to
continue
to
have
client-side
overrides
for
DNS,
so
basically
splitorize
on
each
client.
We
get
a
different
response
based
on
what
work
work.
It
is
and
I
believe
the
proposal
is
to
not
have
that
and
to
have
kind
of
producer,
oriented
and
but
I
want
to
make
sure
people
give
you
this
aspect.
It's.
H
C
H
C
Okay,
well,
I,
I,
think
I
think
that's
probably
something
we
should.
We
should
tackle
that
would
include
DNS,
but
but
I
think
that's
probably
like
the
way
we
handle
kubernetes
hosts
and
nips
I.
Think
it's
probably
like
a
separate
topic
for
ambient
and
istio
compatibility
and
and
DNS
you
know
whatever
DNS
is
doing,
would
just
fall
out
from
that.
B
H
I
looked
at
your
functionality
recently
and
it
does
cover
it
for
foreign,
but
for
ambient
I
think
we'll
need
to
make
some
changes.
John
was
also
refactoring
a
bit.
The
way
we
get
the
the
discoveries
are
put
and
I
think
we
need
a
small
patch
to
filter
it
by.
So
we
still
have
some
some
remaining
work,
but
the
foundation
at
least.
Is
there.
B
H
Yes,
I
mean
I,
think
I,
think
we
we
not
only
in
Google
but
because
gamma
Gateway
API
have
some.
You
know,
requirements
for
for
MCS
compatibility,
I,
think
we
we
and
and
because
it
breaks,
upgrade
and
then
install
from
my
point
of
view.
It's
a
blocker
for
you
know
using
ambient
on
by
default
in
the
entire
cluster.
We
cannot
have
it
otherwise,
because
some
applications
will
be
broken,
so
I
cannot
imagine
launching
ambient
without
this
fixed.
C
C
H
C
I
I
guess
I'm
just
thinking
that
we
should
probably
have
a
doc
to
I
forget
who
has
to
Mitch,
maybe
a
doc
that
maybe
captures
you
know
like
what
will
break
in
which
scenarios
you
know,
and
maybe
those
are
our
two
scenarios
like
going
to
Ambien
from
raw
kubernetes
going
from
tambian
from
istio,
and
then
you
know
waste
ways
to
mitigate
if
possible,
Etc
nothing
should
break
as
a
requirement.
Yeah.
That's
that's.
That's
been
a
requirement
for
istio
since
day,
one
probably.
C
H
So
I,
my
my
personal
opinion
is
that
this
dog
is
the
same
dope
with
the
foundation
he's
still
because
whatever
we
Define
in
Foundation
ambient
should
support
it,
and
we
should
definitely
need
to
have
some
some
talk
about.
What
is
the
features
in
in
the
foundation?
So
I
would
rather
share
the
work
between
the
two
streams
kit.
What
do
you
think.
J
B
C
J
J
The
foundation
mode
was
a
way
to
get
around
that.
If
we're
okay,
with
breaking
changes
that
at
that
point,
I
think
we
just
start
making
things
from
Sable
and
beta
if
we
don't
see
what
their
future
for
future
future
future
future
future
forward.
It's
hard
to
say
when
it
comes
to
DNS
and
breaking
people,
and
things
like
that
I
think
getting
the
scenarios
out
on
paper
is
going
to
help
us
understand.
J
C
I
guess
I
guess
I
was
trying
to
trying
to
think
of
like
I
suspect.
So
so,
basically,
this
this
doctors
brought
brought
up
the
broader
topic
of
the
fact
that
ambient
is
going
to
respect
kubernetes
with
respect
to
host
names
for
cluster
local
being
just
local
to
the
cluster
and
using
the
cluster
Set
hostname
to
address
the
service
mesh.
C
So
that's
like
us,
respecting
kubernetes
is
actually
us
breaking
compatibility
with
istio
in
a
way,
so
there's
kind
of
like
that
trade-off,
so
so
I
so
I
feel
like
we
need.
We
need
to
figure
out
where
to
document
this
and
I
suspect
this
isn't
the
only
topic
of
of
you
know:
breaking
changes
coming
from
either
kubernetes
or
istio.
J
Yeah,
that's
a
really
really
good
point,
I,
think
yeah
I
think
I
did
class
submission
only
to
try
to
break
once
yeah
it's
it's
it's
difficult,
because
I
think
everybody
I
think
everybody
stands
again
if
she
has
more
a
lot
of
kubernetes
but
but
yeah
I'm
going
to
change.
This
aren't
aren't
great.
So
that
means
anything
to
think
about
that.
C
Yeah
I
mean
to
be
fair,
I
think
you
know,
istio
made
it
made
a
terrible
decision
early
on
to
just
hijack
cluster
local
to
be
mesh
wide
I
mean
that
was
a
the
original
sin
of
istio.
So
I
think
you
know
the
the
you
know
the
adopting
kubernetes
model
is.
Is
the
right
thing
to
do
by
default?
Maybe
maybe
we
provide
options
to
opt
into
the
istio
way
of
doing
things?
I
don't
know,
but
even
then
you
get
into
situations
where
well,
what?
C
C
You
know
that
that
original
sin
of
istio
that's
that's
kind
of
like
the
bane
of
this
anyway
I
I
I.
Think
the
question
is
I
think
we
all
agree.
We
need
to
document
it.
I
think
I,
think
they're.
The
the
question
is
like,
where
and
and
how
to
keep
track
of
this.
It's
it's
probably
something
we
should.
We
should.
You
know
keep
track
of
as
a
group
and-
and
you
know
make
some
decisions
about.
You
know.
Okay,
so
we've
got
this
problem.
C
J
Well
and
to
add
some
more
like
context
into
this,
so
we've
been
talking
about
this
aspect
from
gamma
and
Gamma
for
a
while
and
turned
out
if
she's
not
alone
like
there
are
other
other
messages
you
can
multi-cluster.
Don't
really
do
things
the
NCS
way,
and
so
you
know
the
idea
of
the
clients
being
able
to
decide
where
the
traffic
is
routed.
B
and
DNS
is
one
of
the
things
I
one
of
the
things
that
has
led
to
MCS.
Having
not
super
widespread
adoption
across
service
missions.
J
H
But,
okay,
it's
not
about
MCS,
we
may
have
other
Solutions,
but
the
main
point
is
cluster.
Local
should
stay
local,
otherwise
applications
will
break
and
we
cannot
so
how
we
do.
We
represent
cluster
set
or
something
else.
That's
probably
Up.
For
Debate
and
implementation
can
have
other
Solutions.
But
it's
a
critical
thing
is
that
you
know
you
shall
not
break
applications
when
you
enable
ambient
well.
H
G
H
C
I
mean
yeah,
so
so,
if,
if
ambient,
if,
if
the
solution
is
ambient,
provides
knobs
to
to
allow
the
istio
thing,
I
mean
to
your
point
earlier.
You
know
the
the
requirement
is
to
not
break
right,
and
that
means
for
both
istio
users
and
kubernetes
users.
So
that
means
we're.
Gonna
have
to
have
knobs
I.
Think.