Bug 1659783 - OSPD 14 beta doc node tagging control or controller ?
Summary: OSPD 14 beta doc node tagging control or controller ?
Keywords:
Status: NEW
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation
Version: 14.0 (Rocky)
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: ---
Assignee: RHOS Documentation Team
QA Contact: RHOS Documentation Team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-12-16 12:20 UTC by Tzach Shefi
Modified: 2019-01-11 15:35 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:
Target Upstream Version:


Attachments (Terms of Use)

Description Tzach Shefi 2018-12-16 12:20:31 UTC
Description of problem: On osp14 beta doc 
https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/14-beta/html/director_installation_and_usage/creating-a-basic-overcloud-with-cli-tools

6.3. Tagging nodes into profiles
When we tag nodes I noticed on the example for controller we have:

(undercloud) $ openstack baremetal node set --property capabilities='profile:control,boot_option:local' 1a4e30da-b6dc-499d-ba87-0bd8a3819bc0


I'm not sure but suspect we have an issue here-> 'profile:control
Needs to find a match on hostnames.yml
When I deploy via infrared files hostnames.yml is created for me with:
cat hostnames.yml 
---
parameter_defaults:

    CephStorageHostnameFormat: 'ceph-%index%'
    ObjectStorageHostnameFormat: 'swift-%index%'
    ControllerHostnameFormat: 'controller-%index%'
    ComputeHostnameFormat: 'compute-%index%'


In my case the correct controller profile tag should be 
-> 'profile:controller 


But then again this is the case only with Infrared automated deployment.
If we do a manual deploy I'm not sure what we add under hostname.yml, if we create it at all or use flages to set flavors when we run overcloud deploymnet later. 

Any way just pointing out the fact that someone needs to verify that we use the correct/matching name in both places. Same goes for compute I suspect. 

When I look under a deployed overcloud using ironic node show on a controller I see:

|                        | u'cpus': u'8', u'capabilities': u'profile:controller,boot_option:local'} |

In the past unsure up to which version this used to be "control" rather then controlled. 

Again I'm not sure which is correct, suspect "controller" just asking that we check and keep docs consistent.  

Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 1 Tzach Shefi 2018-12-16 12:29:01 UTC
Something else popped up might be related

On my deployment, notice flavor "control"
(undercloud) [stack@cougar08 ~]$ openstack flavor list
+--------------------------------------+---------------+------+------+-----------+-------+-----------+                                  
| ID                                   | Name          |  RAM | Disk | Ephemeral | VCPUs | Is Public |                                  
+--------------------------------------+---------------+------+------+-----------+-------+-----------+                                  
| 1913c841-33da-47ef-8874-f966ac54a403 | block-storage | 4096 |   40 |         0 |     1 | True      |                                  
| 87cac270-d8a1-4875-a859-e825e4ac280d | baremetal     | 4096 |   40 |         0 |     1 | True      |                                  
| aa830f2b-e814-4865-8df6-db5c0e1fa4e2 | control       | 4096 |   40 |         0 |     1 | True      |                                  
| d689c8a6-6460-43da-805d-1f9a822ed094 | compute       | 4096 |   40 |         0 |     1 | True      |  

On Infrared's deployment notice "controller" 
(undercloud) [stack@undercloud-0 ~]$ openstack flavor list
+--------------------------------------+------------+-------+------+-----------+-------+-----------+
| ID                                   | Name       |   RAM | Disk | Ephemeral | VCPUs | Is Public |
+--------------------------------------+------------+-------+------+-----------+-------+-----------+
| 02ba6628-3539-43e4-89a3-00e51a33e47f | compute    |  6144 |   17 |         0 |     1 | True      |
| c5de318f-c54c-4f2e-8aca-f2fd88e6124e | baremetal  |  4096 |   16 |         0 |     1 | True      |
| eac2ff9c-2a96-4dee-8a46-eeed7f658c28 | controller | 26384 |   27 |         0 |     7 | True      |
+--------------------------------------+------------+-------+------+-----------+-------+-----------+


I'm not sure where these flavor's come from either automatically self created by deployment of undercloud or if we have to create them but the tag/name/flavor needs to math. 
And this should be explained on the doc, or at least mentioned that we should use "openstack flavor list" to check which tag we should use.

Comment 2 Tzach Shefi 2018-12-16 12:50:28 UTC
Oh one more thing switch hostnames.yml with nodes_data.yaml above. 

My deployment:
cat nodes_data.yaml
---
parameter_defaults:
    ControllerCount: 1
    OvercloudControlFlavor: control
    ComputeCount: 1
    OvercloudComputeFlavor: compute



Infrared's 
(undercloud) [stack@undercloud-0 ~]$ cat virt/nodes_data.yaml 
parameter_defaults:
    ControllerCount: 3
    OvercloudControlFlavor: controller
    ComputeCount: 2
    OvercloudComputeFlavor: compute


Notice flavor names differ, name/tag needs to match whatever we have on this file nodes_data.yaml rather then hostnames.yml.
Then again it should probably also match undercloud's openstack flavor list output.


Note You need to log in before you can comment on or make changes to this bug.