Open Stack

Hello Eugene!

Are you talking about seeing the code in a simplified approach for a
single create call using the current API objects, or one that uses
objects created based on the proposal?

I was experimenting over the weekend on getting a single create call in
the current API model.  I was able to implement it pretty easy but did
run into some issues.  Now, since this was just a quick test, and to
save time I did not implement it the correct way, only a way in which it
accepted a single create call and did everything else the usual way.  If
it were actually a blueprint and up for a merge I would have done it the
proper way (and with everyone else's input).  If you want to see that
code let me know, its just on a branch of a fork.  Nothing really much
to see though, implemented in the easiest way possible.  For what its
worth though, it did speed up the creation of an actual load balancer by
75% on average.

The current way to define an extension's resources and objects is using
a dictionary that defines the resource, object expected for POSTs and
PUTs, and plugin methods to be implemented.  This dictionary is passed
to the neutron API controller that does validation, defaulting, and
checks if an attribute of an object is required and if it can be changed
on posts and puts.  This currently does not support defaults for 2nd
level nested dictionary objects, and doesn't support validation,
defaulting, or required attributes for any nesting level after the
2nd.  

This can easily be added in obviously (smells like recursion will come
in handy), but it should be noted that just the resource and API object
schema definitions for what we need for a single create call are not
supported right now.

Maybe there's some way to allow the extensions to define their own
validation for their own resources and objects.  That's probably another
topic for another day, though.

On Fri, 2014-04-18 at 17:53 +0400, Eugene Nikanorov wrote:
>                 > 3. Could you describe the most complicated use case
>                 > that your single-call API supports? Again, please be
>                 > very specific here.
>                 Same data can be derived from the link above.
>                 
>                 
>         
>         
>         Ok, I'm actually not seeing and complicated examples, but I'm
>         guessing that any attributes at the top of the page could be
>         expanded on according the the syntax described.
>         
>         
>         Hmmm...  one of the draw-backs I see with a "one-call"
>         approach is you've got to have really good syntax checking for
>         everything right from the start, or (if you plan to handle
>         primitives one at a time) a really solid roll-back strategy if
>         anything fails or has problems, cleaning up any primitives
>         that might already have been created before the whole call
>         completes.
>         
>         
>         The alternative is to not do this with primitives... but then
>         I don't see how that's possible either. (And certainly not
>         easy to write tests for:  The great thing about small
>         primitives is their methods tend to be easier to unit test.)
>  
> These are the good arguments! That's why I'd like to actually see the
> code (even simplified approach will could work as a first step), i
> thing it could do a lot of things clearer.
> 
> 
> Thanks,
> Eugene.
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev