Re: [openstack-dev] [Octavia] Questions about the Octavia project
Hi Phillip, Thanks for your response. On 6 Jan 2015, at 20:33, Phillip Toohill phillip.tooh...@rackspace.com wrote: Ill answer inline what I can, others can chime in to clear up anything and answer the rest. The reason I asked the questions I did is because I can’t find any OS the docs will actually compile on and it is difficult to find these answers trawling throw .dot and .rst files. I’ve since found answers for a couple of them. I have several recommendations based on what I have read so far. Such as not using Protobufs instead of JSON for the Amphorae-Controller configuration communication (I can go into lots of detail into why another time). I very much like the HMAC-signed UDP messages idea though. I now have some feedback for my team, thanks again. Kind Regards -- Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Octavia] Questions about the Octavia project
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.tooh...@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 and...@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
Re: [openstack-dev] [Octavia] Questions about the Octavia project
Hi Andrew, More responses inline: On Wed, Jan 7, 2015 at 12:11 AM, Andrew Hutchings and...@linuxjedi.co.uk wrote: Hi Phillip, Thanks for your response. On 6 Jan 2015, at 20:33, Phillip Toohill phillip.tooh...@rackspace.com wrote: Ill answer inline what I can, others can chime in to clear up anything and answer the rest. The reason I asked the questions I did is because I can’t find any OS the docs will actually compile on and it is difficult to find these answers trawling throw .dot and .rst files. I’ve since found answers for a couple of them. I have several recommendations based on what I have read so far. Such as not using Protobufs instead of JSON for the Amphorae-Controller configuration communication (I can go into lots of detail into why another time). I very much like the HMAC-signed UDP messages idea though. I think we defaulted to JSON because it's a well-understood way of serializing data for use in a RESTful interface. I'm not familiar with protobufs, and am willing to hear you out on reasons we should use it instead of JSON-- but do note that what you're seeing is the result of some hard-won compromises after extensive discussion, and we're *finally* (after several months of this) getting to the point where we can divide-and-conquer on this problem because we're achieving clarity and consensus on what the components should be and how they should interface. We're going to be resistant to changing certain details precisely because we don't want to re-open cans of worms that we're just now getting sealed shut-- so unless you've got some *really* compelling reasons here, we're unlikely to want to change things at this juncture. I now have some feedback for my team, thanks again. Kind Regards -- Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Stephen Balukoff Blue Box Group, LLC (800)613-4305 x807 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Octavia] Questions about the Octavia project
Hi Stephen, Thanks for taking the time to write both responses. On 7 Jan 2015, at 19:27, Stephen Balukoff sbaluk...@bluebox.net wrote: I think we defaulted to JSON because it's a well-understood way of serializing data for use in a RESTful interface. I'm not familiar with protobufs, and am willing to hear you out on reasons we should use it instead of JSON-- but do note that what you're seeing is the result of some hard-won compromises after extensive discussion, and we're *finally* (after several months of this) getting to the point where we can divide-and-conquer on this problem because we're achieving clarity and consensus on what the components should be and how they should interface. We're going to be resistant to changing certain details precisely because we don't want to re-open cans of worms that we're just now getting sealed shut-- so unless you've got some *really* compelling reasons here, we're unlikely to want to change things at this juncture. I’ve pretty much summarised the reasons here at the following URL but I understand the reasons for sticking with JSON: http://linuxjedi.co.uk/posts/2014/Oct/31/why-json-is-bad-for-applications/ Kind Regards -- Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Octavia] Questions about the Octavia project
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 and...@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¹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. 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. 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 4. There is mention of Docker in some of the deploy scripts. Is this for multi-tenancy or just separation of the Amphorae processes? 5. I take it Amphorae is designed to be single-AZ for now? 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 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 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 :) Many thanks for your time. Kind Regards -- Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Octavia] Questions about the Octavia project
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’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? 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? 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 4. There is mention of Docker in some of the deploy scripts. Is this for multi-tenancy or just separation of the Amphorae processes? 5. I take it Amphorae is designed to be single-AZ for now? 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? 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 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 :) Many thanks for your time. Kind Regards -- Andrew Hutchings - LinuxJedi - http://www.linuxjedi.co.uk/ signature.asc Description: Message signed with OpenPGP using GPGMail ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
