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