Re: [openstack-dev] [nova][qa] turbo-hipster seems to be out to lunch
Hey, Yes, sorry, I only discovered this yesterday. I should have updated the wiki page sooner but I've placed some details there now: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/kilo+topic:fix-th,n,z Basically the removal of migrate-flavor-data from master broke turbo-hipster and a few of the patches to make it work just missed the cut-off for kilo. As such they are backported here: https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:stable/kilo+topic:fix-th,n,z Turbo-hipster is now disabled, blocked on getting those in so any help reviewing would be appreciated. Thanks, Josh On Sat, Jul 11, 2015 at 9:09 AM, Matt Riedemann wrote: > There are a lot of failures on nova changes since yesterday and rechecks > today don't seem to be coming back (after rechecking several hours ago). > > Known issues? > > -- > > 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 > __ 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] Hello,everyone
Hi @jiaxi, please see failures caused by the code change in your patch :) Hope that helps. http://logs.openstack.org/12/200512/5/check/gate-tempest-dsvm-large-ops/a2bcf0c/logs/devstacklog.txt.gz#_2015-07-11_16_32_56_433 http://logs.openstack.org/12/200512/5/check/gate-tempest-dsvm-large-ops/a2bcf0c/logs/devstacklog.txt.gz#_2015-07-11_16_33_07_195 Thanks, dims On Sat, Jul 11, 2015 at 7:53 PM, 唐甲希 wrote: > Hello, > in my tox.inienvlist = py27,pep8,docs,genconfig > my tox runs ok. > why so many failure occured in jekins. > Would you please tell me? > > This the first time for me to commit patch. > > > __ > 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 > -- Davanum Srinivas :: https://twitter.com/dims __ 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] Hello,everyone
Hello, in my tox.inienvlist = py27,pep8,docs,genconfig my tox runs ok. why so many failure occured in jekins. Would you please tell me? This the first time for me to commit patch.__ 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] [neutron]
Just wanted to clarify if a normal PCI device (instead of a VF) can be attached to the neutron port when using the SR-IOV networking as described in https://wiki.openstack.org/wiki/SR-IOV-Passthrough-For-Networking. If it is not supported just wondering if there is already a blueprint. Cheers, -Anil __ 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] [all] Setting epoch in setup.cfg??
Ian Cordasco wrote: On 7/10/15, 03:44, "Thierry Carrez" wrote: Joshua Harlow wrote: Hi all, I was thinking about those who are packaging with venvs (and using the version of a project in the venv file name); like what anvil[1] is now capable of (and does this in the gate now[2]) or packaging via rpms (which anvil also does) and they are going to be affected by the version shrinkage that just recently happened this cycle. Soo that got me around to thinking, why aren't all the projects setting an epoch[3] in there setup.cfg (for the ones that had a version shrinkage from 201X.Y to something small) to make it less painful for all these people (and to make it obvious to those reading setup.cfg and looking at the version number that a epoch change just happened)... So I proposed https://review.openstack.org/#/c/200187/ (to cinder) but didn't want to push something similar out everywhere before getting more input, is there any reason we should not do that? Is there a better way to do that? (Or something else I am missing?) As Robert posted on the review: a) pbr doesn't support epochs [yet] Is there a bug for this? I'll be happy to tackle it. b) the release team specifically decided not to epoch things. Also you'll find that the various distros use different epoch values for the same software, because epoch are also used to cover local blunders in packaging and historical artifacts. That is why epochs should be local to each packaging system and specifying it upstream is imho counter-productive. So, unpopular opinion time, but I think we restrict ourselves way too much based on a false notion that the only people who consume OpenStack are consuming it via downstream packages. Joshua has pointed out a very real use case (deploying inside a virtual environment) and there are also cases where people build from source and will be (attempting) to upgrade from 2015.1.x to 11.0.0 or 8.0.0. Even if people only use PyPI as a way of determining version order, using epochs will be significantly better for them. Perhaps I'm too late to the discussion, but it also appears no other opinions were solicited for it, especially not from users or operators. Not IMHO unpopular, in fact I agree with it (but maybe that means I'm unpopular to, ha). IMHO the epoch values 'reasons' as Thierry specified are exactly what we are trying to do, openstack had a 'cover local blunders in packaging and historical artifacts' *moment* by having date based versions and changing it 4+ years into the game and now it needs to correctly handle that 'blunder'. Specifically, I'd like to understand why using a feature of PEP 440 to explicitly indicate a shift in version numbering is "counter-productive". It seems like it would be very productive for people who aren't tightly integrated into the development process. I'd like to know that to; and it IMHO raises another question, why did we go about changing all the versions without epoch support in the first place? Shouldn't we make sure PBR (or other tool) has epoch support, then change the version numbers, not the other way around? (I do not question the reasoning to change the version numbers themselves, I get that, just the ordering of how it was done...) __ 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] [all] Setting epoch in setup.cfg??
On 7/10/15, 03:44, "Thierry Carrez" wrote: >Joshua Harlow wrote: >> Hi all, >> >> I was thinking about those who are packaging with venvs (and using the >> version of a project in the venv file name); like what anvil[1] is now >> capable of (and does this in the gate now[2]) or packaging via rpms >> (which anvil also does) and they are going to be affected by the version >> shrinkage that just recently happened this cycle. >> >> Soo that got me around to thinking, why aren't all the projects >> setting an epoch[3] in there setup.cfg (for the ones that had a version >> shrinkage from 201X.Y to something small) to make it less painful for >> all these people (and to make it obvious to those reading setup.cfg and >> looking at the version number that a epoch change just happened)... >> >> So I proposed https://review.openstack.org/#/c/200187/ (to cinder) but >> didn't want to push something similar out everywhere before getting more >> input, is there any reason we should not do that? Is there a better way >> to do that? (Or something else I am missing?) > >As Robert posted on the review: > >a) pbr doesn't support epochs [yet] Is there a bug for this? I'll be happy to tackle it. >b) the release team specifically decided not to epoch things. > >Also you'll find that the various distros use different epoch values for >the same software, because epoch are also used to cover local blunders >in packaging and historical artifacts. That is why epochs should be >local to each packaging system and specifying it upstream is imho >counter-productive. So, unpopular opinion time, but I think we restrict ourselves way too much based on a false notion that the only people who consume OpenStack are consuming it via downstream packages. Joshua has pointed out a very real use case (deploying inside a virtual environment) and there are also cases where people build from source and will be (attempting) to upgrade from 2015.1.x to 11.0.0 or 8.0.0. Even if people only use PyPI as a way of determining version order, using epochs will be significantly better for them. Perhaps I'm too late to the discussion, but it also appears no other opinions were solicited for it, especially not from users or operators. Specifically, I'd like to understand why using a feature of PEP 440 to explicitly indicate a shift in version numbering is "counter-productive". It seems like it would be very productive for people who aren't tightly integrated into the development process. __ 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] devstack installation problem
On 2015-07-11 18:09:26 + (+), Jeremy Stanley wrote: > On 2015-07-11 22:49:27 +0530 (+0530), Venkateswarlu P wrote: > > After running ./stack.sh > > I am getting the following error. > > > > 015-07-11 17:01:02.188 | error in setup command: 'tests_require' must > > be a string or list of strings containing valid project/version requirement > > specifiers; Expected ',' or end-of-list in > > python-ldap>=2.4;python_version=='2.7' at ;python_version=='2.7' > [...] > > That's an indication something's dragging in an older PBR release > that didn't know not to copy environment markers into tests_require. > Without more of the logs indicating what installed which versions of > PBR and why, it's hard to tell you any more than that. Are you > running from the DevStack master branch or a stable/something > branch? Oh, I also meant to add that if you're re-running stack.sh on a machine where you've already run it before, this is a known issue. See https://launchpad.net/bugs/1468808 for a detailed explanation and current workaround. -- 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] devstack installation problem
On 2015-07-11 22:49:27 +0530 (+0530), Venkateswarlu P wrote: > After running ./stack.sh > I am getting the following error. > > 015-07-11 17:01:02.188 | error in setup command: 'tests_require' must > be a string or list of strings containing valid project/version requirement > specifiers; Expected ',' or end-of-list in > python-ldap>=2.4;python_version=='2.7' at ;python_version=='2.7' [...] That's an indication something's dragging in an older PBR release that didn't know not to copy environment markers into tests_require. Without more of the logs indicating what installed which versions of PBR and why, it's hard to tell you any more than that. Are you running from the DevStack master branch or a stable/something branch? -- 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] [Openstack-operators] [Openstack] Rescinding the M name decision
Thierry, Well put, and interesting. I didn't know about the other cultural concerns around numbers. Most importantly, I think using names for releases is better than numbers, creating a more personal connection to each release. Would hate to see that end. Unfortunately there isn't much we can do to avoid legal concerns. If people are more frustrated by having legal on the backend, it sounds like we have an alternative to return to. If all else fails we could vote on which process was preferred after the M release. Jay On Fri, Jul 10, 2015 at 4:20 AM Thierry Carrez wrote: > Adam Lawson wrote: > > The alternative of course is to just number the releases since names > > ultimately don't mean anything but it seems there are problems with that > > level of simplicity. I personally prefer Tristan's suggestion to keep it > > as simple as possible. In a few years we'll run out of letters anyway. > > Part of the confusion here is that we are not naming "releases". We are > naming release *cycles*. We are giving a name to a period of time, > basically. In that period of time, various version numbers for various > components will be released. Saying "Glance 12.0.0 was released in > OpenStack 13 cycle" is not really helping. > > We won't run out of letters, because the names can cycle back to A > (potentially using a new theme, away from "geographic features near > where the corresponding design summit happened"). > > So while we could technically name a release cycle "14", I feel it's a > bit more difficult to rally around a number than a name. Also, numbers > wouldn't really solve the perceived issues with names: numbers happen to > also be culturally meaningful. You don't have a 13th floor in many US > buildings. In China, building miss the 4th floor instead. 9 is feared in > Japan. And don't talk about 39 to Afghans. > > I think "growing up" is accepting the pain that comes with picking a > good name, rather than sidestepping the issue. > > -- > 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 > __ 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] devstack installation problem
Hi all, After running ./stack.sh I am getting the following error. 015-07-11 17:01:02.188 | error in setup command: 'tests_require' must be a string or list of strings containing valid project/version requirement specifiers; Expected ',' or end-of-list in python-ldap>=2.4;python_version=='2.7' at ;python_version=='2.7' 2015-07-11 17:01:02.188 | 2015-07-11 17:01:02.188 | 2015-07-11 17:01:02.188 | Command "python setup.py egg_info" failed with error code 1 in /home/venkat/codebase/keystone complete description is in the link: http://paste.ubuntu.com/11862076/ Can someone can help? -Venkatesh __ 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] Fix python26 jobs (Re: [all][tests] Fix it friday! [mock failure in CI])
@sdague, @lifeless, requirements-core folks, Looks like we still need this requirements review to merge to help fix a bunch of oslo library failures: https://review.openstack.org/#/c/200344/ Thanks, dims On Fri, Jul 10, 2015 at 6:55 PM, Robert Collins wrote: > On 11 July 2015 at 04:50, Jeremy Stanley wrote: >> On 2015-07-10 18:15:18 +0200 (+0200), Victor Stinner wrote: >>> Is there a plan to use pinned versions on other gates to avoid similar >>> issues in the future? (Decide when we upgrade a dependency) >> >> Sachi has a design underway for applying constraints files to tox >> envs as well: https://review.openstack.org/198620 > > Yup. The requirements-management spec is only partly implemented. tox > is one of the key targets and will be reached in a couple weeks I > hope. > > -Rob > > -- > Robert Collins > Distinguished Technologist > HP Converged Cloud > > __ > 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 -- Davanum Srinivas :: https://twitter.com/dims __ 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] [testing] moving testrepository *outside* the tox venv
On 11 July 2015 at 22:04, Robert Collins wrote: > On 11 July 2015 at 12:38, Matthew Treinish wrote: >> The whole argument for making testr live outside of the venv and being an >> implicit dependency like tox is based around tracking the results between the >> tox venvs right? If we decoupled the database and other result storage from >> testr a bit and made that the external platform independent piece wouldn't we >> maintain everything this thread is trying to address without having the >> issues >> we're seeing now or requiring that everyone change their usage model and >> expectations? > > Huh, no. > > The argument is this: a single testr knows how to run heterogeneous > test backends which may be anywhere in the world, in any language, in > any context. Running it from within one of those contexts is a > seriously poor chicken-and-egg situation which doesn't make any sense. > And the current problem with database compat due to switching out the > python version between invocations is just the tip of the iceberg. Oh, I missed a point: the separation of process via subunit from backend to testr is the heart of the very abstraction of storage etc you're talking about. We can certainly abstract it further (and making the glue-in to HTTP repositories better would need that), but its already there. The issue at hand is that the installation mechanism for testr within OpenStack's context today is inside-out. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud __ 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] [testing] moving testrepository *outside* the tox venv
On 11 July 2015 at 12:38, Matthew Treinish wrote: > On Sat, Jul 11, 2015 at 11:35:16AM +1200, Robert Collins wrote: >> On 9 July 2015 at 10:52, Jeremy Stanley wrote: >> > On 2015-07-09 10:37:17 +1200 (+1200), Robert Collins wrote: >> >> So - I'm looking to: >> >> >> >> A) have a discussion and identify any issues with moving testr out of >> >> the venvs. (Note: this doesn't mean stop using it, just removing it >> >> from test-requirements.txt, in the same way that tox isn't in >> >> test-requirements.txt). >> >> B) Capture that in a spec if its non-trivial. >> >> C) find volunteers to make it happen. >> > >> > D) keep reminding developers to install it on their systems when >> > they ask why they can't run tests >> >> We can make the os-testr which *is* installed in the venv look for >> testr in the PATH and error with a good explanation when its not >> there. > > I guess we could do this, it would be very simple to implement and I'm not > necessarily opposed to it, if that's the direction everyone wants to go. Right > now ostestr only interacts with testr through subprocess, which makes the > implementation of something like this quite simple. > > But, I have 2 concerns right now: First was that my medium/long term my plan > was > to use testr's ui layer to implement ostestr's cli instead of the dirty > subprocess hack I did to get things done faster. Doing this would require > either > breaking out of the venv to get the testr imports (which I wouldn't really > want > to do), require all the tox venv use system site-packages (which I don't think > is really a good idea, and wouldn't solve the python version issue) or making > sure testr was installed in the venv too. Or moving os-testr out of the venv as well. > The other is ostestr isn't universally used right now, only a few projects are > using the ostestr CLI. os-testr is only really being installed in the venv > everywhere because projects use subunit-trace, which is also part of os-testr, > via a pretty_tox.sh script. So to make this a solution we would have to > migrate > everything over to ostestr first. Which wouldn't really be an issue and it's > something I want to do eventually. > > TBH, I tend to agree with everyone else's opinion elsewhere on this thread. > While it might be viewed as an anti-pattern for how testr was originally > intended to be used it doesn't change that this is pretty much the model used > and expected by everything and everyone using testr (or any test runner) in > OpenStack. I would view doing something like this as more of a workaround than > just fixing the storage engine to be compatible with multiple python versions. Wearing my upstream hat, testr is *still* intended to be used differently than OpenStack is doing. Running all the tests for all python versions at once in parallel is the sort of thing testr is aimed at, and thats fairly fundamentally incompatible with running from inside a venv. As is distributed testing across multiple machines. I haven't had time to help OpenStack mature its use of testr until recently, and fixing these issues that are and will have seems pretty important to me. > The whole argument for making testr live outside of the venv and being an > implicit dependency like tox is based around tracking the results between the > tox venvs right? If we decoupled the database and other result storage from > testr a bit and made that the external platform independent piece wouldn't we > maintain everything this thread is trying to address without having the issues > we're seeing now or requiring that everyone change their usage model and > expectations? Huh, no. The argument is this: a single testr knows how to run heterogeneous test backends which may be anywhere in the world, in any language, in any context. Running it from within one of those contexts is a seriously poor chicken-and-egg situation which doesn't make any sense. And the current problem with database compat due to switching out the python version between invocations is just the tip of the iceberg. -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud __ 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] [testing] moving testrepository *outside* the tox venv
On 11 July 2015 at 15:54, Ian Cordasco wrote: > On 7/10/15, 18:34, "Monty Taylor" wrote: > >>On 07/10/2015 07:19 PM, Robert Collins wrote: >>> On 10 July 2015 at 01:59, Morgan Fainberg >>>wrote: Or a database per python major version (or at least gracefully handle the incompatibility). >>> >>> So that would partition the data, and the whole point of test >>> *repository* is that it builds a database across all your tests to >>> answer useful questions. >> >>Totally understand that. >> >>On the other hand ... >> >>a) is that setup/behavior common enough to be more important than: >> >>b) the dbm file format mess is both annoying and confusing >> >>I get the theory of why - but it's also a common thing that provides rage. > > Just as an example, I went to fix a pypy error and was receiving an > exception about not being able to import _bsddb. The fix? Remove > .testrepository. I understand testrepository is meant to be a metatool, > but it provides very bizarre problems in some cases. I understand why we > use it, but the situation really need to improve the situation. Fixing that is why I'm proposing this change ;). -Rob -- Robert Collins Distinguished Technologist HP Converged Cloud __ 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] [manila] share dismantling policies
Just a correction of what I stated earlier... - Original Message - > From: "Csaba Henk" > To: "OpenStack Development Mailing List (not for usage questions)" > > Sent: Thursday, July 9, 2015 3:13:29 PM > Subject: Re: [openstack-dev] [manila] share dismantling policies ... > Sure, Manila cannot force the users to unmount the volume, but it *can* > render the mount unusable (ending up in a state whereby all system calls > to the mount fail). That's what generic driver -- and any driver with > kNFS as export mechanism -- does (disruptive access control). However, as > we found out, a user mount with glusterfs_native will remain usable after > access to share is revoked (non-disruptive access control). So ATM there is > no > uniformity in access control disruptiveness across the drivers. With respect to gluster_native: "a user mount with glusterfs_native will remain usable after access to share is revoked" is not true. glusterfs_native does comply with the access deny requirements as laid down by Ben in another mail of this thread[1]. The correct statement is: we were experimenting with some optimizations for glusterfs_native through which we ended up with a modification that had the effect of leaving user mounts with glusterfs_native usable after access to share was revoked. TL;DR: glusterfs_native is OK. [1] http://lists.openstack.org/pipermail/openstack-dev/2015-July/069109.html Csaba __ 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] [Openstack-operators] [Openstack] Rescinding the M name decision
+1 for this On Fri, Jul 10, 2015 at 5:20 PM Thierry Carrez wrote: > Adam Lawson wrote: > > The alternative of course is to just number the releases since names > > ultimately don't mean anything but it seems there are problems with that > > level of simplicity. I personally prefer Tristan's suggestion to keep it > > as simple as possible. In a few years we'll run out of letters anyway. > > Part of the confusion here is that we are not naming "releases". We are > naming release *cycles*. We are giving a name to a period of time, > basically. In that period of time, various version numbers for various > components will be released. Saying "Glance 12.0.0 was released in > OpenStack 13 cycle" is not really helping. > > We won't run out of letters, because the names can cycle back to A > (potentially using a new theme, away from "geographic features near > where the corresponding design summit happened"). > > So while we could technically name a release cycle "14", I feel it's a > bit more difficult to rally around a number than a name. Also, numbers > wouldn't really solve the perceived issues with names: numbers happen to > also be culturally meaningful. You don't have a 13th floor in many US > buildings. In China, building miss the 4th floor instead. 9 is feared in > Japan. And don't talk about 39 to Afghans. > > I think "growing up" is accepting the pain that comes with picking a > good name, rather than sidestepping the issue. > > -- > 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 > __ 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] [Openstack-operators] [Openstack] Rescinding the M name decision
+1 for this. On Fri, Jul 10, 2015 at 5:20 PM Thierry Carrez wrote: > Adam Lawson wrote: > > The alternative of course is to just number the releases since names > > ultimately don't mean anything but it seems there are problems with that > > level of simplicity. I personally prefer Tristan's suggestion to keep it > > as simple as possible. In a few years we'll run out of letters anyway. > > Part of the confusion here is that we are not naming "releases". We are > naming release *cycles*. We are giving a name to a period of time, > basically. In that period of time, various version numbers for various > components will be released. Saying "Glance 12.0.0 was released in > OpenStack 13 cycle" is not really helping. > > We won't run out of letters, because the names can cycle back to A > (potentially using a new theme, away from "geographic features near > where the corresponding design summit happened"). > > So while we could technically name a release cycle "14", I feel it's a > bit more difficult to rally around a number than a name. Also, numbers > wouldn't really solve the perceived issues with names: numbers happen to > also be culturally meaningful. You don't have a 13th floor in many US > buildings. In China, building miss the 4th floor instead. 9 is feared in > Japan. And don't talk about 39 to Afghans. > > I think "growing up" is accepting the pain that comes with picking a > good name, rather than sidestepping the issue. > > -- > 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 > __ 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] [Openstack-operators] [Openstack] Rescinding the M name decision
+1 from me as well. 2015년 7월 10일 (금) 18:27, Neil Jerram 님이 작성: > On 10/07/15 10:19, Thierry Carrez wrote: > > > > Part of the confusion here is that we are not naming "releases". We are > > naming release *cycles*. We are giving a name to a period of time, > > basically. In that period of time, various version numbers for various > > components will be released. Saying "Glance 12.0.0 was released in > > OpenStack 13 cycle" is not really helping. > > > > We won't run out of letters, because the names can cycle back to A > > (potentially using a new theme, away from "geographic features near > > where the corresponding design summit happened"). > > > > So while we could technically name a release cycle "14", I feel it's a > > bit more difficult to rally around a number than a name. Also, numbers > > wouldn't really solve the perceived issues with names: numbers happen to > > also be culturally meaningful. You don't have a 13th floor in many US > > buildings. In China, building miss the 4th floor instead. 9 is feared in > > Japan. And don't talk about 39 to Afghans. > > > > I think "growing up" is accepting the pain that comes with picking a > > good name, rather than sidestepping the issue. > > +1 to all that. Nicely put. > > Neil > > ___ > OpenStack-operators mailing list > openstack-operat...@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators > __ 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
