►
From YouTube: 2021 05 18 Jenkins Infra Meeting
Description
Jenkins infra meeting May 18, 2021 with topics including Puppet Agent certificate expiration, AWS sponsorship, Scaleway sponsorship, CI agent improvements, and Discourse trial for chat and threaded conversations. Also noted that Azure cost reductions have started to bring us nearer the allowed Azure budget
A
B
C
B
B
D
B
Yes,
so,
first
few
announcements,
is
it
recording
sorry?
Yes,
okay,
so
I
think
we
have
to
cut
that
first
part
of
the
video
so
welcome
everybody
to
this
new
jenkins
infrastructure
meeting.
We
have
few
announcements
on
the
sponsoring
detail.
The
first
one
is
amazon
is
going
to
renew
the
sponsoring
so
last
year
they
gave
us
a
60
000
to
cover
the
ci
infrastructure
and
we
got.
We
recently
got
confirmation
that
they
will
renew
that
sponsoring,
which
is
really
great.
B
We
just
have
some
technical,
some
implementation
that
we
have
to
solve,
because
what
happened
last
year
is
so.
The
current
situation
for
the
amazon
account
that
we
are
using
is
officially
owned
by
cloud
ps
and
we
have
to
transfer
that
account
to
the
cdf.
That's
that
was
a
long-standing
project
and
what
happened
last
year
is
when,
when
the
sponsoring
sponsoring
arrived,
it
was.
It
appears
in
cloud
b's
billing
information,
and
this
is
something
that
we
want
to
avoid
this
time.
B
So
we
are
currently
investigating
if
it's
faster,
to
transfer
the
account
to
the
cdf,
if
it's
faster,
to
transfer
the
account
to
an
independent
organization
or
any
other
solution,
but
yeah
at
least
at
least.
The
good
thing
is,
the
cost
will
be
covered
from
a
second
sponsoring
standpoint.
Scale
away
will
offer
some
money,
if
my.
If,
if
I
remember
correctly,
it
will
be
600
euro
per
month,
so
this
is
also
some
some
compute
that
will
be
able
to
use
for
the
ci
environment.
B
In
that
specific
areas.
We
may
have
some
some
some
work
to
do,
because
the
that
region
will
be
a
little
bit
further
than
east
to
west
coast.
So
we
may
probably
use
that
money
for
a
specific
ci
environment
we
still
have
to
to
to
identify
which
one.
So,
if
you
want
to
help
with
scale
way,
feel
free
to
reach
out,
and
we
can
see
how
to
to
to
use
that
money.
B
E
B
B
So
we
recently
discovered
a
week
ago
that
the
certificate
and
the
puppet
infrastructure
expired
two
months
ago,
and
so
the
puppet
agent
stopped
working
several
months
two
months
ago
at
the
same
time,
so
that
certificate
was
configured
to
work
for
five
years
and
we
had
no
monitoring
in
place.
So
what
we
had
to
do,
which
is
a
little
bit
cumbersome,
was
to
first
renew
the
certificate
on
the
puppet
master,
and
now
we
have
to
go
on
every
agent
to
renew
the
certificate,
so
the
agent
can
connect
with
the
master.
B
We
did
it
for
few
machine,
trust.ci
archives.ci,
and
we
now
have
to
continue
bringing
back
everything
on
track,
and
so
in
the
process
we
identified
that
some
changes
were
not
correctly
applied.
This
mainly
this
many
affected
demian
ssh
keys
that
were
not
deployed
on
some
machines,
so
he
needed
me
to
to
to
run
the
puppet
agents.
B
So
that's
still
a
work
in
progress.
Any
question
on
this
no
sounds
perfect,
so
that
then,
let's
continue
so
the
next
topic,
so
we
covered
the
ios
sponsoring
we
covered
the
scale
way
sponsoring
so
we
have
now.
The
next
topic
to
the
agenda
is
agent
on
rci
environments.
So
I
mean,
I
think
you
want
to
bring
this
as
you
as
you
as
you're.
The
one
who've
been
working
on
that
on
that
topic,
so.
E
The
initial
goal-
and
it's
still
the
scope
of
the
initial
change
it's
to
update,
regularly
the
operating
system,
packages
and
tools
inside
the
agents
right
now,
ci,
jenkins,
io
and
all
other
instances
that
we
use
are
using
images
from
december,
which
means
we
need
to
upgrade
the
content.
The
operating
system
mainly
and
the
main
challenge
we
have-
and
we
discovered
is
that
by
updating
we
have
the
latest
tools
specifics
per
cloud
on
aws,
it's
named
ssm
or
ec2
launcher.
E
They
provide
services
that
your
instance
use
to
connect
to
the
web
services
get
the
instance,
data
get
the
private
key
prints
to
the
console,
etc
and
at
least
for
the
ec2
plugin.
It
creates
a
big
issue.
It's
that
you
have
to
wait
for
the
instance
not
only
to
be
started,
started
and
ready
to
be
connected
to,
but
also
to
start
all
the
ec2
services.
Sometimes
it
reboots
it.
It
resize
the
file
system.
E
After
the
initial
connection,
there
is
no
risk
because
we
always
checked
afterwards,
but
that's
the
first
one
and
the
question
is:
oh:
is
it
a
real
threat,
the
man
in
the
middle
for
an
initial
ssh
connection
in
our
context,
because
we
build
the
mei?
These
are
not
outside
mei
and,
most
of
the
time
it's
inside
a
private
network.
E
However,
that's
still
a
risk,
I'm
not
good
enough
to
evaluate
the
potential
of
this
one,
but
we
have
the
challenge
of
do
we
want
fast
instances,
although
we
want
really
safe
instances
during
the
connection
right
now,
the
idea
is
to
try
to
keep
the
slowest
instances.
That's
the
proposal
I
prefer
staying
safe,
but
that
creates
challenges
depending
on
the
combination
of
operating
system
and
cloud
provider.
E
The
second
point
is
for
the
linux
instances:
irm
and
md.
The
goal
is
to
use
docker
as
an
unprivileged
process,
which
means
the
route
inside
the
container
won't
be
the
root
of
the
virtual
machine.
The
goal
is
to
strengthen
a
bit
on
that
part,
which
means
we
can
totally
target
on
linux,
to
use
the
unprivileged
user
for
the
jenkins
agent,
which
means
jenkins
agent
is
able
to
run
container,
but
the
jenkins
agent,
even
with
container,
is
not
able
to
to
own
or
to
build
root.
That's
the
goal
windows
for
windows
door.
E
We
don't
have
the
unprivileged
docker
container
engine,
it's
not
possible.
So
that's
why
the
initial
reason
is
to
keep
the
administrator
user.
The
second
reason
is
also
because
I
haven't
found
a
way
to
create
a
user
on
windows.
That's
as
simple
as
that
you
can
create
a
user,
but
you
don't
have
a
home.
You
don't
have
a
set
of
predefined
settings,
predefined
keys,
so
on
the
end,
the
user
must
be
unprivileged
so
that
that
means
no
need
to
create
an
unpivoted
user
and
add
too
much
code
to
maintain.
E
So
with
these
experiences
that
has
been
documented
on
the
repository,
the
goal
is
to
have
the
same
set
of
images
that
should
be
updated
at
least
monthly
and
deployed
automatically
on
all
the
instances.
So
we
will
have
the
same
behavior
between
for
releases
for
external
contributor,
on
ci
and
for
ocd,
so
that
should
be
end
of
the
month
for
that
set
of
tasks.
B
Thanks
damian,
I
would
just
just
add
something
quite
important:
while
you
are
looking
at
the
windows
agents,
we
still
have
an
issue
in
the
release
environment,
where
we
had
to
use
a
specific
version
of
the
ssh
plugin
so
yeah.
If,
if
you
have
enough
time
and
feel
confidence,
I
mean
that's.
If,
if
it's
remain
in
your
the
thing
that
you're
working
at
the
moment,
maybe
you
could
also
look
at
it?
Maybe
that's
something
easy
to
fix,
yeah,
good
pointer,
any
other
question.
C
B
C
Yeah
sorry
damian,
you
said
that
the
goal
is
to
have
a
similar
configuration
between
agents
in
those
various
environments.
Did
I
capture
that
correctly
in
the
notes,
ci
and
trusted,
and
release
and
infra
now?
Cert
is
certainly
one
that
daniel
cares
about
intensely
and
release
is
one
that
the
release
team
cares
about
intensely.
C
B
So,
just
something
to
to
specify
here,
the
release
environments
rely
totally
on
communities,
so
we
use
windows
pods
for
the
windows
parts,
so
windows
containers
and
we
use
linux
containers
running
on
communities.
That's
one
thing:
the
other
thing
is
the
work
that
daemon
is
doing
on
ci,
touching
that
io,
that's
where
we
spend
most
of
the
money
so
having
fast
with
those
agents
and
stable
windows.
Agent
is
pretty
important
for
cine
for
the
ci
to
check
in
that
I
o,
because
that's
our
biggest
instance.
B
Obviously,
once
we
have
a
good
process,
we
can
definitely
apply
the
same
configuration
to
cert.ci
to
trust.ci
as
well.
That's
what
we
did
in
the
past,
the
the
the
previous
situation
that
what
we
had
before
demon
started
working
I
mean,
even
I
would
say
one
or
two
years
ago
we
were
just
configuring
everything
from
jenkins.
So
when
jenkins
would
start
an
agent,
he
would
install
docker,
we
installed
the
user
and
we
would
just
run
a
script
for
windows
agent
and
then
we
started
creating
custom
windows
machines
using
packer.
B
This
is
something
that
alex
r
started
working
on
a
year
ago,
maybe
two
years
ago,
and
we
realized
that,
for
instance,
on
trust.ci,
we
were
still
using
the
previous
configuration
and
that's
the
challenge
of
having
configuration
that
we
modify
manually.
Is
that
sometimes
we
have
a
fix
happening
on
one
instance
and
it's
not
replicated
on
the
other
instances.
B
And
so
the
work
that
demand
is
doing
is
to
have
small
agent
a
small.
I
mean
templates
that
we
can
reuse
across
different
ci
instances,
and
this
brings
to
the
next
topic,
which
is
having
configuration
as
code
for
ci
jenkins.io,
and
the
idea
would
be
to
start
using
gcast
to
configure
the
cloud
agents.
B
Not
not
changing
everything
in
one
time,
but
just
working
on
one
area
at
the
time,
and
I
think
it
would
be
really
good
to
have
that,
because
the
cloud
configuration
is
quite
big
and
when
we
have
to
go
to
the
web
interface.
It's
quite
difficult
to
know
when
we
change
something
and
we
yeah
that
just
having
a
configuration
that
we
can
commit
and
that
people
can
review
would
be
definitely.
B
B
B
Any
question
on
that
topic,
so
I
propose
to
move
to
the
last
one,
so
I
had
discussion
about
using
this
course
in
the
jenkins
project.
So
for
those
who
are
not
familiar
with
this
course,
it's
a
tool
that
you
it's
similar
to
a
forum,
that's
a
tool
where
you
can
have
people
discussing.
We
can
group
topic
regroup
topics,
so
that
would
be
a
nice
way
to
organize
the
various
areas
in
the
jenkins
project.
B
Oleg
initially
came
to
me
asking
if
we
could
use
this
course
for
the
user
for
the
jenkins
user,
so
we
could
use
it
on
top
of
the
user
mailing
list.
I
think
it
would
also
be
great
to
use
it
for
dev
and
for
the
infrastructure,
because
this
idea
of
having
yeah
to
split
the
information
into
topic
would
be
really
helpful.
B
I've
been
looking
in
the
past
to
discourse
to
deploy
it
manually.
That
was
not
a
great
experience.
That's
why
I
mean
I.
I
don't
want
to
go
down
that
path,
so
I
would
like
to
look
at
either
if
we
can
have
some
sponsoring
from
this
course
or
maybe
pay
for
the
service
right
now,
when
we
start
the
trial,
we
have
14
days
to
test
it.
So
if
there
are
people
interested
to
look
at
them,
look
at
that
with
me
once
we
have
enough
people
to
test
this
course.
E
E
I
think
that's
a
subject
outside
this,
but
it
was
overall
pretty
good.
I
liked
it
and
you
have
a
way
to
personalize
customize
and
that
the
the
conclusion
was
the
same.
Maintaining
it
ourself
is
complicated,
so
if
you
have
to
do
it
just
be
prepared
to
have
way
more
things
and
it
was
working
really
smoothly
on
their
web
service.
I
never
had
any
incident
on
one
and
a
half
so
that
that's
quite
nice
and
you
can
tune
a
lot
of
things.
B
D
I
believe
that
we
could
get
sponsorship
for
managed
service
and,
moreover,
I
was
been
working
with
a
few
other
communities
recently
and,
for
example,
one
of
the
communities
open
source
design.
They
use
a
sponsored
version
of
this
course
from
the
vendor
company,
so
they
don't
manage
the
discourse
on
their
own.
They
just
get
a
managed
service.
D
B
D
So
yeah
we
can
potentially
even
pay
for
this
discourse
from
even
our
current
infrastructure
budget.
I
wouldn't
say
that
it's
the
desired
approach,
but
yeah,
so
discord
vendor
donated
2500
dollars
to
us
so
potentially
covers
the
cost
for
two
years
of
managed
service.
Just
by
that-
and
we
haven't
allocated
this
donation
anyway,.
E
We
should
be
a
pretty
good
candidate
for
the
open
source
program
for
the
record
with
traffic
they
evaluated
that
traffic,
even
though
the
source
code
is
open,
source
traffic
is
only
maintained
by
one
company,
which
is
containers
so
the
we
were
not
candidates,
they
refused
and
we
had
to
pay
for
that.
But
two
years
ago
at
least
they
said
jenkins
was
an
example
of
an
open
source
project.
E
When
we
asked
so
they
said
they
are
that's
very
well
known.
There
are
companies
different
people
from
different
interests.
They
considered
us
at
least
two
years
ago,
three
years
ago,
now
as
a
candidate,
so
that
should
be
a
good
still
a
positive
thing.
I
don't
know
with
the
experience,
but
don't
don't
get
me
wrong.
Maybe
they
will
say
the
same
and
they
will
ask
us
to
pay
because
club
business
behind
or
something
they
can
always
find.
This.
B
C
Well,
so
more
fyi
than
anything,
but
the
weekly
release
has
been
temporarily
delayed
and
intentionally
delayed
by
a
day,
so
that
we
can
get
a
little
bit
more
time
to
evaluate
a
possible
change.
It
was
in
the
release
channel.
It's
nothing
that
infra
needs
to
do
about
it
just
be
aware,
don't
enable
the
weekly
build
process
at
the
moment.
Let
tim
jacom
continue.
Managing
that.
B
B
B
B
C
I
I
don't
object
it
just
it
didn't
this
particular
condition
I
think,
is
handled
well
enough
by
the
job
being
disabled
and
as
daniel
noted,
the
cron
job.
But
if,
if
you
think
that
would
be
a
good
safeguard,
that's
great
as
well.
I
just
would
hate
to
have
lost
the
management
of
that,
because
we
forgot
to
enable
it
again
after
this
period
is
done.
B
C
B
Two
jobs
that
need
to
be
disabled
here
we
have
the
release
job
on
release.ci,
but
we
also
have
the
infra
management
job
that
manages
the
kubernetes
cluster.
So
if,
for
some
reason
we
update
jenkins,
if
for
some
reason,
yeah,
if
there
is
an
update
on
jenkins
and
we
accidentally
merged
that
change,
communities
will
be
updated
and
obviously
we
restart
the
the
jenkins
instance
so
we'll
restart
really.ti.
So
that's
why
I
was
suggesting
to
just
comment
this
line,
so
we
are
sure
that
we
don't.
We
don't
update
the
service
accidentally.
B
A
Release
yeah,
I
just
wanted
to
mention
this-
is
mostly
relevant
for
security
updates,
because
we
skipped
the
weekly
in
the
week
of
the
security
update,
and
that
has
happened.
I
think
once
or
twice
now
that
I
disabled
the
job
three
four
five
days
later,
someone
merges
something
jenkins
restarts
and
the
job
is
enabled
again.
B
B
B
D
So
currently
the
account
is
owned
by
cloudbees
and
we
had
some
issues
related
to
that
in
the
previous
years.
So
the
idea
that
we
would
start
a
new
account
and
we
move
jenkins
resources
there,
and
then
we
would
connect
sponsorship
so
that
sponsorship
is
dedicated
on
the
to
the
junkies
account
and
after
that
the
company
will
be
looking
opportunity
to
transfer
ownership
of
this
account
to
the
continuous
delivery
foundation
so
that
it's
officially
under
the
roof
of
cdf,
like
our
microsoft
accounts.
B
One
of
the
major
benefits
to
transfer
that
account
to
the
cdf
would
be
to
invite
non-cloud
base
employees
there,
because
right
now
only
cloud-based
employees
can
have
access
to
the
amazon
account,
which
is
a
blocker.
In
the
past
we
saw
that
key
contributors
who
had
access
to
azure
to
the
azure
account
really
helped
to
unblock
situation
and
right
now
we
have
strong
dependencies
on
on.
B
D
Not
a
big
factor
because
sorry,
yes
strategically,
it
should
be
transferred
the
continuous
delivery
foundation.
We
had
a
discussion
about
that
more
than
a
month
ago,
the
time.
Basically
nobody
had
time
to
do
that
we
had
much
more
serious
issues
with
asia
accounts.
Now.
Asia
problem
is
more
or
less
settled
and
yeah
thanks
to
olivia
for
pushing
that,
because,
finally,
as
a
board
member,
I
received
the
invoice
first
time,
so
at
least
the
process
gets
streamlined.
B
And
why
we
talk
about
azure
accounts?
We
still
have
to
reduce
the
cost
of
that
accounts.
So
with
the
recent
change
that
we
did
to
the
mirror
infrastructure
we
already
reduce,
but
it's
still
too
early
to
want
to
know
how
much
we
reduce
the
cost,
but
we
should
definitely
reduce,
I
hope,
to
reduce
by
one
thousand
dollar
based
on
the
change
we
did
two
weeks
ago.
B
B
So
I
hope
that
the
work
that
damien
is
doing
to
increase
on
the
time
to
to
to
start
an
agent
will
also
affect
the
bidding,
but
we
have
to
work
on
that,
but
we
are
running
over
time.
So
thanks
everybody
thanks.
Thank
you
for
your
time
and
see
you
on
rc
and
before
I
before
you
leave.
I
already
put
the
notes
to
the
next
meeting
agenda.
So
if
you
already
have
ideas
that
you
know
you
want
to
discuss
next
week
feel
free
to
add
them
thanks.