►
From YouTube: Keptn Refinement Meeting - Mar 21, 2023
Description
Meeting notes: https://docs.google.com/document/d/10Fig1eYFZ9iQFSYWkz0c4eTwzgJiPtQI5IsczbvLsuE/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
A
A
A
Then
we
have
something
here.
This
is
already
Big
Move,
this
one
Thomas
consolidation
of
the
examples
and
they're
getting
sorting
guide.
A
C
B
A
So
for
release
0.8,
we
have
quite
of
things
here
already.
Some
of
these
have
been
tackled,
but
the
biggest
feature
should
be
an
automatic
application
discovery
this.
What
we
should
aim
as
a
goal
for
the
next
release,
because
currently
Captain
requires
a
captain
app
to
be
next
to
your
deployments
in
order
to
work
properly.
A
But
it's
not
always
necessary,
because
if
you're
following
the
good
kubernetes
standards
and
having
those
recommended
labels
or
annotations,
then
we
can
derive
out
of
the
box.
This
Captain
app
for
you.
So
if
you
want
to
use
just
the
observability
aspect
of
your
deployment,
you
don't
need
to
do
anything
and
we
can
provide
things
for
you
out
of
the
box.
A
A
There
then
improve
a
bit
the
tasks
execution,
because
now
we
allow
a
job
to
fail,
fail,
fail,
fail
over
and
over
and
over,
instead
of
having
a
max
amount
of
time
that
this
can
be
failed
for
then
improve
a
bit
The
Matrix,
because
we
saw
with
the
recent
data
dog
implementation
that
some
providers
require
a
specific
from
into
either
API.
So
we
should
provide
a
time
frame,
so
the
two
is
always
now
and
the
from
is
now
minus
the
time
frame
then
also
timeouts
and
retrievable
should
be
configurable
for
function.
A
Then
this
one
I
guess,
and
now
we
discuss
a
bit
yes
from
last
time.
We
refund
it
a
bit
better
to
provide
extra
coverage
for
this
water
dot
go
file,
and
then
we
have
some
pipelining
things
to
have
a
pipeline
that
nightly
checks
that
we
can
upgrade
our
home
charts
from
the
latest
version
to
the
master
version
or
main
version.
This
way
we
can
test
nicely
if
we
can
upgrade
the
klt
Via
Helm
or
not.
D
E
A
Then
this
is
a
follow-up.
So
let's
move
it
closer
to
the
previous
one,
since
we
changed
the
captain
metric
to
support
the
time
frame,
now
it's
time
to
update
all
the
different
SLI
providers
to
make
use
of
this
value,
then,
from
this
oops
sorry
from
a
previous
PR,
we
introduced
some
LinkedIn
for
Emer
files,
but
now
our
only
warning
and
do
not
fail
any
build,
and
instead
we
should
do
a
research
and
decide
on
which
rules
we
should
apply
and
which
node
and
then
enable
this.
A
A
A
E
Was
an
ugly
PR
to
begin
with,
but
there's
no
way
to
format
it
and
it
just
got
uglier.
So,
but
let's
see,
if
we
can
look
at
it,
we
need
for
the
crds.
We
need
I
think
we
need
a
reference
page
for
each
one,
that's
fairly
detailed
and
complete.
So
we
can
just
reference
that
then
we
do
use
case
documents
about
how
to
do
something
and
we
can
just
link
to
the
various
crds
for
all
the
detail
and
then
in
the
use
case.
E
We
just
say
we
did
this
here
for
this
and
that
the
Moritz
has
got
it.
So
it's
Auto
generating
some
information,
but
the
information,
it's
Auto,
generating,
isn't
exactly
what
users
need.
I
think
we
need
discussion
for
the
group,
but
I
I
want
us
to
have
a
lot
more
authored
information
in
there
and
we've
got
issues
about
formatting
and
everything.
But
the
first
question
is
whether
this
is
what
we
all
agree
so
to
look
at
this
ugly
thing.
So
you've
got
that's
what's
currently
displaying
for
them.
D
E
Yeah,
okay
and
the
first
thing
I
think
we're
gonna
need
a
separate
file
for
each
crd,
because
when
I'm
done
with
it,
it's
really
long.
E
So
what
I
did
was
I
pulled
out
and
I
took
task
definition.
It
has
a
definition
that
I
don't
know
what
I
did
now
I
thought
I
had
yeah.
So
it
starts
out
with
a
very
brief
but
explanation
about
what
the
crd
is
for
and
then
now
I
put
in
yaml
synopsis,
because
I
guess
that's
not
actually
what
the
machine
is
seeing,
but
that's
what
the
user
sees
and
and
I
think
everybody
else
when
the
existing
docs
we've
got
on
these
people.
This
is
what
we
show.
E
This
is
what
people
have
to
fill
out,
so
I
put
that
in
and
then
I
lost
my
header,
but
at
line
95
there
should
be
a
header
that
starts
the
fields,
definitions
and
there
we
go
through
and
discuss
each
one
of
them
and
I've
got
some
text.
That
would
need
a
lot
of
work
on
it,
but
it
gives
you
a
general
idea,
but
how
you
fill
it
in
what
value
values
this
sort
of
stuff
and
then
at
line?
181
I've
got
the
field
spec,
which
is
what
is
being
auto-generated
and.
E
Right,
oh
I,
think
that
might
actually
I
did.
I
was
looking
there's
various
tools
out
there
yeah.
So
this
garbage
is
up
your
source
code
right.
E
E
I
was
under
the
impression
that
this
is
no
I
would
love
to
have
it
in
separate
files.
Actually,
that
were
I
thought.
This
is
what
you
guys
wanted.
C
Maybe,
to
clarify
a
little
bit:
this
is
just
in
that
file
so
that
we
can
Auto
generate
it
so
that
we
don't
need
formatted
things
at
all
or
pre-formatted
rendered
yaml
files,
so
it
will
auto
render
it
for
us.
That's.
A
E
F
I
think
on
the
top,
there
should
be
a
comment,
separate
comments.
F
E
A
F
F
And
the
task
definition
that
were
edited
or.
D
D
E
A
A
D
F
F
C
E
A
We
need
to
put
into
how
much
effort
do
we
need
really
to
put
into
this,
because
we
might
want
to
have.
E
G
A
To
create
the
extra
tooling
for
this
I
don't
know
if
it's
worth
the
effort
right
your
opinion,
because
you
know
the
auto
generation
tool
better.
E
E
So
I
mean
one
possibility,
is
that
we
have
this
section
that
has
the
markdown
generated
files
that
start
with
the
yaml
file
and
have
all
the
traditional
reference
for
the
end
user
and
then
have
a
subdirectory.
That
is
the
file
for
that
library.
With
its
auto-generated
I
mean
it
would
give
them
like
the
types
for
different
fields
and
stuff,
which
is
of
some
interest.
E
F
A
G
F
E
E
What
we
don't
want
to
do
is
have
we
want
in
the
examples
we
want
to
discuss
exactly
what
the
crd
is
doing.
It's
you
know
it's
running
this,
and
you
know
this
is
how
it's
done.
I
don't
want
everyone
to
be
explaining
all
the
bloody
fields
that
are
in
there
there's
stuff.
That's
just
standard
I
want
us,
you
know
a
central
place,
that's
comprehensive
for
that.
F
F
B
E
For
example,
I
mean
this
one
is
a
particularly
interesting
one
for
the
at.
What
is
the
field,
the
one
where
you
actually
give
the
dental
code
and
everything
for
what
the
task
is
going
to
do,
and
that
needs
some
details.
F
A
F
F
E
E
E
Have
it
be
listed,
alphabetically
and
I
would
be
delighted
if
I
could
just
take
this
stuff
here
and
expand
it
and
put
it
put
them
in
alphabetical
files
in
something
called
a
reference
section
and
and
just
author
them
within
the
docs
tree.
C
Would
actually
do
it?
The
other
way
around
I
would
think
of
the
concept
section
as
your
reference
as
what
you're
referring
to
as
the
reference
section.
That
is
the
reference
section.
Okay
and
then
you
have
your
on
the
quotation
marks
Pros
documentation
about
the
yamos
in
there
and
none
nothing
is
also
generated,
basically
done.
Okay
and
and
the
API
reference
can
be
whatever
it
is
somewhere
else.
C
E
D
C
But
it
makes
sense
because,
because
it
is
broader
Concepts
that
we
talk
about
and
not
specific
old
things
under
quotation
marks
again
well,
it
is
Concepts
and
behavioral
things
that
we
talk
about
in
each
of
the
crgs,
because,
as
Anna
said
it,
the
cods
are
configuration
to
change
behavior
of
our
controllers
of
of
our
operator.
C
C
So
in
that
sense,
I
I
would
say
if
it's
fine
for
us
as
developers
as
biased,
as
that
may
be,
it's
maybe
also
fine
for
our
users.
If
that
makes
sense.
E
C
E
B
A
C
Basically,
the
question
is
what,
if
you're
trying
to
configure
kot,
what
kind
of
documentation
would
you
like
to
see
and
kind
of
in
a
way?
C
So
the
the
bigger
question
that
we
have
in
the
room
now
is
basically
auto-generated
kind
of
API
reference
versus
nicely
formatted
I,
don't
know
pages
of
the
yaml
with
explanations
of
all
the
separate
fields.
G
If
I,
if
I,
think
personally
I
think
I'll
go
with
the
yaml
type,
because,
let's
say
I
am
you
know
working
currently
on
building
klt
killer,
coder
demo,
so
I
find
it
easy
when
I
refer
to
the
yaml
type
rather
than
this,
because
all
right,
let's
say
I,
have
to
run
to
different
files.
I
will
have
to
manually
go
through
files
and
then
for
the
API.
One
I
have
to
go
to
manual
files
and
then
check
for
it,
but
in
the
in
the
yaml
type.
F
F
So,
for
instance,
I
want
to
make
a
task
I
go
to
task,
I
check
the
file
here
and
then
here
I
have
a
link
that
tells
me
okay.
This
is.
B
I'm
also
for
this
option,
because
yeah
kubernetes
as
far
as
I
know,
does
it
in
the
same
manner.
So
we
should
stick
what
it's,
but
the
big
guy
is
basically
say:
yeah.
A
A
My
life
get
out
of
the
source
code.
Only
so
I
would
also
still
keep
those
yeah.
This
Auto
generated
stuff,
because
very
Advanced
users
might
want
to
steal
every
single
detail,
but
move
as
much
as
possible
into
concept
is
auto-generated.
C
E
What
about
we
could
we
could
put
one
more
comment
line
in
the
source
code
that
would
link
back
to
the
concepts
file,
that's
relevant,
so
they
could
go
back
and
forth
from
each
other
one.
Would
you
think
of
what'd
you
think
of
that.
C
C
E
And
let
me
I
can
go
ahead
hopefully
and
have
at
least
a
PR
in
the
docs,
so
we
can
look
at
it
with
netlify
for
a
couple
of
these
by
the
community
meeting
tomorrow.
Let
me
see
if
I
can
do.
E
Stuff,
there's
a
bunch
of
stuff
that
appears
in
the
yaml
file
that
is
actually
sub-objects
to
the
crd
and
are
we
auto-generating
any
information
about
those.
E
Like
for
the
captain,
I
think
it's
spec,
where
you
put
the
actual
code
executed,
yeah
and
that's
not
currently
showing
up
in
what's
auto-generated.
The
auto
generator
is
just
the
pure
for
that
particular
crd.
Right.
C
It
is
in
there,
but
in
one
of
the
sub-objects
okay,
there's
a
captain
task.
You
have
your.