13:04:43 <sgallagh> #startmeeting OpenLMI (2013-10-21)
13:04:43 <zodbot> Meeting started Mon Oct 21 13:04:43 2013 UTC.  The chair is sgallagh. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:04:43 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
13:04:45 <sgallagh> #meetingname OpenLMI Public IRC Meeting
13:04:45 <zodbot> The meeting name has been set to 'openlmi_public_irc_meeting'
13:04:54 <sgallagh> #chair sgallagh tsmetana jsafrane
13:04:54 <zodbot> Current chairs: jsafrane sgallagh tsmetana
13:05:12 <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:05:32 <sgallagh> #topic Roll Call and Introductions
13:05:58 <sgallagh> (oops, can someone op zodbot, please?)
13:06:25 <jsafrane> jooks like there is no op on this channel
13:06:33 <tbzatek> we're opless, unless someone has registered the channel in chanserv
13:07:00 <sgallagh> tsmetana: You should have op if you /msg Chanserv op #openlmi
13:07:06 <sgallagh> IIRC
13:07:37 <sgallagh> #topic Roll Call and Introductions
13:07:40 <tsmetana> sgallagh: right.
13:07:46 <sgallagh> Thanks
13:08:27 <sgallagh> Ok, so let's make a few introductions. My name is Stephen Gallagher and I'm an architect at Red Hat involved with server experience and manageability.
13:09:10 <tsmetana> Hi. I'm Tomas Smetana, supervisor of the group working on the OpenLMI project in Red Hat.
13:09:14 <sgallagh> I mostly make grand pronouncements and then rely on tsmetana and his team of brilliant engineers to actually get useful things done.
13:09:54 <jsafrane> I'm Jan Safranek, senior engineer in Red Hat, OpenLMI tech lead
13:10:13 <vcrhonek> Hi, I'm Vitezslav Crhonek, Red Hat engineer, WBEM/CIM package maintainer, OpenLMI service provider author
13:10:54 <phatina> Hi. I am Peter Hatina, Red Hat engineer, OpenLMI tools project author
13:10:55 <kkaempf> I am Klaus Kämpf, project manager and architect for systems management, working for SUSE Linux.
13:11:40 <tbzatek> Hi, I'm Tomáš Bžatek, Red Hat engineer, journald provider author, working on logging in general
13:11:52 <rnovacek> I'm Radek Novacek, engineer at Red Hat, author of the -networking and -power providers, I also manage openlmi buildbot instance
13:12:13 <jsynacek> Jan Synacek, software engineer at Red Hat, OpenLMI team. I maintain LogicalFile and I'm helping with the storage provider as well.
13:12:40 <pschiffe> Hi. I'm Peter Schiffer, Red Hat engineer, working on hardware provider in OpenLMI.
13:13:09 <miminar> Hi, I'm Michal Minar, Red Hat engineer, OpenLMI Software and Scripts author.
13:13:46 <jsafrane> oh, I forgot, I'm author of OpenLMI Storage
13:14:48 <sgallagh> Anyone else? jfilak, famicom` ? Are you folks participating or just lurking in the channel?
13:15:11 <tsmetana> jfilak is just watching. :)
13:15:28 <jfilak> I'm just interested in OpenLMI
13:15:30 <sgallagh> I'm a little disappointed at the turnout. I had confirmations from three other people representing three other companies, but it seems that they haven't turned up.
13:16:05 <sgallagh> But thank you everyone that is here.
13:16:22 <sgallagh> #topic Round-table Goals for OpenLMI
13:17:12 <sgallagh> So this first meeting is going to be very informal. I want us to talk a little bit about where we want to see the OpenLMI project go. What are the driving goals of the project?
13:17:44 <sgallagh> We have quite a bit of Red Hat representation, and I am hoping to hear from kkaempf as well.
13:17:50 <kkaempf> Port openLMI to other Linux distributions (please ;-))
13:18:21 <sgallagh> kkaempf: Ensuring that OpenLMI is portable to other distributions is a key goal that we want to accomplish.
13:18:51 <sgallagh> Certainly, in the interests of wide adoption, we will do what we can to make it easier to port and package.
13:19:05 <rdoty> kkapmpf: any idea what is required to port to other distros?
13:19:09 <kkaempf> I am packaging openLMI (and other CIM related packages) here: https://build.opensuse.org/project/show/systemsmanagement:wbem
13:19:33 <kkaempf> rdoty: I just started to figure that out
13:19:43 <sgallagh> #info kkaempf is packaging openLMI (and other CIM related packages) for SUSE
13:19:48 <sgallagh> #link https://build.opensuse.org/project/show/systemsmanagement:wbem
13:19:49 <kkaempf> rdoty: for software, support for 'zypper' besides 'yum'
13:20:09 <kkaempf> sgallagh: https://build.opensuse.org/project/show/systemsmanagement:wbem builds for RHEL and Fedora too :-)
13:20:24 <sgallagh> #info  https://build.opensuse.org/project/show/systemsmanagement:wbem builds for RHEL and Fedora too :-)
13:20:27 <sgallagh> Good to know
13:20:31 <kkaempf> rdoty: for network, the SUSE network scripts need to be supported
13:20:38 <tsmetana> hm. if only packagekit wasn't so... broken.
13:20:55 <sgallagh> kkaempf: Yes, one of the things we should be considering for the software provider is using an abstraction framework like PackageKit in the backend.
13:21:04 <kkaempf> sgallagh: build.opensuse.org could also build for Debian or Ubuntu (not my area of expertise though)
13:21:05 <sgallagh> Is Zypper package-kit compatible?
13:21:22 <kkaempf> sgallagh: yes, zypper works with package-kit
13:22:23 <kkaempf> One goal for openLMI would be a single URL to grab (binary) packages for all major distributions
13:22:50 <sgallagh> kkaempf: I'm not sure I follow. Could you explain that in greater detail?
13:23:31 <rnovacek> kkaempf: opensuse doesn't use NetworkManager?
13:23:49 <sgallagh> Ah, do you mean binary packages OF OpenLMI? (Sorry, got confused with the software provider discussion)
13:23:58 <kkaempf> sgallagh: https://fedorahosted.org/openlmi/ could link to build.opensuse.org for SUSE binaries.
13:24:39 <rnovacek> kkaempf: I though that NetworkManager can eat SUSE network scripts...
13:24:45 <kkaempf> rnovacek: NetworkManager only for the desktop, but many people switch it of for servers.
13:24:57 <sgallagh> kkaempf: As an aside, we're retiring fedorahosted.org as a wiki for the project. We've moved to www.openlmi.org and a Drupal-based site. That's orthogonal to the discussion, though
13:25:32 <kkaempf> sgallagh: What's wrong with github for openLMI ?
13:25:35 <sgallagh> kkaempf: That was a classic problem we had in RHEL as well, but with the upcoming RHEL 7 (and the many server-specific features that have been added to NM), we're recommending it as the preferred approach now.
13:25:39 <tbzatek> idea: what about supporting PackageKit Service Packs? http://www.packagekit.org/pk-faq.html#service-pack
13:26:06 <sgallagh> kkaempf: We may be switching to github for the git repository. That's open for discussion. We're just switching AWAY from the Trac-based Wiki because it sucks :)
13:26:13 <kkaempf> :-)
13:26:52 <tsmetana> kkaempf: NM got more server-oriented features (bridging, bonding,...) in the latest versions. and more to come.
13:27:18 <sgallagh> tbzatek: I'm not sure what you are trying to say there.
13:27:43 <kkaempf> As some of you might know, I am working with cim/wbem for a couple of years now (google me ;-)). When I try to advocate this technology, I have troubles finding good (open source) applications.
13:27:53 <sgallagh> kkaempf: The primary reason that OpenLMI went with NetworkManager is because its API provides consistency.
13:28:02 <tbzatek> sgallagh: an example of single-click installation of binary packages of openlmi, mentioned earlier
13:28:04 <rdoty> kkaempf: we've noticed that...
13:28:14 <sgallagh> If OpenLMI adopts network-scripts, we have to essentially put a lot more of the network-management logic into the provider itself.
13:28:16 <kkaempf> So I'd like to see a demo application (Ruby on Rails?) showing the capabilities of CIM
13:28:24 <sgallagh> Effectively creating a THIRD network stack
13:28:34 <sgallagh> tbzatek: Ah gotcha
13:28:52 <rdoty> kkaempf: any suggestions for what that demo might be?
13:28:52 <kkaempf> tsmetana: Thanks, I didn't know that part of NetworkManager
13:29:01 <sgallagh> kkaempf: Have you had a chance to play with lmishell and the lmishell scripts at all?
13:29:33 <kkaempf> sgallagh: Not yet. :-/
13:30:14 <sgallagh> kkaempf: That's our first-party consumer at this point. It's python (so no new language to learn) and capable of building powerful metacommands for BASH scripts and the like to call
13:30:39 <kkaempf> rdoty: The power of CIM (ihmo) is associations, showing how things are connected. I'd like to see a graphical representation (i.e. using d3js)
13:30:41 <sgallagh> We don't have a real GUI application consuming OpenLMI at this point because our initial research indicated that while such things are "pretty", real administrators work with scripts.
13:31:03 <rdoty> kkaempf: can you flesh that out a bit more?
13:31:04 <sgallagh> So our initial goal was to produce something that would fill the same problem-space as PowerShell
13:31:50 <kkaempf> sgallagh: Sysadmins (esp. coming from Windows) already know the technology. openLMI should also attract the decision-makers (CIOs).
13:32:35 <sgallagh> Interesting point...
13:32:56 <kkaempf> rdoty: A graph showing e.g. LMI_BaseBoard and the hardware connected to it.
13:33:32 <rdoty> kkaempf: Hmm, could  be interesting, especially with the latest changes to the hardware provider.
13:33:37 <sgallagh> Hmm, that actually might be a really good thing to add to that other project we're announcing soon...
13:33:42 <kkaempf> rdoty: use 'YAWN', get an instance of LMI_Chassis, and then click on "object associated with this instance"
13:33:56 <rdoty> Are you aware of anything out there that could be modified to do this?
13:34:51 <kkaempf> rdoty: I started https://github.com/kkaempf/wbem-explorer years ago to accomplish that. It talks cim/xml and ws-management. So one can shows Linux CIM information and Windows WMI information in one tool.
13:35:17 <kkaempf> rdoty: But neither my Rails nor my JavaScript knowledge is sufficient to bring this forward :-(
13:35:32 <rdoty> Interesting. When I looked at it, it looked like wbem-explorer was fairly dead...
13:35:53 <tsmetana> miminar: what about making YAWN to draw clickable pictures?
13:35:56 * tsmetana hides
13:36:00 <kkaempf> rdoty: Yes, it's fairly dead because I simply don't have time for it.
13:36:14 <miminar> tsmetana: I guess it's possible :-)
13:36:21 <miminar> but not that easy ...
13:36:56 <miminar> well.. actually I wanted to rewrite it from scratch months ago :-)
13:37:13 <rdoty> Ah, wbem-explorer is more current than I thought. Thanks for pointing that out.
13:37:44 <sgallagh> miminar: Let's avoid writing anything from scratch if we can help it
13:38:07 <kkaempf> rdoty: wbem-explorer still uses a SQL database. I was experimenting with orientdb (a graph database) lately, which looks promising.
13:38:09 <sgallagh> Particularly if something like wbem-explorer is a partial solution that we could perhaps bring under the OpenLMI umbrella
13:38:43 <rdoty> kkaempf: can you give us a quick overview of wbem-explorer and its capabilities?
13:38:58 <miminar> sgallagh: ouch...then it's a real challenge
13:39:10 <sgallagh> miminar: Why is that?
13:39:50 <kkaempf> rdoty: Its an attempt to bring CIM structure information (instances + associations) to a visual representation (graph, tree, list).
13:39:51 <jsafrane> miminar: on 'associators' page yawn seems to have all information it needs, now we need some js to draw nice boxes and arrows
13:40:39 <kkaempf> rdoty: Its based on Rails + d3js. d3js is particularly interesting because all graph elements (vertexes, edges) are active (clickable) elements.
13:40:50 <rdoty> kkaempf: Have you tried running it against OpenLMI?
13:40:59 <miminar> jsafrane: sgallagh: do we really want to extend those already not so readable pages for another stuff?
13:41:06 <rdoty> And do you have a screen shot or pdf you could share with us?
13:41:07 <kkaempf> rdoty: not yet
13:41:44 <miminar> I think that another more interactive design would be more beneficial .. something more oriented on interactive use
13:41:59 <sgallagh> miminar: No, I'm suggesting that if kkaempf's wbem-explorer is closer to what we want, we might be better off focusing on helping him finish that, rather than rewriting YAWM
13:42:02 <kkaempf> rdoty: wbem-explorer uses https://github.com/kkaempf/ruby-wbem which is an abstraction layer on top of ruby-sfcc (talking cim/xml) and openwsman (talking ws-management).
13:43:16 <miminar> sgallagh: that's true
13:43:37 <sgallagh> Hmm, that brings up another point we want to discuss at greater length: The further we go, the more clear it becomes that we're going to need to bring in openwsman to the discussion.
13:44:01 <tsmetana> sgallagh: yes.
13:44:16 <kkaempf> rdoty: wbem-explorer then does some simply queries for base classes, like ComputerSystem, Service, Network, etc. pp. do visualize different aspects of the infrastructure.
13:44:46 <kkaempf> sgallagh: Talking about openwsman, I am also 'upstream' for openwsman :-)
13:45:00 <sgallagh> kkaempf: Yes, I thought I recalled that :)
13:47:17 <sgallagh> kkaempf: Does wbem-explorer have a long Ruby dep-chain?
13:47:41 <sgallagh> My experience with the language has generally been that it's really hard to maintain if there are a lot of dependencies.
13:48:39 <sgallagh> kkaempf: Would there be any chance of setting up a public (read-only) example of the wbem-explorer that we could poke at?
13:48:49 <kkaempf> sgallagh: besides Rails, it uses https://github.com/kkaempf/cim (cim model in Ruby), https://github.com/dmacvicar/ruby-sfcc (cim/xml) and openwsman (ruby bindings)
13:49:32 <kkaempf> sgallagh: oh, and https://github.com/kkaempf/wbem-explorer for the client abstraction
13:49:35 <sgallagh> Ok, assuming those gems don't have a lot of deps themselves, that looks pretty manageable
13:50:18 <kkaempf> Oops, https://github.com/kkaempf/ruby-wbem for client abstraction.
13:50:34 * sgallagh nods
13:51:10 <sgallagh> #action sgallagh will look into wbem-explorer and play around with it.
13:51:20 <kkaempf> sgallagh: 'cim' has no deps, ruby-sfcc needs sblim-sfcc, openwsman-ruby needs openwsman (the client side libs)
13:51:48 <kkaempf> sgallagh: I haven't tried to run wbem-explorer for some time, it might be in broken state.
13:52:30 <sgallagh> kkaempf: Ok, determining that would be a good first step, I'd say :)
13:52:50 <sgallagh> So, we've gotten a bit into the weeds here, so I'd like to redirect the conversation a little bit
13:52:58 <kkaempf> sgallagh: while wbem-explorer tries to implement the 'visualization' part, it doesn't really implement a 'real life' use-case for sysadmins or CIOs.
13:53:00 <rdoty> kkaempf: can you check and let us know about the current status?
13:53:08 <sgallagh> kkaempf: From your (or SUSE's) perspective: what is the long-term purpose that OpenLMI/CIM fulfills.
13:53:09 <kkaempf> rdoty: I will.
13:53:13 <rdoty> Thank you
13:53:18 <sgallagh> What are you hoping to get out of it, besides pretty visualizations?
13:54:04 <kkaempf> sgallagh: Infrastructure information. What hardware is there ? Can I upgrade RAM ? Which services are running, etc. pp.
13:54:51 <kkaempf> sgallagh: based on this information, build a 'service view' (service in terms of 'service provided by the datacenter'). Not 'service daemon running on a system'.
13:55:20 <sgallagh> Ok, so your use-cases are primarily on querying and monitoring, rather than modification?
13:55:35 <kkaempf> sgallagh: currently yes.
13:57:04 <sgallagh> Ok, that's notably different from our focus thus far, which has been on (re)configuration
13:57:13 <kkaempf> sgallagh: I'm unsure if modification is a 'sweet spot' for CIM. Because it needs two systems, one issuing one or more CIM calls to a client, and the client acting on the calls through its installed providers.
13:57:31 <kkaempf> sgallagh: How does this match with Katello and Puppet ?
13:57:56 <sgallagh> kkaempf: Ongoing discussion, sometimes heated :)
13:58:08 <kkaempf> I thought so. LOL.
13:58:16 <sgallagh> Puppet we can coexist with. The technologies are good at different things.
13:58:26 <kkaempf> Agreed
13:58:26 <sgallagh> Puppet is good at saying "The configuration is *this*".
13:59:05 <sgallagh> Whereas CIM would be better for dealing with rules-based changes such as "Bandwidth is getting tight on this bond, shift an interface over here from one that's underused"
13:59:47 <kkaempf> From my POV the sweet spot for CIM is interoperability. Using one data model to talk to Linux, Windows, Intel iAMT, Dell DRAC, VMware, you name it.
14:00:03 <sgallagh> kkaempf: That would be nice if any of them ACTUALLY used the same models.
14:00:18 <jsafrane> kkaempf: there is no _one_ data model
14:00:19 <sgallagh> But I do get your point
14:01:12 <kkaempf> In terms of getting infrastructure information, the basics are similar and one can tap into existing knowledge (of a Windows or a VMware admin).
14:01:24 <sgallagh> We have reached the top of the hour. If we need to stop here, that's fine. If people would like to continue, I at least have nothing scheduled for the next hour.
14:01:45 <kkaempf> In terms of actually changing configurations, I'm not sure if CIM is interoperable.
14:02:13 <kkaempf> I have to leave in the next ~5mins
14:02:36 <jsafrane> kkaempf: isn't IPMI better for hw inventory? The protocol is widely used and while every HW vendor deviates a bit, in general it's followed
14:02:44 <sgallagh> Ok, so then let's close this out and we'll happily continue this discussion later (either in this channel or at next week's meeting)
14:03:09 <kkaempf> jsafrane: maybe, but it only covers HW.
14:03:28 <jsafrane> yup, IPMI is HW only
14:04:05 <kkaempf> Last question: Should I send patches to make openLMI work on SUSE to the mailing list ?
14:04:35 <sgallagh> kkaempf: http://reviewboard-openlmi.rhcloud.com is our review site
14:05:10 <kkaempf> sgallagh: So it get an account and push patches there ?
14:05:14 <sgallagh> You can submit patches there either directly through the Web UI or by using the RBTools client package (recommended)
14:05:17 <kkaempf> s/it/I/g
14:05:25 <kkaempf> Ack, thanks
14:05:30 <sgallagh> kkaempf: Ah right. I'll need to get you an account.
14:05:42 <sgallagh> We're going to be migrating it to an OpenID-capable system soon.
14:05:50 <sgallagh> Oh, you can self-register, actually
14:06:19 <kkaempf> I'll do later today. Have to run to the next meeting now. Thanks a lot !!
14:06:29 <sgallagh> kkaempf: Thanks very much for participating.
14:08:05 <sgallagh> Thank you all for coming. Same time next week!
14:08:07 <sgallagh> #endmeeting