►
From YouTube: Working Group: 2021-03-17
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).
C
I
gotta
spend
five
minutes
at
the
beginning,
making
sure
everybody's
name
links
to
their
profile.
C
All
right,
let's
jump
in,
do
we
have
any
new
faces.
C
C
I
don't
think
there.
I
think
everybody
else
has
been
here
before
so
we'll
move
on
to
release
planning
and
updates
start
with.
A
Implementation,
I
can
speak
to
that.
We've
been
working
on
implementing
the
06
apis.
I
think
we
just
decided
to
push
one
of
the
features
that
was
in
06207,
but
that
will
position
us
well
to
ship
the
rest
of
the
stuff
soon.
A
C
B
I
talked
about
this
at
the
previous
office
hours.
The
idea
is
that
the
build
image
and
round
image
have
different
uids
with
the
same
gi
d,
so
that
the
purpose
of
this
would
be
for
security,
so
the
user
can't
edit
any
of
these
files
unless
they're
group
writable
at
runtime.
C
Yeah,
I
wonder
if
this
is
the
wrong
way
to
go
about
solving
the
problem,
especially
because
build
packs
may
make
assumption
like
if
you're
using
20
different,
build
packs
in
your
build.
Many
of
them
may
make
assumptions
about
whether
they
can
write
using
unix
permissions.
To
you
know
it
will
definitely
work
as
a
means
of
preventing
rights,
but
if
it's
really,
the
goal
is
to
have
a
read-only
image,
you
know
it
might
be
better
to
do
that.
Using
platform
features
that
make
the
file
system
read
only.
A
Should
we
add
this
as
a
topic
if
we
want
to
talk
about
it,
yeah,
like
I
think,
it'd
be
better.
If
sam,
I
guess,
did
this
yeah
was
here,
but
I
think
we
can
fight
it
out
a
little
bit
without
him
time
zone
is
hard
for
him
yeah
I
mean
I
think
we
can
still
leave
feedback
and
then
talk
with
them
about
it.
C
All
right,
so
that's
in
the
agenda.
Next
one
disambiguate
layer,
metadata
files
from
app
metadata
another
one
from
sam.
B
I
can
talk
to
this
too,
because
I
just
read
through
it.
I
think
it
came
out
of
a
conversation
that
we
had
in
slack,
but
right
now
we
name
files
that
contain
layer
metadata
with
the
layer,
id
dot
tomml,
but
we've
added
a
couple:
other
dot,
tomml
files
that
built
packaging
for
other
purposes,
launch
toml
and
build
tomml,
and
every
time
we
add
one
of
those.
A
It's
interesting
because
isn't
there
a
spec
pr
that
attacks
us
from
exactly
the
opposite
direction
for
forbids
those
names
completely.
B
That
spec
pr
was
also
from
sam,
and
it's
codifying
what's
already
true,
like
the
life
cycle,
actually
forbids
you
from
creating
layers
with
those
names,
but
it
was
never
in
the
spec.
So
I
think
that
pr
is
about
clarifying
the
world
as
it
actually
is,
and
we
probably
want
to
merge
that
change
into
the
next
api
version,
so
we
can
get
in
as
soon
as
possible
because
it's
an
undocumented
truth
about
how
our
life
cycle
behaves,
at
least,
and
I
think
this
is
a
better
approach
for
versus
suspect.
After
that.
B
Yeah,
I
thought
maybe
a
better
solution,
be
to
like
reorganize
the
directories
and
stuff
like
that,
but
I
feel,
like
we've
run
into
problems
like
this,
a
lot
where
this
is
better
than
what
we
have.
The
best
thing
is
a
major
reorganization
that
I
wouldn't
want
to
require
in
order
to
merge
this
improvement
right.
A
C
C
Awesome,
it's
much
easier,
rfc
process,
specific
working
directory.
C
Forest
here,
yeah
yeah-
I
made
some
updates
to
this
from
feedback
from
last
working
group
meeting
changed
the
key
name
and.
A
Oci,
like
oci
image
metadata,
I
have
some
typos
that
I
need.
C
Have
discourse
on
it?
It's
totally
fine
I'll
keep
looking
at
this
sounds
good.
I
still
don't
like
your
key
name.
I
think
working
directory
is
too
long.
We
should
go
to
the
kate's
working
dirt.
C
A
C
Awesome
next
thing
in
the
list
is
guidelines
for
accepting
component
level.
C
Oh
yeah,
that's
right!
Sorry,
just
read
it
without
thinking
about
it.
Yes,
so
where
are
we
at
with
this
one.
A
I
think
the
biggest
thing
from
the
last
working
group
was
an
action
for
you
to
review,
to
investigate
cncf
policies
or
if
there
was
prior
art
there
in
ccf.
I
left
a
comment
like
a
few
minutes
ago
on
that
from
joe's
thing
other
than
that,
I
think
it
looks
good
to
me
and
just
like
just
trying
to
make
sure
we're
not
doing
anything.
We
shouldn't
be
sounds.
C
Good
I'll
follow
up
on
the
if
there
are
any
legal
questions
and
stuff
before
pushing
them
forward.
A
C
Issue
generation-
javier's-
not
here,
also
see
where
we're
at.
It's
got
some
comments
20
minutes
ago.
So
it
looks
like.
A
I've
incorporated
feedback,
I
don't
know
how
to
get
people
to.
I
guess,
review
it,
but
need
some
type
of
view
from
the
rest
of
the
folks
in
the
core
team.
A
I
could
poke
them
more,
but
I
know
there's
a
sherpa
for
this.
Oh
there
isn't
one.
How
does
this
not
have
a
sherpa.
C
C
Thanks
cool
looks
like
I'm
a
sherpa
on
this
one.
This
looks
like
it
has
enough
approvals
to
move
forward.
Yeah,
that's
where
I've
been
through
sap.
I
think
it's
blocked
on
issues
being
created,
closing
on
march
yep
waiting
for
some
issues
to
be
created.
Where
are
we
with
that?.
B
B
C
A
Yeah
I
put
this
one
up,
so
this
I've
been
seeing
quite
a
bit
and
I
think
some
other
folks
have
as
well
so
I
ran
into
this
when
I
was
doing
a
pack
build
of
the
kpac
controller
and
I
was
using
the
cf
build
service,
tiny
builder
and
consistently
over
the
last
couple
days.
A
I
reach
a
unexpected
status
code,
504
gateway,
timeout
and
we're
thinking
that
it's
a
docker
issue.
I
tried
it
with
a
couple
other
builders
as
well
no
success,
and
I
know
that
anthony
said
they
were
experiencing
some
similar
problems
and
yell,
maybe
as
well
or
did
you
say
that
I
posted
about
it
in
the
build
packs
pack,
cli
slack.
A
I
don't
know
if
that's
the
best
place
for
this,
but
I
was
wondering
if
we
you
know
if
anyone
else
was
experiencing
this
or
if
there
is
a
way
that
we
could
maybe
make.
You
know
the
life
cycle
a
little
bit
more
resilient
to
these
errors
and
something
that
we
wanted
to
look
into.
A
I
just
want
people's
thoughts
on
that.
I
just
have
to
say
that
I
stopped
experiencing
this.
Oh
you
did.
C
I
gave
a
demo
a
couple
like
sometime
late
last
week
and
kept
getting
504s
when
I
was,
I
had
to
switch
to
a
smaller
app
because
it
was
too
big
and
for
my
local
kind
cluster
I
couldn't
export
layers
to
it.
So
I've
definitely
seen
those
errors.
Also
is
there
a
does?
Go
container
registry
do
very
much
to
retry
uploads.
B
C
A
C
C
All
right,
the
next
thing
agenda
is
different
user
rfc.
Let's
talk
about
both
of
sam's
rfcs
without
him
here.
B
B
A
B
But
you
make
sure
the
group
has
access
right,
but
I
don't
think
there's
a
lot
of
cases
where
you
want
the
you
know.
The
group
has
to
have
read
access,
but
I
don't
think
you
want
the
user
access
in
many
cases
and
also
you
could
say
that
some
of
this
is
rolled
up
into
the
stack
id
like
a
build
pack
says
it
supports
a
stack
and
the
default
users
are
a
feature
of
the.
C
Stack
so
this
wouldn't
this
wouldn't
mean
that
for
an
existing
stack,
you
can
use
a
different
idea
that
run
image
just
that
the
stack
is
allowed
to
say
that
the
run
image
runs
as
a
different
user.
I
wonder
if
this
is
too
much
stack.
Proliferation
like
we,
we
said.
Okay,
stacks
are
now
like
bionic
they're,
not
like
you
know,
bob's
custom
stack
right,
ideally
for
stack
ids
it
you
know.
Is
there
a
way
we
could
express?
C
I
use
the
cont
like
express
contractual
okayness
with
read-onlyness
right
without
having
to
you
know
have
people
you
know,
create
different
versions
of
the
stack
and
separately.
Is
this
something
we
want
the
user
to
be
able
to
control
by
selecting
a
stack
image
or
is
this?
Is
this
more
like?
Could
this
be
a
build
pack
feature
that
says
when
the
exporter
exports,
these
layers
make
them
root
owned
instead
of
owned
by
the
cnb
user?
Would
that
be
a
better
interface.
B
I
don't
think
it
should
be
the
build
packs
responsibility
because
I
think,
definitely
see
cases
where
the
people
who
want
to
do
this
are
not
build
pack
authors,
they're,
sort
of
app
developers
who
are
running
in
a
platform
that
has
certain
guidance
or
their
stack
authors
right.
C
I
think
maybe
the
direction
I'm
coming
from
is:
why
are
all
of
the
files
the
build
packs
generate
writable
by
default?
Anyways
like
it
seems
like
it's
a
little
bit
of
it's
like
kind
of
the
way
you
know
cloud,
foundry
and
heroku
used
to
work.
It's
not
that
uncommon.
You
know
on
platforms
for
the
files
to
be
owned
by
the
user.
That's
running
them,
but
you
know
like
if
you
look
at
a
linux
distribution
deployed
to
a
vm
right.
C
Apache
is
running,
as
you
know,
a
hdbd
user,
but
the
files
are
all
owned
by
root.
So
you
know,
if
you
get
access
to
that
user,
you
can't
modify
it
like.
Should
that
maybe
be
the
default
and
then
build
packs
have
to
opt
in
to
you
know:
user
writable
directories
if
they
want
to,
and
then
that
way,
it's
not
something
like.
A
C
C
Yeah
because
there's
like
it's
kind
of
inconsistent,
whether
tools
will
write
with
the
group
with
group
write
or
not.
I
wonder
if
it's
better
to
like
ignore
the
permissions
and
just
use
the
just
like
if
the
flag
were
just
you
know,
is
this
layer
writable
by
root
or
is
this
layer
writable
by
you
know
the
normal
user
and
the
default
is
root
and
export
right?
Would
that
be
enough.
C
B
I
don't
know
so
I
think,
where
it
gets
complicated
is
the
place
where
this
ends
up
being
the
most
relevant
is
probably
the
after,
rather
than
bill
peck
created
layers
anyways,
I
don't
know
if
the
build
pack
always
knows.
B
I
guess
a
build
pack
could
say
like
make
the
actor
not
writeable.
If
I
really
wanted
to
right,
not
sure
it
feels
like
the
right
distribution
of
responsibilities.
To
me,
I
sort
of
like
the
straightforwardness
of
a
bill
pack
offer
author
being
able
to
in
their
build
pack
if
they're
inspecting
the
file
permissions
or
something
those
are
the
permissions
that
are
going
to
be
in
the
final
image.
And
then
they
can
check
the
user
of
the
final
image
sort
of
straightforward
a
little
bit
less
magic.
C
There
is
a
security
benefit
to
the
two
user
model,
which
is
you
know,
kind
of
on
that
track
right,
which
is
that,
if
you
had
like
you
know
some
zoo
id
things
that
once
they're
owned
by
root,
become
more
dangerous
right
having
it
having
everything
owned
by
a
build
time,
user,
that's
separate
from
the
runtime
user
might
might
be
the
most
secure.
You
know
configuration
for
it.
B
We
can
also
give
some
guidance
that
you
know
if
you
need
to
write
a
file
or
something
in
an
exec
d
or
profile
on
startup.
You
should
be
using
a
tempter
or
something
that
is
expected
to
be
writable
by
the
runtime
user,
not
the
actor
or
layer.
B
C
It's
safer
to
do
this
in
a
really
coarse-grained
way
than
do
than
or
to
like,
have
the
interface
be
coarse-grained
and
absolute
as
opposed
to
kind
of
pushing
the
complexity
of
permissions
management
onto
build
pack
author
or
you
know,
app
developer,
like
the
user,
seems
the
right
level
for
this
to
me.
I
I
wonder
if
the
there's
another
proposal
to
allow
build
packs
to
select
a
run
image
or
have
multiple
run
images
per
builder
right.
I
wonder
if
this
there's,
like
some
contract,
to
build
pectomal
where
bill
peck
can
say
you
know
this.
C
A
A
Yeah,
like
I
actually
want
to,
I
want
to
push
back
on
your
your
desire
for
a
coarse
grained
thing.
I
think,
making
making
very
surgical
changes
is
actually
a
preference
here.
Security
wise,
like
I
think,
the
default
case
today,
right
like
if
we
split
the
user
ids,
like
nearly
everything,
would
work
today,
because
we've
already
had
to
go
off,
certainly
like
on
our
side
of
the
fence.
A
We've
had
to
go
off
and
deal
with
the
fact
that
there
are
read-only
use
cases
for
this,
so
we've
actually
already
done
the
hard
work
and,
if
I
do
want
to
make
an
exception
to
it,
making
an
exception
in
one
very
small
directory
or
one
very
surgical
file
feels
like
a
better
outcome
than
saying.
Okay
flip
the
switch
so
that
everything's
writable
again.
For
me.
C
I
I
think,
I'm
okay
with
surgical,
like
saying
you
know
these,
these
particular
files
are
writable
or
not
right
about
the
life
cycle
level.
It
just
to
me
using
the
user
to
control
that,
as
opposed
to
changing
the
group
and
hoping
that
all
the
files-
or
you
know,
have
the
right
group
permissions
or
you
know
what
not
seems
like
it's
a
little
bit
safer.
So
I'm
not
I'm
not.
If
we
decide
to
go
with
something
that
where
you
could
say,
these
groups
of
files
are
owned
by
this
user
and
these
groups
files
are
not.
C
A
C
C
In
a
minute,
make
sure
we're,
including.
A
Difficult,
it
might
be
to
do
some
of
these
situations.
We've
talked
about
with
windows,
so
I
think
whatever
we
design,
we
want
to
make
sure
to
loop
in
someone
who's
got
a
little
bit
more
windows
permission
stuff
here
yeah,
I
will
say
we
we
did
do
in
the
early
days
of
heroku,
even
pre-build
packs.
We
did
do
this
read-only
thing
and
as
a
pas
I
know
we
ran
into
a
bunch
of
problems
of
just
most.
A
People
are
fine,
but
there
was
definitely
like
the
five
to
ten
percent
of
people
who
ran
the
problems
of
just
us
always
assuming
to
mount
read
only
but
like,
I
think
I
said
last
week
in
office
hours
when
sam
brought
this
up,
like,
I
think
for
sam's
use
case.
It's
not
a
general
pass
is
a
very
specific
like
internal
thing
that
you're
building
like
you,
get
to
kind
of
make.
Those
calls
right
like
this
is
just
how
this
platform's
gonna
function.
A
So
when
we
came
around
and
did
build
packs,
I
think
we
explicitly
by
design,
did
not
force
the
kind
of
built.
I
guess
work
working
directory
to
not
be
read
only.
C
That's
running
node
can
also
modify
the
node
binary
right
that
to
me,
that's
the
the
worst
part
of
the
security
story,
what
we
have
and
that
making
it
so
that
by
default
in
the
normal
case,
when
build
packs,
when
the
node
build
pack
installs
the
node
runtime,
you
know
it's
running
as
a
normal
user,
but
at
launch
that
user
can't
go
back
and
modify.
The
runtime
afterwards
seems
like
it'd,
be
a
really
big
win
and
the
rest
of
the
interface
around
that.
I
don't
have
extremely
strong
opinions
about.
B
What
I
like
about
the
two
user
solution
or
what
I
think
is
elegant
about
it-
is
that
we're
not
forcing
build
pack
authors
or
app
developers
who
are
debugging
issues
to
have
to
learn
about
our
specific
feature.
That
represents
this,
like
it's
all,
just
using
things
that
they
are
already
familiar
with.
B
That's
what
I
think
is
nice
about
it,
and
I
don't
know
why
we
explicitly
forbid
this
in
the
spec
like
if
I
go
and
take
a
bionic,
pacquiao
run
image
and
change
the
user.
Like
everything
already
works
right
now,
it's
only
the
spec
that
says
you're
not
allowed
to
do
that,
but
it
it's
totally
fine.
C
A
C
No,
but
it
hurts
it
hurts
build
pack,
authors
right
because
build
tech.
Authors
read
that
they
can
make
an
assumption,
a
strict
assumption
right
and
if
we
relax
that
assumption
and
say,
okay
users
are
actually
allowed
to
change
like
the
developers
are
allowed
to
change
the
user
at
runtime
to
something
where
they
could
no
longer
write.
Then
buildpak
authors
made
a
decision
about
some
that
they'd
be
able
to
write
to
locations
now
their
bill
packs
will
fail
at
launch.
In
those
cases.
A
Yeah,
like
I
hate
those
build
pack
authors
like
I,
I
think
the
reason
that,
like
the
paquetto
build
packs,
don't
like
do
not
observe
this
to
be
a
significant
problem
and
the
fact
that
it
will
just
work
is
like
we're
super
careful
about
not
writing
any
files
into
an
ephemeral
container
in
the
first
place
like
there's
no
right
anymore.
In
these
things,.
A
And
even
that
is
hyper
protected
for
those
environments
where
this
runs
in
a
completely
read-only
environment
like
no
matter.
What
change
we
make
here,
every
single
build
pack
that
writes
a
file
should
already
be
accounting
for
the
fact
that
they
might
be
running
on
that
other
platform.
That
really
strongly
encourages
you
to
go
with
read-only
file
systems
just
for
safety.
B
And
we've
enabled
a
feature
in
pack:
let's
run
the
build
in
the
root
group,
so
that
you
actually
create
a
runnable
image
and
that
whole
workflow
is
actually
kind
of
similar.
To
this,
where
the
only
thing
you're
guaranteeing
is
that
the
group
is
the
same,
but
platforms
can
be
changing
users,
and
I
think,
if
we
built
in
an
expectation
in
our
spec
that
we
had
to
run
as
specific
users
we're
going
to
end
up
being
incompatible
with
some
platforms
that
we
could
be
compatible
with.
C
A
Yeah,
I
think
I'm
okay,
putting
a
pin
in
this
since
sam
didn't
participate
anyway.
We
don't
even
have
like
what
his
preference
would
be
on
this,
but
I
think
there's
a
good
enough
discussion
for
us
to
move
on
to
the
next
one.
I
guess
what
are
we
putting
on
that
pr?
Oh,
we
have
the
discussion,
but
he
did
not
hear
it
and
or
may
not
actually
watch
the
recording
everybody
go
back
and
make
your
arguments
in
the
pr.
C
C
So
I
could
also
mention
hey.
This
was
discussed
at
the
working
group
meeting
for
a
good
20
minutes
might
want
to
take
a
look.
B
C
B
Listen,
I'm
with
you
or
like
an
ideal
world.
We
wouldn't
have
named
the
actor
workspace
be
named
app
and
the
layers
dirt
would
be
named
workspace
and
each
build
pack
have
a
workspace.
Maybe
under
that
they'd
have
some
layers
because
there's
a
bunch
of
stuff
in
layers
that
aren't
layers-
and
this
is
a
hack
to
solve
that-
and
maybe
there's
a
better
solution.
C
There's
like
there's
no
reason
thinking
about
the
life
cycle.
Implementation
there's
no
reason
why
we
have
those
files
as
persistent
files
that
survive
each
execution
of
the
build
pack
and
in
fact
we
have
other
files
like
the
billet
materials
files,
right
that
are
ephemeral
and
go
away
after
each
build
pack
executes
and
they're
processed
by
the
life
cycle,
like
it's
just
kind
of
weird
that
we
have
launched
tommel
and
bill
toml,
where
they
are
at
all
in
some
ways.
C
You
know
when
other
other,
similar
files
like
build
materials,
files,
right
inputs
and
outputs.
You
know
come
into.
C
That's
right,
yeah.
The
plan
isn't.
C
A
C
B
B
C
B
Pass
things
between
life
cycle
phases
on
a
volume
instead
of
making
users
around
yet
another
volume,
for
no
good
reason.
We
like
to
use
the
volume
that
already
exists,
so
I
think,
even
if
we
got
some
of
this
stuff
out
of
layers,
they're
always
going
to
be
a
couple
things
in
layers
that
aren't
layers.
C
B
Well,
I
like
the
ephemeral
files
better
than
platformer.
I
think.
C
Platform,
there
already
has
some
ephemeralness
right
with
the
environment
variables
coming
from.
I
guess
they're,
not
exactly
ephemeral
platform
sets
that's
up.
Could
we
make
a
new
directory
inside
of
the
layer,
stirrer
called
metadata
or
something
and
then
just
have
one
layer
name,
that's
permanently
you're
not
allowed
to
use
metadata
and
metadata.tumble.
C
Can
we
move,
we
do
have
a
metadata
directory?
No,
it's
called
config.
C
C
Sorry,
instead
of
instead
of
figuring
out
instead
of
moving
build
tomorrow
and
launch
tomlin
to
the
platform
door,
we're
coming
up
with
another
location
to
write
those
files,
that's
maybe
fixed
for
every
build
pack
and
is
parsed
in
between
the
two.
Could
we
keep
everything
we
have
as
it
is
today,
but
instead
of
renaming
the
layer
metadata
files
to
layer,
dot,
something
dot,
tom
will
just
have
one
reserved
layer
name
like
metadata.
There
would
be
a
folder
inside
of
layers
that
would
then
have
tombl
files
in
it
like
launch
tunnel
and
build.
B
C
B
C
C
C
Maybe
sam
can
go
back
and
listen
to
the
different
options
here
and
see
what
he
likes
best.
B
Layers
anymore,
oh
well,
actually,
if
you
don't
make
the
directories
out
of
the
name,
then
you
can
reuse
your
layers.
Okay,
take
it
back.
This
is
the
advantage
to
the
approach.
If
we're
only
renaming
the
metadata
file,
we
don't
have
to
change
the
paths
of
the
directory,
so
we
don't
have
to
throw
away
old
layers.
Yeah.