Wednesday, 2014-11-26

*** sjmc7__ has joined #heat00:04
*** tellesnobrega_ has joined #heat00:04
*** zhenzanz has joined #heat00:05
*** zhenzanz_ has joined #heat00:06
*** julienvey has quit IRC00:06
*** sjmc7_ has quit IRC00:07
*** rdo has quit IRC00:08
*** achanda has quit IRC00:08
*** zhenzanz has quit IRC00:09
*** zhenzanz_ is now known as zhenzanz00:09
*** Qiming has joined #heat00:09
*** rdo has joined #heat00:10
*** JayJ has quit IRC00:14
*** Qiming has quit IRC00:18
*** pmallya has quit IRC00:19
*** achanda has joined #heat00:26
*** dims_ has quit IRC00:30
*** achanda has quit IRC00:37
*** alexpilotti has quit IRC00:51
*** sjmc7__ has quit IRC00:54
*** achanda has joined #heat00:57
*** rdo has quit IRC01:02
*** zaneb has quit IRC01:03
*** rdo has joined #heat01:03
*** Qiming has joined #heat01:05
*** gokrokve has quit IRC01:06
*** julienvey has joined #heat01:17
*** sgordon has quit IRC01:20
*** julienvey has quit IRC01:22
*** achanda has quit IRC01:22
*** tellesnobrega_ has quit IRC01:23
*** tellesnobrega_ has joined #heat01:29
*** dimsum__ has joined #heat01:30
*** achanda has joined #heat01:31
*** achanda has quit IRC01:35
*** dimsum__ has quit IRC01:36
*** dimsum__ has joined #heat01:37
*** hdd has joined #heat01:40
*** dimsum__ has quit IRC01:41
openstackgerritMerged openstack/heat: Use correct IDs when collecting multipart config parts  https://review.openstack.org/13690601:42
*** dimsum__ has joined #heat01:53
*** Yanyanhu has joined #heat02:03
*** mc__ has joined #heat02:04
*** serg_melikyan has quit IRC02:07
*** mc__ has quit IRC02:10
*** serg_melikyan has joined #heat02:10
openstackgerritMerged openstack/heat: Fix permission bits for source file.  https://review.openstack.org/13707402:12
*** apporc has joined #heat02:14
*** nosnos has joined #heat02:14
*** mc__ has joined #heat02:14
*** erkules_ has joined #heat02:28
*** serg_melikyan has quit IRC02:30
*** erkules has quit IRC02:30
*** sdake_ has joined #heat02:31
*** sdake_ has quit IRC02:31
*** sdake_ has joined #heat02:31
*** sgordon_ has quit IRC02:32
*** serg_melikyan has joined #heat02:34
openstackgerritEthan Lynn proposed openstack/heat: Fix package name when using heat-db-setup in rhel7  https://review.openstack.org/13676302:36
*** erkules_ is now known as erkules02:36
*** alexheneveld has quit IRC02:46
*** gokrokve has joined #heat02:52
*** gokrokve has quit IRC02:52
*** dimsum__ has quit IRC02:52
*** gokrokve has joined #heat02:52
*** gokrokve has quit IRC02:53
*** gokrokve has joined #heat02:53
*** gokrokve has quit IRC02:54
*** gokrokve has joined #heat02:55
*** gokrokve has quit IRC02:59
*** ramishra has joined #heat02:59
*** gokrokve has joined #heat02:59
*** gokrokve has quit IRC02:59
*** gokrokve has joined #heat02:59
*** gokrokve has quit IRC03:00
*** gokrokve has joined #heat03:00
huangtianhuashardy: would you please to review https://review.openstack.org/#/c/130107/ and https://review.openstack.org/#/c/132625/ thx:)03:00
*** nosnos has quit IRC03:01
*** LiJiansheng has joined #heat03:01
asalkeldhuangtianhua, he said he was travelling03:03
*** Marga_ has quit IRC03:03
asalkeldnot sure where too03:03
asalkeldand for how long03:03
huangtianhuaah :)03:03
asalkeldhe should have filled us in more :-O03:04
*** hdd has quit IRC03:04
*** Marga_ has joined #heat03:04
*** gokrokve has quit IRC03:05
*** gokrokve has joined #heat03:05
*** gokrokve has quit IRC03:06
huangtianhuaasalkeld: about the neutron network constraint, http://paste.openstack.org/show/138570/ how do you think? it seems a litter odd:)03:07
*** gokrokve has joined #heat03:07
asalkeldlooking03:07
*** gokrokve has quit IRC03:07
asalkeldQiming, come chat where the cool kids are;)03:07
Qimingokay03:08
*** gokrokve has joined #heat03:08
*** gokrokve has quit IRC03:08
Qimingwe were talking about the design/roadmap for autoscaling separation work03:08
*** ananta has joined #heat03:09
asalkeldhuangtianhua, isn't there some similar discovery code somewhere03:09
anantao/03:09
anantagood morning fellas03:09
asalkeldhey ananta03:09
anantaHi asalkeld03:09
asalkeldgood morning apac03:10
Qimingthe suggestion is to make AS RPC calls work first03:10
anantaasalkeld: when is the poc evaluation planned?03:11
huangtianhuaasalkeld: not found, but for sahara resources, I found there is a validation of checking if running on neutron03:11
asalkeldananta, we are probably going to have to push to next week03:11
asalkeldananta, because of the US holidays03:11
huangtianhuaasalkeld: but I think it's incorrect in using nova network situation03:12
*** gokrokve has joined #heat03:12
asalkeldi wish for the concept that were the same we had generic resources03:12
asalkeldso the user didn't have to put neurton in their templates03:13
asalkeldananta, are you going to do the small poc (based on zane's repo)?03:13
asalkeldit would be nice to compare on equal ground03:14
*** serg_mel_ has joined #heat03:14
anantaasalkeld: no, our poc is based on current heat engine impl03:15
asalkeldananta, and no plans?03:15
asalkeld:-(03:15
asalkeldmaybe i need to try03:15
anantaasalkeld: I think as long as we canvey the idea it should be fine03:15
asalkeldok03:16
anantaasalkeld: we as a team wanted to understand Heat implementation, without which we couldn't have done it....03:16
asalkeldhuangtianhua, we can use a nova network with nova server, right?03:16
asalkeldananta, i understand03:16
huangtianhuaasalkeld: yes03:17
*** gokrokve has quit IRC03:17
anantaI mean understanding where Heat is now and how convergence would be brought in was the challenge we were looking for03:17
asalkeldananta,  we are coming at it from the other point of view03:17
*** serg_melikyan has quit IRC03:17
asalkeldananta, understanding heat - but trying to figure out convergence03:17
anantaasalkeld: true...we couldn't have done better with our limited understanding03:18
stevebakerananta: The problem is that your solution can't be evaluated against the alternatives unless it is implemented in zaneb's simple POC.03:18
asalkeldstevebaker, it can - it03:19
asalkeldstevebaker, it can - it's just more difficult03:19
stevebakerasalkeld: true, but not directly with the POC test suite03:19
anantanonetheless, it is important to convey the ideas03:19
*** serg_mel_ has quit IRC03:19
asalkeldstevebaker, ananta i'll try find some time to try that (convert what you have to zanes harness)03:19
asalkeldno promises tho'03:20
asalkeldstevebaker, who is on pto (zane/shardy)03:20
stevebakerananta: the risk is that if it is more difficult to evaluate then your solution might be overlooked, that would be a real shame03:20
anantastevebaker: its just not only the code with our PoC...we do have docs for it03:20
anantaI understand it would be bit difficult, but as folks who know Heat engine, I do believe that its not that difficult03:21
stevebakerananta: that is all good, but my point remains03:21
anantastevebaker: I think if we can work on getting the idea out of PoC we shouldn' have any problems03:22
stevebakerananta: do you have a particular objection to reimplementing in the POC? I realise the rework would be annoying03:22
*** killer_prince has quit IRC03:23
anantastevebaker: yes, the rework , for which we will have to again spend efforts in understanding that PoC03:24
*** Marga_ has quit IRC03:24
elynnmorning guys :)03:24
anantastevebaker: and I do feel that its much bettter to compare against the current impl03:25
anantawhere convergence takes us from where we are03:25
anantastevebaker: we have our own reason for choosing the way we went, so the focus for us should be on how we can convey the idea and converge on the idea03:26
anantastevebaker: I will definitely give it a try03:26
anantathanks for bringing that up03:27
*** harlowja is now known as harlowja_away03:29
asalkeldananta, def _get_ready_resources(self): is really get resources that need to be converged?03:29
anantaasalkeld: yes03:29
asalkeldcool, thx03:29
stevebakerananta: the POC was created so that ideas could be tried with minimal effort, so in theory it wouldn't take much coding. I think its fair to say that zaneb is the heat-core leading the convergence effort, so if he suggests doing something it would be very much to your benefit to give it a try. inc0 has contributed his own approach to the POC, and has grown the test cases, so it is becoming a useful focus point03:30
stevebakerfor evaluating approaches03:30
stevebakerananta: especially for building a test suite which exercises all those corner cases03:31
anantastevebaker: zaneb's poc started much after we started doing it...so there was no way for us to work on top of it03:32
anantaas I said I do inderstand your concern03:33
anantaasalkeld: there are few minor work remaining in our poc so I wanted to know when the evaluation was planned03:34
anantaasalkeld: by next week we should be ready03:34
asalkeldananta, it was going to be this week, but i forgot about all the US holidays03:34
stevebakerananta: yes, you're right, the POC happened after03:34
anantaasalkeld: np03:34
asalkeldso maybe we should plan for next03:34
*** hdd has joined #heat03:35
anantalets plan for next week03:35
asalkeldananta, if/when you do any work on a zane-based poc, let me know please03:36
asalkeld(and like wise, I'll do the same)03:37
anantaasalkeld: sure03:37
*** sarob has joined #heat03:45
asalkeldstevebaker, send some of that cool nz air here please, phew hot-n-sweaty here03:46
stevebakerasalkeld: its hot here, like 19 degrees!03:49
asalkeldthat's cool03:49
asalkeldit's not that hot here (only 29) but super humid03:49
*** sarob has quit IRC03:49
anantastevebaker: cooler than in here 23 degree C :)03:51
*** dimsum__ has joined #heat03:52
*** ananta has quit IRC03:54
stevebakerhmm, actually it got up to 24 today03:55
*** dimsum__ has quit IRC03:57
cmystermorning04:03
cmysterhad an issue yesterday with a template that was missing "resources:" but had "outputs:" stack-show gave me this:  "output_error": "The specified reference \"private_network\" (in unknown) is incorrect.",04:08
cmysteris this what I am expected in this case ?04:08
cmysterexpecting even04:09
cmysterbluh, brb + coffee04:09
*** achanda has joined #heat04:12
*** nosnos has joined #heat04:16
*** killer_prince has joined #heat04:17
*** killer_prince is now known as lazy_prince04:18
stevebakercmyster: it seems like a nicer error would be good04:21
cmysterI'll open a bug here then,04:22
*** asalkeld has quit IRC04:22
cmysterBTW stevebaker this sort of thing just explodes on older versions04:22
cmysterpuking ERROR:... blah blah when I do this, so this might need a back port as well04:23
*** asalkeld has joined #heat04:24
stevebakercmyster: so we're already better than we were ;)04:25
cmysterstevebaker: moving forward means progress04:25
cmysterprogress means that new introduced bugs are better looking ;)04:26
cmysterstevebaker: while at it, if I did not give a description in the outputs (2), one will show me only the value and the other will show me "description": "No description given",04:27
cmysterso the behavior is not the same, I'll add a different minor bug report for that as there is no reason to try both versions of the output in the same stack04:29
cmysteroh wait, sorry that was me not seeing clear, disregard...04:30
*** achanda has quit IRC04:30
stevebakerok, bbl dinner04:32
*** Marga_ has joined #heat04:35
*** mc__ has quit IRC04:37
*** Marga_ has quit IRC04:39
*** sabeen1 has joined #heat04:46
*** kebray has quit IRC04:56
*** LiJiansheng has quit IRC05:02
*** hdd has quit IRC05:09
*** rushiagr_away is now known as rushiagr05:10
*** kopparam has joined #heat05:11
*** ishant has joined #heat05:12
*** apporc has quit IRC05:15
*** kopparam has quit IRC05:17
*** kopparam has joined #heat05:17
elynnHi stevebaker , do you have time to review https://review.openstack.org/#/c/135197/ again?05:20
*** mc__ has joined #heat05:21
*** nkhare has joined #heat05:21
*** rakesh_hs has joined #heat05:27
*** apporc has joined #heat05:28
*** LiJiansheng has joined #heat05:49
*** vijayagurug has quit IRC05:50
*** gokrokve has joined #heat05:50
*** gokrokve has quit IRC05:52
Qimingasalkeld, there?05:52
asalkeldQiming, yip05:53
Qimingagain, for autoscaling05:53
Qimingonce there is a dedicated engine doing autoscaling05:53
QimingHeat won't see auto-scaling-group as a nested stack, right?05:53
asalkeldQiming, it depends on whether you assign the owner stack id05:54
asalkeld(which you probably should)05:54
Qimingin the backgroud, as-engine is creating a stack for the ASG?05:55
asalkeldyip as normal05:55
Qimingso ... for 'normal' use cases, Heat will just ask AS-engine to create an asg, without caring how it is implemented05:58
QimingHeat may also ask AS-engine to scale up/down an ASG, also without caring the details05:58
asalkeldQiming, that would be ideal05:58
*** rushiagr is now known as rushiagr_away05:59
Qimingfor 'advanced' users, they want to know the ASG details as they can do today: resource-list --nest-depth05:59
Qimingis it okay to break that assumption?05:59
asalkeldQiming, it's good to keep that if possible06:00
*** sanjayu has joined #heat06:00
QimingI see, then we will keep that requirement in mind while focusing on getting the simpler cases solved06:01
*** k4n0 has joined #heat06:03
*** edmund has quit IRC06:06
*** tomek_adamczewsk has joined #heat06:22
*** apporc has quit IRC06:24
*** ananta has joined #heat06:28
*** ygoto has joined #heat06:38
openstackgerritMiguel Grinberg proposed openstack/heat: Consider invalid keywords a template validation error  https://review.openstack.org/13729006:57
*** apporc has joined #heat07:00
*** jprovazn has joined #heat07:02
*** rushiagr_away is now known as rushiagr07:07
*** kopparam has quit IRC07:19
*** achanda has joined #heat07:31
*** achanda has quit IRC07:36
*** alexheneveld has joined #heat07:37
*** alexheneveld has quit IRC07:41
*** chris_ has joined #heat07:45
*** pas-ha has joined #heat07:49
*** jstrachan has joined #heat07:53
*** inc0 has joined #heat07:55
*** rdo_ has joined #heat07:56
*** kopparam has joined #heat07:57
*** rdo has quit IRC07:59
pas-hamorning all08:00
openstackgerritQi Zhang proposed openstack/heat: Pickup the region name passed in from heatclient  https://review.openstack.org/13552108:03
*** jtomasek has joined #heat08:04
*** tomek_adamczewsk has quit IRC08:08
*** GonZo2K has joined #heat08:12
inc0gmornign08:13
cmystermorning08:16
*** ifarkas has joined #heat08:16
*** kopparam has quit IRC08:25
*** sorantis has joined #heat08:25
*** kopparam has joined #heat08:28
*** ifarkas has quit IRC08:28
*** ifarkas has joined #heat08:28
*** jcoufal has joined #heat08:29
*** achanda has joined #heat08:33
*** rdo_ has quit IRC08:42
*** rdo has joined #heat08:43
cmystershould there be a limit to nested template depth when creating a stack ?08:45
cmysterI can call a template from its parent, but it won't call lower template for some reason08:46
*** apporc has quit IRC08:46
*** apporc has joined #heat08:46
*** achanda has quit IRC08:48
cmyster/should/is/08:50
*** tomek_adamczewsk has joined #heat08:54
openstackgerritPavlo Shchelokovskyy proposed openstack/heat: Support volume type in Sahara Node Group Template  https://review.openstack.org/12720508:54
openstackgerritPavlo Shchelokovskyy proposed openstack/heat: Support secgroups in Sahara Node group templates  https://review.openstack.org/13602208:54
openstackgerritPavlo Shchelokovskyy proposed openstack/heat: Support availability zones in Node Group Templates  https://review.openstack.org/13602308:54
*** serg_melikyan has joined #heat08:55
*** rdo has quit IRC08:56
*** rdo has joined #heat08:58
*** jistr has joined #heat08:59
*** zhenzanz has quit IRC08:59
*** jprovazn has quit IRC09:01
shardycmyster: there is, see max_nested_stack_depth in heat.conf09:02
shardycmyster: it's defaulted to 3, which, arguably, is too low in many cases09:02
*** rdo has quit IRC09:10
cmysteroh hi there shardy09:12
cmystersec lemme see09:12
*** derekh has joined #heat09:12
*** rdo has joined #heat09:12
cmystershardy: if three then in my case I should see the grandchild created, but its not. also the logs are a bit useless in that regard becase there is no recollection to a limit that I could see09:15
*** jprovazn has joined #heat09:15
shardycmyster: probably you're not hitting the limit then, it's most likely some other issue, or you'd get a "Recursion depth exceeds 3" error message09:19
shardyhttps://github.com/openstack/heat/blob/master/heat/engine/stack_resource.py#L13309:19
cmysterhmmm interesting, I'll hit the logs again09:19
*** serg_melikyan has quit IRC09:19
*** rdo has quit IRC09:20
cmysterno thats not it.09:20
cmysterthough shardy after yesterday I stopped trusting myself ;)09:20
*** tomek_adamczews1 has joined #heat09:22
*** rdo has joined #heat09:22
*** tomek_adamczewsk has quit IRC09:23
huangtianhuashardy: around:) would you please to review https://review.openstack.org/#/c/130107/ and https://review.openstack.org/#/c/132625/ thx09:25
elynnHi shardy :) also this cherry-patch and related patches https://review.openstack.org/#/c/135528/09:26
elynnheat doesn't support python2.6 in kilo?09:28
*** mc__ has quit IRC09:31
shardyelynn: all projects are dropping python 2.6 support during kilo09:33
*** cmyster has quit IRC09:35
*** rdo has quit IRC09:35
inc0that will stir the waters...09:35
*** cmyster has joined #heat09:36
elynnwow so openstack kilo release can not be installed in rhel6.x?09:37
*** rdo has joined #heat09:37
*** GonZo2K has quit IRC09:38
cmysterno09:39
shardythat's not strictly true, python 2.7 can be installed via software collections09:41
shardyI can't comment on what vendors will actually support though, just saying it's probably technically possible09:41
openstackgerritThomas Herve proposed openstack/heat: Update Barbican resources to match library changes  https://review.openstack.org/13731509:48
*** lazy_prince has quit IRC09:48
*** tochi has quit IRC09:49
*** LiJiansheng has quit IRC09:53
cmystershardy: if the default depth is 3, should I expect the same when gate is running ?09:55
*** LiJiansheng has joined #heat09:55
cmysterarrg, brb09:56
*** jcoufal_ has joined #heat09:57
*** tomek_adamczewsk has joined #heat09:58
*** tomek_adamczews1 has quit IRC09:58
*** Qiming has quit IRC09:59
*** rdo has quit IRC09:59
*** jcoufal has quit IRC10:00
*** blues-man has joined #heat10:01
*** rdo has joined #heat10:01
*** julienvey has joined #heat10:09
openstackgerritQi Zhang proposed openstack/heat: Pickup the region name passed in from heatclient  https://review.openstack.org/13552110:12
*** kopparam has quit IRC10:14
openstackgerritQi Zhang proposed openstack/heat: Pickup the region name passed in from heatclient  https://review.openstack.org/13552110:17
*** elynn has quit IRC10:17
*** fayablazer has joined #heat10:18
*** mkollaro has joined #heat10:19
*** kopparam has joined #heat10:25
*** kopparam has quit IRC10:26
*** kopparam has joined #heat10:27
*** elynn has joined #heat10:30
*** ygoto has quit IRC10:33
asalkeldpas-ha, are there no fixed values for volume type in sahara10:33
*** KanagarajM has joined #heat10:34
*** stannie has joined #heat10:34
pas-haasalkeld, I think that's determined by what volume_types are available in Cinder10:35
pas-hamight worth a check probably10:35
asalkeldso there is no way to validate other that creating really10:36
asalkeld(that's ok, just asking)10:36
pas-hanot sure, if there is such a thing as cinder volume-type-list we may try to validate10:36
pas-hawill check10:36
asalkeldk10:37
pas-hawell, there is cinder type-list in shell. will implement validation then.10:38
pas-hawould it be worth to validate all the other stuff? secgroups are surely discoverable, and availablilty zones too10:39
*** sorantis has quit IRC10:40
asalkeldi don't know pas-ha, it is also expensive10:40
asalkeldlots of calls to services10:41
asalkeldthere are pros and cons to it10:41
inc0when we would validate that? in handle_create or in tpl publishing?10:42
*** dkusidlo has quit IRC10:42
asalkeldinc0, so what is there is validate by fire10:43
asalkeldwhich is one option10:43
asalkeldbut i was hoping there was a static list of volume types10:44
asalkeld - guess not10:44
inc0is there any other real option? We can validate before we even begin with stack create, but that doesn't mean that real thing won't change when we actually start doing that10:44
inc0so potentially validation will return false positive, therefore it will be useless10:44
asalkeldbrb10:44
thervevolume types are defined in cinder configuration. Static but per deployment.10:45
inc0you can add new volume types10:45
inc0by conf ofc, but still10:45
pas-haone surely can create volume-types on the fly - we even have e resource for that :) (may be still on review)10:47
pas-habut probably only as admin10:48
pas-halisting them is for everyone10:48
pas-hayep, cinder type-create XXX is admin-only10:49
*** tellesnobrega_ has quit IRC10:49
pas-hainc0, we usually try to check such stuff in validate() resource's method, but it is indeed puts some API calls burden10:50
pas-haon the other hand, it is probably still worth it than failing (huge) stack in the middle of creation10:51
inc0ehh, I don't like that we fail stack because of one failed resource10:51
*** kopparam has quit IRC10:51
pas-hawell, in this case (wrong input) even convergence would not help10:52
*** tellesnobrega_ has joined #heat10:52
inc0yes, but convergence can fail part of stack10:52
inc0branch of graph dependant on this one resource10:52
pas-haand we must fail. or have some state OMG_I_ONLY_CREATED_HALF_OF_THE_STUFF10:52
pas-habut having only part of the stack still means you have the full stack failed10:53
inc0yeah, I know, I just emphasize my disapproval for this approach;)10:53
*** Yanyanhu has quit IRC10:54
inc0we can cache some api calls10:54
*** Qiming has joined #heat10:54
pas-haI mean other alternative is keep trying with wrong user input params, keep showing CREATE_IN_PROGRESS and fail only after timeout10:54
inc0I mean, volume types are common for every user in stack...10:54
pas-habut they might change on the fly10:55
pas-haCRUDed by admin10:55
inc0yeah, my point is, we don't even know if our validation is correct when we start doing actuall creating10:55
inc0convergence could enable us "retry this part of stack"10:56
pas-hanot completely, sure, but with quite fair degree of confidence10:56
*** killer_prince has joined #heat10:56
*** killer_prince is now known as lazy_prince10:56
inc0so we set up 99 vms, 1 is failed due to wrong input, we update this singular one10:56
pas-hayes, but how/when to tell the user that he needs update?10:56
*** kopparam has joined #heat10:56
inc0we'd need "stack partially complete" status..10:57
inc0and way of reporting how things really are right now10:57
pas-hahow convergence would understand that resource creation is failed due to some out-of-band problem or due to wrong params?10:57
inc0but that would also make stack create not an atomic function10:57
inc0we can just tell user - hey something is wrong, fix it10:58
inc0maybe retry create this part of stack is enough10:58
pas-hawe actually had the idea of "created_enough_to_operate" partial state somehwere in summit etherpads10:58
inc0can we actually make such decission?10:59
pas-hawhich?10:59
inc0if it is "enough to operate"10:59
pas-hawell, user sets a goal10:59
inc0I'd support "partially complete" and let user decide10:59
pas-halike a hadoop cluster, I spin up 1000 vms but would like to start diong stuff as soon as I have 10011:00
*** sorantis has joined #heat11:00
inc0but we'd need some nifty way of make changes to existing stack...not an atomic one11:00
skraynevpas-ha: I thought, that we had some objections about partially complete stacks...11:00
inc0so you get "partially create" status, user comes and sees "o, 100 out of 1000 is enough, lets keep these and retry other 900"11:01
pas-haor pacemaker cluster, where voting for master needs min N/2+1 nodes11:01
pas-hainc0, yeah, smth like that11:02
inc0thats why I really don't like that we actually consider create as singular, atomic action :/11:02
inc0with all or nothing approach11:02
asalkeldinc0, there are lots of use cases for both approaches (every thing must succeed and partial)11:04
asalkeldno one solution11:04
inc0asalkeld, thats why I say "let user decide"11:04
asalkeldtho' we brought this up at summit and most were against it11:04
shardywhat's wrong with just having a stack status of create failed when it's partially created, then looking at the status of the individual resources to decide if doing an update to reach complete state is needed?11:05
shardynot all resources succeeded, so a top level status of failed is accurate IMO11:05
shardyit's not like we don't expose the per-resource status too11:06
asalkeldyo shardy11:07
asalkeldshardy my fingers are feeling worn out, do you mind running the meeting?11:07
asalkeldtoo much irc'ing today11:08
shardyasalkeld: Ah, hmm, I forgot about that as I'm travelling this week11:08
shardyasalkeld: Ok, will do11:08
asalkeldo, where are you11:08
asalkeldin a bus/train/plane11:08
shardyasalkeld: In Paris - so it's in ~50mins right?11:08
asalkeldyeah11:08
asalkeldoo, lucky you11:08
asalkeldfinally got to paris11:09
shardyasalkeld: Ok, I'll grab some lunch then can run the mtg11:09
asalkeldi'll be there shardy11:09
shardyasalkeld: Heh, yeah made it eventually :)11:09
inc0asalkeld, we wanted to discuss which convergence approach we finally take today, do you feel like you need to be here for that?11:10
asalkeldinc0, i'll be there11:10
inc0ok11:10
asalkeldinc0, tho' zane won't11:10
asalkeldand lots of US people on holiday11:10
shardyzane needs to be here to make that decision IMO, so we should defer till next week11:10
asalkeldso I'd suggest we post pone til next week11:11
* shardy -> lunch11:11
inc0sure, agreed11:11
*** mkollaro has quit IRC11:11
inc0although Zane made an impression yesterday that he'll be here11:11
inc0we'll see I guess11:12
*** tellesnobrega_ has quit IRC11:14
*** julienvey has quit IRC11:16
asalkeldany items to add: https://wiki.openstack.org/wiki/Meetings/HeatAgenda11:22
*** kitch_ has joined #heat11:33
*** hdd has joined #heat11:35
*** sorantis has quit IRC11:36
*** kitch_ has quit IRC11:39
asalkeldinc0, are you looking at this: https://github.com/zaneb/heat-convergence-prototype/commit/423087f899606273d7271390270acb2664b8cd4611:39
asalkeldinc0, zane has pulled your code and applied his new tests to your branch11:40
asalkeldand tests are failing11:40
*** kitch_ has joined #heat11:40
*** jamielennox is now known as jamielennox|away11:48
*** hdd has quit IRC11:49
*** viktors|afk is now known as viktors11:52
inc0asalkeld, we've spoke about that, there was problems with implementations11:53
inc0were*11:53
inc0I also added few tests on my own to my code11:53
asalkeldcool, are they solvable?11:54
inc0haven't seen any case which isn't11:54
asalkeldok11:54
inc0I see that Zane added few more tests so I'll try to port these cases as well11:54
inc0problem with common testing is that my architecture is stateless and async by design, so its hard to have same test code for sync and async11:55
asalkeldwell i am happy you are both getting stuck into it, well done11:55
shardy+1, it's great to see the collaboration :)11:55
inc0yeah, problem will be when we'll actually have to make decision;)11:56
*** kitch_ has quit IRC11:56
inc0noone wants to drop his guard;)11:56
inc0although I'm leaning towards trying to make both approaches at the same time;)11:56
inc0only mine will be called convergence contionous observer11:57
cmystershardy: that depth thingy, its not working . I changed to 5 and it created it all.11:57
cmysternice name inc011:57
inc0and someday will "accidently" start solving create/update/whatever as well as normal convergence engine11:57
cmysterdeserves a comic super villain11:57
*** sorantis has joined #heat11:58
asalkeldmeeting time in 2 mins11:58
inc0http://img3.wikia.nocookie.net/__cb20100402161911/lotr/images/f/f5/Eye_of_sauron.jpg11:58
shardycmyster: Ok, last time I tested it it worked fine, pls raise a bug and we can investigate11:58
shardyI actually thought we had tests which prove it works tbh11:59
cmystershardy: I am working on it11:59
cmysterbut it dod not work so I started investigating11:59
cmysterI built the templates for the test and am testing them manually to make sure I can later automate11:59
*** kitch_ has joined #heat12:00
cmystertime12:00
*** dulek has joined #heat12:00
inc0thing is Zane wants to have something done asap, and for that his approach is better, its much closer to what heat does right now. I want to have it all in stateless, and thats kinda revolutionary12:00
*** kitch_ has quit IRC12:00
asalkeldmeeting time folks12:00
*** kopparam has quit IRC12:03
*** kitch_ has joined #heat12:06
*** dulek has quit IRC12:06
*** dulek has joined #heat12:06
*** kopparam has joined #heat12:09
*** rakesh_hs2 has joined #heat12:12
*** rakesh_hs has quit IRC12:12
*** rpothier has joined #heat12:20
*** serg_melikyan has joined #heat12:20
*** blues-man has quit IRC12:23
*** rpothier has quit IRC12:24
*** serg_melikyan has quit IRC12:24
*** julienvey has joined #heat12:27
*** KanagarajM has quit IRC12:28
*** julienvey has quit IRC12:31
*** kopparam has quit IRC12:33
*** julienvey has joined #heat12:34
asalkeldg'night all12:34
*** rpothier has joined #heat12:34
*** asalkeld has quit IRC12:34
cmysternn asa12:37
cmysteroops12:37
cmystershardy: issue resolved12:38
cmysterit wasn't a real issue12:38
*** sgordon_ has joined #heat12:39
*** rpothier has quit IRC12:39
inc0ananta, by the way, have you seen my approach yet?12:42
*** rpothier has joined #heat12:42
inc0I'd be curious if you have any feedback on your own12:42
*** kleini has joined #heat12:44
*** chris_ has quit IRC12:44
kleinihow can I get outputs of a stack when the stack creation failed? It seems to me that no outputs all are then available.12:44
*** rushiagr is now known as rushiagr_away12:46
pas-hakleini, I think it depends on whether the resources that those outputs refer to have been created12:46
pas-hai.e if yuo had get_attr: [server, networks] and server failed to create - you get nothing12:46
*** jcoufal_ has quit IRC12:47
pas-hasince most of the attributes are actually making API calls to the resource12:47
kleiniI have outputs from three different resources. two of them are created completely without any failures. their outputs are not available, too.12:48
*** hdd has joined #heat12:48
*** jcoufal has joined #heat12:48
pas-hathan it seems I am wrong :(12:48
kleinihere is what I see with the heat client: http://pastebin.com/icUq89yA12:51
kleinithe outputs for failed stacks looks strange...12:53
pas-hacan you paste your outputs section from the template?12:53
kleinihttp://pastebin.com/sme1Cp9s12:55
*** nkhare has quit IRC12:57
*** rpothier has quit IRC12:59
anantainc0, nope13:02
anantagreat if you could tell in brief13:02
pas-haso, what actually failed? if server, than none of the other two ref'd resources created either13:02
pas-hakleini, ^13:02
*** zaneb has joined #heat13:08
zanebhey guys13:08
zanebdid I miss the meeting already?13:08
dulekzaneb: Yes.13:09
zanebdammit13:09
dulekzaneb: But there weren't anything special I think.13:09
zanebsorry, haven't adjusted my calendar for daylight savings ending13:09
zanebthese 7am ones are not working our for me :/13:10
zanebdulek: cool, thanks. I will read the log13:10
inc0hi zaneb13:10
dulekzaneb: inc0 will be here in a moment, maybe you can confront both convergence ideas13:10
zanebbut right now... breakfast13:10
dulekalso ananta is there I think13:11
kleinipas-ha: only the last resource 'deployment' fails actually. the floating-ip and the server are created completely13:11
zanebdulek, inc0, ananta: my plan is to start a mailing list discussion today13:12
inc0thats probably good idea, but will make things longer..13:13
inc0I was thinking about other thing...I think we could proceed with both ideas zaneb - yours and mine13:14
inc0I'm not sure how yours cope with ananta's but all I'm really doing is slightly different observeer13:14
inc0which may one day be enough for creation and so on13:15
anantazaneb: sure, we can start with the mailing list13:15
anantaand discuss in detail next week13:16
inc0its thanksgiving week I think, that may make things a bit stressed about time13:16
*** prazumovsky has joined #heat13:20
*** nosnos has quit IRC13:20
*** prazumovsky has left #heat13:20
*** prazumovsky has joined #heat13:20
*** alexpilotti has joined #heat13:21
*** mkollaro has joined #heat13:21
*** LiJiansheng has quit IRC13:22
openstackgerritQiming Teng proposed openstack/heat: Extract group functions into a utility module.  https://review.openstack.org/13735613:24
*** apporc has quit IRC13:24
*** swygue has joined #heat13:25
openstackgerritPeter Razumovsky proposed openstack/heat: Fix [H302] errors in heat_integrationtests  https://review.openstack.org/13712613:30
openstackgerritPeter Razumovsky proposed openstack/heat: Remove ignoring [H302] in tox.ini  https://review.openstack.org/13712713:30
openstackgerritPeter Razumovsky proposed openstack/heat: Fix [H302] errors in heat/engine  https://review.openstack.org/13418713:30
openstackgerritPeter Razumovsky proposed openstack/heat: Fix [H302] errors in heat/tests  https://review.openstack.org/13533013:30
*** alexpilotti has quit IRC13:32
*** serg_melikyan has joined #heat13:35
*** blues-man has joined #heat13:39
zanebinc0, ananta: back13:39
zanebyeah, it is thanksgiving tomorrow, so I am out the rest of the week after today13:39
*** serg_melikyan has quit IRC13:40
anantazaneb, inc0: sorry I have to go for a meeting, catch you later13:40
openstackgerritPeter Razumovsky proposed openstack/heat: Fix [H302] errors in heat_integrationtests  https://review.openstack.org/13712613:40
openstackgerritPeter Razumovsky proposed openstack/heat: Remove ignoring [H302] in tox.ini  https://review.openstack.org/13712713:40
openstackgerritPeter Razumovsky proposed openstack/heat: Fix [H302] errors in heat/engine  https://review.openstack.org/13418713:40
openstackgerritPeter Razumovsky proposed openstack/heat: Fix [H302] errors in heat/tests  https://review.openstack.org/13533013:40
*** ananta has quit IRC13:40
*** rushiagr_away is now known as rushiagr13:42
*** rakesh_hs2 has quit IRC13:43
openstackgerritPeter Razumovsky proposed openstack/heat: Fix [H302] errors in heat/engine  https://review.openstack.org/13418713:43
openstackgerritPeter Razumovsky proposed openstack/heat: Fix [H302] errors in heat_integrationtests  https://review.openstack.org/13712613:45
openstackgerritPeter Razumovsky proposed openstack/heat: Remove ignoring [H302] in tox.ini  https://review.openstack.org/13712713:45
openstackgerritPeter Razumovsky proposed openstack/heat: Fix [H302] errors in heat/engine  https://review.openstack.org/13418713:45
openstackgerritPeter Razumovsky proposed openstack/heat: Fix [H302] errors in heat/tests  https://review.openstack.org/13533013:45
inc0I'm back as well13:50
*** dimsum__ has joined #heat13:51
inc0zaneb, I was thinking if we could proceed with our ideas at same time13:51
zanebinteresting, how would that work do you think?13:52
inc0I think if we'll keep in sync, we could model our work in a way which will solve problems of both approaches13:52
inc0well we do want observer to happen eventuallyu13:53
inc0and its pretty close to what I'm doing13:53
inc0only difference will be its behaviour wont be just to schedule next graph traveral, but to schedule actual actions13:54
*** che-arn8 has joined #heat13:54
*** che-arne has joined #heat13:54
*** che-arn8 has quit IRC13:54
inc0we both have notion of goal, just representation slightly differs13:55
zanebso the idea behind the original convergence flow chart is that we do both13:55
zanebwe schedule graph traversals for the worker, and individual actions for the observer13:55
inc0and difference would be that graph traversals won't really happen in worker13:56
inc0it could happen in engine and worker will be just to do atomic actions13:56
inc0like call nova.servers.create13:56
inc0I mean handle_create13:56
inc0so, client call stack create, your algorithm will schedule actions for creation based on graph and so on13:57
zanebfwiw the plan is that the engines will be the workers13:57
zanebbut I think what you're suggesting is that each traversal will be owned by one engine?13:58
inc0whatever we name it (personally I think workers would have to be more scallable than any other part)13:58
inc0that wouldn't be much of an improvement;)13:58
zanebno, exactly ;)13:59
inc0what I mean is you keep your graph state in db and at some point you'll want to schedule next step right?13:59
zanebactually in my approach we don't keep it in the DB14:00
inc0distributed-graph?14:00
zanebI guess we keep parts of it in the db, when we are joining two branches14:01
inc0well, at least notion of dependency has to be kept somewhere14:01
inc0it can be in resource table14:02
inc0still, it will be some representation of an graph14:02
*** hdd has quit IRC14:02
inc0and this representation will be goal my observer wants to achieve14:02
zanebyes14:02
inc0then there is slight difference of approaches, because you base on this graph and calculate next moves14:03
inc0while I don't really calculate next moves with notion of graph as whole, just moves that brings us closer to what we want14:04
inc0and then there is execution, and it will be 80+% of work in my opinion14:04
inc0and it will be common for both approaches if we'll be careful to make it so14:05
*** aweiteka has joined #heat14:06
*** sanjayu has quit IRC14:07
*** kitch_ has quit IRC14:15
*** kitch_ has joined #heat14:16
*** kitch_ has quit IRC14:17
*** julienvey has quit IRC14:18
*** kitch_ has joined #heat14:20
*** kitch_ has quit IRC14:20
openstackgerritPeter Razumovsky proposed openstack/heat: Change RouterGateway resource's name  https://review.openstack.org/13633914:21
*** kitch_ has joined #heat14:23
openstackgerritPeter Razumovsky proposed openstack/heat: Change RouterGateway resource's name  https://review.openstack.org/13633914:23
inc0zaneb, btw...if we consider complex actions like update-replace as atomic, I guess algorithm is almost the same..14:23
inc0I had problems because I didn't want to make this an atomic action...14:25
inc0(but problem was solvable...nearly solved really)14:25
zanebit can't be atomic, can it? what do you mean by atomic?14:25
inc0update-replace as one synchronious function call14:26
inc0a workflow so to say14:26
*** Qiming has quit IRC14:26
zanebI don't see how it can be, given that other resources need to be processed between creating the replacement and deleting the original14:26
inc0yeah, thats my point...and creation takes time14:27
inc0quite frankly I'm trying to find some fundamental differences between our approaches14:31
inc0could you help me with that?14:31
*** ramishra has quit IRC14:33
zanebtbh I'm not entirely sure what your approach is, because there is so much stuff where you said 'oh, the real thing won't work like this'14:34
inc0my approach is: "someone creates a stack, we create goal stack in db"14:34
inc0then there is while True:14:34
zanebI do know that it's so heavy on the db that even the simulator runs noticeably slow, which is something I wouldn't previously have believed possible ;)14:34
*** julienvey has joined #heat14:34
inc0check goal stack -> check what is in reality -> put on queue action which we can do right now (all deps met) and will solve subset of diffs14:35
inc0thats it14:36
*** serg_melikyan has joined #heat14:36
inc0you do update, you change goal stack14:36
inc0you do next update (even before previous was finished) you change goal stack14:36
inc0and converger doesn't really care if you updated something or what14:37
*** Qiming has joined #heat14:37
inc0it just looks, o, there is difference, all requirements are met, lets solve this one difference and check again14:37
inc0or even schedule solving14:38
zanebit sounds similar, except for the while True part14:38
inc0yeah, you just run it14:38
inc0but problem is14:38
inc0you don't really know how many steps are needed14:38
inc0it will end...eventually14:38
inc0so you can't really just say "do converge"14:38
inc0because end will happen in finite number of steps, but you never know this number14:39
zanebI think the difference is you're trying to combine the worker and the observer into a single process, effectively14:39
inc0its like...stack is complete when there is no futher diff to process14:39
inc0no, why? observer schedules n tasks which are possible to do now14:40
inc0worker takes 1 task from queue, performs it and thats all14:40
zanebwhich I don't think will be helpful when we have two different kinds of resources (phase 2-compatible and legacy)14:40
inc0what wouldn't be compatible?14:40
*** serg_melikyan has quit IRC14:40
dulekinc0: observer schedules tasks? Or engine?14:40
zanebsee, you're using your own definition of observer again14:40
inc0dulek, observer...whatever does converge really14:41
zanebwhich makes this discussion really hard14:41
zanebbecause we are not speaking the same language14:41
*** mikeit has joined #heat14:42
inc0ok, so lets call worker==process which takes task from queue and performs it (like single handle_create)14:42
inc0converger==event loop which checks whats real state (from db) and goal state(from db) and puts actions on queue which can be done right now14:43
inc0observer==process which polls real resources (literally checks if nova instance is active) and puts that status to real_state_db14:43
inc0engine==process API calls for template resolution and puts goal_db_state14:44
zanebno, let's back up14:45
inc0ok..14:45
zanebI'm not even talking about your proposal14:45
zanebI'm talking about the original convergence flowchart14:45
*** che-arne has quit IRC14:46
zanebin that flowchart you had a worker, which is responsible for handling the update (or not) of one resource14:46
zanebwhich it can do one of two ways:14:46
zanebphase 1: by calling handle_create()/handle_update() directly14:47
*** mikeit has quit IRC14:47
zanebphase 2: by farming work out to an observer14:47
zaneb(provided that the resource is written to support that, otherwise the phase 1 method remains an option)14:48
*** mikeit has joined #heat14:48
zanebyour proposal effectively combines the two parts, so each step is a step that in the original flowchart would have been performed by the observer14:49
inc0with a few changes, because observer would also have notion of dependency14:49
inc0but basically yes14:49
inc0and problem is, handle_create now is completely stateful and synchronous right?14:50
zanebyes14:51
inc0allright, so for start lets do something like that:14:51
zaneband for some resources will remain that way for quite some time14:51
inc0worker (I'm reffering to worker I described)14:51
inc0will call rsc.handle_pre_create()14:51
inc0rsc.handle_creat()14:51
inc0rsc.hadnle_post_create()14:52
inc0pre and post create will be methods implemented in base resource class14:52
inc0so will be inherited14:52
inc0and pre: will add resource with "new" status to reality, so effectively create a resource lock14:53
inc0post: will release a lock14:53
inc0and handle_create will be just synchronous handle_create14:54
inc0later we can override these methods in resources to slowly migrate them to phase2-compatible14:54
inc0you can put synchronous code to async framework14:55
*** che-arne has joined #heat14:56
zanebI don't want to have to implement the algorithm in every new resource; implement it once in create() and choose on the basis of what handle_*() methods are available14:57
*** Qiming has quit IRC14:58
*** andersonvom has joined #heat14:59
inc0agreed15:00
zanebinc0: btw did you look at the changes I pushed to iterative-adapted yesterday?15:00
zanebI fixed the test failures (my fault)15:01
zanebbut then I imported the basic_create test from my branch15:01
inc0ah15:01
zaneband it fails because it doesn't respect dependencies15:01
zanebI had a go at fixing it but couldn't find anything obvious15:02
inc0yeah, thats probably because I didnt resolve getrsc or getatt as new deps15:02
zanebyep, I think so15:02
inc0I simply put all of this explicitly to template15:02
zanebbut I couldn't find the code where you were checking for any dependencies15:02
zanebso I didn't know how to fix it15:02
dulekI'll check if this is the issue.15:02
inc0https://github.com/inc0/heat-convergence-prototype/blob/iterative/converge/resource.py#L7915:03
zanebbut I think you could consider merging the -adapted branch now, so that we are both using the same test framework15:03
inc0I will15:03
zanebaha15:04
inc0I also will write a detailed spec of my idea, because I feel there is lot of misunderstands between us;)15:04
zanebbtw Template.dependencies() calculates it all for you15:04
inc0or even misunderstandings15:04
inc0yeah, I figured that out afterwards;)15:04
inc0also I could do something about this db heavy stuff...lookups are done in horrible way15:05
zanebyeah15:05
dulekIf you put the dependencies explicitely basic_create is working fine on iterative-adapted15:05
zanebso some of my design goals were15:06
dulekSo it's like inc0 said.15:06
zaneb- minimise db access15:06
zaneb- constrain db locking to the smallest scope possible, for minimal contention15:06
*** elynn has quit IRC15:06
zaneb- avoid reading attributes of resources (i.e. hitting the OpenStack APIs) multiple time15:07
zanebdulek: ok cool, thanks15:07
inc0yeah, I probably could rewrite this now in better way15:07
*** sgordon has joined #heat15:08
inc0basically all dependency stuff are stored in check_*_readiness15:09
inc0where each resource will check if things its dependant on are in state which it wants it to be15:09
inc0or needs it to be15:09
*** jcoufal has quit IRC15:10
*** mkollaro1 has joined #heat15:11
*** mkollaro has quit IRC15:12
*** randallburt has joined #heat15:19
*** randallburt has quit IRC15:19
*** randallburt has joined #heat15:19
*** lazy_prince is now known as killer_prince15:21
*** edmund has joined #heat15:28
*** dimsum__ has quit IRC15:28
*** dimsum__ has joined #heat15:29
*** gokrokve has joined #heat15:30
jpeelershardy: of all(any) of your stable updates going to make tomorrow's freeze?15:31
*** radez is now known as radez_g0n315:32
*** andersonvom has quit IRC15:32
*** andersonvom has joined #heat15:33
shardyjpeeler: I'd love them to, I just have no idea how to make them pass the **** gate tests15:34
jpeelerwas assuming they'd make it in, is there a packaging deadline for RDO?15:35
shardyjpeeler: We may have to carry them downstream, atm I don't understand why the grenade job keeps failing, let me look at it again15:38
shardyI've nearly worn out the letters r e c h e and k on my keyboard :\15:39
jpeelerheh15:39
*** alexpilotti has joined #heat15:39
jpeelerok, i'm prepared to do that. i'll at least assume at this point it's okay to roll into the next stable release, rather than right this moment.15:39
shardyjpeeler: Ok, sounds good, I'll have another attempt at rechecking them15:40
shardyHmm, grenade actually failed for a different reason this time I think, maybe it will work this time15:44
*** jcoufal has joined #heat15:46
jpeelerit's been added to this list just in case: https://etherpad.openstack.org/p/StableJuno15:47
*** GonZo2K has joined #heat15:49
*** JayJ has joined #heat15:52
*** EricGonczer_ has joined #heat15:56
*** GonZo2K has quit IRC15:57
*** sarob has joined #heat16:00
inc0cyas guys, happy thanksgiving for US folks16:00
*** EricGonczer_ has quit IRC16:01
*** dimsum__ is now known as dims16:03
*** mikeit has quit IRC16:04
*** inc0 has quit IRC16:05
*** serg_melikyan has joined #heat16:06
*** vijendar has joined #heat16:09
*** ishant has quit IRC16:09
*** serg_melikyan has quit IRC16:10
*** JayJ has quit IRC16:12
*** JayJ has joined #heat16:13
*** zigo has quit IRC16:16
*** JayJ has quit IRC16:17
*** rpothier has joined #heat16:17
*** EricGonczer_ has joined #heat16:18
*** JayJ has joined #heat16:18
*** zaneb has quit IRC16:18
*** tomek_adamczewsk has quit IRC16:19
*** JayJ has quit IRC16:22
*** JayJ has joined #heat16:23
*** EricGonczer_ has quit IRC16:23
*** swygue has quit IRC16:24
*** crose has joined #heat16:25
*** swygue has joined #heat16:26
openstackgerritTetiana Lashchova proposed openstack/python-heatclient: Fix H302 errors  https://review.openstack.org/13606716:26
*** swygue has quit IRC16:26
*** swygue has joined #heat16:26
*** dulek has quit IRC16:26
*** zigo has joined #heat16:27
*** sarob has quit IRC16:28
*** gokrokve_ has joined #heat16:30
*** k4n0 has quit IRC16:30
*** gokrokve has quit IRC16:31
*** zaneb has joined #heat16:31
*** jcoufal has quit IRC16:33
*** JayJ has quit IRC16:34
jpeelerzaneb: i know you're probably trying to get things wrapped up today, but if you could let me know if https://review.openstack.org/137237 is even close to what you were wanting, that would be helpful16:34
zanebsure, I'll take a look16:34
*** sarob has joined #heat16:35
*** packet has joined #heat16:35
*** packet has quit IRC16:37
*** ananta has joined #heat16:40
zanebjpeeler: looks really close16:42
zanebjpeeler: can you explain "# PROBLEM: get_class doesn't have access to the stack object?"?16:42
*** rpothier has quit IRC16:45
*** gokrokve_ has quit IRC16:45
*** Marga_ has joined #heat16:46
*** serg_melikyan has joined #heat16:46
jpeelerzaneb: i didn't see a way to always return an outputs object, such as in generate_class of template_resource16:48
jpeelerwhich sort of defeats everything that i was trying to do16:48
zanebah, ok16:48
zanebI have an idea for that16:48
zanebjust writing a comment now16:48
*** ananta has quit IRC16:49
jpeelersuper, I figured you had all the answers16:50
*** fayablazer has quit IRC16:51
*** serg_melikyan has quit IRC16:51
*** kleini has left #heat16:53
*** viktors is now known as viktors|afk16:53
zanebjpeeler: rofl16:56
*** andersonvom has quit IRC16:57
*** Marga_ has quit IRC16:57
*** Marga_ has joined #heat16:58
*** Marga_ has quit IRC16:59
*** Marga_ has joined #heat16:59
*** Marga_ has quit IRC16:59
*** Marga_ has joined #heat17:00
*** prazumovsky has quit IRC17:02
*** andersonvom has joined #heat17:13
zanebjpeeler: ah, it's trickier than I thought. I was pretty sure you can call parse() with stack=None though? obviously all bets are off for validating/getting outputs, but if you're only using it to grab the schema it should be fine...17:16
openstackgerritMerged openstack/heat: Fix [H302] errors in heat/engine  https://review.openstack.org/13418717:17
openstackgerritMerged openstack/heat: Fix [H302] errors in heat/tests  https://review.openstack.org/13533017:18
openstackgerritMerged openstack/heat: Fix [H302] errors in heat_integrationtests  https://review.openstack.org/13712617:20
openstackgerritMerged openstack/heat: Remove ignoring [H302] in tox.ini  https://review.openstack.org/13712717:21
openstackgerritMerged openstack/heat: Update Barbican resources to match library changes  https://review.openstack.org/13731517:21
shardyjpeeler: FYI I raised bug #1396696 for the most persistent juno grenade check failure, as it's not clear to me if it's an existing bug or not17:23
uvirtbotLaunchpad bug 1396696 in glance "grenade tests failing with glance 400 error" [Undecided,New] https://launchpad.net/bugs/139669617:23
shardyI'll keep rechecking, but if anyone else wants to recheck while I'm AFK this evening, feel free17:23
shardyjpeeler: I linked the affected patches in that bug report17:24
jpeelershardy: thanks - Alan is at least aware of them17:24
*** Marga_ has quit IRC17:24
jpeelerzaneb: hrm, I don't think I tried that - will look into that17:25
*** Marga_ has joined #heat17:26
*** sdw_ has joined #heat17:26
*** Marga_ has quit IRC17:30
*** Marga_ has joined #heat17:30
openstackgerritAnderson Mesquita proposed openstack/heat: Add Digest intrinsic function  https://review.openstack.org/13718817:32
*** gokrokve has joined #heat17:39
*** blues-man has quit IRC17:40
*** mkollaro1 has quit IRC17:44
*** sorantis has quit IRC17:51
*** Marga_ has quit IRC17:52
*** sdw_ has quit IRC17:52
*** Marga_ has joined #heat17:53
*** Marga_ has quit IRC17:54
*** Marga_ has joined #heat17:55
*** Marga_ has quit IRC17:55
*** jistr has quit IRC17:56
sdakeanyone ever seen this ERROR: create() argument after ** must be a mapping, not Namespace17:56
*** Marga_ has joined #heat17:56
sdake(unrleated to heat)17:56
*** derekh has quit IRC17:58
*** julienvey has quit IRC17:58
*** steel13 has joined #heat17:59
*** harlowja_away is now known as harlowja18:04
*** Marga_ has quit IRC18:06
*** Marga_ has joined #heat18:06
*** Marga_ has quit IRC18:07
steel13when creating heat stack, through the command line, an error returned, "ERROR: Could not fetch remote template 'software_config_server.yaml': Invalid URL scheme", in the template i'm using i have a property "type" referencing another template and here is the problem, anyone have any ideas to resolve this?18:07
*** Marga_ has joined #heat18:07
*** Marga_ has quit IRC18:12
*** Marga_ has joined #heat18:12
*** Marga_ has quit IRC18:13
*** crose has quit IRC18:14
*** Marga_ has joined #heat18:14
steel13exist some specific structure to use in property type resource?18:15
larskssteel13: can you post your template?18:17
steel13http://paste.openstack.org/show/101278/18:17
larskssteel13: I'm doing pretty much exactly that here, and it works: https://github.com/larsks/heat-kubernetes/blob/master/kubecluster.yaml#L21418:17
*** Marga_ has quit IRC18:18
*** Marga_ has joined #heat18:18
*** harlowja has quit IRC18:18
*** andersonvom has quit IRC18:18
larsksAnd there exists a file named "software_config_server.yaml" in the same directory as that template?18:18
*** andersonvom_ has joined #heat18:18
*** Marga_ has quit IRC18:19
*** harlowja has joined #heat18:19
*** Marga_ has joined #heat18:19
steel13larsks: yes, i have the two files in the same directory18:20
larsksWhat version of the heat client are you using?18:21
*** Marga_ has quit IRC18:21
*** Marga_ has joined #heat18:22
steel13larsks: heat --version 0.2.818:24
*** Marga_ has quit IRC18:25
larsksHmmm.  I've got 0.2.12 locally; I don't know if that is significant or not.18:25
*** Marga_ has joined #heat18:25
larsksFor what it's worth, the template itself looks fine to me.18:25
steel13hmm, i will update version to test. Thanks18:26
*** ifarkas has quit IRC18:27
*** Marga_ has quit IRC18:32
*** Marga_ has joined #heat18:32
*** Marga_ has quit IRC18:35
*** Marga_ has joined #heat18:36
*** Marga_ has quit IRC18:39
*** Marga_ has joined #heat18:39
*** harlowja_ has joined #heat18:41
*** jstrachan has quit IRC18:44
*** harlowja has quit IRC18:45
*** rushiagr is now known as rushiagr_away18:45
openstackgerritTetiana Lashchova proposed openstack/heat: Remove resource_by_refid() from OS::Heat::HARestarter  https://review.openstack.org/13744619:00
*** reed has quit IRC19:02
*** steel13 has quit IRC19:18
*** mkollaro has joined #heat19:18
*** jprovazn has quit IRC19:20
*** reed has joined #heat19:23
*** bitblt has joined #heat19:28
*** bitblt has left #heat19:30
*** tomek_adamczewsk has joined #heat19:37
*** rpothier has joined #heat19:43
*** pas-ha has quit IRC19:47
*** GonZo2K has joined #heat19:56
*** dims has quit IRC19:56
*** radez_g0n3 is now known as radez20:01
*** rpothier has quit IRC20:15
*** sarob has quit IRC20:28
*** sarob has joined #heat20:29
*** sarob has quit IRC20:34
*** ananta has joined #heat20:37
anantaHi zaneb20:40
zanebo/20:40
anantaGood afternoon20:40
zanebananta: isn't it like 2am in India???20:41
anantazaneb:  yes20:41
anantazaneb: I thought to discuss about and heard that there will be thanksgiving and folks may not be available20:42
ananta*about poc20:42
zanebyeah, US-based folks will be away the next couple of days20:42
anantazaneb: I couldn't get much time to see the poc you have been working on, but I have tried to read the log messages20:43
anantawe have the convergence poc at github https://github.com/anantpatil/heat-convergence-poc and would like to have some feedback for us20:45
zanebyes, I am going to try to write a summary for the list today20:45
zanebalthough I have struggled to be able to review what you have20:46
zanebI think where I ended up was similar, except for the method of traversing the graph20:46
*** tomek_adamczewsk has quit IRC20:46
*** tomek_adamczewsk has joined #heat20:46
zanebI have a DB record for each node that is waiting on input in a given transition, rather than one per node20:47
zanebI think you will run into locking problems with your approach, but I haven't looked closely to see how you addressed that yet20:47
anantazaneb: ok...how would it behave if an engine were to go down?20:48
zanebthat is the big undecided question20:49
anantazaneb: we  are seeing that we will have to lock frequently, but the lock is for minimum duration20:49
zanebif we know something has died, we can start another traversal20:49
zanebananta: yeah, I'm more concerned that everything is in contention on the same lock20:50
anantazaneb: yes, we hit the same wall...and we have few idea around removing the lock yet making it resilient20:51
zanebI think your approach and mine have similar issues if an engine goes down, so I would be interested to hear your solution20:51
*** aweiteka has quit IRC20:52
anantazaneb: in our approach, we keep the graph in db and send the nodes for convergence and exactly one engine listens for motifications on the stack topic20:53
anantathe engine which got the stack operation request creates a topic in AMQP and listens for the notifications there20:53
anantawhen the notifs arrives, the engine queues them and processes them from there20:53
zanebnotifications to mark a node as traversed?20:54
anantasince there is only one engine listening, other engines will not contend for the lock20:54
anantazaneb: yes...notifications mark as traversed, and new set of ready nodes a re computed20:54
anantawithin one engine the notifications are queued so that they are processed sequentially20:55
zanebheh, that sounds very similar to what inc0 is doing20:55
anantathe egine queue is simple queue datastructure20:55
zaneband if that engine dies?20:55
anantathere is tack lock table in DB and if the engine dies another engine can pick up from there20:56
zanebwhat about the lost notifications?20:56
anantafor that we need a periodic task running in each heat engine or an external api request20:56
anantathe notifications will be there in AMQP since they will not be ACKed untill they are processed and updated in DB20:57
anantathe idea is use the AMQP infrastructure effectivly and improve on relaibility20:57
zanebhmmm.... ok. oslo.messaging does not support that. did you modify it somehow?20:57
anantawe are still in the process of doing it :)20:58
anantadoing this approach in poc...20:58
zanebgood, I think we will need that for whatever we implement :)20:58
anantasure...20:59
anantaalso we were thinking about concurrent updates and would like you and other folks to also think about it20:59
anantain our case, if a stack is being provisioned, the concurrent request goes to the same engine which is processing the notification...so it just drops a;; the old notifs and starts fromm sratch again21:00
ananta*all21:01
anantawe are still brainstorming on concurrent update21:01
zanebyeah, mine would have the same behaviour I think21:01
anantasure21:01
zanebI think that is probably the right thing21:02
anantai think next week when you are back we can collaborate furthur and converge on a design21:02
zanebyou can't know what the rest of the template contains, so it doesn't make sense to continue the previous traversal when you have a new template21:02
zaneb+121:02
zanebthe tricky part is what to do with the resources that are already in progress21:03
anantazaneb: sure, I have a feeling your approach doesn't drastically differ from what we are thinking :)21:03
zanebyeah, I have a feeling you're right21:03
anantazaneb: we wait for them to finish so that we move from one stable state to another for the resource21:03
zanebyup, so the question is how long do you wait?21:04
anantacan't afford to just kill or abruptly stop on that resource21:04
zanebin current Heat it's hard-coded at 4 minutes21:04
*** andersonvom_ has quit IRC21:04
zanebthat isn't a very good solution, but I don't really know what is21:04
anantazaneb: I haven't thought about that...it will wait for default I guess... so we even wanted to bring the resource timeout21:05
anantazaneb: but it was becoming a overkill...21:05
anantanonetheless I feel someday we would need the resource timeout21:06
zanebyeah, the discussion got sidetracked into nonsense about zookeeper :/21:07
anantazaneb: yeah... the only problem in current approach is that if the engine dies then another engine has no otherway to know that apart from an external request or periodic task to check engine status21:08
anantaso folks in my team were thinking we have some supporting infrastructure which can tell about the events in group membership21:09
anantagroup of heat egines...if one goes down otherw would know via tooz or zookeeper etc.21:09
anantaso that they can take over from there21:09
anantaI do have a feeling for long term benifits of Heat engine we would need such external infra21:10
anantaotherwise we endup writing lot of code aroound this in HEat :(21:11
anantazaneb: beileve me...I wish we were sitting face to face ...there is so much complexitity and feedaback needed and discussion needed21:12
ananta:)21:12
*** randallburt has quit IRC21:12
zanebyeah, it's a struggle trying to figure out stuff like this collaboratively with no face-to-face meetings21:13
*** achanda has joined #heat21:15
*** radez is now known as radez_g0n321:17
anantazaneb: please do draft an e-mail as you had planned...next week when you are back we can discuss more21:17
zanebok cool, will do21:20
*** achanda has quit IRC21:20
anantazaneb: sure...thanks for you time and Happy Thanksgiving!21:21
zanebno worries, thanks for getting up at 2am to discuss!21:21
anantazaneb: no problem at all...feeling very sleepy...catch you later...bye21:23
*** ananta has quit IRC21:23
*** mkollaro has quit IRC21:26
*** zaneb has quit IRC21:31
*** JayJ has joined #heat21:36
*** rpothier has joined #heat21:37
*** tomek_adamczewsk has quit IRC21:38
*** tomek_adamczewsk has joined #heat21:38
*** zaneb has joined #heat21:45
*** achanda has joined #heat21:48
*** achanda has quit IRC21:49
*** matt__ is now known as mattoliverau21:53
*** Drago has joined #heat21:55
*** ifarkas_ has joined #heat21:56
*** hdd has joined #heat21:56
*** ifarkas_ has quit IRC21:59
*** asalkeld has joined #heat22:03
*** tomek_adamczewsk has quit IRC22:06
*** tomek_adamczewsk has joined #heat22:06
*** alexpilotti has quit IRC22:15
*** Drago has quit IRC22:20
*** ccrouch has quit IRC22:21
*** hdd has quit IRC22:21
*** hdd has joined #heat22:24
*** kitch_ has quit IRC22:24
*** tomek_adamczewsk has quit IRC22:25
*** tomek_adamczewsk has joined #heat22:25
*** rpothier has quit IRC22:26
*** zaneb has quit IRC22:29
*** tellesnobrega_ has joined #heat22:40
*** zaneb has joined #heat22:41
*** alexpilotti has joined #heat22:45
*** EmilienM has quit IRC22:47
*** EmilienM has joined #heat22:47
*** Drago has joined #heat22:49
*** achanda has joined #heat22:50
*** jamielennox|away is now known as jamielennox22:51
*** Drago has quit IRC22:54
*** achanda has quit IRC22:55
*** tellesnobrega_ has quit IRC23:18
*** JayJ has quit IRC23:21
*** gokrokve has quit IRC23:27
*** hdd has quit IRC23:40
*** tochi has joined #heat23:44
*** ygoto has joined #heat23:45
*** tellesnobrega_ has joined #heat23:47
*** GonZoPT has joined #heat23:47
*** GonZo2K has quit IRC23:49

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!