17:02:16 #startmeeting murano 17:02:17 Meeting started Tue Jul 8 17:02:16 2014 UTC and is due to finish in 60 minutes. The chair is ruhe. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:02:18 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:02:20 The meeting name has been set to 'murano' 17:02:47 any murano contributors today? 17:02:51 o/ 17:02:55 hi 17:02:58 hello 17:02:59 Hi 17:03:06 hi 17:03:15 here 17:03:30 katyafervent: ping 17:03:35 #link https://wiki.openstack.org/wiki/Meetings/MuranoAgenda#Agenda 17:04:01 agenda didn't change much from the previous meeting. would anyone like to add new item for the agenda right now? 17:04:27 ruhe - yeah.. we've had some problems with long-running reviews 17:04:39 and related to scoping 17:05:01 sjmc7: ok. let's put "long-running reviews right after the action items topic" 17:05:21 #topic action items review 17:05:21 hi 17:05:22 and also i'd like to briefly discuss external changes getting rushed through 17:05:37 sjmc7: ack 17:05:42 #link http://eavesdrop.openstack.org/meetings/murano/2014/murano.2014-07-01-17.01.txt 17:05:56 katyafervent: ping again 17:06:13 I'm here 17:06:37 katyafervent: katyafervent__ investigate 17:06:39 https://bugs.launchpad.net/murano/+bug/1328512 17:06:41 Launchpad bug 1328512 in murano "Pressing "quick deploy" too quickly may cause an error" [High,In progress] 17:07:15 seems like this bug has a fix proposed 17:07:44 ah, it's the one we decided to postpone and rework 17:07:46 I can't catch it, but did not try too hard 17:07:57 i think a lot of time got spent on this and i don't believe it's a serious problem 17:08:25 sjmc7: do you suggest to move this one to "low" priority? 17:08:29 afair, it's 3rd meeting when that issue gets attention :) 17:08:30 i think so 17:09:01 ok. changed to low priority and set status to "new" 17:09:21 next AI is: katyafervent to provide an update on horizon/dashboard/selenium tests research 17:09:23 BTW tsufiev reworked quick deploy behaviour a bit - now environment is created only after forms got filled 17:10:11 katyafervent, that was quite a long ago. The aforementioned bug has nothing to do with it. 17:10:23 Well I research that they mocked everything while using selenium 17:11:01 ruhe, currently I'm researching... well, try to write a test for Horizon fix using both some js-tests and selenium 17:11:08 s/try/trying/ 17:11:09 tsufiev, the bug is also old, may be it was caught without that fix 17:11:39 katyafervent: it would be great if you could compose a document where you would describe how it's done in horizon and pros and cons of this approach for testing murano-dashboard 17:12:14 ruhe, but as we long we don't want to test client-side code in muranodashboard, things will be simpler 17:12:33 tsufiev: simpler is better 17:12:35 ruhe, ok. do you need a research on all type of tests? 17:13:01 katyafervent: i think, just selenium 17:13:26 btully had ideas (or patches) to run unit tests for dashboard 17:14:08 i think ryan did some work on it, and got it working for one of the modal dialogs 17:14:11 but it's tricky 17:14:20 and once you get to testing JS stuff, it's very hard 17:14:37 #action katyafervent conduct a document about selenium testing approaches in horizon. also describe pros and cons of this approach for testing murano-dashboard 17:15:29 sjmc7: yeah. guys from storyboard have a great js,selenium,etc testing infrastructure, but afaik it's not applicable for horizon 17:16:14 there two more action items, but they don't have assignees. so, let's move to next topics and discuss those AIs in the "open discussion" section 17:16:29 agreed 17:16:35 #topic long-running reviews 17:17:09 i can confirm that some of reviews take to much time and definitely some of them should receive earlier review feedback 17:17:26 occasionally scope seems to change too 17:17:29 ruhe, i think horizon is moving towards the approach used in storyboard, but slowly 17:17:30 sjmc7: can you please outline the issues you've found 17:18:02 ruhe, i mean, recently they started to use AngularJS and added a few Jasmine client-side test for it 17:18:03 we had one particular case where maybe the definition wasn't defined enough (adding supplier info to packages) but it's been under review forever 17:18:32 and new features came in in the interim (like adding HOT support), which became reasons for rejecting the change 17:18:58 i'm not sure what the right way to handle that is, but it is disheartening to have to keep revisiting the same patch 17:19:56 my suggestion is that after a certain point (maybe 1 week or 2 weeks) if most serious feedback has been addressed, maybe any other serious feedback should be filed as a bug. otherwise, a patch will get stuck in review forever it's very easy for it to be out of date with so many changes 17:20:08 sjmc7: aggree. that's really unfortunate 17:20:41 ankurrr: right. that blueprint was filed long time ago and patch was almost ready to be merged by the end of juno1 17:20:45 it's made worse i think by the timezone difference - it means feedback is less immediate 17:21:12 with this particular case partially i think it's that the spec wasn't really tied down, and i have certainly had this happen on other projects too 17:21:42 but like ankur says, it might be better to iterate than keep rebasing the same patch 17:22:34 i thought that this patch passed murano-ci tests. tnurlygayanov please make sure that this patch passed murano-ci, and if it doesn't, please help ankurrr to pass the tests 17:23:00 one other point: for a blueprint, it's easier to get a bugfix reviewed and merged than it is to get a larger change reviewed and merge . maybe another alternative is to break down blueprints into smaller tickets and have the smaller changes merged separately? 17:23:47 ankurrr: i appologize that you had to maintain this patch for so long. that shouldn't happen and i should've notice that earlier 17:24:19 ankurrr: yes, breaking down a large blueprint into smaller pieces does make sense 17:24:35 ruhe: no problem. simply sounds like we need to improve the review process 17:24:45 not sure what the best solution is 17:24:58 not only the review process, but also bp approval process :) 17:25:44 touche 17:26:27 re: review process. i tried to use customized review dashboards. it's a project developed by Sean Dague and it helped to identify long-waiting reviews. so, this might help 17:27:38 re: bp approval process - here is what i'm trying to do now - once BP author submitted a BP, i'm trying to get feedback from related core team members and related people who work on this area. and only then, approve the blueprint 17:27:42 what else can we do? 17:28:07 i think make sure bps are properly scoped 17:28:13 more design review 17:28:17 too many are just a few lines 17:28:33 maybe we should adopt specs repo approach? 17:28:34 I have couple of patches that were on review for more than 3 weeks ... that's because the first feedback was provided only after a week. 17:28:35 easier then to say "well, the change fits the bp" 17:28:53 https://github.com/openstack/?query=specs 17:29:09 and if somebody saw -1 he even does not look on a patch 17:29:39 which is wrong policy 17:30:40 katyafervent, -1 from Jenkins is a sign for me that I should wait with review - until it disappears 17:31:18 katyafervent: (and everybode else who sees this problem) please don't hesitate to ping people in irc, even every day, if you see that no one is paying attention 17:31:30 tsufiev, how often do you check ether it from Jenkins or not + you can still review it 17:31:33 i've been guilty of that a couple of times, i'll try harder 17:31:33 and if that doesn't work, ping me in person 17:31:56 true, maybe we need to be more proactive in getting others to review a change 17:32:00 sjmc7: sergmelikyan: stanlagun: what do you think about adopting specs repo approach? 17:32:13 ankurrr: ^^ 17:32:23 +1 17:32:25 katyafervent, frankly speaking not very often :( 17:32:53 sure, we can go the specs repo route 17:32:53 tsufiev, what percent of review gets -1 from the first time? 17:32:53 here is an example of spec Alex is writing for Glance Artifact repo: https://review.openstack.org/#/c/100968/ 17:33:27 if you review all patches even if it would -1 from Jenkins you will reduce the amount of patchsets 17:33:27 it's really big because it's a really big change for Glance 17:33:38 and not only you, everybody can :) 17:34:05 ruhe, not sure that we are ready to adopt specs repo... First of all it will reduce development speed a lot. I suggest to postpone till the next cycle 17:35:40 sergmelikyan: yes, it has this downside, it reduces development speed. on the other hand it helps to draft a clear specification, where everybody will have time to leave feedback. that should help to produce clearer and understandable changes into the project 17:35:57 sjmc7: what do you think about that? 17:36:47 i don't think there has to be a huge formal process 17:37:04 but if a bp is a sentence, and i can't immediately see how i'd implement it, maybe it needs some more detail 17:37:55 sjmc7, that makes sense. we can always provide specification url 17:38:13 or if it fits to description of the bp - provide it there 17:38:37 ok. i guess that'll be a long-running AI on me. make sure spec is clearly written and most of the correct team left a postive feedack on it 17:38:49 ... before BP is approved 17:39:22 anything else on this topic (long-running reviews)? 17:40:00 nope 17:40:19 sjmc7: you also wanted to discuss another topic. right? 17:40:28 yes. let me remember what it was 17:40:36 scope changes 17:40:58 that was related 17:41:07 the other topic was the change from yesterday, the heat stack thing 17:41:57 and in general, making changes that will affect users and support scenarios 17:42:15 internal changes i'm (sort of) ok rushing through 17:42:29 but things that could change e.g. documentation need to at least be discussed 17:42:51 we discussed that with stanlagun and sergmelikyan. i believe we're clear now that no change should be merged that fast 17:43:36 k 17:43:51 also, since we're in different timezones (we're on opposite sides of the globe) we should alway give time to review and provide feedback to folks from the other side 17:44:12 good enough for me 17:44:41 anything else on this topic? 17:44:53 nope 17:44:57 so everybody should start work day with reviewing new patches :) 17:44:57 speaking of discussing wide-scope changes... 17:45:26 I'd like to draw a bit of your attention to that change in dynamic UI http://lists.openstack.org/pipermail/openstack-dev/2014-July/039405.html 17:47:03 probably ankurrr and btully could give feedback in this thread? 17:47:43 ruhe, or katyafervent 17:48:03 ruhe, should I have asked that question in the related BP's whiteboard? 17:48:09 yep. katyafervent: can you start your work day by replying on this mail? ;) 17:48:47 tsufiev: you could, but mail is fine too 17:49:02 ruhe, ok 17:49:09 ruhe, ok, then won't add it there 17:49:11 feedback on patch reviews or feedback on the dynamic UI bp? 17:49:41 btully: dynamic ui bp 17:49:58 k i'l take a look 17:50:00 btully, it was kind of FYI message :)... so far I agree with stanlagun suggestion 17:50:02 we don't have much time left. let's move to the next topic 17:50:30 #topic important bugs we need to fix 17:51:03 there is one filed by sjmc7 just recently about fqn not being an unique field in the DB 17:51:10 http://j.mp/murano-j-bugs 17:51:26 ^^ open bugs on Murano 17:52:15 there are two critical bugs without assignees 17:52:30 If you think some bug require higher priority please - mention it now 17:53:12 sergmelikyan: stanlagun: would you be able to take care of those two critical bugs? 17:53:23 ruhe, they are really big bugs... We need to rewrite noticeable piece of code 17:53:45 ruhe, sure, but I am not sure about j2 scope 17:54:23 took https://bugs.launchpad.net/murano/+bug/1325101 17:54:24 Launchpad bug 1325101 in murano "[api] marks environments deleted regardless of actual state" [Critical,Confirmed] 17:54:37 sergmelikyan: we can take an approach similar to BPs. you can draft a document with description of the fix and discuss that document with the team 17:54:40 ruhe, ok 17:55:16 but, before you jump into possible "big changes", please discuss your plan with the team 17:55:53 ruhe, definitely 17:56:21 any other important bugs we should discuss today? 17:57:08 #topic current state of murano testing 17:57:26 murano-ci is moving to become stable enough, but not there yet 17:57:53 we plan to allocate new server which you help to make it more stable 17:58:01 *which would 17:58:31 murano-dasbhard didn't fail for a long time though 17:59:06 would anyone like to add somethig for this topic? 17:59:44 I would like to draw attention to CI related fix: https://review.openstack.org/105398 18:00:24 we're out of time. let's continue at #murano 18:00:27 without this fix Murano CI is running tests on outdated version of Core Library 18:00:42 thanks everyone. this was an important and valuable meeting 18:00:45 #endmeeting