14:02:03 <sgallagh> #startmeeting OpenLMI Public IRC Meeting (2013-12-09)
14:02:03 <zodbot> Meeting started Mon Dec  9 14:02:03 2013 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:02:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:02:07 <sgallagh> #meetingname OpenLMI Public IRC Meeting
14:02:07 <zodbot> The meeting name has been set to 'openlmi_public_irc_meeting'
14:02:12 <sgallagh> #chair sgallagh tsmetana jsafrane rdoty
14:02:12 <zodbot> Current chairs: jsafrane rdoty sgallagh tsmetana
14:02:14 <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:02:19 <sgallagh> #topic Roll Call
14:02:24 <sgallagh> .hellomynameis sgallagh
14:02:25 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
14:02:38 <tsmetana> .hellomynameis tsmetana
14:02:39 <zodbot> tsmetana: tsmetana 'Tomas Smetana' <tsmetana@redhat.com>
14:02:55 <tbzatek> .hellomynameis tbzatek
14:02:56 <zodbot> tbzatek: tbzatek 'Tomas Bzatek' <tbzatek@redhat.com>
14:03:53 <sgallagh> kkaempf: Are you around this week?
14:04:50 <rnovacek> .hellomynameis rnovacek
14:04:51 <zodbot> rnovacek: rnovacek 'Radek Novacek' <rnovacek@redhat.com>
14:05:13 <sgallagh> Ok, I suppose we'll get right into it, then. I've only got a couple topics for this week
14:05:23 <sgallagh> #topic Follow-up on udisks-LVM
14:05:39 <sgallagh> Last week, I was asked to look into the progress on the udisks-lvm support and report back.
14:06:09 <sgallagh> I spoke with Marius Vollmer and Stef Walter about it. Their view is that having this working is a blocker for their plans to launch Cockpit with Fedora 21
14:06:35 <sgallagh> Stef started building the new udisks add-on daemon last week and is making good progress.
14:07:23 <sgallagh> We will need to continue working closely with them so we can get an accurate sense of exactly when is the right time for us to move to using the udisks daemon for openlmi-storage support.
14:07:44 <sgallagh> If it's too late in the cycle before things stabilize, we may want to wait until OpenLMI 1.2.0
14:07:47 <tbzatek> sounds good!
14:08:12 <sgallagh> But we should absolutely be in contact and communicating our needs to them
14:08:22 <sgallagh> They are highly receptive to our participation
14:08:34 <tsmetana> sgallagh: so there will be two daemons in F21? udisks and "lvm-udisks"?
14:09:01 <sgallagh> Yes, the latter (with name TBD) will not reimplement any part of udisks, though
14:09:15 <sgallagh> It will provide an extension to the D-BUS API that udisks provides
14:09:31 <sgallagh> The goal is for these two projects to eventually merge, by demonstrating the value to the udisks upstream
14:09:43 <sgallagh> Without necessitating a complete fork at this time
14:10:36 <sgallagh> #info Progress on the LVM extensions to udisks is proceeding. Cockpit upstream is driving this effort and his highly receptive to OpenLMI input and collaboration.
14:11:17 <sgallagh> #info OpenLMI will need to monitor progress on udisks-lvm closely to determine when is the right time to switch over. Depending on delivery schedules, this may mean OpenLMI 1.2.0.
14:12:03 <sgallagh> #info The current implementation will be a second add-on daemon to udisks providing extended functionality. The goal is to eventually merge the projects together, pending upstream udisks approval.
14:12:36 <sgallagh> Any other questions on this topic?
14:12:44 <sgallagh> If not, I'll proceed to the next
14:13:32 * tsmetana has no questions atm.
14:13:41 <sgallagh> #topic Progress on OpenLMI 1.0.1
14:14:14 <sgallagh> We basically have two weeks to deliver 1.0.1 before the winter holidays get in the way (as agreed in previous meetings)
14:14:41 <sgallagh> It would probably be a good idea to reserve time at this and next week's meeting to discuss anything that looks important and prioritize it.
14:16:20 <sgallagh> tsmetana: Can you highlight the major pieces that we're considering blockers to the release right now?
14:16:39 * tsmetana looks at the bug list...
14:16:46 <sgallagh> We talked in general terms about "no known crash bugs or race-conditions", but I'd like to get some more concrete bugs to follow.
14:18:01 <tsmetana> there are some races reported in rhbz...
14:18:17 <tsmetana> and one crash
14:18:39 <sgallagh> In the "Nice-to-have" category, I know there is excellent work going on cleaning up the documentation. Thanks go out to Russ Doty for trying that out from an inexperienced perspective.
14:18:51 <tsmetana> +1
14:19:27 <sgallagh> tsmetana: Can we get those cloned to the upstream tracker? I'd like to have that be the canonical view of "what we need to do and how we have it prioritized"
14:19:43 <sgallagh> I.e. if I want to know "blockers for 1.0.1", that should be a saved search
14:21:03 <tsmetana> sgallagh: ok. i'll go through the races and the crash and clone them to the tracker.
14:21:10 <sgallagh> That would be a big help.
14:21:25 <sgallagh> tsmetana: What's your general comfort level on doing a release by the 20th?
14:23:43 <sgallagh> tsmetana: Your silence makes me nervous :)
14:23:53 * tsmetana thinks :)
14:24:24 <sgallagh> #action tsmetana to clone RHBZ crashes and races into the upstream trac for organizational purposes
14:24:33 <tsmetana> sgallagh: i would need to review the bugs in question.
14:26:01 <sgallagh> tsmetana: Would you be less nervous about doing a 1.0.1rc1 on that schedule, with an opportunity to finalize it early in January?
14:26:29 <tsmetana> sgallagh: yes. i'm afraid some of the races might need more time to debug and fix...
14:26:55 <sgallagh> #info There is concern that one of the race-condition bugs may need more time to debug and fix.
14:27:29 <sgallagh> #info suggestion may be to do a 1.0.1rc1 release next week and finalize it in early January.
14:28:13 <sgallagh> tsmetana: Are you aware of any blocking issues that we should discuss today?
14:28:46 <tsmetana> sgallagh: there is the problem with realmd ... not sure if that should be a blocker
14:29:07 <sgallagh> #topic realmd issue
14:29:12 <tsmetana> tbzatek, miminar: do you guys have some bugs that you would consider a blocker?
14:29:14 <sgallagh> tsmetana: Could you summarize it briefly, please?
14:29:42 <tbzatek> tsmetana: not a blocker exactly, no
14:30:03 <tsmetana> sgallagh: yes. the dbus message might timeout sooner than the result of the realmd operation (join/leave) is known to the realmd daemon itself.
14:30:30 <sgallagh> tbzatek: Hold that thought and I'll ask you to expand on it shortly :)
14:30:47 <sgallagh> #info the dbus message might timeout sooner than the result of the realmd operation (join/leave) is known to the realmd daemon itself
14:30:52 <tsmetana> sgallagh: so, e.g., the provider reports an error "operation time out" but after some time (minutes even) the system joins the realm.
14:31:19 <miminar> tsmetana: yes, I have
14:31:31 <sgallagh> tsmetana: Can't we work around that simply by extending the d-bus timeout (or disabling it entirely)?
14:31:45 <tsmetana> sgallagh: i actually have problems reproducing this -- it nees extra slow (hihg latency) network.
14:32:04 <sgallagh> The timeout value defaults to (IIRC) 15s, but the timeout is a standard part of the D-BUS API.
14:32:21 <miminar> tsmetana: this one: 1039018
14:32:31 <miminar> working onit
14:32:34 <sgallagh> I remember when writing the SSSD's D-BUS code that it was possible to specify -1 and have that mean "several weeks in the future"
14:32:37 <tsmetana> miminar: ok.
14:32:57 <tsmetana> miminar: i'll clone it to the trac so it's visible.
14:32:59 <sgallagh> miminar: I'll ask you to summarize that one in a couple minutes too, just for the logs here
14:33:19 <sgallagh> tsmetana: Who is working on that realmd bug?
14:33:23 <tsmetana> sgallagh: yes, but the realmd provider uses glib and -1 doesn't always work
14:33:28 <tsmetana> sgallagh: it's me.
14:34:27 <sgallagh> tsmetana: We can look into that together tomorrow morning (my time), if you want.
14:34:34 <tsmetana> sgallagh: according to tbzatek the "solution" the desktop people use for their code is to set the timeout to INT_MAX... but i dislike it of course.
14:34:52 <sgallagh> tsmetana: Internally, that's the same thing that using -1 does in libdbus
14:34:58 <tsmetana> sgallagh: yep. the problem is -- i don't know much of d-bus and realmd.
14:35:08 <sgallagh> tsmetana: I know a bit about both. I'll help with it.
14:35:34 <sgallagh> #action sgallagh to assist tsmetana on the realmd issue
14:35:48 <sgallagh> tbzatek: Ok, what was your "not a blocker exactly"?
14:36:15 <tbzatek> sgallagh: the indication subscription deadlock we were debugging last Friday
14:36:30 <sgallagh> #topic Indication subscriber deadlock
14:36:59 <tbzatek> I'm having a look at it and hopefully we'll find a solution or workaround till the release
14:37:00 <sgallagh> tbzatek: Ok, right. So in certain circumstances, it's possible to get the indication manager to freeze up until Pegasus is rebooted.
14:37:17 <tbzatek> but so far I have no idea where the issue is
14:37:22 <tbzatek> needs more debugging...
14:37:25 <sgallagh> I was hitting it consistently with the released OpenLMI bits, but it went away as far as I can tell with HEAD
14:37:47 <sgallagh> #info In certain circumstances, it's possible to get the indication manager to freeze up until Pegasus is rebooted
14:37:56 <tbzatek> I will cherry pick series of fixes from master
14:38:03 <tbzatek> that will make the hit rate much lower
14:38:37 <sgallagh> #action tbzatek to cherry-pick a series of fixes from master that will significantly reduce the hit rate of this issue
14:38:53 <sgallagh> #info tbzatek is continuing to research the cause of the deadlock
14:39:08 <sgallagh> Ok, miminar: would you mind summarizing your blocker as well?
14:39:34 <miminar> ok, it concerns indication delivery
14:39:47 <sgallagh> (Apologies if I am rushing a bit, I have a hard stop in ten minutes to go give a presentation)
14:39:56 <sgallagh> #topic Indication delivery
14:40:08 <miminar> they are not delivered when the subscription is made after the provider is initialized
14:40:32 <sgallagh> #info Indications are not delivered when the subscription is made after the provider is initialized
14:40:57 <tbzatek> miminar: which provider, is that on git master?
14:41:02 <miminar> it affects also Sync* calls done in lmishell
14:41:19 <miminar> tbzatek: software ... sorry for not being explicit :)
14:41:21 <sgallagh> #undo
14:41:21 <zodbot> Removing item from minutes: <MeetBot.items.Info object at 0xd413c50>
14:41:27 <sgallagh> #info Indications are not delivered when the subscription is made after the software provider is initialized
14:41:31 <miminar> yes its in master
14:41:39 <miminar> not the fix
14:41:58 <sgallagh> miminar: The same problem is in the stable branch as well?
14:42:16 <miminar> sgallagh: yes
14:42:30 <miminar> sgallagh: I'm still workin on fix
14:42:31 <sgallagh> Ok, just confirming
14:42:38 <sgallagh> #action miminar is working on a fix
14:42:48 <sgallagh> Thank you for the updates.
14:42:53 <miminar> job handling had to be reworked a bit
14:43:09 <miminar> you're welcome
14:43:10 <sgallagh> #info Fix requires job handling rework
14:43:22 <sgallagh> #topic Open Floor
14:43:55 <sgallagh> Anything for Open Floor?
14:44:56 <sgallagh> OK, I'll close out the meeting in one minute unless anyone has something to add.
14:45:56 <sgallagh> #endmeeting