Re: [openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax additions/changes
Yair, I am very well plugged-in to this project and feeding the necessary information to the weekly Tempest IRC meeting. In fact, since a few weeks ago, I've made a point of sharing weekly with the Tempest team what I am doing with the LBaaS team from the Tempest point of view. Cheers On Thu, Aug 28, 2014 at 11:31 PM, Brandon Logan wrote: > On Tue, 2014-08-26 at 14:22 +0300, John Schwarz wrote: > > > > On 08/25/2014 10:06 PM, Brandon Logan wrote: > > >> > > >> 2. Therefor, there should be some configuration to specifically enable > > >> either version (not both) in case LBaaS is needed. In this case, the > > >> other version is disabled (ie. a REST query for non-active version > > >> should return a "not activated" error). Additionally, adding a > > >> 'lb-version' command to return the version currently active seems > like a > > >> good user-facing idea. We should see how this doesn't negatively > effect > > >> the db migration process (for example, allowing read-only commands for > > >> both versions?) > > > > > > A /version endpoint can be added for both v1 and v2 extensions and > > > service plugins. If it doesn't already exist, it would be nice if > > > neutron had an endpoint that would return the list of loaded extensions > > > and their versions. > > > > > There is 'neutron ext-list', but I'm not familiar enough with it or with > > the REST API to say if we can use that. > > Looks like this will be sufficient. No new rest endpoint needed. > > > >> > > >> 3. Another decision that's needed to be made is the syntax for v2. As > > >> mentioned, the current new syntax is 'neutron > lbaas--' > > >> (against the old 'lb--'), keeping in mind that once v1 > > >> is deprecated, a syntax like 'lbv2--' would be > probably > > >> unwanted. Is 'lbaas--' okay with everyone? > > > > > > That is the reason we with with lbaas because lbv2 looks ugly and we'd > > > be stuck with it for the lifetime of v2, unless we did another > migration > > > back to lb for it. Which seemed wrong to do, since then we'd have to > > > accept both lbv2 and lb commands, and then deprecate lbv2. > > > > > > I assume this also means you are fine with the prefix in the API > > > resource of /lbaas as well then? > > > > > I don't mind, as long there is a similar mechanism which disables the > > non-active REST API commands. Does anyone disagree? > > >> > > >> 4. If we are going for different API between versions, appropriate > > >> patches also need to be written for lbaas-related scripts and also > > >> Tempest, and their maintainers should probably be notified. > > > > > > Could you elaborate on this? I don't understand what you mean by > > > "different API between version." > > > > > The intention was that the change of the user-facing API also forces > > changes on other levels - not only neutronclient needs to be modified > > accordingly, but also tempest system tests, horizon interface regarding > > LBaaS... > > Oh yes this is in the works. Miguel is spearheading the tempest tests > and has made good progress on it. Horizon integration hasn't begun yet > though. Definitely something we want to get in though. Have to wait > until more information about the incubator comes out and where these > patches for other products need to go. > > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax additions/changes
Hi Yair, On Thu, 2014-08-28 at 07:47 -0400, Yair Fried wrote: > I would like to add a question to John's list > > > > - Original Message - > > From: "John Schwarz" > > To: "OpenStack Development Mailing List (not for usage questions)" > > > > Sent: Tuesday, August 26, 2014 2:22:33 PM > > Subject: Re: [openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax > > additions/changes > > > > > > > > On 08/25/2014 10:06 PM, Brandon Logan wrote: > > >> > > >> 2. Therefor, there should be some configuration to specifically enable > > >> either version (not both) in case LBaaS is needed. In this case, the > > >> other version is disabled (ie. a REST query for non-active version > > >> should return a "not activated" error). Additionally, adding a > > >> 'lb-version' command to return the version currently active seems like a > > >> good user-facing idea. We should see how this doesn't negatively effect > > >> the db migration process (for example, allowing read-only commands for > > >> both versions?) > > > > > > A /version endpoint can be added for both v1 and v2 extensions and > > > service plugins. If it doesn't already exist, it would be nice if > > > neutron had an endpoint that would return the list of loaded extensions > > > and their versions. > > > > > There is 'neutron ext-list', but I'm not familiar enough with it or with > > the REST API to say if we can use that. > > >> > > >> 3. Another decision that's needed to be made is the syntax for v2. As > > >> mentioned, the current new syntax is 'neutron lbaas--' > > >> (against the old 'lb--'), keeping in mind that once v1 > > >> is deprecated, a syntax like 'lbv2--' would be probably > > >> unwanted. Is 'lbaas--' okay with everyone? > > > > > > That is the reason we with with lbaas because lbv2 looks ugly and we'd > > > be stuck with it for the lifetime of v2, unless we did another migration > > > back to lb for it. Which seemed wrong to do, since then we'd have to > > > accept both lbv2 and lb commands, and then deprecate lbv2. > > > > > > I assume this also means you are fine with the prefix in the API > > > resource of /lbaas as well then? > > > > > I don't mind, as long there is a similar mechanism which disables the > > non-active REST API commands. Does anyone disagree? > > >> > > >> 4. If we are going for different API between versions, appropriate > > >> patches also need to be written for lbaas-related scripts and also > > >> Tempest, and their maintainers should probably be notified. > > > > > > Could you elaborate on this? I don't understand what you mean by > > > "different API between version." > > > > > The intention was that the change of the user-facing API also forces > > changes on other levels - not only neutronclient needs to be modified > > accordingly, but also tempest system tests, horizon interface regarding > > LBaaS... > > > 5. If we accept #3 and #4 to mean that the python-client API and CLI must be > changed/updated and so does Tempest clients and tests, then what about other > projects consuming the Neutron API? How are Heat and Ceilometer going to be > affected by this change? That's a good question about Heat and Ceilometer, and honestly it hasn't been discussed. It definitely should be something that should be researched. I think once the incubator dust has settled and we know what goes where, we can dive into this further. Thanks for bringing it up. > > Yair > > > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax additions/changes
On Tue, 2014-08-26 at 14:22 +0300, John Schwarz wrote: > > On 08/25/2014 10:06 PM, Brandon Logan wrote: > >> > >> 2. Therefor, there should be some configuration to specifically enable > >> either version (not both) in case LBaaS is needed. In this case, the > >> other version is disabled (ie. a REST query for non-active version > >> should return a "not activated" error). Additionally, adding a > >> 'lb-version' command to return the version currently active seems like a > >> good user-facing idea. We should see how this doesn't negatively effect > >> the db migration process (for example, allowing read-only commands for > >> both versions?) > > > > A /version endpoint can be added for both v1 and v2 extensions and > > service plugins. If it doesn't already exist, it would be nice if > > neutron had an endpoint that would return the list of loaded extensions > > and their versions. > > > There is 'neutron ext-list', but I'm not familiar enough with it or with > the REST API to say if we can use that. Looks like this will be sufficient. No new rest endpoint needed. > >> > >> 3. Another decision that's needed to be made is the syntax for v2. As > >> mentioned, the current new syntax is 'neutron lbaas--' > >> (against the old 'lb--'), keeping in mind that once v1 > >> is deprecated, a syntax like 'lbv2--' would be probably > >> unwanted. Is 'lbaas--' okay with everyone? > > > > That is the reason we with with lbaas because lbv2 looks ugly and we'd > > be stuck with it for the lifetime of v2, unless we did another migration > > back to lb for it. Which seemed wrong to do, since then we'd have to > > accept both lbv2 and lb commands, and then deprecate lbv2. > > > > I assume this also means you are fine with the prefix in the API > > resource of /lbaas as well then? > > > I don't mind, as long there is a similar mechanism which disables the > non-active REST API commands. Does anyone disagree? > >> > >> 4. If we are going for different API between versions, appropriate > >> patches also need to be written for lbaas-related scripts and also > >> Tempest, and their maintainers should probably be notified. > > > > Could you elaborate on this? I don't understand what you mean by > > "different API between version." > > > The intention was that the change of the user-facing API also forces > changes on other levels - not only neutronclient needs to be modified > accordingly, but also tempest system tests, horizon interface regarding > LBaaS... Oh yes this is in the works. Miguel is spearheading the tempest tests and has made good progress on it. Horizon integration hasn't begun yet though. Definitely something we want to get in though. Have to wait until more information about the incubator comes out and where these patches for other products need to go. > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax additions/changes
I would like to add a question to John's list - Original Message - > From: "John Schwarz" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Tuesday, August 26, 2014 2:22:33 PM > Subject: Re: [openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax > additions/changes > > > > On 08/25/2014 10:06 PM, Brandon Logan wrote: > >> > >> 2. Therefor, there should be some configuration to specifically enable > >> either version (not both) in case LBaaS is needed. In this case, the > >> other version is disabled (ie. a REST query for non-active version > >> should return a "not activated" error). Additionally, adding a > >> 'lb-version' command to return the version currently active seems like a > >> good user-facing idea. We should see how this doesn't negatively effect > >> the db migration process (for example, allowing read-only commands for > >> both versions?) > > > > A /version endpoint can be added for both v1 and v2 extensions and > > service plugins. If it doesn't already exist, it would be nice if > > neutron had an endpoint that would return the list of loaded extensions > > and their versions. > > > There is 'neutron ext-list', but I'm not familiar enough with it or with > the REST API to say if we can use that. > >> > >> 3. Another decision that's needed to be made is the syntax for v2. As > >> mentioned, the current new syntax is 'neutron lbaas--' > >> (against the old 'lb--'), keeping in mind that once v1 > >> is deprecated, a syntax like 'lbv2--' would be probably > >> unwanted. Is 'lbaas--' okay with everyone? > > > > That is the reason we with with lbaas because lbv2 looks ugly and we'd > > be stuck with it for the lifetime of v2, unless we did another migration > > back to lb for it. Which seemed wrong to do, since then we'd have to > > accept both lbv2 and lb commands, and then deprecate lbv2. > > > > I assume this also means you are fine with the prefix in the API > > resource of /lbaas as well then? > > > I don't mind, as long there is a similar mechanism which disables the > non-active REST API commands. Does anyone disagree? > >> > >> 4. If we are going for different API between versions, appropriate > >> patches also need to be written for lbaas-related scripts and also > >> Tempest, and their maintainers should probably be notified. > > > > Could you elaborate on this? I don't understand what you mean by > > "different API between version." > > > The intention was that the change of the user-facing API also forces > changes on other levels - not only neutronclient needs to be modified > accordingly, but also tempest system tests, horizon interface regarding > LBaaS... 5. If we accept #3 and #4 to mean that the python-client API and CLI must be changed/updated and so does Tempest clients and tests, then what about other projects consuming the Neutron API? How are Heat and Ceilometer going to be affected by this change? Yair > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax additions/changes
On 08/25/2014 10:06 PM, Brandon Logan wrote: >> >> 2. Therefor, there should be some configuration to specifically enable >> either version (not both) in case LBaaS is needed. In this case, the >> other version is disabled (ie. a REST query for non-active version >> should return a "not activated" error). Additionally, adding a >> 'lb-version' command to return the version currently active seems like a >> good user-facing idea. We should see how this doesn't negatively effect >> the db migration process (for example, allowing read-only commands for >> both versions?) > > A /version endpoint can be added for both v1 and v2 extensions and > service plugins. If it doesn't already exist, it would be nice if > neutron had an endpoint that would return the list of loaded extensions > and their versions. > There is 'neutron ext-list', but I'm not familiar enough with it or with the REST API to say if we can use that. >> >> 3. Another decision that's needed to be made is the syntax for v2. As >> mentioned, the current new syntax is 'neutron lbaas--' >> (against the old 'lb--'), keeping in mind that once v1 >> is deprecated, a syntax like 'lbv2--' would be probably >> unwanted. Is 'lbaas--' okay with everyone? > > That is the reason we with with lbaas because lbv2 looks ugly and we'd > be stuck with it for the lifetime of v2, unless we did another migration > back to lb for it. Which seemed wrong to do, since then we'd have to > accept both lbv2 and lb commands, and then deprecate lbv2. > > I assume this also means you are fine with the prefix in the API > resource of /lbaas as well then? > I don't mind, as long there is a similar mechanism which disables the non-active REST API commands. Does anyone disagree? >> >> 4. If we are going for different API between versions, appropriate >> patches also need to be written for lbaas-related scripts and also >> Tempest, and their maintainers should probably be notified. > > Could you elaborate on this? I don't understand what you mean by > "different API between version." > The intention was that the change of the user-facing API also forces changes on other levels - not only neutronclient needs to be modified accordingly, but also tempest system tests, horizon interface regarding LBaaS... ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax additions/changes
Hi Clark, >From my understanding the keystone catalog will not contain endpoints for neutron extensions. I could see it being allowed but since Neutron can enable/disable extensions on a whim, there would need to be some cross project communication between keystone and neutron. I'm sure there are other issues that would arise from this too. Then again, I could be wrong and this is already both solved for and allowed in Keystone. Regarding having two separate commands for each version; Since neutron extensions don't have any kind of versioning built it, it would be tough to do through the API at least. The client can make smart decisions though and make it easier for a user. However, if lb-- worked for both v1 and v2, and the user has no idea what Neutron has loaded, I don't see that being a better user experience when they try to do a v1 command when v2 has been loaded. Thanks, Brandon On Sun, 2014-08-24 at 11:50 -0700, Clark Boylan wrote: > On Sun, Aug 24, 2014, at 06:37 AM, John Schwarz wrote: > > Hi, > > > > With the ongoing development of LBaaS v2, support for v2 of LBaaS in > > neutronclient is also being developed, as can be seen in [1]. > > The current implementation adds a new syntax for v2; Whereas the v1 > > syntax is 'neutron lb--', the new v2 syntax is 'neutron > > lbaas--'. > > > > We fear that this can lead to some level of confusion on the users' > > side. Currently, nothing prevents a user from trying to create a v1 pool > > and then trying to add v2 members. Of course the second command will > > fail, but the error message will be a non-intuitive one. > > > > This was discussed at the last weekly IRC meeting ([2]). Some bulletins: > > > > 1. As was discussed in the hackathon, there shouldn't be more than one > > version active at any given time - either v1 or v2. Also, using the same > > syntax for both v1 and v2 is not a good idea (db migration will be > > difficult when both version share syntax). We believe this should also > > be enforced in the server side. > > > > 2. Therefor, there should be some configuration to specifically enable > > either version (not both) in case LBaaS is needed. In this case, the > > other version is disabled (ie. a REST query for non-active version > > should return a "not activated" error). Additionally, adding a > > 'lb-version' command to return the version currently active seems like a > > good user-facing idea. We should see how this doesn't negatively effect > > the db migration process (for example, allowing read-only commands for > > both versions?) > > > > 3. Another decision that's needed to be made is the syntax for v2. As > > mentioned, the current new syntax is 'neutron lbaas--' > > (against the old 'lb--'), keeping in mind that once v1 > > is deprecated, a syntax like 'lbv2--' would be probably > > unwanted. Is 'lbaas--' okay with everyone? > > > > 4. If we are going for different API between versions, appropriate > > patches also need to be written for lbaas-related scripts and also > > Tempest, and their maintainers should probably be notified. > > > > Are there any issues with one of the points raised above? Does anyone > > see any other problems which we forgot to write down? > > > > Thanks a lot, > > > > John Schwarz, Yair Fried, > > Redhat. > > > > [1]: https://review.openstack.org/#/c/111475 > > [2]: > > http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/neutron_lbaas.2014-08-21-14.00.log.html > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > As a user of both the neutron API and python-neutronclient it would be > much better to have the client use a common set of commands for both v1 > and v2 where the specific version used is determined by the keystone > catalog or other overriding information. I don't want to have to > remember two different sets of commands with potentially two different > outputs. Client libraries exist so that users don't have to think about > this stuff. > > This should prevent confusion as users will use a common version unless > they specifically provide an override of some sort. > > Clark > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax additions/changes
Hi John, Comments in-line On Sun, 2014-08-24 at 16:37 +0300, John Schwarz wrote: > Hi, > > With the ongoing development of LBaaS v2, support for v2 of LBaaS in > neutronclient is also being developed, as can be seen in [1]. > The current implementation adds a new syntax for v2; Whereas the v1 > syntax is 'neutron lb--', the new v2 syntax is 'neutron > lbaas--'. > > We fear that this can lead to some level of confusion on the users' > side. Currently, nothing prevents a user from trying to create a v1 pool > and then trying to add v2 members. Of course the second command will > fail, but the error message will be a non-intuitive one. > > This was discussed at the last weekly IRC meeting ([2]). Some bulletins: > > 1. As was discussed in the hackathon, there shouldn't be more than one > version active at any given time - either v1 or v2. Also, using the same > syntax for both v1 and v2 is not a good idea (db migration will be > difficult when both version share syntax). We believe this should also > be enforced in the server side. I actually don't think a real decision was made at the hackathon for this. I know we were originally going to do a shim layer to translate v1 calls into v2 and v2 object model to v1 for v1 driver consumption. I am, however, fine with that rule and it will make things much simpler. There will definitely need to be code in the intiialization of both v1 and v2 plugins that check whether the other version has been initialized, since we cannot guarantee an order in which extensions/service plugins are loaded. This should be trivial to do though. > > 2. Therefor, there should be some configuration to specifically enable > either version (not both) in case LBaaS is needed. In this case, the > other version is disabled (ie. a REST query for non-active version > should return a "not activated" error). Additionally, adding a > 'lb-version' command to return the version currently active seems like a > good user-facing idea. We should see how this doesn't negatively effect > the db migration process (for example, allowing read-only commands for > both versions?) A /version endpoint can be added for both v1 and v2 extensions and service plugins. If it doesn't already exist, it would be nice if neutron had an endpoint that would return the list of loaded extensions and their versions. > > 3. Another decision that's needed to be made is the syntax for v2. As > mentioned, the current new syntax is 'neutron lbaas--' > (against the old 'lb--'), keeping in mind that once v1 > is deprecated, a syntax like 'lbv2--' would be probably > unwanted. Is 'lbaas--' okay with everyone? That is the reason we with with lbaas because lbv2 looks ugly and we'd be stuck with it for the lifetime of v2, unless we did another migration back to lb for it. Which seemed wrong to do, since then we'd have to accept both lbv2 and lb commands, and then deprecate lbv2. I assume this also means you are fine with the prefix in the API resource of /lbaas as well then? > > 4. If we are going for different API between versions, appropriate > patches also need to be written for lbaas-related scripts and also > Tempest, and their maintainers should probably be notified. Could you elaborate on this? I don't understand what you mean by "different API between version." > > Are there any issues with one of the points raised above? Does anyone > see any other problems which we forgot to write down? > > Thanks a lot, > > John Schwarz, Yair Fried, > Redhat. > > [1]: https://review.openstack.org/#/c/111475 > [2]: > http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/neutron_lbaas.2014-08-21-14.00.log.html > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax additions/changes
On Sun, Aug 24, 2014, at 06:37 AM, John Schwarz wrote: > Hi, > > With the ongoing development of LBaaS v2, support for v2 of LBaaS in > neutronclient is also being developed, as can be seen in [1]. > The current implementation adds a new syntax for v2; Whereas the v1 > syntax is 'neutron lb--', the new v2 syntax is 'neutron > lbaas--'. > > We fear that this can lead to some level of confusion on the users' > side. Currently, nothing prevents a user from trying to create a v1 pool > and then trying to add v2 members. Of course the second command will > fail, but the error message will be a non-intuitive one. > > This was discussed at the last weekly IRC meeting ([2]). Some bulletins: > > 1. As was discussed in the hackathon, there shouldn't be more than one > version active at any given time - either v1 or v2. Also, using the same > syntax for both v1 and v2 is not a good idea (db migration will be > difficult when both version share syntax). We believe this should also > be enforced in the server side. > > 2. Therefor, there should be some configuration to specifically enable > either version (not both) in case LBaaS is needed. In this case, the > other version is disabled (ie. a REST query for non-active version > should return a "not activated" error). Additionally, adding a > 'lb-version' command to return the version currently active seems like a > good user-facing idea. We should see how this doesn't negatively effect > the db migration process (for example, allowing read-only commands for > both versions?) > > 3. Another decision that's needed to be made is the syntax for v2. As > mentioned, the current new syntax is 'neutron lbaas--' > (against the old 'lb--'), keeping in mind that once v1 > is deprecated, a syntax like 'lbv2--' would be probably > unwanted. Is 'lbaas--' okay with everyone? > > 4. If we are going for different API between versions, appropriate > patches also need to be written for lbaas-related scripts and also > Tempest, and their maintainers should probably be notified. > > Are there any issues with one of the points raised above? Does anyone > see any other problems which we forgot to write down? > > Thanks a lot, > > John Schwarz, Yair Fried, > Redhat. > > [1]: https://review.openstack.org/#/c/111475 > [2]: > http://eavesdrop.openstack.org/meetings/neutron_lbaas/2014/neutron_lbaas.2014-08-21-14.00.log.html > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev As a user of both the neutron API and python-neutronclient it would be much better to have the client use a common set of commands for both v1 and v2 where the specific version used is determined by the keystone catalog or other overriding information. I don't want to have to remember two different sets of commands with potentially two different outputs. Client libraries exist so that users don't have to think about this stuff. This should prevent confusion as users will use a common version unless they specifically provide an override of some sort. Clark ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
