►
From YouTube: CNB Office Hours: 2021-11-18
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).
B
Hey
I
just
wanted
to
follow
up
on
some
conversation.
We
had
a
working
group
earlier
today.
I
just
wanted
to
make
sure
I
had
the
arguments
right
right
because
I
do
have
to
synthesize
it
and
present
to
other
people,
but
the
I
think
what
we're
concerned
with
was
you
know
if
gem
packages
is
gonna,
be
making
a
bomb
in
the
docker
files
rc
right,
we
don't
want
this
thing
or
its
dependencies
to
be
present
in
the
final
application
image.
B
That's
point
one
point
two
is:
how
do
we
get
rebase
working
in
this
scenario?.
A
B
I
guess
I
guess
I'm
concerned
with
what
is
gen
pack
right.
Is
it
sift
like
sift
a
binary
that
could
be
sift
right,
pretty
much
just
sift
package
export
blah
blah
blah.
A
Yeah
I'm
somewhat
unclear
on
this,
but
from
my
interpretation
yeah,
it's
essentially
a
a
script
right
that
allowed
to
execute
whatever
you
need
in
order
to
generate
the
s-bomb.
That
would
then
be
attributed
to
having
additional
information.
Yeah.
B
A
So
this
isn't
something
that
I
thought
about
too
much
about.
I
know
sam
has
so
I
wish
he
was
here,
but
let's
think
about
it
through
step-by-step
process.
So
right
now
the
rebase
is
an
operation
where
all
we're
doing
is
changing
the
a
couple
of
layers
right
and
re-pointing
those
and
creating
a
new
config
from
those
new
layers.
B
A
B
B
No
no
problem,
so
you
take
maybe
the
run
image
right
and
apply
the
it
as
the
base
right
for
your
new
application
image
and.
B
You
know
you'd
have
to
choose
right,
there's
an
old
image
and
there's
a
new
image
bomb,
there's
an
old
image
bomb
and
new
image
bomb
right.
You
would
want
to
take
the
layer.
Oh
you
know,
there's
another
step
now
it
would
just
take
the
layer
of
the
new
image
bomb
and-
and
you
know
put
it
also
with
with
with
your
new
sandwich
right.
B
Where
we
need
to
put
it
somewhere
right,
we
don't
need
it
in
the
basement.
We've
been
saying
this:
we
don't
need
this
in
the
base
image.
We
could
put
it
like.
You
know
the
cosine
solution.
We
put
it
somewhere
else
right,
but
for
for
right
now
putting
it
on
it
and
then
putting
a
label
where
the
layer
is
is
maybe
expedient
right.
A
A
B
B
A
B
B
B
Go
app
because
it
goes
all.
I
know
right.
You
have
a
go
bill
pack
that
installs
go
right.
The
go
bill
pack
is
gonna.
Give
you
an
s-bomb
for
go
right
because
that's
the
thing
it
it
put
on,
maybe
for
you
right
and
did
it
go,
build
maybe
got
some
dependencies
and
go
build
whatever
right
right,
but
if
you're
modifying
the
base
image
and
then
you
put
curl
for
some
reason
right
or
something
right,
maybe
you
use
curl
to
get
your
go
binary.
B
B
B
B
I
don't
know
I
thought
there
must
have
been,
but
now
that
I'm
seeing
this
I'm
gonna
double
down
on
it,
and
I
say
yes,
I'm
gonna
say
yes
right,
because
this
that's
the
only
way
it
can
work
right
after
you
run
the
extensions
you're,
replacing
something
that
that
must
exist
already
right.
I
I
this
is
purely
speculation
here
I
don't
know,
but
I'm
I'm
saying
there
has
to
be
one
already
and
we're
replacing
it.
Otherwise,
it's
just
it's
just.
B
A
B
Well
see
what
I'm
trying
to
do
is
we're
trying
to
proceed
this
with
that
right,
like
we're,
trying
to
say
okay,
whatever
gem
packages
would
make.
This
is
the
initial.
This
is
the
initial
like,
let's
say
before
we
run
any
extensions
right
like
we're
trying
to
say
all
right.
Gem
packages
should
make
something
that
looks
like
this
right.
B
A
B
I
see
okay,
I
don't
know,
I
don't
know
that
right,
but
I
would
think
that
when
the
stack
author
makes
the
run
image,
it's
already,
it's
already
run
by
them
right.
I
don't
know
if
lifecycle
needs
to
run
it
or
anything
like
that
right,
but
it
has
to
be
prev,
it
should
be
predefined.
B
A
Okay,
so
then
the
way
I
see
it
is
that
there's
a
a
baked
in
yes
of
it,
yes,
and
if
they,
so
they
could
that's
one
option
right.
Yes,
the
option
where
you
could
just
bake
it
in
there's
no
gem
packages,
there's
no
hooks,
there's
no,
nothing
right.
A
Yes,
there's
the
option
where
you
could
still
have
those
baked
in
right,
but
you
could
utilize
hooks
and
then,
if
you
have
hooks
you
should,
then
we
should
also
execute
gen
packages.
That's
right!
Yes,
okay,
hooks
gem
packages
and
then,
when
gen
packages
will
do
is
it
would
override
any
pre-existing
baked
in
s-bomb?
Yes,.
A
A
A
Okay,
so
that's
definitely
a
lot
clearer
for
me
now
you
can
see
where
a
lot
of
the
ambiguity
here
is
from
one
paragraph
to
that.
B
A
No,
I
agree:
okay,
okay,
so
now
now
that
I
have
a
better
understanding
stepping
back
right,
the
concern
is
this
gen
packages
being
on
the
final
app
image,
so
gem
packages
and
other
dependencies,
so
is
the
quick
solution.
A
I
was
gonna,
say:
okay,
I'm
just
gonna,
throw
it
out
there.
You
tell
me
how
terrible
of
an
idea
this
says
is
that
you
could
have
your
gen
packages,
but
you
have
to
identify
what
layers
to
exclude
from
the
running
from
the
final
run,
image.
B
Okay,
I'm
not
gonna,
say
that's
terrible
only
because
that
was
the
first
thing
that
came
into
my
head
too
right.
I
couldn't
it's
just
a
lot
of
work
right.
B
That
way,
we
could
exclude
it
right.
We
could
like
exclude
it
when
we
make
the
final
I
I
just
I
just
didn't
think
it
was
clean
at
the
fir
was
the
first
time
it
popped
in
my
head.
I
just
I
just
didn't
want
to
say
it
in
working
group
and
look
like
an
idiot
right,
because
it
didn't
seem
like
a
clean
interface.
There
has
to
be
a
cleaner
way
to
go
about
this
right.
A
C
A
A
A
I
think
that
would
be
good
enough
right,
maybe
so
that
would
be
good
enough
and
then,
when
the
hooks
execute
right.
So
this
is
all
pre-compilation.
A
Or
pre-build
pack
build
if
that
makes
sense,
and
then
during
a
build
pack
build
we
execute
the
docker
files
and
then
we
could
look
at
the
image
and
say:
okay,
these
are
the
layers
that
would
then
be
excluded
from
the
final
app
image.
So
we'd
we
could
do
a
or
yeah
config
manipulation
to
exclude
those.
B
Oh
okay,
I
mean,
I
don't
know
if
it
has
to
happen
in
that
way.
I
mean
honestly.
I
think
it
could
be
up
to
the
exporter
right
like
it
could
be
all
the
way
at
the
export
level
level.
We
just
make
sure
we
add
the
run
image
and
then
exclude
this,
this
right
label
right,
but
yeah
and
that's
in
you
know
I'm
I'm
in
agreeing
with.
In
essence,
what
you're
saying
right.
A
Okay,
hopefully
we
haven't
been
barking
up
the
wrong
tree
and
now
that
sam
is
here,
he
could.
A
C
A
Trying
to
find
a
path
forward
for
yeah
the
the
runtime
s-bomb
stuff
wow,
I
think
in
the
short
term,
to
keep
it
in
parity
with
what's
going
on
for
or
what's
going
out
for
the
other
s
bomb,
the
build
pack
provided
s-bombs
is
to
keep
them
in
the
app
right,
and
so
I
think
you
don't
have
a
a
problem
there.
We
all
look,
I
think
myself
and
you
agree
that
it'd
be
better
to
have
sidecar
but
we'll
cry
about
that
later.
A
A
Require
that
the
gen
pack
related
layers
be
labeled
in
the
run
image
so
that
they
could
be
excluded
after
it
is
executed.
C
C
C
C
So
I
dynamically
switch
that
over
here.
It
just
means
that
the
dynamic
switch
for
that
dynamic.
Switching
each
of
your
run.
Images
must
have
the
gen
packages
binary,
bundled
in
the
way
that
I
bundled
in
some
way
that
it
works,
and
then
it
also
means
that
if
you're,
starting
with
the
let's
say,
you
created
a
run
image
that
was
packaged
with
gen
packages
and
you
add
more
layers
on
it.
C
Like
so
the
point
is
we
don't
want
to
restrict
users
from
the
kind
of
base
images
they
want
to
generate?
Like
that's
the
point
of
this
rfc,
and
then
we
just
need
to
make
sure
whatever
we
do
to
introduce
this
gen
packages
variable
or
like
the
executable
like
allows
users
to
still
dynamically
modify
the
run
image
that
they're
going
to
use
while
still
being
able
to
use
gem
packages
with
it
and
it
not
ending
up
in
the
final
lap
image.
B
Yes,
it
makes
sense,
but
stepping
back
right
like
there's
a
couple
options
right:
either
they
run
it
every
time
they
make
the
image
right
or
I
guess
we
run
it
ourselves
right
when
we
do
any
builds.
C
B
B
C
C
I
I
really
didn't
that's
why
I
didn't
include
this
in
my
original
rfc
and
that's
why
I
kept
it
out
of
scope,
because
the
more
I
tried
to
think
about
it,
the
more
I
realize
it's
going
to
be
really
hard
to
include
it
in
the
basement.
It's
like
it
with
the
base
image
and
include
the
output
as
form
in
the
output
image.
If
you
want
to
do
operations
like
replace
very
easily
like
there
are
a
lot
of
constraints
on
how
that
file
is
present
and
where
that
file
is
present.
C
In
order
for
us
to
do
a
quick
rebase,
all
of
those
problems
go
away.
If
you
just
have
your
like
it's
from
elsewhere,
you
can
is.
C
Hey
every
all
the
layers
after
this
are
just
for
general,
I
mean
a
lot
of
this
goes
away
if
the
life
cycle
comes
or
like
whatever
your
builder
is
comes
with
the
gen
packages
and
which
is
standalone
and
if
you're
doing
a
kaneko
style
build
like
where
you're
placing
the
contents
entirely
and
your
orchestration
binary
lives
in
a
separate,
independent
folder.
Gen
packages
could
live
in
that
separate,
independent
folder
still
run
on
their
own
image,
create
a
dynamic
run,
image
attach
and
respond
to
it
and
ship.
C
A
C
And
you
put
the
life
cycle
in
cnb
lifecycle,
whatever
I'm
saying
that
if
the
gen
packages
stuff
could
also
be
put
in
a
special
part
such
that
it
doesn't
interfere
with
where
you're
or
how
you're
generating
the
dynamic
rom
images,
then,
however,
we
are
running
life
cycle.
We
could
run
jet
packages
the
same
way.
B
C
B
C
B
C
I
mean,
and-
and
there
are
lots
of
open
source
tools
that
will
currently
fit
this
criteria
like
the
sift
binary.
That's
a
standalone
go
binary
that
you
can
just
put
that
will
work,
yes,
so
like
something
that
simply
wraps
it
up
or
some
way
if
you
can
conform
to
whatever
sets
flags
are
so
like.
If
we
can
say
here's
the
binary
and
I
can
decide
the
flags
or
indicate
the
flags
that
should
be
passed
to
it
in
some
way.
C
That
will
make
things
easier.
So,
like
you
can
you
can
just
take
the
shift
binary
it
outputs,
e2x,
it
outputs
spdx,
it
outputs
this.
If
json
and
that's
your
gen
packages
minor,
we
don't
even
have
to
provide
it.
We
just
said
the
constraints
that
hey
it's
a
standalone
binary.
A
Could
we
create
that
sort
of
separation
and
say
like?
Is
this
good
to
move
forward
with
and
really
just
kind
of
put
the
brakes
on
this
rfc
and
say?
Let's
because
I
mean
one,
paragraph
does
not
do
this
justice
anthony-
and
I
were
talking
about
this
like
it-
doesn't-
give
us
enough
clarity
of
exactly
how
it
works,
what
you
know
when
it
works
and
and
so
forth.
So
I
think
we
could
definitely
elaborate
on
that,
but
I
guess
my
the
the
best
question
I
can
come
up
with
is:
should
it
really
block
this
rfc.
C
C
The
the
reason
I'm
so
skeptical
around
all
of
this
is
that
you've
seen
how
quickly
this
whole
landscape
is
changing
right
and
like
even
with
the
buildback
specific
one.
We
spent
a
lot
of
time
time
trying
to
make
it
generic
so
that
we
could
switch
out
formats,
keep
it
decoupled
from
our
api
as
much
as
possible.
C
Just
hoping
that,
like,
whenever,
whatever
we
introduce
for
the
base
image
like
still
allows
us
to
adapt
to
that
format
and
like
any
new
formats,
whether
it's
storing
s,
forms
creating
s
bombs,
the
format
they're
created
and
still
allows
rebase.
I
I
know
it's
not
a
part
of
this
rfc,
but
it
should
at
least
not
introduce
any
changes
that
would
prevent
us
from
releasing
things
easily
in
the
future.
If
we
wanted
to.
A
A
C
C
B
Other
point,
sorry,
you
know
there's
the
other
point
stephen
had
about
the
name
of
the
file
right.
He
didn't
want
to
run
or
building
it.
He
wanted
the
digest
or
whatever
he
wanted,
the
digest
of
it
just
so
it
wouldn't
collide
in
case
you
wanted
to
build
one
in
it.
Do
you
care
about
that.
C
B
C
B
A
C
There
are
two
or
three
of
them:
yeah,
there's
many
more
all
right
yeah,
I
mean
most
of
them
just
use
pack
in
this
case
it's
it's
just
a
matter
of
dating
back
the
rest,
and
I'm
talking
about
things
that
just
call
out
to
life
cycle
experience-
and
I
mean
back-
has
a
minus
minus
bomb
come
on
that
just
outputs
the
bomb
that
api
doesn't
have
to
change?
So
that's
a
user-facing
api
apac
has
a
similar
api
management
response,
doesn't
have
to
change.
C
C
I'm
just
saying
that
whatever
changes
we
make
here
should
follow
a
similar
ideology
like
we
should
really
not
be
introducing
changes
because,
like
it's
an
emergency
and
then
it
hurts
us
in
the
future
when
we're
trying
to
preserve
backwards,
compatibility
for
all
of
these
versions
and
then
something
new
has
come
about
and
buildbacks
can
can't
get
on
to
it
because,
like
we're
too
invested
in
our
older
apis,
like
that's,
that
was
a
huge
issue
with
this
bomb
rfc
in
the
first
place,
like
we
were
so
invested
in
this
bomb
table
format
that,
like
trying
to
come
up
with
a
new
way
of
specifying
bombs,
while
still
preserving
compatibility
for
the
old
one.
B
Sorry,
when
you're
saying
cosine
will
break
things
for
will
be
transparent
to
end
users.
Like
are
we
talking
about
scanning
tools?
I
mean.
C
I'm
talking
about
scanning
tools
or
tools
that
want
to
get
nsform
from
the
image
so
like
even
in
terms
of
scanning
tools.
C
I'm
assuming
that,
like
I,
I
actually
had
a
few
ideas
in
terms
of
scanning
tools
like
for
things.
Like
dawn
and
gripe.
I
was
like
actually
like
at
the
end
of
the
day.
C
Not
everything
is
going
to
be
built
with
built.
Backsplit,
there's
always
going
to
be
some
generic
image
scanner
that
people
will
have
to
put
in
unless
they
get
to
a
point
where
everything
is
built
by
buildbacks
and
what
I
was
imagining
is,
if,
once
we
decide
on
this
format,
if
we
could
augment
all
these
scanners
so
that
if
an
image
is
built
by
build
packs,
your
output
s1
is
generated
much
more
accurately
and
quickly
than
it
would
be.
C
If
it
wasn't
so,
you
still
get
the
same
interface
so
like
if
you're
on
sift
run
or
whatever,
with
a
buildback
image.
I
don't
know
if
they
would
be
like
they.
C
C
Okay,
that's
that
I
mean
that's
just
my
line
of
thought
like
I.
I
know
how
important
it
is
to
have
this
so
that
you
have
a
complete
bill
of
materials
for
your
output,
application
image,
I'm
not
trying
to
block
anyone,
I'm
just
like
thinking
what
are
the
consequences
of
including
something
that
just
works
for
one
api
version
and
then
our
newer
features
may
make
it
difficult
to
implement
the
api.
We're
suggesting.
A
A
Next
steps,
you
know,
I
want
to
be
a
little
bit-
I
guess
maybe
overly
optimistic
here,
but
it
sounds
like
we're
in
somewhat
of
an
agreement
that
this
stuff
is
good
right
like
it
can
most
likely
go,
there's
some
reservations
about
it
potentially
breaking
in
the
future
and
to
make
us
feel
more
at
ease.
It
would
be
nice
to
know
exactly
how
this
would
operate
right,
be
able
to
solidify
this
piece
to
minimize
that
risk
of
having
to
change
it
yet
again.
On
the
next
point
version.
C
I
mean,
as
long
as
we
can
come
up
with
a
way
to
solve
this,
I'm
completely
fine
with
the
other
one
going
through
like
that.
That
rfc
makes
sense
to
me,
like
I'm
fine,
and
I
accept
that
we
might
have
to
do
a
multi-step
thing
to
attach
the
s
bomb
that
will
also
be
future
compatible.
So
if
you
do
move
to
like
a
cosine
thing
with
back
attaches
bomb
could
just
create
the
attached
as
form
on
the
registry
instead
of
creating
a
new
image
and
putting
it
on
there
also
forward
thinking
this
thing.
A
Thing
this
hideous
thing
all
right,
yeah,
I
think
that's
something
that
we
can
work
on.
I
know
is
steven
out
for
a
while.
He
said
what's
happening.
A
Yeah
yeah,
I
I
do
wonder,
maybe
anthony
you
and
I
could
sit
down
and
expand
on
this
gen
pax
thing
and
try
to
remedy
some
of
those
concerns.
To
say,
like
this
proposed
solution
would
work.
We
could
even
explore
additional
solutions
or
options
and
kind
of
prove
out
that
at
least
those
would
work
in
the
confines
of
the
other
rfc.
A
So
we
have
a
little
bit
of
time
left.
I
didn't
want
to
go
too
much
into
like
a
side
quest,
but
what
what
was
the
turning
point
in
which
we
decided
to
say
no
to
something
like
the
attached
artifacts
or
the
associated
artifacts
versus
embedded.
C
It's
like
it's,
we
didn't
say
no,
it's
that
the
order
of
operations
didn't
match
up
with
not
introduced,
but
I
wrote
that
rsa
originally
cosine
was
not,
as
popular
things
had
not
adopted
it
and
in
the
three
months
period
or
the
four
month,
video
that
I've
seen
once
it
was,
and
at
that
point
it
was
sort
of
late
and
we
wanted
to
ship
those
with
those
things
out,
because
it
was
like
high
time
we
supported
all
of
these
things.
A
A
A
Do
you
wanna,
I
guess
take
point
on
that.
I
think
you're,
a
cosign
expert
at
this
point.
C
Oh
try
to
get
something:
oh
it's
just
like
my
last
few
weeks
of
being
like
running
from
one
week
to
another,
trying
to
get
things
under
control
with
you.
A
I
know
the
holidays
are
coming
up
for
us.
What
about
you
all
over
there
for.
A
There
you
go
we'll
teeter
that
way,
yeah
all
right!
Well,
I
don't
want
to
hold
you
all
up
I'll
give
you
eight
minutes
left
sound
good,
yeah.