►
From YouTube: Cartographer Office Hours - May 2nd, 2022
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
Feel
free
to
add
yourself
to
that
in
this
list
and
sharing
again
the
link
for
folks
who
just
joined
all
right
so
remember
the
goal
of
this
space
mainly
to
discuss
ideas
that
could
improve
the
project
in
the
form
of
rfcs.
A
So
we
have
the
project
board
we're
trying
out
the
the
beta
githubs
projects
in
this
case
for
rfcs.
So
we
will
start
by
discussing
with
the
rfc
756
introduced
to
native
events,
which
is
blocked
on
dlc.
Is
there
anyone
from
dlc
here?
Yet?
No,
so
we
should
start
but
another
one,
probably
yeah,
yeah,
okay,
we'll
wait!
If
someone
from
the
dlc
joins
and
next
up,
it's
705
simplified
run
of
huge
usage
which
has
been
labeled
as
blocked.
A
C
C
Yeah
so
I
heard
this
and
then
there
there
was
a
scott
raised,
an
objection.
I
I
saw
those
as
separable
issues
and
that's
why
I
opened
787
and
I've
heard
steven
say
that,
like
I've
talked
to
stephen
and
he
said
well,
I
want
to
resolve
787
before
approving
705..
C
I
think
separately,
78
and
well,
I
think
787
is
doable.
It
actually
complicates
things
even
more,
at
least
in
the
short
term,
because
we
would
have
to
support
two
competing
ways
of
doing
things.
C
Just
within
runnable
forget
like
using
using
a
flag
which
has
made
and
and
also
I
think,
that
there
is
just
a
user
design
like
a
ux
question,
where
some
folks
think,
like
oh,
the
current
runnable
structure,
where
you
have
a
workload
and
then
you
have
a
runnable
and
then
you
have
all
these
runs
is
is
good
for
users
and
another
camp.
That
says,
if
I
create
a
template-
and
I
just
put
this
flag
on
it-
to
say
it's
immutable
and
then
suddenly
I
see
this
new
object.
C
Runnable,
that's
created,
that's
confusing
to
me
and,
and
it
would
be
simpler,
not
to
have
that,
and
one
thing
I
was
thinking
was:
we
could
actually
try
that
out
and
just
have
the
default
for
the
flag,
be
no
runable
and
we
we
soaked
that
runnable
behavior
up
into
the
into
the
workload
behavior
and
we
leave
runable
as
it
is
for
those
people
who
do
want
that
runnable
object.
So
we
simplify.
We
both
simplify
things
and
we
leave
like
this
other
experience
and
then
we
could
like
gather
user
feedback.
C
You
know
the
other
option
is
just
to
get
some
users
and
put
some
designs
in
front
of
them
and
ask
what
they
think.
I
expect
some
I'm
I'm
expecting
that
rash
might
be
happy
about
my
proposal
to
suck
the
runnable
behavior
up
into
the
workload.
C
That
is
something
that
the
engineering
team
has
proposed
for
a
while,
and
I
wonder
if
having
both
at
the
same
time,
maybe
like
not
trying
to
deprecate
runnable
just
having
both
could
be
kill
two
birds
with
one
stone.
D
D
That's
assuming
it
can
be
simpler,
I'm
hoping
it
it
can
be
as
simple
as
we
originally
suggested,
with
just
setting
a
life
cycle
and
they're
just
behaving
like
like
it's
needed
to
for
all
of
the
you
know,
there's
new
rfcs
that
have
come
since
then,
and
I'm
not
sure
if,
if
any
of
those
things
cause
any
sort
of
impedance
mismatch
like
I
like
the
status
one,
for
example,
the
health
we've
got
a
health
rfc,
I'm
not
sure
if
that
can
now
conflicts
in
any
way.
Assuming
it
doesn't.
D
D
My
argument
is
that
the
object
graph
is
part
of
the
user
experience
of
cartographer
right
you're
using
cartographer,
and
you
define
a
supply
chain.
You
have
a
bunch
of
resources,
they
generally
map
to
one
reese
object,
resource
and
resource
object,
and
you
expect
to
see
that
there
and
then
from
there
to
be
able
to
debug
those
in
their
own
world
essentially,
and
so
that
seems
cleaner,
that
we
create
the
thing
that
we
say
we're
going
to
create
in
the
template.
B
This
points
to
another
one,
that's
just
because
if
we
go
with
the
implementation
of
them
in
that
order,
for
instance,
the
template
field
for
runnable,
I
think
this
one
is
blocked
on
the
ability
for
you
to
essentially
do
selection
at
a
higher
level
than
runnable,
because
if
we
get
that
one
end
and
like
it
simplifies
this,
if
this
gets
in,
then
it
simplifies
the
the
other
fc.
I
forgot
the
the
name
and
the
number
the
the
overarching
like.
Oh,
let's,
simplify
runnable.
E
E
It
seems
like
if
we
want
to
encourage
a
preferred
workflow,
then
it
probably
makes
sense
to
deprecate
that
select
runnable.
C
Yeah,
the
the
reason
we
need
selector
at
in
the
supply
chain
templates
is
if
we
have
selector
in
the
runnable
object,
and
then
we
start
templating,
and
we
refer
to
things
it's
unclear
in
the
inline
template.
I
don't
know
it
yeah,
it's
it's
complicated,
which
is
which
is
part
of
why
I'm
like,
maybe
with
the
maybe
we
just
leave
runable
as
it
is,
and
then
we
we
put
the
life
cycle
flag
on
the
life
cycle.
E
C
Be
clear,
so
that's
what
I
was
trying
to
preview
that
like
I
would.
I
would
like
to
to
take
a
different
approach
and
say,
like
the
rfc,
as
it
is,
is
saying
what
if
we
stamp
out
a
runnable
say
like
let's
not
do
that.
Let's
have
the
the
workload
controller
stamp
out.
Those
techton
task
runs
and
in
the
status,
make
sure
that
it's
reporting,
like
the
proper
task,
run
object
and
just
not
have
a
runnable
created
at
all.
F
D
C
D
D
G
One
one
last
thing
I'll
say
about
its
events
is,
I
think,
one
change
not
just
last
week
or
two
weeks
ago.
That
was
basically
suggested
that
we
say
that
the
events
in
the
rfc
are
examples
rather
than
a
finite
set
of
we
will
have
excitement.
D
C
I
think
we
have
alignment
that
when
we
make
changes
to
the
status
that
that
does
require
an
rfc,
I'm
wondering
if
we
think
of
the
event
submitted
as
less
of
the
api,
the
user
api
than
the
status.
G
G
What
have
you
so
like
for
the
content
of
the
status
like,
I
think,
that's
a
place
where
we
absolutely
expect
people
and
tools
to
like
care
deeply
about
the
structure,
like
tools,
will
look
for
certain
flags,
certain
conditions
and
make
decisions
based
off
of
that
in
terms
of
what
they
display
or
how
they
interpret
the
health
of
that
resource
events
are
more
informational
and
more
debugging
oriented,
rather
than
something
that
you
would
necessarily.
G
G
You
might
write
something
that
alerts
like
with
a
certain
event:
fires
more
times
over
a
certain
period.
So
if
you
like
trigger
some
threshold,
you
might
then
like
page
somebody
so
like
we
should
be
careful
about
changing
the
was
it
the
reasons
arbitrarily
but
like
specifically
like
the
messages
like
those
are
like
free
form.
Those
are
human
readable.
We
can
change
them
whenever
we
need
to
just
because
something
reads
better
so
like
it's
definitely
something
we
should
document
and
we
should
be
conscious
of,
but
I
don't
think
the
standard
is
as
high.
D
You
know
excessive,
excessive
thrashing
that
kind
of
thing
things
that
can't
be
observed,
looking
at
a
status,
basically
high
numbers
on
events
over
sure
I
mean
histographically
right
so
mostly
when
they
attach
tooling
that
can
pick
up
and
I'm
it's
a
neologism,
but
histographic
works
for
me.
Histogramically.
D
It's
probably
the
right
term
here,
but
if
you
attach
some
kind
of
monitoring
tool
that
then
alerts
you
on
a
high
number
of
events.
Particular
events,
especially
in
these
you'd,
want
those
to
be
fairly
reliable
because
you're,
probably
you're,
probably
setting
up
your
operations
around
those
sorts
of
behaviors.
A
Okay,
yeah
remember
to
go
there
and
provide
you
review,
so
we're
able
to
move
it
in
the
process.
Okay,
next
thing
will
be,
according
to
the
board,
to
play
comment
on
the
rfcs
in
the
fcp
stage.
Would
that
be
a
good
approach.
A
Because
I
see
this
one
sorry,
this
rfc
well
according
to
the
board,
is
the
final
comment
period
stage
so
wondering
there
is
any
additional
comment.
Has
an
approval
by
scott
already
already
needs
an
additional
review
by
stephen.
H
D
D
D
I
I
was
trying
to
introduce
maybe
a
discussion
around
this
in
this
meeting
and
then
I
decided
decided
we.
I
think
we
all
know
that
it's
a
little
hard
to
understand
what
the
statuses
are
and
and
to
make
sure
that
rscs
move
to
where
they
are
and
communicate
broadly
what
the
rsc
status
is.
I
just
wanted
to
pick
up
some
more
work
to
actually
go
and
improve
on
that
a
bit
in,
hopefully
in
copying
what
someone
else
is
doing
somewhere.
D
It
feels
like
it's
still
all
very
manual,
and
this
like
just
before
this
meeting
me
and
david
got
together
and
just
made
sure
that
the
priorities
matched
what
we'd
seen
in
the
in
the
rfc
board
and
we're
also
a
little
confused,
because
the
rsc
board
looks
a
little
out
of
date,
and
I
noticed
that
when
I
merged
one
this
week,
I
forgot
to
give
it
a
new
number,
because
it's
that
easy,
because
there's
no
automation
around
it.
So
these
are
things
I'd
like
to
tackle
at
some
point.
A
A
All
right
yeah,
thank
you,
raj
for
bringing
that
up.
Okay,
we
have
several
rfcs
in
pending
state
yeah.
We
we've
seen
some
differences
between
the
beta
board
and
the
the
let's
say,
the
old.
What
we
were
using,
but
but
of
course,
keep
iterating
on
whatever
works
best.
A
D
Some
of
these
have
been
left
in
pending,
just
for
the
the
the
sake
of
I
mean
they're
actually
drafts.
A
lot
of
these
multipath
is
supposed.
I
D
It
should
be
a
draft
yeah
pending
really
does
I
mean
we
will
move,
move
them
into
we'll
move
them
into.
D
Yeah,
those
pendings
are
entirely
different
to
the
other
board.
We've
got
to
work
out
why
the
two
boards
are
completely
out
of
sync
with
each
other.
D
I
J
J
Can't
from
what
I
remember,
the
the
last
decision
was
no
changes
to
the
workload
for
now
for
this
release,
the
changes
for
the
the
parameterization
for
the
maven
repository
will
provided
the
via
the
params,
at
least
for
the
first
release.
Until
we
get
some
feedback
and
then
we
can
revisit
the
workload
and
update
it
accordingly.
J
J
We're
updating
the
vmware
source
controller
code
to
to
handle
the
maven
repositories
and
that'll
probably
take
a
couple
more
weeks.
J
And
we
can
see
like
what
the
supply
chain
looks
like
when
it's
going.
A
Yeah,
thank
you
all
right.
Yeah
next
up
is
the
proposal
from
the
rash.
It's
is
there
any
objection
of
moving
the
multi-path
proposal
to
decline.
D
I'm
gonna
put
a
little
description
on
it,
just
to
say
that
we're
declining
it
because
it
makes
it
too
simple
for
supply
chains
to
start
looking
like
concourse
pipelines,
which
defeats
the
purpose
of
a
choreographer.
That
depends
on
well-designed
resources.
A
It
rash
looks
like
no
objections
in
that
regard.
Really:
okay,
cool
all
right.
Next
up
was
the
discussion
topic
on
using
hacking
d
instead
of
google
docs,
for
this
particular
meeting
notes,
and
that's
a
really
good
point,
because
the
original
idea,
at
least
my
idea
with
using
google
docs,
was
to
make
it
accessible
even
for
folks
who
are
not
familiar
with
markdown,
but
right
now
it's
becoming
hard
to
maintain.
A
I
mean
google
docs,
because
you
know
lack
of
automation,
integration,
so
yeah.
There's
this
proposal
of
migrating
and
meeting
notes
to
hecandy.
C
D
My
first
one
is
I'd
like
the
creation
of
next
week's
meeting
to
be
done
today,
and
we
forget
to
do
that.
So
it's
hard
to
come
in
and
make
some
annotations
about
what
we'd
like
to
mention
next
week,
because
the
first
person
who
decides
to
do
it
has
got
to
do
a
copy,
pasta
and
put
in
a
date
and
it's
all
kind
of
just
it's
distracting
and
then
I'm
sitting
there
going
wait.
D
D
That's,
but
the
main
automation
is
just
to
create
a
new
section
every
after
every
meeting,
and
I
believe,
that's
easier
to
do
with
hackmd.
I
could
be
wrong.
The
other
reason
was
because
people
have
suggested
it
because
most
of
us
are
engineers
and
we
we
write
in
markdown
really
easily.
C
C
F
C
You
know
where,
like
on
the
screen
where
it
has
normal
text,
it
has
like
the
formatting
for
different
headings.
Yes,
my
subtitle
heading
is
a
colored
with
a
gray
background,
fixed,
fixed
width
font
so
that
it
can
just
like
very
quickly
be
like
this
is
code.
B
D
Understand
yep
yeah
anyway,
I
mean
we
don't
have
to
do
it.
I
just
figured
it
would
be
something
to
bring
up.
It
might
be
nice,
I'm
hoping
we
can
just
automate
creating
new
sections
each
month
a
week
I'll
be
a
fan
of
that
oh
yeah.
Smart
quotes,
it's
fun.
A
K
Nothing
in
particular
land.
I
think
I
noticed
I
think
scott
looked
at
the
eventing
one.
This
morning
we
talked
about
it
a
little
bit
too
earlier.
A
Cool.
Thank
you
all
right
is
there
anything
else
you'd
like
to
discuss
share
here.