15:01:41 #startmeeting craton 15:01:43 Meeting started Mon Sep 26 15:01:41 2016 UTC and is due to finish in 60 minutes. The chair is jimbaker. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:01:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:01:47 The meeting name has been set to 'craton' 15:01:55 #topic rollcall 15:02:10 syed_, hi, hope you had a nice weekend 15:02:34 anything you need to ping me on? 15:02:46 jimbaker: hi, yes it was good, i hope you had a good weekend too 15:03:03 not really for now, trying to get the keystone thing fixed, since i need to get it going for horizon peoples 15:03:23 was able to get authentication from the server, but when i do the client api call, i get an error 15:03:23 there's beautiful fall foliage in the high country of colorado right now 15:04:23 ohh great 15:04:38 yeah fall is beautiful, i was in chicago over the weekends visiting my aunt ! 15:05:16 it was good to see the the colors of the aspen - mostly yellow - as well as other foliage against the first snow of the season, at around 3000m 15:05:47 woah, thats sounds really cool 15:05:55 but well, there is no fall in texas 15:06:01 haha 15:06:02 syed_, sounds good about keystone work 15:06:43 getting the middleware setup, plus dockerization of supporting services, is going to very helpful 15:07:16 yes it indeed will be, so i am trying to grasp as much as possible to get these things going asap 15:07:24 i guess the client side of code is going pretty well 15:07:28 we got hosts and regions up 15:07:32 cell is out there 15:07:37 then we will be left with variables 15:07:49 which i have briefly started taking a look into 15:08:26 syed_, yeah, first parts of var support should be easy, but absolutely essential 15:09:43 i saw reviews of ansible integration, they look good 15:10:11 syed_, that's an important part of the variable work as well 15:10:22 hmm .. 15:10:35 i'm glad we decided that we didn't need to do more substantive work on inventory modeling... 15:10:39 at least at this time 15:10:43 yeap 15:11:48 my work on the two level task scheduling is going to need for sulo to finish up on the parent hierarchy 15:12:17 (i might take that bit of code back from him at this point...) 15:12:32 syed_, on the client side with respect to variables 15:12:51 o/ 15:13:00 besides the ansible inventory endpoint, plus the json export script from ansible 15:13:09 sigmavirus, hi! 15:14:40 looks like a small meeting today, so we can use this to mostly discuss dev issues 15:14:56 +1 15:15:32 the only two admin/community things outstanding are 15:16:14 1. sigmavirus started the process of getting a logbot set up for #craton 15:16:24 s/two/few 15:17:06 2. we were able to finalize a time for tues dev meetings focused on the client & ecosystem at 1600 UTC 15:17:49 3. i have a talk tomorrow for the colorado openstack meetup - this will be a chance to get some warmup in for next month's talk in barcelona 15:18:43 4. last week we talked about pushing more community involvement, and i was going to write an email. haven't done that. but i will promote tomorrow; and will get to writing more emails 15:18:56 i think that's it 15:19:03 jovon, hi! 15:19:03 3- good luck for tomorrow jim, yes it will be great going for barcelona ! 15:20:05 syed_, thanks! i have some slides from jcannava, plus some other stuff. will focus on finalizing this pres today & tomorrow 15:20:38 #topic dev this week 15:21:41 oi! jim 15:21:42 sigmavirus, i guess this work for you continues to help shepherd through the cratonclient reviews, right? 15:23:18 while we wait for sigmavirus... jovon? 15:23:28 how are things going with you? 15:23:39 palendae, welcome 15:23:50 o/ 15:24:14 Thing are well thanks. Bug fixing as usual 15:25:03 jovon, are you planning to update the review in https://review.openstack.org/#/c/363171/ ? 15:26:31 just want to know where we are on that. maybe something smaller to start with? 15:26:34 yes. the merger of surveys patch must have slipped me 15:26:42 turvey* 15:27:18 it will take a simple edit of the index.rst and the patch will be completed 15:27:22 my apologie 15:27:40 jovon, no worries, i'm just trying to keep this review process managed. i let it go out of whack, don't want to repeat 15:28:45 right now, i think we are in good shape - sulo has no pending reviews, just an experiment + a review blocked on other work. so that's pretty good on the core side 15:29:32 and sigmavirus has been helping land chrisspencer's work 15:29:53 palendae, any help you need on reviews on the ansible integration side? 15:30:42 I have a few outstanding right now, but they're not directly related. I should have a couple this week 15:30:51 The export argument review merged 15:31:08 palendae, awesome to hear about that merge. please reach out when you are ready 15:31:26 i found the modeling discussion last week to be extremely helpful 15:31:43 Good 15:32:55 i will briefly mention what i have been looking at 15:33:49 first, i'm going to complete the api refactor, now that region_id vs region consistency issues have been addressed, since this was conflicting 15:34:21 this should remove a lot of boilerplate, and make it easier to get some other changes, like 204 for delete 15:34:38 (not so difficult now, but just more boilerplate to workaround) 15:35:36 second, my focus has been on the taskflow backend; and how to accommodate tracking more information, especially with respect to linking an overall taskgraph with a subtraskgraph 15:35:50 so divide work up to the cabinet level in one graph 15:36:14 and then do the actual workflow tasks against the cabinet in another graph 15:36:43 so i have worked out (most of) the modeling, and plan to implement this week 15:37:35 once that's in place, we can start hooking up some of the api stuff that sulo was exploring in https://review.openstack.org/#/c/355938/ 15:38:32 you've been busy. good work ! 15:38:35 so this will result in scalable, resumable workflows that are data center aware. all buzzwords will be checked off :) 15:38:56 jovon, thanks :) 15:39:33 syed_, any updates on your side? 15:39:39 well as i told 15:39:49 looking into client side variable things up 15:40:07 have installed docker locally, so working on functional testing 15:40:09 syed_, so planning on adding that to cratonclient support? 15:40:29 but for now i am trying to get the keystone thing done for horizon folks 15:40:31 so they can play with client, and now more things are out there, so that will be great for them 15:41:11 for now i am getting an understanding of what and how that works in craton, but mostly focusing towards getting docker-py working, 15:41:18 i am expecting keystone thing to be done by today eod 15:41:29 syed_, right sounds like the right priorities. 1. keystone; 2. functional testing; 3. variables 15:41:33 yes 15:42:37 with respect to variables, one thing that we need to figure out is how to rollup exceptional situations in the variables. this seems like a problem to be done in the core. and it needs to be extensible 15:42:54 Hmm .. 15:43:35 one thing that occurred to me is that we could use the virtualized variable model we have talked about, and use that here 15:44:17 so in a nutshell, variables have a resolution model that is built on https://docs.python.org/3/library/collections.html#collections.ChainMap 15:44:47 Ahh i see 15:44:49 (which in turn is modeled on how locals, globals are resolved in python) 15:45:49 the virtualized variable model is really simple here. we can install a PluginMap (which we write) in this ChainMap, which can do arbitrary things 15:46:32 this follows the CS adage that the solution to all problems is another level of indirection (except indirection itself...) 15:48:40 anyway... what if we had an ExceptionalPluginMap, which much like a generated column in a sql database, summarizes other variables? we can then ask it for the 'exceptions' key or whatever on a given host, and it looks at the reported variables for say osa-security 15:49:27 the only requirements for an ExceptionalPluginMap is that it supports the abstract class for a read-only python Map 15:49:54 anyway... just a thought here 15:49:58 Hmm 15:50:00 let me look into that 15:50:03 will come up with this 15:50:18 syed_, it's a fun problem to think about 15:50:44 indeed it is :) 15:51:14 the good thing is, you can indefinitely block to do any necessary lookups. the bad thing is, we still have to care about what that means for a client, so it's not quite right :) 15:51:56 but maybe it can be mostly right. anyway, something to think about 15:52:31 syed_, in looking at this - i would suggest the following 15:53:27 for this example: we have in the host variables the information captured from the osa-security role audit 15:53:38 okay 15:53:54 given those variables - what does it mean to rollup to "out-of-compliance" 15:54:19 Is Craton handling that logic? 15:54:39 I didn't think it was 15:54:42 palendae, so we have to handle that logic, or so i assume 15:54:57 but we cannot know in advance all possibilities 15:55:16 so that's why i want to generalize this as a plugin 15:55:50 Fair 15:56:03 palendae, but maybe audits from osa can have enough information on output that we can label accordinglu 15:56:16 sounds likes a good discussion for ansible integration :) 15:56:42 Yezah 15:57:10 I ask because my assumption would have been that Craton stores the information, than somthing external queries and decides on compliance 15:57:31 palendae, right - this is the rackspace public cloud model that we have adopted 15:57:57 we got a general variables model, guess what we can stuff it with whatever looks useful :) 15:58:12 Ok 15:58:21 the problem is, we want to hook it up to a console like horizon 15:58:35 but to do that, horizon doesn't know about compliance 15:58:55 so this originally external query needs to be pushed into craton core, without making it tightly coupled 15:59:47 time to wrap up 15:59:57 good follow on discussion on #craton 16:00:00 #endmeeting