15:01:59 #startmeeting Murano 15:02:00 Meeting started Mon Sep 9 15:01:59 2013 UTC and is due to finish in 60 minutes. The chair is dkoryavov. Information about MeetBot at http://wiki.debian.org/MeetBot. 15:02:01 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 15:02:04 The meeting name has been set to 'murano' 15:02:30 Here are our agenda https://wiki.openstack.org/wiki/Meetings#Murano_meeting 15:02:45 https://wiki.openstack.org/wiki/Meetings/MuranoAgenda * 15:02:54 Hi everyone! 15:03:02 Summary from the previous meeting http://eavesdrop.openstack.org/meetings/murano/2013/murano.2013-09-02-15.02.html 15:03:10 Hi! 15:03:28 hi 15:03:58 Unfortunately, as far as I can see, we have no Georgy here, so let's speak about Action Items from the previous meeting. 15:04:58 We have one action item > need to update https://blueprints.launchpad.net/murano/+spec/linux-agent 15:05:44 As far as I can see, blueprint is updated. 15:06:03 But I have several questions: > Linux agent should be agnostic to the Linux distribution, but it is ok if only some specific Linux is supported initially. 15:06:39 I can see some updates of this blueprint, but we also should add info about commands/scripts and etc. 15:07:22 It is really difficult to support, so I suggest to support Ubuntu LTS (12.04, 14.04) and CentOS/RHEL 6.4, 7.0. 15:07:48 (as minimum, on a first time) 15:08:14 What do you think, folks? 15:08:36 dkoryavov, realy, for the first version we can support only Ubuntu or other DEB-based linux 15:09:01 because we will should support two versions of scripts for Ubuntu and CentOS 15:09:20 about scripts and commands? do you mean that Linux agent must work through the sudo wrapper with the limited set of commands? 15:10:14 As far as I can recall sudo is not configured in CentOS by default. 15:10:30 IgorYozhikov, yes, 15:11:15 dkoryavov, we have root user in CentOS by default and can use it for the first version of implemenation. 15:11:25 So, to work with the help of sudo we should create a custom CentOS images. :) It is not very good idea I think. 15:11:26 tnurlygayanov_: why "two versions of scripts" ? I though that Python code is portable ... 15:11:56 Can we add support for SuSE (SLES) too? 15:12:18 why do we need custom images/installation with sudo? 15:12:19 dteselkin: As far as I can recall CentOS has Python 2.6 while Ubuntu has Python 2.7. 15:12:36 yes, Python code is portable, but bash scripts with packages-installation is not portable without specific scripts-actions. 15:12:43 joel_c: Well, yes. Which version? 12.2? 15:12:57 Do we have functionality which requires 2.7 only & 15:12:59 * ? 15:13:50 In dashboard no AFAIK 15:13:55 dteselkin I don't know. sergmelikyan ? 15:14:16 SLES10, SLES11 15:14:37 shell scripts are not to complex as python, so I think that agent may has ability to execute them 15:15:05 ok, lokks like we can support SLES10 and SLES11 for the first version of linux agent. 15:15:17 What about puppet and chef support? 15:15:31 Why you decided to use SUSE? 15:15:37 Why not RedHat? 15:16:26 SUSE is free. 15:17:57 AFAIK 15:17:59 as I remember, SUSE has newer version of packages 15:18:01 Ok. So Lets support Ubuntu, SUSE and CentOS 15:18:10 Does anybody know which version of Python in SLES10 and SLES11? 15:18:16 Ubuntu is widely used in OpenStack 15:18:18 AFAIK there are no code special for 2.7 15:19:11 If 2.6 or 2.7 and there are no problems with sudo, I think it will be easy to support SLES10 and 11. 15:20:16 Folks, my question about python 2.7 meant "do we plan any functionality in AGENT which requires python 2.7". As far as I know, we haven't implemented yet a line of code for Python Murano Agent :) 15:20:21 We need to check the difference between Linux distribution. We need to make sure that scripts will work perfectly on any Linux version. 15:21:16 Yes. Agent should be Python based. 2.7 version is not mandatory but it is usually available on any distribution. 15:22:32 gokrokve CentOS 6.4 has Python 2.6 in repositories…. 15:23:04 Ok. What we can do with that? Support 2.6? 15:24:02 gokrokve I think yes. 15:24:07 all murano components work with 2.6, as I know 15:24:25 Currently all openstack software is tested against 2.6 15:24:30 By the way, I want also discuss our approach on state management in workflows. Right now it is hard to understand what the state is and how it is related to the workflow rules. 15:24:39 IgorYozhikov, YEP 15:24:53 I suggest to support any distro who satisfies the following conditions: 15:24:53 * Python 2.6 and 2.7 on the board; 15:24:53 * 'sudo' installed and configured by default. 15:25:04 Can we have a separate design session on that? 15:25:20 IgorYozhikov do we really need 'sudo'? 15:25:23 I've heard that it's possible to bundle different verions of python with your package. In this case, your python is independent from the system. But it requires some investigation. 15:25:29 Currently conductor have in memory state during workflow execution\ 15:25:31 dkoryavov I agree. Look quite reasonable. 15:25:49 if Agent would use unprivileged user - yes 15:26:20 If any fail is occured during exeecution this task will be restarted from begining and all aready provisioned resources going to be droped 15:26:29 dteselkin, you are speaking about virtualenv 15:26:46 From the security viewpoint it should be non root user with some specific command allowed via sudo. 15:26:59 to prevent security issues 15:27:04 Right. 15:28:25 OK. #info Requirements for GNU/Linux agent: Python 2.6 or Python 2.7. An utility 'sudo' installed and configured by default. 15:29:37 gokrokve, any other question about state? 15:29:41 #info: blueprint for linux agent was updated: added new comments. 15:30:12 sergmelikyan: Just need a meeting date and time. 15:30:48 today after this meeting? 15:30:57 #info From the security viewpoint it should be non root user with some specific command allowed via sudo. 15:31:03 during this week. 15:31:10 ok 15:31:56 What is about second feature? 15:32:12 And by the way we are running out of time. 15:32:45 gokrokve no, we have 1 hour for meeting. :) 15:32:50 https://blueprints.launchpad.net/murano/+spec/custom-workflows 15:33:17 Good. 15:33:23 Lets continue then. 15:33:35 This is our second planned feature for v0.3. Do you have any questions about it? 15:34:02 how we can save and provide new workflows for users? 15:34:16 how users can share workflows? 15:34:38 *with this new feature, of course. 15:35:37 should we use git repository for the first version or we will use workflows-server? 15:36:47 as user I want to have ability to download new workflows and WebUI forms from WebUI ) 15:37:08 agree 15:37:09 do we plan to support it? 15:38:18 or we plan make just private-git repository and share workflows for administrators of OpenStack clusters? 15:39:31 tnurlygayanov_ I think we can use a git repository on a first time. To create custom workflow you need to be a high skilled user (like an admin), so it is not a big problem to use git for these users, I think. 15:39:35 Implementation is based on time-frames for release, we still not yet estimated this featureds 15:40:16 Am I right? :) 15:41:00 dkoryavov: I agree that to get it off the ground using Git is ok however we want to provide custom workflows to bussiness units who will not be OpenStack Admins 15:41:58 If this service would reside inside the cloud, I believe that it could use keystone as the security backend, but this is only my suggestion 15:43:10 What is about metadata service to keep all workflows in the one place and use keystone for ACL? 15:43:16 joel_c gokrokve Hmm. Can you create a document how you see this implementation? We can discuss it on a next meeting. 15:43:23 Please* 15:44:14 dkoryavov: Ok. 15:46:26 joel_c: You can submit your own blue print on the launchpad.net. 15:46:41 gokrokve: yes. 15:46:47 Or you can try to add whiteboard comments to the existing one. 15:47:07 gokrokve Alex and Stan are not here today, thus we had no discussion about this. 15:47:27 As I see we will need UI part for this feature too. 15:47:29 > Or you can try to add whiteboard comments to the existing one. 15:47:52 If would be very nice. 15:47:54 It means that we need to understand what will be the process of management for workflows. 15:48:09 gokrokve, yes, but the workflows should come first 15:48:55 Not necessarily. From the service viewpoint this is a standard CRUD REST API 15:48:59 i need some workflows api to base Ui on it 15:49:23 can we combine metadata and custom workflows "keeper" service in one? 15:49:29 Ok. I think Sergey can create some API for you. 15:49:41 It is exactly the plan. 15:50:42 gokrokve, yes, that would be nice 15:51:03 We need also to think how we will upload multi-component workflow. It consists of workflow itself, scripts, templates, UI definition. 15:51:28 may be like gz comntainer? 15:51:33 It looks like that folder based approach fits here. 15:51:43 may be like gz container? 15:51:49 Yes. Archived folder. 15:52:30 OK, folks, we have no time. Let's finish our meeting. I suggest to discuss custom workflows on the next meeting when we'll have some estimates for basic implementation of it. 15:54:19 Btw, I suggest to discuss custom workflows directly in Launchpad. 15:54:26 Here: https://blueprints.launchpad.net/murano/+spec/custom-workflows 15:54:45 dkoryavov: Ok. Sounds good. 15:56:17 The next meeting will be at Sep 16. 15:56:22 #endmeeting murano