Restriction on the name of physical-resource-name size

Bug #1239972 reported by yogesh-mehra
16
This bug affects 2 people
Affects Status Importance Assigned to Milestone
OpenStack Heat
Triaged
Medium
Limor Stotland

Bug Description

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.

Tags: tripleo
Revision history for this message
Steven Hardy (shardy) wrote :

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

Changed in heat:
status: New → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in heat:
status: Incomplete → Expired
Revision history for this message
Maharajan Nachiappan (mnachiappan) wrote :

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.

Changed in heat:
status: Expired → Opinion
Changed in heat:
assignee: nobody → Maharajan Nachiappan (mnachiappan)
status: Opinion → In Progress
Angus Salkeld (asalkeld)
Changed in heat:
importance: Undecided → Low
Revision history for this message
Angus Salkeld (asalkeld) wrote :

resetting as no activity in a year.

Changed in heat:
status: In Progress → Triaged
assignee: Maharajan Nachiappan (mnachiappan) → nobody
Changed in heat:
assignee: nobody → Limor Stotland (limor-bortman)
Changed in heat:
status: Triaged → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to heat (master)

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

Revision history for this message
Steve Baker (steve-stevebaker) wrote :

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

Changed in heat:
importance: Low → High
Revision history for this message
Steve Baker (steve-stevebaker) wrote :

'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.

Revision history for this message
Steven Hardy (shardy) wrote :

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/

tags: added: tripleo
Revision history for this message
Zane Bitter (zaneb) wrote :

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.

Revision history for this message
Steve Baker (steve-stevebaker) wrote :

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)

Revision history for this message
Steven Hardy (shardy) wrote :

> 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?

Revision history for this message
Steve Baker (steve-stevebaker) wrote :

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

Changed in heat:
status: In Progress → Triaged
importance: High → Medium
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on heat (master)

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

Rico Lin (rico-lin)
Changed in heat:
milestone: none → no-priority-tag-bugs
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.