<div dir="ltr">Hello! I'm gonna answer inline as well, based on Phillip's responses.<div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jan 6, 2015 at 12:33 PM, Phillip Toohill <span dir="ltr"><<a href="mailto:phillip.toohill@rackspace.com" target="_blank">phillip.toohill@rackspace.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ill answer inline what I can, others can chime in to clear up anything and<br>
answer the rest.<br>
<span class=""><br>
On 1/6/15 10:38 AM, "Andrew Hutchings" <<a href="mailto:andrew@linuxjedi.co.uk">andrew@linuxjedi.co.uk</a>> wrote:<br>
<br>
>Hi,<br>
><br>
>I¹m looking into the Octavia project in relation to something my team are<br>
>working on inside HP and I have a bunch of questions.  I realise it is<br>
>early days for the project and some of these could be too low level at<br>
>this time.<br>
><br>
>Some of these questions come from the fact that I could not get the<br>
>documentation to compile and the docs site for Octavia is down.  The<br>
>v0.5-component-design.dot file crashes Graphviz 2.38 in every OS I tried<br>
>and unfortunately all my dev machines have that version or 2.36 which is<br>
>too low to render it correctly.  It also requires at least 5 extra<br>
>dependencies (Sphinx modules) to build the docs but doesn¹t try to<br>
>install them.<br></span></blockquote><div><br></div><div>I'm not sure what to tell you on this: It rendered fine when I wrote it using 2.37. I'm now using 2.39 and it still renders fine for me and others on the project. Perhaps (in private e-mail or chat) you could send me your error output and we can help you troubleshoot it?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
><br>
>I¹ll guess I¹ll start from the most obvious question:<br>
><br>
>1. Octavia looks a lot like Libra but with integration into Neutron and<br>
>Barbican (both were planned for Libra) as well as few other changes.  So<br>
>the most obvious question is: why not just develop Libra for integration<br>
>with Neutron?<br>
</span>There was many discussions with many contributors that included HP,<br>
Rackspace, Bluebox A10 etc.. In regards to this decision. In the docs we<br>
should have links to the reasonings behind some of these.<br></blockquote><div><br></div><div>Phillip is right about this. It's also been many months since we discussed this, but I seem to recall that nobody working on the project was in favor of starting with the Libra code. Rather, we're building this from the ground up, perhaps utilizing some of the lessons learned in Libra, but also with the intent to not repeat mistakes made with Libra. If you'd like to think of Octavia as "next generation Libra" that's fine, but they really are separate projects. Please also note that this is a fruitless discussion: Nobody working on Octavia is interested in going back on the months of discussion, design, and work we've done on Octavia and starting from the Libra source code at this time.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">><br>
>Amphorae stuff:<br>
><br>
>2. I see a lot of building blocks for the controller and Amphorae but not<br>
>a lot about communication.  What protocol / method is to be used to<br>
>communicate to the Amphorae instances?<br>
</span>In the docs/specs the communication protocols are defined.<br></blockquote><div><br></div><div>..and they usually end up being RESTful when it's intended for components to run on separate machines (virtual or otherwise). As far as what each of these internal APIs look like: Some have been defined in separate specs, some are still under review, some have yet to be defined.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>3. How are Amphorae instances to be spun up on-demand?  I see a reference<br>
>to Heat but not sure if that is why it is there<br>
<br>
</span>The specs define how this is to happen<br></blockquote><div><br></div><div>The reference to heat has to do with auto-scaling, which is something that will come into play a lot later in the development process, probably after Octavia v2.0. Even when this is in place, though, Octavia contains a controller which interfaces with Nova and Neutron to accomplish spinning up amphorae as needed. And yes, these are defined in separate specs.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>4. There is mention of Docker in some of the deploy scripts.  Is this for<br>
>multi-tenancy or just separation of the Amphorae processes?<br></span></blockquote><div><br></div><div>Docker (and the use of containers) is envisioned as one possible way to generate amphora (as opposed to a pure VM). There is no plan at this time to allow for multi-tenancy on a single amphora. Initially, each amphora will also service only one loadbalancer.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
>5. I take it Amphorae is designed to be single-AZ for now?<br></span></blockquote><div><br></div><div>Correct. Multi-AZ is something that will be discussed probably after the v1.0 release.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
><br>
>Load Balancing:<br>
><br>
>6. It seems like you are going to have SSL termination support and are<br>
>going to use HAProxy, which means that you will have unencrypted data<br>
>between the LB and web servers.  How do you plan to work around this<br>
>problem?<br>
</span>Not sure what the 'problem' is, ultimately its up to the user, but a<br>
private network can be configured between the LB and Web server<br></blockquote><div><br></div><div>Yes, again for some this is not a problem. In the context of Neutron LBaaS (which Octavia will be using as its user API), there has been some discussion of encrypting traffic between the "thingy" providing load balancing and the back-end pool member machines. So far, though, nobody working on the project has had this as a show-stopper requirement-- and everyone working on it would simply like to see front-end TLS termination delivered first (ie. walk before running).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="">><br>
>Security:<br>
><br>
>7. Someone in the specification there is talk of a 1 minute cache of<br>
>security certificates.  How are you going to ensure that the cache will<br>
>actually erase that cache after the 1 minute?  Also why cache them at<br>
>all?  It seems to me to be a potential security risk<br></span></blockquote><div><br></div><div>This is an obvious optimization for deploying a given user-supplied TLS certificate across several amphorae in rapid succession. It's likely initial versions of the code will not actually cache anything. Regardless, it's pretty trivial to use something like memcache (or other volatile storage) for this without significantly increasing any security risks.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
><br>
>API:<br>
><br>
>8. More a comment than a question.  There is talk of using Pecan+WSME.<br>
>Libra had a 5K patch on top of WSME just to make it behave correctly with<br>
>Pecan and correct JSON specifications in certain situations, judging by<br>
>the planned API you will also hit those same situations.  I admit I¹ve<br>
>not looked at WSME for a year and there was an effort to strip it out of<br>
>Libra completely at one point.  So that one is mainly my 2c :)<br></span></blockquote><div><br></div><div>Most people on the project are pretty new to pecan and WSME, though we understand that OpenStack in general is moving in this direction, hence our willingness to give it a try. It's entirely possible that we may run into some of the issues you've vaguely alluded to here-- we would appreciate your insight, eh!</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
><br>
>Many thanks for your time.<br>
><br>
>Kind Regards<br>
>--<br>
>Andrew Hutchings - LinuxJedi - <a href="http://www.linuxjedi.co.uk/" target="_blank">http://www.linuxjedi.co.uk/</a><br>
><br>
><br>
<br>
<br>
</span>_______________________________________________<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>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807
</div>
</div></div>