<div dir="ltr">Hi Evgeny,<div><br></div><div>Is there any reason we wouldn't want a better name for the class? Why not simply SNIList or SNIPolicy? Or maybe something more descriptive of its contents like SNICertificate. I don't think there's a need to mention the listener in the class name since there is no other object in this model to which it makes sense to attach an SNI certificate.</div>
<div><br></div><div>Is there a naming convention for referencing objects which are outside of the current software's code base entirely (as the barbican containers are)?</div><div><br></div><div>Anyway, this is mostly nit-picking at this point. I hate the name, but I don't want to delay development of this feature over this.</div>
<div><br></div><div>Stephen</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jun 26, 2014 at 3:44 AM, Evgeny Fedoruk <span dir="ltr"><<a href="mailto:EvgenyF@radware.com" target="_blank">EvgenyF@radware.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi guys,<br>
<br>
Stephen, I understand your concerns regarding misleading names.<br>
Here are my thoughts:<br>
default_tls_container_id<br>
This name is the same for API and database model and I think this name explains its meaning well.<br>
sni_container_ids(for API) and listenersniassociations (for database table)<br>
These two comes to specify the same thing - TLS container ids list for listener's SNI function,<br>
Still there is a difference: in API it's just a list of IDs contained in listener's API call,<br>
while in database it becomes to specify association between listener ID and TLS container ID in separate database table.<br>
As Brandon posted, database table names in Neutron are derived from data model class names defining them.<br>
Listenersniassociations table name is actually comes from ListenerSNIAssociation class that defines the table.<br>
I understand there is no table for SNI object in neutron schema but I did not think of a better name for this association table name.<br>
It could be named ListenerContainerAssociation but this name does not clarify that this is for SNI and there is no Containers table in Neutron's schema neither)<br>
Calling it ListenerSNIContainerAssociation may be too long..<br>
<br>
These are my thoughts but I may miss something, please propose alternative names you think of<br>
<br>
Thanks,<br>
Evg<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
-----Original Message-----<br>
From: Brandon Logan [mailto:<a href="mailto:brandon.logan@RACKSPACE.COM">brandon.logan@RACKSPACE.COM</a>]<br>
Sent: Wednesday, June 25, 2014 11:00 PM<br>
To: <a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a><br>
Subject: Re: [openstack-dev] [Neutron][LBaaS] Should TLS settings for listener be set through separate API/model?<br>
<br>
Hi Stephen,<br>
<br>
The <entity><entity>associations table name is consistent with the rest of neutron's table names, as is not breaking the table name words up by an underscore. I think this stems from the sqlalchemy models getting the table name for free because of inheriting from a base model that derives the table name based on the model's class name.<br>
<br>
However, with markmcclain's blessing the new loadbalancing tables will be prefixed with lbaas_, but the model names will be LoadBalancer, Listener, etc.<br>
<br>
I would agree though that since sni will not be a separate table then that will be a bit odd to have an association table's name implying a join of a table that doesn't exist.<br>
<br>
Thanks,<br>
Brandon<br>
<br>
On Wed, 2014-06-25 at 09:55 -0700, Stephen Balukoff wrote:<br>
> What's the point of putting off a potential name change to the actual<br>
> code (where you're going to see more friction because names in the<br>
> code do not match names in the spec, and this becomes a point where<br>
> confusion can happen). I understand the idea that code may not exactly<br>
> match the spec, but when it's obvious that it should, why use the<br>
> wrong name in the spec?<br>
><br>
><br>
> Isn't it more confusing when the API does not match database object<br>
> names when it's clear the API is specifically meant to manipulate<br>
> those database objects?<br>
><br>
><br>
> Is that naming convention actually documented anywhere? And why are<br>
> you calling it a 'listenersniassociations'? There is no "SNI" object<br>
> in the database. (IMO, this is a terrible name that needs to be<br>
> re-read three times just to pick out where the word breaks should be!<br>
> As written it looks like "Listeners NI Associations" what the heck is<br>
> an 'NI'?)<br>
><br>
><br>
> They say that there are two hard problems in Computer Science:<br>
> * Cache invalidation<br>
> * Naming things<br>
> * Off-by-one errors<br>
><br>
><br>
> And far be it from me to pick nits about a name (OK, I guess it's<br>
> isn't that far fetched for me to pick nits. :P ), but it's hard for me<br>
> to imagine a worse name than 'listenersniassocaitions' being<br>
> considered. :P<br>
><br>
><br>
> Stephen<br>
><br>
><br>
><br>
><br>
> On Wed, Jun 25, 2014 at 2:05 AM, Evgeny Fedoruk <<a href="mailto:EvgenyF@radware.com">EvgenyF@radware.com</a>><br>
> wrote:<br>
> Hi folks<br>
><br>
><br>
><br>
> Regarding names, there are two types of them: new API<br>
> attributes for REST call, and new column name and table name<br>
> for the database.<br>
><br>
> When creating listener, 2 new attributes will be added to the<br>
> REST call API:<br>
><br>
> 1. default_tls_container_id - Barbican TLS container uuid<br>
><br>
> 2. sni_container_ids (I removed the “_list” part to make<br>
> it shorter) – ordered list of Barbican TLS container uuids<br>
><br>
> For the database, these will be translated to:<br>
><br>
> 1. default_tls_container_id- new column for listeners<br>
> table<br>
><br>
> 2. listenersniassociations (changed it from<br>
> vipsniassociations which is a mistake) – new associations<br>
> table, holding: id(generated), listener_id, TLS_container_id,<br>
> and position(for ordering)<br>
><br>
> This kind of a name comes to comply current neutron’s table<br>
> name convention, like pollmonitorassociation or<br>
> providerresourceassociation<br>
><br>
><br>
><br>
> I think names may always be an issue for the actual code<br>
> review, the document is just a functional specification<br>
><br>
> Since new objects model code is not landed yet, naming<br>
> conventions may be changed while implementing this spec.<br>
><br>
> I will commit the document with all comments addressed and<br>
> mentioned above names.<br>
><br>
> Please review it and give your feedback, I think we are close<br>
> to complete this one )<br>
><br>
><br>
><br>
> Thanks,<br>
><br>
> Evg<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> From: Vijay Venkatachalam<br>
> [mailto:<a href="mailto:Vijay.Venkatachalam@citrix.com">Vijay.Venkatachalam@citrix.com</a>]<br>
> Sent: Wednesday, June 25, 2014 8:34 AM<br>
><br>
><br>
> To: OpenStack Development Mailing List (not for usage<br>
> questions)<br>
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Should TLS<br>
> settings for listener be set through separate API/model?<br>
><br>
><br>
> Thanks for the details Evg!<br>
><br>
><br>
><br>
> I understand there was no TLS settings API originally planned.<br>
><br>
><br>
><br>
> From: Stephen Balukoff [mailto:<a href="mailto:sbalukoff@bluebox.net">sbalukoff@bluebox.net</a>]<br>
> Sent: Wednesday, June 25, 2014 5:46 AM<br>
> To: OpenStack Development Mailing List (not for usage<br>
> questions)<br>
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Should TLS<br>
> settings for listener be set through separate API/model?<br>
><br>
><br>
><br>
><br>
> Evgeny--<br>
><br>
><br>
><br>
><br>
> Two minor nits:<br>
><br>
><br>
><br>
><br>
><br>
> * Your spec lists the new SNI related settings 'sni_list' (and<br>
> it contains more than just IDs, so calling it<br>
> 'sni_container_ids_list' is misleading). Please be precise in<br>
> the terms you use, and don't switch them mid discussion. :)<br>
><br>
><br>
> * Also, I personally really hate long table names when they're<br>
> unnecessary. "vipsniassociations" isn't mentioned in your spec<br>
> anywhere, and frankly, is a lot worse than "sni_list." I<br>
> personally prefer "SNIPolicies", but I'm also OK with a short<br>
> name like "sni_list".<br>
><br>
><br>
><br>
><br>
><br>
> Otherwise I agree with you on all points.<br>
><br>
><br>
><br>
><br>
><br>
> Stephen<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Tue, Jun 24, 2014 at 3:26 AM, Evgeny Fedoruk<br>
> <<a href="mailto:EvgenyF@radware.com">EvgenyF@radware.com</a>> wrote:<br>
><br>
> Vijay, there is no intension for a new TLS settings<br>
> API.<br>
><br>
> Creation of a listener with TLS offloading will be<br>
> one-step.<br>
><br>
><br>
><br>
> When tenant creates listener with TERMINATED-HTTPS<br>
> protocol he must supply default_tls_container_id for<br>
> offloading.<br>
><br>
> Not supplying default TLS container id for offloading<br>
> for TERMINATED-HTTPS listener will raise an error.<br>
><br>
> SNI list may or may not be supplied by the tenant.<br>
> Default value for SNI certificates list is an empty<br>
> list.<br>
><br>
><br>
><br>
> So listener resource will have another two attributes:<br>
> default_tls_container_id and sni_container_ids_list.<br>
> These are relevant for TERMINATED-HTTPS protocol<br>
> listeners only. In other cases its default value are<br>
> ‘None’ and empty list.<br>
><br>
> In schema, Default_tls_container_id will be added to<br>
> listener object as another column.<br>
><br>
> Sni_container_ids_list wil be managed by new table<br>
> “vipsniassociations” which has listener_id,<br>
> container_id, and position (for ordering) columns<br>
><br>
><br>
><br>
> Does it make sense?<br>
><br>
><br>
><br>
> Thanks,<br>
><br>
> Evg<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> From: Vijay Venkatachalam<br>
> [mailto:<a href="mailto:Vijay.Venkatachalam@citrix.com">Vijay.Venkatachalam@citrix.com</a>]<br>
> Sent: Tuesday, June 24, 2014 12:31 PM<br>
><br>
><br>
> To: OpenStack Development Mailing List (not for usage<br>
> questions)<br>
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Should<br>
> TLS settings for listener be set through separate<br>
> API/model?<br>
><br>
><br>
><br>
><br>
><br>
><br>
> To clarify, the request is for a new TLS settings API<br>
> with “default_tls_container_id” & “sni_list”.<br>
><br>
><br>
><br>
> If there is a new API, then we would have an object<br>
> model reflecting this as a separate entity.<br>
><br>
><br>
><br>
> The tenant would do the following<br>
><br>
><br>
><br>
> 1. Create a listener with TERMINATED_HTTPS<br>
><br>
> 2. Set the TLS settings for the listener<br>
> using /v2.0/listener/<listenerid>/tlssettings (if at<br>
> all we are having some default values this can be<br>
> reflected here)<br>
><br>
><br>
><br>
> The only good thing is the separation of the TLS<br>
> settings out of the listener API.<br>
><br>
><br>
><br>
> But, I can see 2 downsides<br>
><br>
> 1. The loadbalancer creation is a 2 step<br>
> procedure<br>
><br>
> 2. We cannot enforce certificate attachment as<br>
> part of the create of listener.<br>
><br>
><br>
><br>
> If the new API itself has “-1”s then I am perfectly OK<br>
> with the current object model with<br>
> default_tls_container_id in listener table.<br>
><br>
><br>
><br>
> Thanks,<br>
><br>
> Vijay V.<br>
><br>
><br>
><br>
><br>
><br>
> From: Evgeny Fedoruk [mailto:<a href="mailto:EvgenyF@Radware.com">EvgenyF@Radware.com</a>]<br>
> Sent: Tuesday, June 24, 2014 2:19 PM<br>
> To: OpenStack Development Mailing List (not for usage<br>
> questions)<br>
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Should<br>
> TLS settings for listener be set through separate<br>
> API/model?<br>
><br>
><br>
><br>
><br>
> Vipsniassociations table:Line 147 in last patch of the<br>
> document<br>
><br>
><br>
><br>
> From: Vijay Venkatachalam<br>
> [mailto:<a href="mailto:Vijay.Venkatachalam@citrix.com">Vijay.Venkatachalam@citrix.com</a>]<br>
> Sent: Tuesday, June 24, 2014 10:17 AM<br>
> To: OpenStack Development Mailing List (not for usage<br>
> questions)<br>
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Should<br>
> TLS settings for listener be set through separate<br>
> API/model?<br>
><br>
><br>
><br>
><br>
><br>
><br>
> >>SNI list is managed by separate entity<br>
><br>
> What is this entity?<br>
><br>
><br>
><br>
> From: Evgeny Fedoruk [mailto:<a href="mailto:EvgenyF@Radware.com">EvgenyF@Radware.com</a>]<br>
> Sent: Tuesday, June 24, 2014 12:25 PM<br>
> To: OpenStack Development Mailing List (not for usage<br>
> questions)<br>
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Should<br>
> TLS settings for listener be set through separate<br>
> API/model?<br>
><br>
><br>
><br>
><br>
> +1 for option 1. SNI list is managed by separate<br>
> entity, default TLS container is part of a listener<br>
> object. It will have None value when listener does not<br>
> offloads TLS.<br>
><br>
> Managing another entity for 1:0-1 relationship just<br>
> for future use seems not right to me. Breaking TLS<br>
> settings apart from listener can be done when needed,<br>
> if needed.<br>
><br>
><br>
><br>
> Thanks,<br>
><br>
> Evg<br>
><br>
><br>
><br>
><br>
><br>
> From: Stephen Balukoff [mailto:<a href="mailto:sbalukoff@bluebox.net">sbalukoff@bluebox.net</a>]<br>
> Sent: Tuesday, June 24, 2014 4:26 AM<br>
> To: OpenStack Development Mailing List (not for usage<br>
> questions)<br>
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Should<br>
> TLS settings for listener be set through separate<br>
> API/model?<br>
><br>
><br>
><br>
> Ok, so we've got opinions on both sides of the<br>
> argument here. I'm actually pretty ambivalent about<br>
> it. Do others have strong opinions on this?<br>
><br>
><br>
><br>
><br>
> On Mon, Jun 23, 2014 at 6:03 PM, Doug Wiegley<br>
> <<a href="mailto:dougw@a10networks.com">dougw@a10networks.com</a>> wrote:<br>
><br>
> Put me down for being in favor of option 1.<br>
><br>
><br>
><br>
><br>
><br>
> A single attribute in a 1:1 relationship? Putting<br>
> that in a new table sounds like premature optimization<br>
> to me; design the database change for the future<br>
> feature when you can see the spec for it.<br>
><br>
><br>
><br>
><br>
><br>
> Thanks,<br>
><br>
><br>
> Doug<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> From:Stephen Balukoff <<a href="mailto:sbalukoff@bluebox.net">sbalukoff@bluebox.net</a>><br>
> Reply-To: "OpenStack Development Mailing List (not for<br>
> usage questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> Date: Monday, June 23, 2014 at 5:25 PM<br>
> To: "OpenStack Development Mailing List (not for usage<br>
> questions)" <<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
> Subject: Re: [openstack-dev] [Neutron][LBaaS] Should<br>
> TLS settings for listener be set through separate<br>
> API/model?<br>
><br>
><br>
><br>
><br>
><br>
> Also to add to pros for 2:<br>
><br>
><br>
><br>
><br>
> * Keeping the TLS stuff contained to its own objects<br>
> means we can have separate development resources on<br>
> each and not worry as much about overlapping domains.<br>
> (TLS-related knowledge and knowledge of dealing with<br>
> TCP / UDP listeners are separate knowledge domains. Or<br>
> at least, the former is a more specialized subset of<br>
> the latter.)<br>
><br>
><br>
><br>
><br>
><br>
> Note that what we're proposing means there's<br>
> essentially a 1:0-1 relationship between Listener and<br>
> this new yet-to-be-named object. (0 in case the<br>
> Listener is not terminating TLS.)<br>
><br>
><br>
><br>
><br>
><br>
> Stephen<br>
><br>
><br>
><br>
><br>
> On Mon, Jun 23, 2014 at 3:38 PM, Brandon Logan<br>
> <<a href="mailto:brandon.logan@rackspace.com">brandon.logan@rackspace.com</a>> wrote:<br>
><br>
> Whoops, [Neutron][LBaaS] got taken out of the subject<br>
> line here.<br>
> Putting it back in.<br>
><br>
><br>
> On Mon, 2014-06-23 at 21:10 +0000, Brandon Logan<br>
> wrote:<br>
> > Okay so we've talked a bit about this in IRC and now<br>
> I'm sending this<br>
> > out as an update. Here are the options with pros<br>
> and cons that have<br>
> > come from that discussion.<br>
> ><br>
> > 1) default_certificate_id is an attribute of the<br>
> Listener object.<br>
> ><br>
> > Pros:<br>
> > -No extra entity needed<br>
> ><br>
> > Cons:<br>
> > -May bloat Listener object when more attributes are<br>
> needed for only TLS<br>
> > termination. Sounds like TLS version and cipher<br>
> selection will be<br>
> > needed attributes in the future.<br>
> ><br>
> ><br>
> > 2) A separate TLS Entity is created that is<br>
> referenced by the Listener<br>
> > object. This entity at first may only contain a<br>
> certificate_id that<br>
> > references barbican. Name and description can be<br>
> allowed as well.<br>
> ><br>
> > Pros:<br>
> > -TLS domain specific attributes contained in its own<br>
> entity<br>
> > -Future attributes would just be added to this<br>
> entity and not bloat the<br>
> > Listener object.<br>
> ><br>
> > Cons:<br>
> > -It's another entity<br>
> ><br>
> > In IRC we (sbalukoff, myself) seemed to agree option<br>
> 2 is right way to<br>
> > go. Anyone agree or disagree?<br>
> ><br>
> > Thanks,<br>
> > Brandon<br>
> ><br>
> > On Mon, 2014-06-23 at 12:15 -0700, Stephen Balukoff<br>
> wrote:<br>
> > > The separate entity makes sense for certificates<br>
> participating in an<br>
> > > SNI configuration, but probably not so much for<br>
> the 'default'<br>
> > > certificate used when TLS is being terminated.<br>
> > ><br>
> > ><br>
> > > Vijay: You're also right that other TLS-related<br>
> attributes will<br>
> > > probably get added to the Listener object. This<br>
> probably makes sense<br>
> > > if they apply to the Listener object as a whole.<br>
> (This includes things<br>
> > > like TLS version and cipher selection.)<br>
> > ><br>
> > ><br>
> > > I don't see much of a point in creating a separate<br>
> object to contain<br>
> > > these fields, since it would have a 1:1<br>
> relationship with the<br>
> > > Listener. It's true that for non-TLS-terminated<br>
> Listeners, these<br>
> > > fields wouldn't be used, but isn't that already<br>
> the case in many other<br>
> > > objects (not just in the Neutron LBaaS sub<br>
> project)?<br>
> > ><br>
> > ><br>
> > > Thanks,<br>
> > > Stephen<br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > ><br>
> > > On Mon, Jun 23, 2014 at 9:54 AM, Brandon Logan<br>
> > > <<a href="mailto:brandon.logan@rackspace.com">brandon.logan@rackspace.com</a>> wrote:<br>
> > > Vijay,<br>
> > > I think the separate entity is still going<br>
> to happen. I don't<br>
> > > think it<br>
> > > has remvoed. Or that is may just be my<br>
> assumption.<br>
> > ><br>
> > > Thanks,<br>
> > > Brandon<br>
> > ><br>
> > > On Mon, 2014-06-23 at 15:59 +0000, Vijay<br>
> Venkatachalam wrote:<br>
> > > > Hi:<br>
> > > ><br>
> > > ><br>
> > > > In the “LBaaS TLS termination capability<br>
> specification”<br>
> > > proposal<br>
> > > ><br>
> > > > <a href="https://review.openstack.org/#/c/98640/" target="_blank">https://review.openstack.org/#/c/98640/</a><br>
> > > ><br>
> > > > TLS settings like default certificate<br>
> container id and SNI<br>
> > > cert list are part of the listener<br>
> properties.<br>
> > > ><br>
> > > > I think it is better to have this as a<br>
> separate entity so<br>
> > > that the listener properties are clean and<br>
> is not “corrupted”<br>
> > > with TLS settings.<br>
> > > ><br>
> > > > I liked the original SSL proposal better<br>
> where TLS settings<br>
> > > was a separate entity.<br>
> > > ><br>
> > > > It is just 2 properties now but in<br>
> future the TLS settings<br>
> > > would grow and if we are going to<br>
> introduce a TLS<br>
> > > profile/params/settings entity later, it<br>
> is better to do it<br>
> > > now (albeit with min properties).<br>
> > > ><br>
> > > > Thanks,<br>
> > > > Vijay V.<br>
> > ><br>
> > > ><br>
> _______________________________________________<br>
> > > > OpenStack-dev mailing list<br>
> > > > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > > ><br>
> > ><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>
> > ><br>
> _______________________________________________<br>
> > > OpenStack-dev mailing list<br>
> > > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > ><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>
> > ><br>
> > ><br>
> > ><br>
> > > --<br>
> > > Stephen Balukoff<br>
> > > Blue Box Group, LLC<br>
> > > <a href="tel:%28800%29613-4305%20x807" value="+18006134305">(800)613-4305 x807</a><br>
> > > _______________________________________________<br>
> > > OpenStack-dev mailing list<br>
> > > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> > ><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>
> > _______________________________________________<br>
> > OpenStack-dev mailing list<br>
> > <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> ><br>
><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>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
><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>
><br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> Stephen Balukoff<br>
> Blue Box Group, LLC<br>
> <a href="tel:%28800%29613-4305%20x807" value="+18006134305">(800)613-4305 x807</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
><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>
><br>
><br>
><br>
><br>
><br>
><br>
> --<br>
> Stephen Balukoff<br>
> Blue Box Group, LLC<br>
> <a href="tel:%28800%29613-4305%20x807" value="+18006134305">(800)613-4305 x807</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
><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>
><br>
><br>
><br>
><br>
><br>
> --<br>
> Stephen Balukoff<br>
> Blue Box Group, LLC<br>
> <a href="tel:%28800%29613-4305%20x807" value="+18006134305">(800)613-4305 x807</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
><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>
><br>
><br>
><br>
><br>
> --<br>
> Stephen Balukoff<br>
> Blue Box Group, LLC<br>
> <a href="tel:%28800%29613-4305%20x807" value="+18006134305">(800)613-4305 x807</a><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>
_______________________________________________<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>
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>
</div></div></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>