07:00:23 #startmeeting Heat 07:00:24 Meeting started Wed Nov 25 07:00:23 2015 UTC and is due to finish in 60 minutes. The chair is skraynev. Information about MeetBot at http://wiki.debian.org/MeetBot. 07:00:25 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 07:00:28 The meeting name has been set to 'heat' 07:00:30 #topic rollcall 07:00:55 hi 07:01:17 stevebaker, shardy: ping 07:02:37 O/ 07:02:47 ramishra: looks like only we will be here ;) 07:02:58 skraynev: it seems all busy preparing for thanksgiving tomorrow;) 07:02:59 O/ 07:03:26 o/ 07:03:27 ramishra: probably yes ;) 07:03:38 rico_, rakesh_hs: hi 07:03:51 skraynev: hi 07:04:02 Hi! 07:05:09 #topic Adding items to agenda 07:05:17 #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-11-25_0700_UTC.29 07:06:07 there is nothing special ;) only usual topics + check status of actions from last meeting 07:07:31 what is the status of making convergence gate job voting? 07:07:48 Is it there in the agenda? 07:07:49 ramishra: it's next one 07:07:53 yeap 07:08:16 I suppose, that nothing new for agenda, so let's go to the next item 07:08:30 #topic Check status of actions from last meeting 07:08:40 So first action was on me 07:08:47 skraynev sync with HP guys for making convergence job voting to the end of the next week 07:09:18 ramishra: probably this is what you wondering for 07:09:59 So, I suppose, that all know about plans about convergence for this week ;) 07:10:10 I had a chat with Kanagaraj. 07:10:11 rakesh_hs: we have only one fix in progress to make the gate go green 07:10:32 He said something like this ^ 07:10:33 :) 07:10:41 lol 07:10:54 I am here, had an irc client fail 07:10:58 o/ 07:11:00 rakesh_hs: is there fix on review? 07:11:05 https://review.openstack.org/#/c/248676/2 07:11:07 stevebaker: cool ;) 07:12:02 the whole chain starting from https://review.openstack.org/#/c/241598/16 needs reviews 07:12:17 rakesh_hs: looks like dependent patch has -1 from Kanagaraj 07:12:28 this one https://review.openstack.org/#/c/243715/6 07:12:39 skraynev: could this be added to the agenda "release notes with reno" 07:12:55 stevebaker: sure 07:13:24 stevebaker: done 07:13:25 skraynev: Yeah, I am addressing that 07:13:31 rakesh_hs: Me and KanagarajM had a discussion about it needs update 07:14:05 rakesh_hs: ananta: ok. Do I correctly understand, that other patches in this series are ready ? 07:14:34 skraynev: yes 07:14:43 we will just rebase after fixing it 07:15:03 https://review.openstack.org/#/c/241598/ can actually go in 07:15:22 ananta: Ok. I planned to do it today ;) 07:16:17 skraynev: sure 07:16:30 stevebaker: shardy: feel free if you have a time to help with review these ^ patches 07:16:38 sure 07:16:51 next action was: skraynev or somebody else send mail and start re-organization for specs repository according last suggestion 07:16:53 will do 07:16:57 it's in progress 07:17:11 just need to finish writing the mail ;) 07:17:26 I will send it today ;) 07:17:55 that's all about this topic. next one... 07:18:07 #topic Review priorities 07:18:19 #link https://etherpad.openstack.org/p/heat-reviews 07:18:48 I have added one patch for enabling batching for Heat scheduler 07:18:57 which we discussed on the summit 07:19:41 stevebaker: p.s. I forgot to review openstackclient integration :( I will try to do it.. I promise ;) 07:19:45 I won't add it yet as it needs tests, but I'd appreciate some eyes on https://review.openstack.org/#/c/226384/ 07:19:52 can someone put that last convergence series in there? 07:20:17 It's the reauthenticate on token expiration one, I tested it yesterday and had to add a hack which invalidates all the the client plugins 07:20:22 feedback on that welcome ;) 07:20:33 stevebaker: I can, after mail about specs repo changes ;) 07:20:43 stevebaker: added the link in heat-review 07:20:47 ta 07:20:55 skraynev: do we have a spec for scheduler batching? I could not find one. or it's agreed that it's not required;) 07:22:18 ramishra: we had not any agreement about it. I personally don't see reason, because patch is only one and looks pretty easy. However if it's necessary, we may create a spec 07:24:36 ok 07:25:05 move on 07:25:15 #topic Release notes with reno 07:25:57 stevebaker: I have heard, that it's useful thing for auto generation release notes, but had not had a chance to check it 07:26:15 #link http://docs.openstack.org/developer/reno/ 07:26:21 so that we can do any liberty or mitaka release we need to come up with some heat changes like this 07:26:25 #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/078301.html 07:27:22 These changes will need to be proposed soon, I'm happy for anyone to volunteer, but also don't mind doing it 07:28:10 I can help with that :) 07:28:51 ricolin: its yours! 07:29:26 ricolin: cool! 07:29:45 happy thanksgiving 07:29:59 :) 07:30:33 thats all from me 07:31:12 I have a topic to add, TripleO CI 07:31:16 stevebaker: thx 07:31:35 * shardy was late so didn't add it to the wiki, apologies 07:31:37 shardy: can we discuss it in Open Discussion ? 07:31:41 skraynev: sure! 07:31:56 shardy, ok, then... 07:32:03 #topic Open Discussion 07:32:33 shardy: What was happened with Tripleo CI ? 07:32:40 So, in the TripleO meeting yesterday, we discussed getting the TripleO CI running my default again for some projects, in particular Heat and Ironic 07:33:01 it would initially be non-voting, but for it to be worthwhile we'll need to pay attention to it 07:33:03 sounds good to me 07:33:08 what do folks think? 07:33:10 +1 07:33:21 +1 07:33:25 IMHO it's a good idea, because TripleO has found several serious heat bugs recently 07:33:40 recently? lol 07:33:51 constantly ? 07:33:54 :) 07:33:57 haha ;) 07:34:27 Also, we may be able to test some things indirectly, such as that token expiration patch, which will be impossible (AFAICS) via our integration tests 07:34:43 shardy: how much time it will take if compare with current jobs ? 07:35:10 skraynev: they can take up to 2 hours, but we're trying to make them faster 07:36:05 shardy: can it be launched like some test for nova or test for neutron plugins ? 07:36:27 I mean in parallel with main bunch of the tests 07:36:41 skraynev: the problem for the token expiration patch is we need to modify the token expiry of the keystone in the test environment 07:36:48 I don't know if/how we can do that 07:37:13 e.g we don't want an integration test which uses the default expiration of 1 hour, because it'll take over an hour to run ;) 07:37:13 shardy: i think that would be possible 07:37:33 shardy: agree 07:37:35 stevebaker: Ok, nice, I couldn't see how we could modify the non-heat config 07:37:52 shardy: maybe in project-config 07:37:52 stevebaker: if you can comment on https://review.openstack.org/#/c/226384 w/details I'll try it out 07:38:13 and I don't mind to launch against each patch 07:38:27 stevebaker: aha, yeah we could just reduce the expiration for all tests to $time_of_slowest_test_plus_some 07:39:12 shardy: why not even shorter? exercise it against all the tests 07:39:33 stevebaker: heh, I wasn't feeling that brave ;) 07:39:34 * stevebaker sets 1 minute tokens 07:39:48 stevebaker: I have actually been testing locally with 1-minute tokens 07:39:53 it's been exciting 07:39:54 cool 07:40:16 exciting == mostly very broken ;) 07:40:22 lol 07:40:26 lol 07:41:44 shardy: it's really strange... 07:44:39 stable/liberty gate is broken with the same magnum client plugin test as master. fix backport https://review.openstack.org/#/c/249574/ 07:45:27 shardy: Is the same behavior with patch, which you did with Oleksii? 07:45:55 ramishra: Argh... I can not merge it :) 07:45:59 ramishra: thanks, approved 07:46:13 oh, can we talk https://review.openstack.org/#/c/248189/ 07:46:33 skraynev: you should be added to stable-maint core now you're PTL ;) 07:47:06 skraynev: Yeah, I've been testing the patch Oleksii and I have been working on locally with 1-minute tokens 07:47:07 shardy: I had such thought... but I can not do it myself ;) 07:47:32 shardy: for whole list of the tests ? 07:47:41 stevebaker: sure 07:47:44 I wonder, would switching from username to userid in the notification actually break anything for anyone? Does anything that consumes username also work with userid? 07:48:47 stevebaker: I supose, if you have not good rsolving code for username 07:48:51 stevebaker: Isn't it hitting the backward consistency? 07:48:53 *resolving 07:50:17 skraynev: I think you can just mail the stable-maint list asking to be added 07:50:20 https://wiki.openstack.org/wiki/StableBranch#Joining_the_Team 07:50:57 stevebaker: it's difficult to say something more, than we change output format, which users expected before 07:51:17 it may be risky for them, but also may be not 07:51:28 skraynev: yeah it is a risk 07:51:30 it depends on how they use it 07:52:12 stevebaker: gah, I was hoping the current key was "user", but it's user_id, assigned with the name :( 07:52:15 stevebaker: I am happy to use user id, but have some doubts 07:52:36 also I wonder, is there some standard schema we can move towards for these common properties of notifications? 07:52:53 shardy; yeah. it's the cause, why I think, that it looks like a bug 07:53:45 skraynev: maybe that means it's OK to change it, but we'll have to clearly document it in the release notes 07:53:56 bug+1 07:54:08 shrady: thx. I will send mail ;) 07:54:17 I was hoping we could just add a new key and avoid breaking backwards compatibility at all 07:54:26 shardy: it's about stable-maint list ;) 07:54:45 shardy: I think what will end up happening is leaving the current key, and adding 2 new ones, userid and username 07:54:53 shardy: yes, I had such suggestion in comment too 07:54:56 so we can deprecate user_id 07:55:04 stevebaker: +1 that sounds reasonable 07:55:20 stevebaker: agree. sounds better 07:55:21 ok, lets comment in the review, moving on 07:55:31 also add some deprecate message in notification 07:55:35 stevebaker: we could deprecate tenant_id while we're at it 07:55:44 for projectid/projectname 07:55:48 or something 07:55:48 ricolin: I wonder how we can do that 07:56:06 in Log? 07:56:30 we might just need to document it 07:56:49 deprecation messages in logs aren't very useful, except for stuff like config options 07:56:50 #action shardy will add TripleoCI job in in the main list of gate jobs. This job will be still non voting. Let's try to make it faster or launch in parallel with other Heat jobs 07:57:09 shardy: it's true :( 07:57:40 shardy: sounds crazy, but we may add separate field for this Deprecation in notification format 07:57:49 skraynev: thanks, FYI it will already run in parallel 07:57:50 and then use it as we want 07:58:42 shardy: I meant something different like for nova https://review.openstack.org/#/c/248989/ 07:58:52 Jenkins check and Intel PCI CI check 07:59:20 let's continue in the #heat 07:59:32 :) 07:59:35 skraynev: it might be a separate job anywat 07:59:40 anyway 07:59:44 #endmeeting