Description of problem: In order to remove the master domain we need to provide a different tasks infrastructure that is not relying on the master file-system persistency.
Fede, I understand entirely theis FRE although this should be divided into several separate bugs. 1 - vdsm-infra - for the task framework to stop persisting tasks onto the master file system 2 - vdsm-storage - get rid of master file-system (this also related to the reconstruct master flow ... and probably should depend on #1 3 - engine-storage - handle the irsBroker handling on engine according to the new flows 4 - infra-engine - add a new interface to enable querying the vdsm for specific objects statuses after failing async task. 5 - storage-engine - utilize #4 for all storage flows So this RFE is about storage and infra should own some of the tasks as listed above. Can you please open the appropriate bugs
(In reply to Barak from comment #1) > Fede, > > I understand entirely theis FRE although this should be divided into several > separate bugs. > > 1 - vdsm-infra - for the task framework to stop persisting tasks onto the > master file system Bug 1082498 > 2 - vdsm-storage - get rid of master file-system (this also related to the > reconstruct master flow ... and probably should depend on #1 Bug 1082502 > 3 - engine-storage - handle the irsBroker handling on engine according to > the new > flows Bug 1082503 (note: same as 5 for now) > 4 - infra-engine - add a new interface to enable querying the vdsm for > specific objects statuses after failing async task. Bug 1082501 > 5 - storage-engine - utilize #4 for all storage flows Bug 1082503 (note: same as 3 for now) Full dependency tree at: https://bugzilla.redhat.com/showdependencytree.cgi?id=1080372
Should this be on post? can you add the patches?
Adam is about to introduce a new jobs infrastructure, the relevant patches should be added to the tracker in this bz. moving the needinfo? on him.
Gerrit patches 45381 and 44857 provide the internal mechanism (based on existing v2v jobs infrastructure). Yet to be posted are patches to expose an actual API to engine for this. Those are forthcoming.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
This bug was accidentally moved from POST to MODIFIED via an error in automation, please see mmccune with any questions
Adam, with the introduction of ./lib/vdsm/jobs.py, shouldn't this be moved to MODIFIED?
Is there any feature page for this RFE? We need to understand the scope of this and what needs to be covered from QE side
(In reply to Raz Tamir from comment #10) > Is there any feature page for this RFE? > We need to understand the scope of this and what needs to be covered from QE > side I'm changing it to a CodeChange - the interesting thing to test is its use - the move of commands to HSM, which have their own feature pages. There you'll have plenty to test, including negative scenarios.
(In reply to Yaniv Kaul from comment #11) > (In reply to Raz Tamir from comment #10) > > Is there any feature page for this RFE? > > We need to understand the scope of this and what needs to be covered from QE > > side > > I'm changing it to a CodeChange - the interesting thing to test is its use - > the move of commands to HSM, which have their own feature pages. > There you'll have plenty to test, including negative scenarios. There is engine side changes on progress and tasks that need a feature page. I don't consider this a code change.
Adam - any feature page for this?
Should this be MODIFIED?
As Yaniv Kaul stated, this is infrastructure that can only be tested by way of the flows which use it including: Move disk and cold merge.
Adam, I think we should write a small doc text on that feature
Hi Adam. Can you confirm that this feature is an infrastructure change only, and does not require any updates to the documentation.
I've added The requires_doc_text:? flag and proposed some doc text to describe the user-visible aspects of this feature. Please see the relevant parts of the bug.
Tested the following 4 commands with the new HSM infrastructure: Cold Move Cold Merge Create Cloned VM from Template Moving to VERIFIED
Yes it is random