►
Description
What's the difference between Keptn and the Keptn LifeCycle Toolkit?
In the last Keptn community meeting, we discussed the differences and similarities between the two tools to help you decide which is best for your individual case.
Meeting notes: https://docs.google.com/document/d/1y7a6uaN8fwFJ7IRnvtxSfgz-OGFq6u7bKN6F7NDxKPg/edit
Learn more: https://keptn.sh
Get started with tutorials: https://tutorials.keptn.sh
Join us in Slack: https://slack.keptn.sh
Star us on Github: https://github.com/keptn/keptn
Follow us on Twitter: https://twitter.com/keptnProject
Sign up to our newsletter: https://bit.ly/KeptnNews
A
A
We
have
a
project
where
you
could
follow
what
we
have
planned
for
our
roadmap
and
right
now
for
version
5.
We
want
to
consolidate
the
examples
and
bootstrap
the
documentation
of
the
lifecycle
toolkit,
which
is
lessaco.captain.sh
here.
You
could
see
the
new
documentation
for
the
recycle
toolkit.
It's
still
work
in
progress.
So
if
you
want
to
try
out
the
lifecycle
toolkit-
and
you
see
that
some
parts
are
missing-
you're
welcome
to
propose
a
PR
to
support
us
in
documenting
the
different
things.
C
A
B
C
B
C
Perfect,
so
one
of
the
things
that
that
I
want
to
highlight-
and
we
all
have
seen
this
thread-
we
at
kubecon
when
we
were
all
on
stage
and
kind
of
all
when
we
were
presenting
Captain
Beyond
1-0
sailing
into
the
future
I-
think
it
was
a
good
presentation
on
showing
where
we
are
and
where
we
had
to,
but
it
also
caused
a
couple
of
people
to
say.
What's
what's
really
going
on
now,
right
and
I
just
highlighted
two
of
the
conversations
we
had
on
slack.
C
We
had
many
more
but
I
highlighted
these
together,
then
Daniel
right,
geralt
felt
like
Captain
life
cycle
toolkit
loses
the
multi-stage
delivery
aspect.
Why
can't
I
use
Captain
for
what
I
want
Dev
Stage
production
and
Danielle
similar,
like
some
confusion
on?
Does
this
mean
Captain,
one
always
there
that
we're
deprecating
it
what's
happening
and
they
were
looking.
We
had
long
discussions
with
Daniel
and
his
team.
C
Daniel
is
working
for
a
large
Bank
in
in
Europe
and
they
are
currently
really
investing
a
lot
into.
What's
the
next
big
thing
for
my
continuous
delivery
perspective
and
they're
really
so
kept
in
this
kind
of,
as
he
says
here,
the
umbrella
that
can
give
full
State
and
visibility
into
continuous
delivery
from
first
commit
to
to
production,
and,
as
you
can
see,
it
was
also
a
little
bit
sad
if
his
assumption
were
correct.
C
So
what
I
pointed
here
on
the
bottom
is
Dev
staging
prod.
What
many
people
are
asking,
and
especially
those
that
are
going
full
kit,
Ops,
meaning
you're,
using
Argo
using
flux
or
whatever?
It
is
right.
You
start
with
the
kit
commit
that
deploys
into
into
Dev,
and
then
their
deal
with
Captain
life
cycle
toolkit
is
that
through
the
pre
and
post
deployment
tasks,
you
can
actually
achieve
exactly
what
you
want.
That
means
you
can
do
your
functionality
checks
by
executing
some
functional
tests.
C
You
can
do
dependency
checks,
that's
basically
what
also
Thomas
showed
in
his
cubecon
talk.
You
can
do
performance
validations
because
we
do
provide
the
ability
to
meditate
metrics
against
Prometheus
or
dynatrace
or
any
other
data
source,
because
we
have
the
the
evaluation
task.
The
great
thing
about
this
is
we
are
pushing,
then
the
results
of
this
through
open
Telemetry
and
some
metrics
two.
C
You
know
your
visibility
tool
or
your
obso
ability
tool
of
choice,
and
this
means
it
doesn't
stop
here,
because
one
of
the
things
we
can
do
as
part
of
the
kind
of
post
deployment
task
is.
We
can
also
think
of
promoting
that
change
into
the
next
stage
by
creating
a
pull
request.
Now
this
is
not
implemented
yet,
but
with
the
task,
it's
all
possible.
I,
don't
know
Giovanni
correct
if
I'm
wrong.
C
And
if
you,
if
you
follow
this
model
right,
it's
the
same
thing
in
every
stage
we
can
promote
the
change.
We
can
use
our
tasks
to
actually
really
do
the
multi-stage
delivery,
but
the
big
benefit-
and
this
is
what
all
everybody
everybody
said.
You
want
to
have
an
end-to-end
visibility
across
all
stages
and
what
we
achieve
with
the
lifecycle
toolkit
by
using
Open
observability
Standards
like
open
Telemetry.
C
We
give
you
through
a
trace
and
end-to-end
View
From
First
commit
all
the
way
to
production,
one
of
the
things
that
I
didn't
put
in
here,
but
I
should
probably
we
also
thought
about.
How
can
we
start
already
a
trace,
maybe
with
the
first
initial
kit
commit?
That
means
the
trace
could
start
even
earlier,
and
then
captain
could
take
over
at
open
Telemetry
a
span
ID
and
then
really
do
an
end-to-end
full
end-to-end
trace.
C
C
Think
we
solved
this
problem,
which
means
you
can
actually
look
at
all
of
the
data
in
your
tool
of
choice,
whether
this
is
grafana
Diana,
Trace,
honeycomb
data
dog
or
whatever,
whatever
it
is
so
I
think
this
I
try
to
illustrate
in
discussions
with
these
people
that
that
had
questions
on
on
what
what
can
be
done
with
the
lifecycle
toolkit.
One
other
thing
that
I
didn't
mention
I
think
it
was
Danielle
and
also
geralt.
He
said
Hey
in
Captain,
10
I,
really
like
the
separation
of
concerns
between
processing,
processing
processes
and
tooling.
C
But
now
you
force
me
to
put
the
process
into
my
deployment
definitions
as
pre
and
post
deployment
tasks,
but
this
is
also
not
in
conversations.
We
then
figured
out
further.
First
of
all,
when
you
define
tasks
as
pre-employment
deployment,
test,
you're
referencing
it
by
name
and
you
still,
the
task
itself
is
deployed
separately.
That
means
you
have
a
separation
of
concern.
What
is
the
task
that
say
notified
really
doing,
plus
with
our
application
definitions?
C
You
can
really
separately
of
your
deployments
control
what
should
happen
in
the
app
context
and
I
think
especially
the
last
conversation
we
had
with
Daniel
and
his
team
that
bank
they
really
said.
Okay,
this.
This
makes
a
lot
of
sense
and
really,
if
everything
works,
as
as
we
discussed,
it
could
really
solve
their
problem
of
getting
end-to-end,
multi-stage
visibility
to
promotion
and
the
separation
of
concerns.
A
C
I've
learned
I
think
what
we've
learned
in
the
discussion,
Chobani
I,
want
to
just
quickly
actively
bring
you
in
I
I.
Think
that
pretty
much
everything
that
is
on
here,
you
know
at
least
Works
in
theory,
also
practically
the
only
thing
that
practically
I
guess
doesn't
work
yet
is
the
promotion,
even
though
we
can
probably
implement
it
yeah
exactly.
A
C
A
C
Great
and
just
to
let
you
know
what
the
next
steps
in
the
discussions
we
had
and
I
have
to
come
back
to
Daniel
and
his
team,
because
we
had
I
think
three
three
of
his
team
members
on
the
call
with
Thomas
and
myself.
They
are
going
to
now
look
into
this
and
in
early
January,
once
Europe
is
back
from
the
holidays.
Also
Thomas
will
work
directly
with
them
and
really
try
to
get
this
implemented
and
I
know
then
also
see
where,
where
are
things
still
missing?
So
there's
close
collaboration
on
this.
C
So
this
is
kind
of
like
what
I've,
what
we've
learned
from
these
discussions.
Now
another
thing
is
and
again
I'm
not.
Fortunately,
I
was
never
hired
as
a
web
designer,
but
this
is
kind
of
like
what
the
next
thing
kind
of
my
idea
on
how
we
can
maybe
redesign
the
website-
and
maybe
the
first
thing
on
on
on
on
on
the
GitHub
page,
because
people
are
asking.
C
So
what
is
the
right
Captain
for
me
and
the
way
I
Envision
it
and
would
like
to
get
feedback
is
first
of
all,
we
need
to
explain
what
kept
on
the
project
is
really
all
about.
The
project
is
about
providing
observability
into
your
deployments,
enforcing
checks,
pre
and
post
deployment,
validating
that
your
deployments
are
healthy
through
slos
and
orchestrate
whatever
else
other
tools
you
have.
C
The
lifecycle
toolkit,
however,
really
only
makes
sense
if
you
are
fully
Cloud
native
and
you're
fully
committed
to
kidops,
because
this
is
where
the
lifecycle
toolkit
shines,
if
you're
using
Argo,
if
you're
using
flux
or
any
other
tool
that
provides
a
github's
model
in
kubernetes,
then
the
lifecycle
toolkit
gives
you
automated
pre
and
post
deployment
checks
and
then
exposes
all
the
data
through
open,
telemetry,
that's
kind
of
my
hey.
You
already
are
using
Argo.
You
already
have
your
own.
C
You
have
an
obserability
platform
as
well
that
can
consume
open
telemetry
10
lifecycle
toolkit
is
a
great
start
option.
Two
would
then
be
if
you're
not
kiddops
right
if
you're
not
fully
kiddos,
because,
as
we
know,
we
tried
with
Captain
B1
to
to
kind
of
add
githubs
to
Captain,
but
it
was
never
centered
around
get
UPS,
but
there's
a
lot
of
users
out
there
that
are
in
that
stage
where
they
just
need.
C
You
know
Captain
with
customizable
sequences,
as
we
call
them
to
automate
and
orchestrate
a
couple
of
tasks
either
around
delivery
or
remediation.
This
is
where
Captain
B1
is
perfect
for
and
then
there
was
also
questions.
Can
we
combine
the
two
you
can
you
can
use
the
lifecycle
toolkit
if
you're
fully
get
ups
and
then,
if
you
really
like
some
of
the
flexibility
that
Kevin
V1
gives
you
with
customizable
sequences?
If
you
like
this
approach
better
or
whatever
other
reason
you
have,
then
we
can
also
and
again
to
run
it.
A
C
Nobody
ever
hired
me
to
become
a
web
designer
because
it
looks
ugly,
but
what
I
did
is
because
I
always
asked
me,
because
this
has
to
be
also
discussed.
I,
think
in
the
in
the
governance
board,
I
created
a
git
issue
for
that
and
very
happy
to
get
feedback
and
I
think
this
feedback
will
then
also
help
I'll
post
the
link
in
with
my
chat
window.
So
this
is
the
kit
issue
that
I
created
on
the
captain
website
repo
exactly
with
it
and
then
you
know
provide
feedback.
C
This
will
help
the
governance,
but
also
to
make
a
decision,
and
then
whoever
then
needs
to
implement
this
all
right
to
then
come
to
kind
of
like
what
is
still
open
and
I
think
Joanna.
This
is
where
I
would
like
to
I
guess,
bring
you
with,
and
everybody
else
more
written
wherever
else
is
on
the
on
the
call
now
you
can
to
to
can
chime
in
with
some
answers.
A
A
C
To
you
know
Giovanni:
are
there
any
key
capabilities
or
features
that
people
have
asked
for
that?
We
that
you
think
would
be
great
to
have,
but
currently
we
don't,
we
don't
have
it
on
our
radar,
and
maybe
we
want
to
ask
somebody
for
support
and
also
right.
We
want
to
grow
the
community.
We
want
to
get
more
contributors.
A
For
Captain
B1
how
to
be
honest,
that
we
don't
have
many
good
first
issues,
but
it's
something
that
we
are
planning
to
look
into,
especially
for
me.
During
this
winter
holidays,
I
will
cover
the
repository
Mark
as
many
tickets
as
possible,
with
good
first
issues
to
support
the
community
to
get
into
easy
tasks
that
can
contribute
to.
A
C
I
also
I
agree
I,
think
cap
V1
is
really
now
in
a
state
where
the
people
at
least
that
I
know
right.
This
is
the
the
people
that
we
interact
with
in
the
community.
We
also
have
a
lot
of
dinosaurs
customers
today,
using
Captain
weave
on
and
for
the
use
cases
that
they
use
it.
It's
mainly
about
the
SLO
evaluation
and
then
a
lot
of
them
are
also
combining
it
with
executing
tests,
and
most
of
them
are
executed
through
the
the
job,
executor
and
I.
C
A
The
idea
is
eventually
to
enhance,
there's
a
lot
of
supports,
because
Captain
V1
I
guess
as
one
of
the
best
SLO
implementation,
that
you
can
do.
Multiple
things
like
scoring
put
weights
on
different
solo
evaluations
that
currently
are
not
supporting
the
lifecycle.
Toolkit
and
idea
is
to
improve
on
this
side
as
well.
A
C
That
yeah,
yeah,
exactly
and
and
I
think
this
would
then
also
kind
of
could
could
be
a
good
way
to
discuss.
The
next
question.
Any
status
on
open,
SLO
support
right
because
open
SLO
is
a
community
that
we
have
engaged
with
over
the
last
year
since
they
started,
but
we've
at
least
with
Captain.
We
won.
We.
We
had
a
different
vision
and
approach
to
slos
because
we
were
using
slos
not
for
like
production,
monitoring
and
error
budgets
and
everything,
but
we
were
using
them
for
Quality
gating.
A
Yeah
I
think
going
forward.
We
are
much
closer
now
to
open
slows
than
we
were
before
because
they
were
using
or
they
are
specified
fixed
similarly
to
a
custom
resource
which
would
be
perfect
for
our
use
case
in
the
lifecycle
toolkit.
So
the
idea
is
to,
of
course,
involved
or
try
to
get
into
the
community,
but
since
we
have
this
General
way
of
having
different
providers
for
evaluating
your
slos,
maybe
we
can
have
also
an
hot
dog
provider
that
supports
exactly
open
SLO
specifications.
C
I
actually,
now
think
of
it,
I
think
open
SLO.
If
I'm
not
mistaken,
they
have
a
reference
implementation
that
they
called
Oslo
and
I
think
there's
actually
a
command
line
tool
and
if
I'm
and
again,
if
I
guess
I
haven't
looked
at
closer
to
it.
But
this
could
be
an
interesting
way
to
say
you
can
just
execute
all
slow
as
part
of
a
of
a
post-deployment
task.
C
A
But
also
we
have
him
plan.
You
might
have
seen
the
Epic
that
you
created
to
also
enhance
a
bit
the
SLI
part
of
Captain
lifecycle
toolkit.
The
idea
is
to
provide
a
generic
metric
server
for
kubernetes,
so
you
can
fetch
your
data
from
your
accessibility
platform
and
we
speak
the
complete
this
language,
so
other
integration
of
communities
can
make
use
of
that.
So
you
can
use
Captain
lifecycle
toolkit
also
as
a
source
for
metrics
that
you
can
use
afterwards
for
your
HPA,
so
horizontal
Port,
Auto
scalar
for.
B
C
So
I
think
I
said
to
to
kind
of
wrap.
Maybe
this
topic
up
foreign
we
should
have
some
discussions
and
I
think
a
good
first
issue
would
be
to
look
into
calling
any
type
of
open,
SLO
implementation
from
Captain.
That
would
be
good
and
then
I
really
like
the
the
kubernetes
metric
server,
because
this
opens
up
the
data
that
we
fetch
to
other
use
cases
to
the
native
to
kubernetes.
B
The
reason
we
had
so
many
a
few
months
ago
was
that
they'd
been
done
in
11.
Some
of
them
were
done
in
eight
release,
eight
or
zero
point,
eight,
seven,
zero
point.
Eleven
they
hadn't
been
updated.
Tutorials
are
extremely
resource,
intensive
to
create
and
maintain,
and
the
ones
that
we
had
were
so
far
behind
that
we
now
have
one
good
one
that
gets
people
started
and
then-
and
anybody
who
wants
to
step
up
what
we
are
asking.
B
B
What
I
found
out
was
that
people
were
using
the
tutorial.
The
tutorials
were
supposed
to
just
give
you
a
light,
look
at
what
Captain
could
do
and
people
were
trying
to
set
up
their
production
environments
using
those
instructions
and
then
running
into
problems,
and
this
is
really
not
what
they
should
be
doing.
Anyhow,
so
we've
been
concentrating
more
on
getting
the
documentation
up
to
Snuff
to
actually
go
through
that
you
have
to
do
this,
and
you
have
to
do
this,
and
if
you
want
this,
you
need
to
do
this
at
this
stage.
B
My
sense
is
that
what
if
we
did
have
more
new
to,
if
we
had
more
tutorials,
we
need
more
on
Advanced
ones
like,
for
instance,
I'd
like
to
have
a
really
good
tutorial
up
there
on
creating
good,
slis
and
slos
working
with
your
some
more
advanced
topics
we
had
was
like
10,
different
versions
of
how
you
get
started
with
Captain,
which
seemed
redundant.
So
so
that's
the
answer
there
and.
B
C
Awesome
so
I
think
that
if
I
hit
us
correctly,
it's
better
to
have
one
good
tutorial
to
show
people
how
to
get
started
with
Captain
V1.
If
we
need
more
people
want
more
tutorials,
we
need
people
to
step
up
to
make
sure
that
these
tutorials
also
stay
maintained,
because
otherwise
we
end
up
with
20
tutorials
and
18
of
them
are
outdated
all
the
time.
Yes,.
B
Exactly
and
they
aren't
the
tutorial,
you
know,
the
point
of
the
tutorial
is
see
how
easy
this
is,
which
is
a
good
way
to
get
started.
When
you
get
into
really
setting
things
up,
you
should
be
looking
at
real
documentation
that
tells
you
watch
out
for
this,
and
at
this
stage
you
know
run
this
to
verify
that
you're,
okay,
Etc,
and
that
is
we
are
putting
more
and
more
of
that
into
the
documentation.
We
still
have
work
to
do
but
and
love
to
have
feedback
from
anybody
too.
C
Awesome
then,
moving
on
to
the
next
one.
This
is
very
specific
to
the
the
captain
community
that
are
also
using
Dyna
Trace,
because
we
we
have
a
lot
of
people.
Obviously
that
are
using
Diamond
trees
and
many
of
them
are
asking.
Can
we
have
just
a
lighthouse
feature
kind
of
like
I,
say
Standalone
version,
because
they
don't
necessarily
need
full-fledged
Captain,
but
really
just
like
that
capability,
Jovan
I
think
there
is
at
least
late
on
this.
Yes,.
A
I
was
speaking
with
York,
the
maintainer
of
the
directory
service
the
other
day,
and
we
were
thinking
to
create.
Maybe
a
CLI
so
do
kind
of
a
hackathon
together
to
have
a
proof
of
concept
of
a
standalone
Lighthouse
than
a
trace
integration
to
see
how
it
can
work-
and
this
also
solves
many
use
cases
such
as
running
a
quality
K
directly
into
your
Jenkins
pipeline.
Since
you
have
everything
in
acli.
C
Yeah
exactly-
and
that
means
you
can
just
call
the
CLI
natively
on
your
let's
say:
Jenkins
agent
or
package
it
in
a
container
I
guess
and
then
run
it
even
as
a
GitHub
action
very
easily
without
gender
dependency
and
without
needing
the
full-fledged
kit.
Now
that's
awesome
yeah.
It
would
be
keep
us
posted
on
this
I
think
this
would
would
this
become
attend
a
sub
project
on
I,
guess,
GitHub.
A
C
C
Last
question:
can
I
combine
klt
with
Captain
V1
I?
Think
we
had.
We
mentioned
this
earlier
in
my
overview
slide,
that's
clearly
possible,
but
I
think
it
only
makes
sense
if
you're,
if
you're
core
approach
is,
is
githubs
and
you're
deploying
everything
already,
because
this
is
where
the
klt
makes
most
sense,
and
then
you
can
from
their
trigger
okay,
move
on
sequences,
for
instance,
if
you
really
need
sequences
and
you
want
the
visualization,
the
bridge
yeah.
C
Awesome
so
I
think
this
is
this.
This
was
it
from
me.
I
I
hope
that
it
answers
a
couple
of
the
questions
and
gives
some
clarity
on
what
people
have
struggled
with
and
especially,
if
I
go
back
to
to
this
year
and
I
think
this
is
a.
This
is
what's
possible
with
with
the
lifecycle
toolkit,
but
the
lifecycle
toolkit
is
not
for
everyone,
but
it's
for
those
that
are
moving,
two
kubernetes
that
are
doing
githubs
and
that
have
a
way
and
are
com.
C
A
Okay,
so
from
the
last
point
of
the
agenda,
is
Community
team.
Please
help
us
it's
a
call
for
Action
from
to
from
me
to
the
community.
In
the
next
days.
I
will
try
to
look
into
good
first
issues
that
you
can
work
on,
and
one
cool
thing
especially
would
be
to
support
us
on
the
documentation
side.
Since
the
lifecycle
toolkit
is
very
new,
we
don't
have
a
very
good
documentation
in
place.
A
A
PR
to
fix
that
would
be
very
good,
but
also
I
will
try
to
create
new
issues
that
should
help
you
to
get
into
the
project,
so
you
can
then
contribute
more
and
more
and
then,
hopefully,
one
day
become
also
a
maintainer
of
the
captain
V1
or
the
lifecycle
toolkit
in
particular,
for
the
lifecycle
toolkit
I
would
like
to
have
from
the
community
more
contribution
to
what's
different
obserability
providers.
At
the
moment
we
support
Prometheus
and
dynatories,
and
this
code
to
support
a
number
cerability
platform.
B
A
B
D
No,
no
problem,
no
problem.
Okay.
First
of
all,
thank
you.
I
really
appreciate
your
help
in
the
slack
Community
I.
There
are
a
lot
of
things.
I
learned
from
you
guys
and
I
think
that
this
new
this
this
Captain
toolkit
I,
think
for
for
you,
our
user
use
case
is
good
because,
as
you
say,
we
want
a
github's
approach,
so
approach.
So
thank
you
for
for
that
roadmap.
D
The
problem
we
have
right
now
or
I
am
I
have
is
maybe
I
don't
know
if
I
I
am
doing
something
bad.
Is
that
the
task?
The
task,
for
example,
first
of
all,
I
I
I,
use
the
pre-evaluation
and
it's
worked
great
with
Prometheus
and
then
I
want
to
use
some
pre-deployment?
No,
no,
yes,
pre-deployment
task
evaluation,
for
example,
I'm,
using
your
your
example
that
you
have
the
check
the
end
point
and
in
the
of
the
service
I,
don't
know
why?
D
C
I've
I
think
I've
responded
to
one
of
your
things
with
because
in
the
example,
the
test
that
Thomas
specified
is
referenced
from
a
file
on
GitHub
and
I'm,
just
wondering
if
you
were
set
up,
and
especially
your
istio,
if
you
egress,
is
actually
allowing
outbound
connections
to
that.
Because
if
you
look
at
the
task
definition
where
you
can,
you
can
specify
tasks
either
with
inline
code,
where
the
code
sits
within
your
Cod
or
you
can
reference
an
external
resource
and
if
it's
external
it
will,
it
needs
to
be
downloaded.
C
D
Yes,
yes,
I
have
I,
am
allowed
and
I,
don't
know
why
it
stays
in
not
really
in
the
downloading
stage,
because
I
made
another
a
test.
I
only
use
the
console
log
for
only
to
say,
okay,
this
is
this
stage
and
it's
the
door
will
stay
in
in
not
really
yeah
I'm,
not
really
State
I,
don't
know.
If
okay
I
will
better
send
you
in
the
in
the
slack.
What
I
did
what
I
did
because
right
now,
I'm
sorry
but
I
cannot
show
you
my
closer
because,
like.
B
D
C
D
I'm
using
the
last
well
I
think
that's
the
from
your
privacy.
That's
the
the
version
that
we
have
to
use.
Another
question,
I
have
and
and
well
I
think
that
you
mentioned
it.
It
was
for
the
for
the
task
that
we
can
use
a
script
into
a
scripted
language
like
python.
You
say
something
like
that
right.
We.
D
Yeah,
because
they
because
we
in
the
past,
you
skip
them
and
we
had
the
approach
with
with
the
job
executor,
because
that
that
tool
made
made
us
a
lot
of
things
good
for
us,
so
right
now
only
for
type
scripting.
Okay,
another
question
is
is
regarding
your
your
support
for
the
captain,
a
I
think
I'm
confused,
so
I
think
the
U.S
team
you're
approaching
more
to
the
toolkit
than
the
captain,
the
normal
Captain.
That's
correct
or
I'm
not
correct.
C
Think
David,
I,
I
guess
I
did
a
bad
job
in
the
beginning,
explaining
everything,
maybe
I
should
explain
it
again,
but
I
think
what
we,
what
we,
what
I
say
what
we
said
in
the
beginning.
We
see
the
world
moving
towards
githubs
and
kubernetes,
which
means
we
see
a
better
need
in
investing
to
a
pure
githubs
and
pure
Cloud
native
and
kubernetes
Native
approach,
and
that's
the
lifecycle
toolkit.
This
is
why
we
are
shifting
our
Focus,
because
this
is
where
the
world
is
moving
towards.
C
Okay,
okay,
what
it
doesn't
mean
is
that
we
are
not
a
painting
in
Captain
1-0,
because
Captain
one
always
there
and
Chobani
also
said
earlier.
There's
plans
already
in
the
roadmap
for
for
a
captain,
one
one
version
and
for
other
things,
but
we
are
at
least
shifting
priorities,
but
it's
not
going
away.
D
Yeah
that
okay,
okay,
thank
you
yeah
yeah,
we
adopted
toolkit.
We
are
now
learning
from
it
because
I,
don't
always
I
think
he
is
good,
but
well
documentation.
Only
that
part
yeah
I
I
knew
I.
We
can
I
think
that
is
good,
but
well.
I
I
share
my
feedback
in
the
slack
and
I
I.
Well.
The
problem
I
had
was
about
the
versions
because
the
the
web
page
saved
one
version
and
the
GitHub
is
using
another
version,
for
example,
for
the
definitions
task,
for
example.
But
okay,
that's
correct!
That's
good!
Okay!
D
C
D
D
Well,
I
think
they
only.
The
only
issue
we
have
is
is
the
the
the
the
task
because
of
what
I
said
so
I
will
I
will
share
you
well
in,
like
I,
don't
know
if
you
will
be
in
six
hours,
because
today,
right
now
we
are
at
3am
47,
so
I
will
I
will
give
you
a
well
I
will
show
you
in
the
slack
and
another
thing.
Let
me
know
only
that
only
that.
Thank
you
all
really
I
appreciate
your
help
and
your
time
really
only
that,
for
me.
C
B
D
Yes
and
and
the
other
problem
I
had
and
I
showed
you.
The
feedback
was
about
the
the,
for
example.
My
controller
pod
for
the
toolkit
was
crash.
I,
don't
know
why,
but
my
other
reports
from
another
namespace
could
not
start
because
they
were
trying
to
reach
the
toolkit.
That
I
think.
That
was
a
strange
case,
because
no
one
of
my,
for
example,
my
Argo
ports
or
my
istio
pods,
could
start
because
my
controller
yeah,
my
captain
toolkit
controller
was
was
crashed
and
I.
D
Don't
know
because
that
namespace,
for
example
the
my
yard
or
you
still
don't,
have
the
the
captain
annotation
in
the
namespace.
So
that's
what
we're
I
show
you
the
the
logs
and
that's
the
other,
the
other
problem
in
my
heart,
really
because
yeah
everything
is
good
and
I
I
will
ask
for
the
Hampshire,
but
I
I,
see
I
saw
the
roadmap,
so
we
are
good.
I
know
you
will
implement
it.
That's
that's
good
and
okay.
Only
that.
Thank
you.
Thank
you.
A
A
A
Any
last
from
the
chapter
is
nothing
more,
so
I
think
we
can
close
the
meeting
here
thanks
to
everyone
involved.
It
was
a
great
year
for
Captain.
We
have
a
new
cool
project
that
supports
key
tops,
a
major
release
of
Captain
B1,
so
I
think
was
a
successful
year
for
the
captain
project
and
with
that
I
wish
you
nice
holidays
and
see
you
again
in
January,
bye,
bye.
Thank.