17:00:46 <sergmelikyan> #startmeeting murano
17:00:50 <openstack> Meeting started Tue Mar 22 17:00:46 2016 UTC and is due to finish in 60 minutes.  The chair is sergmelikyan. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:51 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:53 <openstack> The meeting name has been set to 'murano'
17:01:08 <kzaitsev_mb> o/
17:01:13 <freerunner> \o/
17:01:17 <ddovbii> o/
17:01:49 <Nikolay_St> o/
17:02:12 <tlashchova> o/
17:03:38 <sergmelikyan> hi folks :)
17:03:51 <sergmelikyan> Looks like this is last meeting with me as a chair? :)
17:04:01 <ativelkov> o/
17:04:24 <kzaitsev_mb> I can always #addchair you =P
17:05:21 <Nikolay_St> hah
17:06:22 <sergmelikyan> :D
17:08:22 <sergmelikyan> #topic Action Items Review
17:08:52 <kzaitsev_mb> Don't think we had any =) prev time we only had status updates
17:09:05 <sergmelikyan> right )
17:09:15 <sergmelikyan> I should've checked before changing topic )
17:09:27 <sergmelikyan> #topic Status Updates (RC1, RC2)
17:09:41 <sergmelikyan> we have RC1 release and branches created, right? )
17:09:48 <kzaitsev_mb> so we had RC1 tagged yesterday
17:10:00 <kzaitsev_mb> and stable/mitaka branch is already cut
17:10:34 <kzaitsev_mb> We already have a couple of commits to backport to stable/mitaka meaning — we would most likely have to release RC2 somewhere next week
17:10:54 <kzaitsev_mb> and we agreed to have RC2 for our i18n folks anyway )
17:11:36 <kzaitsev_mb> Mitaka Release will be Apr 4-8
17:11:39 <sergmelikyan> I also propose to merge docs commits too to stable/mitaka
17:12:08 <kzaitsev_mb> RC2 will be tagged around Mar 28-1, I think
17:12:43 <kzaitsev_mb> sergmelikyan: I have no objections to merge docs to s/mitaka. we did that during liberty release cycle and I even asked release team — everyone is fine with it
17:13:11 <sergmelikyan> good, we have several things that would be nice to have in stable/mitaka
17:13:23 <kzaitsev_mb> no more updates from my side
17:13:28 <kzaitsev_mb> sergmelikyan: which ones?
17:14:35 <sergmelikyan> glare docs - https://review.openstack.org/295762
17:14:43 <sergmelikyan> I was talking about docs changes
17:14:54 <sergmelikyan> #topic Suggestion to adopt single +2 +A policy for translations bot's commits
17:15:02 <kzaitsev_mb> sure
17:15:03 <sergmelikyan> +1 I totally agree!
17:15:32 <kzaitsev_mb> this one was suggested by AJaegar, I think.
17:15:56 <kzaitsev_mb> i18n team needs to see results and the commits do not affect code
17:16:07 <kzaitsev_mb> so I'm +1 on the idea
17:16:22 <kzaitsev_mb> any objections, folks?
17:16:40 <ksnihyr> no
17:16:42 <ativelkov> +1
17:16:57 <kzaitsev_mb> ok then, I think we can say that we agree =)
17:17:07 <kzaitsev_mb> #agreed to adopt single +2 +A policy for translations bot's commits
17:17:27 <sergmelikyan> #topic Suggestion to adopt single +2 +A policy for requirements bot's commits
17:17:34 <kzaitsev_mb> this one is a bit trickier
17:17:48 <sergmelikyan> why?
17:18:04 <kzaitsev_mb> requirements do affect the code
17:18:13 <sergmelikyan> given that all tests are passing I suggest to follow same rule
17:18:14 <kzaitsev_mb> so there might be some concerns here
17:18:54 <kzaitsev_mb> although I don't really think that there can be a situation, when someone would block (-1/-2) such a commit for some reason
17:19:53 <kzaitsev_mb> So I'd rather say, that I'm +1 on this one
17:20:27 <ativelkov> Well, usually there is nothing to review there
17:20:40 <ativelkov> so, +1 from me as well
17:20:59 <slagun> +1
17:21:21 <kzaitsev_mb> cool, I think we can agree here too )
17:21:28 <kzaitsev_mb> #agreed to adopt single +2 +A policy for requirements bot's commits
17:21:54 <freerunner> #agreed as well ;)
17:22:37 <sergmelikyan> #topic Suggestion to have regular (i.e every first Tuesday of month) agenda point for backport bug triaging
17:22:47 <kzaitsev_mb> freerunner: this will be shown as a separate point on logs, be a bit carefull with that one.
17:23:05 <sergmelikyan> kzaitsev_mb: can you elaborate on this? don't really got the topic
17:23:21 <freerunner> kzaitsev_mb: damn. sorry. extra hashtag here..
17:23:27 <kzaitsev_mb> last topic from me. I've been working on making a formal document (or a wiki page) that would describe how we manage backports for murano
17:24:01 <kzaitsev_mb> I'll be finishing it shortly, this week I hope =)
17:24:58 <kzaitsev_mb> the point is — someone needs to tag bugs with ***backport-potential tags and/or nominate them for series
17:25:10 <kzaitsev_mb> I suggest, taht we would do it on regular basis in IRC
17:25:17 <kzaitsev_mb> as part of our weekly meeting
17:25:30 <kzaitsev_mb> but not on weekly basis, but rather once a month
17:26:11 <kzaitsev_mb> Like — every 1st meeting of the month would have an agenda item called (Triaging new stable-branch bugs/backports)
17:26:21 <kzaitsev_mb> what do you think of the idea?
17:26:43 <Nikolay_St> kzaitsev_mb: sounds good, but can be it'll be better to do it twice a month?
17:27:03 <sergmelikyan> I think this is helpful, but I believe we also need a person who will do this on regular basis each day, and monthly we can approve them on the meeting
17:27:59 <kzaitsev_mb> Nikolay_St: I'm not entirelly sure about the format =) every odd tuesday sounds ok to me too )
17:28:13 <kzaitsev_mb> although a bit more complicated (=
17:28:31 <slagun> we can add it to weekly agenda but skip it if there's nothing to discuss
17:28:53 <Nikolay_St> or if we have too packed agenda
17:29:10 <Nikolay_St> but not rarely than once a month
17:29:39 <Nikolay_St> also sergmelikyan has a good idea about everyday duty
17:29:57 <Nikolay_St> but I don't remember formal criteria for backport-potential bugs
17:30:06 <kzaitsev_mb> sergmelikyan: and that person has to be core, but our cores are usually busy
17:30:36 <slagun> kzaitsev_mb: why does he has to be core?
17:30:37 <kzaitsev_mb> So I'd like to have a regular meeting, when most of us can help that person )
17:31:24 <kzaitsev_mb> slagun: at least one of the drivers for murano. To be able to nominate bugs correctly
17:32:20 <kzaitsev_mb> I generally see that there are no objections to the idea iether.
17:32:23 <slagun> kzaitsev_mb: I think it is a good opportunity for newbies to get more involved into the project. Because you have to understand what those bugs are about
17:32:30 <Nikolay_St> kzaitsev_mb: I guess that if we will collect formal criterias it will be an "easy" job
17:32:41 <kzaitsev_mb> I suggest we start doing this and see where it goes (=
17:32:55 <slagun> kzaitsev_mb: it is a matter of permissions. We can always grant them
17:33:01 <kzaitsev_mb> slagun: sounds fair
17:34:00 <sergmelikyan> and criteria is simple: critical + security bugs
17:34:32 <sergmelikyan> by the way this is related to the stable-maintanance team
17:34:41 <sergmelikyan> discussion in mailing list
17:35:35 <kzaitsev_mb> sergmelikyan: well, since we're not core project and not yet managed — we're the onces who manage our stable branches
17:35:39 <slagun> if they can be backported. e.g. you need to understand first when it was introduced and what will it take to backport it.
17:36:03 <sergmelikyan> kzaitsev_mb: right, but I was talked about following practices adopted for the core projects
17:37:11 <kzaitsev_mb> slagun: sounds fair, yes =) I know that you've been mostly doing this job. Let's see if we can offload this duty off you. =) probably we would have someone volounteer =) I'll ask around
17:38:25 <sergmelikyan> let's wrap up this topic?
17:38:35 <kzaitsev_mb> ok. to wrap up — let's try having a be-weekly agnda point for triaging/tagging bugs suitable for backports, and let's see if anyone of our newfound contributors would want to volounteer for a regular tagging duty )
17:38:54 <kzaitsev_mb> and let's see where this leads us =)
17:39:13 <sergmelikyan> #agreed to have bi-weekly agenda for triagging/tagging bugs
17:39:21 <sergmelikyan> #undo
17:39:22 <openstack> Removing item from minutes: <ircmeeting.items.Agreed object at 0x9fc1f90>
17:39:34 <sergmelikyan> #agreed to have bi-weekly agenda for triagging/tagging bugs suitable for backports
17:40:15 <sergmelikyan> #topic Upgrading murano-apps (https://review.openstack.org/#/c/292889/) Pros & Cons
17:40:42 <kzaitsev_mb> ddovbii: can you please cover your points on this commit/bp
17:41:58 <ddovbii> well, i tried to provide our Simple Software configuration feature. But it seems to me that provided behavior looks weird
17:41:59 <kzaitsev_mb> I'm opposed to the current commit because 1) it makes the app slower (instead of 1 exec plan we're sending multiple) 2) it feels like an ugly hack to 1st put the file to /tmp and then run a command, that executes it
17:42:34 <ativelkov> +1 to kzaitsev_mb. The problem with the "new" notation here is that it actually does not look cleaner
17:42:52 <sergmelikyan> strongly agree with point #2
17:43:07 <ativelkov> I believe that the "simple sofware configuration" is a step in a right direction
17:43:17 <ativelkov> But we are not there yet, it is not simple yet
17:43:40 <kzaitsev_mb> on the other hand. not having these giant execution plans feels a lot easier to develop the apps with this approach for newcomers
17:43:40 <ddovbii> maybe if we had one more method like runScript it would look better
17:43:45 <slagun> there's no need to put file in /tmp first
17:44:25 <sergmelikyan> slagun: ?
17:44:25 <slagun> conf:Linux.runCommand($instance.agent, $myScript)
17:44:45 <ddovbii> I tried do it in this way
17:44:51 <slagun> you can pass the whole script to runCommand. That's why we need it in the first place
17:44:51 <sergmelikyan> $myScript: $resources.string(...) ?
17:44:57 <slagun> yes
17:45:14 <ativelkov> I would prefer more design to be put here first
17:45:14 <ddovbii> it doesn't work in all scripts
17:45:23 <ddovbii> *with all scripts
17:45:31 <slagun> if it doesn't work this way then there is a bug that need to be fixed ASAP
17:46:08 <slagun> it should work. This function is meaningless if you need to put file to /tmp first
17:46:45 <slagun> if it doesn't then the feature is broken/incomplete
17:47:04 <slagun> and fixing it is more important than apps upgrade
17:47:43 <ddovbii> slagun, I like your approach. But looks like we need to add pre-encoding to base64 in this case
17:47:44 <sergmelikyan> ddovbii: can you explain what is not working?
17:48:11 <slagun> ddovbii: maybe. Lets investigate it and do what's necessary
17:48:39 <kzaitsev_mb> I also do not really like the idea of mixing MuranoPL and bash code
17:48:59 <slagun> also we'll add more methods like executeScript() which will not require $resources.string() and turn Linux methods into extensions of Agent class
17:49:29 <slagun> kzaitsev_mb: agree. But you don't need to mix them at all
17:49:38 <kzaitsev_mb> this prevents us from being able to cleanly lint/test shell code.
17:49:40 <slagun> bash remains in resource files
17:49:47 <ddovbii> as far as I remember, deployment failed due to issues with transferring of some special symbols and quotes to VM
17:49:47 <kzaitsev_mb> slagun: agree.
17:50:14 <slagun> ddovbii: you can file a bug and assign it on me if you want
17:50:26 <kzaitsev_mb> I guess, that we'll have to postpone this commit https://review.openstack.org/#/c/292889/ until we make it work seamlessly.
17:50:31 <kzaitsev_mb> #link https://review.openstack.org/#/c/292889/
17:50:36 <sergmelikyan> +1
17:51:21 <slagun> we can put bash statements into MuranoPL in case of one-liner trivial scripts like "apt-get install something". Anything that is more complex than than need to be in resources
17:52:24 <slagun> The first thing about this commit is that in need to be split
17:52:32 <slagun> there's no need to upgrade everything at once
17:53:13 <ksnihyr> +1
17:53:20 <ativelkov> I also believe that we don't need all that applications in murano-apps at all
17:53:46 <slagun> ativelkov:  probably. But thats a different story
17:53:54 <kzaitsev_mb> ativelkov: that is a different question, yep )
17:53:59 <ativelkov> That repo is intended to host several demo apps showing various aspects of how to use murano, not the garbage heap for all the apps ever written
17:54:30 <slagun> ativelkov: I believe that's the role of a.o.o
17:54:42 <ativelkov> Well, yeah, but until it is solved we will have to revisit this topic again and again: as soon as a new feature comes up in the language or standard lib, we will be asking questions if we should update all the apps or not
17:54:44 <ddovbii> slagun, +1
17:54:44 <slagun> ativelkov: I mean to host everything possible
17:55:16 <ativelkov> slagun: a.o.o is an index, not a source code repo
17:55:53 <kzaitsev_mb> a.o.o should be our pypi, not source code repo
17:55:59 <ativelkov> yup
17:56:17 <ativelkov> and the actual apps should be hosted in their respective repos
17:56:18 <slagun> ativelkov: a.o.o can host apps from many different repos. We, as a murano team need to maintain only the one with good examples. Maybe those examples are not needed at a.o.o at all
17:56:36 <slagun> ativelkov: looks like we're on the same page here
17:56:38 <ativelkov> slagun: agree
17:56:57 <ativelkov> but for now it seems like the murano-apps repo is a pile of everything
17:57:19 <ativelkov> So, I'd propose to stop updtaing them to newer features unless that's absolutely nessesary
17:58:07 <ativelkov> When we sort it out and will select just several "perfect" demo apps we will keep them updated to match the most modern features of MuranoPL and its stdlib
17:58:19 <kzaitsev_mb> ativelkov: that doesn't sound like what even you think murano-apps repo should be
17:58:36 <kzaitsev_mb> the point of this update was to showcase new feature
17:58:53 <ativelkov> I understand
17:59:04 * sergmelikyan reminding about time
17:59:08 <kzaitsev_mb> we're almost out of time. I believe, that we'll have to revisit murano-apps topic again.
17:59:15 <ativelkov> but it turned out that 1) the feature is not good enough, 2) there are too many identical apps
17:59:22 <ativelkov> agree
17:59:25 <sergmelikyan> +1, for now let's not merge commit in questions
17:59:27 * ativelkov shuts up
17:59:41 <slagun> ativelkov: I believe we should create new app for each major feature and have a readme.txt file that describes what feature is demonstrated by what app. Once we have a better syntax we write another app instead of upgrading old one to demonstrate both old and new syntax
17:59:43 <kzaitsev_mb> but for now — I believe, that we agreed that we should polish the commit in question further
18:00:09 <sergmelikyan> #endmeeting