►
From YouTube: CNB Sub-Team Sync: Implementation: 2022-02-02
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
A
Let's
get
started,
though
I
can
run
this
thing.
I
haven't
done
that
in
a
while.
First
up,
everyone
please
sign
into
the
document.
A
And
while
folks
are
doing
that,
maybe
we
can
go
through
status
updates,
kick
us
off
jesse.
B
Sure,
let's
see
the
only
thing
I
really
have
outstanding
right
now
for
this
team
is
I've
got
a
pr
outstanding
to
the
proof
of
concept,
pr
that
does
the
kanako
style,
docker
files
stuff?
B
And
so
I
think
someone
said
they
were
going
to
give
that
a
look
today.
So
I'm
hoping
to
get
that
merged
in
it's
kind
of
our
our
very
rough
pse
end
and
extending
build,
extending
run
and
kind
of
pushing
it
all
together
and
have
been
checking
that
it
did
what
we
think
it
did.
So
I
have
to
get
that
pushed
in,
so
we
can
continue
iterating
and.
B
Yeah
as
long
as
you
set
up
a
registry,
it
just
works
like
it's
just
sort
of
assuming
there's
a
registry
to
push
and
pull
the
bits
that
happen
during
the
kind
of
code
like
to
like
put
it
on
to
deal
with
like
registry.
It
needs
to
be
an
unauthorized
registry
and
stuff
like
that
right.
But
it's
it's
good
enough
and
there's
a
test
script
in
that
branch
to
to
run
through
that.
That
does
all
the
docker
steps
cool
so.
D
Yes,
I'm
almost
I'm
almost
done
I
I
maybe
we
can
check
a
little
bit
the
rfc
I've
been
working
on
saddened
or
something
yeah.
That's
that's
my
update.
A
B
Yeah
yeah
before
natalie
left
she
did
leave
a
like.
We
could
get
an
r4014
rc
out,
but
I
have
not
had
the
the
time
or
means
to
do
that.
Yet
there's
a
couple
blockers
as
well
as
well
for
that.
B
We
probably
should
at
least
call
out
the
spec
prs
when
we
get
to
that
section.
If
that's
the
section
in
this
meeting,
I
think
it
is
just
to
make
sure
that
at
least
folks
on
this
team
have
given
their
their
thoughts
on.
B
Yeah,
I'm
not
either
we
haven't
talked
about
this
in
a
while.
So
I
kind
of
wonder
if
this
is
yeah,
I
don't
know,
I'm
not
sure
when
the
these
okay,
it
was,
it
was
adam
on
december.
13Th
looks
like
natalie
is
the
only
one
who
has
any
context
here.
It
looks
like
there's
a
workaround
as
well,
so
I
think
we
can
push
this
and
see
what
natalie
had
in
mind
next
time.
She's
around.
A
Good,
well,
that's
it
for
needs
discussion.
So
let's
move
on
to
rc's
here.
A
B
C
I
don't
know
emily
if,
if
I
brought
this
up
in
the
past
or
if
we
came
to
a
conclusion,
but
I
do
recall
that
some
of
these
rfcs
have
this
idea
that
we
want
to
more
or
less
wait
until
you
know
certain
parts
are
done.
I
think
the
the
daemon
being
ejected
is
is
one
of
those
things.
C
C
It
doesn't
necessarily
make
sense,
because
pack,
for
instance,
would
still
need
to
find
a
way
to
solve
this
once
the
life
cycle
stops
using
the
daemon.
So
it's
just
really
kind
of
reallocating
the.
C
A
I
think
I
was
the
one
pushing
really
hard
for
which
do
the
demon
stuff
first,
even
before
approving
these
rfcs.
After
hearing
everyone's
arguments
that
work
in
group
last
week,
I
think
I've
come
around
to
the
other
side
where
we
could.
You
know
maybe
approve
these
rfcs
first,
but
I
do
want
to
prioritize
implementing
the
demon
change.
A
Especially
because,
right
now
like
we
have
a
couple,
maybe
like
one
or
two
issues
but
like
image,
references
and
labels,
where
you
know
behavior,
is
different
between
the
registry
and
the
demon.
But
as
we
approve
these
things,
those
two
cases
will
diverge
more
and
more
in
ways
that
I'm
uncomfortable
with
and
also
getting
rid
of,
the
demons.
Something
we've
wanted
to
do
for
a
long
time.
A
So
I'm
I
don't
want
to
just
live
with
the
demon
problem
forever.
We've
been
talking
about
it
for
a
long
time
and
I
think
I'd
like
to
move
forward
on
it.
But
if
no
one
thinks
that
blocking
these
rfcs
is
the
right
way
to
do
that
or
the
right
time
to
do
that.
I'm
okay,
but
I
want
to
figure
out
how
we
can
move
forward
on
it.
C
Yeah,
I
mean
I'm
definitely
all
for
extracting
the
daemon
case
and
I'm
with
you
on.
I
think
that
that
seems
like
high
priority
execution
seems
a
little
bit
difficult
right
too,
to
rally
the
troops
around
the
daemon
extraction
when
there's
higher
bigger
items
at
play
at
the
moment,
but
like
the
oci,
you
know
recommended
annotations.
C
That
seems
like
very
low
hanging
fruit
that
I
I
do
wonder
whether
prioritizing
that,
after
the
daemon
extraction,
is
useful
right
so,
like
I
feel
like
we
could
do
the
oci
annotations
fairly
quickly
and
and
just
say,
you
know,
dimming
here
or
not-
it's
almost
irrelevant.
I
guess.
A
The
reason
these
things
feel
coupled
to
me
is
that
this
current
proposal
is
recommending
that
the
life
cycle
add
these
recommended
annotations,
but
I
actually
don't
think
that
the
life
cycle
should
be
making
those
kind
of
specific
decisions.
Instead,
I
think
we
should
augment
the
build
pack
api
such
that
a
build
pack
can
add
an
annotation
to
an
image,
and
then
you
know
you
can
have
a
build
pack
that
adds
all
these
recommended
ones.
C
A
C
A
In
my
mind,
like
I
know
that
you
know
we're,
gonna
have
some
sort
of
pack
load
situation.
So
eventually,
even
we
get
rid
of
the
demon.
You
know
we're
gonna
put
it
on
the
file
system
and
then
we'll
load
it
into
the
daemon
and
the
version
that
gets
loaded
into
the
demon
still
will
not
have
those
energy
exactly.
A
A
B
I
would
agree
with
that,
that's
kind
of
how
I
feel
about
it
like.
I
think
we
should
prioritize
it.
I
don't
know
from
just
a
philosophical
standpoint.
I
don't
know
whether
we
should
block
rfcs
on
things
that
we
are
mostly
technical
debt,
but
I
don't,
but
I
think
they're
two
different
streams
of
work.
B
You
know
the
product
work
and
as
long
as
rfcs
are
about
the
product,
I
think
that's
fine
and
like
we
dictate
our
own
schedule,
and
so
I
think
it's
fine
to
to
push
things
based
on
tech
debt,
but
I
don't
know
that
it
has
to
block
the
approval
of
the
rfc,
just
the
implementation
of
it
and
how
we
implement
it.
That's
kind
of
how,
where
I
stand
on
it.
A
Because
we
never
clean
up
any
of
this
stuff,
we're
going
to
get
to
a
point
where
it's
impossible
to
make
progress.
Even
simple
things
like
this
are
hard
because
of
the
fact
that
we
haven't
removed
the
demon
already
like
you
know,
I've
run
into
a
lot
of
compromises
really
quickly.
It's
like
we
have
this
image
interface,
an
image
util.
Are
you
gonna?
Add
things
to
it
like
set
annotation
that
just
don't
work
in
the
demon
case,
like
you're
gonna
quickly
get
into
a
situation.
C
A
Although
I
do
want
to
come
back
and
make
this
I'd
like
to
encourage
sam
to
make
this
a
proposal,
that's
about
field
tax
setting
annotations,
not
about
specific,
recommended
annotations.
C
A
I
guess
one
of
the
other
things
I
want
to
talk
about
sort
of
a
team.
That's
gone
through
a
lot
of
our
rfc
conversations
lately,
which
is
about
whether
or
not
we're
gonna
continue
making
breaking
changes
to
apis
like
build
pack
api.
A
A
For
me,
I'm
trouble
totally
buying
into
that
argument,
because
if
you
don't
want
to
make
changes,
I
don't
see
why
you
want
to
update
the
api
anyways
right.
It's
like
I
can
change
this
number
in
my
bill
pack
tumble
file
and
not
change
anything
else
and
it
still
works.
But
why
did
I
even
bother
changing
that
number
like
what
have
I
accomplished,
but
I
guess
you
know
when
we
tie
it
to
new
features.
D
B
I'm
okay
with
the
making
these
sort
of
breaking
changes.
Personally,
like
I
think
it's
healthy
for
the
project
to
to
be
able
to
do
that
and
and
practice
it
doing
that
for
one
thing
as
well
like.
If
we
don't
ever
make
any
breaking
changes,
then
it
will
be
especially
hard
when
we
decide
that
we
really
want
one,
and
I
think
that
if
api
versions
aren't
there
to
allow
us
to
make
that
flexibility,
I
don't
really
you
know-
I
don't
know,
I
don't
get
it.
C
D
C
C
A
Because
you
know,
if
like
in
order
to
implement
something
like
applying
docker
files,
we
need
to
like
reorder
the
phases
and
then,
like
you,
know,
there's
not
a
lot.
You
can
do
about
that
right
and
especially
like
a
lot
of
the
new
big
features
that
people
want
are
going
to
require.
Platforms
to
you
know,
read
and
implement
carefully,
but
luckily
I
think
there
are.
There
are
fewer
platforms
right
and
they,
for
the
most
part,
are
motivated
to
provide
these
features
in
a
way
that
might
be
different
from
a
large
group
of
bill.
C
I
don't
know
that
I
would
completely
agree
with
that
argument,
because
if
I
look
at
things
like
get
lab,
auto
ops,
I'm
not
sure
that
they've
touched
it
since
they
first
implemented
it,
which
means
that
they're,
probably
in
a
much
older
platform,
api
right.
So
once
we
say
like
hey,
we're,
gonna
have
these
builders,
and
these
builders
now
have
these
docker
files
that
they
execute,
and
you
know
all
these
changes.
Those
builders
are
no
longer
compatible.
A
I
think
the
whole
class
of
platforms
that
we
sort
of
talked
about
as
different
platforms
that
I'll
use
pac.
I
really
just
one
platform
which
is
pack
right
and
like
pack
in
a
bunch
of
different
contexts,
because
they're
not
actually
using
the
platform
api
right,
they're
using
pax
api,
which
makes
it
sort
of
a
different
question
of
evolution
and
breaking
changes.
B
Yeah,
I
think
the
motivation
is
there
for
a
platform
reflect
platforms
to
do
those
changes
like
this
phase
swapping
like
and
they
can
make
that
decision
on
their
own.
You
know
for
the
features
they
want
like
we
haven't.
I
don't
think
one
of
our
platforms.
We
haven't
done
the
latest
ones
that
do
some
of
the
s
bomb
stuff,
because
now
the
buildbacks
that
we're
currently
using
don't
don't
really
mess
with
s-bomb.
B
D
B
A
I
think
part
of
the
reason
I'm
probing
at
it
right
now
is
because
there's
some
rfcs
here
that
are
largely
or
to
some
extent,
cosmetic
right.
It's
like
I'd
like
to
make
the
file
structure
look
better.
We
would
like
to
you
know,
like
have
environment
variables
instead
of
positional
arguments
stuff
like
that,
and
how
much
I
want
to
do.
Those
at
all
depends
on
whether
we
can
ever
get
rid
of
the
old
stuff
it's
like.
A
C
In
one
of
the
conversations
we
had
about,
you
know
what
1.0
would
look
like
and
maybe
a
2.0
right
like
future
thinking,
type
stuff.
Terence
brought
up.
The
idea
of
you
know,
imagine
a
world
where
1.0
right,
you
have
1.0,
then
1.1,
1.2,
so
forth,
and
in
each
one
of
those
you
know
sort
of
you
know
iterative.
What
is
it
minor
releases?
You
would
be
adding
features
right.
C
It
would
be
additive
features
in
a
sense,
but
it
would
be
like
in
a
non-breaking
format
and
then,
once
you
get
to
the
next
major
version,
then
that
becomes
the
purge
right.
So
then,
at
that
point
you
drop
everything.
So
I
wonder
if
you
know
again,
I
argue
we're
already
at
1.0,
but
you
know
if
we
envision,
you
know
zero
dot,
whatever
right
we're,
making
all
these
changes.
A
A
But
we
decided
to
sort
of
treat
each
of
these
miners
like
that,
because
we
had
enough
cases
where
we
were
breaking
things.
So
maybe
what
you're
saying
is
we
should
go
to
1-0
now,
like,
I
think,
that's
almost
the
same
argument
which
is
like
if
we
now
want
to
move,
but
if
we
want
to
stop
breaking
things
which
we
have
been
doing,
we
have
been
bringing.
If
we
want
to
stop
breaking
things,
I
think
we
would
start
calling
that
1-0,
rather
than
treating
the
oh
whatever's
differently.
C
I
think
a
lot
of
it
has
to
do
in
my
mind.
I
agree
with
everything
there.
It's
just
I
don't
know
if
we
could
feasibly
do
it
for
removing
stacks
yeah
right
when
we
remove
stacks.
That
seems
such
a
big
like
such
a
big
change
that
I'm
not
sure
how
we
would
have
a
backwards
compatible.
B
B
C
The
the
scary
part
for
me
is
because
it
hasn't
been
tried
right,
like
we,
don't
know
what
what
negative
impacts,
removing
the
builder
or
sorry
the
stocks
may
have
in
in
a
practical
application
like
we
might
need
quick,
additional
changes.
So
that's
really
scary
part
right
is
to
go
like
to
1.0
and
then
all
of
a
sudden
realize
like
holy
crap.
This
doesn't
work
the
way
that
we
wanted
to
1.1
right,
never
use
1.0.
A
C
The
scary
part
with
that
is
whether
people
would
platforms
specifically
have
the
incentive
to
do
so
right,
and
I
guess
that
that
number
might
be
a
smaller
set
of
platforms
that
don't
use
pac,
but
like
k,
pack
and
pack
at
minimum
would
all
have
to
go
through
major
changes.
If
we're
not
going
to
provide
any
sort
of
compatibility.
A
C
B
But
that's
because
I
think
we
kind
of
have
to
lead
the
way
with
pack.
Almost
like
the
pack
create
builder
is
gonna,
probably
be
responsible
in
my
mind
for
like
creating
some
of
these,
like
whatever
life
cycle
needs
to
do
the
job
of
like
old,
stack,
new
stack
or
old
stack,
and
now
now
no
stack
potentially
right.
B
B
Get
all
the
like,
distro
and
stuff,
or
at
least
a
tattoo
right.
C
I
wonder
what
a
good
strategy
for
that
would
be
like.
Is
it
design
first
like
think
through
how
to
best
do
it,
or
is
it
like
a
poc
style,
where
it's
like?
Okay,
I'm
going
to
create
a
pack
that
creates
these
no
stack
builders
and
then
be
like
okay.
Now,
how
do
I
make
this
work
with
old
life
cycle
with.
B
I
think
that's
kind
of
what
we
need
really
like.
I
think,
having
a
builder
that
has
been
refreshed.
That
has
so.
We
can
start
figuring
out
what
we
actually
need
on
that
builder
to
make
it
work
and
how
life
cycle
needs
to
see
those
those
builders
and
so
that
it
can
execute
those
build
packs
and
lie
to
the
bill.
Packs
of
old
about
the
stack
or
something
yeah.
A
Yeah,
I
guess
it
really
comes
down
to
sort
of
like
what
order
we
think
makes
sense
to
encourage
things
to
move
in
because,
rather
than
starting
with
sort
of
like
a
base
image
that
isn't
a
stack,
I
was
sort
of
imagining
it
going.
The
other
way
where
you
have
a
bunch
of
build
packs
that
express
requirements
in
terms
of
these
first
level
concepts
rather
than
stacks
right
like
I
need
a
linux,
I
need
a
whatever.
A
B
B
C
B
But
maybe
that's
a
thing
we
need
to
do
sooner
than
later
is
have
pac,
create
builder
start,
adding
those
labels
even
to
folks
who
haven't
added
it
to
their
docker
file.
For
the
builder
right,
like
you
know,
I
don't
know
if
it
needs
to
be
behind
a
flag
or
anything
at
first
or
whatever
experimental,
but,
like
you
know,
force
force
having
those
those
labels
on
there
or
whatever.
We
need
to
to
start
making
sure
that
platforms
are
producing
builders
that
can
work
in
a
newer
world.
C
I
I
guess
the
the
challenge
I
have
is
thinking
through
this
is
pack
is
going
to
change
the
way
that
a
builder
is
created.
Where
there's
no
mention
of
a
stack
right
like
there's,
no
stack
id,
there's,
no
nothing.
How
does
it
come
up
with
those
terms
or
or
those
legacy
labels.
A
D
C
A
A
So
I
think
you
should
be
able
to
create
a
builder
from
stack
images
that
aren't
annotated
with
a
bunch
of
backwards
compatible
metadata.
But
I
think
if
you
do
you
get
a
warning,
that's
like
by
the
way
you
might
fake
out
some
build
banks.
A
A
B
A
B
C
A
B
B
B
Yeah,
I
think,
in
the
next
two
weeks.
I
would
be
happy
if
we
got
the
o14
out
out
in
alignment
on
those
two
spec
things,
and
then
it
would
be
really
good
to
start
having
some
serious
conversations
about
getting
rid
of
the
demon
figuring
out.
What
that,
how
we
approach
that
as
a
as
a
team
and
start
doing
the
hard
work.
A
I
know
juan
you're
working
on
an
rfc,
for
that
right
is
that
linked
in
the
rfc
repo,
or
is
that,
like
a
heck
md
at
the
moment,
I'd
love
to
read
through
that
as
well.
D
Yeah
it
it's,
let
me
paste
it
here,
it's
unhappy
yet,
but
I
think
I'm
going
to
moves
it
to
the
repo.
Just
let
me
go
through
it,
so
you
can
see
it
and
then
you
can
read
it
when
you
have
some
time
and
maybe
left
some
stuff
there.
Okay.
D
Okay,
so
I
did
some
changes
to
this
image
based
on
natalie
feedback.
She
wanted
me
to
remove
some
actors
and
components
that
are
not
worried
about
this
part,
yet
so
at
the
end,
so
we
would
just
want
to
remove
this
interaction
between
the
life
cycle
and
the
demand.
That's
part
of
the
motivation.
D
And
in
a
high
level,
then
the
solution
is
to
move
responsibility
to
the
platform
and
then
remove
the
connection
we
did
before.
So
that's
the
high
level
idea
anything
behind
that
one.
If
that
idea
is
not
the
one
we
want,
so
that's
a
good
place
to
left
a
comment
so
the
way
it
works.
I
divided
into
sections
first
from
platform
perspective,
which
we
are
moving
some
responsibilities
to
this
component.
D
D
Okay
yeah,
so
I
did
it
with
simulating
like
some,
like
some
platform
will
use
a
tool
similar
to
scorpio
or
what
copied
it's
doing
right.
D
So,
for
example,
in
this
case
it
is
interacting
with
the
daemon
to
download
in
oci
format
this
alpine
image
right
and
then,
when
this
image
is
saved,
it
will
look
like
the
oci
layout
format
right
so
and
at
the
end,
when
the
live
cycle
finished
its
job,
it
will
provide
a
platform
with
the
image
created
during
the
build
in
the
same
format,
with
the
oci
layout
specification
right
and
then
the
platform
needs
to
push
that
iman
into
the
demon,
because
that's
what
the
user
is
expecting.
D
D
That's
what
we
are
proposing
right,
that
it
takes
that
it
should
be
taking
care
of
interacting
with
the
demon
to
pull
or
to
push
the
images
and
also
maybe
against
the
it
could
be
against
a
registry.
D
So,
for
example,
if
I'm
trying
to
download
this
alpine
image
from
a
registry,
then
it
can
do
the
same
thing
and
put
the
image
for
the
life
cycle
in
in
that
format.
Okay,
then,.
D
A
I
definitely
see
the
point
of
loading
it
back
into
the
demon
for
people,
like
that's
a
nice
thing
for
peck
to
do.
But
why
would
we
want
to
take
images
out
of
the
demon
sort
of
like,
in
this
case
we're
talking
about?
Turning
like
the
run
image
into
an
oci
layout,
to
pass
it
to
the
live
cycle?
C
So
this
seems
like
a
pac-specific
conversation
right.
I
think
the
oci
layout
piece
is
within
the
the
realm
of
the
life
cycle
platform
kind
of
conversation.
C
I
think
that
could
be
a
separate
conversation
so,
like
I
guess,
if
we
want
to
talk
about
pac,
we
can
do
that
right
like
of
what
makes
sense
there
or
we
could
talk
about
some
of
that
and
how
that
may
influence
the
life
cycle
platform
api
because
I
have
thought
through,
but
I
thought
it,
I'm
not
sure
that
I
want
to
increase
the
scope
to
this,
but
right
now
on
the
oci
part,
we're
basically
saying
everything
is
layout
right.
So
if
you
pass
a
layout
path,
everything
is
layout
everything's
on
the
file
system.
C
You
pull
from
that
layout.
You
add
to
that
layout.
Yes,
the
mix
part
is,
is
the
part
that
becomes
adds
complexity
to
the
life
cycle.
I.
D
C
D
C
C
D
D
If
I
do
not
have
the
run
image,
then
I
go
to
the
registry
and
download
it
from
there,
but
I
don't
know
if,
if
that's
what
we
want
in
the
final
behavior
right,
I
I
think
the
best
is
avoid
the
having
things
mix
it.
Even
that
could
make
the
life
easier
right
to
the
platform,
because
platform
can't
worry
just
about
maybe
the
previous
image
and
that's
it.
A
Porn,
I
feel
like
we
could,
with
you
know,
good
abstractions
and
image
util
like
actually
just
make
everything
totally
work,
and
it
just
downloads
things
when
it
needs
them
to
turn
into
layouts
like
you
can
make
it
pretty
easy
to
plug
and
play
any
of
these
things
into
each
other
and
from
a
ux
perspective
as
a
user.
I
would
expect
any
of
that
to
work,
but
the
performance
is
going
to
be
really
bad
if
you
are
taking
in
some
of
these
cases
right.
B
Yeah
and
also
the
docker
files
makes
this
maybe
impossible
with
oca
layout
without
knowing
like
like
because
it's
going
to
need
to
pull
like
you,
can
change
the
from
image
right
and
like
do
your
own
from
image
in
like
a
docker
file
in
the
future,
and
so
that's
going
to
be
impossible
to
have
on
the
layout.
Lifecycle
would
have
to
do
that
for
you
from
somewhere.
B
So
I
feel
like
we
won't
fully
be
disconnected
like
lifecycle,
could
still
do
that
and
spit
it
out
onto
oci
layouts
for
the
few
further
stages,
but
we're
going
to
lifestyle
is
going
to
have
to
turn
something
into
oc.
Add
layout
at
some
point
anyway.
So
it
makes
me
kind
of
wonder
if
we
should
just
do
mostly
registry
and
then
oci
layout.
At
the
end,
only
really.
A
B
B
That
work
anyway
right
yeah,
so
pack
would
have
to
turn
your
it
would
have
to
go
fetch
from
docker
hub
to
spit
it
out
to
give
it
to
lifecycle
in
the
first
place,
so
lifecycle
doing
it
doing
that
in
the
exporter.
Phase
only
means
that
you
don't
have
to
do
that
work
until
you're
exporting
at
least
right,
like
you're,
pushing
that
work
off
until
the
very
end,
because
you
don't
need
those
oci
layouts
for
the
base
image
until
until
you're
about
to
write
it
to
oci
layout.
C
The
only
other
downside
to
registry
only
is
for
pack-
and
this
is
maybe
selfish,
but
if
we
only
have
the
damon
right
then,
and
the
image
only
exists
in
the
daemon.
That
means
we
have
to
spin
up
a
registry
and
literally
proxy
everything
through
that
registry
to
then
go
find
it
in
the
daemon.
So
we
have
to
set
up
a
process,
essentially
all
right.
A
C
The
only
additional
complexity
that
I
could
think
of-
and
I've
been
thinking
about
this
for
a
while
already
so
it
might
just
be.
The
good
opportunity
is
the
we
need
to
have
a
way
to
signify
where
the
image
is
located
right
if
it's
oci
or
registry,
and
so
here
comes
in
like
the
uri
schemas
that
we
built
for
pack
right
like
now,
we
could
drive
those
into
the
life
cycle.
I
think
that
would
be
beneficial
overall.
A
Not
to
derail
this,
those
uri,
schemas
they're,
still
the
thing
I
mess
up.
I
still
mess
them
up
all
the
time
when
I'm
trying
to
test
out
my
build
packs,
I'm
always
like
accidentally
getting
build
packs
from
the
bill
pack
registry.
When
I'm
trying
to
use
a
demon
image
and
like
I
cannot
get
those
things
to
work
right.
The
first
try
ever.
B
C
I
think
we
definitely
were
influenced
by
the
the
skopje
ones.
I
think
the
problem
is
the
default
might
be
what
emily
you're
running
into,
but
I
I
do
think
that
there's
there's
value
in
that
right.
If
we
use
the
uri
schemas
more
throughout
the
the
you
know
the
whole
domain,
then
we
could
find
issues
like
that
right,
like
where
it's
clunky
or
it
doesn't
make
sense
and
really
kind
of
iron.
That
piece
out
of
it
as
well.
B
I'm
on
board
with
the
mix
and
match,
but
I
do
think
you
have
to
be
able
to
force
it
one
way
or
the
other,
because
I
think
otherwise
we're
getting
this
weird
situation
where,
like
pack
on
you,
know,
oci
layouts,
your
your
your
run
image,
but
then
we
end
up
pulling
it
for
some
reason
somewhere
else
like
we're
doing
like
run
extensions
and
like
it
doesn't
come
from
the
oci
layout
and
it's
like
whoops
like
we
extended
a
different
image
like
because
you're
going
to
reference
images
with
pac
that
aren't
on
our
registry
anywhere.
B
C
Yeah,
that
is
true
right.
I
think
that's
the
other
added
complexity,
like
the
run
image,
is
baked
into
some
label
at
some
point
right
and
that
doesn't
have
a
schema
right
like
so
that
one
is
intended
to
be
pulled
from
aka
the
single
source
of
truth,
and
if
we
just
have
this
either
your
layout
or
your
registry,
then
there's
no
real
confusion
as
to
where
we
should
be
getting
it
from.
B
Yeah
because
they
would
just
fail
like
we
couldn't
find
the
right
image
they're
like
oh,
I
need
to
pull
the
run
image
like
it's.
It's
a
very
obvious
fix
instead
of
like
oh,
I
pulled
a
run
image
last
time,
but
it's
not
the
one.
I
expect
because
I
was
building
a
custom
one,
but
now
it's
you
know
anyway.
I
see
some
confusion
happening
if
we
don't
make
it.
C
D
Well,
I
okay
for
what
I
understood
was
okay,
maybe
I
can
add
some
section
regarding
these
combinations
of
inputs
and
outputs.
I
tried
to
do
something
similar
in
a
table
here,
but
what
it
is
yeah.
I
don't
know
why
it's
this
thing
is
moving
okay.
I
tried
to
do
that
with
how
the
image
name
provide
by
the
user
and
how
it's
expected
to
life
cycle
to
deal
with
it.
D
C
I
I
would
definitely
suggest
that
we
keep
it
separate
from
the
core
of
what
you
have
here,
so
whether
it
be
like
an
alternative
or
like
an
open
question
section,
but
something
that
basically
says
like
we're
thinking
about
whether
we
should
allow
for
combinations
of
these
two
and
kind
of
dive
into
some
of
the
drawbacks
and
benefits
all
that
kind
of
stuff.
And
what
that
would
look
like.
C
D
C
B
C
And-
and
I
think
juan
one
of
the
initial
diagrams
I
provided
yeah
was
one
of
the
options
and
yes
kind
of
drawbacks
too,
but.