Re: [Engine-devel] Maven 3 here we come!
On 23/05/12 19:58, snmis...@linux.vnet.ibm.com wrote: > > New to maven. Using rhel6.2, and installed maven 3.0.4. Changed path to pick > this version instead of 2.2.1 I was using before. > > when running "mvn clean install" I see - > > Downloading: > http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plugin/2.3.1/maven-install-plugin-2.3.1.pom > > It doesn't look right, shouldn't it be maven3 instead of maven2 ? Sharad, Maven works with plugins for various tasks. Each plugin is a Maven artifact with its own version. The install plugin handles installation tasks to local repository. You can read more about it here: http://maven.apache.org/plugins/maven-install-plugin/ So in this case, your Maven 3 is using a plugin called maven-install, and the /plugin's/ version is 2.3.1. That's perfectly fine. > > Do we need to update the "Maven personal settings" section on > http://www.ovirt.org/wiki/Building_Ovirt_Engine > > At least the part where it says "maven 3.x will not work". How about > ~/.m2/settings.xml ? Thanks for the reminder- wiki updated. No change needed for the settings.xml file, or its location. > > -Sharad > > Quoting Eyal Edri : > >> - Original Message - >>> From: "Doron Fediuck" >>> To: engine-devel@ovirt.org >>> Cc: "" >>> Sent: Wednesday, May 23, 2012 12:59:53 PM >>> Subject: [Engine-devel] Maven 3 here we come! >>> >>> Hi all, >>> As discussed last month[1], we had to deal with some issues which >>> turned out to be a Maven bug. >>> Thanks to Juan and Asaf's work, our current sources now build >>> properly using Maven 3. >>> So you're all invited to migrate into Maven 3. Other than upgrading >>> your local maven package >>> no other action is needed. >>> >>> For now, Maven 2 will also work for you, but I expect in the future >>> we'd like to make use >>> of some advanced features, so migration to 3 is recommended. >>> >>> Talking about advanced features, an interesting challenge is feedback >>> on parallel builds [2]. >>> So whoever wants to try it out and report if it improves run time >>> without breaking anything, >>> will be appreciated. >>> >>> Happy migration! >>> >>> [1]http://lists.ovirt.org/pipermail/arch/2012-April/000490.html >>> [2] https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html >>> -- >> >> +1 on the move and testing out new features! >> >>> >>> /d >>> >>> "Email returned to sender -- insufficient voltage." >>> ___ >>> Engine-devel mailing list >>> Engine-devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> ___ >> Engine-devel mailing list >> Engine-devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > -- /d "This message is made with 100% recycled electrons. No new atoms were destroyed in the making of this message." ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Maven 3 here we come!
- Original Message - > From: "Yaniv Kaul" > To: "Doron Fediuck" > Cc: engine-devel@ovirt.org, "" > Sent: Wednesday, May 23, 2012 11:04:12 PM > Subject: Re: [Engine-devel] Maven 3 here we come! > > On 05/23/2012 12:59 PM, Doron Fediuck wrote: > > Hi all, > > As discussed last month[1], we had to deal with some issues which > > turned out to be a Maven bug. > > Thanks to Juan and Asaf's work, our current sources now build > > properly using Maven 3. > > So you're all invited to migrate into Maven 3. Other than upgrading > > your local maven package > > no other action is needed. > > > > For now, Maven 2 will also work for you, but I expect in the future > > we'd like to make use > > of some advanced features, so migration to 3 is recommended. > > > > Talking about advanced features, an interesting challenge is > > feedback on parallel builds [2]. > > I'm not happy with parallel builds - it creates more java processes, > each taking quite a bit of memory. This, in turn, causes them to > swap, > making everything crawl. > Took me 22 minutes to compile the webadmin and additional 21 minutes > for > the user portal, with -T 4. I've had 3.5GB of swap used (and 7GB > resident memory with 'java' processes running around). > It usually takes me > > The command line I've used was: > mvn -T 4 clean install -Pgwt-admin,gwt-user -DskipTests=true > -Dmaven.test.skip=true > Have you tried using the mvn -T 1C option (to run one thread per core?) On some builds it reduced my compilation time in a few min, but it wasn't consistent. also, maven says that some of the modules are not thread-safe and he will run then sequentially, so perhaps if the modules were re-factored to fit parallel builds, only then we'll see real improvement. > > As opposed to 7+ 3 minutes without '-T 4'. > > Y. > > > So whoever wants to try it out and report if it improves run time > > without breaking anything, > > will be appreciated. > > > > Happy migration! > > > > [1]http://lists.ovirt.org/pipermail/arch/2012-April/000490.html > > [2]https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html > > > ___ > Arch mailing list > a...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/arch > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Maven 3 here we come!
On 05/23/2012 12:59 PM, Doron Fediuck wrote: Hi all, As discussed last month[1], we had to deal with some issues which turned out to be a Maven bug. Thanks to Juan and Asaf's work, our current sources now build properly using Maven 3. So you're all invited to migrate into Maven 3. Other than upgrading your local maven package no other action is needed. For now, Maven 2 will also work for you, but I expect in the future we'd like to make use of some advanced features, so migration to 3 is recommended. Talking about advanced features, an interesting challenge is feedback on parallel builds [2]. I'm not happy with parallel builds - it creates more java processes, each taking quite a bit of memory. This, in turn, causes them to swap, making everything crawl. Took me 22 minutes to compile the webadmin and additional 21 minutes for the user portal, with -T 4. I've had 3.5GB of swap used (and 7GB resident memory with 'java' processes running around). It usually takes me The command line I've used was: mvn -T 4 clean install -Pgwt-admin,gwt-user -DskipTests=true -Dmaven.test.skip=true As opposed to 7+ 3 minutes without '-T 4'. Y. So whoever wants to try it out and report if it improves run time without breaking anything, will be appreciated. Happy migration! [1]http://lists.ovirt.org/pipermail/arch/2012-April/000490.html [2]https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] Maven 3 here we come!
New to maven. Using rhel6.2, and installed maven 3.0.4. Changed path to pick this version instead of 2.2.1 I was using before. when running "mvn clean install" I see - Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-install-plugin/2.3.1/maven-install-plugin-2.3.1.pom It doesn't look right, shouldn't it be maven3 instead of maven2 ? Do we need to update the "Maven personal settings" section on http://www.ovirt.org/wiki/Building_Ovirt_Engine At least the part where it says "maven 3.x will not work". How about ~/.m2/settings.xml ? -Sharad Quoting Eyal Edri : - Original Message - From: "Doron Fediuck" To: engine-devel@ovirt.org Cc: "" Sent: Wednesday, May 23, 2012 12:59:53 PM Subject: [Engine-devel] Maven 3 here we come! Hi all, As discussed last month[1], we had to deal with some issues which turned out to be a Maven bug. Thanks to Juan and Asaf's work, our current sources now build properly using Maven 3. So you're all invited to migrate into Maven 3. Other than upgrading your local maven package no other action is needed. For now, Maven 2 will also work for you, but I expect in the future we'd like to make use of some advanced features, so migration to 3 is recommended. Talking about advanced features, an interesting challenge is feedback on parallel builds [2]. So whoever wants to try it out and report if it improves run time without breaking anything, will be appreciated. Happy migration! [1]http://lists.ovirt.org/pipermail/arch/2012-April/000490.html [2] https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html -- +1 on the move and testing out new features! /d "Email returned to sender -- insufficient voltage." ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] custom properties sheet feature page
> - Original Message - > From: "Simon Grinberg" > Sent: Wednesday, May 23, 2012 6:53:46 PM > > - Original Message - > > From: "Itamar Heim" > > To: "Einav Cohen" > > Cc: "Andrew Cathrow" , "Eldan Hildesheim" > > , engine-devel@ovirt.org, "Simon > > Grinberg" , "Eldan Hildesheim" > > > > Sent: Friday, May 18, 2012 1:50:17 AM > > Subject: Re: [Engine-devel] custom properties sheet feature page > > > > On 05/17/2012 04:08 PM, Einav Cohen wrote: > > ... > > >>> Hi, > > >>> > > >>> Please review/comment on the Custom Properties Sheet feature > > >>> page: > > >>> http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > > >>> > > >> > > >> It looks great. > > >> Are all the keys going to be exposed in the dropdown, or will we > > >> have > > >> private keys that the user has to know about? > > > > > > All keys will be exposed; not sure what you mean by "private", > > > but > > > all keys are treated the same today. > > > If we want some kind of differentiation between the keys, it is a > > > another feature... > > > [I could, of course, be missing something, please clarify if I > > > did] > > > > > > > in the future, we may want to give permissions to which users are > > allowed to use which custom properties. > > not relevant for now. > > Is this cool looking design be also available from the user portal? custom properties aren't available in the user portal. > If so how do you prevent any user that just have permission to Edit > VMs to do damage? With custom property you can do almost anything. > > Consider the case where there is a hook that allows to directly > attach a LUN/Add Tap/more destructive options. It is intended for > use of the sys admins but any user can use. > > You would say correctly that this was always the case. But with the > old textbox interface the user would need to know that the option > exists. Now we actually tell him what he can use. > > Cool for the webadmin / kind'a dangerous from the user portal until > you get permissions per users feature for it. > > The minimum that is needed is an option to disable this properties > tab in the user portal. > Better have MLA for using properties at all if per property can't be > accommodated. > > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > > > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] custom properties sheet feature page
- Original Message - > From: "Itamar Heim" > To: "Einav Cohen" > Cc: "Andrew Cathrow" , "Eldan Hildesheim" > , engine-devel@ovirt.org, "Simon > Grinberg" , "Eldan Hildesheim" > Sent: Friday, May 18, 2012 1:50:17 AM > Subject: Re: [Engine-devel] custom properties sheet feature page > > On 05/17/2012 04:08 PM, Einav Cohen wrote: > ... > >>> Hi, > >>> > >>> Please review/comment on the Custom Properties Sheet feature > >>> page: > >>> http://www.ovirt.org/wiki/Features/CustomPropertiesSheet > >>> > >> > >> It looks great. > >> Are all the keys going to be exposed in the dropdown, or will we > >> have > >> private keys that the user has to know about? > > > > All keys will be exposed; not sure what you mean by "private", but > > all keys are treated the same today. > > If we want some kind of differentiation between the keys, it is a > > another feature... > > [I could, of course, be missing something, please clarify if I did] > > > > in the future, we may want to give permissions to which users are > allowed to use which custom properties. > not relevant for now. Is this cool looking design be also available from the user portal? If so how do you prevent any user that just have permission to Edit VMs to do damage? With custom property you can do almost anything. Consider the case where there is a hook that allows to directly attach a LUN/Add Tap/more destructive options. It is intended for use of the sys admins but any user can use. You would say correctly that this was always the case. But with the old textbox interface the user would need to know that the option exists. Now we actually tell him what he can use. Cool for the webadmin / kind'a dangerous from the user portal until you get permissions per users feature for it. The minimum that is needed is an option to disable this properties tab in the user portal. Better have MLA for using properties at all if per property can't be accommodated. ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
Re: [Engine-devel] restapi: New params for import VM/Template
- Original Message - > From: "Gilad Chaplik" > To: "Simon Grinberg" > Cc: "Michael Pasternak" , "engine-devel" > , "Itamar Heim" > , "Livnat Peer" , "Ori Liel" > > Sent: Thursday, May 17, 2012 10:21:51 AM > Subject: Re: [Engine-devel] restapi: New params for import VM/Template > > cc'ing Simon, > > Hi Simon, > > I remember we talked about why the engine can't decide implicitly if > to clone the vm or not - it should be the user call? > Can you share your opinion about that? Sorry for missing on that. First reason informative - User should know what he and we are doing. Example: * Setup2 already has vm named Kuku imported few months back or by another admin * The admin that usually works on setup1, decides it's time to move the VM to setup2 (for any reason), so he exports kuku and then imports into setup1 * We automatically import as Kuku1 * Admin searches for the name kuku and starts it - he is now working on the old one without knowing it. The above can cause confusion, lost time to understand why kuku is not working as expected and/or lost time to fix the err when trying to merge data from the currently running kuku and kuku1 which is the VM the user actually wanted to use. We must stop and ask. The question should be very similar to file copy on decent OSs - Override, save as, cancel. So does the API for this operation. * The above also leads to also question if importing a VM with the same name as a vm in the system, even though it is clear it's a different VM (different GUID/image ID etc) Second reason - prevent user error: User writes a script, by mistake he tries to copy the same VM over and over (he meant other VMs or just wrong stop condition), he can easily fill out his storage domain, or waste a lot of time before discovering the mistake since we don't return error but silently clone as new, Again the options above should be suffice to prevent that, if the user decides to to use with the force overrider or always clone, that is his problem. Third one, convenience: Assume a user has a VM on setup1, and wants a similar but not identical setup2. The reason is that he may want some day to move the VM to setup2. There is no support at all for this scenario. it will be either, the VM is imported as is and if he wants to move over the original VM it will have to be cloned (Thus changed). Or he can import and clone now (redundant copy operation) - The use case here is similar for the clone VM functionality but the clone is into a different setup. We should not always assume that it's fine to have identical VMs on different setups. I can think of some more if it's really necessary : Bottom line: Having this now will save at least 3 RFEs coming from the reasoning above and in a very reasonable price. All we have to do is to allow a checkbox in the import menu and stop assuming that we know better then the user what he wants to do. If you have a functionality that on one hand makes a novice user life easier while on the other hand may restrict advanced users, allow to choose - just have the defaults set to the case you think is the most common. The said above assumes clone on import changes everything including image IDs otherwise all the said above is a moot point. * Now in more advanced scenarios, use may be able to change everything he's allowed to change - same as when he does "Clone VM from template". But this is extension to simple clone case, with the price of going to the VM properties and edit it is solvable. * If override is complex for now, then reject if not specifically stated to clone (in the API) and Question to Copy As or Cancel is also reasonable. The user can always choose cancel and delete before trying again. > > Thanks, > Gilad. > > - Original Message - > > From: "Livnat Peer" > > To: "Gilad Chaplik" > > Cc: "Michael Pasternak" , "engine-devel" > > , "Itamar Heim" > > > > Sent: Thursday, May 17, 2012 9:43:45 AM > > Subject: Re: [Engine-devel] restapi: New params for import > > VM/Template > > > > > > > > > > Going FW it would be nice to override parameters in import > > > vm/template > > > > > > I agree with you and that's why - > > > > As a user I don't think there should be a difference in the API > > between: > > - Importing a VM and changing it's name > > - Importing a VM for the second time > > > > The reason you want to add artificial difference between the two > > scenarios above is because currently there are implementations > > limitations (changing the image ID while importing is not supported > > yet) > > > > I think that we should solve the limitations in the implementation > > instead of making our API cumbersome (implicit clone by name and > > adding > > some clone entity are both bad IMO). > > > > > > > > Livnat > > > > > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovi
Re: [Engine-devel] Maven 3 here we come!
- Original Message - > From: "Doron Fediuck" > To: engine-devel@ovirt.org > Cc: "" > Sent: Wednesday, May 23, 2012 12:59:53 PM > Subject: [Engine-devel] Maven 3 here we come! > > Hi all, > As discussed last month[1], we had to deal with some issues which > turned out to be a Maven bug. > Thanks to Juan and Asaf's work, our current sources now build > properly using Maven 3. > So you're all invited to migrate into Maven 3. Other than upgrading > your local maven package > no other action is needed. > > For now, Maven 2 will also work for you, but I expect in the future > we'd like to make use > of some advanced features, so migration to 3 is recommended. > > Talking about advanced features, an interesting challenge is feedback > on parallel builds [2]. > So whoever wants to try it out and report if it improves run time > without breaking anything, > will be appreciated. > > Happy migration! > > [1]http://lists.ovirt.org/pipermail/arch/2012-April/000490.html > [2] https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html > -- +1 on the move and testing out new features! > > /d > > "Email returned to sender -- insufficient voltage." > ___ > Engine-devel mailing list > Engine-devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
[Engine-devel] Maven 3 here we come!
Hi all, As discussed last month[1], we had to deal with some issues which turned out to be a Maven bug. Thanks to Juan and Asaf's work, our current sources now build properly using Maven 3. So you're all invited to migrate into Maven 3. Other than upgrading your local maven package no other action is needed. For now, Maven 2 will also work for you, but I expect in the future we'd like to make use of some advanced features, so migration to 3 is recommended. Talking about advanced features, an interesting challenge is feedback on parallel builds [2]. So whoever wants to try it out and report if it improves run time without breaking anything, will be appreciated. Happy migration! [1]http://lists.ovirt.org/pipermail/arch/2012-April/000490.html [2] https://cwiki.apache.org/MAVEN/parallel-builds-in-maven-3.html -- /d "Email returned to sender -- insufficient voltage." ___ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
