17:00:40 <sergmelikyan> #startmeeting murano
17:00:41 <openstack> Meeting started Tue Oct 13 17:00:40 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:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:44 <openstack> The meeting name has been set to 'murano'
17:00:51 <Nikolay_St> hi
17:00:52 <sergmelikyan> Hi folks! o/
17:00:59 <StanLagun> o/
17:01:04 <katyafervnt2> 0/
17:01:22 <vahidh> o/
17:02:33 <kzaitsev_mb> 0/
17:03:00 <ativelkov> o/
17:03:06 <freerunner> o/
17:03:37 <sergmelikyan> #topic Action Items Review
17:03:48 <sergmelikyan> #1 discuss https://bugs.launchpad.net/murano/+bug/1502437 severity with Serg, continue considering fixes.
17:03:48 <openstack> Launchpad bug 1502437 in murano mitaka "Murano picks cidr for subnet which is already used" [High,Confirmed] - Assigned to Alexander Tivelkov (ativelkov)
17:04:08 <sergmelikyan> folks, looks like we unable to fix this until release, ativelkov can you confirm that?
17:04:11 <ativelkov> I think I can give an update on this one
17:04:31 <ativelkov> sergmelikyan: there is no way easy way to fix it properly
17:04:50 <ativelkov> but there is a good workaround to dramatically reduce the chances of this thing happening
17:05:38 <ativelkov> It is to increase the value of max_environments setting in the config from 20 to 250
17:06:19 <sergmelikyan> I think we should leave a comment on the bug and mark as won't fix for Liberty
17:06:58 <sergmelikyan> and then see if we can backport it when we will have fix in Mitaka
17:07:00 <ativelkov> So, you don't want the config change to happen in L?
17:07:19 <sergmelikyan> ativelkov: you propose to change default value in config right now?
17:07:19 <kzaitsev_mb> I've makred it with kilo/liberty backport potential
17:07:31 <sergmelikyan> I didn't realize that
17:07:45 <sergmelikyan> 250 - not too much?
17:07:48 <ativelkov> The proper fix will require us to do a MAJOR redesign of murano engine, this is unlikely to be backported. The simple fix still can be backported
17:07:59 <sergmelikyan> why 250
17:08:11 <ativelkov> cause it gives us 250 unique CIDRs per env
17:08:21 <ativelkov> theoretically we may have more :)
17:08:34 <ativelkov> but 250 is quite ok
17:08:55 <ativelkov> it will give you cidrs of 10.0.1.0/24 - 10.0.255.0/24
17:09:31 <ativelkov> It is not a complete solution though
17:09:33 <sergmelikyan> ativelkov: than let's change configuration file for Liberty :) But not mark this bug as fixed
17:09:38 <ativelkov> As the collision are still possible
17:09:51 <sergmelikyan> ativelkov: I understand
17:10:34 <ativelkov> Also, there is a better fix which we may do in Mitaka
17:11:15 <ativelkov> It is to generate cidrs not in engine, but at the API (when we generate Network objects for newly created nets)
17:11:55 <ativelkov> The API has access to DB, so it may do the proper locking
17:12:11 <ativelkov> and ensure that the generated cidrs are unique
17:12:26 <sergmelikyan> ativelkov: I propose to go with configuration change in Liberty, explain what we did in comment message and mark bug as won't fix
17:12:40 <ativelkov> OK
17:12:43 <ativelkov> I'll do that
17:12:47 <sergmelikyan> and see later how to proceed in Mitaka :)
17:13:13 <sergmelikyan> We have release in 2 days, sorry for me being so focused on Liberty :(
17:13:25 <ativelkov> np, I perfectly understand that
17:13:44 <ativelkov> So, I'll submit the patch to stable/liberty today
17:13:56 <StanLagun> we haven't decided yet if we are going to increment versions of core library / MuranoPL format for L
17:14:07 <ativelkov> #action ativelkov to change the max_environments setting in stable/liberty
17:14:41 <katyafervnt2> StanLagun: that's a good question
17:15:07 <sergmelikyan> #topic Increment Version of Core Library
17:15:47 <StanLagun> I think we should do it
17:16:11 <sergmelikyan> StanLagun: bearing in mind that versioning is still experimental in Libery, what do you propose we should do with that?
17:16:32 <StanLagun> Otherwise it is impossible for applications to specify that they require yaql 1.0 (via Format: MuranoPL/1.1) or Liberty core library (via its version)
17:16:47 <StanLagun> It is still backward compatible
17:17:09 <StanLagun> But Murano Kilo will refuse to load applications having Format MuranoPL/1.1
17:17:29 <StanLagun> so this is a guard from attempting to use yaql 1 functions on Kilo
17:18:32 <sergmelikyan> StanLagun: seems right, ativelkov you opinion?
17:18:39 <sergmelikyan> kzaitsev_mb, katyafervnt2?
17:18:46 <ativelkov> I am with StanLagun here
17:19:08 <ativelkov> As I want to get rid of yaql legacy mode usage in murano
17:19:12 <StanLagun> Another question is if we are going to ship 2 versions of core library or just one considering no one could fix on 0.0.0
17:19:36 <sergmelikyan> StanLagun: I propose to finish with first question first )
17:19:43 <StanLagun> yes, we already have 1.1 unofficially and it doesn't uses legacy mode
17:19:45 <kzaitsev_mb> I'm... not entirely sure
17:19:54 <katyafervnt2> I'm also voting for increasing version in L
17:19:55 <sergmelikyan> ativelkov: but it's still will be possible, I mean liberty will run kilo apps
17:20:16 <ativelkov> sergmelikyan: yes, but these are two different engines
17:20:38 <StanLagun> both 1.0 and 1.1 will be supported
17:21:08 <sergmelikyan> ativelkov: not exactly, it's just running YAQL in Legacy mode?
17:21:50 <ativelkov> sergmelikyan: these are different classes for muranopl runtime
17:21:58 <ativelkov> 1.0 and 1.1
17:22:08 <ativelkov> 1.0 uses yaql legacy and 1.1 does not
17:22:18 <StanLagun> I'd say different modes
17:22:34 <ativelkov> yup
17:22:41 <kzaitsev_mb> the adoption is slow, but if we do not push it it would be even slower
17:22:52 <kzaitsev_mb> the adoption of new features I mean..
17:22:59 <StanLagun> there is a code that determines if legacy mode should be enabled based on format version. This is done for each function independently
17:23:09 <sergmelikyan> Ok then, let's do that
17:23:17 <katyafervnt2> does engine require some modifications? to support both versions and switch to legacy mode if needed?
17:23:22 <kzaitsev_mb> of new muranopl features I mean
17:23:41 <kzaitsev_mb> man, my head is fuzzy these days...
17:23:57 <StanLagun> It already supports switching. The only thing that need to be added is version constant to compare with
17:23:58 <sergmelikyan> #agreed to increase version of MuranoPL Format version
17:24:08 <StanLagun> what about core library?
17:24:12 <kzaitsev_mb> katyafervnt2: StanLagun: I believe it already supports both versions.
17:24:33 <sergmelikyan> StanLagun: I just realised that we don't have much time left to verify all our apps
17:24:50 <StanLagun> kzaitsev_mb, probably not 1.1. There is 1.0 and ongoing development 2.0. 1.1 will be kind of backport
17:25:15 <StanLagun> There is no need to verify all of the apps
17:25:39 <StanLagun> If we agree to increment core library version meta folder will contain both 0.0.0 and 0.1.0
17:26:19 <StanLagun> oh, I'm wrong here
17:26:26 <sergmelikyan> I would propose to not increase version of core library
17:26:40 <sergmelikyan> versioning itself still experimental
17:26:53 <sergmelikyan> and even not working properly
17:27:11 <sergmelikyan> given number of bugs regarding this in Mitaka
17:27:18 <sergmelikyan> which are not fixed in Liberty
17:28:36 <StanLagun> if we not increment version is will still have a version 0.0.0. This may be okay but it uses yaql 1.0 inside so there is no way for apps to say they require Kilo core library
17:30:11 <StanLagun> So the question is if we want Liberty CL to be distinguishable from Kilo one
17:30:36 <sergmelikyan> StanLagun: do I understand correctly that you propose just to increase version of current core library in Liberty (and NOT put two of them in Liberty), and if versioning is switched off it does not make difference?
17:30:40 <StanLagun> because apps have requirement on 0.*.* anyway so the change from 0.0.0 to 0.1.0 changes nothing here
17:31:04 <sergmelikyan> *does not make any difference from apps point of view
17:31:17 <StanLagun> sergmelikyan, yes, thats correct. Currently we have only one version of CL
17:31:35 <StanLagun> but in Mitaka we will develop second version, not modify current
17:31:44 <sergmelikyan> Then, this means we will not break any current apps
17:32:23 <StanLagun> no, we will not unless someone said he require 0.0.0 explicitly
17:32:35 <StanLagun> Maybe we need to consider shipping Kilo as 0.0.0 then
17:33:06 <sergmelikyan> StanLagun: it is buy default right? I don't think we should gather all of them in one folder
17:33:10 <sergmelikyan> *by
17:33:44 <StanLagun> sergmelikyan, we should unless we distribute core library via app-catalog etc
17:33:52 <StanLagun> or via plugin
17:34:30 <StanLagun> we may leave Liberty as 0.0.0 so there will be single CL for now
17:34:56 <StanLagun> To be honest I don't know myself what is better. Just giving the options
17:35:15 <sergmelikyan> When you don't know what it's better, better do nothing :)
17:35:38 <sergmelikyan> in this case we can leave as it is, and then if needed change in stable/liberty
17:35:50 <StanLagun> may be. But if we do nothing it will be impossible to have Kilo and Liberty CL in the same repo ever
17:36:37 <katyafervnt2> if we'll have a request we do backports
17:36:44 <katyafervnt2> *can do
17:36:45 <sergmelikyan> it's may be ok... given current number of app, that we updating them, and fact that versioning will be working only with Mitaka release
17:37:57 <StanLagun> anyway the version we release now must become frozen. So no modifications there. And then we need to think how to avoid 2 copies of the same code in 2 folders
17:38:14 <StanLagun> we could do this for murano-apps but not for CL
17:38:28 <sergmelikyan> #startvote Should we update version of CL now? Yes, No
17:38:29 <openstack> Begin voting on: Should we update version of CL now? Valid vote options are Yes, No.
17:38:30 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
17:38:34 <sergmelikyan> #vote No
17:39:02 <ativelkov> #vote No
17:39:05 <sergmelikyan> StanLagun: easy - liberty folder is available in Liberty branch
17:39:21 <StanLagun> sergmelikyan, not that easy
17:39:22 <Nikolay_St> #vote No
17:39:29 <StanLagun> #vote No
17:39:46 <katyafervnt2> #vote No
17:39:59 <katyafervnt2> I'm with you :)
17:40:06 <sergmelikyan> #endvote
17:40:07 <openstack> Voted on "Should we update version of CL now?" Results are
17:40:08 <openstack> No (5): Nikolay_St, StanLagun, katyafervnt2, ativelkov, sergmelikyan
17:40:24 <StanLagun> sergmelikyan, anyway *all* versions of CL must be imported during installation of Murano.
17:40:28 <kzaitsev_mb> wow that was a fast 2-minute vote =)
17:40:41 <sergmelikyan> #agreed that we are not updating CL version
17:40:53 <sergmelikyan> kzaitsev_mb: majority
17:40:54 <sergmelikyan> :)
17:41:55 <StanLagun> the things that worries me is that 1.0 -> 1.1 update is not a bug, but it has to be backported to stable/liberty
17:43:31 <sergmelikyan> StanLagun: I am not sure that it will be required
17:44:11 <StanLagun> The whole point of this is to be possible to require Liberty runtime buy saying MuranpPL/1.1
17:44:44 <StanLagun> *by saying Format: MuranoPL/1.1*
17:44:49 <sergmelikyan> MuranoPL/1.1 is a one thing, version of core library is another right?
17:44:54 <StanLagun> yes
17:45:50 <StanLagun> But current core library requires yaql 1.0 so it may be reasonable so specify 1.1 there as well
17:46:18 <StanLagun> but then it need to be tested because it may require yaql legacy mode
17:47:21 * sergmelikyan feeling that he and Stan eating meeting time
17:47:30 <sergmelikyan> Than we can test this before merging :)
17:48:12 <sergmelikyan> StanLagun: please propose change and let's see. If we will not be able to make sure that everything is working like we planning - we will not merge this in Liberty
17:48:27 <StanLagun> ok, lets proceed
17:49:24 <sergmelikyan> We have one more bug assigned but not fixed in Liberty https://bugs.launchpad.net/bugs/1504135
17:49:24 <openstack> Launchpad bug 1504135 in murano mitaka "Murano-engine utilizes 100% of CPU" [High,Confirmed]
17:49:29 <sergmelikyan> we even don't know details...
17:49:53 <sergmelikyan> We will be able to look at this bug before release?
17:51:19 <sergmelikyan> ativelkov: ^
17:51:41 <ativelkov> I am not sure. It happens only during the rally testing
17:52:12 <ativelkov> I could not reproduce it locally
17:53:08 <sergmelikyan> Then I propose to remove from liberty and mark as backport potential https://bugs.launchpad.net/bugs/1504135
17:53:09 <openstack> Launchpad bug 1504135 in murano mitaka "Murano-engine utilizes 100% of CPU" [High,Confirmed]
17:53:49 <sergmelikyan> objections?
17:54:11 <StanLagun> none
17:54:15 <Nikolay_St> nope
17:54:27 <ativelkov> ++
17:56:30 <Nikolay_St> oh
17:56:42 <Nikolay_St> serge has quit
17:57:04 <StanLagun> but he promised to come back some day :)
17:57:08 <Nikolay_St> :D
17:57:19 <sergmelikyan> sorry, got disconnected :(
17:57:24 <sergmelikyan> any objections?
17:57:39 <Nikolay_St> no objections)
17:57:42 <katyafervnt2> everybody has no :)
17:57:47 <sergmelikyan> #agreed remove from liberty and mark as backport potential https://bugs.launchpad.net/bugs/1504135
17:57:47 <openstack> Launchpad bug 1504135 in murano mitaka "Murano-engine utilizes 100% of CPU" [High,Confirmed]
17:57:49 <katyafervnt2> *says
17:57:56 <sergmelikyan> then let's finish on this note :)
17:57:58 <sergmelikyan> #endmeeting