20:00:30 <stevebaker> #startmeeting heat
20:00:31 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
20:00:35 <openstack> The meeting name has been set to 'heat'
20:00:38 <stevebaker> #topic rollcal
20:00:44 <tspatzier> hi all
20:00:52 <zaneb> \o
20:00:56 <rpothier> o/
20:01:01 <skraynev_> o//
20:01:02 <lkarm> o/
20:01:22 <stevebaker> skraynev_: 2 left arms?
20:01:47 <skraynev_> stevebaker: take one more, while Pavlo is in vacation :)
20:01:58 <stevebaker> #topic Adding items to agenda
20:02:08 <stevebaker> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-06-17_0700_UTC.29
20:03:45 <stevebaker> #topic 5.0
20:03:50 <randallburt> o/
20:03:55 <dhellmann> o/
20:03:58 <jruano> hi
20:04:00 <tlashchova__> hi
20:04:05 <ochuprykov> hi
20:04:48 <stevebaker> 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 <stevebaker> nothing to discuss really, just a PSA
20:05:15 <skraynev_> stevebaker: instead of 2015.2
20:05:20 <stevebaker> yup
20:05:21 <dhellmann> stevebaker: there is actually a potential issue
20:05:22 <skraynev_> stevebaker: hang on
20:05:35 <skraynev_> stevebaker: yeah , what about our support statuses ?
20:05:43 <skraynev_> for resources
20:05:55 <skraynev_> I suppose, that we should change it every where?
20:06:12 <skraynev_> if we replace 2015.2 on 5.0
20:06:13 <dhellmann> the nova team has some deprecation messages with version numbers that will never appear, too
20:06:38 <stevebaker> skraynev_: old releases remain the same. I guess any 2015.2 we've added recently could be changed to 5.x
20:06:51 <stevebaker> dhellmann: what will l-1 be versioned as?
20:07:26 <skraynev_> stevebaker, dhellmann: so right. you need update all places where you find 2015.2 version :)
20:07:39 <skraynev_> dhellmann: resources and so on
20:07:47 <zaneb> I guess this means a new epoch in all the distro packaging :/
20:07:47 <dhellmann> stevebaker: I think ttx is planning X.0.0b1
20:08:08 <stevebaker> zaneb: yes, epoch will be required
20:08:11 <skraynev_> zaneb: we are so old for this ... :)
20:08:29 <dhellmann> 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 <stevebaker> skraynev_: so s/2015.2/5.0.0/
20:08:47 <skraynev_> dhellmann: ok, I can help you ;)
20:08:52 <dhellmann> skraynev_: great, thank you
20:09:19 <skraynev_> stevebaker: yeah. sure. just want to be sure, that we replace it everywhere
20:09:26 <stevebaker> dhellmann: regarding major numbers, do we have the potential to...
20:09:51 <skraynev_> dhellmann: np, I will upload patchset for it tomorrow
20:10:12 <dhellmann> skraynev_: ok, please add me as a reviewer so I definitely see it
20:10:17 <stevebaker> dhellmann: 1) not increment the major at the M release date if there were no major changes? or
20:10:18 <dhellmann> stevebaker: ?
20:10:30 <stevebaker> dhellmann: 2) increment the major in the middle of a dev cycle
20:10:43 <skraynev_> stevebaker: so in documentation we will see statuses: 2014.2, 2015.1, 5.0, ...
20:11:03 <dhellmann> 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 <skraynev_> stevebaker: I mean for resources support statuses
20:11:13 <dhellmann> and also for now, no on #2, until we see how the experiment with ironic goes
20:11:27 <dhellmann> so possibly next cycle, but not this cycle
20:11:37 <stevebaker> dhellmann: yep, understood
20:12:04 <dhellmann> 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 <stevebaker> it would be anarchy :)
20:12:50 <dhellmann> right, and we're preparing for that future
20:13:03 <dhellmann> not all projects will choose to do that, but many will
20:13:23 <stevebaker> I would assume heat would end up with long-running major numbers if anything
20:13:45 <stevebaker> (after convergence is the default)
20:14:17 <dhellmann> 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 <dhellmann> in addition to the more standard API changes, of course
20:15:08 <stevebaker> yep
20:15:36 <stevebaker> #topic heat reviews https://etherpad.openstack.org/p/heat-reviews
20:15:54 <dhellmann> stevebaker: before we move on, I have one more thing
20:15:58 <stevebaker> sure
20:16:24 <dhellmann> 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 <dhellmann> 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 <dhellmann> normally that's the PTL, but it doesn't have to be
20:17:25 <zaneb> what incompatibility are we talking about?
20:17:47 <dhellmann> 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 <stevebaker> dhellmann: there is no checking, its for documentation generation for when resources and properties are added
20:18:32 <dhellmann> stevebaker: ah, ok, good -- so nothing would break?
20:18:35 <skraynev_> 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 <stevebaker> dhellmann: its just a string, but we've likely already added 2015.2 here and there
20:18:42 <zaneb> that's jsut a docs problem AIUI
20:19:01 <dhellmann> 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 <stevebaker> me
20:19:14 <dhellmann> ok
20:19:30 <dhellmann> ok, that's all I needed, thanks!
20:19:36 <stevebaker> cool, ok
20:19:46 <skraynev_> zaneb: I suppose, that not only doc issue, especially for deprecated stuff.
20:20:17 <zaneb> skraynev_: ok, I didn't know we were that smart about it ;)
20:20:36 <stevebaker> skraynev_: but we're never actually parsing version strings, and we likely never should
20:21:05 <dhellmann> 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 <skraynev_> dhellmann: thank you. sorry for the distraction from work
20:21:33 <dhellmann> 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 <stevebaker> dhellmann: we have date-based template schema versions
20:21:57 <dhellmann> stevebaker: ok, that should do it
20:21:58 <skraynev_> stevebaker: right, I want to said, that as you mentioned early we should do s/2015.2/5.0 everywhere and ...
20:22:20 <skraynev_> stevebaker: I was not sure, that dhellmann familiar with this
20:23:10 <stevebaker> ok, lets move on
20:23:19 <skraynev_> 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 <stevebaker> skraynev_: it should just be in the SupportStatus objects
20:24:24 <randallburt> and the mapping in the doc generation
20:24:26 <skraynev_> stevebaker: I suppose, but only we know it...
20:25:12 <skraynev_> randallburt: yes
20:25:38 <skraynev_> sorry. we want to discuss https://etherpad.openstack.org/p/heat-reviews :)
20:25:41 <stevebaker> skraynev_: do you mean we should document somewhere for the users what the version progression is (2015.1->5.0)?
20:25:50 <stevebaker> skraynev_: that would be a good idea
20:25:52 <zaneb> grep works
20:26:44 <skraynev_> stevebaker: yeap
20:26:47 <stevebaker> ok, heat-reviews
20:26:50 <stevebaker> #link https://etherpad.openstack.org/p/heat-reviews
20:27:36 <skraynev_> stevebaker: I have removed 2 merged patches (one - mine, and another one related with Session client)
20:28:17 <stevebaker> skraynev_: regarding the Session client change...
20:29:07 <stevebaker> 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 <stevebaker> I mean this change https://review.openstack.org/#/c/163484/
20:29:39 <skraynev_> stevebaker: also for convergence https://review.openstack.org/#/c/191666/1
20:30:15 <skraynev_> stevebaker: looking..
20:31:04 <randallburt> the designate client plugin merged as well
20:31:36 <stevebaker> lets talk about convergence reviews
20:33:06 <stevebaker> 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 <stevebaker> since they are on a disabled code path
20:33:26 <skraynev_> stevebaker: hm... good question. We can test it manually.
20:34:13 <randallburt> 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 <stevebaker> 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 <skraynev_> stevebaker: plan to review as much as can convergence patches tomorrow
20:34:42 <randallburt> I wouldn't −2 it
20:35:23 <stevebaker> anecdotelly, basic create and delete stack is working, update has issues
20:36:13 <randallburt> stevebaker:  and silence is consent… I'm not hearing a lot of argument at the moment.
20:36:24 <zaneb> stevebaker: if you merge poor quality code it generally never gets fixed
20:36:33 <randallburt> doh!
20:36:35 <skraynev_> stevebaker: I think we may land it, but I personally wanted to really make sure, that last "fixes" fix issues :)
20:36:41 <zaneb> so I'd be more inclined to apply the usual degree of review oversight
20:37:33 <zaneb> (disclaimer: I haven't looked at any of the patches in question)
20:37:42 <skraynev_> zaneb: :)
20:38:32 <zaneb> 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 <stevebaker> 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 <stevebaker> zaneb: but your point is entirely valid
20:40:53 <zaneb> stevebaker: basically you're saying I'm not doing enough reviews? ;)
20:41:01 <randallburt> Merging it anyway won't change that though
20:42:02 <stevebaker> zaneb: I wasn't even remotely implying that :D
20:42:13 <zaneb> why not?
20:42:24 <stevebaker> #topic High priority bugs http://bit.ly/1FnhaIK
20:45:33 <stevebaker> 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 <openstack> Launchpad bug 1464248 in python-heatclient "Cannot list software_configs" [High,Triaged] - Assigned to lvdongbing (dbcocle)
20:46:34 <zaneb> what is the cause?
20:46:34 <skraynev_> stevebaker: I think it should be backported
20:46:47 <zaneb> the API is flat out missing?
20:47:30 * stevebaker runs away in shame
20:48:50 <zaneb> lol
20:50:27 <stevebaker> also, if anyone feels inclined to urgently work on comment #6 for https://bugs.launchpad.net/heat/+bug/1239972
20:50:28 <openstack> 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 <stevebaker> #topic Open Discussion
20:53:35 <ochuprykov> I still have not reached a consensus with shardy on https://review.openstack.org/#/c/183506/
20:54:05 <ochuprykov> so it would be great to have extra eyes on spec
20:55:43 <stevebaker> ochuprykov: converging the interfaces of ASG and RG is definitely desirable
20:57:02 <ochuprykov> stevebaker: in short, 2 problems with extracting common functionality between rg and asg regarding rolling_update
20:57:26 <skraynev_> stevebaker: and I suppose deprecating one of resource in the happy future
20:57:54 <ochuprykov> stevebaker: 1)rolling_update updates only existing instanves 2)asg and rg have different naming conventions and deletion policies
20:59:33 <ochuprykov> stevebaker: this leads to ugly common functions with if-else logic dependent on action we do
21:00:45 <ochuprykov> 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 <notmyname> stevebaker: just about done?
21:01:00 <stevebaker> notmyname: arg, sorry
21:01:03 <stevebaker> #endmeeting