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