►
From YouTube: Cartographer Office Hours - Apr 18, 2022
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).
A
Run
right
welcome
everyone
to
the
cartographer
office
hours
today's
april
11th
and
well
we'll
glad
we're
glad
that
you're
here,
because
the
ideas
that
keep
making
cryptographer
great
every
week,
all
right
joshua,
will
help
us
today
today,
with
the
note
taker,
feel
free
to
add
yourself
to
that
in
this
list,
including
your
affiliation.
So
we
can
catch
up
later
on.
A
All
right
any
new
faces,
let
me
see
no
jaclyn.
No,
I
guess
no,
not
exactly
new
faces,
so
welcome.
All
all
right,
we'll
start
reviewing
outstanding
rfcs,
considering
some
rfcs
that,
having
let's
say,
label,
not
exactly
labeled
but
considered
priori
rfc.
A
B
The
team
is
proposing
here
that
we
actually
reject
this
rfc.
We
don't
think
it's
necessary,
so
we
just
wanted
to
bring
it
up
and
get
a
feel
from
everyone
else.
A
C
As
the
author,
I
yeah
I'm
pretty
convinced
that
we
don't
need
it
anymore,
so
yeah
happy
to
move
this
to
closed
or
rejected
or
whatever.
E
Yeah,
if
it's
not
needed
scott,
I
think
I
saw
you
had
that
comment
on
there
was
there
anything
from
your
point
of
view.
F
A
A
B
D
I
think
it
was
to
get
more
feedback
from
the
toc
since
rash
had
responded
to
the
initial
comments.
But
it
looks
like
scott
just
put
some
comments
up
in
the
last
couple
hours.
F
B
It
would
be
good
so
if
we
just
update
the
basically
the
summer
summary
of
the
rfc,
would
that
be
all
that's
really.
F
D
One
question
I
have,
though,
is
are-
and
this
just
like
in
general,
our
events
and
like
specifically
the
types
of
events
and
the
reasons
are
those
part
of
like
a
public
facing
api.
Or
do
we
consider
that
kind
of
like
log
messages,
because
if
it
is
part
of
the
public-facing
api
like
we
would
want
to
codify
it
to
an
extent
and
ensure
that
we
don't
break
that
or
anything
and
then
I'd
want
to
see
them
laid
out
explicitly
in
the
rfc.
F
F
In
the
broader
ecosystem
of
securities,
I'm
sure
somebody
has
done
that.
Typically,
I've
never
seen
it.
F
D
D
Either
you
know
reasons
are
rfc'd
or
they're.
Not.
Is
that
what
I'd
like
to
say
right
because
like
if
you
don't,
if
you
need
an
rc
to
remove,
not
to
add
that
means,
you
know
anybody
could
go
add
one
without
an
rfc
and
then
everyone
else
is
stuck
supporting
that
forever.
Until
you
make
an
rc
to
remove
it,
you
know.
G
D
Can
this
just
be
like
a
pr
to
contributing,
rather
than
an
rfc,
and
people
can
put
their
thoughts
on
the
pr
like?
I
don't
know
what
this
rfc
means
I
mean
like
I'm
happy
to
like.
I
think
it
should
def.
There
should
definitely
be
guidance
in
terms
of
what
we're
doing,
but
it
feels
a
little
weird
as
it
if.
D
F
I
think
I
think
it's
it's
fair
for
rfcs
to
define
best
practices
and
how
a
cartographer
embraces
those
established
best
practices
so
like
producing
events
is
a
good
practice
for
a
controller
and
this
sort
of
describes
how
cartographer
approaches
that
space
within
its
domain.
So
I
think,
having
that
as
an
rfc
is
not
bad.
F
D
E
G
E
Want
to
overkill
rc's,
I
think
everybody
when
he
works
on
more
rfcs
than
anything
else,
so
we're
good
to
try
and
find
the
balance,
and
hopefully
we
can
as
we
evolve.
We
can
find
more
that
leans
into
more
coding
reviews
and
various
other
practices.
You
know
around
guidance
is
as
opposed
to
fully-fledged
rfcs
checking
everything
that's
going
in.
It
doesn't
need
to
be
like
that.
You
need
to
have
freedom
to
be
able
to
work
and
involve,
and
then
we
have
at
higher
levels.
A
D
B
B
C
I
think
we
need
to
give
an
opportunity
right
for
people
to
like
accept
it.
I
think
it's
a
little
too
quick
for
a
turnaround
for
something
like
this
to
just
blanketly
assume
that
people
are
abstaining.
C
Yeah,
I
I
don't
think
we
need
to
wait
that
long
right,
maybe
just
like
another
week
or
something,
and
then
we
can
assume
that
we'll
just
try
and
get
people
on
board
and
if.
C
C
I'll
just
say:
we'll
give
it
one
more
week,
and
then
we
can
start
moving
to
final
comment
period
next
week.
How's
that
sound.
E
I
guess
it
does
seem
like
is
it
do?
Do
we
lose
a
whole
week
there
right
it's
just
just
and
wonder
if
there's
anything
we
can
do
to
say
think
you've
they've
had
a
week.
People
have
had
a
week,
it's
been
talked
about,
you
know,
there'll,
be
discussions
in
slack
or
in
office
hours
like
if
you
haven't
said
anything
now
or
maybe
even
asked
to
comment.
Then
it's
gone
past.
I
don't
know
a
set
number
over
approved.
Then
we
can
just
move
it
through.
I
don't
know
just
a
thought.
D
I'd
plus
one
that,
like
we
have
with
the
author
and
the
two
approvers
from
the
team,
that's
almost
half
the
team
plus
two
members
of
the
toc
and
like
there's
no
formal
process
of
like
how
long
it
takes
to
be
considered,
abstaining
and
like
it
was
presented
at
a
meeting
last
week.
Talking
about
it
now
had
a
week
to
look
at
it.
D
B
C
I
think
that
makes
sense.
The
only
thing
I'm
trying
to
avoid
is
like
someone
being
on
vacation
for
a
week
and
then
they
like
me,
they
have
like
legit
concerns
about
something
and
they
never
get
a
chance
to
voice
it
right.
So,
as
long
as
like,
we
can
avoid
like
that
simple
turnaround
where
someone
like
doesn't
get
to
voice
their
their
objections.
It
doesn't
feel
like
this
is
the
case
for
this
one.
So
I
think
it's
fine.
I
So
the
only
waiting
period
that's
mentioned
in
the
rfc
process,
doc
is
a
seven
day
final
comment
period,
assuming
there's
contention
right.
If,
if
people
disagree
about
something,
then
then
we'd
say:
okay,
we'll
we'll
wait
a
week
and
all
that,
let
things
freak
out
a
little
bit
more,
but
other
than
that
it.
I
We
should
get
that
in
the
rules
and
not
move
to
that
before
we,
you
know
have
figured
out
what
it
looks
like
right.
C
I
I
mean
for
now,
if
you're
going
to
abstain,
comment
on
the
rfc
with
something
that
says.
I
abstain,
so
that
we
know
we
can
move
on,
because
otherwise
we're
just
going
to
we're
going
to
have
to
have
the
discussion
for
every
rfc
about
how
long
we
wait
for
people
who
haven't
made
any
indication
of
what
their
opinion
is
yet
right.
D
I
C
D
I
I
I
C
No,
it's
fine
and
we
actually
call
this
out
right.
We
actually
say
that
we
require
a
time
period
of
no
less
than
five
working
days
for
comment
and
remain
cognizant
of
holidays
and
stuff.
C
A
Yeah
right,
so
this
rc
should
be
still
with
you
for
the
five
days
period
that
you
mentioned
joshua
and
then
fcp
then,
or
for
what.
A
Okay:
okay,
now
come
on
blue
plane
architecture.
D
D
Okay,
so
this
one
is
still
in
draft
state
like
it's
a
draft
pr,
because
we're
still
looking
for
feedback
on
some
options
here
and
we
got
a
little
bit
of
feedback
but
still
want
to
present
it
to
everyone.
So
we
could
discuss
it
a
bit,
but
the
basic
idea
is
collapsing.
All
the
current
blueprints,
which
we've
used
to
define
supply
chains
and
deliveries
so
collapsing
all
supply
chains
and
deliveries,
and
now
all
templates
into
a
single
crd,
called
the
cluster
blueprint.
D
And
so
the
idea
there
would
be
everything
all
templates
other
than
cluster
on
template
templates
and
supply
chains
would
all
have
a
way
of
defining
of
like
being
selected
against
and
defining
resources
to
stamp
out,
and
I
guess
to
start
with
like
why
we
want
to
do
this.
D
First
of
all,
there's
like
seven
crds
that
you
need
right
now
to
create
a
simple
supply
chain
or
delivery,
so
simplifying
that
data
model
can
be
helpful
for
users
to
not
have
to
learn
all
the
different
crds
and
when
to
use
which,
where-
and
there
have
been,
there
have
been
a
lot
of
steps
a
lot
of
times
where
we
said
it
would
be
nice
if
we
could
reconcile
templates,
but
it's
always
the
trade-off
of
like
well.
It
would
be
nice
to
reconcile
them,
but
there's
also
five
new
reconcilers.
D
This
also
would
be
a
way
of
enabling
snippets,
which
we've
talked
about
and
yeah.
So
there's
two
options
for
how
to
do
this.
D
So
the
first
one
I
should
have
reviewed
this
before
I
started
presenting
sound
wrote
this
while
ago,
but
the
first
one
is
basically
saying
that
every
blueprint
will
have
an
optional
selector
field,
because
you
could
either
define
templates
that
can
be
selected
against
directly
or
not
and
would
then
only
be
meant
to
be
used
as
part
of
a
larger
blueprint
and
then
every
and
then
the
blueprint
would
have
this
resource,
this
list
of
resources
and
they
look
exactly
the
way
resources
look
right
now
in
a
supply
chain
for
the
most
part
except
one.
D
D
And
then
other
than
that,
it's
pretty
similar
except
some
names
have
changed
because
you
know
templates
are
now
blueprints
other
than
that.
It's
pretty
similar.
But
the
difference
here,
which
is
true
about
both
options,
is
that
since
there's
just
a
cluster
blueprint,
there's
no
source
or
image
or
config
templates
outputs
are
are
whatever
you
want
them
to
be.
D
So
you
would
have
to
name
your
output
and
the
value
and
the
path
at
which
to
grab
the
value
for
every
blueprint,
and
so
you
can
name
them
whatever
you
want
and
just
define
like
which
resource
to
look
for
for
an
output,
and
so
like
here
we're
saying,
look
at
the
first
resource
and
grab
the
output
foo
and
if
you
go
up
to
the
first
resource,
since
this
is
a
resource
which
is
inlining,
it
is
defining
this
output
foo,
which
lives
at
status.url,
and
the
same
thing
would
be
true
for
all
of
them,
like,
even
if
you're,
not
inlining
and
you're,
just
referencing
another
another
blueprint.
D
The
main,
I
think
only
difference
between
this
and
the
second
and
the
second
option
is
the
second
option
does
not
allow
inlining
of
temp
of
templates
or
blueprints
within
the
resources
block,
and
so
every
blueprint
now
functions
either
as
a
supply
chain
or
as
a
template
in
today's
world.
So
either
you
have
resources
which
reference
other
blueprints
or,
or
you
make
this
blueprint
the
blueprint.
That's
actually
templating
out
a
stamped
object
other
than
that
the
options
are
the
same.
D
But
the
idea
was
that
you
know
this
inlining
gets
a
little
bit
hard
to
follow,
even
though
it
can
be
nice
and
helpful
on
the
smaller
scale.
Like
you
know,
in
the
larger
scale,
can
create
some
really
hard
to
read
blueprints,
and
so
it
might
be
easier
to
use
if
we
kind
of
constrain
every
blueprint
to
either
act
as
a
supply
chain
today
and
define
resources
or
act
as
a
template
today
and
just
define
the
template
or
ytt.
C
C
Sorry
question
is
there,
so
is
this
whole
thing
written
so
that
outputs
are
custom
or
is
there
any
strong
typing
still.
D
I
I
actually
had
the
same
basically
the
same
question,
but
I
left
a
kind
of
a
longer
form
version
of
that
comment.
Just
just
yesterday.
I'm
not
sure
if
you
had
a
chance
to
look
at
it,
yet
I
wonder
if
it's
possible
to
preserve
like
I
really
I
really
like
this
idea.
First
of
all,
like
you
know,
I
think
it's
a
great
way
to
go.
I
I
really
like
the
simplicity,
ads
and
kind
of
the
added
flexibility
the
I
like
the
idea
of
getting
rid
of
the
maybe
call
it
static
types
right
like
having
each
of
the
resources
for
each
type.
You
know
require
an
explicit
crd
cluster
image
template
cluster
source
template.
You
know,
that's
always
felt
very
inflexible
right.
It
could
be
great
if
we
could
maintain
that
typing,
but
not
have
to
kind
of
you
know,
maybe
directly
encode
the
typing.
You
know
into
the
kind
of
ux
we're
creating.
I
I
wonder
if
it's
possible
to
you
know,
maybe
if,
like
right
now,
we
have
strong
static
types
right.
Maybe
we
could
move
to
strong,
dynamic
types
or
something
like
that
where
we
still
maintain
the
types,
so
you
can
still
swap
a
template
that
outputs
an
image
for
any
other
template
that
outputs
an
image,
but
we
don't
have
to
put
the
names
of
the
types
and
the
kinds,
for
example
the
resources
like.
Could
you
have
cluster
blueprint
that
you
know
outputs
a
type
and
then
maybe
maybe
there
are
two
crs?
I
Maybe
there's
a
cluster
blueprint,
type
cr?
Where
you
could?
You
could
use
the
register
types
in
the
system
that
has
a
open
api.
You
know
schema
for
what
that
type
looks
like
or
something
along
those
lines
right
like
is
there
a
way
we
can?
You
know,
make
the
types,
something
that
a
distribution
of
carto
like
like
sorry,
maybe
a
platform
built
using
cartographer,
defines
right,
but
aren't
aren't
hardcoded
into
cartographer
itself
and
still
maintain
that
swap
ability
turn
maybe
make
it
a
little
more
of
a
generic
tool
in
that
way,.
D
I
Right
now
we
have
like
a
void
type,
which
means
there's
no
output,
but
we
we
don't
have
like
you
know
generic
box,
like
generic
string
type
right.
You
know
maybe,
instead
of
saying
that
the
types
are
optional.
Maybe
you
know
if
somebody
wanted
to
create
a
generic
string
type
right,
that's
a
type
they
could
register
specific
to
their
platform.
I
H
I
think
the
one
thing
that
I
that
is
possibly
worrisome
with
this
approach,
but
I
think
that
what
steven
is
saying
may
help
with
is
we've
seen
people
using
cartographer,
where
you
can
separate
our
back
between
like
a
supply
chain
and
the
actual
templates
a
lot
of
times.
I
Would
you
prefer
to
manage
that
by
having
namespace
scope
blueprints
instead
of
like
letting
a
developer
access
cluster
level
resources
like
if
there
were
namespace
code
blueprint?
Would
that
solve
the
problem?
Sorry.
H
I
think
it
could
solve
the
problem.
I
think
that
possibly
having
the
two
crds,
where
one
is
a
blueprint
and
one
is
a
template,
even
if
we
took
away
the
strong
typing
and
just
had
a
template
which
would
be
used
for
source
image,
config
cluster
template.
Anything
like
that
and
one
for
the
supply
chain
allows
also
even
staying
at
the
cluster
level,
the
ability
to
say
you
can
configure
things.
H
I
And
sorry,
scott
I'll,
let
you
quit
a
second
just
one
final
clarification.
So
when
you
think
about
that
separation,
do
you
want,
because
you
know
something
implied
by
the
proposal-
is
that
you
can
encapsulate
kind
of
a
supply
chain
definition
and
something
that's
reusable
right?
Is
it
the
is
the
thing
you
want
to
restrict
access
to?
You
know.
I
Any
combination
of
you
know
any
kind
of
coordination
of
templates
together,
or
is
it
just
the
the
one
that
selects
the
descriptors
that
you
want
to
gain
access
to,
because
in
this
world
I
you
know,
I
imagine
some.
Some
of
these
would
have
that
selector
at
the
top
and
some
wouldn't
right
and
the
ones
that
don't
are.
You
know
just
kind
of
like
templates,
but
they
may
be,
may
actually
be.
You
know
a
combination
of
resources
or
and
some
would
actually
have
the
selector
and
it
would
apply
to
the
platform.
H
A
Thank
you,
scott,
so
much
scott
andrews
you,
yes
even.
F
I
I
have
more,
I
have
more
questions
if
somebody
else
doesn't
work,
yeah
go
for
it
for
your
selector
at
the
top,
because
this
kind
of
you
know
before
we
had
workload
and
deliverable
right
as
different
descriptors.
It
seems
like
that
selector
would
need
a
kind
also
or
like
it
would
need
to
define
the
type
of
descriptor
that
it
applies
to.
It
might
be
good
to
just
kind
of
flesh
out
that
section
a
little
bit,
because
it
seems
like
it's
going
to
be
pretty
different
from
what
we
had
before.
D
That's
interesting,
I
mean
the
way
the
way
supply
chains
are
now.
It
doesn't
explicitly
reference
workload
just
as
like
spec
dot,
and
it's
knowing
that
it's
looking
at
some
sort
of
owner
and
so
you're
saying
you
might
want
to
restrict
certain
blueprints
to
only
match
against
a
workload
versus
a
deliverable.
I
Yeah,
because
right
now
we
have
supply
chain
and
delivery
as
separate.
You
know
things
that
can
do
selection
against
their
respective
descriptors
right,
but
if,
in
this
world,
if
we
just
have
one
type
there
we'll
need
to
say
you
know
what
it
selects
against,
and
maybe
that
could
be
something
that
the
user
could
bring
also
like
there's,
because
we
don't
have
a
contract
with
the
spec
of
the
descriptor.
I
That's
only
in
the
templates
right
that
could
be
a
resource
that
you
know
actually
could
be
brought
from
outside
of
cartographer,
which
I
think
is
really
interesting
to.
Let
you
maintain
your
own
descriptor
as
a
platform
author,
you
could
have
your
own
spec
fields
make
your
own
conversion
web
hooks,
even
if
you
wanted
to
migrate
it
forward.
I
think
that
it's
a
lot
of
interesting
stuff.
I
think
this
opens
up
there,
but
you
would
need
a
kind
reference
in
the
selector.
E
Go
check
one
when
somebody
on
the
first
option,
you
it's
not
right
there,
so
it's
mutually
exclusive!
You
can
still
do
the
reference
to
another
blueprint
name
or
do
a
I'll.
Have
it
and
then
have
another
one
as
referencing
doing
an
inline,
you
could
still
use
both
yeah.
It
makes
sense.
Okay,
yeah.
D
D
I
I
wonder
if
the
separation,
instead
of
being
blueprint
and
template,
if
it's
more
like
instead
of
pushing
selector
into
blueprint,
we
should
take
selector
out
of
blueprint
and
the
thing
to
decouple
is
just
you
know:
maybe
a
cr
that
maps
a
selector
to
a
blueprint,
and
then
you
preserve
that
you
know
kind
of
nested,
reusable
nature
of
the
definition
and
then
the
thing
that
actually
acts
on
the
cluster
right
can
stay
outside
of
it
and
have
separate
our
back,
because
I
think
I
think
that
would
solve
scott's
problem.
I
J
H
D
F
D
I
I
also
like
option
two,
I
think
just
keeping
it
really
flat
and
preserving
that
current,
you
know
way
of
defining
a
template.
That's
you
know,
sort
of
straightforward.
I
also
you
know
at
some
point
it
feels
like
you
might
want
your
templates
to
be
in
a
git
repo
or
not
on
the
cluster
right
and
so
to
me.
Option
two
might
lend
itself
a
little
better
to
that
long
run.
E
Just
I
I
did
like
the
inlining
just
to
really
mess
it
up.
No,
I
think
I
think
I
I
I
I
take
what
scott
and
steven
was
saying.
I
guess
where
I
was
coming
from
like
being
able
to
visually
understand
and
get
that,
and
you
know,
follow
something
through
is
quite
quite
appealing
and
having
the
indirections.
Sometimes
it's
quite
hard
to
rationalize.
You
know
we're
looking
at
different
resources,
but
I
guess
you
could
imagine
these
could
probably
escalate
quite
quite
badly.
E
J
I
I
think
at
some
point
it's
worth
deciding
you
know.
Is
this
a
thing
where
we're
going
to
make
a
new
api
version
of
a
bunch
of
conversion
web
hooks?
Or
should
we
say
you
know
we
keep
the
old
things
supported
for
an
amount
of
time
and
then
here's
a
separate
thing
over
here
right
some
decisions
to
make
it
seems
like
we
have
a
bunch
of
bunch
of
changes
like
this,
that
we
want
to
wrap
up.
I
I
wonder
if
there's
a
design
where
you
could
have
the
template,
like
the
blueprint,
can
be
a
template
at
the
top
level
right.
So
there's
there's
not
a
lot
of
you
know
deep
nesting
right,
but
at
the
same
time,
when
you're
specifying
that
those
that
resource
list
you
have
the
option
of
providing
a
template
in
line
right,
in
addition
to
providing
a
reference
to
one
and
that
way,
the
way
everybody
wins
we
get,
the
the
things
can
be
templates
at
the
top
level.
I
We
can
have
the
resource
list
and
your
resource
list
can
look
like
a
bunch
of
templates
in
a
row.
If
you
want
one
really
long,
you
know
you
know
if
you
want
to
really
avoid
indirection
and
have
just
one
supply
chain.
That
is
everything
together
in
one
definition,
you
could
do
that
right.
Just
you
know,
give
folks
all
the
different
organizational
options
they
want.
So
you've
got.
D
A
All
right
moving
quickly
to
what
will
be
next
rfc,
the
one
that's
still
blocking
dlc
simplify
runnable
usage,
which
is
not
here
but
was
wondering
if
there
are
comments,
especially
from
dlc
members
around
these
rfc.
I
I
You
know
kind
of
separate
from
the
other
one
right
where
you'd,
like
you
know,
create
a
new
reconciler
for
the
you
know,
in
order
to
reconcile
like
one
of
the
cluster
templates
into
a
cluster
run,
template
and
a
runnable
like
there's,
there's
an
architecture
that
could
work.
You
know
you
know
with
an
extra
reconciler
to
make
this
one
work.
I
think
there's
a
lot
of
reluctance
around
doing
this
before
787.
If
we're
going
to
do
787
just
so,
we
don't.
I
You
know
kind
of
create
one
architecture
over
here
to
solve
this
one
problem
and
then
have
to
you
know,
replace
a
lot
of
functionality
get
rid
of
a
reconciler
later
once
we
have,
the
ability
to
inline
cluster
run
template
into
the
runnable,
so
we
don't
need
to
kind
of
reconcile
out
that
resource
right
and
so,
instead
of
you
know,
playing
this
and
rewinding.
Some
of
it
and
then
playing
the
next
one,
especially
if
we're
going
to
bash
a
bunch
of
breaking
changes
up
into
an
api
version
release.
I
It
might
make
sense
to
look
at
787
first
and
see
what's
possible
there.
Some
interesting
things
about
787
and
kind
of
a
reason.
So
something
that
makes
me
feel
like
this
can
be
a
bunch
of
changes
wrapped
together
in
787.
I
I
think
the
big
like
difficult
thing
to
get
past
to
make
this
work
is
the
multiple
layers
of
templating,
which
is
just
due
to
the
selector.
So
runnable
has
this
idea
of
selector.
It
basically
selects
another
descriptor,
and
you
know
somehow
that
feature
ended
up
in
runable.
I
You
know,
because
I
think
you
know
it
let
it
be
used
in
a
kind
of
self-contained
way
to
select
against
a
tecton.
You
know
pipeline
to
be
used
with
the
tactile
pipeline
run,
but
it
may
be
that
that
selector
is
it's
kind
of
similar
to
the
top
level
descriptor,
and
so
I
wonder
if
that
in
the
long
run
could
turn
into
like
you
know,
secondary
descriptors,
that
don't
trigger
the
creation
of
instantiation
of
the
blueprint.
I
But
you
know
let
you
reference
additional
resources
and
then
then
you
could
pull
that
out
of
runable.
Then
it
would
be
possible
to
inline
run
template.
Then
it
would
be
possible
to
you
know:
it'd
be
easier
to
create
that
shortcut
right
and
so
there's
kind
of
a
bunch
of
changes
here
that
are
interconnected,
that
I
wonder
like
if
the
larger
architecture
you
know
might
encompass,
does
that
make
sense?
I'm
kind
of
this
is
a
little
bit
of
rabbit,
holder.
C
Sorry,
I'm
just
trying
to
take
notes
fiercely,
but
I
also
have
a
quick
question
when
you
say
a
more
generic
approach
to
selecting
other
objects
in
the
cluster
right.
How
like
is
that
by
allowing
other
objects
to
be
selected
against
a
supply
chain
like
with
the
supply
chain
or
blueprint
or
whatever
we
want
to
call
it,
or
is
that
like
allowing
objects
to
be
selected
with
a
workload
like?
How
do
you.
I
You
know
it's
like
a
little
purpose
built
for
one
specific
use
case.
I
wonder
if
taking
that
selector
functionality
and
moving
it
up
to
the
supply
chain
level
right
the
blueprint
level
right
and
then
allowing
that
to
be
templated
at
the
top
level.
I
Like
you
know,
in
in
the
cluster
template,
instead
of
the
cluster
run,
template
right,
would
you
know
just
the
same
way
we
do
with
workload
right
so
it'd
be
like
the
only
difference
between
it
and
workload
between
like
extending
it
to
like
you
can
have
n
number
of
descriptors
instead
of
one.
Is
that
these
creation
of
these
other
descriptors,
doesn't,
you
know,
create
an
instantiation
of
the
whole
thing
right,
they're
just
used
alongside
a
workload
right.
I
I
wonder
if
pushing
that
up
into
that
kind
of
blueprint
level
would
you
know,
make
runnable
simpler
and
its
purpose
a
little
more
well-defined
and
you
know
kind
of
stop
us
from
needing
to
manage
templating
on
top
of
another
templating,
which
is
why
we
can't
inline
it
today
or
why
the
barrier
to
enlightening
it
that
we've
identified
today.
C
And
then
these,
like
other
objects,
that
got
selected
alongside
your
alongside
your
workload,
would
just
get
injected
into
every
single
template
along
the
way.
F
Interesting
cool,
so
one
way
I
was
thinking
about
this,
just
as
we
were
talking-
and
maybe
this
is
right.
Maybe
this
is
off,
but
if
we
took
the
notion
of
params
that
currently
exist
and
basically
said
instead
of
defining
them
statically
either
as
part
of
the
template
or
as
part
of
the
supply
chain,
we
could
take
it
and
make
the
param
sort
of
have
another
way
of
defining
the
default
value,
where
you're
basically
saying
go
actively.
Look
for
some
other
context
in
the
cluster
and
then
use
that
as
the
value
that
gets
injected.
F
So,
basically,
just
using
a
take
take
the
existing
param
infrastructure,
so
that
allows
us
to
pass
individual
key
value
pairs
from
the
supply
chain
to
a
template
and
basically,
instead
of
taking
the
existing
default
value.
I
I
I
think
we
need
some
way
of
saying
that
the
descriptors
are
co-labeled
right
or
something
like
that.
There's,
because
it's
not
that
you
want
to
grab
every
tactile
pipeline
in
the
name
space
it's
next
to
the
workload.
It's
that
you
want
to
grab
the
tactile
pipeline.
That
has
you
know
the
workload
name
and
it's
as
a
label
on
it
or
something
like
that.
Right.
F
I
F
Actually,
I
think
that's
a
key
advantage
of
this
is
that
it
gives
you
a
way
to
parameterize
supply
chains
that
without
having
to
actually
specify
all
the
parameters
on
the
workload.
So
you
could
have
like
a
resource
and
a
namespace.
That's
configuration
for
supply
chain
without
having
to
sort
of
specify
that
config
on
every
single
workload.
C
F
I
I
I
I
wonder
if
we
need,
like
some
higher
level
architectural
plan,
that
accounts
for
this
train
and
blueprints-
and
you
know
like
seems
like
a
lot
of
these
changes-
are
some
of
these
changes
could
happen
in
the
current
instance
of
you
know,
current
version
of
cartographer
in
a
way
that's
non-breaking
right,
and
we
should
do
that
where
possible,
if
we
feel
like
it's
worth
delivering
that
value
soon
right,
but
then
a
bunch
of
these
changes
that
are
more
breaking,
we
should
probably
wrap
together
and
say:
okay,
this
is
the
next
api
version,
or
this
is,
you
know,
gonna
sit
next
to
kind
of
the
stuff
we
already
did,
maybe
having
a
oh,
you
know
one
proposal
that
kind
of
accounts
for
these
different
things
together
that
are
very
interconnected
and
kind
of
help
clarify
that
I
know
scott
you've
been
asking
for.
A
All
right
yeah!
Well,
I
guess
not
enough
time
left
we're
introducing
any
additional
rfc
for
everyone
else
out
there
keep
an
eye
on
the
on
the
rfc
board
there
you
can
have
a
sense
on
the
actual
status
of
each
rc
and
yeah
keep
adding
to
the
discussion
there.