►
From YouTube: Keptn Refinement Meeting - Feb 7, 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
Over
YouTube
so
welcome
everyone
to
the
first
iteration
of
this
Captain
refinement
meeting.
The
idea
of
this
meeting
is
to
go
through
our
open,
PR
and
issues
to
discuss
them
in
the
community
settings,
so
everyone
can
provide
inputs
and
support
us
with
technical
decisions
today,
I
think
more
written,
Andre
and
Anna
have
some
topic
on
the
agenda,
which
is
her
repos,
home
charts
and
repository
for
the
klt.
A
B
A
A
C
This
works
in
an
Accu
way,
but
we
followed
Helen
documentation
about
crd
handling
and
they
were
suggesting
to
store
our
custom
defined
resources
in
a
folder
which
is
called
crds
inside
the
chart
structure,
and
this
will
be
installed
every
time
you
do
uninstall
only
if
nothing
of
those
CRTs
is
already
present
in
the
cluster,
and
this
translates
in
this
horrible
behavior,
for
which,
if
there
is
a
change
in
the
CRT
during
development,
then
using
Helm,
update
or
uninstall
won't
work.
It
won't
change
the
crd
in
the
cluster.
A
B
Yeah,
you
cannot
even
install
a
new
API
version
of
the
same
thing
if
something
already,
if
something's
already
there.
So
if
we
have
the
cap
nap,
V1
rfa1
and
we
developed
V1,
Alpha
2
upgrade
wouldn't
actually
install
the
new
version.
B
And
then
we
kind
of
I
mean
yeah
we
with
our
project.
We
are,
of
course,
not
the
first
ones
to
stumble
over
this
and
we
kind
of
looked
at
different,
basically
workarounds,
that
people
did
and
there
are
a
few.
But
it's
really
like
it's
work.
A
G
A
B
C
B
B
C
B
In
the
same
template,
so
we
don't
use
the
CRTs
folder,
but
just
treat
the
series
as
any
other
template.
So
it's
just
in
the
templates
folder
inside
the
home
chart
and
with
that
we
had
issues
with
conversions
again,
I
think.
C
B
Yeah,
so
you
could
remove
an
API
version,
for
example,
and
if,
for
some
reason,
there's
an
actual
resource
of
that
API
version
in
the
cluster,
it
would
just
be
gone
and
we'll
delete
the
crd
and
the
cro
will
be
gone.
G
B
B
H
H
B
D
B
C
B
G
G
B
An
option
to
solve
that
would
be
to
actually
get
rid
of
customize,
since
we
don't
really
need
it
for
auto
generation
anymore
now
or
not
necessarily
needed
I
guess.
C
G
H
I
A
I
D
C
H
H
But
they
have
when
they
they
have
upgrading
procedures.
So
when
you
take
a
look
on
the
readme
of
the
of
the
stick,
you
see
what
should
be
updated
when
you
update
from
two.
D
B
H
B
D
H
Well,
I
think
you
always
need
only
only
to
have
these
versions
which-
which
you
have
already
supported
at
the
moment,
because
if
you
have
custom
Resources
with
versions
which
are
not
supported
but
and
you
drop
the
you
drop,
the
definition
for
the
versions,
they
would
be
gone
in
any
way.
C
D
B
Is
the
conversion?
So
if
you,
if
you
add
a
new
crd
version,
all
the
versions
that
exist
in
the
cluster
already
all
the
custom
Resources
with
the
previous
version
that
exists
in
the
cluster
already
won't
actually
be
upgraded
right.
Yes,.
B
G
H
B
B
H
So
we
need
to
Define
how
many
versions
We
want
to.
We
want
to
support.
So,
let's
say
the
last
one,
the
the
last
two
or
three
ones
and,
to
be
honest,
the
lifecycle
controller
is
the
life
cycle.
Toolkit
is
built
in
a
way
that
that,
if
you
update
regularly,
the
old
things
might
might
get
deprecated
in
any
way,
because.
D
H
You
create
them
you
when
you,
when
you
add
a
new
application,
the
application
will
get
great
you,
you
will
get
a
new,
a
new
application
version
and
so
on.
The
only
problem
would
be
that
if
someone
does
not
deploy
very
often
that
that
our
resources
get
dropped
at
some
point
in
time,
but
this
will
also
not
have
any
impact
on
the
application,
because
then
the
only
thing,
what
happens
is
that
our
resources
are
gone.
B
B
B
D
H
I
think
this
would
be
a
good
question
for
all
for
community
members.
A
I
But
what
are
the
biggest
kind
of
pros
of
the
helm,
charts
standard,
of
course,
and
it
provides
the
user
the
possibility
to
configure
values
which,
in
the
current
case,
it's
not
easy.
G
A
Yes
or
no,
because
config
CRT
works
well,
if
you
apply,
but
if
you're
using
terraform
pulumi
hard
to
make
it
work.
H
So,
from
an
integration
perspective,
it's
always
easier
to
integrate
a
hidden
chart
than
a
manifest
to
be
honest
yeah,
so
when
it
especially
when
it
comes
to
terraform
or
when
it
comes
to
I,
think
I
think
from
a
cross
printing
perspective.
It's
not
it's
not
this
relevant,
but
especially
when
it
comes
to
terraform,
then
Hill
Mr
way
to
go.
C
H
The
the
whole
details
thing
is
always
a
topic
when,
when
you
remove,
when
you
remove
circuits
yeah
so
when
it
simply
comes
to
updating
or
adding
new
versions
and
so
on,
this
is
absolutely
no
problem
and
we
at
some
point
in
time
we
will
get
to
a
point
where
the,
where
the
resources
will
not
change
very
often,
hopefully.
C
A
At
the
moment,
I
think
we
need
to
pose
a
bit
this
topic
and
to.
C
A
A
A
C
A
A
C
So
in
the
last
one,
okay,
yeah.
A
A
F
D
I
F
Was
in
the
example
folder,
but
I
think
the
description
and
the
readme
was
not
so
much
descriptive
for
a
beginner
for
a
beginner,
so
I
think
I
can
like
improve
a
little
bit
of
it.
Awesome.
A
A
I
Yeah,
the
question
is
how
deep
the
Roundup
should
be.
Yeah
probably
start
from
the
beginning,
due
to
the
community.
I
Yeah,
so
the
whole
concept
of
the
auto
application
Discovery
shoots,
allow
us
to
kind
of
take
the
existing
manifest
that
the
users
already
have
applied
them
to
the
cluster
and
have
an
out
of
the
box
automatic
application
already
created
without
the
manual
user
creation,
which
is
in
the
which
is
the
current
state.
I
I
The
captain
up
creation
request
custom
resource,
also,
it's
a
follow-up
ticket
after
or
yeah,
basically,
a
parallel
ticket
to
changes
made
to
the
web
hook,
which
was
refined
in
the
last
refinement,
where
the
new
update
is
basically
that
instead,
the
kept
the
mutating
level
creates
a
captain
app.
Now
it
creates
a
new
captain,
app
creation
request
and
the
creation
of
the
Krypton
app
is
handled
by
the
captain
up
creation
request
controller.
I
Let's
look
at
the
technical
details,
I
added
at
the
beginning,
some
explanationary
notes
so,
for
example,
how
to
know
if
the
captain
app
is
user
defined,
so
the
captain
app
is
user
defined
if
it
does
not
have
the
metadata
dot
owner
reference
at
all,
because
it's
made
and
applied
by
the
user.
If,
for
example,
the
captain
app
was
created
by
Captain
up
creation,
request
controller,
it
has
got
this
reference
in
the
metadata
dot
on
the
reference.
So
therefore
we
can
see
if
it
was
or
not
user
created
I'm.
I
I
This
decision
is
made
by
the
mutating
webhook
and
it's
based
on.
If
the
it's
based
on
the
presence
of
the
application,
Captain
application
annotations
in
the
in
the
workload
or
in
the
Manifest.
Basically,
the
difference
between
a
single
service
and
a
multi-service
application
is
in
the
timeout,
so,
basically,
by
single
service
application.
We
do
not
need
to
wait
another
30
seconds
to
have
all
the
manifests
applied,
because
we
basically
know
that
that
we
have
the
one
manifest
already
applied
and
we
can
directly
proceed
to
creating
the
captain
app.
I
In
other
case,
if
we
have
a
multi-service,
we
need
to
wait
a
few
seconds.
This
value
will
have
a
default
of
30
seconds,
but
in
the
future
it
will
be
configured
via
Captain,
config
crd,
so
that
we
are
sure
that
we
have
all
the
workloads
or
manifests
applied
to
the
cluster
before
creating
the
app
yeah,
how
it
should
actually
work
so
the
workflow
in
the
first.
I
In
the
first
step,
the
controller
should
try
to
fetch
the
captain
app
if
he
finds
it
and
it's
user
defined.
So
then
there
is
no
Auto
application,
Discovery
needed.
It
will
remove
the
captain
up
creation,
the
request
and
do
not
reconcile
again.
So
that's
basically
it
that's
the
easiest
scenario
then
second
test.
If
the
captain
app
exists
and
it's
not
user
defined,
the
control
checks
the
timeout.
If
it's
not
expired,
it
reconciles
so
we're
still
waiting
for
the
timeout
and
the
same
applies.
I
If
the
captain
app
does
not
exist
yet,
then
we
check
the
timeout
and
if
it's
not
expired,
we
reconcile
what
happens
if
the
timeout
has
expired.
I
Yeah
the
length
of
the
timeout,
as
I
already
said,
is
depend
on
if
it's
single
or
multi-service
application
afterwards.
The
control
effect
is
all
the
existing
workloads
in
the
system
which
are
pointing
to
the
application
and
create
or
updates
a
captain
app
with
the
correct
version.
I
Just
to
know
the
version
of
the
captives
is
computed
as
a
hash
of
the
versions
of
the
workloads
which
are
part
of
this
application.
So
they
are
basically
two
scenarios.
If
the
captain
app
does
not
exist,
it's
created,
and
if
it
already
exists,
then
it
we
are
speaking
about
updating
of
the
captain
app
adding
workloads
bumping
the
version
of
one
of
the
workloads
or
more
and
so
on.
I
So
creation
of
the
captain
app
controller
creates
a
captain
app
just
a
node
here
up.
We
cannot
forget
to
start
the
context
of
the
app
due
to
the
traces,
so
we
need
to
include
the
trace
context
carrier
into
the
annotations.
Examples
are
in
the
links,
but
that's
up
to
the
implementer
to
look
at
to
it
and,
of
course,
all
of
the
existing
workloads
pointing
to
the
applications
are
part
of
this
Captain
app.
I
I
The
captain
upgradation
request
is
deleted
as
yeah.
That's,
basically
it
and
the
reconcile
Loop
ends
in
this
In
This
Moment,
so
yeah
any
questions
or
thoughts.
I.
A
Do
have
a
question
because
right
exactly
today,
I
was
talking
with
Thomas
about
where
does
the
trisk
or
the
trace
starts
and
I
was
sure
it
was
in
the
web
hook,
but
in
the
code
we
have
also
a
place
where
we
started
tracing
the
app
controller.
H
F
I
We
do
not,
we
basically
started
tracing
the
web
hook
and
I
suggest
that
the
trace
which
we
started
in
the
web
hook.
Currently,
we
should
start
here
in
the
captain,
upgradation
request
controller,
so
basically
just
move
the
functionality
from
the
web
hook
to
the
controller.
I
A
You
please
change
the
text
to
report
that,
so
there
is
no
confusion
for
this.
How
do
how
should
I
change
it
just
to
say
that
move
the
logic
from
starting
the
trace
of
the
Web
book
here.
I
I
think
it's
pretty
clear
because
if
you
click
on
the
examples
they're
referring
to
the
web
hook
so
true.
G
The
trace
that
started
in
the
Red
Hook-
that's
they
want
for
the
for
all
the
reconciliation,
Loops
right.
A
A
I
Yes,
exactly
yeah,
this
ticket
is
basically
about
covering
Corner
cases
which
might
happen
during
the
creation
of
the
app
yeah
I
described
the
corner
cases
the
most
it
was
basically
part
of
the
previous
ticket
previously,
but
we
as
a
team
agree
that
it
should
be
good
to
split
this
because
it
kind
of
the
complexity
grows
which
have
a
covering
all
the
stuff
as
part
of
the
one
PR
or
one
ticket.
I
So
what
is
the
corner
case?
We're
speaking
about
yeah?
Mostly
what
happens
if
we
apply
a
captain
workload
with
version
one
and
before
the
timeout,
and
also,
and
also
with
the
version
V2?
What
happens
if
it's
applied
after
the
timeout?
I
So
if
the
captain
workload
kept
on
work
out
about
version,
V2
is
applied
before
the
timeout
expired.
Each
of
the
currently
present
workloads
will
be
added
to
the
app.
If
there
are
multiple
versions
of
the
same
workload,
the
latest
will
be
applied
by
time.
So
if
we
applied
workload,
V1
and
5
seconds
later
record
V2
and
after
20
seconds,
the
timeout
has
expired.
The
we
workload
of
E2
will
be
picked
to
be
edit
to
the
to
the
captain.
App
any
questions
about
the
behavior
of
this.
G
It
might
be
that
this
doesn't
really
need
any
additional
implementation
right.
It's
just
something
to
double
check,
because
if
you
update
a
workload
that
we
already
had,
then
we
won't
have
the
the
previous
one
anyway,
I'm
done
once
the
expiration
deadline
has
exceeded
for
the
discovery
then,
what's
there
will
be
will
be
taken
exactly.
I
In
kubernetes,
we
always
have
a
basically
the
latest
version
of
the
same
service
develop
deployment
spots
or
whatever.
Well,
there
are
always
one
there's,
no
way
that
two
of
them
can
exist
if
they
are
not
named
the
same.
I
Okay,
so
I'll
move
to
the
second,
which
is
a
little
bit
trickier.
So
what
happens?
If
the
captain
worked
out,
we
too
is
applied
after
the
time
of
expired,
for
example,
basic
usage.
We
apply
the
workloads,
the
timeout
has
expired
and
the
captain
app
was
created
and
afterwards
after
two
days,
a
new
version
of
the
workload
is
applied
so
version
V2.
I
If
the
implementation
of
the
controller
is
done
correctly,
yeah
just
a
note
under
the
line,
only
the
new
workload
will
be
displayed
in
the
auto
trace
of
the
captain,
app
version,
but
that's
basically
expected
because
it,
the
trace
itself,
displays
what's
happening
in
the
system,
so
yeah.
This
is
I,
don't
know.
If
it
will
need
additional
implementation,
but
it's
definitely
good
to
consider
these
two
cases
and
kind
of
create
unit
tests
and
component
tests
for
these
specific
cases,
maybe
if
maybe
also
without
any
implementation
changes
necessary.
A
I
C
D
C
D
A
I
D
F
C
I
also,
usually
add
the
e,
but
that's
only
for
cows.
A
A
I
Basically,
the
goal
is
to
document
the
newly
introduced
resource,
create
examples.
I
Yeah
basic
stuff
introducing
into
the
readme
also
create
an
input
in
the
docs
folder,
create
an
example
for
the
users
where
they
can
actually
try
it.
The
things
we
basically
do
for
every
new
feature,
nothing
much
just
more
to
say
about
this.
To
be
honest,.
E
A
E
A
A
E
F
Can
yeah
I
was
I
was
looking
at
the
sample
app
calleder,
so
I
today,
I
tried
to
make
up
and
running
a
sample
app,
but
the
disc
the
readme
was
not
descriptive
enough
for
me.
So
I
had
a
lot
of
difficulties
while
doing
that,
but
in
the
end
I
could
set
it
up
and
meanwhile
I
already
did
appear
a
small
peer.
So
that's
that
but
I
think
this
space
can
be
improved
a
lot
so
that
any
beginner
can
like
set
up
local
kubernetes
cluster
and
then
run
the
example
app.
G
E
D
D
F
I
was
looking
at
that
already
have
been
asked,
has
been
assigned
to
me.
I
sent
it
to
the
chat,
but
I
don't
have
like
any
idea
or
I,
don't
know
where
to
start.
So
if
you
could
give
me
some
hints
on
that,
then
that
would
be
yes.
Sorry.
A
I
miss
your
ping.
This
one
I
just.
F
A
Yeah
now
I'm
a
bit
agitating
because
we
just
discussed
ham
charts
and
we
don't
know
exactly
how
to
proceed.
So
this
is
exactly
covering
yeah
I.
Just
for
the
hand,
chart
I'll
say
anyway,
it's
worth
for
you
to
give
it
a
shot,
because
we
don't
know
if
we
will
go
ahead
with
them
charts
or
not.