14:02:54 <sgallagh> #startmeeting OpenLMI Public IRC Meeting (2014-01-13) 14:02:54 <zodbot> Meeting started Mon Jan 13 14:02:54 2014 UTC. The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:02:54 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 14:03:03 <sgallagh> #meetingname OpenLMI Public IRC Meeting 14:03:03 <zodbot> The meeting name has been set to 'openlmi_public_irc_meeting' 14:03:08 <sgallagh> #chair sgallagh tsmetana jsafrane rdoty 14:03:09 <zodbot> Current chairs: jsafrane rdoty sgallagh tsmetana 14:03:13 <sgallagh> #info Meetings are recorded and will be posted on www.openlmi.org. Opinions expressed do not necessarily reflect the reviews of the participant's employer. 14:03:17 <sgallagh> #topic Roll Call 14:03:22 <rnovacek> .fas rnovacek 14:03:22 <zodbot> rnovacek: rnovacek 'Radek Novacek' <rnovacek@redhat.com> 14:03:30 <sgallagh> .hellomynameis sgallagh 14:03:33 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com> 14:03:41 <jsafrane> .fas jsafrane 14:03:42 <zodbot> jsafrane: jsafrane 'Jan Šafránek' <jsafrane@redhat.com> 14:03:43 <tsmetana> .hellomynameis tsmetana 14:03:45 <zodbot> tsmetana: tsmetana 'Tomas Smetana' <tsmetana@redhat.com> 14:03:49 <tbzatek> .fas tbzatek 14:03:50 <zodbot> tbzatek: tbzatek 'Tomas Bzatek' <tbzatek@redhat.com> 14:03:52 <phatina> .hellomynameis phatina 14:03:53 <zodbot> phatina: phatina 'Peter Hatina' <phatina@redhat.com> 14:04:59 <sgallagh> miminar: Are you around? The software provider is first on the agenda today. 14:05:31 <tsmetana> phatina: poke him, please 14:05:47 * phatina will poke miminar, when he returns back 14:06:36 <sgallagh> Ok, well the software provider agenda item was currently the only one on my list. 14:06:50 <sgallagh> So I guess I'll just ask "Does anyone have questions to bring up?" 14:06:53 <tsmetana> phatina: what about the ssl verification? 14:07:06 <sgallagh> #topic SSL Verification Status 14:07:30 <phatina> tsmetana: right 14:08:04 <phatina> sgallagh: before going to christmas PTO, I run into the "same" issue, we were dealing with in pywbem 14:08:27 <sgallagh> phatina: Sorry, can you clarify? 14:08:32 <phatina> sgallagh: I mean, the issue, which is related to certificate hostname/IP cerification 14:08:55 <sgallagh> Do you mean that you found cases where the fix didn't work? 14:09:01 <sgallagh> Or that it apparently regressed? 14:09:37 <phatina> sgallagh: C++ library (replacement for pywbem) uses TOG-Pegasus client library, which provides some means of x509 verification, but it lacks API for hostname-to-hostname verification 14:10:05 <sgallagh> Ah ok. So to rephrase for clarity: 14:10:11 <phatina> basically, TOG-Pegasus provides the "same" api, as pywbem did <- before miminar's fix 14:10:21 * miminar is back 14:10:23 <phatina> what I started doing is: 14:10:37 <sgallagh> You discovered during the rewrite to the C API that the pegasus WBEM library also lacks a hostname comparison routine built-in. 14:10:49 <sgallagh> #info phatina discovered during the rewrite to the C API that the pegasus WBEM library also lacks a hostname comparison routine built-in 14:11:30 <phatina> I added some methods, which expose necessary calls to retrieve subjectAltNames, currently I am working on IP addresses counterpart 14:11:43 <phatina> then I can move on and *do the check* in lmiwbem module 14:12:35 <sgallagh> phatina: It would be preferable to do the check in the pegasus library 14:12:38 <sgallagh> If at all possible 14:12:42 <sgallagh> Then other packages would benefit 14:13:24 <phatina> sgallagh: or in the TOG-Pegasus's library 14:13:29 <phatina> sgallagh: OK 14:14:35 <phatina> sgallagh: so I will check all the things in Pegasus's library and also expose API to be able to do anything I want in client's code? 14:14:42 <sgallagh> #action phatina to work on adding certificate subject comparison to the Pegasus C library. 14:14:58 <sgallagh> phatina: I don't understand what you mean by "do anything I want" 14:16:46 <phatina> sgallagh: you suggest to verify the certificate in Pegasus's library, so client doesn't have to do anything - but current API provides a means of registering a callback to verify the certificate at client's side <- does it make sense to expose subjectAltNames/... to client's callback function? 14:17:28 <sgallagh> phatina: My recommendation would be that we should implement a default verification callback that is used unless the client specifies its own. 14:17:43 <sgallagh> In that case, it should be up to the client to implement all appropriate aspects of the verification. 14:17:48 <phatina> sgallagh: so yes, it does 14:17:56 <sgallagh> Yes 14:18:49 <phatina> sgallagh: in that case, the verification callback needs to change it's prototype, and some other client libs will break... there is no other way, I can think of 14:18:56 <kkaempf> Hi guys, can you come up with a testcase for the certification issue ? Then I could check sfcc (sblim client lib) against it. 14:19:01 <sgallagh> phatina: Hmm. 14:19:22 <sgallagh> kkaempf: Easy: create an alias hostname (such as in /etc/hosts) and connect to it. 14:19:33 <sgallagh> If it accepts the certificate for the real hostname, then it's broken. 14:19:43 <kkaempf> :-) 14:20:01 <sgallagh> Basically, there's an issue right now where any certificate signed with a trusted authority is accepted. 14:20:14 <sgallagh> But it should only accept one that's signed and has the appropriate subject or subjectAltName 14:20:31 <phatina> or IP address (x509v3 extension) 14:20:39 <sgallagh> Right 14:20:55 <sgallagh> kkaempf: We fixed this same issue recently in pywbem 14:21:08 <sgallagh> But it's apparently an issue in the pegasus client lib as well 14:21:50 <kkaempf> I've seen the pywbem fix (but being an ssl illiterate, I didn't really grasp it :-/ ;-) ) 14:22:04 <sgallagh> kkaempf: Does the above explanation make things a little clearer? 14:22:15 <kkaempf> Yes, thanks ! 14:22:38 <sgallagh> kkaempf: Also, were you aware of our efforts to build a replacement python library for pywbem? 14:22:58 <sgallagh> We've discovered that the pure-python implementation of pywbem is a serious performance bottleneck 14:22:59 <kkaempf> No, I haven't read anything about it on the mailing list. 14:23:16 <sgallagh> kkaempf: I think it's mostly been discussed in these IRC meetings, sorry 14:23:28 * phatina will announce the module soon 14:23:34 * kkaempf need to catch up on irc meeting minutes 14:24:04 <sgallagh> kkaempf: anyway, the plan is for us to re-implement a (hopefully) drop-in replacement for pywbem with a significant performance gain 14:24:25 <sgallagh> And the ability to maintain the connection (rather than pywbem's current behavior of renegotiating connection and auth for every request) 14:24:50 <kkaempf> You did look at sblim-sfcc before starting this project, didn't you ? ;-) 14:25:11 <phatina> kkaempf: sure 14:25:22 <sgallagh> kkaempf: We did, but the license isn't acceptable for our use :( 14:26:03 <kkaempf> I see. The usual problem with IBM. Even the sblim team is complaining :-/ 14:26:31 <rdoty> Is there a backstory on this we should know? 14:26:38 <sgallagh> rdoty: A backstory on what? 14:26:55 <rdoty> IBM licensing, especially on sblim & sfcc 14:26:58 <kkaempf> rdoty: Just that IBM lawyers outnumber IBM engineers. 14:27:07 <rdoty> :-( 14:27:18 <rdoty> Ah yes, the Nazgul... 14:27:36 <kkaempf> rdoty: the sblim team would *love* to have an easier license + move to github. 14:27:53 <rdoty> Any chance of this happening? 14:28:18 <sgallagh> rdoty: I'm kind of hoping "SBLIM is incompatible with OpenLMI" will become the driver for that :) 14:32:41 <tsmetana> do we want to move to the sw provider rewrite now? 14:32:45 <sgallagh> Lets 14:32:49 <sgallagh> #topic Software Provider 14:33:51 <sgallagh> So, the situation as I see it: 14:34:07 <miminar> to summarize: software provider is now written in python, it's slow, fat (due to yum's obfuscated API) and memory demanding 14:34:08 <sgallagh> We have two conflicting, important goals for the Software Provider 14:35:21 <sgallagh> 1) We want to improve performance and portability, which means rewriting to support PackageKit instead of yum directly (bonus: we won't need to rewrite for dnf either) 14:35:40 <sgallagh> 2) We have a number of important feature enhancements that we want in the Software Provider (see the email on the list) 14:36:04 <sgallagh> It's worth noting that if we do 2) first, it *will* mean a larger amount of stuff to rewrite when we do get around to 1) 14:36:18 <sgallagh> But I'd like to get rdoty's opinion here on perceived consumer needs. 14:36:29 <sgallagh> Is it more important to have those features to drive adoption? 14:36:47 <rdoty> This is more a long term issue than a short term issue. 14:37:03 <rdoty> In the short term, the ability to configure a system is critical. 14:37:20 <rdoty> The functional capabilities of the current SW provider are a good baseline. 14:37:47 <rdoty> From what I've seen, the capabilities and performance to query specific packages and install a package are adequate 14:37:56 <rdoty> Large queries are far too slow. 14:38:23 <rdoty> So, I don't see it as a V1 issue, but one that will become significant as people begin to use OpenLMI. 14:38:38 <sgallagh> rdoty: Don't see which as a V1 issue? 14:38:50 <rdoty> Summary: The rewrite is desirable, but not time critical 14:39:02 <rdoty> sgallagh: SW Provider performance issues 14:39:23 <sgallagh> Right, but that's only one of two considerations there as well 14:39:31 <rdoty> To summarize differently: I support the SW provider rewrite. 14:39:33 <sgallagh> The other being portability: right now it only works for yum 14:39:41 <sgallagh> Which has two problems: 14:39:59 <sgallagh> 1) To the best of my knowledge, only Fedora and RHEL use yum for package management 14:40:19 <rdoty> kkaempf: can you provide input here? 14:40:19 <sgallagh> 2) Fedora is switching to DNF in the relatively near future (possibly before 2014 concludes) 14:40:57 <tsmetana> + fedora is switching to python3 as a default. 14:41:25 <kkaempf> rdoty: openSUSE and SLES use zypper for package management (command line client, similar to yum, but written in C++) 14:41:38 <sgallagh> kkaempf: Is zypper compatible with PackageKit as well? 14:41:52 <kkaempf> sgallagh: yes 14:41:54 <sgallagh> ok 14:43:15 <sgallagh> My personal opinion on the matter is that since we know this is a move we need to make eventually, it would be better to get it over with now rather than waiting until the DNF switch forces our hand. 14:43:49 <sgallagh> The performance gains are a major plus, but not the driving concern for me. 14:44:32 <sgallagh> And the more features we implement, the harder this band-aid will be to rip off. 14:45:10 <jsafrane> exactly 14:45:23 <jsafrane> so let's rewrite it? 14:46:19 <sgallagh> jsafrane: I'm waiting for rdoty to respond as well. 14:46:48 <sgallagh> I want to give him a chance to make another argument 14:47:43 <rdoty> Umm, what part of "09:39: I support the SW Provider rewite" needs clarification? 14:48:15 <sgallagh> rdoty: The part that didn't reach my IRC client? 14:48:33 <sgallagh> I got "Summary: The rewrite is desirable, but not time critical" 14:48:37 <miminar> :) let's do it then :) ... reordering my TODO list 14:48:42 <rdoty> <rdoty> To summarize differently: I support the SW provider rewrite. 14:48:56 <sgallagh> rdoty: Ah 14:49:10 <sgallagh> It sounded to me like you were saying "Do it later". My mistake. 14:49:17 <sgallagh> Ok, then we're all on board here. 14:49:31 <sgallagh> miminar: For now, push the other RFEs to 1.2.0 14:49:44 <sgallagh> If the rewrite goes quickly, we'll pull some back in. 14:49:58 <miminar> sgallagh: ok 14:50:38 <sgallagh> #agreed miminar will work on the rewrite to PackageKit and defer other Software Provider RFEs until that is complete. 14:50:42 <sgallagh> #topic Open Floor 14:50:52 <sgallagh> Any topics for Open Floor? 14:51:37 <jsafrane> I started looking at udisks so we can drop blivet, but I've just just started 14:52:06 <sgallagh> jsafrane: Anything noteworthy? 14:53:16 <jsafrane> well, udisks misses a feature or two, but I have its maintainer sitting just next to me :) 14:53:29 <tbzatek> :-) 14:54:24 <jsafrane> especially, udisks is about block devices only, while we want to mount ntfs/cifs/tmpfs etc 14:54:42 <sgallagh> hmm 14:55:13 <sgallagh> #info udisks lacks support for non-block devices (such as network mounts and tmpfs) 14:55:57 <sgallagh> This would be a good conversation to have with the Cockpit folks. They're working on udisks extensions and I suspect they'll need this functionality as well 14:56:07 <tsmetana> wouldn't cockpit need those features too? 14:56:10 <tsmetana> ah 14:56:14 <tsmetana> slow typing... 14:56:42 <rdoty> Also, we're seeing increasing interest in SSD based caching... 14:56:55 <tbzatek> hmm, in Desktop this is abstracted by gvfs, but it's a mixture of fstab, mtab and udisks entries 14:58:56 <tsmetana> rdoty: bcache is already in f20 afaik. but i'm not sure it has any api or something. 14:59:21 <rdoty> tsmetana: As usual in Linux, there are multiple projects addressing the need... 15:00:09 <sgallagh> rdoty: Hmm, looks like the HP meeting was canceled. 15:00:16 <sgallagh> ah, whoops. Wrong channel 15:01:22 <sgallagh> Shall I just leave this as an action item for jsafrane to discuss with the Cockpit project and report on it next week? 15:01:38 <jsafrane> fine for me 15:01:49 <sgallagh> #action jsafrane to discuss udisks enhancements with the Cockpit Project and report back next week. 15:02:08 <sgallagh> Any further topics for this week? (We're a few minutes over) 15:02:26 <tbzatek> sgallagh: on a side note, could you please retest https://fedorahosted.org/openlmi/ticket/184 with latest packages (openlmi-providers-0.4.2 series) when you have time please? 15:02:54 <sgallagh> tbzatek: Yes, sorry. I've been preoccupied. 15:03:02 <tbzatek> sgallagh: no worries 15:03:05 <sgallagh> I'll try to get to that today if possible 15:03:23 <tbzatek> any testing is welcome 15:04:55 <sgallagh> #action sgallagh to retest https://fedorahosted.org/openlmi/ticket/184 15:05:08 <sgallagh> OK, closing out the meeting in 60s unless there are other topics 15:06:33 <sgallagh> Thank you everyone for participating today! 15:06:36 <sgallagh> #endmeeting