15:15:45 <jimbaker> #startmeeting craton
15:15:45 <openstack> Meeting started Mon Jun 13 15:15:45 2016 UTC and is due to finish in 60 minutes.  The chair is jimbaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:15:46 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:15:48 <openstack> The meeting name has been set to 'craton'
15:15:51 <apuimedo> I wonder why it didn't work
15:15:56 <apuimedo> sorry about that
15:16:01 <hvprash> we should create a crato-specs git
15:16:02 <jimbaker> apuimedo, no worries
15:16:09 <hvprash> *craton-specs
15:16:11 <sulo> hvprash: yeah that sound fine
15:16:26 <jimbaker> hvprash, to be honest, i'm always worried about splitting stuff up
15:16:26 <b3rnard0> sulo: i know sigmavirus24 wanted us to consider storyboard instead of lp. i put myself on that task to see if we should go down the storyboard route
15:16:46 <sulo> b3rnard0: ok
15:17:02 <jimbaker> so i really like the idea of capturing specs in git
15:17:04 <sarob> Launchpad is simple but it works
15:17:20 <sulo> either ways ... we should track the new work either in git or lp or storyboard
15:17:23 <sarob> Jimbaker: me too
15:17:26 <jimbaker> what we can do is this workflow for such specs: blueprint -> git
15:17:37 <sarob> +1
15:17:40 <cmspence> +1
15:18:11 <jimbaker> then put the finalized specs in docs/source under git, so it gets built as part of the docset
15:18:24 <jimbaker> at some point, our docset may become too big. i don't see this as a problem yet ;)
15:18:47 <sarob> Jimbaker: good prob to have
15:19:21 <sarob> Btw, I pushed the agenda to https://wiki.openstack.org/wiki/Meetings/craton
15:19:21 <jimbaker> exactly. when we have that problem, we can work it. until then, one place to go for people who want to know what craton is trying to do, and does, makes sense
15:19:42 <jimbaker> sarob, yeah, that was super helpful
15:19:49 <sarob> Cool
15:20:46 <jimbaker> ok, i think we can close discussion of topic 63 out for this meeting - we are going to come up with some docs in blueprints about requirements, and integration patterns
15:21:12 <sarob> #action sarob push infra patch to move repo into OpenStack org this week
15:21:15 <jimbaker> #action jimbaker begin doc of craton inventory integration patterns in blueprints
15:21:48 <sarob> Jimbaker: I think you need to post my action as chair
15:22:26 <jimbaker> #action antongribok doc requirements for https://github.com/rackerlabs/craton/issues/63
15:22:35 <jimbaker> #action sarob push infra patch to move repo into OpenStack org this week
15:22:43 <sarob> Thx
15:22:45 <jimbaker> ok, that completes those actions we agreed on
15:22:50 <jimbaker> last topic
15:23:12 <jimbaker> #topic review outstanding issues
15:23:24 <jimbaker> specifically "MVP" issues
15:23:36 <jimbaker> https://waffle.io/rackerlabs/craton?milestone=MVP
15:23:51 <jimbaker> so lots of progress in the last week or so
15:24:03 <jimbaker> sulo, what's the status of osic ingest?
15:24:19 <sulo> mostly done
15:24:30 <jimbaker> awesome
15:24:55 <sulo> its something specific to rackspace and it just a script writing into the inventory
15:24:56 <jimbaker> one thing that came in the dev meeting a week back or so, i believe gus mentioned it
15:25:17 <jimbaker> is that we want to use this as a model for a scalable test fleet
15:25:40 <jimbaker> so 10, 100, 1000, 10000 hosts, etc
15:25:55 <jimbaker> that we can programmatically build up and test our assumptions
15:26:50 <jimbaker> in particular, we need to do this to verify our assumptions about database modeling, and corresponding performance
15:27:02 <jimbaker> this sounds like a blueprint to me
15:27:54 <jimbaker> not hearing any disagreement, i will put that as an action
15:28:31 <jimbaker> #action jimbaker open blueprint re scalable test fleet that is programmatically built, using osic as a model
15:29:20 <jimbaker> remaining inventory MVP issues:  resolved variables and ansible inventory
15:30:26 <jimbaker> resolved variables is basically done at the python api level, including testing; however we need to expose to REST users. that will be a separate PR from me
15:30:56 <jimbaker> ansible inventory is the last real issue. i will be working on that this week, in conjunction with sigmavirus24
15:31:05 * sigmavirus24 nods
15:31:31 <jimbaker> sarob, do we have a 30 min slot, or full 1 hour?
15:31:57 <rainya> jimbaker, the wiki says full hour
15:32:19 <jimbaker> rainya, ack. advantage of having a holiday, then vacation day for me... :)
15:32:35 <sarob> Hour
15:33:32 <jimbaker> so this is the week we are trying to pull the current inventory work all together, so we can demo what can be done
15:34:05 <jimbaker> the core dev team will be having a vidyo meeting later today to discuss
15:35:03 <jimbaker> but in a nutshell, the concepts described in http://craton.readthedocs.io/en/latest/high-level-design.html#concepts, unless marked as WIP, are now implemented
15:35:14 <sarob> I would like to discuss forking part of OneOps for our uses
15:35:24 <jimbaker> sarob, sounds like a great topic
15:35:29 <jimbaker> #topic oneops
15:35:38 <sarob> Specifically the CMS parts
15:35:57 <sarob> VitaliyZ has joined us from the OneOps team
15:36:50 <sarob> Vitaliy can you give us the run down of what the CMS is
15:36:54 <jimbaker> +1
15:36:56 <sarob> VitaliyZ
15:37:03 <sarob> That is
15:37:17 <VitaliyZ> so CMS is oneops configurations management systems
15:37:41 <VitaliyZ> which is basically generic object oriented db design
15:37:53 <VitaliyZ> generic classes and relations between them
15:38:07 <VitaliyZ> we use it in OneOps to model every aspect of the system
15:38:43 <jimbaker> (some discussion of overall oneops arch: http://oneops.github.io/admin/key-concepts/)
15:38:53 <VitaliyZ> so for Inventory management we can use this part of OneOps - DB schema + API + Elastic Search integration to model/manage hw components
15:39:06 <jimbaker> (example DDL for schema: https://github.com/oneops/db-schema/blob/master/db/kloopzcm-tables.ddl)
15:39:57 <VitaliyZ> it's way more generic then what I can see at https://github.com/rackerlabs/craton/blob/master/doc/source/img/schema.svg
15:40:31 <VitaliyZ> We don't want to create a table per configuration item, this will kill you in the future
15:40:32 <jimbaker> VitaliyZ, correct, we have intentionally not made the craton inventory generic, because we assume integration with rackspace core, openops cmdb, etc
15:41:34 <VitaliyZ> integration on what level? API?
15:42:16 <jimbaker> VitaliyZ, although we have a fair amount of flexibility in sqlalchemy in terms of adding object oriented modeling. so we did this for host < device inheritance
15:42:56 <jimbaker> VitaliyZ, so this is the integration patterns blueprint i mentioned earlier as an action item i will do this week
15:43:38 <jimbaker> after looking at oneops cmdb, it seemed that one possible integration point was via sqlalchemy's support for object mappers
15:44:02 <jimbaker> it's very similar to the capabilities seen in mybatis
15:44:09 <VitaliyZ> We went through this strongly typed approach back at eBay where each Configuration Item had corresponding java class - not scalable
15:44:43 <VitaliyZ> if every time you  change your model you need to do a code release - not worky
15:45:31 <jimbaker> VitaliyZ, i understand this concern. i have seen similar approaches for other cmdb's
15:45:41 <jimbaker> everything is modeled explicitly, etc
15:46:05 <jimbaker> we actually are trying to avoid doing this with our model, which is based on what has scaled at rackspace
15:46:47 <VitaliyZ> We went through this, and oneops model works perfectly at Walmart scale
15:48:18 <sarob> So how about I create a bp
15:48:22 <jimbaker> VitaliyZ, what i think makes sense is to use a sqlalchemy object mapper to integrate oneops CIs against corresponding devices
15:48:32 <sarob> On forking CMS for craton
15:48:43 <jimbaker> sarob, sounds like a good action item
15:48:59 <sarob> I'm all about the action items
15:49:05 * sarob )
15:49:08 <jimbaker> #action sarob creates bp on forking oneops CMS for craton
15:49:09 <jimbaker> :)
15:49:51 <sulo> maybe a session on how oneops is managing these items .. i.e. how devices are modeled how configuration is modeled etc might help too
15:49:58 <jimbaker> sarob, VitaliyZ - to me this is one of the most interesting questions we have here: how can we combine efforts here
15:50:42 * sarob wondertwin powers in the form of inventory
15:50:43 <jimbaker> the concepts doc references oneops for its support of governance workflows, which i think are going to be an amazing integration point for users
15:50:47 <sulo> by looking at db-schema it looks like configuratin items encompasses more in oneops model than how we have don it so far
15:50:58 <sulo> i would love to understand hat modeling better
15:51:13 <jimbaker> sulo, exactly. and agreed - we need to have that discussion
15:51:46 <jimbaker> #action b3rnard0 organize a vidyo meeting to discuss specifics
15:51:51 <sarob> Can we make sure that any side meetings get their highlights dumped into the Amal?
15:51:55 <sarob> Serv
15:52:09 <sarob> Mailing list that is
15:52:17 <jimbaker> sarob, nice typo
15:52:20 <sarob> Spell check angry
15:52:44 <jimbaker> sarob, i think it could make for an interesting project name...
15:53:05 <jimbaker> sarob, yeah, that's an extremely important point. we will do this going forward
15:53:09 <sarob> My mistakes are golden
15:53:30 <jimbaker> #action jimbaker dev discussions should be summarized on mailing list
15:54:02 <sarob> That's one of the things the TC looks at
15:54:11 <sarob> Public discussions
15:54:13 <jimbaker> sarob, exactly. we need to do a better job here
15:54:25 <jimbaker> but easy enough to do as well
15:54:34 <sarob> Habit
15:54:57 <sarob> Painful openness
15:55:01 <jimbaker> reminders can help establish, or break, habits
15:55:02 <sulo> VitaliyZ: is the cms modeling sitting on top of a separate device model ?
15:55:26 <sarob> Time check 5 mi
15:55:31 <jimbaker> sulo, i started with https://github.com/oneops/db-schema/blob/master/db/kloopzcm-tables.ddl, and related ddl
15:55:33 <sarob> Min
15:55:57 <jimbaker> sulo, but we are going to have a meeting with VitaliyZ to discuss specifics
15:55:58 <VitaliyZ> sulo Not sure I understand what device model you are talking about
15:56:14 <jimbaker> sulo, this is component instances (CIs)
15:56:21 <sulo> sounds good re: meeting
15:56:31 <jimbaker> in oneops - they are more detailed than our device model
15:56:34 <VitaliyZ> I'm going to push to github pdf with schema design in a few mins - would be easier to grasp
15:56:40 <jimbaker> VitaliyZ, awesome
15:57:05 <jimbaker> #action VitaliyZ publishes oneops schema
15:57:15 <jimbaker> any other topics?
15:57:20 <jimbaker> 2.5 minutes left
15:57:21 <sarob> I'm good
15:57:27 <sulo> VitaliyZ: https://github.com/oneops/db-schema/blob/master/db/kloopzcm-tables.ddl seems to be managing state ? so the state for which this is managed is separate ?
15:58:02 <sulo> anyway lets have this discussion later.. this seems like a very useful and important integration point
15:58:05 <jimbaker> sulo, VitaliyZ - let's take this over to #craton so we can wrap up
15:58:13 <jimbaker> sulo, agreed
15:58:24 <jimbaker> thanks everyone!
15:58:26 <sarob> I've gots to jump to another gathering
15:58:28 <jimbaker> #endmeeting