16:02:38 <amotoki> #startmeeting Horizon
16:02:39 <openstack> Meeting started Tue Oct  7 16:02:38 2014 UTC and is due to finish in 60 minutes.  The chair is amotoki. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:02:40 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:02:43 <openstack> The meeting name has been set to 'horizon'
16:02:48 <amotoki> let's start.
16:03:03 <amotoki> #topic announcement
16:03:25 <amotoki> RC1 is released later last week. thanks everyone for your efforts.
16:03:50 <woodm1979> Yay!  :-D
16:03:56 <rdopieralski> hi
16:04:04 <jpich> woohoo
16:04:17 <amotoki> RC2 is planned for translation imports and other some cleanups.
16:04:49 <amotoki> perhaps RC2 will be shipped later this week.
16:05:05 <amotoki> I would like to cover RC2 potential bugs.
16:05:14 <amotoki> #link https://bugs.launchpad.net/horizon/+bugs?field.tag=juno-rc-potential
16:05:30 <amotoki> Is there any other release blocking bugs we need aware?
16:07:17 <akrivoka> hello
16:07:42 <tsufiev> hi
16:07:56 <amotoki> is there any announce for the team?
16:08:39 <amotoki> let's move on the meeting agenda.
16:08:41 <amotoki> #link https://wiki.openstack.org/wiki/Meetings/Horizon
16:08:52 <amotoki> #topic translations imports and related topics
16:09:18 <amotoki> translation import is scheduled at around 1300UTC Oct 9. I will post a patch.
16:09:38 <amotoki> In addition, I would like to remove MO files (compiled message catalogs) in RC2.
16:10:01 <amotoki> we discussed on removing MO files in dev list. I got a consensus on removing them and got positive feedbacks from distributors (at least RDO and Debian so far).
16:10:16 <amotoki> any concern on removing mo files?
16:10:25 <jpich> It strikes me as a little late, when distros wouldn't have had the time to test the new process during any of the milestones, but if the packagers are ok with it then it's all good
16:10:29 * rdopieralski approves, as it will make the splitting easier too
16:11:12 <amotoki> jpich: good point. as far as I gathered, RDO is not affected. Debian (zigo) agrees the change.
16:11:34 <amotoki> no information from Ubuntu Cloud team so far.
16:11:38 <rdopieralski> and ubuntu will probably put them back anyways ;)
16:11:57 <jpich> or suse
16:12:40 <amotoki> We need to mention this in the release and I believe it helps us.
16:12:58 <zigo> We had *really* a lot of changes at the very last minute in Horizon, I think it's a very good thing to remove the .mo in general, but why so late?
16:13:14 <zigo> I've posted the first patch about it about a year ago !!!
16:13:36 <rdopieralski> zigo: the short answer is we are understaffed
16:13:47 <amotoki> zigo: really sorry. I couldn't have enough time to do so.....
16:14:20 <zigo> I'm not discussing the feature, I like it. I'm discussing the timing.
16:14:40 <zigo> We're a bit more than a week before the release...
16:15:01 <zigo> Can't this be delayed for the next point release of Juno?
16:15:46 <amotoki> zigo: yes. I can do it in Kilo, but many distribution hate this and I just wonder it is better in Juno or not.
16:16:15 <jpich> Not sure if that would be an appropriate backport for the stable branch
16:16:22 <rdopieralski> the question is what's worse, continue to ship the mo files, or make a sudden change
16:16:24 <amotoki> at least, I thnk it is not a good idea to change a thing like this in stable upates.
16:16:51 <zigo> jpich: I do think it's appropriate, and much better than doing it 9 days before the relase.
16:17:00 <jpich> I think it would be more surprising as a point release change
16:17:13 <amotoki> If we have a concern on this, we can defer removing mo files to kilo.
16:17:31 <zigo> Then I prefer to have it happen now, if there's no hope for a point release change.
16:19:13 <amotoki> okay. I understand it bothers folks who work on distributions. can anyone reach ubuntu and suse team?
16:20:07 <jpich> amotoki: I'll try to find out who they are and point them to the thread, tomorrow morning
16:20:17 <zigo> amotoki: It only bothers me if I discover it the day of the release, if you do it and cut a new RC let's say tomorrow, then that's acceptable for me... :)
16:20:42 <zigo> Wait 7 days and give me 2 days to test it, then I wont like it.
16:21:10 <jpich> I guess I'll try to find them tonight so we can get their input early then :-)
16:21:37 <zigo> :)
16:22:31 <amotoki> thanks jpich.
16:23:07 <amotoki> more i investigated the problem, i feel it is not a good thing more.... really sorry for bringing this at the moment.
16:23:28 <amotoki> jpich: could you follow this on the dev list?
16:23:46 <jpich> amotoki: Sure
16:24:08 <amotoki> jpich: thanks.
16:24:14 <amotoki> move on the next topic
16:24:25 <amotoki> #topic Deprecation notice of OPENSTACK_QUANTUM_NETWORK
16:24:44 <amotoki> the patch I proposed has been merged already.
16:25:12 <amotoki> OPENSTACK_QUANTUM_NETWORK is previously used only for enable_lb (lb = lbaas) in Icehouse.
16:25:51 <amotoki> and OPENSTACK_QUANTUM_NETWORK works in Juno, so I believe deprecation has no negative effect.
16:25:54 <amotoki> any concern?
16:27:14 <jpich> Nope
16:27:49 <amotoki> If you find any concern on this, please let me know.
16:28:35 <amotoki> #info OPENSTACK_QUANTUM_NETWORK will be deprecated in Juno release.
16:28:52 <amotoki> #topic Oslo Liaison for Kilo
16:29:02 <amotoki> the next topic is Oslo liaison.
16:29:38 <amotoki> Oslo is cross-project project and we need a liaison to bridge a project and Oslo.
16:30:00 <amotoki> It is same as Juno release. the detail is https://wiki.openstack.org/wiki/Oslo/ProjectLiaisons
16:30:19 <amotoki> In juno release, Lin served as a liaison.
16:30:51 <amotoki> Kilo release is same. I am interested in doing this.
16:31:12 <amotoki> Is anyone interested in this?
16:31:53 <amotoki> core member is not a requirement as discussed in recent posts in dev list.
16:32:41 <rdopieralski> I'd love to get more involved in Oslo, but I don't think I would have the time for this
16:35:24 <amotoki> horizon use a few oslo libraries now, so minimum work would be small, but it is better we get more involved in olso.
16:35:41 <jpich> Looks like you get to do it amotoki... One more hat to add to your large collection
16:36:03 <jpich> That makes sense
16:36:04 <tqtran> =D
16:36:18 <amotoki> thanks
16:36:41 <rdopieralski> are there any plans to have liaisons for other stuff too?
16:36:42 <amotoki> I will add me to the list. I will do my best :)
16:37:01 <jpich> Thank you amotoki!
16:37:13 <amotoki> rdopieralski: I am not sure at now, but docs team want a liaison too.
16:37:37 <amotoki> in addition, we need a liaison from integrated projects too :-)
16:37:47 <amotoki> *liaisons
16:38:45 <rdopieralski> thanks
16:39:11 <amotoki> we can discuss how to improve our works to cover more works of projects next week or after.
16:39:21 <amotoki> let's move on the next topic.
16:39:27 <amotoki> #topic Adding Sinon.JS dependency
16:39:37 <amotoki> tsufiev: ping
16:39:45 <tsufiev> here
16:40:15 <amotoki> please go ahead on Sinon.js
16:40:22 <tsufiev> I just wanted to make sure that everybody is fine with adding another dependency to Horizon
16:40:39 <rdopieralski> that's for test-requirements, right?
16:40:54 <jpich> From your email it's about javascript testing?
16:41:07 <tsufiev> Sinon.js is a very nice library that can be used with many testing frameworks. It provides testing spies, stubs, mocks and emulating time in case of async calls
16:41:14 <tsufiev> jpich, yes, exactly
16:41:34 <jpich> I think we already added Jasmine just for this, which seems to have similar capabilities?
16:41:38 <tqtran> whats the difference between this and jasmine?
16:41:46 <tqtran> jpich: right
16:41:52 <jpich> tqtran: Right :P
16:41:56 <tqtran> =D
16:42:06 <rdopieralski> I think jasmine was added to test angular.js
16:42:09 <tsufiev> jpich, tqtran, the Jasmine is a whole testing framework, while Sinon.js can be used with any framework
16:42:29 <jpich> rdopieralski: It can do more though, it doesn't depend on Angular
16:42:43 <tsufiev> personally I needed to add testing mock to QUnit test, unfortunately it is not as rich as Jasmine
16:42:55 <rdopieralski> jpich: that I don't know, but as far as I know, nobody except for angular people is interested in using it
16:43:08 <rdopieralski> jpich: it has horrible "natural language-like" syntax
16:43:12 <tsufiev> jpich, well, should we rewrite all QUnit tests using Jasmine?
16:43:20 <rdopieralski> tsufiev: please no
16:43:43 <rdopieralski> I'm not even sure if we actually have any tests that use jasmine?
16:43:48 <jpich> That sounds like a decent idea to me, to use only one framework for testing
16:44:03 <tqtran> yeah agree
16:44:16 <rdopieralski> oh, we have 2
16:44:18 <tsufiev> rdopieralski, jpich, perhaps we have a bigger topic here than just adding one tiny JS library :)
16:44:39 <tqtran> im in favor of jasmine, since angular is using a subset of it
16:44:52 <rdopieralski> jpich: let's see what will be less work, rewrite 50+ tests from qunit to jsamine, or rewrite 2 tests from jasmine to quinit?
16:45:16 <jpich> rdopieralski: jasmine was added because it has capabilities that we need / will need that qunit just doesn't have, is my understanding
16:45:21 <jpich> Do we have 50+ javascript tests?
16:45:27 <rdopieralski> jpich: what are those capabilities?
16:46:14 <jpich> rdopieralski: if MaxV's around, I'm sure he could explain in more details :-) From what I recall it centred around the Angular stuff like you said, which is what we're going toward
16:46:23 <jpich> tqtran: Would you have more insightful input on this?
16:46:45 <rdopieralski> jpich: sorry, just 35 tests, I lied
16:47:07 <tqtran> jpich: I just got into it recently, wouldnt have anything insightful to say
16:47:17 <tsufiev> jpich, my fault, I haven't made thorough investigation of features Sinon.JS providing vs. Jasmine
16:47:31 <jpich> rdopieralski: that's cool, last I looked we had very very very few javascript tests, glad this has changed
16:47:40 <tsufiev> jpich, to me Sinon.JS selling point was that it could be used seamlessly with QUnit
16:47:42 <rdopieralski> from what I know, sinon.js is a lot like python's unittests.mock
16:47:49 <tqtran> but from what i have seen, angular is using jasmine for unit testing, and since thats where we are headed.. its something that seems logical to me
16:47:55 <rdopieralski> and it is being used a lot in all possible frameworks
16:48:06 <rdopieralski> it even has some code specially for jasmine
16:48:13 <tsufiev> rdopieralski, yep
16:48:23 <rdopieralski> so there are people who use it in jasmine too -- so apparently it's not a duplication of features
16:48:25 <jpich> tsufiev: Maybe you can follow up about this on the ML, and we can pick up either on list or during the meeting?
16:48:42 <tsufiev> jpich, sure, I'll look into this
16:48:51 <rdopieralski> tsufiev: I have one question
16:49:02 <jpich> Fair enough. One of my concerns was that we were getting close to having more javascript testing libraries than javascript tests, but if we have 35 there's a small margin ;)
16:49:02 <rdopieralski> tsufiev: are you going to take care of the xstatic package?
16:49:10 <jpich> tsufiev: Thank you!
16:49:49 <rdopieralski> tsufiev: as in, create and maintain it?
16:49:50 <tsufiev> rdopieralski, yes, I could do this. That's the main reason I put this on agenda - to avoid unnecessary work )
16:50:01 <tsufiev> rdopieralski, hm...
16:50:37 <tsufiev> rdopieralski, create - yes. Maintain - well, I'll do my best
16:51:14 <rdopieralski> tsufiev: up until now we kinda ignored it, but the js code also gets security updates
16:51:19 <rdopieralski> tsufiev: and stuff like that
16:51:23 <amotoki> it seems we need to discuss and decide what test framework(s) we use based on our needs and then consider maintaining xstatic libs.
16:51:28 <rdopieralski> tsufiev: a testing library is probably low risk, though
16:51:44 <tsufiev> rdopieralski, yeah, no production usage
16:51:50 <rdopieralski> amotoki: I would also revive the mox vs. mock discussion
16:52:11 <rdopieralski> amotoki: maybe next week
16:52:21 <amotoki> rdopieralski: yeah... mox sometimes behaves in a tricky way.
16:52:38 <amotoki> #topic Open Discussion
16:52:55 <amotoki> any topics to be discussed?
16:53:12 <tsufiev> also I wanted to take this one bug https://bugs.launchpad.net/horizon/+bug/1276735
16:53:18 <zigo> Yeah...
16:53:41 <zigo> https://bugs.launchpad.net/horizon/+bug/1377372
16:53:54 <zigo> I really would like this one to be fixed for Juno if possible.
16:54:13 <jpich> Could you add the juno-rc-potential tag to it to increase its visibility?
16:54:13 <pkarikh> I'm working on "Implement inline-editing to all tables" blueprint (https://blueprints.launchpad.net/horizon/+spec/inline-editing-implementation-to-all-tables).  I've implemented inline editing for one table (as it said in the blueprint) and I have doubts whether I should do unit tests for each commit immediately, or to wait until the community will evaluate each usecase?
16:54:15 <tsufiev> David Lapsley set it WIP 4 months ago and didn't show up since
16:54:20 <TravT_> tsufiev: that bug doesn't seem valid to me anymore
16:54:28 <jpich> (zigo: Sorry this is happening again...)
16:54:30 <amotoki> zigo: i think mrunge tried to reach you to discuss it
16:54:31 <zigo> And also, I still don't have an answer for test_update_project_when_default_role_does_not_exist() failing in Django 1.7, and I have no idea how to work on that one.
16:54:52 <tsufiev> TravT_, has it been superseded by some new functional?
16:55:04 <zigo> jpich: Ship happens, no worries ! :)
16:55:09 <TravT_> tsufiev: the new "update metadata" widget based on the Glance Metadata Definitions catalog replaced the old extra specs.  Have you pulled a new devstack?
16:55:17 <jpich> zigo: That it does
16:55:45 <rdopieralski> pkarikh: have you seen the data table formsets in horizon?
16:55:55 <tsufiev> TravT_, well, I was more interested in the related commit for it https://review.openstack.org/#/c/71330/ - fixing the modal stack
16:56:32 <amotoki> https://bugs.launchpad.net/horizon/+bug/1360794
16:56:57 <amotoki> zigo: perhaps Django 1.7 issues has the same root cause of bug 1360794.
16:57:13 <tsufiev> TravT_, but you may be right, if Extra Specs is implemented on Glance Metadata defs, it would be a solution looking for a problem
16:57:19 <amotoki> zigo: I tried to investigate it but .....
16:57:39 <pkarikh> rdopieralski, nope
16:57:39 <TravT_> tsufiev: yeah, pull a new devstack and take a look.  same widget is used for flavors, host aggregates, and images now.
16:57:56 <jpich> tsufiev: If it's been a long time and the author doesn't reply to you (you can use Launchpad's "Contact this user" feature to send an email too if you like being thorough), feel free to take the patch over and co-author it
16:58:00 <zigo> About test_update_project_when_default_role_does_not_exist(), I asked half a dozen people to have a look, and nobody gets it. How about removing this test completly and be done with it? :)
16:58:12 <tsufiev> TravT_, okay, thank you for pointing me to that. Will take a look
16:58:25 <rdopieralski> pkarikh: nevermind
16:58:34 <TravT_> jpich: i think i will update that patch to point out that is was superseded by new work.
16:58:49 <amotoki> zigo: in juno?
16:58:53 <jpich> TravT_: Okay, just pointing this out as a general rule
16:58:58 <rdopieralski> pkarikh: as for your question, each patch should include tests for the functionality that it adds
16:59:05 <jpich> If you're counting time in months and can't get an answer it's usually ok to take over
16:59:17 <zigo> amotoki: Yeah, and in Icehouse too, since there's the issue there as well.
16:59:20 <tsufiev> jpich, ok. Still speaking about that bug helped me to avoid solving already solved problem :)
16:59:33 <jpich> tsufiev: Even better :)
16:59:48 <amotoki> zigo: django 1.7 support is in our rader in Kilo and i am not sure we support it in Juno.
16:59:53 <jpich> tsufiev: Hm depending on what you find can you add a comment to the bug too? Sounds like we might want to close it then
16:59:58 <TravT_> tsufiev: that modal problem does still exist on volume type extra specs and QOS specs that were just added. we hope to replace that with new widget as well and have blueprints on it.  but we have some dependent cinder work.
17:00:10 <amotoki> ah.... our time is being over.
17:00:24 <pkarikh> rdopieralski, thanks, I realized
17:00:26 <amotoki> thanks all for your efforts.
17:00:32 <amotoki> have a good week.
17:00:33 <rdopieralski> bye
17:00:37 <amotoki> #endmeeting