17:01:48 <ativelkov> #startmeeting murano
17:01:49 <openstack> Meeting started Tue Mar 18 17:01:48 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:50 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:53 <openstack> The meeting name has been set to 'murano'
17:02:04 <ativelkov> Hi folks
17:02:07 <tsufiev_> hi!
17:02:09 <sergmelikyan> o/
17:02:10 <ruhe> hi
17:02:11 <dteselkin> Hi!
17:02:18 <katyafervent2> Hi
17:02:18 <ativelkov> Anybody here for Murano meeting? Identify youself please
17:02:44 <ativelkov> Cool. Let's start then
17:02:57 <ativelkov> Agenda is here: #link https://wiki.openstack.org/wiki/Meetings/MuranoAgenda
17:03:40 <ativelkov> First item is AI review, however we don't have any AI's from the last time )
17:03:42 <ruhe> i have to take my words back about me not being able to attend the meeting :)
17:04:23 <ativelkov> ruhe, good ) Then you can present your idea on your own
17:04:34 <ativelkov> so, let's get started
17:04:44 <ativelkov> #topic Getting rid of murano-common
17:05:01 <ativelkov> Ruhe, please lead this
17:05:08 <ruhe> i've outlined all the pros and cons in the https://wiki.openstack.org/wiki/Meetings/MuranoAgenda
17:05:32 <ruhe> does anyone have something to add that list?
17:05:41 <ruhe> *to that list
17:06:04 <ativelkov> The idea is to have voting on this
17:06:27 <ativelkov> So, if somebody wants to calify something or ask questions - it's just about time to do it
17:06:52 <sergmelikyan> I don't think that we need specific LP project for murano-common
17:07:11 <tsufiev_> wasn't there 3rd option: don't touch murano-common before 0.5 release :)?
17:07:17 <sergmelikyan> We can merge tracking issues with main repository (like it is done now)
17:07:45 <ativelkov> If these two repos have different version numbers, then we should manage the release independently
17:07:46 <ruhe> sergmelikyan: well, if you have a project, then you need to track it's releases, track bugs and plan them for a release
17:08:06 <sergmelikyan> And actually we don't care much about dependency not listed in g-requirement in nearest feature (1-2 month)
17:08:34 <sergmelikyan> *future
17:08:38 <ruhe> tsufiev_: what you're speaking about is close to option #1
17:08:49 <tsufiev_> i agree that having a separate LP project for murano-common is too much for murano-common
17:09:45 <sergmelikyan> "there are just 20 commits in a 9 months history of this project" - so nor maintaining overhead that listed in 1 approach, since there is not so much code
17:09:45 <ruhe> the reason for both options is to avoid dependency hosted on tarballs.o.o
17:09:45 <tsufiev_> so, +1 for 2nd option (given that murano-common codebase remains roughly the same size)
17:10:20 <tsufiev_> i mean, copy-paste code
17:10:47 <sergmelikyan> +1 for first option - since we actually do nothing more that we did'nt before.
17:10:50 <katyafervent2> as for me we should show Murano-v0.5 as ready for incubation project - and with reduced amount of repos. If we have a chance to do it now, why do not to try?
17:11:11 <sergmelikyan> katyafervent2, why we SHOULD show that?
17:11:48 <katyafervent2> because we will present it on summit, so even we will not show everyone will see that
17:12:22 <sergmelikyan> katyafervent2, I am not sure how everyone should see that
17:12:28 <katyafervent2> so +1 for the second one
17:12:34 <ativelkov> stanlagun (who is absent today) had a valid concern: what happens if we need some more shared code in future?
17:12:46 <sergmelikyan> But lets just vote , and don't spent precious time
17:12:54 <ativelkov> #startvote Which option to choose for murano-common? 1, 2
17:12:55 <openstack> Begin voting on: Which option to choose for murano-common? Valid vote options are 1, 2.
17:12:56 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
17:13:04 <sergmelikyan> #vote 1
17:13:13 <ativelkov> #vote 2
17:13:16 <katyafervent2> #vote 2
17:13:17 <ruhe> option 1 - keep it, option 2 - get rid of it by copy-paste
17:13:23 <ruhe> #vote 2
17:14:07 <ativelkov> tsufiev_, dteselkin?
17:14:15 <tsufiev_> #vote 2
17:15:04 <dteselkin> #vote 2
17:15:34 <ativelkov> Anybody else?
17:16:01 <gokrokve_> #vote 2
17:16:01 <ativelkov> #endvote
17:16:01 <openstack> Voted on "Which option to choose for murano-common?" Results are
17:16:02 <openstack> 1 (1): sergmelikyan
17:16:03 <openstack> 2 (6): tsufiev_, ruhe, ativelkov, katyafervent2, dteselkin, gokrokve_
17:16:20 <ativelkov> gokrokve_: last moment vote, thanks )
17:16:58 <ativelkov> #agreed to copy murano-common code to modules which use it (murano-api and murano-agent) and drop murano-common repository
17:18:04 <ativelkov> So, it seems like other agenda items remained unchanged from the previous week
17:18:24 <ativelkov> ApplicationCatalog API and UI for the Application Catalog
17:19:24 <ativelkov> I don't see much changes in these topics since last week, so I don't feel we need to discuss them again
17:19:40 <ativelkov> Does anybody have anything more important to discuss?
17:19:57 <gokrokve_> UI
17:20:08 <gokrokve_> What is a final decision on action list>
17:20:12 <gokrokve_> What is a final decision on action list?
17:20:29 <gokrokve_> Can API generate this tree like structure from class definitions?
17:20:34 <gokrokve_> Do we want to do this?
17:20:35 <tsufiev_> gokrokve_: it seems, there won't be nested actions in 0.5
17:21:12 <tsufiev_> also, i think actions should move from Environment level to Application level
17:21:45 <ativelkov> Yes, I think the API will be able to retrieve the actions for a given application instance
17:21:51 <ativelkov> not for any nested entities
17:22:45 <ruhe> gokrokve_: speaking about UI. maybe we should publish screenshots of our fancy drop-off forms in ML in hope that we'll get comments from UX experts?
17:23:30 <tsufiev_> ruhe: i'd suggest first show our last AppCatalog design to our UX guy )
17:23:32 <gokrokve_> ruhe: As soon as we agreed on implementation side, yes.
17:23:52 <ruhe> good
17:24:01 <gokrokve_> ok. So we move action list to application.
17:24:37 <gokrokve_> And show only highest level classes.
17:24:46 <tsufiev_> yes
17:24:47 <ativelkov> yes
17:24:55 <tsufiev_> that way it will be much simpler
17:25:18 <gokrokve_> sure
17:25:29 <gokrokve_> but I think about nested resources like LB
17:25:46 <ativelkov> gokrokve_: we will support this
17:25:47 <gokrokve_> which can expose important events
17:25:52 <ativelkov> But later
17:25:55 <gokrokve_> ok
17:26:08 <ativelkov> because we will need a common way for navigating through the environment
17:26:16 <ativelkov> think of zoom-in/zoom-out
17:26:30 <ativelkov> And this will requires nested storage etc
17:26:52 <gokrokve_> I did not get it.
17:27:21 <tsufiev_> ativelkov: i doubt that zoom+/zoom- is realistic until 'next-gen UI'
17:27:29 <gokrokve_> So do we expect to see a new API method for actions or it will be a part of app info?
17:27:31 <ativelkov> Well, displaying nested resources is needed not only for action list
17:27:44 <ativelkov> There will be an API method
17:27:55 <ativelkov> It is yet to be decided how it will work
17:28:09 <gokrokve_> can we mock up it for now?
17:28:28 <gokrokve_> to add required changes to client and UI
17:28:53 <gokrokve_> so add a new API method which returns some static data for now.
17:29:14 <gokrokve_> We need to know data fromat and call methods to continue our work in other components.
17:30:01 <ativelkov> Ok, we will add it
17:30:27 <katyafervent2> ttps://etherpad.openstack.org/p/muranorepository-api
17:30:43 <katyafervent2> you can share your thoughts here
17:31:41 <katyafervent2> also we need to prepare package samples
17:32:39 <ativelkov> I've started working on that
17:33:33 <tsufiev_> tomorrow I hope to finish with 1st version of ui definition for ActiveDirectory app
17:34:04 <tsufiev_> so we'll have almost all resources for the first package
17:35:04 <ativelkov> Good
17:35:57 <tsufiev_> ativelkov: i've mastered yaql to do my biddings :)
17:36:09 <ativelkov> tsufiev_: cool!
17:36:19 <ativelkov> BTW, yaql 0.2.2 is published on PyPI
17:37:09 <ruhe> ativelkov: is this the version we're going to use in murano 0.5?
17:37:18 <ativelkov> yes
17:38:08 <ativelkov> porting DSL to use yaql 0.3 should be part of the goals for Murano 0.6
17:38:47 <ruhe> yes, there are some parts of Murano DSL which should be probably ported back to yaql
17:39:32 <ativelkov> ruhe: what do you mean?
17:40:14 <ruhe> there are some helper classes around yaql in Murano DSL which might be a part of yaql library
17:40:35 <ativelkov> You mean, part of standard yaql functions?
17:40:40 <ruhe> right
17:41:03 <ativelkov> Probably, yet I would keep yaql itself lightwight
17:41:15 <ativelkov> probably we may have something like yaql-contrib
17:41:27 <ativelkov> to support various extensions
17:41:35 <ativelkov> But this is discussbale
17:42:58 <ativelkov> Any other questions or topics to dicsuss?
17:43:53 <ativelkov> Then let's wrap up
17:44:06 <ativelkov> #endmeeting