Re: [ovirt-devel] Lowering the bar for wiki contribution?
On Wed, Jan 4, 2017 at 8:57 AM, Roy Golan wrote: > I'm getting the feeling I'm not alone in this, authoring and publishing a > wiki page isn't as used to be for long time. > > I want to suggest a bit lighter workflow: > > 1. Everyone can merge their page - (it's a wiki) > Same as with (public and open) code, no one has the motivation to > publish a badly written > wiki page under their name. True, it can have an impact, but not as with > broken code > > 2. Use Page-Status marker > The author first merges the draft. Its now out there and should be > updated as time goes and its > status is DRAFT. Maintainers will come later and after review would > change the status to > PUBLISH. That could be a header in on the page: > --- > page status: DRAFT/PUBLISH > --- > > Simple I think, and should work. > > Sounds very good. +1 > > > > ___ > 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] Lowering the bar for wiki contribution?
On 04/01/17 09:57 +0200, Roy Golan wrote: I'm getting the feeling I'm not alone in this, authoring and publishing a wiki page isn't as used to be for long time. I want to suggest a bit lighter workflow: 1. Everyone can merge their page - (it's a wiki) Same as with (public and open) code, no one has the motivation to publish a badly written wiki page under their name. True, it can have an impact, but not as with broken code 2. Use Page-Status marker The author first merges the draft. Its now out there and should be updated as time goes and its status is DRAFT. Maintainers will come later and after review would change the status to PUBLISH. That could be a header in on the page: --- page status: DRAFT/PUBLISH --- Simple I think, and should work. +1, github's contribution workflow is terrible and doesn't make any sense for wiki pages. ___ 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] Lowering the bar for wiki contribution?
On Wed, Jan 4, 2017 at 9:57 AM, Roy Golan wrote: > I'm getting the feeling I'm not alone in this, authoring and publishing a > wiki page isn't as used to be for long time. > Indeed. Several changes in the process have made it more difficult than it probably should be. > > I want to suggest a bit lighter workflow: > > 1. Everyone can merge their page - (it's a wiki) > It's not really a wiki. Perhaps parts of the site should be? > Same as with (public and open) code, no one has the motivation to > publish a badly written > wiki page under their name. True, it can have an impact, but not as with > broken code > Does everyone have merge rights in public and open code? > > 2. Use Page-Status marker > The author first merges the draft. Its now out there and should be > updated as time goes and its > status is DRAFT. Maintainers will come later and after review would > change the status to > PUBLISH. That could be a header in on the page: > --- > page status: DRAFT/PUBLISH > --- > Interesting idea. How do we ensure we are not left with draft content all over? Y. > > Simple I think, and should work. > > > > > ___ > 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 does findbugs work?
> On 21 Dec 2016, at 12:23, Eyal Edri wrote: > > You can see from the output the maven plugin is running [1], > Have you checked the filters that are ignoring 'false positives'? maybe those > needs to be updated? > > The are in the 'exclude-filters.xml' files under each project and maintained > by the ovirt-engine maintainers. AFAICT no, it’s not excluded, but checking whole ovirt-engine on coverity site I can’t seem to find the whole file. I dunno, I’m not much of an expert, but I do not see any exclude anywhere and there are bunch of other files in the same dir… anyone any idea? > > > > [1] 08:13:21 [FINDBUGS] Collecting findbugs analysis files... > 08:13:23 [FINDBUGS] Finding all files that match the pattern > **/findbugsXml.xml > 08:13:23 [FINDBUGS] Parsing 34 files in > /home/jenkins/workspace/ovirt-engine_master_find-bugs_created > 08:13:23 [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt-engine_master_find-bugs_created/ovirt-engine/backend/manager/extensions-tool/target/findbugsXml.xml > with 0 unique warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt-engine_master_find-bugs_created/ovirt-engine/backend/manager/modules/aaa/target/findbugsXml.xml > with 0 unique warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt-engine_master_find-bugs_created/ovirt-engine/backend/manager/modules/auth-plugin/target/findbugsXml.xml > with 0 unique warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt-engine_master_find-bugs_created/ovirt-engine/backend/manager/modules/bll/target/findbugsXml.xml > with 0 unique warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt-engine_master_find-bugs_created/ovirt-engine/backend/manager/modules/branding/target/findbugsXml.xml > with 0 unique warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt-engine_master_find-bugs_created/ovirt-engine/backend/manager/modules/builtin-extensions/target/findbugsXml.xml > with 0 unique warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt-engine_master_find-bugs_created/ovirt-engine/backend/manager/modules/common/target/findbugsXml.xml > with 0 unique warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt-engine_master_find-bugs_created/ovirt-engine/backend/manager/modules/compat/target/findbugsXml.xml > with 0 unique warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt-engine_master_find-bugs_created/ovirt-engine/backend/manager/modules/dal/target/findbugsXml.xml > with 0 unique warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt-engine_master_find-bugs_created/ovirt-engine/backend/manager/modules/docs/target/findbugsXml.xml > with 0 unique warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt-engine_master_find-bugs_created/ovirt-engine/backend/manager/modules/enginesso/target/findbugsXml.xml > with 0 unique warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt-engine_master_find-bugs_created/ovirt-engine/backend/manager/modules/extensions-api-root/extensions-api/target/findbugsXml.xml > with 0 unique warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt-engine_master_find-bugs_created/ovirt-engine/backend/manager/modules/extensions-manager/target/findbugsXml.xml > with 0 unique warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt-engine_master_find-bugs_created/ovirt-engine/backend/manager/modules/logger/target/findbugsXml.xml > with 0 unique warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt-engine_master_find-bugs_created/ovirt-engine/backend/manager/modules/restapi/interface/common/jaxrs/target/findbugsXml.xml > with 0 unique warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt-engine_master_find-bugs_created/ovirt-engine/backend/manager/modules/restapi/interface/definition/target/findbugsXml.xml > with 0 unique warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt-engine_master_find-bugs_created/ovirt-engine/backend/manager/modules/restapi/jaxrs/target/findbugsXml.xml > with 0 unique warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file > /home/jenkins/workspace/ovirt-engine_master_find-bugs_created/ovirt-engine/backend/manager/modules/restapi/types/target/findbugsXml.xml > with 0 unique warnings and 0 duplicates. > 08:13:
Re: [ovirt-devel] Manageiq ova upload is failing
On Wed, Jan 4, 2017 at 6:51 AM, Michal Skrivanek wrote:
>> On 03 Jan 2017, at 23:59, Piotr Kliczewski
>> wrote:
>>
>> All,
>>
>> I want to upload manageiq ova from [1] when I attempted to do it I see:
>>
>> on the engine side:
>>
>> 2017-01-03 23:43:59,318+01 ERROR
>> [org.ovirt.engine.core.bll.GetVmFromOvaQuery] (default task-1)
>
> You're falling for the confusing trap we created:)
> OVA in oVirt is for vmware ova conversion, not for importing ovirt
> native-like images. For that you need to use the old and cumbersome
> flow of export/import via export domain
I looked for it initially and noticed that ovirt-image-uploader is not
there in 4.1.
Is there any other way to do it?
>
>> [33a1d8b5-8cec-4b00-9a35-ee9f1d9635b2] Exception:
>> org.ovirt.engine.core.common.errors.EngineException: EngineException:
>> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException:
>> VDSGenericException: VDSErrorException: Failed to GetOvaInfoVDS, error
>> = Error parsing ovf information: no memory size, code = -32603 (Failed
>> with error unexpected and code 16)
>>at
>> org.ovirt.engine.core.bll.VdsHandler.handleVdsResult(VdsHandler.java:118)
>> [bll.jar:]
>>at
>> org.ovirt.engine.core.bll.VDSBrokerFrontendImpl.runVdsCommand(VDSBrokerFrontendImpl.java:33)
>> [bll.jar:]
>>at
>> org.ovirt.engine.core.bll.QueriesCommandBase.runVdsCommand(QueriesCommandBase.java:242)
>> [bll.jar:]
>>at
>> org.ovirt.engine.core.bll.GetVmFromOvaQuery.getVmInfoFromOvaFile(GetVmFromOvaQuery.java:24)
>> [bll.jar:]
>>at
>> org.ovirt.engine.core.bll.GetVmFromOvaQuery.executeQueryCommand(GetVmFromOvaQuery.java:20)
>> [bll.jar:]
>>at
>> org.ovirt.engine.core.bll.QueriesCommandBase.executeCommand(QueriesCommandBase.java:110)
>> [bll.jar:]
>>at
>> org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:33)
>> [dal.jar:]
>>at
>> org.ovirt.engine.core.bll.executor.DefaultBackendQueryExecutor.execute(DefaultBackendQueryExecutor.java:14)
>> [bll.jar:]
>>at org.ovirt.engine.core.bll.Backend.runQueryImpl(Backend.java:579)
>> [bll.jar:]
>>at org.ovirt.engine.core.bll.Backend.runQuery(Backend.java:547)
>> [bll.jar:]
>>
>> on the vdsm side:
>>
>> 2017-01-03 23:43:58,437 ERROR (jsonrpc/0) [jsonrpc.JsonRpcServer]
>> Internal server error (__init__:552)
>> Traceback (most recent call last):
>> File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line
>> 547, in _handle_request
>>res = method(**params)
>> File "/usr/lib/python2.7/site-packages/vdsm/rpc/Bridge.py", line
>> 198, in _dynamicMethod
>>result = fn(*methodArgs)
>> File "/usr/share/vdsm/API.py", line 1493, in getExternalVmFromOva
>>return v2v.get_ova_info(ova_path)
>> File "/usr/lib/python2.7/site-packages/vdsm/v2v.py", line 226, in
>> get_ova_info
>>_add_general_ovf_info(vm, root, ns, ova_path)
>> File "/usr/lib/python2.7/site-packages/vdsm/v2v.py", line 1225, in
>> _add_general_ovf_info
>>raise V2VError('Error parsing ovf information: no memory size')
>> V2VError: Error parsing ovf information: no memory size
>>
>> Is our code not parsing correctly or manageiq guys publish not correct file?
>>
>> I am using:
>> ovirt-engine
>> Version : 4.1.0
>> Release : 0.3.beta2.20161221085908.el7.centos
>> vdsm
>> Version : 4.18.999
>> Release : 1218.gitd36143e.el7.centos
>>
>> Thanks,
>> Piotr
>>
>>
>> [1] http://manageiq.org/download/
>> ___
>> 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] Lowering the bar for wiki contribution?
On 4 January 2017 at 09:57, Roy Golan wrote: > I'm getting the feeling I'm not alone in this, authoring and publishing a > wiki page isn't as used to be for long time. Maybe we're using the wrong tool for the job? The site is intentionally not a wiki to allow OSAS some editorial control over what goes on the public site. I'm guessing that the scenario you are talking about here is a developer looking to create a preliminary design document for further discussion. Maybe we need a different tool and process for that? -- Barak Korren bkor...@redhat.com RHCE, RHCi, RHV-DevOps Team https://ifireball.wordpress.com/ ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Manageiq ova upload is failing
On Wed, Jan 4, 2017 at 9:39 AM, Piotr Kliczewski wrote:
> On Wed, Jan 4, 2017 at 6:51 AM, Michal Skrivanek
> wrote:
> >> On 03 Jan 2017, at 23:59, Piotr Kliczewski
> wrote:
> >>
> >> All,
> >>
> >> I want to upload manageiq ova from [1] when I attempted to do it I see:
> >>
> >> on the engine side:
> >>
> >> 2017-01-03 23:43:59,318+01 ERROR
> >> [org.ovirt.engine.core.bll.GetVmFromOvaQuery] (default task-1)
> >
> > You're falling for the confusing trap we created:)
> > OVA in oVirt is for vmware ova conversion, not for importing ovirt
> > native-like images. For that you need to use the old and cumbersome
> > flow of export/import via export domain
>
> I looked for it initially and noticed that ovirt-image-uploader is not
> there in 4.1.
>
> Is there any other way to do it?
>
you should be able to go to webadmin to disks tab and upload it from there.
>
> >
> >> [33a1d8b5-8cec-4b00-9a35-ee9f1d9635b2] Exception:
> >> org.ovirt.engine.core.common.errors.EngineException: EngineException:
> >> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException:
> >> VDSGenericException: VDSErrorException: Failed to GetOvaInfoVDS, error
> >> = Error parsing ovf information: no memory size, code = -32603 (Failed
> >> with error unexpected and code 16)
> >>at org.ovirt.engine.core.bll.VdsHandler.handleVdsResult(
> VdsHandler.java:118)
> >> [bll.jar:]
> >>at org.ovirt.engine.core.bll.VDSBrokerFrontendImpl.
> runVdsCommand(VDSBrokerFrontendImpl.java:33)
> >> [bll.jar:]
> >>at org.ovirt.engine.core.bll.QueriesCommandBase.runVdsCommand(
> QueriesCommandBase.java:242)
> >> [bll.jar:]
> >>at org.ovirt.engine.core.bll.GetVmFromOvaQuery.
> getVmInfoFromOvaFile(GetVmFromOvaQuery.java:24)
> >> [bll.jar:]
> >>at org.ovirt.engine.core.bll.GetVmFromOvaQuery.
> executeQueryCommand(GetVmFromOvaQuery.java:20)
> >> [bll.jar:]
> >>at org.ovirt.engine.core.bll.QueriesCommandBase.executeCommand(
> QueriesCommandBase.java:110)
> >> [bll.jar:]
> >>at org.ovirt.engine.core.dal.VdcCommandBase.execute(
> VdcCommandBase.java:33)
> >> [dal.jar:]
> >>at org.ovirt.engine.core.bll.executor.
> DefaultBackendQueryExecutor.execute(DefaultBackendQueryExecutor.java:14)
> >> [bll.jar:]
> >>at org.ovirt.engine.core.bll.Backend.runQueryImpl(Backend.
> java:579)
> >> [bll.jar:]
> >>at org.ovirt.engine.core.bll.Backend.runQuery(Backend.java:547)
> >> [bll.jar:]
> >>
> >> on the vdsm side:
> >>
> >> 2017-01-03 23:43:58,437 ERROR (jsonrpc/0) [jsonrpc.JsonRpcServer]
> >> Internal server error (__init__:552)
> >> Traceback (most recent call last):
> >> File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line
> >> 547, in _handle_request
> >>res = method(**params)
> >> File "/usr/lib/python2.7/site-packages/vdsm/rpc/Bridge.py", line
> >> 198, in _dynamicMethod
> >>result = fn(*methodArgs)
> >> File "/usr/share/vdsm/API.py", line 1493, in getExternalVmFromOva
> >>return v2v.get_ova_info(ova_path)
> >> File "/usr/lib/python2.7/site-packages/vdsm/v2v.py", line 226, in
> get_ova_info
> >>_add_general_ovf_info(vm, root, ns, ova_path)
> >> File "/usr/lib/python2.7/site-packages/vdsm/v2v.py", line 1225, in
> >> _add_general_ovf_info
> >>raise V2VError('Error parsing ovf information: no memory size')
> >> V2VError: Error parsing ovf information: no memory size
> >>
> >> Is our code not parsing correctly or manageiq guys publish not correct
> file?
> >>
> >> I am using:
> >> ovirt-engine
> >> Version : 4.1.0
> >> Release : 0.3.beta2.20161221085908.el7.centos
> >> vdsm
> >> Version : 4.18.999
> >> Release : 1218.gitd36143e.el7.centos
> >>
> >> Thanks,
> >> Piotr
> >>
> >>
> >> [1] http://manageiq.org/download/
> >> ___
> >> 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] Lowering the bar for wiki contribution?
On Wed, Jan 4, 2017 at 10:51 AM, Barak Korren wrote: > On 4 January 2017 at 09:57, Roy Golan wrote: >> I'm getting the feeling I'm not alone in this, authoring and publishing a >> wiki page isn't as used to be for long time. > > Maybe we're using the wrong tool for the job? > The site is intentionally not a wiki to allow OSAS some editorial > control over what goes on the public site. > > I'm guessing that the scenario you are talking about here is a > developer looking to create a preliminary design document for further > discussion. Maybe we need a different tool and process for that? I agree, we are using the wrong tool for the job of putting initial design for discussion. For publishing user documentation the site is ok. I miss the wiki we had, it was easier to use for development of feature pages and developer documentation. Nir ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
[ovirt-devel] Can't find relative path for class "org.ovirt.engine.api.resource.VmDisksResource", will return null
Hello, In ovirt-system-tests results I can see engine log is flooded with messages like: 147: 40147:2017-01-03 21:45:13,837-05 ERROR [org.ovirt.engine.api.restapi.util.LinkHelper] (default task-22) [] Can't find relative path for class "org.ovirt.engine.api.resource.VmDisksResource", will return null There're 123 messages like (logging time is 15 mins). Is it expected to have too many ERROR messages? [1] http://jenkins.ovirt.org/job/ovirt_4.1_system-tests/28/artifact/exported-artifacts/test_logs/basic-suite-4.1/post-004_basic_sanity.py/lago-basic-suite-4-1-engine/_var_log_ovirt-engine/engine.log -- Pavel Zhukov Software Engineer RHEV Devops IRC: landgraf ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Can't find relative path for class "org.ovirt.engine.api.resource.VmDisksResource", will return null
On 01/04/2017 10:09 AM, Pavel Zhukov wrote: > > Hello, > > In ovirt-system-tests results I can see engine log is flooded with messages > like: > 147: 40147:2017-01-03 21:45:13,837-05 ERROR > [org.ovirt.engine.api.restapi.util.LinkHelper] (default task-22) [] Can't > find relative path for class "org.ovirt.engine.api.resource.VmDisksResource", > will return null > > There're 123 messages like (logging time is 15 mins). > > Is it expected to have too many ERROR messages? > > [1] > http://jenkins.ovirt.org/job/ovirt_4.1_system-tests/28/artifact/exported-artifacts/test_logs/basic-suite-4.1/post-004_basic_sanity.py/lago-basic-suite-4-1-engine/_var_log_ovirt-engine/engine.log > No, it isn't expected. It isn't very serious either. It means that the system isn't able to calculate a link for something. That needs to be fixed anyhow. Can you open a BZ? ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Lowering the bar for wiki contribution?
On 4 January 2017 at 11:06, Nir Soffer wrote: > On Wed, Jan 4, 2017 at 10:51 AM, Barak Korren wrote: > > On 4 January 2017 at 09:57, Roy Golan wrote: > >> I'm getting the feeling I'm not alone in this, authoring and publishing > a > >> wiki page isn't as used to be for long time. > > > > Maybe we're using the wrong tool for the job? > > The site is intentionally not a wiki to allow OSAS some editorial > > control over what goes on the public site. > > > > I'm guessing that the scenario you are talking about here is a > > developer looking to create a preliminary design document for further > > discussion. Maybe we need a different tool and process for that? > > I agree, we are using the wrong tool for the job of putting initial design > for discussion. > > For publishing user documentation the site is ok. > > I miss the wiki we had, it was easier to use for development of feature > pages and developer documentation. > Who is our OSAS contact these days? > Nir > ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Lowering the bar for wiki contribution?
On Wed, Jan 4, 2017 at 9:57 AM, Roy Golan wrote: > I'm getting the feeling I'm not alone in this, authoring and publishing a > wiki page isn't as used to be for long time. > > I want to suggest a bit lighter workflow: > > 1. Everyone can merge their page - (it's a wiki) > Same as with (public and open) code, no one has the motivation to > publish a badly written > wiki page under their name. True, it can have an impact, but not as with > broken code > > +1. Moreover, I think we shouldn't block any merging. Instead, wiki maintainers could act afterwards and revert when needed (Wikipedia style). Another issue is that (sadly) unlike mediawiki, we need to wait for wiki publish after a change. So I'd suggest to build and publish the wiki at least once a day. Any way, I think we should make the workflow much more intuitive and pleasant like the previous wiki - i.e. much less restrictive than manipulating a code base. > 2. Use Page-Status marker > The author first merges the draft. Its now out there and should be > updated as time goes and its > status is DRAFT. Maintainers will come later and after review would > change the status to > PUBLISH. That could be a header in on the page: > --- > page status: DRAFT/PUBLISH > --- > > Simple I think, and should work. > > > > > ___ > 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] Can't find relative path for class "org.ovirt.engine.api.resource.VmDisksResource", will return null
Thanks Juan. Opening. On Wed, Jan 04 2017, Juan Hernández wrote: > On 01/04/2017 10:09 AM, Pavel Zhukov wrote: >> >> Hello, >> >> In ovirt-system-tests results I can see engine log is flooded with messages >> like: >> 147: 40147:2017-01-03 21:45:13,837-05 ERROR >> [org.ovirt.engine.api.restapi.util.LinkHelper] (default task-22) [] Can't >> find relative path for class >> "org.ovirt.engine.api.resource.VmDisksResource", will return null >> >> There're 123 messages like (logging time is 15 mins). >> >> Is it expected to have too many ERROR messages? >> >> [1] >> http://jenkins.ovirt.org/job/ovirt_4.1_system-tests/28/artifact/exported-artifacts/test_logs/basic-suite-4.1/post-004_basic_sanity.py/lago-basic-suite-4-1-engine/_var_log_ovirt-engine/engine.log >> > > No, it isn't expected. It isn't very serious either. It means that the > system isn't able to calculate a link for something. That needs to be > fixed anyhow. Can you open a BZ? -- Pavel Zhukov Software Engineer RHV DevOps IRC: landgraf ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] [ovirt-users] Lowering the bar for wiki contribution?
On Wed, Jan 4, 2017 at 11:38 AM, Daniel Erez wrote: > > > On Wed, Jan 4, 2017 at 9:57 AM, Roy Golan wrote: > >> I'm getting the feeling I'm not alone in this, authoring and publishing a >> wiki page isn't as used to be for long time. >> >> I want to suggest a bit lighter workflow: >> >> 1. Everyone can merge their page - (it's a wiki) >> Same as with (public and open) code, no one has the motivation to >> publish a badly written >> wiki page under their name. True, it can have an impact, but not as >> with broken code >> >> > +1. > Moreover, I think we shouldn't block any merging. Instead, wiki > maintainers could act afterwards and revert when needed (Wikipedia style). > Another issue is that (sadly) unlike mediawiki, we need to wait for wiki > publish after a change. So I'd suggest to build and publish the wiki at > least once a day. Any way, I think we should make the workflow much more > intuitive and pleasant like the previous wiki - i.e. much less restrictive > than manipulating a code base. > > >> 2. Use Page-Status marker >> The author first merges the draft. Its now out there and should be >> updated as time goes and its >> status is DRAFT. Maintainers will come later and after review would >> change the status to >> PUBLISH. That could be a header in on the page: >> --- >> page status: DRAFT/PUBLISH >> --- >> >> Simple I think, and should work. >> >> +1 The effort of maintaining the wiki today compare to how it used to be before is much more cumbersome and problematic. I think we can learn a lot from wikipedia workflow, It is a much more inviting process where anyone can change the content easily. I'm not saying we should let any anonymous user change the wiki but even if we make it easier in house we can achieve much more informative reliable and updated wiki. > >> >> >> ___ >> Devel mailing list >> Devel@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/devel >> > > > ___ > 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] [ovirt-users] Lowering the bar for wiki contribution?
On 4 January 2017 at 12:17, Maor Lipchuk wrote: > > > On Wed, Jan 4, 2017 at 11:38 AM, Daniel Erez wrote: > >> >> >> On Wed, Jan 4, 2017 at 9:57 AM, Roy Golan wrote: >> >>> I'm getting the feeling I'm not alone in this, authoring and publishing >>> a wiki page isn't as used to be for long time. >>> >>> I want to suggest a bit lighter workflow: >>> >>> 1. Everyone can merge their page - (it's a wiki) >>> Same as with (public and open) code, no one has the motivation to >>> publish a badly written >>> wiki page under their name. True, it can have an impact, but not as >>> with broken code >>> >>> >> +1. >> Moreover, I think we shouldn't block any merging. Instead, wiki >> maintainers could act afterwards and revert when needed (Wikipedia style). >> Another issue is that (sadly) unlike mediawiki, we need to wait for wiki >> publish after a change. So I'd suggest to build and publish the wiki at >> least once a day. Any way, I think we should make the workflow much more >> intuitive and pleasant like the previous wiki - i.e. much less restrictive >> than manipulating a code base. >> > >> >>> 2. Use Page-Status marker >>> The author first merges the draft. Its now out there and should be >>> updated as time goes and its >>> status is DRAFT. Maintainers will come later and after review would >>> change the status to >>> PUBLISH. That could be a header in on the page: >>> --- >>> page status: DRAFT/PUBLISH >>> --- >>> >>> Simple I think, and should work. >>> >>> > +1 > The effort of maintaining the wiki today compare to how it used to be > before is much more cumbersome and problematic. > I think we can learn a lot from wikipedia workflow, > It is a much more inviting process where anyone can change the content > easily. > I'm not saying we should let any anonymous user change the wiki but even > if we make it easier in house we can achieve much more informative reliable > and updated wiki. > > I really think Github Pages is a perfect fit and an alternative to my first suggestion. see https://github.com/oVirt/ovirt-site/wiki/Why-aren't-we-using-this%3F > >>> >>> >>> ___ >>> Devel mailing list >>> Devel@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/devel >>> >> >> >> ___ >> 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] [ovirt-users] Lowering the bar for wiki contribution?
On Wed, Jan 4, 2017 at 12:41 PM, Roy Golan wrote: > > > On 4 January 2017 at 12:17, Maor Lipchuk wrote: >> >> >> >> On Wed, Jan 4, 2017 at 11:38 AM, Daniel Erez wrote: >>> >>> >>> >>> On Wed, Jan 4, 2017 at 9:57 AM, Roy Golan wrote: I'm getting the feeling I'm not alone in this, authoring and publishing a wiki page isn't as used to be for long time. I want to suggest a bit lighter workflow: 1. Everyone can merge their page - (it's a wiki) Same as with (public and open) code, no one has the motivation to publish a badly written wiki page under their name. True, it can have an impact, but not as with broken code >>> >>> +1. >>> Moreover, I think we shouldn't block any merging. Instead, wiki >>> maintainers could act afterwards and revert when needed (Wikipedia style). >>> Another issue is that (sadly) unlike mediawiki, we need to wait for wiki >>> publish after a change. So I'd suggest to build and publish the wiki at >>> least once a day. Any way, I think we should make the workflow much more >>> intuitive and pleasant like the previous wiki - i.e. much less restrictive >>> than manipulating a code base. >>> >>> 2. Use Page-Status marker The author first merges the draft. Its now out there and should be updated as time goes and its status is DRAFT. Maintainers will come later and after review would change the status to PUBLISH. That could be a header in on the page: --- page status: DRAFT/PUBLISH --- Simple I think, and should work. >> >> +1 >> The effort of maintaining the wiki today compare to how it used to be >> before is much more cumbersome and problematic. >> I think we can learn a lot from wikipedia workflow, >> It is a much more inviting process where anyone can change the content >> easily. >> I'm not saying we should let any anonymous user change the wiki but even >> if we make it easier in house we can achieve much more informative reliable >> and updated wiki. >> > > > > I really think Github Pages is a perfect fit and an alternative to my first > suggestion. see > https://github.com/oVirt/ovirt-site/wiki/Why-aren't-we-using-this%3F This is not github pages, this is the builtin wiki, but we can use this for developing content. ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel >>> >>> >>> >>> ___ >>> Users mailing list >>> us...@ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >>> >> > > > ___ > 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] how does findbugs work?
On Wed, Jan 4, 2017 at 10:37 AM, Michal Skrivanek < michal.skriva...@redhat.com> wrote: > > On 21 Dec 2016, at 12:23, Eyal Edri wrote: > > You can see from the output the maven plugin is running [1], > Have you checked the filters that are ignoring 'false positives'? maybe > those needs to be updated? > > The are in the 'exclude-filters.xml' files under each project and > maintained by the ovirt-engine maintainers. > > > > AFAICT no, it’s not excluded, but checking whole ovirt-engine on coverity > site I can’t seem to find the whole file. I dunno, I’m not much of an > expert, but I do not see any exclude anywhere and there are bunch of other > files in the same dir… > anyone any idea? > I can't tell you what Coverity covers from findbugs filters, it might not be the same so don't use it as reference. Adding some people which I know had experience with the findbugs in the past and might shed some light on how the filters works. > > > > > [1] 08:13:21 [FINDBUGS] Collecting findbugs analysis files... > 08:13:23 [FINDBUGS] Finding all files that match the pattern > **/findbugsXml.xml > 08:13:23 [FINDBUGS] Parsing 34 files in /home/jenkins/workspace/ovirt- > engine_master_find-bugs_created > 08:13:23 [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt- > engine_master_find-bugs_created/ovirt-engine/backend/ > manager/extensions-tool/target/findbugsXml.xml with 0 unique warnings and > 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt- > engine_master_find-bugs_created/ovirt-engine/backend/ > manager/modules/aaa/target/findbugsXml.xml with 0 unique warnings and 0 > duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt- > engine_master_find-bugs_created/ovirt-engine/backend/ > manager/modules/auth-plugin/target/findbugsXml.xml with 0 unique warnings > and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt- > engine_master_find-bugs_created/ovirt-engine/backend/ > manager/modules/bll/target/findbugsXml.xml with 0 unique warnings and 0 > duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt- > engine_master_find-bugs_created/ovirt-engine/backend/ > manager/modules/branding/target/findbugsXml.xml with 0 unique warnings > and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt- > engine_master_find-bugs_created/ovirt-engine/backend/ > manager/modules/builtin-extensions/target/findbugsXml.xml with 0 unique > warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt- > engine_master_find-bugs_created/ovirt-engine/backend/ > manager/modules/common/target/findbugsXml.xml with 0 unique warnings and > 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt- > engine_master_find-bugs_created/ovirt-engine/backend/ > manager/modules/compat/target/findbugsXml.xml with 0 unique warnings and > 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt- > engine_master_find-bugs_created/ovirt-engine/backend/ > manager/modules/dal/target/findbugsXml.xml with 0 unique warnings and 0 > duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt- > engine_master_find-bugs_created/ovirt-engine/backend/ > manager/modules/docs/target/findbugsXml.xml with 0 unique warnings and 0 > duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt- > engine_master_find-bugs_created/ovirt-engine/backend/ > manager/modules/enginesso/target/findbugsXml.xml with 0 unique warnings > and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt- > engine_master_find-bugs_created/ovirt-engine/backend/ > manager/modules/extensions-api-root/extensions-api/target/findbugsXml.xml > with 0 unique warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt- > engine_master_find-bugs_created/ovirt-engine/backend/ > manager/modules/extensions-manager/target/findbugsXml.xml with 0 unique > warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt- > engine_master_find-bugs_created/ovirt-engine/backend/ > manager/modules/logger/target/findbugsXml.xml with 0 unique warnings and > 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt- > engine_master_find-bugs_created/ovirt-engine/backend/ > manager/modules/restapi/interface/common/jaxrs/target/findbugsXml.xml > with 0 unique warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt- > engine_master_find-bugs_created/ovirt-engine/backend/ > manager/modules/restapi/interface/definition/target/findbugsXml.xml with > 0 unique warnings and 0 duplicates. > 08:13:23 [FINDBUGS] Successfully parsed file /home/jenkins/workspace/ovirt- > engine_maste
Re: [ovirt-devel] Manageiq ova upload is failing
You can only upload the OVA disk and attach it to a VM with 4.1.
Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306
8272306
Email: yd...@redhat.com
IRC : ydary
On Wed, Jan 4, 2017 at 10:53 AM, Tomas Jelinek wrote:
>
> On Wed, Jan 4, 2017 at 9:39 AM, Piotr Kliczewski <
> piotr.kliczew...@gmail.com> wrote:
>
>> On Wed, Jan 4, 2017 at 6:51 AM, Michal Skrivanek
>> wrote:
>> >> On 03 Jan 2017, at 23:59, Piotr Kliczewski
>> wrote:
>> >>
>> >> All,
>> >>
>> >> I want to upload manageiq ova from [1] when I attempted to do it I see:
>> >>
>> >> on the engine side:
>> >>
>> >> 2017-01-03 23:43:59,318+01 ERROR
>> >> [org.ovirt.engine.core.bll.GetVmFromOvaQuery] (default task-1)
>> >
>> > You're falling for the confusing trap we created:)
>> > OVA in oVirt is for vmware ova conversion, not for importing ovirt
>> > native-like images. For that you need to use the old and cumbersome
>> > flow of export/import via export domain
>>
>> I looked for it initially and noticed that ovirt-image-uploader is not
>> there in 4.1.
>>
>> Is there any other way to do it?
>>
>
> you should be able to go to webadmin to disks tab and upload it from there.
>
>
>>
>> >
>> >> [33a1d8b5-8cec-4b00-9a35-ee9f1d9635b2] Exception:
>> >> org.ovirt.engine.core.common.errors.EngineException: EngineException:
>> >> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException:
>> >> VDSGenericException: VDSErrorException: Failed to GetOvaInfoVDS, error
>> >> = Error parsing ovf information: no memory size, code = -32603 (Failed
>> >> with error unexpected and code 16)
>> >>at org.ovirt.engine.core.bll.VdsHandler.handleVdsResult(VdsHand
>> ler.java:118)
>> >> [bll.jar:]
>> >>at org.ovirt.engine.core.bll.VDSBrokerFrontendImpl.runVdsComman
>> d(VDSBrokerFrontendImpl.java:33)
>> >> [bll.jar:]
>> >>at org.ovirt.engine.core.bll.QueriesCommandBase.runVdsCommand(Q
>> ueriesCommandBase.java:242)
>> >> [bll.jar:]
>> >>at org.ovirt.engine.core.bll.GetVmFromOvaQuery.getVmInfoFromOva
>> File(GetVmFromOvaQuery.java:24)
>> >> [bll.jar:]
>> >>at org.ovirt.engine.core.bll.GetVmFromOvaQuery.executeQueryComm
>> and(GetVmFromOvaQuery.java:20)
>> >> [bll.jar:]
>> >>at org.ovirt.engine.core.bll.QueriesCommandBase.executeCommand(
>> QueriesCommandBase.java:110)
>> >> [bll.jar:]
>> >>at org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandB
>> ase.java:33)
>> >> [dal.jar:]
>> >>at org.ovirt.engine.core.bll.executor.DefaultBackendQueryExecut
>> or.execute(DefaultBackendQueryExecutor.java:14)
>> >> [bll.jar:]
>> >>at org.ovirt.engine.core.bll.Backend.runQueryImpl(Backend.java:
>> 579)
>> >> [bll.jar:]
>> >>at org.ovirt.engine.core.bll.Backend.runQuery(Backend.java:547)
>> >> [bll.jar:]
>> >>
>> >> on the vdsm side:
>> >>
>> >> 2017-01-03 23:43:58,437 ERROR (jsonrpc/0) [jsonrpc.JsonRpcServer]
>> >> Internal server error (__init__:552)
>> >> Traceback (most recent call last):
>> >> File "/usr/lib/python2.7/site-packages/yajsonrpc/__init__.py", line
>> >> 547, in _handle_request
>> >>res = method(**params)
>> >> File "/usr/lib/python2.7/site-packages/vdsm/rpc/Bridge.py", line
>> >> 198, in _dynamicMethod
>> >>result = fn(*methodArgs)
>> >> File "/usr/share/vdsm/API.py", line 1493, in getExternalVmFromOva
>> >>return v2v.get_ova_info(ova_path)
>> >> File "/usr/lib/python2.7/site-packages/vdsm/v2v.py", line 226, in
>> get_ova_info
>> >>_add_general_ovf_info(vm, root, ns, ova_path)
>> >> File "/usr/lib/python2.7/site-packages/vdsm/v2v.py", line 1225, in
>> >> _add_general_ovf_info
>> >>raise V2VError('Error parsing ovf information: no memory size')
>> >> V2VError: Error parsing ovf information: no memory size
>> >>
>> >> Is our code not parsing correctly or manageiq guys publish not correct
>> file?
>> >>
>> >> I am using:
>> >> ovirt-engine
>> >> Version : 4.1.0
>> >> Release : 0.3.beta2.20161221085908.el7.centos
>> >> vdsm
>> >> Version : 4.18.999
>> >> Release : 1218.gitd36143e.el7.centos
>> >>
>> >> Thanks,
>> >> Piotr
>> >>
>> >>
>> >> [1] http://manageiq.org/download/
>> >> ___
>> >> 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
[ovirt-devel] The feature everyone was asking for is finally here...
FYI, After many requests from multiple developers and testers, the oVirt CI added a new simple job that lets you run the full fledged end-to-end oVirt system tests with a click of a button. You can read all the details and how-to in the new oVirt blog [1]. We wanted to allow running oVirt system tests on EVERY open patch from ANY oVirt project, without relaying on complex building code inside the job. Luckily we just added the 'build-on-demand' so together with it you can build any rpms you'd like and use them to run the manual job. So the 2 steps you'll need to do are: 1. Write 'ci please build' inside a comment on an open oVirt patch ( make sure the feature is enabled for that project first, its already available for ovirt-engine,vdsm,dashboard and vdsm-jsonrpc-java) 2. Run the manual OST job for the version you'd like to test with the URLs you got from #1 You'll get and email once the job is done and you can browse the results and check for logs from engine and the hosts. Please feel free to ask questions on in...@ovirt.org as usual. [1] https://www.ovirt.org/blog/2017/01/ovirt-system-tests-to-the-rescue/ -- Eyal Edri Associate Manager RHV DevOps EMEA ENG Virtualization R&D Red Hat Israel phone: +972-9-7692018 <+972%209-769-2018> irc: eedri (on #tlv #rhev-dev #rhev-integ) ___ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
Re: [ovirt-devel] Publicly available REST documentation
Hello again, built master documentation is available on [1], latest 4.1 and 4.0 tags on [2] and [3] (these two were created manually, automated build will be triggered by a next tag). [1] http://ovirt.github.io/ovirt-engine-api-model/master/ [2] http://ovirt.github.io/ovirt-engine-api-model/4.1/ [3] http://ovirt.github.io/ovirt-engine-api-model/4.0/ 2017-01-03 15:22 GMT+01:00 Juan Hernández : > On 01/03/2017 03:20 PM, Petr Horacek wrote: >> Hi, I've been hacking public API docs yesterday, and I think it will >> work in GitHub-Travis combination. Now I am waiting if Gerrit-GitHub >> mirroring will remove branch created directly on GitHub, if not, then >> my approach would be following: >> >> Both 4.0 and 4.1 branches will have .travis.yml in them that will run >> the build and then push generated pages to gh-pages branch (authorized >> via GitHub deploy key). For now I have a working demo on my fork >> (https://github.com/phoracek/ovirt-engine-api-model/blob/master/.travis.yml), >> this one does not use deploy keys, but token instead. >> >> Hope I'm not breaking your work. >> > > Excellent! Please go ahead. > >> 2017-01-03 14:49 GMT+01:00 Vojtech Szocs : >>> >>> >>> - Original Message - From: "Rafael Martins" To: "Vojtech Szocs" Cc: "Juan Hernández" , "Michal Skrivanek" , "devel" Sent: Tuesday, January 3, 2017 2:28:30 PM Subject: Re: [ovirt-devel] Publicly available REST documentation - Original Message - > From: "Vojtech Szocs" > To: "Rafael Martins" > Cc: "Juan Hernández" , "Michal Skrivanek" > , "devel" > Sent: Tuesday, January 3, 2017 2:24:22 PM > Subject: Re: [ovirt-devel] Publicly available REST documentation > > > > - Original Message - >> From: "Rafael Martins" >> To: "Vojtech Szocs" >> Cc: "Juan Hernández" , "Michal Skrivanek" >> , "devel" >> Sent: Tuesday, January 3, 2017 2:17:49 PM >> Subject: Re: [ovirt-devel] Publicly available REST documentation >> >> - Original Message - >>> From: "Vojtech Szocs" >>> To: "Juan Hernández" >>> Cc: "Michal Skrivanek" , "devel" >>> Sent: Tuesday, January 3, 2017 2:11:06 PM >>> Subject: Re: [ovirt-devel] Publicly available REST documentation >>> >>> >>> >>> - Original Message - From: "Juan Hernández" To: "Jakub Niedermertl" Cc: "devel" , "Michal Skrivanek" Sent: Monday, January 2, 2017 10:48:53 PM Subject: Re: [ovirt-devel] Publicly available REST documentation On 01/02/2017 10:13 PM, Jakub Niedermertl wrote: > Hi Juan, > > from time to time I'd like the REST doc to be available on some > public > site. It would allow us to > * check the documentation without searching for running engine > * be able to easily link documentations in irc/mails > * link rest doc from ovirt.org site doc > Recently I've also heard similar request from other guys (cc-ed). > Would it be possible to for example publish generated doc of merged > patches of ovirt-engine-api-model project? Maybe github project > pages > [1] of project mirror [2] could be used for hosting. > > Regards > Jakub > > [1] > https://help.github.com/articles/user-organization-and-project-pages/#project-pages > [2] https://github.com/oVirt/ovirt-engine-api-model > Yes, we can publish the documentation using gh-pages. I just created and populated the 'gh-branch' with some initial content, and requested the activation of the feature in Github. I will inform you when it is ready. >>> >>> Alternatively, you could use readthedocs.org which supports webhooks: >>> a push to GitHub (mirror) project [syncing Gerrit with GitHub] would >>> regenerate the project's documentation available at >>> >>> .readthedocs.io >>> >>> which would allow to separate the GitHub project from its docs, given >>> the source comes from Gerrit. >> >> ReadTheDocs relies on sphinx and/or mkdocs to rebuild the docs when >> called >> by >> the webhook, and we use something else. We just need some hosting for >> static >> files, then github-pages is a better solution. > > Hm, and what about pushing to https://github.com/oVirt/ovirt-site > directly, > instead of pushing to GitHub (mirror) project pages? there's no real need to mess with the ovirt-site repo. we can have a separated repo, that can be freely updated by a jenkins job, for example, and include it on ovirt-site using a sub-repository, like it is done for data/events today. The good thing of this approach is that we can have "unstable" docs in the separated repo, updated by
Re: [ovirt-devel] Publicly available REST documentation
On 01/04/2017 05:08 PM, Petr Horacek wrote: > Hello again, built master documentation is available on [1], latest > 4.1 and 4.0 tags on [2] and [3] (these two were created manually, > automated build will be triggered by a next tag). > > [1] http://ovirt.github.io/ovirt-engine-api-model/master/ > [2] http://ovirt.github.io/ovirt-engine-api-model/4.1/ > [3] http://ovirt.github.io/ovirt-engine-api-model/4.0/ > Thank you very much Petr, awesome job! > 2017-01-03 15:22 GMT+01:00 Juan Hernández : >> On 01/03/2017 03:20 PM, Petr Horacek wrote: >>> Hi, I've been hacking public API docs yesterday, and I think it will >>> work in GitHub-Travis combination. Now I am waiting if Gerrit-GitHub >>> mirroring will remove branch created directly on GitHub, if not, then >>> my approach would be following: >>> >>> Both 4.0 and 4.1 branches will have .travis.yml in them that will run >>> the build and then push generated pages to gh-pages branch (authorized >>> via GitHub deploy key). For now I have a working demo on my fork >>> (https://github.com/phoracek/ovirt-engine-api-model/blob/master/.travis.yml), >>> this one does not use deploy keys, but token instead. >>> >>> Hope I'm not breaking your work. >>> >> >> Excellent! Please go ahead. >> >>> 2017-01-03 14:49 GMT+01:00 Vojtech Szocs : - Original Message - > From: "Rafael Martins" > To: "Vojtech Szocs" > Cc: "Juan Hernández" , "Michal Skrivanek" > , "devel" > Sent: Tuesday, January 3, 2017 2:28:30 PM > Subject: Re: [ovirt-devel] Publicly available REST documentation > > > > - Original Message - >> From: "Vojtech Szocs" >> To: "Rafael Martins" >> Cc: "Juan Hernández" , "Michal Skrivanek" >> , "devel" >> Sent: Tuesday, January 3, 2017 2:24:22 PM >> Subject: Re: [ovirt-devel] Publicly available REST documentation >> >> >> >> - Original Message - >>> From: "Rafael Martins" >>> To: "Vojtech Szocs" >>> Cc: "Juan Hernández" , "Michal Skrivanek" >>> , "devel" >>> Sent: Tuesday, January 3, 2017 2:17:49 PM >>> Subject: Re: [ovirt-devel] Publicly available REST documentation >>> >>> - Original Message - From: "Vojtech Szocs" To: "Juan Hernández" Cc: "Michal Skrivanek" , "devel" Sent: Tuesday, January 3, 2017 2:11:06 PM Subject: Re: [ovirt-devel] Publicly available REST documentation - Original Message - > From: "Juan Hernández" > To: "Jakub Niedermertl" > Cc: "devel" , "Michal Skrivanek" > > Sent: Monday, January 2, 2017 10:48:53 PM > Subject: Re: [ovirt-devel] Publicly available REST documentation > > On 01/02/2017 10:13 PM, Jakub Niedermertl wrote: >> Hi Juan, >> >> from time to time I'd like the REST doc to be available on some >> public >> site. It would allow us to >> * check the documentation without searching for running engine >> * be able to easily link documentations in irc/mails >> * link rest doc from ovirt.org site doc >> Recently I've also heard similar request from other guys (cc-ed). >> Would it be possible to for example publish generated doc of merged >> patches of ovirt-engine-api-model project? Maybe github project >> pages >> [1] of project mirror [2] could be used for hosting. >> >> Regards >> Jakub >> >> [1] >> https://help.github.com/articles/user-organization-and-project-pages/#project-pages >> [2] https://github.com/oVirt/ovirt-engine-api-model >> > > Yes, we can publish the documentation using gh-pages. I just created > and > populated the 'gh-branch' with some initial content, and requested > the > activation of the feature in Github. I will inform you when it is > ready. Alternatively, you could use readthedocs.org which supports webhooks: a push to GitHub (mirror) project [syncing Gerrit with GitHub] would regenerate the project's documentation available at .readthedocs.io which would allow to separate the GitHub project from its docs, given the source comes from Gerrit. >>> >>> ReadTheDocs relies on sphinx and/or mkdocs to rebuild the docs when >>> called >>> by >>> the webhook, and we use something else. We just need some hosting for >>> static >>> files, then github-pages is a better solution. >> >> Hm, and what about pushing to https://github.com/oVirt/ovirt-site >> directly, >> instead of pushing to GitHub (mirror) project pages? > > there's no real need to mess with the ovirt-site repo. we can have a > separated repo, that can be freely updated by a jenkins job, fo
Re: [ovirt-devel] Heads-up: moving Libvirt xml creation to the engine
I agree with Piotr&Edward:
- having engine uses libvirt xml would impose coupling between engine
and libvirt (a cross-layers dependency), which currently does not exist.
- moreover, engine would be coupled to all versions of libvirt api that
it manages - currently each VDSM version knows how to interact with libvirt
it uses (de-centralized approach)
- currently we do not have a mechanism that ensures libvirt version
based on cluster level (IMHO). Ensuring that would imply requesting a very
specific version of libvirt by VDSM.
- cluster version means a minimum level of compatibility, but what if
cluster of version (x.y) contains a host of a newer version (x+1.y+2). What
would be able to tell about libvirt it uses?
Regards,
Yevgeny
On Fri, Dec 9, 2016 at 12:58 PM, Martin Sivak wrote:
> > I like transport abstractions (DTOs) and here we make the libvirt xml
> > (its structure) part of our communication interface.
>
> I agree, but only partially. We can have a DTO for this, but we need a
> library to convert from/to it. Hosted engine has to duplicate the
> current Java code as it has to convert the OVF to the format vdsm is
> expecting. And that is very error prone. Getting the domain XML from
> the engine and using it directly would solve a lot of bugs we have. Or
> alternatively the ability to send the OVF to vdsm without
> preprocessing.
>
> On the other hand, the logic we have in vdsm is not that complicated
> and we could move it to the engine, because we have (almost) all the
> information there as well. The (complicated) logic needed to use vdsm
> verbs is part of engine anyway and I am constantly under pressure to
> not use (for example from virt) the verbs directly. It does not make
> sense to maintain the current separation in the situation where there
> is tight coupling anyway.
>
> This whole discussion will boil to a simple point eventually: What is
> the role of vdsm and how dumb is it supposed to be in the future (it
> is pretty dumb currently.. just a conversion proxy + monitoring, at
> least in areas I am concerned about). I would like slightly smarter
> vdsm with engine acting only as the high level boss, without the
> micromanaging of storage verbs for example.
>
> TLDR; I would like to get data from storage (currently OVF) and pass
> them to vdsm without any preprocessing. Separation is not a bad idea,
> but we currently have three different formats with no clear rules for
> conversion. I would also like to have slightly more high level API in
> vdsm ("prepareImage" should make sure domain monitor is up, domain is
> mounted and so on.. I do not want to micromanage that).
>
> Martin
>
>
> On Fri, Dec 9, 2016 at 11:39 AM, Piotr Kliczewski
> wrote:
> > I like transport abstractions (DTOs) and here we make the libvirt xml
> > (its structure) part of our communication interface.
> > We were never good at evolving our api. Here is [1] recent example of it.
> >
> > I am not against this change but I would like us to think about
> > potential changes to this xml. With this approach when change
> > happens we would need to change the engine and vdsm code and make sure
> > that supported engine/vdsm matrix still work.
> >
> > Will it be possible to have different libvirt versions (different xml
> > structure) between version clusters? If so, how are we going to
> > handle different xml structure per cluster?
> >
> > Thanks,
> > Piotr
> >
> > [1] https://gerrit.ovirt.org/#/c/67596
> >
> >
> > On Thu, Dec 8, 2016 at 11:30 PM, Edward Haas wrote:
> >>
> >>
> >> On Wed, Nov 23, 2016 at 2:59 PM, Arik Hadas wrote:
> >>>
> >>> Hi All,
> >>>
> >>> We are working on something that is expected to have a big impact,
> hence
> >>> this heads-up.
> >>> First, we want you to be aware of this change and provide your
> feedback to
> >>> make it as good as possible.
> >>> Second, until the proposed mechanism is fully merged there will be a
> chase
> >>> to cover all features unless new features are also implemented with
> the new
> >>> mechanism. So please, if you are working on something that adds/changes
> >>> something in the Libvirt's domain xml, do it with this new mechanism
> as well
> >>> (first version would be merged soon).
> >>>
> >>> * Goal
> >>> Creating Libvirt XML in the engine rather than in VDSM.
> >>> ** Today's flow
> >>> Engine: VM business entity -> VM properties map
> >>> VDSM: VM properties map -> Libvirt XML
> >>> ** Desired flow
> >>> Engine: VM business entity -> Libvirt XML
> >>>
> >>> * Potential Benefits
> >>> 1. Reduce the number of conversions from 2 to 1, reducing chances for
> >>> mistakes in the process.
> >>> 2. Reduce the amount of code in VDSM.
> >>> 3. Make VM related changes easier - today many of these changes need
> to be
> >>> reviewed in 2 projects, this will eliminate the one that tends to take
> >>> longer.
> >>> 4. Prevent shortcuts in the form of VDSM-only changes that should be
> >>> better reflected in the engine.
> >>> 5. Not
Re: [ovirt-devel] Publicly available REST documentation
> On 04 Jan 2017, at 17:08, Petr Horacek wrote: > > Hello again, built master documentation is available on [1], latest > 4.1 and 4.0 tags on [2] and [3] (these two were created manually, > automated build will be triggered by a next tag). Thanks, Petr! I missed that a lot! > > [1] http://ovirt.github.io/ovirt-engine-api-model/master/ > [2] http://ovirt.github.io/ovirt-engine-api-model/4.1/ > [3] http://ovirt.github.io/ovirt-engine-api-model/4.0/ > > 2017-01-03 15:22 GMT+01:00 Juan Hernández : >>> On 01/03/2017 03:20 PM, Petr Horacek wrote: >>> Hi, I've been hacking public API docs yesterday, and I think it will >>> work in GitHub-Travis combination. Now I am waiting if Gerrit-GitHub >>> mirroring will remove branch created directly on GitHub, if not, then >>> my approach would be following: >>> >>> Both 4.0 and 4.1 branches will have .travis.yml in them that will run >>> the build and then push generated pages to gh-pages branch (authorized >>> via GitHub deploy key). For now I have a working demo on my fork >>> (https://github.com/phoracek/ovirt-engine-api-model/blob/master/.travis.yml), >>> this one does not use deploy keys, but token instead. >>> >>> Hope I'm not breaking your work. >> >> Excellent! Please go ahead. >> >>> 2017-01-03 14:49 GMT+01:00 Vojtech Szocs : - Original Message - > From: "Rafael Martins" > To: "Vojtech Szocs" > Cc: "Juan Hernández" , "Michal Skrivanek" > , "devel" > Sent: Tuesday, January 3, 2017 2:28:30 PM > Subject: Re: [ovirt-devel] Publicly available REST documentation > > > > - Original Message - >> From: "Vojtech Szocs" >> To: "Rafael Martins" >> Cc: "Juan Hernández" , "Michal Skrivanek" >> , "devel" >> Sent: Tuesday, January 3, 2017 2:24:22 PM >> Subject: Re: [ovirt-devel] Publicly available REST documentation >> >> >> >> - Original Message - >>> From: "Rafael Martins" >>> To: "Vojtech Szocs" >>> Cc: "Juan Hernández" , "Michal Skrivanek" >>> , "devel" >>> Sent: Tuesday, January 3, 2017 2:17:49 PM >>> Subject: Re: [ovirt-devel] Publicly available REST documentation >>> >>> - Original Message - From: "Vojtech Szocs" To: "Juan Hernández" Cc: "Michal Skrivanek" , "devel" Sent: Tuesday, January 3, 2017 2:11:06 PM Subject: Re: [ovirt-devel] Publicly available REST documentation - Original Message - > From: "Juan Hernández" > To: "Jakub Niedermertl" > Cc: "devel" , "Michal Skrivanek" > > Sent: Monday, January 2, 2017 10:48:53 PM > Subject: Re: [ovirt-devel] Publicly available REST documentation > >> On 01/02/2017 10:13 PM, Jakub Niedermertl wrote: >> Hi Juan, >> >> from time to time I'd like the REST doc to be available on some >> public >> site. It would allow us to >> * check the documentation without searching for running engine >> * be able to easily link documentations in irc/mails >> * link rest doc from ovirt.org site doc >> Recently I've also heard similar request from other guys (cc-ed). >> Would it be possible to for example publish generated doc of merged >> patches of ovirt-engine-api-model project? Maybe github project >> pages >> [1] of project mirror [2] could be used for hosting. >> >> Regards >> Jakub >> >> [1] >> https://help.github.com/articles/user-organization-and-project-pages/#project-pages >> [2] https://github.com/oVirt/ovirt-engine-api-model > > Yes, we can publish the documentation using gh-pages. I just created > and > populated the 'gh-branch' with some initial content, and requested > the > activation of the feature in Github. I will inform you when it is > ready. Alternatively, you could use readthedocs.org which supports webhooks: a push to GitHub (mirror) project [syncing Gerrit with GitHub] would regenerate the project's documentation available at .readthedocs.io which would allow to separate the GitHub project from its docs, given the source comes from Gerrit. >>> >>> ReadTheDocs relies on sphinx and/or mkdocs to rebuild the docs when >>> called >>> by >>> the webhook, and we use something else. We just need some hosting for >>> static >>> files, then github-pages is a better solution. >> >> Hm, and what about pushing to https://github.com/oVirt/ovirt-site >> directly, >> instead of pushing to GitHub (mirror) project pages? > > there's no real need to mess with the ovirt-site repo. we can have a > separated repo, that can be freely updated by a jenkins job, for example, >>
Re: [ovirt-devel] Heads-up: moving Libvirt xml creation to the engine
Thanks for feedback, this is WIP, early stage, so your comments and your
time to think about it is much appreciated.
few comments/arguments/thoughts below
On 04 Jan 2017, at 20:01, Yevgeny Zaspitsky wrote:
I agree with Piotr&Edward:
- having engine uses libvirt xml would impose coupling between engine
and libvirt (a cross-layers dependency), which currently does not exist.
Yes, it creates a coupling. We do have such coupling already though, just
more of it. I would refer you to the religious wars on "is vdsm api a
general purpose api"
Obviously there is another close coupling in vdsm<->libvirt as well
- moreover, engine would be coupled to all versions of libvirt api that
it manages - currently each VDSM version knows how to interact with libvirt
it uses (de-centralized approach)
Yes, same as engine is coupled to all versions of vdsms.
- currently we do not have a mechanism that ensures libvirt version
based on cluster level (IMHO).
That is correct. OTOH we do have that thing in engine. This is effort is
removing one layer of translation, but it doesn't magically solve/remove
such mechanism
- Ensuring that would imply requesting a very specific version of
libvirt by VDSM.
No, similarly as all vdsms are backward compatible, libvirt has the same
(to certain degree, but actually in general they do a better job than vdsm
due to wider exposure of the project)
- cluster version means a minimum level of compatibility, but what if
cluster of version (x.y) contains a host of a newer version (x+1.y+2). What
would be able to tell about libvirt it uses?
Same as today with engine and vdsm
Regards,
Yevgeny
On Fri, Dec 9, 2016 at 12:58 PM, Martin Sivak wrote:
> > I like transport abstractions (DTOs) and here we make the libvirt xml
> > (its structure) part of our communication interface.
>
It's not only communication, it is a design change, to model entities and
features close to how they are modeled in libvirt, participate on that
_there_, contribute
It does look quite when you look deep at vdsm minus storage and network
code.
> I agree, but only partially. We can have a DTO for this, but we need a
> library to convert from/to it. Hosted engine has to duplicate the
> current Java code as it has to convert the OVF to the format vdsm is
>
Yeah, this could have been avoided, but it was not, so you are right.
expecting. And that is very error prone. Getting the domain XML from
> the engine and using it directly would solve a lot of bugs we have. Or
> alternatively the ability to send the OVF to vdsm without
> preprocessing.
>
> On the other hand, the logic we have in vdsm is not that complicated
> and we could move it to the engine, because we have (almost) all the
> information there as well. The (complicated) logic needed to use vdsm
> verbs is part of engine anyway and I am constantly under pressure to
> not use (for example from virt) the verbs directly. It does not make
> sense to maintain the current separation in the situation where there
> is tight coupling anyway.
>
Yep, I do see the pain of SLA/HE teams around that.
> This whole discussion will boil to a simple point eventually: What is
> the role of vdsm and how dumb is it supposed to be in the future (it
> is pretty dumb currently.. just a conversion proxy + monitoring, at
>
Yep, especially in "virt" it's a dumb 1:1 proxy with its quirks and tedious
boilerplate not helping anyone. All that on top of dealing with libvirt
quirks, boilerplate, etc.
least in areas I am concerned about). I would like slightly smarter
> vdsm with engine acting only as the high level boss, without the
> micromanaging of storage verbs for example.
>
> TLDR; I would like to get data from storage (currently OVF) and pass
> them to vdsm without any preprocessing. Separation is not a bad idea,
> but we currently have three different formats with no clear rules for
> conversion. I would also like to have slightly more high level API in
> vdsm ("prepareImage" should make sure domain monitor is up, domain is
> mounted and so on.. I do not want to micromanage that).
>
It all does make a whole lot more sense when you do not think only within
our current central, engine, dc, cluster, host, vdsm design/constraints
> Martin
>
>
> On Fri, Dec 9, 2016 at 11:39 AM, Piotr Kliczewski
> wrote:
> > I like transport abstractions (DTOs) and here we make the libvirt xml
> > (its structure) part of our communication interface.
> > We were never good at evolving our api. Here is [1] recent example of it.
> >
> > I am not against this change but I would like us to think about
> > potential changes to this xml. With this approach when change
> > happens we would need to change the engine and vdsm code and make sure
> > that supported engine/vdsm matrix still work.
>
I do want to get to a point when there is no vdsm(in current sense)
involved in elementary changes - those which are modeled and handled by
libvirt (e.g. vm config updates,
Re: [ovirt-devel] Publicly available REST documentation
On Jan 4, 2017 6:08 PM, "Petr Horacek" wrote: Hello again, built master documentation is available on [1], latest 4.1 and 4.0 tags on [2] and [3] (these two were created manually, automated build will be triggered by a next tag). [1] http://ovirt.github.io/ovirt-engine-api-model/master/ [2] http://ovirt.github.io/ovirt-engine-api-model/4.1/ [3] http://ovirt.github.io/ovirt-engine-api-model/4.0/ Well done! A post to the users mailing list + blog post on ovirt.org would make it more visible. Y. 2017-01-03 15:22 GMT+01:00 Juan Hernández : > On 01/03/2017 03:20 PM, Petr Horacek wrote: >> Hi, I've been hacking public API docs yesterday, and I think it will >> work in GitHub-Travis combination. Now I am waiting if Gerrit-GitHub >> mirroring will remove branch created directly on GitHub, if not, then >> my approach would be following: >> >> Both 4.0 and 4.1 branches will have .travis.yml in them that will run >> the build and then push generated pages to gh-pages branch (authorized >> via GitHub deploy key). For now I have a working demo on my fork >> (https://github.com/phoracek/ovirt-engine-api-model/blob/ master/.travis.yml), >> this one does not use deploy keys, but token instead. >> >> Hope I'm not breaking your work. >> > > Excellent! Please go ahead. > >> 2017-01-03 14:49 GMT+01:00 Vojtech Szocs : >>> >>> >>> - Original Message - From: "Rafael Martins" To: "Vojtech Szocs" Cc: "Juan Hernández" , "Michal Skrivanek" < mskri...@redhat.com>, "devel" Sent: Tuesday, January 3, 2017 2:28:30 PM Subject: Re: [ovirt-devel] Publicly available REST documentation - Original Message - > From: "Vojtech Szocs" > To: "Rafael Martins" > Cc: "Juan Hernández" , "Michal Skrivanek" > , "devel" > Sent: Tuesday, January 3, 2017 2:24:22 PM > Subject: Re: [ovirt-devel] Publicly available REST documentation > > > > - Original Message - >> From: "Rafael Martins" >> To: "Vojtech Szocs" >> Cc: "Juan Hernández" , "Michal Skrivanek" >> , "devel" >> Sent: Tuesday, January 3, 2017 2:17:49 PM >> Subject: Re: [ovirt-devel] Publicly available REST documentation >> >> - Original Message - >>> From: "Vojtech Szocs" >>> To: "Juan Hernández" >>> Cc: "Michal Skrivanek" , "devel" < devel@ovirt.org> >>> Sent: Tuesday, January 3, 2017 2:11:06 PM >>> Subject: Re: [ovirt-devel] Publicly available REST documentation >>> >>> >>> >>> - Original Message - From: "Juan Hernández" To: "Jakub Niedermertl" Cc: "devel" , "Michal Skrivanek" Sent: Monday, January 2, 2017 10:48:53 PM Subject: Re: [ovirt-devel] Publicly available REST documentation On 01/02/2017 10:13 PM, Jakub Niedermertl wrote: > Hi Juan, > > from time to time I'd like the REST doc to be available on some > public > site. It would allow us to > * check the documentation without searching for running engine > * be able to easily link documentations in irc/mails > * link rest doc from ovirt.org site doc > Recently I've also heard similar request from other guys (cc-ed). > Would it be possible to for example publish generated doc of merged > patches of ovirt-engine-api-model project? Maybe github project > pages > [1] of project mirror [2] could be used for hosting. > > Regards > Jakub > > [1] > https://help.github.com/articles/user-organization- and-project-pages/#project-pages > [2] https://github.com/oVirt/ovirt-engine-api-model > Yes, we can publish the documentation using gh-pages. I just created and populated the 'gh-branch' with some initial content, and requested the activation of the feature in Github. I will inform you when it is ready. >>> >>> Alternatively, you could use readthedocs.org which supports webhooks: >>> a push to GitHub (mirror) project [syncing Gerrit with GitHub] would >>> regenerate the project's documentation available at >>> >>> .readthedocs.io >>> >>> which would allow to separate the GitHub project from its docs, given >>> the source comes from Gerrit. >> >> ReadTheDocs relies on sphinx and/or mkdocs to rebuild the docs when >> called >> by >> the webhook, and we use something else. We just need some hosting for >> static >> files, then github-pages is a better solution. > > Hm, and what about pushing to https://github.com/oVirt/ovirt-site directly, > instead of pushing to GitHub (mirror) project pages? there's no real need to mess with the ovirt-site repo. we can have a separated repo, that can be freely updated by a jenkins job, for example, and include it on ovirt
