[ovirt-devel] [ACTION REQUIRED] unresolved deps for ovirt-optimizer-ui
package: ovirt-optimizer-ui-0.1-1.fc19.noarch from ovirt-3.5-beta-sanity unresolved deps: ovirt-optimizer-webadmin-portal >= 0:3.4 -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Stats for oVirt Downloads: Jan-May 2014
All: For some time, traffic statistics for the sites in the ovirt.org domain (lists, resources, gerrit, and linode01) have been collected and organized using awstats[1] at stats.ovirt.org[2]. From the data provided for resources, I have been able to put together what should be a fairly definitive set of statistics for software downloads within the oVirt Project. Methodology The statistics that were analyzed were for five parts of the project: * Engine * Live * Node * Engine Reports * Engine dwh Downloads of the Engine RPM file, it was determined, would be indicative of actual oVirt installs. The allinone RPMs were not analyzed at this time, since installing this RPM is a choice made during the installation process itself. Tracking the Engine Reports and dwh RPMs was done to determine the popularity of these two tools and to ensure their numbers were comparable. To count downloads, data was gathered each month that listed the total downloads of every file, a number derived from the total hits each file had, minus any 206 hits, which indicated incomplete downloads. Key files for Engine, Engine Reports, and Engine dwh were identified and the data filtered to include counts for each one of the files, in whatever version released. Tracking of Live and Node RPMs was already set up within the awstats reporting, and was taken directly from awstats in each month. If there is any part of this methodology that is in error, feedback is very much appreciated. Presentation of Data Data was aggregated using Pivot Tables in Google Docs, and the application of SUMIFS functions in the same spreadsheet document. This document is still being formatted into a more presentable form, but until then, I wanted to deliver some preliminary results to the community for the first five months of the year. It will be noted that in general, download numbers are on the rise, particularly around the time oVirt 3.4 was released. There are significant gaps in downloads of Engine Reports and Engine dwh. I am still investigating the cause of this lack of data. Engine Jan 5815 Feb 4251 Mar 1980 Apr 10509 May 12043 Engine Reports Jan 0 Feb 1209 Mar 0 Apr 10282 May 9647 Engine dwh Jan 0 Feb 603 Mar 0 Apr 9974 May 10311 Live Jan 845 Feb 757 Mar 739 Apr 1981 May 1187 Node Jan 95 Feb 757 Mar 739 Apr 1981 May 1187 Thanks for Alon Bar-Lev and Michael Scherer for their invaluable assistance with this data gathering and reporting. BKP [1] http://awstats.sourceforge.net/ [2] http://stats.ovirt.org/ -- Brian Proffitt oVirt Community Manager Project Atomic Community Lead Open Source and Standards, Red Hat - http://community.redhat.com Phone: +1 574 383 9BKP IRC: bkp @ OFTC ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] [QE] [ACTION NEEDED] oVirt 3.5.0 Beta / branching delay
Hi, I started building ovirt-engine this morning as soon as ovirt infra team patches have been merged. The build is still running since 6 hours ago due to heavy load of jenkins slaves, so we couldn't perform basic sanity tests on the build yet. The build is based on git hash 54d6a0bba7e9d62f2ec3bd16157ca2387b57ab58 and is running here [1] As soon as it finishes we'll publish it on nightly master snapshot and will be tested tomorrow morning. If sanity test passes, the ovirt-engine-3.5 branch will be created from above hash with the content of the snapshot including the build [1]. Any other change to the repo other than critical fixes (like missing dependency fixes or new builds addressing critical issues) shouldn't be allowed in that yum repository. If you're aware of any critical issue fixed later than 54d6a0bba7e9d62f2ec3bd16157ca2387b57ab58 please let us know as soon as possible. Note to VDSM team, I see VDSM already branched a few days ago but in nightly snapshot builds are still coming from master branch and no jenkins job has been created for building from 3.5 yet. Please provide the right RPM needed for this beta release or the one built from master will be taken. I'm sorry for the delay. [1] http://jenkins.ovirt.org/job/ovirt-engine_master_create-rpms_merged/2105/ -- 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] multipath configuration
configfile.py was written as a utility to manage operations vdsm does on config files. handling stuff like ovirt node persistence and selinux management. Consider using this for multipath. Currently it comments and removes comments since it had to be backward compatible with old code. I have no objection (can't speak for others though) to replacing it's functionality with rotating[1]. It would have to be modified to support multipth's sections. This would effect libvirt.con, qemu.conf, qemu-sanlock.conf and others[2] Thanks, Mooli. [1] we would have to think about upgrading from one method to the other: one solution could be to remove vdsm's comments and then rotate. [2] for a full list see configurator.py:LibvirtModuleConfigure.FILES - Original Message - > On Wed, Jun 25, 2014 at 09:58:52AM -0400, Yeela Kaplan wrote: > > Hi, > > > > Currently multipath.conf is being rotated each time we reconfigure it. > > > > We'd like to change the behaviour for multipath.conf so that current > > configuration will be commented out > > and we'd stop rotating (in the same manner as libvirt conf works today). > > > > Does anybody have any comment for/ against? > > I'd like to present the problem in a slightly different light. > > It is highly uncommon for a service to mangle the configuration files > of another service. Administrator do not expect they complain (e.g. Bug > 1076531 - vdsm overwrites multipath.conf at every startup) > > We used to have this problem with libvirtd.conf, but it has been > aleviated by moving the configuration to vdsm-tool, which should do its > thing when asked by the local admin, or once during automatic host > installation. > > We should do this with multipath.conf, too. And we should deprecate the > RHEV trademark that is stuck there while at it. > > The only question is how. Should we place the old configuration in a > rotated file (a-la .rpmsave) or should we place them in the same file, > completely commented out. > > We've taken the comment-out approach for libvirtd.conf, logrotate etc., > but I must admit that moving that saving a copy of the original file is > simpler and cleaner. Note that we do not need to rotate more than one > file. On upgrade, we should overwrite our version of the multipath.conf > with our new favorite version. The original version should be kept just > in case we want to uninstall Vdsm and revert to the original. > > Another question is how we should write the configuration file: should > we do it as simple text, or should we take a smarter augeas-based > approach. > > In my opinion, as long as we want to dump our own conf file, there is > not motivation for augeas. If, on the other hand, we would like to > replace only a section of the file, it should come into play. > > Is this what you have in mind for multipath.conf, Federico? Could you > elaborate? > > 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
[ovirt-devel] Fwd: [ OWF 2014 ] CFP Deadline extended until 15th of July
Open World Forum 2014 (http://www.openworldforum.paris/en/) View this email in your browser (http://us2.campaign-archive2.com/?u=135959c7d6d8cb5b4d119799e&id=5d98457353&e=86db4bd8d0) http://www.openworldforum.paris/fr/ Deadline extended for the CFP : 15th of July (http://www.openworldforum.paris/en/cfp/) http://www.openworldforum.paris/en/cfp/ Classic and essential subjects such as Cloud computing, Data, Internet of Things, Dev, etc. will be treated from the point of view of users. We will also put a strong emphasis on trending topics : Security, Privacy, Trust and Mobility. If you wish to submit a proposal about one of these topics and many more, please do so on the page dedicated to the Call for Paper (http://openworldforum.org/en/cfp/) . http://www.openworldforum.paris/en/news/an-open-world-for-citizens/ THINK (http://www.openworldforum.paris/en/news/an-open-world-for-citizens/) "Open Access: for an Open and accessible to all Research ?" http://www.openworldforum.org/en/code/ CODE (http://www.openworldforum.org/en/code/) "Openness to take back technical control" http://www.openworldforum.org/en/experiment/ EXPERIMENT (http://www.openworldforum.org/en/experiment/) "An Open World Forum for Citizens" ** (http://mondomaine.paris/) Assuming its pioneering role, the Open World Forum is ranked within the first hundred websites to switch to the “.paris” TLD Wednesday 4th of June. It represents one more step towards a strong digital space for the OWF, giving us a complementary approach to the physical space on which the OWF was based upon. As an ambassador of this innovative initiative which promotes business activity on our territory, the OWF gets a local anchorage that measures up to its international ambition. Registrars, selected websites representatives and political figures were gathered at the first floor of the Eiffel tower to welcome this new domain name providing an original link between a digital location and a geographical location which has benefits from an excellent brand image. During the press conference, the OWF's team stood alongside with Anne Hidalgo, mayor of Paris, Jean-Louis Missika, the Deputy Mayor who has been carrying the project for six years, and a lot of others famour ambassadors (such as RATP, Desley, Paris Airport, DS World, Spotteo, Bercy Arena or the Eiffel tower). ** cont...@openworldforum.org (mailto:cont...@openworldforum.org) ** sponsor...@openworldforum.org (mailto:sponsor...@openworldforum.org) ** pr...@openworldforum.org (mailto:pr...@openworldforum.org) ** (http://openworldforum.org/en/) Copyright © 2014 OpenWorldForum, All rights reserved. You are receiving this email because you were registered to previous editions of OWF Our mailing address is: OpenWorldForum 8 Avenue de la Vauve Palaiseau 91127 France ** unsubscribe from this list (http://openworldforum.us2.list-manage1.com/unsubscribe?u=135959c7d6d8cb5b4d119799e&id=8b79da4dd2&e=86db4bd8d0&c=5d98457353) ** update subscription preferences (http://openworldforum.us2.list-manage.com/profile?u=135959c7d6d8cb5b4d119799e&id=8b79da4dd2&e=86db4bd8d0) ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] multipath configuration
On Wed, Jun 25, 2014 at 09:58:52AM -0400, Yeela Kaplan wrote: > Hi, > > Currently multipath.conf is being rotated each time we reconfigure it. > > We'd like to change the behaviour for multipath.conf so that current > configuration will be commented out > and we'd stop rotating (in the same manner as libvirt conf works today). > > Does anybody have any comment for/ against? I'd like to present the problem in a slightly different light. It is highly uncommon for a service to mangle the configuration files of another service. Administrator do not expect they complain (e.g. Bug 1076531 - vdsm overwrites multipath.conf at every startup) We used to have this problem with libvirtd.conf, but it has been aleviated by moving the configuration to vdsm-tool, which should do its thing when asked by the local admin, or once during automatic host installation. We should do this with multipath.conf, too. And we should deprecate the RHEV trademark that is stuck there while at it. The only question is how. Should we place the old configuration in a rotated file (a-la .rpmsave) or should we place them in the same file, completely commented out. We've taken the comment-out approach for libvirtd.conf, logrotate etc., but I must admit that moving that saving a copy of the original file is simpler and cleaner. Note that we do not need to rotate more than one file. On upgrade, we should overwrite our version of the multipath.conf with our new favorite version. The original version should be kept just in case we want to uninstall Vdsm and revert to the original. Another question is how we should write the configuration file: should we do it as simple text, or should we take a smarter augeas-based approach. In my opinion, as long as we want to dump our own conf file, there is not motivation for augeas. If, on the other hand, we would like to replace only a section of the file, it should come into play. Is this what you have in mind for multipath.conf, Federico? Could you elaborate? Dan. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [QE] [ACTION NEEDED] oVirt 3.5.0 Test Day wiki
On 26/06/14 14:03, Sandro Bonazzola wrote: > Il 26/06/2014 13:00, Lior Vernia ha scritto: >> I edited the document earlier this week, but today tried again and got >> the following error: >> >> "You do not have permission to edit this page, for the following reason: >> The action you have requested is limited to users in the group: Users." >> >> Known issue? > > Did you logged in to the wiki today? > If yes, I think this is a new issue. > Logged in since yesterday. Logged out and back in now and everything worked fine, sorry for the noise :) >> >> >> On 23/06/14 17:23, Sandro Bonazzola wrote: >>> Hi, >>> as you should know we're going to have oVier 3.5 first test day on Jul 1st. >>> Maintainers and community, please start filling test day wiki [1] >>> with relevant tests needed. >>> >>> [1] http://www.ovirt.org/OVirt_3.5_TestDay >>> > > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ACTION REQUIRED] ovirt-3.4-snapshot repository closure failures
On Thu, Jun 26, 2014 at 05:59:47AM -0400, Francesco Romani wrote: > - Original Message - > > From: "Sandro Bonazzola" > > To: devel@ovirt.org, "infra" > > Sent: Thursday, June 26, 2014 11:56:19 AM > > Subject: [ACTION REQUIRED] ovirt-3.4-snapshot repository closure failures > > > > Hi, > > ovirt-3.4-snapshot is currently failing repository closure test: > > http://jenkins.ovirt.org/job/repos_3.4_check-closure_merged/DISTRIBUTION=centos6/80/console > > > > due to missing vdsm packages. > > > > VDSM is not published since May 29th due to job failing: > > http://jenkins.ovirt.org/job/vdsm_3.4_create-rpms_merged/ > > > > Note that > > http://jenkins.ovirt.org/view/Publishers/job/publish_ovirt_rpms_nightly_3.4 > > is not marked as failing also if a required package is missing. > > > > Can infra take care of the publisher job and vdsm team of the failing > > build? > > Thanks, > > Looks like we need to update the cpopen package to 1.3-3 on the F20 host. > > Background: http://lists.ovirt.org/pipermail/devel/2014-June/007813.html In case it was not clear - the cpopen bug is the reason of recent failures. Please join me in giving karma to https://admin.fedoraproject.org/updates/FEDORA-2014-7758/python-cpopen-1.3-3.fc20 so it can be pushed to Fedora 20. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] [QE] [ACTION NEEDED] oVirt 3.5.0 Test Day wiki
Il 26/06/2014 13:00, Lior Vernia ha scritto: > I edited the document earlier this week, but today tried again and got > the following error: > > "You do not have permission to edit this page, for the following reason: > The action you have requested is limited to users in the group: Users." > > Known issue? Did you logged in to the wiki today? If yes, I think this is a new issue. > > > On 23/06/14 17:23, Sandro Bonazzola wrote: >> Hi, >> as you should know we're going to have oVier 3.5 first test day on Jul 1st. >> Maintainers and community, please start filling test day wiki [1] >> with relevant tests needed. >> >> [1] http://www.ovirt.org/OVirt_3.5_TestDay >> -- 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] [QE] [ACTION NEEDED] oVirt 3.5.0 Test Day wiki
I edited the document earlier this week, but today tried again and got the following error: "You do not have permission to edit this page, for the following reason: The action you have requested is limited to users in the group: Users." Known issue? On 23/06/14 17:23, Sandro Bonazzola wrote: > Hi, > as you should know we're going to have oVier 3.5 first test day on Jul 1st. > Maintainers and community, please start filling test day wiki [1] > with relevant tests needed. > > [1] http://www.ovirt.org/OVirt_3.5_TestDay > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Engine - Changes to various issues around commands and queries construction and internal execution - please read
Hi all,
Thanks to the help of Alon, oved, Tal, Moti, Arik and others, the following
changes were introduced:
1. Internal commands invocation -
When invoking an internal command from a command, please use the following :
Instead of Backend.getInstance().runInternalAction...
Use
runInternalAction - a new method that was introdced at CommandBase.
This method has two variants - one that accepts command context, and the other
that does not have a command contet -
runInternalAction(VdcActionType,VdcActionParametersBase,CommandContext)
and
runInternalAction(VdcActionType,VdcActionParametersBase)
If CommandContext is not passed the context at the calling command will be
cloned and set at the child command.
If a Command context is pased - it should be the responsibility of the caller
to clone, however, this will give the caller some degree of freedom to
determine whether various
parts of the context will be cloned, or not.
Examples:
runInternalAction(VdcActionType.AddPermission, permissionParams) has the same
effect as : runInternlAction(VdcActionType.AddPermissiosn, permissionParams,
getContext().clone())
runInternlAction(VdcActionType.AddPermissiosn, permissionParams,
getContext().clone().withoutCompensationContext()) - will cause the
compensation context to be reset, and let the child command determine the value
of compensation context (at handleTransactivity method).
The complete list of "context alteration methods" are -
withCompensationContext(CompensationContext) , withoutCompensationContext()
withLock(EngineLock), withoutLock()
withExecutionContext(ExecutionContext), withoutExecutionContext() - bare in
mind that all these follow the chaining method "design pattern" [1] (I would
like to thank Moti for the naming suggestions)
two methods for running InternalAction with context for tasks were created:
runInternalActionWithTasksContext(VdcActionType, VdcActionParametersBase)
runInternalActionWithTasksContext(VdcActionType, VdcActionParametersBase,
EngineLock)
These methods use ExecutionHandler.createDefaultContextForTasks to create the
relevant command context to be passed to the child command.
runInternalMultipleActions was introduced to command base in a similar manner,
with 3 versions:
runInternalMultipleActions(VdcActionType, ArrayList)
runInternalMultipleActions(VdcActionType, ArrayList,
ExecutionContext)
runInternalMultipleActions(VdcActionType, ArrayList,
CommandContext)
2. Queries invocation -
runInternalQuery(VdcQueryType, VdcQueryParametersBase) was introduced to
command base.
Basically it takes the engine context from the current command context, and
runs the internal query with it.
EngineContext is the context which should hold all the common attributes to our
flows at engine - currently it holds the engineSessionId, working towards
moving correlationId to it as well.
3. Commands & Queries coding
Each internal query should have a ctor that takes the parameters, and also the
engine context .
As some of the queries are both internal and non internal you may have two
ctors - one with parameters only, one with parameters and EngineContext
for example
public class GetUnregisteredDiskQuery extends QueriesCommandBase {
public GetUnregisteredDiskQuery(P parameters) {
this(parameters, null);
}
public GetUnregisteredDiskQuery(P parameters, EngineContext context) {
super(parameters, context);
}
Notice that the ctor without the context calls the one with the context.
Same happens at Commands:
public RemovePermissionCommand(T parameters) {
this(parameters, null);
}
public RemovePermissionCommand(T parameters, CommandContext commandContext)
{
super(parameters, commandContext);
}
4. runVdsCommand was introduced to CommandBase as well
runVdsCommand(VDSCommandType, VdsCommandParameters) - currently this just runs
the vds command on vds broker, working on propagating the engine context via
vds broker as well.
Please use the above in your code. If you see any issues , or places where its
problematic to use, feel free to contact me.
[1]
http://en.wikipedia.org/wiki/Method_chaining
___
Devel mailing list
Devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ACTION REQUIRED] ovirt-3.4-snapshot repository closure failures
- Original Message - > From: "Sandro Bonazzola" > To: devel@ovirt.org, "infra" > Sent: Thursday, June 26, 2014 11:56:19 AM > Subject: [ACTION REQUIRED] ovirt-3.4-snapshot repository closure failures > > Hi, > ovirt-3.4-snapshot is currently failing repository closure test: > http://jenkins.ovirt.org/job/repos_3.4_check-closure_merged/DISTRIBUTION=centos6/80/console > > due to missing vdsm packages. > > VDSM is not published since May 29th due to job failing: > http://jenkins.ovirt.org/job/vdsm_3.4_create-rpms_merged/ > > Note that > http://jenkins.ovirt.org/view/Publishers/job/publish_ovirt_rpms_nightly_3.4 > is not marked as failing also if a required package is missing. > > Can infra take care of the publisher job and vdsm team of the failing build? > Thanks, Looks like we need to update the cpopen package to 1.3-3 on the F20 host. Background: http://lists.ovirt.org/pipermail/devel/2014-June/007813.html -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] [ACTION REQUIRED] ovirt-3.4-snapshot repository closure failures
Hi, ovirt-3.4-snapshot is currently failing repository closure test: http://jenkins.ovirt.org/job/repos_3.4_check-closure_merged/DISTRIBUTION=centos6/80/console due to missing vdsm packages. VDSM is not published since May 29th due to job failing: http://jenkins.ovirt.org/job/vdsm_3.4_create-rpms_merged/ Note that http://jenkins.ovirt.org/view/Publishers/job/publish_ovirt_rpms_nightly_3.4 is not marked as failing also if a required package is missing. Can infra take care of the publisher job and vdsm team of the failing 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
