►
From YouTube: Cartographer Office Hours - March 21st, 2022
Description
00:00 Intro
01:40 Review outstanding RFCs
The purpose of this meeting is to discuss architecture-changing ideas (in the form of RFCs) and provide in-depth support to the community of Cartographer contributors.
You can continue the conversation by adding comments to the RFCs PR: https://github.com/vmware-tanzu/cartographer/labels/rfc
Agenda: https://docs.google.com/document/d/1ImIh7qBrOLOvGMCzY6AURhE-a68IE9_EbCf0g5s18vc/edit?usp=sharing
A
Okay,
welcome
everyone
to
the
cartographer
office
hours
meeting.
We're
really
glad
to
see
you
here.
Let
me
share
my
screen
here.
A
A
C
Hey
yeah,
I'm
from
the
well
now
part
of
the
cartographer's
team.
As
of
today
yeah,
I
was
previously
on
the
scc
team
and
still
getting
to
know
a
photographer.
A
Yeah
me
too
awesome
welcome
to
here
glad
to
have
you
here
all
right,
reviewing
outstanding
rfcs.
I
want
to
go
to
the
project
here
from
left
to
right.
We
have
several
artists
sitting
at
the
in
review
stage.
First,
one
being
workload
conventions.
A
A
Seven,
I
believe,
a
provost
and
one
from
a
member
from
dlc,
so
I
believe
that
will
make
it
move
to
be
accepted.
Is
that
correct.
A
Yeah,
okay,
so
we'll
move
it
to
the
final
comment
period
and
if
there's
any
objection,
remember
that
the
standard
time
for
the
for
this
stage
is
seven
days
to
provide
yeah
comments,
objections
observations
with
before
we
discuss
moving
it
to
accept
this
all
right,
yeah,
we
have
others
here
in
the
in
review
stage.
I
don't
know
if
we
want
to
go
each
party.
D
A
B
A
A
Yeah
yeah,
we
we
hope
you
can
use
a
review
and
click
the
remaining
rsv
yeah.
This
one
still
pretty
much
in
review.
D
B
We
that
we
actually
land
on
something
where
we
can
provide
end-to-end
artifact-
or
at
least
you
know,
relate
artifacts
to
where
they
came
from.
It
may
be
a
different
shape.
What
do
we
do
in
the
rfc
process,
when
we
think
we
have
to
revisit
something.
B
G
So
I
was
under
the
impression
that
we
were
inching
towards
something
that
would
have
been
workable
under
this
under
this
rfc,
assuming
we
also
have
rfc
20.
If
we
hold
status
updates.
B
F
I
think
if
we
saw
a
proposal
that
was
more,
it's
kind
of
updated
to
match
what
things
look
like
right
now
there
was
more
tightly
scoped
that
functionality
of
holding
status
updates
to
something
that's
optionally,
enabled
per
template
right.
So,
like
a
template
author
can
say
you
know
this
obeys,
observed
generation
and
follows
all
the
rules
that
would
you
know,
allow
for
that
artifact
racing.
F
If
it
were
more
of
a
tool
right
as
opposed
to
a
unilateral
change
across
the
whole
runtime
contract
for
all
resources,
then
you
know,
I
think,
that'd
be
a
more
interesting
thing
to
look
at.
I
know
scott.
You
had
kind
of
similar
concerns
about
the
runtime
contract.
Does
that
seem
like
it
would
help.
D
B
B
G
I
think
we
just
need
direction
on
whether
or
not
like
this
is
something
we
keep
pursuing
right
and
I
think
what
you
just
said:
stephen
is
like
a
good
reframing.
So.
F
I
think
it's
reasonable
to
keep
pursuing
a
more
limited.
You
know
form
of
this
as
a
tool
right.
I
think
it's
hard
to
say.
If,
because
there
are
a
million
ways,
we
could
do
artifact
tracing
right,
we
could
rely
on
attestations
created
by
all
the
individual
components
entirely
outside
of
cartographer
to
form
that
tree.
But
you
know,
if
someone
pulls
it
in
your
tool,
then
we
lose
the.
You
know
linkage
automatically,
so
I'm
I'm
a
fan
of
cartographer,
adding
individual
tools
that
can
be
enabled
per
resource
to
help
you
achieve
that.
F
I
think
that's
like
a
reasonable
middle
ground,
but
I
also
I
kind
of
scott.
I
was
poking
you
earlier
because
I
know
you
had
things
about
the
runtime
contract
or
you
know.
Are
you
particularly?
Would
you
be
opposed
to
a
more
kind
of
judiciously
used
kind
of
optional,
enablable
version
of
of
that
runtime
contract
change
on
a
per
resource
basis
for
template
basis
or.
B
F
That
we
change
the
runtime
contract
across
all
resources
right
and
then
like
as
a
default,
and
then
I
think
scott.
Maybe
you
want
to
talk
a
little
more
specifically
about
what
else
the
rfc
is
not
ready
and
what
it
needs.
I
think
a
description
of
edge
cases
and
a
little
more
information
about
how
that
you
know
what
would
be
held
when
right,
because
it
is
you
know
a.
G
G
The
only
other
way
that
we
thought
of
was
to
hold
status
updates
for
certain
resource
types
to
ensure
that
we
can
observe
the
proper
generation
and
match
inputs
to
outputs
is.
Does
that?
Does
that
whole
like
holding
status?
Does
that
fall
into
that
category?
Scott
of
things
that
are
too
dangerous
to
attempt.
D
I
mean
it
depends
on
the
breadth
and
the
context
so
like
I'm
not
going
to
say
universally.
That
is
too
dangerous
but
like
if
the
bar
is
higher.
In
my
mind,.
F
F
Yeah
talks
about
that
interface
looks
like
you
know.
I
could
also
see
other
ways
if
a
resource
presents
its
the
output
and
the
input
in
the
status
at
the
same
time
right
then,
you
wouldn't
need
to
change
the
runtime
contract.
You
could
just
use
that
to
make
the
association
and
seeing
that
as
a
tool
would
mean
that
we
can
make
less
runtime
contract
changes
to
existing
supply
chains,
because
those
supply
chains
could
you
know
for
kpac,
not
need,
for
example,
not
need
to
implement
that
change.
G
Is
that
something
we're
going
to
ask
kpec
to
do,
because
it
doesn't
do
that
right
now
right,
it
doesn't
do
that
right
now,
but
it'd
be
a.
G
F
A
that's
a
much
safer
tool
right
compared
to
the
runtime
contract
change,
but
as
long
as
they're
all
different
tools
for
achieving
that
outcome.
Right
that
a
template
author
as
they're
writing
a
template
should
think.
Oh,
if
I
want,
if
I
want
artifact
tracing,
I
should
do
this
or
this
or
maybe
there's
a
configuration
option
that
you
know
lets
the
resource,
provide
that
information
separately.
Somehow
right,
it'd
be
good
to
see
that
in
the
rfc.
G
So,
okay
that'll
make
sense.
It's
been
a
while,
since
I've
read
it
but
rfc
20
isn't
all
that
far
from
that,
I
don't
think.
I
think
it
talks
about
like
a
lot
of
those
similar
concepts.
G
So
can
we
can
we
maybe
like
try
and
reorient
rfc
20
around
this
idea
of
like
individual
template
like
modeling,
that
behavior
in
individual
templates,
as
opposed
to
cartographer
as
a
whole,
because
I
really
don't
think
it's
that
far
away
but
yeah.
If
there's
like
a
couple
of
like
lines
of
feedback,
you
could
write
in
there.
Stephen
to
kind
of
get
that
point
across
would
be
awesome.
F
Sounds
good:
let's,
let's
work
towards
that,
and
then
we
can
come
back
and
scott.
You
can
see
if
it
covers
the
things
we're
looking
for.
D
G
B
What's
the
resource
status,
rsc.
G
The
request
for
rc-
that's
the
one
where
this
one
694.
A
B
A
G
Yeah,
I
think
in
the
interim
we
could
probably
move
rfc,
18
and
rfc
20
back
into
pending.
Just
take
the
matter
of
interview.
A
A
B
Yeah,
well,
I
I'm
frustrated,
but
that
this
one
would
simplify
the
user
interface,
but
not
the
code.
B
We'd
really
like
we'd,
really
like
the
option
of
having
a
life
cycle,
be
just
baked
into
our
code,
which
makes
maintaining
runnable
harder,
possibly
I'd.
Rather,
it
didn't
admit
a
runnable
under
the
hood.
I
think
that's
actually
just
surprising
to
people
I
think
finding
out
that
they
get
a
runnable
and
not
a
and
not
the
resources
in
the
template
is
probably
more
surprising
than
if
they
just
got
the
resources
in
the
template
that
behaved
with
the
new
life
cycle.
B
Remember
yeah:
at
a
high
level,
our
this
rsc
is
proposing
that
there
is
a
a
life
cycle
field.
There
is
actually
a
true
false,
but
I
agree
with
scott
that
it
would
be
a
it
should
be
enumeration
type,
some
sort
of
field
that
says
that
this
is
a
immutable
resource.
So
next
time
you
see
an
input,
you
have
to
generate
a
brand
new
output
and
the
way
it
was
going
to
stamp
out
a
new
resource.
B
The
way
I
was
going
to
implement
that
was
to
create
a
runnable
under
the
hood
for
the
user
and
that
runnable
would
contain
the
and
the
run
template
at
the
same
time.
That
is
the
actual
template
creator
for
that
runnable.
So
to
hide
that
implementation,
detail
from
the
design
or
the
crds
you
have
to
provide
to
the
cluster.
F
I
really
like
the
separation
like
that
right
now,
cartographers,
you
know,
stays
simple
in
its
implementation
of
it
stamps
out
resources
and
moves
things
between
them
right
and
that
we've,
you
know,
kind
of
pulled
away.
The
separate
component,
that's
responsible
for
garbage,
collecting
running
the
mutable.
You
know
whatever.
I
also
like
that
we
I
I
think
I
am
a
fan
of
having
runnable
as
a
resource
that
shows
up
in
the
tree.
If
you
look
under
the
workload
resource
right,
you
have
there's
one
place
where
you
get
the
status.
That
is
the
latest.
F
You
know
image
build
or
whatever
right.
Translated
from
that
garbage
collected,
10
runs
right,
but
all
that
said,
if
there's
a
way
to
create
like
a
convenience,
you
know
template
type
right.
That
kind
of
combines
those
things
together.
That
gives
you
an
easier
interface
for
defining
a
template.
When
you
don't
need
the
reusability
of
being
able
to
reuse
a
run
template
across
many
cartographer
templates
right
or
you
know,
like
supply
chain,
integrated
templates,
then
that
seems
like
it
could
be
a
very
useful
tool.
I
wonder
if
that
does
that.
F
B
B
As
you
create
this,
it's
it's
just,
not
a
one-to-one
mapping.
I
guess
between
what
you
see
in
the
template
and
what
actually
happens.
B
F
That
makes
sense,
I
wonder
if
it's
like
having
runnable
not
coupled
to
cartographer
the
rest
of
cartographer
right,
you
know,
is
a
design
win
right
and
if
cartographer
has
some
special
integration,
that's
specific
to
runable
the
other
direction.
You
know
as
a
convenience
feature
for
using
this
particular
external
service.
I
agree
would
be
better
if
it
didn't
need
to
have
that
right,
but
I
don't
like
I
I
I
it
might
be
not
a
terribly
negative
thing
as
long
as
runable
stays
on
its
own,
you
know
or
is
like
still
independently
usable
right.
D
Scott,
there
were
two
primary
concerns
that
I
called
up
on
this
one.
First,
the
idea
of
creating
a
cluster
run
template
at
runtime
for
the
pipeline
run
that
gets
stamped
out
to
be
able
to.
Then
reference
feels
like
it's
an
extra
impedance
mismatch
that
we're
just
kind
of
hacking
around
again,
so
I
suggested
to
basically
inline
the
template
directly
into
the
runnable
that
gets
stamped
out,
which
should
make
the
inputs
and
outputs
a
lot
smoother.
D
The
other
concern
was
around
just
what
other
fields
exist
on
runable
today
that
users
might
need
to
specify
so
like
at
the
moment,
there's
gc
fields,
and
I
think
that's
about
it.
D
That's
like
really
important,
but
as
we
start
to
look
at
other
concerns
around
the
life
cycle
of
how
resources
get
updated,
runnable
is
something
where
I
could
definitely
see
there
being
like
additional
life
cycle
parameters
that
need
to
be
set
like,
for
example,
don't
update
the
spec
until
the
current
runnable
finishes
like
I
could
expect
to
see
that
to
be
a
common
case
or
to
go
ahead
and
update,
and
then
just
give
me
the
most
recent
finished
on
my
status
or
wait
till
the
most
recent
stamped
out
version
finishes
and
then
update
the
status.
D
B
B
B
I
do
understand
that
there
is
an
upside
to
having
a
cluster-wide
run
template.
Then
there
may
be
one
I
just
like
to
know
how
solid
that
is
how
important
it
is
to
have
a
cluster-wide
run
template
how
that's
an
improvement
over
just
ensuring
that
your
template
that
you
do
use
in
your
supply
chain
spells
out
the
semantics
of
creating
a
immutable
resource.
G
I
wonder
if
just
the
inlining
the
template
into
the
pipeline
on
its
own,
like
achieves
part
of
that
without,
like
the
rest
of
everything
so
like
one
would
be
so,
like
you
know,
the
first
incremental
change
we
could
make
is
allow
people
to
create
their
runnable
object.
Inline
their
their
cluster
run,
template
into
the
runnable
object
and
then
just
use
it
like
that.
It's
one
less
thing
they'd
have
to
reason
about.
F
That
creating
a
more
inline
version
of
this
you
know
skipping
one
of
the
levels,
an
earlier
proof
of
concept
and
the
problem
was
having
two
layers
of
templating
on
top
of
each
other.
Like
I
know
cyril,
when
you
you
presented
the
first
version
of
runnable,
you
had
the
run,
template
separate
and
said:
why
did
you
make
run
templates
separate?
F
Why
not
just
make
it
part
of
runnable
and
have
it
be
definable
in
all
one
thing,
and
you
convinced
me
that
actually
it
just
doesn't
work,
there's
too
many
levels
of
templating
on
top
of
each
other,
and
so
you
have
to
separate
that
part
out,
and
so
that's
that's
how
we
ended
up
with
so
many
layers
of
interaction
for
this
one.
If
that
makes
sense,
it's
the
double
templating
layer,
but
maybe
that's
solvable
in
a
different
way.
Right
like
we,
we
didn't
dig
that
deep
into.
F
E
B
Yeah,
what's
what's
the
what's
the
value
of
bringing
like
how
much
value
does
this
bring
having
to
work
through
this
design?
At
this
point,
is
there
a
strong
drive
to
actually
have
this
feature
implemented
anytime
soon,
just
a
priority
question.
G
Washuma's,
not
here,
but
I
know,
he's
talked
about
it
because
he's
trying
to
reason
through
all
the
tutorials
right
and
every
time
that
he
goes
through
and
explains
what
a
supply
chain
is.
He
always
has
to
stop
at
runnable
and
be
like,
oh
by
the
way.
There's
this
whole
other
thing
that
you
need
to
write
and
care
about
so
yeah.
I
think
that's
it's
coming
from
a
lot
of
the
tutorial
work
that
he's
working
on
right
now,.
B
G
Yeah
but
then
we
go
back
to
scott's
point
that
he
made
earlier
right,
where
you
do
have
all
these,
like,
like
runnable,
specific
configurations
that
we'd
have
to
roll
up
into
every
single
template
like
gc
and,
like
you
know,
like
other
life
cycle
things,
and
that
means
like
all
of
those
specific
features
need
to
roll
up
into
every
single
template,
which
I
don't
know
it's
a
thing
that
would
have
to
happen.
B
G
B
It's
just
from
that
perspective
of
that.
I'm,
like
yeah
users,
I
think,
are
the
ones
who
don't
really
care
about
what
runable
is
I'm
curious
about
that
being
a
valuable
thing
to
people
other
than
runable
could
be
useful
outside
of
this,
and
we
could
continue
to
support
runable,
as
is
backed
by
the
same
library
of
code
anyway,.
F
F
I
wonder
if,
if
there's
a
way
to
have
that
convenience
resource
without
kind
of
coupling
ourselves
like
like,
is
there
architecture
we
should
propose
for
introducing?
You
know
templates
that
work
based
on
a
duct
type
or
something
like
that
right?
Is
there
a
way
we
can
you
know?
Could
we
create
a
separate
resource?
That's
not
part
of
cartographer
or
runnable,
or
you
know,
supply
chain,
part
of
cartographer
or
runable
that
creates
the
necessary
configuration
for
cartographer
automatically
right
like.
F
G
F
What
if
you
introduced
a
new
template
type
that
has
its
own
controller,
that
degrades
into
or
that
gets
reconciled
into
a
cartographer
template
type
that
embeds
a
runnable,
and
it
also
creates
a
run
template
underneath
right
that,
like
creates
all
these
sub
resources
for
you,
would
that
solve
any
problems?
I
guess
it'd
be
hard
to
reference
that
temp
we're
referencing,
that
template
type,
wouldn't
reference
the
underlying
components.
B
You
still
end
up
with
a
at
least
one
direction
of
coupling
right.
I'd
have
to
know
that
you
exist
yeah
yeah
at
the
moment.
What
we
do
is
we
say
that
what
you
have
to
know
exists
is
that
there's
a
runnable
type
that
will
solve
this
problem
for
you
all
right
and
that's
the
loosest
coupling
we
have,
because
cartographer
doesn't
care,
that's
what
we
have
today.
Any
of
these
other
proposed
solutions
seem
to
couple
us
to
the
concept
of
immutable.
However,
we
decide
to
implement
it
all
right.
B
But
you're
saying:
can
we
maintain
that
lack
of
that
complete
decoupling
in
some
way
that
that
makes
things
simpler
for
people
to
rationalize.
F
Yeah,
I
don't
have
an
immediate
solution
to
it.
It
also
again
like
if
to
me
if
we
need
a
couple,
if
if
we
can
keep
runnable
separate,
but
cartographer
needs
some
extra
stuff
right
in
order
to
make
it
easy
to
use
runnable
that
that
doesn't
seem
like
a
terrible
outcome
right.
I
agree
it's
less
desirable
than
completely
separate,
but
you
know
as
if
runable
is
still
this
kind
of
independently
usable
tool
right,
it
doesn't
seem
terrible.
It
feels
a
little
better
because
it's
still
kind
of
a
tool
around
orchestration,
that's
usable
generically.
B
So
you're
saying
let's
leave
runnable
where
it
is
and
promote,
or
even
create
better
controllers
for
or
translation
controllers.
Even
I
mean
what
stephen
was
saying,
but
maybe
specific
might
be
the
easy
way
to
solve.
For
that
says,
you
create
a
a
techdon
immutable
run
right
that
you
can
update.
That's
very
immutable
run
that
you
can
update
as
you
wish,
and
we
do
the
translation
in
between
and
update
it.
I
mean
that's
what
runnable
does
generically
today
all
right.
F
I
think
a
nice
thing
about
runable
is
it
lets
an
end
user
say?
Oh,
I
want
to
use
argo
workflows
instead
or
I
want
to
use
you
know
any
other
tool
that
behaves
like
tekton.
I
would
use
jobs
because
I
don't
have
techcon
installed
right.
That
seems
super
valuable,
and
so
I
still
see
a
lot
of
value
in
what
runable
provides.
F
But
if
there
are
a
tech,
ton,
specific
and
interface
you're
doing
this
users
didn't
have
to
use
runnable.
As
often
that
seems
supplemental
right.
That
seems
like
it
could
be
a
good
outcome
also.
B
I
guess
my
I
just
want
to
take
it
back
to
that
point.
Is
the
use
case
of
describing
describing
how
you
set
things
up
to
users
and
then
walking
them
through
what
they
actually
get
improved
or
enhanced
by
this
feature,
because
if
it's
not,
I
would
rather
not
implement
something
like
this,
which
feels
like
it's
starting
to
couple,
something
that
was
well
and
truly
decoupled,
and
it
only
takes
it
ever
so
far.
B
It
still
leaves
a
lot
of
baggage
behind
and
I
think
for
you
from
a
user's
perspective,
regardless
of
how
you
feel
about
clean
separation
of
concerns
having
a
template
that
behaved
one
way
or
the
other
because
of
a
a
generic
late
life
cycle
field
would
just
be
healthier,
it'd
be
easier
to
understand.
As
a
user.
F
B
F
A
All
right
great,
thank
you
so
yeah,
please,
please,
free
to
add
all
your
concerns
objections,
observations
into
the
thread
for
each
one
of
the
articles.
A
G
So
there
is
a
another
request
for
rfc
that
kinda
supersedes
the
snippets
one.
This
is
the
one
it's
called
single
blueprint
architecture.
C
A
G
So
this
is
something
we've
been
talking
a
bit
about
out
of
band,
I'm
not
sure
we've
ever
talked
about
it
in
a
meeting,
but
it's
the
idea
that
we've
been
thinking
about
what
it
might
look
like
to
merge,
supply
chains,
deliveries
templates
all
into
a
concept
called
blueprints,
and
then
those
would
all
be
typed
based
on
the
current
template
types
and
then,
by
doing
something
like
that,
you
would.
G
We
would
also
inherently
have
to
tackle
composability
because
we're
basically
getting
rid
of
templates,
and
so
this
is
a
request
for
an
rfc
that
tackles
just
this
aspect,
which
kind
of
like
would
clean
up
a
lot
of
our
crd
usage.
F
G
F
Mention
that,
in
the
issue
description
I
just
wasn't
sure,
because
I
could
see
like
yeah
they're
all
merged
together,
but
you
can
only
reference.
F
G
G
F
I
really
like,
I
think
this
drives
us
to
having
kind
of
more
distinctly
defined
architectural
components
for
cartographer
like
if
we've
talked
about
you
know,
moving
away
from
the
monorepo
longer
term.
Right
now
we
have
convention
service
living
as
a
separate
repo.
Also,
you
know,
I
think
this
makes
it
more
clear
that
you
have
like
the
blueprint
component
that
supports
the
stamping
out
right.
F
I
think
the
supply
chain
and
delivery
being
you
know,
different
tools
with
the
same
implementation
right,
it's
a
little,
you
know
makes
it
hard
to
tell
that
story
right
now,.
G
Yeah
scott,
do
you
have
any
any
insights
into
like
what
this
might
entail.
D
The
biggest
thing
that
jumps
out
at
me
is
flattening
both
the
the
workload
and
deliverable
resources,
because
those
do
have
different
purposes
and
intents
and
since
they're,
both
selected,
I
guess
previously
by
the
cluster
supply
chain
or
cluster
delivery
like
you,
would
want
to
make
sure
that
your
supply
chain
blueprints
versus
your
delivery.
Blueprints
are
selecting
the
right
thing.
B
B
B
Yeah
and
that
way
we
get
it
that
way
we
get
a
way
to
do
migrations.
When
we
implement
this,
we
can
continue
to
have
fully
circular
migrations
back
down
to
workloads
with
supply
chains
and
deliveries
and
deliverables
right.
B
D
The
the
two
ways
to
do
it
are
to
either
write
a
controller
that
basically
just
takes
resources
of
one
kind
and
copies
them
over
to
the
second
kind
and
reflects
back
the
status
so
that'll.
Allow
you
to
do
one-way
migrations.
B
I
mean
again
it's
not
the
main
reason.
The
main
reason
would
be
because
there
are
different
shapes
yeah
different
configuration
shapes
where
we
don't
think
that
params
make
the
right
sense.
This
should
be
something
you
can
trust
shape-wise
that
exists
in
your
workload
or
in
your
deliverable.
B
A
Okay,
any
objection,
any
other
comment
update
check
here.