14:04:19 <sgallagh> #startmeeting OpenLMI Public IRC Meeting (2013-11-25)
14:04:19 <zodbot> Meeting started Mon Nov 25 14:04:19 2013 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:04:19 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
14:04:29 <sgallagh> #chair sgallagh tsmetana jsafrane
14:04:29 <zodbot> Current chairs: jsafrane sgallagh tsmetana
14:04:38 <sgallagh> #topic Roll Call
14:04:45 <sgallagh> .hellomynameis sgallagh
14:04:47 <zodbot> sgallagh: sgallagh 'Stephen Gallagher' <sgallagh@redhat.com>
14:05:03 <jsafrane> .hellomynameis jsafrane
14:05:03 <zodbot> jsafrane: jsafrane 'Jan Šafránek' <jsafrane@redhat.com>
14:05:11 <rnovacek> .hellomynameis rnovacek
14:05:11 <tsmetana> .hellomynameis tsmetana
14:05:11 <zodbot> rnovacek: rnovacek 'Radek Novacek' <rnovacek@redhat.com>
14:05:14 <zodbot> tsmetana: tsmetana 'Tomas Smetana' <tsmetana@redhat.com>
14:06:35 <sgallagh> Looks like Praveen and Klaus aren't around this week
14:07:11 <sgallagh> Ok, so I have two (related) agenda items for this week. I sent out the note about planning OpenLMI 1.1.0, but I also wanted to take a few minutes to talk about 1.0.1
14:07:20 <sgallagh> #topic Planning OpenLMI 1.0.1
14:07:43 <tsmetana> sgallagh: i've added the milestones to trac but i guess we might want to change them
14:08:15 * sgallagh looks for the link to paste in
14:08:36 <sgallagh> #link https://fedorahosted.org/openlmi/report/9
14:09:30 <sgallagh> So on the topic of OpenLMI 1.0.1 (a bugfix release for 1.0.0), I want to discuss Klaus's request to have some of his patches included.
14:09:35 <sgallagh> #link https://lists.fedorahosted.org/pipermail/openlmi-devel/2013-November/001894.html
14:09:46 <sgallagh> ^^ Is the mailing list thread where he made this request.
14:10:19 <sgallagh> My understanding is that most of them were acked and approved for the master branch already, so it should be fairly simple to backport them (since we haven't diverged far yet).
14:10:23 <sgallagh> Is that a fair assessment?
14:10:51 <tsmetana> they're also mostly included in the 40-fixes branch
14:11:11 <tsmetana> sgallagh: but yes, your statement is correct.
14:11:32 <sgallagh> 40-fixes branch?
14:11:59 <sgallagh> Ah, is that what we named the stable branch? (Sorry, I missed that)
14:12:23 <jsafrane> sgallagh: tsmetana: it's 0.4-fixes
14:12:35 <tsmetana> jsafrane: ah. sorry typo...
14:12:47 <sgallagh> #info Most of Klaus' patches are acked and included in the 0.4-fixes branch already
14:13:12 <sgallagh> tsmetana: Was BZ #1031334 the only one remaining?
14:13:25 <sgallagh> .bz https://bugzilla.redhat.com/show_bug.cgi?id=1031334
14:13:33 <sgallagh> .bz 1031334
14:13:44 * sgallagh thought zodbot understood that...
14:14:11 <tsmetana> sgallagh: yes.
14:14:18 <sgallagh> #link https://bugzilla.redhat.com/show_bug.cgi?id=1031334
14:14:31 <rnovacek> .bug 1031334
14:14:38 <zodbot> rnovacek: Bug 1031334 LMI_AccountProvider crash if user password is in /etc/passwd instead of /etc/shadow - https://bugzilla.redhat.com/show_bug.cgi?id=1031334
14:14:41 <tsmetana> sgallagh: it would be good to create regression test for the bugs.
14:14:41 <sgallagh> rnovacek: Thanks
14:15:07 <sgallagh> #info tsmetana recommends creating regression tests for the bugs
14:15:23 <sgallagh> I agree, and would suggest that we should file tickets to track that
14:15:48 <sgallagh> Has anyone looked into the above crash, yet? Do we have a handle on it?
14:16:02 <tsmetana> tbzatek: ^^^
14:16:14 <sgallagh> I suspect this is something we're going to want to fix in the stable branch. Crash bugs are unpleasant for users.
14:16:18 <tbzatek> I haven't been looking at that one yet
14:16:32 <sgallagh> #chair rdoty
14:16:32 <zodbot> Current chairs: jsafrane rdoty sgallagh tsmetana
14:16:48 <tbzatek> but looks pretty simple
14:16:53 * tbzatek adds on TODO list
14:17:25 <tsmetana> sgallagh: but there is a patch attached...
14:17:37 <tsmetana> and it looks sane...
14:17:39 <sgallagh> My thought is that it would be good citizenship for us to fix Klaus' remaining bug and release OpenLMI 1.0.1 soon. That way, he can get OpenLMI into OpenSUSE and we can hopefully get some greater exposure
14:17:49 <sgallagh> (And more bug reports_
14:18:19 <tsmetana> however having passwords stored in /etc/passwd should be quite exceptional situation.
14:18:45 <sgallagh> tsmetana: I wish that was true.
14:18:51 <sgallagh> But there are a lot of archaic setups out there.
14:19:41 <sgallagh> #info Fix for BZ #1031334 looks simple and the problem appears to be well-understood.
14:20:33 <sgallagh> So, are there any opposing views on doing an upstream 1.0.1 release soon?
14:20:36 <sgallagh> tsmetana, rdoty?
14:20:53 <rdoty> No objections
14:21:00 <jsafrane> we have still some races in account provider
14:21:18 <sgallagh> jsafrane: Tickets?
14:21:24 <tsmetana> sgallagh: how soon? should we align with opensuse schedule?
14:21:32 <sgallagh> #info Some races still exist in account provider.
14:21:59 <sgallagh> tsmetana: Yes, I think we should find out from Klaus what his schedule needs are.
14:22:13 <sgallagh> (That should include testing time)
14:22:14 <jsafrane> .bug #1026663
14:22:14 <zodbot> jsafrane: Error: '#1026663' is not a valid integer.
14:22:19 <jsafrane> .bug 1026663
14:22:21 <zodbot> jsafrane: Access Denied - https://bugzilla.redhat.com/show_bug.cgi?id=1026663
14:22:26 <jsafrane> :)
14:23:26 <sgallagh> Ok, for the benefit of anyone reading this later: this bug is a race-condition when waiting for indications
14:23:27 <tbzatek> it's not only that, the whole concept of separate passwd and shadow files is racy and libuser seems to have no tools for that
14:24:01 <tsmetana> tbzatek: have you discussed this with mitr?
14:24:17 <tbzatek> tsmetana: not yet
14:24:50 <sgallagh> tbzatek: That race sounds like something that may need more time to sort out. I'm not sure we necessarily want to wait for it if Klaus' needs are sooner.
14:25:04 <sgallagh> #action sgallagh to check with kkaempf about his schedule needs
14:25:40 <sgallagh> In the interest of not eating our entire meeting time on this topic, shall we agree to resume this discussion either next week or on the mailing list?
14:25:48 <tbzatek> sgallagh: that's a separate long-term issue, not directly related to bug  #1031334
14:26:13 <tbzatek> sgallagh: I think we can live with some workarounds for now
14:26:20 * sgallagh agrees
14:26:44 <sgallagh> ok, shall we move on to discussing future efforts?
14:27:09 <sgallagh> #topic Planning OpenLMI 1.1.0 (Next feature release)
14:27:24 <tsmetana> btw: https://en.opensuse.org/openSUSE:Roadmap
14:27:34 <sgallagh> #undo
14:27:34 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x6e1b850>
14:27:41 <sgallagh> #link https://en.opensuse.org/openSUSE:Roadmap
14:27:45 <sgallagh> #topic Planning OpenLMI 1.1.0 (Next feature release)
14:28:36 <sgallagh> So let's talk about the next set of interesting features we want to deliver over the next ~six months
14:29:04 <sgallagh> rdoty: I expect to hear from you here :)
14:29:26 <rdoty> Thank you Stephen!
14:29:33 <sgallagh> tsmetana: You mentioned earlier that you'd done some preliminary triaging; care to note any particular themes?
14:29:42 <rdoty> The biggest feature is, of course, LMIshell
14:30:12 <rdoty> Including delivery of the initial set of LMI Modules and LMI Commands (including documentation)
14:30:13 <sgallagh> rdoty: Please elaborate
14:30:16 <tsmetana> sgallagh: advanced storage features: lvm snapshotting, thin provisioning; also firewall might be a bigger topic.
14:30:44 <rdoty> We would like to get additional contributions to LMI Modules
14:31:15 <rdoty> Especially around task-oriented scripts to do things like configure storage and networks
14:31:52 <sgallagh> #info Major provider efforts: Advanced storage features (lvm snapshotting, thin provisioning) and Firewall manipulation
14:31:53 <tsmetana> oh. right: i would like to add fetures that would allow for cloud image sw management: basically create a module that would allow to mimic yum's behaviour over a set of machines.
14:32:03 <rdoty> It would be interesting to see someone put together a script to configure storage - an interactive script that prompted the user for input
14:32:37 <sgallagh> #info Other efforts: cloud image software management - perform package operations over a set of machines
14:32:39 <rdoty> I could see a simple UI that would enumerate the available devices and ask the user what to do
14:32:53 <rdoty> This could start off as a simple effort and grow over time
14:33:26 <rdoty> It is ideal for outside involvement, as it builds on top of existing core capabilities and should grow and evolve over time
14:33:30 <sgallagh> #info LMIshell script plans: Simplify creation of scripts. Build task-oriented scripts, possibly interactive or question-answer tools.
14:34:21 <rdoty> Beyond that, I would like to see more work on Indications
14:34:36 <sgallagh> rdoty: To meet what use-cases?
14:34:51 <rdoty> Take the indications that are currently available and come up with useful ways to use them.
14:35:01 <rdoty> This would do several things:
14:35:09 <rdoty> 1. Do useful things with Indications
14:35:24 <rdoty> 2. Develop examples and infrastructure for using Indications
14:35:40 <sgallagh> That's a bit ambiguous.
14:35:55 <rdoty> 3. Provide us with opportunities to discover any issues with our current implementation...
14:36:03 <tsmetana> lmi shell has some means to use the indications already.
14:36:14 <rdoty> 4. Give insight into what Indications should be developed next.
14:36:50 <rdoty> tsmetana: Yes. I'm suggesting that the next step should be to use the current Indications, preferably at the LMIshell level.
14:37:11 <sgallagh> #info rdoty recommends increasing the functionality and recommended practices around indications. See the full logs of the meeting for details.
14:37:31 <sgallagh> #info tsmetana notes that lmishell has some indication support today
14:37:48 <rdoty> sgallagh: I'm being a bit ambiguous to give people the opportunity to say "Hmmm, maybe I can use Indications to solve a specific problem I have"
14:38:11 <rdoty> Or "hmm, there is something interesting I can do to learn how to use Indications"
14:38:44 <rdoty> tsmetana; what are the top three currently available Indicators that might be used to do something interesting?
14:39:32 <tbzatek> well, I've been adding filtering support into indication queries, that might be an area of improvement, it still needs some (mostly client) work
14:39:32 <tsmetana> rnovacek: are there any indications in the networking? i think yes, but don't want to mystify anybody...
14:39:51 <sgallagh> rdoty: I'd say 1) Async completion notification, 2) System error alert for a start
14:40:28 <rdoty> sgallagh: those are technology areas - what can you do with them?
14:40:30 <rnovacek> tsmetana: yes, there are, like notification about change network interface state or notification about job change
14:41:04 <tsmetana> rnovacek: ok. thanks. what about, e.g. bonding iface degradation?
14:41:14 <sgallagh> rdoty: Well, error alerts seem fairly obvious; they can be directed at monitoring tools to notify admins of issues needing their attention
14:41:31 <rdoty> Can we do something like: Get an indication for a file system hitting 80% full and send an email to someone?
14:41:47 <sgallagh> Weird, I was just thinking of that exact example
14:41:48 <tsmetana> rdoty: networking might provide some nice examples: dhcp may take a while, so we have a job with indication on the interface being brought up.
14:41:48 <rnovacek> tsmetana: no, I would have to check if NM supports that
14:42:04 <rdoty> sgallagh: Great minds think alike. And so do ours...
14:42:33 <tsmetana> rnovacek: ok. it would be a nice example for an alert... others i can think of are raid/multipath degradation, scsi error, etc...
14:42:34 <sgallagh> rnovacek: Were you replying to the bonding degradation or the dhcp comment there?
14:42:52 <rnovacek> sgallagh: bonding
14:42:56 <sgallagh> Thanks
14:42:59 <jsafrane> storage does not track filesystem usage for now, but that could be added
14:43:07 <rdoty> tsmetana: do we have Indicators for those events?
14:43:13 <sgallagh> Can indications be created with conditions?
14:43:26 <tsmetana> rdoty: that is what the indication manager is supposed to do.
14:43:35 <jsafrane> but getting indication for filesystem space... that's possible only by using polling and I don't like that
14:43:40 <sgallagh> i.e. Can we have a generic "notify me when X percentage of storage is used", where we specify X when registering?
14:43:57 <rnovacek> sgallagh: networking provider already has indications to monitor connection activation (that includes waiting for dhcp)
14:44:12 <tsmetana> jsafrane: true. wherever we can get the events we should aim for "native indications"
14:44:19 <rdoty> jsafrane: what about setting the poll at 15 minute intervals?
14:44:43 <sgallagh> rdoty, jsafrane: Let's not dig into the weeds on that too much right now
14:44:49 <rdoty> Whoa - if we are looking at monitoring, what about Performance CoPilot?
14:44:52 <sgallagh> Let's talk at the consumer level first
14:45:05 <rdoty> Hmm, do we have any indicator support in PCP?
14:45:13 <sgallagh> fche: ^^
14:45:17 <jsafrane> sgallagh: rdoty: we don't have *any* events in storage now, I miss blivet support. I doesn't even provide md raid status
14:45:19 <rdoty> This might be a good time to talk to the PCP group.
14:45:33 <rdoty> Oh, right - Hi fche!
14:45:47 <sgallagh> jsafrane: Right, that's one of the key reasons to look into a daemon like udisks2
14:45:59 <sgallagh> I'm trying to coordinate that effort.
14:46:14 <jsafrane> sgallagh: right, I would prefer to rewrite storage first and then report indications
14:46:18 <sgallagh> #action sgallagh to check in on udisks2 LVM and RAID efforts
14:46:31 <rdoty> OK, let's get back to an earlier question: What are three currently available Indicators that could be used to do something interesting?
14:46:38 <rdoty> Anyone?
14:46:44 <tbzatek> account, journal?
14:46:46 <sgallagh> rdoty: "Updates are available for this system"
14:46:59 <rdoty> sgallagh: say more?
14:47:15 * tsmetana thinks there are no events in pmapi
14:47:39 <sgallagh> rdoty: If PackageKit/Yum/DNF/etc. on the target system identifies that one or more [security] updates are available for the system, we can send a notification to a registered client to inform them of this fact.
14:47:44 <rdoty> tbsatek: hmm, interesting. Something like send a notification if a password is changed?
14:48:01 <rdoty> What Indications do we have in account?
14:48:05 <tbzatek> rdoty: basically any change in passwd and group files
14:48:16 <sgallagh> rdoty: The accountsservice daemon has this capability (and so will SSSD when it subsumes the accountsservice functionality)
14:48:35 <rdoty> sgallagh: Is there sometime type of monitoring demon? I thought you had to manually invoke a check for updates?
14:48:36 <tbzatek> rdoty: right now "User/Group has been added/deleted" - four cases
14:49:02 <sgallagh> #info Much discussion on potential use-cases for various indicators in assorted providers. See full chat logs for details.
14:49:18 <sgallagh> rdoty: PackageKit is a monitoring daemon (if you're still talking about accounts)
14:49:30 <tbzatek> rdoty: and for journal we have "A new message has been logged" with ability to filter for some string and soon for severity level
14:49:39 <rdoty> OK, so we have User/Group has been added/deleted. I'm going to call that one, not four.  ;-)
14:49:49 <tbzatek> :-)
14:50:27 <sgallagh> rdoty: Accountsservice/SSSD will give us the ability to get a D-BUS notification whenever any attribute is modified.
14:50:38 <sgallagh> Which I recommend translating more-or-less directly into an indication
14:50:47 <rdoty> tbzatek: We actually have a general purpose Indicator for journald? That sounds _very_ interesting
14:51:08 <rdoty> sgallagh: Agreed, but the Indicator has to be written.
14:51:35 <sgallagh> Right, and this is still probably some time off
14:52:19 <rdoty> So, today we have User/Group added/deleted and New Message in journal with filtering
14:52:36 <rdoty> Who has the third (currently existing) Indication?
14:53:06 <jsafrane> the networking one?
14:53:13 <tsmetana> rdoty: networking
14:53:19 <rdoty> (And I now have material for the next few TechPonder Blog postings. Thanks, guys!)
14:53:31 <tsmetana> rdoty: and the polling for whatever using the indication manager...
14:53:34 <rdoty> OK, what Indicators exist for networking?
14:53:35 <tbzatek> rdoty: with limited filtering I'd say, for now (depends on CIMOM filtering and that one in Pegasus is quite limited, sfcbd might be on different level, better or even worse)
14:54:12 <rdoty> tbsatek: it's a start. Quite a good one, actually.
14:54:51 <tsmetana> rdoty: networking can send "notification about change network interface state or notification about job change"
14:55:36 <rdoty> OK, great.
14:56:17 <rdoty> Next challenge: If someone wants to write a program to use indications, preferably in LMIshell, how do they get started?
14:56:29 <rdoty> Are there any examples? Documentation?
14:56:41 <rdoty> Where should we point them?
14:57:04 <tsmetana> rdoty: http://www.openlmi.org/lmishell_indications
14:57:32 <rdoty> Good!
14:57:38 <tsmetana> (Submitted by rdoty on Thu, 09/26/2013 - 21:50) :)
14:57:45 <sgallagh> #link http://www.openlmi.org/lmishell_indications
14:57:50 <rdoty> Is there a HelloWorld for Indications?
14:58:01 <sgallagh> tsmetana: That was him pulling in content from the old Wiki, I think
14:58:18 <tsmetana> sgallagh: i know... i put a smiley there...
14:58:20 <rdoty> What do you need to do to install Indication support?
14:58:31 <rdoty> (rdoty was ignoring you)
14:59:23 <sgallagh> tsmetana: Sorry, missed the smiley as a closing paren
15:00:06 <tsmetana> rdoty: the document itself is basically a "hello world" for the indications
15:00:24 <tsmetana> ...i only hope it's up-to-date...
15:00:30 <rdoty> Seriously, if someone says "hmm, I'd like to write a program to send myself a text message when a new user is added to a system" what do they do?
15:00:36 <rdoty> How do they get started?
15:00:49 <tsmetana> phatina: ^^^ (indications in lmi shell)
15:00:51 <sgallagh> tsmetana: Who wrote it originally?
15:00:59 <tsmetana> sgallagh: i suppose phatina
15:01:03 <sgallagh> phatina: Willing to take an action item to make sure that page is up to date?
15:01:20 <sgallagh> (Hmm, we're past the hour; do we need to stop?)
15:01:28 <rdoty> (Have I thanked phitina for his work on LMIshell recently?)
15:01:28 <tsmetana> rdoty: they may replace the do_something_with() function in the example with send_sms()...
15:02:36 <phatina> rdoty: http://www.openlmi.org/sites/default/files/doc/client/lmishell/latest/indications.html
15:03:20 <phatina> sgallagh: there is a duplicity art LMIShell, the original link mentioned by rdoty should have been deleted, when uploading the "new" documentation...
15:03:21 <sgallagh> phatina: Ok, if that's the up-to-date version, we need to change the link on openlmi.org to point there
15:03:43 <sgallagh> #action phatina to update the links for lmishell indication documentation
15:03:43 <phatina> sgallagh: have a look at http://www.openlmi.org/sites/default/files/doc/client/lmishell/latest/index.html
15:03:51 <sgallagh> phatina: I will
15:03:52 <rdoty> phitina: I would suggest copying that content into the current Indications page
15:04:00 <sgallagh> #link http://www.openlmi.org/sites/default/files/doc/client/lmishell/latest/indications.html
15:04:05 <sgallagh> #link http://www.openlmi.org/sites/default/files/doc/client/lmishell/latest/index.html
15:04:22 <sgallagh> rdoty: Copying is prone to being forgotten
15:04:46 <sgallagh> I'd rather have the links to that page point back out to the sphinx docs
15:05:13 <rdoty> I'm OK with having a high level overview containing a link to the Sphinx docs
15:05:28 <sgallagh> rdoty: +1
15:05:59 <sgallagh> #agreed http://www.openlmi.org/lmishell_indications will be replaced with a high-level overview and a pointer to the Sphinx docs.
15:06:26 <rdoty> I'd still like to have a HelloWorld example that someone can run that shows Indications in action
15:06:54 <sgallagh> rdoty: File a ticket, please
15:07:14 <sgallagh> #action rdoty to file a ticket requesting a HelloWorld lmishell indication.
15:07:22 <phatina> I suggest to point all the links present at http://www.openlmi.org/using_lmishell to the Sphinx documentation
15:07:23 <rdoty> How hard is it to create a Gnome notification?
15:07:45 <sgallagh> rdoty: Call out to '/usr/bin/notify-send "message"'
15:08:05 <rdoty> phitina: will do. I would like to list you as the author for this page.
15:08:11 <sgallagh> #info phatina suggests pointing all the links present at http://www.openlmi.org/using_lmishell to the Sphinx documentation
15:08:15 <phatina> rdoty: there is a python binding for notify-send (notify-python)
15:08:32 <rdoty> sgallagh: sounds like we have our HelloWorld!
15:08:48 <tbzatek> (remember to set proper $DISPLAY var.)
15:08:58 <tsmetana> sorry guys... i need to run.
15:09:04 <rdoty> "If user_added than send notification"
15:09:09 <tsmetana> thanks everyone. bye.
15:09:37 <sgallagh> rdoty: Easy enough, yes.
15:09:45 <sgallagh> Please file a ticket.
15:09:56 <sgallagh> Maybe I'll even take that one myself as a learning exercise.
15:10:16 <rdoty> It should take 10 minutes to write
15:10:19 <rdoty> Right?
15:10:22 <rdoty> ;-)
15:11:24 <sgallagh> rdoty: I'll let you know. *After* you file the ticket.
15:13:58 <sgallagh> Ok, I think this is a good place to stop for this week.
15:14:07 <sgallagh> Thank you everyone for participating. Keep up the good work!
15:14:23 <rdoty> sgallagh: ticket #178
15:14:41 <sgallagh> #link https://fedorahosted.org/openlmi/ticket/178
15:14:46 <sgallagh> #endmeeting