17:00:12 #startmeeting craton 17:00:13 Meeting started Thu Mar 9 17:00:12 2017 UTC and is due to finish in 60 minutes. The chair is thomasem. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:16 The meeting name has been set to 'craton' 17:00:33 #chair sigmavirus sulo jimbaker thomasem 17:00:33 Current chairs: jimbaker sigmavirus sulo thomasem 17:00:33 #link https://etherpad.openstack.org/p/craton-meetings 17:00:33 #topic Roll Call 17:00:37 o/ 17:00:38 o/ 17:00:41 o/ 17:00:43 o/ 17:00:54 o/ 17:00:58 hi 17:01:13 hi 17:01:18 o/ 17:02:00 #topic Roadmap planning - email to openstack-dev [craton] 17:02:47 should we start with that? 17:02:54 It's on the list 17:03:23 i understand, but maybe consume our standing agenda first - namely standup/reviews 17:03:30 but it's ok, we can start here 17:03:39 Nah, i'm cool w/ that. The template needs to be updated 17:03:44 if we're wanting to do something different for this meeting. 17:03:49 #undo 17:03:50 Removing item from minutes: #topic Roadmap planning - email to openstack-dev [craton] 17:03:53 #topic Stand Up 17:04:26 #info each team member briefly describes what they are working on this week, and describes blockers (if there are any) 17:04:36 #topic Stand Up :: jimbaker 17:05:22 i have two changes to fix up, namely var search respecting resolution (will block thomasem's work since dependency); alembic schema 17:05:37 also some outstanding discussion re bootstrap 17:06:07 look forward to today's road map discussion, because we need to get that onto openstack-dev 17:06:18 +1 17:06:40 and we also have a forthcoming meeting by the openstack-operators in milan, which tojuvone needs our help prepping him for 17:06:50 (it's a team effort!) 17:06:53 dome 17:06:54 done 17:07:01 #topic Stand Up :: fsaad 17:08:25 think I'll pass, other than a constructive meeting yesterday to get the loading script approved for demo by sulo/tim, and get the ball rolling for the roadmap meeting tuesday 17:08:27 done 17:09:09 #topic Stand Up :: thomasem 17:10:12 Overcoming the nuances I run into as I'm continuing to work on JSON path-like variables querying and made a fair amount of progress, found there are some existing sqlalchemy functions that may help with this, namedly func.json_contains and func.json_extract; plugging away at code reviews, too; 17:10:42 done 17:10:47 #topic Stand Up :: antonym 17:11:53 sure, i've been poking around on craton a bit, mainly testing a use case for provisioning servers. been taking some stuff we did internal at rax for public cloud and porting it over to craton 17:12:26 https://github.com/antonym/plip <- takes variables from craton given an id and converts them into variables that can be populated into iPXE for scripting server boot 17:12:55 done 17:13:02 antonym, like to hear that experience report 17:13:09 +1 17:13:10 topic after standup? 17:13:22 #topic Stand Up :: sulo 17:13:23 sure we can catch up after 17:13:52 i am finishing up the patch adding bootstrap command to dbsync 17:14:09 will pick up something else from the milestone list after 17:14:10 done 17:14:19 #topic Stand Up :: git-harry 17:15:03 Patches are up for https://bugs.launchpad.net/craton/+bug/1666536 17:15:03 Launchpad bug 1666536 in craton "Cyclical hierarchies using parent_id" [Critical,In progress] - Assigned to git-harry (git-harry) 17:15:15 Now working on https://bugs.launchpad.net/craton/+bug/1665015 17:15:15 Launchpad bug 1665015 in craton "All text errors reported by the Craton REST API should be JSON encoded" [High,New] - Assigned to git-harry (git-harry) 17:15:15 done 17:15:39 #topic Stand Up :: tojuvone 17:15:59 Well I just worked the docker doc 17:16:15 and now would be interested to have the milan etherpad in shape 17:16:26 so that's a blocker for you 17:16:30 docker install 17:17:13 Wait, which is a blocker? 17:17:24 thomasem, milan etherpad 17:17:27 Gotcha 17:17:28 Okay, cool 17:17:41 but will be discussed momentarily as a separate topic... 17:17:42 Yes, to know what we like to shere there about Craton 17:17:47 yep 17:17:53 Sound good! 17:18:10 done 17:18:22 #topic Stand Up :: jovon 17:19:54 while I have investigated and experimented with several tools (beyond RAML) for simplified doc generation, most existing methods are not as comprehensive as manual generation especially for API documented in .rst format, which was a requirement of this study 17:21:06 jovon, cool, maybe we can explore in a forthcoming meeting? 17:21:22 sounds good 17:21:22 i suggest you put this on the agenda 17:21:39 +1 17:21:44 done 17:22:17 Cool. Ready to go into topics now? 17:22:24 yes 17:22:34 #topic Roadmap planning - email to openstack-dev [craton] 17:23:16 fsaad, git-harry, sulo - probably want to start with you on this 17:23:26 fsaad: I know we discussed this at length yesterday. Sounds like we're basically wanting to bring the idea to the group that we turn the Tuesday meeting into an alternation between retrospective and planning... 17:23:55 And start thinking about what we want to be when we grow up 17:24:04 that sounds good to me, with an additional 30 mins per email suggestion 17:24:18 30 min earlier sounds good 17:24:25 to better accommodate UK 17:24:30 +1 17:24:34 +1 17:24:37 and finland for that matter :) 17:24:51 +1 :) 17:25:12 I updated the etherpad accordingly 17:25:59 Not sure where else that needs to be updated? 17:26:00 the net of it seems: 1) figure out our high level goals. so cmdb for sure. but do need to integrate with workflows? (i believe we do...) 17:26:20 The question wasn't about integration, it was about whether they both belong in the same project. 17:26:31 s/project/repository/ 17:26:38 thomasem, ok. fair enough 17:27:13 so one possibility that i think may make sense is that the db aspects of workflows should be in the same project 17:27:34 but the specific worker implementation - celery? taskflow? - is pluggable 17:27:41 just throwing it out there 17:27:54 Lemme scare up some stuff here 17:27:55 fwiw - when we first started the project, we had it more decoupled than it is now 17:28:10 so just want to say there is some history here 17:28:10 What was the original reason for including workflows in the same repository as the craton API? 17:28:41 mostly because craton is not so big 17:28:52 Is there any technical reason? 17:28:52 and it's not clear to me we need to make this distinction 17:29:05 clearly we can always link 17:29:19 the major technical reason however 17:29:25 What I mean is, can the workflow engine utilize the Craton API? 17:29:26 is that we want our models to be shared 17:29:30 Ah 17:29:37 So, why's that necessary? 17:29:53 because simplicity. not necessity 17:29:54 What if the workflow engine was a client of the Craton API? 17:30:17 thomasem, so the engine itself, yes 17:30:38 We seem to be discussing specific roadmap items, was that the purpose of this topic? 17:30:55 think that's what the tue meeting is for :) 17:30:57 git-harry: you're correct, we can punt this discussion to that. 17:30:59 the question is, are there supporting model aspects, such as how rbac works, where it would be simpler to have a workflow model in the same model as users, the things that the workflow is for 17:31:14 i certainly agree here! 17:31:19 with git-harry and fsaad 17:31:26 So I still believe that we (Rackspace employees) need to be pushing for a roadmap that advances Rackspace goals. Until we have that internal discussion, I don't believe we can effectively (from the perspective of Rackspace) guide the direction of the project. 17:31:33 Okay. Let's table this for a more involved discussion of roadmap items. 17:31:58 git-harry, well sulo and i are technically part of OSIC 17:32:07 (I am, too) 17:32:11 and tojuvone is at nokia 17:32:13 works. Like I mentioned my intent is to gather consensus on the end goal so that we can break apart in pieces needed to get us there 17:32:13 (I found out) 17:32:20 cool 17:32:28 so we have to put on our upstream hats :) 17:32:46 that rackspace is the first customer, this is awesome 17:33:10 of course we are going to work very closely with our customers. everyone should expect that 17:34:01 and i think the biggest prioritization we see is cmdb 17:34:10 guess what, this is the most important thing for nokia too. win win! 17:34:29 o/ 17:34:31 I just spoke today with Vitrage, and they should be happy to have notifications from Craton. 17:34:45 and notifications are essential for rackspace too 17:34:50 Also putting up feature where Craton coudl update something on Nova 17:35:11 and webhooks on the rackspace side, which is we can implement 17:35:18 *how we can* 17:35:27 ^^ fits under workflow engine umbrella, btw. 17:35:35 at least that's my opinion :) 17:35:38 yes, workflow + notif 17:35:39 Sulochan Acharya proposed openstack/craton master: Adds project/user bootstrap command to dbsync https://review.openstack.org/443170 17:36:10 and namespace 17:36:11 thomasem, fwiw not as we originally envisioned. but highly open to other ways to get there 17:36:22 sulo: yay 17:36:46 Alright, so these are things that we need to collect and get into, say, Story Board. 17:37:02 antonym: heh, hopefully that will help a bit :) 17:37:03 thomasem, everything here is in a blueprint or bug 17:37:09 Okay, good. 17:37:18 but yes, moving to storyboard will help highlight it much better 17:37:23 and needs to be done regardless 17:38:06 Alright. So, what did we want to get out of discussing this topic today? 17:38:09 and especially capture details like, yes we need notifications. but let's link to a specific way to implement 17:38:45 I think a 10k foot view of the goal was a good start but I learned that's going to be more involved than I thought. 17:38:57 thomasem, i think the key thing for us is to bring this up so we can start thinking about 1) that email to openstack-dev; 2) corresponding planning during tues meeting 17:39:03 fsaad, hah, yes 17:39:11 so, seems like we at least got the time and recurrency of it mostly OK'd, every tuesday, half hour earlier 17:39:19 Yep 17:39:21 and do sprint plan one week and retrospective the next ? 17:39:24 fsaad, not every tues 17:39:30 just next week's meeting 17:39:53 i think we are good with the slot time for now, until we find otherwise 17:40:02 jimbaker: Ah... so the proposal was for changing the purpose of that meeting, since it's really become more of an extension of Monday's meeting, really. 17:40:14 same 17:40:19 thomasem, it has become an extension of monday's meeting 17:40:27 so backing up 17:40:56 originally we had tues & thurs meetings that were dev focused; monday was to be focused on the wider community 17:41:07 communicate with them, here's what we are doing 17:41:24 except it turned out that only the devs were showing up for monday's meeting. so we repurposed accordingly 17:41:38 hosts/id/variables doesn't do pagination right? 17:41:45 just giant wall of text 17:41:54 pwnall1337, no pagination, correct 17:41:58 thanks 17:42:25 jimbaker: Okay, so, are you against us changing the purpose to planning/retro alternating? 17:42:29 to be honest, i think the monday meeting works well 17:42:47 thomasem, for tues, i think it works to look at planning/retrospective 17:43:01 i just don't expect it to take 90 minutes every single tues that's all 17:43:19 We could just keep it at an hour and increase if we find it's not enough? 17:43:24 cool we can kick jokes and drink coffee for the remaining for team bonding 17:43:27 but we have built up quite a backlog 17:43:32 I mean, cut it short and get back to work 17:43:35 :P 17:43:49 lol fsaad 17:44:10 start early, add that 30 min and end early if needed 17:44:22 it does not work well for UK folks to extend 17:44:30 sulo, correct 17:44:31 if we ever have to do that 17:44:45 so i don't think we need to do extend. except next tues 17:45:06 and we are extending early of course :) 17:45:24 yeah, i agree .. i dont think it will take that long every tues 17:45:50 so let's see. we can always revisit. but next tues starts 30 min early 17:46:01 I'm personally fine with either. I imagine we'll adjust as needed. 17:46:26 is this open discussion 17:46:28 also lemme know if I need to do anything with the storyboard, I hopped on yesterday and seems I can create a new board but I'm not sure that's what we need 17:46:41 sulo, we somehow drifted here 17:46:47 But, there is a need for planning/retro on a regular basis since we're getting into a more formal process for developing according to a roadmap. 17:46:52 we were discussing openstack-dev email 17:46:58 And this allows us to not add on additional meetings 17:46:59 thomasem: agreed 17:47:00 re roadmap 17:47:12 and i think the point is: that's tuesday 17:47:16 yep 17:47:17 did we decide to sprint or is that up for discussion next meeting 17:47:31 It'll resemble sprints, sans story points (I hope). 17:47:35 sulo, so we were discussing yesterday 17:47:45 yeah, no need for story points 17:48:00 but the net of it was, two week iterations 17:48:25 we will see if that's workable or not for this project. but it's more of a question of 2 weeks, or longer; not shorter 17:48:44 i don't think any of our tasks are adjust the web interface type of stuff 17:49:03 I'd vote for more of a kanban based approach, I don't know if storyboard supports it. 17:49:32 well it is a board... 17:49:43 git-harry: +1, I am hoping the planning is simply for us to prioritize things regularly. 17:50:02 interestingly it's possible to support multiple board views, which hopefully can help us look at stuff from a customer perspective 17:50:24 not to mention integration with say what rackspace is doing via supposedly an easy to use API 17:50:34 so, how about we go the Kanban route and use planning/retro just as regular checkpoints to be sure things are prioritized and we're continuously improving our process 17:50:34 (but has to be better than the LP API) 17:50:51 so thomasem git-harry jimbaker fsaad do we need to decide on kanban sprint somethingelse ? 17:51:15 combo of 17:51:16 not right now, I'll get my learn on kanban cause I've only done pseudo sprints (no points) 17:51:21 thomasem, yeah, i think that's the combo approach right 17:51:28 then can probably have more educated conversation 17:51:38 jimbaker: I guess? Agile's pretty bastardized these days. 17:51:40 true sprints have everything aligned on two week iterations 17:51:47 or something. i don't know 17:52:10 I think we'll just start with the raw clay and mold what we want as we go 17:52:15 This sounds like a good starting point. 17:52:19 whereas we will likely do the bastardized approach. the raw clay in other words 17:52:40 As long as the process works for us and not the other way around, we should be okay. 17:53:01 personally i think what we have been doing is pretty good. we just need more roadmap clarity. and more roadmap adjustment. hence the two week retro/planning 17:53:04 Who will draft up the e-mail to openstack-dev? 17:53:07 right, so are we doign to discuss that tues too ? 17:53:33 thomasem, i suggest we start with fsaad's email thread, and edit accordingly. most important 17:53:43 it must link against our corresponding blueprints 17:53:56 even better: what if it did this against storyboard? ... 17:53:58 win! 17:54:17 from a public relations perspective 17:54:18 We only have 6 minutes for remaining topics. :\ 17:54:19 are we discussing what our process is next tuesday too ?? 17:54:21 fsaad: ^^ 17:54:27 sulo, absolutely 17:54:30 hence extra time 17:54:40 lets make sure we have enough time for that + discussing priority work 17:54:43 but we should be prepped to do so 17:55:00 well, collation of items from thread is a starting point 17:55:02 again tues is better. mon morning is rough to have a planned agenda 17:55:20 so this repurposing is much more realistic 17:55:25 discussion of them I mean, and write up a draft of what we want to see as end game 17:55:37 I agree we should have an agenda to keep focus 17:56:06 Sounds good. Can we take the rest of this into #craton after this meeting so we can get to tojuvone's topic? 17:56:08 so basically this meeting, plus the current emai threadl - should be a good start 17:56:17 thomasem, +1 17:56:31 #topic Upcoming meeting in Milan (March 15/16) - need to craft agenda/talking points for https://etherpad.openstack.org/p/MIL-ops-inventory-and-fleet-management 17:56:32 cool, need to step away but will catch up in a bit, thanks guys 17:56:34 tojuvone: take it away 17:56:38 fsaad: cheers! 17:57:26 i can also discuss - this is effectively the same thing as the email, plus what we have done so far (which would be a great thing to include in that email) 17:57:49 but in the context of engaging with our previous meeting at the op summit in nyc 17:57:55 + barcelona 17:58:10 we need to take concrete use cases 17:58:30 such as maintenance mgmt, and describe mapping to craton 17:58:47 another good example: antonym's work on plip 17:59:01 and of course the use cases we have been recently working through, and corresponding demo 17:59:12 I will have the maintenance MIL-ops-telco-nfv 17:59:55 tojuvone volunteered to lead this session on behalf of craton, since he will be in milan. but we need to fully support him 18:00:56 thomasem, we are over our time limit... 18:01:19 Yep 18:01:27 so what we want to share there. Some current status, roadmap 18:01:27 anyway, let me conclude: let's just all look at the etherpad 18:01:35 Lol yeah 18:01:39 #endmeeting