Open Stack

From: Kamhout, Das [mailto:das.kamhout at intel.com] 
Sent: Friday, September 12, 2014 12:04 PM

I am with you Tim...

It is almost like someone just needs to put together a dependencies map, and really look at this from the perspective of what an operator needs to supply a different set (ala carte - or everything in the integrated release) of consumable services to their end users (people building cool apps on OpenStack).

I may  be missing something, but this conversation almost feels academic vs. what will benefit shops wanting to run and consume OpenStack services ala carte, or with everything that is needed.


[Rocky Grober]
First, all, please remember that this set of capabilities, tests and designated code is being analyzed and graded against the state of OpenStack as it *was* at Havana Release.  That said:
 
The current DefCore discussion *is* "academic" or really "legal" as Defcore is starting with just a straightforward process of:

1.  List the capabilities existing in Havana integrated release
2.  Rate and rank them against the 12 criteria and weighting established
2.5 Eliminate all admin required capabilities as tests are not runnable by non-privileged "users" 
3.  Identify tests
4.  Identify code

The current process is really *totally* ignoring the operators and their shops because of the specific determination to ignore all admin required capabilities for this round.  This is something that needs to be part of the discussion going forward:  how to include admin capabilities in Refstack tests when the tester does not have admin privilege (hierarchical clouds may provide a solution for at least some of that, but that's future).  

But also keep in mind that DefCore has never taken the stance that what is declared "core" will deliver a working openstack cloud solution.  Its purpose is to say what has to be within the code set and behaviors (as verified by the capabilities tests) of a cloud product to be able to legally use the/an OpenStack trademark.

With the law, working has little to do with rights, privileges and contracts;-)

--Rocky
[/Rocky Grober]


-Das

From: Tim Bell <Tim.Bell at cern.ch<mailto:Tim.Bell at cern.ch>>
Date: Friday, September 12, 2014 at 11:57 AM
To: Joshua McKenty <joshua at pistoncloud.com<mailto:joshua at pistoncloud.com>>, Rob Hirschfeld <Rob_Hirschfeld at Dell.com<mailto:Rob_Hirschfeld at Dell.com>>
Cc: "Defcore-committee at lists.openstack.org<mailto:Defcore-committee at lists.openstack.org>" <Defcore-committee at lists.openstack.org<mailto:Defcore-committee at lists.openstack.org>>
Subject: Re: [OpenStack-DefCore] Results from Community Meetings > discussion/+1 about reconsidering Havana Swift as a core capability


I'm a real newbie on this topic but isn't a Keystone token a pre-requisite and strategic direction for any other operation ?

Code is another question....

Tim

From: Joshua McKenty [mailto:joshua at pistoncloud.com]
Sent: 12 September 2014 20:37
To: Rob Hirschfeld
Cc: Defcore-committee at lists.openstack.org<mailto:Defcore-committee at lists.openstack.org>
Subject: Re: [OpenStack-DefCore] Results from Community Meetings > discussion/+1 about reconsidering Havana Swift as a core capability

Just so I'm clear, Doug - you would therefore also like to propose some designated sections for Keystone?

--

Joshua McKenty
Chief Technology Officer
Piston Cloud Computing, Inc.
+1 (650) 242-5683
+1 (650) 283-6846
http://www.pistoncloud.com

"Oh, Westley, we'll never survive!"
"Nonsense. You're only saying that because no one ever has."

On Sep 12, 2014, at 11:35 AM, <Rob_Hirschfeld at Dell.com<mailto:Rob_Hirschfeld at Dell.com>> <Rob_Hirschfeld at Dell.com<mailto:Rob_Hirschfeld at Dell.com>> wrote:



> -----Original Message-----
> From: Doug Hellmann [mailto:doug at doughellmann.com]
> The actual current proposal, if I understand correctly, is to require
> the Swift APIs be provided, but not require the use of Swift's code to
> do so. We may be converging on dropping the requirement of the APIs,
> but I don't think that's settled.



The current Havana recommendation includes some Swift APIs; however, I believe we should (and will ask the Board to) reconsider that based on feedback I have been getting.

> I believe, and Rob please correct me if I misunderstood, that some
> distros would also like to provide an OpenStack product that doesn't
> include object storage in any way (neither Swift nor Ceph). I'm not
> especially inclined to care about that use case, but it's out there.



I don't see distros doing omitting whole projects; however, more integrated products or services have already proven that they will be more selective.  IMHO, that's the market giving us critical feedback and we should be careful in over fencing the market.
_______________________________________________
Defcore-committee mailing list
Defcore-committee at lists.openstack.org<mailto:Defcore-committee at lists.openstack.org>
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee


_______________________________________________
Defcore-committee mailing list
Defcore-committee at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee