Tuesday, 2014-11-11

*** asalkeld has joined #heat00:02
*** Qiming has joined #heat00:05
*** Qiming has quit IRC00:11
*** spzala has joined #heat00:13
*** dims has quit IRC00:16
*** boris-42 has quit IRC00:17
*** achanda has joined #heat00:20
*** vijendar1 has joined #heat00:31
*** piccata has quit IRC00:31
*** piccata has joined #heat00:33
*** vijendar has quit IRC00:33
*** achanda has quit IRC00:34
miguelgrinbergstevebaker: is there a reason to have separate tripleo elements for each software config hook? These are all small scripts that only run if they are explicitly invoked, if they are installed and not used they would not cause any harm.00:41
stevebakermiguelgrinberg: yes, they also install the config tool. People won't want puppet, salt, ansible *and* chef on their images ;)00:43
ryansbstevebaker: should I be adding tests to the heat functionaltests for new features, or are those not run currently?00:43
miguelgrinbergstevebaker: thanks, looks like I missed that :-)00:44
ryansbstevebaker: what if they're infra polyglots and they use multiple config mgmt tools. That would help them DevOp harder, yes? ;-)00:44
stevebakerryansb: they are run in check-heat-dsvm-functional-mysql, and we'll be moving to requiring functional tests for new features. It will become voting when it is more stable.00:45
stevebakerheh00:45
ryansbok, so should I be doing that instead of tempest tests at the moment, or is that down the road?00:45
stevebakerryansb: we'll likely move all current tempest tests into the heat tree, so I would recommend new tests being in-tree00:46
stevebakerryansb: and using heatclient00:46
ryansbnoted. I'll scoot my tempest tests over. Thanks00:47
*** achanda has joined #heat00:47
*** Putns has quit IRC00:50
stevebakerryansb: ok, thanks00:50
*** julienvey has joined #heat00:54
*** zns has quit IRC00:58
*** julienvey has quit IRC00:58
*** dims has joined #heat00:59
*** zhiwei has joined #heat01:08
*** achanda has quit IRC01:08
*** nosnos has joined #heat01:09
*** otoolee has quit IRC01:11
*** dims has quit IRC01:14
*** spzala has quit IRC01:15
*** Qiming has joined #heat01:16
*** mkollaro has quit IRC01:17
*** achanda has joined #heat01:18
*** apporc has joined #heat01:25
*** killer_prince has joined #heat01:29
*** killer_prince is now known as lazy_prince01:29
*** Guest47013 has joined #heat01:29
*** Qiming_ has joined #heat01:30
*** otoolee has joined #heat01:31
*** Qiming has quit IRC01:34
*** otoolee has quit IRC01:36
*** dteselkin has quit IRC01:37
*** andersonvom has quit IRC01:38
*** dteselkin has joined #heat01:38
*** achanda has quit IRC01:41
*** achanda has joined #heat01:42
*** boris-42 has joined #heat01:44
*** achanda has quit IRC01:46
*** funzo_ has joined #heat01:48
*** funzo has quit IRC01:49
*** asalkeld_ has joined #heat01:52
*** asalkeld has quit IRC01:56
*** elynn has quit IRC01:56
*** tiantian has joined #heat01:58
*** elynn has joined #heat01:59
*** FL1SK has quit IRC02:08
*** FL1SK has joined #heat02:09
*** elynn has quit IRC02:09
*** radez_g0` has joined #heat02:09
*** radez_g0` has quit IRC02:09
*** radez_g0` has joined #heat02:09
*** radez_g0n3 has quit IRC02:10
*** Guest47013 has quit IRC02:20
*** Viswanath has joined #heat02:23
*** Viswanath has quit IRC02:26
*** alexheneveld has quit IRC02:36
*** alexheneveld has joined #heat02:37
*** LiJiansheng has joined #heat02:38
*** alexheneveld has quit IRC02:42
*** julienvey has joined #heat02:42
*** alexheneveld has joined #heat02:44
*** julienvey has quit IRC02:47
*** erkules has quit IRC02:48
*** erkules has joined #heat02:49
*** elynn has joined #heat02:59
openstackgerrithuangtianhua proposed a change to openstack/heat-specs: Support Cinder volume type manage  https://review.openstack.org/13041702:59
elynnmorning guys :)03:00
openstackgerritChangBo Guo(gcb) proposed a change to openstack/heat: Sync with latest oslo-incubator  https://review.openstack.org/13349203:11
openstackgerritChangBo Guo(gcb) proposed a change to openstack/heat: Sync with latest oslo-incubator  https://review.openstack.org/13349203:13
*** thedodd has joined #heat03:19
*** nosnos has quit IRC03:20
*** jyoti-ranjan has joined #heat03:21
*** jyoti-ranjan2 has joined #heat03:23
*** jyoti-ranjan has quit IRC03:23
*** zns has joined #heat03:27
*** alexheneveld has quit IRC03:31
openstackgerritA change was merged to openstack/python-heatclient: Updated from global requirements  https://review.openstack.org/13279003:31
*** pmallya has quit IRC03:33
*** dims has joined #heat03:45
openstackgerritChangBo Guo(gcb) proposed a change to openstack/heat: Sync with latest oslo-incubator  https://review.openstack.org/13349203:52
asalkeld_urg, time zone is fighting back04:04
*** shakamunyi has joined #heat04:04
*** cmyster has joined #heat04:07
*** cmyster has quit IRC04:07
*** cmyster has joined #heat04:07
cmystermorning04:08
openstackgerritA change was merged to openstack/heat-specs: Use Zaqar for software-config metadata and signaling  https://review.openstack.org/13188704:10
*** achanda has joined #heat04:11
openstackgerritA change was merged to openstack/heat-specs: OS::Nova::Server rich network property  https://review.openstack.org/13009304:11
*** nosnos has joined #heat04:12
*** andersonvom has joined #heat04:15
openstackgerritSteve Baker proposed a change to openstack/heat: Integration test for software-config tools  https://review.openstack.org/11371104:15
openstackgerritSteve Baker proposed a change to openstack/heat: Use RPC directly for software config operations  https://review.openstack.org/13360404:15
openstackgerritSteve Baker proposed a change to openstack/heat: Use RPC directly for software deployment operations  https://review.openstack.org/13360504:15
cmystermorning stevebaker did you have the chance to see my mail ?04:17
*** sanjayu has joined #heat04:18
*** julienvey has joined #heat04:31
*** otoolee has joined #heat04:33
*** achanda_ has joined #heat04:34
*** julienvey has quit IRC04:36
*** achanda has quit IRC04:36
*** shakamun_ has joined #heat04:45
*** andersonvom has quit IRC04:46
*** shakamunyi has quit IRC04:49
*** rushiagr_away is now known as rushiagr04:51
*** chlong has quit IRC05:02
*** andersonvom has joined #heat05:04
*** thedodd has quit IRC05:14
*** Yanyanhu has joined #heat05:14
openstackgerritA change was merged to openstack/python-heatclient: Tests work fine with random PYTHONHASHSEED  https://review.openstack.org/13255805:15
openstackgerritA change was merged to openstack/heat: Add nested_depth column to stack table  https://review.openstack.org/11573005:15
openstackgerritA change was merged to openstack/heat: engine service add nested_depth to create_stack  https://review.openstack.org/11573105:15
openstackgerritA change was merged to openstack/heat: Add nested_depth to internal _create_stack RPC interface  https://review.openstack.org/11573205:15
*** chlong has joined #heat05:18
*** Drago has quit IRC05:23
*** Yanyanhu has quit IRC05:36
*** boris-42 has quit IRC05:37
*** rakesh_hs has joined #heat05:38
*** k4n0 has joined #heat05:39
*** saju_m has joined #heat05:40
*** saju_m has quit IRC05:41
*** Yanyanhu has joined #heat05:41
*** saju_m has joined #heat05:42
*** tiantian has quit IRC05:43
*** saju_m has quit IRC05:46
*** jyoti-ranjan2 has quit IRC05:52
*** jyoti-ranjan has joined #heat05:59
*** sanjayu has quit IRC06:00
openstackgerritOpenStack Proposal Bot proposed a change to openstack/heat: Imported Translations from Transifex  https://review.openstack.org/13361506:01
*** sanjayu has joined #heat06:01
*** julienvey has joined #heat06:02
*** julienvey has quit IRC06:07
*** ishant8 has joined #heat06:13
*** tiantian has joined #heat06:17
*** chlong has quit IRC06:19
*** achanda_ has quit IRC06:27
*** achanda has joined #heat06:29
*** saju_m has joined #heat06:30
*** chlong has joined #heat06:31
asalkeld_stevebaker, lifeless (any other jet lagged folk) http://www.jetlagrooster.com/06:39
cmysternifty06:51
*** saju_m has quit IRC06:58
*** rushiagr is now known as rushiagr_away07:11
*** otoolee has quit IRC07:13
*** ipolyzos_ has joined #heat07:15
*** ipolyzos has quit IRC07:16
*** chlong has quit IRC07:18
*** saju_m has joined #heat07:18
*** otoolee has joined #heat07:19
*** apporc has quit IRC07:20
*** apporc_ has joined #heat07:20
*** achanda has quit IRC07:20
*** fbo has quit IRC07:25
*** radix__ has quit IRC07:28
*** radix__ has joined #heat07:29
*** adam_g` has joined #heat07:33
*** adam_g has quit IRC07:38
*** fbo has joined #heat07:38
*** kopparam has joined #heat07:39
*** ramishra has joined #heat07:39
*** ramishra has quit IRC07:39
*** ramishra has joined #heat07:39
*** serg_melikyan has joined #heat07:40
*** Putns has joined #heat07:41
*** zns_ has joined #heat07:42
*** zns has quit IRC07:45
*** julienvey has joined #heat07:47
*** rushiagr_away has quit IRC07:49
*** jprovazn has joined #heat07:50
*** julienvey has quit IRC07:52
*** kopparam has quit IRC07:54
*** Qiming__ has joined #heat08:04
*** zns_ has quit IRC08:06
*** LiJiansheng has quit IRC08:07
*** Qiming_ has quit IRC08:07
*** LiJiansheng has joined #heat08:09
*** zns has joined #heat08:14
*** jstrachan has joined #heat08:15
*** ramishra has quit IRC08:18
*** zns has quit IRC08:19
*** serg_melikyan has quit IRC08:20
*** achanda has joined #heat08:21
*** rushiagr has joined #heat08:25
*** achanda has quit IRC08:26
*** ishant9 has joined #heat08:29
*** ishant8 has quit IRC08:30
*** serg_melikyan has joined #heat08:30
*** serg_melikyan has quit IRC08:34
shardymorning all08:34
cmystermorning08:35
*** alexheneveld has joined #heat08:36
*** ifarkas has joined #heat08:44
*** LiJiansheng has quit IRC08:47
*** LiJiansheng has joined #heat08:48
*** pas-ha has joined #heat08:49
*** nkhare has joined #heat08:49
*** hdd has joined #heat08:51
*** kopparam has joined #heat08:52
*** Yanyanhu has quit IRC08:52
*** ramishra has joined #heat08:54
*** serg_melikyan has joined #heat08:54
elynnafternoon :)08:54
*** ramishra has quit IRC08:54
elynnI have a question about running unittests.08:55
elynnNow I using below command to run unittests.08:55
elynn./run_test.sh -V -p -u08:55
elynnBut it will run functional tests as well.08:55
elynnIf I don't want to run functional tests, what should I do?08:56
shardyelynn: try tox -e py2708:56
shardyrun_tests.sh seems to be a bit broken since the functional tests were added, unfortunately08:56
elynncool, will try that.08:57
*** hdd has quit IRC08:58
*** jistr has joined #heat08:59
elynnHi shardy , it failed when using 'tox -e py27'09:00
elynnIs there any special config to using tox?09:00
elynnhttp://paste.openstack.org/show/131812/ is error output.09:00
*** derekh has joined #heat09:01
*** Yanyanhu has joined #heat09:01
shardyelynn: Non-zero exit code (2) from test listing normally means there's an import error in the test09:02
shardyit's an annoyingly opaque error :(09:02
shardyI'd do rm -fr .tox/py27 then try again09:03
shardyperhaps you're missing some dependency, that will rebuild the venv09:03
elynnWill remove venv and retry it again. ha :D09:04
*** Marga_ has joined #heat09:05
*** Marga_ has quit IRC09:05
*** Marga_ has joined #heat09:05
elynnWhat's the difference between using tox and run_tests.sh?09:05
cmysterelynn: check the bash script itself09:06
cmysterdoes some things differently09:07
openstackgerrithuangtianhua proposed a change to openstack/heat: Implement 'InstanceId' for LaunchConfiguration  https://review.openstack.org/13340109:07
elynnIt seems if some tests failed in run_tests.sh, I can see where exactly it failed, but using tox it just say it failed and I don't know why.09:07
elynnHow to debug with tox?09:08
cmysterelynn: different way to test and therefore different way to show the error09:08
cmysterdon't know (yet) havn't started on those09:08
* cmyster just remembered09:10
cmystershardy: about that link ?09:11
cmysterwhat you said you would send me in RH's mail ?09:11
elynnOk, it seems not very convenient using tox for unittests09:12
cmystertherefore, tox ;)09:12
*** kopparam has quit IRC09:15
*** kopparam has joined #heat09:18
*** lazy_prince has quit IRC09:22
*** kopparam has quit IRC09:23
shardycmyster: sorry, forgot, sent now09:29
*** hdd has joined #heat09:30
shardyelynn: there are a few ways to approach it - all ways of running tests have various annoyances IME, but here's what I do:09:30
shardy- run tox -e py27, if it fails then run the individual failing test via eithe python -m testtools.run, or sometimes nosetests09:30
shardyThe problem with nose is any tests using testscenarios won't work, so in theory it's not supported09:31
shardypreviously I also used run_tests.sh, as it's a convenient way to run both the unit tests and pep check before doing git review09:32
shardyso it would, IMO, be nice to fix it at some point09:33
* shardy hasn't had time to look into it yet09:33
*** ramishra has joined #heat09:33
*** blues-man has joined #heat09:34
*** kopparam has joined #heat09:36
*** tspatzier has joined #heat09:36
*** julienvey has joined #heat09:36
elynnThanks shardy :) , now I'm clear.09:39
*** julienvey has quit IRC09:41
*** Marga_ has quit IRC09:43
openstackgerritRabi Mishra proposed a change to openstack/heat-templates: Add in-instance docker software config hook  https://review.openstack.org/12818209:45
*** tspatzier has quit IRC09:47
*** mkerrin has quit IRC09:47
cmysterthanks shardy09:51
cmysterI hate being that guy (no, not really) but did you also get a chance to read my mail from earlier today ?09:51
shardycmyster: I just replied ;)09:52
*** ishant10 has joined #heat09:52
cmysterhmmm got me a timer on mailcheck, thanks :)09:52
*** ishant9 has quit IRC09:53
*** ramishra has quit IRC09:55
*** tspatzier has joined #heat09:55
*** serg_melikyan has quit IRC09:56
*** Yanyanhu has quit IRC09:59
*** serg_melikyan has joined #heat10:01
*** Qiming__ has quit IRC10:02
*** kopparam has quit IRC10:07
*** elynn has quit IRC10:08
*** aruna has joined #heat10:09
arunacould i use Fn::join in a heat template?10:10
*** boris-42 has joined #heat10:11
shardyhttp://docs.openstack.org/developer/heat/template_guide/hot_spec.html#list-join10:11
shardyaruna: In a CFN template, yes, in a HOT template, you should use list_join instead10:11
*** tspatzier has quit IRC10:12
*** LiJiansheng has quit IRC10:14
*** achanda has joined #heat10:23
*** zhiwei has quit IRC10:23
*** tspatzier has joined #heat10:24
openstackgerrithuangtianhua proposed a change to openstack/heat: Delete resource_data after resource deleted  https://review.openstack.org/12950810:26
openstackgerrithuangtianhua proposed a change to openstack/heat: Failed res no need UpdateReplace which has nested_stack  https://review.openstack.org/13010710:26
*** achanda has quit IRC10:28
*** asalkeld__ has joined #heat10:28
*** asalkeld_ has quit IRC10:31
arunaso i got this {list_join: ['',[ {get_param: hostname},'stub01']]} but i get a api error like "Unexpected error occurred serving API: Property error : stub01: name Value must be a string"10:34
*** kopparam has joined #heat10:38
arunaany ideas what i could be doing wrong?10:42
*** kopparam has quit IRC10:43
asalkeld__shardy, fyi: https://github.com/stackforge/monasca-agent10:47
asalkeld__username/password10:48
*** asalkeld__ is now known as asalkeld10:48
*** kopparam has joined #heat10:51
shardyasalkeld: interesting, so where does the metric data end up, ceilometer?10:52
shardyIt mentions monitoring the overcloud ceilometer, but it's not clear what the datastore is for the check metrics it's collecting10:54
*** kopparam has quit IRC10:56
*** ramishra has joined #heat10:56
*** blues-man has quit IRC10:59
*** jyoti-ranjan has quit IRC11:00
*** ramishra has quit IRC11:01
*** ishant10 has quit IRC11:03
*** ishant10 has joined #heat11:04
*** ishant10 has quit IRC11:04
*** ishant has joined #heat11:05
*** ipolyzos_ is now known as ipolyzos11:07
*** ipolyzos has quit IRC11:08
*** ipolyzos has joined #heat11:08
*** serg_melikyan has quit IRC11:09
lsmolashadower: shardy so looking some more into the last heat issue11:12
shardyhey lsmola11:12
lsmolashardy: hello11:13
lsmolashardy: i think the problem is11:13
lsmolashardy: there are 2 ControllerAllNodesDeployment11:13
asalkeldshardy, that goes to monasca11:13
asalkeldnot ceilometer11:13
lsmolashardy: one CREATE_IN_PROGRESS and one UPDATE_IN_PROGRESS11:13
*** Qiming has joined #heat11:14
lsmolashardy: they are created 1 second after another11:14
lsmolashardy: but seems there is a race condition, cause each node is sending signal to one of them11:14
shardylsmola: interesting, so is that happening because the ControllerAllNodesDeployment is getting replaced during the update?11:15
lsmolashardy: but the CREATE_IN_PROGRESS creates new ControllerAllNodesDeployment also with new descendants11:15
lsmolashardy: so if the signal was sent to UPDATE_IN_PROGRESS, it never updates the new resource in CREATE_IN_PROGRESS11:16
lsmolashardy: and timeouts11:16
lsmolashardy: seems like the CREATE_IN_PROGRESS and UPDATE_IN_PROGRESS ControllerAllNodesDeployment has different uuid11:17
lsmolashardy: when I look to uuid referenced from event-list11:17
shardylsmola: Thanks, this is most helpful11:18
shardyso, to clarify, your update is adding a controller?11:18
lsmolashardy: actually the event with CREATE_IN_PROGRESS has the resource uuid blank, but it appears in CREATE_FAILED11:18
shardyso ther servers property is getting updated on the ControllerAllNodesDeployment?11:18
shardys/ther/the11:18
lsmolashardy: but it seems the uuid is taken anyway, so being blank is another mini bug11:18
lsmolashardy: sorry, typo11:19
lsmolashardy: it's all ComputeAllNodesDeployment11:19
lsmolashardy: but the story should be the same with Controller11:19
shardyhttps://github.com/openstack/tripleo-heat-templates/blob/master/overcloud-without-mergepy.yaml#L73911:20
shardySo you increment the number of controllers in the ResourceGroup, which changes the get_attr to "servers", which causes the ControllerAllNodesDeployment to get replaced on update11:20
shardyBut in this case, you don't really want that, you want ControllerAllNodesDeployment to remain, as the existing ResourceGroup members already have a reference to it11:21
lsmolashadower: so I think the problem is this http://paste.openstack.org/show/131850/11:21
lsmolashardy: ^11:21
lsmolashardy: each one is referring to different resource11:21
lsmolashardy: yes, not creating another resource would solve it11:22
shardylsmola: yup, I'm not sure why that resource is visible via the cli - was that just the output of heat resource-list?11:22
*** serg_melikyan has joined #heat11:23
lsmolashardy: otherwise there woul have to be either some timeout, or merging of signals of resources from CREATE and UPDATE11:23
lsmolashardy: this is heat event-list11:23
shardylsmola: Ok, so we need to either not replace ControllerAllNodesDeployment, or, move the deployment resource into the nested stack being scaled out by the resource group11:23
lsmolashardy: the resources are being rewritten, so event-list is the only history of what happened there11:24
shardyThe latter is the preferred pattern for resource groups, but I guess you want the config to happen after all members are created, right?11:24
lsmolashardy: actually the config can happen in parallel, after each node is deployed11:25
*** julienvey has joined #heat11:25
lsmolashardy: there are some dependencies on controller though11:25
shadowershardy: AllNodes is outside because it's building the list of IP addresses (and other stuff) of all the nodes in the resource group11:25
lsmolashardy: at least I think11:25
shardylsmola: Ok, so we need to move teh deployment resource inside OS::TripleO::Controller, so we create one deployment per controller, rather than a one for the entire group11:26
shadowerwe may want to change that to something more clever happening outside of Heat, but it is what it is now (these nodse need to know about each other)11:26
shadowershardy: yeah, that's not possible atm11:26
shardyshadower: aha, Ok, I guessed that it was something like that - evidently that's not an update friendly pattern :(11:27
*** saju_m has quit IRC11:27
shadoweryeah :-(11:27
lsmolashardy: just addition the resource id of UPDATE_IN_PROGRESS and previously created with stack-create is the same11:27
shadowerso AllNodesDeployment is a OS::Heat::SoftwareDeployments (note the plural) type. Looks like this might be a bug in that resource's update code?11:28
lsmolashardy: so it's the another CREATE_IN_PROGRESS that creates new ComputeAllNodesDeployment and child resources11:28
shardyshadower: Yeah, arguably it shouldn't be replaced when "servers" changes, unlike SoftwareDeployment (singular)11:29
shadoweryeah11:29
shardyFiguring out exactly what it should do however is probably not that simple11:29
shadoweryea :-(11:29
shardye.g, how many signals do we expect on update11:29
*** serg_melikyan has quit IRC11:29
shardyProbably something to discuss with stevebaker and tspatzier but I'm sure we can come up with a solution11:29
*** julienvey has quit IRC11:29
shadowerI guess you do want a replace if you change "servers" to another resource. But not if it's just resized11:29
shardylsmola: thanks for your analysis, much appreciated :)11:30
*** justin-8 has joined #heat11:30
shardyshadower: Yeah, and probably expect the number of signals to be the difference in the list length11:30
lsmolashardy: for ComputeAllNodesDeployment, each child resource should get one signal11:30
shadoweryeah11:30
shadower(my yeah was to shardy's msg, yay concurrency)11:31
shardylsmola: but, if say you have 9 controllers, and you update to 10, do all of them signal on update, or just the one new one?11:31
*** kopparam has joined #heat11:31
lsmolashardy: actually I don't see and actual connection to child resources, only to ComputeAllNodesDeployment,11:31
lsmolashardy: from my testing all of them11:31
shadowershardy: I think the previous ones should be untouched (and not send any signals) unless they get updated for another reason11:32
lsmolashardy: but, since it worked few times, there is a race11:32
lsmolashardy: so it might or might not send it to new ComputeAllNodesDeployment,11:32
shadowerlsmola: but now you're describing the buggy behaviour, right? If all you do is increase the number of servers in the resource group, teh old ones will not send anything, will they?11:33
*** justin-8_ has quit IRC11:33
shadowerrather: should not send anything11:33
*** tiantian has quit IRC11:33
shadoweronly the newly created nodes should be sending signals11:33
shardyhttps://github.com/openstack/tripleo-heat-templates/blob/master/overcloud-without-mergepy.yaml#L61011:33
lsmolashadower: I tested with computes, and they all had signal sent in logm in about the same time11:33
shardyI'm trying to figure out where deploy_signal_id is coming from in this case11:34
lsmolashadower: so 2 signals in log in total for the compute that was just updated11:34
lsmolashadower: so I guess count ++ is taken as change and os-collect-config runs again11:34
shadowerlsmola: but that's because of the botched AllNodes update code, right?11:35
shardyOh, that appears to be a magic input provided by SoftwareDeployment11:35
lsmolashadower: nevertheless, heat expects signal from all of them11:35
shardylsmola: well, now it does, if we fix the update behaviour, it won't11:35
shadowerhm okay. I don't like taht but w/e11:35
lsmolashadower: as the new ComputeAllNodesDeployment resource has 2 childs11:35
shardyand if we don't replace the ComputeAllNodesDeployment, there's no longer any race :)11:35
lsmolashadower: and it fails on the updated one, cause that sent signal to the old ComputeAllNodesDeployment,11:36
shadowerlsmola: yes but all you're describing now is the buggy behaviour, right? None of this should be happening once we fix it11:36
shardylsmola: Yeah, I think we're all agreed this is a bug, the question is just how to fix it :)11:36
shadowerright?11:36
shardyLet me make a coffee and hack on some code11:36
lsmolashadower: shardy if we will not create new ComputeAllNodesDeployment, that should fix it11:37
lsmolashadower: shardy though I guess signals should be sent from all nodes11:37
*** serg_melikyan has joined #heat11:37
shardylsmola: I guess that is my main question - will that happen, or just one from the new node11:37
lsmolashadower: shardy unless we check that also some parameters has been changed and check what nodes it affects ...11:37
shadowerlsmola: why? The existing nodes shouldn't be updated11:38
shadowershould they?11:38
shardyshadower: that's my expectation as well11:38
lsmolashadower: I guess it's just easier that doing plenty of checks11:38
shardyalthough I don't really know the agent-side stuff very well11:38
shadowershardy: yeah me neither...11:38
lsmolashadower: I mean what will happen if you will change e.g. somethin in nova.conf?11:38
lsmolashadower: and scale at the same time?11:39
shadowerlsmola: that's something else though. We're talking about the situation where all you do is change the count11:39
shardynova.conf isn't applied by this deployment, is it?11:39
shadowerlsmola: if you change the config value, that will force a replacement11:39
shadowerI need to drop off for a bit, bbl11:39
arunadoes list_join only work in a specific version of openstack, as i am having trouble getting it to work11:39
lsmolashadower: hm ok, I would just expect they always sent if because it's easier11:40
lsmolashadower: but I guess if the deployment for the updated node will not change, it should not invoke os-collect-config and it should not wait for signal11:40
shardyaruna: http://docs.openstack.org/developer/heat/template_guide/hot_spec.html#list-join11:40
shadoweraruna: you need a Juno Heat and the right template version11:40
shardyit was introduced in the Juno, you may need to use the AWS resource if you're on an older heat11:41
shardyhttp://docs.openstack.org/developer/heat/template_guide/hot_spec.html#heat-template-version11:41
shardyaruna: provided you use 2013-05-23 as your template version, Fn::Join should work even in a HOT template11:42
arunabummer we are only running havana11:42
shardywe made things stricter from 2014-10-1611:42
shardyaruna: I guess use Fn::Join then plan to migrate to list_join later?11:42
lsmolashadower: but if we scale and change parameters, will it force to create new ComputeAllNodesDeployment, so this race could appear again?11:43
arunathanks will try that now11:43
lsmolashadower: given we fix it by not creating new ComputeAllNodesDeployment on scale11:43
*** athomas has joined #heat11:46
shardylsmola: there are no parameters referenced in allNodesConfig or ControllerAllNodesDeployment11:52
lsmolashardy: and ComputeNodesDeployment ?11:53
shardyNeither of them reference any parameters11:54
shardySo it should be fine11:54
lsmolashadower: you are right that it should not call os-collect-config on just updated nodes, cause it will restart all services, we don't want that11:54
lsmolashardy: and referencing of parameters is causing what? :-)11:55
shardyOS::TripleO::Compute takes the parameters, so on update it's possible you change something which cases replacement of nodes, in which case the list referenced in "servers" to the deployments resource changes, and we know from comparing the old/new list how many signals to expect11:55
shardy"change parameters, will it force to create new ComputeAllNodesDeployment"11:55
shardyI am saying it won't11:56
lsmolashardy: ok, good11:56
shardythat said, using ResourceGroup may not be the best long term plan, as if you change something which requires replacement, we'll replace everything in the group11:56
lsmolashardy: hm11:56
shardyAutoScalingGroup allows rolling updates, which we may want to use at some point in future11:56
shardyanyway, that is unrelated to this problem11:57
lsmolashardy: yeah, shadower is already working on that11:57
shardyJust getting the basic update use-cases working seems like our first priority :)11:57
lsmolashardy: ok, so what is causing creation of new ComputeAllNodesDeployment"?11:57
shardylsmola: A heat bug, or the tripleo template design depending on your perspective11:58
shardyI'm looking into a fix in heat now11:58
lsmolashardy: seems like the os-collect-config run could be caused by creating new ComputeAllNodesDeployment11:58
lsmolashardy: ok good11:58
lsmolashardy: could be somehow possible to merge the two ComputeAllNodesDeployment?11:59
shardylsmola: when the bug is fixed there will only be one11:59
lsmolashardy: so if it already got the signal from update, you would propagate it to create?11:59
lsmolashardy: ok, great11:59
lsmolashardy: just last check, after it is fixed, it will never create new ComputeAllNodesDeployment?12:00
*** nkhare has quit IRC12:00
shardylsmola: yes, that's the plan12:00
lsmolashardy: ok, seem like that should fix all the potential problems12:00
shardy(subject to feedback from stevebaker and tspatzier)12:01
lsmolashardy: ok, thank you very much12:01
lsmolashardy: I will summarize the problem into the bug12:01
shardylsmola: np, yep summary would be great, I'll add some notes re the possible solution and ping you when there's a patch we can test12:01
tspatzierhey shardy, I saw somebody typed my name :-)12:01
shardyHey tspatzier!12:02
shardyWe're discussing the SoftwareDeployments resource12:02
*** alexpilotti has joined #heat12:02
shardylsmola/tripleo have a problem because it gets replaced whenever the "servers" list changes12:02
tspatzieryeah, I scanned thru the history a bit. still have to fully understand the issue12:02
*** sgordon has quit IRC12:02
shardywe're discussing making that not happen, so on update we compare the old/new lists and expect the appropriate number of signals12:03
*** sgordon has joined #heat12:03
*** blues-man has joined #heat12:03
shardytspatzier: basically, the Deployments "servers" property references a ResourceGroup, which changes size on update12:03
tspatzierok12:04
*** Marga_ has joined #heat12:05
shardythat doesn't work, because we replace the Deployments resource on update, instead of handling the change in the servers list without replacement12:06
tspatzierso lsmola will file a bug with a summary and where we can have all the discussion, right? that would be good12:06
tspatzierright, handling the update instead of replacing would be better. I guess we have to create/update/delete derived configs created by the deployments resource.12:07
*** jtomasek has joined #heat12:07
*** asalkeld has quit IRC12:07
shardyhttps://bugs.launchpad.net/heat/+bug/138917812:07
uvirtbotLaunchpad bug 1389178 in heat "heat stack-update failure when scaling resource group" [High,Triaged]12:07
shardytspatzier: ^^12:07
shardyI'm going to have a try at implementing a solution this afternoon12:08
tspatzierok, so that bug is for tracking this. I'll stay tuned.12:09
lsmolatspatzier: shardy bug updated https://bugs.launchpad.net/heat/+bug/138917812:10
uvirtbotLaunchpad bug 1389178 in heat "heat stack-update failure when scaling resource group" [High,Triaged]12:10
tspatzierlsmola: very good summary. thanks.12:11
*** cdent has joined #heat12:11
*** dims has quit IRC12:13
*** dims has joined #heat12:13
*** nosnos has quit IRC12:13
*** nosnos has joined #heat12:14
*** nosnos has quit IRC12:18
lsmolashardy: quick question, I guess we can't backport this one, right? https://review.openstack.org/#/c/128365/12:19
lsmolashardy: it landed in kilo, right?12:19
*** jistr is now known as jistr|english12:23
*** aruna has quit IRC12:23
*** sgordon` has joined #heat12:25
*** nkhare has joined #heat12:25
*** julienvey has joined #heat12:26
*** julienvey has quit IRC12:30
*** ramishra has joined #heat12:37
*** hdd has quit IRC12:40
*** alexpilotti has quit IRC12:41
*** blues-man has quit IRC12:43
*** nkhare has quit IRC12:44
*** apporc_ has quit IRC12:53
*** nkhare has joined #heat12:58
*** andersonvom has quit IRC13:04
*** blomquisg has joined #heat13:04
*** EricGonczer_ has joined #heat13:06
*** ramishra has quit IRC13:08
*** Marga_ has quit IRC13:09
*** Marga_ has joined #heat13:09
shardylsmola: Right, we can't backport it to upstream stable13:10
*** EricGonczer_ has quit IRC13:10
*** nkhare has quit IRC13:11
*** andersonvom has joined #heat13:13
*** Drago has joined #heat13:17
*** serg_melikyan has quit IRC13:17
*** pas-ha has quit IRC13:17
*** mkollaro has joined #heat13:24
*** achanda has joined #heat13:26
*** andersonvom has quit IRC13:28
*** andersonvom has joined #heat13:28
*** achanda has quit IRC13:31
*** pas-ha has joined #heat13:33
*** Qiming has quit IRC13:34
*** Qiming has joined #heat13:35
*** andersonvom has quit IRC13:35
*** rpothier has joined #heat13:40
*** jdob has joined #heat13:40
*** jprovazn has quit IRC13:43
*** kopparam has quit IRC13:51
*** funzo_ is now known as funzo13:58
lsmolashardy: ok13:59
*** andersonvom has joined #heat13:59
*** bart613 has quit IRC14:01
*** bart613 has joined #heat14:02
*** jistr|english is now known as jistr14:02
*** blues-man has joined #heat14:03
*** rushiagr is now known as rushiagr_away14:04
*** crose has joined #heat14:07
*** ramishra has joined #heat14:09
*** GonZo2K has joined #heat14:13
*** dims has quit IRC14:13
*** dims has joined #heat14:14
*** ramishra has quit IRC14:14
*** julienvey has joined #heat14:15
*** Drago has quit IRC14:18
*** jprovazn has joined #heat14:18
*** julienvey has quit IRC14:19
*** rakesh_hs has quit IRC14:23
*** ishant has quit IRC14:23
*** gokrokve has joined #heat14:29
*** jmckind has joined #heat14:29
openstackgerritQiming Teng proposed a change to openstack/heat: Adds multi-region support for stack resource  https://review.openstack.org/5331314:30
*** Drago has joined #heat14:32
*** zns has joined #heat14:34
*** ramishra has joined #heat14:36
*** GonZo2K has quit IRC14:44
*** zz_gondoi is now known as gondoi14:46
*** rushiagr_away is now known as rushiagr14:51
*** blues-man has quit IRC14:52
*** rushiagr is now known as rushiagr_away14:52
*** pmallya has joined #heat14:54
*** openstackgerrit has quit IRC14:55
*** crose has quit IRC15:01
*** blues-man has joined #heat15:04
*** rushiagr_away is now known as rushiagr15:05
*** tspatzier has quit IRC15:08
pscheieshardy, in Example 1 in http://docs.openstack.org/hot-guide/content/how-to-use-template-resources-for-composition.html, does the key_name property defined in the main template (main.yaml) become a parameter in the child template (my_nova.yaml)?15:09
*** GonZo2K has joined #heat15:09
*** tspatzier has joined #heat15:10
*** julienvey has joined #heat15:15
*** EricGonczer_ has joined #heat15:18
*** tellesnobrega_ has joined #heat15:18
*** kopparam has joined #heat15:19
*** tellesnobrega_ has quit IRC15:20
*** julienvey has quit IRC15:20
Qimingpscheie, that is correct15:22
*** GonZo2K has quit IRC15:22
*** serg_melikyan has joined #heat15:23
*** GonZo2K has joined #heat15:24
*** Drago has quit IRC15:27
*** k4n0 has quit IRC15:27
*** GonZo2K has quit IRC15:33
*** GonZo2K has joined #heat15:36
pscheieQiming, tx.15:41
*** gokrokve_ has joined #heat15:44
*** justin-8 has quit IRC15:46
*** justin-8 has joined #heat15:46
*** gokrokve has quit IRC15:47
*** bdellegrazie has joined #heat15:49
*** zns has quit IRC15:51
*** randallburt has joined #heat15:51
bdellegrazieHi everyone, I'm on Icehouse (heat client version 0.2.8, server 2014.1.3-0ubuntu1) trying to use the ResourceGroup's %index% capability. However the %index% never seems to be substituted in the name. Anyone have any other suggestions?15:51
*** zns has joined #heat15:52
*** Qiming has quit IRC15:52
jdandreabdellegrazie: Can you please post an example template to paste.openstack.org? Maybe that will provide some clues (and more eyes can have a look-see).15:54
bdellegrazieSure... one moment15:54
jdandreatx!15:54
bdellegrazie@jdandrea: http://paste.openstack.org/show/131930/15:57
*** thedodd has joined #heat15:57
*** GonZo2K has quit IRC15:59
bdellegrazie@jdandrea: ignore the duplicate image: tag that's a copy paste error15:59
*** achanda has joined #heat15:59
*** kitch_ has joined #heat16:01
jdandreabdellegrazie: Thanks! Looking.16:02
jdandreaI'll ignore that dupe.16:02
*** blues-man has quit IRC16:02
*** serg_melikyan has quit IRC16:03
*** gondoi is now known as zz_gondoi16:04
jdandreaHmph. That looks mostly harmless. Trying it ...16:04
*** serg_melikyan has joined #heat16:04
*** thedodd has quit IRC16:05
*** hdd has joined #heat16:06
pscheieI'm using the snippets shown in http://paste.openstack.org/show/131929/16:07
*** achanda has quit IRC16:07
pscheieBut I keep getting this error: Property error : ods_instance: availability_zone The Parameter (my_zone) was not provided.16:08
pscheieCan a property be passed in as a parameter from a OS::Heat::ResourceGroup?16:09
bdellegrazie@pscheie: do you have a definition for my_zone in the parameters section of the child template/16:12
bdellegrazie?16:12
*** ramishra has quit IRC16:14
*** julienvey has joined #heat16:16
*** ramishra has joined #heat16:16
*** mkollaro has quit IRC16:17
*** bdossant has joined #heat16:17
*** serg_melikyan has quit IRC16:17
*** serg_melikyan has joined #heat16:17
*** metral is now known as metral_zzz16:18
*** crose has joined #heat16:20
*** julienvey has quit IRC16:21
bdellegrazie@jdandrea: according to Git it looks like it isn't merged into IceHouse ... https://github.com/openstack/heat/commit/22095896d6a3f35445e72e484c8c7b7d05a82f9a (in branch 2014.2, not 2014.1) :(16:21
jdandreabdellegrazie: Ohhhh. :(16:22
jdandreaEek.16:22
bdellegrazieWell at least that explains why it doesn't work...16:22
bdellegrazie@jdandrea: thanks for your time and help16:23
jdandreanp!16:24
*** pmallya__ has joined #heat16:26
pscheiebdellegrazie, no, I don't.  I was thinking I only had to define it once, in the parent.16:26
pscheieOtherwise, what's the point of passing it as a parameter if I have to define it in the child template anyway?16:27
pscheiebdellegrazie, oh, I see.  I have to have it as a parameter in the child, but I don't have to assign a value to it in the child16:28
pscheieThe value comes as a parameter from the parent.16:29
*** pmallya has quit IRC16:29
*** Marga_ has quit IRC16:31
*** Marga_ has joined #heat16:31
*** randallburt has quit IRC16:33
*** Marga_ has quit IRC16:35
*** zz_gondoi is now known as gondoi16:36
bdellegrazie@pscheie: you got it.16:40
bdellegraziebye all16:40
*** bdellegrazie has left #heat16:40
*** blues-man has joined #heat16:40
pscheienuts!  Why do the people I'm chatting with keep leaving.16:41
*** crose has quit IRC16:41
jdandreapscheie: Places to go, stacks to create? :-o16:42
pscheiejdandrea, yes, I supposed other people have lives, too. ;-)16:42
jdandreaHehe.16:42
* jdandrea just has Colloquy running all the time.16:43
*** gokrokve has joined #heat16:43
pscheieOk, at bdellegrazie's suggestion, I added a my_zone parameter to the child, as shown here:16:43
pscheiehttp://paste.openstack.org/show/131950/16:43
pscheieBut now I'm getting a different error: Property error : ods:resource_def: Property my_zone not assigned16:44
*** metral_zzz is now known as metral16:44
*** gokrokve_ has quit IRC16:46
*** gokrokve has quit IRC16:48
*** tellesnobrega_ has joined #heat16:48
*** tellesnobrega_ has quit IRC16:49
jdandreapscheie: Try putting my_zone under properties under resource_def (yes, there will be two properties - one at the ResourceGroup level and one at the resource_def level).16:49
jdandreaExample: http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::ResourceGroup16:49
pscheieCan anyone verify that properties of a ResourceGroup get passed as parameters to the template specified by resource_def?16:50
jdandreaThat also means type: goes under resource_def and not in its own {}16:50
shardypscheie: You only specify the property that gets passed to the child inside the resource_def map:16:50
shardyhttps://github.com/openstack/tripleo-heat-templates/blob/master/overcloud-without-mergepy.yaml#L44416:50
jdandreapscheie: Yup, what shardy said.16:51
*** gokrokve has joined #heat16:51
shardyIn your last example, you were passing my_zone to ResourceGroup, not to the child template via resource_def, which won't work16:51
*** kopparam has joined #heat16:51
jdandreapscheie: I think this will do the trick, but have not verified it. http://paste.openstack.org/show/131953/16:52
*** tellesnobrega_ has joined #heat16:52
*** EricGonczer_ has quit IRC16:53
*** Viswanath has joined #heat16:53
pscheieYay!  Progress!16:53
*** EricGonczer_ has joined #heat16:54
pscheieI still got an error, but in a different place, so I'm moving forward.16:54
*** gokrokve has quit IRC16:54
*** gokrokve has joined #heat16:55
*** jistr has quit IRC16:55
*** Viswanath has quit IRC16:56
*** kopparam has quit IRC16:56
*** blues-man has quit IRC16:56
jdandreaGood! Progress is progress.16:57
*** ramishra has quit IRC17:06
*** tellesnobrega_ has quit IRC17:08
*** ramishra has joined #heat17:09
*** spzala has joined #heat17:10
*** julienvey has joined #heat17:12
*** julienvey has joined #heat17:12
*** hdd has quit IRC17:13
*** GonZo2K has joined #heat17:13
*** ramishra has quit IRC17:14
*** bdossant has quit IRC17:14
*** tchaypo has joined #heat17:15
*** athomas has quit IRC17:20
*** thedodd has joined #heat17:21
*** Marga_ has joined #heat17:25
*** julienvey has quit IRC17:27
*** ifarkas has quit IRC17:33
*** GonZo2K has quit IRC17:34
*** sanjayu has quit IRC17:35
*** GonZo2K has joined #heat17:38
*** ifarkas has joined #heat17:39
*** Marga_ has quit IRC17:42
*** derekh has quit IRC17:44
*** tellesnobrega_ has joined #heat17:45
*** openstackgerrit has joined #heat17:49
jdandreaReality check Q: OS::Cinder::Volume does *not* respond to volume size updates (increased size) with a detach/extend/reattach ... correct? Not seeing it in Icehouse or Juno.17:58
pas-hajdandrea, could you be more specific?18:00
jdandreapas-ha: If I try to increase a OS::Cinder::Volume size as part of a stack-update, my thinking is the request will be ignored by the resource plugin.18:00
jdandreaI'm asking for confirmation, in case I'm not reading the source correctly.18:00
pas-hano, it is implemented18:01
shardyjdandrea: No, on Juno at least, it will try to extend it if you've changed the size18:01
jdandreapas-ha: I looked at Juno and didn't see it.18:01
jdandreaI must be misreading then.18:01
pas-hahttps://github.com/openstack/heat/blob/master/heat/engine/resources/volume.py#L66918:02
pas-hahttps://github.com/openstack/heat/commit/f50738ffcdc58f3814efbff7d7b1095ee5549cf118:02
jdandreaThanks! I was indeed looking in the wrong spot. tyvm. Whew.18:03
*** tellesnobrega_ has quit IRC18:03
*** zns has quit IRC18:03
*** serg_melikyan has quit IRC18:03
*** bnemec has quit IRC18:04
pas-habtw, I have a question concerning the planned convergence workers and getting rid of scheduler tasks in resources18:05
*** pmallya__ has quit IRC18:05
pas-haare the workers planned to be multithreaded? or single worker will process only one single resource until completion in a blocking manner?18:06
*** bnemec has joined #heat18:07
pas-habecause disposing those scheduler tasks right now will penalize performance greatly18:07
shardypas-ha: my understanding is that the aim is to decouple the resource implementations from the scheduler, as currently the Scheduler implementation has leaked into resources, which would make replacing it with some other implementation much harder18:10
shardyI'm pretty sure we won't do that until it can be done without penalizing performance greatly though :)18:10
shardyzaneb is probably the best person to clarify how he expects that to play out :)18:10
pas-haok, will as him when we happen to be here at once :)18:11
*** GonZoPT has joined #heat18:11
pas-has/as/ask18:11
*** tellesnobrega_ has joined #heat18:12
*** GonZo2K has quit IRC18:13
*** serg_melikyan has joined #heat18:14
*** achanda has joined #heat18:17
*** serg_melikyan has quit IRC18:20
*** randallburt has joined #heat18:20
*** Marga_ has joined #heat18:27
*** daneyon has joined #heat18:30
*** alexheneveld has quit IRC18:31
*** Marga_ has quit IRC18:31
*** mkollaro has joined #heat18:35
*** tellesnobrega_ has quit IRC18:39
*** rushiagr is now known as rushiagr_away18:43
*** tellesnobrega_ has joined #heat18:43
*** jprovazn has quit IRC18:50
*** Drago has joined #heat18:54
*** zns has joined #heat18:55
*** zns has quit IRC18:56
*** achanda has quit IRC19:00
*** gokrokve has quit IRC19:01
*** zns has joined #heat19:01
*** EricGonczer_ has quit IRC19:03
*** gokrokve has joined #heat19:04
*** gokrokve has quit IRC19:09
*** randallburt has quit IRC19:09
*** tspatzier has quit IRC19:13
*** Marga_ has joined #heat19:15
zanebpas-ha: the workers will likely use eventlet for multithreading, just like we do now19:15
zanebpas-ha: the scheduler stuff is only for parallelising stuff within a stack's greenthread, which won't be needed with convergence19:16
*** randallburt has joined #heat19:18
*** achanda has joined #heat19:18
*** EricGonczer_ has joined #heat19:20
*** tellesnobrega_ has quit IRC19:20
*** tellesnobrega_ has joined #heat19:23
pas-hazaneb, but on the worker we might still need it, right?19:24
pas-haoh, I see, actual multithreading19:24
zanebpas-ha: no, we'll only be processing one resource at a time19:24
zanebi.e. one resource per greenthread19:24
pas-haok, that makes sense. thanks19:25
*** aweiteka has quit IRC19:25
pas-haok, g'night all, see you tomorrow19:25
*** pas-ha has quit IRC19:26
*** alexheneveld has joined #heat19:29
*** Drago has quit IRC19:30
*** Drago has joined #heat19:31
openstackgerritAnderson Mesquita proposed a change to openstack/heat: Implement handle_check for CloudWatch  https://review.openstack.org/12767019:31
openstackgerritAnderson Mesquita proposed a change to openstack/heat: Make resource check messages more consistent  https://review.openstack.org/13128119:31
openstackgerritAnderson Mesquita proposed a change to openstack/heat: Implement handle_check for Ceilometer alarms  https://review.openstack.org/12767119:32
openstackgerritAnderson Mesquita proposed a change to openstack/heat: Implement handle_check for OS::Nova::Server  https://review.openstack.org/12835719:32
openstackgerritAnderson Mesquita proposed a change to openstack/heat: Implement handle_check for Rackspace Cloud Servers  https://review.openstack.org/12835819:33
openstackgerritAnderson Mesquita proposed a change to openstack/heat: Implement handle_check for OS::Trove::Instance  https://review.openstack.org/13128219:33
openstackgerritAnderson Mesquita proposed a change to openstack/heat: Implement handle_check for OS::Swift::Container  https://review.openstack.org/13128319:34
openstackgerritAnderson Mesquita proposed a change to openstack/heat: Implement handle_check for OS::Nova::KeyPair  https://review.openstack.org/13128419:34
openstackgerritAnderson Mesquita proposed a change to openstack/heat: Implement handle_check for Cinder and EC2 Volumes  https://review.openstack.org/13128519:35
pscheieMy two-template stack is now able to spin up an instance.19:35
pscheieBut the hostname is an abomination: da-gog2knome-0-khotb5wgzctf-ods_instance-4owwsde2o2lk19:36
*** gokrokve has joined #heat19:37
pscheieThe environment is named dave1, and I've specified the name as one of the properties of OS::Nova::Server in the child template.19:37
pscheiesee http://paste.openstack.org/show/132000/19:39
pscheieI'm passing in the Environment parameter from the calling/parent template.19:40
pscheieSo, why isn't the name property being assigned the string I'm constructing for it?19:40
*** gokrokve has quit IRC19:41
*** pmallya_ has joined #heat19:42
*** jstrachan has quit IRC19:42
*** pmallya_ has quit IRC19:43
*** pmallya has joined #heat19:43
gpocentekhi all19:48
*** Drago has quit IRC19:48
*** Drago has joined #heat19:48
gpocentekFYI the hot-reference and hot-guide are "officialy" published: http://docs.openstack.org/hot-reference/content/ and http://docs.openstack.org/user-guide/content/hot-guide.html19:49
*** gokrokve has joined #heat19:49
*** kopparam has joined #heat19:52
*** shakamun_ has quit IRC19:52
*** shakamunyi has joined #heat19:57
*** swygue has joined #heat19:57
*** kopparam has quit IRC19:58
stevebakergpocentek: nice. do you know where the change is needed to trigger regeneration on post-merge heat changes?19:58
stevebakerhey, cross-linking from user-guide to hot-reference. very cool19:59
gpocentekstevebaker: to regenerate the reference?20:00
stevebakergpocentek: yeah20:01
gpocentekthere's a script in the openstack-manuals repository20:01
gpocentekhttps://github.com/openstack/openstack-manuals/blob/master/doc/hot-reference/README.rst20:02
stevebakerI assume something could be set up in project-config to trigger it20:02
gpocentekwe could probably setup something, yes20:03
*** Marga_ has quit IRC20:06
*** swygue has quit IRC20:09
*** killer_prince has joined #heat20:09
*** killer_prince is now known as lazy_prince20:09
*** pmallya has quit IRC20:13
jpeelerstevebaker: this look okay to you? http://fpaste.org/149805/20:15
*** hdd has joined #heat20:16
*** mkollaro has quit IRC20:19
*** pmallya has joined #heat20:20
*** gondoi is now known as zz_gondoi20:21
*** mkollaro has joined #heat20:26
*** tellesnobrega_ has quit IRC20:26
stevebakerjpeeler: are there any templates left in the package?20:26
stevebakerjpeeler: other than the software-config examples?20:26
jpeelernot with this change20:27
stevebakerI suppose there is a case for including the hot/* templates, but not if that implies that we "support" them20:28
*** jrist has quit IRC20:28
jpeelerkind of afraid that is the implication20:28
stevebakerjpeeler: yeah, in that case lgtm20:29
jpeelerthanks!20:29
stevebakerlsmola, shardy, shadower: I've read the SoftwareDeployments backscroll20:29
*** zz_gondoi is now known as gondoi20:31
openstackgerritAnderson Mesquita proposed a change to openstack/heat: Implement handle_check for Rackspace Cloud Servers  https://review.openstack.org/12835820:38
*** jmckind has quit IRC20:42
*** randallburt has quit IRC20:45
*** jmckind has joined #heat20:45
*** spzala has quit IRC20:45
*** achanda has quit IRC20:46
*** mkollaro has quit IRC20:47
*** mkollaro has joined #heat20:48
*** randallburt has joined #heat20:50
*** zns has quit IRC20:51
*** asalkeld has joined #heat20:52
*** zns has joined #heat20:52
asalkeldmorning20:52
stevebakermorning20:52
*** ifarkas has quit IRC20:55
*** aweiteka has joined #heat20:56
*** vijendar has joined #heat21:00
*** cdent has quit IRC21:00
*** vijendar1 has quit IRC21:03
*** mkollaro has quit IRC21:08
*** mkollaro has joined #heat21:09
*** zns has quit IRC21:09
*** Viswanath has joined #heat21:09
*** Marga_ has joined #heat21:11
*** Viswanath has quit IRC21:12
*** achanda has joined #heat21:14
*** zns has joined #heat21:15
*** shakamunyi has quit IRC21:18
openstackgerritSteve Baker proposed a change to openstack/heat: Use RPC directly for software deployment operations  https://review.openstack.org/13360521:23
openstackgerritSteve Baker proposed a change to openstack/heat: Use RPC directly for software config operations  https://review.openstack.org/13360421:23
openstackgerritSteve Baker proposed a change to openstack/heat: Integration test for software-config tools  https://review.openstack.org/11371121:23
asalkeldanyone interested in being the stable branch liaison?21:27
*** pmallya has quit IRC21:27
openstackgerritA change was merged to openstack/python-heatclient: Remove _ from builtins  https://review.openstack.org/13255521:28
asalkeldit's a new "thing"21:28
stevebakertumbleweeds21:32
randallburtcrickets21:32
*** Marga__ has joined #heat21:33
*** shakamunyi has joined #heat21:34
*** Marga_ has quit IRC21:35
asalkeldmmm, maybe i can ask this evening21:35
*** Marga__ has quit IRC21:38
*** Marga_ has joined #heat21:39
*** shakamunyi has quit IRC21:39
*** pmallya has joined #heat21:41
jpeelerasalkeld: what all does it entail? i might be interested21:43
*** alexheneveld has quit IRC21:44
asalkeldjpeeler, cool -  so honestly not sure21:44
asalkeldbut watch the ml21:44
asalkeldtheirry will email soon21:44
*** mkollaro has quit IRC21:45
asalkeldthey want to de-centralise the stable-core-team21:46
asalkeldso give the projects more autonomy with stable branch21:46
asalkeldcoffee time21:47
*** hdd has quit IRC21:47
*** alexheneveld has joined #heat21:52
stevebakerevery heat ptl has stayed on stable-core-team, so we're already quite decentralised21:54
pscheiejdandrea, your example worked for me.  Thanks.21:54
pscheieNow I'm trying to pass the %index% number so I can incorporate it into each instance's hostname.21:55
pscheieIn the resource_def, I've got this property: my_index: %index%21:56
*** mkollaro has joined #heat21:57
*** jdob has quit IRC21:57
pscheieBut it's giving me this error: Property error : ods:resource_def: Property my_index not assigned21:57
stevebakercmyster: still awake21:58
stevebaker?21:58
pscheieIs that saying that no value is being assigned to my_index?  That is, is %index% not a valid variable?21:58
*** zns has quit IRC21:58
*** alexheneveld has quit IRC21:58
pscheieI picked it up from http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::ResourceGroup21:59
randallburtpscheie:  do you have a link to your template?22:00
pscheierandallburt, I'll make one.  Hang on.22:00
randallburtk22:00
*** Marga_ has quit IRC22:04
*** zns has joined #heat22:04
asalkeldrandallburt,22:05
randallburtasalkeld:  hey22:05
asalkeldthe hp guys say that they might be able to pay for our hotel in india22:06
asalkeld(still checking it out)22:06
asalkeldbut would that change things for you guys?22:06
asalkeldor not really22:06
asalkeld(for mid cycle)22:07
pscheierandallburt, http://paste.openstack.org/show/132032/22:07
asalkeldhotel is normally a big cost22:07
randallburtasalkeld:  dunno tbh. I'd have to check with Keith or whoever my boss winds up being.22:07
asalkeldk22:07
randallburtasalkeld:  did I miss a link to the poll or is that still pending (just now getting back to work after summit recovery).22:08
randallburtpscheie:  looking22:08
asalkeldrandallburt, i was planning to do that today22:08
randallburtasalkeld:  cool, just didn't want to miss it :)22:08
asalkeldi'll send a message to the ml22:08
*** daneyon has quit IRC22:09
randallburtpscheie:  I think that may be a limitation of using %index% like this. You may have to supply a default value to that param in the child template since %index% isn't resolved until the group is created.22:10
asalkeldtry "index_%index%"22:10
randallburtpscheie:  the default value will allow initial validation to pass, though I may be wrong here.22:10
pscheierandallburt, if I don't use the parameter in the child, it shouldn't cause any errors, should it?22:11
randallburtpscheie, asalkeld: or just "%index%" maybe.22:11
randallburtpscheie:  shouldn't as long as you remove passing it in the parent22:12
*** dsneddon has joined #heat22:13
asalkeldpscheie, you also don't have a default, so it will be required i think22:14
pscheierandallburt, well, if I pass it from the parent, and I have a parameter in the child to go with it, but then don't use that parameter with any of the resources, that should not generate any errors, right?22:14
pscheieI'm just trying to eliminate pieces to isolate my problem.22:14
randallburtpscheie:  no, because its considering the my_index property in the parent, not the child.22:15
pscheieHmm, setting a default in the child parameter seems to have fixed it, or at least got rid of the initial error.22:16
stevebakerrandallburt: I thought you were your own boss, APPROVED!22:21
*** chlong has joined #heat22:22
randallburtstevebaker:  I'm a figurehead. I get to approve contractor timesheets and go to meetings. Don't tell the team I can't fire them though. It'll be anarchy.22:22
*** asalkeld_ has joined #heat22:22
*** asalkeld has quit IRC22:26
pscheierandallburt, I think %index% in the parent doesn't contain a value to asssign to my_index.22:29
randallburtpscheie:  correct. validation will then fail unless you give a default value in the child template.22:30
pscheieIf I put a default value in the child's parameter, the resource always gets that.22:30
randallburtpscheie:  oh. that's bad. Hrm. Might be a bug. Can you try the other suggestions from myself and asalkeld_ (use quotes)22:30
*** bhi has quit IRC22:30
pscheieBut when I spin up the stack, the parameter in the child always seems to have the default value, not the value the parent should be passing.22:30
randallburtpscheie:  very odd. I will be afk in a bit, but you may need to submit a bug.22:31
pscheierandallburt, sure.  But won't quoting %index% just turn that into a string with the value %index%?22:31
randallburtpscheie:  should still get replaced.22:31
pscheierandallburt, quoting it results in a hostname of dave1-ods-%index%22:34
pscheieSo, the parent IS passing the value, which is good.  But it's not getting the actual index number value.22:34
randallburtpscheie:  looks like it. can you submit a bug and add me as a watcher or assign it to me?22:35
pscheierandallburt, sure.  I'm going to try a couple variations first just to make sure I don't have something screwy syntactically.22:35
randallburtpscheie:  k.22:36
jdandreapscheie: Glad to hear it!22:36
*** rpothier has quit IRC22:36
*** aweiteka has quit IRC22:38
pscheieWeird: now I'm getting a different error: found character that cannot start any token22:38
pscheie  in "<unicode string>", line 74, column 2222:38
pscheiecolumn 22 is the first % in %index%22:39
pscheieThe line is just  my_index: %index%22:40
pscheieI swear I had that syntax earlier but didn't get that error (although perhaps the lack of a default in the child was masking it).22:40
*** tspatzier has joined #heat22:41
*** rdo has quit IRC22:42
*** rdo has joined #heat22:44
zanebasalkeld_: our manager is away this week, but in general terms it's looking like budget will be *very* tight for any midcycle22:46
*** rushiagr_away is now known as rushiagr22:48
*** randallburt has quit IRC22:49
*** randallburt has joined #heat22:49
*** jmckind has quit IRC22:51
*** jrist has joined #heat22:51
*** dsneddon has quit IRC22:52
*** daneyon has joined #heat22:53
*** dsneddon has joined #heat22:53
*** rdo has quit IRC22:55
*** EricGonczer_ has quit IRC22:56
*** rdo has joined #heat22:57
*** daneyon_ has joined #heat22:59
*** shakamunyi has joined #heat22:59
*** jrist has quit IRC22:59
*** jrist has joined #heat23:00
*** shakamun_ has joined #heat23:00
*** daneyon has quit IRC23:03
*** shakamunyi has quit IRC23:04
*** shakamunyi has joined #heat23:07
*** shakamun_ has quit IRC23:11
*** jrist has quit IRC23:14
asalkeld_ok zaneb23:14
asalkeld_i think mid cycle is asking a lot of companies23:14
stevebakersounds like we're leaning towards not having one23:15
*** asalkeld_ has quit IRC23:20
*** asalkeld__ has joined #heat23:20
*** thedodd has quit IRC23:21
*** daneyon_ has quit IRC23:23
*** zns has quit IRC23:25
*** achanda has quit IRC23:27
*** achanda has joined #heat23:27
*** achanda has quit IRC23:28
*** pmallya has quit IRC23:44
*** Drago1 has joined #heat23:44
*** Drago has quit IRC23:44
*** dims_ has joined #heat23:47
*** dims has quit IRC23:50
*** achanda has joined #heat23:51
*** shakamunyi has quit IRC23:53
*** dims_ has quit IRC23:54
*** dims has joined #heat23:55
*** asalkeld__ is now known as asalkeld23:56
asalkeldMadkiss, ping23:56

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