►
From YouTube: Cartographer Office Hours, Feb 22nd, 2022
Description
00:00 Intro
03:39 Thoughts on why multipath is a strong choice for the project
31:29 RFC Supply Chain tracing (proposal to move to FCP)
41:47 RFC: more option selectors (proposal to move to FCP)
43:41 RFC: add matchFields and matchLabels (proposal to move to FCP)
57:53 Amend options matcher context to remove workload prefix
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
A
A
D
Yeah,
so
maybe
we
could
just
go
over
them
and
then
see
if
we
agree
or
disagree
with
someone's
comments
right
and
then
because
we
yeah,
we
do
need
to
make
a
decision
right
between
multi-path
and
type
supply
chains
because
we
need
to
move
forward.
So
so,
what's
he
saying
some
of
these
thoughts
on
my
multiple
strong
choice.
D
The
supply
chains
themselves
don't
end
up
containing
all
that
much
useful
information
because
they
basically
both
share
this
configure
step,
which
contains
the
bulk
of
your
logic,
and
then
they
each
have
a
separate
second
step
or
in
the
first
case
like
on
line
17,
git,
ops
and
online
17.
The
second
one
redrops,
so
most
of
your
logic,
is
encapsulated
away
somewhere
else.
B
I
I
wonder
how
what
you
know
thinking
about
encapsulation
of
the
supply
chains
like
this.
The
second
point
is
about
you
know:
if
you
do
this
encapsulation,
you
still
only
kind
of
get
one
supply
chain
at
any
level
right.
Your
your
output
is
always
you
know,
kind
of
well
defined
from
the
perspective
of
a
single
supply
chain
right
and
that's
a
like
disadvantage,
or
it's
less
flexible
compared
to
multi-path,
where
in
multi-path
you
can
overlay.
B
You
know
any
number
of
supply
chains
on
top
of
the
same
supply
chain
right.
A
supply
chain
can
be
20
different
supply
chains,
and
it
just
depends
on
you
know
the
conditionals
at
the
higher
ones
and
how
they
drive
different
inputs
at
the
lower
ones,
and
you
lose.
You
lose
some
context
there
right
it's.
You
can
no
longer
look
at
a
supply
chain
and
kind
of
know.
What's
going
to
happen,
you
know,
but
but
you
do
have
that
extra
flexibility
and
is
more
concise
to
express
you
know.
B
The
supply
chain
can
have
different
outputs.
I
I
wonder
how
much?
How
important
is
it
to
be
able
to
have
supply
chains
that
have
different
outputs
that
are
well-defined
outputs,
where
you
can
look
at
a
workload
and
understand
what
the
final
artifact
is
versus
having
multiple
supply
chains,
for
you
know
different
artifact
outputs,
you
know:
do
we
do
we?
How
critical
is
that
functionality.
E
I
think,
from
my
point
of
view,
I've
always
felt
found,
but
a
lot
easier
to
clock.
Any
of
this
is
by
go
through
these
examples
that
you've
got
you
know
showing
up
there
josh.
I
think
that's
really
helpful.
I
think
where,
where
I
was
coming
from,
it
was
mainly
around
the
ux
of
this,
so
I
think
we
know
that
things
can
be
a
little
bit
complex,
there's
a
little
bit
of
on-ramp
on
the
moment
and
right
now,
our
interface
for
the
supply
chains
is
via
yaml.
E
It
does
feel
like
we
can
come
up
with
some
elegant
solutions,
but
it's
hard
at
the
moment
for
people
to
understand,
what's
going
on
when
with
their
supply
chain,
to
maintain
and
manage
their
supply
chains,
there's
lots
of
indirection.
So
I
think
it's
one
of
these.
It's
one
of
these
things.
I
don't
have
a
strong
enough
opinion
for
anything.
F
I'm
a
big
fan
of
the
multi-path,
I
think
over
the
snippets
just
because
I
think
the
flexibility
makes
it
a
lot
easier.
I
have
had
again
with
the.
If
we
use
snippets
there
will
be
a
lot
of
cases
with
many
supply
chains
to
that
could
be
solved
in
a
single
supply
chain,
and
I
think
that
it
doesn't
prevent
you.
If
someone
wants
to
create
supply
chains
that
are
easier
to
understand,
they
still
can
do
it
with
multi-path.
They
don't
need
to
use.
Multi-Path
multipath
is
just
an
escape
hatch.
F
B
Snippets
still
allows
you
to
take
multiple
paths
right
like
as
long
as
you
define
those
pads
as
different
optional
snippets.
You
can
get.
You
have
the
same
power
right
in
the
end,
except
for
you
know
there
are
some
edge
cases
like
at
the
point
where
we
start
needing
to
define.
We
don't
have
this
yet,
but
if
we
need
to
define
supply
chain,
outputs
right
like
say
we're
going
to
create
a
source
or
source
supply
chain
cluster
source
supply
chain
cluster
image
supply
chain,
then
snippets
can
be
a
little.
B
You
know
if
we
use
that
implementation
to
implement
snippets.
You
know,
then,
then
you
can't,
you
know,
have
a
multi-path
version
that
has
truly
different
outputs.
Instead
right
so
they're,
you
know,
but
aside
from
kind
of
the
boundaries
of
of
that
they
don't
one
doesn't
seem
more
or
less
powerful.
To
me,
it
just
seems
like
they're
different
user
experiences,
for
how
you
configure
kind
of
the
same
outcome.
F
B
F
F
You
know
where
things
are
going
to
when
it
gets
more
complex
and
you
have
you
know,
seven
options
for
a
specific
thing
or
whatever
yeah
it
becomes
complex
there.
But
that's
where
you
know
graphs,
like
you
know,
rasheed
was
building
for
you
know
where
you
could
get
a
ui
kind
of
come
out
from
the
supply
chain
or
something
like
a
dry
run.
That
would
tell
you
what
the
path
would
be
taken
from
a
workload.
B
I
think
I
worry
about
you
know
what
it
would
be
like
to
design
a
ui
to
build
a
supply
chain.
If
you
know
like
to
be
able
to
cover
that
you
have
a
conditional
input
further
up.
The
graph
then
drives
other
inputs
that
based
on
which
input
is
driven,
makes
decisions
further
down
in
the
graph
and
that
that
can
nest
right
and
that
sort
of
you
can
end
up
like
a
supply
chain
builder
would
have
to
to
cover
the
full
functionality
right.
B
F
It
wouldn't
be
any
different,
except
for
the
fact
that
you
could
just
blob
things
together
and
say:
hey
this
is
you
know
we're
doing
stuff
here?
This
is
a
you
know
closed
whatever.
It's
just
showing
less
information
right.
If
you
wanted
to
show
all
the
information
in
both
cases,
you
have
the
same
amount
of
paths.
B
I
think
with
snippets
you
can
use
encapsulation
to
present
the
same
interface
over
and
over
again.
You
could
like
you
know,
because
you
only
get
one
conditional
at
each
box
right.
You
could
say
this
box,
isn't
a
you
know,
kpac
image,
template
that
or
you
know
whatever
integration,
it's
another
supply
chain.
You
double
click
on
that
you
get
the
same
editor
and
you
get
to
do
the
same
thing
right
and
to
me
that
that
interface
seems
a
little.
It's
like
less
to
understand
or,
like
you
know,
less
the
the
encapsulation
there.
I
don't
know.
D
F
How
would
you
is?
You
would
still
need
to
show
the
all
of
the
options
right
like
you
could
encapsulate.
You
could
have
a
kind
of
minimized
view
of
just
what
the
overall
steps
are,
but
you
would
still
have
the
necessity
of
showing
of
having
some
way
of
showing
the
entire
graph
for
someone
to
be
able.
F
F
B
F
B
I
was
thinking
about
this
in
the
context
of
building
a
supply
chain
like
as
an
operator
for
many
workloads.
That's
what
I'm
thinking
about,
drag
and
dropping,
and
you
know
showing
designing
an
interface
for
multi-path
versus
designing
an
interface
for
you
know
snippets.
Are
you
thinking
more
about
like
just
visualizing
something
in
the
context
of
one
workload?
Can
you
help
me
understand.
F
Yeah
and
I'm
thinking
of
it
of
I'm
trying
to
understand
what
would
happen
with
a
workload
what
is
actually
going
to
happen
if
I
create
a
workload
this
way,
what's
going
to
happen,
if
I
create
a
workload
a
different
way,
you
know
what
would
actually
happen
here.
Kind
of
like
a
dry
run,
ui
that
would
show
you
what
would
happen
with
a
supply
chain.
B
F
Exactly
no,
I
don't
think
it
needs
to
change
there.
What
I
was
saying
is,
I
don't
think
that
you
get
any
more
simplicity
in
the
ui
necessarily
by
using
snippets,
though,
because
when,
if
that's
the
use
case,
the
one
that
I
was
talking
about,
we
were
just
talking
about
different
ui
use
cases.
I
think
in
the
ui
use
case
of
this.
It's
you
know
you
know.
In
the
end,
you
want
to
show
the
whole
graph,
so
the
whole
graph
is
the
same
graph
in
either
path.
G
B
So
I'm
mostly
concerned
with
like,
if
you're
going
to
build
a
ui
for
an
operator
to
be
able
to
create
a
supply
chain.
I
think
multi-path,
where
you
have
a
condition
far
up
the
graph
and
you
have
to
graphically
represent
a
builder
interface
right
where
that
can
cascade
into
multiple
inputs,
where
the
inputs
drive
subsequent
steps.
It
creates,
like
many
simultaneous
graphs
that
you
have
to
think
about
managing
at
the
same
time
and
and
kind
of
the
same.
B
H
B
B
E
So
on
that
note,
no
no,
it's
good!
It's
on
that
note
I
mean
it's
hard
just
so
I
can
kind
of
gauge
an
understanding,
because
it's
a
little
bit
difficult.
I
know
there's
it's
not
very
particularly
scientific,
so
I
know
people
aren't
on
this
call,
but
you
know
what
camp
are
we
in
at
the
moment?
Are
we
on
the
snippets
camp
or
you're
on
the
multipath
camp?
What
are
people
thinking?
Do
we
have
a
raise
of
a
hand
who
are
kind
of
leaning
towards
snippets
at
the
moment?
E
B
Yeah,
I
would
say
we
should
do
one,
and
then
we
should
get
feedback
about
it
and
then
make
the
decision
for
whether
we
can
do
the
other,
but
I
wouldn't
exclude
doing
both
right
or
like
who
knows
what,
like,
after
you
do.
One
thing:
people
use
it
all
sorts
of
ways
that
maybe
there's
a
better
option
than
both
of
these
we're.
Not
thinking
about
that.
We'll
figure
out
right.
E
G
So
then
you
can
also
upgrade
those
things
together
so
like
in
terms
of
deciding
which
one
is
better
at
the
moment.
I
don't
think
the
proposals
are
on
equal
footing
in
terms
of
like
the
ability
to
like
start
progress
on
one.
I
think
snippets
is
more
mature
in
terms
of
an
rfc,
but
that
still
might
be
true
that
the
the
multipath
thing
is
going
to
be
easier
to
implement
so
like
it,
I
don't
know
how
that
washes
out.
D
The
way
I've
been
thinking
about
it
is,
I
do
think.
The
simple
case
for
multipath
is
simpler
than
anything
related
to
snippets
and
so
to
me
it
made
the
most
sense
to
do
the
simple
thing
to
solve
the
simple
cases,
and
then
once
we
see
that
no
simple
cases
are
getting
too
complex,
that's
when
it
makes
sense
to
you
know.
I
C
If
we're
saying
we
can't
compare
these
rfcs,
because
they're
not
mutually
exclusive
and
don't
necessarily
like,
can
both
solve
the
same
problem,
but
also
both
have
like
different
other
elements
to
them
like.
What's
the
exact
problem
we're
trying
to
solve
and
like
which
one
do
we
think
solves
that
specific
problem
better,
you
know.
B
I
don't
I
don't
know
if
we're
not
aligned
on
which
problem
we
want
to
solve,
just
whether
it's
better
to
start
with
a
you
know,
it's
like
over
what
time
period
are
we
optimized
solving
a
problem?
Right,
like
I
think,
multi-path
in
the
short
term,
is
a
very
elegant
solution,
for
you
know
letting
you
you
know,
take
the
supply
chains.
B
C
B
Like
I
I
you
know,
if
the
mat
like
scott's
right,
you
have
to
imagine
some
other
logic
for
the
branching
further
down,
but
you
know
to
me
it
seems
very
elegant,
but
I
worry
about
the
long-term
implication.
I
worry
about
you
know
giving
people,
especially
if
the
only
tool
to
do
branching
once
your
supply
chains
start
getting
more
complex.
B
You
know
like
and
once
we
start
needing
to
build
ui
around
it
right
it's
going
to
get
like
you
know.
In
the
long
term,
it
may
create
more
trouble
for
us
if
that
makes
sense
and
more
trouble
for
users,
whereas
snippets
seems
like
maybe
it's
a
little
bit
less
functional
in
some
ways.
You
know,
maybe
it's
not
as
nice
a
ux
for
making
simple
branches
through
right,
but
it
seems
very
like
we'll
need
it
eventually.
It
seems
very
sustainable
right,
and
so
that's
why
I
kind
of
lean
towards
the
safer
option.
I
I
Oh
somehow,
get
some
configuration
push
it
somewhere
right
like
when
you're
just
looking
at
those,
like
maybe
true
resources
that
you're
seeing
from
like
the
main
cluster
supply
chain
and
then
sure
there
might
be
a
lot
of
branching
going
on
underneath
those
those
like
true
top
level
resources
and
like
yeah,
the
fact
that
you
can
abstract
it
in
that
way.
If,
like
look
love
it
about
snippets
like
this
idea
of
like
oh,
this
is,
if
you
could
like,
create
powershells
right
and
then
now
you're
templating.
I
It's
because
it's
much
simpler
thinking
about,
like
I
don't
know,
html
even
right
like
this
idea,
oh
create
these
powershells.
Then
you
create
this
web
page
and
you
you
can
reason
about
it
as
opposed
to.
If
you
were
to
do
everything
in
line
so
love
that.
But
if
the
only
approach
to
doing
branching
is
nasty
via
this
interaction
yeah,
then
it
also
gets
really
complicated.
I
I
really
really
like
both
from
the
team.
The
perspective
that
I
get
is
that
multipath
is
actually
easier
to
reason
about
the
edge
cases
right
now,
so
we
would
end
up
with
a
solution
that
has
actually
less
problems
like
there
are
less
unknowns,
like
unknown
unknowns
from
an
implementation
perspective,
and
the
team
could
iterate
much
quicker
than
quicker
than
snippets.
I
So,
if
I
were
to
vote,
both
was
the
only
one
I'd
go
with
what
the
team
is
pulls
me
forward,
which
is
yeah
start
with
multi-path
and
then
go
for
snippets,
even
though
personally
I
also
really
like
snippets
and
the
version
of
snippets
that
I
really
like
is
the
one
where
we
reuse
the
templates.
We
have
like
cluster
source
template
so
and
so
on,
and
then
make
use
of
like
an
extra
few
resources
and
then
yeah
you
either
use
resources
or
a
template
in
in
those
objects.
E
That
was
that
was
really
good.
That
was
really
good.
I
do
wonder
I
do
wonder
I
mean
it
can't
be
answered
now
but
like
that
was
a
really
good
good
view
there.
Sarah-
and
I
just
wonder,
is
that
something
do
you
think
you
know
presenting
that
from
the
snippets
point
of
view?
Do
you
think
more
people
might
come
on
board
with
that
approach,
or
do
you
think
that
that
is
you
know
I
mean
maybe
marty?
Can
it
can
help
answer
this?
D
So
I
to
me
that
answer
that
asks
a
different
question,
because
what
what
zero
pointed
out
right
is
that
there's
snippets
also
has
a
whole
bunch
of
proposed
syntaxes
at
the
moment,
and
he
identified
one
that
I
didn't
think
was
the
front
runner
which,
because
there's
right
now
there's
a
few
different
proposals
for
snippets.
One
is
allowing
a
whole
bunch
of
resources
to
be
nested
under
a
template
and
the
other
is
allowing
typed
supply
chains.
D
And
so
it's
it's
interesting
right
because
the
it's
not
just
the
conversation
between
multipath
and
snippets.
At
this
point,
it's
a
question
of
multipath
or
you
know,
version
a
b
or
c
or
d
or
e
of
snippets,
so
yeah,
and
I
think
that
snippets
as
a
whole
has
a
whole
bunch
of
like
open-ended
questions
around
it
that
we
haven't
resolved
as
well
and
that
all
of
the
different
options
they
all
have.
The
the
same
inherent
problems.
E
E
I
wonder
if
we
can
kind
of
continue
this
discussion,
but
there's
a
better
way.
We
can
continue.
This
discussion
find
out
what
we
need,
what
information
either
analysis
we
need
to
do
or
any
and
more
unknowns.
We
can
find
and
we'll
see
if
we
can
act
on
this,
follow
up,
maybe
with
something
we
can
chat
on
final
approach
to
do
the
same
more
asynchronously
on
slack.
Essentially,
if
people
are
up
for
that,
kubernetes
yeah
yeah,
maybe.
D
David
facility,
in
the
kubernetes
slack,
I
posted
both
the
options
and
all
of
the
gists
that
all
solve
the
exact
same
use
case.
So
far,
there
hasn't
been
any
responses:
scott
who
actually
just
dropped
off.
We
got.
We
had
a
good
discussion
there,
but
hopefully
yeah.
If
there's
other
things
that
people
want
to
add.
Please
add
it
to
the
the
slack
thread
that
I.
H
D
A
A
A
D
I
B
G
G
Yeah
this,
the
the
tl
dr
is
this
is
a
distilled
subset
of
what
was
proposed
in
rfc
18
and,
I
think,
also
rfc
14.,
where
essentially,
the
goal
here
was
just
to
take
information
that
cartographer
already
has
when
it's
processing
a
supply
chain
and
reflect
that
out
onto
the
workload
status
as
well
as
the
deliverable
status.
Anything
workload
is
equally
applicable
to
delivery.
G
So
I
guess
kind
of
what's
here
is
basically
just
a
list
of
resources
that
are
all
named
and
then
have
a
reference
to
the
actual
template.
In
this
case,
it's
almost
always
going
to
be
a
cluster
something
template
resource
as
well
as
a
stamped
resource.
So
it's
the
resource
that
the
template
is
actually
templating
and
then
also
including
the
inputs
and
outputs.
As
far
as
we
know
them,
so
the
input
is
really
just
the
name.
G
The
output
is
something
that
I
changed
a
little
bit
earlier
today,
based
off
of
feedback
from
evan
on
rfc
18,
as
well
as
just
a
general
concern
they
had.
So
it
is
basically
a
a
named
copy
of
the
output
so
basically
like
for
an
image.
It's
going
to
be
image
for
source.
It's
going
to
be
url
revision
for
config,
it's
config
and
an
earlier
version
of
this
rfc
had
a
basically
had
the
value
captured.
G
I
ended
up
backing
that
off
for
both
concerns
around
like.
Are
these
values
safe
to
actually
expose
directly
on
the
workload
just
in
case
for
some
reason
like
our
back
is
set
up
and
you
don't
want
to
expose
the
internal
implementation
details
to
a
user,
but
secondarily,
and
actually,
probably
primarily
the
if
you
have
multiple.
If
you
have
a
large
supply
chain
with
it's
producing
large
artifacts,
the
size
of
those
could
accumulate
to
be
bigger
than
the
size
of
a
kubernetes
resource
that
would
be
allowed.
G
So
you
could
end
up
just
a
mile
servicing
that
workload
just
because
there's
too
much
data
within
it,
so
instead
backed
it
off
to
be
a
digest
which
is
basically
shot
256
of
the
actual
real
value
and
then
also
capturing
the
json
path
on
the
actual
stamped
resource,
where
a
user
could
look
up
extended
resource
and
resolve
that
value
that's
themselves
and
the
last
bit.
There
is
just
having
a
timestamp
for
the
last
time
that
the
value
changed.
B
If
I'm
thinking
about
you
know,
how
would
I
visualize
that
it
wouldn't
be
dump
a
whole
bunch
of
data
for
the
really
large
you
know
values
is,
would
it
make
sense
to
introduce
some
kind
of
value
summary
or
sha
of
the
config
for
configs,
or
you
know
some
way
to
to
represent
the
artifact,
the
actual
artifact?
That's
not
the
literal
value.
G
G
B
G
A
common
thread:
it's
just
it's
not
a
matter
of
right
and
wrong.
It's
just
a
matter
of
choice.
I
was
optimizing
for
making
something
easier
for
a
user
to
potentially
consume
so
basically
having
named
resources,
I
thought
would
be
easier
for
a
user
rather
than
them
needing
to
say.
Okay,
is
this
a
config
type?
Then?
Okay,
if
it's
a
config
type,
I
do
x
versus
y.
I
realize
that
logic
has
to
exist
somewhere.
B
B
G
Oh,
it's
a
little
digestible
because
it's
like
these
values
we
accept
to
be
smaller
and
config,
is
like
the
who
knows
what
it
is
like.
It
could
literally
be
anything
like
yeah.
We
could
still
have
the
value
in
place
for
those
ones
because
we
like
they
should
be
shorter,
but
at
the
same
time
I
thought
it
was
just
worth
being
consistent
and
just
kind
of
treating
the
object
model
like
there's
one
way.
If
you
want
the
value,
then
this
is
what
you
do
every
single
time.
B
I
think
I
can
think
of
a
few
ways
to
achieve
that
consistency.
It's
like
you
could
say
that,
where
the
digest
value
for
those
types
is
just
the
digest,
but
the
digest
value
for
configs
is
the
diet
is
the
sha
of
the
config
and
then
you'd
at
least.
Have
one
field
right
or
you
could
say,
like
everything.
B
G
Probably
a
separate
rfc
where,
if
we
want
to
say
like
add
explicit
values
for
source
templates,
add
explicit
values
for
image
templates
and
I
think
we
can
sort
of
address
those
separately
like
I'm
not
opposed
to
that.
It's
just
a
matter
of
I
was
just
trying
to
do
like
one
thing
consistently
that
will
work
across
the
board
for
this
rfc.
I.
H
G
H
G
A
I
B
B
D
D
H
H
H
I
I
don't
disagree.
I
think
controlling
the
version
is
fine
too.
I
don't
see
why
we
couldn't
support
both
I
mean
most
of
our
most
of
our
crds
are,
are
referential
right
so
and
and
if
they're
not
referential
enough,
we
make
them
so
so
that
the
only
difference
is
what
the
selector
object
looks
like
on
the
two
different
versions.
H
C
I
C
I
D
B
Snippets
there
may
be
other
breaking
changes.
We
would
not
want
to
introduce
for
snippets.
That
would
suggest
a
v1
alpha
one,
and
so
we
could
roll
this
change
into
snippets
should
snippets
be
the
implementation.
I
just
I
don't
know
if
it's
worth
approving
this
rfc.
With
a
caveat
that
says
this
will
go
into
the
next.
B
H
Yeah,
my
question
is:
how
else
do
you
do
it?
It
seems
to
me
like
the
right
way
here
is
to
start
v.
One
alpha
two
put
this:
the
first
breaking
change
in
there
that's
going
to
exist
so
that
we're
better
prepared
for
other
breaking
changes.
But
how
do
you
release
that
and
say
we're
releasing
with
a
stable
api
v1
alpha,
1
and
v1
alpha
2
is
unstable.
H
B
You
know
opinions
about
first
thing
in
the
kids
ecosystem
in
this
way
than
I
do,
but
I
think
nothing
stops
you
from
creating
that
v1
alpha
2
version
and
adding
this
feature
to
it
and
telling
you
know
not
publishing
it
as
part
of
your
public
api
right
in
code.
Right,
like
nothing
stops
you
from
from.
B
H
I
know
I
think
you're
right
yeah.
I
mean
that
feels
great
to
me
because
I'd
rather
we,
I
think,
because
my
personal
obsession
with
this
one
here
is
that
it's
consistent,
it's
a
nicer
interface,
not
who
wants
to
use
it
who's
going
to
need
it.
I
don't
think
I
think
if
we
have
a
solution
for
multi-path
of
v1a1,
if
you
want
alpha
one
we're
good
to
go,
but
it
would
still
be
nice
to
have
something
consistent,
so
we
should
start
that
work
now
or
as
soon
as
we
can
with
something
that
says,
that's
acceptable.
G
They
all
need
to
be
maintained
in
the
future
until
you're
actually
ready
to
remove
support
for
a
specific
version,
but
you
also
need
to
be
able
to
upgrade
and
downgrade
these
resource
versions
to
whatever
downgrade
means,
so
that
you
can't
lose
state
as
you
round
trip
between
the
different
versions
and
if
you
define
resources,
v1
beta,
beta1,
someone
loads
it
as
v1
alpha
one
there's
a
subset
of
their
capabilities.
They
edit
that
subset
of
capabilities.
Then
it
needs
to
get
promoted
back
into
v1
beta1.
G
The
way
the
user
would
have
expected
it
to
happen
for
whatever
that
means
semantically.
So,
like
you
can
say
like.
Oh
yes,
this
is
forward
upgradeable,
but
how
you
take
this
version,
that's
proposed,
even
if
it
is
just
as
b1
alpha
2
and
then
expose
it
as
v1
alpha
1,
in
a
way
that
a
user
can
still
edit
the
label
selector
and
have
it
like
work
meaningfully
could
be
a
little
bit
complicated.
B
H
So
we
would
need
a,
we
would
need
a
field
selector
entry,
that's
what
we're
suggesting
there
right.
Nv1
alpha
one.
I
don't
know
it
seems
like
work
to
learn
how
to
do
to
be
able
to
introduce
these
sorts
of
things.
Is
there
another
driving
force
on
this
one
other
than
consistency,
assuming
everything
else
is,
is
equal.
We
come
up
with
a
multi-path
solution.
D
To
honestly,
this
is
the
most
important
thing
I
think
we
should
drive
forward
right
now,
just
because,
even
if
we
don't
do
snippets
or
multipath,
if
we
have
top
level
field
selectors
like
this,
then
you
could
even
just
achieve
like
pre-built
images
using
multiple
supply
chains.
Even
if
you
had
to
duplicate
a
whole
bunch
of
things.
B
This
only
necessitate
or
snippets
only
necessitate
top
level
field
selectors
for
configurations
where
you
need
multiple
top
level
supply
chains
right,
not
for
configurations
where
you
need
multiple
inner
supply
chains,
and
we
only
need
multiple
top
level
supply
chains
for
supply
chains
that
have
different
outputs.
Is
that
right
and
so.
B
D
B
Which
is
not
a
concept,
it
is
a
to
some
extent,
it's
a
different
feature
than
multi-pathing
and
that,
like
then,
that
is
something
that
we
haven't
implemented.
Yet
that
is,
is
not
a
direct
use
case
that
we're
talking
about
when
we
talk
about
either
the
snippets
or
the
multi-path
implementation.
Sorry
rash,
as.