►
From YouTube: Cartgrapher Office Hours - June 27th, 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
All
right
welcome
everyone
to
cryptographer
office
hours.
This
is
the
space
designed
mainly
to
discuss
proposals
discuss
rfp
if
you
are
not
familiar
with
the
project.
Rst
process
you're
welcome
to
check
it
out
it's
at
the
top
of
the
meeting
notes.
A
A
A
Okay.
So
we
will
start
with
the
rfcs
that
team
considered
priori
to
discuss,
because
mainly
they
are
tied
to
any
to
a
specific
release
or
upcoming
release.
So
they
need
to
be
to
be
discussed.
You
know
firsthand,
so
we
will
start
with
the
app
match.
Params
select
or
rfc
yeah
great
confirm
there
you
go.
Thank
you.
Github
all
right
add
match
parm
selector.
Is
there
any
update
or
any
comment
you
like
to
address
regarding
this
rfc,
so.
C
Yeah
I
moved
this
from
denied
to
pending
a
few
weeks
ago
in
a
meeting
that
was
as
far
as
they
attended
as
this
one,
and
there
have
been
no
comments
since,
and
so
I
was
like
well,
let's
mention
again
that
this
is
in
the
loop.
Unfortunately,
there
are
no
members
of
the
tsc
to
discuss
it
now
as
to
the
actual
contents
of
it.
C
The
idea
is,
we
have.
We
have
options
to,
for
example,
switch
betw
to
say
if
you
see
this
field
in
the
workload
do
x
and
you
know
stamp
out
template
x
if
you
see
different
values
stamp
out
with
template
y,
but
we
can't
do
that
against
params
at
the
time
that
this
was
proposed,
and
you
saw
you
can
see
this
was
written
by
josh.
C
I
think
I
was
actually
the
first
maintainer.
That
said,
I
think
that
we
can.
I
think
that
we,
this
is
not
necessary,
because
the
persona
of
the
app
operator
will
always
know
whether
they
are
setting
a
param
or
not,
and
since
they
know,
if
they're
setting
a
param,
then
they
can
just
check
to
see
whether
the
workload
has
set
a
param.
C
B
A
If
someone
from
you
are
not
familiar
with
the
the
stages,
they
are
describing
the
rc
process
and
the
team
created
these
nice
dashboards,
the
project
to
actually
visualize
the
current
status
of
the
proposals.
So
this
one
was
moved
from
the
night
swing
review,
so
we
could
cover
additional
details
with
the
technical
oversight
committee.
A
Let's,
which
one.
A
B
No,
I
think
I
think
I
think
at
this
point,
that
this
is
clearly
there,
but
not
the
highest
priority.
I
was
hoping
to
ask
washuma
what
the
priority
was
for
this.
If
there
was
some
requirement
from
anyone,
I'm
not
in
a
rush
to
move
it
forward.
Personally,
because
I
haven't
heard
what
the
use
case
is,
that
means
that
we
must
implement
versus
whether
it's
a
valid
or
good
idea.
Is
I
like
the
idea
personally,
but
I
in
no
rush
to
see
that
it
gets
done
so
I'll.
B
Just
put
that
wishing
fell
offline.
A
B
The
big
open
question
we
had
while
your
internet
was
disappeared,
was
what's
the
what's
the
motivation
to
introduce
the
match.
Params
back.
Is
there
a
use
case
that
needs
to
be
solved
at
this
point
from
a
customer
or
user,
or
can
it
sit
there
and
wait
until
someone's
got
time
to
actually
get
in
there
and
review
it?
Is
it
okay,
just
impending
for
now.
C
C
Simplified
templates,
instead
of
having
like
huge
functions
up
at
the
top
that
are
used
to
determine
what
sort
of
template
am
I
supposed
to
be
and
then
and
then
have
functions
that
then
stamp
out
that
template
to
instead
allow
allow
authors
of
platforms
like
tap
to
use
those
options,
options
on
params
to
just
declaratively
switch
and
say
like
oh,
this
param
is
set
so
clearly
we're
stamping
out
this
sort
of
object.
I.
B
C
It's
not
so
much
in
the
that
it's
in
the
rfc,
it's
that
when
I
was
working
on
tap
work
in
the
in
the
last
iteration.
I
kept
running
up
against
this
problem
where
I
was
like.
I
would
really
like
to
have
like
I
don't
know
what
params
are
going
to
be
set
here,
and
I'd
really
like
to
be
able
to
use
options
against
them,
and
we
had
sort
of
left
this
with
a.
B
I
won't
go
off
on
a
tangent
for
very
long,
but
really
quickly.
The
assessing
what
kind
of
inputs
a
template
takes
would
be
quite
easy
if
all
we
ever
had
to
do
is
read
templates
and
not
ytt.
B
We're
thinking
that
if
we
can
just
say
well,
you
get
better
awareness
of
the
type
requirements
of
a
template
simply
by
using
only
templates
and
not
ytt
we'd
like
to
promote
that
we'd
like
that
for
better
experiences
warnings
that
sort
of
stuff.
So
that
goes
in
the
right
direction
to
that.
So,
if
it's
mentioned
that,
that's
what
it
it
helps
with,
I
think
we
can
make
sure
that
we
get
an
approval
from
toc
for
it.
For
that.
A
Right
great,
thank
you.
Okay,
now
for
the
next
one,
the
artifact
racing
with
correlation
rules,
which
we
believed
in
the
first
office
hours
meeting
where
we
introduced
this
proposal.
C
That's
not
the
case,
I
definitely,
I
think
it
was
two
weeks
ago
spent
most
of
office
hours
talking
about
the
three
artifact
tracing
proposals,
so
this
is
not
a.
This
is
not
an
introduction.
This
is
a
please
comment
and
if
you
aren't
commenting,
please
approve
yeah.
C
C
I
have
not
heard
any
comments
that
suggested:
oh
yeah,
the
for
the
artifact
tracing
with
correlation
rules.
There
was,
I
was
suggesting
that
we
should
do
some
caching
for
security
and
stephen
and
scott
were
pointing
out
lots
of
use
cases
where
yeah,
where
a
cartographer
could
still
be
man
in
the
middle
when
dealing
with
other
controllers
and
so
yeah.
It
was
like
okay,
let's
put
put
this
off
since,
since
it
doesn't
wholly
solve
that
problem,
but
otherwise
yeah
that
the
changes
has
been
made.
B
We
go
alrighty
to
actually
take
this
to
the.
What
do
we
call
core
maintainers
there
we
go
cool
nice.
A
B
B
We
we're
just
working
on
maine.
At
the
moment
we
haven't
got
a
branching
philosophy
for
for
backboarding
patches
and
I
think
that's
a
good
thing
to
have
we're
starting
to
see
a
need
for
it.
So
this
is
just
a
suggestion
on
how
to
do
it.
I
think
it's
pretty
consistent.
B
And
I
don't
know
if
anyone
has
any
big
concerns
about
it
or
some
great
suggestions
about
what
would
be
better?
Does
anyone
want
me
to
talk
it
through
or
or
shall
I
just
leave
it
on
the
on
the
table?
A
B
C
No,
no,
this
seems
like
a
pretty
straightforward.
This
would
just
be.
We
would
have
essentially
a
developer,
a
develop
branch
and
a
and
a
use
this
one
branch-
oh.
C
D
C
B
Yeah,
I
think
I
think,
though,
with
like,
if
we
need
to
backport
something
to
an
a
minor
right,
we
would
take
the
miner
and
we
just
create
a
release
branch
for
it
off
of
its
off
of
its
most
recent
miner
release
right
sorry
offer
if
it's
yeah
offers
most
recent
miner
release
or
whatever
patch
release
we
did
and
then
going
forward
from
there
create
our
tags
off
of
that,
so
that
we
maintain
compatibility.
B
I
suspect
there
is
one
that
should
land
it
just
depends
on
how
much
noise
we
hear,
because
I
know
that
I
know
that
certain
steps
actually
run
in
parallel
when
they
should
not
in
030.
I
think,
and
that
might
be
something
we
care
about.
So
that's
why
I
introduced
this
as
I
was
like.
Maybe
we're
about
to
need
to
create
a
patch
for
the
first
time.
So
so
that's
why
it's
there.
D
Just
excuse
me
does
cartographer,
have
a
a
historic
policy
like
n
minus
two,
or
something
like
that
for
just
haven't
gotten
that
far.
B
A
Okay,
next
up
it's.
This
is
an
idea
that
was
proposed
by
mauricio
salapino.
A
Back
then,
in
february,
to
work
on
a
proof-of-concept
in
using
cartographer,
as
the
let's
say,
the
glue
to
integrate
several
tools:
jenkins,
tecton,
k,
native
etc,
using
cd
events,
cd
events
is
a
recent
continuous
delivery
foundation
project
member
project
and
their
goal
is
to
basically
standardize
the
protocol
or
the
proposer's
standardized
protocol
to
handle
events
between
different
systems
in
the
context
of
continuous
integration
and
continuously
the
game
systems,
the
the
the
they
have
this
interest
since
we
included
the
word
events
in
our
documentation
and
we've
been
sharing
with
this
community.
A
The
ideas
of
the
project
there's
this
idea
to
work
on
the
proof
of
concept.
Why
not?
The
cartographer,
toc
and
technical
leadership
has
already
discussed
this.
Now
we
have
the
eyes
of
fatih
the
germany,
the
user.
He
is
now
the
continuous
delivery
foundation
general
manager
and
happens
to
be
also
the
supply
software
supply
chain
leaf.
A
I
have
here
at
the
at
the
city
foundation,
it's
so
it's
a
great
opportunity.
I
will
keep,
let
not
say
pushing
working
with
the
technical
oversight
committee
and
the
leadership,
and
anyone
from
you
who,
like
to
collaborate
to
you,
know
make
this
happen,
because
I
think
it's
a
really
interesting
use
case
and
anything
we
can
do
with
this
community
is
pretty
beneficial
for
the
project.
C
C
I
I
agree
like
I
agree
in
terms
with
the
sentiment
of
wanting
to
to
be
helpful
in
the
city
foundation,
but
this
specific
ask
surprises
me.
Quite
none
of
the
ask
surprises
me,
but
that
we're
considering
doing
the
ask
surprises
me.
If
someone
told
me,
I
want
a
choreographer
that
works
with
cd
events.
I
would
say:
hey,
there's
captain
you
should
use
captain,
because
captain
is
pushing
for
the
city.
C
You
often
hear
rash
and
stephen
talking
about
cartographer
being
level
triggered,
and
what
that
translates
to
at
a
really
tangible
level
is
instead
of
listening
for
events
published
by
the
the
controllers
of
the
objects.
We
look
at
the
state,
that's
written
to
the
objects
by
those
controllers,
and
so
I've
heard
I've.
I
saw
someone
write
an
idea
like
oh
well.
We
could
have
a
a
third
object
that
would
that
was
me.
Listen
to
okay,
fair
enough
yeah.
That
would
listen
to
cd
events
and
publish
that
information
which
my
first
thought
was
like.
B
C
So
if
cd
events
were
widely
adopted,
for
example,
with
kpac
like
I
would,
I
would
expect
that
kpac
would
publish
cd
events
because
there
are,
you
know
there
are
build
specific
ideas
and
cd
events
that
they're
doing,
but
I
still
wouldn't
expect
that
we
would
interact
with
with
kpac
via
their
events.
I
would
expect
it
would
be
interacting
with
them
by
their
status.
C
B
B
B
B
Transition,
yes,
thank
you
that
would
make
that
possible
as
well,
and
I
think
for
more
details.
We
need
to
find
out
what
james
is
thinking,
but
he's
definitely
already
considered
this
and
is
looking
into
it.
So
I
mean
we
should
see
what
he's
thinking
and
maybe
we
can
also
ask
the
cd
foundation
for
more
details
as
to
what
they
think
this
might
look
like
all
right.
So
what
what
they'd
like
to
see
satisfied
that
makes
sense
in
that
space?
B
I
do
know
that
that
some
people
consider
like
cd
and
ci
quite
different,
I'm
not
sure
where
the
cd
also
includes
a
lot
of
ci
behavior
and
so
there's
an
integration
to
there,
which
is
when
you're
done
with
ci,
for
example.
I
think
jenkins
x
is
looking
at
emitting
these
events
too,
that
when
you're
done
with
ci,
we
still
get
into
the
cartographer
approach.
The
delivery,
which
then
leaves
up,
leaves
the
events
behind,
but
should
still
be
triggerable
by
them.
So
I
think
there's
that
as
well.
B
C
Yeah
so,
and
some
of
the
things
that
I
heard
you
say
like,
oh
maybe
runnable
should
should
admit
cd
events
and
even
maybe
workloads
paired
with
supply
chains
should
emit
them.
That
makes
total
sense
to
me
in
almost
the
conversation
that
we
didn't
have
in
office
hours,
but
a
conversation
we
had
with
adam
about
attesting
to
work,
that's
being
done
like
yeah.
It
would
be
useful
to
have
like
the
coordinator
emitting
events
and
then
the
you
know.
C
Each
individual
piece
is
also
responsible
for
emitting
events,
but
the
thing
that
makes
me
wary
in
just
in
this
issue
is
to
demonstrate
how
tools
can
coordinate
existing
tools
by
using
cd
events
and
so
for,
if
the,
if
they
ask,
is
like
hey,
can
you
show
how
cartographer
could
like
do?
C
A
C
B
I
think
it's,
I
think
it's
a
very
reasonable
point
and
I'd
like
to
make
sure
that
that's
raised
right
because
yeah,
but
we
already
know
that
we're
not
going
to
change.
B
E
Might
have
a
use
case
about
this,
so,
as
I
wrote
also
in
the
slack
channel
a
few
weeks
ago,
I
was
looking
into
yeah,
creating
some
kind
of
gui
for
cartographer,
and
one
idea
that
I
got
was
actually
to
implement
a
controller
that
would
intercept
all
the
message.
Passing
the
cartographer
takes
care
of,
doing
updating
the
status
and
to
intercept
that
and
emitting
events,
so
that
then
I
can
build
a
gui
just
by
listening
to
events
that
would
contain
information
about
source
code,
updated
or
image
published
or
stuff
like
that.
So
it
would
be.
E
B
For
you
like
a
lot
of
the
well,
the
app
monitoring
tools
already
do
something
like
that,
which
will
at
least
tell
you
like
how
many
times
something
has
happened
in
an
hour
and
that
sort
of
thing
it's
not
not
necessarily
useful
for
workload
or
anything
like
that.
You'd
make
something
much
more
specific,
but
I
really
think
it
would
be
kate's
native
events
that
we'd
be
trying
to
support
in
that
space.
C
E
Those
events
would
be
based
on
the
cloud
event
specifications,
so
there
would
be
something
like
canadian,
eventing
or
a
system
consuming
these
events
object
and
then
there
can
be
consumers
listening
to
k
native
eventing
receiving
those
events.
So
it's
not
the
kubernetes
events,
yeah.
B
Oh
okay:
well,
I
think
you
should
raise
an
issue
with
some
really
strong
lens
to
the
links
to
those
k-native
events,
if
they're
different
from
kubernetes
events,
so
that
we
can
learn
more
about
what
you're,
after
and
and
bring
it
up
for
discussion,
maybe
next
week,
so
so
that
people
have
had
a
chance
to
look
at
what
your.
What
your
ask
is,
because
I'd
love
to
hear
it
it'd
be
great.
C
And
in
terms
of
tips
of
that
interop,
I
would
my
read
unless
I
misread
the
cd
events
proposal.
My
understanding
is
that
it
they
would
be
a
subset
of
cloud
events
that
all
cd
events
would
be
valid
cloud
events.
They
are,
but
they're
they're,
more
strict.
You
could
have
a
cloud
event.
That's
not
a
cd
event
that
you,
you
would
never
have
a
cd
event
that
wasn't
a
cloud
event,
and
so
that's
where
I
would
expect
the
interop
to
be
like
anybody
who
is
expecting
to
consume
a
a
valid
cloud
event.
B
Really
we'd
love
to
see
an
issue
raised
by
that,
so
that
we
can
sort
of
like
dive
into
some
links,
and
maybe
even
if
you
present
some
of
the
things
that
you're
looking
for
like
an
example
of
what
what
you're
looking
for
and
what
the
use
cases
would
be
great
and
the
team
can
die.
Yeah.
A
All
right
now,
thomas,
you
know
back
in
june,
16
thomas
presented
at
the
go
to
arrows
event,
told
that
included
cartographer.
A
He
made
the
these
lights
public,
we'll
put
the
link
in
the
chat,
so
we
can
add
it
to
the
notes
please,
and
he
was
kind
enough
to
to
bring
here
the
feedback
he
got
from
attendees,
so
yeah.
Thank
you,
thomas.
Not
only
for
setting
up
a
talk,
including
cartographer,
but
for
taking
the
time
to
reach
to
us
and
yeah.
A
E
Yeah,
the
presentation
was
very
well
received.
There
were
also
attendees
like
with
not
very
familiar
with
kubernetes
that
really
were
excited
about
the
developer,
experience
with
the
cartographer
and
the
separation
of
concerns.
So
the
fact
that
moving
to
kubernetes
for
them
with
cartographer,
wouldn't
mean
to
learn
of
the
tools
and
having
that
cognitive
load
that
for
developers
it's
a
problem.
E
Nowadays,
I
found
really
useful
to
present
this
from
imperative
versus
reactive
systems,
point
of
view,
so
with
the
standard,
ci,
cd
pipelines
being
an
imperative
system
and
then
githubs
that
kind
of
split,
the
last
part
of
the
traditional
ci
cd
pipeline,
making
it
reactive
and
based
on
declarative
language
and
then
extending
that
kind
of
process
to
the
whole
pipeline,
making
it
a
reactive
system
so
a
resilient
and
responsive
and
message
driven
and
then,
at
that
point,
introducing
cartographer
as
the
solution.
E
Like
the
two
main
points,
I
think
that
were
the
most
well
received
or
and
where
the
separation
of
concerns
so
less
troublesome
developers
and
the
fact
that
it's
quite
flexible,
so
you
can
choose
different
technologies
and
you're
not
tied
to
a
specific
platform,
but
it's
quite
flexible.
You
can
provide
some
yeah
paved
path
to
production,
but
you
can
customize
it
as
you
wish.
So
it's
it's
quite
flexible
from
that
point
of
view
yeah.
So
that
was
good,
so
that
was
yeah.
E
It
was
very
well
received
on
the
improvement
side.
I've
been
yeah.
I
got
comments
about
the
lack
of
a
gui
and
in
particular
like
a
developer
friendly
way
of
knowing
what
is
happening
through
in
this
path
to
production
and
in
particular,
if
something
fails
how
to
address
that,
because,
with
the
workload
abstraction
you
only,
the
developer
only
provides
yeah
a
few
information
that
developers
are
aware
of.
E
But
if
something
fails,
then
you
need
to
know
how
it
works
under
the
hood,
and
that
was
pointed
to
me
as
a
as
an
issue
also
in
a
in
a
production
scenario
that
the
developers
pushes
some
code
it
does
fails.
Then
how
to
get
that
visibility
or
to
know
right
away
that
something
failed,
so
that
the
developer
can
fix
that
before
moving
on
to
the
next
task,
like
in
the
spirit
of
continuous
integration
yeah,
I
think
that
was
the
gist
of
it.
E
So
positive
feedback
excitement
about
separation
of
concerns
and
this
reactive
system
that
is
quite
flexible
and
comments
on
at
least
lack
of
a
gui
or
something
more
developer
friendly
to
to
get
information
about
what
is
happening
in
the
supply
chain.
C
Is
great
that
gives
us
some
some
validation
of
both
the
increased
for
things
like
status,
on
workloads
status
for
each
of
our
individual
individual
resources?
Things
like
the
the
events
that
rash
was
just
talking
about
that
we're
intending
to
implement,
as
well
as
artifact
tracing
to
say:
where
are
your
changes
in
your
supply
chain?.
B
I
believe
there
is,
I
believe
there
is
discussion
around
making
what
is
a
tanzu
private
product
at
the
moment,
public,
which
is
the
what's
the
framework
we're
using
backstage
a
backstage
plug-in
for
visibility.
B
I
don't
know
where
that's
going,
but
I'm
I'm
hopeful
that
that
might
come
to
the
fore
and
and
be
the
thing
that
people
can
use
to
get
some
quick
graphic
user
interface.
Not
sure
can't
make
any
promises,
but
there's
discussion
about
that
kind
of
thing.
It
would
probably
appear
in
the
panzer
community
edition.
I
guess
we'll
see
it's
understandable
for
sure.
E
Yeah,
I
think
it
would
also
help
when
yeah,
explaining
cartographer
for
people
new
to
the
project.
I
think
just
visualizing
in
a
simple
way.
What
is
going
on
so
both
like
the
production
side,
but
also
like
for
yeah,
sharing
the
project
and
advocating
for
adopting
it.
B
B
C
B
At
all
I
mean
we
also.
We
also
do
have
that
that
live
editor,
which
is
my
my
concern
for
people
who
are
trying
to
understand
how
to
build
their
first
supply
chains.
I
would
certainly
like
to
see
more
effort
go
into
generating
that,
if
you're
not
aware
of
it,
there's
the
live.
Editor
big,
big.
E
A
I
think
thomas
yeah,
I
think
the
summaries
we
are
at
it
most
of
the
rfcs
discussed
here
are
exactly
geared
towards
that
direction.
Providing
more
observability,
I
will
say
so,
yeah.
No,
thank
you
for
your
feedback.