►
From YouTube: Keptn Community & Developer Meeting - August 2, 2023
Description
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
Okay,
so
let's
start
I
have
very
little
announcement
for
the
community,
but
I
see
Stacy
also
has
something.
So
let's
try
to
keep
it
brief,
because
I
think
today
we
have
quite
a
lot
of
things
to
refine,
so
maybe
we
can
switch
up
the
agent
a
little
bit.
A
So
first
big
news:
we
have
a
minor
release
for
Captain
LTS.
This
is
mostly
security
related,
so
dependency
bumps.
A
There
is
also
something
that
has
to
do
with
documentation
and
nothing,
much
more
to
say
about
this.
This
is
1.4.1.
A
A
A
yes,
we
are
still
all
working
on
the
klt
monorepo
and
today
we
will
refine
with
flow
the
next
Milestone,
which
is
implementing
Gasol
parity,
so
that
we
have
exactly
the
same
feature
as
Captain
LTS
in
klt
and
I.
Think
that
sums
it
up
as
for
status
updates,
there
has
not
been
many
changes
from
last
time.
As
far
as
I
am
concerned,
Oh
Stacy.
Do
you
want
to
show
what
this
is
about?
Shall.
E
I
share
the
screen:
if
you,
if
you
can
just
click
on
that
link,
that's
fine,
so
yeah
Brad
McCoy
is
giving
a
sort
of
an
intro
to
Captain
lifecycle
toolkit
and
how
to
get
started
on
the
cncf
online
programs.
So
it's
an
on-demand
webinar.
It
will
be
available
starting
August
17th
and,
as
you
can
see,
that's
just
the
registration
page,
so
I
think
it's
available
for
like
two
days
and
then
it
makes
you
wait
and
then
they
post
it
like
a
week
later
for
just
on-demand
viewing
so
register
for
that.
E
A
D
Did
some
rewrites
to
clarify,
especially
on
the
captain,
apps
thanks,
so
much
for
flow
dude
straightening,
some
things
out
working
on
the
migration
guide,
which
so
far
we
you
know
we're
just
sort
of
writing
down
what
we've
got
to
know
and
we'll
put
it
there
and
hope
it
grows,
or
something
happens
and
Yosh
is
not
here
right.
D
D
So
so
that
I
was
gonna,
have
him
if
he
was
here
just
start.
Looking
at
that
old
big
architecture,
diagram
which
I
can
kind
of
I
can't
figure
out
half
of
what's
in
it
if
I
blow
it
up,
so
I
can
see
it
but
and
I.
Think
and
there's
you
know
it's
obviously
outdated.
For
starters,
the
separate
metrics
operator
doesn't
show
so,
but
we'll
need
him
here.
For
that.
So
don't
know
that
and
Adam's
working
on
a
new
getting
started
document.
D
D
Nice,
a
big
drawing
of
what
you're,
gonna
get
and
I
don't
know.
Would
we
you
know
I,
guess
we'll
have
a
discussion?
Do
we
we've
still
got
the
original,
getting
started
guide
that
Thomas
wrote
up
there
with
some
refinement
and
then
we've
got
the
three-part
thing
that
I
did
based
on
Andy's
demo
and
I.
Don't
know
whether
we
want
to
keep
all
of
them
or
just
trained
to
this
one
or
whatever,
but.
E
I
wonder
about
making
the
the
ones
that
you
did
for
based
off
of
Andy's
video,
like
more
of
like
a
use
case
guide
versus
like
a
getting
started
guide.
Well,.
E
D
Was
told
we
need
yeah,
that's
a
possibility
yeah,
but
we've
also
got
to
deal
with
if
we
continue
to
use
that,
we
need
to
make
sure
that
that
app
is
getting
the
app
that
we're
using
is
getting
updated
and
kept
up
to
date
with
the
software
and
and
there's
a
problem
that
it's
often
a
private
repo,
and
we
kind
of
don't
want
to
be
tying
to
things
that
are
in
private
repos
and
I
mean
it's
available
publicly,
but
yeah.
D
All
sorts
of
discussions
that
are
sort
of
you
know
I,
don't
have
strong
feelings
about
them.
Sort
of
up
to
the
group
to
decide
what
works
so
so.
D
D
D
D
E
E
Getting
started
guide
is
like
something
entirely
different
than
oh.
Here's.
Your
use
case
follow
this
guide
right,
so
yeah
that
that
kind
of
just
makes
sense
to
me
but
open
to
whatever.
A
C
Yes,
you
should
see
my
browser
all
right.
Okay,
so
today
we're
gonna
refine
the
issues
from
the
SLO
feature:
parity,
epic.
C
Last
week
in
the
community
meeting,
the
overall
concept
was
explained
right.
So
let's
in
this
session,
look
at
the
individual
issues
that
need
to
be
tackled
for
this
Epic
and
the
tracking
issue
you
can
see
here
on
my
screen.
So
this
is
the
issue
for
the
Epic
and
basically
here
we
have
the
list
of
all
individual
items
that
need
to
be
tackled.
They
are
already
ordered.
C
Mostly,
there
are
some
interdependencies
between
those
but
yeah.
Let's
go
through
them.
One
by
one
I
would
say
also
I
think
everyone
that
votes
is
already
in
the
board
right.
Okay,
that
looks
just
to
be
sure.
I
will
post
a
link
to
the
board
one
more
time
to
the
chat.
So
nobody
is
left
out
all
right
and
let's
look
at
the
first
one.
So
this
is
about
bootstrapping,
the
first
custom
resource
definition
that
we
will
need
for
this
to
work.
C
So
this
is
the
equivalent
what
to
what
used
to
be
the
slo.yaml
file
and
Captain
V1,
and
the
structure
is
depicted
in
an
example
here:
I'm
not
going
to
go
through
the
complete
structure
in
detail,
because
I
think
this
was
discussed
in
last
week,
but
in
case
you
do
want
to
to
get
into
more
details
there.
C
There
is
also
a
proof
of
concept,
pull
request
that
I
was
working
on,
were
Destructor
yeah,
pretty
much
defined
as
they
should
be,
so
that
can
can
be
taken
as
a
reference
and
then
also
in
addition
to
that,
there
are
some
constraints
when
it
comes
to
this
struct.
C
I
am
here
so,
for
example,
within
the
structure
we
allow
the
the
any
off
for
all
of
properties
either.
One
of
those
should
be
configurable,
so
you
wouldn't
be
allowed
to
set
both
any
off
and
the
all
of
property
and
then,
similarly
to
that,
for
example,
within
this
target
items,
you
can
only
set
one
of
those
operators
so,
for
example,
only
less
than
or
equal,
but
not
any
of
the
other
ones.
C
B
Definition
of
that
question
in
between
yeah,
if
you
go
back
up
to
the
example
the
outermost
any
of
or
is
it
intentional
that
those
are.
C
Any
of
no
that's
not
intentional,
so
that's
correct
that
should
be
I,
don't
know
that
should
be
like
it
is
because
here
we
only
have
either
any
of
or
all
of
but
not
multiple
of
those
okay.
B
C
You,
okay!
So
it's
just
to
to
stay
in
line
with
the
previous
structure
that
we
had
in
the
SLO
yaml
yeah!
Sorry
about
the
confusion.
C
B
A
C
Just
to
allow
multiple
combinations
of
targets,
this
proved
to
be
the
most
flexible
solution,
which
also
provides
the
the
same
features
as
the
SLO
all
right
and
then
yeah.
Of
course,
the
definition
of
done
would
be
that
we
have
this
custom
resource
definition
ready
with
with
the
manifests
and
all
other
required
configuration
generated
by
Cube
builder,
then
also
the
validation
web
hook
with
those
constraints
and
then,
of
course,
unit
tests.
What
a
validation
that
book
and
some
quick
little
tests
to
check
where
we
can
apply
those
resources
to
the
cluster
foreign.
D
G
F
A
Maybe
an
example
of
the
crd
filled
in
in
the
samples
could
be
part
of
this
ticket
yeah.
C
All
right,
Mo
any
opinions
for
DL.
B
C
C
So
if
you
recall
the
overall
concept,
this
will
be
similar
to
what
the
cap
metrics
would
be
right
now,
but
with
the
edit
support
for
making
use
of
a
templating
syntax,
because
later
on,
when
we
do
the
actual
analysis
evaluations,
we
will
need
to
be
able
to
fill
out
those
placeholders
in
order
to
get
the
actual
value
of
a
certain
required
value
for
the
particular
time
frame
of
the
metric
and
yeah.
Overall,
this
issue
is
similar
to
the
one
we
discussed
before.
So.
C
C
Previous
issue,
I
think
there
are
any
questions
about
that
one,
or
should
we
jump
into
the
estimation.
C
A
G
A
C
All
right,
we
have
an
agreement,
so
everyone
voted
for
s
in
this
case,
so
let's
put
a
little
rabbit
here
and
remove
the
label
all
right.
Thank
you
and
let's
go
on
with
the
next
one.
This
is
about
bootstrapping
and
other
custom
resource
definition.
So
this
is
the
analysis
crd
and
this
is
what
will
be
used
to
trigger
the
actual
analysis.
So
this
is
kind
of
an
application
of
an
instance
of
this
custom
resource
would
be
the
evolution.triggered
event
in
Captain
V1.
C
So
in
this
case,
to
do
an
analysis
you
would
create
an
instance
of
this
resource
and
what
you
will
need
to
provide
here
would
be
the
the
time
frame
because
in
this
case,
you're
interested
in
analyzing
a
certain
time
frame
and
additionally,
you
will
be
able
to
pass
a
set
of
selectors
or
not
where
you
can,
for
example,
looking
at
Captain
version
one
you
can
say
I
want
to
do
this
for
project
X
stage,
so
and
so,
and
so
and
so
and
so,
but
of
course,
in
addition
to
that,
you
can
pretty
much
pass
on
any
other
kind
of
key
value
pairs
that
can
later
be
used
in
the
and
retrieval
of
the
analysis
values
that
will
be
so.
C
This
will
basically
be
what
will
be
inserted
into
the
template
string
of
the
analysis,
value
templates
and,
of
course,
when
triggering
such
an
analysis,
you
will
refer
to
an
analysis
definition.
So
this
is
the
custom
resource
that
we
discussed
at
the
beginning.
So
this
will
tell
you
exactly
what
goals
the
the
values
that
you
would
like
to
analyze
should
meet
and
let's
I'll
just
copy
over
the
additional
entries
for
the
definition
of
done.
D
F
D
C
Sage
service,
those
we
do
not
type
in
klt
here,
I
just
added
those
particular
selectors
to
kind
of
establish
the
link
between
Captain
version
one
and
this
new
feature
in
klt.
So
this
would
be
how
you
could
translate
to
that.
But
those
are
not
any
special
kind
of
Concepts
that
are
going
to
be
introduced
in
klt,
so
those
could
can
really
be
any
key
value
pairs
like
this
full
bar
here.
C
If
you
would
really
like
to
map
project
stage
and
service
to
to
the
klt
I
guess,
project
would
be
a
captain.
App
service
would
be
a
cat
workload
and
for
stage
that's
not
really
a
concept
in
klt
that
would
translate
to
that
directly.
A
B
C
Don't
hear
you
or
not,
I
hear
him
yeah
Anna
just
confirmed
either
context
or
metadata
yeah
any
opinions
for
any
of
those.
A
In
in
Captain
LTS,
we
have
the
context
as
the
event
ID
yeah
or
something
like
that.
Yeah
in
we
are
gonna
have
context,
though,
because
we
have
an
issue
for
that,
so
filters.
B
F
F
A
C
A
A
D
Actually,
a
question
about
kind
for
all
of
these:
why
aren't
we
using
like
Captain
analysis
and
Etc
yeah.
C
We
recently
discussed
this
and
yeah
having
captain
in
front
of
all
of
the
custom.
Resources
doesn't
make
too
much
sense
at
this
point
because
it
just
becomes
overly
verbal.
So
we
actually
do
plan
to
remove
this
prefix
when
we
make
a
stable
version
of
all
the
apis.
D
G
B
The
API
Group
okay,
that
means
with
qctl,
if,
like
analysis,
is
also
a
thing
in
Argo
right.
So
if
you
would
do
Cube
CTL
get
analyzes,
you
wouldn't
actually
get
anything
because
it's
ambiguous.
If
you
have
security
and
Argo
for
example,
so
there
is
an
argument
to
have
it.
Prefixed
with
Captain
I.
Think.
A
You
can
have
the
short
name
which
is
Captain
a
or
Ka,
or
something
like
that.
So
you
can
do
a
get
with
that.
Oh
yeah,
okay
and
then,
if
not.
A
C
Apply
this
this
can
be
auto-generated.
So
if
you're
just
using
the
metrics
operate
and
not
the
life
cycle
toolkit,
you
can
then
trigger
an
analysis
by
applying
such
a
resource,
but
later
on,
within
the
lifecycle
toolkit.
C
This
could
replace
the
the
captain
evaluations
that
we
have
right
now
and
that's
what
the
life
cycle
toolkit
could
then
Auto
generate
when
doing
the
pre
and
post
evaluations.
C
C
C
This
will
be
about
implementing
the
actual
evaluation
logic
that
was
previously
taken
care
of
by
the
lighthouse
service
in
Captain
V1,
and
basically
we
don't
need
to
go
through
the
four
specifications
here.
I
think
because
this
will
kind
of
explode
or
time
frame
that
we
have
basically,
the
this
component,
that's
to
be
implemented
in
this
issue
will
take
a
set
of
analysis,
values
that
were
retrieved
previously,
essentially
a
map,
from
name
of
a
certain
value
to
the
its
actual
value
right
and
evaluates
those
against
the
goals
that
you
defined
in
the
analysis.
C
Definition,
and
basically,
this
component
will
go
through
each
of
the
objectives
that
you
defined
check.
The
criteria
that
you
defined
using
the
combination
of
the
any
off
and
all
of
properties
within
those
criteria
then
calculates
the
score
for
each
of
those
based
on
the
weight
of
the
individual
goals.
C
Summarize
them
and
then
it
will
calculate
the
achieved
percentage
of
the
total
achievable
score
and
then
using
the
pass
and
warning
thresholds
that
you're
specifying
in
the
past
percentage
and
warning
percentage.
It
will
then
decide
whether
the
result
is
a
pass
or
or
a
warning
and
yeah.
This
issue
is
for
for
implementing
this
component.
There
is
already
a
proof
of
concept
that
I
was
working
on,
because
the
logic
in
the
lighter
service
in
Captain
we
want
was
a
pretty
complicated
to
follow
and
I.
C
Think
I
found
a
a
good
approach
on
how
to
make
this
much
much
easier
and
testable.
So
I'm
gonna
link
this
proof
of
concept
PR
to
this
issue
and
yeah,
and
this
issue
is
really
about
only
implementing
this
this
function
or
this
this
component.
That
will
do
that.
So
the
definition
of
done
here
is
really
to
implement
the
component
and
do
the
unit
test
and
in
another
issue
we
will
actually
make
use
of
this
in
the
analysis
controller.
But
this
will
be
out
of
scope
of
this
issue.
B
F
C
Yeah
I
will
need
to
go
through
this
in
detail
later
after
the
meeting,
but
I
will
promise
mode
to
update
this,
but
I
think
it.
The
exact
thing
naming
will
not
affect
the
estimation
too
much
if
there
are
no
other
questions.
Let's
jump
into
the
estimation.
C
All
right,
we
have
two
else
and
two,
maybe
let's
start
with
the
the
else
so
Anna
and
Andre.
A
G
B
B
C
C
Only
exceptional
performance
will
consider
the
passing
rate
all
right.
Our
looking
time
was
20
minutes
left
perfect,
so
we
might
just
make
it
through
all
of
the
issues
that
we
need
here
all
right.
We
did
that
now.
The
next
one
is
the
controller
for
the
analysis.
C
This
one
depends
on
a
couple
of
the
previous
ones
that
we
just
discussed
all
right
yeah.
So
this
will
be
the
actual
controller
Logic
on
a
very
high
level.
What
it's
going
to
do
is
because
it
will
be
triggered
when
an
analysis
crd
is
applied
to
the
cluster.
So
when
you
want
to
do
an
analysis
of
a
certain
time
frame
and
what
the
controller
will
do
is
it
will
fetch
the
reference.
The
analysis
definition
right.
C
This
will
tell
the
controller
what
values
do
I
actually
need,
based
on
the
analysis,
value
template
references
within
that
analysis
definition
then
it
will.
It
should
make
use
of
the
the
current
provider
implementation,
so
dynatrace,
Prometheus,
eql
and
datadoc
to
actually
retrieve
those
values
based
on
on
the
queries
that
are
in
the
analysis,
definitions
for
that
it
will
need
to
replace
the
the
fields
from
the
baggage
that
we
have
in
the
analysis.
C
C
C
B
A
I
have
a
question
about
the
analysis.
Did
we
think
about
an
error
in
the
status?
Is
it
there
I,
don't
remember
if
I
see
it
so
like
if
this
core
computation
fails,
will.
C
Be
yeah
this
will
likely
be
an
outcome
of
either
this
issue
or
the
previous
one
where
the
actual
logic
is
implemented.
So
this
one
I
didn't
specify
in
detail,
but
I
think
this
will
be
an
implementation
detail
that
will
become
more
apparent
and
then
it's
up
to
the
implemented
to
suggest
concept
for
that
yeah.
C
Yeah,
let's
reveal
we
have
two
else:
one
M
any
strong
opinions
for
the
m.
C
C
Literally
plowing,
through
this
issue,
I
like
that.
Okay,
then,
let's
go
on
with
the
next
one,
and
this
is
about
adding
the
status
to
the
analysis
crd.
This
is
likely
gonna,
be
an
outcome
of
one
of
the
previous
two
issues
that
we
just
discussed.
I
just
wanted
to
to
separate
this
one
from
the
bootstrapping
of
that
analysis,
crd,
because
it's
important
for
the
other
issues
to
to
have
the
spec
of
the
analysis,
CRV
and
the
crd
itself
available.
C
So
we
can
work
off
of
that,
and
so
this
issue
is
all
about
just
storing
the
status
of
the
evaluation
and
as
Andre
suggested
here.
I
like
that
suggestion
is,
for
example,
also
add
the
status
of
the
individual
slis
that
we're
we're
using
during
an
analysis
also
including
the
concrete
query
that
we
then
used
to
send
to
the
provider,
to
fetch
the
query,
to
make
troubleshooting
easy.
If,
if
you
get
a
suspicious
value
for
one
of
those
analysis,
values
that
are
retrieved
during
the
analysis
and.
C
Yeah,
that's
pretty
much
the
scope
of
this
issue,
any
questions
about
that.
C
All
right,
let
me
delete
the
estimates
of
the
previous
one
and,
let's
estimate.
C
Okay,
we
have
two
s
and
one
Xs
I,
don't
have
a
strong
opinion
for
the
excess.
A
C
C
Then
we
would
have
two
more
issues
left,
but
just
to
give
you
a
quick
lens
of
this
code,
these
will
be
about
converting
the
the
captain.
B1
artifacts,
related
to
this
feature,
so
the
SLO
and
SLI
yaml
to
the
resources
that
we
discussed
here,
but
actually
I'm,
not
sure
how
how
much
we
can
set
in
stone
here
at
this
point,
because
I
think
it's
going
to
be
likely
that
some
things
will
change
during
the
work
on
the
previous
tickets.
That
will
likely
affect
the
goals
of
these
issues
here.
C
C
A
A
A
We
have
one
main
example
with
multiple
repo
with
observability
and
whatnot,
so
maybe
it
makes
sense
to
add
one
little
yaml
for
the
analysis
there
and
and
I
reckon
it
would
be
nice
if
we
do
it
and
it
separates,
because
then
anybody
can
document
it.
C
I
mean
if
there
are
any,
only
gonna,
be
adding
the
new
custom
resources.
The
rest
is
more
on
the
complex
side.
I
would
say.
A
C
C
Caused
this
with
Chobani,
because
I
think
also
the
timeline
that
we
need
to
fulfill
here.
C
A
Case
scenario
the
example
ticket
could
be
yeah.