17:01:11 #startmeeting murano 17:01:12 Meeting started Tue Jul 15 17:01:11 2014 UTC and is due to finish in 60 minutes. The chair is ruhe. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:13 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:15 The meeting name has been set to 'murano' 17:01:23 #link https://wiki.openstack.org/wiki/Meetings/MuranoAgenda#Agenda 17:01:39 katyafervent2: hi 17:01:39 o/ 17:01:43 hi 17:01:51 hi 17:02:16 hi 17:02:29 hi 17:02:50 ok. we have a quorum. i hope more people will join soon 17:02:58 #topic action items review 17:03:15 first AI is - ruhe: create stackforge/murano-apps project for apps from murano-app-incubator 17:03:40 and it's done - https://review.openstack.org/#/c/107071/ ; now we'll need to wait for this patch to be merged 17:04:12 great! 17:04:19 please note that this will be an empty repo, i've specifically excluded an option which allows to populate repo with upstream from murano-project on github 17:04:53 ruhe, this is right. Currently our app-incubator is quite far from what we hope it is should be 17:04:54 we didn't pay much attention to reviews in github repo, so we'll have a chance to review each app again 17:05:32 there are no more action item from previous meeting. let's move on 17:05:39 #topic [katyafervent] provide an update on horizon/dashboard/selenium tests research 17:05:46 katyafervent2: please 17:06:20 it turns out, that there are just a few tests in horizon that use selenium 17:07:06 tsufiev: i believe you also researched this area in horizon? 17:07:14 ruhe, yep 17:07:15 in integration tests they prerared infrustructure, and currently just one test is ready in this section 17:07:41 ruhe, there are integration tests and unit-tests 17:07:58 it uses page object model to make selenium tests clear and easier to refactor 17:08:34 and it turns out (for horizon) that writing unit test using selenium is a hard thing because it is hard to mock out client calls using selenium 17:08:56 and i guess that we found the solution about hiw dashboard tests could be run on the openstack Jenkins 17:09:01 and i guess we identified a few point we could imporve in our selenium tests: it's difficult to run these tests in development environemnt, it's impossible to run these tests in dsvm (devstack vm in gates) job 17:09:55 * ruhe doesn't know how ruhe manages to make so many grammatical mistakes 17:10:07 one can use @override_settings for SeleniumTestCase - so that is a way that new unit tests could be written with Selenium: to replace direct python imports with dynamic imports of client modules specified in config 17:10:09 right, and it will be possiable to run tests on devstack installation 17:10:20 katyafervent2: when will it be possible? 17:10:24 ruhe - let's do this in russian and see how i do with grammar :) 17:10:51 since all improvements will be tested and merged 17:11:23 sjmc7: good idea, we should try that ;) 17:11:31 katyafervent2: do you have a patch on review? 17:11:44 i could test it on devstack 17:12:06 there are two of them right niw abd the third is coming 17:12:06 ruhe, but we don't need upstream horizon to adopt that approach, for murano it will be sufficient to move MURANOCLIENT to the setings.py - so we could mock it in Selenium 17:12:54 then muranodashboard will be tested independently from murano-api 17:13:24 tsufiev: do you say that there is a way to mock API calls in dashboard and run selenium tests on top of that? 17:13:35 ruhe, exactly 17:13:39 tsufiev but we still need in integration tests 17:14:16 katyafervent, i don't doubt that integration tests are needed 17:14:23 tsufiev: katyafervent2: i think that we need to spend more time on this and try to conduct our plan with this in form of a blueprint 17:14:29 it's just an approach to writing Selenium unit tests 17:14:36 tsufiev thats a lit of work - you need to mock all calls 17:15:02 ruhe, katyafervent: that's how I did in the horizon https://review.openstack.org/#/c/103895/6/horizon/test/tests/selenium_tests.py 17:15:05 katyafervent2: tsufiev: will you please follow up on this in an etherpad document? 17:15:16 I've mocked only openstack_auth 17:16:08 ruhe, yes 17:16:15 tsufiev: this look promisiong 17:16:20 ok. thank you 17:16:39 #action katyafervent2 and tsufiev follow up on selenium testing in an etherpad document 17:17:06 #topic Current state of Murano testing 17:17:25 i'd like to provide a briefe update on murano-ci 17:17:51 murano-ci has been flaky for a long time. and there are several reasons for that 17:18:04 we're working on stabilisation step by step 17:18:52 also, we hope to re-locate CI to the dedicated server in a new data center; that should make things more stable 17:19:19 any updates or questions on this topic? 17:20:04 no. but we need it stabkle 17:20:10 what's about fix so that we can see test artifacts from gerrit? 17:20:20 tsufiev, done 17:20:40 sergmelikyan, hurray ) 17:21:18 sergmelikyan: is it really done? i haven't seen artifacts published along with job logs in case of job failure 17:22:16 iyozhikov, working on that 17:22:18 i'll just check 17:22:30 ok. let's move on then 17:22:34 ruhe, check https://murano-ci.mirantis.com/logs/02/103502/6/check/murano-dashboard-integration-tests-centos/23a4ae6/ 17:22:45 the recent patchset, they are here 17:22:57 #topic approval of BP dynamic-ui-specify-no-explicit-name-field 17:23:03 + 17:23:08 #link https://blueprints.launchpad.net/murano/+spec/dynamic-ui-specify-no-explicit-name-field 17:23:35 as we agreed on our last meeting, BPs should be approved by a consensus decision of the whole team 17:23:52 BP was discussed in a mail thread 17:23:54 #link http://lists.openstack.org/pipermail/openstack-dev/2014-July/040264.html 17:24:17 the discussion was about versioning 17:24:42 i'd like to let everyone comment on this BP before we move forward with the implementation 17:25:23 the email was about incrementing versions 17:25:56 sjmc7: right, mail thread covered only a small part of this bp 17:25:57 sjmc7, agree, but that was the most dubious thing in that BP 17:25:58 i agree that no UI specific fields should be passed to the engine 17:26:19 but the reasoning seems wrong; it might be very useful to have 'name' for debugging 17:26:34 in terms of bumping the version number, no comment here, since we have no packages in the wild 17:26:59 stanlagun, are you here? 17:27:03 yep 17:27:38 sjmc7: would you like to postpone implementation and spend some time to discuss implementation details in BP spec? 17:27:50 there should be name. Just not as a class property. 17:28:13 i'm not really clear what the issue is 17:28:14 Maybe '?'/name will be the best place 17:28:59 i think storing UI-specific stuff separately is probably an ok solution 17:29:10 the issue is that only declared properties can appear inside object model. For everything else there is a special hidden place - '?' 17:29:17 sjmc7, the issue is actually with default MuranoPL behaviour with unknown attributes in input JSON: should it reject them and fail or should it ignore them silently? 17:29:20 I don't see any problem to keep name as a class property 17:29:39 tsufiev- if we know what they're called, they're not unexpected 17:29:42 In fact we use names quite often internally in workflows to generate some resource names 17:30:32 I think unexpected property should be ignored with warnings in logs 17:30:39 gokrokve: it is ok to have name where you want it and if you declare such property. The problem is that curent UI forces this property in every object no matter if it was declared or not 17:30:46 nobody will look at logs 17:30:59 gokrokve: this is how it works now and it is wrong 17:31:07 i'm a fan of aggressive validation where possible 17:31:34 gokrokve, dteselkin could tell you how much this approach is perilous :) 17:31:36 There is no good mechanism in Horizon to provide a feedback 17:31:37 because of such behavior it is very hard to catch type errors where you just mistype property name and default value was used instead 17:31:56 We will need to implement some form with results from API 17:31:58 sjmc7: agree. turns out we had warnings about indexes being too long for a long time and one day those warnings turned into errors 17:32:12 if deployment will fail it will be hard not to notice 17:33:03 we're getting those warnings now 17:33:12 I think in UI we need to have a form with validation. In this form we can show all errors and messages from API 17:33:12 if there are properties in object model that are not declared in MuranoPL it is 100% sign of programmer's mistake 17:33:43 the engine can refuse the deployment and make that clear in the deployment status. i don't like silent errors at all 17:34:03 sjmc7: 100% agree 17:34:05 I think the problem will partly go away when dynamic UI will be generated from MuranoPL classes 17:34:10 Agree. We need to have some reportings. 17:34:39 seem like we need to continue discussion on this blueprint elsewhere and postpone the implementation 17:35:11 tsufiev: when it will be generated it will become even more important to fail because if unknown property occurs in OM this is guaranteed to be a bug 17:35:23 sjmc7, stanlagun, tsufiev let's discuss this later :) It's look like hot topic 17:35:33 on the other hand, UI always needs a name for every manageable entity - to show it properly... but it could calculate the entity's name from some other sources - explicitly given name is not the only option 17:35:35 ruhe: it seems that we all agreed. Why postpone? 17:36:53 i'd like to ask everyone invovled in this discussion to leave your vote on blueprint's whiteboard 17:37:02 #link https://blueprints.launchpad.net/murano/+spec/dynamic-ui-specify-no-explicit-name-field 17:37:25 meanwhile i've moved definition status to 'discussion' 17:37:34 i suggest to move on 17:38:01 #topic [smurashov] BP cli-simple-read-only-tests 17:38:08 #link https://blueprints.launchpad.net/murano/+spec/cli-simple-read-only-tests 17:38:19 smurashov_: are you here? 17:38:30 yep 17:38:51 ruhe 17:38:54 i just did this one 17:39:08 er... wait, ignore that. this is CI ? 17:39:18 sorry, thought it meant unit tests, ignore me 17:39:31 ok :) 17:39:41 yes, these are tempest-like tests for client CLI interface 17:40:39 they're supposed to go into murano/functionaltests/cli and run in gate-murano-devstack-dsvm job 17:41:04 this job is triggered in every patch to murano, murano-dashboard and python-muranoclient 17:41:46 this BP has a good description and work plan 17:41:54 agreed 17:42:06 does anyone have conserns or improvement suggestions about it? 17:42:54 no 17:43:13 ok then. i'm going to approve it for juno-3 17:43:33 #agreed to approve https://blueprints.launchpad.net/murano/+spec/cli-simple-read-only-tests 17:43:58 #topic [sjmc7] Discsus auth trusts; how much of a big deal, pitfalls? 17:44:05 #link https://blueprints.launchpad.net/murano/+spec/auth-for-long-running-requests 17:44:07 sjmc7: please 17:44:25 yeah.. i know this came up for Heat 17:44:28 so they moved to using Trusts 17:44:43 it's slightly more complicated for murano since really it needs deferred trusts, but i think we can make do with what is there 17:45:07 but HP's already had problems with launching deployments with horizon tokens where the user logs out and the token becomes invalid 17:45:23 so in my opinion we need to try to reduce that risk, but i wanted some feedback 17:45:38 I think we need to start doing this BP and final solution will be shaped during implementation. We can start, as sjmc7 mentioned with partial solution and improve it alongside with Trusts improvements 17:45:40 thats sad( 17:45:56 i put some more details onto the etherpad in there 17:46:11 and i'm intending to implement it soon if everyone agrees it's something needs looking at 17:47:05 i kind of agree with sergmelikyan. since no one has a clear view how this can be done, we should continue with sjmc7's plan and see how it goes (hopefully, well) 17:47:14 :) 17:47:18 + for approve 17:47:20 ok 17:48:22 sjmc7: one of my colleagues involved with keystone might help with this. i'll point him to your BP and patches once they arrive 17:48:41 ok 17:48:54 #agreed to approve https://blueprints.launchpad.net/murano/+spec/auth-for-long-running-requests 17:49:08 nex topic is... 17:49:15 s/nex/next 17:49:18 #topic Important bugs we need to fix 17:49:31 lets investigate cons and pros of trusts before implementing something 17:50:22 stanlagun: that's the plan. sjmc7 will work on this and it'll be the investigation part 17:50:31 well, i don't know of any other solution 17:51:04 even if there are no other solutions I'd like to no cons of this one in advance 17:51:13 *to know 17:51:38 i guess they'll show up soone and sjmc7 will notify us about them 17:51:43 http://j.mp/murano-j-bugs 17:51:53 I think we don't have much new bugs since last meeting 17:51:55 yes, let's get back to the topic 17:52:44 i'm worried about those two critical bugs. sergmelikyan, stanlagun: do you have a plan how to fix those? 17:53:03 ruhe, stanlagun is working on one of them, and I will start on next one soon. 17:53:34 just briefly, what's going to be the solution for tracking this better? 17:53:50 sjmc7, tracking bugs?\ 17:53:55 * sergmelikyan also suggest to review patches that are already submitted for some of the bugs 17:53:57 sergmelikyan: stanlagun: as we agreed during last meeting - please publish your plan before you jump into the implementation 17:53:58 no. tracking deployments (and whether they fail) 17:54:05 and tracking environment deletion 17:54:41 ruhe, unfortunately I didn't started working on this issue yet 17:54:52 * sergmelikyan means investigating and writing plan 17:54:58 ruhe: there is no plan. It is already implemented. But there is a strange bug in RPC code and message doesn't get sent. So just need to fix that bug 17:55:04 ok, no worries. i'm interested in these two 17:55:10 so i will read what is available 17:55:34 sergmelikyan: i understand you had a lot on your plate, just please notify us when you're ready 17:55:48 sjmc7, regarding env deletion, briefly we need to convert delete phase to real action and make it behave as deploy (simular how Heat it does). 17:56:01 splendid, ok 17:56:51 any other 'hot' bugs to discuss? 17:57:22 ruhe, i would say this one: https://bugs.launchpad.net/murano/+bug/1334352 17:57:23 Launchpad bug 1334352 in murano "package loading makes repeat API calls" [High,Confirmed] 17:57:48 oh, yeah 17:57:50 that one's fun 17:58:08 but I am not sure that there is something to discuss about this bug. This is just need to be done. Really incorrect work with packages 17:58:33 yeah, i agree. i had some more thoughts i can add to the bug report, but doesn't need a big discussion 17:58:35 this bug might turn into a blueprint about proper package caching mechanism 17:58:58 sjmc7, I would appreciate that. This code is mostly written by me :'( 17:59:03 ok. let's have couple of minutes for open discussion 17:59:06 yeah - there're two parts; caching, and not making loads of requests for one package 17:59:20 #topic open discussion 17:59:37 did we miss something to discuss today? 18:00:15 folks, please don't forget to comment on https://blueprints.launchpad.net/murano/+spec/dynamic-ui-specify-no-explicit-name-field 18:00:57 all right. thanks everyone. i'll be travelling next week. sergmelikyan will chair the meeting 18:01:10 #endmeeting