Don't we run it per patch as well?
How did it got merged?
On Apr 14, 2016 9:42 AM, "Sandro Bonazzola" wrote:
>
> http://jenkins.ovirt.org/job/vdsm_master_build-artifacts-fc23-x86_64/823/console
>
> *00:05:46.751*
> ==*00:05:46.7
http://jenkins.ovirt.org/job/vdsm_master_build-artifacts-fc23-x86_64/823/console
*00:05:46.751*
==*00:05:46.751*
ERROR: Failure: ImportError (No module named 'netaddr')*00:05:46.751*
--
> I'm curios, where did you use AspectJ? For how many and what kind of
> crosscutting concerns did you use it?
Personal project (Spring based, the AOP there is extremely simple to
write) and mostly for metrics and instrumentation (like adding Hystrix
wrapper around all service calls). So I never
Hi,
Thanks for the feedback!
I commented below.
- Original Message -
> Hi all,
>
> I agree that it was an interesting article.
>
> > However, since AspectJ is an extension to Java, most of oVirt
> > developers would need to know additional programming language
> > which puts the cost-ef
Hi everybody,
there is one piece I always missed when developing my optimizer plugin
and that is the access to the engine css styles.
I feel it might be pretty easy and good for both bandwidth and
branding to expose them using some "well known" url from the engine.
All plugins would be then able
Hi all,
I agree that it was an interesting article.
> However, since AspectJ is an extension to Java, most of oVirt
> developers would need to know additional programming language
> which puts the cost-effectiveness of this approach into question.
Actually you only need to learn some very basic
Hi all,
In [1] you can find some patches which are meant to improve the test
writing experience in ovirt-engine.
They provide the following things:
A) Domain Object builders which can be used for creating and/or
persisting domain objects [2]
B) DAO testing without writing fixtures because of
On 04/13 15:01, Yaniv Kaul wrote:
> On Wed, Apr 13, 2016 at 2:02 PM, David Caro wrote:
>
> > Though you will not have any caching and zram execution (just as the
> > jenkins
> > slaves don't have it).
> >
>
> That should change. The sooner the better.
So as I said, there's an usync between what
On Wed, Apr 13, 2016 at 2:02 PM, David Caro wrote:
> Though you will not have any caching and zram execution (just as the
> jenkins
> slaves don't have it).
>
That should change. The sooner the better.
If they have enough ram, they can actually run in /dev/shm/something.
That's what I'm doing w
On 04/13 13:35, Yaniv Kaul wrote:
> On Wed, Apr 13, 2016 at 1:05 PM, David Caro wrote:
>
> > On 04/10 20:52, Yaniv Kaul wrote:
> > > On Sun, Apr 10, 2016 at 6:06 PM, Eyal Edri wrote:
> > >
> > > > test_logs/
> > >
> > >
> > > This is an annoying change of behavior. In the past, I believe the log
I missed the part of reducing to 10 artifacts.
I think we should keep it at 20, I agree lower than that will be harder to
see errors.
We'll keep monitoring it closely until the migration (planned for the
24-25/04).
On Wed, Apr 13, 2016 at 1:56 PM, Sandro Bonazzola
wrote:
>
>
> On Wed, Apr 13, 2
On Wed, Apr 13, 2016 at 12:42 PM, Eyal Edri wrote:
> +1 from me.
>
> We are in the process of migration to the new jenkins [2], Actually some
> of the jobs already migrated (node/lago),
> So we will be able to increase history back to higher levels once we
> finish the migration.
>
> I think on s
+1 from me.
We are in the process of migration to the new jenkins [2], Actually some of
the jobs already migrated (node/lago),
So we will be able to increase history back to higher levels once we finish
the migration.
I think on some projects we reduced it to 20 already, which projects still
use
Hi all,
Due to very slow performance we are restarting the gerrit service.
It'll be back up in one minute
Sorry for the inconvenient
Gil
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Hi,
Jenkins is back online. Some jobs were still in the queue. Please make sure
that your patches have passes check patch or check merge and if not,
re-trigger them.
Thanks
Gil
On Tue, Apr 12, 2016 at 11:36 AM, Gil Shinar wrote:
> Hi,
>
> We need to install two security patches and for that we
Hi,
We need to install two security patches and for that we need to restart the
Jenkins.
In order to do that we will need you to stop sending patches for two hours
so the Jenkins queue will clear itself.
I'm scheduling the restart for today at 18:00 IST. Patches that'll be sent
after 16:00 IST mig
Hi,
Upstream Jenkins disk always get filled up and I want to reduce the amount
of builds to keep from 40 to 30 or even 20 and the amount of archived
artifacts to keep from 20 to 15 or even 10.
Is that OK by you?
Thanks
Gil
___
Devel mailing list
Devel@
On Wed, Apr 13, 2016 at 11:49 AM, Nir Soffer wrote:
> On Wed, Apr 13, 2016 at 11:27 AM, Sandro Bonazzola
> wrote:
> >
> >
> > On Tue, Apr 12, 2016 at 8:37 PM, Yaniv Kaul wrote:
> >>
> >> Probably fails because of:
> >> git describe
> >> fatal: No names found, cannot describe anything.
> >
> >
>
Hi Juan,
Sent you an email in the morning. Can you please check?
Thanks
Gil
On Mon, Apr 11, 2016 at 3:49 PM, Juan Hernández wrote:
> On 04/11/2016 02:07 PM, Gil Shinar wrote:
> > Hi,
> >
> > Now it should be OK till Juan will permanently fix that.
> >
> > Gil
> >
>
> What do I need to fix?
>
>
On Wed, Apr 13, 2016 at 1:05 PM, David Caro wrote:
> On 04/10 20:52, Yaniv Kaul wrote:
> > On Sun, Apr 10, 2016 at 6:06 PM, Eyal Edri wrote:
> >
> > > test_logs/
> >
> >
> > This is an annoying change of behavior. In the past, I believe the logs
> > were under the deployment dir. Now, they are h
On 04/10 20:52, Yaniv Kaul wrote:
> On Sun, Apr 10, 2016 at 6:06 PM, Eyal Edri wrote:
>
> > test_logs/
>
>
> This is an annoying change of behavior. In the past, I believe the logs
> were under the deployment dir. Now, they are here. It requires cleaning
> them manually every time.
Before it a
On Wed, Apr 13, 2016 at 11:27 AM, Sandro Bonazzola wrote:
>
>
> On Tue, Apr 12, 2016 at 8:37 PM, Yaniv Kaul wrote:
>>
>> Probably fails because of:
>> git describe
>> fatal: No names found, cannot describe anything.
>
>
> Yes. I think autogen.sh and configure.ac shouldn't rely on git for package
On 04/13 11:19, Eyal Edri wrote:
> We should also have more el7 hypervisors now so if needed we can use them
> instead.
Nop, the issue is that you are totally unable to run fc* chroots on top of el*
hypervisors, so we fell back to using fc* hypervisors only, that means that any
chroot (fc* or el*)
On Wed, Apr 13, 2016 at 10:19 AM, Eyal Edri wrote:
> We should also have more el7 hypervisors now so if needed we can use them
> instead.
>
> We can reinstall the fc23 as el7 if we don't need specifically fedora hosts
>
I'm not aware of jobs requiring fc23 slaves.
> On Apr 13, 2016 11:09 AM,
On Tue, Apr 12, 2016 at 8:37 PM, Yaniv Kaul wrote:
> Probably fails because of:
> git describe
> fatal: No names found, cannot describe anything.
>
Yes. I think autogen.sh and configure.ac shouldn't rely on git for package
versioning.
The automation/build-artifacs.sh script can take care of addi
We should also have more el7 hypervisors now so if needed we can use them
instead.
We can reinstall the fc23 as el7 if we don't need specifically fedora hosts
On Apr 13, 2016 11:09 AM, "David Caro" wrote:
> On 04/12 18:16, Sandro Bonazzola wrote:
> > Hi,
> > Project vdsm_master_check-merged-el7
On 04/12 18:16, Sandro Bonazzola wrote:
> Hi,
> Project vdsm_master_check-merged-el7-x86_64 failing consistently at least
> since April 7.
>
> *00:15:04.646* * Starting VM vdsm_functional_tests_host-fc23:
> *00:15:04.649* libvirt: QEMU Driver error : Cannot check QEMU binary
> /usr/libexec/qe
27 matches
Mail list logo
