►
From YouTube: Kuma Community Call - June 8, 2022
Description
In this call, we are discussing Kuma 1.7.0, Kuma 1.6.1, Kuma 1.5.2.
A
A
We
are
waiting
for
unvoice
security
patch,
that's
supposed
to
be
released
tomorrow
and
as
soon
as
we
got
all
binaries
compiled
for
envoy,
I
think
we
are
ready
to
go
and
cut
release
and
the
same
for
I
think
before
we
will
have
1.6.1
and
after
that
1.7.0
it
should
be
at
the
beginning
of
the
next
week.
If
I'm
correct
so
yes
charlie,
do
you
have
anything
to
add
for
releases.
C
B
Yeah,
so
in
the
past,
what
we've
been
doing
for
proposals
for
like
big
features
or
big
changes
to
kuma
has
been
docs
like
marked
down
files
inside
puma
that
didn't
really
have
any
kind
of
format
what
we've
been
and
the
process
wasn't
very
well
defined.
So
what
we've
been
working
on
now
is
to
have
an
adr
process
and
to
do
this,
so
it's
all
defined.
Well,
do
you
want
to
show
the
old
proposals?
First
yeah?
B
So
we
have
this
here,
so
the
very
first
magr
is
to
actually
use
madr.
So
if
you
pick
this
one
yeah,
it
actually
describes
what
we
do.
The
cool
thing
is
actually
defining
what
needs
an
madr
so
that
people
can
quickly
know
whether
or
not
they
should
go
for
a
design
and
so
to
open
it.
You
just
you
know,
create
a
time
like
follow
this
template,
and
then
you
do
need
to
get
free
approvals
on
the
pr
to
get
the
mhr
actually
merged
in
and
yeah.
B
D
C
A
E
So
there
is
like
problem
how
to
detect
to
which,
which
pro
materials
should
take
the
metrics.
It
might
be
some
there.
It
looks
like
the
metrics
shouldn't
be
much
specific,
more
like
zone
specific
or
something
like
this,
because
you
mostly
want
one
promise
for
whole
a
cluster,
and
that's
that's
why
I
thought
maybe
the
merch
specific
policies,
not
all
they
don't
have
to
be
like
this
same.
It
comes
to
the
external
services.
They
might
be
also
not
the
mesh
specific
and
maybe
some
default
policies
that
you
want
to
apply
for
all
the
meshes.
B
A
I,
in
my
opinion,
it
doesn't
make
sense
to
take
the
policies
that
we're
using
for
setting
some
stuff
from
inbound
or
outbound
and
have
these
type
of
policies
to
be
available
for
all
measures.
I
think
that's
kind
of
breaks,
isolation
that
we
want
to
achieve
with
meshes,
but
at
the
same
time
I
get
the
I
get
the
use
case
with
prometheus.
A
E
E
E
B
Account
mean,
I
guess
one
thing
is
the
bit
of
observability
we're
talking
about
it's
not
really
down
to
configuring
data
planes.
It's
like
configuring,
external
stuff
right
in
that
case,
it's
the
permission.
It's
the
back
ends
for
logging,
tracing
and
metrics,
and
the
other
example
we
have
is
external
services
right.
C
B
A
Yeah,
it's
something
that
like
cluster
operator,
gives
you.
For
example,
you
have
one
logging
backend
in
your
cluster
and
you
just
create
and
define
this,
and
you
can
use
it
from
every
mesh,
so
maybe
such
stuff
for
logging
tracing
that
you
mentioned
that
exactly
should
be
defined
on
global
class
level,
not
mesh
level
yeah.
I
can
try
to
write
down
what
we
discussed
so
backhands
for.
A
B
C
A
C
B
D
C
B
C
C
A
C
D
A
B
F
G
G
G
C
G
F
No
this
summer
I'm
gonna
be
working
on,
and
I
I
talked
to,
I
think
jacob
in
the
past
before
this,
but
I'm
going
to
be
working
with
one
of
the
developer
advocates
of
hashicorp
and
developing
a
vault
plug-in
that
will
manage
the
token
brokering
in
kuma.
There's
some
a
lot
of
manual
steps
to
that
and
a
lot
of
pieces
that
we,
I
think,
would
be
nice
to
automate,
and
I
think
that
those
two
products
would
kind
of
complement
each
other
pretty
nicely
so
yeah.
F
That's
something
that
I'm
going
to
be
working
on
this
summer.
I've
been
digging
into
kuma
a
lot
lately,
because
I
work
in
public
sector
in
the
u.s
and
they
tend
to
use
kong
for
their
api
gateways.
So
I've
done
some
some
service
measures
with
console
and
some
other
stuff,
and
there
are
some.
Sometimes
there
can
be
some
challenges
to
get
those
to
work
just
quite
right
because
they
work
slightly
different
in
certain
certain
areas,
so
digging
into
kuma
as
well.
F
C
D
C
C
Do
you
see
what
I
mean
like
if
I
look
before
and
after
it's
twice
as
many
logs,
but
at
the
same
time
it's
kind
of
nice
to
see
that
something
has
completed
right
so
right
now
I've
written
this,
but
because
of
not
producing
too
many
logs,
we
probably
should
log
only
once
right
and
probably
it's
better
to
look
before
an
action.
So
if
there
is
an
error,
it's
kind
of
clear
what
was
the
cause
of
an
error.
So
what
do
you
think
about
this?
Can
we
just.
C
D
I
think
that
for
like
trace
or
debug
level,
we
could
actually
log
before
and
after
so
we
know
how
long
the
action
takes,
so
you
don't
have
to
like
hook
up
any
like
instrumentation
stuff.
So
you
know
like
performance
wise.
You
know
exactly
how
long
the
action
took,
but
only
for
like
higher
levels
or
lower
levels
of
vlogging.
C
B
D
D
C
Yeah,
that's
a
good
question.
I
was
writing
this
by
just
you
know.
I
went
through
the
code
base
more
or
less
to
just
see
how
we
use
logging-
and
I
was
trying
to
you-
know-
write
examples
of
what
we
are
doing
right
and
what
we
could
improve
right
but
yeah.
Maybe
there
are
standards
with
like
bigger
code
bases.
D
C
C
Of
course,
any
linking
of
this
should
be
possible,
but
I
don't
know
if
there
is
like
a
built-in
south
ocean
that
we
can
take,
or
will
we
like,
spend
a
month
implementing
this
price
so
yeah,
let's
see
okay.
That
was
the
point
that
I
was
the
most
concerned
about.
So
thanks
for
the
input
and
if
you
have
like
more
suggestions
or
questions
or
whatever
just
comment,
I
would
love
to
hear
more.