►
From YouTube: Cartographer Office Hours - Jan 24th, 2022
Description
00:00 Intro
01:50 RFC process discussion
19:33 Follow up con Convention Service (RFC 0017)
40:16 RFC 009 discussion
A
A
Thank
you,
okay
and
yeah
feel
free
to
add
yourself
to
the
attendee
list,
yeah,
it's
great
how
scott
scott
andrews
does
that
using
the
ad
capabilities
on
bulldogs.
Thank
you.
Okay.
That's
great,
remember
that
the
goal
of
this
space
is
to
discuss
potentially
architecture,
changing
ideas
or
improvement,
general
improvement
ideas
for
the
project,
and
also
you
can
bring
your
questions
here
for
the
maintainers
team
to
address
right.
So
today
we
have
at
least
one
discussion
topic,
really
a
really
interesting
one,
one
that
has
at
least
one
issue
related
to
it.
A
C
B
I
wrote
in
there
you
know
see
the
notes
from
12
6,
because
we
did
have
this
conversation.
As
you
noted,
I'm
not
exactly
sure
what
was
left
unanswered
from
that
conversation,
but
it
does
seem
like
we're
still
not
in
agreement
but,
as
I
said
there
aren't
enough
maintainers
here
for
this
discussion
to
happen.
Probably.
A
A
D
Yeah
the
build
packs
one
is
actually
an
rfc
that
talks
about
what
changes
you
know
need
an
rfc
for
the
most
part,
it
also
kind
of
establishes
what
the
rfc
process
for
that
project
is.
I'd
really
recommend.
We
do
something
similar
where
we
document
you
know
either
through
the
rfc
process
itself.
This
was
like
one
of
the
earlier,
like
the
fourth
rfc
we
had
in
the
project
after
the
first
three,
we
realized
we
needed.
D
You
know
more
more
definition,
and
so
you
know
I
I'd
recommend
we
do
something
similar
where
someone
opens
an
rfc.
That
says
this
is
what
the
process
looks
like
here's.
The
final
comment
period
here
approvers
right
now,
we
don't
have
a
concept
of
who
approves
rfcs
and
I
think
that's
that's
a
gap
too,
because
I
think
it
means
they
kind
of
sit.
Sometimes
you
know
on
that
topic
of
what
kinds
of
changes
right
like.
How
do
you
describe
substantial?
This
change
is
substantial
enough
that
it
needs
more
per
view.
D
An
easy
way
to
start
is
anything
that's
user-facing,
anything
that
affects
the
user
experience
of
cartographer.
If
it's,
you
know
that
might
sound
like
a
lot
of
things,
but
an
rfc
doesn't
have
to
be
extremely
low
level.
It
can
be
a
high
level
thing
that
says
here's,
this
big
feature.
We
need
right
and
all
the
parts
of
it.
You
know
the
smaller
details,
even
if
their
user
interface
details
in
some
cases
right
could
come
out
through
the
work
or
it
could
be.
D
D
D
E
Yeah
that
makes
sense
yeah.
It
sounds
like,
then,
if
we
were
to
adopt
that,
if
there
were
a
story
in
the
project
backlog
that
was
not
marked
as
chore,
and
we
do
still
have
things
marked
as
chores
if
it,
if
we
couldn't
tie
it
to
an
rfc,
that
should
be
a
code
smell
that
we
weren't
meeting
this
process,
that's
being
proposed.
D
Yep,
I
I
think
that
that
seems
right.
Like
again,
you
know
when
you
talk
about
a
story
there,
it
almost
implies
that
the
story
comes
first
and
then
you
figure
out
an
rfc.
You
know
to
cover
it.
I
think
the
way
I
I
see
it
more
is
you
know,
a
need
is
identified
right
and
then
you
start
with
an
rfc
that
covers
hey
here's,
here's
the
big
high
level.
You
know
this
is
the
feature
we
need.
You
know
over
time.
It
gets
refined
into
something
that
covers
enough
of
the
user.
D
Experience
that
we're
comfortable,
saying
everything
else
can
be
left
up
to
the
team
working
on
it
and
then
then
it
gets
broken
down
into
github
issues
right
that
are
kind
of
more
like
the
user
stories.
On
the
other
end,
and
some
you
know,
let's
say
you
know,
here's
this
first
part,
here's
this
next
part,
here's
this
next
part
and
then
you
know
whoever's
responsible
for
different
parts
of
the
code
base
or
whatever.
However,
you
want
to
organize
it
right
folks
start
working
on
those
github
issues
and
then
eventually
the
rfc
is
complete.
E
E
E
Yeah,
I
don't
think
that
for
for
all
the
rc's
that
have
been
approved
so
far,
I
think
that
we
generally
have
just
had
a
process
where
we
were
just
like
where
we
just
had
a
conversation.
We're
like
okay,
it's
getting
approved
right,
right,
right,
right
and
then
we're
like
okay
yeah.
It's
proved.
I
assume
that
part
of
what
we
are
moving
towards
is
either
during
one
of
these
meetings
or
in
an
async
process.
We're
just
going
to
say
like
okay,
everybody
in
favor,
everybody
in
favor
put
your
hand
up.
E
D
Yeah,
so
github
has
a
like
on
a
pr.
If
you
do
your
rfcs
through
pr's,
you
can
use
github's.
You
know
like
ability
to
approve
a
pr
in
order
to
handle
that,
and
there
there's
some
nice,
like
you
can.
You
know,
create
like
a
team
alias
of
the
people
who
are
supposed
to
approve
they
get
added
automatically
when
it's
created,
and
so
they
all
get
a
you
know
request
to
approve.
F
Also,
well,
you
mentioned
one
thing
which
and
hopefully
we'll
get
to
that
situation,
but
you
mentioned
like
if
so,
some
people
disagree
and
some
people
agree
and
then
it's
kind
of
like
some
overall
decision,
hopefully
with
all
of
these
things,
so
we
can
get
to
a
general
consensus.
I
think
I
mean
I
know,
that's
doesn't
happen
always,
but
I
think
in
a
lot
of
things,
I've
seen
people
if
there's
people
have
good
reasons
to
to
say
yeah
to
decline,
something
or
then
we
should
try
hard
to
kind
of
address.
F
Those
concerns
and
understand,
have
empathy
and
then
try
and
you
know,
try
and
convert
that
into
some
kind
of
agree
and
commit
status.
I
think
I
think
it
shouldn't
be
just
I've
had
a
I've
said
a
reject
on
this
one
that
gets
overruled.
You
know
we
don't
want
to
be
having
people
feel
like
that.
I
think
that
doesn't
create
a
good
good
environment.
F
Ultimately,
you
know
things
will
happen.
Maybe
everybody
won't
always
be
on
the
page,
but
I
think
we
should
just
try
and
encourage
that
we
address
people's
concerns.
So
if
we
do
put
something
down
as
a
project,
maybe
it's
with
context
to
say
this
is
why
what
we
can
do
for
the
next
steps
to
turn
that
into
an
approval.
Potentially
that
kind
of
thing.
D
Yeah
a
lot
of
times
on
cloud
native,
build
packs,
for
example,
we'll
have
one
person
who
you
know
isn't
a
super
major
like
you
know,
wouldn't
be
a
super
majority
who
disapproves
and
other
people
aren't
willing
to
proceed
without
them.
You
know
if
they're
strongly
opposed
saying
yes,
okay,
I'm
comfortable
with
this,
it
doesn't
doesn't
have
to
be
a
legalistic
process.
D
B
E
I
mean
what
I
was
hearing
from
stephen
and
james.
Was
you
work
until
everybody
is
until
that
last
person
is
like
you
know?
I
don't
think
this
is
necessarily
the
best
way
forward,
but
I'll
I'll
put
my
I'll
put
my
john
hancock
on
it
so
that
we
can
make
forward
progress.
That
sounds
to
me
like
a
consensus
process,
not
a
majoritarian
or
democratic
process.
F
Maybe
it
needs
to
go
flicker
on
its
head.
Slightly
is,
if
you
have
a
reason
to
say
to
just
to
not
approve,
then
make
that
known
with
comments
and
try
and
get
to
that.
It's
on
you
to
get
back
to
a
good
review,
a
positive
review,
but
the
risk
is
that
if
you
put
a
negative
and
it
just
grinds
to
a
halt
and
then
that
can
be
really
that's
really
bad
for
everybody
involved.
F
E
I
don't
disagree
with
anything
that
you're
saying
there.
I
think
that
healthy
organizations
certainly
work
that
way,
but
I
I'm
also
trying
to
figure
out
like
in
our
rfc
process,
what
happens
when
that
person
says
like
yeah
when
we
get
to
the
to
the
thorny
problem
and
we
we
have
two
individuals
who
are
just
saying
like.
I
really
think
this
is
the
wrong
thing
guys,
like
I
hear
you,
I
think
we're
all
like
working
in
good
faith,
and
I
just
disagree.
D
D
B
A
A
Nope,
hey
cool.
We
had
a
couple
of
action
items
from
from
last
session.
Well,
I
don't
know
rfc
to
specify
inclusion
of
conventions
and
branch
or
new
repo
to
imbibe
convention
service
yeah.
I
don't
know,
I
believe
it's
called
andrews
who
refer
to
it.
If,
if
there
is
a
timeline
for
this
or
any
other
discussion
that
is
needed.
E
E
I
would
also
say
that,
like
I,
the
flip
side
of
that
is
that
I,
I
remain
a
little
hesitant
about
adding
convention
service
to
cartographer,
but
my
impression
of
the
group
was
that
there
was
there's
wide
agreement,
otherwise
that
bringing
it
on
would
be
something
like
that.
There
was
white
agreement,
yeah
like
let's
bring
it
on,
but
I
don't
think
there
was
agreement
to
bring
it
on
as
a
monorepo.
F
G
I
think
that
whether
or
not
a
cartographer
is
a
monorepo
is
orthogonal
to
whether
or
not
convention
service
makes
sense
within
the
umbrella
of
cartographer,
I'm
using
the
term
umbrella.
There
loosely
so
like
if
cartographer
decides
that
it's
appropriate
to
decompose
into
multiple
repos,
and
I
think
conventions
can
make
sense
as
one
of
those
repos
like
if
cartographer
otherwise
doesn't
think
it
makes
sense.
At
this
point
to
split
into
other
repos,
I
think
conventions
would
just
be
another
chunk
of
code
in
the
same
repo.
F
F
Given
this
previous
discussions
that
the
teams
can
kind
of
say
having
this
small
microservices
style,
it's
supposed
to
monoreport
style,
so
I'm
imagining,
even
if
it
doesn't
the
current
one
doesn't
spit
out
straight
away.
Maybe
there's
more
coming
soon.
That
would
adopt.
That
approach
is
that
is
that
a
fair
statement.
F
E
Yeah
my
my
impression
was
that
there's
both
the
question
of
where
does
the
code
for
the
convention
service
go
and
then,
where
does
the
code
for
the
conventions
go,
and
my
understanding
was
that
one?
It
wasn't
even
clear
that
the
conventions
that
have
currently
been
written
would
be,
but
also
that
they
that
code
can
sit
totally
separate
from
convention
service.
Oh.
G
Yeah,
just
for
that
conventions
are
not
part
of
this
proposal
other
than
like.
We
have
a
couple
samples
that
we
can
throw
in,
but
like
the
the
the
other
conventions
that
that
exist
today,
like
whether
or
not
those
go
open
source
is
like
a
separate
conversation,
and
even
if
it's
decided
that,
like
yes,
these
things
should
be
open
source
like
it's,
not
at
all
obvious
to
me
that
they
belong
in
cartographer.
E
E
G
G
E
Or
the
other
I
I
would
even
tying
that
decision,
like
tying
those
two
things
together
is
like
necessary
for,
like
how
does
this
decision
get
made?
Is
a
point
of
disagreement,
so
I
I
don't
think
that
the
status
of
runable
as
as
within
this
repo
or
not
should
affect
whether
convention
service
is
within
this
repo
or
not,
and
like
I,
I
hear
your
reasoning.
I
just
don't
agree
all
right.
That's
I
was
trying
to
convey.
B
Meaning
are
you
okay
with
us
or
with
the
maintainers,
making
the
decision
about
monorepo
or
separate,
even
if
it
contradicts
the
line
of
reasoning
that
even
if
the
rest
of
cartographer
stays
as
one
refill,
essentially
because
if
you're
not
okay
with
that,
then
it's
something
we
should
iron
out
in
the
rfc.
If
you
are
okay
with
that
and
we
can
and
the
maintainers
can
decide
where
it
goes,
then
yeah
the
rfc
can
theoretically
ignore
it.
G
There's
a
little
bit
of
question
of
like
just
whether
there's
like
just
a
temporal
drift
here
in
terms
of
like
cartographers,
moving
towards
or
moving
away
from
a
monorepo
model
and
towards
multiple
repos
like
then,
if
just
like
conventions
are
the
first,
then
like
that's
one
thing:
if
it's
like
no
like
permanently
like
the
desires
that
cryptographer
stays
is
a
monorepo,
but
conventions
is
kind
of
over
there,
then
that's
clearly
an
indication
that
conventions
are
viewed
as
something
else
and
lesser,
and
that's
where
I
think
like.
Maybe
we
don't
have
alignment.
B
G
A
So
what
if
it
all
comes
down
to
the
rfc
process
itself,
it
has
some
relationship
there.
So
if,
if
like
james
said,
probably
in
the
future,
there
will
be
more
integrations,
we
should
reach
an
agreement
at
this
point
on
how
to
handle
that
separate
repo,
monorail,
etc.
So
what
what
about?
Having
an
rfc
for
that
we're
deciding
how
to
handle,
integrations
separate
repo
monorepo,
and
we
can
have
the
conversation
the
agreement
documented
publicly
and
in
the
future.
A
E
H
Here
on
this
issue,
sorry,
can
we
just
take
a
beat
on
this
this
issue
for
a
second,
I
I'm
not
sure
I've
seen
scott
rosenberg
pop
up
a
few
times
and
scott.
I
just
want
to
welcome
you
to
our
community
meeting
and
I
just
wanted
to
give
you
an
opportunity
to
ask
questions
if
you
had
any.
I
think
you
are
our
first.
B
B
B
H
H
G
Okay,
just
overall
can,
I
just
say,
like
I
think,
the
unresolved
questions
added
more
confusion
than
clarification
like
I
think
the
rfc
stands
on
its
own
fine
without
those
I'm
going
to
drop
them.
I'm
going
to
add
a
small
note,
basically
just
saying
this
is
talking
about
the
controller
for
conventions,
not
specific
conventions,
talking
about
things
that
exist
today,
not
things
that
we
could
do
in
the
future.
H
Okay,
so
we're
going
to
say
that
we're
accepting
this
rfc
and
then
we
will
scott.
Can
we
can
we
make
this
a
separate
repo
to
start
just
because
to
me
it's
it's
not
clear
that
the
the
release
cycles
are
going
to
line
up
immediately.
So
can
we
start
as
a
separate
repo
and
then,
if
we
decide
that
we
want
to
go
down
the
path
and
like
sync
up
the
release
cycles
for
these
two
products,
then
we
can
merge
it
all
into
one.
F
It
feels
feels
to
me
this
is
the
probably
the
best
way
to
get
moving
and
and
it'll
also
help
iterate
on
that
repo
easily
more
easily
and
yeah.
So
that
sounds
good
to
me
and
I've.
If
it
helps,
I
can
help
put
together
an
rfc
to
help
start
splitting
out
parts
that
we
think
may
not
be
always
shipped
with
quite
like,
possibly
when
the
ball.
I
think
that
was
suggested.
H
F
F
Yes,
I
think
you
know
it's
been.
It's
been
quite
a
few
conversations
on
this
and
I
don't
know,
but
it's
it's
probably
would
just
be
good
to
get
code
moved
in
somewhere,
I'm
not
sure
what
the
fallout
of
of
this
other
separate
conversation
or
they
where
they
have
remained
stuck
here.
But
for
me
personally
I'd
just
like
to
see
some.
You
know
scotland
blocked
and
putting
some
code
somewhere
and
then
there's
iterating
on
that
and
you
being
use
used
as
well
getting
that
feedback
and
then
people
that
feel
strongly
about
where
things
live.
F
F
A
G
A
C
A
C
A
A
C
A
E
A
E
E
E
E
F
This
is
just
asking
a
question,
and
it's
probably
this
goes
back
to
probably
some
design
decisions
way
back
when,
but
I
just
wanted
to
ask
this
question,
so
nobody
shoot
me
if
it's
a
bad
question
was
there
a
reason
is:
has
it
been
discussed
about
having,
rather
than
using
like
a
dynamic
labeling
on
the
with
work,
those
and
things
using
some
a
git
based
approach
to
it?
So
something
like
a
marker
file
or
something
in
the
git
repository
that
helps
define
these?
F
So
you
kind
of
get
that
level
the
the
level
of
control
and
approval
over
the
what
the
supply
chain
the
selectors
are
or
is
it
you
want?
There
is
a
reason:
there's
a
design
reason
why
we
want
to
be
able
to
dynamically
one
developer.
Could
dynamically
change
a
workload,
whereas
another
developer
on
the
same
team
could
also
dynamically
change
that,
and
you
know,
you've
got
this
this
strange
and
you
know
no
traceability
of
who's.
What
developers
changing
the
workload
yeah?
What
is
is
there?
E
E
I
mean
part
of
this
could
be
coming
up
with
a
manner
to
say,
like
okay,
pull,
that
from
have
flux,
pick
up
the
state
of
that
git
repository
and
then
expose
those
like
whatever
values,
you're
mentioning
there
to
cartographer
itself
or
to
a
further
template,
and
then
the
template
could
make
some
decision,
but
the
way
cartographer
works
right
now
that
that
would
be
necessary,
because
the
controller
right
now
doesn't
know.
What's
in
that
git
repository.
D
I
think
backing
away
from
the
you
know.
Like
specific
you
know,
technology
decisions
or
interfaces
or
how
things
work
right,
like
the
goal
of
cartographer,
is
like
to
create
kubernetes
based
sort
of
dsl
for
an
operator
to
describe
an
application
platform
in
you
know
completely
kate's
native
way
right
to
say
you
know
this
is
how
this
particular
platform
processes
an
application,
and
so
the
configuration
isn't
in
the
source
code.
D
For
a
specific,
you
know
application
or
isn't
in
the
you
know,
like
workload,
definition,
first,
specific
workload
in
some
cases
right
or
it's
very
controlled
as
to
how
that
application
can
influence.
A
specific
application
can
influence
the
supply
chain
to
kind
of
keep
that
separation
of
personas.
So
you
have
kind
of
as
an
operator,
you
can
define
something:
that's
reusable
kind
of
reduce
sprawl
for
a
lot
of
developers,
which
looks
really
different
than
a
lot
of
a
lot
of
ci
cd.
You
know
single
applications.
D
F
Yeah,
it's
just
that
thing
where
just
kind
of
the
abstraction
that
we
have,
that
we
create
for
the
developer.
That
we
say
is
to
create
a
workload
that
abstraction
is
a
dynamically
created
thing
which
can
change
and
there's
no
traceability
over
that.
So,
if
you're
working
in
the
team
of
multiple
developers
on
that
microservice,
one
person
could
change
that
workload
and
the
other
person
not,
and
so
with
more
thing
complexity
be
adding
around.
F
When
we're
talking
about
these
things
and
labels
and
things
just
from
a
usability
point
of
view,
it
it
can
be
yeah
and
that
traceability,
it
can
be
a
little
bit
hard
if
you're,
offering
a
dynamic
ways
of
changing
things.
That's
really
the
way
where
my
motivation
is
going
for,
but
assuming
yeah,
I
don't
take
a
point.
You
know
it's
one
way,
and
so
how
do
you
do
it
for
others
as
well?
But
that's
where
I'm
going
for
this
is
get
more
get
things
in
configuration
in
get
to
where
they
are.
D
Maybe
if
I
tried
to
like
give
you
the
future
that
you're
looking
for
or
something
like
like,
if
you
imagine
the
workload
as
it
is
today,
but
there's
a
special
you
know
stub
workload
or
something
you
could
create.
That
says:
pull
the
workload
spec
from
this
workload.
That's
checked
into
the
git
repo
and
so.
C
D
Processing
it
you,
the
params,
instead
of
coming
from
the
workload
in
the
cluster
that
come
that
actually
looks
into
the
you
know,
get
repo
and
pulls
them
out
and
then
uses
those
params
instead,
for
example,
that's
interesting
because,
like
right
now
you
could
kind
of
achieve
that
by
having
cap
and
putting
workload
in
a
separate
repo
and
then
having
caps
sync
to
that
separate
repo.
But
you,
then
you
need
to
re-boast
right
and
that's
maybe
kind
of
a
disadvantage
for
some
workflows
see.
We
have
a
lot
of
questions
based
on
that.
I
I
I
was
just
I
was
just
gonna
check
in
with
folks.
I
think
this
is
a
really
interesting
conversation,
but
it
feels
like
a
very
different
conversation
than
what
the
rfc
is
actually
talking
about.
So
I
was
wondering
if
we
want
to
head
to
the
rc
conversation,
but
maybe
like
james.
This
might
make
sense
as
an
issue
or
something
to
write
up,
as
you
actually
like
to
support
and
maybe
something
we
can
put
on
the
agenda
and
talk
about
explicitly
because
I
don't
think
it's
actually
the
same
as
the
rfc.
F
D
I
think
it
is.
It
is
kind
of
related
in
that,
when
you're
talking
about
dynamic,
behavior,
selecting
different
parts
of
the
supply
chain,
oftentimes
you're
doing
that
because
it's
application,
specific
behavior,
and
so
it
leads
you
to
the
question
of
well.
You
know:
should
some
of
this
actually
configuration
actually,
because
if
we
want
application,
specific
behavior
shouldn't
some
of
that
come
from
the
application,
and
so
I
think
it's
it's
it's
related.
It's
just
a
you
know,
kind
of
bigger
philosophical
question
about
the
problem
itself.
If
that
makes
sense.
G
Yeah,
so
I
guess
going
back
to
the
original
question
of
the
rfc.
It
definitely
leans
strongly
towards
the
the
second
option,
where
it's
more
context,
driven
main
reason
is
that
if
you
look
at
the
first
example,
where
we're
using
a
label
selector
scroll
up
a
little
bit,
we're
basically
asking
users
to
repeat
themselves
where
they
basically
have
to
say
here's.
E
Yeah
so
I'll
say
that
it
happens
that
I
agree.
I
I
like
the
field
selectors,
the
advocates
of
label
selectors
they've
talked
to
one
of
the
points
is
that
each
platform,
each
platform
could
have
their
own
workload
inspector
or
we
could
write
a
universal
workload
inspector
that
could,
when
a
supply
chain
or
when
a
workload
is
submitted,
could
mutate
the
workload
and
add
labels
to
add
labels
to
that
workload
so
that
it's
not
the
developer.
That
needs
to
repeat
themselves.
G
H
The
one
use
case
that
I've
been
thinking
about-
that's
not
accounted
for
by
just
using
field.
Selectors
directly
is
the
case
where
we're
associating
you
have
your
tekton
pipeline,
which
is
associated
to
your
workload
through
its
own
label
matching
mechanism,
and
so
using
field
selectors
in
the
supply
chain.
You
wouldn't
be
able
to
make
the
association
to
like
these
other
related
objects,
whereas
if
you
had
some
mechanism
like
like
a
workload
inspector,
it
could
be
a
lot
more
intelligent
about
other
other
resources
that
exist
within
the
ecosystem.
E
I
I
think
you
are
completely
right
that
the
proposal
as
it
is
right
now
we
have
no
way
to
know
about
some
third
object,
that
was
of
some
certain
had
some
gbk
and
some
label.
We
could
add
it
to
here,
but
also
nothing
about.
This
proposal
precludes
having
that
inspector
that
could
handle
that
single
use
case.
E
E
E
The
behavior
of
the
supply
chain
could
truly
be
dynamic.
It
could
be
that
I
was.
I
tend
to
go
with
the
example
of.
Let's
say
you
have
a
convention
and
the
convention
annotates
a
supply
chain
or
annotates
a
deployment
in
some
sort
of
way,
and
perhaps
it
annotates
it
in
a
way
where
k-native
actually
can't
deploy
the
deploy
that
kate's
object
anymore.
It
needs
to
be
deployed
with
a
regular
deployment.
E
With
access
to
that
entire
templating
context,
that
decision
could
be
encoded
in
the
supply
chain.
If
we
did
not
have
that,
we
wouldn't
have
that
dynamic
behavior,
and
I
think
that
there
there
is
an
argument
for
not
allowing
such
dynamic
behavior,
because
it's
very
useful
to
be
able
to
tell
what's
the
path
of
this
object
going
to
be.
Just
from
the
point
that
you
like
the
moment,
the
workload
has
been
submitted
being
able
to
plot
out.
I
Yeah,
I
just
I
think,
I'm
I
just
wanted
to
sort
of
say
this
out
loud
and
see
if
it
makes
sense.
I
think
I'm
actually
after
proposing
that
james's
conversation
was
slightly
orthogonal.
I
think
I'm
making
the
connection
on
why
it's
actually
really
important
here
between
these
approaches.
I
think
there's
something
to
think
about
what
is
enabled
or
not
enabled,
if
we're
asking
the
if
we're
having
something
that
annotates
the
workload
on
a
user's
behalf.
I
Does
that
create
problems
if
we
do
want
to
have
a
get
ops
based
workflow,
where
people
are
modifying
that
workload
in
their
their
git
repository
and
we're
watching
that,
and
it
becomes
sort
of
out
of
sync
with
like
the
sort
of
magic,
annotation
thing
that
was
happening
somewhere,
where
if
we
are
pulling
stuff
contextually
out
of
the
prams,
maybe
we
dodge
that
question
entirely.
I
also
might
not
be
understanding
this
but
sort
of
saying
that
a
lot.
D
D
Is
there
an
issue
with
using
that
in
this
context,
wouldn't
that
kind
of
solve
the
problem
on
the
cluster?
The
workload
would
have
the
annotations
that
point
it
towards
a
particular
path
through
the
supply
chain
off
the
cluster.
You
know
those
annotations
aren't
there
and
their
name
space
to
be.
You
know
you
know
always
present
in
one
place
and
not
present
another
place.
F
Yeah,
I
I
think
with
annotations
they
they
I've,
always
treated
them
as
things
that
tend
to
be
added
by
things
like
like
automation,
or
you
know,
use
them
to
store
that
metadata
and
various
things,
as
you
learn
controllers,
adding
that
adding
to
them
and
whatnot
labels
less
so.
But
I
don't
know
if
that
helps.
Is
that
what
you're
saying
stephen.
D
Yeah
yeah,
like
it
seems
like
scott,
you
had
a
concern
about
using
that
and
zac
you
just
expressed
kind
of
the
same
concern
about
using
labels.
If
they're
automatically
added
you
and
you're
checking
your
workload
into
a
gear
repo,
then
they
get
out
of
sync
with
what's
on
the
cluster,
but
a
common
pattern
with
annotations,
which
we
could
also
use
in
this
case,
I
think,
or
we
could
use
instead
is-
is
to
have
web
hooks.
D
G
D
Would
decouple
the
thing
that
looks
at
the
workload
and
decides
you
know
is
the
work?
Is
this
workload
a
workload
that
takes
a
source
code
from
a
git
repository
versus
an
image,
for
example?
Or
is
this
you
know
workload,
a
workload
that
you
know
I
don't
know
needs
to
have
other
properties
that
we've
talked
about
that
we
might,
you
know,
do
have
dynamic
supply
chain
behavior
and
describe
that
in
a
concise.
D
E
E
E
So
the
supply
chain
recognizes
that
label
and
it
handles
that
use
case,
and
it
feels
like
there's
just
a
lot
of
extra
steps
in
there
where
it
could
just
be
I'm
going
to
figure
out.
What,
in
my
workload,
indicates
that
I'm
in
that
use
case
and
then
I'm
going
to
tell
my
supply
chain
look
for
that
and
handle
that
use
case.
I
Well,
I
was
just
going
to
kind
of
plus
one
what
I
think
what
schumer's
saying
in
terms
of
I
think
the
second
option
feels
more
traceable
in
that
I
can
go
directly
to
the
supply
chain
to
see
like
what
is
the
thing
that
triggered
this,
and
it
also
feels
like
something
you
can
report
up
sort
of
resources.
If
you
want
to
easier,
you
can
sort
of
say
I
hit
this
condition
versus
like
I
have
to
go.
I
Look
somewhere
else
for
this,
like
map
of,
did
I
apply
xyz
label
to
a
thing
based
on
condition,
and
then
how
did
that
match
to
like
supply
chains
over
here,
sort
of
at
least
at
first
blush
feels
like
it's.
So
maybe
a
little
easier
to
sort
of
the
logic
exists
where
it's
sort
of
resolved,
which
maybe
makes
it
feel
a
little
more
debuggable
and
understandable.
E
As
we
are
at
time,
my
my
intent
to
do
to
move
us
forward
is
to
actually
come
down
in
the
rfc
and
propose
that
we
do
the
field
selectors
and
put
that
take
this
out
of
a
draft
state
and
put
it
into
an
so
that
people
can
mark,
approve
or
disapprove,
and
I'm
not
doing
that
to
short-circuit
the
conversation.
Certainly,
if
you
have
yeah,
please
feel
free
to
to
drop
in
comments
and,
let's
all,
engage
with
those.
H
Sorry,
all
right,
as
you
say,
if
you're
doing
that,
could
you
just
come
up
with
some
like
standard
examples
of
like
field
selectors
that
we
might
see.
So
we
get
like
an
idea
of
the
extent
of
the
syntax
and
how
complicated
the
field,
selector
definition,
might
look
like
like
yeah.
If
we
need
to
match
you
know
four
different
fields
to
match
the
supply
chain
and
then,
like
a
few
other
like
and
then
like
this
field,
matches
to
this
path.