Re: [openstack-dev] [nova][cinder] can we deprecate the volume CLIs in novaclient?
On 5/15/2015 9:38 AM, Sean Dague wrote: On 05/15/2015 12:28 PM, Everett Toews wrote: On May 15, 2015, at 10:28 AM, John Griffith john.griffi...@gmail.com mailto:john.griffi...@gmail.com wrote: On Thu, May 14, 2015 at 8:29 PM, Matt Riedemann mrie...@linux.vnet.ibm.com mailto:mrie...@linux.vnet.ibm.com wrote: This came up while talking about bug 1454369 [1]. This also came up at one point in kilo when we found out the volume CLIs in novaclient didn't work at one point and we broke the cells devstack exercises job because of it. python-novaclient uses cinder API to handle the volume CLI rather than going to the nova volume API. There are issues with this because novaclient needs a certain endpoint/service_type setup in the service catalog to support cinder v1/v2 APIs (whatever devstack sets up today). novaclient defaults to volume (v1) and if you disable that in cinder then novaclient doesn't work because it's not using volumev2. So like anyone might ask, why doesn't novaclient talk to nova volume APIs to do volume thingies and the answer is because the nova volume API doesn't handle all of the volume thingies like snapshots and volume types. So I got to to thinking, why the hell are we still supporting volume operations via novaclient anyway? Isn't that cinderclient's job? Or python-openstackclient's job? Can't we deprecate the volume CLIs in novaclient and tell people to use cinderclient instead since it now has version discovery [2] so that problem would be handled for us. Since we have nova volume APIs maybe we can't remove the volume CLIs in novaclient, but could they be limited to just operations that the nova API supports and then we make novaclient talk to nova volume APIs rather than cinder APIs (because the nova API will talk to cinderclient which again has the version discovery done for us). Or assuming we could deprecate the volume CLIs in novaclient, what would the timeline on deprecation be since it's not a server project with a 6 month release cycle? I'm assuming we'd still have 6-12 months deprecation on a client like this because of all of the tooling potentially written around it. [1] https://bugs.launchpad.net/python-novaclient/+bug/1454369 [2] https://review.openstack.org/#/c/145613/ I can't speak for the nova folks, however i do think removing the volume calls from novaclient seems ok. It was always sort of left for compat I think, and not sure any of us really thought about just removing it. At this point it probably just introduces confusion and as you're running into problems. Seems like a good plan, and somewhat less confusing. On a side note, might be some other *things* in novaclient that we could look at as well, particularly around networking. FWIW, this is already underway in jclouds-land. After a lengthy deprecation period (still ongoing actually), we’ll be removing the Nova volume calls but obviously keeping the volume attachment stuff. Both the Nova and Cinder calls have coexisted for over a year with documentation pointing from Nova to Cinder. The deprecation annotations handle emitting warnings for the deprecated calls to increase visibility. Everett, this is actually a different thing. nova volume does not talk to Nova's volume proxy, it goes straight to cinder through the service catalog. Deprecating this part of nova client is probably fine, but it should have a lengthy deprecation cycle, as it's been like this for a very long time. It feels like it won't go away before openstack client starts taking hold anyway. I think this raises a more important issue of Service Catalog Standarization. The reason we're in a bind here has as much to do with the fact that service catalog content isn't standardized for OpenStack services. If so, having another cinder implementation in novaclient wouldn't be such a bad thing, and not having to switch cli commands is pretty handy (all hail our future osc overlords). Fortunately, we're going to be talking about just this kind of problem at Summit - http://libertydesignsummit.sched.org/event/194b2589eca19956cb88ada45e985e29 -Sean Here is the change for those following along at home: https://review.openstack.org/#/c/185141/ -- Thanks, Matt Riedemann __ 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] [nova][cinder] can we deprecate the volume CLIs in novaclient?
On Thu, May 14, 2015 at 8:29 PM, Matt Riedemann mrie...@linux.vnet.ibm.com wrote: This came up while talking about bug 1454369 [1]. This also came up at one point in kilo when we found out the volume CLIs in novaclient didn't work at one point and we broke the cells devstack exercises job because of it. python-novaclient uses cinder API to handle the volume CLI rather than going to the nova volume API. There are issues with this because novaclient needs a certain endpoint/service_type setup in the service catalog to support cinder v1/v2 APIs (whatever devstack sets up today). novaclient defaults to volume (v1) and if you disable that in cinder then novaclient doesn't work because it's not using volumev2. So like anyone might ask, why doesn't novaclient talk to nova volume APIs to do volume thingies and the answer is because the nova volume API doesn't handle all of the volume thingies like snapshots and volume types. So I got to to thinking, why the hell are we still supporting volume operations via novaclient anyway? Isn't that cinderclient's job? Or python-openstackclient's job? Can't we deprecate the volume CLIs in novaclient and tell people to use cinderclient instead since it now has version discovery [2] so that problem would be handled for us. Since we have nova volume APIs maybe we can't remove the volume CLIs in novaclient, but could they be limited to just operations that the nova API supports and then we make novaclient talk to nova volume APIs rather than cinder APIs (because the nova API will talk to cinderclient which again has the version discovery done for us). Or assuming we could deprecate the volume CLIs in novaclient, what would the timeline on deprecation be since it's not a server project with a 6 month release cycle? I'm assuming we'd still have 6-12 months deprecation on a client like this because of all of the tooling potentially written around it. [1] https://bugs.launchpad.net/python-novaclient/+bug/1454369 [2] https://review.openstack.org/#/c/145613/ -- Thanks, Matt Riedemann __ 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 can't speak for the nova folks, however i do think removing the volume calls from novaclient seems ok. It was always sort of left for compat I think, and not sure any of us really thought about just removing it. At this point it probably just introduces confusion and as you're running into problems. Seems like a good plan, and somewhat less confusing. On a side note, might be some other *things* in novaclient that we could look at as well, particularly around networking. __ 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] [nova][cinder] can we deprecate the volume CLIs in novaclient?
On May 15, 2015, at 10:28 AM, John Griffith john.griffi...@gmail.commailto:john.griffi...@gmail.com wrote: On Thu, May 14, 2015 at 8:29 PM, Matt Riedemann mrie...@linux.vnet.ibm.commailto:mrie...@linux.vnet.ibm.com wrote: This came up while talking about bug 1454369 [1]. This also came up at one point in kilo when we found out the volume CLIs in novaclient didn't work at one point and we broke the cells devstack exercises job because of it. python-novaclient uses cinder API to handle the volume CLI rather than going to the nova volume API. There are issues with this because novaclient needs a certain endpoint/service_type setup in the service catalog to support cinder v1/v2 APIs (whatever devstack sets up today). novaclient defaults to volume (v1) and if you disable that in cinder then novaclient doesn't work because it's not using volumev2. So like anyone might ask, why doesn't novaclient talk to nova volume APIs to do volume thingies and the answer is because the nova volume API doesn't handle all of the volume thingies like snapshots and volume types. So I got to to thinking, why the hell are we still supporting volume operations via novaclient anyway? Isn't that cinderclient's job? Or python-openstackclient's job? Can't we deprecate the volume CLIs in novaclient and tell people to use cinderclient instead since it now has version discovery [2] so that problem would be handled for us. Since we have nova volume APIs maybe we can't remove the volume CLIs in novaclient, but could they be limited to just operations that the nova API supports and then we make novaclient talk to nova volume APIs rather than cinder APIs (because the nova API will talk to cinderclient which again has the version discovery done for us). Or assuming we could deprecate the volume CLIs in novaclient, what would the timeline on deprecation be since it's not a server project with a 6 month release cycle? I'm assuming we'd still have 6-12 months deprecation on a client like this because of all of the tooling potentially written around it. [1] https://bugs.launchpad.net/python-novaclient/+bug/1454369 [2] https://review.openstack.org/#/c/145613/ I can't speak for the nova folks, however i do think removing the volume calls from novaclient seems ok. It was always sort of left for compat I think, and not sure any of us really thought about just removing it. At this point it probably just introduces confusion and as you're running into problems. Seems like a good plan, and somewhat less confusing. On a side note, might be some other *things* in novaclient that we could look at as well, particularly around networking. FWIW, this is already underway in jclouds-land. After a lengthy deprecation period (still ongoing actually), we’ll be removing the Nova volume calls but obviously keeping the volume attachment stuff. Both the Nova and Cinder calls have coexisted for over a year with documentation pointing from Nova to Cinder. The deprecation annotations handle emitting warnings for the deprecated calls to increase visibility. Everett __ 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] [nova][cinder] can we deprecate the volume CLIs in novaclient?
On 05/14/2015 10:29 PM, Matt Riedemann wrote: This came up while talking about bug 1454369 [1]. This also came up at one point in kilo when we found out the volume CLIs in novaclient didn't work at one point and we broke the cells devstack exercises job because of it. python-novaclient uses cinder API to handle the volume CLI rather than going to the nova volume API. There are issues with this because novaclient needs a certain endpoint/service_type setup in the service catalog to support cinder v1/v2 APIs (whatever devstack sets up today). novaclient defaults to volume (v1) and if you disable that in cinder then novaclient doesn't work because it's not using volumev2. So like anyone might ask, why doesn't novaclient talk to nova volume APIs to do volume thingies and the answer is because the nova volume API doesn't handle all of the volume thingies like snapshots and volume types. So I got to to thinking, why the hell are we still supporting volume operations via novaclient anyway? Isn't that cinderclient's job? Or python-openstackclient's job? Can't we deprecate the volume CLIs in novaclient and tell people to use cinderclient instead since it now has version discovery [2] so that problem would be handled for us. Since we have nova volume APIs maybe we can't remove the volume CLIs in novaclient, but could they be limited to just operations that the nova API supports and then we make novaclient talk to nova volume APIs rather than cinder APIs (because the nova API will talk to cinderclient which again has the version discovery done for us). Or assuming we could deprecate the volume CLIs in novaclient, what would the timeline on deprecation be since it's not a server project with a 6 month release cycle? I'm assuming we'd still have 6-12 months deprecation on a client like this because of all of the tooling potentially written around it. I wrote this on the bug report, too, but I believe deprecating the volume commands from novaclient is the appropriate solution. I think a single 6 month deprecation cycle is appropriate. Best, -jay __ 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] [nova][cinder] can we deprecate the volume CLIs in novaclient?
On 05/15/2015 12:28 PM, Everett Toews wrote: On May 15, 2015, at 10:28 AM, John Griffith john.griffi...@gmail.com mailto:john.griffi...@gmail.com wrote: On Thu, May 14, 2015 at 8:29 PM, Matt Riedemann mrie...@linux.vnet.ibm.com mailto:mrie...@linux.vnet.ibm.com wrote: This came up while talking about bug 1454369 [1]. This also came up at one point in kilo when we found out the volume CLIs in novaclient didn't work at one point and we broke the cells devstack exercises job because of it. python-novaclient uses cinder API to handle the volume CLI rather than going to the nova volume API. There are issues with this because novaclient needs a certain endpoint/service_type setup in the service catalog to support cinder v1/v2 APIs (whatever devstack sets up today). novaclient defaults to volume (v1) and if you disable that in cinder then novaclient doesn't work because it's not using volumev2. So like anyone might ask, why doesn't novaclient talk to nova volume APIs to do volume thingies and the answer is because the nova volume API doesn't handle all of the volume thingies like snapshots and volume types. So I got to to thinking, why the hell are we still supporting volume operations via novaclient anyway? Isn't that cinderclient's job? Or python-openstackclient's job? Can't we deprecate the volume CLIs in novaclient and tell people to use cinderclient instead since it now has version discovery [2] so that problem would be handled for us. Since we have nova volume APIs maybe we can't remove the volume CLIs in novaclient, but could they be limited to just operations that the nova API supports and then we make novaclient talk to nova volume APIs rather than cinder APIs (because the nova API will talk to cinderclient which again has the version discovery done for us). Or assuming we could deprecate the volume CLIs in novaclient, what would the timeline on deprecation be since it's not a server project with a 6 month release cycle? I'm assuming we'd still have 6-12 months deprecation on a client like this because of all of the tooling potentially written around it. [1] https://bugs.launchpad.net/python-novaclient/+bug/1454369 [2] https://review.openstack.org/#/c/145613/ I can't speak for the nova folks, however i do think removing the volume calls from novaclient seems ok. It was always sort of left for compat I think, and not sure any of us really thought about just removing it. At this point it probably just introduces confusion and as you're running into problems. Seems like a good plan, and somewhat less confusing. On a side note, might be some other *things* in novaclient that we could look at as well, particularly around networking. FWIW, this is already underway in jclouds-land. After a lengthy deprecation period (still ongoing actually), we’ll be removing the Nova volume calls but obviously keeping the volume attachment stuff. Both the Nova and Cinder calls have coexisted for over a year with documentation pointing from Nova to Cinder. The deprecation annotations handle emitting warnings for the deprecated calls to increase visibility. Everett, this is actually a different thing. nova volume does not talk to Nova's volume proxy, it goes straight to cinder through the service catalog. Deprecating this part of nova client is probably fine, but it should have a lengthy deprecation cycle, as it's been like this for a very long time. It feels like it won't go away before openstack client starts taking hold anyway. I think this raises a more important issue of Service Catalog Standarization. The reason we're in a bind here has as much to do with the fact that service catalog content isn't standardized for OpenStack services. If so, having another cinder implementation in novaclient wouldn't be such a bad thing, and not having to switch cli commands is pretty handy (all hail our future osc overlords). Fortunately, we're going to be talking about just this kind of problem at Summit - http://libertydesignsummit.sched.org/event/194b2589eca19956cb88ada45e985e29 -Sean -- Sean Dague http://dague.net __ 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] [nova][cinder] can we deprecate the volume CLIs in novaclient?
This came up while talking about bug 1454369 [1]. This also came up at one point in kilo when we found out the volume CLIs in novaclient didn't work at one point and we broke the cells devstack exercises job because of it. python-novaclient uses cinder API to handle the volume CLI rather than going to the nova volume API. There are issues with this because novaclient needs a certain endpoint/service_type setup in the service catalog to support cinder v1/v2 APIs (whatever devstack sets up today). novaclient defaults to volume (v1) and if you disable that in cinder then novaclient doesn't work because it's not using volumev2. So like anyone might ask, why doesn't novaclient talk to nova volume APIs to do volume thingies and the answer is because the nova volume API doesn't handle all of the volume thingies like snapshots and volume types. So I got to to thinking, why the hell are we still supporting volume operations via novaclient anyway? Isn't that cinderclient's job? Or python-openstackclient's job? Can't we deprecate the volume CLIs in novaclient and tell people to use cinderclient instead since it now has version discovery [2] so that problem would be handled for us. Since we have nova volume APIs maybe we can't remove the volume CLIs in novaclient, but could they be limited to just operations that the nova API supports and then we make novaclient talk to nova volume APIs rather than cinder APIs (because the nova API will talk to cinderclient which again has the version discovery done for us). Or assuming we could deprecate the volume CLIs in novaclient, what would the timeline on deprecation be since it's not a server project with a 6 month release cycle? I'm assuming we'd still have 6-12 months deprecation on a client like this because of all of the tooling potentially written around it. [1] https://bugs.launchpad.net/python-novaclient/+bug/1454369 [2] https://review.openstack.org/#/c/145613/ -- Thanks, Matt Riedemann __ 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
