►
From YouTube: Cartographer Community Meeting - April 6, 2022
Description
00:00 Intro
00:40 New faces
01:54 The TL;DR
11:15 Template options using best match
15:35 ROADMAP discussion
For more details please check the meeting notes here: https://docs.google.com/document/d/1HwsjzxpsNI0l1sVAUia4A65lhrkfSF-_XfKoZUHI120/edit?usp=sharing
A
Hello,
everyone
welcome
to
the
cryptographer
community
meeting
now
in
every
other
week.
Cadence
and
the
goal
of
this
session
is
to
share
updates
and
what's
new
in
the
project.
The
discussion,
some
other
stuff
that
that
matters
to
the
community
feel
free,
tell
yourself
that
in
this
list
and
also
your
affiliation
any
new
faces.
I
I
don't
know
if
him,
if
even
matt,
if
this
is
your
first
time
in
this
meeting,
feel
free
to
introduce
yourselves.
B
Yeah
yeah.
This
is
definitely
my
first
time
I
think
so
for
matt
as
well
hi,
I'm
tim.
I
work
at
vmware.
I
involved
a
lot
with
the
cloud
foundry
side
of
things
and
our
cf
on
kubernetes
efforts.
I'm
here
just
to
learn
more
about
what's
going
on
with
cartographer
and
particularly
around
what
y'all
are
doing
with
the
better
status
visibility,
because
we're
we're
interested
in
that
stuff.
So,
okay.
C
Hey
sorry,
I'm
on
my
phone
because
my
my
work
laptop's
having
some
internet
trouble
at
the
moment
yeah
I
work
with
tim,
also
on
cf
on
kate's,
and
I'm
I'm
here
for
basically
the
same
reason:
we're
we're
thinking
about
using
cartographer
and
there's
some
features
we'd
like
to
talk
about
that.
You
proposed.
A
Yeah
feel
free
to
add
whatever
you
would
like
to
discuss
to
add
it
directly
open
mind
discussion
section,
so
we
can
okay
yeah.
Thank
you
all
right.
Well,
the
tldr.
What's
in
the
project
this
week?
Well,
several
things,
but
one
that
I
wanted
to
note
here-
is
the
tutorials
team
work
on
having
a
set
of
step-by-step
tutorials
that
really
take
you
from
ground
zero.
To
start
you
know,
building
supply
chains
and
using
some
features
of
photographer.
A
I
find
it
really
easy
to
follow
and
yeah.
They
are
amazing,
but
we
know
we
could
do
even
better.
So
we
will
ask
you
to
use
the
tutorials
and
if
you
could
lend
us
some
minutes
from
your
time,
we
would
like
to
have
a
conversation
with
with
you
on
feedback,
getting
your
feedback
on
tutorials
and
documentation
and
in
exchange
for
your
valuable
time
we
are
giving
you
a
bundle
of
cartographer's
slack.
A
A
A
A
A
You
musa
due
to
time
zone
constraints,
he
couldn't
join,
but
he
is
he's
a
field
engineer,
as
you
know,
sales
engineer
at
vmware
and
he
worked
autonomously
in
a
proposal
that
got
accepted
for
kubecon
europe,
where
he
will
present
and
demo
cartographer
there
and
that's
you
know,
that's
amazing,
because
this
conference
had
an
acceptance
rate
of
19
percent.
I
mean
for
every
52
proposals.
A
Only
one
got
accepted,
so
the
work
that
benoit
did
was
was
amazing
and
we
wanted
to
recognize
you
when
weed
and
we'll
do
also
a
public
shout
out
on
social
media
and
and
will
ship
you
nice
sought.
So
you
can
show
your
pride
for
the
project
at
kubecon
awesome
all
right.
What
team
is
working
on
a
lot
of
stuff
right?
Does
anyone
want
to
share
about
work
on
rfcs.
E
E
D
E
A
C
Yeah
I've
been
keeping
up
with
it.
I
think
I
it
looks
good
to
me.
I
know
there's
a
lot
of
discussion
around
the
structure
of
it.
I
don't
really
have
a
strong
opinion
either
way.
I
think
the
biggest
thing
that
we
are
looking
forward
to,
though,
is
just
knowing
the
success
or
failure,
status
or
health,
or
of
each
of
the
resources
that
stamped
out
so
just
excited
about
the
the
idea.
Generally.
A
A
D
Yeah
so
you'd
be
able
to
show
the
new
site
repository.
Most
people
won't
be
able
to
see
this
yet
as
it's
still
marked
private,
but
it
will
be
public
very
soon.
Contributions
to
the
documentation
and
the
website
will
be
in
a
separate
repository
now
much
faster
to
go
through
sanity
checks
separating
out
from
the
code
and
that's
close
to
landing.
We're
just
waiting
on
approval.
A
A
Any
comment
comments
I
mean
I
found
this
once
it's
public.
We
hope
folks
find
it
not
only
useful,
but
you
you
may
contribute
to
it
the
core
principles.
As
I
understand
this
is
basically
to
define
what
cartographer
does
what
what
the
main
goals
the
main
issues
it's
designed
to
address
and
what
it
doesn't
do
is
that
correct.
G
H
Slash
delivery
level,
though,
I'm
concerned
that
it's
not
the
best
approach
at
the
template
level
because,
like
just
like
a
bad,
like
example,
off
the
top
I
head
like.
If
you
had
one
template
that
you
want
to
go
for
whenever
it's
source.git,
you
only
need
one
match
fields
to
express
that.
But
if
you
had
another
temple
option
that
you
know
you
only
want
to
you
know
you
have
a
second
one,
that's
like.
H
F
D
I
think
the
reason
I
like
it
the
way
it's
implemented,
and
this
is
like
ad-hoc
reasoning,
but
the
reason
I
like
it.
The
way
it's
implemented
is
because
it
is
exactly
the
same
as
top
level
matching,
so
you
can
reason
about
them.
The
same
way,
that's
not
the
greatest
argument
if
it
introduces
a
really
bad
user
experience,
but
I
like
it
for
that
reason,.
H
Yeah,
I'm
not
suggesting
it's
necessarily
wrong,
just
wanted
to
call
it
out
because
it
wasn't
the
rfc
that
added
these
options
was
not
explicit
about
this,
and
I
think
we
had
all
kind
of
assumed
it
wouldn't
be
met
best
matching,
and
then
it
was
kind
of
accidentally
made
into
best
matching,
and
maybe
that
was
a
good
thing.
But
I
wanted
to
call
it
out
and
make
sure
we
all
agreed
on
that.
A
I
I
I
J
I
I
I
I
D
Sure
under
trolls
I've
got
to
reduce
duplication
and
core
code.
We've
got
some
duplication,
that's
annoying
us
we
now,
even
before
we
get
to
a
new
rfc
for
blueprints,
I
think
we
can
use
new
generics
to
or
just
better
abstractions
to
clean
some
of
that
up.
It's
just
some
some
code
improvements.
I
think
we
can
do
and
some
instructions
we
can
build.
D
D
I
I
A
H
Just
allowing
the
templates
to
kind
of
define,
define
status
of
the
the
resources
that
they're
stamping
out,
so
that
those
can
be
reflected
on
the
workload
and
users
can
kind
of
go
to
the
workload
to
get
the
source
of
truth.
For
all
the
resources
that
have
been
created
by
the
blueprint
rather
than
having
to
like
go
use.
Some
external
tool
or-
or
you
know,
use
cubecuttleget
on
every
single
resource
to
find
the
information
they
most
likely
care
about.
I
J
C
K
K
F
I
know
in
the
past
we've
talked
about
the
idea
that
there
there
might
be
other
objects
in
the
cluster
that
the
supply
chain
probably
wants
to
know
about,
but
isn't
actually
responsible
for
stamping
out
directly.
So,
like
you
know
like
even
something
as
simple
as
like
a
secret
that
I
might
use
and
that
my
whole
supply
chain
relies
on
but
like
the
supply
chain
has
no
knowledge
about
it,
and
so
maybe
even
just
like
watching
these
objects
for
changes
could
be
related
to
that.
But
I'm
not
sure
either.
To
be
honest,.
K
Yeah,
I
remember
this
being
a
big
deal
in
regards
to
runable,
where
we
have
the
like
selector
field
in
the
spec.
So
I
guess
the
suggestion
there
was
like.
Oh,
we
could,
let's
say
I'm
a
kpac
image
and
I
make
use
of
a
service
account
and
I
can
like
keep
track
of
changes
to
that
service
account
or
I
don't
know
the
secret
attached
to
it
and
then
reconcile
if
that
changes.
Okay,.
I
L
F
I
F
G
F
I
Yeah,
I
think
I
think
most
of
us
do.
I
think
these
are.
These
are
ver
very
rough
ideas
that
have
been
shared
or
or
the
the
that
are
out
there
in
the
in
the
ether
from
our
from
some
of
the
technical
leaders
so
yeah
I
I
certainly
can't
speak
to
them
and
maybe
maybe
without
them
being
here
it
doesn't
make
sense
to
dive
into
it,
but.
H
K
As
an
adopter,
I
really
really
I
see
that
coming
like
it's
super
super
helpful,
even
just
troubleshooting,
like
figuring
out,
oh,
like
did
anything
even
change
for
this
particular
resource
that
I'm
looking
at
right
and
like
if
it
did
when
was
that
like?
Is
it
changing
every
10
seconds?
Is
it
not
or
gc
right
like
when
we
switch
from
one
let's
say:
selecting?
Is
one
supply
chain
selects
against
another,
now
being
the
like?
Oh,
these
objects
got
deleted
by
gc
because
so
far
it
can
be.
K
J
Cool
yeah.
I
would
also
second,
that
of
being
able
to
understand
the
history
of
you
know
why
something
happened
or
what
the
kind
of
history
of
the
workload
is
through
the
events.
But
I
think
the
other
part
that,
for
me,
events
would
be
helpful
with
is
there
are
certain
integrations
that
can
be
done,
especially
around
monitoring
that
do
a
much
better
job
with
doing
that
with
events
than
do
with
just
following
the
status.
J
Possibly
so
the
events
could
be
an
easy
way
of
doing
possibly
things
around
artifact
tracking,
possibly
different
data
that
could
be
thrown
into
events
that
don't
bring
you
so
close
to
the
maximum
size
of
a
cr
in
kubernetes.
That
would
not
be
fun
to
reach.
So
I
think
that
it's
a
beneficial
thing
there
as
well.
D
D
H
D
H
Like
the
adopters,
like
what
information
we
feel
we're
missing
and
like
what
information
do
you
like
sky,
like
you,
mentioned
those
outside
tools
that
can
make
decisions
off
of
these
events?
Like
what
types
of
events
would
you
anticipate
making
a
decision
off
of,
because
I
think
rash's
rfc
did
a
really
great
job
listing
out
a
bunch
of
really
potentially
really
useful
events.
H
But
it's
very
hard
for
me
to
say,
like
which
one
of
these
are
actually
useful
and
an
adopter
developer
would
actually
care
about
and
rash
has
a
really
long
list
and
like
it
might
be
like
if
we
just
emit
all
of
them
from
the
start.
That
might
be
useless
because
there's
too
much
there
and
it's
too
hard
to
get
your
actual
useful
data,
and
I
would
love
to
see
some
actual
feedback
from
people
about
which
ones
they
really
care
about.
D
I
I
K
G
I
I
Fine,
okay
and
we're
just
about
a
time
here
so
looks
like
some
people
are
phil's
still
finishing
up,
which
is
great,
but
I
think,
for
the
sake
of
time,
we'll
just
get
started
here.
I'm
gonna
focus
on
some
some
adopters
contributors
to
start
dave
walter.
Would
you
like
to
share
a
little
bit
about
your
your
prioritized
list?
Sure.
M
I'll
get
to
my
video,
I
prioritized
the
the
two
shows.
First,
just
because
I
feel
like
paying
down
technical
debt
is
important.
Making
the
code
more
maintainable
and
extendable
feels
like
a
good
thing
to
target
on
first
before
we
embark
on
new
new
features.
Personally,
I'm
always
a
fan
of
improved
release
processes.
So
I
put
that
high
on
the
list.
M
The
first
feature
that
I
I
looked
at
was
the
surfacing
areas
up
to
the
workload
so
that
we
can
just
say:
okay,
we've
created
the
workload.
That's
the
thing
we're
going
to
look
at
to
figure
out
where
the
problem
is,
if
something's,
not
if
a
resource
hasn't
been
created,
the
way
we
expect
it
to
have
been.
M
M
I
think
that
the
big
thing
that
stuck
in
my
mind
was
we
were
we
kept
being
told
about
deliverables
and
deliveries,
but
there
were
no
examples
of
that
and
all
of
the
examples
just
used
templates,
and
so
it
was
very
hard
to
figure
out.
Oh
okay,
well
we're
supposed
to
be
using
this
thing,
but
we
have
no
idea
how
to
use
it,
and
I
know
matt's
done
a
lot
more
digging
into
that
than
I
have.
But
that
was
just
my
recollection
from
when
I
did
the
spike
on
this.
C
Sure
yeah,
so
I
kind
of
just
prioritized
in
terms
of
what
the
features
that
are
either
blocking
the
use
case.
We
have
in
mind
or
would
be
most
useful
for
it,
so
the
one
that's
actually
blocking
us
is
not
having
the
success
or
failure,
status
or
health,
the
unhealth
status
on
the
workloads
for
the
stamped
resources,
so
that
was
my
top
and
then
the
rest
below
this
are
either
would
be
useful
for
maybe
allowing
us
to
add
additional
features
on
top
of
cartographer
or
in
like
having
visibility
for
users.
C
C
Similarly,
I
don't
think
we
have
any
feature
needs
for
the
events,
but
I
think
just
in
terms
of
debugging
and
understanding
the
state
of
a
workload,
the
events
would
be
incredibly
helpful,
as
others
have
said,
and
then
just
yeah.
I
think
the
cartographer
is
very
complicated
and
I
think
that
and
anything
we
could
do
to
simplify
and
make
the
docs
a
little
easier
to
approach
would
be
help
really
helpful
for
for
new
users.
C
J
I
J
Yeah,
so
for
me,
I
think
definitely
the
surfacing
of
status
and
errors
to
the
workload
is
by
far
number
one,
because
that's
key
for
a
lot
of,
I
think
end
users.
I
think
publishing
kubernetes
events
will
just
open
up
a
lot
of
options
and
makes
debuggability
much
easier
patching.
The
live,
editor
options.
I
would
love
that
because
I
use
the
live
editor
for
all
the
supply
chains
that
I
build
and
I
build
two
or
three
a
week.
J
Different
ones
so
having
it
with
options
will
be
awesome
now
that
I've
started
to
use
them
and
artifact
tracing,
I
think,
is
a
really
nice
thing
to
have
as
well.
Maven
artifacts,
I'm
starting
to
see
people
really
looking
into
that,
and
not
necessarily
just
nathan,
but
overall
passing
in
you
know
whatever
artifacts
into
cartographer,
I
think
will
be
great.
J
I
do
think
that
the
simplifying
of
the
architecture-
and
my
guess
is
that
that's
referring
to
the
runnable
cluster
run
template
being
generated
automatically.
That
was
talked
about
in
previous
meetings.
I
think
it's
nice,
I
personally
have
gotten
so
used
to
building
out
the
cluster
run
templates
and
everything
that
it's
not
that
difficult
for
me
to
understand
anymore,
but
I
can
understand
why
it
is
for
people,
so
that
would
be
a
nice
thing
to
have
and
the
out
of
the
box
supply
chains
for
tc.
J
I
have
my
own
out
of
the
box
supply
chains,
so,
like
I'm
cool
with
that,
but
I've
heard
that
from
a
lot
of
tce
users
of
app
toolkit
and
cartographers,
I
think
adding
that
in
will
just
gain
more
usage
in
the
open
source
community
of
cartographer,
which,
in
the
end
just
brings
more
people
in,
I
didn't
add
anything
around
docs,
because
I
don't
use
docs.
I
learn
from
breaking
things.
So
that's
why,
to
me
less
important
and
as
a
non-maintainer
other
things
also
become
less
important
to
myself.
J
D
J
B
B
I
D
Okay,
can
I
quick
ask,
please,
can
we
please
maybe
start
a
discussion
on
the
kinds
of
problems
we're
trying
to
solve
or
something
like
out
of
band
of
here,
but
one
of
our
struggles
creating
documentation
is
oh,
we
could
describe
a
myriad
things
you
might
want
to
try
and
solve.
We
can't
write
that
many
docs
and
it
would
be
a
library,
so
we
need
to.
B
Yeah,
that's
totally
fair
and,
like
I
think,
our
team,
our
problems
are
kind
of
niche,
but
I'm
just
like
thinking
of
like
onboarding
new
users
like
problems
like
hey,
I
want
to
like
sign
my
images
like
this
is
how
I
would
like
make
a
supply
chain
to
do
so,
something
that
like
makes
it
more
discoverable
from
from
that.
Like
perspective,
yeah.
D
J
I
think
that,
from
my
perspective
in
docs,
it's
less
so
I
think
the
tutorials
first
of
all
made
a
huge
improvement
to
the
docs.
So
that's
really
important.
I
think
that
docs
overall,
that
I
find
the
most
useful
are
not
the
ones
that
actually
say
how
to
do
something,
but
how
to
approach
it
and
those
docs
are
the
hardest
ones
to
write
but
they're
by
far
the
most
beneficial
and
also
stay
relevant
over
time.
J
So,
instead
of
building
out
a
full
solution,
it's
talking
about
how
you
would
decide
to
use
something
or
how
you
would
approach
a
situation:
how
to
build
a
supply
chain.
Theoretically,
almost
not
necessarily
going
down
into
the
bits
and
bytes
of
writing
it
and
things
like
that,
but
how
you
would
actually
logically
build
out
your
supply
chain
before
actually
going
to
the
project
itself,
so
that
you
have
the
data
so
that
when
you
go
to
build
the
supply
chain,
it's
easier,
so
kind
of
a
higher
level
above
the
actual
nitty-gritty.
B
And
I
I
realize
maybe
what
I'm
actually
thinking
of
is
more
like
almost
like
marketing
or
blog
post,
or
something
just
something
that
helps
people
know
that
that
have
a
problem,
but
they
don't
know
anything
about
cartographer
that
they
can
discover
it
and
like
learn
like
this
is
how
I
can
solve
my
problem
with
it.
It's
just
like
that's
that's.
The
sort
of
thing
that
I
feel
like
is
is
missing.
From
the
current
like
set
of
docks
and
and
things
we've
got
out
there.
I
D
It's
something
that
I
would
like
to
communicate
to
the
community
that
they
are
welcome
to
submit
blog
posts
to
the
cartographer
site.
I
think
community
contributions
on
the
cartographer
website
would
be
welcome
as
well,
if
no
one
wants
to
host
their
own
blog
posts,
otherwise
we'll
link
to
them
in
the
resources.
I
E
L
Yeah,
so
I
yeah,
I
feel
the
the
wands
for
the
the
surfacing
areas.
That's
why
I
had
that
there
I
put
blueprint
architecture
and
api
evolution
higher,
because
I
feel
like
the
cost
of
doing
those
things
later.
Just
it's
going
to
increase,
and
you
know
we
have
more
people
adopting
that's
going
to
be
like
more
ripple
out
kind
of
effect,
and
I
kind
of
feel
like
it's
a
good
lead
up
to
doing
before
reducing
other
duplication
in
code.
But
that's
just
my
feeling.
Artifact
tracing
yeah
lots
of
people
want
it.
I
I
A
I
I
think
the
next
step
here
is
that
we
want
to
right
write
some
kind
of
a
a
readme
or
a
blog
post
that
just
describes
some
of
these
things.
We're
planning
to
do
in
the
next
quarter,
so
to
give
a
you
know,
list
these
out
and
give
a
line
or
two
on
each
of
them,
as
well
as
some
of
the
things
we're
thinking
about
in
the
future,
linking
to
the
rfcs
asking
for
more
feedback.