Open Stack

On Wed, Feb 5, 2014 at 5:54 PM, Rochelle.RochelleGrober
<rochelle.grober at huawei.com> wrote:
> On Wed, Feb 5, 2014 at 12:05 PM, Russell Bryant <rbryant at redhat.com> wrote:
>
> On 02/05/2014 11:22 AM, Thierry Carrez wrote:
>> (This email is mostly directed to PTLs for programs that include one
>> integrated project)
>>
>> The DefCore subcommittee from the OpenStack board of directors asked the
>> Technical Committee yesterday about which code sections in each
>> integrated project should be "designated sections" in the sense of [1]
>> (code you're actually needed to run or include to be allowed to use the
>> trademark). That determines where you can run alternate code (think:
>> substitute your own private hypervisor driver) and still be able to call
>> the result openstack.
>>
>> [1] https://wiki.openstack.org/wiki/Governance/CoreDefinition
>>
>> PTLs and their teams are obviously the best placed to define this, so it
>> seems like the process should be: PTLs propose designated sections to
>> the TC, which blesses them, combines them and forwards the result to the
>> DefCore committee. We could certainly leverage part of the governance
>> repo to make sure the lists are kept up to date.
>>
>> Comments, thoughts ?
>>
>
> The process you suggest is what I would prefer.  (PTLs writing proposals
> for TC to approve)
>
> Using the governance repo makes sense as a means for the PTLs to post
> their proposals for review and approval of the TC.
>
>
>
> +1
>
>
>
> +1
>
>
>
> Who gets final say if there's strong disagreement between a PTL and the
> TC?  Hopefully this won't matter, but it may be useful to go ahead and
> clear this up front.
>
>
>
> The Board has some say in this, too, right? The proposal [1] is for a set of
> tests to be proposed and for the Board to approve (section 8).
>
>
>
> What is the relationship between that test suite and the designated core
> areas? It seems that anything being tested would need to be designated as
> core. What about the inverse?
>
>
>
> The test suite should validate that the core
> capabilities/behaviors/functionality behave as expected (positive and
> negative testing in an integrated environment).  So, the test suites would
> need to be reviewed for applicability.  Maybe, like Gerrit, there would be
> voting and nonvoting parts of tests based on whether something outside of
> core gets exercised in the process of running some tests.  Whatever the
> case, I doubt that the tests would generate a simple yes/no, but rather a
> score.  An discussion of one of the subsets of capabilities for Nova might
> start with the capabilities highlighted on this page:
>
> https://wiki.openstack.org/wiki/HypervisorSupportMatrix
>
>
>
> The test suite would need to exercise the capabilities in these sorts of
> matrices and might product the A/B/C grades as the rest of the page
> elucidates.
>

Sorry but I think this misses the point of the PTL request being made
here.  The question being asked is not "is the interface compatible",
it's quite possible for somebody to build a cloud without a single
piece of OpenStack code but still provide an OpenStack compatible
interface and mimic behaviors.  IMO compatibility tests already exist
for the most part via the Tempest test suite that we use to gate on.
If I'm incorrect and that is in fact the goal, that's significantly
easier to solve IMO.

The question here as I understand it (and I may be confused again
based on the thread here) is what parts of the code/modules are
required to be used in order for somebody building a cloud to say
"it's an OpenStack cloud"?  The cheat answer for me would be, you have
to be using cinder-api, cinder-scheduler and cinder-volume services
(regardless of driver).  That raises the next layer of detail though,
do those services have to be un-modified?  How much modification is
acceptable etc. What about deployments that may use their own
scheduler?

I think the direction the thread is taking here is that there really
isn't enough information to make this call, and there certainly isn't
enough understanding of the intent, meaning or ramifications.
>
>
> --Rocky
>
>
>
> Doug
>
>
>
> [1] https://wiki.openstack.org/wiki/Governance/CoreDefinition
>
>
>
>
>
>
> --
> Russell Bryant
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>