►
From YouTube: Working Group: 2021-02-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
If
I
want
runtime,
we
forgot
the
first
bullet
point
yeah
my
fault.
B
A
I
forgot,
I
lost
my
train
of
thought,
but
basically
yeah
the
different
process
types
and
being
able
to
do
that
in
the
future.
B
Config,
that's
a
good
point:
the
when
you're
specifying
environment
variables.
Sorry
in
a
in
pack,
though,
like
if
it's
going
to
be
in
the
you
know
in
project
tamil
or
if
you're
going
to
pass
dash
dash
runtime
end.
Would
you
expect,
then,
to
have
some
syntax
for
saying
that
you're
just
setting
those
environment
variables
for
a
particular
process?
B
If,
given
that
the
user
is
not
contributing
the
process,
types
right,
the
build
packs
are
contributing
to
process
types.
Is
there
a
need
or
a
way
to
be
specific
about
where
those
environment
variables
apply?
Isn't
it
kind
of
like
the
build
pack's
responsibility
to
say
what
environment
variables
apply
to
the
process,
types
that
it's
contributing?
D
C
Potentially
porn
because
I
feel
like
it's
convenient
to
set
these
things
on
the
image
right,
that's
straightforward
fits
people's
expectations,
but
I
also
wonder
because
we
aren't
doing
that
with
build
pack
provided
environment
variables,
like
maybe
it
gets
confusing
people
start
seeing
environment
variables
directly
in
the
config,
and
they
expect
all
of
them
to
be.
There.
B
I
I
feel
like
in
the
back
of
my
head.
I
have
a
goal
of
making
it
possible
to
use
cloud-native
build
packs
without
the
launcher
at
some
point
in
the
future,
where
the
environment
variables
in
the
directories
could
all
be
evaluated
at
the
end
of
the
build
process
and
then
applied
and
you'd
lose
some
functionality
right.
B
You
wouldn't
be
able
to
input
runtime
environment
variables
that
then
get
processed
automatically
by
build
pack
code,
and
you
know
then
send
the
environment,
but
that
mode
seems
like
it
would
be
useful
for
some
use
cases,
especially
because
our
launcher
is
in
go
and
so
for
functions.
There's
a
little
bit
of
overhead
with
the
you
know,
dc
starting
up
and
everything,
and
so
this
this
feels
like
another
place
where
you
would
take
a
strong
dependency
on
the
launcher.
E
It
makes
me
think
even
inside
of
project
humble
if
we
need,
if
there
is
just
like
a
community-sanctioned,
build
pack
that
does
this
functionality
and
there
just
needs
to
be
more
configurability
for
doing
build,
packs
like
being
able
to
pass
in
a
bunch
of
stuff
to
it
build
packed.
That
could
then
do
this
makes
me
think
of
the
discussion
we
had.
I
feel
like
it
was
two
weeks
ago
or
something
similar
with
like
inline
bill
packs
and
like
wanting
to
expose
more
functionality
inside
project
humble
for
simple
things.
C
A
It's
about
shifting
the
extensibility
from
something
that
is
managed
and
maintained
by
the
project
to
something
that
could
be
independently
maintained
right
I
mean
I
could
see
that
as
being
the
argument,
if
we
consider
like
build
packs
as
the
extension
point
right
like
use
these
set
of
build
packs
that,
let's
say
even
the
project
maintains.
A
I
know
we
haven't
discussed
that
in
the
past,
but
you
know
you
have
these
build
packs
that
then
just
provide
additional
functionality,
as
you
wanted
to,
instead
of
adding
the
complexity
to
the
core
system
of
the
life
cycle
and
then
adding
that
contract
to
anybody
else.
That
wants
to
adhere
to
that
contract
right.
C
C
And
I
think
the
sort
of
the
syntax
for
how
we
do
this
with
the
paquetto
build
pack
like
one
of
the
reasons
I
want
to
make
this
into
the
lifecycle,
like
all
the
users,
that
I
support
right
now,
have
this
functionality
right
through
this
build
pack,
but
I
think
the
interface
is
less
than
ideal,
because
you
need
to
pass
normal,
build
time,
environment
variables,
but
we
have
special
prefixes,
like
bpe,
underscore
append
before
your
key
name.
B
I
have
a
maybe
a
different
approach
for
getting
to
the
same
conclusion,
because
I
think
we're
talking
about
you
know
philosophical
reasons
for
the
you
know
how
we
might
include
it
or
excluded
in
different
parts
of
the
interface,
but
it
may
be
that
there
are
requirements
for
how
these
this
behaves.
That
mean
that
we're
kind
of
driven
to
use
a
file
based
solution
so
like,
for
instance,
do
we
expect
runtime
environment
variables
to
be
set
before
the
build
packs
supplied,
runtime,
environment
variables
or
afterwards
like?
B
Should
their
input
be
processable
by
the
life
cycle
or
not
if
the
life
cycle
sets
them
in
the
environment
at
the
very
end,
and
then
the
build
pack
environment
variables
run
afterwards.
You
know
they'll
get
overwritten
like
what
are
our
expectations
about
the
behavior
of
you
know:
user
supplied,
runtime,
environment
variables
through
pack,
build
dash,
dash,
run
dash
and
when?
How
would
we
expect
those
to
interact
with
other
build
packs,
because
that
may
make
our
decision
easier
on
the
you
know
for
what's
right
for
the
interface
perfect.
E
C
B
So
it's
override
so
that
what
we're
talking
about
is
really
an
override
of
the
build
pack
provided
environment
variables
that
get
loaded
dynamically
during
launch
and
in
that
case
making
it
into
the
image
would
be.
I
mean
it'd
be
doable
like
you
could
read
it
and
then
you
could
write
it
afterwards
or
something
in
the
launcher.
But
you
know
that
would
be
pretty
weird
so
that
that
would
push
me
away
from
baking
it
directly
in.
D
C
Create
these
files
or
it's
like
you-
have
a
build
pack,
I
think,
having
a
build
pack
sort
of
introduces,
concepts
around
order
and
other
things
that
I'm
not
sure
we
want
to
get
into
when
they're,
like
very
straightforward
to
things,
I
don't
think
it's
just
environment
variables.
I
think
labels
process
types
and
like
maybe
even
app
slices
are
things
you
just
feel
the
set.
C
E
I
think
more,
my
point
was,
I
don't
think
the
configuration
in
prachitomo
whatever
is
sufficient
enough
to
make
that
a
good
experience
for
bill
pax,
which
is
maybe
just
a
separate
tangent.
E
Like
I
think
it
would
be
nice
when
you're
like
saying
I
want
to
use
the
spill
pack
in
project
tomlin
to
be
able
to
potentially
pass
the
config
of
like
the
runtime
of
mbars.
You
want
to
use
as
part
of
that
in
the
tamil
file.
C
Well,
right
now
you
set
a
build
time
environment
variable
with
a
special
prefix
and
the
build
pack
strips
off
the
prefix
and
sets
it
as
a
runtime
environment
variable
in
the
simplest
case.
So
you
either
set
it
in
your
m
section
of
project
tumble
or
pass
it
on
a
command
line
with
an
m5.
If
you're
using
pac.
E
I
guess
I
was
maybe
suggesting
something
like
a
extending
the
build.bill
packs
thing
in
project
tamil.
So
potentially
you
could
pass
in
specific
stuff
for
that
build
pack,
because
I
think
it's,
if
you
think
about
the
interface
as
like
it
is
linked
to
the
build
embar
it
gets
really
gross,
because
I
think
it
runs
into
the
issues
potentially
some
stuff
steven's
talking
about
where
it's
like.
You
really
do
potentially
want
them
to
be
separate,
like
I
don't
think
you
necessarily
always
want
runtime
stuff
linked
to
stuff
you're
passing
to
build.
C
E
D
D
Or
any
platform,
I
don't
like
writing
it
there,
just
because
of
the
override
reasons
like
I
don't
want
volumes
like
wiping
it
out
on
accident.
F
But
then
you
start
thinking
about
if
you're
trying
to
set
properties
on
the
application
that
were
a
function
of
what
a
bill
pack
did,
then
the
bill
packs
the
best
place
thing
to
understand
how
to
manage
that,
because
over
time
that's
going
to
shift
and
then
your
build
pack
can
take
the
old
values
that
came
in
and
it
can
mutate
them
before
it
sets
them
into
the
the
output.
So
it's
an
important
functional
point
in
the
chain,
then
of
managing
that
data.
B
Maybe
an
example
could
be
so
you
have
a
really
simple
java
build
pack
that
doesn't
do
a
lot
of
fancy,
jvm
tuning
or
whatever
right,
just
kind
of
installs
java
and
then,
like
you
know
that
you're
providing
a
jar
as
your
you
know,
source
directory
and
then,
as
a
user.
You
want
to
add
some
jvm
tuning
properties
into
the
image,
so
you
don't
have
to
put
them
in
your
case
deployment
configuration
when
you
run
it
right,
it
might
be
annoying
to
have
to
like
find
a
build
pack.
That's
going
to
understand.
B
Oh,
I
need
to
take
some
or
create
a
build
pack.
That
will
say.
Oh,
I
need
to
take
some
jvm
tuning
parameters,
they're
going
to
be
supplied
as
build
time
environment
variables
and
make
sure
I
export
them
out
to
runtime
environment
variables.
But
I
I
agree
that
I
think
that
we've
gotten
this
far
as
a
project
without
the
ability
to
set
runtime
environment
variables
in
the
image
is
indicative
that
it's,
maybe
not
as
common
in
use
case,
that
we
imagine
it
is
like.
I
haven't.
C
There
are
a
couple
cases
where,
like
existing
kettlebell
packs,
not
the
java
ones
we'll
take
the
build
time
environment
variable
and
set
it
at
launch
time
as
well,
but
I
feel
like
this
is
less
explicit,
but
the
bill
packs
trying
to
do
something
convenient,
but
sometimes
users
want
a
different
value,
build
in
launch
time.
So
you
don't
really
have
that
option
available
to
you.
C
There's
definitely
big
cases
on
the
spring
side
as
well,
where
someone
wants
to
like
append
a
argument
to
their
java
commands.
Like
you
know,
at
launch
time,
I
want
you
to
respect
this
additional
profile
and
they
don't
want
to
have
to
specify
that
every
time
they're
deploying
it,
but
it's
not
something
they
want.
F
It's
just
in
a
lot
of
the
stuff
that
I've
seen
those
particular
ones
and
the
jvm
tuning
one
as
well
would
be
something
you
would
supply
by
the
environment
dynamically
at
deployment
time,
rather
than
something
that
you
would
be
baking
into
an
image
and
hard
setting
forever,
because
that
prevents
that
one
image
they're
never
being
tuned
differently.
You
know
to
do
your
red
black
testing
and
stuff
well,.
C
D
C
I
can
think
of
like
some
jvm
cases,
like
maybe
not
memory
region
tuning,
but
I
just
like
do
some
work
with
gemfire
dashes
and
stuff
like
that
and
depending
on
like
the
size
of
your
data
objects,
you
probably
want
to
tune
your
garbage
collection
a
little
bit
differently,
and
that
is
a
kind
of
thing
that
doesn't
vary
dynamically
at
runtime.
But
it's
not
the
kind
of
thing
that,
like
a
build
pack,
is
ever
going
to
know
about
in
advance
or
want
to
know
about.
E
Yeah,
I
think,
at
least
on
the
heroku
side,
for
like
some
of
the
ruby
and
rails
things
it's
like.
Potentially,
you
might
want
to
set
like
rails
m
or
something
by
default
like
we
said
to
production,
but
maybe
you
actually
have
built
out
some
other
environments
that
you
want
to
kind
of
force
this
image
onto.
E
I
think
that's
like
a
common
use
case,
or
maybe,
if
you
have
like
other
api,
endpoints
or
stuff
that
it
links
to
you,
want
to
be
able
to
hard
code
like
a
set
of
defaults
that
a
bill
pack
will
never
know
about
right.
It's
like
it's
specific,
my
app
like
by
default.
E
Expect
to
hit
this
api
right,
so
it's
it's
really
about.
I
guess
like
apps
as
a
configuration.
A
Yeah,
it
ultimately
depends
on
the
process
right,
like
handing
over
if
you're
thinking
about
handing
over
from
a
development
perspective
to
the
you
know,
devops
personnel,
then
you
want
to
give
an
image-
that's
already
almost
pretty
much
pre-configured
right
and
not
having
to
have
additional
configuration
then
set
afterwards,
and
I
mean
going
back
like
the
fact
that
there
is
a
build
pack
that
provides
this
functionality
should
indicate
that
there
is.
You
know,
a
need
for
this.
I.
C
B
Going
back
to
terence's
idea
about
metadata
for
each
build
pack
and
project
tommel,
that's
really
very
interesting
to
me,
but
we
we
had
a
for
the
old
cf
build
packs.
We
had
a
buildpack.yaml
file.
It
was
just
a
convention
where
the
top
level
thing
was
the
name
of
the
build
pack
top
level.
Keyser
name
of
the
build
pack
and
buildpacks
could
read
configuration
that
was
buildpack
specific.
B
We
we
ended
up
killing
that
for
build
time
environment
variables,
because
it
was
like
too
many
ways
for
people
to
configure
the
same
things
if
that
makes
sense,
but
build
time,
environment
variables
applied
to
all
build
packs,
and
maybe
that's
not
really
the
experience.
People
are
looking
for.
I'm
curious,
if
that's
a
more
general
idea,
that's
that's
worth
exploring
or
like
on
the
heroic
side.
If
you
you
know
had
had
similar
conventions
or
winds
of
configuration
that
are
more
more
unified.
D
Same
user
yeah
but
also
seems
restricting
in
some
ways
like
just
having
you
know,
if
you're
looking
at
real
zoom
to
make
a
decision
today
and
then
suddenly,
they
scope
it
to
the
this
particular
build
pack,
and
you
have
a
bunch
of
bill.
Packs
working
in
a
concert
then
like
it.
Maybe
won't
have
that
information
anymore
and
make
different
decisions,
but.
E
C
I
think
it's
a
slightly
different
concern.
I
haven't
seen
it
come
up
as
much
on
the
paqueto
side.
This
particular
concern,
but
one
of
the
things
I'd
worry
about.
If
we
did,
this
is
right
now
you
know
I
can
sort
of
like
let's
say
I
want
to
use
a
azul
zulu
jvm.
Instead
of
my
bellsoft
jvm,
I
could
kind
of
just
like
drop
another
build
pack
in
the
order
and
not
think
about
changing
my
configuration.
B
We
have
put
a
lot
of
effort
into
that
kind
of
decoupling
where,
like
when
build
packs
talk
to
build
packs,
they
don't
know
each
other's
ids
right.
You
can
make
them
really
really
easily
swappable
in
your
configurations,
if
you
decide,
you
know,
like
the
whole
dependency
system,
is
kind
of
based
on
that
idea,
so
that
that's
a
pretty
strong
argument
to
me.
C
Well,
there's
a
couple
different
environment
variables:
you
can
take
right
like
you
can
set
the
jvm
version.
It's
supposed
to
install
and,
like
all
of
our
different
jvm,
build
packs,
take
the
same
set
of
flags.
So
if
you
swap
one
for
the
other
or
even
just
put
a
new
one
first
in
the
order
because
it
will
consume
the
build
plan,
entry
and
the
other
one
won't
run
like
it's
very
replaceable
without
changing
anything
else.
E
C
D
F
I
mean
going
back
to
the
jvm
tuning
one
there.
If
all
you
could
get
away
with
passing
jvm
tuning
as
an
environment
variable
to
your
runtime,
if
you
know
which
jvm
you're
going
to
be
running
against
at
the
end
of
the
day-
and
you
know
the
exact
arguments
that
that
one
supports.
But
if
you
don't,
then
it's
time
to
start
writing
a
jvm
tuning,
build
pack
that
can
you
know
it?
F
But
that
sounds
quite
complicated,
but
it
does
provide
the
decoupling
now
I
I
still,
I
still
listen
to
the
idea
of
passing
runtime
environment
variables
that
will
be
baked
into
an
image
essentially
and
worry
about
that
slightly
against
the
idea
of
externalized
configuration
and
how
you
know
anything
that
you're
going
to
break
into
the
image
is
not
going
to
come
under
the
list
of
an
externalized
configuration
agreed.
F
F
D
F
F
It
is
a
common
thing,
isn't
it
that
people
are
going
to
want
to
do
this,
because
it's
the
easy
way
to
avoid
having
to
manage
your
configuration
at
deployment
time?
If
you
baked
everything
into
the
image
and
the
image
just
works,
when
you
deploy
it,
it's
fine,
but
then
you
haven't
really
gained
the
advantage
of
properly
externalizing
it.
So
you
can't
then
run
it
on
a
different
environment
with
different
configurator.
You
have
to
rebuild
the
image
first
or
I
think
sorry.
A
No
sorry,
I
apologize.
I
think
it
depends
on
the
use
case
right
if
you're
building
an
image
that
is
a
minecraft
server
right
to
use
joe
cuttner's
example
right,
like
that,
isn't
intended
to
go
into
some
sort
of
like
secondary
process
of
where
the
environment
is
tied
to
something
else
right.
It
goes
to
a
more
simplistic
solution,
which
I
think
we
still
want
to
enable
as
part
of
this
project.
D
F
B
F
I
think
I'm
quite
heavily
biased
because
most
of
the
images
I'm
messing
with
most
of
the
stuff.
The
scenarios
I'm
looking
at
are
enterprise
grade
big
coupe
deployments
or
big
multi-service
deployments
within
large-scale
organizations,
and
they
definitely
don't
want
to
go
inside.
But
I
can
totally
get
the
point
that
if
you're
just
like
creating
a
jamula
server-
or
you
know-
whatever-
you
know
like
home
home
level-
service
that
you're
just
going
to
deploy
on
docker,
because
it's
easy
for
somebody
to
do
it
that
way
and
minecraft
definitely
fits
that
model.
B
That's
a
situation
where
you're
not
going
to
be
able
to
it
would
be
really
annoying
to
document.
Oh
yeah,
everybody
who
consumes
this
image
you
have
to
set.
You
know
blah
blah
blah
some
obscure
thing
equals
to
some.
You
know
constant
value,
it
would
seem
really
weird
and
in
enterprise.
I've
definitely
seen
cases
where
the
you
know.
B
Some
very
large
organizations
where
the
operators
are
not
you
know
are
so
disconnected
from
developers
that
the
the
way
you
provide
your
app
to
them
is
you
know,
here's
the
place.
You
put
your
image:
you're
not
allowed
to
define
additional
runtime
configuration
because
that's
you
know
part
of
the
it
operator.
B
You
know
space
and
as
a
developer,
you
might
you
might
want
that.
You
know
ability,
or
maybe
it's
harder
to
define
the
you
know-
to
get
people
to
make
changes
at
that
level.
So
I
could
see
I
could
see
arguments
you
know
kind
of
along
those
lines
of
when
the
personas
are
not
the
same.
C
I
think
from
the
life
cycles
perspective
at
least
we
should
default
like
philosophically,
to
sort
of
flexibility
and
allowing
people
to
use
whatever
workflow
works
for
them,
and
then
you
can
sort
of
leave
it
to
platforms
to
be
a
bit
more
opinionated
like
not.
Every
platform
has
to
expose
this
feature,
and
maybe
other
platforms
like
if
every
app
that's
running
on
is
running
completely
internally
and
they
want
to
take
in
some
platform,
specific
environment
variable.
B
That's
very
like
the
gut
feeling
I
have
about
this
is
like
oh,
not
allowing
people
to
do.
This
feels
like
a
lot
of
the
decision
making
they
made
in
the
past
around
trying
to
create
very
constrained,
builds
where
the
operator
has.
You
know
an
amount
of
control
or
really
trying
hard
to
prevent
the
developer
from
shooting
themselves
in
the
foot.
For
some
reason-
and
I
think
what
we
saw
over
and
over
again
is
when
we
put
those
kind
of
inflexible
guard
rails
in
place,
you
know.
B
Yes,
it
accomplishes
that
goal,
but
it's
it's
too
much.
It
makes
it
causes
users
to
get
frustrated
when
they
can't.
You
know
account
for
some.
You
know
weird
edge
case.
I
think
in
the
cloud
foundry
built
back
side.
Historically,
that
was
like
something
I
would
have
changed
is
probably
more
flexibility
in
that
respect,
and
so
that's
that's
why
I
think
I
also
lean
towards
saying
we
should
add
it.
You
know,
even
if
I
you
know,
as
long
as
platforms
can
turn
it
off.
If
they
want
to.
D
So
we
talked
a
lot
about
this
being
a
part
of
like
project
tomml,
which
is
of
course,
an
extension
right,
and
we
talked
about
a
prepare
phase
that
we've
also
talked
about
being
sort
of
extension
right
like
optional.
So
this
is.
Where
does
this
feature
if
we
were
going
to
build
it?
Where
does
it
live?
C
B
A
An
input
to
the
life
cycle,
the
life
cycle
could
do
whatever
it
wants
with
it
afterwards
for
the
final
image.
A
I
mean
it
doesn't
even
have
to
say
the
name
platform
right,
because
it's
not
platform
at
that
point
anymore.
It's
just
runtime
environment
variables
or
launch,
which
brings
me
to
my
other,
maybe
net.
Here
I
think
from
the
project
tamil
perspective.
I'd
like
to
use
the
term
run
or
run
time
as
opposed
to
launch,
because
I
think
launch
is
maybe
very
internal
in
context
to
the
lifecycle
and
the
build.
A
F
D
C
D
They
don't
know
what
launcher
launcher
is
so
like
run
makes
the
most
sense
to
me
from
that
perspective,
and
I
you
know
whatever
we
have
to
do
to
make
that
consistent
seems
fine
yeah,
just.
C
F
I
was
having
to
explain
to
somebody
the
other
day
that
no
the
life
cycle
isn't
something
we
need
to
rewrite
from
scratch
to
the
specification
that
is
already
there
yeah
yeah
the
biggest
confusion.
There
basically
comes
down
to
build
packs
that
I'm
saying
build
packs
with
a
capital
b,
which
is
the
whole
thing
and
build
cut
spill
packs
with
a
little
b,
which
are
the
things
that
live
inside
a
builder
image.
E
F
Right,
which
has
extra
ones
that
gets
added
as
well
so
and
that's
referred
to
as
a
build
pack
directory
and
you're
like
that's,
not
it's
sort
of
related.
But
what
is
a
build
pack
at
this
point
is
a
build
pack,
a
thing
that
lives
in
a
builder
image
or
is
a
build
pack,
a
collection
of
builder
images
with
buildbacks
and
an
ecosystem
like
where?
Where
would
you
describe
pequito
at
that
point
or
a
picato?
I
don't
know
pronunciation
for
it,
but
you
know
I
mean
how
would
you
describe
that
within
the
terms
of
bill
packs.
B
E
E
C
Well,
which
one
do
you
use
that
to
refer
to
so
I'll
use
that
to
refer
to
both
the
project
and
the
individual
things?
If
I'm
trying
to
differentiate
from
the
previous
generation,
I
don't
use
it
to
differentiate
between
project
and
build
packs.
F
A
All
right
so
as
far
as
going
back
to
the
rfc
I'll
try
to
draft
something
up
or
delegate
we'll
see
which
one
comes
out
first.
A
To
work
through
when
drafting
the
rfc
asking
questions
on
the
implementations,
slack
channel
to
figure
out
those
details,
because
it
does
seem
like
it's
more
opinionated
on
that
side
of
things,
but
the
high
level
feature.
That's
what
I
want
to
care
about.
A
E
B
So
we
can
call
this.
People
have
ideas
about
runtime
environment
variables,
maybe
open
an
rfc,
kick
it
off
on
github.