Re: [openstack-dev] [Neutron] [LBaaS] LBaaS v2 API syntax additions/changes

2014-08-29 Thread Miguel Lavalle
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 brandon.lo...@rackspace.com
 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-object-command'
   (against the old 'lb-object-action'), keeping in mind that once v1
   is deprecated, a syntax like 'lbv2-object-action' would be
 probably
   unwanted. Is 'lbaas-object-command' 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

2014-08-28 Thread Yair Fried
I would like to add a question to John's list



- Original Message -
 From: John Schwarz jschw...@redhat.com
 To: OpenStack Development Mailing List (not for usage questions) 
 openstack-dev@lists.openstack.org
 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-object-command'
  (against the old 'lb-object-action'), keeping in mind that once v1
  is deprecated, a syntax like 'lbv2-object-action' would be probably
  unwanted. Is 'lbaas-object-command' 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

2014-08-28 Thread Brandon Logan
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-object-command'
  (against the old 'lb-object-action'), keeping in mind that once v1
  is deprecated, a syntax like 'lbv2-object-action' would be probably
  unwanted. Is 'lbaas-object-command' 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

2014-08-28 Thread Brandon Logan
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 jschw...@redhat.com
  To: OpenStack Development Mailing List (not for usage questions) 
  openstack-dev@lists.openstack.org
  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-object-command'
   (against the old 'lb-object-action'), keeping in mind that once v1
   is deprecated, a syntax like 'lbv2-object-action' would be probably
   unwanted. Is 'lbaas-object-command' 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

2014-08-26 Thread John Schwarz


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-object-command'
 (against the old 'lb-object-action'), keeping in mind that once v1
 is deprecated, a syntax like 'lbv2-object-action' would be probably
 unwanted. Is 'lbaas-object-command' 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

2014-08-25 Thread Brandon Logan
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-object-command', the new v2 syntax is 'neutron
 lbaas-object-command'.
 
 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-object-command'
 (against the old 'lb-object-action'), keeping in mind that once v1
 is deprecated, a syntax like 'lbv2-object-action' would be probably
 unwanted. Is 'lbaas-object-command' 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

2014-08-25 Thread Brandon Logan
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-object-action
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-object-command', the new v2 syntax is 'neutron
  lbaas-object-command'.
  
  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-object-command'
  (against the old 'lb-object-action'), keeping in mind that once v1
  is deprecated, a syntax like 'lbv2-object-action' would be probably
  unwanted. Is 'lbaas-object-command' 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

2014-08-24 Thread Clark Boylan
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-object-command', the new v2 syntax is 'neutron
 lbaas-object-command'.
 
 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-object-command'
 (against the old 'lb-object-action'), keeping in mind that once v1
 is deprecated, a syntax like 'lbv2-object-action' would be probably
 unwanted. Is 'lbaas-object-command' 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