►
From YouTube: Keptn Community Meeting - July 30th, 2020
Description
Meeting notes: https://docs.google.com/document/d/1y7a6uaN8fwFJ7IRnvtxSfgz-OGFq6u7bKN6F7NDxKPg/edit
Keptn will have a virtual booth at KubeCon 2020 - Aug. 17. - 20.
CNCF Slack Channel: Join here
Good first issues: https://goodfirstissue.dev/ or start here
Keptn mailing list / google group: https://groups.google.com/forum/#!forum/keptn
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.
Andreas:
Describe advanced installation using the Helm chart https://keptn.sh/docs/0.7.x/operate/install/#advanced-install-keptn-using-the-helm-chart
Bridge dropped labels: https://github.com/keptn/keptn/issues/2137 and https://github.com/keptn/keptn/pull/2143/
keptn update project failed: https://github.com/keptn/keptn/issues/2125 and https://github.com/keptn/keptn/pull/2143/
Imre:
Shouri:
Johannes:
Inconsistency in installation setup docs: https://github.com/keptn/keptn/issues/2120
Add data labels for the Keptn Bridge Evaluation done line graphs - keptn.sh/docs update: https://github.com/keptn/keptn/issues/1501 → https://keptn.sh/docs/0.7.x/reference/bridge/#services-view
(in progress) Formulate spec for Shipyard 0.2.0 and implement a dedicated type in the go-utils: https://github.com/keptn/spec/pull/36
Roadmap → KEP / SPEC / Issues
KEP 06: The next generation of Shipyard: https://github.com/keptn/enhancement-proposals/pull/6
Keptn 0.8: Presentation of KEP 06
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
A
A
A
All
the
team
members
of
the
captain
project
are
also
in
the
slack,
so
you
can
also
go
there
to
ask
some
questions
and
you
might
already
know
our
own
slack
channel
it's
on
slack.captain.sh,
so
you
can
also
still
use
this
channel
because
right
now
we
don't
want
to
get
rid
of
it.
Since
we
have
a
couple
of
very
interesting
discussions
already
there
and
we
just
want
to
keep
the
history
of
these
discussions
also
to
be
kind
of
a
hub
for
for
for
answering
questions.
A
You
can
use
the
search
function
to
find
some
questions
and
answers
that
you
might
have
if
you
want
to
get
started
with
the
captain
project.
As
always,
please
go
to
good
good
first
issue,
def
or
click
on
the
link
here
to
go
to
our
github
repository
and
find
good
first
issues,
and
if
you
want
to
stay
up
to
date,
please
follow
us
also
in
our
captive
mailing
list
or
join
us
in
our
google
group,
where
you
can
get
started
and
where
you
can
follow
us.
So
with
this
I'm
already
handing
over.
A
I
guess
this
time
to
andreas
and
yeah.
If
you
have
any
questions
in
the
meantime,
please
put
them
in
the
chat,
otherwise,
we'll
just
go
through
the
list
of
note
words
sheet
noteworthy
issues
and
pr's
and
later
on,
johannes
will
share
a
little
bit
of
the
the
roadmap
for
the
next
generation
of
the
shipyard.
So
please
andreas
I'm
handing
over
well,
please
go
ahead,
and
if
there
are
any
questions
I
will
just,
I
will
pick
them
up
and
throw
them
in
as
they
come.
B
Cool,
thank
you.
So,
as
already
described
last
time,
we
are
now
shipping
captain
as
a
health
chart.
So
that
means
you
can
install
captain
using
a
helm
chart
and,
of
course,
you
can
directly
use
this
hamstrite
in
order
to
install
cabin
and
therefore
I've
added
an
advanced
section
in
our
documentation
which
describes
how
you
can
use
the
hard
cli
in
order
to
install
captain
and,
for
example,
where
the
repository
is
located
of
our
installer.
B
This,
of
course,
now
allows
you
some
advanced
use
cases.
For
example,
you
can
overwrite
your
values
using
the
set
command
so
by
adding
minus
one
set.
You
can
now
overwrite,
for
example,
the
registry
of
all
our
images,
and
this
can
be
especially
handy
if
you
have
an
acad
system
and
for
example,
you
cannot
access
docker
hub
where
usually
our
images
are
located.
B
So
the
second
issue
I
clocked
on
was
a
bridge
issue.
So
now
the
bridge
can
be
used
in
order
to
send
an
approval
finished
event.
That
means
an
approval.
Finished
event.
Is
is
in
the
response
of
an
approval,
triggered
event,
and
this
approval
triggered
event
can
contain
labels.
However,
if
you
used
the
bridge
in
order
to
to
approve
this
approval,
triggered
we
lost
these
labels
here
and
therefore.
B
B
And
finally,
there
was
a
small
bug
in
our
cabin
update
project
command.
This
command
allows
you
to
to
set
an
upstream
afterwards
and
basically,
we
did
not
correctly
link
our
local
branches
with
the
upstream
branches,
and
this
was
also
addressed
in
this
put
request
here.
I'm
basically
setting
the
upstream
and
directly
pushing
it
to
the
upstream
repository,
so
here
I'm
using
the
git
cli
and
make
a
push
set
the
upstream
to
the
upstream
repository
specified
by
the
yuri
and
also
specifying
the
branch.
A
I'm
just
throwing
in
a
question
here
so
rob
was
asking
if
we
now
use
the
cncf
slack
and
not
the
captain
step.
So
actually
we
keep.
We
have
now
the
possibility
to
use
both
slack
options.
So
most
people
still
use
our
own
slack
channel,
which
is
on
slack.captain.sh
because
it's
they
are
already
used
to
it,
and
it
has
a
long
history
already
of
conversations
and
we
don't
want
to
lose
it.
A
But
if
you're
already
part
of
the
cncf
slack-
and
you
also
want
to
interact
with
the
captain
team,
you
can
just
use
the
cncf
slack
and
just
go
to
the
captain
channel
and
it's
the
first
starting
point
to
interact.
We
might
then
ask
you
to
join
our
own
slack
channel.
If
we
already
have
some
similar
discussions
there
that
you
can
also
join,
but
both
ways
are
totally
fine,
so
you
can
go
either
on
slack.cncf.io
and
join
us
there
or
on
slack.captain.sh.
A
D
So
it's
now
time
to
go
over
my
issues.
First
of
all,
I
started
fixing
some
issues
and
some
troubles
in
the
installation
guide.
Imre
was
pointing
out
that
there
were
a
mismatch
between
api
token
and
captain
endpoint.
At
some
parts
we
used
the
term
captain
api
endpoint
and
in
other
parts
we
used
the
term
captain
endpoint
and
now
it's
streamlined,
and
everything
is
now
just
kept
an
end
point
thanks
for
this
close
look
on
the
documentation.
It's
always
good
to
also
get
feedback
on
that,
and
maybe
just
as
a
quick
reminder.
D
D
D
D
It
is
still
in
progress
and
not
merged
yet,
but
instead
of
going
to
this
pull
request
and
then
talking
about
the
specification,
I
will
now
move
on
and
go
over
to
the
road
map,
because
a
very
central
part
of
captain
0.8
will
be
the
new
shipyard
file
and
in
the
next
couple
of
minutes
I
will
tell
you-
and
I
will
explain
you-
how
the
new
shipyard
will
look
like
and
for
you
to
get
started
also
to
think
about
the
new
way
of
of
the
shipyard
file.
Let
me
point
you
to
the
roadmap
of
captain.
D
D
Captain
hartman
proposals
and
40.8,
we
have
now
one
captain
huntsman
proposed
proposal.
We
are
working
on
and
this
is
the
next
generation
of
the
shipyard
here.
In
this
note,
I
I
explain
briefly:
what's
the
end
user
value
of
implementing
this
cap,
but
more
details
can
be
found
in
the
enhancement
proposal
itself.
D
D
D
D
Let's
take
a
look
into
the
production
stage,
for
example,
here
we
have
a
deployment
strategy
that
defines,
on
the
one
hand,
how
a
new
artifact
is
deployed
in
this
stage
and
one
line
below
we
define
that.
We
also
want
to
trigger
remediation
actions
whenever
there's
a
problem
and
well,
we
don't
know
we
do
not
differentiate
between
these
two
workflows.
We
keep
them
very
close,
and
this
makes
it
complicated
and
not
very
well
formulated.
D
Then
there
is
also
a
problem
that,
in
this
version,
we
don't
support
to
add
a
custom
task
to
a
delivery.
Workflow,
it's
not
possible
that
you
can,
for
example,
do
a
migration
step
before
a
deployment
or
to
do
some
kind
of
approval.
After
a
testing
phase,
this
is
actually
not
possible,
and
last
but
not
least,
you
have
also
no
possibility.
D
There
is
no
possibility
to
define
what
is
actually
a
trigger
of
a
workflow
right
now
we
triggered
the
delivery
workflow
with
the
new
artifact
event,
and
the
remediation
workflow
will
trigger
with
a
problem
open
event,
but
there
are
different
kinds
of
events
that
also
should
work
as
a
trigger,
and
this
is
not
possible
to
to
declare
and
those
limitations
yeah.
They
were
the
motivation
why
we
started
to
think
about
a
new
shipyard
version
and
this
new
shipyard
version
is
odot
2
and
it
will
address
the
limitations
that
we
saw
in
1.
D
into
in
the
current
version
and
it's
I
will
now
explain
one
by
one.
What
is
meant
by
that,
and
also
what's
the
the
benefit?
What's
the
user
value
of
the
of
the
new
feature
that
comes
with
the
new
shipyard
and
but
before
we
go
through
the
user
benefits,
I
will
take
a
look
at
the
specification
itself
yeah
on
top
of
a
shipyard
specification.
You
will
now
find
the
metadata
of
this
specification.
It's
just
the
api
version.
D
Then
the
next
property
is
the
spec
property
as
we
are
used
to
or
used
from
kubernetes.
This
is
a
common
way
of
of
then
declaring.
What's
actually
part
of
the
specification
and
the
main
property,
there
is
the
stage
stages
property,
because
here
we
just
say
well,
our
shipyard
consists
of
a
couple
of
stages,
and
this
property
takes
a
list
of
stages.
D
D
D
D
A
Okay,
cool.
We
got
another
question
from
the
community,
the
task
section:
has
it
a
specific
execution
order
and
how
is
the
kind
of
continue
on
error
if
it's
supported
or
not?
How
is
this
working?
The
question
is
from
rob
so
rob
you're
on
the
call.
If
you
want
to
unmute
yourself
and
just
ask
questions
in
your
own
words,.
D
D
C
No,
I
was
just
gonna
say
you
just
for
consideration,
maybe
just
for
you
know,
because
I
know
some
pipelines.
Can
you
know,
depending
on
what
it
is,
support,
parallel
task
execution.
So
just
maybe
a
consideration
as
you're
thinking
about
it.
You
know
there
could
be
some
tasks
that
could
run
in
parallel
and
then
converge.
D
Yeah,
that's
actually
it's
it's
a
point
that
we
also
considered
talking.
While
we
were
talking
about
the
news
new
ship
yet
and
the
answer
to
that
is,
when
you
have
parallel
tasks,
then
you
will
have,
for
example,
two
services,
two
captain
services
that
have
subscription
to
one
particular
event
and
when
this
event
is
sent
out,
then,
for
example,
two
two
captain
services
that
are
for
testing.
They
will
then
start
to
work
and
they
will
then
respond
with
a
finished
event.
And
when
captain
receives
both
finished
events,
then
it
will
go
on.
C
Gotcha
and
right
so
if,
if
we
had
like
a
custom
service,
like
I
know,
like
andy
built
a
you
know,
a
service
that
could
just
call
an
arbitrary
bash
script
right
or
or
some
external
integration
is
that
also
kind
of
envisioned
in
this
too,
like
you
could
have
a
another,
a
task
that
would
call
out
to
something
outside
of
captain.
As
long
as
there
was
like
a
service
that
was
the
intermediary.
C
C
C
D
D
But
it's
just
additional
metadata
to
this
particular
task,
and
you
have
the
flexibility
to
to
add
any
data.
You
want
yeah,
whatever
you
want,
you
can
here
add,
and
then
this
property
will
be
added
to
the
cloud
event,
and
this
cloud
event
will
then
be
sent
over
to
the
recipient
to
the
receiver
of
this
event,
and
then
the
re,
the
recipient,
takes
care
of
of
reading
it
executing
it
depending
on
what
is
implemented.
B
For
example,
currently
our
tests
can
fail,
but
we
after
what's
doing
evaluation-
and
I
guess
this
is
still
needed.
So
even
if
the
tests
fail,
we
go
on
and,
for
example,
we,
the
emulation
triggered
event
is
sent
out
and
the
emulation
service.
The
lighthouse
service
in
our
case
has
to
decide
whether
he,
whether
it
makes
an
emulation
or
not.
C
A
B
D
All
right,
then,
I
will
move
on
to
the
next
slide.
That
brings
me
to
the
first
user
benefit,
because
what
we
now
achieve
with
this
gpu
loader
too,
is
that
we
separate
the
workflows
from
each
other.
We
have
one
that
is
for
delivery.
The
other
one
is
for
remediation,
and
when
someone
wants
to
bring
in
another
workflow
into
a
stage,
then
he
can
define
it
yeah
depending
on
on
his
or
her
needs.
D
Let
me
just
show
you
an
example
again
the
specification
I
have
here
production
stage,
this
production
stage
has
workflows,
and
in
this
case
it's
an
artifact
delivery,
workflow,
the
first
one
and
the
second
one
is
a
remediation
workflow,
and
this
workflow
is
triggered
by
this
kind
of
event.
It's
it's
actually
the
artifact
delivery
from
the
preceding
stage,
which
is
hardening
when
this
one
is
done.
Then
this
one
will
kick
in
and
will
do
its
job
and
the
remediation
workflow.
D
Then
the
second
benefit
is
that
someone
can
bring
in
a
custom
task
to
a
workflow.
Let
me
just
give
you
an
example:
again
we
have
here
a
stage
which
is
called
hardening.
We
have
an
artifact
delivery,
workflow
that
is
triggered
based
on
an
artifact
delivery
from
the
dev
stage,
and
here
in
this
case
the
person
decided
to
do
a
migration
step
at
the
beginning,
for
example,
doing
a
database
migration
from
one
to
another,
and
this
task
can
be
added
to
the
shipyard.
D
And
then,
when
you
create
the
project,
the
shipyard
will
be
used
to
create
the
project,
and
then
captain
knows
that
you
want
to
send
out
a
migration
event
before
the
deployment
should
be
executed,
and
it's
not
limited
to
to
a
certain
number
of
tasks.
You
can
add
as
many
tasks
as
you
want,
depending
on
your
requirements
and
your
needs
and
again
you
can
add
arbitrary
properties
to
each
task,
to
customize
those
and
also
to
provide
more
information
for
the
captain
service
that
is
receiving
this
task.
Or
this
event.
D
E
D
E
D
Right,
okay,
yeah!
What
we
are
working
on
is
the
shipyard
controller
I
will
now.
I
will
explain
at
the
end,
because
the
shipyard
controller
then
takes
care
of
collecting
all
the
data
that
is
coming
back
from
the
services
and
kind
of
accumulating
everything,
so
that
this
approval
step
knows
what
happened
in
the
migration
step
in
the
deployment
step
test
step
and
then
can
do
or
can
provide
this
information
to
someone
who
has
to
do
the
approval.
D
D
Two
customers
customer
ae
customer
b
and
both
customers
have
an
own
environment,
but
they
want
to
get
their
artifact
from
the
pre-prod
environment,
and
this
is
now
also
possible
with
this
new
shipyard
file,
because
what
you
have
to
do
is
you
have
to
define
your
staging
process
for
dev,
hardening
and
pre-prod
and
for
the
stage
production
customer
a
which
is
this
one?
You
just
say
this.
This
is
wrong.
Sorry
trigger
the
artifact
delivery,
when
pre-prod
is
also
done,
and
the
same
is
true
or
the
same
you
have
to
configure
for
a
second
environment.
D
D
C
D
D
F
So
my
question
is
that
for
our
specific
scenario,
we
usually
do
a
lot
of
parallel
deployment.
Just
to
give
an
example
when
to
validate
one
specific
name,
space
in
place
of
one
namespace
validation,
why
are
kept
in
quality
gate
we
validate,
maybe
around
10,
20,
50
or
200,
or
even
500
namespace
with
the
data?
F
What
we
are
right
now
doing
is
that
we
are
running
every
name
space
as
a
separate
pipeline.
Now,
when
you
explain
just
a
bill
before
that,
the
parallel
thing.
We
believe
that
parallel
thing
is
already
there.
But
what
is
your
suggestion
to
handle
this
specific
use
case
because
we
are
getting
a
lot
of
500s
when
we
are
doing
this
process,
which
is
the
normal
quality
gate
process
for
a
name
specialization.
F
D
F
D
F
So
each
name
space
is
exposed
as
a
ingress
endpoint
and
it
has
a
specific
function
to
solve,
which
has
been
executed
by
our
workflow.
Now
that
one
pipeline
is
think
about
that.
You
have
one
service
and
you
are
validating
that
service
with
the
throughput
error
and
the
percentile
now
like
that.
At
the
same
time
you
are
doing
for
50
200
namespaces.
F
F
F
Okay,
so
what
you
are
saying
that
whatever
we
have,
let's
use
that
there
is
no
separate
concept
of
parallelism
of
doing
a
separate
pipeline.
I
my
question
was
mortal
because
you
gave
that
there's
a
way
you
can
do.
Multiple
shipyard
quality
gate
function
in
a
parallel,
but
now
I'm
I'm
hearing
that
yeah.
We
need
to
do
that.
One
is
a
different
use
case
and
what
I'm
asking
is
not
relevant
to
that.
B
D
D
D
D
All
right,
then,
in
the
progress
column,
we
have
one
issue
that
I
created
and
I
will
maintain
it
as
as
a
kind
of
always
open
issue,
because
what
we
experienced
in
our
releasing
process
is
that
the
integration
tests
for
captain
for
the
master
branch
they
are
flaky
because
from
time
to
time
they
fail
and
it's
very
difficult
to
to
understand.
What's
the
reason
because
of
of
the
failing
test-
and
I
will
use
this
issue-
that
we
post
their
findings
in
regard
to
the
flakiness
of
our
integration
tests,
then
andreas.
D
All
right,
cool
and
yeah,
the
same
is
true
for
this
issue.
I
started
to
work
in
the
shipyard,
odor
2
specification.
Also.
I
showed
you
today
how
it
looks
like,
but
still
a
couple
of
tasks
are
necessary
to
get
it
done
and
next
week
we'll
hopefully
show
you
the
outcome
of
that.
One
imra
is
not
on
this
call.
He
worked
on
this
issue,
but
next
time
he
should
give
us
an
update
on
that
one.
D
B
D
D
We
have
now
the
problem
that
scaffold
does
not
work
anymore
on
our
local
machines,
and
this
is
kind
of
cleanup
task
or
it's
not
a
cleanup.
It's
just
getting.
Those
manifests
up
to
date,
so
that
scaffold
is
again
working,
yeah,
test
and
repair
scaffold
and
add
the
kubernetes
labels
to
the
manifests
of
all
services.
D
D
B
B
A
Okay,
all
right,
I
can
also
provide
a
little
bit
of
maybe
help,
because
I
was
also
creating
a
graphing
service
that
is
basically
also
not
installing
grafana
but
just
connecting
to
grapana
and
configuring,
something
in
grafana
like
a
dashboard.
So
we
can
sync
up
on
this.
How
I
did
it?
Maybe
it's
a
very
similar
way
for
prometheus
all.
D
All
right,
then,
when
we
take
a
look
at
the
backlog,
we
see
that
there
are
a
couple
of
red
ones:
that's
not
a
good
indicator!
Yeah.
There
are
a
couple
of
of
bugs
and
and
hiccup
hiccups
in
the
bridge,
and
I
will
take
care
of
talking
with
this
air
airmen
about
those
so
that
we
yeah
get
this
box
fixed
and
to
have
also
a
very
or
a
smoother
experience
when,
when
using
the
the
captain's
bridge,
it's
it's
not,
there
are
not
big
issues.
D
They
are
more
related
to
corner
cases,
but
still
we
need
to
get
them
done
to
have
yeah
a
bridge
that
is
working
perfectly
all
right,
yeah.
I
will
take
care
of
of
discussing
these
issues
with
airmen
and
also
to
define
what
the
outcome
should
be:
yeah,
the
old
bridge
related
and
here
further
down.
We
have
still
one
that
is
labeled
as
good
first
issue
whenever
you
want
to
start
working
with
captain
or
want
to
get
started
with
implementing
your
first
issue.
D
A
C
C
For
example,
for
example,
if
I
was
saying
get
service
I
would
expect
I
could
pass
the
stage
argument
as
an
option,
but
it
seems
like
that's,
not
supported,
and
you
know
it's
it
just
I
think
it
just.
I
tried
to
write
what
I
think
you
wanted
the
requirement
to
be,
and
maybe
that's
a
good
little
grid
to
test
it
just
to
see
if
that's
working
but,
like
I
said
I
I
was
trying
to
say
like
get
service,
my
service
name,
but
it
it
didn't,
support
that
flag.