17:00:42 <sergmelikyan> #startmeeting Murano
17:00:43 <openstack> Meeting started Tue Jan 20 17:00:42 2015 UTC and is due to finish in 60 minutes.  The chair is sergmelikyan. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:46 <openstack> The meeting name has been set to 'murano'
17:00:50 <sergmelikyan> Hi guys!
17:00:51 <ruhe> o/
17:00:54 <katyafervent> Hi!
17:01:01 <OndrejVojta> hi
17:01:11 <sergmelikyan> #topic Action Items Review
17:01:52 <sergmelikyan> I think I've forgot to record  Action Items from previous meeting, but I am pretty sure that we have question about YAQL
17:02:00 <sergmelikyan> Stan?
17:03:17 <katyafervent> Is Stan here?
17:03:22 <ruhe> i've pinged him
17:04:15 <ruhe> i believe it was one of the main action items from the previous meeting :)
17:04:27 <ruhe> ok. let me cover Stan :)
17:04:43 <katyafervent> We have no AI, but anyone can suggest topic to discuss later in this meeting
17:04:56 <ruhe> Here is what I know about progress in yaql:
17:05:10 <ruhe> 1. Code and spec almost finished
17:05:19 <ruhe> 2. Now Stan is fixing remaining issues and bugs
17:05:43 <ruhe> 3. It should appear on review by EOW
17:06:05 <katyafervent> Cool, so on the next week we will be able to review the specification
17:06:25 <ruhe> yeah, i hope maybe even earlier
17:07:48 <ruhe> ok. Stan is still not here. I guess we should move on unless there are questions related to yaql
17:07:55 <katyafervent> Do you know, after new YAQL will be merged, will Murano require any changes to support new version?
17:08:27 <katyafervent> Does anyone have questions about YAQL?
17:08:29 <ruhe> katyafervent: according to Stan there should be some changes in muranopl
17:08:36 <dteselkin> Hi
17:08:49 <katyafervent> Hi dteselkin !
17:08:50 <ruhe> which means that versioning support is a must have for Kilo
17:08:55 <henar> hi
17:09:02 <katyafervent> hi henar !
17:09:35 <katyafervent> ruhe, yeah, we should support version in in Kilo
17:09:47 <katyafervent> *versioning
17:10:26 * ruhe is a temporary for sergmelikyan on this meeting :)
17:10:37 <ruhe> * temporary substitue
17:10:43 <ruhe> ok. let's move on
17:10:48 <sergmelikyan> :)
17:11:09 <ruhe> sergmelikyan: you're back. take the control of the meeting then
17:11:25 <sergmelikyan> Let's move on to the next meeting item?
17:11:30 <sergmelikyan> ruhe, thx :)
17:12:21 <sergmelikyan> #topic Juno 2014.2.1 Release
17:13:24 <sergmelikyan> I've found one nasty bug in our Juno release that is main reason for the releasing 2014.2.1 maintenance release
17:13:49 <ruhe> can you give us a link?
17:14:00 <sergmelikyan> https://bugs.launchpad.net/bugs/1412164
17:14:09 <sergmelikyan> ruhe, sure ^
17:14:19 <sergmelikyan> https://launchpad.net/murano/+milestone/2014.2.1
17:15:05 <sergmelikyan> Alongside I decided that once we anyway going to release 2014.2.1 we can backport some other fixes there
17:15:24 <sergmelikyan> All bugs mentioned on https://launchpad.net/murano/+milestone/2014.2.1 already backported
17:15:28 <ruhe> so, that nasty bug affects only upstream testing. it shouldn't affect any existing deployments, unless people deploy productin from pip :)
17:16:06 <sergmelikyan> or have already built packages with wrong dependencies
17:16:19 <sergmelikyan> btw, another one is https://bugs.launchpad.net/bugs/1392102
17:18:08 <sergmelikyan> so, do we have any other things that we need to backport?
17:19:26 <ruhe> sergmelikyan: i don't have anything else on my mind
17:20:08 <katyafervent> me too, there are no serious bugs were fixed
17:20:42 <sergmelikyan> I plan to release 2014.2.1 in a few days, so if anything critical will be found for Murano Juno, please assign bug for 2014.2.1
17:23:01 <ruhe> ok
17:24:28 <sergmelikyan> I have nothing else on agenda, do anyone have anything specific or let's move to the Open Discussion?
17:26:59 <sergmelikyan> #topic Open Discussion
17:27:59 <FilipBlaha> Hi Serg and others, we would like to get feedback to our changes. Which was not merged to master
17:28:05 <OndrejVojta> i have question about my review https://review.openstack.org/#/c/142458, if you had chance to look at it or if you need something from me
17:29:03 <FilipBlaha> and https://review.openstack.org/#/c/147515/
17:30:44 <sergmelikyan> I started reviewing both changes, but had no chance to do it properly, that is why there is no feedback from my side yet
17:31:05 <sergmelikyan> Generally they look pretty good, I just like to play with them first before approving
17:31:11 <OndrejVojta> ok
17:31:47 <FilipBlaha> ok, thanks
17:32:44 <sergmelikyan> Filip, I see you resolved question about changing configuration of Murano?
17:35:03 <FilipBlaha> Murano CI job needs to be modified if we want policy enforcment fuctional tests to be part of Murano CI job
17:35:44 <sergmelikyan> dteselkin is responsible for maintenance of Murano CI
17:35:50 <FilipBlaha> should be policy enforcement functional tests part of Murano CI job?
17:37:00 <FilipBlaha> https://github.com/stackforge/murano-deployment there are scripts preparing devstack environment for Murano CI
17:37:17 <sergmelikyan> I would say there is no reason to duplicate running of same tests on both CI
17:37:26 <sergmelikyan> FilipBlaha, yeah, exactly
17:37:39 <sergmelikyan> We can have more heavy tests on Murano CI
17:38:43 <FilipBlaha> I agree so we should add policy enf tests to Murano CI ?
17:39:27 <sergmelikyan> Definitely, but later when we will be able to deploy application and verify whole policy enf staff with Mistral and so on
17:39:52 <sergmelikyan> I think we should start to cover policy enf with tests on Murano CI when we will have MVP
17:40:23 <ruhe> dsvm job is a good starting point, we should keep as much tests there as possible
17:40:42 <sergmelikyan> +1
17:41:02 <ruhe> and only if it is not possible to add some specific test to dsvm, this test should be considered for Murano CI
17:42:59 <ruhe> and this case would be the one which requires deployment of murano applications with real-world software
17:45:05 <FilipBlaha> I dont know exactly the difference between dsvm and Murano CI tests but we need launch deployment in our tests
17:46:19 <FilipBlaha> I did not find such test in dsvm tests maybe I missed something
17:46:55 <sergmelikyan> Main difference is that Murano CI is running on much more powerfull VMs, where you can do actual deployment
17:47:18 <sergmelikyan> That is why we keep deployment-based tests on Murano CI and all other stuff on DSVM
17:50:11 <FilipBlaha> so from this point of view should be our tests in Murano CI?
17:50:42 <sergmelikyan> When they will do real deployment of heavy apps - yes
17:51:30 <FilipBlaha> they deploy telnet however deployment is aborted due to policy violation
17:52:18 <FilipBlaha> if test goes right way
17:53:06 <katyafervent2> so you dont need to spawn an instance?
17:53:14 <sergmelikyan> I think in that case is no reason to deploy telnet, you can just create special app that does not spin-up VM
17:54:56 <FilipBlaha> Ok I will consider to do it more lightweight. We thank that functional test should do somethink real-world
17:55:57 <sergmelikyan> OpenStack CI gives only 8 Gb of RAM for VM with DevStack where DSVM tests are running
17:56:24 <FilipBlaha> katya: is test goes right way then instance is not created since deployment is aborted by policy enforcement
17:56:26 <sergmelikyan> It should be more then enough for any tests that are not spawning heavy VMs
17:56:47 <sergmelikyan> But enough to spawn VM with Cirros for example
17:57:52 <FilipBlaha> ok thanks , I will consider dsvm tests
17:58:42 <sergmelikyan> FilipBlaha, np
17:58:46 <sergmelikyan> Thank you, guys!
17:58:50 <sergmelikyan> #endmeeting