[ovirt-devel] Re: discussing the future of the upgrade suite in ost

2018-10-08 Thread Martin Perina 
On Mon, Oct 8, 2018 at 1:41 PM Eyal Edri  wrote:

>
>
> On Mon, Oct 8, 2018 at 1:00 PM Yedidyah Bar David  wrote:
>
>> On Wed, Oct 3, 2018 at 3:51 PM Dafna Ron  wrote:
>> >
>> > Hi All,
>> >
>> > I was reviewing the upgrade suites in ost and there are some issues
>> that I am seeing in the suite tests-scenarios which I want to discuss and
>> decide the future of.
>> >
>> > At it current state, I think we should remove the upgrade suite or most
>> of the post test-scenarios as it is not testing what it should.
>>
>> Nothing at all, of what it should? Or not enough?
>>
>> >
>> > The tests currently only test engine upgrade and basic sanity after the
>> upgrade.
>> > This is problematic in a few ways:
>> >
>> > 1. upgrade should test the upgrade of rhv and not just a clean engine
>> upgrade (i.e host, storage, vm).
>>
>> This sounds to me like missing functionality, not a reason to remove
>> it altogether.
>>
>> > 2. as we have limited resources I do not think that the upgrade suite
>> should be longer then the basic suite (and as we are currently running the
>> basic suite after the upgrade it is longer)
>>
>> How often do we run it? If it's a significant burden on the CI
>> systems, perhaps run it only once per day, or even less.
>>
>
> We currently gate with it on CQ along with the basic suite.
> We we think the suite in its current status isn't that beneficial, we can
> move it to nightly and move it from CQ, but then we won't be gating upgrade
> issues
> from reaching to QE, is that what we want?
>
> Sandro, do you want to move the upgrade suite to nightly mode until it'll
> have more functionality?
>

I plan to add more tests, which comes from infra team responsibilities
(like upgrade of the host, upgrade the whole cluster, ...). I will post a
design document till end of week ...

>
>
>>
>> >
>> > That brings me to question what should be essential to test in upgrade
>> in the CI?
>>
>> That's a very good question, but not sure it's related to the previous
>> point.
>>
>> If you think we need more functionality, and I think I agree, open a bug.
>>
>> If current suite causes too much load, run it less frequently.
>>
>> > I would also need someone in dev to volunteer and take ownership of the
>> testing scenarios for upgrade - is there anyone that can help?
>>
>> I guess I can try looking after the current suite (mainly testing
>> engine-setup's upgrade functionality). Not sure about new
>> functionality (hosts, storage etc).
>>
>> >
>> > Thanks,
>> > Dafna
>> >
>> >
>> >
>> >
>> >
>> >
>> > ___
>> > Infra mailing list -- in...@ovirt.org
>> > To unsubscribe send an email to infra-le...@ovirt.org
>> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> > oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> > List Archives:
>> https://lists.ovirt.org/archives/list/in...@ovirt.org/message/IMWTTWFIGJM3OBBOO6WVFSWMGHNPLOPF/
>>
>>
>>
>> --
>> Didi
>> ___
>> Infra mailing list -- in...@ovirt.org
>> To unsubscribe send an email to infra-le...@ovirt.org
>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>> oVirt Code of Conduct:
>> https://www.ovirt.org/community/about/community-guidelines/
>> List Archives:
>> https://lists.ovirt.org/archives/list/in...@ovirt.org/message/GTUFYRH23OKAAEZCAQEA5BOPNSEXGBGU/
>>
>
>
> --
>
> Eyal edri
>
>
> MANAGER
>
> RHV/CNV DevOps
>
> EMEA VIRTUALIZATION R
>
>
> Red Hat EMEA 
>  TRIED. TESTED. TRUSTED. 
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
> ___
> Devel mailing list -- devel@ovirt.org
> To unsubscribe send an email to devel-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/devel@ovirt.org/message/KLXZDWIQOXSTFUEPJ2BLR3VIGAQXWC7P/
>


-- 
Martin Perina
Associate Manager, Software Engineering
Red Hat Czech s.r.o.
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/XR76IAH2RA6JKZAZKU6RFAAZIETTZKXG/

[ovirt-devel] VDSM API schema inconsistencies

2018-10-08 Thread Marcin Sobczyk 

Hi,

when I was working on BZ#1624306 it turned out, that even if I'd fix the 
help-printing code in vdsm-client, there's still a lot of 
inconsistencies in API's schema files.


After some investigation, I found that there's a code for reporting 
schema inconsistencies, but it's turned off because it bloats the logs. 
There's also a "strict" mode that raises an exception each time an 
inconsistency is found, but it's also off because there's so many of them.


I think that no one wants to maintain both: the actual code and schema 
files. My idea would be to make the schema derived from the code at 
build time as a long-term effort. Before we can do that though, we need 
to address the inconsistencies first.


https://gerrit.ovirt.org/#/q/status:open+project:vdsm+branch:master+topic:vdsm-api-schema-debug

This is a series of patches that helps fixing schema issues. What it 
does, is it adds a bunch of information from stack to vastly ease the 
process of fixing them. The logging level is also changed from 'WARNING' 
to 'DEBUG'. Here's an example of a logged entry:


Host.setKsmTune
With message: Required property pages_to_scan is not provided when 
calling Host.setKsmTune

With backtrace: [
    [
    "_verify_object_type",
    {
    "call_arg_keys":[
    "merge_across_nodes",
    "run"
    ],
    "schema_type_name":"KsmTuneParams"
    }
    ],
    [
    "_verify_complex_type",
    {
    "schema_type_type":"object"
    }
    ]
]

To make it work, a patch for OST's 'basic-master-suite' is on the way 
that switches 'schema.inconsistency' logger's logging level do 'DEBUG'. 
That way, we can find all reported errors in 'vdsm-schema-error.log' files.


An initial report that groups reported errors by namespaces/methods has 
also been made. Please note, that an implementation that completely 
avoids error duplicates is really hard and IMHO not worth the effort. 
You can find the results here:


 * Host: https://pastebin.com/YM2XnvTV
 * Image: https://pastebin.com/GRc1yErL
 * LVMVolumeGroup: https://pastebin.com/R1276gTu
 * SDM: https://pastebin.com/P3tfYEDD
 * StorageDomain: https://pastebin.com/Q0DxKgF5
 * StoragePool: https://pastebin.com/VXFWpfRC
 * VM: https://pastebin.com/tDC60c29
 * Volume: https://pastebin.com/TYkr9Zsd
 * |jobs|: https://pastebin.com/jeXpYyz9
 * |virt|: https://pastebin.com/nRREuEub

Regards, Marcin

___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/NW67DZSIMQTFB4HG6SDCACFFOY6CB2YN/

[ovirt-devel] Re: discussing the future of the upgrade suite in ost

2018-10-08 Thread Eyal Edri 
On Mon, Oct 8, 2018 at 1:00 PM Yedidyah Bar David  wrote:

> On Wed, Oct 3, 2018 at 3:51 PM Dafna Ron  wrote:
> >
> > Hi All,
> >
> > I was reviewing the upgrade suites in ost and there are some issues that
> I am seeing in the suite tests-scenarios which I want to discuss and decide
> the future of.
> >
> > At it current state, I think we should remove the upgrade suite or most
> of the post test-scenarios as it is not testing what it should.
>
> Nothing at all, of what it should? Or not enough?
>
> >
> > The tests currently only test engine upgrade and basic sanity after the
> upgrade.
> > This is problematic in a few ways:
> >
> > 1. upgrade should test the upgrade of rhv and not just a clean engine
> upgrade (i.e host, storage, vm).
>
> This sounds to me like missing functionality, not a reason to remove
> it altogether.
>
> > 2. as we have limited resources I do not think that the upgrade suite
> should be longer then the basic suite (and as we are currently running the
> basic suite after the upgrade it is longer)
>
> How often do we run it? If it's a significant burden on the CI
> systems, perhaps run it only once per day, or even less.
>

We currently gate with it on CQ along with the basic suite.
We we think the suite in its current status isn't that beneficial, we can
move it to nightly and move it from CQ, but then we won't be gating upgrade
issues
from reaching to QE, is that what we want?

Sandro, do you want to move the upgrade suite to nightly mode until it'll
have more functionality?


>
> >
> > That brings me to question what should be essential to test in upgrade
> in the CI?
>
> That's a very good question, but not sure it's related to the previous
> point.
>
> If you think we need more functionality, and I think I agree, open a bug.
>
> If current suite causes too much load, run it less frequently.
>
> > I would also need someone in dev to volunteer and take ownership of the
> testing scenarios for upgrade - is there anyone that can help?
>
> I guess I can try looking after the current suite (mainly testing
> engine-setup's upgrade functionality). Not sure about new
> functionality (hosts, storage etc).
>
> >
> > Thanks,
> > Dafna
> >
> >
> >
> >
> >
> >
> > ___
> > Infra mailing list -- in...@ovirt.org
> > To unsubscribe send an email to infra-le...@ovirt.org
> > Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> > oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> > List Archives:
> https://lists.ovirt.org/archives/list/in...@ovirt.org/message/IMWTTWFIGJM3OBBOO6WVFSWMGHNPLOPF/
>
>
>
> --
> Didi
> ___
> Infra mailing list -- in...@ovirt.org
> To unsubscribe send an email to infra-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct:
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives:
> https://lists.ovirt.org/archives/list/in...@ovirt.org/message/GTUFYRH23OKAAEZCAQEA5BOPNSEXGBGU/
>


-- 

Eyal edri


MANAGER

RHV/CNV DevOps

EMEA VIRTUALIZATION R


Red Hat EMEA 
 TRIED. TESTED. TRUSTED. 
phone: +972-9-7692018
irc: eedri (on #tlv #rhev-dev #rhev-integ)
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/KLXZDWIQOXSTFUEPJ2BLR3VIGAQXWC7P/

[ovirt-devel] Re: discussing the future of the upgrade suite in ost

2018-10-08 Thread Yedidyah Bar David 
On Wed, Oct 3, 2018 at 3:51 PM Dafna Ron  wrote:
>
> Hi All,
>
> I was reviewing the upgrade suites in ost and there are some issues that I am 
> seeing in the suite tests-scenarios which I want to discuss and decide the 
> future of.
>
> At it current state, I think we should remove the upgrade suite or most of 
> the post test-scenarios as it is not testing what it should.

Nothing at all, of what it should? Or not enough?

>
> The tests currently only test engine upgrade and basic sanity after the 
> upgrade.
> This is problematic in a few ways:
>
> 1. upgrade should test the upgrade of rhv and not just a clean engine upgrade 
> (i.e host, storage, vm).

This sounds to me like missing functionality, not a reason to remove
it altogether.

> 2. as we have limited resources I do not think that the upgrade suite should 
> be longer then the basic suite (and as we are currently running the basic 
> suite after the upgrade it is longer)

How often do we run it? If it's a significant burden on the CI
systems, perhaps run it only once per day, or even less.

>
> That brings me to question what should be essential to test in upgrade in the 
> CI?

That's a very good question, but not sure it's related to the previous point.

If you think we need more functionality, and I think I agree, open a bug.

If current suite causes too much load, run it less frequently.

> I would also need someone in dev to volunteer and take ownership of the 
> testing scenarios for upgrade - is there anyone that can help?

I guess I can try looking after the current suite (mainly testing
engine-setup's upgrade functionality). Not sure about new
functionality (hosts, storage etc).

>
> Thanks,
> Dafna
>
>
>
>
>
>
> ___
> Infra mailing list -- in...@ovirt.org
> To unsubscribe send an email to infra-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: 
> https://www.ovirt.org/community/about/community-guidelines/
> List Archives: 
> https://lists.ovirt.org/archives/list/in...@ovirt.org/message/IMWTTWFIGJM3OBBOO6WVFSWMGHNPLOPF/



-- 
Didi
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/GTUFYRH23OKAAEZCAQEA5BOPNSEXGBGU/

[ovirt-devel] Re: Request for reviews - vdsm-tool update-volume

2018-10-08 Thread Germano Veit Michel 
All passing CI and rebased to latest master.
Reviews are welcome.

On Tue, Sep 25, 2018 at 8:01 AM Germano Veit Michel 
wrote:

>
>
> On Tue, Sep 25, 2018 at 7:59 AM Dan Kenigsberg  wrote:
>
>>
>>
>> On Tue, Sep 25, 2018 at 12:49 AM Germano Veit Michel 
>> wrote:
>>
>>>
>>>
>>> On Mon, Sep 24, 2018 at 11:56 PM Dan Kenigsberg 
>>> wrote:
>>>
 On Mon, Sep 24, 2018 at 9:24 AM Germano Veit Michel 
 wrote:
 >
 > Hi,
 >
 > I'm working an a tool (vdsm-tool update-volume) to make modifying SD
 metadata easier and more importantly, safer. This is very useful to recover
 from failed LSMs or snapshot issues.
 >
 > The plan is to use the VDSM API (modified by some of these patches)
 and add a tool (vdsm-tool) that talks to the API and modifies the volumes
 metadata as required by the user. Currently this is done manually, i.e.:
 looking at MD_XXX tags, doing dd, sed and then dd back to the storage. Any
 wrong argument (like a skip in place of a seek) can ruin the entire
 metadata, so this tool can be quite handy.
 >
 > The code is not necessarily 100% finished yet, but I've been testing
 this for some time and it seems ok from a functional point of view. I'm
 just not sure everything I did (especially inside VDSM, example 94366) is
 correct. Your comments on what can/should be improved are very welcome at
 this point. Please see this series and help reviewing it.
 >
 >
 https://gerrit.ovirt.org/#/q/topic:update-volume+(status:open+OR+status:merged)
 > https://gerrit.ovirt.org/#/c/93258/

 I am not a maintainer of vdsm.storage, but I can say that I'm missing
 a high-level description of the change that you are suggesting, and
 its motivation. When do you see a need to manually change the metadata
 of volumes? Shouldn't we fix the bug that causes this need?

>>>
>>> Ohh, sorry. I thought it was obvious. This is for snapshot related
>>> issues. These bugs have been present for a while, they are fixed but new
>>> ones come up. In the end downstream support is constantly manually
>>> repairing chains. This is why this tool is needed. Both to make those
>>> changes safer and to save time.
>>>
>>>
 I personally have a deep resentment to a "force" flags - not just
 here, but everywhere. It is never clear what is being forced. Some
 things cannot or should not be forced.

>>>
>>> Nir already suggested to remove the force flag. I don't mind, the idea
>>> was just to keep the old behavior the same if the force flag is not used.
>>>
>>>

 One last note: a CI+1 gives a positive psychological vibe to your
 reviewer.

>>> Yes, I know. Most of them have CI+1. They keep randomly failing on FC28
>>> (but EL7 succeeds) on every push.
>>>
>>
>> We used to have a regression in iproute on Fedora few weeks ago. a rebase
>> on master may help. It is your responsibility to find why fc28 fails, as we
>> cannot merge a patch that does not pass there.
>>
>
> Thanks, I'll rebase them. Hopefully thats it.
>
>
>>
>> And there is just one that is constantly failing, I even sent an email to
>>> this list ("Jenkins help") to try to better understand why, but no one
>>> replied yet. It seems to be complaining about an object not having a
>>> member, but the member is created at runtime (based on api schema).
>>>
>>
___
Devel mailing list -- devel@ovirt.org
To unsubscribe send an email to devel-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/devel@ovirt.org/message/FUKUIR3EGDIBPLFY3YZULF4J2VSWF36K/