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