Open Stack

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 ?

> 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.

> 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).

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.

-- 
Thierry Carrez (ttx)