►
From YouTube: Cloud-Native Chaos Engineering WG Weekly Sync Up - August 13 2021 | CNCF TAG App Delivery
Description
Check out the recording from the Cloud Native Chaos Engineering Working Group Weekly Sync Up from August 13th, 2021
For more information check out the WG Charter: https://docs.google.com/document/d/1scr9uuvG1g1xpIHPs3314FqeFufE31ustTVnRMrX3gI/edit?usp=sharing
A
Okay,
hi
calvin.
Welcome
to
the
chaos
engineering,
one
group
sync
up,
so
I
think
this
is
our
third
workgroup
sync
up
and
we
don't
have
too
many
participants.
Today.
I
have
a
brief
agenda:
an
update,
the
logistics
part
of
the
workgroup.
We
were
trying
to
obtain
a
dedicated
github
repository
within
cncf
and
also
provide
a
mailing
list
where
people
can
discuss.
A
A
A
All
right,
so,
in
the
last
time
we
were
trying
to
identify
the
procedure
to
request
for
this
service
discovery.
This
was
identified
as
the
approach,
and
now
we
have
got
a
repository
didn't
see
in
the
cf
to
place
all
our
artifacts
in.
It
is
not
populated
right
now,
but
I
will
be
making
this
change
shortly
with
the
charter.
The
meeting
notes
reference
to
the
survey
and
the
white
paper
is
also
the
glossary.
Video.
A
I
also
got
confirmation
that
we
can
publish
the
recordings
in
cncf
youtube
channel
in
a
dedicated
playlist
and
I'm
waiting
on
the
credentials.
So
we
will
probably
get
some
details
on
that
on
the
open
services
ticket
and
we
also
got
a
mailing
list
so
that
we
can
share
information
more
freely
and
have
more
discussions.
A
A
A
People
who
are
actual
practitioners
can
come
and
speak
about
their
experience
with
the
chaos
engineering
for
cloud
negative
applications
using
any
tone
of
their
choice,
and
then
we
could
use
some
of
their
learnings
and
place
some
of
their
perspectives
into
the
paper.
That
was
the
next
logical
activity.
We
were
going
to
do
user
presentations,
something
that
we
wanted
to
do,
and
I
have
actually
reached
out
to
a
couple
of
users
of
requests
who
are
willing
to
come
and
present.
I'm
sure
there
are
users
within
the
care
search
community.
A
Who
can
do
the
same
so
we
could
basically
have.
Let's
say
we
have
three
four
user
presentations
across
different
tools
or
people
who
might
be
using
other
tools
that
not
in
the
scenes
you
can
scale
as
well,
but
just
to
get
the
general
idea
of
how
they're
attacking
case
engineering
challenges
for
cloud
native
apps
and
use
that
information.
A
A
So
that's
something
we
can
set
up
for
the
next
call.
We
could
go
ahead
and
get
some
of
the
users
to
start
talking.
We
could
give
them,
let's
say
a
15
or
20
minutes
slot
either
to
do
a
demonstration
or
maybe
just
talk
through
of
what
they're
doing
and
sort
of
back
in
a
couple
of
presentations
in
each
of
those
calls.
I
would
assume
so
I
think
that's
an
action
item
that
we
can
take
respectively
for
both
of
us
and
invite
some
folks
to
come
and
present.
A
Apart
from
that,
we
wanted
to
go
ahead
and
select
an
application
upon
which
we
can
suggest
scenarios
just
to
maintain
consistency
and
have
a
coaching,
coherent
workflow
for
the
users
when
they
come
and
take
a
look
at
the
different
scenarios,
they
can
see
it
on
the
same
application
and
can
deliver
a
better
perspective.
The
journey
of
the
experiments
of
the
cares
engineering,
as
performed
on
one
application.
So
we
we
sort
of
zeroed
in
on
potato
head
as
the
application,
and
we
did.
A
We
didn't
go
ahead
and
commit
a
microservices
branch
there
to
make
it
a
microservices
application
and
lend
itself
better
to
chaos.
Engineering
scenarios
and
demonstrations
so
what
we
have
missing
there
are
a
stateful
component.
So
that's
something
that
we've
been
working
on
to
add.
We
will
shortly
add
that
into
the
repository.
That
is
something.
A
A
So
there
is
some
progress
on
the
potato
head
application
improvements.
I
will
send
that
information
over
on
this
mailing
list
when
we
we
are
able
to
make
some
more
tangible
progress
there
and
it
is
committed
onto
the
repository
and
the
next
agenda
item
was
to
talk
about
the
dictionary
or
the
glossary
that
we
have
for
chaos.
Engineering.
A
So
we
can
sort
of
advocate
it
within
the
community
and
share
this
around
there's
a
lot
of
case
engineering
material
on
the
internet,
but
this
is
a
consolidation
of
all
the
major
terminologies
and
philosophy
and
points
associated
with
it,
and
this
is
at
this
point
based
on
general
chaos,
engineering,
not
so
much
for
cloud
native
chaos
or
microservices
apps
about
general
chaos,
engineering,
and
we
have
not
followed
an
alphabetical
order.
As
you
can
see,
it
is
more
about.
A
It
is
following
a
flow
that
you
would
most
associate
with
a
chaos
engineering
practitioner
as
he
embarks
on
his
journey.
So
what
is
chaos
engineering
in
one
of
his
principles
and
what
is
meant
by
an
experiment,
how
you
define
blast
radius
and
what
is
meant
by
steady
state?
How
do
you
formulate
hypothesis,
and
how
do
you
look
at
observability
infrastructures,
make
a
part
of
experiments?
A
What
is
the
role
generally
associated
with
chaos?
Engineering?
How
do
you
want
to
carry
out
experiments?
What
is
the
setting
in
which
it
is
done?
What
are
the
kpis
associated
with
chaos,
engineering
and
what
is
the
general?
You
know
final
metric
that
people
would
take
a
look
at
as
the
as
the
takeaway
of
all
the
work
that
someone
did
with
chaos
engineering.
A
B
This
is
really
this
is
really
great
document
and
a
great
progress
that
you
met
and,
and
I'm
sorry
I
think
this
kind
of
slipped
my
mind
for
some
time.
So
how
how
could
we,
you
know,
I
think
we
for
all
projects
involved
in
chelsea,
engineering
and
cncf.
We
should
all
you
know,
participate
and
contribute
to
the
document
and-
and
obviously
you
you
guys-
have
already
made
a
very,
very
amazing
progress
on
it.
So
how?
How
could
we,
you
know,
go
moving
forward
from
now
and
how
can
we
contribute
to
it?
A
Yeah,
I
think
we
could
do
it
multiple
ways.
One
way
like
like
I
mentioned
is:
we
can
probably
start
filling
up
sections
in
the
white
paper
that
we
sort
of
agreed
initially
on
the
areas
that
you
would
like
to
fill.
For
example,
we
basically
talked
about
in
the
last
meeting.
We
talked
about
the
sections
of
the
white
paper,
which
we
can
sort
of
go
ahead
and
fill
based
on
our
application
with
the
tags.
B
A
B
B
A
Here
it's
also
linked
on
the
meeting
notes.
Yeah.
It
has
some
questions
which
you
might
have
already
taken
a
look
at,
so
we
can
probably
extend
the
problem
statements
and
take
a
look
at
what
is
you
know
the
expected
outcomes
and
goals,
and
if
there's
something
that
you
would
like
to
add
coming
in
from
the
sick
network,
the
tag
network.
That
would
also
be
great
if
you
can
talk
about
some
scenarios
or
some
sections
in
the
white
paper
that
correspond
to
common
incidents
around
networking
chaos,
that's
something
that
would
be
great.
B
For
the
dictionary,
do
you
think
it's
necessary
to
you
know,
add
sections
for
for
project
specific.
You
know
technologies
like,
for
example,
some
items
are
specific
to
to
a
little
skill.
Some
and
some
are
specific
to
like
chaos
match,
but
it's
not
like
common
ones.
I
think
the
current
currently
listed
a
common
terminologies
right
that
could
be
applied
to
all
projects
or
close
engineering
projects.
B
A
I
think
that
the
white
paper
is
going
to
contain
a
section
above
the
various
tools
in
the
landscape,
and
I
see
that
being
a
common
trend
in
different
other
white
papers,
where
there
are
some
sections
dedicated
to
letting
the
users
know
about
the
available
tools
in
the
landscape
and
how
they
operate.
A
brief
summarization
like
like
we
discussed
earlier
so
in
that
section.
A
I
think
we
could
link
a
project
specific
glossary
where-
and
there
are
some
terminologies
that
are
native
to
that
project
and
people
would
get
a
better
idea
of
okay
when
I'm
navigating
this
project
or
starting
to
use
this
particular
tool.
These
are
the
items
or
terms.
I
should
be
aware
of
to
proceed,
so
I
think
it
makes
a
lot
of
sense
to
create
a
specific
glossary.
A
B
A
B
A
B
I
think
I
have
on
top
of
my
head.
I
have
like
something:
firstly,
they
need
to
like
introduce
their
their
business
or
company,
and
then
they
introduce
their
scenarios.
All
the
pain
points
there
of
the
scenarios
for
because
and
for
testing
then-
and
I
they
just
you,
know
the
key.
The
focus
is
on
how
they
solve
their
testing
pinpoints
with
is
chaos
engineering,
especially
for
cloud
native
class
engineering.
B
B
B
A
Yes,
we
have
about,
I
think
the
workbook
sort
of
can
be
extended
and
operate
for
as
long
as
it
is.
But
since
there
is
a
general
goal
towards
completing
the
white
paper
before
the
group
con
and
we
are
going
to
be
making
use
of
the
user
insights
to
be
placed
inside
the
white
paper,
I
would
assume
that
before
august
12th,
let's
say
this
begins,
and
you
would
keep
a
couple
of
weeks
aside
for
actually
I
trading
on
the
white
paper
and
sort
of
reviewing
it
finally
etc.
A
A
Let's
say
we
have
about
40
minutes
dedicated
for
user
presentations
and
we
could
try
and
back
in
one
or
two
presentations
in
each
of
the
subsequent
calls.
If
at
all,
we
have
the
agenda.
Of
course,
it's
it's
subject
to
folks
coming
forward
to
present
it
and
having
the
time
to
do
it,
but
that
would
sort
of
leave
us
to
you
know
have
some
20
minutes
per
presentation.
Do
you
think
that
is
a
fair
amount
of
time
to
capture
this
info.