►
From YouTube: Working Group: 2021-09-16
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
All
right,
so
any
new
faces
today.
A
My
first
time
in
this
group
I've
seen
several
folks
around
other
meetings
but
mikey
bolt.
I
just
joined
the
cloud
native
building
packs
contrib
team
at
vmware.
So
I'm
excited
to
be
here
and
dig
in
it's
my
first
week
so
still
kind
of
getting
the
wheels
on
but
looking
forward
to
what's
to
come.
B
D
Hi,
I'm
I'm
aiden.
I
work
at
sambhav
in
london.
B
D
B
I
can
give
a
quick
update,
I
know
pack
0
21
shipped
yesterday.
I
think
I
saw
that
on
the
life
cycle
side
we
shipped
our
release
candidate
last
week
and
now
we're
just
waiting
to
get
all
of
the
features
documented
before
we
publish
the
final
release.
E
F
Yeah
we
just
released
pac
earlier
this
week
and
so
far
everything
seems
to
be
going
good.
We
do
have.
Basically
the
pipeline
is
broken
for
delivering.
What
is
it
called
arch
linux,
but
nobody's
really
complained
yet,
but
we
will
be
taking
a
look
at
that.
A
Awesome
joined
it
just
the
right
time,
any
other
sub
team
updates
distribution,
learning
anything
like
that.
A
F
C
I
think
I
push
the
updates
here,
so
I
updated
the
proposal
to
move
away
from
the
whole
volume
directive
back
to
something
that
a
bill
packing
said
so
in
your
buildback,
normal
okay.
First
of
all,
the
motivation.
In
summary,
the
idea
behind
this
rfc
is
to
allow
buildbacks
to
write
to
paths
apart
from
slash
players
and
app
directory
and
for
those
parts
to
be
exported
out
into
the
final
image.
C
This
is
useful
for
a
bunch
of
cases
which
I've
highlighted
here,
and
it
also
allows
you
to
like
for
buildbacks
to
write
all
these
layers
and
still
preserve
the
rebase
capabilities
while
being
able
to
write
to
other
folder
parts.
C
The
way
I've
currently
structured
it
is
that
a
well
packed
would
declare
that
it
needs
to
write
to
a
certain
fixed
number
of
directories
in
its
spellback
normal
and
when
the
builder
is
being
created
by
a
platform,
it
would
validate
that
the
build
and
run
image
do
not
have
any
conflicts
on
these
bots
and
also
add
and
add
a
label
on
the
builder
to
for
the
build
for
the
build
process
to
know
which
additional
volumes
to
be
mounted
during
the
time.
C
In
terms
of
how
this
would
work
during
build
time,
the
platform
would
look
at
this
label
and
if
it
finds
any
additional
parts,
it
will
try
to
mount
volumes
there
and
the
lifecycle
would
be
responsible
for
taking
the
things
there
and
putting
it
on
the
final
run.
Image
build
packs
could
also
take
advantage
of
slices
the
same
way
as
they
currently
do
with
the
app
directory
and
specify
like
fine
grained
parts
in
different
layers
if
they
want
to,
and
additionally
the
analysis,
space
would
be
responsible
for
validating
that.
C
C
Drawbacks
are
register
complexity
and
like
potential
implementation
complexity
for
platforms
like
tecton.
F
C
I
think
we
could,
if
we
do
it
during
the
builder
creation
time
and
add
appropriate
flags.
The
life
cycle
could
simply
look
for
those
flags
and
pass
along
like
and
the
analysis.
Space
validation
could
be
fairly
simple,
but
it
would
probably
increase
the
amount
of
time
it
takes
to
create
the
builder
which
ideally
shouldn't
impact
build
times,
but
just
people,
the
creation
time.
C
Yeah,
I
think,
for
those
use
cases.
If
we
skip
validation,
we
could
potentially
improve
on
the
performance,
but
even
then
I
I
can't
say
the
like
how
much
time
it
would
take
for
us
to
verify
that
certain
parts
exist
or
do
not
exist,
for
once
we
are
inside
the
builder
container.
Verifying
that
a
particular
path
is
empty
is
fairly
trivial
for
the
run
image.
F
Yeah
cause,
I'm
thinking
like
we'd,
have
to
look
at
all
the
layers
on
the
image
I'm
trying
to
think
of
whether
or
not
they'd
be
compressed
or
not.
So
we
might
have
to
decompress
them
and
then
essentially,
look
at
the
listing
of
the
file
system
right.
E
Theoretically,
the
same
like
overwriting,
the
path
on
the
run
image
problem
exists
with
the
way
we
do
after
right
now,
but
it
seems
less
important
that
it
exists
now,
because
we
have
such
a
our
default
path.
For
after
is
something
that
is
highly
unlikely
to
be
set
or
relevant
like
we
could
just
blow
away.
What's
on
the
run
image,
if
we
wanted
to
be
more.
A
C
E
I
know
a
couple
times:
we've
talked
about
like
actually
tarring
up
layers
in
the
build
phase.
I
wonder
if
that
becomes
more
tempting
with
this
proposal
as
well,
because
I
think
it
is
a
bit
of
a
problem
for
platforms
like
techton
to
be
mounting
volumes
to
arbitrary
paths.
I
don't
want
to
put
too
much
work
on
platforms
to
be
able
to
execute
a
build,
but
you
know
if
we
were
layerizing
in
the
build
phase,
we
wouldn't
actually
need
it
to
be
a
volume.
E
A
E
C
For
takedown,
the
other
option
was
for
us
just
simulink,
like
the
life
cycle
during
one
of
the
initial
phases
where
it
does
have.
Some
privileged
permissions
could
create
the
appropriate
modifications
to
the
builder
image
so
that
in
the
builder
image,
they
point
to
the
same
volume
and
then
build
backs
right
to
that
thing
where
it's
preserved,
because
it's
on
that
single
volume
that
was
mounted.
F
Sorry,
if
I
take
a
step
backwards,
but
could
you
remind
me
why
we're
using
volumes
as
opposed
to
just
standard
file
system?
I
I
remember
something
about
abi.
Is
that
true.
D
Do
we
think
all
the
volume
shuffling
is
better
than
taking
like
a
snapshot
of
these
directories
like?
Could
we
use
something
like
iconic
kind
of
code
like
snapshotter
to
you
know,
take
a
snapshot
of
the
ops
directory
before
any
of
the
build
phases
occur
and
then
afterwards
to
create
a
layer
that
way
and
then
apply
it
as
we
export.
E
I
don't
even
think
we
need
to
do
a
snapshot
thing.
We
can
do
exactly
what
our
exporter
does
now,
when
it's
like
layerizing
and
slicing
the
after.
We
just
do
it
at
the
end
of
the
build
phase
after
the
build
packs
run
and
then
put
that
on
the
volume
we
already
have.
So
you
don't
have
to
deal
with
sort
of
arbitrary
volumes
at
arbitrary
paths.
D
D
D
Yeah
I
like
this
without
the
volume
specific
stuff
like
if
we,
if
we
could
turn
it
into
exporting
with
our
exporter,
like
that,
that
feels
it
feels
better
to
me
than
like
relying
on
volumes
to
be
a
part
of
this.
F
How
do
sorry,
how
do
we
get
around
needing
volumes
for
the
you
know,
kind
of
sharing
content
across
the
faces.
E
E
And
then,
because
this
is
very,
this
is
different
from
how
we
do
other
layers
like
we
don't
need
to
restore
anything
during
the
restore
phase.
Here
we
don't
need
to
like
copy
and
app
contents
in
advance
of
detect.
So
the
only
place
where
we
need
to
preserve
changes
in
our
current
scheme
is
between
build
and
export,
but
we
don't
really
have
to
do
the
tarring
during
export.
E
Yeah,
which
might
be
a
good
thing
to
do,
anyways
like
we've,
talked
about
other
cases
where
that
would
be
helpful.
It's
like!
Oh,
do
we
want
to
try
to
parallelize
it
with
the
build
stuff.
I
think
once
it's
in
the
builder
phase,
then
we're
free
to
like
make
all
those
changes
later
without
it
being
a
big
deal,
because
it's
not
changing
the
interface
for
folks,
so
we
could
start
just
by
you
know
making
it
the
last
thing
that
happens
during
film,
so
basically
everything's
happening
in
the
same
order.
It's
just
this.
E
Can
this
phase
boundary
is
different.
If
we
did
that,
then
I
feel
like
we'd,
be
in
a
good
place
to
unblock
some
other
stuff.
D
C
C
I
mean
that
makes
sense
to
me.
It
also
might
open
up
the
the
spike
we
have
on
the
other
rfc
to
test
out
what
happens
if
we
do
that
during
the
like,
if
we
paralyze
the
expo
during
the
build
phase,
so
if
it's
just
moving,
one
function
call
from
the
export
simplifying
things
of
it,
but
if
it's
moving
one
thing
from
the
export
phase
to
the
build
phase
and
then
the
rest
of
the
process
remains
the
same.
That
works.
F
Does
I
haven't
thought
it
all
the
way
through,
but
does
that
then
change
the
performance
concerns
of
what
the
platform
will
have
to
do
as
far
as
volumes
are
concerned
of
having
to
check
the
paths.
C
It
would
still
have
to
if
you
want
to
ensure
that
there's
nothing
there.
It's
it's
like
the
same
guarantee
we
take
with
the
app
directory
where
we
assume
there's
nothing
there
on
the
run
image
on
that
path,
and
you
just
overlay
it
on
top.
If
you're
fine
with
that
assumption,
then
this
this
there
shouldn't
be
any
performance
it.
If
you
want
to
validate
that
these
parts
are
in
fact
empty.
Then
yes,
we'll
have
to
verify
that
somewhere.
D
If
we
just
overlay
these
files
on
top
of
the
run
image,
are
there
any
security
implications
for
doing
something
like
that?
Like?
Are
there
any
paths
that
operators
would
need
to
deny.
E
I
think
there's
almost
certainly
malicious
things
that
bill
pack
could
do
in
that
case
right,
but
also
there's
so
many
things,
malicious
things
that
bill
pack
could
do.
I
feel,
like
you
have
to
trust
on
some
level
that
your
bill
pack
isn't
malicious,
because
you
can
just
put
a
malicious
map
in
your
app
if
it
really
wants
to
do
that
right.
F
I
do
wonder
if
there
needs
to
be
a
way
kind
of
like
how
right
now
the
operator
is
able
to
say,
like
you
can't
use
this
build
pack
right
if
there's
a
way
that
they
can
inspect
the
paths
and
say,
okay,
any
build
pack
that
tries
to
write
to
this
directory,
basically
can't
be
accepted.
F
F
Yeah,
but
I
think
this
one's
different
right,
the
approach
is,
you
have
a
platform,
you
know
at
some
enterprise
and
basically
you
know
you
have
these
like
run
images,
and
maybe
you
have
some
security.
You
know
concepts
that
say
nothing
should
be
able
to
write
to
you,
know
user
bin
or
something
like
that
right.
F
Then
then
they
could
kind
of
have
those
checks
in
place.
As
long
as
the
build
packs
themselves
say,
these
are
the
paths
that
I'm
going
to
try
to
extract
right.
F
D
C
A
You
know
this
is
like
one
of
three
different
proposals
to
kind
of
solve
for
this
problem,
which
I
think
is
a
good
problem
to
solve,
for
we
you
know
it's,
you
know
we
do
need
to
do
something.
I
think
the.
How
do
we
feel
about
this?
You
know.
A
A
A
Proposal,
I
think
it
does
create
some
coupling
with
the
stack
and
that
now
a
build
pack
has
to
know
about
paths
in
the
stack
that
are
pretty
specific
and
relies
on
those
pads
being
empty
right,
which
is,
I
can
see
a
situation
where,
like
a
build
pack
says,
oh
I'm
going
to
write
to
opt
because
opt
happens
to
be
empty
on
the
stack
and
then
somebody
extends
the
stack
with
more
things
than
opt
right.
You
know
for
their
because
they
needed
an
additional
piece
of
software.
F
Well,
I
think
opt
would
be
too
too
big
of
a
scope
to
try
to
take
in
right.
I
think
that'd
be
like
a
failure
of
the
build
pack
itself
in
some
of
the
use
cases
defined
there.
I
think
it's
very
specific
directories
with
an
opt
and
that's
the
way.
I
view
it
because
I
think,
based
on
the
use
cases,
it's
it's
things
that
make
a
lot
more
sense
that
are
in
predefined
directories
or
expected
directories,
but
I
get
what
you're
saying
I
just
wanted
to
help.
You
know
define
that.
A
A
A
A
All
right,
so
we
are
at
half
time
and
the
other
proposal,
or
other
thing
to
talk
about
today
was
the
name
for
whatever
we
call
stack,
packs
or
hooks
and
the
support
docker
files
rfc.
I
think
we've
resolved
unless
happy
to
talk
about
anything
else
in
there
that
is
unresolved.
I
think
we've
resolved
everything
that's
worth
talking
about
during
a
working
group.
Sorry
natalie
go
ahead.
B
Oh
yes,
sorry
I
was
I
was
thinking
about
this
this
morning.
The
the
rfc
mentions
that
the
I
think
it's
both
base
images,
but
that
they
might
have
statically
labeled
provides
that
could
be
contributed
to
the
build
plan
and
I
started
to
think
about
like
I
know
in
stack
packs.
We
had
this
concept
of.
B
I
can
provide
any
mix
in
right.
I
know
mixins
are
going
away,
but
the
idea
that,
like
a
generic
docker
file,
that's
just
like
I
can
just
install
whatever
package
is,
you
know
provided
to
me
as
an
argument
like
is
that
gonna
write
it's
not
right
in
the
build
plan
like
every
package
out
there
right,
you
know,
and
so
how
do
we
reconcile
that
with
like
build
packs,
potentially
making
requests
via
the
build
plan
for
arbitrary
packages.
A
Not
sure
I
totally
understood
so,
there's
there's
a
provision
in
there
for
being
able
to
label
a
base.
Image
with
you
know
here
are
some
provides
that
should
always
get
matched
right
to
requires
the
and
sorry.
What
are
you.
B
Oh
yeah,
I
think
I
had
two
questions
rolled
into
one.
I
had
like
an
observation
that
prompted
another
question.
I'm
really
kind
of
getting
at
like
the
the
hooks
communicating
with
build
packs
via
the
build
plan
and
the
idea
that
build
packs
could
request
some
arbitrary
package
right
and
you
know
there
could
be
a
hook.
That's
like
I
can
install
any
package.
A
So
there's
there's
no
concept
of
packages
anymore
within
the
build
plan
right,
there's,
there's
like
we
don't
have
a
mix-ins
list
or
or
a
packages
list,
it's
it's
just
a
communication
contract
and
so
the
if
a
hook
like
are
you
asking
like?
How
would
you
implement
an
apt
build
pack.
A
I
thought
we
had
an
example.
Maybe
there's
not
an
example
in
there
anymore.
A
The
requires
can
specify
metadata
that
go
to
the
provides,
and
so
things
require
requiring
something
from
an
app
to
build.
Pack
could
pick
a
known,
build
plan
entry
name
and
put
require
entries
for
the
packages
they
want
to
install
that
would
get
received
by
the
hook
build
pack.
I
think
that
was
the
you
can
like
require.
B
That's
that's
helpful,
that's
helpful
and
then
sorry,
I
had
one
more
question.
I
think.
Maybe
this
makes
sense
if
both
base
images
build
and
run
are
able
to
statically
provide
something
when
that
goes
into
the
build
plan.
Is
there
any
concept
of
like
build?
You
know
again,
I
know
mixins
are
going
away,
but
like
build
colon,
you
know
this
provide
is
on
the
build
image.
This
provide
is
on
the
run
image
like.
Can
we
differentiate
between
the
two.
A
D
C
D
D
Yeah
it'd
be
up
to
the
hook
right
the
hook
contract
so
instead
of
it
being
a
contract
that
the
lifecycle
implements.
It's
really
just
the
metadata
contract
between
the
hook
and
the
build
packs
that
are
requesting
that
and
obviously,
as
a
community.
Hopefully
we
would
rally
around
like
apt
or
something
being
the
require.
Then
maybe
we
have
a
extension
spec
for
how
to
you
know
if
you
do
curl
minutes.
C
A
A
Yeah,
I
just
I
think
we
at
some
point.
There
were
details
there
that
were
not
written
down.
I
actually
get
them
into
the
things
we
can
talk
about
something
that's
more
concrete,
because
I
forget,
if
it
was
that
it
should
only
be
on
one
image
or
if
there
was
a
you
know,
plan
to
resolve
being
on
both
images.
A
So
I
think
the
kind
of
topic
for
you
know
what
we
put
on
the
agenda
today
was
that
we
started
a
little
bit
of
an
impasse
over
what
we
should
call
hooks.
I
think
everybody.
A
Nobody
is
strongly
attached
to
a
particular
name,
but
nobody
is
fully
on
board
with
the
different
names
people
have
come
up
with
so
far,
and
so
I
wanted
to
kind
of
use
this
time
to
do
a
little
bit
of
game
generation,
maybe
and
see
if
we
can
come
up
with
any
any
names
that
have
you
know
more
broad
consensus,
and
if
we
can't
you
know,
maybe
disqualify
a
couple
of
them
or
or
not,
and
just
do
a
poll
and
come
up
with
the
most
popular
name.
A
So
we
have
some
options
listed
there.
Already
we
come
up
with
hooks
x
from
froms.
I
don't
know
how
that
looks
like
and
or
stage
or
stages.
A
Does
anybody
want
to
talk
about
these
existing
things?
Is
there
a
plural
version
of
from
like
how
do
you
talk
about
from.
E
A
A
Maybe,
if
folks,
who
came
up
with
those
ideas
or
have
opinions
want
to
add
different
or
like
examples
of
how
that
you
use
the
name
in
there,
that'd
be
good,
but
also
does
anybody
have
other
suggestions
for
for
names?
Besides
these
four
things.
D
Coming
in
a
little
green,
but
it
has
anybody
proposed
provider
or
providers.
A
I
think
it
it's
similar
to
provide-
or
we
have
a
build
plan
concept
called-
provides.
That's
a
little
similar
to
that.
But
the
you
know
I
don't
think
overlapped.
There
would
be
terrible.
A
The
the
functionality
again
for
folks
haven't
been
following
super
closely
to
this
is
the
ability
to
run
docker
files
on
your
build
before
the
you
know,
normal
build
packs,
run
and
install
stuff
into
the
contractually
defined
layers,
and
so
I
picked
hooks
kind
of
arbitrarily
because
they're
like
it
says
it's
the
thing
that
runs
before
the
build
happens
or
something,
but
you
know
it
doesn't
quite
get
across.
They
used
to
be
called
stack
packs.
D
No,
I
think
it
was
just
alternative
there.
I
just
put
it
in
there,
it's
a
short
short
one.
I
know
we
don't
like
long
directory
names,
so
I
think
it's
for
me.
Directory
names
can.
E
D
Yeah,
that
was
mine-
I
didn't
suggest
initializers,
so
I
was
hesitant
to
say,
but
that's
what
I
was
thinking
it
would
be.
The
director.
F
B
E
A
Your
initials
in
that's
a
good
idea,
because
they're,
not
it's
not
a
vote
for
approval,
put
your
initials
in
front.
If
you
like,
the
suggestions.
C
A
All
right
seems,
like
things
have
settled
down
a
bit.
I
see
some
questions
in
the
chat
so
natalie
you
want
to
talk
about
your
comment.
C
F
E
E
F
F
So
I
think
between
those
the
extensions
and
initializers.
If
we
wanted
to
be
generic,
we
could
do
extensions
if
we
wanted
to
be
prescriptive
to
the
idea
of
a
pre-process
initializers.
A
A
B
B
Yeah
yeah,
I
think
it
implies
completely
the
wrong
thing.
I
agree,
like
I
think
stage
has
a
similar
problem,
but
at
least
we're
like
in
the
realm
of
building
images,
where
I
mean
containers
have
nothing
to
do
with
that,
and
I
think
it's
like,
I
think
it
implies.
Like
oh
yeah,
if
I
put
something
here,
it's
gonna
give
me
like
a
net
container
or
something.
F
I
was
gonna
bring
up
the
extensions
one
of
the
kind
of
hesitations
I
have
with.
That
name
has
to
do
with
the
idea
that
we
have
extension
specs,
and
I
know
that
in
the
past
we've
talked
about
potentially
putting
a
directory
somewhere.
That
basically
has,
like
extension,
related
artifacts,
and
you
know.
If
we
do
do
that,
then
it
would
be
very
confusing
to
have
extensions
and
extensions
mean
different
things
within
the
file
system.
B
A
It
seems
like
the
only
one
that
nobody
has
expressed
some
lack,
or
some
particular
offense
that
and
has
popular
support
as
extensions.
Does
anybody
want
to
say
something
negative
about
extensions
again?
We're
not
gonna
have
to
decide
here.
We
can
do
a
vote
later.
I
just
want
to
talk
through
all
the
options.
E
E
A
It's
just
gonna
say
we're
we're
at
and
now
over
time.
Hopefully
this
has
been
helpful
to
think
about
some
names.
We
should
do
a
kind
of
more
formal
poll
after
this
because
I
don't
think
we're
gonna
get
to
it.
Concerns
us
on
one
thing
in
particular
all
right.
Thanks.