►
From YouTube: Keptn GitOps Working Group Meeting, Apr 28, 2021
Description
Review of the GitOps in Keptn projects and open issues/priorities.
Meeting notes: https://docs.google.com/document/d/1Hu2o8-GwZmX39o7zP9UFAnlBxePNk9245wyyuu3sM64/edit?usp=sharing
A
A
So
we
have
a
first
meeting
of
the
github's
working
group
for
captain
and
the
idea
today
is
to
just
do
a
deep
dive
into
the
stories
we
have
so
captain
guitar
separator
and
just
captain
operator,
which
is
a
foundation
story
for
that
cap7.
The
which
is
at
remove
stages,
which
is
also
a
kind
of
table,
stake
feature
if
you
want
to
have
it
integrated
and
basically,
whatever
you
have
around
the
stories,
including
integrations
design,
features,
etc,
etc.
A
So,
basically
it's
just
an
open
sync
up
and
let's
see
how
it
goes
and
maybe
one
item
I
would
like
to
start
from
just
to
get
a
quick
start,
just
update
on
the
way
we
stand
with
a
captain,
github
separator,
so
that
everyone
is
up
to
speed.
So
maybe
thomas,
if
you
could
take
this
part,
it
would
be
awesome.
C
So
currently,
I
think
this
has
the
version
number
zero,
one,
zero,
three,
seven
or
whatever
so
very
stable
at
the
moment,
but
nevertheless
I'm
using
it
for
for
my
own
pocs
and
try
to
make
it
better
and
it
works
pretty
well
in
the
meanwhile.
So
also
adam
tried
to
try
to
be
to
work
with
this.
I
think
he
he
hit
a
lot
of
part
of
parks
with
the
pre-released
three,
which
are
which
are
honestly
fixed
in
the
meanwhile.
C
C
C
A
second
thing
regarding
keytop
switch
came
out,
but
this
is
the
other,
the
other,
the
other
side
of
the
github
of
the
of
the
is
the
is
to
integrate
captain
into
integrated
tools
in
captain.
So
I
think
this
was
the
one
thing
you
mentioned
before,
like
regarding
the
gsoc
project
and
yes,
they
are
yeah.
We
are
also
working
on
on
an
approach
for
that,
so
integrating
via
events
or
via
notifications.
I
think
brad
also
did
some
work
around
this.
C
A
One
of
the
interesting
questions
is,
let's
say,
optimistic
timeline,
so
mine
is
sending
that.
Currently
we
have
captain
github's
operator
in
preview,
so
anyone
is
welcome
to
evaluate
it
and
probably
need
to
somehow
facilitate
it.
But
what
is
our
pass
from
the
current
preview
to
jay?
So
how
would
you
see
this
progress?
What
would
be
the
ut
from
your
side
and
what
are
we
missing
on
this.
C
C
A
I
think
that
your
assessment
is
right,
so
we
need
much
more
users,
much
more
feedback
and,
at
the
same
time
we
can
stay
in
preview
indefinitely
at
the
moment.
So
until
there
are
users,
basically,
we
have
no
need
to
switch
to
g
so
yeah.
There
might
be
some
interest
from
our
vendors
like
dana,
trace
or
kirotec
to
get
it
in
jee
quickly,
but
from
the
community
standpoint
stan
can
preview
we're
doing
a
few
rounds
of
reviews.
D
A
Share,
okay,
I
keep
saying
about
70,
so
if
you
think
that
I
over
emphasize
this
story
in
the
discussion,
please
let
me
know
yeah
just
well
for
me,
it's
an
architectural
problem
which
definitely
creates
a
massive
impediment
for
githubs
and
actually
any
kind
of
configuration
management
wish.
It
was
just
githubs.
D
They
all
store
their
configuration
in
india,
but
with
current
discussions
and
and
current
enhancement
proposals,
this
role
of
git
might
change
in
the
future
and
in
the
couple
of
in
the
next
couple
of
minutes,
walk
you
through
the
discussion
process
that
is
currently
ongoing
and
how
git
will
change
for
the
end
user.
And
why
is
this
important
for
you,
because
yeah
or
in
this
group
the
discussion
about
the
githubs
operator
ongoing
and
therefore,
at
the
end,
you
need
to
interact
with
a
geek
prize
approach.
D
But
nevertheless,
what
I
want
to
point
out
is
that
the
git
repository
that
using
might
not
be
the
target
repository
of
an
operator,
and
why
why
this
is
the
case.
I
would
yeah
explain
you
now
in
a
couple
couple
of
minutes
and
the
entire
discussion
or
the
the
switch
and
the
perception
of
the
good
repository
started,
always
the
easy
task
or
easy
enhancement,
proposal
of
adding
and
removing
a
stage
as
we
iterated
over
that
enhancement
proposal.
We
then
figured
out
that
we
need
to
change
the
way
captain
is
working
with
this
git
repository.
D
And
this
is
now
the
content
of
my
presentation.
I
would
step
by
step,
walk
you
through
the
different
enhancement
proposals
and
also
the
ideas
that
were
discussed
and
came
out
here,
just
a
summary
of
of
the
caps
and
end
links
to
the
caps
on
github.
But,
as
I
said
before,
we
will
start
with
the
enhancement
proposal
of
adding
and
removing
a
stage.
D
Cap
70.,
pretty
straightforward
or
the
idea
is,
as
a
captain
user,
I
would
be
able
to
add
a
stage
after
I
created
my
project,
because
this
is,
as
of
today,
not
possible.
It's
just
done
the
stage
creation
when
you
initialize
a
project,
but
once
the
universe
is
initially
initialization
is
happening
or
is
finished,
then
you
cannot
add
any
additional
stage,
and
here
just
give
you
an
idea
in
this
picture.
I
would
like
to
add
a
new
stage
which
sits
in
between
depth
and
hardening.
D
D
Then
we
again
run
into
the
same
problem
that
this
is
not
possible,
because
then
we
don't
have
any
other
branches
available
or
any
other
git
dependent,
modeling
element
and
so
actually
a
blocking
blocking
road.
When
we
go
some
branches
going
forward-
and
the
second
pain
point
is
that
we
also
have
some
captain
entities
as
part
of
the
the
database
we're
also
managing
those
in
the
database,
and
here
some
alignment
needs
to
happen
in
code
and
what
we
did.
D
At
the
end,
it
was
a
table
that
compares
the
current
branch-based
approach
with
the
folder-based
approach
and,
as
you
can
see
here
in
this
screenshot
yeah
on
the
left
side
for
a
branch-based
approach,
there
are
quite
a
lot
of
red
crosses
yep,
since
we
identified
more
disadvantages
than
advantages
when
we
stay
with
this
model
and
on
the
other
side
on
the
right
side.
Yeah.
D
D
Now,
before
going
to
the
next
cap
enhancement
proposal,
which
focuses
on
the
restructuring
of
of
the
of
the
or
which
focuses
on
switching
from
branches
to
folders,
I
just
want
to
summarize
that
the
captain
enhancement
proposal
of
adding
and
removing
a
stage
can
and
should
at
the
end,
allow
someone
to
add
a
new
stage
and
to
remove
a
stage
from
a
project
and
the
way
we
envision.
That
is,
by
updating
the
shipyard
file.
D
First,
you
add
that
you
want,
or
you
take
the
the
current
existing
one
out
of
the
shipyard
file,
and
then
you
do
a
captain
update
project
with
the
new
shipyard
or
you
directly
use
the
api
endpoint,
which
then
also
does
the
the
update
for
you.
This
is
just
to
sum
up
this
cap
enhancement
proposal.
The
way
the
end
user
should
then
work
with
for,
for
this
particular
use
cases.
D
D
D
Oh
yeah,
I
already
explained
their
high
level
structure
and,
as
I
said,
this
is
a
proposal
and
also
needs
an
iteration
and
double
checking,
especially
a
double
check
against
other
solutions
like
helm
or
customize,
because
these
two
tools
they
have
already
solved
this
problem.
They
have
a
very
nice
way
of
storing
configuration,
also
for
yeah,
kunitis
apps
and
then
also
for
different
variants
and
environments
and
so
on,
and
here
we
need
to
double
check
whether
our
idea
also
holds
and
is
aligned
with
with
the
ideas
that
other
tools
are
doing.
D
And
here
I
have
an
example
where
I
then
added
two
services
to
this
folder
here,
it's
the
card
service
and
the
payment
service
which
are
underneath
the
services
folder
and
then
my
example
from
before.
We
have
a
dev
staging
and
production
stage
and
they
live
in
this
stages.
Folder
and
configuration
which
is
in
the
state
in
the
stages.
Folder
is
the
default
for
all
services
in
there
and
the
most
specific
config
lives
very
close
to
the
service
itself,
which
is
then
in
this
particular
service.
D
D
All
right
yeah,
this
was
kind
of
a
quick
run
through
cap
81,
where
the
the
overarching
goal
is
that
we
get
rid
of
the
branching
and
take
the
the
content
from
the
branch
and
represent
that
represent
it
in
a
more
flat
way
in
just
using
folders
and
directories
again.
This
is
a
break
point
for
me
and
I
want
to
ask
if
there
are
questions
so
far.
A
C
And
currently
we
are.
We
are
pushing
the
artifacts
to
the
upstream
repository
in
a
very
in
a
very
clunky
way,
to
be
honest
and
cap82
would
would
make
this
prettier
and
on
the,
on
the
other
hand,
a
bit
better
user
brand,
better
integratable
for
for
captain
itself,
because
then
we
would
not
have
to
deal
with
the
upstream
repository
in
the
operators
and
could
only
interact
with
the
captain
api.
D
D
Just
here
an
example
in
case
I
would
like
to
trigger
delivery
and
staging.
Then
captain
takes
a
look
into
the
git
repository
fetches.
The
last
commit
which
is
then
here
this
one
and
adds
this
kit
commit
to
the
event
payload
and
then
other
services
can
take
this
git
commit
and
then
use
it
as
a
reference
to
fetch
the
the
correct
configuration,
and
here
we
have
the
problem
that
we
are
always
taking
the
head
and,
let's
just
say,
someone
did
an
update
on
config
or
also
manipulated
it
in
some
way.
D
D
Then
the
bridge
is
smart
enough
to
take
this
information
and
to
display
it
at
certain
points.
But
this
is
more
hacky
and
and
not
that
sophisticated
and
hence
also
some
cleanup
needs
to
happen
in
this
direction
and
yeah.
The
solution
journey
would
look
as
follows
that
we
basically
introduce
a
version
as
first
class
citizen
property
in
an
event
payload
next
to
project
service
and
stage.
I
have
my
version
property
followed
by
a
value,
and
this
is
then
used
by
captain
for
versioning
of
artifacts,
as
well
as
for
triggering
deliveries
based
by
diversion.
A
D
C
D
A
Also
yeah,
if
you
talk
about
the
images,
so
one
of
us
cases,
probably
that
as
a
part
of
one
sequence,
you
deploy
multiple
images
which
may
have
multiple
versions
so,
for
example,
one
for
linux,
one
for
md64,
one
whatever
so
a
bunch
of
tags.
So
so
basically
it's
one
project,
one
service,
but
multiple
versions
been
deployed.
A
D
That's
a
good
question.
Actually,
I
have
never
thought
about
this
use
case,
but
at
the
end
I
would
in
captain.
I
would
then
model
it
a
little
bit
different
to
have
really
then
dedicated
services,
one
for
linux,
one
for
windows
and
so
on,
even
though
they
have
they
are
the
same
service,
but
just
in
different
variations,
then
having
them
yeah
divided
into
multiple
services,
and
then
each
of
each
service
gets
its
own
version
again
unique
version
number,
because
having
here
a
list
of
versions
might
be
quite
of
a
challenge.
B
D
All
right,
then,
just
briefly
to
this
picture,
because
it
highlights
the
solution
journey.
We
have
in
our
mind-
and
here
let's
get
started
with
the
ci
part,
because
dci,
all
the
time
yeah,
builds
up
tests
and
uploads
the
artifact
and
well.
In
this
step,
we
would
like
to
have
that
the
ci
also
tells
us
the
version
of
the
artifact
which
was
currently
built
and
therefore
it
then
can
post
on
on
the
captain
api.
D
The
config,
which
was
produced
or
the
artifact
can
be
a
helm
chart,
can
be
a
customized
template
and
so
on,
to
which
service
it
belongs,
as
well
as
the
version
it
belongs
and
with
d3
at
attributes.
We
are
then
taking
the
the
config
and
then
storage
git
in
the
first
run.
Therefore,
we
already
have
this
resource
service
which
talks
to
git
and
then
stores
it
in
the
git
repository
in
the
git
repository.
D
All
right
so
far
we
have
talked
about
the
ci
is
pushing
artifacts
to
captain
which
are
versioned
and
then
at
the
end,
are
some
were
stored
and
when
then
a
person
decides
to
to
trigger
delivery.
The
only
information
this
person
knows
is
the
version
number,
because
at
the
end
the
git
committee
is
hidden
and
not
accessible
by
the
user.
D
All
right
yeah,
this
is
the
the
overarching
picture
of
of
also
using
git,
and
this
will
then
change
the
role
of
git
in
captain,
because
the
captain
ap
api
will
hide
the
git
repository.
Everything
will
be
hidden
behind
the
api
and
no
user
will
interact
with
the
git
repo
anymore.
It's
just
captain
who
will
then
upload
artifacts
and
also
pick
those
artifacts
by
a
certain
version.
D
Number,
as
I
said,
skit
will
also
then
change
and
become
more
like
an
artifact
store,
which
is
then
managed
by
git
per
captain
only
and
when
it
comes
to
the
github's
approach-
and
this
is
also
the
reason
why
talking
today
in
this
group
here,
we
should
really
focus
on
on
cap
67,
which
is
the
proposal
for
introducing
real
git
tops
in
captain
and
having
it
really.
The
way.
Also
others
see
sigitups.
D
I
haven't
mentioned
that,
but
here
in
the
summary
slide,
I
have
it
this
bullet
point,
because
the
update
of
the
configuration
which
happens
here
by
this
by
the
ci
this
can
or
should
be
like
a
pulse
operation,
meaning
we
take
the
entire
set
of
files.
We
would
like
to
update
and
not
syncing
files
anymore.
D
The
kit
operator
is
just
the
only
component
which
then
interacts
with
the
the
repos
on
the
on
the
user
side.
This
can
be
the
code
repository
or
configuration
repository,
but
it's
not
working
with
the
captain
internal
repo
anymore,
because
it's
not
the
intention
is
not
to
have
their
custom
resources.
B
B
C
C
So
this
was
the
reason
why
they
could.
There
were
some
things
created
like
the
promotion
service
and
other
operators
to
to
allow
exactly
exactly
these
things
and
by
acting
away
this,
so
the
one.
The
one
idea
of
the
whole
approach
we
have
now
was
that
the
captain
upstream
repository
is
is
some
kind
of
file
storage,
so
it
doesn't
have
to
be
kit.
C
It
should
not
even
be
to
be
honest,
so
it
should
be
s3.
It
should
be
a
file
system,
it
should
be
an
artifactory
or
whatever,
but
it
it
should
not
even
be
kit
and
this
the
truth
for
other
developers
should
be
on
the
left
side.
So
they
should
have
a
real
detox
repository
where
the
the
real
current
state
is
stored.
C
So
I
think
we
can
avoid
a
lot
of
failures
and
can
clarify
the
way
how
how
captain
works,
because
currently
at
the
moment
the
people
think.
Yes,
I
have
a
key
repository.
I
can
put
in
some
thing
whatever
I
want,
but
in
reality
it's
not
more
than
an
internal
storage
of
cable,
and
I
think
this
is
a
very
important
stuff
thing
in
this.
In
this
whole
topic,.
D
Thanks
thomas
for
jumping
in
I,
you
answered
the
question
perfectly
really
nothing
to
add
from
my
side,
except
of
one
thing.
Actually,
we
are
not.
I
think,
from
my
point
of
view.
We
are
not
introducing
more
complexity.
Actually,
we
take
away
complexity
because,
right
now
we
kind
of
give
the
impression
to
the
user
that
you
can
work
with
the
git
repository
that
is
linked
to
your
captain,
but
whenever
changes
are
done
in
there,
they
are
not
automatically
synced
and
really
not.
There
is
no
trigger
that
takes
the
change.
D
A
D
The
idea
is
that,
yes,
we
have
it.
Yes,
it
will.
No,
it
will.
No,
it
will
be
no
breaking
change
because
we
will
run
both
solutions
in
parallel
for
a
couple
of
versions
and
to
have
a
migration
strategy
on
project
level,
so
that,
from
an
end
user
point
of
view
and
also
in
the
bridge,
you
can
hit
a
button
which
says,
transfer
the
old
format
into
the
new
one,
and
once
this
is
once
this
happened,
the
migration
is
done
and
you
cannot
switch
back.
I
mean
they
will.
This
option
is
not
for
right.
D
A
D
D
A
A
A
I
mean
okay,
so
in
any
case,
this
is
something
that
we
will
need
to
mention
in
the
upgrade
guide,
so
whether
we
consider
it
as
a
breaking
change
or
not.
Well,
I
would
argue
it's
breaking
for
some
use
cases
for
those
who,
like
scripting,
doing
full
whatever
configuration
management
outside
github's
approach
but
yeah,
I
think
it
will
firstly
need
documentation
and
the
rest
is
rather
a
topic
for
discussion.
C
A
Okay,
so
this
is
something
I
can
capture
on
the
roadmap.
I
guess
I
will
still
need
to
create
roadmap
items
for
new
caps,
etc,
but
since
I'm
tampering
with
the
roadmap
anyway,
I
will
do
it
probably
just
with
for
2.0,
because
I
don't
see
much
sense
in
maintaining
the
all
the
roadmap
after
the
community
discussions
but
yeah
well,
it
means
that
they
will
also
need
to
update
the
documentation
eventually,
because
right
now
we
point
to
the
old
road
map
and
github
doesn't
offer
any
immigration
ways.
A
A
A
Yeah,
so
I
guess
thomas
will
be
speaking
about
it
at
the
gitobscon
anyway,
some
extent
so
maybe
having
a
new
road
map
et
cetera
shopping.
What
we
actually
do
would
be
useful
for
the
conversation,
but
whether
we
need
additional
meeting
for
that.
I
don't
think
so
and
it's
a
question,
but
when
everyone
has
time
actually.
C
So
I
just
wanted
to
reach
out
and
talk
to
brad
in
the
next
few
months,
a
few
weeks,
because
I
think
you
created
some
integration
into
argo
based
on
based
on
with
captain,
and
I
also
think
this
might
be
relevant
for
this
working
group
to
find
out
how
how
how
we
can
integrate
into
our
detox
tools
into
captain
and
yeah.
There
would
be
their
current
state
would
be
pretty
cool.
E
E
E
A
Thanks
a
lot,
it's
definitely
interesting
discussion,
so
I'll
get
the
video
published,
etc.
Today
and
yeah
we
also
have
yeah.
We
have
community
meeting
tonight.
So
I'm
not
sure
whether
it
will
happen
depends
on
how
many
people
we
get
because
yesterday
it
was
just
me
and
mike
but
yeah.
If
there
are
more
people
joining,
then
of
course
we'll
have
a
long
discussion.