17:00:13 <kzaitsev_mb> #startmeeting murano
17:00:15 <openstack> Meeting started Tue Jun 28 17:00:13 2016 UTC and is due to finish in 60 minutes.  The chair is kzaitsev_mb. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:16 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:18 <openstack> The meeting name has been set to 'murano'
17:00:43 <kzaitsev_mb> #topic rollcall
17:00:59 <kzaitsev_mb> let's see who is going to make it to todays meeting =)
17:01:13 <vakovalchuk> \o/
17:01:15 <freerunner> \o/
17:01:21 <kzaitsev_mb> A large portion of our team has a day off today )
17:01:27 <vakovalchuk> like me
17:01:33 <zhurong> 0/
17:01:36 <kzaitsev_mb> like you, yep =)
17:01:54 <StanLagun> o/
17:04:25 <kzaitsev_mb> Let's see if we have finished any of the AI from last time )
17:05:07 <sergmelikyan> o/
17:05:23 <kzaitsev_mb> #topic Action Items Review
17:06:16 <kzaitsev_mb> 1) Nikolay_St kzaitsev_mb draft a spec with all the options we have considering swtiching from glance v1 to glance v2
17:06:27 <kzaitsev_mb> that one is still in progress
17:07:00 <kzaitsev_mb> mine about asking horizon guyse is related and will be in the spec
17:07:21 <kzaitsev_mb> #action Nikolay_St kzaitsev_mb draft a spec with all the options we have considering swtiching from glance v1 to glance v2
17:07:37 <kzaitsev_mb> 2) Nikolay_St check convergence on 2d CI host and enable it
17:08:01 <kzaitsev_mb> I think it's also not done yet, Nikolay has been working hard to enable 3d host for our CI lately
17:08:46 <kzaitsev_mb> He's real close, so I guess he'll do that as soon as he get's a break from configuring the CI =)
17:09:10 <kzaitsev_mb> #action Nikolay_St enable convergence on CI
17:09:29 <kzaitsev_mb> I guess it's time we just start using it and sort out any problems heat throws at us
17:09:50 <kzaitsev_mb> btw, I actually though we use heat from devstack on our CI, but apparently we dont
17:09:53 <kzaitsev_mb> =/
17:11:18 <kzaitsev_mb> not that we're using any complex heat features and should rely on the latest heat for CI puporses...
17:11:36 <kzaitsev_mb> so I'm kind of ok with not having it that way
17:11:59 <kzaitsev_mb> just feels that we should remove it from CI then — should speed up tests by a minute or two
17:12:02 <kzaitsev_mb> ok,
17:12:06 <kzaitsev_mb> to the agenda
17:12:16 <kzaitsev_mb> #link https://wiki.openstack.org/wiki/Meetings/MuranoAgenda
17:12:37 <kzaitsev_mb> #topic murano-agent release model
17:12:50 <kzaitsev_mb> This one is going to be really short unfortunatelly
17:13:04 <kzaitsev_mb> #link https://review.openstack.org/#/c/334534/
17:13:31 <kzaitsev_mb> I've added a review, and wrote a letter just recently about the agent
17:14:08 <kzaitsev_mb> but 1) apparently we've missed the window for changing the release model
17:14:24 <kzaitsev_mb> I was really really sure that in mitaka it was m3, not m1
17:14:37 <kzaitsev_mb> but then again it might be my memory playing tricks on me
17:14:58 <Nikolay_St> hi all
17:15:03 <Nikolay_St> sorry for being late
17:15:09 <kzaitsev_mb> so we would have to postpone this idea untill ocata I guess =/
17:16:37 <kzaitsev_mb> anyways, I welcome you guys to leave comments in the review and to my mail regarding agent's release model
17:18:27 <kzaitsev_mb> I think I'll try getting some of the dhellman's time and talk with him if we can go and change versioning of murano-agent. Since I surelly don't want to release a 3.0.0 version of the agent — the only real change that justifies it is py3 I guess
17:19:12 <kzaitsev_mb> then again — we're not really tied to any branches with it
17:19:24 <kzaitsev_mb> so we can just release a 2.1.0 at the end of the cycle
17:19:42 <kzaitsev_mb> but I'm not really sure what the milestone tags should be then..
17:20:47 <kzaitsev_mb> #action kzaitsev_mb clarify with the release-team versioning of milestones and full releases of murano-agent ETA: N2
17:20:55 <kzaitsev_mb> feels more like a monologue today =)
17:21:10 <kzaitsev_mb> Nikolay_St: was it you who added convergence item to agenda?
17:21:49 <Nikolay_St> kzaitsev_mb: no
17:22:02 <kzaitsev_mb> let me check the wiki history then
17:23:04 <kzaitsev_mb> freerunner: looks like it was you
17:23:05 <freerunner> kzaitsev_mb: Hm, I can't find convergence item in our agenda -_-
17:23:21 <kzaitsev_mb> #topic Make murano-coverage job voting and add coverage jobs to client and dashboard in non-voting mode
17:23:29 <kzaitsev_mb> so, what's you take on it? =)
17:23:38 <kzaitsev_mb> oh man
17:23:40 <kzaitsev_mb> it's coverage =)
17:23:43 <freerunner> -_-
17:23:50 <freerunner> coverage, ofc =)
17:24:11 <freerunner> Folks, I would like to propose the following change as mentioned in topic
17:24:47 <kzaitsev_mb> StanLagun: ativelkov: sergmelikyan: ^^^
17:24:58 <sergmelikyan> +
17:25:04 <sergmelikyan> I totally support that
17:25:05 <freerunner> I think, that our coverage job is stable now. So, making it voting will give us a little bit more coverage
17:25:22 <kzaitsev_mb> zhurong: your opinion is also important =)
17:25:26 <sergmelikyan> question is - do we actually running tests using heat at all? because my understanding is no
17:25:34 <sergmelikyan> than enabling convergence would not change anything
17:25:42 <kzaitsev_mb> sergmelikyan: it's coverage not convergance
17:25:50 <sergmelikyan> or may be I am misunderstanding something?
17:25:56 <sergmelikyan> kzaitsev_mb: :D
17:26:11 <sergmelikyan> yeah, I am misunderstanding question like totally )
17:26:19 <StanLagun> don't like the idea of coverage job
17:26:28 <freerunner> Actually, I would like also add this job to muranoclient and dashboard.
17:26:28 <kzaitsev_mb> freerunner wants us to write more tests )
17:26:38 <freerunner> kzaitsev_mb: Exactly :)
17:26:43 <sergmelikyan> I am worried that coverage job doesn't count muranopl tests
17:27:03 <sergmelikyan> StanLagun: reasons?
17:27:26 <StanLagun> not because it's bad but because it's not always good and if its voting you have to improve the coverage in each commit even if your tests are not unit-tests and don't count
17:27:58 <kzaitsev_mb> StanLagun: not exactly, you can have no more than 5 more uncovered lines than before
17:28:06 <kzaitsev_mb> so you can in fact decrease the coverage
17:28:10 <sergmelikyan> :D
17:28:14 <StanLagun> :)
17:28:17 <kzaitsev_mb> but just really really a little =)
17:28:23 <sergmelikyan> folks, you are discussing how to cheat :)
17:28:29 <sergmelikyan> this is not right )
17:28:41 <kzaitsev_mb> sergmelikyan: not exactly =)
17:28:57 <sergmelikyan> freerunner: what is out coverage for murano?
17:28:59 <StanLagun> I'd hate to see fake units tests that cover something else, not the code in the commit just to satisfy the job
17:29:11 <freerunner> sergmelikyan: In percentage?)
17:29:16 <sergmelikyan> yes
17:29:18 <kzaitsev_mb> it's more about the fact that it's sometimes hard to write good unit tests. or even impossible. If we're fixing a race condition for example
17:29:46 <freerunner> sergmelikyan: ~68%
17:30:19 <freerunner> sergmelikyan: This is unit test coverage.
17:30:38 <freerunner> sergmelikyan: I really would like to increase it.
17:31:14 <kzaitsev_mb> yeah, 68 seems a bit low
17:31:15 <Nikolay_St> freerunner: oh
17:31:23 <Nikolay_St> we have very bad coverage :D
17:31:36 <Nikolay_St> so, I'm +1 for voting job
17:31:48 <kzaitsev_mb> I wouldn't say, that 68 is very bad )
17:33:25 <freerunner> Yep, it is bad, but not very bad. It will be ok, that our code will be covered for 85% + , for example ;)
17:33:26 <StanLagun> I'd say we should improve coverage but I have more faith in our developers to think that the only way to do it is to hit ourself in the head
17:33:48 <sergmelikyan> ?
17:34:12 <sergmelikyan> why you call that "hit ourself in the head"? :)
17:34:21 <freerunner> s/head/leg/g
17:34:25 <freerunner> mm?
17:34:35 <sergmelikyan> I would propose to keep the job non-voting until we have acceptable level of coverage
17:34:53 <sergmelikyan> s/hit/shoot
17:35:08 <StanLagun> I mean if we can improve coverage we should do it anyway. No need to go extreme and require coverage improvements on each commit even where it's impossble
17:35:40 <StanLagun> hit in the heat like if the job doesn't enforce you you won't do anything
17:35:40 <freerunner> StanLagun: Stan, then we will do it really slow.
17:35:51 <sergmelikyan> but from other perspective it's does not require to cover more, only cover what you are proposing for review
17:36:01 <kzaitsev_mb> freerunner: lets file a bp and advertise it on the ML and start improving that, shall we? =)
17:36:05 <sergmelikyan> which seems fare, we should cover our code with tests
17:36:25 <freerunner> kzaitsev_mb: File a bp for coverage or what?)
17:36:43 <StanLagun> wishlist bug
17:36:46 <freerunner> kzaitsev_mb: Filing a bp for voting jobs is overkill
17:36:47 <kzaitsev_mb> for increasing coverage, yep )
17:38:04 <freerunner> kzaitsev_mb: Really? I do not think, that this is helps us to increase our coverage shortly.
17:38:16 <sergmelikyan> So, I am voting for postponing making this job voting, but I encourage to set -1 for any change-request which is not covered by unit-tests and was not really clear how this works or reviewer has any doubts that it will work as expected
17:38:28 <sergmelikyan> *had
17:38:33 <kzaitsev_mb> freerunner: writing tests to increase the coverage is a good entry-level contribution opportunity
17:39:00 <kzaitsev_mb> so, I would say, that we can benefit from advertising it on the ML, filing a bp and leading this initiatives ourselves
17:39:04 <sergmelikyan> So - you, as a reviewer, think that code might not work or have troubles reading the code? Set -1 and ask for unit-tests
17:39:22 <kzaitsev_mb> also, well, we're reviewers, right, we can always -1 if the job is red
17:39:23 <sergmelikyan> kzaitsev_mb: what is your opinion on my proposal?
17:39:46 <freerunner> kzaitsev_mb: That's will be the same if the job will be voting.
17:40:17 <kzaitsev_mb> I like sergmelikyan's idea more than making the job voting right now
17:40:45 <kzaitsev_mb> freerunner: making the job voting wouldn't make us increase the coverage
17:40:55 <kzaitsev_mb> actually writing more tests would
17:41:13 <freerunner> kzaitsev_mb: This is not equal?
17:41:13 <kzaitsev_mb> and I suggest to do that in a most open way possible
17:41:24 <kzaitsev_mb> freerunner: I believe not.
17:41:50 <freerunner> More tests == more coverage
17:42:43 <kzaitsev_mb> freerunner: making job voting won't increase the coverage
17:43:32 <freerunner> kzaitsev_mb: Maybe, but at least - this will help us to keep our 68% +
17:43:36 <kzaitsev_mb> freerunner: if the job would be voting — we would not write the tests for the 30% that we lack
17:43:59 <sergmelikyan> I think we can go to the next item in agenda, and save argues for #murano
17:45:31 <freerunner> -_-
17:45:53 <kzaitsev_mb> #agreed Not to make coverage job voting, -1 in case the job is red
17:46:02 <kzaitsev_mb> at least we didn't agree otherwise )
17:46:13 <freerunner> looks like..
17:46:36 <kzaitsev_mb> #topic Open Discussion
17:46:42 * freerunner upset
17:47:21 <kzaitsev_mb> #action kzaitsev_mb file a bp and advertise it in the ML
17:47:44 <sergmelikyan> #action comfort freerunner
17:47:47 <kzaitsev_mb> =)
17:48:09 <kzaitsev_mb> #action kzaitsev_mb file a bp and advertise it in the ML about increasing the coverage
17:48:34 <kzaitsev_mb> We can always do that at least ;) regardles of voting or non-voting job
17:48:54 <kzaitsev_mb> Since we're talking about jobs
17:49:41 <kzaitsev_mb> Can we delete gate-murano-pylint job? =)
17:50:00 <kzaitsev_mb> does anyone really check it? =)
17:50:17 <freerunner> kzaitsev_mb: Yep. I forgot to add this item to agenda :)
17:50:39 <Nikolay_St> kzaitsev_mb: I remember that we have a bp/bug to make pylint job green
17:51:00 <kzaitsev_mb> I think Philip Blaha added it, but since then I'm not really sure that anyone looks at it's results
17:51:11 <freerunner> Nikolay_St: Could you find it, please?
17:51:18 <kzaitsev_mb> the job is green
17:51:49 <Nikolay_St> freerunner: https://blueprints.launchpad.net/murano/+spec/reduce-pylint-warnings
17:51:56 <Nikolay_St> ddovbii added it
17:52:17 <kzaitsev_mb> but well the exceptions it throws are... vague at least )
17:52:33 <kzaitsev_mb> "Too many statements (51/50)" =)
17:53:02 <freerunner> ["Similar lines in 3 files", "from murano.dsl import constants"]
17:53:06 <freerunner> lol :)
17:53:54 <zhurong> folks, shall we discuss about this patch:https://review.openstack.org/#/c/334943/ about murano-client with OSC
17:54:33 <kzaitsev_mb> freerunner: exactly
17:55:24 <freerunner> zhurong: Well, I like this patch.
17:55:34 <zhurong> And Tang Chen give me another review:https://review.openstack.org/#/c/333311/ ironicclient which project -2 to this
17:56:08 <kzaitsev_mb> zhurong: it should be in test-requirements.txt
17:56:13 <kzaitsev_mb> I believe
17:56:38 <kzaitsev_mb> ok, I'll propose the patch with removal of the pylint job and would advertise it on #murano
17:57:33 <kzaitsev_mb> or well
17:57:46 <kzaitsev_mb> zhurong: just putting it back into requirements doesn't solve anything really
17:57:57 <zhurong> yeap, but the comment is ironicclient give a lot of information for not include osc-lib right now
17:58:17 <freerunner> zhurong: It's unstable?
17:58:24 <zhurong> osc-lib  not a stable version, there will change a lot
17:58:52 <kzaitsev_mb> so it should either be reverted back to openstackclient in the code, or we shouldn't accept this commit imo
17:59:10 <freerunner> zhurong: Hm, this changing everything.
17:59:39 <kzaitsev_mb> ok, we're almost out of time
17:59:54 <kzaitsev_mb> let's move the rest to #murano and to the review itself
18:00:04 <zhurong> ok
18:00:06 <freerunner> kk
18:00:09 <kzaitsev_mb> thanks for coming
18:00:12 <kzaitsev_mb> #endmeeting