<div dir="ltr">Hi Brandon,<div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Apr 22, 2014 at 6:58 AM, Brandon Logan <span dir="ltr"><<a href="mailto:brandon.logan@rackspace.com" target="_blank">brandon.logan@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello Eugene!<br>
<br>
Are you talking about seeing the code in a simplified approach for a<br>
single create call using the current API objects, or one that uses<br>
objects created based on the proposal?<br></blockquote><div>I'm talking about actually implementing single-call API within existing code (LBaaS plugin)</div><div>Let's see what it takes. It obviously should not account for each end every case we have in mind,</div>
<div>but at least it should allow existing functionality (single vip, single pool).</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I was experimenting over the weekend on getting a single create call in<br>
the current API model. I was able to implement it pretty easy but did<br>
run into some issues. Now, since this was just a quick test, and to<br>
save time I did not implement it the correct way, only a way in which it<br>
accepted a single create call and did everything else the usual way. If<br>
it were actually a blueprint and up for a merge I would have done it the<br>
proper way (and with everyone else's input). If you want to see that<br>
code let me know, its just on a branch of a fork. Nothing really much<br>
to see though, implemented in the easiest way possible. For what its<br>
worth though, it did speed up the creation of an actual load balancer by<br>
75% on average.<br></blockquote><div>I'd prefer to see such patch on gerrit.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The current way to define an extension's resources and objects is using<br>
a dictionary that defines the resource, object expected for POSTs and<br>
PUTs, and plugin methods to be implemented. This dictionary is passed<br>
to the neutron API controller that does validation, defaulting, and<br>
checks if an attribute of an object is required and if it can be changed<br>
on posts and puts. This currently does not support defaults for 2nd<br>
level nested dictionary objects, and doesn't support validation,<br>
defaulting, or required attributes for any nesting level after the<br>
2nd.<br>
<br>
This can easily be added in obviously (smells like recursion will come<br>
in handy), </blockquote><div>That also smells like a bit of generic work for Neutron Extension Framework.</div><div>It has limited support for 2nd level resources right now.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
but it should be noted that just the resource and API object<br>
schema definitions for what we need for a single create call are not<br>
supported right now.<br>
<br>
Maybe there's some way to allow the extensions to define their own<br>
validation for their own resources and objects. That's probably another<br>
topic for another day, though.<br></blockquote><div> </div><div>Yes, I think most extensions provide both additional resources and additional validation methods.</div><div><br></div><div>Thanks,</div><div>Eugene.</div><div>
<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
On Fri, 2014-04-18 at 17:53 +0400, Eugene Nikanorov wrote:<br>
> > 3. Could you describe the most complicated use case<br>
> > that your single-call API supports? Again, please be<br>
> > very specific here.<br>
> Same data can be derived from the link above.<br>
><br>
><br>
><br>
><br>
> Ok, I'm actually not seeing and complicated examples, but I'm<br>
> guessing that any attributes at the top of the page could be<br>
> expanded on according the the syntax described.<br>
><br>
><br>
> Hmmm... one of the draw-backs I see with a "one-call"<br>
> approach is you've got to have really good syntax checking for<br>
> everything right from the start, or (if you plan to handle<br>
> primitives one at a time) a really solid roll-back strategy if<br>
> anything fails or has problems, cleaning up any primitives<br>
> that might already have been created before the whole call<br>
> completes.<br>
><br>
><br>
> The alternative is to not do this with primitives... but then<br>
> I don't see how that's possible either. (And certainly not<br>
> easy to write tests for: The great thing about small<br>
> primitives is their methods tend to be easier to unit test.)<br>
><br>
> These are the good arguments! That's why I'd like to actually see the<br>
> code (even simplified approach will could work as a first step), i<br>
> thing it could do a lot of things clearer.<br>
><br>
><br>
> Thanks,<br>
> Eugene.<br>
</div></div><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>