Re: [openstack-dev] [cinder][stable] Cinder client broken in Juno
On 08:49 Jun 23, Mike Perez wrote: There was a bug raised [1] from some large deployments that the Cinder client 1.2.0 and beyond is not working because of version discovery. Unfortunately it's not taking into account of deployments that have a proxy. Cinder client asks Keystone to find a publicURL based on a version. Keystone will gather data from the service catalog and ask Cinder for a list of the public endpoints and compare. For the proxy cases, Cinder is giving internal URLs back to the proxy and Keystone ends up using that instead of the publicURL in the service catalog. As a result, clients usually won't be able to use the internal URL and rightfully so. This is all correctly setup on the deployer's side, this an issue with the server side code of Cinder. There is a patch that allows the deployer to specify a configuration option public_endpoint [2] which was introduced in a patch in Kilo [3]. The problem though is we can't expect people to already be running Kilo to take advantage of this, and it leaves deployers running stable releases of Juno in the dark with clients upgrading and using the latest. Two options: 1) Revert version discovery which was introduced in Kilo for Cinder client. 2) Grant exception on backporting [4] a patch that helps with this problem, and introduces a config option that does not change default behavior. I'm also not sure if this should be considered for Icehouse. As decided, we went with option 1 and reverted version discovery in 1.3.1 of python-cinderclient for now. -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder][stable] Cinder client broken in Juno
On Mon, Jun 29, 2015 at 11:58 PM, Duncan Thomas duncan.tho...@gmail.com wrote: We already have an environment variable for version... 'auto'? On 30 Jun 2015 07:57, John Griffith john.griffi...@gmail.com wrote: On Mon, Jun 29, 2015 at 8:54 PM, Jay Bryant jsbry...@electronicjungle.net wrote: I too would prefer option 2. Would rather do the pack ports than remove the functionality. Jay On Wed, Jun 24, 2015 at 9:40 AM Gorka Eguileor gegui...@redhat.com wrote: On Tue, Jun 23, 2015 at 08:49:55AM -0700, Mike Perez wrote: There was a bug raised [1] from some large deployments that the Cinder client 1.2.0 and beyond is not working because of version discovery. Unfortunately it's not taking into account of deployments that have a proxy. A little bit unrelated, but volume pagination in Cinder client is also broken due to Version Discovery: https://bugs.launchpad.net/python-cinderclient/+bug/1453755 Cinder client asks Keystone to find a publicURL based on a version. Keystone will gather data from the service catalog and ask Cinder for a list of the public endpoints and compare. For the proxy cases, Cinder is giving internal URLs back to the proxy and Keystone ends up using that instead of the publicURL in the service catalog. As a result, clients usually won't be able to use the internal URL and rightfully so. This is all correctly setup on the deployer's side, this an issue with the server side code of Cinder. There is a patch that allows the deployer to specify a configuration option public_endpoint [2] which was introduced in a patch in Kilo [3]. The problem though is we can't expect people to already be running Kilo to take advantage of this, and it leaves deployers running stable releases of Juno in the dark with clients upgrading and using the latest. Two options: 1) Revert version discovery which was introduced in Kilo for Cinder client. 2) Grant exception on backporting [4] a patch that helps with this problem, and introduces a config option that does not change default behavior. I'm also not sure if this should be considered for Icehouse. +1 to option 2 and I wouldn't be totally against considering it for Icehouse. Cheers, Gorka. [1] - https://launchpad.net/bugs/1464160 [2] - http://docs.openstack.org/kilo/config-reference/content/cinder-conf-changes-kilo.html [3] - https://review.openstack.org/#/c/159374/ [4] - https://review.openstack.org/#/c/194719/ -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I'll echo Jeremy and Dave's statements regarding compatibility, seems really pretty lame that this can't work. If it's not possible to support both scenarios in the client in a reasonable manner without long timeout periods my vote is for a revert and new client version. Sorry, but in my opinion backports to Cinder itself don't cut it in this case. It's unfortunate we got to this point. Why can't we make this a config option in cinderclient itself? Like USE_AUTO_DISCOVERY=True|False with a default of False in the client and just deal with it or as others have asked can't we make all of this smarter? I mean it's sort of odd to have a discovery option that only works with 'new' versions of the API doesn't it? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev On Mon, Jun 29, 2015 at 11:58 PM, Duncan Thomas duncan.tho...@gmail.com wrote: We already have an environment variable for version... 'auto'? Which doesn't work unless you're on current Cinder version, which is what I thought the whole point of this thread was all about. I'm proposing we actually make sure
Re: [openstack-dev] [cinder][stable] Cinder client broken in Juno
Sorry, I don't think I was entirely clear with my proposal - I meant that we release a new current that will default to the old behavior, but allow the new behavior to be tested by explicitly choosing the value 'auto'. This allows people to test their config with version discovery, without breaking normal usage. On 30 Jun 2015 19:28, John Griffith john.griffi...@gmail.com wrote: On Mon, Jun 29, 2015 at 11:58 PM, Duncan Thomas duncan.tho...@gmail.com wrote: We already have an environment variable for version... 'auto'? On 30 Jun 2015 07:57, John Griffith john.griffi...@gmail.com wrote: On Mon, Jun 29, 2015 at 8:54 PM, Jay Bryant jsbry...@electronicjungle.net wrote: I too would prefer option 2. Would rather do the pack ports than remove the functionality. Jay On Wed, Jun 24, 2015 at 9:40 AM Gorka Eguileor gegui...@redhat.com wrote: On Tue, Jun 23, 2015 at 08:49:55AM -0700, Mike Perez wrote: There was a bug raised [1] from some large deployments that the Cinder client 1.2.0 and beyond is not working because of version discovery. Unfortunately it's not taking into account of deployments that have a proxy. A little bit unrelated, but volume pagination in Cinder client is also broken due to Version Discovery: https://bugs.launchpad.net/python-cinderclient/+bug/1453755 Cinder client asks Keystone to find a publicURL based on a version. Keystone will gather data from the service catalog and ask Cinder for a list of the public endpoints and compare. For the proxy cases, Cinder is giving internal URLs back to the proxy and Keystone ends up using that instead of the publicURL in the service catalog. As a result, clients usually won't be able to use the internal URL and rightfully so. This is all correctly setup on the deployer's side, this an issue with the server side code of Cinder. There is a patch that allows the deployer to specify a configuration option public_endpoint [2] which was introduced in a patch in Kilo [3]. The problem though is we can't expect people to already be running Kilo to take advantage of this, and it leaves deployers running stable releases of Juno in the dark with clients upgrading and using the latest. Two options: 1) Revert version discovery which was introduced in Kilo for Cinder client. 2) Grant exception on backporting [4] a patch that helps with this problem, and introduces a config option that does not change default behavior. I'm also not sure if this should be considered for Icehouse. +1 to option 2 and I wouldn't be totally against considering it for Icehouse. Cheers, Gorka. [1] - https://launchpad.net/bugs/1464160 [2] - http://docs.openstack.org/kilo/config-reference/content/cinder-conf-changes-kilo.html [3] - https://review.openstack.org/#/c/159374/ [4] - https://review.openstack.org/#/c/194719/ -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I'll echo Jeremy and Dave's statements regarding compatibility, seems really pretty lame that this can't work. If it's not possible to support both scenarios in the client in a reasonable manner without long timeout periods my vote is for a revert and new client version. Sorry, but in my opinion backports to Cinder itself don't cut it in this case. It's unfortunate we got to this point. Why can't we make this a config option in cinderclient itself? Like USE_AUTO_DISCOVERY=True|False with a default of False in the client and just deal with it or as others have asked can't we make all of this smarter? I mean it's sort of odd to have a discovery option that only works with 'new' versions of the API doesn't it? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe:
Re: [openstack-dev] [cinder][stable] Cinder client broken in Juno
We already have an environment variable for version... 'auto'? On 30 Jun 2015 07:57, John Griffith john.griffi...@gmail.com wrote: On Mon, Jun 29, 2015 at 8:54 PM, Jay Bryant jsbry...@electronicjungle.net wrote: I too would prefer option 2. Would rather do the pack ports than remove the functionality. Jay On Wed, Jun 24, 2015 at 9:40 AM Gorka Eguileor gegui...@redhat.com wrote: On Tue, Jun 23, 2015 at 08:49:55AM -0700, Mike Perez wrote: There was a bug raised [1] from some large deployments that the Cinder client 1.2.0 and beyond is not working because of version discovery. Unfortunately it's not taking into account of deployments that have a proxy. A little bit unrelated, but volume pagination in Cinder client is also broken due to Version Discovery: https://bugs.launchpad.net/python-cinderclient/+bug/1453755 Cinder client asks Keystone to find a publicURL based on a version. Keystone will gather data from the service catalog and ask Cinder for a list of the public endpoints and compare. For the proxy cases, Cinder is giving internal URLs back to the proxy and Keystone ends up using that instead of the publicURL in the service catalog. As a result, clients usually won't be able to use the internal URL and rightfully so. This is all correctly setup on the deployer's side, this an issue with the server side code of Cinder. There is a patch that allows the deployer to specify a configuration option public_endpoint [2] which was introduced in a patch in Kilo [3]. The problem though is we can't expect people to already be running Kilo to take advantage of this, and it leaves deployers running stable releases of Juno in the dark with clients upgrading and using the latest. Two options: 1) Revert version discovery which was introduced in Kilo for Cinder client. 2) Grant exception on backporting [4] a patch that helps with this problem, and introduces a config option that does not change default behavior. I'm also not sure if this should be considered for Icehouse. +1 to option 2 and I wouldn't be totally against considering it for Icehouse. Cheers, Gorka. [1] - https://launchpad.net/bugs/1464160 [2] - http://docs.openstack.org/kilo/config-reference/content/cinder-conf-changes-kilo.html [3] - https://review.openstack.org/#/c/159374/ [4] - https://review.openstack.org/#/c/194719/ -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I'll echo Jeremy and Dave's statements regarding compatibility, seems really pretty lame that this can't work. If it's not possible to support both scenarios in the client in a reasonable manner without long timeout periods my vote is for a revert and new client version. Sorry, but in my opinion backports to Cinder itself don't cut it in this case. It's unfortunate we got to this point. Why can't we make this a config option in cinderclient itself? Like USE_AUTO_DISCOVERY=True|False with a default of False in the client and just deal with it or as others have asked can't we make all of this smarter? I mean it's sort of odd to have a discovery option that only works with 'new' versions of the API doesn't it? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder][stable] Cinder client broken in Juno
I too would prefer option 2. Would rather do the pack ports than remove the functionality. Jay On Wed, Jun 24, 2015 at 9:40 AM Gorka Eguileor gegui...@redhat.com wrote: On Tue, Jun 23, 2015 at 08:49:55AM -0700, Mike Perez wrote: There was a bug raised [1] from some large deployments that the Cinder client 1.2.0 and beyond is not working because of version discovery. Unfortunately it's not taking into account of deployments that have a proxy. A little bit unrelated, but volume pagination in Cinder client is also broken due to Version Discovery: https://bugs.launchpad.net/python-cinderclient/+bug/1453755 Cinder client asks Keystone to find a publicURL based on a version. Keystone will gather data from the service catalog and ask Cinder for a list of the public endpoints and compare. For the proxy cases, Cinder is giving internal URLs back to the proxy and Keystone ends up using that instead of the publicURL in the service catalog. As a result, clients usually won't be able to use the internal URL and rightfully so. This is all correctly setup on the deployer's side, this an issue with the server side code of Cinder. There is a patch that allows the deployer to specify a configuration option public_endpoint [2] which was introduced in a patch in Kilo [3]. The problem though is we can't expect people to already be running Kilo to take advantage of this, and it leaves deployers running stable releases of Juno in the dark with clients upgrading and using the latest. Two options: 1) Revert version discovery which was introduced in Kilo for Cinder client. 2) Grant exception on backporting [4] a patch that helps with this problem, and introduces a config option that does not change default behavior. I'm also not sure if this should be considered for Icehouse. +1 to option 2 and I wouldn't be totally against considering it for Icehouse. Cheers, Gorka. [1] - https://launchpad.net/bugs/1464160 [2] - http://docs.openstack.org/kilo/config-reference/content/cinder-conf-changes-kilo.html [3] - https://review.openstack.org/#/c/159374/ [4] - https://review.openstack.org/#/c/194719/ -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder][stable] Cinder client broken in Juno
On Mon, Jun 29, 2015 at 8:54 PM, Jay Bryant jsbry...@electronicjungle.net wrote: I too would prefer option 2. Would rather do the pack ports than remove the functionality. Jay On Wed, Jun 24, 2015 at 9:40 AM Gorka Eguileor gegui...@redhat.com wrote: On Tue, Jun 23, 2015 at 08:49:55AM -0700, Mike Perez wrote: There was a bug raised [1] from some large deployments that the Cinder client 1.2.0 and beyond is not working because of version discovery. Unfortunately it's not taking into account of deployments that have a proxy. A little bit unrelated, but volume pagination in Cinder client is also broken due to Version Discovery: https://bugs.launchpad.net/python-cinderclient/+bug/1453755 Cinder client asks Keystone to find a publicURL based on a version. Keystone will gather data from the service catalog and ask Cinder for a list of the public endpoints and compare. For the proxy cases, Cinder is giving internal URLs back to the proxy and Keystone ends up using that instead of the publicURL in the service catalog. As a result, clients usually won't be able to use the internal URL and rightfully so. This is all correctly setup on the deployer's side, this an issue with the server side code of Cinder. There is a patch that allows the deployer to specify a configuration option public_endpoint [2] which was introduced in a patch in Kilo [3]. The problem though is we can't expect people to already be running Kilo to take advantage of this, and it leaves deployers running stable releases of Juno in the dark with clients upgrading and using the latest. Two options: 1) Revert version discovery which was introduced in Kilo for Cinder client. 2) Grant exception on backporting [4] a patch that helps with this problem, and introduces a config option that does not change default behavior. I'm also not sure if this should be considered for Icehouse. +1 to option 2 and I wouldn't be totally against considering it for Icehouse. Cheers, Gorka. [1] - https://launchpad.net/bugs/1464160 [2] - http://docs.openstack.org/kilo/config-reference/content/cinder-conf-changes-kilo.html [3] - https://review.openstack.org/#/c/159374/ [4] - https://review.openstack.org/#/c/194719/ -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I'll echo Jeremy and Dave's statements regarding compatibility, seems really pretty lame that this can't work. If it's not possible to support both scenarios in the client in a reasonable manner without long timeout periods my vote is for a revert and new client version. Sorry, but in my opinion backports to Cinder itself don't cut it in this case. It's unfortunate we got to this point. Why can't we make this a config option in cinderclient itself? Like USE_AUTO_DISCOVERY=True|False with a default of False in the client and just deal with it or as others have asked can't we make all of this smarter? I mean it's sort of odd to have a discovery option that only works with 'new' versions of the API doesn't it? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder][stable] Cinder client broken in Juno
The problem there is that it takes (significant) time for the connection attempt to time out - every cinder command taking several minutes is not acceptable. Obviously this depends on the network setup of the cloud - I can only talk about the case we saw On 24 Jun 2015 00:25, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-06-23 08:49:55 -0700 (-0700), Mike Perez wrote: [...] Cinder client asks Keystone to find a publicURL based on a version. Keystone will gather data from the service catalog and ask Cinder for a list of the public endpoints and compare. For the proxy cases, Cinder is giving internal URLs back to the proxy and Keystone ends up using that instead of the publicURL in the service catalog. As a result, clients usually won't be able to use the internal URL and rightfully so. [...] It seems like there would be an option #3: add a fallback behavior to cinderclient to try its old connection method if it fails to reach the discovered URL. I'm guessing there's some specific reason that's impossible, or it would have already been in the works? -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder][stable] Cinder client broken in Juno
Mike Perez wrote: Two options: 1) Revert version discovery which was introduced in Kilo for Cinder client. 2) Grant exception on backporting [4] a patch that helps with this problem, and introduces a config option that does not change default behavior. I'm also not sure if this should be considered for Icehouse. I think both options are possible -- this issue is significant enough that I would grant it a backport exception. But given that there are a lot of pre-Juno clouds out there and people should be able to use the latest client on them, I think we should bite the bullet and fix it completely rather than partially... so I'd pick option 1. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder][stable] Cinder client broken in Juno
On 2015-06-24 09:01:51 +0300 (+0300), Duncan Thomas wrote: The problem there is that it takes (significant) time for the connection attempt to time out - every cinder command taking several minutes is not acceptable. [...] Another silly idea from an end user of cinderclient here, but try both in parallel and use whichever responds first (abandoning the other connection attempt at that point)? I just don't buy that we can consider new versions of the client requiring existing deployments on still relevant releases to upgrade to support it (either to a newer release, a patch, an additional config option, some combination of the three). What we're going to find instead is some (lots of?) providers updating their documentation to tell users that they should stick with an older cinderclient release indefinitely, and that's terrible from an OpenStack interoperability standpoint. -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder][stable] Cinder client broken in Juno
On 24 June 2015 at 14:34, Jeremy Stanley fu...@yuggoth.org wrote: On 2015-06-24 09:01:51 +0300 (+0300), Duncan Thomas wrote: The problem there is that it takes (significant) time for the connection attempt to time out - every cinder command taking several minutes is not acceptable. [...] Another silly idea from an end user of cinderclient here, but try both in parallel and use whichever responds first (abandoning the other connection attempt at that point)? I just don't buy that we can consider new versions of the client requiring existing deployments on still relevant releases to upgrade to support it (either to a newer release, a patch, an additional config option, some combination of the three). What we're going to find instead is some (lots of?) providers updating their documentation to tell users that they should stick with an older cinderclient release indefinitely, and that's terrible from an OpenStack interoperability standpoint. The clients have always strived to have backwards compatibility, and this seems to be no different from the other scenarios that have been encountered. We've started to get away from that, and it feels like a mistake. As Jeremy points out, I fail to see why fallback default behaviour cannot be used.. Attempt to use version discovery feature, if fail - fall back to legacy behaviour.. What are the issues associated with this? Thanks -- Kind Regards, Dave Walker __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder][stable] Cinder client broken in Juno
On Tue, Jun 23, 2015 at 08:49:55AM -0700, Mike Perez wrote: There was a bug raised [1] from some large deployments that the Cinder client 1.2.0 and beyond is not working because of version discovery. Unfortunately it's not taking into account of deployments that have a proxy. A little bit unrelated, but volume pagination in Cinder client is also broken due to Version Discovery: https://bugs.launchpad.net/python-cinderclient/+bug/1453755 Cinder client asks Keystone to find a publicURL based on a version. Keystone will gather data from the service catalog and ask Cinder for a list of the public endpoints and compare. For the proxy cases, Cinder is giving internal URLs back to the proxy and Keystone ends up using that instead of the publicURL in the service catalog. As a result, clients usually won't be able to use the internal URL and rightfully so. This is all correctly setup on the deployer's side, this an issue with the server side code of Cinder. There is a patch that allows the deployer to specify a configuration option public_endpoint [2] which was introduced in a patch in Kilo [3]. The problem though is we can't expect people to already be running Kilo to take advantage of this, and it leaves deployers running stable releases of Juno in the dark with clients upgrading and using the latest. Two options: 1) Revert version discovery which was introduced in Kilo for Cinder client. 2) Grant exception on backporting [4] a patch that helps with this problem, and introduces a config option that does not change default behavior. I'm also not sure if this should be considered for Icehouse. +1 to option 2 and I wouldn't be totally against considering it for Icehouse. Cheers, Gorka. [1] - https://launchpad.net/bugs/1464160 [2] - http://docs.openstack.org/kilo/config-reference/content/cinder-conf-changes-kilo.html [3] - https://review.openstack.org/#/c/159374/ [4] - https://review.openstack.org/#/c/194719/ -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder][stable] Cinder client broken in Juno
On 24 June 2015 at 16:42, Dave Walker em...@daviey.com wrote: As Jeremy points out, I fail to see why fallback default behaviour cannot be used.. Attempt to use version discovery feature, if fail - fall back to legacy behaviour.. What are the issues associated with this? So the issue is that for pre-kilo deployments that use a load-balancer (or kilo+ deployments that use a load balancer and haven't set the correct config option to the address of their load balancer) the version discovery URL given out by cinder API points to a node behind the load balancer. Depending on how this node is firewalled (drop packets .v. send reset), an attempt to connect to this URL can take a long time to timeout. I *think* we can get the desired behaviour by looking at the entry in the catalogue, and if it has a trailing version number then don't do discovery, but I might be wrong... -- Duncan Thomas __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [cinder][stable] Cinder client broken in Juno
There was a bug raised [1] from some large deployments that the Cinder client 1.2.0 and beyond is not working because of version discovery. Unfortunately it's not taking into account of deployments that have a proxy. Cinder client asks Keystone to find a publicURL based on a version. Keystone will gather data from the service catalog and ask Cinder for a list of the public endpoints and compare. For the proxy cases, Cinder is giving internal URLs back to the proxy and Keystone ends up using that instead of the publicURL in the service catalog. As a result, clients usually won't be able to use the internal URL and rightfully so. This is all correctly setup on the deployer's side, this an issue with the server side code of Cinder. There is a patch that allows the deployer to specify a configuration option public_endpoint [2] which was introduced in a patch in Kilo [3]. The problem though is we can't expect people to already be running Kilo to take advantage of this, and it leaves deployers running stable releases of Juno in the dark with clients upgrading and using the latest. Two options: 1) Revert version discovery which was introduced in Kilo for Cinder client. 2) Grant exception on backporting [4] a patch that helps with this problem, and introduces a config option that does not change default behavior. I'm also not sure if this should be considered for Icehouse. [1] - https://launchpad.net/bugs/1464160 [2] - http://docs.openstack.org/kilo/config-reference/content/cinder-conf-changes-kilo.html [3] - https://review.openstack.org/#/c/159374/ [4] - https://review.openstack.org/#/c/194719/ -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder][stable] Cinder client broken in Juno
Hi Mike, We have similar functionality in Glance and I think this is critical enough fix to backport to Juno. Considered for Icehouse, definitely not: http://lists.openstack.org/pipermail/openstack-announce/2015-June/000372.html - Erno (jokke_) -Original Message- From: Mike Perez [mailto:thin...@gmail.com] Sent: 23 June 2015 16:50 To: OpenStack Development Mailing List Cc: Jesse Keating Subject: [openstack-dev] [cinder][stable] Cinder client broken in Juno There was a bug raised [1] from some large deployments that the Cinder client 1.2.0 and beyond is not working because of version discovery. Unfortunately it's not taking into account of deployments that have a proxy. Cinder client asks Keystone to find a publicURL based on a version. Keystone will gather data from the service catalog and ask Cinder for a list of the public endpoints and compare. For the proxy cases, Cinder is giving internal URLs back to the proxy and Keystone ends up using that instead of the publicURL in the service catalog. As a result, clients usually won't be able to use the internal URL and rightfully so. This is all correctly setup on the deployer's side, this an issue with the server side code of Cinder. There is a patch that allows the deployer to specify a configuration option public_endpoint [2] which was introduced in a patch in Kilo [3]. The problem though is we can't expect people to already be running Kilo to take advantage of this, and it leaves deployers running stable releases of Juno in the dark with clients upgrading and using the latest. Two options: 1) Revert version discovery which was introduced in Kilo for Cinder client. 2) Grant exception on backporting [4] a patch that helps with this problem, and introduces a config option that does not change default behavior. I'm also not sure if this should be considered for Icehouse. [1] - https://launchpad.net/bugs/1464160 [2] - http://docs.openstack.org/kilo/config-reference/content/cinder-conf- changes-kilo.html [3] - https://review.openstack.org/#/c/159374/ [4] - https://review.openstack.org/#/c/194719/ -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: OpenStack-dev- requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder][stable] Cinder client broken in Juno
On 06/23/2015 11:49 AM, Mike Perez wrote: There was a bug raised [1] from some large deployments that the Cinder client 1.2.0 and beyond is not working because of version discovery. Unfortunately it's not taking into account of deployments that have a proxy. Cinder client asks Keystone to find a publicURL based on a version. Keystone will gather data from the service catalog and ask Cinder for a list of the public endpoints and compare. For the proxy cases, Cinder is giving internal URLs back to the proxy and Keystone ends up using that instead of the publicURL in the service catalog. As a result, clients usually won't be able to use the internal URL and rightfully so. This is all correctly setup on the deployer's side, this an issue with the server side code of Cinder. There is a patch that allows the deployer to specify a configuration option public_endpoint [2] which was introduced in a patch in Kilo [3]. The problem though is we can't expect people to already be running Kilo to take advantage of this, and it leaves deployers running stable releases of Juno in the dark with clients upgrading and using the latest. Two options: 1) Revert version discovery which was introduced in Kilo for Cinder client. 2) Grant exception on backporting [4] a patch that helps with this problem, and introduces a config option that does not change default behavior. I'm also not sure if this should be considered for Icehouse. I'm, sadly, going to vote for (1) I LOVE the version discovery, but it needs to be able to work with clouds that are out there. Some of them aren't running juno yet. Some of them might not be in a position to deploy the backport patch. OTOH, if you go with (2) - can we add support to cinderclient for skipping version discover if an API_VERSION is passed in? [1] - https://launchpad.net/bugs/1464160 [2] - http://docs.openstack.org/kilo/config-reference/content/cinder-conf-changes-kilo.html [3] - https://review.openstack.org/#/c/159374/ [4] - https://review.openstack.org/#/c/194719/ -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder][stable] Cinder client broken in Juno
On 2015-06-23 08:49:55 -0700 (-0700), Mike Perez wrote: [...] Cinder client asks Keystone to find a publicURL based on a version. Keystone will gather data from the service catalog and ask Cinder for a list of the public endpoints and compare. For the proxy cases, Cinder is giving internal URLs back to the proxy and Keystone ends up using that instead of the publicURL in the service catalog. As a result, clients usually won't be able to use the internal URL and rightfully so. [...] It seems like there would be an option #3: add a fallback behavior to cinderclient to try its old connection method if it fails to reach the discovered URL. I'm guessing there's some specific reason that's impossible, or it would have already been in the works? -- Jeremy Stanley __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [cinder][stable] Cinder client broken in Juno
My first choice here is to revert the version discovery. However, that may be too disruptive. If it is too disruptive then the back port patch is the right approach. In either case this is unfortunate. Sent via mobile On Jun 23, 2015, at 12:30, Monty Taylor mord...@inaugust.com wrote: On 06/23/2015 11:49 AM, Mike Perez wrote: There was a bug raised [1] from some large deployments that the Cinder client 1.2.0 and beyond is not working because of version discovery. Unfortunately it's not taking into account of deployments that have a proxy. Cinder client asks Keystone to find a publicURL based on a version. Keystone will gather data from the service catalog and ask Cinder for a list of the public endpoints and compare. For the proxy cases, Cinder is giving internal URLs back to the proxy and Keystone ends up using that instead of the publicURL in the service catalog. As a result, clients usually won't be able to use the internal URL and rightfully so. This is all correctly setup on the deployer's side, this an issue with the server side code of Cinder. There is a patch that allows the deployer to specify a configuration option public_endpoint [2] which was introduced in a patch in Kilo [3]. The problem though is we can't expect people to already be running Kilo to take advantage of this, and it leaves deployers running stable releases of Juno in the dark with clients upgrading and using the latest. Two options: 1) Revert version discovery which was introduced in Kilo for Cinder client. 2) Grant exception on backporting [4] a patch that helps with this problem, and introduces a config option that does not change default behavior. I'm also not sure if this should be considered for Icehouse. I'm, sadly, going to vote for (1) I LOVE the version discovery, but it needs to be able to work with clouds that are out there. Some of them aren't running juno yet. Some of them might not be in a position to deploy the backport patch. OTOH, if you go with (2) - can we add support to cinderclient for skipping version discover if an API_VERSION is passed in? [1] - https://launchpad.net/bugs/1464160 [2] - http://docs.openstack.org/kilo/config-reference/content/cinder-conf-changes-kilo.html [3] - https://review.openstack.org/#/c/159374/ [4] - https://review.openstack.org/#/c/194719/ -- Mike Perez __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
