Restriction on the name of physical-resource-name size

[yogesh-mehra]

File: /heat/engine/resources/instance.py

Physical resource name length max limit should be configurable instead of hardcoded as 63. This will give much required flexibility to the consumer frameworks.

[Steven Hardy (shardy)]

Can you provide more information on the use-case for this?

The reason for the limit is that hostname labels are limited to 63 characters or less, ref http://www.ietf.org/rfc/rfc1035.txt

So if you exceed this limit bad things happen, like DHCP doesn't work anymore, ref bug #1238272

[Launchpad Janitor (janitor)]

[Expired for heat because there has been no activity for 60 days.]

[Maharajan Nachiappan (mnachiappan)]

It affects us, since we need a name lesser than 53 ( physical_resource_name_limit = 53 ) what we have in instance.py and server.py. Its creating unnecessary in length, when you are trying to add in DNS. User need control in the length. I understand it should not go beyond 63 but at the same time we should allow the user to have name with limit(maximum) what they like.

[Angus Salkeld (asalkeld)]

resetting as no activity in a year.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/174309

[Steve Baker (steve-stevebaker)]

To fix this I would like to see the following:
- A heat.conf option nova_dhcp_domain which defaults to novalocal
- Changing all server resource name length calculations to take into account the length of nova_dhcp_domain so the resulting name is < 64 chars
- Downstream configuration tools (puppet modules etc) to make sure nova.conf dhcp_domain and heat.conf nova_dhcp_domain are set to the same value

[Steve Baker (steve-stevebaker)]

'openstacklocal' is also a common default for dhcp_domain, so an urgent backportable fix could be to reduce the hard-coded server length name to accommodate this.

[Steven Hardy (shardy)]

In addition, I think we need to figure out tweaks to the truncation algorithm which prefer removing the random suffixes, because we end up with some impressively obfuscated names after a few levels of nesting, e.g this is a tripleo hostname:

ov-sszdbj5rdne-0-bhseh65edxv6-Controller-zoqc6tlypbdp

I sent a patch[1] which makes that configurable for tripleo via the templates, but I think a more general solution would be to make the algorithm either omit the random suffixes entirely, or at least only retain the one for the current stack and strip those from further up the tree.

E.g you'd end up with something which looked like:

overcloud-0-Controller

or overcloud-0-Controller-zoqc6tlypbdp

[1] https://review.openstack.org/#/c/191726/

[Zane Bitter (zaneb)]

I agree, I think a deeply-nested hostname like that should be of the form overcloud-0-Controller-zoqc6tlypbdp

I'm not sure why ResourceGroup or TemplateResource (not sure which) is adding a random part after -0 at all? ov-sszdbj5rdne-0 should be completely unique, calling the child stack ov-sszdbj5rdne-0-bhseh65edxv6 is entirely unnecessary.

[Steve Baker (steve-stevebaker)]

It may be too late to just change the name pattern now since I don't think the name is stored, so this could affect old stacks after a cloud upgrade.

Likely the best we could do is add a resource-type property (name_format) to allow template authors to choose different formats (changing causes replacement by default)

[Steven Hardy (shardy)]

> It may be too late to just change the name pattern now since I don't think the name is stored, so this could affect old stacks after a cloud upgrade.

I don't really understand this - we store the stack name in the DB, so surely we just use that, and use the newly calculated physical_resource_name for any new resources?

Perhaps I'm missing something, can you clarify when this would be a problem wrt upgrades?

[Steve Baker (steve-stevebaker)]

If we could guarantee (or even enforce) that physical_resource_name() is only called during stack_create then we could change the naming algorithm.

Currently this is not the case, for example the OS::Nova::Server name attribute ends up calling physical_resource_name rather than looking up the nova server name

[OpenStack Infra (hudson-openstack)]

Change abandoned by Limor Stotland (<email address hidden>) on branch: master
Review: https://review.openstack.org/174309