17:00:26 <ativelkov> #startmeeting Murano Community Meeting
17:00:27 <openstack> Meeting started Tue Jan 21 17:00:26 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:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:30 <openstack> The meeting name has been set to 'murano_community_meeting'
17:00:47 <ativelkov> Hi folks
17:01:09 <ativelkov> It's time for Murano meeting, isn't it?
17:01:20 <katyafervent2> Hi
17:02:00 <ativelkov> Let's start then
17:02:05 <stanlagun> hi
17:02:16 <ativelkov> #topic AI review
17:02:38 <ativelkov> We had lot's of actions related to the new DSL
17:02:51 <ativelkov> stanlagun to submit the sources to a custom repo
17:03:12 <ativelkov> Stan, as far as I remember you've done that
17:03:24 <ativelkov> Could you please remind us the url to this repo?
17:03:40 <stanlagun> https://github.com/istalker2/MuranoDsl
17:04:20 <ativelkov> #info new DSL is temporary availalble at custom repo at https://github.com/istalker2/MuranoDsl
17:04:50 <ativelkov> We'll need to decide where to put it when it is ready for integration into 0.5
17:05:32 <katyafervent2> Right now?)
17:06:00 <ativelkov> We'll, there is no rush, but we need to start working on the actual 0.5 soon
17:06:45 <katyafervent2> I suggest murano-common or repository
17:06:58 <ativelkov> +1 for murano-common for DSL
17:07:24 <ativelkov> DSL engine is reusable, so common is a good placce for it
17:07:44 <stanlagun> murano-shared
17:07:58 <ativelkov> stanlagun: is it going to be a new repo?
17:07:59 <tnurlygayanov_> ok, let's move it to murano-common. One more repository& )
17:08:42 <katyafervent2> We do have murano common and shared has the same meaning though
17:09:12 <ativelkov> We will need to reorganize our repos. But this requires a discussion - let's first cover all the open AIs first
17:09:23 <stanlagun> I would suggest having "murano" for reusable parts and "murano-services" for services
17:10:09 <ativelkov> Second AI is "stanlagun to update the DSL description according to the implemented PoC"
17:10:40 <ativelkov> PoC is still in its final implementation steps, right?
17:11:29 <stanlagun> not yet done as PoC is not fully implemented and still there are several problems left. But it is close to final steps as today I've done ~70% of remaining changes in DSL
17:12:12 <ativelkov> Good.
17:12:38 <ativelkov> So, the last AI is not applicable as weel. It was on me, and I was supposed to organize a call with Dmitry to demonstrate the PoC
17:12:51 <ativelkov> So, we expect this to happen during this week
17:13:02 <ativelkov> right?
17:14:09 <stanlagun> not sure on documentation, but as for PoC - yes
17:14:33 <ativelkov> #info DSL PoC to be completed this week. Documentation could be delayed
17:14:39 <ativelkov> So, the AIs remain the same
17:14:47 <ativelkov> #action stanlagun to update the DSL description according to the implemented PoC
17:14:56 <ativelkov> #action ativelkov to schedule a meeting with Dmitry
17:15:04 <ativelkov> OK, we are done with the AIs
17:15:09 <ativelkov> #topic New DSL
17:15:46 <ativelkov> So, speaking about the new DSL: what remain to be done in terms of implementation?
17:17:13 <stanlagun> Several APIs to talk to Heat and Agents, several YAQL functions/macro  and most difficult - memoization of some DSL methods
17:17:43 <ativelkov> what do you mean by memoization?
17:17:46 <stanlagun> That is make Deploy be callable many times without side effects
17:18:05 <stanlagun> And syncronization between several parallel callers
17:19:42 <ativelkov> Ah, you mean the logic when a method can be caused only once with the given set of parameters, and the result is kept in memory, so subsequent calls return the same without actual computations?
17:19:49 <ativelkov> can be alled*
17:19:53 <ativelkov> called**, sorry )
17:20:10 <stanlagun> yes, more or less
17:21:10 <ativelkov> Ok. Any estimates on this?
17:22:16 <stanlagun> this is all parts of PoC
17:22:26 <stanlagun> so this week, as i said
17:23:11 <ativelkov> Ah, good
17:24:03 <ativelkov> Anything else to discuss about the New DSL?
17:24:36 <stanlagun> lets continue on next CM
17:25:20 <ativelkov> Ok
17:25:29 <ativelkov> #topic Release 0.4.1 status
17:25:50 <ativelkov> katyafervent2, can you give an update on the ststaus of the release?
17:26:14 <katyafervent2> Heap, everything is on track
17:27:14 <ativelkov> On the last meeting we agreed to add support for Neutron LB in this delivery. Any progress on this?
17:27:20 <katyafervent2> Work for all items that we were added to our deliverables are in progress
17:27:35 <tnurlygayanov_> ativelkov, yes
17:27:53 <katyafervent2> First part of  blueprint was implemented by Serg
17:28:01 <tnurlygayanov_> neutron support was reviewed and added two new blueprints
17:28:13 <tnurlygayanov_> for 0.4.1
17:28:14 <ativelkov> tnurlygayanov_: have we deployed the LB to some of our labs?
17:28:14 <tnurlygayanov_> https://blueprints.launchpad.net/murano/+spec/auto-assign-floating-ip
17:28:15 <katyafervent2> And just small piece left
17:28:25 <tnurlygayanov_> and https://blueprints.launchpad.net/murano/+spec/auto-assign-virtual-ip
17:28:52 <katyafervent2> Also we do have several medium bugs left
17:28:56 <tnurlygayanov_> yes, I deployed it on my QA environment with devstack
17:29:32 <ativelkov> #info Neutron LB support implementation in progress
17:29:41 <ativelkov> #info release 0.4.1 on track
17:30:07 <katyafervent2> And from now we do need to concentrate more on testing
17:30:32 <ativelkov> Please note that 0.4.1 should not have any strict dependencies on IceHouse artifacts or trunk
17:30:34 <katyafervent2> Also Dmitry is done with devstack integration
17:31:34 <tnurlygayanov_> yes, we will test it with devstack from trank
17:31:55 <ativelkov> tnurlygayanov_: please test in on latest Havana
17:31:56 <katyafervent2> Let's move on
17:32:14 <tnurlygayanov_> ativelkov, it it already done.
17:32:21 <ativelkov> good.
17:32:56 <ativelkov> The reason I am asking is that it is likely that 0.4.1 may be included in MOS 4.1, which will be Havana-based
17:33:24 <ativelkov> So, the next item in our agenda
17:33:34 <ativelkov> #topic Repository reorganization
17:33:50 <ativelkov> That's a long topic and probably will require more meetings
17:34:03 <ativelkov> But in general I see a problem with our infrastructure
17:34:29 <ativelkov> we have 11 (eleven) repositories
17:34:58 <ativelkov> that is about 5 times more then optimal :)
17:35:26 <ativelkov> We need to reorganize them
17:35:47 <ativelkov> At the same time, we need to preserve testability
17:36:58 <ativelkov> Also, it is ok to have a separate repos for python bindings (python-muranoclient or whatever it is called) and OpenStack Dashboard plugin
17:39:12 <ativelkov> I would suggest to have a signle repository for the main components of Murano (we will need to merge murano-api, murano-conductor and murano-repository), a single repo for python bindings (need to merge python-muranoclient and murano-metadataclient)
17:39:16 <stanlagun> services + python-client + UI + app catalog services metadata + (maybe) shared code + docs = 5-6 at minimum. How do you make less?
17:39:49 <dteselkin> what about murano-deployment ?
17:39:56 <stanlagun> +1
17:40:02 <ativelkov> what is the diff between "service" and "app catalog services metadata"?
17:40:19 <stanlagun> services = api/conductor etc.
17:40:30 <ativelkov> metadata should be there as well
17:40:39 <ativelkov> it is a core component for us
17:40:46 <stanlagun> metadata = app templates, sample services. Those are pure YAML/templates etc
17:41:09 <ativelkov> Ah, the examples
17:41:13 <ativelkov> They should go to extra
17:41:32 <ativelkov> as well as deployment scripts, buildable docs etc
17:41:48 <stanlagun> Don't think that metadata for core classes like Object can be considered as extra
17:42:19 <ativelkov> I don't speak about core classes
17:42:36 <ativelkov> core shoould be stored in the main repo, altogether with the engine itself
17:43:30 <ativelkov> I don't see the reason for such granularity
17:43:42 <stanlagun> Core classes are part of initial AppCatalog content and should be also installed to glance
17:44:18 <ativelkov> And what is the problem with that if they reside in the primary repo?
17:44:27 <stanlagun> Alongside with common base class library
17:45:40 <stanlagun> If they would be in a separate repository companies could make forks with custom basic workflows adopted for concrete IT
17:46:01 <ativelkov> We don't want any forks of our base library!
17:46:09 <stanlagun> Why?
17:46:19 <ativelkov> We have inheritence for that
17:46:31 <ativelkov> Forking is not an openstack way of doing this
17:46:58 <ativelkov> Base library should remain base :)
17:47:48 <ativelkov> And anyway, if somebody wants to fork, they can fork the whole repo
17:48:30 <ativelkov> The packaging and glance-publsihing should be done by deploymnet scripts
17:48:50 <stanlagun> I don't speak about inheritance. I talk about uses cases like "all Vms in our cloud must be booted from volume" or have additional security constraints or additional workflow steps. If you use inheritance for this you would have to create a custom version of every possible service in catalog instead of modifying one class "Instance"
17:48:51 <ativelkov> And the location of the sources for these packages is irrelevant
17:50:41 <ativelkov> in this case yes, the custom fork of the library is possible, but I don't see reasons to have different repo for that
17:51:08 <ativelkov> There may be need to modify the engine as well - with approximately the same probability of this need
17:51:20 <ativelkov> So, they can fork the whole repo
17:52:00 <ativelkov> Anyway, I would suggest to initiate a discussion
17:52:14 <ativelkov> Probably there is more then one way of doing this
17:52:41 <ativelkov> I suggest to write to infra ML and ask for better practises and some advices from openstack folks
17:53:00 <stanlagun> Well not with same probability. Metadata is designed to be modified by cloud-ops while code is not. But this not neccessary mean you're wrong :)
17:54:04 <stanlagun> Fo me metadata is an advanced version of config files
17:54:23 <ativelkov> Cool. Do you suggest to have a separate repo for all the config files? ;)
17:55:08 <ativelkov> #action ativelkov to write to ML about repository re-organization
17:55:30 <ativelkov> Guys, we have 5 minutes left. It seems like we have to continue the repo discussion later
17:55:57 <ativelkov> One more note: next week gokrokve and me will be at Glance mini-summit in Washington DC
17:56:24 <ativelkov> Could someone else lead a community meeting on the next week?
17:58:39 <ativelkov> Any volunteers? ;)
17:59:21 <gokrokve> Volunteers will be assigned :-)
17:59:29 <ativelkov> Nice idea )
17:59:41 <ativelkov> I likee this way of volunteering! )
17:59:47 <ativelkov> Ok, thank's all for joining
17:59:53 <ativelkov> #endmeeting