►
From YouTube: OCI Weekly Discussion - 2021-03-03
Description
OCI weekly developer's call recording from 03 March 2021. Notes/agenda here: https://hackmd.io/El8Dd2xrTlCaCG59ns5cwg#March-3rd-2021
B
A
E
G
G
Well,
that's
different
for
different
images.
Right.
I
think
tienen
explains
it
in
the
comments
that
you
know
for
something
like
golan
alpine.
The
base
image
is
golang
alpine,
which
is
based
on
the
alpine
image.
Well,
yeah,
it's
based
on
the
alpine
image.
It
gets
a
little
more
complicated
with
like
golang
debian,
where
it's
based
on,
like
a
bill,
packs
derivative
of
the
original
debian
os
image.
So,
yes,.
E
G
E
A
A
E
E
But
in
all
cases
you
can
know
that
if
any
of
these
images
I
depended
on
at
build
time
have
changed.
That
means
something
to
me,
and
I
should
probably
rebuild
my
image
and
so
I
think,
that's
kind
of
a
simple
general
concept
that
is
useful
and
addresses
the
the
primary
concern
which
was
about
you
know.
Not
all
images
have
a
single
base
image.
What
do
we
do.
A
Well,
there's
a
difference
in
what
I'm
getting
at
is
what
nietzsche
was
kind
of
talking
about
is
golang
depends
on
alpine.
Let's
say
I
don't
remember
it's
not
important.
The
point
is,
is
that
there's
that
history
and
that's
that
I'm
not
as
worried
about
because
if
you
take
it,
if
you
include
the
golang
one,
for
instance,
then
you
are
picking
up
the
others
implicitly
right.
A
More
referring
to
is
the
in
the
multi-stage
docker
files.
We
have
all
the
other
from
statements
that
are
used
to
compile
your
code
that
gets
put
into
the
ultimate.
So
if
you
have
a
an
order
on
an
ordered
list,
maybe
that's
the
answer.
If
you
have
a
comment
delimited
list,
then
how
do
you
know,
which
is
the
one
it's
actually
on
as
because
that's
the
content,
that's
in
the
image
versus
here's,
the
other
images
that
were
used
to
build
it.
G
E
Basically
any
image
that
you
need
to
pull
down
should
go
in
this
list,
regardless
of
like,
if
the
layers
end
up
in
there
or
if
it's
just
used
as
an
intermediate
step
for
say,
getting
the
go
compiler
to
produce
a
binary
it
regardless
it's
a
build
time,
dependency
and
so
like
it.
If
you
know
that
it
has
changed,
then
the
output
of
your
build,
possibly
will
change,
and
so
you
can
know
hey.
E
I
should
probably
re-trigger
a
build
or
something
in
in
the
simple
case
of
like
I
have
one
base
image
from,
and
I
am
appending
to
that
thing.
Then
yeah
like
you,
can
do
more
interesting
stuff
where
you
know
the
file
system
contents,
but
I
don't
think
it's
reasonable
to
specify
that.
I
think
this,
the
relationship
that
this
annotation
expresses
is
more
powerful
if
it's
simpler
and
then
the
simpler
part
is.
I
have
a
build
time
dependency
on
this
other
image,
and
so
then
we
don't
have
to
talk
about
like
what
does
that
mean?
E
G
E
E
A
Support
this
with
tasks
where
there's
a
base
image
dependency
for
the
content,
that's
in
the
image!
That's
actually
you
know
in
the
image
you're
talking
about
right.
That's
in
many
ways
the
most.
It's
not
well
the
only
important
thing,
but
it's
considered
one
of
the
important
things
there's
an
optional
way
to
say.
I
also
want
to
be
triggered.
If
any
of
the
other
images,
I
call
it
sdk
images,
that's
not
a
good
example.
I
can't
remember
what
we
call
them,
so
I'm
just
asking,
I
think,
there's
a
delineation
between
the
two
I'd
be
fine.
E
Do
I
think
you're
you're
really
tunneling
in
on
very
docker
specific
things
that
are
specific
to
the
implementation
of
docker
build
and
not
the
format
of
the
image
where,
like
the
produced
layer,
could
be
inherited
from
a
base
image
and
that's
fine.
I
mean
like
we
could
describe
that
as
a
separate
concept,
but
in
terms
of
what
tooling
you
want
to
build.
I
don't
know
that
it's
interesting
like
we
could
lie.
I
don't
know
it
just.
E
G
E
It
is
a
implementation
detail
of
like
a
docker
build
like
you
can
build
docker
images
with
bazel
that
don't
understand
like
there's,
not
really
a
base
image
right.
You
can
get
an
equivalent
thing,
but
there's
no
notion
concretely
of
what
a
base
image
is.
We
could
define
one,
and
maybe
we
want
to
do
that
as
part
of
this
proposal,
but,
like
I
think,
it's
moved
in
a
better
direction.
A
A
E
A
A
E
Yeah,
let
me
find
this
link,
so
I
talked
to
steve,
not
you
steve,
the
other,
steve
stevo
and-
and
I
was
asking
like
what
is
this
reserved
data
field,
and
is
it
what
I
expect
it
to
be
and
it
turns
out
yes.
So
there
are
some
use
cases
where,
like
I
have
a
descriptor
that
points
to
a
very
small
amount
of
data,
and
it
is
a
shame
that
I
will
have
to
do
a
separate
hop
to
go
fetch
that
data
say
100
bytes.
E
So
I
think
the
intention
of
this
reserve
data
field
was
to
just
embed
in
the
descriptor
the
content
that
is
described
by
the
descriptor,
so
that
you
can
just
have
inline
data
and
not
have
to
do
this
extra
hop,
and
so
this
is
just
it
would
be
a
performance
optimization
if
we
spec
this
out
and
I
think
it'd
be
pretty
simple
to
spec
it
out,
but
I'm
interested
in
other
people.
I've
looked
at
this
or
thought
about
this
and
wanted
to
bring
it
to
the
attention
of
folks.
E
I
would
like
to
send
a
proposal
that
we
define
what
this
data
field
is
for
and
then
I
can
start
using
it
in
other
places.
I
have
some
concerns
around,
like
you
know,
do
for
for
a
registry
right
if
this
descriptor
has
data
embedded.
Does
the
registry
expect
people
to
have
also
pushed
that
data
to
the
to
the
registry
blob
store?
A
I
mean
I
like
it.
This
solves
part
of
the
problems
we've
been
trying
to,
although
annotations
might
have
solved
it.
This
is
the
in
a
notary,
v2
case.
How
do
I
know
who
signed
you
know
which
who
signed
that
particular
signature,
so
I
can
filter
on
it
so,
and
this
was
the
thing
we've
been
talking
about
in
the
payload
response
like
do.
I
need
to
return
a
whole
manifest
just
because
one
of
those
elements
is
interesting.
A
C
E
E
No,
I
don't
think
so.
I
so
like
it's
nice
that
this
is
in
the
descriptor
and
not
like
somewhere
else.
I
get
what
you're
getting
at
like
for
a
canonical
index
manifest.
It
would
be
nice
if
the
embedding
of
data
in
a
descriptor
didn't
affect
the
digest
yeah.
I
think
that
gets
into
like
very
tricky
territory
and
I'd
like
to
avoid
it,
and
just
you
know
if,
if
the
author
of
this
artifact
decided
to
embed
the
data,
then
that's
that's
what
the
artifact
is.
E
It
has
embedded
data
for
some
cases
like
with
the
listing
proposal
I
have
where
I
want
to
return
a
set
of
descriptors.
In
that
case,
we
could
leave
it
up
to
the
registry,
whether
or
not
like
they're
going
to
embed
some
data
in
that
return
type
but
yeah.
I
don't
think
we
should
get
into
the
business
of
canonicalizing
the
artifacts.
We
should
just
be
dumb
and
say:
oh
yes,
these
bytes.
I
can
move
them
around
and
not
think
about
it.
E
E
E
Well
right,
so
it's
a
pointer
right,
and
so
we
have
it's
it's
data
about
the
thing
being
pointed
to
not
data
about
the
thing
that
is
pointing
to
that
thing
so
like
it
would,
if
you
have
say
a
manifest
list,
this
is
multi-arch
specific
and
you
wanted
to
embed
all
the
manifests
in
that,
so
that
you
could
do
it
in
one
hop
instead
of
two
that
decision,
whether
or
not
to
embed
it
would
affect
the
digest
of
this
outer
manifest
list.
But
not
the
inner
manifests.
D
A
G
E
It's
you
know
we're
pointing
to
stuff
already
in
the
dag,
and
now
this
this
node
in
the
dag
is
slightly
different
than
a
node
in
the
dag
that
is
equivalent,
but
doesn't
embed
that
data,
and
we
already
have
that
problem
right
with
json,
formatting
and
all
kinds
of
things
and
ordering
of
keys,
and
so
it
doesn't
really
add
a
new
class
of
problem.
It's
just
you
should
I
don't
think
it's
really
a
problem.
G
Well,
I
mean
yeah
it
I'm
concerned
about,
like
just
general,
like
identifiability.
How
would
a
how
would
a
person
know
that?
How
do
person
know
the
difference
between
you
know?
One
image
and
the
other
image
when
the
only
thing
different
about
them
is
that
the
data
that
data
field
is
in
one
versus
not
in
the
other
and
not
in
the
other.
E
I
would
argue
they're
different
artifacts
right.
We
have
this
problem
already
with
compression
right
if
I
gzip,
with
fast
compression
and
ugzip
with
best
or
if
you
g,
zip,
with
z,
standard
like
they're,
functionally
the
exact
same
thing,
but
they
have
different
digests
similarly
like,
if
you
add
a
label
or
an
annotation
to
a
manifest
you've
changed
it
and
it
it
has
a
new.
It
expresses
a
new
thing,
even
though
they
are
equivalent,
and
so
I
think
this
falls
into
that
class
of
problem.
E
A
A
E
E
A
Listening
to
this,
I
encourage
back
to
go
back
to
the
you
know.
This
is
the
the
caption
of
the
requirements,
because
I
agree
just
returning
a
descriptor
isn't
enough
information.
If
I
have
a
collection
of
signatures,
I
don't
know
which
one
I
care
about
so
now.
I've
got
to
fetch
each
one
of
them:
that's
inexpensive
in
operation.
So
that's
why
we're
in
this
longer
debate?
A
E
C
A
B
B
E
So
the
the
first
thing
was
to
reorder
it
just
because
like
for
aesthetic
reasons,
but
the
more
important
change
is
that
second
commit
where
I
clarify
that
a
client
should
expect
to
receive
a
201
or
a
202
and
those
mean
different
things.
So
I
I
get
them
confused
in
my
head
when
I'm
not
looking
at
it,
but
one
of
them
is
oh
yes,
I
I
accept
this
single
request
model
that
I
upload
you're
done
and
the
other
beings.
E
I
B
No,
I
yeah,
I
I
looked
at
that
we
can.
We
can
carry
on
the
pr
if
you
could
there's
an
open
pr
from
wang
from
hardware
project,
and
I
think
it's
related
to
this.
If
you
can
see
if
those
changes
reflect
what
you're
proposing
because
yeah
it's
I
put
it
in
the
chat
or
I
put
it
in
the
I
linked
to
that
pr
I'll
put
it
in
the.
B
E
E
E
C
C
E
I
mean
we,
we
talked
about
that
in
the
call,
but,
like
derek
mentioned
on
my
issue,
that,
like
the
best
behavior,
is
probably
to
do
what
I've
done,
I
can
remove
it
or,
but
I
don't
know
we
don't
have
consensus,
and
so,
if
there
is
consensus
that
we
should
remove
it.
Please
comment
on
the
pr
issue
and
I'm
happy
to
do
that.
B
A
E
C
E
Yes,
okay
and
and
my
pr
I
tried
to
if
there's
a
way
to
make
it
more
explicit.
I
was
reading
through
the
rfc
about
how
to
write
an
rfc,
and
I
wasn't
sure
about
the
language
specifically,
but
if
there's
a
way
to
make
it
clear
what
I'm
intending
that
like
clients
should
probably
expect
not
to
have
this
be
supported
and
here's
what
to
do
if
it's
not
and
here's
how
registry
is
expressed,
that
it's
not
supported.
A
I'd
also,
I
like
the
idea
of
moving
it
down
for
for
people.
Just
don't
want
to
read
too
much
it's.
You
want
to
read
the
thing
that
until
you
hit
something
and
you
start
executing
if
they
start
executing
on
that
one,
because
it's
the
first
in
the
list-
it's
you
know,
I
don't
think
that's
the
intent.
We
want
to
send
here
so
right
that
also
already.
B
B
There's
an
intro
section
in
there
that
I
I'm
particularly
it's
new
content,
I'm
particularly
proud
of,
but
it
kind
of
goes
through
the
relationship
between
the
three
specs
and
artifacts,
which
for
a
lot
of
people
coming
in
to
oci
they're
thrown
all
these
terms,
and
so
jimmy
had
mentioned
that
he'd
maybe
like
to
see
something
like
that
across
all
the
specs.
But
if
you
haven't
seen
the
new
readme
check
it
out,
it's
based
on
the
image.
F
B
B
Yeah,
I
don't
know
if
anyone
wants
to
elaborate
on
that,
but
we've
kind
of
we've
been
talking
about
potentially
getting
it
into
cncf
as
a
project
so
that
it's
a
little
bit
more
official
because
it's
one
of
the
building
blocks
of
the
helm
integration.
So
yeah
there's
there's
a
lot
there,
but
I
have
been
talking
to
alexa
and
we
have
been
discussing
potentially
baking
what
the
scopio.
B
B
E
E
That
is
a
reference
implementation,
because
there
is
no
way
to
push
to
a
registry
that
complies
with
the
standard,
because
registries
that
allow
you
to
push
require
you
to
do
authentication
and
so,
like
you
can't
right,
and
so,
if
we
there's
a
dependency
for
like
or
as
to
be
a
reference
implementation
of
anything
of
us
to
describe
authentication,
I
mean
you
know.
Technically,
you
can
make
a
registry
that
doesn't
require
authentication,
but
no
one's
going
to
run
that
and
no
one's
going
to
use
that.
C
B
Let's
make
it
a
let's:
let's
I
don't
want
to
go
down
too
deep
into
the
to
the
tunnel
here,
but
let's
make
it
a
priority
after
1-0
to
get
to
basically
codify
the
auth
that
everyone
already
knows
how
to
use
and
has
been
written
into
several
clients,
because
it
is
an
implicit
spec.
You
know
and
there's
a
bunch
of
code
doing
the
same
stuff
everywhere.
G
Yeah,
that's
that's
the
thing
right.
I
don't
know
whether
I
don't
know
what
kind
of
authentication
a
registry
is
using
unless
I
query
the
right,
endpoints
and
and
get
the
information
that
I
need,
like
the
the
docker
login
way
is
I
mean
it's
great
for
usability,
but
it's
not
really
that
good
for
understanding.
G
A
A
It
gets
under
a
foundation
because
the
deus
labs
has
always
been
just
a
staging
ground
and
it's
been
sitting
there
too
long
and
it
is
becoming
a
problem.
So
if
we
can't
find
a
clear
path
to
put
it
in
oci,
then
let's
go
to
cncf,
that's
what
it's
there.
For
I
mean
it's
to
me.
Cncf
is
overkill
because
it's
never
meant
to
be
a
a
large
community
of
people
contributing
to
auras.
A
lot
of
people
should
be
consuming
rs
as
to
work
with
registries,
and
that's
why
we
thought
oci
was
the
right
answer.
A
We
can't
seem
to
find
consensus
on
that
and
I
do
think
it's
more
important
to
get
it
into
a
foundation.
So
I
I'm
you
know
to
me.
I
thought
oci
was
the
better
fit.
If
we
can't
get
that
happen,
then
it's
more
important.
It
gets
under
a
foundation
which
I
don't
you
know.
I
don't
know
how
much
this
call
is
as
relevant
in
the
sense
that
this
is
technically
oci.
A
A
It
could
oh
it
absolutely
could
the
question
is:
is
there
the
re?
Oh
sorry,
the
reason
I
it's
not
that
I
couldn't
go
to
cncf
when
we
scoped
this
in
the
tob
several
months
ago.
The
discussion
was
oci
is
more
around
the
specs
that
are
there
and
you
know,
does
this
conform
to
those
specs?
It
pulled
in
some
of
the
libraries
and
other
things
that
wasn't
intentional.
We
can
factor
that
out,
but
the
idea
is
in
oci
we're
not
going
to
get
like
a
lot
of
marketing
coverage.
A
We're
not
looking
to
be
a
tile
on
some
big
cncf
kind
of
wall.
It's
a
few
projects
and
they're
meant
for
a
few
people
to
use
in
a
lot
of
different
places.
Cncf
there's
a
lot
of
people
using
a
lot
of
projects
and
there's
a
lot
of
marketing
budget
and
coverage.
You
automatically
get
talks
at
conferences
and
so
forth.
That's
kind
of
overkill,
I
think,
for
what
we're
trying
to
do
with
juarez,
but
it
needs
to
go
somewhere
and
if
we
can't
get
it
here
being
this
is
the
oci
call.
A
Project
problem
with
the
distribution,
so
I
love
that
distribution
went
over.
So
it's
not
that
there's
a
problem
related
to
that.
It's
that
it's
really
for
the
spec.
This
distribution
is
also
a
you
know,
an
opinionated
view
of
the
distribution
spec.
I
don't
know
if
that's
the
right
way
to
say
it,
so
I
don't
know
if
it
should
go
under
distribution,
because
people
will
use
it
having
nothing
to
do
with
distribution.
It's
really
related
to
the
distribution
and
artifact
specs,
as
opposed
to
the
distribution
implementation.
J
Yeah,
I
was
just
more
thinking
that
in
that
sense
you
don't
have
to
worry
about.
You
know
carrying
sort
of
a
whole
project
for
something
that
you
know
is
mostly
consumed
but
well,
like
you
said,
there's
a
wide
array
of
people
who
probably
want
something.
You
know
a
small
library
like
that,
but
you
know
maybe
doesn't
rise
to
the
sort
of
breadth
of
of
a
full
cncf
project.
A
F
D
So
I
can
speak
to
some
of
that.
I've
tried
to
stay
quiet
and
let
you
all
kind
of
work
through
things.
I
would
take
a
look
at
the
sandbox
proposal
and
see
if
that's
a
really
good
fit
for
what
it
is
that
you
guys
are
currently
looking
at
now,
and
the
reason
that
I
say
that
is
because
we
have
another
sandbox
inclusion
meeting
end
of
the
month
so
march.
23Rd
got
some
time,
not
a
ton
of
time,
but
enough
to
be
able
to
look
and
see.
G
G
F
F
D
Oh
okay,
sorry
that's
the
question
here.
Yes,
I
can
definitely
answer
some
of
that
too.
Part
of
that
is
that
the
sandbox
project
applies
for
being
able
to
move
to
incubation
and
they
go
through
a
thorough,
due
diligence
process
led
by
one
of
the
toc
sponsors
like
they.
A
lot
of
things
need
to
happen
for
that
to
be
able
to
come
together.
D
G
G
B
I
I
don't
know
I
I
personally
would
like,
as
a
go
developer,
to
import,
open
containers,
something
and
push
something,
and
that's
that
was
my
whole
push
to
get
it
as
part
of
open
containers,
project
and
part
of
why
I
want
to
get
something
in
there
and
why
I'm
talking
to
alexa
and
this
umochi
stuff
I
just
as
I
just
want
to
build
tools
and
go
and
have
something.
That's
like
the
official
thing,
and
that's
that's
really.
E
I
I
have
opinions
here.
I
think
this
is
complicated.
Software
like
there
are
some
opinionated
things
that
happen
and
as
such,
like
I
don't
know
that
there
can
be
like
a
kind
of
straightforward,
like
official
implementation
of
this.
Exactly
right
like
expect,
the
the
spec
itself
has
a
lot
of
like
optional.
You
know,
may
whatever
there's
there's
all
kinds
of
things
that
clients
could
do
differently,
and
I
don't
know-
and
just
like
politically
like
there
are
a
handful
of
these-
that
already
exist
owned
by
various
orgs.
E
There's
like
the
docker
stuff,
the
container
d
stuff,
the
red
hat
stuff,
the
google
stuff.
Everybody
has
a
registry
client,
and
so
like
to
your
point.
It
would
be
nice
if
there
was
an
official
one,
but
you
know
the
implementations
are
different
for
a
reason
like
different
orgs
have
different
opinions
about
how
this
software
should
work,
and
I
don't.
B
B
E
A
Thing
we
just
we
need
like,
and
I
put
this
in
the
chat
session.
I
don't
think
we
would
have
seen
so
much
adoption
of
artifacts
with
all
these
different
types.
If
josh
and
cheway
didn't
put
this
thing
together
over
christmas
a
couple
of
years
ago,
it
has
since
expanded
because
it
would
never
had
an
official
charter
and
everything
so
there's
been
a
bunch
of
stuff
that
got
contributed
to
it.
A
So
it's
it's
kind
of
a
a
bunch
of
stuff
in
it
now
and
you
know,
it'll
be
nice
to
get
that
cleaned
up,
but
at
the
end
of
the
day
the
success
of
it
has
been
that
I
can
push
and
pull
artifacts
non-container
artifacts
into
a
registry
and
as
far
as
I
can
tell
every
registry
I've
seen
has
now
been
able
to
support
that
because
they
basically
supported
it
anyway.
It's
just
there's
now
a
documented,
and
you
know
way
to
do
it
and
there's
a
cli.
A
A
You
know,
I
think
that's
has
always
been
the
intent,
but
it
to
john
to
your
point
is
like
it
there's
a
certain
set
of
capabilities
that
do
need
to
exist
across
all
registries
or
they're.
Just
they
shouldn't
be
called
registries.
I
mean
whatever
you
want
to
call
them,
but
we
need
the
whole
idea
here.
We're
trying
to
get
to
is.
We
can
build
tooling
that
consistently
works
across
all
registries.
A
The
docker
client
happens
to
work
across
all
registries
because
there's
an
expectation
on
that
for
push
and
pull
for
instance,
or
you
know
whatever
apis,
we
want
to
be
able
to
do
things
for
other
artifacts.
We
want
to
be
able
to
enhance
that
experience.
For
instance,
you
know
the
tags,
the
manifests
and
the
other
stuff
so
that
you
can
see
this
ecosystem
work
across
a
set
of
registries.
B
Yes,
yeah,
I
think
that
the
you
know,
purism
aside,
the
the
project
has
had
traction
and
you
know
the
helm,
the
helm
implementation
rolled
out
like
in
2019
and
we're
finding
that
it's
being
supported
like
all
over
the
place
and
it
seems
to
just
work
and
that's
thanks
to
the
you
know
how
well
container
d's
libraries
support
all
these
different
registries
and
edge
cases.
So
I
don't
think
we
should
throw
it
in
the
garbage,
but
I
think
we
should
throw
it
into
a
foundation
so
that
it
gets
the
love.
B
E
What
I'm
hearing
is,
there
are
bugs
encoded
in
clients,
and
so,
if
we
do
a
reference
implementation,
we
have
lost.
What
did
josh
was
saying:
the
history
of
container
d
being
backward
compatible
and
broadly
compatible
so
like
if,
if
we
have
a
pure
reference
implementation
that
doesn't
take
into
account
how
broken
most
registries
are
under
the
hood,
it's
not
useful
because
it
doesn't
work
without
accounting
for
those
the
reality
of
writing
a
client
that
works
across
all
the
registries.
Oh,
that,
that's
a
that's
a.
D
C
C
E
C
E
E
C
Yeah,
but
I
do
I
do
think
we
need
a
a
ref
we
need.
We
need
a
reference
implementation
for
you
know,
and
that
was
really
why
I
believe
the
docker
guys
initially
you
know
push
forward
their
their
spec
to
you
know
to
us
say:
hey,
hey,
go,
you
know,
go
hand,
hold
this
a
little
bit
and
then
you
know
the
good
thing
is
like
to
say:
distribution
is
now
in
cncf.
So
a
lot
of
potential
there.
A
But
it
needs
to
be
refactored
and
cleaned
up.
It
seems
to
me.
I
think
we
want
to
do
that
regardless,
I
mean
it's
just
a
matter
of
people
spending
the
time
to
to
get
to
it.
That's
always
been
a
challenge
with
these
things.
Look
I
you
know
the
fact,
there's
even
an
implication,
there's
some
politics
around
juarez
and
microsoft,
because
it's
there
like
that,
that's
the
main
thing
I
just
want
to
absolutely
avoid.
A
So
I,
unless
somebody's
gonna,
unless
somebody
really
wants
it
to
be
an
oci,
and
I
keep
on
hearing
people,
you
know
keep
on
pushing
back
for
various
reasons,
whether
you
want
to
argue
with
them
or
not,
that
that's
the
part
that
I
just
don't
want
us
to
get
caught
up
in.
So
to
me,
I
I'm
fine
going
forward
with
cncf
and
if
it
sits
in
you
know,
I
would
say
incubation.
A
You
know
for
a
while
at
least
it's
under
a
federation
that
has
some
governance
around
and
there's
no,
no
implication
of
politics
whatsoever.
This
was
never
intended
to
be
a
microsoft
project
that
we
happen
to
occasionally
take
contributions
from
others.
It
has
always
been
a
true
open
source
project
that,
if
we
were
fifty
percent
of
the
countries
was
basically
josh
and
chiwe
and
there's
now
others
that's
great,
and
we
want
to
support
more
of
that.
So.
B
E
C
B
E
A
A
We
came
away
with
some
way
to
determine
the
separation
between
the
from
statement
for
the
invention.
I
know
it's
docker
based,
but
what
are
what
are
the
other
layers
that
this
thing
came
from
versus
the
things
that
went
into
it
and
for
better
or
worse,
the
multi-stage
dockerfile
is
used
pretty
popularly
so
having
some
conversation
availability
for
it?
So
you
don't
have
this.
You
know
list
of
strings
which
you
know.
I
guess
I'm
not
a
fan
of
the
list
of
strings
in
this
one.
I'm
a
fan
of
there
is
one
base
image.