<div dir="ltr">Hi Sam,<div><br></div><div>So, If I understand you correctly, you don't think that specifying routing rules (eg. static routing configuration) should be beyond the scope of LBaaS?</div><div><br></div><div>
I agree that it might be possible to reach a given member over different routes. The example that comes to mind for me is a member with a public IP on the internet somewhere that's either accessible from the VIP address via the VIP's subnet's default gateway, or via a VPN service available on the same layer 2 network. But if we're going to support choosing routes to a given member, shouldn't this information be located with the member?</div>
<div><br></div><div>I don't know why putting this information as properties of the VIP in the object model would make scheduling and placing the configuration any easier-- specifically, if you've got enough information / completed objects to deploy a load balancing service, wouldn't the service's pools and pool member information also be implicitly available as part of the overall configuration for the service?</div>
<div><br></div><div>Thanks,</div><div>Stephen</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, May 4, 2014 at 12:36 AM, Samuel Bercovici <span dir="ltr"><<a href="mailto:SamuelB@radware.com" target="_blank">SamuelB@radware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div lang="EN-US" link="blue" vlink="purple">
<div>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Hi,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I prefer a different approach (AKA, I oppose
</span><span style="font-size:11.0pt;font-family:Wingdings;color:#1f497d">J</span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">)<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I think that this information should be properties of the VIP and not the pool.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">So VIP should have:<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>1.<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span dir="LTR"></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">VIP subnet (this is where the IP will be allocated)<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span dir="LTR"></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">List of members subnets (it could be optional. This means that members have L2 proximity on the VIP subnet)<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>3.<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span dir="LTR"></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">List of static routes (to be able to specify how to reach members which are not on L2 proximity) – if not presented, this could
be calculated by the “driver” backend but sometimes where you can use multiple different paths a user intervention might be required.
<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">I prefer this approach for the following:<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>1.<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span dir="LTR"></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Concentrating the L3 information in a single place (VIP) – this also makes scheduling and placement of the configuration easier.<u></u><u></u></span></p>
<p><u></u><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><span>2.<span style="font:7.0pt "Times New Roman"">
</span></span></span><u></u><span dir="LTR"></span><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">When using multiple pools (L7 content switching) that have members on the same subnet, no need to repeat the subnet information<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Regards,<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"> -Sam.<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d"><u></u> <u></u></span></p>
<div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> Adam Harwell [mailto:<a href="mailto:adam.harwell@RACKSPACE.COM" target="_blank">adam.harwell@RACKSPACE.COM</a>]
<br>
<b>Sent:</b> Saturday, May 03, 2014 10:17 AM</span></p><div class=""><br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
</div><div><div class="h5"><b>Subject:</b> Re: [openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs Distinction<u></u><u></u></div></div><p></p>
</div>
</div><div><div class="h5">
<p class="MsoNormal"><u></u> <u></u></p>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">Sounds about right to me. I guess I agree with your agreement. :)<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">Does anyone actually
<b>oppose</b> this arrangement?<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">--Adam<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">From:
</span></b><span style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:black">Stephen Balukoff <<a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</a>><br>
<b>Reply-To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<b>Date: </b>Friday, May 2, 2014 7:53 PM<br>
<b>To: </b>"OpenStack Development Mailing List (not for usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<b>Subject: </b>Re: [openstack-dev] [Neutron][LBaaS] Use-Cases with VPNs Distinction<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">Hi guys,
<u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">Yep, so what I'm hearing is that we should be able to assume that either all members in a single pool are adjacent (ie. layer-2 connected), or are routable from
that subnet.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">Adam-- I could see it going either way with regard to how to communicate with members: If the particular device that the provider uses lives outside tenant private
networks, the driver for said devices would need to make sure that VIFs (or some logical equivalent) are added such that the devices can talk to the members. This is also the case for virtual load balancers (or other devices) which are assigned to the tenant
but live on an "external" network. (In this topology, VIP subnet and pool subnet could differ, and the driver needs to make sure that the load balancer has a virtual interface/neutron port + IP address on the pool subnet.)<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">There's also the option that if the "device" being used for load balancing exists as a virtual appliance that can be deployed on an internal network, one can
make it publicly accessible by adding a "neutron floating IP" (ie. static NAT rule) that forwards any traffic destined for a public "external" IP to the load balancer's internal IP address. (In this topology, VIP subnet and pool subnet would be the same thing.)
The nifty thing about this topology is that load balancers that don't have this static NAT rule added are implicitly "private" to the tenant internal subnet.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">Having seen what our customers do with their topologies, my gut reaction is to say that the 99.9% use case is that all the members of a pool will be in the same
subnet, or routable from the pool subnet. And I agree that if someone has a really strange topology in use that doesn't work with this assumption, it's not the job of LBaaS to try and solve this for them.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">Anyway, I'm hearing general agreement that subnet_id should be an attribute of the pool.<u></u><u></u></span></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">On Fri, May 2, 2014 at 5:24 AM, Eugene Nikanorov <<a href="mailto:enikanorov@mirantis.com" target="_blank">enikanorov@mirantis.com</a>> wrote:<u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">Agree with Sam here,
<u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">Moreover, i think it makes sense to leave subnet an attribute of the pool. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">Which would mean that members reside in that subnet or are available (routable) from this subnet, and LB should have a port on this subnet.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">Thanks,<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">Eugene.<u></u><u></u></span></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">On Fri, May 2, 2014 at 3:51 PM, Samuel Bercovici <<a href="mailto:SamuelB@radware.com" target="_blank">SamuelB@radware.com</a>> wrote:<u></u><u></u></span></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">I think that associating a VIP subnet and list of member subnets is a good choice. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">This is declaratively saying to where is the configuration expecting layer 2 proximity. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">The minimal would be the VIP subnet which in essence means the VIP and members are expected on the same subnet. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">Any member outside the specified subnets is supposedly accessible via routing. <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">It might be an option to state the static route to use to access such member(s). <u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">On many cases the needed static routes could also be computed automatically. <br>
<br>
Regards, <u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"> -Sam.<u></u><u></u></span></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><br>
On 2 </span><span lang="HE" dir="RTL" style="font-size:10.5pt;color:black">במאי 2014</span><span dir="LTR"></span><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><span dir="LTR"></span>, at 03:50, "Stephen Balukoff" <<a href="mailto:sbalukoff@bluebox.net" target="_blank">sbalukoff@bluebox.net</a>>
wrote:<u></u><u></u></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">Hi Trevor,
<u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">I was the one who wrote that use case based on discussion that came out of the question I wrote the list last week about SSL re-encryption: Someone had stated
that sometimes pool members are local, and sometimes they are hosts across the internet, accessible either through the usual default route, or via a VPN tunnel.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">The point of this use case is to make the distinction that if we associate a neutron_subnet with the pool (rather than with the member), then some members of
the pool that don't exist in that neutron_subnet might not be accessible from that neutron_subnet. However, if the behavior of the system is such that attempting to reach a host through the subnet's "default route" still works (whether that leads to communication
over a VPN or the usual internet routes), then this might not be a problem.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">The other option is to associate the neutron_subnet with a pool member. But in this case there might be problems too. Namely:<u></u><u></u></span></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal" style="color:black">
<span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">The device or software that does the load balancing may need to have an interface on each of the member subnets, and presumably an IP address from which to originate requests.<u></u><u></u></span></li>
<li class="MsoNormal" style="color:black">
<span style="font-size:10.5pt;font-family:"Calibri","sans-serif"">How does one resolve cases where subnets have overlapping IP ranges?<u></u><u></u></span></li></ul>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">In the end, it may be simpler not to associate neutron_subnet with a pool at all. Maybe it only makes sense to do this for a VIP, and then the assumption would
be that any member addresses one adds to pools must be accessible from the VIP subnet. (Which is easy, if the VIP exists on the same neutron_subnet. But this might require special routing within Neutron itself if it doesn't.)<u></u><u></u></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">This topology question (ie. what is feasible, what do people actually want to do, and what is supported by the model) is one of the more difficult ones to answer,
especially given that users of OpenStack that I've come in contact with barely understand the Neutron networking model, if at all.<u></u><u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">In our case, we don't actually have any users in the scenario of having members spread across different subnets that might not be be routable, so the use case
is somewhat contrived, but I thought it was worth mentioning based on what people were saying in the SSL re-encryption discussion last week.<u></u><u></u></span></p>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">On Thu, May 1, 2014 at 1:52 PM, Trevor Vardeman <<a href="mailto:trevor.vardeman@rackspace.com" target="_blank">trevor.vardeman@rackspace.com</a>> wrote:<u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">Hello,<br>
<br>
After going back through the use-cases to double check some of my<br>
understanding, I realized I didn't quite understand the ones I had<br>
already answered. I'll use a specific use-case as an example of my<br>
misunderstanding here, and hopefully the clarification can be easily<br>
adapted to the rest of the use-cases that are similar.<br>
<br>
Use Case 13: A project-user has an HTTPS application in which some of<br>
the back-end servers serving this application are in the same subnet,<br>
and others are across the internet, accessible via VPN. He wants this<br>
HTTPS application to be available to web clients via a single IP<br>
address.<br>
<br>
In this use-case, is the Load Balancer going to act as a node in the<br>
VPN? What I mean here, is the Load Balancer supposed to establish a<br>
connection to this VPN for the client, and simulate itself as a computer<br>
on the VPN? If this is not the case, wouldn't the VPN have a subnet ID,<br>
and simply be added to a pool during its creation? If the latter is<br>
accurate, would this not just be a basic HTTPS Load Balancer creation?<br>
After looking through the VPNaaS API, you would provide a subnet ID to<br>
the create VPN service request, and it establishes a VPN on said subnet.<br>
Couldn't this be provided to the Load Balancer pool as its subnet?<br>
<br>
Forgive me for requiring so much distinction here, but what may be clear<br>
to the creator of this use-case, it has left me confused. This same<br>
type of clarity would be very helpful across many of the other<br>
VPN-related use-cases. Thanks again!<br>
<br>
-Trevor<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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><u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><br>
<br clear="all">
<u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">--
<br>
Stephen Balukoff <br>
Blue Box Group, LLC <br>
<a href="tel:%28800%29613-4305%20x807" target="_blank">(800)613-4305 x807</a><u></u><u></u></span></p>
</div>
</div>
</blockquote>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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><u></u><u></u></span></p>
</div>
</blockquote>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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><u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
</div>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">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><u></u><u></u></span></p>
</div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><br>
<br clear="all">
<u></u><u></u></span></p>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black"><u></u> <u></u></span></p>
</div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:"Calibri","sans-serif";color:black">--
<br>
Stephen Balukoff <br>
Blue Box Group, LLC <br>
<a href="tel:%28800%29613-4305%20x807" value="+18006134305" target="_blank">(800)613-4305 x807</a> <u></u><u></u></span></p>
</div>
</div>
</div>
</div></div></div>
</div>
<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>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><span></span>Stephen Balukoff
<br>Blue Box Group, LLC
<br>(800)613-4305 x807
</div>