*** mnaser has left #heat | 00:03 | |
*** ZZpablosan is now known as pablosan | 00:21 | |
*** matsuhashi has joined #heat | 00:25 | |
*** duncanjw has quit IRC | 01:15 | |
openstackgerrit | Cyril Roelandt proposed a change to openstack/python-heatclient: Python 3: decode bytes before feeding them to jsonutils.loads() https://review.openstack.org/78652 | 01:21 |
---|---|---|
*** duncanjw has joined #heat | 01:33 | |
*** nosnos has joined #heat | 01:36 | |
openstackgerrit | Lee Li proposed a change to openstack/python-heatclient: Using common methods from oslo cliutils https://review.openstack.org/67120 | 01:48 |
*** pablosan is now known as ZZpablosan | 01:59 | |
*** PhilK has quit IRC | 02:08 | |
*** PhilK has joined #heat | 02:10 | |
*** ZZpablosan is now known as pablosan | 02:11 | |
*** david-lyle has joined #heat | 02:14 | |
*** liang has joined #heat | 02:21 | |
*** rcleere has joined #heat | 02:52 | |
*** matsuhashi has quit IRC | 02:55 | |
*** ramishra has joined #heat | 03:02 | |
*** ramishra_ has joined #heat | 03:03 | |
*** ramishra has quit IRC | 03:07 | |
*** matsuhashi has joined #heat | 03:21 | |
*** nati_ueno has joined #heat | 03:23 | |
*** liang has quit IRC | 03:28 | |
*** nkhare has joined #heat | 03:31 | |
*** liang has joined #heat | 03:32 | |
*** duncanjw has joined #heat | 03:34 | |
*** duncanjw has quit IRC | 03:38 | |
*** liang has quit IRC | 03:39 | |
*** killer_p- has joined #heat | 03:52 | |
*** killer_p- is now known as killer_prince | 03:52 | |
*** lazy_prince has quit IRC | 03:53 | |
*** liang has joined #heat | 03:53 | |
*** pablosan is now known as ZZpablosan | 03:56 | |
openstackgerrit | Liang Chen proposed a change to openstack/heat: Tidy up urlfetch.py exception handling https://review.openstack.org/81960 | 04:13 |
*** killer_prince has quit IRC | 04:16 | |
*** liang has quit IRC | 04:17 | |
openstackgerrit | A change was merged to openstack/heat-templates: Remove tag to allow default resolved group id https://review.openstack.org/82158 | 04:18 |
*** killer_prince has joined #heat | 04:18 | |
openstackgerrit | A change was merged to openstack/heat-templates: Correct a few typos and remove nan workaround https://review.openstack.org/81425 | 04:19 |
*** fandi has joined #heat | 04:20 | |
*** Akshik has joined #heat | 04:21 | |
*** liang has joined #heat | 04:31 | |
*** cmyster has joined #heat | 04:36 | |
*** ramishra_ has quit IRC | 04:39 | |
*** mestery has joined #heat | 04:46 | |
*** nati_ueno has quit IRC | 04:46 | |
*** nati_ueno has joined #heat | 04:47 | |
*** nati_ueno has quit IRC | 04:51 | |
*** nati_ueno has joined #heat | 04:52 | |
openstackgerrit | A change was merged to openstack/python-heatclient: Python 3: Fix YamlEnvironmentTest tests https://review.openstack.org/77737 | 04:56 |
skraynev | Morning | 05:06 |
openstackgerrit | A change was merged to openstack/heat: Get rid of global variable in JSON->YAML conversion https://review.openstack.org/81096 | 05:09 |
*** ramishra has joined #heat | 05:11 | |
openstackgerrit | A change was merged to openstack/heat: Fix user provider template registration https://review.openstack.org/79953 | 05:13 |
*** chandankumar has quit IRC | 05:14 | |
*** mestery has quit IRC | 05:14 | |
openstackgerrit | Mitsuru Kanabuchi proposed a change to openstack/heat: Reimplement DHCPAgent as net's property https://review.openstack.org/81726 | 05:15 |
*** nosnos_ has joined #heat | 05:16 | |
*** nosnos has quit IRC | 05:19 | |
*** Akshik has quit IRC | 05:20 | |
*** Akshik has joined #heat | 05:20 | |
openstackgerrit | A change was merged to openstack/heat: Implement an identifier stack_path() https://review.openstack.org/80869 | 05:22 |
openstackgerrit | A change was merged to openstack/heat: Provide the necessary inputs to enable HEAT_SIGNAL https://review.openstack.org/80169 | 05:23 |
openstackgerrit | ChenZheng proposed a change to openstack/heat: Sort requirement files in alphabetical order https://review.openstack.org/76775 | 05:24 |
*** liang has quit IRC | 05:25 | |
*** chandan_kumar has joined #heat | 05:25 | |
openstackgerrit | A change was merged to openstack/python-heatclient: Using common methods from oslo cliutils https://review.openstack.org/67120 | 05:26 |
*** Akshik_ has joined #heat | 05:26 | |
*** Akshik has quit IRC | 05:26 | |
*** Akshik_ has quit IRC | 05:33 | |
*** duncanjw has joined #heat | 05:35 | |
*** Akshik has joined #heat | 05:35 | |
*** IlyaE has quit IRC | 05:39 | |
*** liang has joined #heat | 05:39 | |
*** duncanjw has quit IRC | 05:40 | |
*** Akshik has quit IRC | 05:41 | |
*** IlyaE has joined #heat | 05:43 | |
*** Akshik has joined #heat | 05:46 | |
*** sdake_ has quit IRC | 05:47 | |
*** Akshik has quit IRC | 05:53 | |
*** Akshik_ has joined #heat | 05:54 | |
*** Akshik_ has quit IRC | 05:57 | |
*** Akshik_ has joined #heat | 05:57 | |
*** matsuhas_ has joined #heat | 06:00 | |
*** matsuhashi has quit IRC | 06:01 | |
cmyster | morning | 06:03 |
openstackgerrit | Jenkins proposed a change to openstack/heat: Imported Translations from Transifex https://review.openstack.org/72566 | 06:09 |
*** cfriesen has quit IRC | 06:11 | |
*** mestery has joined #heat | 06:13 | |
*** mestery has quit IRC | 06:13 | |
*** mestery has joined #heat | 06:14 | |
*** nati_ueno has quit IRC | 06:14 | |
*** mestery_ has joined #heat | 06:15 | |
*** mestery has quit IRC | 06:15 | |
openstackgerrit | A change was merged to openstack/heat: Add documentation to the firewall properties https://review.openstack.org/77840 | 06:19 |
*** nosnos has joined #heat | 06:19 | |
*** mestery_ has quit IRC | 06:20 | |
*** nosnos_ has quit IRC | 06:22 | |
openstackgerrit | A change was merged to openstack/heat: Add more unit tests for ThreadGroupManager https://review.openstack.org/78286 | 06:23 |
openstackgerrit | A change was merged to openstack/python-heatclient: Sort requirement files in alphabetical order https://review.openstack.org/76812 | 06:27 |
*** matsuhas_ has quit IRC | 06:31 | |
*** matsuhashi has joined #heat | 06:31 | |
*** IlyaE has quit IRC | 06:32 | |
*** saju_m has joined #heat | 06:35 | |
*** liang has quit IRC | 06:52 | |
*** liang has joined #heat | 06:53 | |
*** duncanjw has joined #heat | 06:56 | |
*** saju_m has quit IRC | 06:59 | |
*** jprovazn has joined #heat | 07:04 | |
*** saju_m has joined #heat | 07:12 | |
*** saju_m has quit IRC | 07:17 | |
*** Tross1 has joined #heat | 07:17 | |
*** saju_m has joined #heat | 07:18 | |
*** nkhare_ has joined #heat | 07:19 | |
*** Akshik__ has joined #heat | 07:19 | |
*** nkhare has quit IRC | 07:19 | |
*** Tross has quit IRC | 07:19 | |
*** Akshik_ has quit IRC | 07:19 | |
*** saju_m has quit IRC | 07:22 | |
*** duncanjw has quit IRC | 07:22 | |
*** duncanjw has joined #heat | 07:22 | |
*** Akshik__ has quit IRC | 07:23 | |
*** ramishra has quit IRC | 07:24 | |
*** saju_m has joined #heat | 07:24 | |
*** saju_m has quit IRC | 07:30 | |
*** saju_m has joined #heat | 07:32 | |
*** liang has quit IRC | 07:35 | |
*** jistr has joined #heat | 07:38 | |
*** e0ne has joined #heat | 07:44 | |
*** e0ne has quit IRC | 07:47 | |
*** liang has joined #heat | 07:48 | |
*** tspatzier has joined #heat | 07:50 | |
*** jstrachan has joined #heat | 08:13 | |
therve | Good morning! | 08:16 |
*** bgorski has joined #heat | 08:19 | |
bgorski | Hi. Is there a way to control number of resources that are created in parallel? | 08:19 |
*** ramishra has joined #heat | 08:21 | |
*** pasquier-s has joined #heat | 08:21 | |
*** tomek_adamczewsk has joined #heat | 08:26 | |
*** tomek_adamczews1 has joined #heat | 08:30 | |
*** e0ne has joined #heat | 08:30 | |
*** tomek_adamczewsk has quit IRC | 08:30 | |
*** TonyBurn has joined #heat | 08:31 | |
*** duncanjw has quit IRC | 08:32 | |
*** alexheneveld has joined #heat | 08:33 | |
*** liang has quit IRC | 08:33 | |
*** jamie_h has joined #heat | 08:34 | |
lifeless | bgorski: the dag controls that implicitly, but no way beyond that that I know of | 08:34 |
openstackgerrit | Thomas Herve proposed a change to openstack/heat-templates: Add an example of native autoscaling resources https://review.openstack.org/82447 | 08:35 |
*** ifarkas has joined #heat | 08:35 | |
*** ramishra has quit IRC | 08:36 | |
bgorski | lifeless, We have something call ThreadGroup and it has pool_size. | 08:38 |
skraynev | therve: Woow. Great example of autoscaling group I will test it ;) | 08:39 |
skraynev | therve: Also what do you think about moving it in new separate directory, IMO lb template as sub-template for autoscaling little confusing. | 08:41 |
*** renlt has joined #heat | 08:42 | |
*** duncanjw has joined #heat | 08:42 | |
skraynev | therve: I mean that not all users could understand that they should also download additional template for using autoscaling | 08:42 |
*** alexheneveld has quit IRC | 08:42 | |
*** pas-ha has joined #heat | 08:45 | |
pas-ha | morning all :) | 08:46 |
*** alexheneveld has joined #heat | 08:47 | |
*** derekh has joined #heat | 08:57 | |
*** tomek_adamczews1 has quit IRC | 08:58 | |
therve | skraynev, Maybe. If you have the files locally, heat client should just work by passing the file for you (soon) | 08:58 |
*** jamie_h has quit IRC | 08:58 | |
therve | (using https://review.openstack.org/#/c/80528/) | 08:58 |
*** tomek_adamczewsk has joined #heat | 08:58 | |
*** jistr has quit IRC | 08:59 | |
*** jamie_h_ has joined #heat | 08:59 | |
*** jamie_h_ has quit IRC | 09:00 | |
*** liang has joined #heat | 09:04 | |
lsmola_ | shardy: hello, are you around | 09:08 |
lsmola_ | shardy: ? | 09:08 |
*** mkollaro has joined #heat | 09:11 | |
shardy | morning all | 09:12 |
shardy | lsmola_: Hi! | 09:12 |
cmyster | morning | 09:12 |
lsmola_ | shardy: good morning | 09:13 |
lsmola_ | shardy: was you way back good? | 09:13 |
skraynev | therve: yeap, it works. I just want to say, that it's uncomfortable in case , when you start stack using only url link on repository. | 09:14 |
lsmola_ | shardy: I think I had enough beer and meat for this year :-D | 09:14 |
lsmola_ | shardy: I have one tiny question about http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::UpdateWaitConditionHandle | 09:14 |
cmyster | lsmola_: no such thing :) | 09:14 |
therve | skraynev, Hum yeah interesting. That could work too though | 09:14 |
lsmola_ | :-) | 09:14 |
lsmola_ | shardy: can I use one handle for multiple completion conditions? | 09:15 |
shardy | lsmola_: haha, yeah likewise, although I still ended up at a beer festival on Saturday night ;) | 09:15 |
shardy | lsmola_: Yes you can specify a count | 09:15 |
cmyster | lsmola_: in what syntax? | 09:15 |
cmyster | but ^ | 09:16 |
*** jistr has joined #heat | 09:16 | |
shardy | lsmola_: http://docs.openstack.org/developer/heat/template_guide/cfn.html#AWS::CloudFormation::WaitCondition | 09:16 |
lsmola_ | shardy: cmyster example http://paste.openstack.org/show/74113/ | 09:16 |
shardy | You must pass a different UniqueId value for each bit of data passed to the Handle | 09:17 |
cmyster | this, is long | 09:18 |
lsmola_ | shardy: I am not really sure I get that :-) | 09:19 |
shardy | lsmola_: basically you just need to specify a Count of $n in the WaitCondition Properties, then pass several signals, e.g via cfn-signal -i '0001' && cfn-signal -i '0002' | 09:19 |
lsmola_ | shardy: zaneb pointed me to this https://bugs.launchpad.net/tripleo/+bug/1291905 | 09:19 |
uvirtbot | Launchpad bug 1291905 in tripleo "heat stack-update fails on timeout" [High,Triaged] | 09:19 |
lsmola_ | shardy: so in the example template above ^ I just define count 4 in each compute condition? | 09:21 |
lsmola_ | shardy: and when every compute condition will sent it once it will work? | 09:21 |
cmyster | btw there's a new bug I was wondering about when I defin a parameter with type: Boolean and engine will complain about this type. I did define this Type: string and default: true to pass it as I wanted | 09:22 |
cmyster | define* | 09:22 |
shardy | lsmola_: Yes, you define one WaitCondition, one WaitConditionHandle, have each thing send one signal (with a different UniqueId) and the WaitCondition won't go CREATE_COMPLETE until it's rx'd 4 signals | 09:22 |
lsmola_ | shardy: it defines number of signals the handle must receive? | 09:22 |
shardy | lsmola_: yes that's what "Count" does | 09:23 |
openstackgerrit | Dong Liu proposed a change to openstack/heat: router add dependence to subnet https://review.openstack.org/82452 | 09:23 |
*** IgorYozhikov has joined #heat | 09:23 | |
lsmola_ | shardy: so in the example above, there are 4 different Conditions, but 1 handle (defined four times, but it is still the same), is that correct? | 09:25 |
lsmola_ | shardy: or the handle needs to be defined separately? | 09:25 |
shardy | lsmola_: No, you only ever associate one Handle with one condition | 09:25 |
shardy | so you can either have 4 handles and 4 conditions, or 1 handle, and 1 condition with a "Count" of 4 | 09:26 |
lsmola_ | shardy: hm | 09:26 |
lsmola_ | shardy: so I am trying to figure out what zaneb means here https://bugs.launchpad.net/tripleo/+bug/1291905 | 09:26 |
uvirtbot | Launchpad bug 1291905 in tripleo "heat stack-update fails on timeout" [High,Triaged] | 09:26 |
lsmola_ | shardy: basically it works only when I use one handle for all | 09:26 |
*** e0ne_ has joined #heat | 09:27 | |
lsmola_ | shardy: 'works' cause it has already created resource so the handle condition is not failing on that | 09:27 |
*** dteselkin has joined #heat | 09:27 | |
lsmola_ | shardy: it's the #10 comment | 09:28 |
shardy | lsmola_: I don't really see how that's related to what we're discussing, which is multiple conditions and/or signals? | 09:29 |
shardy | zaneb is suggesting the UpdateWaitConditionHandle may work around your signal failure on update issue, because we replace the handle, instead of reusing the one from the "old" stack | 09:29 |
*** e0ne has quit IRC | 09:29 | |
shardy | ergo, it's in the new stack when you need it, so should work (probably) | 09:30 |
lsmola_ | shardy: hm | 09:30 |
lsmola_ | shardy: but still when I add new resource with Compute1ConditionHandle | 09:31 |
lsmola_ | shardy: it doesn't see that handle, cause it is only in the new template | 09:32 |
lsmola_ | shardy: so 'That should ensure you can always access it, since its always in the template (with the same name).' | 09:32 |
lsmola_ | shardy: I got that like I should have the Handle in the template named the same | 09:33 |
lsmola_ | shardy: so it is always there | 09:33 |
shardy | lsmola_: Ok, so you're using one consistently named handle, with multiple WaitCondition resources? | 09:34 |
lsmola_ | shardy: trying that :-) | 09:35 |
lsmola_ | shardy: though that will not probably work correctly :-) | 09:35 |
*** lindsayk has joined #heat | 09:35 | |
lsmola_ | shardy: and with adding two resources it failed for me | 09:35 |
*** renlt has quit IRC | 09:35 | |
*** lindsayk has quit IRC | 09:36 | |
lsmola_ | shardy: even when all events are correctly completed | 09:36 |
*** alienyyg has quit IRC | 09:36 | |
*** alienyyg has joined #heat | 09:36 | |
shardy | lsmola_: Yeah it won't work, because the signal data is stored with the Handle not the Condition | 09:37 |
lsmola_ | shardy: hmm right, that would explain why adding one works, but adding two not | 09:38 |
lsmola_ | shardy: so is hack like this possible some other way? | 09:39 |
shardy | lsmola_: tbh I'm not sure - you're probably best updating the bug with details of what you've tried and continuing your discussion with zaneb | 09:40 |
shardy | lsmola_: I'll try a few things later this morning and see if I can offer any suggestions too | 09:41 |
lsmola_ | shardy: ok, cool, thank you very much | 09:41 |
lsmola_ | shardy: one last question | 09:42 |
lsmola_ | shardy: can I define the handle and the completion condition once | 09:43 |
lsmola_ | shardy: and then somehow reference it from Compute resources? | 09:43 |
lsmola_ | shardy: so every COmpute will call it once? | 09:43 |
shardy | lsmola_: yes, you could create one WaitCondition, one UpdateWaitConditionHandle, and pass the reference to the same handle into each compute resource | 09:45 |
shardy | Then you specify "Count" of the WaitCondition to match the number of compute resources you expect signals from | 09:45 |
shardy | as I mentioned, you will need some way to pass a different unique ID (e.g the resource name) | 09:45 |
shardy | https://github.com/openstack/heat/blob/master/heat/engine/resources/wait_condition.py#L76 | 09:46 |
lsmola_ | shardy: so this would be just a property of the specific WaitCondition with reference to the one WaitCondition? | 09:48 |
lsmola_ | shardy: or? :-) | 09:48 |
shardy | lsmola_: give me 5mins to make another coffee and I'll make a template example for you | 09:48 |
lsmola_ | shardy: can I just past parameteters with ref: ? | 09:48 |
lsmola_ | shardy: excellent, thank you very much | 09:49 |
openstackgerrit | Chmouel Boudjnah proposed a change to openstack/heat: Fix creating container. https://review.openstack.org/82457 | 09:54 |
* lsmola_ is going to lunch | 09:56 | |
openstackgerrit | Dong Liu proposed a change to openstack/heat: Add subnets as a dependency for router https://review.openstack.org/82452 | 09:59 |
openstackgerrit | Chmouel Boudjnah proposed a change to openstack/heat: Display container ip not gateway IP https://review.openstack.org/82458 | 10:00 |
therve | chmouel, The privileged thing depends on docker version :/ | 10:07 |
chmouel | therve: really? i could not find it in the docker-py git history | 10:07 |
*** DaveJ__ has joined #heat | 10:07 | |
therve | chmouel, https://github.com/dotcloud/docker-py/commit/64781888e06824f6beac5a6ccc4afd85109ecf30#diff-5262437d121a30fc85a81c4b1da57e4b | 10:07 |
chmouel | therve: should we just 'fix' the requirement file or do some silly introspection to handle that case? | 10:08 |
therve | Not sure | 10:09 |
chmouel | or just assume master i guess | 10:09 |
DaveJ__ | Hi guys, I'm having trouble using cloud-init data in the user-data section of my heat templates. I write a script starting with #cloud-config or Content-Type: text/cloud-config but each time cfn seems to be creating a multipart and setting it's content type to cfninitdata | 10:09 |
DaveJ__ | Is there anyway to override this ? | 10:09 |
therve | chmouel, I think at the very least I would only pass it if the value is True | 10:09 |
therve | This way it works with the older version on the default case | 10:09 |
therve | DaveJ__, You need to use user_data_format to RAW | 10:09 |
chmouel | therve: true true but in that case that would need to be done for every other resources | 10:09 |
cmyster | brb f00d | 10:09 |
therve | chmouel, "that" what? | 10:10 |
DaveJ__ | therve: What is 'user_data_format to RAW' do you have an example ? | 10:10 |
therve | DaveJ__, https://github.com/openstack/heat-templates/blob/69608faeedb474a4597f965786a1a1d2ac475899/hot/software-config/example-cloud-init.yaml#L98 | 10:10 |
chmouel | therve: that mean if we do 'that' way :) | 10:11 |
therve | chmouel, Other projects care about backward compatibility in general :) | 10:11 |
therve | It's certainly a docker bug to break that way. We don't have to create a general policy for it, though. | 10:12 |
DaveJ__ | therve: I'm using AWS templates, do I need to convert them to use OS::Nova::Server instead ? | 10:16 |
DaveJ__ | Initally I'm getting a validation error when I try to launch | 10:16 |
therve | Yes | 10:16 |
sgran | DaveJ__: mostly the AWS templates work. The native resources tend to be more feature complete, however | 10:16 |
therve | templates != resources though | 10:16 |
therve | You can use OS::Nova::Server in a CFN template | 10:16 |
sgran | true | 10:17 |
DaveJ__ | But to keep compatibility, as I launch this on AWS and Openstack, can I use my existing CF template, with the EC2 resource and specifiy cloud-init data ? | 10:17 |
DaveJ__ | I'm guessing not ? | 10:18 |
*** aignatov is now known as bucash | 10:20 | |
*** bucash is now known as aignatov | 10:20 | |
therve | Looks like you're asking a bit too much :) | 10:21 |
*** jistr has quit IRC | 10:24 | |
DaveJ__ | therve: Fair enough. Although do you think specifying a #cloud-config script instead of a shell script might be a fairly common thing to use "UserData" for ? | 10:26 |
*** jistr has joined #heat | 10:27 | |
shardy | DaveJ__: If you can pass data direct to cloud-init via the AWS resource on CloudFormation, you can raise a bug and we can attempt to align the AWS-compatible resource with that behavior | 10:27 |
shardy | DaveJ__: The native OS::Nova::Server resource is preferred for users who don't require portability to CFN tho | 10:28 |
DaveJ__ | shardy: Yep that makes sense. | 10:28 |
shardy | DaveJ__: The intention is to allow portability when using the CFN templates/resources, so even if we can't fix it immediately, it will be good to know where stuff doesn't work | 10:29 |
therve | DaveJ__, I don't know what the behavior in AWS. Is UserData not handled by cfn there? | 10:30 |
DaveJ__ | therve: I didn't think so - but let me just verify that. | 10:30 |
*** matsuhashi has quit IRC | 10:33 | |
*** matsuhas_ has joined #heat | 10:35 | |
*** duncanjw has quit IRC | 10:37 | |
*** david-lyle has quit IRC | 10:41 | |
lsmola_ | shardy: wait, this hack works, it was just my local keystone error previously | 10:44 |
*** duncanjw has joined #heat | 10:45 | |
lsmola_ | shardy: so given template like this http://paste.openstack.org/show/74121/ | 10:45 |
lsmola_ | shardy: for update, I am adding resources Compute1 and Compute2 | 10:46 |
lsmola_ | shardy: and they use handle that is named the same | 10:46 |
*** alienyyg has quit IRC | 10:48 | |
lsmola_ | shardy: seems like it is building one handle with deps to all conditions http://paste.openstack.org/show/74122/ | 10:48 |
*** alienyyg has joined #heat | 10:48 | |
lsmola_ | shardy: so I am not sure what hack I found, but it works :-) seems like the handle is not that significant or I found bug :-D | 10:49 |
*** fandi has quit IRC | 10:49 | |
shardy | lsmola_: well all of the WaitConditions will just complete when the first signal hits the Handle, so it's not exactly working.. ;) | 10:50 |
lsmola_ | shardy: hmm, but some other thing forces it to wait for all instances to be up | 10:51 |
lsmola_ | shardy: e.g. the NovaCompute1 resource was added only when nova cmopute 1 was finished | 10:51 |
lsmola_ | shardy: so seems like there is another condition, that makes this work :-) | 10:52 |
openstackgerrit | huangtianhua proposed a change to openstack/heat: Fix stack-show failed with a name in uuid format https://review.openstack.org/82471 | 10:52 |
lsmola_ | shardy: or at least when I track how are the resoruces marked complete, this still works, even when handle does not :-) | 10:52 |
*** liang has quit IRC | 10:53 | |
lsmola_ | shardy: hm also the completion conditions seems to have different timestamp | 10:54 |
lsmola_ | shardy: could it be that it actually waits on the nova instance? not just the handle? | 10:54 |
lsmola_ | shardy: hm, I hate when something should not be working but it is :-D or it pretends to be :-D | 10:55 |
shardy | lsmola_: it's a perplexing phenomenon called "luck" :D | 10:56 |
lsmola_ | shardy: hehe | 10:56 |
*** mkollaro has quit IRC | 10:56 | |
*** nkhare_ has quit IRC | 10:57 | |
lsmola_ | shardy: so what data does the handle have? from it's details it seems none, that all signal data are in the completion condition, and handle just handles it | 10:57 |
shardy | lsmola_: no, the data is stored in metadata associated with the Handle resource, not the condition | 10:58 |
shardy | the implementation is a bit weird, as it would be better if the data was associated with the Condition, but it's not | 10:58 |
lsmola_ | shardy: I see, the signal knows only about the handle | 11:00 |
shardy | Yeah and internally, the WaitCondition looks at the data associated with the Handle | 11:01 |
lsmola_ | shardy: but if you look at the event list http://paste.openstack.org/show/74124/ | 11:01 |
lsmola_ | shardy: the completion conditions wait on all dependencies somehow :-) | 11:02 |
lsmola_ | shardy: so it is not the first handle to completes them, but the last more likely | 11:02 |
* lsmola_ is confused | 11:02 | |
lsmola_ | shardy: so internally means the handle will complete all dependencies if the signal count is right? | 11:05 |
lsmola_ | shardy: what if you have 5 conditions as dependencies, is the count 5 then? | 11:06 |
shardy | lsmola_: I don't really understand "5 conditions as dependencies" | 11:07 |
lsmola_ | shardy: http://paste.openstack.org/show/74122/ | 11:07 |
*** matsuhas_ has quit IRC | 11:07 | |
lsmola_ | shardy: the relations is the required by, right? | 11:07 |
lsmola_ | shardy: so I wonder how handle counts how many signals does it have to receive | 11:08 |
lsmola_ | shardy: if it sums all the related conditions, this could be a hidden feature :-D | 11:09 |
lsmola_ | shardy: or the reason why it is completed after last handle might be elsewhere :-) | 11:10 |
*** mkollaro has joined #heat | 11:19 | |
*** nosnos has quit IRC | 11:23 | |
*** alienyyg has quit IRC | 11:27 | |
*** alienyyg has joined #heat | 11:28 | |
*** chandankumar_ has joined #heat | 11:29 | |
shardy | lsmola_: http://paste.fedoraproject.org/88017/60519139 | 11:29 |
shardy | You will see that wait_condition2 takes 60s longer to complete that wait_condition, beacuse of the Count | 11:29 |
*** sergmelikyan has joined #heat | 11:32 | |
*** alexheneveld_ has joined #heat | 11:37 | |
*** _ruhe_ has joined #heat | 11:37 | |
*** _ruhe_ has quit IRC | 11:38 | |
*** alexheneveld has quit IRC | 11:38 | |
*** alexheneveld_ is now known as alexheneveld | 11:38 | |
*** _ruhe_ has joined #heat | 11:38 | |
lsmola_ | shardy: hm, can you try example with 2 conditions using the same handle? | 11:38 |
lsmola_ | shardy: whether it waits for one handle or two | 11:39 |
lsmola_ | shardy: can't find code that is deciding that | 11:39 |
shardy | lsmola_: Well I have already said that won't work, and I linked the exact code which showed why.. | 11:39 |
lsmola_ | shardy: :-) I am just trying to understand why it is working for me :-) | 11:40 |
shardy | https://github.com/openstack/heat/blob/master/heat/engine/resources/wait_condition.py#L77 | 11:40 |
shardy | lsmola_: OK I'll try with my example, but then I have to get on with some other stuff ;) | 11:40 |
lsmola_ | shardy: ok, cool, thanks for the help :-) we would really need to have this fixed in Icehouse | 11:41 |
lsmola_ | shardy: so I need to find the less ugliest hack :-) | 11:42 |
DaveJ__ | shardy: therve: I was pretty sure this worked, so quickly booted a cloud formation template on AWS. | 11:42 |
DaveJ__ | https://www.irccloud.com/pastebin/c9WtvOkK | 11:42 |
*** alexheneveld_ has joined #heat | 11:43 | |
DaveJ__ | This works, and executes the cloud-config script, creating the file in /tmp. | 11:43 |
DaveJ__ | https://www.irccloud.com/pastebin/q2EJQiRy | 11:43 |
*** aweiteka has joined #heat | 11:44 | |
DaveJ__ | Under /var/lib/cloud/data it extracts the 'cloud-config' into a seperate script called 'cloud-config.txt' which is executed. | 11:44 |
DaveJ__ | I guess this is the equivalent of the user_data_type = raw, but the default. I can create a blueprint for this if it makes sense ? | 11:44 |
*** alexheneveld has quit IRC | 11:44 | |
*** alexheneveld_ is now known as alexheneveld | 11:44 | |
*** randallburt has joined #heat | 11:45 | |
*** randallburt has quit IRC | 11:45 | |
shardy | lsmola_: http://paste.fedoraproject.org/88020/56615341 | 11:46 |
*** randallburt has joined #heat | 11:46 | |
openstackgerrit | A change was merged to openstack/heat: Don't re-bind parameters during stack update https://review.openstack.org/81678 | 11:46 |
shardy | as I said earlier, both conditions will complete as soon as the first signal hits the handle | 11:46 |
shardy | lsmola_: I think your workaround is to use UpdateWaitConditionHandle, and probably also to use Count | 11:46 |
*** faramir1 has joined #heat | 11:47 | |
shardy | lsmola_: if you think that won't work, please update the bug with some minimal examples (based on what I just pasted) and steps to reproduce | 11:47 |
shardy | lsmola_: one of the barriers atm is the complexity of your template examples, so we really need some simple reproducers | 11:47 |
lsmola_ | shardy: ok, so it has to be something else in dependency chain that prevents it from completing | 11:48 |
openstackgerrit | Jenkins proposed a change to openstack/heat: Updated from global requirements https://review.openstack.org/76689 | 11:48 |
shardy | DaveJ__: If it works on cfn but not heat, please raise a bug with details and we can try to look into it | 11:48 |
therve | DaveJ__, It's a bit weird that we don't have the same default behavior as AWS | 11:48 |
lsmola_ | shardy: yeah it will get better when rewritten to provider resource and hot software config | 11:48 |
lsmola_ | shardy: ok, thanks for the help, I am going to investigate this more | 11:49 |
therve | If there is no AWS::CloudFormation::Init maybe we should default to RAW there | 11:50 |
DaveJ__ | therve: I think the issue/problem stems from the fact heat constructs a multi-part passed to cloud-init, where as CF in AWS just seems to pass the UserData through 'raw' every-time, so you can create a multi-part yourself, or just embed one of the supported scripts. | 11:50 |
DaveJ__ | therve: That would be a good quick fix that would suit me. I might see if I can create a patch to test that out. | 11:51 |
*** matsuhashi has joined #heat | 11:53 | |
*** nosnos has joined #heat | 11:54 | |
openstackgerrit | Jenkins proposed a change to openstack/python-heatclient: Updated from global requirements https://review.openstack.org/76698 | 11:54 |
*** rpothier has quit IRC | 11:56 | |
*** networkn8 has joined #heat | 12:00 | |
*** rbuilta has joined #heat | 12:11 | |
*** chandankumar_ has quit IRC | 12:13 | |
*** matsuhashi has quit IRC | 12:14 | |
*** lipinski has joined #heat | 12:14 | |
therve | shardy, Have you seen my comment on https://review.openstack.org/#/c/80034/ ? | 12:16 |
*** matsuhas_ has joined #heat | 12:17 | |
shardy | therve: which comment? I replied to your loglevel remark? | 12:18 |
therve | Did you? Hum I missed it | 12:19 |
therve | Ah yeah thanks | 12:19 |
shardy | therve: I think maybe you missed the switch to default log level of WARNING in https://review.openstack.org/#/c/79487/2 | 12:19 |
shardy | :) | 12:19 |
therve | OK cool | 12:20 |
openstackgerrit | Sergey Kraynev proposed a change to openstack/heat: Initial validation of functions https://review.openstack.org/82486 | 12:21 |
openstackgerrit | Sergey Kraynev proposed a change to openstack/heat: Validation functions for resources and outputs https://review.openstack.org/82487 | 12:21 |
openstackgerrit | Sergey Kraynev proposed a change to openstack/heat: Adding validation algorithm for get attr functions https://review.openstack.org/82488 | 12:21 |
*** e0ne_ has quit IRC | 12:24 | |
*** radez_g0n3 is now known as radez | 12:26 | |
*** ZZpablosan is now known as pablosan | 12:33 | |
*** rpothier has joined #heat | 12:36 | |
* IgorYozhikov is now away: went away... | 12:44 | |
*** IgorYozhikov is now known as IYozhikov_away | 12:44 | |
*** networkn81 has joined #heat | 12:45 | |
*** networkn8 has quit IRC | 12:48 | |
*** e0ne has joined #heat | 12:55 | |
*** denis_makogon has joined #heat | 12:57 | |
*** e0ne has quit IRC | 12:59 | |
*** alexpilotti has quit IRC | 13:00 | |
*** rbuilta has quit IRC | 13:07 | |
*** e0ne has joined #heat | 13:11 | |
*** matsuhas_ has quit IRC | 13:12 | |
*** matsuhashi has joined #heat | 13:13 | |
openstackgerrit | Pavlo Shchelokovskyy proposed a change to openstack/python-heatclient: Use correct order of arguments to assertEqual https://review.openstack.org/82498 | 13:14 |
*** matsuhashi has quit IRC | 13:17 | |
*** cmyster has quit IRC | 13:19 | |
*** BillArnold_ has quit IRC | 13:21 | |
tspatzier | Hi all, I was having a look at the Heat API documentation at http://api.openstack.org/api-ref-orchestration.html and realised that most of the GET operations are document with "This operation does not return a response body". Is this an issue in the way how the docs get generated? I mean, obviously GET usually returns a response body. | 13:23 |
*** rustlebee is now known as russellb | 13:23 | |
*** nosnos has quit IRC | 13:24 | |
*** nosnos has joined #heat | 13:25 | |
*** radez is now known as radez_g0n3 | 13:25 | |
randallburt | tspatzier: the api docs are generated from the wadl, so yeah, I think it may be an issue with the wadl? | 13:28 |
*** nosnos has quit IRC | 13:29 | |
tspatzier | randallburt: thanks, got it. Has anyone else raised this questions before? I.e. should we fix something, or am I just mis-reading it? | 13:31 |
randallburt | tspatzier: haven't heard it come up before, but sounds like a bug to me. | 13:31 |
tspatzier | I actually never had a look at the API docs but just used the API :-) But a colleague pinged me and was confused by all/most GETs returning nothing according to the docs. | 13:32 |
*** jcru has joined #heat | 13:32 | |
randallburt | tspatzier: yeah, it sounds a little confusing. there's are missing request/response examples too last time I looked. | 13:33 |
*** mwheckmann has joined #heat | 13:34 | |
tspatzier | randallburt: where are we in the Icehouse release cycle to fix this? I'm not too deep into the processes. Sometimes seems to me like for decimation or stuff that might be subject to i18n there are custom dates? | 13:35 |
tspatzier | s/custom/cut-off/ | 13:35 |
randallburt | tspatzier: I don't think the cutoff for docs is the same as for FF. IMO, this sounds like a bug in any case, so IMO its fine to file and fix. | 13:36 |
randallburt | afa i18n, I'm not sure. | 13:36 |
openstackgerrit | Sergey Kraynev proposed a change to openstack/heat: Validation functions for resources and outputs https://review.openstack.org/82487 | 13:37 |
openstackgerrit | Sergey Kraynev proposed a change to openstack/heat: Adding validation algorithm for get attr functions https://review.openstack.org/82488 | 13:38 |
tspatzier | Ok, I'll file a bug. Just wanted to hear somebody confirm I am not completely mis-understanding ;-) I can also see what of the definitions I can work on. Might need some input on some. | 13:38 |
*** faramir1 has quit IRC | 13:38 | |
randallburt | tspatzier: k. sounds good to me. | 13:43 |
*** jrist has joined #heat | 13:44 | |
*** radez_g0n3 is now known as radez | 13:46 | |
openstackgerrit | Chmouel Boudjnah proposed a change to openstack/heat: Fix creating docker containers https://review.openstack.org/82457 | 13:49 |
*** daneyon has joined #heat | 13:51 | |
*** daneyon has quit IRC | 13:52 | |
*** daneyon has joined #heat | 13:52 | |
*** rcleere has quit IRC | 13:54 | |
*** wchrisj has joined #heat | 13:54 | |
*** pas-ha has quit IRC | 13:56 | |
*** daneyon_ has joined #heat | 13:58 | |
*** daneyon has quit IRC | 13:58 | |
*** nosnos has joined #heat | 13:58 | |
*** matsuhashi has joined #heat | 13:59 | |
*** daneyon_ has quit IRC | 13:59 | |
*** nosnos has quit IRC | 14:00 | |
*** nosnos has joined #heat | 14:01 | |
*** aweiteka has quit IRC | 14:02 | |
*** vijendar has joined #heat | 14:02 | |
openstackgerrit | Chmouel Boudjnah proposed a change to openstack/heat: Display container ip not gateway IP https://review.openstack.org/82458 | 14:05 |
*** nosnos has quit IRC | 14:05 | |
*** cfriesen has joined #heat | 14:07 | |
*** nosnos has joined #heat | 14:11 | |
*** varora has left #heat | 14:11 | |
*** skraynev is now known as skraynev_afk | 14:12 | |
*** varora has joined #heat | 14:13 | |
*** alienyyg has quit IRC | 14:13 | |
*** nosnos has quit IRC | 14:14 | |
openstackgerrit | Chmouel Boudjnah proposed a change to openstack/heat: Display container ip not gateway IP https://review.openstack.org/82458 | 14:16 |
*** matsuhashi has quit IRC | 14:16 | |
*** rwsu has joined #heat | 14:17 | |
*** aweiteka has joined #heat | 14:17 | |
openstackgerrit | Chmouel Boudjnah proposed a change to openstack/heat: Add docker network_gateway attribute https://review.openstack.org/82511 | 14:18 |
openstackgerrit | A change was merged to openstack/python-heatclient: Output warnings for deprecated commands https://review.openstack.org/80034 | 14:20 |
*** ramishra has joined #heat | 14:21 | |
openstackgerrit | Chmouel Boudjnah proposed a change to openstack/heat: Display container ip not gateway IP https://review.openstack.org/82458 | 14:24 |
*** rcleere has joined #heat | 14:27 | |
*** matsuhashi has joined #heat | 14:32 | |
chmouel | is there a --force cleanup kind of thing when a resource cannot fail to get cleaned for some reason? | 14:37 |
shardy | chmouel: can you expand on the requirement? For delete you should just be able to re-try the delete until you fix the error and it works | 14:38 |
chmouel | shardy: well as an example I am trying out the docker container which failed to start for some reason | 14:38 |
chmouel | shardy: if i want to try to delete it would just say cannot delete since it doesn't exist | 14:39 |
chmouel | shardy: is it by design or it needs a fix in the docker client ? | 14:39 |
shardy | chmouel: that's a bug, most resources tolerate NotFound exceptions and treat it as a successful delete | 14:39 |
*** saju_m has quit IRC | 14:39 | |
chmouel | shardy: ok cool make sense | 14:39 |
chmouel | shardy: will log a bug/fix | 14:39 |
*** cmyster has joined #heat | 14:41 | |
*** cmyster has joined #heat | 14:41 | |
shardy | chmouel: Yeah, there should be a try/catch around the kill here: | 14:41 |
shardy | https://github.com/openstack/heat/blob/master/contrib/docker/docker/resources/docker_container.py#L243 | 14:41 |
chmouel | shardy: yep, thanks! | 14:42 |
*** david-lyle has joined #heat | 14:43 | |
*** zns has joined #heat | 14:45 | |
*** radez is now known as radez_g0n3 | 14:47 | |
*** dims has quit IRC | 14:47 | |
openstackgerrit | Chmouel Boudjnah proposed a change to openstack/heat: Display container ip not gateway IP https://review.openstack.org/82458 | 14:52 |
*** wchrisj has quit IRC | 14:54 | |
*** IlyaE has joined #heat | 14:56 | |
*** pas-ha has joined #heat | 14:58 | |
pas-ha | chmouel: where is the actual code of docker client that is supposed to be used by docker resource? this one - https://github.com/dotcloud/docker-py ? | 14:59 |
*** samstav has joined #heat | 14:59 | |
pas-ha | would like to take a look | 14:59 |
*** kgriffs_afk is now known as kgriffs | 15:00 | |
*** dims has joined #heat | 15:00 | |
*** radez_g0n3 is now known as radez | 15:01 | |
*** duncanjw_ has joined #heat | 15:05 | |
*** jmckind has joined #heat | 15:06 | |
*** duncanjw has quit IRC | 15:06 | |
cmyster | shardy: spare 5 minutes ? | 15:07 |
shardy | cmyster: sure | 15:09 |
openstackgerrit | Dong Liu proposed a change to openstack/heat: Add subnets as a dependency for router https://review.openstack.org/82452 | 15:09 |
*** mspreitz has joined #heat | 15:12 | |
*** duncanjw_ has quit IRC | 15:13 | |
SpamapS | zaneb: https://bugs.launchpad.net/tripleo/+bug/1291905 <-- lsmola_ has explained this to me now | 15:14 |
uvirtbot | Launchpad bug 1291905 in tripleo "heat stack-update fails on timeout" [High,Triaged] | 15:14 |
SpamapS | zaneb: there is a bug | 15:14 |
SpamapS | zaneb: the problem is that during an update, new wait condition handles cannot be accessed | 15:14 |
SpamapS | zaneb: updatewaitconditionhandle isn't really "the answer".. it is a workaround. | 15:15 |
zaneb | SpamapS: yes, I'm aware of that | 15:15 |
openstackgerrit | Cyril Roelandt proposed a change to openstack/python-heatclient: Do not use the '+' operation dict_items() https://review.openstack.org/82523 | 15:15 |
SpamapS | zaneb: seems like we could fix the code path to not look up the new handle through the old template | 15:15 |
zaneb | "I believe the workaround is to use the OS::Heat::UpdateWaitConditionHandle..." | 15:15 |
lsmola_ | zaneb: SpamapS problme is I don't know how to use this workaround | 15:15 |
SpamapS | zaneb: yeah, but I didn't fully understand | 15:15 |
zaneb | lsmola_: I'm writing a comment as we speak | 15:15 |
SpamapS | lsmola_: the workaround is as you said.. use one handle, and update the count | 15:15 |
lsmola_ | zaneb: did you mean to use only one Condition and Handle ? with count attr, like shardy showed me http://paste.fedoraproject.org/88017/60519139/ | 15:16 |
SpamapS | but that seems like a fairly straight forward bug to fix in our API .. with a stack and a resource name we should be able to find metadata if it is CREATE_COMPLETE .. we should not need the template. | 15:16 |
zaneb | SpamapS: will the existing server post to the WaitConditionHandle again during an update, even though it isn't being replaced? | 15:16 |
SpamapS | zaneb: we're not replacing a server | 15:16 |
zaneb | i.e. do we need to increase the Count when adding a server? | 15:16 |
SpamapS | And don't plan to ever use that. | 15:17 |
SpamapS | We create, rebuild, or delete. | 15:17 |
zaneb | SpamapS: right, so we have NovaCOmpute0 already, and we add NovaCompute1. Do we need to (/can we) increase the Count to 2 on the WaitCondition, or do we just move it from Server0 to Server1? | 15:18 |
lsmola_ | zaneb: SpamapS btw. also this worked for me, even when it should't https://review.openstack.org/#/c/82479/1 | 15:18 |
SpamapS | zaneb: We want a condition per server | 15:19 |
lsmola_ | zaneb: SpamapS due to the our dependencies, it actually waits for all computes | 15:19 |
SpamapS | zaneb: in software-config, that's what we'll have | 15:19 |
SpamapS | hm | 15:19 |
SpamapS | that makes me think | 15:19 |
SpamapS | perhaps the answer is "just use software-config" | 15:19 |
SpamapS | Because those conditions are tied to the config resource + server ... not a specific handle. | 15:20 |
zaneb | SpamapS: how can we have a condition per server, if we're adding a server but can't add conditions? | 15:20 |
SpamapS | zaneb: we did add a condition | 15:20 |
*** beekneemech is now known as bnemec | 15:20 | |
SpamapS | zaneb: and it is not accessible | 15:20 |
zaneb | sorry, can't access new handles | 15:20 |
SpamapS | zaneb: because we try to load it via the old template | 15:20 |
lsmola_ | SpamapS: well with ResourceGroup, we will have only one condotion with count most probably | 15:20 |
zaneb | which is the only one in the database | 15:20 |
SpamapS | which is, I think, a straight forward bug | 15:20 |
lsmola_ | SpamapS: or AutoscalingGroup | 15:21 |
SpamapS | zaneb: we have a stack + resource name in the db | 15:21 |
SpamapS | it is CREATE_COMPLETE | 15:21 |
lsmola_ | SpamapS: cause we won't be copypasting the resources | 15:21 |
zaneb | SpamapS: https://bugs.launchpad.net/tripleo/+bug/1291905/comments/7 | 15:21 |
uvirtbot | Launchpad bug 1291905 in tripleo "heat stack-update fails on timeout" [High,Triaged] | 15:21 |
SpamapS | lsmola_: no, we will have a stack per, because software-config does that :) | 15:21 |
zaneb | SpamapS: lsmola_ investigated this already, and it is a bear to fox :( | 15:21 |
zaneb | s/fox/fix/ | 15:22 |
SpamapS | Yeah, this is the same old problem. | 15:22 |
SpamapS | not storing the template snippets with the resources | 15:22 |
SpamapS | damnit | 15:22 |
* lsmola_ scratches his head | 15:22 | |
zaneb | once upon a time we used to store the template snippets with the resources | 15:23 |
SpamapS | This will likely cause the same problem in software-config too | 15:23 |
SpamapS | zaneb: _what_ ? | 15:23 |
zaneb | then I killed it | 15:23 |
* SpamapS braces for where zaneb explains how this jerk SpamapS raised hell about it a year ago | 15:23 | |
SpamapS | oh good | 15:23 |
zaneb | because it seemed like we were storing heaps of redundant data | 15:24 |
SpamapS | turns out, worthwhile data. :-/ | 15:24 |
lsmola_ | SpamapS: we should have a group of e.g. nova computes with just number how many we want, right? in the template | 15:24 |
lsmola_ | SpamapS: so it should be one code, with one template, etc. | 15:24 |
SpamapS | lsmola_: looks like we'll have to work that way. But I'm worried that we will fall back on this when we convert to using OS::Heat::SoftwareConfig to abstract away our wait conditions. | 15:24 |
SpamapS | zaneb: and really, you need the snippet + parameters | 15:25 |
zaneb | SpamapS: yeah, iirc we stored the snippet completely resolved | 15:25 |
*** matsuhashi has quit IRC | 15:25 | |
zaneb | which made it useless in many ways | 15:25 |
lsmola_ | SpamapS: I think it should work correctly, heat can do any kind of magic :-D | 15:26 |
SpamapS | zaneb: my thinking is that we store the new template + params as an anonymous stack and update pointers per resource to that... last bit is to move the name to the new stack and mark old one deleted. | 15:26 |
*** nati_ueno has joined #heat | 15:26 | |
zaneb | but in retrospect, was useful for locking in the old parameters | 15:26 |
SpamapS | zaneb: but that is definitely "major surgery" | 15:26 |
zaneb | indeed | 15:26 |
lsmola_ | SpamapS: zaneb yep, I am trying to find a solution for next 3 weeks | 15:26 |
zaneb | lsmola_: I just posted another comment which should explain the workaround in more detail | 15:26 |
SpamapS | but that would solve it as during the update, we'd pass the new stack id in and things that need to signal new handles / etc. would be able to do so by stack id. | 15:27 |
SpamapS | (of course this also means we have to have two stack ids.. the stack handle for in-stack things, and the stack id, for users) | 15:27 |
SpamapS | lsmola_: well software-config may be.. tomorrow.. so we need to figure out something for that too | 15:27 |
SpamapS | stevebaker: when you're up and around.. have you tested software-config with updates when adding a new server? | 15:28 |
SpamapS | I'm guessing it has no chance at working. :( | 15:28 |
*** matsuhas_ has joined #heat | 15:28 | |
SpamapS | Which is fine, we can just use NO_SIGNAL and keep our old wait condition handles | 15:29 |
SpamapS | lsmola_: thanks for testing early. This helps me plan :) | 15:29 |
*** packet has joined #heat | 15:29 | |
lsmola_ | SpamapS: :-) | 15:29 |
zaneb | lsmola_: what makes you say that https://review.openstack.org/#/c/82479/1 shouldn't work? | 15:30 |
lsmola_ | SpamapS: btw. we have been talking a bit with shardy and shadower about rewriting of templates | 15:30 |
lsmola_ | SpamapS: shardy shadower might be good to have a short hangout about that | 15:31 |
SpamapS | lsmola_: Cool.. see https://review.openstack.org/#/c/81666/ | 15:31 |
lsmola_ | SpamapS: regarding the software config, ResourceGroups and also Provider resource which is kind of new | 15:31 |
SpamapS | lsmola_: resource groups have a big problem | 15:32 |
SpamapS | lsmola_: count-- == death of the newest server | 15:32 |
SpamapS | lsmola_: we need to have a way to express which servers are marked for death first. I have an idea on that, which is to just pass a list of offsets that should be selected first for removal. | 15:32 |
lsmola_ | SpamapS: yeah that should be resolved in another bp, where you can pick which to kill | 15:32 |
SpamapS | remove_servers: [4, 1, 5] | 15:33 |
lsmola_ | SpamapS: there is a bp for the in heat somewhere | 15:33 |
*** matsuhas_ has quit IRC | 15:33 | |
SpamapS | lsmola_: that is a bug IMO | 15:33 |
*** jpeeler has joined #heat | 15:33 | |
lsmola_ | SpamapS: yeah :-) | 15:33 |
*** vijendar has quit IRC | 15:33 | |
*** andersonvom has joined #heat | 15:34 | |
lsmola_ | SpamapS: right, so now when you want to delete certain resoruce, you just delete it from template? | 15:34 |
*** vijendar has joined #heat | 15:35 | |
SpamapS | lsmola_: precisely | 15:35 |
lsmola_ | SpamapS: but then you cant upscale using merge.py, so.. | 15:35 |
SpamapS | lsmola_: precisely | 15:35 |
lsmola_ | :-) | 15:35 |
SpamapS | lsmola_: but we can fix that relatively easily in merge.py as well by passing the same list.. | 15:35 |
lsmola_ | SpamapS: right, but since we want to get rid of that, maybe we should focus on the heat way | 15:36 |
SpamapS | lsmola_: actually I want it to be offline_servers: [..] .. and then merge.py and/or resource groups will just ignore that those offsets even exist. This way if you update just that list.. it will create new servers to fill in the gaps, and you can manually delete them from nova yourself (or shut them down, or whatever) | 15:36 |
SpamapS | or not to fill in the gaps.. but to fill in the count | 15:37 |
SpamapS | lsmola_: we should always focus on the heat way | 15:37 |
SpamapS | merge.py was written as a POC that was supposed to land in Heat .. quickly | 15:37 |
SpamapS | but turns out a lot of people had opinions on how software configs should be decoupled from servers | 15:37 |
lsmola_ | SpamapS: yeah | 15:38 |
SpamapS | and now we're almost ready to deprecate that bit.. | 15:38 |
SpamapS | and we'll have to push hard on getting scaling right in Heat so we can fully deprecate it. | 15:38 |
*** wchrisj has joined #heat | 15:38 | |
lsmola_ | SpamapS: yes, we will be pushing that way too :-) | 15:38 |
SpamapS | Let's not wait though | 15:39 |
SpamapS | We're close enough to release.. you can push patches up now that will land shortly after unfreeze :) | 15:39 |
lsmola_ | SpamapS: yes | 15:40 |
lsmola_ | SpamapS: shardy shadower let me know when you are ready for the hangout | 15:41 |
lsmola_ | SpamapS: we had a big Heat brainstorming last week :-) | 15:42 |
lsmola_ | SpamapS: ok so, regarding the completion condition | 15:42 |
lsmola_ | SpamapS: could I push it the way of one Condition and Handle? | 15:43 |
SpamapS | lsmola_: yeah. | 15:43 |
SpamapS | lsmola_: and link that bug to TripleO | 15:43 |
lsmola_ | SpamapS: yeah it already is I think | 15:43 |
SpamapS | lsmola_: also retitle it.. I think we know what the real problem is now.. new resources are not available for signalling during an update | 15:43 |
lsmola_ | SpamapS: yes | 15:44 |
lsmola_ | SpamapS: done | 15:45 |
lsmola_ | SpamapS: now, I could put there the total count via merge.py | 15:45 |
lsmola_ | SpamapS: but it might be better to start parameter for that, as this will be used in groups later | 15:46 |
lsmola_ | SpamapS: might be a problem if only new resources are sending the signal though, but from the events I see that all resources are sending that | 15:46 |
lsmola_ | SpamapS: even when there is no rebuilding, could it be possible zaneb ? | 15:47 |
shadower | um what hangout | 15:47 |
* shadower reads back | 15:47 | |
zaneb | lsmola_: it's possible, I don't know how SpamapS's in-instance stuff works | 15:48 |
lsmola_ | zaneb: all of the events were updated, not just the new ones http://paste.openstack.org/show/74124/ , so count should be probably count of all | 15:48 |
lsmola_ | zaneb: ok | 15:48 |
lsmola_ | shadower: about joining our effort of rewriting of the templates :-) | 15:48 |
*** mutex has left #heat | 15:48 | |
mspreitz | lsmola_: what's this about rewriting templates? | 15:49 |
lsmola_ | shadower: with all of the new cool heat stuff :-) | 15:49 |
lsmola_ | mspreitz: rewriting of tripleo heat tempaltes | 15:49 |
* shadower is a bit wary of dragging a bunch of people from disparate tzs into meetings | 15:49 | |
shadower | surely a mailing list is a better and more open solution? | 15:49 |
zaneb | lsmola_: the events don't mean much here I don't think. But try with Count=2... if it fails you'll soon be able to see ;) | 15:49 |
shadower | the mailing list even | 15:50 |
mspreitz | lsmola_: you mean rewriting by hand to use new features, I take it. | 15:50 |
lsmola_ | shadower: yeah I guess, I am one of the people who prefers talking as faster way :-D | 15:50 |
lsmola_ | shadower: whatever suits you | 15:50 |
lsmola_ | zaneb: ok, will try | 15:51 |
lsmola_ | zaneb: I thought the events are result of the completion handle | 15:51 |
zaneb | lsmola_: events are the result of the stack update | 15:51 |
lsmola_ | mspreitz: yes basically, we need to rewrite it to latest cool stuff :-) | 15:52 |
lsmola_ | mspreitz: mainly to avoid the copypasting | 15:52 |
lsmola_ | zaneb: ok | 15:52 |
*** duncanjw has joined #heat | 15:54 | |
lsmola_ | shadower: could you send the email with the examples you have created? | 15:55 |
SpamapS | lsmola_: yes, the count should be all, not just new | 15:55 |
SpamapS | lsmola_: that was the point of making UpdateWaitConditionHandle | 15:55 |
lsmola_ | SpamapS: yeah it got to me :-) ok, will try that | 15:56 |
lsmola_ | SpamapS: what about the parameters vs. merge.py for whole count? | 15:56 |
lsmola_ | SpamapS: problem is the parameter won't be used until we use the ResourceGroup, but I won't have to modify merge.py | 15:57 |
sdake | zaneb trivial review if you want to pump your stats up:) https://review.openstack.org/#/c/82386/ | 15:58 |
zaneb | ooh, stats :) | 15:58 |
sdake | zaneb anyway I would like your comments | 15:58 |
sdake | since you and stevebaker seemed pretty locked into using super() | 15:59 |
SpamapS | lsmola_: I like the idea of the parameter, and just make the default the count. So if you're expanding NovaCompute# .. then make it NovaComputeCount. | 15:59 |
sdake | I found using super() expects a function exist to call, so there wasn't a way to get the ancestor class | 15:59 |
*** blamar has joined #heat | 15:59 | |
*** blamar has quit IRC | 15:59 | |
lsmola_ | SpamapS: ok | 16:00 |
*** blamar has joined #heat | 16:00 | |
zaneb | sdake: I don't understand the reference to super()? | 16:00 |
SpamapS | nor I | 16:01 |
sdake | zaneb maybe that was stevebaker's suggestion | 16:01 |
sdake | reference to super() is that review above | 16:01 |
sdake | zaneb^ | 16:01 |
zaneb | sdake: I'm looking at the review and I don't understand the connection to super() | 16:03 |
zaneb | sdake: would isinstance(e, heat.common.exception.HeatException) not work? | 16:03 |
zaneb | or, even better | 16:04 |
*** ifarkas has quit IRC | 16:04 | |
zaneb | except heat.common.exception.HeatException: | 16:04 |
zaneb | raise rpc_common.ClientException() | 16:04 |
sdake | zaneb NotFound is not a HeatException | 16:07 |
*** vijendar has quit IRC | 16:07 | |
sdake | zaneb I didn't try isinstance | 16:07 |
zaneb | sdake: shouldn't we make it one? | 16:07 |
sdake | zaneb NotFound is an "Error" exception | 16:08 |
sdake | I didn't really understand the difference in the base class | 16:08 |
sdake | I was a bit hestitant to change the base class - assuming there is some reason they are not the same | 16:08 |
sdake | NotFound is in heat.common.exception | 16:08 |
zaneb | https://github.com/openstack/heat/commit/1584bc17bb748a8b93f03781e1e210182b2708d3 | 16:08 |
zaneb | that's where it came from | 16:09 |
sdake | how do you git blame on github so fast? | 16:09 |
zaneb | IIRC I originally copied NotFound from openstack,.common.exception because it seemed like a waste to define a new one | 16:09 |
zaneb | since that module doesn't exist any more, I don't see any reason for that one to be treated differently | 16:10 |
zaneb | sdake: I was already looking at the file, so I just clicked 'Blame' ;) | 16:10 |
sdake | ya analsysis makes sense | 16:10 |
sdake | zaneb cool that must be a recent rfeature to github | 16:11 |
zaneb | I don't believe so ;) But it sure is a PITA to use if you have to go back more than one change | 16:12 |
zaneb | e.g. if the line has had a whitespace change | 16:12 |
sdake | I''ll add an empty rebase at the head of that change, and then merge the base classes | 16:13 |
zaneb | so you want to do a blame on the previous revision | 16:13 |
*** mspreitz has quit IRC | 16:13 | |
zaneb | requires about 15 clicks or manual editing of the URL :( | 16:13 |
zaneb | qgit is much better | 16:13 |
*** vijendar has joined #heat | 16:18 | |
*** sdake_ has joined #heat | 16:18 | |
*** sdake_ has quit IRC | 16:18 | |
*** sdake_ has joined #heat | 16:18 | |
sdake_ | zaneb assuming isinstance works, I presume you believe that is a better way to fix this problem? | 16:20 |
zaneb | The better way would be to only catch HeatException and not have any conditionals at all | 16:21 |
zaneb | which will work if isinstance works | 16:21 |
zaneb | so I'd say that is strictly preferable to isinstance | 16:21 |
sdake_ | other exceptions besdies heatexception can occur | 16:21 |
sdake_ | so you mean get rid of the conditional test and then use catch exception.HeatException? | 16:23 |
zaneb | sdake_: yes | 16:26 |
zaneb | except heat.common.exception.HeatException: | 16:26 |
zaneb | raise rpc_common.ClientException() | 16:26 |
zaneb | and let the rest handle themselves | 16:26 |
openstackgerrit | Tomas Sedovic proposed a change to openstack/heat: Don't create cloud-init user unless specified https://review.openstack.org/79678 | 16:28 |
sdake_ | zaneb interesting, isinstance matches against anything in the mro it looks like | 16:29 |
sdake_ | zaneb your suggestion works | 16:30 |
zaneb | yes, it includes all subclasses | 16:30 |
sdake_ | if something uses a try/ctch, and the catch doesn't catch the raised exception | 16:30 |
sdake_ | is the exception reraised out of the try? | 16:30 |
zaneb | yes, if you don't catch an exception it continues to propagate | 16:34 |
sdake_ | cool thanks zanb | 16:35 |
sdake_ | zaneb | 16:35 |
*** nati_ueno has quit IRC | 16:35 | |
openstackgerrit | Chmouel Boudjnah proposed a change to openstack/heat: Add docker network_gateway attribute https://review.openstack.org/82511 | 16:39 |
openstackgerrit | Cyril Roelandt proposed a change to openstack/python-heatclient: Python3: fix a bytes/str issue https://review.openstack.org/82543 | 16:40 |
openstackgerrit | Cyril Roelandt proposed a change to openstack/python-heatclient: Python3: fix a bytes/str issue https://review.openstack.org/77938 | 16:42 |
*** IlyaE has quit IRC | 16:43 | |
openstackgerrit | Roman Podoliaka proposed a change to openstack/heat: WIP: heat engine parameters unicode https://review.openstack.org/82545 | 16:44 |
openstackgerrit | Cyril Roelandt proposed a change to openstack/python-heatclient: Do not use the '+' operation with dict_items() https://review.openstack.org/82523 | 16:44 |
*** packet has quit IRC | 16:46 | |
*** tspatzier has quit IRC | 16:47 | |
*** pvaneck has joined #heat | 16:48 | |
*** harlowja has joined #heat | 16:49 | |
*** shakayumi has joined #heat | 16:51 | |
*** shakayumi has quit IRC | 16:51 | |
*** alexheneveld has quit IRC | 16:52 | |
* sdake_ groans - 68 test case failures to change base class of NotFound | 16:54 | |
sdake_ | oh well time to tackle this afternoon | 16:54 |
sdake_ | have to run for a meeting thanks zaneb for taking a look | 16:54 |
zaneb | np | 16:54 |
* zaneb starts thinking about lunch | 16:54 | |
*** shakayumi has joined #heat | 17:00 | |
*** shakayumi has quit IRC | 17:01 | |
*** zns has quit IRC | 17:01 | |
*** zns has joined #heat | 17:02 | |
*** IlyaE has joined #heat | 17:08 | |
*** ifarkas has joined #heat | 17:14 | |
*** e0ne has quit IRC | 17:14 | |
openstackgerrit | A change was merged to openstack/heat: Refactor CLB to work with groups https://review.openstack.org/65586 | 17:14 |
shardy | andersonvom: Hi, around? | 17:15 |
*** nati_ueno has joined #heat | 17:17 | |
*** yogesh has joined #heat | 17:30 | |
*** jaustinpage has joined #heat | 17:32 | |
*** jistr has quit IRC | 17:36 | |
*** duncanjw has quit IRC | 17:38 | |
*** fandi has joined #heat | 17:39 | |
*** duncanjw has joined #heat | 17:41 | |
cmyster | evening btw | 17:44 |
*** IlyaE has quit IRC | 17:45 | |
*** IlyaE has joined #heat | 17:48 | |
lipinski | Are nested provider templates supported? | 17:48 |
lipinski | I'm trying to have a template which refers to a resource via a provider template which in turn refers to another resource via a provider template. | 17:49 |
lipinski | The engine is not finding the second (nested) resource type | 17:49 |
andersonvom | shardy: yup | 17:52 |
*** kgriffs is now known as kgriffs_afk | 17:53 | |
*** duncanjw has quit IRC | 17:53 | |
*** derekh has quit IRC | 17:54 | |
shardy | andersonvom: hey! | 17:55 |
shardy | andersonvom: I'm working on some tempest tests, and decided to do one for the new stack list query args | 17:56 |
shardy | andersonvom: I have a couple of quick questions.. | 17:56 |
andersonvom | shardy: shoot | 17:56 |
shardy | The limit argument limits from the *end* of the list, is that expected? | 17:56 |
openstackgerrit | Jeff Peeler proposed a change to openstack/heat-templates: Add template for separated node/broker OpenShift https://review.openstack.org/81632 | 17:57 |
harlowja | hmmm, murano murano, murano | 17:58 |
shardy | andersonvom: #2 the status filter expects e.g "COMPLETE", no action, which could be arguably confusing, because we're exposing the internal definition of "status" rather then filtering on the action_status combination (which is the API view of "status") | 17:59 |
shardy | andersonvom: again, is that expected and what we want? | 17:59 |
andersonvom | shardy: what do you mean with "limits from the end of the list"? | 18:00 |
andersonvom | shardy: fwiw, both limit and marker are being used as other projects use them. | 18:01 |
shardy | andersonvom: Ok, I mean if I list without any limit, then with a limit=1, I get the last item in the list | 18:03 |
therve | harlowja, Please complain :/ | 18:03 |
harlowja | lol | 18:03 |
shardy | andersonvom: I was kinda expecting the first, and to be able to step thru the list from the top with marker | 18:03 |
therve | I don't think they heard enough yet | 18:03 |
harlowja | lol | 18:03 |
shardy | andersonvom: but it's entirely possible I'm just expecting the wrong thing :) | 18:03 |
harlowja | therve are u sure? | 18:03 |
harlowja | everytime i look at https://wiki.openstack.org/wiki/Murano/DSL/Blueprint#Block_constructs i get confused, lol | 18:04 |
therve | harlowja, It's wrong in some many ways. They have to understand that it will block their graduation. Or so I hope. | 18:04 |
harlowja | therve ya, i think they are probably tired of hearing me and zaneb complain, lol | 18:05 |
andersonvom | shardy: humm... I'm looking at the code here and trying to understand how that's happening. I would expect the same thing you were, tbh. | 18:05 |
harlowja | i was looking over the code and although its neat and all, i don't get it still :-P | 18:06 |
harlowja | https://github.com/stackforge/murano-api/tree/master/muranoapi/engine | 18:06 |
harlowja | it seems like a mix of java, python, yaml, yaql | 18:06 |
*** tango has joined #heat | 18:06 | |
harlowja | https://github.com/stackforge/murano-api/blob/master/muranoapi/engine/class_loader.py | 18:06 |
harlowja | even has class loaders | 18:06 |
*** jmckind has quit IRC | 18:09 | |
*** jmckind has joined #heat | 18:10 | |
andersonvom | shardy: oh... it's a problem with the python-heatclient | 18:12 |
*** IlyaE has quit IRC | 18:12 | |
andersonvom | shardy: the API actually works correctly, but, for some reason, the heat client is returning the list backwards | 18:12 |
shardy | andersonvom: aha! | 18:12 |
shardy | testing ftw! :) | 18:12 |
shardy | andersonvom: hrm, although I think my tempest test isn't actually using heatclient (it's an API not scenario test) | 18:13 |
andersonvom | shardy: interesting. when I try just the API call with and without limit, I get the behavior we were expecting. | 18:18 |
andersonvom | on master | 18:18 |
shardy | andersonvom: Ok thanks, I must have some issue with either my test or environment then | 18:21 |
shardy | andersonvom: re the second point, do you think we need to add action as a query filter? | 18:21 |
shardy | andersonvom: e.g so you can do action=CREATE&status=COMPLETE | 18:22 |
andersonvom | shardy: oh yeah, that. when we implemented it, that was intended, as it might be more useful to find all FAILED status than it it to find only all CREATE_FAILED, for example. | 18:23 |
andersonvom | shardy: but I agree, we could add action as well. it has its uses too. | 18:23 |
andersonvom | s/it it/it would/ | 18:23 |
shardy | andersonvom: Ok, sounds good, then perhaps when we move to a v2 API we can decouple stack_status to be action/status in the stack response | 18:24 |
* andersonvom thinks there should be a plugin for irssi that would actually run the replace command on your lines. | 18:24 | |
andersonvom | shardy: +2 for decoupling | 18:25 |
shardy | haha, somehow rewrite history in everyone's client, or maintain a local 30s "typo buffer" :) | 18:25 |
* shardy could use one of those | 18:25 | |
*** jpeeler has quit IRC | 18:26 | |
*** alexheneveld has joined #heat | 18:26 | |
*** mestery has joined #heat | 18:27 | |
*** mestery has quit IRC | 18:29 | |
*** e0ne has joined #heat | 18:30 | |
*** alexheneveld has quit IRC | 18:36 | |
*** mkollaro has quit IRC | 18:36 | |
*** IlyaE has joined #heat | 18:41 | |
*** lipinski has quit IRC | 18:41 | |
*** ramishra has quit IRC | 18:47 | |
*** ramishra has joined #heat | 18:48 | |
*** aweiteka has quit IRC | 18:49 | |
*** yogesh has quit IRC | 18:52 | |
*** ramishra has quit IRC | 18:52 | |
*** rbuilta has joined #heat | 18:53 | |
*** yogesh has joined #heat | 18:54 | |
*** mspreitz has joined #heat | 18:57 | |
*** zns has quit IRC | 18:58 | |
*** mdelder has joined #heat | 18:58 | |
mdelder | Hi, I think I've found a bug in some new behavior around sw_config/sw_deploy. I've found a problem in the authentication protocol that breaks standalone/multicloud support. Is anyone here familiar with (1) the updates for swconfig/deploy or (2) the authentication protocol for Heat? | 18:59 |
*** duncanjw has joined #heat | 19:00 | |
*** harlowja has quit IRC | 19:01 | |
*** aweiteka has joined #heat | 19:02 | |
* mspreitz eagerly listens for a response | 19:02 | |
*** harlowja has joined #heat | 19:03 | |
*** lindsayk has joined #heat | 19:04 | |
*** BillArnold_ has joined #heat | 19:09 | |
*** jprovazn has quit IRC | 19:10 | |
mspreitz | Let's try an easier question. Look at https://etherpad.openstack.org/p/software-config-component --- how much has been deprecated? Everything after the deprecation remark? | 19:11 |
zaneb | harlowja: lol | 19:15 |
harlowja | zaneb u should propose using http://en.wikipedia.org/wiki/Brainfuck instead | 19:16 |
harlowja | lol | 19:16 |
zaneb | I still have to get through all the new mails in that thread | 19:17 |
harlowja | more fun :-P | 19:17 |
zaneb | last week on that thread was exhausting enough :/ | 19:17 |
harlowja | def | 19:17 |
*** che-arne has quit IRC | 19:20 | |
*** kgriffs_afk is now known as kgriffs | 19:21 | |
harlowja | zaneb everytime i think about a language built ontop of python i start to think about all the vulnerbilities that are so easy to pull off (even in a restrictive dsl) | 19:21 |
harlowja | and how hard in python it is going to be to get it right | 19:22 |
harlowja | so many places to cause DOS | 19:23 |
*** e0ne has quit IRC | 19:25 | |
*** duncanjw has quit IRC | 19:26 | |
*** TonyBurn has quit IRC | 19:30 | |
*** duncanjw has joined #heat | 19:30 | |
*** mspreitz has left #heat | 19:38 | |
*** bgorski has quit IRC | 19:40 | |
*** rbuilta has quit IRC | 19:45 | |
*** mestery has joined #heat | 19:47 | |
*** zns has joined #heat | 19:49 | |
*** mspreitz has joined #heat | 19:53 | |
*** connie has joined #heat | 20:00 | |
*** lindsayk1 has joined #heat | 20:02 | |
*** lindsayk1 has quit IRC | 20:03 | |
*** lindsayk1 has joined #heat | 20:03 | |
*** lindsayk has quit IRC | 20:04 | |
*** mdelder_ has joined #heat | 20:08 | |
openstackgerrit | Steve Baker proposed a change to openstack/heat: Document software config classes https://review.openstack.org/81407 | 20:09 |
openstackgerrit | Steve Baker proposed a change to openstack/heat: Store stack domain credentials for deployments https://review.openstack.org/80868 | 20:09 |
openstackgerrit | Zane Bitter proposed a change to openstack/heat: Fail if non-existent security group referenced https://review.openstack.org/81558 | 20:10 |
*** mdelder has quit IRC | 20:11 | |
*** jaustinpage has quit IRC | 20:12 | |
andersonvom | anybody who's very well versed in the ways the templates get parsed during the life cycle of a stack? | 20:15 |
*** mwheckmann has quit IRC | 20:17 | |
*** Tross1 has quit IRC | 20:22 | |
openstackgerrit | Steven Dake proposed a change to openstack/heat: Error and NotFound inherit HeatException class https://review.openstack.org/82593 | 20:23 |
openstackgerrit | Steven Dake proposed a change to openstack/heat: Properly encode heat.common.exception in rpc https://review.openstack.org/82386 | 20:23 |
sdake_ | zaneb can you have a look at the first change and see if its correct | 20:23 |
sdake_ | I would expect __init__ to take args, but for some reason python doesn't want it to take kwargs[:1] | 20:23 |
sdake_ | and the test cases pass with the change | 20:23 |
sdake_ | so I'm not sure if I broke something or not :( | 20:24 |
openstackgerrit | Steven Dake proposed a change to openstack/heat: Properly encode heat.common.exception in rpc https://review.openstack.org/82386 | 20:27 |
*** harlowja_ has joined #heat | 20:27 | |
*** DaveJ__ has quit IRC | 20:27 | |
*** jaustinpage has joined #heat | 20:27 | |
*** insanidade has joined #heat | 20:28 | |
insanidade | hi all. quick question: is heat totally compatible with the CFN format ? | 20:29 |
sdake_ | insanidade some of the resources are not 100% compatible, but cfn should be pretty close | 20:29 |
sdake_ | for example, heat doesn't provide full coverage of amazon's resources, such as route53, etc | 20:29 |
insanidade | sdake_: I see. but the basics are compatible, right? I mean: the basics for a fully functional cloud. | 20:31 |
*** lindsayk1 has quit IRC | 20:31 | |
insanidade | sdake_: and what about the progress of HOT ? | 20:31 |
*** networkn81 has quit IRC | 20:31 | |
*** harlowja has quit IRC | 20:31 | |
sdake_ | we are supporting hot going forward from icehouse | 20:34 |
sdake_ | the openstack resources are in really good shape | 20:34 |
sdake_ | i'd recommend just writing native HOT using openstack native resources | 20:34 |
insanidade | sdake_: so, when using HOT, your recomendation would be using only native openstack resources and that would be pretty safe to assume that such orchestration would work, right? | 20:35 |
sdake_ | yup | 20:35 |
sdake_ | we have 2000+ test cases | 20:35 |
sdake_ | the code base has high degree of coverage | 20:35 |
insanidade | are we supposed - from an Openstack perspective - to forget CFN templates any time soon ? | 20:37 |
sdake_ | insanidade future difficult to predict, but based upon what I know today - cfn parsrer will be made pluggable, the aws compatibility resources are already pluggable, and some cloud vendors may turn then off or keep them on | 20:37 |
sdake_ | but the openstack native resources will generally be in an on state | 20:38 |
sdake_ | so it really depends on your vendor | 20:38 |
*** mdelder_ has quit IRC | 20:38 | |
insanidade | got it. so CFN support will be available even after HOT reaching a very high maturity level. | 20:38 |
sdake_ | can't guarantee it forever | 20:39 |
sdake_ | but we don't have plans to remove cfn or aws resources in the next 6-12 months | 20:39 |
sdake_ | I don't see any strong motivation to remove said resources | 20:39 |
sdake_ | or said parser | 20:39 |
sdake_ | but some openstack vendors dont want aws mentioned in their marketspeak, so they are free to turn them off iif they want | 20:39 |
*** lindsayk has joined #heat | 20:40 | |
insanidade | I see. I understand HOT itself should cover all functionality provided by CFN so going with HOT in the future should be pretty safe - am I wrong ? | 20:41 |
sdake_ | hot provides parity with cfn | 20:41 |
*** lipinski has joined #heat | 20:41 | |
sdake_ | I like to think of HOT as what AWS would have done if they got a mulligan | 20:41 |
* randallburt puts on his Heat core hat: There's no reason to remove support for CFN in the foreseeable future IMO. | 20:43 | |
sdake_ | insanidade in a general and real sense, HOT is much more optimal then cfn to work with | 20:43 |
* randallburt puts on his Rackspace hat: I wish it were easier to remove "default" resources from Heat | 20:43 | |
shardy | randallburt: +1, I've had conversations with several existing users who find CFN compatibility important | 20:44 |
sdake_ | randallburt I think it makes sense to allow a config option to allow people to turn on/off resources by top level namespace | 20:44 |
randallburt | sdake_: sounds reasonable. | 20:44 |
*** mspreitz has quit IRC | 20:44 | |
shardy | randallburt: But I'd like over time for us to move to having all the AWS resources reimplemented as provider templates over the native resources | 20:44 |
sdake_ | shardy +1 | 20:44 |
randallburt | shardy: totally agreed. FWIW I think its a pretty compelling use case for cloud users. | 20:44 |
shardy | then we can reduce the plugin-level duplication and make it easier to "turn off" the AWS stuff | 20:44 |
randallburt | shardy: indeed. quite a bit of work though and there's that pesky "Metadata" to worry about, but I think its solve-able. | 20:45 |
shardy | randallburt: agreed, it's a mid-term goal to work towards over several cycles IMO | 20:46 |
randallburt | shardy: sounds good to me | 20:46 |
*** e0ne has joined #heat | 20:47 | |
*** andersonvom_ has joined #heat | 20:50 | |
*** andersonvom has quit IRC | 20:50 | |
*** Tross has joined #heat | 20:51 | |
lipinski | Anyone know if nested/layered proviter templates are supposed to work? | 20:52 |
lipinski | provider | 20:52 |
shardy | lipinski: yes, they do work | 20:52 |
*** jpeeler has joined #heat | 20:53 | |
*** jpeeler has quit IRC | 20:53 | |
*** jpeeler has joined #heat | 20:53 | |
insanidade | sdake_: thanks for clarifying those points. | 20:54 |
*** jpeeler has quit IRC | 20:54 | |
*** jpeeler has joined #heat | 20:54 | |
*** jpeeler has quit IRC | 20:54 | |
*** jpeeler has joined #heat | 20:54 | |
lipinski | shardy: anything special to get them to work? I am having problems - Heat claims it cannot find the "second-layer" resource. | 20:56 |
lipinski | Template -> resourceA -> resourceB. Both resourceA and resourceB defined in registry. Heat complains it does not know what resourceB is. | 20:56 |
lipinski | Yet, if I put resourceB directly in Template, it works. | 20:57 |
*** alexheneveld has joined #heat | 20:58 | |
openstackgerrit | Steve Baker proposed a change to openstack/python-heatclient: Process provider templates for included files https://review.openstack.org/82603 | 21:06 |
*** andersonvom_ has quit IRC | 21:07 | |
*** andersonvom has joined #heat | 21:07 | |
*** Gamekiller77 has joined #heat | 21:09 | |
Gamekiller77 | hey guys | 21:09 |
Gamekiller77 | any one around | 21:09 |
lipinski | shardy: it seems fi I define the resource_registry in /etc/heat/environment.d then it works. But, if my resource_registry is defined in the environment file, it doesn't propogate, it seems. | 21:09 |
Gamekiller77 | is it possible to use a snapshot with a Heat HOT template ? | 21:10 |
Gamekiller77 | i about to read all the doc pages but wanted to ask before i go googling | 21:10 |
lipinski | Can you pass JSON arrays as a list? That seemed to fail on me. | 21:10 |
*** Gamekiller77 has quit IRC | 21:12 | |
*** Gamekiller77 has joined #heat | 21:13 | |
stevebaker | Gamekiller77: a cinder snapshot? | 21:15 |
Gamekiller77 | yes | 21:16 |
Gamekiller77 | want to do a storage bench marking and load testing | 21:16 |
Gamekiller77 | would be nice to presetup apps then have heat just blast out like 50 boxes | 21:16 |
Gamekiller77 | pre set it up | 21:17 |
*** jstrachan has quit IRC | 21:17 | |
stevebaker | Gamekiller77: how about OS::Nova::Server block_device_mapping snapshot_id? http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server | 21:19 |
*** connie has quit IRC | 21:19 | |
Gamekiller77 | ok i take a look | 21:19 |
Gamekiller77 | thanks | 21:19 |
Gamekiller77 | i using Ceph RBD so snapshot work very well to spin up new instances | 21:19 |
*** tomek_adamczewsk has quit IRC | 21:21 | |
stevebaker | SpamapS: can you walk me through the new-server config issue? | 21:22 |
*** e0ne has quit IRC | 21:23 | |
*** tango has quit IRC | 21:24 | |
*** sgordon_ has quit IRC | 21:25 | |
*** aweiteka has quit IRC | 21:26 | |
SpamapS | stevebaker: sure | 21:28 |
SpamapS | stevebaker: during an update, signals can't be accepted for new wait handles. | 21:28 |
SpamapS | stevebaker: that is because in order to load a resource, you need the template snippet for it. | 21:28 |
*** asalkeld has joined #heat | 21:28 | |
*** alexheneveld has quit IRC | 21:29 | |
SpamapS | stevebaker: that snippet only exists in the engine doing the update's RAM until the stack is complete again. | 21:29 |
*** cmyster_ has joined #heat | 21:29 | |
stevebaker | SpamapS: so this is an issue which affects new WaitHandle and SoftwareDeployment resources on update? | 21:30 |
*** e0ne has joined #heat | 21:30 | |
*** andrew_plunk has joined #heat | 21:31 | |
*** asalkeld has quit IRC | 21:32 | |
*** vijendar has quit IRC | 21:32 | |
SpamapS | stevebaker: right | 21:32 |
*** stannie1 has joined #heat | 21:32 | |
SpamapS | stevebaker: It really goes back to the same thing that prevents retry | 21:32 |
*** asalkeld has joined #heat | 21:32 | |
*** rpothier has quit IRC | 21:32 | |
SpamapS | stevebaker: update is fundamentally broken until it keeps track of state in the db | 21:33 |
*** cmyster has quit IRC | 21:33 | |
stevebaker | ok | 21:33 |
*** Gamekiller77 has left #heat | 21:33 | |
SpamapS | stevebaker: so, the only answer is to just have one handle, and use the count to account for new resources. | 21:33 |
SpamapS | Not sure but I _think_ you can have multiple wait conditions on a single handle | 21:34 |
stevebaker | ug, which means no deployment resources | 21:34 |
SpamapS | stevebaker: right, they're not useful for updates. :( | 21:34 |
SpamapS | well | 21:34 |
SpamapS | unless you never add one :-P | 21:34 |
SpamapS | stevebaker: they're still super super super super awesome for the other parts though :) | 21:34 |
SpamapS | stevebaker: and we _could_ special case new resources... | 21:35 |
stevebaker | SpamapS: how about if the server and the deployment are in a provider template? (which they should be eventually anyway) that way you're adding a nested stack during the update | 21:35 |
SpamapS | stevebaker: so they'd have a different stack name to hand the API? | 21:36 |
SpamapS | stevebaker: that would work, as long as you destroy the whole thing before update. | 21:36 |
stevebaker | hmmm yes? | 21:36 |
SpamapS | but you wouldn't normally, you'd do an update on it | 21:36 |
SpamapS | hm still might work | 21:36 |
SpamapS | stevebaker: that might be longer-term-viable than special casing anyway. | 21:37 |
*** asalkeld has quit IRC | 21:37 | |
insanidade | exit | 21:38 |
*** insanidade has quit IRC | 21:38 | |
stevebaker | SpamapS: oh well, I look forward to update working | 21:40 |
SpamapS | stevebaker: yeah me too. I had my first successful abandon/adopt last week though.. so I feel a little better about dealing with FAILED in production. | 21:41 |
stevebaker | nice | 21:41 |
openstackgerrit | Andrew Plunk proposed a change to openstack/heat: Chef solo resource https://review.openstack.org/55208 | 21:42 |
andrew_plunk | hey stevebaker, I finally got it posted ^^ | 21:43 |
stevebaker | andrew_plunk: \o/ | 21:43 |
*** jaustinpage has quit IRC | 21:44 | |
andrew_plunk | :). I deprecated the old namespace of "OS::Heat::ChefSolo" for "Rackspace::Cloud::ChefSolo" to support some of our old templates. If that is a problem then we can find another way to solve that using environments or something | 21:45 |
*** nati_ueno has quit IRC | 21:47 | |
stevebaker | andrew_plunk: could you just do the OS::Heat::ChefSolo mapping in your /etc/heat/environment.d? | 21:47 |
shardy | SpamapS: lsmola_ and I were discussing the multiple waitconditions thing earlier, you can but in most cases it won't make sense | 21:47 |
shardy | because the data is stored with the handle, so maybe if you had two different paths with different counts or something | 21:48 |
*** nati_ueno has joined #heat | 21:48 | |
shardy | otherwise all the conditions will complete at the same time, so will be redundant | 21:48 |
andrew_plunk | yeah that is what I was mentioning. That will require a production infra change for us and all of our templates will have to be changed stevebaker. If the way I am currently handling it is a problem I can change to environments, I was just taking the path of least resistance for now | 21:49 |
SpamapS | stevebaker: https://review.openstack.org/82244 <-- deployments via cfn API landed in os-collect-config :) | 21:49 |
SpamapS | shardy: well I was thinking that you could use it to block along the way | 21:50 |
*** asalkeld has joined #heat | 21:50 | |
SpamapS | shardy: it wouldn't work for divergent branches, but it would for linear | 21:50 |
stevebaker | SpamapS: sweetness | 21:50 |
shardy | SpamapS: ah, so add a new WaitCondition on update with a larger count? | 21:50 |
shardy | but leave the old one alone? | 21:51 |
SpamapS | shardy: no, just update the count for that | 21:51 |
SpamapS | shardy: but you can do this: | 21:51 |
zaneb | lipinski: the environment file doesn't propagate to provider stacks | 21:51 |
SpamapS | [handle]->[server0]->[waitcondition0,count==1]->server1->[waitcondition1,count==2] | 21:52 |
SpamapS | shardy: that will block until count >= 1, and then >= 2 | 21:52 |
SpamapS | if it isn't >= .. if it is == .. well.. that may be a bug anyway ;) | 21:52 |
shardy | SpamapS: aha, yeah that would work, I tested something similar earlier | 21:52 |
SpamapS | but anyway | 21:52 |
SpamapS | I'm comfortable that users can work around this.. myself included | 21:53 |
SpamapS | but I'm sad that we can't use the built in wait pieces of deployments | 21:53 |
*** alexpilotti has joined #heat | 21:54 | |
*** Tross has quit IRC | 21:54 | |
shardy | SpamapS: I think we'll just have to work really hard to sort out the various update issues in Juno, unfortunately | 21:54 |
*** mestery has quit IRC | 21:55 | |
*** dims has quit IRC | 21:56 | |
*** lindsayk has quit IRC | 21:56 | |
*** Linz has joined #heat | 21:57 | |
*** _ruhe_ has quit IRC | 21:59 | |
SpamapS | shardy: #1 priority for me. | 22:01 |
SpamapS | it is #2 for me, behind graceful notifying of servers before rebuild/delete | 22:02 |
*** lindsayk has joined #heat | 22:04 | |
*** mestery has joined #heat | 22:04 | |
*** mestery has quit IRC | 22:06 | |
*** che-arne has joined #heat | 22:07 | |
*** andersonvom has quit IRC | 22:07 | |
*** dims_ has joined #heat | 22:14 | |
*** Linz has quit IRC | 22:14 | |
*** BillArnold_ has quit IRC | 22:22 | |
*** alexheneveld has joined #heat | 22:22 | |
*** jcru has quit IRC | 22:23 | |
*** lipinski has quit IRC | 22:23 | |
*** faramir1 has joined #heat | 22:24 | |
zaneb | stevebaker: do you have a link to the Neutron dependency issue we were discussing on Friday? | 22:25 |
* zaneb has lost it | 22:25 | |
zaneb | and also the link | 22:25 |
*** alexheneveld has quit IRC | 22:26 | |
*** andrew_plunk has quit IRC | 22:26 | |
*** Tross has joined #heat | 22:29 | |
openstackgerrit | Ziad Sawalha proposed a change to openstack/heat: Update common docstrings to match guidelines https://review.openstack.org/73519 | 22:31 |
*** ifarkas has quit IRC | 22:31 | |
*** alexheneveld has joined #heat | 22:31 | |
openstackgerrit | Ziad Sawalha proposed a change to openstack/heat: Update api docstrings to match guidelines https://review.openstack.org/73515 | 22:32 |
*** Linz has joined #heat | 22:33 | |
openstackgerrit | Ziad Sawalha proposed a change to openstack/heat: Update contrib docstrings to match guidelines https://review.openstack.org/73070 | 22:35 |
*** saurabhs has joined #heat | 22:35 | |
*** alexheneveld has quit IRC | 22:36 | |
*** e0ne has quit IRC | 22:41 | |
*** yogesh has quit IRC | 22:41 | |
*** jmckind has quit IRC | 22:42 | |
*** Linz has quit IRC | 22:43 | |
*** Linz has joined #heat | 22:44 | |
*** zns has quit IRC | 22:46 | |
*** david-lyle has quit IRC | 22:52 | |
*** duncanjw has quit IRC | 22:54 | |
*** kgriffs is now known as kgriffs_afk | 22:55 | |
*** alexheneveld has joined #heat | 22:56 | |
*** tomek_adamczewsk has joined #heat | 22:56 | |
*** sgordon has joined #heat | 22:59 | |
*** sgordon has quit IRC | 22:59 | |
*** sgordon has joined #heat | 22:59 | |
*** gokrokve has joined #heat | 23:02 | |
*** rcleere has quit IRC | 23:08 | |
stevebaker | Could we get some reviews on the rc1 bugs? https://launchpad.net/heat/+milestone/icehouse-rc1 | 23:17 |
stevebaker | zaneb: https://bugs.launchpad.net/heat/+bug/1279645 (and https://bugs.launchpad.net/heat/+bug/1243992) | 23:19 |
uvirtbot | Launchpad bug 1279645 in heat "stack delete failed when using OS::Neutron::Router's external_gateway_info property" [Medium,In progress] | 23:19 |
openstackgerrit | Steven Dake proposed a change to openstack/heat: Properly encode heat.common.exception in rpc https://review.openstack.org/82386 | 23:19 |
openstackgerrit | Steven Dake proposed a change to openstack/heat: Error and NotFound inherit HeatException class https://review.openstack.org/82593 | 23:19 |
zaneb | stevebaker: ta | 23:21 |
*** faramir1 has quit IRC | 23:22 | |
*** duncanjw has joined #heat | 23:22 | |
*** tomek_adamczewsk has quit IRC | 23:22 | |
*** saurabhs has quit IRC | 23:31 | |
*** randallburt has quit IRC | 23:33 | |
stevebaker | SpamapS, lifeless, where is image building for tripleo CI at? I wonder if I could hook into that to get an os-*-config enabled image for software-config tempest tests | 23:35 |
*** stannie1 has quit IRC | 23:42 | |
*** sgordon has quit IRC | 23:44 | |
*** rbuilta has joined #heat | 23:45 | |
*** Tross has quit IRC | 23:46 | |
lifeless | stevebaker: we build imags during CI | 23:47 |
*** gokrokve has quit IRC | 23:48 | |
*** pvaneck has quit IRC | 23:48 | |
stevebaker | lifeless: my previous attempt to invoke dib during devstack stalled on waiting for devstack to switch to pip-1.5 | 23:49 |
*** pvaneck has joined #heat | 23:49 | |
lifeless | why do you need pip 1.5? | 23:49 |
*** aweiteka has joined #heat | 23:51 | |
*** alexheneveld has quit IRC | 23:51 | |
*** rbuilta has quit IRC | 23:54 | |
openstackgerrit | A change was merged to openstack/heat: Fix stack-show failed with a name in uuid format https://review.openstack.org/82471 | 23:54 |
*** IlyaE has quit IRC | 23:57 | |
*** pvaneck has quit IRC | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!