16:00:53 #startmeeting Storyboard 16:00:54 Meeting started Mon Dec 22 16:00:53 2014 UTC and is due to finish in 60 minutes. The chair is krotscheck. Information about MeetBot at http://wiki.debian.org/MeetBot. 16:00:55 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:00:57 The meeting name has been set to 'storyboard' 16:01:42 o/ 16:01:48 hi everyone 16:01:53 Hi o/ 16:01:55 Agenda! 16:01:57 #link https://wiki.openstack.org/wiki/StoryBoard#Agenda 16:01:58 o/ 16:02:09 Actions from last week! 16:02:14 #topic Actions from last week 16:02:24 I have continued to pester fungi, but he appears to be immune to pestering. 16:03:05 rcarrillocruz: You’ve done a lot of work on the streaming API, with quite a bit of success. Can you give us a summary? 16:03:11 sure 16:03:15 #link https://review.openstack.org/#/c/143304/8 16:03:39 krotscheck: yeah, setuptools 8/pbr has more or less beaten several of us into submission for a week or so now 16:04:12 so, i had initially in mind using gevent-socketio, since socketio is cool in the sense that it downgrades automatically between various protocols if websocket is not supported 16:04:18 hi there 16:04:22 * NikitaKonovalov needs to look carefully at this change 16:04:26 websocket-> then it tries flash -> then something else 16:04:27 etc 16:04:41 but the problem is that gevent does not play well with pika 16:04:45 tornado does 16:04:55 so providing we already have pika in requirements, i opted to use tornado 16:05:03 please, no flash 16:05:14 * krotscheck has a love hate relationship with flash :D 16:05:35 with the change above, if you open a websocket to http://:8888/events , you get a websocket connected 16:05:43 then do a 'suscribe ' 16:05:54 and you start getting events piped to the websocket 16:06:25 this is a POC, the subscribe/unsubscribe format should be JSON and allow granularity on things to subscribe/unsubscribe, but you get the idea 16:06:37 i wanted to share if you think this is a good way to go forward 16:06:50 otherwise i could look to gevent or something like autobhan 16:07:03 those are the 3 framewors i've seen most mature for python websockets 16:07:14 rcarrillocruz: I dont see anything looking like an initial request object when setting up a connection 16:07:33 is there a way to access headers while establishing ws? 16:07:43 we might need those to check auth 16:07:48 yes 16:07:51 tornado allows all that 16:07:57 let me dig up 16:08:17 http://tornado.readthedocs.org/en/latest/guide/security.html 16:08:33 it has decorators to wrap functions to make them fail if there's no auth 16:08:38 it has stuff for OAuth 16:09:08 * NikitaKonovalov likes when a framework has all we need 16:09:14 Me too 16:09:15 ++ 16:09:22 seems pretty mature 16:09:48 So, from an intital look at the code this seems pretty readable. I haven’t stepped through the logic myself, but it feels like you’re on the right path. 16:09:49 it even has stuff for allowing multiprocessing, although i think we may want to put a LB in front and scale out tornado servers... 16:09:58 great 16:10:04 tornado is the one used or created by facebook , right? 16:10:13 yes, i think so yolanda 16:10:14 Is this something we can run concurrent on the same server? 16:10:46 yes, so the idea would be using http://httpd.apache.org/docs/2.4/mod/mod_proxy_wstunnel.html 16:11:11 to allow websocket pass thru apache running on the machine and pass those connections to the tornado server listening in 8888 or whichever port we put 16:11:11 Oh neat! 16:11:38 This suggests we don’t need to open up any new ports. 16:12:07 yeah, the idea is that apache would do his thing detecting is a websocket, then passing that to other internal port on localhost 16:12:19 Excellent! 16:12:21 haven't tested that yet, but it seems others do that thing with nginx or apache 16:12:38 i can work on that this week as well 16:13:00 Coooooool 16:13:17 Quick question for fungi: What’s the current thougths in infra on ansible vs. Puppet? Are we still doing all the puppet things? 16:13:40 * krotscheck thinks we are. 16:14:05 krotscheck: yep 16:14:10 yes, ansible is merely being used for orchestration 16:14:16 puppet is still used for configuration management 16:14:19 The reason I’m asking is that it may make sense for us to put a bit of time into our installation docs vis-a-vis single server to multi-server 16:14:44 Cool, I’ll add a story for that. 16:15:03 So, rcarrillocruz - things are looking good there, keep it up :) 16:15:21 Next topic: ctpollard isn’t here, on vacation. Postponing to the new year. 16:15:36 excellent, thx :-) 16:16:00 I didn’t get much done on the deferred processing engine docs, was working on the cron things instead. 16:16:25 krotscheck: can you elaborate on "The reason I'm asking is that it may make sense for us to put a bit of time into our installation docs vis-a-vis single server to multi-server" 16:16:26 Honestly I feel like I’m yak-shaving a bit. I submit a patch, someone makes a small comment that’s actually a ton of work. I submit another patch, same thing happens, etc etc. 16:16:30 krotscheck: i didn't quite follow that 16:17:34 jeblair: Storyboard is becoming a bit complicated as far as the install base goes. While it’s nice to have it running on one server for our own purposes, with downstream users starting to show up it may make sense to think about how we’d recommend separating services. 16:17:43 Sorry- not install base. Installed components. 16:18:47 jeblair: I don’t anticipate us needing it, but making sure that’s at the back of our brains as we put this together is starting to bug me. 16:19:26 jeblair: Any more questions on that? 16:19:26 krotscheck: yeah, should definitely keep it in mind. though i'm still comfortable saying that we should focus on getting it running for openstack first, and we should expect to be the largest installation of it for some time 16:19:30 nope 16:19:36 Coolio. 16:19:46 #topic User Feedback 16:19:49 Anyone hear anything? 16:20:01 niet 16:20:10 i think i've filed some stories about ui quirks 16:21:42 jeblair: Nice. Those are getting lost at the bottom of the queue though ebcause bigger effort items are at the top. 16:22:25 rcarrillocruz: [btw, i think etherpad-lite can support websockets. we should probably enable that apache module there not only because it's a good idea, but it'll also give us some more experience with it] 16:22:59 oh 16:23:06 sure, good idea 16:23:13 #action krotscheck Figure out how to surface recent things so that we can work on them. 16:23:14 krotscheck: yeah, that makes sense. i don't think any of them are critical 16:23:25 i'll work on a change for that 16:23:28 would make good little things to take a break from the bigger things ;) 16:23:51 jeblair: Yep. Believe me, there’s something about the dashboard that’s been bugging me for AGES and I really want to fix it. 16:24:03 I want to consolidate all changes to a specific story under one story header. 16:24:18 Like: In story X, foo happened, then bar happened, then fwiffo said something.... 16:24:20 maybe it improves etherpad latency, it has some issues for me sometimes... 16:24:50 krotscheck: in "recent events"? 16:25:01 yep 16:25:09 jeblair: Also, the fact that you can’t link through to comments. 16:25:27 i have no recent events right now, but i think i can imagine that and it sounds good :) 16:25:51 krotscheck, looks as a good idea to me 16:25:58 my recent events tab is messy 16:26:32 no kidding. I clicked 234 times on that close icon today 16:26:49 ttx: I know, right? 16:27:00 would it be a good idea to auto-remove some old recent events? 16:27:06 Also reading a comment and having to guess which story it belongs to is a fun game 16:27:13 o/ 16:27:30 especially when the comment is "that's the worst idea ever!" 16:27:40 :-) 16:27:54 can we also have a list of stories that a user is subscribed to? 16:28:09 NikitaKonovalov: Yeah, subscription management also seems like a sane thing. 16:29:35 #action krotscheck Add Subscription management and Update Recent Events UI as Stories. 16:29:42 Ok, moving on to urgent things 16:29:45 #topic Urgent Items 16:29:51 So updates on storyboard.o.o seem to be broken. 16:29:56 yes, we pinged fungi 16:30:09 looks as puppet was not running, he has submitted a change to fix it 16:30:17 Cool, is there a patch? 16:30:32 https://review.openstack.org/143474 16:30:36 i think fungi pushed something already 16:31:05 Ok, that was 8 mintues ago. 16:31:18 i still don't see new changes coming 16:31:42 Let’s keep an eye on http://puppetboard.openstack.org/node/storyboard.openstack.org 16:31:47 it will take minutes and minutes for that to go into effect 16:32:09 you might check http://puppetboard.openstack.org/ in a few more 16:32:26 Alright, so that’s well in hand. Moving on. 16:32:32 #topic Discussion topics: Branch Support 16:32:53 krotscheck: replied to your comment there 16:32:57 ttx! Seems like that spec’s in good shape, and we’ve already got a patch from aleksey against it! 16:33:43 #link https://review.openstack.org/#/c/143455/ 16:33:53 btw, Aleksey is a new developer @ Mirantis. He is dedicated to SB. 16:33:55 (Incidentally, who’s Aleksey?) 16:33:58 WOO 16:34:06 Where’s he located? 16:34:07 :) 16:34:14 krotscheck, next table to us :) 16:34:18 yep 16:34:21 Oh good. Pelt him with chocolate. 16:34:27 Or vodka 16:34:28 krotscheck, ok, i asked a question to Aleksey, because i only saw changes for git_repo 16:34:41 Oh wait. Wrong story 16:34:44 * krotscheck cannot read. 16:34:47 My apolgoies. 16:35:14 Anyway, back to the topic, I’m pretty comfortable with the branch spec, does anyoen else have any issues with it? 16:35:40 krotscheck: open question on the implementation side on whether we want to always assocaite tasks to branches (and use a default catch-all branch called 'master' in non-code cases), or allow NULL there 16:35:47 i'm ++ on it 16:36:03 I'd argue a default branch is simpler (NOT NULL) 16:36:27 but then I'd start treading into implementation too much 16:36:47 NULL looks good because it will allow to filter out tasks w/o branches and tell some to assign branches 16:37:03 the task with default branch can live unnoticed 16:37:04 Good point NikitaKonovalov 16:37:09 NikitaKonovalov: I'd argue there is no such thing as a task without branch 16:37:28 A task has a project and a branch 16:37:33 I don’t think the Win The Enterprise team has branches. 16:37:44 krotscheck: they have a single branch. 16:37:49 the default one. 16:38:12 and the UI hides it away from them, since there is a single branch, so nothing to choose there 16:38:13 Do they have a repository? 16:38:29 krotscheck: srsly we had that discussion already 16:38:44 I called it "area" so that you stop thinking about code branches 16:38:51 Right. 16:38:54 and then people complained that "area" was too vague 16:39:03 so I fixed it back to call it "branch" 16:39:12 but that may or may not represent a CODE branch 16:39:29 that's a branch of work in the project. If you only have use for one category, then just use the default one 16:39:59 so if WTE has no code and no branch, their work is always associated with the "default branch" 16:40:20 which I would call 'master' since that's what the default branch is called for code-backed repos 16:40:31 (but then, that's all written in the spec) 16:40:37 ttx, makes sense to me to always have a default branch 16:40:47 Right. I think it’s just a question of calling a duck a duck. If a project has code, it shoudl have a git repo and branches. And I’m ok with that being represented directly in the table. I also feel that work areas may be separate from cdoe themselves, and that that idea also has merit, but perhaps not right now. 16:40:50 * krotscheck yet. 16:41:25 i.e. I want both. 16:41:32 But right now we only care about code. 16:41:40 At least that’s the way I’m thinking about it. 16:41:45 krotscheck: couldn't they be reporesented with the very same construct ? 16:41:54 ttx: Should we overload the construct? 16:42:11 ttx: Or, better question: Can a project have both code and distinct work areas? 16:42:21 Say, security work on the icehouse branch? 16:42:57 krotscheck: I'd say no 16:43:17 That’s fair, and it’s orthogonal to the spec anyway. 16:43:21 tasks are unit of work. They result in a patch on a branch, or something else 16:44:00 so the branch/area thing is "where the work lands" 16:44:12 Plus, if at some point in time we choose to create distinct different concepts of area and branch, we have a way to select tasks that have a default branch that are not associated to a project that has code - ergo we could clear those later if we need to. 16:44:25 and we can allow a project to have its own default branch. Then it can be called whatever suits best. master for code repo, direction of work, etc 16:44:44 right 16:45:22 So I would answer my earlier question saying... all tasks must have a branch. 16:45:25 So I have no objections to default branches. 16:45:40 I’m ok with them not having a branch :) 16:46:08 Either way, we can move forward. 16:46:10 krotscheck: I'm not oK with that, because it creates an area where it's nobody's work to handle the task 16:46:22 same reason why i don't like stories without tasks 16:46:43 The migration script should create a default branch for each project then 16:47:47 project/branch combination uniquely defines which group is responsible for the task 16:47:53 project alone is not enough 16:48:24 ttx: You’re starting to conflate groups and code now. Do we have a spec for groups yet? 16:48:25 example: nova/stable-juno means the work is on backporters, and the stable liaison is ultimately resposnible 16:48:50 example: nova/master: work on regular devs, PTL ultimately responsible 16:49:17 krotscheck: not talking assignees here. I'm talking how people will use the thing 16:49:17 ttx: For every example there’s counterexamples, let’s focus on how we handle adding code repository references to our tasks, ok? 16:49:38 And on that topic, I feel we’re pretty well settled on the spec. 16:49:40 but right now each task is assigned to a project so, the set of default branch per project should be enough to start 16:49:51 NikitaKonovalov: ++ 16:50:31 and then let the people decide if they like the default branch or they want to change it immediately 16:50:36 Just saying people will add stories and tasks. and some group will pick them up. And that group is uniquely defined by the project/branch combination 16:50:56 not talking storyboard groups here) 16:51:01 just people using it 16:51:44 namaste, ttx. I totally understand your view of things. I disagree with some finer points, but you don’t have to convince me of the overall direction. 16:52:05 * ttx crawls back to his hole 16:52:16 Oh no you don't. 16:52:21 We need you out here. 16:52:26 * krotscheck drags ttx back out. 16:52:39 ouch ouch 16:53:38 We’re running out of time unfortunately. 16:54:11 So: Active Specs Branch Support. I heard a + from me, from NikitaKonovalov, from yolanda and from rcarrillocruz, and ttx authored it. 16:54:41 I don’t actually hear anyone disagreeing with this spec, so do we agree on moving forward with implementation? 16:54:52 * ttx will rebase the story types story on top of the branch/milestone specs 16:55:17 and will work on a milestone report spec, even if that's further away in implementation time 16:55:37 Speak now or forever hold your peace! 16:55:43 I mean rebase the story types *spec* on top of the branch/milestone specs 16:56:05 #agreed Mark https://review.openstack.org/#/c/139613 as ready for implementation 16:56:35 I’m going to skip over all the next things to switch to open discussion in case there are burning issues for the last few minutes. 16:56:41 +1 16:56:42 #topic Open Discussion 16:56:44 I’ve got nothing. 16:57:02 krotscheck, wanted to talk about preferences caching 16:57:16 but we can talk after the meeting, no time... 16:57:17 I've got base classes for python client covered with tests on review 16:57:18 yolanda: Yes I did! 16:57:26 now working on endpoints 16:57:31 yolanda: Aren’t you on vacation? 16:57:38 NikitaKonovalov: that makes me increidbly happy 16:57:40 i wanted to discuss tasks and how they map to gerrit changes? 16:57:44 yes, but i'm computer addicted :) 16:57:44 Users and Preferences are almost ready 16:57:58 Teams, Projects, Project groups coming next 16:58:04 NikitaKonovalov: Neat 16:58:12 NikitaKonovalov: awesome :-) 16:58:13 yolanda: GO ON VACATION, YOU HAVE FAMILY :D 16:58:25 :) 16:58:39 zaro: ttx: Sounds like tasks may need an adidtional field for patchset. 16:58:55 That feels like it’s related to branch support. 16:58:59 needs something. 16:59:27 stories to changes is not grandular enough IMO 16:59:36 zaro: Yeah, it should be tasks to changes. 16:59:55 so it also means task needs status transitions 17:00:12 zaro: We’re out of time, let’s take it into channel. 17:00:17 Thanks everyone! 17:00:19 basically IMO tasks needs to be the smallest unit in sB 17:00:29 #endmeeting