►
From YouTube: Meshery CI Working Group (June 1st, 2020)
Description
A demo of @LitmusChaos github action with @udit_gaurav15 and @ksatchit today.
B
D
A
A
E
Hey,
yes,
lee
I've
actually
figured
out
every
monday
morning,
something
regarding
measuring
to
add
in
the
linkedin
update,
so
people
that
got
to
know
that
we
are
working
on
that
we
have
some
making
some
progress.
So
I
have
very
small
timing,
I'm
working
on
a
private
project,
so
I
just
throw
it
out
that
people
might
to
know
that
we
have
achieved
a
very
lit
huge
in
a
little.
D
A
Well
now
I
realize
we're
kind
of
you
know
that
maybe
let's
just
start
the
call
we'll
we'll
talk
about
that
a
little
bit
so
to
about
more
about
three
afters,
we'll
get
rolling
and
to
see
karthik.
Here
I
owe
karthik
a
response
on
some
things
so
karthik
we
can
probably
talk
about
that.
Actually,
it's
a
great
topic
karthik
for
this
meeting.
F
C
C
C
C
A
That
sounds
good.
That's
great,
that
you
find
just
a
quick
minute
to
put
something
out.
That's
enough!
That's
good,
and
that
was
a
good
rip.
Just
seeing
your
update
was
a
good
reminder
to
me
that
well
a
couple
of
things,
one
that
we
need
to
go,
write
that
up
a
little
bit
and
talk
about
all
of
last
week's
news,
which
was
quite
a
bit
but
then
also
specifically,
I
opened
up
this
issue
428
on
the.
A
E
All
right,
yes,
last
time
we
were
talking
about
that
if
somebody
hit
the
mystery
website
so
for
the
last
continuous
and
he
doesn't
come
back
in
a
month
or
three
month
or
four
months,
we
have
subscribed
to
them
and
showing
them
updates,
that's
encouraging
to
hate
our
website
or
encourage
them
to
go
on
this
live.
So
I
am
very
pretty
much
inclined
for
that,
and
also,
I
think
we
put
together
some
other
updates
as
well
worldwide
consoles
partnership
with
the
hashicorp.
E
What
console
is
updating,
so
people
got
to
know
that
we
are
pretty
much
in
the
business
now
of
updating
ourselves
regarding
understanding
other
peoples
are
doing
so
I'm
pretty
much
inclined
with
that.
So
really,
I
think
everybody
is
in
the
call
encouraging
that,
so
we
can
weekly
show
them
the
useful
link
for
mystery
to
learn
about
that
this
week.
We
are
done
that
the
last
time
we
have
updating.
E
E
A
F
F
A
Okay,
well,
this
then
actually
that's
it's.
A
good
next
topic
by
the
way
is
karthik.
Last
week
was
just
with
really
something
of
a
blur
for
me,
I
I
didn't
even
I
know
in
my
mind.
I
know
that
there
was
a
message
that
you
had
written
and
I'd
read
like
the
first
sentence,
and
but
that's
not
as
far
as
so,
don't
assume
that
I
have
all
of
the
context.
I
guess.
F
No
problem
yeah,
no
problem.
The
context
was,
I
think,
some
of
the
calls
in
the
preceding
weeks
where
they
discussed
the
possibility
of
running
a
chaos
action
where
you
could
bring
up
a
kind
cluster
as
part
of
the
cia
pipeline
through
a
kit
of
action
and
probably
deploy
a
lap.
That's
that's
part
of
the
measuring
suite
and
then
run
a
simple
chaos
test
against
it.
F
F
F
Now
you
could
consider
this
like
some
kind
of
an
e
to
v.
If
that
has
succeeded,
then
you
go
and
push
the
image
into
the
repository
once
this
is
passed.
So
this
is
the
flow
flow
that
we
sort
of
tried
to
work
with
a
sample
application,
not
really
a
mystery
app,
but
just
a
hello
world
app.
Otherwise,
maybe
users
can
just
share
the
screen.
If
that
particular
flow
is
handy.
H
H
I
H
Yeah,
so
so
this
is
the
workflow
yaml,
which
is
going
to
be
trigger
and
the
first
step
it's
basically
building
a
docker
image.
So
this
image
is
containing
in
the
root
directory.
Here
contains
some
hello,
app
application,
a
sample
one.
It
can
be
different
according
to
our
need.
So
after
building
it,
we
will
just
see
whether
it's
up
and
there
and
then
we'll
just
make
a
kind
of
cluster.
H
So
this
ubuntu
image
ubuntu
latest
comes
up
with
the
kind
installation
we
just
need
to
up
the
cluster
with
I
haven't.
I
have
chosen
a
default
name.
We
can
give
that
also
and
after
having
the
kind
pressure
up,
we
just
need
to
do
a
kind,
get
cube,
config
internal.
It
will
just
make
it
kind
cluster
to
be
accessible
to
our
github
actions
and
after
that,
just
checking
the
nodes
state.
H
So
right
now
it's
not
pushed
and
we
we
will
just
use
this
to
create
this
application
and
we
wait
for
it
to
come
up
and
check
the
status
of
it.
Then
we
will
create
a
liveness
pod
in
this
and
then
we'll
wait
for
that
also
to
come
up,
so
this
is
the
workflow.
And
finally,
we
came
to
our
actions,
which
will
just
right
now
it
is
spot
delete.
F
A
H
Yeah
yeah
yeah,
so
it
takes
seven
minutes.
Approximately
eight
minutes
depends
on
the
docker
build,
so
it
can
be
very
very
it
can
vary
with
the
builds
like
if
it
is
a
heavy
docker
file.
It
can
might
take
some
four
minutes
here,
but
yeah
so
successful.
For
some
successful
run.
It
takes
seven
to
eight
minutes
like
it
was
one
successful
one.
It
takes
eight
minutes
13
seconds.
A
Curious
about
about
docker,
I'm
sorry,
github,
github's
infrastructure
and
what
they
provide
to
open
source
projects.
I
we,
I
don't
recall
if
it
was
on
this
call
or
a
different
one,
that
we
kind
of
looked
at
the
limitations
on
github
workflows
and
how
many
you
can
run
and
that
kind
of
a
thing
for
open
source
projects.
Clearly,
it's
not
an
issue
for
whatever
those
limitations
are
aren't
an
issue
for
what
we're
doing
here.
I
guess
the
question
I'm
trying
to
get
here
is
the
accounting
environment.
H
F
H
G
F
Earlier
conversation,
but
have
not
really
gone
back
and
checked
early,
but
there
are
these
runners
that
we
can
probably
configure.
So
that's
a
vm
environment
which
is
not
the
one
that
it
provides
by
default,
but
we
could
set
up
one
that
sort
of
is
fit
for
our
requirements
and
get
these
actions
done
there.
A
It
strikes
me
that
a
lot
of
times
that
we'll
be
doing
those
performance
tests
in
context
of
a
event.
I
should
say
in
that
event,
being
a
new
version
of
the
eskimize
that
you
know
like
there's
a
pr
merge,
something
similar
to
that
in
the
smi
project
that
we
would
want
to
kick
off.
A
set
of
you
know,
test
validation
tests
and
these
validation
tests
are
a
bit
like
what
we're
looking
at
here.
A
A
A
B
A
A
A
G
F
Okay,
so
this
is
basically,
as
you
can
see,
these
are
all
parameters
that
we
are
going
to
use
to
precondition.
The
experiment,
camels
or
artifacts,
which
are
sort
of
going
to
be
pulled
as
part
of
the
chaos
run
itself.
So
there
is
this
install.
It
must
rule
that
you
see
here
it's
actually
going
to
pull
the
experiment
dml
and
then
going
to
pre-condition
it
with
the
details
that
you've
provided
like
app
name,
space
label,
experiment,
image,
etc,
and
then
the
experiment
is
going
to
be
run
according
to
that
particular
manifest.
F
Now
this
is
a
particulate
experiment
and,
like
you
said
this
particular
action
with
experiment
names,
it
reportedly
knows
exactly
to
run
only
that
experiment,
but
you
could
write
the
actions
for
including
custom
experiments
for
a
particular
app.
So
you
know
what
all
variables
we
want
to
pass
to
it
from
outside.
F
A
Oh
just
to
get
more
familiar
with
it
of
the
actions
that
are
invokable
it
like,
like
the
experiment
image
listed
there.
This
could
be
any
custom
experiment,
that's
cool
and
that
the
way
to
integrate
with
the
chaos
action
that
you
guys
have
created
is
to
have
your
experiment
available
in
a
runner-friendly
format.
F
A
A
So
we're
going
to
spend
some
time.
Looking
at
this
looking
at,
if
this
can
accelerate,
I
mean,
I
think
I
think
it's
kind
of
there's
kind
of
two
things.
Maybe
there's
actually
a
couple
of
things.
I
think
that
collection
here,
one
is,
is
what's
being
shown
here.
Valuable
in
context
of
the
smi
conformance
effort
is
what's
being
shown
here,
valuable
in
terms
of
just
mescheri's
own
platform.
A
Compatibility
testing,
because
it
measuring
needs
to
be
compatible
with
any
number
of
environments
that
you'll
be
running
meshes
on
and
any
number
of
service
meshes,
and
so
we've
got
kind
of
a
gaping
hole
around
integration
tests
ongoing.
You
know,
compatibility
tests.
I
think
that
was
maybe
the
initial
context
in
which
we
were
talking
about
this.
So
so
there's
a
couple
of
avenues
to
explore.
F
Right,
I
think,
probably
also
as
part
of
the
discussion
we
could
just
fit
in
the
chaos
workflows.
I
think
in
1.4.0
we
just
sort
of
tried
to
write
some
more
documentation
around
how
you
could
use
our
go
to
run
parallel
chaos.
I
think,
if
I
understood
right,
I
heard
you
talk
about
performance
testing,
so
you
could
have
a
performance
workload
triggered
off
and
then
parallely
have
some
kind
of
staggered
chaos
when
the
performance
run
is
going
on.
A
Yeah,
that's
right,
yeah!
That's
that's
right!
There
there's
another
project
that
is
about
to
endeavor
into
kind
of
distributed
performance
and
so
yeah
the
we
they're
like
we
were
talking
about
before
we're
kind
of
missing
a
schedule,
a
centralized
scheduler
if
you
will
and
something
to
kind
of
coordinate
and
orchestrate
the
test.
So
this
is
that's
a
another
venue,
another
use
case
and
and
that
one
in
some
respects
is
kind
of.
A
F
A
Let's
think
about
that,
for
an
imagehub
one
is
nice
and
lightweight.
It
is
at
the
moment,
there's
at
this
very
point
in
time,
there's
an
enhancement
that
needs
to
be
put
into
the
mesh
adapter
for
console
to
really
make
that
a
smooth
integration
like,
I
think,
that's
a
good,
a
good
app
in
general.
At
the
moment,
a
bit
broken
we'll
have
to
fix
that.
A
A
A
Yet,
and
so
this
would
be
a
good
there
could
be
some
hiccups,
I
hope
not,
but
the
reason
I
call
out
natish
and
a
couple
of
others
is
because
they're
looking
at
measuring
ctl
as
a
client
to
invoke
those
same
operations
like
you
know,
to
spin
up
a
service
mesh
to
deploy
a
sample
app
and-
and
we
haven't
gotten
there
yet,
but
had
we
have
already
been
on
the
other
side
of
that.
I
think
we
would
have
worked
through
potential
kinks.
F
A
I
guess
actually,
in
that
regard
considering
well
a
couple
things.
I
think
how
how
sexy
the
image
hub
is
sexy,
I
mostly
mean
in
terms
of
like
it,
hit
the
technology
that
it's
doing
kind
of
how
it's
teaching
people
some
new
things
and
how
lightweight
it
is
it,
even
though
it
might
be
the
right
place
to
start,
because
we
will
eventually
fix
the
issue
with
the
con.
The
measuring
adapter
for
console
and
because
to
your
point,
there
are
kubernetes,
manifests
for
laying
down
the
image,
laying
down,
console
and
laying
down
the
image
hub.
A
A
A
E
So
with
that
in
mind,
I
think
we
have
two
approaches.
One
is
kind
and
one
is
k3.
Yes,
so
k3
as
I
have
written
about
and
learning
about
that
this
is
a
cluster
that
built
for
production,
use
cases
so
k3s.
So
it's
have
a
small
and
a
very
lightweight
cluster,
so
you
can
test
it
out,
run
some
edge
devices
and
other
other
things
as
well.
E
So
I
think
if
the,
if
I
understand
the
flow
of
that
that's
the
subs,
some
I
confirm
instance,
or
some
kind
of
a
measuring
commands
as
we're
testing,
we
need
a
cluster
there
to
test
those
commands.
So
a
part
of
that,
I
think
we
need
these
two
options
either
go
for
the
k3s
or
for
the
kind.
For
my
knowledge,
I
think
k3s
is
a
very
lightweight
compared
to
the
client
cluster.
E
So
k3
has
an
option
for
the
production,
use
cases
and
also
the
kts
is
from
ranchers
lab,
so
they
have
a
production
in
which
you
have
a
persistent
persistent
volume
claim
there.
So
you
can
stateful
application
for
that.
So
I
think
most
of
the
people
are
going
for
the
k3s
because
of
their
lightweight
production
use
cases.
So
I
think
when
we
integrate
the
continuous
integration
testing,
that's
I've.
E
So
we
have
to
build
these
two
clusters
side
by
side,
either
go
with
a
kind
either
for
the
k3.
As
for
that,
so
I'm
not
pretty
sure
I'm
drawing
I'm
trying
out
some
diagram,
but
some
hindrance
there
for
me.
So
how
we
test
that?
How
do
we
test
measuring
in
particular
this?
What
we?
What
are
the
things
that
we're
going
to
test
so
in
that
place?
E
I
am
really
stuck
right
now
I
have
drawing
the
development
workflow,
but
I'm
going
to
the
continuous
integration
workflow,
I'm
just
missing
what
kind
of
things
that
we
are
testing
and
when,
with
this
testing
done,
we
have
to
go
back
to
other
productions
and
code
for
that.
So
these
two
recommendations
for
me.
I
think
we
should
to
check
it
out
k3s
as
well.
G
F
Yeah,
I
think
k3
is
also
pretty
popular
like
simon,
is
saying
and
there's
a
lot
of
production
usage.
The
k3
is
from
what
we've
seen
one
of
the
reasons
why
we
sort
of
devote
with
kind,
I
think,
maybe
it's
a
good
exercise
to
see
how
the
k3s
goes
as
well.
That
will
be
new
learning
for
us
as
well
kind,
I
think,
is
being
used
a
lot
in
ci
environments.
E
Adding
gothic's
flight-
I
think
one
thing
one
use
case
is
that
I
think
that's
excites,
that
when
we
go
for
the
client
cluster,
I
think
people
have
to
know
about
something
about
kubernetes
operations
work.
So
if
we
go
to
the
k3s,
the
many
of
the
people
are
talking
about.
They
doesn't
wondering
how
the
kubernetes
is
working,
so
k3s
is
working
on
top
of
kubernetes
and
they've
done
things
on
behalf
of
you
in
that
you
have
a
very
little
knowledge
of
kubernetes.
E
E
A
A
Our
highest
priority
within
the
and
that
is
a
hold
of
control
over
mercury's
releases
measuring
server
releases,
and
to
do
that,
we
were
saying
well,
mastery
server
needs
to
be
first
self-aware.
He
needs
to
be
cognizant
of
its
own
version,
so
that
yeah
and
so
leor
had
recently
like
with
this
last
week,
I
think
produced
a
updated
workflow
include
properties.yaml
file
system
of
the
mexi
container
image,
and
that
now
I
think
I
think
we're
ready
for
these
next
two
steps.
K
A
Yep,
the
primary
well
a
couple
of
reasons,
but
maybe
the
the
initial
reason
for
the
rest.
Api
to
expose
mesherie's
properties
is
so
that
a
client
like
measuring
ctl
when
it
runs.
When
you
run
message,
ctl
version
could
return
on
the
command
line,
the
version
of
measuring
ctl
as
a
binary
and
then
also
the
version
of
meschery
server
as
a
server,
so
to
basically
return
the
the
versions
of
the
client
and
server
and
the
way
that
measuring
ctl
interfaces
with
azure
server
is
through
rest.
And
so
I
mean
that's.
K
J
A
A
K
A
L
L
A
L
A
L
I
feel
like
a
top
level
version
command
is
more
intuitive.
Okay,
yeah,
just
based
on
other
clies,
where
everyone,
either
flags,
even
either
passes
the
dash
dash
version
or
just
the
version
command,
but
we
could
still
have
a
system
version
that
replicates
the
same
behavior
and
there's
there's
no
reason
why
we
couldn't
do
that.
A
A
L
Right
right,
yeah,
I
I
was
thinking
about
the
same
under
the
mesh
command
yeah.
I
guess
I
guess
that's
that's
that's
where
we
can.
We
can
have
the
version
under
each
of
these
parent
commands
and
we
have
the
regular
dash
dash
version
that
just
tells
you
from
a
messy
ctl
perspective.
What
the
client
and
server
version
are
exactly
like
cube
ctl
for
that
matter.
A
Nice,
okay,
yep
very
good,
makes
sense,
and
it's
probably
one
of
the
very
few
global
commands
that
actually
kind
of
constrains
itself
it
only
like
it's
possible.
I
don't
know
another
good
thought
here
is
well
assuming
that
we
have
measuring
ctl
mesh
version,
if,
assuming
that
we
already
had
that,
would
it
in
the
future
be
desired,
behavior
that
this
would
spit
out.
L
A
L
Yeah,
that's,
I
think,
that's
a
legit
thought
too,
rather
than
having
to
figure
out
what
the
subversion
commands
are.
You
just
have
one
top
level
that
it
gives
you
all
the
versions
yeah.
I
think
I
think
that's
a
better
experience
honestly
than
going
into
sub
commands
unless
we
were
doing
something
really
different
in
those
version
commands.
L
That
isn't
yeah
we
could,
we
could
break
it
down,
though,
like
we
could
have
a
instead
of
a
global
flag.
You
have
a
root
level
flag
and
then
you
have
sub
flags
within
sorry
flags
within
every
sub
command.
That
only
tells
you
about
the
version
for
that
that
command
like
if
you
say
system,
it
only
shows
you
the
client
and
server.
If
you
say
mesh
dash
dash
version,
it
shows
you
everything
about
the
mesh,
but
if
you
do
it
from
the
the
root
level,
it
shows
you
all.
The
information.