Open Stack

On Jun 18, 2015, at 11:17 AM, Chris Hoge <chris at openstack.org> wrote:
> 
> 
>> On Jun 18, 2015, at 7:51 AM, Monty Taylor <mordred at inaugust.com> wrote:
>> 
>> On 06/18/2015 10:48 AM, Rob Hirschfeld wrote:
>>> On 06/18/2015 07:43 AM, Monty Taylor wrote:
>>>> ... bit of a step from being reflective towards influencing what folks
>>>> _Should_ be doing. Agree - excellent topic fo mid-cycle. 
>>> 
>>> From an interop perspective, it's part of our charter.  Some API
>>> differences are reasonable to absorb but we need to find a way to get
>>> ahead of the current sprawl and drive it back towards convergence.  The
>>> goal of DefCore was to create carrots and sticks.
>>> 
>> 
>> I'm honestly not sure I agree that some API differences are reasonable
>> to absorb - but I'm perfectly willing to accept it as a first step
>> position. :)
> 
> It’s unavoidable. If DefCore helps define a standard way to discover that
> interoperability, then its a good start, even if it means for a year OpenStack
> SDKs based on interoperability efforts needs a few nasty 'if-else’ blocks.
> 
> It will be necessary as preferred APIs transition. I think we made a mistake
> in admitting Glance v2 though. It seems like it will be ready for Liberty,
> but doesn’t seem ready now.
> 
> Keystone v2/v3 might also seem like another pain point, but there’s only
> one non-admin api call.
> 
> Networking? I don’t see a good solution for networking. Maybe defining
> the expected ways to accomplish a task like getting a public IP address?

DefCore has scoring criteria.  Some of these things have never actually been thoroughly scored (that I know of) because we’ve presumed that they’d fail one criteria or another (“it’s clearly not widely deployed", etc etc) and we had a lot of other work that needed doing to get this boat into the water.  I think it’s time we actually went through the exercise of scoring some of them even though it’s not easy and we may not find that anything is currently require-able.  

Maybe we’ll be surprised.  But even if not, we’ll have a much clearer picture of what’s closest to meeting the bar and some idea of what has to be done to get over it, which is information the project core teams, TC, and others can use.  I’ve actually already started working on a networking proposal so we can do just that.

At Your Service,

Mark T. Voelker


> 
> This part of why I want to work through the tests and map capabilities to
> APIs. Also, a more deliberate approach to defining capabilities. For example,
> 
> “tempest.api.compute.servers.test_create_server.ServersTestJSON.test_verify_created_server_vcpus”
> 
> exists as a test capability, but I don’t see anything like
> 
> “tempest.api.compute.servers.test_create_server.ServersTestJSON.test_create_server”.
> 
> (maybe "tempest.api.compute.servers.test_servers.ServersTestJSON.test_create_server_with_admin_password”?)
> 
> The former implies the latter, but it’s worrying that we just don’t have
> a direct test for the latter (unless I missed it somewhere). The test for a
> capability should give a developer a blueprint for answering the question
> “how do I do ‘x’?"
> 
> -Chris
> _______________________________________________
> Defcore-committee mailing list
> Defcore-committee at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/defcore-committee