15:10:03 <NikitaKonovalov> #startmeeting Storyboard
15:10:04 <openstack> Meeting started Mon Aug 18 15:10:03 2014 UTC and is due to finish in 60 minutes.  The chair is NikitaKonovalov. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:10:05 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:10:07 <openstack> The meeting name has been set to 'storyboard'
15:10:08 <ttx> o/
15:10:19 <jeblair> o/
15:10:45 <NikitaKonovalov> Agenda https://wiki.openstack.org/wiki/StoryBoard#Agenda
15:11:12 <NikitaKonovalov> #topic Search
15:11:53 <NikitaKonovalov> krotscheck is out of this meeting, so I'll just say that the search related changes have landed
15:12:18 <jeblair> i left a -1 on the current search spec; i think there's still something that i'm missing
15:12:19 <ttx> NikitaKonovalov: can that be considered complete?
15:12:30 <NikitaKonovalov> the UI has not updated for some reason
15:12:53 * NikitaKonovalov looking at jeblair's comments
15:13:28 <ttx> NikitaKonovalov: you skipped the first two items in the agenda
15:13:48 <ttx> which may help in the "UI not updating" department
15:13:49 <jeblair> basically, i'm not sure about the fact that we have 3 search endpoints, and we'll need to hit all 3 to do a simple search
15:14:15 <jeblair> ttx: ah, ok, i'll bump those to the top of my list
15:15:12 <NikitaKonovalov> jeblair: the reason to have different endpoint is first of all to have a clear routing
15:15:46 <jeblair> NikitaKonovalov: because of the "REST" model, you mean?
15:15:46 <NikitaKonovalov> the second reason is that the result respons contains objects of only one type
15:16:06 <NikitaKonovalov> jeblair: yes
15:16:48 <jeblair> i'm not a rest expert, but i think that there must be a good solution to this.  imagine if the system were more complicated and we had 50 object types -- we really wouldn't want to do 50 api calls to search them
15:17:20 <ttx> :)
15:17:51 <jeblair> i just think that most of the searches will be for comments, stories, and tasks, so most of the time we will end up doing 3 api calls for one search
15:18:42 <NikitaKonovalov> well, we may have one endpoint
15:18:50 <ttx> that sounds like a valid concern
15:19:04 <NikitaKonovalov> but still the number of the db_api call will stay the same
15:19:09 <jeblair> from working on gertty, i've learned that in some situations, network lag is high enough that can be a real noticable effect (lifeless submitted a number of patches that reduce the number of api calls to improve the experience for his use)
15:20:01 <jeblair> NikitaKonovalov: yeah, that makes sense.  i'm mostly worried about adding network lag and making it difficult for api client users
15:20:44 <NikitaKonovalov> we need more opinions I guess
15:20:51 <jeblair> NikitaKonovalov: do you think having those 3 endpoints, but then also having a general endpoint that can return any kind of result would work?
15:22:02 <NikitaKonovalov> jeblair: I think we can add this endpoint as an experimental and see how it workd
15:22:20 <NikitaKonovalov> *works
15:22:48 <jeblair> okay, thanks.  that's all i wanted to bring up on the subject.
15:23:12 <ttx> maybe come back to "Urgent Items" and "Discussion topics" ?
15:23:31 <NikitaKonovalov> yes
15:23:49 <NikitaKonovalov> #topic Urgent items
15:23:59 <NikitaKonovalov> StoryBoard WebClient no longer updating
15:24:11 <ttx> So there seems to be two reviews up to fix this, jeblair said he would prioritize them up
15:24:28 <ttx> Not sure there is much more to discuss on that
15:24:53 <ttx> at least not at this point
15:24:55 <NikitaKonovalov> looks like we need infra reviewers there
15:25:44 <jeblair> yeah, i'll poke people today
15:25:58 <jeblair> but i have a new urgent item
15:26:00 <jeblair> 1 second
15:26:23 <jeblair> http://paste.openstack.org/show/96507/
15:26:35 <jeblair> that's the traceback from when i tried to create a story yesterday
15:27:04 <jeblair> i think there's a problem with rabbitmq?
15:28:03 <ttx> Or a bug in http://git.openstack.org/cgit/openstack-infra/storyboard/commit/?id=c8cbc9720d671e796f05f88b3e9900660da7b3ee
15:28:49 <NikitaKonovalov> are the notifications enabled right now?
15:29:02 <ttx> default might be enable_notifications = True
15:29:16 <ttx> err, no it's Flase
15:29:50 <jeblair> enable_notifications = True
15:29:52 <jeblair> on the server
15:30:23 <ttx> do we even have rabbit on the server-side? /me is slightly out of touch
15:30:35 <jeblair> i believe so
15:31:18 <jeblair> closing AMQP connection <0.20405.0> (127.0.0.1:58084 -> 127.0.0.1:5672):
15:31:18 <jeblair> {heartbeat_timeout,running}
15:31:24 <jeblair> that shows up a few times in the rabbitmq log
15:31:39 <jeblair> closing AMQP connection <0.10791.0> (127.0.0.1:55191 -> 127.0.0.1:5672):
15:31:39 <jeblair> connection_closed_abruptly
15:31:40 <jeblair> also that
15:32:03 <ttx> maybe the code is not very resilient to connection drops
15:32:04 <jeblair> i'm not sure if those are normal or not.  but on the python side, i wouldn't be surprised if we were trying to use a closed connection
15:32:11 <jeblair> ttx: yeah
15:32:27 <ttx> jeblair: it's not as if we did not encounter this issue on other openstack projects
15:32:48 <jeblair> ttx: have they solved it yet?  :)
15:33:09 <ttx> Maybe we should have used oslo.messaging after all :P
15:33:12 <NikitaKonovalov> so the workaroud is to switch notifications off untill there is a better workaround?
15:33:32 <ttx> NikitaKonovalov: that sounds like a valid workaround yes
15:34:02 <ttx> But then it might make sense to check if it's a one-off
15:34:11 <jeblair> yeah, sounds like we should do some local testing where we break connections, and let them time out, etc, to make sure the rabbit stuff is resilient
15:34:39 <jeblair> ttx: i can restart everything and see if that fixes it, and then see if we notice the problem again in a few days
15:34:49 <ttx> jeblair: your call
15:35:00 <Ish__> I ll look into this. I didn’t face such issues.
15:35:08 <ttx> i'm fine with either... didn't even know notifications were running :)
15:35:19 <jeblair> i'll do that.  i don't want to keep doing it if it's really broken, but i'm fine doing it once or twice to collect more info
15:36:10 <ttx> ok, so we restart and see, and in the meantime Ish__ looks up the code to see if there could be failure conditions in that area
15:36:21 <NikitaKonovalov> ok, so any other urgent items?
15:37:20 <jeblair> #link https://storyboard.openstack.org/#!/story/202
15:37:31 <jeblair> i restarted rabbitmq and apache, and then was able to file that ^
15:39:04 <jeblair> no idea why i left the paste link; /me updates with actual traceback
15:39:27 <NikitaKonovalov> so the obvious change to be done here is to handle rabbit disconnects
15:39:42 <NikitaKonovalov> Ish__: will you take that?
15:39:51 <Ish__> yes.
15:39:54 <NikitaKonovalov> ok
15:40:17 <Ish__> https://review.openstack.org/#/c/113016/ also needs to be reviewed.
15:40:57 * NikitaKonovalov adding a reminder to do that
15:41:33 <ttx> NikitaKonovalov: next topic?
15:42:05 <NikitaKonovalov> #topic MVP 1.1: LP data import
15:42:32 <ttx> there was a related question in "discussion topics" on the agenda
15:42:37 <ttx> "What do we do when a launchpad project has successfully migrated, but someone submits a ticket in launchpad? "
15:42:47 <ttx> I think we would close the Launchpad project
15:42:55 <ttx> once migration is completed
15:43:07 <ttx> or at least disable the bug side
15:43:08 <jeblair> ttx: ++
15:43:18 <NikitaKonovalov> ttx: looks like an easy solution, +1
15:43:27 <ttx> jeblair: we also move closed items, right
15:44:08 <jeblair> that suggests that someday we'll probably want to be able to disable a project in storyboard too, but not for a while i hope :)
15:44:12 <ttx> note that the current migration would lose info if applied to a more... traditional project
15:44:30 <ttx> but it should work fine for at least infra, QA, oslo...
15:44:41 <ttx> which do not rely on "milestones" that much
15:45:13 <ttx> otherwise the review from mordred is just waiting for Nikita to revise his -1
15:45:38 <ttx> and then we can Workflow+1
15:45:55 <ttx> tat's all I had on that topic
15:46:05 <ttx> review at https://review.openstack.org/#/c/113624/
15:46:42 * NikitaKonovalov removed the -1
15:47:25 <ttx> ok will +1
15:47:38 <reed> one step closer :)
15:47:42 <NikitaKonovalov> #topic MVP 1.1:Subscriptions
15:47:50 <ttx> reed: one step beyond!
15:48:34 <NikitaKonovalov> any news, except the rabbit problem?
15:49:04 <Ish__> NikitaKonovalov:  I have heartbeats disabled in my rabbitmq configuration file.
15:50:10 <Ish__> I think this has to be done in the server aswell so that we will not face that issue again.
15:52:13 <NikitaKonovalov> ok, I have seen the WIP change from krotscheck for subscriptions UI
15:52:41 <NikitaKonovalov> so we are waiting for him to complete it
15:53:47 <NikitaKonovalov> #topic MVP 1.1:Tags
15:54:19 <NikitaKonovalov> I've got 2 changes for the db_api and rest controller
15:54:55 <NikitaKonovalov> https://review.openstack.org/#/c/113889/ and https://review.openstack.org/#/c/114217/
15:55:01 <NikitaKonovalov> So reviewers are welcome
15:56:18 <NikitaKonovalov> and the last MVP topic
15:56:28 <NikitaKonovalov> #topic MVP 1.1:Emails
15:57:02 <NikitaKonovalov> Do we need a spec for it?
15:58:01 <NikitaKonovalov> ttx, jeblair ^^
15:58:31 <ttx> NikitaKonovalov: I think so. I have no idea what is behind this
15:58:35 <jeblair> i think it might be a good idea
15:58:46 <ttx> so i don't feel like I'm the right person to spec it
15:58:51 <jeblair> i think we'll want to hash out when to send emails and what to include, and a spec is probably a good place for that
15:59:14 <ttx> I would be fine with the system not supporting email, but tha's just me
15:59:29 * ttx has to drop to join another call #crazymonday
15:59:41 <NikitaKonovalov> ok
15:59:53 <NikitaKonovalov> so we are out of time anyway
15:59:59 <NikitaKonovalov> thanks everyone
16:00:00 <jeblair> well, this was a useful and not-short meeting after all :)  thanks NikitaKonovalov
16:00:07 <ttx> thanks NikitaKonovalov !
16:00:10 <NikitaKonovalov> #endmeeting