►
From YouTube: Meshery Development Meeting (Jan 27th, 2021)
Description
A new release of Meshery is in the works! Want to help?
C
Today
we
got
a
bunch
of
old-timers
and
a
couple
of
people
returning
back
to
us,
but
I
can't
really
spot
any
newcomers.
So
all
right.
Welcome
to
the
mystery
death
call
everybody
we
take
a
day
every
week,
because
that's
everything
related
to
mystery
and
related
projects
be
free
to
add
any
topic
to
the
agenda.
C
B
Yeah,
sorry,
sorry
about
that,
I
I
didn't
realize
it
was
mute.
Yeah
hi,
guys,
I'm
pranav,
I'm
a
third
year
student
in
india
and
I've
been
for
the
better
part
of
this
week.
You
know
working
with
the
community
to
on
various
issues
just
exploring
around,
so
I'm
also
just
sticking
around
this
call
to
see
what's
going
to
happen
and
to
learn
more
hopefully,
so.
Thank
you
so
much
for
having
me.
C
All
right
so
interesting
week
we
have
a
mastery
version,
0.5
release
coming
up
and
that's
pretty
exciting
and
that
we
will
be
discussing
a
couple
of
items
related
to
that
on
this
particular
call.
If
you
want
to
contribute,
there's
a
link
to
the
issues
pertaining
to
it.
Go
pick
something
up.
Go
assign
yourself
to
it
and
push
through
you're.
Very
welcome
to
do
that.
If
you
have
any
questions,
you're
very
free
to
ask
them
on
this
call
or
engage
us
in
slack
or
any
way
that
you
want
to
post
that.
C
A
C
A
E
D
Controlling
two
of
our
custom
controllers,
which
are
mesh
sync
and
measuring
broker
so
mesh
sync,
is
an
application,
a
custom
controller
that
scans
for
scans
for
the
state
inside
the
cluster.
Basically,
the
current
state
of
the
cluster
and
gives
back
the
data
in
short
and
measured
broker
is
nothing
but
a
a
queueing
application
where
you
can
publish
and
consume
messages
whenever
and
wherever.
D
A
A
A
The
adapters
like
you
know
all
you
know
entirely
rewritten
and
then
and
then
the
other
components
that
that
abishak
was
just
mentioning.
So
we
need
to
do
some
testing.
We
need
to
write
up
this
stuff
to
both
inform
users
of
what's
going
on
what
those
components
are,
what
they
do
also
to
help.
You
know
get
the
word
out
to
those
that
don't
know
about
mesri
and
who,
who
might
come
to
use
it
might
find
value
so
there's
some.
A
The
measuring
docks
needs
needs
a
little
bit
of
help
as
we're
doing
that
there
are
some.
I
guess
you
know
some
some
feature
deep.
Dives
some
blog
posts
that
that
can
be
written
and
there's
an
opportunity
for
each
of
you
to
get
your
name
out
a
little
bit,
also
kind
of
mark
your
name
on
on
an
aspect
of
the
project.
It's
an
aspect
that
you're
familiar
with
that
that
other
dock
that
street
would
be
showing
there's
a
number
of.
So
I
guess
it's
here.
A
Actually
these
issues
here
we
want
to
get
these
assigned,
or
rather
I'll
say
if
these
are
interested
interesting
to
you.
If
you
worked
on
them,
go
ahead
and
self-assign,
probably
toward
the
end
of
the
week,
if
they're,
not
self-assigned,
I'll,
assume
that
that
one
of
the
one
of
the
core
maintainers
will
pick
it
up
and
and.
A
A
A
That's
a
great
question:
I
think
that
the
it's
a
little
bit
hard
to
definitively
say
it
it
kind
of
if,
let's,
let's
just
assume,
that
we
don't
find
any
bugs
in
this
current
beta,
which
you
know
like
the
likelihood
of
that
happening,
is
probably
pretty
low.
We've
got
a
couple
of
things
in
maestri
ctl
that
have
yet
to
be
completely
tied
off.
Context
should
have
been
tied
off
a
couple
of
weeks
ago,
but
it's
still
kind
of
hanging
out
there.
A
I
might.
I
would
anticipate
that,
like
that,
we'll
end
up
going
through
either
one
or
two
more
beta
releases,
maybe
switching
it
over
to
like
a
release
candidate,
which
is
just
sort
of
a
further
way
of
saying
that,
like
this
thing's,
even
I
don't
know
why
I'm
explaining
that
to
you,
but
but
anyway,
that
we're
getting
closer,
I
think
the
reality
is
it'll,
probably
be
like
another
two
and
a
half
weeks.
A
I
suspect,
of
you,
know
activities
of
going
through
some
tests
kind
of
validating
that
really
the
the
newer
components,
work
well
the
adapters
and
that
that
rewrite
those
have
been
being
baked
and
tested
for
for
a
while.
You
know,
and
those
are
generally
sitting
in
a
fairly
pretty
place
like
the
console
adapter.
For
example,
the
istio
one,
the
linker
d,
the
others
traffic
mesh
kuma.
A
F
G
A
F
A
A
C
A
A
A
F
A
If
anyone
has
a
hankering
to
do
to-
and
michael
actually
you've
done
this
in
the
past,
like
if
you've
got,
if
anyone
wants
to
re,
do
a
demo
of
what
they've
done
or
of
that
feature
either
if
you'd
like
to
do
it,
if
you'd
like
help
doing
it,
if
you'd
like
for
someone
else
to
do
it,
but
have
it
included
in
your
post
like
we
can,
I
guess
you
know,
go
go
nuts
that
will
will
help
I'll
I'll
help.
Others
here
will
help.
A
A
A
A
A
Of
but
yeah
there
are
you're
right
by
the
way.
Just
drew
brings
up
a
good
point
about
like
availability
of
assets,
and
you
know
graphics
and
logos
and
things
all
of
the.
So
there
are
brand
kits
there's
a
brand
kit
for
mastery
operator
for
mesh
sync
for
mesherie
and
there's
templated,
google
slides
templated
there's
a
lot
there's.
A
All
all
of
these
things
are
in
the
google
drive
like
there's,
there's
quite
a
bit
in
there,
so
don't
and
if
you
can't
find
it
or
if
you
need
something
new
yeah,
please
just
please
just
raise
your
hand.
Actually
augustine
is
probably
the
person
that
I'll
point
you
to
again,
because
both
he'll
be
capable
of
creating
something
new
he's
kind
of
reworking.
Some
of
the
the
templates
that
are
there
and
available
to
everyone
so
and
those
templates
are
there
for
you
for
this
purpose.
So.
A
A
A
F
F
We
started
discussing
a
bit
how
to
extend
the
api
where
and
then
it
sort
of
stalled.
So
I
think
it's
not
nothing
happened
since
then,
but
I
think
it
would
need
a
change
and
then
you
know
everyone
is
when
you
start
looking
at
that,
then
you
say:
oh
maybe
we
should
have
a
sort
of
a
general
endpoint
that
that's
called
you
know
get
info
or
something
that
you
know
that
all
components
provide.
I
had
to
get
info
about
this
component,
like
version
and
name
and
then
suddenly,
it
gets.
A
A
A
F
Sorry,
I
think
it
would
be
really
useful
to
have
sort
of,
like
you
know,
an
expected
endpoint,
even
though
you
have
to
implement
it
in
the
different
product
buffers
and
your
pc
interfaces
and
and
and
use
some
time
to
sort
of
like
discuss.
You
know
we
should
have
a
couple
of
fixed
fields
or
a
map
or
and
where
it
should
live
and
stuff
like
this.
A
All
right,
I
agree,
yeah,
sorry,
no,
no,
you
know,
and
I
wish
there
was
yeah.
I
wish
it
was
pretty
funny
like
I
wish
that
there
was
like
how
has
this
not
been
done
already?
How
is
there
not
just
something
of
a
central,
spec
or
central
proto
that
you
know
kind
of
like
simple
network
management
protocol
snmp
or
like
prometheus,
like
the
the
people,
are
implementing
service
status
met
counters
like
like
you
know,
every
micro
service
needs
this,
like
I'm
sure
it's
been
done,
thousands
of
times
over.
A
Okay,
so,
and
actually
not
to
to
blow
that
up
and
expand
it
even
more
and
make
it
even
harder
to
get
done
is
like
when
you
toss
in
the
concept
of
something
like
open,
telemetry
and
use
of
it
in
meshkit
as
a
framework
for
instrumenting
the
component,
you
know
instrumenting
the
components
that
are
using
meshkit.
It's
like
oh
well.
You
would
think
that
a
project
like
that
might
have
a
central
reference
for
slash
info
like
this
thing
that
we're
so
yeah,
okay.
A
A
A
C
H
H
H
So
that
is
one
thing
and
another
feature
is
now:
has
the
global
verbose
flag,
so
this
can
be
used
anywhere
throughout
measure
exceeded
it?
It
is
available
globally,
like
it
can
be
used
to
print
the
debug
logs,
basically
everything
workbooks,
but
we
don't
have
that
many
debug
logs
currently,
so
we
might
need
to
add
them
along
the
way.
As
we
build
more
components
for
measures,
he
did
yeah,
that's
it.
F
F
A
G
A
Is
not
very
well
written
or
written
very
much
and
in
its
the
spec.
It
goes
by
the
name
of
I
think
it's
mesherie
messaging
system,
which
refers
to
like
error
codes
and
how
we've
intentionally
set
aside
room
for
error
codes
and
what
they
are
and
how
to
what
their
probable
cause
is,
how
to
remediate
them
et
cetera,
but
like
as
part
of
that
sort
of
the
this
there's
a
collection
of
concerns
around
what
we
were
just
talking
about
before
the
slash
info,
endpoint
or
or
whatever.
A
The
name
is,
but
just
that
that
concept,
the
concept
of
then
having
a
structured
framework
for
facilitating
troubleshooting
of
error
codes
that
might
arise,
and
then,
along
with
that
is
it.
You
know
precisely
what
you're
you're
pointing
out
as
well
is
like.
Well,
you
know
multiple
ways
to
get
like:
hey
the
logging.
That's
going
on
you're
able
to
use
mastery
ctl
to
examine
logs
from
I'm
a
little
confused
on
this.
A
F
I'm
not
quite
sure,
if
I
remember
I
didn't
look
closer,
I
think
it's
it's
the
same.
You
get
the
same
and
I
think
the
adapters
are
at
least
you
know
the
one
I
was
looking
at
this
sort
of
like
a
little
bit
the
same
issue
as
with
measuring
ctl
they're,
not
so
many
debug
statements
and
a
challenge.
There
is
also
you
know.
How
do
you
sort
of
like
have
a
good
client?
What
is
debug
and
what
is
not
debug,
but
it's
it's
the
the
locking
framework
in.
F
Mesh
kit,
machine,
adapter
library
is
prepared
to
have
a
debug
label
as
well,
but
it's
not
sort
of
like
that.
You
can
switch
it
on
with
a
flag
so
being
able
to
switch
it
on
by
some
means.
You
know
using
measuringctl
so
that
this
is
propagated
to
the
adapters
and
switching
on
debug.
I
think
that
would
be
a
very
useful
feature
also
with
respect
to
these
trolls,
where
it's
even
it's
more
difficult.
A
A
H
A
When
we
go
to
support
context,
we
go
to
that
support
for
context,
touches
each
and
every
mastery
ctl
system
command
related
to
that,
but
also,
but
also
just
independent
of
that
is
the
ability
for
measuring
ctl
to
when
you
go
to
start
measuring.
If
you
run
mastery
ctl
system
start
that,
maybe
you
want
to
spin
up
some
docker
containers
on
your
local
host
or
maybe
you'd
like
to
deploy
mesherie
in
cluster
in
kubernetes
cluster.
A
It
speaks
to
how
to
bring
support
for
deploying
from
measuring
ctl
to
deploy
into
a
kubernetes
cluster,
so
how
to
make
sure
that
when
you
do
measure
ctl
system
start,
if
you
want
from
azure
to
go
into
kubrick,
do
you
be
deployed
in
kubernetes
how
to
make
that
happen
and
bendy?
Do
you
want
to
talk
about
the
considerations
that
you've
made.
H
Yeah
the
like
the
first
thing
was
to
whether
we
have
to
use
mesh
gate
in
master
ctl,
because
it
has
a
lot
of
predefined
support
for,
like
the
deploying
the
manifest
files
and
stuff
like
that.
So
yes,
here
suggested,
we
definitely
need
to
use
meshkit
and
yeah.
We
we
also
like
discussed
about
supporting
the
air
gap
deployments,
which
I
think
would
be
great
for
on-premise
deployments
and
it
seems
like
we
already
have
users
wanting
that
support.
That's
going
to
support
so
like,
as
lisa
suggested.
H
A
A
Oh
yeah
boy,
how
do
we?
How
do
we
structure
this?
I
guess
you
know
one
of
the
the
so
I
think
on
the
first
point
of
like
use
of
helm,
charts
or
use
of
kubernetes
manifests
in
the
either
way.
I
don't
think
that
we
will
go
wrong
like
like
you
know
so
long
as
we
do.
One
of
them
we'll
be
in
a
better
place.
A
A
couple
of
thoughts
about
the
use
of
help,
so
part
of
the
value
of
using
helm
here
is
that
you're
able
to
use
templatized
you're
able
to
go
over
to
values.yaml
and
given
that
those
values
have
been
templatized
in
the
rest
of
the
you
know,
the
kubernetes
manifests
you've
got
a
a
relatively
easy
place
to
control
the
config
of
that.
You
know
the
options
for
that
chart.
A
A
A
It
falls
in
line
with
the
structure
that
we
have
today
for
kind
of
directly
using
and
compiling
a
docker
compose
file
that
the
values.yaml
in
the
helm
chart
is
really
ends
up
being
pretty
similar
to
the
config.yml
that
messry
ctl
has
because
config.yaml
says
things
like
what
adapters
do
you
want
to
run?
What
channel
and
what
version
do
you
want
to
be
on?
What
token
do
you
want
to
use
you,
just
I
think,
they'll
be
the
list,
will
expand
a
little
bit.
A
F
A
I
think
we're
on
a
path
to
suggest.
Currently
we
download
it
or
like.
If
you
look
at
what
we
do
with
docker
compose,
we
download
it,
you
don't
as
a
user,
you
generally
don't
feel
that,
because
it
sort
of
happens
implicitly
as
you
either
do
the
bash
installer
and
whenever
you
run
sys
message
system
start
like
it
does
it,
and
then
you
don't
you're,
not
really
paying
attention
to
the
fact
that
that
happens,
that
is
bothersome
for
there's
a
couple
of
issues.
A
You
don't
have
that
concern
about
versioning,
because
it's
like
the
version
appropriate
manifesto
right
there,
bundled
with
your
client.
It
is
that,
does
you
know,
instead
of
just
downloading
a
single
binary,
like
you
end
up
downloading
a
few
files
since
there's
a
bash
installer,
I
don't
think
that's
an
issue,
that's
kind
of
behind
the
scenes.
People
don't
have
to
worry
about
it.
The
bundling
some
of
this
stuff
in
into
the
to
the
ctl
package
means
that
supporting
air
gap.
Things
is
maybe
a
little
bit
easier
because
you
kind
of
got
all
that.
A
You
need
locally
already,
where
we
end
up
right
now,
we're
kind
of
straddling
the
line
between
when
every
time,
if
you're
familiar
with
cube
ctl,
whenever
someone
goes
to
invoke
a
cube,
ctl
command,
it
will
reference
your
local
cube,
config
on
the
fly
from
from
disk.
You
know
from
or
from
the
command
line,
if
you're,
providing
it
and
every
single
time
you
execute
the
man,
you
have
to
have
a
cube
configurative
source
from
there
and
it
needs
to
know
you
know
it's
not
a
it's
a
it's,
not
a
long-lived
process.
A
A
C
A
Or
you
know
it
based
on
the
ability
to
write
out
those
manifests,
doc
or
kubernetes
or
docker,
so
we're
kind
of
between
kind
of
straddling
defense
between
needing
to
source
from
an
external
you
know
manifest
and
all
that
it
can
contain
which
like
and
having
that
built
into
mastery
cto.
I'm
not
saying
you,
I
don't.
I
don't
think
it's
the
right
thing
for
us
to
go
over
and
build
in
all
the
things
you
can
put
into
kubernetes
manifest.
You
know,
that's
not
the
so
a
couple
things
that
you
sense.
A
Or
I
think
that
what
we
currently
have
for
how
context
works
for
docker
compose
works
pretty
well,
it
might
be
nice
if
we
start
to
bundle
in
the
compose
file
and
the
manifest
files
such
that
it's
not
absolutely
required
for
when
you
do.
A
master
ctl
system
start
that
it
for
the
first
time
has
to
reach
out,
because
that
could
cause
a
hiccup
if
you're
in
an
air-gapped
environment,
and
so
we
have
some
controls
yeah,
which
we're
we're
almost
to
a
really
sweet
spot
sort
of
in
today's
design.
F
Well,
yes,
I
see,
I
see
all
that
the
one
one
point
to
consider
is
that
that's
why
I
thought
sort
of
thinking
about
suggesting
helm
is
is
a
parametrized
parametrization
of
the
manifests,
I
think,
for
the
air
gap
deployment.
You
would
want
to
change
a
couple
of
parameters
with
this
spec
to
where
to
get
the
images
from,
and
maybe
you
know
and
and
of
course
you
can
do
that
also
with
manifests.
If
we
do
templating,
there
is
templating
included
in
meshkit
that
you
can
use
for
the
manifest,
but
then.
F
Of
course
turn
the
manifests
into
templates
with
the
placeholders
so
that
this
works
and
the
support
for
is
not
very
advanced.
I
think
it's
just
replacing
single
and
simple
variables,
I'm
not
quite
sure,
but
anyway
and
in
the
helm
this
is
sort
of
like
baked
in
right
from
the
start,
the
parameterization,
and
so
so.
This
is
sort
of
at
one
point
we'd
like
to
consider,
because
I
I
think
you
know
so
maybe
you
know
when
you
think
you
know
a
local
environment.
F
You
always
have
one
note,
but
when
you
deploy
to
a
appropriate
environment
production
for
instance,
then
probably
you
will
have
several
notes
and
you
would
like
to
have
several
replicas
of
your
things
and
then
you're
already
in
the
game
of
parameters.
Parameterizing
your
manifest,
for
instance,
just
sort
of
like
a
point
too.
I
think.
A
You
you
definitely
have
to
do
support
exactly
what
you
said
like
you
definitely
have
to
let
people
use
so
right
now.
I
think
in
mexico
ctl
it
identifies
where
the
registry
is,
I
think,
as
a
global
variable,
and
if
that's
not
the
case,
we're
going
to
have
to
do
that.
We're
going
to
have
to
let
people
specify
a
different
registry
and
and
and
in
many
respects,
like
the
config.yaml,
all
of
the
anything
that's
inside
config.yaml,
the
mesh
config
meschery
ctl
config.
A
Those
all
need
to
be
parameters
that
are
yeah.
All
of
those
things
in
there
do
need
to
be
parameterized
in
docker
compose
and
in
kubernetes
manifests,
and
so
all
the
things
you
just
said
are
totally
true,
and
so
I
don't
have
a
strong.
This
isn't
as
strong
it
I'm
equally
as
happy
to
for,
for
my
part
to
go
with,
did
who
else
has
got
something
to
to
add
to
help
us
move
forward.
D
D
What
I
was
saying
is
that
mystery
ctl,
if
measuring
ctl,
is
going
to
have
this
conflict
of
confirming
the
registry,
then,
ideally
in
other
places
they'll
have
to.
I
they'll
have
to
inherit
from
that
one
place
like
right
now.
They
they
have
their
own
way
of
managing
their
endpoints
and
places
their
fetch
assets
from
so
we'll
have
to
centralize
things.
Whatever.
A
Yeah,
so
the
config
config.yaml
for
that,
for
that
context,
sounds
like
the
source
is
a
source
of
truth.
For
how
a
given
measuring
deployment
is
configured
the
mechanics
of
how
those
values
are
disseminated,
I
guess
yeah
michael,
maybe
that's
one
way
of
reflecting
on
it
is,
is
sort
of
the
maybe
the
inverse
of.
C
A
A
F
A
A
For
I
think
part
of
my
thinking
was
like
hey.
We
need
those
the
we
need.
Templatized
things
we're
going
to
be
the
we're
going
to
empower
the
user.
With
these
parameters
they're
going
to
affect
you
know,
they're
going
to
take
effect
in
a
couple
of
places,
the
mesh
config,
the
config.yaml.
We
can
assort
the
source
of
truth
for
any
give
for
the
configuration
of
any
given
deploy
any
given
deployment.
A
F
A
A
F
A
And
there
is
all
right
yeah
the
chart
does
get
published
to
well.
That's
part
of
our
issues
like
right.
Now
we
don't
have
this
is
this
is
kind
of
like
the
only
like
it's
the
only
plus
point,
five
that
I
can
give
to
the
manifest
is
more
or
less
what
you're
saying
michael,
which
is
like
I
should
be
like.
We
can't
have
the
code.
We
can't
have
the
code
and
structure
for
that
approach
today
and
it's
a
little
bit
more
of
the
same.
A
It's
a
few
more
yaml
files,
but
what
we
don't
have,
and
so
because
we
don't
have
ci
for
our
helm
chart
because
we
don't
have
because
we're
not
using
because
we're
doing
direct
yamaha,
manipulator
yaml
file.
Manipulation
today
was
like,
oh,
that
felt
like
a
natural
path,
not
that
that
was
necessarily
the
best
path
or
like
like.
A
I
think
I
would.
If
we
were
already
using
helm
to
manipulate
docker
compose,
I
would
be
making
this
the
argument
for
dockercon
for
helm
and
so
yeah.
Please
don't
concede
to
be
nice,
because
because
I
don't
care
because
this
doesn't
it
it's
it's
mostly
just
like
hey
novena.
Can
you
get
this
done
into
and
it's
like
hey
we're
going
to
make
this
release,
and
is
this
going
to
be
included
in
the
release
that
we're
going
to
support
context
for
kubernetes
yeah
yeah?
That
would
be
ideal.
Okay.
Can
you
get
that
done?
A
G
A
G
Yeah
then,
even
if
you
have
the
kubernetes
dashboard
or
something
where
you
can
see,
your
deployments
add
a
new
deployment
and
that
one
is
first
time
mastery
and
then
you
can
configure.
You
can
let's
say:
try
a
dummy
install
of
mastery,
not
dummy
easy
from
a
dashboard.
But
does
it
make
sense?
What
I'm
saying.
G
Like
yeah,
exactly
one
it's
actually
it's
called
like
kubernetes
dashboard
or
something
it
does
need
on
it's
to
have
out
that
administration,
kubernetes
module,
but
yeah
or
I
don't
know-
or
for
us
or
take
a
kubernetes
distribution
which
I
don't
know
to
give
more
example
I
but
yeah.
So
the
thing
is:
have
a
dashboard
where
you
can
see
your
kubernetes
services.
You
can
see
your
context
or
switch
quant
of
context
and
yeah
just
from
there
install
the
the
thing
that
you
wanted
to
do
with
helm,
but
don't
do
it
with
her.