►
From YouTube: Cartographer Office Hours, Feb 28th, 2022
Description
00:00 Intro
Proposals to move the following RFCs to Final Comment Period:
02:05 More option selectors
10:24 Add matchFields and matchLabels to top level blueprints
33:36 Remove workload prefix
35:55 Resource tracing
A
Remember
that
the
goal
of
this
session
is
to
basically
do
you
know,
open
a
space
to
discuss
and
move
ideas
to
keep
improving
the
project,
ideas
in
the
form
of
rfcs
and
also
to
bring
questions
that
you
may
have
for
the
maintainers
team,
so
delete
me
share
my
screen
and
yeah
in
the
chat.
I
I
shared
the
now.
I
will
do
it
in
the
notes.
Also
the
links
for
the
rfc
board,
where
we're
trying
to
to
have
a
single
way
to
visualize
the
status
of
the
rfc.
A
E
D
D
F
G
F
At
the
top
of
the,
if
you
roll
to
the
top,
I
just
check
with
says
projects
in
a
review
that
will
move
into
under
projects
is
where
you
would
look
to
know
what
status
it
has.
Otherwise
we're
adding
two
labels
for
one
thing:
sorry
back
where
you
were
david,
when
you
were
looking
at
that
yeah
see
here
under
project
rfc,
it's
an
rsc!
F
A
I
F
G
More
natural,
but
if
no
one
else
wants
it,
I
don't
need
it.
I
just
thought
it
might
be
helpful
to
have
a
label
on
it
to
make
it
explicit,
like
I
don't
think
people
naturally
look
to
the
project
to
figure
things
like
that
out
unless
you're
on
the
internal
team
and
know
to
look
at
the
project
board,
but
if
no
one
else
wants
it,
I
don't.
F
E
F
G
G
C
G
C
J
B
J
J
I
think
if
we
have
a
process
that
kind
of
forces
everybody
to
synchronously
do
something
right,
it
might
be
better
to
work
it
in
a
direction
that
allows
you
know
things
to
pass
once
once
a
threshold
of
asynchronous
things
happen.
If
that
makes
sense
so
that
we
can,
you
know,
like
we,
don't
have
to
kind
of
rally
the
vote
or
get
everybody
together
at
one
point
tell
them
go,
you
know,
put
your
vote
on
something
sorry
rash.
F
A
F
B
C
C
G
F
F
I
I
just
want
to
double
check.
This
is
the
story
that
we
are
trying
to
push
into
fly
already
right
yeah.
So
so
this
one
is
up
there
a
lot
of
agreement
on
this
one.
So
far,
although
we
have
not
got
anything
from
steering,
we
spoke
with
scott
today
to
get
clarification.
Stephen
approved
it.
Oh,
I
didn't
see
that
I'm
sorry,
we
do
have
some
things
to
talk
about
as
a
team
about
our
version
management,
because
it's
a
breaking
change
and
what
that
means.
F
This
is
the
same
as
what
scott
mentioned
last
week,
so
I
think,
as
a
team
we
can
handle
that,
but
I
just
I'll
mention
that
it'll
at
least
be
in
scp.
So
if
we
find
that
it's
something
we
say,
no,
we
can't
do
this.
We
can
say
it
today
and
make
that
decision,
and
that's
already
in
how
did
that
end
up
in
final
climate
period.
It
wasn't
there
earlier
was
it.
I
guess
it
was
so
that
one's
in
a
good
position
unless
anyone
wants
to
pull
it
back.
K
K
F
If
you
have
v1
alpha
2
on
a
cluster
and
it's
got
selector
match
fields
and
match
labels
and
match
expressions,
then
someone
should
be
able
to
request
it
as
a
v1
alpha
1
resource,
which
means
there
needs
to
be
fields
and
it
needs
to
be
complete.
So
the
when
is
pushed
back.
You
don't
lose
those.
So
there
needs
to
be
strangely
named
fields
like
maybe
match
fields
select
a
field
selector
at
the
top
level
right.
F
G
B
B
B
F
D
F
I
think
we'd
give
it
a
good,
healthy
name:
matt,
select,
field
selector
or
whatever
we're
going
to
call
it
right
and
and
core
label
selector.
If
we're
going
to
rename
the
we're
going
to
add
the
we're
going
to
change
the
base,
selector
behavior
as
well,
so
that
there's
a
way
to
express
match
expressions.
F
C
F
J
So
so
the
the
underlying
implementation
behind
this
is
that
this
this
version
that's
stored
in
xcd,
could
be
any
of
these
right.
There's
no
special
underlying
storage
version,
and
so
the
kubernetes
has
to
be
able
to
retrieve
right
any
one
of
these
versions
and
display
them
as
say.
The
latest
version
right,
and
so
the
best
practice
is
to
create
a
reasonable
interface
for
all
of
the
versions
and
just
migrate.
C
B
F
F
F
D
D
You're
good,
I
think
the
biggest
thing
to
keep
in
mind
with
conversion
web
books
is
effectively
where
they
are.
Their
best
is
renaming
fields,
not
adding
new
fields,
not
removing
old
fields,
just
used
to
be
called
foo.
Now
it's
called
bar
and
you
can
sort
of
constantly
go
back
and
forth
and
like
oh,
this
bar
is
now
foo.
Foo
is
now
bar.
It's
perfectly
round.
Trippable.
F
So
you're
saying
when
we
cut
this
into
a
v2,
we
will
have
an
interface
that
no
as
soon
as
it's
in
in
the
next
release,
which
is
why
we're
trying
to
move
this
one
along
because
we
do
need
it
as
soon
as
it's
in
the
next
release.
V2
is
now
one
that
we
cannot
also
have
renames
in.
We
can
only
have
additive
changes,
which
is
means
that
we
don't
we
we're
pushing
ourselves
towards
v3,
v4
v5
and
that's
not
good
either,
and
I
think
you're
right.
L
Mean
I
think
what
what'll
end
up
happening,
though,
is
that
the
conversion
we're
hook
needs
to
interconvert
between
all
these
different
versions
until
we
actually
get
to
deprecate
them.
So
you
know
if
we
end
up
with
like
v1
alpha
8
through
1,
all
being
things
that
we
support
doesn't
feel
like
it's
going
to
be
fun.
Yeah.
D
So
it's
not
just
a
matter
of
whether
the
number
is
large.
It's
a
matter
of
how
many
different
concurrent
versions
of
the
api
you're
supporting
and
when
a
user
is
trying
to
seek
support,
what
version
of
the
resource
that
they're
finding
and
if
they
copy
and
paste,
and
it's
not
quite
the
right
for
that
version,
then
they're
going
to
have
weird
errors.
D
So
having
a
high
number
of
versions
is
not
good
from
a
user's
perspective,
even
though,
like
the
high
version
number
is
like
not
a
problem
in
its
own
right,
but
the
user
experience
of
having
10
versions
of
an
api
and
then
the
user
having
to
know
what
version
they
actually
need
to
use.
That's
not
good.
C
F
F
E
F
F
F
Right
yeah,
so
so
the
question
again
stands.
I
think
at
the
moment,
because
we
do
need
to
move
this
forward.
Otherwise
I
wouldn't
be
hovering
on
this,
but
I
know
that
this
is
a
priority
for
our
next
release,
so
the
question
remains:
shall
we
just
use
a
couple
of
less
than
satisfactory
fields
that
we
know
we
will
then
clean
up
and
we
can
even
put
in
the
docs
alpha
two
is
coming
and
that
will
when
alpha
2
comes
we'll
have
a
better
interface
for
this.
F
J
One
thing
to
think
about
is
deprecating.
Your
your
storage
version
is
much
harder
than
deprecating
things
in
the
middle
right.
It
could
affect
our
deprecation
windows.
It's
like,
if
you
know
right
now,
we've
shipped
something
that
has
the
storage
version
of
the
first
api
right.
We
can
keep
that
and
keep
rolling
forward
right
at
some
point.
If
we
wanted
to
deprecate
v1
alpha
2,
that's
actually
easier
than
deprecating
b1
alpha
one.
F
J
J
D
J
J
D
D
F
That
means
that
this
part
is
definitely
done
sooner
without
conversions,
we
can
we.
We
are
fast
approaching
the
next,
the
next
iteration
for
this
team,
and
during
that
design
iteration
we
can
quickly
identify
whether
there's
going
to
be
any
other
likely
breaking
changes
and,
and
then
say
that's
what
we're
going
to
wait
for
or
if
we
don't
see
any
say
that
actually
well
with
this
iteration,
we
will
create
that
new
version.
L
F
F
C
C
J
D
J
So
the
there's
nothing
wrong
with
the
schema
proposed
for
v1
alpha
2
in
this
rfc.
That's
just
missing
the
schema
for
v1,
alpha,
1.
right
and
so
we're
deciding
that
we,
instead
of
following
up
with
another
rfc,
so
that
it's
we
can
implement
it.
We
want
to
hold
this
rfc
until
we
get
that
information
in
there
is
that
right.
J
F
F
Anyone
need
more
time
before
I
ask
that
question.
Are
we
all
aware
of
what's
going
on
all
good
okay?
So
I'm
going
to
move
this
into
scp
fcp,
I
don't
know,
I'm
copying
things
over
ssl
now,
okay
and
there
is
there's
not
a
lot
of
the
maintainer
team,
at
least
there's
a
couple
missing.
So
if
you
all
could
review
it,
let
us
know
what
you
think
positive
or
negative.
F
F
B
F
F
Well
before
we
get
to
that,
I
just
want
to
very
quickly
look
at
the
rfc
board
show
that
one
of
the
things
that's
sort
of
missing
when
we
move
these
things
across
the
board
is
any
kind
of
sense
of
when
that
happened,
without
looking
at
each
one
individually.
So
it'd
be
be
nice.
If
any
time
you
do
change
the
status
of
an
rfc.
F
F
In
review
to
rfcs
to
accept
it
in
rfcs,
so
I
move
this
one,
which
is
the
supply
chain
selection
with
traits,
which
is
the
options
that's
actually
already
implemented
on,
but
mainline.
I
believe
it
was
accepted
before
the
the
new
rsc
process.
I
just
thought
we'd
be
verbose
about
the
fact
that
this
thing
has
been
treated
as
accepted.
F
F
Right,
yeah,
it's
just
just.
If
we
go
to
move
these,
we
should
make
sure
that
they
come
up
at
the
meeting
just
so
that
everyone
knows
it's
happened.
This
one
was
like
pre-accepted.
I
hope
everyone
is
comfortable
with
that.
I
guess
I
would
draw
everyone's
attention
to
it
and
to
say
it
is
already
being
implemented.
So
if
you
have
any
concerns,
you
need
to
raise
them
really
soon
because
they
will
be
in
the
next
cut.
F
F
F
F
B
So
we've
settled
on
most
of
this
rfc
right.
I
think
we
all
agree
on
everything.
The
outputs
we've
the
latest
is
that
we've
talked
that
the
outputs
will
have
a
digest
and
last
transition
time
and
I'm
pushing
for
the
preview
field
that
stephen
mentioned
and
marty
sorry
marty
originally
just
to
give
a
bit
of
a
hint
at
the
value,
that's
underlying
in
that
output
and
scott.
I
know
you
originally
had
concerns
about
the
length
of
that
field,
as
well
as
the
sensitivity
of
the
contents
of
that
field.
B
D
D
F
When
you're,
when
you're
sharing,
I
have
no
idea
how
to
do
it.
My
my
question
or
my
concern
is
that
thing
about
it
being
like
a
product
decision.
I
think
also.
It
also
impacts
what
or
how
we
document,
and
it's
just
something
I
want
to
be
clear
about
like.
Obviously,
if
you
can
see
the
workload
you
can
see
some
of
the
sensitive
information,
it
may
be
something
created
by
a
resource
that
an
opera
dev
operator
doesn't
want
you
to
see.
D
Later
that
there
was
also
a
suggestion
previously
about
introducing
a
flag
so
that
someone
an
operator
could
basically
turn
off
that
behavior
globally.
If
this,
if
that
was
a
concern
of
theirs,
this
rfc
doesn't
address
that
problem,
but
like
it's
sort
of
like
something
that
could
be
done
in
the
future,.
B
It
it
definitely
like.
I
totally
agree
that
it
is
a
product
question
to
a
certain
degree,
scott
too,
but
the
way
I've
always
looked
at
it
is
like
the
the
workload
should
probably
like.
I
see
it
as
a
thing
that
does
its
best
to
summarize
all
the
information
from
all
of
its
underlying
resources
right
and
because
they
live.
You
know
in
the
same
name
space,
because
a
lot
of
assumptions
are
around
the
fact
that
you
know
if
you
have
access
to
one.
B
G
D
F
G
G
F
F
F
I
feel
like
it
should
be
a
design
goal,
and
I
don't
know
what
the
design
goal
exactly
is
that
we're
trying
to
create,
and
I
and
I'm
fine
with
it
just
being
developers
can't
tamper
with
workloads,
there's
a
way
that
an
operator
can
configure
our
back
such
that
a
developer
cannot
tamper
with
a
workload
with
a
with
the
final
output
and
that
being
the
line.
But
we
just
haven't
ever
drawn
that
it
would
be
nice
to
have
that
written
as
like
a
stance
or
a
high
level
goal
for
the
project.
F
C
F
J
I
think
this
is
this
is
maybe
a
more
complex
there's
like
a
larger
question
about
the
security
model
here,
because
they're
like
it's
not
just
whether
the
developer
can
create
a
workload.
It's
also
like.
Can
the
app
developer
create
pods
in
the
same
name
space?
Can
those
pods
read
the
same
service
account
that
you
know
is
used
by
cartographer
to
create
those
resources
right
like?
J
I
think
we
have
to
think
more
comprehensively
about
all
of
the
actions
that
we
expect
the
developer
to
do
you
know
in
that
namespace
to
be
able
to
make
a
call
on
what
different
security
models
we
support
right
and
right,
and
I
I
think
the
answer
may
be
that
there
are
different
users
are
going
to
want
different.
You
know
security
set
up,
some
are
going
to
want.
J
You
know
a
service
account
that
you
know
works
across
all
name
spaces
and
controls
everything,
but
has
maybe
worse,
you
know
security
boundary
across
tenants
right
or
some
might
want
individual
service
accounts
for
stamping
out.
You
know
things
because
they're
coming
from
workloads
that
you
have
data
coming
from
workloads
in
each
namespace,
and
you
want
to
isolate
right.
You
want
to
use
one
surface
account
that
could
write
across
namespaces,
but
maybe
more
okay
with
developers
having
access
to
that
service
account
right
that
can
stamp
out
those
resources.
B
All
right
absence
of
that.
I
think,
in
the
absence
of
that,
I
think
we
should
err
on
the
side
of
the
workload
being
as
helpful
as
possible
right
because
at
the
end
like
because
all
those
things
like
removed
right,
you
could
always
just
not
give
developers
access
to
your
kubernetes
cluster
at
all
right.
You
know
get
them
to
check
a
workload
into
some
git
repository
and
then
have
an
operator
like
apply
it
through
git,
ops
or
something
right,
and
so
in
theory
right.
The
developer
doesn't
need
access
to
any
of
this
stuff.
B
So
the
workload
should
be
as
helpful
as
possible
to
enable
those
other
workflows
where
the
developers
do
have
access
and
are
granted
permission
to
this
stuff
because
down
the
road
right
where
we
probably
want
to
do
something
like
expose
resource
statuses
as
well
in
the
workload
and
that
could
also
contain
potentially
sensitive
information
right
and
so
we
have
to.
We
have
to
really
tow
the
line
between
helpful
and
hurtful,
but
I
think
because
we
have
a
fallback
of
not
giving
developer
access
at
all.
I
think
we
can
be
as
helpful
as
possible.
H
Yeah
I
just
tried
this
is
a
great
conversation.
I'm
trying
to
like
put
a
framework
start
thinking
of
a
framework
we
can
use
to
sort
of
think
think
through
these
right,
and
I
think
our
original
goal
with
surfacing
this
stuff
on
workload,
is
to
allow
workload
creators
developers
to
understand,
given
the
current
state
of
my
my
workload.
What
is
the
current
state
of
what's
happening
within
the
system
right,
and
so
I
think
from
it.
H
From
that
perspective,
there's
parts
of
this
that
are
the
cartographer
system
and
those
are
these
interfaces
kind
of
in
between
these
components.
Cartographer
creates
a
bunch
of
underlying
resources
for
you,
the
whole
content
of
those
resources
might
be
really
unique
to
that
and
worth
hiding
in
some
way.
But
the
interface
is
that
I
have
these
sorts
of
outputs
that
help
you
traverse
the
supply
chain.
So
in
that
sense
we're
like
really
just
servicing
cartographer
parts
and
so
thinking
of
that
as
sort
of
a
clean
interface.
F
So
if
we,
if
we
take
that
to
be
the
case,
then
we're
fine
with
read-only
information
appearing
there.
So
what
we
need
is
to
decide
what
we're
going
to
show
and
how
we're
going
to
show
it
is
that
correct
is
about
digesting
or
just
truncating
or
truncating
and
digesting,
or
is
there
more
on
the
table
here?
C
C
H
M
B
M
Say
the
vast
majority
of
it.
That
would
be
the
case
there,
I'm
using
also.
There
is
a
lot
there
that
gets
stamped
out
because
I'm
doing
inline
also
for
some
tasks
and
then
it's
creating
tasks.
Basically
task
runs
that
are
very
long
for
some
of
the
source
testing
with
inline
pipelines
so
that
I
don't
need
to
actually
create
the
tasks
manually
in
advance.
So
that
also
takes
a
lot
of
the
ammo.
B
Task,
sorry,
I
are:
are
we
talking
about
the
all
the
yaml
from
all
the
templates
being
33
000
lines,
or
is
this
the
or
is
this
the
output
of
one
config?
That's
33
000
lines
of
all
okay
and
is
so
basically
what
we're
talking
about
right
is
putting
the
output
of
a
config
template
in
the
workload
status.
Is
there
any
config
template
that
you're
using
that
produces
an
unusually
like
a
giant
yaml
block
that
would
destroy
the
workload
status
if
we
put
it
in
there.
M
I
don't
think
there
would
be
for
a
config,
I
think
there
very
likely
will
be
for
customers
at
source,
because
customers
are
going
to
want
to
not
create
in
advance
necessarily
the
task
and
have
an
inline
task
run
and
if
you
take
the
entire
source
template
and
put
it
there.
The
answer
is
that
is
very
likely
with
the
tecton
task
to
happen.
G
M
F
M
Yeah,
if
they
trying
to
a
ghetto
yaml
and
then
try
and
oh
yeah,
I'm
just
gonna
make
a
few
changes
to
this.
That
I
can
reapply
something
and
then
they
end
up
deleting
4
000
lines
of
stuff
at
the
bottom.
That's
why
I
use
cube
ctl
plugins
for
exporter
that
just
deletes
the
status
when
I
do
a
get
oh
yeml
and
never
do
an
oh
yeah
but
yeah.
M
I
I
think
that
it
would
be
fine,
I'm
not
sure
I
go
back
and
forth
because
having
it
from
a
visibility,
perspective
would
be
great
in
many
cases,
but
it
could
get
overwhelming,
especially
if,
like
you're,
not
playing
k
native,
if
you're,
deploying,
if
you're
confident
if
your
configs
are
creating
a
let's
say,
an
hpa,
a
deployment
in
ingress,
a
persistent
volume,
a
deployment
and
all
of
the
objects.
Let's
say
that
go
into
a
k
native
service.