17:00:42 #startmeeting murano 17:00:42 Meeting started Tue Mar 11 17:00:42 2014 UTC and is due to finish in 60 minutes. The chair is ativelkov. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:43 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:45 The meeting name has been set to 'murano' 17:00:46 Hi all! 17:00:51 Hi folks 17:01:08 Those who are here for Murano, please identify yourself 17:01:12 Hi 17:01:29 Hi 17:01:39 hi 17:01:58 Ok, some folks around, let's start then 17:02:03 #topic AI review 17:02:17 We have just a few of AIs from the last week 17:02:44 BTW, agenda is here: #link https://wiki.openstack.org/wiki/Meetings/MuranoAgenda#Agenda 17:02:48 Howdy 17:02:56 o/ 17:03:14 So, the first AI was on ruhe: ruhe to add repository-reorganization BP to roadmap 17:03:31 he is not jere, as far as I can see 17:04:15 Didn't we postpone this activity? 17:04:17 But eventually it was decided to drop repository reorganization blueprint from this delivery 17:04:35 katyafervent: yes, we did. We just did it after the previous weekly meeting 17:05:02 well if we will unite 3 repos to one we'll kind of reach this) 17:05:15 #agreed to postpone explicit repo reorganization till the delivery is done 17:05:27 We have a section in agenda to discuss this 17:05:31 I'm talking about contributing new code to murano-api 17:05:35 Ok, sorry) 17:05:37 It's more then just 3 repos 17:05:51 So, the next one: tsufiev to create a BP on Marconi usage 17:06:04 Is Timur here today? 17:06:17 hi 17:06:24 Hi Timur 17:06:31 There was an AI on you: tsufiev to create a BP on Marconi usage 17:06:42 i did it ) 17:07:04 Could you please share the link? 17:07:06 https://blueprints.launchpad.net/murano/+spec/investigate-marconi-messaging 17:07:21 #link https://blueprints.launchpad.net/murano/+spec/investigate-marconi-messaging 17:07:24 Thanks 17:07:43 Did you have a chance to do the initial investifation about it? 17:08:58 tsufiev: ? 17:09:00 nope (. i've been doing a lot of CR recently 17:09:59 Ok, no problem. We are not in a rush with this. We'll need to coordinate with Dmitry on unified agent initiative, but this waits till the AppCatalog MVP is live 17:10:00 Hi! 17:10:13 Hi 17:10:15 hi 17:10:38 So, the last AI: ruhe to create BPs for infrustructure-related items in roadmap 17:10:43 ativelkov: yes, as soon as I finish with AppCatalog UI, i'll able to do it 17:11:23 ruhe: Do you have +2 rights? 17:11:45 We need to improve our review activity. 17:11:58 gokrokve: no, i didn't earn this privilegy yet :) 17:12:19 gokrokve: but i'm reviewing as hard as i can 17:12:27 cool 17:12:45 YEs, we have quite a long backlog 17:12:58 We need to catch up on this 17:13:04 sure 17:13:14 But let's keep with the Agenda ) 17:13:28 there are some patches with did not get any review since March 9th 17:13:34 sure 17:13:46 So, as for the last AI, I believe ruhe has made all the blueprints for our infra-changes 17:14:06 So, we can proceed 17:14:20 #topic Repo-reorganization progress 17:15:07 So, we have decided not to explicitly spend any time on repo-migration during this phase 17:15:34 however, there are chances to do a lot of work seemlessly 17:16:09 the only item under question is murano-common 17:16:12 We have two major blocks which are going to land to our codebase in the nearest month: a new DSL engine and a new repository API 17:16:36 should we get rid of that repo by copy-pasting it across other projects or leave it as is? 17:16:46 We've decided to put them both into the murano-api repository (instead of murano-conductor and murano-repository accordingly) 17:17:14 ruhe - yes, it seems like this is the only part which will remain outside of joined murano-api 17:17:28 btw, did we make change in review that is already in progress? 17:17:53 I believe we should fallback to copy-pasting this into the agent till we are done with its unification 17:18:07 katyafervent: which review do you mean? 17:18:30 https://review.openstack.org/#/c/75882/ 17:18:31 this one 17:19:01 Ah, we will finish reviewing it 17:19:01 katyafervent: ruhe has already copy-pasted this commit into murano-api 17:19:10 great! 17:19:22 katyafervent: i've copied this CR to murano-api. see https://review.openstack.org/#/c/79629/ 17:19:22 and oncah, then, tsufiev, please abandone it 17:19:42 oncah? 17:19:52 ativelkov: ok, once it get 2 +2 17:19:58 Sure 17:20:26 oncah was a typo, sorry ) 17:20:44 everybody is eager to know what did you mean ) 17:20:56 So, we are on a good progress with this: in 0.5 we are going to have all murano services in one repo, and a single python-client 17:21:32 that was supposed to be the beginning of "and once we have it approved.." 17:22:16 We'll manage murano-docs and murano-tests during the next iteration 17:22:33 I think copy-pasting murano-common may be not so good. 17:22:52 what do you propose instead? 17:23:29 We will end-up not only copying existing functionality to murano-agent, but also all other functionality that is currently provided by packages that is not available in global-requirements 17:23:47 what is this funcitonality? 17:23:51 bunch? 17:23:56 deepcopy? 17:24:00 deep? 17:24:13 we need to consider them one by one 17:24:18 we should remove these dependencies 17:24:36 probably we may either find other ways of doing that, or publish them 17:24:56 sergmelikyan: do you propose to first remove the dependencies and then copy-paste the result? 17:26:09 maybe we can merge agent with the rest of murano repositories and leave murano-common as a module within this unified repository 17:26:25 tsufiev, I am not sure why we need to have this troubles at all (with copy-pasting). We expect to have troubles to publish murano-common in global-requirements if Murano will be incubated before migration on other agent implementation? 17:26:46 But this will mean that the agent will be have to install everything, including engine and apis 17:27:35 Hm, folks, a funny idea... what about putting that "utils" block into the python-muranoclient? 17:27:38 ativelkov, anyway when you installing API you will also install engine 17:28:12 sergmelikyan: that's ok for a service node, which may even change its roles on the fly. It may be not ok for the client 17:28:27 s/client/agent 17:29:00 maybe we can find a way to customize installation somehow 17:29:07 probably 17:29:38 this would be also useful for API vs Engine 17:30:03 But I am still not convinced about the need to use all those dependencies in the Agent 17:30:05 I suggest to postpone merging murano-common code ether to murano repo or murano-agent 17:30:18 sergmelikyan: +1 17:30:31 actually we already agreed on that 17:30:49 We are not in a rush 17:31:00 the only problem which is really hot is Puka 17:31:19 I have already submitted patch for Puka 17:31:22 Anyway lets try to avoid copy-pasting by all means possible. 17:31:32 https://review.openstack.org/79639 17:31:34 As soon as openstack-infra updates tox on their CI, we'll get everything broken for Murano 17:32:17 As new tox will bring new pip with it, and the new pip is unable to install from untrusted sources 17:32:25 ativelkov, I have found one more issue today (it is already fixed), but had no time to fully test this patch on a lab. 17:32:42 sergmelikyan: that's good. Let's speed-up this process 17:32:44 So I believe we can ger rid of Puka in a matter of days 17:32:45 ativelkov: you mean the dev versions? 17:33:17 tsufiev: no, everything 17:33:54 :( 17:34:04 Jenkins runs tox, tox runs pip install -r requirements.txt, and it fails if pip is 1.5.4 17:34:12 There is always a temporary solution - to use regular puka instead of custom fork 17:34:53 stanlagun: I would prefer permanent solutions :) 17:35:09 As sergmelikyan has almost got one ready, I would wait for it 17:35:12 ativelkov: me too. Consider it as plan B 17:35:20 Got it 17:36:13 So, are we all agree on the repositories? 17:36:57 + 17:37:05 + 17:37:12 + 17:37:26 No objections. Cool ) Let's move on 17:37:29 #topic ApplicationCatalog API 17:37:30 ativelkov: +1 for merging but so that it would be possible to choose what deamon runs at each place. And without copy-paste 17:38:19 So, as far as I understand, gokrokve has some proposal on the repository APIs 17:38:28 yes 17:38:35 But we have already designed an API and started implementing it 17:38:47 I still want to split APi and have artifacts API which will be moved to Galnce 17:39:03 and Catalog API with handles Catalog specific actions 17:39:07 What do you mean? 17:39:26 I think that Catalog API will wrap artifact API 17:40:10 At least during the transition period 17:41:26 gokrokve: so we will have 3 APIs for the near future? 17:41:31 Yoa are right it will wrap 17:41:39 We will 17:41:53 stanlagun: Glance API will not appear in the nearest future 17:41:59 One APi will be Glance artifacts repository API 17:41:59 not till the mid of summer 17:42:17 and Murano will have its own API for catalog 17:42:44 As we don't want to change API again when artifacts API will move 17:42:44 Why don't we split them as soon as Glance API becomes available? 17:42:47 From my point of view, there may be two possible approaches: 1) murano user interacts only with Murano API for both catalog and deployment tasks, while Murano API wraps some of this calls and sends them to Glance 17:42:53 then I suggest to have a clear separation now 17:43:15 stanlagun: We can't change APi frequently 17:43:40 If we design it properly now, we will need to change endpoint instead of making a new PAI version 17:44:12 2) There are no catalog APIs in Murano at all, everything related to catalogization is done via a glance-plugin, while murano just handles the "deployment", same as nova does it now for images 17:44:40 We would not have to if Glance API is left as an implementation detail. UI should not talk to Glance directly. At least if Murano API didn't explicitly told it to do so 17:45:05 ativelkov: +1 for 1) 17:45:28 gokrokve: I don't understand how do you suppose to use glance 17:45:42 I don't say that 17:45:49 I am ok with wrapping Glance API 17:45:58 but we need to design this properly 17:46:01 ativelkov, +1 for 1 17:46:05 ativelkov, +1 the way of Glance usage 17:46:31 api version could be v1.1 or even v1.1.1 17:46:36 wrapping Glance is fine to me 17:46:57 gokrokve: if we stick to p1 above, Glance becomes a back-end for us 17:47:12 So, we will not have to change the API when we move to Glance 17:47:37 ok 17:47:48 Say, there is a POST /v?/catalog/packages call to publish a package 17:47:54 it is in our API 17:48:01 ativelkov: not neccessary 17:48:08 it may change 17:48:45 then it may either store the package in our db (as it does now), OR it may extract the archive, inspect-validate-preprocess it - and then make a glance/v2/artifacts/.. call 17:49:14 (By "as it does now" I mean "as it is designed in the version being currently developed") 17:49:44 stanlagun: I would prefern not to change the APIs unless absolutely nesessary 17:50:40 Actually, it depends on the actual logic we put there 17:51:11 I still see a possibility of the direct interaction with Glance (p2 in my "options" above) 17:51:28 I like this option less then option 1, but it has its pros as well 17:51:34 ativelkov: yes. But there are no guarantee we will not have too unless Murano API would proxy all Glance traffic. Murano API may still tell UI/Engine/Whatever do doenload something directly from Glance. Especially large files 17:52:26 stanlagun: in the case of large files it is more likely that they will be doesnloaded from the storage 17:52:38 directly, I mean, not via glance 17:52:52 Isn't Glance would be our storage frontend? 17:53:14 Glance abstracts Swift and other storages 17:54:34 I don't really want to write support for all possible storage backends 17:54:59 Glance does indeed provide such an abstraction 17:55:40 But download link provided by it may target directly to the storage 17:55:46 But I am not sure yet 17:55:52 This needs to be verified 17:56:19 So, we are almost run out of time 17:56:42 4 mins left, and still one agenda item 17:56:45 #topic UI for the Application Catalog 17:56:49 ativelkov: Again I agee on p1. Just wanted to tell that it doesn't guarantee we don't make breaking API changes once we move to Glance 17:57:07 So, any questions of the new UI drafts? 17:57:17 so we started implementing new UI layout for AppCatalog 17:58:18 it uses tile layout instead of tables 17:58:25 Yes, did we share the UI design anywhere? 17:58:47 not yet 17:59:31 I am sure we need to 17:59:47 We dont' have much time left to discuss it here 17:59:59 So I suggest either to move to the ML or to #murano channel 18:00:04 Will we remove the Service Definition tab right? 18:00:11 more to say, the UI discussion doesn't look like a fruitful one 18:00:37 It worth discussing, but now here anyway 18:00:43 Thanks everybody 18:00:47 #endmeeting