12:00:13 <asalkeld> #startmeeting heat
12:00:14 <openstack> Meeting started Wed Jan 21 12:00:13 2015 UTC and is due to finish in 60 minutes.  The chair is asalkeld. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
12:00:18 <openstack> The meeting name has been set to 'heat'
12:01:22 <asalkeld> anyone about?
12:01:39 <asalkeld> #link https://wiki.openstack.org/wiki/Meetings/HeatAgenda
12:01:51 <zaneb> o/
12:02:07 <ryansb> \p
12:02:13 <ryansb> \o
12:02:29 <skraynev> o/
12:03:08 <asalkeld> i'll wait a bit, small crowd
12:03:30 <BillArnold> hi
12:03:54 <skraynev> asalkeld: sigh
12:03:59 <pas-ha> o/
12:04:26 <asalkeld> #topic  Review action items from last meeting
12:04:40 <zaneb> ananta: about?
12:04:55 <ananta> Hi
12:05:16 <zaneb> excellent
12:05:18 <asalkeld> there was one old action for me to email re: meetup
12:05:31 <asalkeld> still not done, not sure if it is needed tho'
12:05:52 <asalkeld> anyway moving on...
12:05:57 <asalkeld> #topic Adding items to the agenda
12:06:24 <asalkeld> zaneb, more convergence discussion at the end?
12:06:31 <zaneb> yes please
12:06:38 <asalkeld> k
12:06:52 <asalkeld> #topic Remove deprecation properties
12:07:00 <asalkeld> skraynev I assume ^
12:07:17 <skraynev> sure, Just want collect more feedback about this email topic http://lists.openstack.org/pipermail/openstack-dev/2015-January/054645.html
12:07:46 <skraynev> asalkeld and shrady already answered, so other opinions are welcome
12:07:59 <asalkeld> skraynev, so given that these templates are stored
12:08:08 <skraynev> s/shrady/shardy
12:08:13 <asalkeld> it is really tricky to truely remove
12:08:48 <zaneb> I agree with asalkeld's mail
12:08:50 <asalkeld> unless it can be dynamically converted
12:08:52 <skraynev> I had a suggestion about how to make it "short"
12:09:01 <zaneb> I don't see how we can ever ditch this stuff completely
12:09:58 <pas-ha> could we forbid only stack creation with some properties, but still support update/delete?
12:10:21 <asalkeld> pas-ha, maybe?
12:10:41 <asalkeld> it's going to get messy
12:10:51 <ryansb> I feel like that would be really annoying for users who (say) clean migrated to a new openstack installation
12:10:54 <skraynev> pas-ha: and preview and template validate too, I suppose
12:11:31 <pas-ha> skraynev, yes, only those that assme some non-existing-yet stack
12:11:33 <zaneb> pas-ha: I think if you put the check in the validate() call, then it will have that effect
12:11:50 <asalkeld> skraynev, there is no easy answer here other than come up with a really clever idea and sell it to us
12:11:52 <zaneb> that is, Resource.validate()
12:12:00 <pas-ha> validate is also done on update, no?
12:12:09 <asalkeld> yes it is
12:12:18 <zaneb> pas-ha: we don't validate the old one on update, only the new one
12:12:30 <zaneb> at least, we shouldn't
12:12:33 <asalkeld> zaneb, rollback?
12:12:48 <pas-ha> aha, so forbid updates that use "deprecated" properties too
12:12:56 <zaneb> asalkeld: I don't think so
12:12:57 <asalkeld> we just grab the old template and update
12:13:16 <zaneb> nothing calls validate as a side effect any more
12:13:33 <zaneb> it's done explicitly by create_stack and validate_template
12:13:41 <asalkeld> ok, that could end up been a problem tho'
12:14:04 <asalkeld> if this exact problem comes up, operator updates
12:14:13 <asalkeld> and property disapears
12:14:25 <skraynev> so how will be look whole deprecation process? 1. we mark it as deprecated, 2. then add migration. 3. what we plan to do after 3 releases after that?
12:14:26 <zaneb> right, it can
12:14:37 <zaneb> right, it can't disappear
12:14:58 <asalkeld> just make it "invisible"
12:15:06 <zaneb> but we can start failing validation on it so that new stacks don't get created with deprecated properties
12:15:06 <pas-ha> so, what do we care exactly about? which upgrade scenario would we enforce/recommend?
12:15:51 <asalkeld> pas-ha, yeah "the how we do this"
12:16:03 <asalkeld> do we do a migrate and how
12:16:13 <asalkeld> etc...
12:16:41 <asalkeld> skraynev, anything more to talk about?
12:16:59 <skraynev> hm..
12:17:16 <skraynev> not sure, that fully understand what we plan to do after 2 releases
12:17:27 <asalkeld> 1. don't ever totally remove properties
12:17:45 <asalkeld> 2. maybe get smart and migrate to new properties
12:17:59 <pas-ha> what if we move "deprecated" to "not supported" after deprecation period? how will it affect at least old stack deletion?
12:18:26 <asalkeld> 3. validate on create (don't allow old properties)
12:18:46 <skraynev> pas-ha: do't think that deletion is a problem case
12:19:04 <skraynev> the most important it's rollback
12:19:20 <asalkeld> 4. don't rename properties unless really needed?
12:19:37 <skraynev> deletion will work independent from properties
12:19:41 <pas-ha> not sure why upgrade when some stacks are IN_PROGRESS
12:19:52 <skraynev> asalkeld: № 4  ++++
12:19:57 <asalkeld> anything controversial there?
12:20:04 <zaneb> skraynev: I believe that's correct
12:20:53 <asalkeld> when resources start looking old, maybe it's better to create a new resource
12:21:09 <skraynev> asalkeld: no. last question: what about my last suggestion to move deprecated property in option of property?
12:21:28 <pas-ha> yay, resource versioning :)
12:21:36 <skraynev> asalkeld: not always....
12:21:54 <asalkeld> reading back
12:22:23 <zaneb> pas-ha: I know randallburt was keen to have that, not sure what's happening with it though
12:22:26 <skraynev> asalkeld: http://lists.openstack.org/pipermail/openstack-dev/2015-January/054739.html
12:22:33 <skraynev> this one ^
12:23:25 <asalkeld> skraynev, yeah that might work
12:23:28 <zaneb> skraynev: I like that and I think you should try implmenting it
12:23:35 <zaneb> it may be harder than you'd hope
12:23:36 <asalkeld> like oslo.config
12:23:52 <pas-ha> zaneb, ok, agree for large deployment you don't want to pause everybody on upgrade in ideal case
12:24:04 <asalkeld> I am going to move on
12:24:12 <asalkeld> #topic kilo-2
12:24:17 <skraynev> zaneb: it's always, only hard ideas :)
12:24:29 <asalkeld> #link https://launchpad.net/heat/+milestone/kilo-2
12:24:51 <asalkeld> jpeeler, lazy loading?
12:24:57 <asalkeld> what's up with that?
12:25:06 <skraynev> asalkeld, zaneb: ok, I will sent email with summarization results :)
12:25:15 <asalkeld> thanks skraynev
12:25:35 <asalkeld> zaneb, you know where jpeeler is with that?
12:25:44 <zaneb> I don't, sorry
12:25:49 <asalkeld> mmm
12:25:55 <zaneb> I suspect he's busy with other stuff
12:26:04 <asalkeld> decouple-nested it going to be tight
12:26:12 <asalkeld> fighting the tests
12:26:29 <asalkeld> nearly rewriten half the tests
12:26:35 <asalkeld> (or feels like it)
12:26:47 <asalkeld> inc0 not here?
12:27:09 <ryansb> doesn't seem so
12:27:13 <asalkeld> ok, i'll follow up with him
12:27:32 <asalkeld> the others don't look risks
12:27:36 <asalkeld> risky
12:27:43 <ryansb> not sure where he's located, but it's 4am on the west coast FWIW
12:27:55 <pas-ha> zaneb, could you take a look at https://review.openstack.org/#/c/147461/ - I suspect that it is not that simple as I've done it, most probably missed smth
12:28:18 <pas-ha> that is about bug 1384750
12:28:35 <zaneb> pas-ha: ok, I'll take a look
12:28:40 <asalkeld> ok we have a bout 10 days until kilo-2
12:28:42 <pas-ha> zaneb, thnx
12:28:53 <asalkeld> so review things for k2 please
12:29:00 <asalkeld> (try to focus on them)
12:29:08 <asalkeld> i'll move on
12:29:13 <asalkeld> #topic convergence
12:29:20 <asalkeld> zaneb, ananta ..
12:29:41 <ananta> zaneb: please proceed
12:29:44 <skraynev> it's show time :)
12:29:45 <zaneb> so I posted to the ML a couple of days ago
12:29:53 <asalkeld> i saw
12:30:00 <asalkeld> nice so lets get stuck in
12:30:09 <zaneb> with an updated branch that is, I think, pretty close to what ananta is proposing
12:30:28 <ananta> i need to review the code on github... but from the mail I agree to most of it
12:30:40 <zaneb> so ideally I'd like to get code reviews on that and input on anything that's still different
12:30:58 <zaneb> ananta: cool, that's a good sign :)
12:30:59 <ananta> zaneb: sure
12:31:11 <asalkeld> what are the next steps
12:31:19 <asalkeld> who needs to do what
12:31:28 <zaneb> next step I think is to break this down into tasks
12:31:39 <zaneb> maybe create specs/bps?
12:31:45 <zaneb> and assign them to people
12:32:00 <zaneb> I think a bunch of folks are interested in helping
12:32:08 <asalkeld> yes
12:32:23 <zaneb> I'm probably going to be mostly limited to reviewing
12:32:33 <zaneb> other commitments :/
12:32:37 <asalkeld> zaneb, are you and ananta going to try break things down
12:32:42 <asalkeld> into tasks?
12:32:51 <asalkeld> you have your heads in it
12:33:05 <ananta> i will work with zaneb  to break down
12:33:07 <zaneb> my plan was to take a first pass at it and post to the ML for input
12:33:15 <asalkeld> cool
12:33:15 <ananta> into implementable specs and tasks
12:33:27 <zaneb> ananta: did y'all have migration plan in mind?
12:33:32 <asalkeld> after decouple-nested i can help with things
12:33:45 <zaneb> I have the beginnings of one in my head somewhere
12:34:11 <ananta> you mean db migration?
12:34:22 <zaneb> no
12:34:25 <asalkeld> operator migration
12:34:33 <zaneb> not even that
12:34:34 <asalkeld> and stack migration
12:34:56 <zaneb> more like how can we implement this incrementally without having all the code be broken in the meantime
12:35:14 <zaneb> so we don't have to try and land everything on the same day ;)
12:35:29 <ananta> this could be done only after our approach is final :)
12:35:40 <pas-ha> how about implement worker API on the heat-engine itself first
12:35:52 <pas-ha> then start beraking it out to separate workers
12:35:56 <asalkeld> pas-ha, i think that was the plan
12:36:02 <ananta> pas-ha: thats the plan
12:36:06 <ananta> as of now
12:36:09 <zaneb> pas-ha: yeah, the plan is not even to break it out
12:36:41 <asalkeld> the only difference is different thread vs. process
12:37:07 <ananta> zaneb: lwts first break down into impl specs and then on the migration plan
12:37:14 <ananta> s/lwts/lets
12:37:22 <zaneb> I'm thinking that old stacks use the old code and new stacks have a config option, off by default, to create using the new code
12:37:47 <zaneb> unit tests stick with old code until they migrate to functional tests
12:38:06 <ryansb> I could see that as an environment thing
12:38:06 <ananta> good time to introduce versioning for Heat?
12:38:24 <asalkeld> ananta, what versioning?
12:38:31 <asalkeld> this is stack versioning
12:38:46 <asalkeld> we have versioning everywhere it seems
12:39:08 <zaneb> ananta: well, I think the migration plan (maybe that wasn't a good choice of words on my part) very much affects what our list of implementation tasks looks like
12:39:30 <asalkeld> more like code-landing-plan
12:39:44 <zaneb> yes
12:39:49 <zaneb> exactly
12:40:14 <zaneb> I'll take a stab at it over the next couple of days
12:40:31 <asalkeld> zaneb, please lets get cracking with this
12:40:53 <zaneb> yes, my goal is to get out of the critical path asap ;)
12:40:53 <ananta> zaneb: ok... I would like to work on the detailed tasks and then update them with our final plans
12:40:54 <asalkeld> i am concerned we won't get anywhere if we are not careful
12:41:13 <asalkeld> thanks
12:41:36 <asalkeld> if you you guys need help, please let me know
12:42:04 <asalkeld> pas-ha, you are working on removing the task runnner?
12:42:14 <asalkeld> (removing it from resources)
12:42:15 <pas-ha> yes, for pathces up
12:42:32 <pas-ha> but the trickier ones are left - volume and server
12:42:44 <asalkeld> zaneb, i can't remember the exact purpose of that
12:42:52 <asalkeld> can you remind me
12:42:53 <pas-ha> plus I have no idea how to do it with instance group
12:43:16 <asalkeld> do we need to remove functions from the cookie?
12:43:17 <zaneb> asalkeld: it's an enabler for phase 2 of convergence
12:43:28 <zaneb> so not super urgent
12:43:39 <asalkeld> ok
12:43:50 <zaneb> yeah, we need to only include stuff we can serialise in the cookie
12:43:51 <pas-ha> so we could probably retarget the bug
12:44:08 <asalkeld> pas-ha, ^ not wait stuff in the cookie
12:44:37 <pas-ha> so, simple container/dict-like object will do?
12:44:43 <zaneb> yep
12:44:51 <asalkeld> #topic open discussion
12:44:54 <pas-ha> no methods thoug, ok
12:45:28 <asalkeld> zaneb, ananta it would be good to find other tasks like that
12:45:48 <asalkeld> that can be done somewhat independently
12:46:37 <asalkeld> also if any one has heaps of time on their hands, i have work for you:-)
12:46:55 <asalkeld> (working on test rework)
12:47:00 <asalkeld> really fun stuff
12:47:11 <pas-ha> not sure if mutating that handler_data inside check_*_complete is a good thing
12:47:33 <ananta> asalkeld:  unit tests?
12:47:47 <asalkeld> ananta, for decouple-nested
12:48:02 <BillArnold> asalkeld how complete (incomplete) are you find the test coverage to be?
12:48:18 <asalkeld> we need to remove creation of nested stacks in unit tests
12:48:18 <zaneb> pas-ha: why not?
12:48:26 <asalkeld> BillArnold, it's quite good
12:48:40 <asalkeld> the worst is contrib/ and wsgi
12:48:43 <pas-ha> ok then, smth like that https://review.openstack.org/#/c/147953/3/heat/engine/resources/neutron/loadbalancer.py,cm ?
12:50:31 <zaneb> pas-ha: feels weird to have unconditional return in a while loop, but yes, something like that
12:51:24 <pas-ha> oops, will change that, probably wanted to save a couple of calls :)
12:52:28 <zaneb> :)
12:53:09 <asalkeld> https://etherpad.openstack.org/p/heat-unit-test-rework
12:53:15 <asalkeld> i'll work on there
12:53:22 <asalkeld> what needs to be done
12:53:30 <asalkeld> if anyone wants to help
12:53:37 <pas-ha> #link https://etherpad.openstack.org/p/heat-unit-test-rework
12:54:02 <ananta> asalkeld: let me know how I can get started
12:54:13 <asalkeld> ok
12:54:32 <ananta> are those the tests that need to be updated?
12:54:59 <asalkeld> ananta, yeah - put you name against a test
12:55:45 <ananta> asalkeld: ok
12:56:59 <dgonzalez> Hi all, i want to get started with heat development. Is there anything a beginner could do to help with the unit tests?
12:57:25 <asalkeld> ooo, victim
12:57:49 <asalkeld> dgonzalez, i'd suggest run the coverage test
12:58:01 <asalkeld> and see what is missing and add tests for that code
12:58:21 <asalkeld> dgonzalez, i have other work but it's time critical
12:59:03 <asalkeld> 2 mins
12:59:11 <dgonzalez> ok, sounds like a good method to get to know the code base ;-)
12:59:33 <asalkeld> dgonzalez, "tox -ecover"
12:59:58 <asalkeld> then point your browser at heat/cover/index.html
13:00:28 <asalkeld> we are done, thanks
13:00:32 <asalkeld> #endmeeting