14:31:07 #startmeeting Craton 14:31:08 Meeting started Mon May 23 14:31:07 2016 UTC and is due to finish in 60 minutes. The chair is jimbaker. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:31:10 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:31:13 The meeting name has been set to 'craton' 14:31:27 #topic Craton stakeholders 14:34:08 hi everyone. just wanted to kick off this initial meeting on irc for craton 14:34:36 b3rnard0, o/ 14:35:05 jimbaker: \o/ 14:35:26 (i'm currently also on the vidyo channel, in case we didn't communicate this well enough. which we probably didn't!) 14:36:44 one disadvantage of a shared meeting channel like this is that it's rather hard to figure out who is here specifically for this meeting 14:37:11 jimbaker: i think we may have this time slot for another meeting 14:37:16 anyway, if you are here for craton, please do the usual o/ 14:37:33 banix, ahhh... 14:37:44 don’t see your meeting here: http://eavesdrop.openstack.org/ 14:38:03 banix, no worries, we must have a communication mixup 14:38:07 we meet here in this time slot for one hour but today finished in half hour 14:38:17 sure just wanted to let you know 14:39:17 banix, got it. so i guess we at least can take your slot for the remaining half hour? 14:39:26 yes of course 14:39:26 for 20 min... 14:39:44 banix, awesome. we will do just that, and figure it out for next time 14:39:54 sounds good. 14:40:16 jcannava, o/ 14:41:10 sulo, any updates on the ceph modeling you were looking into? 14:41:56 no real progress ... we need hvprash_ etc to give some input there 14:42:36 sulo, ack. just wanted to better understand drivers there. at this point i think we have the underlying modeling support for inventory 14:42:40 ideally even drive that ... but i am happy to pick it up once we know what we are need etc 14:42:42 * sigmavirus24 lurks 14:43:44 sulo, Anton from my team is working on it 14:43:53 sulo, the related question we had from last time was connecting physical inventory to virtualized services 14:43:55 hvprash_: hi, cool 14:43:56 he is putting together our reqs 14:44:09 hvprash_, fantastic, that's going to really help 14:44:12 hvprash_: yeah that will help a lot 14:44:31 hvprash_: feel free to drive that really .. i do have some info from same team at rackspace 14:44:34 sure, we need that :) 14:45:18 ill get some req's populated on that doc 14:45:45 #action hvprash is driving requirements for ceph (and presumably storage in general) modeling based on needs at walmart 14:46:01 hvprash_, agreed on that? 14:46:06 sounds good 14:46:22 * jimbaker has not used meetbot for a while, so working on fluency here :) 14:46:45 jimbaker: so what was the concern re: physical to virtualized services ? 14:46:57 sulo, this is rainya's question from the last meeting 14:47:20 ah right ... i think we have that mostly covered 14:47:38 so the model will be that we use labels along with variables to drive that 14:47:48 i think there are three key concerns that we got about inventory: 1. being able to model devices that are not directly addressable by tooling like ansible 14:48:12 so #1 is hopefully being addressed with the new device support, and we will validate against hvprash_'s reqs 14:48:52 2. being able to map to virtualization. and yes, hopefully we can use labels for that 14:50:13 sulo, i think the key thing here is just to detail how we could write tooling to make that connection with nova. we have discussed a couple of times, i think we are covered 14:50:48 yeah, and whats the 3rd ? 14:50:52 3. integration with existing asset databases, such as the oneops cmdb or rackspace cmdb 14:51:29 presumably if we can get integrations with both, we are good in terms of this aspect of our modeling 14:51:41 so 3) would be purely through rest api ? 14:52:04 so hopefull that should work for any external system 14:52:26 sulo, in some cases, it will be through rest api. but indirectly 14:53:16 i believe the consensus at the summit was that we would do the integration at the python object model level 14:54:07 oh, wont that be difficult given we wont know what other cmdb systems look like ? 14:54:09 so let's say we have oneops, which is modeled with postgres (and to the rest of oneops, via ibatis. but that's not so interesting here) 14:55:20 we can integrate with its component instance (CI) model by writing an object mapper (using sqlalchemy) such that it joins with device 14:56:09 sulo, alternatively we can integrate with an existing rest object model by building python object models of the external cmdb 14:56:33 i think REST API will be better as it will be more generic and integration with other platforms too 14:57:12 hvprash_, we are providing a rest api, which goes against this object model 14:57:38 ah ok, got it 14:58:40 our first iteration was that we were going to do everything internally in a rest api. but that's more work 14:58:50 jimbaker: perhaps we need an example to visualize how this works, maybe action item for next time ? 14:58:51 externally, yes, rest api. also the client will use that rest api 14:58:57 sulo, yep, i think so 14:59:10 like a class diagram ? 14:59:31 #action jimbaker describe integration with external rest api-based cmdb (such as rackspace core) 15:00:08 hvprash_, we are going to have end this meeting momentarily. apparently we only got 30 minutes today 15:00:14 at least here in this channel 15:00:27 ok 15:00:38 but we can move over this discussion to #craton now 15:00:46 agree, thx 15:01:06 #endmeeting