17:00:08 <sergmelikyan> #startmeeting murano
17:00:08 <openstack> Meeting started Tue Apr  7 17:00:08 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:09 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:11 <openstack> The meeting name has been set to 'murano'
17:00:17 <sergmelikyan> Evening folks! o/
17:00:41 <velovec> Hi^^
17:00:46 <sergmelikyan> btw, is 17:00 UTC considered as evening? :)
17:01:23 <StanLagun> hi
17:01:59 <kzaitsev> all
17:02:20 <kzaitsev> > is 17:00 UTC considered as evening? :)
17:02:27 <kzaitsev> Time is haaaaarrrrd
17:02:33 <katyafervent> hey
17:03:11 <ativelkov> o/
17:03:17 <henar> hi
17:03:46 <sergmelikyan> We had no AIs from previous meeting :)
17:04:05 <sergmelikyan> Let's move to reviewing new features for Liberty?
17:04:18 <sergmelikyan> I saw few new BPs proposed by henar
17:04:44 <henar> if you want more information you can ask me. I am working on the spec for providing more information
17:04:50 <sergmelikyan> Let's walk through them?
17:04:55 <sergmelikyan> henar, thank you!
17:04:56 <sergmelikyan> https://blueprints.launchpad.net/murano/+spec/diff-networks-in-env-template
17:05:25 <sergmelikyan> "possibility of having different networks in the different applications which compose an environment template. "
17:05:52 <henar> yes, there are two ideas: i) the possibility to create as many networks as required in the env template /environment
17:05:58 <sergmelikyan> I see that we need ability to have different networks for applications at first to implement this blueprint
17:06:22 <henar> and ii) an application (VM) deploys on different networks
17:06:23 <sergmelikyan> henar, are both of them covered by this BP?
17:07:00 <henar> if they are not covered yet, it should be.. or it is better to split them?
17:07:46 <sergmelikyan> henar, I think they are should be in one BP
17:07:56 <henar> ok
17:08:07 <ativelkov> We've being discussing this for some time
17:08:31 <ativelkov> That's a really needed feature
17:08:55 <henar> perfect
17:09:16 <ativelkov> And it's proper implementation is quite complicated, as requires some major improvements in MuranoPL language and the way how we generate the object model
17:09:50 <ativelkov> But we definitely should start doing the first steps towards this direction
17:10:54 <sergmelikyan> I believe no one can object that it is needed feature :) => Approved
17:11:31 <sergmelikyan> #2 https://blueprints.launchpad.net/murano/+spec/abstract-env-template
17:12:08 <sergmelikyan> To be honest I didn't get idea of this BP after reading description :)
17:12:15 <sergmelikyan> * :(
17:12:27 <sergmelikyan> henar, can you elaborate a little bit?
17:12:33 <henar> the environment template catalogue implied the defiition of enviornment templates for a user. This blueprint tries to create environment templates to be customized and used by any user
17:13:16 <sergmelikyan> You mean UI for environment templates?
17:13:30 <henar> for instance, a environment template load balancer - web -server- database. Anyone can see this template in the environemnt template catalogue. In case the user wants to use, just cutomize it including the keypair
17:13:56 <henar> and the environmetne template is deployed
17:14:13 <henar> it no the GUI, is the catalogue for environment templates independent on user
17:14:28 <henar> it is quite simple to implement
17:15:06 <ativelkov> I don't quite get it.. what is the difference between this end a regular template?
17:15:24 <henar> as well as we have an application catalogue... we can have an environment template catalogue
17:15:57 <henar> we can say, abstract template has not an owner, and regular templates do
17:16:55 <ativelkov> Hmm
17:17:35 <ativelkov> Why don't we utilize the same sharing logic we have for Applications and Images?
17:17:41 <sergmelikyan> Do I understand correctly that in current version since we don't have ability to see env templates created by other users, we need a way to have shared env templates available to be copied to the own catalog?
17:17:42 <henar> and also it does not have user information (keypair..)
17:18:12 <henar> the abstract template catalogue will be populated by the administrator, no by users
17:18:47 <henar> so we are not sharing user templates, but creating typical templates by the administrator
17:19:04 <ativelkov> Ok, I think I understand now
17:19:08 <henar> in fiware, we have this feature for Genertic Enablers deployments
17:20:18 <ativelkov> So, we have actually two open questions here: 1) template ownership, 2) template completeness, i.e. "generic" templates may be missing some data intended to be supplied by user when they are converted to actual environments. Right?
17:21:11 <henar> yes
17:21:14 <ativelkov> good
17:21:25 <ativelkov> So, we may utilize an artifact repository for this
17:22:12 <ativelkov> If a template is an artifact, then it may be shared with other users directly or made public by administrator
17:22:34 <ativelkov> But it will be still owned by the user who initially uploaded it
17:22:55 <ativelkov> It will be just accessible to users other then owner
17:23:05 <sergmelikyan> ativelkov, I think we can migrate to this alongside with whole migration to artifacts, but I think this is easier to implement at first on current way of handling things
17:24:24 <ativelkov> Well, yes, if you add a "visibility_level" field to the current environment-template entity
17:24:50 <sergmelikyan> Let's discuss ideas at first, and then talk about implementation :)
17:25:05 <ativelkov> I just believe that there is no actual difference between "regular" and "generic" templates
17:25:34 <ativelkov> "generic" ones just don't have data for some of the fields
17:26:32 <henar> and they are accessible by everybody..
17:27:27 <ativelkov> I believe that these are independent things: you may want to share with everybody even your non-generic template
17:28:00 <henar> ok, I see your point..
17:28:15 <henar> the user administrator can have environment templates too
17:28:28 <henar> and then we can have like a field 'public'
17:28:32 <ativelkov> yes
17:28:51 <ativelkov> And then we may make a "clone" operation
17:29:29 <ativelkov> which creates a new template out of some existing template (probably a public one) by filling in some of its missing data
17:29:32 <henar> yes
17:29:51 <stan_lagun> this way we can have more than 2 levels of how generic template can be
17:29:56 <sergmelikyan> Let's postpone discussion of this idea, I see that we need more time to refine it
17:29:57 <ativelkov> And you may have as many clones as you want with the needed level of details
17:29:58 <henar> so that, it involes just to complete the API (with the clone operation) and a new field public
17:30:05 <stan_lagun> hierarchy of specialization
17:30:07 <ativelkov> right
17:30:14 <sergmelikyan> henar, you are still going to miss Summit this time?
17:30:22 <ativelkov> sergmelikyan: agree.
17:30:28 <henar> yes :-(
17:30:38 <sergmelikyan> :(
17:30:39 <ativelkov> henar: you may submit a spec and we may continue the discussion in the review
17:30:41 <stan_lagun> :(
17:30:56 <henar> sure
17:31:09 <stan_lagun> I think etherpad is a right place for discussions like this
17:31:16 <ativelkov> or we may create an etherpad if we need more decnical discussion
17:31:17 <sergmelikyan> We can start with voice discussion, summarize in ML  and then move to spec
17:32:03 <sergmelikyan> #action schedule discussion for https://blueprints.launchpad.net/murano/+spec/abstract-env-template
17:32:36 <sergmelikyan> #info approval postponed until further discussion for blueprint/abstract-env-template
17:32:49 <sergmelikyan> #3 https://blueprints.launchpad.net/murano/+spec/diff-regions-in-env-template
17:33:24 <sergmelikyan> Multi-region support, I believe we already have BP for that
17:33:34 <henar> the idea behind is the inclusion of region information in the the environment template /environment and the deployment of different applications from the same environment in different regiones
17:34:16 <sergmelikyan> oh... this is specific for templates and we have https://blueprints.launchpad.net/murano/+spec/multiple-heat-stacks
17:34:22 <sergmelikyan> as overall feature
17:35:11 <sergmelikyan> Yep, once we will have this feature we need support in env templates
17:35:27 <henar> yes
17:35:37 <henar> but most of the work I think it is there
17:36:12 <sergmelikyan> Direction: Approved :)
17:37:18 <sergmelikyan> henar, did we covered all proposed features?
17:37:29 <henar> yes, thanks
17:38:13 <sergmelikyan> #topic Python Lint in Murano Gates
17:39:07 <FilipBlaha> Hi, some openstack projects like sahara, manilla, cinder and others has this job
17:39:28 <sergmelikyan> FilipBlaha, have you checked how they decide +1/-1 for this gate?
17:39:54 <katyafervent> Is this job non-voiting for all of those projects?
17:40:10 <FilipBlaha> yes, they compare issue sets of current commit and the previos commit
17:40:23 <FilipBlaha> if there is new issue then -1
17:41:13 <FilipBlaha> I think is non-voting but not sure if it is true for all projects
17:42:00 <FilipBlaha> on the other hand nova project stop using it since they consider it no usefull
17:43:08 <sergmelikyan> If it's easy to enable we can start using and check how it's useful for us. Overall such tools are helpful, but it is very thin tunning
17:44:04 <FilipBlaha> yes , I agree I wolud start with similar configuration as other projects and tha we can tunr it
17:44:39 <kzaitsev> I like the idea, but want it to be non-voting =)
17:45:42 <FilipBlaha> yes , I agree I would start with similar configuration as other projects and than we can tune it   ... sorry for typos
17:46:57 <sergmelikyan> +1
17:47:01 <FilipBlaha> It should not be difficult to enable it
17:47:06 <ativelkov> +1, let's try it
17:47:39 * ativelkov hates when some AI pretends to be smarter then him, but is going to try it one more time
17:47:59 <stanLagun> +1 for non-voting just for experiment
17:48:01 <freerunner> +1 for this idea ;)
17:48:12 <sergmelikyan> #agreed enable pylint non-voting check job for Murano
17:48:30 <sergmelikyan> #topic Open Discussion
17:48:52 <stanLagun> henar: https://bugs.launchpad.net/murano/+bug/1441276
17:48:54 <openstack> Launchpad bug 1441276 in murano "[murano-agent] FormatVersion was not incremented" [Critical,New] - Assigned to Henar Muñoz (henar-munozfrutos)
17:49:12 <henar> thanks, I have just seen it
17:50:08 <henar> I have some Chef/Puppet package examples, where should I upload it? It is just for testing ..
17:51:26 <sergmelikyan> henar, I think examples should be published to murano-apps
17:51:55 <henar> √?
17:52:02 <henar> https://github.com/murano-project/murano-app-incubator?
17:52:22 <henar> or https://github.com/stackforge/murano-apps
17:52:27 <sergmelikyan> henar, if you are talking about usage examples, if you are talking about samples for tests - than it should go to same place where tests are going to be
17:52:38 <sergmelikyan> henar, github.com/stackforge/murano-apps
17:52:43 <henar> ok, thanks
17:52:57 <henar> usage examples..
17:53:06 <sergmelikyan> henar, than murano-apps
17:53:11 <sergmelikyan> We need to reformat our murano-apps repo
17:54:12 <sergmelikyan> murano-apps was intended to be a place for examples and for ready to use apps
17:54:41 <sergmelikyan> What do you think folks?
17:55:36 <stanLagun> sergmelikyan, agree, do you have a vision on new structure?
17:55:38 <ativelkov> I think that we need some CI jobs for all the apps in the "incubated" murano apps projet
17:56:08 <sergmelikyan> ativelkov, yeah - we already discussed that we are going to have CI based on rally
17:56:27 <sergmelikyan> User will be able to submit application + rally scenario for testing of this application
17:56:53 <ativelkov> sergmelikyan: Isn't rally an overkill?
17:57:02 <ativelkov> it's the load testing thingy
17:57:38 <sergmelikyan> ativelkov, not exactly
17:58:42 <sergmelikyan> ativelkov, nope don't have draft right now, will do by tomorrow
17:59:11 <sergmelikyan> #action propose new structure for murano-apps
17:59:30 <sergmelikyan> #endmeeting