►
From YouTube: Cartographer community meeting - Oct. 27th 2021
Description
Community meetings happen each Wednesday at 8:00 AM PT/11:00EDT
See the agenda here (https://bit.ly/2Z67z08), add any topic you may want to discuss and join us live!
00:00 Intro
01:24 The TL;DR
03:47 Follow up on Action items from last week
05:07 Brief RFC discussion
09:15 (Open Mic) Introducing the Core Infrastructure Initiative and the Cartographer progress with that
17:08 (Open Mic) Discuss 'owner' references in templates
A
A
A
Okay,
so
for
this
not
only
for
this
session,
but
for
the
gender
for
the
structure,
it
felt
the
agenda.
We
added
a
new
section,
replacing
another
section
that
we
didn't
use
last
time
and
I
call
it
the
tldr
the
the
purpose,
to
give
a
really
short
overview
on
what
the
team
is
doing
right
now,
how
what
change
in
the
project
during
this
week,
and
so
that
way
the
community
will
get
a
proper
starting
point
for
this
conversation.
B
B
So,
if
you're
more
information
about
what
that
looks
like
feel
free
to
check
out
the
rfc
which
I've
linked
in
the
docs
here-
and
this
are
this-
this
release
also
has
a
couple.
Breaking
changes
to
be
aware
of
so
the
big
ones
are
is
that
we
rename
the
the
components
block
to
resources
in
the
supply
chain
and
we're
making
the
run
template
in
pipeline
cluster
scoped,
and
that's
just
to
better
align
with
some
of
the
other
templates
from
supply
chain,
so
yeah.
A
A
D
Well,
I
think
there
needs
to
be
I
still
I
I've
been
bouncing
around
internally.
So
it's
something
I
need
to
share
with
the
open
source
community
type,
using
stricter
typing
for
resources
in
a
supply
chain
same
within
the
delivery,
so
that
we
can
actually
have
a
source
versus
sources
and
have
it
be
sensibly
typed.
So,
if
there's
no
more
to
talk
about
on
that
right
now,
I'll
try
to
make
sure
that
we
do
have
a
proposal
for
that
in
an
rfc,
maybe
that
rfc
yeah.
E
E
E
D
A
E
D
D
E
A
There
you
go
that's
great
okay,
there
is
not
anything
else
for
rfcs,
you
can
move
the
open
knife
discussion.
Well,
it
seems
like
mine
is
the
first
one,
so
I
wanted
to
introduce
the
common
infrastructure
initiative.
I
believe,
yeah
core
infrastructure
initiative.
This
is
a
program
by
linux
foundation
and
the
goal
is
to
provide
a
standardized
way
to
certify
that
open
source
projects
out.
A
There
follow
a
baseline
of
best
practices
on
different
books
and,
depending
on
how
much
of
these
criteria
we
need,
we
meet,
we
earn
the
passing
level
or
silver
level
or
goal
level.
So
if
we
see
here,
for
example,
it's
in
the
gold
level
we
have,
we
have,
for
example,
node.js
only
has
passing
level,
but
they
have.
We
have,
for
example,
the
linux
kernel,
it's
in
the
gold
tier
obviously
and
pearl
in
many
other
packages
and
software
we
use
every
day.
A
A
section
that
I
started
you
know
this:
this
program
works
in
a
self.
It's
a
self
certifying
thing,
because
we
we
enter
the
information.
Some
of
the
information
is
automatically
retrieved
from
the
repo
and
the
remaining
is
is
entered
by
by
whoever
owns
this
page.
I
actually
owned
this
page,
so
I'm
I'm
getting
started,
I'm
adding
the
stuff
that
I
know
that
I'm
aware
of
that
there
are
some.
A
A
Some
other
form
of
release,
notes
that
the
the
the
human
can
understand
out
there
what's
new
and
what's
important
from
this
release,
so
that's
something
we
will
need
to
discuss
how
to
handle
this
release
notes.
I
know
that
it
help
now.
It
has
some
features
to
automatically
generate
we'll
need
to
see
how
to
handle
this
and
well.
There
will
be
several
oral
domains
that
I
will
be
discussing
with
you
all
to
see.
How
can
we
meet
this
criteria?
A
E
A
A
It's
more
what
users
get
out
of
this,
for
example,
with
better
release
notes.
Well,
we
will
have
more
users
that
are
that
have
clear
information
on
what's
new
and
why
this
new
release
is
important
right.
So
at
least
getting
the
passing
legal
criteria
is
something
that
is
considered
necessary
for
open
source
projects
under
the
vmware
umbrella,
but
with
with
the
progress
of
you,
know,
silver
and
gold
level,
attorching
several
security
topics,
so
it
will
be
great.
E
D
In
all
seriousness,
though,
like
it's
nice
to
have
a
well
a
well
groomed
list
of
criteria
that
makes
your
project
more
attractive,
so
so
I'm
all
for
it.
I
just
like
to
put
my
hand
up
for
helping
with
the
analysis
section
of
this,
because
we
we
have
been
talking
about
static
and
dynamic
code
analysis
and
I'd
love
to
get
some
feedback
too
on
what
tooling
should
work.
D
We
were
thinking
of
using
sonarqube,
but
it
does
talk
about
using
floss,
and
so
I'd
like
to
know
what's
available
in
the
floss
domain,
for
us
to
ensure
that
we
meet
those
criteria
and
that
we
get
good
feedback
on
code
quality,
make
our
reviews
easier.
It
will
make
it
easier
for
us
to
be
consistent,
so
that
might
my
hands
up
for
that.
If
you
need
to
find
someone
to
talk
to
about
it,.
F
On
that
you
know,
I
know
we
have
done
some
nice
integration
with
something
sony
cube
cloud.
I
think
they
do
like
freeze
service
for
open
source
projects,
which
is
kind
of
nice,
but
there
is
a
little.
I
know
that
recent
other
tooling
services,
south
services,
the
code
curve,
I
think,
had
some
fairly
horrendous
security
issues
as
well.
So
it's
recent
of
last
year,
so
it's
probably
yeah
it's
one
of
those
how
they
got
implemented,
but
yeah
having
that
kind
of
stuff
analysis
and
also
like
it's
really
really
really
really.
Nice.
D
Yeah,
I
think
what
I've
what
I
struggled
with
was
knowing
that
these,
because
also
for
the
cncf
criteria.
They
want
us
to
use
common
open
source
tooling
for
these
things,
and
it's
just
hard
to
find
a
list
for
go
of
good
tooling.
That
isn't,
in
my
opinion,
weak
vet
tools
that
don't
seem
to
do
the
job
very
well.
D
So
the
only
thing
I
found
that
worked
with
cena
cube-
and
I
don't
know
whether
being
available
for
open
source
is
the
same
as
being
open
source
in
itself
and
if
it's
open
source
enough
for
it
to
satisfy
these.
So
I'd
like
to
dive
in
on
that,
make
sure
we're
using
a
tool
that
will
meet
this
thing's
criterias
and
the
cncf
ones.
A
E
A
D
D
Why
would
we
deploy
two
templates
in
a
system
if
we
can
avoid
it,
especially
if
you
just
want
to
be
out
of
carp
launch
it?
Yes,
the
deliveries
deliveries
templates
tend
to
live
on
a
different
cluster
than
on
a
then
on
where
the
supply
chain
sits,
but
if
you
want
them
on
the
same
one,
that
should
work.
D
C
D
Yeah,
I'm
just
thinking
about
the
one
example
where
I'm
building
a
supply
chain
and
delivery
at
the
moment,
and
I
would
rather
have
the
two
templates,
because
there
is
another
small
issue
too,
which
is
that
that
template
just
uses
the
metadata
name
and
the
delivery
tends
to
also
have
the
same
name.
Sorry,
the
deliverable
has
the
same
name
as
the
workload,
so
we
get
a
name
collision.
D
D
E
Probably
images
as
well
right,
I
think,
there's
a
push
for
using
supply
chains
for
images,
and
I
could
see
that
being
used
for
both,
I
think
from
like
a
a
ux
perspective
or
like
a
user's
perspective
like
you
wouldn't
want
to
have
to
know
you
know
one
versus
the
other
right
like.
If
it's
the
same
template,
it's
going
to
only
work
the
same
way
between
both.
D
I
think
it's
important
as
an
alias,
because
I
think
there's
a
lot
of
times
where
you
just
want
to
be
very
explicit
and,
and
that
way
our
template
will
just
obviously
explode.
If
you
said,
if
you
said
you
know,
workload
workload.spec.nf
right
instead
of
telling
us
owner.spec.m
doesn't
exist,
it
would
just
simply
say
no
workload
here,
and
that
would
be
useful.
So
in
the
templates,
where
you
know
it's
specifically
for
a
particular
type
of
chain
for
one
of
a
better
word,
then
you
use
that
specifically
and
the
owner
is
a
reference.
E
But
I
mean
that
that
brings
up
a
bigger
discussion
right
like
what
is
the
future
for
ytt
inside
of
supply
chains
and
deliveries.
Right
of
this,
like,
like
we're
not
I
mean,
in
the
context
of
delivering
things
in
a
certain
time
frame
right,
like
those
kinds
of
work
around
discussions
are
important,
but
if
we're,
if
we
want
to
make
something,
you
know
for,
if
we
have
our
eyes
on
the
longer
term,
which
I
think
like
these
discussions
should
be,
should
should
be
right
like
what
is
what
are
we
doing
long
term
with
ytt.
F
D
It's
very
light.
We
have
we,
we
have
enough
abstraction,
the
the
the
choice
between
like
like
ytt
and
the
plane,
templating,
that
we
have
are
two
little
implementations
that
are
called
from
the
same
base,
which
comes
basically
in
with
a
set
of
inputs,
known
inputs
that
you
can
get
values
for
your
get
values
for
for
your
interpolation
right,
yeah.
So.
D
D
E
E
Double
down,
or
is
this
something
that
we
want
to
like
bridge
the
functionality
gap
with
stuff
to
get
us
to
where
we're
at
with
ytt
and
then
go
from
there?
So,
like
from
my
perspective,
you
know
it's
not
it's
more
of
an
engineering
discussion
right
like
do.
We
want
to
continue
to
use
it
double
down
or
what?
What
do
you
all
think.
D
F
D
F
One
other
maybe
thing
that
might
be
worth
considering.
That,
though,
is
adoption
of
how
familiar
people
are
using
it,
so
it
might
make
our
lives
easier,
but
is
there
a
barrier
to
entries
to
some?
Do
you
have
to
learn
ytt
somebody,
that's
not
familiar
with
ytt.
It's
I've
had
to
scratch
my
head,
a
little
I'll,
be
honest,
not
yeah.
That's
probably
just
because
I
haven't
had
the
time
to
you
know,
probably
look
at
it.
I
don't
mean
to
offend
it.
F
D
D
I
see
why
the
choices
exist,
because
this
gives
you
a
structural
template.
The
problem
with
go
templates
is
that
you
then
start
to
have
to
make
sure
your
white
space
makes
sense,
and
so
that
becomes
frustrating
more
so
than
I
would
just
wish.
I
could
get
some
yaml
in
here
and
have
it
injected
as
it
as
an
object,
rather
than
as
a
string
right
and
that's
where
most
of
us
land
on
that.
D
I
almost
think
that
our
templating
should
be
replaced
with
go
templating
and
then
we'd
have
a
comparison
that
actually
makes
more
sense
that
we
could
have
users
try
to
one
that's
a
very
common
idiom,
which
is
go
templates
and
one
that
is
designed
to
improve
the
structural
templating
pains
that
you
have
rather
than
the
templating
we
have
today,
which
is
entirely
unique.
I
mean
it's
json
path,
but
it's
still
entirely
unique
and
very
limited.
E
Yeah,
I
guess
I
guess,
like
that's
what
I
was
gonna
say
like
what
do
we
need
to
get
there
to
get
to
a
point
where
we
can
make
an
intelligent
decision,
one
way
or
the
other?
So
if
it's
like,
we
need
to
support,
go
templating
first,
to
be
able
to
say:
okay,
it's
this
versus
that,
then
you
know
like
it's
not
a
decision
we
need
to
make
today.
I'm
sure
we
could
talk
about
it
a
lot
but
like
what?
D
E
Should
we
be,
should
we
be
closing
that
functionality
gap
right
like
that's,
that's
the
that's!
The
question
is
like
yeah
should,
should
we
be
right
or
can
we
like,
I
was
saying
double
down
on
ytt
like
in
my
opinion,
ytt
is
pretty
ugly
in
there
but
and
like
offering
a
nicer
user
experience
would
be
better,
but
right.
H
So
I
I
don't
think
pivoting
to
to
going
to
blades
would
be
like
I
mean
it's
like
saying,
like
yeah,
we
get
apple's
apples
comparison
because
now
we're
just
using
two
different
templating
engines,
but,
like
you
know,
I
don't
think
we
want
to
go
to
something.
That's
text-based,
and
you
know
one
of
the
things
that
that
our
baked
approach
has
is
that
it
is.
C
H
A
D
H
F
It
sounds
like
there's
quite
a
few,
a
few
different
parts
to
it.
What's
the
next
approach
is
it
is
this?
Is
there
an
issue
for
you
already?
Is
there
what
would
be
the
best
approach
to
kind
of
start
dumping,
some
thoughts
and
tracking
this,
because
it
sounds
like
it's
not
going
to
be
a
solve
overnight
kind
of
a
thing
and
there's
lots
of
thoughts
and
lots
of
maybe
looking
experimenting
or
research
needs
to
be
done.
D
I
think
that
we
have
to
identify
those
like
those
use
cases,
so
so
so
the
the
the
repeats
are
about
things
where
you
have
more
than
one
thing.
You
need
to
configure
I'm,
but
like
I'm,
just
going
to
jump
straight
to
my
solution
just
to
try
to
describe
what
I
I
think
should
happen
here
is
that
we
can
template
any
object
out
that
we
want
to
so
there
should
be
an
object.
That's
well
designed
for
dealing
with
this
problem,
which
is
hey.
I've
got
I've
got
a
bunch
of
resources.
D
I
need
to
write
config
for
so
we
have
a
config
template.
The
config
template
should
come
up
with
that
by
using
a
sub
resource.
That's
designed
to
omit
that
and
then
you
should
not
need
a
ytt
template
for
that.
So
that's
a
that's
being
able
to
do
a
looping
solution
of
some
kind,
all
right
it
should
be.
I
think
it
should
be
aware
of
the
input.
D
So
if
it's
for
a
like
a
service,
a
list
of
services
that
you
want
to
be
able
to
attach
to,
then
it
should
know
about
services
and
generate
some
result,
which
means
that
we
need
to
either
work
with
the
community
or
find
solutions.
That
already
do
that.
That
say,
take
a
list
of
services
and
create
some
config.
You
can
append
and
then
the
other
one
is
conditional
logic
and
that's
way
more
complicated.
And
I
haven't
got
any
clues
about
that
one.
But
the
conditionals
tend
to
be
based
on
the
fact
that.
D
H
But
yeah
it's
almost
like
you,
it
feels
like
you
want
to
have
something
like
you
know
that
recursive,
like
templating
nesting,
part
and
then
like.
I
don't
know
if
you
folks
remember
much
or
ever
want
to
remember
much
about
xslt,
but
the
way
you
could
say
well,
I
want
to
apply
those
templates,
and
this
is
the
selecting
filter
that
I
want
on
it
right
and
then,
if
you
could
have
those
filters,
then
that
kind
of
gets
you
away
from
having
like
conditionals,
because
you
know
you
can
just
say
this.
B
The
underlying
problem
is
that
there's
all
these
different
use
cases
we
need
to
tackle
them
individually,
and
it's
going
to
be
a
much
larger
discussion
to
see
if
we
can
come
up
with
something
that's
cohesive
and
that
makes
sense
for
each
individual
use
case.
But
until
that
happens
until
we
can
identify
all
those,
then
I
think
ytt
will
just
be
there
for
a
while
or
some
templating
will
be
there
for
a
while.
D
I
think
logical
templating
will
be
there
forever.
That
would
be.
My
recommendation
is
that
we
don't
ever
think
we're
going
to
lose
it,
because
I
think
people
will
always
need
a
new
solution
out
the
gate
that
hasn't
been
solved
with
a
crd
and
with
controllers,
and
I
think
it
behooves
us
to
support
that
in
perpetuity,
because
that,
although
ytt
is
complex,
that
is
immediately
a
lower
barrier
to
entry,
then
well,
you
need
your
own
controller
and
crd
to
support
this
problem
right,
but
one
thing
we
could
do
to
sort
of
like
separate
the
concerns.
D
A
little
bit
is
actually
something
that's
been
brought
up
before,
which
is
produce
a
crd
ytt
itself.
So
then
there's
no
longer
our
problem.
It's
just
that's
the
default,
one
that
you
can
use
in
a
like.
A
config
template
create
a
a
ytt,
and
that
could
be
a
an
easy
proposal
to
separate
the
concerns,
and
then
let
someone
who
wants
golang
templates
to
go
and
do
that
and
create
a
to
create
their
own
crd
for
that
as
well.
C
E
I
think
I
think
that's
reasonable,
like
this
is.
This
is
clearly
a
longer
discussion
right
and,
like
I
think
in
my
mind,
this
is
like
a
this
is
like
a
like
a
medium
to
long
term
thing
that
we
need
to
figure
out
like
for
now.
Ytt
is
here
right,
and
so,
let's
you
know,
our
community
usage
is
obviously
minimal
right.
So,
as
we
grow
right
like
we
can,
these
are
things
that
we
can
can
rally
around
in
terms
of
like
like.
Should
we
address
the
functional
gap
to
what
ytp
can
do
natively
with
photographers?
H
D
D
D
It
is
pretty
straightforward,
but
if
it's
a
little
hand-holdy
document
a
bit
of
documentation,
then
maybe
people
won't
be
worried
about
it
and
then
the
other
thing
is
is
in
our
example,
to
make
sure
that
we
over
explain,
because
I
believe
our
example
carries
ytt
in
it
and
and
certainly
will
soon,
because
I
believe
we're
putting
in
an
example
that
uses
choices
for
git
ops
behavior.
So
we
should
over
explain
in
that
to
a
user
who's.
Reading
the
example
just
what
the
ytt
is,
even
though
we
can
say
here's
your
ytt
documentation.