►
From YouTube: Steve & Sacha talk "Ortelius and GitOps POC"
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).
B
So
what
I'm
going
to
do
is
I'm
going
to
go
through
my
vision
of
the
gitops
around
captain,
argo
and
ortelius.
A
Can
I
can
I
can
I
give
you
some
feedback
just
quickly
now,
just
just
to
see
if
I'm
on
the
right
track
with
you,
like,
basically
your
source
of
truth,
being
your
repo
yeah?
Is
that
right,
so
you've
got
a
code
base
and
a
helm
chart
right,
and
your
argo
is
looking
at
your
helm,
chart,
obviously
for
any
changes:
correct,
okay
and
then
your
and
then
ortilius
is
like
the
grand
orchestra
got
grand
conductor
of
the
orchestra.
Basically,
all
these
changes
and
versions
that
are
being
pushed
and
pulled
it's
being
recorded.
B
B
It's
an
event
driven
pipeline.
B
All
right,
so
we
have
we're.
Gonna,
have
git
here
and
we're
going
to
have
a
developer
checks
in
source
code
and
that's
going
to
be
going
to
then
trigger
captain.
B
B
So
we
have
it
pushed
off
to
quay
and
what
ends
up
happening
is
captain
will
then
tell
ortilius
it'll
send
a
message
over
tortelius
push
has
been
done
and
that's
going
to
go
over
to
ortelius.
B
And
ortelius
is
going
to
then
it's
going
to
register
a
component
update,
so
we
get
a
new
component
version.
B
B
B
B
And
so
that
application
set
repo
basically
has
in
it,
which
other
repos
to
monitor
so.
A
B
B
B
B
It's
going
to
be
a
commit,
a
pr
if
it's
going
to
be
a
certain
directory
that
gets
updated.
It
will
monitor
that.
So
that's
on
the
argo
side.
So
it's.
B
B
A
A
A
B
A
After
after
captain
yeah
go
ahead,
the
initial
commit
is
ignored
by
argo,
yeah
and
and
but
not
otilius,
and
not
captain.
That's
right.
B
B
A
B
Yep,
so
this
is
so
from
there.
What
will
happen
is
after
the
build
and
push
captain
is
going
to
want
to
do
a
deployment.
A
B
Which
is
the
the
new
docker
image
so
we're
going
to
come
across
and
captain's
going
to
say:
okay
now
go
ahead
and
deploy
because
ortilius
at
the
application
version
here
is
looking
over
the
101
repos.
B
B
Now
what
that
means
is,
when
you
talk
about
your
helm,
we're
going
to
then
apply
to
the
helm.
Chart
that
shot
then
gets
applied
to
the
home
charts,
specifically
the
values
files.
A
B
Right
so
because
we
know
which
component
versions
have
changed,
we
know
which
values
need
to
be
applied
now.
What
ends
up
happening?
Is
we
go
back
to
these
repos
and
we
start
updating
them
again.
B
B
Each
of
the
microservice
repos.
A
To
each
of
yeah
that
makes
sense
to
me:
microservice
repo,
well
yeah,
so
go
back
to
the
it
goes
back
to
the
repos
now
and
it
updates
them
again
and
pushes
the
new
values
file
to
each
of
the
microservice
repairs.
Yeah.
That
makes
sense.
B
B
A
B
Now,
when
one
thing
that
we'll
need
we
have
to
do
is
we
have
to
know
when
argo
is
completed,
so
argo's
gonna
have
to
send
an
event
back
to
back
to
ortillius
to
the
deployment
process
out
of
completion.
A
B
Right,
so
we
just
want
to
make
sure
that
we
record
that
that
it
was
successfully
or
or
if
it
failed,
that
what
happened
so
argo
will
send
the
event
back
to
artelia,
saying
this
for
this
values
file
that
you
just
had
me
update.
I
completed
it
as
part
of
that
and
that
kind
of
wraps
up
our
our
process
for
like
a
ci
event.
Now
the
cool
thing
is
once
we
know
it's
been
completed.
B
A
B
A
B
Like
okay,
we
just
deployed
in.
A
B
B
Captain
content
can
tell
ortilius,
deploy
roll
back
that
deployment
and
just
deploy
the
minus
one
application
version,
and
what
will
happen
is
when
we
say
go,
deploy
the
minus
one.
Ortilius
would
go
and
update
the
repos
again
with
the
values
file
from
the
minus
one
version,
and
we
go
through
this
whole
process
again
with
the
quality
gate,
check
and
argo
keeping.
A
B
A
Of
a
bad
deploy
and
goes
where
they're
gonna
move
into
a
power
deployment,
and
then
it
notifies
notifies
of
tilius,
which
and
begins
rolling
back,
begins
the
rollback
process.
B
A
A
B
B
Basically,
what
we
need
to
do
now
is
now
that
the
source
code
is
passing
the
ci
level.
We
probably
want
to
go
ahead
and
do
our
final
build
to
push
it
down.
Do
our
merge
into
main
and
then
do
our
our
final
build.
So
that's
where
you
get
into
hold
the
into
the
whole
git
flow,
like
you
were
talking
about
of
how
you
tag
things
and
move
things
along,
but
basically
we've
done
our
ci
level,
we're
happy
with
all
that.
B
B
Well,
captain
would
go
on
to
the
next
stage
of
the
pipeline
and
we
want
to
go
ahead
and
merge
the
pr
onto
main
and
or
onto
like
the
the
system.
Integration
branch-
you
know,
however,
your
git
flow
is.
A
B
Yeah
so
once
we
once
we
quality
gauge
ci
and
we're
happy
with
that
ci's,
the
ci
environment
is
all
good
in
in
ci
or
dev.
Whatever
you
want
to
call
it
once
we're
happy
with
that
environment,
we
need
to
do
our
final
build
because,
most
of
the
time,
all
these
prs
are
happening
all
day
long.
You
don't
want.
A
B
You
have
to
do
your
merge
into
a
branch
to
get
your
code,
that's
on
your
pr
code
merged
with
the
main,
so
you
you're
you're
doing
your
integration
and
you're
figuring
out
your
merge
conflicts,
because
at
this
point
we
could
still
have
merge
conflicts.
So
if
you
change
something
I'd
change
the
same
code,
we
could
have
a
merge
conflict
and
we
need
to
resolve
that
as
part
of
our
git
flow.
A
B
Once
we
go
through
and
merge
our
our
coding
change
to
either
like
a
a
well-known
branch
or
into
maine,
that's
where
we'll
do
our
last
build
and
then
that's
when
we
we
start
over
again.
So.
A
Yeah,
I
see
what
you're
saying
so.
Can
I
just
recap
quickly?
So
it's
so
when
you've
got
nothing,
it
goes
in
right
and
it
does.
It
goes
through
its
process,
but
you
say
certain
things
will
be
some
some
part
of
the
process
will
be
ignored
by
which
one
was
it
again.
One
of
them
will.
B
A
B
A
B
Then
we
go
back
once
we
we
go
back
to
captain,
say:
captain
says:
okay,
deploy
it
and.
A
A
B
Well,
they
already
have
their
pr
on
their
incoming.
B
So
this
is
probably
going
to
be.
This
will
probably
be
the
pr
branch.
B
A
Example
and
then
and
then
obviously
developers
start
getting
branches
like
I
don't
know,
features
hotfixes
whatever
yeah,
okay,.
B
So
that's
the
first
time
through
and
we
go
through
do
our
deployment.
We
tell
captain
that
the
deployment's
done
captain
runs
his
quality
check,
everything's
good
now,
captain
because
it
has
a
pipeline
we'll
go
on
to
its
next
step
in
the
pipeline,
which
will
be
like
system,
integration
or
qa
or
whatever
you
want
to
call.
It
doesn't
really
matter,
but
that's.
A
A
So
captain
is
like
really
the
source
of
all
the
quality
gates
and
and
qa.
A
A
B
Yeah,
so
once
we
once
we
go
through
the
first
loop
for
ci,
the
quality
gate
is
good.
Now
we
have
to
we're
going
to,
we
could
either
stop
there
or
we
can
automatically
merge
that
pr
onto
main,
for
example,
or
onto
whatever
branch
you
want
to
call
it
doesn't
really
matter
whatever
your
git
flow
process
is.
A
Success,
basically,
pr
gets
merged
onto
main
yeah.
B
B
B
B
We
tell
come
back
and
tell
captain
that
the
deployment
into
qa
is
complete,
go
check
your
quality
gate
and
it
says
oh
everything's,
good,
on
the
quality
gate
for
qa.
Do
we
want
to
now
go
ahead
and
follow
our
git
flow
and
move
it
to
the
next
stage,
and
that
could
be
like
tagging.
You
can
add
another
tag
or
do
another
merge
from
qa
into
prod,
for
example,
on
the
branch
level
or.
B
So
there's
going
to
be
a
ci1
there's
going
to
be
a
qa1,
there's
gonna
be
a
prod
one
and
that
allows
the
git
repo
to
have
the
representation
of
that
cluster.
For
that
stage
of
the
life
cycle,.
A
And
then
you
have
different
stages
right.
You
have
your
different
stages
and
environments
in
your
values.yaml
yep
yeah,
I'm
very
familiar
that
okay.
That
makes
complete
sense.
B
Yeah
and
the
nice
thing
with
our
the
argo
application
sets,
is,
you
could
do
like
prod
dash
values,
dot,
yaml,
and
it
will
recognize
that
that's
the
production
one
or
you
could
do
qa
dash,
values.yeah,
mmo
or
ci,
and
it
that's
some
of
its
filtering
capabilities
that
allow
us
to
have
multiple
values.
Files
in
the
same
get
repo.
A
B
They
would
actually
because
the
application
sets
you
can
set
up
different
values,
file
for
each
stage.
A
B
Yeah,
so
that's
what
ortelius
is
doing
is
when
he
goes
to
deploy
each
one
of
those
values
files.
He
just
showed
me
in
discord.
A
B
Because
it
knows
the
image
tag
and
shock,
it's
going
and
updating
those
values,
files
checking
them
back
in
committing
them,
which
causes
argo
to
go
ahead
and
take
off
and
do
it.
B
That's
all
this
application
set
repository,
how
you
know
what
the
cluster
names
are.
B
A
Your
source
of,
like
kind
of
like
microservice
infrastructure,
really
yeah.
B
B
I
think
that's
a
good
way
to
describe
it.
It
basically
is
for
this,
this
microservice.
This
is
where
the
which
cluster
I
want
you
to
send
it
to,
for.
A
B
Or
namespace,
you
know
that
type
of
thing
is
kept
in
the
application
set,
that's
kind
of
like
the
you
can
think
of
it
like
the
deployment
configuration
file.
Is
the
application
set.
A
Yeah
it's
the
deployment.
It's
like
the
deployment
filing
or
kubernetes
really
is
that
right.
B
B
So
it
knows
about
all
the
different
deployments
that
need
to
happen
across
your
pipeline
for
for
this
application
that
we're
working
with.
So,
if
you
have
like
five
clusters,
it'll
know
how
to
to
what
the
cluster
names
are.
Those
type
of
things
for
the
different
stages
of
your
pipeline.
B
So
that's
kind
of
the
process.
It's
the!
If
you,
if
you
step
back
and
look
at
it,
you
know
you
have
your
your
your
change.
That's
happening
to
to
get
captains,
picking
that
up
telling
ortilius
about
it.
Ortilius
does
the
deployment
it
just
comes
back
and
tells
captain
that
it's
done
and
then
from
there
it
says:
okay,
we're
good
to
go
we'll
go
on
to
the
next
stage
of
the
of
your
get
process.
B
So,
like
the
the
your
git
flow,
you
know
how
you're
going
to
get
from
if
you're
going
to
do
branches
with
certain
names
or,
if
you're
going
to
do
certain
labels
or
whatever
it
doesn't
really
matter
to
us.
A
B
Can
you
can
have
developers
be
totally
oblivious
to
the
whole
deployment
process
and
they
just
go
in
and
change
their
one
microservice,
and
this.
A
B
Automatically
happen
for
them,
you'll
get
a
whole
new
application
version
moved
through
the
pipeline,
so
it'll
keep
everything
coordinated
and
tracked.
B
So
normally,
what
you'd
have
to
do
is
after
the
build's
done,
and
you
do
your
push.
You
have
to
go.
Take
that
image,
num
image,
sha
and
then
go
back
and
update
your
values,
file
manually
with
a
new
version
and
then
check
that
in
and
have
a
go.
But
then
you
know
you
don't
have
that
concept
of
an
application
version
and
argo
doesn't
really
have
a
a
concept
of
of
the
an
application
either
and
that's.
B
A
B
The
image
tags
you
can
go
monkey
around
with
them
and
and
change
them
to
point
to
just
like
latest
you
can.
You
know
how
you
can
always
move
latest.
That's
immutable
tags
are
mutable
where
the
digests
are
are
immutable.
B
So
if
you
ever
want
to
get
make
sure
that
you
you
have
the
exact
version
of
the
container,
you
should
be
using
the
digest.
Instead
of
a
tag
in
your
values,
file.
A
Yeah,
okay,
okay,
so
I
was
my
thinking
is
to
draw
this
first
as
a
diagram,
because
it
makes
it
easier
to
explain
right
and
to
weed
out
all
the
all
the
things
that
are
wrong
right,
yeah
that
I
got
wrong.
B
Yeah,
one
of
the
things
I
would
do
is
you
know,
lay
out
the
first
go.
A
A
B
The
final,
the
final
build
will
be
the
next
part.
A
B
B
Just
focus
on
on
the
first
first,
the
first
commit
get
that
that
laid
out
and
then
we'll
go
and
take
it
to
the
next
level.
Because
that's
where.
A
B
The
whole
git
process,
like
I
said
it,
will
be
slightly
different,
but
from
the
artillery
side
and
the
kept
inside
doesn't
really
matter.
It
all
happens,
the
the
same
from
there
on
out,
because
one
of
the
things
is
once
we
do
our
merge
into
main.
For
example,
that's
gonna
be
our
last
build
and
we'll
take
that
image.
A
Exactly
okay,
that
makes
sense
to
me
a
really
awesome
process.
Wow,
like
I
said,
I've
got
a
meeting
with
woodcock
tomorrow
morning
at
eight,
my
time,
so
just
to
get
some
captain
feedback
from
him,
but
yeah.
I
can
go
build
this
along
and
it's
cloud
agnostic
right
yeah.
This
is
totally
cloud
agnostic.
You
don't
need
to
worry
about,
be
anywhere.
A
A
B
Right
if
you're
anything,
we
get
confused
on
anything.
B
But
I'll
send
you
the
link
once
this
gets
produced.