17:00:53 <sergmelikyan> #startmeeting murano
17:00:54 <openstack> Meeting started Tue Apr 29 17:00:53 2014 UTC and is due to finish in 60 minutes.  The chair is sergmelikyan. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:55 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:57 <openstack> The meeting name has been set to 'murano'
17:01:15 <sergmelikyan> #topic Roll Call
17:01:18 <sergmelikyan> Serg Melikyan
17:01:33 <sjmc7> Steve McLellan (sjmc7)
17:02:06 <katyafervent2> Kate F.
17:02:08 <dteselkin_> Dmitry Teselkin
17:02:41 <btully> Brian Tully
17:03:12 <tsufiev__> hi there!
17:03:18 <sergmelikyan> Welcome to Murano Weekly Meeting :)
17:03:36 <sergmelikyan> #topic Action Items Review
17:03:54 <sergmelikyan> #link https://wiki.openstack.org/wiki/Meetings/MuranoAgenda
17:04:14 <sergmelikyan> I believe we have only one Action Item - file a BP to track conversion of existing apps to the new DSL
17:04:35 <sergmelikyan> This AI on me, status done: https://blueprints.launchpad.net/murano/+spec/convert-existing-apps-to-muranopl
17:05:36 <sergmelikyan> Sorry, other one on ativelkov: Advanced Networking
17:06:03 <sergmelikyan> AFAIK, Alexander finished Advanced Networking today, and also did Floating IP feature.
17:06:30 <sergmelikyan> Now there is a option in UI (like in previous version) to allocate Floating IP for Application :)
17:06:51 <sjmc7> yay! does the floating IP get reported back anywhere?
17:06:54 <tsufiev__> sergmelikyan: it is still on review
17:06:55 <sergmelikyan> We expect Security Groups also be finished as task related to Advanced networking.
17:07:25 <katyafervent2> It should appears at app detail page
17:07:30 <sjmc7> splendid
17:07:34 <katyafervent2> inside environment
17:07:37 <sjmc7> thanks!
17:08:05 <sergmelikyan> tsufiev__, yes, one last change related to AdvNetworking )
17:08:36 <sergmelikyan> Other questions about AdvNetworking, or we moving on? :)
17:09:52 <sergmelikyan> #topic Release Status
17:10:18 <sergmelikyan> Status of all BP's and issues are in actual state: https://launchpad.net/murano/+milestone/0.5
17:11:02 <sergmelikyan> We planned to have code-freeze today, do we ready?
17:11:05 <sergmelikyan> tsufiev?
17:12:04 <tsufiev__> sergmelikyan: there are still several commits on review
17:12:11 <tsufiev__> with -1 from murano-ci
17:12:47 <sergmelikyan> :(
17:13:00 <tsufiev__> exactly, 2 commits with -1 from murano-ci and one with -1 from tnurlyagayanov
17:13:43 <tsufiev__> I don't know whether murano-ci is relevant now or not - better ask our QA
17:14:14 <sergmelikyan> tnurlygayanov ? ) Does this -1 from murano-ci relevant or related to our CI being on maintance?
17:15:24 <sergmelikyan> Looking on changes - I think they will be merged today :)
17:16:00 <tsufiev__> yes, I hope so :)
17:16:13 <sergmelikyan> Guys, a little notice about code-freeze procedure: We branching our release-0.5 branch, and all changes related to release goes to that branch
17:16:40 <sergmelikyan> Only bug-fixes, security fixes are get merged to release-0.5 branch.
17:17:08 <sergmelikyan> After branch is stable enough - we tag it we appropriate tag
17:17:33 <sergmelikyan> to push changes to specific branch - just mention branch name: git review release-0.5
17:17:48 <sergmelikyan> change will be published to release-0.5 branch
17:18:32 <tsufiev__> sergmelikyan: i suspect it'd better for one man to do it
17:18:49 <tsufiev__> by man i mean ruhe :)
17:19:02 <katyafervent2> :)
17:19:09 <sergmelikyan> tsufiev__, sure
17:19:38 <sergmelikyan> Actually who does create branches not really matter, I think :)
17:20:04 <sergmelikyan> #info ruhe to create release-0.5 branches after announcing code-freeze
17:20:33 <tsufiev__> oh, i meant mostly final 0.5 tagging
17:20:50 <sergmelikyan> #info code-freeze will be announced after all release-0.5 relevant  changes going to be merged
17:21:01 <sergmelikyan> tsufiev__, ok )
17:21:40 <sergmelikyan> #info ruhe to tag release-0.5 branch with appropriate tag after release
17:22:00 <sergmelikyan> katyafervent, can you share some details about documentation for this release?
17:22:14 <sergmelikyan> this almost only still open blueprint
17:22:24 <sergmelikyan> *this is
17:22:52 <katyafervent2> User guide is updated, developer docs were updated by ruhe and located at the read the docs
17:23:24 <katyafervent2> we plan to extend read the dohttps://murano-api.readthedocs.org/en/latest/
17:23:31 <katyafervent2> https://murano-api.readthedocs.org/en/latest/
17:23:46 <katyafervent2> to extend this page with information from wiki
17:24:18 <katyafervent2> and plan to add some more information, about MuranoPL for ex.
17:24:52 <katyafervent2> So documentation status is about 75% ready
17:25:48 <katyafervent2> Do you have any questions or we can move on?
17:26:37 <sergmelikyan> katyafervent, actually status looks not so good :( But I think that not-developer documentation (located in separate repo) may be finished after code-freeze.
17:26:58 <katyafervent2> sure
17:27:13 <sergmelikyan> katyafervent, let's move on :) Next still open BP is also on you: https://blueprints.launchpad.net/murano/+spec/add-return-to-environment-checkbox
17:27:25 <sergmelikyan> sorry
17:27:38 <sergmelikyan> wrong one :) It is already implemented :)
17:27:57 <sergmelikyan> "Convert existing Apps to MuranoPL" - is on me :)
17:28:29 <sergmelikyan> Looks like we have only 4 apps not converted to the new MuranoPL: IIS, ASP.NET, SQL Server, SQL Cluster
17:28:47 <sergmelikyan> I think last one will not be converted in this release :( Too heavy one
17:29:13 <katyafervent2> Too complex you mean?
17:29:59 <sergmelikyan> It is not as much complex, as have too many scripts and parts that are hard to debug
17:30:34 <sergmelikyan> But other Apps have pretty good chance to be converted.
17:30:58 <sergmelikyan> We extracted all apps to https://github.com/murano-project/murano-app-incubator
17:31:03 <tsufiev__> better to improve MuranoPL debugging first, either debugging SQL Cluster will be a nightmare :)
17:31:05 <sergmelikyan> simular to stackforge
17:31:05 <sjmc7> as a sort of aside, it would be great to have a way of verifying packages without having to deploy them
17:31:11 <sjmc7> agreed tsufiev__ :)
17:31:14 <sergmelikyan> simular to stackforge/heat-templates
17:31:31 <sergmelikyan> sjmc7, how do you see this? :)
17:31:58 <sjmc7> as a dream :)  not sure - something like heat's template-validate
17:32:03 <sergmelikyan> :)
17:32:06 <sjmc7> something for another day
17:32:20 <sergmelikyan> Let's move open discussion and discuss? :)
17:32:27 <sergmelikyan> #topic Open Discussion
17:32:55 <katyafervent2> we can create syntax validator
17:33:07 <sjmc7> currently, debugging is very difficult - some things could be made better by making sure heat errors and engine errors are reported better
17:33:16 <sjmc7> but yes katyafervent2, that would help also
17:33:38 <sergmelikyan> Package consist of several parts that needs to be validated: manifest.yaml - package manifest, may be easily validated without deployment.
17:33:51 <katyafervent2> sjmc7:will you create blueprint for that?
17:34:03 <sjmc7> it's things like variable names being mismatched that cause silent errors, heat template fragment errors
17:34:04 <katyafervent2> we can validate archive during uploading
17:34:38 <sergmelikyan> scripts - hard to be validated without deployment, and even with deployment this also hard to validate.
17:34:40 <sjmc7> katyafervent2 - yes, i will create a blueprint, though it might end up being done in several pieces
17:34:53 <tsufiev__> katyafervent2: unfortunately, we'll form modality if validation fails :(
17:34:59 <tsufiev__> *we'll lose
17:35:16 <sjmc7> sergmelikyan - yes, agreed, some stuff is harder to validate
17:35:16 <tsufiev__> that's how it is done in horizon for file uploads
17:36:00 <sergmelikyan> MuranoPL - this is most interesting parts :) I will try to share my thoughts about MuranoPL validation:
17:36:12 <sjmc7> there are already some tickets to improve how the engine reports errors i think
17:36:20 <katyafervent2> but if can validate smth before a deployment, let's do it
17:36:42 <sjmc7> this discussion could go forever :)
17:36:57 <tsufiev__> sjmc7: also i'd be interested to hear about UI improvement you spoke earlier
17:37:14 <tsufiev__> or have they all been already commited?
17:37:24 <sjmc7> tsufiev__ - no, we were waiting til the release
17:37:28 <sjmc7> ^til after
17:37:49 <tsufiev__> sergmelikyan: are we free to speak about plans for next release?
17:38:00 <sjmc7> btully will probably be the person that leads those changes
17:38:16 <sergmelikyan> 1)Input ObjectModel validation: should be handled by contracts, currently handled in two layers: UI with UI definition and dashboard processing, and Contracts & Types in Engine. Each of them have own pitfalls. Engine is a very like PoC one: almost no logging, no exception handling or debugging aid. One of the first priority thing in the next release.
17:38:23 <tsufiev__> sjmc7: ok. anyway, he can submit blueprints too
17:38:36 <sergmelikyan> tsufiev__, why not?
17:39:33 <sergmelikyan> UI Validation - not sure that will be improved above what we have now in the next release. Should be completely superseeded by Contract & Types validation in UI
17:40:13 <tsufiev__> sergmelikyan: speaking of data validation on UI side... we've spoken recently with ativelkov about porting YAQL to JavaScript - which should make field validation much easier using YAQL expressions (get rid of hand-written javascript code)
17:40:34 <ativelkov> Hi folks, sorry for being soo late today
17:40:52 <sergmelikyan> tsufiev__, but leaves duplication :(
17:41:25 <tsufiev__> so, i've investigated a bit and found that there is a Jison js-library similary to ply used in python YAQL - and it can be used for that purpose
17:41:42 <sergmelikyan> 2)Murano PL validation: may be tested in several ways. Core functions available in YAQL may be tested by unit-tests, Core Library may be tested by our MuranoPL testing tool - we can mock calls to the actual services and test workflow execution or some language constructs
17:41:46 <tsufiev__> sergmelikyan: which duplication do you actually mean?
17:42:09 <sergmelikyan> tsufiev__, duplication of Contracts in class properties and validators in UI definition
17:42:49 <sergmelikyan> UI definition is a kind of a hack, I think, we had no time to make proper dynamic ui that relies only on application description/
17:43:19 <ativelkov> sergmelikyan: Not exactly
17:43:21 <tsufiev__> sergmelikyan: yes, seamless converting MuranoPL contracts into UI looks like a distant perspective
17:43:43 <ativelkov> I don't think this is possible and is a goal
17:44:13 <tsufiev__> ativelkov: why shouldn't we consider it as a goal??
17:44:21 <ativelkov> Because UI is always richer then app definition
17:44:23 <sjmc7> i'll create a blueprint and we can add ideas to it? I think there are lots of things that would help that can be done at different times
17:44:35 <ativelkov> And we will not be able to generate a complete UI based on it
17:44:44 <ativelkov> So, UI definition will always be needed
17:45:12 <sergmelikyan> sjmc7, sure! We can discuss in etherpad/google doc as much more easy tools to hold discussion in
17:46:02 <ativelkov> However, we may think about some notation which will map fields in IU definition to properties of class declarations, and if the latter have contracts, they will be inforced on the former
17:46:14 <sergmelikyan> ativelkov, but I think in a little bit other form, more like ui hints - to help with presentation layer, not validation
17:46:27 <ativelkov> sergmelikyan: yes, exactly
17:46:48 <tsufiev__> ativelkov: i'd put it that way: for the UI to be reach enough we would have to add additional hints to MuranoPL classes making them less focused on deployment/ALM/such things
17:47:05 <tsufiev__> (if we are to make UI defs from MuranoPL classes)
17:47:12 <ativelkov> tsufiev__: right, and we don't want that
17:47:27 <ativelkov> So, the UI definition will define user controls and map them to MuranoPL classes
17:47:49 <ativelkov> this will enforce the contracts (yet additional validation and automation may be added on UI-only side)
17:47:52 <sergmelikyan> sjmc7, I suggest to create BP and attach etherpad/google doc. We can discuss there some ideas and latter have some workshop/brainstorm discussion in hangout. This is very important topic.
17:48:00 <sjmc7> yep, will do
17:48:10 <sjmc7> told you this could go on forever :)
17:48:37 <ativelkov> Currently we just have instance templates, which manually copy the data from forms to the model. This may be improved
17:49:44 <tsufiev__> ativelkov: this templates/applications sections actually have not much common with UI
17:49:55 <sergmelikyan> sjmc7, we need to start from something :) I really hate debugging in current state of the engine - is almost like wooodoo magic
17:50:08 <sjmc7> yes. it is very frustrating
17:50:09 <tsufiev__> they were added as a temporary solution :) - to fit plain forms to new tree-like object model
17:50:19 <ativelkov> sergmelikyan: it is not "like the magic", it is the magic itself
17:50:22 <sergmelikyan> :) Especially with event driven code :)
17:51:42 <tsufiev__> ativelkov: so they are better to be moved somewhere else
17:52:26 <ativelkov> As I said, I would follow some MVC-like pattern
17:53:30 <ativelkov> UI definitions define the view, model is provided by the MuranoPL class declarations, "Controller" is represented by YAQL expressions that bind M to V
17:54:03 <tsufiev__> so the question is where the 'Controller' should reside?
17:54:50 <ativelkov> This needs to be discussed
17:55:16 <ativelkov> In simple case it is just a "binding" yaql expression in field's declararion
17:55:34 <sergmelikyan> ativelkov, I see it blended with app definition, something like in Cloudify. But this needs discussion and some time to think about :) UI-hints blended with app definition is my vision from top of the head - probably wrong one :)
17:55:37 <ativelkov> However, there are repeated patterns and more, and this needs to be defined somhow and somewhere
17:57:18 <tsufiev__> another issue will be the necessity to maintain backward compatibility with existing templates/definitions - thus we'll have to desing it well from the beginning...
17:58:09 <ativelkov> A hell of template compatibility.. Yes, may be an issue
17:58:23 <sergmelikyan> I think we can drop that compatibility by offering some simple convertion tool
17:58:47 <sergmelikyan> Let's wrap-up :) Time is ticking out :)
17:59:05 <sergmelikyan> #endmeeting