►
From YouTube: Cartographer Office Hours - May 23rd, 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
Anything
anything
I
do
wrong
is
because
I'm
new
to
this
there's
the
there's
the
hackmd
for
today's
notes.
Please
pop
your
name
in
there
if
you're
a
vmware,
just
stick
yourself
on
the
same
line
as
me,
and
and
if
someone
could
take
notes,
that'd
be
great
someone
up
to
taking
notes.
A
So
at
the
moment
the
the
only
outstanding
rsc,
the
only
thing
that's
looks
like
it's
ready
to
move
that
I
could
see,
was
the
introduce
gates,
events
which
is
simply
sitting
in
a
final
comment
period,
and
we
have
not
seen
anything
since
so
I
suspect
we
can
call
that
accepted
unless
anyone
has
any
last
minutes
concerns.
A
Happy
to
just
call
it
now
accepted
so
anyone
else
anything
else,
currently
pressing
we're
heading
towards
a
sprint
to
try
and
deliver
our
0.0.4
milestone.
A
B
We
can
give
a
bit
of
feedback,
I
think
came
up
a
few
a
number
of
times.
There
was
a
talk
of
it
and
including
the
talk
very
very
well
attended.
So
I
think
there's
a
good
amount
of
understanding
and
interest
in
it.
There's
a
few
discussions
we
have
as
well.
I
think
also
met
scott
as
well
who's
in
the
call
which
is
quite
nice.
B
So
I
think
I
think
one
of
the
things
that
really
jumped
out,
I
think,
was,
I
think,
the
other
projects
of
the
doing
you
know
building
on
top
of
kubernetes.
I
think
when
I
was
going
around
some
of
the
areas-
and
you
know
talking
with
them
and
understanding
having
a
little
bit
of
a
look
at
what
they're,
what
they're
doing.
I
think
this
is
similar
challenges
around
complexity
and
things.
B
I
really
think
you
know,
I
love
what
the
work
that
we're
doing
the
focus,
what
we
have
around
the
feedback
we've
already
have,
and
what
we're
doing
to
address
that
those
things
things
like
the
blueprint,
rfc
and
other
things
like
that,
and
the
other
surfacing
areas
and
stuff
like
that.
That
was
really
just
one
of
my
takeaways,
so
definitely
super
interesting
supply
chains
is
a
very
hot
topic
at
the
moment.
B
Understandably,
and
then
I
guess
how
we're
looking
at
doing
some
collaboration
integrations
with
some
of
the
other
open
source
projects
would
be,
would
be
really
good
as
well.
A
C
Once
you
once
you
build
you're,
going
to
push
you're
going
to
push
some
kid's
configuration
to
a
repo,
and
I
that
question
of
are
you
pushing
it
to
one
repo
and
then
you
pull
from
that
one
repo
to
a
number
of
a
number
of
different
environments
that
they
all
or
do
you
say
if
you,
if
you
or
do
you,
expect
the
person
who's
writing
to
build
the
supply
chain,
has
knowledge
of
and
has
control
over
how
many
different
types
of
environments
that
can
be
pushed
to,
because
right
now,
if
you,
if
you
push
to
just
one
repo-
and
you
expect
like
oh
yeah,
the
people
like
the
the
deliverables,
the
deploys
on
the
other
end
of
things
that
are
going
to
pull
that
that
configuration
there
may
be
changes
that
they
need
to
make
to
right
size
them
for
what
for
the
cluster
that
they're
using?
C
And
so
you
know,
scott-
and
I
were
talking
about
oh
yeah.
What
would
it
look
like
to
change
that
in
flight
once
you've
grabbed
it
with
your
deliverable
in
delivery?
That's
not
a!
It
sounded
like
a
use
case.
That
is
reasonable
enough
that
we
might
want
an
answer
to
it
so
and
yeah
I
think
scott
had
already
been
thinking
about.
It
was
like
yeah.
C
You
could
just
you
know
if
we
just
allowed
you
to
specify
with
a
json
path,
to
say,
like
oh
yeah,
at
this
value,
replace
it
with
this
somewhat
similar
to
you
know
similar
to
what
ytt
does,
but
in
our
own
cartel
way.
D
I've
been
thinking
about
this,
a
bunch
yeah,
and
I
think
it's
not
just
a
question
of
like
do.
We
need
some
ability
to
modify
one
get
repo.
That's
created
right
from
the
build
cluster
dynamically
as
it
gets.
You
know
installed
into
the
next
cluster
deployed
into
the
next
cluster,
via
an
overlay
or
values
or
whatever.
I
think
it's
actually,
when
you
kind
of
need
to
get
repos,
or
at
least
two
get
repos,
there's
like
the
output
of
the
build
cluster.
That's
something
that
you
want
to
promote
through
different
environments.
D
Right,
like
it's,
some
kubernetes
configuration
it
should
apply
in
different
places,
but
then
each
of
those
environments,
in
many
cases,
could
have
a
get
repo,
that's
specific
to
that
environment.
That
has
other
deployments
in
it
as
well
right,
and
so
I
put
together
this,
like
kind
of.
If
you
don't
mind
if
I
could
pick
up
a
screen
share
from
whoever
yeah,
so
I
put
together
this
diagram
just
last
week,
because
I
was
thinking
about
the
same
thing.
It's
just
like
what
what
is
the
you
know
like?
D
Cluster
would
look
like
I
don't
know
if
this
kind
of
framing
helps
a
little
bit
but
like
on
the
there's
this,
like
maybe
a
producer,
that's
like
on
a
build
cluster
supply
chain
right,
that's
you
know
either
producing
templates
in
a
git
repo
or
maybe
in
the
future
or
home
charts
or
packages.
Right
could
be
the
output
of
that.
You
know
build
cluster,
and
this
is
like
templatized
configuration
right
now.
We
don't
templatize
it,
but
it
really,
you
know,
like
I
think,
we're
like.
D
Oh,
you
could
put
overlays
over
it
when
you
deploy
it
just
kind
of
what
you
were
talking
about.
You
could
do
dynamically
in
the
other
environment
right,
but
then
there's
there's,
maybe
this
middle
step
that
we're
not
talking
about
that's
like
interpolate,
whatever
this
is
and
commit
it
to
an
environment,
specific
get
repo
and
then
pick
up
that
environment,
specific
git,
repo
and
deploy
it
and
like.
Maybe
even
these
are
separate,
get
repos
like
you
know
this.
A
Yeah
one
of
the
things
that
I
think
this
solves
for
that
that
people
are
bringing
up
fairly
regularly
internal
customers
of
vmware,
but
also
others
I've
talked
about.
Can
we
use
this
for
delivery?
Not
for
deployment?
So
can
we
have
packages
at
the
end
of
our
chain,
and
packages
need
to
be
configurable
all
right,
so
that
first
step
definitely
rings
true,
and
if
we
can
incorporate
that
at
all
times,
that
would
be
like
in
all
of
our
demonstrations
and
and
likely
scenarios
for
supply
chains.
That
might
be
more
appreciable.
That
way.
D
A
E
That
is
something
that
usually
your
dev
cluster
isn't
going
to
be
the
same,
but
changing
the
image
mapped
within
the
deployment
is
something
that
probably
shouldn't
be
changed,
because
if
you
do,
what
help
did
it
do
that
you
did
definitely
before
going
to
prod
and
that's
where
I
think
on
one
hand
having
it.
You
could
already
do
this
through
git
and
having
multiple
get
writers
and
pushed
multiple
places
and
having
app
cr
that
would
pull
in
from
multi
get
fetches
and
whatever
and
do
something
in
that
sort.
E
I
wonder
if
there's,
if
it's
worth
it,
I
mean
wishing
we
were
talking
about
adding
almost
a
descriptive
way
within
the
deliverable
crd
for
like
adding
resources
right,
even
if
it
wasn't
for
everything,
but
just
for
the
things
that
we
know
are
the
common
things
that
someone
would
want
to
change
for
anything
else.
They
can.
E
You
can
use
the
full
git
path
and
you
know,
updates
and
merging
different
repos
and
all
of
that,
but
for
the
common
case,
maybe
giving
that
simple
overlay
mechanism
of
whether
it's
a
json
patch,
if
not
using
ytt
or
a
ytt
overlay,
would
give
a
more
let's
say,
safe
default,
that
someone
wouldn't
start
messing
with
things.
A
I
hear
you
suggest
two
things
there
like
it
sounds
like
one,
but
I
think
it's
two,
which
is
that
deliverables
have
a
shape
for
very
common
configurable
elements,
and
then
the
implementation
in
the
templates
is
to
use
something
like
jsonpath
to
apply
that
as
a
as
a
mutation,
some
templating
further
on
in
the
delivery
right
exactly.
E
B
So
I've
got
some
thoughts
around
this.
I
think
there's
it's
just
taking
a
step
back
slightly.
I
think
where
we
want
to
get
for
different
packaging.
You
know
some
some
folks
are
going
to
be
using
how
some
some
people
folks
are
going
to
use
the
cap
controller
applications
it
some
will
just
do
vanilla
communities,
resources.
B
We
want
to
encourage.
You
could
get
guitars
practices
as
well.
I
think
everything
in
it
should
be
in
the
git
repository
apart
from
secrets.
Generally,
that's
something
I
really
strongly
believe
in
configurations
code
is
a
you
know,
standard
software
in
the
software
industry.
People
really
expect
that
so
everything
apart
from
secrets,
but
you
could
have
secret
references
like
the
external
secrets
or
the
csi
driving
stuff.
So,
but
one
of
the
things
I
find,
I
think
is
so
just
bear
with
me
a
second
rash.
B
One
of
the
things
I
think
is
important
is
how
we
define
that
structure
of
a
githubs
repo,
because
we
want
to
be
able
to
build
automation
over
the
top
of
these
git
repos.
I
think
folks
are
also
when
we
did
this
in
jenkins
decks.
We
started
off
with
lots
of
different
get
repos
and
we
got
the
feedback.
Actually,
most
people
only
want
a
git
repo
per
cluster,
and
then
you
have
your
application
operator
to
be.
Has
permissions
and
we
have
a
configuration
file
in
there.
B
So
that's
environment,
specific
configuration
for
that
cluster,
which
we
then
templatize
and
committed
back
into
the
gateway
park
and
show
people
anytime.
They
want
to
have
a
look
at
what's
going
on
if
it
worked
really
well
and
the
people,
like
the
permission
model
that
way,
because
anything,
any
change
that
goes
into
my
cluster
that
I
own
as
a
platform
operator.
B
I
said:
that's
people
can
pull
requests
into
it,
but
nobody
has
permissions
to
be
able
to
merge
those
those
changes
and
therefore
you've
got
a
nice
clean
quality
gate
changes,
an
approval
mechanism
of
changes
coming
into
your
cluster
that
you
own
and
that
you
can
configure
yourself
and
then
push
out
when
you
want
to
promote
that
one
thoughts.
Sorry
rush.
A
Yeah
I
mean
you,
you
triggered
something
that
I've
been
thinking
about,
so
I'll
ask
for
the
screen
back
again,
stephen-
and
this
is
this-
is
just
some
thoughts
that
I
I
was
having
and
I've
shared
with
quite
a
lot
of
technical
leadership
that
there's
quite
a
I.
I
believe
that
there's
some
sort
of
canonical
record
is
it's
the
workload
and,
in
the
case
of
what
we're
talking
about
with
configuring
deployments
is,
is
very
close
to
a
canonical
representation
of
expected
state
or
desired
state,
and
without
going
into
too
much
depth
here.
A
A
Sorry,
your
delivery,
deliverable
I'll
get
the
words
right,
and
that
should
be
something,
and
it
is
something
that
is
quite
easy
to
add
to
the
what's
written
to
our
get
ops
repo
that
canonical
reference
right.
So
so
I
think,
in
line
with
that,
we
will
be
able
to
take
that
canonical
reference
of
what
went
through
a
supply
chain
or
a
delivery
to
end
up
with
what
we
have
deployed.
A
A
Sorry,
the
deliverable
or
the
supply
chain
the
shape
of
the
blueprint,
not
sure
how
to
tackle
that,
but
it
is
important
that
they
exist
as
being
able
to
deliver,
especially
in
the
supply
chain,
being
able
to
deliver
that
that
patching
life
patching
behavior,
so
something
to
consider
there,
but
definitely
taking
the
workload
or
the
deliverable
into
your
get
ops
repo
and
using
that
as
the
as
the
way
that
you
can
then
apply
it
back
to
a
cluster.
To
keep
on
building
a
no-one
good
scenario
or
known.
A
B
Yeah,
it
could
be,
I
mean
just
very
quickly.
I
could
actually
probably
just
I'll
share
my
screen
scene
as
we're
doing
the
show-and-tell
there
we
go.
Let's
do
something
like
this.
This
is
this
is
one
of
the
this
is
a
reaper
that
gets
created.
So
mostly
a
lot
of
this.
You
can
kind
of
ignore,
but
in
here
you've
got
the
jx
requirements,
which
is
the
environment.
The
cluster
specific
configuration
that
we
have
here
we've
got
some
information.
B
I
mean
this
is
a
typical
one
right,
each
cluster
you're
going
to
want
to
pass
in
a
domain
of
something.
So
that's
a
good
one.
Each
each
cluster
in
each
environment
is
gonna,
have
something
different.
So
this
is
kind
of
like
this
this
and
we
then
have
we
defaulted
to
using
helm
and
then
helm
file.
Helm
file
is
a
way
to
construct
multiple
helm
charts.
So
if
you
go
into
here,
each
one
of
these
folders
represents
a
namespace.
B
You
can
imagine
that
this
this
one's,
maybe
certain
managers
different
one,
so
the
helm
files.
What
you
would
do
is
you
can
have
in
multiple
charts
in
here
to
multiple
charts,
and
you
can
actually
then
add
in
the
template
the
global
configuration
for
your-
and
you
know
your
environment
configuration
which
is
here
which
was
basically
generated
from
a
job
and
then
any
custom
configuration
and,
of
course,
you
can
then
add
in
extra
configuration
into
a
different
from
a
different
folder
within
that
git
repository
if
you
wanted
to.
B
B
So
if
you're
going
to
config
root,
all
of
this
is
regenerate
is
generated,
and
in
here,
if
we
go
to,
let's
go
name
spaces.
Oh
I
don't
jx.
Here
we
go,
let's
do
nexus.
So
what
you'd
actually
see
in
here
is
the
real
degenerate,
any
any
custom
configuration
it
would
actually
be.
The
exact
configuration
that
is
applied
is
effectively
cube,
ctl
applied
inside
the
cluster.
What
that
means
is
you've
got
this
kind
of
really
nice.
B
If
I
look
at
the
commit
and
should
always
change
to
see
every
single
time
what
configuration
is
being
is
going
in
any
stage
change
for
that
cluster
is
exactly
in
that
conflict
root
direction
and
which
was
just
re.
It
worked
really
really
well,
so
I
don't,
I
guess
well,
I'm
going
to
show.
I
think
I
think
you're
right
right.
I
think
there's
something
here.
There's
some
meld
of
some
things.
B
We've
learned
having
that
global
or
configuration
that
we
want
to
be
able
to
provide
in
a
git
repository
is
a
good
thing
being
and
then
maybe
supporting
different.
You
know
ways:
people
applying,
maybe
using
gargo
or
flux
or
cap
controller
or
cubesat
and
applying
the
job,
but
having
providing
this
kind
of
mechanism
per
cluster
seems
to
be
quite
a
nice
way.
A
B
Yeah,
it's
actually
so
it's
all
templated
and
I
seem
to
remember
something
from
jobido.
Actually
once
mentioned
something
similar
to
around
this
expansion
or
something
like
it
was.
I
have
to
dig
out
where,
where
it
was,
but
I
think
it
was
a
nice
approach
and
yeah
they
do
that
in
in
google's
yeah
in
comfy
connect
version
of
this
as
well,
and
it
is
quite
nice
because
then
you've
got
that
is
the
desired
state
and
granted.
B
You
never
really
go
into
this
conflict
group
directory
only
when
there's
something
wrong
and
you
want
to
have
traceability
to
find
out
what
happened
and
what
went
wrong
and
then
you
can
actually
pull
that
out
to
a
pull
request
and
either
revert
it
or
you
know
you
trace
it.
Your
traceability
of
whether
it
was
tracking
down
changes
coming
into
your
cluster.
A
Just
before
I
hand
it
over
to
you,
shimmer
we're
at
nearly
at
time
we'll
just
get
wishima's
last
comment
here
and
then
I'll
just
ask:
if
there's
anything
else,
so
washuma.
C
My
comment
is
a
question
for
steven
look
at
because
yeah
new
ideas.
I
want
a
question
to
make
sure
I'm
building
the
right
mental
model.
D
I
think
the
thing
I
showed
was
intended
to
be
abstract
enough
to
encompass
the
model
that
james
is
describing,
if
that
makes
sense
so
the
same,
but
you
know
they're
they're
I
was
trying
not
to
because
I
think
different
customers
are
going
to
have
different
kinds
of
config.
Sorry
different
end
users
of
cartographer
right
are
going
to
have
different
kinds
of
configuration
mechanisms
and
ways
that
they
want
to
do
promotion
right.
I
can
imagine
one
get
repo
being
used
for
everything,
but
things
getting
committed
back
to
that
get
repo
right.
D
I
could
imagine
all
the
interpolation
happening
at
one
stage
ahead
of
time
in
the
commit
of
the
templatized
thing
and
the
interpolated
configuration
that
getting
promoted
all
the
way
through,
but
I
think
in
the
end,
there's
always
these
stages
of
like
you're,
producing
templatized
configuration
you're
interpolating,
it
you're,
potentially
getting
it
back
into
a
git
repo,
that's
environment,
specific
right
and
you're,
deploying
that
into
an
environment
and
then
you're
signifying
that
the
you
know
original
thing
needs
to
get
reinterpreted
for
the
next
environment
deployed.
Maybe
that
gets
converted
back
together.
D
People
maybe
doesn't
right,
and
so
I
think
it'd
be
great
if
we
ensure
that
we're
from
cartographer's
perspective
right,
the
cartographer
is
compatible
with
all
of
those
different
kinds
of
workflows.
Right
like
there
are
tools
available
to
do
that.
A
We're
going
to
have
to
call
it
there,
but
it's
a
really
interesting
discussion.
Keep
it
going
in
the
open
source
channel,
keep
it
going
in
your
back
channels
and
let's
make
sure
that
we
come
back
to
it,
because
I.
E
A
This
is
a
good
future,
the
discussion
of
the
future
of
cartographer.
So
thank
you.
Everyone
have
a
good
day.