From shaohef at linux.vnet.ibm.com Thu May 24 14:13:41 2012 Content-Type: multipart/mixed; boundary="===============1616301633127616408==" MIME-Version: 1.0 From: ShaoHe Feng To: devel at ovirt.org Subject: [Engine-devel] [ovirt-engine-sdk] Simplify the process of the RSDL code generation Date: Fri, 25 May 2012 02:13:27 +0800 Message-ID: <4FBE7A47.6090001@linux.vnet.ibm.com> --===============1616301633127616408== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --------------060000080308030607050901 Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Content-Transfer-Encoding: 7bit Hi all, Now I'm using the code generation suites of ovirt-engine-sdk, I find it = is very troublesome. IMO, we can simplify the process. And I want to engaged in it. there are two tools parse the api.xsd and generate the params.py code. = They are generateds_gui.py and generateDS.py. but there still some code can not be generate by these tools. now we = should add these codes manually. the not NOT_GENERATED codes are as follow in the current params.py code: 1. import python module 2. a new attribute of GeneratedsSuper class 3. modify the get_root_tag function. 4. modify the parseString function to shut up the stdout. 5. _rootClassMap 6 . _elementToClassMap 7. findRootClass And I have two ideas about the code generation. For we should not modify the generateDS.py tools. But we can improve it. I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be configured. So I want to add an configure file to tell how to add the extra code = that are not generated by generateDS.py tools. And new python program, as extension of generateDS.py to read the = configure file and generate these codes. Or without the configure file, just make the new python program that = supports an interactive commands. --------------060000080308030607050901 Content-Type: text/html; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

Now I'm using the code generation suites of ovirt-engine-sdk, I find it is very troublesome.

IMO, we can simplify the process. And I want to engaged in it.

there are two tools parse the api.xsd and generate the params.py code. They are generateds_gui.py and generateDS.py.
but there still some code can not be generate by these tools. now we should add these codes manually.

the not NOT_GENERATED codes are as follow in the current params.py code:
1. import python module
2. a new attribute of GeneratedsSuper class
3. modify the get_root_tag function.
4. modify the parseString function to shut up the stdout.
5. _rootClassMap
6 . _elementToClassMap
7. findRootClass

And I have two ideas about the code generation.
For we should not modify the generateDS.py tools.
But we can improve it.

I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be configured.
So I want to add an configure file to tell how to add the extra code that are not generated by generateDS.py tools.
And new python program, as extension of generateDS.py to read the configure file and generate these codes.

Or without the configure file, just make the new python program that supports an interactive commands.
--------------060000080308030607050901-- --===============1616301633127616408== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4KLS0tLS0tLS0tLS0t LS0wNjAwMDAwODAzMDgwMzA2MDcwNTA5MDEKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PUlTTy04ODU5LTE7IGZvcm1hdD1mbG93ZWQKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzog N2JpdAoKSGkgYWxsLAoKTm93IEknbSB1c2luZyB0aGUgY29kZSBnZW5lcmF0aW9uIHN1aXRlcyBv ZiBvdmlydC1lbmdpbmUtc2RrLCBJIGZpbmQgaXQgCmlzIHZlcnkgdHJvdWJsZXNvbWUuCgpJTU8s ICB3ZSBjYW4gc2ltcGxpZnkgdGhlIHByb2Nlc3MuIEFuZCBJIHdhbnQgdG8gZW5nYWdlZCBpbiBp dC4KCnRoZXJlIGFyZSB0d28gdG9vbHMgcGFyc2UgdGhlIGFwaS54c2QgYW5kIGdlbmVyYXRlIHRo ZSBwYXJhbXMucHkgY29kZS4gIApUaGV5IGFyZSBnZW5lcmF0ZWRzX2d1aS5weSBhbmQgZ2VuZXJh dGVEUy5weS4KYnV0IHRoZXJlIHN0aWxsIHNvbWUgY29kZSBjYW4gbm90IGJlIGdlbmVyYXRlIGJ5 IHRoZXNlIHRvb2xzLiBub3cgd2UgCnNob3VsZCBhZGQgdGhlc2UgY29kZXMgbWFudWFsbHkuCgp0 aGUgbm90IE5PVF9HRU5FUkFURUQgY29kZXMgYXJlIGFzIGZvbGxvdyBpbiB0aGUgY3VycmVudCAg cGFyYW1zLnB5IGNvZGU6CjEuICBpbXBvcnQgcHl0aG9uIG1vZHVsZQoyLiAgYSBuZXcgYXR0cmli dXRlIG9mIEdlbmVyYXRlZHNTdXBlciBjbGFzcwozLiAgbW9kaWZ5IHRoZSBnZXRfcm9vdF90YWcg ZnVuY3Rpb24uCjQuICBtb2RpZnkgdGhlIHBhcnNlU3RyaW5nIGZ1bmN0aW9uIHRvIHNodXQgdXAg dGhlIHN0ZG91dC4KNS4gIF9yb290Q2xhc3NNYXAKNiAuIF9lbGVtZW50VG9DbGFzc01hcAo3LiBm aW5kUm9vdENsYXNzCgpBbmQgSSBoYXZlIHR3byBpZGVhcyBhYm91dCB0aGUgY29kZSBnZW5lcmF0 aW9uLgpGb3Igd2Ugc2hvdWxkIG5vdCBtb2RpZnkgdGhlIGdlbmVyYXRlRFMucHkgdG9vbHMuCkJ1 dCB3ZSBjYW4gaW1wcm92ZSBpdC4KCkkgdGhpbmsgdGhlIDEsIDIsIDMsIDcsIGNhbiBiZSBoYXJk LWNvZGUsIGFuZCA0LCA1IGFuZCA2IGNhbiBiZSBjb25maWd1cmVkLgpTbyBJIHdhbnQgdG8gYWRk IGFuIGNvbmZpZ3VyZSBmaWxlIHRvIHRlbGwgaG93IHRvIGFkZCB0aGUgZXh0cmEgY29kZSAKdGhh dCBhcmUgbm90IGdlbmVyYXRlZCAgYnkgZ2VuZXJhdGVEUy5weSB0b29scy4KQW5kICBuZXcgcHl0 aG9uIHByb2dyYW0sIGFzIGV4dGVuc2lvbiBvZiBnZW5lcmF0ZURTLnB5IHRvIHJlYWQgdGhlIApj b25maWd1cmUgZmlsZSBhbmQgZ2VuZXJhdGUgdGhlc2UgY29kZXMuCgpPciB3aXRob3V0IHRoZSBj b25maWd1cmUgZmlsZSwganVzdCBtYWtlIHRoZSBuZXcgcHl0aG9uIHByb2dyYW0gdGhhdCAKc3Vw cG9ydHMgYW4gaW50ZXJhY3RpdmUgY29tbWFuZHMuCgotLS0tLS0tLS0tLS0tLTA2MDAwMDA4MDMw ODAzMDYwNzA1MDkwMQpDb250ZW50LVR5cGU6IHRleHQvaHRtbDsgY2hhcnNldD1JU08tODg1OS0x CkNvbnRlbnQtVHJhbnNmZXItRW5jb2Rpbmc6IDdiaXQKCjxodG1sPgogIDxoZWFkPgoKICAgIDxt ZXRhIGh0dHAtZXF1aXY9ImNvbnRlbnQtdHlwZSIgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0 PUlTTy04ODU5LTEiPgogIDwvaGVhZD4KICA8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIj MDAwMDAwIj4KICAgIEhpIGFsbCwgPGJyPgogICAgPGJyPgogICAgTm93IEknbSB1c2luZyB0aGUg Y29kZSBnZW5lcmF0aW9uIHN1aXRlcyBvZiBvdmlydC1lbmdpbmUtc2RrLCBJIGZpbmQKICAgIGl0 IGlzIHZlcnkgdHJvdWJsZXNvbWUuPGJyPgogICAgPGJyPgogICAgSU1PLCZuYnNwOyB3ZSBjYW4g c2ltcGxpZnkgdGhlIHByb2Nlc3MuIEFuZCBJIHdhbnQgdG8gZW5nYWdlZCBpbiBpdC48YnI+CiAg ICA8YnI+CiAgICB0aGVyZSBhcmUgdHdvIHRvb2xzIHBhcnNlIHRoZSBhcGkueHNkIGFuZCBnZW5l cmF0ZSB0aGUgcGFyYW1zLnB5CiAgICBjb2RlLiZuYnNwOyBUaGV5IGFyZSBnZW5lcmF0ZWRzX2d1 aS5weSBhbmQgZ2VuZXJhdGVEUy5weS48YnI+CiAgICBidXQgdGhlcmUgc3RpbGwgc29tZSBjb2Rl IGNhbiBub3QgYmUgZ2VuZXJhdGUgYnkgdGhlc2UgdG9vbHMuIG5vdyB3ZQogICAgc2hvdWxkIGFk ZCB0aGVzZSBjb2RlcyBtYW51YWxseS4gPGJyPgogICAgPGJyPgogICAgdGhlIG5vdCBOT1RfR0VO RVJBVEVEIGNvZGVzIGFyZSBhcyBmb2xsb3cgaW4gdGhlIGN1cnJlbnQmbmJzcDsgcGFyYW1zLnB5 CiAgICBjb2RlOjxicj4KICAgIDEuJm5ic3A7IGltcG9ydCBweXRob24gbW9kdWxlIDxicj4KICAg IDIuJm5ic3A7IGEgbmV3IGF0dHJpYnV0ZSBvZiBHZW5lcmF0ZWRzU3VwZXIgY2xhc3M8YnI+CiAg ICAzLiZuYnNwOyBtb2RpZnkgdGhlIGdldF9yb290X3RhZyBmdW5jdGlvbi48YnI+CiAgICA0LiZu YnNwOyBtb2RpZnkgdGhlIHBhcnNlU3RyaW5nIGZ1bmN0aW9uIHRvIHNodXQgdXAgdGhlIHN0ZG91 dC4gPGJyPgogICAgNS4mbmJzcDsgX3Jvb3RDbGFzc01hcCA8YnI+CiAgICA2IC4gX2VsZW1lbnRU b0NsYXNzTWFwPGJyPgogICAgNy4gZmluZFJvb3RDbGFzcyA8YnI+CiAgICA8YnI+CiAgICBBbmQg SSBoYXZlIHR3byBpZGVhcyBhYm91dCB0aGUgY29kZSBnZW5lcmF0aW9uLjxicj4KICAgIEZvciB3 ZSBzaG91bGQgbm90IG1vZGlmeSB0aGUgZ2VuZXJhdGVEUy5weSB0b29scy4mbmJzcDsgPGJyPgog ICAgQnV0IHdlIGNhbiBpbXByb3ZlIGl0LiA8YnI+CiAgICA8YnI+CiAgICBJIHRoaW5rIHRoZSAx LCAyLCAzLCA3LCBjYW4gYmUgaGFyZC1jb2RlLCBhbmQgNCwgNSBhbmQgNiBjYW4gYmUKICAgIGNv bmZpZ3VyZWQuPGJyPgogICAgU28gSSB3YW50IHRvIGFkZCBhbiBjb25maWd1cmUgZmlsZSB0byB0 ZWxsIGhvdyB0byBhZGQgdGhlIGV4dHJhIGNvZGUKICAgIHRoYXQgYXJlIG5vdCBnZW5lcmF0ZWQm bmJzcDsgYnkgZ2VuZXJhdGVEUy5weSB0b29scy48YnI+CiAgICBBbmQmbmJzcDsgbmV3IHB5dGhv biBwcm9ncmFtLCBhcyBleHRlbnNpb24gb2YgZ2VuZXJhdGVEUy5weSB0byByZWFkIHRoZQogICAg Y29uZmlndXJlIGZpbGUgYW5kIGdlbmVyYXRlIHRoZXNlIGNvZGVzLjxicj4KICAgIDxicj4KICAg IE9yIHdpdGhvdXQgdGhlIGNvbmZpZ3VyZSBmaWxlLCBqdXN0IG1ha2UgdGhlIG5ldyBweXRob24g cHJvZ3JhbSB0aGF0CiAgICBzdXBwb3J0cyBhbiBpbnRlcmFjdGl2ZSBjb21tYW5kcy4gPGJyPgog ICAgPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtZmFtaWx5OiBhcmlh bCwgc2Fucy1zZXJpZjsKICAgICAgZm9udC1zaXplOiAyNHB4OyBmb250LXN0eWxlOiBub3JtYWw7 IGZvbnQtdmFyaWFudDogbm9ybWFsOwogICAgICBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXIt c3BhY2luZzogbm9ybWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOwogICAgICBvcnBoYW5zOiAyOyB0 ZXh0LWFsaWduOiAtd2Via2l0LWF1dG87IHRleHQtaW5kZW50OiAwcHg7CiAgICAgIHRleHQtdHJh bnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7CiAgICAgIHdvcmQt c3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87CiAgICAgIC13ZWJr aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0NSwgMjQ1 LAogICAgICAyNDUpOyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsgZmxvYXQ6IG5vbmU7ICI+ PC9zcGFuPgogIDwvYm9keT4KPC9odG1sPgoKLS0tLS0tLS0tLS0tLS0wNjAwMDAwODAzMDgwMzA2 MDcwNTA5MDEtLQoK --===============1616301633127616408==-- From mpastern at redhat.com Fri May 25 13:42:06 2012 Content-Type: multipart/mixed; boundary="===============3176814142894246754==" MIME-Version: 1.0 From: Michael Pasternak To: devel at ovirt.org Subject: Re: [Engine-devel] [ovirt-engine-sdk] Simplify the process of the RSDL code generation Date: Fri, 25 May 2012 20:48:50 +0300 Message-ID: <4FBFC602.90105@redhat.com> In-Reply-To: 4FBE7A47.6090001@linux.vnet.ibm.com --===============3176814142894246754== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, On 05/24/2012 09:13 PM, ShaoHe Fen3g wrote: > Hi all, > = > Now I'm using the code generation suites of ovirt-engine-sdk, I find it i= s very troublesome. I completely agree with you, automating python entities generation is on top of my TODO stack see [1], Along with this, there was always something more important to do, and it was delayed time after time, so your help is most welcome. [1] http://www.ovirt.org/wiki/SDK#codegen > = > IMO, we can simplify the process. And I want to engaged in it. > = > there are two tools parse the api.xsd and generate the params.py code. T= hey are generateds_gui.py and generateDS.py. > but there still some code can not be generate by these tools. now we shou= ld add these codes manually. > = > the not NOT_GENERATED codes are as follow in the current params.py code: > 1. import python module > 2. a new attribute of GeneratedsSuper class > 3. modify the get_root_tag function. > 4. modify the parseString function to shut up the stdout. > 5. _rootClassMap > 6 . _elementToClassMap > 7. findRootClass > = > And I have two ideas about the code generation. > For we should not modify the generateDS.py tools. = > But we can improve it. > = > I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be configure= d. > So I want to add an configure file to tell how to add the extra code that= are not generated by generateDS.py tools. > And new python program, as extension of generateDS.py to read the config= ure file and generate these codes. sounds good, btw 5,6 can be constructed programmatically using __all__ gene= rated by generateDS and finding element name in xsd by type (from __all__). > = > Or without the configure file, just make the new python program that supp= orts an interactive commands. > = > = > = > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- = Michael Pasternak RedHat, ENG-Virtualization R&D --===============3176814142894246754==-- From shaohef at linux.vnet.ibm.com Sun May 27 13:06:38 2012 Content-Type: multipart/mixed; boundary="===============8239587862868331865==" MIME-Version: 1.0 From: ShaoHe Feng To: devel at ovirt.org Subject: Re: [Engine-devel] [ovirt-engine-sdk] Simplify the process of the RSDL code generation Date: Mon, 28 May 2012 01:06:25 +0800 Message-ID: <4FC25F11.8090201@linux.vnet.ibm.com> In-Reply-To: 4FBFC602.90105@redhat.com --===============8239587862868331865== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 05/26/2012 01:48 AM, Michael Pasternak wrote: > Hi, > > On 05/24/2012 09:13 PM, ShaoHe Fen3g wrote: >> Hi all, >> >> Now I'm using the code generation suites of ovirt-engine-sdk, I find it = is very troublesome. > I completely agree with you, automating python entities generation is on = top > of my TODO stack see [1], > > Along with this, there was always something more important to do, and > it was delayed time after time, so your help is most welcome. > > [1] http://www.ovirt.org/wiki/SDK#codegen > >> IMO, we can simplify the process. And I want to engaged in it. >> >> there are two tools parse the api.xsd and generate the params.py code. = They are generateds_gui.py and generateDS.py. >> but there still some code can not be generate by these tools. now we sho= uld add these codes manually. >> >> the not NOT_GENERATED codes are as follow in the current params.py code: >> 1. import python module >> 2. a new attribute of GeneratedsSuper class >> 3. modify the get_root_tag function. >> 4. modify the parseString function to shut up the stdout. >> 5. _rootClassMap >> 6 . _elementToClassMap >> 7. findRootClass >> >> And I have two ideas about the code generation. >> For we should not modify the generateDS.py tools. >> But we can improve it. >> >> I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be configur= ed. >> So I want to add an configure file to tell how to add the extra code tha= t are not generated by generateDS.py tools. >> And new python program, as extension of generateDS.py to read the confi= gure file and generate these codes. > sounds good, btw 5,6 can be constructed programmatically using __all__ ge= nerated by generateDS > and finding element name in xsd by type (from __all__). should all the element name in xsd by type be added to _rootClassMap, = and no element can be exception? >> Or without the configure file, just make the new python program that sup= ports an interactive commands. >> >> >> >> _______________________________________________ >> Engine-devel mailing list >> Engine-devel(a)ovirt.org >> http://lists.ovirt.org/mailman/listinfo/engine-devel > --===============8239587862868331865==-- From mpastern at redhat.com Mon May 28 02:49:28 2012 Content-Type: multipart/mixed; boundary="===============0805170273924976071==" MIME-Version: 1.0 From: Michael Pasternak To: devel at ovirt.org Subject: Re: [Engine-devel] [ovirt-engine-sdk] Simplify the process of the RSDL code generation Date: Mon, 28 May 2012 09:56:08 +0300 Message-ID: <4FC32188.6080409@redhat.com> In-Reply-To: 4FC25F11.8090201@linux.vnet.ibm.com --===============0805170273924976071== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 05/27/2012 08:06 PM, ShaoHe Feng wrote: > On 05/26/2012 01:48 AM, Michael Pasternak wrote: >> Hi, >> >> On 05/24/2012 09:13 PM, ShaoHe Fen3g wrote: >>> Hi all, >>> >>> Now I'm using the code generation suites of ovirt-engine-sdk, I find it= is very troublesome. >> I completely agree with you, automating python entities generation is on= top >> of my TODO stack see [1], >> >> Along with this, there was always something more important to do, and >> it was delayed time after time, so your help is most welcome. >> >> [1] http://www.ovirt.org/wiki/SDK#codegen >> >>> IMO, we can simplify the process. And I want to engaged in it. >>> >>> there are two tools parse the api.xsd and generate the params.py code. = They are generateds_gui.py and generateDS.py. >>> but there still some code can not be generate by these tools. now we sh= ould add these codes manually. >>> >>> the not NOT_GENERATED codes are as follow in the current params.py cod= e: >>> 1. import python module >>> 2. a new attribute of GeneratedsSuper class >>> 3. modify the get_root_tag function. >>> 4. modify the parseString function to shut up the stdout. >>> 5. _rootClassMap >>> 6 . _elementToClassMap >>> 7. findRootClass >>> >>> And I have two ideas about the code generation. >>> For we should not modify the generateDS.py tools. >>> But we can improve it. >>> >>> I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be configu= red. >>> So I want to add an configure file to tell how to add the extra code th= at are not generated by generateDS.py tools. >>> And new python program, as extension of generateDS.py to read the conf= igure file and generate these codes. >> sounds good, btw 5,6 can be constructed programmatically using __all__ g= enerated by generateDS >> and finding element name in xsd by type (from __all__). > should all the element name in xsd by type be added to _rootClassMap, an= d no element can be exception? basically yes, cause _rootClassMap is holder which used for (b= y name) type retrieval, only exception is if certain type is not referenced by any other type (then= none will look for it during the type construction), but i would not implement this logic. > = >>> Or without the configure file, just make the new python program that su= pports an interactive commands. >>> >>> >>> >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > = -- = Michael Pasternak RedHat, ENG-Virtualization R&D --===============0805170273924976071==-- From shaohef at linux.vnet.ibm.com Mon May 28 04:01:05 2012 Content-Type: multipart/mixed; boundary="===============6840343285748532061==" MIME-Version: 1.0 From: ShaoHe Feng To: devel at ovirt.org Subject: Re: [Engine-devel] [ovirt-engine-sdk] Simplify the process of the RSDL code generation Date: Mon, 28 May 2012 15:26:43 +0800 Message-ID: <4FC328B3.2050808@linux.vnet.ibm.com> In-Reply-To: 4FC32188.6080409@redhat.com --===============6840343285748532061== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 05/28/2012 02:56 PM, Michael Pasternak wrote: > On 05/27/2012 08:06 PM, ShaoHe Feng wrote: >> On 05/26/2012 01:48 AM, Michael Pasternak wrote: >>> Hi, >>> >>> On 05/24/2012 09:13 PM, ShaoHe Fen3g wrote: >>>> Hi all, >>>> >>>> Now I'm using the code generation suites of ovirt-engine-sdk, I find i= t is very troublesome. >>> I completely agree with you, automating python entities generation is o= n top >>> of my TODO stack see [1], >>> >>> Along with this, there was always something more important to do, and >>> it was delayed time after time, so your help is most welcome. >>> >>> [1] http://www.ovirt.org/wiki/SDK#codegen >>> >>>> IMO, we can simplify the process. And I want to engaged in it. >>>> >>>> there are two tools parse the api.xsd and generate the params.py code.= They are generateds_gui.py and generateDS.py. >>>> but there still some code can not be generate by these tools. now we s= hould add these codes manually. >>>> >>>> the not NOT_GENERATED codes are as follow in the current params.py co= de: >>>> 1. import python module >>>> 2. a new attribute of GeneratedsSuper class >>>> 3. modify the get_root_tag function. >>>> 4. modify the parseString function to shut up the stdout. >>>> 5. _rootClassMap >>>> 6 . _elementToClassMap >>>> 7. findRootClass >>>> >>>> And I have two ideas about the code generation. >>>> For we should not modify the generateDS.py tools. >>>> But we can improve it. >>>> >>>> I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be config= ured. >>>> So I want to add an configure file to tell how to add the extra code t= hat are not generated by generateDS.py tools. >>>> And new python program, as extension of generateDS.py to read the con= figure file and generate these codes. >>> sounds good, btw 5,6 can be constructed programmatically using __all__ = generated by generateDS >>> and finding element name in xsd by type (from __all__). >> should all the element name in xsd by type be added to _rootClassMap, a= nd no element can be exception? > basically yes, cause _rootClassMap is holder which used for = (by name) type retrieval, > only exception is if certain type is not referenced by any other type (th= en none will look for > it during the type construction), but i would not implement this logic. > Hi Michael, what's your account on ovirt IRC channel? >>>> Or without the configure file, just make the new python program that s= upports an interactive commands. >>>> >>>> >>>> >>>> _______________________________________________ >>>> Engine-devel mailing list >>>> Engine-devel(a)ovirt.org >>>> http://lists.ovirt.org/mailman/listinfo/engine-devel > --===============6840343285748532061==-- From shaohef at linux.vnet.ibm.com Mon May 28 04:02:03 2012 Content-Type: multipart/mixed; boundary="===============0738693614788928462==" MIME-Version: 1.0 From: ShaoHe Feng To: devel at ovirt.org Subject: Re: [Engine-devel] [ovirt-engine-sdk] Simplify the process of the RSDL code generation Date: Mon, 28 May 2012 15:54:25 +0800 Message-ID: <4FC32F31.3050308@linux.vnet.ibm.com> In-Reply-To: 4FC328B3.2050808@linux.vnet.ibm.com --===============0738693614788928462== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 05/28/2012 03:26 PM, ShaoHe Feng wrote: > On 05/28/2012 02:56 PM, Michael Pasternak wrote: >> On 05/27/2012 08:06 PM, ShaoHe Feng wrote: >>> On 05/26/2012 01:48 AM, Michael Pasternak wrote: >>>> Hi, >>>> >>>> On 05/24/2012 09:13 PM, ShaoHe Fen3g wrote: >>>>> Hi all, >>>>> >>>>> Now I'm using the code generation suites of ovirt-engine-sdk, I = >>>>> find it is very troublesome. >>>> I completely agree with you, automating python entities generation = >>>> is on top >>>> of my TODO stack see [1], >>>> >>>> Along with this, there was always something more important to do, and >>>> it was delayed time after time, so your help is most welcome. >>>> >>>> [1] http://www.ovirt.org/wiki/SDK#codegen >>>> >>>>> IMO, we can simplify the process. And I want to engaged in it. >>>>> >>>>> there are two tools parse the api.xsd and generate the params.py = >>>>> code. They are generateds_gui.py and generateDS.py. >>>>> but there still some code can not be generate by these tools. now = >>>>> we should add these codes manually. >>>>> >>>>> the not NOT_GENERATED codes are as follow in the current = >>>>> params.py code: >>>>> 1. import python module >>>>> 2. a new attribute of GeneratedsSuper class >>>>> 3. modify the get_root_tag function. >>>>> 4. modify the parseString function to shut up the stdout. >>>>> 5. _rootClassMap >>>>> 6 . _elementToClassMap >>>>> 7. findRootClass >>>>> >>>>> And I have two ideas about the code generation. >>>>> For we should not modify the generateDS.py tools. >>>>> But we can improve it. >>>>> >>>>> I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be = >>>>> configured. >>>>> So I want to add an configure file to tell how to add the extra = >>>>> code that are not generated by generateDS.py tools. >>>>> And new python program, as extension of generateDS.py to read the = >>>>> configure file and generate these codes. >>>> sounds good, btw 5,6 can be constructed programmatically using = >>>> __all__ generated by generateDS >>>> and finding element name in xsd by type (from __all__). >>> should all the element name in xsd by type be added to = >>> _rootClassMap, and no element can be exception? >> basically yes, cause _rootClassMap is holder which used = >> for (by name) type retrieval, >> only exception is if certain type is not referenced by any other type = >> (then none will look for >> it during the type construction), but i would not implement this logic. >> > Hi Michael, > what's your account on ovirt IRC channel? seem I can not log on the #ovirt IRC channel. still some questions. can I edit the generateDS.py directly in order to generate the params.py = code that we expect. and then rename the generateDS.py, put it into the = SDK directory? or an new py program to call the functions of generateDS? >>>>> Or without the configure file, just make the new python program = >>>>> that supports an interactive commands. >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Engine-devel mailing list >>>>> Engine-devel(a)ovirt.org >>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >> > --===============0738693614788928462==-- From mpastern at redhat.com Mon May 28 04:13:32 2012 Content-Type: multipart/mixed; boundary="===============5356853001577939828==" MIME-Version: 1.0 From: Michael Pasternak To: devel at ovirt.org Subject: Re: [Engine-devel] [ovirt-engine-sdk] Simplify the process of the RSDL code generation Date: Mon, 28 May 2012 11:17:37 +0300 Message-ID: <4FC334A1.60209@redhat.com> In-Reply-To: 4FC32F31.3050308@linux.vnet.ibm.com --===============5356853001577939828== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 05/28/2012 10:54 AM, ShaoHe Feng wrote: > On 05/28/2012 03:26 PM, ShaoHe Feng wrote: >> On 05/28/2012 02:56 PM, Michael Pasternak wrote: >>> On 05/27/2012 08:06 PM, ShaoHe Feng wrote: >>>> On 05/26/2012 01:48 AM, Michael Pasternak wrote: >>>>> Hi, >>>>> >>>>> On 05/24/2012 09:13 PM, ShaoHe Fen3g wrote: >>>>>> Hi all, >>>>>> >>>>>> Now I'm using the code generation suites of ovirt-engine-sdk, I find= it is very troublesome. >>>>> I completely agree with you, automating python entities generation is= on top >>>>> of my TODO stack see [1], >>>>> >>>>> Along with this, there was always something more important to do, and >>>>> it was delayed time after time, so your help is most welcome. >>>>> >>>>> [1] http://www.ovirt.org/wiki/SDK#codegen >>>>> >>>>>> IMO, we can simplify the process. And I want to engaged in it. >>>>>> >>>>>> there are two tools parse the api.xsd and generate the params.py cod= e. They are generateds_gui.py and generateDS.py. >>>>>> but there still some code can not be generate by these tools. now we= should add these codes manually. >>>>>> >>>>>> the not NOT_GENERATED codes are as follow in the current params.py = code: >>>>>> 1. import python module >>>>>> 2. a new attribute of GeneratedsSuper class >>>>>> 3. modify the get_root_tag function. >>>>>> 4. modify the parseString function to shut up the stdout. >>>>>> 5. _rootClassMap >>>>>> 6 . _elementToClassMap >>>>>> 7. findRootClass >>>>>> >>>>>> And I have two ideas about the code generation. >>>>>> For we should not modify the generateDS.py tools. >>>>>> But we can improve it. >>>>>> >>>>>> I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be conf= igured. >>>>>> So I want to add an configure file to tell how to add the extra code= that are not generated by generateDS.py tools. >>>>>> And new python program, as extension of generateDS.py to read the c= onfigure file and generate these codes. >>>>> sounds good, btw 5,6 can be constructed programmatically using __all_= _ generated by generateDS >>>>> and finding element name in xsd by type (from __all__). >>>> should all the element name in xsd by type be added to _rootClassMap,= and no element can be exception? >>> basically yes, cause _rootClassMap is holder which used fo= r (by name) type retrieval, >>> only exception is if certain type is not referenced by any other type (= then none will look for >>> it during the type construction), but i would not implement this logic. >>> >> Hi Michael, >> what's your account on ovirt IRC channel? > seem I can not log on the #ovirt IRC channel. mpastern > = > still some questions. > can I edit the generateDS.py directly in order to generate the params.py = code that we expect. and then rename the generateDS.py, put it into the SDK= directory? > or an new py program to call the functions of generateDS? rewriting generateDS means that from now on we maintaining it (including bu= g fixes etc.), i prefer new py module extending generateDS, and leaving maintenance of gen= erateDS to author/community. > = >>>>>> Or without the configure file, just make the new python program that= supports an interactive commands. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Engine-devel mailing list >>>>>> Engine-devel(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> > = -- = Michael Pasternak RedHat, ENG-Virtualization R&D --===============5356853001577939828==-- From shaohef at linux.vnet.ibm.com Mon May 28 07:49:21 2012 Content-Type: multipart/mixed; boundary="===============5070901517664507098==" MIME-Version: 1.0 From: ShaoHe Feng To: devel at ovirt.org Subject: Re: [Engine-devel] [ovirt-engine-sdk] Simplify the process of the RSDL code generation Date: Mon, 28 May 2012 19:49:05 +0800 Message-ID: <4FC36631.80207@linux.vnet.ibm.com> In-Reply-To: 4FC32F31.3050308@linux.vnet.ibm.com --===============5070901517664507098== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable I have write an example. Now it can only add the import module = automatically . see the attachment. What about this way to add the NOT_GENERATED codes? if OK, I will go ahead to add the left NOT_GENERATED codes. such as how to add an attribute of an class. On 05/28/2012 03:54 PM, ShaoHe Feng wrote: > On 05/28/2012 03:26 PM, ShaoHe Feng wrote: >> On 05/28/2012 02:56 PM, Michael Pasternak wrote: >>> On 05/27/2012 08:06 PM, ShaoHe Feng wrote: >>>> On 05/26/2012 01:48 AM, Michael Pasternak wrote: >>>>> Hi, >>>>> >>>>> On 05/24/2012 09:13 PM, ShaoHe Fen3g wrote: >>>>>> Hi all, >>>>>> >>>>>> Now I'm using the code generation suites of ovirt-engine-sdk, I = >>>>>> find it is very troublesome. >>>>> I completely agree with you, automating python entities generation = >>>>> is on top >>>>> of my TODO stack see [1], >>>>> >>>>> Along with this, there was always something more important to do, and >>>>> it was delayed time after time, so your help is most welcome. >>>>> >>>>> [1] http://www.ovirt.org/wiki/SDK#codegen >>>>> >>>>>> IMO, we can simplify the process. And I want to engaged in it. >>>>>> >>>>>> there are two tools parse the api.xsd and generate the params.py = >>>>>> code. They are generateds_gui.py and generateDS.py. >>>>>> but there still some code can not be generate by these tools. now = >>>>>> we should add these codes manually. >>>>>> >>>>>> the not NOT_GENERATED codes are as follow in the current = >>>>>> params.py code: >>>>>> 1. import python module >>>>>> 2. a new attribute of GeneratedsSuper class >>>>>> 3. modify the get_root_tag function. >>>>>> 4. modify the parseString function to shut up the stdout. >>>>>> 5. _rootClassMap >>>>>> 6 . _elementToClassMap >>>>>> 7. findRootClass >>>>>> >>>>>> And I have two ideas about the code generation. >>>>>> For we should not modify the generateDS.py tools. >>>>>> But we can improve it. >>>>>> >>>>>> I think the 1, 2, 3, 7, can be hard-code, and 4, 5 and 6 can be = >>>>>> configured. >>>>>> So I want to add an configure file to tell how to add the extra = >>>>>> code that are not generated by generateDS.py tools. >>>>>> And new python program, as extension of generateDS.py to read = >>>>>> the configure file and generate these codes. >>>>> sounds good, btw 5,6 can be constructed programmatically using = >>>>> __all__ generated by generateDS >>>>> and finding element name in xsd by type (from __all__). >>>> should all the element name in xsd by type be added to = >>>> _rootClassMap, and no element can be exception? >>> basically yes, cause _rootClassMap is holder which used = >>> for (by name) type retrieval, >>> only exception is if certain type is not referenced by any other = >>> type (then none will look for >>> it during the type construction), but i would not implement this logic. >>> >> Hi Michael, >> what's your account on ovirt IRC channel? > seem I can not log on the #ovirt IRC channel. > > still some questions. > can I edit the generateDS.py directly in order to generate the = > params.py code that we expect. and then rename the generateDS.py, put = > it into the SDK directory? > or an new py program to call the functions of generateDS? > >>>>>> Or without the configure file, just make the new python program = >>>>>> that supports an interactive commands. >>>>>> >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> Engine-devel mailing list >>>>>> Engine-devel(a)ovirt.org >>>>>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > --===============5070901517664507098== Content-Type: text/x-python MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="genparams.py" IyEvdXNyL2Jpbi9weXRob24KIwojIENvcHlyaWdodCAoYykgMjAxMCBSZWQgSGF0LCBJbmMuCiMK IyBMaWNlbnNlZCB1bmRlciB0aGUgQXBhY2hlIExpY2Vuc2UsIFZlcnNpb24gMi4wICh0aGUgIkxp Y2Vuc2UiKTsKIyB5b3UgbWF5IG5vdCB1c2UgdGhpcyBmaWxlIGV4Y2VwdCBpbiBjb21wbGlhbmNl IHdpdGggdGhlIExpY2Vuc2UuCiMgWW91IG1heSBvYnRhaW4gYSBjb3B5IG9mIHRoZSBMaWNlbnNl IGF0CiMKIyAgICAgICAgICAgaHR0cDovL3d3dy5hcGFjaGUub3JnL2xpY2Vuc2VzL0xJQ0VOU0Ut Mi4wCiMKIyBVbmxlc3MgcmVxdWlyZWQgYnkgYXBwbGljYWJsZSBsYXcgb3IgYWdyZWVkIHRvIGlu IHdyaXRpbmcsIHNvZnR3YXJlCiMgZGlzdHJpYnV0ZWQgdW5kZXIgdGhlIExpY2Vuc2UgaXMgZGlz dHJpYnV0ZWQgb24gYW4gIkFTIElTIiBCQVNJUywKIyBXSVRIT1VUIFdBUlJBTlRJRVMgT1IgQ09O RElUSU9OUyBPRiBBTlkgS0lORCwgZWl0aGVyIGV4cHJlc3Mgb3IgaW1wbGllZC4KIyBTZWUgdGhl IExpY2Vuc2UgZm9yIHRoZSBzcGVjaWZpYyBsYW5ndWFnZSBnb3Zlcm5pbmcgcGVybWlzc2lvbnMg YW5kCiMgbGltaXRhdGlvbnMgdW5kZXIgdGhlIExpY2Vuc2UuCiMKCmltcG9ydCByZQppbXBvcnQg c3lzCiNJIGhhdmUgZmluZCBhIGdvb2Qgd2F5IHRvIGltcG9ydCB0aGUgZ2VuZXJhdGVEUyBtb2R1 bGUsCiMgU28gSSBhZGQgdGhpcyBtb2R1bGUgcGF0aCB0byBzeXMgcGF0aCwgdGVudGF0aXZlbHkK c3lzLnBhdGguYXBwZW5kKCIvdXNyL2xpYi9weXRob24yLjcvc2l0ZS1wYWNrYWdlcy9nZW5lcmF0 ZURTLTIuN2ItcHkyLjcuZWdnL0VHRy1JTkZPL3NjcmlwdHMvIikKdHJ5OgogICAgaW1wb3J0IGdl bmVyYXRlRFMKZXhjZXB0IEltcG9ydEVycm9yOgogICAgcHJpbnQgIkVycm9yOiBNb2R1bGUgZ2Vu ZXJhdGVEUyBub3QgYXZhaWxhYmxlLiIKICAgIGV4aXQoMSkKZnJvbSBnZW5lcmF0ZURTIGltcG9y dCAqCgpkZWYgZmluZFRoZUxhc3RJbXBvcnRNb2R1bGUoaGVhZFRlbXBsYXRlKToKICAgICMgSSBz dXBwb3NlIHRoZSBjb2RlIGdlbmVyYXRlZCBieSBnZW5lcmF0ZURTIHNob3VsZCBpbXBvcnQgc29t ZSBjb2RlLiAKICAgIHAgPSByZS5jb21waWxlKCdcbmltcG9ydFxzLionKQogICAgbWF0Y2ggPSBw LmZpbmRhbGwoaGVhZFRlbXBsYXRlKQogICAgcmV0dXJuICBtYXRjaC5wb3AoKQoKZGVmIGFkZEV4 dHJhSW1wb3J0TW9kdWxlKGhlYWRUZW1wbGF0ZSwgcnVsZSwgbW9kdWxlcz1bXSk6IAogICAgaWYg bm90IG1vZHVsZXMgb3Igbm90IHJ1bGU6CiAgICAgICAgcmV0dXJuIGhlYWRUZW1wbGF0ZQogICAg cmVwbGFjZSA9IHJ1bGUgKyAiXG5cbiMgQmVnaW4gTk9UX0dFTkVSQVRFRFxuIgogICAgZm9yIG1v dWRsZSBpbiBtb2R1bGVzOgogICAgICAgIHJlcGxhY2UgPSByZXBsYWNlICsgbW91ZGxlICsgIlxu IiAKICAgIHJlcGxhY2UgPSByZXBsYWNlICsgIiMgRW5kIE5PVF9HRU5FUkFURUQiCiAgICByZXR1 cm4gcmUuc3ViKHJ1bGUsIHJlcGxhY2UsIGdlbmVyYXRlRFMuVEVNUExBVEVfSEVBREVSLCAxKQoK cnVsZSA9IGZpbmRUaGVMYXN0SW1wb3J0TW9kdWxlKGdlbmVyYXRlRFMuVEVNUExBVEVfSEVBREVS KQoKI3RoaXMgbW9kdWxlcyBsaXN0IGNhbiBiZSBzZXQgaW4gYSBjb25maWd1cmUgZmlsZQptb2R1 bGVzID0gWyJmcm9tIG92aXJ0c2RrLnV0aWxzLnJlZmxlY3Rpb25oZWxwZXIgaW1wb3J0IFJlZmxl Y3Rpb25IZWxwZXIiXQpnZW5lcmF0ZURTLlRFTVBMQVRFX0hFQURFUiA9IGFkZEV4dHJhSW1wb3J0 TW9kdWxlKAogICAgICAgICAgICAgICAgICAgIGdlbmVyYXRlRFMuVEVNUExBVEVfSEVBREVSLCBy dWxlLCBtb2R1bGVzKQojbm93LCBpdCBpcyBvayB0byBhZGQgdGhlIGltcG9ydCBtb2R1bGUuCnBy aW50IGdlbmVyYXRlRFMuVEVNUExBVEVfSEVBREVSCgo= --===============5070901517664507098==-- From shaohef at linux.vnet.ibm.com Thu Jun 7 11:14:12 2012 Content-Type: multipart/mixed; boundary="===============8530116869558395228==" MIME-Version: 1.0 From: ShaoHe Feng To: devel at ovirt.org Subject: Re: [Engine-devel] [ovirt-engine-sdk] some questions about the params.py code generated by generateSD Date: Thu, 07 Jun 2012 23:14:00 +0800 Message-ID: <4FD0C538.1080001@linux.vnet.ibm.com> In-Reply-To: 4FBE7A47.6090001@linux.vnet.ibm.com --===============8530116869558395228== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --------------040905020303040609040101 Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed Content-Transfer-Encoding: 7bit Hi all, as we all know the current params.py was not completely by the = generateSD.py, there are parts that have to be updated manually. now I have post a primarypatch to improve it. = http://gerrit.ovirt.org/#/c/4880/ it can generate some codes, but still two parts codes can not be generated. they aretwo dictionaries: _rootClassMap and _elementToClassMap. However, for I do get any clue to know these two dictionaries from the = params.py. there are some questions: 1. And the __all__ list which include all the classes of _rootClassMap and = _elementToClassMap. And there some classes both in _rootClassMap and _elementToClassMap. 2. And some of class in _rootClassMap inherit GeneratedsSuper class, some = inherit BaseResource class, and two classes inherit Link class. And it is the same with _elementToClassMap. so what is the difference between _rootClassMap and _elementToClassMap. What rule to generate these two dictionaries. 3. And also, how to generate the keys in _rootClassMap and = _elementToClassMap.Any rule to generate them? there are some items in these two dictionaries "access_control_list" : = AccessControlList, # "_" among the word in key "api" : API, "body" : Body, "iscsi" : = IscsiDetails, # key "iscsi" is one part of value "IscsiDetails" "storage_domain" : StorageDomain, "topology" : CpuTopology, "creation_status" : Status, # = key has a more word "creation" than the value. "parent" : TagParent --------------040905020303040609040101 Content-Type: text/html; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit Hi all,

as we all know the current params.py was not completely by the generateSD.py, there are parts that have to be updated manually.

now I have post a primary patch to improve it. http://gerrit.ovirt.org/#/c/4880/

it can generate some codes, but still two parts codes can not be generated.

they are two dictionaries: _rootClassMap and _elementToClassMap.<= br>
However, for I do get any clue to know these two dictionaries from the params.py.

there are some questions:
1.
And the __all__ list&= nbsp; which include all the classes of _rootClassMap and _elementToClassMap.
And there some classes both in _rootClassMap and _elementToClassMap.

2.
And some of class in _rootClassMap inherit GeneratedsSuper class, some inherit BaseResource class , and two classes inherit Link class.
And it is the same with _el= ementToClassMap.

so what is the difference between _rootClassMap and _elementToClassMap.
What rule to generate these two dictionaries.

3.
And also, how to generate the keys in _rootClassMap and _elementToClassMap.Any rule to generate them?

there are some items in these two dictionaries

           &nb= sp;          "access_control_l= ist"           : AccessControlList,   # "_" among the word in key
           &nb= sp;          "api"  =             &nb= sp;            =          : API,           = ;            &n= bsp;
           &nb= sp;          "body"  = ;            &n= bsp;            = ;      : Body,
=    "iscsi"         =             &nb= sp;           : IscsiDetails,         &n= bsp;   # key "iscsi" is one part of value "IscsiDetails"
       &nb= sp;            "storage_domain"         = ;       : StorageDomain,
           &nb= sp;          "topology" &= nbsp;           &nbs= p;             : CpuTopology,
        = ;            &n= bsp; "creation_status"        &nbs= p;         : Status,  &nb= sp;            =    # key has a more word "creation" than= the value.
        = ;            &n= bsp; "parent"          &= nbsp;           &nbs= p;         : TagParent

--------------040905020303040609040101-- --===============8530116869558395228== Content-Type: multipart/alternative MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="attachment.bin" VGhpcyBpcyBhIG11bHRpLXBhcnQgbWVzc2FnZSBpbiBNSU1FIGZvcm1hdC4KLS0tLS0tLS0tLS0t LS0wNDA5MDUwMjAzMDMwNDA2MDkwNDAxMDEKQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFy c2V0PUlTTy04ODU5LTE7IGZvcm1hdD1mbG93ZWQKQ29udGVudC1UcmFuc2Zlci1FbmNvZGluZzog N2JpdAoKSGkgYWxsLAoKYXMgd2UgYWxsIGtub3cgdGhlIGN1cnJlbnQgcGFyYW1zLnB5IHdhcyBu b3QgY29tcGxldGVseSBieSB0aGUgCmdlbmVyYXRlU0QucHksIHRoZXJlIGFyZSBwYXJ0cyB0aGF0 IGhhdmUgdG8gYmUgdXBkYXRlZCBtYW51YWxseS4KCm5vdyBJIGhhdmUgcG9zdCBhIHByaW1hcnlw YXRjaCB0byBpbXByb3ZlIGl0LiAKaHR0cDovL2dlcnJpdC5vdmlydC5vcmcvIy9jLzQ4ODAvCgpp dCBjYW4gZ2VuZXJhdGUgc29tZSBjb2RlcywgYnV0IHN0aWxsIHR3byBwYXJ0cyBjb2RlcyBjYW4g bm90IGJlIGdlbmVyYXRlZC4KCnRoZXkgYXJldHdvIGRpY3Rpb25hcmllczogX3Jvb3RDbGFzc01h cCBhbmQgX2VsZW1lbnRUb0NsYXNzTWFwLgoKSG93ZXZlciwgZm9yIEkgZG8gZ2V0IGFueSBjbHVl IHRvIGtub3cgdGhlc2UgdHdvIGRpY3Rpb25hcmllcyAgZnJvbSB0aGUgCnBhcmFtcy5weS4KCnRo ZXJlIGFyZSBzb21lIHF1ZXN0aW9uczoKMS4KQW5kIHRoZSBfX2FsbF9fIGxpc3QgIHdoaWNoIGlu Y2x1ZGUgYWxsIHRoZSBjbGFzc2VzIG9mIF9yb290Q2xhc3NNYXAgYW5kIApfZWxlbWVudFRvQ2xh c3NNYXAuCkFuZCB0aGVyZSBzb21lIGNsYXNzZXMgIGJvdGggaW4gX3Jvb3RDbGFzc01hcCBhbmQg X2VsZW1lbnRUb0NsYXNzTWFwLgoKMi4KQW5kICBzb21lIG9mIGNsYXNzIGluIF9yb290Q2xhc3NN YXAgaW5oZXJpdCBHZW5lcmF0ZWRzU3VwZXIgY2xhc3MsIHNvbWUgCmluaGVyaXQgQmFzZVJlc291 cmNlIGNsYXNzLCBhbmQgdHdvIGNsYXNzZXMgaW5oZXJpdCBMaW5rIGNsYXNzLgpBbmQgaXQgaXMg dGhlIHNhbWUgd2l0aCBfZWxlbWVudFRvQ2xhc3NNYXAuCgpzbyB3aGF0IGlzIHRoZSBkaWZmZXJl bmNlIGJldHdlZW4gX3Jvb3RDbGFzc01hcCBhbmQgX2VsZW1lbnRUb0NsYXNzTWFwLgpXaGF0IHJ1 bGUgdG8gZ2VuZXJhdGUgdGhlc2UgdHdvIGRpY3Rpb25hcmllcy4KCjMuCkFuZCBhbHNvLCBob3cg dG8gZ2VuZXJhdGUgdGhlIGtleXMgaW4gX3Jvb3RDbGFzc01hcCBhbmQgCl9lbGVtZW50VG9DbGFz c01hcC5BbnkgcnVsZSB0byBnZW5lcmF0ZSB0aGVtPwoKdGhlcmUgYXJlIHNvbWUgaXRlbXMgaW4g dGhlc2UgdHdvIGRpY3Rpb25hcmllcwoKICAgICAgICAgICAgICAgICAgICAgICAiYWNjZXNzX2Nv bnRyb2xfbGlzdCIgICAgICAgICAgIDogCkFjY2Vzc0NvbnRyb2xMaXN0LCAgICMgICJfIiBhbW9u ZyB0aGUgd29yZCBpbiBrZXkKICAgICAgICAgICAgICAgICAgICAgICAiYXBpIiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDogQVBJLAogICAgICAgICAgICAgICAgICAgICAgICJi b2R5IiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDogQm9keSwKICAgICAgICAgICAg ICAgICAgICAgICAgImlzY3NpIiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIDogCklz Y3NpRGV0YWlscywgICAgICAgICAgICAgIyBrZXkgImlzY3NpIiBpcyBvbmUgcGFydCBvZiB2YWx1 ZSAiSXNjc2lEZXRhaWxzIgogICAgICAgICAgICAgICAgICAgICAgICJzdG9yYWdlX2RvbWFpbiIg ICAgICAgICAgICAgICAgOiBTdG9yYWdlRG9tYWluLAogICAgICAgICAgICAgICAgICAgICAgICJ0 b3BvbG9neSIgICAgICAgICAgICAgICAgICAgICAgICAgICA6IENwdVRvcG9sb2d5LAogICAgICAg ICAgICAgICAgICAgICAgICJjcmVhdGlvbl9zdGF0dXMiICAgICAgICAgICAgICAgICAgOiBTdGF0 dXMsICMgCmtleSBoYXMgYSBtb3JlIHdvcmQgICJjcmVhdGlvbiIgIHRoYW4gdGhlIHZhbHVlLgog ICAgICAgICAgICAgICAgICAgICAgICJwYXJlbnQiICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA6IFRhZ1BhcmVudAoKCgoKCgoKLS0tLS0tLS0tLS0tLS0wNDA5MDUwMjAzMDMwNDA2MDkw NDAxMDEKQ29udGVudC1UeXBlOiB0ZXh0L2h0bWw7IGNoYXJzZXQ9SVNPLTg4NTktMQpDb250ZW50 LVRyYW5zZmVyLUVuY29kaW5nOiA3Yml0Cgo8aHRtbD4KICA8aGVhZD4KICAgIDxtZXRhIGNvbnRl bnQ9InRleHQvaHRtbDsgY2hhcnNldD1JU08tODg1OS0xIgogICAgICBodHRwLWVxdWl2PSJDb250 ZW50LVR5cGUiPgogIDwvaGVhZD4KICA8Ym9keSBiZ2NvbG9yPSIjRkZGRkZGIiB0ZXh0PSIjMDAw MDAwIj4KICAgIDxmb250IGNvbG9yPSIjMDAwMDAwIj5IaSBhbGwsPGJyPgogICAgICA8YnI+CiAg ICA8L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDAwMDAiIHNpemU9IjMiPmFzIHdlIGFsbCBrbm93IHRo ZSBjdXJyZW50CiAgICAgIHBhcmFtcy5weSB3YXMgbm90IGNvbXBsZXRlbHkgYnkgdGhlIGdlbmVy YXRlU0QucHksJm5ic3A7IDwvZm9udD48Zm9udAogICAgICBjb2xvcj0iIzAwMDAwMCI+PGZvbnQg c2l6ZT0iMyI+dGhlcmUgYXJlIHBhcnRzIHRoYXQgaGF2ZSB0byBiZQogICAgICAgIHVwZGF0ZWQg bWFudWFsbHkuPC9mb250Pjxicj4KICAgICAgPGJyPgogICAgICBub3cgSSBoYXZlIHBvc3QgYSA8 L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDAwMDAiIHNpemU9IjMiPnByaW1hcnk8L2ZvbnQ+PGZvbnQK ICAgICAgY29sb3I9IiMwMDAwMDAiPiBwYXRjaCB0byBpbXByb3ZlIGl0LgogICAgICA8YSBjbGFz cz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0IiBocmVmPSJodHRwOi8vZ2Vycml0Lm92aXJ0Lm9yZy8j L2MvNDg4MC8iPmh0dHA6Ly9nZXJyaXQub3ZpcnQub3JnLyMvYy80ODgwLzwvYT48YnI+CiAgICAg IDxicj4KICAgICAgaXQgY2FuIGdlbmVyYXRlIHNvbWUgY29kZXMsIGJ1dCBzdGlsbCB0d28gcGFy dHMgY29kZXMgY2FuIG5vdCBiZQogICAgICBnZW5lcmF0ZWQuPGJyPgogICAgICA8YnI+CiAgICAg IHRoZXkgYXJlPC9mb250Pjxmb250IGNvbG9yPSIjMDAwMDAwIiBzaXplPSIzIj4gdHdvIGRpY3Rp b25hcmllczoKICAgICAgX3Jvb3RDbGFzc01hcCBhbmQgX2VsZW1lbnRUb0NsYXNzTWFwPC9mb250 Pjxmb250IGNvbG9yPSIjMDAwMDAwIj4uPGJyPgogICAgICA8YnI+CiAgICAgIEhvd2V2ZXIsIGZv ciBJIGRvIGdldCBhbnkgY2x1ZSB0byBrbm93IHRoZXNlIDwvZm9udD48Zm9udAogICAgICBjb2xv cj0iIzAwMDAwMCIgc2l6ZT0iMyI+IHR3byBkaWN0aW9uYXJpZXM8L2ZvbnQ+PGZvbnQKICAgICAg Y29sb3I9IiMwMDAwMDAiPiZuYnNwOyBmcm9tIHRoZSZuYnNwOzwvZm9udD48Zm9udCBjb2xvcj0i IzAwMDAwMCIgc2l6ZT0iMyI+CiAgICAgIHBhcmFtcy5weTwvZm9udD48Zm9udCBjb2xvcj0iIzAw MDAwMCI+Ljxicj4KICAgICAgPGJyPgogICAgICB0aGVyZSBhcmUgc29tZSBxdWVzdGlvbnM6PGJy PgogICAgICAxLjxicj4KICAgICAgQW5kIHRoZSZuYnNwOzwvZm9udD48Zm9udCBjb2xvcj0iIzAw MDAwMCIgc2l6ZT0iMyI+IF9fYWxsX18gbGlzdCZuYnNwOyB3aGljaAogICAgICBpbmNsdWRlIGFs bCB0aGUgY2xhc3NlcyBvZiBfcm9vdENsYXNzTWFwIGFuZCBfZWxlbWVudFRvQ2xhc3NNYXA8L2Zv bnQ+PGZvbnQKICAgICAgY29sb3I9IiMwMDAwMDAiPi4gPGJyPgogICAgICBBbmQgdGhlcmUgc29t ZSBjbGFzc2VzJm5ic3A7IGJvdGggaW4gPC9mb250Pjxmb250IGNvbG9yPSIjMDAwMDAwIgogICAg ICBzaXplPSIzIj4gX3Jvb3RDbGFzc01hcCBhbmQgX2VsZW1lbnRUb0NsYXNzTWFwPC9mb250Pjxm b250CiAgICAgIGNvbG9yPSIjMDAwMDAwIj4uIDxicj4KICAgICAgPGJyPgogICAgICAyLjxicj4K ICAgIDwvZm9udD48Zm9udCBjb2xvcj0iIzAwMDAwMCI+QW5kJm5ic3A7IHNvbWUgb2YgY2xhc3Mg aW4gPC9mb250Pjxmb250CiAgICAgIGNvbG9yPSIjMDAwMDAwIiBzaXplPSIzIj5fcm9vdENsYXNz TWFwIGluaGVyaXQgR2VuZXJhdGVkc1N1cGVyCiAgICAgIGNsYXNzLCBzb21lIDwvZm9udD48Zm9u dCBjb2xvcj0iIzAwMDAwMCIgc2l6ZT0iMyI+aW5oZXJpdAogICAgICBCYXNlUmVzb3VyY2UgY2xh c3M8L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDAwMDAiPiAsIGFuZCB0d28gY2xhc3NlcwogICAgICBp bmhlcml0IExpbmsgY2xhc3MuPGJyPgogICAgICBBbmQgaXQgaXMgdGhlIHNhbWUgd2l0aCA8L2Zv bnQ+PGZvbnQgY29sb3I9IiMwMDAwMDAiIHNpemU9IjMiPl9lbGVtZW50VG9DbGFzc01hcC48YnI+ CiAgICAgIDxicj4KICAgICAgc28gd2hhdCBpcyB0aGUgZGlmZmVyZW5jZSBiZXR3ZWVuIDwvZm9u dD48Zm9udCBjb2xvcj0iIzAwMDAwMCIKICAgICAgc2l6ZT0iMyI+X3Jvb3RDbGFzc01hcCBhbmQg X2VsZW1lbnRUb0NsYXNzTWFwLjxicj4KICAgICAgV2hhdCBydWxlIHRvIGdlbmVyYXRlIHRoZXNl IHR3byA8L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDAwMDAiCiAgICAgIHNpemU9IjMiPmRpY3Rpb25h cmllczwvZm9udD48Zm9udCBjb2xvcj0iIzAwMDAwMCI+Ljxicj4KICAgICAgPGJyPgogICAgICAz LiA8YnI+CiAgICA8L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDAwMDAiIHNpemU9IjMiPkFuZCBhbHNv LCBob3cgdG8gZ2VuZXJhdGUgdGhlCiAgICAgIGtleXMgaW4gPC9mb250Pjxmb250IGNvbG9yPSIj MDAwMDAwIiBzaXplPSIzIj5fcm9vdENsYXNzTWFwIGFuZAogICAgICBfZWxlbWVudFRvQ2xhc3NN YXAuPC9mb250Pjxmb250IGNvbG9yPSIjMDAwMDAwIj5BbnkgcnVsZSB0bwogICAgICBnZW5lcmF0 ZSB0aGVtPzxicj4KICAgICAgPGJyPgogICAgICB0aGVyZSBhcmUgc29tZSBpdGVtcyBpbiB0aGVz ZSB0d28gPC9mb250Pjxmb250IGNvbG9yPSIjMDAwMDAwIgogICAgICBzaXplPSIzIj5kaWN0aW9u YXJpZXM8L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDAwMDAiPjxicj4KICAgICAgPGJyPgogICAgICAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgImFjY2Vzc19jb250cm9sX2xpc3QiJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDoKICAgICAgQWNjZXNzQ29udHJv bExpc3QsJm5ic3A7Jm5ic3A7ICMmbmJzcDsgIl8iIGFtb25nIHRoZSB3b3JkIGluIGtleTxicj4K ICAgICAgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7ICJhcGkiJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IDoKICAgICAgQVBJLCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YnI+CiAg ICAgICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAiYm9keSImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOgogICAgICBCb2R5 LCA8YnI+CiAgICAgICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsgImlzY3NpIiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA6CiAgICAgIElzY3NpRGV0YWlscywmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgIyBrZXkgIjwv Zm9udD48Zm9udCBjb2xvcj0iIzAwMDAwMCI+aXNjc2k8L2ZvbnQ+PGZvbnQKICAgICAgY29sb3I9 IiMwMDAwMDAiPiIgaXMgb25lIHBhcnQgb2YgdmFsdWUgIjwvZm9udD48Zm9udAogICAgICBjb2xv cj0iIzAwMDAwMCI+SXNjc2lEZXRhaWxzIjwvZm9udD48YnI+CiAgICA8Zm9udCBjb2xvcj0iIzAw MDAwMCI+Jm5ic3A7ICZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsKICAgICAgInN0b3JhZ2VfZG9tYWluIiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyA6IFN0b3JhZ2VEb21haW4sPGJyPgogICAgICAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgInRvcG9sb2d5 IiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA6CiAgICAgIENwdVRv cG9sb2d5LCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8L2ZvbnQ+PGJyPgogICAgPGZvbnQgY29sb3I9IiMwMDAwMDAiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOwog ICAgICAiY3JlYXRpb25fc3RhdHVzIiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyA6IFN0YXR1cywmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgPC9mb250Pjxmb250CiAgICAgIGNvbG9yPSIjMDAwMDAwIj4jIGtleSBoYXMgYSBt b3JlIHdvcmQmbmJzcDsgIjwvZm9udD48Zm9udAogICAgICBjb2xvcj0iIzAwMDAwMCI+Y3JlYXRp b248L2ZvbnQ+PGZvbnQgY29sb3I9IiMwMDAwMDAiPiImbmJzcDsgdGhhbiB0aGUKICAgICAgdmFs dWUuPC9mb250Pjxicj4KICAgIDxmb250IGNvbG9yPSIjMDAwMDAwIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsKICAg ICAgInBhcmVudCImbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgOiBUYWdQYXJlbnQ8YnI+CiAgICAgIDxicj4KICAg ICAgPGJyPgogICAgICA8YnI+CiAgICA8L2ZvbnQ+PGJyPgogICAgPGJyPgogICAgPHNwYW4gc3R5 bGU9ImNvbG9yOiByZ2IoNTEsIDUxLCA1MSk7IGZvbnQtZmFtaWx5OiBhcmlhbCwgc2Fucy1zZXJp ZjsKICAgICAgZm9udC1zaXplOiAyNHB4OyBmb250LXN0eWxlOiBub3JtYWw7IGZvbnQtdmFyaWFu dDogbm9ybWFsOwogICAgICBmb250LXdlaWdodDogbm9ybWFsOyBsZXR0ZXItc3BhY2luZzogbm9y bWFsOyBsaW5lLWhlaWdodDogbm9ybWFsOwogICAgICBvcnBoYW5zOiAyOyB0ZXh0LWFsaWduOiAt d2Via2l0LWF1dG87IHRleHQtaW5kZW50OiAwcHg7CiAgICAgIHRleHQtdHJhbnNmb3JtOiBub25l OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3aWRvd3M6IDI7CiAgICAgIHdvcmQtc3BhY2luZzogMHB4 OyAtd2Via2l0LXRleHQtc2l6ZS1hZGp1c3Q6IGF1dG87CiAgICAgIC13ZWJraXQtdGV4dC1zdHJv a2Utd2lkdGg6IDBweDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI0NSwgMjQ1LAogICAgICAyNDUp OyBkaXNwbGF5OiBpbmxpbmUgIWltcG9ydGFudDsgZmxvYXQ6IG5vbmU7ICI+PC9zcGFuPiA8YnI+ CiAgPC9ib2R5Pgo8L2h0bWw+CgotLS0tLS0tLS0tLS0tLTA0MDkwNTAyMDMwMzA0MDYwOTA0MDEw MS0tCgo= --===============8530116869558395228==-- From jhernand at redhat.com Thu Jun 7 14:04:43 2012 Content-Type: multipart/mixed; boundary="===============0627928472627519397==" MIME-Version: 1.0 From: Juan Hernandez To: devel at ovirt.org Subject: Re: [Engine-devel] [ovirt-engine-sdk] some questions about the params.py code generated by generateSD Date: Thu, 07 Jun 2012 20:04:32 +0200 Message-ID: <4FD0ED30.5010804@redhat.com> In-Reply-To: 4FD0C538.1080001@linux.vnet.ibm.com --===============0627928472627519397== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 06/07/2012 05:14 PM, ShaoHe Feng wrote: > Hi all, > > as we all know the current params.py was not completely by the > generateSD.py, there are parts that have to be updated manually. > > now I have post a primarypatch to improve it. > http://gerrit.ovirt.org/#/c/4880/ > > it can generate some codes, but still two parts codes can not be generate= d. > > they aretwo dictionaries: _rootClassMap and _elementToClassMap. > > However, for I do get any clue to know these two dictionaries from the > params.py. The reason for these dictionaries is that "generateDS.py" generates = classes for the complex types inside the API .xsd, but it doesn't = generate anything for the tags that can appear as root tags in the XML = documents used by the API. The map helps the parser find the classes = that correspond to each of those tags. It might be possible to generate this map from the list of classes using = a rule like this: CamelCaseName -> camel_case_names But there are exceptions like these: VLAN -> vlan IPs -> ips IscsiDetails -> iscsi You could write code that takes into account the exceptions and = generates the map. But I think it is not worth, and error prone. I would = rather take that chunk of code out of params.py and move it to an = external file or to a constant, like you do for other chunks of code in = paramsconf.py. > there are some questions: > 1. > And the __all__ list which include all the classes of _rootClassMap and > _elementToClassMap. > And there some classes both in _rootClassMap and _elementToClassMap. The "__all__" list is just a python mechanism to control the symbols = that are imported when you do something like "from whatever import *". = In this case "generateDS.py" is making sure that all the generated = classes are imported, which is not really relevant for us. > 2. > And some of class in _rootClassMap inherit GeneratedsSuper class, some > inherit BaseResource class, and two classes inherit Link class. > And it is the same with _elementToClassMap. > > so what is the difference between _rootClassMap and _elementToClassMap. > What rule to generate these two dictionaries. I can't find any difference between those two dictionaries, they serve = exactly the same purpose. Maybe Michael had a future use in mind. > 3. > And also, how to generate the keys in _rootClassMap and > _elementToClassMap.Any rule to generate them? > > there are some items in these two dictionaries > > "access_control_list" : > AccessControlList, # "_" among the word in key > "api" : API, > "body" : Body, > "iscsi" : > IscsiDetails, # key "iscsi" is one part of value "IscsiDetail= s" > "storage_domain" : StorageDomain, > "topology" : CpuTopolog= y, > "creation_status" : Status, # > key has a more word "creation" than the value. > "parent" : TagPare= nt -- = Direcci=C3=B3n Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta = 3=C2=BAD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid =E2=80=93 C.I.F. B82657941 - Red Ha= t S.L. --===============0627928472627519397==-- From shaohef at linux.vnet.ibm.com Fri Jun 8 13:30:31 2012 Content-Type: multipart/mixed; boundary="===============5855405616202219808==" MIME-Version: 1.0 From: ShaoHe Feng To: devel at ovirt.org Subject: Re: [Engine-devel] [ovirt-engine-sdk] some questions about the params.py code generated by generateSD Date: Sat, 09 Jun 2012 01:30:21 +0800 Message-ID: <4FD236AD.1090200@linux.vnet.ibm.com> In-Reply-To: 4FD0ED30.5010804@redhat.com --===============5855405616202219808== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable still a question. I find there are reduplicate items in _rootClassMap dictionary of = ./src/ovirtsdk/xml/params.py file. such as: 1. in line 18924 "storage" : Storage, in line 18931 "storage" : Storage, above items has same key and value. 2. in line 18905 "product_info" : ProductInfo, in line 18934 "product_info" : ProductInfo, above items has same key and value. 3. in line 18953 "vm_pause_details" : VmPauseDetails, in line 18962 "vm_pause_detail" : VmPauseDetails, above items has value but different key. is it OK ? or should I commit a patch to fix it? On 06/08/2012 02:04 AM, Juan Hernandez wrote: > On 06/07/2012 05:14 PM, ShaoHe Feng wrote: >> Hi all, >> >> as we all know the current params.py was not completely by the >> generateSD.py, there are parts that have to be updated manually. >> >> now I have post a primarypatch to improve it. >> http://gerrit.ovirt.org/#/c/4880/ >> >> it can generate some codes, but still two parts codes can not be = >> generated. >> >> they aretwo dictionaries: _rootClassMap and _elementToClassMap. >> >> However, for I do get any clue to know these two dictionaries from the >> params.py. > > The reason for these dictionaries is that "generateDS.py" generates = > classes for the complex types inside the API .xsd, but it doesn't = > generate anything for the tags that can appear as root tags in the XML = > documents used by the API. The map helps the parser find the classes = > that correspond to each of those tags. > > It might be possible to generate this map from the list of classes = > using a rule like this: > > CamelCaseName -> camel_case_names > > But there are exceptions like these: > > VLAN -> vlan > IPs -> ips > IscsiDetails -> iscsi > > You could write code that takes into account the exceptions and = > generates the map. But I think it is not worth, and error prone. I = > would rather take that chunk of code out of params.py and move it to = > an external file or to a constant, like you do for other chunks of = > code in paramsconf.py. > >> there are some questions: >> 1. >> And the __all__ list which include all the classes of _rootClassMap and >> _elementToClassMap. >> And there some classes both in _rootClassMap and _elementToClassMap. > > The "__all__" list is just a python mechanism to control the symbols = > that are imported when you do something like "from whatever import *". = > In this case "generateDS.py" is making sure that all the generated = > classes are imported, which is not really relevant for us. > >> 2. >> And some of class in _rootClassMap inherit GeneratedsSuper class, some >> inherit BaseResource class, and two classes inherit Link class. >> And it is the same with _elementToClassMap. >> >> so what is the difference between _rootClassMap and _elementToClassMap. >> What rule to generate these two dictionaries. > > I can't find any difference between those two dictionaries, they serve = > exactly the same purpose. Maybe Michael had a future use in mind. > >> 3. >> And also, how to generate the keys in _rootClassMap and >> _elementToClassMap.Any rule to generate them? >> >> there are some items in these two dictionaries >> >> "access_control_list" : >> AccessControlList, # "_" among the word in key >> "api" : API, >> "body" : Body, >> "iscsi" : >> IscsiDetails, # key "iscsi" is one part of value = >> "IscsiDetails" >> "storage_domain" : StorageDomain, >> "topology" : = >> CpuTopology, >> "creation_status" : Status, # >> key has a more word "creation" than the value. >> "parent" : = >> TagParent > > > --===============5855405616202219808==-- From mpastern at redhat.com Sun Jun 10 02:42:40 2012 Content-Type: multipart/mixed; boundary="===============5202163649602412023==" MIME-Version: 1.0 From: Michael Pasternak To: devel at ovirt.org Subject: Re: [Engine-devel] [ovirt-engine-sdk] some questions about the params.py code generated by generateSD Date: Sun, 10 Jun 2012 09:49:52 +0300 Message-ID: <4FD44390.7030209@redhat.com> In-Reply-To: 4FD0C538.1080001@linux.vnet.ibm.com --===============5202163649602412023== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi, On 06/07/2012 06:14 PM, ShaoHe Feng wrote: > Hi all, > = > as we all know the current params.py was not completely by the generateSD= .py, there are parts that have to be updated manually. > = > now I have post a primarypatch to improve it. http://gerrit.ovirt.org/#/c= /4880/ > = (in review) > it can generate some codes, but still two parts codes can not be generate= d. > = > they aretwo dictionaries: _rootClassMap and _elementToClassMap. > = > However, for I do get any clue to know these two dictionaries from the p= arams.py. > = > there are some questions: > 1. > And the __all__ list which include all the classes of _rootClassMap and = _elementToClassMap. > And there some classes both in _rootClassMap and _elementToClassMap. > = > 2. > And some of class in _rootClassMap inherit GeneratedsSuper class, some i= nherit BaseResource class, and two classes inherit Link class. > And it is the same with _elementToClassMap. > = > so what is the difference between _rootClassMap and _elementToClassMap. > What rule to generate these two dictionaries. _elementToClassMap no longer relevant, you can place everything in _rootCla= ssMap > = > 3. > And also, how to generate the keys in _rootClassMap and _elementToClassMa= p.Any rule to generate them? you can traverse all elements in the schema creating data structure where k= ey is the type of the schema element and value is the element name, for instance: _element_type_to_name_map {SpecialObjects, special_objects}, this way later when you go over items in __all__ [1] list, you can use each= item as key at _element_type_to_name_map to retrieve element name=3D"special_objects". [1] __all__ =3D [..., "SpecialObjects", ...] > = > there are some items in these two dictionaries > = > "access_control_list" : AccessControlList= , # "_" among the word in key > "api" : API, = = > "body" : Body, > "iscsi" : IscsiDet= ails, # key "iscsi" is one part of value "IscsiDetails" > "storage_domain" : StorageDomain, > "topology" : CpuTopology,= = > "creation_status" : Status, = # key has a more word "creation" than the value. > "parent" : TagParent > = > = > = > = > = > = > = > = > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel -- = Michael Pasternak RedHat, ENG-Virtualization R&D --===============5202163649602412023==-- From mpastern at redhat.com Sun Jun 10 02:49:49 2012 Content-Type: multipart/mixed; boundary="===============0006829354180428363==" MIME-Version: 1.0 From: Michael Pasternak To: devel at ovirt.org Subject: Re: [Engine-devel] [ovirt-engine-sdk] some questions about the params.py code generated by generateSD Date: Sun, 10 Jun 2012 09:57:02 +0300 Message-ID: <4FD4453E.1030107@redhat.com> In-Reply-To: 4FD236AD.1090200@linux.vnet.ibm.com --===============0006829354180428363== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable On 06/08/2012 08:30 PM, ShaoHe Feng wrote: > still a question. > = > I find there are reduplicate items in _rootClassMap dictionary of ./src= /ovirtsdk/xml/params.py file. > such as: > 1. > in line 18924 > "storage" : Storage, > in line 18931 > "storage" : Storage, > above items has same key and value. > = > 2. > in line 18905 > "product_info" : ProductInfo, > in line 18934 > "product_info" : ProductInfo, > above items has same key and value. > = > 3. > in line 18953 > "vm_pause_details" : VmPauseDetails, > in line 18962 > "vm_pause_detail" : VmPauseDetails, > = > above items has value but different key. > = > is it OK ? or should I commit a patch to fix it? should be single appearance of each element (it was handcrafted). -- = Michael Pasternak RedHat, ENG-Virtualization R&D --===============0006829354180428363==--