[ovirt-devel] [ATN] [master] SSO patchset were merged
Hello, We have merged SSO patchset into master. These kind of deep infra changes are non trivial, we hope we reduced most of the side effects within the 171 revisions and testing. Thanks for Ravi Nori for his great effort! The SSO is based on OAuth2 specification, full description is available[1], it is a stable supported interface of engine. In a nut shell, the major change is that login dialog is now handled by a separate non gwt webapp, this webapp provides authentication and authorization services to other webapps. The immediate bonus is: no need to re-authenticate to user portal and/or admin portal, maybe soon we integrate reports. Performance bonus: if using spnego (kerberos) there is no performance penalty (double request). Usability bonus: support many authentication sequences we were unable to provide using the previous implementation. Regards, Alon Bar-Lev. [1] http://www.ovirt.org/Features/UniformSSOSupport ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Reported-By - giving credit to our testers
- Original Message - > From: "Yaniv Kaul" > To: "Nir Soffer" > Cc: "Piotr Kliczewski" , "devel" > Sent: Thursday, November 12, 2015 4:55:10 PM > Subject: Re: [ovirt-devel] Reported-By - giving credit to our testers > > On Thu, Nov 12, 2015 at 4:45 PM, Nir Soffer < nsof...@redhat.com > wrote: > > > Hi all, > > Our QE (and sometimes our users) are working hard testing and > reporting bugs, but > their effort is never mentioned in our code. > > Looking at kernel git history, I found that they are using the > Reported-By header for > giving credit to the person reporting a bug. I suggest we adapt this header. > > Here are some examples how we can use it: > > - https://gerrit.ovirt.org/#/c/48483/3//COMMIT_MSG > - > https://github.com/oVirt/vdsm/commit/fb4c72af5e4c200409c74834111d44d92959ebbd > - > https://github.com/oVirt/vdsm/commit/f8127d88add881a4775e7030dde2433125c7b598 > > Thanks, > Nir > ___ > Devel mailing list > Devel@ovirt.org > http://lists.ovirt.org/mailman/listinfo/devel > > +1 > > In case they help with the verification of the change, I suggest adding > Tested-By which is just as important. > From https://www.kernel.org/doc/Documentation/SubmittingPatches : > > A Tested-by: tag indicates that the patch has been successfully tested (in > some environment) by the person named. This tag informs maintainers that > some testing has been performed, provides a means to locate testers for > future patches, and ensures credit for the testers. This meant to give credit for whoever is doing that in his own time, not for cooperation that pays for QA nor replace bugzilla. If you go over the logs, you will see I provide Reported-By and Tested-By two who produce significant effort in helping out a case. > > Y. > > ___ > 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 deps for ovirt-engine-extension-aaa-misc on fc23
no, the tomcat package does not provide classpath generic but fedora. /usr/share/doc/tomcat-servlet-3.1-api /usr/share/doc/tomcat-servlet-3.1-api/LICENSE /usr/share/java/tomcat-servlet-3.1-api.jar /usr/share/java/tomcat-servlet-api.jar /usr/share/maven-metadata/tomcat-tomcat-servlet-api.xml /usr/share/maven-poms/JPP-tomcat-servlet-api.pom - Original Message - > From: "Alon Bar-Lev" > To: "Sandro Bonazzola" > Cc: "devel" > Sent: Monday, November 9, 2015 3:33:14 PM > Subject: Re: [ovirt-devel] missing deps for ovirt-engine-extension-aaa-misc > onfc23 > > > ok, please try if tomcat-servlet-3.1-api works for you. > I see that we do have servlet = 3.0 virtual since fc22, so having servlet >= > 2.5 should do the trick. > > - Original Message - > > From: "Alon Bar-Lev" > > To: "Sandro Bonazzola" > > Cc: "devel" > > Sent: Monday, November 9, 2015 3:25:31 PM > > Subject: Re: [ovirt-devel] missing deps for ovirt-engine-extension-aaa-misc > > on fc23 > > > > > > This is pure packaging, you can submit fixes as well. > > I have no fedora 23 setup. > > What package provides servlet api in fedora 23? > > We already had these: tomcat6-servlet-2.5-api, tomcat-servlet-3.0-api while > > having no virtual (Provides). > > > > - Original Message - > > > From: "Sandro Bonazzola" > > > To: "devel" > > > Sent: Monday, November 9, 2015 3:19:53 PM > > > Subject: [ovirt-devel] missing deps for ovirt-engine-extension-aaa-misc > > > on > > > fc23 > > > > > > DEBUG util.py:393: Getting requirements for > > > ovirt-engine-extension-aaa-misc-1.0.1-0.0.master.20151109125118.git7fb5a88.fc23.src > > > DEBUG util.py:393: --> ant-1.9.6-2.fc23.noarch > > > DEBUG util.py:393: --> > > > 1:java-1.8.0-openjdk-devel-1.8.0.65-3.b17.fc23.x86_64 > > > DEBUG util.py:393: --> javapackages-tools-4.6.0-7.fc23.noarch > > > DEBUG util.py:393: --> > > > ovirt-engine-extensions-api-impl-4.0.0-0.0.master.20151109101020.gitc097ce3.fc23.noarch > > > DEBUG util.py:393: --> slf4j-1.7.12-2.fc23.noarch > > > DEBUG util.py:393: Error: No Package found for tomcat-servlet-3.0-api > > > please fix ASAP. > > > Thanks, > > > -- > > > 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 > > ___ > > 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
Re: [ovirt-devel] missing deps for ovirt-engine-extension-aaa-misc on fc23
ok, please try if tomcat-servlet-3.1-api works for you. I see that we do have servlet = 3.0 virtual since fc22, so having servlet >= 2.5 should do the trick. - Original Message - > From: "Alon Bar-Lev" > To: "Sandro Bonazzola" > Cc: "devel" > Sent: Monday, November 9, 2015 3:25:31 PM > Subject: Re: [ovirt-devel] missing deps for ovirt-engine-extension-aaa-misc > onfc23 > > > This is pure packaging, you can submit fixes as well. > I have no fedora 23 setup. > What package provides servlet api in fedora 23? > We already had these: tomcat6-servlet-2.5-api, tomcat-servlet-3.0-api while > having no virtual (Provides). > > - Original Message - > > From: "Sandro Bonazzola" > > To: "devel" > > Sent: Monday, November 9, 2015 3:19:53 PM > > Subject: [ovirt-devel] missing deps for ovirt-engine-extension-aaa-misc on > > fc23 > > > > DEBUG util.py:393: Getting requirements for > > ovirt-engine-extension-aaa-misc-1.0.1-0.0.master.20151109125118.git7fb5a88.fc23.src > > DEBUG util.py:393: --> ant-1.9.6-2.fc23.noarch > > DEBUG util.py:393: --> > > 1:java-1.8.0-openjdk-devel-1.8.0.65-3.b17.fc23.x86_64 > > DEBUG util.py:393: --> javapackages-tools-4.6.0-7.fc23.noarch > > DEBUG util.py:393: --> > > ovirt-engine-extensions-api-impl-4.0.0-0.0.master.20151109101020.gitc097ce3.fc23.noarch > > DEBUG util.py:393: --> slf4j-1.7.12-2.fc23.noarch > > DEBUG util.py:393: Error: No Package found for tomcat-servlet-3.0-api > > please fix ASAP. > > Thanks, > > -- > > 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 > ___ > 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 deps for ovirt-engine-extension-aaa-misc on fc23
This is pure packaging, you can submit fixes as well. I have no fedora 23 setup. What package provides servlet api in fedora 23? We already had these: tomcat6-servlet-2.5-api, tomcat-servlet-3.0-api while having no virtual (Provides). - Original Message - > From: "Sandro Bonazzola" > To: "devel" > Sent: Monday, November 9, 2015 3:19:53 PM > Subject: [ovirt-devel] missing deps for ovirt-engine-extension-aaa-misc on > fc23 > > DEBUG util.py:393: Getting requirements for > ovirt-engine-extension-aaa-misc-1.0.1-0.0.master.20151109125118.git7fb5a88.fc23.src > DEBUG util.py:393: --> ant-1.9.6-2.fc23.noarch > DEBUG util.py:393: --> > 1:java-1.8.0-openjdk-devel-1.8.0.65-3.b17.fc23.x86_64 > DEBUG util.py:393: --> javapackages-tools-4.6.0-7.fc23.noarch > DEBUG util.py:393: --> > ovirt-engine-extensions-api-impl-4.0.0-0.0.master.20151109101020.gitc097ce3.fc23.noarch > DEBUG util.py:393: --> slf4j-1.7.12-2.fc23.noarch > DEBUG util.py:393: Error: No Package found for tomcat-servlet-3.0-api > please fix ASAP. > Thanks, > -- > 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 ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Login issue on master
People, please DO NOT try to upgrade database not via engine-setup. Any manual changes of database will cause your system to be invalid, in this case the setup will not be able to upgrade between configuration admin user to new. Also, please remember to make install-dev= so that you have synced PREFIX with whatever version you are working on. In this case the PREFIX is out of date. - Original Message - > From: "Vered Volansky" > To: "Alon Bar-Lev" > Cc: "Martin Perina" , "Omer Frenkel" > , "Oved Ourfali" , > devel@ovirt.org > Sent: Wednesday, August 12, 2015 10:25:17 AM > Subject: Re: [ovirt-devel] Login issue on master > > new setup log attached. > > On Wed, Aug 12, 2015 at 9:57 AM, Vered Volansky wrote: > > > I did what Alon suggested, replaced only MY_PASSWORD. engine setup was ok, > > but I still get the same error on login. > > > > > > On Wed, Aug 12, 2015 at 9:46 AM, Alon Bar-Lev wrote: > > > >> > >> > >> - Original Message - > >> > From: "Martin Perina" > >> > To: "Omer Frenkel" > >> > Cc: "Oved Ourfali" , "Vered Volansky" < > >> ve...@redhat.com>, devel@ovirt.org > >> > Sent: Wednesday, August 12, 2015 9:35:08 AM > >> > Subject: Re: [ovirt-devel] Login issue on master > >> > > >> > > >> > > >> > - Original Message - > >> > > From: "Omer Frenkel" > >> > > To: "Martin Perina" > >> > > Cc: "Vered Volansky" , "Oved Ourfali" < > >> ov...@redhat.com>, > >> > > devel@ovirt.org > >> > > Sent: Wednesday, August 12, 2015 8:28:00 AM > >> > > Subject: Re: [ovirt-devel] Login issue on master > >> > > > >> > > On Wed, Aug 12, 2015 at 8:54 AM, Martin Perina > >> wrote: > >> > > > >> > > > > >> > > > > >> > > > - Original Message - > >> > > > > From: "Oved Ourfali" > >> > > > > To: "Vered Volansky" > >> > > > > Cc: devel@ovirt.org > >> > > > > Sent: Wednesday, August 12, 2015 7:51:14 AM > >> > > > > Subject: Re: [ovirt-devel] Login issue on master > >> > > > > > >> > > > > Please share complete engine.log and server.log. > >> > > > > >> > > > Log produced by engine-setup is more important at the moment. > >> > > > Are you sure that engine-setup finished successfully? > >> > > > > >> > > > > > >> > > > > - Original Message - > >> > > > > > From: "Vered Volansky" > >> > > > > > To: devel@ovirt.org > >> > > > > > Sent: Wednesday, August 12, 2015 8:48:00 AM > >> > > > > > Subject: Re: [ovirt-devel] Login issue on master > >> > > > > > > >> > > > > > engine: > >> > > > > > 2015-08-12 08:12:41,129 INFO > >> > > > > > [org.ovirt.engine.core.bll.aaa.LoginBaseCommand] > >> > > > > > (default task-28) [] Can't login user 'admin' with > >> authentication > >> > > > profile > >> > > > > > 'internal' because the authentication failed. > >> > > > > > 2015-08-12 08:12:41,146 ERROR > >> > > > > > > >> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > >> > > > > > (default task-28) [] Correlation ID: null, Call Stack: null, > >> Custom > >> > > > Event > >> > > > > > ID: -1, Message: User admin cannot login, please verify the > >> username > >> > > > and > >> > > > > > password. > >> > > > > > 2015-08-12 08:12:41,154 ERROR > >> > > > > > > >> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] > >> > > > > > (default task-28) [] Correlation ID: null, Call Stack: null, > >> Custom > >> > > > Event > >> > > > > > ID: -1, Message: User admin@internal failed to log in. > >> > > > > > 2015-08-12 08:12:41,154 WARN > >> > > > > > [org.ovirt.engine.core
Re: [ovirt-devel] Login issue on master
- Original Message -
> From: "Martin Perina"
> To: "Omer Frenkel"
> Cc: "Oved Ourfali" , "Vered Volansky" ,
> devel@ovirt.org
> Sent: Wednesday, August 12, 2015 9:35:08 AM
> Subject: Re: [ovirt-devel] Login issue on master
>
>
>
> - Original Message -
> > From: "Omer Frenkel"
> > To: "Martin Perina"
> > Cc: "Vered Volansky" , "Oved Ourfali" ,
> > devel@ovirt.org
> > Sent: Wednesday, August 12, 2015 8:28:00 AM
> > Subject: Re: [ovirt-devel] Login issue on master
> >
> > On Wed, Aug 12, 2015 at 8:54 AM, Martin Perina wrote:
> >
> > >
> > >
> > > - Original Message -
> > > > From: "Oved Ourfali"
> > > > To: "Vered Volansky"
> > > > Cc: devel@ovirt.org
> > > > Sent: Wednesday, August 12, 2015 7:51:14 AM
> > > > Subject: Re: [ovirt-devel] Login issue on master
> > > >
> > > > Please share complete engine.log and server.log.
> > >
> > > Log produced by engine-setup is more important at the moment.
> > > Are you sure that engine-setup finished successfully?
> > >
> > > >
> > > > - Original Message -
> > > > > From: "Vered Volansky"
> > > > > To: devel@ovirt.org
> > > > > Sent: Wednesday, August 12, 2015 8:48:00 AM
> > > > > Subject: Re: [ovirt-devel] Login issue on master
> > > > >
> > > > > engine:
> > > > > 2015-08-12 08:12:41,129 INFO
> > > > > [org.ovirt.engine.core.bll.aaa.LoginBaseCommand]
> > > > > (default task-28) [] Can't login user 'admin' with authentication
> > > profile
> > > > > 'internal' because the authentication failed.
> > > > > 2015-08-12 08:12:41,146 ERROR
> > > > > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> > > > > (default task-28) [] Correlation ID: null, Call Stack: null, Custom
> > > Event
> > > > > ID: -1, Message: User admin cannot login, please verify the username
> > > and
> > > > > password.
> > > > > 2015-08-12 08:12:41,154 ERROR
> > > > > [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> > > > > (default task-28) [] Correlation ID: null, Call Stack: null, Custom
> > > Event
> > > > > ID: -1, Message: User admin@internal failed to log in.
> > > > > 2015-08-12 08:12:41,154 WARN
> > > > > [org.ovirt.engine.core.bll.aaa.LoginAdminUserCommand] (default
> > > task-28) []
> > > > > CanDoAction of action 'LoginAdminUser' failed for user
> > > > > admin@internal.
> > > > > Reasons: USER_FAILED_TO_AUTHENTICATE_WRONG_USERNAME_OR_PASSWORD
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Aug 12, 2015 at 8:41 AM, Vered Volansky < ve...@redhat.com >
> > > wrote:
> > > > >
> > > > >
> > > > >
> > > > > Can't login to engine after rebase and schema-dev execution.
> > > > > Can't investigate more at the moment, just a heads up.
> > > > >
> > > > >
> > > > > ___
> > > > > 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
> > >
> >
> > any chance you deleted your prefix?
> > if so, the setup creates new keys and cannot decrypt the saved password
> > (that was encryped using the old keys), try to use
> > engine-config --set AdminPassword=interactive
>
> This is no longer valid, admin password is not stored in vdc_options anymore.
> If you want to change you admin@internal password, please do following:
>
> 1. Run ovirt-engine-crypto-tool to encode new password:
>
> ${PREFIX}/share/ovirt-engine/bin/ovirt-engine-crypto-tool.sh pbe-encode
> --password=interactive:
>
> 2. Save encoding password into
> ${PREFIX}/etc/ovirt-engine/extension.d/internal-authn.properties
>into field config.authn.user.password
>
> 3. Restart the engine
>
$ PREFIX/bin/engine-setup
--otopi-environment="OVESETUP_CONFIG/adminPassword=str:MY_PASSWORD"
will set your password in simpler manner.
>
>
> >
> > to create new password, restart the engine and try..
> >
> ___
> 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] ovirt-engine-extension-aaa-ldap-setup broken dep on 3.5
Hi, I already branched, ovirt-engine-extension-aaa-ldap-1.0 Even with no branch the master will work with 3.5 excluding the setup package. Regards, Alon - Original Message - > From: "Sandro Bonazzola" > To: "Alon Bar-Lev" , devel@ovirt.org > Sent: Friday, July 31, 2015 9:45:36 AM > Subject: [ovirt-devel] ovirt-engine-extension-aaa-ldap-setup broken dep on > 3.5 > > Hi, > looks like a recent change in ovirt-engine-extension-aaa-ldap-setup is now > requiring engine 3.6 and otopi 1.4. Please branch > ovirt-engine-extension-aaa-ldap-setup to keep 3.5 support or make it still > compatible with 3.5. > 07:40:20 package: > ovirt-engine-extension-aaa-ldap-setup-1.1.0-0.0.master.20150729115014.git1b0203a.el7.noarch > from check-custom-el7 07:40:20 unresolved deps: 07:40:20 ovirt-engine >= > 0:3.6 07:40:20 otopi >= 0:1.4.0 > Thanks, > -- > 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 ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Ovirt-engine is not starting after rebuild
Hello, In devenv, it is much simpler to use jboss-eap[1], it will work for you for 3.5, master, fc, rhel without any special configuration. Download and extract it to /opt. Just remember to pass --jboss-home=/opt/jboss-eap-xxx every time you run engine-setup. You do not really need to use wildfly, it just makes it more complex as we need to patch it. Regards, Alon [1] http://www.jboss.org/products/eap/download/ - Original Message - > From: "Ramesh Nachimuthu" > To: "Martin Perina" > Cc: devel@ovirt.org > Sent: Thursday, July 23, 2015 2:54:29 PM > Subject: Re: [ovirt-devel] Ovirt-engine is not starting after rebuild > > > > On 07/23/2015 05:14 PM, Martin Perina wrote: > > Hi, > > > > are you sure that you executed all steps as described in [1]? > > If so please attach boot/server/engine logs. > > Yes. To confirm this, when I remove the ~/ovirt-engine folder and drop > the engine database then build and setup it works. > > Regards, > Ramesh > > > Thanks > > > > Martin > > > > > > [1] http://lists.ovirt.org/pipermail/devel/2015-June/010832.html > > > > - Original Message - > >> From: "Ramesh Nachimuthu" > >> To: devel@ovirt.org > >> Sent: Thursday, July 23, 2015 1:34:05 PM > >> Subject: [ovirt-devel] Ovirt-engine is not starting after rebuild > >> > >> Hi, > >> > >> I have a strange issue with dev setup in F22. Engine fails to start after > >> every rebuild. I have to drop the engine database and remove the folder > >> ~/ovirt-engine and do a fresh setup to start the engine. Anyone facing the > >> similar issue. > >> > >> [rnachimu@rnachimu ovirt-engine]$ > >> $HOME/ovirt-engine/share/ovirt-engine/services/ovirt-engine/ovirt-engine.py > >> start > >> OpenJDK 64-Bit Server VM warning: ignoring option PermSize=256m; support > >> was > >> removed in 8.0 > >> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=256m; > >> support > >> was removed in 8.0 > >> Listening for transport dt_socket at address: 8787 > >> [rnachimu@rnachimu ovirt-engine]$ > >> > >> Regards, > >> Ramesh > >> > >> ___ > >> 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
Re: [ovirt-devel] Registration duplication?
- Original Message - > From: "Dan Kenigsberg" > To: "Fabian Deutsch" > Cc: "Alon Bar-Lev" , "Douglas Landgraf" > , devel@ovirt.org > Sent: Thursday, July 23, 2015 1:47:04 PM > Subject: Re: [ovirt-devel] Registration duplication? > > On Wed, Jul 22, 2015 at 04:04:38PM +0200, Fabian Deutsch wrote: > > On Wed, Jul 22, 2015 at 4:59 PM, Douglas Schilling Landgraf > > wrote: > > > On 07/22/2015 09:42 AM, Fabian Deutsch wrote: > > >> > > >> Hey, > > >> > > >> I've seen that some new code landed to support Engine registration > > >> using the generic registration approach. > > >> > > >> But it seem that we now have two implementations: > > >> > > >> 1. vdsm-tool register [0] > > >> 2. ovirt-register [1] > > >> > > >> To reduce code duplication I'd suggest to drop one of these approaches > > >> before we enter 3.6. > > >> Or are there reasons for keeping both of them? > > > > > > I believe not. > > > > Great. > > > > >> My take is to keep ovirt-register which is independent and would allow > > >> us to add plain hosts to Engine (host-deploy is then taking care of > > >> the rest IIUIC). > > >> The vdsm-tool approach reuqires vdsm to be installed. > > >> > > >> Thoughts? > > > > > > > > > +1 for dropping vdsm-tool register verb. It started as alternative and > > > later > > > we merged everything in ovirt-register project which is the generic > > > registration. I can send a patch to drop it soon. > > > > Right. > > So let's see what Dan replies and then we can possibly drop the > > duplicate effort. > > To answer properly, I'll need to know about the current state of > ovirt-register. > > Is ready and available? I know that long ago someone opened complex > RFEs for it, but the implementation never got into fruition. > > I'd like to see vdsm-reg gone, and I'd like to see it gone now. With > vdsm-tool register merged, I don't think there's any remaining effort on > that front (except of removing the dead vdsm-reg code out of vdsm, but > this applies to both). vdsm-reg can be gone only when entire functionality is provided, such as PXE, kernel parameters and service. so a simple hack of vdsm-tool is not the solution. please do not address me as "someone". if you had comments about the design, you should have noted before you took parallel incomplete actions. > > I don't mind at all seeing ovirt-node use ovirt-register instead of > vdsm-tool, and I wouldn't realy care if `vdsm-tool register`'s > implementation is scrapped in favor of calling ovirt-register. > > Dan. > ___ > 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] Registration duplication?
Maybe better is to figure out who requested it to be part of vdsm-tool and why, while there were open bugs to have standalone tool. - Original Message - > From: "Fabian Deutsch" > To: "Douglas Landgraf" , "Dan Kenigsberg" > , "Alon Bar-Lev" > > Cc: devel@ovirt.org > Sent: Wednesday, July 22, 2015 4:42:37 PM > Subject: [ovirt-devel] Registration duplication? > > Hey, > > I've seen that some new code landed to support Engine registration > using the generic registration approach. > > But it seem that we now have two implementations: > > 1. vdsm-tool register [0] > 2. ovirt-register [1] > > To reduce code duplication I'd suggest to drop one of these approaches > before we enter 3.6. > Or are there reasons for keeping both of them? > > My take is to keep ovirt-register which is independent and would allow > us to add plain hosts to Engine (host-deploy is then taking care of > the rest IIUIC). > The vdsm-tool approach reuqires vdsm to be installed. > > Thoughts? > > Greetings > fabian > > --- > [0] https://gerrit.ovirt.org/#/c/40966/ > [1] https://gerrit.ovirt.org/gitweb?p=ovirt-register.git > ___ > 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] How to create FreeIPA user for ovirt engine (engine-manage-domains)?
- Original Message - > From: "David Jaša" > To: devel@ovirt.org > Sent: Wednesday, July 1, 2015 4:49:26 PM > Subject: [ovirt-devel] How to create FreeIPA user for ovirt engine > (engine-manage-domains)? > > Hi, > > Pretty much any documentation around oVirt use of domains uses an > undefined user (engine-manage-domains ... --user=[USER]) and maybe > because of that, virtually all the ovirt tutorials that feature > FreeIPA/IdM use "admin" user of FreeIPA (engine-manage-domains ... > --provider=freeipa --user=admin). This leads to pretty scary situation > of administrator password for your identity management system being > stored for use by another system (ovirt-engine). Please do not use the legacy provider, use the new one. http://wiki.ovirt.org/Features/AAA https://gerrit.ovirt.org/gitweb?p=ovirt-engine-extension-aaa-ldap.git;a=blob;f=README;hb=HEAD > So, the right way to do things should be use of a "service user" for > engine that would have just enough privileges in FreeIPA to work > correctly. So my questions are: > > 1. what are the necessary permissions for such a service user? Perform queries to locate the user details of these that are trying to login. No special permission is required. > 2. how to create such an user? Can it be done throught IPA web UI or > does one need to go through the ldif/ldapmodify route? I have no idea, you should ask IPA people how to create user. Regards, Alon Bar-Lev. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] [ATN][devenv] Please update otopi/ovirt-host-deploy to latest master
Hi, Due to recent additions of serial console, please make sure all devs update otopi/ovirt-host-deploy to latest master snapshot at resources.ovirt.org. Thanks! ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] ovirt can automatically save and load username password?
Greg/Ravi please work this out in the new login form. - Original Message - > From: "Einav Cohen" > To: 395459...@qq.com, "Greg Sheremeta" > Cc: "devel" > Sent: Sunday, June 7, 2015 11:58:51 PM > Subject: Re: [ovirt-devel] ovirt can automatically save and load > usernamepassword? > > Hi, I'm not quite sure if I understood the exact requests here: > > The first one is about remembering the username and password in > the GUI login page(s). > > This can refer to either: > > (a) browser-native username and password remembering (though this > one will not cause an automatic login - just an auto-fill of the > user-name ans password, I believe). > The browser is not offering to remember the user-name and password > field values within the web-admin/user-portal login pages, as opposed > to other web-sites (see e.g. http://i.imgur.com/R4RNQ3d.png). > > @Greg - do we know why the browser doesn't offer to remember the > user-name/password for the oVirt login pages? do we have any reason > to not introduce such remembering to the login pages? > > [not sure how upcoming SSO changes (which include a new SSO login page) > will affect / be affected by that] > > -- or: -- > > (b) application-specific username and password remembering (which > can lead to a fully-automated login - see http://i.imgur.com/rG7nB9P.png) - > this is a feature that should be implemented and designed carefully > (see [1] for some references). > if this feature is important for you - please open an oVirt RFE for that > (again - I am not sure if upcoming SSO changes will affect / be affected > by that). > > The second question [2] seems to be about automating the login process > using a script. > This may be related to [3]. > @Greg - any thoughts? > > > Thanks, > Einav > > > [1] some threads in stackoverflow.com about implementing 'remember me': > - > http://stackoverflow.com/questions/549/the-definitive-guide-to-form-based-website-authentication > [part II] > - > http://stackoverflow.com/questions/244882/what-is-the-best-way-to-implement-remember-me-for-a-website > > [2] translation to English of the second question (by Google Translate): > """ > The second question: > I Arm board, with firefox login to ovirt publish virtual desktop every > time you need to enter a user name and password you, there is no way > to specify a user name and password in the script, then the call firefox > when the parameters passed to it let firefox automatically go landing? > THX > """ > > [3] https://gerrit.ovirt.org/#/c/38017/ > [userportal, webadmin: allow SSO robots to fill in the login form] > this patch ^^^ solved the following BZ: > Bug 1154666 - Unable to authenticate if user is using > http://indeed-id.com/index.html solution for authentication. > [https://bugzilla.redhat.com/show_bug.cgi?id=1154666] > > > > - Original Message - > > From: 395459...@qq.com > > To: "devel" > > Sent: Monday, June 1, 2015 10:54:34 PM > > Subject: [ovirt-devel] ovirt can automatically save and load username > > password? > > > > My ovirt-engine installed on centos with IP 192.168.0.202, > > When i use 192.168.0.202 to login in with user portal,It load me to the > > address https://192.168.0.202/ovirt-engine/userportal/?locale=en_US#login, > > Now i hope the browser(firefox) remember my username and password,so next > > time when i enter the address > > https://192.168.0.202/ovirt-engine/userportal/?locale=en_US#login ,it can > > login automatically. > > > > 第二个疑问： > > 我在Arm板上，用firefox登陆到ovirt发布的虚拟桌面，每次都需要输入用户名、密码吗，有没有办法实现在脚本中指定用户名、密码，然后在调用firefox的时候把参数传递给它，让firefox自动去登陆呢？ > > 谢谢 > > > > 395459...@qq.com > > > > ___ > > 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
Re: [ovirt-devel] why host deploy install packages except for vdsm ?
- Original Message - > From: "Fabian Deutsch" > To: "Alon Bar-Lev" > Cc: tlito...@redhat.com, devel@ovirt.org > Sent: Monday, May 18, 2015 6:57:07 PM > Subject: Re: [ovirt-devel] why host deploy install packages except for vdsm ? > > - Original Message - > > - Original Message - > > > From: "Tolik Litvosky" > > > To: devel@ovirt.org, "Alon Bar-Lev" > > > Sent: Monday, May 18, 2015 5:21:56 PM > > > Subject: [ovirt-devel] why host deploy install packages except for vdsm ? > > > > > > Hi > > > > > > I have noticed that host deploy installs several packages which are not > > > VDSM deps. > > > Its : tuned kexec-tools iptables-services. > > > > > > If VDSM needs them maybe it can pull them in using dependencies? > > > And if not why are they installed. > > > > it is not vdsm that needs them, it is host configuration that we require. > > vdsm can work any tuning of a machine, it does not and should not care how > > you optimize the machine. > > system dump is the same. > > and so firewall. > > Does it make sense to let some component require (in the spec) those > packages? ovirt-host-deploy-offline? ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] why host deploy install packages except for vdsm ?
- Original Message - > From: "Tolik Litvosky" > To: devel@ovirt.org, "Alon Bar-Lev" > Sent: Monday, May 18, 2015 5:21:56 PM > Subject: [ovirt-devel] why host deploy install packages except for vdsm ? > > Hi > > I have noticed that host deploy installs several packages which are not > VDSM deps. > Its : tuned kexec-tools iptables-services. > > If VDSM needs them maybe it can pull them in using dependencies? > And if not why are they installed. it is not vdsm that needs them, it is host configuration that we require. vdsm can work any tuning of a machine, it does not and should not care how you optimize the machine. system dump is the same. and so firewall. Alon ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] [ATN][devenv][master] please update ovirt-host-deploy package
Hello, For these who use devenv to deploy hosts, please update ovirt-host-deploy to latest snapshot[1]. It is required due to some changes in master. If you repo is configure correctly a simple yum update will do the trick. Regards, Alon Bar-Lev. [1] ovirt-host-deploy-1.4.0-0.0.master.20150505210235.giteabc23b ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Hosted-engine installation failed because of time-out (low prio)
- Original Message - > From: "Christopher Pereira" > To: "Alon Bar-Lev" > Cc: devel@ovirt.org > Sent: Wednesday, May 6, 2015 9:49:43 AM > Subject: Re: [ovirt-devel] Hosted-engine installation failed because of > time-out (low prio) > > On 06-05-2015 3:39, Alon Bar-Lev wrote: > > Hi, > > > > What version of ovirt-engine do you use? > Latest night build. > > > > When connection is terminated the sshd on host should kill the process > > group, very strange that a process is keep running on non existence pipe. > This was Gerrit patched with [1], which avoids glusterfs running and > dying inside VDSM's cgroup. > > [1] https://gerrit.ovirt.org/#/c/40240/ this is a different issue, the python process should die when connection is terminated. > > What happen if you retry host-deploy? does the issue happens with specific > > host ar all hosts? > Yes, multiple times. > I finally tried "Activate" and the host works fine. > > I didn't have problems installing and activating a second host (after > adding the required repo). and a third? I would like to know if this is specific to single host, as the last report of these kind of failures were long ago. > BTW, shouldn't the repo be added by the installation process? No, it is sysadmin task to configure the right repo, we cannot guess where it is within enterprise. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Hosted-engine installation failed because of time-out (low prio)
Hi,
What version of ovirt-engine do you use?
When connection is terminated the sshd on host should kill the process group,
very strange that a process is keep running on non existence pipe.
What happen if you retry host-deploy? does the issue happens with specific host
ar all hosts?
Thanks,
Alon
- Original Message -
> From: "Christopher Pereira"
> To: devel@ovirt.org
> Sent: Wednesday, May 6, 2015 6:41:45 AM
> Subject: [ovirt-devel] Hosted-engine installation failed because of time-out
> (low prio)
>
> Hi,
>
> Today a hosted-engine setup timed out during the host installation process.
> We were able to activate the host anyway, so I'm just providing this info in
> case it helps or saves time to anyone.
>
> It looks like the engine was not piping the right input to the otopi deploy
> process.
>
> Engine logs:
>
>
> 2015-05-05 22:47:13,769 INFO
> [org.ovirt.engine.core.bll.hostdeploy.InstallerMessages] (VdsDeploy)
> [a64986b] Installation 'h5.imatronix.com': Enrolling certificate
> 2015-05-05 22:47:13,875 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (VdsDeploy) [a64986b] Correlation ID: a64986b, Call Stack: null, Custom
> Event ID: -1, Message: Installing Host H5. Enrolling certificate.
> 2015-05-05 22:47:15,222 INFO
> [org.ovirt.engine.core.bll.hostdeploy.InstallerMessages] (VdsDeploy)
> [a64986b] Installation 'h5.imatronix.com': Stage: Transaction commit
> 2015-05-05 22:47:15,317 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (VdsDeploy) [a64986b] Correlation ID: a64986b, Call Stack: null, Custom
> Event ID: -1, Message: Installing Host H5. Stage: Transaction commit.
> 2015-05-05 22:47:15,317 INFO
> [org.ovirt.engine.core.bll.hostdeploy.InstallerMessages] (VdsDeploy)
> [a64986b] Installation 'h5.imatronix.com': Stage: Closing up
> 2015-05-05 22:47:15,433 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (VdsDeploy) [a64986b] Correlation ID: a64986b, Call Stack: null, Custom
> Event ID: -1, Message: Installing Host H5. Stage: Closing up.
> 2015-05-05 22:50:34,791 ERROR
> [org.ovirt.engine.core.utils.servlet.ServletUtils] (ajp--127.0.0.1-8702-3)
> [] Can't read file '/usr/share/ovirt-engine/files/spice/SpiceVersion.txt'
> for request '/ovirt-engine/services/files/spice/SpiceVersion.txt', will send
> a 404 error response.
> 2015-05-05 22:50:34,794 INFO
> [org.ovirt.engine.docs.utils.servlet.ContextSensitiveHelpMappingServlet]
> (ajp--127.0.0.1-8702-7) [] Context-sensitive help is not installed. Manual
> directory doesn't exist: /usr/share/ovirt-engine/manual
> 2015-05-05 22:50:39,608 INFO
> [org.ovirt.engine.core.bll.aaa.LoginAdminUserCommand]
> (ajp--127.0.0.1-8702-9) [] Running command: LoginAdminUserCommand internal:
> false.
> 2015-05-05 22:50:39,675 INFO
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
> (ajp--127.0.0.1-8702-9) [] Correlation ID: null, Call Stack: null, Custom
> Event ID: -1, Message: User admin@internal logged in.
>
>
> 2015-05-05 22:56:59,097 ERROR
> [org.ovirt.engine.core.bll.hostdeploy.VdsDeploy] (VdsDeploy) [a64986b] Error
> during deploy dialog: java.io.IOException: Unexpected connection termination
> at
> org.ovirt.otopi.dialog.MachineDialogParser.nextEvent(MachineDialogParser.java:388)
> [otopi.jar:]
> at
> org.ovirt.otopi.dialog.MachineDialogParser.nextEvent(MachineDialogParser.java:405)
> [otopi.jar:]
> at
> org.ovirt.engine.core.bll.hostdeploy.VdsDeploy._threadMain(VdsDeploy.java:841)
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.hostdeploy.VdsDeploy.access$2000(VdsDeploy.java:88)
> [bll.jar:]
> at org.ovirt.engine.core.bll.hostdeploy.VdsDeploy$52.run(VdsDeploy.java:989)
> [bll.jar:]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_79]
>
> 2015-05-05 22:56:59,098 ERROR [org.ovirt.engine.core.uutils.ssh.SSHDialog]
> (org.ovirt.thread.pool-12-thread-3) [a64986b] SSH error running command
> r...@h5.imatronix.com :'umask 0077; MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" mktemp
> -d -t ovirt-XX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null
> 2>&1; rm -fr \"${MYTMP}\" > /dev/null 2>&1" 0; tar --warning=no-timestamp -C
> "${MYTMP}" -x && "${MYTMP}"/setup DIALOG/dialect=str:machine
> DIALOG/customization=bool:True': SSH session timeout host '
> r...@h5.imatronix.com '
> 2015-05-05 22:56:59,099 ERROR [org.ovirt.engine.core.uutils.ssh.SSHDialog]
> (org.ovirt.thread.pool-12-thread-3) [a64986b] Exception:
> javax.naming.TimeLimitExceededException: SSH session timeout host '
> r...@h5.imatronix.com '
> at
> org.ovirt.engine.core.uutils.ssh.SSHClient.executeCommand(SSHClient.java:499)
> [uutils.jar:]
> at
> org.ovirt.engine.core.uutils.ssh.SSHDialog.executeCommand(SSHDialog.java:312)
> [uutils.jar:]
> at
> org.ovirt.engine.core.bll.hostdeploy.VdsDeploy.execute(VdsDeploy.java:1138)
> [bll.jar:]
> at
> org.ovirt.engine.core.bll.hostdeploy.InstallVdsInternalCommand.installHost(InstallVdsInternalCommand.java:168)
> [bll.jar:]
> at
> org.o
Re: [ovirt-devel] [ATTN] yum install python-docker-py to install ovirt-engine
This should be optional like any other optional functionality. - Original Message - > From: "Roy Golan" > To: devel@ovirt.org > Sent: Tuesday, May 5, 2015 2:16:54 PM > Subject: [ovirt-devel] [ATTN] yum install python-docker-py to install > ovirt-engine > > recently a docker integration plugin was merged, which requires docker > python bindings. > > to fix your env dependencies just add it: > > yum install python-docker-py > > wiki[1] updated accordingly and a patch[2] for README.developer is on > the way > > [1] > http://www.ovirt.org/OVirt_Engine_Development_Environment#Install_3rd_party_packages > [2] https://gerrit.ovirt.org/#/c/40532/ > > > ___ > 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] [URGENT][ACTION REQUIRED] ovirt-master-snapshot repository closure broken on EL6
- Original Message - > From: "Sandro Bonazzola" > To: "Alon Bar-Lev" > Cc: "Fabian Deutsch" , devel@ovirt.org, "infra" > > Sent: Wednesday, April 22, 2015 3:07:53 PM > Subject: Re: [URGENT][ACTION REQUIRED] ovirt-master-snapshot repository > closure broken on EL6 > > Il 22/04/2015 13:45, Alon Bar-Lev ha scritto: > > > > > > - Original Message - > >> From: "Sandro Bonazzola" > >> To: "Fabian Deutsch" , "Alon Bar-Lev" > >> , devel@ovirt.org, "infra" > >> > >> Sent: Wednesday, April 22, 2015 2:41:47 PM > >> Subject: [URGENT][ACTION REQUIRED] ovirt-master-snapshot repository > >> closure broken on EL6 > >> > >> starting from commit 7479c7cde296a6bf8b7202f7483e408470e7e58f vdsm is not > >> built and published on el6 for 3.6. > > > > so don't build ovirt-host-deploy-offline as well? > > Can you please push a fix for the job? > The source code is here: git://gerrit.ovirt.org/jenkins > If not, please open a ticket on https://fedorahosted.org/ovirt/ and someone > in infra will pick it up when they'll have capacity. opened: https://fedorahosted.org/ovirt/ticket/315 > > > > >> This is causing repository closure error on the el6 nightly master > >> snapshot > >> branch: > >> > >> 12:28:43 package: > >> ovirt-host-deploy-offline-1.4.0-0.0.master.20150416125617.git15a1979.el6.x86_64 > >> from check-custom-el6 > >> 12:28:43 unresolved deps: > >> 12:28:43 vdsm-cli > >> 12:28:43 vdsm > >> 12:28:43 package: > >> ovirt-host-deploy-offline-1.4.0-0.0.master.20150420081612.git885b99a.el6.x86_64 > >> from check-custom-el6 > >> 12:28:43 unresolved deps: > >> 12:28:43 vdsm-cli > >> 12:28:43 vdsm > >> 12:28:43 package: > >> ovirt-host-deploy-offline-1.4.0-0.0.master.20150420172335.gitca4f58b.el6.x86_64 > >> from check-custom-el6 > >> 12:28:43 unresolved deps: > >> 12:28:43 vdsm-cli > >> 12:28:43 vdsm > >> 12:28:43 package: ovirt-node-plugin-vdsm-0.4.3-0.0.master.el6.noarch from > >> check-custom-el6 > >> 12:28:43 unresolved deps: > >> 12:28:43 vdsm-reg >= 0:4.10.3 > >> 12:28:43 vdsm-hook-ethtool-options > >> 12:28:43 vdsm-gluster > >> > >> Please fix the dependency tree as soon as possible (either by fixing > >> jenkins > >> jobs, dropping vdsm deps, removing the rpms from the publisher job). > >> Thanks, > >> > >> -- > >> Sandro Bonazzola > >> Better technology. Faster innovation. Powered by community collaboration. > >> See how it works at redhat.com > >> > > > -- > 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] [URGENT][ACTION REQUIRED] ovirt-master-snapshot repository closure broken on EL6
- Original Message - > From: "Sandro Bonazzola" > To: "Fabian Deutsch" , "Alon Bar-Lev" > , devel@ovirt.org, "infra" > > Sent: Wednesday, April 22, 2015 2:41:47 PM > Subject: [URGENT][ACTION REQUIRED] ovirt-master-snapshot repository closure > broken on EL6 > > starting from commit 7479c7cde296a6bf8b7202f7483e408470e7e58f vdsm is not > built and published on el6 for 3.6. so don't build ovirt-host-deploy-offline as well? > This is causing repository closure error on the el6 nightly master snapshot > branch: > > 12:28:43 package: > ovirt-host-deploy-offline-1.4.0-0.0.master.20150416125617.git15a1979.el6.x86_64 > from check-custom-el6 > 12:28:43 unresolved deps: > 12:28:43 vdsm-cli > 12:28:43 vdsm > 12:28:43 package: > ovirt-host-deploy-offline-1.4.0-0.0.master.20150420081612.git885b99a.el6.x86_64 > from check-custom-el6 > 12:28:43 unresolved deps: > 12:28:43 vdsm-cli > 12:28:43 vdsm > 12:28:43 package: > ovirt-host-deploy-offline-1.4.0-0.0.master.20150420172335.gitca4f58b.el6.x86_64 > from check-custom-el6 > 12:28:43 unresolved deps: > 12:28:43 vdsm-cli > 12:28:43 vdsm > 12:28:43 package: ovirt-node-plugin-vdsm-0.4.3-0.0.master.el6.noarch from > check-custom-el6 > 12:28:43 unresolved deps: > 12:28:43 vdsm-reg >= 0:4.10.3 > 12:28:43 vdsm-hook-ethtool-options > 12:28:43 vdsm-gluster > > Please fix the dependency tree as soon as possible (either by fixing jenkins > jobs, dropping vdsm deps, removing the rpms from the publisher job). > Thanks, > > -- > 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] Installing host from engine fails (master)
- Original Message -
> From: "Alon Bar-Lev"
> To: "Christopher Pereira"
> Cc: devel@ovirt.org
> Sent: Monday, April 20, 2015 10:47:54 AM
> Subject: Re: [ovirt-devel] Installing host from engine fails (master)
>
>
>
> - Original Message -
> > From: "Christopher Pereira"
> > To: devel@ovirt.org
> > Sent: Monday, April 20, 2015 8:44:02 AM
> > Subject: Re: [ovirt-devel] Installing host from engine fails (master)
> >
> > On 20-04-2015 2:05, Christopher Pereira wrote:
> >
> >
> >
> > On 20-04-2015 0:57, Christopher Pereira wrote:
> >
> >
> > Engine in master is having problems activating a CentOS 7 host.
> > The cause seems to be related with "missing" plugins:
> >
> >
> > 2015-04-20 00:32:20,955 ERROR [org.ovirt.engine.core.bll.InstallerMessages]
> > (VdsDeploy) [50ddd3ed] Installation 'h4.imatronix.com': Internal error:
> > Internal error, plugins set(['otopi', 'setup']) are missing
> >
> > Inside the ovirt-host-deploy.tar that is executed on the host, inside the
> > 'otopi-plugins' directory, I only have two plugins: 'otopi" and
> > 'ovirt-host-deploy'.
> > There is no 'setup' plugin.
> > Maybe it was renamed? Or the tar is missing a symbolic link?
> >
> > Fixed locally with a workarround by patching
> > '/usr/lib/python2.7/site-packages/otopi/context.py'
> >
> > ...
> > needgroups.add('otopi') # always load us
> >
> > # Workarround
> > needgroups.remove('setup')
> > needgroups.add('ovirt-host-deploy')
> > ...
>
> Thanks for report!
>
> I fixed that.
>
> Please reinstall otopi to revert your changes and install this[1]
> ovirt-host-deploy package when job completes or wait for the next snapshot.
>
> Regards,
> Alon
>
> [1]
> http://jenkins.ovirt.org/job/ovirt-host-deploy_3.5_create-rpms-el7-x86_64_merged/19/
hmmm... new job[1]
[1]
http://jenkins.ovirt.org/job/ovirt-host-deploy_master_create-rpms-el7-x86_64_created/53/
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Installing host from engine fails (master)
- Original Message -
> From: "Christopher Pereira"
> To: devel@ovirt.org
> Sent: Monday, April 20, 2015 8:44:02 AM
> Subject: Re: [ovirt-devel] Installing host from engine fails (master)
>
> On 20-04-2015 2:05, Christopher Pereira wrote:
>
>
>
> On 20-04-2015 0:57, Christopher Pereira wrote:
>
>
> Engine in master is having problems activating a CentOS 7 host.
> The cause seems to be related with "missing" plugins:
>
>
> 2015-04-20 00:32:20,955 ERROR [org.ovirt.engine.core.bll.InstallerMessages]
> (VdsDeploy) [50ddd3ed] Installation 'h4.imatronix.com': Internal error:
> Internal error, plugins set(['otopi', 'setup']) are missing
>
> Inside the ovirt-host-deploy.tar that is executed on the host, inside the
> 'otopi-plugins' directory, I only have two plugins: 'otopi" and
> 'ovirt-host-deploy'.
> There is no 'setup' plugin.
> Maybe it was renamed? Or the tar is missing a symbolic link?
>
> Fixed locally with a workarround by patching
> '/usr/lib/python2.7/site-packages/otopi/context.py'
>
> ...
> needgroups.add('otopi') # always load us
>
> # Workarround
> needgroups.remove('setup')
> needgroups.add('ovirt-host-deploy')
> ...
Thanks for report!
I fixed that.
Please reinstall otopi to revert your changes and install this[1]
ovirt-host-deploy package when job completes or wait for the next snapshot.
Regards,
Alon
[1]
http://jenkins.ovirt.org/job/ovirt-host-deploy_3.5_create-rpms-el7-x86_64_merged/19/
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] unboundid-ldapsdk
- Original Message - > From: "Sandro Bonazzola" > To: devel@ovirt.org > Sent: Monday, April 13, 2015 2:26:16 PM > Subject: [ovirt-devel] unboundid-ldapsdk > > Hi, > We are currently building unboundid-ldapsdk from svn. > > The README file within our build job says: > > LDAP Framework for ovirt-engine-extension-aaa-ldap > > NOTE: > Until release of 2.3.7 and util upstream actually > releases source tarballs, we use svn snapshots from > svn at[1] > > [1] http://svn.code.sf.net/p/ldap-sdk/code/trunk > > > but looks like 2.3.7 and 2.3.8 has been already released: > https://docs.ldap.com/ldap-sdk/docs/release-notes.html > > Should we now build from 2.3.8? Who's maintaining the package? they just added a tag for 2.3.8, still refuse to release proper source tarball. we can remain in the current version there is no actual need to bump. but I tested 2.3.8 for sanity and it seems ok, it can be obtained out of svn from tags/2.3.8. Alon ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] Issue with vdsm on EL6 nodes
- Original Message - > From: "ybronhei" > To: "Alon Bar-Lev" , "Dan Kenigsberg" > Cc: us...@ovirt.org, "Oved Ourfalli" , devel@ovirt.org > Sent: Sunday, April 12, 2015 1:56:18 PM > Subject: Re: [ovirt-users] Issue with vdsm on EL6 nodes > > On 04/12/2015 12:17 PM, ybronhei wrote: > > On 04/07/2015 04:45 PM, Alon Bar-Lev wrote: > >> > >> > >> - Original Message - > >>> From: "knarra" > >>> To: "Alon Bar-Lev" > >>> Cc: us...@ovirt.org > >>> Sent: Tuesday, April 7, 2015 3:39:58 PM > >>> Subject: Re: [ovirt-users] Issue with vdsm on EL6 nodes > >>> > >>> On 04/07/2015 05:58 PM, Alon Bar-Lev wrote: > >>>> > >>>> - Original Message - > >>>>> From: "knarra" > >>>>> To: "Alon Bar-Lev" > >>>>> Cc: us...@ovirt.org > >>>>> Sent: Tuesday, April 7, 2015 3:25:07 PM > >>>>> Subject: Re: [ovirt-users] Issue with vdsm on EL6 nodes > >>>>> > >>>>> On 04/07/2015 05:50 PM, Alon Bar-Lev wrote: > >>>>>> - Original Message - > >>>>>>> From: "knarra" > >>>>>>> To: us...@ovirt.org > >>>>>>> Sent: Tuesday, April 7, 2015 3:15:12 PM > >>>>>>> Subject: [ovirt-users] Issue with vdsm on EL6 nodes > >>>>>>> > >>>>>> > >>>>>> > >>>>>>> SSLError: [Errno 1] _ssl.c:1390: error:1409442E:SSL > >>>>>>> routines:SSL3_READ_BYTES:tlsv1 alert protocol version > >>>>>>> > >>>>>>> Can some one help me to resolve this issue. > >>>>>> your openssl is patched to disable ssv3, and engine is trying to > >>>>>> communicate using sslv3. > >>>>>> > >>>>>> please upgrade engine to latest z-stream, it should be resolved. > >>>>> Hi Alon, > >>>>> > >>>>>I checked the following value in my database and my engine > >>>>> is using > >>>>> TLSv1 and not sslv3 to comminucate. I am on 3.6 master branch. > >>>>> > >>>>> engine=# select option_name,option_value from vdc_options where > >>>>> option_name = 'VdsmSSLProtocol'; > >>>>> option_name | option_value > >>>>> -+-- > >>>>> VdsmSSLProtocol | TLSv1 > >>>>> (1 row) > >>>> hmmm and you say you get this when you use vdsClient, so maybe > >>>> it tries > >>>> to connect using sslv3. > >>>> > >>>> is engine working proberly? > >>> yes, engine works fine, i have few other nodes where i have the same > >>> vdsm version added to same engine and i do not hit this issue there. I > >>> am just wondering how is this happening. > >>> > >> > >> compare openssl version. > >> > >> yaniv, please fix the vdsClient to use TLSv1 > >> > > should it use v1 always (forcefully)? we can do that, but currently it > > chooses the highest version both parties are able to use > > > > > Vdsm uses ssl.PROTOCOL_SSLv23 which chooses the right tls version in > python 2.7. In el6 we have python 2.6 which picks sslv2 or sslv3 when > using ssl.PROTOCOL_SSLv23 (the highest version both sides support) - > > ovirt 3.6 (vdsm 4.17 and above) doesn't support el6 anymore therefore > current 3.6 code works as expected in el7\fedora>20. > > If we want to fix vdsm 4.16.x (ovirt 3.5 package) to use explicitly > ssl.PROTOCOL_TLSv1 we can do so - but it will be ovirt-3.5 branch only > > do we want that? if so we need bug for 3.5 as far as I understand the ssl.PROTOCOL_SSLv23 will also use TLSv1, the problem is at client side not at server side. Alon ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [vdsm] vdsm hosts clock sync
- Original Message - > From: "Shahar Havivi" > To: "Alon Bar-Lev" > Cc: vdsm-de...@lists.fedorahosted.org > Sent: Monday, April 6, 2015 3:05:20 PM > Subject: Re: [vdsm] vdsm hosts clock sync > > On 06.04.15 08:00, Alon Bar-Lev wrote: > > > > > > - Original Message - > > > From: "Shahar Havivi" > > > To: "Alon Bar-Lev" > > > Cc: vdsm-de...@lists.fedorahosted.org > > > Sent: Monday, April 6, 2015 2:54:07 PM > > > Subject: Re: [vdsm] vdsm hosts clock sync > > > > > > On 06.04.15 07:50, Alon Bar-Lev wrote: > > > > > > > > > > > > - Original Message - > > > > > From: "Shahar Havivi" > > > > > To: vdsm-de...@lists.fedorahosted.org > > > > > Sent: Monday, April 6, 2015 2:44:06 PM > > > > > Subject: [vdsm] vdsm hosts clock sync > > > > > > > > > > Hi, > > > > > > > > > > I want to add a new feature that reports migration actual downtime > > > > > (the > > > > > time > > > > > that the VM was inaccessible to the user). > > > > > > > > > > Libvirt reports that information but the vdsm hosts need to be in > > > > > sync by > > > > > clock > > > > > time. > > > > > I can measure the ping for NTP server an report back to the user if > > > > > the > > > > > ping > > > > > is too long (more then ~100ms or so) - a way to do that is via > > > > > ntpstat > > > > > shell > > > > > command. > > > > > The NTP delay can be report back via vdsStats and can be performed > > > > > every > > > > > few hours or so. > > > > > > > > > > Anyone knows of a better way that we can sync between hosts? > > > > > > > > I am unsure how a ping to clock source is helping, can you please > > > > explain > > > > more? > > > In this case I can only report back to the user that its hosts clock is > > > delayed and need to be set... > > > > > > > > If you assume clocks are synced why anything more is needed? > > > Why do I assume that? > > > > > > > > Or would you like to have a solution in which you do not require clock > > > > sync? > > > > > > I do need the clock to be in sync - if not libvirts "actual downtime > > > migration" will be not accurate. > > > > you do not need clock to sync, you need to know the delta between hosts. > > > > but if you assume clock are in sync so what is the actual question? > > As I understand from your answer is by having configured ntp the hosts clock > are in sync. I do not follow. 1. if you are using ntpd on hosts and hosts are in sync you can use distributed timestamps. detecting if host is synced can be done using either (based on what actually installed): ntpq -c rv | grep -q clock_sync && echo ok chronyc waitsync 1 && echo ok 2. you can also measure the time diff between hosts by clockdiff or similar process and avoid the need of ntpd deployed. 3. you may be able to calculate the time within in the handover is given to remote and eliminate the network time. Not sure what your implementation is. Alon ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] el6 future in ovirt-3.6
- Original Message - > From: "Itamar Heim" > To: "Alon Bar-Lev" > Cc: "Sahina Bose" , "Dan Kenigsberg" , > devel@ovirt.org > Sent: Tuesday, March 17, 2015 12:10:46 AM > Subject: Re: [ovirt-devel] el6 future in ovirt-3.6 > > On 03/17/2015 12:01 AM, Alon Bar-Lev wrote: > > > > > > - Original Message - > >> From: "Itamar Heim" > >> To: "Alon Bar-Lev" > >> Cc: "Sahina Bose" , "Dan Kenigsberg" > >> , devel@ovirt.org > >> Sent: Monday, March 16, 2015 11:55:05 PM > >> Subject: Re: [ovirt-devel] el6 future in ovirt-3.6 > >> > >> On 03/16/2015 11:48 PM, Alon Bar-Lev wrote: > >>> > >>> > >>> - Original Message - > >>>> From: "Itamar Heim" > >>>> To: "Sahina Bose" , "Dan Kenigsberg" > >>>> , devel@ovirt.org > >>>> Sent: Monday, March 16, 2015 11:41:36 PM > >>>> Subject: Re: [ovirt-devel] el6 future in ovirt-3.6 > >>>> > >>>> On 03/16/2015 06:02 PM, Sahina Bose wrote: > >>>>> > >>>>> On 03/16/2015 03:28 PM, Dan Kenigsberg wrote: > >>>>>> Current master branch of vdsm (destined for our 3.6 release) uses el7 > >>>>>> as > >>>>>> its main platform. New features are expected to be available only on > >>>>>> el7 > >>>>>> (and modern Fedoras) but not on el6. > >>>>>> > >>>>>> On el6, vdsm still builds, runs, and exports clusterLevel <= 3.5, with > >>>>>> no feature loss relative to 3.5. This has been done per gluster > >>>>>> request. > >>>>>> > >>>>>> However, maintaining this furhter as high costs: we keep testing el6, > >>>>>> we > >>>>>> need to make sure nothing breaks there, and there's a lot of legacy > >>>>>> code > >>>>>> that we could start deleting. > >>>>>> > >>>>>> Sahina, would you explain (again... sorry for not recalling the > >>>>>> details) > >>>>>> why ovirt-3.6's vdsm should keep running on el6? I'd like to see if > >>>>>> there's a nother means to solve the underlying gluster issue. > >>>>> > >>>>> This was only because downstream gluster + vdsm would continue to be > >>>>> supported on RHEL 6. > >>>> > >>>> is there an expected date at which new features would be .el7 only, so > >>>> .el6 support can be dropped upstream? > >>> > >>> there is no reason to drop anything from upstream if it is to be > >>> supported. > >>> it will only create overhead for product support. we have long on going > >>> effort is to reduce diff while you keep pushing for fork. it always > >>> turned > >>> out to be incorrect decision. please learn from experience. > >> > >> I asked when they plan to drop support, so we can drop unneeded code. > > > > I do not understand. unneeded code from where? you wrote "upstream" which > > suggest you keep it "downstream". > > Had you written from "product" / "vdsm" I would not have responded. > > > > vdsm master (aka 3.6) should work or should not work on el6? > > [downstream/upstream/customized] > > should work, for gluster > > > does it mean that 3.6 cluster level will not be supported at el6? > > for virt side, yes. > > > does it mean that 3.5 will be supported long cycle for el6 to bridge the > > gap for these who do not upgrade to el7? no new features for el6 (z-stream > > only)? > > yes, that's the plan - no new features for the virt side for .el6. > my question was when this would be true for the gluster side. I cannot understand these conflicting statements. if any component of vdsm needs to run on el6, el6 support cannot be dropped, this [among other] includes python version and other infra modules, packaging included. a possible sensible solution is to continue maintaining 3.5 for gluster on el6 with possibly new features, and have master free of el6 for all dependencies. dropping el6 from 3.6 should have been early in development cycle to allow proper testing. the gluster issue should have resolved even before the 3.6 cycle. > > > > >> > >>> > >>>> > >>>>> > >>>>>> > >>>>>> Regards, > >>>>>> Dan. > >>>>> > >>>>> ___ > >>>>> 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
Re: [ovirt-devel] el6 future in ovirt-3.6
- Original Message - > From: "Itamar Heim" > To: "Alon Bar-Lev" > Cc: "Sahina Bose" , "Dan Kenigsberg" , > devel@ovirt.org > Sent: Monday, March 16, 2015 11:55:05 PM > Subject: Re: [ovirt-devel] el6 future in ovirt-3.6 > > On 03/16/2015 11:48 PM, Alon Bar-Lev wrote: > > > > > > - Original Message - > >> From: "Itamar Heim" > >> To: "Sahina Bose" , "Dan Kenigsberg" > >> , devel@ovirt.org > >> Sent: Monday, March 16, 2015 11:41:36 PM > >> Subject: Re: [ovirt-devel] el6 future in ovirt-3.6 > >> > >> On 03/16/2015 06:02 PM, Sahina Bose wrote: > >>> > >>> On 03/16/2015 03:28 PM, Dan Kenigsberg wrote: > >>>> Current master branch of vdsm (destined for our 3.6 release) uses el7 as > >>>> its main platform. New features are expected to be available only on el7 > >>>> (and modern Fedoras) but not on el6. > >>>> > >>>> On el6, vdsm still builds, runs, and exports clusterLevel <= 3.5, with > >>>> no feature loss relative to 3.5. This has been done per gluster request. > >>>> > >>>> However, maintaining this furhter as high costs: we keep testing el6, we > >>>> need to make sure nothing breaks there, and there's a lot of legacy code > >>>> that we could start deleting. > >>>> > >>>> Sahina, would you explain (again... sorry for not recalling the details) > >>>> why ovirt-3.6's vdsm should keep running on el6? I'd like to see if > >>>> there's a nother means to solve the underlying gluster issue. > >>> > >>> This was only because downstream gluster + vdsm would continue to be > >>> supported on RHEL 6. > >> > >> is there an expected date at which new features would be .el7 only, so > >> .el6 support can be dropped upstream? > > > > there is no reason to drop anything from upstream if it is to be supported. > > it will only create overhead for product support. we have long on going > > effort is to reduce diff while you keep pushing for fork. it always turned > > out to be incorrect decision. please learn from experience. > > I asked when they plan to drop support, so we can drop unneeded code. I do not understand. unneeded code from where? you wrote "upstream" which suggest you keep it "downstream". Had you written from "product" / "vdsm" I would not have responded. vdsm master (aka 3.6) should work or should not work on el6? [downstream/upstream/customized] does it mean that 3.6 cluster level will not be supported at el6? does it mean that 3.5 will be supported long cycle for el6 to bridge the gap for these who do not upgrade to el7? no new features for el6 (z-stream only)? > > > > >> > >>> > >>>> > >>>> Regards, > >>>> Dan. > >>> > >>> ___ > >>> 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
Re: [ovirt-devel] el6 future in ovirt-3.6
- Original Message - > From: "Itamar Heim" > To: "Sahina Bose" , "Dan Kenigsberg" , > devel@ovirt.org > Sent: Monday, March 16, 2015 11:41:36 PM > Subject: Re: [ovirt-devel] el6 future in ovirt-3.6 > > On 03/16/2015 06:02 PM, Sahina Bose wrote: > > > > On 03/16/2015 03:28 PM, Dan Kenigsberg wrote: > >> Current master branch of vdsm (destined for our 3.6 release) uses el7 as > >> its main platform. New features are expected to be available only on el7 > >> (and modern Fedoras) but not on el6. > >> > >> On el6, vdsm still builds, runs, and exports clusterLevel <= 3.5, with > >> no feature loss relative to 3.5. This has been done per gluster request. > >> > >> However, maintaining this furhter as high costs: we keep testing el6, we > >> need to make sure nothing breaks there, and there's a lot of legacy code > >> that we could start deleting. > >> > >> Sahina, would you explain (again... sorry for not recalling the details) > >> why ovirt-3.6's vdsm should keep running on el6? I'd like to see if > >> there's a nother means to solve the underlying gluster issue. > > > > This was only because downstream gluster + vdsm would continue to be > > supported on RHEL 6. > > is there an expected date at which new features would be .el7 only, so > .el6 support can be dropped upstream? there is no reason to drop anything from upstream if it is to be supported. it will only create overhead for product support. we have long on going effort is to reduce diff while you keep pushing for fork. it always turned out to be incorrect decision. please learn from experience. > > > > >> > >> Regards, > >> Dan. > > > > ___ > > 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
Re: [ovirt-devel] [ACTION REQUIRED] Packages for 3.5.2 RC1
- Original Message - > From: "Sandro Bonazzola" > To: "Alon Bar-Lev" > Cc: devel@ovirt.org, "David Caro" , "Max Kovgan" > , "Shirly Radco" > , "Martin Sivak" , "Roy Golan" > , "Saggi Mizrahi" > , "Piotr Kliczewski" , "Dan > Kenigsberg" , "Yaniv > Bronheim" > Sent: Monday, March 2, 2015 9:23:02 AM > Subject: Re: [ACTION REQUIRED] Packages for 3.5.2 RC1 > > Il 01/03/2015 14:32, Alon Bar-Lev ha scritto: > > > > > > - Original Message - > >> From: "Sandro Bonazzola" > >> To: devel@ovirt.org, "David Caro" , "Max Kovgan" > >> , "Alon Bar-Lev" > >> , "Shirly Radco" , "Martin Sivak" > >> , "Roy Golan" > >> , "Saggi Mizrahi" , "Piotr > >> Kliczewski" , "Dan > >> Kenigsberg" , "Yaniv Bronheim" > >> Sent: Thursday, February 26, 2015 6:27:42 PM > >> Subject: [ACTION REQUIRED] Packages for 3.5.2 RC1 > >> > >> # All remaining projects will be taken from nightly publisher: > > > > not sure why we are still synchronizing packages z-stream with engine > > cycle, these satellite packages can be released at any time, this is the > > main reason that they are packaged separately. > > > >> http://jenkins.ovirt.org/job/otopi_1.3_create-rpms_merged/label=el6/3/ > >> http://jenkins.ovirt.org/job/otopi_1.3_create-rpms_merged/label=el7/3/ > >> http://jenkins.ovirt.org/job/otopi_1.3_create-rpms_merged/label=fc20/3/ > >> http://jenkins.ovirt.org/job/otopi_1.3_create-rpms_merged/label=fc21/3/ > > > > I will release z-stream soon. > > > >> http://jenkins.ovirt.org/job/unboundid-ldapsdk_master_create-rpms-el6-x86_64_merged/1/ > >> http://jenkins.ovirt.org/job/unboundid-ldapsdk_master_create-rpms-el7-x86_64_merged/1/ > >> http://jenkins.ovirt.org/job/unboundid-ldapsdk_master_create-rpms-fc20-x86_64_merged/1/ > > > > not changed, please take the stable branch. > > > >> http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_master_create-rpms-el6-x86_64_merged/107/ > >> http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_master_create-rpms-el7-x86_64_merged/48/ > >> http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_master_create-rpms-fc20-x86_64_merged/108/ > > > > please take the stable branch, I will or will not release a new z-stream in > > next few days. > > > >> http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-misc_master_create-rpms-el6-x86_64_merged/12/ > >> http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-misc_master_create-rpms-el7-x86_64_merged/8/ > >> http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-misc_master_create-rpms-fc20-x86_64_merged/11/ > > > > please take the stable branch. > > > >> http://jenkins.ovirt.org/job/ovirt-engine-extension-logger-log4j_master_create-rpms-el6-x86_64_merged/16/ > >> http://jenkins.ovirt.org/job/ovirt-engine-extension-logger-log4j_master_create-rpms-el7-x86_64_merged/8/ > >> http://jenkins.ovirt.org/job/ovirt-engine-extension-logger-log4j_master_create-rpms-fc20-x86_64_merged/16/ > > > > this I will build soon to be included, as the fedora issue was resolved. http://jenkins.ovirt.org/job/ovirt-engine-extension-logger-log4j_any_create-rpms_manual/8/ > > > > Thanks, > > Alon > > > > Done > > > -- > 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] [ACTION REQUIRED] Packages for 3.5.2 RC1
- Original Message - > From: "Sandro Bonazzola" > To: devel@ovirt.org, "David Caro" , "Max Kovgan" > , "Alon Bar-Lev" > , "Shirly Radco" , "Martin Sivak" > , "Roy Golan" > , "Saggi Mizrahi" , "Piotr > Kliczewski" , "Dan > Kenigsberg" , "Yaniv Bronheim" > Sent: Thursday, February 26, 2015 6:27:42 PM > Subject: [ACTION REQUIRED] Packages for 3.5.2 RC1 > > # All remaining projects will be taken from nightly publisher: not sure why we are still synchronizing packages z-stream with engine cycle, these satellite packages can be released at any time, this is the main reason that they are packaged separately. > http://jenkins.ovirt.org/job/otopi_1.3_create-rpms_merged/label=el6/3/ > http://jenkins.ovirt.org/job/otopi_1.3_create-rpms_merged/label=el7/3/ > http://jenkins.ovirt.org/job/otopi_1.3_create-rpms_merged/label=fc20/3/ > http://jenkins.ovirt.org/job/otopi_1.3_create-rpms_merged/label=fc21/3/ I will release z-stream soon. > http://jenkins.ovirt.org/job/unboundid-ldapsdk_master_create-rpms-el6-x86_64_merged/1/ > http://jenkins.ovirt.org/job/unboundid-ldapsdk_master_create-rpms-el7-x86_64_merged/1/ > http://jenkins.ovirt.org/job/unboundid-ldapsdk_master_create-rpms-fc20-x86_64_merged/1/ not changed, please take the stable branch. > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_master_create-rpms-el6-x86_64_merged/107/ > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_master_create-rpms-el7-x86_64_merged/48/ > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_master_create-rpms-fc20-x86_64_merged/108/ please take the stable branch, I will or will not release a new z-stream in next few days. > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-misc_master_create-rpms-el6-x86_64_merged/12/ > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-misc_master_create-rpms-el7-x86_64_merged/8/ > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-misc_master_create-rpms-fc20-x86_64_merged/11/ please take the stable branch. > http://jenkins.ovirt.org/job/ovirt-engine-extension-logger-log4j_master_create-rpms-el6-x86_64_merged/16/ > http://jenkins.ovirt.org/job/ovirt-engine-extension-logger-log4j_master_create-rpms-el7-x86_64_merged/8/ > http://jenkins.ovirt.org/job/ovirt-engine-extension-logger-log4j_master_create-rpms-fc20-x86_64_merged/16/ this I will build soon to be included, as the fedora issue was resolved. Thanks, Alon ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Packages for oVirt 3.5.1 RC
- Original Message - > From: "Sandro Bonazzola" > To: "Alon Bar-Lev" > Cc: devel@ovirt.org, "David Caro" , "Barak Korren" > , "Eyal Edri" > > Sent: Thursday, January 15, 2015 11:38:27 AM > Subject: Re: Packages for oVirt 3.5.1 RC > > Il 15/01/2015 10:29, Alon Bar-Lev ha scritto: > > > > > > - Original Message - > >> From: "Sandro Bonazzola" > >> To: devel@ovirt.org, "David Caro" , "Juan Hernandez" > >> , "Shirly Radco" > >> , "Alon Bar-Lev" , "Yaniv Bronheim" > >> , "Dan Kenigsberg" > >> , "Piotr Kliczewski" , "Saggi > >> Mizrahi" , "Lev Veyde" > >> , "Martin Sivak" , "Yaniv Dary" > >> , "Federico Simoncelli" > >> , "Michal Skrivanek" , "Allon > >> Mureinik" , "Alexander > >> Wels" , "Einav Cohen" , "Lior Vernia" > >> , "Barak Korren" > >> , "Eyal Edri" > >> Sent: Thursday, January 15, 2015 11:14:39 AM > >> Subject: Packages for oVirt 3.5.1 RC > >> > >> Hi, > >> We're going to compose 3.5.1 RC with the following packages. > >> ACTION: please review the list and raise any change you need ASAP. > > > > how much time from rc to release? > > RC should go out today, GA is scheduled for next week, 2015-01-21 > see http://www.ovirt.org/OVirt_3.5.z_Release_Management > > > > > > >> #ovirt-engine-extension-aaa-ldap > >> http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_any_create-rpms_manual/9/ARCH=x86_64,DISTRIBUTION=fedora-20/ > >> http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_any_create-rpms_manual/9/ARCH=x86_64,DISTRIBUTION=epel-6/ > >> http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_any_create-rpms_manual/9/ARCH=x86_64,DISTRIBUTION=epel-7/ > > > > we need fc21, no? > > we should keep the 1.0.1 release we already have, I cannot find artifacts > > in any of the past job. > > maybe I will release 1.0.2 for that release. > > but please do not distribute snapshots for this package. > > Above are not snapshot, are the last release build. manual builds are also some tarballs that used for testing. latest is not latest release... > fc21 is not targeted to 3.5.1. We don't have it working on master yet. > VDSM team is releasing vdsm packages for F21 since the host side should be > fine. > In 3.5.0 we didn't have el7. In 3.5.1 we have it. > I can discard the other builds and just add the el7 one then. I think we keep only latest artifacts instead of keeping all? anyway 1.0.2 is available. http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_any_create-rpms_manual/11/ > > > > > >> # ovirt-engine-extension-aaa-misc > >> http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-misc_any_create-rpms_manual/2/ARCH=x86_64,DISTRIBUTION=fedora-20/ > >> http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-misc_any_create-rpms_manual/2/ARCH=x86_64,DISTRIBUTION=epel-6/ > >> http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-misc_any_create-rpms_manual/2/ARCH=x86_64,DISTRIBUTION=epel-7/ > > > > we need fc21, no? > > if not, just leave what we have in 3.5. > > > I can discard the other builds and just add the el7 one then. in this case yes, no lost artifacts. > > > > > >> # ovirt-engine-extension-logger-log4j > >> http://jenkins.ovirt.org/job/ovirt-engine-extension-logger-log4j_any_create-rpms_manual/ARCH=x86_64,DISTRIBUTION=fedora-20/ > >> http://jenkins.ovirt.org/job/ovirt-engine-extension-logger-log4j_any_create-rpms_manual/ARCH=x86_64,DISTRIBUTION=epel-6/ > >> http://jenkins.ovirt.org/job/ovirt-engine-extension-logger-log4j_any_create-rpms_manual/ARCH=x86_64,DISTRIBUTION=epel-7/ > > > > same. also in this case take only el7. > > > > # otopi > > > > I will release today 1.3.1. > > Ok, ping me when ready http://jenkins.ovirt.org/job/otopi_any_create-rpms_manual/15/ > > > > > >> # oVirt Host Deploy > >> http://jenkins.ovirt.org/job/ovirt-host-deploy_any_create-rpms_manual/20/ARCH=x86_64,DISTRIBUTION=fedora-20/ > >> http://jenkins.ovirt.org/job/ovirt-host-deploy_any_create-rpms_manual/20/ARCH=x86_64,DISTRIBUTION=epel-6/ > >> http://jenkins.ovirt.org/job/ovirt-host-deploy_any_create-rpms_manual/20/ARCH=x86_64,DISTRIBUTION=epel-7/ > > > > leave what we have in repo, maybe I will releas
Re: [ovirt-devel] Packages for oVirt 3.5.1 RC
- Original Message - > From: "Sandro Bonazzola" > To: devel@ovirt.org, "David Caro" , "Juan Hernandez" > , "Shirly Radco" > , "Alon Bar-Lev" , "Yaniv Bronheim" > , "Dan Kenigsberg" > , "Piotr Kliczewski" , "Saggi > Mizrahi" , "Lev Veyde" > , "Martin Sivak" , "Yaniv Dary" > , "Federico Simoncelli" > , "Michal Skrivanek" , "Allon > Mureinik" , "Alexander > Wels" , "Einav Cohen" , "Lior Vernia" > , "Barak Korren" > , "Eyal Edri" > Sent: Thursday, January 15, 2015 11:14:39 AM > Subject: Packages for oVirt 3.5.1 RC > > Hi, > We're going to compose 3.5.1 RC with the following packages. > ACTION: please review the list and raise any change you need ASAP. how much time from rc to release? > #ovirt-engine-extension-aaa-ldap > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_any_create-rpms_manual/9/ARCH=x86_64,DISTRIBUTION=fedora-20/ > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_any_create-rpms_manual/9/ARCH=x86_64,DISTRIBUTION=epel-6/ > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_any_create-rpms_manual/9/ARCH=x86_64,DISTRIBUTION=epel-7/ we need fc21, no? we should keep the 1.0.1 release we already have, I cannot find artifacts in any of the past job. maybe I will release 1.0.2 for that release. but please do not distribute snapshots for this package. > # ovirt-engine-extension-aaa-misc > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-misc_any_create-rpms_manual/2/ARCH=x86_64,DISTRIBUTION=fedora-20/ > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-misc_any_create-rpms_manual/2/ARCH=x86_64,DISTRIBUTION=epel-6/ > http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-misc_any_create-rpms_manual/2/ARCH=x86_64,DISTRIBUTION=epel-7/ we need fc21, no? if not, just leave what we have in 3.5. > # ovirt-engine-extension-logger-log4j > http://jenkins.ovirt.org/job/ovirt-engine-extension-logger-log4j_any_create-rpms_manual/ARCH=x86_64,DISTRIBUTION=fedora-20/ > http://jenkins.ovirt.org/job/ovirt-engine-extension-logger-log4j_any_create-rpms_manual/ARCH=x86_64,DISTRIBUTION=epel-6/ > http://jenkins.ovirt.org/job/ovirt-engine-extension-logger-log4j_any_create-rpms_manual/ARCH=x86_64,DISTRIBUTION=epel-7/ same. # otopi I will release today 1.3.1. > # oVirt Host Deploy > http://jenkins.ovirt.org/job/ovirt-host-deploy_any_create-rpms_manual/20/ARCH=x86_64,DISTRIBUTION=fedora-20/ > http://jenkins.ovirt.org/job/ovirt-host-deploy_any_create-rpms_manual/20/ARCH=x86_64,DISTRIBUTION=epel-6/ > http://jenkins.ovirt.org/job/ovirt-host-deploy_any_create-rpms_manual/20/ARCH=x86_64,DISTRIBUTION=epel-7/ leave what we have in repo, maybe I will release today 1.3.1. > #unboundid-ldapsdk > http://jenkins.ovirt.org/job/unboundid-ldapsdk_master_create-rpms-el6-x86_64_merged/1/ > http://jenkins.ovirt.org/job/unboundid-ldapsdk_master_create-rpms-el7-x86_64_merged/1/ > http://jenkins.ovirt.org/job/unboundid-ldapsdk_master_create-rpms-fc20-x86_64_merged/1/ leave what we have in repo. thanks! ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Adding support for 3.6 in engine database
- Original Message - > From: "Oved Ourfali" > To: "Dan Kenigsberg" > Cc: "engine-de...@ovirt.org" > Sent: Wednesday, January 14, 2015 5:19:03 PM > Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database > > > > - Original Message - > > From: "Dan Kenigsberg" > > To: "Oved Ourfali" > > Cc: "engine-de...@ovirt.org" > > Sent: Wednesday, January 14, 2015 5:03:12 PM > > Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database > > > > On Wed, Jan 14, 2015 at 08:19:00AM -0500, Oved Ourfali wrote: > > > > > > > > > - Original Message - > > > > From: "Dan Kenigsberg" > > > > To: "Oved Ourfali" , fsimo...@redhat.com > > > > Cc: "engine-de...@ovirt.org" > > > > Sent: Wednesday, January 14, 2015 3:15:02 PM > > > > Subject: Re: [ovirt-devel] Adding support for 3.6 in engine database > > > > > > > > On Thu, Jan 08, 2015 at 08:46:09AM -0500, Oved Ourfali wrote: > > > > > > > > > > > > > > > - Original Message - > > > > > > From: "Eli Mesika" > > > > > > To: "Lior Vernia" , "Oved Ourfali" > > > > > > > > > > > > Cc: "engine-de...@ovirt.org" , "Dan Kenigsberg" > > > > > > , "Yaniv Bronheim" > > > > > > > > > > > > Sent: Thursday, January 8, 2015 3:41:31 PM > > > > > > Subject: Re: [ovirt-devel] Adding support for 3.6 in engine > > > > > > database > > > > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > From: "Lior Vernia" > > > > > > > To: "Eli Mesika" > > > > > > > Cc: "engine-de...@ovirt.org" , "Dan Kenigsberg" > > > > > > > , "Yaniv Bronheim" > > > > > > > > > > > > > > Sent: Thursday, January 8, 2015 3:08:24 PM > > > > > > > Subject: Re: [ovirt-devel] Adding support for 3.6 in engine > > > > > > > database > > > > > > > > > > > > > > Tried to work with it, and noticed that: > > > > > > > 1. The engine doesn't list 4.17 as a supported vdsm version. > > > > > > > 2. 4.17 vdsm doesn't report 3.6 as a supported engine version. > > > > > > > > > > > > > > This basically means that no host could be operational in a 3.6 > > > > > > > cluster, > > > > > > > as to my understanding 4.17 is exactly the version supporting 3.6 > > > > > > > functionality. > > > > > > > > > > > > > > May I send a fix for (1), or is there any argument against? And > > > > > > > who > > > > > > > could take care of (2)? > > > > > > > > > > > > I had understood deom Oved that this is 4.16 see patch > > > > > > http://gerrit.ovirt.org/#/c/36511/ > > > > > > Oved ??? > > > > > > > > > > > > > > > > I don't know when we should add 4.17. I remember there is some > > > > > "policy" > > > > > for > > > > > that. > > > > > Dan? > > > > > > > > Yes, there is. > > > > > > > > Vdsm would like to declare its support of clusterLevel 3.6 only when it > > > > actually does. This is not yet the case, as we are not yet in 3.6 > > > > feature freeze (heck, we're not yet in feature definition). > > > > > > > > To test cluster level 3.6 on the master branch, someone has to "lie". > > > > > > > > It may be Vdsm (by claiming that it supports 3.6 while it does > > > > not) or Engine (by allowing vdsm 4.17 into cluster 3.6, even though it > > > > does not). > > > > > > > > I prefer the latter, as the Engine-side hack is eaiser to undo on a > > > > distributed system. If today's Vdsm claims that it already support 3.6, > > > > future Engines would add it to their cluster, only to find that random > > > > APIs fails. If the hack is Engine-side, it would be gone when 3.6 > > > > reaches feature freeze. > > > > > > > > > > We don't have a mechanism to "allow" specific version of VDSM to a > > > specific > > > cluster level. > > > For this we only rely on the reported supported cluster levels. > > > > I know. I'm asking Engine to add it. > > The logic in the engine is complex and confusing enough, without adding any > other configuration to it, so I prefer to leave it as is. > I don't see why we can't add the cluster levels to the supported VDSM cluster > levels, as we didn't release any official VDSM version yet, so what's the > issue with that? > The fact that engine master has 3.6 cluster level doesn't mean it is > supported either. It will be once 3.6 is released. this is old discussion... if master work toward a release or version is determine near release. there are two policies in our project, one for vdsm - determine versions near release, and the other is to all other components which is working toward a release. I believe that working toward a release is a better approach especially when components are a coupled. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] engine.ear fails on current ovirt-3.5 branch
- Original Message - > From: "Adam Litke" > To: devel@ovirt.org > Cc: "Alon Bar-Lev" > Sent: Thursday, January 8, 2015 5:35:20 PM > Subject: Re: [ovirt-devel] engine.ear fails on current ovirt-3.5 branch > > On 07/01/15 16:43 -0500, Adam Litke wrote: > >Hi all, > > > >Back from a long vacation I decided to build a fresh engine from the > >tip of the ovirt-3.5 branch (447ff7) and to my dismay, the deployed > >build will not start within jboss. The following error seems of > >paramount importance (full log attached). Can anyone help me figure > >out what is going on? > > Alon and Yair: git blame tells me that you guys are responsible for > the api-extensions code. It looks like my build is missing the > definition of Base.ContextKeys.CONFIGURATION_FILE even though I see it > defined in my source. Could you please give me a hand to figure out > what might be going on. Is anyone else using the 3.5 branch in > development mode or is everyone consuming the rpm build? This is part of the source code, I suggest that you clean ~/.m2/repository and/or execute git clean -dxf to clean all non git files at your working copy. > > > > >2015-01-07 16:36:34,558 ERROR [org.jboss.msc.service.fail] (MSC service > >thread 1-7) MSC1: Failed to start service > >jboss.deployment.subunit."engine.ear"."bll.jar".component.Backend.START: > >org.jboss.msc.service.StartException in service > >jboss.deployment.subunit."engine.ear"."bll.jar".component.Backend.START: > >Failed to start service > > at > > > > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1767) > > [jboss-msc-1.0.2.GA.jar:1.0.2.GA] > > at > > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > > [rt.jar:1.7.0_71] > > at > > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > > [rt.jar:1.7.0_71] > > at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_71] > >Caused by: java.lang.IllegalStateException: JBAS011048: Failed to construct > >component instance > > at > > > > org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:163) > > at > > > > org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:85) > > at > > > > org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:116) > > at > > > > org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:130) > > at > > > > org.jboss.as.ee.component.ComponentStartService.start(ComponentStartService.java:44) > > at > > > > org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1811) > > [jboss-msc-1.0.2.GA.jar:1.0.2.GA] > > at > > > > org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1746) > > [jboss-msc-1.0.2.GA.jar:1.0.2.GA] > > ... 3 more > >Caused by: javax.ejb.EJBException: Unexpected Error > > at > > > > org.jboss.as.ejb3.tx.CMTTxInterceptor.handleExceptionInOurTx(CMTTxInterceptor.java:163) > > at > > > > org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:230) > > at > > > > org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:333) > > at > > > > org.jboss.as.ejb3.tx.SingletonLifecycleCMTTxInterceptor.processInvocation(SingletonLifecycleCMTTxInterceptor.java:56) > > at > > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > > at > > > > org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > > at > > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > > at > > > > org.jboss.as.ee.component.TCCLInterceptor.processInvocation(TCCLInterceptor.java:45) > > at > > > > org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:288) > > [jboss-invocation-1.1.1.Final.jar:1.1.1.Final] > > at
Re: [ovirt-devel] UI Plugin to Upload ISO Files
- Original Message - > From: "Itamar Heim" > To: "Tony James" > Cc: "Nir Soffer" , "Liron Aravot" , > devel@ovirt.org, "Alon Bar-Lev" > > Sent: Friday, January 2, 2015 9:44:45 AM > Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files > > On 12/29/2014 06:13 PM, Tony James wrote: > > On Mon, Dec 29, 2014 at 5:26 AM, Itamar Heim wrote: > >> On 12/29/2014 09:25 AM, Nir Soffer wrote: > >>> > >>> - Original Message - > >>>> > >>>> From: "Tony James" > >>>> To: devel@ovirt.org > >>>> Sent: Monday, December 29, 2014 3:30:49 AM > >>>> Subject: [ovirt-devel] UI Plugin to Upload ISO Files > >>>> > >>>> This message is in response to an earlier thread regarding a UI plugin > >>>> to upload ISO files. Like the original poster, Lucas, I began work on > >>>> a UI plugin to allow uploading ISO files through a UI plugin. After > >>>> reading the previous thread I'm re-thinking the architecture. > >>>> > >>>> It was suggested that the recommended approach to upload files to a > >>>> storage domain is through the VDSM API [1]. I'm pretty familiar with > >>>> the oVirt REST API but have been unable to find documentation > >>>> regarding accessing the VDSM API. Should the VDSM API be accessible > >>>> by a UI plugin? If so, is there documentation available to do so? > >>>> > >>>> [1] http://lists.ovirt.org/pipermail/devel/2014-December/009497.html > >>> > >>> > >>> Basically you have to: > >>> 1. Use the vdsm xmlrpc/jsonrpc to create an image > >>> 2. Use the vdsm http api to upload the data to the image. This will > >>> create > >>> a task and return a task id. > >>> 3. Use the vdsm xmlrpc/jsonrpc api to check the task status, and clear > >>> the task when done > >>> > >>> The xmlrpc/jsonrpc api is documented here: > >>> > >>> http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=vdsm/rpc/vdsmapi-schema.json;h=1edcda86c8468b68c620eff4844b57ca30e44ea7;hb=HEAD > >>> > >>> You can check the code for upload here: > >>> > >>> http://gerrit.ovirt.org/gitweb?p=vdsm.git;a=blob;f=vdsm/rpc/BindingXMLRPC.py;h=759ed7845e63658a13c139684095bd56c03a29ac;hb=HEAD#l158 > >> > >> > >> I assume the upload will be done via a servlet on the engine, not directly > >> by the ui plugin accessing vdsm. > >> worth discussing your plans here, to make sure architecture/security are > >> correct. > >> > > > > I was planning on using a python CGI script which would accept the > > upload via POST from the UI plugin. The file would be stored in /tmp > > on the engine host. > > > > After the file was successfully uploaded, the CGI script would send a > > POST to a python HTTP server (BaseHTTPServer, also running on engine > > host) with the filename and storage domain information. This python > > script would then take care of mounting the storage domain and copying > > the file to the appropriate location. > > > > This was my initial approach, I plan on checking out the VDSM API as well. > > > > my preference would be to stream via a servlet to the vdsm api, rather > than "store and forward" to avoid potentially exhausting space on engine > or having to deal with two phased task tracking. > > the tricky part which requires a review is validating authentication and > authorization by the servlet - to make sure one has the permission to > write to a certain disk (for data domains) / iso domain. > this should be similar to the websocket novnc approach of validating > user has access to relevant VM (but Alon may correct me if its different) these requirements are for core product feature, while I guess Tony is after a solution to bridge the gap of the missing basic product feature within his environment. his solution is the most simple to solve his local problem, please assign core developer(s) to resolve the generic problem. Expecting a contributer to apply something the product was not designed for or to fix the entire product is incorrect. we have long way to enable pluggable server side logic; we have no stable interface for authentication check (although we plan to have one for 3.6), we have no stable xmlrpc wrapper, not to mention that the xmlrpc should be obsoleted once the json rpc is out, we do not have access to dao to obtain information about entities, we do not have stable interface to engine key and track its usage, we do not have restapi extensions to extend server side functionality, I guess we do not have many more, as engine was never designed as modular extensible component. we should also consider dropping the image upload to vdsm in favor of glance, so that core product will support glance directly either by embedding it or by delegating into it. this will enable us to retire the xmlrpc entirely as far as I understand, it will also enable to implement similar functionality of what initially requested within this thread. Regards, Alon ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] oVirt AAA LDAP
- Original Message -
> From: "Tang Jackson"
> To: devel@ovirt.org
> Sent: Monday, December 15, 2014 11:55:22 AM
> Subject: [ovirt-devel] oVirt AAA LDAP
>
>
>
> Hello Alon,
>
>
>
> I am having some trouble using the new aaa released in version 3.5 of oVirt.
>
>
>
> include =
>
>
>
> #
>
> # Active directory domain name.
>
> #
>
> vars.domain = jp.co.x.com
>
>
>
> #
>
> # Search user and its password.
>
> #
>
> #vars.user = CN=username,OU=UserAccounts,DC=jp,DC=co,DC=xxx,DC=com
>
> vars.user = xxx
user should be username@${global:vars.domain}
>
> vars.password = xx
>
>
>
> #
>
> # Optional DNS servers, if enterprise
>
> # DNS server cannot resolve the domain srvrecord.
>
> #
>
> vars.dns = dns://xxx.jp.co..com
this must point to active directory dns implementation, all srv records should
be available, you can choose one or more domain controllers or remove this if
your default dns is referring the microsoft dns.
> 2014-12-15 13:39:28,265 ERROR
> [org.ovirt.engineextensions.aaa.ldap.AuthzExtension] (MSC service thread
> 1-6) [ovirt-engine-extension-aaa-ldap.authz::sqex-authz] Cannot initialize
> LDAP framework, deferring initialization. Error: An error occurred while
> attempting to query DNS in order to retrieve SRV records with name
> '_gc._tcp.jp.co.square-enix.com': javax.naming.NameNotFoundException: DNS
> name not found [response code 3]; remaining name
> '_gc._tcp.jp.co.square-enix.com'
this states that the jp.co.square-enix.com is either:
1. not active directory domain name, missing component or similar, or spelled
incorrectly.
2. the ldap you refer to is missing active directory srv records.
Alon
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] UI Plugin to Upload ISO Files
- Original Message - > From: "Federico Simoncelli" > To: "Alon Bar-Lev" > Cc: "Nir Soffer" , "devel" , "李建盛" > , "Lucas Vandroux" > , "Liron Aravot" , "潘礼洋" > , "Michal Skrivanek" > > Sent: Monday, December 15, 2014 7:09:11 PM > Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files > > - Original Message - > > From: "Alon Bar-Lev" > > To: "Nir Soffer" > > Cc: "devel" , "李建盛" , "Lucas > > Vandroux" , "Liron > > Aravot" , "潘礼洋" , "Michal > > Skrivanek" > > Sent: Monday, December 15, 2014 5:52:36 PM > > Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files > > > > - Original Message - > > > From: "Nir Soffer" > > > To: "Alon Bar-Lev" > > > Cc: "Itamar Heim" , "devel" , "Lucas > > > Vandroux" , "李建盛" > > > , "潘礼洋" , "Michal > > > Skrivanek" > > > , "Liron Aravot" > > > > > > Sent: Monday, December 15, 2014 6:47:44 PM > > > Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files > > > > > > - Original Message - > > > > From: "Alon Bar-Lev" > > > > To: "Itamar Heim" > > > > Cc: "devel" , "Lucas Vandroux" > > > > , > > > > "李建盛" , "潘礼洋" > > > > , "Michal Skrivanek" > > > > Sent: Sunday, December 14, 2014 11:47:26 PM > > > > Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files > > > > > > > > > > > > using ssh and/or nfs to send artifacts to hosts is something we should > > > > avoid > > > > so using iso/image uploader tools are not a solution. > > > > vdsm should support uploading images using its own protocol based on > > > > the > > > > authentication between engine and vdsm, is it already? > > > > > > Vdsm does support upload over http/https directly to storage. > > > > > > This feature is used to store ovf backups on storage domains, and > > > probably > > > not very efficient, but may be good enough for now. > > > > > > See vdsm/rpc/BindingXMLRPC.py (do_PUT) > > > > thanks. > > I hear this function is not supported by the new jsonrpc, nor will it be > > supported when messaging will be used... so not sure if it is a good idea > > to > > add functionality on top of this one. > > The format (xmlrpc/jsonrpc) here is not much interesting, the interesting > part is the transport. In fact current download/uploadImage uses REST > GET/PUT for downloading/uploading the images (only the errors/messages are > reported with xmlrpc or eventually they could be reported with jsonrpc). > > By design they were not mixed with the other control APIs (because it's > not control, it's data). And indeed it cannot be transported with > messaging. > > Uploading/dowloading data to/from the host involves a data transport > (and http REST is the most commonly used). Which is exactly what you > need here, and it was in fact designed for this use case. there are plans to use messaging/broker to access hosts. this should abstract the physical location of the host. using direct connection to host in addition to broker is something that should be avoided. once solution may be to obtain connection information from the control channel, but one of the "problems" that will nice to be solved is to stop initiating connections from manager. > > > this should be core feature, it cannot be implemented as plugin within the > > current monolithic implementation. > > +1 > > -- > Federico > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] UI Plugin to Upload ISO Files
- Original Message - > From: "Michal Skrivanek" > To: "Alon Bar-Lev" > Cc: "Itamar Heim" , "Lucas Vandroux" > , "devel" , "潘礼洋" > , "李建盛" , "Scott Herold" > , "Allon Mureinik" > , "Federico Simoncelli" , "Barak > Azulay" , "Brian > Proffitt" > Sent: Monday, December 15, 2014 5:50:21 PM > Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files > > > On Dec 14, 2014, at 22:47 , Alon Bar-Lev wrote: > > > > > > > - Original Message - > >> From: "Itamar Heim" > >> To: "Lucas Vandroux" , "devel" > >> , "潘礼洋" , "李建盛" > >> > >> Cc: "Michal Skrivanek" , "Scott Herold" > >> , "Allon Mureinik" > >> , "Federico Simoncelli" , "Barak > >> Azulay" , "Brian > >> Proffitt" , "Alon Bar-Lev" > >> Sent: Sunday, December 14, 2014 11:35:40 PM > >> Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files > >> > >> On 12/12/2014 05:15 AM, Lucas Vandroux wrote: > >>> Dear all, > >>> > >>> I'm actually working to create a custom user interface plugin for oVirt > >>> web administration application to let user upload iso files. > >>> > >>> I'm in the very first stage of the project. I'm planning to use > >>> angularjs with the ng-flow module <https://github.com/flowjs/ng-flow> on > >>> the client-side and a java servlet using the ovirt-iso-uploader > >>> <http://www.ovirt.org/OVirt_engine_tools#ovirt-iso-uploader> engine tool > >>> on the server-side. > >>> > >>> All my code is going to be on Github in the following repository : > >>> iso-uploader-plugin > >>> <https://github.com/ovirt-china/iso-uploader-plugin>. You can also check > >>> a more detailed version of the specifications on my wiki > >>> <https://github.com/ovirt-china/iso-uploader-plugin/wiki/Specifications>. > >>> > >>> I'm writing to you guys to know if there is a way for us to collaborate > >>> as you may also want to develop something like this to be integrated in > >>> the oVirt Engine. > >>> > >>> Best regards, > >>> > >>> - Lucas Vandroux （冯凯） > >>> > >>> > >> > >> looks very nice. > >> > >> This is actually very interesting (and requested by multiple folks) but > >> i'd like to see if we should focus on the more simple "upload iso's" or > >> it doing more than just upload ISO's, but also VMs. > >> for the latter, architecture would probably be a servlet[1] on the > >> engine and stream to vdsm to write to storage, so both vm disks and/or > >> iso's could be uploaded/downloaded. > > > > using ssh and/or nfs to send artifacts to hosts is something we should > > avoid so using iso/image uploader tools are not a solution. > > vdsm should support uploading images using its own protocol based on the > > authentication between engine and vdsm, is it already? > > nope, we don't > > > this should be a core feature not an add-on within the current monolithic > > implementation, as there is no access to vdsm interaction from any of the > > interfaces. > > well, since we have this feature in the plan for a long time and didn't get > to it then a UI plugin would be nice. > Currently the only way to upload "stuff" is using ovirt-iso-uploader. indeed "nice", but we cannot introduce anything that is "nice" but insecure. using iso/image uplaoder spawned by servlet cannot be something that is endorsed. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] UI Plugin to Upload ISO Files
- Original Message - > From: "Nir Soffer" > To: "Alon Bar-Lev" > Cc: "Itamar Heim" , "devel" , "Lucas > Vandroux" , "李建盛" > , "潘礼洋" , "Michal Skrivanek" > , "Liron Aravot" > > Sent: Monday, December 15, 2014 6:47:44 PM > Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files > > - Original Message - > > From: "Alon Bar-Lev" > > To: "Itamar Heim" > > Cc: "devel" , "Lucas Vandroux" , > > "李建盛" , "潘礼洋" > > , "Michal Skrivanek" > > Sent: Sunday, December 14, 2014 11:47:26 PM > > Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files > > > > > > > > - Original Message - > > > From: "Itamar Heim" > > > To: "Lucas Vandroux" , "devel" > > > , > > > "潘礼洋" , "李建盛" > > > > > > Cc: "Michal Skrivanek" , "Scott Herold" > > > , "Allon Mureinik" > > > , "Federico Simoncelli" , > > > "Barak > > > Azulay" , "Brian > > > Proffitt" , "Alon Bar-Lev" > > > Sent: Sunday, December 14, 2014 11:35:40 PM > > > Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files > > > > > > On 12/12/2014 05:15 AM, Lucas Vandroux wrote: > > > > Dear all, > > > > > > > > I'm actually working to create a custom user interface plugin for oVirt > > > > web administration application to let user upload iso files. > > > > > > > > I'm in the very first stage of the project. I'm planning to use > > > > angularjs with the ng-flow module <https://github.com/flowjs/ng-flow> > > > > on > > > > the client-side and a java servlet using the ovirt-iso-uploader > > > > <http://www.ovirt.org/OVirt_engine_tools#ovirt-iso-uploader> engine > > > > tool > > > > on the server-side. > > > > > > > > All my code is going to be on Github in the following repository : > > > > iso-uploader-plugin > > > > <https://github.com/ovirt-china/iso-uploader-plugin>. You can also > > > > check > > > > a more detailed version of the specifications on my wiki > > > > <https://github.com/ovirt-china/iso-uploader-plugin/wiki/Specifications>. > > > > > > > > I'm writing to you guys to know if there is a way for us to collaborate > > > > as you may also want to develop something like this to be integrated in > > > > the oVirt Engine. > > > > > > > > Best regards, > > > > > > > > - Lucas Vandroux （冯凯） > > > > > > > > > > > > > > looks very nice. > > > > > > This is actually very interesting (and requested by multiple folks) but > > > i'd like to see if we should focus on the more simple "upload iso's" or > > > it doing more than just upload ISO's, but also VMs. > > > for the latter, architecture would probably be a servlet[1] on the > > > engine and stream to vdsm to write to storage, so both vm disks and/or > > > iso's could be uploaded/downloaded. > > > > using ssh and/or nfs to send artifacts to hosts is something we should > > avoid > > so using iso/image uploader tools are not a solution. > > vdsm should support uploading images using its own protocol based on the > > authentication between engine and vdsm, is it already? > > Vdsm does support upload over http/https directly to storage. > > This feature is used to store ovf backups on storage domains, and probably > not very efficient, but may be good enough for now. > > See vdsm/rpc/BindingXMLRPC.py (do_PUT) thanks. I hear this function is not supported by the new jsonrpc, nor will it be supported when messaging will be used... so not sure if it is a good idea to add functionality on top of this one. this should be core feature, it cannot be implemented as plugin within the current monolithic implementation. > > > this should be a core feature not an add-on within the current monolithic > > implementation, as there is no access to vdsm interaction from any of the > > interfaces. > > Nir > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] UI Plugin to Upload ISO Files
- Original Message - > From: "Itamar Heim" > To: "Lucas Vandroux" , "devel" , > "潘礼洋" , "李建盛" > > Cc: "Michal Skrivanek" , "Scott Herold" > , "Allon Mureinik" > , "Federico Simoncelli" , "Barak > Azulay" , "Brian > Proffitt" , "Alon Bar-Lev" > Sent: Sunday, December 14, 2014 11:35:40 PM > Subject: Re: [ovirt-devel] UI Plugin to Upload ISO Files > > On 12/12/2014 05:15 AM, Lucas Vandroux wrote: > > Dear all, > > > > I'm actually working to create a custom user interface plugin for oVirt > > web administration application to let user upload iso files. > > > > I'm in the very first stage of the project. I'm planning to use > > angularjs with the ng-flow module <https://github.com/flowjs/ng-flow> on > > the client-side and a java servlet using the ovirt-iso-uploader > > <http://www.ovirt.org/OVirt_engine_tools#ovirt-iso-uploader> engine tool > > on the server-side. > > > > All my code is going to be on Github in the following repository : > > iso-uploader-plugin > > <https://github.com/ovirt-china/iso-uploader-plugin>. You can also check > > a more detailed version of the specifications on my wiki > > <https://github.com/ovirt-china/iso-uploader-plugin/wiki/Specifications>. > > > > I'm writing to you guys to know if there is a way for us to collaborate > > as you may also want to develop something like this to be integrated in > > the oVirt Engine. > > > > Best regards, > > > > - Lucas Vandroux （冯凯） > > > > > > looks very nice. > > This is actually very interesting (and requested by multiple folks) but > i'd like to see if we should focus on the more simple "upload iso's" or > it doing more than just upload ISO's, but also VMs. > for the latter, architecture would probably be a servlet[1] on the > engine and stream to vdsm to write to storage, so both vm disks and/or > iso's could be uploaded/downloaded. using ssh and/or nfs to send artifacts to hosts is something we should avoid so using iso/image uploader tools are not a solution. vdsm should support uploading images using its own protocol based on the authentication between engine and vdsm, is it already? this should be a core feature not an add-on within the current monolithic implementation, as there is no access to vdsm interaction from any of the interfaces. Alon ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Important change in UI plugins REST API integration
- Original Message - > From: "Sven Kieske" > To: devel@ovirt.org > Sent: Tuesday, December 2, 2014 10:41:00 AM > Subject: Re: [ovirt-devel] Important change in UI plugins REST API > integration > > > > On 01/12/14 20:26, Vojtech Szocs wrote: > > In other words, usability of REST session ID is now strictly > > scoped to GUI user being authenticated. If the user logs in, > > (always) new REST session ID will be passed to all UI plugins. > > If the user logs out, REST session ID will not work anymore. > > What if I use just REST for logging in and doing something > without any GUI interaction at all? > > this reads a little like: you always need an open web gui > to be able to use REST, which does not make sense at all. If you provide your own credentials nothing changed. The change is only effecting RESTAPI usage within the user interface using the credentials obtained interactively from the user within login page. > So I guess I'm misreading this? > > -- > Mit freundlichen Grüßen / Regards > > Sven Kieske > > Systemadministrator > Mittwald CM Service GmbH & Co. KG > Königsberger Straße 6 > 32339 Espelkamp > T: +49-5772-293-100 > F: +49-5772-293-333 > https://www.mittwald.de > Geschäftsführer: Robert Meyer > St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen > Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen > ___ > 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] 3rd party jars within rpm
- Original Message - > From: "Sandro Bonazzola" > To: "Alon Bar-Lev" , "devel" > Sent: Thursday, November 20, 2014 9:34:23 AM > Subject: Re: 3rd party jars within rpm > > Il 19/11/2014 16:11, Alon Bar-Lev ha scritto: > > Hi, > > > > The following 3rd party jars are embedded without our spec while it should > > not be without very good reason. > > > > known waiting we drop support from > ./usr/share/ovirt-engine/modules/common/org/apache/sshd/main/sshd-core.jar > > Can't we have it backported from f21 to f20? Already asked to the fedora > package maintainer? > yes, and rejected per one of the dependencies. > > > > known, bug#1164547 > > ./usr/share/ovirt-engine/modules/common/org/antlr/antlr4-runtime/main/antlr4-runtime.jar > > > > these are new... not sure why were added and not with proper external > > dependency and/or jboss. I could not find a specific patch, so I cannot > > open a specific bug. > > > > ./usr/share/ovirt-engine/modules/common/com/sun/xml/bind/main/jaxb-xjc.jar > > ./usr/share/ovirt-engine/modules/common/com/sun/xml/bind/main/jaxb-impl.jar > > ./usr/share/ovirt-engine/modules/common/com/sun/xml/bind/main/jaxb-core.jar > > > > Regards, > > Alon > > > > > -- > 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] 3rd party jars within rpm
- Original Message - > From: "Alon Bar-Lev" > To: "devel" > Sent: Wednesday, November 19, 2014 5:11:34 PM > Subject: [ovirt-devel] 3rd party jars within rpm > > Hi, > > The following 3rd party jars are embedded without our spec while it should > not be without very good reason. > > known waiting we drop support from ./usr/share/ovirt-engine/modules/common/org/apache/sshd/main/sshd-core.jar > > known, bug#1164547 > ./usr/share/ovirt-engine/modules/common/org/antlr/antlr4-runtime/main/antlr4-runtime.jar > > these are new... not sure why were added and not with proper external > dependency and/or jboss. I could not find a specific patch, so I cannot open > a specific bug. > > ./usr/share/ovirt-engine/modules/common/com/sun/xml/bind/main/jaxb-xjc.jar > ./usr/share/ovirt-engine/modules/common/com/sun/xml/bind/main/jaxb-impl.jar > ./usr/share/ovirt-engine/modules/common/com/sun/xml/bind/main/jaxb-core.jar I was looking at wrong branch, added per[1]. Is it jboss-7.1.1 issue or common to eap, if common to eap we should open a bug to resolve this without external dependency. We should add rpm dependency and symlink like any other package. Thanks, Alon [1] http://gerrit.ovirt.org/#/c/30713/ ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] 3rd party jars within rpm
Hi, The following 3rd party jars are embedded without our spec while it should not be without very good reason. known waiting we drop support from http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Thoughts on modularization
Hi, I can summarized that you want again to go into the "Java way" and not the "Simple/primitive way". I think it is a mistake and will not have any benefit, "API" can be a wrapper over primitive interaction. We were there at past discussions, and as there is no leader of project we can discuss this to death, and I am not intend to do this yet another time (we have done this at branding, we have done this for aaa, partially for ui plugins [there we should kill gwt], and ...). I will make this short... 1. the current extension api is sufficient to construct a very complex implementation using very simple and primitive interface. 2. the current extension api enable implementing extensions using non java technologies, such as javascript/jpython. 3. the current extension api enable to not have any difference if core or extension interacts with extensions. 4. the current extension api enable forward and backward compatibility in simple methodology,. 5. a wrapper over the extension api can provide whatever high level api that is preferred by developer as an optional utility. we can always over engineer solution or have java specific solutions, I always vote for simplicity. Alon - Original Message - > From: "Vojtech Szocs" > To: "Yair Zaslavsky" > Cc: "Alon Bar-Lev" , "Mark Proctor" , > devel@ovirt.org > Sent: Friday, November 7, 2014 4:53:49 PM > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > - Original Message - > > From: "Yair Zaslavsky" > > To: "Alon Bar-Lev" > > Cc: "Vojtech Szocs" , "Mark Proctor" > > , devel@ovirt.org > > Sent: Wednesday, November 5, 2014 9:40:05 PM > > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > > > - Original Message - > > > From: "Alon Bar-Lev" > > > To: "Vojtech Szocs" > > > Cc: "Mark Proctor" , devel@ovirt.org > > > Sent: Wednesday, November 5, 2014 6:16:15 PM > > > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > > > > > > > - Original Message ----- > > > > From: "Vojtech Szocs" > > > > To: "Alon Bar-Lev" > > > > Cc: devel@ovirt.org, "Mark Proctor" > > > > Sent: Wednesday, November 5, 2014 6:07:50 PM > > > > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > > > > > > > > > > > - Original Message - > > > > > From: "Alon Bar-Lev" > > > > > To: "Vojtech Szocs" > > > > > Cc: devel@ovirt.org, "Mark Proctor" > > > > > Sent: Wednesday, November 5, 2014 4:32:31 PM > > > > > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > From: "Vojtech Szocs" > > > > > > To: "Alon Bar-Lev" > > > > > > Cc: devel@ovirt.org, "Mark Proctor" > > > > > > Sent: Wednesday, November 5, 2014 5:24:14 PM > > > > > > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > From: "Alon Bar-Lev" > > > > > > > To: "Vojtech Szocs" > > > > > > > Cc: devel@ovirt.org, "Mark Proctor" > > > > > > > Sent: Wednesday, November 5, 2014 4:12:06 PM > > > > > > > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > > From: "Vojtech Szocs" > > > > > > > > To: devel@ovirt.org > > > > > > > > Cc: "Mark Proctor" > > > > > > > > Sent: Wednesday, November 5, 2014 5:04:24 PM > > > > > > > > Subject: [ovirt-devel] Thoughts on modularization > > > > > > > > > > > > > > > > Hi guys, > > > > > > > > > > > > > > > > I've discussed this recently with Yair and Mark, I just wanted > > > > > > > > to > > > > > > > > share >
Re: [ovirt-devel] Thoughts on modularization
- Original Message - > From: "Yair Zaslavsky" > To: "Alon Bar-Lev" > Cc: "Vojtech Szocs" , "Mark Proctor" > , devel@ovirt.org > Sent: Wednesday, November 5, 2014 10:40:05 PM > Subject: Re: [ovirt-devel] Thoughts on modularization > > > > > > 4. there must be core model to trigger the entire thing, core cannot be > > just > > a loader. > > Alon, can you elaborate here on number 4? > In an ideal world, wouldn't you want to have the "engine core" be a small as > something that goes over the extensions and loads them? and maybe let each > extension expose somehow its relevant part of rest-api (besides of using > ext-api to interact between extension and of course each extension should > have the relevant logic implementerd within) Well, there is a balance between generic and specific. If you go this route, can the Java JRE be the core you are looking for? The wisdom is to draw the line where the building blocks serves the purpose of building the application you need. Alon ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Thoughts on modularization
- Original Message -
> From: "Vojtech Szocs"
> To: "Alon Bar-Lev"
> Cc: devel@ovirt.org, "Mark Proctor"
> Sent: Wednesday, November 5, 2014 6:07:50 PM
> Subject: Re: [ovirt-devel] Thoughts on modularization
>
>
>
> - Original Message -
> > From: "Alon Bar-Lev"
> > To: "Vojtech Szocs"
> > Cc: devel@ovirt.org, "Mark Proctor"
> > Sent: Wednesday, November 5, 2014 4:32:31 PM
> > Subject: Re: [ovirt-devel] Thoughts on modularization
> >
> >
> >
> > - Original Message -
> > > From: "Vojtech Szocs"
> > > To: "Alon Bar-Lev"
> > > Cc: devel@ovirt.org, "Mark Proctor"
> > > Sent: Wednesday, November 5, 2014 5:24:14 PM
> > > Subject: Re: [ovirt-devel] Thoughts on modularization
> > >
> > >
> > >
> > > - Original Message -
> > > > From: "Alon Bar-Lev"
> > > > To: "Vojtech Szocs"
> > > > Cc: devel@ovirt.org, "Mark Proctor"
> > > > Sent: Wednesday, November 5, 2014 4:12:06 PM
> > > > Subject: Re: [ovirt-devel] Thoughts on modularization
> > > >
> > > >
> > > >
> > > > - Original Message -
> > > > > From: "Vojtech Szocs"
> > > > > To: devel@ovirt.org
> > > > > Cc: "Mark Proctor"
> > > > > Sent: Wednesday, November 5, 2014 5:04:24 PM
> > > > > Subject: [ovirt-devel] Thoughts on modularization
> > > > >
> > > > > Hi guys,
> > > > >
> > > > > I've discussed this recently with Yair and Mark, I just wanted to
> > > > > share
> > > > > some more thoughts on this topic -- in particular, how modularization
> > > > > problem can be approached (regardless of implementation details).
> > > > >
> > > > > I see two approaches here. The typical one is to define APIs for
> > > > > modules
> > > > > to consume. For example, oVirt Engine extension API has API for auth
> > > > > stuff; oVirt UI plugin API has API for showing tabs and dialogs, etc.
> > > > > The advantage is strict consistency, disadvantage is burden of having
> > > > > to maintain the whole API. With this approach, you tell modules:
> > > > > "This
> > > > > is the API to work with system, defining how you can plug into it."
> > > > >
> > > > > Now turn 180 degrees. The other approach, which is really
> > > > > interesting,
> > > > > is to let modules themselves export API. This naturally leads to
> > > > > module
> > > > > hierarchies. Ultimately, this leads to micro-kernel-style
> > > > > development,
> > > > > where all logic resides in modules. Now you might ask: "What if we
> > > > > want
> > > > > to employ some consistent work flow across multiple modules? For
> > > > > example,
> > > > > have some pluggable *auth* infra?" -- this can be done via some
> > > > > "higher"
> > > > > level module, that exports API and "lower" level modules consume that
> > > > > API.
> > > > >
> > > > > If you have any ideas, please share!
> > > >
> > > > Both solutions can be applied using existing extension api, an
> > > > extension
> > > > can
> > > > locate other extension and interact with it the same way the core
> > > > interacts
> > > > with extensions.
> > >
> > > But how does core interact with extensions? I assume via well-defined
> > > API, i.e. in accordance with first approach mentioned above.
> >
> > presentation:
> > http://www.ovirt.org/File:Ovirt_3.5_-_aaa.pdf
>
> Thanks for sharing!
>
> >
> > package org.ovirt.engine.api.extensions;
> >
> > /**
> > * Interface of an extension.
> > */
> > public interface Extension {
> >
> > /**
> > * Invoke operation.
> > * @param input input parameters.
> > * @param output output parameters.
> > *
> > *
> > * Interaction is done via the parameters.
> > * Exceptions are not allowed.
> > *
> > *
> > * Basic mappings available at {@link Base}.
&g
Re: [ovirt-devel] Thoughts on modularization
- Original Message -
> From: "Vojtech Szocs"
> To: "Alon Bar-Lev"
> Cc: devel@ovirt.org, "Mark Proctor"
> Sent: Wednesday, November 5, 2014 5:24:14 PM
> Subject: Re: [ovirt-devel] Thoughts on modularization
>
>
>
> - Original Message -
> > From: "Alon Bar-Lev"
> > To: "Vojtech Szocs"
> > Cc: devel@ovirt.org, "Mark Proctor"
> > Sent: Wednesday, November 5, 2014 4:12:06 PM
> > Subject: Re: [ovirt-devel] Thoughts on modularization
> >
> >
> >
> > - Original Message -
> > > From: "Vojtech Szocs"
> > > To: devel@ovirt.org
> > > Cc: "Mark Proctor"
> > > Sent: Wednesday, November 5, 2014 5:04:24 PM
> > > Subject: [ovirt-devel] Thoughts on modularization
> > >
> > > Hi guys,
> > >
> > > I've discussed this recently with Yair and Mark, I just wanted to share
> > > some more thoughts on this topic -- in particular, how modularization
> > > problem can be approached (regardless of implementation details).
> > >
> > > I see two approaches here. The typical one is to define APIs for modules
> > > to consume. For example, oVirt Engine extension API has API for auth
> > > stuff; oVirt UI plugin API has API for showing tabs and dialogs, etc.
> > > The advantage is strict consistency, disadvantage is burden of having
> > > to maintain the whole API. With this approach, you tell modules: "This
> > > is the API to work with system, defining how you can plug into it."
> > >
> > > Now turn 180 degrees. The other approach, which is really interesting,
> > > is to let modules themselves export API. This naturally leads to module
> > > hierarchies. Ultimately, this leads to micro-kernel-style development,
> > > where all logic resides in modules. Now you might ask: "What if we want
> > > to employ some consistent work flow across multiple modules? For example,
> > > have some pluggable *auth* infra?" -- this can be done via some "higher"
> > > level module, that exports API and "lower" level modules consume that
> > > API.
> > >
> > > If you have any ideas, please share!
> >
> > Both solutions can be applied using existing extension api, an extension
> > can
> > locate other extension and interact with it the same way the core interacts
> > with extensions.
>
> But how does core interact with extensions? I assume via well-defined
> API, i.e. in accordance with first approach mentioned above.
presentation:
http://www.ovirt.org/File:Ovirt_3.5_-_aaa.pdf
package org.ovirt.engine.api.extensions;
/**
* Interface of an extension.
*/
public interface Extension {
/**
* Invoke operation.
* @param input input parameters.
* @param output output parameters.
*
*
* Interaction is done via the parameters.
* Exceptions are not allowed.
*
*
* Basic mappings available at {@link Base}.
*
*
* @see Base
*/
void invoke(ExtMap input, ExtMap output);
}
> With second approach mentioned above, core would not interact with
> extensions at all (or in a very limited way), instead - extensions
> would interact with each other. In other words, extension would not
> need to implement core-specific API (there would be none), instead
> it would inject its dependencies (other modules/extensions) and
> consume their APIs. This is the difference I wanted to point out :)
The extension interface is primitive to enable exactly that, provided java
people will open their minds :)
Regards,
Alon
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Thoughts on modularization
- Original Message - > From: "Vojtech Szocs" > To: devel@ovirt.org > Cc: "Mark Proctor" > Sent: Wednesday, November 5, 2014 5:04:24 PM > Subject: [ovirt-devel] Thoughts on modularization > > Hi guys, > > I've discussed this recently with Yair and Mark, I just wanted to share > some more thoughts on this topic -- in particular, how modularization > problem can be approached (regardless of implementation details). > > I see two approaches here. The typical one is to define APIs for modules > to consume. For example, oVirt Engine extension API has API for auth > stuff; oVirt UI plugin API has API for showing tabs and dialogs, etc. > The advantage is strict consistency, disadvantage is burden of having > to maintain the whole API. With this approach, you tell modules: "This > is the API to work with system, defining how you can plug into it." > > Now turn 180 degrees. The other approach, which is really interesting, > is to let modules themselves export API. This naturally leads to module > hierarchies. Ultimately, this leads to micro-kernel-style development, > where all logic resides in modules. Now you might ask: "What if we want > to employ some consistent work flow across multiple modules? For example, > have some pluggable *auth* infra?" -- this can be done via some "higher" > level module, that exports API and "lower" level modules consume that API. > > If you have any ideas, please share! Both solutions can be applied using existing extension api, an extension can locate other extension and interact with it the same way the core interacts with extensions. Alon ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ATN] [ovirt-engine] engine master logging
- Original Message -
> From: "Moti Asayag"
> To: "Alon Bar-Lev"
> Cc: devel@ovirt.org
> Sent: Monday, October 20, 2014 1:14:51 PM
> Subject: Re: [ovirt-devel] [ATN] [ovirt-engine] engine master logging
>
>
>
> ----- Original Message -
> > From: "Alon Bar-Lev"
> > To: devel@ovirt.org
> > Sent: Sunday, October 19, 2014 9:02:52 PM
> > Subject: [ovirt-devel] [ATN] [ovirt-engine] engine master logging
> >
> > Hello All,
> >
> > Thanks to Martin Perina efforts[1] the ovirt-engine logging was cleaned up
> > significantly throughout the engine.
> >
> > 1. Logging Facade is slf4j.
> > 2. Logging backend is jboss logging at jboss and java.util.logging at
> > standalone.
> > 3. No more commons-logging, log4j, combinations nor proprietary loggers.
> >
>
> Nice work. I was about to write "I guess the next step will be clearing the
> ThreadLocalParametersContainer" - but noticed it was already removed.
>
> > The org.ovirt.engine.core.utils.log.LogFactory and
> > org.ovirt.engine.core.utils.log.Log are depreciated now, the correlation id
> > is managed using logging MDC, so no need to use wrapper, and correlation
> > has
> > much wider effect, as also 3rd parties log records are attached with
> > correlation id.
>
> Would you consider extending the declaration of @Depracated for those classes
> with more information for the sake of those who might miss this email and
> should
> know what is the proper replacement for the deprecated logging method ?
as I wrote we will remove this classes soon using mass changes.
in few days there will be no reference for these.
> >
> > We will start to push changes to remove the usage of these classes in favor
> > of plain slf4j loggers.
> >
> > Quick lineup...
> >
> > 1. Usage:
> > import org.slf4j.Logger;
> > import org.slf4j.LoggerFactory;
> > class x {
> > private static final Logger log = LoggerFactory.getLogger(x.class);
> > }
> >
> > 2. slf4j logger javadoc is here[2].
> >
> > 3. Crash course:
> >
> > // simple string
> > log.info("string");
> >
> > // string with exception and stack trace
> > log.info("string", exception);
> >
> > // string with vars, logger will call argN.toString() for each {}.
> > log.info("string {} {} {}", arg1, arg2, arg3);
> >
> > 4. *NOTICE* Major difference than what we had:
> >
> > Exception arguments are not "magically" detected.
> >
> > // previous (utils Log): "exception" magically detected.
> > log.infoFormat("string {0}", arg1, exception);
> >
> > // new (slf4j):
> > log.info("string {}", arg1);
> > log.info("Exception", exception);
> >
> > // better new (slf4j):
> > log.info("string {}", arg1);
> > log.debug("Exception", exception);
> >
> > Please do not hesitate to raise any related issue you may find.
> >
> > Regards,
> > Alon Bar-Lev.
> >
> > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1109871
> > [2] http://www.slf4j.org/api/org/slf4j/Logger.html
> > ___
> > 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] [ATN] [ovirt-engine] engine master logging
Hello All,
Thanks to Martin Perina efforts[1] the ovirt-engine logging was cleaned up
significantly throughout the engine.
1. Logging Facade is slf4j.
2. Logging backend is jboss logging at jboss and java.util.logging at
standalone.
3. No more commons-logging, log4j, combinations nor proprietary loggers.
The org.ovirt.engine.core.utils.log.LogFactory and
org.ovirt.engine.core.utils.log.Log are depreciated now, the correlation id is
managed using logging MDC, so no need to use wrapper, and correlation has much
wider effect, as also 3rd parties log records are attached with correlation id.
We will start to push changes to remove the usage of these classes in favor of
plain slf4j loggers.
Quick lineup...
1. Usage:
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
class x {
private static final Logger log = LoggerFactory.getLogger(x.class);
}
2. slf4j logger javadoc is here[2].
3. Crash course:
// simple string
log.info("string");
// string with exception and stack trace
log.info("string", exception);
// string with vars, logger will call argN.toString() for each {}.
log.info("string {} {} {}", arg1, arg2, arg3);
4. *NOTICE* Major difference than what we had:
Exception arguments are not "magically" detected.
// previous (utils Log): "exception" magically detected.
log.infoFormat("string {0}", arg1, exception);
// new (slf4j):
log.info("string {}", arg1);
log.info("Exception", exception);
// better new (slf4j):
log.info("string {}", arg1);
log.debug("Exception", exception);
Please do not hesitate to raise any related issue you may find.
Regards,
Alon Bar-Lev.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1109871
[2] http://www.slf4j.org/api/org/slf4j/Logger.html
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] host installation failed
Please look at event log to see what actually failed.
- Original Message -
> From: "Yair Zaslavsky"
> To: "Alon Bar-Lev"
> Cc: devel@ovirt.org
> Sent: Friday, October 17, 2014 11:09:53 AM
> Subject: Re: [ovirt-devel] host installation failed
>
>
>
> ----- Original Message -
> > From: "Alon Bar-Lev"
> > To: "Yair Zaslavsky"
> > Cc: devel@ovirt.org
> > Sent: Friday, October 17, 2014 10:07:01 AM
> > Subject: Re: [ovirt-devel] host installation failed
> >
> >
> > You probably do not use ovirt-host-deploy-1.3.x within devenv, but have
> > ovirt-host-deploy-1.2.x.
>
> Thanks, it did help.
> Now I'm encountering this -
>
>
> 014-10-17 10:13:14,647 ERROR [org.ovirt.engine.core.uutils.ssh.SSHDialog]
> (org.ovirt.thread.pool-8-thread-6) SSH error running command
> root@192.168.1.1:'umask 0077; MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" mktemp -t
> ovirt-XX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; rm
> -fr \"${MYTMP}\" > /dev/null 2>&1" 0; rm -fr "${MYTMP}" && mkdir "${MYTMP}"
> && tar --warning=no-timestamp -C "${MYTMP}" -x && "${MYTMP}"/setup
> DIALOG/dialect=str:machine DIALOG/customization=bool:True': Command returned
> failure code 1 during SSH session 'root@192.168.1.1'
> 2014-10-17 10:13:14,650 ERROR [org.ovirt.engine.core.uutils.ssh.SSHDialog]
> (org.ovirt.thread.pool-8-thread-6) Exception: java.io.IOException: Command
> returned failure code 1 during SSH session 'root@192.168.1.1'
> at
>
> org.ovirt.engine.core.uutils.ssh.SSHClient.executeCommand(SSHClient.java:527)
> [uutils.jar:]
> at
>
> org.ovirt.engine.core.uutils.ssh.SSHDialog.executeCommand(SSHDialog.java:312)
> [uutils.jar:]
> at org.ovirt.engine.core.bll.VdsDeploy.execute(VdsDeploy.java:1118)
> [bll.jar:]
>
>
> My host is fedora core 20, in case I forgot to mention.
>
> >
> > - Original Message -
> > > From: "Yair Zaslavsky"
> > > To: devel@ovirt.org
> > > Sent: Friday, October 17, 2014 8:41:41 AM
> > > Subject: Re: [ovirt-devel] host installation failed
> > >
> > > I'm using master,
> > >
> > > commit hash -
> > > 6985aa8ac1b4182e346859082d10e5d542ca2969
> > >
> > >
> > >
> > > - Original Message -
> > > > From: "Yair Zaslavsky"
> > > > To: devel@ovirt.org
> > > > Sent: Friday, October 17, 2014 7:47:42 AM
> > > > Subject: [ovirt-devel] host installation failed
> > > >
> > > > HI,
> > > > I'm getting the following error when trying to add a host -
> > > >
> > > > .
> > > > 2014-10-17 06:51:02,522 INFO [org.ovirt.engine.core.bll.VdsDeploy]
> > > > (VdsDeploy) Host 192.168.1.1 reports unique id
> > > > 52402781-53A0-11CB-9BE9-B7E5E5F061A6
> > > > 2014-10-17 06:51:02,550 INFO [org.ovirt.engine.core.bll.VdsDeploy]
> > > > (VdsDeploy) Assigning unique id 52402781-53A0-11CB-9BE9-B7E5E5F061A6 to
> > > > Host
> > > > 192.168.1.1
> > > > 2014-10-17 06:51:02,817 ERROR [org.ovirt.engine.core.bll.VdsDeploy]
> > > > (VdsDeploy) Error during deploy dialog: java.lang.NullPointerException
> > > > at
> > > >
> > > > org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236)
> > > > [otopi.jar:]
> > > > at
> > > > org.ovirt.engine.core.bll.VdsDeploy$37.call(VdsDeploy.java:580)
> > > > [bll.jar:]
> > > > at
> > > > org.ovirt.engine.core.bll.VdsDeploy$37.call(VdsDeploy.java:579)
> > > > [bll.jar:]
> > > > at
> > > >
> > > > org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:668)
> > > > [bll.jar:]
> > > > at
> > > >
> > > > org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:873)
> > > > [bll.jar:]
> > > >
> > > >
> > > > Can you please assist ?
> > > >
> > > > Yair
> > > >
> > > > ___
> > > > 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
Re: [ovirt-devel] host installation failed
You probably do not use ovirt-host-deploy-1.3.x within devenv, but have ovirt-host-deploy-1.2.x. - Original Message - > From: "Yair Zaslavsky" > To: devel@ovirt.org > Sent: Friday, October 17, 2014 8:41:41 AM > Subject: Re: [ovirt-devel] host installation failed > > I'm using master, > > commit hash - > 6985aa8ac1b4182e346859082d10e5d542ca2969 > > > > - Original Message - > > From: "Yair Zaslavsky" > > To: devel@ovirt.org > > Sent: Friday, October 17, 2014 7:47:42 AM > > Subject: [ovirt-devel] host installation failed > > > > HI, > > I'm getting the following error when trying to add a host - > > > > . > > 2014-10-17 06:51:02,522 INFO [org.ovirt.engine.core.bll.VdsDeploy] > > (VdsDeploy) Host 192.168.1.1 reports unique id > > 52402781-53A0-11CB-9BE9-B7E5E5F061A6 > > 2014-10-17 06:51:02,550 INFO [org.ovirt.engine.core.bll.VdsDeploy] > > (VdsDeploy) Assigning unique id 52402781-53A0-11CB-9BE9-B7E5E5F061A6 to > > Host > > 192.168.1.1 > > 2014-10-17 06:51:02,817 ERROR [org.ovirt.engine.core.bll.VdsDeploy] > > (VdsDeploy) Error during deploy dialog: java.lang.NullPointerException > > at > > > > org.ovirt.otopi.dialog.MachineDialogParser.cliEnvironmentGet(MachineDialogParser.java:236) > > [otopi.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy$37.call(VdsDeploy.java:580) > > [bll.jar:] > > at org.ovirt.engine.core.bll.VdsDeploy$37.call(VdsDeploy.java:579) > > [bll.jar:] > > at > > > > org.ovirt.engine.core.bll.VdsDeploy._nextCustomizationEntry(VdsDeploy.java:668) > > [bll.jar:] > > at > > org.ovirt.engine.core.bll.VdsDeploy._threadMain(VdsDeploy.java:873) > > [bll.jar:] > > > > > > Can you please assist ? > > > > Yair > > > > ___ > > 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
Re: [ovirt-devel] Changes in engine dependencies modules
Hello All, Please notice that if you are using devenv you should remove PREFIX/share/ovirt-engine/modules after master rebase and before next make install-dev so you avoid leftovers. Regards, Alon Bar-Lev. - Original Message - > From: "Martin Perina" > To: devel@ovirt.org > Sent: Monday, October 13, 2014 10:19:43 AM > Subject: [ovirt-devel] Changes in engine dependencies modules > > Hi, > > as a part of logging refactoring [1] we needed to change structure > in engine dependencies modules. Now there are two subdirectories > under backend/manager/dependencies: > > common > - contains modules of standard dependencies modules (previously > they were placed directly under backend/manager/dependencies) > > tools > - contains special modules used only in tools (engine-manage-domains, > engine-config, notifier) > - those modules contains libraries that overwrites libraries contained > in JBoss distribution (currenlty slf4j with JUL as logging backend) > > So if you are currently preparing patches which change dependencies modules, > please adapt them to the new structure. > > Thanks > > Martin Perina > > > [1] http://lists.ovirt.org/pipermail/devel/2014-October/009004.html > ___ > 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 rpm dependency
Hi, This is a different issue. The fedora minimal has no tar per default. And we need to transfer set of files from manager to host, this is prior we know what host it is and what we need to perform. Transferring the file is using tar, so tar should exist on host prior of deploy. Only after files are extracted yum/rpms are used, so adding tar as dependency will have no effect. I hope it answers your question. Regards, Alon - Original Message - > From: "Tomer Saban" > To: "Alon Bar-Lev" > Cc: devel@ovirt.org > Sent: Monday, October 13, 2014 9:55:27 AM > Subject: Re: [ovirt-devel] Missing rpm dependency > > Because It seems this issue has been around since Fedora 19. > I came across it when trying to setup a new host on my oVirt. > > That problem persists when clicking "reinstall" on a host in oVirt(That's > exactly > what a user would do if the installation fails from the first place). > > That's why I think we ought to come out with a solution to this problem on > oVirt. > It's important for oVirt to have a hands-off host setup policy. > > Thanks, > Tomer Saban > > - Original Message - > From: "Alon Bar-Lev" > To: "Tomer Saban" > Cc: devel@ovirt.org > Sent: Sunday, October 12, 2014 7:54:32 PM > Subject: Re: [ovirt-devel] Missing rpm dependency > > > - Original Message - > > From: "Tomer Saban" > > To: devel@ovirt.org > > Sent: Sunday, October 12, 2014 6:31:57 PM > > Subject: [ovirt-devel] Missing rpm dependency > > > > Hi, > > > > It seems a dependency for "tar" is missing in Fedora 20. > > This issue has already been fixed on Fedora 19(See > > https://bugzilla.redhat.com/show_bug.cgi?id=986539#c1 for details) But it > > seems > > It made a comeback on Fedora 20. > > > > Who is in charge for the dependencies on oVirt and can check it out? > > why is this issue/bug related to ovirt? > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Missing rpm dependency
- Original Message - > From: "Tomer Saban" > To: devel@ovirt.org > Sent: Sunday, October 12, 2014 6:31:57 PM > Subject: [ovirt-devel] Missing rpm dependency > > Hi, > > It seems a dependency for "tar" is missing in Fedora 20. > This issue has already been fixed on Fedora 19(See > https://bugzilla.redhat.com/show_bug.cgi?id=986539#c1 for details) But it > seems > It made a comeback on Fedora 20. > > Who is in charge for the dependencies on oVirt and can check it out? why is this issue/bug related to ovirt? ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] vdsmcert expiration policy
You should trust the ca and not the certificate, so a change in certificate will not effect you. - Original Message - > From: "Denis Kirjanov" > To: devel@ovirt.org > Cc: "Sergey Mironov" > Sent: Thursday, October 9, 2014 10:30:18 AM > Subject: [ovirt-devel] vdsmcert expiration policy > > Hi guys, > > How can I manage the expiration time of the vdsmcert certificate? I've found > backup copies of the old vdsmcert.pem > on the hypervisor host in the /etc/pki/vdsm/certs directory and the new > vdsmcert.pem with a different certificate. > > I'm using vdsClient tool with SSL enabled so I have to use the vdsmcert.pem. > I thought that the certificate doesn't change... > > Thank you. > ___ > 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] Packages for oVirt 3.5.0 GA
- Original Message - > From: "Alon Bar-Lev" > To: "Sandro Bonazzola" > Cc: "Juan Hernandez" , devel@ovirt.org, "Paz Dangur" > , "Ohad Basan" > > Sent: Monday, October 6, 2014 7:48:13 PM > Subject: Re: [ovirt-devel] Packages for oVirt 3.5.0 GA > > > > - Original Message - > > From: "Sandro Bonazzola" > > To: "Alon Bar-Lev" > > Cc: "Juan Hernandez" , devel@ovirt.org, "Paz Dangur" > > , "Ohad Basan" > > > > Sent: Monday, October 6, 2014 5:25:36 PM > > Subject: Re: [ovirt-devel] Packages for oVirt 3.5.0 GA > > > > Il 06/10/2014 14:04, Alon Bar-Lev ha scritto: > > > > > > > > > - Original Message - > > >> From: "Sandro Bonazzola" > > >> To: "Juan Hernandez" , devel@ovirt.org > > >> Cc: "Paz Dangur" , "Ohad Basan" > > >> Sent: Monday, October 6, 2014 10:33:51 AM > > >> Subject: [ovirt-devel] Packages for oVirt 3.5.0 GA > > >> > > >> Hi, this is the package list for 3.5.0 GA composition. Some packages are > > >> still building, other are unchanged since RC4. > > >> Please review the list and warn if any package must be rebuilt. > > >> Thanks. > > >> > > >> > > >> # From developers: > > >> # oVirt Engine: > > >> > > >> waiting on > > >> http://jenkins.ovirt.org/view/All%20Running%20jobs/job/manual-build-tarball/424/ > > >> hash: ebf21d1 - build: ovirt-engine-3.5.0 > > >> > > >> # otopi > > >> waiting on Alon > > > > > > way too long... > > > http://jenkins.ovirt.org/job/otopi_any_create-rpms_manual/9/ > > > > Missing EL7 build. > > Added epel-7 axis, rebuilding from the tarball used in job #9. Please let > > me > > know if you want to rebuild it yourself or it's ok for you. > > http://jenkins.ovirt.org/job/otopi_any_create-rpms_manual/10/ > > > > > > > > > > >> # ovirt host deploy > > >> waiting on Alon > > > > > > way too long... > > > http://jenkins.ovirt.org/job/ovirt-host-deploy_any_create-rpms_manual/11/ > > > > > > Same here > > http://jenkins.ovirt.org/job/ovirt-host-deploy_any_create-rpms_manual/13/ ovirt-host-deploy-offline at powerpc, thanks to yaniv: http://koji.fedoraproject.org/koji/taskinfo?taskID=234 > > > > > > > > >> # ovirt-engine-extension-aaa-ldap > > >> # won't be released in 3.5.0 > > >> > > >> # ovirt-engine-extension-aaa-misc > > >> waiting on Alon > > > > > > hmmm... I will release this with the ldap... no point of it as > > > standalone. > > > > > >> > > >> # ovirt-engine-extension-logger-log4j > > >> waiting on Alon > > > > > > will be provided soon. > > > > > we will defer this to 3.5.1 with the others when we have ci job to build > tarballs. > > > > > > > -- > > 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] Packages for oVirt 3.5.0 GA
- Original Message - > From: "Sandro Bonazzola" > To: "Alon Bar-Lev" > Cc: "Juan Hernandez" , devel@ovirt.org, "Paz Dangur" > , "Ohad Basan" > > Sent: Monday, October 6, 2014 5:25:36 PM > Subject: Re: [ovirt-devel] Packages for oVirt 3.5.0 GA > > Il 06/10/2014 14:04, Alon Bar-Lev ha scritto: > > > > > > - Original Message - > >> From: "Sandro Bonazzola" > >> To: "Juan Hernandez" , devel@ovirt.org > >> Cc: "Paz Dangur" , "Ohad Basan" > >> Sent: Monday, October 6, 2014 10:33:51 AM > >> Subject: [ovirt-devel] Packages for oVirt 3.5.0 GA > >> > >> Hi, this is the package list for 3.5.0 GA composition. Some packages are > >> still building, other are unchanged since RC4. > >> Please review the list and warn if any package must be rebuilt. > >> Thanks. > >> > >> > >> # From developers: > >> # oVirt Engine: > >> > >> waiting on > >> http://jenkins.ovirt.org/view/All%20Running%20jobs/job/manual-build-tarball/424/ > >> hash: ebf21d1 - build: ovirt-engine-3.5.0 > >> > >> # otopi > >> waiting on Alon > > > > way too long... > > http://jenkins.ovirt.org/job/otopi_any_create-rpms_manual/9/ > > Missing EL7 build. > Added epel-7 axis, rebuilding from the tarball used in job #9. Please let me > know if you want to rebuild it yourself or it's ok for you. http://jenkins.ovirt.org/job/otopi_any_create-rpms_manual/10/ > > > > > >> # ovirt host deploy > >> waiting on Alon > > > > way too long... > > http://jenkins.ovirt.org/job/ovirt-host-deploy_any_create-rpms_manual/11/ > > > Same here http://jenkins.ovirt.org/job/ovirt-host-deploy_any_create-rpms_manual/13/ > > > > >> # ovirt-engine-extension-aaa-ldap > >> # won't be released in 3.5.0 > >> > >> # ovirt-engine-extension-aaa-misc > >> waiting on Alon > > > > hmmm... I will release this with the ldap... no point of it as standalone. > > > >> > >> # ovirt-engine-extension-logger-log4j > >> waiting on Alon > > > > will be provided soon. > > we will defer this to 3.5.1 with the others when we have ci job to build tarballs. > > > -- > 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] Packages for oVirt 3.5.0 GA
- Original Message - > From: "Sandro Bonazzola" > To: "Juan Hernandez" , devel@ovirt.org > Cc: "Paz Dangur" , "Ohad Basan" > Sent: Monday, October 6, 2014 10:33:51 AM > Subject: [ovirt-devel] Packages for oVirt 3.5.0 GA > > Hi, this is the package list for 3.5.0 GA composition. Some packages are > still building, other are unchanged since RC4. > Please review the list and warn if any package must be rebuilt. > Thanks. > > > # From developers: > # oVirt Engine: > > waiting on > http://jenkins.ovirt.org/view/All%20Running%20jobs/job/manual-build-tarball/424/ > hash: ebf21d1 - build: ovirt-engine-3.5.0 > > # otopi > waiting on Alon way too long... http://jenkins.ovirt.org/job/otopi_any_create-rpms_manual/9/ > # ovirt host deploy > waiting on Alon way too long... http://jenkins.ovirt.org/job/ovirt-host-deploy_any_create-rpms_manual/11/ > # ovirt-engine-extension-aaa-ldap > # won't be released in 3.5.0 > > # ovirt-engine-extension-aaa-misc > waiting on Alon hmmm... I will release this with the ldap... no point of it as standalone. > > # ovirt-engine-extension-logger-log4j > waiting on Alon will be provided soon. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] Building vdsm within Fedora
- Original Message - > From: "Sven Kieske" > To: devel@ovirt.org, "users" > Sent: Wednesday, September 24, 2014 10:44:17 AM > Subject: Re: [ovirt-users] Building vdsm within Fedora > > > > On 24/09/14 09:13, Federico Simoncelli wrote: > > You probably missed the first part "we were using qemu-kvm/qemu-img in > > the spec file". In that case you won't fail in any requirement. > > > > Basically the question is: was there any problem on centos6 before > > committing http://gerrit.ovirt.org/31214 ? > > Of course there was a problem, please follow the link in this very > commit to the according bugzilla: > > https://bugzilla.redhat.com/show_bug.cgi?id=1127763 > > In short: you can not use live snapshots without this updated spec file. > > And it's a PITA to install this package by hand, you must track > it's versions yourself etc pp. you basically lose all the stuff > a proper spec file gives you. > > > PS: I also don't get the "we want to get vdsm in every distribution" > a) it was never in any distro, it was in epel, which is a third party > repository anyway, so you can just provide it via ovirt repo imho. > b) no one packages vdsm for debian, ubuntu, gentoo, arch, suse, > $nameyourdistro or I completely missed it, so why treat fedora > in a special way? Don't misunderstand me, it would be cool if you > have packages for every distro, or even bsd based stuff, but I think > this is still a long way. > c) will anyone use vdsm without ovirt? is this even possible? > so imho you need ovirt repos anyway? People think that distribution is monolithic. While in fact most, including fedora, are modular. Alon ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [URGENT][ACTION NEEDED] ovirt-engine-extension-aaa-ldap is not built for 3.5.0 on Fedora 19
- Original Message - > From: "Alon Bar-Lev" > To: "Sandro Bonazzola" > Cc: "David Caro" , devel@ovirt.org, "infra" > > Sent: Tuesday, September 2, 2014 1:35:27 PM > Subject: Re: [ovirt-devel] [URGENT][ACTION NEEDED] > ovirt-engine-extension-aaa-ldap is not built for 3.5.0 on Fedora > 19 > > > > - Original Message - > > From: "Sandro Bonazzola" > > To: "David Caro" > > Cc: devel@ovirt.org, "infra" > > Sent: Tuesday, September 2, 2014 1:08:50 PM > > Subject: Re: [ovirt-devel] [URGENT][ACTION NEEDED] > > ovirt-engine-extension-aaa-ldap is not built for 3.5.0 on Fedora > > 19 > > > > Il 02/09/2014 12:05, David Caro ha scritto: > > > On 09/02, Sandro Bonazzola wrote: > > >> Hi, > > >> existing job is building ovirt-engine-extension-aaa-ldap_master using > > >> master repository for getting engine packages. > > >> http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_master_create-rpms-fc19-x86_64_merged/20/console > > >> > > >> Doesn't ovirt-engine-extension-aaa-ldap have a stabilization branch? > > >> > > > > > > It only has master branch. > > > > > >> BTW, a new job must be created getting engine packages from 3.5 snapshot > > >> repository in order to build on Fedora 19. > > >> > > > > > > Current job is failing due to requiring a non-existing rpm > > > (ovirt-engine-extensions-api) on f19 build. Will they ever be there? > > > Should I just replace the repos for f19? > > > > ovirt engine master is not built for F19 anymore. > > Not sure about requirements for building this package, but for F19 yes, > > please use 3.5 repo. There won't be f19 support on 3.6. > > I did not know we do not build f19 any more. > But yes, we can use the 3.5 repo. > same for ovirt-engine-extension-aaa-misc, ovirt-engine-extension-logger-log4j > > > > > > > > > > > >> Thanks, > > >> > > >> -- > > >> Sandro Bonazzola > > >> Better technology. Faster innovation. Powered by community > > >> collaboration. > > >> See how it works at redhat.com > > >> ___ > > >> Infra mailing list > > >> in...@ovirt.org > > >> http://lists.ovirt.org/mailman/listinfo/infra > > > > > > > > > -- > > 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 > > > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [URGENT][ACTION NEEDED] ovirt-engine-extension-aaa-ldap is not built for 3.5.0 on Fedora 19
- Original Message - > From: "Sandro Bonazzola" > To: "David Caro" > Cc: devel@ovirt.org, "infra" > Sent: Tuesday, September 2, 2014 1:08:50 PM > Subject: Re: [ovirt-devel] [URGENT][ACTION NEEDED] > ovirt-engine-extension-aaa-ldap is not built for 3.5.0 on Fedora > 19 > > Il 02/09/2014 12:05, David Caro ha scritto: > > On 09/02, Sandro Bonazzola wrote: > >> Hi, > >> existing job is building ovirt-engine-extension-aaa-ldap_master using > >> master repository for getting engine packages. > >> http://jenkins.ovirt.org/job/ovirt-engine-extension-aaa-ldap_master_create-rpms-fc19-x86_64_merged/20/console > >> > >> Doesn't ovirt-engine-extension-aaa-ldap have a stabilization branch? > >> > > > > It only has master branch. > > > >> BTW, a new job must be created getting engine packages from 3.5 snapshot > >> repository in order to build on Fedora 19. > >> > > > > Current job is failing due to requiring a non-existing rpm > > (ovirt-engine-extensions-api) on f19 build. Will they ever be there? > > Should I just replace the repos for f19? > > ovirt engine master is not built for F19 anymore. > Not sure about requirements for building this package, but for F19 yes, > please use 3.5 repo. There won't be f19 support on 3.6. I did not know we do not build f19 any more. But yes, we can use the 3.5 repo. > > > > > > >> Thanks, > >> > >> -- > >> Sandro Bonazzola > >> Better technology. Faster innovation. Powered by community collaboration. > >> See how it works at redhat.com > >> ___ > >> Infra mailing list > >> in...@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/infra > > > > > -- > 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 > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ENGINE] thoughts about LinqUtils
- Original Message - > From: "Greg Sheremeta" > To: "Alon Bar-Lev" > Cc: "Yair Zaslavsky" , "Itamar Heim" , > devel@ovirt.org > Sent: Friday, August 22, 2014 11:33:09 PM > Subject: Re: [ovirt-devel] [ENGINE] thoughts about LinqUtils > > > > - Original Message - > > From: "Alon Bar-Lev" > > To: "Greg Sheremeta" > > Cc: "Yair Zaslavsky" , "Itamar Heim" > > , devel@ovirt.org > > Sent: Friday, August 22, 2014 4:20:19 PM > > Subject: Re: [ovirt-devel] [ENGINE] thoughts about LinqUtils > > > > > > > > - Original Message - > > > From: "Greg Sheremeta" > > > To: "Yair Zaslavsky" > > > Cc: "Itamar Heim" , devel@ovirt.org, "Alon Bar-Lev" > > > > > > Sent: Friday, August 22, 2014 8:39:54 PM > > > Subject: Re: [ovirt-devel] [ENGINE] thoughts about LinqUtils > > > > > > > > > > > > - Original Message - > > > > From: "Yair Zaslavsky" > > > > To: "Itamar Heim" > > > > Cc: devel@ovirt.org > > > > Sent: Thursday, August 21, 2014 8:39:31 PM > > > > Subject: Re: [ovirt-devel] [ENGINE] thoughts about LinqUtils > > > > > > > > > > > > > > > > - Original Message - > > > > > From: "Itamar Heim" > > > > > To: "Yair Zaslavsky" , "Yevgeny Zaspitsky" > > > > > > > > > > Cc: devel@ovirt.org > > > > > Sent: Friday, August 22, 2014 12:25:52 AM > > > > > Subject: Re: [ovirt-devel] [ENGINE] thoughts about LinqUtils > > > > > > > > > > On 08/21/2014 09:55 AM, Yair Zaslavsky wrote: > > > > > > > > > > > > > > > > > > - Original Message - > > > > > >> From: "Yevgeny Zaspitsky" > > > > > >> To: "Yair Zaslavsky" > > > > > >> Cc: "Moti Asayag" , "Allon Mureinik" > > > > > >> , devel@ovirt.org > > > > > >> Sent: Thursday, August 21, 2014 4:35:33 PM > > > > > >> Subject: Re: [ovirt-devel] [ENGINE] thoughts about LinqUtils > > > > > >> > > > > > >> On 21/08/14 12:08, Yair Zaslavsky wrote: > > > > > >>> > > > > > >>> - Original Message - > > > > > >>>> From: "Yevgeny Zaspitsky" > > > > > >>>> To: "Moti Asayag" > > > > > >>>> Cc: "Yair Zaslavsky" , "Allon Mureinik" > > > > > >>>> , devel@ovirt.org > > > > > >>>> Sent: Thursday, August 21, 2014 11:26:40 AM > > > > > >>>> Subject: Re: [ovirt-devel] [ENGINE] thoughts about LinqUtils > > > > > >>>> > > > > > >>>> It seems like we can try moving to common-collections4. Yum on > > > > > >>>> my > > > > > >>>> Fedora20 > > > > > >>>> computer finds apache-commons-collections4 package. Fortunately > > > > > >>>> somebody > > > > > >>>> packed the jar into for a rpm for us. :-) > > > > > >>> What about RHEL 6.5? Can you please run a quick check? > > > > > >> Unfortunately my happiness was too hasty. Only Fedora people care > > > > > >> to > > > > > >> be > > > > > >> in the forward of the technology... The RHEL ones do not care > > > > > >> about > > > > > >> that... > > > > > > > > > > > > This is what I remembered. When you responded to the email for the > > > > > > first > > > > > > time , I had a strong deja vu that you tried addressing this issue > > > > > > yourself in the past (commons-collectios4) - due to different > > > > > > reason. > > > > > > > > > > > > > > > > is there a specific conflict or problem (or a huge chain of > > > > > dependencies) > > > > > ? > > > > > > > > To me it seems the answer to both is no - > > > > > > > > This is the requirement list - > > > > > > > > java >= 1.5 > > > > jpackage-utils > > > > rpmlib(CompressedFileNames) <= 3.0.4-1 > > > > rpmlib(FileDigests) <= 4.6.0-1 > > > > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > > > > rpmlib(PayloadIsXz) <= 5.2-1 > > > > > > > > > > > > Probably a matter of packaging? > > > > > > IIRC, Alon was the one who replied, and the issue was that Jboss included > > > an > > > old version (and we don't have classpath isolation, I guess) > > > > > > Greg > > > > > > > We would like to avoid maintaining and package components that are not > > provider either by el6 or jboss distribution. > > > > But based on other threads, it seems that I am the only one who remained > > trying to push compliance to the old ways, people feel that can maintain > > anything anywhere with no effort. > > > > Regards, > > Alon > > > > If I may clarify, there would be at least two stipulations for introducing > collections4. > > 1. someone else packages it and maintains it, available in Fedora and EL, >long term. Quality package. this is what missing, us maintaining a new package just to have more beautiful code is something that can be deferred for now. > 2. JBoss has proper classloader isolation so that, even though JBoss uses >collections3, a webapp can use collections4. should not be a problem to use both. > > I don't know the answer to either question :) > > Seems like minimal gain to me, though. > > Greg > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ENGINE] thoughts about LinqUtils
- Original Message - > From: "Greg Sheremeta" > To: "Yair Zaslavsky" > Cc: "Itamar Heim" , devel@ovirt.org, "Alon Bar-Lev" > > Sent: Friday, August 22, 2014 8:39:54 PM > Subject: Re: [ovirt-devel] [ENGINE] thoughts about LinqUtils > > > > - Original Message - > > From: "Yair Zaslavsky" > > To: "Itamar Heim" > > Cc: devel@ovirt.org > > Sent: Thursday, August 21, 2014 8:39:31 PM > > Subject: Re: [ovirt-devel] [ENGINE] thoughts about LinqUtils > > > > > > > > - Original Message - > > > From: "Itamar Heim" > > > To: "Yair Zaslavsky" , "Yevgeny Zaspitsky" > > > > > > Cc: devel@ovirt.org > > > Sent: Friday, August 22, 2014 12:25:52 AM > > > Subject: Re: [ovirt-devel] [ENGINE] thoughts about LinqUtils > > > > > > On 08/21/2014 09:55 AM, Yair Zaslavsky wrote: > > > > > > > > > > > > - Original Message - > > > >> From: "Yevgeny Zaspitsky" > > > >> To: "Yair Zaslavsky" > > > >> Cc: "Moti Asayag" , "Allon Mureinik" > > > >> , devel@ovirt.org > > > >> Sent: Thursday, August 21, 2014 4:35:33 PM > > > >> Subject: Re: [ovirt-devel] [ENGINE] thoughts about LinqUtils > > > >> > > > >> On 21/08/14 12:08, Yair Zaslavsky wrote: > > > >>> > > > >>> - Original Message - > > > >>>> From: "Yevgeny Zaspitsky" > > > >>>> To: "Moti Asayag" > > > >>>> Cc: "Yair Zaslavsky" , "Allon Mureinik" > > > >>>> , devel@ovirt.org > > > >>>> Sent: Thursday, August 21, 2014 11:26:40 AM > > > >>>> Subject: Re: [ovirt-devel] [ENGINE] thoughts about LinqUtils > > > >>>> > > > >>>> It seems like we can try moving to common-collections4. Yum on my > > > >>>> Fedora20 > > > >>>> computer finds apache-commons-collections4 package. Fortunately > > > >>>> somebody > > > >>>> packed the jar into for a rpm for us. :-) > > > >>> What about RHEL 6.5? Can you please run a quick check? > > > >> Unfortunately my happiness was too hasty. Only Fedora people care to > > > >> be > > > >> in the forward of the technology... The RHEL ones do not care about > > > >> that... > > > > > > > > This is what I remembered. When you responded to the email for the > > > > first > > > > time , I had a strong deja vu that you tried addressing this issue > > > > yourself in the past (commons-collectios4) - due to different reason. > > > > > > > > > > is there a specific conflict or problem (or a huge chain of dependencies) > > > ? > > > > To me it seems the answer to both is no - > > > > This is the requirement list - > > > > java >= 1.5 > > jpackage-utils > > rpmlib(CompressedFileNames) <= 3.0.4-1 > > rpmlib(FileDigests) <= 4.6.0-1 > > rpmlib(PayloadFilesHavePrefix) <= 4.0-1 > > rpmlib(PayloadIsXz) <= 5.2-1 > > > > > > Probably a matter of packaging? > > IIRC, Alon was the one who replied, and the issue was that Jboss included an > old version (and we don't have classpath isolation, I guess) > > Greg > We would like to avoid maintaining and package components that are not provider either by el6 or jboss distribution. But based on other threads, it seems that I am the only one who remained trying to push compliance to the old ways, people feel that can maintain anything anywhere with no effort. Regards, Alon ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [URGENT][ACTION REQUIRED] vdsm-jsonrpc-java is not building on el6 and fc20
- Original Message - > From: "Sandro Bonazzola" > To: devel@ovirt.org, "infra" > Sent: Tuesday, August 19, 2014 10:34:56 AM > Subject: [ovirt-devel] [URGENT][ACTION REQUIRED] vdsm-jsonrpc-java is not > building on el6 and fc20 > > Hi, > vdsm-jsonrpc-java is not building on el6 and fc20. See: > > - > http://jenkins.ovirt.org/job/vdsm-jsonrpc-java_master_create-rpms-el6-x86_64_merged/ > - > http://jenkins.ovirt.org/job/vdsm-jsonrpc-java_master_create-rpms-fc20-x86_64_merged/ > > Please fix it as soon as possible, thanks. Saggi is aware of this. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] What does your oVirt development environment look like?
- Original Message - > From: "Adam Litke" > To: "Yair Zaslavsky" > Cc: devel@ovirt.org > Sent: Friday, August 15, 2014 11:17:05 PM > Subject: Re: [ovirt-devel] What does your oVirt development environment look > like? > > On 15/08/14 15:57 -0400, Yair Zaslavsky wrote: > > > > > >- Original Message - > >> From: "ybronhei" > >> To: "Adam Litke" , devel@ovirt.org > >> Sent: Friday, August 15, 2014 7:36:23 PM > >> Subject: Re: [ovirt-devel] What does your oVirt development environment > >> look like? > >> > >> On 08/15/2014 09:32 AM, Adam Litke wrote: > >> > Ever since starting to work on oVirt around 3 years ago I've been > >> > striving for the perfect development and test environment. I was > >> > inspired by Yaniv's recent deep dive on Foreman integration and > >> > thought I'd ask people to share their setups and any tips and tricks > >> > so we can all become better, more efficient developers. > >> > > >> > My setup consists of my main work laptop and two mini-Dell servers. I > >> > run the engine on my laptop and I serve NFS and iSCSI (using > >> > targetcli) from this system as well. I use the ethernet port on the > >> > laptop to connect it to a subnet with the two Dell systems. > >> > > >> > Some goals for my setup are: > >> > - Easy provisioning of the virt-hosts so I can quickly test on Fedora > >> >and CentOS without spending lots of time reinstalling > >> > - Ability to test block and nfs storage > >> > - Automation of test scenarios involving engine and hosts > >> > > >> > To help me reach these goals I've deployed cobbler on my laptop and it > >> > does a pretty good job at managing PXE boot configurations for my > >> > hosts (and VMs) so they can be automatically intalled as needed. > >> > After viewing Yaniv's presentation, it seems that Forman/Puppet are > >> > the way of the future but it does seem a bit more involved to set up. > >> > I am definitely curious if others are using Foreman in their personal > >> > dev/test environment and can offer some insight on how that is working > >> > out. > >> > > >> > Thanks, and I look forward to reading about more of your setups! If > >> > we get enough of these, maybe this could make a good section of the > >> > wiki. > >> > > >> Heppy to hear :) for those who missed - > >> https://www.youtube.com/watch?v=gozX891kYAY > >> > >> each one has its own needs and goals I guess, but if you say it might > >> help, I'll never say no for sharing :P > >> I have 3 dells under my desk, I compile the engine a lot and its heavy > >> for my laptop. So I clone my local working directory and build it on the > >> strongest mini-dell using local jenkins server > >> (http://www.ovirt.org/Local_Jenkins_For_The_People). The other 2 I use > >> as hypervisor when needed. provision them is done by me manually :/.. > >> cobbler pxe boot could help with already defined image.. Other then > >> that, I have nfs mount for storage and few vms for compilation and small > >> tests > > > >Haven't used "Jenkins for the people" for quite some time, it's > >awesome though. Yaniv, does your Jenkins build all your local > >branches? I don't have much to share, my environment is even > >simpler. I am sure it's a common knowledge but still a reminder > >(even if a new developer can benefit from it, it will be good) - you > >can create a database schema per each branch you work on, and if > >needed to switch between branches, you don't have to destroy your > >current database. Quite helpful, I must say , for someone who works > >100% on engine related stuff. > > Thanks for sharing... How do you manage your multiple db schemas? > Just with the engine-backup and engine-restore commands? just create N empty databases, install each environment to different PREFIX and when running engine-setup select one for each environment. refer to README.developer at engine repo. BTW: with proper listen ports customization, you can even have N engine instances running at same machine at same time. Alon ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] can't install any host on latest master -- otopi errors / NPE
If you are using master devenv you should enable the master-snapshots repo and update all components. In your case you do not have the latest ovirt-host-deploy (you probably have 1.2 instead of 1.3). Unlike production, the devenv has no automatic dependency enforcement. - Original Message - > From: "Greg Sheremeta" > To: devel@ovirt.org > Cc: "Alon Bar-Lev" > Sent: Wednesday, August 6, 2014 12:52:57 AM > Subject: Re: [ovirt-devel] can't install any host on latest master -- otopi > errors / NPE > > > > - Original Message - > > From: "Greg Sheremeta" > > To: devel@ovirt.org > > Sent: Tuesday, August 5, 2014 5:42:46 PM > > Subject: [ovirt-devel] can't install any host on latest master -- otopi > > errors / NPE > > > > Hi, > > > > I can't install any host on latest master (fresh database, fresh install). > > I tried using both latest ovirt node and host-initiated install of a fresh > > f19 machine. > > > > Engine log shows NPEs. Host log has otopi errors. Both attached. > > > > Any ideas? > > > > greg@dauntless:~/ovirt-engine/var/log/ovirt-engine$ yum list installed > > otopi > > Installed Packages > > otopi.noarch > > 1.2.0-0.4.master.20140226.gita0f037f.fc20 > > @ovirt-nightly > > I updated otopi and still have the issue. > > otopi.noarch 1.3.0-0.0.master.20140728.git336a22e.fc20 @ovirt-snapshots > > > > > > greg@dauntless:~/ovirt-engine/var/log/ovirt-engine$ sudo yum update otopi > > No packages marked for update > > greg@dauntless:~/ovirt-engine/var/log/ovirt-engine$ > > > > > > Greg Sheremeta > > Red Hat, Inc. > > Sr. Software Engineer, RHEV > > Cell: 919-807-1086 > > gsher...@redhat.com > > > > ___ > > 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] [TEST-REQUEST] New LDAP implementation for ovirt-engine
Hello All, If you are brave enough to test ovirt-engine betas, and you are using or like to use LDAP integration - you can assist us. Within the 3.4/3.5 cycle we have done major rework on the entire authentication, authorization and accounting or in short AAA, the 3.5.0_rc1 is ready to be tested. I will appreciate any feedback and help perfecting the solution. The implementation is the first pluggable implementation of the backend, this means that we can extend the functionality without rebuilding the engine, even implementations that are not LDAP based can be added. The new LDAP implementation is a backend extension that is called ovirt-engine-extension-aaa-ldap[1], documentation is available[2][3][4], there is no upgrade path between the legacy implementation and the new implementation, users of legacy implementation can continue to use it as-is without enjoying the new features. Unlike the legacy implementation, the new implementation is pure LDAP implementation, no kerberos and special DNS settings are required. It also supports customization to enable support complex/foreign LDAP sources. It also supports multi domain forest of Active Directory, performance improvements, fallback policy, security and more. Configuration is file based, the engine-manage-domains utility is obsolete. Examples are available at [2]. First install the extension[5]: # yum install ovirt-engine-extension-aaa-ldap A simple active directory configuration is per the following, make sure you define seaerchuser with valid password within the ldap to be used to search for user information during interaction. Other directories that are supported are: OpenLDAP, IPA, RHDS please refer to documentation. --- Authorization settings - used post authentication to fetch user's attributes and groups. /etc/ovirt-enigne/extensions.d/authz-company.properties --- ovirt.engine.extension.name = authz-company ovirt.engine.extension.bindings.method = jbossmodule ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine-extensions.aaa.ldap ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engineextensions.aaa.ldap.AuthzExtension ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz config.profile.file.1 = /etc/ovirt-engine/aaa/company.properties --- --- Authentication settings - user is resolved using search then LDAP bind is used to validate password. /etc/ovirt-enigne/extensions.d/authn-company.properties --- ovirt.engine.extension.name = authn-company ovirt.engine.extension.bindings.method = jbossmodule ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine-extensions.aaa.ldap ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engineextensions.aaa.ldap.AuthnExtension ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn ovirt.engine.aaa.authn.profile.name = company.com ovirt.engine.aaa.authn.authz.plugin = authz-company config.profile.file.1 = /etc/ovirt-engine/aaa/company.properties --- --- Common profile customization for company.com domain /etc/ovirt-engine/aaa/company.properties --- include = pool.default.serverset.type = srvrecord pool.default.serverset.srvrecord.domain = company.com pool.default.auth.simple.bindDN = searchuser pool.default.auth.simple.password = 123456 --- Regards, Alon Bar-Lev [1] http://gerrit.ovirt.org/gitweb?p=ovirt-engine-extension-aaa-ldap.git [2] http://gerrit.ovirt.org/gitweb?p=ovirt-engine-extension-aaa-ldap.git;a=blob;f=README;hb=HEAD [3] http://gerrit.ovirt.org/gitweb?p=ovirt-engine-extension-aaa-ldap.git;a=blob;f=README.unboundid-ldapsdk;hb=HEAD [4] http://gerrit.ovirt.org/gitweb?p=ovirt-engine-extension-aaa-ldap.git;a=blob;f=README.profile;hb=HEAD [5] http://resources.ovirt.org/pub/ovirt-3.5-pre/rpm/ ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] master fails tests VmStatisticsTest
Hi, This happens on jenkins only, local build is ok. The strange thing is that I cannot find VmStatisticsTest in sources... Anyone? Alon 18:35:35 Tests in error: 18:35:35 addToHistory_nullBefore(org.ovirt.engine.core.common.businessentities.VmStatisticsTest): org.ovirt.engine.core.common.businessentities.VmStatistics.addToHistory(Ljava/util/List;Ljava/lang/Integer;I)Ljava/util/List; 18:35:35 addToHistory_oneValueBefore(org.ovirt.engine.core.common.businessentities.VmStatisticsTest): org.ovirt.engine.core.common.businessentities.VmStatistics.addToHistory(Ljava/util/List;Ljava/lang/Integer;I)Ljava/util/List; 18:35:35 addToHistory_addingNull(org.ovirt.engine.core.common.businessentities.VmStatisticsTest): org.ovirt.engine.core.common.businessentities.VmStatistics.addToHistory(Ljava/util/List;Ljava/lang/Integer;I)Ljava/util/List; 18:35:35 addToHistory_emptyBefore(org.ovirt.engine.core.common.businessentities.VmStatisticsTest): org.ovirt.engine.core.common.businessentities.VmStatistics.addToHistory(Ljava/util/List;Ljava/lang/Integer;I)Ljava/util/List; 18:35:35 addToHistory_zeroLimit(org.ovirt.engine.core.common.businessentities.VmStatisticsTest): org.ovirt.engine.core.common.businessentities.VmStatistics.addToHistory(Ljava/util/List;Ljava/lang/Integer;I)Ljava/util/List; 18:35:35 addToHistory_exaclyTheLimit(org.ovirt.engine.core.common.businessentities.VmStatisticsTest): org.ovirt.engine.core.common.businessentities.VmStatistics.addToHistory(Ljava/util/List;Ljava/lang/Integer;I)Ljava/util/List; 18:35:35 addToHistory_twoOverLimitValuesBefore(org.ovirt.engine.core.common.businessentities.VmStatisticsTest): org.ovirt.engine.core.common.businessentities.VmStatistics.addToHistory(Ljava/util/List;Ljava/lang/Integer;I)Ljava/util/List; 18:35:35 addToHistory_twoValuesBefore(org.ovirt.engine.core.common.businessentities.VmStatisticsTest): org.ovirt.engine.core.common.businessentities.VmStatistics.addToHistory(Ljava/util/List;Ljava/lang/Integer;I)Ljava/util/List; 18:35:35 addToHistory_oneOverLimitValuesBefore(org.ovirt.engine.core.common.businessentities.VmStatisticsTest): org.ovirt.engine.core.common.businessentities.VmStatistics.addToHistory(Ljava/util/List;Ljava/lang/Integer;I)Ljava/util/List; 18:35:35 addToHistory_oneLimit(org.ovirt.engine.core.common.businessentities.VmStatisticsTest): org.ovirt.engine.core.common.businessentities.VmStatistics.addToHistory(Ljava/util/List;Ljava/lang/Integer;I)Ljava/util/List; ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] UI plugins - talking with Engine via JSESSIONID now requires separate request header
- Original Message - > From: "Juan Hernandez" > To: "Alon Bar-Lev" , "Vojtech Szocs" > Cc: devel@ovirt.org > Sent: Thursday, July 24, 2014 10:31:12 AM > Subject: Re: [ovirt-devel] UI plugins - talking with Engine via JSESSIONID > now requires separate request header > > On 07/24/2014 08:13 AM, Alon Bar-Lev wrote: > > > > > > ----- Original Message - > >> From: "Vojtech Szocs" > >> To: "Alon Bar-Lev" , "Juan Antonio Hernandez Fernandez" > >> > >> Cc: devel@ovirt.org > >> Sent: Tuesday, July 15, 2014 9:46:52 PM > >> Subject: Re: [ovirt-devel] UI plugins - talking with Engine via JSESSIONID > >> now requires separate request header > >> > >> > >> > >> - Original Message - > >>> From: "Alon Bar-Lev" > >>> To: "Vojtech Szocs" > >>> Cc: devel@ovirt.org, "Oved Ourfalli" > >>> Sent: Tuesday, July 15, 2014 8:22:06 PM > >>> Subject: Re: [ovirt-devel] UI plugins - talking with Engine via > >>> JSESSIONID > >>> now requires separate request header > >>> > >>> > >>> > >>> - Original Message ----- > >>>> From: "Vojtech Szocs" > >>>> To: "Alon Bar-Lev" > >>>> Cc: devel@ovirt.org, "Oved Ourfalli" > >>>> Sent: Tuesday, July 15, 2014 9:18:44 PM > >>>> Subject: Re: [ovirt-devel] UI plugins - talking with Engine via > >>>> JSESSIONID > >>>> now requires separate request header > >>>> > >>>> > >>>> > >>>> - Original Message - > >>>>> From: "Alon Bar-Lev" > >>>>> To: "Vojtech Szocs" > >>>>> Cc: devel@ovirt.org, "Oved Ourfalli" , "René Koch" > >>>>> > >>>>> Sent: Tuesday, July 15, 2014 7:47:35 PM > >>>>> Subject: Re: [ovirt-devel] UI plugins - talking with Engine via > >>>>> JSESSIONID > >>>>> now requires separate request header > >>>>> > >>>>> > >>>>> > >>>>> - Original Message - > >>>>>> From: "Vojtech Szocs" > >>>>>> To: "Alon Bar-Lev" > >>>>>> Cc: devel@ovirt.org, "Oved Ourfalli" , "René Koch" > >>>>>> > >>>>>> Sent: Tuesday, July 15, 2014 8:40:30 PM > >>>>>> Subject: Re: [ovirt-devel] UI plugins - talking with Engine via > >>>>>> JSESSIONID > >>>>>> now requires separate request header > >>>>>> > >>>>>> > >>>>>> > >>>>>> - Original Message - > >>>>>>> From: "Alon Bar-Lev" > >>>>>>> To: "Vojtech Szocs" > >>>>>>> Cc: devel@ovirt.org, "Oved Ourfalli" , "René > >>>>>>> Koch" > >>>>>>> > >>>>>>> Sent: Tuesday, July 15, 2014 7:17:40 PM > >>>>>>> Subject: Re: [ovirt-devel] UI plugins - talking with Engine via > >>>>>>> JSESSIONID > >>>>>>> now requires separate request header > >>>>>>> > >>>>>>> > >>>>>>> Can we have X-OVIRT-SESSIONID header name or any generic term and > >>>>>>> per > >>>>>>> ovirt > >>>>>>> specific instead of generic java terms? > >>>>>> > >>>>>> Good question. In general I agree, JavaEE's default "JSESSIONID" > >>>>>> naming > >>>>>> convention for custom header (or cookie) is not very meaningful in > >>>>>> multi > >>>>>> app deployment. > >>>>>> > >>>>>> However, I'd rather avoid "X-" prefix [1]. > >>>>>> > >>>>>> [1] > >>>>>> http://stackoverflow.com/questions/3561381/custom-http-headers-naming-conventions > >>>>>> > >>>>>> Currently, it is the "JSESSIONID" cookie which maps to the session. > >>>>>> Currently, "JSESSIONID
Re: [ovirt-devel] [ovirt-users] [ANN] oVirt 3.5.0 Second Beta is now available for testing
- Original Message - > From: "Sandro Bonazzola" > To: "Alon Bar-Lev" > Cc: devel@ovirt.org > Sent: Thursday, July 24, 2014 9:42:05 AM > Subject: Re: [ovirt-users] [ANN] oVirt 3.5.0 Second Beta is now available for > testing > > Il 23/07/2014 18:49, Alon Bar-Lev ha scritto: > > > > > > - Original Message - > >> From: "Sandro Bonazzola" > >> To: "Alon Bar-Lev" > >> Cc: devel@ovirt.org > >> Sent: Wednesday, July 23, 2014 7:07:22 PM > >> Subject: Re: [ovirt-users] [ANN] oVirt 3.5.0 Second Beta is now available > >> fortesting > >> > >> Il 23/07/2014 17:57, Alon Bar-Lev ha scritto: > >>> > >>> This is one week old software. > >>> People will not be able to check fixes that were introduced this week. > >>> Please issue snapshot before the test day. > >> > >> I'm not sure about what you're referring to. Most of the packages are from > >> this morning publisher job. > >> http://jenkins.ovirt.org/view/Publishers/job/publish_ovirt_rpms_nightly_3.5/28/console > >> packages not taken from there are taken from build provided by > >> maintainers. > >> > >> Can you detail what's so old in this release? > >> Thanks. > >> > > > > I look at the tag: ovirt-engine-3.5.0_beta2 > > 8e1babcc5512e228336989dd34a601982af11834 > > > > Date: Mon Jul 21 09:18:39 2014 -0400 > > > > Until Tue Jul 29th it will be more than two week old version. > > > > Isn't this the right tag? > > > > $ git log --oneline 8e1babcc5512e228336989dd34a601982af11834..HEAD | wc -l > > 21 > > > > well, the publisher job took the latest available build which was: > > http://jenkins.ovirt.org/job/ovirt-engine_3.5_create-rpms_merged/label=centos6-host/60/ > completed yesterday morning at 02:21:12 AM taking sources from > 8e1babcc5512e228336989dd34a601982af11834. > All remaining patches were not included in that build. The build has been > done 16 hours before the official announce by jenkins. > > We needed to test it for basic sanity. > We just can't announce a beta including packages with patches just merged > without any kind of test on it. > If you want a bleeding edge build without any sanity test on it, you're > welcome to use daily 3.5 snapshot. > That's why we have it. > it has nothing to do with bleeding edge... it is about asking subsystem maintainers if a tag is stable, instead of taking random. for example: 6b9f795b0785fad1598cdddfed83cd9861bc4d71, fb7172bba8f729161694c584cec3a9e3d6989d97, 03dbc8bdb68600108a3befbfb819d422065a77ef infra would have probably nak beta at this hash. > > > >> > >> > >> > >> > >>> > >>> - Original Message - > >>>> From: "Sandro Bonazzola" > >>>> To: annou...@ovirt.org, us...@ovirt.org, devel@ovirt.org > >>>> Sent: Wednesday, July 23, 2014 6:49:42 PM > >>>> Subject: [ovirt-users] [ANN] oVirt 3.5.0 Second Beta is now available > >>>> for > >>>> testing > >>>> > >>>> The oVirt team is pleased to announce that the 3.5.0 Second Beta is now > >>>> available for testing as of Jul 21th 2014. > >>>> > >>>> The beta is available now for Fedora 19, Fedora 20 and Red Hat > >>>> Enterprise > >>>> Linux 6.5 > >>>> (or similar). > >>>> > >>>> Feel free to join us testing it on Tue Jul 29th second test day! > >>>> > >>>> This release of oVirt includes numerous bug fixes. > >>>> See the release notes [1] for a list of the new features and bugs fixed. > >>>> > >>>> The existing repository ovirt-3.5-pre has been updated for delivering > >>>> this > >>>> release without the need of enabling any other repository. > >>>> > >>>> Please refer to release notes [1] for Installation / Upgrade > >>>> instructions. > >>>> New oVirt Live, oVirt Guest Tools and oVirt Node ISO will be available > >>>> soon > >>>> as well[2]. > >>>> > >>>> Please note that mirrors may need a couple of days before being > >>>> synchronized. > >>>> If you want to be sure to use latest rpms and don't want to wait for the > >>>> mirrors, > >>>> you can edit /etc/yum.repos.d/ovirt-3.5.repo commenting the mirror line > >>>> and > >>>> removing the comment on baseurl line. > >>>> > >>>> [1] http://www.ovirt.org/OVirt_3.5_Release_Notes > >>>> [2] http://resources.ovirt.org/pub/ovirt-3.5-pre/iso/ > >>>> > >>>> -- > >>>> Sandro Bonazzola > >>>> Better technology. Faster innovation. Powered by community > >>>> collaboration. > >>>> See how it works at redhat.com > >>>> ___ > >>>> Users mailing list > >>>> us...@ovirt.org > >>>> http://lists.ovirt.org/mailman/listinfo/users > >>>> > >> > >> > >> -- > >> Sandro Bonazzola > >> Better technology. Faster innovation. Powered by community collaboration. > >> See how it works at redhat.com > >> > > > -- > 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] UI plugins - talking with Engine via JSESSIONID now requires separate request header
- Original Message - > From: "Vojtech Szocs" > To: "Alon Bar-Lev" , "Juan Antonio Hernandez Fernandez" > > Cc: devel@ovirt.org > Sent: Tuesday, July 15, 2014 9:46:52 PM > Subject: Re: [ovirt-devel] UI plugins - talking with Engine via JSESSIONID > now requires separate request header > > > > - Original Message - > > From: "Alon Bar-Lev" > > To: "Vojtech Szocs" > > Cc: devel@ovirt.org, "Oved Ourfalli" > > Sent: Tuesday, July 15, 2014 8:22:06 PM > > Subject: Re: [ovirt-devel] UI plugins - talking with Engine via JSESSIONID > > now requires separate request header > > > > > > > > - Original Message - > > > From: "Vojtech Szocs" > > > To: "Alon Bar-Lev" > > > Cc: devel@ovirt.org, "Oved Ourfalli" > > > Sent: Tuesday, July 15, 2014 9:18:44 PM > > > Subject: Re: [ovirt-devel] UI plugins - talking with Engine via > > > JSESSIONID > > > now requires separate request header > > > > > > > > > > > > - Original Message - > > > > From: "Alon Bar-Lev" > > > > To: "Vojtech Szocs" > > > > Cc: devel@ovirt.org, "Oved Ourfalli" , "René Koch" > > > > > > > > Sent: Tuesday, July 15, 2014 7:47:35 PM > > > > Subject: Re: [ovirt-devel] UI plugins - talking with Engine via > > > > JSESSIONID > > > > now requires separate request header > > > > > > > > > > > > > > > > - Original Message - > > > > > From: "Vojtech Szocs" > > > > > To: "Alon Bar-Lev" > > > > > Cc: devel@ovirt.org, "Oved Ourfalli" , "René Koch" > > > > > > > > > > Sent: Tuesday, July 15, 2014 8:40:30 PM > > > > > Subject: Re: [ovirt-devel] UI plugins - talking with Engine via > > > > > JSESSIONID > > > > > now requires separate request header > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > From: "Alon Bar-Lev" > > > > > > To: "Vojtech Szocs" > > > > > > Cc: devel@ovirt.org, "Oved Ourfalli" , "René > > > > > > Koch" > > > > > > > > > > > > Sent: Tuesday, July 15, 2014 7:17:40 PM > > > > > > Subject: Re: [ovirt-devel] UI plugins - talking with Engine via > > > > > > JSESSIONID > > > > > > now requires separate request header > > > > > > > > > > > > > > > > > > Can we have X-OVIRT-SESSIONID header name or any generic term and > > > > > > per > > > > > > ovirt > > > > > > specific instead of generic java terms? > > > > > > > > > > Good question. In general I agree, JavaEE's default "JSESSIONID" > > > > > naming > > > > > convention for custom header (or cookie) is not very meaningful in > > > > > multi > > > > > app deployment. > > > > > > > > > > However, I'd rather avoid "X-" prefix [1]. > > > > > > > > > > [1] > > > > > http://stackoverflow.com/questions/3561381/custom-http-headers-naming-conventions > > > > > > > > > > Currently, it is the "JSESSIONID" cookie which maps to the session. > > > > > Currently, "JSESSIONID" custom header is only for CSRF-protection, > > > > > i.e. to be compared with cookie value (cookie is still required in > > > > > order to reuse existing session). > > > > > > > > > > AFAIK, Juan plans to support passing session ID via custom HTTP > > > > > header, as an alternative to passing session ID via cookie. When > > > > > this gets done, the custom HTTP header should be named something > > > > > like "OVIRT-SESSIONID". > > > > > > > > I do not see any reason why not to use this (or any other non > > > > JSESSIONID) > > > > name for header now. > > > > > > Yes, we could also change it now, because JSESSIONID header was > > > introduced only recently by http://gerrit.ovirt.org/#/c/29681/ > > > >
Re: [ovirt-devel] [ovirt-users] [ANN] oVirt 3.5.0 Second Beta is now available for testing
- Original Message - > From: "Sandro Bonazzola" > To: "Alon Bar-Lev" > Cc: devel@ovirt.org > Sent: Wednesday, July 23, 2014 7:07:22 PM > Subject: Re: [ovirt-users] [ANN] oVirt 3.5.0 Second Beta is now available for > testing > > Il 23/07/2014 17:57, Alon Bar-Lev ha scritto: > > > > This is one week old software. > > People will not be able to check fixes that were introduced this week. > > Please issue snapshot before the test day. > > I'm not sure about what you're referring to. Most of the packages are from > this morning publisher job. > http://jenkins.ovirt.org/view/Publishers/job/publish_ovirt_rpms_nightly_3.5/28/console > packages not taken from there are taken from build provided by maintainers. > > Can you detail what's so old in this release? > Thanks. > I look at the tag: ovirt-engine-3.5.0_beta2 8e1babcc5512e228336989dd34a601982af11834 Date: Mon Jul 21 09:18:39 2014 -0400 Until Tue Jul 29th it will be more than two week old version. Isn't this the right tag? $ git log --oneline 8e1babcc5512e228336989dd34a601982af11834..HEAD | wc -l 21 > > > > > > > > - Original Message - > >> From: "Sandro Bonazzola" > >> To: annou...@ovirt.org, us...@ovirt.org, devel@ovirt.org > >> Sent: Wednesday, July 23, 2014 6:49:42 PM > >> Subject: [ovirt-users] [ANN] oVirt 3.5.0 Second Beta is now available for > >>testing > >> > >> The oVirt team is pleased to announce that the 3.5.0 Second Beta is now > >> available for testing as of Jul 21th 2014. > >> > >> The beta is available now for Fedora 19, Fedora 20 and Red Hat Enterprise > >> Linux 6.5 > >> (or similar). > >> > >> Feel free to join us testing it on Tue Jul 29th second test day! > >> > >> This release of oVirt includes numerous bug fixes. > >> See the release notes [1] for a list of the new features and bugs fixed. > >> > >> The existing repository ovirt-3.5-pre has been updated for delivering this > >> release without the need of enabling any other repository. > >> > >> Please refer to release notes [1] for Installation / Upgrade instructions. > >> New oVirt Live, oVirt Guest Tools and oVirt Node ISO will be available > >> soon > >> as well[2]. > >> > >> Please note that mirrors may need a couple of days before being > >> synchronized. > >> If you want to be sure to use latest rpms and don't want to wait for the > >> mirrors, > >> you can edit /etc/yum.repos.d/ovirt-3.5.repo commenting the mirror line > >> and > >> removing the comment on baseurl line. > >> > >> [1] http://www.ovirt.org/OVirt_3.5_Release_Notes > >> [2] http://resources.ovirt.org/pub/ovirt-3.5-pre/iso/ > >> > >> -- > >> Sandro Bonazzola > >> Better technology. Faster innovation. Powered by community collaboration. > >> See how it works at redhat.com > >> ___ > >> Users mailing list > >> us...@ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/users > >> > > > -- > 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-users] [ANN] oVirt 3.5.0 Second Beta is now available for testing
This is one week old software. People will not be able to check fixes that were introduced this week. Please issue snapshot before the test day. - Original Message - > From: "Sandro Bonazzola" > To: annou...@ovirt.org, us...@ovirt.org, devel@ovirt.org > Sent: Wednesday, July 23, 2014 6:49:42 PM > Subject: [ovirt-users] [ANN] oVirt 3.5.0 Second Beta is now available for > testing > > The oVirt team is pleased to announce that the 3.5.0 Second Beta is now > available for testing as of Jul 21th 2014. > > The beta is available now for Fedora 19, Fedora 20 and Red Hat Enterprise > Linux 6.5 > (or similar). > > Feel free to join us testing it on Tue Jul 29th second test day! > > This release of oVirt includes numerous bug fixes. > See the release notes [1] for a list of the new features and bugs fixed. > > The existing repository ovirt-3.5-pre has been updated for delivering this > release without the need of enabling any other repository. > > Please refer to release notes [1] for Installation / Upgrade instructions. > New oVirt Live, oVirt Guest Tools and oVirt Node ISO will be available soon > as well[2]. > > Please note that mirrors may need a couple of days before being synchronized. > If you want to be sure to use latest rpms and don't want to wait for the > mirrors, > you can edit /etc/yum.repos.d/ovirt-3.5.repo commenting the mirror line and > removing the comment on baseurl line. > > [1] http://www.ovirt.org/OVirt_3.5_Release_Notes > [2] http://resources.ovirt.org/pub/ovirt-3.5-pre/iso/ > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > ___ > Users mailing list > us...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] vdsm-jsonrpc-java failing builds on el6
- Original Message - > From: "Piotr Kliczewski" > To: "Alon Bar-Lev" > Cc: "Sandro Bonazzola" , "Saggi Mizrahi" > , devel@ovirt.org > Sent: Friday, July 18, 2014 8:01:39 PM > Subject: Re: [ovirt-devel] vdsm-jsonrpc-java failing builds on el6 > > > > > > - Original Message - > > From: "Alon Bar-Lev" > > To: "Sandro Bonazzola" , "Piotr Kliczewski" > > > > Cc: "Saggi Mizrahi" , devel@ovirt.org > > Sent: Friday, July 18, 2014 6:19:05 PM > > Subject: Re: [ovirt-devel] vdsm-jsonrpc-java failing builds on el6 > > > > > > > > - Original Message - > > > From: "Sandro Bonazzola" > > > To: "Alon Bar-Lev" > > > Cc: "Piotr Kliczewski" , "Saggi Mizrahi" > > > , devel@ovirt.org > > > Sent: Friday, July 18, 2014 7:11:43 PM > > > Subject: Re: [ovirt-devel] vdsm-jsonrpc-java failing builds on el6 > > > > > > Il 18/07/2014 17:59, Alon Bar-Lev ha scritto: > > > > > > > > > > > > - Original Message - > > > >> From: "Sandro Bonazzola" > > > >> To: "Piotr Kliczewski" , "Saggi Mizrahi" > > > >> , devel@ovirt.org > > > >> Sent: Friday, July 18, 2014 6:34:32 PM > > > >> Subject: [ovirt-devel] vdsm-jsonrpc-java failing builds on el6 > > > >> > > > >> Hi, > > > >> we'll have 3.5 beta 2 on Monday and vdsm-jsonrpc-java is still failing > > > >> to > > > >> build on CentOS 6[1]. > > > >> Can you please fix it? > > > > > > > > you are not building this using rpmbuild, please avoid building > > > > manually. > > > > > > Not sure about what you mean. However, > > > > > > # cat /etc/system-release > > > CentOS release 6.5 (Final) > > > > > > # git clone git://gerrit.ovirt.org/vdsm-jsonrpc-java > > > # cd vdsm-jsonrpc-java/ > > > # ./autogen.sh > > > # ./configure > > > # make dist > > > # rpmbuild -ta vdsm-jsonrpc-java-1.0.0_master.tar.gz > > > error: Failed build dependencies: > > > codehaus-jackson-core-asl is needed by > > > vdsm-jsonrpc-java-1.0.0-0.0.master.el6.noarch > > > codehaus-jackson-mapper-asl is needed by > > > vdsm-jsonrpc-java-1.0.0-0.0.master.el6.noarch > > > > > > > > > Looking at http://gerrit.ovirt.org/28974 > > > above deps shouldn't be there. > > > > > > spec changelog say: > > > * Tue Jun 24 2014 Piotr Kliczewski 1.0.1 > > > - Make jackson dependency conditional for rhel and centos > > > > > > but tarball generated is still 1.0.0. > > > > yes, there is problem with maintainers to understand the release management > > within master, I already explain that one many times. > > 1. tag name should be PACKAGE-VERSION > > 2. post release must increment version and have pre-release rpm release > > > > > so also rpmbuild fails. > > > > yes, this error is right. > > > > piotr the following should also be conditioned: > > > > BuildRequires:» codehaus-jackson-core-asl > > BuildRequires:» codehaus-jackson-mapper-asl > > > > I though that we agreed to use maven to build for centos and fedora. For rhel > we agreed > to use brew. In this situation when maven is used the build time dependencies > are not > checked. Am I missing something? if you specify something in spec, it is checked... we use maven so we download these during build (violation of spec) because there is no package. this means we cannot specify these as dependencies in spec. > > > > > > jenkins uses mock after building src.rpm from tar.gz and mock just > > > provide > > > build requirements and then rpmbuild the src.rpm > > > > you cannot build using mock this package for centos, dcaro already aware of > > this, because of missing build time dependencies which are available at > > runtime, so instead of package these, we just use maven to download them. > > > > Thanks! > > > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] vdsm-jsonrpc-java failing builds on el6
- Original Message - > From: "Sandro Bonazzola" > To: "Alon Bar-Lev" > Cc: "Piotr Kliczewski" , "Saggi Mizrahi" > , devel@ovirt.org > Sent: Friday, July 18, 2014 7:11:43 PM > Subject: Re: [ovirt-devel] vdsm-jsonrpc-java failing builds on el6 > > Il 18/07/2014 17:59, Alon Bar-Lev ha scritto: > > > > > > - Original Message - > >> From: "Sandro Bonazzola" > >> To: "Piotr Kliczewski" , "Saggi Mizrahi" > >> , devel@ovirt.org > >> Sent: Friday, July 18, 2014 6:34:32 PM > >> Subject: [ovirt-devel] vdsm-jsonrpc-java failing builds on el6 > >> > >> Hi, > >> we'll have 3.5 beta 2 on Monday and vdsm-jsonrpc-java is still failing to > >> build on CentOS 6[1]. > >> Can you please fix it? > > > > you are not building this using rpmbuild, please avoid building manually. > > Not sure about what you mean. However, > > # cat /etc/system-release > CentOS release 6.5 (Final) > > # git clone git://gerrit.ovirt.org/vdsm-jsonrpc-java > # cd vdsm-jsonrpc-java/ > # ./autogen.sh > # ./configure > # make dist > # rpmbuild -ta vdsm-jsonrpc-java-1.0.0_master.tar.gz > error: Failed build dependencies: > codehaus-jackson-core-asl is needed by > vdsm-jsonrpc-java-1.0.0-0.0.master.el6.noarch > codehaus-jackson-mapper-asl is needed by > vdsm-jsonrpc-java-1.0.0-0.0.master.el6.noarch > > > Looking at http://gerrit.ovirt.org/28974 > above deps shouldn't be there. > > spec changelog say: > * Tue Jun 24 2014 Piotr Kliczewski 1.0.1 > - Make jackson dependency conditional for rhel and centos > > but tarball generated is still 1.0.0. yes, there is problem with maintainers to understand the release management within master, I already explain that one many times. 1. tag name should be PACKAGE-VERSION 2. post release must increment version and have pre-release rpm release > so also rpmbuild fails. yes, this error is right. piotr the following should also be conditioned: BuildRequires:» codehaus-jackson-core-asl BuildRequires:» codehaus-jackson-mapper-asl > jenkins uses mock after building src.rpm from tar.gz and mock just provide > build requirements and then rpmbuild the src.rpm you cannot build using mock this package for centos, dcaro already aware of this, because of missing build time dependencies which are available at runtime, so instead of package these, we just use maven to download them. Thanks! ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] vdsm-jsonrpc-java failing builds on el6
- Original Message - > From: "Sandro Bonazzola" > To: "Piotr Kliczewski" , "Saggi Mizrahi" > , devel@ovirt.org > Sent: Friday, July 18, 2014 6:34:32 PM > Subject: [ovirt-devel] vdsm-jsonrpc-java failing builds on el6 > > Hi, > we'll have 3.5 beta 2 on Monday and vdsm-jsonrpc-java is still failing to > build on CentOS 6[1]. > Can you please fix it? you are not building this using rpmbuild, please avoid building manually. > > http://jenkins.ovirt.org/view/Master%20branch%20per%20project/view/vdsm-jsonrpc-java/job/vdsm-jsonrpc-java_master_create-rpms-el6-x86_64_merged/ > > We'll have second test day after this build and I guess most of the people > will run CentOS / RHEL so this package must build. > Thanks, > > -- > 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 > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] UI plugins - talking with Engine via JSESSIONID now requires separate request header
- Original Message -
> From: "Vojtech Szocs"
> To: "Alon Bar-Lev"
> Cc: devel@ovirt.org, "Oved Ourfalli"
> Sent: Tuesday, July 15, 2014 9:18:44 PM
> Subject: Re: [ovirt-devel] UI plugins - talking with Engine via JSESSIONID
> now requires separate request header
>
>
>
> - Original Message -
> > From: "Alon Bar-Lev"
> > To: "Vojtech Szocs"
> > Cc: devel@ovirt.org, "Oved Ourfalli" , "René Koch"
> >
> > Sent: Tuesday, July 15, 2014 7:47:35 PM
> > Subject: Re: [ovirt-devel] UI plugins - talking with Engine via JSESSIONID
> > now requires separate request header
> >
> >
> >
> > - Original Message -
> > > From: "Vojtech Szocs"
> > > To: "Alon Bar-Lev"
> > > Cc: devel@ovirt.org, "Oved Ourfalli" , "René Koch"
> > >
> > > Sent: Tuesday, July 15, 2014 8:40:30 PM
> > > Subject: Re: [ovirt-devel] UI plugins - talking with Engine via
> > > JSESSIONID
> > > now requires separate request header
> > >
> > >
> > >
> > > - Original Message -
> > > > From: "Alon Bar-Lev"
> > > > To: "Vojtech Szocs"
> > > > Cc: devel@ovirt.org, "Oved Ourfalli" , "René Koch"
> > > >
> > > > Sent: Tuesday, July 15, 2014 7:17:40 PM
> > > > Subject: Re: [ovirt-devel] UI plugins - talking with Engine via
> > > > JSESSIONID
> > > > now requires separate request header
> > > >
> > > >
> > > > Can we have X-OVIRT-SESSIONID header name or any generic term and per
> > > > ovirt
> > > > specific instead of generic java terms?
> > >
> > > Good question. In general I agree, JavaEE's default "JSESSIONID" naming
> > > convention for custom header (or cookie) is not very meaningful in multi
> > > app deployment.
> > >
> > > However, I'd rather avoid "X-" prefix [1].
> > >
> > > [1]
> > > http://stackoverflow.com/questions/3561381/custom-http-headers-naming-conventions
> > >
> > > Currently, it is the "JSESSIONID" cookie which maps to the session.
> > > Currently, "JSESSIONID" custom header is only for CSRF-protection,
> > > i.e. to be compared with cookie value (cookie is still required in
> > > order to reuse existing session).
> > >
> > > AFAIK, Juan plans to support passing session ID via custom HTTP
> > > header, as an alternative to passing session ID via cookie. When
> > > this gets done, the custom HTTP header should be named something
> > > like "OVIRT-SESSIONID".
> >
> > I do not see any reason why not to use this (or any other non JSESSIONID)
> > name for header now.
>
> Yes, we could also change it now, because JSESSIONID header was
> introduced only recently by http://gerrit.ovirt.org/#/c/29681/
>
> However I think this is not really "Engine session ID", but rather
> "Java webapp session ID" - AFAIK, real Engine session ID is stored
> inside Java webapp session attribute - see SessionConstants
> HTTP_SESSION_ENGINE_SESSION_ID_KEY ("ovirt_aaa_engineSessionId").
>
> But we can consider real Engine session ID as impl. detail, so we
> can rename JSESSIONID to OVIRT-SESSIONID or similar.
>
> As for the cookie name, I'm not aware of any way to change it in
> JBoss. I think that even Java servlet spec says it must be called
> JSESSIONID. (But then again, in future I'd like to avoid using that
> cookie altogether, in favor of using custom OVIRT-SESSIONID header.)
>
it is not important what session id it is... it can be the jboss now and other
later, what important is that we do not change the interface in future, so that
the session id whatever it may be is set within header that is forward
compatible.
the fact that we have a cookie is nice, may have some value (or not...), but
cookie is set by server and sent by client automatically, so naming is not
important.
> >
> > >
> > > >
> > > > - Original Message -
> > > > > From: "Vojtech Szocs"
> > > > > To: devel@ovirt.org
> > > > > Cc: "Oved Ourfalli" , "René Koch"
> > > > > Sent: Tuesday, July 15, 2014 8:06:19 PM
> > > > > Subject: [ovirt-devel] UI plugins - talking with Engine via
> > > > > JSESSIONID
> > > > >
Re: [ovirt-devel] UI plugins - talking with Engine via JSESSIONID now requires separate request header
- Original Message - > From: "Vojtech Szocs" > To: "Alon Bar-Lev" > Cc: devel@ovirt.org, "Oved Ourfalli" , "René Koch" > > Sent: Tuesday, July 15, 2014 8:40:30 PM > Subject: Re: [ovirt-devel] UI plugins - talking with Engine via JSESSIONID > now requires separate request header > > > > - Original Message - > > From: "Alon Bar-Lev" > > To: "Vojtech Szocs" > > Cc: devel@ovirt.org, "Oved Ourfalli" , "René Koch" > > > > Sent: Tuesday, July 15, 2014 7:17:40 PM > > Subject: Re: [ovirt-devel] UI plugins - talking with Engine via JSESSIONID > > now requires separate request header > > > > > > Can we have X-OVIRT-SESSIONID header name or any generic term and per ovirt > > specific instead of generic java terms? > > Good question. In general I agree, JavaEE's default "JSESSIONID" naming > convention for custom header (or cookie) is not very meaningful in multi > app deployment. > > However, I'd rather avoid "X-" prefix [1]. > > [1] > http://stackoverflow.com/questions/3561381/custom-http-headers-naming-conventions > > Currently, it is the "JSESSIONID" cookie which maps to the session. > Currently, "JSESSIONID" custom header is only for CSRF-protection, > i.e. to be compared with cookie value (cookie is still required in > order to reuse existing session). > > AFAIK, Juan plans to support passing session ID via custom HTTP > header, as an alternative to passing session ID via cookie. When > this gets done, the custom HTTP header should be named something > like "OVIRT-SESSIONID". I do not see any reason why not to use this (or any other non JSESSIONID) name for header now. > > > > > - Original Message - > > > From: "Vojtech Szocs" > > > To: devel@ovirt.org > > > Cc: "Oved Ourfalli" , "René Koch" > > > Sent: Tuesday, July 15, 2014 8:06:19 PM > > > Subject: [ovirt-devel] UI plugins - talking with Engine via JSESSIONID > > > now > > > requires separate request header > > > > > > Hi guys, > > > > > > please be advised, patch for master [1] as well as ovirt-engine-3.5 [2] > > > branch was merged recently. This patch enables CSRF (Cross-Site Request > > > Forgery) protection for REST API session acquired by WebAdmin UI plugin > > > infrastructure. > > > > > > If you maintain UI plugin(s) and utilize "RestApiSessionAcquired" event > > > handler function, i.e. your UI plugin (JavaScript) calls Engine directly > > > or you pass the session ID to some other system which calls Engine, make > > > sure that any request to Engine contains both: > > > > > > * JSESSIONID cookie (as today) > > > * JSESSIONID request header (this is new) > > > > > > For CSRF-protected session [3], REST API backend compares these values > > > and if not successful, it responds with HTTP 403 (Forbidden) which will > > > break the communication with Engine. > > > > > > As mentioned above, this applies to all UI plugins deployed on Engine > > > WebAdmin version 3.5 and later. > > > > > > In order to stay compatible with older (unpatched) UI plugins, we could > > > introduce some Engine config parameter to control whether the REST API > > > session for UI plugins should use CSRF protection or not. > > > > > > [1] http://gerrit.ovirt.org/#/c/29682/ > > > [2] http://gerrit.ovirt.org/#/c/29850/ > > > [3] details in commit message of http://gerrit.ovirt.org/#/c/29849/ > > > > > > Regards, > > > Vojtech > > > ___ > > > 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] UI plugins - talking with Engine via JSESSIONID now requires separate request header
Can we have X-OVIRT-SESSIONID header name or any generic term and per ovirt specific instead of generic java terms? - Original Message - > From: "Vojtech Szocs" > To: devel@ovirt.org > Cc: "Oved Ourfalli" , "René Koch" > Sent: Tuesday, July 15, 2014 8:06:19 PM > Subject: [ovirt-devel] UI plugins - talking with Engine via JSESSIONID now > requires separate request header > > Hi guys, > > please be advised, patch for master [1] as well as ovirt-engine-3.5 [2] > branch was merged recently. This patch enables CSRF (Cross-Site Request > Forgery) protection for REST API session acquired by WebAdmin UI plugin > infrastructure. > > If you maintain UI plugin(s) and utilize "RestApiSessionAcquired" event > handler function, i.e. your UI plugin (JavaScript) calls Engine directly > or you pass the session ID to some other system which calls Engine, make > sure that any request to Engine contains both: > > * JSESSIONID cookie (as today) > * JSESSIONID request header (this is new) > > For CSRF-protected session [3], REST API backend compares these values > and if not successful, it responds with HTTP 403 (Forbidden) which will > break the communication with Engine. > > As mentioned above, this applies to all UI plugins deployed on Engine > WebAdmin version 3.5 and later. > > In order to stay compatible with older (unpatched) UI plugins, we could > introduce some Engine config parameter to control whether the REST API > session for UI plugins should use CSRF protection or not. > > [1] http://gerrit.ovirt.org/#/c/29682/ > [2] http://gerrit.ovirt.org/#/c/29850/ > [3] details in commit message of http://gerrit.ovirt.org/#/c/29849/ > > Regards, > Vojtech > ___ > 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] use mvn instead of make to deploy
- Original Message - > From: "Eyal Edri" > To: "Roy Golan" > Cc: devel@ovirt.org > Sent: Sunday, July 6, 2014 4:45:46 PM > Subject: Re: [ovirt-devel] use mvn instead of make to deploy > > any changed for jenkins jobs as a result? > we're using make and mvn on some of the jobs.. no. this is usable for people that are using ide, and ide for some reason does not know to execute generic commands. > > e. > > - Original Message - > > From: "Roy Golan" > > To: devel@ovirt.org > > Sent: Sunday, July 6, 2014 3:13:49 PM > > Subject: [ovirt-devel] use mvn instead of make to deploy > > > > just merged http://gerrit.ovirt.org/#/c/25661/ to help us use mvn to > > copy the project artifact instead of make. > > > > usage: > > > > #build and deploy to $OVIRT_ENGINE_PREIFX > > mvn clean install -Pmake > > > > #just deploy > > mvn install -pl org.ovirt.engine:make -Pmake > > > > > > #alternative prefix > > mvn clean install -Pmake -Dprefix=/path/to/prefix > > > > > > ___ > > 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
[ovirt-devel] ovirt-engine-3.5 branch is way too old
Hi, The following backlog is post branching, as branching was done at random point in effort. As far as I can see all these should go into 3.5 anyway, if someone can do us the service and just remove on top of master it will reduce effort of each individual developer. Next time branch should be created after at least one bug day is over and major issues found are in. Beta is a tag in time not a branch in time. Thanks, Alon 549d9e6 engine: NetworkValidator uses new validation syntax 9f0310b engine: Clear syntax for writing validations 52c6b35 host-deploy: appropriate message for kdump detection 375c554 core: Use force detach only on Data SD 8f02a74 engine: no need to save vm_static on run once c6851e4 ui: remove Escape characters for TextBoxLabel 5e37215 ui: improve hot plug cpu wording 028c175 engine: Rename providerId to networkProviderId in add/update host actions 5b4d20c engine: Configure unique host name on neutron.conf 90eb1d2 extapi: aaa: add auth result to credential change 994996b backend: Add richer formatting of migration duration 98e293b core: handle fence agent power wait param on stop bb9ecfb engine: Clear eclipse warning in AddVdsCommand 36dd138 aaa: always use engine context for queries 24f0cf8 restapi: rsdl_metadata - quota.id in add disk 7161ac0 tools: Expose VmGracefulShutdownTimeout option to engine-config 8255f44 aaa: more fixes to command context propgation b8feb57 restapi: missing vms link under affinity groups f056835 core, engine: Fix HotPlugCpuSupported config value 4492ef7 core, engine: Avoid migration in ppc64 2710b07 ui: avoid casting warnings on findbugs bcb156c core: adding missing command constructor 92c1522 core: Changing Host free space threshold a0d000b webadmin: column sorting support for Disks sub-tabs 5a0c76f webadmin: column sorting support for Storage sub-tabs 14a625e webadmin: column sorting support for Disks tabs a32d199 core: DiskConditionField - extract verbs to constants 48cc09d core: fixed searching disks by creation date ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Project vdsm-jsonrpc-java backup maintainer
- Original Message - > From: "Sandro Bonazzola" > To: "infra" , devel@ovirt.org > Cc: "Piotr Kliczewski" > Sent: Friday, June 27, 2014 5:30:34 PM > Subject: Project vdsm-jsonrpc-java backup maintainer > > Hi, > looks like only one person has +2 / merge rights on vdsm-jsonrpc-java. > I think every project should have a "backup" maintainer. > Since it seems pkliczewski is the only committer there, I would like to > propose him as maintainer too. > My usual statement: The term of "Backup maintainer" is wrong in my opinion. 1. There is nothing emergency in upstream project. 2. Downstream maintainer can always add patches on top of upstream release if there is downstream emergency, this is the reason of having downstream. 3. For small and medium projects there should be only one maintainer, to keep project consistent. 4. Large projects should be modular (components with own release cycle), so for each module single maintainer is assigned. vdsm-jsonrpc-java is a good example of taking a component out of the monolithic engine into a module with own release cycle and own maintainer. 5. If maintainer of component is unresponsive or is not productive, maintainer should be assigned to different person. Regards, Alon ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Correct way to run internal actions from commands
- Original Message - > From: "Gilad Chaplik" > To: "Yair Zaslavsky" > Cc: devel@ovirt.org > Sent: Thursday, June 19, 2014 11:33:19 AM > Subject: Re: [ovirt-devel] Correct way to run internal actions from commands > > - Original Message - > > From: "Yair Zaslavsky" > > To: "Gilad Chaplik" > > Cc: devel@ovirt.org > > Sent: Thursday, June 19, 2014 11:22:49 AM > > Subject: Re: [ovirt-devel] Correct way to run internal actions from > > commands > > > > > > > > - Original Message - > > > From: "Gilad Chaplik" > > > To: "Yair Zaslavsky" > > > Cc: devel@ovirt.org > > > Sent: Thursday, June 19, 2014 11:14:35 AM > > > Subject: Re: [ovirt-devel] Correct way to run internal actions from > > > commands > > > > > > We should enforce that in code level: getBackend() should be private in > > > CommandBase, and won't need any convention. > > > > Using getBackend() is also a "convention". > > so you're adding another one :-) > > how should I enforce not using getBackend().runXXX in reviews? I've probably > need to remember your email... Soon you will probably different signature for the helper runXXX() and the getBackend().runXXX()[1], as we are adding command context inheritance, to enable proper security context, correlation id inheritance and remove the ThreadLocal usage. So it will be easier to remember... :) [1] http://gerrit.ovirt.org/#/c/28829/ > > > > > > > > > > > Thanks, > > > Gilad. > > > > > > > > > - Original Message - > > > > From: "Yair Zaslavsky" > > > > To: devel@ovirt.org > > > > Sent: Wednesday, June 18, 2014 8:44:41 AM > > > > Subject: [ovirt-devel] Correct way to run internal actions from > > > > commands > > > > > > > > Hi all, > > > > Thanks to the collaboration of some of the maintainers and others I > > > > have > > > > managed to merge a patch which gives the ability to run internal > > > > commands > > > > the following way: > > > > > > > > If you're writing a code in a class that extends CommandBase, please > > > > follow > > > > the following instructions: > > > > > > > > Instead of Backend.getInstance().runInternalAction (or MultipleActions) > > > > you > > > > should use > > > > > > > > runInternalAction > > > > > > > > More patches will be added for running internal queries , and probably > > > > endAction as well. > > > > > > > > > > > > Thanks, > > > > Yair > > > > > > > > > > > > ___ > > > > 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
Re: [ovirt-devel] ovirt-engine master doesn't build anymore
- Original Message - > From: "Sandro Bonazzola" > To: devel@ovirt.org > Cc: "infra" > Sent: Wednesday, June 18, 2014 9:39:32 AM > Subject: ovirt-engine master doesn't build anymore > > See > http://jenkins.ovirt.org/job/ovirt-engine_master_create-rpms-quick_gerrit/2664/label=fedora20/console > Please fix ASAP, thanks. Unresolved conflict[1] [1] http://gerrit.ovirt.org/28875 > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > ___ > Infra mailing list > in...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/infra > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Question/thoughts about our engine logging framework
- Original Message - > From: "Martin Perina" > To: "Alon Bar-Lev" > Cc: devel@ovirt.org > Sent: Monday, June 16, 2014 4:49:57 PM > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging > framework > > > > ----- Original Message - > > From: "Alon Bar-Lev" > > To: "Martin Perina" > > Cc: devel@ovirt.org > > Sent: Monday, June 16, 2014 3:26:00 PM > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging > > framework > > > > > > > > - Original Message - > > > From: "Martin Perina" > > > To: "Alon Bar-Lev" > > > Cc: devel@ovirt.org > > > Sent: Monday, June 16, 2014 4:22:16 PM > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging > > > framework > > > > > > > > > > > > - Original Message - > > > > From: "Alon Bar-Lev" > > > > To: "Martin Perina" > > > > Cc: devel@ovirt.org, "Greg Sheremeta" > > > > Sent: Sunday, June 15, 2014 7:44:22 PM > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging > > > > framework > > > > > > > > > > > > > > > > ----- Original Message - > > > > > From: "Martin Perina" > > > > > To: "Alon Bar-Lev" > > > > > Cc: devel@ovirt.org, "Greg Sheremeta" > > > > > Sent: Sunday, June 15, 2014 8:17:13 PM > > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging > > > > > framework > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > From: "Alon Bar-Lev" > > > > > > To: "Martin Perina" > > > > > > Cc: devel@ovirt.org, "Greg Sheremeta" > > > > > > Sent: Sunday, June 15, 2014 6:27:09 PM > > > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine > > > > > > logging > > > > > > framework > > > > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > From: "Martin Perina" > > > > > > > To: "Alon Bar-Lev" > > > > > > > Cc: devel@ovirt.org, "Greg Sheremeta" > > > > > > > Sent: Sunday, June 15, 2014 7:19:15 PM > > > > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine > > > > > > > logging > > > > > > > framework > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > > From: "Alon Bar-Lev" > > > > > > > > To: "Martin Perina" > > > > > > > > Cc: "Greg Sheremeta" , devel@ovirt.org > > > > > > > > Sent: Sunday, June 15, 2014 5:07:28 PM > > > > > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine > > > > > > > > logging > > > > > > > > framework > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > > > From: "Martin Perina" > > > > > > > > > To: "Greg Sheremeta" > > > > > > > > > Cc: devel@ovirt.org > > > > > > > > > Sent: Sunday, June 15, 2014 5:34:51 PM > > > > > > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine > > > > > > > > > logging > > > > > > > > > framework > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > > > > From: "Greg Sheremeta" > > > > > > > > > > To: "Yair Zaslavsky" > > > > > > > > > > Cc: devel@ovirt.org > > > > > > > > > > Sent: Sunday, June 15, 20
Re: [ovirt-devel] Question/thoughts about our engine logging framework
- Original Message - > From: "Martin Perina" > To: "Alon Bar-Lev" > Cc: devel@ovirt.org > Sent: Monday, June 16, 2014 4:22:16 PM > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging > framework > > > > ----- Original Message - > > From: "Alon Bar-Lev" > > To: "Martin Perina" > > Cc: devel@ovirt.org, "Greg Sheremeta" > > Sent: Sunday, June 15, 2014 7:44:22 PM > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging > > framework > > > > > > > > - Original Message - > > > From: "Martin Perina" > > > To: "Alon Bar-Lev" > > > Cc: devel@ovirt.org, "Greg Sheremeta" > > > Sent: Sunday, June 15, 2014 8:17:13 PM > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging > > > framework > > > > > > > > > > > > - Original Message - > > > > From: "Alon Bar-Lev" > > > > To: "Martin Perina" > > > > Cc: devel@ovirt.org, "Greg Sheremeta" > > > > Sent: Sunday, June 15, 2014 6:27:09 PM > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging > > > > framework > > > > > > > > > > > > > > > > - Original Message - > > > > > From: "Martin Perina" > > > > > To: "Alon Bar-Lev" > > > > > Cc: devel@ovirt.org, "Greg Sheremeta" > > > > > Sent: Sunday, June 15, 2014 7:19:15 PM > > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging > > > > > framework > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > From: "Alon Bar-Lev" > > > > > > To: "Martin Perina" > > > > > > Cc: "Greg Sheremeta" , devel@ovirt.org > > > > > > Sent: Sunday, June 15, 2014 5:07:28 PM > > > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine > > > > > > logging > > > > > > framework > > > > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > From: "Martin Perina" > > > > > > > To: "Greg Sheremeta" > > > > > > > Cc: devel@ovirt.org > > > > > > > Sent: Sunday, June 15, 2014 5:34:51 PM > > > > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine > > > > > > > logging > > > > > > > framework > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > > From: "Greg Sheremeta" > > > > > > > > To: "Yair Zaslavsky" > > > > > > > > Cc: devel@ovirt.org > > > > > > > > Sent: Sunday, June 15, 2014 4:25:54 PM > > > > > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine > > > > > > > > logging > > > > > > > > framework > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > > > From: "Eli Mesika" > > > > > > > > > To: "Yair Zaslavsky" > > > > > > > > > Cc: devel@ovirt.org > > > > > > > > > Sent: Sunday, June 15, 2014 10:02:15 AM > > > > > > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine > > > > > > > > > logging > > > > > > > > > framework > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > > > > From: "Vojtech Szocs" > > > > > > > > > > To: "Martin Perina" > > > > > > > > > > Cc: devel@ovirt.org > > > > > > > > &
Re: [ovirt-devel] Question/thoughts about our engine logging framework
- Original Message - > From: "Martin Perina" > To: "Alon Bar-Lev" > Cc: devel@ovirt.org, "Greg Sheremeta" > Sent: Sunday, June 15, 2014 8:17:13 PM > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging > framework > > > > - Original Message - > > From: "Alon Bar-Lev" > > To: "Martin Perina" > > Cc: devel@ovirt.org, "Greg Sheremeta" > > Sent: Sunday, June 15, 2014 6:27:09 PM > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging > > framework > > > > > > > > - Original Message - > > > From: "Martin Perina" > > > To: "Alon Bar-Lev" > > > Cc: devel@ovirt.org, "Greg Sheremeta" > > > Sent: Sunday, June 15, 2014 7:19:15 PM > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging > > > framework > > > > > > > > > > > > - Original Message - > > > > From: "Alon Bar-Lev" > > > > To: "Martin Perina" > > > > Cc: "Greg Sheremeta" , devel@ovirt.org > > > > Sent: Sunday, June 15, 2014 5:07:28 PM > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging > > > > framework > > > > > > > > > > > > > > > > - Original Message - > > > > > From: "Martin Perina" > > > > > To: "Greg Sheremeta" > > > > > Cc: devel@ovirt.org > > > > > Sent: Sunday, June 15, 2014 5:34:51 PM > > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging > > > > > framework > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > From: "Greg Sheremeta" > > > > > > To: "Yair Zaslavsky" > > > > > > Cc: devel@ovirt.org > > > > > > Sent: Sunday, June 15, 2014 4:25:54 PM > > > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine > > > > > > logging > > > > > > framework > > > > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > From: "Eli Mesika" > > > > > > > To: "Yair Zaslavsky" > > > > > > > Cc: devel@ovirt.org > > > > > > > Sent: Sunday, June 15, 2014 10:02:15 AM > > > > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine > > > > > > > logging > > > > > > > framework > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > > From: "Vojtech Szocs" > > > > > > > > To: "Martin Perina" > > > > > > > > Cc: devel@ovirt.org > > > > > > > > Sent: Friday, June 13, 2014 12:57:49 PM > > > > > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine > > > > > > > > logging > > > > > > > > framework > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > > > From: "Martin Perina" > > > > > > > > > To: "Yair Zaslavsky" > > > > > > > > > Cc: devel@ovirt.org > > > > > > > > > Sent: Friday, June 13, 2014 10:43:59 AM > > > > > > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine > > > > > > > > > logging > > > > > > > > > framework > > > > > > > > > > > > > > > > > > Hi Yair, > > > > > > > > > > > > > > > > > > I had in my mind to clean up logging framework mess for quite > > > > > > > > > some > > > > > > > > > time > > > > > > > > > :-) > > > > > > > > > Currently this is the usage of logging frameworks in engine > > > > > > > &g
Re: [ovirt-devel] Question/thoughts about our engine logging framework
- Original Message - > From: "Martin Perina" > To: "Alon Bar-Lev" > Cc: devel@ovirt.org, "Greg Sheremeta" > Sent: Sunday, June 15, 2014 7:19:15 PM > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging > framework > > > > - Original Message - > > From: "Alon Bar-Lev" > > To: "Martin Perina" > > Cc: "Greg Sheremeta" , devel@ovirt.org > > Sent: Sunday, June 15, 2014 5:07:28 PM > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging > > framework > > > > > > > > - Original Message - > > > From: "Martin Perina" > > > To: "Greg Sheremeta" > > > Cc: devel@ovirt.org > > > Sent: Sunday, June 15, 2014 5:34:51 PM > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging > > > framework > > > > > > > > > > > > - Original Message - > > > > From: "Greg Sheremeta" > > > > To: "Yair Zaslavsky" > > > > Cc: devel@ovirt.org > > > > Sent: Sunday, June 15, 2014 4:25:54 PM > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging > > > > framework > > > > > > > > > > > > > > > > - Original Message - > > > > > From: "Eli Mesika" > > > > > To: "Yair Zaslavsky" > > > > > Cc: devel@ovirt.org > > > > > Sent: Sunday, June 15, 2014 10:02:15 AM > > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging > > > > > framework > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > From: "Vojtech Szocs" > > > > > > To: "Martin Perina" > > > > > > Cc: devel@ovirt.org > > > > > > Sent: Friday, June 13, 2014 12:57:49 PM > > > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine > > > > > > logging > > > > > > framework > > > > > > > > > > > > > > > > > > > > > > > > - Original Message - > > > > > > > From: "Martin Perina" > > > > > > > To: "Yair Zaslavsky" > > > > > > > Cc: devel@ovirt.org > > > > > > > Sent: Friday, June 13, 2014 10:43:59 AM > > > > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine > > > > > > > logging > > > > > > > framework > > > > > > > > > > > > > > Hi Yair, > > > > > > > > > > > > > > I had in my mind to clean up logging framework mess for quite > > > > > > > some > > > > > > > time > > > > > > > :-) > > > > > > > Currently this is the usage of logging frameworks in engine > > > > > > > classes: > > > > > > > > > > > > > > java.util.logging.Logger 6.8% > > > > > > > org.apache.commons.logging.Log7.8% > > > > > > > org.apache.log4j.Logger 13.6% > > > > > > > org.ovirt.engine.core.utils.log.Log 68.8% > > > > > > > org.slf4j.Logger 2.9% > > > > > > > > > > > > > > I think we should definitely use only 1 logging framework for the > > > > > > > whole > > > > > > > engine! > > > > > > > > > > > > > > So +1 to slf4j from me. > > > > > > > > > > > > +1 from me as well. > > > > > > > > > > +1 > > > > > > > > > +1 to slf4j. I started using that exclusively in Java projects 4 years > > > > ago > > > > :) > > > > > > > > Just be careful if we're introducing it as a new dependency. (It's > > > > provided > > > > by Fedora, but there might be conflicts if JBoss/Wildfly uses it. We > > > > should > > > > use that same version, if it does.) > > > > > > We already have a dependency to slf4j 1.7.5 in the root pom.xml. And > > > AFAIK > > >
Re: [ovirt-devel] Question/thoughts about our engine logging framework
- Original Message -
> From: "Martin Perina"
> To: "Greg Sheremeta"
> Cc: devel@ovirt.org
> Sent: Sunday, June 15, 2014 5:34:51 PM
> Subject: Re: [ovirt-devel] Question/thoughts about our engine logging
> framework
>
>
>
> - Original Message -
> > From: "Greg Sheremeta"
> > To: "Yair Zaslavsky"
> > Cc: devel@ovirt.org
> > Sent: Sunday, June 15, 2014 4:25:54 PM
> > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging
> > framework
> >
> >
> >
> > - Original Message -
> > > From: "Eli Mesika"
> > > To: "Yair Zaslavsky"
> > > Cc: devel@ovirt.org
> > > Sent: Sunday, June 15, 2014 10:02:15 AM
> > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging
> > > framework
> > >
> > >
> > >
> > > - Original Message -
> > > > From: "Vojtech Szocs"
> > > > To: "Martin Perina"
> > > > Cc: devel@ovirt.org
> > > > Sent: Friday, June 13, 2014 12:57:49 PM
> > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging
> > > > framework
> > > >
> > > >
> > > >
> > > > - Original Message -
> > > > > From: "Martin Perina"
> > > > > To: "Yair Zaslavsky"
> > > > > Cc: devel@ovirt.org
> > > > > Sent: Friday, June 13, 2014 10:43:59 AM
> > > > > Subject: Re: [ovirt-devel] Question/thoughts about our engine logging
> > > > > framework
> > > > >
> > > > > Hi Yair,
> > > > >
> > > > > I had in my mind to clean up logging framework mess for quite some
> > > > > time
> > > > > :-)
> > > > > Currently this is the usage of logging frameworks in engine classes:
> > > > >
> > > > > java.util.logging.Logger 6.8%
> > > > > org.apache.commons.logging.Log7.8%
> > > > > org.apache.log4j.Logger 13.6%
> > > > > org.ovirt.engine.core.utils.log.Log 68.8%
> > > > > org.slf4j.Logger 2.9%
> > > > >
> > > > > I think we should definitely use only 1 logging framework for the
> > > > > whole
> > > > > engine!
> > > > >
> > > > > So +1 to slf4j from me.
> > > >
> > > > +1 from me as well.
> > >
> > > +1
> > >
> > +1 to slf4j. I started using that exclusively in Java projects 4 years ago
> > :)
> >
> > Just be careful if we're introducing it as a new dependency. (It's provided
> > by Fedora, but there might be conflicts if JBoss/Wildfly uses it. We should
> > use that same version, if it does.)
>
> We already have a dependency to slf4j 1.7.5 in the root pom.xml. And AFAIK
> 1.7.2 is a part of EAP 6.
The jboss we are using provides slf4j-1.6.1, while it seems to be patched to
support varargs[1] as 1.7.x.
As standalone at fedora there is slf4j which is compatible and at rhel there is
slf4j-eap6 both are 1.7.x.
However for centos we use jpackage which provides only 1.6.1[2].
So for standalone packages we may experience issues if were build using varargs.
[1] logger.debug("format", obj1, obj2, obj3, ...)
[2] http://jpackage.org/browser/rpm.php?jppversion=6.0&id=12435
>
> >
> > > >
> > > > Note that GWT UI code uses java.util.logging exclusively to do all
> > > > logging.
> > > > (GWT emulates java.util.logging API and provides log handlers for use
> > > > on
> > > > client side such as console.log() or stdout/DevMode-during-debug
> > > > handlers.)
> > > >
> > > > >
> > > > > And once we agree to 1 logging framework, I can start preparing
> > > > > patches
> > > > > to
> > > > > use it.
> > > > >
> > > > > - Original Message -
> > > > > > From: "Yair Zaslavsky"
> > > > > > To: devel@ovirt.org
> > > > > > Sent: Friday, June 13, 2014 8:15:55 AM
> > > > > > Subject: [ovirt-devel] Question/thoughts about our engine logging
> > > > > > framework
> > > > > >
> > > > > > Hi all,
> > > > > > During my recent work on AAA, I was suggested by Juan Hernandez to
> > > > > > use
> > > > > > slf4j
> > > > > > logging framework which serves as a facade for other logging
> > > > > > frameworks
> > > > > > (including java utils logging which is now used by jboss), log4j
> > > > > > and
> > > > > > others.
> > > > > > I have accepted Juan's offer, and then when looking at our
> > > > > > LogFactory
> > > > > > class
> > > > > > I
> > > > > > have noticed we use commons logging.
> > > > > >
> > > > > > Several thoughts/questions -
> > > > > > A. Why continue use our own wrapper as slf4j is already a facade.
> > > > > > b. I think we should move cross java code to slf4j. What do you
> > > > > > think
> > > > > > on
> > > > > > this
> > > > > > point?
> > > > > >
> > > > > > Some reading material -
> > > > > >
> > > > > > http://javarevisited.blogspot.com.au/2013/08/why-use-sl4j-over-log4j-for-logging-in.html
> > > > > > http://stackoverflow.com/questions/3222895/what-is-the-issue-with-the-runtime-discovery-algorithm-of-apache-commons-logging
> > > > > >
> > > > > >
> > > > > >
> > > > > > Yair
> > > > > > ___
> > > > > > Devel mailing list
> > > > > > Devel@ovirt.org
> > > > > > http://lists.ovirt.org/mailman/listinfo/devel
> > > > > >
Re: [ovirt-devel] Github Repositories
- Original Message - > From: "Saggi Mizrahi" > To: devel@ovirt.org > Sent: Sunday, June 15, 2014 1:29:34 PM > Subject: [ovirt-devel] Github Repositories > > We are moving all ovirt stuff from my own user to > the newly created ovirt-infra group on github. > > Update your git remotes! > > https://github.com/ovirt-infra Why not open/use oVirt organization? ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] devenv setup failure
- Original Message - > From: "Alon Bar-Lev" > To: "Moti Asayag" > Cc: "Simone Tiraboschi" , devel@ovirt.org > Sent: Sunday, June 8, 2014 2:53:14 PM > Subject: Re: [ovirt-devel] devenv setup failure > > > Check this one: > > http://gerrit.ovirt.org/#/c/28452/ also, this patch is missing handling of SETUP_ATTRS_MODULES of new modules. was reported already, but I do not see any progress. so maybe indeed reverting the patch is good. > > - Original Message - > > From: "Moti Asayag" > > To: devel@ovirt.org > > Cc: "Simone Tiraboschi" > > Sent: Sunday, June 8, 2014 2:43:24 PM > > Subject: [ovirt-devel] devenv setup failure > > > > Hi, > > > > Due to commit "Split of engine-setup-plugin > > 33e469b7b2db2c36b070509d700c34114c274559 [1], > > the development environment setup fails with: > > > > 2014-06-08 14:09:03 DEBUG otopi.context context._executeMethod:152 method > > exception > > Traceback (most recent call last): > > File "/usr/lib/python2.7/site-packages/otopi/context.py", line 142, in > > _executeMethod > > method['method']() > > File > > > > "/home/masayag/ovirt-engine/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-common/base/core/uninstall.py", > > line 249, in _cleanup > > os.makedirs(os.path.dirname(output)) > > File "/usr/lib64/python2.7/os.py", line 150, in makedirs > > makedirs(head, mode) > > File "/usr/lib64/python2.7/os.py", line 157, in makedirs > > mkdir(name, mode) > > OSError: [Errno 13] Permission denied: '@SETUP_ETC@' > > 2014-06-08 14:09:03 ERROR otopi.context context._executeMethod:161 Failed > > to > > execute stage 'Clean up': [Errno 13] Permission denied: '@SETUP_ETC@' > > 2014-06-08 14:09:03 DEBUG otopi.context context.dumpEnvironment:468 > > ENVIRONMENT DUMP - BEGIN > > 2014-06-08 14:09:03 DEBUG otopi.context context.dumpEnvironment:478 ENV > > BASE/exceptionInfo=list:'[(, OSError(13, > > 'Permission denied'), ), ( > 'exceptions.OSError'>, OSError(13, 'Permission denied'), > at 0x33ee518>)]' > > > > A patch to revert this one is suggested on [2]. > > > > [1] http://gerrit.ovirt.org/#/c/27647/ > > [2] http://gerrit.ovirt.org/28458 > > > > Regards, > > Moti > > > > ___ > > 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
Re: [ovirt-devel] devenv setup failure
Check this one: http://gerrit.ovirt.org/#/c/28452/ - Original Message - > From: "Moti Asayag" > To: devel@ovirt.org > Cc: "Simone Tiraboschi" > Sent: Sunday, June 8, 2014 2:43:24 PM > Subject: [ovirt-devel] devenv setup failure > > Hi, > > Due to commit "Split of engine-setup-plugin > 33e469b7b2db2c36b070509d700c34114c274559 [1], > the development environment setup fails with: > > 2014-06-08 14:09:03 DEBUG otopi.context context._executeMethod:152 method > exception > Traceback (most recent call last): > File "/usr/lib/python2.7/site-packages/otopi/context.py", line 142, in > _executeMethod > method['method']() > File > > "/home/masayag/ovirt-engine/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-common/base/core/uninstall.py", > line 249, in _cleanup > os.makedirs(os.path.dirname(output)) > File "/usr/lib64/python2.7/os.py", line 150, in makedirs > makedirs(head, mode) > File "/usr/lib64/python2.7/os.py", line 157, in makedirs > mkdir(name, mode) > OSError: [Errno 13] Permission denied: '@SETUP_ETC@' > 2014-06-08 14:09:03 ERROR otopi.context context._executeMethod:161 Failed to > execute stage 'Clean up': [Errno 13] Permission denied: '@SETUP_ETC@' > 2014-06-08 14:09:03 DEBUG otopi.context context.dumpEnvironment:468 > ENVIRONMENT DUMP - BEGIN > 2014-06-08 14:09:03 DEBUG otopi.context context.dumpEnvironment:478 ENV > BASE/exceptionInfo=list:'[(, OSError(13, > 'Permission denied'), ), ( 'exceptions.OSError'>, OSError(13, 'Permission denied'), at 0x33ee518>)]' > > A patch to revert this one is suggested on [2]. > > [1] http://gerrit.ovirt.org/#/c/27647/ > [2] http://gerrit.ovirt.org/28458 > > Regards, > Moti > > ___ > 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] [ovirt-users] [ANN] oVirt 3.4.1 Release is now available
- Original Message - > From: "Sandro Bonazzola" > To: "David Caro" > Cc: devel@ovirt.org, "Alon Bar-Lev" > Sent: Thursday, May 8, 2014 5:44:43 PM > Subject: Re: [ovirt-users] [ANN] oVirt 3.4.1 Release is now available > > Il 08/05/2014 16:27, David Caro ha scritto: > > On Thu 08 May 2014 04:02:04 PM CEST, Sandro Bonazzola wrote: > >> Il 08/05/2014 16:00, Sandro Bonazzola ha scritto: > >>> Il 08/05/2014 15:51, Alon Bar-Lev ha scritto: > >>>> > >>>> > >>>> - Original Message - > >>>>> From: "Sandro Bonazzola" > >>>>> To: annou...@ovirt.org, us...@ovirt.org, devel@ovirt.org > >>>>> Sent: Thursday, May 8, 2014 4:02:52 PM > >>>>> Subject: [ovirt-users] [ANN] oVirt 3.4.1 Release is now available > >>>>> > >>>>> The oVirt development team is pleased to announce the general > >>>>> availability of oVirt 3.4.1 as of May 8th 2014. This release > >>>>> solidifies oVirt as a leading KVM management application and open > >>>>> source alternative to VMware vSphere. > >>>>> > >>>>> oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5 > >>>>> (or similar). > >>>>> > >>>>> This release of oVirt includes numerous bug fixes. > >>>>> See the release notes [1] for a list of the new features and bugs > >>>>> fixed. > >>>>> > >>>>> The existing repository ovirt-3.4 has been updated for delivering this > >>>>> release without the need of enabling any other repository, however > >>>>> since we > >>>>> introduced package signing you need an additional step in order to get > >>>>> the public keys installed on your system. > >>>>> Please refer to release notes [1] for Installation / Upgrade > >>>>> instructions. > >>>>> > >>>>> For Fedora 19 users, a known issue may cause installation failure > >>>>> due to recent changes in sos package. > >>>>> Please refer to release notes [1] known issues for resolving on your > >>>>> system. > >>>>> > >>>>> A new oVirt Node and oVirt Live ISO will be available [2]. > >>>>> > >>>>> [1] http://www.ovirt.org/OVirt_3.4.1_release_notes > >>>>> [2] http://resources.ovirt.org/plain/pub/ovirt-3.4/iso/ > >>>> > >>>> What is plain? > >>> > >>> Sorry, my bad in copy / paste from firefox. it just disable the theme, > >>> both with and without /plain/ points to the same files. > >>> > >>>> > >>>> Sources are not available, example[1] > >>>> > >>>> [1] http://resources.ovirt.org/pub/src/ovirt-engine/ > >>> > >>> Sure, sources are available in http://resources.ovirt.org/pub/src/ and on > >>> http://gerrit.ovirt.org > >>> I'll remember to add the links to the next announce. > >> > >> Correcting myself, for some reason sources are in > >> http://resources.ovirt.org/pub/ovirt-3.4/src/ and not in > >> http://resources.ovirt.org/pub/src/ > >> > >> > >>> > >>> > >>>> > >>>>> > >>>>> -- > >>>>> Sandro Bonazzola > >>>>> Better technology. Faster innovation. Powered by community > >>>>> collaboration. > >>>>> See how it works at redhat.com > >>>>> ___ > >>>>> Users mailing list > >>>>> us...@ovirt.org > >>>>> http://lists.ovirt.org/mailman/listinfo/users > >>>>> > >>> > >>> > >> > >> > > > > I can help with that, should I move or copy the sources? > > I think move is better, let's avoid confusion in src location. I do not care if there are sources at 3.4, but must be at /pub/src, still waiting for releasing ebuilds. > > > > > > > -- > > 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 > > > > > -- > 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-users] [ANN] oVirt 3.4.1 Release is now available
- Original Message - > From: "Sandro Bonazzola" > To: annou...@ovirt.org, us...@ovirt.org, devel@ovirt.org > Sent: Thursday, May 8, 2014 4:02:52 PM > Subject: [ovirt-users] [ANN] oVirt 3.4.1 Release is now available > > The oVirt development team is pleased to announce the general > availability of oVirt 3.4.1 as of May 8th 2014. This release > solidifies oVirt as a leading KVM management application and open > source alternative to VMware vSphere. > > oVirt is available now for Fedora 19 and Red Hat Enterprise Linux 6.5 > (or similar). > > This release of oVirt includes numerous bug fixes. > See the release notes [1] for a list of the new features and bugs fixed. > > The existing repository ovirt-3.4 has been updated for delivering this > release without the need of enabling any other repository, however since we > introduced package signing you need an additional step in order to get > the public keys installed on your system. > Please refer to release notes [1] for Installation / Upgrade instructions. > > For Fedora 19 users, a known issue may cause installation failure > due to recent changes in sos package. > Please refer to release notes [1] known issues for resolving on your system. > > A new oVirt Node and oVirt Live ISO will be available [2]. > > [1] http://www.ovirt.org/OVirt_3.4.1_release_notes > [2] http://resources.ovirt.org/plain/pub/ovirt-3.4/iso/ What is plain? Sources are not available, example[1] [1] http://resources.ovirt.org/pub/src/ovirt-engine/ > > -- > Sandro Bonazzola > Better technology. Faster innovation. Powered by community collaboration. > See how it works at redhat.com > ___ > Users mailing list > us...@ovirt.org > http://lists.ovirt.org/mailman/listinfo/users > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] commons-collections v4.0
- Original Message - > From: "Mike Kolesnik" > To: "Alon Bar-Lev" > Cc: "yzaspits" , devel@ovirt.org > Sent: Thursday, May 8, 2014 7:18:51 AM > Subject: Re: [ovirt-devel] commons-collections v4.0 > > - Original Message - > > > > > > - Original Message - > > > From: "Yevgeny Zaspitsky" > > > To: "Alon Bar-Lev" , "Mike Kolesnik" > > > > > > Cc: devel@ovirt.org > > > Sent: Thursday, May 8, 2014 1:11:41 AM > > > Subject: Re: [ovirt-devel] commons-collections v4.0 > > > > > > On the other hand, changing a jar in the runtime environment without > > > compiling and running test with the new jar could lead an application to > > > stop functioning in a customer environment. > > > Also not every bug found in a dependency jar would cause a problem in the > > > application. (An application might not use the problematic part of the > > > dependency.) > > > I'd better trust the test suite (automatic and manual) that we run on the > > > compiled application with all the dependencies that the developers choose > > > at > > > the development time and then deliver that (with its dependencies as a > > > single package) to the customers. > > > Every bug in a dependency should be evaluated within the given > > > application > > > scope and only if proven as the given application problem only then the > > > application should be released. > > > > So what you basically claim is that java developers and technology is not > > mature enough to keep backward compatibility, so each java developer should > > freeze a snapshot in time for his application to work. > > > > I truly hope this is not the case. > > There can always be regressions as you're well aware, and I don't know but > usually people who develop the libraries are not Einstein so yes, they do > break > backwards compatibility on occasions, sometimes even on purpose > (deprecation). > > > > > And for addressing your claim explicitly, what you can test at single point > > in time, does not mean that it is definite as well, at customer site bugs > > may be found also in the packages that you do test. > > Well, when you test on site by dev & qa you make sure you send something to > the > customer - X. When the dependencies are updated out of band, the customer > actually is using X'. > I can see at least 2 things wrong here: > 1. You're putting the customer in a position of a tester for the X' > application. > 2. If customer finds a bug he actually found it on X', whereas the developer > who > would be assigned to the bug could be using X'' by now. > > If you're so keen on packaging a jar outside WAR file, we need to specify > explicit version and not >=. Explicit version is at if you pack it within your application, there is no point in that. Think of how RHEL is provided, think of Fedora, in all cases there are components working together and each can be updated independently, and amazingly - it works. You can think of Windows with all of its libraries and interfaces (Microsoft or 3rd party), that application use, and it does work without every [sane] application pulls the entire dependencies. For some reason only people with Java background (including the J2EE designers) assume that Java developers cannot be trusted for not breaking backward compatibility in minor versions. This is not technical assumption but human assumption, as there is no technical reason for Java library to break backward compatibility within minor releases, so what does it tells us about what Java developers thinks of them-selves? Java will be ready for enterprise only when this is resolved. I hope all the dependencies we are using are at the quality level that enables us to to trust their developers. > > > > > > > > > > > > Sent from Samsung Mobile > > > > > > Original message > > > From: Alon Bar-Lev > > > Date: 07/05/2014 21:41 (GMT+02:00) > > > To: Mike Kolesnik > > > Cc: Yevgeny Zaspitsky ,devel@ovirt.org > > > Subject: Re: [ovirt-devel] commons-collections v4.0 > > > > > > > > > > > > - Original Message - > > > > From: "Mike Kolesnik" > > > > To: "Alon Bar-Lev" > > > > Cc: "Yevgeny Zaspitsky" , devel@ovirt.org > > > > Sent: Wednesday, May 7, 2014 9:34:03 PM > > > > Subject: Re: [ovirt-deve
Re: [ovirt-devel] commons-collections v4.0
- Original Message - > From: "Yevgeny Zaspitsky" > To: "Alon Bar-Lev" , "Mike Kolesnik" > Cc: devel@ovirt.org > Sent: Thursday, May 8, 2014 1:11:41 AM > Subject: Re: [ovirt-devel] commons-collections v4.0 > > On the other hand, changing a jar in the runtime environment without > compiling and running test with the new jar could lead an application to > stop functioning in a customer environment. > Also not every bug found in a dependency jar would cause a problem in the > application. (An application might not use the problematic part of the > dependency.) > I'd better trust the test suite (automatic and manual) that we run on the > compiled application with all the dependencies that the developers choose at > the development time and then deliver that (with its dependencies as a > single package) to the customers. > Every bug in a dependency should be evaluated within the given application > scope and only if proven as the given application problem only then the > application should be released. So what you basically claim is that java developers and technology is not mature enough to keep backward compatibility, so each java developer should freeze a snapshot in time for his application to work. I truly hope this is not the case. And for addressing your claim explicitly, what you can test at single point in time, does not mean that it is definite as well, at customer site bugs may be found also in the packages that you do test. > > > Sent from Samsung Mobile > > Original message > From: Alon Bar-Lev > Date: 07/05/2014 21:41 (GMT+02:00) > To: Mike Kolesnik > Cc: Yevgeny Zaspitsky ,devel@ovirt.org > Subject: Re: [ovirt-devel] commons-collections v4.0 > > > > - Original Message - > > From: "Mike Kolesnik" > > To: "Alon Bar-Lev" > > Cc: "Yevgeny Zaspitsky" , devel@ovirt.org > > Sent: Wednesday, May 7, 2014 9:34:03 PM > > Subject: Re: [ovirt-devel] commons-collections v4.0 > > > > - Original Message - > > > > > > > > > - Original Message - > > > > From: "Yevgeny Zaspitsky" > > > > To: "Alon Bar-Lev" > > > > Cc: devel@ovirt.org > > > > Sent: Tuesday, April 22, 2014 11:39:11 AM > > > > Subject: Re: [ovirt-devel] commons-collections v4.0 > > > > > > > > That means that we manage 2 separate environments: > > > > 1. Development - relies on pom files. E.g. unit tests run with > > > > commons-collections v3.1 (and when I add v4.0) and succeed. > > > > > > devenv will use runtime option. > > > you are right about the unit tests, these relays on the poms. > > > > I use devenv and it always uses the dev option not the runtime. > > So basically developers are using the pom specified versions and not what > > used in runtime. > > > > Even more so, in runtime it highly depends on what OS you're using, so > > someone > > developing on F19 might not be using same versions as a developer on F20 > > and > > both are probably very different versions than on RHEL/CentOS. > > I won't even mention other OS`s. > > > > > > > > > 2. Run-time - relies on JBoss own dependencies that bring > > > > commons-collection > > > > v3.2.1-redhat-2. > > > > > > in rhel case, yes. > > > > > > > This kind of discrepancies might be found in other libraries as we do > > > > not > > > > synchronize our pom files with the JBoss current version dependencies. > > > > IMHO that could lead to some very difficult bugs that we won't be able > > > > to > > > > simulate in our unit tests. > > > > > > correct, but the java way to pull dependencies at will without being able > > > to > > > fix z-stream using central package management tools is more severe than > > > unit > > > tests not working/not working. > > > > > > for example, your application uses x.jar and actually delivers x.jar... > > > so > > > from release to eternity it is your responsibility to track x.jar for > > > severe > > > stability bugs and security bugs, and release your entire application > > > each > > > time found, now multiple it with the # of components application is using > > > and see how much effort you have just to maintain stability and security > > > if > > > you embed 3rd party components without your application. > > &
