►
From YouTube: Keptn Refinement Meeting - May 16, 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
Or
a
context
this
morning,
I
discuss
with
the
people
here
in
the
room
about
this
specific
topic
and
I
need
to
bring
up
this
to
the
technical
committee.
This
question,
because
if
you
want
to
support
python
container
runtime
and
node.js,
what
should
be
the
be
the
behavior
if
I
specify
a
function
in
typescript
in
a
function
in
python
and
a
container
shoot
all
of
free,
be
part
of
a
single
caption
task?
A
B
B
So
this
just
needs
to
be
slightly
touched,
but
the
task
controller
is
something
which,
at
the
same
time,
has
the
logic
for
creating
the
job
and
the
logic
to
decide
how
to
fill
in
the
container,
and
these
two
things
should
be
separated
in
a
way
that
the
logic
to
create
the
container
is
then
abstracted
and
we
have
different
one
according
to
the
different
technology
you
want
to
use
for
runtime,
and
this
is
a
bit
of
flim
key
work,
because
the
two
things
are
quite
tied
together,
but
it's
nothing
too
complex.
B
Just
a
bit
tiresome
and
a
few
changes
in
the
main
controller
logic
have
to
be
done,
but
mostly
this
is
in
the.
If
you
click
Giovanni
the
link,
this
would
be
the
job
utils
and
the
function
utils
that
has
to
be
touched
and,
of
course,
tests
need
to
be
adapted
and
integration
tests
should
work
exactly
like
before
without
any
change.
A
A
A
A
E
Exactly
yes,
so
I
was
browsing
through
the
lifecycle
toolkit
operator
code
a
little
bit
and
to
see
how
everything
plays
together,
which
components
are
generating,
which
resources
and
I
found
a
couple
of
potential
issues
that
might
happen
actually
I've.
Also
Illustrated.
This
I'm
gonna
send
an
excalator
link
into
the
chat,
because
this
will
make
it
a
little
bit
clearer.
E
Hopefully,
if
it's
working
yeah
exactly
so.
This
is
basically
just
illustrates
how
everything
plays
into
place
together,
and
this
first
ticket
relates
to
the
to
the
upper
half.
So
to
speak
with
the
first
red
circle,
and
the
problem
here
is
that
recently
we
decided
to
to
limit
the
length
of
the
name
of
the
cabin
app
to
what
is
also
allowed
for
a
kubernetes
object,
meaning
253
characters.
E
Yeah
and
and
now
we
could
have
the
problem-
that
if
we
have
a
application
name
detected
in
the
Web
book-
that's
for
example,
greater
than
253
characters
and
the
captain
workload.
Then
we
immediately
will
have
a
problem
because
the
captain
workloads
will
not
be
able
to
be
created
because
its
name
is
a
combination
of
the
app
name
and
the
ad
controller.
E
E
So
therefore,
we
should
or
I
think
we
can
get
rid
of
these
very
small
naming
restrictions
in
the
Pod
webhook
all
together
and
just
truncate
the
string
or
the
name
of
the
captain
workload
that
we
generate,
but
there's
also
actually
a
dependency
that
we
need
to
resolve.
First
yeah
I've
up
the
formatting
here,
so
this
should
be
hashtag
1425.
E
E
E
A
Okay,
so
and.
E
Good
point
I
think
the
scatter
level
also
need
to
be
checked,
I
think
there.
We
also
retrieve
the
workload
instance.
D
A
E
E
Because
this
is
about
adapting
the
cabinet
version
controller
and
potentially
it's
the
scheduler.
That
was
a
good
point,
because
if
you
go
to
the
to
the
linked
code
here.
E
This
brings
two
problems
with
it.
The
first
one
is
that
it's
not
exactly
the
most
performant
solution,
because
this
way
in
each
reconciliation
Loop,
we
look
up
each
of
the
individual
workloads
by
getting
it
via
a
separate
request.
So
if
you
have
n
workloads
that
are
part
of
the
cabinet
version,
We
retrieve
that
end
times
via
the
API
and
then
the
second
problem
is.
E
If
we
do
truncate
the
name,
then
we
might
run
into
problems
when
we
try
to
access
it
by
the
name
and
therefore
the
solution
I
suggested
here
is
to
instead
use
a
list
request
which
filters
for
the
expected
ad
version
and
spec
dot
version
properties
of
the
workload
instances,
and
this
way
in
each
reconciliation
Loop
to
get
all
of
the
workload
instances
that
are
part
of
the
captain
app
version.
We
would
then
only
need
this
one
list
request,
and
this
then
will
also
avoid
problems
with
names.
Being
truncated.
C
A
C
If
I,
it's
basically
substituting
a
one,
multiple
get
methods
in
a
loop
with
one
list
method,
plus
the
index
Inc,
which
is
I,
think
one
function
to
retrieve
resources
and
adding
one
index
and
one
unit
test
or
a
given
function
with
a
fake,
kubernetes
client.
So
I
do
not
consider
that.
B
E
D
B
E
Well,
because
the
other
ones
was
just
adapting
to
very
tiny
functions,
yeah,
it's
affecting
multiple
components
to
the
the
version
controller
and
the
scheduler,
with
the
additional
indexing
methods
which
all
is
not
very
complex
in
isolation.
But
for
me
it
sums
up
to
be
one
level
higher
than
the
previous
issue.
E
Exactly
here,
we
kind
of
have
the
the
other
way
around
so
right
now.
The
captain
task
controller
has
a
place
where
it
checks
whether
the
job
that
should
execute
this
particular
instance
of
the
task
is
already
created,
and
this
one
it
does
by
sending
a
list
request
with
the
label,
selector
task
name
being
equal
to
the
name
of
the
task,
and
here
we
also
have
some
performance
and
potential
functional
problems
because
performance,
first
of
all,
we're
sending
a
list
request
and
only
ever
expect.
One
object
to
be
to
be
returned.
E
So
therefore,
here
we
could
look
it
up
by
the
name
of
the
task
or
by
the
job
name,
actually,
because
we
do
have
that
property
within
the
within
the
status
of
the
captain
task.
E
So
that's
the
first
thing
and
then
the
second
one,
which
is
a
bit
more
critical,
is
that,
since
we
are
looking
for
a
label
called
task
name
with
the
value
set
to
the
name
of
the
task
object,
this
can
be
a
problem
because
and
the
name
of
the
task
object
can
be
253
characters,
but
labels
are
limited
to
63
and
when
I
was
playing
around
with
the
toolkit.
I'll
run
it
exactly
into
this
problem,
where
I
generated
a
very,
very
long
task
name
and
then
somewhere
during
the
reconciliation
of
the
complete
cabinet.
E
E
And
that's
why
also
we
shouldn't
I
shouldn't,
add
the
task
name
and
also
not
the
app
and
workload
names
as
labels,
because
those
can
all
be
potentially
longer
than
those
63
characters.
And
if
you
do
the
lookup
by
status.shop
name
with
the
get
request,
we
actually
don't
use
those
labels
anymore
anywhere.
A
A
A
B
C
A
D
A
F
I,
have
it
actually
started
coding?
It
like
I,
was
currently
learning
more
about
kubernetes
operator,
like
I
brought
my
first
operator
this
past
two
to
three
days
back
so
I'm
still
exploring
the
code
right
now
and
then
I'll
start
working
on
it.