<div dir="ltr">Hi Jorge,<div><br></div><div class="gmail_extra"><div class="gmail_quote">On Fri, Jun 6, 2014 at 12:48 PM, Jorge Miramontes <span dir="ltr"><<a href="mailto:jorge.miramontes@rackspace.com" target="_blank">jorge.miramontes@rackspace.com</a>></span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
1) We are assuming that load balancers can only operate on one update at a<br>
time correct? I.E. We are not allowing multiple updates to occur<br>
concurrently? Whatever the case on this I advocate that we do NOT allow<br>
concurrent modification as complexity of the system increases dramatically<br>
and the gain is very small since load balancers are usually configured<br>
upon create and then rarely updated over their lifetime.<br></blockquote><div><br></div><div>I agree. The only exception to this rule I would say is that operations which delete objects should be allowed to override any queued up reconfiguration. (If a resource gets into a strange state where it isn't otherwise alterable, it's handy to be able to delete it without operator intervention.)</div>


<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2) It appears that sharing objects is causing complexity to creep in the<br>
deeper the conversations are getting. For example, managing object<br>
statuses seems like a nightmare! That said, does the fundamental rationale<br>
for sharing objects outweigh the simplicity of not sharing objects?<br></blockquote><div><br></div><div>I wouldn't say it's a nightmare, but it certainly isn't trivial, and some solutions to this problem may reveal more about the back-end than we really want to reveal to a user. This particular complication only comes into play when "status" becomes a meaningful attribute of the object. (For example, "status" is meaningless on logical constructs like L7Policies or TLS Certificates.) Do you see complications other than status and stats collection becoming an issue here?</div>
<div><br></div><div>Having said this, it would be possible to define most things with a 'status' from the load balancer down in the object tree as being non-share-able, I suppose. It does simplify what needs to be done algorithmically by quite a bit, but does complicate the user experience when it comes to setting up and maintaining load balancer related configuration.</div>
<div><br></div><div>I will say: I'm a little reluctant to change horses at this stage in the race, though. I feel like we have discussed this pretty thoroughly in the past and am not sure it's appropriate to re-hash those discussions now. What you're talking about are essentially core object-model level changes.  (Obviously, others should feel free to disagree with me about whether it makes sense to revisit this discussion yet again.)</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I understand that we've been diligently working on the API revision but I<br>
wanted to take a step back and look at the goal we are trying to solve and<br>
weigh the perceived need for complexity (i.e "flexibility" in the API) vs<br>
a simpler solution.<br><br></blockquote></div><div class="gmail_extra"><br></div><div class="gmail_extra">Stephen</div><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br><a href="tel:%28800%29613-4305%20x807" value="+18006134305" target="_blank">(800)613-4305 x807</a>

</div></div>