Bug 1432605 - Documentation: Need to document the services needed for ironic composable role in OSP11
Summary: Documentation: Need to document the services needed for ironic composable rol...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: documentation
Version: 11.0 (Ocata)
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ga
: 11.0 (Ocata)
Assignee: Dan Macpherson
QA Contact: RHOS Documentation Team
URL:
Whiteboard:
Depends On: 1432560
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-03-15 18:43 UTC by Alexander Chuzhoy
Modified: 2017-05-18 08:05 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-05-18 08:05:12 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Alexander Chuzhoy 2017-03-15 18:43:53 UTC
In OSP11 (and 10) we need to ensure that these 2 services are together when ironic composable role is used:
    - OS::TripleO::Services::IronicConductor
    - OS::TripleO::Services::IronicApi


Also,
Need to document that ironic role needs access to the storage network.

Thanks.

Comment 2 Derek 2017-03-16 15:39:01 UTC
Is designing the functionality for access to the storage network covered in an OSP 11 RFE?  If so, what's the number?

Comment 3 Alexander Chuzhoy 2017-03-16 15:50:31 UTC
I'm not aware of such RFE.
Ramon, do you have an answer?

Comment 4 Ramon Acedo 2017-03-16 17:37:52 UTC
No, as support for a composable Ironic node starts with Ocata, previously in Newton that was transparent as ironic-conductor was on the controllers which already have storage network. When we QAed this we saw how ironic-conductor was accessing Glance via the storage network, which brings us here.

Comment 5 Ramon Acedo 2017-03-16 17:51:07 UTC
By the way, enabling a network in a custom role is no different from the standard way with the default roles:

https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html-single/advanced_overcloud_customization/#sect-Creating_Custom_Interface_Templates

Comment 6 Dan Macpherson 2017-03-16 18:17:23 UTC
The docs impact is pretty minimal. We might only just require a short note for the Standalone Ironic role:

https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/10/html/advanced_overcloud_customization/Roles#Standalone-Ironic

Comment 7 Ramon Acedo 2017-03-31 13:44:49 UTC
Details of the role can be found here: https://bugzilla.redhat.com/show_bug.cgi?id=1432560#c6

Comment 8 Ramon Acedo 2017-04-10 10:32:00 UTC
Dan, we have made all the necessary improvements to allow a composable role with only OS::TripleO::Services::IronicConductor Please, check the details here in this comment: https://bugzilla.redhat.com/show_bug.cgi?id=1432560#c6

So the service IronicApi is not mandatory for the Ironic role.

Besides the notes in the documentation, could we ensure we mention in the release notes that the Ironic service now supports being deployed as a composable role?

Thanks.

Comment 9 Dan Macpherson 2017-04-11 05:05:29 UTC
Ramon and Sasha, I might need some clarification here. Initially this bug said that the Conductor and the API services need to be together. However, Roman said in comment #8 that the API doesn't need to be on the same role.

Sasha, can you confirm this from a QE perspective?

Also, does this mean we can have separate Ironic and IronicApi roles?

Comment 10 Ramon Acedo 2017-04-11 11:21:47 UTC
Dan, you are right, initially, when this BZ was opened, that was the case (IronicApi and IronicConductor had to be together), then we worked on BZ#1432560 to fix this constraint, with the expectation that the fix might land after GA. The fix made it earlier though, and that's why now adding IronicApi is not mandatory for the Ironic role.

We have tested with IronicConductor in mind as the composable role of choice for Ironic . We have tested the composable role with:

1. IronicConductor + IronicApi (this was our initial working test)
2. IronicConductor (verified after the patch in BZ#1432560 landed downstream)

A user might desire to have ironic-conductor service on a dedicated node to alleviate the load it produces on the controllers (where it's deployed by default) or to simply isolate the service instead of having it running along with the public APIs for example. That's why the priority is to have IronicConductor working as a composable service.

Comment 11 Alexander Chuzhoy 2017-04-11 13:11:47 UTC
+1 to comment #10.

Comment 12 Dan Macpherson 2017-04-11 13:44:41 UTC
Hi Ramon,

Thanks for the answer. Just for additional clarification, can IronicApi exist on its own role as well? e.g. have an architecture with:

1 x IronicConductor
1 x IronicApi
1 x Controller
n x whatever other nodes

Comment 13 Ramon Acedo 2017-04-11 13:51:17 UTC
Technically yes, IronicApi can exist on its own, but we haven't done QA on this as testing IronicConductor as a composable role was more critical for the reasons explained in comment #10.

Comment 14 Dan Macpherson 2017-04-11 14:05:26 UTC
Okay, so for the moment, I'll add a note to say IronicApi can either be placed on the Ironic role or the Controller role depending on the user's decision. If those are the only two scenarios we've tested, we'll stick with those.


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