Open Stack

Thanks.  There are places where the document pre-dates discussions where 
we changed direction.

I think how capabilities will be maintained and formed over time is a 
key aspect of the discussion around the DefCore process.  Ideally, all 
stakeholders would have a voice (e.g: users, ecosystem clients and 
operators).  There are a lot of ways to maintain the mapping of 
capabilities to tests.  One thing to think about is how to we handle if 
"tests" expand beyond Tempest.

On 02/12/2015 10:01 AM, Russell Bryant wrote:
> During the DefCore meeting yesterday, feedback was requested on the
> following DefCore process document:
>
> https://docs.google.com/document/d/1rekLXVuyXUxV1zWWxvpVaaS_8MSxGUqUp0bvC1C2prU/edit#heading=h.gqn73w9yzkli
>
> I made some comments and suggested some edits, but wanted to bring some
> of that here for discussion.
>
> 1) Ongoing maintenance of capabilities
>
> One of the key points in the document is:
>
>     "Going forward, we want to rely on the technical leadership to
>      create, cluster and describe capabilities.  DefCore bootstrapped
>      this process for Havana.  Further, Capabilities are defined by
>      tests in Tempest..."
>
> Later in the document, "technical leadership" was clarified as:
>
>     "all tests are categorized into a capability by the PTL
>      through a Gerrit patch of the JSON file"
>
> I'm curious how much discussion there has been with the technical
> leadership about this part.  It seems important to work out for this to
> be sustainable long term.
>
> As I understand it, the test groupings into capabilities has been a
> manual process so far.  Is that right?
>
> Ideally, I think we should be working with the tempest team to have the
> required metadata be a part of tempest itself and kept up to date as
> tests are added/removed/changed over time.  I think *that* should be the
> primary request to the technical leadership.  Define a set of
> requirements for the metadata needed about available tests and then
> discuss possible solutions.
>
> Perhaps there is existing work in this area already?
>
> 2) Designated Sections
>
> I made several suggested edits to the document to clarify that the TC is
> not responsible for defining designated sections.  To recap, the
> official TC response to this was:
>
> http://governance.openstack.org/resolutions/20140211-tc_defcore_response.html
>
> The suggested edits just change it such that the defcore committee is
> responsible for defining designated sections, but will do so with input
> from any interested community members.  Further, the suggested edits
> clarify that the ongoing maintenance of the designated sections
> definitions will be done in the defcore git repository.
>

-- 
   

Rob
____________________________
Rob Hirschfeld, 512-773-7522
RackN CEO, Founder

I am in CENTRAL (-6) time
http://robhirschfeld.com
twitter: @zehicle, github: cloudedge & ravolt