Open Stack

FYI


Begin forwarded message:

> From: Matt Riedemann <mriedem at linux.vnet.ibm.com>
> Date: May 6, 2016 at 9:24:23 PM EDT
> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev at lists.openstack.org>
> Subject: [openstack-dev] [nova] Austin summit feature classification session recap
> Reply-To: "OpenStack Development Mailing List \(not for usage questions\)" <openstack-dev at lists.openstack.org>
> 
> On Thursday morning John Garbutt led a session on feature classification in Nova. The full etherpad is here [1].
> 
> We've had a concept of this in the Nova devref for awhile [2].
> 
> The goals of the session were to agree on understanding what this was trying to fix and figure out the plan for working on it.
> 
> The point of feature classification is to identify what features in Nova are incomplete. This can mean they aren't fully tested, documented, etc. The idea is to communicate to users and operators what works for their technology choices, e.g. which hypervisor they use, shared vs non-shared storage, etc.
> 
> We also want it as a way to identify the gaps in testing and documentation so we can work on closing those gaps. There are then levels of completeness applied to a feature or scenario:
> 
> * Incomplete, e.g. cells v2
> * Experimental, e.g. cells v1
> * Complete, e.g. attach a volume to a server instance
> * Complete and required, e.g. create and destroy a server instance
> * Deprecated, e.g. nova-network
> 
> We can also use feature classification as a means to identify things that need to be deprecated, e.g. agent builds.
> 
> We also talked about how best to present this information so it's understandable to mere mortals.
> 
> We have the (hypervisor) feature support matrix already [3]. That's useful when you're drilling down into the lower level features that each virt driver (and even architecture for a virt driver like libvirt, for example) supports, but it's hard to parse from a high level.
> 
> So we agreed that for feature classification we'd start out with some high-level use cases. For example, network function virtualization, high-performance computing, pets (legacy application workloads) vs cattle (dev/test) clouds, etc. This is sort of like the architecture design guide [4]. Then from those use cases we start filling out the features you'd want for each one and then get into their level of completeness.
> 
> For Newton, John wants to accomplish the following:
> 
> * Get the infrastructure in place for creating the document within Nova, sort of like what we have for the feature support matrix, i.e. docs built from an ini/json/yaml file.
> 
> * Identify the use case categories, e.g. NFV, HPC, etc.
> 
> * Break those down into feature categories, and classifications, based on the existing hypervisor support matrix and DefCore.
> 
> * Then start filling out the table.
> 
> John has an example prototype POC here [5]. Note that's built from the docs job and will probably be gone soon, so I have an image of the table here [6].
> 
> Future work will include:
> 
> * Populating links to existing test results which can be community infra gate/check jobs/tests or third party CI results.
> 
> * Adding Tempest test uuids per feature and then cross referencing the test uuids to recent test results to automatically calculate if a feature is working or not.
> 
> * Linking to docs for each category.
> 
> * Add warning log messages for any big gaps in testing and potentially propose deprecation for some features unless testing is added.
> 
> [1] https://etherpad.openstack.org/p/newton-nova-feature-classification
> [2] http://docs.openstack.org/developer/nova/feature_classification.html
> [3] http://docs.openstack.org/developer/nova/support-matrix.html
> [4] http://docs.openstack.org/arch-design/
> [5] http://docs-draft.openstack.org/19/264719/7/check/gate-nova-docs/890de6a//doc/build/html/feature_classification.html#prototype-feature-support-matrix
> [6] http://imgur.com/4rxX9V7
> 
> -- 
> 
> Thanks,
> 
> Matt Riedemann
> 
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev