openstack team mailing list archive

["Day, Phil" <philip.day@xxxxxx>]

Hi Folks,

At the risk of looking lazy in my first question by following up with a second:

So I tracked this down in the code and can see that the validation has moved into network/manager.py, and what was a validation/cast in network/api.py has been replaced with a call - but that seems to make the system more tightly coupled across components (i.e. if my there is a problem getting the message to the Network Manager then even an invalid request will be blocked until the call returns or times out).

It also looks as if the validation for disassociate_floating_ip has also been moved to the manager, but this is still a cast from the api layer - so those error messages never get back to the user.

Coming from Diablo it all feels kind of odd to me - I thought we were trying to validate what we could of requests in the API server and return immediate errors at that stage and then cast into the system (so that only internal errors can stop something from working at this stage).     Was there a deliberate design policy around this at some stage ?

Cheers,
Phil

From: openstack-bounces+philip.day=hp.com@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+philip.day=hp.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Day, Phil
Sent: 28 March 2012 09:20
To: openstack@xxxxxxxxxxxxxxxxxxx (openstack@xxxxxxxxxxxxxxxxxxx) (openstack@xxxxxxxxxxxxxxxxxxx)
Subject: [Openstack] Validation of floating IP opertaions in Essex codebase ?

Hi Stackers,

In Diablo there is a bunch of validation that goes on in the network/api layer, for example when associating an IP to an instance there are checks for:


-          Is the address allocated

-          Is it allocated to this project

-          Is it already assigned to an instance, and if so dis-associate it first.

However looking at the same code in Essex I just see a simple call to the Manager:

    def associate_floating_ip(self, context, floating_address, fixed_address,
                                                 affect_auto_assigned=False):
        """Associates a floating ip with a fixed ip.

        ensures floating ip is allocated to the project in context
        """
        rpc.call(context,
                 FLAGS.network_topic,
                 {'method': 'associate_floating_ip',
                  'args': {'floating_address': floating_address,
                           'fixed_address': fixed_address,
                           'affect_auto_assigned': affect_auto_assigned}})


True there is some validation in the manager side  to prevent association if the address is already in use (which was also in Diablo), but by then it's too late to return a meaningful error to the user.

I can't see where the other checks have been moved to (they don't appear to be in the API extension or compute/api layer (which the request passes through).   Can someone point me to where this sort of validation is handled now please ?

I agree that the api code looks a lot cleaner in Essex without all of that validation code in it ;-)  - but surely we haven't removed those checks altogether ?

Thanks
Phil