►
From YouTube: Meshery Development Meeting (Nov 18th, 2020)
Description
Review of Meshery Adapter Library.
A
A
A
B
B
And
then
yet
you
know
it
is
talked
about
in
that
talk.
The
other
one
that's
talked
about
is
smi
service
mesh
interface.
We
just
had
a
meet
the
maintainers
talk
at
kubecon
yesterday,
which
went
pretty
well
and
dhruv
was
on
that
call,
and
so
was
abhishek
kumar
or
as
he's
known
in
this
meeting,
abhishek
fantango,
and
since
he
didn't
write
his
name
down,
we
will
just
make
up
last
name
for
google.
B
B
A
B
A
Nice
all
right,
that's
another
chance
for
anybody
who
missed
out
on
it
and
also
didn't
sign
up
for
kubecon,
so
you
can
go
ahead
and
see
it
afterwards
and
that's
it
for
the
announcements
for
this
particular
week,
abrisheik
you're
up.
I
was
looking
forward
to
pronouncing
your
last
name,
but
you
corrected
it.
So
I
can't
now.
C
So
when
we
look
at
the
mesh
kit,
it
has
so
our
common
use
cases
on
different
microservices
have
gets
involved,
with
using
loggers
using
error,
objects
using
custom
errors
or
are
say
using
custom
utilities
etc.
So
to
solve
those
challenges,
we
just
generally,
we
decided
to
create
this
package,
so
the
higher
level
of
this
package
involves
all
of
these
components
that
we
want
to
use
like.
C
They
can
order
the
box
import
this
library
to
sort
of
use
it.
So
this
ensures
that
there
is
uniformity
and
stability
across
all
the
projects
in
missouri
and
also
the
the
loggers
and
the
error
object,
especially
that
we
try
to
create.
It
has
a
lot
of
additional
information
rather
than
the
golang
default
error
objects.
C
For
example,
the
error
error
message,
or
the
error
object
from
any
measuring
project
here,
would
give
you
the
error
code,
the
severity
of
the
error,
the
shorter
description
in
the
longer
description,
along
with
what
the
probable
cause
is,
and
it
also
suggests
a
remediation
for
that
particular
error
that
any
user
is
facing
so
such
customizations
to
facilitate
such
customizations.
We've
created
this
particular
particular
package,
and,
and
so
we
we've
got
different
other
use
cases
with
different
other
utilities.
C
For
example,
in
utils
library,
we've
got
a
couple
of
utility
functions
which
are
very
much
useful
in
in
our
daily
in
our
regular
projects
like,
for
example,
if
we
want
to
check
if
an
endpoint
is
reachable
or
not,
we
have
a
function
called
tcp
check
that
is
related
to
network,
and
if
you
want
to
quickly
generate
a
uid,
we've
got
a
rapid
function
for
uid
and
and
so
we've
also
got
a
set
of
utilities
for
kubernetes
inside
kubernetes
folder
as
well.
So
so
this
mesh
kit
package
is
a
whole
hole.
C
So
that's
all
about
the
mesh
kit
project
that
we
have
worked
on
and
the
second
second
bit
I
want
to
discuss
is
about
measuring
adapter
library.
So
this
this
particular
library
is,
as
I
said,
it's
designed
for
design
specific
to
the
adapter
use
cases,
and
so
this
this
has
got
all
the
components.
For
example,
if
if
we
wanna
use
different
config
providers
to
maintain
adapter
configs,
we've
got
the
facility
for
that
as
well.
C
Right
now,
we've
got
a
viper
and
in-memory
configs,
and,
and
so
we've
got
a
concrete
config
interface,
which
manages
the
config
lifecycle
of
the
adapters
and
that
that's
about
config
packages.
And
if
you
look
at
the
proto
buffers,
the
adapters
would
use
that
has
also
been
exported
as
a
package
in
here
and
also
the
grpc,
all
the
trace
tracing
utilities
or
the
server
that
needs
to
be
embedded
over
the
adapter.
C
That
has
also
been
a
library
that
has
also
been
presented
as
a
library
in
here,
so
that
each
of
the
adapter,
when
when
it
is
developing,
they
just
have
to
import
these
packages
and
then
they
can
just
implement
their
business
logic
in
their
adapter
code
and
everything
will
work
out
of
the
box.
So
in
other
words,
we
can
call
this
a
framework
for
the
adapters
itself,
because
it's
it's
got
a
lot.
A
whole
lot
of
utilities
as
well.
C
Like,
for
example,
it's
like
how
we
have
sample
applications
that
are
running
in
machine
that
we
can
install
via
a
machine.
All
of
those
operations
are
also
being
generalized
in
in
our
in
one
of
the
packages
inside
the
library,
and
so
we
don't
have
to
always
define
these
operations
in
different
adapters
and
we've
also
got
a
special
package
called
status
which
tracks
the
status
of
any
operation,
and
it
just
described
it
tracks
the
description
for
the
status
and
and
so
yeah.
C
B
B
C
Well,
for
example,
let's
take
an
example
of
chrome
adapter,
let's
let's
say,
for
example,
in
kuma
adapter.
We
we
wanna,
install
kuma,
for
example,
the
install
operation
for
puma.
We
start
with
the
status
as
installing
and
then
after
every
step
and
each
and
every
step
as
we
progress,
we
just
track
in
the
status
and
then
at
the
end
we
just
change
the
status
to
install
it.
C
B
C
C
B
B
B
Is
it
yeah?
Is
that
what
you
were
asking
or
one
of
the
things
you're
asking?
Well
yeah?
That's!
That's
all
nice!
Okay!
Well,
that's
a
hell
of
an
opportunity!
Okay,
nice
yeah,
especially
if
somebody
like.
So
what
are
some
of
the
like
istio
that
adapter
it
hasn't
been
refactored.
Yet
has
it?
Oh,
no,
oh,
okay!
So
so
there's
an
opportunity
for
someone
to
go.
Take
the
istio
adapter
all
right.
Let's
see
I
okay
good
cool
yeah,
the
istio
adapter,
the
link,
your
d
adapter.
B
B
B
B
C
We've
just
started
with
kuma
adapter
and
console
adapter
for
the
time
being,
and
the
rest
of
them
are
very
much
easy,
very
much
available
for
grabs
and
the
person
who
can
help
you
help
out
with
getting
you
started
would
be
me
one,
and
there
is
miguel
who
can
who's
also
equally
active,
and
he
has
been
equally
contributing
to
this
particular
pro
to
these
projects.
So
he
he's
one
one
other
point
of
contact
for
getting
seeking
help
and
yeah.
So
there
is
also
utkarsh
who
is
also
their
leverage.
C
D
D
C
We
create
a
new
tag
and
then
make
a
release
for
the
tag
basically
to
point
to
the
latest
so
that
we
don't
want
to.
We
don't
want
to
break
the
previous
build
because
there
might
be
a
number
of
packages
who
are
using
the
previous
build,
but
also
we
need
to
provide
these
enhancement.
Enhanced
features
to
the
new
available
to
be
available,
so
we
just
create
a
new
tag.
D
C
D
D
D
A
B
C
C
B
I'd,
given
some
comments
that
I
thought
like
if
I
was
reading
my
comments
I
might
have
it
might
serve
us
well
to
have
a
verbal
conversation
to
help
speed
along
because
I
felt
like
I
was
some
of
my
comments
were
probably
like
holding
back
progress
that
wouldn't
be
good
so
and
maybe,
rather
than
me
driving
the
conversation
abhishek
did.
Did
you
feel
like
any
of
these
were
unresolved
or
could
use
some
discussion.
C
So,
let's,
rather
we'll
go
one
by
one.
Basically,
it's
only
a
couple
of
it's
only
three
comments
that
you
dropped,
so
the
first
one
being
that
you
just
wanted.
You
was
just
wondering
if
it
should
be
info
command,
so
this
this
is
also.
This
has
been
changed.
I
have
updated
and
pushed
a
new
change
for
that.
B
B
There's
kind
of
it's
kind
of
funny,
because
there's
an
interesting
spectrum
like
there's
some
and
it's
yeah
anyway
I'll
try
not
to
be
too
philosophical.
I
guess,
but
it's
suffice
to
say
that
we're
we're
baking
in
hard
coding
in
support
for
a
few
sample
applications
for
purposes
of
helping
people
understand
service
meshes
and
explore
them,
which
is
good
and
useful,
and
something
that
people
find
value
in
today
and
for
a
long
time
from
now.
B
C
Other
yeah,
so
I
think
we
had
this
discussion
before
so
we,
basically
even
if
we
wanna
do
it.
If
we
want
to
update
or
give
some
updates
without
release
without
making
a
release,
we
don't
have
the
provision
at
the
moment
because
be
it
measuring
server
or
the
adapters.
It
runs
as
a
container
and
asking
people
to
sign
in
into
the
container
and
then.
B
B
B
But
in
our
conversations
I
had
said
like
oh,
we
can
externalize
these
names
and
put
them
into
a
yaml
file.
Kind
of
you
know
externally
that
that's
helpful
as
a
first
step,
because
then
you
don't
have
to
recompile
the
code
to
accept
a
new
app,
but
really
like
that
would
just
be
kind
of
a
first
step
or
like,
maybe
maybe
not
even
something
that
we
should
do.
B
Rather
you
these
would
be
separated
from
the
adapter.
The
adapters
are
to
have
service
mesh
specific
knowledge,
so
the
console
one
needs
to
know
that
it
has
to
add
annotations
on
pod
specs,
because
that's
what
console
needs
for
running
services
on
console,
whereas
for
istio
or
a
different
mesh
it
may
not
need
to
it.
May
only
it
may
not
depending
upon
whether
or
not
sidecar
the
sidecar
injector
is
currently
running
in
that
namespace
that
they
want
to
provision
to.
It
really
may
not
need
to
do
anything
to
the
ammo.
B
Source
of
truth
for
the
ammo
is
the
publishers
of
the
workload.
So
if
it's
a
sample
app,
it
probably
comes
from
the
service
meshes
themselves
and
if
it's
something
that
is
unique,
it
like,
if
josh
who's
on
the
call
if
he
took
it
and
deployed
it
in
his
environment,
but
josh
has
his
own
app.
It's
josh.
C
C
So
we've
defined
the
operation
here,
and
you
said
that
the
operation
itself
should
be
filled
in
by
by
a
source
and
what
would
that
source
be
that
that
the
it
said
again
that
the
operation
would
be
what
so
so
like
we
have.
The
list
of
operations
in
here
like,
for
example,
hdb
bin
or
a
major
all
of
these
list
of
operations
that
are
defined
along
with
their
properties
on
on.
C
B
B
Like
the
the
the
point
here.
What
what
I'm
making
with
this
comment
is
that
the
the
mechanics
where
we're
listing
what
the
the
name
of
the
app
is
the
operation
for
it
is
the
version
of
that
having
those
mechanics
in
the
library
or
in
an
adapter.
That's
good
and
what
we
want
what
apps
go
in.
There,
though,
would
ideally
be.
B
Things
that
you
can
admit
that
the
user
can
manipulate
from
measure
ui.
They
can
like
remove
that
sample
app
because
they
just
don't
like
it,
and
they
don't
want
to
see
it
anymore.
They're
not
going
to
use
it
or
add
a
new
app
because
they're
they
have
they
brought
their
own
and
so,
to
the
extent
that
yeah
you
either
can
have
that
defined
in
the
adapter.
B
In
the
adapter
library,
but
ideally
like
without
additional,
if
we're
baking
it
into
for
hard
coding
and
and
it
requires
recompilation
and
a
release
of
mastery
itself
and
of
the
adapter
itself,
it
becomes,
it
can
be
okay,
providing
the
user.
Some
controls
to
maybe
hide
those
would
would
be
helpful
but
providing
the
user
the
ability
to
like
let's
say
that
a
new
version,
ideally
every
adapter,
it
will
support.
B
If
istio
1.8
comes
out
right
now,
does
the
adapter
support
that
well
today?
It
doesn't
because
it
explicitly
lists
out
every
single
version
that
it
does
support.
Ideally,
it
would
also
have
a
perpetual
latest
which
hopefully,
the
current
adapter
code
supports.
It
may
be
the
case
that
istio
changes
so
significantly
that
the
adapter
doesn't,
but
hopefully
it
would
and
and
to
the
extent
that
it
does,
we
would
have
a
latest
in
there
and
it
would
be
the
same
thing
for
the
sample
apps.
B
Yep
potentially
yeah
I
mean
oppa
itself,
wouldn't
have
the
yeah.
It's
a
that's
a
good
discussion.
They
go
op
itself,
wouldn't
be
the
repository
sort
of
the
source
of
truth
for
what
applications
measuring
supports,
because
it
wouldn't
have
that
long-term
persistence.
It
would
be
capable
of
connecting
to
that
long-term
persistence.
B
B
So
maybe
the
things
that
I'm
suggesting
here
I
might
have
to
put
a
pin
in
it
like,
because
it's
just
you
know
it.
Otherwise
we
might
get
mired
up
like
on
that,
michael
any
any
thoughts
here,
like
we're
kind
of
I'm
kind
of
suggesting
that
I
that
I
retract
my
comment
like
and-
and
you
know,
log
it
for
a
future
consideration.
E
E
E
It
still
means
we
have
to
somewhere,
we
have
to
version
or
we
have
to
package,
we
have
to
copy
it
to
somewhere.
So
this
have
to
have
a
good
plan
for
this
and
and
also
a
good
plan.
I
think
to
be
able
to
support
adapters,
specific
modifications
or
maybe
even
overrides,
if
the
modifications
are
risky
or
too
complicated,
to
implement
it's
automatically
adjusted
and
for
some
for
some
service
meshes.
Maybe
not
everything
can
be
controlled
using
manifests.
E
E
B
D
D
That's
one
opinion.
Second
opinion
workload,
it's
a
common
name
for
when
you
deploy
a
service
in
kubernetes,
so
workload
is
the
app
itself.
So
that's
okay.
I
mean,
when
you
say
application,
everybody
will
think
of
something
else.
Workload
is
for
sure
what
it
means
and
third
thing:
if
we
use
labels
like
mesh
work,
you
have
the
workload
description
and
you
have
labels
and
use
some
specific
measuring
labels
measure
adapters
labels.
D
D
You
can
use
as
many
as
you
want
in
in
the
workload
so
not
sure
if
we
have
ingress
egress,
whatever
these
things
already
or
context
or
yeah,
but
then
everything
that
is
going
to
be
related
with
the
workload
or
with
the
deployment
or
with
whatever
we
want
to
delete
the
the
workload
and
all
the
extra
associated.
Then
we
can
use
the
labels,
I
I
didn't
see,
it
doesn't
mean
it
might
exist.
I
didn't
see
it,
and
maybe
it's
not.
D
D
B
D
D
I
do
have
a
fourth
point
by
the
way,
also
besides
couple
of
main
labels,
you
can
also
use
like
dynamic
labels.
Let's
say
for
each
depends
over,
you
can
if
they
have
a
certain
prefix.
I
don't
know,
but
also,
but
at
one
point
I
don't
know
depends
on.
Let's
say
your
your
application
is
a
stack
or
doesn't
it
needs
something
else
or
so,
then
you
need
an
extra
label
or
something
like
that.
So
leave
the
people
who
are
using
measure
who
are
installing
a
different
app
to
add
more
labels
if
they
want.
B
Yeah,
that's
a
good
one,
yep
yeah
right!
Actually,
let
people
annotate
their
workloads
so
that
yeah
as
they
go
to
manage
those
ongoing
that
they
they
may
want
to
just
add
their
own
labels
and
tags
annotations
onto
their
own.
So
yeah,
thank
you,
ayush,
so
and
then
thank
you
adina.
I
knew
she
was
just
and
so
so
to
wrap
this
up
real
quickly,
because
I
think
karsh
was
going
to
show
something
is
I'll.
B
From
my
perspective,
you
guys,
I
think,
we're
like
the
in
alignment
with
the
sentiment
long
term,
that,
like
hey,
that,
ideally
we're
being
as
dynamic
as
possible,
we're
recognizing
who
the
source
of
truth
is
for
the
definition
of
these
things
that
yes,
each
individual
adapter
should
be
considering
service
mesh
specific
things,
so
they
should
be
mutating
the
manifest
with
service
mesh,
specific
annotations
or
labels
on
a
namespace
or
or
whatever
needs
to
be
done
to
or
like
hey.
If
a
manifest
a
workload.
B
That's
going
to
be
deployed
if
it's
using
this
the
same
port
that
envoy
does,
and
that
would
create
a
conflict
for
that.
Like
there's
a
few
considerations
that
you
take
into
account
when
you
onboard
a
service
onto
the
mesh
like,
is
it
gonna
work
well
or
not,
and
and
those
are
mostly
specific
to
a
mesh
and
that's
what
the
adapter
should
be
concerned
with
and
should
have
hard-coded
code?
B
You
know,
well-written
code,
that
deals
with
that
at
some
point
will
be
less
and
less
concerned
with
the
specific
app
that
you're
deploying,
but
right
now,
with
the
stage
of
maturity
that
we're
in
and
how
much
we're
kind
of
taking
on
by
just
in
this.
This
up
leveling
here
that
set
of
concerns
is
a
whole
bucket
full
of
work
itself
and
so
maybe
best
postponed
for
a
later
point
in
time.
A
F
F
It
is
visible
right,
yep,
yes,
so
this
is
the
mystery
dashboard.
Initially
we
had,
like
any
user,
could
add
from
ethios
or
grafana
manually
right
now,
we
like,
I
recently
added
a
feature
where
a
user
would
be
able
to
add
their
own
primitive
server.
If
we
don't
list
this
them
up
in
here
and
if
we
do,
then
they
can
select
it
automatically.
So,
for
example,
I
deployed
our
prometheus.
F
F
So
similarly,
krifana
would
also
like
we
would
also
list,
like
the
instances
that
we
have
discovered
and
similar
just
like
from
information
we
list
out
both
for
the
load
balancer
as
well
as
cluster
ip
based
endpoints.
Because
again
we
are
not
right
now
familiar
if
we
are
within
the
cluster
outside
the
cluster,
so
you
can
select
a
one
and
submit
it
and
we
will.
We
can
just
add
directory.
A
C
B
B
That's
that
status
like
there
needs
to
be
a
property
or
of
a
struct
or
or
something
where
measuring,
where
we
document
for
a
given
deployment
measuring
needs
to
determine
whether
or
not
it
itself
is
deployed
inside
of
a
cluster
or
outside
it.
It
has
that
logic
today
when
it
would
crash.
If
you
go
to
the
environment
tab
it
will
it
will.
It
has
the
logic
today.
B
The
logic
follows
like
this:
mastery
wakes
up,
it
looks
into
its
environment
variables
if
it
sees
that
there's
a
secret
that
has
a
certificate
to
talk
to
a
cube
api,
it
it
says.
Well,
I
must
be
deployed
in
cluster
I'll,
go
ahead
and
try
to
connect
to
cube
api
and
I'll
I'll
connect,
and
so
I'm
in
cluster
I'm
an
in-cluster
deployment.
B
E
B
B
People
know
grafana
they've
invested
into
the
charts
and
the
boards
that
they're
using
and
they
might
want
to
look
at
those
same
metrics
while
they're
examining
the
performance
of
their
mesh.
We
understand
that
you
know,
of
course
they
do
and
mesri
doesn't
intend
to
displace
grafana,
but
it
does
want
to
bring
some
new
generate
some
new
stats
and
show
them,
and
so
it's
best
to
show
those
in
context
of
what
was
happening
on
your
node
and
what
was
happening
in
other
other
things
that
you're
already
tracking
well.
B
So
so
you
can
just
paste
in
your
definitions
here
on
the
or
you
can
paste
in
prometheus
queries
here
and
bring
your
own
queries
on
the
grafana
tab.
That's
actually
exactly
what
meshri
is
doing
automatically
meshrie
is
automatically
using
grafana's
sdk,
connecting
to
grafana
retrieving
the
names
of
any
boards
and
charts
that
you
might
already
have
defined
in
that
instance,
and
letting
you
choose
which
ones
you
want
to
display
here.
B
B
B
Well,
those
things
are
just
sitting
there
measuring
actually
discovers
them
knows
that
grafana
and
prometheus
are
sitting
there,
but
we
didn't
expose
that
in
the
ui,
and
so
we
just
needed
to
take
this
extra
little
step
to
like
take
the
thing
that
we've
already
discovered
register.
It
automatically
just
like
we
discover
if
kubernetes
is
present
and
register
that
connection.