20:00:13 #startmeeting heat 20:00:13 Meeting started Wed Jul 1 20:00:13 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:14 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:00:17 The meeting name has been set to 'heat' 20:00:35 #topic rollcall 20:00:57 morning o/ 20:01:02 hi 20:01:06 morning everybody :) 20:02:09 zaneb, shardy_, ping? 20:02:23 ohai 20:02:37 #topic Adding items to the agenda 20:02:43 #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-07-01_2000_UTC.29 20:03:03 o/ 20:03:16 \o 20:03:35 would like to talk about Fn:Split alternatives 20:03:49 shardy_: should we talk about resource mapping bp later if we have time? 20:04:18 stevebaker: sure, sounds good 20:04:44 fn::select that is 20:04:53 pas-ha: didn't I just implement that? :P 20:05:28 pas-ha: path based attributes are supposed to to the same 20:05:43 not everywhere, let's discuss it further 20:05:47 e.g select by key or index 20:06:06 Ok cool, lets add it :) 20:06:11 late again, sorry 20:06:17 ok, lets kick off 20:06:17 #topic heat reviews https://etherpad.openstack.org/p/heat-reviews 20:07:50 some of convergance's patches are werged 20:07:57 *merged 20:08:08 zaneb: there was discussion last week that it shouldn't be possible to abandon unless the stack is in EXPORT_COMPLETE state, but there would be a --force option to override that 20:08:37 why? 20:08:49 why what? 20:09:01 hi! 20:09:04 why would there be a --force option? 20:09:44 do you mean why not insiste on EXPORT_COMPLETE in all cases? 20:09:50 yes 20:10:32 bug #1353670 20:10:32 bug 1353670 in heat "Stack Abandon is unsafe" [High,In progress] https://launchpad.net/bugs/1353670 - Assigned to Kanagaraj Manickam (kanagaraj-manickam) 20:10:45 for when you want to abandon and just throw away the data? 20:11:02 resources stuck in ERROR states, stacks wedged in IN_PROGRESS 20:11:30 any reason those couldn't be exported? 20:11:32 or you don't care about the data (you're taking over management of the stack for example and not importing somewhere) 20:12:11 randallburt: requiring you to export first hardly seems like an onerous requirement, even in that case though 20:12:41 to you and me maybe. someone thought it was valuable and I can't see a reason not to provide it. 20:13:28 we could add a step to heatclient that says "Are you sure?" just to cover our bases 20:13:30 requiring export is one thing, but allowing a stack in any *_* state to be forced into an EXPORT_COMPLETE state just so an abandon may or may not be performed doesn't seem right 20:14:11 so, I don't know where EXPORT came from in that discussion 20:14:41 what I suggested was that we keep an abandon command and that it move the stack to the ABANDON_COMPLETE state 20:14:47 whence it could be deleted 20:15:31 +1 20:15:35 but then the waters were muddied in the bug discussion for reasons I never understood 20:15:48 ok, it sounds like we should be reviewing https://review.openstack.org/#/c/181880/ more 20:16:25 yeah, so he is doing export then abandon 20:16:30 which is weird 20:16:37 it should be export then delete 20:17:15 or export should just export data and not have a state associated with it 20:17:18 one or the other 20:17:21 not both 20:17:24 assuming the delete after export doesn't actually delete any resources (I assume with changing the policy) 20:17:45 it could be partly semantics, in that change abandon does the delete, and export is what you're calling abandon 20:17:51 randallburt: right, the idea is that delete would not remove resources when the stack is in ABANDON_COMPLETE state 20:18:01 (physical resources) 20:18:06 should export then change some internal stack attr so that when it is deleted via normal delete actual resource are not? 20:18:13 ok 20:18:38 but then the idea of export+abandon seems clearer to me 20:18:41 stevebaker: it's all semantics, but the current patch appears to implement two conflicting sets of semantics 20:19:20 pas-ha: just check the resource state, if it's abandoned, do nothing 20:19:41 as in "delete for this state does one, for another state does another" is not really clear. why not just call "the other delete" abandon? :) 20:20:21 tbh I'd like to see abandon/adopt killed and redesigned natively for convergence 20:21:11 ++ it's never actually worked in the current implementation anyway 20:21:18 maybe using asalkeld's external resources proposal instead 20:23:17 so on to convergence changes 20:23:27 the reviewer pool is still quite shallow 20:25:19 other than encouraging more core reviews I'm not sure what else can be done. 20:25:30 Are the specs raised by zaneb still accurate? I kinda lost track of some of this work thus have been wary to review it 20:26:18 if there's been a major divergence, it hasn't been discussed on the ML or with me 20:26:30 I think we're towards the end of that spec tree 20:26:32 (it may have been discussed in reviews, I haven't looked at most of them) 20:26:54 stevebaker: did I raise a spec for porting the tests from the simulator? 20:27:12 seems like we're getting close to the point where those would be super useful 20:27:21 yeah 20:27:24 I can't remember 20:27:42 https://blueprints.launchpad.net/heat/+spec/convergence-simulator-tests 20:29:03 * zaneb pats self on back 20:29:17 #link http://specs.openstack.org/openstack/heat-specs/specs/kilo/convergence-simulator-tests.html 20:29:52 The question is whether anyone but you can implement it 20:30:12 speaking of specs, we have lots in review 20:30:26 lol 20:30:36 https://review.openstack.org/#/q/status:open+project:openstack/heat-specs,n,z 20:31:14 therve: it's not a small job, but it honestly shouldn't be that hard 20:31:36 #topic High priority bugs http://bit.ly/1FnhaIK 20:31:57 https://bugs.launchpad.net/heat/+bug/1467965 20:31:57 Launchpad bug 1467965 in heat "test_db_encrypt_decrypt UnicodeDecodeError: 'utf8' codec can't decode " [Critical,Confirmed] - Assigned to Angus Salkeld (asalkeld) 20:32:18 asalkeld merged a fix for ^ but apparently it is still happening 20:32:40 stevebaker, What should we do with spec like https://review.openstack.org/#/c/187447/ 20:32:59 it happens on the test for decoding an invalid password, which randomly explodes 20:33:08 That test is ridiculous though 20:33:17 I have a patch that changes it 20:33:37 (Fernet doesn't support reloading stuff encrypted with a different key) 20:34:40 maybe deleting the test would be best. if they're using the wrong password then UnicodeDecodeErrors are the least of their problems 20:35:47 Well it's only part of the test 20:36:35 therve: have you looked into whether there is a Fernet codec which is completely compatible with our current oslo crypt one? 20:36:52 stevebaker, I haven't, no 20:37:20 that would avoid encryption migration pain if it is possible 20:37:43 stevebaker: I'd think that we could surface a better error than UnicodeDecode 20:37:44 I'd be surprised if that was the case 20:38:54 ryansb: I'm sure we could 20:39:00 #topic new SessionClient (https://review.openstack.org/#/c/163484/) and old servers 20:39:23 stevebaker, you had a question 20:39:28 therve: 187447 is comically lacking in any actual analysis or content 20:39:57 about compatibility old seevers and new SessionClient 20:40:05 shardy_, Right. We shouldn't have spec like that. If we consider the change okay with one, let's delete that. 20:40:11 *servers 20:40:50 so, I can answer all your questions about it 20:42:42 shprotby: so a heat server configured for password based deferred auth, or a standalone heat 20:43:12 shprotby: will these sessionclient changes affect that, because heatclient has strong backwards compatibility requirements 20:45:20 is this about keystoneclient sessions? 20:45:22 hm... New sessionclient just don't use any credentials, but logic us the same with old sessionclient 20:45:34 because they aren't coupled to the underlying API versions afaik 20:46:02 it's just a totally different model for the client side code 20:47:14 shardy_: could you take a look at https://review.openstack.org/#/c/163484/ ? 20:47:48 #topic Fn::Select alternatives 20:47:50 stevebaker: sure, will do (probably not till tomorrow tho..) 20:47:59 pas-ha: go 20:48:13 I think we talked about this last week 20:49:02 so, the idea is that we have some functions that returned lists or maps, (like "outputs[_list]" of the asg) 20:49:26 how shoudl one access a single element then? 20:49:44 * pas-ha wasn't there last time, sorry of repeating questions 20:49:46 pas-ha: there is path based selection parameters for get_attr 20:49:57 and my position was that we don't need an alternative to Fn::Select, because all complex data structures are either attributes or parameters, so deep selection is handled by extended get_param and get_attr 20:49:57 the same for get_param 20:49:58 you mean resourse.0 20:50:37 get_attr: [ resource, attribute, 0, foo, bar, 2 ] like that 20:50:40 I also just realized that simple yaql thing asalkeld is trying out might solve this as well :) 20:50:45 we probably need better docs on this.. 20:50:52 yaql thing https://review.openstack.org/#/c/196984/ 20:51:16 btw the template guide is the new hot guide 20:51:24 but yeah, the idea is get_attr/get_param already support getting items by index (list) or key (map) 20:51:25 #link http://docs.openstack.org/developer/heat/template_guide/ 20:51:34 which is the old hot guide ;) 20:51:41 stevebaker: why does the hot_guide keep moving? 20:51:57 every time I link to it it ** breaks! ;) 20:52:14 count my question solved for now 20:52:25 shardy_: it moved into centralised docs but the old one was never deleted, then it moved back because big tent 20:52:26 e.g the one covering composition and software config that was in the user guide 20:52:36 shardy_: http://docs.openstack.org/developer/heat/template_guide/software_deployment.html 20:53:16 stevebaker: Ok, cool thanks 20:53:17 * shardy_ shakes fist at big tent 20:53:21 also http://docs.openstack.org/developer/heat/template_guide/composition.html 20:54:09 stevebaker, Broken link right in there 20:54:19 we might get more heat developers writing doc content now that it is in tree, especially if we -1 changes which lack docs ;) 20:55:12 therve: we probably need to port the hotref handler into our sphinx config 20:55:33 :/ 20:55:47 stevebaker: +1 to having it in tree, but it's a shame the user-facing links have moved around so much (e.g that in the user guide is currently broken) 20:55:48 or just change the link format, since it is an internal link now 20:56:27 yeah, a redirection would have been polite 20:56:37 4 mintues 20:56:48 plenty of time for 20:56:51 #topic resource interfaces 20:56:55 haha 20:57:30 Oh man, shall we tackle this when we have more than 3 minutes? 20:57:40 absolutely 20:57:56 http://docs.openstack.org/user-guide/hot.html 20:58:08 https://review.openstack.org/196656 20:58:11 that sucks ^^ fwiw 20:58:53 why? 20:59:36 stevebaker: because hot guide is a link back to itself, not the actual guide 20:59:48 e.g where all the super-useful info is :) 21:00:10 #endmeeting