►
From YouTube: Cartographer Office Hours, June 14th, 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
Right
welcome
everyone
to
cryptographer
and
office
hours.
We're
glad
that
you're
here
for
watching
the
recording,
remember
the
goal
of
this
space
faces
mainly
to
discuss
rfts
and
any
other
idea.
You
may
have
to
keep
improving
the
project
for
today's
session.
I
guess
that
I
can
take
notes.
A
It
will
be
leave
it
well,
okay
and
I'm
glad
to
see
new
faces.
Mr
thomas
vitaly
welcome
thomas.
B
A
Oh
all,
right
great
again,
I
will
I
will
share
the
link
for
the
notes
and
agenda.
Oh
no,
that's
not
the
correct
one
here
in
the
chat.
This
is
the
one
so
feel
free
to
have
your.
A
Yeah
sorry,
this
thing
moved
in
with
newt
sorry,
so
yeah,
if
your
affiliation
with
vmware,
you
just
need
to
add
your
name
if
from
other
organizations,
just
add
your
order
there
to
the
affiliation
list-
okay,
great
cool,
so
we
could
start
by
reviewing
our
standard
rfcs,
but
it
seems
like
there's
a
priori
rfc.
The
goal
of
this
table
here
is
that
you
may
insert
here
rfc
that
that
didn't
consider
priority
to
be
discussed
first,
because
we
have
a
board
with
with
all
the
rfcs
with
the
corresponding
status.
A
C
Well,
I
just
was
wondering
if
I
have
a
really
quick
question
to
put
to
everyone
if
washroom
is
still
wanting
for
waiting
for
another
person
to
join
before
he
starts.
C
B
C
If
that's,
okay
with
you
david,
it's
just
a
quick
one,
just
to
sort
of
share
out,
I've
started
on
an
rsc,
the
rfc
yeah.
So
it's
it's
a
really
rough
draft.
It's
not
worth
sharing
at
the
moment,
but
the
idea
is
that
we
constrain
all
outputs
so
that
whenever
you
take
inputs
into
a
resource
that
they
are
constrained,
they
are
related
to
the
same
generation
of
those
as
outputs
elsewhere.
C
So,
for
example,
if
source
generates
an
image
and
then
at
the
end
you
decide
you
want
to
spit
out
the
source
reference
and
the
image
in
your
config,
it
would
be,
it
would
be
the
source
that
actually
caused
that
image.
It
couldn't
possibly
be
some
other
and
that's
how
people
tend
to
use
tend
to
use
cartographer
when
they
do
take
more
than
one
input,
and
we
thought
it
probably
could
just
be
implied
that
behavior
no
need
to.
C
We
don't
think,
there's
any
special
cases
where
people
will
want
to
create
a
graph
where
two
inputs
to
a
node
are
unconstrained,
that
they
could
be
different,
random
variables
from
elsewhere.
This
would
be
normal
in
orchestration
to
allow
that
sort
of
thing,
but
I
don't
see
any
reason
to
do
it
in
choreography,
so
I
just
wanted
anyone
who
thought
I
was
wrong
about
that
to.
C
Let
me
know
all
right
before
I
get
started
on
the
rsc,
I'm
going
to
write
it
anyway,
because
I
want
it
and
I
think
the
implementation
works
either
way,
but
it
feels
like
if
we
could
just
imply
that
all
inputs
are
constrained.
That
would
be
awesome,
be
the
best
experience
for
everyone.
That
was
wishim's
suggestion
and
I
think
he's
right
with
that
one.
F
C
Much
time
describing
it,
but
I
will
come
up
with
something
soon.
D
D
C
D
Yeah,
I
think,
just
if
I'm
not
going
to
dive
into
all
the.
D
We
see
a
lot
of
we've
seen
folks
and
we
definitely
think
there
are
use
cases
where
this
last
step.
The
get
writer
is
going
to
want
to
do
something
like
say,
like
hey:
here's,
the
shaw
that
this
config
that
I'm
referencing
is
talking
about,
but
there's
no
right
now,
there's
no
way
for
it
to
reliably
have
that
information
and
what
we've
already
seen
people
do
is
say
like.
D
Oh
well,
the
shot
comes
off
of
the
source
provider,
I'll
just
grab
the
value
from
the
source
provider,
but
that
this
value
may
have
changed
between
providing
a
value
to
the
image
builder
and
that
like
propagating
down
to
the
get
writer,
and
so
we
need
some
way
yeah.
We
we
need
to
be
able
to
tell
each
resource
like
hey
what
you
are,
what
you're
working
on
right
now,
it's
like
based
on
this
config,
but
also
on
like
a
certain
image
and
a
certain
value.
C
C
And
so
demonstrably
this
is
what
it
generally
looks
like
when
people
try
to
do
this
and
what
what
I'm
suggesting
is
that
down
the
bottom
of
this
of
this
supply
chain.
Definition,
where
you
see
the
config
that
source
is
just
assumed,
can
only
be
the
same
source
that
entered
into
that
config
provider,
they're
they're
codependent,
and
that's
what
we
mean
by
constrained.
We're
just
saying
do
with
that
by
default,
so
there's
no
reason
actually
for
them
to
ever
be.
C
Did
anyone
would
ever
really
want
to
say?
Oh,
I
want
a
source
that
is
a
totally
unrelated
source
right.
You
can
make
one,
but
you
just
wouldn't
also
make
it
an
input
to
an
image
builder
right,
and
then
that
could
be
your
unconstrained
one.
It's
unconstrained
by
by
not
being
involved
in
the
rest
of
the
past.
C
D
E
D
Yeah,
okay,
I
think
I'm
also
going
to.
A
D
Yeah
so
artifactory
saying
the
what
the
why
the,
how
duh
what
is
it
so
cartographer
so
yeah,
I'm
I'm
not
the
the
rfcs.
Are
there
they're
they're
pretty
long,
some
of
it's
kind
of
duplicative?
D
So
instead
I'm
gonna
like
talk
about
this.
I'm
just
gonna
use
this
presentation
to
talk
about
it
at
a
high
level,
which
I
think
will
be
more
helpful,
so
cartographer
supplies
inputs
to
a
template.
You
know
it
gets
values
from
the
workload
from
the
supply
chain
and
it
stamps
out
some
object
and
then
cartographer
also
reads
values
from
this
stamped
object
and
those
become
outputs.
D
So
I've
got
inputs
over
here
and
then
we've
got
output,
some
fields
on
this
object
and
what
we're
talking
about
with
artifact
tracing
is
just
being
able
to
establish
the
logical
relationship
of
hey.
I've
got
some
object
and
I've
got
these
outputs
and
I
want
to
I
want
to
say,
like
this
particular
url
and
sha
came
from
this
url
and
branch,
for
example,
from
the
git
repository
object
or
from
the
kpac
image
object.
D
This
image
address
is
related
to
this
particular
url
and
sha,
and
right
now
we
can't
do
that
because
you
might
submit
like
a
bunch
of
inputs
all
at
once.
You
might
update
the
object
multiple
times
and
then
you'll
see
this
output
like
changing
over
time.
So
why
do
we
care
like?
We
can't
do
it
now?
Maybe
it's
okay.
There
are
two
reasons:
one
observability,
the
other
security
thinking
about
observability.
D
It's
it's
easy
to
read
the
current
state
of
the
supply
chain.
So
when
I
see
the
supply
chain
now,
I
can
just
see
like
hey
this
git
revision.
This
git
repository
has
some
revision
here.
The
kpac
image
has
some
image.
The
config
is
is
has
defined
some
kate's
object,
but
these
aren't
necessarily
logically
connected
this
case.
Object
object,
there's
no
guarantee
that
it
belongs
to
this,
that
it's
reflecting
this
image
and
so
artifact
tracing
is
saying.
D
We
want
to
enable
cartographer
to
establish
the
causal
graph
to
say
like
oh,
you
know,
this
was
the
revision
that
led
to
this
kate's
object.
This
was
the
revision
that
led
to
this
image,
etc.
D
These
rc's
do
not
do
not
cover
the
question
of
how
do
you?
How
do
you
like?
Where
do
you
write
that
graph?
Where
do
you
write
when
I
say
allow
for
a
log,
it
does
not
establish.
Where
do
you
write
that
log?
That
is
an
implementation
detail?
There
is
an
rfc
that
we
talked
about
long
ago
back
then
we
talked
about.
We
referred
to
it
as
rc18.
D
D
The
other
thing
that
we
want
to
talk
about
is
security,
so
cartographer
submits
object,
definition,
definitions
to
the
cluster,
but
we're
really
only
relying
on
our
back
to
help
us
out
with
new
definitions
or
sorry
to
to
we're
only
relying
on
our
back
to
make
sure
that
our
supply
chain
is
not
corrupted.
D
I
argue
that
it
would
be
better
to
be
able
to
write
a
secure
supply
chain
on
top
of
an
unsecure
system
rather
than
to
say
cartographer's.
Security
is
only
as
good
as
the
underlying
systems
security
and,
I
believe,
that's
possible
with
artifact
tracing.
So
what's
the
problem
right
now,
we
already
do
a
little
bit
of
the
assurance
that
the
object
is
in
a
good
state.
D
D
So,
to
see
an
example
of
this,
let's
say:
we've
got
something
like
kpac,
where
we
we
pass
it
in
some
good
source
code
and
then
a
rogue
actor
comes
in
and
reapply
applies,
some
rogue
source
code
and
then
cartographer
later
comes
back
and
says:
oh
wait!
No,
that's
that's
rogue
inputs,
I'm
going
to
establish
the
the
good
source
code.
D
Is
there
what
will
happen
today?
Well,
the
goods,
the
good
spec
will
propagate
and
the
status
will
still
be
unknown.
You
know,
throughout
this
whole
process,
there's
been
no
output
and
the
status
will
be
unknown
and
we'll
see
some
good
image.
It'll
be
the
good
image
from
this
original
first
good
source
code,
and
then
we
could
see.
D
Oh
status
is
still
unknown
and
you
could
see
this
rogue
image
still
comes
because
it
you
know
it
had
this
definition
it
it
picked
up
that
definition
that
propagated
it
forward
and
then
later
we
would
see.
Oh
the
good
image
happens.
It's
the
system
is
eventually
consistent,
but
that
is
that
may
not
be
enough
of
a
guarantee,
and
so
we
want
to
give
our
users
some
ability
to
toggle
and
say
I
don't
want
an
eventually
consistent,
ci
cd
system.
D
I
want
a
ci
cd
system
that
is
strongly
consistent,
so
yeah
with
our
artifact
tracing
cartographer
can
determine
that
an
output
did
not
originate
from
its
own
input
because
we
can
associate
outputs
to
inputs.
Cartographer
would
ignore
rogue
outputs.
D
D
Another
is
what,
if
an
object,
told
us
the
equivalent
of
the
artifact
information
that
we
wanted,
but
not
exactly
in
in
the
phrasing
that
we
plan
for
in
number
one,
and
the
third
is
what
an
object
doesn't
help
us
out
at
all.
What
do
those
look
like?
Well,
one
is
resources
where
you
might
see
an
output,
some
latest
good,
and
it
provides
that
value
that
we're
gonna
read
and
then
there's
just
a
field,
and
it
says:
hey
the
inputs.
There
is
some
url.
D
There
is
some
revision,
that's
case.
One
case
two
is
well.
Maybe
it
provides
not
not
specific
inputs,
but
just
a
generation
number
of
the
spec
that
led
to
this
output
and
the
last
one.
It
provides
nothing.
So
we
see
that
here.
So
we
can
take
these
one
by
one,
we'll
start
with
the
easiest
inputs
provided
with
the
outputs.
All
we
need
to
do
is
save
the
info
that
we're
told
it's
super
simple.
D
We
can
just
have
a
log
file.
You
know
this
uri
uri
abc
resulted
from
url,
www.g.com
and
revision123
boom,
we're
done
that
is
artifact
tracing
and
and
and
we
don't
have
to
do
anything
else,
we
can
just
read
it
off
the
file,
but
if
we
want,
if
we
want
that
security
guarantee,
we
will
have
to
do
something
one
more
thing
which
is
we'll
need
to
cache
the
inputs
that
we
submitted.
D
D
C
Me
pause
right
there,
yeah
yeah.
Can
you
go
back?
Can
you
go
back
one
yeah,
yep,
nope
and
again
source
revision
could
be
something
unrelated,
because
it's
a
source
template.
It
can
spit
out
anything
it
likes
and
that
could
still
be
valid.
I
think
what
you're
suggesting
is
that
if.
D
Where
the,
where
the
resource
is
one
that
is
providing
that
information
that
we
want
so
here
and
this
this,
this
input
field
is
nested
under
the
latest
good
field.
So
this
is
a
resource
where
they're
specifically
saying
I'm,
I'm
going
to.
C
D
Relies
completely
on
resource
authors
being
on
board
with
this
pattern
that
we're.
D
C
D
If
you
look
at
a
tecton
task
run,
it
will
have
in
its
output
the
definition
of
the
task,
the
spec
of
the
task
run
when
it
ran,
and
I
think
that's
largely
because
technically
you
could
update
the
spec
of
the
task
run,
but
it
wouldn't
it's
not
going
to
rerun
or
anything.
So
it's
just
like.
Oh,
like
here's,
the
canonical
place
where
you
should
figure
out
like
what
what
was
used
to
run
this
task
run.
F
E
D
I
overlap.
Yes,
I
think
that
one
of
the
things
that
is.
D
D
That
lower
level
document
providence
or
attestation
information
that
those
resources
provide
at
the
cartographer
level,
all
we
can
say
is
hey.
I
submitted
this
information
to
this
controller
and
it
gave
me
back
this
this
other
stuff.
I
think
that
that
has
value
for
the
you
know
to
be
able
to
say
at
that
system
level
like
what
what
you
know
you,
I
plugged
in
all
these
different
pieces
to
your
system.
D
What,
when
you
were
responsible
for
moving
values
between
those
pieces,
what
did
you
do
and
then
there's
definitely
it's
definitely
crucial
that
those
individual
pieces
are
going
to
have
much
more
in-depth
information
about
what
they
did,
and
I
don't
think
that
this
this
in
no
way
is
meant
to
replace
the
sort
of
attestation
that
kpac
would
have
to
do
where
it
details.
Like
here's.
D
E
It
does
it's
just
I
guess
where
my
head's
going
is
you
know,
do
we,
I
guess,
are
we
saying
that
so
this
wouldn't
it
by
itself,
wouldn't
enable
attestations,
because
you're
saying
the
individual
components
need
to
be
part
of
that.
D
At
the
end
of
the
day,
yeah
this
doesn't
prevent
you
from
stamping
out
or
from
bringing
in
bad
bad
controller
x.
Cartographer
can
tell
you
hey,
I
gave
bad
controller
x
this
input
and
it
gave
me
this
output,
but
it's
still
going
to
be
important
to
interrogate
that
controller.
To
ask
it
like.
What
exactly
did
you
do.
E
D
I
think
that
this
is
this
is
necessary
for
that
that
top
level
observability,
because
it
becomes
difficult
to
trace
this
it
becomes
difficult
to
trace
back
like
what
attestation,
if
I'm
looking
at
this
sorry,
let's
let's
say
like
at
this
point
today,
I
get
this
kids
object
and
I
say:
okay,
I've
got
this
case
object
and
this
came
off
of
the
config
and
then
I
could
dive
into
that.
D
Yeah,
depending
on
how
how
things
are
indexed
in
that
controller,
maybe
they're
not
even
indexing
on
outputs,
maybe
they're
indexing
on
inputs
and
they're
like
oh.
If
you
want
to
know
what
happened
with
this
input,
give
me
give
me
an
input
definition,
and
so
you
need
to
provide
some
image
and
right
now
you
wouldn't
even
know
what
image
to
to
say
like
oh
image,
xyz.
What
did
you
do
with
that?
Does
that
make
sense.
E
I
think
so
yeah
I
was
yeah.
I
think
it
was
more
around
what
the
aims
for
this,
what
we
use
it
for
and
what's
the
you
know
from
that
level,
and
if
this
I
mean
having
a
goal
around
salsa
and
provenance
and
attestations,
is
something
that
it
keeps
coming
up,
and
I
was
just
wondering
if
this
is
related
to
if
it's
not
what
the,
what
the
people
use
to
build.
On
top
of
this,
you
know.
C
I
think
this
is
about
debug
for
first
and
foremost
right.
I
think
the
first
goal
that
you're
trying
to
solve
with
this
is
helping
people
understand,
what's
happening
right
rationalizing
about
the
behavior
of
the
supply
chains,
they're
designing,
knowing
that
they
can
have
trust
in
what
they
have
designed,
which
then
leads
to
well.
Can
I
trust
the
attestation
of
a
certain
thing
right?
What
am
I
testing
for?
That's
a
it
could
answer
that,
but
it's
lower
down
the
rung
than
I
can
just
even
debug
to
get
to
that
point.
D
I
would
say
two
two
use
cases
really
jump
out
at
me.
One
of
them
is
if
you're
building
a
ui
on
top
of
a
cartographer
users,
probably
care
hey.
I
made
some.
I
made
some
change
to
my
code.
Where
is
it
right
now
like?
Has
it
gotten
all
the
way
through
or
not?
And
so
that's
that's
observability
and,
as
I
said,
the
other
piece
is
security
that
like
right
now,
eventually,
we
know
that
cartographer
will
output
good
configuration
for
your
cluster,
but
right
now
it's
possible
that
you
have
trent.
D
If
you
had
a
rogue
actor
that
that
had
permissions
that
it
wasn't
supposed
to
have
and
they
altered
a
k-pac,
you
know
if
they
altered
any
of
those
objects
it
would,
it
would
be,
it
would
be
possible
for
them
to
have
the
ci
cd
output
a
transient
configuration
on
the
cluster,
that's
bad,
so
I
don't
think
we
should
allow
that.
C
D
Let's
move
on
to
the
next
case,
I
kind
of
related
rash.
You
were
talking
about
observed
about
generations
and
I
think
that
this
is
actually
what
we
should
be
using
or
what
we
should
be
encouraging
as
a
pattern
in
the
kt
ecosystem,
where,
with
your
latest
good
output,
the
input
is
some
generation
of
the
spec.
D
So
why?
Why
do
I
say
that
a
resource
spec
is
full
of
fields
template?
You
know,
any
cartographer
template
is
going
to
vary
some
subset
of
that
field,
but
it's
not
clear
that
the
resource
author,
the
people
that
write
k-pac
images,
are
going
to
agree
with
the
template
author,
like
the
app
operator
who's.
Writing
some
template
that
wraps
kpac
image
that
the
only
important
update
inputs
are
some
given
subset.
It's
much
more
likely
that
the
the
resource
authors
will
say
all
of
these
inputs
matter
all
the
fields
on
the
spec
matter.
D
That's
why
I
put
them
there,
and
so
we
should.
It
would
make
much
more
sense
to
say.
Well,
let's
expect
that
resources
report
all
inputs
and
rather
than
just
have
a
list
of
all
the
inputs,
I
mean
really
just
replicate
the
spec
just
use
the
generation,
the
the
that
that's
what
that's,
what
the
generation
is
short
for.
So
here
we
can
see
what
we
would
do.
We
would
cache.
You
know
we
would
submit
a
template.
D
The
template
would
have
some
inputs.
We
would
then,
when
we
submitted
to
the
cluster,
the
cluster
would
give
us
back
an
object
and
that
would
have
a
field
metadata.generation
and
we
just
cache
that
generation,
along
with
the
the
input
fields
that
we
care
about.
So
in
our
cache
we'd
have
gen
3
revision,
456
gen,
four
revision,
one
two
three
and
then
later
we
can
read
this
object
and
see.
Oh,
it
says
this
is
observe
generation.
Four,
we'll
say
this:
uri
abc
came
from
revision,
one
two
three
where's.
C
Yeah
yours
is
a
way
harder.
Yours
is
a
way
harder
question
to
answer
so
start
with
mine,
because
mine's
not
a
question.
Mine
was
a
point.
E
Yeah
I'd
say:
I
stopped
no
historical
information.
You
know,
cumin's
resources
can't
be
relied
upon
for
historical
information
that
needs
to
be
persisted
outside
the
cluster.
No.
C
I
mean
what
I'm
saying
is
that
I
thought
at
the
ecd
level
or
the
keystore
level
that
they
would
keep
some
sort
of
like
historical
record
of
of
specs
per
generation,
so
that
you
could
historically
step
back
it.
Just
it's
a
pattern
that
is
almost
implemented
here,
which
is,
I
have
a
version
database,
but
I'm
only
going
to
show
you
the
latest
version.
That's
what
was
surprising,
not
that
that's
how
kubernetes
is
because
it
isn't
clearly
it
isn't.
But
that
was
the
surprise
for
me.
C
When
I
saw
generations
I
thought
so
they're
keeping
some
kind
of
historical
database
like
some
time
series.
E
C
That's
okay,
the
I!
The
idea
is
that
it's
while
it's
alive,
there's
meaning
to
that
generation
right!
That's
what
I
was
surprised
by.
I
think
it's
more
about
storage
and-
and
whatever
else
came
with
that,
but
yeah
it
doesn't
it's
unrelated.
It's
not
something
we
get.
We
have
to
implement
it
ourselves
right,
but
it's
kind
of
surprising
yeah.
D
You
mentioned
that
last
week
and
I
went
searching,
I
haven't
seen
anything
any
discussions
on.
Why
that
isn't
there
but
yeah
I
it
does
seem
reason
seems
reasonable
to
me
james
to
to
your
question
on
where
the
cache
exists.
That
is
at
the
end
of
this
presentation.
So
if
I
can,
if
you
can
don't
mind
waiting.
E
D
I
the
the
la
the
sort
of
the
last
sort
of
object
where
it
provides
inputs
needed.
Caching,
this
one
needs
caching
and
surprise
surprise.
The
next
pattern
will
also
need
caching,
so
so
yeah.
So
hopefully
I've
convinced
you
that
if
the
you
know,
if
we
have
an
object
like
this,
where
the
observed
generation
is
provided
with
the
with
the
output,
we
hit
both
of
our
goals,
we
can
construct
a
graph
of
inputs
and
outputs
and
we
can
achieve
security
by
saying
any
generation.
D
That
is
not
in
our
cache.
We
just
ignore.
We
don't
propagate
forward
pausing
for
questions
all
right.
Let's
go
ahead.
F
F
C
F
G
I'm
curious
about
something
that
maybe
I
missed
earlier
in
this.
The
observed
generations
are
all
tied
to
individual
outputs,
so,
like
your
resource
could
have
multiple
outputs
with
different
generations.
G
The
you
know,
I
think
I've
seen
that
occasionally,
but
I
it's
I've
probably
seen
a
pattern
more
where
the
status
has
one
observed
generation
as
representative
of
spec,
I
think
we
can
still
use
that
the
same
way
right.
You
know
we
don't
we
don't
need
to
force
individual
output
observed
generations
if
there
are
multiple
outputs,
but
I
just
wanted
to
double
check
again.
I
missed
the
beginning.
So
if
you
covered
that,
I'm
sorry.
D
I
I
did
not
cover
that
it
will
be
incumbent,
I
think
one.
It
will
be
incumbent
upon
the
template
author
to
understand
the.
D
It
says
that
it's
if
it,
if
a
user
is
reaching
towards
status,
dot,
observe
generation
for
for
for
this
they're,
almost
certainly
wrong,
because
that
generally
is
not
tied
to
the
latest
good
output,
and
I
would
liken
this
more
to
the
observed
generation
field
that
we
see
in
meta
v1
conditions
where
there,
if
you
read
the,
if
you
read
it,
it
says
the
observed
generation
here
relates
to
the
generation
that
caused
this
condition
to
switch
to
its
current
value
and
so
for
for
each
condition
like
there's,
there's
something
there.
D
I
think
that
if
you
had
a
like
scoot
it
back
over
here,
if
you
had
something
like
that,
oh
I'm,
in
presentation
mode.
So
I
can't
change
this
at
the
moment,
but
yeah.
I
think
if
you
had
a
latest
good
and
it
wasn't
just
uri,
it
was
like
uri
and
revision
and
message.
It
would
be
fine
to
have
that
to
have
some
object
or
multiple
fields
and
all
that
to
have
this
one
input.
D
So
it's
not
that
every
that
every
output
needs
if
you're
outputting
three
different
kinds
of
information.
I
don't
argue
that
you
need
three
separate
observed
generations,
but
I
do
think
that
you
will
almost
certainly
need
a
different
observed
generation
than
status.
Dot,
observed
generation.
G
I
don't
see
a
an
edge
case
that
you
know
prevents
that
from
working.
I
think
what
the
thing
that
you've
proposed
you
can
do
that
you're
just
worried
that
in
some
cases
it's
not
going
to
be
accurate,
you're,
not
saying
that
it's
not
possible
to
use
that.
There's
something
different
about
the
model
that
you're
proposing.
That
would
make
it.
You
know
so
that
you
couldn't
use
status.observegeneration
to
form
the
association.
D
I
think
more
what
you
were
just
describing
where
you're
saying
you
can
use
these
three
pieces
of
information
to
reason
and
and
make
sure
that
these
inputs
are
outputs.
I
think
that
that's
going
to
be
synonymous
with
that
third
approach
that
I'm
offering-
and
I
certainly
agree
and
right
here
in
the
same
way
that
generations
with
inputs
provided,
was
kind
of
hypothesizing.
D
What,
if
we
lived
in
a
world
where
we
didn't
have
the
performance
hit?
What
if
we
lived
in
a
world
where
people
gave
us
more
information
and
utilized
this
new
pattern?
All.
G
C
C
This
is
what
I
keep
trying
to
submit
this
kubecon
try
and
get
a
talk
accepted
where
I
can
go
and
talk
about
what
is
it
to
be
a
good
actor
in
a
ci
cd
scenario
on
a
kubernetes
cluster
right
and-
and
this
here
is
the
this
here,
I
think,
is
the
goal
to
advertise
to
people-
tell
us
about
an
output
and
what
spec
it
matches.
It's
going
to
be
the
nicest
thing
that
you
could
possibly
do
all
right.
It
doesn't
mean
that
it
happens.
It
just
means
that
it'll
be
great.
D
So
to
yeah
I
love
when
I'm
giving
a
presentation
and
folks
are
like
what,
if
we
did
this
other
thing,
and
I'm
like
oh
it's
here
so
to
what
steven
was
talking
about
what
if
they
just
don't
provide
us
anything,
you
know
it's
it's
the
way
most
crds
are
today.
There's
we've
gotta
wait.
D
D
That
doesn't
mean
that,
like
something
else,
you
know
there
might
be
some
petubation
in
the
universe
that
the
changes
think
so,
for
example,
there
might
be
new
k-pac
base
images
or
there
might
be
new
commits
to
a
branch
in
git
and
so
that
kpac
image
or
that
get
repository,
may
change
on
that
same
generation.
But
for
right
now
it's
at
rest.
D
If
we
see
these
two
things,
then
we
can
say:
hey.
The
current
output
is
the
result
of
the
current
spec,
the
so
yeah
the
same
like
take.
This
our
source
revision
is
written
into
the
spec,
but
there's,
oh
sorry,
yeah.
So
one
question
is:
is
it
sufficient
to
just
hold
rights?
It
is
not,
and
so
why
not.
The
source
revision
is
something
that's
written
into
the
spec,
and
you
know
this
will
update
this
from
time
to
time.
D
The
base
image
definition
is
something
that
exists
out
in
the
universe,
separate
from
the
spec
that
we
that
we
define
it
it
gets
updated
without
are
observing
it,
and
so
there's
quite
if
we
can
see
that
we
could
have
a
concurrent
update
of
source
revision
and
this
base
image
definition
and
let's
say
that
the
base
image
updates
an
instant
before
the
source
does
that
we
we're
not
able
to
observe,
like
we've
we've
already
done.
A
read
we
saw
ready,
is
true
and
then
we're
saying:
okay,
I'm
going
to
do
a
write.
D
Now
we
can
do
atomic
rights,
it's
totally
possible
to
say
hey
when
I
submit
this,
make
sure
that
I'm
submitting
with
this,
like
the
spec,
hasn't
changed.
But
again
this
base
image
definition,
isn't
the
result
of
a
change
to
the
spec.
There's
no
way
to
make
that
atomic
change
and
say
you
know
if
something
else
has
changed
in
the
universe,
then
then
allow
me
to
then
you
should
fail
this
right.
It
has
to
be
atomic,
and
so,
as
a
result,
we
see
two
new
outputs.
D
We
see
image
generation
n
with
the
new
base
image,
and
then
we
see
the
input
generation,
n,
plus
one
with
the
new
base
image
and
but
because
we
didn't
know
about
this,
with
the
most
likely
thing
that
we
would
do
is
resend,
oh
well,
I
gave
it
a
new
input,
so
this
is
input
generation,
n
plus
one,
and
there
was-
and
it
gave
me
the
based
on
the
base
image
and
then
there
must
have
been
an
update.
D
There
was
a
new
base
image
and
that's
input,
generation,
n,
plus
one,
and
so
there's
there's
not
enough
information
for
us
to
disambiguate
between
these.
Unless
we
wait
for
for
the
system
to
settle
and
to
only
read
when
ready
equals,
true
so
yeah,
so
we
must
hold
reads
until
the
controller
has
an
output
for
the
current
spec,
so
read
only
when
generation
is
observed,
generation
red
equals.
True,
there
is
an
issue
of
starvation.
D
If
updates
happen
faster
than
reconciliations
that
can
starve
the
supply
chain.
So
we
have
to
hold
update.
We
have
to
hold
reads
and
we
have
to
hold
rights,
so
we
can
only
write
if
the
system
is
at
rest.
I
one
thing
to
note:
is
that
ready
can
equal,
true
or
ready
can
equal
false?
In
that
case
the
you
know
the
pros:
hey,
we
avoid
starvation
and
it
guarantees
artifact
tracing
the
cons.
Is
that
we'll
skip
updates
in
that
case?
D
So
if,
at
time
zero,
we
submit
update
one
and
it's
going
to
take
10
seconds
to
complete
or
10
ticks
at
time?
Three,
we
we
have
update
two
we'll
just
cartographer,
won't
stamp
that
out,
because
things
are
in
an
unknown
state
update
three
comes
in
at
time:
seven.
We
won't
stamp
that
out,
because
things
are
in
an
unknown
state
at
time.
Nine,
a
new
update
comes
in
and
we
see
that
it,
it
waits
and
then,
at
time
ten.
D
When
this
completes
then
update
four
will
be
applied,
so
these
two
will
be
skipped
over.
D
I
would
say
that
we
have
examples
of
crds
that
operate
like
that
kpac,
for
example,
if
you
submit
multiple
inputs,
there's
only
one
build
going
at
a
time
and
it
will
toss
out
old,
like
it'll,
only
submit
the
newest
one
when
it's
ready
to
create
a
new
build,
I
see
rash
and
then
stephen
and.
G
D
G
Doesn't
behave
like
that,
we're
not
we're
not
holding
the
rights
to
enforce
that
behavior
that
you're
talking
about
where
things
kind
of
build,
serially
right,
we're
holding
right
so
that
we
can
wait
for
it
to
settle
whatever
kind
of
resource.
It
is
so
that
we
can
observe
the
correlation
between
input
and
output
without
getting
those
inputs
overwritten
so
that
we
end
up
starved,
for
you
know
a
thing
that
we
can
correlate
to
allow
it
to
progress
forward.
C
C
Cause
here
could
be
if
a
lot
of
images
got
created
that
I
can
think
of
with
kpac,
specifically.
G
It's
updating
a
kpac
image
spec
over
and
over.
G
E
C
G
G
You
know
one
after
another
into
the
future
right,
so
that
that
skipping
of
updates
is
like
it's
a
part
of
a
level
triggered
system
right.
It's
like
like
how
this
type
of
thing
or
it's
an
expectation
of
the
type
of
thing
we're
building.
So
you
know
that
compromise
doesn't
mean
that
much
personally
I
mean
I'm
not
saying
we
shouldn't
argue
about
it.
G
E
C
Though,
where
it's
like
already
false
right.
D
C
All
right,
but
if
it's
oh,
oh
sorry,
it's
hard
to
read
this
one,
sorry,
the
logic
here
finally
ticked
over
for
me
when,
though,
when
the
generations
are
matching
and
we
prevent
rights
until
it's
false
or
true,
it's
completed
a
step.
Yeah,
okay,.
D
C
D
Okay
yeah,
so
one
thing
that
I
mentioned
that
you
know
all
these
approaches
need
need.
Caching,
this
one
needs
two
caches.
Sometimes
we
can't
read
a
current
value,
so
we
need
to
cache
the
value
that
we're
reading,
but
also
sometimes
we
can't
write
the
most
recent
templated
definition,
so
we
need
to
template.
We
need
to
cache
the
definition
we
expect
to
be
on
the
cluster.
D
So
you
know
that
that
piece
I
was
just
talking
about,
but
currently
we're
doing
this
in
memory
like
we
submit
an
object
to
the
cluster
we
check
and
see
like
hey,
is
this
all
right?
I
see
david
said
five
minutes
left,
so
I'm
gonna
skip
over
this.
D
It's
useful
just
know
we
need
to.
We
need
to
both
the
spec
that
we
submit
so
that
we
can
continue
to
ensure
that
it's
the
one
that's
on
the
cluster
and
we
need
to
cache
the
outputs,
because
when
that
object
is
spinning,
we
won't
be
able
to
read
the
output
off
of
it.
We'll
need
we'll
need
to
read
it
off
of
some.
D
Some
cache
that
we've
specified
I've
been
using
ready,
equals
true
as
a
shorthand,
but
I
don't
think
that
we
should
actually
hard
code
that
in
we
should
just
use
health
rules.
We
have
definition
for
health
rules.
You
know,
sam
has
I
been
working
super
hard
to
to
make
sure
that's
implemented
and
in
the
in
the
rfc
I
received
some
feedback
that
maybe
users
would
want
to
have
different
health
rules
for
the
top
level.
Like
is
this
object
healthy
and
the
like?
D
Is
this
ready
to
pass
information
on
so
I've
written
it
so
that
you
have
two
separate
health
rules
fields?
I.
D
Because
I'm
amenable
to
that
not
be
it's
not
clear
to
me
that
that's
actually
necessary,
but
I'm
totally
minimal
yeah.
So
I
argue
that
at
this
point
we
have
achieved
our
two
goals
that
we
read
up.
Outputs
always
correspond
to
the
inputs,
the
you
know,
they're
just
what
was
the
you
can
read:
hey
here's,
the
spec,
here's,
the
output
ready
is
true
and
it's
same
generation.
D
This
spec
led
to
this
output
and
also
rogue
outputs
will
never
be
read
off,
because
cartographer
will
always
ensure
that
spec,
if
it's
changed,
we'll
flip
it
right
back
and
then
we'll
just
wait
until
things
are
in
a
good
state
again
that
that's
like
the
broad
overview
and
then
the
last
couple
slides
talk
about
the
caching
and
like
what
you
know.
What
do
I
think?
Where
do?
I
think
that
cash
is?
Are
there
any
questions
about
these
approaches?
Before
I
talk
about
that.
D
That
is,
that's
likely
good
enough.
I
think
the
one
thing
that
we
would
see
if
we,
if
we
did
just
if
we
did
do
just
that
and
then
the
template
changed
then
we
would.
We
would
see
like
a
little
more
churn
in
the
system
which
we
could
probably
handle.
D
C
D
C
I
guess
my
point
is
simply
that
if
today
you
had
some
inputs,
you
know
what
gen
2
created
you.
If
someone
changed
the
template,
you
would
have
a
gen
3,
so
you
don't.
You
got
new
inputs
for
that
one.
So
you
would
cache
them
and
then
still
you
don't
need
the
spec.
You
just
need
the
the
things
that
we
need
to
know
about
as
inputs
yeah
anyway.
It's
technical
detail.
I
don't
think
we
need
to
go
into
too
deeply.
If
you
want
to
get
onto
your
caching
stuff.
D
Yeah
and
david,
I
appreciate
your
forbearance
here.
There
are
so
where's
the
cache
I
think
they're
broadly
for
options
in
memory
in
the
status
of
the
workload
in
a
separate
object
on
the
cluster
and
in
a
data
store.
They'll
have
you
know
some
strengths
and
drawbacks
in
memory.
We
probably
need
something
that
what
rash
is
just
talking
about.
Survivability
like
we
should
expect
that
the
controller
will
go
down,
sometimes
in
the
status
of
the
workload,
the
workload's
already
very
long.
D
I
worry
not
so
much
about
the
there's,
a
one
megabyte
limit.
I
don't
worry
so
much
about
that
as
I
do
about
the
about
just
readability,
but
maybe
that
ship
has
sailed.
I
in
a
separate
object
on
the
cluster.
D
I
think
it's
a
good
idea
and
then
we
could
just
do
it
put
in
a
data
store
like
have
some
database
on
case
or
off.
G
Sorry
steven
we're
thinking
about
that
separate
object
in
the
context
of
blueprints
so
like,
as
we
think
about
rethink
the
descriptor.
The
you
know,
amount
of
stuff
in
status
makes
that
descriptor,
not
especially
user
friendly
right
and
so,
and
if
we
wanted
to,
you
know
folks
be
able
to
bring
their
own
descriptor.
That's
not
even
like
you
know
intended
to
be
used
with
the
system
right
like
they
want
to
reconcile
against
a
config
map
or
something
like
that
right.
G
You
could
imagine
something
you
know
something
like
that
being
useful
in
an
operator
operator
context
right,
then
we
really
would
need
some
other
kind
of
storage
there.
And
so
I
wonder
if
there's
a
touch
point
between
blueprints
and
this,
where
you
know
we
can
make
a
decision
that
works
well
in
both
cases.
C
C
D
D
Yeah,
the
only
final
thing
to
say
about
the
cache
is
you
know
when
we
talk
about
a
separate
object,
it
could
be
a
config
map,
they're
well
understood,
but
my
concern
is
that
I
would
just
expect
lots
of
people
to
have
permission
to
alter
config
maps
and
altering
it
would
mean
like
really
disrupting
the
behavior
of
the
supply
chain.
So
I
think
we
just
need
some
custom
cartographer
object
that
we
just
call
it
the
carto
config
map.
E
D
E
Be
good
to
understand
is
probably
what
size
these
grow
to
and
the
number
of
them
what
the
payload
is
inside
these
as
well.
My
one
of
my
concerns
around
is
just
to
grow
a
number
of
resources
and
using
more
resources
to
store
things
which
a
lot
of
people
do,
which
is
good,
but
if
there
is
going
to
be
thousands
of
these
that
hasn't
does
have
an
impact
on
the
performance
of
clusters,
with
lots
of
applications
creating
their
own
resources.
Just
something
else
to
be
aware
of
yeah.
D
D
D
C
D
C
D
Get
outside
of
my
own
head,
but
david,
I
am
done.
That
is
that's
everything
you
want
to
do
now.
A
First,
thank
you.
Thank
you
for
taking
the
time
to
build
this
presentation
to
introduce
three
rfts
in
a
in
a
very
clear
presentation.
Thank
you
for
doing
that.
Could
you
please
drop
the
link
for
the
presentation
chat,
so
I
can
add
it
to
the
notes.
Yes,
thank
you.
Thank
you
all
for
attending
one
last
thing
we
have
thomas
here
again,
thomas
thank
you
you'll,
be
presenting
this
week
and
go
to
the
go
to
conference
in
beautiful
denmark
right.
If
there's.
A
Cool,
so
so,
first,
thank
you
for
doing
that,
thomas,
the
the
link
for
the
for
his
presentation.
It's
in
the
notes-
and
I
will
add
it
here
also
again,
if
you
need
something
from
the
team,
if
you
have
any
question,
feel
free
to
reach
out.
If
there's
anything,
we
can
do
to
help
for
your
session,
it
will
be
awesome.
B
Yeah
I'll
definitely
share
yeah
what
I've
been
working
on
also.
Hopefully
it
can
be
useful
for
the
project
also
for,
like
yeah
sharing
the
world
about
cryptographer,
I'm
really
really
big
fan
of
the
project.
So
I'm
happy
I
get
to
yeah,
show
it
to
people
this
week,
I'm
not
sure
if
the
conference
is
recorded,
but
if
it
is
then
of
course
I'll
share
the
video
with
you
and
let
you
know.
A
All
for
attending
and
yeah
hope
to
see
you
next
thank
week.