►
From YouTube: Keptn Refinement Meeting - Jun 13, 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
I
would
suggest
that
we
postpone
the
merge
of
that
PR
until
we
do
the
release
of
0.8,
which
should
come
either
today
or
tomorrow.
So
we
can
merge
that
PR
and
then
work
on
the
CLI
changes.
Otherwise,
we
release
captain
in
a
version
that
you
have
this
option,
but
you
cannot
really
use
it.
Yeah.
B
A
A
Okay,
okay,
perfect
and
thanks
to
you
for
working
on
that,
okay,
so
10
different
tickets
were
to
start.
Where
is
the
tracking
here,
I
kind
of
remember
now
the
work
in
progress
since
I'm
done
with
this,
so
the
next
big
thing
for
0.9
should
be
the
support
for
Readiness
Gates.
So
during
kubecon
talking
with
people,
we
discovered
that
everyone
have
their
own
special
scenario
with
their
own
special
platform.
Setup
and
many
people
have
custom
scheduling,
schedulers
deployed
in
their
clusters.
Therefore,
we
should
go
away
from
our
scheduler
plugin
and
instead
use
the
Readiness
Gates.
A
This
way
more
people
can
use
captain
and
also
we
don't
have
to
ship
another
image,
consuming
more
resources,
allocating
more
memory
in
the
cluster
where
we
can
use
something
which
is
native,
but
there
is
a
big
but
Readiness
Gates
is
just
in
beta,
it's
not
stable.
Yet,
therefore,
we
cannot
go
out
with
that
full
flash.
We
need
to
be
ready
to
support
it,
but
we
can
only
enable
this
feature
where
in
two
conditions
right
in
this
case
it's
enabled-
and
we
are
deploying
klt
in
a
cluster
where
it's
stabled.
A
So
until
then,
we
should
hide
all
of
this
behind
the
feature
flag
and
before
to
induct.
We
need
to
do
a
bit
of
refactoring,
so
the
first
thing
is
to
change,
or
we
do
inject
the
decoder
inside
the
WebEx,
because
here
the
container
runtime
or
the
library
that
we're
using
change
the
way
of
it
works
and
we're
not
compatible
anymore.
So
we
need
to.
A
A
A
Instead
of
an
excess,
so
basically
it's
straightforward
change
from
having
a
method
that
injects
it
from
that
to
have
here
inside
the
structure
passing
this
decoder
create
outside
and
pass
it
through.
So
very
straightforward,
I
put
s
instead
of
Xs,
because
maybe
we
need
to
adapt
multiple
tests,
but
I'm
fine
with
an
excess.
It's
quite
straightforward,
I
would
say.
A
Since
it's
an
excess,
okay,
then
support
controller
runtime.
After
we
change
our
code
base.
With
this
explicit
injection
of
the
decoder,
we
can
move
and
bump
our
library,
the
control
runtime
version
to
0.15,
and
here
we
need
to
do
a
bit
of
a
refactoring
of
the
code.
Let's
say
because
there
are
a
lot
of
other
breaking
changes:
okay
and
we
need
to
change
how
we
inject
our
certificates
and
already
did
the
POC
here
slowly
we'll
go
to
the
right
line
here.
It
is
from
here
to
this.
A
D
When
I
did
the
research,
the
library
has
not
stabilized
yet
was
not
released
yet
so
these
are
the
changes
listed
up
to
now.
There
may
be
other
things
that
fail
when
we
go
right.
A
D
I
forgot
to
mention
that
if
we
bump
control
around
time,
we
don't
kubernetes
as
well
look.
This
is
also
kubernetes
2017.
C
A
A
A
The
first
part
is
to
have
a
new
web
hook
that
can
work
with
Readiness
Gates.
So,
in
addition
to
the
existing
Web
book,
we
create
a
new
one,
and
this
new
one
can
inject
writing
skate.
I
call
it
klt
pre-check
gate,
but
the
name
is
up.
You
know
for
discussion.
If
you
have
a
better
name
pick
it
in
the
comment
or
slack
whatever,
or
do
implementation
during
the
peer
review.
Let's
come
up
with
a
better
name.
A
A
Furthermore,
the
web
hook
should
only
be
called
when
a
new
manifest
is
created
if
a
manifest
is
modified
or
deleted.
The
webbook
should
not
be
invoked
at
all,
so
we
should
only
register
on
the
create
event.
A
C
D
A
And
it's
behind
the
feature
flag.
That's
why
so
cattle
test
I
asking
you
team?
What
do
you
think
she
have
a
cattle
test
that
turn
on
the
feature,
flag,
run
and
checks
for
is
the
Manifest
now
having
this
Readiness
gate
or
not,
or
it's
better
to
wait
until
all
the
pieces
are
complete
and
we
do
our
final
end-to-end
test
can.
D
One
will
be
at
all
past
the
whole
feature
with
the
hand
part
as
well,
because
right
now
we
do
not
do
our
tests
with
sound.
We
do
it
with
the
Manifest,
but
this
whole
logic
won't
be
right.
A
I
would
say:
Helm
is
a
bit
different,
because
in
help
we
need
to
consider
scheduling
the
scheduler
should
not
be
deployed.
This
feature
is
true.
It's
enabled
sorry,
so
I
would
not
consider
how
the
manifests
hit
the
cluster,
because
in
a
cuddle
test
you
check
when
manifest
hit
the
cluster
what's
happening.
So
once
everything
is
already
installed,
I'm
not
consider
the
installation.
A
E
C
C
A
C
B
C
C
A
A
A
A
A
D
A
D
A
No,
unfortunately,
you
cannot
work
immediately
on
this
one
because
before
we
need
to
bump
the
dependency
I
forgot
to
edit
great
sorry
before
we
need
to
have
this
bump
on
this
Library.
Otherwise
we
cannot
use
it.
A
Then
next
piece
of
the
puzzle,
as
I
was
saying:
we
have
now
everything
in
place
that
ads
already
in
skates.
We
need
to
get
rid
of
this
Readiness
gate
as
soon,
oh
sorry,
not
soon,
but
after
all,
the
pre-deployment
checks
are
completed.
C
C
D
A
B
Well,
I
would
also
have
set
access,
but
due
to
adding
extensive
tests
in
the
form
of
unit
tests,
I
want
it
a
little
bit
up
to
2s.
A
A
G
C
D
A
No,
but
beside
that,
Christian
Morris
have
a
valid
point,
because
here
we
only
check
for
Server
version,
but
server
might
be
one
version
forward
compared
to
the
node,
and
so
there
are
mismatch
between
cubelet
cubelets.
G
A
A
Okay,
so
I
will
keep
the
previous
text
to
make
sure
that
we
have
the
logic.
The
only
thing
that
we
change
is
which
version
of
creates.
We
are.
B
A
A
Oh
someone
changed
their
opinion.
I
put
l
to
be
on
the
safer
side,
but
m
is
also
fine
for
me,
and
here
we
have
a
dependency.
I
was
waiting
for
the
Readiness
gates
to
be
marked
as
stable
so
before
we
can
trigger
this,
but
we
can
prepare
everything
and
just
wait
for
the
pr
to
be
merged
once
the
values
table
or
since
now
we
have
it
kind
of
feature
flag
or
a
template.
A
A
A
A
I
have
this
function
with
some
parameters,
for
instance
the
channel
in
which
this
message
should
be
sent
and
the
token
to
authenticate.
So
we
know
from
which
user
or
which
user
is
used
to
post
this
message,
so
I
create
this
function
with
these
parameters,
then
I
can
create
follower
up
functions
that
depend
on
this
one.
The
only
thing
that
they
do
are
changing
these
parameters,
so
I
can
reuse
the
same
function
and
just
customize.
It
and
Andre
wants
to
get
rid
of
this
with
mounting
config
map.
A
A
Yes,
because
Andre
wanted
to
do
this
refactoring,
but
then
we
wanted
to
discuss.
Does
this
refactory
make
sense
in
all
the
points
that
you
want
to,
or
not
so
he's
already
working
on
that
he
already
has
a
PR
oud.
That's
why
I
know
about
this
parent
part.
B
A
A
B
Yeah
right
now,
it's
just
implemented
in
a
very
one
key
way,
so
we
should
at
least
try
to
simplify
that
and
look
into
this
how
to
refactor
it
properly.
A
B
A
A
A
A
And
then
migration
guide
I
think
we
are
not
ready
yet
to
refine
this
since
Mac
didn't
finish
to
put
all
the
different
tickets
but
other
information
for
everyone.
Here
we
want
to
create
some
migration
guides,
how
you
can
do
work
in
Captain
V1,
or
how
can
you
migrate
what
you
were
doing
in
captivity,
one
with
instead
doing
the
same
with
klt
and
so
far
we
are
collecting
collecting
use
cases
and
mainly
through
the
slack
I
could
see
people.
It
was
using
Captain
V1
for
deploying
via
our
home
service
and
run.