►
From YouTube: Cartographer Office Hours - April 04, 2022
Description
00:00 Intro
01:17 Welcome new faces
06:06 Simplify Runnable usage RFC
25:24 Maven support RFC
For more details please refer to the Office Hours meeting notes: https://docs.google.com/document/d/1ImIh7qBrOLOvGMCzY6AURhE-a68IE9_EbCf0g5s18vc/edit?usp=sharing
A
B
C
A
C
A
D
A
A
A
Cool
yeah
welcome,
yeah.
We
are
out
outnumbered
yeah
for
all
the
team,
just
joining
feel
free
to
add
your
questions.
Discussion
topics
to
the
agenda
if,
besides
the
rfc
discussion,
is
there
something
that
you
like
to
see
here,
but
most
of
the
times
the
rfc
discussion
takes
the
entire
session.
So,
okay,
no
problem.
So
in
the
last
session
I
see
we
had
rfc.
A
A
A
A
Okay.
So
in
last
session
there
was
a
new
rfc
introduced,
simplified
runable
usage.
It's
been
sitting
in
review
for
a
couple
of
weeks,
I
believe
so.
I
will
encourage
anyone
there
to
provide
your
comments.
If
there
is
any
comment-
or
if
you
like
to
discuss
this
right
now,
we
could
give
it
a
space.
Is
there
any
comment
around
the
specific
rfc.
H
H
So
so
yeah
the
I
was
here
to
present
this
three
weeks
ago
and
then
two
weeks
ago
there
was
discussion
about
it
and
I
wasn't
it
wasn't
here,
and
so
I
wanted
to
talk
a
little
bit
about
about
those
as
well
as
point
to
another
rrc.
It's
about
this,
so
yeah.
I
I
think
the
one
question
that
came
up
was
simply:
should
we
do
this
like
do
we
need
to
simplify
runnable?
H
Most
users
are
going
to
have
to
do
at
some
point,
so
we
should
simplify
the
things
that
people
have
to
do
really
often,
as
also
point
out
that
when
I
you
know
linked
to
this
issue
in
the
cartographer
kubernetes
slack,
that
cora,
who
is
a
vmware
developer,
advocate,
responded
and
is
like.
Yes,
please
do
this,
so
our
developer
advocates
are
saying
that
we
should
do.
H
It
are
the
folks
that
are
you
know
the
individual
who's
taken
on
the
most
responsibility
for
writing
tutorial
things
for
users
me
saying
that
we
should
do
this.
So
yes,
I
think
we
should
do
this.
Another
question
is:
should
we
be
stamping
out
a
runnable
at
all,
or
should
we
just
deprecate
runable
and
just
have
this
be
a
responsibility
of
you
know
the
workload
controller.
Frankly
personally,
I
would
prefer
that,
but
I
think
that
that
ship
has
sailed.
H
I
don't
see
an
advocate
on
the
steering
committee
that
would
that
would
carry
that
proposal.
If
there
is
a
member
of
the
steering
committee
that
would
like
to
step
up
and
say
like
yes,
let's,
let's
get
rid
of
burnable,
then
like
yeah,
I'm
that'd
be
great,
but
until
then
I
think
what
we
should
do
is
the
approach
that
is
laid
out
here,
which
is
let's
stamp.
H
H
H
I
On
the,
I
think
this
went
through
a
whole
bunch
of
different.
You
know
parts
of
solving
this
problem
on
the
you
know
specifically
on
this.
Simplifying
by
getting
rid
of
a
cluster,
run,
template
right,
and
so
you
just
have
runable
and
the
template
is
embedded
and
runnable
that
design
was
actually
the
original,
like
proposed
version
of
the
architecture
was
like
very
early
on.
It
was
the
like
original
thing
that
was
kind
of
sketched
out
was
like.
I
Could
we
have
a
resource
that
you
know
gets
templated
and
then
because
the
higher
level
template
its
parameters,
change?
It
changes
the
you
know,
inner
resources,
values
which
causes
it
to.
You
know,
register
a
change
and
the
reason
we
didn't
go
with
that
architecture
wasn't
because
we
felt
like
it
was
better
to
have
reusability
of
the
run,
template
or
anything
like
that.
It
was
mostly,
I
think,
cereal.
You
might
remember
this
better
than
I
do.
It
was
mostly
just
because
it
was
hard
to
manage
it.
I
Wasn't
just
having
two
layers
of
templating
and
needing
some
kind
of
escape.
It
was
like
the
there
were
some
problems
changing
as
a
long
time
ago.
So
it's
hard
for
me
to
remember,
like
there
were
some
problems,
changing
the
inner
thing
from
a
templating
language
if
it
was
also
a
template
and
then
having
those
changes
propagate
that
there
was
like
a
really
specific
kind
of
you
know
technical
thing
we
ran
into
I'm
wondering
if
sierra
you
remember
some
of
more
of
those
details,
because
I
remember
we
had
this
conversation.
H
H
A
A
H
Yes,
so
there
are
there's
a
primary
proposal
and
a
secondary
proposal.
The
primary
proposal
is
just
that.
We
use
a
essentially
a
singleton
pattern,
which
is
when
a
workload
pairs
with
a
template
with
a
supply
chain
that
has
a
template
that
says,
lifecycle
immutable
where
a
runnable
will
have
to
be
stamped
out
that
two
things
would
occur.
Both
the
runnable
would
be
created
and
also
a
cartographer
would,
in
that
reconcile
loop
would
check
to
make
sure
that
a
cluster
run
template
had
been
created.
H
That
would
match
with
that
runable,
runnable
and
yeah,
so
the
first
workload
would
involve,
would
kick
off
the
creation
of
that
cluster
run
template
and
every
successive
workload
would
would
check
and
see.
Like
oh
yep,
that
exists,
it's
it
has
the
the
spec
that
I
expected
and
would
be
a
no
op,
and
then
it
would
just
create
the
runnable.
H
The
second
approach
would
be,
as
you
just
said,
we
would
have
to
create
a
new
controller
that
would
reconcile
the
four
temp
or
any
supply
chain
deliverable
template
type,
and
that
would
just
be
for
the
purpose
of
creating
a
cluster
run.
Template
from
a
cluster,
for
example,
a
cluster
source
template
that
was
for
an
immutable
resource.
H
L
L
I
know
it's
hard
to
kind
of
predict.
I'm
just
trying
to
wonder
like.
Is
there
an
order
thing
here,
because
there
is
the
the
blueprint
discussion?
Rfc,
that's
kind
of
out
there
and
being
discussed,
I'm
just
wondering
about
an
ordering
thing.
Does
anybody
do
you
might
have
a
feel
of
that
with
anybody
else.
K
Personally,
I
wouldn't
want
to
block
either
one
on
the
other
and
think
we
can
like
the
singleton.
One
singleton
approach
is
easier
and
simple
yeah,
I
think
more
simple
from
the
start,
and
if
we
get
blueprints
we
can.
We
can
kind
of
extract
that
logic,
but
I
don't
think
it's
necessary
to
block
either
one
of
them
personally.
J
H
H
H
H
J
The
actual
behavior
at
runtime
like
because,
like
for
all
these
resources
like
these
are
cluster
scope,
resources,
so
you're
already
operating
in
a
single
global
namespace,
so
that
for
every
new
resource,
you're
creating
like
you,
have
to
come
up
with
a
unique
name
so
like
if
you're
basing
it
off
of
the
name
of
the
the
cluster
template.
That's
being
that's
immutable
that
you're,
basically,
then
deriving
the
run
template
from
then
like
those
that
have
potential
of
naming
conflicts
with
like
either
existing
resources
or
just
other
resource
happenings
to
exist
so
like.
H
J
J
If
you're
going
to
use
generated
name,
then
you
run
the
risk
and
like
maybe
this
isn't
a
big
risk.
But
you
could
have
two
resources
from
two
concurrent
reconciliations
of
the
same
supply
chain
that
both
are
trying
to
stand
by
the
same
resource,
seeing
that
there
isn't
an
existing
resource
and
trying
to
create
it
and
they
will
succeed.
Because
now
you
don't
have
a
unique
name.
J
J
H
H
I
I
think
there's
a
question
here
of
you
know.
Maybe
you
could
make
this
work,
but
do
you
really
want
to
like
you
know,
is
it
maybe
worth
resolving
the
you
know
to
keep
the
architecture
clean
right,
resolving
the
underlying
issue
of
having
to
have
this
weird
shared
clusters
code
resource
right
before
we
address
the
you
know,
reusability
part,
but
simplification
of
the
random
part.
I
mean
sorry.
H
M
I
think
you
had
a
few
observations
at
the
start
that
you
wanted
to
address,
and
one
of
them
was
do
we
want
to
do
this
versus
no,
and
I
don't
think
you're
getting
any
resistance
to
do.
We
want
to
do
this,
which
is
a
positive
here
right,
but
it
sounds
like
there
are
some
design
factors
that
actually
need
to
be
hashed
out.
M
A
A
N
N
N
L
Yeah,
I
can
maybe
start
something
off
that
helps
I
mean
I
think
there
was
some
some
discussions
and
that
there
was
really
the
aim
of
integrating
with
like
an
artifact
repository
to
be
able
to
consume.
You
know
watch
for
new
jars
or
war
files
that
are
built
from
an
external
system
that
will
probably
start
with
jars,
but
then
going
forward,
and
maybe
other
things,
maybe
other
artifacts,
maybe
helm,
charts
or
different
binaries,
ruby,
gems
or
go
binaries
various
other
things,
and
so
just
to
I
guess
you
know
one
of
the
early
questions.
L
We
were
kind
of
pondering
with
a
few
folks
on
around
here
and
he's
kind
of
expressed
in
this
pr
as
well
rfc
as
well
is
what
level?
What
does
that
ux
look
like,
potentially
to
somebody
configuring
that
workload?
Do
we
want
folks
to
be
able
to
have
to
you
know,
describe
what
that
artifact
is
in
that
workload?
Is
it
something
that
is
maybe
made
them
specific
and
then
extending
we
need
to
add
in
different.
You
know
different
support,
different
binary
types
going
forward.
L
Is
there
something
more
generic
that
could
be
done
potentially,
so
the
is
more
around
the
url,
possibly
unlikely,
but
he
was
more
just
asking
the
questions.
So
we've
got
a
data
record
to
check
that
we
can
come
back
and
we've
asked
that
question.
I
think
some
of
the
challenges
around
that
might
be
about
how
do
you
know
what
the
latest
version
something
is
like
with
maven
you
get
a
metadata
xml.
L
What
other
things
do
would
that
be
implementation
specific
between
different
artifact
repositories,
and
so
I
was
looking
down
on
that
and
I
think
there
was
a
fairly
good
consensus.
I
know
from
the
lots
of
folks
in
the
integration
folks
on
the
court
we're
thinking
more
around
initially
providing
support
for
like
specific
maven
and
extending
growing
that
out.
I
think
I've
got
to
feel
that's
where
the
thread
the
conversations
tend
to
has
tended
to
go
so
moving
away
from
like
a
generic
approach
to
more
of
a
artifact
specific
implementation,
yeah,
okay,.
M
So
rfc
is
already
very
implementation,
specific
for
maven
loading
in
an
artifact.
It's
assumed
to
be
at
the
moment.
It
says:
oh,
it's
maven,
and
that
means
that
you're
picking
up
something
that
is
going
to
be
exposed
as
a
maven
artifact
elsewhere.
It
doesn't
mean
that
there's
a
jaw
or
whatever
else
it
just
means
it's
coming
from
maven,
but
I
think
the
assumption
is
that
it's
going
to
be
of
a
type
that
you're
likely
to
pull
as
a
java
application.
L
L
You
know
I
guess
it
doesn't
have
to
answer
now,
but
in
the
back
of
our
minds,
I
guess
it's
just
having
the
thought
of
what
is
the
things?
Is
there
much
effort?
Do
things
look
terribly
different
for
different
artifact
types,
and
you
know
we
don't
have
to
really
consider
consider
implementation.
Now,
it's
more
just
have
that
in
the
back
of
my
mind
from
the
design
perspective,
what
where
those
lines
might
be
drawn.
So
I
think
that's
the
only
thing
I'd
say.
J
Yeah,
I
I
definitely
think,
because
cartographer
itself
has
a
specific
knowledge
here.
It's
going
to
be
all
defined
on
what
the
actual
resources
the
supply
chain,
stamping
out,
look
like
so
like
in
general.
I
think
the
workload
should
sort
of
like
be
the
80
solution
for
sort
of
the
shape
of
things
that
need
to
get
stamped
out
by
a
supply
chain
so
like.
J
M
I
guess
my
concern
is
that
if
we
provide
this
maven,
a
maven
struct
in
source,
that
is
it
possible
for
that
to
still
confuse
does
it
need
even
more
annotations
to
say
not
only
is
this
a
maven
artifact,
but
this
is
made
of
an
artifact.
It
will
work
on
this
kind
of
supply
chain,
not
on
one
that's
trying
to
pick
up.
You
know
you
kind
of
like
how
git
sources
are
not
enough
to
not
enough
to
know
that.
L
Yeah
it
does
I'm
under,
I
guess
some
of
the
things
and
it
might
be
the
question
for
adam
others
have
been
looking
at
this
one
of
the
main
reasons
that
we
need
to
know.
It's
it's
maven.
Is
it
because
we
need
to
look
at
the?
Why
is
it
the
metadata
imp
file
to
see
what
the
latest
version
of
a
file
is?
Is
that
really
you
know,
and
the
coordinates
is
that
the
main
reasons
of
basically
configure
the
figuring
the
watcher
to
be
able
to
know
where
to
look
for
where
to
pull.
G
G
L
L
O
O
L
Yeah,
and-
and
so
maybe
that
that's
maybe
yeah,
I
agree
exactly,
I
think,
to
add
a
bit
more
articulate
my
question
a
little
bit
better.
I
wonder
if,
as
part
of
this,
we
don't
have
to
think
about
implementation,
just
what
that
spec
changes
might
be.
If
we
were
to
do
a
helm,
chart
and
say
a
go
binary,
you
know
what
would
that
workload
if
change
needs
to
be,
if
it
did
anything,
I
think
that's
all
I'm
wondering.
I
J
So
in
the
case
of
pointing
to
the
maven
artifact
like
a
jar
itself,
is
a
set
of
files.
It's
often
pre-compiled
but
like
if
you
pass
that
through
k-pac
with
the
java,
build
packs
then
like
it
can
still
interpret
that
and
actually
turn
that
jar
into
a
runnable
image,
so
it
can
provide
a
jre
and
everything
else
around
it
necessary
for
it
actually
to
run
so
like
I
do
see
value
here.
On
that
sense,
I
think
the
question
may
be,
in
my
mind,
is
like
okay,
we
had
maven.
J
It's
not
necessarily
a
bad
thing
like
we
can
figure
out
like
what
are
the
common
use
cases
and
sort
of
add
them
as
we
need
to
if
it's
npm,
if
it's
a
rubygem,
if
it's
whatever
like
as
long
as
there's
a
story
around
like
this
artifact
has
source
code,
then
we
need
to
take
an
enrich
and
then
do
something
else
with
it
like.
I
think,
that's
fair.
G
I
think,
from
an
implementation
point
of
view,
it
may
be
that
we
find
that
they're
all
nearly
identical
and
under
the
hood
we
find
very
little
variance
between
them.
One
of
the
reasons
why
I've
kind
of
defended,
at
least
within
our
own
team,
you
know,
having
that
space,
maven
specific
and
being
specific,
is
that
that
code
code
communicates
twice
right
and
talking
to
the
computer.
Computer
is
the
easy
part
right,
so
it
makes
it
a
very
obvious
path
forward
for
an
implementer
and
a
maintainer
to
be
very
specific.
G
It
also
protects
us
from
the
oh
moment.
You
have
three
quarters
of
the
way
through
an
implementation
when
you
find
something
fundamentally
different
between
two
package
repositories,
for
example
that
now
become
very
awkward
to
maintain
in
the
long
run,
but
I
think,
as
far
as
when
we're
thinking
about
ux,
I
think
it's.
The
ux
alone,
where
I
would
say
instead
of
making
everything
appear,
general
from
the
outside,
is
to
appear
as
specific
and
explicit
as
possible
from
the.
I
Outside
wonder,
if
it's
worth
looking
at
this
in
two
parts,
right,
there's
a
maven
key
in
workload
and
the
descriptor
right,
but
there's
also
a
question
about:
do
we
need
a
maven
key
in
the
source
type
right
in
the
source
that
gets
promoted
between
the
stages
right?
If
we're
gonna
say
we
take
maven
as
input.
Currently,
you
know
we
have
two
kinds
of
source
we
can
promote
between
stages,
get
and
blob
right
is
the
plan
to
is.
I
Is
it
if
we
are
just
saying
we
need
maven
in
the
workload,
because
we
would
like
a
clean
interface
for
somebody
to
specify
this
is
my
maven
coordinate
and
then
underneath
we
need
we
need
it
needs
to.
There
needs
to
be
some
knowledge
that
it's
a
maven
coordinate,
because
we
have
to
pull
that
maven,
coordinate
and
find
the
list
of
versions
and
there's
a
bunch
of
maven
specific
code
in
that
integration.
To
a
point
where
you
really
do
need
something
that
says
me
than
in
the
workload
that
that
kind
of
makes
sense
to
me.
I
I
Is
it
gonna
be
weird
that
we're
creating
something?
That's
a
little
disjoint
between
those
two
two
places
you
know
if
you
look
at
descriptors,
are
something
we
could
have
more
types
of
in
the
future,
because
they're
not
we're
not
only
our
templates
are
dependent
on
their
spec.
You
know,
is
there
a
benefit
to
keeping
things
just
to
the
descriptor
level
and
not
pulling
them
into
the
type
system
and
kind
of
more
hard-coding
them
into
the
way
cartographer
works.
M
I
I
Right
now
they
have
the
same
structure
right
yeah,
but
but
in
the
future,
do
we
you
know
I
have
to
think
about
like
does
that
ever
need
to
be
extended
to
account
for
more
different
artifact
types,
because
we
have
this
pattern
of
flux,
get
repo,
always
clones
and
then
hosts
at
the
beginning,
but
I
don't
think
we
intended
that
to
be
the
only
way
you
could
pass
source
through
this.
You
know
thing
right,
maybe
I'm
wrong,
maybe
maybe
maybe
that
is
the
you
know.
E
C
M
J
H
G
C
J
J
It
doesn't
have
to
know
how
to
authenticate
to
an
image
registry
so
like
as
long
as
there's
something
that
produces
source
code,
then
sort
of
just
exposes
it
as
a
url
with
a
tarball
like
the
whole
rest
of
the
supply,
chain's
interoperable,
so
like
what
resource
gets
stamped
out
by
the
supply
chain.
It's
part
of
that
source
component.
J
Now,
that's
inelegant,
it's
not
user
friendly,
but
like
mechanically,
it
can
work
and
then
once
we
see
that
working,
I
think
we
can
go
through
and
say.
This
is
something
that
we
see
existing
in
the
wild.
It's
worth
normalizing
it.
So
we
can
basically
say
when
you
do
when
you
have
a
maven
artifact
like
this
is
how
you
should
specify
it
in
a
supply
chain
and
then
we're
just
sort
of
like
paving
the
road
rather
than
defining
the
road.
H
I
You
know
pipelines
that
promote,
for
instance,
get
repo,
and
you
know
the
commit
to
check
out
in
that
get
repo
from
kind
of
you
know
really
viable.
You
know
options,
although,
admittedly
you
could
use
the
tool
that
way
come
up
with
your
own
set
of
templates
that
work
like
that
right
and
I
don't
think
we
ever
declared
you're
always
supposed
to
use
this
with
flux
so
that
the
ecosystem
stays
compatible.
H
J
M
H
I'm
not
opposed
to
this
as
a
principle,
but
I'll
just
say
that
I'm
I
was
surprised
to
hear
it
as
a
principal
and
I've
heard
rash
say
like
we
should.
We
should
write
our
principles
down
somewhere.
This
would
be
one
that
yeah
as
we
discover
this.
Perhaps
you
know
we
should
kick
it
around
for
a
little.
You
know
kick
the
tires
on
it
and
then
actually.
G
M
I
was,
I
was
kind
of
there's
a
place.
I
keep
going
and
it's
I
don't
know
whether
to
make
an
rfc
for
it
or
not.
Whether
people
just
want
to
shoot
it
down
now
but,
like
I
keep
going
to
this
place
where
I
feel
like
we
should
make
in
this.
This
intention,
by
instead
of
having
the
source
provider,
be
the
first
resource,
it's
nice,
because
it's
a
resource
and
then
you
can
reason
about
it
in
the
order
that
it's
in.
M
But
it
also
feels
to
me
like
it's
the
first
responsibility
that
we
really
expect.
So
I
feel
like
there's
a
special
kind
of
resource,
which
is
the
one
that
turns
source
into
turns
unconstrained
sources
of
different
types
into
a
constrained
type
for
source
and
for
images.
Similarly-
and
I
don't
know
whether
we
should
say
you
know
is-
is
that
something
that
people
shouldn't
even
have
to
try
and
add
to
the
top
of
their
supply
chain?
M
Cartographer
out
of
the
box
will
do
that
and
the
first
resource
gets
a
source
right
based
on
pre-baked
rules,
because
they
always
seem
to
take
the
same
shape.
There's
a
bit
off
to
the
side,
but
I
always
think
that,
because
I'm
like,
I
don't
think
people
really
need
to
reason
about
that
part.
They
need
the
constrained
resource
and
what
they're
going
to
do
with
it
from
there
on
in.
L
So
and
there's
only
a
few
minutes
left,
there's
probably
a
lot
that's
been
talked
about
there.
There
were
some
concrete
actions
or
some
next
steps.
I
think
scott
you
propose
one
around
working
out.
We
can
just
configure
the
current
workload
to
be
able
to
watch
a
even
repo,
ignoring
any
ux
around
that
just
get
it,
get
something
working
and
get
something
being
pulled
in
to
the
supply
chain.
L
Looking
at
how
we
look,
we
look
at
downstream
dependencies
and
then
we'll
get
that
through
and
then
back
up
after
we've
got
that
going
looking
to
see
if
there's
any
commonality
across
different
artifacts
and
then
maybe
we
can
look
at
the
ux
around
what
that.
What
that
structure
of
the
workload
looks
like
if
anything
did
look
at
that
right.
G
That's
there
for
a
reason
right
and
then
the
early
at
the
earliest.
We
have
customers
who
are
looking
to
us
saying
we
need
to
support
artifactory.
Now
we
have
to
understand
that
it's
managers
asking
this
question,
not
developers,
so
I
think
a
lot
of
us
right
away
like
jettisoned
the
idea
of
our
artifactory
in
favor
of
oh
well,
we're
going
to
talk
maven
or
we're
going
to
talk
some
other
supported,
artifact
helm.
G
G
M
M
G
G
M
Answer
your
question:
yeah.
Sorry,
no
really!
My
question
was:
would
there
be
anything
different
in
this?
The
shape
of
the
the
data
that
needs
to
be
provided
by
the
workload?
Remembering
that,
like
security
information,
would
be
at
a
at
a
service
account
level?
It
wouldn't
be
something
we'd
be
passing
across.
So
if
they're
the
same
then
I
would
like
us
to
go
for
the
same
and
then
use
other
selection
criteria
if
we
want
to
be
specific
to
maven.
So
maybe
we
just
want
to
say
yeah
whatever
that
protocol
is
called
the
artifactory.
L
Protocol,
I
just
confirmed
as
well.
It
was
more
than
just
the
next
steps:
it's
not
necessary
to
to
be
able
to
deliver
this.
It's
just
going
in
get
something
going
through
for
the
dancing
dependencies
work
out,
how
that
needs
that
can
come
back
up
and
then
work
on
what
that
polling.
What's
that
watching
really
looks
like
because
then
we'll
understand
more
about
what's
needed
to
come
in,
so
I
think.
L
Yeah,
and
whilst
this
is,
I
know
initially
targeting
the
maven
but
having
in
the
back
having
understanding
what
that's
going
to
look
like,
you
know,
if
we
come
around,
then
in
two
months
time
they
go.
Oh
we've
got
to
do
this
for
helm
or
this
for
go
binary
this
for
rubygem.
You
know
it
may
be
we
might
go.
Maybe
we
should
have
done
it
a
different
way.
So
it's
just
having
that
that
thought
in
the
back
of
our
minds
as
we
as
we
go
through
that
what
that
do
any.