Open Stack

>> 
>> On Aug 13, 2013, at 2:11 AM, Day, Phil wrote:
>> 
>> If we really want to get clean separation between Nova and Neutron in the V3
>> API should we consider making the Nov aV3 API only accept lists o port ids in
>> the server create command ?
>>
>> That way there would be no need to every pass security group information
>> into Nova.
>>
>> Any cross project co-ordination (for example automatically creating ports)
>> could be handled in the client layer, rather than inside Nova.
> 
> Server create is always (until there's a separate layer) going to go cross project
> calling other apis like neutron and cinder while an instance is being
> provisioned. For that reason, I tend to think it's ok to give some extra
> convenience of automatically creating ports if needed, and being able to
> specify security groups.

I think there's a difference between the current interaction with Cinder, where Nova will accept a UUID of a cinder object to attach to, and the interaction with Neutron where Nova actually creates the Port Objects in Neutron, and as a result also needs to accept parameters that are attributes of the foreign object.

Fundamentally the relationship between objects in Nova and Neutron is the instance<>port mapping - so I'm suggesting that's all that needs to be reflected in the V3 API.

If consider some of the problems we've had  in Havana (Neutron port quota running out during server create, Errors from the neutron client being reported back as 500 errors in Nova) etc it seems to me that a lot of those would have been avoided if we had a much simpler model and pushed the cross-service complexity / convenience up to the client layer.


> 
> For the associate and disassociate, the only convenience is being able to use the
> instance display name and security group name, which is already handled at
> the client layer. It seems a clearer case of duplicating what neutron offers.

Agree that this is a clearer case - but in the context of V3 API changes I think we should look at the wider issue.

Cheers,
Phil