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