►
From YouTube: CNB Office Hours: 2022-01-13
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
I
guess
we'll
I'll
go
ahead
and
get
us
started
with
the
platform.
Config
part
of
the
project.
Descriptor.
A
All
right
there
you
go
so
basically
this
is
a
pre-draft
rfc
that
I'm
working
on,
based
on
a
lot
of
really
good
feedback
and
input
from
various
parties
on
how
we
could
essentially
improve
the
build
packs,
use
case
and
usage
of
the
platform.
Sorry,
the
project,
descriptor
right.
A
So
through
a
lot
of
conversations,
I
think
we
we
distilled
it
down
to
three
goals.
We
want
to
be
able
to
serialize
the
cli
configuration
so
in
cases
like,
let's
say,
pac
right,
you
want
to
have
all
these
flags.
I
would
kind
of
store
the
configuration
that
you
would
other
you
wise
uses
flags
for
pack
to
be
able
to
configure
pack
and
then
be
able
to
check
this
into
a
repository
and
have
everybody
on
your
team.
A
You
know,
or
anybody
that
checks
out
the
repo
be
able
to
build
an
oca
image
using
build
packs
in
the
same
way
if
they
were
to
use
both
or
sorry
pack
cli.
B
B
A
When
you're
talking
about
global
configuration
or
are
we
talking
about
the
global
configuration
at
the
pac?
Yes,
this
rfc
doesn't
go
into
that
sort
of
detail.
It
kind
of
chucks
it
away
as
a
sort
of
pac-specific
implementation
right.
This
is
talking
more
or
less
about.
A
We
have
this
thing
now
this
additional
file
right
and
how
do
we
merge
essentially
or
utilize
project
descriptor
with
this
other
pac
tumble
file?
I
do
I
further
down
here.
I
do
kind
of
punt
the
the
specifics
of
pat
tummle
off
to
its
own
rfc,
which
I
think
joe
is
is
kind
of
leading
on
that
one.
So
I
think
that's
a
really
good
question
for
for
that.
If
this
all
still
makes
sense
right,
does
that
answer
your
question.
A
Yes,
like
other
platforms,
essentially
right
now,
you
could
think
about
kpak
having
its
own
configuration
file.
Tecton
salesforce.
You
know,
I
believe,
functions
that
sort
of
stuff.
A
So
the
second
goal
was
making
a
file
that
is
recognizable
in
these
repositories
right
so
kind
of
leaning
a
little
bit
more
into
we're
configuring
pack
through
some
sort
of
configuration
file.
I
know
from
a
a
branding
standpoint.
We
want
to
have
very
similar
kind
of
picture
that
docker
files
have
in
repositories.
Right.
You
go
to
a
repository.
You
see
a
docker
file.
You
know
that
it's
using
docker
or
you
can
use
docker
to
build
that
application.
A
We
want
to
do
the
same
thing
here,
but
for
build
packs.
You
go
into
repository,
you
see
a
you
know,
pac
tumble.
You
know
that
you
can
use
pac
to
build
that
application
again
x,
number
of
platforms.
You
can
kind
of
say
the
same
thing,
so
we
want
to
enable
platforms
to
be
able
to
promote
themselves
as
a
way
to
to
use
their
configuration
file
names.
If
that
makes
sense.
A
Yeah,
please
feel
free
to
interrupt
me
as
I
go
through
this,
but
I
know
it's
kind
of
lengthy,
so
I'll
just
kind
of
go
through
the
next
one.
Is
you
know,
kind
of
tied
into
that?
To
some
extent
is
we
have
this
project
descriptor
file
called
project
tamil
and
one
of
the
current
challenges
that
I'm
noticing
is
that
some
users
kind
of
expect
this
file
to
be
adhered
to
or
or
recognized
by
other
various
platforms
right.
A
Descriptor
within
the
I
o
build
packs,
namespace
to
be
applied,
and
so
they're
surprised
when
you
know
something,
unlike
k-pack,
it's
ignoring
environment
variables
or
not
being
able
to
set
build
packs,
and
then
you
can
kind
of
see
that
sort
of
trending
in
in
the
alarm,
as
as
you
go
into
other
platforms
and
something
that
works
on
now,
my
machine
isn't
necessarily
reproducible
on
a
platform
or
some
other
machine,
that's
kind
of
more
or
less
the
idea,
and
so
that's
the
the
thing
I
care
the
most
about,
and
this
is
just
kind
of
tying
and
building
on
top
of
other
people's
work,
to
kind
of
create
this
holistic
view
of
something
that
we
could
achieve
all
right.
A
So
with
with
these
three
goals
in
mind,
the
things
that
I've
heard
and
I've
kind
of
distilled
out
of
it
is
kind
of
proposing
that
we
make
three
changes.
So
the
three
changes
are
moving.
I
o
build
packs
to.
I
o
build
packs
defaults.
A
This
the
prior
art
kind
of
being
github
actions
where
the
idea
of
defaults
kind
of
really
does
mean
defaults,
and
it's
not
the
primary
way
to
configure
a
platform
right.
Primary
ways
to
configure
platforms
should
be
pointed
to
those
platform-specific
configuration
files
and
or
namespaces
that's
kind
of
more
the
idea
there
I'll
get
into
it
in
a
little
bit.
A
A
I'll
try
to
go
through
this
quickly.
For
the
most
part,
the
namespace
defaults
should
declare
default
values
that
every
platform
should
at
minimum
acknowledge
right,
and
I
think
this
is
a
pretty
big
piece
here.
Is
that
anything
that
we
put
into
default?
A
A
But
in
a
general
sense,
this
defaults
area
right
now,
as
it
sounds,
it's
just
taking
what
we've
currently
got
on
project
descriptor
o2
and
just
bumping
it
up
into
the
defaults
namespace.
A
A
Last
but
not
least,
it
is
of
my
opinion
that
you
know
that
the
name
itself
defaults
kind
of
conveys
a
lot
more
and
it
changes
the
the
mindset
quite
significantly
to
what
it
was
prior,
where
your
expectation
is
that
this
will
just
work
on
every
platform
now
you're
at
least
pointed
to
these
are
defaults
and
there's
got
to
be
something
else
or
somewhere
else
else.
That
kind
of
sets
the
concrete
configuration
for
it.
A
Some
of
the
examples
here
that
I
have,
I
think
I
only
have
one
is
this
idea
where
we
could
have
multiple
platforms
right,
so
we
could
have
a
pack
and
a
kpac
configuration
all
within
a
project
descriptor-
and
this
is
the
pack
config
area
here
and
the
kpac
config
area
here
and
then
there's
defaults
that
essentially
would
be
applied
to
both
platforms
on
that
side.
A
This
is
a
pretty
big
chunk.
I
want
to
make
sure
I
don't
miss
out
on
any
questions.
B
C
D
D
I
think
one
one
reason
is
that
if
you
that
you
want
to
have
a
place
like,
let's
just
take
bill
pack
as
an
example,
I
want
to
set
that
once
and
I
want
it
to
work
on
all
the
platforms
I
deploy
to.
D
But
if
we
don't
have
a
list
of
build
packs
in
defaults,
because
kpac
doesn't
support
that,
then,
even
though
I'm
not
using
kpac,
I
would
have
to
put
that
list
in
my
pack
section
and
my
salesforce
section
or
tekton
section
right
so
like
by
by
restricting
what
can
go
into
the
defaults
based
on
what
everyone
can
support
ends
up
in
people
using
other
platforms
having
to
repeat
themselves.
A
Cool
all
right
now,
this
is
kind
of
I
guess
the
the
meat
of
it
all
of
of
how
this
is
unified,
all
the
different
components.
A
I
think
that
we
had
a
converter
at
some
point
in
rfc
for
converter,
but
I
think
we've
wanted
a
preparer
for
a
long
time
now,
and
I
think
this
is
a
pretty
good
use
case
of
a
preparer
where
the
preparers
responsibilities
are
to
merge
the
defaults
with
the
platform
specific
configuration
we,
it
should
have
built-in
kind
of
requirements
to
notify
the
user
of
any
properties
that
go
unused,
whether
it
be
on
the
defaults
namespace
or
on
the
platform
specific
namespace,
and
then
it
should
apply
the
configuration
up
and
apply
the
configuration.
A
I
think
that
is
still
maybe
a
little
bit
nebulous,
because
it
won't
be
able
to
apply
everything,
but
it
would
most
likely
be
able
to
apply
a
certain
amount
of
it
right.
I
think
we
talked
about
environment
variables,
like
I
can't
think
of
a
world
in
which
you
know
the
out
of
the
box.
Cnb
provided
preparer
couldn't
apply
the
environment
variables
from
a
configuration
file
right.
A
That's
just
one
example
there,
let's
see
the
next
thing.
The
the
next
big
hurdle
and
I've
been
working
on
this
today
is
is
the
merging
right.
So
let's
maybe
look
at
an
example
here
where
we
have
a
let's
see
yeah.
So
we
have
this
pack
namespace
in
the
project.
Descriptor.
A
If
we
were
to
you
know
kind
of
let
the
preparer
know
that
hey.
This
is
the
name
space
where
you
could
find
the
build
pack
or
sorry
the
platform
specific
configuration,
then
the
preparer
itself
could
do
the
merging
and
the
end
result
would
be
the
builder
set
to
the
pack
based
configuration
and
then
also
the
environment.
Variables
would
be
again
the
pack
specific
ones
as
opposed
to
the
default
provided
ones.
A
This
lends
a
lot
of
the
efforts
and
works
from
ie
tf.
I've
never
had
to
say
that
out
loud
rfc
and
basically
there
are
a
couple
limitations
that
we
have
to
work
around,
which
is
basically
arrays
are
not
appended
they're
replaced,
which
I
think
simplifies
the
system.
A
We
don't
have
to
worry
about
that,
but
I
I
do
foresee
some
some
users
kind
of
wanting
some
pen
functionality
open
to
discussion
there
and
then
there's
a
limitation
in
tamil
which
doesn't
allow
you
to
have
or
doesn't
have,
the
idea
of
a
no
or
no,
which
is
what
the
the
rfc
up
here,
uses
to
essentially
unset
or
zero
out,
which
I
think
is
what
joe
brought
up
at
some
point.
A
workaround
for
this
is
to
do
an
empty
table
and
use
that
as
a
way
to
unset
things
from
the
top.
A
Let's
see
that's
for
the
most
part
it
you
can
see.
Another
example
here
where
we
have
a
project
tamil
and
then
we
have
a
pac
tumble.
I
am
kind
of
I
think.
A
Suggesting
that
we
make
a
change
to
the
current
tamil
paktomo
rfc
in
that
I
think
we
can
go
away
from
name
spaces
at
that
file
level
and
it
that's
kind
of
how
I'm
going
through
this
but
joe.
You
know
free
to
talk
about
it,
but
the
idea
here
is:
we
have
project
tunnel
here
we
have
a
packed
tunnel
here.
We
let
the
preparer
know
that
that's
the
name
space
and
you
know
very
similar
effect-
happens
in
this
regard.
A
Yeah-
and
I
think
that's
a
good
segue
into
this,
so
this
is
the
prepare
executable.
These
are
the
configuration
elements
or
properties
to
it,
so
we
do
have
a
config
path,
which
would
be
the
prom
project
tamil
by
default,
a
platform
specific
config
path,
the
namespace
right,
because
it
does
have
to
know
you
know
that
information
and
then
there's
another
thing.
A
An
ignore
property
and
the
ignore
property
is
really
useful
for
when
the
platform
itself
is
taking
care
of
that
property,
so,
like
builder
for
pack,
would
be
a
really
good
example
where,
before
anything
happens,
pack
is
going
to
look
at
this
file,
whether
it
be
the
packed
home
or
project
descriptor,
and
it's
going
to
determine
what
the
builder
is,
that
it
should
use
based
on
that
configuration
and
what
it'll
do
is
when
it
executes
the
preparer
it'll,
say
I've
already
taken
care
of
the
builder.
You
don't
have
to
worry
about
that
property.
A
You
could
ignore
it,
and
so
by
ignoring
it,
what
that
means
is
that
it's
not
going
to
notify
the
user
that
it's
not
being
used
right.
So
everything
else
that
isn't
in
the
ignore
here.
If
the
preparer
doesn't
know
about
it
doesn't
know
what
to
do
with
it,
then
basically
it'll
throw
in
a
built-in
notification
or
warning
to
the
user.
B
A
See
other
examples
is
the
kpac
here,
so
this
one
will
throw
a
warning
if,
for
instance,
you
had
a
builder
set
on
it
or
if
you
were
to
say,
have
build
packs
right.
If
you
have
a
set
set
default
group
of
build
packs
that
you
wanted
to
use-
and
you
put
this
into
k
pack,
because
kpac
is
only
taking
care
of
include,
excludes
and
and
and
bill
environment
variables
for
build.
C
A
Because
it
would
based
on
the
properties
right,
so
if
it's
not
properties,
it
is
aware
of,
or
it's
not
and
or
its
properties
that
are
not
in
this
ignored
list
right,
then
it
would
work
for
all
those
properties.
C
So
let's
say,
let's
see,
there's
a
builder
and
if
the
so
the
way
to
signify
that
the
platform
has
already
taken
care
of
things
and
to
signify
that
it
doesn't
support.
Something
are
the
same
like
you
have
to
declare
both
of
them
through
ignore.
C
C
A
The
only
thing
I
could
think
of
at
this
point
would
be
environment
variables.
C
A
Okay,
so
exclude
doesn't
mean
don't
export.
A
Yeah,
so
if
it's
able
to
do
that,
then
yes,
that
should
be
doable
as
well.
I
guess
maybe
another
you
know.
Kind
of
thing
we
could
dive
into
is
that
the
preparer
could
change
right.
So
if,
if
k-pac
wanted
to
to
introduce
its
own
preparer,
that
does
know
how
to
handle
build
packs,
you
know
in
a
different
method
or
mechanism.
A
B
A
Yes,
so
only
configuration
level,
it
has
no
intimate
knowledge
into
the
the
properties
themselves,
how
they're
applied
and
and
or
the
the
feature
set
of,
the
platform
itself.
C
C
C
A
Well,
that's
a
that's
a
good
one.
I
I
was
definitely
thinking
more
on
the
default
side
of
things.
If
you
were
to
have
you
know
some
arbitrary
default
property
and
then
you
apply
a
change
and
that
property
goes
unused
right
and
and
the
platform
doesn't
have
it
as
part
of
ignore.
Then
it
would
say:
foo
was,
you
know
not
applied
configuration
foo
was
not
applied.
A
The
use
case
of
let's
say
kpac
namespace
having
fu.
We
could
do
the
same
thing.
I
don't
know
if
it
makes
sense.
C
C
A
Right,
I
think
that's
the
the
maybe
the
question
and
I
think
we
could.
I
guess
the
way
I
was
envisioning
this,
and
I
don't
know
if
I
put
it
on
here,
is
that
it
should
be
top
level
right.
So
you
could
it's
it's
whatever
you
want
to
ignore,
and
it's
children
essentially
right.
So
you
could
do
that
as
some
sort
of
that
that
might
minimize.
So
you
don't
have
to
do
every
individual
field
right.
You
could
just
do
properties
but
yeah.
That's
something
that
I
haven't
considered.
C
Okay
because
like
for
example,
the
the
cnb
platform
config,
ignore
the
examples
are
not
namespace
right,
they're,
just
top
level
keys.
Yes,
so
let's
say
I
want
my
namespace
to
be
vmware
kpac
whatever,
but
I
also
want
the
preparer
to
ignore
any
keys
that
it's
not
aware
of
that.
How
would
I
specify
that.
A
So,
first
off
I
it's
not
defined
right
now
that
that
functionality,
you
propose,
would
be
something
that
comes
out
of
the
box,
so
that
that
is
pretty
much
an
open
question
right
like
what
would
it
even
look
at
other
platform,
config
name
space
properties,
or
would
it
just
ignore
those
by
default?
Okay,
right.
B
A
C
Prefer,
if
it
just
ignores
everything
it
does
not
know
by
default,
but
it
gets
into
a
murky
place
because,
let's
say
this
com,
vmware
kpac,
that
has
its
own
schema
version.
I
o
build
packs,
will
have
its
own
schema
version
when
it's
trying
to
merge
those
two
things-
and
let's
say
at
some
point,
the
I
o
build
packs
schema
version
was
something
new
that
the
vmware
kpac
schema
version
is
not
aware
of.
C
C
A
That's
the
big
empty
section
right
there
I
haven't
gotten
to
that
point.
Yet
I
didn't
want
to
go.
Do
too
much
work
up
front
if,
if
this
is
all
something
we
want
to
throw
out
but
yeah,
that
is
a
really
good
kind
of
thought.
Experiment.
C
A
Yeah-
and
I
think
this
is
where
I
I
mean
it's
the
tail
end
of
this
right,
but
cnb
maintained
utilities,
whether
they
be
gold,
library
functions
or
or
just
the
executable,
that's
shipped
with
the
life
cycle.
A
I
think
those
are
one
of
the
things
that
I
I
think
are
necessary
in
order
for
there
to
be
success
in
this
sort
of
strategy,
and
I
think
that
may
be
a
place
where
we
could
provide
that
sort
of
functionality
right.
It's
where
platforms,
have
this
kind
of
pre-built
notion
on
how
to
do
the
merging
right,
because,
because
we
don't
want
to
have
every
platform,
have
to
rebuild
that
and
then
also
this
upgrade
strategy
whatever
it
may
be,
that
we
come
up
with.
C
I
have
a
prepare
phase
that
works
with
kpac
version,
0.5
and
pac
version
0.23
up
up
until
that
version,
and
it
knows
how
to
handle,
or
rather
than
the
pack
or
k-pack
version.
It
knows
how
to
handle
certain
schema
versions
under
the
pack
domino
or
com
vmware
kpac
table,
and
it
knows
how
to
handle
certain
versions
of
the
I
o
buildbacks
schema
and
if
it
doesn't
find
that
it
just
fails,
this
file
is
out
of
my
reach.
A
So,
but
from
I'm
thinking
about
it
from
a
user's
perspective,
right
like
the
the
platform,
tamil
and
the
let's
say,
pac-tom
or
k-pac
tunnel
in
this
merge
process
or
before
the
merge
process,
both
of
those
things
are
part
of
the
same
repository
and
coexist
right.
A
So
it's
not
like
a
separate
entity
owns
one
piece
and
then
another
entity
owns
another
piece
right,
so
the
user
could
just
simply
upgrade
both
of
them.
Wouldn't
that
be
the
solution
there.
C
C
You
still
want
certain
overrides
from
the
k
pack
side
or
like
which
are
not
by
default
present
in
io,
build
packs
it
the
more,
I
think
about
it,
the
more
like
it's
weird
to
duplicate
like
keys
across
files,
at
least.
If
it's
dynamic
configuration
you're
passing
through
cli
or
through
like
the
spec
it
it
makes
sense.
But
if
it's
in
the
same
repository,
why
would
you
have
one
configuration
in
your
project
normal
and
another
one
in
your
pack
demo.
C
Like
if,
if
the
goal
is
cross
platform
compatibility,
why
why
would
you
split
that
across
two
tables
and
make
certain
settings
specific
to
pack
and
override
the
defaults
in
I
o
buildback's
defaults
with
that,
like
you,
you
may
want
to
set
certain
flags
that
are
specific
to
pack
which
are
not
available
in
your
buildbacks
default.
But
why
would
you
want
to
merge
them
in.
D
Let's
say
your
default
is
a
some
java
build
pack
and
then,
when
you're
running
that's
for
your
production
environment
and
then,
when
you're
running
pac
locally,
you
want
the
java
build
pack
and
some
debug
build
pack
that
helps
you
like
hot
load
changes
or
something
like
that.
So
I
think
in
some
ways
it
may
be
unique
to
pack
because
of
the
local
use,
but
I
think
that's
one
reason
you
might
do
it
that
way.
C
D
B
B
A
B
A
So
could
you
elaborate
on
why
pac
would
want
to
ignore
it,
because
at
some
point
I
mean
it'd
be
nicer.
If
the
platform
just
took
care
of
it
or
sorry
yeah
the
life
cycle
prepared
just
take
care
of
it.
B
C
D
Yeah,
which
I
think
speaks
to
why
you
might
want
to
have
more
than
one
file
like,
and
I
mean
right
today,
pack
accepts
like
a
dash
p
option.
I
think
for
build.
Where
you
can.
You
can
name
your
project
tunnel,
whatever
you
want,
maybe
it's
dash
c,
but
you
could
have
like
a
pac-dev
dot,
tumble
or
something
like
that
and
just
pass
it
explicitly.
C
B
C
D
D
D
A
So
there's
multiple
pieces
here
right
so
there's
the
idea
of
of
needing
multiple
files
and
then
there's
the
idea
of
merging
namespaces,
and
I
think
those
are
two
very
you
know
like
mutually
exclusive
things
that
we
could
talk
about,
but
I
think
the
part
where
the
different
namespaces
exist
and
the
reason
why
we
want
to
merge
them
is
to
enable
you
know
platform-specific
configuration
when
we
talk
about
keys.
That
might
not
make
sense
at
this
like
global.
You
know
top
level
section
that.
C
C
A
The
part
where
I'm
trying
to
solve
it
is
like
the
io
dot,
build
packs.
You
know
namespace
before
the
defaults
right
as
it
stands
today.
Is
we
throw
stuff
in
there
and
not
every
platform
is
required
to
acknowledge
that
that
configuration
exists.
That's
the
part
that
I'm
trying
to
solve-
and
I
think
this
is
leaning
towards.
C
A
A
D
I've
got
I've
got
to
drop
in
two
minutes,
but
I
just
want
to
say
a
few
things
one.
First
of
all,
thank
you
for
writing
this
up.
I
really
appreciate
iterating
on
this
and
putting
it
together,
so
we
can
talk
about
it.
Second
thing
is,
I
would
probably
I
would
probably
approve
this,
as
is,
I
think,
there's
things
we
should
figure
out,
but
I
think
it's
aligned
enough
with
my
thinking
that
that
I
would
go
with
it.
I
think
the
the
gaps
that
we
have
are
worth
figuring
out.
D
What
one
change
one
change
I
would
require
is
actually
for
the
pack
tumble.
I
think
you
have
a
top
level
pack
table,
but
that's
just
that's
not
a
big
deal
and
then
the
last
thing
is
I'm
gonna.
I
would
like
to
think
about
doing
away
with
the
defaults
table
somehow,
and
I
wonder
if
the
existence
of
io.buildpax.pac
is
the
thing
that's
requiring
the
defaults
table
like
what,
if
we
moved
pack
out
from
the
I
o
build
packs
table
all
together,
but
I'll
spend
some
cycles.
A
All
right,
I
know
we
had
another
item
in
our
agenda
that
I
think
we
might
have
overlooked.
Are
there
any
other
thoughts?
Do
you
we
think
10
minutes
is
enough
for
the
next
item.
I
don't
know
who
put
that
on
there.
C
I
I
put
it
down
there.
I
was
just
that
was
just
something
I
wanted
to
share.
I
don't
know
if
other
people
might
find
it
useful,
but
kivono
is
a
sibling,
cncf
project,
it's
a
policy
engine
that
can
enforce
or
like
allow
you
to
create
mutation
of
validation,
web
hooks
using
ammo
files.
So
like
one
of
the
use
cases
that
I
generally
come
across
as
like
restricting.
C
Images
based
on
the
build
packs
that
we
used
to
build
them
or
like
the
base
images
that
they
have
or
the
user,
the
default
user
on
the
container
image
or
like
things
like
that,
so
the
the
proposal
is,
to
like
add
a
bunch
of
such
functionality,
first
class
to
that
webhook,
so
that
you
can
say
that
if
this
image
doesn't
contain
buildback
for
version,
1.0
then
reject
it
so
or
something
like
that
or
like
I.
C
So
you
can
enforce
policies
like
that
or
other
things.
It's
just
something
I
wanted
to
throw
out
there,
while
we
think
about
moving
things
out
of
the
label
like
what
kind
of
information
we
might
want
to
put
in
the
manifest.
So
like
the
current
design
supports,
reading
manifest
annotations,
config,
blobs
and
things
like
that.
C
But,
like
I
don't
know,
if
that's
a
requirement
you've
seen
on
your
side,
but
that's
like
something
I
I
care
a
lot
about
like
validating
the
image,
outputs
and
making
sure
that
there's
no
misconfiguration
or
invalid
builders
or
build
packs
or
base
images
being
used
or
if
the
base
image
is
too
old,
with
no
patches
so
yeah.
They
also
like
I
attended
the
community
meeting.
They
were
interested
in
knowing
about
buildbacks
and
like
what
what
other
integrations
they
can
have
with
us.
B
C
C
So
I
just
wanted
to
point
out
that
the
current
implementation
that
this
proposed
relies
on
being
able
to
read
the
manifest
and
the
config
blob
like
reading
layers
would
be
potentially
too
expensive
to
do.
You
know.
B
A
So
if
I'm
not
mistaken
or
or
maybe
I
don't
know
if
you
answered
it,
but
layers
would
probably
be
the
more
difficult
to
use
across
different
projects.
Yeah.
C
Manifest
annotations
for,
like
small
metadata,
would
be
great,
like
whatever
metadata
you're,
currently
storing
as
labels.
It
would
be
nice
to
move
them
as
manifest
annotations.
Moving
them
to
layers
would
probably
make
sense
for
things
like
s4,
which
are
like
fairly
large.
A
So
from
technical
side
of
things,
I
know
the
labels
cause
a
lot
of
issues
for
image.
Loading
and
stuff,
like
that.
Do
annotations
not
have
the
same
restriction
at
all
like?
Are
they
just
discarded.
C
It's
not
even
discarded
it's
just
that
the
manifest
is
a
registry
only
concept,
the
config
is
a
runtime
concept,
so
manifest
is
like
something
that
describes
how
it's
stored
in
metadata
about
that,
whereas
the
config
is
actually
used
by
the
container
runtime
to
like
spin
up
the
container.
So
it's
aware
of
it
and
retains
that
information.
C
The
original
use
of
labels,
I
believe,
was
docker,
introduced
it
to
filter
through
containers
with
with
certain
label
values
so,
like
you,
could
filter
containers
that
are
running
with
label
up
equals,
like
environment,
equals
production,
or
something
like
that,
but
it's
being
misused
and
like
the
way
labels
are
right
now
like
it's
nowhere,
even
close
to
what
they
were
meant
to
do.
A
C
A
B
A
B
A
A
So
that
is
true.
The
thing
that
I
think
is
still
not
associated
is
the
idea
of
a
schema
version
to
a
platform
api
right.
A
I
don't
think
I
think
the
converter
try
to
do
something
like
that,
but
in
this
current
proposal
that's
definitely
not
a
goal
and
it
doesn't
seem
like
it's
a
fit
in
my
mind,.
B
Does
that
mean
what
does
that
mean
for
the
converter
rfc
if
we
went
down
this
path
and
merged
this
in
or
baked
it
into
this.
A
So
I
think
the
the
the
challenges
with
the
converter
were
that
it
made
changes
that
then
the
platform
had
to
read
after
the
fact
and
it
discarded
everything
that
was
platform
specific.
So
you
know
it
did
a
partial
job
for
for
certain
things
and
I
think
that's.
A
Yeah,
I
mean
ultimately,
I
think
it
it
shifts
away
from
there
being
this
like
central
configuration
to
just
there
being
a
a
platform-specific
configuration
right,
and
it's
really
the
platform's
responsibility
to
take
ownership
of
that
and
there's
a
little
bit
of
leakage
there
in
the
in
the
repair,
but
the
that's
only
so
that
we
could
handle.
You
know
99
of
the
cases
for
pac
or,
like
you
know,
standard
cases,
but
platforms
could
replace
the
preparer
so
that
it
does
stuff
that
they
want,
with
only
their
configuration
and
totally
irrelevant
or
discard.