►
From YouTube: Meshery Development Meeting (Feb 16th, 2022)
Description
Meshery Development Meeting - February 16th 2022
Agenda -
- Check for expired tokens/expired token error message #4989
- Update the user on "Token" expire #319
- Status of Meshery v0.6.0 tests
- Increase test coverage in GitHub workflows using service mesh patterns. Sheet
- Multi-context support in Meshery.
- Migration of MeshKit repo.
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
We'll
do
a
couple
of
housekeeping
items
which
is
if
you're
new,
on
the
call
we
have
a
tradition,
say
hi
introduce
yourself
get
harassed.
There's
lots
of
sarcasm
that
flows
around
here.
So
all
purely
out
of
love
and
the
enjoyment
of
the
giver
of
the
sarcasm.
I
think,
if
yeah
actually,
so
we
should
pause
there
right,
we
should
say:
hey
yeah.
Is
there
anybody
new
on
this
call?
A
A
A
A
B
A
B
A
B
B
A
E
I
completed
my
engineering
in
computer
science
and
then
I
was
working
for
big
binary
as
a
qa
automation
engineer
like
basically,
I
was
working
with
cyprus
to
test
react,
based
applications
and
all,
and
then
I
realized
that
that
I
could
do
more.
Then
I
resigned
and
started
learning
monstab
and
after
like
four
five
months,
I
kind
of
completed
like
some
of
my
on
the
tutorials.
I
was
following
from
youtube
and
now
like
like
from
a
few
weeks,
I
started
to
like,
like
see
all
the
open
source
things
and
like
today
successfully.
E
A
E
A
F
But
basically,
I
think
piyush
pointed
out.
There
is
a
function
and
the
auth.go
file
new
request
that
we
could
put
these
checks
for
as
far
as,
like
a
token
goes,
and
I
kind
of
moved
him
over.
There
deleted
the
checks
just
in
the
profile
result
and
apply
commands
from
the
perf
command
tree
and
it
seems
to
be
working
pretty
well.
I
could
do
a
little
demo
here
for
you.
F
F
F
There's
a
couple
like
checks,
you
know
it's
just
kind
of
unsure
of
how
they
fit
in
so
these
lasso
checks
here
all
three
of
those
commands
check
them
and
I'm
just
a
little
unsure
kind
of
how
to
implement
them
in
a
centralized
way
because
they
use
this.
A
response
variable
that
is
ultimately
gets
returned
by
this
function.
F
F
Whenever
I
push
this
to
the
to
the
pull
request,
because
it
ends
up
using
this
response
before
checking
it,
although
it
gets
checked
within
this
new
request
function,
it's
probably
not
good
to
go
ahead
and
just
use
it
here
without
checking
again.
If
that
makes
any
sense,
that's
so
throwing
a
few
errors
on
on
the
pr,
because
you
know
we're
using
it
without
checking
anything,
although
we
do
check
it
and
appear
in
the
new
within
the
new
request
function.
F
G
Okay,
I
have
left
the
comment
on
your
pia.
I
think
we
can
discuss
it
there.
The
idea
was
to
like
you
can
see
this
line
of
these
lineup
code
from
140.
We
are
like
reading
the
response
and
then
we
are
like.
We
are
executing
the
request
inside
inside
the
new
function
in
your
code
and
now
we
are,
we
are
making
a
request
again
here
in
online
137,
so
we
have
already
done
it
in
new
request.
G
I
think
we
can
return
the
response,
whatever
we
got
from
there
directly
here,
so
we
won't
be
making
a
new
request
on
line
137
and
that
response
will
be
directly
passed
to
line
145
and
we
will
have
the
like
the
response
turned
into
what
should
I
say
what
I'm
trying
to
say.
Whatever
response
we
got
from
got
from
the
first
requesting
new
request
function,
we
will
return
that
function
instead
of
that
http
request
at
the
end
of
the
return
statement.
Okay,
so
I
think
am
I
making
sense
gotcha.
F
G
C
C
H
Yeah,
so
the
topic
was,
we
need
to,
you
know,
notify
the
user
to
log
in
again,
once
their
token
expired.
So
my
approach
was
like
with
each
private
request.
We
are
going
to
send
the
token
and,
on
the
back
end,
we
are
going
to
check
whether
the
token
is
expired
or
not,
and
if
it
is
expired,
we
will
redirect
it
the
user
to
the
login
page.
A
Cool,
so
we're
talking
about
kind
of
the
same
issue
around
making
sure
that
users
have
valid
tokens,
one
especially
around
the
tokens
that
haven't
expired,
so
jared's,
I
remember
now,
jared's
hitting
it
from
you
guys
are
both
hitting
it
from
two
different
client
perspectives:
raj
from
the
measure
ui
jared
from
the
cli
yeah,
okay,
good
yeah
raj.
Please
continue.
G
So,
okay,
so
raj
was
proposing
that
if
someone
is
like
working
with
the
slash
profile
page
on
ui
and
suddenly
he
got
that
it
is
expired.
So
what
he'll
do
is
he'll
re
like
he'll,
save
that
url
as
a
parameter
and
redirect
them
to
login
again
and
once
they
have
logged
in
again
they'll
get
redirected
to
the
same
page?
G
Okay.
So
that's
what
he's
proposing!
I
think
there
are
several
things
to
like
make
sure
that
we
do
like
clear
the
cache
stored
in
our
browser,
the
cookies
and
then
make
this.
This
redirection
like
actually
happen.
So
I'm
not
a
like
a
ui
geek.
I
think
niche
and
other
people
can
comment
how
this
can
be
executed.
A
A
They
go
about
the
business
of
re
up,
re-authenticating
and
logging
back
in
and
when
they're
done,
instead
of
dropping
them
onto
the
home
page,
the
the
main
dashboard
they're
redirected
back
to
where
they
go
so
the
you
know,
the
ux
sounds
pretty
great,
there's
a
dependency
that
was
just
being
updated.
Today
it
was
a
ui
redirect
dependency,
so
raj
is
part
of
the
approach
that
you've
been
looking
at
here.
A
A
And
so
yeah,
so
actually
let
me
try
to
phrase
that
into
more
of
a
question
I
guess
which
is
like
of
what
you've
considered
thus
far
are
you
is
the
focus
of
the
change
that
you're
working
on?
Is
that
a
next
js
chain
configuration
or
is
that
incorporation
of
use
of
the
library
that
will
help
track
where
to
redirect
the
user
back
to
or
is
there
something
custom
that
you're
thinking
about.
H
No
so
far,
I
think
you
know
we
can
do
with
the
existing
libraries,
because
whenever,
whenever
we
do
a
redirection
for
the
user,
there
is
an
inbuilt
html
tag
which
stores
the
value.
If
the
user
is
coming
from
some
redirected
page,
so
yeah
one
successful
login,
we
can
use
that
information
to
redirect
the
user
back
to
the
page.
A
Cool
what's
the
question,
or
is
it
just
just
verification
that,
like
that
the
approach
that
you're
specifying
right
here
there
can
be
multiple
ways
solve
this,
but
I'm
assuming
that
each
request
we're
sending
the
token
to
the
server
and
with
each
request
private
routes
that
on
the
server
side
we
are
verifying
the
token
yes,
we
are
so
once
the
token
expires.
While
the
user
is
on
the
performance
page,
for
example,
they
can
be
redirected
to
login
on
the
login
page.
A
A
A
Or
pranav-
or
I
don't
know
that
yeah
no,
even
if
there
were
it's
not
like,
we
necessarily
would
want
to
invalidate
any
of
those
cash
any
of
that
cash.
So
so
good.
So
by
the
way
for
clarification
of
the
focus
that
you're
looking
at
there
was
another
individual
who
had
been
working
on
notifying
the
user
that
they
had
an
expired
token,
so
that
if
the
user
was
you
know
if
they
someone
had
signed
in,
they
got
up
and
left
their
keyboard.
A
A
A
A
A
There
might
be
something
there
like
a
framework
like
that:
it's
a
common,
it's
a
very
commonplace
use
case
for
any
web
app,
so
the
framework
might
handle
something
good
well.
So,
as
we
move
on
to
the
next
topic,
I
figured
since
since
we're
talking
about
tokens
and
expiring
them,
or
I'm
sorry
talking
about
tokens,
the
the
user,
improving
the
user
experience
when
someone
has
an
expired
token,
or
they
just
haven't,
authenticated
to
the
system
to
measure
your
server.
A
I
also
note
that
there's
been
kind
of
a
long-standing
issue.
It's
a
security
related
issue
having
to
do
with
tokens.
So
there
you
are
measuring
users,
get
a
token,
get
an
authentication.
You
know
authenticate
and
get
a
token
from
a
provider,
an
identity
provider.
That's
like
the
first
screen
that
they're
shown
when
you
go
to
use
measuring,
there's
a
drop
down
list.
There's
a
couple
of
choices.
One
of
the
choices
is,
it's
called
none.
It's
the
built-in
local
provider.
A
When
you
choose
the
local
provider,
the
user
is
essentially
choosing
to
have
well
essentially
a
single
user
experience
when
in
using,
measuring
and
and
and
good
now,
for
that
measuring
deployment
that
they're,
basically
an
anonymous
user
using
a
tool
that
they
you
know
using
measuring
that
they've
deployed
so
they're
like
an
anonymous
user,
we
there's
a
token,
that's
generated
a
token
that's
generated,
and
for
that
particular
session,
if
I
have
my
stream
up
I'll
I'll
show
it
just
for
context.
Like
a
gust
of,
I
wonder
if
I
like.
A
A
A
Sometimes
some
some
of
you
have
used
that
when
you
want
to
go
out
or
or
just
kubernetes
dashboard
or
kubernetes
api,
and
as
you
go
to
interface
with
that
api,
or
you
can
interface
with
that
dashboard,
you,
you
know,
there's
a
couple
of
different
authentication
mechanisms
to
use.
One
of
those
is
a
token
you
know
a
bearer
token
and
that
helps
provide
security.
A
A
I
Yeah,
so
to
highlight
something:
if
your
message
is
behind
the
ingress,
you
may
not
see
this
kind
of
issue
because
whenever
it
is
installed-
and
it
has
a
load
balancer
I
be
exposed,
then
you
have
this
particular
issue
coming
in.
So
I
that
is
my
idea.
So
I
have
also
tried
to
do
that.
So
if
you
install
it
behind
ingress,
then
of
course
you
will
not
able
to
login
with
non.
A
Yes,
bbk
and
it's
like
hey,
hey,
don't
do
that
or,
and
so
we're
kind
of
identifying
it
either
as
out
of
scope
for
the
project.
It's
like
look.
It's
all
kinds
of
security
mechanisms
to
use
samir
just
mentioned
one.
You
know
use
use
another
tool
to
make
sure
that
you're
you're
protecting
this
endpoint
to
your
protectiveness.
A
Yeah
and
for
any
yeah
into
samir's
point
like
for
any
you
know
with
seasoned
or
not
any
anyone,
who's
running,
kubernetes
or
running
any
amount
of
infrastructure
like
these
are
security
concerns
that
they
have
to
deal
with
routinely
with
any
software,
any
any
infrastructure
that
they're
deploying.
So
this
isn't
odd
in
any
way
over
time,
and
so
it
might
be
something
that
again,
I'm
bringing
up
now,
but
maybe
we
just
choose
to
punt
it
down
the
field
and
and
potentially
address
later.
A
A
We
don't
want
to
ship
a
piece
of
software
that
has
that,
but
that
is
insecure
by
default,
or
that
doesn't
so
like
an
example.
Here
is,
if
you
all
have
pro,
probably
you
all
have
like
a
wi-fi
router
at
home,
used
to
be
wi-fi
routers,
you
deploy
them
and
what
used
to
be.
They
just
pull
up
an
open
network
and
anybody
could
come
by
and
and
you'd
share
your
network
with
them.
Your
wireless
network
would
be
you're
insecure.
A
Also,
the
administrative
interface
on
that
wi-fi
router
would
also
be
opened
and
or
I
have
a
standard
like
admin
password,
and
you
know
over
time
as
the
internet
picked
up
and
more
people
got
wi-fi
at
home.
Wi-Fi
was
more
prevalent
like
that.
Those
those
things
have
been
changed
like
they'll
ship,
you
the
unit
and
then
they'll
say
you've
got
to
change
your
password
on
the
first,
like
as
you
deploy
it.
A
Eventually,
when
we
reach
our
one
one
millionth
and
one
user,
then
we'll
be
forced
to
address
this
in
the
meantime.
Does
anybody
have
I
mean
samir's
statement
is
perfect
and
it's
like
one
of
those
things
to
have
in
the
dock.
You
know
in
our
deployment.
Docs
is
like
hey.
A
a
hardened
deployment
of
meshri
includes
endpoint
protection,
and
so
here's
you
know,
there's
a
variety
of
ways
to
accomplish
that.
I
A
Yeah,
it's
totally
that's
such
a
great
suggestion.
Here's
the
that's
an
evolution
of
the
project.
I
think
when
we
so
right
now
what
we
have
more
of
a
challenge
of
is
people
trying
to
deploy,
measuring
and
stumbling
all
over,
like
even
being
able
to
expose
the
endpoint
to
get
to
the
thing
and
yeah.
I
think
that
to
samir's
point
we'll
hit
an
inflection
point
by
which
there's
enough
seasoned
operators
using
measuring
and
saying
look,
you
know,
like
here's,
here's
one
step
towards
a
more
secure
out
of
the
box
posture,
so
smear
hold
key.
A
I
Yeah
we'll
write
it
down
on
community
page,
so
people
yeah
and
for
the
standalone
install
installations
who
are
doing
so.
It
is
very
much
kind
of
you
know,
cloud
agnostic,
so
there
are
policies
which
you
can
enforce
so
vm
should
not
have
public
ips
so
that
they
will
be
using
some
kind
of
ingress
path
or
gateway.
A
There
but
yeah
perfect,
I'm
gonna
try
to
share
a
couple
of
links
as
we
move
on
to
the
next
topic,
but
there
should
absolutely
be
there's
somewhere
there's
a
draft
guide
to
like
a
hardened,
what
a
production
deployments
look
like
and
the
various
concern
considerations
that
people
need
to
make
yeah.
So
samir
good
point:
okay,
other
comments
on
tokens,
security.
A
A
A
A
Some
of
those
test
results
are
now
centralized
and
pushed
into
mesh
redox
into
the
compatibility
matrix
there.
So
you
can
see
the
latest
status
of
integration
tests
that
have
been
run
with
nvendy's,
pointing
out
that
the
integration
tests
are
basic
in
nature.
Today,
they're,
not
real,
specific
ashish,
and
even
you
mario,
like
what
what
do
we
have
for
in
the
works
for
more
space
for
deeper
tests
using
patterns.
J
Yeah
so
recently
I
updated
updated
patents
report
to
have
more
patents.
So
one
thing
is
that,
with
the
patents
we
can
test
that
we
are
able
to
deploy
more
and
more
complex
patents
using
meshi.
For
example,
we
had
an
import
feature
recently,
so
you
can
basically
condense
a
break
pattern
file
into
a
smaller
pattern
file,
and
but
when
we
test
that
we
can
be
sure
that
you
know
basically
all
the
all
the
features
that
meshi
says
it
provides.
It
actually
does
so.
J
The
next
step
might
be
to
to
basically
right
now,
mostly,
we
have
patent
files
that
are
very
specific
to
istio.
So
we
have
book
info
and
we
have
other
apps
only
for
stu,
so
we
can
have
more
application
inside
of
our
service
mesh
patterns,
repo
that
reflect
that,
basically
for
traffic
for
osm
for
puma.
Basically,
we
have
applications
for
different
types
of
service
meshes
and
then
maybe
we
can
have
you
know
like
using
the
import
feature.
A
Wait,
wait,
wait,
I
think
you
probably
let's
can
you,
can
you
show
people
part
of
what
this
is?
Can
we
get?
Can
we
make
an
ask
of
those
that
we
want
to
volunteer
here
because
the
because
patterns
are
and
use
of
those
are
going
to
be
pervasive
within
measuring,
and
so
we
should
have
any
number
of
like
patterns
designs
available,
but
we
should
have
a
bunch
of
sample
apps
yeah.
J
Yeah,
so
if
so,
this
is
what
what
navindu
showing
right
now.
This
repository
is
also
what
we
use
when
we
seed
our
content
for
the
local
provider.
So
if
you
want
to
so
basically,
we
encourage
people
to
write
more
and
more
pattern
files,
there's
also
in
our
disks
form.
We
also
discuss
how
to
write
pattern
files
and
also
you
can
go
to
the
discus
form
and
if
you
want
to
have
some
help,
writing
any
kind
of
patent
file.
There
are
people
available
there.
J
There
are
demo
patent
files
there,
the
you
can
get
an
idea
about
how
to
write
a
patent
file.
If
you
go
to
the
service
mesh
patents,
okay,
go
to
the
root
repository
here.
You
also
have
a
usage
dot,
markdown
uses
dot
md,
which
basically
goes
over
a
few
of
the
features
of
a
few
of
the
fields
in
a
pattern
file
and
how
you
can
use
them.
J
This
needs
to
be
updated,
I'll
update
to
I'll
update
it
to
reflect,
because
still
a
lot
of
people
don't
actually
know
how
to
write
them
so
like,
for
example,
a
lot
of
people
don't
know
what
references
are
in
a
patent
file
which
is
a
very
powerful
construct.
A
lot
of
people
don't
know
how
we
can
use
depends
on
and
all
so.
This
is
kind
of
an
overview
of
those
things
and
I'll
update
it
to
reflect
more
and
more
thing.
J
So
I
will
and
I'll
encourage
that
if
you
really
want
to
volunteer,
you
can
volunteer
and
write
your
own
pattern
files.
So
you
can
go
over
to
any
particular
service
message
manifest
and
you
can
convert
that
into
a
patent
file
by
putting
it
on
to
services.
Service
is
basically
a
unit
of
deployment
in
a
patent
file.
So
I'll
add
that
in
this
uses.md
as
well,
so
as
you
understand
more
and
more
about
the
pattern
files,
you
can
even
contribute
to
the
service
mesh
patterns,
repo
updating,
the
user.markdown
and
all.
J
J
I
would
actually
encourage
you
to
start
a
public
discussion
either
in
the
discuss
forum
or
in
the
measuring
slack
channel,
and
people
would
be
more
than
happy
to
help
you
there
and,
as
we
have
more
and
more
patent
files,
we
can
use
your
even
your
patent
files
for
our
tests
that
we
do
in
our
adapters.
So
basically,
the
more
the
patent
file
is
the
more
we
can.
The
robust
our
systems
would
be
as
we'll
have
more
and
more
tests
to
run
with
those
patent
files.
J
Oh
hello,
I'm
audible,
yep,
yeah,
okay,
so
this
spreadsheet
is
where
we
track
the
status
of
all
the
adapters.
So,
as
you
can
see,
we
are
deploying
the
we
are
deploying
the
currently
we're
deploying
the
sample
app
only
for
sto
and
actually
not.
We
are
not
even
deploying
this
sample
up.
We
are
deploying
the
add-ons
actually
so
sample.
J
Apps
are
not
being
deployed
for
any
other
service
for
any
of
the
adapters,
so
we
are
only
deploying
the
control
plane
and
there
are
subsequent
add-ons
like
prometheus
and
graphene,
and
we
are
testing
whether
the
ports
come
up
properly
or
not.
So
the
next
step
would
be
again.
We
like
booking,
for
we
can
have
deploy
a
book
info
app
as
a
end-to-end
test
for
istio
and
we
can
deploy
an
emoji
world
of
linkedin
each
of
these
applications.
Each
of
these
service
measures
have
their
own
in
their
repos.
J
J
Okay,
so,
instead
of
workflows,
we
have
this
e
to
e
tests,
and
currently
we
have
currently
we
only
test
the
service,
mesh
installation
and
the
installation
of
service
mission
add-ons,
and
here,
as
you
can
see,
that
we
have
some
some
some
in
the
install
directory.
We
have
these.
These
yaml
files
are
basically
pattern
files,
so
this
is
a
default
sql
service,
mesh
installation
pattern
file.
So
we
have
services
here
and
we
only
have
one
service
these
few
and
the
type
is
system.
J
So
we
see
it
install
systeo
and
the
other
one
installs
istio,
along
with
a
bunch
of
add-ons
like
the
fun
information
here
you
can
see
the
use
of
fields
like
depends
on,
and
if
you
write
a
patent
file
it
would
be.
The
patent
file
will
be
more
robust
if
you
use
fields
like
these
and
you
use
things
like
references.
So
the
point
is
that
currently
we
have
only
two
patent
files
and
we
test
against
only
these
dependent
files.
The
ask
would
be
to
have
another
pattern
file
that
first
deploys
the
service
mesh.
J
J
And
if
I
go
to
the
samples
we
already
have
a
sample
for,
let's
say,
install
now
what
what
this
stu
install
does.
Is
it
installs
istio?
And
if
I
go
to
the
minimal
istio
book
info?
Okay,
so
here
we
already
have
this
pattern.
This
pattern
basically
first
also
uses
the
import
feature.
It
deploys
your
steel
service
mesh.
Then
it
deploys
the
book
info
app
after
the
http
control.
Pane
is
deployed.
J
J
We
only
have
two
like
service
mesh
installation
and
service
mesh
installation
with
add-ons,
so
we
can
have
one
more
like
service
mesh
installation
with
the
book
info
app
and
there
we
would
deploy
this
particular
patent
file,
which
would
deploy
the
sto
and
then
also
deploy
the
book
info.
As
you
can
see
here,
this
actually
references
the
other
patent
file
which
which
internally
has
the
entire
book
info
thing.
So
basically,
this
service
is
referencing
this
this
book
info
patent
file.
So
where
is
it
okay?
Here?
It
is
this
particular
patent
file.
J
So
this
here
you
can
see
the
use
of
references
and
all.
If
you
want
to
make
some
changes
to
this
pattern
file,
you
can
do
that
as
well.
Maybe
add
some
extra
things
here
and
there
and
the
same
thing
we
would
need
in
other
adapters
as
well
and
and
for
other
adapters.
We
would
also
need
so,
for
example,
here
we
have
like
things
like
virtual
servers
and
destination
roots,
so
anymore,
like
the
emoji
photo
for
linker
date
has
its
own
custom
resources.
I
J
J
This
is
it,
and
it
has
this
if
you,
if
I
zoom
in
it,
has
this
vars
field,
so
vars
field
is
basically
the
exposed
field
of
this
particular
pattern
file
and
every
service
inside
of
this
pan
file
references
the
speed
it
has
a
default
value
of,
in
this
case,
just
default,
so
the
name
space
is
default.
So
if
you'll
have
your
own
deployments,
it
will
have
a
default
namespace,
and
what
we
are
potentially
doing
here
is
overriding
this,
I'm
just
overriding
that
with
default.
A
I
J
J
Because
it
would
be
like
we
have
a
pattern
file,
then
we
have
another
yaml
for
that
pattern
file.
So
every
patent
file
has
a
values.tml
helm
defines
its
own.
You
know,
there's
this
helm
chart
and
it
has
chart.yaml
and
there
are
a
bunch
of
yaml
and
then
you
have
templates
and
everything
a
service
mesh.
A
pattern
file
is
patent.yaml
is
should
be
basically
that
unit
of
deployment
should
be
enough
should
be
basically
exhaustive,
so
it
has
everything
it
needs
so
having
a
values.gml
attached
to
each
pattern.yaml.
J
Is
you
know
you
have
it's
like?
Why
do
we
have
that
in
under
the
ammo?
Why
do
we
have
that
those
fields
externalized
into
another
diamond?
So
each
pattern
fight
will
have
a
different
yaml
to
always
keep
track
of
so
and
because
we
don't,
you
know,
have
a
repository
when
we
deploy
a
pattern.
We
have
a
pattern
file
at
single
file,
so.
I
It
has
two
things,
so
one
is
if
somebody
doesn't
know
how
to
write
a
pattern
file
you
may
not
be
it
may
not
be
so
much
user
friendly
rather
than
he
should
always
go
for
values
to
demo
and
do
some
tweak
there
pass
the
values
and
he
need
not
to
write
it.
If
you
get
something
like
that,
so
like
from
the
user
perspective,
it
becomes
very
long
when
you
write
a
lot
of
pattern
in
the
same
file,
then
sometime,
you
know
I
felt
so
when
you
keep
on
scrolling.
J
That's
the
idea
of
this
thing
right
so
for
it
like,
for
example,
in
this
case,
you
could
have
again
even
the
this
is
the
installation
service.
This
does
not.
This
is
not
a
normal.
Your
service,
like
it's,
also
importing
another
pattern.
So
the
thing
that
you're
talking
about
that
this
long
scroll
of
things.
J
All
that
person
has
to
do
is
create
this
pattern
file
and
expose
the
external
variables.
Another
people
will
just
import
that
pattern
file
and
ask
hey:
what's
the
what
are
the
external
variables?
Okay,
I
can
configure
namespace,
so
basically,
I'm
installing
a
booking
for
pattern
and
with
the
namespace.
So
there
is
no
scroll
here.
So
these
would
be
these
can
be
provided
by
the
community
itself.
We
can
write
these
for
you
and
we'll
provide
these
and
we'll
have
as
many
things
as
externally
configurable
as
possible.
J
So
you
don't
have
to
scroll
anything
you
just
import
them
and
override
everything
that
you
need
and
all
the
sensible
things
that
need
to
be
overwritten
would
be
we
would.
We
would
push
them
into
the
vars
field
so
that
they
can
be
overridden
by
you,
so
that
will
basically
tackle
what
you
the
problem
that
you
are
facing,
that
why
do
we
have
these
so
many
long
pattern,
files.
I
J
Okay,
so
talking
in
terms
of
kubernetes
manifest
like,
if
you
have
your
deployments
defined
in
terms
of
communities
manifest
in
messi
server,
we
have
a
function
that
takes
your
manifest
and
converts
it
into
a
pattern
file.
So
you
don't
have
to
manually
push
everything
into
a
service.
It
can
do
it
for
you,
and
once
you
have
that
inside
of
a
pattern
file,
you
can
import
that
pattern
file
onto
another
pattern
file
and
use
it
directly
as
you
wish.
J
B
A
A
Those
are
kind
of
two
two
separate
things.
There's
also
yeah
a
pattern
configurator
in
the
ui
in
measuring.
That
is
intended
to
help
people
not
have
to
write
yaml
because
it
can
get
because
you
could,
like
the
configuration
of
a
given
service.
Mesh,
could
go
on
for
a
long
time
and
it's
not
just
a
service
mesh,
but
it's
kubernetes
as
well.
A
A
I
From
the
mystery
ui,
so
when
I
was
trying
to
like
create
some
patterns,
I
saw
some
unusual
thing,
so
I
might
post
them
in
the
channel
with
the
interest
of
time.
So,
even
if
I
don't
write
anything
in
a
pattern,
but
it
is
still
creating
some
pattern.
Some
entries
in
the
pattern
file
in
the
right
side.
I
A
A
A
A
The
output
of
the
the
results
of
those
tests
are
pushed
dynamically
to
the
docs
here.
So
this
is
this:
is
the
latest
set
of
tests
and
their
status
for
each
adapter,
so
for
the
mastery
istio
adapter,
it
was
run.
The
last
one
was
run
a
few
days
ago.
Four
days
ago,
the
things
that
have
been
tested
was
really
just
basic
provisioning
of
istio
itself,
its
core
components,
and
it
looks
like
we.
We
ran
maybe
some
tests
to
deploy
a
couple
add-ons,
but
don't
have
status
of
those.
A
So
she
like
it.
Not
only
is
there
a
call
for
volunteer
but
also
ashish.
This
is
something
to
to
dig
into
then
for
each
adapter
type,
aditya
subedi
had
made
sure
that
people
can
drill
in
so,
if
you're
looking
at
measuring
istio.
This
is
the
latest
set
of
tests
run
again
four
days
ago,
but
if
you
want
to
see
the
historical
set
of
tests
and
how
that
has
been
happening
over
the
different
versions
of
istio
and
the
different
versions
of
the
adapter,
you
can
go
back
in
time.
A
A
So
that's
about
as
far
as
we've
taken
it?
We're
ready
for
those
next
steps
and
deploying
a
sample.
App
is
probably
that
next
step
so
yeah,
it's
a
really
good.
It's
a
kind
of
a
neat
system.
There's
another
aditya,
I'm
sorry
ashish
will
also
tag
aditya
subeti,
it's
kind
of
familiar
and
he's
been
helping
with
how
how
those
tests
are
dynamically
documented,
they're,
documented.