►
From YouTube: CNB Sub-Team Sync: Platform: 2022-02-09
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
All
right
so
the
first
one
to
get
started.
We've
got
the
the
youtube
stream
going
so
there's
that
far
as
any
status
updates,
something
slightly
related
to
the
sub
team
is
more
or
less
an
announcement
of
sorts
that
the
google
summer
of
code
through
the
cncf
is
accepting
projects
right
now.
That
is
definitely
something
that
we
should
probably
take
advantage
of.
A
I
believe
the
deadline,
for
that
is
the
14th,
so
that
would
be
sometime
next
week,
but
obviously
don't
wait
to
the
last
minute
I
just
this
morning
submitted
and
got
accepted
for
one
of
the
cash
flag
options,
issues
that
we
had
in
pack
and
so
that'll
be
something
that
hopefully
I
can
mentor
somebody
through
and
getting
that
implemented
again.
The
opportunities
are
there
for
just
about
anything
on
any
layer.
You
know
as
long
as
there's
code
involved,
they're
they're
more
than
happy
to
accept
those.
A
So
if
you
have
any
more
questions,
please
feel
free
to
reach
out
to
me.
That's
one
of
the
things
that
I'm
working
on
right
now.
A
Any
other
status
updates
mentions.
A
All
right,
if
there
are
none
there,
we
can
move
over
to
release
planning.
If
I'm
not
mistaken,
I'll
have
to
look
at
this
like
here,
but
we
are
or
sorry
david
did
put
up
an
rc4
pack
o24,
and
so
that
was
last
thursday.
I
believe
that
should
be
going
out
tomorrow.
If
all
goes
well.
A
Okay,
next,
we
have
our
fcs
so
for
rfcs
on
the
platform
side
of
things,
we
really
only
have
one.
A
Maybe
there
really
should
be
two,
but
the
one
currently
listed
is
for
support
of
pac.tamul.
This
is
more
or
less
the
idea
of
having
a
different
file
that
would
be
checked
in
with
source
code
and.
A
There's
a
couple
reasons
why
this
exists:
there's
a
long
history
if
you
want
to
get
into
that,
we
can
do
that,
but
basically
pac
tommo
would
be
the
configuration
of
pack
in
a
file
format
that
then
pack
would
read,
and
it's
supposed
to
work
with
project
descriptor
or
more
or
less
kind
of
add
some
functionality
there.
A
So
if
you
have
any
thoughts
on
that
interested
in
that,
you
could
go
ahead
and
review
that
rfc,
it
is
currently
marked
as
blocked,
because
we
are
working
on
some
other
changes
for
the
project
descriptor
and
a
what's
called
a
prepared
phase
which
I'll
go
ahead
and
add
that
label
to
the
preparer
phase
as
well
or
actually,
I
don't
think
that
I
can
so
we
might
have
to
wait
for
the
working
group
in
order
to
be
able
to
do
that.
A
Okay,
let's
see,
I
think,
yeah.
If
we
refresh
that
should
show
it
now.
I
think
that's
pretty
much
it
for
all
these
standing
items.
If
I
missed
anything,
please
feel
free
to
jump
in
other
than
that
we
can
move
on
to
the
other
topics.
I
think
someone
had
a
question
about
remove
stacks
rfc.
B
Let
me
put
that
there,
I
think
I
put
that
there
and
then
I
went
back,
and
I
looked
at
the
spec
issue,
which
was
created
for
looks
like
rfc
number
172,
and
I
saw
your
last
comment,
javier,
that
was
the
builder
distribution
spec.
It
sort
of
like
was
a
milestone.
B
Before
we
can
start
thinking
about
the
stack
removal
stuff,
I
mean
just
just
like
I'm
interested
in
it
because
it
at
one
point
has
been
floated
that
stack
removal
should
be
sort
of
figured
out
before
we
can
really
completely
figure
out
the
support,
docker
files
track
of
work.
So
I'm
just
like
trying
to
keep
tabs
on
it.
But
I
don't
know
if
there's
anything
to
say
just
brought
it
up
to
kind
of
wonder
what
everyone
else
is
thinking.
B
A
That's
a
good
thought.
I
I
will
tell
you
that
I
believe,
while
you
were
out
in
one
of
the
implementation
meetings
emily
and
I
discussed
what
the
potential
strategy
for
going
through
the
implementation
of
that
would
look
like
specifically
like
let's
say
the
builder
through
pack
pack
creates
builders
and
we
were
kind
of
trying
to
figure
out
what
the
best
strategy
would
be
to
like
kind
of
keep
that
sort
of
backwards.
Compatibility
aspect
necessary
the
least
path
of
breakage,
and
we
do
have
some
some
plans
there.
A
I
honestly
don't
know
exactly,
though,
where
that
priority
lands
and
who's
really
slated
to
do
that.
Work.
A
The
other
tidbit
that
you
mentioned
was
sort
of
how
this
should
should
or
shouldn't
coordinate
with
the
support
doctor
files
implementation.
I'm
curious
to
hear
what
your
thoughts
have
been
on.
That
is
one
slated
to
be
done
before
the
other
is
one
going
to
block
the
other
or
they're
go.
Are
they
gonna
have
to
be
released,
essentially
on
the
same
version,
which
I
think
would
be
probably
the
worst
case
scenario.
A
Yeah
because
I
guess,
if
I'm
not
mistaken,
both
of
these
greatly
impact.
A
Most,
if
not
all,
of
the
specifications
right-
and
I
think
that's
the
part
of
concern-
is
that
I
think
we're
wanting
and
hoping
to
have
every
specification
be
independent
and
then
therefore
be
able
to
operate
almost
interchangeably
in
some
form
or
fashion
to
keep
that
compatibility.
A
You
know
at
least
somewhat
stable
and
so
yeah.
I
think
that's
going
to
require
a
large
effort
in
planning.
The
part
that
I
think
maybe
you're
you're
poking
at
is
who's
doing
the
planning.
And
how
are
we
going
about
that?
And
maybe
we
should
have
a
a
task
force
right
or
a
what
do?
They
call
it
in
the
kids
world
a
tag.
A
A
That's
honestly,
the
only
thing
I
can
think
of
because
yeah
I
haven't
given
it
much
thought
sounds
like
you
know.
I
think
you
just
said
you
you
haven't,
and
so
I
don't
know
who
is,
I
think,
we're
all
just
equally
afraid
that
at
the
amount
of
work
and
the
coordination
necessary,
but
if
we
don't
face
it,
I
don't
see
how
it
would
work
out.
B
B
I
see
us
kind
of
getting
to
a
place
where
we
might
be
ready
to
ship
like
an
experimental
or
you
know
some
kind
of
not.
You
know
ready
for
production
thing
that
people
can
use
to
try
it
out,
and
at
that
point
we
might
ask
ourselves.
Okay,
are
we
gonna
be
boxing
ourselves
in
here?
If
we
don't
figure
out
how
this
plays
with
the
stack
removal
stuff
right,
but
we're
not
quite
there
yet
with
the
the
proof
of
concept?
So
maybe
you
know
we
just
keep
an
eye
on
it.
B
A
So
is
the
order
of
operations
intended
right
now?
It's
like
we're
doing.
We
started
with
an
rfc
right
and
everybody
kind
of
aligned
on
the
idea
behind
it
and
then
said,
but
we
need
a
poc
to
prove
out
the
implementation
and
maybe
limitations
thereof
and
that's
the
stage
we're
at,
but
then
I
would
assume
that
would
influence
finalizing
the
rfc
and
or
creating
the
spec
right
yeah.
It's
back
before
we
ship
is
that
a
true
statement.
B
To
my
mind
I
mean,
like
I
don't
know,
I
could
be
wrong,
but
I
feel
like
the
poc
has
driven
out
like
when
I
look
at
the
rfc
I
feel
like.
Okay,
all
my
questions
are
answered,
but
without
giving
the
poc
out
for
people
to
experiment
with
you
know
there
could
be
stuff.
We
don't
know
still
unresolved.
A
Just
so
that
I'm
clear
when
you
say
give
it
out,
it
sounds
like
you're
hoping
to
have
a
decent
amount
of
testers
as
opposed
to
just
having
a
you
know
off
branch.
You
know
an
off
release
or
something
like
that,
like
you're
you're,
maybe
wanting
to
include
it
in
the
release
under
like
an
experimental
flag
or
something
like
that.
Is
that,
like
what
is
the
strategy
there?
Maybe.
B
I
don't
think
we
we
established
what
we
want,
there's
kind
of
a
couple
things
we
could
try.
I'm
sort
of
of
the
opinion
that
an
experimental
api
might
be
a
good
idea.
A
Yeah
and
then
I
think,
maybe
in
the
same
vein,
we
could
talk
about
when
we're
ready
kind
of
establishing
a
quote-unquote
task
force
to
coordinate
both
efforts
and
make
sure
that
we
do
it
in
a
reasonable
manner.
A
A
Is
that
something
vmware
is
hoping
to
assist
with,
or
are
we
kind
of
waiting
for
other
people
to
have
more
of
a
need
for
it
to
pick
it
up?.
B
A
Yeah,
so
I
I
mean
ultimately,
it
sounds
like
we're
just
gonna
wait
to
see
where
the
dr
paul
poc
goes
and
then,
if
that
blocks
something
like
this
or
sorry.
If
we
find
that.
A
The
stack
removal
is
blocking
something.
Then
we
would
put
a
little
more
focus
on
that,
but
the
builder,
the
builder
spec
and
distribution
spec,
those
are
going
out
right
like
I
am
pushing
for
that
to
go
out,
so
I
think
we'll
be
ready
there.
It's
just
again
the
implementation
part
of
it.
A
All
right
next,
we
have
implications
for
platform
of
removing
daemon
support.
A
I
think
you're
muted
one.
I
can't
hear
you,
let
me
see
there.
C
That
worked
that
worked.
Okay,
yeah
I
put
that
one
there
I
was
thinking
on.
Maybe
we
can
have
a
little
brainstorming.
C
C
Solution
we
decide
on
life
cycle
side.
I
was
thinking
on
okay.
C
If
maybe
we
can
start
on
the
implications
from
platform
perspective,
I
was
trying
to
check
the
spec,
for
example,
and
let's
see
let
me
share
here
yeah
if
I
go
here
into
this
pack,
yes-
and
I
then
search
for
demon
here
then
yeah
right
now,
I
can
see
in
the
spec
that
we
are
only
maybe
exposing
the
flag
to
deal
with
the
demon
on
platform,
side
right,
some
environment
variables
and
stuff,
and
then
some
behavior
on
what
should
what
which
you
should
expect
or
not
if
the
flack
is
enabled,
but
it
seems
that
that's
the
only
thing
we
are
mentioned
on
the
platform
specification
right
now
right.
C
So
if
I
think
on
what
we
are
planning
to
do,
and
it's
actually
delegating
responsibilities
into
the
platform
for
me,
it
looks
like
more
like
well
probably
will
we
will
require
to
mention
in
the
spec
that
now
platform
has
to
deal
with
the
demons
somehow
with
yeah
somehow,
but
I
can't
see
any
other
implications
right
now,
so
that's
more
or
less.
C
Why
I
put
these
things
because,
for
me
is
okay:
maybe
we
we
are
not
going
to
remove
the
flags
and
stuff
we
are
exposing
from
for
platform,
because
we
are
expecting
to
to
still
work
with
the
demon,
but
it's
not
going
to
be
responsibility
for
from
life
cycle
perspective.
Now
it's
the
platform
who
has
to
take
care
of
it.
So
maybe
this
is
not
going
to
change,
but
maybe
somehow
here
we
will
have
to
ask
to
put
that
behavior
on
that
responsibility.
A
I
would
definitely
I'm
gonna
kind
of
just
like
spit
out
everything.
That's
in
my
mind,
but
like
I
definitely
see
the
damon
going
away
from
the
spec
right,
like
there's
no
reason
for
the
flag
to
exist
and
be
passed
away,
because
the
life
cycle
isn't
changing
behaviors
at
that
point
in
time,
so
it
becomes
irrelevant
right
now
right
now.
The
reason
why
that
flag
is
necessary
is
because
then
it
looks
up
and
communicates
through
the
socket
right.
C
A
So
that
wouldn't
be
necessary
and
kind
of.
In
the
same
vein,
the
the
platform
is
taking
care
of
the
daemon,
but
one
of
the
things
that
I
will
say
you
mentioned
that
maybe
we
want
to
add
some
wording
that
says
that
the
platforms
will
take
care
of
the
daemon
or
something
like
that.
I
don't
think
that's
necessary
either.
Okay,
because
platforms,
only
pack
cares
about
damon
right.
Other
platforms,
most
likely
will
not
care
about
the
demons
at
all.
A
Yeah
exactly
so,
it's
like
we're,
not
gonna
tell
them
like
that.
They
should
run
linux
right
on
on
their
personal
workstations,
or
something
like
that
or
so
there's,
no
reason
why
we
should
tell
them
anything
about
the
demons.
I
would
say
that
just
the
daemon
does
not
exist
for
the
context
of
this
conversation
right
when
we're
talking
about
it
on
spec
there's
no
mention
of
damon,
because
it's
not
a
directly
supported
feature.
If
that
makes
sense,.
C
C
Then,
if
you
upgrade
and
yeah
it
will
be
that
at
issue
from
user
perspective,
we
yeah,
we
will
have
to
tell
them
something
about
it
or
no.
Maybe
if
you
are
you're
going
to
still
want
demon,
you
want
to
to
interact
with
the
demon,
then,
okay,
you
will
have
to
use
a
old
version
from
life
cycle
that
it's
going
to
do
that,
for
you.
A
There's
a
couple
like
minor
little
things
that
change,
but
at
the
in
the
great
scheme
of
things,
there's
no
operational
difference
between
daemon
and
register
yeah
people's
perspective,
and
so
what
we
are
going
to
do
is
that,
like
that,
doesn't
impact
the
user
right,
but
we're
gonna
mitigate
like
that
same
behavior,
that
they
expect
where
they
want
their
images
loaded
into
the
daemon
by
default,
for
instance
right.
So,
if
you
do
like
a
pack
build
my
app
that's
one
that
needs
to
be
loaded
into
the
daemon.
C
A
And
then
I
know
that
what
we
talked
about
was-
or
I
don't
know,
natalie.
A
We
had
a
conversation
about
how
oci
layout
is
probably
not
gonna
work
out
for
us
because
of
the
yeah.
The
desert
may
be
shocked,
but
yeah.
I
think
jesse
threw
out
a
couple
of
pretty
major
concerns,
primarily
those
that
have
to
do
with
the
docker
file,
implementation
and.
A
So
really,
if,
if
I
want
to
like
simplify
it,
if
we
do
oci
layout,
then
the
images
have
to
be
pre-existing
on
the
file
system
right
when
you
execute
lifecycle.
So
that
means
that
any
any
sort
of
like
registry,
lookups
or
anything
like
that
are
not
gonna
function
and
so
with
docker
files
and,
let's
say,
there's
an
rfc.
I
believe
that
sam
brought
up
where
the
dockerfile
has
a
from
and
that
from
becomes
the
run
image
right.
A
B
Doesn't
pack
download
the
images
first,
if
you
have
like
a
pull
policy,
is
you
know,
if
not
present?
Let's
say
pac
would
pull
your
your
images
first,
so,
like
pack
is
doing
kind
of
the
work
necessary
to
ensure
that
the
life
cycle
is
going
to
find
that
image
on
the
daemon.
If
it's
requested
right,
not.
A
Necessarily
true
right,
the
if
I'm
not
mistaken
the
life
cycle,
since
it
has
direct
connection
to
the
daemon,
can
and
maybe
already
don't
do
additional
pulling.
A
Right
because
it
could
touches
if
it's
using
imaging
tail,
it
could
do
it.
A
pull
from
that.
B
I
love
to
look
and
see
what
part
of
the
code,
because
there's
like
there's
like
a
life
cycle
library
package,
which
just
takes
an
image
until
image,
and
I
think
it
has
methods
like
okay.
Is
this
bound
right,
but
I
don't
think
there's
anything
that's
like
if
not
found,
then
pull,
but
I
have
to
look
at
the
code.
Yeah
basically,
like
my
whole,
like
this
whole
thing
that
I
brought
up
was
like
why?
B
B
A
Yes
and
no
right
so
like
let's
talk
through,
and
maybe
this
is
wrong,
but
like
dynamic,
run
image
selection,
that's
the
I
think,
the
the
maybe
the
thing
that
breaks
the
camel's
back
is
if
we
need
dynamic,
runtime
selection,
there's
no
way
for
pac
to
know
that
right
now,
right
and
so
therefore,
there's
no
way
for
pac
to
load
that
into
disk.
B
But
there's
also
no
way
for
pack
to
load
that
into
the
daemon
either
right.
That's
why
we
have
to
like
be
sure
what
the
life
cycle
does.
Maybe
maybe
it
does
do
a
pull
like
an
implicit
pull
or
something
in
which
case
like
okay,
we
set
ourselves
up
for
failure,
but
we
have
to
double
check.
Maybe
jesse
knows.
A
Yeah,
but
I
mean
true,
but
I
would
say
that,
because
you
currently
have
damon
what
is
it
called
damon
access,
you
could
theoretically
do
a
pull
right
for
that
run,
dynamic,
run
image.
B
Yeah,
well
I'm
just
kind
of
going
back
to
like
you
know.
Why
is
that
a
problem
right,
if
you,
if
you
you're,
using
docker
files
and
you're
using
runtime
like
dynamic,
runtime
image
selection,
but
you
haven't
pre-loaded
your
files
on
disk.
You
know,
then,
like
okay,
you
know
too
bad
right.
Like
I
mean
I
don't
see
why
we
have
to
abandon
the
whole
approach,
just
because
it
wouldn't
work
in
like
a
specific
scenario
that
you
know
maybe
isn't
going
to
capture
a
lot
of
people.
A
And
and
then
the
life
cycle
would
be
even
further
simplified
because
then
there
is
no
oci
component
and
it
only
operates
through
registries,
so
think
about
it.
From
that
perspective,
now
you're
like
oh
now,
there's
two
benefits
right:
okay,
let's
go
down
that
path;
instead,
right,
that's
kind
of
where
I
think,
where,
where
were
our
mindset
is
at
right?
A
Is
the
life
cycle
ends
up
only
talking
registry
and
it's
really
up
to
the
platform
to
essentially
create
a
proxy
for
that
registry
that
says:
okay,
you
know
what
I
need
this
I'll
pull
it
from
the
daemon,
push
it
to
the
daemon
so
forth,
right.
B
And
that
is
something
that
we
talked
about
with
the
like:
the
konica
work
to
support,
docker
files,
sort
of
like
a
you
know,
rather
than
build
in
all
this
logic
to
the
life
cycle.
That
knows
how
to
cache
and
retrieve
layers.
You
know
from
kanika
and
kind
of
like
do
the
translation
to
be
able
to
determine
whether
a
layer
has
already
been
created.
B
A
B
B
B
A
Yeah,
okay,
that
makes
sense.
I
think,
if
anything,
it
would
be
an
added
benefit
right,
but
there
wouldn't
be
a
conflict.
B
B
A
That
yeah,
I
think,
the
the
part
that's
really
interesting
to
me
from
a
registry
standpoint-
is
now
that
there
would
be
a
proxy
or
pac
would
create
this
proxy.
A
I
do
wonder
whether
or
not
we'll
run
into
a
challenge
where
certain
things
are
added
to
the
registry
that
may
not
be
intended
to
go
into
the
daemon
right
so,
like
think,
like
ephemeral
things
or
something
right
and
like
basically,
how
do
we
identify
those
right?
How
do
we
identify
like?
Oh
it
actually
wanted
this
image
to
go
there.
So
therefore,
we're
gonna
like
actually
take
that
image
and
put
it
into
the
daemon
versus
like
this
other
image
that
was
created.
A
Yeah
thinking
about
ephemeral
builders,
thinking
about
you
know
if
let's
say
that
the
life
cycle
somehow
chooses
to
use
the
same
registry,
which
actually
wouldn't
make
sense,
because
I
wouldn't
know
if
it's
an
ephemeral
proxy
registry
or
if
it's
like
gcr
right,
like
I'm,
pretty
sure
you
don't
want
to
do
that
with
gcr.
A
Then
the
other
challenge
I
think
juan
captured
from
jesse,
was
that
something
to
do
with
networking
in
security
right.
So
very
you
know
the
the
simple
answer
that
I
could
think
of,
or
the
simple
challenge
I
could
think
of
is
making
sure
that
the
life
cycle
has
access
to
the
registry
via
networking.
A
And
so
you
know
we
there's
a
there's
some
networking
limitations,
or
sometimes
it
can
be
a
little
bit
challenging
between
mac,
os
or
docker
desktop
and
linux
specifically,
and
so
I
think
we
want
to
do
a
poc
first
to
make
sure
that
we're
not
gonna
run
into
anything
unexpected
there,
because
pac
does
already
muck
around
with
network
a
little
bit,
and
so
there
might
be
competing.
A
Options
or
challenges
yeah
so
impact
you
could
specify
network
and
you
can
say
like
network
none
right
and
then
we
actually
start
the
container
with
no
network,
and
if
that
is
so,
how
is
it
they're
going
to
reach
the
proxy
registry
right
so
little?
Things
like
that,
you
know,
but
I'm
sure
we
could
solve
those.
B
A
C
C
Then
yeah
probably
get
more
details
about
it,
but
what
I
don't
want
to
do
is
add
more
details,
maybe
to
the
oci
layout,
and
probably
it's
going
to
be.
You
know
this
car,
so
it
makes
no
sense
to
invest
more
time
on
it.
Yeah.
A
Yeah
I
mean,
I
think,
it'd
be
nice
to
know
natalie
whether
the
life
cycle
does
a
daemon
pull,
because
I
think
that
would
help
at
least.
A
All
right,
so
it
sounds
like
we're
gonna
discuss
some
of
this
in
working
group
as
well.
Is
that
what
you're
thinking
one.