[Engine-devel] Managing async tasks
by Adam Litke
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
12 years
Re: [Engine-devel] [vdsm] Host bios information
by Barak Azulay
----- 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
>
12 years
[Engine-devel] VDSM tasks, the future
by Saggi Mizrahi
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.
12 years
[Engine-devel] Creating New Data-Center and Permission on Network
by Moti Asayag
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
12 years
[Engine-devel] ThreadPoolUtil with 500 threads and no queue?
by Juan Hernandez
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.
12 years
[Engine-devel] UI plugins - next steps
by Vojtech Szocs
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
12 years
[Engine-devel] Adding Authentication mechanism to oVirt
by Alon Bar-Lev
------=_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--
12 years
Re: [Engine-devel] Request power-user status for mom project in jenkins
by Eyal Edri
[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
>
>
12 years
