16:59:29 <sergmelikyan> #startmeeting murano
16:59:29 <openstack> Meeting started Tue Jan 27 16:59:29 2015 UTC and is due to finish in 60 minutes.  The chair is sergmelikyan. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:59:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:59:32 <openstack> The meeting name has been set to 'murano'
16:59:44 <sergmelikyan> Hi guys!
16:59:57 <katyafervent2> hi
17:00:18 <slagun> o/
17:02:34 <sergmelikyan> I see most of the us are here :) Hi, henar, OndrejVojta, RadekPospisil
17:02:38 <sergmelikyan> Let's start meeting :)
17:02:47 <OndrejVojta> hi
17:03:03 <RadekPospisil> hi
17:03:08 <sergmelikyan> Our agenda is available on the wiki as always: https://wiki.openstack.org/wiki/Meetings/MuranoAgenda
17:03:23 <henar> good afternoon
17:03:42 <sergmelikyan> So let's start with second item of the agenda, cause we don't have AI's from previous meeting: http://eavesdrop.openstack.org/meetings/murano/2015/murano.2015-01-20-17.00.html
17:04:04 <sergmelikyan> #topic Big-fix release for stable/juno
17:04:40 <sergmelikyan> I was planning to release 2014.2.1 on the last week, but we found another issue on the Friday, so release slipped a little bit
17:05:12 <katyafervent2> how is the progress of this bug?
17:05:36 <sergmelikyan> henar, RadekPospisil, if you use Juno version for testing, is better to use stable/juno branch instead of 2014.2 tag
17:05:59 <sergmelikyan> katyafervent, https://bugs.launchpad.net/bugs/1414072
17:06:26 <sergmelikyan> I was talking about this one, and it is already fixed
17:07:19 <sergmelikyan> I don't get it, how we this nasty thing slipped though our hands  :(
17:08:30 <sergmelikyan> Let's move to the next topic?
17:08:43 <henar> ok
17:09:46 <katyafervent2> thank you lets move on
17:10:59 <sergmelikyan> #topic Log Messages localization
17:11:17 <sergmelikyan> It's really hot topic, Kate, can you provide some context?
17:11:26 <sergmelikyan> I think this topic is proposed by you
17:12:34 <katyafervent2> we need to discuss should we add lig translation or not
17:14:36 <slagun> I think we shouldn't
17:15:22 <katyafervent2> Stan could you provide facts, why we shoul not do that
17:15:39 <sergmelikyan> katyafervent, ok, as far as I know there was several discussions in OpenStack, can you summarize them for us? Or may be links?
17:18:00 <slagun> log files are not intended for end users. Those are for operators/administrators and they in turn may send them to application developer for bug investigation. We (as Murano team) will be not ready to help users with Chinese logs for example
17:18:13 <slagun> also you cannot grep such log
17:18:38 <katyafervent2> give me one minite
17:18:47 <slagun> IMO only messages presented in UI should be localized
17:21:20 <sergmelikyan> Any other thoughts on this topic?
17:21:49 <katyafervent2> I agreed, sorry cant paste the link
17:22:02 <sergmelikyan> In the oslo.i18n project there is a guide how to translate log messages: http://docs.openstack.org/developer/oslo.i18n/guidelines.html#log-translation
17:22:40 <sergmelikyan> But I think this guide does not specify directly that all projects need to translate log messages.
17:23:37 <katyafervent2> if we accept teanslation, we need to test it and we have no time for that
17:23:45 <sergmelikyan> katyafervent, I propose to gather more information, best practices and so on, before deciding anything, sticking with current approach for now (not translating log messages & exceptions)
17:23:52 <katyafervent2> so stay with no
17:24:10 <sergmelikyan> katyafervent, can you look at this matter a little bit more?
17:24:52 <OndrejVojta> exception can be localized because there is also stack trace so we know the line even when localized
17:25:49 <katyafervent2> ok
17:26:17 <sergmelikyan> #action katyafervent, research more about log/exception localization
17:26:43 <sergmelikyan> And let's return to this topic in the mailing list than
17:27:09 <sergmelikyan> ...sticking with current approach for now...
17:27:20 <sergmelikyan> #topic YAQL
17:27:49 <sergmelikyan> slagun, can you update on this topic?
17:27:51 <slagun> that was my topic :)
17:28:13 <slagun> so we have YAQL 1.0 almost ready
17:28:34 <slagun> and it is a great step forward for both yaql and Murano
17:28:50 <slagun> the problem is that it was rewritten like almost from scratch
17:29:04 <slagun> so it is extremely hard to break it into small commits
17:30:05 <slagun> so what I suggest is to have it in single large commit and single spec. That is not so bad as it may sound because yaql 1.0 have great unit test coverage so there is no need to review every single line of code
17:30:50 <slagun> and then to migrate Murano to it shortly after we release it
17:31:04 <slagun> and help Mistral to do the same
17:31:20 <RadekPospisil> what parts of Murano code will be affected by the change?
17:31:50 <RadekPospisil> e.g.  only murano/dsl, or murano/engine, ...
17:32:51 <slagun> Murano uses yaql 0.2.x and will not migrate to 1.0 automatically. Migration requires changes to dsl package for engine and also to murano-dashboard that also uses yaql 0.2
17:33:14 <RadekPospisil> ok, thanks
17:34:12 <sergmelikyan> I would say this is kinda extreme proposal, but I get the point. What about pushing it as one commit, and one spec. Make a thoughtful review on spec, regarding functionality. Make sure that all parts of code is covered by unit-tests, and fix some issues that are not bugs, and don't break PEP-8 check on the gate later.
17:35:08 <RadekPospisil> will the change to YAQL 1.0 require changes in existing packages (i.e., classes)?
17:35:46 <slagun> yes. Lets review it but not merge it before spec is merged and before we achieve real high UT coverage
17:36:05 <sergmelikyan> Yeah, that was I was saying
17:36:24 <slagun> RadekPospisil: there are some breaking changes but with 99% chance you won't have to change anything
17:36:40 <RadekPospisil> ok
17:36:55 <sergmelikyan> We need to have special section in spec regarding breaking chagnes
17:37:29 <OndrejVojta> are coverage reports available somewhere in jenkins?
17:37:56 <slagun> there are no more tuples (but dict(a=>b, c=>d) still works) and there is no filtration using $collection[predicade] syntax (use $collection.where(predicate) instead). If you are not using one of those you don't need to change anything
17:39:32 <sergmelikyan> OndrejVojta, yes, it generated for each OpenStack CI unit-tests check
17:41:28 <sergmelikyan> at least I thought so, maybe something changed :(
17:43:30 <sergmelikyan> #agreed slagun will push yaql 1.0 as one commit. We will ensure functionality reviewing the spec, and quality by making sure that we have good coverage (80% at least) by UT
17:44:00 <sergmelikyan> #topic Advanced image filtering
17:44:13 <sergmelikyan> katyafervent, you proposed this topic?
17:45:07 <katyafervent2> yes
17:45:34 <katyafervent2> I want to add feature of dynamic image filtering in kilo
17:46:26 <katyafervent2> Thus application owner provides image requirements in application definition
17:46:44 <sergmelikyan> we planned to implement this feature using Metadata Repository that is going to be available in L
17:46:44 <katyafervent2> and via image metadata images will be filters in dashboard
17:46:49 <sergmelikyan> what's changed?
17:47:37 <katyafervent2> Stan suggest setting requirement with Yaql, so I will summer up the ideas and change the blueprint
17:48:12 <sergmelikyan> How to set requirements is one question, where to store them and how to query them is another
17:48:22 <katyafervent2> but docker apps will be added in kilo, and if no docker installed on image - the deployment will failed silintly
17:48:55 <sergmelikyan> They are already working in MOX without this feature :)
17:49:00 <sergmelikyan> in production :)
17:49:07 <katyafervent2> But all changes should be summered in the one spesification
17:49:28 <katyafervent2> Ok, if we don't need that feature - let's continue to the next topic
17:49:37 <sergmelikyan> Let's try to catch-up with Travis regarding MetadataDef and think about how to have proper interface for this feature using YAQL
17:50:18 <sergmelikyan> We definitely need this feature, but I would propose to start with thinking about implementation details and put spec in place, and implement in L
17:50:46 <sergmelikyan> katyafervent, you agree?
17:51:43 <katyafervent2> Well, I suggest to assign it to kilo with low priority and if we will not find time for it - will move it to L
17:51:56 <sergmelikyan> Why?
17:52:46 <katyafervent2> Cause kilo will be released in May, we have a chance to implement it in kilo
17:54:47 <katyafervent2> It's 5 minutes left, does anybody have questions for open discussion?
17:54:56 <sergmelikyan> Not sure about this :( Kilo - 2 in a few days, we even didn't started versioning
17:55:38 <sergmelikyan> Let's discus on which release to assign this feature when we will have a spec based on Metadata Defs and YAQL 1.0
17:56:01 <katyafervent2> it's just versioning left, will we implement it for months?
17:56:14 <sergmelikyan> I am sure that we will not be able to deliver this in K, cause Metadata Defs functionality from J may be not enough for us.
17:56:30 <sergmelikyan> And this feature depends on two others that are still not in source tree
17:57:24 <sergmelikyan> katyafervent, it's not a just versioning :) And I am sure that we will work on versioning  even in the next release - it is huge
17:58:01 <sergmelikyan> You agree about: "Let's discus on which release to assign this feature when we will have a spec based on Metadata Defs and YAQL 1.0@
17:58:05 <sergmelikyan> ?
17:58:35 <sergmelikyan> katyafervent, https://wiki.openstack.org/wiki/Murano/Roadmap#Unscoped <- what is left to do in K
17:59:20 <katyafervent2> ok, got it
18:00:24 <sergmelikyan> #endmeeting