►
From YouTube: Kuma Community Call - September 15, 2021
Description
Kuma hosts official monthly community calls where users and contributors can discuss about any topic and demonstrate use-cases. Interested? You can register for the next Community Call: https://bit.ly/3A46EdD
A
Today
we
probably
split
this
call
into
sections,
I'm
going
to
speak
about
revisiting
policy,
matching
that
we
want
to
implement
in
the
future,
and
now
we
outlined
the
problem
we
have
with
policy
matching.
We
will
speak
about
these
problems
and
also
we
speak
about
some
of
the
ideas
how
to
fix
this
and,
at
the
end,
we'll
have
some
time
for
a
q,
a
section
as
usual.
A
A
But
this
is
the
list
of
problem
that
we're
noticing
and
they
kind
of
painful
for
us,
and
we
are
considering
them
to
be
fixed
and,
please
add,
as
a
comments
what
you
find
problematic
with
the
policy
matching
yeah
and
the
first
thing
that's
kind
of
problematic
in,
in
my
opinion-
and
I
checked
with
developers,
either
is
much
incambiguity,
so
sometimes
it's
just
not
clear
which
policy
takes
precedent
over
another
policy.
A
I
gave
three
examples
of
different
policy
fault,
injection
circuit,
breaker
and
trait
limit,
and
it's
never
obvious
left
or
right
will
be
applied
and
it
which
is
more
interesting.
It
sometimes
depends
on
the
type
of
the
policy,
some
of
them
some
of
the
problem.
Already.
Some
one
problem
already
was
fixed
for
fault
injections.
A
It's
merged,
but
not
released
from
what
I
can
tell,
but
for
circuit
breaker
entry
limiting.
It's
unobvious
that
in
this
case
for
circuit
breaker,
the
latest
create
the
latest
policy.
Will
be
taken
so
we
sort
them
by
creation
time,
but
for
it
limiting
we
actually
sort
by
sources,
so
the
most
specific
source
will
take
precedence,
which
is
which
might
be
confusing.
A
The
second
problem
that
we
have
is
traffic
permission.
I
think
this
problem
was
reported
by
charlie
and
we
have
an
issue.
I
just
lost
link
to
the
issue,
but
briefly
speaking,
if
you
have
two
traffic
permission
from
b
to
a
and
from
c
to
a
then
the
second
one
takes
precedence
over
the
first
one
and
that's
why
you
will
lose
traffic
between
b
and
a
which
is
quite
an
obvious
as
well
and
technically.
A
A
The
next
problem
is
big:
it's
huge
or
it's
no
tooling
to
debug
or
which
policy
to
figure
out
which
policy
were
applied
at
the
end
and
kind
of
the
only
way
right
now
to
check
which
policy
were
applied
is
to
go
to
android
admin,
api,
config,
dump
and
see
the
real
values
in
the
configuration
and
opt-out
would
be
kind
of
a
great
feature,
especially
for
policies
like
traffic
permission,
traffic
clocks
and
actually
for
every
policy.
A
If
you
want
to
apply
policy
for
everything,
except,
for
example,
couple
of
services,
so
it
would
be
kind
of
useful
yeah.
That's
five
policies,
that's
five
problem
that
we
outlined,
but,
of
course,
there
are
more,
probably
and
feel
free
to
add
your
ideas,
you
what
what's
the
main
pain
for
you
when
you
work
with
matching
and
now
about
ideas
and
potential
solutions
that
we
can
implement.
A
A
That
becomes
tricky
when
you
start
thinking
about
types
of
the
policy,
so
some
of
them
imply
stacking.
So
you
can
kind
of
create
many
fault
injections.
You
can
stack
them
one
on
top
of
another
and
have
many
fault
injections,
but
some
policies
they
imply
overriding,
so
one
timeout,
overwrites,
another
timeout
or
or
one
rate
limit,
overrides
another
rate
limit.
A
A
That
allows
you
to
explicitly
show
your
desire,
for
example,
append
and
overwrite.
If
we're
talking
about
fault
injections,
then
you
can
append
you
fold
to
already
the
existing
base
fault
injections.
For
example,
you
defined
a
board
500
and
then
you
create
new
fault
injection
for
most
specific
services,
which
is
abort
401
and
at
the
end
you
will
have
two
status
codes
for
back-end
service.
For
example,
there
is
also
overwrite
section
which
looks
the
same
as
yes,
here's
example.
A
A
The
next
idea
is
pretty
easy
to
implement
and
we
think
it
will
make
things
more
predictable,
because
now,
if
you
policies
are
equally
specific,
so
they
have
equal
rank,
we
take
the
latest
the
latest
policy,
so
we
start
by
creation
time
and
that
might
be
unobvious
and
unpredictable,
especially
if
user
has
some
machinery
that
apply
policies
by
iterating
in
the
directory
and
something
may
be
changing
in
the
file,
names
and
policy
will
be
applied
in
different
order
and
another
result,
then
another
timeout,
which
is
on
great
and
the
simple
the
simplest
thing
we
can
do
is
to
introduce
lexicographic
order
as
an
example.
A
A
A
The
next
idea
is
pretty
big
and
it
it's
really
huge
from
the
implementation
perspective
and
from
the
design
perspective,
but
maybe
we
should
think
about
it
more
because
today,
the
model
we
have
with
sources
and
destinations
in
some
places
it
doesn't
fit
well
with
the
real
world.
So
because
of
that
we
have
some
limitations
on
the
destinations.
A
A
So
maybe
we
should
go
with
a
more
simple
and
transparent
model
of
matching
and
replace
source
and
destination
selector
with
the
simple,
oh
wait:
where
is
it
simple
selectors
that
we
already
have
for
data
plane
policies?
A
So
maybe
all
policies
should
become
data,
plane
policies
and
then
in
the
configuration
you
will
add,
more
details
or
which
outbound,
for
example,
you
want
to
pick
like
an
example
with
timeouts,
so
you
choose
gateway
and
you
sp,
you
specifically
define
which
outbound
should
be
on
which
outbound
dispose
should
be
applied.
A
Yeah,
that's
probably,
will
make
things
more
a
bit
more
simpler,
but
we
need
to
pay
more
attention
to
this
option
yeah
and
to
link
yes,
we
have
to
do
something
with
doing
this
is
not
in
the
scope
of
this
of
this
document.
A
Also,
there
is
second
document
which
is
slowly
updated
with
the
new
use
cases.
Now
there
are
four
of
them,
so
the
idea
of
this
document
is
to
show
where
kuma
is
limited
today.
A
What
use
cases
today
could
not
be
covered
well
with
kuma
and
how
they
will
be
covered
after
we
create
these
improvements,
so
this
document
is
not
finished
it's
in
progress,
but
please
get
familiar
with
these
documents.
I
left
things
here
and
comment,
ask
questions
and
propose
some
stuff,
so
that's
pretty
much
it
for
a
proposal
of
revisiting
policy
matching.
A
B
Okay,
I
guess
we
discussed
this
policy
matching
within
the
team
at
home,
but
I'm
very
curious
so
deeply.
What
do
you
think
about
about
this?
As
a
as
a
user
of
corner.
C
Yeah,
so
I
mean
yeah,
definitely
a
few
things
are
which
which
has
been
shown
here
is
is
very
important,
and
I
I
actually
like
the
fourth
one
when
you
actually
get
rid
of
the
source
and
destination
and
specifically
because
because.
C
So
I
mean
yeah,
so
I
would
definitely
suggest
that
we
should
do
some
something
to
make
sure
that
it
is
easier
for
us
to
consume.
B
Yeah,
the
initial
idea
was
so
the
user
can
think
about
connections
right.
So
if
you
have
like
traffic
logging,
you
think
about
logging
on
this
connection,
but
in
the
real
world
users
actually
care
on
which
side
of
the
connection
this
policy
is
applied
right
so
with
different
policies,
as
you
said,
sometimes
it's
slightly
confusing
on
which
side
it
is
applied,
whereas
with
these
selectors
it's
very
explicit.
B
The
downside
of
this
approach
is
that
it
is
major
breaking
change,
which
is,
of
course,
not
impossible
to
do
right,
but
if
we
want
to
go
this
way,
we
really
need
to
make
sure
that
this
is
something
that
our
users
would
like
to
see.
So
that's
why
it's
kind
of
curious
what
you
what
you
think
about
this.
C
A
Yeah,
I
will
post
links
and
share
later
to
the
channel,
so
other
people
who
didn't
join
today
also
could
look
through
any
other
questions,
not
regarding
this
policy
marching
in
general.
Maybe.
C
So
I
saw
the
latest
blog
coming
out
with
with
gong
and
kuma,
acting
as
the
gateway,
so
just
wanted
to
ask
you
women,
I
think
two
or
three
call
back
earlier.
We
we
were
talking
about
some
changes
that
we
want
to
make
on
the
gateway,
the
gateway
data
plane.
C
So
did
we
did
we
do
that
or
where
we
are
with
respect
to
that,
I
mean
just
want
to
make
sure
that
so
the
action
item
on
me
was
to
create
a
jira
a
create
ticket,
but
I
have
created
that
I
did
not
see
any
any
comments
on
that.
So,
if,
if
we
want
we
can
we
can
debate
on
this
or
or,
however,
you
want.
A
What
kind
of
tickets
could
you
please
about
gateway.
A
Oh
this
one
yeah
yeah
okay,
so
there
is
kind
of
some
work
in
progress
here
and
probably
you
may
notice
something.
A
Yes,
so
we
slowly
adding
new
resources,
we're
considering
how
it
should
look
like.
Unfortunately,
we
don't
have
james
right
now
on
the
call
who
may
bring
more
details
about
this
stuff,
but
some
work
happens
and
I'm
not
sure
when
it
will
be
in
some
final
stage.
A
Maybe
some
someone
else
has
some
insights,
but
that's
just
what
I'm
observing.
C
And
are
we
also
planning
to
add
mtls?
I
mean
mps
termination
capability
so
that
we
can
terminate
any
tls
or
mdls
connection.
A
B
Termination
yeah,
you
can
say
about
mtls
whether
the
gateway
will
be
able
to
verify
the
client's
certificate.
I
not
sure
if
this
is
in
the
initial
model,
but
it's
it
sounds
very
natural
to
introduce
this
right.
So
if
this
one
will
not
be
in
the
initial
scope,
then
it
will
be
implemented
eventually.
C
So
from
my
experience,
maybe
I
can
just
add
one
thing:
instead
of
adding
a
client
certificate
validation,
if
you
can
add,
chart
validation,
yeah,
that
would
be
a
great
piece
to
have,
because
what
I've
generally
seen
is
whenever
there's
whenever
there
is
a
decoupling
between
the
gateway
and
and
the
remote
endpoint,
it
is
tls
plus
chart
validation.
B
Right
right,
so
when
it
comes
to
authentication
of
the
client
right,
you
can
pick
a
couple
of
options.
So,
like
you
said,
job
is,
is
another
option
option
which
is,
I
guess,
more
user-friendly
to
users,
because
users
hate
to
deal
with
with
tls
right.
So
that's
one
of
the
reason
this
machine
exists
yeah.
So
I
guess
this
is
also
at
least
in
the
road
map.
I
don't
know
if
the
initial
implementation
will
contain
this.
C
Sure
yeah
one
question
I
wanted
to
ask
is
the
visualization
that
you
have
added
1.3
again
I
looked
at
the
blog,
I
did
not.
Actually
I
saw
it
myself.
Is
it
out
of
the
box
or
does
it
require
some
kind
of
integration
with
with
grafana.
D
D
But
if
you're
running
your
own
grafana
stack,
you
will
need
to
download
the
data
source.
It's
in
getup.com,
qmihq,
slash,
rafana,
datasource,
okay
and
you
can
find
the
release
and
the
binaries
there
and
how
to
actually
set
it
up.
If
you,
if
you
run
into
any
issues
like
the
documentation,
is
very
scarce
at
the
moment.
So,
like
ping
me
also
when
the
process
of
getting
the
binary
signed
by
grafana,
but
this
is
a
lengthy
process,
so
it's
not
signed
yet.
C
Understood,
and
does
it
also
need
some
kind
of
so
is
it?
Is
it
very
much
comparable
to
kiali.
D
Jali
is
the
inspiration
I
wouldn't
say
it's
like
as
complete
as
kali,
but
okay,
probably
like
at
some
point,
we'll
add
links
to
being
able
to
jump
to
traces
and
to
jump
to
logs
and
get
deeper.
Insight
like
this
is.
This
is
very
much
like
a
first
try
and
and
trying
to
like
see
what
we
can
go
from
there,
where
we
can
go
from
there
with
this
feature.
C
Our
question
is:
does
it
also
require
control,
plane
access
and
does
it
need
to
understand
the
data
plane
definitions
or
are?
It
is
completely
out
of
your
final.
D
So
the
data
source
actually
communicates
with
the
control
plane
api
to
get
the
list
of
services
and
things
like
that,
and
it
also
communicates
to
your
prometheus
data
source
to
actually
get
the
actual
stats.