17:01:11 <ruhe> #startmeeting murano
17:01:12 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:15 <openstack> The meeting name has been set to 'murano'
17:01:23 <ruhe> #link https://wiki.openstack.org/wiki/Meetings/MuranoAgenda#Agenda
17:01:39 <ruhe> katyafervent2: hi
17:01:39 <sergmelikyan> o/
17:01:43 <stanlagun> hi
17:01:51 <iyozhikov> hi
17:02:16 <tsufiev> hi
17:02:29 <sjmc7> hi
17:02:50 <ruhe> ok. we have a quorum. i hope more people will join soon
17:02:58 <ruhe> #topic action items review
17:03:15 <ruhe> first AI is - ruhe: create stackforge/murano-apps project for apps from murano-app-incubator
17:03:40 <ruhe> 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 <katyafervent2> great!
17:04:19 <ruhe> 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 <sergmelikyan> ruhe, this is right. Currently our app-incubator is quite far from what we hope it is should be
17:04:54 <ruhe> 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 <ruhe> there are no more action item from previous meeting. let's move on
17:05:39 <ruhe> #topic [katyafervent] provide an update on horizon/dashboard/selenium tests research
17:05:46 <ruhe> katyafervent2: please
17:06:20 <katyafervent2> it turns out, that there are just a few tests in horizon that use selenium
17:07:06 <ruhe> tsufiev: i believe you also researched this area in horizon?
17:07:14 <tsufiev> ruhe, yep
17:07:15 <katyafervent2> in integration tests they prerared infrustructure, and currently just one test is ready in this section
17:07:41 <tsufiev> ruhe, there are integration tests and unit-tests
17:07:58 <katyafervent2> it uses page object model to make selenium tests clear and easier to refactor
17:08:34 <tsufiev> 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 <katyafervent2> and i guess that we found the solution about hiw dashboard tests could be run on the openstack Jenkins
17:09:01 <ruhe> 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 <tsufiev> 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 <katyafervent2> right, and it will be possiable to run tests on devstack installation
17:10:20 <ruhe> katyafervent2: when will it be possible?
17:10:24 <sjmc7> ruhe - let's do this in russian and see how i do with grammar :)
17:10:51 <katyafervent2> since all improvements will be tested and merged
17:11:23 <ruhe> sjmc7: good idea, we should try that ;)
17:11:31 <ruhe> katyafervent2: do you have a patch on review?
17:11:44 <ruhe> i could test it on devstack
17:12:06 <katyafervent2> there are two of them right niw abd the third is coming
17:12:06 <tsufiev> 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 <tsufiev> then muranodashboard will be tested independently from murano-api
17:13:24 <ruhe> 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 <tsufiev> ruhe, exactly
17:13:39 <katyafervent2> tsufiev but we still need in integration tests
17:14:16 <tsufiev> katyafervent, i don't doubt that integration tests are needed
17:14:23 <ruhe> 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 <tsufiev> it's just an approach to writing Selenium unit tests
17:14:36 <katyafervent2> tsufiev thats a lit of work - you need to mock all calls
17:15:02 <tsufiev> 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 <ruhe> katyafervent2: tsufiev: will you please follow up on this in an etherpad document?
17:15:16 <tsufiev> I've mocked only openstack_auth
17:16:08 <tsufiev> ruhe, yes
17:16:15 <ruhe> tsufiev: this look promisiong
17:16:20 <ruhe> ok. thank you
17:16:39 <ruhe> #action katyafervent2 and tsufiev follow up on selenium testing in an etherpad document
17:17:06 <ruhe> #topic Current state of Murano testing
17:17:25 <ruhe> i'd like to provide a briefe update on murano-ci
17:17:51 <ruhe> murano-ci has been flaky for a long time. and there are several reasons for that
17:18:04 <ruhe> we're working on stabilisation step by step
17:18:52 <ruhe> 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 <ruhe> any updates or questions on this topic?
17:20:04 <sjmc7> no. but we need it stabkle
17:20:10 <tsufiev> what's about fix so that we can see test artifacts from gerrit?
17:20:20 <sergmelikyan> tsufiev, done
17:20:40 <tsufiev> sergmelikyan, hurray )
17:21:18 <ruhe> sergmelikyan: is it really done? i haven't seen artifacts published along with job logs in case of job failure
17:22:16 <katyafervent2> iyozhikov, working on that
17:22:18 <iyozhikov> i'll just check
17:22:30 <ruhe> ok. let's move on then
17:22:34 <tsufiev> ruhe, check https://murano-ci.mirantis.com/logs/02/103502/6/check/murano-dashboard-integration-tests-centos/23a4ae6/
17:22:45 <tsufiev> the recent patchset, they are here
17:22:57 <ruhe> #topic approval of BP dynamic-ui-specify-no-explicit-name-field
17:23:03 <sergmelikyan> +
17:23:08 <ruhe> #link https://blueprints.launchpad.net/murano/+spec/dynamic-ui-specify-no-explicit-name-field
17:23:35 <ruhe> as we agreed on our last meeting, BPs should be approved by a consensus decision of the whole team
17:23:52 <ruhe> BP was discussed in a mail thread
17:23:54 <ruhe> #link http://lists.openstack.org/pipermail/openstack-dev/2014-July/040264.html
17:24:17 <sjmc7> the discussion was about versioning
17:24:42 <ruhe> i'd like to let everyone comment on this BP before we move forward with the implementation
17:25:23 <sjmc7> the email was about incrementing versions
17:25:56 <ruhe> sjmc7: right, mail thread covered only a small part of this bp
17:25:57 <tsufiev> sjmc7, agree, but that was the most dubious thing in that BP
17:25:58 <sjmc7> i agree that no UI specific fields should be passed to the engine
17:26:19 <sjmc7> but the reasoning seems wrong; it might be very useful to have 'name' for debugging
17:26:34 <sjmc7> in terms of bumping the version number, no comment here, since we have no packages in the wild
17:26:59 <tsufiev> stanlagun, are you here?
17:27:03 <stanlagun> yep
17:27:38 <ruhe> sjmc7: would you like to postpone implementation and spend some time to discuss implementation details in BP spec?
17:27:50 <stanlagun> there should be name. Just not as a class property.
17:28:13 <sjmc7> i'm not really clear what the issue is
17:28:14 <stanlagun> Maybe '?'/name will be the best place
17:28:59 <sjmc7> i think storing UI-specific stuff separately is probably an ok solution
17:29:10 <stanlagun> the issue is that only declared properties can appear inside object model. For everything else there is a special hidden place - '?'
17:29:17 <tsufiev> 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 <gokrokve> I don't see any problem to keep name as a class property
17:29:39 <sjmc7> tsufiev- if we know what they're called, they're not unexpected
17:29:42 <gokrokve> In fact we use names quite often internally in workflows to generate some resource names
17:30:32 <gokrokve> I think unexpected property should be ignored with warnings in logs
17:30:39 <stanlagun> 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 <sjmc7> nobody will look at logs
17:30:59 <stanlagun> gokrokve: this is how it works now and it is wrong
17:31:07 <sjmc7> i'm a fan of aggressive validation where possible
17:31:34 <tsufiev> gokrokve, dteselkin could tell you how much this approach is perilous :)
17:31:36 <gokrokve> There is no good mechanism in Horizon to provide a feedback
17:31:37 <stanlagun> 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 <gokrokve> We will need to implement some form with results from API
17:31:58 <ruhe> 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 <stanlagun> if deployment will fail it will be hard not to notice
17:33:03 <sjmc7> we're getting those warnings now
17:33:12 <gokrokve> 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 <stanlagun> if there are properties in object model that are not declared in MuranoPL it is 100% sign of programmer's mistake
17:33:43 <sjmc7> 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 <stanlagun> sjmc7: 100% agree
17:34:05 <tsufiev> I think the problem will partly go away when dynamic UI will be generated from MuranoPL classes
17:34:10 <gokrokve> Agree. We need to have some reportings.
17:34:39 <ruhe> seem like we need to continue discussion on this blueprint elsewhere and postpone the implementation
17:35:11 <stanlagun> 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 <sergmelikyan> sjmc7, stanlagun, tsufiev let's discuss this later :) It's look like hot topic
17:35:33 <tsufiev> 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 <stanlagun> ruhe: it seems that we all agreed. Why postpone?
17:36:53 <ruhe> i'd like to ask everyone invovled in this discussion to leave your vote on blueprint's whiteboard
17:37:02 <ruhe> #link https://blueprints.launchpad.net/murano/+spec/dynamic-ui-specify-no-explicit-name-field
17:37:25 <ruhe> meanwhile i've moved definition status to 'discussion'
17:37:34 <ruhe> i suggest to move on
17:38:01 <ruhe> #topic [smurashov] BP cli-simple-read-only-tests
17:38:08 <ruhe> #link https://blueprints.launchpad.net/murano/+spec/cli-simple-read-only-tests
17:38:19 <ruhe> smurashov_: are you here?
17:38:30 <smurashov_> yep
17:38:51 <sjmc7> ruhe
17:38:54 <sjmc7> i just did this one
17:39:08 <sjmc7> er... wait, ignore that. this is CI ?
17:39:18 <sjmc7> sorry, thought it meant unit tests, ignore me
17:39:31 <ruhe> ok :)
17:39:41 <ruhe> yes, these are tempest-like tests for client CLI interface
17:40:39 <ruhe> they're supposed to go into murano/functionaltests/cli and run in gate-murano-devstack-dsvm job
17:41:04 <ruhe> this job is triggered in every patch to murano, murano-dashboard and python-muranoclient
17:41:46 <ruhe> this BP has a good description and work plan
17:41:54 <sjmc7> agreed
17:42:06 <ruhe> does anyone have conserns or improvement suggestions about it?
17:42:54 <katyafervent2> no
17:43:13 <ruhe> ok then. i'm going to approve it for juno-3
17:43:33 <ruhe> #agreed to approve https://blueprints.launchpad.net/murano/+spec/cli-simple-read-only-tests
17:43:58 <ruhe> #topic [sjmc7] Discsus auth trusts; how much of a big deal, pitfalls?
17:44:05 <ruhe> #link https://blueprints.launchpad.net/murano/+spec/auth-for-long-running-requests
17:44:07 <ruhe> sjmc7: please
17:44:25 <sjmc7> yeah.. i know this came up for Heat
17:44:28 <sjmc7> so they moved to using Trusts
17:44:43 <sjmc7> 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 <sjmc7> 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 <sjmc7> so in my opinion we need to try to reduce that risk, but i wanted some feedback
17:45:38 <sergmelikyan> 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 <katyafervent2> thats sad(
17:45:56 <sjmc7> i put some more details onto the etherpad in there
17:46:11 <sjmc7> and i'm intending to implement it soon if everyone agrees it's something needs looking at
17:47:05 <ruhe> 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 <sjmc7> :)
17:47:18 <sergmelikyan> + for approve
17:47:20 <sjmc7> ok
17:48:22 <ruhe> 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 <sjmc7> ok
17:48:54 <ruhe> #agreed to approve https://blueprints.launchpad.net/murano/+spec/auth-for-long-running-requests
17:49:08 <ruhe> nex topic is...
17:49:15 <ruhe> s/nex/next
17:49:18 <ruhe> #topic Important bugs we need to fix
17:49:31 <stanlagun> lets investigate cons and pros of trusts before implementing something
17:50:22 <ruhe> stanlagun: that's the plan. sjmc7 will work on this and it'll be the investigation part
17:50:31 <sjmc7> well, i don't know of any other solution
17:51:04 <stanlagun> even if there are no other solutions I'd like to no cons of this one in advance
17:51:13 <stanlagun> *to know
17:51:38 <ruhe> i guess they'll show up soone and sjmc7 will notify us about them
17:51:43 <sergmelikyan> http://j.mp/murano-j-bugs
17:51:53 <sergmelikyan> I think we don't have much new bugs since last meeting
17:51:55 <ruhe> yes, let's get back to the topic
17:52:44 <ruhe> i'm worried about those two critical bugs. sergmelikyan, stanlagun: do you have a plan how to fix those?
17:53:03 <sergmelikyan> ruhe, stanlagun is working on one of them, and I will start on next one soon.
17:53:34 <sjmc7> just briefly, what's going to be the solution for tracking this better?
17:53:50 <sergmelikyan> sjmc7, tracking bugs?\
17:53:55 * sergmelikyan also suggest to review patches that are already submitted for some of the bugs
17:53:57 <ruhe> sergmelikyan: stanlagun: as we agreed during last meeting - please publish your plan before you jump into the implementation
17:53:58 <sjmc7> no. tracking deployments (and whether they fail)
17:54:05 <sjmc7> and tracking environment deletion
17:54:41 <sergmelikyan> ruhe, unfortunately I didn't started working on this issue yet
17:54:52 * sergmelikyan means investigating and writing plan
17:54:58 <stanlagun> 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 <sjmc7> ok, no worries. i'm interested in these two
17:55:10 <sjmc7> so i will read what is available
17:55:34 <ruhe> sergmelikyan: i understand you had a lot on your plate, just please notify us when you're ready
17:55:48 <sergmelikyan> 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 <sjmc7> splendid, ok
17:56:51 <ruhe> any other 'hot' bugs to discuss?
17:57:22 <sergmelikyan> ruhe, i would say this one: https://bugs.launchpad.net/murano/+bug/1334352
17:57:23 <uvirtbot> Launchpad bug 1334352 in murano "package loading makes repeat API calls" [High,Confirmed]
17:57:48 <sjmc7> oh, yeah
17:57:50 <sjmc7> that one's fun
17:58:08 <sergmelikyan> 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 <sjmc7> 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 <ruhe> this bug might turn into a blueprint about proper package caching mechanism
17:58:58 <sergmelikyan> sjmc7, I would appreciate that. This code is mostly written by me :'(
17:59:03 <ruhe> ok. let's have couple of minutes for open discussion
17:59:06 <sjmc7> yeah - there're two parts; caching, and not making loads of requests for one package
17:59:20 <ruhe> #topic open discussion
17:59:37 <ruhe> did we miss something to discuss today?
18:00:15 <ruhe> folks, please don't forget to comment on https://blueprints.launchpad.net/murano/+spec/dynamic-ui-specify-no-explicit-name-field
18:00:57 <ruhe> all right. thanks everyone. i'll be travelling next week. sergmelikyan will chair the meeting
18:01:10 <ruhe> #endmeeting