17:01:26 <serg_melikyan> #startmeeting murano
17:01:27 <openstack> Meeting started Tue Jun  9 17:01:26 2015 UTC and is due to finish in 60 minutes.  The chair is serg_melikyan. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:01:28 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:01:30 <openstack> The meeting name has been set to 'murano'
17:01:34 <serg_melikyan> Hi folks :)
17:01:35 <serg_melikyan> o/
17:01:47 <katyafervent> 0/
17:01:48 <kztsv_mpb> all.
17:01:54 <StanLagun> o/
17:01:58 <FilipBlaha> Hi!
17:02:03 <freerunner> Yo!
17:02:12 <kztsv_mpb> btw. is it ok to change names? (kzaitsev here) =)
17:02:19 <aderyugin> Hi!
17:02:24 <Nikolay_St> o/
17:02:25 <ruhe> o/
17:02:40 <kztsv_mpb> ate there any stats or smth for meetings?
17:02:41 <serg_melikyan> Yeah, better to stick with one that you are using always though :)
17:03:04 <serg_melikyan> kztsv_mpb: about which stats you are talking about?
17:03:09 <kztsv_mpb> I intend on using several with different _smth postfix
17:03:27 <serg_melikyan> There is following staff: http://eavesdrop.openstack.org/meetings/murano/2015/
17:04:07 <kztsv_mpb> I think I saw a talk, that mentioned some stats about irc meetings
17:04:13 <serg_melikyan> Agenda for today's meeting: https://wiki.openstack.org/wiki/Meetings/MuranoAgenda
17:04:19 <kztsv_mpb> maybe I'm imagining things =)
17:04:26 <serg_melikyan> We have pretty packed agenda for today :)
17:05:13 <serg_melikyan> #topic Action Items Review
17:05:35 <serg_melikyan> #1 sergmelikyan create a doodle to select date for overview meeting
17:06:04 <serg_melikyan> I've sent e-mail regarding Murano Mid-Cycle Summit, please take a look and participate in choosing date and time
17:06:29 <serg_melikyan> http://lists.openstack.org/pipermail/openstack-dev/2015-June/066326.html
17:06:58 <serg_melikyan> I encourage you to open this doodle right now and participate ;)
17:08:11 <serg_melikyan> Participated? :)
17:08:21 <serg_melikyan> Let's move on? :)
17:08:29 <kztsv_mpb> are dates in UTC?
17:08:33 <serg_melikyan> Yep
17:09:06 <katyafervent> I've already set my dates :)
17:09:54 <serg_melikyan> Ok :)
17:10:01 <katyafervent> so 10 will be 13:00 Moscow time and we have a meeting at that time
17:10:06 <serg_melikyan> #topic Use launchpad.net/murano-apps
17:10:35 <serg_melikyan> I've sent e-mail regarding using separate launchpad project for our openstack/murano-apps repository and didn't get any feedback on that
17:10:47 <serg_melikyan> that's why I've added this item to our agenda
17:10:59 <katyafervent> Yeah, we should move all bugs related to the murano-apps to the new project
17:11:29 <katyafervent> You can add AI for me or some other person who is willing to do that :)
17:11:45 <katyafervent> Anybody?
17:12:06 <serg_melikyan> I would start asking about if there any objections to that or not :)
17:12:26 <kztsv_mpb> I see no objections to using launchpad.net/murano-apps
17:12:50 <katyafervent> Well, I don't know what would be in blueprints
17:13:21 <katyafervent> and is it ok to support 3 different preojects?
17:13:24 <serg_melikyan> new apps?
17:13:45 <katyafervent> Yeah, ok
17:13:53 <katyafervent> +1 from me
17:14:20 <Nikolay_St> +1
17:14:55 <katyafervent> I can go through bugs, select related to murano-apps and put the correct tag (as the result of the next topic discussion)
17:15:20 <serg_melikyan> Ok, decided :)
17:15:20 <katyafervent> And next topic is
17:16:04 <serg_melikyan> #agreed we are going to use launchpad.net/murano-apps for tracking bugs & bp related to apps
17:16:31 <serg_melikyan> #action katyafervent will re-assign open bugs for apps to newly created project
17:16:51 <ruhe> should it be reflected in documentation, primary LP project, README files?
17:16:52 <serg_melikyan> #action sergmelikyan will populate project with appropriate release milestones
17:17:05 <serg_melikyan> ruhe: for sure,
17:18:00 <serg_melikyan> #info documentation, readme needs to be updated to include information about lp/murano-apps
17:18:08 <kztsv_mpb> This probably deserves a small 'documentation' bug then. Will add.
17:18:52 <serg_melikyan> kztsv_mpb: thank you :) I expect that in Liberty you will hold a flag of "ultimate bug-fixer" :)
17:19:17 <serg_melikyan> #topic Use tags in launchpad (see Propose Tags section below)
17:19:33 <serg_melikyan> katyafervent: finally we are switched to your topic :)
17:20:10 <katyafervent> Ok. So we have a need in better bug filtering
17:20:36 <katyafervent> to do that tags can help, since it's not so many tools that LP provides
17:20:53 <katyafervent> I wanted to make a list, that will be used in murano project
17:21:19 <katyafervent> I found similar list of tags, that are used in other OpenStack projects
17:21:50 <katyafervent> So we can use project-wide tags
17:22:04 <katyafervent> and approve tags for murano and update wiki after that
17:22:24 <katyafervent> https://etherpad.openstack.org/p/murano-tags
17:22:32 <katyafervent> Here is the list of proposed tags
17:23:10 <katyafervent> there are 10 bugs
17:23:21 <katyafervent> please, provide your opinion
17:23:40 <serg_melikyan> I've took a look at the proposed list of the tags and found them pretty use-able, but we can't rely on the fact that users will assign appropriate tags to the bugs
17:23:51 <kztsv_mpb> I strongly agree with the whole idea of tags. (I've already started using general OS tags for bugs that I file.)
17:23:54 <serg_melikyan> tags assigning should be part of the triaging process
17:24:01 <katyafervent> That's why bug-supervisors exist
17:24:23 <serg_melikyan> katyafervent: sure :)
17:24:28 <kztsv_mpb> serg_melikyan: I guess the bug still has to be confirmed and/or triaged by someone. that person should also put tags if appropriate
17:24:37 <katyafervent> I have a question regarding tag " issues related to python-muranoclient use as a library"
17:25:16 <katyafervent> is there only 2 types of bugs in murano-client: library-related and cli-related
17:25:23 <katyafervent> is it tru&
17:25:40 <serg_melikyan> I have concern regarding how useful this practice will be in reality - I didn't have issues with filtering before, and we don't have contributors that are working specifically on one of the code-base parts like engine or api
17:26:23 <serg_melikyan> I am not sure that these tags will be used at all (I mean used for filtering, not assigning)
17:26:24 <kztsv_mpb> well there can't be engine-related bugs in python-muranoclient, right? =)
17:26:31 <katyafervent> Yes, and we don't have low-hanging-fruite for a long time and this is not good
17:26:44 <serg_melikyan> katyafervent: agree with that
17:26:55 <serg_melikyan> I was mostly talking about db/engine/api and so on
17:26:58 <kztsv_mpb> I've added several low-hanging-friuts recently ;)
17:27:18 <serg_melikyan> So +1 for the idea from me, let's how it will work for us
17:27:23 <katyafervent> so, if bug is not marked with cli tag it belongs to client library and do we need separate tag for that?
17:27:26 <StanLagun> what tag to use for hot-packages bugs? for plugins? TOSCA etc?
17:27:55 <kztsv_mpb> StanLagun: I do not think, that we should tag every bug
17:28:00 <katyafervent> we can update list of tags
17:28:15 <Nikolay_St> I know that in Sahara they use plugin-name tags for plugins
17:28:19 <katyafervent> look to the Glance list, they have artefacts tag, it's kind of a new
17:28:39 <katyafervent> +1 for hot
17:28:42 <serg_melikyan> StanLagun: you want so detailed tags?!
17:28:43 <katyafervent> or heat
17:28:48 <serg_melikyan> -1 for hot
17:29:00 <katyafervent> but plugins are not supposed to managed by murano
17:29:02 <serg_melikyan> We will end-up with tag per each feature in that way
17:29:08 <ruhe> my experience shows that it is time to introduce new tag once there is a sufficient amount of bugs under this group
17:29:12 <serg_melikyan> and it will be a mess
17:29:34 <StanLagun> serg_melikyan, no, I don't. Just tying to figure out how to use the tags in the list. Have bugs without tags looks good to me
17:29:44 <serg_melikyan> Nikolay_St: in our case we don't have yet some set of core plugins
17:30:04 <Nikolay_St> serg_melikyan: ok, it was just a suggestion
17:30:20 <StanLagun> db tag looks strange
17:30:25 <katyafervent> Please, answer:  so, if bug is not marked with cli tag it belongs to client library and do we need separate tag for that?
17:30:41 <serg_melikyan> I generally think that list of tags should be as small as possible - we should not increase they number.
17:31:01 <StanLagun> serg_melikyan, +1
17:31:29 <serg_melikyan> katyafervent: sorry did't get you question
17:31:31 <katyafervent> so what about library tag and hot tag.
17:31:32 <StanLagun> do we really need them at all?
17:32:03 <katyafervent> StanLagun, how often are you looking for a bug to fix?
17:32:05 <serg_melikyan> -100000 for hot tag, let's not extend number of tags from ones that are already proposed
17:32:14 <katyafervent> new contributors will do it all the time
17:32:23 <serg_melikyan> let's start with current proposal and see which tags will be used in reality
17:32:42 <kztsv_mpb> StanLagun: Sure we do. Say we have a great front-end developer, ready to work on our dashboard bugs. How would you filter them for him?
17:32:44 <ativelkov> folks, tags are intended to be added by anyone, aren't they?
17:32:45 <serg_melikyan> katyafervent: as new contributor you have no idea what hot and engine is
17:32:55 <serg_melikyan> ativelkov: yeah
17:33:05 <katyafervent> The problem is that we know about almost all bugs we have, so we don't have to filter them
17:33:16 <ativelkov> so, if we limit the list of tags, they stop being tags
17:33:24 <kztsv_mpb> katyafervent: do we? =) I don't =)
17:33:34 <katyafervent> what if I used to contribute to other openstack project
17:33:38 <ativelkov> so, if someone wants to have a tag called "hot", why shouldn't he add one?
17:33:57 <ativelkov> we just need a list of tags which have meaning for us as maintainers
17:33:59 <katyafervent> and to heat also, the best start would be to look how murano interacts with heat
17:34:15 <ativelkov> i.e. proposed-%releasename%, low-hanging-fruit etc
17:34:25 <katyafervent> ativelkov, +1 it's not 100% mandatory
17:34:26 <StanLagun> katyafervent, I prefer readable bug titles. Also I I was frontend developer it would still be a good idea for me to walk through whole bug list so that I don't miss something
17:34:27 <Nikolay_St> I agree with katyafervent
17:34:59 <ativelkov> all other tags may have meaning for other developers
17:35:49 <serg_melikyan> ativelkov: +1 for using this list of tags as ones that we use as maintainers but anyone can add any tags he/she wants to his bug
17:35:52 <katyafervent> so let's add heat or hot ( I actually prefer heat) May be it would be useful for contributors from Alcatel
17:36:22 <ativelkov> may be we let contributor from Alcatel to decide what they need? :)
17:36:56 <serg_melikyan> #startvote Accept proposed list of tags as list used during bug-triaging, do not extend this list with new tags unless we see that people use them everyday? Yes, No
17:36:57 <openstack> Begin voting on: Accept proposed list of tags as list used during bug-triaging, do not extend this list with new tags unless we see that people use them everyday? Valid vote options are Yes, No.
17:36:58 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
17:37:11 <kztsv_mpb> #vote Yes
17:37:14 <katyafervent> I just want to help, ok let's move on
17:37:15 <serg_melikyan> #vote Yes
17:37:30 <katyafervent> #vote Yes
17:37:41 <Nikolay_St> №vote yes
17:37:44 <ativelkov> #vote Yes
17:38:02 <StanLagun> #vote yes
17:38:17 <StanLagun> though I don't like db tag
17:38:21 <freerunner> #vote yes
17:38:49 <serg_melikyan> StanLagun: yeah :) I would also prefer database - so if katyafervent doesn't mind I would prefer database
17:39:18 <StanLagun> serg_melikyan, I'd like not to have it at all. This is too specific
17:39:29 <StanLagun> db is part of api
17:39:47 <serg_melikyan> StanLagun: it's details, let's not discuss this here
17:40:01 <serg_melikyan> We can argure forever on list of tags and spelling
17:40:02 <FilipBlaha> #vote Yes
17:41:16 <Nikolay_St> StanLagun: many projects uses db tag.
17:41:49 <kztsv_mpb> any more votes?
17:41:56 <serg_melikyan> #endvote
17:41:57 <openstack> Voted on "Accept proposed list of tags as list used during bug-triaging, do not extend this list with new tags unless we see that people use them everyday?" Results are
17:41:59 <openstack> Yes (7): StanLagun, ativelkov, katyafervent, serg_melikyan, kztsv_mpb, freerunner, FilipBlaha
17:42:07 <serg_melikyan> Flawless victory :)
17:42:16 <katyafervent> db is used in all other projects, so let's make it universal
17:42:32 <serg_melikyan> #agreed accept proposed list of tags as list used during bug-triaging, do not extend this list with new tags unless we see that people use them everyday
17:42:37 <katyafervent> AI to update wiki on me
17:43:06 <serg_melikyan> #link list of proposed tagshttps://etherpad.openstack.org/p/murano-tags
17:43:09 <katyafervent> #action Ekaterin Chernova update OpenStack wiki with approved tag list
17:43:17 <serg_melikyan> #link list of proposed tags https://etherpad.openstack.org/p/murano-tags
17:43:38 <serg_melikyan> #topic Set proxy for instance automatically
17:43:56 <serg_melikyan> ativelkov: can you elaborate a little bit on this topic
17:43:57 <serg_melikyan> ?
17:43:59 <ativelkov> right
17:44:10 <ativelkov> So, I had a cnverstation with one of our customers using Murano
17:44:57 <ativelkov> One of the most significant issues they have is the fact that their VMs do not have internet connectivity due to their enterprise security policies
17:45:40 <ativelkov> so, our execution plans cannot run successfully, as software repositories are not accessible from the VMs
17:45:46 <FilipBlaha> the same in our office :-)
17:46:05 <ativelkov> FilipBlaha: yeah, this should be a regular case
17:46:38 <ativelkov> the workaround is obvious: to add an execution plan which configures VMs to use a proxy server
17:46:57 <ativelkov> (at least if such proxy exists in this particular enterprise)
17:47:11 <serg_melikyan> FilipBlaha: which workaround you are using to overcome that issue?
17:47:50 <FilipBlaha> we are using images with already set proxy (workaround)
17:47:58 <serg_melikyan> ativelkov: you propose to write a small library that would be able to do that or extend Murano to support that by default for LinuxMuranoInstance?
17:49:10 <ativelkov> Yes, I propose to add extra property to Instance class and appropriate method implementation in its inheritors to set-up proxies
17:49:44 <ativelkov> So, the Instance page of the wizards will need to get extra optional fields to setup the proxy
17:50:08 <ativelkov> right now it will be painful, as it will require us to change the UI definition of each application
17:50:25 <ativelkov> so, +1 reason to implement the "per-component ui" feature
17:50:47 <ativelkov> another thing to do is to add murano-wide default for this value, and read it from config file instead of asking the user
17:51:22 <ativelkov> which is probably a better approach, as this is actually a cloud's environment setting, which should not be part of users' input
17:51:46 <slagun> ativelkov, proxy is a policy because if need needed it is needed for all instances and there is no need to configure it per-object. Also apps doesn't know about proxy and it would be wrong to expect every app to ask for it. This should be implemented as an aspect
17:52:28 <ativelkov> slagun: yeah, sure. But I don't believe in aspects appearing before the U release
17:52:43 <slagun> it may be implemented via config option till then
17:52:56 <ativelkov> (where U stands for "Unicorns" if you know what I mean)
17:53:13 <ativelkov> slagun: yes, config option is exactly what I speak about :)
17:54:04 <slagun> ativelkov, I'm a little bit more optimistic on this as there are too many use cases for them. I'd like them to be a part of M release roadmap. But this is off-topic
17:54:13 <serg_melikyan> ativelkov: Let's start with blueprint and bring this topic to mailing list?
17:54:21 <serg_melikyan> we have not so much time left for today
17:54:26 <ativelkov> (still, a per-object override may be needed: in the same way we use to specify images and flavors per-instance. Proxy configuration are no difference from them)
17:54:31 <ativelkov> serg_melikyan: agree
17:54:39 <ativelkov> #action ativelkov to file a BP on proxies
17:54:41 <slagun> we can make use of per-class configs for this feature
17:55:31 <serg_melikyan> #topic Backports to stable/kilo & stable/juno (see Backport links)
17:55:39 <serg_melikyan> I propose to move this topic to ml as well
17:55:48 <serg_melikyan> kztsv_mpb: ok?
17:56:02 <kztsv_mpb> sure
17:56:47 <kztsv_mpb> in short — I'm working on a list of backports and will write a letter about that shortly.
17:56:53 <serg_melikyan> #topic Open Discussion
17:57:04 <serg_melikyan> Few minutes but still :)
17:59:20 <ativelkov> none asked
17:59:23 <serg_melikyan> #endmeeting