Open Stack

On 05/17/13 at 09:12am, Christopher Yeoh wrote:
>On Thu, 16 May 2013 10:11:26 -0400
>Andrew Laski <andrew.laski at rackspace.com> wrote:
>> On 05/14/13 at 09:18am, Christopher Yeoh wrote:
>> > <snip>
>> >In a closely related issue there is also a blueprint covering
>> >promoting APIs to core and vice-versa and we'll need to get a
>> >consensus around this as well, so if anyone has any suggestions,
>> >please make them.
>>
>> I'm assuming that core means on by default, and guaranteed to be on
>> because there's some enforcement of it being loaded.  If this is not
>> the case then disregard the rest of this post, but if it is I would
>> like to propose an alternative.
>
>What is loaded by default is currently down to just what is in setup.cfg
>when Nova is packaged and then whatever is found in PYTHONPATH at
>runtime. I've held off on hard coding checks that all of the "core" API
>is in and abort if not present as I wasn't sure how much desire there
>was for it (though its starting to sound like people do really want
>that).
>
>My understanding is that what is to be considered core may at least be
>partly a political decision related to using the OpenStack trademark.
>eg. What features do you need to be able to call it an
>OpenStack based cloud?

I have the same understanding.  And that's why I'm not as concerned 
about forcing specific extensions to be loaded.  Providers should be 
looking to be compliant with refstack, or whatever is used for this 
purpose, but I'm not sure it's the job of Nova to enforce that.  I would 
rather see us provide a default configuration that's compliant, but not 
limit flexibility.  I can also see Russells point about providing a 
known quantity that's guaranteed to be there.  I would just like to see 
it limited in scope.

>
>> I suppose another way I could phrase the argument would be that I
>> think core, as I think it's currently defined, should not contain
>> anything that can't be supported by any Nova deployment.  Which I
>> think pares it down to a bare minimum of functionality that would be
>> guaranteed to be loaded.
>
>I think its a good guideline, but I wouldn't make it a strict
>requirement. At this stage I don't think we want to be too restricted by
>the lowest common set of functionality. That, or we raise the
>requirement for what we'll support.

I agree with this.  I didn't mean for it to come across as too strict.  
What I'm really after here is configurability and flexibility.

>
>Chris.
>
>_______________________________________________
>OpenStack-dev mailing list
>OpenStack-dev at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev