Open Stack

Filed a bug: https://bugs.launchpad.net/horizon/+bug/1614000

2016-08-17 11:19 GMT+03:00 Tatiana Ovtchinnikova <
t.v.ovtchinnikova at gmail.com>:

> It is definitely a bug in Horizon. The additional columns
> "Implementation", "Component" and "Resource" are representative for a
> limited resource type group only. Since Heat allows to specify a URL as a
> resource type, we should not use these columns at all. "Type" column and
> filter will do just the same trick.
>
> Tatiana.
>
>
> 2016-08-17 1:22 GMT+03:00 Rob Cresswell <robert.cresswell at outlook.com>:
>
>> This sounds like a bug on the Horizon side. There is/was a patch
>> regarding a similar issue with LBaaS v2 resources too. It's likely just an
>> incorrect assumption in the logic processing these names.
>>
>> Rob
>>
>> On 16 Aug 2016 11:03 p.m., "Zane Bitter" <zbitter at redhat.com> wrote:
>>
>>> On 16/08/16 17:43, Praveen Yalagandula wrote:
>>> > Hi all,
>>> > We have developed some heat resources for our custom API server. We
>>> > followed the instructions in the development guide
>>> > at http://docs.openstack.org/developer/heat/pluginguide.html and got
>>> > everything working. However, the Horizon "Resource Types" panel is
>>> > returning a 500 error with "TemplateSyntaxError: u'resource'" message.
>>> >
>>> > Upon further debugging, we found that the Horizon is expecting all Heat
>>> > resource type names to be of form
>>> > <implementation>::<component>::<resource>. However, we didn't see this
>>> > requirement in the heat development documents. Some of our resource
>>> > types have just two words (e.g., "Avi::Pool"). Heat itself didn't care
>>> > about these names at all.
>>>
>>> Given that Heat has a REST API specifically for validating templates,
>>> it's surprising that Horizon would implement its own, apparently
>>> incorrect, validation.
>>>
>>> > Question: Is there a general consensus is to enforce
>>> > the <implementation>::<component>::<resource> format for type names?
>>>
>>> No. We don't really care what you call them (although using OS:: or
>>> AWS:: as a prefix for your own custom types would be very unwise). In
>>> fact, Heat allows you to specify a URL of a template file as a resource
>>> type, and it sounds like that might run afoul of the same restriction.
>>>
>>> > If so, can we please update the heat plugin guide to reflect this?
>>> > If not, we can file it is as a bug in Horizon.
>>>
>>> +1 for bug in Horizon.
>>>
>>> - ZB
>>>
>>> ____________________________________________________________
>>> ______________
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.op
>>> enstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>>
>>
>> ____________________________________________________________
>> ______________
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160817/1450c169/attachment.html>