13:04:43 #startmeeting OpenLMI (2013-10-21) 13:04:43 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 13:04:45 #meetingname OpenLMI Public IRC Meeting 13:04:45 The meeting name has been set to 'openlmi_public_irc_meeting' 13:04:54 #chair sgallagh tsmetana jsafrane 13:04:54 Current chairs: jsafrane sgallagh tsmetana 13:05:12 #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 #topic Roll Call and Introductions 13:05:58 (oops, can someone op zodbot, please?) 13:06:25 jooks like there is no op on this channel 13:06:33 we're opless, unless someone has registered the channel in chanserv 13:07:00 tsmetana: You should have op if you /msg Chanserv op #openlmi 13:07:06 IIRC 13:07:37 #topic Roll Call and Introductions 13:07:40 sgallagh: right. 13:07:46 Thanks 13:08:27 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 Hi. I'm Tomas Smetana, supervisor of the group working on the OpenLMI project in Red Hat. 13:09:14 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 I'm Jan Safranek, senior engineer in Red Hat, OpenLMI tech lead 13:10:13 Hi, I'm Vitezslav Crhonek, Red Hat engineer, WBEM/CIM package maintainer, OpenLMI service provider author 13:10:54 Hi. I am Peter Hatina, Red Hat engineer, OpenLMI tools project author 13:10:55 I am Klaus Kämpf, project manager and architect for systems management, working for SUSE Linux. 13:11:40 Hi, I'm Tomáš Bžatek, Red Hat engineer, journald provider author, working on logging in general 13:11:52 I'm Radek Novacek, engineer at Red Hat, author of the -networking and -power providers, I also manage openlmi buildbot instance 13:12:13 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 Hi. I'm Peter Schiffer, Red Hat engineer, working on hardware provider in OpenLMI. 13:13:09 Hi, I'm Michal Minar, Red Hat engineer, OpenLMI Software and Scripts author. 13:13:46 oh, I forgot, I'm author of OpenLMI Storage 13:14:48 Anyone else? jfilak, famicom` ? Are you folks participating or just lurking in the channel? 13:15:11 jfilak is just watching. :) 13:15:28 I'm just interested in OpenLMI 13:15:30 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 But thank you everyone that is here. 13:16:22 #topic Round-table Goals for OpenLMI 13:17:12 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 We have quite a bit of Red Hat representation, and I am hoping to hear from kkaempf as well. 13:17:50 Port openLMI to other Linux distributions (please ;-)) 13:18:21 kkaempf: Ensuring that OpenLMI is portable to other distributions is a key goal that we want to accomplish. 13:18:51 Certainly, in the interests of wide adoption, we will do what we can to make it easier to port and package. 13:19:05 kkapmpf: any idea what is required to port to other distros? 13:19:09 I am packaging openLMI (and other CIM related packages) here: https://build.opensuse.org/project/show/systemsmanagement:wbem 13:19:33 rdoty: I just started to figure that out 13:19:43 #info kkaempf is packaging openLMI (and other CIM related packages) for SUSE 13:19:48 #link https://build.opensuse.org/project/show/systemsmanagement:wbem 13:19:49 rdoty: for software, support for 'zypper' besides 'yum' 13:20:09 sgallagh: https://build.opensuse.org/project/show/systemsmanagement:wbem builds for RHEL and Fedora too :-) 13:20:24 #info https://build.opensuse.org/project/show/systemsmanagement:wbem builds for RHEL and Fedora too :-) 13:20:27 Good to know 13:20:31 rdoty: for network, the SUSE network scripts need to be supported 13:20:38 hm. if only packagekit wasn't so... broken. 13:20:55 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 sgallagh: build.opensuse.org could also build for Debian or Ubuntu (not my area of expertise though) 13:21:05 Is Zypper package-kit compatible? 13:21:22 sgallagh: yes, zypper works with package-kit 13:22:23 One goal for openLMI would be a single URL to grab (binary) packages for all major distributions 13:22:50 kkaempf: I'm not sure I follow. Could you explain that in greater detail? 13:23:31 kkaempf: opensuse doesn't use NetworkManager? 13:23:49 Ah, do you mean binary packages OF OpenLMI? (Sorry, got confused with the software provider discussion) 13:23:58 sgallagh: https://fedorahosted.org/openlmi/ could link to build.opensuse.org for SUSE binaries. 13:24:39 kkaempf: I though that NetworkManager can eat SUSE network scripts... 13:24:45 rnovacek: NetworkManager only for the desktop, but many people switch it of for servers. 13:24:57 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 sgallagh: What's wrong with github for openLMI ? 13:25:35 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 idea: what about supporting PackageKit Service Packs? http://www.packagekit.org/pk-faq.html#service-pack 13:26:06 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 :-) 13:26:52 kkaempf: NM got more server-oriented features (bridging, bonding,...) in the latest versions. and more to come. 13:27:18 tbzatek: I'm not sure what you are trying to say there. 13:27:43 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 kkaempf: The primary reason that OpenLMI went with NetworkManager is because its API provides consistency. 13:28:02 sgallagh: an example of single-click installation of binary packages of openlmi, mentioned earlier 13:28:04 kkaempf: we've noticed that... 13:28:14 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 So I'd like to see a demo application (Ruby on Rails?) showing the capabilities of CIM 13:28:24 Effectively creating a THIRD network stack 13:28:34 tbzatek: Ah gotcha 13:28:52 kkaempf: any suggestions for what that demo might be? 13:28:52 tsmetana: Thanks, I didn't know that part of NetworkManager 13:29:01 kkaempf: Have you had a chance to play with lmishell and the lmishell scripts at all? 13:29:33 sgallagh: Not yet. :-/ 13:30:14 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 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 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 kkaempf: can you flesh that out a bit more? 13:31:04 So our initial goal was to produce something that would fill the same problem-space as PowerShell 13:31:50 sgallagh: Sysadmins (esp. coming from Windows) already know the technology. openLMI should also attract the decision-makers (CIOs). 13:32:35 Interesting point... 13:32:56 rdoty: A graph showing e.g. LMI_BaseBoard and the hardware connected to it. 13:33:32 kkaempf: Hmm, could be interesting, especially with the latest changes to the hardware provider. 13:33:37 Hmm, that actually might be a really good thing to add to that other project we're announcing soon... 13:33:42 rdoty: use 'YAWN', get an instance of LMI_Chassis, and then click on "object associated with this instance" 13:33:56 Are you aware of anything out there that could be modified to do this? 13:34:51 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 rdoty: But neither my Rails nor my JavaScript knowledge is sufficient to bring this forward :-( 13:35:32 Interesting. When I looked at it, it looked like wbem-explorer was fairly dead... 13:35:53 miminar: what about making YAWN to draw clickable pictures? 13:35:56 * tsmetana hides 13:36:00 rdoty: Yes, it's fairly dead because I simply don't have time for it. 13:36:14 tsmetana: I guess it's possible :-) 13:36:21 but not that easy ... 13:36:56 well.. actually I wanted to rewrite it from scratch months ago :-) 13:37:13 Ah, wbem-explorer is more current than I thought. Thanks for pointing that out. 13:37:44 miminar: Let's avoid writing anything from scratch if we can help it 13:38:07 rdoty: wbem-explorer still uses a SQL database. I was experimenting with orientdb (a graph database) lately, which looks promising. 13:38:09 Particularly if something like wbem-explorer is a partial solution that we could perhaps bring under the OpenLMI umbrella 13:38:43 kkaempf: can you give us a quick overview of wbem-explorer and its capabilities? 13:38:58 sgallagh: ouch...then it's a real challenge 13:39:10 miminar: Why is that? 13:39:50 rdoty: Its an attempt to bring CIM structure information (instances + associations) to a visual representation (graph, tree, list). 13:39:51 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 rdoty: Its based on Rails + d3js. d3js is particularly interesting because all graph elements (vertexes, edges) are active (clickable) elements. 13:40:50 kkaempf: Have you tried running it against OpenLMI? 13:40:59 jsafrane: sgallagh: do we really want to extend those already not so readable pages for another stuff? 13:41:06 And do you have a screen shot or pdf you could share with us? 13:41:07 rdoty: not yet 13:41:44 I think that another more interactive design would be more beneficial .. something more oriented on interactive use 13:41:59 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 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 sgallagh: that's true 13:43:37 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 sgallagh: yes. 13:44:16 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 sgallagh: Talking about openwsman, I am also 'upstream' for openwsman :-) 13:45:00 kkaempf: Yes, I thought I recalled that :) 13:47:17 kkaempf: Does wbem-explorer have a long Ruby dep-chain? 13:47:41 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 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 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 sgallagh: oh, and https://github.com/kkaempf/wbem-explorer for the client abstraction 13:49:35 Ok, assuming those gems don't have a lot of deps themselves, that looks pretty manageable 13:50:18 Oops, https://github.com/kkaempf/ruby-wbem for client abstraction. 13:50:34 * sgallagh nods 13:51:10 #action sgallagh will look into wbem-explorer and play around with it. 13:51:20 sgallagh: 'cim' has no deps, ruby-sfcc needs sblim-sfcc, openwsman-ruby needs openwsman (the client side libs) 13:51:48 sgallagh: I haven't tried to run wbem-explorer for some time, it might be in broken state. 13:52:30 kkaempf: Ok, determining that would be a good first step, I'd say :) 13:52:50 So, we've gotten a bit into the weeds here, so I'd like to redirect the conversation a little bit 13:52:58 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 kkaempf: can you check and let us know about the current status? 13:53:08 kkaempf: From your (or SUSE's) perspective: what is the long-term purpose that OpenLMI/CIM fulfills. 13:53:09 rdoty: I will. 13:53:13 Thank you 13:53:18 What are you hoping to get out of it, besides pretty visualizations? 13:54:04 sgallagh: Infrastructure information. What hardware is there ? Can I upgrade RAM ? Which services are running, etc. pp. 13:54:51 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 Ok, so your use-cases are primarily on querying and monitoring, rather than modification? 13:55:35 sgallagh: currently yes. 13:57:04 Ok, that's notably different from our focus thus far, which has been on (re)configuration 13:57:13 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 sgallagh: How does this match with Katello and Puppet ? 13:57:56 kkaempf: Ongoing discussion, sometimes heated :) 13:58:08 I thought so. LOL. 13:58:16 Puppet we can coexist with. The technologies are good at different things. 13:58:26 Agreed 13:58:26 Puppet is good at saying "The configuration is *this*". 13:59:05 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 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 kkaempf: That would be nice if any of them ACTUALLY used the same models. 14:00:18 kkaempf: there is no _one_ data model 14:00:19 But I do get your point 14:01:12 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 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 In terms of actually changing configurations, I'm not sure if CIM is interoperable. 14:02:13 I have to leave in the next ~5mins 14:02:36 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 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 jsafrane: maybe, but it only covers HW. 14:03:28 yup, IPMI is HW only 14:04:05 Last question: Should I send patches to make openLMI work on SUSE to the mailing list ? 14:04:35 kkaempf: http://reviewboard-openlmi.rhcloud.com is our review site 14:05:10 sgallagh: So it get an account and push patches there ? 14:05:14 You can submit patches there either directly through the Web UI or by using the RBTools client package (recommended) 14:05:17 s/it/I/g 14:05:25 Ack, thanks 14:05:30 kkaempf: Ah right. I'll need to get you an account. 14:05:42 We're going to be migrating it to an OpenID-capable system soon. 14:05:50 Oh, you can self-register, actually 14:06:19 I'll do later today. Have to run to the next meeting now. Thanks a lot !! 14:06:29 kkaempf: Thanks very much for participating. 14:08:05 Thank you all for coming. Same time next week! 14:08:07 #endmeeting