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