Monday, 2014-03-24

*** mnaser has left #heat00:03
*** ZZpablosan is now known as pablosan00:21
*** matsuhashi has joined #heat00:25
*** duncanjw has quit IRC01:15
openstackgerritCyril Roelandt proposed a change to openstack/python-heatclient: Python 3: decode bytes before feeding them to jsonutils.loads()  https://review.openstack.org/7865201:21
*** duncanjw has joined #heat01:33
*** nosnos has joined #heat01:36
openstackgerritLee Li proposed a change to openstack/python-heatclient: Using common methods from oslo cliutils  https://review.openstack.org/6712001:48
*** pablosan is now known as ZZpablosan01:59
*** PhilK has quit IRC02:08
*** PhilK has joined #heat02:10
*** ZZpablosan is now known as pablosan02:11
*** david-lyle has joined #heat02:14
*** liang has joined #heat02:21
*** rcleere has joined #heat02:52
*** matsuhashi has quit IRC02:55
*** ramishra has joined #heat03:02
*** ramishra_ has joined #heat03:03
*** ramishra has quit IRC03:07
*** matsuhashi has joined #heat03:21
*** nati_ueno has joined #heat03:23
*** liang has quit IRC03:28
*** nkhare has joined #heat03:31
*** liang has joined #heat03:32
*** duncanjw has joined #heat03:34
*** duncanjw has quit IRC03:38
*** liang has quit IRC03:39
*** killer_p- has joined #heat03:52
*** killer_p- is now known as killer_prince03:52
*** lazy_prince has quit IRC03:53
*** liang has joined #heat03:53
*** pablosan is now known as ZZpablosan03:56
openstackgerritLiang Chen proposed a change to openstack/heat: Tidy up urlfetch.py exception handling  https://review.openstack.org/8196004:13
*** killer_prince has quit IRC04:16
*** liang has quit IRC04:17
openstackgerritA change was merged to openstack/heat-templates: Remove tag to allow default resolved group id  https://review.openstack.org/8215804:18
*** killer_prince has joined #heat04:18
openstackgerritA change was merged to openstack/heat-templates: Correct a few typos and remove nan workaround  https://review.openstack.org/8142504:19
*** fandi has joined #heat04:20
*** Akshik has joined #heat04:21
*** liang has joined #heat04:31
*** cmyster has joined #heat04:36
*** ramishra_ has quit IRC04:39
*** mestery has joined #heat04:46
*** nati_ueno has quit IRC04:46
*** nati_ueno has joined #heat04:47
*** nati_ueno has quit IRC04:51
*** nati_ueno has joined #heat04:52
openstackgerritA change was merged to openstack/python-heatclient: Python 3: Fix YamlEnvironmentTest tests  https://review.openstack.org/7773704:56
skraynevMorning05:06
openstackgerritA change was merged to openstack/heat: Get rid of global variable in JSON->YAML conversion  https://review.openstack.org/8109605:09
*** ramishra has joined #heat05:11
openstackgerritA change was merged to openstack/heat: Fix user provider template registration  https://review.openstack.org/7995305:13
*** chandankumar has quit IRC05:14
*** mestery has quit IRC05:14
openstackgerritMitsuru Kanabuchi proposed a change to openstack/heat: Reimplement DHCPAgent as net's property  https://review.openstack.org/8172605:15
*** nosnos_ has joined #heat05:16
*** nosnos has quit IRC05:19
*** Akshik has quit IRC05:20
*** Akshik has joined #heat05:20
openstackgerritA change was merged to openstack/heat: Implement an identifier stack_path()  https://review.openstack.org/8086905:22
openstackgerritA change was merged to openstack/heat: Provide the necessary inputs to enable HEAT_SIGNAL  https://review.openstack.org/8016905:23
openstackgerritChenZheng proposed a change to openstack/heat: Sort requirement files in alphabetical order  https://review.openstack.org/7677505:24
*** liang has quit IRC05:25
*** chandan_kumar has joined #heat05:25
openstackgerritA change was merged to openstack/python-heatclient: Using common methods from oslo cliutils  https://review.openstack.org/6712005:26
*** Akshik_ has joined #heat05:26
*** Akshik has quit IRC05:26
*** Akshik_ has quit IRC05:33
*** duncanjw has joined #heat05:35
*** Akshik has joined #heat05:35
*** IlyaE has quit IRC05:39
*** liang has joined #heat05:39
*** duncanjw has quit IRC05:40
*** Akshik has quit IRC05:41
*** IlyaE has joined #heat05:43
*** Akshik has joined #heat05:46
*** sdake_ has quit IRC05:47
*** Akshik has quit IRC05:53
*** Akshik_ has joined #heat05:54
*** Akshik_ has quit IRC05:57
*** Akshik_ has joined #heat05:57
*** matsuhas_ has joined #heat06:00
*** matsuhashi has quit IRC06:01
cmystermorning06:03
openstackgerritJenkins proposed a change to openstack/heat: Imported Translations from Transifex  https://review.openstack.org/7256606:09
*** cfriesen has quit IRC06:11
*** mestery has joined #heat06:13
*** mestery has quit IRC06:13
*** mestery has joined #heat06:14
*** nati_ueno has quit IRC06:14
*** mestery_ has joined #heat06:15
*** mestery has quit IRC06:15
openstackgerritA change was merged to openstack/heat: Add documentation to the firewall properties  https://review.openstack.org/7784006:19
*** nosnos has joined #heat06:19
*** mestery_ has quit IRC06:20
*** nosnos_ has quit IRC06:22
openstackgerritA change was merged to openstack/heat: Add more unit tests for ThreadGroupManager  https://review.openstack.org/7828606:23
openstackgerritA change was merged to openstack/python-heatclient: Sort requirement files in alphabetical order  https://review.openstack.org/7681206:27
*** matsuhas_ has quit IRC06:31
*** matsuhashi has joined #heat06:31
*** IlyaE has quit IRC06:32
*** saju_m has joined #heat06:35
*** liang has quit IRC06:52
*** liang has joined #heat06:53
*** duncanjw has joined #heat06:56
*** saju_m has quit IRC06:59
*** jprovazn has joined #heat07:04
*** saju_m has joined #heat07:12
*** saju_m has quit IRC07:17
*** Tross1 has joined #heat07:17
*** saju_m has joined #heat07:18
*** nkhare_ has joined #heat07:19
*** Akshik__ has joined #heat07:19
*** nkhare has quit IRC07:19
*** Tross has quit IRC07:19
*** Akshik_ has quit IRC07:19
*** saju_m has quit IRC07:22
*** duncanjw has quit IRC07:22
*** duncanjw has joined #heat07:22
*** Akshik__ has quit IRC07:23
*** ramishra has quit IRC07:24
*** saju_m has joined #heat07:24
*** saju_m has quit IRC07:30
*** saju_m has joined #heat07:32
*** liang has quit IRC07:35
*** jistr has joined #heat07:38
*** e0ne has joined #heat07:44
*** e0ne has quit IRC07:47
*** liang has joined #heat07:48
*** tspatzier has joined #heat07:50
*** jstrachan has joined #heat08:13
therveGood morning!08:16
*** bgorski has joined #heat08:19
bgorskiHi. Is there a way to control number of resources that are created in parallel?08:19
*** ramishra has joined #heat08:21
*** pasquier-s has joined #heat08:21
*** tomek_adamczewsk has joined #heat08:26
*** tomek_adamczews1 has joined #heat08:30
*** e0ne has joined #heat08:30
*** tomek_adamczewsk has quit IRC08:30
*** TonyBurn has joined #heat08:31
*** duncanjw has quit IRC08:32
*** alexheneveld has joined #heat08:33
*** liang has quit IRC08:33
*** jamie_h has joined #heat08:34
lifelessbgorski: the dag controls that implicitly, but no way beyond that that I know of08:34
openstackgerritThomas Herve proposed a change to openstack/heat-templates: Add an example of native autoscaling resources  https://review.openstack.org/8244708:35
*** ifarkas has joined #heat08:35
*** ramishra has quit IRC08:36
bgorskilifeless, We have something call ThreadGroup and it has pool_size.08:38
skraynevtherve: Woow. Great example of autoscaling group I will test it ;)08:39
skraynevtherve: 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 #heat08:42
*** duncanjw has joined #heat08:42
skraynevtherve: I mean that not all users could understand that they should also download additional template for using autoscaling08:42
*** alexheneveld has quit IRC08:42
*** pas-ha has joined #heat08:45
pas-hamorning all :)08:46
*** alexheneveld has joined #heat08:47
*** derekh has joined #heat08:57
*** tomek_adamczews1 has quit IRC08:58
therveskraynev, 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 IRC08:58
therve(using https://review.openstack.org/#/c/80528/)08:58
*** tomek_adamczewsk has joined #heat08:58
*** jistr has quit IRC08:59
*** jamie_h_ has joined #heat08:59
*** jamie_h_ has quit IRC09:00
*** liang has joined #heat09:04
lsmola_shardy: hello, are you around09:08
lsmola_shardy: ?09:08
*** mkollaro has joined #heat09:11
shardymorning all09:12
shardylsmola_: Hi!09:12
cmystermorning09:12
lsmola_shardy: good morning09:13
lsmola_shardy: was you way back good?09:13
skraynevtherve: 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 :-D09:14
lsmola_shardy: I have one tiny question about http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Heat::UpdateWaitConditionHandle09:14
cmysterlsmola_: no such thing :)09:14
therveskraynev, Hum yeah interesting. That could work too though09:14
lsmola_:-)09:14
lsmola_shardy: can I use one handle for multiple completion conditions?09:15
shardylsmola_: haha, yeah likewise, although I still ended up at a beer festival on Saturday night ;)09:15
shardylsmola_: Yes you can specify a count09:15
cmysterlsmola_: in what syntax?09:15
cmysterbut ^09:16
*** jistr has joined #heat09:16
shardylsmola_: http://docs.openstack.org/developer/heat/template_guide/cfn.html#AWS::CloudFormation::WaitCondition09:16
lsmola_shardy: cmyster example http://paste.openstack.org/show/74113/09:16
shardyYou must pass a different UniqueId value for each bit of data passed to the Handle09:17
cmysterthis, is long09:18
lsmola_shardy: I am not really sure I get that :-)09:19
shardylsmola_: 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/129190509:19
uvirtbotLaunchpad 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
cmysterbtw 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 wanted09:22
cmysterdefine*09:22
shardylsmola_: 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 signals09:22
lsmola_shardy: it defines number of signals the handle must receive?09:22
shardylsmola_: yes that's what "Count" does09:23
openstackgerritDong Liu proposed a change to openstack/heat: router add dependence to subnet  https://review.openstack.org/8245209:23
*** IgorYozhikov has joined #heat09: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
shardylsmola_: No, you only ever associate one Handle with one condition09:25
shardyso you can either have 4 handles and 4 conditions, or 1 handle, and 1 condition with a "Count" of 409:26
lsmola_shardy: hm09:26
lsmola_shardy: so I am trying to figure out what zaneb means here https://bugs.launchpad.net/tripleo/+bug/129190509:26
uvirtbotLaunchpad 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 all09:26
*** e0ne_ has joined #heat09:27
lsmola_shardy: 'works' cause it has already created resource so the handle condition is not failing on that09:27
*** dteselkin has joined #heat09:27
lsmola_shardy: it's the #10 comment09:28
shardylsmola_: I don't really see how that's related to what we're discussing, which is multiple conditions and/or signals?09:29
shardyzaneb 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" stack09:29
*** e0ne has quit IRC09:29
shardyergo, it's in the new stack when you need it, so should work (probably)09:30
lsmola_shardy: hm09:30
lsmola_shardy: but still when I add new resource with Compute1ConditionHandle09:31
lsmola_shardy: it doesn't see that handle, cause it is only in the new template09: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 same09:33
lsmola_shardy: so it is always there09:33
shardylsmola_: 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 #heat09:35
lsmola_shardy: and with adding two resources it failed for me09:35
*** renlt has quit IRC09:35
*** lindsayk has quit IRC09:36
lsmola_shardy: even when all events are correctly completed09:36
*** alienyyg has quit IRC09:36
*** alienyyg has joined #heat09:36
shardylsmola_: Yeah it won't work, because the signal data is stored with the Handle not the Condition09:37
lsmola_shardy: hmm right, that would explain why adding one works, but adding two not09:38
lsmola_shardy: so is hack like this possible some other way?09:39
shardylsmola_: tbh I'm not sure - you're probably best updating the bug with details of what you've tried and continuing your discussion with zaneb09:40
shardylsmola_: I'll try a few things later this morning and see if I can offer any suggestions too09:41
lsmola_shardy: ok, cool, thank you very much09:41
lsmola_shardy: one last question09:42
lsmola_shardy: can I define the handle and the completion condition once09:43
lsmola_shardy: and then somehow reference it from Compute resources?09:43
lsmola_shardy: so every COmpute will call it once?09:43
shardylsmola_: yes, you could create one WaitCondition, one UpdateWaitConditionHandle, and pass the reference to the same handle into each compute resource09:45
shardyThen you specify "Count" of the WaitCondition to match the number of compute resources you expect signals from09:45
shardyas I mentioned, you will need some way to pass a different unique ID (e.g the resource name)09:45
shardyhttps://github.com/openstack/heat/blob/master/heat/engine/resources/wait_condition.py#L7609: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
shardylsmola_: give me 5mins to make another coffee and I'll make a template example for you09:48
lsmola_shardy: can I just past parameteters with ref: ?09:48
lsmola_shardy: excellent, thank you very much09:49
openstackgerritChmouel Boudjnah proposed a change to openstack/heat: Fix creating container.  https://review.openstack.org/8245709:54
* lsmola_ is going to lunch09:56
openstackgerritDong Liu proposed a change to openstack/heat: Add subnets as a dependency for router  https://review.openstack.org/8245209:59
openstackgerritChmouel Boudjnah proposed a change to openstack/heat: Display container ip not gateway IP  https://review.openstack.org/8245810:00
thervechmouel, The privileged thing depends on docker version :/10:07
chmoueltherve: really? i could not find it in the docker-py git history10:07
*** DaveJ__ has joined #heat10:07
thervechmouel, https://github.com/dotcloud/docker-py/commit/64781888e06824f6beac5a6ccc4afd85109ecf30#diff-5262437d121a30fc85a81c4b1da57e4b10:07
chmoueltherve: should we just 'fix' the requirement file or do some silly introspection to handle that case?10:08
therveNot sure10:09
chmouelor just assume master i guess10: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 cfninitdata10:09
DaveJ__Is there anyway to override this ?10:09
thervechmouel, I think at the very least I would only pass it if the value is True10:09
therveThis way it works with the older version on the default case10:09
therveDaveJ__, You need to use user_data_format to RAW10:09
chmoueltherve: true true but in that case that would need to be done for every other resources10:09
cmysterbrb f00d10:09
thervechmouel, "that" what?10:10
DaveJ__therve:  What is 'user_data_format to RAW' do you have an example ?10:10
therveDaveJ__, https://github.com/openstack/heat-templates/blob/69608faeedb474a4597f965786a1a1d2ac475899/hot/software-config/example-cloud-init.yaml#L9810:10
chmoueltherve: that mean if we do 'that' way :)10:11
thervechmouel, Other projects care about backward compatibility in general :)10:11
therveIt'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 launch10:16
therveYes10:16
sgranDaveJ__: mostly the AWS templates work.  The native resources tend to be more feature complete, however10:16
thervetemplates != resources though10:16
therveYou can use OS::Nova::Server in a CFN template10:16
sgrantrue10: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 bucash10:20
*** bucash is now known as aignatov10:20
therveLooks like you're asking a bit too much :)10:21
*** jistr has quit IRC10: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 #heat10:27
shardyDaveJ__: 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 behavior10:27
shardyDaveJ__: The native OS::Nova::Server resource is preferred for users who don't require portability to CFN tho10:28
DaveJ__shardy:  Yep that makes sense.10:28
shardyDaveJ__: 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 work10:29
therveDaveJ__, 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 IRC10:33
*** matsuhas_ has joined #heat10:35
*** duncanjw has quit IRC10:37
*** david-lyle has quit IRC10:41
lsmola_shardy: wait, this hack works, it was just my local keystone error previously10:44
*** duncanjw has joined #heat10: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 Compute210:46
lsmola_shardy: and they use handle that is named the same10:46
*** alienyyg has quit IRC10: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 #heat10: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 :-D10:49
*** fandi has quit IRC10:49
shardylsmola_: 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 up10:51
lsmola_shardy: e.g. the NovaCompute1 resource was added only when nova cmopute 1 was finished10:51
lsmola_shardy: so seems like there is another condition, that makes this work :-)10:52
openstackgerrithuangtianhua proposed a change to openstack/heat: Fix stack-show failed with a name in uuid format  https://review.openstack.org/8247110: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 IRC10:53
lsmola_shardy: hm also the completion conditions seems to have different timestamp10: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 :-D10:55
shardylsmola_: it's a perplexing phenomenon called "luck" :D10:56
lsmola_shardy: hehe10:56
*** mkollaro has quit IRC10:56
*** nkhare_ has quit IRC10: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 it10:57
shardylsmola_: no, the data is stored in metadata associated with the Handle resource, not the condition10:58
shardythe implementation is a bit weird, as it would be better if the data was associated with the Condition, but it's not10:58
lsmola_shardy: I see, the signal knows only about the handle11:00
shardyYeah and internally, the WaitCondition looks at the data associated with the Handle11: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 likely11:02
* lsmola_ is confused11: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
shardylsmola_: I don't really understand "5 conditions as dependencies"11:07
lsmola_shardy: http://paste.openstack.org/show/74122/11:07
*** matsuhas_ has quit IRC11: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 receive11:08
lsmola_shardy: if it sums all the related conditions, this could be a hidden feature :-D11:09
lsmola_shardy: or the reason why it is completed after last handle might be elsewhere :-)11:10
*** mkollaro has joined #heat11:19
*** nosnos has quit IRC11:23
*** alienyyg has quit IRC11:27
*** alienyyg has joined #heat11:28
*** chandankumar_ has joined #heat11:29
shardylsmola_: http://paste.fedoraproject.org/88017/6051913911:29
shardyYou will see that wait_condition2 takes 60s longer to complete that wait_condition, beacuse of the Count11:29
*** sergmelikyan has joined #heat11:32
*** alexheneveld_ has joined #heat11:37
*** _ruhe_ has joined #heat11:37
*** _ruhe_ has quit IRC11:38
*** alexheneveld has quit IRC11:38
*** alexheneveld_ is now known as alexheneveld11:38
*** _ruhe_ has joined #heat11: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 two11:39
lsmola_shardy: can't find code that is deciding that11:39
shardylsmola_: 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
shardyhttps://github.com/openstack/heat/blob/master/heat/engine/resources/wait_condition.py#L7711:40
shardylsmola_: 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 Icehouse11: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/c9WtvOkK11:42
*** alexheneveld_ has joined #heat11:43
DaveJ__This works, and executes the cloud-config script, creating the file in /tmp.11:43
DaveJ__https://www.irccloud.com/pastebin/q2EJQiRy11:43
*** aweiteka has joined #heat11: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 IRC11:44
*** alexheneveld_ is now known as alexheneveld11:44
*** randallburt has joined #heat11:45
*** randallburt has quit IRC11:45
shardylsmola_: http://paste.fedoraproject.org/88020/5661534111:46
*** randallburt has joined #heat11:46
openstackgerritA change was merged to openstack/heat: Don't re-bind parameters during stack update  https://review.openstack.org/8167811:46
shardyas I said earlier, both conditions will complete as soon as the first signal hits the handle11:46
shardylsmola_: I think your workaround is to use UpdateWaitConditionHandle, and probably also to use Count11:46
*** faramir1 has joined #heat11:47
shardylsmola_: if you think that won't work, please update the bug with some minimal examples (based on what I just pasted) and steps to reproduce11:47
shardylsmola_: one of the barriers atm is the complexity of your template examples, so we really need some simple reproducers11:47
lsmola_shardy: ok, so it has to be something else in dependency chain that prevents it from completing11:48
openstackgerritJenkins proposed a change to openstack/heat: Updated from global requirements  https://review.openstack.org/7668911:48
shardyDaveJ__: If it works on cfn but not heat, please raise a bug with details and we can try to look into it11:48
therveDaveJ__, It's a bit weird that we don't have the same default behavior as AWS11:48
lsmola_shardy: yeah it will get better when rewritten to provider resource and hot software config11:48
lsmola_shardy: ok, thanks for the help, I am going to investigate this more11:49
therveIf there is no AWS::CloudFormation::Init maybe we should default to RAW there11: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 #heat11:53
*** nosnos has joined #heat11:54
openstackgerritJenkins proposed a change to openstack/python-heatclient: Updated from global requirements  https://review.openstack.org/7669811:54
*** rpothier has quit IRC11:56
*** networkn8 has joined #heat12:00
*** rbuilta has joined #heat12:11
*** chandankumar_ has quit IRC12:13
*** matsuhashi has quit IRC12:14
*** lipinski has joined #heat12:14
therveshardy, Have you seen my comment on https://review.openstack.org/#/c/80034/ ?12:16
*** matsuhas_ has joined #heat12:17
shardytherve: which comment?  I replied to your loglevel remark?12:18
therveDid you? Hum I missed it12:19
therveAh yeah thanks12:19
shardytherve: I think maybe you missed the switch to default log level of WARNING in https://review.openstack.org/#/c/79487/212:19
shardy:)12:19
therveOK cool12:20
openstackgerritSergey Kraynev proposed a change to openstack/heat: Initial validation of functions  https://review.openstack.org/8248612:21
openstackgerritSergey Kraynev proposed a change to openstack/heat: Validation functions for resources and outputs  https://review.openstack.org/8248712:21
openstackgerritSergey Kraynev proposed a change to openstack/heat: Adding validation algorithm for get attr functions  https://review.openstack.org/8248812:21
*** e0ne_ has quit IRC12:24
*** radez_g0n3 is now known as radez12:26
*** ZZpablosan is now known as pablosan12:33
*** rpothier has joined #heat12:36
* IgorYozhikov is now away: went away...12:44
*** IgorYozhikov is now known as IYozhikov_away12:44
*** networkn81 has joined #heat12:45
*** networkn8 has quit IRC12:48
*** e0ne has joined #heat12:55
*** denis_makogon has joined #heat12:57
*** e0ne has quit IRC12:59
*** alexpilotti has quit IRC13:00
*** rbuilta has quit IRC13:07
*** e0ne has joined #heat13:11
*** matsuhas_ has quit IRC13:12
*** matsuhashi has joined #heat13:13
openstackgerritPavlo Shchelokovskyy proposed a change to openstack/python-heatclient: Use correct order of arguments to assertEqual  https://review.openstack.org/8249813:14
*** matsuhashi has quit IRC13:17
*** cmyster has quit IRC13:19
*** BillArnold_ has quit IRC13:21
tspatzierHi 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 russellb13:23
*** nosnos has quit IRC13:24
*** nosnos has joined #heat13:25
*** radez is now known as radez_g0n313:25
randallburttspatzier:  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 IRC13:29
tspatzierrandallburt: 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
randallburttspatzier:  haven't heard it come up before, but sounds like a bug to me.13:31
tspatzierI 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 #heat13:32
randallburttspatzier:  yeah, it sounds a little confusing. there's are missing request/response examples too last time I looked.13:33
*** mwheckmann has joined #heat13:34
tspatzierrandallburt: 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
tspatziers/custom/cut-off/13:35
randallburttspatzier:  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
randallburtafa i18n, I'm not sure.13:36
openstackgerritSergey Kraynev proposed a change to openstack/heat: Validation functions for resources and outputs  https://review.openstack.org/8248713:37
openstackgerritSergey Kraynev proposed a change to openstack/heat: Adding validation algorithm for get attr functions  https://review.openstack.org/8248813:38
tspatzierOk, 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 IRC13:38
randallburttspatzier:  k. sounds good to me.13:43
*** jrist has joined #heat13:44
*** radez_g0n3 is now known as radez13:46
openstackgerritChmouel Boudjnah proposed a change to openstack/heat: Fix creating docker containers  https://review.openstack.org/8245713:49
*** daneyon has joined #heat13:51
*** daneyon has quit IRC13:52
*** daneyon has joined #heat13:52
*** rcleere has quit IRC13:54
*** wchrisj has joined #heat13:54
*** pas-ha has quit IRC13:56
*** daneyon_ has joined #heat13:58
*** daneyon has quit IRC13:58
*** nosnos has joined #heat13:58
*** matsuhashi has joined #heat13:59
*** daneyon_ has quit IRC13:59
*** nosnos has quit IRC14:00
*** nosnos has joined #heat14:01
*** aweiteka has quit IRC14:02
*** vijendar has joined #heat14:02
openstackgerritChmouel Boudjnah proposed a change to openstack/heat: Display container ip not gateway IP  https://review.openstack.org/8245814:05
*** nosnos has quit IRC14:05
*** cfriesen has joined #heat14:07
*** nosnos has joined #heat14:11
*** varora has left #heat14:11
*** skraynev is now known as skraynev_afk14:12
*** varora has joined #heat14:13
*** alienyyg has quit IRC14:13
*** nosnos has quit IRC14:14
openstackgerritChmouel Boudjnah proposed a change to openstack/heat: Display container ip not gateway IP  https://review.openstack.org/8245814:16
*** matsuhashi has quit IRC14:16
*** rwsu has joined #heat14:17
*** aweiteka has joined #heat14:17
openstackgerritChmouel Boudjnah proposed a change to openstack/heat: Add docker network_gateway attribute  https://review.openstack.org/8251114:18
openstackgerritA change was merged to openstack/python-heatclient: Output warnings for deprecated commands  https://review.openstack.org/8003414:20
*** ramishra has joined #heat14:21
openstackgerritChmouel Boudjnah proposed a change to openstack/heat: Display container ip not gateway IP  https://review.openstack.org/8245814:24
*** rcleere has joined #heat14:27
*** matsuhashi has joined #heat14:32
chmouelis there a --force cleanup kind of thing when a resource cannot fail to get cleaned for some reason?14:37
shardychmouel: 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 works14:38
chmouelshardy:  well as an example I am trying out the docker container which failed to start for some reason14:38
chmouelshardy: if i want to try to delete it would just say cannot delete since it doesn't exist14:39
chmouelshardy: is it by design or it needs a fix in the docker client ?14:39
shardychmouel: that's a bug, most resources tolerate NotFound exceptions and treat it as a successful delete14:39
*** saju_m has quit IRC14:39
chmouelshardy: ok cool make sense14:39
chmouelshardy: will log a bug/fix14:39
*** cmyster has joined #heat14:41
*** cmyster has joined #heat14:41
shardychmouel: Yeah, there should be a try/catch around the kill here:14:41
shardyhttps://github.com/openstack/heat/blob/master/contrib/docker/docker/resources/docker_container.py#L24314:41
chmouelshardy: yep, thanks!14:42
*** david-lyle has joined #heat14:43
*** zns has joined #heat14:45
*** radez is now known as radez_g0n314:47
*** dims has quit IRC14:47
openstackgerritChmouel Boudjnah proposed a change to openstack/heat: Display container ip not gateway IP  https://review.openstack.org/8245814:52
*** wchrisj has quit IRC14:54
*** IlyaE has joined #heat14:56
*** pas-ha has joined #heat14:58
pas-hachmouel: 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 #heat14:59
pas-hawould like to take a look14:59
*** kgriffs_afk is now known as kgriffs15:00
*** dims has joined #heat15:00
*** radez_g0n3 is now known as radez15:01
*** duncanjw_ has joined #heat15:05
*** jmckind has joined #heat15:06
*** duncanjw has quit IRC15:06
cmystershardy: spare 5 minutes ?15:07
shardycmyster: sure15:09
openstackgerritDong Liu proposed a change to openstack/heat: Add subnets as a dependency for router  https://review.openstack.org/8245215:09
*** mspreitz has joined #heat15:12
*** duncanjw_ has quit IRC15:13
SpamapSzaneb: https://bugs.launchpad.net/tripleo/+bug/1291905 <-- lsmola_ has explained this to me now15:14
uvirtbotLaunchpad bug 1291905 in tripleo "heat stack-update fails on timeout" [High,Triaged]15:14
SpamapSzaneb: there is a bug15:14
SpamapSzaneb: the problem is that during an update, new wait condition handles cannot be accessed15:14
SpamapSzaneb: updatewaitconditionhandle isn't really "the answer".. it is a workaround.15:15
zanebSpamapS: yes, I'm aware of that15:15
openstackgerritCyril Roelandt proposed a change to openstack/python-heatclient: Do not use the '+' operation dict_items()  https://review.openstack.org/8252315:15
SpamapSzaneb: seems like we could fix the code path to not look up the new handle through the old template15: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 workaround15:15
SpamapSzaneb: yeah, but I didn't fully understand15:15
zaneblsmola_: I'm writing a comment as we speak15:15
SpamapSlsmola_: the workaround is as you said.. use one handle, and update the count15: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
SpamapSbut 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
zanebSpamapS: will the existing server post to the WaitConditionHandle again during an update, even though it isn't being replaced?15:16
SpamapSzaneb: we're not replacing a server15:16
zanebi.e. do we need to increase the Count when adding a server?15:16
SpamapSAnd don't plan to ever use that.15:17
SpamapSWe create, rebuild, or delete.15:17
zanebSpamapS: 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/115:18
SpamapSzaneb: We want a condition per server15:19
lsmola_zaneb: SpamapS due to the our dependencies, it actually waits for all computes15:19
SpamapSzaneb: in software-config, that's what we'll have15:19
SpamapShm15:19
SpamapSthat makes me think15:19
SpamapSperhaps the answer is "just use software-config"15:19
SpamapSBecause those conditions are tied to the config resource + server ... not a specific handle.15:20
zanebSpamapS: how can we have a condition per server, if we're adding a server but can't add conditions?15:20
SpamapSzaneb: we did add a condition15:20
*** beekneemech is now known as bnemec15:20
SpamapSzaneb: and it is not accessible15:20
zanebsorry, can't access new handles15:20
SpamapSzaneb: because we try to load it via the old template15:20
lsmola_SpamapS: well with ResourceGroup, we will have only one condotion with count most probably15:20
zanebwhich is the only one in the database15:20
SpamapSwhich is, I think, a straight forward bug15:20
lsmola_SpamapS: or AutoscalingGroup15:21
SpamapSzaneb: we have a stack + resource name in the db15:21
SpamapSit is CREATE_COMPLETE15:21
lsmola_SpamapS: cause we won't be copypasting the resources15:21
zanebSpamapS: https://bugs.launchpad.net/tripleo/+bug/1291905/comments/715:21
uvirtbotLaunchpad bug 1291905 in tripleo "heat stack-update fails on timeout" [High,Triaged]15:21
SpamapSlsmola_: no, we will have a stack per, because software-config does that :)15:21
zanebSpamapS: lsmola_ investigated this already, and it is a bear to fox :(15:21
zanebs/fox/fix/15:22
SpamapSYeah, this is the same old problem.15:22
SpamapSnot storing the template snippets with the resources15:22
SpamapSdamnit15:22
* lsmola_ scratches his head15:22
zanebonce upon a time we used to store the template snippets with the resources15:23
SpamapSThis will likely cause the same problem in software-config too15:23
SpamapSzaneb: _what_ ?15:23
zanebthen I killed it15:23
* SpamapS braces for where zaneb explains how this jerk SpamapS raised hell about it a year ago15:23
SpamapSoh good15:23
zanebbecause it seemed like we were storing heaps of redundant data15:24
SpamapSturns 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 template15:24
lsmola_SpamapS: so it should be one code, with one template, etc.15:24
SpamapSlsmola_: 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
SpamapSzaneb: and really, you need the snippet + parameters15:25
zanebSpamapS: yeah, iirc we stored the snippet completely resolved15:25
*** matsuhashi has quit IRC15:25
zanebwhich made it useless in many ways15:25
lsmola_SpamapS: I think it should work correctly, heat can do any kind of magic :-D15:26
SpamapSzaneb: 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 #heat15:26
zanebbut in retrospect, was useful for locking in the old parameters15:26
SpamapSzaneb: but that is definitely "major surgery"15:26
zanebindeed15:26
lsmola_SpamapS: zaneb yep, I am trying to find a solution for next 3 weeks15:26
zaneblsmola_: I just posted another comment which should explain the workaround in more detail15:26
SpamapSbut 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
SpamapSlsmola_: well software-config may be.. tomorrow.. so we need to figure out something for that too15:27
SpamapSstevebaker: when you're up and around.. have you tested software-config with updates when adding a new server?15:28
SpamapSI'm guessing it has no chance at working. :(15:28
*** matsuhas_ has joined #heat15:28
SpamapSWhich is fine, we can just use NO_SIGNAL and keep our old wait condition handles15:29
SpamapSlsmola_: thanks for testing early. This helps me plan :)15:29
*** packet has joined #heat15:29
lsmola_SpamapS: :-)15:29
zaneblsmola_: 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 templates15:30
lsmola_SpamapS: shardy shadower might be good to have a short hangout about that15:31
SpamapSlsmola_: 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 new15:31
SpamapSlsmola_: resource groups have a big problem15:32
SpamapSlsmola_: count-- == death of the newest server15:32
SpamapSlsmola_: 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 kill15:32
SpamapSremove_servers: [4, 1, 5]15:33
lsmola_SpamapS: there is a bp for the in heat somewhere15:33
*** matsuhas_ has quit IRC15:33
SpamapSlsmola_: that is a bug IMO15:33
*** jpeeler has joined #heat15:33
lsmola_SpamapS: yeah :-)15:33
*** vijendar has quit IRC15:33
*** andersonvom has joined #heat15:34
lsmola_SpamapS: right, so now when you want to delete certain resoruce, you just delete it from template?15:34
*** vijendar has joined #heat15:35
SpamapSlsmola_: precisely15:35
lsmola_SpamapS: but then you cant upscale using merge.py, so..15:35
SpamapSlsmola_: precisely15:35
lsmola_:-)15:35
SpamapSlsmola_: 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 way15:36
SpamapSlsmola_: 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
SpamapSor not to fill in the gaps.. but to fill in the count15:37
SpamapSlsmola_: we should always focus on the heat way15:37
SpamapSmerge.py was written as a POC that was supposed to land in Heat .. quickly15:37
SpamapSbut turns out a lot of people had opinions on how software configs should be decoupled from servers15:37
lsmola_SpamapS: yeah15:38
SpamapSand now we're almost ready to deprecate that bit..15:38
SpamapSand we'll have to push hard on getting scaling right in Heat so we can fully deprecate it.15:38
*** wchrisj has joined #heat15:38
lsmola_SpamapS: yes, we will be pushing that way too :-)15:38
SpamapSLet's not wait though15:39
SpamapSWe're close enough to release.. you can push patches up now that will land shortly after unfreeze :)15:39
lsmola_SpamapS: yes15:40
lsmola_SpamapS: shardy shadower let me know when you are ready for the hangout15:41
lsmola_SpamapS: we had a big Heat brainstorming last week :-)15:42
lsmola_SpamapS: ok so, regarding the completion condition15:42
lsmola_SpamapS: could I push it the way of one Condition and Handle?15:43
SpamapSlsmola_: yeah.15:43
SpamapSlsmola_: and link that bug to TripleO15:43
lsmola_SpamapS: yeah it already is I think15:43
SpamapSlsmola_: also retitle it.. I think we know what the real problem is now.. new resources are not available for signalling during an update15:43
lsmola_SpamapS: yes15:44
lsmola_SpamapS: done15:45
lsmola_SpamapS: now, I could put there the total count via merge.py15:45
lsmola_SpamapS: but it might be better to start parameter for that, as this will be used in groups later15: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 that15:46
lsmola_SpamapS: even when there is no rebuilding, could it be possible zaneb ?15:47
shadowerum what hangout15:47
* shadower reads back15:47
zaneblsmola_: it's possible, I don't know how SpamapS's in-instance stuff works15: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 all15:48
lsmola_zaneb: ok15:48
lsmola_shadower: about joining our effort of rewriting of the templates :-)15:48
*** mutex has left #heat15:48
mspreitzlsmola_: 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 tempaltes15:49
* shadower is a bit wary of dragging a bunch of people from disparate tzs into meetings15:49
shadowersurely a mailing list is a better and more open solution?15:49
zaneblsmola_: 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
shadowerthe mailing list even15:50
mspreitzlsmola_: 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 :-D15:50
lsmola_shadower: whatever suits you15:50
lsmola_zaneb: ok, will try15:51
lsmola_zaneb: I thought the events are result of the completion handle15:51
zaneblsmola_: events are the result of the stack update15:51
lsmola_mspreitz: yes basically, we need to rewrite it to latest cool stuff :-)15:52
lsmola_mspreitz: mainly to avoid the copypasting15:52
lsmola_zaneb: ok15:52
*** duncanjw has joined #heat15:54
lsmola_shadower: could you send the email with the examples you have created?15:55
SpamapSlsmola_: yes, the count should be all, not just new15:55
SpamapSlsmola_: that was the point of making UpdateWaitConditionHandle15:55
lsmola_SpamapS: yeah it got to me :-) ok, will try that15: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.py15:57
sdakezaneb  trivial review if you want to pump your stats up:) https://review.openstack.org/#/c/82386/15:58
zanebooh, stats :)15:58
sdakezaneb anyway I would like your comments15:58
sdakesince you and stevebaker seemed pretty locked into using super()15:59
SpamapSlsmola_: 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
sdakeI found using super() expects a function exist to call, so there wasn't a way to get the ancestor class15:59
*** blamar has joined #heat15:59
*** blamar has quit IRC15:59
lsmola_SpamapS: ok16:00
*** blamar has joined #heat16:00
zanebsdake: I don't understand the reference to super()?16:00
SpamapSnor I16:01
sdakezaneb maybe that was stevebaker's suggestion16:01
sdakereference to super() is that review above16:01
sdakezaneb^16:01
zanebsdake: I'm looking at the review and I don't understand the connection to super()16:03
zanebsdake: would isinstance(e, heat.common.exception.HeatException) not work?16:03
zanebor, even better16:04
*** ifarkas has quit IRC16:04
zanebexcept heat.common.exception.HeatException:16:04
zaneb    raise rpc_common.ClientException()16:04
sdakezaneb NotFound is not a HeatException16:07
*** vijendar has quit IRC16:07
sdakezaneb I didn't try isinstance16:07
zanebsdake: shouldn't we make it one?16:07
sdakezaneb NotFound is an "Error" exception16:08
sdakeI didn't really understand the difference in the base class16:08
sdakeI was a bit hestitant to change the base class - assuming there is some reason they are not the same16:08
sdakeNotFound is in heat.common.exception16:08
zanebhttps://github.com/openstack/heat/commit/1584bc17bb748a8b93f03781e1e210182b2708d316:08
zanebthat's where it came from16:09
sdakehow do you git blame on github so fast?16:09
zanebIIRC I originally copied NotFound from openstack,.common.exception because it seemed like a waste to define a new one16:09
zanebsince that module doesn't exist any more, I don't see any reason for that one to be treated differently16:10
zanebsdake: I was already looking at the file, so I just clicked 'Blame' ;)16:10
sdakeya analsysis makes sense16:10
sdakezaneb cool that must be a  recent rfeature to github16:11
zanebI don't believe so ;) But it sure is a PITA to use if you have to go back more than one change16:12
zanebe.g. if the line has had a whitespace change16:12
sdakeI''ll add an empty rebase at the head of that change, and then merge the base classes16:13
zanebso you want to do a blame on the previous revision16:13
*** mspreitz has quit IRC16:13
zanebrequires about 15 clicks or manual editing of the URL :(16:13
zanebqgit is much better16:13
*** vijendar has joined #heat16:18
*** sdake_ has joined #heat16:18
*** sdake_ has quit IRC16:18
*** sdake_ has joined #heat16:18
sdake_zaneb assuming isinstance works, I presume you believe that is a better way to fix this problem?16:20
zanebThe better way would be to only catch HeatException and not have any conditionals at all16:21
zanebwhich will work if isinstance works16:21
zanebso I'd say that is strictly preferable to isinstance16:21
sdake_other exceptions besdies heatexception can occur16:21
sdake_so you mean get rid of the conditional test and then use catch exception.HeatException?16:23
zanebsdake_: yes16:26
zanebexcept heat.common.exception.HeatException:16:26
zaneb    raise rpc_common.ClientException()16:26
zaneband let the rest handle themselves16:26
openstackgerritTomas Sedovic proposed a change to openstack/heat: Don't create cloud-init user unless specified  https://review.openstack.org/7967816:28
sdake_zaneb interesting, isinstance matches against anything in the mro it looks like16:29
sdake_zaneb your suggestion works16:30
zanebyes, it includes all subclasses16:30
sdake_if something uses a try/ctch, and the catch doesn't catch the raised exception16:30
sdake_is the exception reraised out of the try?16:30
zanebyes, if you don't catch an exception it continues to propagate16:34
sdake_cool thanks zanb16:35
sdake_zaneb16:35
*** nati_ueno has quit IRC16:35
openstackgerritChmouel Boudjnah proposed a change to openstack/heat: Add docker network_gateway attribute  https://review.openstack.org/8251116:39
openstackgerritCyril Roelandt proposed a change to openstack/python-heatclient: Python3: fix a bytes/str issue  https://review.openstack.org/8254316:40
openstackgerritCyril Roelandt proposed a change to openstack/python-heatclient: Python3: fix a bytes/str issue  https://review.openstack.org/7793816:42
*** IlyaE has quit IRC16:43
openstackgerritRoman Podoliaka proposed a change to openstack/heat: WIP: heat engine parameters unicode  https://review.openstack.org/8254516:44
openstackgerritCyril Roelandt proposed a change to openstack/python-heatclient: Do not use the '+' operation with dict_items()  https://review.openstack.org/8252316:44
*** packet has quit IRC16:46
*** tspatzier has quit IRC16:47
*** pvaneck has joined #heat16:48
*** harlowja has joined #heat16:49
*** shakayumi has joined #heat16:51
*** shakayumi has quit IRC16:51
*** alexheneveld has quit IRC16:52
* sdake_ groans - 68 test case failures to change base class of NotFound16:54
sdake_oh well time to tackle this afternoon16:54
sdake_have to run for a meeting thanks zaneb for taking a look16:54
zanebnp16:54
* zaneb starts thinking about lunch16:54
*** shakayumi has joined #heat17:00
*** shakayumi has quit IRC17:01
*** zns has quit IRC17:01
*** zns has joined #heat17:02
*** IlyaE has joined #heat17:08
*** ifarkas has joined #heat17:14
*** e0ne has quit IRC17:14
openstackgerritA change was merged to openstack/heat: Refactor CLB to work with groups  https://review.openstack.org/6558617:14
shardyandersonvom: Hi, around?17:15
*** nati_ueno has joined #heat17:17
*** yogesh has joined #heat17:30
*** jaustinpage has joined #heat17:32
*** jistr has quit IRC17:36
*** duncanjw has quit IRC17:38
*** fandi has joined #heat17:39
*** duncanjw has joined #heat17:41
cmysterevening btw17:44
*** IlyaE has quit IRC17:45
*** IlyaE has joined #heat17:48
lipinskiAre nested provider templates supported?17:48
lipinskiI'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
lipinskiThe engine is not finding the second (nested) resource type17:49
andersonvomshardy: yup17:52
*** kgriffs is now known as kgriffs_afk17:53
*** duncanjw has quit IRC17:53
*** derekh has quit IRC17:54
shardyandersonvom: hey!17:55
shardyandersonvom: I'm working on some tempest tests, and decided to do one for the new stack list query args17:56
shardyandersonvom: I have a couple of quick questions..17:56
andersonvomshardy: shoot17:56
shardyThe limit argument limits from the *end* of the list, is that expected?17:56
openstackgerritJeff Peeler proposed a change to openstack/heat-templates: Add template for separated node/broker OpenShift  https://review.openstack.org/8163217:57
harlowjahmmm, murano murano, murano17:58
shardyandersonvom: #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
shardyandersonvom: again, is that expected and what we want?17:59
andersonvomshardy: what do you mean with "limits from the end of the list"?18:00
andersonvomshardy: fwiw, both limit and marker are being used as other projects use them.18:01
shardyandersonvom: Ok, I mean if I list without any limit, then with a limit=1, I get the last item in the list18:03
therveharlowja, Please complain :/18:03
harlowjalol18:03
shardyandersonvom: I was kinda expecting the first, and to be able to step thru the list from the top with marker18:03
therveI don't think they heard enough yet18:03
harlowjalol18:03
shardyandersonvom: but it's entirely possible I'm just expecting the wrong thing :)18:03
harlowjatherve are u sure?18:03
harlowjaeverytime i look at https://wiki.openstack.org/wiki/Murano/DSL/Blueprint#Block_constructs i get confused, lol18:04
therveharlowja, It's wrong in some many ways. They have to understand that it will block their graduation. Or so I hope.18:04
harlowjatherve ya, i think they are probably tired of hearing me and zaneb complain, lol18:05
andersonvomshardy: 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
harlowjai was looking over the code and although its neat and all, i don't get it still :-P18:06
harlowjahttps://github.com/stackforge/murano-api/tree/master/muranoapi/engine18:06
harlowjait seems like a mix of java, python, yaml, yaql18:06
*** tango has joined #heat18:06
harlowjahttps://github.com/stackforge/murano-api/blob/master/muranoapi/engine/class_loader.py18:06
harlowjaeven has class loaders18:06
*** jmckind has quit IRC18:09
*** jmckind has joined #heat18:10
andersonvomshardy: oh... it's a problem with the python-heatclient18:12
*** IlyaE has quit IRC18:12
andersonvomshardy: the API actually works correctly, but, for some reason, the heat client is returning the list backwards18:12
shardyandersonvom: aha!18:12
shardytesting ftw! :)18:12
shardyandersonvom: hrm, although I think my tempest test isn't actually using heatclient (it's an API not scenario test)18:13
andersonvomshardy: interesting. when I try just the API call with and without limit, I get the behavior we were expecting.18:18
andersonvomon master18:18
shardyandersonvom: Ok thanks, I must have some issue with either my test or environment then18:21
shardyandersonvom: re the second point, do you think we need to add action as a query filter?18:21
shardyandersonvom: e.g so you can do action=CREATE&status=COMPLETE18:22
andersonvomshardy: 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
andersonvomshardy: but I agree, we could add action as well. it has its uses too.18:23
andersonvoms/it it/it would/18:23
shardyandersonvom: Ok, sounds good, then perhaps when we move to a v2 API we can decouple stack_status to be action/status in the stack response18:24
* andersonvom thinks there should be a plugin for irssi that would actually run the replace command on your lines.18:24
andersonvomshardy: +2 for decoupling18:25
shardyhaha, somehow rewrite history in everyone's client, or maintain a local 30s "typo buffer" :)18:25
* shardy could use one of those18:25
*** jpeeler has quit IRC18:26
*** alexheneveld has joined #heat18:26
*** mestery has joined #heat18:27
*** mestery has quit IRC18:29
*** e0ne has joined #heat18:30
*** alexheneveld has quit IRC18:36
*** mkollaro has quit IRC18:36
*** IlyaE has joined #heat18:41
*** lipinski has quit IRC18:41
*** ramishra has quit IRC18:47
*** ramishra has joined #heat18:48
*** aweiteka has quit IRC18:49
*** yogesh has quit IRC18:52
*** ramishra has quit IRC18:52
*** rbuilta has joined #heat18:53
*** yogesh has joined #heat18:54
*** mspreitz has joined #heat18:57
*** zns has quit IRC18:58
*** mdelder has joined #heat18:58
mdelderHi, 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 #heat19:00
*** harlowja has quit IRC19:01
*** aweiteka has joined #heat19:02
* mspreitz eagerly listens for a response19:02
*** harlowja has joined #heat19:03
*** lindsayk has joined #heat19:04
*** BillArnold_ has joined #heat19:09
*** jprovazn has quit IRC19:10
mspreitzLet'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
zanebharlowja: lol19:15
harlowjazaneb u should propose using http://en.wikipedia.org/wiki/Brainfuck instead19:16
harlowjalol19:16
zanebI still have to get through all the new mails in that thread19:17
harlowjamore fun :-P19:17
zaneblast week on that thread was exhausting enough :/19:17
harlowjadef19:17
*** che-arne has quit IRC19:20
*** kgriffs_afk is now known as kgriffs19:21
harlowjazaneb 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
harlowjaand how hard in python it is going to be to get it right19:22
harlowjaso many places to cause DOS19:23
*** e0ne has quit IRC19:25
*** duncanjw has quit IRC19:26
*** TonyBurn has quit IRC19:30
*** duncanjw has joined #heat19:30
*** mspreitz has left #heat19:38
*** bgorski has quit IRC19:40
*** rbuilta has quit IRC19:45
*** mestery has joined #heat19:47
*** zns has joined #heat19:49
*** mspreitz has joined #heat19:53
*** connie has joined #heat20:00
*** lindsayk1 has joined #heat20:02
*** lindsayk1 has quit IRC20:03
*** lindsayk1 has joined #heat20:03
*** lindsayk has quit IRC20:04
*** mdelder_ has joined #heat20:08
openstackgerritSteve Baker proposed a change to openstack/heat: Document software config classes  https://review.openstack.org/8140720:09
openstackgerritSteve Baker proposed a change to openstack/heat: Store stack domain credentials for deployments  https://review.openstack.org/8086820:09
openstackgerritZane Bitter proposed a change to openstack/heat: Fail if non-existent security group referenced  https://review.openstack.org/8155820:10
*** mdelder has quit IRC20:11
*** jaustinpage has quit IRC20:12
andersonvomanybody who's very well versed in the ways the templates get parsed during the life cycle of a stack?20:15
*** mwheckmann has quit IRC20:17
*** Tross1 has quit IRC20:22
openstackgerritSteven Dake proposed a change to openstack/heat: Error and NotFound inherit HeatException class  https://review.openstack.org/8259320:23
openstackgerritSteven Dake proposed a change to openstack/heat: Properly encode heat.common.exception in rpc  https://review.openstack.org/8238620:23
sdake_zaneb can you have a look at the first change and see if its correct20: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 change20:23
sdake_so I'm not sure if I broke something or not :(20:24
openstackgerritSteven Dake proposed a change to openstack/heat: Properly encode heat.common.exception in rpc  https://review.openstack.org/8238620:27
*** harlowja_ has joined #heat20:27
*** DaveJ__ has quit IRC20:27
*** jaustinpage has joined #heat20:27
*** insanidade has joined #heat20:28
insanidadehi 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 close20:29
sdake_for example, heat doesn't provide full coverage of amazon's resources, such as route53, etc20:29
insanidadesdake_: I see. but the basics are compatible, right? I mean: the basics for a fully functional cloud.20:31
*** lindsayk1 has quit IRC20:31
insanidadesdake_: and what about the progress of HOT ?20:31
*** networkn81 has quit IRC20:31
*** harlowja has quit IRC20:31
sdake_we are supporting hot going forward from icehouse20:34
sdake_the openstack resources are in really good shape20:34
sdake_i'd recommend just writing native HOT using openstack native resources20:34
insanidadesdake_: 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_yup20:35
sdake_we have 2000+ test cases20:35
sdake_the code base has high degree of coverage20:35
insanidadeare 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 on20:37
sdake_but the openstack native resources will generally be in an on state20:38
sdake_so it really depends on your vendor20:38
*** mdelder_ has quit IRC20:38
insanidadegot it. so CFN support will be available even after HOT reaching a very high maturity level.20:38
sdake_can't guarantee it forever20:39
sdake_but we don't have plans to remove cfn or aws resources in the next 6-12 months20:39
sdake_I don't see any strong motivation to remove said resources20:39
sdake_or said parser20:39
sdake_but some openstack vendors dont want aws mentioned in their marketspeak, so they are free to turn them off iif they want20:39
*** lindsayk has joined #heat20:40
insanidadeI 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 cfn20:41
*** lipinski has joined #heat20:41
sdake_I like to think of HOT as what AWS would have done if they got a mulligan20: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 with20:43
* randallburt puts on his Rackspace hat: I wish it were easier to remove "default" resources from Heat20:43
shardyrandallburt: +1, I've had conversations with several existing users who find CFN compatibility important20:44
sdake_randallburt I think it makes sense to allow a config option to allow people to turn on/off resources by top level namespace20:44
randallburtsdake_:  sounds reasonable.20:44
*** mspreitz has quit IRC20:44
shardyrandallburt: But I'd like over time for us to move to having all the AWS resources reimplemented as provider templates over the native resources20:44
sdake_shardy +120:44
randallburtshardy:  totally agreed. FWIW I think its a pretty compelling use case for cloud users.20:44
shardythen we can reduce the plugin-level duplication and make it easier to "turn off" the AWS stuff20:44
randallburtshardy:  indeed. quite a bit of work though and there's that pesky "Metadata" to worry about, but I think its solve-able.20:45
shardyrandallburt: agreed, it's a mid-term goal to work towards over several cycles IMO20:46
randallburtshardy:  sounds good to me20:46
*** e0ne has joined #heat20:47
*** andersonvom_ has joined #heat20:50
*** andersonvom has quit IRC20:50
*** Tross has joined #heat20:51
lipinskiAnyone know if nested/layered proviter templates are supposed to work?20:52
lipinskiprovider20:52
shardylipinski: yes, they do work20:52
*** jpeeler has joined #heat20:53
*** jpeeler has quit IRC20:53
*** jpeeler has joined #heat20:53
insanidadesdake_: thanks for clarifying those points.20:54
*** jpeeler has quit IRC20:54
*** jpeeler has joined #heat20:54
*** jpeeler has quit IRC20:54
*** jpeeler has joined #heat20:54
lipinskishardy: anything special to get them to work?  I am having problems - Heat claims it cannot find the "second-layer" resource.20:56
lipinskiTemplate -> resourceA -> resourceB.  Both resourceA and resourceB defined in registry.  Heat complains it does not know what resourceB is.20:56
lipinskiYet, if I put resourceB directly in Template, it works.20:57
*** alexheneveld has joined #heat20:58
openstackgerritSteve Baker proposed a change to openstack/python-heatclient: Process provider templates for included files  https://review.openstack.org/8260321:06
*** andersonvom_ has quit IRC21:07
*** andersonvom has joined #heat21:07
*** Gamekiller77 has joined #heat21:09
Gamekiller77hey guys21:09
Gamekiller77any one around21:09
lipinskishardy: 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
Gamekiller77is it possible to use a snapshot with a Heat HOT template ?21:10
Gamekiller77i about to read all the doc pages but wanted to ask before i go googling21:10
lipinskiCan you pass JSON arrays as a list?  That seemed to fail on me.21:10
*** Gamekiller77 has quit IRC21:12
*** Gamekiller77 has joined #heat21:13
stevebakerGamekiller77: a cinder snapshot?21:15
Gamekiller77yes21:16
Gamekiller77want to do a storage bench marking and load testing21:16
Gamekiller77would be nice to presetup apps then have heat just blast out like 50 boxes21:16
Gamekiller77pre set it up21:17
*** jstrachan has quit IRC21:17
stevebakerGamekiller77: how about OS::Nova::Server block_device_mapping snapshot_id? http://docs.openstack.org/developer/heat/template_guide/openstack.html#OS::Nova::Server21:19
*** connie has quit IRC21:19
Gamekiller77ok i take a look21:19
Gamekiller77thanks21:19
Gamekiller77i using Ceph RBD so snapshot work very well to spin up new instances21:19
*** tomek_adamczewsk has quit IRC21:21
stevebakerSpamapS: can you walk me through the new-server config issue?21:22
*** e0ne has quit IRC21:23
*** tango has quit IRC21:24
*** sgordon_ has quit IRC21:25
*** aweiteka has quit IRC21:26
SpamapSstevebaker: sure21:28
SpamapSstevebaker: during an update, signals can't be accepted for new wait handles.21:28
SpamapSstevebaker: that is because in order to load a resource, you need the template snippet for it.21:28
*** asalkeld has joined #heat21:28
*** alexheneveld has quit IRC21:29
SpamapSstevebaker: that snippet only exists in the engine doing the update's RAM until the stack is complete again.21:29
*** cmyster_ has joined #heat21:29
stevebakerSpamapS: so this is an issue which affects new WaitHandle and SoftwareDeployment resources on update?21:30
*** e0ne has joined #heat21:30
*** andrew_plunk has joined #heat21:31
*** asalkeld has quit IRC21:32
*** vijendar has quit IRC21:32
SpamapSstevebaker: right21:32
*** stannie1 has joined #heat21:32
SpamapSstevebaker: It really goes back to the same thing that prevents retry21:32
*** asalkeld has joined #heat21:32
*** rpothier has quit IRC21:32
SpamapSstevebaker: update is fundamentally broken until it keeps track of state in the db21:33
*** cmyster has quit IRC21:33
stevebakerok21:33
*** Gamekiller77 has left #heat21:33
SpamapSstevebaker: so, the only answer is to just have one handle, and use the count to account for new resources.21:33
SpamapSNot sure but I _think_ you can have multiple wait conditions on a single handle21:34
stevebakerug, which means no deployment resources21:34
SpamapSstevebaker: right, they're not useful for updates. :(21:34
SpamapSwell21:34
SpamapSunless you never add one :-P21:34
SpamapSstevebaker: they're still super super super super awesome for the other parts though :)21:34
SpamapSstevebaker: and we _could_ special case new resources...21:35
stevebakerSpamapS: 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 update21:35
SpamapSstevebaker: so they'd have a different stack name to hand the API?21:36
SpamapSstevebaker: that would work, as long as you destroy the whole thing before update.21:36
stevebakerhmmm yes?21:36
SpamapSbut you wouldn't normally, you'd do an update on it21:36
SpamapShm still might work21:36
SpamapSstevebaker: that might be longer-term-viable than special casing anyway.21:37
*** asalkeld has quit IRC21:37
insanidadeexit21:38
*** insanidade has quit IRC21:38
stevebakerSpamapS: oh well, I look forward to update working21:40
SpamapSstevebaker: 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
stevebakernice21:41
openstackgerritAndrew Plunk proposed a change to openstack/heat: Chef solo resource  https://review.openstack.org/5520821:42
andrew_plunkhey stevebaker, I finally got it posted ^^21:43
stevebakerandrew_plunk: \o/21:43
*** jaustinpage has quit IRC21: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 something21:45
*** nati_ueno has quit IRC21:47
stevebakerandrew_plunk: could you just do the OS::Heat::ChefSolo mapping in your /etc/heat/environment.d?21:47
shardySpamapS: lsmola_ and I were discussing the multiple waitconditions thing earlier, you can but in most cases it won't make sense21:47
shardybecause the data is stored with the handle, so maybe if you had two different paths with different counts or something21:48
*** nati_ueno has joined #heat21:48
shardyotherwise all the conditions will complete at the same time, so will be redundant21:48
andrew_plunkyeah 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 now21:49
SpamapSstevebaker: https://review.openstack.org/82244 <-- deployments via cfn API landed in os-collect-config :)21:49
SpamapSshardy: well I was thinking that you could use it to block along the way21:50
*** asalkeld has joined #heat21:50
SpamapSshardy: it wouldn't work for divergent branches, but it would for linear21:50
stevebakerSpamapS: sweetness21:50
shardySpamapS: ah, so add a new WaitCondition on update with a larger count?21:50
shardybut leave the old one alone?21:51
SpamapSshardy: no, just update the count for that21:51
SpamapSshardy: but you can do this:21:51
zaneblipinski: the environment file doesn't propagate to provider stacks21:51
SpamapS[handle]->[server0]->[waitcondition0,count==1]->server1->[waitcondition1,count==2]21:52
SpamapSshardy: that will block until count >= 1, and then >= 221:52
SpamapSif it isn't >= .. if it is == .. well.. that may be a bug anyway ;)21:52
shardySpamapS: aha, yeah that would work, I tested something similar earlier21:52
SpamapSbut anyway21:52
SpamapSI'm comfortable that users can work around this.. myself included21:53
SpamapSbut I'm sad that we can't use the built in wait pieces of deployments21:53
*** alexpilotti has joined #heat21:54
*** Tross has quit IRC21:54
shardySpamapS: I think we'll just have to work really hard to sort out the various update issues in Juno, unfortunately21:54
*** mestery has quit IRC21:55
*** dims has quit IRC21:56
*** lindsayk has quit IRC21:56
*** Linz has joined #heat21:57
*** _ruhe_ has quit IRC21:59
SpamapSshardy: #1 priority for me.22:01
SpamapSit is #2 for me, behind graceful notifying of servers before rebuild/delete22:02
*** lindsayk has joined #heat22:04
*** mestery has joined #heat22:04
*** mestery has quit IRC22:06
*** che-arne has joined #heat22:07
*** andersonvom has quit IRC22:07
*** dims_ has joined #heat22:14
*** Linz has quit IRC22:14
*** BillArnold_ has quit IRC22:22
*** alexheneveld has joined #heat22:22
*** jcru has quit IRC22:23
*** lipinski has quit IRC22:23
*** faramir1 has joined #heat22:24
zanebstevebaker: do you have a link to the Neutron dependency issue we were discussing on Friday?22:25
* zaneb has lost it22:25
zaneband also the link22:25
*** alexheneveld has quit IRC22:26
*** andrew_plunk has quit IRC22:26
*** Tross has joined #heat22:29
openstackgerritZiad Sawalha proposed a change to openstack/heat: Update common docstrings to match guidelines  https://review.openstack.org/7351922:31
*** ifarkas has quit IRC22:31
*** alexheneveld has joined #heat22:31
openstackgerritZiad Sawalha proposed a change to openstack/heat: Update api docstrings to match guidelines  https://review.openstack.org/7351522:32
*** Linz has joined #heat22:33
openstackgerritZiad Sawalha proposed a change to openstack/heat: Update contrib docstrings to match guidelines  https://review.openstack.org/7307022:35
*** saurabhs has joined #heat22:35
*** alexheneveld has quit IRC22:36
*** e0ne has quit IRC22:41
*** yogesh has quit IRC22:41
*** jmckind has quit IRC22:42
*** Linz has quit IRC22:43
*** Linz has joined #heat22:44
*** zns has quit IRC22:46
*** david-lyle has quit IRC22:52
*** duncanjw has quit IRC22:54
*** kgriffs is now known as kgriffs_afk22:55
*** alexheneveld has joined #heat22:56
*** tomek_adamczewsk has joined #heat22:56
*** sgordon has joined #heat22:59
*** sgordon has quit IRC22:59
*** sgordon has joined #heat22:59
*** gokrokve has joined #heat23:02
*** rcleere has quit IRC23:08
stevebakerCould we get some reviews on the rc1 bugs? https://launchpad.net/heat/+milestone/icehouse-rc123:17
stevebakerzaneb: https://bugs.launchpad.net/heat/+bug/1279645 (and https://bugs.launchpad.net/heat/+bug/1243992)23:19
uvirtbotLaunchpad bug 1279645 in heat "stack delete failed when using OS::Neutron::Router's external_gateway_info property" [Medium,In progress]23:19
openstackgerritSteven Dake proposed a change to openstack/heat: Properly encode heat.common.exception in rpc  https://review.openstack.org/8238623:19
openstackgerritSteven Dake proposed a change to openstack/heat: Error and NotFound inherit HeatException class  https://review.openstack.org/8259323:19
zanebstevebaker: ta23:21
*** faramir1 has quit IRC23:22
*** duncanjw has joined #heat23:22
*** tomek_adamczewsk has quit IRC23:22
*** saurabhs has quit IRC23:31
*** randallburt has quit IRC23:33
stevebakerSpamapS, 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 tests23:35
*** stannie1 has quit IRC23:42
*** sgordon has quit IRC23:44
*** rbuilta has joined #heat23:45
*** Tross has quit IRC23:46
lifelessstevebaker: we build imags during CI23:47
*** gokrokve has quit IRC23:48
*** pvaneck has quit IRC23:48
stevebakerlifeless: my previous attempt to invoke dib during devstack stalled on waiting for devstack to switch to pip-1.523:49
*** pvaneck has joined #heat23:49
lifelesswhy do you need pip 1.5?23:49
*** aweiteka has joined #heat23:51
*** alexheneveld has quit IRC23:51
*** rbuilta has quit IRC23:54
openstackgerritA change was merged to openstack/heat: Fix stack-show failed with a name in uuid format  https://review.openstack.org/8247123:54
*** IlyaE has quit IRC23:57
*** pvaneck has quit IRC23:59

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