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