►
From YouTube: Working Group: 2022-04-19
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
get
started
well
welcome
everyone
to
the
pacquiao
working
group
weekly
meeting,
we're
really
glad
to
have
you
here.
Let
me
share
my
screen
real
quick
here.
A
All
right
who
would
like
to
take
notes
for
this
session.
Is
there
anyone
who
like
to
volunteer
for
that.
A
A
There
you
go
okay
and
also
your
affiliation.
We
want
to
share
okay,
so
new
faces,
you
see
a
couple
of
new
faces.
I
don't
know
if
this
is
the
first
time
you
join
this
session
feel
free
to
introduce
yourself.
B
Hi
there
I
I
may
be
a
face
that
you
don't
recognize.
I
I
I
don't
recognize
you
I'm
a
returning
face.
I
have
been
in
this
meeting
suddenly
last
year.
At
some
point,
I
am
stepping
in
as
the
manager
of
vmware's
potato
contribution
team
and
having
previously
worked
more
focused
on
the
commercial
implementations
of
those
bill
packs
prior
to
that,
an
emeritus
contributor
to
the
cloud
native
bill
pack
project
itself.
A
C
Welcome
yeah
hi,
I'm
the
leader
yeah.
I
I've
been
working
on
bill
packs
for
a
bit,
but
mostly
implementation
side
and
some
of
the
sort
of
stuff
to
do
with
how
red
hat
wants
to
use,
build
packs
in
the
future
and
particularly
interested
in
the
whole
dockerfile
stuff
that
they've
got
going
on
over
there
at
the
moment,
but
a
lot
of
what
I'm
doing
is
now
starting
to
stray
back
down
into
the
now
that
sort
of
stuff
is
settling.
A
That's
great
welcome.
Welcome
us.
We
are
glad
to
have
you
here
all
right,
anyone
else.
No,
I
don't
think
so.
Okay,
so
next
step
will
be
to
review
outstanding
rfcs,
so
we
will
start
from
the
bottom
rfc
for
secure
runtime
environments.
D
Looks
like
he's
incorporated
most
of
our
feedback,
so
I
guess
at
this
point
we're
mostly
waiting
on
dan.
Unless
your
comment
is
recent,
I
don't
know
if
you
need
to
re-review
or
if
you
have
another
outstanding
comment
down.
A
A
E
D
I
finally
got
a
chance
to
read
through
this
one,
and
I
think
most
of
my
questions
were
about
the
cases
where
we're
sort
of
setting
values
in
this
file,
but
based
on
sort
of
the
state
of
the
image
that
we're
building
from
using
the
docker
file.
There
might
be
a
a
right
answer
to
this
and
the
question
is
sort
of
do
we
want
to.
You
know
like
cross-reference.
D
What's
in
this
file
versus
the
answer
we
find
in
the
base
image,
or
do
we
want
to
sort
of
like
take
that
information
out
and
just
grab
it
from
the
base
image?
So,
for
example
like
in
our,
if
we
were
rebuilding,
you
know
our
bionic
stacks
using
this
stack
descriptor
and
we
went
and
looked
in
the
xcos
release
file
we'd
find
that
you
know
the
distribution.
D
Yeah,
I
think
maybe
that'd
be
easier
and
then
the
other
thing
that's
like
that
is
the
platforms
where
you
know,
I
think
you're,
either
directly
referencing
a
manifest
for
a
single
image,
in
which
case
you're,
going
to
inherit
the
platform
or
like
sort
of
your
base,
image
right
that
your
docker
file
is
building
on
top
of
or
if
that
is
referencing
like
a
manifest
list
that
has
a
multi-arch
image.
Do
we
want
to
do
something
there
where
we,
you
know,
just
use
whatever
platforms,
we
find
my.
D
F
That
is
like
there
are
a
lot
of
platforms
so,
like
I
just
looked
at
jimmy
there's
six
platforms
in
the
jimmy
base
image.
I'm
not
sure
we
want
to
support
like
risk
v64
or
I
I
don't
know
there
was
like
a
few
others
that
I
was
like
these
are
kind
of
on
the
long
tail
of
things
that
I'm
not
sure
we
immediately
are
looking
to
support,
so
I
certainly
could
see
there
being
like
a
some
code
in
there.
F
D
I
agree
with
that.
I
don't
think
we
should
support
all
of
them,
but
I
think
maybe
we
need
to-
or
at
least
reading
this
wasn't
obvious
to
me-
sort
of
in
the
multi-arch
case,
sort
of
how
how
we
would
go
about
this
made
me
feel
like.
Maybe
we
need
to
have
some
more
requirements
about
the
docker
file.
It's
like
you
know.
D
We
have
from
a
base
image,
it
seems
like
we
would
want
to
require
that
to
be
a
build
arg
so
that
we
could
run
it
multiple
times
with
different
inputs
and
then
stitch
together,
a
multi-arch
image
from
the
output.
If
we're
going
to
support
multiple
platforms
in
a
single
invocation
of
create
stack
and
then,
if
we
don't
want
to
do
that,
you
know
for
all
versions
of
the
base
image.
F
D
Specify
something
more
specific,
but
then
you
can
be
specific.
I
guess
the
question
is:
if
we
want
this
to
spit
out
a
multi-arch
image
on
the
other
side,
then
I
think
we
need
to.
We
can't
let.
D
The
default
behavior
take
over
it's
like
if
I'm
running
on
an
amd
64.
You
know
vm
in
my
mac,
desktop
like
by
default.
If
I
run
the
docker
file,
that's
building
from-
and
I
just
say,
like
ubuntu
bionic,
it's
going
to
pull
the
linux
linux
amd64
and
it's
going
to
build
a
linux
amd64
image.
Now,
if
I
want
to
do
the
arm1,
I
need
to
more
explicitly
tell
it
to
use
the
arm1,
because
it's
not
going
to
match
the
platform
by
default,
but
it
actually
can
run
it
if
it's
using.
D
You
know
the
qemu
virtualization
and
then
you
need
to
do
something
to
take
the
two
outputs
of
that
and
turn
them
into
a
multi-arch
image.
So
it's
like,
if
this
create
stack
command,
is
going
to
be
doing
that
magic
for
us.
Then
I
think
I
need
more
detail
about
how
that
would
work
in
a
case
like
this,
and
maybe
we
need
to
put
more
requirements
on
the
docker
file,
so
we
can
explicitly
force
it
to
use
certain
variants
of
the
base
image
in
order
to
get
variants
that
we
need
for
our
multi-arch
build.
F
F
But
my
belief
is
that
that
is
what
it's
actually
pulling,
because
I'm
explicitly
telling
the
platform
or
telling
docker
what
the
platform
is.
At
that
point,.
D
D
F
My
intention
is
to
have
it
spit
out,
on
the
other
side,
like
an
ocr
oci
archive
that
is
like
a
multi-arch
like
image
index
that
has
you
know
all
the
variants
of
os
platforms
that
you're
targeting.
D
F
F
What
this
could
mean
for
bionic?
We
are
going
to
try
to
like
align
the
stacks
in
terms
of
the
way
that
they
operate.
I
think
there's
still
an
open
question
about
the
actual
repository
names
and
tagging.
I
think
we
maybe
just
have
like
a
difference
of
opinion
on
that
front.
Still,
so
I
don't
know
we
still
need
to
hash
it
out
in
order
before
we
get
to
something
we
could
use.
F
I
mostly
if
I
can
just
like
air
my
grievances
here.
I
mostly
am
just
confused
by
the
current
naming
like
repository
naming
scheme
because,
like
we
have
these
images
that
we're
like
calling
paquetto
packs,
slash,
build
and
paquetto
build
pack
slash,
run
except
like
depending
upon
which
stack
happened,
to
be
released
most
recently.
F
What
that
image
is
is
like
entirely
different
in
terms
of
its
content.
Really,
the
way
you
would
figure
out
what's
in
an
image,
is
to
look
at
its
tag
to
me,
like
tags,
at
least
the
way
that
I've
interacted
with
them
in,
like
every
other
kind
of
thing,
they're
really
trying
to
like
specify
for
the
most
part.
What
like
version
a
thing
is
even
stuff
like
jammy
is
like
jimmy
is
a
version
number.
It
happens
to
be
a
name,
but
it's
like
a
version
of
ubuntu.
F
It
isn't
that,
like
ubuntu,
is
entirely
different
or
like
configured
entirely
differently
in
those
different
versions.
So
to
me
to
have
like
these
other
things
like
the
base,
full
tiny
information
in
there
just
seems
a
little
bit
odd
because
you
are
like
at
that
point
delivering
like
logically
different
artifacts.
D
Building
off
your
jammy
first
of
all,
I
understand
this
is
totally
a
bike,
I'm
fine
with
whatever
we
come
out
of
this
with,
but
I
think
we
should
do
the
bike
shed.
Just
just
for
fun.
Going
off
your
ubuntu,
you
know
jammy
is
aversion
analogy.
D
Does
that
mean
our
repos
should
really
be
like
build
tiny,
build
base,
build
full?
And
then
it's
like.
D
D
F
F
F
D
So
that's
like
one
concern,
but
it's
not
a
super
important
one
concern
number
two
and
I
think
in
some
ways
this
is
already
addressed
here.
My
big
pet
peeve
about
the
current
system
is
the
dash
cmb
part
of
the
tags.
I
always
forget
about
it.
D
Because
in
some
ways
it
seems
like
it's
putting
a
qualifier
on
something
when
I
feel
like
it's
the
default
like
whatever
that
pre
image.
Is
that
isn't
the
stack
image
like
I
don't
care
about
that?
I
don't
care
if
anyone
pushes
it
to
a
tag
ever
again,
it
can
just
be
an
implementation
detail,
ephemeral
that
gets
thrown
away,
but
it
seems
like
that's
already
in
here.
D
D
My
question
is:
is
there
like
a
base,
build
image
and
different
flavors
of
it
like
the
ubi
flavor
and
the
jamie
flavor,
and
the
bionic
flavor,
where
it
would
make
sense
to
put
those
together
or
is
it
like?
D
D
So
yeah
I
don't
know-
maybe
I've
convinced
myself
through
this
whole
saying
this
out
loud
that
there's
no
better
option
than
what's
in
it
right
now,
but
it's
like
we
want
to
call
it
like
ubuntu
build
that
then
has
jammy
and
bionic,
but
then
you
still
the
flavors
and
then
what's
the
latest.
I
don't
know.
F
That's,
I
guess
slightly
different
than
if
you
went
with
one
that
was
like
you
know,
jammy
build
bass
then,
like
the
tags
are
actually
like,
differing
depending
upon
what
what
you
are,
what
happens
to
have
been
released
most
recently,
you
wouldn't
be
able
to
do
anything
like
say,
like
you
know,
jammy
build
latest
because,
depending
upon
which
image
happens
to
have
been
published
most
recently,
you'd
probably
get
something
entirely
different
than
what
you'd
expect.
F
I
think
sure
you
end
up
recreating
this
with
other
tags.
Basically,
what
ends
up
happening.
D
Sort
of
the
analogy
that
I
was
thinking
about
is
maybe
like
how
golang
images
are
handled
in
docker
hub
where
yes,
there's
goaling
and
there's
different
versions,
and
then
there's
you
know
mutable
tags
for
different
version
lines.
It's
you
know
major
version
x,
but
there's
also,
I
believe,
with
going
there's
different
underlying
operating
systems.
It's
like
do.
I
want
the
alpine
version
of
this.
Do
I
want
the
busybox
version
of
this?
D
D
That's
why
I'm
sorry
proposing
the
build
and
run
schema
like
those
seem
like
it's
like
I
don't
know,
I
want
the
build
image
or
the
run
image.
It's
like.
Oh
here
are
all
the
flavors
that
are
available
to
me
and
then
we
can
use
latest
as
some
sort
of
defaulting.
D
Mechanism-
and
maybe
we
can
even
use
it
to
eventually
like
move
people
to
a
new
default
stack.
I
don't
know
that
was
my
original
proposal,
but
I'm
curious
what
other
people
think
and
I'm
not
deeply
wedded
to
that.
G
C
G
I
actually
do
like
what's
outlined
in
the
rfc
now,
because
it
just
you
know,
makes
it
a
lot
simpler
and
I'm
also
kind
of
wondering
on
your
point
about
like
discoverability
in
docker
hub,
like
how
important
would
that
be
because
I
was
thinking
most
people
would
be
picking
up.
Obviously
people
would
be
looking
at
docker
hub,
but
a
lot
of
people
would
be
picking
up
the
stacks
from
what
we
have
in
our
builders.
F
I
think
the
same
problem
is
gonna
happen
on
the
builder's
side,
like
this
rfc
doesn't
outline
that,
but
like
I
definitely
had
an
open
question
at
the
bottom
of
like
what
does
this
mean
for
builders?
Generally
speaking,
I
think
we're
gonna
have
the
same
kind
of
like
naming
concern
there
as
well
be
great
if
they
lined
up
right.
That
would
help.
D
F
But
if
your
concern
is
like
discoverability,
then
like
we
don't
have
to
name
them
in
order
to
achieve
that,
you
could
just
do
like
what's
proposed
in
the
actual
rsc
now
and
make
it
so
that
the
readmes
basically
cross
post
information
about
the
other
builders
that
are
available
or
other
stacks
that
are
available
and
then
for
your
concern
about
like
what
the
default
could
be.
You
could
duplicate,
publish
one
of
the
stacks
under
the
like
canonical,
build
or
run.
F
Think
for
me,
the
hardest
thing
in
the
current
tag.
Naming
thing
is
like
I'll
go
to
the
like
current
page
and
I'm
kind
of
like
what
tags
even
are
there
and
I
like
end
up
scrolling
back
like
five
pages
before
I
discover
like
oh
there's
like
a
such
and
such
build
pack
list
base
builder
thing
that
I
can
use
and
like
it
just
isn't
easily
identifiable
on
the
front
page.
D
D
A
A
Yeah,
I
guess
no,
okay,
all
right!
Okay
project
update,
I
mean
there
are
some
updates
that
I
have
in
line,
but
I'm
not
exactly
recent
yeah
like
the
liberty,
wheel
pack
and
some
other
stuff,
but
it
happened
like
weeks
ago.
So
is
there
any
recent
project
update
that
you'd
like
to
share.
A
Okay,
is
there
any
questions,
especially
from
folks
who
just
joined?
Is
there
any
questions
around
the
project?
Anything
you
like
to
discuss.
A
No
all
right!
Well,
if
there's
anything
else,
I
would
like
to
say
thank
you.
Thank
you
for
your
time
for
your
input
and
hope
to
see
you
next
week.