17:01:14 #startmeeting murano 17:01:15 Meeting started Tue Mar 4 17:01:14 2014 UTC and is due to finish in 60 minutes. The chair is ativelkov. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:01:16 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:01:19 The meeting name has been set to 'murano' 17:01:25 Hi folks 17:01:35 Hi! 17:01:38 A quick check who is present, please? 17:01:43 hello! 17:02:19 o/ 17:03:08 Ok, let's begin 17:03:13 Hi 17:03:17 #link https://wiki.openstack.org/wiki/Meetings/MuranoAgenda#Agenda 17:03:25 #topic AI review 17:03:33 We have just a few of AIs for today 17:03:45 ativelkov to create the remaining blueprints targeting 0.5 17:03:58 The bluepwints and roadmap were created 17:04:07 thanks to sergmelikyan for assistance with this 17:04:26 #link http://wiki.openstack.org/wiki/Murano/Roadmap#Version_0.5_.28end_of_March.2C_2014.29 - this is the updated roadmap 17:04:45 It turns our we are going to have the biggest release ever 17:05:16 The next ai was low priority: tsufiev to look at Marconi (low priority task) 17:05:32 haven't started yet 17:05:36 I see 17:05:42 Hi 17:05:43 could you please create a BP for this? 17:05:49 Hi guys 17:05:51 hi 17:05:57 ativelkov: do you mind if i link my bp repository-reorganization on this wiki page? 17:05:58 ativelkov: yes, will do 17:06:08 ruke - sure, please do 17:06:29 #action ruhe to add repository-reorganization BP to roadmap 17:06:40 #action tsufiev to create a BP on Marconi usage 17:07:16 next ai 17:07:18 ativelkov to update the incubation statuspad 17:07:32 It is updated 17:07:33 #link http://etherpad.openstack.org/p/murano-incubation-status 17:08:05 The etherpad link is added to our Incubation page on wiki 17:08:17 #link http://wiki.openstack.org/wiki/Murano/Incubation 17:08:30 We are done with AIs, I guess 17:09:03 Next topic :) 17:09:07 #topic Roadmap review for Murano 0.5 17:09:19 So, the roadmap is updated 17:09:46 I've structured it in several dimensions 17:09:47 Now it's more clear) 17:10:21 First part is feature-based, second is split by modules, third one is infrustructure-related. 17:10:51 The latter is mostly needed to simplify our incubation 17:11:26 It's quite long, so I don't want to repeat it here: I'd rather answer the questions if somebody have them 17:11:57 ativelkov: should we create BPs for the last 3 infra items? maybe they exist already? 17:12:26 ruhe: yes, I am sure we need them 17:12:54 ativelkov: then you can add one more AI for me :) 17:13:18 does anybody know if launchpad allows to differentiate "tasks", "use-cases" and "feature improvements"? 17:13:44 #action ruhe to create BPs for infrustructure-related items in roadmap 17:14:13 Any other questions on the roadmap? 17:14:49 Ok, then let's proceed 17:15:03 #topic MuranoRepository v2 API 17:15:40 I'd pass the word to katyafervent who designed this API 17:16:22 katyafervent, could you give an update? 17:16:29 Well, we have designed it collaboratively I just documented it 17:17:13 Here http://docs.muranorepositoryapi.apiary.io/ it could be found 17:17:49 so we need to approve it together with the community and it will be ready for an implementation 17:18:00 #link http://docs.muranorepositoryapi.apiary.io/ - docs for the muranorepository 17:18:06 katyafervent: where should i post my comments - mailing list? 17:18:07 Also we decided do not to switch for Pecan for now 17:18:29 katyafervent: is it possible to use apiary for discussion? 17:18:39 katyafervent: which engine should we use? 17:18:52 ruhe, you can post comment directly on that page, etherpad or mailing list 17:19:08 https://etherpad.openstack.org/p/muranorepository-api 17:19:18 here is the etherpad for a discussion 17:19:26 I would prefer to use community-approved ways of discussing 17:19:47 so, etherpad should be fine 17:19:50 that is etherpad, right? 17:19:53 Ok) 17:19:54 Yes 17:20:01 We will stay with Flask 17:20:12 Right? 17:20:27 I've already added some notes to the etherpad 17:20:30 ativelkov: ok, just curious ) 17:20:52 #info Flask to be used to implement v2 api of murano metadata repository 17:21:18 That's it for v2 API 17:21:26 * ozstacker is away: I'm out smoking crack with triplecheesesina. how we roll. 17:21:34 leave your comments on the etherpad page 17:21:40 * ozstacker is back (gone 00:00:07) 17:21:51 Any questions on the current api draft? 17:22:49 So, then I'd suggest to postpone this discussion to the next meeting - I hope more people will read the drafts and have more questions 17:23:02 ativelkov, good idea 17:23:52 next topic 17:23:58 #topic Commands/Events discussion 17:24:12 gokrokve: please, drive this 17:24:25 Sure. 17:24:58 Murano needs to provide a way for extarnal tools to call specific action of the application. 17:25:11 The simplest example is backup action. 17:25:21 Called by Mistral service, for example. 17:26:05 There is a BP to add an ability to register event hooks capability in Murano DSL for application definitions. 17:26:19 Why do we need some additional hooks? 17:26:28 Each application\class can register a set of actions which will be available to call from the outside 17:27:04 From the DSLs point of view any public method of the application can be called from outside. Why do you need to "register" something? 17:27:07 I am not saying that they are additional. A callable hook is a term to describe something which is exposed to outside 17:27:44 Because you need to support this on API level 17:28:12 but support on API level also does not need any registration 17:28:45 for now we have an API endpoint like /v1/environments/%env_id%/deploy 17:28:57 for users the term event hook is understandable. The term public action is not self obvious for user and can be a source of wrong exposing by application developer who considers public method from OOP world 17:29:01 this eventually calls a "deploy" action for the given env 17:29:11 We can call this actions/commands/events by uri like ativelkov shown above 17:29:52 There is one point here though 17:30:14 These APIs - as external connection points - are actually part of CLOUD interface 17:30:22 not the application's 17:30:53 How user will get a list of actions available. How cloud admin ot user can prevent call to this action 17:30:57 So, I would say that the cloud administrator should be responsible for allowing or forbidding to call these APIs 17:31:24 I think about the following two use-cases 17:31:28 1) Admin's case 17:31:37 Sure. That is why I suppose to add a well defined entity with controllable access. 17:31:47 For a given application-package administrato may inspect the list of public actions 17:32:12 for each of these actions administrator may enable or disable external communication 17:32:22 and even probably specify the URL 17:32:45 or define a notification topic if we use notification-based APIs instead of REST 17:32:54 Then, a second case 17:32:56 2) user's 17:33:09 gokrokve, i think first level of control should be available to application publisher. I am not sure that there is a reason for cloud administrator to interfere here 17:33:09 User deploya an application from this package 17:33:22 What about user? Ex an example, I deployed an application which has public method backup. I don't want this method to be called as I did not prepare backup env. How I can disable it? 17:34:01 Since all action are are done on behalf of the user, using his\ resources. 17:34:02 For a deployed application user may see a list of endpoints (call them "hooks" if you wish) which we configured by admin 17:34:14 and then use them as he wishes 17:34:41 sergmelikyan: application publisher may not be aware about the cloud environment and its capabilities 17:34:41 gokrokve, there could not be actions outside of the application/environment 17:35:05 ativelkov: This will require admin to read the application DSL and in advance figure out all use cases for users. 17:35:13 I don't think that this will work. 17:35:19 ativelkov, sure but cloud administrator is not aware about which action what capabilities require 17:35:32 That's a good point, I agree 17:35:56 But I don't think that app publisher can define this alone as well 17:36:05 gokrokve, but I don't see how registering action in API gives any benefits 17:36:16 sergmelikyan: +1 17:36:33 actually, "registered event" will be just additional keyword to the method declaration 17:36:35 So. application developer will expose as much as possible to the outside to have a flexibility. User will do a fine tune of what he wants to use and what should be prohibited in his environment. 17:37:17 gokrokve, who is "user" that you are mentioning? 17:37:22 sergmelikyan: tha actual implementation can be different. This BP just shows the requirement of: 17:37:35 1) ability to list hook available for application 17:37:57 2) enable\disable there hook in his particular deployment 17:38:15 User is a person who deployms an app in his environment 17:38:58 I've got your point 17:39:04 As I said, app developer will tend to expose as much as possible 17:39:15 Do you mean that action are available to someone that does not have any access to actual deployed environment? 17:39:23 User will tend to restrict as much as possible allowing anly hooks which he actually uses 17:39:50 I just don't like the term "hook" 17:40:03 gokrokve, what reasons to restrict? 17:40:03 You can do this by exposing actions directly. But there should be API call to list them and enable them 17:40:08 As these are just a publicly available actions 17:40:16 publicly?! 17:40:36 sergmelikyan: because you can break something 17:40:44 well, I mean, from outside of the environment 17:40:54 What reason may be to have them publicly available? 17:41:30 If resources to which this actions/commands apply available only to the user? 17:41:32 sergmelikyan: I mean there are 3 types of accessability for class actions 17:41:41 sergmelikyan: these actions are exposed to outside. someone sends a request to this hook and Murano will perform action which may be undesired from user perspective 17:41:56 1) private - i.e. the actions which are called only by other actions of this class 17:42:40 2) old-sense public (you may call them "internal" , which is similar to C#) - actions which may be called by other classes of this environment 17:42:48 sergmelikyan: because 3rd party systems not necesserely integrated with keystone 17:43:06 3) gokrokve-sense public (or "hooks") - to allow calling them via murano-api or notifications 17:43:11 * ozstacker is away: off to smoke some crack with triplecheesesina 17:43:19 * ozstacker is back (gone 00:00:01) 17:43:51 Like, ceilometer will call "scaleUp" action 17:44:08 so, scaleUp action is publicly available via some API 17:44:18 but ceilometer could not call this action without user authentication - resources are money 17:44:36 Nice point 17:44:56 This means that the user - when generating a URL for this action - may specify some secret key there 17:46:10 So, the actual method will be called by calling muranohost/api/v2/enviroments/%env_id%/%app_id%/event_name/?token=... 17:46:36 where the token is generated by user's request 17:46:50 We may think about using barbican to share this secret 17:46:57 But this is a long-term goal 17:47:09 We need a simple concept to begin with 17:48:07 I would still think about admin's ability to restrict the usage of the public actions for the whole package 17:48:21 But this is also just a desired option 17:48:31 In general I like gokrokve's proposal 17:49:34 Any other concerns about this topic? 17:49:38 let's move on. 17:49:52 So, have we agreed that this feature is needed? 17:50:01 What is about devstack gate? 17:50:30 Feature itself is needed. I have customer's demand for it. 17:50:31 #agreed to have a public action discovery and enablence 17:50:55 #topic Open discussion 17:51:09 I think in case of direct control over which method may be called by what service we need some way to register specific action under specific (i think random) URI with specific access token that can be shared with one or more applications. Simularly how it is done in many existing authentication systems. 17:51:46 sergmelikyan: yes, exactly 17:51:49 And this is should be done on methods marked somehow as 'public/external' 17:52:14 yup 17:52:17 So, the devstack gate. That's mostly a question to tnurlygayanov 17:52:41 afaik, there are two patchsets waiting: one in infra, another one in our repo 17:53:03 The links can be found in incubation-status etherpad 17:53:27 probably tnurlygayanov can give more update on this. Timur? 17:53:50 hm ) 17:53:53 hi there ) 17:54:18 yes, we have devstack scripts and functional tests for devstack gates 17:54:44 and we just wainting for aprove 17:55:00 Here the link https://review.openstack.org/#/c/75078/ 17:55:21 tnurlygayanov: there are some unresolved comments in your patch https://review.openstack.org/#/c/74998/ 17:55:29 and also this https://review.openstack.org/#/c/74998/ 17:55:37 yes, I will fix it 17:55:50 Dmitry Teselkin will help me with it 17:55:56 I hope ) 17:56:53 Good, sounds nice 17:57:02 Any other questions? 17:57:42 Sorry for being late, but can we schedule hangout to discuss event handling? This seems to be much wider topic 17:58:25 stanlagun: we may do it in IRC, so others may join 17:58:27 And life-cycle management in general 17:58:34 we can make it tomorrow in murano channel 17:58:54 others can join hangout too 17:59:12 We'll IRC is a common way 17:59:28 We may start in IRC and will move to hangout if everybody are ok with that 17:59:37 I'll schedule a meeting and send an invite 17:59:50 We are running out of time 17:59:55 * ozstacker is away: 18:00:14 So, just a reminder: TC will be reviwing our incubation request today 18:00:18 at 20:00 UTC 18:00:33 All who are interested may join #openstack-dev 18:00:38 Thanks for joining, bye ) 18:00:39 Ok) 18:00:41 #endmeeting