Re: [ovirt-devel] oVirt engine 4.0 will require WildFly 10 / EAP 7
Hi, patches were merged, oVirt master now requires WildFly 10! Please upgrade your development environment as described below. Also please be aware, that if you are using aaa-jdbc extension in you development environment prefix, you need to rebase to latest aaa-jdbc master, build and install it into your existing prefix and run engine-setup. Please let me know if you have any issues with this upgrade. Thanks Martin Perina - Original Message - > From: "Martin Perina" > To: "devel" > Sent: Thursday, January 14, 2016 1:09:50 PM > Subject: [ovirt-devel] oVirt engine 4.0 will require WildFly 10 / EAP 7 > > Hi, > > we are going to merge patches which drop EAP 6 support [1] and require > WildFly 10 / EAP 7 [2] for oVirt engine master on Monday January 18th > at 10:00 CET. > > This is a huge step as we will finally be able to use all new features > provided by WildFly 10 (J2EE 7, Java 8, RESTEasy 3, ActiveMQ Artemis, > Hibernate 5, ...). > Upgrade of code base to use those new features will be done incrementally, > for example this patch [3] cleans up our CDI related code and upgrades > to CDI 1.2. > > So on Monday please upgrade WildFly packages on your development machines > to: > > ovirt-engine-wildfly-10.0.0 > ovirt-engine-wildfly-overlay-10.0.0 > > and rebase your patches on top of latest master. > > To ease backporting of patches to oVirt 3.6 we have already merged patches > which made oVirt 3.6 compatible with WildFly 10, but please bear in mind > that oVirt 3.6 have to be compatible with EAP 6 and there are no plans > to upgrade it to WildFly 10! > > > Please contact me or other members of infra team if you have any issues > with this upgrade. > > Thanks > > > Martin Perina > > > [1] https://gerrit.ovirt.org/48208 > [2] https://gerrit.ovirt.org/48209 > [3] https://gerrit.ovirt.org/48305 > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Ensure processes death by terminating decorator - https://gerrit.ovirt.org/51407
Hi guys, Following the work to omit deathSignal attribute from our cpopen implementation we posted https://gerrit.ovirt.org/51407 which is ready for use. Currently locations that should use it are: (I wrote above who I expect to check the area and post a patch for that - we'll discuss it during next vdsm-sync to follow the work) shavivi: vdsm/v2v.py - in _start_virt_v2v you return aysnProc that should call kill() on fail fromani: vdsm_hooks/checkimages/before_vm_start.py - in checkImage - the code looks ok, but check if not better to use the terminating decorator.. I think it will be nicer nsoffer: vdsm/storage/mount.py - good looks ok, I prefer to use terminator there vdsm/storage/iscsiadm.py vdsm/storage/imageSharing.py vdsm/storage/hba.py -good handling, use terminator vdsm/storage/blockSD.py please check your usage with the returned process and see that you're not depending on deathSignal for it to die properly on crush some places define deathSignal for no reason, the call is sync - please remove those places: nsoffer: lib/vdsm/qemuimg.py vdsm/storage/curlImgWrap.py vdsm/storage/storage_mailbox.py vdsm/storage/misc.py fromani: lib/vdsm/virtsparsify.py ybronhei: vdsm/API.py If you can't get to it in a reasonable time, add the task to the list [1] and someone else will be it up. Please try to go over before the sync call. [1] - https://docs.google.com/spreadsheets/d/180F-C1jU54ajUn7TuR-NwrKRZY1IiZI1Z8U5HWbvEvM/edit#gid=0 -- *Yaniv Bronhaim.* ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Topic for next Vdsm call - 19.1
Things I plan to raise. feel free to add more 1. Plans to handle async processes without using death signal. 2. Vdsm messaging - I'll ask Piotr to elaborate about infra plans for that topic (what about the external broker plans? any standard plan to communicate with vdsm? such as for supervdsm and mom). 3. Contract for events and new apis - where it stands. 4. py.test - If someone can pick up the migration to py test -- *Yaniv Bronhaim.* ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] [ANN] Team in Whiteboard is not more, long live oVirt Team custom field.
Hi All, For a long time now we have been using the whiteboard free-text field to set the team that owns each ticket in Bugzilla. This causes several issues: - The usage was not documented. - We had issue reporting on that field. - People can make mistakes setting it (mis-spelling the team for example). Today Bugzilla team has completed setting oVirt Team field for all open bugs (NEW-> VERIFIED). From today we will be moving to using it. The documentation for this field is updated in Bugzilla, so if you are not sure on what team to set the ticket, click on the field itself and you will have a detailed help page. Please update all queries to use it! It should be easy to do so by changing the field you search on from 'Whiteboard' to 'oVirt Team'. Next Tuesday (26/01/16) I will request removal of all whiteboard team values. Please make sure to fix you queries beforehand. Thanks! Yaniv Dary Technical Product Manager Red Hat Israel Ltd. 34 Jerusalem Road Building A, 4th floor Ra'anana, Israel 4350109 Tel : +972 (9) 7692306 8272306 Email: yd...@redhat.com IRC : ydary ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Ensure processes death by terminating decorator - https://gerrit.ovirt.org/51407
- Original Message - > From: "Yaniv Bronheim" > To: "devel" , "Shahar Havivi" , > "Francesco Romani" , "Nir > Soffer" > Sent: Monday, January 18, 2016 11:01:10 AM > Subject: Ensure processes death by terminating decorator - > https://gerrit.ovirt.org/51407 > > Hi guys, > > Following the work to omit deathSignal attribute from our cpopen > implementation we posted https://gerrit.ovirt.org/51407 which is ready for > use. > Currently locations that should use it are: > (I wrote above who I expect to check the area and post a patch for that - > we'll discuss it during next vdsm-sync to follow the work) > fromani: > vdsm_hooks/checkimages/before_vm_start.py - in checkImage - the code looks > ok, but check if not better to use the terminating decorator.. I think it > will be nicer Fair enough, posted https://gerrit.ovirt.org/52349 > some places define deathSignal for no reason, the call is sync - please > remove those places: [...] > fromani: > lib/vdsm/virtsparsify.py Done in https://gerrit.ovirt.org/52357 -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] oVirt 3.6.2 RC3 build planned
Fyi oVirt developers, An oVirt build is planned for this Tuesday 11:00 AM TLV time (10:00 AM CET), please make sure to backport any open patches to the stable branch for review by the stable branch maintainers, final date for this will be Monday 11:00 AM. - https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A3.6.2%20flag%3Ablocker%20status%3Anew%2Cassigned%2Cpost -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] oVirt 3.6.2 RC3 merge / tag / bugzilla reminder
All stable branch maintainers, please make sure to - merge all relevant open bugs until tuesday morning 11:00 AM TLV time. - https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A3.6.2%20target_release%3A---%20status%3Amodified%2Cpost Every package build (i.e oVirt product) - please make sure every bug in MODIFIED has the right Target Release and Target Milestone. A Target release should state the version of the package you're building and should include the same version you used for the tag you just used for this build. (e.g. for ovirt-engine, tag: ovirt-engine-3.6.2.6, tr: 3.6.2.6) -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] oVirt 3.6.2 RC3 build planned
Just to clarify, the patches need to be MERGED by 11:00 AM and not backported by then. Taking into consideration the time it takes for Jenkins to run a full CI I'd suggest backporting everything by tonight and making sure to mark as verified and CR +2 so it will be ready for merging tomorrow morning. On Mon, Jan 18, 2016 at 4:49 PM, Sandro Bonazzola wrote: > Fyi oVirt developers, > > An oVirt build is planned for this Tuesday 11:00 AM TLV time (10:00 AM CET), > please make sure to backport > any open patches to the stable branch for review by the stable branch > maintainers, final date for this will be > Monday 11:00 AM. > > >- > https://bugzilla.redhat.com/buglist.cgi?quicksearch=target_milestone%3A3.6.2%20flag%3Ablocker%20status%3Anew%2Cassigned%2Cpost > > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Subject: Looking for advice regarding user portal development.
Thanks a lot for the welcome and suggestion! I brought your suggestion up with my tutor and was informed VM pooling is something which has been discussed and considered internally and at this juncture it has been decided that pooling is an optimisation which is going to be implemented at a later date. At this time the system is going to be used Makes sense from a performance perspective in an enterprise because you'd have separate storage server + all the images / software would likely be pre-loaded with the same bits of software. This is not always going to be the case with us as we've got a lot of different images with varied installations, we've got students from different year groups using different images at the same time. Also we want the students to have the freedom to install their own tools / software. The primary motivation for using oVirt at our university is to enable the students remote access to a lab environment. Although I mentioned in my previous mail that we wanted students to be able to quickly spin up VMs, I should have used the word simply, as it's more a case of minimising distractions + amount of actions required to create a VM from template. Unfortunately at this juncture we do not have the resources available to set up VM pooling for all of the different images we make use of so are going to approach the workflow in terms of students creating the VMs from template. Many Thanks, Thomas On 12 January 2016 at 09:02, Barak Korren wrote: > Hi, > > Thanks for getting involved with oVirt! > > > > 1) The ability to quickly create a new VM from a template, whilst hiding > > some of the complexity from the user. > > > It seems to me you can gain the same simplicity benefits by using VM > pools and with no additional code... > While cloud environments have made people used to dynamically spinning > up VMs, this is a hammer that does not fit all nails, a pool of > stateless pre-created VMs might suit your need better, and will work > faster from an individual user's point of view. > It is also more efficient in storage terms. > > > > > 2) The ability to provide some of the more advanced features whilst > hiding > > some of the complexities of the Extended view > > ... > > > > Proposed Solution A: Create a third tab ... > > > > Proposed Solution B: Similar to the above ... > > > > Proposed Solution C: Add settings that will allow the user to > enable/disable > > GUI elements in the userportal as required. > > > I would go with solution C which seems to me the most generally useful... > > > > > 3) Ability to specify sets of VM templates which can be created as new > VMs > > together > > > In conjunction with my proposal for feature 1, think about how this > would work for pools... > > -- > Barak Korren > bkor...@redhat.com > RHEV-CI Team > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Topic for next Vdsm call - 19.1
On Mon, Jan 18, 2016 at 1:39 PM, Yaniv Bronheim wrote: > Things I plan to raise. feel free to add more > > 1. Plans to handle async processes without using death signal. > 2. Vdsm messaging - I'll ask Piotr to elaborate about infra plans for that > topic (what about the external broker plans? any standard plan to > communicate with vdsm? such as for supervdsm and mom). > 3. Contract for events and new apis - where it stands. > 4. py.test - If someone can pick up the migration to py test Looks good. I would add: 5. __del__ is considered harmful, removing it from vdsm ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Missing admin permissions.
Hi,
Somewhere during master upgrades somehow my admin@internal did not get
permissions to create VMs. Its is compiling about no permissions to assign a
CPU profile. Its been a while since I tried creating a VM. Can any one point me
to what is missing and how to fix it?
This is the error in the log:
2016-01-18 15:59:46,843 INFO [org.ovirt.engine.core.bll.AddVmCommand]
(default task-56) [a6fd12b] Lock Acquired to object 'EngineLock:
{exclusiveLocks='[=]',
sharedLocks='[----=]'}'
2016-01-18 15:59:46,893 WARN [org.ovirt.engine.core.bll.AddVmCommand]
(default task-56) [] Validation of action 'AddVm' failed for user
admin@internal. Reasons:
VAR__ACTION__ADD,VAR__TYPE__VM,ACTION_TYPE_NO_PERMISSION_TO_ASSIGN_CPU_PROFILE,
$cpuProfileId f9a05b39-9f57-4655-aab2-2846fe6519f6,$cpuProfileName DEV35
2016-01-18 15:59:46,894 INFO [org.ovirt.engine.core.bll.AddVmCommand]
(default task-56) [] Lock freed to object 'EngineLock:
{exclusiveLocks='[=]',
sharedLocks='[----=]'}'
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Missing admin permissions.
On Mon, Jan 18, 2016 at 11:00 PM, Alexander Wels wrote:
> Hi,
>
> Somewhere during master upgrades somehow my admin@internal did not get
> permissions to create VMs. Its is compiling about no permissions to assign
> a
> CPU profile. Its been a while since I tried creating a VM. Can any one
> point me
> to what is missing and how to fix it?
>
Perhaps it's https://bugzilla.redhat.com/show_bug.cgi?id=1293338 , and the
workaround is to re-run engine-setup, I believe.
Y.
>
> This is the error in the log:
> 2016-01-18 15:59:46,843 INFO [org.ovirt.engine.core.bll.AddVmCommand]
> (default task-56) [a6fd12b] Lock Acquired to object 'EngineLock:
> {exclusiveLocks='[=]',
> sharedLocks='[----= ACTION_TYPE_FAILED_TEMPLATE_IS_USED_FOR_CREATE_VM$VmName >]'}'
> 2016-01-18 15:59:46,893 WARN [org.ovirt.engine.core.bll.AddVmCommand]
> (default task-56) [] Validation of action 'AddVm' failed for user
> admin@internal. Reasons:
>
> VAR__ACTION__ADD,VAR__TYPE__VM,ACTION_TYPE_NO_PERMISSION_TO_ASSIGN_CPU_PROFILE,
> $cpuProfileId f9a05b39-9f57-4655-aab2-2846fe6519f6,$cpuProfileName DEV35
> 2016-01-18 15:59:46,894 INFO [org.ovirt.engine.core.bll.AddVmCommand]
> (default task-56) [] Lock freed to object 'EngineLock:
> {exclusiveLocks='[=]',
> sharedLocks='[----= ACTION_TYPE_FAILED_TEMPLATE_IS_USED_FOR_CREATE_VM$VmName >]'}'
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Missing admin permissions.
I think this should help:
https://www.mail-archive.com/devel%40ovirt.org/msg05152.html
On Mon, Jan 18, 2016 at 11:38 PM, Yaniv Kaul wrote:
>
>
> On Mon, Jan 18, 2016 at 11:00 PM, Alexander Wels wrote:
>
>> Hi,
>>
>> Somewhere during master upgrades somehow my admin@internal did not get
>> permissions to create VMs. Its is compiling about no permissions to
>> assign a
>> CPU profile. Its been a while since I tried creating a VM. Can any one
>> point me
>> to what is missing and how to fix it?
>>
>
> Perhaps it's https://bugzilla.redhat.com/show_bug.cgi?id=1293338 , and
> the workaround is to re-run engine-setup, I believe.
> Y.
>
>
>>
>> This is the error in the log:
>> 2016-01-18 15:59:46,843 INFO [org.ovirt.engine.core.bll.AddVmCommand]
>> (default task-56) [a6fd12b] Lock Acquired to object 'EngineLock:
>> {exclusiveLocks='[=]',
>> sharedLocks='[----=> ACTION_TYPE_FAILED_TEMPLATE_IS_USED_FOR_CREATE_VM$VmName >]'}'
>> 2016-01-18 15:59:46,893 WARN [org.ovirt.engine.core.bll.AddVmCommand]
>> (default task-56) [] Validation of action 'AddVm' failed for user
>> admin@internal. Reasons:
>>
>> VAR__ACTION__ADD,VAR__TYPE__VM,ACTION_TYPE_NO_PERMISSION_TO_ASSIGN_CPU_PROFILE,
>> $cpuProfileId f9a05b39-9f57-4655-aab2-2846fe6519f6,$cpuProfileName DEV35
>> 2016-01-18 15:59:46,894 INFO [org.ovirt.engine.core.bll.AddVmCommand]
>> (default task-56) [] Lock freed to object 'EngineLock:
>> {exclusiveLocks='[=]',
>> sharedLocks='[----=> ACTION_TYPE_FAILED_TEMPLATE_IS_USED_FOR_CREATE_VM$VmName >]'}'
>>
>> ___
>> Devel mailing list
>> Devel@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/devel
>>
>
>
> ___
> Devel mailing list
> Devel@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel
>
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
