►
From YouTube: Cartographer Office Hours - March 28th, 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
There
we
go
the
same
sparkling
personality
as
david
he's
out
today,
so
I'm
just
standing
in
for
him
welcome
everyone.
I
will
drop
a
link
just
to
make
sure
that
everyone's
got
today's.
A
I
believe
that
normally
all
we
do
is
we
find
the
note
taker
and
then
get
started
talking
so
who's
up
for
taking
notes.
B
A
B
Let
me
just
find
everybody
cool
yeah,
so
basically,
this
came
from
a
request
for
rfc
issue
that
was
out,
and
the
idea
is
just
to
allow
templates
to
describe
what
health-
and,
I
guess,
lack
of
health
of
a
resource
means
for
the
given
resource
that
the
template
is
stamping
out
and
there's
already
been
some
comments
on
this
and
there's
been
some
edits
to
the
rfc,
so
I
just
couldn't
present
it,
as
is
not
the
original
version
that
had
comments
that
were
accepted.
B
So
basically,
the
basic
idea
is
for
all
template.
Types
to
now
include
within
the
spec
are
placed
to
reference
a
resource
status.
Rule
ref,
I
think
that's
supposed
to
say
whoops.
I
think,
there's
a
one
that
has
it
correctly.
I
think
they're
all
wrong,
but
it's
supposed
to
be.
Each
template
is
able
to
reference
a
resource
status
rule
which
is
a
new
crd.
We
will
define
and
the
crd
looks.
B
Actually.
I
can
just
go
to
the
bottom
to
show
the
spec.
The
resource
status
rule
essentially
looks
like
this
has
two
at
the
moment:
two
topical
fields
healthy
and
unhealthy,
and
under
each
of
them
you
can
define
conditions
and
or
fields
where
cartographer
can
look
to
find
the
health
of
the
of
the
resource,
and
so,
for
example,
if
you
defined
a
condition,
if
we
go
back
to
the
top
for
an
example,
you
could
say
whenever
this
thing
is
ready.
B
True,
that
means
it's
healthy
or
if
it's
already
false,
that
would
mean
it's
unhealthy,
so
cartographer
would
look
for
that
to
determine
the
health
or,
if
you
had
one
that
was
defining
fields.
That's
for
a
simpler
one.
You
could
just
say
like
for
a
service,
for
example
that
doesn't
have
any
conditions,
so
you
could
say
if
the
status.load
balancer
field
has
been
filled
in
then
it's
healthy.
If
not,
then
it's
not
healthy.
B
So
this
match
field
section
follows
the
way
we've
done
match
fields
in
in
blueprints.
Selecting
templates
that
you
know
the
same
operator
is
in
not
in
existence
does
not
exist
and
if
you
say
like
in
then
you
just
provide
a
valid
values
and
then
for
conditions.
All
you
have
to
give
is
the
type
and
status
of
the
condition,
and
so
this
health,
healthy
or
unhealthy
status,
gets
reflected
in
the
workload
status
in
the
resources
section.
B
So
that's
up
for
discussion,
but
this
new
stamp
status
field
for
every
resource,
which
will
give
the
overall
status,
whether
it's
healthy
or
unhealthy,
and
then
the
it'll
either
have
fields
or
conditions.
So
this
one
was
defining
a
match
field.
So
it'll
give
you
the
fields
that
it
read
to
determine
that
it
was
unhealthy,
and
so,
if
you
had
a
conditions
one
then
it
would
look
like
this.
It
would
give
you
the
condition
that
it
read
and
for
condition,
even
though
you've
only
supplied
the
type
and
status
we'll
fill
in
everything
else.
B
That
was
in
the
condition
it
will
propagate
everything
else.
That
was
in
the
condition
and
for
fields
we
give
you
the
option.
This
is
an
optional
field
to
put
in
match.
Fields
is
just
message
path,
which
is
just
a
place
where
a
cartographer
can
populate
kind
of
some
some
sort
of
useful
error
message
because
match
fields
like
with
conditions
you,
you
naturally
will
have
a
message,
but
for
match
fields.
You
won't
obviously
have
an
obvious
message.
B
So
if
there's
some
more
useful
contacts
that
you
want
to
provide,
you
can
give
a
message
path
and
cartographer
will
pull
off.
The
message
like
the
way
cap
gives
you
a
useful
error
message,
we'll
just
pull
the
status
there
and
for
fields
we'll
just
report,
the
key
that
we
were
reading
and
the
value
that
led
to
the
state
and
then
finally,
if
cartographer
cannot
read
healthy
or
unhealthy
like
it
can't
read
any
it,
it
can't
successfully
reconcile
either
either
the
healthy
conditions
and
fields
or
the
unhealthy
conditions
and
fields.
It
will
go.
B
It'll
say
that
resources
in
the
unknown
state.
We
have
an
example
somewhere
unknown
right
like
this
one.
So
if
you,
if
you
say
that
you're
looking
for
already
true
and
for
some
reason,
we're
not
at
ready,
true
yet
then
or
and
we're
also
not
already
false,
there's
nothing
there.
The
resource
will
go
into
the
unknown
state,
so
that's
just
in
terms
of
the
difference
in
what
users
will
see
in
terms
of
underlying
behavior
is
another
important
point
here
are
a
couple
of
important
points.
B
First
of
all,
the
three
just
to
reiterate:
the
three
states
that
the
resource
can
be
in
right
now
are
healthy,
unhealthy
and
unknown.
Healthy
and
unhealthy
are
up
to
the
user
or
the
template
author
to
define
unknown
just
means
cartographer
cannot
determine
either
one
of
those
two
states
and
for
all
the
healthy
conditions
they
will
be
anded
together.
B
And,
finally,
the
templates
will
two
things.
First
of
all,
templates
will
have
a
status
now
and
they
will
only
the
template
will
only
be
considered
ready
if
the
reference
cluster
resource
status
rule
exists
or,
if
you
don't
reference
rule,
because
it
is
optional
which
we'll
get
to
and
otherwise
it'll
be
false,
and
this
way
blueprints
which
reference
the
templates
will
know.
B
The
blueprint
themselves
will
not
be
considered
ready
unless
all
the
templates
are
ready-
and
I
mentioned
that
you
don't
have
to
reference
rule
we've
defined
in
this
rfc-
that
if
no
rule
is
referenced,
every
resource
will
just
default
to
healthy,
but
that
it
can
be
debated
and
the
reason
we
chose.
B
That
is
because,
as
part
of
this
rfc,
we've
determined
that
or
we've
defined,
that
the
work
the
owners
or
the
workload
are
deliverable
will
not
go
into
a
ready,
true
state
unless
all
underlying
resources
are
are
currently
healthy
and
therefore,
if
the
default
behavior
is
not
or
if
the
default
behavior
is
that
resources
do
not
go
into
the
healthy
state.
If
no
cluster
resource
status
rule
is
defined,
then
the
owner
will
never
go
into
the
ready,
true
state.
B
So
I
said
a
lot
any
questions.
Anything
I
can
clarify
anything
that
wasn't
clear.
D
I
have
a
question
about
the
cluster
resource
status
rule.
Is
there
a
reason?
That's
a
separate,
cr
versus
embedding
it
in
the
thing
as
a
reusability
there,
I'm
trying
to
think
like
if
you
had
a
bunch
of
templates
that
templated
the
same
underlying
resource.
Maybe
that's
a
reason
to
do
reusability,
but
it's
just
curious
behind,
though
that's
your
motivation
or
something
else.
B
Yeah
one
of
the
alternatives
we
defined
was
that
we
could
embed
them
directly
into
template,
but
two
one
there's
two
reasons.
One
like
you
said:
if
you
have
a
bunch
of
templates
that
type
of
the
same
resource
type,
then
you
might
be
duplicating
these
rules,
which
is
also
theoretically
more
of
a
well
yeah.
That's
one
reason:
another
thing
is
just
like
ready.
True
is,
might
be
a
common
condition
that
a
lot
of
resources
share.
D
D
You
know
what,
if
names
conflict
between
that
thing-
and
you
know
the
same
thing
that
other
templates
are
bringing
from
the
catalog
right,
the
I
don't
have
a
better
idea
right
for,
like
I
don't
think
it
makes
sense
to
make
it
cluster
local
and
then
select
against
the
templates,
because
then
you
get
different
your
template
to
have
different
behavior
on
different
clusters,
so
that
aspect
of
the
direct
reference
I
like,
but
sorry,
scott.
E
I
literally
was
just
raising
my
hand
as
he
apologized
so
no
need
to
apologize,
so
I
I
also
tend
to
agree
that
I
would
tend
to
lean
towards
inlining.
These
rules
that
they
are
at
all
complex
is
probably
an
indication
that
the
rule
itself
can
be
simplified
like
for
many
cases.
E
I
expect
it
will
just
be
as
simple
as
basically
just
grab
the
ready
condition
and
use
that
as
an
aggregate
that
represents
everything
else
and
that's
like
all
the
rule
needs
to
be
the
other
big
advantage
of
not
having
external
rules
that
we
don't
have
to
actually
start
reconciling
all
the
template
resources,
as
well
as
the
blueprints,
and
they
can
just
continue
to
remain,
as
is.
B
D
I
think
I
I
had
this
idea
earlier
for
like
a
way
to
extract
and
reuse
those
kind
of
like
workload,
selection
logic
into
the
workload
inspectors.
It's
like
one
of
the
kind
of
earlier
architecture
documents
and
decided
that
you
know
the
it's
really
the
distribution
problem
that
makes
it
hard
to
externalize
pieces
kind
of
of
what's
on
those
templates,
and
so
because
this
has
shown
up
a
couple
times.
I
wonder
if
there's
you
know,
maybe
in
this
case
we
don't
need
to
be
able
to
extract
this
logic
into
something
separate.
D
But
I
wonder
if,
in
the
long
term
we
should
think
about
patterns,
for
you
know,
if
templates
do
need
to
share
information
right.
What
would
those
patterns
look
like,
although
in
this
case
I
you
know,
I
think
it'd
probably
be
okay
to
headline.
F
I
wonder
if,
when
in
lining,
we
should
consider
something
like
by
default.
We
like
the
templates,
evaluate
like
ready,
true
ready,
false,
but
then,
if
you're
then
working
with
a
with
a
resource
that
does
not
adhere
to
that.
Then
you
provide,
because
I
would
guess
that,
like
the
majority
majority
probably
uses
the
ready
tree,
but
if
you
want
conventions
but
then
like
one
or
another
resource,
you
would
then
have
to
inline
the
definition,
because
it's
a
little
odd
kind
of
resource.
D
I
wonder
if
this
comes
back
to
the
you
know,
we're
talking
about,
in
some
cases
providing
tools
to
make
runtime
contract
changes
right
for
like
artifact
tracing
but
being
really
explicit
about
them.
D
I
think,
if
we're
going
to
use,
if
we're
going,
to
assume
ready
true
in
order
to
do
visualization
or
in
order
to
like
give
users
a
better
indication
of
what's
happening,
that
seems
reasonable.
But
if
we're
going
to
assume
ready
true
to
make
you
know
runtime
contract
changes,
then
I
feel
like
that
needs
to
be
more
explicit
right.
D
I
don't
have
a
solution
there.
I
just
thought
it
was
interesting.
You
know
the
what
you're
going
to
use
the
data
for
you
know
determines
whether
how
comfortable
you
are
maybe
making
the
default.
A
I'm
hoping
that's
a
segway
into
one
of
my
concerns
about
this
rfc,
but
I
just
want
to
check
if
anyone
else
has
anything
else
they
want
to
discuss
before
I
take
my
shot,
I
mean
I
really
like
this
one.
I
do
actually
have
a
question
before
I
talk
about
my
concern.
Is
there?
Did
you
guys
derive
this
from
somewhere
because
there's
no
prior
art
written
on
this,
but
I
was
wondering
if
you
took
inspiration
from
some
place
or
another
on
how
these
choices
were
yeah.
The
design
of
the
crd
for
matching.
H
Yeah,
I
think
we
I
mean
we
really
tried
to
just
start
from
no
prior
art,
and
then
we
thought
about
you
know,
options
and
how
we
added,
like
the
selectors
there,
and
this
felt
kind
of
similar
to
that
and
then
upon
like
talking
further
with
zero
on.
This
ciro
showed
us
some
really
old
prior
art
and
we
were
pretty
close
actually
to
what
was
originally
designed.
A
A
F
C
F
Not
like
level
triggered
resources
right.
C
I
A
Sometimes
an
idiom
exists
that
we
haven't
taken
the
time
to
go
and
find
that's
all
right.
Let's
see
if
we
match
up
with
it,
I
like
this
design,
but
it
feels
yeah.
It
feels
first
principles,
which
is
often
good,
but
I
was
just
wondering
if
there
was
something
else
that
already
sort
of
reflected
this
thinking
out
there
I
mean
I'm
not
too
worried.
I
don't
think
we're
going
to
like
collide
with
other
people's
preconceived
notions,
because
there's
not
a
lot
of
this,
but
that's
why
I
brought
it
up.
G
H
Weight
rules
when
doing
this,
I
forget,
like
our
complete
conclusion
on
that
marty,
we
found
them
difficult
to
read
first
of
all,
and
they
only
deal
with
conditions,
I
believe,
and
they
don't
deal
with
match
with
fields
right.
We
did
look
at
these
and.
B
Both
those
things
are
true
and
also,
it
seems
very
hard
to
reason
about
when
you
try
to
get
when
you
have
multiple.
You
know
multiple
conditions,
because
you
have
to
like
visually
kind
of
figure
out
failure
like
aggregate
all
the
failures
and
successes.
I
guess
I
don't
honestly
don't
fully
know
how
they
parse
these,
but
yeah.
It
seemed
hard
and
especially
when
we
wanted
to
add
field
matching
and
we
and
like
to
name
it
condition
matches
when
we
already
have
match
fields
match
selector.
I
If
you
had
a
resource
matcher
of
what
resources
a
specific
rule
creates,
and
then
anyone
that
created
templates,
you
don't
necessarily
need
to
add
a
ref
to
the
weight
rule,
because
a
techton
task
always
has
the
same
status.
So
anyone
that
wants
to
add
any
resource
into
a
supply
chain
or
into
a
template
could
simply
create
these
and
then
there's
no
referencing.
I
That
needs
to
happen.
So
if
they
don't
exist,
it
just
defaults
to
we're
not
going
to
look
for
status,
but
there's
no
built-in
dependency
on
having
those
crds
in
a
cluster.
You
get
more
visibility
if
you
have
them,
but
they're,
not
hardly
coupled
that
you
need
another
resource
in
order
for
the
template
to
be
imported
and
work
in
the
cluster.
B
You
know,
get
that
resource
rule
and
we
decided
against
that,
because,
with
yct
and
even
in
regular
templating,
as
scott
pointed
out,
the
api
version
and
kind
of
the
resource
being
stamped
out
can
be
templated
as
well,
and
so
it
would
be
very
hard
to
know
just
by
looking
at
the
template
what
rule
will
be
applied.
C
B
E
The
other
issue
is
because
the
script
resource
like
they
can
only
be
defined
once
in
the
cluster,
so
that,
if
you
have
especially
if
you're
using
cap,
if
you
have
multiple
apps
trying
to
define
the
same
resource,
then
it's
basically
the
first
claim
wins
and
everything
else
will
just
bounce
off
later.
G
Yes,
absolutely
cool,
so
there's
this
question
of
like
healthy
and
unhealthy,
and
I
sort
of
wonder
like:
is
there
any
value
in
it's
almost
like?
What
we're
doing
here
is
something
that
could
be
sort
of
generalized
right,
like
aggregate
statuses,
to
a
thing
right.
Would
there
be
value
in
saying
that,
like
we
let
template
author,
the
supply
chain,
author
pick
the
status
and
further
we
make
it
so
that
it's
not
just
this
one
special
thing:
it's
just
something
you
can
do.
G
You
can
aggregate
data
off
of
off
of
your
underlying
resource
into
you
know
more
than
one
of
these
types
of
sort
of
summary
values.
H
Allowing
template
authors
to
determine
it's
an
array
of
statuses
and
they
can
call
the
status
whatever
they
want,
and
if
we
can
determine
you
know
a
status
to
be
successful
or
meet
all
the
criteria.
Then
we
could
promote
that
that
state
of
whatever
you
know
they
want
to
call
it.
It
gets
a
little
bit
more
complicated
with
the
ands
and
the
oars
and
deciding
you
know
how
you
want
to
determine
what
makes
that
status
or
that
state
fulfilled
and
there's
no
limits
across
like
we
had.
B
C
A
Exists,
I
the
thing
I
actually
wanted
to
discuss
was
the
I've
been
working
on
the
information
architecture,
view
of
a
workload?
Can
I
share
screen
real,
quick
marty,
because
I
this
leads
into
the
one
that
I
actually
wanted
to
ask,
which
was
imagine
we're
inside
a
workload
here.
Sorry,
this
is
just
a
snippet
of
information,
but
I
was
thinking
that
in
a
workload
under
resources
where
we
list
them,
oh.
A
It
might
be
a
builder
or
something
like
that
that
the
status
of
a
stamped
this,
I
think
you
currently
call
stamp
status.
B
A
Status
what's
well,
it's
a
fair
thing
that
there's
what
it's
called,
but
what
I
I
figured
looking
at
this
from
a
person
viewing
the
workload
with
a
lot
of
denormalized
information
about
the
entire
system,
and
that's
what
we're
trying
to
do
here
is
help
people
understand
what
the
state
of
the
system
is
via
the
workload
that
we
probably
want
an
overarching
condition
like
ready.
We
probably
should
reference
for
each
resource.
This
is.
We
should
probably
reference
whether
the
submission
step
has
worked
or
not.
A
There's
a
lot
of
events
there
that
we'll
be
generating,
but
there's
also
information
that
should
be
there.
I'd
like
to
also
be
able
to
reference
whatever
the
status
is
that
came
out
of
this
particular
rfc,
which
led
me
to
just
ask
like:
is
there
a
way
that
we
could
make
this
more
idiomatic,
because.
A
Because
a
status
is
usually
true,
false
and
unknown
when
it's
in
a
condition.
I
know
this
is
outside
of
that,
but
the
healthy
unhealthy
also
doesn't
feel
entirely
idiomatic.
I
was
wondering
if
it
could
be
a
top
level
for
the
stamp
status
conditions.
That's
you
know
one
kind
that
goes
in
there
that
represents
idiomatically
and
as
a
condition,
the
result
that
you
saw
from
all
the
other
fields
or,
if
you've
thought
about
that.
B
C
B
But
that's
like
seems
pretty
separate
from
this
rfc.
I
think,
like
line
14
having
a
status
be
true,
false
or
unknown,
doesn't
really
make
sense
right
in
a
condition.
The
status
of
the
condition
type
is
true
or
false,
like
ready
is
false,
not
status,
it's
false
right,
and
so
you
can't
say
static
like
saying
it's
not.
A
Honest,
I
do
understand
what
you're
saying
I
guess
what
I'm
thinking
is.
If
I
was
to
implement
this,
this
would
be
the
stamp
conditions
or
stamp
status
or
whatever
we
want,
which
literally
references
this
and
then
I
need
a
value
here.
We'd
have
to
do
a
translation
at
this
point.
We'd
go
healthy,
equals
true,
unhealthy
equals
false
unknown
equals
unknown.
A
I'm
just.
I
know
it's
a
bit
forward
thinking
and
it's
not
just
within
the
scope
of
this
spec,
but
I'm
jumping
in
early,
so
that
we
could
come
up
with
something
that
looks
like
a
list
of
conditions.
Scott
you've
got
your
hand
up
too,
so
I
don't
want
to
hold
you
up
for
too
long.
B
E
I
originally
raised
my
hand
to
respond
to
something
zach
said
earlier,
but
rash.
The
comments
you're
making
here
are
almost
a
one-to-one
comment
I
put
on
the
rfc
this
morning.
Okay,
I
I
totally
agree.
E
E
So
I'd
really
like
to
see
some
way
to
actually
unify,
so
that
there's
like
one
outward
facing
consistent
user
experience
in
terms
of
how
this
information
gets
displayed.
E
So
a
straw
man
I
put
up
as
a
way
to
do
that
was
basically
just
eliminate
stem
status
and
replace
it
with
basically
resource
conditions.
What
rash
was
just
showing
and
one
of
those
conditions
could
be
healthy
and
then
the
message
inside
of
that
condition
and
the
reason
of
that
condition
can
then
have
that
more
richer
detail,
but
that's
a
straw,
man
proposal,
although
it
definitely
aligns
with
what
we
were
just
discussing.
A
A
Yes,
I
can't
I
can't
find
it
anymore
for
some
reason,
I
did
find
it
to
put
my
hand
up,
but
now
I
can't
take
it
down
anyway,
the
that
that's
why
I
had
to
come
from
this,
this
external
view
of
of
what
the
rsc
is
trying
to
deliver
in
terms
of
what
we
present
to
users.
I
definitely
want
that.
A
I
wasn't
going
to
be
mean
scott,
because
my
concern
is
that
that
there's
multiple
matches
that
could
happen
and
we've
had
this
problem
before,
like
it's
quite
noticeable
here
in
a
workload
you
see
the
resources
submitted
status,
we
only
show
the
first,
possibly
multiple
failing
ones,
so
that
one
to
many
mapping
into
a
condition
hides
information,
and
I
was
glad
that
we
finally
had
per
resources
space
that
we
could
put
that,
so
we
could
have
one
for
each
place
that
it
failed,
and
now
we've
got
that
same
issue
again
for
the
status.
A
E
So,
like
maybe
you
just
concatenate
the
two
together,
maybe
you
define
like
a
little
prefix
before
the
string.
There
are
ways
to
do
it.
Like
you
have
I
mean
messages
are
intentionally
very
long
and
free
form,
so
you
can
kind
of
do
whatever
you
need
to
do,
but
putting
some
structure
around
it
would
be
nice,
but
avoiding
the
need,
for
that
would
be
even
better.
A
E
Yeah,
there's
definitely
going
to
be
cases
where
you
will
need
to
match
multiple
conditions
or
multiple
fields
so,
like
that
still
needs
to
exist.
It's
just
a
matter
of
how
do
you
aggregate
the
message
when
that
happens,
I
think
that's
places
where
we
have
room
and
flexibility,
but
in
many
cases
I
think
there
will
be
a
single
resource
or
a
single
field
producing
a
message
that
we
actually
care
about.
A
A
So
next
up
is
simplify
runnable
usage.
This
was
discussed
last
week.
I
just
wanted
to
see
if
anyone
wanted
to
discuss
anything
further
from
this,
no
one
else
has
added
anything
to
the
board,
so
I
just
brought
forward
what
was
up
last
week,
I
says:
simplify
runnable
usage.
A
The
using
runnable,
inline
and
I've
seen
a
lot
of
discussion,
that's
gone
on
in
here.
I
don't
know.
If
anyone
wanted
to
talk
about
this,
unfortunately
washroom
is
not
present,
so
it
may
not
be
terribly
helpful,
but
was
there
anything
that
anyone
wanted
to
mention
on
this
today.
A
A
D
A
So
now
we
do
actually
have
a
little
bit
of
time,
a
space
for
show
and
tell
if
anyone
cares
to
does
anyone
want
to
talk
about
anything
they've
been
doing
this
week?
That
might
be
useful.
Is
this
discussion
point?
A
Oh
sorry,
that's
true.
I
forgot
about
that
one
I
put
it
there
myself
and
I
forgot
about
it.
Thank
you
co-hosting.
That's
why
we
pair
should
we
add
work,
describe
possible
secrets
and
sensitive
information
in
our
logging.
A
This
is
this
is
a
difficult
thing.
It
will
slow
the
system
down
if
we
start
to
scrub
secrets,
but
we
do
log
a
lot
of
a
lot
of
information,
usually
information
that
we
pull
from
error
messages,
but
I
think
there's
a
risk
for
there
to
be
secrets
in
some
spaces.
A
We
often
log
errors
that
were
raised
by
internal
tools,
so
we
do
wraps,
you
know,
percent
w
all
the
way
down.
A
So
I
can
only
guess
that,
especially
when
we
try
to
apply
a
template
if,
if
something
mentioned,
the
content
of
the
template
or
the
partially
applied
api,
call
that
there'd
be
information
about
the
resource
or
there's
no
there's
certainly
not
been
any
alternative
to
this,
which
would
be
make
sure
when
you're
logging
errors
that
they
can't
possibly
be
errors.
That
would
be
raising
sensitive
information.
I
guess
that
could
be
the
other
way
you
could
resolve
this,
but
yeah
I
haven't
seen
us.
Try.
D
There
shouldn't
be
places
where
we're
putting
secrets
into
the
api
server
outside
of
a
secret
resource
right,
and
so
you
know,
if
we're
logging,
you
know
things
that
are
coming
from.
You
know
at
cd
we
shouldn't
be,
or
we
should
be
careful
not
to
log.
The
contents
of
you
know,
capital
s,
secrets
right.
Is
it
maybe
you're
worried
about
when
we
read
those
values
and
then
pass
them
to
go?
Libraries,
for
example,.
C
A
A
I
mean
I
mean
it's
possible
that
what
just
I
mean
also,
first
of
all,
there's
the
word
secret,
which
tends
to
like
glommer
around
things
that
are
specifically
known
to
be
information.
You
don't
want
shared
and
then
there's
sensitive
information,
which
is
just
information
that
people
don't
necessarily
want
to
have
turning
up
in
their
logs
about
what
what
is
currently
happening
at
a
particular
place.
I
haven't
thought
deeply
about
this.
I
just
recognized
that
we
haven't
done
any
analysis
of
security
here
when
it
comes
to
those
secrets.
A
A
Here's
the
string-
oh
that
just
happens
to
have
secrets,
because
someone
put
that
in
the
config
map.
This
is
imagination,
not
not
concrete
examples.
This
is
what
I
was
concerned
about
being
possible
again.
We
we
work
with
untyped
a
lot
of
untyped
data
or
not
strongly
typed.
The
config
comes
back
as
a
string.
We
validate
that
it's
a
valid
yaml
string,
but
that
that
can
easily
be
something
that's
still
problematic.
A
Right,
I
see
what
you
mean,
use
cases
where
users
of
cartographer
are
likely
to
do
that
kind
of
thing,
not
that
I
know
of
zero,
maybe
even
scott
rosenberg
could
consider
might
have
more
real
world.
F
Sorry
I
was
going
to
say
the
only
use
case
I
can
think
of
is
a
secret.
That's
like
a
placeholder!
That's
going
to
take
some
data
later
on,
like
how,
with
the
grid
j
and
you
can
have
like
those
placeholder
secrets
for
getting
like
registry
credentials
that
I
could
think
of
or
something
insert
manager
related
true.
F
But
then
again
in
that
case,
like
there's
no
data
there
it's
well,
there
is
until
there
is,
I
mean
there
isn't
so
there
is,
but
then
cartographer.
I
I
think
the
one
other
use
case
there
may
be
a
secret
is
is
if
someone's
resource
was
an
app
a
cap
app
or
anything
like
that
and
to
pass
in
values.
You
do
a
secret
ref,
so
they
may
be
stamping
out
a
secret
in
order
to
add
in
values.
It's
not
really
a
secret,
I
it
is,
and
it
isn't
it's
a
data
values
file,
but
you
know
they're
using
secrets.
I
Badges,
I
think
that
may
have
been
added.
I
think
that
was
added
in
0
32
of
cap
controller.
There
is
no
like
config
map
ref.
I
think
also,
if
I
remember
correctly,
but
still
all
the
examples
out.
There
are
secret
ref
in
cap
controller
and
that's
kind
of
become
a
de
facto
standard
in
that
tooling,
for
good
or
for
bad.
E
E
There
are
secrets
that
cartographer
has
primarily
the
service
account
that
it's
operating
under
and
the
service
account
that
it's
creating
api
requests
for?
I'm
not
super
concerned
about
user
resources
because
again,
like
stamping
out
a
secret's
kind
of
weird
and
stamping
out
credentials
onto
a
resource.
That's
not
a
secret
is
also
like
an
anti-pattern
but
like
it's
that
resources
problem
at
that
point
because
they're
the
one
violating
the
norms,
but
in
terms
of
cartographers
own
secrets,
like
I
think,
like
those
are
things
that
should
definitely
never
be
logged.
A
So
there
could
be
an
action
item
to
make
sure
that
where
we
interact
with
those
secrets,
we're
not
in
a
situation
where
we
might
hit
an
error
that
can
surface
it,
it's
really
all
I'm
thinking
of.
When
I
talk
about
logging
right,
we
don't
tend
to
log
values,
specifically,
we
tend
to
say
well,
here's
an
error
from
an
api
or
a
third-party
library.
A
A
And
then
there's
the
so
I
mean,
I
guess
really
all
I
was
wondering
was:
would
people
have?
Is
it
a
reasonable
expectation
that
we
would
always
scrub
logs
before
we
admit
them
all
right?
I'm
not
sure
that's
true,
but
I
just
wanted
to
ask
the
question.
A
D
C
D
Don't
you
know
because
those
concourse
instances
are
often
used
by
open
source
projects?
The
output
is
public
and
you're
have
a
lot
of
different
tasks,
and
you
know
like
that
extra
level
on
top
was
useful.
I
I
think
you
know
concourse
did
that
because
of
the
use
cases
people
had
for
concourse
that
you
know
drove
that
to
be
a
problem
right.
D
I
you
know,
I
I
don't
know
if
it's
a
common
enough
pattern
in
a
kubernetes
controller,
that's
more
where
the
controller
logs
are
more
around
something
an
internal
operator
would
look
at,
and
that's
not
kind
of
made
public
and
external
right
that
it
justifies.
You
know
that
same
kind
of
solution
to
the
problem,
at
least
at
this
point
would
be
my
my
gut
right.
A
Absolutely
yeah,
okay,
so
I
think
that's,
I
think,
that's
pretty
much
all
of
the
items
here.
There
is
a
draft
for
events,
but
it
is
a
draft,
so
I'm
going
to
take
it
out
of
there
and
I
will
present
it
next
week
when
I've
got
it
finished
and
I
might
even
save
my
show
and
tell
for
our
next
team
meeting.