07:00:18 #startmeeting Heat 07:00:19 Meeting started Wed Dec 9 07:00:18 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:20 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 07:00:23 The meeting name has been set to 'heat' 07:00:29 #topic rollcall 07:00:47 o/ 07:00:52 o/ 07:00:53 \o 07:02:20 shardy, therve, pas-ha 07:03:22 #topic Adding items to agenda 07:03:36 #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-12-09_0700_UTC.29 07:04:03 I hope, that other guys will join later ;) or will read logs :) 07:04:26 Do we have any extra topics for discussion? 07:04:43 https://review.openstack.org/#/c/135492/5 07:04:55 the external resource 07:05:27 need to have more review comment on it 07:05:40 Added 07:05:53 thx 07:06:46 #topic Review priorities 07:06:51 https://etherpad.openstack.org/p/heat-reviews 07:06:54 #link https://etherpad.openstack.org/p/heat-reviews 07:07:33 o/ 07:09:16 shardy: hi 07:09:33 hey skraynev, sorry I'm late 07:10:00 O/ 07:10:56 shardy: np, you are not the alone in it ;) 07:11:06 hi 07:11:19 Re review priorities, I wanted to highlight https://review.openstack.org/#/c/253074/ 07:11:28 ramishra: I have removed SubnetPool from review list etherpad 07:11:36 that's for update restrict, a spec we merged in kilo and ramishra_ is now working on 07:11:44 I suppose, it's really close to be merged 07:11:54 skraynev: sure 07:12:04 zaneb has now voiced some concerns on the (already merged) spec https://review.openstack.org/#/c/135444/ 07:12:13 More views on that would be good 07:12:34 personally I think it's very bad that we're now blocking a spec which took *7 months* to land 07:13:06 it's a strong demotivator for folks to bother at all with specs if they take months to land and aren't reviewed my many cores (who may then block the implementation) 07:14:55 We do have discussion about move these specs to other folder 07:15:05 shardy: agree, but may be also case, when some spec already obsolete due to some new changes.. 07:15:27 skraynev: sure, but that isn't the case here, some folks just didn't review it and now don't like the interfaces 07:16:13 skraynev: perhaps we need a process (as ricolin is referring to) that enables us to remove obsolete specs, and maintain those which remain valid 07:16:18 ricolin: move all incomplete. I remember about it and sent mail with plan of this work. I hope, that will do it during this week 07:16:49 skraynev: sure 07:17:25 skraynev: to clarify, was the decision to move all incomplete ones into specs/mitaka 07:17:28 ? 07:17:39 skraynev: I agree we need to clean the obsloete specs 07:18:07 shardy: hm. do you mean some regular process? like 1 meeting in months or rare, and re-review some old specs... 07:18:10 shardy: I assume the alternative suggested is to make update-preview more robust, right? The user should know what he/she is doing? 07:18:35 ramishra_: well update preview doesn't really work at all atm, I'm working on fixing it 07:18:56 it doesn't work for anything involving nested stacks, or any replacements associated with changes of resource type 07:19:27 shardy: something similar more details here: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080490.html 07:19:31 #link http://lists.openstack.org/pipermail/openstack-dev/2015-November/080490.html 07:20:16 skraynev: thanks - so we can probably drop all obsolete specs as part of the "move all not implemented" patch? 07:20:26 e.g work that out via the review 07:20:46 and then perhaps review all obsolete specs after feature freeze each release 07:21:07 or, whenever someone notices something is no longer valid, they can propose a patch to remove the spec 07:21:28 shardy: yeah, I saw you raised some bugs on that, but wanted to know if that's the suggestion. or there is more to it? 07:22:08 ramishra_: I need to discuss with zaneb but AFAICT yes, the suggestion is force the users to always implement an external to heat workflow around stack update --dry-run 07:22:12 shardy: I prefer one common scope for all specs. Btw ... Need to think how better mark them as not implemented 07:22:39 common scope+1 07:22:50 shrady: about total removing - I think ,that the right way - update it with HUGE topic - it was "removed" due to. 07:23:16 check out how Ironic specs repo is layed out, they have "backlog" folder 07:23:18 shrady: so if someone take a look on it, he will see, the original spec with this mark 07:23:45 like ideas that are not going to be worked on right now 07:23:59 pas-ha: ok. thx. 07:24:21 pas-ha, shardy: could you leave comments and your suggestions in mail thread mentioned above 07:24:32 ok, will do 07:24:52 I will combine them and then upload patches for spec repo. 07:24:58 ok. let' got to the next 07:25:18 skraynev: the linked blueprint should show the implementation status 07:25:18 ramishra_: which is fine, but it's not at all what the spec proposed, and it's not declaring immutability as a property of the resource in the heat model 07:25:24 skraynev: one possibility would be to have all incomplete specs in heat/specs/foo.rst, then move them into specs/mitaka when they are complete 07:25:57 then we'd have a pool of incomplete specs not linked to a release, but maintain an easy place for folks to look and see what was implemented for a particular release 07:26:07 btw, there's an effort to ditch LP blueprints completely and replace it with RFE "Wishlist" bugs 07:26:13 #topic: Reno notes 07:26:46 pas-ha: interesting - some folks will find that odd, given that "wishlist" has traditionally meant "super low priority" 07:26:59 mostly complete 07:27:08 only this one left https://review.openstack.org/#/c/249747/ 07:27:55 shardy, that's to replace blueprints, a usual spec is still required. and tagging with "rfe" helps sort these out 07:28:30 pas-ha: ack, makes sense I guess 07:28:48 pas-ha: specs are useful for new features, irrespective of their priority. Though you can put all the details in the bug description. 07:29:30 neutron has a page how this process works for them. a bit too fornalized to my taste, we can work out something more relaxed for us 07:30:49 #link: http://docs.openstack.org/project-team-guide/release-management.html#when-to-add-release-notes 07:31:19 I wanted to ask all contributers to add notes for new features in Reno 07:31:33 the process is described here: ^ 07:32:16 so if you have a some really important bug fix, feature, etc - please add notes in the same or follow patch 07:32:25 more of a suggestion for cores - when you see something falling to these ^^ w/o reno note - do not merge it 07:32:51 pas-ha: personally I'm starting to think something very lightweight for features is a good idea, as quite often specs stall in review for months, until there is code to discuss 07:33:51 gerrit is still a better place for discussion that LP. but I do agree code speaks for itself most of the time 07:34:20 so I am strongly against denying reviews until spec is merged 07:34:28 pas-ha: I'd thought, that specs also need for users... 07:34:58 sure, to document the implementation details for wider audience 07:35:10 pas-ha: +2 for both. 07:35:21 and that's why it is important to make update patches to existing specs when implementation diverged 07:35:27 does anybody have some question about Reno ? 07:35:56 pas-ha: +1 - I'm just feeling pretty negative re the specs process atm, as it can eat a *lot* of time, and not reach conclusion if cores can't agree (or even if one person doesn't like the idea) 07:36:21 anyway, not a discussion for now, I may start a "is our spec process broken" ML thread ;) 07:36:27 as I understand it will be necessarily from M2 ... so will be good to start try it right now :) 07:37:24 +1, and also reviewers expect pseudo code in the spec;) 07:37:36 shardy: +1. yeah. and then we will add notes about new process to wiki :) 07:37:38 ramishra_, so true :) 07:37:59 and Python *is* almost pseudo-code 07:38:19 ramishra_: +1, that's why I think less detail is probably better 07:38:54 ok. last reminder about Reno, I will start add -1 if will be sure, that note needs for some patch. 07:39:15 #topic Applying new tags for project 07:39:45 I just got mail from ttx about new tags, which I forgot to add :) 07:40:03 so wanted to get confirm from you guys about it 07:40:08 http://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html 07:40:14 and 07:40:17 #link http://governance.openstack.org/reference/tags/assert_supports-upgrade.html 07:40:23 #link http://governance.openstack.org/reference/tags/assert_follows-standard-deprecation.html 07:41:08 this two tags, as I understand Heat already follow requirement in tag's descriptions, so we may apply both 07:41:24 one more about rolling updates 07:41:27 #link http://governance.openstack.org/reference/tags/assert_supports-rolling-upgrade.html 07:41:39 I am not sure, that we has it in Heat ^ 07:41:48 so your thoughts ? 07:42:29 first two IMO we definitely comply 07:43:03 third (rolling) imo too - can we already talk to old DB and old engines? 07:43:25 pas-ha: we don't document the dance with RPC pins etc like nova does though 07:43:27 what's the status of nova-style objects work 07:43:33 If you need clarification on what that entails, you can ask dansmith 07:43:39 pas-ha: also, it's completely un-tested 07:43:52 yeah, that's enother issue 07:44:05 and I am not even sure if it is possible to test on gates 07:44:46 so IMO we can't assert the tag until it's tested (like nova) in CI 07:44:46 the versioned objects part of the DB problably works, but I'm less sure about the RPC part 07:45:16 ttx: ok. sure :) p.s. thx for reminder, I had plan to add deprecation tag in my long TODO list, but it was not close for starting ;) 07:45:52 can grenade be configured to make a three step upgrade? test->API->test->engine->test->DB->test 07:46:05 shardy: do you talk about rolling updates or upgrades? Also as I understand you agree with deprecation 07:46:23 upgrades 07:47:24 pas-ha: hm. I am not sure, that we have some already existing examples of such process... 07:47:45 pas-ha: but we may be a explorers 07:47:54 skraynev: the one I'm not sure about is the full rolling upgrade capability like nova has 07:47:57 well, that's what ops in a big enough (or any) productino would do AFAIU 07:47:58 and try to write these bash scripts 07:48:18 I don't think we can do that, when you have mismatched DB and RPC versions, with API and engine services on different boxes 07:48:38 than we need to fix it :) 07:48:52 pas-ha: all services except nova need to fix it ;) 07:49:09 shardy: lol. it's true 07:49:33 lol 07:49:35 shardy: also swift has such abilities 07:49:45 according documentation 07:49:57 #shardy: http://governance.openstack.org/reference/tags/assert_supports-rolling-upgrade.html#application-to-current-projects 07:50:36 skraynev: interesting, thanks 07:50:41 pas-ha: about simple supports-upgrade tag : do you agree ? 07:50:42 did we implement versioned objects completely? other day I saw number of unused exceptions merged as part of the first patch for that blueprint and still unused. 07:50:54 skraynev, I do 07:50:56 or it's the same situation like for rolling upgrade? 07:51:08 we have grenade job running and voting 07:51:10 ok. so I will add two tags for Heat 07:51:14 cool! 07:51:31 10 mins left 07:51:35 oh 07:51:39 #topic fixing heat-templates dsvm gate 07:51:45 and have lots of dance around deprecated stuff 07:51:49 this is short one 07:52:04 pas-ha: As I see you added link on related patches for priority review list 07:52:11 one is alomost ready (-2 on weird pep8 error in.egg ?!) 07:52:18 and looks like one patch require fix for pep8 job 07:52:30 yeah 07:52:34 second one is in project-config - please weigh in 07:52:40 https://review.openstack.org/#/c/252523/ 07:52:58 that's all for now, the fate of the third patch is still discussed :) 07:53:32 pas-ha: so the second patch means using post-hook placed in heat=-templates repo, right? 07:53:38 yes 07:53:48 pas-ha: ok. got it will review 07:53:54 first one creates it, second one starts to actually use it 07:54:10 #topic: move Heat to devstack plugin? 07:54:20 this is again about more control :) 07:54:36 since Heat is no longer installed by default in DevStack 07:54:53 I think we can consider moving to be a devstack plugin 07:55:17 all the code for devstack integration would live in our repo - moar control for us :) 07:55:36 #link http://docs.openstack.org/developer/devstack/plugins.html 07:55:52 pas-ha: do you want to do it or we need volunteers ? 07:56:09 pas-ha: p.s. I agree with this idea 07:56:19 first probably a vote in ML if people agree to that 07:56:42 I might volunteer myself :) 07:56:45 pas-ha: ok. just send it and I will +1 :) 07:56:53 pas-ha: awesome 07:57:02 ok, cool, will take on it 07:57:18 #topic: Support Conditions 07:57:31 it's from previous meeting... 07:57:51 Re devstack, if we do move it, can we please ensure https://review.openstack.org/#/c/254755/ lands first 07:57:58 also, reviews of that would be good :) 07:58:13 shardy: sure. thx 07:58:15 It fixes our heat.conf to include a trustee and clients_keystone section 07:58:40 there is WIP code for conditions also https://review.openstack.org/#/c/221648/ 07:58:58 about support conditions - I probably will send mail... need to get more opinions 07:59:31 shardy, sure 07:59:39 rpothier: ok. thx 08:00:10 time's up 08:00:13 let's continue in the #heat 08:00:16 rpothier: thanks, looks like that's only for CFN templates, is there a spec for native conditionals? 08:00:16 out of time.. 08:00:16 -> #heat 08:00:19 #endmeeting