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