►
From YouTube: Think Big: Release Management - US/EMEA
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Today
we
have
a
guest,
a
guest
from
the
configure
team,
it's
the
pm
of
configure
victor
and
he
has
a
topic
around
kubernetes
agent
and
integrating
that
more
closely
with
the
release
management
features
in
our
agenda.
We've
dropped
in
the
product
issue
as
well
as
some
work
that
the
design
has
been
doing
so
I'll
pass
it
over
to
victor
to
give
like
a
high
broad
stroke,
and
then
we
can
kind
of
brainstorm
and
then
at
the
end,
think
small
about
what
issues
we
can
start
creating
in
the
next
couple
of
milestones.
B
Yeah,
thank
you.
So,
basically,
let
me
try
quickly
describe
what
the
harvey
approach
deployments
and
releases
in
the
configure
team
beat
the
gitlab
kubernetes
agent,
especially
so,
basically,
it's
a
pool
based
style
of
deployment
and
I
think
the
the
best
idea
to
describe
it.
I'm
going
to
share
my
screen
in
a
minute
to
to
visualize.
It
is
that
basically.
B
The
user
would
have
multiple
projects.
I
hope
that
my
screen
is
can
be
seen
well,
like
an
application
code
repository.
That's
your
generic
project,
then
I'm
skipping
this
to
the
agent
configuration
repository
where
you
configure
the
agent
itself
in
code.
So
it's
not
it's
not
configured
through
the
ui,
but
it's
configured
in
code,
because
that's
how
the
people
whom
we
are
trying
to
serve
the
sres
and
everybody
prefers
to
do
that.
B
So
this
is
the
basic
setup
where
we,
where
we
operate,
that
we
have
a
manifest
project
with
a
bunch
of
files
that
describe
your
infrastructure,
the
expected
state
of
that
infrastructure
and
the
agent
just
grabs
those
and
tests
to
your
cluster
that
they
provide
me
this
infrastructure
and
we
have
today
this
setup
and
it
works
at
a
very
minimal
level.
We
released
the
agent
two
months
ago
or
a
month
ago.
Actually,
and
the
question
is:
how
could
we
improve
it?
B
Together
with
you
and
as
jackie
pointed
a
few
ideas
very
quickly,
you
have
lots
of
features
like
the
deploy
freezes,
secrets,
management
and
many
other
things
there.
That
might
be
interesting
for
us
as
well
and
if
you
can
cooperate
around
those
and
and
if
you
can
do
that
in
a
user
valuable
fashion.
So
it's
it's
really
just
an
ideation
how
we
could
help
each
other
to
to
gain
more
adoption
to
more
visibility
and
to
provide
more
valuable
features.
B
The
truth
is,
I
don't
know
much
about
the
release
management
features
except
the
the
bullet
points
type
listing.
I
never
use
them
so.
A
Well,
you're,
probably
using
them-
and
you
don't
know
it
that
seems
to
be
the
mo
with
some
of
the
people
that
I
interview
like
environments,
is
a
release,
feature
yeah
and
the
release
environments,
dashboard
environments
index,
there's
a
lot
of
features
that
are
secretly
released
management.
So
I
think
victor.
For
me
it
might
be
really
helpful
to
step
back
and
look
at
the
job
to
be
done
and
the
pain
that
we're
solving
with
the
kubernetes
agent.
So
that
way
I
can
start
wrapping
my
head
around.
Who
is
the
persona
that
we're
targeting
here.
A
Management,
we
think
about
two
main
personas:
the
release
manager,
which
is
cutting
across
multiple
projects
and
the
developer,
who
has
to
consume
the
features
that
that
release
manager
or
admin
then
turns
on.
So
I
would
love
to
know
who
we,
which
part
of
the
funnel,
are
we
engaging
and
what
involving
and
then
that
might
allude
to
what
features
we
would
want
to
hook
in
with
with
it.
B
Okay,
so
in
the
past
year
I've
added
two
personas
to
the
gitlab
persona
list.
One
is
called
the
application
operator
and
that
is
called
the
platform
operator
and
they
are
our
core
personas,
the
platform
operator,
the
best
how
you
can,
where
you
can
meet
a
platform
operator.
If
you
enter
the
infrastructure
launch
slack
channel,
they
are
the
platform
operator
in
gitlab's
case,
so
they
are
really
people
who
set
up
the
underlying
cluster
that
everybody
else
is
using
afterwards
and
they
are
responsible
for
that
cluster.
B
A
B
Okay,
so
the
pain
points
here
are
mostly
around
complexity,
namely
the
the
developers
don't
really
care,
whether
their
code
runs
on
kubernetes
or
ec2
or
whatever,
and
would
like
even
the
platform.
Operators
would
like
to
make
seamless
experience
for
the
developers,
because
that's
that's
where
they
get
everything,
and
this
is
true
for
the
operators
as
well,
that
everybody
here
tries
to
make
it
easy
for
the
developers
to
do
their
work
and
at
the
same
time
there
is
this.
B
A
I
think
another
area
where
we
can
help
improve
the
developer
complexity,
pain
point
is
around
setting
up
vault
or
other
secrets
management
stores,
because
today
it's
a
really
horrible
experience
for
users,
like
developers
who
are
trying
to
leverage
the
evolved
integration,
but
have
to
set
it
up
themselves.
So
it's
another
platform
experience
that.
B
People
have
just
for
me
to
understand
in
the
case
of
what
is
it,
that
the
voice
server
would
be
set
up
in
these
terms
by
the
platform
operator,
and
then
the
developer
has
to
integrate
with
that
world,
and
that's
where
you
try
right
yeah,
that's
that
would
be,
for
example,
a
great
integration
point
for
us
as
well.
D
A
Developing
against
that
at
that
point
that
point,
but
I
think
for
the
team
on
this
call
deploy
freezes
would
also
be
interesting,
because
that
is
something
that
the
operator
has
to
also
set,
and
then
the
developer
is
merging
changes,
but
then
their
stuff
could
get
blocked
across
projects.
So
that's
another
setup
thing
and
I
think
sean.
I
would
love
to
hear,
like
your
perspective,
on
how
you
think
we
can
solve
some
of
the
pains
that
we've
experienced
with
with
deploy
freezes
and
that
kind
of
workflow.
E
Sure
sure,
in
fact,
thanks
for
checking.
B
Just
I
will
give
it
back
soon,
and
I
want
this
topic
just
to
make
it
shorter.
I
think
this
this
might
be
related
to
it
as
well.
Is
that
how
we
work
today?
B
We
have
this
manifest
repository
and
somehow
we
have
to
generate
the
content
or
the
user
has
to
generate
the
content
of
this
repository,
and
these
are
actually
the
release
artifacts.
So
this
is
what
what's
going
to
be
deployed,
as
is
in
the
cluster,
and-
and
this
is
an
area
that
that
is
totally-
we
have
solutions
for
that,
but
we're
definitely
not
happy
with
what
we
have
and
now
I'm
getting
back
there
too,
and
we
stop
screen
sharing.
E
Yeah,
victor
just
to
add
to
your
actual
the
point
you
just
made.
Actually
I
mean
we're
just
currently
we're
still
working
on
a
feature
which
will
allow
releases
to
automatically
create
the
binaries
associated
that
release
and
publish
them
to
our
to
our
repository
and
in
terms
of
then,
taking
that
one
step
further
so
you're
saying
to
take
that
one
step
further
and
then
essentially
create
the
next
version
of
the
application
inside
the
cluster.
Is
it?
Is
that
what
you're
referring
to.
B
So
basically,
I
don't
know
how
much
I
should
go
into
detail
so
feel
free
to
stop
me,
but
in
in
the
case
of
kubernetes,
your
cluster
is
described
in
a
ml
file,
a
bunch
of
yaml
files
and
basically,
what
what
we
are
deploying
are
just
these
xaml
files,
and
everything
else
is
up
to
the
cluster,
to
figure
out
how
to
set
up
the
deployments,
the
services,
how
to
connect
them,
and
everything
like
that
and
the
agent
does
this
deployment.
B
So
the
agent
grabs,
the
yaml
files
pulls
them
from
your
repository
and
applies
them
in
the
cluster.
What
jackie
said
like
with
deploy
phrases?
That's
clearly
a
question
that
how
how
to
attach
that
that
okay,
do
I
really
want
the
agent
to
pull
those
yaml
files
on
sunday
four
in
the
morning
or
definitely
not
or
another
question
here?
B
Is
that
how
do
I
generate
those
yaml
files,
because
I
can
tag
them,
as
you
said
as
well,
and
then
for
them
to
be
the
releases,
but
actually,
for
example,
an
interesting
question
here
is
that
we
see
that
other
tools
like
argo,
cd
and
flux,
cd,
some
of
them
support
even
tech
based
release
watching
and
that's
what
they
are
going
to
grab.
But,
for
example,
personally,
I
don't
see
yet
how
widespread
use
for
these
are.
So
there
are
many
many
open
questions
on
our
site
here.
E
Yeah
I've
got
a
few
questions
for
you,
based
on
what
you
just
said
so
because
you're
talking
earlier
about
the
you
know
the
operations
group
that
manage
the
the
infrastructure,
the
kubernetes
cluster,
but
is
this
class?
Are
we
talking
about
a
cluster
that
is
essentially
organization
wide
or
department-wide
or
project-wide
associated
with?
You
know
specific
project
inside
of
gitlab,
for
example,
which
they
might
have
managed
apps
associated
with
it?
You
know,
so
we
already
have
a
process
to
to
deploy
those.
B
E
Yeah
because
because
the
deploy
freeze
actually
can
transcend
projects
right
like
it
can
go
it
you
can,
you
can
basically
query
it.
It's
it's
stored
in
the
database,
the
gitlab
database
itself,
and
so
it
could
be
part
of
the
ammo
to
to
check
during
a
deployment,
is
a
deploy
phrase
that
covers
this
particular
project
in
this
particular
deploy
time.
But
then
because
then
it's
really
it's
essentially
a
function
of
of
the
environment.
E
At
this
point,
right
like
whether
the
okay,
whether
the
environments
are
deployed
or
not,
based
on
deployed
query.
E
Is
like
I
guess
I,
I
guess,
I'm
not
really
sure
whether
we
should
be
rewriting
these.
It's
cube
cube.game
or
we're
not
talking
about
the
gitlab
ciam
or
we're
talking
about
the
kubernetes
hammer,
exactly
yeah,
so
right
so
should
we
should
we
be
rewriting
that
with
the
information,
that's
in
the
deploy
phrase
or
should
the
m
will
just
go
and
query
the
deploy
phrase.
B
I
think
it's
the
latter
one,
it's
even
shouldn't
necessarily
be
the
dmo
that
creates,
because
so
our
from
institute's
point
of
view,
we
have
a
component
called
cos.
The
I
wanted
to
say
it
quickly:
kubernetes
agent
server
that
sits
besides
gitlab
and
that
communicates
with
with
git
lab
and
and
that
communicates
with
the
agent
as
well.
So
I
guess
we
are
adding
more
and
more
logic
in
cars
anyway,
and
we
could
add
the
deploy,
freeze,
logic
as
well
that
whenever
the
agent
comes
in,
wants
to
check
out
some.
E
Yeah,
I
guess
also
the
question:
is:
how
does
this
feedback
to
the
user
like?
What's
the
ux
experience,
if,
if
the
you
know,
because
the
cluster
is
over
here
in
the
in
deep
inside
the
infrastructure
and
if,
for
some
reason,
there's
problems,
how
does
that
get
kind
of
bubbled
up
to
to
the
operators
or
yeah.
B
We
are
still
working
on
that,
so
we
have
some
very
rough
ideas,
just
some
wireframes.
Actually,
I
think
the.
B
The
first
issue
I
added
to
doc:
no,
it's
not
about
that,
so
I
can
add
wireframe
based
issuings.
If,
if
you
are
interested
harvey
imagine
this-
and
here
it
is.
B
Yeah,
it's
very
interesting
here
that
clearly
we
need
something.
B
We
definitely
need
some
kind
of
dashboarding
around
these
things
again
here
we
see
different
use
cases
for
the
different
personas
and
I
don't
yet
know
what
whom
does
the
environment
dashboard
target,
because
from
platform
operators
point
of
view,
what
I
care
about
is
the
how
many
pods,
how
many
agent
pods
are
running
in
my
cluster,
whether
the
agent
has
an
active
connection,
if
it
has
any
errors,
syncing
and
stuff
like
that
from
an
app
operator
point
of
view,
what
I
care
about
is
whether
my
application,
manifest
cameras,
have
been
synced.
E
Yeah,
absolutely
with
the
and
with
the.
E
Right
right
because,
because
the
first,
the
first
the
the
platform
operators,
they
wouldn't,
they
would
be
using
kubernetes
tools
right.
They
wouldn't
be.
You
know
they
wouldn't
be
looking.
They
wouldn't
be
wanting
to
look
through
git
lab
itself
right,
they
would
wouldn't
they
be
using.
B
What
I've
heard
from
our
own
sra
is
that
gitlab
is
often
a
great
starting
point
for
them.
So,
for
example,
when
I,
when
I
spoke
with
the
jarvis
about
the
the
deploy
boards,
we
have,
he
told
me
that
they
use
deploy
boards
when
they
were
migrating
over
to
kubernetes,
and
then
it
was
a
great
way
to
see
whether
something
is
green
or
red.
E
B
E
But
from
a
from
a
developer's
perspective,
as
you're
saying
you
know,
they
just
want
to
know
where
their
environment's
up
and
if
it's
not.
Why?
What
happened
to
it
and
yeah,
I
mean,
I
think
I
think
we
kind
of
have
some
of
that
information
already
in
the
environment,
information
environments
page
and
then,
if
we
expand
into
an
environment's
dashboard.
E
I
mean
we've
talked
in
other
think
bigs
about
also
having
some
type
of
calendar
for
scheduled
as
as
part
of
deploy
pleases
as
a
calendar,
for
you
know,
scheduled,
implementations
and,
and
that
type
of
thing
all
linked
with
it.
With
a
dashboard.
B
Yeah
one
question
here
that
I
have
is
that
to
me,
environments
are
really
just
labels
or
tags
on
a
on
a
ci
job
or
pipeline,
and
after
that
I
guess
you
got
a
whole
bunch
of
data
based
on
a
single
tag
with
clever
queries.
So
the
question
here
that
I
have
is
that
today
what
environments
are
from
us
are
actually
directories,
so
I
have,
as
my
cluster
is
described,
by
a
bunch
of
yaml
files.
B
Actually,
everything
in
that
cluster
is
my
environment.
Everything
in
the
directory
is
my
environment
and
somehow
I
would
like
to
hook
into
the
existing
environments
features
of
gitlab,
but
the
truth
is,
I
don't
know
yet
how
to
do
that.
E
Yeah
sure,
in
fact,
is
we're
a
bit
opaque
there
right
because
we
have
the
environment
status
and
we
have
logs
but
yeah.
For
example,
environment
can
be
quite
complex
right.
They
can
have
multiple
different
databases.
It
can
have.
You
know,
background
services
elastics,
you
know
whatever
all
these
different
services,
but
and
if
you
just
receive
a
message
that
it's
not
working
and
then
you
kind
of
have
to
sit
for
the
logs.
E
E
Because
because
we've
actually
added,
I
mean,
if
you
look
at
our
managed
apps,
also
we've
added
quite
a
lot.
You
know
recently
to
digilab
and
sometimes
I
feel
a
little
bit
like
wow
we've
added
all
these
applications
and
well.
How
do
we
kind
of
see
what's
going
on
with
all
of
them?
E
B
Yeah
from
dashboard
in
point
of
view,
actually
we
have
received
one
feedback
again,
that
was
from
from
jar
who
said
that,
really
for
dashboards.
What,
as
you
mentioned
as
well,
probably
would
use
other
tools
and
he
said
that
he
he
would
be
happy
to
have.
B
He
pointed
out
one
of
the
google
dashboards.
He
would
be
happy
to
have
that
in
gitlab
and
nothing
more.
That
was
very
strict,
that
and
nothing
more
because
for
everything
more.
He
would
go
for
a
third-party
tool.
B
E
E
B
And
definitely
build
yeah,
okay,
I
I
think
we
can,
sooner
or
later
add
the
ability
for
deploy
phrases
that
the
question
is
when
when
to
add
that,
but
there's
definitely
a
seems
to
be
an
easy
win
and
something
that
you
built
most
logic
there
and
the
uis
and
everything
so
we
just
have
to
hook
into
it.
B
B
Run
books
that
I
sorry
that
I
know
jackie
was
or
is
working
on
or
you
are
working
on-
is
that
in
our
case
release
round
books
are
the
kubernetes
agent.
On
the
other
hand,
so
it's
fully
automatic
in
this
sense,
on
the
other,
still
what
we
feed
into
the
run
book.
That's
the
manifest
project
in
a
sense
and
that's
why
I'm
thinking
that?
How
could
we
we
work
on
these.
C
A
Like
some
designs
that
we're
working
back
on
and
the
initial
introduction
of
it
will
be
in
issue
type
and
then
we'll
start
to
create
like
more
refined,
run
book
functionality.
As
far
as
like
adding
steps
and
some
of
the
longer
term
visions
that
we've
discussed
are
attaching
like
pieces
of
your
animal
that
you
want
to
inject
into
your
yaml
file.
But
this
is
the
git
lab
ci
dot
aml,
not
the
kubernetes
ammo.
So
we
could.
We
could
add
a
step
inside
a
run
book
that
says,
run
script
and
kubernetes
ammo.
A
If
we're
telling
the
agent
to
provision
something,
I
think
that's
a
definitely
like
a
feature
request
that
we
could
add
as
like
an
option
for
people
to
inject
into
their
run
books
that
we
create,
but
it's
still
it's
still
still
in
its
infancy
and
there's
a
lot
of
flexibility
that
we
can
build
in
there.
B
B
The
most
well-known
is
called
ham,
but
even
gitlab
is
just
currently
moving
away
from
home
or
there
are
considerations
to
move
away
from
harm,
and
we
know
of
some
companies
who
use
ansible
just
to
template
the
final
yaml
files
and
the
basic
idea
is
that
even
ham
can
output
the
yaml
files
that
we
need
and
any
templating
language
can
output
the
ammo
files.
That
are
that.
That
is
the
end.
That
is
the
content
of
the
manifest
project,
and
we
want
to
keep
it
like
this.
B
So
like
what
what
I,
when
I
set
up
an
example
project,
what
I
did
was
that
I
in
the
application
repo
I
had
a
ci
ml
that
did
the
build,
and
this
last
step
pushed
created
the
new
yaml
file
and
made
a
new
commit
into
the
manifest
repo.
So
there
was
a
ci
part.
Clearly.
Another
idea
we
have
is
that
there
would
be
a
web
hook
that
caused
something
in
the
manifest
repo
and
what
what
it
drives.
B
A
E
A
Like
we
got
really
far
away
from
what
I
think
we
wanted
to
accomplish-
and
we
have
a
couple
of
minutes
left
here,
so
I
think
what
I
wanted
to
what
I
wanted
to
kind
of
recap
on
and
where
we
think
we
should
be
potentially
focusing
in
in
the
near
term.
As
I
think
runbook's
priority
is
going
to
be
a
q1
next
year
focus.
So
the
back
half
of
this
year
is
finishing
up.
A
Some
of
our
more
cross-project
features
like
group
releases
group
environments,
and
I
think
that
this
kubernetes
agent
could
really
help
us
with
this
cross-project
functionality,
and
I'm
wondering
if
there's
a
way
that
we
can
talk
about
the
kubernetes
agent
provisioning,
deploy
freezes
across
multiple
projects
for
users
or
provisioning
environments
like
if
there's
something
that
there's
a
tangible
way
to
connect.
Some
of
these
cross
repository
actions
that
we're
now
requiring
users
to
manually
do,
I
think,
that'd
be
a
really
big
win
for
us,
but
I
could
be
missing.
A
The
deploy
phrases
are
very
focused
at
each
repository
for
for
the
end
user,
like
they're,
going
to
set
it
at
each
project,
but
they
would
like
to
control
these
and
administer
them.
What
sean
was
alluding
to?
It
transcends
the
project,
so
it
would
be
across
for
a
group
and
I'm
only
using
deploy
phrases
as
like
a
a
micro
example
of
the
cross
project.
Functionality
that
we're
looking
to
instrument
but
deploy
freezes
is
a
good
example,
because
today
you
set
it
at
your
project
ammo,
but
it
could
be
for
an
entire
environment.
A
B
Yeah,
it
could
be
interesting
so
clearly
the
agent
in
itself
is.
B
Unfortunate,
we
miss
an
important
feature
with
the
agent,
which
is
private
project
support.
We
are
just
adding
it
in
in
these
months
and
with
that
we
could
have
something
like
that.
You
you
set
up
this,
deploy
phrases
for
your
manifest
project
and
then
every
project
that
the
agent
would
deploy
is
managed
by
that
single
this
deploy-free
setup,
but
as
we
are
missing
private
project,
it's
really.
We
know
that
it's
a
it's
a
huge
problem
now
that
we
try
to
to
ship
actually,
but
once
we
have
it,
the
prophecies
are
definitely
something
we
can.
E
All
right,
I
know
we're
almost
out
of
time,
but
there's
just
there's
there
is
I'm
having.
I
do
have
one
slight
disconnect
in
that
you
know.
Currently
the
gitlab
yaml
ci,
you
know,
essentially
you
know,
assumes
the
kubernetes
cluster
is
already
there
and
pushes
into
it,
and
it
doesn't
really
manage
the
cluster
right.
So,
for
example,
if
you
want
a
database,
we
actually
put
it
in
it
might
be
a
step
in
the
you
know
to
install
the
database,
which
is
not
really
the
same.
E
It's
not
really
what
you
want
to
do
with
the
kubernetes
manifest
right
like
we're,
not
actually
passing
it
off
as
a
manifest
command.
It's
it's
just
kind
of
like
you
know.
Here's
this
empty
community,
shell,
with
with
some
of
the
managed
apps
that
have
been
selected
and
then
we're
we're
installing
my
sql,
so
kubernetes
probably
doesn't
really
manage
that
mysql
database
properly
right
because
it's
not.
B
That's
a
very
good
question.
It's
so
exactly.
B
Yeah
eating
that
yeah.
Definitely
we
so
what
we
know
about
managed
apps
is
that
we
want
to
support
gitlab
features,
but
we
don't
want
managed
apps
that
we
have
today,
like.
I
think
you
have
been
involved
in
the
jupiter
discussion
as
well.
It's
basically
unused
elastic
stack
is
not
production.
Ready,
k
native
is
unused,
so
what
we
see
is
that
runner
is
a
highly
used.
Gitlab
managed
app
because
gitlab
cis
around
run
range
is
great,
so
we
definitely
want
to
add
support
for
that.
B
We
already
have
a
poc
around
that
with
the
with
the
agent,
but
otherwise
what
will
be
the
future
of
git
lab
managed
apps,
I'm
almost
sure
that
the
ui
base
one
will
be
deprecated
as
soon
as
we
can
the
and
what
we,
what
we
will
have
as
a
code
based
one.
That's
a
that's
a
bigger
question
where
I
don't
even
have
an
opinion.
Yet
we
we
will
have
something
there
and,
as
you
said,
jack
yeah,
it's
the
agent
easily
cannibalizes,
the
the
git
language
labs.
A
Your
vault
was
super
easy,
then.
I
think
that
that
would
be
a
really
great,
really
great.
I'm
trying
to
think
of
like
a
super
super
sweet
word
for
it,
but
I
can't
I
think
it
would
just
help
us
release
users
to
set
up
their
vault
instance
inside
their
cluster
way
easier
than
the
managed
app
does
today,
because
today
you
initialize
the
vault
instance
inside
your
cluster.
A
You
don't
have
to
have
an
existing,
and
then
you
have
to
do
all
the
manual
hookup
with
our
integration,
and
you
still
have
to
set
your
roles
policies
and
then
customers
are
usually
just
like
I'm
out
that
sucks.
So
I
want
us
to
make
that
better
and
if
we're
going
to
be
eventually
replacing
the
manage
app,
I
don't
want
to
continue
investing
in
the
managed
app
I'd.
A
Rather
us
really
look
at
how
we
can
have
the
kubernetes
agent
go
inside
the
cluster
set
up
the
vault
integration
for
our
users,
and
then
people
can
just
start
rolling
with
their
with
their
vault.
The
biggest
thing
that
there's
two
use
cases
there
there's
an
existing
vault
url
that
the
program
manager
platform,
ops
person's
already
set
up
that
the
dev
has
to
then
connect
to
or
they
want
to
just
use
the
oss
version
of
vault
and
they
don't
have
an
existing
url.
A
So
I
can
see
the
vault
agent,
in
this
case
the
kubernetes
agent
on
for
vault,
enabling
both
as
far
as
next
steps
on
that
I
can
create
some
issues
and
we
can
continue
the
async
discussion
because
I
don't
think
we'll
ever
find
a
time
zone
for
us
to
meet
synchronously
altogether
with
the
lead
developer
on
there.
So
I
I
will
go
ahead
and.
D
A
This
issue,
and
we
can
start
the
discussion
on
that
front
as
far
as
I
think,
there's
more
work
to
be
done
on
how
we
can
enable
release
management.
I
don't
thoroughly
understand
how
I
would
help
bake
in
our
features
into
the
kubernetes
manifest
or
how
this
looks
from
a
from
a.
B
A
E
A
B
So
I
mentioned
today
that
I
still
understand
what
you
mean,
so
the
manifest
project
is
exposed
specifically
to
the
agent,
but
actually
it's
it's
a
gitlab
project.
So
there's
no
okay,
it's
not
hidden
at
all.
It's
a
full-featured
gitlab
project
that
just
contains
the
ammo
files.
E
B
B
B
Here
here
the
yeah-
I
was,
I
understand,
what
you're
thinking
about
actually-
and
I
I
would
say
unfortunately,
no.
This
is
something
I'm
struggling
as
well
with,
because
so
it
would
be
just
so
great
to
say
that
yeah.
This
is
my
release.
This
is
that
that
got
released
into
my
cluster,
so
it
doesn't
make
sense.
B
What
you're
saying,
on
the
other
hand,
in
this
whole
idea
behind,
is
that
this
is
pure
gitops,
which
means
that
what
you
are
releasing
is
in
git
this,
your
your
single
source
of
truth
is
git,
and
it's
not
a
special
release.
Artifact,
and
the
only
thing
we
can
add
here
is-
is
actually
tagging,
so
I
can
add
the
git
tag
and
every
new
tag
becomes
a
deployment,
but
I
don't
need
this,
which
would
be
your.
A
So
one
other
use
case
that
this
kind
of
forks
with
is
when
people
are
building
their
their
code
for
them
their
developers
to
build
off
of
so
they're,
creating
like
infrastructure
code
images
and
they
want
to
distribute
those
through
through
git
lab,
and
we
have
a
couple
of
customers
who
are
using
release
tags
for
that
exact
functionality
where
they
have.
This
is
the
infrastructurous
code.
I
want
people
to
be
building
off
of
and
then
they
have
like.
A
They
want
to
see
all
the
existing
repositories
who
are
building
off
of
historical
infrastructure
as
code
tags,
and
I
think
that
this
would
be
really
useful
for
the
kubernetes
agent,
because
we
could
see
how
many
people
are
using
the
most
recent
version
of
kubernetes
agent
versus
historical
ones.
If
we
were
tagging
the
repository
and
distribution
of
the
kubernetes
agent,
unless,
if
you're
expecting
those
to
be
not
versioned
like,
if
it's
not
like
a
virgin
dependency,
there.
B
I
mean
it's
clearly
versioned,
even
in
git,
so
it's
it's
definite
option,
it's
more
of
what
I'm
thinking
about
is,
but
if
you
can
use
an
outdated
version
at
all,
because
if
your
agent
is
running
it
so
it's
this
is
the
difference
between
the
pool
and
push
base
deployment
and
and
the
agent
is
a
pool-based
deployment
that
here
the
agent
asks
gitlab.
Do
you
have
a
more
recent
version
and
whenever
replies
yes,
then
give
me
that
version.
So
it's
it's
a
bit
hard
to
be
outdated
in
this
sense,.
D
E
E
So
so,
if
we
use
gitlab
as
an
example,
you
know
so
we
have
a
specific
release
of
git
lab
and
then
we
add,
we
add
vault
in
in
one
of
the
releases
as
as
part
of
us.
Then
then,
but
then
the
the
kubernetes
manifest.yaml
needs
to
then
incorporate
the
fault
of
the
appropriate
version
number
as
a
dependency
for
good
lab
right
yeah.
E
So
isn't
it
then
a
little
bit
circular
right,
because
we
have
to
also
update
the
we
have
to
update
you
know
we
have
to
push
to
ci
and
create
create
the
the
binaries,
but
then
we
also
have
to
somehow
update
the
kubernetes
as
well.
B
B
E
Yes,
yes,
yes,
yes,
I
I
completely
understand.
I
guess
I
guess
what
I'm
saying
is
the
gamble
files
in
its
own
project,
the
the
kubernetes
manifest
gamma
files
in
the
same
project,
and
then
we've
got
the
application,
gitlab
application
and
then
we've
added
something
new
to
the
stack
that
didn't
previously
exist,
and
so
the
ammo,
the
kubernetes
yaml,
has
to
change
right.
E
E
Yeah
yeah
yeah,
but
yeah
before
we
could
push
that
before
you
could
pull
that
release
it
would
we
would
need
to
tell
kubernetes
hey.
We
need
this
new
component.
E
B
B
D
Okay,
I'm
I'm
trying
to
understand
your
question,
but
I
think
that,
like
so
like,
you
would
update
the
manifest
yama.
Let's
say
your
ad
vault,
so
you
I
I
add
that
to
the
let's
say:
I'm
doing
it
manually,
I
add
it
to
the
manifest
yaml
manually.
D
I
push
that
up
to
get
then
as
part
of
the
that
would
automatically
be
applied
to
your
cluster
or
maybe
eventually,
if
you're
rolling
out
a
new
version
of
the
lab,
creating
a
new
cluster
based
on
the
latest
manifest
yaml.
You
always
keep
rolling
forward.
Is
that
answer.
E
Well,
you
know
partially
partially,
because
you
know
if,
if
so,
if
we're
using
the
volt
example,
so
we
didn't
previously
have
vault
at
all
in
the
cluster
and
then
we
we
update
a
new
version
of
of
our
application
and
now
that
application
needs
this
component
in
each
file.
So
we
so
there
is
then,
isn't
there
then
a
manual
step
to
for
some
for
the
operator
to
come
and
update
the
manifest
gamble
to
say
hey
now
we
need
volt
in
this
cluster
so
that
the
application
can
start
accessing.
D
E
E
D
The
cluster
directly
yeah,
so
so
in
that
case,
like
okay,
so
so
in
that
case
we're
tempted
to
deploy
something
of
which
we
have
a
dependency
right.
So
then
you
have
to
yes,
so
in
that
case
you
have
a
dependency
that
you'd
have
to
integrate.
You
know
like
in
this
case
you
have
autism,
you
know,
managed
app,
I'm
not
sure
that
it
would
be
the
same
setup,
though,
that
we
have
now
where,
like
maybe
there's
some
code
underneath
that's
supporting
the
map,
the
managed.
E
Like
I,
I
I
I'm
not
sure
entirely
how
the
managed
apps
work
internally
as
well,
but
it's
definitely
gitlab
specific
right.
We're
not
using
we're
not
just
pulling
an
image
from
somewhere,
but
I
guess
I
guess
you
know,
wouldn't
we
need
to
communicate
to
to
the
kubernetes
configuration
file
that
we
need
to
have
this
meter
approach,
because
unless
we
tell
it,
it
doesn't
know
to
pull,
it
doesn't
have
to
pull
it
and
we
and
we
wouldn't.
E
B
A
Over
so
I
think
we
can
go
ahead
and
end
this,
but
we'll
create
issues
for
follow-up
and
engage
on
that.
Thank
you
all
for
this
really
appreciate
your
time.