Open Stack

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). 





> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/defcore-committee/attachments/20141017/9ff864f1/attachment-0001.html>