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