►
From YouTube: Platform Sync: 2021-01-06
Description
Meeting notes: https://bit.ly/38pal2Z
A
A
A
B
C
A
C
C
About
this
morning,
I
need
a
need
to
talk
to
joe
it's
just
the
two
of
us,
so
it's
you
know,
obviously
a
lot
easier
to
communicate,
but
if
there's
other
people
maybe
interested
in
just
having
broader,
more
inclusive
discussions,
it
sounds
like
it
would
probably
be
a
good
thing.
I
imagine
I
just
need
to
sync
up
with
joe
and
see
what
his
thoughts
are
and
also
just
from
a
salesforce
side
of
things.
C
I'm
actually
going
to
be
switching
roles,
so
there's
going
to
be
some
disruption
momentarily
with
that,
as
joe
is
also,
I
think,
switching
some
roles
on
his
end
as
well,
but
I
think
once
things
settle,
he
and
I
will
sit
down
and
have
a
discussion
and
think
about
what
makes
sense
for
that.
But
if
you
have
any
inputs
or
thoughts
too
yeah,
let
me
know.
C
A
B
B
So
the
first
is
there's
two
open
pr's
that
you
know
I'm
debating
whether
to
or
not
to
pull
in
or
wait
for
the
you
know
hold
the
release
on
the
first
is
dan
has
a
pr
about
pushing
cash
images.
We
had
a
kind
of
long
discussion,
internal
discussion
today
about
trying
to
dig.
It
seemed
like
there
were
some
weird
like
504,
like
issues
that
we
were
getting,
probably
because
when
we
create
these
cache
images
for
like
for
java,
so
the
m2
cache
is
like
the
maven.
B
Cache
is
massive
and
it
seems
like
we
don't
in
the
life
cycle.
We
don't
do
like
good
chunking
of
or
we
don't
really
chunk
the
requests.
So
it
just
tries
sending
this
massive
blob
and
if
you
don't
have
a
great
network
connection
like
I
do,
meaning
I
don't
have
one
then
it
will.
It
will
cause
some
issues,
but
it
works
with
gcr
and
it
works
with
some
other
cases
so,
and
the
code
seems
correct,
so
we
were
leaning
towards
pulling
that
in
for
this
release.
B
As
long
as
you
know,
just
I
don't
know
if
whether
or
not
we
want
to
publicize
it
so
intensely
if
one
of
the
main,
if
still
the
standard
registry
people
use,
is
docker.
So
I
don't
know
if,
if
it's
like
something
we'd
want
to
we'd
want
to
publish
especially
widely
until
we're
more
confident
that
it
would
work
for
everybody's
use
case.
But
I'm
wondering
what
people
think
about
that.
A
If
I
recall
correctly,
the
image
cache
situation
comes
more
or
less
from,
I
guess:
cicd
solutions
right,
people
that
are
using
pack
and
ci
cd
solutions
and
in
most
cases
they
either
have
their
own
registry
or
they're,
using
maybe
even
ggcr
or
gcr.
Sorry,
I
haven't
heard
of
a
lot
of
them
using
docker
hub
right,
especially
now,
with
the
rate
limiting
and
a
whole
bunch
of
other
stuff.
A
So
I
feel
kind
of
comfortable
going
through
with
that
direction
and
even
publicizing
it
would
be
good
and
then
I
know
we
talked
about
potentially
making
a
blog
post
for
it
and
then
just
being
kind
of
maybe
explicit
in
that
blog
post.
That
dr
hub
currently
has
a
limitation
in
which
bigger
layers
might
be
an
issue.
D
B
Probably
should
okay,
so
we
should
keep
in
mind
some
validation
for
that
the
seconds
there's
there's
like
a
drafts,
pr
from
one
of
the
people
associated
with
red
hat
and
and
padman
making
some
changes
for
docker
host.
I'm
a
bit
nervous
to
pull
this
in,
especially
because
I
asked
micah
to
to
check
into
it,
because
I
know
he
interacts
a
lot
with
setting
different
docker
hosts
and
he
had
some
reservations
all
like
it
seemed
like
about
it.
A
B
B
B
We
were
trying
and
javier-
and
I
kind
of
had
some
discussion
on
the
issue,
trying
to
figure
out
what
actually
looks
like
a
good
ux.
What
makes
sense,
I
kind
of
feel
like
it's
fine
to
you
know,
to
defer.
Also,
for
you
know,
defer
the
question
for
now
and
see
what
people
think,
but
I
wanted
to
see
whether
anybody
else
had
any
strong
feelings
on
that.
A
A
B
Yeah
exactly
anyways
we're
not.
We
may
be
printing
warning
signs,
but
we're
not
actually
deprecating
any
like
fully
deprecating
any
old
commands.
So
everybody
like
there's
no
major
changes
that
need
to
be
made
also
because
you
want
to
get
feedback
and
see
whether
people
are
happy
with
it
or
hate
it.
So
the
last
thing
is,
I
guess,
in
that
case
I'll,
probably
try
and
pull
the
push
and
cache
images
pr
in
and
then
we
should
get
around
to
cutting
a
release
branch
and
I'm
doing
some
something
of
ccb.
D
A
A
A
B
A
C
There
was
an
issue
recently,
maybe
on
the
life
cycle,
where
someone
asked
a
similar
question
about
where,
where
are
these
environment
variables
set
and
emily
explained
that
that
the
launcher
is
responsible
for
setting
them
so
that
the
actual
container
config
doesn't
have
them?
I
think
think
the
resolution
was
you
know
like
this
is
the
this
is
the
approach
that
we've
taken
right,
like
there's
reasons
why
it's
not
said
on
the
image
itself,
but
I
don't
know
if
that's
relevant
here.
A
Yeah-
and
I
would
think
that
that's
true,
because
some
of
it
has
to
do
with
what
is
it
the
process
type
right
so
like
each
process
type,
has
its
own
set
of
environment
variables,
something
that
I
know
we've
looked
at
in
the
past
unless
we're
talking
about
now
quote-unquote
global
environment
variables.
But
that
would
be
something
up
for
discussion
via
rfc.
D
I
do
wonder
if,
like
pack
build-
and
I
think,
like
I
said-
you've
seen
confusion
with
this
before,
but
I'd
hate
to
add
the
word
build
to
it.
But
I
almost
want
it
to
say
build
ins
right
so
that
you
know
that
it's
only
for
the
build
and
it's
not
going
to
be
part
of
the
runtime
image
unless
the
buildpack
does
it.
But
I
don't
know
it's
already
under
the
build
subcommand.
A
A
Pivotal:
what's
that
cool
all
right,
so
any
other
relatively
new
ones,
that
we
should
talk
about
enterprise
proxies?
I
think
we've
already
talked
about
this
I'll,
follow
up
on
this
and
kind
of
say
that
we
are
likely
to
move
forward
with
this
and
david,
maybe
I'll,
just
kind
of
get
with
you
and
and
make
sure
that
that
makes
sense
as
well.
D
A
A
A
It's
all
new
files-
and
you
know
furthermore
like
if
it's
a
small
change
it
requires
that
we
release
a
whole
new
version
right
for
every
small
change
and
that's
something
that
I'd
hate
to
do
and
instead
add
more
value
per
release,
and
so
what
I'm
thinking
about
is
creating
a
development
workflow
that
actually
uses
the
tecton
integration
repo
and
we
could
kind
of
point
to
it
from
the
catalog
that
all
development
happens
here
and
then
we
kind
of
do
something
similar.
Where
we'll
create.
A
The
other
thing
that
this
would
allow
us
to
do
is
add,
tooling,
for
better
end-to-end
testing
across
different
platforms
or
different
kate
distributions,
so
things
like
kind,
open
shift
and
gke
are
things
that
we
could
do
within
this
repo.
So
I
wanted
to
mention
that,
and
so
it
doesn't
surprise
anybody
and
if
you
have
any
questions,
comments
or
concerns.
Let
me.
A
D
D
I,
like
all
the
url,
parsing
and
figuring
out
what
kind
of
locator
it
is,
which
is
really
cool
to
see
kind
of
looking
at
the
pack
code
and
getting
familiar
with
that.
So
I
might
have
some
questions
around
like
some
of
this
because
we'd
like
to
leverage
you
know
as
much
as
possible
as
far
as
like
you
know,
detecting
these
urns
the
same
way
so
that
someone
can
build
and
pack
and
then
build
on
our
platform
without
having
to
you
know,
run
into
gotchas
between
the
two
platforms.
D
D
A
You
know,
go
library
mechanism
right
where
anybody
that
is
writing
a
go
program
could
leverage
but
then,
at
the
same
time,
instead
of
just
having
pac
like
actually
have
like
other
tools
that
are
a
subset
of
pack
right
and
in
this
case
something
like
I
don't
know
like
downloader
right,
I
don't
I'm
just
making
stuff
up
right
or
or
platform
youtube
package
locator
or
something
right.
Yeah,
yeah.
A
So
if,
if
we
were
to
do
that,
I
think
we
could
provide
better
flexibility
but
at
the
same
time
remove
a
lot
of
the
burden
of
trying
to
like
create
separate
repos
for
everything
or
and
then
having
to
maintain
like
an
upstream
workflow,
like
you
know,
kind
of
it's
a
little
painful
to
update
stuff
in
image.
Util
right
now
right
and
then
have
to
like
walk
it
down
to
get
that
implementation
back
in
because.
D
Yeah
we've
already
sort
of
had
to
you
know,
even
though
pack
processes
the
project
descriptor
we're
having
to
do
the
same
thing,
because
we
need
to
emit
an
order
tunnel,
but
pax
already
sort
of
doing
that.
But
it's
doing
it
sort
of
on
the
fly
when
it
talks
to
life
cycle
right,
but
they
both
have.
You
know
if
they
both
produced
an
order.
D
You
know
tommel
struck
of
some
sort
and
one
writes
it,
and
one
doesn't
or
something
like
yeah,
like
you
said
these
little
utilities
to
like
process
a
project,
descriptor
or
process
and
order
or
whatever
you
know,
download
build
packs
like
that.
Those
would
be
some
utility
functions
would
be
super
useful.
D
C
D
D
C
B
Right,
I
wanna,
do
you
think
we
should?
If
we
do
that,
do
you
think
you
know
there
was
there?
Was
that
request
export
the
archive
package?
And
you
know
now
there's
some
pushback
from
image.
You
tell
them
like.
We
never
really
got
around
to
finishing
that
we
could
at
the
moment
you
know,
move
that
into
a
package,
at
least
so
that
someone
can
consume
it
still
right.
A
D
That's
more
or
less
that
you're
gonna
stop
good
yeah,
exactly
like
like
first
step
would
at
least
be
making
these
packages
and
yeah
you
might
have
to
wrap
them
in
your
own.
Go
for
now,
but
being
able
to
have
like
a
downloader
would
be.
You
know
useful
for
all
platforms.
So
you
just
don't
you
know
you
can
just
bump
the
builder
version
right
or
something
and
to
suddenly
support
the
new
urls.
That
pack
is
supporting
or
something
one
day.