►
From YouTube: Working Group: 2021-03-11
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,
let's
see
so,
we've
started
the
recording.
I
did
have
a
meta
point.
I
wanted
to
bring
up
and
we
don't
have
to
resolve
it
here,
but
I
will
be
out
of
office
next
week,
so
I
am
looking
for
so
somebody
to
volunteer
as
a
facilitator
in
my
absence.
So
we
could.
A
You
know
if
you're
interested
in
doing
that.
It
really
is
just
about
being
present
and
being
able
to
answer
any
questions
that
might
come
up,
but
yeah
anybody
willing
to
volunteer
for
next.
A
A
Okay
moving
on
thank
you
for
that,
so
it
seems
like
we
have
two
topics:
github's
actions
configuration
with
the
audience
being
the
contributor.
I
do
also
see
a
run
versus
build.
Do
we
know
who
added
that
that
one,
I'm
just
curious,
if
maybe
that
was
a
little
bit
more
applicable.
C
D
A
Do
we
mind
if
we
do
that
one
first,
since
I
feel
like
it
might
be
a
little
bit
more
general
to
everybody,
and
then
we
could
dig
into
the
contributor
specific
one
awesome
all
right.
Sam,
do
you
want
to
take
it
away?
Yeah
your
question.
C
Yes
briefly
describe
like
so
the
use
case,
I'm
imagining
here
and
then
I
can
talk
about
what
the
spec
says
so
currently
in
the
platform
spec.
It
says
that
the
run
user,
id
and
group
id
should
be
set
to
the
same
user,
id
and
group
id
as
the
build
images
user,
and
it
should
match
with
the
actual
images
user
field.
C
Now,
sometimes,
when
you're
building
apps,
you
may
want
to
build
apps
that
are
essentially
frozen
or
have
a
read-only
file
system
so
that
when
you're
launching
it
in,
let's
say
some
some
runtime
environment,
the
user
can't
modify
the
app
the
files
or
directories
that
have
been
created
during
build
time.
C
A
A
I
don't
know
natalie
if
you
have
anything
in
mind
right
now,
but
I
guess
the
part
where
something
like
refreshes
my
mind
is
the
openshift
platform
right
which,
if
my
understanding
is
correct
on
some
of
the
users
for
openshift
the
uid,
essentially
when
the
application
is
ran,
is
is
ran
as
this
other
you
know,
user,
that's
not
necessarily
the
one
that
the
image
was
created
for,
I'm
pretty
sure.
That's
that's
a
true
statement.
So
therefore
I
wouldn't
say
that
it's
out
of
the
realm
of
possibilities.
A
As
far
as
the
spec
is
concerned,
I
think
that's.
You
know
a
very
interesting
question.
C
Yeah
and
I'm
just
curious
why
that
point
is
in
the
spec
if,
if
if
it
has
some
negative
impacts
or
if
it
was
just
something,
I
just
was
curious
behind
the
reasoning
for
that,
because
maybe
I
don't
want
to
set
the
user
externally,
so
I'm
guessing
openshift,
the
user
is
decided
by
some
by
some
modification
made
later
on
to
the
image
or
something
else.
But
let's
say
in
the
run
image
itself.
I
want
to
set
a
different
user.
C
What
I
is
there
anything
wrong
with
that
or
would
anything
like
I've
tried
it
and
it
seems
to
work.
So
I'm
just
curious
why
the
spec
says
it
shouldn't.
D
C
So
I
I
mean
you
can
still
verify
that
the
user
is
non-root
right.
You
can
still
verify
that
the
user
is
not
a
user
with
uid0.
D
B
C
That
I
mean
yeah.
My
final
objective
is
to
have
like
a
read-only
file
system
like
I
want
to
essentially
a
frozen
image
and,
like
the
only
maybe
writeable
thing
should
be
something
like
a
scratch
volume
like
either
temp
or
some
volume
that's
attached
during
runtime.
But
whatever
is
there
in
the
image
I
would.
A
Yeah
the
use
case
is
definitely
very
interesting.
I
think
it
definitely
makes
sense
and,
like
I
said,
I
don't
think
it's
it's
beyond
the
capabilities
or
possibilities
right
now,
but
as
kenny
kenneth
was
mentioning
they're
they're,
I
guess
we.
A
If
my
understanding
is
correct,
we
try
to
veer
on
to
the
side
where
the
permissions
set
on
the
file
system
right
are
the
permissions
that
you
expect
to
have
at
runtime
and
as
build
time
right.
So
I
think
we're
really
just
trying
to
align
those
as
far
as
the
repercussions.
What
happens
when
you
go
beyond
that
right?
I
think
that's
really
the
the
big
question
again.
A
I
think
one
of
the
the
other
places
where
this
has
come
up
with
is
with
openshift,
and
I
know
emily
has
kind
of
brought
up
the
mention
where
we
might
need
to
revisit
how
permissions
or
our
strategy
on
permissions,
because
it
seems
like
more
often
than
not
we're
actually
bitten
by
the
kind
of
constraints
that
we've
set
versus
allowing
platforms,
and
you
know
I
guess
in
this
case
certain
use
cases
from
veering
off
of
from
what
the
spec
specifically
says.
C
Yeah,
because
I
would
assume
that
even
if
the
user
is
same-
and
I
said
the
directory
or
file
permission
says,
read
only
there's
nothing
preventing
from
the
same
runtime
user
to
change
that
permission
and
then
write
to
it
right,
yeah,
since
it's
the
same
user,
they
can
just
I'm
assuming
they
can
just
do
whatever
they
want.
With
those.
A
Files,
I
wonder
if
you
could
write
up
the
use
case,
just
like
you
did
here
in
the
spec
channel.
C
A
E
A
Okay,
moving
on
to
github
actions
configuration,
I
think,
yeah.
You
brought
up
this
question.
F
Yeah
I
just
put
a
topic.
I
mean
it
was
initially
something
they
brought
to
to
discuss
in
our
team,
and
then
we
changed
the
working
group
to
be
an
office
hour.
So
I
thought
it
would
be
something
useful
for
everyone
just
to
discuss
how
the
github
actions
work
in
our
repos.
F
I
had
a
chance
to
work
on
it
a
little
bit,
but
I
think
javier.
I
have
a
feeling
that
you
can
like
try
this
and
talk
about
it
much
more
than
I
do.
I
think
it
could
be
very
useful
for
everyone.
A
B
Sure
I
guess
what
are
we
trying
to
achieve
like
a
general
sort
of
overview,
or
is
there
like
a
specific
problem
that
a
contributor
might
be
grappling
with
that?
We
want
to
clarify.
F
Specifically
for
me
there
is,
I
mean
I
don't
have
a
specific
question.
It
was
just
a
topic
that
I
think
someone
brought
up
in
one
of
our
discussions
in
our
tech
talks
and
then
I
thought
to
myself.
Okay,
maybe
we
should
discuss
it
more
like
more
details,
so
I
don't
have
any
questions.
I
mean
any
specific
question,
but
I
think
it's
worth
like
describing
what
happened,
how
things
are
working?
F
A
Yeah,
so
so
maybe
two
things
to
interject
here,
I
think
I'm
interested
on
you
know
the
use
of
docker
within
the
build
process
of
the
life
cycle.
I
thought
I
thought
that
was
very
interesting
and
I
don't
have
enough
context
there.
So
I'd
maybe
like
to
understand
exactly
why
it
is.
We
went
that
route.
A
Yeah,
so
I
think
sam
has
a
very
specific
use
case
in
mind
where
he
wants
to
create
a
essentially
like
a
read-only
app
image,
and
the
understanding
is
that
the
spec
kind
of
constrains
what
the
gid
and
uid
for
the
user
is
and
between
build
and
run
images.
A
C
C
And
then,
if
it
wants
to
do
some
processing,
it
can
do
that
in
like
separate
temporary
directories
or
volumes.
And
so
currently
the
spec
says
that
the
iran
images
user,
like
the
uid,
the
cnb,
uid
and
gid,
must
be
set
to
the
user
field
in
the
run
image.
C
And
that
must
be
the
same
as
the
build
image
but,
like
I
think,
I've
tried
it
and
there's
nothing
that
prevents
me
from
doing
this
on
back
like
I
can
set
a
different
uid
and
gid
and
it
seems
to
work,
but
the
spec
disallows
that
so
I
was
wondering
if
there
are
any
repercussions
to
actually
doing
this
or
why
this
decision
was
made
and
if
we
can
account
for
such
use
cases
where
we
want
even
fewer
permissions
during
run
time.
G
C
That
would
be
a
property
of
the
stack,
though
right.
So
if
the
build
pack
says
it's
compatible
with
a
particular
stack
and
the
stack
has
different
users
set
on
the
build
image
and
the
run
image
whatever
build
pack
is
compatible
with,
it
should
be
compatible
with
the
fact
that
there
would
be
two
different
users.
C
G
D
E
Yeah,
there
are
definitely
edge
cases
where
that
doesn't
work,
because
that's
how
old
heroku
used
to
work
on
our
platform-
and
we
definitely
had
to
change
our
tune
very
quickly.
But
if
you're
building
your
own
platform,
that
is
not
a
public
path.
You
can
definitely
like
limit
what
what
is
being
used
and
what
is
allowed
right.
E
Wait
yeah
would
we
want
to
expose?
I
guess
this
comes
back
to
amway's
like
want
for
this
new
stack
section
of
the
spec,
but
it
seems
like
maybe
that's,
there's
probably
some
level
of
things
that
we
want
stacksville
to
expose.
G
Yeah,
I
think
we
need
a
stacks
section.
I'm
also
wondering
if
we
should
be
breaking
down
stack,
ids
into
more
granular
information,
so
that
more
build
packs
can
be
compatible
on
things
that
they
should
run
on.
D
C
I
think
we
have
like
a
star
stack,
but
I
would
love
like
the
name
space
stack,
so
you
can
specify
like
a
top
level
name
space,
so
it's
compatible
with,
let's
say
all
of
one
two.
Then
you
can
go
something
down
to
bionic
and
then
some
other
derivatives
of
that,
but
something
like
that
would
have
been
would
also
be
great.
C
G
A
really
good
idea,
it
makes
me
really
wish
we
had
put
linux
before
ubuntu,
so
you
could
do
like
a
linux
start.
A
C
C
E
Well,
like
I,
like
you,
can
imagine
like
salesforce
or
heroku
having
its
own
set
of
stacked
things
that
are
compatible
with
a
bionic,
because
it
is
underneath,
or
maybe
it's
compatible
with
ubuntu
overall,
but
it
doesn't
have
to
be
labeled.
E
And
it
can
come
with
potentially
other
attributes
as
well.
If
we
expanded
on
the
stack
concept.
D
A
So
it
sounds
like
there's
multiple
rfc
ideas,
but
going
back
to
the
original
question,
it
sounds
like
it's
very
reasonable
to
as
a
path
forward
to
suggest
that
change
right.
I'm
assuming
that
would
be
an
rfc
proposal.
G
Yeah,
it
seems
like
the
kind
of
thing
we
probably
weren't
an
rfc
for
the
fact
that
it
works
now
means
you
can
probably
do
it
yeah,
because
it's
not
broken,
but
I
agree
that
we
should
make
that
clear.
C
Yeah,
I
I
was
just
hoping
that
like
because
it
works
right
now
I
was
just
hoping
like
I
I
don't
implement
like
I
don't
use
some
buildback
or
implement
some
buildback
in
the
future
and
then
suddenly
it
stops
working
and
the
assumptions
crumble
so
just
wanted
to
clarify.
If
that's
like,
there's
something
in
the
underlying
life
cycle
that
that
assumes
those
things
or.
A
D
G
We
try
not
to
break
old,
build
packs
ever
in
new
lifecycle
versions.
So
even
if
a
new
api
came
out
and
we
added
a
check
to
enforce
it,
we'd
probably
only
add
the
check
for
the
new
api,
even
though
the
older
versions
said
they
would
said
they
had
that
requirement
right.
So
I
don't
think
like
we're
not
going
to
add
behavior
that
breaks
something,
but
I
think
it's
good
to
capture
this
as
an
rfc.
So
we
know
not
to
you
know,
add
that
behavior
new
lifecycle
versions,
because
it's
under
discussion
and
maybe
not
ideal.
A
Yeah,
but
it
could
also
be
a
platform.
Validation
right,
like
pac,
could
take
this
information
from
the
current
spec
and
say:
oh
you
know
what
like
sam
just
mentioned,
that
we
missed
a
part
of
their
requirement.
Let's
go
ahead
and
vote.
G
D
A
Oh
man,
okay,
all
right,
so
that
that
sounds
good.
Any
more
conversation
on
that
topic.
A
Cool,
I
know
I
have
to
drop
here
in
four
minutes,
but
if
we
want
to
continue
to
the
next
topic,
we
could
certainly
do
so.
B
I
I
also
have
to
drop
in
four
minutes,
but
I
can
do
my
best
in
the
time
that
we
have
to
introduce
the
github
actions
in
the
life
cycle.
Javier
had
the
question
about.
Why
do
we
use
docker
so
maybe
I'll?
B
This
one
okay
and
what
was
it
it
was
this
thing,
so
we
have
a
bunch
of
github
actions.
Probably
the
one
that's
most
interesting
for
now
is
to
look
at
the
bill
which
runs
on
pushes
and
pull
requests
to
main
and
our
release
branches.
B
You
can
see
it's,
you
know
it's
fairly
easy
to
read.
We
have
tests
that
run
on
linux
and
windows.
Then
we
build
assuming
there's
no
test
failures.
We
will
build
and
package
a
life
cycle
on,
looks
like
because
we're
able
to
cross
compile
the
lifecycle.
We
can
just
do
the
builds
for
linux
and
and
windows
all
on
ubuntu
we're
currently
pinned
to
1804,
because
we
had
a
a
weird
thing
that
happens,
but
something
that
we
can.
We
can
probably
unpin
with
a
small
change
and
then
what's
probably
interesting
for
our
purposes.
B
Here
is
the
fact
that
we
we
package
the
lifecycle
binaries
into
the
format
that
you
would
see
on
the
release
page.
You
know
if
we
decide
to
ship
these
artifacts
those
these
these.
Actually,
these
artifacts
would
be
the
ones
that
you
download,
so
that
gets
uploaded.
You
know
to
wherever
github
keeps
track
of
them
and
then
to
answer
javier's
question.
B
After
all
of
that
has
happened,
we
published
the
lifecycle
image
which,
if
you
don't
know
what
that
is,
I'm
going
to
shamelessly
plug
a
blog
post
that
I
wrote
I
can
get
that
chat
back,
which
explains.
Why
is
there
what
it's
used
for
well
here?
It
is
more
chat.
B
We
actually
build
that
image
with
our
own
tooling.
That
makes
use
of
image
you
till
and
kind
of
mimics.
The
way
the
exporter
builds
images,
but
because
it
was
harder
to
do
that
to
create
a
manifest
list.
B
A
I
think
we'll
call
it
early
due
to
availability
but
yeah
catch
us
next
time,
and
we
might
even
discuss
this
topic
further
if
we
want
to
dive
into
anything
specific.
Thank
you
thanks.
So.