Open Stack

The new Keystone PTL, Morgan Fainberg and I sat down to review the current state of Keystone tests and their relation to Defcore last week. There’s definitely a full range of tests available in Tempest. We’ve identified the set that are essential for Keystone functionality and should be wrapped into Defcore in some way. If the only blocker to entry is porting the client-based test to endpoint based tests, that can be one of my short-term tasks in the month or so leading up to and out of the summit. Keystone is too important to be left on the floor in this process.

I’m attaching the Etherpad that Morgan and I worked up for additional comment and review.

https://etherpad.openstack.org/p/keystone-defcore

-Chris


On Oct 17, 2014, at 6:27 AM, Troy Toman <troy at tomanator.com> wrote:

> 
>> On Oct 17, 2014, at 8:14 AM, Mark Collier <mark at openstack.org> wrote:
>> 
>> I personally think public cloud is this *most* important target for defcore. IMHO having a consistent target for developers to write to across dozens of different public clouds all over the world is job 1. 
>> 
>> I agree with your point about volume and image being important for compute. 
>> 
>> On the requirements that are problematic for large scale deployments it seems that removing those requirements is the quick "fix" while addressing the underlying technical fit in the code is the right long term solution (easier said than done i know). 
> 
> I agree that targeting those capabilities is important and prioritizing the resolution is key. My concern is that if the capability is defined as ‘images-v1’ and the resolution is ‘images-v2’, we need to make sure that becomes a replacement capability vs. a superset. Similarly, the floating IP and security groups capabilities are defined based on API extensions and implementations in Nova. If the resolution comes through Neutron only improvements, that needs to be reflected in the required capabilities. The problem comes when we have a goal of not removing capabilities easily on a going forward basis.
> 
>> 
>> 
>> 
>> 
>> 
>> On Oct 17, 2014, at 8:02 AM, Troy Toman <troy at tomanator.com> wrote:
>>  
>>> A few thoughts that apply broadly - so I’ll top post.
>>> 
>>> I think this is fine as a starting point for broad feedback. But, I would see an alternative which is to include volume and image under Compute. I realize this potentially misalign with how we name things on the development side. But, we have often talked about the unique interconnection between basic compute, block and image services. In particular, you can’t really boot server without some reference to images (unlike having a standalone object store). So, I would be a proponent of including those under a compute umbrella that goes beyond Nova.
>>> 
>>> Also, I will raise a point in writing that I have brought up in several conversations (this is really feedback on the Havana proposal in general as opposed to this particular split.) While I realize that compute-floating-ips, compute-security-groups and images-v1 made it through the scoring process, they are problematic for large-scale public cloud applications. This is the reason they are not offered by Rackspace’s cloud service. This is being addressed on a number of fronts. However, the concerns about images-v1 were addressed with images-v2 (which is available from Rackspace’s public cloud) and the ways to address security groups and floating IPs are being discussed in the context of Neutron (which is not represented in the current capabilities.) This means those 3 capabilities may never be feasible.
>>> 
>>> If public cloud is a target use case for Defcore, then we need to consider if those capabilities go forward for Icehouse and Juno or not. I expect you will see more details coming from the public cloud team at Rackspace. But, I wanted to make sure the Defcore team is aware.
>>> 
>>> Troy
>>> 
>>>> On Oct 16, 2014, at 11:12 PM, rob at zehicle.com wrote:
>>>> 
>>>> DefCore,
>>>>  
>>>> I believe it's important for us to have a specific recommendation for the board meeting so there can be a vote that moves us forward.   I've compiled a draft based on my understanding of the Foundation's proposal and discussions on the list.  Discussion (or +1) is encouraged!
>>>>  
>>>> I will preemptively remind everyone about the glaring omission of Keystone.  There were no tests, so we have no Havana Keystone capabilities.
>>>>  
>>>> Platform and Program Capabilities
>>>> 
>>>> Recommendation:  Extend the DefCore principles to allow for multiple levels: programs and platforms.  Programs represent subsections of the overall platform.  In some cases, it is acceptable for a program identified without being included in the platform.  New programs are added at Foundation recommendation via board approval.  Programs are added to the platform via board approval.
>>>> 
>>>> Recommendation: The initial programs will be Compute & Object.  The DefCore platform will require the Compute program, Object program and additional capabilities.
>>>> 
>>>> Recommendation: The Compute Program will consist of the following capabilities: 
>>>> 
>>>> compute-servers 
>>>> 
>>>> compute-volume
>>>> 
>>>> compute-quotas
>>>> 
>>>> compute-flavors
>>>> 
>>>> compute-auth
>>>> 
>>>> compute-keypairs
>>>> 
>>>> compute-servers-metadata
>>>> 
>>>> compute-floating-ips 
>>>> 
>>>> compute-images 
>>>> 
>>>> compute-instance-actions 
>>>> 
>>>> compute-security-groups
>>>> 
>>>> 
>>>> Recommendation: The Object Program will consist of the following capabilities:
>>>> 
>>>> objectstore-object, 
>>>> 
>>>> objectstore-container
>>>> 
>>>> 
>>>> Recommendation: The Platform will consist of all the capabilities in the Compute and Object programs and the following capabilities:
>>>> 
>>>> images-v1
>>>> 
>>>> volume
>>>> 
>>>> volume-snapshots 
>>>>  
>>>> 
>>>> 
>>>> Rob 
>>>> ____________________________ 
>>>> Rob Hirschfeld, 512-773-7522 
>>>> 
>>>> I am in CENTRAL (-6) time 
>>>> http://robhirschfeld.com 
>>>> twitter: @zehicle, github: cloudedge & ravolt
>>>> _______________________________________________
>>>> Defcore-committee mailing list
>>>> 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
> 
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20141017/bfde0865/attachment-0001.html>