Re: Fedora openid not working?
The same happens for me. - Original Message - > From: "Greg Padgett" > To: "infra" > Sent: Friday, August 7, 2015 4:48:06 PM > Subject: Fedora openid not working? > > Hi Infra team, > > When I try to log in to Gerrit using Fedora OpenID, I'm greeted with: > >Provider is not supported, or was incorrectly entered. > > Can this be fixed, and/or could you link my gdpadg...@gmail.com account to > my Fedora account of https://gpadgett.id.fedoraproject.org/ ? > > Thanks! > Greg > ___ > 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
Re: u/s CI job failure on infra issue
- Original Message - > From: "Adam Litke" > To: "Dan Kenigsberg" > Cc: "Vered Volansky" , "infra" > Sent: Tuesday, June 17, 2014 7:08:42 PM > Subject: Re: u/s CI job failure on infra issue > > On 17/06/14 13:35 +0100, Dan Kenigsberg wrote: > >On Tue, Jun 17, 2014 at 03:02:07AM -0400, Vered Volansky wrote: > >> Hi, > >> > >> http://jenkins.ovirt.org/job/vdsm_master_storage_functional_tests_localfs_gerrit/1298/ > >> failed on an infra issue. > >> There are more patches that fail like this. > >> Is there indeed an infra issue? > >> If so, what is it? > >> If not, what should be done in the job configuration as to not inform on > >> an infra issue? > > > >All I can tell is that _attachStorageDomain failed with > > > > AssertionError: error code: 16, message: Unexpected exception > > > >I wish I could get a grip of the vdsm.log during this test. I am not > >sure that > >http://jenkins.ovirt.org/job/vdsm_master_storage_functional_tests_localfs_gerrit/1298/artifact/vdsm.log > >is the whole thing, but it includes very interesting tracebacks that > >should be better understood. > > > >This is most likely a bug in Vdsm code: > >Thread-11::ERROR::2014-06-16 > > > > 15:22:42,157::storageServer::704::Storage.ConnectionMonitor::(_monitorConnections) > >Monitoring failed > >Traceback (most recent call last): > > File "/usr/share/vdsm/storage/storageServer.py", line 696, in > > _monitorConnections > >self._checkConnections() > > File "/usr/share/vdsm/storage/storageServer.py", line 670, in > > _checkConnections > >for conId, con in self._conDict.iteritems(): > >RuntimeError: dictionary changed size during iteration > > > >And this one looks like a mom bug: > >Thread-113::ERROR::2014-06-16 > >15:22:34,115::BindingXMLRPC::1126::vds::(wrapper) unexpected error > >Traceback (most recent call last): > > File "/usr/share/vdsm/rpc/BindingXMLRPC.py", line 1110, in wrapper > >res = f(*args, **kwargs) > > File "/usr/share/vdsm/rpc/BindingXMLRPC.py", line 455, in getStats > >return api.getStats() > > File "/usr/share/vdsm/API.py", line 1268, in getStats > >stats.update(self._cif.mom.getKsmStats()) > > File "/usr/share/vdsm/momIF.py", line 60, in getKsmStats > >stats = self._mom.getStatistics()['host'] > > File "/usr/lib/python2.7/site-packages/mom/MOMFuncs.py", line 74, in > > getStatistics > >host_stats = > >self.threads['host_monitor'].interrogate().statistics[-1] > >AttributeError: 'NoneType' object has no attribute 'statistics' > > Until this is fixed, the following command can be used to fix your > source so the problem will not appear: > > git show 54d16950 -- vdsm/mom.conf.in | patch -p1 -R I'll try that. Thanks, Vered > > -- > Adam Litke > ___ > 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
Re: u/s CI job failure on infra issue
- Original Message - > From: "Dan Kenigsberg" > To: "Vered Volansky" , ali...@redhat.com > Cc: "infra" > Sent: Tuesday, June 17, 2014 3:35:42 PM > Subject: Re: u/s CI job failure on infra issue > > On Tue, Jun 17, 2014 at 03:02:07AM -0400, Vered Volansky wrote: > > Hi, > > > > http://jenkins.ovirt.org/job/vdsm_master_storage_functional_tests_localfs_gerrit/1298/ > > failed on an infra issue. > > There are more patches that fail like this. > > Is there indeed an infra issue? > > If so, what is it? > > If not, what should be done in the job configuration as to not inform on an > > infra issue? > > All I can tell is that _attachStorageDomain failed with > > AssertionError: error code: 16, message: Unexpected exception > > I wish I could get a grip of the vdsm.log during this test. I am not > sure that > http://jenkins.ovirt.org/job/vdsm_master_storage_functional_tests_localfs_gerrit/1298/artifact/vdsm.log > is the whole thing, but it includes very interesting tracebacks that > should be better understood. > > This is most likely a bug in Vdsm code: Exactly, this is what it looked like to me, but the infra message is misleading and I was wondering how to remove (assuming that there isn't an infra issue on top the vdsm code obvious issue). > Thread-11::ERROR::2014-06-16 > > 15:22:42,157::storageServer::704::Storage.ConnectionMonitor::(_monitorConnections) > Monitoring failed > Traceback (most recent call last): > File "/usr/share/vdsm/storage/storageServer.py", line 696, in > _monitorConnections > self._checkConnections() > File "/usr/share/vdsm/storage/storageServer.py", line 670, in > _checkConnections > for conId, con in self._conDict.iteritems(): > RuntimeError: dictionary changed size during iteration > > And this one looks like a mom bug: > Thread-113::ERROR::2014-06-16 > 15:22:34,115::BindingXMLRPC::1126::vds::(wrapper) unexpected error > Traceback (most recent call last): > File "/usr/share/vdsm/rpc/BindingXMLRPC.py", line 1110, in wrapper > res = f(*args, **kwargs) > File "/usr/share/vdsm/rpc/BindingXMLRPC.py", line 455, in getStats > return api.getStats() > File "/usr/share/vdsm/API.py", line 1268, in getStats > stats.update(self._cif.mom.getKsmStats()) > File "/usr/share/vdsm/momIF.py", line 60, in getKsmStats > stats = self._mom.getStatistics()['host'] > File "/usr/lib/python2.7/site-packages/mom/MOMFuncs.py", line 74, in > getStatistics > host_stats = > self.threads['host_monitor'].interrogate().statistics[-1] > AttributeError: 'NoneType' object has no attribute 'statistics' > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Bad setup code in vdsm_master_storage_functional_tests_localfs_gerrit
- Original Message - > From: "David Caro" > To: "Dan Kenigsberg" > Cc: dc...@redhat.com, "Vered Volansky" , "infra" > > Sent: Tuesday, June 17, 2014 11:33:24 AM > Subject: Re: Bad setup code in > vdsm_master_storage_functional_tests_localfs_gerrit > > On Tue 17 Jun 2014 10:24:49 AM CEST, Dan Kenigsberg wrote: > > On Tue, Jun 17, 2014 at 03:40:51AM -0400, Vered Volansky wrote: > >> > >> > >> - Original Message - > >>> From: "Dan Kenigsberg" > >>> To: "Vered Volansky" > >>> Cc: "infra" > >>> Sent: Monday, June 16, 2014 11:29:42 AM > >>> Subject: Re: Bad setup code in > >>> vdsm_master_storage_functional_tests_localfs_gerrit > >>> > >>> On Sun, Jun 15, 2014 at 04:11:53AM -0400, Vered Volansky wrote: > >>>> The job with this issue is gone, let me know if it's risen again. > >>> > >>> The fragile code is still in > >>> http://jenkins.ovirt.org/view/All/job/vdsm_master_storage_functional_tests_localfs_gerrit/configure > >>> why not make it more robust before /var/log/vdsm disappears and make it > >>> break again? > >> > >> because I don't understand the issue. The file is only created if > >> missing. The directory should be there. > > It was fixed by me some time ago (I added the mkdir -p before the > touch, just in case) > > sudo mkdir -p /var/log/vdsm > sudo chown vdsm:kvm > sudo sh -c 'echo "" > /var/log/vdsm/vdsm.log' > sudo sh -c 'echo "" > /var/log/vdsm/supervdsm.log' I saw that, but this thread was opened after this change. > > > > > However, apparently it was not there, which made the echo fail, which > > led to the job failing. We should understand why it disappeared. > > > > dcaro, eedri - do you have any idea? > > Totally agree, and, if it was meant to be there, I'll remove the mkdir > to make the test fail if it's not there. > But for what I see on the job, there's nothing that ensures you that > the directory will be there, vdsm might never have been installed on > that machine, or might have been properly cleaned at some point > (removing logs and leftovers). > So, In my opinion the issue is that we are not cleaning up properly > after the vdsm jobs and leaving the logs behind. We sure are not. In the past I had vdsm logs when vdsm was not installed, which led to this echo. logrotate was suggested to me, but I saw the job is already configured this way and then told this was actually related to something else and the above is how it should be done. A different suggestion is welcome. The test is not supposed to run in parallel to another, this is how it's configured. > > Also, to which point can these tests run on docker? Anyone have tried? No, When asked how to set it up this is what was suggested. > Because it would make it fit to be run in parallel and on any slave > with any specific deps. > > > -- > David Caro > > Red Hat S.L. > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > Email: dc...@redhat.com > Web: www.redhat.com > RHT Global #: 82-62605 > > > ___ > 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
Re: Bad setup code in vdsm_master_storage_functional_tests_localfs_gerrit
- Original Message - > From: "Dan Kenigsberg" > To: "Vered Volansky" > Cc: "infra" > Sent: Monday, June 16, 2014 11:29:42 AM > Subject: Re: Bad setup code in > vdsm_master_storage_functional_tests_localfs_gerrit > > On Sun, Jun 15, 2014 at 04:11:53AM -0400, Vered Volansky wrote: > > The job with this issue is gone, let me know if it's risen again. > > The fragile code is still in > http://jenkins.ovirt.org/view/All/job/vdsm_master_storage_functional_tests_localfs_gerrit/configure > why not make it more robust before /var/log/vdsm disappears and make it > break again? because I don't understand the issue. The file is only created if missing. The directory should be there. > > BTW, if /var/log/vdsm/vdsm.log is missing, the discussed line would > create it owned by root, which would fail the startup of vdsm. Please > use the vdsm user instead. Ack. > ___ > 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
u/s CI job failure on infra issue
Hi, http://jenkins.ovirt.org/job/vdsm_master_storage_functional_tests_localfs_gerrit/1298/ failed on an infra issue. There are more patches that fail like this. Is there indeed an infra issue? If so, what is it? If not, what should be done in the job configuration as to not inform on an infra issue? Thanks, Vered ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Bad setup code in vdsm_master_storage_functional_tests_localfs_gerrit
The job with this issue is gone, let me know if it's risen again. Vered - Original Message - > From: "Eyal Edri" > To: "Nir Soffer" > Cc: "infra" , "Vered Volansky" , "Dan > Kenigsberg" > Sent: Thursday, June 12, 2014 2:37:33 PM > Subject: Re: Bad setup code in > vdsm_master_storage_functional_tests_localfs_gerrit > > we're not maintaining the functional tests code in jenkins, > i believe it's vered. > > vered - do you need any help with refactoring this? > > eyal. > > - Original Message - > > From: "Nir Soffer" > > To: "infra" , "Vered Volansky" , "Dan > > Kenigsberg" > > Sent: Wednesday, June 11, 2014 9:10:40 PM > > Subject: Bad setup code in > > vdsm_master_storage_functional_tests_localfs_gerrit > > > > Hi infra, > > > > I have seen this failure today: > > > > 16:52:35 Triggered by Gerrit: http://gerrit.ovirt.org/28610 > > 16:52:35 Building remotely on dcaro-ovirt-vm02-fc20 (os1 fedora20) in > > workspace > > /home/jenkins/workspace/vdsm_master_storage_functional_tests_localfs_gerrit > > ... > > 16:53:00 + sudo sh -c 'echo "" > /var/log/vdsm/vdsm.log' > > 16:53:00 sh: /var/log/vdsm/vdsm.log: No such file or directory > > 16:53:02 Build step 'Execute shell' marked build as failure > > > > We need more robust code. Something like: > > > > vdsm_log="/var/log/vdsm/vdsm.log" > > > > if [ -f "$vdsm_log" ]; then > > sudo sh -c 'echo "" > "$vdsm_log" > > fi > > > > Thanks, > > Nir > > ___ > > 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
Re: Storage functional tests CI job
Hi David, - Original Message - > From: "David Caro" > To: "Vered Volansky" , "infra" > Sent: Wednesday, May 28, 2014 2:21:45 PM > Subject: Re: Storage functional tests CI job > > On 05/26/2014 02:58 PM, Vered Volansky wrote: > > Hi David, > > > > After talking with Eyal and Ohad we understand our needs comply with a > > matrix job. > Upstream or downstream? upstream. > > Which project/projects? Should it build engine/vdsm/both. Currently the working job is vdsm_master_storage_functional_tests_localfs_gerrit, but we're working vdsm_master_storage_functional_tests_nfs_gerrit as well, and a new job Yoav requested based on vdsm_master_storage_functional_tests_localfs_gerrit . So instead all of the above and more we were thinking about a matrix job based on vdsm_master_storage_functional_tests_localfs_gerrit. We're only building vdsm. > > Should it use a nightly repo or something? No, just building vdsm. > > Should it be triggered by ovirt-engine patches? vdsm patches? both? Timed? > manually run only? It should run on every patchset, as does vdsm_master_storage_functional_tests_localfs_gerrit. > > If triggered by gerrit, should it send any feedback to the patch? Should it > block the patch if failed? Block, again as already configured in vdsm_master_storage_functional_tests_localfs_gerrit. > > Which setup is required for the tests to start? > (ex. build vdsm, install packages, services up, network interfaces...) build vdsm, some "cells" in the matrix should start services (rpcbind, nfs) we then stop at cleanup, some don't. Some might need network interfaces in the future, I'm not currently working on such a test. > > What needs to be cleaned up after? Right now - only stopping the above services, removing vdsm installation. The current job was configured based on some network job, since we didn't exactly what we should be doing, so I'm hopfull we don't still have garbage there. > > Can it run in parallel with itself? And with other jobs? No. > > Does it require a specific hardware/distribution? fedora 19/20, specifically 20. > > What should be saved from the tests (any specific logs? Just the output?) vdsm and supervdsm logs. already set to be cleaned at beginning and saved. > > > Our inputs (currently passed by env variables to run_tests.sh) are > > generally the cross product of version and storage types: > > version=[0,1,2,3], storage_type=[localfs,nfs,posix,iscsi,fc]. > Do you have an example of one of the combinations run script? > (ex. ./run_tests.sh --storage-type localfs --version 1) currently we're running it based on env vars: sudo NOSE_WITH_XUNIT=1 \ VDSM_TEST_STORAGE_TYPES='localfs' \ VDSM_TEST_STORAGE_VERSIONS='0 3' \ ./run_tests.sh functional/storageTests.py > > > Can you please set a time for us to set this up together? > Sure, but have the answers for the previous questions beforehand, so we can > start working right away, I don't know anything of the above, so I can't help > defining them. All is basically already answered in the already existing job: vdsm_master_storage_functional_tests_nfs_gerrit . We need the matrix job to be based on this condiguration. > > > We'll need Yoav Kleinberger to have permissions for this job as well. > > Dependent on how long it takes to set this up, this job might be enough, > > with no need to the job Yoav asked in the mailing list. > > > > Thanks, > > Vered > > > > > -- > David Caro > > Red Hat S.L. > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > Email: dc...@redhat.com > Web: www.redhat.com > RHT Global #: 82-62605 > > > ___ > 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
Storage functional tests CI job
Hi David, After talking with Eyal and Ohad we understand our needs comply with a matrix job. Our inputs (currently passed by env variables to run_tests.sh) are generally the cross product of version and storage types: version=[0,1,2,3], storage_type=[localfs,nfs,posix,iscsi,fc]. Can you please set a time for us to set this up together? We'll need Yoav Kleinberger to have permissions for this job as well. Dependent on how long it takes to set this up, this job might be enough, with no need to the job Yoav asked in the mailing list. Thanks, Vered ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Storage Functional Tests.
CI job vdsm_master_storage_functional_tests_localfs_gerrit is now on for any storage-related patch-set, as well as dependencies for the storage tests. (storageTests.py) . Please do not ignore test failures. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: How come same version pep8 does't work the same?
- Original Message - > From: "David Caro" > To: "Dan Kenigsberg" > Cc: "Vered Volansky" , "infra" > Sent: Friday, May 23, 2014 12:52:35 PM > Subject: Re: How come same version pep8 does't work the same? > > On Fri 23 May 2014 11:47:52 AM CEST, Dan Kenigsberg wrote: > > On Thu, May 22, 2014 at 05:45:45PM +0200, David Caro wrote: > >> On Thu 22 May 2014 03:50:23 PM CEST, Yaniv Dary wrote: > >>> > >>> > >>> - Original Message - > >>>> From: "Vered Volansky" > >>>> To: "infra" > >>>> Sent: Thursday, May 22, 2014 4:48:37 PM > >>>> Subject: How come same version pep8 does't work the same? > >>>> > >>>> I see a patch failing to build vsdm rpm on a pep8 error. pep8 version is > >>>> 1.4.6, yet the actual pep8 job works jst fine. Same pep8 version to > >>>> both. > >>>> How come? > >>> > >>> Please upgrade your version of pep8. > >>> There were many changes in the latest update and this is probably causing > >>> your issue. > >>> > >>> > >>> Yaniv > >>> > >>>> I need to know why this happens in order to fix my job. > >>>> > >>>> Patch in question: http://gerrit.ovirt.org/#/c/26759/5 > >>>> pep8 job: > >>>> http://jenkins.ovirt.org/job/vdsm_master_pep8_gerrit/9179/console > >>>> Failing job: > >>>> http://jenkins.ovirt.org/job/vdsm_master_storage_functional_tests_localfs_gerrit/852/consoleFull > >>>> > >>>> Thanks, > >>>> Vered > >>>> ___ > >>>> 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 > >> > >> Couple of things to have in mind here: > >> > >> The jobs that you sent are for different patches, I'll focus on the > >> patch you sent only. > >> > >> Why pep8 job did pass: > >> - Because the pep8 job only checks the changes made in that patch, > >> and in that patch, there were no issues (git diff HEAD~) > >> > >> Why vdsm_master_storage_functional_tests_localfs_gerrit did not pass: > >> - Because when compiling it will check all the files, not only the > >> ones your patch changes, and your patch was based on an already failing > >> patchset (http://gerrit.ovirt.org/#/c/27977/5/vdsm/BindingXMLRPC.py,cm). > >> > >> You can see in the gerrit comments for that patchset that it did > >> actually fail: > >> Patch Set 5: Code-Review-1 Verified-1 > >> Build Unstable > >> http://jenkins.ovirt.org/job/vdsm_master_pep8_gerrit/9162/ : UNSTABLE > >> http://jenkins.ovirt.org/job/vdsm_master_unit_tests_gerrit/9305/ : > >> SUCCESS > >> http://jenkins.ovirt.org/job/vdsm_master_unit_tests_gerrit_el/8374/ : > >> SUCCESS > >> > >> > >> Mybe it's a good point to run pep8 on all the files and not only on the > >> latest commit diff, to block any patchset based on a previously failing > >> patch. Ideas? > > > > I prefer to keep the diff. The previously-failing patch should be marked > > and fixed. If follow-ups are fine - let them be. > > Skipping pep8 (with PEP8=true) during the storage job would have avoided > > the issue in a cleaner way. > > Ok, let me know what you decide you want and if there are any changes > needed on my side. I've accepted Dan's proposal, it is indeed cleaner this way. Changed my test accordingly. Thank you both. > > -- > David Caro > > Red Hat S.L. > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > Email: dc...@redhat.com > Web: www.redhat.com > RHT Global #: 82-62605 > > > ___ > 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
How come same version pep8 does't work the same?
I see a patch failing to build vsdm rpm on a pep8 error. pep8 version is 1.4.6, yet the actual pep8 job works jst fine. Same pep8 version to both. How come? I need to know why this happens in order to fix my job. Patch in question: http://gerrit.ovirt.org/#/c/26759/5 pep8 job: http://jenkins.ovirt.org/job/vdsm_master_pep8_gerrit/9179/console Failing job: http://jenkins.ovirt.org/job/vdsm_master_storage_functional_tests_localfs_gerrit/852/consoleFull Thanks, Vered ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
ssh permissions
Hi, I'd like ssh permissions in order to properly debug u/s storage functional tests (currently 2 CI jobs). Thanks, Vered ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: allowing debug ssh access to jenkins slaves for developers
- Original Message - > From: "Michal Skrivanek" > To: "Eyal Edri" > Cc: "David Caro" , "Vered Volansky" , > "Allon Mureinik" , > "Barak Azulay" , "infra" > Sent: Tuesday, March 11, 2014 11:52:39 AM > Subject: Re: allowing debug ssh access to jenkins slaves for developers > > > On 11 Mar 2014, at 11:46, Eyal Edri wrote: > > > > > > > - Original Message - > >> From: "David Caro" > >> To: "Allon Mureinik" > >> Cc: "Eyal Edri" , "Barak Azulay" , > >> "infra" , "Michal > >> Skrivanek" > >> Sent: Tuesday, March 11, 2014 11:44:19 AM > >> Subject: Re: allowing debug ssh access to jenkins slaves for developers > >> > >> On Tue 11 Mar 2014 09:55:08 AM CET, Allon Mureinik wrote: > >>> > >>> > >>> - Original Message - > >>>> On Mon 10 Mar 2014 09:15:12 AM CET, Eyal Edri wrote: > >>>>> Hi, > >>>>> > >>>>> Recently I've been approached by several developers who are working on > >>>>> enabling > >>>>> vdsm functional tests on jenkins.ovirt.org, and they need access to the > >>>>> slaves running those tests, > >>>>> otherwise its almost impossible to debug and fix those tests (errors > >>>>> doesn't reproduce on their test env). > >>>>> > >>>>> What i propose is giving "power user" access to jenkins slaves, similar > >>>>> to > >>>>> what we do on jenkins master, > >>>>> maybe at 1st w/o sudo access, and later on adding specific commands to > >>>>> sudo > >>>>> if it's needed. > >>>>> > >>>>> procedure should be documented in ovirt.org and request should be sent > >>>>> to > >>>>> infra@ovirt.org, > >>>>> explaining the need to access the slaves + public key of the requester. > >>>>> > >>>>> I think it's important to allow this access if we want our infra to > >>>>> scale, > >>>>> having more > >>>>> people that can fix and solve problems on their specific jobs/projects. > >>>>> > >>>>> thoughts/suggestions? > >>>>> > >>>>> Eyal. > >>>>> > >>>>> ___ > >>>>> Infra mailing list > >>>>> Infra@ovirt.org > >>>>> http://lists.ovirt.org/mailman/listinfo/infra > >>>> > >>>> IMO each allowed developer must have it's own user/ssh key to log into > >>>> the slaves. > >>>> > >>>> Also some of the slaves are not reachable from outside (minidells) or > >>>> only reachable from jenkins master or vpn (rackspace). That needs to be > >>>> sorted out also. > >>> Another "parallel" feature would be the ability to pin a job to a slave > >>> (not sure if this is achievable currently), so you could run a job, login > >>> to the slave, fix something, re-run, repeat. > >> > >> Mmm, well, if you can configure the job you can pin it to a slave, just > >> click 'restrict where this job can be run' and write there the name of > >> the slave. Is that what you want? > >> > >> That should only be done on jobs that are in development, as it will > >> greatly affect other runs. > > > > +1 in general for allowing power users ssh access to slaves (no sudo access > > at first). > > but i would like to ask the relevant vdsm funtional tests which info are > > they seeking in the slave, > > and if those logs can be collected and archived via the job (like other > > jobs are doing already). > > > > can the vdsm fuctional test owner can provide more info? > > not sure if we can find out all pieces. Would sudo to less on everything in > /var/log/ really hurt? > maybe something like logcollector…but they tend to be huge +1 Plus download time after each run will become unreasonable. > > > > > eyal > > > >> > >>> > >>>> > >>>> -- > >>>> David Caro > >>>> > >>>> Red Hat S.L. > >>>> Continuous Integration Engineer - EMEA ENG Virtualization R&D > >>>> > >>>> Email: dc...@redhat.com > >>>> Web: www.redhat.com > >>>> RHT Global #: 82-62605 > >>>> > >>>> > >>>> ___ > >>>> Infra mailing list > >>>> Infra@ovirt.org > >>>> http://lists.ovirt.org/mailman/listinfo/infra > >>>> > >> > >> > >> > >> -- > >> David Caro > >> > >> Red Hat S.L. > >> Continuous Integration Engineer - EMEA ENG Virtualization R&D > >> > >> Email: dc...@redhat.com > >> Web: www.redhat.com > >> RHT Global #: 82-62605 > >> > >> > > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: fedora19 needs the new glusterfs repo for certain CI jobs
- Original Message - > From: "Eyal Edri" > To: "Ohad Basan" > Cc: "Vered Volansky" , "infra" , "VDSM > Project Development" > > Sent: Sunday, February 16, 2014 12:43:13 PM > Subject: Re: fedora19 needs the new glusterfs repo for certain CI jobs > > is it relevant only for f19 machines? or any fedora slave? Did not encounter on f20. > > e. > > - Original Message - > > From: "Ohad Basan" > > To: "Dan Kenigsberg" > > Cc: "Eyal Edri" , "VDSM Project Development" > > , "Vered Volansky" > > , "infra" > > Sent: Sunday, February 16, 2014 11:14:56 AM > > Subject: Re: fedora19 needs the new glusterfs repo for certain CI jobs > > > > sent a patch for that > > http://gerrit.ovirt.org/#/c/24510/ > > please review > > > > > > - Original Message - > > > From: "Dan Kenigsberg" > > > To: "Eyal Edri" > > > Cc: "Ohad Basan" , "VDSM Project Development" > > > , "Vered > > > Volansky" , "infra" > > > Sent: Friday, February 14, 2014 12:42:09 AM > > > Subject: Re: fedora19 needs the new glusterfs repo for certain CI jobs > > > > > > On Thu, Feb 13, 2014 at 09:30:21AM -0500, Eyal Edri wrote: > > > > > > > > > > > > - Original Message - > > > > > From: "Ohad Basan" > > > > > To: "Vered Volansky" > > > > > Cc: "infra" > > > > > Sent: Thursday, February 13, 2014 3:04:13 PM > > > > > Subject: Re: fedora19 needs the new glusterfs repo for certain CI > > > > > jobs > > > > > > > > > > I think that what has to be done here is that we need to add to > > > > > puppet > > > > > the > > > > > gluster upstream repository. > > > > > opinions anyone? > > > > > > > > you're talking about the glusterfs epel repos? > > > > fine by me, but adding vdsm devel to confirm. > > > > > > > > > Yes, please pull in > > > http://download.gluster.org/pub/gluster/glusterfs/3.4/LATEST/Fedora/fedora-19/aarch64/ > > > > > > ___ > 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
Re: CI notification and link via u/s gerrit is non-existent
- Original Message - > From: "Eyal Edri" > To: "Vered Volansky" > Cc: "infra" > Sent: Thursday, February 13, 2014 4:34:49 PM > Subject: Re: CI notification and link via u/s gerrit is non-existent > > > > - Original Message - > > From: "Vered Volansky" > > To: "infra" > > Sent: Thursday, February 13, 2014 2:44:37 PM > > Subject: CI notification and link via u/s gerrit is non-existent > > > > Hi, > > > > I have two jenkins CI jobs that are triggered from this patch (every > > patchset): > > http://gerrit.ovirt.org/#/c/23343/. > > > > The jobs are: > > http://jenkins.ovirt.org/job/vdsm_storage_functional_tests_localfs > > http://jenkins.ovirt.org/job/vdsm_storage_functional_tests_nfs > > please rename the jobs to have _gerrit suffix. Didn't help. jobs are still trigerred and not linked to by gerrit. > > > > > I've just noticed that they are both triggered, but this doesn't appear in > > the patchset (#33). > > They are indeed triggered though: > > http://jenkins.ovirt.org/job/vdsm_storage_functional_tests_localfs/170/ > > http://jenkins.ovirt.org/job/vdsm_storage_functional_tests_nfs/109 > > also, they are triggered for every branch (**), and not just master/3.4/3.3 - > is that on purpose? > the current behavior is that gerrit doesn't show it's starting the tests, but > only when it's done. > i think it was requested in the past to avoid spamming the users, it can be > enabled back. > > > > > > Thanks > > ___ > > 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
fedora19 needs the new glusterfs repo for certain CI jobs
Hi, When http://jenkins.ovirt.org/job/vdsm_storage_functional_tests_localfs runs on a fedora19 machine, it seems as though the glusterfs repository is stale. Can it please be updated? Please note the following error in http://jenkins.ovirt.org/job/vdsm_storage_functional_tests_localfs/170/consoleFull . Error: Package: glusterfs-cli-3.4.0-8.fc19.x86_64 (@updates) Requires: glusterfs-libs = 3.4.0-8.fc19 and so on... Thanks, Vered ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
CI notification and link via u/s gerrit is non-existent
Hi, I have two jenkins CI jobs that are triggered from this patch (every patchset): http://gerrit.ovirt.org/#/c/23343/. The jobs are: http://jenkins.ovirt.org/job/vdsm_storage_functional_tests_localfs http://jenkins.ovirt.org/job/vdsm_storage_functional_tests_nfs I've just noticed that they are both triggered, but this doesn't appear in the patchset (#33). They are indeed triggered though: http://jenkins.ovirt.org/job/vdsm_storage_functional_tests_localfs/170/ http://jenkins.ovirt.org/job/vdsm_storage_functional_tests_nfs/109 Thanks ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: NFS functional test failure on jenkins
Hi Francesco, Note that this is a different job this time. I'll have a look later on. FYI test code/CI job configuration was not changed. Will update when I have news, Vered - Original Message - > From: "Francesco Romani" > To: "Vered Volansky" > Cc: infra@ovirt.org > Sent: Monday, January 27, 2014 3:06:27 PM > Subject: Re: NFS functional test failure on jenkins > > > > ----- Original Message - > > From: "Vered Volansky" > > To: "Francesco Romani" > > Cc: infra@ovirt.org > > Sent: Monday, January 27, 2014 1:53:03 PM > > Subject: Re: NFS functional test failure on jenkins > > > > Hi, > > > > This test is currently disabled, I might need to enable it again for > > further > > testing though. > > Hi, > > No problem for me reenabling hat test any time; to be honest I still fail to > see why it is broken. > > Retriggred the jenkins verification manually and got this: > > http://jenkins.ovirt.org/job/vdsm_storage_functional_tests_localfs/64/console > > snippet of error: > Error: Package: glusterfs-cli-3.4.0-8.fc19.x86_64 (@updates) >Requires: glusterfs-libs = 3.4.0-8.fc19 >Removing: glusterfs-3.4.0-8.fc19.x86_64 (@updates) >glusterfs-libs = 3.4.0-8.fc19 >Updated By: glusterfs-3.4.2-1.fc19.x86_64 (updates) >glusterfs-libs = 3.4.2-1.fc19 >Removing: glusterfs-3.4.1-1.fc19.x86_64 (installed) >glusterfs-libs = 3.4.1-1.fc19 >Updated By: glusterfs-3.4.2-1.fc19.x86_64 (updates) >glusterfs-libs = 3.4.2-1.fc19 >Installed: glusterfs-libs-3.4.1-1.fc19.x86_64 (@updates) >glusterfs-libs = 3.4.1-1.fc19 >Available: glusterfs-3.4.0-0.5.beta2.fc19.i686 (fedora) >glusterfs-libs = 3.4.0-0.5.beta2.fc19 >Available: glusterfs-libs-3.4.2-1.fc19.i686 (updates) >glusterfs-libs = 3.4.2-1.fc19 > > yum/repo glitch? > > Thanks, > > -- > Francesco Romani > RedHat Engineering Virtualization R & D > Phone: 8261328 > IRC: fromani > ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: NFS functional test failure on jenkins
Hi, This test is currently disabled, I might need to enable it again for further testing though. Vered - Original Message - > From: "Francesco Romani" > To: infra@ovirt.org > Sent: Monday, January 27, 2014 1:30:25 PM > Subject: NFS functional test failure on jenkins > > > Hi, > > I got this failure: > http://jenkins.ovirt.org/job/vdsm_storage_functional_tests_nfs/3/console > on a small submission unrelated to storage > (http://gerrit.ovirt.org/#/c/23663/) > > Can someone take a look? > > Thanks, > > -- > Francesco Romani > RedHat Engineering Virtualization R & D > Phone: 8261328 > IRC: fromani > ___ > 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
Re: git fetch stuck/slow
Yes I am.. Also read the thread Omer started, so I'll just wait... Thanks! - Original Message - > From: "David Caro Estevez" > To: "Vered Volansky" > Cc: "infra" > Sent: Wednesday, January 22, 2014 3:19:20 PM > Subject: Re: git fetch stuck/slow > > Are you in TLV redhat office? If so, can you check with local ops if you have > enough bandwidth? > > Thanks! > > - Original Message - > > From: "Vered Volansky" > > To: "infra" > > Sent: Tuesday, January 21, 2014 3:33:28 PM > > Subject: git fetch stuck/slow > > > > Hi, > > > > I tried to git fetch about an hour ago and it just got stuck. > > Then again a few minutes ago, and it was stuck for a while and then > > finished > > slowly. > > > > Can somebody take care of this? > > > > Thanks, > > Vered > > ___ > > 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
Re: Jenkins job vdsm_storage_functional_tests failing
Hi Adam,
I've installed libnl on all hosts as requested.
I've looked at the failed CI jobs and I see the issue you're referring to.
It doesn't look like anything in the new test itself.
I've re-triggered the test (after libnl installation), but it's stuck due to
office bad internet connection, so not so much I can do for now.
I'll get back to it when I have the resources.
Tomorrow's oVirt test day, I'll try to get to it on the next working day, which
is Sunday.
Feel free to ping/mail me if you need any urgent assistance.
Regards,
Vered
- Original Message -
> From: "Allon Mureinik"
> To: "Adam Litke"
> Cc: "Dan Kenigsberg" , "Vered Volansky"
> , "Ohad Basan" ,
> "infra"
> Sent: Tuesday, January 21, 2014 10:46:28 PM
> Subject: Re: Jenkins job vdsm_storage_functional_tests failing
>
> Hi Adam,
>
> Enabling VDSM's functional tests was a 3.4 requirement raised by Dan (among
> others)[1].
> Vered from the storage team and Ohad from the infra team (both CCed) are
> working on it.
>
> As far as I know (which is updated to about half a day ago) - the test you
> linked to runs only on a local storage backend, and /should/ work properly
> (i.e., I saw it work a couple of patches ago - not quite sure what changed
> since).
> However, Vered and Ohad are working on a replacing this job with a job that
> will run X permutations on storage backends in a single job. I'm not sure,
> though, if the errors we see are caused by the effort to modify this job or
> whether the work is done on a different job.
> Vered/Ohad - can you share some insight?
>
>
> Thanks,
> Allon
>
> [1]
> https://docs.google.com/spreadsheet/ccc?key=0AuAtmJW_VMCRdHJ6N1M3d1F1UTJTS1dSMnZwMF9XWVE&usp=drive_web
> - see line 57, not sure how to directly link to it.
>
> - Original Message -
> > From: "Adam Litke"
> > To: infra@ovirt.org
> > Sent: Tuesday, January 21, 2014 9:37:47 PM
> > Subject: Jenkins job vdsm_storage_functional_tests failing
> >
> > Hi all,
> >
> > The jenkins job for 'vdsm_storage_functional_tests' is failing due to the
> > following error:
> >
> > ==
> > ERROR:
> > --
> > Traceback (most recent call last):
> > File "/usr/lib/python2.7/site-packages/nose/suite.py", line 208, in run
> > self.setUp()
> > File "/usr/lib/python2.7/site-packages/nose/suite.py", line 291, in setUp
> > self.setupContext(ancestor)
> > File "/usr/lib/python2.7/site-packages/nose/suite.py", line 314, in
> > setupContext
> > try_run(context, names)
> > File "/usr/lib/python2.7/site-packages/nose/util.py", line 469, in
> > try_run
> > return func()
> > File
> >
> > "/home/jenkins/workspace/vdsm_storage_functional_tests/rpmbuild/BUILD/vdsm-4.14.1/tests/apiTests.py",
> > line 125, in setUpModule
> > createFakeAPI()
> > File
> >
> > "/home/jenkins/workspace/vdsm_storage_functional_tests/rpmbuild/BUILD/vdsm-4.14.1/tests/apiTests.py",
> > line 84, in createFakeAPI
> > _API = __import__('API', globals(), locals(), {}, -1)
> > File
> >
> > "/home/jenkins/workspace/vdsm_storage_functional_tests/rpmbuild/BUILD/vdsm-4.14.1/vdsm/API.py",
> > line 34, in
> > from clientIF import clientIF
> > File
> >
> > "/home/jenkins/workspace/vdsm_storage_functional_tests/rpmbuild/BUILD/vdsm-4.14.1/vdsm/clientIF.py",
> > line 28, in
> > import alignmentScan
> > File
> >
> > "/home/jenkins/workspace/vdsm_storage_functional_tests/rpmbuild/BUILD/vdsm-4.14.1/vdsm/alignmentScan.py",
> > line 24, in
> > from storage.misc import execCmd
> > File
> >
> > "/home/jenkins/workspace/vdsm_storage_functional_tests/rpmbuild/BUILD/vdsm-4.14.1/vdsm/storage/misc.py",
> > line 57, in
> > from caps import isOvirtNode
> > File
> >
> > "/home/jenkins/workspace/vdsm_storage_functional_tests/rpmbuild/BUILD/vdsm-4.14.1/vdsm/caps.py",
> > line 38, in
> > from vdsm import netinfo
> > File
> >
> > "/home/jenkins/workspace/vdsm_storage_functional_tests/rpmbuild/BUILD/vdsm-4.14.1/lib/vdsm/netinfo.py",
> > line 36, in
> > from .ipwrapper import getLink, getLinks
> > File
> &g
git fetch stuck/slow
Hi, I tried to git fetch about an hour ago and it just got stuck. Then again a few minutes ago, and it was stuck for a while and then finished slowly. Can somebody take care of this? Thanks, Vered ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
gerrit-jenkins connection
Hi, There seems to be a problem with the connection between jenkins and gerrit, for instance: http://jenkins.ovirt.org/job/vdsm_storage_functional_tests/32/console snippet: Fetching changes from 1 remote Git repository ERROR: Problem fetching from origin / origin - could be unavailable. Continuing anyway hudson.plugins.git.GitException: Failed to connect to http://gerrit.ovirt.org/vdsm at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getURLWithCrendentials(CliGitAPIImpl.java:1391) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.getURLWithCrendentials(CliGitAPIImpl.java:1338) at org.jenkinsci.plugins.gitclient.CliGitAPIImpl.setRemoteUrl(CliGitAPIImpl.java:611) at hudson.plugins.git.GitAPI.setRemoteUrl(GitAPI.java:119) at hudson.plugins.git.GitSCM.fetchFrom(GitSCM.java:790) at hudson.plugins.git.GitSCM.access$000(GitSCM.java:58) at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:983) at hudson.plugins.git.GitSCM$2.invoke(GitSCM.java:948) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2394) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:326) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) ERROR: Could not fetch from any repository hudson.util.IOException2: remote file operation failed: /home/jenkins/workspace/vdsm_storage_functional_tests/vdsm at hudson.remoting.Channel@50e084b7:fedora20-vm01 at hudson.FilePath.act(FilePath.java:906) at hudson.FilePath.act(FilePath.java:883) at hudson.plugins.git.GitSCM.determineRevisionToBuild(GitSCM.java:948) at hudson.plugins.git.GitSCM.checkout(GitSCM.java:1114) at org.jenkinsci.plugins.multiplescms.MultiSCM.checkout(MultiSCM.java:117) at hudson.model.AbstractProject.checkout(AbstractProject.java:1376) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:655) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:560) at hudson.model.Run.execute(Run.java:1592) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:237) If that's the case, can it be fixed? Thanks, Vered ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: ovirt jenkins account
Thanks everyone! - Original Message - > From: "David Caro" > To: "Dan Kenigsberg" > Cc: "Vered Volansky" , "infra" > Sent: Wednesday, January 8, 2014 2:25:41 PM > Subject: Re: ovirt jenkins account > > El mié 08 ene 2014 10:47:49 CET, Dan Kenigsberg escribió: > > On Wed, Jan 08, 2014 at 04:26:25AM -0500, Vered Volansky wrote: > >> Hi all, > >> > >> I'm adding storage functional tests as a CI job. > >> I need an account in jenkins.ovirt.org with permissions to create, > >> configure, enable, disable the test. > >> > >> Please ack... > > > > Yes please, it's a noble cause! > > ___ > > Infra mailing list > > Infra@ovirt.org > > http://lists.ovirt.org/mailman/listinfo/infra > > Done :) > > -- > David Caro > > Red Hat S.L. > Continuous Integration Engineer - EMEA ENG Virtualization R&D > > Email: dc...@redhat.com > Web: www.redhat.com > RHT Global #: 82-62605 > > > ___ > 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
ovirt jenkins account
Hi all, I'm adding storage functional tests as a CI job. I need an account in jenkins.ovirt.org with permissions to create, configure, enable, disable the test. Please ack... Thanks, Vered ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
ovirt wiki password
Hi, I have to write a new ovirt wiki, yet it doesn't recognize my password (my username is valid), I've tried to reset the password and was told an email was sent to my account. This was hours ago, and no such email. It's NOT being filtered. I also tried to reset it again, and got a message saying I can do that only once every 24 hours, so my previous request was undoubtedly logged. Somebody please help with this issue. Thanks, Vered ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Fedora Open ID issue
- Original Message - > From: "Yaniv Dary" > To: "Vinzenz Feenstra" > Cc: infra@ovirt.org > Sent: Wednesday, March 6, 2013 12:07:46 PM > Subject: Re: Fedora Open ID issue > > > > > > > > > From: "Vinzenz Feenstra" > To: infra@ovirt.org > Sent: Wednesday, March 6, 2013 11:35:43 AM > Subject: Re: Fedora Open ID issue > > > 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 .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:// .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! > > This solution created a new user and I lost all the permissions I had > and patches connection an so on. > > > > Yaniv I didn't use https/http to begin with. I suppose this works for those who used https://.id.fedoraproject.org before, while I was using https://admin.fedoraproject.org/accounts/openid/id/ . > > > > > > > ___ > 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 > > > ___ > 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
Fedora Open ID issue
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. Regards, Vered ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Wiki update help needed
I can see it there, thanks! - Original Message - > From: "Mike Burns" > To: "Vered Volansky" > Cc: "infra" > Sent: Thursday, December 13, 2012 1:21:11 PM > Subject: Re: Wiki update help needed > > On Thu, 2012-12-13 at 02:22 -0500, Vered Volansky wrote: > > Hi, > > > > I'm updating the node wiki ( http://www.ovirt.org/Category:Node ) > > with the actual current release, which is oVirt Node 2.5.5-0.1. > > There was a link there to the package's tar: > > http://ovirt.org/releases/stable/src/ovirt-node-2.5.1.tar.gz, only > > I need the equivalent of it for 2.5.5, which is not under the same > > folder. > > > > Can someone put the tar there, or give me a good link? > > > > Uploaded the 2.5.5 tarball. > > Mike > > > Thanks, > > Vered > > ___ > > 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
Wiki update help needed
Hi, I'm updating the node wiki ( http://www.ovirt.org/Category:Node ) with the actual current release, which is oVirt Node 2.5.5-0.1. There was a link there to the package's tar: http://ovirt.org/releases/stable/src/ovirt-node-2.5.1.tar.gz, only I need the equivalent of it for 2.5.5, which is not under the same folder. Can someone put the tar there, or give me a good link? Thanks, Vered ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
Re: Wiki issue: Installing VDSM from rpm
No problem, thanks for the update. Vered - Original Message - > From: "Mike Burns" > To: "Vered Volansky" > Cc: infra@ovirt.org > Sent: Wednesday, October 10, 2012 3:45:44 PM > Subject: Re: Wiki issue: Installing VDSM from rpm > > On Wed, 2012-10-10 at 09:29 -0400, Vered Volansky wrote: > > The above wiki( http://wiki.ovirt.org/wiki/Installing_VDSM_from_rpm > > ) has the following instruction: > > wget > > http://www.ovirt.org/releases/nightly/fedora/16/ovirt-engine.repo > > -P /etc/yum.repos.d/ > > > > 1. Need to change to the actual fedora 17 url. > > 2. The updated url hasn't got ovirt-engine.repo in it. > > You can get vdsm directly from Fedora, yes. You can also get it from > the ovirt.org repos. The .repo file no longer exists, but there is > an > ovirt-release rpm available. I've updated the wiki to reflect that. > > Thanks for pointing this out. > > Mike > > > ___ > > 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
Wiki issue: Installing VDSM from rpm
The above wiki( http://wiki.ovirt.org/wiki/Installing_VDSM_from_rpm ) has the following instruction: wget http://www.ovirt.org/releases/nightly/fedora/16/ovirt-engine.repo -P /etc/yum.repos.d/ 1. Need to change to the actual fedora 17 url. 2. The updated url hasn't got ovirt-engine.repo in it. ___ Infra mailing list Infra@ovirt.org http://lists.ovirt.org/mailman/listinfo/infra
