►
From YouTube: 2020 10 22 Platform SIG
Description
Jenkins Platform special interest group Oct 22, 2020. Topics included Windows Server LTSC2019 vs. Windows 1909, Docker platform support plan, Oracle Cloud, Jenkins agents for PowerPC 64LE, and more
A
A
A
A
A
A
A
A
I've
still
got
the
action
to
prepare
a
blog
post
on
plugin
installation
manager.
That's
that's
a
good
thing,
because
we've
had
fewer
than
fewer
blog
posts
lately
than
we
want
then
typical
so
mark
to
do,
and
we
had
one
item
from
jim
crowley
of
ibm
on
submitting
refinements
for
further
parallelization.
A
So
we'll
need
we'll
need
a
further
conversation
with
alex.
I
thought
it
was
going
to
use
adopt,
but
as
far
as
I
can
tell
it
is
not
it's
a
lot
to
check
to
see
if,
if
the
new
versions
based
on
debian
10
are
using
it
next
topic,
then
retirement
plan
for
debian
stretch
9
in
the
docker
images
and
there
will
be
written.
A
Sorry
gareth,
I
just
realized,
I
may
not
have
started
the
recording,
oh
no,
I
am.
We
are
good,
sorry,
okay,
so
switching
the
retirement
plan
for
debian,
9
that'll
just
be
part
of
the
platform
plan.
The
docker
platform
plan
jeb,
because
debian
9
is
an
obvious
way
to
test
the
rules
test.
The
proposals
for
the
guidelines
to
say,
hey
would
that
have
caused
us
to
drop
this
naturally
anyway.
A
A
B
Yeah,
so
I
suppose
there
is
a
bit
of
an
ongoing
question
about
whether
this
is
windows,
server,
1909
support
or
whether
we
want
to
change
it
to
be
windows.
Server,
2019,
ltsc
support,
one
of
the
things
we've
found
is
building
docker
images
on
windows.
Is
it's
very
strict
about
the
version
of
the
kernel
that
you
have
in
older
versions
of
windows?
It's
it's
extremely
strict.
That
strictness
has
loosened
slightly
in
2019
and
onwards,
but
it
would
it
still.
B
We
wouldn't
be
able
to
build
an
1809
image
on
a
1909
server,
for
instance,
which
means
that
every
six
months
we're
going
to
be
sort
of
version
chasing
creating
new
vms
to
be
able
to
handle
the
builds
of
these
images.
So
it's
a
I'll
just
let
mark
catch
up
slightly,
but
it's
it's
it's
an
ongoing.
It's
gonna
be
an
ongoing
task
and
the
question
is:
what
do
we
actually
want
to
support?
B
I
think
the
recommendation,
or
that
I'm
proposing-
and
I
think
mark
agrees-
is
that
we
we
go
with
the
ltsc
versions
of
windows
and
try
and
support
those
and,
where
possible,
we
can
still
keep
building
these
on
a
regular
basis.
So
that
we
get
patch
upgrades
but
1909,
also
2019
ltsc
is
supported
until.
B
B
B
A
A
Right
well
and
of
course,
there
was
a
1903
in
there
and
there
was
an
1803
so
and
but
I
think,
rolling
our
our
generating
equipment
every
six
months
is
is
more
work
than
we
want
and
more
work
than
our
consumers
want
so
and
then,
but
then
use
ltsc
2019
as
our
base
regularly
patch.
It
regularly
run.
Windows
update.
B
A
So
I'm
gonna
I'm
going
to
factor
that
into
the
platform
plan.
Champa
jep
as
well
try
to
include
the
rules
as
you've
described
them
gareth
so
that
so
that
people
are
aware
hey.
This
is
the
plan.
1809
is
ending,
live
debian,
9
is
ending
live
and
we
will.
We
will
switch
at
this
point
to
ltsc
2019
rather
than
switching
to
1909
or
20
h2
great
any
other,
any
other
insights
you
want
to
offer
there
or
any
other
guidance
to
us.
I
don't
know,
I
think,
that's
it
all
right.
A
Okay,
let's
see
next
topic,
then
was
oracle
cloud
and
I've
been
in
discussion
with
oracle.
I've
actually
signed
a
confidential
disclosure
agreement
with
them
so
that
they
can
share
things
with
us
with
me
as
needed
and
I'll
be
doing
some
experiments
to
run
jenkins
in
oracle
cloud
here
within
the
next
few
days.
A
A
A
A
So
the
one
of
the
principles
was
that
we
we
want
to
use
current
currently
maintained
operating
systems,
only
know
that
may
sound
shocking
or
surprising.
No,
it
makes
sense
that
we
don't
want
to
use
operating
systems,
that
vendors
aren't
supporting,
currently
maintained
jdks,
and
we
one
of
my
principles
is:
we
want
a
maintainer
assigned
for
each
distribution
for
each
image
that
we
deliver.
A
But
this
is
a
different
concept
than
we
have
right
now,
where
right
now,
what
we
have
is
a
repository
level
maintainer,
not
an
image
level
maintainer,
but
the
docker
image
actually
has
the
concept
of
a
maintainer
in
the
image,
and
I'm
I'm
going
to
bring
the
proposal
that
we
consider
putting
the
names
of
people
in
those
maintainer
image
maintainer
lists,
so
that
we
know
who's
who's.
Aware
of
that
image
and
caring
for
it
now
gareth.
In
your
experience
with
jenkins
x
or
with
the
kubernetes
project,
are
there
any
principles?
A
A
B
We
tried
to
make
the
images
as
small
as
possible.
That's
it's
not
always
easy,
so
jenkins,
x,
one
and
two
had
a
it
used
this
kind
of
builder
process,
which
basically
requires
an
operating
system
and
bundles
everything
into
the
image.
So
the
images,
if
you
wanted
to
have
a
java
builder,
you
required
maven
and
probably
multiple
versions
of
java
and
whatever
else
it
was,
it's
quite
frequent
that
the
builders
would
get
to
around
about
four
gig
in
size.
That
is
a
significant
cost.
B
If
you're
of
on
bandwidth,
when
you're
allowing
people
to
download
those
with
jenkins
x3
it's
using
techton,
so
every
build
step
essentially
runs
in
a
different
container
or
can
run
in
a
different
container,
which
means
you
can
base
images
off
scratch
and
or
some
of
the
smaller
lightweight
things.
So
it
wasn't
wasn't
as
required.
So,
wherever
possible,
we
were
trying
to
base
things
off,
yeah
the
bass,
scratch
image
or
or
something
like
alpine
slim
or
something
as
small
as
possible.