17:02:55 <ruhe> #startmeeting murano
17:02:56 <openstack> Meeting started Tue May 27 17:02:55 2014 UTC and is due to finish in 60 minutes.  The chair is ruhe. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:02:57 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:02:59 <openstack> The meeting name has been set to 'murano'
17:03:09 <ruhe> #topic roll call
17:03:20 <tsufiev> Timur Sufiev
17:03:23 <ruhe> who's here for the meeting today?
17:03:49 <dteselkin_> Dmitry Teselkin
17:04:30 <katyafervent> Ekaterina Fedorova
17:04:49 <stan_lagun> Stan Lagun
17:05:13 <ruhe> woohoo. we have a quorum
17:05:25 <ruhe> #topic Action Items Review
17:05:50 <ruhe> i wasn't present on the last meeting. i don't see any action items in the logs
17:05:59 <ruhe> is that correct?
17:06:41 <ruhe> #topic Review roadmap for j-1
17:06:46 <katyafervent> Yes, it's
17:07:05 <ruhe> #link https://launchpad.net/murano/+milestone/juno-1
17:07:16 <ruhe> that's what we have planned for j-1 for now ^^
17:07:47 <ruhe> there are a couple of features we'd like to land in j-1
17:08:19 <ruhe> on of them is to allow users to use external Murano app repositories...
17:08:28 <katyafervent> It's just 10 blueprints
17:08:32 <tnurlygayanov_> yes
17:08:43 <tnurlygayanov_> external repositories it is interesting
17:08:59 <tsufiev> ruhe, interesting that normalize-dashboard-pagination is in list, while its dependency app-catalog-pagination doesn't
17:09:04 <ruhe> #link https://wiki.openstack.org/wiki/Juno_Release_Schedule
17:09:26 <ruhe> tsufiev: can you give me a link?
17:09:29 <tsufiev> ruhe, oh, sorry it does
17:09:34 <ruhe> k
17:09:50 <tnurlygayanov_> 10 bp for 2 weeks?
17:10:43 <ruhe> for people present here i believe that would be enough. I guess Steve and his team will add somthing to this list
17:11:04 <tnurlygayanov_> we have 3 bp's assignet to one man: Timur Sufiev
17:11:05 <tsufiev> btully, just in time :). we're currently discussing murano blueprints for J1
17:11:13 <tnurlygayanov_> is it ok?
17:11:19 <btully> sorry day back from a holiday weekend and i think our schedule's are confused
17:11:42 <tsufiev> tnurlygayanov_ yes, 2 of them are already implemented and on review now
17:11:50 <tnurlygayanov_> ou, ok
17:12:17 <btully> sounds good tsufiev
17:12:41 <ruhe> so, i'm going to add one more blueprint for external repositories. that'll allow users to use our app incubator any time anywhere
17:12:54 <ruhe> #action ruhe create blueprint for external repositories
17:13:01 <tnurlygayanov_> also I suggest to update status for blueprints with status'Unknown'
17:13:03 <tsufiev> btully, what do you think about https://blueprints.launchpad.net/murano/+spec/murano-ui-horizon-patterns ?
17:13:39 <btully> I added some work items to it on Friday. Did you see those?
17:14:06 <tsufiev> btully, yes. i mean, in terms of planning and J1 priorities
17:15:41 <btully> I'd be happy to start working on those work items with a TODO status, assuming george doesn't mind
17:15:56 <tnurlygayanov_> ruhe, let's update status of https://blueprints.launchpad.net/murano/+spec/alembic-migrations
17:16:10 <ruhe> tnurlygayanov_: there are only two BPs in unknown state. mine is really in unknown state, i plan to start working on it later this week. katyafervent: what about your BP https://blueprints.launchpad.net/murano/+spec/add-article-about-heat-templates-as-app-def
17:16:33 <tsufiev> to me, 'TODO' things in that blueprint can be easily done in J1... ruhe, does that mean we should split Brian's blueprint into several, one of which will be scheduled for J1?
17:16:37 <tnurlygayanov_> ok. we can set 'Not Started'.
17:17:44 <ruhe> tsufiev: you can split that blueprint into separate ones or just track every TODO items as a blueprint work item
17:17:52 <katyafervent> well, I'm writing demo about deploying from heat templates
17:18:14 <ruhe> tsufiev: btully: that's up to you how to track it. choose what you feel is more appropriate
17:18:16 <katyafervent> since it would be ready I'll have the material and update documentation
17:18:50 <btully> This is all new to me, so I guess whatever is easiest?
17:19:11 <ruhe> for me it is easier to track things in separate blueprints
17:19:53 <tsufiev> +1 for separate blueprints
17:20:01 <ruhe> btully: will you please create blueprints for items you would like to implement in J1?
17:21:12 <btully> so you mean, the blueprint i already created, seperate the TODO items into new blueprints, even though they are all dependencies?
17:21:55 <tsufiev> btully, i'd suggest to split the part you're going to do in J1 and add it as dependency to the original one
17:22:15 <ruhe> +1 to what tsufiev said
17:22:26 <btully> ok. and just to be clear, when is J1 (or where can I find out when J1 is on Launchpad)?
17:22:55 <tsufiev> btully, https://wiki.openstack.org/wiki/Juno_Release_Schedule
17:22:57 <ruhe> btully: here is release schedule for OpenStack (which we're following) https://wiki.openstack.org/wiki/Juno_Release_Schedule
17:23:31 <btully> ok, thanks
17:24:11 <ruhe> btully: j1 is a shortcut for juno-1 https://launchpad.net/murano/+milestone/juno-1 . you'll need to update "Milestone target" in your blueprints
17:24:35 <btully> ok
17:24:39 <ruhe> anything else on the topic "Review roadmap for j-1"?
17:25:07 <tsufiev> ruhe, frankly speaking i have some doubts about https://blueprints.launchpad.net/murano/+spec/dynamic-fields-on-service-details at J1
17:25:36 <ruhe> #action btully to create blueprints extracted from generic https://blueprints.launchpad.net/murano/+spec/murano-ui-horizon-patterns
17:25:58 <tsufiev> it requires changes in dynamic UI specification, and probably will break backwards compatibility
17:27:10 <ruhe> tsufiev: select from two options :) 1. postpone it right now 2. keep scheduled for j1 and postpone later, in case if it really couldn't be done in j1 timeframe
17:27:32 <tsufiev> ok, i select the (2)
17:28:17 <ruhe> any objections?
17:28:23 <tsufiev> it is enough time to implement it alone, just wanted to design new spec _right_ (and not in a hurry)
17:28:42 <ruhe> #agreed postpone https://blueprints.launchpad.net/murano/+spec/dynamic-fields-on-service-details
17:28:53 <ruhe> tsufiev: please remove milestone target from this BP
17:29:20 <tsufiev> ruhe, done
17:29:24 <ruhe> ok. we need to move to the next topic
17:29:55 <ruhe> #info agreed on the plan for j1. but we still expect more items from sjmc7
17:30:02 <ruhe> #topic Review blueprints for MuranoPL changes
17:30:10 <ruhe> stan_lagun: your turn
17:30:38 <btully> under "Propose for sprint" do I leave it as "nothing selected"?
17:31:04 <ruhe> btully: yes. this field is not used by OpenStack projects
17:31:07 <stan_lagun> I've submitted quite a big number of blueprints today
17:31:10 <btully> thanks
17:31:35 <stan_lagun> About fixing various issues in MuranoPL
17:31:51 <gokrokve_> Is there a BP for exception/error handling?
17:32:03 <stan_lagun> so i guess we need to decide which of them are going to be scheduled for J1
17:32:09 <stan_lagun> gokrokve_ yes
17:32:10 <gokrokve_> This is what we had in previous version but not in the current.
17:32:21 <stan_lagun> let me find
17:32:50 <stan_lagun> https://blueprints.launchpad.net/murano/+spec/muranopl-exception-handling
17:32:54 <gokrokve_> I think this is very important for now as without exception handling deployment will hang forever in some cases.
17:33:27 <gokrokve_> What is your ETA for this BP?
17:34:16 <stan_lagun> I think it is possible implement this BP and other debugging-related things in J1 time-frame if we concentrate on this
17:34:22 <ruhe> btully: one more request for you. please add me (ruhe) as an approver for your blueprints. (it's just a workaround for launchpad's inability to send notifications on new blieprints)
17:34:35 <btully> ok thanks
17:34:52 <stan_lagun> I mean 2 weeks of work for 1 dev should be enough
17:35:04 <btully> is your name "ruhe" in launchpad?
17:35:47 <btully> i see you (Ruslan) :)
17:35:48 <ruhe> btully: it's my id in launchpad. it should work. otherwise you can use a slightly longer version "Ruslan Kamaldinov" :)
17:36:20 <gokrokve_> stan_lagun: Cool. I vote to implement them at first.
17:36:39 <gokrokve_> Then deployment process will be controllable.
17:37:05 <ruhe> i support implementing error handling in j1
17:37:11 <stan_lagun> https://blueprints.launchpad.net/murano/+spec/muranopl-stack-traces
17:37:22 <stan_lagun> this is also part of debuggability
17:37:51 <ruhe> stan_lagun: you already have https://blueprints.launchpad.net/murano/+spec/hot-packages
17:37:56 <stan_lagun> This BP duplicates https://blueprints.launchpad.net/murano/+spec/muranopl-stacktrace :(
17:38:12 <ruhe> stan_lagun: will you be able to handle https://blueprints.launchpad.net/murano/+spec/muranopl-exception-handling in the same time?
17:38:37 <stan_lagun> HOT packages is nearly finished. One bug need to be addressed
17:38:45 <ruhe> stan_lagun: good
17:39:16 <ruhe> stan_lagun: can you please mark one of these "stacktrace" blueprints as a duplicate?
17:39:44 <stan_lagun> I also would like to improve debugability of contracts. I've written to ML on this
17:39:53 <stan_lagun> ok
17:39:54 <ruhe> stan_lagun: you'll need to change definition to "Superseded"
17:40:57 <ruhe> stan_lagun: you want to improve debugability of contracts also in J1?
17:41:08 <stan_lagun> yes
17:41:58 <stan_lagun> actually I already have prototype implementation that I'm going to commit as soon as we discuss all the details in ML
17:42:03 <gokrokve_> What else do we have in BPs?
17:42:20 <ruhe> stan_lagun: and you already filed a bug for that. i'd suggest to track this as a blueprint
17:42:46 <stan_lagun> ruhe, that bug is only part of the work
17:43:33 <ruhe> gokrokve_: it's seems like we have enough work items for J1. would you like to add more?
17:43:40 <stan_lagun> If you talking about https://bugs.launchpad.net/murano/+bug/1313694
17:43:54 <gokrokve_> No. That is fine to have couple important BPs for J1.
17:44:07 <gokrokve_> Smaller scope is better.
17:44:23 <ruhe> to summarize:
17:44:28 <stan_lagun> I'd like to add one more
17:44:29 <stan_lagun> https://blueprints.launchpad.net/murano/+spec/rename-workflow-to-methods
17:44:33 <gokrokve_> There will be a space to add other BPs as soon as Steve is back.
17:44:50 <ruhe> #info agreed to target https://blueprints.launchpad.net/murano/+spec/muranopl-exception-handling to J1
17:44:54 <stan_lagun> 30 minutes of work but very breaking change :)
17:44:55 <gokrokve_> stan_lagun: +1. It should be trivial change.
17:45:10 <stan_lagun> yes. But breaks 100% of existing apps
17:45:19 <ruhe> #info agreed to target https://blueprints.launchpad.net/murano/+spec/muranopl-stack-traces (or the other one with similar description) to J1
17:45:25 <gokrokve_> Can we do support both?
17:45:58 <stan_lagun> Yes, we can (and drop support for Workflow in K release, for example)
17:46:12 <gokrokve_> And then deprecate Workflows gradually providing autoconversion?
17:46:16 <gokrokve_> Ok.
17:46:18 <stan_lagun> But anyway I think we need to discuss how we handle breaking changes
17:46:37 <ruhe> gokrokve_: stan_lagun: i think we need a wider audience to discuss such changes. would it make sense to bring this topic to ML?
17:46:38 <gokrokve_> Sure. And we need to change version of th format to reflect the change.
17:47:07 <gokrokve_> Lets explore what we can do and then show options to community in ML.
17:47:18 <ruhe> ok
17:47:28 <stan_lagun> Versioning is another big future that is missing
17:47:59 <ruhe> we definitely need versioning in Juno
17:48:21 <stan_lagun> yep. But not in J1
17:48:27 <ruhe> stan_lagun: agree
17:48:46 <ruhe> any other items to discuss in this topic?
17:49:11 <stan_lagun> 1 topic from my side
17:49:19 <ruhe> stan_lagun: sure
17:49:28 <stan_lagun> Contract improvements that I've written in ML
17:50:03 <stan_lagun> They also introduce breaking change. Although it is very unlikely to break anything
17:50:57 <gokrokve_> I think we are not in danger here as our curent contracts are very simple.
17:51:28 <stan_lagun> gokrokve_ I suggest to simplify contracts
17:51:48 <stan_lagun> But maybe we need to agree on breaking changes before making such commits
17:52:06 <gokrokve_> That is fine. Again, can we support both old and new versions of syntax?
17:52:21 <stan_lagun> no
17:52:28 <stan_lagun> syntax is the same
17:52:35 <stan_lagun> semantic differences
17:53:22 <stan_lagun> but the difference is only noticeable for corner cases
17:54:15 <gokrokve_> So both variants will be supported? Where is a breaking change?
17:54:28 <stan_lagun> no, only one variant
17:54:49 <ruhe> stan_lagun: to make these changes transparent i suggest to prepare a patch to app incubator which updates all app definitiions before you send a patch that changes MuranoPL
17:54:59 <tsufiev> gokrokve_, the same contract will mean different things after these changes
17:55:15 <stan_lagun> no incubator app will break
17:56:15 <stan_lagun> for example currently $.int() means int or null. With my changes it would mean just int and null will be converted to 0
17:56:27 <gokrokve_> stan_lagun: Then it is ok to introduce this change.
17:56:46 <ruhe> 4 minutes left. we have one more topic to discuss
17:56:58 <gokrokve_> Just do this ASAP as 0.5 just released and it will take month or two when it will be actually used.
17:57:50 <tsufiev> gokrokve_, you mean backporting changes from J1 to 0.5?
17:57:55 <ruhe> #info agreed to introduce changes in contracts (contract improvements)
17:58:10 <ruhe> #topic Make gate tests voting
17:58:59 <ruhe> so, we recently renamed stackforge/murano-api to stackforge/murano and renamed package muranoapi to murano
17:59:04 <ruhe> #link https://blueprints.launchpad.net/murano/+spec/rename-murano-api-to-murano
17:59:14 <ruhe> no, our dsvm job is green again
17:59:35 <ruhe> i'd like to give it one more week to prove it's stable and make it voting
17:59:51 <tsufiev> no objections from my side
17:59:54 <ruhe> it means that patches will not be able to be merged if this job fails
18:00:04 <katyafervent> +1
18:00:33 <ruhe> #info agreed to mark murano-dsvm job as voting one week later
18:00:38 <sc68cal> ruhe: heads up, have a meeting slated for 1800
18:01:02 <ruhe> that's all for today. thanks everyone
18:01:04 <ruhe> #endmeeting