Open Stack

Hello! I'm gonna answer inline as well, based on Phillip's responses.

On Tue, Jan 6, 2015 at 12:33 PM, Phillip Toohill <
phillip.toohill at rackspace.com> wrote:

> Ill answer inline what I can, others can chime in to clear up anything and
> answer the rest.
>
> On 1/6/15 10:38 AM, "Andrew Hutchings" <andrew at linuxjedi.co.uk> wrote:
>
> >Hi,
> >
> >I¹m looking into the Octavia project in relation to something my team are
> >working on inside HP and I have a bunch of questions.  I realise it is
> >early days for the project and some of these could be too low level at
> >this time.
> >
> >Some of these questions come from the fact that I could not get the
> >documentation to compile and the docs site for Octavia is down.  The
> >v0.5-component-design.dot file crashes Graphviz 2.38 in every OS I tried
> >and unfortunately all my dev machines have that version or 2.36 which is
> >too low to render it correctly.  It also requires at least 5 extra
> >dependencies (Sphinx modules) to build the docs but doesn¹t try to
> >install them.
>

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?


> >
> >I¹ll guess I¹ll start from the most obvious question:
> >
> >1. Octavia looks a lot like Libra but with integration into Neutron and
> >Barbican (both were planned for Libra) as well as few other changes.  So
> >the most obvious question is: why not just develop Libra for integration
> >with Neutron?
> There was many discussions with many contributors that included HP,
> Rackspace, Bluebox A10 etc.. In regards to this decision. In the docs we
> should have links to the reasonings behind some of these.
>

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.


> >
> >Amphorae stuff:
> >
> >2. I see a lot of building blocks for the controller and Amphorae but not
> >a lot about communication.  What protocol / method is to be used to
> >communicate to the Amphorae instances?
> In the docs/specs the communication protocols are defined.
>

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


> >3. How are Amphorae instances to be spun up on-demand?  I see a reference
> >to Heat but not sure if that is why it is there
>
> The specs define how this is to happen
>

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.


>
> >4. There is mention of Docker in some of the deploy scripts.  Is this for
> >multi-tenancy or just separation of the Amphorae processes?
>

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.


> >5. I take it Amphorae is designed to be single-AZ for now?
>

Correct. Multi-AZ is something that will be discussed probably after the
v1.0 release.


> >
> >Load Balancing:
> >
> >6. It seems like you are going to have SSL termination support and are
> >going to use HAProxy, which means that you will have unencrypted data
> >between the LB and web servers.  How do you plan to work around this
> >problem?
> Not sure what the 'problem' is, ultimately its up to the user, but a
> private network can be configured between the LB and Web server
>

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


> >
> >Security:
> >
> >7. Someone in the specification there is talk of a 1 minute cache of
> >security certificates.  How are you going to ensure that the cache will
> >actually erase that cache after the 1 minute?  Also why cache them at
> >all?  It seems to me to be a potential security risk
>

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.


> >
> >API:
> >
> >8. More a comment than a question.  There is talk of using Pecan+WSME.
> >Libra had a 5K patch on top of WSME just to make it behave correctly with
> >Pecan and correct JSON specifications in certain situations, judging by
> >the planned API you will also hit those same situations.  I admit I¹ve
> >not looked at WSME for a year and there was an effort to strip it out of
> >Libra completely at one point.  So that one is mainly my 2c :)
>

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!


> >
> >Many thanks for your time.
> >
> >Kind Regards
> >--
> >Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/
> >
> >
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Stephen Balukoff
Blue Box Group, LLC
(800)613-4305 x807
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150107/bee8c3ae/attachment.html>