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