Open Stack

Following: https://etherpad.openstack.org/p/DefCoreScale.10

# Summary:

* Great discussions about numerous topics - will show up on ML and as 
patches, so watch Gerrit!
* Scheduled single topic meeting to reviiew process on Tuesday 4/7 @ 9 
PT  > https://etherpad.openstack.org/p/DefCoreScale.10B
* Recommending 2015.next with addition of Juno to BoD for 4/2 approval
* Agreed to make some changes to the JSON Schema for 2015.next after 4/2.

# Agenda

* New Interop Web Page Live as of Today
* http://www.openstack.org/brand/interop/
* Review and Prepare 2015.next for April Board Meeting [DID MAKE IT!]
    * Identity tests, scoring and addition.
      https://review.openstack.org/#/c/169655/
* Plan for moving additional items into OpenStack/DefCore repo
* Capabilities and Designated Sections Clarification
* json file as single source of truth (see also 
https://review.openstack.org/#/c/169017/ )
* updates to json schema for 2015.next (expected 2015.05)
* fix release version for 2015.03
* https://review.openstack.org/#/c/169799/
* Outreach
DefCore & TC Interlock
Communtiy
* Discuss UUID vs Test Names as ID
* Initial discussion about API additions?
* http://lists.openstack.org/pipermail/openstack-dev/2015-March/059765.html
* "What I'm suggesting is that Defcore should not just specify which API 
features need to be supported, but also specify that nonstandard API 
features must not be added to the APIs its covering." --Jeremy Stanley
* What to do about overlapping capabilities (see below)


# Roll Call
Mark T. Voelker (VMware)
Vince Brunssen (IBM)
Carol Barrett (Intel)
Rob HIrschfeld (Co-Chair, RackN)
Will Auld (Intel)
Chris Hoge (OpenStack Foundation)
Egle Sigler (Co-Chair, Rackspace)
Van Lindberg (Rackspace)
Kevin Carter (Rackspace)
Jim Meyer (HP) (thanks!)
Mark Atwood (HP)


What to do about overlapping capabilities
=================================
    * We’ve generally shied away from “picking winners” where there is 
overlapping functionality between two OpenStack components by simply not 
including either one in our capabilities lists.
    * Example: today there are two major networking models in 
OpenStack—Neutron and nova-net.  Neither is included in DefCore 
capabilities in spite of the fact that you need networking to run a 
cloud and both have been present since pretty early days of OpenStack.  
There is some consensus that nova-net will likely eventually be 
deprecated and replaced by Neutron, though this has been postponed more 
than once.  However in the meantime:
       * We can’t add Neutron capabilities as this would disqualify the 
not-small number of clouds running nova-net (e.g. it is “widely deployed”).
       * We can’t add nova-net capabilities as this would disqualify the 
not-small number of clouds running Neutron (e.g. it is also “widely 
deployed”).
       * We can’t say “you must provide either nova-net capability or 
Neutron capability” because we have no concept of “either/or” in DefCore 
today.
       * We can’t include both because the two are essentially mutually 
exclusive in an operating cloud.
     * This situation may occur more often in the future with the 
tagging initiative taken up by the TC recently which seeks in part to 
have a “bigger tent” of projects in OpenStack.  Indeed, several 
contributors expressed “internal competition” as a motivator for the new 
model.
         * As a strawman: it is not unreasonable to think that 
Ceilometer, Monasca, and/or StackTach might one day all be in the 
OpenStack namespace and provide some overlapping functionality.  It is 
also not unreasonable to think that multiple of these might become 
fairly widely deployed, much like Neutron/nova-net today.
     * How should DefCore address these scenarios?
         * Do we want to always force ourselves to choose one project’s 
capabilities over the others?
             * If so: are we choosing Neutron or nova-net? =)
         * Do we include none of the overlapping components in DefCore 
until there’s a clear winner in terms of user acceptance?
             * Basically what we do today.
             * Neutron has been in the integrated release (or “core” as 
it was then known) since Folsom but we apparently still don’t have a 
winner after nearly 3 years…is it really ok not to have networking 
capabilities as part of DefCore?  This seems to expose us to a situation 
where a cloud/vendor/etc might use something completely non-OpenStack to 
provide networking capability and still be able to call itself an 
"OpenStack Powered Platform".
         * Do we want to consider having a “must provide capability x OR 
capability y” construct?
             * Is this too slippery a slope?
             * This would also entail having an "either/or" construct 
for designated sections
         * Do we have a required capability that can be achieved by 
either of two projects and describe *just the tests* in an either/or 
construct?
             * Example: “create and attach an IP address to an instance 
for outside-world connectivity” is something that both nova-net and 
Neutron can do, but each has it’s own tests for this.
             * This would also entail having an "either/or" construct 
for designated sections
         * Other option?
* v2/v3 for Keystone. What tests to choose? Need an -or- condition?
* if targetting >= kilo I say v3. (currently defcore applies to two 
latest releses, so overlap will happen Juno/Kilo) maybe we use a 
small(er) sub-set of tests and target only v3 for both Juno/Kilo. (v3 is 
deployed everywhere unless disabled in `api-paste.ini`).
ML Thread:
http://lists.openstack.org/pipermail/defcore-committee/2015-March/000665.html
     Suggestions about how this might look in practice in our artifacts 
(some unanswered questions there yet): 
http://lists.openstack.org/pipermail/defcore-committee/2015-March/000671.html

# Community Review of Process

* Do we need a DefCore interactive review?+1+1+1+1+1+1
   * Tenative - Tuesday April 7 11am-1pm CDT San Antonio, TX
People who can join in person:
Egle Sigler
Rob Hirschfeld
Vince Brunssen
People who can call in:
Chris Hoge
Jim Meyer (2nd hour)
Carol Barrett
Will Auld (2nd hour)
Agenda
Review Process Doc
Figure out plan to move docs into DefCore repo
* TC interactive review? +1
* Community "open review" meeting April 13th ish+1 +0 (will be in China 
that week)

# Current Defcore Code Review Links
https://review.openstack.org/#/c/169799/
https://review.openstack.org/#/c/169655/
https://review.openstack.org/#/c/169021/
https://review.openstack.org/#/c/167450/
https://review.openstack.org/#/c/169833/

ACTION > Rob will recommend 2015.next for approval on 4/2 BoD meeting

# Changes JSON format (to become v1.2)

ACTION > Pulls for Flagged Test Reason
https://review.openstack.org/#/c/169833/ < Catherine's previously-merged 
patch for 2015.03 applied to 2015.next
DISCUSSION > Pulls for to make it Version ++
      Moving this to a DefCore Process discussion
      Chris to do a pull request for discussion
ACTION > Pulls to include Designated Section






-- 
   

Rob
____________________________
Rob Hirschfeld, 512-773-7522

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