Open Stack

On 09/07/2016 07:34 PM, Andrew Laski wrote:
> 
> 
> On Wed, Sep 7, 2016, at 06:54 PM, Martin Millnert wrote:
>> On Thu, 2016-09-08 at 09:34 +1200, Adrian Turjak wrote:
>>  3) core functionality should IMO require as few API calls as possible,
>> to as few components as possible, while keeping REST data models etc.
>> intact, [1][2]
> 
> I agree that it should require as few API calls as possible but maybe we
> disagree about what core functionality is. Or to put it another way,
> what is core functionality depends on your perspective.
> 
> I subscribe to the plumbing and porcelain approach
> (https://git-scm.com/book/en/v2/Git-Internals-Plumbing-and-Porcelain)
> and believe that Nova should be part of the plumbing. So while I fully
> agree with a small number of API calls to do simple tasks I don't
> believe that orchestrating network setups is core functionality in Nova
> but is core to OpenStack.

Personally, I think that the role of Nova is to give you a functional
compute unit. If you can't talk to that over the network, that doesn't
seem very functional to me. For complicated setups it's fine that you
need to do complicated things, but "I would like a working server with
network" doesn't feel like it's a complicated ask from the user.

And more importantly, if there isn't some firm line there, the ability
to do that between clouds is going to be somewhat limited, because
exactly how you need to configure each cloud's neutron manually to work
with their physical network setup is going to be different.

You end up with the shade situation now, which isn't a great user
experience.

I do get the concern about Nova scope creep into orchestration. However
it's not like "orchestration" has a bright line anywhere. And I think
that basic working networking for requested computes isn't something we
should require another service for.

	-Sean

-- 
Sean Dague
http://dague.net