►
From YouTube: Keptn Community Meeting - October 22nd, 2020
Description
October 22, 2020
Diary - what happened last week?
Continued working on shipyard-controller
Keptn Community Meetings now included in official CNCF calendar: https://www.cncf.io/calendar/
Hacktoberfest - we are part of it as well as contributing.today
Keptn mailing list / google group: https://groups.google.com/forum/#!forum/keptn
Welcome new contributors - please start with a good first issue to make yourself familiar with the project!
Noteworthy Issues & PRs (Review)
For each PR, please tell us if you updated the docs, or in case it was not necessary please say so.
Jürgen
Litmus Service: https://github.com/keptn-sandbox/litmus-service
Johannes:
Explain requirements for execution plane services: https://github.com/keptn/keptn.github.io/pull/665
Roadmap → KEP / SPEC / Issues
KEP 06: The next generation of Shipyard: https://github.com/keptn/enhancement-proposals/pull/6
Work in progress:
https://github.com/keptn/keptn/projects/29
Backlog Refinement / Next Sprint:
https://github.com/issues?q=is%3Aopen+is%3Aissue+user%3Akeptn+user%3Akeptn-contrib+label%3A%22next-sprint%22
Planning Board: https://github.com/keptn/keptn/projects/29
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
A
Over
to
the
cloud-
and
here
we
go
so
welcome
everyone
to
this
captain
community
meeting
yeah
for
today
we
have
prepared
a
couple
of
things.
First
of
all,
I
want
to
welcome
new
community
members
that
are
now
also
finding
us
on
the
cncf
community
meeting
calendar
or
cncf
calendar
in
general,
so
it's
cncf,
dot,
io,
slash
calendar
and
you
will
also
find
the
captain
community
meetings
there.
A
A
I
think
when
you
click
on
more
details,
it
will
open
in
your
own
calendar
and
then
the
time
will
be
the
correct
time
and
yeah.
You
can
subscribe
to
this
calendar,
so
you
never
miss
a
captain.
Community
meeting
hacktoberfest
is
still
going
on.
So
if
you
want
to
contribute
with
with
your
either
code
improvements
or
documentation
improvements,
you
are
welcome
to
do
so.
Please
follow
our
contribution,
guidelines
and
we're
happy
to
see
your
contribution
and
then
eventually
accept
your
contribution.
A
Let
me
just
close
this
well,
I
think
you'll
know
already
about
the
the
mailing
list
that
we
have.
You
will
get
a
weekly
news
directly
into
your
mailbox
and
again
for
all
the
new
contributors.
Please
start
with
a
good
first
issue.
All
of
them
are
tagged
in
you
know,
github
repository,
so
I
think
you
will
find
something
that
fits
your
skill
set
and
please
take
a
look
there.
A
If
you
have
any
questions,
put
it
on
the
put
your
question
directly
on
the
github
issue
or
reach
out
to
us
in
slack,
that's
the
the
two
best
options
and
with
this,
if
we
don't
have
any
announcement
up
here,
I
think
I'm
already
handing
over
to
the
noteworthy
issues
npr's
since
yeah
I've
edited
myself
on
top
of
the
list
I'll
just
go
ahead.
I
won't
show
you
a
pr
to
the
captain
main
repository,
but
I
want
to
briefly
just
explain
what
we
did
in
with
with
litmus
that
should
load.
A
So
litmus
is
a
chaos,
testing
framework
for
chaos,
experiments
for
for
built
for
kubernetes,
and
if
you
want
to
combine
chaos
testing
with
captain
now
you
can
do
this
with
this
integration
and
it
basically
works.
I
think
we
have
explained
it
here.
It
basically
works
that
this
service
will
also
listen
for
deployment
finished
events,
so
at
the
same
time,
when
we
start
performance
tests,
we
also
start
some
chaos.
A
So
after
the
performance
tests
are
finished,
also
the
chaos
will
be
finished
and
then
the
sno
evaluation
will
take
care
of
the
performance
testing
where
all
the
chaos
has
happened,
so
why
you
might
want
to
do
this
is
to
test
resiliency
of
your
applications,
and
we
recommend
that
also
recommendation
from
the
from
the
litmus
team
to
always
do
the
litmus
chaos
testing
when
there
is
some
load
on
your
service.
So
with
captain
you
can
do
this
easily
by
just
adding
the
litmus
service.
A
A
All
you
have
to
do
is
to
also
install
litmus
in
your
cluster.
Obviously,
and
then
add
one
file.
It
has
to
have
the
name
experiment.dml
and
you
add
it
to
the
service
and
the
stage
in
a
particular
project,
and
then
the
captain
legitimate
service
will
find.
This
will
execute
this
yeah.
I
think
that's
the
the
main
part
or
the
the
main
idea
of
the
service.
A
A
That's
a
very
good
question,
so
litmus
they
have
their
chaos
hub
and
any
kind
of
chaos
are,
I
would
say
some
conditions
to
your
microservice
that
you
would
not
expect
something
like
a
pod
will
be
killed
or
there
will
be
ctu
separation
on
on
your
application
or
the
network
will
be
cut
or
the
this
will
be
flooded
with
with
temporary
files.
So
anything
you
actually
don't
want
to
see
in
your
applications
and
the
litmus
framework
will
introduce
this.
A
Yes
exactly
so,
the
idea
is
that
you
trigger
the
deployment
with
captain.
Then
after
the
deployment,
the
tests
will
be
triggered
and
capture
will
trigger
with
this
integration,
two
tests.
First
of
all
the
jmeter
test
that
will
execute
some
load
and
then
the
chaos
test
in
our
experimentations
and
in
our
development
phase.
A
We
always
did
the
delete
pod
chaos
experiment,
so
it
was
always
deleting
a
pod
from
the
microservice
that
we
tested
and
then
we
could
do
the
sla
slo
evaluation
afterwards
and
just
depending
on
how
fast
the
pod
could
come
up
again
or
how
often
the
pod
has
been
killed.
We
can
then
see
in
the
slow
evaluation
if
we
still
meet.
C
A
A
So,
for
example,
we
are
if
the
the
service
cannot
survive.
If
one
pot
will
be
killed
and
we
cannot
meet
our
slos,
what
we
could
do
is
we
could
just
increase
the
replica
set
by
one
or
by
10
by
50
whatever,
and
then
run
that
experiment
again.
If,
if
we
then
survive,
we
know
we
have
increased
the
resiliency
of
our
application
and
even
though,
if
in
our
production
environment
one
part
will
be
killed
within
a
time
frame
of
two
minutes,
our
application
will
still
satisfy
the
slos,
so
we
can
find
out
what
we.
A
Yeah,
I
think
it
will
be.
The
scenario
will
be
more
to
execute
chaos
together
with
your
performance
tests
and
then
find
out
what
are
the
slos
that
are
failing.
Maybe
the
response
time
is
still
good,
but
maybe
it's
the
error
rate
that
will
be
failing
and
then
you
you
can
tweak
your
application
and
tweak
the
settings
of
your
help,
charts
or
whatever
to
to
satisfied
slos.
Although
you
have
chaos,
I
think
that's
that's
one
of
the
use
cases.
B
All
right
yeah
what
the
thing
the
pull
requests
are.
The
issue
that
I
have
to
share
today
is
regard
is
in
regard
to
the
documentation
and
there
we
want
to
explain
the
requirements
for
a
cap
for
a
captain
service
that
is
running
on
in
the
execution
plane,
and
actually
this
pr
is
not
finished
yet,
as
I
need
a
review
from
someone
of
the
community,
but
still,
let's
just
take
a
look
at
the
documentation
so
that
you
get
also
an
understanding.
B
And,
as
we
see
here
in
this
introduction,
we
consider
a
captain
service
as
the
generic
format
of
any
service
that
is
running
in
the
execution
plane.
And
then
we
do
have
two
very
specific
captain
services
that
are
the
sli
provider
and
the
action
provider.
The
sli
provider,
as
you
know,
is,
is
required
for
fetching
a
slice
from
an
for
a
monitoring
solution
or
a
testing
framework,
and
the
action
provider
is
an
action
that
is
executed
as
part
of
a
remediation
workflow.
B
But
those
are
just
two
specific
services
that
follow
the
same
pattern
as
any
other
captain
service,
and
what
I
have
done
now
is,
first
of
all
make
a
reference
to
our
template
repository
where
you
can
get
started
to
write
your
own
captain
service.
This
is
the
captain
service,
template
minus,
go
and
in
there
you
will
find
a
development
manifest,
which
contains
two
kubernetes
resources.
B
B
E
A
The
bold
parts
here
like
in
this
four
bullet
item
list-
the
bold
parts-
are
the
ones
that
I
have
to
touch
when
I
do
the
integration
or
are
these
the
ones
that
are
actually
already
provided,
because
the
function
of
processing
the
functionality
basically
number
three.
I
have
to
do
right
right,
yeah
and.
B
I
those
are
explained
further
down,
but
very
good
question
and
the
bold
items
they
are
prepared
for
you.
There
is
the
distributor
and
I
will
then
explain
how
to
change
this
distributor.
To
subscribe
to
an
event,
then
in
the
template
there
is
a
function
that
allows
you
to
send
the
started
event.
Then,
in
the
template,
there's
also
a
function
to
send
a
finished
event,
but
the
third
step
yeah.
C
B
C
D
D
A
C
I
think
that's
a
good
question,
because
if
you
just
want
multiple
events,
you
can
have
a
comma
separated
list
as
far
as
I
know,
but
if
you
want
all
events,
I'm
not
sure
if
it's
that
easy,
because
we
have,
we
have
a
new
set,
the
triple
or
even
quadruple
of
events.
Now
we've
triggered
finished,
started,
etc,
and
you
wouldn't
want
to
listen
to.
I
don't
know,
started
events
if
you
just
want
to
have
the
finished
events,
so
this
might
be
something
we
need
to
consider
in
the
distributor.
C
C
C
C
A
B
A
A
A
And
for
because
I
I
I
was
working
with
the
litmus
team
and
we
were
thinking
if
it's
possible
to
also
include
some
information
if
from
the
litmus
tests
itself.
So
when
we
know
the
litmus
tests
have
finished,
then
we
might
want
to
send
some
information
back,
maybe
a
score
so
that
we
would
say
status
is
succeeded
without
this
pass
and
the
litmus
score
or
some
some
other
information.
Yeah.
B
C
C
B
C
C
Like
let's
say
I
don't
know,
you
execute
something
like
you
sent
a
message
to
somewhere
sending
the
message
per
se
might
have
succeeded.
Obviously,
but
you
don't
know
if
it
actually
was
retrieved
and
then
the
result
is
passed
or
failed.
I
mean
like
the
status
unknown
is
what
what
puzzles
me
a
little
bit
yeah.
So
maybe
status
unknown
can
still
result
in
a
pass
or
failed.
C
B
B
C
C
B
All
right,
yeah
then
like
sending
a
started
event,
you
can
also
send
a
finished
event
directly
to
the
event
endpoint
of
captain
or
using
the
distributor,
and
here
I
just
explain
you
know
very
shortly-
how
to
deploy
your
captain
service
based
on
the
deployment
manifest
that
I
recommend
to
use
from
the
service
template
all
right.
There
was
a
very
good
review
round
with
a
couple
of
things
I
have
to
change
and
I
will
do
those
changes
tomorrow
or
next
week
and
then
we'll
ask
someone
to
give
me
a
final
review.
B
B
D
Exactly
so
in
version
0
8
we're
going
to
introduce
a
new
format
for
the
shipyard
file
and
obviously
we
had
to
adapt
the
captain
backhand
services
and
the
cli
to
be
able
to
create
projects.
Using
that
new
specification
and
in
the
course
of
implementing
this
issue,
we
also
refactored
a
lot
of
things.
So
basically,
we
moved
the
http
endpoint
for
creating
and
deleting
and
updating
projects
and
services
from
the
api
service
to
the
new
shipyard
controller,
because
creating
projects
is
done
by
a
shipyard.
D
So
it
made
sense
to
do
that
here
and
we
also
change
the
way
we
are
communicating
with
the
cli
so
for
the
create
project
and
create
service
command.
We
do
not
have
a
websocket
communication
anymore,
but
we
will
immediately
send
back
the
response
and
the
result
of
the
crate
or
delete
operation
by
the
http
response,
so
the
cli
gets,
or
it's
a
little
bit
easier
for
the
cli
and
also
for
other
clients
that
use
the
http.
B
B
B
B
Then
all
the
logs
of
your
automation
will
then
contain
the
sensitive
information
and
I
proposed
to
use
or
to
introduce
a
flag
which
is
called
height,
sensitive
data.
And
whenever
this
flag
is
added
to
the
captain
install
command,
then
the
output
should
not
be
visible,
and
this
gives
us
then
the
chance
to
to
use
this
captain
install
command
and
and,
for
example,
in
travis
and
and
other
automation
tools.
C
A
D
B
D
This
is
about
extending
the
mongodb
data
store,
with
the
possibility
to
invalidate
events
so
most
specifically
evaluation
events
such
they,
so
they
don't
get
compared
with
the
current
evaluation
anymore.
In
case
they
have
been
invalidated.
So
what
I've
done
here?
I've
added
a
new
endpoint
to
the
mongodb
data
store
that
allows
to
retrieve
events
of
a
certain
type
and
with
the
option
to
exclude
events
that
have
been
invalidated
so
that
in
further
consequence,
will
be
used
by
the
lighthouse
service,
for
example,
when
it
fetches.
The
previous
evaluation
results
to
compare
the
current
evaluation
with.
B
B
And
yeah
he
even
provided
a
fix
for
that
and
he
also
used
a
couple
of
unit
tests
to
to
validate
this
fix.
And
let's
just
have
a
look
here.
For
example,
when
you
have
a
domain
with
bridge
dot
demo
dot
captain.sh,
then
the
bridge
was
not
loading,
but
with
his
change
he
now
is
able
to
to
get
the
correct
base
url.
I
think.
C
B
F
F
B
C
Guys
so
the
fix
was
done
by
a
contributor
he
has
removed.
First
of
all,
he's
removed
it
from
the
root
command.
We
will
have
to
reintroduce
it
in
a
different
way,
although
later,
because
we
want
the
version
check
in
the
root
command,
it's
to
some
extent
yeah,
but
not
to
what
it
was
before
and
most
importantly,
he's
introduced
a
timeout
as
you
can
see
here.
B
C
A
We
have
some
attendees
also
in
this
community
meeting
that
might
have
some
questions,
especially
sorry,
if
the
name,
if
I
pronounce
it
not
not
correctly,
he
would
have
some
questions
so
please
make
sure
that
during
this
meeting
you
also
have
some
some
time
to
to
address
these
questions.
Johannes,
I
will
give
you
the
host
of
this
meeting.
Okay.
So
then
you
can
later
on
unmute,
theta
or
tithe,
and
he
can
follow
up
with
you
with
the
questions.
B
C
C
If
you
send
a
new
artifact
and
you
use
docker.io,
we
always
check
for
the
whether
the
image
and
the
tag
exists,
but
if
you
don't
use
docker.io
and
you
just
use
like
in
the
second
example,
the
captain
examples
cartoon
cards
image
with
a
tag
that
does
not
exist,
which
I
provoked
here,
then
you
end
up
having
a
websocket
connection
timeout
in
the
cli,
so
the
websocket
connection,
timeout
itself
is
not
the
issue
that
might
happen
all
right.
It's
it's
like
not
good,
but
it
might
happen.
C
But
the
actual
issue
is
that
helm
service
hangs,
so
it
completely
hangs
itself
up.
It
just
keeps
running
in
an
infinite
loop
in
that
process.
I
think
it's
multi-threaded,
so
it's
not
a
big
deal,
but
if
you
send
let's
say
100
such
events
into
the
cluster
you'll
have
100
processors
that
have
an
infinite
loop.
C
But
if
none
of
this
happens,
this
just
runs
in
an
infinite
loop
forever,
and
this
is
as
far
as
we
debug
it.
This
is
what
happens
and
I
think
we
need
some
more
debugging
into
it,
but
we
also
definitely
need
a
limit
here,
maybe
two
minutes
or
three
minutes
at
a
top
that
we
can
exit.
I
wanted
to
mark
this
as
a
good
first
issue,
but
I
think
it's
a
little
bit
more
involved,
but
if
you
have
some
experience
with
the
helm
service,
this
should
be
rather
easy
to
fix.
C
C
C
C
C
C
F
B
C
All
right
so
the
next
one
I
think
it
was-
was
it
ankit,
maybe
who
actually
brought
it
up
initially
or
actually.
I
think
it
was
another
contributor
that
brought
it
up
that
helped
us
with
the
q
and
e.
This
1.19
support,
who
said
the
distributor
is
crashing
on
the
master
branch
for
the
api
service,
and
the
reason
for
that
was
that
we
left
the
pub
sub
topic
empty
on
purpose
in
the
distributor,
because
the
distributor
serves
as
a
side
car
to
also
connect
to
our
nuts
cluster.
C
So
by
removing
the
distributor
we
fixed
the
crashing
of
the
of
the
pot,
obviously,
but
we
also
removed
functionality.
So
the
api
can
no
longer
send
messages
to
the
event
broker
turns
out.
There
is
a
bug
in
a
distributor
or
yeah.
We
didn't
label
this
back,
but
there
is
apparently
a
problem
in
the
distributor.
If
you
don't
have
a
subscription
topic,
it
just
fails
and
florian
has
written
the
description
here
brought
it
up
as
well.
C
We
need
the
distributor
needs
to
be
able
to
to
run
to
send
events
without
having
to
subscribe
to
events,
and
it
needs
to
be
able
to
be
done
simultaneously.
I
think
that's
already
possible,
I'm
not
sure
why
it's
in
there
and
eventually
the
distributor
needs
to
be
re-added
into
the
manifest
of
api
service
in
the
installer
folder.
E
Yes
today
today
is
better
outside
yeah.
You
can
come
in
number
two.
Yes,
so
I
picked
this
issue.
Well,
I
don't
have
too
much
experience
doing
this,
so
I
just
wanted
to
trying
to
use
it
to
build.
You
know
find
what
to
do
so.
I
I've
been
looking
at
this
issue
since
yesterday
trying
to
figure
out
what
to
do.
I've
checked
the
code,
so
I
figured
that
you
you.
E
E
E
You
know
so
the
the
the
taxes
for
me
to
be
able
to
call
these
functions
this
in
a
good
routine
and
this
other
yeah
both
in
the
go
routine.
Well,
I
really
didn't
figure
out
how
to
do
that.
You
know
seeing
that
this
is
already
called
in
the
main
main
function
to
you
know
and
the
the
pro
the
idea
is
to
make
sure
both
of
them
are
done
in
a
go
routine
using
the
sync
group,
so
I've
been
working
on
that
trying
to
figure
out
how
to
get
that
working.
E
Events
for
a
certain
topic
coming
from
that
or
the
api
is
in
the
main
routine,
why
the
http,
10
points
for
listening
is
certainly
nicole
routine,
so
I
should
make
sure
that
both
of
them
are
in
a
separate
go
routine
as
part
of
a
single
weight
group.
I
understand
how
to
do
this.
Well,
looking
at
the
the
current
code,
both
of
them
are
working
okay
in
the
same
function.
So
this
is
the
one
talking
to
the
captain
api,
and
this
is
the
other
main
function
right
here.
What
is
that?
A
A
A
A
C
F
C
E
A
C
E
E
B
No
okay,
yeah
feel
free
to
reach
out
to
us
buyers
like
cool,
then
I
will
move
it
over
and
here
I
have
one
issue
that
is
related
to
the
bridge
and
to
the
integrations
page
because,
but
what
we
forgotten.
What
I
forgot
in
my
last
proposal
about
the
integrations
page
was
that
we
also
need
to
listen.
No,
not
listen.
B
C
C
Yeah,
so
we
got
a
heads
up,
but
that
dynatrace
is
changing
the
ui
for
the
api
token
generation
to
separate
a
little
bit
the
old
api
endpoints
from
new
api
endpoints
and
to
improve
the
usability,
and
I
got
this
screenshot
and
this
is
going
live
in
the
next
couple
of
weeks.
As
far
as
I
was
as
I'm
aware,
so
we
need
to
update
our
documentation
as
well,
because
we
have
the
old
screenshots
so
yeah.
This
screenshot,
however,
is
not
the
right
one.
C
C
D
B
What
it
means
is
that
we
need
to
make
them
aware
of
the
new
cloud
events,
1.0
format
and
in
case
they
listen
to
certain
events,
then
we
also
need
to
update
captain
services
to
send
out
the
corresponding
started
and
finished
event
yeah
here.
This
issue
is
a
major
issue
that
just
provides
the
summary
of
all
the
pull
requests
that
are
of
all
the
issues
that
are
spread
across
the
different
repositories
when
you
want
to
get
started
or
when
you
have
some
time
and
want
to
work
on
that.