►
Description
Want to view more sessions and keep the conversations going? Join us for KubeCon + CloudNativeCon North America in Seattle, December 11 - 13, 2018 (http://bit.ly/KCCNCNA18) or in Shanghai, November 14-15 (http://bit.ly/kccncchina18).
Using kubectl to Run your End-to-End Tests - Amit Kumar Das & Uday Kiran, MayaData (Intermediate Skill Level)
End-to-end (e2e) tests are tasked to verify that a system with all its moving components (without mocks) can work together and satisfy the end user goals. Just as Kubernetes helps us with managing microservices based application containers, converting e2e tests into containers that can be versioned and orchestrated using Kubernetes helps us to test for functionality, performance benchmarking, upgrades and backward compatibility. Amit and Uday will demonstrate their e2e test containers for testing a storage infrastructure service added to Kubernetes that can be used on different platforms like GKE, OpenShift, etc., These e2e test containers can also be used by customers of the infrastructure service to augment their own CI/CD pipelines. The e2e tests have moved from being scripts to Kubernetes YAML files that are used by service providers and the customers.
"About Amit
Amit is a strong open source advocate and a firm believer of `taco bell programming` that helps him building simple & easy to use software. When he is not into programming, you will find him understanding the world from his daughter's perspective. Amit is the maintainer & core contributor to OpenEBS.
About Uday
Uday has been a Kubernetes user for almost 2 Years now. This will be his first talk at a KubeCon Event. Uday has been part of various Kubernetes and GoLang meetups. Uday also conducts Kubernetes trainings for interested users . Uday is an avid programmer and hacker, he is currently responsible for providing various strategies for managing CI/CD for his organization and has been actively involved in open source project OpenEBS.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! Learn more at https://kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
Join us for KubeCon + CloudNativeCon in San Diego November 18 - 21. Learn more at https://bit.ly/2XTN3ho. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
A
A
You
know
the
lessons
that
we
have
learned
and
what
we
are
currently
doing.
You
know
to
rectify
some
of
those
mistakes
that
we
did
in
our
journey
with
in
to
end
testing
and
the
solutioning.
We
have
actually
converted
that
solution
into
an
implementation
which
we
call
it
as
a
litmus.
It's
a
open
source
library
we'll
talk
more
about
it,
we'll
have
a
demo
to
that
as
well.
A
All
right,
so
a
little
bit
about
us,
I'm,
Amit,
I
work
for
a
company
called
my
data.
My
day,
job
includes
running
around
our
various
pieces
of
kubernetes
and
finding
out
you
know
the
areas
where
I
can
plug
in
storage,
and
even
the
reverse
is
true,
as
well.
I
run
around
storage
and
see
where
I
can
fit
in
kubernetes
pieces,
those
operators,
those
extensions
custom
resources
and
so
on,
and
so
here's,
my
colleague
what
entry
introduced.
A
So
so
he
is
oh
they
and
he
has
been
instrumental
in
getting
this
piece
of
library
built.
This
is
our
take
use
of
who
they
are
while
running
those
demo
a
bit
about
the
company,
my
data,
we
believe
in
simplifying
storage
and
so
a
theme
that
we,
that
is
very
common
across
that
the
teams
in
our
org,
is
moving
the
storage
to
background.
A
In
other
words,
let
the
operators
will
not
be
bothered
about
storage
and
continue
launching
the
apps
without
thinking
about
storage,
you
know-
and
we
believe,
containers
containers
socket
a
our
container
orchestrators,
for
example,
kubernetes,
to
be
instrumental
in
getting
this
vision,
and
so
we
have
been
into
containers
much
before
dock
avoids
popular.
We
were
tinkering
with
continues
when
now
in
the
freebsd.
You
know
where
they
are
known
as
jails.
A
Well,
that
was
a
past
life
and
in
the
current
you
know
day-to-day
activities.
We
are
using
docker
and
we
have
embraced
linux.
We
are
also
into
the
CN
CF
CSI
and
all
so
all
these
steps.
You
know
all
this
stuff
that
I
am
talking
about.
Are
you
know,
signee
the
new
ones,
the
more
exciting
ones
right,
but
with
all
these
excitements
we
need
to
be
careful
about
you
know:
do
we
don't
get
into
the
you
know
the
messiness
that
can
happen
in
the
user?
A
You
know
the
user
environments
in
the
production,
environments
and
and
well
we'll
go
with
this
context
into
e
to
e,
where
we
have
where
we
have
started
using
a
multitude
of
tools.
You
know
the
tools
might
have
been,
you
know
been
for
a
year
or
even
less
than
that,
and
we
we
are
just
jumping
on
his
opportunity
to
get
on
those
tools
and
try
out
you
know,
production
environments.
You
know
when
expecting
users
to
try
out
those
as
well
and
and
so
what
we
did
was
before
we
got
into
this
e
to
e
journey.
A
A
One
search
was,
you
know,
a
kubernetes
developer,
who's
Satyam
and
when
confronted
with
the
question
about
e
to
e,
he
are
just
listening
to
say
that
hey,
I
don't
need
to
bother
about
e
to
e
kubernetes.
Just
does
the
job
for
me.
I
just
need
to
prepare
the
yeah
Mel
and
just
apply
it
and
Bank.
It's
it's
done.
If
the
yeah
Mel
works
out
fine,
if
those
apps
gets
launched,
then
I'm
done.
Do
you
expect
anything
else
for
the
usually
to
work
right?
A
A
You
know
you
just
need
to
create
the
Yambol
and
just
apply
it,
and
you
are
done
perhaps
in
a
few
minutes
or
you
know,
and
finally,
at
the
end
of
the
day,
what
he
does
is
he
just
pushes
these
artifacts
into
some
repo
and
that
can
be
used
later
by
others
as
well,
which
is
you
know
good,
but
because
we
have
that.
You
know
thing
in
our
mind
that
this
may
not
be
the
exact
into
end
scenario,
which
a
customer
would
apply
or
a
customer
would
expect
in
their
environments.
A
We
go
to
the
next
stage,
or
rather
we
go
to
the
next
user.
Who
who
belongs
to
you,
know
the
QA
team
and
just
have
a
look
at
the
slide,
and
you
see
the
you
know,
the
tools
used
differ
drastically.
You
know
the
expectations
again
they
don't
match.
Earlier.
We
talked
about
the
kubernetes
developer.
Who
was
expecting
you
know
to
spend
a
few
of
his
minutes
and
get
this
things
done
here.
A
You
know
that,
ladies
for
now,
she
expects
the
test
phases
to
run
four
days,
perhaps
even
weeks
and
obviously
because
of
your
the
storage
company.
We
need
to
do
the
soak
testing
and
so
many
things,
and
then
you
know,
get
the
results
if
it's
a
pass
or
a
fail,
and
if
you
look
at
the
tools
here,
you
know
these
were
the
old
tools,
maybe
the
boring
stuff
that
we
talked
about
that
we
heard
about
yesterday
and
the
tools
that
we
talked
about
in
the
previous
slide
are
the
ones
which
are
exciting.
A
You
know
so,
but
when
we
actually
combine
all
this
to
stuff
in
our
org
and
we
saw
the
results
of
the
survey,
we
thought
that
all
right,
so
we
have
a
combination.
We
have
a
best
of
the
both
worlds.
We
have
the
exciting
stuff.
You
know
we
have
the
boring
stuff,
the
you
know
the
not
so
shiny
the
old
things,
and
similarly,
we
had
few
other
observations.
Where
I
mean
expectations
were
to
run
it
across
platforms
on
premised,
on
clouds
on
the
clouds
and
different
cloud
providers,
and
so
on.
A
Even
there
were
some
expectations
where
people
expected
into
e
to
provide
the
progress
done
in
a
given
sprint.
Holly
to
you
can't
give
that.
Why
not
right
so!
With
this
things
in
mind,
what
we
saw
is
the
org
is
we
we
felt
that
the
Ark
is
are
doing
good.
We
have
different
roles,
different
teams
who
are
contributing
in
their
own
ways,
and
we
felt
you
know
confident
that
yes,
this
feature
when
released
should
work
in
the
production
environment.
Customers
would
be
happy
right.
A
So
this
is
the
obvious
question:
did
it
work
and
we
were
so
confident
that
our
you
know
the
mix?
The
combination
of
boring
and
new
stuff
should
make
the
things
work.
Well
and
again,
the
priority
was
given
to
the
number
of
cases
that
passed
and
we
we
try
to
cover
up
all
the
kind
of
all
the
possible
cases
that
we
could
think
of
right
that
the
team
could
think
of
that.
The
teams
you
know
across
the
arc
could
think
of,
and
it
was
just
we're
looking
for
those
hundred
percent.
A
You
know
test
results
resulting
into
a
pass
right,
but
this
was
the
major
concern.
We
saw
that
even
if
we
had
done
our
job
well,
you
know
we
wrote
the
test
cases
we
got
it
running
across.
There
were
users
who
started
complaining,
saying
hey,
this
doesn't
work
and
we
had
experiences
where
the
feature
the
product
did
not
work
in
the
day.
One
itself,
you
know
it
felt
like
a
big
miss,
so
you
know,
then
what
do
we
do
now?
You
know
to
recover
from
this
kind
of
situations
right.
A
So
what
we
thought
then
was:
let's
not
just
include
our
own
team
members,
which
comes,
you
know,
developers
testers.
You
know,
product
management
and
all
the
stuff
can
we,
you
know
be
more
inclusive.
Can
we
include
the
users
along
our
journey
and
e
to
e?
Can
the
users
participate
and
what
does
it
mean?
Does
it
mean
we
expect
the
users
to
start
writing
scripts
and
all
those
stuff
start
learning
the
programming
languages?
A
A
Can
the
e
to
e
e
bring
in
more
transparency,
and-
and
this
is
a
very
vital
question-
I
mean
we
cannot
just
release
the
product
with
some
release,
notes
saying
we
have,
you
know
X
Y,
Z
feature
that
has
been
implemented
and
we
have
you
know
some
BCD
fix
that
has
been
fixed
in
this
particular
release.
Right
and
very
is
a
verification
that
it
has
been
done.
Do
we
say
that
hey
we
have
done
it
and
you
just
run
it
on
your
production
or
on
your
keyway
and
it
should
work
well.
A
Can
there
be
any
better
options?
Can
we
think
about
it
right
and
that
in
turn,
you
know
forced
us
to
think
more
about
end-users
right?
Can
they
participate
in
our?
You
know
end-to-end
journey,
and
similarly
can
we,
you
know
the
developers,
the
testers,
and
you
know
those
vendors.
Can
they
participate
in
the
end-to-end
in
the
users
you
know
end-to-end
stuff,
their
own
CI,
CD
right,
alright,
so
and
again,
like
I
said
it's
it's
not
about
like
coaching
the
users
to
do
something
they
are
not
meant
to
do.
A
We
we
don't
need
to
teach
users,
you
know
scripting
and
those
are
complex
stuff.
Rather
imagine
it
imagine
a
scenario
where
the
user
is
expert.
You
know
when
they
define
the
user
stories
they're.
The
ones
who
provide
the
user
stories
are
other
one.
Who
can
you
know
you?
Can
they
can
give
the
finer
details
in
the
user
stories
right
during
the
requirements
gathering
phase?
A
So
what
we
thought
is
instead,
if
you
can,
you
know
extent
you
can
if
we
can
move
one
step
ahead
and
get
those
user
stories
and
feed
it
to
the
e
to
E
and
E
to
E
just
understands
those
user
stories
and
in
converts
to
you
know
some
kind
of
commands
or
let's
say,
for
example,
kuben.
It
is
if
it's
a
Cuban
it
is.
The
user
stories
are
translated
to
kubernetes
commands,
for
example,
launching
a
deployment
deleting
a
deployment
and
whatnot
right.
A
So
wouldn't
it
be
great
and
and
and
what
we
do
is
this
is
what
we
get
alright.
So
so
here
we
have
now
come
to
the
you
know,
solutioning
part
where
we
are
talking
of
a
solution
which
you
know
accepts
a
feed.
A
feed
is
a
feature,
a
user
story
which
you
know
we
expect
the
end
user
to
be.
You
know
to
understand.
You
know
that
this
is
which
is
again
in
the
natives:
natives
specs.
It's
it's
not
any
any
any
programming
language,
it's
not
even
a
yeah
Mille,
which
you
know
some
of
us.
A
You
know
love
it,
but
but
then
many
of
us
don't
understand
it.
You
know
you.
You
need
to
have
the
IDs
and
whatnot
to
get
a
Yambol
done
correctly
and
and
coming
back
to
this
library
litmus.
So
what
it
does
it?
It
accepts
the
user
story.
The
user
stories
are
written
in
plain
English,
which
a
user
definitely
understand
and
in
turn,
each
of
these
steps
that
is
mentioned
in
the
users.
User
story
is
translated
into
a
kubernetes
command.
A
Right
and
again,
if
you
extend,
is
further
candies
entire
logic
of
translation,
be
packaged
as
a
binary
as
an
image
as
a
content
or
image
and
then
feed
it
to
the
kubernetes.
Using
you
know
some
kind
of
resources,
for
example,
jobs,
cron
jobs,
right
or
whatever
I'm.
In
the
scenario
that
particular
scenario
demands-
wouldn't
it
be
great
so
coming
going
back
to
our
earlier
talk
on
the
observation
on
when
you
release
a
release,
note
right,
we
say
we
have
an
ABC
feature
that
has
been
checked
in
or
that
has
been
implemented
in
this
particular
release.
A
And
again
there
has
been
some
fixes
that
has
gone
through
and,
along
with
that,
you
know
we
ship
in
those
channels.
You
know
those
job
constructs
right
and
say
hey.
These
are
the
constructs
that
actually
verifies
the
fixes.
That
verifies
the
features,
wouldn't
it
be
great
and
what
the
user
can
do,
the
the
user
can
take
in
those
features
and
apply,
or
you
know
you
can
apply
it
in
their.
You
know,
environments
meet
staging
or
bit
QA
or
our
beat
production
and
test
it.
You
know
they
get
the
sense.
A
They
get
the
the
tangible
stuff
that
yeah
it
is
working
or
it
is
not
working
right.
So
so
this
is
our
the
entire
motive.
Behind
these
you
know
the
use
of
taking
in
the
user
story
and
getting
it
to
run
in
the
end
users,
environment
and
we
believe,
are,
as
you
go
forward
end
users
will
be
able
to
participate
along
with
the
developers,
along
with
the
testers
frame,
the
user
stories
give
it
to
us
or,
and
let
somebody
from
the
development
or
from
the
testing
script
it
down.
A
You
know
get
it
translated
to
the
relevant
kubernetes
commands
and
make
it
work
package.
It
has
a
binary
as
a
container
and
a
frame,
the
ml,
you
know
job
or
a
cron
job
and
give
it
to
the
users
give
back
to
the
users.
This
is
like
yeah.
This
is
great,
and
this
is
what
we
have
been
doing
now.
Recently,
okay,
and
of
course,
so
how
do
we
do
it?
We
will
see
the
demo,
but
before
that,
it's
a
tool.
This
is
the
tool.
This
is
a
fantastic
tool
that
we
got.
A
This
is
go
dog
and
this
is
from
the
data
dog
community
right.
They
have
been
using
this.
You
know
it's.
The
features
that
we
saw
just
now
you
know,
is
a
family
or
is
an
extended
family
of
the
BDD
specs
behavior-driven
development
specs,
and
it's
nothing
you
it's
it's
been
there.
If
any
one
of
us
here
understands
koo
kumba
as
a
framework,
the
Gherkin
has
a
parser.
This
is
all
about
that.
What
go
dog
does?
Is
it
converts
those
user
stories?
Okay
into
go
commands,
it's
not
exactly
go
commands
rather
go
stubs
and
skeletons.
A
It
actually
generates
some
of
the
skeleton
code
which
maps
to
each
of
the
steps
that
is
present
each
of
the
English
statements
that
is
present
in
the
user
stories
right
and
the
next
thing
is,
you
know,
cue
cuddle,
look
you
control
the
CLI,
which
obviously
all
of
us
know
here
that
it
has.
It
understands
kubernetes
deeply
and
it's
not
just
a
CLI
right.
It's
pretty
loaded
right.
We
can
use
cue
cuddle
to
do
various
things.
You
can
use
yukl
to
do
patch
operations
to
do.
A
You
know,
put
operations,
we
can
deploy
containers,
we
can
deploy
applications,
we
can
scale
it
up,
so
it
goes
beyond
just
being
a
CLI
where
a
typical
CLI
is
used
to
you
know
view
the
state
of
a
system
right
and,
of
course,
obviously
you
cattle.
You
know
we
see
with
the
advent
of
customer
sources
with
a
with
a
way
the
kubernetes
is
providing
the
extensible
mechanisms.
It's
up
to
again.
It's
it's
back
to
cue.
Cuttle,
to
you
know,
provide
those
options
to
scale
up
those
custom
resources,
managers,
custom
resources
and,
and
so
on,
right.
A
So
we
what
we
did
here
is
we.
When
I
said
we
is
the
litmus
the
library
what
it
did
is
it
exposes.
You
know
the
go
dog
specs
at
one
end
right
at
the
other
end
right
it
has
those
two
links.
Those
libraries
looks
common
codes.
That's
typically,
if
you,
if
I
talk
in
a
layman
language,
it's
a
wrapper
of
a
cue
cuttle.
It
invokes
some
of
the
cubicle
commands
and
gets
the
job
done.
It
provides
a
mapping,
it
bridges,
you
know
both
the
worlds.
A
A
A
It
can
be
run
in
a
given
CI,
CD
environment
or
it
can
be
run
even
on
a
laptop
which
has
you
know,
let's
a
mini
cube
or
some
instance
of
kubernetes
running,
because
because
it's
packaged
as
a
binary
as
a
docker
image,
you
can
run
it
as
a
kubernetes
job
specs
right
and
here.
If
we
see
this,
this
is
the
feature
file
right.
It's
all
again.
It's
English
some
amounts
of
given.
When
then
statements,
that's
nothing
but
the
BDD.
A
A
I
have
a
kubernetes
cluster
I
have
some
operators
installed,
I
should
be
able
to
run
Mineo
right
and
it
should
be
up
and
running
in
some
small
of
time,
for
example,
180
seconds
right
and
and
obviously
there
are
some
other
aspects
like
it's
a
check
if
the
PVC
is
bound,
the
menial
on
the
one,
the
menu
has
a
claim,
the
persistent
claim,
if
it
is
bound
to
the
persistent
volume
and
so
on,
and
once
that
is
done,
we
also
want
to
check
I
also
want
to
check
as
an
end
user.
I
want
to
check.
A
If
the
menial
is,
you
know,
uninstalled
properly,
with
the
PV
getting
deleted,
with
a
PVC
getting
unbound,
even
the
PVC
getting
deleted.
This
is
a
I
mean
you
know
a
very
simple
stuff.
If
you
agree
with
me
that
there's
a
simple
stuff,
at
least
we
don't
introduce
any
any
of
these
technical
stuff
here,
we
expect,
we
believe
users
would
be
happy
to.
You
know,
contribute
to
this
user
story
and
we'll
see
just
now
how
to
get
it
run.
A
This
is
the
feature
and
if
you
see
there
is
a
corresponding
dot
go
file,
which
is
you
know,
mapping
of
this
particular
feature.
This
dot
go
file.
Intern,
impose
the
libraries
from
litmus
which
is
again
like
I,
said
it's
a
wrapper
of
a
cube
cuddle.
What
we
do
is
I'll,
go
ahead
and
start
running
this
command.
A
A
A
Alright,
so,
like
I
said
in
this
particular
scenario,
we
saw
that
a
job
would
suffice.
The
needs-
and
there
are
some
config
Maps
created,
which
is
a
which
is
the
you
know
the
job
of
litmus.
It
will
just
get
some
conflict
maps
which
is
mounted
into
the
particular
part
which
is
managed
by
the
job
right
and
when,
when
a
particular
step
comes
across
right
in
the
user
story
that
step
that
statement
comes
across,
it
will
select
those
particular
elements
right,
those
particular
config
maps
and
try
to
run
them.
A
Let's
see
alright
so
yeah,
so
what
do
we
see
here
is
there
is
a
feature
which
has
got
a
description
right
and
each
of
the
scenarios,
the
statements
and
the
scenarios
are
being
converted.
The
litmus
is
now
doing
the
job
of
converting
each
of
the
statements
into
a
corresponding.
It's
it's
translating
those
statements
into
corresponding
cube,
CTL
commands
right
and
it
has-
and
if
you
see
those
green
colors
yeah.
So
if
you
see
those
green
colors,
it
means
that
step
has
been
verified
successfully.
A
Okay,
and
if
you
see
there
is
some
amount
of
progress
being
done
here,
it
is
waiting
for
something
if
you
go
back.
This
is
waiting
for
this
particular
thing
to
happen,
180
seconds,
so
once
this
180
second
passes
it
will
35
the
min
app
if
the
mini
application
has
actually
been
run
successfully
or
not.
If
it's
in
a
running
State
right
and
it
will
do
the
other
verifications
as
well.
Alright,
so.
A
B
B
A
Alright,
so
this
is
that
underlying
stuff-
if
you
see
this
last
one,
this
is
where
the
mapping
is
being
done.
It's
it's
plane,
angle
code.
These
were
the
steps.
These
are
the
common
elements,
the
unique
steps,
the
unique
statements
that
we
saw
in
that
feature
file,
and
it
is
being
mapped
to
a
particular
method
here
right.
Those
methods.
Well,
although
all
these
things
are
defined
in
this
particular
dog,
go
file
which,
in
turn
or
invoke
common
those
common
methods
of
litmus.
Oh.
A
Okay,
so
what
I've
tried
to
do
is
I
have
tried
to
run.
Go
dog
against
that
particular
feature
and
I
have
purposefully
tried,
not
to
run
it
in
a
particular
path,
so
that
go
dog
is
not
able
to
find
those
stubs
that
I
get
that
get
I
mean.
That
is
that
it
is
expecting,
and
this
is
what
you
get.
If
you
run
go
dog,
okay,
go
dog,
say:
hey
I
am
able
to
find
out
this
particular
user
story
that
is
present
in
a
dot
feature
file
and
it
suggests
is
suggest
hey.
A
A
Okay,
all
right,
so
if
you
see
here
like
most
of
the
steps,
all
those
all
the
steps
are
verified,
wherever
it
was
required
to
wait
for
some
time,
it
waited
right
and
again,
this
is
a
specific
feature
of
go
dog
which
is
an
implementation
of
those
gherkin
passer.
What
littmus
does
is
it
uses,
go
dog
and
convert
those
you
know
those
it
tries
to
fill
up
those
stubs
into
corresponding
and
the
kubernetes
commands.
B
A
That's
where
there
has
been
some
amount
of
custom
coding
that
has
gone
into
the
litmus
where
I
just
try
to
I'm
just
trying
to
make
it
out
all
right.
So
these
are
the
some
of
these
config
maps
that
is
understood
by
litmus
only
currently
gives
a
config
mass,
but
we
feel
this
would
get
into
as
kind
of
a
custom
resource
where
we
can
actually
specify
the
behavior.
For
example,
it
tries
to
verify
the
operator
okay
for
in
this
particular
case,
this
is
an
open
abuse
operator.
Okay,
open
is
a
storage.
You
know,
I
promise.
A
You
know
where
it
says
it
is
X.
It
expects
it's.
A
kind
service
account
to
be
present
with
the
name
this
within
the
namespace
default
and
so
on,
like
it
expects
some
cluster
role
binding
and
so
on.
So
this
is
you
know.
This
is
a
list
where
one
can
go
ahead
and
fill
it
up
with
details
right,
and
this
will
go
ahead.
Our
during
the
course
of
run
during
the
course
of
that
front.
B
A
You
should
be
able
to
do
it,
so
there
are
two
ways
here
so
the
first
way.
This
is
like
one
of
the
ways
and
we
can
actually
specify
you
know
the
components
within
the
components
of
different
kinds
and
all
those
things
and
the
otherwise.
What
you
can
do
is
we
can
actually
try
to
code
in
there,
I
mean
if
it
is
something's
very
specific
to
lecture
ingress
or
whatever
you
said
with
the
exact
port.
We
can
actually
code
that
thing
there
right.
A
A
Yeah,
so
if
you
see
the
binary
that
gets
that
we
package
right,
it
has
a
go
dog
who
which
doesn't
have
Java
by
the
by
the
way
it's
the
go.
Implementation
go
dog,
is
actually
a
go
implementation
of
cumber
and
that
that
particular
image
has
cube
cuttle
the
cubital
binary
right
and
what
it
must
does
is
it
has
some
rappers
some
commands
over
cube,
cuttle.
It
uses
cube,
cuttle,
aziz
and
and
and
the
queue
cuttle
we.
What
we
do
is
when
we
have
that.
A
A
Right,
so
so
in
any
of
the
questions
and
again
so
this
litmus
is,
you
know
completely
open
source
as
a
batch
alliance.
Now
any
feedback
and
any
ways
to
contribute
I
mean
we
are
glad
to
have
that
we
can
actually
take
it
forward
and
we
we
have
a
booth
out
there.
Just
a
deposit
can
open
ABS
just
feel
free
to
talk
to
us.
Tell
about
your
ideas.
Tell
about
your
own
journeys.
If
you
have
like
no
better
than
this
kind
of
solutioning,
we
are
all
I
mean
you
know
a
bit
about
that.
A
A
B
A
Core
right
right,
great,
this
is
actually
a
great
question.
So
kubernetes
itself
has
an
e
to
e
framework,
which
is
based
on
ginkgo
and
and
G
Omega,
and
all
those
things
it's
not
that
we
have
not
tried.
We
have
tried
it,
but
we
found
it.
I
mean
you
know
little
bit
difficult
has
a
steep
learning
curve.
Instead,
we
we
try
to
make
use
of
the
existing
learning
that
we
had.
You
know
done
on
Q
cuttle
and
we
found
go
dog
to
be
easy
enough
for
us
to
get
started
that
that
was
a
main
idea.