17:00:25 #startmeeting murano 17:00:26 Meeting started Tue Dec 15 17:00:25 2015 UTC and is due to finish in 60 minutes. The chair is sergmelikyan. Information about MeetBot at http://wiki.debian.org/MeetBot. 17:00:27 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 17:00:30 The meeting name has been set to 'murano' 17:00:40 Hi folks :) 17:00:41 o/ 17:00:50 Hi ;) 17:00:52 o/ 17:03:06 o/ 17:03:09 hi 17:03:19 Todays agenda is pretty empty: https://wiki.openstack.org/wiki/Meetings/MuranoAgenda 17:05:10 o/ 17:05:32 sry for being late, seems like I'm still in time for the rollcall 17:05:40 yep :) 17:06:02 tho with you here let's move to the action items review :) 17:06:18 yeah I think I had one there.. ) 17:06:18 #topics Action Items Review 17:07:20 kzaitsev_mb: you promised to outline pros and cons of abandoning milestones & bps 17:07:25 I was to write a letter starting a discussion about abandoning milestones, yep 17:07:28 haven't done that 17:07:40 let's keep the action item then please 17:08:09 #action kzaitsev_mb write a letter about abandoning milestones and/or blueprints 17:08:18 will this include discussion about murano-apps releasing? or it is better to put this to a separate topic? 17:08:45 katyafervent: I don't think so. seems separate to me 17:09:02 ok, agreed 17:09:43 to start a meaningful discussion on murano-apps release model change we should get to puppet and heat-template folks and other app-like repositories and take a look at how they manage their repos 17:09:47 and how they release that 17:09:48 #topic Open Discussion 17:10:05 And I don't think I'll find time till next meeting to do that. 17:10:30 But I'll surely bring the topic as soon as I'll have a suggestion ) 17:10:31 I guess we should start documenting current release model before trying to change that 17:10:39 I have an item for the open part 17:11:24 right now we have the glare plugin placed in murano's contrib folder 17:11:43 And it has its own setuptools setup.py / setup.cfg pair 17:12:09 Which is - a bit- weird, since the top level directory has its own setup.py/cfg 17:12:31 and same goes for not only glance plugins but also for murano plugins as well by the way 17:12:39 sergmelikyan: right 17:12:46 ativelkov: are there any examples/best practices on how to do that? 17:12:59 like maybe someone does anything similar 17:13:04 kzaitsev_mb: I've had a conversation recently 17:13:08 with iyozhikov 17:13:51 I remember searchlight guys said, that they basically do the same, for their plugins 17:13:57 He suggested to either split them into separate git repos (if they are indeed independent projects with their own release cycles etc), or to unite their setup.cfg's 17:14:25 When we discussed possible murano plugin for searchlight he suggested it would live in the searchlight repo for now 17:14:30 so, have a single setup.cfg which defines all the different entry points, including the main murano's cripts (api, engine etc) and the plugins in appropriate namespaces 17:14:55 ativelkov: but that would mean to install murano on machine where glance is installed 17:15:03 ativelkov: you didn't answer the question though — are we the first to encounter this kind of situation? 17:15:19 and why this is the issue 17:15:33 sergmelikyan: for glance plugin - yes 17:15:44 (but eventually it will get the dependency on murano anyways) 17:16:06 kzaitsev_mb: I don't know, we need to investigate other projects which use stevedore-based plugins 17:17:36 I believe that this may make sense at least for the murano plugins (class and package type extensions) 17:17:37 searchlight does use stevedore, but i don't see setup.cfg of individual plugins 17:17:53 since they have to be deployed in the same env with murano anyway 17:18:26 given two options you suggested — I'd merge the setup.cfgs 17:18:27 kzaitsev_mb: they have all their plugins in their main setup.cfg 17:18:28 https://github.com/openstack/searchlight/blob/master/setup.cfg#L28-L33 17:18:39 oh, right, they do 17:19:15 sergmelikyan: according to iyozhikov the reason for the issue is somewhere in the way they do packaging 17:19:22 ativelkov: this is in the case when plugins are essentially are part of the solutions 17:19:45 sergmelikyan: right, and that's true for all our plugins except glance's artifact type 17:19:47 but what about contrib plugins which are not supposed to be a part of the solution out of the box? 17:20:05 as release liaison for mitaka I kind of don't like the idea of managing 1 more repo =) so don't count on me supporting that idea =) 17:20:08 ativelkov: I would say vice versa 17:20:29 sergmelikyan: nope. Murano type and package type plugins are part of murano 17:20:47 ativelkov: not always, there are not essential part 17:20:49 glance artifact type is part of glance. But is placed in murano 17:21:03 neither are searchlite index backends - they are optional 17:21:05 ativelkov: but when it will get dependency to the murano... 17:21:45 so yeah, I don't have any solution for now 17:21:57 just wanted some input from you guys 17:22:24 I believe we should take a look at other projects that use stevedore =) there must be plenty 17:22:27 I don't have a strong opinion right now... I don't like neither option 17:22:39 we've seen searchlight, probably there would be others 17:23:09 and probably ask them why they chose what they chose 17:23:21 maybe there would be something we don't see right away 17:23:55 maybe... and there are also few things to consider 17:24:39 number of plugin kinds that we have 17:24:46 and how they are tied to the Murano itself 17:25:41 because option of joining setup.cfg implies essentially making this plugin part of Murano 17:26:25 well, we may also ask the glance team about the idea of storing all the artifact types code in glance. For core and big-tent projects, of course 17:26:26 you mean murano plugins? 17:27:06 not the glare-murano plugin, but murano plugins. I believe we don't have any official ones right now. Are we planning to do that? 17:27:35 kzaitsev_mb: we do 17:27:53 at some point we want to make the core library a plugin 17:28:03 ativelkov: where is it then? 17:28:05 which will include the pythonic part 17:28:30 oh right 17:28:40 cloudify and heat are now pluggable 17:28:42 duh 17:28:49 however, that's a different story, since we want to be able to release it independently from murano 17:28:51 having a separate repo won 17:29:03 kzaitsev_mb: ? 17:29:04 won't help though, but would rather harm IMO 17:29:15 while having it in the same setup.cfg does not allow to do this independent releases 17:29:28 since we have a lot of plugins 17:29:53 kzaitsev_mb: does heat use stevedore? The last time I checked, they were just loading the python modules from files on disk, without registering them in python env 17:30:40 ativelkov: https://github.com/openstack/heat/blob/master/requirements.txt#L58 17:30:55 don't know why they use it or what for, but they do 17:31:16 obviously I'm not a heat expert ) 17:31:27 https://github.com/openstack/heat/tree/master/contrib/heat_docker 17:31:47 here they have an independent setup.cfg 17:32:24 yep 17:32:25 (although this does not look like a stevedore plugin, since it does not have entry-points in its cfg) 17:33:01 Well, what about sending a question to the ML asking for stevedore best practices here? 17:34:02 ativelkov: we need to solidify our use-cases and so on... then I guess we will find solution 17:34:14 ativelkov: +1 17:34:16 ativelkov: can you gather this in some etherpad/e-mail first? 17:34:29 ok, will do 17:34:42 #action ativelkov to summarize the plugin usage questions in etherpad 17:37:28 Anything else? 17:57:54 Looks like no :) 17:57:57 #endmeeting