►
From YouTube: 2022 01 04 Jenkins Infra Meeting
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
B
B
Okay-
and
I
made
a
note
of
that
in
the
in
the
jenkins
dash
release
irc
channel
for
reference.
Oh.
C
A
A
Okay,
let's
go
right
step,
one
so
team!
It's
your
subject,
issues
for
infra.
D
Yep
so
I've
kind
of
briefly
mentioned
a
couple
of
times
over
irc
in
the
last
week,
so
we
just
switched
the
hosting
process
over
completely
to
github
issues
and
that's
seems
to
be
going
quite
nicely.
D
D
So
you
can
def,
so
this
is
all
defined
as
code
and
you
can
easily
change
it.
However,
you
want
it's
not
a
lot
nicer
than
jarrah,
because
jarrod's
very
limited
to
who
can
change
it,
and
even
as
someone
who
has
access
it's
pretty
horrible,
changing
it,
it's
so
hard
to
find
your
way
around
and
and
make
waiting
for
it
to
resync
and
everything
and
like
yeah,
even
having
the
access
it's
horrible
to
change,
whereas
here
you
can
change
it
as
easily
as
you
want.
D
C
D
I
created
two
templates
there,
one
for
a
specific
common
task,
which
was
github
permissions
with
some
specific
fields
on.
A
D
Yeah
and
then
there's
a
issue
of
one
I
created,
which
was,
I
think,
generally
based
off
the
the
infra
project.
What
it
has
set
up
at
the
moment,
but
with
a
bit
of
text
a
bit
of
special
text.
C
B
B
D
D
D
But
I
think
infrared
generally
needs
a
bit
less
information
depending
on
what
it
is.
That's
so
cool,
so
I've.
D
Yeah
so
set
to
create
a
label
with
triage,
just
kind
of
depends
on
how
you'd
want
to
work,
whether
you
want
everyone
to
review
an
issue
and
move
it
somewhere.
I
was
planning
to
probably
do
if
people
wanted
it
to
do
some
sort
of
auto
labeling
based
on
the
service.
E
D
I
think
gavin
posted
that
and
get
a
yeah
where
it
will
ingest
all
your
issues
into
algolia
and
then
post
a
comment.
It's
not
quite
as
good
as
the
has
jared's
plug-in
for
it,
but
yeah
you
can
do
that.
D
So
the
thing
I
was
looking
at
here
was
adding
a
service
and
then
adding
something
which
will
automatically
add
a
label
off
of
that
which
would
then
have
some
configuration
for
who
wants
to
get
notified
for
what
labels
it's
one
thing
where
github
is
lacking
is
that
there's
no
fine-grained
subscription
service
people
have
to
build
their
own,
but
yeah,
and
I
added
a
bit
of
text
near
the
top
saying
this
is
for
the
infrastructure
infrastructure
on
the
jenkins
project.
Moving
out
of
the
general
issues.
D
B
D
D
Yep,
any
of
them,
if
you
click
edit,
unfortunately
it
doesn't.
D
So
on
there
basically
each
field
there's
an
array
of
entries-
if
you
see
an
id
on
on
that,
then
that
will
that
can
be
auto
filled
from
the
url.
E
D
Those
are
built-in
parameters,
but
if
you
set
ids
until
you
see
ids
on
any
of
your
fields,
then
you
can
pre-fill
them
with
that.
Yeah
so,
and
url
equals
blah.
D
D
In
the
yaml
config,
you
need
to
set
an
id
for
each
field
and
they're,
not
okay,
yeah,
so
basically
mark's
talking
about
how
does
they
report
an
issue
link
which
includes
like
the
url,
so
he
wants
to
automatically
have
it.
So
I
think
currently
we
pre-populate
a
whole
body.
It's
not
it's
pretty
nasty,
but
this
means
that
you
can
just
put
the
actual
url
on
without
having
to
pre-populate
a
lot
of
stuff.
B
A
D
Yeah
I've
I've
done
migration
before
I've
done
it
on
quite
a
few
of
my
plugins.
I
wonder
if
it's
in
my
forks.
It's
definitely.
E
D
Good
question:
I
prefer
it:
I
just
been
off
gear.
If
I
can.
Okay,
I've
found
it's
a
lot
nicer,
just
to
have
one
source
of
truth,
and
so,
if
you
stop
people
reporting,
it's
really
annoying
having
people
reporting
new
issues
over
in
a
different
place,
I
mean
you
can
kind
of
mitigate
that
with
hope
with
a
whole
project,
because
with
the
whole
project,
you
can
stop
people
creating
new
issues,
but
if
you're
not
getting
rid
of
the
old
ones.
So
I
I
didn't
migrate.
D
A
I
have
so
few
other
questions.
The
first
one
is
you,
you
can
reference
other
issues
from
other
repositories.
A
That
means
so
that
one
is
jira
of
desk.
It's
a
general
question
for
everyone.
We
have
the
concept
of
epic
that
can
be
used
in
different
ways
in
jira.
The
epic
is
like
a
super
task
that
lists
a
bunch
of
tasks
that
are
each
one
atomic
in
term
of
work,
work
item,
but
it's
a
general
automatic
like
deploy
the
new
service,
apply
automation,
update
it
one
time
the
epic
should
be
well
scoped,
even
if
it's
big
scope,
but
it's
still
a
scope.
A
You
can
close
it
at
the
moment
on
time,
and
I
don't
know
on
github
issue
even
when
using
projects
is
there
a
way
to
have
this,
because
in
that
case
I
see
that
would
be.
The
peak
would
be
an
issue
in
that
repo
or
any
repository
like
this
one,
and
that
will
link
all
the
subtasks
on
all
the
repositories.
D
So
there's
a
few
ways
of
doing
it
and
github.
So
there's
there's
milestones
so
you
can
group
a
set
of
issues
together
into
a
milestone
and
then
there's
also
yeah,
so
you
assign
them
to
a
milestone
or
there's
labeling
for
grouping
the
issues
and
then
generally
you'd
have
a
project
or
a
backlog.
So
if
you
go
to
projects.
D
Yeah
you
have
basically
ever
you
can
have
a
project
for
that
piece
of
work
or
as
you're
backlogging.
You
kind
of
you
use
the
top
one,
the
top
one's
a
lot
more
powerful
and
you
can
create
lots
of
different
views
and
different
people
can
have
their
own
different
views,
and
you
can
have
that
at
a
repo
level
or
across
the
organization
level
as
well.
D
So
then,
it's
kind
of
about
yeah
how
you
want
to
work
all
right
labeling
tends
to
work
really
well.
C
D
C
A
Okay,
that
should
make
it.
I
propose
that
we
try
it
for
the
task
we
have
right
now.
I
assume
that
will
involve
maybe
migrating
a
few.
I
existing
at
items
from
jira
like
the
configurations
code
or
the
terraform
relative,
that
we
are
working
on
moving
them
here,
seeing
we
can
aggregate
them
and
in
parallel,
if
it's
okay,
then
we
should
migrate
the
issue
that
are
currently
opened.
I
don't
feel
like
that.
We
need
the
closed
issues,
but
the
goal
will
be
to
try
this
this
month.
A
A
A
A
Okay,
let's
proceed
to
the
next
topic.
What
about
the
the
issues
we
had
during
the
past
two
weeks?
Three
weeks
before?
First
one
we
faced
network
issues
that
started,
let's
say
three
weeks
ago
middle
of
december,
so
we
started
to
sow
only
on
the
kubernetes
instances,
in
particular
on
the
jenkins
agents,
kubernetes
agents,
a
lot
of
tcp
issues.
Most
of
the
time
it
was
random
connection
being
cut
when
trying
to
reach
outside
the
cluster.
A
Like
cloning,
a
repository
from
github
pulling
a
docker
image,
there
weren't
exactly
one
kind
of
domain
or
ip
class
of
ip.
That
was,
it
was
completely
random,
so
erv
and
how
we
checked
the
azure
console
and
we
saw
some
alerts
from
azure
ui
about
so
that
that
was
a
topic
we
presented
two
weeks
ago.
We
had,
we
have
ip
overlap.
These
alerts
have
been
raised
since
one
year
and
a
half
on
the
azure
cluster.
A
A
A
The
public
one
will
host
the
services
that
are
public-facing
and
the
private
one
should
be
on
a
private
network
only
available
through
vpn.
In
order
to
to
have
more
safety
around
the
jenkins
instance,
such
as
infrasi
or
release
ei
with
sensitive
credential,
they
will
be
on
a
physically
separated
network.
A
That's
a
work
that
wasn't
done,
but
that
work
is
will
be
an
implementation
of
the
iep
from
taylor,
the
iep
2,
because
in
fact
it
wasn't
implemented
correctly
and
that
one
described
to
at
least
network
production.
It's
not
the
development
network
that
one
could
be
raised
in
the
future.
For
the
let's
say:
what's
the
name
pull
request
instances
for
the
developer
of
application,
like
plugin
jenkins,
that
run
on
public,
but
right
now
we
are
on
using
correctly
vpn
with
the
private
production
network.
A
A
A
A
But
that's
that's
the
next
steps
and
we
have
to
put
this
as
high
priority,
because
the
reason,
thanks
to
team
research
and
knowledgering,
the
reason
why
it
started
to
appear
middle
of
december
is
because
microsoft
has
rolled
out
a
new
network
infrastructure
system.
So
it
has
been
confirmed
that
we
are
not
alone
having
this
issue
and
any
alerts
that
was
raised
since
month
or
years
started
to
have
a
meaning
which
means
ip
overlaps
means
the
packets
weren't
treated
correctly.
D
D
The
roll
out
part
way
through
december
because
they
didn't
want
to
have
any
more
issues
around
christmas
time
because
people
were
going
on
holiday.
I
wouldn't
be
surprised
if
you
could
ask
them
to
roll
it
back.
Well,
I
mean
sure
we
can
fix
this,
but
it'd
be
nice
if
they
could
undo.
C
A
I
think
yeah,
that's
worth
it,
opening
your
support
ticket,
I'm
not
sure
it's
really
an
issue
in
the
sense
that
by
moving
infrasi
out
of
the
existing
cluster,
we
don't
see
tcp
issue
anymore,
mainly
because
the
the
ip
overlapped
was
caused
by
the
additional
ips
requested
for
each
external
request
made
from
the
kubernetes
agent.
So
we
are
just
back
on
below
the
threshold.
A
A
A
D
A
That
that's
the
second
issue.
It
appears
that
when
you
have
an
aks
cluster
there
are,
there
are
issues
when
using
side
containers
with
the
kubernetes
agent
plugins.
So
that
has
been
it.
It's
not
confirmed
by
the
developers,
but
there
are
people
at
least
at
cloud
base
that
are
working
on
that
since
this
morning
it
has
been
acknowledged
by
another
user
than
us
on
a
public
issue.
So
now
there
is
an
engineering
effort
from
different
contributors.
A
D
That's
good
because
I
mean
it
might
be
something
around
microsoft
as
well,
but
I
guess
they
can
do
that
if
they've
got
some
microsoft
contract
somewhere,
yeah.
A
So,
just
for
information,
I've
put
a
bunch
of
nod
about
the
cluster
and
the
kubernetes
issue
on
acandy.
I've
added
the
link
on
today's
notes,
because
until
yesterday
morning
we
weren't
sure,
except
maybe
tim,
because
he
went
advanced
with
the
analysis
but
weren't
sure
that
the
two
issues
weren't
weren't
the
same.
These
are
two
separated
issues
and
the
jenkins
kubernetes
issues,
since
it
was
spamming,
the
aks
control
plane
of
a
bunch
of
requests
for
cube
cattle
exec
to
the
agents.
A
And
the
latest
kubernetes
spring
so
in
order
to
in
order
to
have
everything
working
for
infra
ci,
we
did
a
bunch
of
work
yesterday
and
today,
with
team
rv
gave
in
we
switched
from
a
pod
agent
with
multiple
container
to
single
container
model.
That
means
where
to
rebuild
and
upgrade
all
of
our
docker
images
to
inherit
from
gdk,
which
was
quite
a
huge
work.
So
thanks
everyone
involved
on
that
because
that
was
let's
say,
annoying
not
complicated,
but
annoying.
A
D
I
assume
gavin
will
winning
weeks
when
he
gets
back
to
it,
but
it'll
only
fix
the
plugin
sites.
The
changes
we
did.
The
annoying
thing
is
that
jenkins
io
uses
a
really
old
version
of
ruby,
and
it's
not
that
version
of
ruby's
not
available
in
alpine's
repositories.
A
Okay,
so
we
might
not,
we
might
need
to
define
new
images
for
that,
but
the
rule
is
all
images
must
inherit
from
inbound
agent
either
debian
windows
or
alpine.
A
C
D
A
D
A
A
The
third
issue
is
just
a
special
thanks
to
olivier,
because
lb
and
hai
tried
to
update,
update
cli
on
some
elements
and
we
everything
started
to
to
break
and
we
have
a
bunch
of
failed
jobs,
so
that
should
be
fixed
by
updating
to
the
latest
17.
that
one
was
quite
annoying
as
well,
because
it
was
stopping
our
ability
to
update,
often
as
well
and
the
free.
A
D
B
Story
but
but
it's
maybe
it's
not
here,
it's
the
the
infra
breakage
meant
we
didn't
deploy
a
particular
image
and
that
image
was
needed
because
other
changes
were
needed
in
how
jenkins
plug-in
incremental
deployments
work.
So
when
I
deliver
a
new
pull
request,
I
automatically
get
a
build
of
that
pull
request
that
I
can
use
in
a
plugins.txt
file
and
it's
really
elegant,
it's
very,
very
powerful.
Let's
me
evaluate
betas
with
code
pre-releases
with
code,
but
that
was
broken
because
we
had
to
break
it.
B
D
D
Yeah
yeah
yeah
randomly
detects
leaders
and
marks
it
and
thinks
it's
a
beta
when
it's
not
because
it
finds
a
b
and
b
and
your
commit
string
but
yeah.
The
other
thing
is
that
I
think
it
was
it's
just.
It
was
basically
a
drive
by
pr.
I
don't
think
he's
actually
tested
it
fully.
So
we
just
need
to
see
whether
it
works.
A
Okay,
but
okay,
that
makes
more
sense
between
team
explanation
and
irc
and
euros
mark.
Now
I
started
to
understand
better
that
area.
I
was
close
to
zero
knowledge
on
this
area,
so
good
to
learn
cool
since
it's
we
are
10
minutes
past
the
limit
of
the
meeting.
I
propose
that
we
delay
the
other
topics
that
are,
let's
say
less
important
to
the
next
team
meeting.
Unless
there
is
one
you
want
to
bring
right
now,.