►
From YouTube: Office Hours: 2021-06-24
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
So
hello,
everyone,
so
my
google
summer
of
code
project
mainly
revolves
around
the
buildbacks
github
actions
repository
and
before
we
started
on
our
actual
project
of
automating,
the
staging
index,
repository
and
registry.
We
wanted
to
clear
the
previous
issue,
the
previous
issue,
of
verifying
the
blocked
name
spaces.
If
they
are
blocked
name
spaces,
we
have
to
ex.
We
need
to
know
that
list
of
blocked
name
spaces
and
we
need
we
need
to
block
the
access
or
to
those
namespaces.
A
A
So
what
it
does
is,
basically,
we
are
getting
the
input
list
and
this
input
list.
What
does
this
input
list
is?
Basically,
we
are
just
inputting
a
string
basically,
but
we
are
returning
an
array
of
strings
and
how
are
they
being
separated?
They
are
being
separated
using
a
comma,
so
we
are
splitting
them
using
a
comma.
So
what?
What
is
this
list
about?
This
list
is
about
the
blocked
name,
spaces,
the
namespaces
that
will
be
blocked
and
the
correspondingly,
because
this
was
updated
inside
the
internal
toolkit,
dot
co.
A
I
updated
the
corresponding
test
tests
as
well
in
the
internal
toolkit,
along
with
that,
we
developed
the
logic
so
that
the
namespace
verification
is
is
works
fine
and
what
do?
What
did
we
do
here
was
basically
we
have
created.
A
function
is
blocked
namespace
and
we
are
passing
our
conflict
structure
and
if
it
is
returning
true
that
is,
if
it
is
a
block
name
space,
then
we
will
return
that
this
name
space
is
restricted,
so
we
will
block
the
excess.
A
So
what
we
did
here,
we
we
in
the
inside
the
struct.
We
created
a
block
name
space,
which
is
of
type
area
of
strings
so,
as
we
say
in
go
like
slice
of
string,
so
here
we
are
getting.
A
This
is
our
we
can
say
the
list
of
block
name
spaces
so
right
now
this
is
cnc
of
buildback
c
and
b,
build
packs,
iu,
build
pack,
we
can
later
on,
add
more
block
name
spaces
and
we
are
assigning
it
to
the
c
dot
block
name
spaces
so
that
it
overrides
the
value
that
has
been
assigned
as
the
environment
variable
by
the
user.
Also.
So
so
it
does
both
both
the
thing-
and
this
is
our
function
that
implements
the
logic.
So
we
are
passing
our
name
spaces.
A
Sorry,
now
we
are
passing.
We
are
going
through
the
entire
loop
of
block
name
spaces
list
and
we
are
matching
the
name
space.
If,
if
the
namespace
matches
the
name
the
names
mentioned
in
the
blocked
namespace,
then
we
will
be
returning
true,
because
then
it
will
be
a
block
namespace,
so
we
will
have
to
block
it.
Otherwise
we
will
just
return
a
false
and
it
will
return.
It
will
work
normal.
So
that
is
how
it
works,
and
for
this
also
I
added
a
test.
A
I
added
the
corresponding
context
text
here
and
verify
namespace
owner
underscore
desk.go.
So
after
this
we
were
able
to
merge
it
with
our
buildbacks
github
actions.
Yesterday
this
was
the
progress
that
we
have
made
till
now.
What
are
our
next
steps?
So
our
next
steps
will
be
now.
What
we
have
to
do
is
I
have
created
based
on
suggestion
of
joe.
I
have
created
the
fork
of
just
give
me
a
moment.
I
have
created
the
fork
of
github
build
packs
registry
index.
A
So
what
what
I
will
do
after
that
planning
to
do
is
that
we
will.
I
will
configure
it
to
my
local
pack
cli,
so
that
it
uses
my
fork
instead
of
the
official
repository,
and
I
will
be
doing
it
using
back.
Add
registry
option
back
config
registries
ad
option,
so
we
will
be
doing
with
that.
I
have
already
done
that
now.
A
I
have
to
just
follow
one
blog
to
test
it
out
and
to
see
if
the
the
thing
that
we
have
done
yesterday,
like
whether
when
we
are
registering
a
normal
buildback
with
the
namespace
that
we
have
mentioned
to
be
in
the
block
list,
whether
it
is
working
or
not
so
that
we
will
be,
we
will
be
testing
it
then,
and
after
that
we
will
be
working
on
the
main
part
of
the
project
which
is
like
like
right
now.
A
If
you
see
the
version
yesterday,
only
the
new
version
was
released
from
4.1
to
4.2
the
github
actions.
So
now
we,
what
we
need
to
do
is
we.
We
want
to
automate
this
process
and
we
we
want
to
automate
both
the
pr
to
update
that
version
and
the
testing
of
it.
So
this
is
now
this
will
be
the
main
goal
of
the
project.
This.
This
is
something
that
we
will
be
working
on
next,
but
before
working
on
that
next,
I
guess
I
I
I
thought
to
try
it
out
manually,
so
joe
suggested
the
same.
A
So
I'm
I'm
going
through
the
entire
process.
I've
been
reading
the
blog
throughout
the
day
and
today
and
maybe
tomorrow
by
tomorrow,
it
will
be
done
but
manually,
and
then
we
will
try
to
figure
out
the
logic
how
to
automate
this
entire
thing,
the
process
of
both
the
pr
to
update
the
version
and
as
well
as
the
testing.
A
B
All
right
thanks
so
much
for
sharing
next
on
our
agenda
today
is
stacks.
B
I
know
I'm
interested
in
talking
about
steven's
remove
stacks
rfc.
It's
a
little
bit
unfortunate
that
we
don't
have
the
bigger
group
we
usually
get
here
today,
because
I'm
sure
people
got
feelings
about
this
one,
but
even
probably
in
the
small
group.
I
wonder
if
people
have
have
questions.
C
B
C
Yeah,
this
is
probably
like
five
rfcs,
it's
just
enough
time,
and
I
said
okay,
this
you
know
this
is
what
I
think
it
should
look
like.
Probably
before
we
go
1-0
you
know
definitely
needs
work
before
it
could
be
merged
so,
but
also
happy
to
talk
about
the
specifics.
B
Yeah,
I
didn't
even
make
it
all
the
way
through.
For
my
commenting,
I
guess
the
thing
that
I
thought
would
be
interesting
to
talk
about
just
sort
of
like
how
you're
imagining
a
run.
Docker
file,
interacting
with
dynamic,
run
image,
selection.
C
Yeah,
so
originally
I
wasn't
thinking
those
things
would
interact.
I
just
figured
this
is
how
app
developers
supply
packages
and
also
run
image
selection
happens
and
there's
no
way
to
prevent.
There's
no
way
to
have
it
automatically
select
a
smaller
base
image
based
on
packages
that
you're
specifying
in
your
you
know,
app
directory
in
a
docker
file
that
those
would
be
things
to
support
language
modules.
Build
packs,
wouldn't
request
those
anyways.
It's
going
to
solve
a
separate
use
case,
but
it's
close
to
working
like
it
could
be.
C
You
know
we
could
tie
it
more
into
the
api.
I
almost
feel
like
we
shouldn't,
though,
because
the
the
whole
the
point
of
the
proposal
is
that,
like
this
is
not
a
problem,
we
should
really
try
to
solve
build
packs.
We've
designed
this
whole
api
to
be
a
great
application
level.
Abstraction
for
you
know
installing
dependencies
in
layers
on
top
of
some
api
compatible
base
image.
Instead
of
trying
to
solve
operating
system
package,
installation
better.
C
B
Agree
with
this,
because
I
feel,
like
stack,
packs,
already
open
up
that
can
of
worms.
But
if
you're,
not,
you
know,
modifying
things
in
this
sort
of
restricted
way
that
works
in
our
system
like
a
non-overlapping
layer
that
participates
in
this
stricter
life
cycle,
like
if
stack
packs
and
already
just
you
know,
go
change
whatever.
C
Why
why
invent
a
new
interface
to
solve
a
problem?
That's
already
solved,
that's
worse
or
that
you
know,
has
no
advantages
over
the
old
interface
right
yeah.
So
so
the
idea
wasn't
that
it
would
interact.
It
was
just
I
had
a
whole
bunch
of
ideas
about
stacks
and
then
put
them
in
one
rfc
and
didn't
want
to.
C
You
know:
go
through
the
effort
of
detangling
everything,
but
we
could
make
them
interact
pretty
easily
right
like
if
you
really
wanted
to
you,
could
label
the
docker
files
with
packages
and
then
match
those
in
addition
to
the
packages
that
you
know
that
are
coming.
C
B
Yeah,
I
guess
it
worries
me
a
little
bit,
I
kind
of
want,
like
some
vision
of
how
they
interact
if
we
want,
if
we
really
want
to
do
both,
I
wonder
if
we
don't
need
the
dynamic
run
image
selection.
Is
that
just
like
an
a
nice
to
have,
but
it
adds
more
complexity
than
it's
worth
like
right
now.
I
think
we
have
these.
B
B
I
mean
as
a
project.
We
don't
specify
this
one
way
or
another,
but
sort
of
want
to
push
people
as
a
convention
to
like
smaller
builders,
poor
per
language,
family,
and
then
maybe
you
don't
need
to
make
as
many
dynamic
choices
about
the
wrong
image.
C
C
Sometimes
you
want
to
build
your
thing
on
top
of
distro
list,
and
sometimes
you
don't,
but
maybe
get
rid
of
the
automatic
dynamic
run
image
selection.
Let
people
specify
multiple
images
in
the
builder
and
then
provide
a
flag
where
the
developer
can
choose
which
run
image
gets
used
in
the
end,
and
then
it.
C
B
B
But
there's
going
to
be
a
couple
cases
like
when
you're
running
tomcat,
you
know
where
catalina
starts
with
a
shell
script,
you
can't
can't
run
on
distrolus,
so
it'd
be
kind
of
cool
like
this.
Is
I'm
gonna
make
a
case
for
your
dynamic
running
selection?
I'm
just
wondering
how
many
cases
are
like
this,
where,
like,
if
you
build
your
app
you'd,
almost
always
get
this
for
list,
but
you
know
if
you're
running
tomcat
it
needs
bash.
C
C
You
know
larger
something
like
that
right
like
how
bad
would
it
be
if
it
wasn't
automatic
or
they
could
install
whatever
they
need,
specifically
in
their
docker
files
right
if
they
had
a
they
wanted
to
provide
just
the
stuff
that
their
tomcat
app
means.
I
don't
know
if
I
make
sense
in
this
context,
but
you
get
the
idea.
B
B
I
guess
I'm
curious
about
like
okay,
so
that's
one
case
where
dynamic
we're
on
image
selection
would
be
good.
I
think
it
might
be
interesting
to
populate
this
rfc
with
more
examples,
and
then
we
could
decide
how
much
how
important
this
problem
is
to
us.
Therefore,
how
much
complexity
we're
willing
to
introduce
in
order
to
solve
it.
C
That
makes
sense,
I
think,
an
advantage
of
starting
with
forcing
the
app
developer
like
having
them.
Just
when
you
build
the
builder,
you
provide
a
map
of
some
name
to
run
image
and
there's
a
default
one,
and
then,
when
you're
doing
pack
build
with
the
builder,
you
can
select
a
particular
run
image
from
it,
and
the
command
line
would
be
that
if
we
wanted
dynamic,
run
image
selection
in
the
future,
we
could
add
it
on
top
of
that
and
it
would
just
be
an
override.
C
That
would
be
hard
because
oh
wait,
no
dynamically,
select
the
run
image
and
then
run
the
docker
file.
But
then
you
don't
know
what
packages
are
installed
by
the
docker
file
right.
That
is
what
happens
actually.
C
B
B
C
C
B
C
When
you
build
the
in
builder
tunnel
right
this
as
proposed,
it
would
look
like
a
list
of
an
ordered
list
of
run
images
and
all
their
individual
run
image
mirrors.
They
would
run
through
that
list
in
order
to
pick
the
first
one
that
matches
right
better,
that
it's
a
map-
and
it
has
name
thing
name
thing,
sorry
name,
run
image
and
mirrors
name
to
run
image
and
mirrors,
and
one
of
them
is
called
default
and
the
default
one
runs
automatically
or
it
has
a
default
key
and
it
has
another
name.
C
When
you
do
a
build,
it
always
picks
the
default
one.
Unless
you
do
dash
dash,
run
image
and
then
there's
another
notation,
that's
not
explicitly
used
as
run
image
from
docker.
That's
use
the
labeled
one
of
the
builder.
So
you
do.
You
know
dash
dash,
run
image
tomcat
in
the
tomcat
case,
and
we
pick
the
special
image,
that's
for
tomcat
out
of
the
builder,
but
you
don't
have
to
know
where
the
tomcat
image
lives
in
your
registry.
C
C
B
C
B
Okay,
I
can
see
that
then
we
so
we
dynamically
select.
We
apply
the
dockerfile
to
the
thing
we
dynamically
selected.
Hopefully
that
works.
If
it
doesn't,
then
you
could
explicitly
select.
C
B
C
B
And
sometimes
you
want
things
to
fail
because
they're
not
gonna
work,
but
I
don't
think
it's
worth
the
complexity
to
get
that
early
failure
most
of
the
time,
especially
because
if
people
aren't
using
them
correctly,
you
don't
get
the
early
failure.
Anyways.
B
C
A
C
B
B
Extract
data
from
it
produce
in
a
different
format,
bake
it
into
a
label.
I
think,
hopefully
that
would
be
small
enough,
that
it
could
be
a
label
which
would
make
everything
easier
for
everyone
like.
I
know
we
want
to
put
the
bomb
in
a
layer
because
we
have
to
and
like
tooling
to
make
it
easier,
but
I
don't
want
us
to
start
putting
lots
of
things
in
layers
because
I
think
it
just
gets
confusing
and
also,
I
think,
there's
probably
a
couple
ways
you
could
specify
these
things
in
cyclone
dx.
It's
like.
B
If
you
have
a
package,
that's
a
dependency
of
a
package.
You
know,
are
you
nesting
it,
and
I
forget
what
all
the
terms
are
like
an
assembly
under
your
package
or
are
they
all
peers,
like
I
kind
of
just
don't
want
to
worry
about
that.
C
B
C
Yeah,
so
I'm
not
going
to
push
back
very
hard
on
this,
but
I
just
I
just
want
to
frame
it
a
little
bit
differently,
so
actually
the
requirement
that
you
put
them
back
on
the
label
instead
of
putting
them
as
a
layer,
that's
referenced
in
the
label.
If
we
really
believe
that
it's
never
going
to
be
too
long,
then
that's
a
good
justification
for
it.
Like
it's
one
request,
instead
of
two
okay.
C
C
Sense
to
restrict
them
to
just
os
packages
right,
you
can
imagine
somebody
installing
a
lot
of
ruby
gems
or
something
on
the
base
image
and
then
listing
a
huge
amount
of
ruby
gems
in
that
cyclone,
dx
formatted
thing,
and
maybe
that's
something
that
we
care
about
matching
against.
I
don't
think
it's
supposed
to
be
super
restricted
for
packages,
so
I'm
a
little
I'm
a
little
on,
I'm
not
quite
sold
on
that.
We
should
put
it
directly
on
the
label.
C
I
kind
of
think
unless
it's
fixed
length
data
now,
because
there's
a
problem
with
it,
we
should
immediately
go
to
a
layer
for
anything
that
could
grow
infinitely,
but
putting
that
to
the
side,
the
assuming
it's
assuming
they're,
both
just
as
many
requests
to
get
right.
The
cyclone
dx
list:
it's
not
very
hard
to
run
through.
It's
not
going
to
be
more
than
I
don't
know
a
megabyte
of
data
or
something
like
that
right.
B
B
I
think
it's
because
like
if
it
was
just
us
doing
the
comparison
I
would
agree.
Actually
there
are
cases
where
you
know
platforms
want
to
do
these
things
and
also
want
to
easily
expose
just
the
essential
things
to
users.
So
they
know
why
things
are
incompatible
or
can
you
know
decide
whether
to
run
an
image
before
using
it,
and
I
don't
want
every
platform,
it's
the
logic
around
this
stuff
to
be
coupled
to
this
bomb
format.
It
feels
wrong
to
me.
C
B
B
A
B
C
B
Okay,
so
I'm
like
going
to
choose
between
some
run
images
in
this
world,
and
I
want
to
know
which
one
image
I'm
trying
to
choose,
which
one
image
I
want
to
use,
I
want
to
like
pack,
inspect,
base
image
and
figure
out
what
packages
are
on
there
as
a
human
being.
I
don't
want
to
see
the
entire
cycle
on
dx.
For
that
I
want
to
see
the
list
of
packages
to
figure
out
whether
this
is
the
base
image
I
want
or
what
I
need
to
install.
C
I'm
not
going
to
push
back
hard
on
it,
but
I
feel
like
it
to
me.
It
seems
more
likely
that
platforms
would
want
to
be
able
to
present
the
list
of
the
stuff
and
the
image
to
users
and
let
them
query
for
what
you
know.
What
version
of
openssl
is
in
this
image.
Things
like
that
right
that
that
feels
like
something
that's
further
away
from
the
core
api
closer
to
things.
C
B
It's
just
kind
of
annoying
like
I'm
going
to
go,
implement
that
in
spring
boot,
I'm
going
to
implement
it
in
pack,
I'm
going
to
implement
it
in
kpac,
it's
like!
Maybe
I
don't
want
to
deal
with
it.
I
just
want
the
list
of
things
because
in
a
lot
of
context,
the
platforms
themselves,
you
know
only
care
about
what
can
and
can't
run
and
like
there's
different,
there's
the
same
data,
but
there's
different
reasons
why
people
want
to
look
at
it.
It's
like
do.
I
want
to
generate
an
osl
file.
B
B
C
Last
question:
if
both
have
to
go
in
layers
proper
file
system
layers,
would
you
does
that
change
your
mind
at
all?
Would
you
feel
like
that's,
that's,
that's
suddenly
more
machinery,
or
it's
already
hard
enough
to
get
the
data
might
as
well
make
it
only
do
it
once.
B
C
B
B
C
I
I
think,
that's,
maybe
the
the
core
core
philosophical
disagreement
is,
I
think
all
platforms
are
going
to
inherently
need
to
understand
the
format,
because
you
want,
like
pac,
inspect
image,
to
show
you
the
package
names
and
their
versions
and
more
information
than
just
you
know.
The
pearl
formatted
ubuntu
package
names
right.
I
imagine
like
we
want
to
provide
a
really
rich
experience
for
understanding
the
dependencies
in
the
image
through
the
pax
cli.
C
B
I
can
think
of
platforms
that
would
parse
neither
pack
probably
wants
to
parse
both,
although
I
will
say
that
right
now,
like
we
show
people
the
bomb
in
pack
and
pack
does
not
actually
parse
it
or
understand
the
format
at
all.
It
just
gives
it
to
you
in
json
and
then,
if
you
want
to
do
something
with
it,
you
use
jq
like
if
we
have
a
json
version
of
cycle
and
dx
like
maybe
pack
also
doesn't
need
to
understand
that
it's
like
just
pipe
it
to
jq
anyways.
C
I
think
that's
out
of
laziness,
I
don't
think
that's
out
of
that's
the
right
thing
to
do.
Right.
Pax
should
be
like,
especially
once
it's
in
cyclone
and
everything
has
a
ton
of
extra
metadata.
You
don't
care
about
it.
I
think
pax
should
provide
a
really
nice
interface
for
seeing
what's
inside,
of
an
image.
B
Maybe,
but
I
think
it
would
take
a
while
before
we
get
there
and
I'm
not
sure
that
you
know
pack
is
going
to
do
a
better
job
at
pulling
arbitrary
things
of
interest
out
of
a
json
file.
Then
jq
is
like
oh
the
set
of
things
you
could
possibly
want
to
implement.
There
is
vast
a
baby
like
you
know.
We
want
to
be
a
small,
sharp
tool
and
instead
cyclone
dx
is
going
to
make
a
great
gui
or
cli
tool
for
exploring
cyclone
dx
and
we
just
hand
it
over
to
that.
C
B
B
B
C
Can
accept
both,
I
don't
know
if
we
want
to
create.
I
think
we
should
create
another
api
version.
It
seems
like
it's
a
lot.
B
C
B
C
B
B
A
B
Things
that
we
already
have
to
treat
like
1-0
like
the
distribution
api
like
we
can,
we
can
change
some
labels
probably,
but
we
cannot
change
the
locations
of
those
files
and
expect
everything
to
be
fine.
C
B
B
C
B
C
I
can
I
can
do
this.
I
think
it
may
take
a
little
bit
of
time,
but
I
can
get
it
broken
down.
Just
two
just
run
images
and
then
this
one
separate
from
that
and
then
add
some
details
to
it.
If
you
want
to
commit
suggestions
to
things
just
in
the
github
interface,
you
can
pick
buttons
for,
for
where
you
you
know
breaking.
B
C
Reviews
be
better
if
people
did
more
proposing
changes
and
less,
but
it's
hard,
because
the
signed
off
thing
makes
it
a
copy
paste
like
off,
and
everything.