►
From YouTube: Implementations Sync: 2021-04-01
Description
Meeting notes: https://bit.ly/38pal2Z
A
A
A
For
everyone
who
wasn't
following
in
the
channel
yesterday,
there
was
a
bug
with
the
0110
version
of
the
lifecycle,
specifically
on
gcp,
we
had
tried
to
pull
in
node-based
identity,
using
the
ggcr,
no
client
key
trend,
but
apparently
there's
an
issue
and
it
can't
talk
to
the
metadata
server.
It
hangs.
A
I
followed
some
of
those
links
that
jesse
provided
and
it
seems
like
the
fix
for
that
is
probably
queued
up
behind
a
big
refactor
of
credential
provisioning
in
kubernetes
in
general,
they're,
like
moving
to
an
external
credential
provider,
plug-in
model
and
based
on
other
issues,
it
seems
like
they
probably
aren't
making
changes
in
the
current
implementation.
So
I
probably
can't
pull
this
back
in.
A
C
Know
they
reopened
the
issue.
The
at
least.
B
B
B
E
So
just
so
I'm
clear
because
I
can
ping
the
right
people
around
this.
This
happens
for
builds
being
done
on
gcp,
or
does
this
happen
outside
of
gcp.
B
C
Let
me
check,
let
me
it
was
kind
of
ad
hoc
yesterday.
So
probably
not
that's.
C
Yeah,
the
stuff
that
was
copied
from
like
the
cage,
keychain
stuff
mentions
that
that's
possibility,
but
it
has
there's
some
amount
of
code
for
timing
out
and
things
like
that,
but
clearly
it
must
always
hit
yeah
anyway
yeah.
In
our
case,
we're
doing
this
was
like
local
life
cycle.
Just
happened
to
be
on
a
google
vm,
and
that
was
unfortunate
because
they
weren't
actually
trying
to
use
the
node-based
identity.
C
It's
just
supposed
to
kind
of
be
a
fallback
if
everything
else
fails,
but
the
not
being
there
caused
a
cascade
of
just
you
know
hanging
and
nothing
ever
working.
So,
okay.
A
That
makes
sense,
I
feel,
like
everyone's
been
working
on
the
release.
Who's
been
working
in
the
life
cycle.
Delinquents,
like
me,
have
been
like
working
on
other
things.
So
next
up
standing
item,
release
planning,
I'm
gonna.
Guess
there
isn't
a
lot
to
talk
about
here,
because
we're
just
starting
to
plan
the
release
with
the
next
apis.
Have
we
even
created
a
milestone
for
it
yet
seems
like
we
have
yeah.
A
So
we
probably
shouldn't
be
adding
adding
more
things
there,
because,
even
though
this
is
a
short
list
compared
to
other
releases,
some
of
these
are
really
big
items.
There.
F
F
Actually
you
know,
I
think
we
had
said,
there's
only
value
in
that
if
people
consume
them,
I
think
at
least
on
the
pacquiao
side.
We
have
some
interest
in
taking
an
rc
binary
and
putting
it
in
a
some
sort
of
pipeline.
So
I
don't
know
if
that's
something
that
the
other
you
know
builder
producers
would
like
to
do,
but
at
the
very
least
I
think
that
would
have
helped
us
yesterday.
So
this
might
be
something
to
explore.
A
G
G
But
I
do
want
to
say
that
from
pac's
perspective
at
least
maybe
the
platform
team
perspective,
we
do
have
interest
in
having
an
rc
for
the
life
cycle,
because
if
we
want
to
get
a
little
bit
closer
to
the
same,
you
know-
let's
say
api
version-
that's
about
to
be
released.
It
would
be
nice
to
have
a
release
candidate
that
we
could
start
working
with
as
opposed
to
having
to
build
everything
by
hand
right.
G
G
G
That's
a
really
good
question.
I
think
right
now,
pax
specifically
holds
off
on
updating
the
lifecycle.
The
default
lifecycle
version
upon
release
just
to
make
sure
that
things
kind
of
settle
down
before
it
becomes
default
for
everybody.
As
a
builder,
I
don't
know
that
we
would
push
too
hard
to
try
to
get
things
integrated
much
faster,
but
I
think
what
it
allows
us
to
do
is
it
enables
us
to
be
able
to
do
it
if
we
wanted
to
right.
E
B
A
F
E
Or
even
like
the
the
label
on
the
image
that
could
be
evenly
consumed,.
F
G
As
I
say,
I
definitely
think
you
could
enable
nightly's
right
by
tagging
a
nightly
thing
like
on
everything
that
just
gets
produced,
and
you
know
to
the
point
where
we
there
are.
I
guess
artifacts
attached
to
the
actions
they're
really
hard
to
access
for
one,
but
I
would
also
say
that
the
rcs
is
is
something
a
little
bit
more
than
that
right,
like
a
nightly
like
from
a
consumer's
perspective.
I
don't
know
what
the
status
of
a
nightly
is
right.
G
I
don't
know
if
there's
some
major
issues
to
it,
I
don't
know
if
the
api
is
completely
implemented,
and
so
that's
why
I
think
the
idea
of
an
rc
sets
that,
like
literally
like
the
milestone
right
or
the
goal
post
that
says
this
is
now
an
attempt
of
something
being
complete.
So
you
could
start
working
with
it.
Not
least,
I
don't
think
at
least
for
us
would
be
as
useful
as
rcs.
A
Especially
because
the
apis
are
atomic
in
some
ways,
so
when
we're
between
releases,
you
might
say
you're
using
api
07,
but
you
really
only
have
half
of
the
spec
features
in
there
and
you
don't
know
exactly
which
ones.
So,
unless
we
did
something
more
formal
with
half
implemented
apis,
it
could
be
a
little
bit
confusing
to
people.
C
Yeah,
I
still
think
it
would
be
nice
to
always
produce
images
that
are
tagged
even
if
they're
you
know
get
get
tagged
as
well
as
like
nightly,
even
if
it's
not
something
we
expect
most
folks
to
use,
and
especially
on
pr's
as
well.
But
I
think
this
ties
back
into
pack
builder
tunnel
needing
to
let
you
use
an
image
instead
of
a
tar
as
well,
because
right
now,
gonna
have
a
mismatch.
C
E
I
wanted
to
talk
about
rc073,
but
the
asset
cache,
because
I
was
going
to
bring
something
into
the
gcp
build
packs
to
do
caching
using
a
local
volume
with
a
readable
volume,
so
I've
been
meaning
to
go
and
find
out
what's
happening
with
this.
I
have
to
see
if
I
can
contribute,
because
I
would
let
me
throw
away
some
code.
A
Nice,
I
think,
from
the
this
rfc
in
a
lot
of
ways,
is
about
how
you
package,
like
vendor
dependencies
into
an
offline,
build
pack.
A
The
life
cycle's
role
in
this
is
mostly
gonna,
be
around
passing
an
environment
variable
through
to
the
buildbacks
like
most
of
the
work
is
build
packs
knowing
to
pull
things
out
of
this
artifact
cache.
So
I
think,
on
the
lifecycle
side,
this
is
pretty
simple.
A
I
have
had
one
idea
that
I
haven't
found
the
right
forum
to
ask
yet,
but
I've
been
wondering
if
even
for
online
build
packs
like
right
now
we
have
a
cache,
that's
per
image
in
a
kind
of
awkward
way.
That
leads
to
a
lot
of
re-downloading
of
things,
but
we
have
some
concerns
around
cash
poisoning
between
builds.
I
was
wondering
if
it
made
sense
to
have
a
shared
asset.
Cash
across
all
builds
so
like
in
a
case
as
a
volume.
A
So
in
a
case
where
your
builder
did
not
have
an
asset
cash
built
into
it,
we
would
mount
asset
cash
volume
and
then
in
different
builds.
Bill
packs
could
contribute
their
assets
to
the
cash.
E
So
that's
what
I've
been
pledging
for,
gcp
bill
packs
and
I
was
going
to
hook
it
into
scaffold
because
that's
our
our
big
concern
is
that
we
use
scaffold
from
our
cloud
code.
Products
and
people
hit
repeated
downloads
if
they're,
building
across
different
images
and
so
we're
gonna
mount
a
readable
volume.
That's
maintained
within
scaffold
and
then
our
build
packs
noted
that
we'll
look
to
see
if
that
volume
exists
and
if
so,
we'll
download
the
artifacts
in
there.
If
they're
not
already
present.
B
A
A
In
the
builder
image
right
because
we're
imagining
some
builder
images
would
come
with
an
asset
cache
pre-populated,
but
maybe
it
could
be
partially
populated,
like
my
idea
of
mounting
the
volume
when
it's
not
there
works
really
well,
if
it's
either
100
populated
or
totally
empty.
I
don't
know
how
well
it
works
if
you're
trying
to
like,
I
don't
think,
there's
some
way
to
have
a
weird
overlay
where
things
that
aren't
there
end
up
on
the
volume,
like,
maybe
that's
possible,
but
I
I
don't
think
so.
E
D
D
You
know
these
two
images
are
associated
with
each
other
and
all
the
code
in
each
of
those
two
things
can
trust
each
other.
But
this
external
thing
can't
and
that's
come
up.
We've
had
like,
I
know
three,
two
or
three
rfcs
that
it
tried
to
solve
that
problem.
This
this
asset
cash
thing
is,
is
a
cash
that
is
immutable
during
the
build
process.
Build
process
can't
as
it's
defined
now
can't
contribute
to
it
at
all.
It's
just
a
way
for
build
packs
to
be
distributed
with
dependencies.
D
If
that
makes
sense
for
air
gap
builds,
and
things
like
that,
so
that
you
know
if
a
platform
wants
to
say:
okay,
I'm
I'm
going
to
provide
the
build
pack
with
every
every
possible
dependency.
So
everything
is
super
fast
and
can
happen
without
internet
at
all.
Right
like
in
a
cluster,
that's
disconnected,
then
you
know
that
that's
kind
of
what
this
enables
if
we're
talking
about
something
that
the
build
process
can
affect
that
works
across
multiple
images.
D
If
everything's
checking
checksums
that
you
know,
two
images
aren't
owned
by
the
same
tenant
for
every
reason
or
if
one
has
a
untrusted
build
pack
and
the
other
is
all
trusted,
build
packs
or
something
like
that,
then
you
know
the
caching
proxy
can
sit
outside
and
ensure
that
it's
you
know
it's
fast
and
you
know
there's
more
validation
in
that
process,
but
I'm
hesitant
to
introduce
like
a
volume.
That's
shared
between
you
know,
builds
of
different
images.
Those.
E
I
should
back
off
and
say
I
have
not
read
these
documents
in
in
great
detail.
So,
okay,
interesting
for
us,
we
have
we're
dealing
with
kind
of
micro
service
applications.
So
we
have
you
know
two
three,
four
images
and
generally
they're
they're,
not
polyglot,
so
people
will
be
using
like
java
images
java
for
all
four
images.
So
we
end
up
downloading
like
the
jdk
four
times
and
that's
painful,
it's
a
real
put
off
for
people.
So
that's
what
that's!
What
we're
looking
to
try
to
improve.
A
D
I
I'd
be
very
hesitant
to
introduce,
even
if
bill
pecks
could
check
the
checksums,
because
people
can
write
code
that
hooks
into
build
packs
in
their
application
directory.
That
could
ignore
those
check
sums
because
you
know
in
the
end,
like
you
know,
the
build
packs
sit
closer
to
the
developer
right
than
the
platform
components.
I'd
suggest
that
if
we're
going
to
introduce
a
cache,
that's
less
safe
than
the
one
we're
talking
about
here,
but
that's
fine,
but
it
should
be
more
explicit,
maybe
separate
from
that.
D
You
know
asset
caching,
like
you
know
where
you're
talking
about
something
that
was
cached
a
long
time
ago.
Right
when
I
think
of
asset
caching,
I
think
of
like
you
know,
a
web
server
and
you've
pre-compiled
assets
ahead
of
time
right
and
they're
being
distributed
down,
not
a
cache.
That's
like
per
request.
Something
gets
cached
on
the
web
server
right.
D
So
to
me,
the
intent
of
this
was
very
much
cash
ahead
of
time,
not
not
cash.
You
know
during
the
build
process
itself,
if
that
makes
sense,
but
not
not
saying
we
shouldn't
also
solve
that
problem.
I
would
just
be
really
hesitant
to
pull
that
a
cash
that's
writable
during
the
build
process
into
this.
This
particular
thing,
unless
everybody
thinks
I'm
crazy,
if
that
makes
sense.
A
G
I'm
gonna
throw
my
bike
shetty
type
of
conversation
with
this,
but
I
hate
the
term
cash
being
used
here
right
where
I
think
I've
already
mentioned
a
couple
times.
We
should
just
use
packages
because
I
think
cash
does
make.
It
seem
like
it's
mutable
right
and
not
just
the
way
that
assets
are
packaged
and
distributed,
which
is
technically
what's
been
what's
happening
here.
D
A
D
It
might
be
easy
to
implement
that
asset
cash
structure
as
a
build
pack
right
using
the
three
levels:
the
image
local
cache,
the
cross
image
cache
and
the
assets
right
like.
I
wonder
if
that's
something
that
could
be
created
in
code
at
the
build
pack
level
or
you
know,
there's
there's
something
we
could
do
to
still
have
that
separation
of
concerns,
but
present
an
interface
to
the
buildpack
author
app
developer,
that
they
are
more
unified
right,
like
yeah.
A
Even
before
we
do
a
nice
unified
thing
just
if
we
had
that
third
one,
the
cross
image
cache,
I
think
yeah
it'd
be
a
big
deal
and
I
think
we
need
to
spec
it
out
so
that
buildbacks,
you
don't
know
how
to
use
it.
You
could
probably
do
something
bespoke
with
pack
and
the
volume
flag
and
a
bunch
of
build
packs
who
are
all
have
an
implicit
contract,
but
it's
not
gonna.
A
A
F
A
C
Yeah,
it
needs
discussion,
natalie
you're,
saying,
support,
stackpacks
needs
discussion
on
how
to
break
this
up
into
smaller
chunks
of
work.
I
agree
that
is
something
we
want
to
do.
Do
we
want
to
discuss
that
today
or
do
we
want
to
set
aside
some
time
for
that.
F
F
G
Yeah,
I
have
just
a
tad
bit
of
context
more
or
less
I'm
coming
at
it
from
a
very
different
point
of
view,
and
I
added
it
to
the
agenda
to
talk
about,
but
I
could
definitely
start
right
now,
if
that's
okay,
sure
cool,
so
one
of
the
things
I've
been
working
through
is
eric
from
bloomberg.
G
Is
or
created
a
proof
of
concept
for
how
build
kit
could
or
yeah
a
build
kit
front-end
for
how
cloud-native
build
packs
could
be
integrated
or
incorporated
there,
and
one
of
the
things
that
came
out
is
that
the
the
export
function
is
the
only
function
that
needs
to
be
re-implemented
for
build
kit,
and
the
reason
for
that
is
because
currently
the
exporter
has
two
ways
of
exporting
an
image
right.
G
It's
exporting
them
into
the
registry
and
therefore
it
needs
like
credentials
to
be
able
to
do
that
or
it's
exporting
them
to
the
daemon,
and
then
it
needs
access
to
that
daemon
right,
whether
it
be
through
tcp
or
through
the
socket.
G
So
my
initial
thought
was
just
like
hey,
you
know
we
could
use
the
oci
layout
format
right.
This
is
a
format.
That's
kind
of
already
been
specced
out,
one
that
we
use
for
build
packages,
and
so
thereby,
if
the.
G
If
the
exporter
could
export
to
an
oci
layout
format,
then
the
export
function
of
build
kit
could
essentially
just
take
whatever
the
output
was
and
translate
it
over
to
llb,
which
is
like
the
mechanism
necessary
to
be
able
to
write.
This
image
within
the
docker
daemon
context
right
with
that
being
said,
I
don't
think
it's
linked
on
there.
G
Let
me
see
actually
yeah,
it
is
so
if
you
go
down
see
that
link
at
the
bottom,
the
investigate
build
kit
front
end
eric
replied
to
it
towards
the
end.
The
second
to
last
comment
and
he's
kind
of
bringing
up
a
good
point
that
I
hadn't
really
thought
about,
but
it
does
seem
weird
that
the
exporter
maybe
has
like
too
much
of
a
responsibility
where
it's
again
kind
of
talking
about
a
daemon
case.
G
It's
talking
about
image,
writing
and
then
it's
now
going
to
potentially
talk
about
oci
layout
format,
and
so
it
seems
like
the
interface
isn't
quite
as
broken
apart
as
it
could
be.
So
I
think
the
proposal
that
eric
is
bringing
up
is
that
we
should
find
out
what
this
interface
should
be,
and
then
just
have
that
be
like
the
final
exported
mechanism.
D
I
think
the
reason
exporter
is
so
integrated
partially
is
because
it
like
there
are
a
bunch
of
interfaces
that
exist
that
are
like
write
the
oci
image
to
disk,
exactly
as
it
is,
or
even
like
write
a
partial,
oci
image
and
put
that
to
a
registry,
but
because
we're
selectively
creating
and
not
creating
some
layers.
It
was
efficient
at
the
time
it
was
written
to
integrate
that
api
and
the
creation
of
the
tar
balls
when
necessary-
or
you
know
like
I
would
love
to
split
those
apart.
D
I
just
wanted
to
say
that,
if
it's
possible
to
do
that,
create
different
apis
and
even
spec
them
differently.
Sorry
to
interrupt.
I
I
gotta
drop
for
the
next
thing,
but
I
just
wanted
to
support
that
effort.
If.
C
B
G
Definitely
don't
know
the
limitations
right.
I
think
that's
what
warrants
a
little
bit
more
investigation
and
thought
right
yeah,
but
it
definitely
sounds
like
something
worth
investigating.
C
G
Like
I
mean
ultimately
right,
what's
going
to
be
the
next
interface
that
we're
going
to
have
to
integrate
with,
you
know,
to
be
able
to
do
something
right
so
like
in
this
case,
build
kids
is
up
and
coming
and
there's
no
way
to
integrate
it
as
of
right
now,
right
and
so
again,
like
I
don't
know
something
comes
up
within
the
mobi
project
that
then
we
someone
else
wants
to
integrate.
C
Yep
that
makes
sense
to
me.
I
like
the
idea
of
having
you
know
one
or
two
formats
that
we
export
from
you
know,
depending
on
what
we
need
to
support.
One
might
be
registry
just
because
of
efficiency,
but
it
would
be
nice
to
be
able
to
drop
the
damon
and
have
pac
do
that
business
and
also
you
know,
build
kit
same
thing.
That
makes
sense
to
me
just
from
an
architecturally.
B
G
Yep
so
yeah,
I'm
not
entirely
sure
who
should
do
that
investigation.
I
know
I'm
kind
of
looking
at
it
more
from
the
outside
in
right,
bringing
up
ideas
and
really
doing
more
of
the
ux
perspective.
I
don't
know
if
emily
has
it
on
her
plate
to
look
at
this
proof
of
concept,
but
it'd
be
great.
If
maybe
we
could
get
other
eyes
on
it
as
well.
C
That
would
be
great.
I
have
a
lot
of
interest
in
build
kit
integration,
but
just
not
a
lot
of
time
right
now,
but
but
yeah.
Hopefully
we
can
get
on
our
radar.
That
would
be
great
I'll
leave
this
in
meets
discussion,
because
I
do
think
we
should
create
some
issues-
maybe
not
in
this
milestone
or
maybe
in
this
milestone,
because
at
least
doing
a
tar
sounds
reasonably
simple
enough
and
would
unlock
the
potential
to.
E
C
C
All
right,
I
have
some
bins
here.
Does
anyone
have
any
context
on
additional
layer,
metadata
images.
G
I
think
I
had
some.
I
think
what
he's
talking
about
right
is
the
command
where
you
see
on
the
second
screenshot.
The
command
area
is
completely
missing,
and
I
know
that
this
has
been
discussed
a
couple
times
that
it'd
be
great
to
put
something
there
that
at
least
describes
from
a
high
level
like
what
it
was
that
happened
in
this
particular
layer.
G
Right
like
why
this
layer
exists
essentially-
and
I
think,
the
further
down
the
path
there
were
a
couple
discussions
about
like
potential
options-
yeah,
I
think
the
last
one
or
that
there
were
at
least
two
or
three
different
formats,
and
it
would
just
be
great
to
see
what
the
interest
is
and
then
maybe
an
rfc
to
get
this
included.
C
Yeah,
that
sounds
great
yeah.
I
think
I'm
also
not
particularly
keen
on
json
just
seeing
the
the
result
here
like.
I
think
it
would
be
more
useful
for
just
readability
just
at
a
glance,
but
because
anything
else,
you're
probably
gonna-
want
to
pull.
C
Yeah,
I
guess:
how
do
we
get
this?
This
would
require
what
this
required.
Rc.
Probably
right,
changes
the
resulting
image.
G
Yeah,
I
would
think
so
right.
It
would
be
a
life
cycle
implementation
detail.
So
therefore
we
probably
want
to
spec
it
out
so
that
there's
some
consistency
in
expectation
to
the
output.
C
Yeah,
I
don't
know
if
someone
wants
to
drive
that
if,
if
no
one
responds
I
can
take.
G
You
could
probably
update
the
the
what
is
it
called
the
label
on
this.
C
C
All
right,
the
next
thing
on
the
agenda
is
review
road
map,
which
is
not
something
we
do
all
the
time.
So
I
don't
think
we
have
have
to
do
that
today.
There
are
what
20
minutes
left.
Does
anyone
have
anything?
The
agenda
was
exported
strategy,
whichever
you
already
discussed
on
here.
So
if.
C
I
know
it
was
brought
up
yesterday
in
the
talking
about
arm
and
specifically
what
we
need
to
push
that
forward.
C
I
don't
have
anything
extra
to
add
there
probably
worth
watching
recording
if
you
didn't,
and
you
have
some
interest
in
and
pushing
that
forward,
but
it
sounds
like
there
is
some
interest
in
having
that
sooner
than
later.
So.
B
C
G
Yeah,
I
think
personally,
for
me
what's
unclear,
is
the
combination
of
the
different
pieces
and
what
it
means
to
support
arm
right
like
is
it
generating
an
arm
image
you
know
through,
like
64
or
whatever
other.
You
know,
x86
build
packs,
or
is
it
everything
from
you
know,
pac
to
life
cycle,
to
the
build
packs
to
the
oci
image,
all
you
know
being
armed
64.,
that's
what's
still
really
unclear
to
me
like
at
what
level
do
we
actually
differentiate?
What's
the
most
common
or
desired
combination
of
all
these
tools
to
be
unarmed,
yeah.
C
I
think
the
desire
is
what
I'm
looking
for
as
well
like.
I
assume
we'll
eventually
get
there
for
all
of
it,
but
I
don't
know
what
needs
to
happen
first,
like
I'm,
not
sure
what
folks
are
really
after
yeah,
you
know.
Are
they
trying
to
build
a
builder
that
is
fully
armed
and
producing
arm
images,
or
are
they
just
or
where
they
like
to
just
produce
arm
from
build
packs
that
run
on
x86
builder.
G
B
C
G
B
D
G
B
Support
all
the
configuration
like
running
tech
on
m1,
but
providing
linux
like
image
or
like
doing
everything
on
m1
engines,
yeah.
G
Does
this
work
no
what's
necessary
to
make
this
work
right
and
like
basically
having
this
matrix
to
really
comprehend,
where
we're
at
right
now
with
support
and
where
how
we
would
be
able
to
get
to
all
green
right,
which
I
I
do
agree.
We
want
to
get
to
all
green,
but
there
might
be
some
very
like
easy
things
to
do
versus
some
very
complex
things
to
do.
B
B
Me
add
that
to
the
to
the
notes
here
I
don't.