Open Stack

Hi Brandon,


On Tue, Apr 22, 2014 at 6:58 AM, Brandon Logan
<brandon.logan at rackspace.com>wrote:

> 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'm talking about actually implementing single-call API within existing
code (LBaaS plugin)
Let's see what it takes. It obviously should not account for each end every
case we have in mind,
but at least it should allow existing functionality (single vip, single
pool).


> 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.
>
I'd prefer to see such patch on gerrit.



>
> 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),

That also smells like a bit of generic work for Neutron Extension Framework.
It has limited support for 2nd level resources right now.

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.
>

Yes, I think most extensions provide both additional resources and
additional validation methods.

Thanks,
Eugene.


> 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
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140422/f3fc9b22/attachment.html>