►
From YouTube: Cartographer Office Hours, August 15th, 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
A
No,
no,
I
understand
I
do
understand
so
long
time
coming.
The
blueprints
proposal
has
been
external
and
then
internal
and
is
now
external
again,
so
we're
here
to
share
it.
This
goes
into,
I
think,
quite
a
lot
of
detail
about
why
lots
and
lots
of
detail
according
to
emily,
because
you
had
to
copy
it
all
it.
A
It
references
two
important
two
important
links
this
one
here,
which
is
the
three
crds
with
documentation
that
we're
proposing
for
blueprints
as
a
complete
replacement
for
supply
chains
and
an
implementation
example
of
one
of
the
that's
not
actually
of
any
of
the
supply
chains.
But
it
was
a
supply
chain
that
would
have
all
of
the
problems
that
we're
trying
to
tackle
things
like
reason
to
nest,
something
and
need
to
rename
parameters
and,
and
all
that
kind
of
thing.
So
that's
there
for
everyone
to
look
at
and
provide
feedback
on
as
well.
C
Yeah,
no,
this
will
be
awesome
I'll
I'll,
take
a
look
at
it
again.
B
C
A
A
So
that
is
we're
not
going
to
create
something
that
would
then
leave
people
adrift
and
not
able
to
consume
blueprints
in
the
future
and
important
enough
for
some
value
of
important,
which
I
guess
would
be
designed
by
decide
decided
by
by
committee
or
product
or
I'm
not
sure
who.
A
But
the
general
idea
is
at
the
moment
the
work
is
to
shore
up
security
and
and
stability
of
the
existing
system,
while
also
working
on
the
new
blueprints.
That's
the
main
plans.
A
Was
there
something
in
my
you
had
in
mind,
scott.
C
No,
no,
it
was
just
based
on
the
previous
office
hours,
where
the
conversation
was
going
on
of.
Do
we
make
the
cut
over
to
a
new
api
type
now,
which
is
something
that
you
really
only
want
to
do
once
and
not
many
times
do
a
full
revamp
of
a
project
was.
I
know
there
were
differing
opinions
amongst
people
of
how
that
should
be
done.
If
we
wanted
to
do
the
break
now
or
try
to
iterate
the
changes
into
supply
chains,
and
then
I.
C
A
A
We
did
you
know
to
your
question
before.
Actually
there
is
one
thing:
that's
on
my
mind
that
I
would
like
to
float,
which
is
at
least
having
go,
based
template
table
testing
for
templates
and
supply
chains,
so
the
folks
can
do
unit
testing
without
having
to
have
a
cluster
running
to
you
know,
prove
that
proves
that
the
templates
are
stamping
how
they
expect
them
to
the
ytt
is
doing
what
they
expect.
Inputs
are
being
picked
up,
the
way
they
expect
and
that
they've
they've
configured
a
supply
chain
correctly.
A
C
A
B
Not
really
one
question:
are
the
blueprints
rfc
updated?
Is
that
in
a
pr
or
is
it
or
did
you
push
straight
to
the
like
to
the
repo
already
just
wondering
if
there's
space
for
scott's
trout,
to
like
put
comments
and
stuff,
it's.
B
A
I
was
looking
for
it
so
that
we
could
share
that.
A
Well,
service
accounts
will
affect
this
because
this
doesn't
discuss
service
accounts.
Why
can't
I
paste
there?
A
We
go
okay,
service
accounts
will
affect
us,
because
this
does
not
talk
about
where
we're
going
to
land
service
accounts,
and
I'm
I've
been
talking
to
folks
about
the
thing
that
I
said
to
you,
the
proposal
I
said
to
you
and
I'm
still
strongly
in
favor
of
that,
because
I
think
there
are
a
couple
of
patterns
we
can
use
to
really
strengthen
habits,
because
your
concern,
I
think,
was
that
folks
get
in
the
habit
of
doing
star
right,
start
type,
permissions
and
right.
C
A
Right
so
one
one
thing
I
will
be
recommending
is
that
all
templates
blueprints,
you
know:
blueprints
that
carry
any
kind
of
creation
also
have
in
their
dock
a
a
cluster
binding,
a
cluster
role,
sorry,
and
that
cluster
role
defines
the
roles
required
to
use
that
template
and
a
label
match
to
a
global
cluster
role
binding
for
cartographer,
so
that
when
you
delete
the
delete
or
add
the
the
document
for
your
template,
you
also
take
the
the
role
binding,
less
garbage
collection
issues
with
that
approach,
as
well.
A
And
if
that's
not
sufficient,
I
think
scott
was
scott.
Andrews
was
talking
about.
Perhaps
we
do
have
service
accounts
described
at
the
binding,
the
blueprint
binding
level.
So
that's
the
object
that
selects
blueprints
against
owner
objects
and
that
would
specify
what
surface
account
to
use.
C
Yeah
and
I
think
with
aggregated
roles,
it
could
be
made
a
lot
better.
I
didn't
think
about
that
option
before
and
if
someone
did
do,
if
we
do
end
up
implementing
the
name,
spaced
blueprints
at
some
point
and
not
just
the
cluster
ones,
then
you
could
just
do
a
roll
for
that
specific
name
space
which
someone
may
have
the
ability
to
do
that
doesn't
have
the
ability
to
create
cluster
ride
wide
roles
in
whatever
and
allow
iteration
in
that
manner.
Yeah.
B
C
B
Yeah
to
do
anything
to
the
namespace
level
we
would
have
to
so
I
guess
either
you
have
to
grant
the
permissions
to
cartographer
cluster-wide
or
we
would
have
to.
B
Allow
the
blueprint,
mapping
or
binding
to
specify
a
service
account,
and
if
it's
a
name,
spaced
mapping,
then
it
would
only,
but
then
the
service
account
will
have
to
exist
in
that
same
name.
Space
and
the
permissions
would
have
to
be
bound
into
that
service
account.
A
C
So
it's
more
the
first
one
and
the
reason
that
I
find
that
problematic,
because
I
know
that
by
default,
let's
say
there
was
a
platform
that
was
a
commercial
product
that
used
cartographer
out
there
in
the
ether
and
it
decided
to
use
whatever
k
native
and
kpac
and
other
things.
It
would
have
those
things
and
would
have
scoped
on
our
back,
but
the
second
we
get
into
the
idea
of
namespace
supply
chains
and
people
start
building
their
own
and
start
adding
different
descriptors
and
different
crds
and
different
things.
C
What's
going
to
happen
is,
is
that
over
time,
the
platform
administrators
are
going
to
get
really
annoyed
with
the
amount
of
times
they
need
to
change
our
back
and
they're.
Just
going
to
add
cluster
admin,
star
star,
star,
aka,
tanzu
package
install
and
basically
we're
going
to
have
a
bunch
of
basically
cartographer
will
be
able
to
do
whatever
it
wants
to
do.
Traceability.
C
B
Yeah,
I
definitely
agree
with
that.
Also,
it's
the
nature
of
our
back
that
we
can't
ever
prevent
that
like
if
someone
with
permissions
to
create
a
cholesterol
binding,
creates
a
cluster
role
binding
to
cluster
admin.
C
Exactly
that's
where
like,
if
this
is
the
that's
where
I
was
saying
like
that,
was
my
one
caveat
with
this
approach,
where
what
I
had
mentioned
to
russia
was,
I
think
this
from
a
ux
perspective,
makes
it
so
much
easier
right,
like
I
don't
need
to
give
the
permissions
to
the
service
account
for
the
user
in
every
single
name
space
to
be
able
to
stamp
out
all
these
resources
right
from
a
ux
perspective.
It's
great
there's
other
tools
out
there
that
are
doing
similar
things
right.
C
C
On
the
other
hand,
when
those
resources
could
be
anything,
I
want
them
to
be
and
any
crd,
and
when
that
becomes
the
case,
the
question
becomes.
How
often
will
it
be
that
a
platform
will
not
have
cluster
admin?
If
this
is
the
approach
because
down
the
road,
especially
if
name
spaced
blueprints
get
implemented,
that's
where
people
are
going
to
start
writing
their
own
controllers
and
writing
their
own
crds
to
do
random
things,
and
it's
just
going
to
get
out
of
hand.
A
C
I
mean,
at
least
from
my
perspective,
the
way
that
I
view
it
is
that,
once
we
move
everything
into
a
single
type
of
crd,
basically,
I
know
we
have
the
descriptor.
We
have
the
blueprint
whatever
selector
we
have
different
crds,
but
once
a
cluster
supply
chain
and
a
cluster
templated
cluster
config
template
image,
template
source
template
all
those
become
one
cr.
I
lose
the
granular,
the
granularity
of
saying
that
a
user
can
edit
a
template
but
can't
change
a
supply
chain.
C
I
lose
granularity
of
being
able
to
manage
our
back
of
cartographer
and
having
the
namespace
allows
me
to
say
great
what
my
paved
paths
to
production
that
I
support
as
a
platform
team
are
the
cluster
supply
chains.
You
want
to
build
your
own
custom.
Things
go
right
ahead,
build
your
namespace
ones,
that's
not
supported
by
us,
but
you
can
go
ahead
and
play
with
that.
Get
your
thing
running.
If
you
want
it
supported,
you
pass
that
in
for
us
to
review
and
we'll
add
it
into
a
cluster
supply
chain.
C
A
Then
it
comes
down
to
what
the
that
is,
the
create
update,
sorry,
the
create
and
read
of
a
resource
all
right.
C
They
could
only
do
that
to
resources
that
the
platform
admin
has
allowed
in
the
rbac
for
it
to
work
with,
because
a
typical
developer
does
not
have
cluster
role,
binding
creation
capabilities
right,
that's
usually
a
much
higher
level
right
like
when
we
think
about
it.
Our
back
is
usually
going
to
be
the
admin
teams
that
are
going
to
be
managing
that.
So
you
get
back
into
the
oh.
C
You
want
to
create
something
bespoke
and
kind
of
get
around
us
as
you're
iterating
and
want
to
build
the
right
supply
chain
for
your
type
of
application-
great
open
a
ticket
to
us.
So
we
can
create
the
role
bindings
for
you
for
your
things,
then
go
back
and
forth
on
why
you
need
these
roles
and
then
they're
also
cluster
wide.
B
A
Yeah
I
mean
I,
I
was
thinking
more-
that
the
create
the
create
the
create,
update
and
and
read,
and
it's
real
there's
really
no
status,
update
right,
just
create,
update
and
read
of
those
templateable
objects
in
the
namespace
supply
chain.
That's
that's
roles
that
we
give
to
cartographer.
A
We
say
that
cartographers
allowed
to
create
these
objects
and
if
cartographer
says
it's
only
ever
in
the
namespace,
it's
not
our
back,
but
it's
cartographers
rule.
These
can
not
only
be
in
the
same
namespace.
You
can't
create
this
somewhere
else.
A
Is
there
much
more
to
apply
for?
I
guess
I'm
not
saying
what
the.
C
Well,
the
issue
is,
is
how
do
you
tell
cartographer
that
I
have
a
new
foo
dot
bar
crd,
that
I've
created
right?
I've
used
meta
controller
operator
sdk,
whatever
I
built
my
own
crd,
that
does
canaco
instead
of
a
tecton
pipeline.
Let's
say
just
as
an
example,
and
I
created
my
own
crd-
it's
not
one
that
the
platform
team
is
utilizing
today
they
haven't,
let
cartographer
create
that
all
right
right.
C
It's
actually
great
to
see
a
tool,
that's
lowering
the
amount
of
crds
they
have,
instead
of
increasing
to
thousands
like
crossplane
does,
but
I'm
making
it
simpler,
because
every
other
tool
is
just
getting
more
complex.
I
think,
but
the
question
comes
when
we
get
this
proliferation
of
crds,
that
people
are
going
to
want
to
stamp
out.
How
do
we
manage
that?
Our
back
in
a
sane
way.
A
A
Please
make
sure
that
only
we
can
use
it.
I'm
not
sure.
I'm
not
sure
that
that
really
applies
here,
but
just
to
say
that
it
does.
A
C
But
is
there
a
way
of
saying
because
in
this
case
the
service
account
is
not
in
the?
U
in
the
workloads,
namespace
it's
in
the
namespace
or
the
descriptor's
namespace
or
whatever
it
would
be
called
now
it's
in
the
cartographer
system.
Namespace
is
there
a
way
of
saying
you
can
create
object
x
only
in
namespace
y.
B
C
C
R,
that
said,
allowed
name
spaces,
and
if
that
was
there,
it
was
or
restricted
namespaces
that
you
could
add
to
a
cluster
role
binding.
That
would
be
an
aggregated
cholesterol
binding.
That
would
say
this
specific.
These
roles
are
only
for
this
name
space
and
then
cartographer
would
block
it.
It
wouldn't
be
q
bar
back.
It
would
be
cartographers
saying
I'm
not
going
to
do
this
in
another
namespace.
A
C
Right
as
long
as
it's
cluster
supply
chains,
then
it
could
be
the
way
it
is
right.
Now,
when
you
add
namespace,
you
had
an
optional
field
that
if
it's
a
namespace
supply
chain-
and
you
want
to
add
specific
permissions,
then,
but
the
question
is
how
much
change
would
that
be
to
the
core
code
of
cartographer,
then
to
start
using
a
different
service
account
instead
of
what
you're
using
today,
meaning?
Is
that
just
pushing
it
off
and
then
adding
a
lot
more
complexity
of
refactoring
to
support
both
methods
down
the
road.
A
Don't
work
that
way,
I
I
am
certain
that
the
rest
of
us
are
going
if
it
is
something
that
we
can
say
is
a
bridge
far
away
all
right,
then
let's
leave
it
as
a
bridge.
Far
away,
we've
got
a
solution
to
what
could
be
done
and
we
know
what
might
need
to
be
done
to
make
it
happen.
Today
we
don't
have
to
incorporate
that
complexity
to
implement
so
yeah.
B
A
I
think
that's
the
way,
I'd
look
at
it
and
pretty
sure
the
rest
of
the
team's
the
same
yeah
I
mean
we've
already
had
to
do
it,
so
we
already
had
the
experience.
What
it's
like
to
bring
in
lots
of
different
rules
around
how
we
all
attach
service
accounts
and
what
it
has
done
is
has
introduced
complexity,
that
it
doesn't
require
a
refactoring
it
just
it's
just
complexity,
it's
about
watching
the
bindings
and
the
it's
about
becoming
responsible.
A
The
controller
has
a
service
account
and
when
things
change
for
that,
the
controller
just
follows
those
rules.
I
can
now
create
api
just
works
as
it
should,
but
we
have
to
sort
of
re-implement
all
that
kind
of
logic
internally,
when
we
accept
service
accounts,
because
we
have
to
watch
for
role
bindings
and
we
have
to
watch
four
roles
changing
and
yeah
right,
yeah,
it's
just.
It
makes
the
code
more
complex
and
it's
like
if
we
want
to
move
fast,
get
a
new
thing.
A
C
Yeah-
and
I
think
that,
as
long
as
we're
not
talking
about
namespace
from
my
perspective
with
aggregation,
I
think
it
it
can
make
sense
and
it
definitely
makes
the
ux
of
developer
namespace
preparation
much
easier.
It's
not
a
full
line
wall
of
the
ammo
that
I
need
to
apply
in
every
single
namespace.
C
C
Nope
nothing
from
my
side.
I
have.
I
just
released
four
new
supply
chains
that
I
just
created,
which
are
fun
and
I've
been
working
on
building
a
bunch
of
custom
ones
now
which
I'm
starting
to
build
out
a
catalog
kind
of
on
github
of
different
cartographer
supply
chains.
Oh.
C
Yeah
or
auto
pushes
backstage
or
auto
pushes
the
delivery
the
deliverable
yaml
as
well
to
get
so
that
I
don't
need
to
do
a
get
and
clean
out
17
different
fields
to
apply
it
to
the
second
cluster
to
a
runtime
cluster.
So
a
bunch
of
changes
like
that
and
built
a
helm.
One
also
that
just
deploys
a
flux,
cd
helm,
chart
and
knows
how
to
template
that
out
with
ytt.
C
A
B
B
C
That's
the
organ
is
it's
just
the
org
that
I
opened
up
where
I'm
putting
a
bunch
of
tap
stuff
but
including
a
bunch
of
cartographer
and
then
accelerator
and
other
fun
things
just
a
playground,
basically
of
things
I
built
for
customers.
B
A
A
Great,
that's
super
exciting.
C
I
doing
with
the
carvel
team
on
the
helm,
one
to
figure
out
how
to
do
something
in
ytt
for
like
two
days,
because
it
was
a
very
edge
used
case
of
how
to
accept
the
path
of
a
variable.
Is
a
dot
notated
string
to
where
to
replace
the
image
that
comes
out
of
kpak
or
k,
arcanico
into
a
chart
value
and
then
how
to
replace
that
into
a
yaml
fragment
to
become
an
overlay,
which
was
a
interesting
thing.
But
it
ended
up
being
like
10
lines
of
ytt
star,
large
stuff
right.
But.
A
We
have
yeah,
no,
I
won't
hold
people
up
much
longer,
but
we
have.
We
have
somewhat
of
a
conflicting
point
of
view
about
like
using
ytt
this
way,
in
the
sense
that
when
you
start
doing
clever
things,
it's
probably
best
to
build
a
controller,
but
at
the
same
time
it
makes
it
less
portable
right.
It's
I'm
kind
of
hoping
that
that
we
can
use
blueprints
in
both
in
in
sort
of
like
both
capacities.
B
C
Exactly
and
I
think
that
ytt
is
a
great
escape
hatch,
that
I
try
to
stay
away
from
as
much
as
possible,
but
you
utilize
and
it's
great
to
have
there
as
the
escape
hatch,
because
the
overhead,
also
from
a
customer's
perspective,
of
maintaining
and
updating
a
controller
just
in
terms
of
even
if
you
just
want
to
maintain
from
security
vulnerabilities,
forget
the
fact
that
you
actually
have
to
learn
a
programming
language
and
write
a
controller
and
understand
how
controller
runtime
works
and
all
the
fun
of
that.
C
C
It's
like
okay,
like
that's
relatively
easy,
but
just
the
maintaining
of
that
is
much
more
difficult
than
ytt
right,
so
that's
kind
of
where,
like
in
cartographer
conventions,
I
know
the
idea
was
brought
up
in
an
issue
and
I
had
plus
one
the
idea
of
having
ytt
for
cartographer
conventions
instead
of
just
web
hooks,
because
it's
a
easy
escape
hatch
that
a
lot
that
makes
it
more
accessible
for
someone
to
do.
Is
it
the
best
idea?
C
A
C
A
If
we
can
get
that
to
work
in
an
lsp
for
for
cartographer
as
a
sub
language,
that
would
be
really
awesome.
C
Exactly
once
they
have
that
to
like
be
able
to
nest
that
into
a
ytt
section
within
cartographer
and
exec
out.
That
would
be
huge
yeah,
but
yeah,
that's
something
that
is
definitely
on
the
ytt
team's
mind
after
I
have
been
telling
them
for
the
last
year
that
I
want
that
and
now
they're
also
wanting
it
once
they
figure
out
how
to
write
an
lsp
is
what
I
was
told.
C
Exactly
but
yeah
I
know
so
they're,
so
I'm
definitely.
I
think
that
that's
moving
in
that
direction
in
carbo,
which
will
make
it
much
easier.
I
would
think,
hopefully,.
B
C
Though,
what's
better
sarah
or
sen,
or
what's
the
new
language
for
crds
that
was
developed.
C
Ceo
from
google,
the
okay,
whatever
common
expression,
language,
which
is
the
new
rego
that
came
out
from
what's
it
called
that
just
came
out
from
google-
that's
basically
just
rego,
but
from
google.
B
C
Well,
no,
it's
a
validation
language
for
crds.
You
could
write
validations
like
instead
of
writing
admission
web
hooks.
You
could
actually
have
it
in
your
crd.
You
could
have
sell
to
validate
things
instead
of
needing
a
validating
web
hook.
It's
actually
interesting
in
that
sense,
but
it's
they
couldn't
have
chosen
a
language
that
anyone
knew
because
they
have
to
be
unique.
C
B
A
C
Was
a
good
talk?
There
was
a
good
talk
at
cubecon
about
bringing
web
assembly
into
the
cube
api
server
to
not
require
aggregated
api
servers,
but
to
be
able
to
run
web
assembly
programs
within
the
api
server
itself
for
admission
web
hooks
and
mutating
web
hooks.
C
A
C
B
Is
why
I
mean
there's
two
different
syntaxes
within
it,
but
it's
it's
very
low
level.
Let's
just
say
that
it
is
on
the
assembler
part
of
it.