[JIRA] (OVIRT-620) Optimize how Jenkins fetchs ovirt-engine from gerrit
by Nadav Goldin (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-620?page=com.atlassian.jira... ]
Nadav Goldin commented on OVIRT-620:
------------------------------------
{quote} I'm also looking to move to a much better VM on amazon, including more cpu/memory/network bandwidth.{quote}
+11
sent a patch to run --aggressive mode monthly on ovirt-engine, will test it tonight to see if it reduced the size. [https://gerrit.ovirt.org/#/c/60247/]
> Optimize how Jenkins fetchs ovirt-engine from gerrit
> ----------------------------------------------------
>
> Key: OVIRT-620
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-620
> Project: oVirt - virtualization made easy
> Issue Type: Sub-task
> Reporter: Nadav Goldin
> Assignee: infra
>
> ovirt-engine git repository is at the time of writing is of size 244MB, where ovirt-engine/.git alone takes 160MB.
> There are two things which might be done:
> 1. Find a way to optimize ovirt-engine.git/.git size, this needs to be explored deeply.
> 2. Check if it is possible to configure git plugin to not download the entire history, although Jenkins attempts to optimize that, it still looks like the git plugin is downloading the entire history(this is what a random check on the slaves using du ../jenkins/workspace/...../.git -h -s showed)
> for instance the following command takes only 91Mb:
> {quote}git clone --depth 1 --branch master {quote}
> Although this will not solve real network/storage issues, it could help reduce those problems and in the overall decrease jobs runtime. As Gerrit is still on AWS, this is a considerable amount of traffic for each job we might be able to reduce.
--
This message was sent by Atlassian JIRA
(v1000.126.2#100004)
7 years, 10 months
[JIRA] (OVIRT-621) Upgrade of the fc21 vms required to run fc24 chroots
by Nadav Goldin (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-621?page=com.atlassian.jira... ]
Nadav Goldin commented on OVIRT-621:
------------------------------------
ok, trying to create fc24 templates.
> Upgrade of the fc21 vms required to run fc24 chroots
> ----------------------------------------------------
>
> Key: OVIRT-621
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-621
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: David Caro
> Assignee: infra
> Attachments: signature.asc
>
>
> The issue being that in order to run the fc24 chroots, it needs the correct gpg
> key for the fc24 repos, and that is included only in a newer mock version, that
> will not be released for fc21 (as it reached it's end of life).
> So possibilities are:
> * manually deploy the keys (puppet?)
> * build a custom mock package with the newer version and install that
> * upgrade the slaves (something that we should do anyhow, sooner than later)
> * remove all the fc24 jobs we added (lago in specific)
> In the meantime, some fc24 builds can't be done (for example, lago is blocked
> by this).
> Cheers!
> --
> David Caro
--
This message was sent by Atlassian JIRA
(v1000.126.2#100004)
7 years, 10 months
[JIRA] (OVIRT-620) Optimize how Jenkins fetchs ovirt-engine from gerrit
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-620?page=com.atlassian.jira... ]
eyal edri [Administrator] commented on OVIRT-620:
-------------------------------------------------
I'm also looking to move to a much better VM on amazon, including more cpu/memory/network bandwidth.
> Optimize how Jenkins fetchs ovirt-engine from gerrit
> ----------------------------------------------------
>
> Key: OVIRT-620
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-620
> Project: oVirt - virtualization made easy
> Issue Type: Sub-task
> Reporter: Nadav Goldin
> Assignee: infra
>
> ovirt-engine git repository is at the time of writing is of size 244MB, where ovirt-engine/.git alone takes 160MB.
> There are two things which might be done:
> 1. Find a way to optimize ovirt-engine.git/.git size, this needs to be explored deeply.
> 2. Check if it is possible to configure git plugin to not download the entire history, although Jenkins attempts to optimize that, it still looks like the git plugin is downloading the entire history(this is what a random check on the slaves using du ../jenkins/workspace/...../.git -h -s showed)
> for instance the following command takes only 91Mb:
> {quote}git clone --depth 1 --branch master {quote}
> Although this will not solve real network/storage issues, it could help reduce those problems and in the overall decrease jobs runtime. As Gerrit is still on AWS, this is a considerable amount of traffic for each job we might be able to reduce.
--
This message was sent by Atlassian JIRA
(v1000.126.2#100004)
7 years, 10 months
[JIRA] (OVIRT-621) Upgrade of the fc21 vms required to run fc24 chroots
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-621?page=com.atlassian.jira... ]
eyal edri [Administrator] commented on OVIRT-621:
-------------------------------------------------
or upgrading the f21.
The ticket is on removing the f21 slaves, so either upgrading them or replacing them with f24.
> Upgrade of the fc21 vms required to run fc24 chroots
> ----------------------------------------------------
>
> Key: OVIRT-621
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-621
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: David Caro
> Assignee: infra
> Attachments: signature.asc
>
>
> The issue being that in order to run the fc24 chroots, it needs the correct gpg
> key for the fc24 repos, and that is included only in a newer mock version, that
> will not be released for fc21 (as it reached it's end of life).
> So possibilities are:
> * manually deploy the keys (puppet?)
> * build a custom mock package with the newer version and install that
> * upgrade the slaves (something that we should do anyhow, sooner than later)
> * remove all the fc24 jobs we added (lago in specific)
> In the meantime, some fc24 builds can't be done (for example, lago is blocked
> by this).
> Cheers!
> --
> David Caro
--
This message was sent by Atlassian JIRA
(v1000.126.2#100004)
7 years, 10 months
[JIRA] (OVIRT-621) Upgrade of the fc21 vms required to run fc24 chroots
by Nadav Goldin (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-621?page=com.atlassian.jira... ]
Nadav Goldin commented on OVIRT-621:
------------------------------------
You mean creating new slaves with FC24?
> Upgrade of the fc21 vms required to run fc24 chroots
> ----------------------------------------------------
>
> Key: OVIRT-621
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-621
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: David Caro
> Assignee: infra
> Attachments: signature.asc
>
>
> The issue being that in order to run the fc24 chroots, it needs the correct gpg
> key for the fc24 repos, and that is included only in a newer mock version, that
> will not be released for fc21 (as it reached it's end of life).
> So possibilities are:
> * manually deploy the keys (puppet?)
> * build a custom mock package with the newer version and install that
> * upgrade the slaves (something that we should do anyhow, sooner than later)
> * remove all the fc24 jobs we added (lago in specific)
> In the meantime, some fc24 builds can't be done (for example, lago is blocked
> by this).
> Cheers!
> --
> David Caro
--
This message was sent by Atlassian JIRA
(v1000.126.2#100004)
7 years, 10 months
[JIRA] (OVIRT-621) Upgrade of the fc21 vms required to run fc24 chroots
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-621?page=com.atlassian.jira... ]
eyal edri [Administrator] commented on OVIRT-621:
-------------------------------------------------
There is already a ticket on reprovisioning f21 slaves with f24: https://ovirt-jira.atlassian.net/browse/OVIRT-584
due to puppet issues.
Its holiday now in Brno, so not too many people are around, hopefully we can tackle this tomorrow or next week.
[~ngoldin(a)redhat.com] - can you give it a try for one VM?
> Upgrade of the fc21 vms required to run fc24 chroots
> ----------------------------------------------------
>
> Key: OVIRT-621
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-621
> Project: oVirt - virtualization made easy
> Issue Type: By-EMAIL
> Reporter: David Caro
> Assignee: infra
> Attachments: signature.asc
>
>
> The issue being that in order to run the fc24 chroots, it needs the correct gpg
> key for the fc24 repos, and that is included only in a newer mock version, that
> will not be released for fc21 (as it reached it's end of life).
> So possibilities are:
> * manually deploy the keys (puppet?)
> * build a custom mock package with the newer version and install that
> * upgrade the slaves (something that we should do anyhow, sooner than later)
> * remove all the fc24 jobs we added (lago in specific)
> In the meantime, some fc24 builds can't be done (for example, lago is blocked
> by this).
> Cheers!
> --
> David Caro
--
This message was sent by Atlassian JIRA
(v1000.126.2#100004)
7 years, 10 months
[JIRA] (OVIRT-621) Upgrade of the fc21 vms required to run fc24 chroots
by David Caro (oVirt JIRA)
David Caro created OVIRT-621:
--------------------------------
Summary: Upgrade of the fc21 vms required to run fc24 chroots
Key: OVIRT-621
URL: https://ovirt-jira.atlassian.net/browse/OVIRT-621
Project: oVirt - virtualization made easy
Issue Type: By-EMAIL
Reporter: David Caro
Assignee: infra
Attachments: signature.asc
The issue being that in order to run the fc24 chroots, it needs the correct gpg
key for the fc24 repos, and that is included only in a newer mock version, that
will not be released for fc21 (as it reached it's end of life).
So possibilities are:
* manually deploy the keys (puppet?)
* build a custom mock package with the newer version and install that
* upgrade the slaves (something that we should do anyhow, sooner than later)
* remove all the fc24 jobs we added (lago in specific)
In the meantime, some fc24 builds can't be done (for example, lago is blocked
by this).
Cheers!
--
David Caro
--
This message was sent by Atlassian JIRA
(v1000.126.1#100004)
7 years, 10 months
Re: Fwd: Re: [oVirt-Infra] : New Gateway
by Michael Scherer
--=-TsLC1+TQtXJ+Qzkr5Z24
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Le mardi 28 juin 2016 =C3=A0 10:14 -0400, Dave Neary a =C3=A9crit :
> FYI.
> ----- Forwarded Message -----
> From: Herv=C3=A9 Leclerc <herve.leclerc(a)alterway.fr>
> To: Dave Neary <dneary(a)redhat.com>, Infra(a)ovirt.org
> Cc: Arnaud CAZIN <arnaud.cazin(a)alterway.fr>, St=C3=A9phane Vincent <steph=
ane.vincent(a)alterway.fr>
> Sent: Mon, 27 Jun 2016 13:06:17 -0400 (EDT)
> Subject: Re: [oVirt-Infra] : New Gateway
>=20
> Hello,
>=20
> Did you made the changes asked ?
> Can you please give us a status on your actions.
I stopped rpcbind, which sould solve the problem.
But I wonder why we didn't got the mail in the first time, it didn't
appear on the list, nor in moderation.=20
> Regards
>=20
>=20
>=20
> Herv=C3=A9 Leclerc
> CTO
> Alter Way
> 227 Bureaux de la colline
> 1 rue Royale - B=C3=A2t. D
> 92210 Saint-Cloud
> France
> *+33 141168336*
> +33 6 83979598
>=20
>=20
>=20
> `like a halo in reverse`
>=20
>=20
>=20
> On Sun, Jun 26, 2016 at 3:54 PM, Herv=C3=A9 Leclerc <herve.leclerc@alterw=
ay.fr>
> wrote:
>=20
> > Hello
> >
> > Your vm alterway02.ovirt.org is participating in a ddos attack. Could
> > please correct the problem rapidly !
> > eg.
> > iptables -A INPUT -p udp --dport 111 -j DROP
> >
> >
> >
> > Regards
> >
> > Original message
> > A public-facing device on your network, running on IP address 89.31.
> > 150.216, operates a RPC port mapping service responding on UDP port 111
> > and participated in a large-scale attack against a customer of ours,
> > generating responses to spoofed requests that claimed to be from the at=
tack
> > target.
> >
> > Please consider reconfiguring this server in one or more of these ways:
> >
> > 1. Adding a firewall rule to block all access to this host's UDP port 1=
11
> > at your network edge (it would continue to be available on TCP port 111=
in
> > this case).
> > 2. Adding firewall rules to allow connections to this service (on UDP p=
ort
> > 111) from authorized endpoints but block connections from all other hos=
ts.
> > 3. Disabling the port mapping service entirely (if it is not needed).
> >
> > More information on this attack vector can be found at this third-party
> > website (we did not create this content):
> > http://blog.level3.com/security/a-new-ddos-reflection-attack-portmapper=
-an-early-warning-to-the-industry/
> >
> > Example responses from the host during this attack are given below.
> > Date/timestamps (far left) are UTC.
> >
> > 2016-06-25 22:46:44.588895 IP 89.31.150.216.111 > 74.201.57.x.80: UDP,
> > length 628
> > 0x0000: 4500 0290 0000 4000 3111 d378 591f 96d8 E.....@.1..xY=
...
> > 0x0010: 4ac9 3924 006f 0050 027c dc65 6572 0a37 J.9$.o.P.|.ee=
r.7
> > 0x0020: 0000 0001 0000 0000 0000 0000 0000 0000 .............=
...
> > 0x0030: 0000 0000 0000 0001 0001 86a0 0000 0004 .............=
...
> > 0x0040: 0000 0006 0000 006f 0000 0001 0001 86a0 .......o.....=
...
> > 0x0050: 0000 ..
> > 2016-06-25 22:46:44.588939 IP 89.31.150.216.111 > 74.201.57.x.80: UDP,
> > length 628
> > 0x0000: 4500 0290 0000 4000 3111 d378 591f 96d8 E.....@.1..xY=
...
> > 0x0010: 4ac9 3924 006f 0050 027c dc65 6572 0a37 J.9$.o.P.|.ee=
r.7
> > 0x0020: 0000 0001 0000 0000 0000 0000 0000 0000 .............=
...
> > 0x0030: 0000 0000 0000 0001 0001 86a0 0000 0004 .............=
...
> > 0x0040: 0000 0006 0000 006f 0000 0001 0001 86a0 .......o.....=
...
> > 0x0050: 0000 ..
> > 2016-06-25 22:46:45.048914 IP 89.31.150.216.111 > 74.201.57.x.80: UDP,
> > length 628
> > 0x0000: 4500 0290 0000 4000 3111 d378 591f 96d8 E.....@.1..xY=
...
> > 0x0010: 4ac9 3924 006f 0050 027c dc65 6572 0a37 J.9$.o.P.|.ee=
r.7
> > 0x0020: 0000 0001 0000 0000 0000 0000 0000 0000 .............=
...
> > 0x0030: 0000 0000 0000 0001 0001 86a0 0000 0004 .............=
...
> > 0x0040: 0000 0006 0000 006f 0000 0001 0001 86a0 .......o.....=
...
> > 0x0050: 0000 ..
> > 2016-06-25 22:46:45.048963 IP 89.31.150.216.111 > 74.201.57.x.80: UDP,
> > length 628
> > 0x0000: 4500 0290 0000 4000 3111 d378 591f 96d8 E.....@.1..xY=
...
> > 0x0010: 4ac9 3924 006f 0050 027c dc65 6572 0a37 J.9$.o.P.|.ee=
r.7
> > 0x0020: 0000 0001 0000 0000 0000 0000 0000 0000 .............=
...
> > 0x0030: 0000 0000 0000 0001 0001 86a0 0000 0004 .............=
...
> > 0x0040: 0000 0006 0000 006f 0000 0001 0001 86a0 .......o.....=
...
> > 0x0050: 0000 ..
> >
> > (The final octet of our customer's IP address is masked in the above
> > output because some automatic parsers become confused when multiple IP
> > addresses are included. The value of that octet is "36".)
> >
> > -John
> > President
> > Nuclearfallout, Enterprises, Inc. (NFOservers.com)
> >
> > (We're sending out so many of these notices, and seeing so many
> > auto-responses, that we can't go through this email inbox effectively. =
If
> > you have follow-up questions, please contact us at noc(a)nfoe.net.)
> >
> > Herv=C3=A9 Leclerc
> > CTO
> > Alter Way
> > 227 Bureaux de la colline
> > 1 rue Royale - B=C3=A2t. D
> > 92210 Saint-Cloud
> > France
> > *+33 141168336 <%2B33%20141168336>*
> > +33 6 83979598
> >
> >
> >
> > `like a halo in reverse`
> >
> >
> >
> > On Wed, Feb 19, 2014 at 10:46 AM, Herv=C3=A9 Leclerc <herve.leclerc@alt=
erway.fr
> > > wrote:
> >
> >> Hello,
> >>
> >> Our Internet gateway is changing.
> >> Could you please change your actual gateway (*89.31.150.249*) on your
> >> machines (89.31.150.215 and 216) and vms to *89.31.150.253*
> >> Thanks
> >>
> >> Let us know when this modification is done.
> >>
> >> Cheers
> >>
> >> Herv=C3=A9 Leclerc
> >> CTO
> >> Alter Way
> >> 1, rue royale
> >> 9 =C3=A8me =C3=A9tage
> >> 92210 St Cloud
> >> *+33 1 41 16 83 36 <%2B33%201%2041%2016%2083%2036>*
> >> +33 6 83979598
> >>
> >>
> >>
> >>
> >> <http://www.alterway.fr/signatures/url/1>
> >>
> >>
> >>
> >>
> >
>=20
--=20
Michael Scherer
Sysadmin, Community Infrastructure and Platform, OSAS
--=-TsLC1+TQtXJ+Qzkr5Z24
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part
Content-Transfer-Encoding: 7bit
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJXcoiiAAoJEE89Wa+PrSK9nKAP/2yufHdT4ISBe/IuaJttfu7H
wLT/a6KLRGJ2y7Ifs11OxS/PJOrV4Z9T4Wtn/3oG87xsNMShNUZlvWSEF/TCQcR0
Hr6BQTimIRbCWbZ9xdvO9ieaNPiv3EF6VEw4jKToH2Vgwy/xkQAOZZGFt7Wyp6Kd
IuABhhM/vaJ6vBeyFx5pNZPbXTqEOy/D2KMhwJFLLXk4UlzpZlMVBHDtQQ1WS6fN
XoJQwqG/KecqiiebwYIIHfirGA7H+ufF7vvnjlgRKiyVuPzS8N5/0q3PDIfWRIol
VImUJj8FY9gupzkizAWqI8X570Hmzwfedb6V9S/E2XTzi6XqfpBsM2sAp7DGATBl
q3AT7UuScq0Y33mqYkeVrSvq9sfhAP1ZxBK8Emj2NKmiAthB1sEmvjcT5FHUp0F2
K+trprkEBoodvVcD9+HiefC8xuuBgHAnNdYXAglBLoOdYzD6eQyVCz823VfWn9+E
sS0pWIXFjssKr9Qpigb2y55FmuIaSPfCjekCQyg5AwKJYsgT/50OkR+ab1eSfjEY
NJ12TKyMOpWXfZAskeQ5DFVXgYe5hbohmSs3vrfeqnFIuXsamn3lzKW6EVK3IE6z
3RyX6lDKq1yVHZTK7J2EPZ4o+mx7NNHR7dE2Fp8mMapTLMEWjIh6D2wFkRp2x+hO
VEevgXHkCTXrCYXfo5yi
=OVh1
-----END PGP SIGNATURE-----
--=-TsLC1+TQtXJ+Qzkr5Z24--
7 years, 10 months
resources/pub/yum-repo
by Yedidyah Bar David
Hi all,
Following a report on users@ about not-up-to-date ovirt-release36.rpm
in $subject, I had a look, then did:
# pwd
/var/www/html/pub/yum-repo
# mkdir bck-2016-07-05
# mv ovirt-release36.rpm bck-2016-07-05 && ln -s
../ovirt-3.6/rpm/el7/noarch/ovirt-release36.rpm
# mv ovirt-release36-snapshot.rpm bck-2016-07-05 && ln -s
../ovirt-3.6/rpm/el7/noarch/ovirt-release36-snapshot.rpm
# mv ovirt-release-master.rpm bck-2016-07-05 && ln -s
../ovirt-master-snapshot/rpm/el7/noarch/ovirt-release-master.rpm
# mv ovirt-release40-snapshot.rpm bck-2016-07-05 && ln -s
../ovirt-4.0-snapshot/rpm/el7/noarch/ovirt-release40-snapshot.rpm
# mv ovirt-release40.rpm bck-2016-07-05 && ln -s
../ovirt-4.0/rpm/el7/noarch/ovirt-release40.rpm
# ls -l ovirt-release*
-rw-r--r--. 1 root root 6408 Jul 28 2014 ovirt-release33.rpm
-rw-r--r--. 1 root root 7968 Sep 9 2014 ovirt-release34.rpm
-rw-r--r--. 2 root root 13904 Nov 10 2015 ovirt-release35.rpm
lrwxrwxrwx. 1 root root 47 Jul 5 19:39 ovirt-release36.rpm ->
../ovirt-3.6/rpm/el7/noarch/ovirt-release36.rpm
lrwxrwxrwx. 1 root root 56 Jul 5 19:41
ovirt-release36-snapshot.rpm ->
../ovirt-3.6/rpm/el7/noarch/ovirt-release36-snapshot.rpm
lrwxrwxrwx. 1 root root 47 Jul 5 19:48 ovirt-release40.rpm ->
../ovirt-4.0/rpm/el7/noarch/ovirt-release40.rpm
lrwxrwxrwx. 1 root root 65 Jul 5 19:46
ovirt-release40-snapshot.rpm ->
../ovirt-4.0-snapshot/rpm/el7/noarch/ovirt-release40-snapshot.rpm
lrwxrwxrwx. 1 root root 64 Jul 5 19:44 ovirt-release-master.rpm ->
../ovirt-master-snapshot/rpm/el7/noarch/ovirt-release-master.rpm
Also, I noticed we have there repodata, i.e. this is a yum repo itself.
If it's indeed used as one anywhere, the above will break it - because
the symlinks will automatically change during releases or nightly
builds, and the repo metadata will not be updated. Is it indeed used?
If so, we should probably do something about this - either revert my
change and have something else that copies the files (and runs
createrepo), or something else that runs createrepo frequently/as
needed.
Best,
--
Didi
7 years, 10 months
[JIRA] (OVIRT-620) Optimize how Jenkins fetchs ovirt-engine from gerrit
by eyal edri [Administrator] (oVirt JIRA)
[ https://ovirt-jira.atlassian.net/browse/OVIRT-620?page=com.atlassian.jira... ]
eyal edri [Administrator] commented on OVIRT-620:
-------------------------------------------------
I would say lets give it a try on the ovirt engine jobs
On Jul 5, 2016 3:15 PM, "Nadav Goldin (oVirt JIRA)" <
> Optimize how Jenkins fetchs ovirt-engine from gerrit
> ----------------------------------------------------
>
> Key: OVIRT-620
> URL: https://ovirt-jira.atlassian.net/browse/OVIRT-620
> Project: oVirt - virtualization made easy
> Issue Type: Sub-task
> Reporter: Nadav Goldin
> Assignee: infra
>
> ovirt-engine git repository is at the time of writing is of size 244MB, where ovirt-engine/.git alone takes 160MB.
> There are two things which might be done:
> 1. Find a way to optimize ovirt-engine.git/.git size, this needs to be explored deeply.
> 2. Check if it is possible to configure git plugin to not download the entire history, although Jenkins attempts to optimize that, it still looks like the git plugin is downloading the entire history(this is what a random check on the slaves using du ../jenkins/workspace/...../.git -h -s showed)
> for instance the following command takes only 91Mb:
> {quote}git clone --depth 1 --branch master {quote}
> Although this will not solve real network/storage issues, it could help reduce those problems and in the overall decrease jobs runtime. As Gerrit is still on AWS, this is a considerable amount of traffic for each job we might be able to reduce.
--
This message was sent by Atlassian JIRA
(v1000.126.1#100004)
7 years, 10 months