[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
Re: [ovirt-devel] [ACTION REQUIRED] ovirt-3.4-snapshot repository closure failures
- Original Message - From: Sandro Bonazzola sbona...@redhat.com To: devel@ovirt.org, infra in...@ovirt.org 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] 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, ArrayListVdcActionParametersBase)
runInternalMultipleActions(VdcActionType, ArrayListVdcActionParametersBase,
ExecutionContext)
runInternalMultipleActions(VdcActionType, ArrayListVdcActionParametersBase,
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 GetUnregisteredDiskQueryP extends
GetUnregisteredDiskQueryParameters extends QueriesCommandBaseP {
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] [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
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] [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 sbona...@redhat.com To: devel@ovirt.org, infra in...@ovirt.org 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
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] 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] 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] [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
