►
Description
Discussion on whether we have reached a dead-end on migrating services and possible rethinking of release pipelines.
A
A
B
A
A
We
are
slowly
inching
towards
state
where
we
are
no
longer
going
to
be
able
to
just
like
do
migration
in
parallel
with
doing
the
other
work
like
it's
already
difficult
and
for
registering
mail
room
services.
Dysfunctions
like
our
migration
that
we
are
currently
doing
is
functioning
because
there
are
slower
moving
services.
They
don't
require
Britain
bumps
that
often,
and
when
they
do,
it's
actually
quite
easy
to
just
bump
them
manually.
A
A
B
C
C
Gonna
probably
need
to
probably
just
come
up
with
the
document
and
start
bouncing
ideas
off
each
other,
because
I
I
think
the
first
thing
we
need
to
do
is
agree
on
the
goals
and
what
what
what
we're
trying
to
accomplish
here
and
I
think
there
there
still
is
a
bit
of
disagreement,
maybe
about
weather,
charts
and
omnibus
are
released
in
lockstep.
Whether
you
know,
though,
like
how
we
manage
the
versions,
if
there's
a
single
source
of
truth
for
the
version
mapping,
where
would
it
be
all
these
things
and
I
and
I?
A
I
agree
with
that,
so,
given
that
it's,
the
purpose
of
this
meeting
is
exactly
this
discussion
and
let
me
check
your
calendars
really
quickly
to
see
whether
you
have
time
to
extend
this
call
both
of
you
do
so
I'm
going
to
just
expand.
This
call
for
the
next
well
to
be
a
full
50
minutes
and
we
can
start
the
discussion.
A
A
A
We
need
to
continue
using
the
helm
charts,
but
because
that's
what
we
offer
to
our
customers,
so
there
is
no
way
around
that
and
we
need
to
do
this
in
in
a
hybrid
setup,
so
both
omnibus
and
kubernetes,
like
we
I,
think
we
can
agree
on
the
last
one
that
there
is
no
way
for
us
to
just
disconnect
them
right
like
it's.
Hybrid
is
gonna
stay
hybrid
for
a
while,
and
we
need
to
live
with
it.
A
B
A
But
it
creates
a
lot
of
back
and
forth
because
we
don't
have
the
charts,
correct
and
charts
also
are
being
currently
built
as
a
copy
of
what
was
you?
What
was
done
for
omnibus
and
the
reason
why
that
is
done
is
because
it's
an
iterative
step
right
left.
You
already
have
a
system
that
builds
omnibus
charts
are
similar
to
what
omnibus,
like
is
doing
so
equal
signs.
B
Okay,
but
like
also
with
omnibus
we
can
go
to
deploy,
we
are
thanking
the
powerful
deployed
releases
or
even
if
we
remove
the
concept
of
tagging,
you
can
trigger
a
built,
an
omnibus
telling
I
want
to
build
from
this
shot
on
get
lab
the
sean
get
away
this
shop.
You
can
override
the
version
of
the
components
yeah
and
we
still
have
the
the
NPM
packages
built
there.
A
Is
a
difference,
though,
the
difference
being
we
have
the
helm
chart
as
like,
let's
say
the
omnibus
package
right
like
it,
it
can
be
tired,
whichever
way,
but
there
is
no
one
single
file
like
a
version
file
for
all
of
the
sub
charts,
so
we
either
have
to
commit
those
changes.
Also
automatically
there
right
like
adapt.
A
The
charts,
which
is
actually
not
the
best,
would
think,
but
also
we
want
to
be
able
to
have
another
level
of
freedom
compared
to
what
Omnibus
gives
us,
and
that
is
we
want
to
be
able
to
adapt
the
charts
or
the
sub
charts
of
a
major
chart
in
such
way
where
we
can
roll
out
images
independently
from
the
sub
chart.
Sub
charts
are
not
moving
that
much
and.
A
B
B
So
also
the
configuration
doesn't
go,
oh
okay,
so
we
would
write
directly
the
gitlab
config,
the
whatever
chart.
Okay.
So
it's
double
effort,
yeah,
because
it's
it's
it's
a
rewrite
of
omnibus
in
sir
yeah
in
a
certain
way,
yeah
the
configuration
part,
let's
say:
okay
suit.
So
now
the
question.
Another
question
is
because
this
is
made
of
sub
charts
as
I
understood.
Can
you
have
the
department?
Is
you
have
the
application
server
the
sidekick
and
can
we
simply
remove
the
main
chart
and
just
kind
of
Ryoka
straight
the
configuration
of
what
we
need
for
github.com?
A
Is
too
much
work
because,
right
now,
what
we
do
is
we
just
pull
the
helm
charts
as
a
whole
same
way
as
we
would
be
pulling
the
package,
and
then
we
use
values,
files
to
roll
out
things
right,
so
use
helm
natives
to
actually
execute
some
of
this
work.
If
we
were
to
separate
the
charts,
then
we
are
just
adding
another
level
of
duplicated
work
and
I
know
that
there
was.
A
B
But
so,
if,
if
I
understand,
the
problem
is
that
we
have
the
the
chart,
part
is
handled
the
templating
engine
and
this
will
will
sit
also
our
need.
What
we
are
missing
now
is
the
ability
to
build
the
real
images
from
a
custom
version.
So
this
is
the
missing
part
right,
because
even
if
we
are
able
to
say
override
the
versions
of
the
images
we
will
deploy,
there
would
be
no
image
tilt.
B
A
A
Okay,
so
you
have
the
shop,
but
you
don't
have
the
independence
of
like
workers
only
building
this
now.
The
reason
for
that
is
like
there
are
multiple,
but
one
of
the
things
was
we
needed
a
way
to
iterate
fast
and
not
be
dependent
on
upstream
projects,
but
basically
this
whole
discussion
is
now
coming
to
a
point.
A
B
A
B
B
C
I've
been
thinking
about
this
today
a
bit
and
let's
pretend
that
we
can
build
all
the
images
independently
of
each
other,
like
each
project
is
responsible
for
its
own
image.
Let's
say:
that's
all
works
which
it
doesn't
now,
but
let's
say
we
can
make
it
work.
I,
don't
quite
see
how
we're
going
to
manage
the
product
version.
You
know
the
twelve
five
or
the
twelve
six
for
both
the
omnibus
package
and
charts
package
because
or
the
charts
project,
because
you
can
kind
of
see.
C
C
Assuming
that
we
only
let's
say
we
only
tagged
the
product
release
on
the
charts
project
and
omnibus
project
and
then
the
sub
components
we
just
use
shots
I,
think
that
would
be
a
nice
same
way
to
go
about
it.
You
know
we
don't
have
any
tags
for
any
of
the
sub
components.
I
think
we
solve
a
problem
right
like
we.
C
We
can't
really
keep
charts
and
omnibus
in
lockstep
unless,
if
we
are
willing
to
issue
a
new
release
without
any
changes,
what
do
you
see
is
like
a
way
we
can
avoid
that,
because
it's
going
to
get
confusing
when
we
have
some
of
our
infrastructure
on
a
product
release,
twelve
five
one
and
some
of
our
other
infrastructure
and
gubin
amis
on
product
release,
12
phi2,
because
you
know
the
other
stuff
hasn't
changed
right
like
this.
What
what
do
we
do
here?
We.
B
B
Are
numbered
by
hell,
so
it's
supposed
to
be.
There
are
two
numbers
when
you
charge
the
version
of
the
chart
and
a
version
of
the
thing
that
you're
installing,
so
it's
already
baked
it
in
in
the
system.
But
this
is
not
true
for
Omnibus,
because
omnibus
is
part
of
the
let's
say
of
the
general
release,
which
is
where
the
0.1
stopped.
Whatever
the
diversion
bomb
in
the
package
should
come,
you
useful,
but
we
don't
use
this.
C
A
C
Parity
between
omnibus
and
charts-
maybe
that's
just
not
realistic,
but
to
keep
everything
straight
I
think
we
need
a
single
source
of
truth
for
version
mapping,
I'm
thinking
like
a
version
like
we
can.
If
we
want
to
be
super
simple,
like
we
can
just
have
a
version,
mapper
file
and
release
tools
that
has
a
product
version
that
to
subcomponent
versions
and
maybe-
and
maybe
we
have
two
product
versions-
one
for
charts
and
one
for
omnibus
and
that's
at
the
top
level,
and
then
underneath
that,
then
we
have
Shaw's
for
each
of
the
services.
Yeah.
A
I
agree:
I
mean
if
you
take
a
look
at
the
epic.
Well
one
one
tree
the
issue
I
created
like
a
year
ago.
It
is
exactly
that
right,
release
tools,
release
tooling,
becomes
the
source
of
truth
for
our
well
everything,
basically
both
package
and
charts
and
then
over
time
that
be
that
also
becomes
independent,
as
in
release.
Tooling
will
be
responsible
for
tagging,
individual
components
and
then
individual
components
are
only
going
to
be
collected
into
a
package
all
right.
So
that
is.
C
A
Think
I
think
we
can
I
think
the
reason
why
it
is
being
tagged
the
way
it
is
being
tagged.
It
is
because
we
were
following
the
path
of
least
resistance,
and
that
is
you
already
have
what
you
know
right
and
that
is
specifically
tagged
versions
so
might
as
well
just
use
them.
There
is
no
reason
for
us
to
reason
it
differently.
Apart
from
it
is
not
humanely
easily
understandable
right.
Look,
you
need
to
map
the
SHA
with
a
certain
version
and
as
a
user
you
don't
know
how
to
do
that.
Possibly
you
know
yeah.
C
And
I
think
I
mean
that's.
The
only
other
place
I
think
it
has.
Impact
is,
is
for
rails,
where
you
have
the
version
file,
and
you
know
the
slash
help
endpoint,
which
gives
you
the
contents
of
that
and
if
we
just
start
using
a
sha
instead,
like
probably
gonna,
have
probably
the
make
an
application
changed,
expose
and.
A
B
A
C
So
the
next
leg
thing
I
think
about
if
we
have
a
version
mapper
which
has
like
a
product
version,
not
with
sub
components
with
like
Shaw's
and
that's
on
release
tools.
Now
we
want
to
build
an
omnibus
package.
The
way
we
do
that
now
is
we
tag
omnibus,
which
you
know
kicks
off
a
special
pipeline,
and
you
know
it
looks
like
these
version
files
in
the
omnibus
project.
C
Would
we
change
that
so
that
maybe
maybe
then
we're
creating
a
service
on
release
tools
that
given
a
product
version,
will
tell
you
these
are
all
the
sub
component
versions
for
this
product
version?
That
way
omnibus
would
just
consume
that,
instead
of
looking
at
local
files,
is
that
the
direction
we
want
to
go
I?
Don't.
A
Know
we
do
we
want
to
offer
a
service-
that's
I'm
concerned
about
that,
like
I,
want
to
offer
to
everyone
who
is
maintaining
either
charts
or
packages
a
way
for
them
to
understand
what
are
the
individual
versions.
So,
theoretically,
what
we
would
want
to
do
is
if
you're
talking
about
a
version
mapper
file
right.
What
we
would
want
to
do
is
whenever
we
are
ready
to
release
either
charts
or
a
package.
We
just
get
that
version
mapper
in
embedded
into
it
right
and
that.
C
C
C
C
C
A
C
A
Whole
point
why
charts
is
completely
different
is
because
chart
is
a
more
faster
moving
project,
an
omnibus
these
days.
I
mean
they
are
way
too
many
changes
need
it
and
where
too
many
versions
need
it
to
actually
address
the
problem.
So
if
we
were
to
have
like
a
uniform
mapping
between
them,
we
will
also
have
to
bump
omnibus
very
frequently,
which
is
very
intimate
ik
right.
So
that's
the
the
reason
I
wouldn't
focus
on
that
specific
problem
like
for
me.
A
A
C
Yeah
I
was
thinking
like
either
either
the
this
service
could
update
the
version
mapper
from
their
pipeline.
When
we
have
like
a
successful
pipeline
about
this
version
mapper
or
we
poled
so
much.
What
we
do
now
and
release
was
we
look
for
the
latest
green
commits
yeah,
so
the
version
mapper
structure
that
I
was
thinking
of
you
know
you'd
have
like
a
version
and
then
underneath
that
would
be
a
branch
and
then
you'd
have
all
the
services
and
the
branch
you
know
would
either
be
in
the
auto
deploy
branch
for
like.
C
Maybe
maybe
you
have
a
top
level
top
level
I,
just
Auto
deploy,
which
is
always
like
the
latest
auto
deploy,
and
then
underneath
that
you
would
have
the
branch
which
is
the
current
auto
deploy
branch.
And
then
you
have
all
the
sub
services
and
each
under
each
each
sub
service,
then
you
would
have
like
okay.
This
is
the
latest
green
sha.
This
is
the
latest
passing
Sean,
then,
and
then
from
that
we
can
trigger
both
CMG
and
omnibus
I.
C
A
C
A
C
A
And
it'll
have
to
happen
like
if
you
wanna
run
things
from
a
central
location,
it
needs
to
be
either
release
tool
or
another
project.
It
doesn't
matter,
but
it
can't
be
the
last
step
in
the
process,
which
is
here
omnibus
right,
and
that
is
a
problem
like.
We
need
to
understand
that
in
this
central
project,
is
the
package
ready
for
these
three
services
that
we
are
deploying
with
the
package?
Okay,
you
can
roll
that
out
independently.
Are
the
images
ready
for
these
services
that
are
really
running
in
in
company?
A
Ok,
you
can
trigger
the
pipeline
that
executes
the
deployment
of
this
specific
version
out
Fernet
of
lee.
We
can
also
use
the
Kate's
workloads,
get
Lacombe
project
and
ask
it
to
query
rather
than
receive
an
input,
as
in
I
know,
it's
frowned
upon
and
I,
don't
like
it
as
well
right,
like
the
latest
AG
I'm,
not
proposing
a
latest
AK.
What
I'm
saying
is
the
point
of
the
latest
AG
is
that
you
can
always
point
towards
something
that
is
the
newest
and
just
have
your
system
automatically
pick
that
up
right?
A
C
Yeah
I
think
that
makes
sense.
I'm
thinking
I
mean
currently
I'm.
Thinking
right
now
is
at
the
end
of
this
after
we,
so
we
we
trigger
the
CNG,
we
trigger
the
omnibus.
We
wait
for
those
pipelines
to
complete,
then
we
trigger
charts
and
then
all
the
app
versions.
Bom
and
now
we
have
a
new
charts
release
and
then
I
was
thinking.
Okay,
now
we
can
go
and
you
can
trigger
Kate's
workloads
by
bumping
the
chart
version
and
that
would
trigger
a
pipeline.
That
would
be
kind
of
like
the
last
step
in
this
release
tools.
C
A
B
Also
want
to
just
spend
a
couple
of
words:
what
was
the
more
challenging
part
of
the
literally
of
malonic,
which
is
exactly
version
handling
and
inversion
tanking,
so
is
the
part
that
we
didn't
solve
at
all
and
there's
also
unenacted
here,
which
is
interesting.
So
little
a
master
is
broken
since
emerging
security
fixes
back
to
calm
because
of
her
race
conditioning
test.
So
we
suspended
the
router
deployment
and
we
said
that
order
to
the
tag
inversion
that
were
a
tether
fix
before
we
know
it
was
the
master
was
broken.
B
B
Yeah
exactly
sure
they
were
noble
version,
so
this
is
a
fact,
and
did
that
point
me
in
some
problems
that
I
see
which
is
from
the
developer's
perspective,
so
they
don't
feel
that
whatever
goes
on
master
can
go
on
production
immediately,
which
is
something
that
is
important
to
understand
and
you
feel,
and
they
still
want
to
have
the
target
version.
Because
of
the
change
look-
and
this
is
the
weirdest
things,
because
we,
how
do
you
manage
change
lock
in
a
continuously
deployed
system?
You
can
use
git
log
I
mean.
A
Change
I
would
rather
want
to
avoid
discussion
about
the
change
log.
That's
such
a
minor
problem,
in
my
opinion
that
right,
like
worst
case
scenario,
we
use
git
log,
like
you
said,
and
just
like
committed
somewhere
I,
like
version
like
you
just
said,
like
broken
master
for
two
days,
is
exactly
the
thing
the
previous
problem,
yeah
problem,
yeah
yeah,
and
if
we
don't
have
an
easy
way
to
do
a
version,
mapping
or
actually
that's
another
thing.
We
need
to
consider
maybe
it's
time
for
us
to
discuss
that.
A
A
A
We
are
not,
we
are
not
taking
that
into
account
because
we
are
using
the
shop.
What
I'm
trying
to
say
here
is
that
if
we
have
a
system
like
they
have
in
Italy
where
they
are
tagging
frequently,
what
we
could
say
is
that
our
continuous
deployment
is
not
gonna,
be
us
using
the
SHA
of
Master
latest
master.
What
we
can
say
is
that
when
they
have
sufficient,
confidence
is
what
they
shipped
merged
into
master
and
they
tagged.
A
That
is
the
sign
that
is
the
trigger
like
as
soon
as
they
tag
that
triggers
an
update
in
whatever
project
is
tracking
the
versions
and
our
system
then
picks
up
that
change
and
triggers
the
rest
of
the
process,
builds.
The
images,
builds
the
packages
and
then
deploys
to
various
systems.
So
we
could
then
go
and
say:
rails
has
to
do
the
same
thing
right
so
currently
we
don't
have
any
owners
there
and
we'll
have
to
figure
out
what
owners
can
we
make,
but,
for
example,
saying
that.
A
To
build
a
version
12
5-0,
they
will
have
to
have
versions
of
get
lob
rails,
tagged,
12,
v,
0.01
0
to
0-3
like
it's,
not
proper
somewhere,
but
we
only
care
about
somewhere
when
we
ship
to
public,
we
don't
have
to
care
about
somewhere
when
we
ship
internally
so
say.
In
order
for
you
to
get
to
version
dot
0,
you
can
use
up
numbers
from
0
to
1000,
basically
so
12
5,
0,
dot,
0
0,
1,
0,
0,
2,
3,
4,
5,
and
so
on.
Every
time
incremented.
A
B
Don't
know
Marvin,
it
will
work.
Definitely
well.
If
you
look
at
this
from
the
literal
rates
point
of
view,
there's
a
step
forward.
If
you
look
at
this
with,
we
were
trying
to
do
with
Easley,
it's
a
step
backward
now.
It
really
depends
on
the
number
of
developers
working
in
the
same
code
base
and
a
lot
of
things
here,
but
the
shorter
in
terms
of
commit
is
the
diff
from
the
deploy
it
easier
is
to
understand.
What's
going
wrong,
yeah.
A
If
we
just
write
like
we
can
say
we're
gonna
pick
the
latest
Green
commit
and
automatically
increment
right,
like
it's
an
option
for
us
as
well,
but
that
might
not
be
sufficient
like
we
might
need
to
hand
this
off
to
developers
and
tell
them
you're
responsible
for
bumping.
These
versions
here
is
a
system
that
you
can
use
to
do
that
so
build
a
system
for
them.
I
think
that's
one
of
the
biggest
problems
that
we
have.
B
You're
thinking
of
a
system
where
each
team
is
can
trigger
on
say
a
complete
deployment
of
the
system,
because
you're
just
bumping
the
bar
today,
oh
and
this
will
trigger
building
new
package
whatever
and
all
the
pipeline
down
to
production
deployment.
So
you
give
them
the
tools
for
actually
shipping
yeah
the
changes.
Okay,
yeah.
C
I
was
thinking
like
maybe
like
I
I
sketched
this
out,
I
put
it
in
the
Genda.
Here,
let's
say
we
have
this
version
mapper
file
and
release
tools
top
level.
You
have
the
product
version
underneath
that
you
have
services,
every
product
version
has
an
Associated
branch,
and
then
you
have
only
really
one
entry
for
auto
deploy
because
auto
deploy
is
always
the
latest
right.
C
So
you
really
don't
I
think
we
can
drop
major
and
minor
from
auto
deploy,
and
then
you
could
imagine
that
the
individual
project
pipelines
would
be
updating
this
file
and
release
tools
when
they're
ready
for
a
new,
auto
deploy,
and
that
could
be
the
latest
green
pipeline
a
master
or
forget
elites
case
like
maybe
it
only
happens.
You
know
they
can
come
up
with
their
own
goals
when
the
version
is
updated.
Does
something
like
this
makes
sense.
A
B
C
B
A
A
Right
and
whenever
they
are
ready,
they
increment
this
number
and
say:
okay,
this
is
ready.
We
automatically
pick
it
up
right,
stick
in
increment
this
all
they
want
and
we
use
the
same
system
for
self-managed,
meaning
at
a
certain
point
in
time.
We
just
pick
this
version
here.
So
if
we
decided
now
from
this
auto
deploy,
we
decided
we
are
going
to
go
and
release.
We
just
use
this
one
and
then
say:
if
you
want
to
pretend
that
we
have
to
do
somewhere,
we
can
always
tag
the
same
here
and
say
this
is
all
right.
A
This
is
now
1
to
12.
So
this
is
the
version
and
it's
based
on
this
latest
bag,
and
then
we
collect
whatever
we
had
here
instead
of
being
shows,
we
have
tags
and
just
translate
it
into
self-manage.
So
auto
deploy
becomes
like
this
free-flowing
thing
that
is
constantly
being
updated
by
teams
responsible
for
tagging
their
own
stuff,
and
the
system
takes
a
certain
point
in
time.
Queries
github.com
for
its
latest
deployed
version
for
each
of
these
components.
A
B
C
A
A
A
Now
the
question
I
also
wanted
to
like
ensure
we
answer
is:
is
this
still
relevant
if
we
are
completely
on
goodlove
like
Bernie
to
see
if
github.com
is
completely,
is
this
problem
still
relevant?
Are
we
solving
something
that
is
useful
for
future,
regardless,
where
the
future
is
or
does
kubernetes
expose
us
to
way
more
flexibility,
so
that
we
don't
have
to
think
about
mice?
I
know
the
answer,
but
I
want
to
hear
you
yeah.
C
I,
don't
I,
don't
think
it's
gonna
I
mean
replace
self-image
with
charts
here
and
you
have
the
same
map.
You
know
you
really
need
the
same
mapping,
because
we're
gonna
have
also
a
parallel
charts
product
version
yeah.
This
is
a
12
v
2,
which
is
going
to
have
the
same
versions
of
all
the
sub
components,
but
there
might
be
different
stuff
and
charts,
and
there
would
be
an
omnibus
right
because-
and
these
will
kind
of
be
released
in
lockstep,
but
may
not
be
released
on
lockstep
all
the
time
right,
so
I
think
it
I.
C
A
Customer
customer
right,
like
we're,
trying
to
optimize
this
process
for
all
and
I
think
we
should
go
there
regardless,
but
let's
say
get
club
comm
is
on
kubernetes
databases
handle
differently.
We
are
not
deploying
omnibus,
we
are
deploying
only
charts.
Do
we
have
to
resolve
a
problem
of
teams
independently
building
images
that
will
be
rolled
out?
No.
B
B
B
Yeah
this
could
be
services
you,
it's
just
the
fact
that
the
get
early
part,
let's
talk
about
kubernetes,
occasionally
pod
can
be
rolled
out
independently
from
the
rest
of
the
of
the
charts.
So
if
we
have
a
system
that
can
ensure
us
that
the
new
field
of
get
early
will
not
break
the
existing
in
the
complete
system-
and
you
can
leave
with
the
old
version
of
his
lab
rails
you're
a
component
there's
no
reason
to
help
this
master
recipe
where
you
have
or
diversion,
because
you
can
clearly
the
system
live.
A
Right,
you
will,
you
will
also
have
to
build,
even
in
that
case
that
you're
mentioning
right
and
you
need
to
somehow
track
all
these
versions.
You
can
query
the
system,
that's
not
a
problem,
but
you
still
need
to
expose
this
catalog
somewhere
this
inventory
somewhere
and
whether
you
call
it
a
recipe
or
an
inventory,
doesn't.
B
B
So
as
long
as
I
mean
these
leave
trails
only
needs
no
work
to
find
III,
IV
eyes
and
point.
So
this
is
a
configuration
in
the
it's
called
to
get
your
brains
chart.
Okay,
so
Italy
cares
about.
The
say:
cares
about
nothing
so
in
just
at
its
own
storage.
So
it's
independent.
This
means
that
you
can.
You
can
have
an
out
chart
that
has
its
own
version.
That
goes
with
its
own
life
that
only
handle
Italy
yeah,
and
this
is
why
I
see
this
is.
Where
is
the
difference?
B
Because
now
we
still
have
the
idea
of
having
the
this
house,
you
just
get
like
the
old
insulation,
but
in
if
we
were
just
having
a
service
with
no
external
customer,
we
can
think
about.
We
have
literally
charts
rails
charts,
so,
yes,
I,
think,
is
based
on
think
of
base,
so
I
would
not.
I
will
update
this
at
the
same
time,
even
if
it's
two
different
charts,
because
it's
bill
different
images
but
from
the
same
codebase,
but
they
will
be.
When
you
do
helm,
LS
will
be
different
installation.
C
Yeah
I
mean
I,
would
I
think
I
think
we're
saying
the
same
thing,
but
basically,
what
was
he
different
if
we
were
starting
over
without
the
omnibus
would
be
that
every
project
would
have
the
chart
in
its
own
project
repository
and
they
probably
would
be
version
together.
So
the
chart
version
where
the
component
would
be
the
same
version?
That's
what
the
point
of
itself,
and
so
you
wouldn't
have
this
separate,
charts,
release
right
and,
and
we
would
just
deploy
these
things
independently
announced
right.
We'd
still
have.
B
A
B
Want
to
know
if
you're
introducing
a
breaking
change-
and
this
means
that
you
need
to
orchestrate
very
well
that
update,
because
you
that
you
can
do
this,
it
thinks
about
all
the
complexity
that
we
have
around
database
migration.
It's
just
that
is
it's
it's
well-known,
and
so
here
there
are
more
it's
more
mature
solution,
but
it's
exactly
the
same
thing.
Database
migration
can
break
the
system,
but.
C
B
A
Even
if
you
go
forward
like
I
I,
don't
I
don't
see
how
you
can
go
without
knowing
the
compatibility
between
the
different
versions
like
don't
have
to
go
backwards.
Much
like
if
you
need
to
roll
back.
You
need
to
know
whether
your
component,
that
you're
rolling
back,
is
compatible
with
whatever
is
in
the
system
already
right.
So
even
if
you
go
independently
there,
you
need
to
have
an
inventory
of
the
system
to
understand
the
compatibility
metrics
between
all
these
various
components.
A
So
what
I'm
trying
to
say
here
and
the
reason
why
I
kind
of
pulled
this
discussion
in
this
way
is?
Is
there
an
intersection
between
what
we
are
doing
right
now
and
what
would
the
ideal
system
be
that
we
can
actually
start
thinking
about
and
working
on
and
then
reorder
our
systems
that
we
currently
have?
According
to
that,
so
that
the
outcome
becomes?
A
A
We
need
to
have
more
of
these
discussions
and
we
need
to
have
an
outcome
of
these
assessments
as
well,
because
there
is
no
after
it's
one
hour
of
discussion,
yeah
well.
Actually
there
is
one
though
jarv
you
and
I
are
definitely
in
agreement
that
we
need
inventory
right.
I,
think
I'll,
ask
you,
you
are
more
or
less
there
as
well
you're,
just
using
different
wording
and.
B
B
C
I
think,
as
the
central
coordinator
I,
don't
know
whether
I
I
guess
some
probably
thinking
it
too
far
to
have
a
service
I
was
actually
thinking
like.
We
could
even
move
this
to
version
that
david.com,
but
I,
don't
know
if
I
want
to
look
at
that
code
or
or
think
about
adding
it
to
that
right,
like
maybe,
just
belongs
and
release
tools
as
a
simple
yamo
file.
A
What
do
you
all
want
to
do?
Next,
like
we
had
all
these
written
down
in
issues,
but
that's
not
moving?
That's
not
good
enough
like
we
need
live
world
like
we
are
having
right
now,
I
think.
Would
you
be
okay
if
I
schedule
another
one
of
these
on
Monday,
so
I
mean,
if
necessary,
every
day
until
we
get
to
a
point
where
we
can
start
right
side
working
working,
because
we
have
this
written
down
in
issues
which
is
the
problem
is
like.
We
need
to
coordinate
this
thing,
which
is
really
really
hard
in
written
yeah.