[openstack-dev] [tripleo] Mistral Workflow for deriving THT parameters

John Fulton johfulto at redhat.com
Wed Jan 11 14:33:25 UTC 2017


On 01/11/2017 12:56 AM, Saravanan KR wrote:
> Thanks Emilien and Giulio for your valuable feedback. I will start
> working towards finalizing the workbook and the actions required.

Saravanan,

If you can add me to the review for your workbook, I'd appreciate it. 
I'm trying to solve a similar problem, of computing THT params for HCI 
deployments in order to isolate resources between CephOSDs and 
NovaComputes, and I was also looking to use a Mistral workflow. I'll add 
you to the review of any related work, if you don't mind. Your proposal 
to get NUMA info into Ironic [1] helps me there too. Hope to see you at 
the PTG.

Thanks,
   John

[1] https://review.openstack.org/396147

>> would you be able to join the PTG to help us with the session on the
>> overcloud settings optimization?
> I will come back on this, as I have not planned for it yet. If it
> works out, I will update the etherpad.
>
> Regards,
> Saravanan KR
>
>
> On Wed, Jan 11, 2017 at 5:10 AM, Giulio Fidente <gfidente at redhat.com> wrote:
>> On 01/04/2017 09:13 AM, Saravanan KR wrote:
>>>
>>> Hello,
>>>
>>> The aim of this mail is to ease the DPDK deployment with TripleO. I
>>> would like to see if the approach of deriving THT parameter based on
>>> introspection data, with a high level input would be feasible.
>>>
>>> Let me brief on the complexity of certain parameters, which are
>>> related to DPDK. Following parameters should be configured for a good
>>> performing DPDK cluster:
>>> * NeutronDpdkCoreList (puppet-vswitch)
>>> * ComputeHostCpusList (PreNetworkConfig [4], puppet-vswitch) (under
>>> review)
>>> * NovaVcpuPinset (puppet-nova)
>>>
>>> * NeutronDpdkSocketMemory (puppet-vswitch)
>>> * NeutronDpdkMemoryChannels (puppet-vswitch)
>>> * ComputeKernelArgs (PreNetworkConfig [4]) (under review)
>>> * Interface to bind DPDK driver (network config templates)
>>>
>>> The complexity of deciding some of these parameters is explained in
>>> the blog [1], where the CPUs has to be chosen in accordance with the
>>> NUMA node associated with the interface. We are working a spec [2], to
>>> collect the required details from the baremetal via the introspection.
>>> The proposal is to create mistral workbook and actions
>>> (tripleo-common), which will take minimal inputs and decide the actual
>>> value of parameters based on the introspection data. I have created
>>> simple workbook [3] with what I have in mind (not final, only
>>> wireframe). The expected output of this workflow is to return the list
>>> of inputs for "parameter_defaults",  which will be used for the
>>> deployment. I would like to hear from the experts, if there is any
>>> drawbacks with this approach or any other better approach.
>>
>>
>> hi, I am not an expert, I think John (on CC) knows more but this looks like
>> a good initial step to me.
>>
>> once we have the workbook in good shape, we could probably integrate it in
>> the tripleo client/common to (optionally) trigger it before every deployment
>>
>> would you be able to join the PTG to help us with the session on the
>> overcloud settings optimization?
>>
>> https://etherpad.openstack.org/p/tripleo-ptg-pike
>> --
>> Giulio Fidente
>> GPG KEY: 08D733BA



More information about the OpenStack-dev mailing list