Re: [openstack-dev] [TripleO][Heat] reverting the HOT migration? // dealing with lockstep changes

2014-08-13 Thread James Slagle
On Tue, Aug 12, 2014 at 7:10 PM, Robert Collins robe...@robertcollins.net wrote: On 13 August 2014 11:05, Robert Collins robe...@robertcollins.net wrote: I've reproduced the problem with zane's fix for the validation error - and it does indeed still break: | stack_status_reason |

Re: [openstack-dev] [TripleO][Heat] reverting the HOT migration? // dealing with lockstep changes

2014-08-12 Thread Robert Collins
On 12 August 2014 10:46, Robert Collins robe...@robertcollins.net wrote: On 12 August 2014 07:24, Dan Prince dpri...@redhat.com wrote: On Tue, 2014-08-12 at 06:58 +1200, Robert Collins wrote: Hi, so shortly after the HOT migration landed, we hit https://bugs.launchpad.net/tripleo/+bug/1354305

Re: [openstack-dev] [TripleO][Heat] reverting the HOT migration? // dealing with lockstep changes

2014-08-12 Thread Robert Collins
On 13 August 2014 11:05, Robert Collins robe...@robertcollins.net wrote: I've reproduced the problem with zane's fix for the validation error - and it does indeed still break: | stack_status_reason | StackValidationFailed: Property error : NovaCompute6: | | key_name

Re: [openstack-dev] [TripleO][Heat] reverting the HOT migration? // dealing with lockstep changes

2014-08-11 Thread Zane Bitter
On 11/08/14 15:24, Dan Prince wrote: Hmmm. We blocked a good bit of changes to get these HOT templates in so I hate to see us revert them. Also, It isn't clear to me how much work it would be to fully support the non-HOT to HOT templates upgrade path. How much work is this? And is that something

Re: [openstack-dev] [TripleO][Heat] reverting the HOT migration? // dealing with lockstep changes

2014-08-11 Thread Robert Collins
On 12 August 2014 10:27, Zane Bitter zbit...@redhat.com wrote: On 11/08/14 15:24, Dan Prince wrote: Hmmm. We blocked a good bit of changes to get these HOT templates in so I hate to see us revert them. Also, It isn't clear to me how much work it would be to fully support the non-HOT to HOT