►
From YouTube: Meshery Development Meeting (March 2nd, 2022)
Description
Meshery Development Meeting - February 23rd 2022
Agenda -
- v0.7.0 Meshery Roadmap (see also: Meshery Architecture deck)
- Multiple Telemetry Providers and Custom Boards (slides 33 and 34)
- Default behavior of `mesheryctl system stop` #5159
- Testing of different clusters (in advance of Azure access)
- Call for Volunteers: [Ashish] List of outstanding multi-cluster items
- Using the clusters query parameter in most APIs from frontend.
- Multi-cluster Design Specification
- Consideration of treatment of separate contexts and the operation.
- Advanced (post v1.0?): Multi-cluster service deployment and their configurations
- MeshKit and Meshery Adapter Library - Jared has been working on updating dependencies (e.g. opentelemetry, logger) which are causing some breaking changes. Some structs renamed.
- Meshery Adapter → Meshery Adapter Library → MeshKit
Join the community at https://layer5.io/community
Find Meshery on:
GitHub: https://github.com/meshery
Twitter: https://twitter.com/mesheryio
LinkedIn: https://www.linkedin.com/showcase/meshery/
Docker Hub: https://hub.docker.com/u/layer5/
A
A
A
A
A
And
so
good,
okay,
last
chance,
okay,
good!
All
right,
let's
get
started
with
our
topics,
so
monov
is
our
lucky
winner
with
today's
first
topic,
and
so
just
as
for
context.
Here.
Most
of
you
are
well
aware
of
this,
because
most
of
you
are
working
toward
this
goal
of
releasing
mescheri
v060
we're
in
like
we're
currently
in
the
release
candidate
phase
for
getting
that
release
out
the
door.
It
seems
perpetually
just
out
of
grasp
we're
so
close
in
context
of
that
there
are
well
there's
a
whole
roadmap.
A
A
A
A
An
item
that
monavie
is
going
to
talk
about
is
on
this
roadmap,
so
I
won't
cover
it,
but
I
want
to
make
sure
that
you
all
had
context
the
other
piece
of
context.
That's
can
be
helpful
and
you'll
probably
see
it
from
monav.
Here
in
a
moment
is
the
architecture.
Deck
is
kind
of
essentially
referenced.
A
There
are
some
names
here
that
have
been
confirmed
and
then
some
folks
who've
sort
of
either
faded
or
maybe
stepped
back
from
those
responsibilities,
and
so
there's
a
few
openings,
so
rude
rocks
has
stepped
down
from
his
maintainer
role.
Sumik
is
near,
as
I
understand
still
on.
The
hook
are
still
desirous
of
working
in
this
area,
but
we
haven't
heard
from
for
a
month
or
so,
and
so
that
makes
you
wonder.
B
How
they
can
contribute
yeah
so
giving
a
glimpse
of
what
it
is
like
a
small
implementation
we
have
done
in
mesh
map.
So
if
you
see
right
now,
these
are
the
small
graphs
which
are
being
rendered.
These
are
dynamic
according
to,
according
to
the
type
we
are
selecting.
So
if
you
say
this
is
a
port,
the
graphs
are
different.
C
B
Are
different
graphs
that
are
based
on
queries,
so
queries
are
specific
type,
which
is
implementation
of
the
custom
part
which
we've
already
talked
about.
So
if
I
say
how
there,
this
is
the
port
level,
there
could
be
a
container
level,
containers
would
have
different
matrices
and
each
port
or
container
will
have
different
sort
of
telemetries
to
be
configured
for
now.
How
is
it
looks
from
the
perspective
of
that
of
the
code?
It's
basically.
B
If
you
see
this
is
an
simple
json
array
which
which
is
defined
for
each
type,
so
it's
totally
dynamic.
If
we
add
one
more
type,
it
will
be
rendered.
Accordingly,
if
I
say
now,
I
want
another
metric
say
xyz
for
for
some
other
title.
I
could
just
append
it
over
here
and
it
will
automatically
be
fetched
by
graphql
and
displayed
on
the
on
the
board,
which
you
are
seeing
earlier
so
and
even
it's
dynamic
on
the
basis
of
the
kind.
B
So
if
I
say
today,
I
I
don't
have
something
for
namespaces,
but
tomorrow
I
have
so.
I
will
just
append
a
key
key
namespace
and
add
the
metro
which
I
want
to
display,
which
is
a
way
of
custom
handling.
Right
now,
it
is
present,
is
in
a
form
of
a
json
block,
but
we
aim
to
convert
it
to
a
database
format
where
these
are
stores
in
stored
in
table.
Now
I
will
like
I've
talked
about
it,
so
I
will
show
you
how
it
it
looks
in
architecture.
B
B
Right
now
we
only
focus
on
one
provider
that
is
one
two
providers
prometheus
and
graphene,
and
that
two
having
a
one-to-one
relationship
that
we
have
prometheus.
We
have
one
parameters.
We
have
one
grifana,
but
this
architecture
which
we
are
proposing
will
be
having
connections
to
multiple
telemetry
providers,
not
just
like
say
there
will
be
three
prometheus
four
prometheus
five
from
any
number
of
prometheus
any
number
of
grafana,
which
will
be
configured
according
to
their
fans.
B
Now
I
talked
about
database,
so
a
glimpse
looks
like
this
like
this
is
the
current
architecture,
which
is
just
one-to-one
relationships
going
on,
but
with
the
database
prospectors
it
will
look
dynamic
and
whenever
say
we
add
a
new
new
end
in
the
database.
It
only
fetched
our
body
to
its
parameters
and
rendered
or
on
the
like
they
saw
the
panel
in
measured
will
be
on
the
better
section.
So
that's
a
brief
of
our
custom
mattresses,
but
the
architecture
is
not
yet
complete
it.
B
It
has
different
openings
and
it
has
different
parts
which
could
be
improved
upon
the
table
itself
could
be
improved
upon.
So
that's
all
I
need-
and
I
like
to
you
guys-
to
work
and
contribute
and
write
comments
to
it
so
that
we
could
work
and
enhance
this
and
at
an
instance
we
could
have
it's
habitually
working.
A
So,
like
a
lot
of
presentations,
there's
kind
of
two
reasons
why
monov
brought
this
up
one
is
to
demo
progress
on
on
an
aspect
of
measuring
the
other
reason
he
brought
it
up
is
to
well
encourage
everyone
to
participate.
Let
everybody
know,
what's
going
on,
give
you
an
opportunity
opportunity
to
jump
in
to
collaborate
so
yep
if
you're
into
react,
it's
a
good
chance
to
collaborate
if
you're
into
golang
a
good
chance
to
collaborate.
A
A
So
one
of
the
things
that
measury
does
is
well.
It
will
connect
to
your
grafana
it'll
connect
to
your
prometheus
instances,
it'll
connect
to
your
grafana
instances
and
right
now
we're
only
talking
about
metrics
right
because
there's
other
types
of
telemetry,
but
for
metrics,
prometheus
and
grafana
are
kind
of
the
two
integrations
of
focus,
and
so
mesheri
will
not
only
speak
to
prometheus.
Today.
It
only
wants
to
talk
to
like
one
one
at
a
time
tomorrow
in
this
next
release.
A
It
needs
to
talk
to
multiple
at
a
time
it
needs
to
understand
which
prometheus
to
get
what
metrics
and
then
where
to
show
those
metrics
in
which
part
of
the
ui
it
also
today,
measury,
will
connect
to
your
grafana
instances
and
ingest
there
any
boards,
any
grafana
boards
you
might
already
have
defined,
which
is
to
to
say
that
those
grafana
boards
have
a
definition
of
different
panels.
Boards
and
panels
are
grafana
nomenclature
for
charts
and
metrics
meshri
will
ingest
those,
so
meshri
embraces
the
investment
that
people
already
have
in
grafana
beyond
that.
A
And
so
this
will
be
a
mechanism
for
doing
that,
as
you
look
forward
to
like
the
dot,
8
or
dot
9
release
or
the
1.0
release.
You'll
find
evidence
in
the
roadmap
of
other
related
integrations
that
would
build
either
on
top
of
this
functionality
or
beside
it.
So
other
things
that
would
sit
beside
this
are
is
support
for
telemetry
types
other
than
metrics,
so
most
notably
logs
and
traces.
A
A
D
C
Okay,
so
yeah.
This
is
just
just
follow
up
on
the
issues
that
we
were
having
with
message:
ctl
stop
stop
system
stop
command
and
I
had
a
talk
with
you
and
push,
and
we
decided
that
you
know
we
came
to
the
conclusion
that
the
default
behavior
of
stop
should
be
what
an
average
measure
user
would
expect
from
system
stock,
which
is
to
get
rid
of
oil
measuring
resources.
C
Let's
say
some
resource
is
not
not
running,
or
is
it
it's
failed
to
come
up.
For
example,
in
this
case,
I
intentionally
deleted
the
custom
resource,
so
it
just
errors
out.
It
doesn't
stop
because
it
says
that
it
couldn't
the
server
could
not
find
the
cr.
So
this
is
solved
with
the
force
flag,
but
the
problem
with
the
first
flag
is
that
it's
not
like
an
average
user.
You
should
not
have
to
put
a
put
up
a
force
just
to
expect
just
to
have
expected
behavior.
C
C
C
Stop
when
you
call
system
stop,
it
doesn't
check
on
like
our
machine
components
running
so
the
problem
with
this
check
is
it
only
checks
for
deployments,
and
I
feel
like
this
check
is
not
very
necessary
if
we're
going
with
the
model
that
you
know,
we
just
try
to
delete
everything
and
if
it
doesn't
exist,
we
just
ignore
it.
So
if
that
is
the
case,
then
we
don't
need
to
check
if
measure
is
running,
because
if
it's
not
running
it
will
just
go
through.
You
know
we'll
just
find
something.
D
A
A
A
Then,
then,
by
god,
do
that
start
it
and
stop
letting
helm
get
in
the
way
home
being
all
sensitive
about
stepping
on
itself
on
a
prior
deployment?
Or
what
have
you
is
like
you
know
now,
just
start
messaging
like
if
there's
already
components
of
mesh
restarted
good,
like
maybe
even
overwrite
them
and
upgrade
them
just
in
case
like
just
in
case
you
stay
in
sync,
it
would
be
the
oddity
that
someone
would
start
measuring
their
existing
components
at
an
older
version
and
someone
actually
desired
that
those
existing
older
components
didn't
get
upgraded.
A
A
Is
that
usually
things
that
delight
people
are
things
that
are
somewhat
opinionated
and
they
just
kind
of
they're
intuitive
they
sort
of
get
get
the.
Not
only
do
they
get
not
only
do
they
do
what
you
were
expecting
them
to
do
so
they're
intuitive,
but
they
also
take
it
like
one
step
further
and
then-
and
therein
lies
the
delight,
the
delightful
part-
and
it's
really
nice
people
want
to
come
back.
A
Users
want
to
come
back
and
use
that
type
of
software,
the
risk
in
imbuing
opinion
and
trying
to
intuit
what
people
desire
is
that
you
try
to
make
the
software
too
smart
and
that's
actually
in
part.
What
you
were
just
pointing
out,
which
is
like,
if
I
forget,
what
seek
if
someone
was
saying,
stop,
measuring
measuring
ctl
system
stop
and
as
we're
doing
it,
we
check
to
see
if
measures
running
it's
like
what
does
it
matter,
just
stop
it
and
if
it's
already
stopped
yeah
right.
C
A
A
A
A
helm
has
been
so
we're
using
your
message:
ctl
under
the
hood
and
now
and
measuring
server
under
the
hood
are
using
helm
foremost
as
the
provisioning
utility
or
provisioning
framework
and
over
time
since
its
genesis,
mesri,
has
used
a
number
of
different
mechanisms
recently
with
hussein's
help
and
and
others
other
and
help
from
other
people.
We've
gotten
off
of
use
of
kubernetes
manifests
hoping
to
find
economies
of
scope
by
using
just
helm
as
the
installer
and
therefore
less
code,
fewer
bugs
and
thus
far
helm
has
been
a
pain
in
the
rump.
C
A
C
We
might
have
to
know
it
like
we
used.
I
think
hussein
are
something
in
chat,
so
we
use
helm
for
install
and
update
and
uninstall
code
will
be
cleaned
up
from
the
mesh
category,
so
the
yeah,
let
the
uninstall
code
will
be.
I'm
not
sure
what
you
mean
by
cleaned
up,
but
the
uninstall
part
will
just
call
the
kubernetes
client
and
it
will
just
tell
it
to
like
delete
components
but
yeah.
So
the
thing
with
start
is
like
we
need
earlier.
As
you
said,
we
were
using.
C
A
C
A
A
Sometimes
it's
by
running
the
by
running
the
bash
script
like
curling
and
running
the
bash
script,
to
start
meschery
internal
to
that
bash
script.
It
calls
mastery
ctl
system
start.
So
it's
the
same
kind
of
starting
point
to
deploy
components
like
measuring
operator
and
that's
the
measuring
operator
and
some
of
the
kubernetes
cluster
roles
and
cluster
role.
Bindings
have
been
part
of
the
the
challenge
with
use
of
helm.
A
A
It
will
also
deploy
a
couple
of
cluster
roles
and
cluster
role
bindings
and
so
there's,
at
least
in
my
mind,
sort
of
two
primary
starting
points
for
where
it
is
that
measuring
might
have
been
installed
and
so
rudra
as
you
work
through
forcing
start
enforcing,
stop
it's
good
to
confirm
from
both
perspectives
and
that
that's
actually
in
part.
Why?
A
C
And
yeah
to
answer
mario's
question
in
the
chat
I
feel
like
yeah.
We
even
at
the
moment
we're
doing
that,
and
I
think
that
should
be
done
is
to
remove
the
deployments
which
are
made
by
measuring
pattern
and
filter,
while
stopping
so
basically
stopping
will
remove
everything.
Unless
you
give
it
the
keep
name
space
feature,
it
will
also
remove
the
name
space.
F
Okay,
so
recently
we
added
a
support
for
multi-cluster
multi-context
in
mastery
and
from
back
end,
we
have
at
least
for
now,
as
we
think
we
have
solved
most
of
the
bugs
around
it
more
more
bugs
will
be
there
when
actually,
basically,
that
api
would
be
consumed
by
the
ui,
be
it
mystery,
ui
or
messy
cdl,
and
they
are
not
consuming
it
right
now.
By
consuming,
I
mean
that
or
at
mystery
server
in
the
middleware,
we
actually
are
currently
grabbing
all
the
context.
F
So,
okay,
so
let
me
give
a
little
bit
of
context
around
this.
No
pun
intended
so
currently,
if
you
basically
make
an
operation.
Basically
you
you
start
an
operation,
you
make
an
operation,
be
it
like
bit
like
install
a
service
measure,
something
like
that.
It
happens
on
a
single
context.
That
is
your
current
context.
Inside
of
your
cube
config.
As
of
now,
so
you
have
one
context.
That
is
your
current
context.
Inside
of
your
queue
config
and
on
that
cluster,
that
particular
operation
is
applied.
F
That
operation
can
be
anything
if
you
go
into
that
life
cycle.
Page
you'll
find
that
there
are
multiple
operations
that
you
can
actually
apply
in
any
of
your
given
service
mesh
so
currently
before
this
multi-context
pr.
That
thing
was
limited
to
single
cluster,
but,
as
you
can
see
on
the
dashboard
as
lee
was
showing
current
like
he
has
only
one
cluster
right
now
or
one
single
context.
Instead
of
his
cube
config,
the
docker
desktop
one.
F
So
that's
why
we
only
see
that
currently,
that
particular
thing
in
the
navbar
is
pretty
no,
it's
only
for
sure.
Basically,
it
does
not
do
anything,
so
the
call
for
volunteers
is
to
make
it
do
something,
and
what
do
I
mean
by
make
it
do
something?
Basically,
when
we
click
on
any
we,
let's
say
there
are
five
contacts
in
that
particular
drop
down
and
someone
clicks
on
to
selects
four
of
them,
so
we
need
to
persist
first
of
all
persist
that
on
to
the
front
end
that
these
are
selected
context.
F
The
next
step
is
that,
after
selecting
those,
if
any
operation
is
applied
like
install
a
service
mesh
or
basically
a
patent
file
is
deployed
in
mesh
box,
we
do
or
some
basically
any
operation
is
performed.
We
need
to
do
that
on
all
of
the
clusters
and
how
we
would
do
that
from
the
ui
part
is
by
providing
the
context
ids
of
all
the
selected
contexts
in
the
query
parameter
what
that
makes.
F
So
the
current
task
is
that
both
in
mexico,
as
well
as
mesh
ui,
because
a
lot
of
times
we
forget
that
we
have
messy
ctl
as
well,
and
it's
important
to
take
that
along
so
people
who
want
to
contribute
and
go.
They
can
go
over
messy
ctel
people
who
want
to
contribute
and
react.
They
can
go
over
mesh
to
ui.
Basically,
we
want
to
be
able
to
any
request
that
is
concerned
with
anything
related
to
kubernetes,
whether
installing
something
in
the
cluster
or
anything.
F
You
need
to
get
that
context,
and
the
end
point
is
slash
api,
slash,
kubernetes
context.
There
you'll
have
the
all
of
the
available
context
from
there.
Basically,
after
you
persist
the
context
ids
you
can
provide
that
into
the
query,
parameter
and
backend
will
handle
it.
All
you
have
to
do
is
persist
that
content
for
for
the
michelin,
ui
part
versus
those
contacts
somewhere
in
react
or
in
redux
we'll
process
that
into
our
state
so
purchase
that
and
then
on.
F
Every
api
call
after
that,
basically
send
those
into
the
query
parameter
from
messy
ct
and
do
the
same
exact
thing.
I
don't
know
how
we
would
approach
this
in
mexico.
That
thought
would
a
little
bit
of
thought
would
be
required
like
we
can
maybe
provide
a
flag
or
something
basically
to
tell
the
user
that
in
which
particular
context
or
in
which
particular
cluster
they're
actually
applying
that
operation.
For
example.
F
Right
now,
if
you
just
say
messy
cd
and
pattern,
apply
or
message
detail
something
system,
something
something,
then
that
would
only
take
place
in
your
current
context.
We
need
to
take
care
of
that
too.
So
maybe
a
flag
would
be
a
nice
thing
to
have.
So
if
anyone
who's
looking
to
attribute
in
cli,
you
can
add
a
flag
and
what
that
flag
will
potentially
do
is
that
it
would
okay,
so
what
that
flag
should
do,
I
think
we
can
make
it
like
a
little
bit.
F
You
know
user
interactive,
something
maybe
if
they
don't
specify
a
context
we
provide.
We
when
they
do
mechanical
pattern,
apply
something
and
when
they
click
enter,
we
show
them
all
of
the
basically
available
context
on
which
they
can
apply
it
to
just
like
in
ui.
We
have
so
this
from
there
they
can
select
it.
I
mean
I
was
just
you
know,
going
over
the
possible
ways.
So,
basically,
the
point
is
that
in
ui,
as
well
as
message
ctl,
we
need
to.
F
A
A
There
are
a
few
enhancements
may
be
wanted,
but
only
a
few
needed,
and
then
there
are
a
number
of
enhancements
needed
in
mesherie's
ui
to
ensure
that
when
someone
is
looking
at
to
ensure
that
I
won't
repeat
what
all
of
our
she's
just
said,
he
just
kind
of
described
much
of
the
need
from
this
client's
perspective.
But
it's
really
is
you
know
it's
both
clients,
like
he
had
said,
mesher
cli
and
mesh
reui
that
need
to
account
for
a
multi-cluster,
slash,
multi-contact
experience,
much
of
the
inner
workings
of
mesh
reservoir
mesh.
A
So,
if
you're
in
the
community
or
have
you
kind
of
filled
in
your
member
form
and
you've
got
access
to
some
of
the
community
resources,
there
are
I'll
drop
a
link
to
a
couple
of
different
documents.
I
think
we
can
delete
this
stock
good.
I
think
this
is
all
mostly
been
moved.
There's
just
kind
of
notes,
we'll
get
a
link
to.
I
believe
this
central
document
anyway,
you'll
find
this
as
a
topic
inside
of
the
community
drive.
G
Okay,
so
the
design
spec
for
mystery
ctl,
like
has
been
written
already,
and
I
have
made
some
comments
over
there.
It's
a
request
for
you
guys
to
go
over
there
and
check
what
those
comments
are
and
so
that
we
can
progress
ahead
and
like
work
on
what
we
actually
want
to
make
like
a
make.
The
cli
work
how
it
will
work
or
not.
So
it
has
a
like
what
should
I
say,
a
proposal
for
how
mesh
config
can
work
with
multiple
kubernetes
having
their
names
or
maybe
their
cube,
config
paths.
A
A
C
G
A
A
Perfect,
this
is
great
yeah
and
what
an
opportunity
for
people
to
jump
in
and
consider
this
this
this
area.
Actually,
I
I'm
gonna,
make
a
statement
and
I'd
love
to
hear
if,
if
people
think
potentially
differently,
one
of
the
well
not
singularly
novel,
but
one
of
the
more
novel
functionalities
that
users
would
come
to
enjoy
from
meshary
from
a
management
plane
is
was.
A
This
is
functionality
around
multi-cluster
support
and
then
all
you
know
just
in
general,
about
managing
kubernetes,
multiple
kubernetes
clusters,
but
also
about
managing
service
mesh
deployments
that
span
multiple
clusters.
There's
a
there's.
A
number
of
the
networking
gets
fun
for
those
service.
Mesh
deployments
measuring
will
need
to
be
aware
of
some
of
what
that
networking
is
you'll
need
to
help
configure
those
service
meshes
to
to
well
configure
those
surface
meshes
to
do
different
style
deployments
because
there's
different
ways
of
interconnecting
clusters.
H
A
Oh
yeah,
I
mean
they
they
so
so
I
don't.
I
don't
look
at
solo
stuff
much,
but
they
there's
a
glue.
Mesh
is
kind
of
a
competitive
project
to
measure
at
least
right
right
now,
it's
not
intended
to
be,
but
it
really,
they
really
only
support
istio
anymore.
There's
some
claim
for
supporting
open
service
mesh,
at
least
what
I
can
see
in
the
code.
There's
some
claim
for
supporting
open
service
mesh
and
maybe
app
mesh,
but
probably
pretty
nascent
anymore.
A
They
have
a
product
offering
that
is
a
distribution
of
istio
and
they
at
least
last
year,
their
last
solocon.
Well
badmouthed
is
probably
the
most
accurate
way
of
saying
it
any
all.
The
other
meshes
other
than
istio
basically
said
it's
an
istio
only
world
and
so
and
they've
rebased
their
product
on
istio
and
they're,
adding
value
on
top,
and
I
added
a
lot
of
comments
just
then
on
things
that
I've
seen
in
the
past.
A
I
haven't
seen
any
of
the
enterprise
offering
or
the
value
that
they
add
on
top
and
I'm
I'm
sure
it's
great,
I'm
sure
it's
quite
helpful.
They
probably
most
no
doubt
they've
got
solutions
around
homeogenious
like
the
centio,
istio,
multi-cluster,
istio
deployments,
and
no
doubt
they've
got
that
covered.
A
Istio
has
a
couple
of
different
answers
here
that
are
have
been
around
for
some
while
they've.
Some
of
the
some
of
how
that
is
implemented
has
changed
over
time
for
sure
over
the
last
two
years,
like
changed
a
fair
bit
for
the
better,
and
then
you
know
like
I,
I
don't
know
I'd
be
surprised
if
kong
slash
kuma
didn't
you
know,
didn't
didn't
have
like
it
may
not.
Kuma
itself
may
not
support
it,
but
maybe
kong
does
console
like
they
definitely
support
federation
as
an
enterprise
feature
they
they
definitely
do.
H
So
the
the
reason
I
was
I
was
asking
is,
I
was
wondering
if
there
might
be
a
benefit
in
separating
the
multi-cluster
topic
here
into
measuring
in
the
idea
of
using
you
know,
contexts
to
switch
between
completely
separate
clusters.
So
you
have
a
cluster,
an
eks
one
aksp
and
gk
whatever
and
they're
each
their
own
thing,
and
you
can
just
point
measure
and
say:
hey
use
this
context.
For
this
context,
you
can
keep
cuddle.
I
know
you
say,
don't
don't
don't
cuddle
your
infrastructure,
but
I'm
gonna
keep
doing
it
all
right.
H
H
A
A
A
And
there's
some
operations
that
I'd
like
to
perform
against,
or
some
maybe
metrics
that
I'd
like
to
look
at
against
just
that
cluster
over
there
and
then
I'd
like
to
maybe
update
that
cluster
or
perform
an
operation
against
just
that
one,
and
then
I'd
like
to
kind
of
quickly
switch
contexts
and
go
cuddle.
Some
other
infrastructure
over
here
you
know
and
so
yeah
this
switcher.
H
A
Well,
so
fine
you've
got
you
know
as
a
project.
You've
got
great
support
for
multiple
kubernetes
clusters,
you
know
and
then
in
this
environment.
Maybe
we've
got
four
clusters
deployed
for
kubernetes
clusters
and
a
deployment
of
a
mesh
that
actually,
you
know,
spans
and
runs
workloads
across
all
four.
What
does
that
look
like
in
the
ui
and
how
do
you?
How
do
you
let
someone
know
that,
like
what's
the
construct
for
representing
that,
because,
because
today
this
this
doesn't
you
know,
provide
you
that
info
and
to
the
extent
that
not
only
is
meshrie
doing
that?
A
Maybe
for
you
know
for
like
an
nginx
service
mesh
deployment,
that's
across
clusters
that
then
also
it's
doing,
that
for
console
or
for
small
like
it
gets
fairly
complex
in
terms
of
both
supporting
those
environments,
but
then
also
providing
people
a
user
experience
around
that.
And
so
what
is
that?
So
so
yeah,
I'm
in
vehement
agreement
with
what
you'd
said
about.
A
A
What
does
that
look
like
and
how
would
that
affect
the
type
of
support
that
you're
providing
for
for
kubernetes
support
so,
which
is
to
say
one
of
the
concepts
that
we
talked
about,
and
so
maybe
jared
this
might
fall
in
line
with
your
thinking.
Is
that
let's
say
that
you
know
you
say
that
you're
in
an
environment
and
you've
got
you've
got
you
know
30
clusters
like
in
this
day
and
age.
A
I'm
not
sure
that
that's
even
a
very
large
thing,
you
know
maybe
you're
letting
all
of
your
developers
individually
connect
up
their
their
clusters,
the
same
piece
of
management
software,
and
so
you
know,
you've
got
50
engineers.
They've
got
their
50
clusters,
then
you've
got
you
know
10
in
prod
and
10
and
qa.
You
know,
anyway,
you
can
end
up
with
a
lot
of
clusters
and
so
hey
at
some
point
it
because
the
just
the
ui
could
become
unwieldy.
A
Maybe
you
have
a
collection
of
clusters
that
you'd
like
to
group
together
and
that
group
is
in
a
specific
geographic
re,
whether
you
want
to
carve
it
up
by
region
or
by
purpose
like
that's,
prod
or
or
this
is
a
dedicated
group
of
clusters
for
an
organization
or
for
a
customer,
or
so
this
concept
of
environments
like
there
may
be
the
need
for
another
construct.
Another
concept,
whether
that's
cluster
groups
or
environments,.
H
Because
I'm
sure
this
will
be
a
fair
amount
of
work
and
the
the
fundamentals
would
be
making
sure
that
measuring
can
handle
the
multi-cluster
use
case
and
then
I
would
kind
of
think
the
next
step
would
be
all
right.
So
we
know
that
we
can
handle
multi-cluster
all
right.
So
now,
how
are
we
going
to
integrate
with
service
meshes?
Who
are
communicating
across
multiple
clusters
and
and
tie
into
that?
And
so
I
was
thinking
of
using
the
mystery
multi-cluster
context,
as
kind
of
the
first
stepping
stone
there,
rather
than
combining
them.
H
A
This
is
thanks
for
bringing
this
up.
I
mean
I,
this
is
pour
those
thoughts
into
here.
If
you
would
early
and
and
you're
right
about
walking
before
we
fly,
there's
there's
some
running
in
between
we
fly,
which
is
there's
some
advance
like
this
is
some
fairly
advanced
and
somewhat
complex.
Stuff
and
part
of
the
part
of
the
challenge
with
this
body
of
discussion
is,
is
not
just
that.
A
It's
somewhat,
you
know
sophisticated
in
nature,
but
it's
also
that
it
can
be
an
area
of
volatility
for
the
meshes
themselves,
as
as
some
of
them
are
evolving
in
terms
of
how
they
do
like
their
own
federation
yeah
jared.
I
can
only
encourage
you
to
be
make
make
a
mess
of
things
like
with
those
thoughts
and
and
yeah,
whether
whether
they're
our
you
know,
design
concept
in
in
thinking
or,
if
they're,
just
sort
of
procedural
in
hey
prioritizing
what
we
might,
what
we
should
collectively
do.
H
H
Okay,
it
it
it's
mostly
just
a
heads
up
regarding
some
some
changes
in
mesh
kit
and
measuring
adapter
library.
I've
been
working
on
updating
those
to
the
latest
golang
version,
and
there
has
been
some
I've
made.
Some
other
major
changes
as
far
as
some
of
the
references,
because
various
libraries
have.
H
And
then
in
measuring
adapter
library,
doing
some
changes
to
the
open,
open
tracing
references,
some
of
the
structs
and
things
have
been
renamed
or
removed
all
together.
The
project
wasn't
structured
things
like
that,
and
so
I
was
hoping
to
get
those
merged
in,
but
I'm
afraid
that
there
might
be
some
unforeseen
consequences.
Part
of
that
you
know,
I'm
not
sure
how
all
the
dependencies
work
out.
When
I
first
well,
I
started
out.
I
was
planning
to
update
nginx
service
mesh
adapter,
and
then
I
ran
into
a
dependency
failure
on
measuring
adapter
library.
H
So
I
went
update
that
and
then
that
failed
because
of
mesh
kit.
So
it's
this
long
chain
of
dependencies,
so
I've
been
trying
to
work
through
that,
but
just
want
to
give
a
heads
up.
If
those
do
get
merged,
there's
you
can
keep
an
eye
out
in
case.
Anything
else
starts
failing
because
we've
been
trying
to
get
those
updated
as
quickly
as
possible,
or
I
don't
know
if
there's
a
if
you
have
a
process
for
this
sort
of
thing.
A
Tiwari
is
probably
your
is
one
of
your
brothers
in
arms
here
or
like
your
partner
in
crime
or,
however,
you
want
to
think
of
it,
but
it's
to
help
like
both
potentially
get
you
empowered
with
some
permissions
to
like
move
briskly
across,
but
also
to
help
be
be
qa
for
you
or
be.
You
know,
be
a
provide
feedback
on
what
those
you
know
like
what
those
breaking
changes
are
impacting
we're
it's
about
time
for,
like
a
a
minor
bump
in
mesherie's
overall
release.
A
Anyway,
like
I
don't
know
how
many
more
release
candidates
we
can,
we
can
do
you
know
the
numbers
allow,
and
I
say
that
jokingly.
Actually,
we
should
just
we're
ready
for
another
measure,
server
release
and
so
understanding
that
mesh
reservoir
also
leverages
mesh
kit.
It
may
be
and
they're
breaking
changes.
We
may
be
forced
to
make
that
release
and
that's
fine
like
it's
time,
so
we
shouldn't.
H
A
H
A
A
H
A
That's
great
all
right
we're
a
bit
over
time.
It
was
very
nice
to
see
you
all
and
it's
nice
to
hear
some
meshy
jokes
too,
so
good,
okay,
we'll
catch
you
all
in
either
in
slack
or
raj,
is
alluding
to
some
things
that
we'll
talk
about.
I
think
on
friday,
for
preparing
for
both
chico
africa
and
open
force.