Re: Change in ovirt-wgt[master]: Correct path to QEMU GA MSI files

[Vinzenz Feenstra]

> On Jun 23, 2016, at 9:30 AM, Barak Korren  wrote:
> 
>> 
>> I now retriggered the job and it finished successfully.
>> 
> Probably some other package got updates on resources in the meantime
> which cause the repomd to be rebuilt.
> 
>> Last night I downloaded the files from resources.ovirt.org and from jenkins
>> and compared them.
>> 
>> cmp -l on them was very long.
>> 
>> opened them with rpm2cpio, and the cpio files were very similar - didn't
>> check the diff, likely timestamp or something like that.
>> 
>> No idea how signatures/checksum etc work in rpm.
> 
> This is still concerning, perhaps we better rebuild the package to
> ensure we have the right version on resources.

It actually works already again and must have been a temporary hiccup

> 
> 
> -- 
> Barak Korren
> bkor...@redhat.com
> RHEV-CI Team
> ___
> Infra mailing list
> Infra@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/infra

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Random jenkins failures

[Vinzenz Feenstra]

I have just submitted a set of 4 patches where 1 patch unit tests failed with 
the pasted text below. Those patches are absolutely unrelated to those failures.

Please check into those issues - Thanks 

http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/2168/console


12:15:21 
12:15:21 ==
12:15:21 ERROR: testLoopMount (mountTests.MountTests)
12:15:21 --
12:15:21 Traceback (most recent call last):
12:15:21   File 
"/home/jenkins/workspace/vdsm_master_check-patch-fc23-x86_64/vdsm/tests/mountTests.py",
 line 128, in testLoopMount
12:15:21 m.mount(mntOpts="loop")
12:15:21   File 
"/home/jenkins/workspace/vdsm_master_check-patch-fc23-x86_64/vdsm/vdsm/storage/mount.py",
 line 225, in mount
12:15:21 return self._runcmd(cmd, timeout)
12:15:21   File 
"/home/jenkins/workspace/vdsm_master_check-patch-fc23-x86_64/vdsm/vdsm/storage/mount.py",
 line 241, in _runcmd
12:15:21 raise MountError(rc, ";".join((out, err)))
12:15:21 MountError: (32, ';mount: /tmp/tmpsDTh9u: failed to setup loop device: 
No such file or directory\n')
12:15:21  >> begin captured logging << 
12:15:21 Storage.Misc.excCmd: DEBUG: /usr/bin/taskset --cpu-list 0-1 
/sbin/mkfs.ext2 -F /tmp/tmpsDTh9u (cwd None)
12:15:21 Storage.Misc.excCmd: DEBUG: SUCCESS:  = 'mke2fs 1.42.13 
(17-May-2015)\n';  = 0
12:15:21 Storage.Misc.excCmd: DEBUG: /usr/bin/taskset --cpu-list 0-1 
/usr/bin/mount -o loop /tmp/tmpsDTh9u /var/tmp/tmpTPj7t6 (cwd None)
12:15:21 - >> end captured logging << -
12:15:21 
12:15:21 ==
12:15:21 ERROR: testSymlinkMount (mountTests.MountTests)
12:15:21 --
12:15:21 Traceback (most recent call last):
12:15:21   File 
"/home/jenkins/workspace/vdsm_master_check-patch-fc23-x86_64/vdsm/tests/mountTests.py",
 line 150, in testSymlinkMount
12:15:21 m.mount(mntOpts="loop")
12:15:21   File 
"/home/jenkins/workspace/vdsm_master_check-patch-fc23-x86_64/vdsm/vdsm/storage/mount.py",
 line 225, in mount
12:15:21 return self._runcmd(cmd, timeout)
12:15:21   File 
"/home/jenkins/workspace/vdsm_master_check-patch-fc23-x86_64/vdsm/vdsm/storage/mount.py",
 line 241, in _runcmd
12:15:21 raise MountError(rc, ";".join((out, err)))
12:15:21 MountError: (32, ';mount: /var/tmp/tmpBpSrGA/backing.img: failed to 
setup loop device: No such file or directory\n')
12:15:21  >> begin captured logging << 
12:15:21 Storage.Misc.excCmd: DEBUG: /usr/bin/taskset --cpu-list 0-1 
/sbin/mkfs.ext2 -F /var/tmp/tmpBpSrGA/backing.img (cwd None)
12:15:21 Storage.Misc.excCmd: DEBUG: SUCCESS:  = 'mke2fs 1.42.13 
(17-May-2015)\n';  = 0
12:15:21 Storage.Misc.excCmd: DEBUG: /usr/bin/taskset --cpu-list 0-1 
/usr/bin/mount -o loop /var/tmp/tmpBpSrGA/link_to_image 
/var/tmp/tmpBpSrGA/mountpoint (cwd None)
12:15:21 - >> end captured logging << -
12:15:21 
12:15:21 ==
12:15:21 ERROR: test_getDevicePartedInfo (parted_utils_tests.PartedUtilsTests)
12:15:21 --
12:15:21 Traceback (most recent call last):
12:15:21   File 
"/home/jenkins/workspace/vdsm_master_check-patch-fc23-x86_64/vdsm/tests/testValidation.py",
 line 97, in wrapper
12:15:21 return f(*args, **kwargs)
12:15:21   File 
"/home/jenkins/workspace/vdsm_master_check-patch-fc23-x86_64/vdsm/tests/parted_utils_tests.py",
 line 61, in setUp
12:15:21 self.assertEquals(rc, 0)
12:15:21 AssertionError: 1 != 0
12:15:21  >> begin captured logging << 
12:15:21 root: DEBUG: /usr/bin/taskset --cpu-list 0-1 dd if=/dev/zero 
of=/tmp/tmpNOvAvX bs=100M count=1 (cwd None)
12:15:21 root: DEBUG: SUCCESS:  = '1+0 records in\n1+0 records 
out\n104857600 bytes (105 MB) copied, 0.373591 s, 281 MB/s\n';  = 0
12:15:21 root: DEBUG: /usr/bin/taskset --cpu-list 0-1 losetup -f --show 
/tmp/tmpNOvAvX (cwd None)
12:15:21 root: DEBUG: FAILED:  = 'losetup: /tmp/tmpNOvAvX: failed to set 
up loop device: No such file or directory\n';  = 1
12:15:21 - >> end captured logging << -
12:15:21

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Random jenkins failures

[Vinzenz Feenstra]

> On Jan 13, 2016, at 1:20 PM, Vinzenz Feenstra <vfeen...@redhat.com> wrote:
> 
> I have just submitted a set of 4 patches where 1 patch unit tests failed with 
> the pasted text below. Those patches are absolutely unrelated to those 
> failures.
> 
> Please check into those issues - Thanks 

It happened again 
http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/2186/console

13:06:47 ==
13:06:47 ERROR: testLoopMount (mountTests.MountTests)
13:06:47 --
13:06:47 Traceback (most recent call last):
13:06:47   File 
"/home/jenkins/workspace/vdsm_master_check-patch-fc23-x86_64/vdsm/tests/mountTests.py",
 line 128, in testLoopMount
13:06:47 m.mount(mntOpts="loop")
13:06:47   File 
"/home/jenkins/workspace/vdsm_master_check-patch-fc23-x86_64/vdsm/vdsm/storage/mount.py",
 line 225, in mount
13:06:47 return self._runcmd(cmd, timeout)
13:06:47   File 
"/home/jenkins/workspace/vdsm_master_check-patch-fc23-x86_64/vdsm/vdsm/storage/mount.py",
 line 241, in _runcmd
13:06:47 raise MountError(rc, ";".join((out, err)))
13:06:47 MountError: (32, ';mount: /tmp/tmpl2jG_h: failed to setup loop device: 
No such file or directory\n')
13:06:47  >> begin captured logging << 
13:06:47 Storage.Misc.excCmd: DEBUG: /usr/bin/taskset --cpu-list 0-1 
/sbin/mkfs.ext2 -F /tmp/tmpl2jG_h (cwd None)
13:06:47 Storage.Misc.excCmd: DEBUG: SUCCESS:  = 'mke2fs 1.42.13 
(17-May-2015)\n';  = 0
13:06:47 Storage.Misc.excCmd: DEBUG: /usr/bin/taskset --cpu-list 0-1 
/usr/bin/mount -o loop /tmp/tmpl2jG_h /var/tmp/tmpRslb5M (cwd None)
13:06:47 - >> end captured logging << -
13:06:47 
13:06:47 ==
13:06:47 ERROR: testSymlinkMount (mountTests.MountTests)
13:06:47 --
13:06:47 Traceback (most recent call last):
13:06:47   File 
"/home/jenkins/workspace/vdsm_master_check-patch-fc23-x86_64/vdsm/tests/mountTests.py",
 line 150, in testSymlinkMount
13:06:47 m.mount(mntOpts="loop")
13:06:47   File 
"/home/jenkins/workspace/vdsm_master_check-patch-fc23-x86_64/vdsm/vdsm/storage/mount.py",
 line 225, in mount
13:06:47 return self._runcmd(cmd, timeout)
13:06:47   File 
"/home/jenkins/workspace/vdsm_master_check-patch-fc23-x86_64/vdsm/vdsm/storage/mount.py",
 line 241, in _runcmd
13:06:47 raise MountError(rc, ";".join((out, err)))
13:06:47 MountError: (32, ';mount: /var/tmp/tmpTeUZUl/backing.img: failed to 
setup loop device: No such file or directory\n')
13:06:47  >> begin captured logging << 
13:06:47 Storage.Misc.excCmd: DEBUG: /usr/bin/taskset --cpu-list 0-1 
/sbin/mkfs.ext2 -F /var/tmp/tmpTeUZUl/backing.img (cwd None)
13:06:47 Storage.Misc.excCmd: DEBUG: SUCCESS:  = 'mke2fs 1.42.13 
(17-May-2015)\n';  = 0
13:06:47 Storage.Misc.excCmd: DEBUG: /usr/bin/taskset --cpu-list 0-1 
/usr/bin/mount -o loop /var/tmp/tmpTeUZUl/link_to_image 
/var/tmp/tmpTeUZUl/mountpoint (cwd None)
13:06:47 - >> end captured logging << -
13:06:47 
13:06:47 ==
13:06:47 ERROR: test_getDevicePartedInfo (parted_utils_tests.PartedUtilsTests)
13:06:47 --
13:06:47 Traceback (most recent call last):
13:06:47   File 
"/home/jenkins/workspace/vdsm_master_check-patch-fc23-x86_64/vdsm/tests/testValidation.py",
 line 97, in wrapper
13:06:47 return f(*args, **kwargs)
13:06:47   File 
"/home/jenkins/workspace/vdsm_master_check-patch-fc23-x86_64/vdsm/tests/parted_utils_tests.py",
 line 61, in setUp
13:06:47 self.assertEquals(rc, 0)
13:06:47 AssertionError: 1 != 0
13:06:47  >> begin captured logging << 
13:06:47 root: DEBUG: /usr/bin/taskset --cpu-list 0-1 dd if=/dev/zero 
of=/tmp/tmp7dS7VS bs=100M count=1 (cwd None)
13:06:47 root: DEBUG: SUCCESS:  = '1+0 records in\n1+0 records 
out\n104857600 bytes (105 MB) copied, 0.350029 s, 300 MB/s\n';  = 0
13:06:47 root: DEBUG: /usr/bin/taskset --cpu-list 0-1 losetup -f --show 
/tmp/tmp7dS7VS (cwd None)
13:06:47 root: DEBUG: FAILED:  = 'losetup: /tmp/tmp7dS7VS: failed to set 
up loop device: No such file or directory\n';  = 1


> 
> http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/2168/console 
> <http://jenkins.ovirt.org/job/vdsm_master_check-patch-fc23-x86_64/2168/console>
> 
> 
> 12:15:21 
> 12:15:21 
> ==

Re: ovirt-guest-agent

[Vinzenz Feenstra]

On 07/11/2014 09:02 AM, Sandro Bonazzola wrote:

Hi,
looking at http://jenkins.ovirt.org/view/All/
I see that for ovirt-guest-agent there's only the following job: 
http://jenkins.ovirt.org/view/All/job/ovirt-guest-agent_master_gerrit/
This means that ovirt-guest-agent is not built nightly neither for master nor 
for stable and it's not published neither in nightly snapshot nor in
official releases.

Yeah it never has been built nightly.

I see that ovirt-guest-agent is shipped within Fedora and EPEL: 
http://koji.fedoraproject.org/koji/packageinfo?packageID=15434
so I suppose official release are shipped there.

Yes

Do we need nightly builds?
It would be great if we would have nightly builds. Or at some trigger 
after merges, as the guest agent has not such a high volume of patches, 
nightly might be overkill, at least for now.

Also I see that http://www.ovirt.org/How_to_install_the_guest_agent_in_Fedora 
refers to obsolete layout / releases and the package is not shipped
within oVirt repo for above considerations and should be updated accordingly.
True, and now looking at it, I have to say that I am surprised that the 
guest agent builds aren't included in the ovirt releases anymore. 
Usually they were including the latest koji builds. (At least from my 
knowledge) that does not seem to be the case anymore. when looking at: 
http://resources.ovirt.org/releases/3.4/rpm/fc20/noarch/ for example.


--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R  D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Please install libtool on 'remote_slave_jnlp_dell01'

[Vinzenz Feenstra]

Hi,

My current ovirt-guest-agent unit tests are failing because the libtool rpm is 
missing on the system.

Please add it there. Thanks.

--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R  D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [oVirt Jenkins] vdsm_unit_tests - Build # 2492 - Still Failing!

[Vinzenz Feenstra]

On 11/07/2013 11:36 AM, Dan Kenigsberg wrote:

Dear infra,

Would you install
http://kojipkgs.fedoraproject.org//packages/python-cpopen/1.2.3/4.el6/x86_64/python-cpopen-1.2.3-4.el6.x86_64.rpm
on centos64-vm02 (and any other slave running el6 vdsm_unit_tests?

Has the package been downgraded since (the successful)
http://jenkins.ovirt.org/job/vdsm_unit_tests/2489/ ?

I do not know why that build is not yet on EPEL6, but its maintainer is
at large until Monday. Missing this version gives annoying false
negatives.
I hope that this the version which fixes the broken version 1.2.3-3 
which is on Fedora 18,19,20 failing because of a wrong import.


On Thu, Nov 07, 2013 at 09:27:34AM +, Jenkins ci oVirt Server wrote:

Project: http://jenkins.ovirt.org/job/vdsm_unit_tests/
Build: http://jenkins.ovirt.org/job/vdsm_unit_tests/2492/
Build Number: 2492
Build Status:  Still Failing
Triggered By: Started by an SCM change



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R  D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: [oVirt Jenkins] vdsm_unit_tests - Build # 2492 - Still Failing!

[Vinzenz Feenstra]

On 11/07/2013 01:08 PM, Dan Kenigsberg wrote:

On Thu, Nov 07, 2013 at 06:12:48AM -0500, Eyal Edri wrote:


- Original Message -

From: Vinzenz Feenstra vfeen...@redhat.com
To: Dan Kenigsberg dan...@redhat.com
Cc: infra@ovirt.org, oba...@redhat.com, ee...@redhat.com, aba...@redhat.com, 
vdsm-patc...@lists.fedorahosted.org,
dc...@redhat.com
Sent: Thursday, November 7, 2013 12:50:38 PM
Subject: Re: [oVirt Jenkins] vdsm_unit_tests - Build # 2492 - Still Failing!

On 11/07/2013 11:36 AM, Dan Kenigsberg wrote:

Dear infra,

Would you install
http://kojipkgs.fedoraproject.org//packages/python-cpopen/1.2.3/4.el6/x86_64/python-cpopen-1.2.3-4.el6.x86_64.rpm
on centos64-vm02 (and any other slave running el6 vdsm_unit_tests?

Has the package been downgraded since (the successful)
http://jenkins.ovirt.org/job/vdsm_unit_tests/2489/ ?

I do not know why that build is not yet on EPEL6, but its maintainer is
at large until Monday. Missing this version gives annoying false
negatives.

I hope that this the version which fixes the broken version 1.2.3-3
which is on Fedora 18,19,20 failing because of a wrong import.

Yes. Vinzenz, do you have any clue why -4 is not (yet) poshed to bodhi?
https://admin.fedoraproject.org/updates/search/python-cpopen

Unfortunately not
Douglas any update on that front?



On Thu, Nov 07, 2013 at 09:27:34AM +, Jenkins ci oVirt Server wrote:

Project: http://jenkins.ovirt.org/job/vdsm_unit_tests/
Build: http://jenkins.ovirt.org/job/vdsm_unit_tests/2492/
Build Number: 2492
Build Status:  Still Failing
Triggered By: Started by an SCM change

update manually for now on our centos64 slaves.
but i think we should ensure latest on our slave for all packages when they are 
available. [1]

[1] http://gerrit.ovirt.org/#/c/21021/

Would this allow newer-than-latest in rare conditions such as now?




--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R  D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: frequent gerrit.ovirt.org session expiry

[Vinzenz Feenstra]

On 10/09/2013 11:20 PM, Yaniv Dary wrote:

Didn't help.
Hmm I haven't had to login now for the past two days, which was not like 
this before. For me it improved the experience.

Thanks for the adjustment.

- Original Message -

From: David Caro Estevez dcaro...@redhat.com
To: Dan Kenigsberg dan...@redhat.com
Cc: infra infra@ovirt.org
Sent: Monday, October 7, 2013 12:43:10 PM
Subject: Re: frequent gerrit.ovirt.org session expiry

I've made some adjustments to the session cache expiration time and related
parameters, but as I've not been able to reproduce the problem, can you ping
me again if it was not solved?

Thanks!

- Original Message -

From: Dan Kenigsberg dan...@redhat.com
To: infra infra@ovirt.org
Sent: Sunday, October 6, 2013 11:36:41 AM
Subject: frequent gerrit.ovirt.org session expiry

Hi,

Recently (for two weeks, maybe?) my gerrit sessions expire several times
a day. Do others experience this? Is this change intentional?

In the past, I had to login only once a day, which I find too frequent
on it's own right. Can the session expiry time be lengthened? Can we
allow multiple sessions, from different devices, for the same user?

Regards,
Dan.
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R  D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: frequent gerrit.ovirt.org session expiry

[Vinzenz Feenstra]

On 10/09/2013 11:20 PM, Yaniv Dary wrote:

Didn't help.
Hmm I haven't had to login now for the past two days, which was not like 
this before. For me it improved the experience.

Thanks for the adjustment.

- Original Message -

From: David Caro Estevez dcaro...@redhat.com
To: Dan Kenigsberg dan...@redhat.com
Cc: infra infra@ovirt.org
Sent: Monday, October 7, 2013 12:43:10 PM
Subject: Re: frequent gerrit.ovirt.org session expiry

I've made some adjustments to the session cache expiration time and related
parameters, but as I've not been able to reproduce the problem, can you ping
me again if it was not solved?

Thanks!

- Original Message -

From: Dan Kenigsberg dan...@redhat.com
To: infra infra@ovirt.org
Sent: Sunday, October 6, 2013 11:36:41 AM
Subject: frequent gerrit.ovirt.org session expiry

Hi,

Recently (for two weeks, maybe?) my gerrit sessions expire several times
a day. Do others experience this? Is this change intentional?

In the past, I had to login only once a day, which I find too frequent
on it's own right. Can the session expiry time be lengthened? Can we
allow multiple sessions, from different devices, for the same user?

Regards,
Dan.
___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra


___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R  D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Security

[Vinzenz Feenstra]

Hi,

I see again quite a lot of POSSIBLE BREAK-IN ATTEMPT alerts lately 
mainly originating from *hichina.com


Could you guys please address this? Thanks

On 10/09/2013 09:15 AM, logwa...@linode01.ovirt.org wrote:
  
  SFTP subsystem requests: 2 Time(s)
  
  **Unmatched Entries**

  Address 198.7.63.240 maps to hosted-by.leaseweb.com, but this does not map 
back to the address - POSSIBLE BREAK-IN ATTEMPT! : 6 time(s)
  reverse mapping checking getaddrinfo for ip223.hichina.com [223.4.145.38] 
failed - POSSIBLE BREAK-IN ATTEMPT! : 455 time(s)
  



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R  D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Fwd: Adding Vinzenz as a maintainer of ovirt-guest-agent

[Vinzenz Feenstra]

seems the original message didn't reach infra@ as I can't find it in the 
archives, resending...


Begin forwarded message:


From: Barak Azulay bazu...@redhat.com
Subject: Adding Vinzenz as a maintainer of ovirt-guest-agent
Date: September 24, 2013 13:22:28 GMT+02:00
To: infra@ovirt.org
Cc: bo...@ovirt.org, Michal Skrivanek mskri...@redhat.com

Hi,

Over the past year, Vinzenz has been the de-facto maintainer of the
ovirt-guest-agent project, and I'm moving the reins over to him.
I'll continue to be in the picture.
please provide him with relevant gerrit permissions.

Thanks
Barak Azulay




___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Logwatch for linode01.ovirt.org (Linux)

[Vinzenz Feenstra]

On 04/24/2013 10:20 AM, logwa...@linode01.ovirt.org wrote:

  reverse mapping checking getaddrinfo for 226-121-162-69.reverse.lstn.net 
[69.162.121.226] failed - POSSIBLE BREAK-IN ATTEMPT! : 604 time(s)
I see this in the logs for the past few days always from the same IP, I 
think this is a bit odd.
Especially that there are few hundred of them every day. In the previous 
2 days it was above 800 times.


It'd be good to check what's going on there.

--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R  D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Fedora Open ID issue

[Vinzenz Feenstra]

On 03/06/2013 10:27 AM, Fabian Deutsch wrote:

Am Mittwoch, den 06.03.2013, 03:51 -0500 schrieb Vered Volansky:

FYI, Fedora Open ID users,

They changed the log in url ( https://fedoraproject.org/wiki/OpenID ).
The change was published in a post today - 
http://lists.fedoraproject.org/pipermail/announce/2013-March/003146.html .
The old openid url is no longer valid, and the new one creates a totally new 
account in gerrit.
You can't link to the old one since that url is no longer valid, so we 
basically don't have gerrit access.

I opened a ticket: https://fedorahosted.org/fedora-infrastructure/ticket/3696 .

I'll update here if and when there's anything new.

Hey,

I also had this problem.
I tried just entering userid.id.fedoraproject.org (without http and
https, as recommended here [0]) and that worked for me.

Greetings
fabian

[0] https://fedorahosted.org/fedora-infrastructure/ticket/3695
Thanks for that explicit note of removing https and http, because I have 
been using https://userid.id.fedoraproject.org for ages now and it 
worked for me and stopped working from this morning. However without the 
https portion it also works for me!

Thanks!



___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R  D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

HTTPS for gerrit?

[Vinzenz Feenstra]

Hi,

I would suggest that we would use https for hosting gerrit, currently 
you cannot even access it, it'd be great, I am not sure why it would be 
non-HTTPS. Even though SSL has it's issues, it's still better than plain 
connections.


--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R  D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: Maintenance outage :: www.ovirt.org :: 2012-12-11 01:00 UTC

[Vinzenz Feenstra]

Well it seems like the user uploads are gone.

http://www.ovirt.org/File:Ovirt-guest-agent-sso-linux.png
http://www.ovirt.org/File:Rhevm-3-1.png
http://www.ovirt.org/File:Ovirt-guest-agent-sso-windows.png

On 12/11/2012 02:51 AM, Karsten 'quaid' Wade wrote:

Hot deploy worked. I was able to follow the specific steps below, and
the marker was set without stopping or restarting the app.

Those with OpenShift access - to restart the app, you have to remove the
wiki/.openshift/markers/hot_deploy file and push. The app should then
restart on that push. You would then return it to hot deployable by
replacing and pushing with the marker in place. To be safe, I would push
the changes around hot_deploy marker by themselves, until we determine
if it can be mixed in with other changes that would normally trigger a
restart.

On 12/10/2012 03:27 PM, Karsten (quaid) Wade wrote:

There is going to be a brief planned outage at 5 pm PST (0100 UTC)
today. The outage window is ten minutes. No downtime is expected
during the outage, but it may occur.

== Details ==

I want to setup hot_deploy for our OpenShift instance running MediaWiki.

When I did this the other day, it failed to work properly. Refer to:

http://lists.ovirt.org/pipermail/infra/2012-December/001612.html

This outage is another attempt to set the app to hot deploy. I intend
to do exactly this:

* 'touch wiki/.openshift/markers/hot_deploy'
* 'git add wiki/.openshift/markers/hot_deploy'
* 'git commit wiki/.openshift/markers/hot_deploy'
* 'git push'

If all works correctly, the app will be set to hot deploy without
doing a restart. If it goes like last time, I may attempt to
troubleshoot for a few minutes but no longer than 10 minutes. At that
time I will force restart the app.

== Affected services ==

www.ovirt.org (wiki)

=== Not-affected services ==

lists.ovirt.org
resources.ovirt.org
gerrit.ovirt.org
jenkins.ovirt.org

== Future plans ==

Hopefully this hot deploy trick will allow us to make minor
configuration changes to the website without it having to restart the app.

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra




___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R  D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra

Re: To /wiki or not to /wiki

[Vinzenz Feenstra]

Hi,

What about using .htaccess or URL rewrite for solving this?

regards,

On 11/14/2012 05:18 PM, Karsten 'quaid' Wade wrote:

This is the best place for this discussion ... sort of.[1]

This topic is slightly complex, I'll sort things here in to some
sections to help.

== Background ==

With MediaWiki serving www.ovirt.org, that means we will be redirecting
away from (and no longer using) wiki.ovirt.org.

MW is going to provide the top-level pages, and standard MW
configuration is to have everything appear after /wiki. It is not
impossible to change this, but it has 3 main caveats:

1. Some stuff is going to be a bit harder - we have to resolve
robots.txt and favicon.ico as not wiki articles, for example.[2]

2. We may get occasional bugs that people who use /wiki won't get.

3. mediawiki.org says, this is not supported by the MediaWiki
developers. So if your scheme doesn't work with a new MediaWiki version,
you're on your own.

Relevant sources:

http://www.mediawiki.org/wiki/Manual:Wiki_in_site_root_directory
http://www.mediawiki.org/wiki/Manual:Short_URL/Apache

== Options ==

A. All site URLs are in the form of http://ovirt.org/wiki/Page_name

B. All site URLs are in the form of http://ovirt.org/w/Page_name

C. All site URLs are in the form of http://ovirt.org/Page_name

== My opinion ==

I like option C - I want to see clean URLs that hide implementation details.

My opinion on those concerns about upstream: that's open source. It's
hard to do anything without having problems unique or rare due to your
circumstances, getting bugs that others don't see who follow the
out-of-the-box installation, and to wonder if you won't be able to get
community support for the unusual configuration.

As it happens, we've been running MediaWiki for the last year using the
EPEL RPM -- which is not supported by the MediaWiki developers. When I
went last Fall looking for help with something, #mediawiki told me to
get rid of the RPM and use the ZIP instead, then come back for help.
(The package maintainer (smooge) has been helpful in all cases instead,
so I've been able to avoid having to go to the upstream developers for
help again.)

We have no guarantee that MediaWiki developers will support the
OpenShift quickstart. It also does not use the ZIP out-of-the-box
install, so it likely is unsupported.

My conclusion here is, personally, I have to not care that we're going
to be unsupported, since being supported is actually worse. (I'd rather
run unsupported with a good RPM than supported with an unsigned ZIP.)

Links from anywhere in the site that point to the wiki should point to
a landing page e.g. [[OVirt wiki]] that organizes the pages on the wiki,
exposing popular categories, etc. Thus, the wiki is not identified by
a specific URL, it is identified by the type of content on the page - is
it intended to be community documentation (a wiki) by it's category.

== Footnotes ==

[1] I want to acknowledge as we start that part of Garrett's expertise
that he brings to oVirt is the human-computer interface skillset. That
may not be a skill that many others of us on this list have. Are there
some folks in the rest of oVirt development we can invite to this
discussion? UI or UX folks, for example?

The reason why this matters is we want to separate our geeky-preferences
from the way things tend to work best for a broad range of humans. For
example, I love sub-domains, they work well for my brain - I'm so much
happier with lists.ovirt.org/mailman/... than www.ovirt.org/mailman...
But if Garrett told me that is not the best way to present the
information for a wide audience, I would have to give that opinion high
credence. Heck, I'm prepared to do some pretzel twists to make it
happen, based on that. (I've also always secretly loathed that MediaWiki
has the /wiki requirement.)

[2] I suspect we can special-case them in the .htaccess file.



___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra



--
Regards,

Vinzenz Feenstra | Senior Software Engineer
RedHat Engineering Virtualization R  D
Phone: +420 532 294 625
IRC: vfeenstr or evilissimo

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com

___
Infra mailing list
Infra@ovirt.org
http://lists.ovirt.org/mailman/listinfo/infra