17:00:36 <serg_melikyan> #startmeeting murano
17:00:37 <openstack> Meeting started Tue Nov 18 17:00:36 2014 UTC and is due to finish in 60 minutes.  The chair is serg_melikyan. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:38 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:40 <openstack> The meeting name has been set to 'murano'
17:00:48 <serg_melikyan> #topic agenda
17:00:59 <serg_melikyan> 1. Action Items Review
17:01:14 <serg_melikyan> 2. Review Roadmap for K
17:01:19 <katyafervent2> hi!
17:01:22 <ruhe> o/
17:01:24 <serg_melikyan> 3. Update blueprint for K1
17:01:34 <serg_melikyan> 4. Open Discussion
17:01:46 <serg_melikyan> #topic Action Items Review
17:01:48 <serg_melikyan> Hi guys!
17:02:21 <serg_melikyan> stan_lagun: you've joined us today?
17:02:28 <stan_lagun> hi!
17:02:42 <stan_lagun> serg_melikyan: sure :)
17:02:45 <janalex> Hi!
17:02:51 <serg_melikyan> janalex: hi!
17:02:51 <ogelbukh> o/
17:03:10 <serg_melikyan> Let's start with action items from previous meeting :)
17:03:22 <ruhe> yes!
17:03:34 <serg_melikyan> meeting minutes: http://eavesdrop.openstack.org/meetings/murano/2014/murano.2014-11-11-17.00.html
17:03:44 <serg_melikyan> 1. ruhe will create murano-specs
17:03:52 <ruhe> #link http://git.openstack.org/cgit/stackforge/murano-specs
17:04:02 <serg_melikyan> thank you!
17:04:16 <serg_melikyan> Now we able to start working on specifications for K :)
17:04:22 <ruhe> repo is already there. but it's empty atm. patch with initial project setup is on review:
17:04:23 <ruhe> #link https://review.openstack.org/#/c/134907/
17:04:48 <katyafervent2> and what about the template for specs?
17:04:50 <ruhe> i've asked stan_lagun to update spec template. i agree with his comment about general versioning impact
17:05:05 <serg_melikyan> 2. Stan Lagun will take a look at what exactly need to be fixed to resolve " Re-surrect support for configuration changes in deployed environment"
17:05:13 <serg_melikyan> stan_lagun: had a chance to take a look?
17:05:23 <stan_lagun> ruhe: I'm going to update it immediately after this meeting
17:05:27 <ruhe> katyafervent2: tempalte is here on review https://review.openstack.org/#/c/134907/
17:05:44 <stan_lagun> serg_melikyan: yes
17:06:01 <katyafervent2> ok
17:06:12 <stan_lagun> Just finished investigation. There are 2 bugs in dashboard that prevent redeployment of failed environments
17:06:29 <serg_melikyan> links?
17:06:37 <stan_lagun> Environments that were deployed successfully can be redeployed
17:06:57 <stan_lagun> no tickets yet. Just finished researching
17:07:24 <serg_melikyan> Ok, I assume that you will create appropriate tickets for them?
17:07:57 <serg_melikyan> #info we have two bugs that prevent proper re-deployment of environments
17:07:58 <stan_lagun> yes. Maybe they already exist. Probably need to talk to Kate
17:08:23 <serg_melikyan> #action stan_lagun will insure that tickets about issues with re-deployment will be created
17:08:27 <katyafervent2> stan_lagun, ping me anytime
17:08:52 <serg_melikyan> 3. stan_lagun, will think about implementation of one-time properties
17:08:59 <stan_lagun> katyafervent2: thanks!
17:09:22 <serg_melikyan> I think that we need to create a document with all improvements in our DSL that we need to do in K
17:09:53 <ruhe> serg_melikyan: create a spec in murano-specs maybe?
17:09:55 <serg_melikyan> and file appropriate blueprints for each of them
17:10:07 <stan_lagun> I have some ideas on how this should be supported on engine's side but I don't see how this can be implemented with current API
17:10:21 <serg_melikyan> ruhe: I think one spec will be not enough
17:10:37 <stan_lagun> because with current API dashboard has no access to class metadata
17:12:00 <serg_melikyan> Ok, but we plan fix API
17:12:20 <serg_melikyan> stan_lagun: what do you think about document with list of all changes in dsl?
17:12:49 <stan_lagun> I think we need to have BPs+specs for each change
17:12:49 <serg_melikyan> can you start working on that document? I believe you already have few thoughts about that
17:12:54 <serg_melikyan> stan_lagun: =1
17:12:57 <serg_melikyan> +1
17:13:17 <stan_lagun> I'm going to submit many of them during thins week
17:13:25 <stan_lagun> *this week
17:14:02 <stan_lagun> but the problem with one-time properties is not one of them
17:14:10 <serg_melikyan> stan_lagun: let's anyway create some etherpad with list
17:14:11 <stan_lagun> because we need to design new API first
17:14:35 <stan_lagun> sure. I'll summarize them in one place for next meeting
17:14:51 <serg_melikyan> stan_lagun: why? we can start with specification, and describe what needs to be changes in API
17:15:20 <stan_lagun> specification is a designed solution. I don't have one at the moment
17:15:43 <serg_melikyan> I think there is no reason why we can't create spec for one-time properties before changing API
17:15:44 <katyafervent2> we can discuss document creation on irc
17:15:57 <serg_melikyan> and changes in API maybe part of the spec
17:16:00 <stan_lagun> Also I'm not sure about exact requirements for new API though I have some requests
17:16:04 <katyafervent2> * in
17:16:40 <serg_melikyan> specification is completely designed solution only when it's merged + implemented
17:16:57 <serg_melikyan> we anyway can at least describe what is this about
17:17:16 <stan_lagun> I have no solution for one-time properties with current API. And there is no point to design small feature that is dependent on whole new API that is not even discussed yet
17:17:29 <serg_melikyan> #action stan_lagun, will create etherpad with list of changes planned in DSL for K
17:17:42 <stan_lagun> The problem is that i have no solution until we have new API
17:17:54 <serg_melikyan> Ok
17:18:03 <serg_melikyan> Let's move on :)
17:19:15 <serg_melikyan> 4. stan_lagun will move his document about versioning to the spec once repo is created
17:19:35 <serg_melikyan> I think we can skip this one - as stan_lagun mentioned before it is not done yet
17:19:44 <stan_lagun> not done because we haven't merged initial commit for murano-spec
17:19:57 <serg_melikyan> #action stan_lagun will move his document about versioning to the spec repo
17:20:29 <serg_melikyan> 5. Serg to send invite to weekly meeting to the Radek and other guys
17:20:43 <serg_melikyan> I've invited guys from HP and Telefonica to our weekly meetinh
17:20:50 <serg_melikyan> *meeting
17:21:00 <_avig_> we are here :-)
17:21:03 <Radek_> hi
17:21:09 <Pablo_> Hi, this is Pablo from Telefonica
17:21:22 <Pablo_> My colleague Henar couldn't join
17:21:28 <serg_melikyan> Hi guys :) Nice to see you here :)
17:21:31 <Pablo_> but next time she will!!
17:21:52 <serg_melikyan> _avig_: sorry about last meeting, I forgot that we had DST changes
17:22:15 <serg_melikyan> Pablo_: ok :)
17:22:47 <serg_melikyan> Let's than move to the next item
17:23:23 <serg_melikyan> #topic Review Roadmap for K
17:23:57 <serg_melikyan> I've composed Roadmap for K cycle - https://wiki.openstack.org/wiki/Murano/Roadmap
17:24:11 <serg_melikyan> We can add new items there, though
17:24:55 <serg_melikyan> I mean add new items later, when we will have better understanding, or time to implement something that we didn't schedule from the begining
17:25:11 <serg_melikyan> Any Blueprints that I've missed to add?
17:25:51 <janalex> Policy driven fulfillment
17:26:01 <_avig__> where is the policy-guided fulfillment item?
17:26:07 <janalex> HP is working on the spec proposal for that
17:26:17 <_avig__> i'm from HP :-)
17:26:21 <janalex> Should we add it to the list now or after we have a blueprint link?
17:26:25 <serg_melikyan> janalex: it not there only because we don't have BP for that right now
17:26:36 <serg_melikyan> We will add that once we will create BP :)
17:26:53 <_avig__> i see, i guess we'll discuss it in tomorrow's meeting, right Serg?
17:27:00 <serg_melikyan> I could'nt figure out how to describe that in BP.
17:27:05 <serg_melikyan> _avig__: right
17:27:11 <stan_lagun> I guess it should me several BPs/specs
17:27:12 <_avig__> great
17:27:12 <janalex> ok, let's do an action item to add BP and an item to the roadmap
17:27:17 <serg_melikyan> and right after that I will update roadmap
17:27:28 <ruhe> jfyi: this wiki page is not something final. it is updated during the development cycle
17:27:28 <janalex> sounds good
17:27:54 <ruhe> it just let's people outside of the project to understand what's going on
17:27:59 <serg_melikyan> #action Serg, discuss policy guided fulfillment and create all necessary BP
17:28:00 <ruhe> *lets
17:30:15 <serg_melikyan> Ok, anything else missing in Roadmap?
17:30:48 <stan_lagun> a lot of MuranoPL/engine thing but we will fix it soon :)
17:30:55 <_avig__> i see there's an item on the list w/o a blueprint. what does it mean?
17:31:19 <ruhe> serg_melikyan: i'd suggest to add a link to official OpenStack Kilo release schedule
17:31:22 <stan_lagun> this is just a bug
17:31:33 <serg_melikyan> ruhe: thank you, will do
17:32:01 <ruhe> _avig__: it's a bug. stan_lagun, serg_melikyan can we add a link to that bug?
17:32:09 <serg_melikyan> _avig__: there was action item about that item, but Stan didn't yet created necessary tickets/bp
17:32:11 <stan_lagun> I think we shouldn't mention bugs in roadmap
17:32:19 <ruhe> we're speaking about "Resurrect support for configuration changes in deployed environment"
17:32:39 <serg_melikyan> stan_lagun: we didn't know is it only a bug )
17:33:04 <serg_melikyan> You was investigating that - Action Item #3 for today )
17:33:15 <stan_lagun> now we know
17:33:33 <serg_melikyan> _avig__: if it's only a bug we will remove that - features == blueprints
17:34:49 <serg_melikyan> added policy guided fulfillment there too,
17:35:07 <serg_melikyan> #action Serg, fill all missing BP in Roadmap
17:35:38 <serg_melikyan> #topic Update blueprint for K1
17:36:16 <serg_melikyan> I've assigned part of the blueprints for K1, mostly ones that are already near completion: https://launchpad.net/murano/+milestone/kilo-1
17:36:50 <serg_melikyan> Deadline for K1 is December 18, exactly one month from now
17:36:51 <ruhe> serg_melikyan: i have a question. should we expect all the blueprints scheduled for Kilo-1 (https://launchpad.net/murano/+milestone/kilo-1) to have a spec?
17:37:52 <stan_lagun> ruhe: I suggest to have specs only for big BPs + write them on request. But not to have this as a mandatory rule
17:38:13 <serg_melikyan> ruhe: I hope so, but I think since we only started with spec-repo part of specs may be in progress
17:38:21 <serg_melikyan> stan_lagun: disagree
17:38:49 <stan_lagun> It is difficult to write spec for each and every tiny feature
17:39:05 <serg_melikyan> stan_lagun: tiny feature - tiny spec
17:39:21 <stan_lagun> I don't want to have such high bar for newbies
17:39:48 <serg_melikyan> stan_lagun: that's why I say that we may not have all BP merged at the end of K1
17:39:59 <serg_melikyan> we will help with spec creation
17:41:29 <stan_lagun> seems like too much bureaucracy for me. I like the idea of specs but don't like being to formal with that
17:42:36 <serg_melikyan> I think we have pretty tentative development schedule for https://launchpad.net/murano/+milestone/kilo-1 already and we don't want any other BPs
17:42:43 <stan_lagun> if you get 100 formally written specs for each little improvement in UI it would be hard to find important ones
17:43:09 <serg_melikyan> It gives us much more time to design features like policy guided fullfillment and support for puppet and chef
17:43:13 <serg_melikyan> Or new API
17:43:24 <ruhe> i suggest to move discussion about scope of specs outside this meeting
17:43:56 <serg_melikyan> ruhe: +1
17:44:19 <ruhe> but sure, we as a team need to agree on this item
17:46:26 <serg_melikyan> Guys, you agree that we don't need to include other blueprints to K1
17:46:58 <stan_lagun> does this implies that all MuranoPL BPs will go to K2?
17:47:28 <ruhe> i'd say that some UI-related work could be done in kilo-1 if there is anyone willing to do that work :)
17:48:35 <serg_melikyan> stan_lagun: it depends - I would prefer to spend time on designing heavy features during k1
17:49:06 <serg_melikyan> ruhe: yes ) Unfortunatelly Brian not with us today, I will ping him on this week about UI part
17:49:19 <stan_lagun> agree. But lets not move all of them to the end of the cycle
17:49:20 <ruhe> also we need to reserve some time for code-freeze and testing of milestone release
17:50:21 <stan_lagun> serg_melikyan: I haven't seen TOSCA in K roadmap but it is in K1
17:50:35 <serg_melikyan> stan_lagun: it is in Roadmap
17:50:39 <ruhe> stan_lagun: look closer ;)
17:50:51 <stan_lagun> sorry. Missed it
17:51:17 <serg_melikyan> But as we discussed we are talking about most basic integration that relies on Heat + heat-translator
17:52:39 <stan_lagun> propper implementation of pluggable translators need some packages API refactoring. I'm not sure how big it is going to be
17:52:56 <stan_lagun> just be aware
17:53:15 <serg_melikyan> ruhe: agree about code-freeze, let's do as always - one week for CF
17:53:46 <serg_melikyan> I think we already moved to the latest part of our meeting
17:53:52 <serg_melikyan> #topic Open Discussion
17:54:18 <serg_melikyan> stan_lagun: you have in mind some nice wrapping around that?
17:54:52 <stan_lagun> serg_melikyan: around what?
17:55:04 <stan_lagun> plugins?
17:55:28 <ruhe> just an update about failing CI jobs. fix for failing gate-murano-devstack-dsvm jobs should be resolved with https://review.openstack.org/#/c/134901/ . it should be merged in a few minutes
17:56:12 <ruhe> murano-ci jobs "gate-murano-integration" are in a good shape at this moment. leave a comment in gerrit "retrigger murano-ci" if you have failing murano-ci tests
17:57:51 <stan_lagun> There was problem with HOT support: MuranoPL class was generated on the fly but UI form was generated at package upload and I couldn't find an easy way to do otherwise
17:59:15 <serg_melikyan> ruhe: thanks
18:00:07 <serg_melikyan> stan_lagun: ok, let's discuss that later, I don't think we need full fledged plugins but something we definitely need
18:00:11 <serg_melikyan> #endmeeting