Description of problem: During OpenStack deployment it's possible to assign fixed IP addresses to node class (compute, controller, storage etc.), according to http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/node_placement.html, but as far as I understand it's not possible to specify exact relation between specific node from each class to IP address. As such, when deployng the cloud, it's not possible to ensure that specific node from a class will get specific IP. For instance, when creating cloud with three controller nodes, it;s possible to say that IPs used for the contollers are 172.16.1.100, 172.16.1.101 and 172.16.1.102, but it's not possible to say that physical machine with specific UUID as reported in ironic node-list gets IP ...100, another one gets ...101 and third gets ...102. I think it would be good if it would be possible to specify relation between ironic UUID and IP this node gets during deployment. Use case: I want to have three controllers in three different places, and want to know the when connecting to IP ...100 (identified as overcloud-controller-0 in nova list) I'll get always to machine in place1 after each deployment. Version-Release number of selected component (if applicable): NA How reproducible: NA Steps to Reproduce: 1. For deployment of overcloud create list of predictable IPs for a class of nodes (for instance compute), as described in http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/node_placement.html#predictable-ips 2. Deploy the overcloud Actual results: Not possible to say which physical node will get assigned which IP address of the fixed IP pool. Can vary between deployments on the same environment. Expected results: Specific node (as identified by UUID from ironic node-list) will get pre-defined IP from the pool after deployment. Additional info: https://bugs.launchpad.net/openstack-requirements/+bug/1639172
I don't think your premise is correct. The IP addresses are assigned in order, and you can control which physical servers are used for which controller nodes: http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/node_placement.html#assign-per-node-capabilities In any event this is not a Heat bug, so I'm reassigning to Director. Incidentally, openstack-requirements is the upstream project for managing which versions of libraries OpenStack projects can use, and is a bizarre place for TripleO bugs.
Hello Zane, Thank for updates, and sorry for confusion about the classification of the bug. It completely can be that I just misunderstood the situation, and made incorrect config on reproducer, will try that once more and report. Thanks, Petr
Hello Zane, We have tested the config, and you are partially right, the predictable address configuration joined with per-node capabilities and Scheduler hits works. Though, it works only on networks other that ctlplane. Is there some way to set up this for ctlplane which I was not able to find, or is this missing for this net? We have used following setup: Prepare YAML template: parameter_defaults: ControllerSchedulerHints: 'capabilities:node': 'controller-%index%' ComputeSchedulerHints: 'capabilities:node': 'compute-%index%' HostnameMap: controller-0: controller-0 controller-1: controller-1 controller-2: controller-2 compute-0: compute-0 Edit environments/ips-from-pool-all.yaml parameter_defaults: ControllerIPs: # Each controller will get an IP from the lists below, first controller, first IP external: - 172.16.23.113 - 172.16.23.111 - 172.16.23.112 internal_api: - 172.16.20.14 - 172.16.20.13 - 172.16.20.15 storage: - 172.16.21.14 - 172.16.21.11 - 172.16.21.13 storage_mgmt: - 172.16.3.7 - 172.16.3.5 - 172.16.3.6 tenant: - 172.16.22.13 - 172.16.22.11 - 172.16.22.12 NovaComputeIPs: # Each compute will get an IP from the lists below, first compute, first IP internal_api: - 172.16.20.12 storage: - 172.16.21.12 tenant: - 172.16.22.10 Thanks, Petr
I have opened a RFE [1] for predictable provisioning IPs sometime back. Currently AFAIK, it's not possible to have predictable IPs. Looking forward to hear for the confirmation from Zane. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1344174
Hi This feature is still not implemented in OSP10 yet, right?
(In reply to Ray Wang from comment #5) > Hi > > This feature is still not implemented in OSP10 yet, right? Not as far as I can see. This would be useful to have as some storage subsystems (e.g. GPFS/Spectrum Scale) require DNS and fixed IP addresses for communication.
*** This bug has been marked as a duplicate of bug 1337770 ***