Ironic deployment guide documentation #1010
Conversation
assumptionsandg
force-pushed
the
ironic-docs
branch
from
5331306 to
4be7d65
Compare
assumptionsandg
force-pushed
the
ironic-docs
branch
from
4be7d65 to
5c734ae
Compare
There was a problem hiding this comment.
Good start @assumptionsandg. I know you're still working on this, but I've added some comments.
| Ironic will require the workload provisioning and cleaning networks to be | ||
| configured in ``networks.yml`` | ||
|
|
||
| The workload provisioning network will require an allocation pool for |
There was a problem hiding this comment.
It would helpful to clarify what these pools are used for. I.e. note that one pool is for statically assigned IPs that will be used by OpenStack Ironic services, and the other pools (Neutron ones) are for dynamically assigning IPs to hosts being provisioned / inspected. I like the idea of suggesting a /16 to start with, to leave room for growth.
| network: internal-net | ||
|
|
||
| To provision baremetal nodes in Nova you will also require setting a flavour | ||
| speciifc to that type of baremetal host. You will need to replace the custom |
| OpenStack Config | ||
| ================ | ||
|
|
||
| Overcloud Ironic will require a router to exist between the internal API |
There was a problem hiding this comment.
I haven't seen a site use a neutron router for this yet. It's an interesting idea. Is there a specific reason for using one? Normally, at least in the past, we have avoided a dedicated router: https://docs.google.com/document/d/1H3hGYzJzieX8w7phxS3xmD6i6OEZgiHmBjvZ7EJEbU4/edit#heading=h.gyl3n9h885m
It would be helpful to start with why a router is required. Specifically, because the TFTP/HTTP server hosting the deploy images is bound exclusively to internal API network, rather than all possible networks the node might PXE boot on. When baremetal nodes PXE boot, they are given the location of the TFTP/HTTP server to fetch the images from. Since the cleaning/provisioning/inspection network is generally not the same as the internal API network, routing is required.
| .. code-block:: yaml | ||
|
|
||
| networks: | ||
| - "{{ openstack_network_intenral }}" |
| project: "admin" | ||
| provider_network_type: "vlan" | ||
| provider_physical_network: "physnet1" | ||
| provider_segmentation_id: 458 |
There was a problem hiding this comment.
nit: reference VLAN variable
| Overcloud Ironic will require a router to exist between the internal API | ||
| network and the provision workload network, a way to achieve this is by | ||
| using `OpenStack Config <https://github.com/stackhpc/openstack-config>` | ||
| to define the internal API network in Neutron and set up a router with |
There was a problem hiding this comment.
Have you tested this configuration? I imagine you still need policy based routing here to prevent traffic bypassing the router? Eg. Node on cleaning network tries HTTP fetch of IPA image, request is routed to a controller, controller replies not via the router, but directly to the node via the cleaning interface. The node sees that the traffic came back from a different MAC, and ignores it.
| ================== | ||
|
|
||
| UEFI booting requires conntrack_helper to be configured on the Ironic neutron | ||
| router, this is due to TFTP traffic being dropped due to being UDP. You will |
There was a problem hiding this comment.
This is another complexity that would go away if we didn't use the Neutron router. Assuming conntrack is already enabled on the controller.
| @@ -0,0 +1,232 @@ | |||
| ====== | |||
There was a problem hiding this comment.
Thanks for sharing the information you have @assumptionsandg. I think we need to consider what the scope of this doc is. We have some general notes on ironic deployment in https://docs.google.com/document/d/1H3hGYzJzieX8w7phxS3xmD6i6OEZgiHmBjvZ7EJEbU4/edit that are possibly more detailed than this but not public. We might also consider whether a generic description of ironic config might be better placed in kayobe or kolla-ansible upstream docs.
Docs that might belong in SKC are generally either
- our opinionated way of doing things, that wouldn't belong upstream
- dependent on additional config in SKC
What was the original request for these docs about? Was it to cover the use of overcloud ironic to manage hypervisors? That could be considered under 1.
There was a problem hiding this comment.
I think the purpose was originally managing hypervisors but I wasn't sure whether to include all of the RAL documentation I had up to this point, I do still need to add the section about managing hypervisors after deployment.
Maybe it would make sense to split the deployment part out and propose that upstream? The openstack-config part might be too opinionated for upstream though.
There was a problem hiding this comment.
You'd need to reference this doc from configuration/index.rst in order for it to be included in the docs.
|
Incorporated into #1089 |
Ironic deployment documentation.