15:00:43 #startmeeting Murano 15:00:43 Meeting started Mon Oct 21 15:00:43 2013 UTC and is due to finish in 60 minutes. The chair is ativelkov. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:00:44 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:00:45 Hi Alex 15:00:46 The meeting name has been set to 'murano' 15:00:48 Hi guys! 15:00:53 Hello 15:00:56 Hi! 15:01:03 hi there 15:01:18 Cool, lot's of people ) 15:01:21 hi all! 15:01:39 We have an agenda here: https://wiki.openstack.org/wiki/Meetings/MuranoAgenda#Agenda 15:02:00 o/ 15:02:14 So, let's start with the review of the previous week's AIs 15:02:21 #topic AI review 15:02:43 Here we have this list: http://eavesdrop.openstack.org/meetings/murano/2013/murano.2013-10-14-15.01.html 15:03:49 So, about backporting of our Heat patches: according to Heat team, these were not bugs, but rather features, so backporting of them to grizzly branch is forbidden 15:04:15 so, we will not be able to commit our backports to official grizzly branch 15:05:07 That is why we will have to distribute release 0.3 either without quantum support at all, or include patches to Heat with our distribution 15:06:09 Does this fix present in havana? Do we fully support it? 15:06:12 Of course, we may use custom for of Heat repository for this as well, but this is not a good practice and should be avoided for public releases 15:06:31 katyafervent, Most of them are present, yes 15:06:41 eltn 15:06:50 oh 15:07:12 however, there was one fix (made by sergmelikyan) which did not get accepted before the check-in gate was closed, so it will get only to icehouse branch 15:08:14 Can we offer quantum as optional for release 0.3? 15:08:23 gokrokve, yes, I think so 15:08:33 I mean on the code level are there any hard dependencies for Quantum? 15:08:50 Not on the code level 15:09:08 And the question is not quantum itself 15:09:20 question is limited support for quantum in Heat 15:10:04 so, we will not support nova network in release-0.3.... 15:10:11 for example, grizzly Quantum support security groups on the port level, but grizzly Heat does not fully support this feature 15:10:32 tnurlygayanov, I would suggest to support it "out-of-the-box" 15:11:23 I mean, the default templates which we distribute with Murano should be targeting Nova Network 15:11:32 ativelkov: but we should have prepared patch for this 15:11:40 but we should include an archive with the quantum-ready templates 15:11:51 yes 15:12:28 and include a manual how to a) substitute the NN templates with the Quantum ones b) patch Heat 15:12:53 by the way, NN templates will work with Quantum as well, but the set of functionality will be different 15:13:21 it is should be 'one magic command', not complex document ) 15:13:43 Still it should be documented in installation guide. 15:13:54 #info The default templates which we distribute with Murano should be targeting Nova Network, but we will include an archive with the quantum-ready templates and ways to migrate and patch the Heat 15:14:19 gokrokve, yes, we should provide a detailed explanation 15:14:44 patching an infrustructure-level component should not be done blindly 15:15:07 but an easy-to-use authomation script is also a good idea 15:15:20 btw I created task in jira that we need to update our documentation before release 15:15:34 Thanks, akuznetsova 15:16:20 Two other action items are related to r0.3 task synchronization. sergmelikyan, can you provide an update on the release status and what is going to be included there? 15:17:29 We had synchronized all tasks for 0.3 15:18:38 what about Murano Panel? Have you decided if it should be part of 0.3 or not? 15:19:21 We have several major features: Support for Managing Linux Instances, Usage of Quantum and ability to mark images in glance via UI 15:19:47 Panel (actually Dashboard in terms of Horizon) not going to be introduced in 0.3 15:20:12 ativelkov: it is simple to implement on its own, but can potentially break many things in 0.3 15:20:19 so, we'll have the same UI layout for 0.3? 15:20:32 ativelkov: yes 15:21:06 #info new leyout of Murano Dashboard will not be included with the release 0.3 and is postponed till 0.4 15:21:46 OK, next AI (we have quite a lot of them btw) 15:22:01 tnurlygayanov, what about the test plan for release-0.3? 15:23:06 ativelkov: we are working on it... 15:23:36 any estimations? 15:23:49 and also on automated testing for all services and new workflows with automated testing inside the workflows. 15:24:17 yes, I plan to finish for 2 days. 15:24:34 and it will not only for release-0.3 test plan, also for 0.4 too. 15:24:43 #info Release 0.3 test plan is in progress, as well as updated automation testing scenarios. The ETA is 2 days 15:24:48 good, thanks 15:25:54 Last AI is on me 15:26:20 I asked Boris to do some follow up on Mistral announcement 15:26:46 It turns out that he didn't get enough time for this, as he is quite busy with his own releases 15:27:00 But we still get some community responses to the announcement 15:27:38 can we ask him provide some feedback on the tech docs we have? 15:28:05 I asked, but he said that he is too busy now, probably later 15:28:07 his opinion should be valuable due to his specific experience 15:28:33 As far as I understood he is interested in Taskflow library, so he should probably have some attention to Mistral as well 15:28:33 yes, I know but I meant ask him to do that before the next meeting or so 15:28:44 I'll try 15:28:50 ok, thanks 15:29:10 So, seems like we are done with AIs 15:29:30 Did we test Linux Agent? 15:29:40 Is it ready for delivery? 15:29:41 Yes 15:29:56 But with quite a simple scenario by now 15:30:06 Do we have example workflow for it? 15:30:12 we simply deploy telnet 15:30:23 #topic Release-0.3 15:31:03 #info LinuxAgent is ready to be delivered in Release-0.3, with simplest possible deployment workflow 15:31:46 sergmelikyan, do we have anything important to discuss about 0.3? 15:32:03 what are the open issues there, etc? 15:33:06 sorry, a quick note/question: as for LinuxAgent, should we start calling it PythonAgent meaning it can be used not on Linux only? 15:33:19 Yes. 15:33:20 or it's already been discussed and approved? 15:33:47 well, we were calling it Unified (vNext) Agent 15:33:52 LinuxAgent is not an official name. We use it just to highlight that it works on Linux. 15:34:11 remove vNext. Nobody understands that. 15:34:17 right, however it may get people confused 15:34:29 who is right here, ha :) 15:35:14 Unified Agent seems to be ok 15:35:21 ativelkov, right now we don't have any outstanding issues 15:35:25 sorry for interrupting, back to open issues 15:36:13 sergmelikyan, what are our estimation on release date? 15:36:14 So we just selected official name - Unified Agent? 15:36:41 I would suggest so 15:36:58 I guess official name for Murano Agent is Murano Agent :) 15:37:13 katyafervent, the idea is that we have a unified agent specification (the one which is available at https://wiki.openstack.org/wiki/Murano/UnifiedAgent) 15:38:09 the name of the exact implementation does not matter much, as we expect that other implementations may appear 15:38:13 ativelkov, end of October, first days of November 15:38:22 sergmelikyan, thanks 15:38:59 #info Release0.3 is on its way, no outstanding issues, release planned to end of October-beginning of November 15:39:35 Ok 15:39:47 #topic Networking Changes for 0.4 15:40:02 So, we have an important question to discuss 15:40:25 It turns oput that we will to introduce a new major feature in Release 0.4 15:40:31 turns out* 15:41:13 In quantum-enabled version of 0.3 we have isolated each environment into is own L2-segment 15:42:02 I.e. each env creates its own network with its own subnet, then creates a router and then plugs this router to some external network 15:42:25 Did you test that with Quantum VM still able to communicate with RabbitMQ? 15:42:51 Yes, sure 15:43:00 the deployments are successfull 15:43:25 The problem is with the IP range of the external network 15:43:37 Our approach means one router per environment 15:43:59 and each router in external network obviously consumes 1 IP address from its range 15:44:13 And these IP{ addresses are quite a valuable resource 15:44:32 The proper way of doing these should be different 15:44:41 we should have a single Router per tenant 15:45:08 and plug all the Networks of this tenant into this router 15:45:43 But to do this we will have to define non-overlapping subnets 15:46:03 probably we can configure some 'murano' router and assign all networks to this router 15:46:24 tnurlygayanov, the proper solution should be more complex 15:46:31 and user will select new network range for new environment 15:46:49 ok) need to describe arch in images 15:47:00 it will more clear for everyone 15:47:41 Yes. I am writing a new document on this topic right now 15:47:59 ok. We need to document this. It is not self obvious about Quantum networking topologies. 15:48:08 #action ativelkov to complete the "Per Environment Network Management" document 15:48:14 so we should have something like subnet booking mechanism? 15:48:23 rakhmerov, yes 15:48:29 gotcha 15:48:45 Also, we should allow the user to select an existing network for the new environment 15:49:01 (we had similar blueprint for security groups) 15:49:13 but this should be an advanced option 15:49:14 probably we could provide two options and let the users make a choice 15:49:21 yup 15:49:28 one the options is by default 15:49:35 but the default should be simple and secure 15:49:41 right 15:50:17 e.g. by default, a new network is created per environment, as subnet is allocated accordign to the existing subnets, and the network is plugged to some default router 15:50:54 and in advanced scenarios user will be able to override any of these defaults (i.e. choose existing network, or modify the ip range, or choose the router, etc) 15:51:15 As I said, I will complete the spec and will submit the blueprint 15:51:42 ok 15:51:44 Seems like we are done with this topic, let's move on 15:51:49 #topic Open Discussion 15:51:54 :) 15:52:07 the most pleasant one :) 15:52:31 yeah. So, any questions, guys? 15:53:34 Nope, thanks for making all questions clear 15:54:09 Alright, so we are probably done 15:54:27 Just do not forget that we have a Mistral meeting in 6 minutes 15:54:36 yes, sure 15:54:44 It's in different channel, #openstack-meeting 15:54:45 ok ) got to the next meeting ) 15:54:46 And in another channel ;) 15:55:08 so, thanks for joining and see you soon 15:55:12 #endmeeting