12:00:26 <asalkeld> #startmeeting heat
12:00:27 <openstack> Meeting started Wed Dec 10 12:00:26 2014 UTC and is due to finish in 60 minutes.  The chair is asalkeld. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:29 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:31 <openstack> The meeting name has been set to 'heat'
12:00:37 <asalkeld> #topic rollcall
12:00:39 <skraynev> o/
12:00:40 <tspatzier> hi
12:00:42 <shardy> o/
12:01:02 <ryansb> o/
12:01:10 <asalkeld> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda
12:02:03 <asalkeld> #topic review last week's actions
12:02:12 <asalkeld> #link http://eavesdrop.openstack.org/meetings/heat/2014/heat.2014-12-03-20.00.html
12:02:29 <asalkeld> skraynev,  take over https://review.openstack.org/#/c/86978/
12:02:35 <asalkeld> that was the only one ^
12:02:51 <asalkeld> say shardy are you around?
12:03:14 <shardy> asalkeld: yup
12:03:21 <skraynev> asalkeld: I starterd working on it
12:03:30 <asalkeld> skraynev, ok
12:03:33 <asalkeld> hi shardy
12:03:51 <asalkeld> #topic Adding items to the agenda
12:04:08 <asalkeld> any more items for the agenda?
12:04:14 <skraynev> and EmilienM already gave me necessary links, so I plan focusing on it all this week
12:04:24 <asalkeld> nice skraynev
12:04:42 <shardy> Thanks skraynev! :)
12:04:43 <pas-ha> o/
12:05:09 <asalkeld> ok, well let's move on and add agenda items as need be
12:05:19 <skraynev> shardy, asalkeld: np, looks interesting for me as research and try to make it work :)
12:05:29 <asalkeld> ok
12:05:37 <asalkeld> #topic kilo-1 status: https://launchpad.net/heat/+milestone/kilo-1
12:05:42 <ckmvishnu> asalkeld: convergence moving forward.
12:06:05 <asalkeld> great, do you want to give us an update?
12:06:24 <asalkeld> (a bit later after the k1 status)
12:06:50 <asalkeld> so i'd like us to go through the bp's
12:06:56 <asalkeld> and see where they are
12:07:11 <pas-ha> that of mine is actually implemented already
12:07:12 <asalkeld> #link https://blueprints.launchpad.net/heat/+spec/decouple-nested
12:07:28 <asalkeld> this is shardy and (now me too)
12:07:34 <skraynev> https://blueprints.launchpad.net/heat/+spec/cinder-volume-type - probably is implemented too
12:07:38 <asalkeld> it's still got a lot of work
12:07:55 <skraynev> it was merged recently
12:08:09 <asalkeld> ok set to implemented
12:08:39 <asalkeld> shardy, i will work on the decouple nested, but will move to k2 in all likely hood
12:08:53 <skraynev> I remember, that Jeff told about this one https://blueprints.launchpad.net/heat/+spec/lazy-load-outputs
12:08:57 <asalkeld> there are a *lot* of tests to sort out
12:09:08 <shardy> asalkeld: Ok, no worries, I know it is a lot of work - thanks for helping move it forward!
12:09:25 <asalkeld> we can still try get the tests in tho'
12:09:31 <asalkeld> no harm in that
12:09:34 <skraynev> asalkeld: +1 for these changes
12:09:50 <shardy> asalkeld: Yeah, I think after the test rework the actual changes should be easy to land
12:10:00 <asalkeld> skraynev, so what's the state of lazy stuff?
12:10:01 <shardy> as all the prerequisites have already been merged
12:10:15 <shardy> e.g the RPC API additions etc
12:10:35 <shardy> Just a shame the test fallout is so horrible :(
12:10:40 <asalkeld> yeah
12:10:50 <shardy> Similar problem for enabling trusts by default..
12:10:53 <skraynev> asalkeld: I do not know! I do not see any related changes with this BP
12:11:18 <asalkeld> last time he said he would be able to get it in
12:11:27 <asalkeld> so maybe it's small
12:11:35 <asalkeld> i'll wait a bit more
12:11:49 <asalkeld> multi region
12:11:59 <tspatzier> that is close to completion IMO
12:12:08 <asalkeld> #link https://blueprints.launchpad.net/heat/+spec/multi-region-support
12:12:23 <asalkeld> should be in, mostly nit picks on the review
12:12:43 <skraynev> asalkeld: ok, imo it's ok wait it till next meeting
12:12:57 <asalkeld> #link https://blueprints.launchpad.net/heat/+spec/stack-snapshot
12:13:09 <asalkeld> that  is therve's
12:13:24 <asalkeld> i think it is largely done
12:13:34 <asalkeld> anyone have more news on it?
12:13:54 <skraynev> suggest to ask therve about it ....
12:14:04 <asalkeld> yeah
12:14:26 <asalkeld> #action skraynev to ask therve about the status of https://blueprints.launchpad.net/heat/+spec/stack-snapshot
12:14:29 <asalkeld> ;)
12:14:47 <asalkeld> skraynev, you just more on his tz
12:14:48 <skraynev> lol
12:14:49 <pas-ha> looks like there is no open reviews for that bp, all is merged (one abandoned)
12:14:54 <skraynev> ok
12:15:22 <asalkeld> so last one:
12:15:27 <asalkeld> #link https://blueprints.launchpad.net/heat/+spec/implement-instanceid-for-launchconfiguration
12:16:14 <asalkeld> mmmm spec still not approved
12:17:09 <asalkeld> well code is there
12:17:13 <shardy> asalkeld: https://review.openstack.org/#/c/132627/
12:17:20 <shardy> Looks like it is approved and merged?
12:17:21 <asalkeld> can we all review that please
12:17:22 <shardy> (the spec)
12:17:53 <asalkeld> shardy, that's the launch config one
12:18:29 <asalkeld> o, sorry - it's confusing as there is a asg and lc spec
12:18:34 <shardy> asalkeld: uh, isn't that what we're talking about, refe the link above?
12:18:46 <shardy> ah
12:18:57 <asalkeld> ok, that should be ok
12:19:20 <asalkeld> and bugs look ok to me
12:19:26 <asalkeld> in progress
12:19:31 <asalkeld> and someone assigned
12:20:17 <asalkeld> ckmvishnu, you want to give a convergence update?
12:20:27 <ckmvishnu> addressing few issues raised by zaneb. looking forward to your suggession. Also have another etherpad https://etherpad.openstack.org/p/execution-stream-and-aggregator-based-convergence. It has more similarities with zanes approach.
12:20:30 <asalkeld> #topic  convergence update
12:20:48 <ckmvishnu> Shouldn't we be working on continuous observer parallelly?
12:21:09 <inc0> well Zane wants to focus on phase1
12:21:25 <asalkeld> ckmvishnu, if you have people twiddling their fingers
12:21:41 <ckmvishnu> distributing workload is fine. but does it even solve any problem heat has right now
12:22:13 <pas-ha> yes, scalability
12:22:16 <asalkeld> ckmvishnu, yes i does improve scale
12:22:30 <shardy> ckmvishnu: making heat more scalable for HP's usage of TripleO is what started off this whole thing
12:22:31 <inc0> well, it changes scope of statefullness - now its whole stack on one engine, its better to have one resource per engine
12:22:54 <pas-ha> lol how every answer get longer ^)
12:23:21 <asalkeld> yeah, ckmvishnu so, yes it is very helpful
12:23:45 <asalkeld> please persist, we are very keen to get there
12:23:52 <ckmvishnu> shardy: but i guess failure are mostly out of band
12:23:55 <ckmvishnu> asalkeld: sure
12:24:32 <asalkeld> ckmvishnu, do you feel you and zane are merging in on a workable solution?
12:24:46 <ckmvishnu> asalkeld: within this week. yes
12:24:53 <asalkeld> awesome
12:25:18 <asalkeld> #topic open discussion
12:25:26 <asalkeld> free for all ...
12:25:52 <asalkeld> (we can continue with convergence or anything else)
12:25:58 <ckmvishnu> asalkeld: so we are not taking up continuous observer for now.
12:26:15 <asalkeld> ckmvishnu, i am ok with that
12:26:27 <ckmvishnu> one other question relating to db patches
12:26:28 <asalkeld> as long as we can get a good foundation
12:26:32 <ckmvishnu> ok
12:26:54 <asalkeld> ckmvishnu, are those going to be needed as-is?
12:27:01 <ckmvishnu> should we be blocked till zero-downtine comes along
12:27:30 <asalkeld> ckmvishnu, so the graph db patches?
12:27:43 <asalkeld> or the name change ones?
12:27:46 <ckmvishnu> not them. in general
12:28:05 <ckmvishnu> db migrations are put on hold
12:28:17 <asalkeld> o, no we can make changes still
12:28:28 <ckmvishnu> ok
12:28:28 <asalkeld> but only if needed
12:28:32 <ckmvishnu> sure
12:28:40 <asalkeld> inc0 is working on that
12:28:58 <asalkeld> it doesn't look too hard, so hopefully shouldn't be too long
12:29:17 <inc0> versioning you mean? well we didn't get to the fun part yet
12:29:28 <inc0> but as long as we draft api for that
12:29:31 <asalkeld> i spoke too soom ;)
12:29:47 <inc0> you can just put your migration to versioning and it will start to work eventually
12:29:48 <inc0> ;)
12:29:50 <prazumovsky> Hello
12:29:58 <asalkeld> hi prazumovsky
12:30:23 <inc0> right now I'm just implementing object classes which does nothing by themselves
12:30:32 <asalkeld> prazumovsky, we are into open discussion
12:30:57 <prazumovsky> asalkeld, OK
12:31:01 <asalkeld> inc0, looks like a good start to me
12:31:34 <inc0> yeah, and I can't see why ckmvishnu couldn't just implent first versioning along with migration
12:31:54 <inc0> even if those won't do anything yet, once we'll have mechanism we'll make it work
12:32:29 <asalkeld> i have a question about testing if we are done
12:32:38 <asalkeld> shardy, skraynev
12:32:47 <pas-ha> inc0, for me it looks like de-/serialization would be the most fun part
12:33:06 <asalkeld> so we can't create stacks with nested stacks in them in the unit tests anymore
12:33:09 <skraynev> asalkeld: here
12:33:25 <shardy> asalkeld: yup
12:33:32 <inc0> pas-ha, mechanism for that actually, and there will be lot of work if we'd like to implement backward versioning, so based on migrations
12:33:32 <asalkeld> so the question is do we do negitive tests in the functional tests
12:33:48 <asalkeld> so do i need to add a test plugin
12:34:00 <asalkeld> that enables me to fail resources
12:34:01 <inc0> this will be less hard more well....big in terms of amount of code
12:34:35 <shardy> asalkeld: My assumption is that we wouldn't, at least initially
12:34:59 <asalkeld> https://review.openstack.org/#/c/140245/3
12:35:02 <asalkeld> skraynev, ^
12:35:15 <skraynev> shardy: do you suggest to move it on kilo X ?
12:35:43 <asalkeld> so one option is to do lots of unit tests
12:35:48 <skraynev> asalkeld: ok, I have got answer :)
12:36:04 <asalkeld> but it does not always test something logically
12:36:34 <shardy> asalkeld: tempest has a negative test framework, I suppose we could look into using that?
12:36:35 <asalkeld> unit tests are sometimes rather dumb
12:37:06 <asalkeld> shardy, i need to create a python resource type
12:37:17 <asalkeld> that fails on create/update
12:37:22 <asalkeld> but not on validate
12:37:25 <skraynev> asalkeld: I have updated my score on review with comment about negative functional testing :)
12:37:33 <shardy> http://docs.openstack.org/developer/tempest/HACKING.html#negative-tests
12:37:40 <asalkeld> i can't do that with a template
12:38:10 <asalkeld> shardy, i'll look into that
12:38:27 <shardy> asalkeld: provider resource with a WaitCondition set to a tiny timeout?
12:38:41 <pas-ha> asalkeld, you mean that our validation is so good already? :)
12:38:47 <asalkeld> lol
12:38:52 <asalkeld> shardy, maybe
12:39:01 <skraynev> :D
12:39:15 <asalkeld> shardy, i don't want to make an actual server
12:39:26 <asalkeld> but that's ok, that might work
12:39:27 <shardy> asalkeld: You wouldn't have to
12:39:39 <asalkeld> i already have a fake server
12:40:01 <pas-ha> yes, just a waiccondition immediately going to fail upon creation
12:40:12 <asalkeld> ok - that will help, but i see a need for this kind of thing in the near future
12:40:30 <asalkeld> (testing resource type, that can fail as we want)
12:40:52 <skraynev> asalkeld: sounds good
12:40:54 <asalkeld> ok, i am all done
12:41:11 <pas-ha> I would presume a resource that just raises whatever failure in hande_* we need
12:41:21 <pas-ha> could be very-very dumb
12:41:34 <pas-ha> almost like a random string
12:41:42 <shardy> pas-ha: Yeah, a way to insert a special test plugin would probably work
12:41:44 <asalkeld> pas-ha, yeah - but maybe with properties (fail in 5 sec)
12:42:13 <pas-ha> cooler - a property defining in which handle_* to fail ;)
12:42:39 <asalkeld> yeah, after x calls to *_complete etc...
12:42:56 <skraynev> pas-ha: and then introduce it as one of common resource :)
12:43:08 <pas-ha> skraynev, lol
12:43:16 <asalkeld> i can live with the wait cond. for now
12:43:40 <pas-ha> OS::Test::UniversalFailure
12:44:10 <shardy> We could have heat_integrationtests/test_resources which are added to plugin_dirs only for the functional test job?
12:44:10 <asalkeld> OS::Test::RandomFailure
12:44:18 <shardy> lol
12:44:33 <skraynev> :)
12:44:42 <asalkeld> shardy, yeah i made that dir a moment ago
12:44:52 <shardy> asalkeld: ah, cool
12:44:54 <asalkeld> but need to tell devstack to set that up
12:45:03 <shardy> I'm not sure how we wire that in, but stevebaker will know
12:45:10 <asalkeld> yeah
12:45:56 <asalkeld> any votes for endmeeting?
12:46:01 <shardy> add HEAT_PLUGIN_DIRS to lib/heat in devstack I guess
12:46:03 <shardy> +1
12:46:07 <skraynev> +1
12:46:10 <pas-ha> +1
12:46:12 <ryansb> +1
12:46:15 <asalkeld> #endmeeting