Re: [openstack-dev] excessively difficult to support both iso8601 0.1.4 and 0.1.8 as deps
On 11/27/2013 06:46 PM, Alan Pevec wrote: 2013/11/27 Sean Dague s...@dague.net: The problem is you can't really support both iso8601 was dormant for years, and the revived version isn't compatible with the old version. So supporting both means basically forking iso8601 and maintaining you own version of it monkey patched in your own tree. Right, hence glance was added https://review.openstack.org/55998 to unblock the previous gate failure. Issue now is that stable/grizzly Tempest uses clients from git trunk, which is not going to work since trunk will add more and more incompatible dependencies, even if backward compatbility is preserved against the old service APIs! Solutions could be that Tempest installs clients into separate venv to avoid dependecy conflicts or establish stable/* branches for clients[1] which are created around OpenStack release time. I'd like to propose to switch testing for stable branches: We should switch to install environments for stable releases through other methods, such as packages. There are quite a few provisioning methods out there right now. The benefit would be, we'd have a very reproducible way to build identical environments for each run; the cost would be, that we'd need to create a test environment for each project: install everything but the project to test via packages. When choosing packages to install: which one do we want to take? Just a single source or take for each (major) distribution, thus multiplying effort here? Matthias ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] excessively difficult to support both iso8601 0.1.4 and 0.1.8 as deps
The problem is you can't really support both iso8601 was dormant for years, and the revived version isn't compatible with the old version. So supporting both means basically forking iso8601 and maintaining you own version of it monkey patched in your own tree. On Wed, Nov 27, 2013 at 1:58 AM, Yaguang Tang yaguang.t...@canonical.com wrote: after update to iso8601=0.1.8, it breaks stable/neutron jenkins tests, because stable/glance requires iso8601=0.1.4, log info https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/43/console, I have filed a bug to track this https://bugs.launchpad.net/glance/+bug/1255419. 2013/11/26 Thomas Goirand z...@debian.org I'm sorry to restart this topic. I don't mind if we upgrade to 0.1.8, but then I will need to have patches for Havana to support version 0.1.8. Otherwise, it's going to be very difficult on the packaging side: I will need to upload 0.1.8 for Icehouse, but then it will break everything else (eg: Havana) that is currently in Sid. Was there some patches already for that? If so, please point to them so that I can cherry-pick them, and carry the patches in the Debian packages (it doesn't have to be backported to the Havana branch, I'm fine keeping the patches in the packages, if at least they are identified). Is there a way that I can grep all commits in Gerrit, to see if there was such patches committed recently? Cheers, Thomas Goirand (zigo) On 10/24/2013 09:37 PM, Morgan Fainberg wrote: It seems like adopting 0.1.8 is the right approach. If it doesn't work with other projects, we should work to help those projects get updated to work with it. --Morgan On Thursday, October 24, 2013, Zhi Yan Liu wrote: Hi all, Adopt 0.1.8 as iso8601 minimum version: https://review.openstack.org/#/c/53567/ zhiyan On Thu, Oct 24, 2013 at 4:09 AM, Dolph Mathews dolph.math...@gmail.com javascript:; wrote: On Wed, Oct 23, 2013 at 2:30 PM, Robert Collins robe...@robertcollins.net javascript:; wrote: On 24 October 2013 07:34, Mark Washenberger mark.washenber...@markwash.net javascript:; wrote: Hi folks! 1) Adopt 0.1.8 as the minimum version in openstack-requirements. 2) Do nothing (i.e. let Glance behavior depend on iso8601 in this way, and just fix the tests so they don't care about these extra formats) 3) Make Glance work with the added formats even if 0.1.4 is installed. I think we should do (1) because both (2) will permit surprising, nonobvious changes in behaviour and (3) is just nasty engineering. Alternatively, add a (4) which is (2) with whinge on startup if 0.1.4 is installed to make identifying this situation easy. I'm in favor of (1), unless there's a reason why 0.1.8 not viable for another project or packager, in which case, I've never heard the term whinge before so there should definitely be some of that. The last thing a new / upgraded deployment wants is something like nova, or a third party API script failing in nonobvious ways with no breadcrumbs to lead them to 'upgrade iso8601' as an answer. -Rob -- Robert Collins rbtcoll...@hp.com javascript:; Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; 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 -- Tang Yaguang Canonical Ltd. | www.ubuntu.com | www.canonical.com Mobile: +86 152 1094 6968 gpg key: 0x187F664F ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Sean Dague http://dague.net ___
Re: [openstack-dev] excessively difficult to support both iso8601 0.1.4 and 0.1.8 as deps
Yes agreed with Sean, make compatible with both iso8601 is overcomplicated. This is my abandoned try: https://review.openstack.org/#/c/53186/ zhiyan On Wed, Nov 27, 2013 at 8:49 PM, Sean Dague s...@dague.net wrote: The problem is you can't really support both iso8601 was dormant for years, and the revived version isn't compatible with the old version. So supporting both means basically forking iso8601 and maintaining you own version of it monkey patched in your own tree. On Wed, Nov 27, 2013 at 1:58 AM, Yaguang Tang yaguang.t...@canonical.com wrote: after update to iso8601=0.1.8, it breaks stable/neutron jenkins tests, because stable/glance requires iso8601=0.1.4, log info https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/43/console, I have filed a bug to track this https://bugs.launchpad.net/glance/+bug/1255419. 2013/11/26 Thomas Goirand z...@debian.org I'm sorry to restart this topic. I don't mind if we upgrade to 0.1.8, but then I will need to have patches for Havana to support version 0.1.8. Otherwise, it's going to be very difficult on the packaging side: I will need to upload 0.1.8 for Icehouse, but then it will break everything else (eg: Havana) that is currently in Sid. Was there some patches already for that? If so, please point to them so that I can cherry-pick them, and carry the patches in the Debian packages (it doesn't have to be backported to the Havana branch, I'm fine keeping the patches in the packages, if at least they are identified). Is there a way that I can grep all commits in Gerrit, to see if there was such patches committed recently? Cheers, Thomas Goirand (zigo) On 10/24/2013 09:37 PM, Morgan Fainberg wrote: It seems like adopting 0.1.8 is the right approach. If it doesn't work with other projects, we should work to help those projects get updated to work with it. --Morgan On Thursday, October 24, 2013, Zhi Yan Liu wrote: Hi all, Adopt 0.1.8 as iso8601 minimum version: https://review.openstack.org/#/c/53567/ zhiyan On Thu, Oct 24, 2013 at 4:09 AM, Dolph Mathews dolph.math...@gmail.com javascript:; wrote: On Wed, Oct 23, 2013 at 2:30 PM, Robert Collins robe...@robertcollins.net javascript:; wrote: On 24 October 2013 07:34, Mark Washenberger mark.washenber...@markwash.net javascript:; wrote: Hi folks! 1) Adopt 0.1.8 as the minimum version in openstack-requirements. 2) Do nothing (i.e. let Glance behavior depend on iso8601 in this way, and just fix the tests so they don't care about these extra formats) 3) Make Glance work with the added formats even if 0.1.4 is installed. I think we should do (1) because both (2) will permit surprising, nonobvious changes in behaviour and (3) is just nasty engineering. Alternatively, add a (4) which is (2) with whinge on startup if 0.1.4 is installed to make identifying this situation easy. I'm in favor of (1), unless there's a reason why 0.1.8 not viable for another project or packager, in which case, I've never heard the term whinge before so there should definitely be some of that. The last thing a new / upgraded deployment wants is something like nova, or a third party API script failing in nonobvious ways with no breadcrumbs to lead them to 'upgrade iso8601' as an answer. -Rob -- Robert Collins rbtcoll...@hp.com javascript:; Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; 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 -- Tang Yaguang Canonical Ltd. | www.ubuntu.com | www.canonical.com Mobile: +86 152 1094 6968 gpg key: 0x187F664F
Re: [openstack-dev] excessively difficult to support both iso8601 0.1.4 and 0.1.8 as deps
2013/11/27 Sean Dague s...@dague.net: The problem is you can't really support both iso8601 was dormant for years, and the revived version isn't compatible with the old version. So supporting both means basically forking iso8601 and maintaining you own version of it monkey patched in your own tree. Right, hence glance was added https://review.openstack.org/55998 to unblock the previous gate failure. Issue now is that stable/grizzly Tempest uses clients from git trunk, which is not going to work since trunk will add more and more incompatible dependencies, even if backward compatbility is preserved against the old service APIs! Solutions could be that Tempest installs clients into separate venv to avoid dependecy conflicts or establish stable/* branches for clients[1] which are created around OpenStack release time. Cheers, Alan [1] we have those for openstack client packages in Fedora/RDO e.g. https://github.com/redhat-openstack/python-novaclient/branches Here's nice explanation by Jakub: http://openstack.redhat.com/Clients On Wed, Nov 27, 2013 at 1:58 AM, Yaguang Tang yaguang.t...@canonical.com wrote: after update to iso8601=0.1.8, it breaks stable/neutron jenkins tests, because stable/glance requires iso8601=0.1.4, log info https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/43/console, I have filed a bug to track this https://bugs.launchpad.net/glance/+bug/1255419. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] excessively difficult to support both iso8601 0.1.4 and 0.1.8 as deps
On 11/27/2013 12:46 PM, Alan Pevec wrote: 2013/11/27 Sean Dague s...@dague.net: The problem is you can't really support both iso8601 was dormant for years, and the revived version isn't compatible with the old version. So supporting both means basically forking iso8601 and maintaining you own version of it monkey patched in your own tree. Right, hence glance was added https://review.openstack.org/55998 to unblock the previous gate failure. Issue now is that stable/grizzly Tempest uses clients from git trunk, which is not going to work since trunk will add more and more incompatible dependencies, even if backward compatbility is preserved against the old service APIs! I think when we decided to unpin clients and said that current clients should work with older servers, we really wanted that to mean current client can talk the REST API of older servers so users don't have to deal with this but we ended up with current clients can be installed in the same python env as older servers, and implemented the compatibility testing assuming the latter. Solutions could be that Tempest installs clients into separate venv to avoid dependecy conflicts or establish stable/* branches for clients[1] which are created around OpenStack release time. We might be able to get the gate testing to work with a separate venv, but I don't know enough to be sure. Even if we could do that, users could have the same problem if they try to install a current library on a machine with an older server. It is a problem that we are stuck in the python version of http://en.wikipedia.org/wiki/DLL_Hell but where there is not even an attempt by some libraries to be compatible. Or am I missing something? Is there some way to support side-by-side libraries the way Microsoft eventually did to get out of this mess? -David Cheers, Alan [1] we have those for openstack client packages in Fedora/RDO e.g. https://github.com/redhat-openstack/python-novaclient/branches Here's nice explanation by Jakub: http://openstack.redhat.com/Clients On Wed, Nov 27, 2013 at 1:58 AM, Yaguang Tang yaguang.t...@canonical.com wrote: after update to iso8601=0.1.8, it breaks stable/neutron jenkins tests, because stable/glance requires iso8601=0.1.4, log info https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/43/console, I have filed a bug to track this https://bugs.launchpad.net/glance/+bug/1255419. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] excessively difficult to support both iso8601 0.1.4 and 0.1.8 as deps
I'm sorry to restart this topic. I don't mind if we upgrade to 0.1.8, but then I will need to have patches for Havana to support version 0.1.8. Otherwise, it's going to be very difficult on the packaging side: I will need to upload 0.1.8 for Icehouse, but then it will break everything else (eg: Havana) that is currently in Sid. Was there some patches already for that? If so, please point to them so that I can cherry-pick them, and carry the patches in the Debian packages (it doesn't have to be backported to the Havana branch, I'm fine keeping the patches in the packages, if at least they are identified). Is there a way that I can grep all commits in Gerrit, to see if there was such patches committed recently? Cheers, Thomas Goirand (zigo) On 10/24/2013 09:37 PM, Morgan Fainberg wrote: It seems like adopting 0.1.8 is the right approach. If it doesn't work with other projects, we should work to help those projects get updated to work with it. --Morgan On Thursday, October 24, 2013, Zhi Yan Liu wrote: Hi all, Adopt 0.1.8 as iso8601 minimum version: https://review.openstack.org/#/c/53567/ zhiyan On Thu, Oct 24, 2013 at 4:09 AM, Dolph Mathews dolph.math...@gmail.com javascript:; wrote: On Wed, Oct 23, 2013 at 2:30 PM, Robert Collins robe...@robertcollins.net javascript:; wrote: On 24 October 2013 07:34, Mark Washenberger mark.washenber...@markwash.net javascript:; wrote: Hi folks! 1) Adopt 0.1.8 as the minimum version in openstack-requirements. 2) Do nothing (i.e. let Glance behavior depend on iso8601 in this way, and just fix the tests so they don't care about these extra formats) 3) Make Glance work with the added formats even if 0.1.4 is installed. I think we should do (1) because both (2) will permit surprising, nonobvious changes in behaviour and (3) is just nasty engineering. Alternatively, add a (4) which is (2) with whinge on startup if 0.1.4 is installed to make identifying this situation easy. I'm in favor of (1), unless there's a reason why 0.1.8 not viable for another project or packager, in which case, I've never heard the term whinge before so there should definitely be some of that. The last thing a new / upgraded deployment wants is something like nova, or a third party API script failing in nonobvious ways with no breadcrumbs to lead them to 'upgrade iso8601' as an answer. -Rob -- Robert Collins rbtcoll...@hp.com javascript:; Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; 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] excessively difficult to support both iso8601 0.1.4 and 0.1.8 as deps
after update to iso8601=0.1.8, it breaks stable/neutron jenkins tests, because stable/glance requires iso8601=0.1.4, log info https://jenkins02.openstack.org/job/periodic-tempest-devstack-vm-neutron-stable-grizzly/43/console , I have filed a bug to track this https://bugs.launchpad.net/glance/+bug/1255419. 2013/11/26 Thomas Goirand z...@debian.org I'm sorry to restart this topic. I don't mind if we upgrade to 0.1.8, but then I will need to have patches for Havana to support version 0.1.8. Otherwise, it's going to be very difficult on the packaging side: I will need to upload 0.1.8 for Icehouse, but then it will break everything else (eg: Havana) that is currently in Sid. Was there some patches already for that? If so, please point to them so that I can cherry-pick them, and carry the patches in the Debian packages (it doesn't have to be backported to the Havana branch, I'm fine keeping the patches in the packages, if at least they are identified). Is there a way that I can grep all commits in Gerrit, to see if there was such patches committed recently? Cheers, Thomas Goirand (zigo) On 10/24/2013 09:37 PM, Morgan Fainberg wrote: It seems like adopting 0.1.8 is the right approach. If it doesn't work with other projects, we should work to help those projects get updated to work with it. --Morgan On Thursday, October 24, 2013, Zhi Yan Liu wrote: Hi all, Adopt 0.1.8 as iso8601 minimum version: https://review.openstack.org/#/c/53567/ zhiyan On Thu, Oct 24, 2013 at 4:09 AM, Dolph Mathews dolph.math...@gmail.com javascript:; wrote: On Wed, Oct 23, 2013 at 2:30 PM, Robert Collins robe...@robertcollins.net javascript:; wrote: On 24 October 2013 07:34, Mark Washenberger mark.washenber...@markwash.net javascript:; wrote: Hi folks! 1) Adopt 0.1.8 as the minimum version in openstack-requirements. 2) Do nothing (i.e. let Glance behavior depend on iso8601 in this way, and just fix the tests so they don't care about these extra formats) 3) Make Glance work with the added formats even if 0.1.4 is installed. I think we should do (1) because both (2) will permit surprising, nonobvious changes in behaviour and (3) is just nasty engineering. Alternatively, add a (4) which is (2) with whinge on startup if 0.1.4 is installed to make identifying this situation easy. I'm in favor of (1), unless there's a reason why 0.1.8 not viable for another project or packager, in which case, I've never heard the term whinge before so there should definitely be some of that. The last thing a new / upgraded deployment wants is something like nova, or a third party API script failing in nonobvious ways with no breadcrumbs to lead them to 'upgrade iso8601' as an answer. -Rob -- Robert Collins rbtcoll...@hp.com javascript:; Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; 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 -- Tang Yaguang Canonical Ltd. | www.ubuntu.com | www.canonical.com Mobile: +86 152 1094 6968 gpg key: 0x187F664F ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] excessively difficult to support both iso8601 0.1.4 and 0.1.8 as deps
It seems like adopting 0.1.8 is the right approach. If it doesn't work with other projects, we should work to help those projects get updated to work with it. --Morgan On Thursday, October 24, 2013, Zhi Yan Liu wrote: Hi all, Adopt 0.1.8 as iso8601 minimum version: https://review.openstack.org/#/c/53567/ zhiyan On Thu, Oct 24, 2013 at 4:09 AM, Dolph Mathews dolph.math...@gmail.comjavascript:; wrote: On Wed, Oct 23, 2013 at 2:30 PM, Robert Collins robe...@robertcollins.net javascript:; wrote: On 24 October 2013 07:34, Mark Washenberger mark.washenber...@markwash.net javascript:; wrote: Hi folks! 1) Adopt 0.1.8 as the minimum version in openstack-requirements. 2) Do nothing (i.e. let Glance behavior depend on iso8601 in this way, and just fix the tests so they don't care about these extra formats) 3) Make Glance work with the added formats even if 0.1.4 is installed. I think we should do (1) because both (2) will permit surprising, nonobvious changes in behaviour and (3) is just nasty engineering. Alternatively, add a (4) which is (2) with whinge on startup if 0.1.4 is installed to make identifying this situation easy. I'm in favor of (1), unless there's a reason why 0.1.8 not viable for another project or packager, in which case, I've never heard the term whinge before so there should definitely be some of that. The last thing a new / upgraded deployment wants is something like nova, or a third party API script failing in nonobvious ways with no breadcrumbs to lead them to 'upgrade iso8601' as an answer. -Rob -- Robert Collins rbtcoll...@hp.com javascript:; Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org javascript:; 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] excessively difficult to support both iso8601 0.1.4 and 0.1.8 as deps
Hi folks! In the images api, we depend on iso8601 to parse some dates and times. Recently, since version 0.1.4, python-iso8601 added support for a few more formats, and we finally got some other issues nailed down by 0.1.8. Maybe the fact that these formats weren't supported before was a bug. I don't really know. This puts us in an awkward place, however. With the help of our unit tests, we noticed that, if you switch from 0.1.8 back to 0.1.4 in your deployment, your image api will lose support for certain datetime formats like -MM-DD (where the time part is assumed to be all zeros). This obviously creates a (perhaps small) compatibility concern. Here are our alternatives: 1) Adopt 0.1.8 as the minimum version in openstack-requirements. 2) Do nothing (i.e. let Glance behavior depend on iso8601 in this way, and just fix the tests so they don't care about these extra formats) 3) Make Glance work with the added formats even if 0.1.4 is installed. As of yesterday we were resolved to do #3, trying to be good citizens. But it appears that to do so requires essentially reimplementing a large swath of iso8601 0.1.8 in glance itself. Gross! So, I'd like to suggest that we instead adopt option #1, or alternatively agree that option #2 is no big deal, we can all go back to sleep. Thoughts? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] excessively difficult to support both iso8601 0.1.4 and 0.1.8 as deps
Hi, Why not use python-dateutil? Regards chuck On Wed, Oct 23, 2013 at 11:34 AM, Mark Washenberger mark.washenber...@markwash.net wrote: Hi folks! In the images api, we depend on iso8601 to parse some dates and times. Recently, since version 0.1.4, python-iso8601 added support for a few more formats, and we finally got some other issues nailed down by 0.1.8. Maybe the fact that these formats weren't supported before was a bug. I don't really know. This puts us in an awkward place, however. With the help of our unit tests, we noticed that, if you switch from 0.1.8 back to 0.1.4 in your deployment, your image api will lose support for certain datetime formats like -MM-DD (where the time part is assumed to be all zeros). This obviously creates a (perhaps small) compatibility concern. Here are our alternatives: 1) Adopt 0.1.8 as the minimum version in openstack-requirements. 2) Do nothing (i.e. let Glance behavior depend on iso8601 in this way, and just fix the tests so they don't care about these extra formats) 3) Make Glance work with the added formats even if 0.1.4 is installed. As of yesterday we were resolved to do #3, trying to be good citizens. But it appears that to do so requires essentially reimplementing a large swath of iso8601 0.1.8 in glance itself. Gross! So, I'd like to suggest that we instead adopt option #1, or alternatively agree that option #2 is no big deal, we can all go back to sleep. Thoughts? ___ 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] excessively difficult to support both iso8601 0.1.4 and 0.1.8 as deps
+1 to option #1 -- dims On Wed, Oct 23, 2013 at 2:34 PM, Mark Washenberger mark.washenber...@markwash.net wrote: Hi folks! In the images api, we depend on iso8601 to parse some dates and times. Recently, since version 0.1.4, python-iso8601 added support for a few more formats, and we finally got some other issues nailed down by 0.1.8. Maybe the fact that these formats weren't supported before was a bug. I don't really know. This puts us in an awkward place, however. With the help of our unit tests, we noticed that, if you switch from 0.1.8 back to 0.1.4 in your deployment, your image api will lose support for certain datetime formats like -MM-DD (where the time part is assumed to be all zeros). This obviously creates a (perhaps small) compatibility concern. Here are our alternatives: 1) Adopt 0.1.8 as the minimum version in openstack-requirements. 2) Do nothing (i.e. let Glance behavior depend on iso8601 in this way, and just fix the tests so they don't care about these extra formats) 3) Make Glance work with the added formats even if 0.1.4 is installed. As of yesterday we were resolved to do #3, trying to be good citizens. But it appears that to do so requires essentially reimplementing a large swath of iso8601 0.1.8 in glance itself. Gross! So, I'd like to suggest that we instead adopt option #1, or alternatively agree that option #2 is no big deal, we can all go back to sleep. Thoughts? ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Davanum Srinivas :: http://davanum.wordpress.com ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] excessively difficult to support both iso8601 0.1.4 and 0.1.8 as deps
On 24 October 2013 07:34, Mark Washenberger mark.washenber...@markwash.net wrote: Hi folks! 1) Adopt 0.1.8 as the minimum version in openstack-requirements. 2) Do nothing (i.e. let Glance behavior depend on iso8601 in this way, and just fix the tests so they don't care about these extra formats) 3) Make Glance work with the added formats even if 0.1.4 is installed. I think we should do (1) because both (2) will permit surprising, nonobvious changes in behaviour and (3) is just nasty engineering. Alternatively, add a (4) which is (2) with whinge on startup if 0.1.4 is installed to make identifying this situation easy. The last thing a new / upgraded deployment wants is something like nova, or a third party API script failing in nonobvious ways with no breadcrumbs to lead them to 'upgrade iso8601' as an answer. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] excessively difficult to support both iso8601 0.1.4 and 0.1.8 as deps
On Wed, Oct 23, 2013 at 2:30 PM, Robert Collins robe...@robertcollins.netwrote: On 24 October 2013 07:34, Mark Washenberger mark.washenber...@markwash.net wrote: Hi folks! 1) Adopt 0.1.8 as the minimum version in openstack-requirements. 2) Do nothing (i.e. let Glance behavior depend on iso8601 in this way, and just fix the tests so they don't care about these extra formats) 3) Make Glance work with the added formats even if 0.1.4 is installed. I think we should do (1) because both (2) will permit surprising, nonobvious changes in behaviour and (3) is just nasty engineering. Alternatively, add a (4) which is (2) with whinge on startup if 0.1.4 is installed to make identifying this situation easy. I'm in favor of (1), unless there's a reason why 0.1.8 not viable for another project or packager, in which case, I've never heard the term whinge before so there should definitely be some of that. The last thing a new / upgraded deployment wants is something like nova, or a third party API script failing in nonobvious ways with no breadcrumbs to lead them to 'upgrade iso8601' as an answer. -Rob -- Robert Collins rbtcoll...@hp.com Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- -Dolph ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
