17:00:26 #startmeeting murano 17:00:26 Meeting started Tue Nov 11 17:00:26 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:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:30 The meeting name has been set to 'murano' 17:00:59 Hi guys! 17:01:08 o/ 17:01:26 I've missed our meetings :) But now summit is finished and we back on schedule 17:01:33 o/ 17:01:45 Agenda: 17:01:52 1) Action Items Review 17:02:00 2) Discuss plans for K 17:02:04 3) Open Discussion 17:02:25 Hi! 17:02:26 I think we can skip first item of agenda 17:02:35 All agree? 17:02:48 agree 17:02:57 Hi 17:02:57 Yes, there were no AI for a long time 17:03:00 We had no Action Items from previous meeting and last few meetings were canceled 17:03:09 Ok 17:03:49 #topic Discuss plans for K 17:03:57 On Summit we met many people and discussed many things. Most of the vision for K cycle is captured in our etherpad 17:04:05 https://etherpad.openstack.org/p/kilo-murano-design-session 17:04:24 I think we should start with creating new repository for specs, like murano-specs 17:05:20 i volunteer for doing this 17:05:32 ruhe: thanks 17:05:41 #action ruhe will create murano-specs 17:06:33 We have too many things to implement during this cycle, so best way to track to have specs for each big feature 17:08:06 After we will create specs repo, and all blueprints will be added to Launchpad, I hope till the next meeting all will be done, we will go through them on the next meeting and assign them to milestone 17:08:24 i agree. but we need to keep a balance. some of simple feature can be tracked as usual with LP blueprints 17:08:34 the only problem with specs that I know is dependency tracking. Sometimes they depend on more than one spec 17:09:07 ruhe: I would like to limit impact of adding specs repo to our community and suggest to write specs alongside with implemention, but have draft and BP before implementation - wjat do you think? 17:09:15 Launchpad can draw dependency graph for BPs 17:09:27 Each spec should have corresponding BP 17:09:44 StanLagun: they don't replace each other 17:09:47 yeah, dependencies still can be tracked in LP 17:10:33 ruhe: ^^^ 17:10:39 Does any other project have special repo for specs? 17:10:49 katyafervent: almost all of them 17:11:09 ok 17:11:17 ruhe: I mean what do you think about having only draft of spec as requirement to BP approval? 17:11:57 serg_melikyan: i would say - it all depends and is specific for each blueprint 17:12:17 Ok 17:12:27 for some BP we can do so, for others it would be beneficial to wait for spec to be approved before approving the BP 17:13:00 Agree depends on 17:13:01 as usual, we need to learn from core projects' expirience 17:14:31 So let's move to the main topic, as many of our contributors missed the summit, I suggest to go through our etherpad and answer questions, and if needed schedule discussions 17:16:07 https://etherpad.openstack.org/p/kilo-murano-design-session 17:16:31 1) Fix mechanism of interaction with Heat 17:16:41 Questions? 17:17:57 Will we publish this roadmap on our wiki? 17:18:32 katyafervent: for sure, once we will create all BP 17:19:14 2) Re-surrect support for configuration changes in deployed environment 17:21:20 ^^ what exactly is needed to be implemented here? 17:22:35 StanLagun: I think we need to rewrite our applications to support redeployment (many apps are written in a wrong way) and few fixes in UI to support redeploy 17:23:36 my point is that it is somethong that should be done on application side and our app repository is empty 17:24:02 We are working on this, I believe 17:24:16 At least ddovbii is working on new set of apps 17:24:20 so this can be written as fill app repository with properly written apps 17:24:26 We can make them proper and publish in community 17:24:43 * ruhe will be afk for 5 minutes 17:25:36 StanLagun: can you take a look at what we exactly should change in UI part? 17:27:00 StanLagun: зштп 17:27:03 ping 17:27:07 StanLagun: ^ 17:27:15 serg_melikyan: I think that nothing should be changed (considering we have no bugs there). But I also think that we should think on how to mark properties that can be set only once and need to be disabled in UI for subsequent modifications 17:27:59 StanLagun: so will you check that we have no bugs related to that? 17:28:09 okay 17:28:21 And failed environment endeed may be redeployed? And we can easily add applications to env 17:28:36 thanks! 17:29:12 I think there are some problems with failed environments 17:29:18 #action will take a look at what exactly need to be fixed to resolve " Re-surrect support for configuration changes in deployed environment" 17:29:30 #action StanLagun will take a look at what exactly need to be fixed to resolve " Re-surrect support for configuration changes in deployed environment" 17:29:50 serg_melikyan: don't forget about one-time properties 17:29:57 Sure 17:29:58 this is really important 17:30:13 #action StanLagun, will think about implementation of one-time properties 17:30:28 3) Migrate to newer version of yaql 17:30:58 I think ruhe already prepared patch for migration to the stackforge (as groundwork for working on the next version) 17:32:59 4) Add timeouts for murano-agent calls 17:33:20 StanLagun: do you have rough estimates about this? 17:33:38 Will we plan to fix yaql compatibility with Python 3? 17:33:54 katyafervent: for sure :) Almost done actually by ruhe 17:34:20 I think yaql is breaking our Py33 jobs for now? 17:34:46 in pythonclient it did even before 17:35:57 mm? 17:36:34 StanLagun: what about rough estimates for #4? 17:37:16 1 day for simple naive implementation, 4 days for heartbeats 17:37:26 Thx :) 17:38:03 #info Implementation of timeouts/heartbeats for agent calls may take up to week 17:38:19 5) Per-class configuration options 17:38:48 StanLagun: I also believe that you already working on this? 17:39:10 serg_melikyan: on timeouts? not yet 17:39:34 StanLagun: on per-class config options 17:39:44 yes 17:40:21 cC 17:40:28 Cool ) 17:40:47 6) Package versioning 17:41:09 This one is big topic - I suggest to start with reading to https://etherpad.openstack.org/p/d2wJEQjOhN 17:42:31 this needs to be designed very carefully. I already found one issue that is not covered by this spec. And there can be more if we go for implementing aspects or anything similar 17:43:03 and this should be aligned with artifacts versioning too 17:43:23 We definitely need spec for this one 17:43:29 Very detailed one 17:43:39 Show UI version be eqal to package version? 17:43:46 * equal 17:43:51 StanLagun: can you move your document to the spec once we create repo? 17:43:56 sure 17:44:08 katyafervent: not necessary 17:44:29 #action StanLagun will move his document about versioning to the spec once repo is created 17:45:10 serg_melikyan: what is the format for specs? Plain text? RST? something else? 17:45:20 StanLagun: RST 17:45:36 7) Support for HOT, TOSCA Simple Profile 17:46:38 8) Integration with CloudFoundry through service broker API 17:48:21 9) [UI] Optional environments 17:51:02 10) [UI] Proper image filtering 17:52:50 11 - 12) Multi-region support & Nova Network Support - both of them on review 17:53:55 13) Adding Policies to Guide provisioning of Murano Environment and Management of instances 17:54:26 And this one is also interesting - we discussed this thing with HP guys, hope we will have another discussion on this week 17:54:58 serg_melikyan: i guess we need to send them an invite for our weekly irc meetings 17:55:22 Will do 17:55:39 #action send invite to weekly meeting to the Radek and other guys 17:56:14 #topic Open Discussion 17:57:36 JFYI i've submitted a patch to infra to move yaql to stackforge: https://review.openstack.org/#/c/133545/ 17:57:51 waiting for Alex to get back from Paris to cleanup branches and tags 17:58:03 ruhe: thank you! 17:59:40 Hi. I suspect that most of thae guys will appear now. As my calendar shows that 10 is a starting time :-) 18:00:08 wrong timezone? 18:00:14 We need also to draft spect for Mistral integration 18:00:23 serg_melikyan: I think so. 18:00:37 It is part of #13 I believe 18:00:47 #endmeeting