►
From YouTube: Carvel Community Meeting - February 1, 2021
Description
Carvel Community Meeting - February 1, 2021
Meeting information and notes can be found here:
https://carvel.dev/community/
A
A
Eastern
time,
if
it's
your
first
time
joining
us
welcome
so
happy
to
to
have
you
here
just
want
to
do
a
quick
reminder
to
pay
attention
to
our
code
of
conduct
whenever
you
are
attending
these
meetings-
and
I
just
realized
it's
actually
not
on
the
agenda,
but
I
will
add
it
to
the
hut
now
today,
we're
gonna
have
aaron
hurley,
take
over
he's,
gonna
go
over
the
agenda
items
and
what
to
expect
from
these
meetings
moving
forward
so
aaron.
If
you
want
to
take
it
away.
B
Cool
I
can
share
my
screen.
B
Do
some
zoom
manipulation
there
we
go
cool,
so
yeah
welcome
to
our
new
format.
So
you
can
take
a
brief
look
at
the
agenda
and
see
we're
planning
to
just
do
some.
Some
brief
updates.
As
to
the
current
things
we
have
in
flight.
What's
coming
next
planning
to
do
you
know
a
a
deeper
discussion
as
to
what
are
we
planning
for
this
week
so
that
you
know
the
necessary
folks
that
are
doing
the
work
understand?
What's
what's
expected
here
and
then
we
also
have
an
area
for
discussion
topics.
B
So
if
anyone
here
right
now
wants
to
discuss
something,
please
add
stuff
here:
if
there
aren't
any
topics
that
are
added,
then
we
may
just
go
deeper
into
the
story.
Discussions
for
this
week,
cool
so
we'll
start
with
then
some
updates,
so
we've
been
working
on
a
schema's
feature
within
ytt
for
for
a
bit
now,
oh
probably
one
quick
disclosure
is
we
just
switched
to
zenhub
as
our
backlog
manager,
so
we're
still
learning
the
ins
and
outs
of
it.
B
So
please
be
patient,
but
hopefully
you
know
this
will
be
an
area
where
we're
able
to
do
more
of
the
planning
in
in
public
and
and
just
be
more
transparent
of
what
our
backlog
looks
like
so
that
folks
can
see.
You
know
whether
their
issues
are
being
prioritized
and
if
not,
then
you
know
that's
a
good
signal
that
this
could
be
a
great
area
for
you
to
contribute
so
diving
into
this
particular
epic
of
work,
ytt
schemas.
B
B
Type
of
value
is
being
provided
within
your
configuration
files,
we'll
dive
into
what
is
still
planned
for
for
this
iteration.
But
currently
this
is
our
our
immediate
focus.
Once
we
finish
the
structure
checking
we,
oh
sorry,
type
checking
was
done
here.
Well,
I'm
sorry,
we,
this
is
the
mvp
and
then
the
the
second
ytt
schemas
feature
set
is
going
to
be
validations
which
which
isn't
planned
here.
But
but
this
is
our
our
immediate
scope
is-
is
mvp.
B
I
guess
before
moving
on,
I
don't
know,
feel
free
to
ask
questions
throughout
and
also
you
know
other
folks
on
the
team.
Please,
please
feel
free
to
jump
in
if
you
want
to
provide
any
additional.
B
Color
cool,
so
we
have
schemas
that's
in
flight.
Another
track
of
work
that
we're
working
on
is
image.
Package
include
non-distributable
layers,
so
this
stemmed
from
an
issue
that
was
submitted
back
in
august
from
from
eli,
but
the
idea
here
was
there
are
well
image
package
currently
does
not
allow
the
ability
to
relocate
images
with
foreign
layers
to
air
gap
environments.
B
So
an
example
here
would
be
like
microsoft,
proprietary
software
there's,
certainly
you
know
more
context
you
can
get
into
in
in
our
open
source
select
channel,
but
the
the
update
here
is
we.
We
have
been
working
on
this
at
this
point
where
I
believe
going
through
some
some
pr
updates-
and
there
is
just
some
some
additional
cleanup
that
we
came
upon,
but
we're
we're
getting
pretty
close
to
to
landing
this
item
and
providing
documentation.
B
So
this
will
be
a
nice
win
to
make
a
relocation
of
of
you
know,
software
that
has
non-distributable
layers
within
them
so
and
you
can
see
dennis,
provided
the
remaining
items
here.
So
please
feel
free
to
dive
in
or
if
you
have
any
questions
you
know
you
can
add
voice
those
right
now.
B
Cool
we'll
keep
moving,
so
the
upcoming
things
that
we're
planning
to
work
on
is
some
more
image
package
focus.
So
we
have
a
performance
investigation.
B
B
So
this
is
a
feature
where
you
know
you're
able
to
nest
a
bundle
which
is
an
artifact
within
another
bundle,
so
that,
ultimately,
you
can
kind
of
nest
all
the
necessary
dependencies
that
that
you
need
and
and
do
so
in
a
way
where,
ultimately,
you
know
it's,
it's
always
a
bundle
that
you
can
provide,
but
sometimes
those
bundles
can
reference
other
bundles
and
just
kind
of
nest.
B
Logically,
so
we'll
we'll
chat
more
about
that,
once
we
get
into
our
weekly
pen
planning
portion
and
then
similarly,
as
another
thing,
we'll
we'll
dive
deeper
into
today,
is
for
ytt
improving
overlay
error
messages.
B
So
what
we're
trying
to
do
is
is
improve
on
the
existing
error
messages
that
we
we
currently
return,
and
we
we
have
some
a
couple
stories
that
are
are
written
as
ways
that
we
that
we
plan
to
progress
through
through
making
these
improvements.
B
All
right
keep
going
then
so
here
is
our
zenhub
board,
there's
kind
of
a
lot
going
on.
I
generally
try
to
collapse
pipelines
whenever
possible,
but
we
have
this
column,
which
kind
of
shows
what
are
our
our
epics,
which
is
kind
of
like
a
group
of
features,
or
maybe
just
a
particularly
meaty
feature.
B
So
you
can
kind
of
see.
These
are
the
things
that
we
mostly
just
talked
about:
ytt,
schemas,
image,
package,
etc.
Then
prioritize
backlog.
This
is
the
work
that
we're
planning
to
do,
but
hasn't
yet
been
started,
and
then
in
progress
is
work.
That's
currently
picked
up
and
in
progress
like
I
mentioned,
we
did
just
move
to
zenhub.
So
there's
a
little
bit
of
cleanup
here.
B
So
if
we
dive
into
the
plan
for
this
week,
then
we
can
start
by
covering
you
know
some
of
the
stories
that
the
team
has
discussed
already
and
pointed,
but
please,
you
know,
feel
free
to
voice
any
thoughts
as
we
go.
But
so
this
first
story
here-
and
this
is
following
the
the
ytt
schemas
epic-
is
for
the
overlay
default
operation
on
array
items
is
append.
B
So
some
context
here
and
some
general
discussion
is-
is
also
linked
here.
But
we've
we've
encountered
some,
I
guess
like
feedback
or
maybe
some
some
confusion
about
ways
that
we
could
just
maybe
make
the
overlay
feature
appli.
B
I
guess
play
more
nicely
so
to
make
the
the
ux
a
little
easier
to
understand
and
it
it
might
make
make
it
a
bit
more
obvious.
Once
you
start
taking
a
look
at
these
examples,
so
let's
see
if
we
look
at
example,
number
one
where
the
non-empty
left
so
that's
kind
of
like
the
the
base
and
the
no
explicit
operations
in
the
right.
So
the
right
is
the
the
overlay.
B
B
Cool,
so
that's
that's
the
idea.
We
kind
of
walk
through
a
couple
more
examples
here.
What
happens
when
the
array
in
the
left
is
empty?
It
depends
what
happens
when
the
array
and
the
right
is
empty.
Nothing
is.
B
Added
and
then
we
also
have
another
condition
where
there's
a
an
implied,
replace
so
taking
a
look
at
this
example.
So
left
has
these
two
this
this
list
has
these
two
items
and
then
the
overlay
we
can
see
that
there
is
a
is
an
additional
overlay
match
here,
where
it's
saying
by
index
one.
B
B
C
Yeah,
so
just
looking
at
this,
when
you
add
the,
or
rather
when
you
load
the
base,
yama
layer
is
the
is
it
always
appending?
Is
that
the
default
yeah
so.
B
That's
kind
of
the
gist
of
this
story
is
that
we
want
append
to
be
the
default
operation
for
when
you
overlay,
on
top
of
the
base
gotcha
yeah.
I
missed
that
part.
C
D
B
Cool
and
then
we
just
hear
him,
can
we
go
over
why
this
isn't
a
breaking
change
again?
B
B
I'm
not
sure
where
it's
called
out,
but
and
someone
else
can
please
correct
me
if
I'm
wrong,
but
but
as
of
now.
This
is
something
that
you
need
to
explicitly
call
so
there's
an
additional
overlay
annotation
that
would
exist
in
these
lines.
E
The
breaking
change
would
be
you're
going
from
an
air
state
which
you
ought
not
rely
on
to
a
state
that
works.
So
not
not.
The
the
one
case
we
thought
of
that
was
I'll.
Call
it
viable
would
be
that
for
some
reason
in
your
ci
you're
checking
to
make
sure
that
your
use
of
your
user's
use
of
your
use
of
ytt
work
that
one
out
that
you're
trying
to
make
sure
that
you
give
back
good
error
messages
when
they
might
have
provided
invalid
input.
E
So
that
might
break
for
you,
but
but
it
is
making
something
that
was
wasn't.
Their
case
is
now
a
working
case.
E
F
E
Don't
have
one
yet
there's
also
a
long-standing
operation
called
merge
that
exists,
and
we
haven't
deprecated
that
so
those
two
will
probably
follow
the
same
fate.
E
B
B
All
right
so
after
that,
following
the
oh,
why
don't
I
hit
the
filter?
So
now
you
only
see
schema
stuff.
It's
a
little
nicer
following
that
issue.
Then
we
have
just
an
issue
to
track
for
for
documentation.
B
So
I
know
this
is
another
story
that
the
team
has
reviewed
before,
but
I
think
high
level
kind
of
just
of
this
is
you
know,
we're
we're
introducing
this
experimental
schema
feature.
We
want
to
tell
users
how
to
take
advantage
of
it
and
to
do
so,
we
want
to
provide
some
reference
material
as
well
as
a
guide
to
show
you
know
how
to
do
this
and
then
kind
of
like
walk
you
through
the
steps,
as
well
as
like
the
general
introduction
of
of
what
schemas
are
and
the
values
it
provides.
E
So
what's
the
minimum
amount
of
information
I
need
to
be
successful
in
evaluating
what's
been
implemented,
so
far
is
kind
of
one
tension
and
then
the
other
is
providing
enough
of
a
foundation
of
explaining
not
just
what
you
can
do,
but
why
the
features
there.
Hopefully
that's
clear
in
the
story:
that's
the
intent.
B
Cool
and
then
the
final
thing
we
have
in
our
backlog
right
now
is
the
conduct
some
usability
testing
for
schemas.
So
I
guess,
if
someone
is
watching
this,
you
know
pl.
If
you
want
to
be
a
part
of
some
of
the
usability
testing,
please
please
let
us
know,
slack
is
always
a
great
avenue,
but
we
want
to
seek
to
verify
that.
You
know
the
functionality
that
we're
providing
for
schemas
and
the
problems
we
set
out
to
solve
are
are
actually
solved.
B
B
B
Cool
so
then,
if
we
expand
so
jumping
epics
now,
so
this
is
on
to
image
package
non-distributable
layers.
So,
as
we
mentioned,
there's
there
already
some
work
in
flight
there.
B
We
do
have
a
another
piece
of
work
after
that
which
is
providing
an
update
to
ggcr.
So
google's
go
container
registry
in
order
to
to
provide
this
ability.
So
we
we
kind
of
created
a
workaround
for
our
use
case
right
now,
but
we
would
like
to
to
try
and
contribute
this
this
upstream,
so
that
the
the
library
can
can
do
it
as
well.
F
B
Yeah,
I
don't
know
if
we've
explicitly
discussed
it,
but
I
mean
I'd,
certainly
be
okay,
cutting
a
release
immediately,
I'm
not
sure
like
what
ggcr's
you
know,
release
cadence
look
like.
So
if
we
were
trying
to
only
pull
finals
or
something
like
that
final
releases,
it
could
be
some
time
but
yeah.
I
don't
know
open
open
to
other
folks
thoughts.
F
B
B
All
right-
and
so
you
can
see
that
the
this
particular
epic
is-
is
a
smaller
epic
in
the
sense
of
like
the
number
of
stories
it
has,
so
that
would
wrap
that
work
up
then.
Looking
at
the
next
thing,
we
we
already
kind
of
touched
on
was,
you
know,
explore
if
image
package
copy
is
inefficient.
B
So
I
know
this
is
another
story
we
had
already
discussed
internally,
but
you
know
just
just
to
give
folks
some
some
idea
of
what
we're
thinking
here.
So
it
was
observed
that
some
small
images,
such
as
like
a
simple
hello
world,
would
at
times
take
20
seconds
to
be
copied
and
we
want
to
again
determine
if
this
is
still
a
problem
and
if
so,
how
are
ways
that
we
can
improve
it?
B
C
What
what
oci
registries
have
you
used
to
test
this
one.
B
I
I'd
probably
kick
it
over
to
dinosaurs
a
while.
I
guess
one
of
y'all.
F
Well,
just
the
docker
registry,
so
we've
definitely
tested
against
docker
hub
and
when
we
run
it
in
the
ci,
we
spin
up
a
container.
That's
running
the
registry
image
v2.
I
believe
tag
and
I
have
run
the
test
suite
against
harbor
as
well
and
that
all
went
and
worked
there's
a
three
different.
I
guess
registries
we've
also
done
gcr
artifactory
and.
D
B
B
This
is
where
I
want
to
be
so
next
in
our
backlog
would
be
image,
package,
support,
copy
and
bundles
reference
by
other
bundles
and
images
lock,
I'm
curious
joao.
If
the
proposal
is
something
worth
going
over
right
now,
if
that's
better
done,
asynchronously.
G
Up
to
y'all,
we
can
always
link
it.
We
can
go
through
it
like
I,
I
still
haven't
published
like
polish
it
in
like
a
broader
place,
but
it
is
more
or
less
finalized.
It's
just.
I
just
realized
a
couple
of
minutes
ago
that
we're
missing
like
a
little
bit,
but
it's
just
a
little
bit
that
is
going
to
be
optional
on
the
proposal,
but
we
can
definitely
go
through
the
proposal.
If
you
want
to.
G
So
like
the
prettier
version,
it
will
it
exists
in
hackmd
and
that's
exactly
the
one
it
has
like
all
the
mark
markdown
rendered,
but
because
it
is
hard
for
us
to
have
like
some
sort
of
a
conversation
and
be
notified
on
hackmd
there
is.
There
is
a
pr
on
our
on
one
of
our
repos
that
contains
exactly
this
information
that
we
can
go
back
and
forth
and
the
pr
is
inside
our
k14s
docs
proposals,
repo.
B
G
And
the
first
one
yeah
there
we
go
so
like
that's
exactly
the
same
thing
as
a
hackmd.
If
you
prefer
to
see
it
with
the
markdown,
that's
there
then
go
for
it.
If
you
prefer
to
see
the
markdown
pre-rendered
for
you,
then
you
have
the
hack
and
the,
as
you
can
see.
Dimitri
already
left
some
comments
there,
but
yeah.
B
G
So
let's
imagine
that
you
have,
for
example,
I
don't
know
you
have
one
application
like
one
micro
service,
that
is
a
application,
a
that
the
team
bundled
together.
It
has
configuration
and
so
on,
and
you
have
a
micro
service
b
that
that
the
other
team
bundled
and
had
configuration
to
it.
Who
has
the
packager
that
wants
to
package
these
two
micro
services
together?
You
didn't
had
like
a
good
way
to
do
it,
because
you
cannot
point
this
new
third
package
directly
to
these
two
bundles
that
the
teams
created.
G
So
the
the
options
that
you,
as
the
person
that
is
trying
to
package
all
these
software
together,
would
be
to
extract
the
bundles
that
each
team
created
and
create
your
own
bundle
with
all
their
configuration
or
eventually
just
create
some
sort
of
like
a
a
script
for
the
end
user.
To
install
these
multiple
bundles,
so
you'd
have
to
say,
like
oh
get,
this
bundle
first
and
get
this
other
bundle.
Eventually,
I
give
you
like
a
third
bundle
that
has
like
some
installation
script,
to
help
you,
but
it
would
be
a
lot.
G
So
what
we're
proposing
here
is
a
way
for
you
as
a
packager
to
say.
Oh,
this
huge
bundle
of
software
contains
these
two
applications
that
are
bundled
separately
and
that
each
team,
bundles
separately
and
this
bigger
bundle
will
become
like
the
place
where
you
can
just
give
it
to
the
final
user
and
say
like
this.
Is
your
bundle
and
the
only
thing
you
need
to
do
is
you
need
to
pull
it
and
then
you'll
have
to
somehow
install
it
with
any
script
that
I
give
you
or
any
kind
of
instructions.
G
So
this
is
more
or
less
the
idea
behind
the
the
proposal
that
we
have
here
and
then,
if
you
scroll
a
little
bit
down,
there
are
like
changes
that
need
to
happen
for
each
for
each
of
our
operations
that
we
do
right.
So,
for
example
like
when
you
do,
when
you
do,
the
push
of
a
bundle
you'll
have
to
do
we'll
have
to
make
sure,
because
today,
when
you
try
to
push
a
bundle
that
contains
other
bundles,
you
get
an
error
message.
G
So
the
idea
here
is
that
we'll
stop
having
that
check
to
start
with
and
we
would
push
the
bundle
as
it
is,
even
if
it
has
bundles
on
it.
So
this
is
like
the
smallest
change
footprint
that
we're
proposing
here
there's
a
an
extra
proposal
on
this
push
command.
G
So
this
is
more
or
less
the
change
that
we're
proposing
in
terms
of
like
the
the
bundle.
So
after
that,
there's
the
the
copy
in
itself,
and
we
have
copies
from
repo
to
tar,
from
tar
to
repo
and
from
repo
to
repo
and
the
the
the
major
change
that
we
have
here
is
that
now
in
the
image
package,
will
have
to
be
aware
that
a
particular
image
that
is
trying
to
copy
it
is
a
bundle.
G
So
it
will
have
to
retrieve
all
the
all
the
images
that
are
part
of
that
bundle
and
because
we're
not
saying
that
this
is
going
to
be
a
one
layer
bundle
we,
you
might
have
a
bundle
of
a
bundle
of
a
bundle
of
a
bundle
not
ideal,
but
we're
not
going
to
cap
that
for
now,
unless
we
see
that
there's
like
a
big
problem
with
that,
so
this
is
yeah.
G
The
only
thing
that
you
need
to
make
sure
is
that
when
you
get
the
tar,
when
you
create
a
copy
to
a
tar
that
we
dedupe
the
layer,
so
we
don't
have
like
duplicated
layers
being
written
to
a
tar.
So
it
doesn't
use
that
much
disc
and
I
think
that's
all
for
the
copy.
G
So,
let's
take
a
little
peek
at
the
pool
and
the
pull
is
the
the
the
complicated
one,
because
when
you
pull
it,
you
want
to
pull
the
configuration
for
all
the
bundles,
so
the
the
proposal,
what
it
what
it
proposes
here,
is
that
we'll
create
a
folder
where
we
will
stack
all
of
the
of
the
the
configurations
from
all
the
bundles,
and
that's
where,
like
we
were
talking
on
the
push
that
we
wanted
to
ignore
a
folder.
G
G
G
This
bigger
package-
this
configuration
here
would
have
to
if,
if
it
wants
to
get
that
information,
we'd
have
to
read
the
this
file,
the
images.tml
file
to
translate
the
name
of
this
folder
with
the
image
that
they
care
about.
So
there's
like
some
some
information
here,
we
talked
a
little
bit
about
the
cyclic
nesting
because,
like
one
image
can
depend
on
another
image
and
that
image
can
depend
on
the
third
and
the
first
one
depend
on
the
on
the
third
as
well
as
it
is
represented
in
like
this
diagram.
G
Here
we
have
some
explanation
about
it
and
in
the
end,
this
is
more
or
less
a
proposal
that
we
have.
So
if
you
have
a
little
bit
of
time,
just
take
a
look
at
it
and
see
if
there's
anything
that
pops
out.
That
last
part
is
a
part
that,
like
that
part,
that
says
like
list
images
in
bundle,
it's
a
part
that
it's
not
100,
flushed
out
that
I
was
writing
down
right
now,
because
that
was
something
that
was
going
to
be
added,
but
I
think
that's
it.
F
Well,
this
might
be
just
a
quick
one,
but
I
was
reading
up
on
oci
artifact,
manifest
spec,
which
maybe
I've
just
read
enough,
just
to
be
dangerous
enough
to
ask
this
question
but,
like
essentially,
it's
like
expect
to
basically
find
map
out
dependencies
between
an
artifact
manifest,
which
sounds
very
similar
to
a
bundle
to
a
bunch
of
other
images
or
other
artifact
manifest
which
might
depend
on
other
images,
and
this
is
a
spec
that
is
out
there.
I
don't
know
how
mature
it
is
or
whether
it's
doing
development,
but
is
there
any
overlap
between?
F
G
I
think
it's
still
in
pr
mode,
and
it
is
being
it
is
an
effort,
that's
being
somewhat
led
by
the
notary
team,
and
it
is
based
on
a
lot
on
the
the
fact
that
we
want
to
sign
images.
And
we
do
not
want
to
change
the
sha
of
the.
F
Images,
oh,
wait,
wait!
Sorry,
you
said
distribution.
I
actually-
and
I
said
yes
to
that,
but
I
should
have
said
no.
It's
in
the
artifacts
repo
and
the
the
spec
is
artifact
manifest.
G
E
Yeah,
that's
a
good
question
dennis
because
on
on
the
face
of
it,
it
does
seem
like
there's
some
overlap
there.
So
yeah.
Definitely
something
for
us
to
dig
into
to
make
sure
that
if
there's
something
that's
emerging
as
a
way
of
expressing
relationships
like
that
that
they
that,
if
there's
a
separate
mechanism,
it's
for
cause
and
not
just
yet
another.
G
G
G
E
For
clarifying
okay
and
just
for
the
recording
and
then
ot
actually
did
both
identify
two
different
specs
there's
one
about
like
how
should
a
registry
that
supports
like
distribution
of
or
how
should
the
distribution
of
images
look
versus
this,
which
is
like
what
is
what
is
an
artifact?
How
is
that
described
so,
just
just
for
the
pedantics
in
the
audience.
B
Great
so
yeah,
please,
please
take
a
a
moment
to
review
the
proposal.
Once
we
get
some
feedback,
we'll
likely
start
writing
some
stories
and
executing
on
the
work.
So
we
have
a
little
bit
more
than
10
minutes
left.
So
I
want
to
make
sure
we
get
back
to
a
discussion
topic
that
someone
had
asked
a
question.
B
H
H
Color
to
this,
as
I
wrote,
the
question.
H
Yeah,
so
I'm
interested
in
the
idea
of
how
objects
and
kubernetes
gets
grouped
together
as
an
application
and
I've
used
cap,
it's
pretty
sweet.
I
like
it
and
one
of
the
things
that
I
guess
that
jumps
out
at
me
in
the
beginning
was
that
it
created
these
labels
and
it's
got
these
numbers.
I
think
it
might
represent
time
or
a
hash,
and
I
wanted
to
see
how
does
or
I
want
to
better
understand
how
cap
knows
that
these
objects
relate
to
each
other.
H
And
if
I
were
to
change
something
about
the
labels
or
let's
say
I
went
in
and
patched
something
what
would
happen
and
also
the
also
the
idea
that
every
time
I
do
a
new
deploy,
it
creates
a
new
config
map
of
what
changed,
and
I
was
wondering
if
there's
if
I
could
get
better
context
behind,
why
that
was
done.
That
way
versus
something
like
say,
patching
the
annotations
to
keep
track
of
these.
E
E
So,
let's
see
so
there's
there's
a
question
about
what
was
the
origin
or
the
thinking
around
the
the
namespaces
for
the
annotations
that
we
selected
and
then
the
other.
The
first
part
of
your
question
seemed
really
related
to
that.
What
was
that
again?
Sam.
H
Yeah,
the
so
the
first.
I
wanted
to
know
why
these?
What
does
the
k,
apps
or
the
caps
labels
do
like
is
whether
it's
like
a?
I
think
I
think
it's
a
time
stamp,
a
hash,
I'm
not
sure
what
it
is
and
what.
E
It's
used
for
yeah
yeah
cool.
Let's
do
that
and
then
then
then
grab
the
next
ones
next,
so
the
the
short
version
of
it
is
that
this
this
label
is
meant
to
be
a
a
guide
and
in
fact
I
would
treat
it
as
a
black
box
string.
It's
just
here's
a
thing
that
identifies
that
app
and
and
if
and
if
there
happens
to
be
any
relationship,
you
know
if,
if
any
of
the
characters
resemble
anybody,
you
know
in
real
life.
That's
a
coincidence.
E
So
they're
meant
to
be.
It's
meant
to
be
identifying.
So
to
answer
the
letter
of
your
question
that
you
wrote
in
which
was
like
hey,
there's
all
these
common
labels.
E
Why
not
use
one
of
those
like
say
like
the
instance
one,
that's
in
part,
because
those
are
meant
those
the
way
we
can
understand
as
they
are
descriptive
rather
than
identifying
like,
for
example,
the
closest
one
that
looks
like
a
unique
id
is
the
is
the
instance
label,
but
that
actually
is
a
concatenation
of
a
meaningful
string
like
the
name
of
the
app
and
your
application
operations
shouldn't
break
because
the
name
of
the
app
changes.
E
So
it's
a
separate
namespace
that
is
more
identifying
and
then
also
you
can
avoid
collisions
with
other
tooling
that
might
rely
on
some
implied
schema
inside
any
of
those
labels.
If
that
helps.
H
Yeah,
the
second
part
was
about
how
the
caps
deployments
work
every
time
anyone
gets
rolled
out.
It
creates
a
new
config
map
that
tracks
the
changes
and
histories
presuming
of
each
new
deployment,
and
so
I
guess,
given
the
context
of
the
first
question,
so
I
don't
actually
so,
like
those
config
maps,
have
no
relationship
to
the
argus,
like
they're,
not
considered
part
of
that
deployment
that
I've
applied
to
the
cluster
right
like
so,
for
example,
if
I
deleted
that
config
map
it
would
not
break
the
application,
I
would
just
lose
history.
E
Yeah
we
rely
on
the
the
labels
themselves,
so
the
the
I'm
trying
to
think
about
where
we
put
the
app
name
to
label
mapping
is
that
in
the
latest
config
map.
Is
anybody
on
the
call
remember.
E
E
H
E
H
Yeah,
okay,
cool
yeah
I'll
follow
up
on
this
offline.
Probably
most
of
the
meeting
topics
are
on
a
different
discussion.
E
A
B
Cool
anyone
else
have
anything
else
they
wanted
to
chat
about.
For
last
few
minutes.
B
All
right:
well,
maybe
that
was
enough,
uncomfortable
silence
to
move
on
so
yeah,
please,
you
know
if
you
have
any
feedback
for
this
meeting.
Please
please
let
us
know
this
is
our
first
iteration
of
of
this
new
format.
B
If
there's
more
information
that
you're
looking
for
or
if
this
wasn't
quite
the
information
you
wanted,
please
please
let
us
know
what
you're
looking
for.
I
don't
know
nancy
anything
else.
You
want
to
add.
A
You
know,
please
join
the
kubernetes
slack
workspace
in
the
carville
project
channel.
You
can
provide
feedback
there
as
well.
As
you
know,
within
github,
and
you
know
we
were
really
looking
to
you
know:
have
these
meetings
foster
and
community
engagement
with
the
team
so
any
and
all
feedback
is
welcome,
but
with
that
you
know,
thank
you.
Everyone
for
attending
this
first
monday's
meeting
for
carville
community
meeting.