20:00:30 #startmeeting heat 20:00:31 Meeting started Wed Jun 17 20:00:30 2015 UTC and is due to finish in 60 minutes. The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:32 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:35 The meeting name has been set to 'heat' 20:00:38 #topic rollcal 20:00:44 hi all 20:00:52 \o 20:00:56 o/ 20:01:01 o// 20:01:02 o/ 20:01:22 skraynev_: 2 left arms? 20:01:47 stevebaker: take one more, while Pavlo is in vacation :) 20:01:58 #topic Adding items to agenda 20:02:08 #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-06-17_0700_UTC.29 20:03:45 #topic 5.0 20:03:50 o/ 20:03:55 o/ 20:03:58 hi 20:04:00 hi 20:04:05 hi 20:04:48 So quicker than I was expecting, all the server projects are switching to semver, so the next heat release will be 5.0 20:05:08 nothing to discuss really, just a PSA 20:05:15 stevebaker: instead of 2015.2 20:05:20 yup 20:05:21 stevebaker: there is actually a potential issue 20:05:22 stevebaker: hang on 20:05:35 stevebaker: yeah , what about our support statuses ? 20:05:43 for resources 20:05:55 I suppose, that we should change it every where? 20:06:12 if we replace 2015.2 on 5.0 20:06:13 the nova team has some deprecation messages with version numbers that will never appear, too 20:06:38 skraynev_: old releases remain the same. I guess any 2015.2 we've added recently could be changed to 5.x 20:06:51 dhellmann: what will l-1 be versioned as? 20:07:26 stevebaker, dhellmann: so right. you need update all places where you find 2015.2 version :) 20:07:39 dhellmann: resources and so on 20:07:47 I guess this means a new epoch in all the distro packaging :/ 20:07:47 stevebaker: I think ttx is planning X.0.0b1 20:08:08 zaneb: yes, epoch will be required 20:08:11 zaneb: we are so old for this ... :) 20:08:29 skraynev_: I'm not going to be able to make all of the project-specific patches needed for this, so I'm going to need someone from the heat core team to do those. I can rebase my setup.cfg change on top of that. 20:08:30 skraynev_: so s/2015.2/5.0.0/ 20:08:47 dhellmann: ok, I can help you ;) 20:08:52 skraynev_: great, thank you 20:09:19 stevebaker: yeah. sure. just want to be sure, that we replace it everywhere 20:09:26 dhellmann: regarding major numbers, do we have the potential to... 20:09:51 dhellmann: np, I will upload patchset for it tomorrow 20:10:12 skraynev_: ok, please add me as a reviewer so I definitely see it 20:10:17 dhellmann: 1) not increment the major at the M release date if there were no major changes? or 20:10:18 stevebaker: ? 20:10:30 dhellmann: 2) increment the major in the middle of a dev cycle 20:10:43 stevebaker: so in documentation we will see statuses: 2014.2, 2015.1, 5.0, ... 20:11:03 for now it's not definite but most projects seem to want to increment the major version at the release date -- it's going to make keeping up with stable branches easier 20:11:08 stevebaker: I mean for resources support statuses 20:11:13 and also for now, no on #2, until we see how the experiment with ironic goes 20:11:27 so possibly next cycle, but not this cycle 20:11:37 dhellmann: yep, understood 20:12:04 we're trying to standardize on the reasons for bumping the major version before we start letting everyone have complete control of version numbers :-) 20:12:32 it would be anarchy :) 20:12:50 right, and we're preparing for that future 20:13:03 not all projects will choose to do that, but many will 20:13:23 I would assume heat would end up with long-running major numbers if anything 20:13:45 (after convergence is the default) 20:14:17 yeah, some of the reasons we've considered for raising that number include database migration squashes, config file changes, and other things that might cause deployers to take special note of upgrades 20:14:29 in addition to the more standard API changes, of course 20:15:08 yep 20:15:36 #topic heat reviews https://etherpad.openstack.org/p/heat-reviews 20:15:54 stevebaker: before we move on, I have one more thing 20:15:58 sure 20:16:24 it's a little disconcerting that this incompatibility was a surprise -- we came within about 30 minutes of me breaking you guys by adding the tag this morning 20:16:48 so I want to make sure someone from the team is designated to be working with the release team this cycle, to make sure we don't have similar miscommunications 20:17:08 normally that's the PTL, but it doesn't have to be 20:17:25 what incompatibility are we talking about? 20:17:47 this thing with the version number checking in the heat code -- I don't actually know what it is, maybe skraynev_ can summarize? 20:18:16 dhellmann: there is no checking, its for documentation generation for when resources and properties are added 20:18:32 stevebaker: ah, ok, good -- so nothing would break? 20:18:35 zaneb: that replacing in one place 2015.2 on 5.0 can raise a lot of errors related with using old version in support statuses 20:18:40 dhellmann: its just a string, but we've likely already added 2015.2 here and there 20:18:42 that's jsut a docs problem AIUI 20:19:01 ok, well, that's good. It still leaves me wondering, who on this team is paying attention to release management this cycle? 20:19:11 me 20:19:14 ok 20:19:30 ok, that's all I needed, thanks! 20:19:36 cool, ok 20:19:46 zaneb: I suppose, that not only doc issue, especially for deprecated stuff. 20:20:17 skraynev_: ok, I didn't know we were that smart about it ;) 20:20:36 skraynev_: but we're never actually parsing version strings, and we likely never should 20:21:05 if you need a schema version, I recommend creating a separate version series and not relying on the software package version number 20:21:07 dhellmann: thank you. sorry for the distraction from work 20:21:33 skraynev_: no problem, I want to make this go as smoothly as possible, so I appreciate you pointing out a potential issue 20:21:40 dhellmann: we have date-based template schema versions 20:21:57 stevebaker: ok, that should do it 20:21:58 stevebaker: right, I want to said, that as you mentioned early we should do s/2015.2/5.0 everywhere and ... 20:22:20 stevebaker: I was not sure, that dhellmann familiar with this 20:23:10 ok, lets move on 20:23:19 stevebaker: so if we do not explain where we also use 2015.2 tag it may be not so obvious to fix it ;) 20:23:39 skraynev_: it should just be in the SupportStatus objects 20:24:24 and the mapping in the doc generation 20:24:26 stevebaker: I suppose, but only we know it... 20:25:12 randallburt: yes 20:25:38 sorry. we want to discuss https://etherpad.openstack.org/p/heat-reviews :) 20:25:41 skraynev_: do you mean we should document somewhere for the users what the version progression is (2015.1->5.0)? 20:25:50 skraynev_: that would be a good idea 20:25:52 grep works 20:26:44 stevebaker: yeap 20:26:47 ok, heat-reviews 20:26:50 #link https://etherpad.openstack.org/p/heat-reviews 20:27:36 stevebaker: I have removed 2 merged patches (one - mine, and another one related with Session client) 20:28:17 skraynev_: regarding the Session client change... 20:29:07 how can we confirm that it doesn't cause a regression with old heat servers, which require passing username and password as well as a token 20:29:30 I mean this change https://review.openstack.org/#/c/163484/ 20:29:39 stevebaker: also for convergence https://review.openstack.org/#/c/191666/1 20:30:15 stevebaker: looking.. 20:31:04 the designate client plugin merged as well 20:31:36 lets talk about convergence reviews 20:33:06 I think that getting them approved quickly so that folk can play with convergence locally is more useful than our usual thorough conservative reviews 20:33:17 since they are on a disabled code path 20:33:26 stevebaker: hm... good question. We can test it manually. 20:34:13 though folks really keen to do it now can just patch with those reviews. not "easy" but doesn't compromise our review integrity ;) 20:34:22 as long as unit test coverage doesn't regress, and the code looks superficially sane, I'm personally happy for it to land. what do other cores think? 20:34:26 stevebaker: plan to review as much as can convergence patches tomorrow 20:34:42 I wouldn't −2 it 20:35:23 anecdotelly, basic create and delete stack is working, update has issues 20:36:13 stevebaker: and silence is consent… I'm not hearing a lot of argument at the moment. 20:36:24 stevebaker: if you merge poor quality code it generally never gets fixed 20:36:33 doh! 20:36:35 stevebaker: I think we may land it, but I personally wanted to really make sure, that last "fixes" fix issues :) 20:36:41 so I'd be more inclined to apply the usual degree of review oversight 20:37:33 (disclaimer: I haven't looked at any of the patches in question) 20:37:42 zaneb: :) 20:38:32 the fact that it's disabled seems less critical to me than the fact that it's code we're going to have to maintain 20:40:19 zaneb: I'm just worried that cores who haven't spent enough time in that code won't understand it enough to review it at all, which will result in no reviews instead of thorough reviews 20:40:50 zaneb: but your point is entirely valid 20:40:53 stevebaker: basically you're saying I'm not doing enough reviews? ;) 20:41:01 Merging it anyway won't change that though 20:42:02 zaneb: I wasn't even remotely implying that :D 20:42:13 why not? 20:42:24 #topic High priority bugs http://bit.ly/1FnhaIK 20:45:33 I wonder if we could justify backporting a fix to https://bugs.launchpad.net/heat/+bug/1464248 ? It would be a REST API addition 20:45:34 Launchpad bug 1464248 in python-heatclient "Cannot list software_configs" [High,Triaged] - Assigned to lvdongbing (dbcocle) 20:46:34 what is the cause? 20:46:34 stevebaker: I think it should be backported 20:46:47 the API is flat out missing? 20:47:30 * stevebaker runs away in shame 20:48:50 lol 20:50:27 also, if anyone feels inclined to urgently work on comment #6 for https://bugs.launchpad.net/heat/+bug/1239972 20:50:28 Launchpad bug 1239972 in heat "Restriction on the name of physical-resource-name size" [High,In progress] - Assigned to Limor Stotland (limor-bortman) 20:52:29 #topic Open Discussion 20:53:35 I still have not reached a consensus with shardy on https://review.openstack.org/#/c/183506/ 20:54:05 so it would be great to have extra eyes on spec 20:55:43 ochuprykov: converging the interfaces of ASG and RG is definitely desirable 20:57:02 stevebaker: in short, 2 problems with extracting common functionality between rg and asg regarding rolling_update 20:57:26 stevebaker: and I suppose deprecating one of resource in the happy future 20:57:54 stevebaker: 1)rolling_update updates only existing instanves 2)asg and rg have different naming conventions and deletion policies 20:59:33 stevebaker: this leads to ugly common functions with if-else logic dependent on action we do 21:00:45 so my thought is to add desired functionality to rg and then make a refactoring, with deprecation of one from asg and rg 21:00:50 stevebaker: just about done? 21:01:00 notmyname: arg, sorry 21:01:03 #endmeeting