December 2012 - Devel - oVirt List Archives

[Engine-devel] Managing async tasks
by Adam Litke 18 Dec '12

18 Dec '12

On today's vdsm call we had a lively discussion around how asynchronous operations should be handled in the future. In an effort to include more people in the discussion and to better capture the resulting conversation I would like to continue that discussion here on the mailing list. A lot of ideas were thrown around about how 'tasks' should be handled in the future. There are a lot of ways that it can be done. To determine how we should implement it, it's probably best if we start with a set of requirements. If we can first agree on these, it should be easy to find a solution that meets them. I'll take a stab at identifying a first set of POSSIBLE requirements: - Standardized method for determining the result of an operation This is a big one for me because it directly affects the consumability of the API. If each verb has different semantics for discovering whether it has completed successfully, then the API will be nearly impossible to use easily. Sorry. That's my list :) Hopefully others will be willing to add other requirements for consideration. >From my understanding, task recovery (stop, abort, rollback, etc) will not be generally supported and should not be a requirement. -- Adam Litke <agl(a)us.ibm.com> IBM Linux Technology Center

3 7

Re: [Engine-devel] [vdsm] Host bios information
by Barak Azulay 16 Dec '12

16 Dec '12

----- Original Message ----- > From: "Ayal Baron" <abaron(a)redhat.com> > To: "Saggi Mizrahi" <smizrahi(a)redhat.com> > Cc: "VDSM Project Development" <vdsm-devel(a)lists.fedorahosted.org> > Sent: Friday, December 14, 2012 2:07:04 AM > Subject: Re: [vdsm] Host bios information > > > > ----- Original Message ----- > > > > > > ----- Original Message ----- > > > From: "Ayal Baron" <abaron(a)redhat.com> > > > To: "Saggi Mizrahi" <smizrahi(a)redhat.com> > > > Cc: "VDSM Project Development" > > > <vdsm-devel(a)lists.fedorahosted.org>, > > > "Shu Ming" <shuming(a)linux.vnet.ibm.com> > > > Sent: Thursday, December 13, 2012 11:30:56 AM > > > Subject: Re: [vdsm] Host bios information > > > > > > > > > > > > ----- Original Message ----- > > > > I think that for the new current XML-RPC API it's OK to add it > > > > to > > > > the > > > > getVdsCaps() verb. > > > > For the new API I suggest moving it to it's own API. The > > > > smaller > > > > the > > > > APIs the easier they are to deprecate and support. > > > > I quite doubt the fields in getBiosInfo() will change half as > > > > frequently as whatever getVdsCaps() returns. > > > > I also kind of want to throw away getVdsCaps() and split it to > > > > better > > > > named better encapsulated methods. > > > > > > Ack. I just don't understand why not start right now? > > > Any new patch should improve things at least a little. > > > We know getVdsCaps() is wrong so let's put the bios info (and > > > anything in getVdsCaps that makes sense to put with it if > > > relevant) > > > in a separate call. Adding a call in engine to this new method > > > should be a no brainer, I don't think that is a good reason for > > > not > > > doing things properly in vdsm, even if we're talking about the > > > current API. > > Well, from what I know the current overhead per call is too large > > to > > mandate a lot of calls. > > At least that is what I've been told. If that is not an issue, do > > it > > in the XML-RPC API too. > > if you call it every 2 seconds to each host then perhaps, but > getVdsCaps is called in initvdsonup which is pretty rare (hours, > days or more) so avoiding an extra call there seems wrong to me. I totally agree that in the long run it is correct to add a different API on vdsm, However for the initial 6 bios params: 1. Host Manufacturer - Manufacturer of the host's machine and bios' vendor (e.g LENOVO) 2. Host Version - For each host the manufacturer gives a unique name (e.g. Lenovo T420s) 3. Host Product Name - ID of the product - same for all similar products (e.g 4174BH4) 4. Host UUID - Unique ID for each host (e.g E03DD601-5219-11CB-BB3F-892313086897) 5. Host Family - Type of host's CPU - (e.g Core i5) 6. Host Serial Number - Unique ID for host's chassis (e.g R9M4N4G) As Dan stated below, is o.k. for this specific phase to add them to getVdsCaps So I suggest: 1 Adding the above 6 above params to getVdsCaps 2 Add a new API to vdsm to retrieve host bios information - that will eventually return the entire list (current will retrieve the exact 6 params and will use the same underlying implementation) 3 In the future engine will start using the new API Start using the new API now on the engine side will require much more testing as it might have an influence on the host state machine. Thanks Barak Azulay > > > > > > > > > > > > Also, in the json-rpc base model, calls are not only cheaper, > > > > you > > > > also have batch calls. This means you can send multiple > > > > requests > > > > as > > > > one message and have VDSM send you the responses as one message > > > > once > > > > all tasks completed. This makes splitting aggregated methods to > > > > smaller methods painless and with minimal overhead. > > > > > > > > ----- Original Message ----- > > > > > From: "Shu Ming" <shuming(a)linux.vnet.ibm.com> > > > > > To: "ybronhei" <ybronhei(a)redhat.com> > > > > > Cc: "VDSM Project Development" > > > > > <vdsm-devel(a)lists.fedorahosted.org> > > > > > Sent: Thursday, December 13, 2012 11:04:09 AM > > > > > Subject: Re: [vdsm] Host bios information > > > > > > > > > > After a quick review of the wiki page, it was stated that > > > > > dmidecode > > > > > gave > > > > > too much informations. Only five fields will be displayed in > > > > > the > > > > > hardware tab, "Manufactory", "Version", "Family", "UUID" and > > > > > "serial > > > > > number". For "Family", it is mean the CPU core's family. > > > > > And > > > > > it > > > > > confuses me a bit with the "CPU name" and "CPU type" fields > > > > > in > > > > > general > > > > > tab. I think we should chose the best one to characterizethe > > > > > CPU > > > > > type. > > > > > > > > > > > > > > > ybronhei: > > > > > > Today in the Api we display general information about the > > > > > > host > > > > > > that > > > > > > vdsm export by getCapabilities Api. > > > > > > > > > > > > We decided to add bios information as part of the > > > > > > information > > > > > > that > > > > > > is > > > > > > displayed in UI under host's general sub-tab. > > > > > > > > > > > > To summaries the feature - We'll modify General tab to > > > > > > Software > > > > > > Information and add another tab for Hardware Information > > > > > > which > > > > > > will > > > > > > include all the bios data that we'll decide to gather from > > > > > > the > > > > > > host > > > > > > and display. > > > > > > > > > > > > Following this feature page: > > > > > > http://www.ovirt.org/Features/Design/HostBiosInfo for more > > > > > > details. > > > > > > All the parameters that can be displayed are mentioned in > > > > > > the > > > > > > wiki. > > > > > > > > > > > > I would greatly appreciate your comments and questions. > > > > > > > > > > > > Thanks. > > > > > > > > > > > > > > > > > > > > > -- > > > > > --- > > > > > 舒明 Shu Ming > > > > > Open Virtualization Engineerning; CSTL, IBM Corp. > > > > > Tel: 86-10-82451626 Tieline: 9051626 E-mail: > > > > > shuming(a)cn.ibm.com > > > > > or > > > > > shuming(a)linux.vnet.ibm.com > > > > > Address: 3/F Ring Building, ZhongGuanCun Software Park, > > > > > Haidian > > > > > District, Beijing 100193, PRC > > > > > > > > > > > > > > > _______________________________________________ > > > > > vdsm-devel mailing list > > > > > vdsm-devel(a)lists.fedorahosted.org > > > > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > > > > > > > _______________________________________________ > > > > vdsm-devel mailing list > > > > vdsm-devel(a)lists.fedorahosted.org > > > > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel > > > > > > > > > > _______________________________________________ > vdsm-devel mailing list > vdsm-devel(a)lists.fedorahosted.org > https://lists.fedorahosted.org/mailman/listinfo/vdsm-devel >

3 2

[Engine-devel] VDSM tasks, the future
by Saggi Mizrahi 16 Dec '12

16 Dec '12

Because I started hinting about how VDSM tasks are going to look going forward I thought it's better I'll just write everything in an email so we can talk about it in context. This is not set in stone and I'm still debating things myself but it's very close to being done. - Everything is asynchronous. The nature of message based communication is that you can't have synchronous operations. This is not really debatable because it's just how TCP\AMQP\<messaging> works. - Task IDs will be decided by the caller. This is how json-rpc works and also makes sense because no the engine can track the task without needing to have a stage where we give it the task ID back. IDs are reusable as long as no one else is using them at the time so they can be used for synchronizing operations between clients (making sure a command is only executed once on a specific host without locking). - Tasks are transient If VDSM restarts it forgets all the task information. There are 2 ways to have persistent tasks: 1. The task creates an object that you can continue work on in VDSM. The new storage does that by the fact that copyImage() returns one the target volume has been created but before the data has been fully copied. From that moment on the stat of the copy can be queried from any host using getImageStatus() and the specific copy operation can be queried with getTaskStatus() on the host performing it. After VDSM crashes, depending on policy, either VDSM will create a new task to continue the copy or someone else will send a command to continue the operation and that will be a new task. 2. VDSM tasks just start other operations track-able not through the task interface. For example Gluster. gluster.startVolumeRebalance() will return once it has been registered with Gluster. glster.getOperationStatuses() will return the state of the operation from any host. Each call is a task in itself. - No task tags. They are silly and the caller can mangle whatever in the task ID if he really wants to tag tasks. - No explicit recovery stage. VDSM will be crash-only, there should be efforts to make everything crash-safe. If that is problematic, in case of networking, VDSM will recover on start without having a task for it. - No clean Task: Tasks can be started by any number of hosts this means that there is no way to own all tasks. There could be cases where VDSM starts tasks on it's own and thus they have no owner at all. The caller needs to continually track the state of VDSM. We will have brodcasted events to mitigate polling. - No revert Impossible to implement safely. - No SPM\HSM tasks SPM\SDM is no longer necessary for all domain types (only for type). What used to be SPM tasks, or tasks that persist and can be restarted on other hosts is talked about in previous bullet points.

4 5

[Engine-devel] Creating New Data-Center and Permission on Network
by Moti Asayag 16 Dec '12

16 Dec '12

Hi, When creating a new data-center, a management network is created for it. By default the created management network is defined as VM network. I'd like to consult from permissions perspective, what is the preferred permission settings for that network. The network is defined as management network, therefore it is designed be used by VMs. However, the admin should grant permissions on that networks to the target users (which one might find tedious). We can grant permission on that network to 'everyone' with role 'NetworkUser', but in case the admin doesn't meant this network to be used, the permission should be removed. In 'Add Logical Network' dialog I've added a new checkbox to allow granting 'everyone' a role for using that network ('NetworkUser'). We can embrace same method in 'Add Data-Center' dialog. Thoughts ? Thanks, Moti

2 1

[Engine-devel] ThreadPoolUtil with 500 threads and no queue?
by Juan Hernandez 16 Dec '12

16 Dec '12

Hello all, What is the reasoning behind the decision to have a pool with a maximum of 500 threads and no job queue (see ThreadPoolUtil.java)? Wouldn't it make more sense to have a much smaller thread pool and a potentially large queue of jobs? Regards, Juan Hernandez -- Dirección Comercial: C/Jose Bardasano Baos, 9, Edif. Gorbea 3, planta 3ºD, 28016 Madrid, Spain Inscrita en el Reg. Mercantil de Madrid – C.I.F. B82657941 - Red Hat S.L.

3 4

[Engine-devel] Design review summary for 3.2 - adding support for External Events
by Eli Mesika 16 Dec '12

16 Dec '12

Discussion : http://wiki.ovirt.org/wiki/Talk:ExternalEvents Updated Design : http://wiki.ovirt.org/wiki/Features/Design/DetailedExternalEvents#Future_di…

5 16

[Engine-devel] UI plugins - next steps
by Vojtech Szocs 13 Dec '12

13 Dec '12

Hi guys, here's my list of tasks that didn't make it into UI plugins yet. These tasks should be revisited and implemented in future patches. The list isn't sorted in any way, so feel free to comment or highlight specific tasks to raise their priority, or add your own tasks/ideas. 1. Pass proper (restapi-definition) entities to UI plugins, instead of simple "{entityId:<guidAsString>}" objects - using restapi-types mappers to map backend business entities to restapi-definition entities (Java POJOs generated from api.xsd via JAXB) - exporting restapi-definition entities for use with JavaScript (UI plugins), e.g. using gwt-exporter [1] (alternatively, we could use GWT deferred binding and do this ourselves) 2. showDialog API function should integrate with WebAdmin dialog infrastructure - shouldn't be too hard, need to create custom dialog PresenterWidget/View and bind it as non-singleton (just like other popups in oVirt GUI) 3. Extend existing WebAdmin dialogs - prototype Doron's proposal to extend Edit Cluster Policy dialog with custom options that would be passed to backend 4. Introduce form-based tabs - custom tab that would display key/value pairs organized in columns, just like in standard "General" sub tabs 5. Introduce table-based tabs - custom tab that would display grid (table) just like in standard main tabs, with API to add columns, set data, etc. 6. Improve api.addMainTabActionButton to allow different button vs. context menu item representations (only button, only menu item, both) 7. Add api.currentUserName and api.currentUserId API functions (these would return same data as with UserLogin event parameters) 8. Minor things: consider renaming UiInit to PluginInit (one-time plugin initialization, called only once, can do non-UI init stuff there as well), consider renaming api.ready to api.initialize (plugin indicates that infrastructure can proceed with initializing itself) Regards, Vojtech [1] http://code.google.com/p/gwt-exporter/wiki/GettingStarted

3 5

[Engine-devel] Adding Authentication mechanism to oVirt
by Alon Bar-Lev 13 Dec '12

13 Dec '12

------=_Part_4736650_2080278089.1355331209999 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Hello Thierry, If I understand correctly you wish to help in modifying the engine to support non GSSAPI authentication methods. Following is a quick design goals for this implementation. I will be glad to improve this. Alon --- Implementation should support the following transports: 1. LDAP (plain). 2. LDAP over TLS. 3. LDAP with StartTLS. Implementation should support the following authentication methods: 1. Simple. 2. Digest-MD5 (plain and strong). I believe the GSSAPI can be dropped, I see no advantage of using it. A sample of low level implementation for transport and authentication is attached. When adding a domain the following facts should be provided: 1. Search user name. 2. Search user password. 3. Transport type (ldap, ldaps, ldap+startTLS) 4. Authentication (simple, Digest-MD5) 5. Sever selection policy (failover, round-robin, random). 6. Server address type (explicit, DNS record) 7. Server address set. 8. Optional base DN. 9. Optional root certificate. 10. Optional certificate chain. 11. Search page size. 10. Query timeout. etc... Within product there are two separate components that perform LDAP authentication: 1. User password validation. 2. User permission fetch. These two components needs to work in share-nothing mode, meaning that each should communicate with directory independently with the other. USER PASSWORD VALIDATION Input: user Input: domain Input: password Output: DN of user Output: success/failure Credentials used: user/password provided. Notes: LDAP session should not be cached. Logic: Perform LDAP bind. USER PERMISSION FETCH Input: DN of user (passed by user password validation) Input: domain (passed by user password validation) Output: A set of permissions Credentials used: search user and password configured within system. Notes: LDAP context can be cached. Logic: Perform LDAP searches, this is most of current logic. ------=_Part_4736650_2080278089.1355331209999 Content-Type: text/x-java; name=LDAPSearch.java Content-Disposition: attachment; filename=LDAPSearch.java Content-Transfer-Encoding: base64 Lyo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PQoKTGljZW5zZWQgdG8gdGhlIEFwYWNoZSBTb2Z0d2FyZSBGb3VuZGF0aW9u IChBU0YpIHVuZGVyIG9uZSBvciBtb3JlCmNvbnRyaWJ1dG9yIGxpY2Vuc2UgYWdyZWVtZW50cy4g IFNlZSB0aGUgTk9USUNFIGZpbGUgZGlzdHJpYnV0ZWQgd2l0aAp0aGlzIHdvcmsgZm9yIGFkZGl0 aW9uYWwgaW5mb3JtYXRpb24gcmVnYXJkaW5nIGNvcHlyaWdodCBvd25lcnNoaXAuClRoZSBBU0Yg bGljZW5zZXMgdGhpcyBmaWxlIHRvIFlvdSB1bmRlciB0aGUgQXBhY2hlIExpY2Vuc2UsIFZlcnNp b24gMi4wCih0aGUgIkxpY2Vuc2UiKTsgeW91IG1heSBub3QgdXNlIHRoaXMgZmlsZSBleGNlcHQg aW4gY29tcGxpYW5jZSB3aXRoCnRoZSBMaWNlbnNlLiAgWW91IG1heSBvYnRhaW4gYSBjb3B5IG9m IHRoZSBMaWNlbnNlIGF0CgogICAgaHR0cDovL3d3dy5hcGFjaGUub3JnL2xpY2Vuc2VzL0xJQ0VO U0UtMi4wCgpVbmxlc3MgcmVxdWlyZWQgYnkgYXBwbGljYWJsZSBsYXcgb3IgYWdyZWVkIHRvIGlu IHdyaXRpbmcsIHNvZnR3YXJlCmRpc3RyaWJ1dGVkIHVuZGVyIHRoZSBMaWNlbnNlIGlzIGRpc3Ry aWJ1dGVkIG9uIGFuICJBUyBJUyIgQkFTSVMsCldJVEhPVVQgV0FSUkFOVElFUyBPUiBDT05ESVRJ T05TIE9GIEFOWSBLSU5ELCBlaXRoZXIgZXhwcmVzcyBvciBpbXBsaWVkLgpTZWUgdGhlIExpY2Vu c2UgZm9yIHRoZSBzcGVjaWZpYyBsYW5ndWFnZSBnb3Zlcm5pbmcgcGVybWlzc2lvbnMgYW5kCmxp bWl0YXRpb25zIHVuZGVyIHRoZSBMaWNlbnNlLgo9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PSovCgppbXBvcnQgamF2YS5p by4qOwppbXBvcnQgamF2YS5uZXQuKjsKaW1wb3J0IGphdmEudXRpbC4qOwppbXBvcnQgamF2YS5z ZWN1cml0eS5jZXJ0Lio7CgppbXBvcnQgamF2YXgubmFtaW5nLio7CmltcG9ydCBqYXZheC5uYW1p bmcuZGlyZWN0b3J5Lio7CmltcG9ydCBqYXZheC5uYW1pbmcubGRhcC4qOwppbXBvcnQgamF2YXgu bmV0Lio7CmltcG9ydCBqYXZheC5uZXQuc3NsLio7CgpwdWJsaWMgY2xhc3MgTERBUFNlYXJjaCB7 Cglwcml2YXRlIGJvb2xlYW4gX2RvU3RhcnRUTFMgPSBmYWxzZTsKCXByaXZhdGUgYm9vbGVhbiBf ZG9TQVNMX2RpZ2VzdE1ENSA9IGZhbHNlOwoJcHJpdmF0ZSBib29sZWFuIF9kb1NBU0xfc3Ryb25n ID0gZmFsc2U7Cglwcml2YXRlIGJvb2xlYW4gX3ZlcmlmeVBlZXJDZXJ0aWZpY2F0ZSA9IHRydWU7 Cglwcml2YXRlIFN0cmluZyBfc2VjdXJpdHlQcm90b2NvbCA9ICJUTFN2MSI7Cglwcml2YXRlIFN0 cmluZyBfdXNlcjsKCXByaXZhdGUgU3RyaW5nIF9wYXNzd29yZDsKCXByaXZhdGUgaW50IF9zZWFy Y2hQYWdlU2l6ZTsKCglMZGFwQ29udGV4dCBfY3R4OwoJU3RhcnRUbHNSZXNwb25zZSBfdGxzOwoJ U3RyaW5nIF9uYW1lQ29udGV4dCA9ICIiOwoKCXB1YmxpYyBzdGF0aWMgaW50ZXJmYWNlIFJlc3Vs dEhhbmRsZXIgewoJCXB1YmxpYyBib29sZWFuIGhhbmRsZShOYW1pbmdFbnVtZXJhdGlvbjxTZWFy Y2hSZXN1bHQ+IHJlc3VsdHMpIHRocm93cyBOYW1pbmdFeGNlcHRpb247Cgl9CgoJcHVibGljIHZv aWQgdXNlU3RhcnRUTFMoYm9vbGVhbiBzdGFydFRMUykgewoJCV9kb1N0YXJ0VExTID0gc3RhcnRU TFM7Cgl9CgoJcHVibGljIHZvaWQgdXNlRGlnZXN0TUQ1KGJvb2xlYW4gc3Ryb25nKSB7CgkJX2Rv U0FTTF9kaWdlc3RNRDUgPSB0cnVlOwoJCV9kb1NBU0xfc3Ryb25nID0gc3Ryb25nOwoJfQoKCXB1 YmxpYyB2b2lkIHNldFNlY3VyaXR5UHJvdG9jb2woU3RyaW5nIHNlY3VyaXR5UHJvdG9jb2wpIHsK CQlfc2VjdXJpdHlQcm90b2NvbCA9IHNlY3VyaXR5UHJvdG9jb2w7Cgl9CgoJcHVibGljIHZvaWQg c2V0Q3JlZGVudGlhbHMoU3RyaW5nIHVzZXIsIFN0cmluZyBwYXNzd29yZCkgewoJCV91c2VyID0g dXNlcjsKCQlfcGFzc3dvcmQgPSBwYXNzd29yZDsKCX0KCQoJcHVibGljIHZvaWQgc2V0U2VhcmNo UGFnZVNpemUoaW50IHNlYXJjaFBhZ2VTaXplKSB7CgkJX3NlYXJjaFBhZ2VTaXplID0gc2VhcmNo UGFnZVNpemU7Cgl9CgoJcHVibGljIHZvaWQgc2V0VmVyaWZ5UGVlckNlcnRpZmljYXRlKGJvb2xl YW4gdmVyaWZ5KSB7CgkJX3ZlcmlmeVBlZXJDZXJ0aWZpY2F0ZSA9IHZlcmlmeTsKCX0KCglwdWJs aWMgdm9pZCBjcmVhdGVDb250ZXh0KFN0cmluZyB1cmwpIAoJdGhyb3dzIE5hbWluZ0V4Y2VwdGlv biwgSU9FeGNlcHRpb24gewoJCWJvb2xlYW4gZG9UTFMgPSB1cmwuc3RhcnRzV2l0aCgibGRhcHM6 Iik7CgoJCUhhc2h0YWJsZTxTdHJpbmcsIFN0cmluZz4gZW52ID0gbmV3IEhhc2h0YWJsZTxTdHJp bmcsIFN0cmluZz4oKTsKCQllbnYucHV0KENvbnRleHQuSU5JVElBTF9DT05URVhUX0ZBQ1RPUlks ICJjb20uc3VuLmpuZGkubGRhcC5MZGFwQ3R4RmFjdG9yeSIpOwoJCWVudi5wdXQoQ29udGV4dC5Q Uk9WSURFUl9VUkwsIHVybCk7CgoJCWlmIChkb1RMUykgewoJCQllbnYucHV0KENvbnRleHQuU0VD VVJJVFlfUFJPVE9DT0wsIF9zZWN1cml0eVByb3RvY29sKTsKCgkJCWlmICghX3ZlcmlmeVBlZXJD ZXJ0aWZpY2F0ZSkgewoJCQkJVW5zZWN1cmVTU0xTb2NrZXRGYWN0b3J5LnNldERlZmF1bHRQcm90 b2NvbChfc2VjdXJpdHlQcm90b2NvbCk7CgkJCQllbnYucHV0KCJqYXZhLm5hbWluZy5sZGFwLmZh Y3Rvcnkuc29ja2V0IiwgVW5zZWN1cmVTU0xTb2NrZXRGYWN0b3J5LmNsYXNzLmdldE5hbWUoKSk7 CgkJCX0KCQl9CgoJCV9jdHggPSBuZXcgSW5pdGlhbExkYXBDb250ZXh0KGVudiwgbnVsbCk7CgoJ CWlmICghZG9UTFMgJiYgX2RvU3RhcnRUTFMpIHsKCQkJX3RscyA9IChTdGFydFRsc1Jlc3BvbnNl KV9jdHguZXh0ZW5kZWRPcGVyYXRpb24oCgkJCQluZXcgU3RhcnRUbHNSZXF1ZXN0KCkKCQkJKTsK CQkJU1NMU2Vzc2lvbiBzZXNzaW9uID0gX3Rscy5uZWdvdGlhdGUoCgkJCQlfdmVyaWZ5UGVlckNl cnRpZmljYXRlID8KCQkJCShTU0xTb2NrZXRGYWN0b3J5KVNTTFNvY2tldEZhY3RvcnkuZ2V0RGVm YXVsdCgpIDogCgkJCQlVbnNlY3VyZVNTTFNvY2tldEZhY3RvcnkuY3JlYXRlU29ja2V0RmFjdG9y eShfc2VjdXJpdHlQcm90b2NvbCkKCQkJKTsKCQl9CgoJCWlmIChfdXNlciAhPSBudWxsKSB7CgkJ CWlmIChfZG9TQVNMX2RpZ2VzdE1ENSkgewoJCQkJX2N0eC5hZGRUb0Vudmlyb25tZW50KENvbnRl eHQuU0VDVVJJVFlfQVVUSEVOVElDQVRJT04sICJESUdFU1QtTUQ1Iik7CgkJCQlpZiAoX2RvU0FT TF9zdHJvbmcpIHsKCQkJCQlfY3R4LmFkZFRvRW52aXJvbm1lbnQoImphdmF4LnNlY3VyaXR5LnNh c2wucW9wIiwgImF1dGgtY29uZiIpOwoJCQkJCV9jdHguYWRkVG9FbnZpcm9ubWVudCgiamF2YXgu c2VjdXJpdHkuc2FzbC5zdHJlbmd0aCIsICJoaWdoIik7CgkJCQl9CgkJCX0KCQkJZWxzZSB7CgkJ CQlfY3R4LmFkZFRvRW52aXJvbm1lbnQoQ29udGV4dC5TRUNVUklUWV9BVVRIRU5USUNBVElPTiwg InNpbXBsZSIpOwoJCQl9CgkJCV9jdHguYWRkVG9FbnZpcm9ubWVudChDb250ZXh0LlNFQ1VSSVRZ X1BSSU5DSVBBTCwgX3VzZXIpOwoJCQlfY3R4LmFkZFRvRW52aXJvbm1lbnQoQ29udGV4dC5TRUNV UklUWV9DUkVERU5USUFMUywgX3Bhc3N3b3JkKTsKCQl9CgoJCS8qCgkJICogbm8gbmFtZXNwYWNl LCBsZXQncyB0YWtlIHRoZSBmaXJzdCBuYW1lIHNwYWNlCgkJICogYXZhaWxhYmxlLgoJCSAqLwoJ CWlmIChfY3R4LmdldE5hbWVJbk5hbWVzcGFjZSgpLmVxdWFscygiIikpIHsKCQkJU3RyaW5nIGNv bnRleHRzW10gPSB7CgkJCQkibmFtaW5nQ29udGV4dHMiLCAvLyBzdGFuZGFyZAoJCQkJImRlZmF1 bHROYW1pbmdDb250ZXh0IiAvLyBhY3RpdmUgZGlyZWN0b3J5CgkJCX07CgkJCUF0dHJpYnV0ZXMg YXR0cmlidXRlcyA9IF9jdHguZ2V0QXR0cmlidXRlcygKCQkJCSIiLAoJCQkJY29udGV4dHMKCQkJ KTsKCQkJZm9yIChTdHJpbmcgY29udGV4dCA6IGNvbnRleHRzKSB7CgkJCQlBdHRyaWJ1dGUgYXR0 cmlidXRlID0gYXR0cmlidXRlcy5nZXQoY29udGV4dCk7CgkJCQlpZiAoYXR0cmlidXRlICE9IG51 bGwpIHsKCQkJCQlfbmFtZUNvbnRleHQgPSBhdHRyaWJ1dGUuZ2V0KCkudG9TdHJpbmcoKTsKCQkJ CQlicmVhazsKCQkJCX0KCQkJfQoJCX0KCX0KCglwdWJsaWMgdm9pZCBkZXN0b3J5Q29udGV4dCgp Cgl0aHJvd3MgTmFtaW5nRXhjZXB0aW9uLCBJT0V4Y2VwdGlvbiB7CgkJaWYgKF90bHMgIT0gbnVs bCkgewoJCQlfdGxzLmNsb3NlKCk7CgkJfQoJCWlmIChfY3R4ICE9IG51bGwpIHsKCQkJX2N0eC5j bG9zZSgpOwoJCX0KCX0KCglwdWJsaWMgdm9pZCBzZWFyY2goCgkJUmVzdWx0SGFuZGxlciBoYW5k bGVyLAoJCVN0cmluZyBxdWVyeSwKCQlTdHJpbmdbXSBhdHRyaWJ1dGVzLAoJCWludCBzY29wZSwK CQlpbnQgdGltZUxpbWl0CgkpIHRocm93cyBOYW1pbmdFeGNlcHRpb24sIElPRXhjZXB0aW9uIHsK CQkvKgoJCSAqIFBhZ2Ugc2VhcmNoLgoJCSAqLwoJCWJ5dGVbXSBjb29raWUgPSBudWxsOwoJCWJv b2xlYW4gY29udCA9IHRydWU7CgkJU2VhcmNoQ29udHJvbHMgc2VhcmNoQ29udHJvbHMgPSBuZXcg U2VhcmNoQ29udHJvbHMoKTsKCQlzZWFyY2hDb250cm9scy5zZXRTZWFyY2hTY29wZShzY29wZSk7 CgkJc2VhcmNoQ29udHJvbHMuc2V0VGltZUxpbWl0KHRpbWVMaW1pdCk7CgkJc2VhcmNoQ29udHJv bHMuc2V0UmV0dXJuaW5nQXR0cmlidXRlcyhhdHRyaWJ1dGVzKTsKCQlkbyB7CgkJCV9jdHguc2V0 UmVxdWVzdENvbnRyb2xzKAoJCQkJbmV3IENvbnRyb2xbXXsgCgkJCQkJbmV3IFBhZ2VkUmVzdWx0 c0NvbnRyb2woCgkJCQkJCV9zZWFyY2hQYWdlU2l6ZSwKCQkJCQkJY29va2llLAoJCQkJCQlDb250 cm9sLkNSSVRJQ0FMCgkJCQkJKQoJCQkJfQoJCQkpOwoJCQljb29raWUgPSBudWxsOwoKCQkJTmFt aW5nRW51bWVyYXRpb248U2VhcmNoUmVzdWx0PiByZXN1bHRzID0gbnVsbDsKCQkJdHJ5IHsKCQkJ CXJlc3VsdHMgPSBfY3R4LnNlYXJjaCgKCQkJCQlfbmFtZUNvbnRleHQsCgkJCQkJcXVlcnksCgkJ CQkJc2VhcmNoQ29udHJvbHMKCQkJCSk7CgkJCQljb250ID0gaGFuZGxlci5oYW5kbGUocmVzdWx0 cyk7CgkJCX0KCQkJY2F0Y2goUGFydGlhbFJlc3VsdEV4Y2VwdGlvbiBlKSB7fQoJCQlmaW5hbGx5 IHsKCQkJCWlmIChyZXN1bHRzICE9IG51bGwpIHsKCQkJCQlyZXN1bHRzLmNsb3NlKCk7CgkJCQkJ cmVzdWx0cyA9IG51bGw7CgkJCQl9CgkJCX0KCgkJCS8qCgkJCSAqIE5leHQgcGFnZQoJCQkgKi8K CQkJaWYgKGNvbnQgJiYgX2N0eC5nZXRSZXNwb25zZUNvbnRyb2xzKCkgIT0gbnVsbCkgewoJCQkJ Zm9yIChDb250cm9sIGNvbnRyb2wgOiBfY3R4LmdldFJlc3BvbnNlQ29udHJvbHMoKSkgewoJCQkJ CWlmIChjb250cm9sIGluc3RhbmNlb2YgUGFnZWRSZXN1bHRzUmVzcG9uc2VDb250cm9sKSB7CgkJ CQkJCWNvb2tpZSA9ICgoUGFnZWRSZXN1bHRzUmVzcG9uc2VDb250cm9sKWNvbnRyb2wpLmdldENv b2tpZSgpOwoJCQkJCX0KCQkJCX0KCQkJfQoJCX0gd2hpbGUoY29udCAmJiBjb29raWUgIT0gbnVs bCk7Cgl9CgoJcHVibGljIHN0YXRpYyBjbGFzcyBEdW1wUmVzdWx0SGFuZGxlciBpbXBsZW1lbnRz IFJlc3VsdEhhbmRsZXIgewoJCXByaXZhdGUgUHJpbnRTdHJlYW0gX29zOwoKCQlwdWJsaWMgRHVt cFJlc3VsdEhhbmRsZXIoT3V0cHV0U3RyZWFtIG9zKSB7CgkJCV9vcyA9IG5ldyBQcmludFN0cmVh bShvcyk7CgkJfQoKCQlwdWJsaWMgYm9vbGVhbiBoYW5kbGUoTmFtaW5nRW51bWVyYXRpb248U2Vh cmNoUmVzdWx0PiByZXN1bHRzKSB0aHJvd3MgTmFtaW5nRXhjZXB0aW9uIHsKCQkJLyoKCQkJICog RHVtcCBwYWdlIHJlc3VsdHMKCQkJICovCgkJCXdoaWxlIChyZXN1bHRzICE9IG51bGwgJiYgcmVz dWx0cy5oYXNNb3JlKCkpIHsKCQkJCVNlYXJjaFJlc3VsdCByZXN1bHQgPSByZXN1bHRzLm5leHQo KTsKCgkJCQlfb3MucHJpbnRsbigpOwoJCQkJX29zLnByaW50bG4ocmVzdWx0LmdldE5hbWVJbk5h bWVzcGFjZSgpKTsKCgkJCQlOYW1pbmdFbnVtZXJhdGlvbjw/IGV4dGVuZHMgQXR0cmlidXRlPiBl YXR0cnMgPSByZXN1bHQuZ2V0QXR0cmlidXRlcygpLmdldEFsbCgpOwoJCQkJd2hpbGUoZWF0dHJz Lmhhc01vcmUoKSkgewoJCQkJCUF0dHJpYnV0ZSBhdHRyID0gZWF0dHJzLm5leHQoKTsKCQkJCQlO YW1pbmdFbnVtZXJhdGlvbjw/PiBlYXR0ciA9IGF0dHIuZ2V0QWxsKCk7CgkJCQkJd2hpbGUoZWF0 dHIuaGFzTW9yZSgpKSB7CgkJCQkJCU9iamVjdCBvID0gZWF0dHIubmV4dCgpOwoJCQkJCQlfb3Mu cHJpbnRsbigKCQkJCQkJCVN0cmluZy5mb3JtYXQoCgkJCQkJCQkJIiUxJHM6JTIkcyIsCgkJCQkJ CQkJYXR0ci5nZXRJRCgpLAoJCQkJCQkJCW8gPT0gbnVsbCA/ICIobnVsbCkiIDogby50b1N0cmlu ZygpCgkJCQkJCQkpCgkJCQkJCSk7CgkJCQkJfQoJCQkJfQoJCQl9IAoJCQlyZXR1cm4gdHJ1ZTsK CQl9Cgl9CgoJLyoKCSAqIGxkYXA6Ly9xYTEucWEubGFiLnRsdi5yZWRoYXQuY29tIGFsb25ibCAx MjM0NTYKCSAqIAlzdXBwb3J0cyBESUdFU1QtTUQ1CgkgKgoJICogbGRhcDovL3d3dy50cnVzdGNl bnRlci5kZQoJICogCXN1cHBvcnRzIGFub255bW91cwoJICogCXN1cHBvcnRzIFN0YXJ0VExTCgkg Ki8KCXB1YmxpYyBzdGF0aWMgdm9pZCBtYWluKFN0cmluZyBhcmdzW10pIHRocm93cyBFeGNlcHRp b24gewoJCVN0cmluZyB1cmwgPSBhcmdzWzBdOwoJCVN0cmluZyB1c2VyID0gbnVsbDsKCQlTdHJp bmcgcGFzc3dvcmQgPSBudWxsOwoJCWlmIChhcmdzLmxlbmd0aCA+IDEpIHsKCQkJdXNlciA9IGFy Z3NbMV07CgkJCXBhc3N3b3JkID0gYXJnc1syXTsKCQl9CgkJU3RyaW5nIHF1ZXJ5ID0gIihvYmpl Y3RDbGFzcz0qKSI7CgkJU3RyaW5nW10gcXVlcnlBdHRyaWJ1dGVzID0geyAiZGlzdGluZ3Vpc2hl ZE5hbWUiLCAiZG4iLCAib2JqZWN0Q2xhc3MiLCAiY24iLCAibWFpbCIsICJuYW1lIiwgInJvbGUi LCAibWVtYmVyT2YiLCAiZ3JvdXAiIH07CgoJCUxEQVBTZWFyY2ggbGRhcCA9IG5ldyBMREFQU2Vh cmNoKCk7CgkJdHJ5IHsKCQkJLyogQkVHSU4gU0VUVElOR1MgKi8KCQkJbGRhcC5zZXRWZXJpZnlQ ZWVyQ2VydGlmaWNhdGUoZmFsc2UpOyAvLyBERUJVRyBPTkxZISEhCgkJCWxkYXAudXNlU3RhcnRU TFModHJ1ZSk7CgkJCWxkYXAudXNlRGlnZXN0TUQ1KHRydWUpOwoJCQlsZGFwLnNldENyZWRlbnRp YWxzKHVzZXIsIHBhc3N3b3JkKTsKCQkJbGRhcC5zZXRTZWFyY2hQYWdlU2l6ZSgyMCk7CgkJCS8q IEVORCBTRVRUSU5HUyAqLwoKCQkJbGRhcC5jcmVhdGVDb250ZXh0KHVybCk7CgkJCWxkYXAuc2Vh cmNoKAoJCQkJbmV3IER1bXBSZXN1bHRIYW5kbGVyKFN5c3RlbS5vdXQpLAoJCQkJcXVlcnksCgkJ CQlxdWVyeUF0dHJpYnV0ZXMsCgkJCQlTZWFyY2hDb250cm9scy5TVUJUUkVFX1NDT1BFLAoJCQkJ MzAwMDAJLy8gdGltZW91dAoJCQkpOwoJCX0KCQlmaW5hbGx5IHsKCQkJbGRhcC5kZXN0b3J5Q29u dGV4dCgpOwoJCX0KCX0KfQo= ------=_Part_4736650_2080278089.1355331209999 Content-Type: text/x-java; name=UnsecureSSLSocketFactory.java Content-Disposition: attachment; filename=UnsecureSSLSocketFactory.java Content-Transfer-Encoding: base64 aW1wb3J0IGphdmEuaW8uKjsKaW1wb3J0IGphdmEubmV0Lio7CgppbXBvcnQgamF2YXgubmV0Lio7 CmltcG9ydCBqYXZheC5uZXQuc3NsLio7CgpwdWJsaWMgY2xhc3MgVW5zZWN1cmVTU0xTb2NrZXRG YWN0b3J5IGV4dGVuZHMgU1NMU29ja2V0RmFjdG9yeSB7CgoJcHJpdmF0ZSBzdGF0aWMgU3RyaW5n IF9kZWZhdWx0UHJvdG9jb2wgPSAiU1NMIjsKCXByaXZhdGUgU1NMU29ja2V0RmFjdG9yeSBfbmV4 dDsKCglwdWJsaWMgc3RhdGljIFNTTFNvY2tldEZhY3RvcnkgY3JlYXRlU29ja2V0RmFjdG9yeShT dHJpbmcgcHJvdG9jb2wpIHsKCQl0cnkgewoJCQlTU0xDb250ZXh0IHNjID0gU1NMQ29udGV4dC5n ZXRJbnN0YW5jZShwcm90b2NvbCk7CgkJCXNjLmluaXQoCgkJCQludWxsLAoJCQkJbmV3IFRydXN0 TWFuYWdlcltdewoJCQkJCW5ldyBYNTA5VHJ1c3RNYW5hZ2VyKCkgewoJCQkJCQlwdWJsaWMgamF2 YS5zZWN1cml0eS5jZXJ0Llg1MDlDZXJ0aWZpY2F0ZVtdIGdldEFjY2VwdGVkSXNzdWVycygpIHsK CQkJCQkJCXJldHVybiBuZXcgamF2YS5zZWN1cml0eS5jZXJ0Llg1MDlDZXJ0aWZpY2F0ZVtdIHt9 OwoJCQkJCQl9CgkJCQkJCXB1YmxpYyB2b2lkIGNoZWNrQ2xpZW50VHJ1c3RlZCgKCQkJCQkJCWph dmEuc2VjdXJpdHkuY2VydC5YNTA5Q2VydGlmaWNhdGVbXSBjZXJ0cywgU3RyaW5nIGF1dGhUeXBl KSB7CgkJCQkJCX0KCQkJCQkJcHVibGljIHZvaWQgY2hlY2tTZXJ2ZXJUcnVzdGVkKAoJCQkJCQkJ amF2YS5zZWN1cml0eS5jZXJ0Llg1MDlDZXJ0aWZpY2F0ZVtdIGNlcnRzLCBTdHJpbmcgYXV0aFR5 cGUpIHsKCQkJCQkJfQoJCQkJCX0KCQkJCX0sCgkJCQludWxsCgkJCSk7CgkJCXJldHVybiBzYy5n ZXRTb2NrZXRGYWN0b3J5KCk7CgkJfQoJCWNhdGNoKEV4Y2VwdGlvbiBlKSB7CgkJCXRocm93IG5l dyBSdW50aW1lRXhjZXB0aW9uKGUpOwoJCX0KCX0KCglwdWJsaWMgc3RhdGljIHZvaWQgc2V0RGVm YXVsdFByb3RvY29sKFN0cmluZyBwcm90b2NvbCkgewoJCV9kZWZhdWx0UHJvdG9jb2wgPSBwcm90 b2NvbDsKCX0KCglwdWJsaWMgc3RhdGljIFNvY2tldEZhY3RvcnkgZ2V0RGVmYXVsdCgpIHsKCQly ZXR1cm4gbmV3IFVuc2VjdXJlU1NMU29ja2V0RmFjdG9yeSgpOwoJfQoKCXB1YmxpYyBVbnNlY3Vy ZVNTTFNvY2tldEZhY3RvcnkoKSB7CgkJX25leHQgPSBjcmVhdGVTb2NrZXRGYWN0b3J5KF9kZWZh dWx0UHJvdG9jb2wpOwoJfQoKCUBPdmVycmlkZQoJcHVibGljIFNvY2tldCBjcmVhdGVTb2NrZXQo U3RyaW5nIGhvc3QsIGludCBwb3J0KQoJdGhyb3dzIElPRXhjZXB0aW9uLCBVbmtub3duSG9zdEV4 Y2VwdGlvbiB7CgkJcmV0dXJuIF9uZXh0LmNyZWF0ZVNvY2tldChob3N0LCBwb3J0KTsKCX0KCglA T3ZlcnJpZGUKCXB1YmxpYyBTb2NrZXQgY3JlYXRlU29ja2V0KFN0cmluZyBob3N0LCBpbnQgcG9y dCwgSW5ldEFkZHJlc3MgbG9jYWxIb3N0LAoJaW50IGxvY2FsUG9ydCkgdGhyb3dzIElPRXhjZXB0 aW9uLCBVbmtub3duSG9zdEV4Y2VwdGlvbiB7CgkJcmV0dXJuIF9uZXh0LmNyZWF0ZVNvY2tldCho b3N0LCBwb3J0LCBsb2NhbEhvc3QsIGxvY2FsUG9ydCk7Cgl9CgoJQE92ZXJyaWRlCglwdWJsaWMg U29ja2V0IGNyZWF0ZVNvY2tldChJbmV0QWRkcmVzcyBob3N0LCBpbnQgcG9ydCkgdGhyb3dzIElP RXhjZXB0aW9uIHsKCQlyZXR1cm4gX25leHQuY3JlYXRlU29ja2V0KGhvc3QsIHBvcnQpOwoJfQoK CUBPdmVycmlkZQoJcHVibGljIFNvY2tldCBjcmVhdGVTb2NrZXQoSW5ldEFkZHJlc3MgYWRkcmVz cywgaW50IHBvcnQsCglJbmV0QWRkcmVzcyBsb2NhbEFkZHJlc3MsIGludCBsb2NhbFBvcnQpIHRo cm93cyBJT0V4Y2VwdGlvbiB7CgkJcmV0dXJuIF9uZXh0LmNyZWF0ZVNvY2tldChhZGRyZXNzLCBw b3J0LCBsb2NhbEFkZHJlc3MsIGxvY2FsUG9ydCk7Cgl9CgoJQE92ZXJyaWRlCglwdWJsaWMgU29j a2V0IGNyZWF0ZVNvY2tldChTb2NrZXQgcywgU3RyaW5nIGhvc3QsIGludCBwb3J0LCBib29sZWFu IGF1dG9DbG9zZSkKCXRocm93cyBJT0V4Y2VwdGlvbiB7CgkJcmV0dXJuIF9uZXh0LmNyZWF0ZVNv Y2tldChzLCBob3N0LCBwb3J0LCBhdXRvQ2xvc2UpOwoJfQoKCUBPdmVycmlkZQoJcHVibGljIFN0 cmluZ1tdIGdldERlZmF1bHRDaXBoZXJTdWl0ZXMoKSB7CgkJcmV0dXJuIF9uZXh0LmdldERlZmF1 bHRDaXBoZXJTdWl0ZXMoKTsKCX0KCglAT3ZlcnJpZGUKCXB1YmxpYyBTdHJpbmdbXSBnZXRTdXBw b3J0ZWRDaXBoZXJTdWl0ZXMoKSB7CgkJcmV0dXJuIF9uZXh0LmdldFN1cHBvcnRlZENpcGhlclN1 aXRlcygpOwoJfQp9Cg== ------=_Part_4736650_2080278089.1355331209999--

4 8

[Engine-devel] patches waiting for review
by Laszlo Hornyak 13 Dec '12

13 Dec '12

Hi, I have abandoned my patches that did not get +2 in a month, so now I have a reduced list of patches waiting for +2: http://gerrit.ovirt.org/#/dashboard/1000027 Your feedback is welcome! Thx, Laszlo

1 0

Re: [Engine-devel] Request power-user status for mom project in jenkins
by Eyal Edri 12 Dec '12

12 Dec '12

[adding engine-devel] usually there is an official vote on each new power user for jenkins, and as long as there are no objections it is approved. since i know you're a mom maintainer and familiar with jenkins, i vote +1. Eyal. ----- Original Message ----- > From: "Adam Litke" <agl(a)us.ibm.com> > To: infra(a)ovirt.org > Cc: eedri(a)redhat.com > Sent: Tuesday, December 11, 2012 6:11:45 PM > Subject: Request power-user status for mom project in jenkins > > Hi all, > > I am the maintainer of the mom sub-project. Recently we upgraded the > mom build > process to use autotools. Unfortunately this has broken the Jenkins > build for > the project. Rather than asking here whenever I need an update to > the build > job, I think it makes sense for me to administer that myself. If > there is > agreement about this, could someone help me to acquire the relavent > permissions? > > Thanks! > > -- > Adam Litke <agl(a)us.ibm.com> > IBM Linux Technology Center > >

3 2