Open Stack

Thierry,
Comments inline.

-----Original Message-----
From: Thierry Carrez [mailto:thierry at openstack.org] 
Sent: Wednesday, October 11, 2017 5:26 AM
To: Kanevsky, Arkady <Arkady_Kanevsky at DELL.com>; lauren at openstack.org; foundation-board at lists.openstack.org; goldmembers at lists.openstack.org; openstack-tc at lists.openstack.org
Subject: Re: [Gold Members] [Foundation Board] OpenStack Deliverables Map -- Feedback Request

Arkady.Kanevsky at dell.com wrote:
> 1.       Ironic is both baremetal provisioning and deployment tool.
> Suggest we replace Bifrost with Bifrost/Ironic.

The deliverables in the "OPENSTACK-LIFECYCLEMANAGEMENT" bucket are the tools that can be used to deploy and/or handle the lifecycle of an OpenStack install.

The reason we put Bifrost in that bucket is that it can be used to deploy Ironic standalone. I don't see Ironic as an OpenStack deployment/lifecycle tool, even if it can be used by deployment/lifecycle tools to deploy OpenStack... Could you expand on what you mean ?

AK: Ironic can and is used by TripleO to manage server configuration specific to the functionality to be run on a node. That includes setup RAID, BIOS and FW. In the future we want to also be able to update FW/RAID thru Ironic. This makes Ironic a deployment tool and life-cycle management tool. 

> 2.       Deployment tools is too restrictive. Suggest renaming it 
> Life-cycle Management. It covers deployment, update, upgrade, etc.

That's a good idea, I agree it's a more complete description for that subcategory.

> 3.       Why is AODH part of Orchestration and not Monitoring Tools.

Aodh was originally put in Monitoring, but we received several pieces of feedback that it would be better placed as an orchestration tool. Not all tools in the Telemetry toolbox are about monitoring. Aodh is a user-facing tool that lets you trigger actions based on metrics.
Communicating to applications what is happening with their infrastructure is not really an operational concern, it should really be seen as an essential IaaS component. So the way I see it, Aodh is the openstack-side, user-facing component that lets you leverage metric information.

AK: Agree that AODH can be utilize by orchestration but it is not an orchestration in itself.
All Monitoring tools are used to trigger some action when certain criteria is met.
I view AODH is part of telemetry bucket along with Painko.

> 4.       Suggest adding Tempest to Optimization/policy tools bucket.
> Also suggest renaming it as validation/optimization/policy tools.
> Tempest is used by many users as validation tool and we expect 
> customers and distros submit tempest results for interop/refstack.

That's a good point. Wondering if we should not have a "Validation / perf testing" subcategory (that would include Rally and Tempest), distinct from the "optimization/policy" subcategory, as those are really different concerns (optimizing a running cloud vs. externally testing a given deployment).

AK: +1

In conclusion, please keep in mind that there is no attempt at categorizing OpenStack components that that will be universally accepted as the correct one. As any mapping exercise, this one is a balancing act between what we show, what we don't show, readability, and correctness.

AK: fully agree.

--
Thierry Carrez (ttx)