►
From YouTube: Platform Sync: 2020-09-16
Description
* Status Updates
* Release Planning
* Automate creating GHA Windows-LCOW runner (ci#21)
* WCOW - pushing it back to GitHub
* pack 0.14.0 (discussion needed)
A
A
A
A
B
I
was
going
to
mention
that
we
had
a
long-running
pr
open
that
had
been
kind
of
stalled
because
we
were
unable
to
get
the
some
of
the
tests
to
be
added
to
pass
on
the
github
actions.
Runner
that's
been
fixed,
but
it
did
require
some
production
code
changes.
But
I
will
open
up
the
pr
I'll
bump
the
pr
again,
but
that's
almost
in
a
ready
to
review
state.
A
B
A
D
I
was,
I
was
gonna
say
I
was
trying
to
find
the
zoom
thing
which
totally
disappeared
in
my
computer.
But
I
was
spent
this
week
working
on
a
rfc
for
builders
trying
to
define
exactly
what
is
present
on
builders
and
diving
into
some
of
the
differences
between
heroku
and
paquito.
And
I
don't
really
look
at
clothes.
But
there
is
as
well,
and
that
is
up,
feel
free
to
check
that.
A
There
are
a
couple
items
that
we
probably
could
add
to
the
agenda
to
discuss
that
we
skipped
over
from
last
week.
I
think
david.
Some
of
those
pertain
to
you
so
I'll
add
those
to
the
agenda
and
we
could
discuss
them
at
longer
length
after
yeah.
After
we
talk
about
the
lcga
runner,
I
believe
anthony.
Do
you
want
to
kick
us
off
on
that
conversation?.
C
Yeah,
so
in
an
earlier
sub
team
sync
a
couple
weeks
ago
right,
I
think
we
had
expressed
interest
in
sort
of
automating
the
provisioning
process
of
these
runners,
just
because
when
they
you
know,
do
eventually
flake
out
or
whatnot,
we
just
would
like
to
easily
recreate
it,
and
I
basically,
I
put
up
a
pr
that
attempts
to
do
that
as
much
as
possible,
basically
uses
terraform
under
the
hood
to
talk
the
packet
and
do
all
the
steps
that
are
documented.
You
know
there's
a
couple
of
things.
C
A
A
C
Good
question,
so
I
believe
there
were
already
some
manual
steps
around
like
starting
pack
up.
I
sorry
I
never
was
able
to
see
that,
but
I
believe
natalie
said
that,
so
I
would
lean
on
you
all
for,
however
pack
is
the
pack
process
has
started
up,
but
for
initiating
docker,
specifically,
that
has
to
be
manual
at
least
from
what
I
could
see
that
just
not
installing
it
just
turning
it
on
the
first
time
and
setting
up
the
share
drives.
Maybe.
B
C
A
A
B
As
far
as
the
terraform
stuff,
too,
do
you
feel
like
any
folks
in
general,
feel
like
that
that
packet
might
be
a
valid
way
to
spin
up
non-ci
vms,
potentially
have
the
shared
windows
vms
that
all
contributors
are
not
all
contributors,
but
all
core
contributors
could
use,
or
do
we
prefer
to
use
like
generic
iss?
For
that.
A
I
see
what
you're
saying
weather
packet
yeah,
that's
a
really
good
question.
I
know
right
now.
As
far
as
the
cncf
is
concerned,
we
are
using
packet
solely
for
ci.
I
don't
know
if
there
would
be
any
sort
of
considerations
there
that
we'd
have
to
let
them
know
that
we're
also
using
it
for
active
development.
A
A
D
B
Yeah,
I
think,
like
the
it
feels
like
the
reproducibility
of
the
ci
failures
in
general,
would
be
a
nice
a
nice
to
have
feature,
but
if
we
only
have
one
set
of
ci
jobs
running
on
the
packet,
then
maybe
we
want
a
more
generic
solution
or
something,
but
I
feel
like
if
we
like
that
terraform
workflow,
though
it
might
be
worth
making
the
process
first
standing
up.
The
one-off
windows
machines
also
use
terraform.
A
C
A
D
C
A
B
Yeah
we
good
to
dive
into
it
now.
Yeah
I'd
be
happy
to
update
that
yeah.
So
it
appears
that
that
should
work.
We
have
an
upcoming
story.
That's
going
to
actually
do
the
work
with
latest
work,
that's
on
main
and
make
sure
that
the
work
around
that
we
or
this
the
state
in
which
we
could
run
everything
on
the
on
the
vanilla
worker.
B
B
We
have
a
little
bit
of
work
to
make
those
skips
those
skip
tests
pass
again,
but
I
haven't
seen
any
clear
sign
that
a
vanilla,
w
cal
worker
will
not
work.
I
think
it's
very
likely
that
we
should
be
able
to
use
for
wcal
a
vanilla
worker,
so
that
would
leave
our
last
remaining
self-hosted
machine
as
the
lcal,
but
I
feel
like
there's
pros
and
cons
to
having
the
self-hosted,
w
cow
and
a
lot
of
the
cons
have
sort
of
gone
away
with
a
very
scriptable
easy
to
use.
B
Reproducible
self-hosted
runner,
but
I
think
there's
still
maybe
enough.
Maybe
enough
debate
to
be
had
on
either
side
which
one
we
would
keep,
but
the
nice
bit
is
to
switch
back
and
forth
to
one
to
the
other
is
really
a
low
effort
with
all
the
automation
work
that
anthony
put
in
and
potentially
with
you
know,
once
once
it's
working
on
a
vanilla
runner,
it's
unlikely
to
stop
working
again,
so
I
feel
like
we
don't
necessarily
have
to
make
the
choice
right
now,
but
it
seems
just
to
answer
your
question.
A
So
it
is
an
option
that
we
could
leverage
if
we
choose
to
and
yeah
speaking
to
why
we
might
want
to.
I
believe
the
wcal
recently
gave
us
some
issues.
I
don't
know
exactly
what
the
fix
was,
I
believe
was
it
dan
took
a
look
at
that,
kicked
it
maybe,
and
it
just
worked
so
we've
had
to
kick
it
a
couple
more
times
than
we'd
like
so
I'd
hate
to
via
cron
job
have
to
restart
it
every
night
as
a
solution.
So
if
someone
else
could
take
that
off
of
our
hands,
that'd
be
awesome.
B
B
A
A
A
A
D
A
D
A
C
D
I
at
the
very
least
wanted
to
give
a
you
know.
I
wanted
to
build
for
people
to
actually
check
it
out,
but,
as
it
was,
quiet
mode
was
not
kind
of
fulfilling
its
mission.
It
was
randomly
having
the
logs
from
the
fetcher
appear,
so
this
at
the
very
least,
takes
that
out
for
quiet
mode,
and
then
it's
just
adding
in
what
the
app
name
and
shot
is.
So
if
that's
useful
great,
if
not
at
the
very
least,
we
should
make
sure
our
quiet
mode
is
fully
quiet.
A
A
A
We
wanted
to
know
how
a
certain
life
cycle
phase
was
executed
and
environment
variables
was
part
of
that
conversation
right.
So
what
was
the
binary
executed?
What
was
the
argument
and
what
were
the
environment
variables
and
then
the
complexity
came
to
be.
When
we
talk
about
environment
variables,
there
are
environment
variables
that
are
being
passed
into
the
container
itself
that
might
have
to
do
with
authentication
and
whatnot,
and
then
there
is
another
set
of
environment
variables
that
is
being
passed
onto
the
disk
right.
A
So
I
don't
know
where
we
want
to
take
this,
but
if
we
want
to
like,
I
guess
I
could
see
this
going
both
ways,
one
of
them
being
the
iterative
approach
where
we
just
ignore
the
environment
variables
at
least
provide
the
binary
and
the
arguments
that
are
being
passed
in.
I
think
that
would
still
add
a
lot
of
value
and
then
add
the
complexity
of
environment
variables.
After
the
fact
where
we
display
that,
and
then
in
that
particular
issue,
we
do
kind
of
aggregate,
both
the
container
and
the
file
based
environment
variables.
A
D
A
D
D
A
B
D
B
Oh,
this
is
also
slightly
slightly
slightly
tangentially
related.
But
sorry,
if
we're,
if
anyone
wants
to
bail,
that's
fine.
So
we
we
stumbled
on
a
bug
in
windows
where
our
current
implementation
for
starting
build
containers
was
to
call
container
start
through
the
docker
api
and
then
call
container
logs
immediately
after
that.
B
We
tried
a
whole
bunch
of
different
approaches
to
try
and
make
it
work.
What
we
ended
up
doing
is
looking
a
lot
of
the
docker
cli
implementation
and
they
actually
like
so
for
a
command
like
docker
run.
It
doesn't
do
that
it
doesn't
do
the
start
and
then
logs
necessarily
instead
of
as
a
docker,
attach
followed
by
a
docker
run
and
then
streams
out
the
handles
to
standard
in
standard
out
directly
to
the
console,
or
you
know,
through
the
whatever
recognitions.
It
has
to
do
that.
B
So
you
can
see
in
the
pr
once
we
finally
get
it
open
again,
but
we're
proposing
to
change
that
for
all
os's.
It
does
seem
to
have
a
slight
speed
improvement
for
for
linux.
We
gotta
confirm
whether
that
is
actually
anything
significant,
but
I'm
just
kind
of
wondering
if
anyone
has
any
big
red
flags
with
potentially
doing
that
or
maybe
has
context,
and
why
the
current
implementation
was
chosen
over
what
was
happening
in
the
docker
cli.
A
B
I
think
that
we
ran
into
I
do
kind
of
want
to
do
a
little
more
poking
to
see
like
not
using
the
log
sub
system.
If
it
you
know,
there's
logs
that
are
lost
or
anything
like
that,
but
from
what
I
could
tell
attaching
prior
to
starting
the
container
pretty
much
guarantees,
you
never
lose
anything,
I'm
just
wondering
if
maybe
those
messages
aren't
kept
in
docker
logs
internally
or
something
like
that
or
but
I
just
saw
hypothetical
downsides.
I
can't
didn't
see
any.
A
A
The
only
thing
I
I
could
think
of-
and
this
is
totally
out
of
line
to
this
specifically
but
there's
a
draft
pr
in
which
I'm
attempting
to
do
where
I
am
messing
with
some
of
the
order
of
operations
there
to
be
able
to
do
interception
right
during
the
life
cycle
phases,
and
I'm
just
thinking
out
loud
to
try
to
understand
whether
or
not
there
would
be
some
implications
there.
But
I
could
most
likely
handle
those
after
the
fact,
and
so
I
don't
think
that
should
be
a
blocker
at
all.