►
From YouTube: 2020 12 15 Jenkins Infra Meeting
Description
Jenkins infrastructure meeting December 15, 2020.
A
Hi
everybody
thanks
for
watching
this.
I
mean
about
to
participate
to
to
this
meeting.
The
first
topic
to
the
agenda
today
is
about
jenkins
infrastructure,
docker
images,
I'm
not
sure
if
it's
daniel
or
damian,
if
it's
damien
or
garrett,
who
put
that
topic
to
the
agenda.
But
basically
the
idea
is
to
build
a
specific
docker
otera
form,
docker
images
that
we
could
use
inside
of
the
jfk
for
a
social
project.
Yeah,
it
sounds
like
it's
demon.
I
don't
think
there
is
anything
important
to
say
here.
Basically
the
idea.
A
A
I
don't
think
there
is
anything
important
here
and
since
damien
is
not
there
to
elaborate
the
topic,
I
propose
that
we
continue
to
down
to
the
next
topic,
something
that
I've
been
thinking
over
past
week
is:
what's
the
current
status
of
confluence,
we
are
still
hosting
the
wiki,
even
if
I
don't
think
anybody
is
still
using
the
wiki
content.
A
B
B
Gavin
mogan
actually
created
a
a
metrics
collector
that
extracts
from
the
logs
and
I've
been
collecting
it.
Now
for
the
like,
the
last
six
or
eight
months,
and-
and
I
can,
I
can
give
you
some
data,
I
could
I
could
get
it
together
for
either
our
next
meeting
or
for
for
a
few.
I
can
send
it
by
email
to
show
which
pages
are
still
being
accessed,
but
we've
got
many
pages
that
are
being
hit
hundreds
of
times
a
day,
still.
A
So
so,
basically
my
fear
is
it's
becoming
a
snowflakes.
Nobody
is
updating
conference,
it's
a
service
that
is
not
updated,
running
in
our
infrastructure,
connected
to
our
ldap
service,
and
so
the
idea
is.
If
we
are
planning
to
maintain
and
to
keep
it
inside
or
infrastructure,
then
we
should
find
some
times
to
correctly
update
to
correctly
update
it.
The
good
thing
is,
I
don't
think
we
have
major
limitations
to
update
the
service.
We
haven't
worked
and
confidence
over
the
past
year,
because
we
knew
that
we
wanted
to
to
transfer
the
jira
to
the
linux
foundation.
A
This
is
maybe
something
that
we
could
also
do
if
we
know
that
we
still
rely
on
confluence,
but
we
don't
want
to
maintain
it
anymore,
but
anyway,
you
know
as
a
short
term
solution.
I
think
that
we
could
just
update
the
image
and
yeah
and
find
something
to
work
on.
But,
oh
sorry,.
B
So
is
your
concern
with
for
because
the
service
is
read
only
to
99
or
more
of
the
users,
I
wasn't
overly
concerned
about
even
doing
an
update.
We've
been
we've
been
actively
moving
content,
but
we
did
used
hack,
hack
events
to
do
that,
like
hacktoberfest
and
ui
ui
meetup,
but
we've
still
got
a
lot
of
content.
We
need
to
move
out
of
that
thing.
I
guess
we
could.
We
could
conceivably
extract
it
and
make
it
just
an
apache
server
serving
static
pages.
A
So,
for
instance,
last
year,
beginning
of
september
there
was
one
where
it
was
possible
to
read
the
content
of
every
files
on
the
machine,
including
a
file
containing
password
and
this
kind
of
things,
while
I'm
not
aware
of
such
vulnerabilities
at
the
moment.
I
also
know
that
if
we
don't
update
that
machine
on
a
regular
basis,
we
are
vulnerable
to
this
kind
of
issues.
So,
even
if
the
service
is
now
in
read-only
mode,
I
don't
trust
the
service
if
we
are
not
updating
it
on
a
regular
basis
which
we
haven't
for
conference.
A
So
the
thing
is
either
either
we
decide
to
keep
maintaining
and
we
I
mean
we
keep
monitoring
it
or
we
just
stop
the
service.
The
reason
why
I
was
suggesting
to
stop
the
service
is
because
I
know
that
we
still
have
many
urls
that
are
targeting
that
endpoint,
but
then
we
redirect
those
requests
to
the
plugin
site,
for
instance.
A
So
what
I
was
suggesting
is
we
could
just
keep
the
the
conf
the
apache
service
as
a
front
end,
and
we
would
just
allow
people
to
access
confirms,
but
let's
say
with
an
ssh
gateway
or
whatever
or
from
the
vpn
or
whatever
so
yeah.
It
was
just
to
still
provide
a
service,
but
we
would
stop
having
it
available
from
the
white
from
the
internet.
So.
A
Suggest
suggesting
what's
that.
A
B
Right,
okay,
so
so
up
to
now
the
the
primary
value
of
that
site,
at
least
for
the
docs
effort
for
the
doc
sig
effort
has
been
that
it.
It
includes
documentation
that
exists
nowhere
else
and
and
we've
migrated
some
of
that
to
jenkins.io.
But
the
migration
process
is
non-trivial
because
much
of
it
is
outdated
and
we
can't
just
vanilla
copy
it.
B
B
A
B
A
B
A
A
So
next
topic,
unless
someone
asks
questions
on
this
one,
particularly
next
topic-
is
about
the
azure
storage
issues
we
had
almost
a
month
ago.
So
what
we
did
after
the
outage,
we
temporarily
were
running,
get
a
jenkins
lio
on
on
the
different
machines
and
what
I
did
over
the
last
weekend
was
to
just
redirect
the
dns
traffic
to
the
kubernetes
cluster.
So
the
azure
file
storage
issue
has
been
solved.
A
The
only
thing
is
right:
now
we
don't
know,
I
mean
azure
support,
wasn't
able
to
provide
us
the
information
about
why
we
got
that
issue
and
how
to
prevent
that
issue
to
happen
again
in
the
future.
Basically,
they
just
explain
us
the
root
cause
like
we
are
limited
to
maximum
2000
open
file.
At
the
same
time,
so
we
were
probably
affected
by
a
file
leaks
somewhere.
A
What
I
find
strange
is
that
service
has
been
running
since
march
last
year,
and
I
don't
understand-
I
still
don't
understand
what
changed
one
month
ago,
but
yeah,
at
least
for
a
time
being,
we
reverted
the
service.
Another
traffic
is
running
to
the
community's
cluster
communities
cluster
again
and
we'll
try
to
monitor
this
one.
A
At
least
the
good
things
from
this
outage
is
that
we
put
in
place
few
things
in
order
to
catch
these
kind
of
issues
in
the
future.
So
we
now
monitor
if
we
can
download
packages,
so
we
have
an
alert
that
can
be
triggered
if
the
latest
package
is
not
available
for
more
than
30
minutes.
That's
one
of
the
things
that
we
put
in
place.
A
We
also
deploy
a
status
page
that
is
touching
the
lio.
So
the
reason
to
that
was,
we
realized
that,
during
the
outage
it
was,
it
was
quite
difficult
to
communicate
about
the
ongoing
issue,
the
ongoing
outage.
So
this
time
now
we
have
a
status
page
where
we
would
published
any
information
related
to
a
notation
windows
maintenance
whatever
so
right
now,
it's
contained
most
of
the
information
so
feel
free
to
look
at
it
and
provide
feedback
any
question.
A
No,
then,
let's
talk
about
the
next
topic,
which
is
the
han
so
the
jenkins
and
first
charts
repository.
So
this
is
the
the
git
repository
used
to
manage
the
kubernetes
cluster.
We
identified
a
few
shoes,
especially
specifically
over
the
past
week
last
week.
The
first
one
is,
we
are
having
a
hard
time
to
identify
when
a
release
of
an
update
is
failing.
We
I
mean
this
is
display
in
the
job,
but
we
are
still
trying
to
identify
how
we
can
be
how
we
can
detect
that.
A
So
a
similar
approach
is
for
the
puppet
codes.
When
puppet
does
an
update
on
one
of
our
machine,
we
receive
a
notification
in
rc,
saying
that
that
machine
was
updated.
Let's
say,
conference
machine
was
updated.
This
is
not
something
that
we
have
right
now.
We
have
to
connect
and
on
a
specific
service,
to
fetch
that
information.
A
So
that's
one
of
the
issues.
The
second
issue
is
about
testing.
Until
today,
we
easily
rely
on
me
testing
any
changes.
This
is
something
that
does
not
work
anymore,
because
we
have
more
and
more
people
contributing
to
git
repositories.
A
So
we
are
thinking
about
ways
to
to
test
the
different
changes
so
the
same,
if
you
have
any
suggestions
here
and
are
more
than
welcome
right
now,
the
first
test
that
we
put
in
place
was
to
do
some
to
run
some
linking
tests
on
humble
files.
A
If
you
have
suggestions
here,
that
would
be
nice
and
the
third
element
that
that
that
we
have
issues
over
the
past
few
weeks
is
the
way
we
deploy
the
way
we
deploy
the
jenkins.
The
way
we
manage
a
cluster,
we
run
basically
and
file
from
a
checking
job,
every
30
minutes
and
we
activated
the
multi
branch
pipeline.
So
what
we
did
was
to
run
the
same
command
from
all
the
branches
on
on
that
git
repositories.
A
So
we
we
have
some
old
branches
that
we
still
have
to
work
on,
and
so
basically
we
were
running.
We
are
using
a
tool
called
update,
light
updates,
every
versions,
and
so
we
were
updating
based
on
old
configuration
so
based
on
hand,
v2
configuration.
So
that's
why
we
saw
many
pr's
that
were
opened
in
a
git
repository
to.
Instead
of
upgrading
the
version
it
tried
to
downgrade
to
old,
hem
chat's
version.
This
is
something
that
we
are
working
on.
A
So
basically,
what
we
would
like
to
do
is
to
only
build
the
master
branch
and
be
it
the
pull
request
branch.
So
this
is
something
that
we
are
looking
at
right
now.
A
So
the
result
of
that
is
to
not
to
carefully
review
prs
right
now,
if
you
detect
anything,
that's
the
right
time
to
to
report
them
and
to
nuts
just
to
pay
attention.
Basically,.
B
I
I
had
I've
been
exploring
oracle
cloud
and
was
wondering:
is
it?
Would
it
be
reasonable
if
I
were
to
attempt
to
construct
a
prototype
version
of
the
jenkins
kubernetes
cluster
on
a
completely
different
cloud?
Is
that
safe
that
I
could
do
that
or
is
no
that's
really
not
safe
and
and
I
I
should
not
even
consider
it-
I
was
thinking
just
for
an
experiment
experimental
basis,
not
a
not
a,
not
a
production
thing.
I'm
just
thinking
is
it?
Is
it
a
safe
thing
to
do
or
no?
A
B
A
No,
as
long
as
you
try
to
be
sure
that
those
are
not
those
are
correctly
configured,
maybe
maybe
we
can
review
the
cluster
together
once
it's
in
place
before
we
deploy
the
resources,
but
otherwise
I
don't
have
any
major
concern.
Basically,
my
my
biggest
concern
at
the
moment
is:
if
we
decide
to
switch
to
to
oracle
what
the
bidding
workflow
would
be.
B
Yeah
and-
and
I'm
I'm
not
anywhere
near
ready
to
to
to
go
further
with
that,
yet
I
I'm
still
just
curious:
will
it
even
work
so
yeah?
I
agree
that
this
was
more
of
a
try
and
exploratory
prototype
with
something
that
someone's
offered
offered
money
that
we
can
use
freely
for
the
during
this
trial
period
and
then
throw
it
away.
D
D
Since
that
was
originally
created,
but
it
seems
to
be
deploying,
I
think
that
the
biggest
issue
I'm
having
at
the
moment
is
around
secrets
and
trying
not
to
obviously
push
to
take
any
secrets
from
their
current
system
or
push
anything
up
so,
but
it
is
allowing
me
to
test
out
the
just
sort
of
j
cask
and
job
dsl
config
to
correctly
apply
all
the
traits
that
we
need
to
run
to
do
that
master
brand
shampoo
requests
stuff,
it's
quite
a
good
test
bed
event.
D
So
if
you,
if
you
want
to,
if
you
want
me
to
show
you
what
I've
done
mark,
I
can
do
that
at
any
point.
Yeah.
A
B
B
A
The
next
topic
is
about
rc
stable
releases,
but
since
steam
is
not
here,
I
think
I
will
just
briefly
explain
what
I'm
working
on
here
and
then
wait
for
team
to
be
there.
So,
basically,
I
would
like
to
build
a
release
candidate
directory
from
that
release.ci.
A
The
limitation
that
I
have
right
now
is
to
use
which
maven
repository
to
use.
So
apparently,
I'm
supposed
to
use
the
snapshots
maven
repository
on
repo
jenkincia.org,
something
that
that
annoying
me
is.
It
uses
a
slightly
different
version
naming
pattern.
Also,
I'm
wondering
if
we
should
build
and
publish
distribution
packages
for
the
earth
really
stable.
A
Are
the
release
candidates
version
right
now,
when
you
go
to
get
the
junkies
or
io,
we
can
see
that
we
published
those
for
the
war
file,
but
we
don't
publish
those
for
the
debian
red,
that's
used.
What
I'm
wondering
is,
is
it
because
the
the
release
candidate
was
triggered
by
oliver
organza
and
he
didn't
have
the
correct
credentials
to
sign
the
red
dots
and
the
debian
package,
or
is
it
or
is
there
any
other
reason?
A
My
guess
is
just
because
of
credentialed
gpg
key
and
code
sending
certificates,
but
we
could
easily
build
and
publish
them
from
the
release.ci,
but
yeah
I'm
just
I'm
just
gathering
some
information.
At
the
moment
I
created
a
jira
to
get
so
I'll,
probably
post
it
on
the
jenkins
release,
rc
channel.
B
Yeah,
as
far
as
I
know,
as
far
as
I
know,
it
is
only
because
he
did
not
have
permissions,
but
I
don't.
I
don't
know
if
there's
anything
compelling
about
making
the
release
candidates
available
in
the
packages,
because,
practically
speaking,
I
don't
know
who's
going
to
the
number
of
people
who
actually
test
the
release.
Candidates
is
dismayingly
small
based
on
feedback
from
the
mailing
list
and
they
all
use
the
war
file.
B
A
B
A
Okay,
perfect,
then,
let's
move
to
the
last
topic
of
today's
agenda,
which
is
jenkins
release.
So
today
we
did
another
weekly
release.
Everything
went
well
as
again.
We
have.
We
have
a
dashboard,
the
database
dashboard
that
you
can
use
to
track
that
information.
A
I'll,
put
the
link
in
the
notes
after
the
meeting,
but
basically
what's
what
I'm
motive?
Monitoring
there
is
I'm
fetching
from
the
maven
repositories,
the
maven
metadata.xml,
I'm
looking
at.
A
What's
the
latest
version,
let's
say
the
version
2.271
and
then,
based
on
that
version,
I
tried
to
download
debian
red
that
were
windows
files
from
get.jenkinsonlio,
and
if
I
can
download
that
version
from
get.js,
then
it
means
that
they
are
available
and
because
there
is
a
gap
between
the
moment
we
release
to
the
maven
repository
and
the
moment
we
publish
those
artify
those
packages,
it's
around
20
to
30
minutes
right
now
we
have
an
alarm
that
that
is
triggered
only
after
30
minutes.
A
So
if
something
goes
wrong
after
30
minutes,
then
we
get
notified
about
the
fact
that
the
latest
release
hasn't
been
pushed.
And
so,
if
we
look
at
the
data
dashboard,
it's
only
one
or
zero.
So,
most
of
the
time
it
should
be
one
except
that
if
the
the
latest
version
cannot
can't
be
downloaded,
then
it's
the
zero
value
yeah.
I
don't
know
if
you
have
the
link,
I
put
the
link
in
rc,
but.
B
A
Okay,
perfect,
otherwise,
I
think
we
cover
everything
for
today
yeah,
but
the
most
important
one.
I
propose
to
not
have
a
championship
for
meeting
next
week
and
the
week
after
so
yeah.
A
A
Then
any
other
question
I'm
going
to
come
to
three
one,
two,
three
thanks
for
your
time
and
see
you
on
rc,
bye,.