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