►
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
C
C
Expansion
day
or
I
don't
know,
if
all
you
can't
please
observe
this
in
sweden,
it's
probably
called
day-
I
know
maybe
in
germany
as
well,
but
yeah.
Yes,
you
know,
like
I
missed
this
whole
day.
So
that's
why
I,
I
kind
of
you
know
thought
of
today
as
the
day
to
have
a
cartographer
present,
but
the
meetings
and
the
presentation
will
be
recorded.
So
anyone
who
misses
the
meetings
they
can
watch
it
afterwards.
C
Okay,
so
zoom
wants
to
quit,
but
I
am
not
doing
that
so
what
I
will
do.
I
will
just
walk
through
the
agenda
which
I
passed.
The
link
to
chat
as
well.
Instead
of
you
know,
closing
my
zoom
client
and
opening
it,
and
then
we
have
very
light
agenda
and
we
can
spend
most
of
the
time
for
the
presentation,
demo
and
discussion
on
cartographers
and
then,
if
anyone
wants
to
bring
up
an
additional
topic,
you
can
do
that
at
the
time
I
lost.
C
So
the
first
thing
on
the
agenda
is
actually
nothing
real.
We
don't
have
any
action
items
from
previous
meetings
and
the
second
topic
is
on
about
the
open
prs
we
have
the
first.
Pr
is
about
the
proof
of
concept
we
have
been
discussing
for
last
couple
of
weeks
and
that
work
starts
on
hack
md,
but
because
of
some
limitations
with,
I
can
be
like
not
getting
notifications.
C
But
that
was
on
purpose,
because
I
want
to
get
feedback
around
stages
first,
and
if
people
agree
on
the
stages
as
a
starting
point,
then
we
can
start
going
to
details
of
all
these
stages
and
look
for
existing
steps,
pipeline
steps
and
create
new
ones.
If
we
can't
find
a
step
we
can
use
so
again.
These
are
just
on
these
two
repositories
open
for
feedback
and
if
any
of
you
is
interested,
you
know
take
part
in
the
proof
of
concept
or
contribute
to
stages
vocabulary.
Please
go
ahead
and
comment
right
on
the
pr's.
C
So
that
was
another
topic
we
had
before
we
moved
to
cartographer
presentation.
Anyone
wants
to
say
anything
about
these
prs.
I
know
terry,
you
had
some
concerns
about
proof
of
concept
being
oriented
around
open
source
software,
and
I
can't
respond
to
your
comment
on
hackmd
saying
that
we
don't.
You
know
we
can
perhaps
start
with
open
source
software
to
bring
the
basics
in
place
for
the
proof
of
concept
and
then
look
for
opportunities
for
thinking
about
more
enterprise
or
commercial
aspects.
C
D
D
So
I'm
going
to
talk
a
little
bit
about
cartographer,
which
is
a
you
know,
a
kind
of
vmware
open
source
project,
the
there's
some
kind
of
software
supply
chain
stuff
in
here,
but
it's
it.
You
know
it's
focused
on
general
presentation.
What
is
the
project?
How
does
it
solve?
You
know,
problems
in
the
space
feel
free
to
stop
me
at
any
point
and
ask
questions.
You
know
not
a
huge
group.
We
can.
It
can
be
kind
of
informal.
D
So
you
know
I'll
start
with.
There
are
a
ton
of
kubernetes
native
ci
cd
tools
now
right.
So
it's
the
space
is
kind
of
getting
crowded.
There's
you
know
flux
and
argo
and
tecton.
You
know.
Argo
also
has
our
workflows,
which
kind
of
looks
like
tecton
in
some
ways:
right,
shipwright
and
vmware.
We
have
an
open
source
project
called
kpac
that
does
cloud
data,
build
packs
project.
D
There's
carvel,
you
know
it
kind
of
handles
deployment.
There
are
a
lot
of
of
interesting
tools
in
the
space
that
solve.
You
know,
cicd
problems
and
all
these
tools
present
a
kubernetes
native
interface.
They
use
crds,
as
they're
kind
of
you
know,
level
triggered
interactions
as
their
way
to
provide
a
user
interface
into
what
they
do
and
so
at
vmware
we
looked
at
kind
of
that
that
ecosystem
and
said
you
know:
can
we
build
an
application
platform
that
is
really
an
extension
to
kubernetes?
D
You
know
using
these
tools
right
and
provide
users
with
a
kind
of
secure
software
supply
chain
that
meets.
You
know
I'll
kind
of
go
into
this.
A
little
bit.
You
know,
operator
and
developer
needs
at
the
same
time
right,
and
so
you
know
the
way,
we're
thinking
about
this
abstractly
is
you
know?
Well,
can
we
take
these
tools?
D
Like
you
know,
say,
flux
to
you
know,
monitor
a
git
repository
for
for
changes
and
hook
that
up
to
techton
to
run
some
unit
tests,
and
then
you
know
once
those
tests
pass,
give
the
source
code
to
you
know
a
capex
image
resource
to
kind
of
build
an
image
and
keep
that
image
up
to
date
with
security
vulnerabilities
and
then
you
know,
generate
some
kubernetes
configuration
you
know
and
deploy
an
application
using
carvel
and
maybe
use
tekton
to
run
smoke
tests
against
it
or
something
like
that.
We
were
thinking
about.
D
How
can
we
take
these
tools
in
the
space
and
create
a
kubernetes
native
application
platform
using
those
tools
right?
A
big
aspect
of
this
is,
you
know
everybody
has
different
opinions.
You
know
different
problems,
they're
trying
to
solve
right.
How
can
we
keep
those
tools
swappable?
So
when
you
want
to
use
you
know
argo
instead
of
carvel,
it's
an
easy
thing
to
do
right
and
at
the
same
time,
especially
relevant.
I
think
here.
How
can
we
allow
you
to
integrate
different
tools
in
the
ecosystem
into
this?
D
You
know
kind
of
a
set
of
services,
so
you
can
assign
images
with
cosines
pressing
store,
so
you
can
maybe
scan
images
using
gripe
or
do
you
know
static
analysis
using
you
know.
Other
tools
right-
and
I
think
kind
of
a
big
principle
here-
is
that
we
wanted
to
create
a
self-serve
developer,
focused
application
platform
using
those
tools,
but
that
also
you
know
kind
of
lets.
An
operator
define
a
path
to
production
through
them
right
that
kind
of
balances
concerns
for
those
two
personas
and
you
know
again,
abstractly
the
way
we
thought
about.
D
D
Another
another
thing
we
were
really
influenced
by
you
know
I
think
captain
had
some
good
blog
posts
on
this
idea.
Like
you
know,
orchestration
versus
you
know,
having
kind
of
cicd,
microservices
or
choreography
right
as
a
word,
some
folks
will
use
that
you
know.
Instead
of
focusing
on
how
can
we
build
individual
imperative
tools
that
get
executed?
D
You
know
to
form
a
pipeline?
How
can
we
treat
the
different
tools
like
microservices,
and
you
know
think
about
you
know?
Instead
of
this
is
the
image
building
step
right.
This
is
the
image
building
service,
and
maybe
you
know
in
the
case
of
k-pac,
when
a
new
dependency
is
available
that
patches
a
cde
instead
of
having
to
run
the
pipeline
from
the
beginning.
D
You
just
rebuild
the
image
for
that
one
component
and
that
kind
of
in
a
declarative
and
level
triggered
way
gives
you
a
new
copy
of
your
deployment
at
the
end,
and
so
the
solution
we
came
up
to
or
this
sorry,
the
solution
we
came
up
with
in
the
space
is
called
cartographer
and
you
know
I'll
kind
of
go
through
the
different.
You
know
pieces
of
cartographer
and
how
it
kind
of
implements
that
that
vision
was
talking
about.
D
D
The
kind
of
key
thing
here
is
this:
isn't
a
linear
pipeline?
It's
not
an
execution
of
these.
These
things
in
a
row.
It's
really
persistent
mutable
crs
that
are
created
and
the
way
data
is
passed
between
them
from
the
status
of
one
to
the
spec.
You
know
to
spec
of
another,
and
so,
if
you
look
at
one
of
these
templates,
you
see
like
this
is
our
template
for
a
kpac
image,
which
is
a
resource
that
continually
rebuilds
images
with
new
sources
available
or
new
dependencies
become
available
through
the
build
pack
model.
D
You
know
with
with
kind
of
an
operator
control
plane
there
and
you
can
see
in
the
template.
You
know
there's
an
input
like
the
source
url
coming
from
previous
stage
and
there's
an
output.
You
know
where,
in
the
status
the
resource
to
look
when
that
status
gets
generated
for
a
new
image
to
get
generated,
and
so
cartographer's
job
is
to
stamp
out
that
kpac
image
and
then
keep
it
up
to
date
over
time
by
reapplying
this
configuration
as
the
inputs
change
and
so
to
kind
of
visualize
this
a
little
bit.
D
You
know
if
it
wasn't
clear
what
I
was
talking
about
there,
the
if
you
imagine
you
have
a
cluster
supply
chain
resource.
You
know
applied
to
your
cluster.
It's
a
it's
a
list
of
references
to
templates,
and
you
know
it's
going
to
pass
kind
of
typed
information.
You
know
commits
of
source
code
or
images
between
those
templates
in
a
way
where
you
know.
D
We
for
some
some
tools
like
techton,
which
work
you
know
like
tecton,
is
a
tool
where
you
define
a
pipeline,
or
you
know
a
piece
of
functionality
it
has.
Is
you
define
a
pipeline
and
then,
whenever
you
want
to
run
the
pipeline,
you
create
a
pipeline
run
resource,
and
so
in
order
to
kind
of
transform
that
from
these
sort
of
immutable
pipeline
runs
into
something
that's
continually
running
a
pipeline.
D
D
So
it's
a
little,
you
know
kind
of
immutable
to
mutable
state
translator
and
that
was
necessary
for
things
like
tekton
and
argo
workflows
when
you
want,
if
you
want
to
integrate
that-
and
so
you
know
the
you
know
really,
a
big
part
of
the
goal
here
is
to
create
a
self-serve
developer,
focused
application
platform
right,
and
so
the
input
to
this
is
a
really
simple
resource
right.
If
you're
a
developer,
you
know,
all
you
need
is,
you
know,
create
one
resource
in
the
cluster
that
says:
here's
where
my
source
code
lives.
D
You
know
look
at
this
branch
for
updates
right.
Maybe
you
want
to
specify
some
environment
variables,
you're
building
a
go
app
and
you
want
to
turn
c
go
off
or
something
like
that
right.
But
it's
we
wanted
a
really
simple
developer
configuration.
You
know
with
maybe
progressive
complexity.
Right
as
you
need
more.
You
know
you
need
to
break
more
glass,
you
can
break
more
glass,
but
the
entry
point
is
very
simple,
so
the
you
know
when
a
developer
creates
one
of
those
workloads
in
a
namespace,
a
cluster
supply
chain.
D
It's
looking
for
changes
in
the
status
and
moving
them
to
the
spec
of
you
know:
resources
further
down
the
chain
using
you
know
by
restamping
those
resources
out
using
the
kind
of
templates
I
showed
earlier,
and
we
also
you
know
this
isn't
just
you
know.
This
is
very
configurable
in
some
ways
too.
So
as
a
developer,
you
can
bring
a
tactile
pipeline
yourself
that
runs
your
unit
tests
and
then
pass
the
name
of
that
pipeline
through,
so
that
the
pipeline
runs
at
the
unit
test.
B
Thanks
could
I
share
it
screen
sticking,
please
awesome
so
differently
from
stephen
I'll.
Take
the
like
mad
scientist
approach,
everything
on
the
terminal.
I
tend
to
go
a
little
fast
but
feel
free
to
like
interrupt
me
at
any
time,
I'll,
try
to
repeat
myself
until
time's
true,
so
everybody
can
get
on
the
same
level.
B
So
we
can
like
start
thinking
about
if
we
were
to
create
a
platform
like
what
could
we
do
like
if
we're
just
to
describe
at
a
high
level
what
we're
trying
to
offer
to
our
customers,
like
putting
the
app
operator
had
the
platform
operator.
Had
my
customers
me
the
development
teams
in
my
company,
my
org.
A
B
What
they're
here
to
do
they're
here
to
code,
their
app
they're
in
these
companies
provide
value,
and
they
know
very
very
well
it's
about
go
about
java.
Who
knows
right.
They
know
about
their
application.
They
want
to
just
provide
the
description
of
where
their
app
is
and
have
it
going
through
the
system.
So
they
can.
You
know,
focus
on
on
their
main
job,
so
I'm
as
a
dev
developer,
just
like
telling
the
system
where
my
code
is
and
what
that
is.
B
Now,
what
should
this
platform
do
so,
taking
the
examples
that
stephen
was
talking
about
of
you
know,
picture
coach
repo
run
some
tests,
then
you
get
an
image
and
then
deploy.
We
could
express
that
in
this,
like
scratch,
space
that
we're
just
thinking
here.
So
you
know
that
pushes
code
to
the
repository
next
thing
that
you
would
expect
to
happen
as
a
dev
while
tests
are
executed,
then
can
tear
image
gets
spewed
and
then
somehow
the
application
gets
deployed.
B
And
then,
when
we
look
at
the
like
the
kubernetes
landscape,
you
could
thin
def
landscape
or
any
one
of
those
you
start
seeing
that
yeah.
There
are
some
pretty
good
tools
out
there
that
do
the
job
that
we're
trying
to
accomplish
here
right,
like
stephen,
was
showing
there's
flux,
git
repository
for
let's
say
keeping
track
of
those
commits
that
lands
in
the
repository
before
running
the
test.
Well,
tecton
is
great
right,
provides
all
these
primitives,
like
text
and
pipeline
tasks
and
so
forth,
and
for
being
a
container
image.
B
Well,
then,
we
also
have
a
lot
of
projects
here,
like
shipwright,
we
have
k-pac,
we
could
do
like
tactile,
plus
canico
mechanical
image
like
there
are
tons
right,
but
ultimately
the
line
of
thought
is
the
same
here
in
this
kubernetes
landscape.
There
are
all
sorts
of
projects
out
there
that
do
their
job
really
really.
B
Well,
I'd
really
like
to
just
be
able
to
pick
and
choose
some
of
them
to
build
my
platform
and
then
final
portion
here
application
getting
deployed
that
could
be
either
like
stephen
was
saying,
like
argo
could
be
cap
controller
so
on
and
so
forth.
It
could
be
anything
that
deploys
some
kubernetes
configuration
into
the
cluster
so
cool.
B
B
Then
you
can
think
of
something
that
like
in
its
back,
you
put
a
revision
there
and
it
started
as
it
says,
hey.
This
is
the
revision
that
that
successfully
did
what
it
was
supposed
to
do
then
wow,
that's
something
that
I
could
pass
forward
again
so
similar
to
get
repository
where
maybe
nurse
back
you're
saying
hey.
This
is
my
url
on
the
branch.
Give
me
a
revision,
giving
a
revision.
B
B
Well,
what
would
be
the
status?
Well,
if
you
look
at
kpac
image
resource
or
even
if
you
look
at
the
let's
say
the
techno
mechanical
task
from
the
the
catalog,
you
see
that
it
always
reports
something
that's
like
a
latest
image
like
the
image
that
got
viewed
and
placed
to
an
image
registry
and
well.
That
could
be
the
thing
that
we
passed
to
the
next
resource
here.
So,
for
instance,
it
could
be
that
I'm
deploying
canadian
service-
or
maybe
actually
one
deployments
like
anything
that
that
deploys
kubernetes
objects.
B
Well,
if
this
thing
takes
a
configuration
that
has
that
image
that
got
built
right
here,
then
we
can
intuitively
start
getting
the
sense
of
oh.
What
I'm
trying
to
do
here
is
take
something
from
this
back
that
service,
reconciles
whatever
you're
trying
to
do
at
that
stage
of
your
supply
chain
and
take
that
output
then
pass
forward
to
the
next
resourcing
that
chain
take
the
output
pass
to
the
next.
Take
that
output
pass
through
the
next
so
and
so
forth.
B
So,
if
you
think
about
cartographer
as
this
controller,
that's
taking
these
objects,
they
got
stamped
out
and
applied
to
the
cluster
looking
under
status,
then
updating
other
objects
in
that
chain.
You
can
see
that
what's
missing
here
is
providing
this
like
linking
between
these,
these
different
resources.
Right
and
again,
that's
where
cartographer
comes
in
place.
This
is
where
that
object.
That
stephen
was
showing
comes
in
place,
which
is
the
cluster
supply
chain
in
the
cluster
supply
chain.
B
What
you're
doing
is
you're
defining,
essentially
a
graph-
that's
saying
that,
for
instance,
the
the
tests
they
need
to
take
a
revision
from
something
that
provides
revisions
for,
let's,
say
the
the
image
builder
resource.
What
you're
declaring
is
like?
Oh,
I
I
know
how
to
stamp
out
something
that
builds
container
images,
but
I
need
a
revision,
and
so
you
link
this
this
imageviewer
resource
to
this
source.
Tester.
B
If
you
were
to
let's
say
my
company,
doesn't
do
tests
for
some
reason.
What
you
do
take
that
that
resource
out
of
your
supply
chain
and
wow.
This
thing
takes
a
revision
right.
This
thing
gives
you
a
revision,
so
you
can
like
link
them
together,
and
so
what
you're
landing
on
here
is
a
very
like
flexible
way.
For
you
to
view
what
your
software
supply
chain
can
look
like,
where
you
can
both
replace.
B
They
they
do
like
they
are
very
into
tests,
and
then
maybe
there
you
have
a
supply
chain
that
has
like
extra
extra
resources
to
do
different
things
that
other
supply
chains
don't,
but
ultimately
going
back
to
the
beginning
as
a
platform
operator,
you're
able
to
create
essentially
this
kind
of
dependency
graph
between
kubernetes
resources
and
so
by
doing
all
of
this
in
a
like
level,
trigger
manner
we're
able
to
also
achieve
what
stephen
was
mentioning,
which
is
this
notion
of.
If
there
is
anything
that
happens,
let's
say
cape
back
here
in
the
middle.
B
B
B
B
Then
we
get
this
automatic
like
redeployment
in
this
case,
because
now
there's
a
difference
here
and
then
cartographer
goes
to
kubernetes
and
implies
that
change
so
stepping
back
a
little
bit
of
ascii
art.
So
this
is
from
our
examples
in
the
photography
repository
being
like
super
super
bare
bones
here.
B
So,
just
one
more
time
before
we
dig
into
yamo
as
a
as
like
a
platform
operator,
I'm
defining
how
the
software
supply
chain
looks
like
right.
This
is
like
how
each
resource
links
to
each
other,
I'm
defining,
which
kubernetes
object,
end
up
being
created
in
that
cluster,
in
that
developer,
name
space.
B
For
that
particular
service,
like
in
this
case
figuring
out,
commits
that
are
pushed
into
an
image
repository
and
with
both
those
two
concepts
together
in
a
supply
chain.
All
it
takes
for
you
as
a
developer
is
to
create
a
workload
so
submit
the
workload
that's
describing
like
where
my
code
is
and
then
the
push
one
workload
it's
going
to
go
ahead
and
create
the
whole
chain
so
create
another
workload,
same
thing
for
the
other
workload.
B
But
with
the
details
passed
in
the
workload
I'm
going
to
be
like
populated
in
these
objects
that
I
got
created
enough
said,
let's
dig
into
the
demo,
so
the
demo
I
have
literally
making
use
of
these
kubernetes
resources,
except
that
I'm
not
using
argo
here,
I'm
actually
just
using
cap
controller
and
what
the
dev
is
going
to
show
is.
Once
we
create
this
workload,
we're
going
to
see
this
object
tree
being
created,
and
then
we
can
follow,
along
with
the
with
our
application,
going
from
like
source
code
to
choose
something
deployed.
B
Cool
so
on
to
the
demo.
So,
as
I
mentioned,
going
to
start
going
very
into
the
demo
here,
so
I
have
just
a
little
bit
of
namespace
set
up
here,
like
service
account,
providing
the
rows
for
a
controller
to
be
able
to
create
those
objects.
In
the
first
place,
like
someone
needs
the
permissions
to
create
a
git
repository,
someone
needs
the
permissions
to
create
pipelines,
tasks,
skatepak
images
and
so
forth.
B
So
I'm
saying
hey
this
namespace,
whoever
uses
the
service
account,
gets
those
permission
essentially
and
then
as
a
developer.
What
I'm
I'm
going
to
run
so
as
a
developer,
let's
say
I'm
creating
this
application
called
app,
and
I'm
telling
you
hey
the
source
code
for
it.
You
can
find
in
this
url
and
this
range
please
keep
building
the
application
for
me
and
applying
to
this
cluster.
B
Now,
oh
and
sorry,
one
detail-
I
forgot
here
in
this
example
with
the
blind
to
the
same
cluster,
but
you
don't
have
to
do
it
that
way.
You
so
like
internally,
for
instance,
the
supply
chains.
They
have,
they
don't
really
apply
directly,
but
instead
like
pushing
the
configuration
to
a
git
repository,
then
other
components
can
do
that
job
of
deploying
once
they
get
merging,
but
anyway,
so
I've
got
the
workload
workload
describing
some
traits
about
my
app
as
well
as
like
hey.
This
is
where
my
code
lives
and
I
go
ahead
and
create
this
workload.
B
Code
workload
created,
see,
workload
got
created,
it's
not
ready.
Yet,
that's
because
there's
some
things
going
on
those
things
going
on
are
essentially
what
I
said
before
so
the
controller,
knowing
that
it
has
to
create
four
resources.
The
first
being
one
is
gonna,
keep
track
of
revisions.
Sorry
commits
pushed
to
a
hit
repository
the
next
one,
something
that
knows
how
to
run
tests.
Third,
one
something
I
know
such
should
be
an
image.
B
B
If
I
were
to
now
introduce
like
a
different
team
to
this
platform,
what
would
that
team
do?
Well,
in
this
case,
the
team-
that's
building
the
ui
of
the
larger
application
called
app.
They
create
another
workload
point
at
their
repository
and
submit
it
to
kubernetes
right.
It's
the
miniature
kubernetes,
I'm
gonna
clean
this.
Okay,
look
at
the
tree
again
the
object
hierarchy
for
ui
same
thing.
It's
going
to
try,
so
the
controller
gauge
should
then
like
relentlessly
make
that
a
graph
that
describes
the
dependency
between
those
resources
x.
Assist
right.
B
B
B
We
are
creating
like
one
git
repository
that
keeps
track
of
every
single
git
repository
out
there.
No,
no!
So,
for
each
workload,
we
create
that
same
path
to
production.
That
the
is
described
via
the
definition
of
the
supply
chain
so
attend
everybody
in
the
org
that
has
a
workload.
That's
saying:
hey,
I'm
a
web
application.
E
B
B
B
If
we
look
at
that
template
how
that
looks,
like
imagine
the
templates
I
have
here.
If
I
look
at
git
repository-
and
here
we
have
the
template
now,
I
can
see
here
I'm
using
rtp
thought
of
the
template
view
that,
as
stephen
shown
in
the
examples
you
can
either
use
ytt
for
templating
or
the
adjacent
path-based
templating
may
have,
but
regardless
going
back
clutter
supply
chain
describing
that
graph
of
the
dependency
between
those
resources
and
then
in
the
template
that
we're
pointing
at
for
this
resource
is
saying
hey.
B
And
then,
if
you
look
at
the
git
repository
that
got
created,
I
get
repositories
and
look:
let's
set
the
ui
one.
We
see
that
it
it
exactly
as
we
specified
right
the
url
from
the
workload.
The
wrap
from
the
workload
is
all
here
so
like
I
was
saying
before
in
the
stack
script
repository,
we're
saying:
hey
keep
track
of
commits
made
to
this
repository
in
the
status
we
have
what
they
discovered
like
hey.
This
is
the
latest
revision.
B
So
what
happened
right
after
based
on
this
dependency
graph
that
we
established
here
well,
because
this
resource
the
source
tester,
is
explicitly
saying.
I
need
source
from
this
guy
right
here.
Then
what
we're
doing
is
we're
taking
the
url
that's
found
at
this
location,
the
revision
that's
found
at
this
rocket
location,
status,
dot,
artifactory,
url
status,
that
artifact
and
revision,
and
then
that
will
be
made
available
for
this
component
for
this
resource
and
so
on
and
so
forth.
B
So
if
the
test
succeeds
and
in
whatever
url
in
revision
path,
we
specified
for
the
source
for
the
source
tester,
then
we're
going
to
make
it
available
for
the
next
resource.
The
image
builder,
so
on
and
so
forth,
and
what's
really
cool
about
is
that
behind
the
scenes
all
the
cartographers
doing
is
relentlessly
looking
at
this
graph
and
then
evaluating
for
each
resource,
whether
it
has
something
new
to
present
kubernetes
or
not.
B
A
B
This
mechanical
and
there
we
go
because
I
have
a
template.
Sorry,
I
forgot
show
a
template
called
candyco
and
then
that
would
be
like
that
hey
this
is.
I
could
make
this
swapable
without
you
even
having
to
think
about
the
dependency
graph,
because
at
the
end
of
the
day
this
is
an
image
template.
This
takes
an
image
so
well,
can
you
connect
such
good
images?
It
can
be
an
image
with
chemical.
B
D
B
Thing
is
going
on:
it
is
going
to
start
creating
those
objects
making
the
the
the
graph
materialize
in
kubernetes.
If
you
do
a
tree,
okay,
I
created
the
app
one,
so
we
can
see
get
your
posture
you
got
created,
test,
got
rent
and
now,
instead
of
seeing
the
kpac
image.
What
we're
seeing
here
now
is
this
runnable,
because
there
is
in
tecton
under
hood
now
with
county
code,
to
build
that
container
image.
If
I
do,
I've
got
task,
relogs.
B
We
can
see
okay,
we
can
see
the
test
that
that
worked
well
and
we
can
see
the
view
it
is
taking
place
and
that's
showing
yeah
like
how
you
can
swap
those
templates.
There
are
a
couple
other
features,
I'm
not
getting
through
it,
but
we
could
even
make
it
so
that,
depending
on,
I
don't
know
a
parameter
that
you
pass
through
your
workload.
B
So,
even
though
we
have
that
that
dependency
graph
that
the
supply
chain
pretty
much
is
you
can
also
in
a
declarative
way,
declare
that,
like,
oh,
you
use
this
template
if,
in
the
workload
you
have
like
these
properties
set,
or
these
other
properties
have
I'll
not
get
into
that
right
now.
But
if
you
want
to
know
more
about
it
following
cartographer.sh,
that's
our
website,
there's
a
documentation
there
they're
examples
and
yeah.
That's
it.
D
D
Good,
okay,
so
the
you
know
final
thing
we
want
to
talk
about
is:
how
are
we
thinking
about
the
future
of
the
project
right?
What
where
are
we
going
from?
You
know,
thinking
about
connecting
together
cicd
tools
in
the
space.
You
know
what
have
we
learned
since
we
you
know
put
that
together
and
you
know
have
a
couple
users
now,
and
so
I
think
a
lot
of
feedback
we've
gotten
is
that
our
crds
are
very.
We
have
a
lot
of
securities
and
they're
very
domain.
D
That's
just
called
cluster
blueprint
or
we'll
have
a
blueprint.
Namespace
scoped
version,
that's
more
nestable,
so
you
can.
You
can
use
a
instead
of
a
template.
You
can
reference
another
supply
chain,
that'll
kind
of
get
inserted
into
the
graph,
and
it
lets
you
define
the
types
yourself
and
the
schema
for
each
type
so
that
you
know,
instead
of
a
baked
an
image
type.
There's
a
cluster
blueprint
type,
your
register
that
can
be
called
image
and
that's
what
you
promote
forward.
D
So
that's
what
we're
looking
at
you
know
doing
for
kind
of
subsequent
versions
of
this
we've
seen
some
really
useful,
some
really
interesting
use
cases
and,
taking
you
know
like
a
bunch
of
different
service,
related
resources
and
kind
of
coalescing
them
into
one
resource
that
you
know
maybe
presents
information
on.
You
know
a
unified
like
a
piece
of
information
on
what
that
service
looks
like
that.
D
D
C
I
asked
you
on
slack
as
well,
because
when
I
look
at
cartographer
website,
I
see
lots
of
great
things
like
the
challenges,
organizations
or
people
face
and
how
they
could
all
come.
Those
channels
and
the
pattern
I
noticed
on
the
website
is,
like
you
also
talk
about
events
on
the
website,
but
I
I
didn't
really
find.
I
couldn't
really
find
detailed
information
about
what
events
we
are
referring
to
and
how
those
things
could
we
know
generalized
like?
Are
they
like
specific
events
or
some
other
events,
no
framework?
C
D
Yeah,
that
makes
sense
so
so
the
question
is,
you
know,
essentially
how
do
events
play
into
this
right
like
what?
What
what's?
What's
the
story
around
that?
So
when
we
talk
about
events
with
cartographer,
we're
talking
about
event,
kubernetes
api
server
events
right
the
the
way
cartographer
acts
as
a
at
least
as
a
choreographer
instead
of
an
orchestrator?
D
Is
that
it's
it's
listening
to
status
sub-resources
on
these
for
status,
changes
which
are
events,
and
then
you
know
taking
information
from
the
updated
status
and
moving
that
stack
of
other
resources,
and
in
that
sense
it's
it's
event
driven,
but
it's
not
it's
not
like
using
edge
triggered.
Events
like
captain
would
use
where
you
know
the
events
could
be
missed
right.
D
It's
using
events
in
a
level
triggered
way
where
the
system
is
always
going
to
reconcile
towards
the
current
state,
and
so
you
know
in
some
ways
we
think
of
that
model,
as
you
know,
maybe
a
little
more
robust
or
that
it
it.
You
know,
kind
of
you
know,
there's
no
events
to
miss
so
you're
going
to
get
it
in
one
iteration.
Are
you
going
to
get
it
next?
If
that
makes
sense,
but
we
we
don't
currently
support
other,
you
know.
D
Events
outside
of
you
know,
events
on
within
the
context
of
a
single
kubernetes
cluster
and
we
use
external
resources
to
do
like
cross-cluster.
You
know
orchestration
type
things
like
writing
to
a
git
repo
with
configuration.
It
gets
picked
up
by
a
resource
in
a
different
in
a
different
cluster.
That
doesn't
mean
we're
not
thinking
about
what
that
could
look
like
in
the
future
right,
and
so
you
know
you
can
imagine
you
know
cloud
events
being
used
between
clusters
or
other.
You
know
kind
of
similar
ideas.
To
that.
D
I
think
a
challenge
there
has
been
that
you
know
it's,
because
we
really
like
this
level
triggered
model.
It's
a
little
difficult
to.
You
know
kind
of
reliably
do
level
triggered
eventing
across
clusters
like
replicate.
You
know
a
level
triggered
resource
in
a
different
cluster,
and
so,
but
we,
you
know,
we
we've
definitely
kind
of
thought
about
different
ways
we
could
achieve
achieve
that.
B
Now
I
just
wanted
to
add
one
thing
to
it.
Another
detail
about
all
of
this
is
that,
as
you
saw
like
we're
using
technology
hood
you're
using
the
flux
to
get
your
pause
tree
like
you
got
to
pick
and
put
those
twos
in
in
the
places
you
you
want,
and
so
if,
for
instance,
using
tactuan
and
tactile
emits
city
events,
compliant
events
somehow
and
you're
able
to
grab
them,
but
like
you
can
still
make
use
of
that
photography.
The
controller
itself
at
the
moment
doesn't
emit
any
event.
C
The
other
reason
why
I'm
asking
this
story:
well,
that
was
the
cd
events
from
I
think
it
was
last
week
now
I
don't
yeah.
I
think
it
was
last
week
and
there
was
a
really
good
talk
from
eric
stannerson
who
actually
worked
with
volvo
cars
and
they
developed
embedded
software
and
they
don't
have
to
brand
it.
C
In
summary,
what
I
am
trying
to
say,
yes,
cool,
that
you
enable
all
these
different
tools
to
be
used
in
a
you
know,
streamlined
manner,
or
you
know
you
know,
program
choreography
for
gifts
or
whatever
the
word
is,
but
yeah
there
are
organizations
out
there
that
are
not
think
about
this
ecosystem
because
of
their
business.
You
know
so.
D
Yeah,
I
think
one
way
we
think
about
that
is
you
know
if
you
have
cic
tools
that
aren't
already
kubernetes
native
right,
like
you
have
a
traditional
jenkins
pipeline
or
something
that
those
tools
can
often
be
adapted.
So,
like
there's
a
common
pattern,
we've
already
seen
where
you
just
use
tekton
as
kind
of
a
general
adapter
for
anything
right
where
your
tactile
pipeline
run.
You
know
the
catalog
has,
I
think,
a
jenkins
integration
right,
so
you
use
a
tekton
pipeline
run.
D
That
talks
to
jenkins
runs
the
jenkins
task
and
comes
back
into
the
pipeline,
and
so
as
long
as
you're
willing
to
use
kubernetes
as
the
the
central
piece
right,
you're,
not
you're,
not
necessarily
limited
to
just
kubernetes
native
tools.
On
top
of
that,
I
think
you
know
we
see
a
lot
of
people
moving
to
kubernetes
for
infrastructure
abstraction
so
that
it
doesn't
worries
too
much.
If
that
makes
sense
that
we
have
that
dependency.
C
Oh,
I
was
just
asking
if
any
other
question
to
you,
yeah,
and
maybe
I
can
say
one
more
thing.
I
I
promised
mauricio
salatino,
who
is
contributing
to
see
the
events
project
heavily
like
since
its
inception,
even
even
before
it
became
a
project,
and
he
was
the
one
who
actually
created
this
proof
of
concept
using
captain
and
techtone,
and
I
asked
like
because
he
is
like
part
of
vmware
organization.
E
Yeah
on
that,
I
am,
I
just
put
in
our
chat
the
playlist
for
city
events
con
last
week
that
took
place
collocated
with
kubecon
and
mauricio
spoke
at
that,
and
he
has
a
really
interesting
talk
about
using
events
between
like
a
multi-cluster
way.
So
you
know
it
might
be
interesting
for
you
and
certainly
yeah
he's
a
fun
one
to
chat
with.
D
Makes
sense,
I
think,
there's
definitely
an
opportunity
to
like,
because
the
events
we're
talking
about
are
really
within
the
context
of
a
single
kubernetes
cluster.
You
know
it's
really
just
building
on
top
of
what
kubernetes
provides
and
there
are
definitely
limits
there
right,
and
so
you
know
I
don't
know
if,
in
the
end,
these
tools
are
going
to
compete
necessarily
or
if
it's
like
within
a
cluster.
You
can
use
cartographer
for
some
things
for
scaling
out
an
application
platform
and
then
between
clusters.
D
E
C
C
C
It
looks
very
cool,
so
I
think
we
will
continue
talking
and
see.
You
know
how
we
can
cultivate
between
cartographer
and
other
projects
or
the
six
we
have
in
cd
foundation
because,
like
as
you
highlighted,
there
are
some
trends
where
people
are
you
know
following,
and
perhaps
we
should
find
how
we
can
collaborate
on
better
working
on
those
type
of
things
together,
like
cross
community
collaboration,
not
just
within
cdf
but
across
the
ecosystem,
which
could
be
under
cncf,
community
and
elsewhere.