►
From YouTube: Cartographer Community Meeting. - May 4th, 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
Welcome
everyone
very
glad
to
see
here
koran
scott
joining
and
everyone
else.
Thank
you
for
joining
all
right.
Let
me
share
my
screen
real
quick
here
and
again
feel
free,
it's
totally
optional,
but
feel
free
to
add
yourself
to
that
in
this
list,
and
so
we
can
catch
up
later,
no
new
faces
today.
Good
luck!
A
A
A
C
B
Well,
this
is
a
follow-on
to
where
she
actually
did
the
work
to
introduce.
Here
we
go,
I've
got
it
in
my
head
now
introducing
a
status
on
each
resource,
so
you
all
might
remember
you
get
a
status
called
resources
submitted
and
it
talks
about
the
resources
that
got
stamped
out,
but
it
only
talks
about
the
first
one
to
error
and
it
is
possible
for
there
to
be
multiple
and
different
statuses.
B
So
now
all
of
the
resources
in
the
status
output
of
a
workload
also
contain
their
conditions
and
what
caused
them
to
fail
to
stamp
or
those
sorts
of
things
so
that
we
can
surface
much
more
information.
That's
part
of
a
rfc
that
I
think
I
wrote,
but
it's
implemented
now.
I
think
that
was
the
big
change
that
came
in.
A
A
D
B
Well,
that's
what
I'm
looking
for
is
the
use
cases.
I'm
told
that
so
so.
At
the
moment
we
have
a
build,
a
build
and
a
runtime
env
field
in
the
workload.
So
you
can
provide
environmental
variables
for
for
builds
and
environment
variables
for
for
run
time
now
with
services,
it's
only
for
runtime
and
it's
well.
B
I
mean
it
can
be
used
for
whatever
you
like,
but
the
intention
is
that
the
services
field,
the
service
resource
claims
service,
claims,
sorry
bad
memory,
but
those
are
intended
for
use
for
runtime
and
there
are
people
saying
that
we
sometimes
they
want
to
reference
us
secret
through
as
though
it
was
a
service
so
that
they
don't
embed
them
environment
variables
for
build
time.
This
is
specifically
important
for
air
gap
environments.
B
C
Yeah
I
was
going
to
mention,
I
think
james
rawlings
has
he
was
involved
in
a
culture
customer
where
they
were
looking
for
providing
like
credentials
to,
like
you
mentioned,
like
an
internal
artifactory
instance
that
they
have,
but
then
they
didn't
want
to
like
force
the
developers
to
provide
the
the
credentials
to
that
artifactory
instance.
They
wanted
like
to
be
this
like
smooth
experience
where
they
would
potentially
just
say
hey.
C
There
is
a
service
I
need
to
reach.
I
don't
really
necessarily
care
how
I
get
the
the
credentials
in
there.
I
just
know
that
it's
going
to
be
available,
like
he
has
a
secret
in
that
name
space,
which
is
essentially
like
this
example.
I
put
there,
but
again
I
would
definitely
reach
out
to
james
on
that,
because
I
think
he
followed,
through
with
the
with
the
customer.
F
A
Oh
sorry,
thank
you
all
right.
No
problem,
okay!
Well,
I
don't
know
if
this
is
for
the
discussion,
but
mainly
for
you
to
be
aware.
Dance
meetup
is
finally
happening
tomorrow
with
cora,
who
is
here
and
happiness
to
speak
spanish
perfectly,
so
that
would
be
awesome
again
an
opportunity
to
keep
telling
your
story
to
an
audience
that
probably
doesn't
have
english
has
first
language,
that's
great
washuma
interview
or
presentation
in
the
podcast.
A
It's
happening
next
week
on
the
tuesday
next
week
the
cloud
native
fm
podcast
so
make
sure
to
subscribe
and
tune
in
when
this
goes
live
and
also
there.
You
say.
Probably
I
already
mentioned
this.
The
continuous
delivery
foundation
has
a
recently
created
software
supply
chain
special
interest
group,
yet
another
sick
around
supply
chain.
A
It
has
a
kind
of
different
shutter
to
the
cncf
supply
chain,
security,
working
group
and
the
open
set
supply
chain
security
working
group.
This
one
has
a
more
practice
oriented
approach.
I
mean
taking
good
practices
and
trying
to
produce
prototypes
with
different
open
source
projects
and
how
they
will
look
like
in,
at
least
in
a
simulated
environment.
A
You
can
read
out
all
the
goals
here:
the
shutter
founding
members
come
from
different
backgrounds
and
includes
myself
and
they're
mainly
to
learn
and
collaborate
as
much
as
they
can
and
there
will
be
a
they
have
these
scheduled
presentations
getting
to
know
better
some
of
the
projects
not
only
cdf
hosted
projects
like
tekton
or
some
others,
but
in
general
projects
that
work
on
this
space
of
supply
chain
topper
supply
chain.
So
we
are
there
scheduled
for
may
26th
stephen
cyril
will
be
helping
introduce
and
demo
cartographer.
A
C
Yeah
we
didn't
so
I
personally
don't
have
a
lot
of
information
about
the
the
the
event
itself,
but
talking
with
stephen
the
idea
there
is
to
like
have
this
space,
where
we
can
talk
about
like
what
photographer
does
right
now
like
how
it
works,
so
probably
give
some
some
demo
of
what
we
have
right
now,
but
then
also
bring
in
in
that
session.
Some
of
the
like
future
ideas
that
we
have
like
the
blueprint
rfc.
C
So
talking
about
some
of
those
like
looking
forward
things
that
can
be
interesting
for
the
community
that
we
think
like
by,
for
instance,
with
blueprints
allowing
you
to
bring
your
own
like
different
kind
of
descriptors,
like
with
some
of
those
thoughts
around
making
it
like
easier
for
you
to
do
your
own
supply
chain
right.
Make
that
share
that
those
thoughts
we
have
with
the
community.
E
F
Yeah
I
wanted
to
share
just
one
thing
that
just
dropped
into
am
I
sharing
the
right
screen?
Do
you
see
the
cartographer
community
notes
all
right,
I'm
going
to
be
doing
an
enlight
enlightening
session
on
cartographer.
This
is
a
part
of
tanzu
tv.
Whitney
is
a
great
advocate
here
at
vmware.
This
is
a
session
that
is
enlightening
is
geared
towards
more
beginners.
So,
if
you
are
looking
for
something,
that's
not
a
super
deep
technical
diet.
F
If
you're
looking
for
something
that's
going
to
really
just
talk
about,
why
would
you
use
cartographer?
Where
does
it
sit
in
terms
of
cloud
tools
if
you
are
a
new
developer
and
are
trying
to
get
your
footing
and
think
like
okay?
How
would
I
build
an
ecosystem
for
myself
and
like
really
get
ready
for
working
in
enterprise,
there's
going
to
be
a
great
session
for
those
use
cases.
B
B
Is
how
we
could
demonstrate
all
of
those
those
prototypical
cloud
native
apps
as
a
so
did
someone
paste
the
link
already
yep,
someone
has
how
we
could
use
all
of
those.
We
could
demonstrate
those
components
using
supply
chains.
All
right.
I
think
I
think
it's
a
great
way
to
describe
reference
architectures
right
and
I'm
wondering
if
there
is
a
way
that
we
can
actually.
Actually,
I
know
what
I
should
do
is.
I
should
probably
raise
an
issue
and
say:
it'd
be
great:
to
have
community
collaboration
on
that
issue.
B
I'm
I'm
looking
for
whether
there's
someone
who's
more
in
the
realm
of
getting
apps
deployed
and
demonstrating
what
cartographer
can
do,
who
might
be
interested
in
in
hacking
together
a
first
demonstration
of
a
supply
chain
that
will
deliver
these
kinds
of
apps.
So
that's
a
thought
I
might
try
and
dive
in
and
create
an
issue
for
that.
C
B
B
B
B
B
C
But
I
think
I
think
the
problem
with
talking
about
is
like
cap's
gonna
deploy
the
the
application,
but
then
like
the
next
step,
which
is
probably
like
a
runnable
decorate,
the
pipeline
runs
or
test
run
like
you
need
something
different
in
this
spec,
so
that,
like
it
triggers
the
creation
of
a
new
run,
and
I
think
scott's
problem
is
getting
something
into
that
runnable
spec
that
is
different.
Is
that
the
problem.
G
Scott
or
yeah
I
mean
because
within
a
tecton
task,
let's
say
let's
say
that
was
you
know
the
next
step.
It's
easy
enough
to
do
a
with,
like
the
kubernetes
tools,
task
step,
you
could
pull
out
from
the
app
based
off
of
owner
reference
all
of
the
sub
objects
and
get
to
that,
but
how
to
do
when
the
deployment
actually
is
when
the
app
is
reconciled
successfully?
G
So
I've
been
trying
to
think
maybe
I'll
do
it
with
an
arg
with
argo
cds
application,
because
argo
cds
applications
do
give
the
resource
everything
that
was
outputted
from
that
app
is
in
the
status
as
well
similar
to
like
the
workload
in
cartographer
now.
So
you
do
get
more
information
there
than
you
do
in
cap,
but
it's
still
a
bit
difficult
to
figure
out
how
you
can
wait
for
a
resource
to
be
completed
instead
of
just
waiting
on
a
specific
status
field.
G
G
E
B
E
F
E
F
I
was
going
to
say
my
first
thought
is,
if
you
don't
mind
having
extra
outputs,
you
could
key
on
that
successful
field
output
it
as
a
config
and
then
create
tekton
that
creates
some
runnable.
Then
we'll
just
put
put
that
string
in
in
a
meaningless
in
some
field.
That's
not
it's
not
going
to
affect
anything,
maybe
just
a
label,
and
then
you
that
would
give
you
your
runs
after
each
update
of
the
status.
G
Yeah,
the
difficulty
with
that
is
that
a
carvel
app
is
going
to
move
from
reconcile,
succeeded
to
reconcile
every
five
minutes
or
whatever
the
reconciliation
period
is,
so
you
can't
even
base
it
off
of
reconcile
succeeded
because
they
move
back
to
reconciling
until
they
do.
The
diff
see
that
there
is
no
diff
and
then
it
goes
back
to
reconcile,
succeeded
every
five
minutes.
You'll
get
a
tech
ton
run.
Then.
F
Rash
sarah
help
me
because
I'm
I
don't
need
to
investigate
to
remember
where
we
are
at
right
now,
but
I
think
that
if
you,
if
you
had
some
task
around
it,
has
and
there's
some
string
that
the
runnable
is,
is
stamping
out
that.
If,
if
that
string
were
successful
at
time
x
and
then
was
written
to
unsuccessful
and
then
was
written
back
to
successful,
the
runable
would
not
create
a
new
tekton
taskrun.
F
B
B
D
G
D
G
G
E
B
G
B
C
C
Okay
like
well,
if
bob
has
a
cluster
deployment
for
deploying
and
then
like
he's,
making
use
of
the
like
deployment
inside
the
resource
in
the
delivery,
neglected
delivery
to
do
the
locking,
maybe
what
he
could
promote
for.
The
next
reason
could
be
something
like
the
status.observedgeneration,
because
then
that
would
reflect
like
changes
to
the
back
of
the
cap
controller
app,
and
it
would
only
be
propagated
forward
if
ui
and
I
reconcile
succeeded
right.
C
B
C
So
the
idea
was
like
because
for
a
delivery,
you
probably
want
to
do
exactly
what
you're
talking
about
or
like
oh,
like
one
resource
is
deploying
something,
but
then
you
want
to
run
the
tests
after
it
has
finished
deploying
we
had
this.
No,
this
idea
of
in
the
delivery
of
being
able
to
let's
say
for
this
second
resource.
Then
it's
going
to
run
the
tests.
You
reference
that
deployment
in
a
way
that
it
would
only
update
the
runnable
if
that
deployment
succeeded.
It's
like
literally
what
we're
talking
about
here.
Okay,.