►
From YouTube: Cartographer Office Hours, June 7th, 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
A
A
Welcome
hi
nice
to
meet.
You
awesome,
welcome
all
right!
Yeah!
Let
me
show
you
my
screen
real,
quick,
okay,
yeah
I'll
put
in
the
chat
again.
A
The
link
for
the
agenda
notes
feel
free
to
drop
anything
you
like
to
discuss
here
all
right.
I
guess
I
guess
I
will
take
notes
for
today's
session
unless
you
have
an
objection
against
that.
A
Cool
all
right,
yeah,
please
look
for
your
attendance.
There
returns
intentions
list.
If
your
affiliation
is
with
vmware
you,
you
only
need
to
provide
your
name
all
right,
review
outstanding
rfcs.
So
we
have
the
general
board
here
of
all
the
rfcs,
but
we
have
a
couple
that
were
added
here
yeah.
I
just
saw
the
pr
for
this
one
like
10
minutes
ago,
so
I
think
it's
it's
fairly
new.
A
So
let
me
let
me
step
back.
Here's
the
current
list
and
the
status
of
rfcs.
We
don't
have
anything
blocked
on
plc
and
especially
we
have
a
couple
of
stuff
a
couple
of
rfc's
blocked.
I
believe
they
block
each
other.
I
I
trying
to
remember
well
so
for
for
those
who
are
in
review,
I
don't
know
if
there's
any
update
somebody,
you
would
like
to
share,
simplify
runnable
rf
series.
B
Simplify
runnable
is
still
kind
of
in
the
same
holding
pattern.
Yeah
I'll
just
leave
it
at
that.
If
you
look
over
again.
A
A
All
right
so
yeah
there
there's
there
are
10
rfcs
in
this
case,
so
yeah.
Well,
nine
of
them
accepted
some
of
them
in
progress.
So
you
have
a
good
list
of
ideas
here,
already
discussed
and
accepted
and
ready
to
be
implemented.
I
believe.
A
Okay
right,
so
we
have
the
add
match.
Parent
selector
seems
like
most
recent
change
status
was
denied.
A
B
Yeah,
I'm
I'm
happy
to
talk
to
this.
I
there
is,
I
feel,
like
I
led
the
charge
on
saying.
Oh
no,
we
don't
need
this.
We
don't
need
this
proposal
and
I'd
laid
out
really
thinking
through
our
personas
as
you've
got
your
app
operator
and
your
app
developer
and
the
app
operator
is
responsible
for
supplying
for
writing
into
the
supply
chain.
B
The
parameters
like
a
default
parameter
or
a
value
parameter,
and
I
argued
at
the
time
when,
when
this
proposal
was
created,
that
is
sufficient
like
when
you
know,
when
you
make
that
decision
you
you
then
don't
need
to
do
any
match
params,
because
you'll
know
what
the
params
are
and
you
can
essentially
like
you.
You
won't
need
to
delegate
to,
like
you
may
say,
like
I'm,
going
to
set
a
default
if
you
set
a
default.
B
Well,
you
know
what
is
going
to
happen
unless
there's
some
particular
field
in
the
workloads
params,
and
so
you
can
just
use
match
field
to
figure
out.
What's
going
on
in
the
workload,
essentially,
I
was
saying:
there's
params
are
weird
because
they
can
come
from
the
template.
They
can
come
from
the
supply
chain.
They
can
come
from
the
workload,
but
if
you're
writing
the
supply
chain,
you
will
know
whether
or
not
you're,
giving
the
permission
to
the
workload
to
alter
it.
B
And
if
you
know
like
hey,
there's
some
field
on
the
workload
that
will
matter
for
execution,
then
you'll
just
write
your
options
with
match
field,
and
and
based
on
that,
you
know,
I
think,
if
you
read
through,
everyone
is
like
yeah.
That
seems
reasonable,
okay.
Well,
this
would
be
extra
work.
Let's
not
do
that
extra
work.
B
Some
work
with
tanzania
application
platform,
which
uses
a
cartographer
to
write
supply
chains,
and
one
of
the
things
that's
become
clear
to
me-
is
there's
this
other
persona
that
we
haven't
really
been
respecting
in
our
discussions
or
certainly
and-
and
I
will
take
full
interest
like
I-
I
had
it
really
figured
out
this
this
extra
persona,
and
that
is
like
this-
the
persona
of
somebody
who's
setting
up
a
default
platform,
but
who
expects
who
expects
some
app
operator
or
some
platform
operator
to
come
in
and
tweak
it
to
their
needs,
and
this,
I
might
say
another
example,
might
be
like
maybe
you're,
heroku
and
you're,
going
to
make
a
a
modern
application
platform
using
cartographer,
you're
going
to
say,
like
hey
here
here,
are
the
default
supply
chains
and
here's?
B
What
I
think
will
make
sense,
but
if
you
want
an
enterprise
account
with
heroku,
and
you
want
to
tweak
these
supply
chains
in
certain
ways,
there
should
be
an
elegant
way
for
heroku.
B
To
say
like
here
are
my
defaults
in
an
elegant
way
for
them
like
elegant
controls
for
them
to
allow
platform
operators
to
change
those
defaults
and
right
now
we
don't
have
that
in
order
to
serve
that
sort
of
workflow,
it's
necessary
to
push
a
lot
of
logic
into
ytt
in
terms
of
both
creating
supply
chains
and
ytt
logic
in
in
templates,
which
I
think
there
are
a
number
of
folks
who
agree
with
me
that
that's
kind
of
an
anti-pattern
that
we
would.
B
Will
know
that
we've
really
succeeded
when
you
do
not
need
to
put
push
conditional
logic
into
ytt,
and
so
based
on
that,
based
on
this
expectation
that
there
will
be
a
persona,
who's
writing
a
supply
chain.
That
has
some
defaults,
but
they
don't
know
at
the
time
that
they
write
the
supply
chain.
What
the
parameters
will
be
that
are
set
in
the
supply
chain
like
at
runtime.
B
So
if
I'm,
if
you,
if
you
don't
know
that
the
the
cleanest
way
to
do
that,
switching
is
to
have
match
params.
B
So
I
put
this
out
there
out
here
to
say
it
was
denied.
I
was
definitely
I
definitely
thought
it
should
be
denied
and
now
having
yeah,
I
think
we
said
at
the
bottom.
B
Yeah,
this
should
be
with
a
note.
It
should
be.
What
is
it
what's
the
phrasing
that
we
use
should
be
repurposed,
it
should
be
brought
back
to
life
if.
B
B
So
yeah
the
it's
been,
it's
been
in
consideration.
I
just
moved
it
from
declined
to
or
denied
to
pending,
but
if
there
are
no
objections,
I'd
want
to
move
it
along
in
the
the
next
step
in
the
rfc
process.
I
forgot
what
yeah
move
that
to
in
review
since
yep
I
haven't
made
any
changes
to
this.
They
would
still
be
looking
for
the
same
comments
as
before.
C
I'm
happy
if
you
say
you
wanted
to
be
in
review
again
and
then
you
can
have
a
round
of
folks
who
have
been
absent.
Today
I
mean.
B
We
have
some
more
when
we
have,
for
example,
any
member
of
the
the
technical
oversight
committee.
A
Cool
anything
else
regarding
this
rfc
or
wise,
we'll
move
to
the
next
one
also
proposed
by
mishuma.
B
Yeah,
so
this
came
out
of
a
conversation
I
I
could
have
sworn
that
it
was
in
office
hours
and
sam,
maybe
you'll
be
able
to
help
me.
We
definitely
had
a
meeting
with
steven
and
scott
about
input,
output,
correlation
and
like
at
that
meeting
steven
was
like
yeah.
Maybe
we
should
separate
out
the
two
different
flows
that
are
currently
in
the
input
output:
rfc,
one
that
you
know
the
one
that's
doing
the
input
output
where
it's
all
in
the
status
and
then
the
other.
B
That's
doing
this,
the
the
flow
that's
more
similar
to
the
super
old
proposal.
C
Generation
thing
yeah,
yeah
right
and
I
think
the
desire
there
is
because
they're
seen
as
two
different
mechanisms
as
well
at
least
in
how
they
behave,
that
they
wanted,
at
least
for
us,
to
write
two
separate
rfcs,
so
that
we
could
make
sure
that
there's
a
good
focus
on
on
the
actual
changes
that
are
going
in
for
each
of
those.
C
A
B
Yeah
cool
this
is
so
at
the
end
of
that
conversation,
I
had
pointed
out
that,
with
input
output
correlation
one
of
the
things
that
we're
doing
is
we're
saying,
like
hey,
there's
we're
thinking,
for
example,
like
oh
kpac
will
hopefully
say
there
are
some
fields
from
our
spec,
which
are
the
inputs
that
will
mark
in
the
output
right
that
when
you
get
your
most
recent
good
image,
that
kpak
will
tag
that
with
like.
B
Oh
here's,
the
here's,
the
source
url
that
that
came
from
at
the
end
of
that
conversation,
I
was
thinking
about
it.
I
was
like
wait
like
if
I'm
the
kpac
writer
author,
if
I
handle
that
crd
for
me,
I'd,
be
like
wait.
But
why
am
I?
B
It
would
be
far
more
reasonable
for
those
individuals
to
report
an
observed
generation
on
their
output.
B
Now
this
separate
from
the
observed
generation
that
we
normally
see
at
the
top
of
the
status
in
instead
an
observed
generation,
that's
more
similar
to
the
observed
generation
in
meta,
v1
conditions
which
says
like.
If
we
look
at
metaview
on
conditions,
it
says
like
hey,
here's,
a
there's,
an
additional
observed
generation
and
that
observed
generation
is,
is
meant
to
say.
B
Here's
the
generation
that
led
to
the
current
condition
that
that
the
current
status
of
this
condition
that's
being
reported
right
now,
and
so
we
we
can
imagine
resource
authors
applying
that
same
pattern
to
outputs
and
reporting
for
each
output
or
reporting
for
their
set
of
outputs.
Here's
the
observed
generation
that
led
to
this
set
of
outputs
so
yeah.
So
this
is
I'll
admit
that
I'm
only
like
I've.
B
I've
got
the
motivation
written
into
this
rfc
so
far,
and
it's
essentially
what
I
was
just
talking
about,
but
I
have
not
there's
still
like
implementation
details
that
I
need
to
need
to
write
in,
but
the
the
intention
is
for
this
to
be
a
third,
a
third
way
you
could
specify,
because
ultimately,
whether
or
not
you
could
use
in
the
input,
outputs
correlation,
whether
you
can
use
generation,
outputs
correlation
depends
entirely
on
choices
that
are
beyond
us
choices
that
what
what
do
those
third-party
resources?
B
D
I
have
a
quick
question
on
that
with
input
output
correlation.
Could
this
also
help
with
correlation
of
inputs
resulting
in
an
error.
B
Sam
one
sam,
you
should
feel
free
to
to
take
this
one.
I
right
now
there
isn't
and
expectation
that
you
would
use
that.
B
B
There
are
four,
you
know,
four
different
definitions
of
an
object
and
one
and
two
were
good
and
then
three
and
four
were
bad
and
I
wanna
know.
B
Or
three
was
bad
and
four
is
still
spinning.
Currently
what
it
will
do
is
it
will?
Let
you
tell
like
hey,
there's
an
output
and
that
output
is
the
output
for
number
two.
B
B
Because
the
object
you
would
expect
the
object
to
be
in
a
state
of
in
an
unknown
state
since,
since
four
is
unknown,
four
is
still
spinning.
B
D
But
I
also
want
to
correlate
failure
because
that
may
help
me
trace
to
what
the
cause
of
failure
was,
what
what
thing
that
I
say
to
go,
execute,
executed
and
was
in
a
bad
status,
and
maybe
it's
not
spinning
anymore.
Maybe
it's
just
in
a
defunct
status
and
it
can't
get
past
the
defunct
status,
because
one
of
the
things
that
I
personally
have
struggled
with
is
being
able
to
triage
and
I'm
and
I'm
not
saying
cartographer-
should
help
me
triage,
but
at
a
glance
if
it
would
give
me
some
sort
of
hint
where
to
go.
D
C
C
E
C
D
B
So
I
think
that
we
could
very
likely
leverage
the
same
sort
of
syntax
for
the
end
user,
like
that.
That
seems
very
reasonable
to
me,
but
I
think
that
what
we
would
end
up
with
reporting
out
to
the
end
user
would
probably
look
very
different
because.
B
C
I'm
just
trying
to
think
about
what
diagnosis
looks
like
today
right
and
I
think
it's
still
very
early
days,
people,
but
but
it
looks
a
lot
like
you
know,
you're
looking
at
individual
stage
and
we
haven't
seen
and
that's
not
to
say
that
it's
not
going
to
come.
You
know
these
users
having
these
massive
problems
like.
Oh
I've
got
this
error
at
this
stage.
I
a
sorry
at
this
stage
c
and
I
now
need
to
trace
all
the
way
back
to
like
the
a
that
closed.
It.
B
B
Like
the
easy
case,
right
is
run
n
or
input
n
was
submitted,
the
definition
was
submitted
and
the
controller
spun
and
then
things
that
if
it
finished
and
the
output
was
good,
let's
say
like
success,
equals
true
red
equals.
True
and
then
definition
two
comes
along
and
definition
two
fails.
B
It's
like,
okay,
that
that's
easy
to
reason
about
it.
It
may
not
yet
be
easy
to
write
controller
for,
but
it's
easy
to
reason
about,
but
then
let's
say
that
you,
let's,
let's
complicate
that,
let's
say
you
submit
definition
n
and
you
submit
n
plus
one
and
then
plus
two
before
n
finishes,
and
then
you
eventually
see
so
so
one.
B
I
would
expect
that
most
one.
I
don't
think
that
there's
anything
stronger
than
convention
in
in
kubernetes
about
how
those
three
different
objects
will
be
reported
on.
I
would
expect
by
convention
that
I
would
see
that
the
conditions
would
remain
in
an
unknown
state.
B
Ready
would
be
unknown
until
that
final
definition
had
been
had
finished,
reconciling
and
it
would
either
yeah
so
and
then
it
would
either
be
in
a
good
or
a
bad
state,
and
so,
if
it's
in
a
good
state,
I
wouldn't
know
anything
about
whether
definition,
one
or
two
that
had
been
bad
and
two
if
it
was
in
an
error
state.
Similarly,
I
wouldn't
know
if
anything
about
one
or
two,
if
either
of
those
had
been
bad,
so
that
that
seems
to.
B
That's
a,
I
think
that
that's
hard,
because
I
don't
think
it's
a
cartographer
doesn't
yet
read
that
information.
That's
like
easy
to
reason
about
from
the
objects.
I
think
it's
much
more.
D
Should
it
even
know
like
it's
confusing
to
me
that
it
would
know
what
the
route
was
to
that
thing,
for
instance
like
as
an
output-
and
I
don't
know
if
that's
an
output,
that
would
be
something
that
I
would
know
about,
but
let's
say
it
did,
but
it
doesn't
know
that
it's
crashing
so
I've
seen
I've
seen
some
inconsistency
where
it
would
know
certain
things
in
these
kinds
of
situations,
but
in
other
cases
it
doesn't
know
anything
it's
just
like.
Well,
I
submitted
it
and
it
was
ready
at
some
point.
It's
fine
right.
D
D
D
Yet-
and
I've
been-
I
was
healthy
at
one
point
in
time,
and
maybe
there
is
a
revision
out
there
that
is
healthy
and
running
fine,
but
revisions,
two
through
four
are
completely
unhealthy
of
whatever
it
was
that
I
submitted
an
object
to
should
cartographer
know
that
or
is
it?
Is
it
just
happy
with
the
fact
that
hey
I
did
have
something
in
the
past
that
was
healthy
and
good
and
ready?
D
I
don't
really
care
about
the
things
that
haven't
been
ready
yet
again,
the
new
version.
I
don't
know
because,
as
when
I
hear
the
word
correlation,
that's
just
where
my
brain
starts
to
go
is
like
what
is
what
is
that
definition?
What
am
I
correlating,
I
guess,
and
how?
How
bro,
because
that
word
can
be
very
broad
and.
C
I'm
sorry
yeah,
so
it's
just
very
semantic,
so
so
small
bit
of
history
like
so
we
originally
were
tasked
with
writing
an
rfc
about
supporting
artifacts
tracing
through
through
supply
chain,
basically
being
able
to
say
that
the
output
that
you've
that's
been
produced
from
a
given
stage
is
indeed
the
output
that
was
produced
based
on
the
inputs
that
cartographer
used
to
stamp
out
that
resource
in
the
first
place
and
so
input
output,
correlations
kind
of
just
been
called
out
as
the
subtask
of
being
able
to
make
that
assumption
just
about
one
resource
in
the
supply
chain.
C
C
B
I
mean
you
can
certainly
see
so
one
thing
that's
easy
to
reason
about
is
once
you
know
that
generations,
one
through
n,
succeeded
and
then
you
have.
You
have
some
inputs
that
never
led
to
outputs.
You
can
say
like
oh
well,
something
happened
after
after
generation
n
part
of
the
challenge
that
I
was
pointing
out
is
if
you've
got,
if
you're
submitting
very
quickly
there's
undefined
behavior.
B
Or
or
behavior
we
can't
know
ahead
of
time
for
an
arbitrary
resource
how
they're
going
to
handle
submitting
like
if
I,
if
I
submit
to
if
I
submit
to
let
me
put
it
this
way.
If
I
submit
three
definitions
very
quickly
to
k-pac
three
different
definitions
of
of
the
same
object
with
pointing
to
different
commits
in
source
code,
kpack
will
build
the
first
one
and
then
it'll
see
like
oh.
I've
got
two
new
two
new
commits
and
it
will
skip
the
second
one
entirely
and
it'll
build
the
third.
B
So
at
that
point
it's
like
well,
if
one
was
good
and
three
was
bad,
I
can't
tell
if
the
problem
was
introduced
in
commit
two
or
commit
three.
Now
I
can
tell
like.
Oh,
it
obviously
happened
after
commit
one,
and
I
think
that
that
sort
of
this
does
help
us
in
saying
like
well.
At
least
we
can
say,
things
were
the
the
last
time
things
were
good
was
input,
n
and
everything
after
n
is
suspect,
but
I
don't
think
that
it
helps
us
narrow
down,
saying.
B
Oh,
there
are
a
bunch
of
candidates
after
n
and
like
I
think
that
might
be
unknowable
from
cartography
from
cartographer's
point
of
view,
but
other
than
as
you
were
kind
of
pointing
out
other
than
teaching
cartographer
a
lot
about
the
internal
operation
of
different
objects.
B
So
one
thing
that
I've
talked
to
the
james
about
is
like:
we
could
have
sidecar
objects
that
were
like.
Oh,
when
you
submit
a
kpac
image,
I'll
tell
you
what's
going
on
there
like
every
kpac
image
is
going
to
create
some
build
objects
and
those
build
objects.
They
work
in
this
way
and
like
we
could
ask,
we
could
create
a
catalog
of
such
objects
and
then
say
like
hey.
If
you
submit
this
object
to
the
cluster,
then
that
that
information
could
be
leveraged
by
a
cartographer
controller.
To
like
do
some
work.
B
But
that
that
would
be
a
very,
I
think
that
would
be
a
heavy
lift
both
for
us
in
terms
of
implementation
and
then
users
in
terms
of
creating
those
those
sidecar
objects.
E
I
wonder
if
pushu
was
something
like
I
cap
controller.
Does
this
with
different
config
changes
down
the
road
that
it
creates
config
maps
with
data
based
off
of
a
specific
version,
and
then
it
has
garbage
collection
of
those
config
maps?
I
think
that
the
status
becomes
very
difficult
when
we
have
multiple
versions
of
things,
because
you
can't
show
this
was
version
two.
This
was
version
three.
This
was
version
four,
but
if
we
stamped
out
resources
that
were
garbage
collected,
let's
say-
and
let's
say
the
default
was
five.
E
Last
revisions,
whatever
the
stamped
out
resource
got
a
config
map
that
was
created
or
whatever
with
the
data,
because
the
status
is
already
huge
right.
The
status
of
a
workload
today
is
very
big
and,
as
we
add
more
things,
you
start
to
get
to
the
maximum
size
of
an
object
in
fcd
and
you
start
to
get
to
fun
things.
E
Possibly
I
don't
know
how
close
we
are
to
that,
but
I
think
that
having
that
allows
then
traceability
of
on
the
workload
status,
we
show
the
current
status
or
what
currently
cartographer
knows
about,
but
we
can
print
out
to
config
maps
other
data,
which
allows
also
some
more
free
ways
of
throwing
error
messages
into
their
from
whatever
controller
spit
that
out
from
cap
from
kpac
cap
controller,
whatever
it
is
cap
controller.
In
the
end,
you
get
c
useful
error
message.
B
Yeah
so
that
question
of
like
how
do
we
like,
where
will
we
once
we've
figured
out
this
correlation?
B
B
B
We
can
put
it
into
the
workload
status,
which
seems
like
the
safest
but,
as
you
said,
like
the
workload
status
is
limited
to
one
megabyte
of
data
and
three
we
could
like
create
some
internal
or
external
database
to
the
cluster
and
like
give
carto
the
you
know,
creds
to
that,
and
then
we
could
just
write
whatever
we
wanted
to
that
database.
B
I
would
say
that
right
right
now,
I'm
yeah,
my
my
go-to
is
like
workload
status.
Until
until
we
like,
I
would
be
shocked
if
our
workload
status,
even
as
long
like
I'm
more
concerned
about
readability
on
the
workload
status,
which
I
think
we've
I
think
the
boat
may
have
sailed
on
then
size
limits,
because
I
think
of
a
a
megabyte
is
really
large
for
text.
B
E
I
I
definitely-
and
I
don't
see
any
other
options
really
other
than
those
and
the
only
one
that
I'm
not
a
fan
of
is
a
database
external
because
it
just
becomes
dependent
on
more
resources
or
more
things.
I
think
config
maps
are
something
that
exists,
and
you
know
if
that
can
be
used
if
it
needs
to
go
to
something
external
and
can't
be
in
the
status
right.
E
Let's
say
that
it's
not
in
the
status,
I
think
config
maps
becomes
the
next
logical
thing,
because
it's
still
in
xcd
it's
something
that
we
can
still
reason
about
within
the
kubernetes
api,
without
creating
some
external
source
with
some
other
client
to
start
querying
that
database,
and
we
can
still
use
the
kubernetes
api
for
everything,
including
the
debugging.
I
think
this
is
also
kind
of
related
to
the
rfc.
We
talked
about
it
cubecon
a
bit,
unlike
when
a
k-native
service,
let's
say,
would
be
deployed
from
cartographer.
E
How
you
get
some
data
out
of
a
something
that
was
stamped
out
from
something
that
was
stamped
out
from
cartographer,
a
cartographer
prints
out
an
app
that
deploys
a
k-native
service,
and
I
want
to
get
the
url
from
that.
Let's
say
that
came
up
in
the
world
of
deliverables
when
we
were
talking
about
that,
I
think,
but
it's
that
same
idea
of
how
do
we
get
the
chain
of
events
into
cartographer
that
I
think,
can
kind
of
correlate
between
these
two
use
cases.
One
is
for
that
for
using
within
a
supply
chain.
D
I
have
one
more
question,
so
I
I
wanted
to
say
I
agree.
Storage
is
tough.
I
was
going
to
say:
well,
maybe
if
you
didn't
want
a
database,
you
could
do
object,
storage,
but
that's
still
an
external
dependency
right
and
then
I've
seen
other
systems
use
like
a
redis,
but
that's
still
an
external
dependency
and
the
nice
thing
is
right
now
cartographer
seems
fairly
well
self-contained
to
just
utilizing
k8's
apis,
which
is
a
nice
continued
goal
because
it
eases
deployment.
D
I
guess
maybe
to
turn
this
rfc
on
its
head
a
little
bit.
Would
there
be
a
desire
for?
Is
there
other
consumers
of
that
information?
Like
some
sort
of?
I
don't
know
if
it
was
in
this
rfc,
but
there
wasn't
an
rfc
that
talked
about
like
a
visualizer,
where
you
wanted
to
be
able
to
visualize
this
information
in
some
form
or
fashion
either
through
the
kate's
cli.
D
You
know
ctl
and
then
get
the
workload.
What
scott
mentioned
or
something
more
extravagant,
like
a
user
interface,
would
that
would
those
kinds
of
interfaces
require
better
payloads
and
by
better
payloads,
maybe
more.
D
Because
what
I
want
to
have
is
a
pointer
where
it's
like
well
go!
Look
at
this
thing
over
here.
If
you
want
to
know
the
information,
I
don't
want
to
have
to
copy
all
the
information,
all
the
status
information,
I'd
rather
say
well,
I
was
looking
here
when
I
determined
this
thing
was
ready,
go,
get
more
details
from
over
here
and
kind
of
link
to
it.
D
D
D
But
if
I
come
back
in
five
minutes,
everything's
cool-
and
I
don't
know
I
I
I'm
wondering
like
if
our
if
there's
a
stakeholder
in
this
data-
is
that
primary
persona,
a
user
is
that
user
developer
is
that
user
an
operator
is
that
user,
a
user
interface,
that's
then
being
presented
to
a
user,
because
that
might
change
our
theories,
that
a
config
map
would
be
too
limiting
in
terms
of
a
storage,
location
or
not,
because
text
is
large
and
I
looked
it
up
because
big
maps,
one
meg
as
well,
so
the
status
is
can't
exceed
a
mag
config
maps
can't
exceed
a
mag,
a
meg's
quite
large.
D
C
Yeah
but
but
right
now,
we've
got
like
one
for
every
resource,
and
so
we
need
to
potentially
have
multiple
of
those
right.
If
we
want
to
try,
maybe
there's
a
successful
one,
there's
one
still
spinning
and
then
we've
got
all
the
conditions
on
those
things
also,
you
know
so
so
you
know
this
this
stuff
being
copied
up.
E
Than
a
minute
to
scroll
up,
I
don't
think
we're
getting
close
even
on
large
supply
chains.
It
takes
only
about
30
seconds
to
scroll
up
in
the
terminal
to
get
to
the
top.
So
I'd
say
it's
probably
not
close
to
a
meg
yet,
but
I
could
imagine
with
large
supply
chains
if
we
start
to
add
revisions
into
the
status
that
you
could
relatively
pretty
quickly
reach
there.
E
If
we
start
to
keep
revisions
and
some
controllers
throw
very,
very,
very,
very
large
error
messages
and
like
to
just
throw
random
text
into
there
and
it
can
get
a
bit
large
if
the
user
also
isn't
smart
with
mapping
out
what
that
error
message
is
in
the
like
conditions
of
what's
successful
or
not,
and
what
to
print
out
is
the
error
message.
D
C
The
thing
that
we're
trying
to
solve
it
could
be.
We
get
all
of
that
data
and
I
don't
know
if
let's
say
we
end
up
storing
everything
in
in
ncd,
then
what
happens
when
we
face
the
oh
yeah,
let's
go
and
do
gc,
but
then
I
don't
know,
customers
find
these
resources
and
go.
Oh
yeah
we'd
like
to
process
it
this
way
or
do
this
kind
of
like
time-based
analysis
on
it
yeah
will
we
be
digging
a
slippery
slope
for
ourselves.
B
So
one
I
sam,
I
cannot
respond
to
what
you
just
said,
because
I
was
like
trying
to
find.
I
was
trying
to
find
a
document
and
I
can't
listen
and
do
other
things,
I'm
terrible
at
it.
So
my
apologies,
but
I
did
want
to
point
out
kind
of
two
things
from
what
brian
had
been
saying
before.
B
One,
I
think,
a
lot
of
the
questions
that
we've
been
talking
about
revolve
around.
What's
so
far,
I
think
the
the
farthest
we've
gotten
in
terms
of
like
writing
down
an
approach
is
this
pull
request.
Pr
519,
that
was
workload
reports
artifact
providence-
and
this
is
this-
is
written.
Assuming
that
the
the
that
the
problem
of
you
know
I
submitted
some
output,
I
submitted
some
input
to
an
object.
I
submitted
an
object
definition.
B
I
got
back
some
object
status
and,
like
I
know
that
these
two
connect,
assuming
that
problem
has
been
solved.
This
is
the
farthest.
I
think,
we've
gotten
in
terms
of
writing
down
an
approach
to
then
cache
that
somewhere.
So
take
a
look
it
I
wrote
at
the
beginning
of
the
year.
I
honestly
couldn't
tell
you
right
off
the
top
of
my
head,
exactly
what
it
says
without
skimming
it
the
and
then
brian
you
you
were
asking
about.
B
Do
we
have
a
hypothesis
of
you
know
who
or
what
is
going
to
consume
this?
I
think
the
answer
to
that
is
yes
in
my
head,
I'm
thinking
primarily
about
developers
who
are
going
to
create
a
ui
around
whatever.
B
Whatever
two
solutions,
whatever
solutions
we
come
up
with
here,
so
you
know
primarily
I'm
thinking
somebody's
going
to
create
an
app
platform
using
cartographer
and
then
that
app
platform
they'll
create
a
ui
that
will
visualize
hey
like
like
you
had
commit
xyz
click
here
and
you
can
see
which
steps
commit
xyz
reached.
B
I
think
that
yeah,
though
they'll
certainly
be
more
about
this
rc
because,
as
I
said,
it's
like
half
written
so
there'll
be
details
that
could
be
hashed.
D
Actually
that
that
that
line
you
had
right
there
from
evan
is
kind
of
what
I
was
referencing.
I
have
not
actually
gone
through
this
whole
rfc,
yet
I'm
catching
up,
but
he
made
a
comment
about
ref
like
a
reference
of
some
sort.
So,
instead
of
copying
everything
over
referencing
a
revision,
but
not
all
do
all
well,
okay,
I
don't
believe
all
crds
that
we
could
be
submitting
things
to
would
have
revisions,
though
right.
B
So
every
every
object
in
kubernetes
has
a
generation,
but
if
the
status
may
not
report
an
observed
generation
and
that
when
you
report
an
observed
generation,
it's
like
wonky
like
you
could
just
be
reporting
like
like
kpac
reports
and
observe
generation
n,
and
then
it
reports
like
a
latest
good
image
and
that
latest
good
image
is
of
either
n
or
some
generation
prior
to
n.
So
it's
a
little
wonky
that
makes
sense.
E
E
There's
no
way
for
you
to
then
debug,
necessarily
what
that
resource
look
like,
which
is
why
it
looks
like
here,
it's
being
added
in
almost
as
the
yaml
of
that
object,
or
at
least
the
gvk
in
certain
cases
is
being
added
in
here,
because
there's
no
way
of
knowing
what
that
actually
looked
like
in
generation.
Two.
If
I'm
on
generation,
four
right
now.
B
A
D
In
the
perfect
world,
you'd
have
to
also
know,
when
you
say
pick
an
opaque
identifier
to
that
point.
Like
you've
all
said
like
it's
not
gonna
be
you're
gonna
be
safer
because
of
the
limitations
of
all
the
all
of
the
crds.
You
just
talked
about
k-pac
cap
and
I'll,
throw
even
k
native
in
there,
but
it
can't
the
cap
is
what
normally
interfaces
with
it.
In
some
cases
that
I've
seen
they,
don't
they
don't
all
work
the
same,
so
you
have
to
copy
everything.
B
Yeah
and
for
for
many
of
our
objects,
that's
not
a
problem,
but
for
the
objects
that
are
passing.
Kate's
configuration,
that's
huge
like
sources,
it's
like.
Oh,
we.
We
just
need
to
copy
a
url
and
a
revision
easy-peasy,
but
like
image,
we
just
have
to
copy
some
uri
of
an
image,
easy
bam.
The
the
configuration
the
case
config
gets
huge.
E
B
Become
very
long:
well,
that's
a
long
definition,
but
I
would.
I
would
argue
that
we
don't
that
what
needs
to
be
cached
is
really
only
the
output
of
whatever
that
task
run
is
okay,.
E
B
Yeah,
maybe
arbitrarily
large,
but
that
that
was
why
I
think
in
in
here
we
there
was
something
about
where
we
said
that
we
were
going
to
truncate
some
fields
I
might
be
like
is
that
I
would
need
to.
I
can't
discuss
that
rfc
very
well,
because
I've
not
read
it
recently,
but
also
we're
255..
I
don't
know
if
there
was
anything
else.
A
A
Get
a
drink
of
water
and
take
a
break
before
they
go
to
it.
Yeah
yeah
so
reminder
to
everyone
here
to
add
your
comments
to
the
rfc
to
the
pr.
So
everyone
out
there
can
add
the
conversation
to
the
discussion
right.