►
From YouTube: Meshery Development Meeting (Oct 06th, 2021)
Description
Meshery Development Meeting - October 06th, 2021
Join the community at https://layer5.io/community
Find Layer5 on:
GitHub: https://github.com/layer5io
Twitter: https://twitter.com/layer5
LinkedIn: https://www.linkedin.com/company/layer5
Docker Hub: https://hub.docker.com/u/layer5/
A
Let's
wait
a
couple
of
minutes
to
let
us
join
in.
Meanwhile,
you
can
fill
in
the.
A
A
Mario,
is
this
your
first
time
on
on
our
calls.
C
C
I
joined
because
I
because
I
I
was
part
of
the
open
source
community
event
help
being
held
this
week
and
well
it's
great
to
be
part
of
this
community.
Thank
you.
A
Thank
you,
media
welcome
to
the
life
community
really
nice
to
have
you
here
and
also
mano.
Is
this
your
first
time
on
this
call.
A
Oh
all
right,
so
the
folks
who
join
different
meetings
are
different.
So
would
you
like
to
introduce
yourself
here
as
well.
D
Yeah,
so
my
name
is
currently
I'm
pursuing
my
b-tech
undergraduate
studies
briefing
here
from
iit
jordan.
I
am
a
person
who
likes
to
see
things
how
abstractly
they
are.
I
love
to
contribute
in
open
source
and
I
aim
to
learn
more
from
the
community.
A
That's
great
great
to
have
you
here.
Man
welcome
to
the
community.
A
All
right
we
are
for
after
and
let's
get
started,
welcome
everyone
to
the
measuring
development
meeting
today
is
the
6th
of
october,
and
before
we
get
into
the
topics,
we
have
a
couple
of
announcements.
A
So,
as
you
know,
kubecon
is
right
around
the
corner,
so
mesheri
is
participating
in
kubecon's
bugbash,
so
bugbash
is
an
event
that
is
hosted
by
cncf
and
sonotype.
So
what
this
event
is
is
it.
It
is
basically
an
event
where
contributors
can
come
in
and
try
to
fix
bugs
in
cncf
projects,
so
measuri
being
a
cncf
project
is
participating
in
in
bugbus
this
time,
so
existing
contributors
can
also
participate.
A
So
if
you
are
a
contributor-
and
if
you
are
on
this
call,
this
might
be
a
good
event
to
showcase
your
skill
and
get
some
bragging
rights
yeah.
So
basically,
this
event
starts
at
at
kubecon
so
next
week
and
you
can,
there
will
be
a
couple
of
open
bugs
from
measuring
in
the
bug
bash
and
basically
you
get
points
for
fixing
bugs
and
the,
and
there
is
a
leaderboard,
obviously
so
who
the
person
who
has
the
top
points
wins
the
event
and
gets
prices
at
the
end.
A
And
we
also
have
a
project
office
hours
for
missouri
at
kubecon,
so
the
we
will
be
live
at
13th
october
at
2,
30
pm
pacific
time,
so
the
project
office
hours
is
when
people
can
come
in
and
ask
questions
to
maintainers.
So
if
you
are,
if
you,
if
you
would
like
to
be
a
part
of
the
projector
coffee
servers,
please
signal
in
chat
or
slack
and
we'll
try
to
add
as
many
people
into
our
project
office
hours
as
we
can.
A
Another
update
is
that
nidish
karthik,
who
is
on
the
call
today,
is
nominated
as
a
mashery
maintainer.
So
if,
if
you
haven't
seen
this
work,
this
has
been
focused
primarily
on
measuring
ui
and
he
has
been
driving
for
some
of
the
recent
initiatives
in
measuring
ui,
especially
state
management,
and
he
has
been
working
on
management.
So,
if
you
haven't
seen
his
work
do
check
it
out.
A
Nathesh
has
been
nominated
as
a
maintainer,
so
I
have,
I
see
a
lot
of
overwhelmingly
positive
responses
to
nadesh's
nomination,
so
nitish,
I
think
congratulations
are
in
order
and
you
there
is
also
a
mailing
list
that
is
being
circulated
among
the
maintainers
and
you
you.
You
got
a
lot
of
positive
responses
there
as
well
all
right.
A
So,
let's
move
on
to
the
topics
for
today.
First
up
we
have
barik
who
will
be
walking
us
through
the
measures
messaging
framework,
so
without
wasting
any
time.
My
give
it
to
you.
F
All
right
sure,
thank
you,
vendo,
okay,
I
am
audible
right,
yes,
yeah
sure
all
right,
so
I'll
share
my
screen.
B
B
I
think
most
most
half
of
you
know
what
I'm
about
to
say
and
the
other
other
half
don't.
But
the
nice
thing
that
just
happened
is
that
barack
made
a
two
dollar
donation
to
the
community
pop
which
is
which
is
he
asked
the
question.
Can
you
see
my
screen
and
and
and
we've
just
made
it
a
public
pet
peeve
or
a
public
matter
of
efficiency
to
phrase
that
differently,
such
that
like
it's,
you
know
something
like
assuming.
B
F
F
So
currently,
what
we
have
is
that
we
have
like
several
go,
go
channels
that
are
inside
our
our
repo
currently,
but
at
some
point
I
think
what
we
have
some
some
issues
having
that,
so
the
issue
that
we
are
we
are
having
for
the
these
online
channels
is
that
some
of
the
channels
are
blocking
the
other
channels,
and
then
it
seems
like
this
is
the
this
is
the
thing
that
we
don't
want
to
have.
Basically,
so
what
we
are
doing
here
is
that
we
we
want
to
implement
a.
F
Like
a
big
pile
of
channel
and
then
and
then
going
forward
this
the
whole
like,
if
any
any
kind
of
system
that
wants
to
listen
to
this
message
channels,
they
can,
they
can
just
add
their
at
their
like
individual
channels
and
then
listen
to
it.
So,
basically,
what
we
want
we
want
to
try
to
implement
is
that
we
want
to
have
like
one
big
channel
for
the
whole
messaging
that
we
have
inside
our
system
yeah.
F
So
previously
we
have
the
the
the
design
spec,
but
I
think
yeah,
so
we
so
we
cannot
have
the
design
spec
previously
and
then
now
we
are
currently
under
underway
for
the
implementation.
So
here
today
I'll
just
let
you
guys
know
like
how
the
overall
architecture
works
and
then
how
the
overall
flow
works.
Basically,
does
it
sound
good?
F
Okay,
assuming
that
it
is
good,
so
all
right,
so,
firstly,
the
architecture
wise,
so
I've
made
a
draw.
I
o
diagram
that
we
can
we
can.
It
can
help
us
like
imagine
like
how
the
overall
architecture
works.
So
we
have
five
instances
here:
the
broadcaster
and
the
measure
server
major
ui
golden
plugin
and
measure
extension.
F
So
so
we,
the
the
main
thing
here,
is
the
measure
server.
So
this
broadcaster
is
the
one
that
we
we
just
implemented
so
inside
the
major
server.
There
are
multiple
instances
of
the
system,
so
so
you
can
see
that
it's
kind
of
weird
that
this
measure
server
is
the
one
that
publishes
the
image
and
then
listen
to
the
image.
Also.
F
So,
if
you,
if
you
kind
of
like
zoom
in
into
the
major
server
there
are
all
there
are
actually
multiple
instances
of
systems,
so
this
major
service
is
that
this
is
like
a
bunch
of
systems
and
we
just
kind
of
group
it.
So
it's
not
really
that
weird
yeah.
How
do
you
understand
so
in
this
system?
Is
that
we
kind
of
like
create
this
broadcaster
and
then
and
then
the
major
extension
also
will
listen
to
this
broadcaster
through
the
through
the
broadcaster
instance
that
we
with
pause
using
the
golang
plugin.
F
If
the
message
that
they
wanted
to
have,
for
example,
they
they
can
implement
some
kind
of
like
filtering,
so
this
message
is
coming
from
what
source
and
then
what
type?
F
So,
if,
if
any
specific
kind
of
like
message
that
they
wanted
to,
they
can
they
can
listen
to
that
and
then,
if
the
major
ui
requests
any
kind
of
like
subscription,
the
message
server
will
will
give
the
data
accordingly.
Basically,
so
this
is
the
architecture
wise
for
the
for
the
broadcaster
framework
and
then
the
next
one
is
the
flowwise.
F
So
you
can
see
that
there
is
the
main
broadcast
broadcast
type
that
we
have
in
the
middle.
So
you
can
see
that
there
are
two
types
of
like
arrows,
so
that
is
the
one
that
listens
and
then
the
one
that
publish
so
we
currently
have
two
types
of
message
at
the
moment.
So
the
message
is
the
first
message
is
mesync
and
then
the
second
message
is
the
health
of
it.
F
So
the
helper,
the
helper
instance
from
the
measure
server,
help
us
to
publish
a
message
calling
that
there
is
a
new
message,
data
that
is
published
and
then
so
we
have
like
a
bunch
of
graphical
subscriptions.
For
example,
this
add-on
subscription
data
points
of
your
chain
and
then
control
plane
subscription.
F
What
I
mean
by
particular
message
is
that
the
message
that
has
the
type
of
messaging
and
then
once
the
message
that
has
the
type
of
instinct
come
in
the
the
substitution.
For
that
particular
particular
I
mean
the
code
for
the
particular
solution
will
will
run
and
then
publish
any
kind
of
data
that
if,
if
there
is
any
any
ui
that
listens
to
this
particular
substitution,
then
they
will
publish
the
data
accordingly
yep.
So
this
is
one
for
the
messync
missing
message
type
and
then
the
other
type
is
the
operator
health.
F
So
we
have
in
the
in
the
measure
server.
We
also
have
the
message
type
of
operator,
health
so
and
then
we
also
have
the
substitution
for
that.
So
this
operator,
health,
promissory
server
will
publish
a
message
saying
that
the
data
the
detail
will
be
like
false
or
true.
False.
False
means
that
the
operator
health
is
good
and
then
the
true
is
means
that
the
operative
heart
is
yeah,
it's
good.
F
Basically,
so,
basically,
every
time
there
is
a
new
state
of
operative
health,
it
will
publish
a
message
saying
that
yeah,
what
kind
of
help
that
operator
are
selling
and
then
the
type
is
health.
So
once
there
is
a
new
data
come
in
and
then
we,
we
kind
of
like
listen
to
that
particular
message
in
the
alberto
state
graphql
subscription,
and
then
we
publish
the
publish
the
the
data
accordingly
to
that
to
the
particular
message
that
we
have
on
this
broadcaster
yep.
F
So
we
are
finished
with
all
the
downloaded
I
o
diagram,
so
we
can
move
on
to
the
code
side
since
yeah.
So
you
can
see
that
this
is
the
where
we
declare
the
broadcaster.
So
the
buffer
size
is
100,
so
there's
there's
actually
no
kind
of
like
decision
making.
That
is
happening
there
actually
yep.
So
inside
the
inside
the
helper,
we
kind
of
like
publish
the
state
of
the.
F
Okay,
assuming
that
you
guys
can
see
the
the
code,
so
you
can
see
that
this
is
the
data
that
we
published
for
the
operators
operating
health,
so
the
type
is
held
and
then
the
data
is
false,
meaning
that
this
is
the
the
particular
offers
that
operators
tell
is
not
good.
Basically,
the
house
is
not
good
and
then
the
next
one
is
the
birth
broadcast
for
the
messing.
So
you
can
see
that
the
type
is
missing
and
then
we
publish
a
new
data.
F
So
this
this
data
is
not
particularly
important
because
we,
I
don't
think
that
we
pass
anything
today,
that
to
the
broadcast
data
right
now
for
the
message
for
this
particular
use
case,
I
think
we
just
want
to
let
the
substitution
know
that
we
are
having
new
data
in
the
mesync
and
then
after
we
publish
this
message,
you
can
see
the
add-on
add-on
graphical
subscription
that
we
listen
to
that
particular
message.
F
So
you
can
see
that
we
plug
in
the
a
new
broadcast
channel,
and
then
we
listen
to
that
particular
the
the
big
the
big
broadcast
part
that
we
have
that
we
have
seen
earlier.
You
can
see
that
this
is
a
new
message
and
then
we
filter
by
the
type
of
messenger,
basically
yep.
So
this
is
a
typewriter.
F
So
once
what's
a
particular
message
come
in,
we
we
run
again
the
particular
code
that
we
have
and
then
we
publish
a
new
kind
of
data
to
the
user,
a
new
kind
of
data
to
the
the
user,
ui
yep
and
then
so
looking
into
the
code
right,
I've
seen
that
there
is
some
some
things
that
we
can
improve
on
based
on
this,
because
this
is
actually
like
a
very
a
very
initial
stage
of
the
implementation.
F
So
I
think
what
we
can
do
to
improve
is
that
we
can
define
the
filter
programmatically.
So
you
have
seen
that
the
filter
we
have
is
that
we,
we
kind
of
define
it
on
our
own
right.
So
I
think
there
should
be
a
way
that
we
can
define
it
programmatically
like
a
foolproof
kind
of
like
plan
and
then
the
second
one,
if
you
have
seen
like
our
measuring.
So
there
is
actually
a
kind
of
like
notification,
but
we
are
we're
not
currently
employing
anything
to
it.
F
D
Yep,
so
actually
you
mean
to
switch
from
using
sse
to
graphical
subscriptions
totally.
D
D
So
I
I
just
have
one
more
question
regarding
the
broadcaster
that
like,
if,
if
we,
if
there
is
no
a
particular
listener,
listening
to
a
particular
event,
I
mean
like,
oh
and
still
still,
the
data
is
being
sent
by
the
thing
which
is
sending
what
would
happen
to
the
data
I
mean
like?
Would
we
lose
it
or
would
that
would
will
that
be
a
way
to
retain
that
data.
F
Once,
for
example,
you're
not
you're
not
currently
subscribing
to
that
to
the
to
the
broadcaster,
if
you
don't
listen
to
that,
then
it's
already
like
the
data
is
lost
forever,
but
I
think
I
think,
in
the
misery
messaging
side
the
data
is
actually
persisted
and
then
what
you
can?
What
we
do
here
is
that
the
the
subscription
is
not
really
like
adding
any
kind
of
like
new
data,
but
instead
it's
it's
like
a
trigger
to
that.
F
B
I
particularly
appreciate
the
symmetry
in
your
diagram.
This
is
nice.
Thank
you
for
putting
this
together,
just
in
a
short
time
frame
as
well.
Let
me
ask
this
question.
B
What's
what's
our
critical
need
in
this
area
like
we
clearly
need
a
robust
eventing
system
and
message
framework,
and
it's
like,
as
you
would
phrase
it
like.
This-
is
the
initial
we
have
an
initial
implementation,
we're
kind
of
at
the
forefront
of
building
out
something
bigger
understanding
that
that
is
a
larger
item
and
that
it's
a
it's
an
architectural
component
kind
of
planned
for
v0.7,
like
the
release
that
we're
about
to
get
into,
I
mean
that
will
require
a
bit
of
you
know
a
bit
more
in-depth.
B
F
For
your
question,
I
think
the
the
pain
points
will
be
like
to
actually
start
implementing
this
kind
of,
like
broadcaster
throughout
the
system
yeah.
B
Okay,
let
me
let
me
tease
that
out
a
little
bit,
so
so
let's
say
so.
If
this,
if
we
don't,
if
there's
no
code
change
in
this
area,
what
aspect
of
measuring
suffers
currently,
I
should
know
this.
F
So,
actually,
through
the
discussions
that
that
we
have
had
in
the
past,
I
think
I
think,
there's
some
kind
of
problems
having
the
golden
channels,
like
like
multiple
going
channels
happening
in
the
system.
B
Nice,
okay,
good
it
does.
Can
anyone
else
help
refresh
our
memories.
H
Actually
so
one
issue
is
that
we
are
mixing
up
the
messages.
The
second
issue,
which
is
also
quite
a
big,
is
that
right
now
what
happens
is
that
a
a
blocking
client
can
block
the
entire
messaging
data
from
being
persistent
database,
and
that
is
something
that
broadcast
approach
is
sort
of
solving.
So
what
it
does
is,
of
course,
if
a
client
is
not
listening,
it
will
avoid
and
still
go
ahead
and
purchase
data
to
the
database,
which
is
the
desirable
behavior
or
else.
H
So
what
can
happen,
and
what
does
happen
is
if
the
client
has
blocked
for
any
reason,
the
channel
that
it's
listening
from
in
that
case,
the
data
will
not
be
positive
to
the
messaging
database.
That
measure
holds,
and
the
consequence
of
it
is
that
okay,
the
client,
maybe
does
not
need
the
data,
but
measure
itself
may
need
the
data
for
any
any
sort
of
operation.
So
that
is
another
issue
that
this
particular
approach
is
solving.
H
The
third
approach,
which
is
a
consequence
of
the
third
issue,
which
is
the
consequence
of
the
same
blocking
approaches
that,
when
missing,
actually
gets
blocked,
other
other
operations
of
graphql
also
tends
to
drop,
because
an
entire
gold
pin
is
blocked
for
that
particular
frame.
So
these
are
some
things
that
adding
broadcast
is
sort
of
solving.
At
the
moment,
please.
B
Nice
yeah:
what's
the
this,
isn't
an
uncommon
question
in
software,
but
what's
the
least
amount
of
effort
that
we
can
do
so
so
from
my
part,
I'm
convinced
we're
reinventing
the
wheel
or,
like
the
problem,
is
bigger
than
we're
dipping
a
toe
into.
What's
a
lot,
a
lot
larger
problem,
we're
going
to
want
to
have
a
lot
of
consistency
between
measuring
components,
we're
going
to
that's.
B
Why
there's
a
messaging
framework,
design,
spec,
that's
well
adjacent
to
what's
being
shown
here,
but
is
was
kind
of
created
under
well
under
it
was
created
under
different
pretenses,
but
it's
trying
to
achieve
the
same
thing
so
for
those
that
are
in
the
in
the
meeting
in
the
chat
there's
a
link
to
this
doc.
It's
long
or
not
it's!
Hopefully
you
can
just
read
the
first
part
and
kind
of
get
why
it
is
that
this
this
is
necessary.
B
To
well
assuming
that
everyone
agrees
like
plan
toward
these,
two
things
is
like
hey
to
overcome
the
the
three-ish
challenges
that
utkarsh
just
mentioned.
What's
the
least
amount
of
effort
that
we
can
put
into
the
existing
model,
this
this
semblance
of
a
broadcast
system
that
has
significant
kind
of
design
faults?
B
What
band-aids
can
we
put
on
there
or
what
quick
changes
can
we
make
while
this
larger,
more
holistic
approach
likely
reusing
an
existing?
You
know
message:
bus
technology
or
just
a
different
implementation,
a
different
well
tried
and
true
golang
implementation
of
of
a
broadcast
type
system
of
a
multi-channel
type
system.
B
So
this
so
so
later
on,
we
have
a
larger
need
for
to
describe
a
couple
of
things.
Measuring
has
a
bunch
of
components.
Those
components
need
to
interchange,
events,
let
each
other
know.
What's
going
on
talk
to
one
another,
ask
each
other
how
how
healthy
they
are,
what
they're,
what
they're
doing,
what
they're
capable
of
when
you
do
when
you
deploy
a
given
measuring
adapter?
Well,
the
adapters
are
individual
adapters
are
capable
of
different
things.
That's
why
there's
that's
why
they
are
adapters,
because
they're
they're
talking
in
this
case
to
different
service
meshes.
B
B
On
that
a
little
bit
as
well,
I
think
this
is
helpful,
and
I
know
this
is
kind
of
digressing
for
a
moment,
and
but
I'm
hoping
that
this
helps
give
everyone
the
right
context
and
gives
everyone
like,
as
we
go
into
we're
at
the
tail
end
of
a
release,
right
4.6
and
that's
the
most
important
set
of
things
for
us
to
be
focused
on.
But
at
the
same
time,
there's
a
little
bit
of
overlap
towards
thinking
on.
You
know,
planning
for
that.
B
Next
release
and
part
of
that
planning
would
be
the
potential,
not
the
potential
but
the
ideally,
the
the
breakout
of
load
generators,
there's
three
types
of
load,
generators
that
are
supported
inside
of
mesherie
and
in
order
to
achieve
some
in
order
to
achieve
distributed,
load
generation,
meaning
deployment
of
any
number
of
load
generators
around
a
cluster
or
outside
a
cluster
or
across
multiple
clusters,
and
have
those
generate
load
to
analyze
service
meshes
to
analyze
the
infrastructure
and
the
applications.
B
The
services,
how
they're
going
to
respond
under
that
different
type
of
load,
generated
sourced
from
different
vectors,
that's
necessary,
and
so
these
compo,
as
these
load
generators,
become
externalized
components.
They
too
in
some
respects.
You
know
they're
just
kind
of
another
adapter
if
you
will
so
so
as
an
external
component,
just
like
an
adapter
they're
going
to
need
to
be
able
to
speak
to
the
server,
to
the
extent
that
anyone
ever
by
the
way,
no
one
else
or
like
if,
if
anyone
all
of
you
that
are
here
are
probably
have
right.
B
Access
to
these
things,
you're
most
welcome
to
make
copies
of
the
slides
and
do
what
I'm
doing,
but
it,
but
don't
do
what
I'm
doing
in
line
like
this,
unless
you're
reviewing
with
a
maintainer,
it's
all
too
easy
to
mess
this
up
and
then
forget
about
it
and
I'm
the
one
that's
most
likely
to
do
it.
B
So
I
guess
it's
a
good
reminder
for
me,
but
these
individual
components
to
the
extent
that
mesherie
itself
is
a
distributed
system
comprised
of
a
number
of
different
services,
different
components,
mesh
sync,
the
mastery
operator,
the
these
externalized
load
generators,
the
adapters
there's
at
some
point,
there'll,
be
integrations
or
deeper
integrations
than
we
already
have
with
argo
as
an
external
system.
There's
plans
for
integrating
workflow
engine
internals
in
mastery,
like
so
depending
upon
how
people
want
to
deploy
mesri.
B
These
components
might
be
speaking
to
one
another
over
the
network
and
to
the
extent
that
that's
the
case,
mesherie
itself
also
has
distributed
systems,
concerns
and
challenges.
Part
of
that
is
making
sure
that
all
of
these
components
are
in
community.
In
communication,
we've
already
pulled
in
nats
as
a
core
component
of
that
messaging
framework,
and
I
would
purport
you
know
I
would
suggest
to
all
of
us
that
perhaps
nats
also
nat
server
also
needs
to
have
a
larger
role
inside
here.
I
think
that
we
need
to
do
that
analysis.
B
Maybe
nats
is
not
the
right
thing,
but
maybe
maybe
it's
something
else
by
the
way,
while
I'm
sharing
my
entire
screen.
Just
just
so,
everyone
knows
like
just
random
example.
Yesterday
I
was
giving
an
update
to
the
cncf
technical
oversight
committee
on
your
initiatives
and
so
so
keep
up
the
good
work.
B
Okay,
I
don't
know
if
that
hopefully
helps
give
context
to
the
fact
that
it's
a
larger
issue,
maybe
that's
what
most
of
you
are
taking
away,
and
my
hope
is
that
or
acknowledging
that
we
have
a
couple
of
issues
here
and
now.
B
It's
a
barrack,
so
geez.
Why
it
totally
totally
derailed
you,
I
think,
not
hearing
much
else
from
others.
B
I
think
you
mission
accomplished
like
in
terms
of
articulating
the
current
state
of
that
broadcast
system,
that's
implemented
in
go
if
you
would
be
so
kind
as
to
capture
in
written
word
the
three
I
think
three
open
challenges
that
would
crush
explained
and
then,
let's,
if,
if
we
can,
let's
itemize,
let's,
let's
identify
what
we
have,
what
we
think
we
can
do
right
now
without
trying,
without
forethought
as
to
building
out
our
own
new
pub
sub
system,
understanding
that
we're
likely
to
reuse.
B
A
Next
up,
we
have
a
review
on
the
v0.60
release,
so
we
have
this
document
which
we
have
been
bringing
up
for
a
while
now,
so
people
have
signed
up
to
test
some
of
these.
A
These
actions
that
uses
measuring
so
there
hasn't
been
much
updates
here
or
only
a
few
updates,
so
people
who
have
signed
up
to
test
this
please
make
sure
to
test
it
out,
and
I
I
know
that,
like
most
of
you
who
have
signed
up
has
works
other
other
in
other
places,
so
they
are
busy
fixing
bugs
and
adding
new
features.
A
So
so
this
also
means
that,
even
if
a
person
has
signed
up
to
test
a
particular
action,
you
can
also
others
can
also
add
their
names
here
and
test
it
out
as
well.
You
don't
need
to
wait
for
this
person
to
complete
it,
and
we
also
have
a
release
candidate
released
two
days
ago,
so
yeah
yeah.
So
please
test
that
tested
out
just
test
this
out
to
these
scenarios.
With
a
new
with
the
latest
release
of
measuring
so
yeah.
A
I
wanted
to
call
out
for
volunteers
to
come
in
and
test
this
out
right
now.
We
also
have
a
a
release-
blog
that
is
being
written,
so
we
have
a
lot
of
new
features
coming
up
for
this
release,
so
we
have
a.
A
We
have
a
release,
blog
that
explains
all
of
this
stuff.
So
saying,
would
you
like
to
point
out
which
areas
may
still
need
people
to
help
out.
A
G
Three
of
blogs
need
to
be
written,
so
one
is
applications
and
then
filters
and
we
have
dynamic
management
uis.
Other.
B
Nice
all
right
well
yeah.
This
is
this
is
the
week
so
for
just
you
know,
yeah
anyone,
that's
on
the
call
you're
welcome
to
either
review
something
that
someone
else
has
written
or
whether
you
contributed
to
these
areas
or
not
to
jump
in
I'll.
B
For
my
part,
I'll
take
the
the
last
one
that
that
beta
program,
the
dynamic
uis
as
well,
I
think-
that's
probably
pretty
hard
for
others
to
to
describe,
and
we
didn't
achieve
all
that
we
had
desired
in
this
release.
A
lot
of
what
was
achieved
in
this
re
release
around
dynamic,
the
dynamicism
in
the
uis
really
has
to
do
with
graphql
and
the
the
subscriptions
that
are
now
ongoing,
and
the
notion
that
the
more
and
more
of
the
screens
of
the
of
the
pages
in
measure
ui
are
just
you
know,
being
auto
updated.
B
I
was
going
to
say
refreshed,
but
that
sounds
like
you're
refreshing
the
screen,
but
the
the
there's
a
there's
a
subscription
there
there's
a
large,
obviously
like
in
part
to
what
I
think
nitish
will
talk
about
in
a
minute.
There's
a
large
architectural
change
for
measures,
ui
planned
for
the
dot
7
release.
B
Part
of
that
will
not
just
be
an
under
the
hood
architectural
change.
That's
that's
significantly
happening,
but
it'll
also
be
a
change
in
the
interfaces
like
the
the
the
widgets
and
the
components
that
users
are
interacting
with,
and
I
know
all
of
you,
everybody
has
an
opinion
about
ui
and
your
opinions
are
welcome,
like
the
suggestions
are
welcome
right
now,
like
the
way
that
the
user,
the
the
user
experience,
is
structured
in
mastery's
ui
dates
back
to
like
the
dot
one
of
measuring,
which
is,
there
was
a
server.
B
B
What
the
user
was
really
clicking
on
was
an
adapter,
so
you-
and
that's
still
the
case
today
in
the
measuring
menu.
If
you
click
on
the
name
of
a
service
mesh
what's
happening
is
in
real
time
there's
a
quick
exchange
between
mesh
reservoir
and
the
adapter
over
over
golang
to
over
grpc
to
from
actuary
server
to
ask
the
adapter.
B
What
are
you
capable
of
it
responds
and
then
the
capabilities,
those
features
of
the
adapter
are
then
displayed
here.
So
if
you
hit
refresh
menu
and
people
watch
for
a
moment,
see
where
it
says,
configure
settings
that
button
that
was
displayed
for
way
too
long,
apparently
the
vendor's
got
a
lot
of
open
tabs
or
whatever.
But
in
that
moment
in
that,
like
really
long
moment,
there
was
a
grpc
interaction
going
on
with
the
server
like
where
that
thing
that
I
just
said
was
is
happening.
B
B
Actually
you
can,
you
can
add
10
different
10,
istio,
adapters
or
10
of
any
kind
of
an
adapter.
So
mesh
read
supports
running
any
number
of
different
types
of
adapters,
also
any
number
of
the
same
type
of
adapters
and
the
ui
is
dynamic
in
that
way,
it'll
show
you
all
of
your
all
of
like
multiple
of
the
same
type
of
adapters,
so
any
one
of
you
can
try.
B
It
there's
an
instructions
in
the
docs
to
do
it,
but
just
a
random
example
of
like
well,
but
is
that
the
best
user
experience
like
do
users
want
to
be
navigating
how
to
manage
service
meshes
by
clicking
on
mesherie
components.
B
B
Actually,
I
think
it
was
last
week
when
we
met
we
had
an
extended
session
about
measure
ux
in
measuring
and
how
people
can
get
involved.
B
D
F
A
B
I
promise
to
be
brief
to
time
me
we're
using
jekyll
the
theme
that
we're
used
for
measuring
docks.
The
theme
that
we're
using
is
doxy
jekyll,
it's
a
rip-off
of,
or
it's
a
capia
or
it's
heavily
inspired
by
doxy.
Based
on
hugo
the
theme,
the
jekyll
theme
does
not
have
built-in
support
for
versions
like
versions
of
the
documentation.
B
That
means
that
measuring
docs
are
perpetually
at
latest,
which
is
fine
for
a
young.
The
meshery,
as
a
project
now
bothers
some
later,
as
people
as
many
users
come
run
meshery
and
they
want
to
know
the
difference
between
what
they're
running
now
and
what
they
could
be
running
and
and
so
without
the
facility
to
have
to
version
the
docks.
B
A
mesh
re:
this
is
one
of
the
areas
where
measuring
needs
to
grow
up.
It's
not
it's
in
concept.
It's
a
super,
simple
challenge.
B
It's
like
ridiculously
easy,
it's
not
yeah
and
then
and
then
for,
but
that
doesn't
mean
that
it
won't
be
hard
for
some
that
pick
it
up
so
anyway,
go
try
it
out,
like
there's
a
lot
of
thought
already
given
to
it
and
suggestions
and
and
there's
been
attempts
by
a
couple
of
people
in
the
past
to
make
it
happen
and
so
yeah
go
go,
there's
no
harm
in
trying.
I
encourage
any
of
you
to
pick
it
up.
A
D
Yeah,
so,
okay,
actually,
I
won't
be
explaining
what
we're
trying
to
do
here,
because
that's
what
we
have
been
doing
in
the
last
three
weeks.
So
if
you
want
to
know
more
about
what's
happening
here,
you
can
go
to
the
links
that
are
provided
in
the
meeting
minutes
and
yeah.
D
And
so
actually
I
would
say
that
yeah
right
now,
like
the
thing
that
we're
focusing
on
right
now,
is
to
create
components
to
first
of
all,
to
create
the
globally
reusable
components
which
will
be
building
up
on
those
things.
D
So,
as
a
part
of
that,
like
some
people
have
taken
up,
initiatives
and
people
are
working
on
that
already
and
if
you
want
to
know
if
you
want
to
like,
we
are
actually
tracking
that
in
a
spreadsheet-
and
I
have
also
linked
that
I've
given
a
link
to
that
in
the
meeting
minutes
as
well.
So
yeah.
D
If
you,
if
you're
interested
in
contributing
to
this,
and
if
you
want
to
write
you
know
contributors,
you
can
go
to
this
link
and
just
put
your
name
in
there
and
start
working
on
it
and
all
the
other
details
regarding
how
like
what
are
the.
How
to
get
started
and
all
those
stuff
I
like
that,
it's
pretty
much
covered
everything
is
covered
in
the
readme
file,
so
yeah.
D
I
would
just
point
you
guys
there
and
if
you
have,
if
you're
still
stuck
with
something,
then
yeah
being
on
slack
or
yeah,
people
would
help
out
so
yeah.
Actually,
that's
not
much
of
an
update
because,
like
people
are
still
working
on
it
and
yeah,
it's
a
it's
going
to
be
a
long
process.
So.
A
Thank
you,
nitesh,
as
nathis
mentioned,
I
just
shared
the
guide
to
contribute
contribute
to
this
area.
So
it's
in
the
it's
in
the
redmi
file
for
in
this
particular
feature
branch
so
do
check
it
out
and
the
other
details
can
be
found
in
the
meeting
minutes.
The
link
to
the
proposal,
as
well
as
the
spreadsheet
that
tracks
things
so
jump
in.
If
you
are
interested
in
working
on
ui,
all
right
and
next
up
aditya.
D
Yeah,
so
so
yeah
so
like
I'm
trying
to
work
on
the
issue
which
tries
to
fix
the
design
of
linkage
adapter,
but
the
adapter
is
not
connecting
right
after
trying
many
steps
I
had
talked
with
aditya
also,
and
he
guided
me
through
all
the
steps,
but
still
the
adapter
is
like
not
being
connected
and
showing
some
random
errors.
A
While
you
prepare
your
environment
ashish,
would
you
like
to
give
an
update
on
the
sqlite
migration.
E
Yeah
yeah
just
a
little
update.
I
will
give
the
link
of
the
pr
inside
the
chat
we
are
currently
for
persisting
a
few
things
like
test
profiles
and
smi
results,
and
even
the
user
preference
like
the
gates,
config
and
all
we
are
using
bitcast.
So
with
my
current
pending
pr,
we
would
be
moving
completely
away
from
bitcast
to
sqlite,
so
the
entire
everything
in
the
meshes
would
be
using
sqlite.
E
B
Hey
on
that,
as
as
people
think
about
what
ashish
just
said,
this
moving
like
migrating
databases
bitcast
to
sqlite
there's,
if
you
still
have
the
link
to
the
arc,
meshery
architecture
deck
that
we
were
looking
at
earlier,
there's
a
slide
in
that
deck
that
talks
about
that.
I
think
it's
like
slide.
Nine,
maybe
not
that
I
memorized
the
deck
number.
You
know
slide
numbers
or
anything,
but
so
this
talks
about
the
fact
that
there
are
well
a
few
places
for
state,
for
you
know
like
for
data
persistence.
B
Actually,
the
the
footnote
at
the
bottom
of
the
table
that
ashish
is
working
on
bitcasts
going
away.
Eventually,
then
sql
light
even
goes
away
and
postgres
becomes
a
kind
of
the
core
database
within
meshary.
One
of
for
what
it's
worth.
One
of
the
reasons
that
okay,
the
one
of
the
reasons
that
bitcast
is
going
away,
is
because
well
it
is
because
we've
outgrown
it
like,
and
it's
not.
B
We
have
a
bit
of
trouble
with
it
as
well.
Meshri
had
used
a
different
golang
based
file
based
data
store
in
the
past,
and
I
can't
remember
the
name
there's
by
the
way,
if
anyone's
seen,
rocksdb
from
facebook,
that's
kind
of
an
intriguing,
potentially
neat
one
to
use.
In
this
case,
the
project
is
headed
toward
postgres
and
away
from
sql
light,
even
in
part
because
of
what
what
I
mentioned
before,
there's
and
there's
a
couple
of
additional
architectural
components
to
come
to
come
into
mesherie
before
it's
1.0.
B
One
of
those
components
is
a
workflow
engine.
The
workflow
and
there's
details
on
this
in
the
community
drive
that
workflow
engine
will
require
postgres,
that's
part
of
the
logic.
A
There
is
a
link
to
this
pr
in
in
the
chat
you
can
check
it
out
as
well.
Leave
mario
going
to
mention
something.
F
D
Yeah
all
right
so
yeah.
So
sorry.
D
Right
so
this
is
the
look
9001
hey
like
908.1
port
and
I've
used
docker
desktop
and
it
seems
to
be
connecting
successfully,
but
when
I
go
into
the
linker
tab,
this
happens
this
unexpected.
D
B
B
B
With
an
s
on
the
end,
so
yeah
for
reasons
that
I
don't
think
are
necessary
anymore,
it
used
to
be
the
case
like
back
when,
like
mystery
was
just
forming,
there
was
the
there
was
the
need
to
override
to
have
an
alternative
name
for
adapters
other
than
localhost
anymore.
I
don't
believe
that
that's
necessary
in
the
project,
so,
but
that
old
architect
that
old
design
has
persisted,
and
maybe
we
need
to
go
change
it
so
right.
The
way
that
when
you
run
when
you
build
meshry
locally
mastery
server,
you
run
it
it.
B
It
comes
with
some
environment
variables.
Predefined,
like
it
assumes
that
you,
you
would
run
all
the
adapters
and
when
you
do
that,
those
adapters
would
be
available
on
their
predefined
port,
like
one
ten
thousand
one
for
linker
d
and
that
the
address
of
those
well,
the
thing
is
you're
using
well,
I'm
like
see
the
anyway
that
the
address
of
those
is
available
at
what
is
it
measuring
local
dot?
What
is
it
if
you
go
back
to
measures
ui.
B
To
to
the
other
tab,
yeah
all
right,
yeah
and
you
go
to
the
dashboard,
the
chips,
the
quote-unquote
chips,
the
adapter
chips,
where
it
says
meshri.local.measurelocal.letter5.org.
B
If
you
were
to
add
an
entry
to
your
hosts
file
to
point
that
name
to
your
loopback
address
to
your
local
host,
you
might
find
success.
That's
kind
of
one
thing
that
jumps
out
at
me.
The
second
thing
is:
if
you
go
to
the,
if
you
go
to
settings
and
you
yeah
and
you
go
to
service
meshes,
yes,
wait
what
happened.
B
B
And
then
you
hit
return
and
then
you
click
the
button
connect
by
the
way
so
mana
I
get
to
pick
on
you
for
whatever
reason
this
and
actually
a
detail.
I
know
you're
actually
trying
to
work
on
this
type
of
ui
component.
That
ui
component,
like
requires
that
you
hit
enter
and
then
hit
the
button.
It's
kind
of
weird,
but
anyway.
A
B
B
So
if
you're
running
linker
d,
okay,
so
that
makes
sense
right
there-
that's
actually
a
great
error
or
a
great.
It
says
it
can't
initialize
the
connection
to
the
adapter,
because
it
can't
talk
to
the
cube
config
is
not
configured
while
that
shouldn't
be
the
case,
while
it
shouldn't
be
the
case
that
you
know,
while
it's
ideally
not
the
case
that
an
adapter
requires
kubernetes
connection,
it
is
the
case
and
like
it's
probably
fine,
like
none
of
the
service
meshes
that
are
out
there
today
run
out
of
context
of
kubernetes.
B
So
it's
fine
that
there's
that
dependency,
but
in
your
environment
it
seems
that
your
meshry
server
is
not
necessarily
connected
to
kubernetes.
So
if
you
go
to
the
yeah
click
this
to
be
able
to
talk,
and
then
what
kind
of
you
have
docker
desktop
deployed,
yeah.
H
B
Let's
see
so,
if
you
bring
back
up
the
logs
for
the
server
this
one
yeah,
is
that
a
trailing
set
of
logs
like
so
we
look
at
the
last
couple
of
so
upload.
Your
kubernetes
like
it's
like
your
cube.
Config
is
not
initialized
like
all
right.
I
wonder.
Can
you
do
me
a
favor?
Can
you
just
go
back
to
settings,
go
to
environment,
kill
your
kubernetes
connection
like
x,
the
like
yeah
this
one.
B
If
you
read
sure
you
refresh
your
screen,
meschery
always
tries
to
stay
connected
to
kubernetes,
so.
B
B
And
we
should
record
this
and
put,
but
like
you're,
not
the
only
one
that
has
bumped
into
this.
So
anyway,
the
there
is
there's
a
couple
of
things
to
do.
One
is
to
raise
the
issue
about
an
unexpected
error,
like
that's,
probably
not
what
we
want
for
people
to
see
if
they
don't
have
a
particular
service
mesh
connected
or
adapter
connected
all
right.
B
I
don't
believe
that
that's
a
necessary
reference
any
longer
and
instead,
like
the
mesh,
the
nginx
one,
that's
probably
what
we're
going
to
try
to
arrive
at.
B
Like
chips,
yeah,
not
the
removal
of
them
and
actually
I've
explained
it
a
couple
of
times
now.
So
probably
I
won't
again
like
actually
I'll
take
that
action
item,
but
if
you
would
take
the
action
item
to
file
the
other
unexpected
error
issue,
that
would
be
great
all
right.
B
By
the
way,
it's
like
that
was
a
cool
kind
of
a
cruel
trick.
Right
like
we're
there,
there
was
something
amiss
where
mesherie
is
able
to
connect
to
kubernetes,
that's
saying
it's
connected
and
then
on
the
setting
it
for
the
settings
for
the
adapter.
It's
saying.
Actually,
your
cube
config
is
not
correct.
B
B
Hopefully,
we'll
see
people
at
kubecon
for
the
measuring
session
for
the
service
mesh
performance
session.
It's
really
late
for
some
of
you,
there'll
be
a
number
of
you
that
are
hopefully
they're
representing.
B
We
also
are
quite
involved
in
the
service
mesh
working
group
and
the
cncf
so
really
like
the
service
mesh
performance
meeting
that
is
held
every
other
thursday,
we're
going
to
turn
that
it's
basically,
that
has
been
the
cncf
service
mesh
working
group
meeting,
because
we
talk
about
get
nighthawk
service,
mesh
performance
service,
mesh
patterns,
testing
in
the
cncf
lab.
B
We
talked
about
smi
conformance
in
there
as
well,
because
the
30
minute
smi
call
that
bridget
man
handles.
You
can't
get
done
that
we're
going
to
give
an
update
at
the
scene.
There's
a
there's,
a
third
talk
that
we'll
give
it's
a
cncf
tag
network.
A
All
right,
then,
we'll
see
everyone
at
cupicon,
bye.