►
From YouTube: Cartographer Office Hours - Feb 7th, 2022
Description
00:00 Intro
00:53 RFC Process
05:40 RFC 009 Supply Chain switches templates
06:44 RFC More option selectors
11:50 Snippets and multipath discussion
13:03 RFC 18 and RFC 20 discussion
A
A
B
I've
likened
this
to
having
like
a
bicameral
legislative
legislature.
It's
the
other
house
just
give
it
a
name
and
then,
instead
of
just
saying
the
advantage
being
that
then
our
processes
reference.
You
know
abstract
groups,
the
reference
interfaces
rather
than
implementations.
We
don't
have
to
reference
stephen
levine.
We
can
just
say
like
a
member
of
this
of
xyz
group,.
C
C
B
D
E
A
B
D
B
A
A
B
You
made
the
suggestion
in
the
comments
after
folks
had
started
voting.
So
it's
like
okay,
let's
just
separate
this
out-
it's
not
controversial.
We
should
be
able
to
improve
this
quickly.
That
is
right.
Now
we
have
match
fields
as
a
selector
under
options,
options
being
what
was
introduced
in
rc9-
and
this
is
just
saying,
let's
further
include
match
expressions
and
match
labels,
which
both
target
just
the
labels
on
the
workload,
no
they're
sealed.
F
B
F
B
G
B
G
A
A
B
B
B
Thing
that
I
would
that,
I
would
say,
we've
got
rc18
and
rc20,
and
there
are.
There
are
two
types
of
conversations
that
are
going
on.
One
is
if
we
assume
that
we're
going
to
do
tracing
what's
the
best
way
to
do
it,
and
the
other
is
a
what,
if
we
don't
assume
that
we're
gonna
do
tracing,
and
so
I
I
posted
in
our
kubernetes
slack
a
suggestion
that
we
that
we
take
rc
18
our
the
the
motivate
so
rc18
a
little
history
came
in
as
an
external
user
rfc.
B
B
But
crucially,
both
of
them
inherent
in
there
is
the
is
the
need
to
say.
You
know
this
change,
that's
made
at
one
step
in
the
supply
chain
to
be
able
to
know
at
some
later
step
like
oh,
this
has
gone
through
like
that
change
over.
There
has
gone
through
all
these
separate
steps,
and
so
that's
what
that's
what
is
being
referred
to
as
tracing.
D
So
is
there
a
perspective
that
we
don't
need
tracing
at
all
or
like,
or
is
the
idea
just?
Could
we
achieve
tracing
through
reliance
on
the
external
tools?
You
know
creating
mappings
between
their,
you
know
the
artifacts
they
create,
or
you
know
something
that
doesn't
involve,
observed
generation
and
that
that
kind
of
mechanics
like
saying
crds
have
to
present
their
inputs.
You
know
things
in
spec
and
status
if
you
want
to
capture
them
when
we
say
like
we
don't
want
to
do
tracing.
D
Are
we
really
talking
about?
We
don't
want
to
implement,
observed
generation
based
tracing
right
or
like
like
some
some
generic
mechanism
like
that,
or
is
it
even
like?
We
don't
want
to
implement
that.
You
know
with
a
strong
assumption
that
resources
will
support
it,
but
we
may
want
to
implement
that
as
an
option
you
can
enable
on
some
resources.
D
Right,
like
I
feel
like
there's
there's
a
long
like
spectrum
of
you
know,
there's
a
world
where
we
implement
tracer,
just
using
observed
generation
turn
it
on
everywhere
and
draw
an
artifact
graph
and
pretend
like
it's
perfect
and
that's
probably
not
the
right
thing
to
do
right
and
there's
a
world
where
we
give
up
on
the
problem
and
don't
you
know,
make
any
associations
between
resources
at
all
and
that's
probably
not
the
right
thing
to
do
right.
Users,
users
definitely
want
the
functionality.
D
So
to
me,
it's
like
there's
some
things
in
rfc
18
and,
like
I
even
like,
so
you
know
some
of
like
the
option
to
use
those
rfc
mechanics
with
observed
generation.
You
know
they
work
right
to
enable
that
to
get
tracing.
When
you
know
it
doesn't
work
to
me
that
or
like
the
path
I
might
suggest
is.
Can
we
look
at
this
more?
D
Like
you
know,
individual
tools,
you
can
use
some
within
cartographer,
some
outside
of
cartographer,
that
you
can
enable
in
order
to
you
know,
do
you
know,
establish
the
chain
of
custody
all
the
way
through.
If
that
makes
sense,
as
opposed
to
like
a
framework
for
establishing
tracing
that,
we
believe
will
be
always
consistent
right.
Is
there
a
way
we
can?
D
E
B
A
B
Able
to
do
tracing-
and
I
think
it's
unquestionable-
that,
like
you,
could
write
all
of
the
crds
that
your
supply
chains,
your
cartographer
supply
chains,
happen
to
point
to
and
just
choose
those
crds
to
be
like.
I
want
you
to
expose
this
provenance
information
in
a
way
that
I
can
consume
and
as
such
boom.
I've
got
a
platform
that
that
gives
you
this
tracing
view,
and
to
that
I
would
just
say,
that's
cool
like,
and
it
has
nothing
to
do
with
cartographer
right.
B
D
I
think
there's
something
in
the
middle
of
those
things,
though
right
it's
like
like
as
an
example.
What,
if
cartographer,
just
provided
a
way
to
capture
providence
information
right
in
in
the
workload
status
but
didn't
provide
the
mechanism
for
collecting
it
directly,
like
you
configure
your
template
somehow
and
your
template,
you
know,
without
using
observed
generation
and
trying
to
match
status,
to
spec,
like
as
an
example
of
one
technique,
it
looks
for
an
input
in
the
output
right
and
if
it
sees
the
commit
next
to
the
image
digest,
then
it
knows
it
can.
D
You
know,
create
a
mapping
between
those,
but
there
may
be.
There
may
be
ways
to
capture
that
providence.
Information
that
you
know
are
more
abstract
right,
like
there's,
every
resources
that
implement
a
some
kind
of
attestation
field
right.
You
know
cartographer,
picks
up
the
attestation
and
goes
and
reads
that
and
then
checks
the
signature
and
records
it
right
there.
D
There
could
be
generic
interfaces
that
we
can
provide
to
capture
the
information
that
don't
require
the
mechanics
of
tracing
that
I
think
people
are
rightfully
worried
about
in
some
cases
right,
but
still
you
know,
extend
cartographer
to
provide
the
interfaces
for
receiving
that
information
and
presenting
it
to
the
user,
and
I
think
I
wonder
if,
like
you
could
start
with
that
right,
you
could
start
with.
Even
just
if
you
know
the
kpac
outputs
the
commit
next
to
the
image
digest,
then
we
can.
D
You
know
record
that
traceability,
information
and
then
add
more
complex
tools
later
right,
as
we
find
you
know,
hey
a
bunch
of
things,
implement,
observed
generation
and
don't
output
their.
You
know,
you
know
stack
information
and
status.
Therefore
you
know,
maybe
that's
a
useful
tool
that
you
can
turn
on
optionally
in
a
template
when
you
know
your
resource
implements
that,
like,
I
think,
I'm
sorry
I
got
some
hands
raised,
so
we
scott's
next.
B
B
Is
that,
like
it
relies
really
on
things
being
well
behaved
from
a
more
general,
like
you
know,
conditions
or
something
that
are
recommended
by
by
the
kubernetes
ecosystem,
as
as
it
is
observed,
generation,
and
so
I'm
much
more
comfortable,
relying
on
on
on
those
pieces
of
information,
rather
than
saying
like
hey
here's,
a
new
field,
I'd
love
it.
If
you
implemented
this
and
then
saying,
if
things
implement
this,
then
I
will
provide
this
to
I'll,
provide
that
information
to
our
users.
G
I
think,
to
to
a
point.
Tracing
is
not
good
that
we
should
encourage
and
we
should
try
to
expose
as
much
as
we
can
until
we're
risking
information
disclosure
about
the
contents
of
things
that
are
being
orchestrated.
That
shouldn't
be
visible
to
the
workload
resource
to
anyone
who
has
visibility
to
that
resource.
G
G
We
don't
know
the
quality
of
the
resources
that
the
supply
chain
will
be
orchestrating.
We
know
there
will
be
a
certain
amount
of
chaos
within
the
implementation
of
the
resources
that
we're
interfacing
to
so,
I
think
like
if
we
expect
too
much
from
those
resources
like
we're,
just
gonna,
be
letting
users
down
on
the
other
side,
also
kind
of
responding
something
stephen
said
about
like
well.
G
If
we
sort
of
enhance
the
contract
to
allow
a
resource
to
provide
an
attestation
about
the
outputs,
I
think
like
if
your
resource
does,
that
great
that's
interesting,
but
a
cartographer
can
never
require
that
to
happen.
Otherwise
it
just
will
never
be
able
to
interface
with
any
other
resources
that
exist.
D
I
want
to
address
the
I
think
something
I
heard
both.
What
both
of
you
just
said
is
around
our
ability
to
capture
providence
information
without
using
you
know,
without
assuming
that
you
know,
observed
generation
works
right
like
to
capture,
if
you
know
assume,
spec
shows
up
in
status
or
something
like
that
and
and
whether
we
can
expect
that
from
tools
and
ecosystem.
D
So
currently
the
orchestrate
k-pac
and
convention
service
is
like
two
primary.
You
know
components
to
do.
A
build,
k-pac
actually
kind
of
does
expose
this
information
already,
but
it
puts
it
on
the
image
right
and
so
that
you
know
you'd
have
to
have
a
very
complex
selector
there
right
that
says.
Well
cartographer,
go
look
at
this
artifact
in
this
register.
Using
the
service
account
right,
but
you
know
it
is
information.
D
That's
exposed
through
that
process
and
convention
service
is,
you
know,
kind
of
joining
the
project,
and
you
have
an
option
of
extending
that
right
to
show
that
information
to
me
it
it
doesn't
seem
unreasonable
for
both
of
those
tools
to
provide
more
metadata
about
the
artifacts
they're
building
right,
I
think
other.
You
know.
I
don't
think
we
can
make
an
assumption
that
everything
you
plug
into
a
cartographer
will
do
that,
but
it
doesn't
seem.
D
You
know,
I
don't
see
a
disadvantage
in
providing
the
ability
through
the
template
resource
to.
If
that
information
is
available,
you
know
collect
it.
You
know
in
a
way
where
we
can
achieve
that.
You
know
kind
of,
or
we
have
a
place
to
centralize-
that
traceability
information
on
the
cluster
that
that
doesn't
seem
like
a
bad
outcome
right.
I
think
this
is
a
problem
that
there
are
some
resources
that
exist
where
they
will.
Never.
D
You
know
their
theoretical
resources
that
exist
where
the
it's
just
not
going
to
be
possible
to
achieve
traceability,
because
whoever
maintains
them
doesn't
care
about
that
right.
We're.
Never.
I
don't
think
we're
ever
going
to
solve
that.
They
don't
don't
have
observed
generation,
because
it's
just
you
know
optional
convention
in
the
ecosystem
you
can
implement.
Doesn't
you
know,
report
anything
about
the
inputs
and
outputs
because
the
author
decided
not
to
so.
D
I
don't
think
it's
a
problem
that
we
will
ever
be
able
to
solve,
where
we
can
say,
if
you're,
using
cartographer
with
anything
in
the
world
you're
going
to
achieve
that
graph
right.
But
I
do
think
that
for
the
tools
we
care
about
and
potentially
more
of
the
ecosystem
that
implements
observed
generation
if
we're
willing
to
make
it
a
template,
author
concern
to
say
yes,
I
understand
that
this
tool
provides
this
information
through
this
mechanism.
D
I
think
we
should
make
it
easy
for
that
template
author
to
turn,
that
on
and
through
that
we
can
ship
supply
chains
right
that
do
provide
that
traceability
and
provide
interfaces
for
when
they
don't
representing.
We
only
got
part
of
the
tree
here.
Sorry,
if
that
makes
sense
like
I
don't
see
another,
you
know
real,
like
a
I'm,
not
sure
what
else
we
would
do.
If
that
makes
sense,.
B
B
B
So
we
should
have
some
some
idea
that
yeah
that
that
field
is
there
when
we
can
provide
it.
So
whatever
implementation
we
do
is
always
going
to
be
a
best
effort,
implementation
in
terms
of,
and
then
the
separate
issue,
and
this
is
far
more
on
the
actual
implementation
side
steven.
You
had
noted
that
kpac.
B
Exposes
a
latest
image
and
then
there
is
actually
like
a
build
object
somewhere
in
the
cluster.
That,
like
has
way
more
detailed
information.
That's
great.
I
would
say
that
runable
is
also
like
that
runnable
exposes
some
output
from
generally
tecton
task
runs
pipeline
runs
and
then
those
task
runs
and
pipeline
runs
do
exist
on
the
cluster
somewhere,
and
so,
if
you
are,
if
you're
a
human
with
like
access
and
like
decent
reasoning
skills,
you
can
like
put
them
together,
but
neither
neither
those
objects.
Neither
runnable
nor
image
make
that
connection
explicit.
B
D
I
wasn't
saying
that
we
should
implement.
You
know
cross-resource
introspection,
just
that
I
I
don't
think
there
are
very
many
barriers
to
having
all
of
those
having
runable.
You
know
with
integration
with
tecton
having
convention
service
and
having
kpac
all
report
to
emit
more
information.
Besides
the
image
like,
for
instance,
in
capex
case
in
the
image
resource,
provide
both
the
digest
and
the
commit
like
those
are
all
teams
we
you
know,
can
talk
to
all
all
software
that
you
know
we
have.
D
You
know
that
kind
of
where
the
people
working
on
those
projects,
you
know
use
cartographer,
also
and
understand.
You
know
like
what
those
needs
are
right.
I
don't
think
there's
a
big
barrier
to
at
least
for
the
components
we
have
now
implementing
this
whole
thing
without
having
to
implement
like
getting
traceability
without
having
to
implement
observed
generation.
I
just
worry
that
it's
not
going
to
work
as
we
expand
out
into
the
ecosystem.
If
that
makes
sense-
and
I
think
the
observed
generation
thing,
there
could
be
a
helpful
tool
in
that
case,.
C
Oh,
but
I
on
the
comments
I
just
mentioned
there,
that
for
runable
specifically
yeah,
it's
simple
to
tie
inputs
with
outputs,
because
you
have
total
control
over
the
outputs
right.
So
as
long
as
yeah
you
implement
it
in
a
way
that,
in
your
outputs,
you
have
the
inputs
boom.
You
have
them
tied
together,
which
means
that,
for
anything
that
is
like
a
run
run
run
once
yeah.
We
can
have
that
contract
very
well
defined,
but
then
for
a
kpak
image,
then
yeah.
We
need
something
more
elaborate.
B
B
D
So
it's
an
interesting
comment
about
like
more
robust
right,
like
on
one
hand
I
could
see
like
having
to
provide
all
the
inputs
in
the
output
seems
like
a
very
specific.
You
know,
like
kind
of
thing.
On
the
other
hand,
though,
like
because
the
resources
you
know
follows
this
kind
of
declarative
contract,
where
you
have
a
specification,
you
have
status
attempting
to
match
the
specification
right
and
there
are
some
things
like
observed
generation
that
can
let
you
say
like
yes,
I
think
this
spec
is
reflected
in
the
status
to
some
extent.
Right.
D
Like
I
don't
know,
it
doesn't
necessarily
feel
wrong
to
me
right,
given
that
it's
not
like
a
you
know,
request
response
system
right.
It's
very
you
know
where
you
have
that
kind
of
strong
association
right.
It
doesn't
seem
that
unreasonable
to
me
to
put
more
information
in
the
status
about
the
you
know,
providence
of
that
artifact.
Really
it
doesn't
bother.
B
Yeah
when
I
was
saying
more
robust,
I
meant
simply
if
we're
relying
like,
I
I
want
to
reduce
the
surface
of
this
configuration
and
it
I
would
not
be
at
all
surprised
if,
because
runnable
can
like
stamp
out
arbitrary
things,
we
actually
do
need
to
give
the
users
the
ability
to
say
like
yeah.
Here's
here
are
the
arbitrary
things
that
would
count
as
an
input,
because
there's
no
way
you
would
know
them.
F
So
I'm
I'm
kind
of
still
confused
on
where
we
landed.
If
I
could
summarize
here,
it
kind
of
seems
like
steven
you're
you're,
mostly
pro
rfc
18
right,
because
this
kind
of
falls
under
the
category
of
let's
do
something
because
doing
nothing
is
not
our
best
foot
forward,
but
it
seems
like
scott
you're,
more
of
the
opinion
that
we
should
do
nothing
because
we
don't
have
enough
due
diligence.
I
think,
as
you
put
to
do
something,
can
we
try
and
reconcile
like
those
two
opinions.
G
No,
I
I
absolutely
did
not
say
do
nothing.
I
think
it
depends
on
what
the
actual
goal
is
and
what
we're
saying
that
we're
doing
so
anytime
we're
proposing
just
surfacing
information
that
exists
onto
the
workload
resource,
to
make
it
easier
for
users
to
discover
what's
happening.
That's
good,
no
issue
there
with
me
at
all.
G
D
G
G
D
I'm
personally
still
not
opposed
to
in
a
limited
like
in
a
controlled
way,
in
a
opt-in
way.
When
you
understand
those
implications
right,
you
know
adjusting
the
runtime
semantics
right
holding
spec,
you
know
if
we
really
truly,
if
we
really
understand
what
those
outcomes
are
and
can
align
on
them.
So
I'm
still
not
opposed
to
you
know
going
down
that
route
or
I
think
I
think
we
should
continue
to
investigate
that,
because
I
don't
think
every
resource
we
find
is
going
to
implement.
D
You
know
showing
you
know,
providing
that
traceability
moving
specular
status
of
inputs,
but
it
seems
like
we're
all
aligned
that
rfc
18
is
good
and
that
we
should
talk
more
about
20.
Maybe
while
we're
talking
about
20
figure
out
other
ways,
we
can
achieve
traceability
that
don't
require
some
of
that
additional
complexity
like
changing
the
runtime
semantics.
F
G
G
D
Did
we
in
rsc-18
did
we
resolve
at
one
point
a
version
of
this?
Had
it
looked
like
it
was
an
artifact
graph,
it
had
the
different
stages,
but
the
artifacts
weren't
actually
connected
to
each
other.
Has
that
been
addressed
or
like?
I
remember
there
was
some
conversation
like
that,
but
it
was
a
while
ago.
B
B
D
B
D
D
F
D
B
To
be
clear,
I
think
there's
there's
value
to
be
had
there,
but
it's
not
the
value
that
the
requester
had.
It
doesn't
match
the
story.
The
motivation,
that's
written
in
rfc,
18
that
that
came
from
our
users,
so
that
that
right,
there
is
why
I
want
to
approve
18,
because
I
I
want
us
to
nail
down.
Are
we
doing
that
that
thing
that
was
asked
for
in
rc
14
when
they
came
to
us,
and
they
said
I
really
need
to
know
when
this
change
that's
made
over
here
finishes
going
through
the
supply
chain?
F
E
G
G
I
don't
think
rc.
Does
that
sorry,
I
don't
think
rc18
does
that
today.
I
think
it
gets
too
deep
into
proposed
solutions
to
actually
be
effective
at
that
high
level
but
like
if
we
were
to
rescue
it
to
sort
of
like
here's,
what
we
think
about
tracing
here's,
what
we
think
about
providence
and
attestation
like
it's,
not
necessarily
the
be
all
end-all
like
it
will
certainly
evolve
over
time,
but
like
putting
a
stake
in
the
ground
and
saying
like
these
are
our
core
tenants
that
we
will
try
to
build
to
over
time.
D
I
I
definitely
agree,
but
that,
like,
if
rfc
18
were
a
commitment
to
solve
the
problem
right
and
and
went
into
detail
about
what
problems
we're
trying
to
solve,
then
I
wouldn't
have
an
issue
I'd
be
like
yes,
that
sounds
great.
You
should
definitely
definitely
agree
with
that
path
forward
and
in
other
projects,
I've
seen
similar
kinds
of
rfcs
that
are
around.
D
You
know
outlining
a
high
level
strategy,
but
it's
it's
the
presence
of
that
artifact
graph.
You
know
that's
very
concrete
without
a
way
to
implement
that
that
it
gives
me
some
pause.
Part
of
one
thing
I
heard
earlier
is
there's.
Maybe
two
use
cases
that
we're
thinking
about.
One
is
like
artifact
tracing
and
the
other
is
like
being
able
to
say
this
turned
into
this.
D
F
The
reason
I
start
to
reason
about
them
in
like
the
same
breath,
is
because
even
with
even
if
we
take
rfc
20
as
a
given
right,
we're
going
to
hit
these
situations,
where,
like
we
possibly
can
trace
an
artifact
up
to
a
point
in
a
supply
chain,
and
then
maybe
there's
like
a
poor,
a
bad
actor
resource
in
our
graph
that
we
can't
trace
past,
and
so
then
like
like.
What
do
we
like?
How
do
we?
F
D
F
I
just
think
it's
the
same
information
in
both
cases
right,
it's
like
you,
do
have
tuples
right,
you
have
a
resource
and
you
have
an
output
and
like
it,
it
really
just
comes
back
to
this
idea.
It
doesn't
even
really
depend
on
what's
in
the
supply
chain,
anymore
right,
because
it's
you
know
it's
the
object
stamped
out
under
the
workload,
but
it's
this
idea
that
I
basically
want
to
draw
a
graph
of
tuples
and
sometimes
like
one
causes
something
and
sometimes
you're,
just
showing
the
latest
to
something
else.
F
B
Oh
well
one.
I
don't
remember
why
I
originally
raised
my
hand,
but
I
you
know,
I
think
josh
one
of
the
we've
talked
and
you've
made
the
case
that
I
think
I
only
made
the
first
half
of
reflected
earlier,
which
is
there
will
be
it's
always
going
to
be.
The
best
effort
and
doing
the
tracing
from
artifact
artifact
is
something
that
we
can
only
do
given.
B
And
I'm
not
opposed
to
having
those
two
graphs
or
those
two.
Those
two
pieces
of
information
are
like
really
similar.
If
you're
saying
like
this
artifact
is
connected
to
this
artifact,
a
subset
of
that
information
would
be
enough
to
say
this.
Artifact
is
connected
to
this
object.
Some
artifact
from
this
object.
E
B
E
We
can
know
ahead
of
time
what
shape
the
supply
chain
takes.
That's
information
that
that's
information
that
we
can
reflect
on
the
workload
we
can
reflect
on
a
supply
chain
and
say
the
supply
chain
will
take
these
different
shapes
depending
on
like
pathing
information
and
that's
something
I've
been
working
on,
and
I
think
there
is
good
reason
to
have
that
information
separate,
but
the
same,
and
the
main
reason
is
because
I
see
with
more
of
our
ways
of
optionally
choosing
a
path
for
a
given
workload.
E
I
still
think
anything:
that's
in
the
artifact
graph,
that's
no
longer
valid
would
still
be
easily
linked,
so
the
artifact
graph
should
be
able
to
say
it
went
through.
This
object
is
no
longer
there
than
to
this
other
one,
but
there
should
still
be
a
truther
as
now
selected
for
the
workload,
something
that
we
can
observe.
E
So
those
are
my
thoughts
and
I
will
definitely
try
at
some
point
soon
to
because
I've
been
wondering
how
do
we
talk
about
high-level
design
goals
and
I
feel
like
having
a
deterministic
supply
chain
would
be
incredibly
valuable,
help
us
get
people
to
demur
on
using
ytt
for
all
sorts
of
things
and
just
use
it
for
the
things
that
our
templating
doesn't
support
like
looping
and
interpolation,
rather
than
making
choices,
which
I
think
we
can
make
it
a
higher
level
and
make
it
much
more
deterministic.
So
that's
my.