►
Description
Ortelius leads a discussion with the open source teams of ArgoCD and Spinnaker around the concepts of grouping deployable objects together in 'sets' which can then be tracked and versioned via Ortelius.
A
B
A
A
A
A
And
for
all
of
the
ortillious
folks
that
are
on
the
call,
just
while
we're
waiting
the
cd
foundation
is
having
their
cd
con
2021
in
june
june
23rd
and
the
24th,
it
will
be,
of
course,
virtual
again
this
year,
ortillas
will
have
some
speaking
slots.
So
please
reach
out
to
me
if
you'd
like
to
speak,
and
I
have
sent
the
I'm
going
to
send
everybody
the
link
again
to
make
sure
you
guys
are
aware
that
you
can
submit
talks
on
artillies
for
cdcon.
A
A
A
They
wanted
to
know
if
we
could
track
relationships
between
those
and
and
lock
those
together
in
a
deployment
and
then
track
who's
consuming
that
set
of
microservices
and
some
of
my
kind
of
snooping
around
with
argo.
I
noticed
that
argo
was
talking
about
application
sets
and
the
argo
folks
sent
over
to
the
artillious
team,
some
very
interesting
webinar
or
information
about
what
argo's
doing
around
what
they
call
application
sets,
and
it
turns
out
that
those
are
very
similar.
A
So
what
I
had
hoped
to
do
with
this
group
is
to
bring
everybody
together
to
acknowledge
that
there
is
a
specific
issue
here.
That
argo
has
is
trying
to
solve
that
spinnaker
may
be
trying
to
solve
and
where
ortilius
the
open
source
project.
That's
now
part
of
the
cd
foundation
could
potentially
step
in
and
do
that
configuration
management
and
pass
it
off
regardless
of
what
deployment
solution
anybody
is
using,
and
so
that's
how
this
conversat
conversation
begun
steve.
Would
you
like
to
add
to
that
in
any
way.
C
Just
the
one
thing
that
we
have
noticed
is
that
there's,
even
though
in
the
microservice
world
microservices
are
supposed
to
be
independently
deployable
and
basically
have
their
own,
like
workflow
or
pipeline
to
get
from
a
developer
change.
You
know
get
check
in
all
the
way
out
to
production
that
loosely
coupledness
doesn't
always
apply,
and
that
there
are.
C
There
is
a
need
for
tightly
coupling
a
a
set
of
versions
of
some
services
together
into
a
set,
and
that's
one
of
the
things
netflix
brought
up
when
we
were
talking
to
them
so
and
that's
kind
of
where
we've
been
trying
to
wrap
our
heads
around
how
other
deployment
tools
are
viewing
this.
This
problem
space
of
microservices
on
their
own,
but
also
microservices,
that
need
to
be
tightly
coupled
and
how
they
roll
up
into
a
logical
view
of
an
application.
C
C
A
D
So
the
application
is
already
been
kind
of
well
conceived
and
has
been
working.
The
next
level
of
the
application
set
that
we
introduced
in
may
of
last
year
was
we
found
the
need
to
have
a
higher
level
grouping
logical
grouping
of
applications
under
an
umbrella
called
the
application
set,
and
so
the
application
set
can
be.
There's
several
use
cases
that
we
see.
D
The
first
was
that
we
wanted
to
group
and
deploy
applications
as
a
unit
where
we're
deploying
across
clusters,
so
maybe
like
a
controller,
goes
into
a
100
different
clusters,
and
so
when
I
want
to
make
a
change
to
that,
I
update
the
application
set
and
100
controllers
are
automatically
updated
because
they're
part
of
the
set
there's
kind
of
on
the
other
side
of
the
use
case
where
it's
not
homogeneous.
There's,
let's
say
you
have
a
git
repo
and
every
directory
of
that
git.
D
Repo
is
some
component
of
a
higher
level
application,
but
those
individual
repos
are
maybe
maintained
by
separate
teams,
and
so
each
team
can
contribute
to
their
own
path
inside
that
git
repo,
but
as
a
as
a
whole
as
they
make
changes.
The
the
set
can
deploy
their
unit,
the
application
individual
individually
as
they
update
their
repo.
D
It
so
actually
there's
no
application
set
repo
a
well.
Our
application
set
is
actually
a
a
generator
of
applications,
so
the
the
pointer
to
repos
are
always
in
the
application,
and
the
application
set
defines
how
to
generate
the
definition
of
application,
so
that
gener,
that
generator
concept
is
like
iterate,
a
a
reap,
a
get
repository
or
traverse
a
git
repository
and
discover
stuff
or
maybe
gets
it
from
some
other
source,
but
but
the
so
yeah.
The.
D
F
Okay,
alex
here
I'm
another
maintainer
of
argo.
I
just
wanted
to
clarify
that
application
set
basically
adds
no
functionality,
nothing
new
to
argo
cd.
Everything
can
be
done
using
applications,
but
the
problem
is
that
people
have
to
create
applications
manually
right
now
and
we
identified
set
of
patterns
which
repeated
frequently
it's
a
very
common
case,
where
people
want
to
create
an
application
per
cluster
or
application
per
per
folder
in
repository,
and
that's
so
application
set
simply
makes
it
easier
kind
of.
C
F
Exactly
yes
and
people
started
from
so
we
have
up
of
apps
pattern,
so
app
application.
Argo
cd
application
is
a
cid.
So
technically
you
can
create
it
manually
in
kubernetes,
using
qptl
apply
as
well
as
you
can
create
home
chart
and
home
chart,
creates
applications,
and
then
you
can
create
application
which
points
to
a
home
chart
which
will
create
applications,
but
the
problem
is
you
still
need
to
maintain
that
home,
chart
and
application
said
because
application
said
it?
F
No,
it's
not
trying
to
be
another
templating
language,
it
kind
of
it's
focused
on
specific
use
cases.
That's
why
it
is
a
little
easier
than
health
chart,
but
options
are
you
can
manually,
run,
qctl
applies
and
create
applications,
or
you
can
use
helm
and
generate
bunch
of
applications
and
application
sets
supposed
to
be
the
most
convenient
way
because
it
solves,
like
particular
use
cases.
Okay,.
C
G
Over
the
years,
we've
made
a
couple
of
couple
of
stabs
at
that
internal
to
netflix.
They've
been
somewhat
adopted,
but
not
well
enough
for
us
to
kind
of
continue
that.
So
at
this
point,
we're
kind
of
looking
for
a
like
we're
still
looking
for
we're
still
looking
for
alternatives,
so
we've
called
them.
We've
called
them
projects
in
like
historical
spinnaker
terminology,
and
it's
been
the
kind
of
logical
groupings
of
applications,
but
it's
been
more
for
the
visibility
of
of
applications
and
their
dependencies
and
then
various
resources
and
and
their
deployment
strategies.
G
What
we,
what
we
struggle
and
the
challenges
we
need
to
tackle
is
the
grouping
the
definitions
of
the
requirements,
so,
let's
say,
say
a
service
owner
like
myself.
We
we
own
spinnaker
spinnaker
itself,
is
10
or
15
applications
at
netflix,
and
we
don't
want
to
have
to
deal
with
the
individual
aspects
of
the
applications
like
we
want
to
say:
hey.
G
F
B
Yeah,
so
this,
I
also
think
of
this.
This
is
guppy
now
opsimix.
We
also
see
the
application
concept
as
a
group
of
these
services
right.
One
of
the
use
cases
I
think
we're
discussing
here
is
you.
You
have
different
environments.
You
want
to
have
one
environment
promoted
to
another
environment,
with
certain
number
of
services
that
go
together.
B
So
that's
again,
a
one
grouping
of
the
services
that
are
going
with
it
and
the
configuration
part
of
it
so
right
now
this
spinnaker
we
don't
have
built
in
this
is
something
that
of
course,
being
thought
through.
It
is
generally
done
at
a
next
level,
one
more
layer
on
top
of
curved
spinnaker
applications.
B
Application
is
set
up
microservices
the
way
the
spinnaker
is
designed
for
the
devops
individual
services,
continuous
delivery
right,
but
we
also
support
for
kubernetes
kind
of
environments.
You
have
an
application
defined
through
helm,
charts
or
customized
packages.
Those
can
be
deployed
too,
so
the
collection
of
those
together
is
what
you
categorize.
The
application.
D
C
D
Right,
that's
an
application
and
then
the
application
set
our
concept.
The
application
set
is:
is
a
higher
level
object
on
top
of
applications,
because,
basically,
in
argo
cd,
this
the
smallest
deployable
unit
is
an
application.
So
that's
that's
what
you
deploy
as
a
set
is
helps
you
assist
with
the
automation
of
deploying
all
of
those
those
units
right
right.
C
I
know
there's
another
open
source
project
out
there
from
ibm
called
razer.
That
is
addressing
it.
The
similar
way
that
you
guys
are
for
argo
with
being
able
to
manage
a
deployment
across.
You
know
hundreds
of
clusters
and-
and
you
know,
passing
in
data
at
dynamically
doing
that
at
deployment
time
now
and
on
the
on
the
spinnaker
side.
What
is
the
your
smallest
deployable
unit
that
you
you?
You
typically
work
with.
G
Basically,
I
mean
it's
very
it's
very
similar
vm
vmware
container
would
be
the
like.
Smallest
smallest
deployment,
artifact
and
an
application
is
typically
single
service
and
supporting
infrastructure
and
resources,
but
again
similar
to
what
jesse
described
there.
It's
up
to
the
implementer.
If
you
want
to
have
multiple
containers
or-
or
you
want
to
do,
multiple,
like
vm
deployments
inside
your
application
kind
of
boundaries,
we
don't
like
we,
we
allow
that.
That's
fine
right.
B
C
My
my
web
front
end
my
my
website
and
that
website
is
running.
On
top
of
you
know,
10
containers
and
I
want
to
deploy
my
website
and
I,
when
I
go
to
do
that,
is
the
is
it
going
to
be
grouped
together?
Those
container
deployments
to
kubernetes
is
going
to
be
done
at
the
workflow
level,
or
are
you
going
to
have
a
separate
workflow
for
each
one
of
those
individual
containers.
B
It's
up
to
the
user.
So
if
you
have
a
helm
package,
that's
deploying
the
all
10
containers
they
could
do
it
that
way,
but
typically
on
a
continuous
delivery
mechanism
right,
you
would
be
doing
one
resource
at
a
time
assuming
there
is
no
other
dependencies
for
it
and
you
can
choose
to
do
blue,
green
or
canary
and
then
we'll
building
update
on
top
of
it.
C
B
B
So
you
have
these
constructs
of
this
pipeline
that
allow
you
to
deploy
using
a
deploy
stage
and
then
once
they
are
deployed,
the
application
state
is
reflected.
We
have
the
cluster
view
or
application
cluster
view
where
you
could
go
and
see
what's
currently
deployed
what
are
the
state
of
each
one
of
the
services
that
you're
running
there.
C
C
D
D
F
F
A
I
A
Yeah
so
steve,
you
want
to
summarize
right
now,
what's
in
your
head
and
and
isaac,
and
all
we
are
one
of
our
you
know,
I
call
them
our
big
rocks
for
the
community.
This
this
first
quarter
is
to
really
get
the
requirements
down
for
understanding
this
particular
use
case
and
adding
those
configurations
into
our
metadata
in
our
configuration
repository.
A
So
that's
the
prime
one
of
the
primary
reasons
for
this
call.
What
we'll
be
doing
is
we'll
put
together
a
requirements
document
that
will
send
out
to
everybody
that
was
on
this
call
to
get
some
feedback,
we'll
probably
put
it
in
google
docs.
So
you
can
respond
to
it
steve.
You
want
to
try
summarizing
right
now.
How
you
see
this
particular
use
case
and
kind
of
what
an
application
set
is
and
how
we
might
interface
to
it.
C
Dynamic
data
coming
into
the
deployment
process,
for
example,
moving
from
deploying
from
five
clusters
to
100
clusters.
That
is
where
that
dynamic
data
is
coming
in,
but
the
end
of
the
day.
The
application
set
from
the
argo
side
is
still
deploying
an
application
just
being
pushed
in
different
data
at
deployment
time
through
the
application
set
control
plane.
So
but
the
higher
level
that
doesn't
seem
to
exist
in
either
solution
is
the
concept
of
a
logical
view
of
an
application.
C
How
are
how
are
these
applications,
or,
I
should
say,
let's
call
them
a
product,
a
logical
view
of
a
product
that
is
going
to
group
together,
multiple
applications
and
the
versions
of
those
applications.
So
we
can
see
how
they
move
through
the
pipeline
from
development
through
qa
to
through
production.
Is
that
close.
A
G
D
A
So
it
turns
out
that
apple
this
con
this
problem,
that
application
sets
addressing,
isn't
unique
just
to
argo,
end
users.
It's
we
have
customers
ourselves
that
are
starting
to
use
what
we
call
an
application
in
some
interesting
ways
so
and
jesse.
I
don't
know
how
much
you
know
about
ortillius,
but
artelias
is
basically
think
about
it
as
a
microservice
configuration
management,
repository
or
database.
A
We
track
and
map
relationships
between
microservices
and
the
applications
that
consume
them,
and
we
know
we
we
need
to.
We
potentially
need
to
have
a
middle
grouping,
which
would
be
we
call
them.
We
would
we
started
calling
them
component
sets,
so
it
seemed
as
if
argo
was
talking
about
it
in
one
way,
we're
all
seeing
that
you
know
it's.
A
I
Yeah,
can
you
guys
hear
me?
Okay,
my
internet
is
not
great.
Today,
yeah,
I'm
seeing
actually
this
prob,
this
be
a
fairly
big
problem,
especially,
I
think
on
the
on
the
spinnaker
side,
because
there
is,
there
is
some
sort
of
grouping,
but
not,
I
think,
grouping
in
the
way
that
certain
customers
want
it
to
be
grouped.
I
I
think
a
tool
like
this
is
really
helpful
because
they're
evolving
so
fast
from
you
know
one
application
to
10
applications
and
what
that
means.
How
do
you
group
it?
How
do
you
have
the
metadata
around
it
that
I
think
this
is
a
pretty
big
space
or
problem
that
people
are
running
into
and
adam?
Do
you
think
that's
a
right
assumption
that
I
made
with
spinnaker
and
the
comfort
with
microservices
that
netflix
said.
C
E
E
D
D
I
don't
want
to
script
a
sync
100
times
across
those
100
clusters,
I'd
like
some
other
higher
level
button
or
not
button
but
spec
to
both
facilitate
the
the
specifications
of
those
applications
and
also
to
logically
group
them
as
a
as
a
higher
level
deployable
unit
so
to
speak.
But
if
they're
I'll
stop
there
yeah.
C
So
in
in
the
the
primary
use
case
that
you
had
was
to
that
you're
running
up
against
was
I
have
this
application
that
needs
to
be
redeployed
to
a
different
environments,
being
qa
production
and
within
those,
let's
say,
within
the
production
environment.
You
need
to
go
out
to
every
single
region
in
aws,
and
you
know
a
cluster
in
every
single
region
and
the
our
application
set
was
going
to
give
you
the
capability
of
doing
that
in
one
pass.
Instead
of
scripting
it
for
every
single
region,.
E
So
one
other
clarifying
question,
so
is
the
application
set
just
logically
a
bucket
of
applications,
or
are
you
actually
adding
the
logic
for
like
what
you're
saying
so
like
the
deploy?
Logic
would
be
associated
with
the
application
set
and
then
it
would
be
like
applied
to
everything
underneath
it.
That's
a
good
question.
D
C
G
B
When
we
are
talking
about
this
application
deployment.
This
is
a
view
where
we
take
one
group's
application
set
of
services
that
they
have
with
their
configuration
and
actually
do
a
deploy,
and
the
product
view
is
something
that
you
don't
deploy
as
part
of
your
group.
But
you
want
to
have
a
view
of
what
makes
your
entire
product
come
to
come
alive
right.
C
Sorry,
yeah
yeah
exactly,
and
I
I
think
we're
going
to
have
that
covered
where
both
use
cases
would
be
handled
on
the
artelia
side.
As
part
of
that
now,
just
to
give
you
just
a
quick
view
of
how
artelius
would
fit
into
this
in
in
the
process
of
the
when
the
deployment
actually
occurs
and
the
cluster
gets
updated,
we
would
want
to
just
get
notified
that
x,
y
and
z
got
updated
in
in
cluster.
You
know,
25.
C
with
that
information.
We
can
complete
the
relationship
map
and
manage
those
relationships
to
bring
you
bring
the
visibility
up
from
you
know,
roll
it
up
to
the
product
view
saying
this
product
a
is
in
qa,
and
it
consists
of
these
parts,
and
these
parts
are,
you
know,
made
up
of
different,
could
be
vms
or
containers
doesn't
matter
to
us,
but
that's
what
we're
looking
at
from
the
the
use
case,
standpoint.
A
Okay,
we
have
taken
40
minutes
of
everybody's
time.
I
want
to
thank
everyone
for
taking
the
time
to
discuss
this
with
us.
It's
been
extremely
helpful.
We
will
work
on
a
requirements
doc
and
make
sure
that
we
send
it
out
to
all.
So
you
can
see
how
we
summarize
this
and
from
that
doc
we'll
be
working.
C
And
just
to
let
you
know
we're
not
that
far
off
from
what
we
just
with
what
we
discussed
like
like
jesse,
was
saying:
it's
it's
more
of
a
everybody
calling.
You
know
this
different
things,
the
same
name
that
can
make
things
very
confusing,
really
quick!
Yes,
so
this
definitely
helped
clarify
for
us
whatever
how
how
people
think
of
the
world.
A
H
D
A
D
C
Yeah
I
read
through
your
spec
and
your
looked
at
your
code
on
how
you're
implementing
the
controller,
and
the
part
that
I
was
getting
tripped
up
on
was
the
what
people
name
things
so
that
that's
where
today's
meeting
really
came
in
and
helped
understand
what
is
an
application?
What
is
a
deployable
unit?
Those
concepts
really
help
solidify
what
you
had
in
your
your
spec,
okay,.