►
From YouTube: INFRA Weekly Meeting 2020-06-16
Description
Jenkins Infrastructure Project Meeting - 2020-06-16
Notes - http://bit.ly/2T0oZ9v
A
Hi
everybody
welcome
for
this
new
Jenkins
infrastructure
meeting
and
today
we're
going
to
talk
about
adaptation
that
happened
last
week
and
some
ideas
about
how
we
could
manage
identity
management.
So,
first,
let's
talk
about
the
LDAP
voltage,
I
mean
I.
Guess
you
see?
Basically
what
happened
so
two
weeks
ago
we
had
an
issue
with
the
kubernetes
cluster,
where
we
had
to
recreate
everything
from
scratch
and
we
discovered
that
or
adapt
database
was
that
backup
since
February.
A
So
the
first
step
was
to
further
restore
the
database,
then
we
realized
that
people
were
nuts
were
created
in
the
process.
Those
icons
were
available
for
someone
else,
which
means
that
it
was
a
big
deal
for
especially
for
playing
in
maintainer
for
recently
maintainer
and
so
the
first.
The
first
step
was
the
first
recover
every
every
account
that
was
blessed,
so
we
first
focus
on
maintainer.
Then
we
use
JIRA
and
artifactory
database
to
restore
those
data
and
once
all
a
user
account
where
were
created,
we
try
to
reset
every
passwords
wide
for
maintainer.
A
It
was
quite
easy.
It's.
It
was
a
very
world
different
scenario
for
the
old
database.
The
main
reason
to
this
is
because
we
have
a
lot
of
accounts
in
our
database.
We
also
have
a
lot
of
garbage.
The
database
and
sending
one
100,000
email
address
in
one
day
is
not
something
easy,
especially
when
we
usually
only
send
something
like
around
500
per
month,
so
it
was.
A
It
was
quite
challenging,
and
this
process
also
highlighted
a
few
limitation
with
our
account
up,
which
is
the
application
that
we
use
to
create,
modify
and
delete
accounts
in
our
database.
So
now
that's
we
arrest
her,
and
we
are
back
to
the
previous
situation.
Jd's
tried
to
identify
how
we
could
prevent
this
to
happen
again
in
the
future
and
yeah
what
what
would
be,
what
would
be
the
different
options?
A
So
last
yesterday
we
had
a
discussion
with
the
Linux
Foundation
were
a
trustee
and
Alec
were
also
lead
discussion,
and
so
the
idea
was
to
see
with
the
Linux
Foundation
infra
team.
What
would
be
the
option
if
we
could
use
if
we
could
delegate
that
responsibility
of
identity
to
the
Linux
Foundation
instead
of
managing
it
by
yourself
by
ourselves
and
also
in
the
discussion?
Also
reminders
I
mean
that
maybe
not
reminders
but
tell
us
that
told
us
that
we
could
also
they
could
also
post
our
dear
instance
on
the
Linux
Foundation.
A
So
basically
everything
so
we
spend
we
discuss
for
around
one
hour
about
why
we
would
use
Linux
Foundation
identity
management's.
What
would
be
the
limitation
and
what
would
be
the
different
services
that
we
would
move
to
the
Linux
Foundation?
So
so,
first
any
question:
until
now
we
want
anybody
want
to
add
something
on
this
so
yeah.
So
then
I
continue.
B
Better
and
yeah
I
just
put
in
the
chat
the
link
to
the
document
we're
just
trying
to
capture
everything
with
their
identity
management
and
the
transition.
So
it's
work
in
progress,
but
I'll
keep
updating
it
with
this
conversation
and
if
folks
want
to
go
in
and
comment
or
use
that
as
just
background
to
what
we're
trying
to
do.
I
just.
A
A
Basically,
it's
a
tool,
that's
quite
easy
to
deploy
on
our
communities
cluster,
and
so
you
can
have
user
Federation,
so
we
could,
for
example,
use
it,
so
we
could,
for
example,
reuse
at
that
database.
A
new
stickler
to
create
user
in
the
database,
modify
user
to
each
users
and
what
we
can
also
use
it
for
is
to,
for
example,
have
it
in
front
of
the
other
tab
database
why
we
are
migrating
to
a
different
solution.
The
data
cloud
could
be
the
central
piece
for
wine.
It
seems
to
be
supporting
a
lot
of
feature.
A
Like
user
can
rule
request
an
account
they
can
has
to
reset
the
password
send
an
email
I
mean,
like
all
the
feature
that
you
would
expect
from
an
identity
management
today,
but
yeah
that
that's
one
of
the
option.
The
other
option
would
be
to
see
if
we
really
need,
because
the
main
reason
why
we
introduced
that
in
the
infrastructure
was
to
use
it
with
JIRA,
but
I
do
is
really
bite
on
my
side
story.
A
A
A
So
one
of
the
challenge
here
first
will
be
to
map
the
Jenkins
account
with
the
Linux
Foundation,
because
there
is
a
probability
that
your
name
is
already
taken
by
someone
else
in
the
Linux
Foundation.
That's
one
of
the
thing.
The
other
thing
is
to
the
Linux.
Foundation
always
provided
always
use
the
identity
management
for
their
own
services.
So
they
don't
know
at
the
moment
how
we
would
use
those
services
and
it
will
not
necessarily
be
easy
to
create
groups
and
change
groups.
A
Member
and
stuff
like
this,
we
don't
think
it's
a
big
deal
because
we
do
not
create.
We
don't
regularly
create
groups
except
the
default
one
to
access,
Sarah
and
maybe
for
let's
say
Arcade
factory,
but
otherwise
this
is
not
something.
That's
regularly
changed,
but
I
do
not
expect
it
to
be
like
a
quick
win
where
we
just
work
in
it
three
days
in
it,
and
it's
done
because
at
that
piece
use
in
a
lot
of
places,
so
the
bigger
side
challenge
I
think
will
be
to
see
how
we
do
for
Jairam.
A
So
if
they
owe
steerer,
then
it's
easy
because
we
don't
have
to
adult,
we
don't
have
to
care
for
the
identity.
We
just
used
random
TT
and
that's
it
and
they
provided
the
cheerin.
If
you
don't
want
to
use
your
anymore
for
some
reason,
maybe
there
is
other
options
and
also
they
also
have
experience
with
their
own
identity
management
to
manage
chief
rock
stars
with
artifactory.
So
this
is
also
something
that
they
already
did
in
the
past.
So
I
don't
really
plan
another
meeting
with
them.
A
C
I'm
particularly
interested
in
the
Egeria
thing,
because
if
I
understand
correctly,
we
we
need
to
confront
a
JIRA
upgrade
within
the
next
six
or
nine
months
right
we've
got.
We've
got
a
zero
version
that
we
need
to
update
anyways,
so
good
excuse
to
consider
hosting
that
by
Linux
Foundation,
great
yeah.
A
That's
definitely
so
the
description
is
just
a
reminder.
So,
right
now
we
have
three
options:
either
we
keep
maintaining
tirugata
ourselves
and
then
we
have
to
upgrade
the
database.
We
have
top
zero,
and
so
it
will
require
from
some
work
from
us.
Either
we
move
to
general
clouds,
but
there
we
have
a
bunch
of
limitation
limitation
that
identify
our
interior.
You
know
our
jury,
so
there
is
a
ticket
with
that.
But
the
main
issues
is
the
number
of
people
who
can
log-in
theorem.
A
We
cannot
use
adapter
to
get
onto
a
cloud,
so
you
have
to
use
JIRA
accounts.
There
are
some
limitation
with
the
domain
that
you
won't
use
for
usually
for
your
accounts
and
stuff
like
this.
So
it's
not
necessarily
true
that
to
move
to
share
a
clouds
and
also
be
efficient
about
using
github
issues,
so
yeah
I
think
it's
kind
of
really
it's
kind
of
linked
all
together,
but
yeah
from
for
all
users.
A
Most
of
the
accounts
accepted
for
maintained
errs
were
it's
way
easier
to
maintain
because
the
amount
of
maintained
or
something
like
one
thousand
seven
Rita
user
account,
which
is
definitely
easier
to
handle
than
the
one
hundred
thousand
user
that
you
have
in
adapt.
But
so
yeah
I
think
the
discussion
about
the
ticket
system.
A
B
On
the
JIRA
site,
I
think
I
want
to
say,
like
I'm
in
favor
of
you
know
aggressively
getting
rid
of
services
that
we
shouldn't
be
managing
and
figuring
out
how
to
do
that.
So
we
can
kind
of
focus
on
other
things.
Jenkins
should
do
well
so
on
the
JIRA
site,
like
it's
I,
think
we
can
separate
some
of
those
discussions,
we're
already
using
github
issues
and
JIRA
cloud
I.
Think
we
need
to
figure
that
out,
so
it
becomes
clear
to
the
community.
That
being
said,
I
don't
think.
B
D
Yeah
there's
been
a
recent
discussion
on
the
developers
mailing
lists
that
some
people
really
love
JIRA
for
their
plugins.
Some
people
hate
it.
So
it's
gonna
be
hard
to
get
a
consensus
on
one
single
tool,
but
we
I
think
we
can
enable
people
to
use
both
but
definitely
moving.
The
services
outside
of
the
jenkins
of
infrastructure
management
would
be
really
nice.
I.
A
A
The
other
thing
I,
also
think
that
you
have
to
be
clear,
is
what
are
the
priorities
for
the
drain
concern
for
our
projects,
because,
right
now
we
have
the
identity
management
that
you
have
the
trades
in
terms
of
priority.
We
still
have
to
finish
the
automation
in
this
project,
because
we
have
a
strong
deadline
about
being
able
to
twini's
stable
release
and
security
release,
because
once
the
security
needs
to
happen
first
stable
release,
we
need
to
be
able
to
provide
security
release
as
well,
so
automated
real,
easy
still
on
the
path.
A
0.0
yard
is
something
that
you
have
to
keep
in
mind,
and
this
was
the
last
thing
that
I
want
to
discuss
an
ultimate
automated
release,
I'm
just
wondering
so
that
we
agreed
that
we
meet
the
security
process,
but
the
way
that
we
test
the
security
process
using
the
next
weekly
release
next
week,
I'm
just
wondering
what
I
mean.
What's
the
current
state,
we
do
windows,
containers,
I,
don't
know
if
it's
alex
from
middle
blocker
in
this
project.
These
parts.
D
We
can
we
can
use
the
default
dotnet
3.5
container
as
the
build
part,
and
we
don't
have
to
build
our
own
image
for
that,
and
then
we
can
use
the
inbound
agent
or
what
used
to
be
called
the
jnlp
agent.
So
I
just
don't
know
how
to
just
set
that
up
in
the
pod
template,
but
I
can
give
you
the
image
names
to
use.
If
that's
helpful,
yeah.
A
D
A
A
C
A
Different,
we
have
to
do
a
different
retrospective
retrospective
regarding
the
author's
I
just
would
like
to
see
before
doing
the
retrospective
to
see
what
are
the
different
output.
What
are
the
different
options
that
you
may
have
to
solve
here,
because
we
had
that
meeting
with
an
index
fund
Asian
yesterday,
which
was
planned
really
late,
I
was
discovered
like
one
or
two
or
before
it
happens,
Swiss
organized
it
in
last
minute.
We
have
a
second
one
next
week
on
Monday,
and
then
we
know
a
little
bit
more
about
what.
What?
A
What
does
it
like
to
move
to
the
Linux
Foundation
for
identity
management
and
how
many
time
will
it
take
to
us
to
move
it
and
stuff
like
this?
So
I
think
it
would
make
make
sense
to
just
delete
a
retrospective
once
we
know
a
little
bit
more
about
what
our
options
is.
It
does.
It
sounds
right
to
you.
C
A
C
E
C
Me
in
the
past,
it's
worked
well
together
as
much
as
we
can
into
the
document
beforehand
and
and
let
everyone
who
is
interested
contribute
their
their
ideas
and
concepts
into
the
document.
So
it's
been
deeply
vetted
before
and
then
yeah
I
would
love
to
hear
it
if
we
could
be
ready
for
next
next
in
from
then
for
meeting.
That
would
be
great
for
me.
F
Can
I
just
add
something
this
I
think
would,
and
this
is
just
a
suggestion
prior
to
doing
the
retrospective.
Would
it
be-
and
this
may
have
been
done
and
I
just
have
not
seen
it.
Would
it
be
good
to
do
some
type
of
a
like
business
disruption
report
and
in
that
report
we
actually
show
a
timeline
of
what
happened.