►
From YouTube: Meshery Development Meeting (Jan 6th, 2021)
Description
Meshery's CLI - mesheryctl has a new command!
B
A
A
A
C
B
B
If
you're
new,
on
the
call
please
take
a
minute
to
introduce
yourself,
make
sure
that
you
can
access
the
meeting
minutes,
a
link
is
provided
in
the
chat.
If
you
can't,
please
do
speak
up,
you
should
be
able
to
access
it
if
you
have
been
onboarded
as
a
community
member
post
that
we
have
a
pretty
good
agenda
today,
so
we
can
start,
but
before
we
do,
are
there
any
new
comments
on
the
call
except
note.
A
A
Happy
new
year
nice
to
have
you
here
thanks
for
joining,
we
like
to
make
everyone
feel
uncomfortable
and
introduce
themselves
just
to
so
everybody
can
get
familiar.
Are
you
whereabouts?
Are
you
coming
from
physically
turkey?
I
am
from
turkey,
istanbul
wow,
very
good,
all
right.
Why
are
you
you
might
be
about
seven
hours
ahead
of
me?
I
suspect
I'm
I'm
in
texas,
so
I'm
still
on
my
this
is
like
my
first
cup
and
a
half.
I
guess
so
it's
my
second
cup
yeah.
A
Oh,
very
good:
okay!
Well,
thanks
for
jumping
in
it's
nice
to
have
you
here,
you're,
making
you're
asking
the
right
questions
you're
digging
in
it's,
that's
good!
Thanks
for
tossing
in
a
topic
as
well,
we'll
we'll
we'll
be
sure
to
get
to
the
documentation
request.
That's
great
anirude!
You
can
go
ahead
and
put
your
we're.
Gonna
put
your
topic
first,
since
we've
gone
round
this,
so
thanks
a
bunch
for
being
here
mert.
But
I
read.
A
Let
me
let
me
set
the
stage
for
some
of
the
things
we'd
like
to
try
to
do,
which
is
you
know,
be
collaborative
share
on
our
designs.
Engage
people
early
in
our
thought
process.
So
people
can
collaborate
on
the
designs.
Anirude
is
trying
to
work
through
a
design
on
mastery
ctl
system
channel
around
a
context,
so
we've
recently
described
and
defined
a
new
construct
in
measuring
ctl.
It's
called
context
and
I'll.
Take
this
since
would
rather
not
this
is
measure
ctl
system
context,
all
right.
A
A
A
Everybody
used
cube
ctl
at
one
point
probably-
and
I
think
docker
has
this
as
well-
the
docker
cli
and
it's
high
time
that
the
meshery
ctl,
the
meschery
cli,
has
it
as
well,
and
so
this
has
been
being
created.
When
you
run
mescheri
ctl
you
to
date,
it
has
been.
It
will
make
the
assumption
that
you
want
to
run
mescheri
locally
on
your
system
in
a
docker
container
and
that's
not
always
the
case
a
lot
of
times.
People
want
to
run
mesher
in
kubernetes
or
they're.
A
A
A
So
it
manages
the
state
and
configuration
of
the
mastery
server
the
adapters
and
at
some
and
as
well
as
the
configuration
of
the
client
and
how
the
client
behaves.
So
these
system
commands
start
messy.
They
stop
measuring,
restart
it
update
certain
components
of
measuring
and
the
like.
So
one
of
the
I
guess
the
proper
term
is
sub
command.
I'm
not
sure
one
of
the
commands
coming
forth
has
to
do
with
context
and
I'm
running
this
stable
version
of
mastery
ctl
right
now,
so
we
don't
oops.
A
So
here
I've
just
got
an
edge
version
of
you
know:
latest
version
of
edge
version
of
mastery
ctl
running
so
I'll.
Do
a
measuring
ctl
system,
hyphen,
h
and
within
here
we've
got
this
new
construct
context.
It's
to
configure
your
mesh
redeployments,
which
is
what
I
was
just
saying.
So
we
take
a
look
at
this.
If
we
just
run
context
itself,
it
will.
Let
us
know
what
our
current
context
is.
I've
created
a
test
context.
A
A
A
Which
is
this
is
informative.
To
tell
you
your
current
context,
it
would
be
probably
appropriate
to
go
ahead
and
give
people
the
full
print
out
of
what's
in
this
configuration
file.
So
we
look
inside
the
configuration
file.
It's
about
it's
information
about
context,
information
about
measuring
deployments,
so
in
this
file
there
are
two
contexts:
there's
a
local
one
and
a
test.
The
local
one
will
most
often
be
in
people's
in
an
individual's
environment,
because
it's
kind
of
the
default.
A
It's
sort
of
the
way
that
measuring
assumes
that
it's
going
to
run,
which
would
be
with
it
assumes
it's
going
to
run
with
all
of
its
adapters
run
locally,
probably
run
on
docker
as
a
platform.
It
will
look
to
a
certain
location
for
the
the
auth
token
to
speak
to
a
mastery
server
and
that
token
will
be.
This
is
interesting.
A
This
anirud-
I
don't
know
if
this
is
accurate-
the
structure
here,
if
we,
if
we
give
this
a
token
a
name,
the
the
name
of
the
token
here
is
called
default.
Okay
and
then
the
location,
though,
is
up
here
which
looks
more
like
a
global
location
for
all
tokens,
and
so
I
know
that
we
haven't
really
gotten
into
manipulating
the
tokens
and
and
doing
a
lot
there,
but
just
as
we
look
at
the
default
template
for
config.yml,
probably
this
is
an
attribute
of
name
and
actually.
A
Actually,
I
think
the
part
of
the
confusion
here
is
that
token
itself
is
independent,
so
so
we'll
have
it
every
config.
Every
context,
sorry
will
have
a
token,
and
it
will
refer
to
that
token
by
name
the
tokens
themselves
and
what
what
attributes
the
default
token
has
like
what
its
location
is
and
maybe
other
things
that
would
be
a
separate
stanza
like
a
separate
object.
A
D
Yeah,
actually
we
did
have
a
discussion
on
this
user
that
we
would
keep
this
as
the
finishing
touches
for
context.
So
once
we
are
done
basically
contextualizing,
the
entire
imagery
ctl,
then
we'll
come
back
to
tokens,
because
only
then
we
would
be
able
to
test
tokens
completely,
because
almost
many
commands
that
take
in
tokens
and
not
how
do
you
say,
constant
contextualized.
A
I
mean
that
technically,
what
I
said
is
inaccurate,
like
you
leave
this
here,
it
will
have
a
name
but
then
you'll
create
another.
You
know
token
reference
which
will
happen
nice,
but
yeah,
but
it
won't
actually
work.
It'll
just
be
a
sort
of
in
preparation
for
him
cool.
So
that's
a
bit
about
on
where
honey
root
has
been
focused
here
recently
anirud.
I
know
you're
taking
this
like
the
next
sort
of
phase
that
you're
looking
at
is
building
in
support
for
different
platforms
and
you're
kind
of
now
that
contexts
are
being
formed.
D
A
G
E
G
C
A
G
A
D
A
Nice,
okay,
that
makes
sense
all
right,
so
so
mert
you're
going
to
give
feedback
on
measuring
ctl
perf.
I
think
I
think
your
feedback
is
is
well
one,
probably
good,
but
two
might
end
up
being
a
feature
feature
enhancement.
It
might
be
that
you're
thinking
of
mastery
ctl
perf
slightly
slightly
differently
than
how
it's
been
designed
today,
but
but
maybe
a
good
feature
request.
So
let
me
explain
what
I
mean,
which
is
the
mystery.
Ctl
perf
is
an
some
messry.
A
A
Generate
load
against
a
single
endpoint
in
the
future
in
the
not
too
distant
future,
we
will
mercury.
Will
let
people
test
multiple
endpoints
at
the
same
time,
and
it's
probably
at
that
point
in
time
like
hey
the
messy
ctl
perf
needs
to
be
augmented,
to
allow
someone
to
say,
I've
got
five
endpoints.
Why
don't
you
hammer
on
all
five
of
these,
and
it
might
be
the
case.
A
That
is
not
exactly
the
that
might
be
something
for
us
to
do,
not
exactly
that.
It
might
be
something
for
us
to
do.
It's
not
not
quite
the
tool
that,
like
that
type
of
network
discovery,
isn't
isn't
exactly
what?
Where
we've
been
focused.
We've
been
focused
on
the
fact
that
measuring
is
managing
workloads.
Endpoints
that
are
running
on
service
meshes.
You
could
have
any
number
of
them.
You
could
have.
A
If
you're
going
to
try
to
hit
a
particular
endpoint,
then
it
would
be
the
same
endpoint
for
the
whole
range
and
you'd
probably
end
up
with
a
number
of
performance
results
that
come
back
that
are
empty
or
that
that
come
back
with
a
bunch
of
errors,
because
there
was
no
endpoint
to
actually
hit.
So
it's
not
a
port
scan
type
utility
or
ping
sweep
type
utility.
In
that
respect,
although
it
does
do
that
type
of
behavior
programmatically
with
kubernetes,
it
does
service
discovery
with
kubernetes
and
does
does
discovery
in
that
way.
G
A
A
Provisioned
messaging
knows
about
that
at
some
point.
It
will
be
dis
it
well.
It
already
discovers
any
applications
or
workloads
that
I'm
running
on
top
of
open
service
mesh.
It's
just
not
taking
that
next
step
of
making
it
convenient
by
listing
out
those
discovered
services.
Here,
as
a
matter
of
fact,
there
were
two
contributors
canal
and
maxim
who
are
going
to
do
that
treaty.
You
you
mind
following
up
with
those
two
on,
they
have
an
open
issue
that
they
were
collaborating
on
and
I
think
they
might
have
gotten
lost
over
the
holiday
sure.
A
Oh
thank
you,
but
yeah.
We
definitely
want
to
enhance
the
experience
because,
because
utkarsh
and
others
can
can
tell
you
hey,
we
know
about
what
those
services
are.
Why
don't
we
just
have
a
drop
down
list
to
show
you
the
end
points
to
show
you
what
the
name
of
your
apps
are
you,
then
you
know,
and
since
we
don't
right
now,
you
you'd
say
well.
My
app
is
running
at
an
ip
address
or
localhost
or
whatever
domain
name
whatever
it
is
on.
A
You
know
this
port
at
hello,
world
or
whatever
the
endpoint
is
right.
Now
mastery
only
supports
generating
http
load,
but
it's
planned
and
very
somewhat
simple
for
us
to
go
support
generating
grpc
based,
load,
udp
and
tcp
based
load.
We
just
haven't
really
exposed
that
that
capability
in
the
ui,
yet
so
mer
to
your
point
right
now.
Mastery
just
wants
to
hammer
on
one
end
point,
but
in
the
near
future
the
intention
is
for
it
to
you
you
to
be
able
to
specify
almost
any
number
of
endpoints.
A
I
guess
we
haven't
talked
about
like
how
many
that
would
be,
but
more
than
one
more
than
that
we're
also,
instead
of
just
having
measuring,
run
a
single
instance
of
a
load
generator
that
we
would
mastery
would
facilitate,
deploying
multiple
instances
of
this
particular
load
generator,
and
that
way
it
can
really
that
way.
It
can
get
a
very
high
fidelity
view
of
what
it
looks
like
when
you
inundate
your
system
or.
A
Yeah
so
good,
so
hopefully
that
helps
with
like
so
yes,
nice.
So
this
isn't
so
messy
ctl
is
whoa
is
a
is
a
client.
So
so
I
should
say
like
it
can
do
or
hopefully
at
some
point
it
can
do
everything
that
the
ui
can
do,
but
not
more
or
not
yet,
and
actually
just
yet
it
doesn't
quite
do
or
expose
everything
that
the
ui
does,
but
folks
like
anirud
and
others
are
trying
to
get
it.
There.
A
A
A
A
It
gets
you
closer:
okay,
cool,
okay.
Anybody
else
have
comments
on
questions,
thoughts
on
the
work-
that's
being
done
here-
maybe
sudan
since
you're
on.
I
know
we're
kind
of
going
out
of
order.
I
I
apologize.
I
just
for
continuity
of
thought
siddhant.
Do
you
want
to
talk
about
the
work
that
you've
been
doing
on
mastery
ctl
system
channel.
A
F
A
F
So
far
like
I
have
been
working
on
the
system
measuring
ctrl
system
channel
where
we
can
using
getting
the
advantage
of
system
contacts.
Currently
each
context
doesn't
have
a
channel
you
can
subscribe,
so
I'm
I'm
working
on
that
to
switch
between
edge
and
stable
and
just
to
show
it's
not
complete.
Yet
just
to
show
like
giving
the
command
system
mystery,
ctrl
system
channel
it
does
it
goes.
It
displays
the
channel
subscription.
A
F
A
Let's
walk
through
a
couple:
yeah
it's
well!
It's
amazingly
somewhat
straightforward
work,
this
type
of
these
commands
and
they
are
also
amazingly
riddled
with
like
all
these
gotchas,
and
so
this
might
be
one
of
them.
Any
route
had
worked
on
that
message.
Detail
system
context
delete
now
when
you
put
localhost
there
was
that
it
expects
the
name
of
a
context
was
oh
okay,
and
so
it
did
delete
localhost,
okay
and
then,
but
the
issue
is
like
unto
your
your
understanding.
A
A
A
A
This
is
anyway,
I
bring
it
up
because
I
mean
this
is
one
of
the
small
ways
to
begin
to
introduce
interactivity
when
it
is,
it's
not
always
entirely
clear
like
when
you
delete
a
context
like
hey,
you
might
have
like
four
other
contexts
in
there.
You
had
five
to
start
with,
you
delete
one
and
then
what
we're
just
supposed
to
guess
like
which
one
to
set
the
current
context
to
gosh.
A
I
hope
that
was
the
right
one,
and
maybe
if
we
chose
the
context
prod
and
you
didn't
really,
we
didn't
really
tell
you
that
we
just
chose
it.
You
weren't
paying
attention
and
you
went
to
do
something
we
might
screw
up
pro
like.
This
is
probably
the
right
point
in
time
where
it's
like
hey.
We
don't
really
know
what
what
your
needs
are
when
you
do
a
ctl
system
context
delete
as
part
of
that
deletion
like
hey,
we'll,
execute
the
deletion,
but
probably
the
next
step.
A
Yeah
yeah,
I
should
please
do
and
that
way
we
can
begin
to.
This
is
a
good
area
to
begin
to
introduce
the
interactivity
it's
an
appropriate
place
where
we
want
to
ask
somebody
the
question,
because
we're
not
really
sure
what
to
do.
There
will
be
the
use
case
where
someone
deleted
the
last
available
context.
A
This
system
context,
it's
been
so
much
needed
for
a
long
time,
very
excellent
to
see
it
coming
through.
It's
also
disruptive
and
that's
just
the
nature
of
the
beast
of
like
it's
disruptive
to
the
rest
of
the
system
commands
so
sudan.
One
of
the
things
that
you
were
just
highlighting
is
well.
When
I
run
system
channel
set
subscribe
to
edge,
the
command
today
goes
out
and
it
modifies
the
docker
file.
A
The
docker
compose
file
that's
there,
but
as
as
we
make
all
of
these
system
commands
context
aware:
okay,
it's
going
to
modify
the
docker
file
for
the
current
context.
Okay,
that's
appropriate
good
now,
but
the
context
as
we're
building
that
in
part
of
the
the
attribute
of
a
context
is
whether
or
not
the
platform
is
docker
so
whether
or
not
to
modify
docker
compose
or
the
platform
is
kubernetes
and
whether
or
not
to
modify
some.
A
A
Something
that
I'll
say
real
quick
is
that
we
were
having
a
discussion
just
yesterday
of
the
day
just
yesterday
about
how
to
manipulate
that
yaml.
Today,
we're
manipulating
yaml
and
you
know,
docker
compose
file
and
the
thing
is
as
you
go.
We
have
a
single
docker
compose
file
today,
okay,
but
if
you
have
multiple
contexts,
then
would
you
have
one
docker
compose
file
per
context
or
one
kubernetes
manifest
set
of
manifests
per
context?
A
Maybe,
or
is
that
something
intrinsic
to
measure
ctl
that
it's
going
to
figure
out
your
config
and
then
generate
the
compose
file
sort
of
based
on
your
config?
Maybe
and
anyway,
there's
that's?
What
on
a
route
was
there's
a
link
to
that
design
spec
in
the
meeting
minutes,
so
go
weigh
in
on
that?
I
was
going
to
update
that
for
any
route
and
abhishek
who
are
part
of
this
conversation,
guys
the
docker
compose
that
binary.
F
F
A
E
D
A
A
A
A
H
A
Years
ago,
oh
okay,
so
refreshing
my
memory,
all
right,
so,
okay,
so
so
for
the
console.
Adapter
michael,
has
used
bats
as
a
as
the
mechanics
to
test
out
to
do
integration
testing
with
the
console
adapter
and
we
considered
like
hey
that
looks
pretty
good.
We
should
you
can
manually
invoke
that
today
we
should
probably
be
auto
magic
we'd,
be
invoking
that
as
part
of
the
workflow
when
the
adapter
is
built
or
released
and
rodolfo
you
had
done
some
work
around
provisioning
of
a
kubernetes
environment
in
through
github
actions,
yeah.
H
A
A
Yeah
and
then
and
then
more
broadly
understanding
what
we
can
do
with
the
temporary
kubernetes
environment.
You
know
we
eat
like
yes
as
a
step
one
and
then
sort
of
as
a
step
step.
One
like
helps.
Do
integration
testing
with
across
all
the
adapters
but
sort
of
a
step
two
is
like
well
now.
If
we
can
provision
a
kubernetes
environment
as
well,
there
are
other
things
beyond
adapters
that
we
might
want
to
test,
and
so
I
think
it
was.
H
Yeah
yeah
actually
in
measuring,
I
created
a
kind
cluster
with
kubernetes
in
docker,
so
in
measuring.
We
have
already
the
kubernetes
environment,
but
I
need
to
do
the
same
in
measure
dash
console
so
right
now.
I
am
testing
that
adapter
measuring
console
in
the
measure
project,
but
I
am
having
problems
with
the
doctor
containers,
but
I
think
I
can
proceed
with
the
measuring
console
testing
in
order
to
have
that
governance
environment
that
you.
A
H
A
Gotcha
any
thoughts
from
any
thoughts
from
anyone
about
you
know
the
ex
the
full
extent
to
which
we
would
do
integration
testing
in
a
workflow
like
we
may
not
want
to
do
full
integration
testing
every
time
that
a
pr
is
merged,
or
maybe
we
do.
We
definitely
want
to
do
integration
testing
before
release.
A
We
don't
want
to
have
a
lot
of
technical
debt
so
to
speak,
or
regression
issues
latent
within
the
master
branch,
all
leading
up
to
a
release
and
then
we're
trying
to
do
integration
tests
at
the
end
and
then
figuring
out,
like
you
know,
there's
a
bunch
of
refactoring
before
we
do
it
really.
We
don't
want
to
make
releases
a
big
event.
This
is
you
know
more
than
they
have
to
be.
A
Before
release
before
release,
there's
a
plus
one
here
and
so
the
more
frequently
we
do
a
release,
the
less
regression
issues
that
we
would
think
that
we
would
have
if
we
do
a
release
once
a
month,
we
might
find
some
regression
issues
as
we
go
to
do
that
full
integration
testing.
Should
integration
testing
not
be
driven,
you
know,
maybe
an
intermediary
approach
here
is
like
there
should
be
nightly
regression
testing
that
runs
independent
of
any
pr.
A
D
So
that's
so
because
of
the
because
it's
overkill
I
didn't
want
it
to
be
for
every
pr,
but
for
every
pr
that
needs
to
be
some
sort
of
a
code
coverage
stuff
which
can
be
done
in
golan,
which
is
specifically
basically
for
golang.
It
is
we
can
write
unit
tests
and
or
enforce
you
know,
unit
tests,
so
that
can
be
done
like.
That
is
an
easier
way
to
do
for
every
pr,
but
integration
test
would
be
like
an
overkill.
A
A
And
I
think
you
know
here's
what
it
sounds
like
we're
coming
up.
We're
proposing
right
now
is
that
potentially
now
there's
full
regression
testing
of
measuring
itself
sort
of
using
you
know
pulling
in
the
different
adapters.
There's
regression
testing
of
the
you
know,
integration
test.
I
keep
saying
regression
testing,
I'm
sorry
integration
to
testing
of
each
of
the
adapters
themselves.
A
A
A
Okay,
interesting,
so
all
right,
maybe
maybe
we
won't
get
all
this
figured
out
on
this
call.
But
rudolfo
is
this-
is
so
rudolph
we
used
to
run
a
weekly,
continuous
integration,
call
where
the
you
know
where
that
was
the
focus
of
the
meeting
and
clearly
we
use
workflows
a
lot.
We
use
a
lot
of
actions,
there's
a
lot
to
do
with
in
there.
A
Sudan
had
recently
pointed
out
that,
like
hey,
if
you
didn't
know
that
there's
there's
a
release
event
you
can
trigger
on
release
which,
for
my
part,
I
think,
is
kind
of
embarrassing
because
it's
like,
I
think
we
should
have
been
using
that
so
clearly,
there's
work
to
be
done
particularly
and
the
more
mature
measuring
gets
and
mesh
is
about
to
reach
its.
You
know,
v0.5
release
this
the
more
effort
put
into
ci
the
earlier,
the
more
that
it
just
pays
off,
pays
off
pays
off.
A
A
This
is
the
kind
of
these
are
the
kinds
of
things
that
that
we
need
in
a
full
dock
because
to
really
grok
it
and
understand,
what's
what's
happening
and
when
I'm
so
there
there
are
two
docs
on
the
subject.
I'm
sit
on
it.
If
you
have
that
you
could
drop
it
in
here
and
I'll
drop
in
the
other
one
and
then
shredi.
It
sounds
like
we
might
have
a.
We
might
have
our
our
next
victim,
rodolfo
and.
A
D
D
D
A
A
A
Some
deployments
will
have
more
components,
some
will
have
less,
but
every
component
is
versioned
independently
they're
released
independently
and
version
independently
and
as
we
go
as
a
user
goes
to
so
as
as
you
have
created
this
mock-up
wow,
which
I
think
illustrates
the
point
that
mesherie
as
a
system
overall
will
be
reporting
on
its
individual
component
versions.
So
measuring
will
be
running
an
operator.
It'll
be
running.
Mesh
sync
you'll
be
running
some
gnats.
You
know
report
on
those
versions,
knowing
that
that's
something
of
a
universal
need
not
just
for
adapters.
A
D
Okay,
so
we
did
have
a
discussion
on
this.
I
believe,
and
it
took
us
to
the
open
application
model.
Oh
I
see
yeah.
Basically,
it's
been
dealt
with
protobuf,
but
but
today
we
do
have
it
on
mesquite.
Basically,
there
is
a
folder
called
photobook
in
which
we've
got
some
generic
interfaces,
which
would
return
status
and
information
like
info
endpoint
will
give
you
the
version
and
name
of
the
server
and
everything
and
the
status
would
give
you
the
health
of
that
particular
server.