07:00:22 <stevebaker> #startmeeting heat
07:00:23 <openstack> Meeting started Wed Jun 24 07:00:22 2015 UTC and is due to finish in 60 minutes.  The chair is stevebaker. Information about MeetBot at http://wiki.debian.org/MeetBot.
07:00:24 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
07:00:26 <openstack> The meeting name has been set to 'heat'
07:00:28 <stevebaker> #topic rollcall
07:00:34 <sirushti> o/
07:00:36 <xek> o/
07:00:57 <Qiming> o/
07:00:58 <ramishra> hi
07:00:59 <inc0> o/
07:01:16 <skraynev> 0/
07:01:18 <tspatzier> hi
07:01:19 <KanagarajM> Hi
07:01:49 <stevebaker> #topic Adding items to agenda
07:01:55 <stevebaker> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda#Agenda_.282015-06-24_2000_UTC.29
07:03:05 <stevebaker> anything else?
07:03:15 <stevebaker> #topic heat reviews https://etherpad.openstack.org/p/heat-reviews
07:03:16 <inc0> oslo.versionedobjects?
07:03:38 <stevebaker> inc0: sure, but zane isn't here to argue with you ;)
07:04:04 <inc0> that's why do it now:>
07:04:05 <inc0> ;)
07:04:14 <KanagarajM> enabling convergence?
07:04:31 <stevebaker> KanagarajM: sure
07:05:13 <stevebaker> so quickly going through https://etherpad.openstack.org/p/heat-reviews
07:05:20 <stevebaker> Fixes for priority bugs
07:05:39 <KanagarajM> here, for https://review.openstack.org/181880, i added an notes
07:06:04 <KanagarajM> would like to get opinion on using the tag.
07:07:36 <stevebaker> KanagarajM: it is valid to abandon without an export. is export mandatory?
07:08:08 <KanagarajM> stevebaker: yes, it could be an user choice
07:08:29 <KanagarajM> some suer may want to block the abandon until exported successfuly
07:08:37 <KanagarajM> while others may don't
07:09:09 <KanagarajM> so it will give flexibility to user and by default, we could make them as mandaotry as suggested by zaneb
07:10:08 <stevebaker> how about a stack-abandon --force will allow the user to abandon even if the stack is not in EXPORT_COMPLETE?
07:11:17 <KanagarajM> this should be an good choice over other one, i feel
07:11:59 <KanagarajM> on --force, abandon will be done. if not then ONLY exported stack would be allowed to abandon
07:12:09 <stevebaker> yes
07:12:27 <KanagarajM> sure. thanks stevebaker.
07:15:43 <KanagarajM> stevebaker: I tried to put the review url in the heat-review, for those L1 items
07:15:49 <ramishra> Is there any reason we want export to be part of the default 'abandon' flow? why can't they be separate workflows altogether? you can combine them if you want(one after the other) as suggested by jason?
07:16:18 <KanagarajM> ramishra: its like this only, its seprated now
07:16:48 <KanagarajM> and there was a comment on how to make the choice on abandon.
07:18:08 <stevebaker> lol, I was talking in the wrong room
07:18:15 * stevebaker is a bit tired
07:19:00 <stevebaker> so the current convergence series seems to start here https://review.openstack.org/#/c/193926
07:19:08 <stevebaker> anything else convergence related which isn't in that series?
07:19:38 <KanagarajM> https://review.openstack.org/#/c/194952/2
07:19:40 <ananta_> stevebaker: few are there
07:19:46 <KanagarajM> i mean starts at https://review.openstack.org/#/c/194952/2
07:20:04 <asalkeld> o/
07:20:55 <ananta_> stevebaker: some more would come
07:21:12 <ananta_> I can put the consolidated list in the etherpad
07:21:32 <stevebaker> ananta_: yes, feel free to just keep it up to date
07:21:47 <stevebaker> #topic High priority bugs http://bit.ly/1FnhaIK
07:22:02 <stevebaker> therve: are you about? https://bugs.launchpad.net/heat/+bug/1468025
07:22:03 <openstack> Launchpad bug 1468025 in heat "Implement encryption using the cryptography module" [High,New] - Assigned to Thomas Herve (therve)
07:24:20 <stevebaker> does that bug imply that switching to the cryptography module means changing encryption algorithms?
07:24:47 <stevebaker> I'll mark it as medium rather than high
07:25:15 <stevebaker> #topic liberty-1 milestone
07:25:50 <stevebaker> l-1 will hopefully be tagged in a few hours, however the gate is broken
07:26:02 <inc0> how surprising
07:26:11 <inc0> was there any release without gate problems?
07:26:20 <stevebaker> we're in good shape, https://launchpad.net/heat/+milestone/liberty-1
07:26:37 <asalkeld> inc0: gate should be ok after this: https://review.openstack.org/#/c/194873/
07:26:48 <stevebaker> but I wanted to make https://bugs.launchpad.net/bugs/1459837 a blocker for tagging
07:26:49 <openstack> Launchpad bug 1459837 in heat "Error messages from nested stacks are awful" [High,In progress] - Assigned to Angus Salkeld (asalkeld)
07:26:58 <asalkeld> need gate working ...
07:27:26 <asalkeld> can we get tripelo guys to commit the dependant patch?
07:27:42 <asalkeld> this one https://review.openstack.org/#q,Iaeaf5affd55e6b6ea98dc65fb64b997aa6565f6d,n,z
07:27:48 <skraynev> asalkeld: we discussed it yesterday with Kairat, he said, that you need just rebase your patch
07:28:07 <asalkeld> skraynev: yeah i did
07:28:14 <stevebaker> so can cores please nurse https://review.openstack.org/#/c/194873/ and https://review.openstack.org/#/c/188228/ through the gate?
07:28:34 <asalkeld> stevebaker: +1
07:28:42 <asalkeld> it should go through
07:28:54 <asalkeld> Robert's patch just got merged
07:29:02 <stevebaker> asalkeld: are you sure? that Depends-On didn't seem to do anything
07:29:26 <stevebaker> there may need to be an os-apply-config release too, the current release expects old pbr
07:29:55 <asalkeld> stevebaker: i mean we can at least hope for a passing tripleo test
07:29:55 <stevebaker> #topic Remove Fn::Select for Liberty HOT? (shardy)
07:30:25 <ttx> stevebaker: i'll keep an eye on those and tag if they ever merge
07:30:26 <stevebaker> I don't think shardy is here
07:30:46 <stevebaker> ttx: thanks, btw we'd like to block on https://bugs.launchpad.net/bugs/1459837 :)
07:30:47 <openstack> Launchpad bug 1459837 in heat "Error messages from nested stacks are awful" [High,In progress] - Assigned to Angus Salkeld (asalkeld)
07:31:13 <ttx> noted!
07:31:14 <stevebaker> I'm +1 on removing Fn::Select
07:31:55 <asalkeld> stevebaker: is it getting replaced with something?
07:32:13 <asalkeld> besides get_attr
07:32:29 <skraynev> +1 for removing Fn::Select
07:32:42 <stevebaker> does get_param do the same thing as get_attr? I can't recall. If so there seems zero need for Fn::Select
07:33:24 <asalkeld> stevebaker: do we have a native version of select?
07:34:05 <stevebaker> asalkeld: get_attr/get_param with extra arguments was always meant to be the native version
07:34:09 <asalkeld> seems like we should have some replacement
07:34:49 <asalkeld> really?
07:35:22 <asalkeld> ok, well not super opinionated about it
07:35:41 <stevebaker> yes, the only thing in heat which can produce dicts or lists are attributes and params
07:36:14 <stevebaker> I've just checked, get_param supports extra attributes
07:37:23 <KanagarajM> a diff i could see is: Select allow to pass index and list/dict as input with out considering the input nature whether its param/attribute
07:37:23 <asalkeld> btw tripleo gate still not working
07:37:50 <shardy> morning all, sorry meeting time mixup
07:37:58 <tspatzier> I think the new str_split function shardy has spec-ed is the final bit for the replacement
07:38:04 <tspatzier> so I think we can remove Select
07:38:12 <stevebaker> KanagarajM: but it would need a new template version, so they'll have to adapt their template
07:38:16 <stevebaker> KanagarajM: ...anyway
07:38:45 <stevebaker> yep, +1 on str_split too
07:39:07 <shardy> 2015-06-24 2000 UTC
07:39:14 * shardy drinks coffee and is confused
07:39:14 <stevebaker> #link https://review.openstack.org/#/c/194171/
07:39:41 <shardy> Ok so I have patches which bump HOT version, remove Fn::Select and adds str_split ready to push
07:39:53 <shardy> is the consensus to push those?
07:40:32 <asalkeld> yeah
07:40:33 <stevebaker> shardy: ah, I see what happened
07:40:35 <stevebaker> Agenda (2015-06-17 2000 UTC)
07:40:38 <stevebaker> Agenda (2015-06-17 0700 UTC)
07:40:42 <stevebaker> Agenda (2015-06-24 2000 UTC)
07:40:52 <shardy> Aha, there's a dupe!
07:41:05 <shardy> Sorry I didn't notice that when cut/pasting agenda blocks yesterday, my bad
07:41:46 <shardy> Ok thanks all, I'll push the series this morning
07:42:55 <stevebaker> shardy: whew, thought I was loosing grasp of reality there
07:43:10 <shardy> stevebaker: So did I! ;D
07:43:59 * shardy enters time-distorted pre-cafinated pseudo reality
07:44:01 <stevebaker> #topic heat_integrationtests into a new repo
07:44:42 <stevebaker> so one outcome of today's gate breakage is that it is likely time we spun out heat_integrationtests into its own repo
07:45:01 <asalkeld> so the problem is sync'ing the integration requirements.txt
07:45:14 <asalkeld> and that is not done by infra
07:45:18 <asalkeld> and it lags
07:45:21 <stevebaker> it has its own requirements.txt, and its turning into another project within a project, like contrib
07:46:02 <asalkeld> so the lazy way out is to get infra to post changes to our requirements
07:46:11 <asalkeld> so we can still have it in-tree
07:46:26 <shardy> I actually like having them in tree, then you can push a patch, or series with a test which proves a fix
07:46:26 <shardy> But cross-repo Depends-On works now, right?
07:46:26 <shardy> ah, OK
07:46:44 <asalkeld> stevebaker: can we make a setup.cfg and have it in-tree
07:46:49 <stevebaker> shardy: lets assume so for this discussion
07:47:32 <asalkeld> or we just toss this feature (and install everything)
07:48:04 <asalkeld> i kinda like it in-tree
07:48:23 <asalkeld> anyone remember why this was added?
07:48:43 <asalkeld> https://github.com/openstack/heat/commit/f518cfe252721553cca1d31c0980dc7aa4111a64
07:48:49 <stevebaker> at some point (in the post tempest world) people are going to want to validate their heat install by running heat_integrationtests against it
07:49:16 <stevebaker> asalkeld: I'm assuming that was seen as a first step to breaking out into its own repo
07:49:39 <asalkeld> yeah
07:49:41 <shardy> stevebaker: Yeah, I guess that's going to be slightly easier from a separate repo..
07:50:02 <stevebaker> oh well, if someone want to drive this with a spec or somesuch then feel free
07:50:18 <asalkeld> i hope we don't forget reviews and become the new tempest :-O
07:50:22 <stevebaker> #topic enabling convergence
07:50:53 <stevebaker> KanagarajM: go
07:51:04 <KanagarajM> for enabling convergence, shall we go for two gate jobs ?
07:51:19 <KanagarajM> may be one of non-convergence and another for convergence with non-voting.
07:51:24 <stevebaker> KanagarajM: that sounds sensible
07:51:25 <KanagarajM> till we stablish it.
07:51:34 <stevebaker> +1
07:51:34 <asalkeld> KanagarajM: maybe for just heat_integration/functional ? - quicker
07:51:34 <skraynev> asalkeld: :) agree
07:51:37 <shardy> +1
07:52:13 <stevebaker> a check-heat-dsvm-functional-conv-mysql
07:52:40 <asalkeld> so the alternatives are more of these DTM patches
07:52:51 <stevebaker> should we go straight to a non-voting job or start with experimental?
07:52:52 <asalkeld> or an experimental
07:53:08 <shardy> Will we need a way to tag functional tests as convergence only?
07:53:15 <stevebaker> did I see someone got a full successful test run?
07:53:19 <asalkeld> stevebaker: i'd vote for experimental
07:53:20 <shardy> e.g so we can add tests which prove the new features?
07:53:49 <asalkeld> shardy: we just want to first shoot for getting the current stuff working
07:53:55 <shardy> asalkeld: kk
07:54:02 <stevebaker> shardy: we can enable/disable sets of tests with heat_integrationtests.conf
07:54:21 <shardy> stevebaker: Ah, cool, sounds good
07:54:25 <KanagarajM> asalkeld: how the experimental different from non-voting?
07:54:26 <asalkeld> atm it is mostlly tags + adopt  that don't work
07:54:43 <asalkeld> KanagarajM: you have to post a comment "check-experimental"
07:54:51 <asalkeld> in the review to get it to run
07:55:03 <asalkeld> so it's not run by default
07:55:35 <asalkeld> actually i don't mind either way
07:55:51 <asalkeld> experimental or non-voting check
07:56:02 <stevebaker> we may go fairly quickly from experimental to non-voting, lets start with experimental. Who wants to submit the change to project-config?
07:56:34 <stevebaker> #topic versioned objects
07:56:35 <asalkeld> :-) tumble weeds
07:56:39 <stevebaker> inc0: go!
07:56:42 <KanagarajM> stevebaker: will do it
07:56:46 <inc0> soo...we have a prototype
07:57:04 <inc0> not very good example, as we agreed to make only convergence call
07:57:05 <stevebaker> KanagarajM: thanks, add me to the review if you need help
07:57:14 <KanagarajM> stevebaker: sure.
07:57:16 <inc0> and it only uses ID
07:57:40 <inc0> but basic idea is to replace normal rpc serializer with VO
07:57:49 <inc0> and refactor calls to use objects
07:58:08 <inc0> Zane tho challanges whole idea of versioned RPC
07:58:37 <asalkeld> inc0: for us, or as a whole?
07:58:42 <inc0> for us
07:58:52 <asalkeld> i don't see why
07:58:55 <skraynev> stevebaker: I think that I or someone from our guys can upload patch to project config ;)
07:59:04 <stevebaker> yeah, we have no conductor, so we're not nova
07:59:06 <inc0> I humbly disagree because we do have few complicated rpc calls
07:59:12 <skraynev> stevebaker:: oops. I am late ;)
07:59:23 <stevebaker> skraynev: sort it out with KanagarajM ;)
07:59:25 <asalkeld> stevebaker: well we upgrade machine by machine
07:59:46 <skraynev> stevebaker: sure, I think I will help with review then :)
07:59:47 <asalkeld> so check_resource call goes to another engine
07:59:48 <inc0> we can end up with one engine from kilo and one from liberty
07:59:54 <asalkeld> that could be newer/older
08:00:15 <stevebaker> inc0: correct me if I'm wrong, but the types to our arguments are "simple", and the responses are generally "complex"
08:00:55 <inc0> well, we can have pretty complex calls, like stack_create
08:01:01 <stevebaker> any meetings starting now?
08:01:03 <inc0> (if I understand question correctly)
08:01:17 <inc0> we can move to #heat with discussion
08:01:22 <stevebaker> inc0: but the individual arguments to stack_create are simple
08:01:23 <asalkeld> stevebaker: should really move to #heat
08:01:29 <stevebaker> #endmeeting