14:59:46 #startmeeting storyboard 14:59:47 Meeting started Mon Jul 21 14:59:46 2014 UTC and is due to finish in 60 minutes. The chair is krotscheck. Information about MeetBot at http://wiki.debian.org/MeetBot. 14:59:48 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 14:59:50 The meeting name has been set to 'storyboard' 14:59:56 Roll call! 15:00:01 o/ 15:00:04 Sourdough 15:00:34 #topic Urgent Items: MySQL 15:00:48 ok 15:01:01 I think we both know what’s up. What do we do about it? 15:01:06 mordred’s input would be useful. 15:01:29 good news is that rackspace now is able to create a 5.6 db 15:01:51 so we could somehow migrate all the data on s.o.o 15:01:53 mordred: We’d like to do a simple fulltext search for the time being on storyboard. Unfortunately, that’s only a MyISAM thing until MySQL 5.6. 15:02:16 the bigger challenge is enabling 5.6 for tests 15:02:48 Ugh. 15:03:11 What’s the version that the ubuntu trusty infra instances is running? 15:03:27 The installation scripts set up a default mysq-server package which is 5.5 15:04:23 * krotscheck is doublechecking the version in which mysql learned Innodb fulltext indexes. 15:04:24 the most likely solution will require a new job which will install mysql-server-5.6 package, and set up all users and databases again 15:04:35 krotscheck: it's 5.6 15:04:39 Ugh. 15:05:15 Ok, the alternatives are… Use MyISAM, Manually upgrade jenkins during build, or not use fulltext? 15:06:03 MyISAM is will not work with SqlAlchemy, as there are no transactions 15:06:13 Ok, so that’s not an option. 15:06:40 we have no sudo during the job execution on jenkis, so there is no way to install a package 15:06:56 Well, we can pull that out of the build script. 15:06:58 the only way to get 5.6 on a slave is install it during puppet setup 15:07:12 And nobody in infra is going to let us do that. 15:07:46 heat is not working with 5.6 15:07:52 and may be something else 15:08:33 so, do we really need fulltext? 15:08:58 Maybe not? 15:09:22 WEll, there’s the whole “Hey what is out there” use case. 15:09:38 But the current LIKE based search approximates a solution to that, it’s just not optimal. 15:09:49 krotscheck: /me has other ideas on innodb fulltext ... but is about to land in a plane ... will follow up 15:10:02 mordred: Have fun in portland :-P 15:10:06 krotscheck: you know it! 15:10:24 krotscheck: (other ideas re: jenkins ... installing 5.6 seems like a fine idea in production) 15:11:47 So, I think we can table the fulltext question until mordred’s plane lands. 15:11:57 Since we’ve got something that sortof works. 15:12:06 * mordred will come back with science 15:12:24 NikitaKonovalov: Thoughts? 15:13:00 we may disable full-text related stuff while testing 15:13:24 Let’s do that. 15:13:46 Not optimal, but if we can just flip a switch and turn them back on once the DB version is up to date, that would make things nice and simple. 15:14:06 looks like a best idea for now 15:14:25 ALrightey 15:14:37 #topic Discussion: Unstable Build & NPM Mirror 15:14:53 So, turns out the build issues we had last week were cause dby two things. 15:15:05 1- NPM was unreliable, a fact that was compounded by .... 15:15:17 2- a bug in bower that caused an unreliable NPM to make things blow up. 15:15:34 Upgrading bower seems to have gotten us back to a happy place. 15:16:12 And my work on the NPM mirror is here, at the suggestion of nibalizer: https://github.com/krotscheck/puppet-npm_mirror 15:16:43 We don’t have a 100% solution, but th ebower upgrade seems to have fixed us. 15:16:55 #topic SubResource PUT/Delete response 15:17:26 How do we want to handle the HTTP response of PUT /resource/ID/subresource/ID? 15:17:29 (or of DELETE) 15:17:56 The current way returns the full array of subresources after modification. 15:18:38 I guess the options are: return nothing, leave as is, return a deleted object 15:18:38 Which feels not-RESTy, but really I just want to be consistent. 15:19:16 And right now we have two implementations, one which I did because it annoyed angular. 15:19:45 But that’s a client thing. Assumign that we have _no_ client application, what makes the most sense? 15:20:14 * krotscheck thinks it should either be nothing, or the instance of the subresource that was linked, but not an array. 15:20:25 An empty body makes sense for delete operation 15:20:46 as for PUT, I'd prefer a modified subresource 15:21:27 … subresource as in a reference to the linking resource (the join table?) or the actual resource that was linked (Say a project for project-groups)? 15:22:07 the second option 15:22:16 That works for me. 15:22:27 204 makes sense as well. 15:22:31 agree 15:22:38 Excellent, 15:23:10 #agreed Linked Subresource PUT responses should return an instance of the linked subresource. DELETE should return empty body with a HTTP 204 15:23:21 * krotscheck thinks that’s the correct command 15:23:41 #topic HTTP Signature for Subscriptions 15:24:07 I have tons of questions about what the /subscriptions API should look like. There’s tons of options, most of them are here: https://etherpad.openstack.org/p/SB-Subscription-Signature 15:25:13 * NikitaKonovalov exploring the etherpad 15:26:15 Well my vote is for the first 15:26:16 From a performance standpoint, there’s really no difference between any of them, since we still have to do a WHERE index search to answer our questions. It’s just a question of “What makes the most sense if we were going to tell people about this”. 15:26:57 I was leaning towards 5, but then realized that it’s just extra effort. 15:27:10 And since 1 gives us everything we need.... 15:28:02 I think the first clearly defines who is subscribed to what without extra subresources 15:28:02 Yeah, 1 is probably best. 15:28:13 And it doesn’t muddy up the codebase either. 15:28:26 Suddenly we’re requiring subscription subcontrollers everywhere? That’s just going to get messy. 15:29:06 and the dbapi part of it is here https://review.openstack.org/#/c/106037/ 15:29:19 NikitaKonovalov: (Yeah, I’ve been building on that :D ) 15:29:25 Ish__: Any thoughts? 15:30:37 I also thought that option 5 is good.. 15:31:41 Ish__: How do you feel about the other discussion points we’ve brought up? 15:32:52 I am trying to make sense of them.. 15:33:04 They are all new to me.. 15:33:28 Alright, I can walk you through them when you get in :) 15:33:42 Moving on... 15:33:52 one more thing about subscriptions 15:33:57 Oh? 15:34:12 #topic Discussion: One More Thing About Subscriptions.... 15:34:28 krotscheck: you asked what if a user wants to subscribe to new projects in a project group 15:34:46 Right. 15:34:48 there is no timeline event for that 15:34:50 but 15:34:57 Or if they want to subscribe to what another user is doing. 15:35:15 a project group might have it's own timeline 15:35:22 the same for the teams 15:36:38 and if we want to subscribe for a user's actions that fits into the first approach of defining subscriptions: the target is a user in that case 15:38:53 Maybe I don’t quite understand what you mean by that. 15:39:07 * ttx waves from conference wifi 15:40:05 So let’s assume that we have a change stream consumer that’s getting these event ID’s, and it wants to process a subscription. 15:40:07 if you want to subsrtibe to a user POST {resourceType: 'User', resourceId: target_user_id, userId: current_user_id} 15:40:12 Right 15:40:52 See, when I see that, I think that I am subscribed to every change to a user resource. 15:41:08 now I see 15:41:41 Yeah, it’s a rough problem. 15:42:22 well, may be a more descriptive resource type User -> User_actions 15:42:29 Maybe, yes. 15:42:47 So, I think we agree on the actual implementation of things. If I want to subscribe to a resource, I’m _actually_ subscribing to that events’ timeline. 15:43:11 yep 15:43:19 s/resource/task/ 15:44:34 However, the actual thing that triggers the user’s subscription list update is the CREATE { type: ‘timelineEvent’ } rather than the UPDATE { type: ‘task’ } 15:45:57 we can say that the UPDATE triggers it, as it is in one code flow with timeline event creation 15:46:38 True. 15:47:12 That UPDATE will then send off two events to the event stream. a POST { type : ‘task’ } and a PUT { type: ‘timelineEvent’ } 15:47:51 At the other end of the queue though the consumer will probably only trigger on the latter. 15:48:18 This then gives us the freedom to add report-building event consumers. 15:48:39 Say, something that pays attention to every POST /tasks event that results in a task being set to MERGED. 15:48:58 And creates a nice little tasks-merged-per-day report for ttx :) 15:49:39 hah! 15:50:07 There is a reason to my madness :D 15:50:24 We got a few people excited with storyboard around here - apparently we are hittig some sweet spot 15:50:31 Ok, we’re running out of time, this discussion should probably have been moved to the main channel, my bad. 15:50:55 ttx: Oh, let them know that this event stream is also going to drive a remote synchronization API that’s going to handle our federation. 15:51:22 krotscheck: I don't want them to get TOO excited 15:51:32 one never knows what can happen then 15:51:34 Fine, fine. 15:51:40 ttx: They might contribute! 15:51:42 Anyway, moving on! 15:51:44 #topic Specs 15:51:51 Any specs-related things we ened to talk about? 15:52:02 no ideas from me here 15:52:24 Ok, next! 15:52:30 #topic Ongoing Work 15:52:44 Let’s go in reverse alphabetical today, starting with ttx. 15:52:53 Any word on the Team/Group requirements? 15:53:26 Last week ISTR we said it might not need to be expanded beyond the use cases on the permissions spec 15:54:03 If you feel that's not the case and we need some high-level doc on it, I can try to whip it something 15:54:22 ttx: Probably it won’t. I’ll pull it off your list. 15:54:27 Any other updates? 15:55:00 krotscheck: not really, been following a few angular presentations/tutorials to ramp up my involvement on the webclient side 15:55:05 Nice! 15:55:09 Ok, NikitaKonovalov ? 15:55:13 ANything new? 15:55:47 should have a lot more time available when I'm back next week 15:55:58 nothing except trying to find workarounds for mysql 15:56:15 Ok. 15:56:51 I took some time to split apart our builds, and updated our images to trusty 15:57:01 I’ve got a bunch of config patches to assist with that. 15:57:20 I think that’s all. 15:57:30 Ish__: Your turn :) 15:57:36 I have set up the dev environment and trying out a few rabbitmq programs.. I am in the process of learning and gathering knowledge. 15:57:57 Ish__: any blocker we could help solving ? 15:58:22 There are no blockers as such.. 15:58:55 or question ? 15:59:33 I am trying to understand the existing code .. 15:59:58 It’s python. Good luck with that :) 16:00:04 * krotscheck is opinionated 16:00:20 Yup.. :) 16:00:31 I’m afraid I have to close the meeting, anything else urgent? 16:00:57 #endmeeting