13:00:19 <sgallagh> #startmeeting OpenLMI (2014-03-31)
13:00:19 <zodbot> Meeting started Mon Mar 31 13:00:19 2014 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:00:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:00:22 <sgallagh> #meetingname OpenLMI Public IRC Meeting
13:00:22 <zodbot> The meeting name has been set to 'openlmi_public_irc_meeting'
13:00:27 <sgallagh> #chair sgallagh tsmetana jsafrane rdoty
13:00:27 <zodbot> Current chairs: jsafrane rdoty sgallagh tsmetana
13:00:32 <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.
13:00:36 <sgallagh> #topic Roll Call
13:00:42 <sgallagh> #info sgallagh is here
13:01:23 * rnovacek is here
13:01:43 <sgallagh> #info rnovacek is here
13:01:44 * jsafrane is here
13:01:49 <sgallagh> #info jsafrane is here
13:02:28 * tsmetana is here
13:02:38 * miminar is here
13:03:07 <sgallagh> #info tsmetana is here
13:03:12 <sgallagh> #info miminar is here
13:03:40 <sgallagh> Ok, let's get started
13:03:46 <sgallagh> #topic Agenda
13:03:54 <sgallagh> I have two items for the agenda:
13:03:59 <sgallagh> #info Fedora Server Roles
13:04:02 <sgallagh> #info Bug Triage
13:04:07 <sgallagh> #undo
13:04:07 <zodbot> Removing item from minutes: INFO by sgallagh at 13:04:02 : Bug Triage
13:04:09 <sgallagh> #undo
13:04:09 <zodbot> Removing item from minutes: INFO by sgallagh at 13:03:59 : Fedora Server Roles
13:04:14 <sgallagh> #info Agenda Item: Fedora Server Roles
13:04:20 <sgallagh> #info Agenda Item: Bug Triage
13:04:30 <sgallagh> Does anyone else have something they'd like to put on the list?
13:04:45 <sgallagh> (sorry for not sending out an agenda request; I mean to do so on Friday, then forgot)
13:04:52 * tsmetana doesn't have anything...
13:05:31 <sgallagh> jsafrane: Anything worth discussing on the storage front?
13:05:44 <jsafrane> sgallagh: not really
13:05:47 <sgallagh> ok
13:06:05 <sgallagh> #topic Fedora Server Roles
13:06:49 <sgallagh> The Fedora Server Product plans to produce a D-BUS API for deploying common infrastructure "Roles" on machines.
13:07:15 <sgallagh> We would like to see OpenLMI provide the remote interface to this capability.
13:07:42 <sgallagh> #info The Fedora Server Product plans to produce a D-BUS API for deploying common infrastructure "Roles" on machines. OpenLMI could be the remote interface for this.
13:08:04 <sgallagh> tsmetana and I had a discussion last week about using OpenLMI also as the default local client for this
13:08:45 <sgallagh> One concern here was whether it would be possible to use OpenLMI client tools as part of a kickstart. tsmetana was going to look into that.
13:08:45 <tsmetana> sgallagh: yes... and i'm afraid for the local only client, openlmi might not be the best fit
13:09:36 <sgallagh> tsmetana: would you mind #info-ing your reasoning?
13:09:41 <tsmetana> sgallagh: no success so far: i have no idea how to start pegasus from the kickstart before the machine reboots
13:10:06 <sgallagh> tsmetana: 'systemctl start' doesn't work?
13:10:34 <tsmetana> sgallagh: no. there is no pegaus in the anaconda system and systemctl refuses to run in chrooted environment
13:10:49 <tsmetana> sgallagh: maybe some trick might work...
13:11:28 <sgallagh> #info Starting Pegasus in the kickstart %post looks unreasonably difficult at this time
13:11:38 <sgallagh> I doubt we want to expend the effort there, then.
13:11:53 <jsafrane> also, dbus in chroot...
13:11:57 <tbzatek> uhm, it's a bit overkill imho to install tons of software for a simple thing withing kickstart
13:12:13 <sgallagh> I guess we'll build a simple local tool for kickstart and rely on OpenLMI for remote cases primarily
13:12:18 <sgallagh> (or at least post-install cases)
13:12:23 <sgallagh> tbzatek: Hmm?
13:12:33 <tsmetana> sgallagh: even if that would work... pegasus would create interop in a "semi-configured" machine, generates certificates, etc. we may not want it to do so early after the installation
13:12:37 <sgallagh> jsafrane: What about dbus? I'm told that this is already possible and done for other things in kickstart
13:13:04 <sgallagh> #info tsmetana also notes that starting pegasus in %post might lead to incorrect first-time configuration bugs.
13:13:48 <jsafrane> sgallagh: I think anaconda uses system dbus for network manager etc. Now we need second dbus in chroot.
13:14:25 <sgallagh> jsafrane: stefw indicated that realmd works in kickstart
13:14:42 <sgallagh> I'm pretty sure that has to be in the chroot to work
13:15:26 <jsafrane> sgallagh: I think realmd has its own anaconda plugin and kickstart commands
13:15:39 <jsafrane> it does not run in %post
13:16:06 <sgallagh> jsafrane: Good to know. I'll sync up with stefw on that.
13:16:13 <sgallagh> We may have to do the same in Fedora Server
13:16:17 <jsafrane> http://fedoraproject.org/wiki/Anaconda/Kickstart#realm
13:16:36 <sgallagh> #action sgallagh to check with stefw about building anaconda plugin and kickstart commands for role deployment
13:16:41 <jsafrane> then we have cimom inside Anaconda, cool :)
13:16:54 <sgallagh> jsafrane: Well, I'm not sure about the CIMOM.
13:17:01 <sgallagh> We'll need it for the Server Roles at least
13:17:23 <sgallagh> It sounds like most people in this discussion are generally opposed to trying to do this in kickstart, and I'm inclined to agree
13:17:28 <sgallagh> At least in the F21 timeframe
13:18:08 <jsafrane> well, kickstart command + dbus is fine, I would prefer  Anaconda without CIMOM
13:18:15 <sgallagh> Proposal: OpenLMI will plan to implement only the remote tool for Fedora Server Roles (or the post-first-boot configuration locally)
13:18:25 * jsafrane nods
13:18:41 * tsmetana agrees
13:18:55 <sgallagh> +1
13:19:17 <sgallagh> #agreed OpenLMI will plan to implement only the remote tool for Fedora Server Roles (or the post-first-boot configuration locally)
13:19:39 <sgallagh> Next question: since OpenLMI is therefore not a blocker to delivering Fedora Server in F21, do we want to reprioritize our involvement?
13:20:08 <sgallagh> It's certainly nice to have a remote interface and it would gain us exposure.
13:20:26 <sgallagh> But it certainly doesn't feel like anything we couldn't defer if we had to
13:21:32 <sgallagh> tsmetana: Opinion?
13:22:39 <tsmetana> sgallagh: yes. we may focus more closely at backporting to rhel-6
13:22:46 <tsmetana> ...or anything else.
13:23:21 <tsmetana> sgallagh: depends on the server-role API: the provider + script might be relatively easy.
13:23:43 <tsmetana> sgallagh: and as you noted: we need some more exposure
13:23:55 * sgallagh nods
13:24:41 <sgallagh> tsmetana: Maybe a task for an intern or thesis candidate?
13:25:05 <rdoty> GSOC?
13:25:26 <sgallagh> I'd have to check the timing on that
13:25:35 <sgallagh> There was a call for proposals recently
13:25:40 <sgallagh> Not a bad idea though
13:25:58 <rdoty> Yeah, we're probably late for this year.  :-(
13:26:17 <sgallagh> Student applications closed five days ago :(
13:26:19 <tsmetana> sgallagh: i can't offer a job to an intern... not saying it's not a good idea.
13:26:40 <sgallagh> Right, I wasn't expecting you to magically grow a req :)
13:26:49 <tsmetana> sgallagh: there will be holiday in summer and we'll have more internship applicants
13:27:33 <tsmetana> if some of them would be interested in summer-only job... we have nothing to lose.
13:27:36 <sgallagh> That still may work out. Alpha change deadline is currently July 22
13:27:46 <sgallagh> It'd be a bit tight, though
13:28:18 <tsmetana> sgallagh: we're not a release blocker. the new provider may land as a 0day update...
13:28:22 <sgallagh> Well, even if it didn't make the install media, it's not a huge issue
13:28:27 <sgallagh> Yeah, exactly what I was thinking :)
13:28:37 <sgallagh> Ok, let's see where that goes.
13:29:05 <sgallagh> So in general, I assume we're agreed that this has become only medium priority for us?
13:29:22 <sgallagh> (if not low)
13:31:02 <sgallagh> #agreed support for Fedora Server Role remote management is no longer a top priority, but will remain nice-to-have if the opportunity presents itself.
13:31:03 <tsmetana> +1 (medium)
13:31:13 <sgallagh> (sorry, jumped the gun a bit...)
13:32:14 <sgallagh> Ok, let's move on to the triage then
13:32:22 <sgallagh> #topic Bug Triage
13:33:03 <sgallagh> Despite the long absence of this meeting, we only have twelve tickets in NEEDS_TRIAGE today.
13:33:20 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/301 - Add subscription manager provider
13:33:59 <sgallagh> So, presumably this is specifically for support of RHEL machines.
13:34:11 <tsmetana> sgallagh: right.
13:35:02 <tsmetana> sgallagh: 1.2.0 is end of the year... so 1.2.0 for now?
13:35:09 <sgallagh> I'm not sure how important this is, since Satellite handles this as well, doesn't it?
13:35:29 <sgallagh> Yeah, I'm not inclined to rush into this, but I'd like to hear from rdoty on the subject
13:36:02 <sgallagh> (BTW, tsmetana: will you handle the ticket updates? I don't want to collide)
13:36:03 <rdoty> This is a 1.2 or 1.3 item. At the moment I'm inclined to push it to 1.3.
13:36:25 <sgallagh> I'm in favor of pushing it out to 1.3 then and pulling it back if we discover that it's important
13:36:28 <tsmetana> sgallagh: yes, i'll update the tickets
13:36:39 <sgallagh> No sense filling up 1.2 with stuff that will get deferred.
13:36:43 <rdoty> We will need to provide this capability at some point in the future, but need to better understand it.
13:36:54 <tsmetana> hm... that means... creating the 1.3.0 milestone...
13:37:14 <sgallagh> tsmetana: I'll do that now
13:37:17 <tsmetana> ok
13:37:19 <rdoty> Do we want to call it 1.3 or 2.0?
13:37:23 <sgallagh> I'll assume six months from 1.2
13:37:29 <sgallagh> rdoty: Let's not complicate matters
13:37:33 <sgallagh> We can change that later
13:37:51 <rdoty> OK. (I'd suggest it is actually a simplification)
13:38:12 <sgallagh> tsmetana: milestone created
13:38:21 <tsmetana> fine.
13:38:41 <sgallagh> tsmetana: Okay with 1.3?
13:39:04 <tsmetana> sgallagh: yes. ticket changed.
13:39:20 <sgallagh> #agreed Push out to OpenLMI 1.3.0
13:39:35 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/303 - Add abrt provider
13:39:35 <tsmetana> sgallagh: perhaps we should put 1.3.0 after 1.2.0
13:39:43 <sgallagh> tsmetana: Hmm?
13:39:54 <sgallagh> Oops, should have been 2015...
13:39:59 <rdoty> I'd suggest the abrt team
13:40:22 <sgallagh> tsmetana: Fixed. Thanks :)
13:40:35 <rdoty> For 303, the abrt team should be responsible for the provider (with help from the OpenLMI team).
13:40:45 <rdoty> This is an application vertical Provider.
13:40:49 <rdoty> Thoughts?
13:41:34 <sgallagh> In line with the SSSD provider currently being developed by the SSSD team, that makes sense.
13:41:36 <tsmetana> rdoty: i can poke jfilak... he's tinkered with openlmi some time ago...
13:42:16 <rdoty> tsmetana: Thank you. We have some real potential for abrt, but there needs to be an integrated program.
13:42:27 <sgallagh> Defer until we talk to the abrt team?
13:42:32 <tsmetana> +1
13:42:39 <rdoty> +1
13:42:53 <sgallagh> #agreed deferred until conversation with the ABRT team occurs
13:43:09 <sgallagh> #action tsmetana to contack jfilak about ABRT provider development.
13:43:26 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/128 - Test with IPv6
13:43:43 <sgallagh> This was deferred a while ago to check with Red Hat QE. Did that happen?
13:44:24 <rdoty> Sounds like a topic for the Friday call
13:44:34 <tsmetana> sgallagh: yes. it did. they don't run any special tests with ipv6 iirc.
13:45:03 <sgallagh> tsmetana: Any basic ones at least?
13:45:06 <tsmetana> sgallagh: i made a feeble attempt to get some info right in the ticket...
13:45:29 <sgallagh> I'd like to confirm that at least 'lmi hwinfo cpu' works over IPv6, for example.
13:45:39 <sgallagh> I think we can *reasonably* extrapolate from that
13:45:52 <tsmetana> sgallagh: i'm not sure they got to the hw provider testing yet.
13:46:03 <sgallagh> I picked an arbitrary example :)
13:46:29 <tsmetana> i picked an arbitrary provider...
13:47:08 <sgallagh> You mean they haven't tested *anything* yet?
13:47:13 <sgallagh> Never mind
13:47:18 <sgallagh> I don't want to know the answer to that
13:47:18 <tsmetana> no... that was a joke attempt.
13:47:26 <sgallagh> :)
13:47:34 <rdoty> tsmetana: you tried and it worked?
13:47:41 <tsmetana> sgallagh: they tested storage, some networking and services + account
13:47:56 * sgallagh nods
13:48:01 <tsmetana> the problem is that each of the providers has been tested by a different qa group
13:48:07 <sgallagh> I'll see about doing some simple IPv6 testing later today.
13:48:17 <sgallagh> Maybe I'll record one of my demos with IPv6
13:48:36 <tsmetana> it should work.
13:48:47 <rdoty> Isn't that on a tombstone?
13:48:55 <rdoty> "It should work"
13:49:01 <tsmetana> not yet.
13:49:11 <rdoty> Well, not yours...
13:49:12 <sgallagh> rdoty: I'm pretty sure you're looking for "It worked in *theory*"
13:49:14 <tsmetana> ah.
13:49:31 <sgallagh> Anyway, let's punt on this for now. I'll test it myself.
13:49:40 <sgallagh> #action sgallagh to try testing with IPv6
13:49:54 <sgallagh> This isn't really a milestone ticket in any case; more of a task
13:50:09 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/298 - LMI_IPNetworkConnection can be in association with incorrect LMI_IPAssignmentSettingData
13:50:14 <rdoty> Throw it into 1.1?
13:50:19 <sgallagh> And the record for longest subject line goes to...
13:50:38 <rdoty> Excuse me; throw IPv6 testing into 1.1?
13:50:52 <sgallagh> rdoty: Milestones are for deliverables.
13:51:09 <sgallagh> Once I test, I'll either close it as done or open individual bugs
13:51:15 <rdoty> OK
13:52:00 <sgallagh> So this looks like a pretty interesting bug
13:52:18 <sgallagh> I'm curious what would happen if we had two wifi adapters in a device
13:52:25 <sgallagh> (such as a USB adapter as well)
13:53:47 <sgallagh> I have a feeling that the bug here is that all devices are getting an association with all wifi networks
13:54:08 <sgallagh> But since there's generally only one WiFI adapter, it's hard to see.
13:55:03 <rdoty> This doesn't occur with ethernet?
13:55:50 <sgallagh> rdoty: The bug is that ethernet devices are being seen as associated with wifi devices
13:55:54 <sgallagh> err wifi networks
13:56:17 <rdoty> Got it. That may be non-optimal behavior...
13:56:22 <sgallagh> Clearly
13:56:31 <rnovacek> sgallagh: looks like that associations are missing some filtering in case of wifi
13:56:43 <rnovacek> sgallagh: should be fairly easy to fix
13:57:01 <sgallagh> Given that our primary target audience is servers which don't have WiFI adapters in general, I'm inclined to push to 1.1 (rather than fix in 1.0)
13:57:10 <sgallagh> But if it's easy to fix, I wouldn't stop it going in, either :)
13:57:50 <sgallagh> tsmetana: thoughts?
13:58:06 <tsmetana> 1.1.0
13:58:12 <rdoty> sgallagh: you mean an upstream and F20 fix?
13:58:24 <rnovacek> sgallagh: well, it's not crash neither it blocks some core functionality, so I would say 1.1
13:58:34 <sgallagh> 1.1 works for me
13:59:23 <rdoty> How about "target 1.1, release upstream when available"?
13:59:41 <sgallagh> That's likely redundant.
14:00:04 <sgallagh> #agreed Fix in OpenLMI 1.1.0
14:00:04 <tsmetana> and would require a special milestone.
14:00:42 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/271 - [RFE] lmi command support for persistent network setting
14:01:06 <sgallagh> So this bug surprised me. I didn't realize we weren't setting persistent network state.
14:01:11 <sgallagh> rnovacek: What's the rationale on this?
14:02:09 <rnovacek> sgallagh: honestly, I don't know. The settings are persistent for me
14:02:35 <rnovacek> sgallagh: I'll have to ask fskola how to reproduce it
14:02:39 <sgallagh> Thanks
14:02:50 <sgallagh> Let's leave this in NEEDS_TRIAGE until you've, well, triaged it :)
14:03:33 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/250 - openlmi-doc-class2rst can't process whole cim schema
14:03:53 <sgallagh> #undo
14:03:53 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x43d83ad0>
14:04:06 <sgallagh> #info Leaving in NEEDS_TRIAGE until rnovacek can reproduce it
14:04:08 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/250 - openlmi-doc-class2rst can't process whole cim schema
14:04:59 * tsmetana has no idea.
14:05:52 <jsafrane> I think there are some problems with konkret, but I haven't had time to investigate further
14:06:04 <sgallagh> I presume this is documentation only?
14:06:33 <sgallagh> I'd call that low urgency myself
14:06:48 <tsmetana> sgallagh: it's marked as such
14:06:49 <jsafrane> no, openlmi-doc-class2rst is the tool to generate doc. And it's low prio
14:07:37 <sgallagh> jsafrane: Right, that's what I meant
14:07:43 <sgallagh> That it only has impact on docs
14:08:03 <sgallagh> "Postponed" bucket?
14:08:37 <tsmetana> might be... same for #251 probably
14:08:48 <sgallagh> tsmetana: +1
14:09:17 <tsmetana> ok. done
14:09:22 <sgallagh> #agreed Move to "Postponed" bucket
14:09:37 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/251 - openlmi-doc-class2rst tracebacks without arguments
14:09:38 <sgallagh> #agreed Move to "Postponed" bucket
14:09:51 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/289 - Service reloading not supported
14:10:30 <sgallagh> If this is true, I'd call this a critical bug
14:10:44 <sgallagh> Many services rely on being reloaded to avoid service interruptions
14:11:44 <tsmetana> vcrhonek: ^^^
14:13:10 <sgallagh> Shall we come back to this when vcrhonek is around?
14:13:13 <vcrhonek> I'm looking at it...
14:13:18 <sgallagh> oh ok, sorry
14:15:34 <vcrhonek> The provider supports ReloadService() method
14:15:58 <sgallagh> vcrhonek: Would you mind syncing up with fskola for a reproducer?
14:16:21 <vcrhonek> sgallagh: Sure, no problem
14:16:35 <sgallagh> #action vcrhonek to ask fskola for a reproducer
14:16:53 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/264 - Can't install packages without repository PGP key
14:18:18 <tsmetana> hm. this looks more like a poor error handling.
14:18:24 <sgallagh> First question, since I don't know the answer: Does the software provider have an interface for installing and approving keys?
14:19:04 <tsmetana> miminar: ^^
14:19:15 <tsmetana> (i think no, but it's safer to ask)
14:20:44 <miminar> sgallagh: yes, it has
14:21:02 <miminar> sgallagh: packagekit offers a nice dbus interface for it
14:21:19 <sgallagh> miminar: And the existing yum-based provider?
14:22:04 <miminar> sgallagh: it could be added, with some enhancements to CIM API
14:22:36 <sgallagh> Hmm, that's going to make life difficult trying to use OpenLMI on pristine deployments.
14:22:54 <sgallagh> IIRC, we don't import the keys at all until the first post-install yum action
14:23:12 <rdoty> If this is going into the PackageKit rewrite, it sounds like 1.1
14:23:34 <miminar> sgallagh: I see, since we are going to deploy OpenLMI on rhel6, it needs to be added even to python provider
14:23:55 <rdoty> Hmmm, good point
14:24:29 <sgallagh> miminar: Is the version of PackageKit on RHEL 6 API-incompatible?
14:24:48 <sgallagh> (did we *have* PackageKit, actually? I forget)
14:25:07 <miminar> sgallagh: no sure, I'll check
14:25:11 <sgallagh> Ok, so I think there are several pieces to this bug, but all of them need addressing in 1.1
14:25:37 <tsmetana> ok
14:26:04 <sgallagh> #agreed Address in OpenLMI 1.1.0
14:26:17 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/302 - Add support for yum history
14:26:42 <sgallagh> I'm inclined to say that this is uninteresting to us in the general case.
14:27:47 <tsmetana> postponed?
14:28:05 <tsmetana> or minor 1.2.0
14:28:10 <sgallagh> But the rollback *might* be useful in some cases (though I think Fedora Atomic/ostree may prove a better solution eventually)
14:28:40 <rdoty> pschiffe: any details on the use case you were thinking of?
14:28:40 <sgallagh> I'm inclined to say postponed until and unless PackageKit grows history support
14:29:47 <sgallagh> I really don't want the deprecated interface to have more features than the one we're moving forward with.
14:30:13 <tsmetana> all right
14:30:46 <pschiffe> sgallagh: only for system script, providing e.g. last updated info, etc. see https://fedorahosted.org/openlmi/ticket/194
14:31:41 <sgallagh> pschiffe: Seems to me that we'd be better off submitting an RFE to PackageKit for that one piece of information instead, then
14:32:19 * sgallagh suspects that in a pinch we could just check the modification time of the RPM db
14:33:15 <sgallagh> So, postponed for now?
14:33:38 <tsmetana> postponed.
14:33:58 <rdoty> +1
14:34:06 <sgallagh> #agreed Move to "postponed" milestone
14:34:11 <pschiffe> sgallagh: simple RFE for PackageKit could work
14:34:19 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/275 - Extended partition size is always 1024
14:35:08 <sgallagh> Is there anything for us to do here if the Blivet bug is fixed?
14:35:21 <sgallagh> If not, I'd just close this as CANTFIX and wait for Blivet to solve it
14:35:49 <rdoty> Is there a BZ for Blivet?
14:36:02 <sgallagh> rdoty: https://bugzilla.redhat.com/show_bug.cgi?id=1077250
14:36:07 <rdoty> Also, is the reporting wrong partition size Blivet or LMI?
14:36:27 <rdoty> sgallagh: ah, didn't scroll far enough. Sorry
14:36:36 <sgallagh> jsafrane: ^^
14:38:03 <jsafrane> sgallagh: I'm just waiting for blivet to fix it, then I'll retest it\
14:38:24 <sgallagh> Ok, let's leave this in NEEDS_TRIAGE for now, then
14:38:33 <sgallagh> No clear idea when this will get fixed.
14:38:39 <sgallagh> tsmetana: work for you?
14:39:22 <tsmetana> yes
14:39:49 <sgallagh> #agreed leave in NEEDS_TRIAGE until we get feedback from the Blivet team
14:40:03 <sgallagh> #topic https://fedorahosted.org/openlmi/ticket/304 - Add total and free storage information
14:40:07 <sgallagh> Last one
14:40:36 <sgallagh> This would certainly be nice to have. 1.2?
14:40:37 <rdoty> Seems useful
14:41:21 <rdoty> I wouldn't object to having it in 1.1, but could live with 1.2
14:41:52 <rdoty> Is this Provider work or LMIShell?
14:42:03 <sgallagh> I'm wary of adding too much new functionality into 1.1, given that it's already a big effort to backport it to older systems
14:42:31 <tsmetana> so 1.2
14:42:32 <sgallagh> jsafrane: Does the storage provider already have this information?
14:42:55 <sgallagh> pschiffe: Can you provide more information on this bug?
14:43:30 <rdoty> We have this information per device, so it shouldn't be "that hard" to sum it up...
14:43:55 <rdoty> Having said that, I can live with 1.2.
14:44:21 <tsmetana> all right...
14:44:25 <pschiffe> sgallagh: it's just two number, total and free storage. when I talked to jsafrane about it, he told me that it's not currently supported, but planned - so I've created ticket for that
14:44:36 <sgallagh> #agreed Add this support in OpenLMI 1.2
14:44:41 <sgallagh> #topic Open Floor
14:44:50 <sgallagh> Anyone have items for Open Floor?
14:45:38 <sgallagh> I'll close out the meeting in one minute
14:46:39 <sgallagh> #endmeeting