Re: [openstack-dev] [all] [tc] "No Open Core" in 2016
I think that will become a clear definition but not a strict one :) In Huawei, each release of product will be evaluated by availability, security, usability, maintainability and something else. Those design ideas looks difficult but could drive projects stronger. On Sat, Feb 6, 2016 at 12:49 AM, Russell Bryant wrote: > On 02/05/2016 05:57 AM, Thierry Carrez wrote: >> Hi everyone, >> >> Even before OpenStack had a name, our "Four Opens" principles were >> created to define how we would operate as a community. The first open, >> "Open Source", added the following precision: "We do not produce 'open >> core' software". What does this mean in 2016 ? >> >> Back in 2010 when OpenStack was started, this was a key difference with >> the other open source cloud platform (Eucalyptus) which was following an >> Open Core strategy with a crippled community edition and an "enterprise >> version". OpenStack was then the property of a single entity >> (Rackspace), so giving strong signals that we would never follow such a >> strategy was essential to form a real community. >> >> Fast-forward today, the open source project is driven by a non-profit >> independent Foundation, which could not even do an "enterprise edition" >> if it wanted to. However, member companies build "enterprise products" >> on top of the Apache-licensed upstream project. And we have drivers that >> expose functionality in proprietary components. So what does it mean to >> "not do open core" in 2016 ? What is acceptable and what's not ? It is >> time for us to refresh this. > > Nice summary. I agree that some clarification would be helpful given to > match our current reality. > >> My personal take on that is that we can draw a line in the sand for what >> is acceptable as an official project in the upstream OpenStack open >> source effort. It should have a fully-functional, production-grade open >> source implementation. If you need proprietary software or a commercial >> entity to fully use the functionality of a project or getting serious >> about it, then it should not be accepted in OpenStack as an official >> project. It can still live as a non-official project and even be hosted >> under OpenStack infrastructure, but it should not be part of >> "OpenStack". That is how I would interpret "no open core" in OpenStack >> 2016. >> >> Of course, the devil is in the details, especially around what I mean by >> "fully-functional" and "production-grade". Is it just an API/stability >> thing, or does performance/scalability come into account ? There will >> always be some subjectivity there, but I think it's a good place to start. >> >> Comments ? >> > > I agree with your take. I'm not too worried about coming up with a > strict definition for what a reasonable open source backend is. We can > throw in some desirable traits like you have done, and then leave it to > the TC to evaluate. I think that's a reasonable part of the TC's job. > > -- > Russell Bryant > > __ > 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 -- Gareth (Kun Huang) Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball OpenStack contributor, kun_huang@freenode My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me and I'll donate $1 or ￥1 to an open organization you specify. __ 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] [neutron][neutron-*] Notice! pylint breakage
nstraints style job >>> and tox.ini should also use the same target, instead of pep8. Like neutron, >>> kilo and juno branches need to pin astroid to 1.3.8. >>> >>> neutron-vpnaas should also pin pylint to 1.4.4 in test-requirements.txt, >>> to prevent it from floating to 1.5.0. >>> >>> All repos will need a plan for updating code to conform to pylint 1.5.0, >>> if/when we upgrade to this. >>> >>> Note: I have not looked at neutron-fwaas, so we need to confirm the above >>> issue is present, but it likely is (even if there is not a current pylint >>> failure). >>> >>> One concern I have, that infra hasn't figured out how it can be >>> addressed, is how we'll update to pylint 1.5.0. If were are using >>> pep8-constraints, the constraints file is in a different repo. Updating, to >>> say, pylint 1.5.0 and astroid 1.4.1, would cause breakage until both the >>> neutron* repos and requirements repo are updated. This is complicated with >>> backward incompatible changes needed. >>> >>> Thanks to blogan, ZZelle, fungi, anteaya, lifeless, ajmiller and others >>> for helping investigate and come up with the approach on this issue! >>> >>> Regards, >>> >>> Paul Michali (pc_m) >>> >>> >> __ >> 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 > -- Gareth (Kun Huang) Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball OpenStack contributor, kun_huang@freenode My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me and I'll donate $1 or ￥1 to an open organization you specify. __ 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] [neutron] questions about uni test
It creates and cleans the tables in memory? On Tue, Jan 26, 2016 at 12:56 AM, Assaf Muller wrote: > On Mon, Jan 25, 2016 at 10:05 AM, Gareth wrote: >> Hey neutron guys >> >> What will happen if I remove this line[0]? >> >> When running unit test, do we create tables in real database? >> >> [0] >> https://github.com/openstack/neutron/blob/master/neutron/tests/unit/testlib_api.py#L78 > > That line has nothing to do with what database backend you use (SQLite > or mysql or whatever), it's used to clear the contents of the tables > so the next test starts with a clean DB. > >> >> -- >> Gareth (Kun Huang) >> >> Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball >> OpenStack contributor, kun_huang@freenode >> My promise: if you find any spelling or grammar mistakes in my email >> from Mar 1 2013, notify me >> and I'll donate $1 or ￥1 to an open organization you specify. >> >> __ >> 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 -- Gareth (Kun Huang) Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball OpenStack contributor, kun_huang@freenode My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me and I'll donate $1 or ￥1 to an open organization you specify. __ 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] questions about uni test
Hey neutron guys What will happen if I remove this line[0]? When running unit test, do we create tables in real database? [0] https://github.com/openstack/neutron/blob/master/neutron/tests/unit/testlib_api.py#L78 -- Gareth (Kun Huang) Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball OpenStack contributor, kun_huang@freenode My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me and I'll donate $1 or ￥1 to an open organization you specify. __ 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] [kolla] Nominating Lei Zhang (Jeffrey Zhang in English) - jeffrey4l on irc
+1 to lei :) On Wed, Jan 20, 2016 at 12:57 AM, Swapnil Kulkarni wrote: > On Tue, Jan 19, 2016 at 1:56 PM, Steven Dake (stdake) > wrote: >> >> Hi folks, >> >> I would like to propose Lei Zhang for our core reviewer team. Count this >> proposal as a +1 vote from me. Lei has done a fantastic job in his reviews >> over the last 6 weeks and has managed to produce some really nice >> implementation work along the way. He participates in IRC regularly, and >> has a commitment from his management team at his employer to work full time >> 100% committed to Kolla for the foreseeable future (although things can >> always change in the future :) >> >> Please vote +1 if you approve of Lei for core reviewer, or –1 if wish to >> veto his nomination. Remember just one –1 vote is a complete veto, so if >> your on the fence, another option is to abstain from voting. >> >> I would like to change from our 3 votes required, as our core team has >> grown, to requiring a simple majority of core reviewers with no veto votes. >> As we have 9 core reviewers, this means Lei requires 4 more +1 votes with >> no veto vote in the voting window to join the core reviewer team. >> >> I will leave the voting open for 1 week as is the case with our other core >> reviewer nominations until January 26th. If the vote is unanimous or there >> is a veto vote before January 26th I will close voting. I'll make >> appropriate changes to gerrit permissions if Lei is voted into the core >> reviewer team. >> >> Thank you for your time in evaluating Lei for the core review team. >> >> Regards >> -steve >> >> >> __ >> 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 >> > > +1 :) > > > __ > 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 > -- Gareth (Kun Huang) Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball OpenStack contributor, kun_huang@freenode My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me and I'll donate $1 or ￥1 to an open organization you specify. __ 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] [OpenStack-dev][Neutron] Is there a tool of generating network topology?
Hi, networking guys, For example, we could use it to generate a png file or print ascii in command line. Is there something like this? -- Gareth Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball OpenStack contributor, kun_huang@freenode My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me and I'll donate $1 or ￥1 to an open organization you specify. __ 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] [Neutron] Mid-cycle meetup for Mitaka
Guys, Is there a conclusion now? What's the schedule of Neutron Mid-cycle? On Thu, Nov 5, 2015 at 9:31 PM, Gary Kotton wrote: > Hi, > In Nova the new black is the os-vif-lib > (https://etherpad.openstack.org/p/mitaka-nova-os-vif-lib). It may be > worthwhile seeing if we can maybe do something at the same time with the > nova crew and then bash out the dirty details here. It would be far easier > if everyone was in the same room. > Just and idea. > Thanks > Gary > > From: "John Davidge (jodavidg)" > Reply-To: OpenStack List > Date: Thursday, November 5, 2015 at 2:08 PM > To: OpenStack List > Subject: Re: [openstack-dev] [Neutron] Mid-cycle meetup for Mitaka > > ++ > > Sounds very sensible to me! > > John > > From: "Armando M." > Reply-To: "OpenStack Development Mailing List (not for usage questions)" > > Date: Wednesday, 4 November 2015 21:23 > To: "OpenStack Development Mailing List (not for usage questions)" > > Subject: [openstack-dev] [Neutron] Mid-cycle meetup for Mitaka > > Hi folks, > > After some consideration, I am proposing a change for the Mitaka release > cycle in relation to the mid-cycle meetup event. > > My proposal is to defer the gathering to later in the release cycle [1], and > assess whether we have it or not based on the course of events in the cycle. > If we feel that a last push closer to the end will help us hit some critical > targets, then I am all in for arranging it. > > Based on our latest experiences, I have not seen a strong correlation > between progress made during the cycle and progress made during the meetup, > so we might as well save us the trouble of travelling close to Christmas. > > I'd like to thank Kyle, Miguel Lavalle and Doug for looking into the > logistics. We may still need their services later in the new year, but as of > now all I can say is: > > Happy (distributed) hacking! > > Cheers, > Armando > > [1] https://wiki.openstack.org/wiki/Mitaka_Release_Schedule > > __ > 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 > -- Gareth Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball OpenStack contributor, kun_huang@freenode My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me and I'll donate $1 or ￥1 to an open organization you specify. __ 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] How to add a periodic check for typos?
Just talking about the idea of auto-spelling-fix. My example patch https://review.openstack.org/#/c/247261/ doesn't work. Topy fixes something and break others. So it is just okay to do auto-spelling-check now, not fix :( On Fri, Nov 20, 2015 at 6:31 AM, Matt Riedemann wrote: > > > On 11/18/2015 8:00 PM, Gareth wrote: >> >> Hi stacker, >> >> We could use some 3rd tools like topy: >> pip install topy >> topy -a >> git commit & git review >> >> Here is an example: https://review.openstack.org/#/c/247261/ >> >> Could we have a periodic job like Jenkins users updating our >> requirement.txt? >> > > Are you asking for all projects or just a specific project you work on and > you forgot to tag the subject line? > > I wouldn't have a bot doing this, if I were going to do it (which I wouldn't > for nova). You could have it built into your pep8 job, or a separate job > that is voting on your project, if you really care about spelling. > > -- > > 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 -- Gareth Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball OpenStack contributor, kun_huang@freenode My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me and I'll donate $1 or ￥1 to an open organization you specify. __ 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] How to add a periodic check for typos?
Hi stacker, We could use some 3rd tools like topy: pip install topy topy -a git commit & git review Here is an example: https://review.openstack.org/#/c/247261/ Could we have a periodic job like Jenkins users updating our requirement.txt? -- Gareth Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball OpenStack contributor, kun_huang@freenode My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me and I'll donate $1 or ￥1 to an open organization you specify. __ 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] [kuryr] gerrit/git review problem error code 10061
TCP error code 10061: No connection could be made because the target machine actively refused it. find this from google, maybe helpful On Mon, Nov 9, 2015 at 10:42 AM, Iury Gregory wrote: > Not sure if this can help you, > Verify if your public key is in your gerrit account. > > Another thing you can try is to update your openstack account to foundation > member, I had a similar error a while a go. > > > 2015-11-08 23:13 GMT-03:00 Baohua Yang : >> >> Hi, >>Anyone recently meet such problem after cloning the latest code from >> kuryr? >>Try proxy also, but not solved. >> >> $ git review -s >> Problem running 'git remote update gerrit' >> Fetching gerrit >> FATAL: Unable to connect to relay host, errno=10061 >> ssh_exchange_identification: Connection closed by remote host >> fatal: Could not read from remote repository. >> >> Please make sure you have the correct access rights >> and the repository exists. >> error: Could not fetch gerrit >> Traceback (most recent call last): >> File "d:\Python27\lib\runpy.py", line 162, in _run_module_as_main >> "__main__", fname, loader, pkg_name) >> File "d:\Python27\lib\runpy.py", line 72, in _run_code >> exec code in run_globals >> File "d:\Python27\Scripts\git-review.exe\__main__.py", line 9, in >> >> File "d:\Python27\lib\site-packages\git_review\cmd.py", line 1202, in >> main >> set_hooks_commit_msg(remote, hook_file) >> File "d:\Python27\lib\site-packages\git_review\cmd.py", line 283, in >> set_hooks_commit_msg >> run_command_exc(CannotInstallHook, *cmd) >> File "d:\Python27\lib\site-packages\git_review\cmd.py", line 152, in >> run_command_exc >> raise klazz(rc, output, argv, env) >> git_review.cmd.CannotInstallHook: Problems encountered installing >> commit-msg hook >> The following command failed with exit code 1 >> "scp -P29418 yangbao...@review.openstack.org:hooks/commit-msg >> .git\hooks\commit-msg" >> --- >> FATAL: Unable to connect to relay host, errno=10061 >> ssh_exchange_identification: Connection closed by remote host >> >> >> $ git remote show origin >> * remote origin >> Fetch URL: git://git.openstack.org/openstack/kuryr >> Push URL: git://git.openstack.org/openstack/kuryr >> HEAD branch: master >> Remote branch: >> master tracked >> Local branch configured for 'git pull': >> master merges with remote master >> Local ref configured for 'git push': >> master pushes to master (local out of date) >> >> >>Thanks! >> >> -- >> Best wishes! >> Baohua >> >> __ >> 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 >> > > > > -- > > ~ > Att[]'s > Iury Gregory Melo Ferreira > Master student in Computer Science at UFCG > E-mail: iurygreg...@gmail.com > ~ > > __ > 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 > -- Gareth Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball OpenStack contributor, kun_huang@freenode My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me and I'll donate $1 or ￥1 to an open organization you specify. __ 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] Proposal to add Alex Xu to nova-core
+11 Alex, good news for you ! On Sat, Nov 7, 2015 at 12:36 AM, Daniel P. Berrange wrote: > On Fri, Nov 06, 2015 at 03:32:04PM +, John Garbutt wrote: >> Hi, >> >> I propose we add Alex Xu[1] to nova-core. >> >> Over the last few cycles he has consistently been doing great work, >> including some quality reviews, particularly around the API. >> >> Please respond with comments, +1s, or objections within one week. > > +1 from me, the tireless API patch & review work has been very helpful > to our efforts in this area. > > Regards, > Daniel > -- > |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| > > __ > 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 -- Gareth Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball OpenStack contributor, kun_huang@freenode My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me and I'll donate $1 or ￥1 to an open organization you specify. __ 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] [infra][dsvm] openstack packages pre-installed dsvm node?
Hey When choosing nodes to run a gate job, is there a liberty-trusty node? The liberty core services is installed and well setup. It is helpful for development on non-core projects and saves much time. -- Gareth Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball OpenStack contributor, kun_huang@freenode My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me and I'll donate $1 or ￥1 to an open organization you specify. __ 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] status of the live upgrade session
Hey guys, In this summary https://wiki.openstack.org/wiki/Design_Summit/Mitaka/Etherpads, there is a live upgrade session. But the linked the etherpad is empty: https://etherpad.openstack.org/p/mitaka-crossproject-upgrades . So what's the status or conclusion of this session? -- Gareth Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball OpenStack contributor, kun_huang@freenode My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me and I'll donate $1 or ￥1 to an open organization you specify. __ 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] [oslo.db][sqlalchemy] rollback after commit
Hi DB experts, I'm using mysql now and have general log like: 1397 Query SELECT 1 1397 Query SELECT 1397 Query UPDATE 1397 Query COMMIT 1397 Query ROLLBACK I found there always is 'SELECT 1' before real queries and 'COMMIT' and 'ROLLBACK' after. I know 'SELECT 1' is the lowest cost for check db's availability and 'COMMIT' is for persistence. But why is a 'ROLLBACK' here? Is this 'ROLLBACK' the behaviour of oslo.db or sqlchemy? -- Gareth Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball OpenStack contributor, kun_huang@freenode My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me and I'll donate $1 or ￥1 to an open organization you specify. __ 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] [requirements] dependencies problem on different release
Btw, it's not a dependency conflict issue. If we install python dependencies via pip, it's okay to be with foo>=1.5.0 in the past, but not now maybe (oslo.util -> oslo_util breaks nearly everything). Maybe we need a requirements.txt as release like: foo==1.5.0 bar==2.1.0 not for>=1.5.0 bar>=2.0.0 On Thu, Aug 27, 2015 at 3:32 AM, Robert Collins wrote: > On 27 August 2015 at 02:00, Gareth wrote: > > Hey guys, > > > > I have a question about dependencies. There is an example: > > > > On 2014.1, project A is released with its dependency in requirements.txt > > which contains: > > > > foo>=1.5.0 > > bar>=2.0.0,<2.2.0 > > > > and half a year later, the requirements.txt changes to: > > > > foo>=1.7.0 > > bar>=2.1.0,<2.2.0 > > > > It looks fine, but potential change would be upstream version of package > foo > > and bar become 2.0.0 and 3.0.0 (major version upgrade means there are > > incompatible changes). > > > > For bar, there will be no problems, because "<2.2.0" limit the version > from > > major version changes. But with 2.0.0 foo, it will break the > installation of > > 2014.1 A, because current development can't predict every incompatible > > changes in the future. > > Correct. But actually bar is a real problem for single-instance binary > distributors - like Debian family distributions - where only one > version of bar can be in the archive at once. For those distributions, > when bar 3 comes out, they cannot add it to the archive until a new > release of project A happens (or they break project A). They also > can't add anything to the archive that depends on bar > 2.2.0, because > they can't add bar. So it leads to gridlock. We are now avoiding > adding and won't except in exceptional circumstances, such defensive > upper bounds to OpenStack's requirements. When we /know/ that the > thing is broken we may - if we can't get it fixed. > > > A real example is to enable Rally for OpenStack Juno. Rally doesn't > support > > old release officially but I could checkout its codes to the Juno release > > date which make both codes match. However even if I use the old > > requirements.txt to install dependencies, there must be many packages are > > installed as upstream versions and some of them breaks. An ugly way is to > > copy pip list from old Juno environment and install those properly. I > hope > > there are better ways to do this work. Anyone has smart ideas? > > As Boris says, use virtualenvs. They'll solve 90% of the pain. > > -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 > -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* __ 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] [requirements] dependencies problem on different release
Hey guys, I have a question about dependencies. There is an example: On 2014.1, project A is released with its dependency in requirements.txt which contains: foo>=1.5.0 bar>=2.0.0,<2.2.0 and half a year later, the requirements.txt changes to: foo>=1.7.0 bar>=2.1.0,<2.2.0 It looks fine, but potential change would be upstream version of package foo and bar become 2.0.0 and 3.0.0 (major version upgrade means there are incompatible changes). For bar, there will be no problems, because "<2.2.0" limit the version from major version changes. But with 2.0.0 foo, it will break the installation of 2014.1 A, because current development can't predict every incompatible changes in the future. A real example is to enable Rally for OpenStack Juno. Rally doesn't support old release officially but I could checkout its codes to the Juno release date which make both codes match. However even if I use the old requirements.txt to install dependencies, there must be many packages are installed as upstream versions and some of them breaks. An ugly way is to copy pip list from old Juno environment and install those properly. I hope there are better ways to do this work. Anyone has smart ideas? -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* __ 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] [Neutron] neutron-lbaas code structure problem
Thanks Brandon, got it. It is easy to understand :) On Sat, Aug 15, 2015 at 2:07 AM, Brandon Logan wrote: > Hi Gareth, > > The reason for this is because lbaas v1 is in the > services/loadbalancer/drivers path. This path was maintained from when > neutron-lbaas was just another directory in the neutron repo. Once we > moved to neutron-lbaas as its own repo and going forward with lbaas v2, the > decision was made to not maintain that same path for v2. There's no reason > to keep that path for v2 as v1 will be deprecated and eventually removed > and we did not want to be stuck with that path. Eventually the plugin.py > module will have to be moved to the root directory as well from > services/loadbalancer but thats a minor change. > > > Thanks, > > Brandon > -- > *From:* Gareth > *Sent:* Thursday, August 13, 2015 9:38 PM > *To:* OpenStack Development Mailing List > *Subject:* [openstack-dev] [Neutron] neutron-lbaas code structure problem > > Dear neutron guys. > > [0] > https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas/drivers > [1] > https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas/services/loadbalancer/drivers > > the codes under these two paths are 'same' (implement same things with v1 > and v2), but why use two different code paths here? > > -- > Gareth > > *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* > *OpenStack contributor, kun_huang@freenode* > *My promise: if you find any spelling or grammar mistakes in my email from > Mar 1 2013, notify me * > *and I'll donate $1 or ￥1 to an open organization you specify.* > > __ > 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 > > -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* __ 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] neutron-lbaas code structure problem
Dear neutron guys. [0] https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas/drivers [1] https://github.com/openstack/neutron-lbaas/tree/master/neutron_lbaas/services/loadbalancer/drivers the codes under these two paths are 'same' (implement same things with v1 and v2), but why use two different code paths here? -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* __ 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][infra] CI System is broken
Could this issue be fixed today? Btw, is it possible to design a special mode for gate/zuul? If ops switch to that mode, all new gerrit event can't trigger any jenkins job. On Thu, Jul 30, 2015 at 9:13 PM, Jeremy Stanley wrote: > On 2015-07-30 10:19:20 +0200 (+0200), Andreas Jaeger wrote: > > Joshua just restarted Zuul and is currently requeueing the jobs > > that were in the system. > [...] > > Also we've got some additional debugging added prior to this most > recent restart which should assist in narrowing down the cause > if/when it happens again. > -- > 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 > -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* __ 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] [tox/pep8] different result between running tox and pep8
Hi guys My problem looks simple: Running "tox -e pep8", the result says ok, not pep8 mistakes. Running "pep8 .", a lot of pep8 mistkes come out. But in your project's tox.ini, there isn't such a long ignore list. So what makes this difference happen? Kun __ 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] [oslo] oslo releasing is noisy...
Thanks ttx. That's the solution we need (anything not perfect would bother someone and help others at same time, so we need solve the problem, not to give up any side of people). I prefer to use openstack-dev mailing list for development discussion only. On Wed, Jun 10, 2015 at 12:33 AM Thierry Carrez wrote: > Victor Stinner wrote: > > Le 09/06/2015 17:50, Jordan Pittier a écrit : > >> Hi, > >> This has already been discussed here: > >> > http://lists.openstack.org/pipermail/openstack-dev/2015-March/059020.html > >> > >> You can always create a filter to match these emails. > > > > Well, I'm doing "the opposite": I want to read (all) Oslo emails, so I > > move them into a dedicated folder in my mail box ;-) > > > > I like these release emails to see what changes, especially because Oslo > > releases break things sometimes ;-) It's better to stay tuned. > > We are currently exploring the option to repurpose the > openstack-announce ML to be the extensive record of release > announcements. It's part of a larger plan to streamline library > releases, about which Doug should start a discussion pretty soon now. > > If we did that, we'd likely post to openstack-announce with Reply-To set > to openstack-dev (so that any discussion on the recent release would > happen on the open list). > > -- > 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] [infra] how to trigger a set of jenkins jobs
Hi infra team, The origin concept of jenkins is "one trigger one job". For example, the job "neutron-unit-test-py27" could respond a new change set from neutron upstream. But the truth is that a gerrit event trigger a set of jenkins jobs: py27-unittest, pep8-check, and many dsvm jobs... How can I configure my jenkins like this? -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* __ 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] IRC meetings agenda is now driven from Gerrit !
As we could generate data dynamically, it is possible to develop a web UI for it which shows real-time and readable scheduler table, provides download link of custom meetings group, etc. On Sat, May 30, 2015 at 2:51 PM yatin kumbhare wrote: > Thank you, Thierry & Tony > > --Daniel > So could we publish the individual ical files for each meeting too. > That way I could simply add nova.ical to my calendar and avoid other > 80 openstack meetings appearing in my schedule. > > this answers my second questions. > > Regards, > Yatin > > On Sat, May 30, 2015 at 3:30 AM, Tony Breeds > wrote: > >> On Fri, May 29, 2015 at 10:42:58AM +0530, yatin kumbhare wrote: >> > Great Work! >> > >> > "New meetings or meeting changes would be proposed in Gerrit, and >> > check/gate tests would make sure that there aren't any conflict." >> > >> > --Will this tell upfront, that in any given day of week, which are all >> > meeting slots (time and irc meeting channels) are available? this could >> > bring down no. patchset and gate tests failures. may be :) >> >> That'd be an interetsing feature but in reality it's trivial to run >> yaml2ical >> locally against the irc-meetings repo (which you already need to propose >> the >> change). Or you can just push the review see if it fails. >> >> > There's some meeting with at weekly interval of 2, I assume we would get >> > iCal by SUMMARY? >> >> I'm not sure I follow what you're asking here. >> >> Yours Tony. >> >> __ >> 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] [nova] Should we add instance action event to live migration?
+1 for the point that the live mirgration should be transparent to *end users* On Wed, Jun 3, 2015 at 4:43 PM Rui Chen wrote: > Hi all: > > We have the instance action and action event for most of the instance > operations, > > exclude: live-migration. In the current master code, when we do > live-migration, the > > instance action is recorded, but the action event for live-migration is > lost. I'm not sure that > > it's a bug or design behavior, so I want to get more feedback in mail list. > > I found the patch https://review.openstack.org/#/c/95440/ > > It's add the live migration action, but no event. It looks weird. > > I think there are two improvement we can do > > [1]: add the live migration event, keep consistence with other > instance operations. > > [2]: remove the live migration action in order to make the operation > transparent to end-users, like Andrew say in the patch comments. > > Which way you like? please let me know, thanks. > __ > 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] error codes design conclusion?
Thanks Rochelle, looking forward to your next version On Wed, Jun 3, 2015 at 6:27 AM, Rochelle Grober wrote: > Spec is in the works but needs to be reworked a bit more. It’s under > Openstack-specs. I’m revamping it, but I’m taking vacation until Monday, > so you won’t see the new patch until at least next week. You are welcome > to comment on the current version, though: > https://review.openstack.org/#/c/172552/ > > > > Need to clean up formatting, add some history, better examples, etc. Any > useful suggestions to address current or your issues extremely welcome. > > > > --Rocky > > > > *From:* Gareth [mailto:academicgar...@gmail.com] > *Sent:* Monday, June 01, 2015 18:17 > *To:* OpenStack Development Mailing List > *Subject:* [openstack-dev] [all] error codes design conclusion? > > > > Hey guys, > > > > I remember there was a session in design summit talking about openstack > error codes. What's the current status? or is there any conclusion yet? > > > > Kun > > __ > 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 > > -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* __ 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] [all] error codes design conclusion?
Hey guys, I remember there was a session in design summit talking about openstack error codes. What's the current status? or is there any conclusion yet? Kun __ 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] [glance] missing implementation on glance basic quota
Hi glance guys There is a bp[0] said it would implement two basic quota usage: a, the number of image stored b, the amount of storage in occupied by a set of image However, only b is implemented in the patch[1], and a is still missing in current glance. [0] https://blueprints.launchpad.net/glance/+spec/glance-basic-quotas [1] https://review.openstack.org/#/c/37993/18 -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* __ 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] missing implementation on glance basic quota
Hi glance guys There is a bp[0] said it would implement two basic quota usage: a, the number of image stored b, the amount of storage in occupied by a set of image However, only b is implemented in the patch[1], and a is still missing in current glance. [0] https://blueprints.launchpad.net/glance/+spec/glance-basic-quotas [1] https://review.openstack.org/#/c/37993/18 __ 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] [Rally] Improve review process
it's super cool!! On Wed, May 6, 2015 at 9:41 AM Yingjun Li wrote: > Nice! > > On May 5, 2015, at 8:11 PM, Roman Vasilets wrote: > > Hi, Rally Team. > I have created Rally Gerrit dashboard that organized patches in groups: > Critical for next release, Waiting for final approve, Bug fixes, Proposed > specs, Important patches, Ready for review, Has -1 but passed tests. Please > use link http://goo.gl/iRxA5t for you comfortable. Patch is here > https://review.openstack.org/#/c/179610/ It was made by > gerrit-dash-creator. > First group are the patches that are needed to merge to the nearest > release. Content of the next three groups is obvious from the titles. > Important patches - its just patches chosen(starred) by Boris Pavlovic or > Mikhail Dubov. Ready for review - patches that are waiting for attention. > And the last section - its patches with -1 mark but they passed CI. > > Roman Vasilets, Mirantis Inc. > Intern Software Engineer > __ > 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] [Ceilometer] proposal to add ZhiQiang Fan to Ceilometer core
Super good news!!! - Kun Huang (Gareth) -Original Message- From: gordon chung [mailto:g...@live.ca] Sent: Thursday, April 02, 2015 8:47 AM To: OpenStack Development Mailing List not for usage questions Subject: Re: [openstack-dev] [Ceilometer] proposal to add ZhiQiang Fan to Ceilometer core for those who i have/haven't already discuss this nomination with already, please vote here: https://review.openstack.org/#/c/169959/ for those who can't comment in gerrit, just holler something in #openstack-ceilometer. cheers, gord > Date: Thu, 2 Apr 2015 09:34:12 +1300 > From: feil...@catalyst.net.nz > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Ceilometer] proposal to add ZhiQiang Fan > to Ceilometer core > > +1 if this can be counted :) > > On 02/04/15 06:18, gordon chung wrote: >> hi, >> >> i'd like to nominate ZhiQiang Fan to the Ceilometer core team. he has been a >> leading reviewer in Ceilometer and consistently gives insightful reviews. he >> also contributes patches and helps triage bugs. >> >> reviews: >> https://review.openstack.org/#/q/reviewer:%22ZhiQiang+Fan%22+project: >> openstack/ceilometer,n,z >> >> patches: >> https://review.openstack.org/#/q/owner:%22ZhiQiang+Fan%22+project:ope >> nstack/ceilometer,n,z >> >> >> cheers, >> gord >> >> ps. this isn't an april fool's joke as he initially thought when i asked him. >> _ >> _ 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 > > -- > Cheers & Best regards, > Fei Long Wang (王飞龙) > -- > > Senior Cloud Software Engineer > Tel: +64-48032246 > Email: flw...@catalyst.net.nz > Catalyst IT Limited > Level 6, Catalyst House, 150 Willis Street, Wellington > -- > > > > __ > 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] [nova] is there a way to simulate thousands or millions of compute nodes?
@Michael Okay, focusing on 'thousands' now, I know 'millions' is not good metaphor here. I also know 'cells' functionality is nova's solution for large scale deployment. But it also makes sense to find and re-produce large scale problems in relatively small scale deployment. @Sandy All-in-all, I think you'd be better off load testing each piece independently on a fixed hardware platform and faking out all the incoming/outgoing services I understand and this is what I want to know. Is anyone doing the work like this? If yes, I would like to join :) On Fri, Nov 28, 2014 at 8:36 AM, Sandy Walsh wrote: > >From: Michael Still [mi...@stillhq.com] Thursday, November 27, 2014 6:57 > PM > >To: OpenStack Development Mailing List (not for usage questions) > >Subject: Re: [openstack-dev] [nova] is there a way to simulate thousands > or millions of compute nodes? > > > >I would say that supporting millions of compute nodes is not a current > >priority for nova... We are actively working on improving support for > >thousands of compute nodes, but that is via cells (so each nova deploy > >except the top is still in the hundreds of nodes). > > > > Agreed, it wouldn't make much sense to simulate this on a single machine. > > That said, if one *was* to simulate this, there are the well known > bottlenecks: > > 1. the API. How much can one node handle with given hardware specs? Which > operations hit the DB the hardest? > 2. the Scheduler. There's your API bottleneck and big load on the DB for > Create operations. > 3. the Conductor. Shouldn't be too bad, essentially just a proxy. > 4. child-to-global-cell updates. Assuming a two-cell deployment. > 5. the virt driver. YMMV. > ... and that's excluding networking, volumes, etc. > > The virt driver should be load tested independently. So FakeDriver would > be fine (with some delays added for common operations as Gareth suggests). > Something like Bees-with-MachineGuns could be used to get a baseline metric > for the API. Then it comes down to DB performance in the scheduler and > conductor (for a single cell). Finally, inter-cell loads. Who blows out the > queue first? > > All-in-all, I think you'd be better off load testing each piece > independently on a fixed hardware platform and faking out all the > incoming/outgoing services. Test the API with fake everything. Test the > Scheduler with fake API calls and fake compute nodes. Test the conductor > with fake compute nodes (not FakeDriver). Test the compute node directly. > > Probably all going to come down to the DB and I think there is some good > performance data around that already? > > But I'm just spit-ballin' ... and I agree, not something I could see the > Nova team taking on in the near term ;) > > -S > > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] is there a way to simulate thousands or millions of compute nodes?
Hi all, Is there a way to simulate thousands or millions of compute nodes? Maybe we could have many fake nova-compute services on one physical machine. By this other nova components would have pressure from thousands of compute services and this could help us find more problem from large-scale deployment (fake ; -) ) I know there is a fake virt driver in nova, but that is not so real. Maybe we need a fake driver could sleep 20s (which is close to real booting time) in 'spawn' function. -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] My notes and experiences about OSv on OpenStack
Pusihng it into OpenStack is not a hard job, because for OpenStack developers OSv image is a normal qcow2 image. What you need do is enabling some Qemu flags in Nova libvirt driver. yep, I will be there :) On Thu, Oct 16, 2014 at 2:10 PM, Zhipeng Huang wrote: > Ahhh, that's bad. Do you think there is a need for pushing OSv integration > in OpenStack in Kilo cycle? Would you come to Paris Summit? > > On Thu, Oct 16, 2014 at 1:24 PM, Gareth wrote: > >> yes :) >> >> I planed that if that topic were picked, I could apply that as a formal >> project in Intel. But failed... >> >> On Thu, Oct 16, 2014 at 12:53 PM, Zhipeng Huang >> wrote: >> >>> Hi, I'm also interested in it. You submitted a talk about it to Paris >>> Summit right? >>> >>> On Thu, Oct 16, 2014 at 10:34 AM, Gareth >>> wrote: >>> >>>> >>>> Here is introducing OSv to all OpenStack developers. OSv team is >>>> focusing on performance of KVM based guest OS, or cloud application. I'm >>>> interested in it because of their hard work on optimizing all details. And >>>> I had also worked on deploying OSv on OpenStack environment. However, since >>>> my work is only for private interests in off working time, my progress is >>>> pretty slow. So I have to share my experience and hope other engineers >>>> could join it: >>>> >>>> # OSv highlights in my mind >>>> >>>> 1, Super fast booting time means nearly zero down time services, an >>>> alternative way to dynamic flavor changing and time improvement for >>>> deploying instances in KVM based PaaS platform. 2, Great work on >>>> performance. Cloud engineers could borrow experience from their work on >>>> guest OS. 3, Better performance on JVM. We could imagine there are many >>>> overhead and redundancy in host OS/guest OS/JVM. Fixing that could help >>>> Java applications perform closer to bare-metal. >>>> >>>> # Enabling OSv on OpenStack >>>> >>>> Actually there should not be any big problems. The steps are that >>>> building OSv qcow2 image first and boot it via Nova then. You may face some >>>> problems because OSv image need many new Qemu features, such as >>>> virtio-rng-io/vhost and enable-kvm flag is necessary. >>>> >>>> Fortunately, I don't meet any problems with network, Neutron (actually >>>> I thought before network in OpenStack maybe hang me for a long time). OSv >>>> need a tap device and Neutron does good job on it. And then I could access >>>> OSv service very well. >>>> >>>> # OSv based demo >>>> >>>> The work I finished is only a memcached cluster. And the result is >>>> obvious: memory throughout of OSv based instance has 3 times than it in >>>> traditional virtual machines, and 90% of performance on host OS[0][1]. >>>> Since their work on memcached is quite mature, consider OSv if you need >>>> build memcached instance. >>>> >>>> Another valuable demo cluster is Hadoop. When talking about Hadoop on >>>> OpenStack, the topic asked most frequently is the performance on virtual >>>> machines. A known experience is higher version Qemu would help fix disk I/O >>>> performance[2]. But how does the overlap in JVM/guest OS? I would love to >>>> find that, but don't have so much time. >>>> >>>> After of all, the purpose of this thread is to bring an interesting >>>> topic on cloud performance and hope more and more efficient clusters based >>>> on OpenStack (in production use). I don't have so much time on OSv because >>>> this just is my personal interest, but I could prove OSv is a valuable way >>>> and topic. >>>> >>>> [0] http://paste.openstack.org/show/121382/ >>>> [1] >>>> https://github.com/cloudius-systems/osv/wiki/OSv-Case-Study:-Memcached >>>> [2] >>>> https://www.openstack.org/summit/openstack-summit-atlanta-2014/session-videos/presentation/performance-of-hadoop-on-openstack >>>> >>>> -- >>>> Gareth >>>> >>>> *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* >>>> *OpenStack contributor, kun_huang@freenode* >>>> *My promise: if you find any spelling or grammar mistakes in my email >>>> from Mar 1 2013, notify me * >>>> *and I'll donate $1 o
Re: [openstack-dev] My notes and experiences about OSv on OpenStack
yes :) I planed that if that topic were picked, I could apply that as a formal project in Intel. But failed... On Thu, Oct 16, 2014 at 12:53 PM, Zhipeng Huang wrote: > Hi, I'm also interested in it. You submitted a talk about it to Paris > Summit right? > > On Thu, Oct 16, 2014 at 10:34 AM, Gareth wrote: > >> >> Here is introducing OSv to all OpenStack developers. OSv team is focusing >> on performance of KVM based guest OS, or cloud application. I'm interested >> in it because of their hard work on optimizing all details. And I had also >> worked on deploying OSv on OpenStack environment. However, since my work is >> only for private interests in off working time, my progress is pretty slow. >> So I have to share my experience and hope other engineers could join it: >> >> # OSv highlights in my mind >> >> 1, Super fast booting time means nearly zero down time services, an >> alternative way to dynamic flavor changing and time improvement for >> deploying instances in KVM based PaaS platform. 2, Great work on >> performance. Cloud engineers could borrow experience from their work on >> guest OS. 3, Better performance on JVM. We could imagine there are many >> overhead and redundancy in host OS/guest OS/JVM. Fixing that could help >> Java applications perform closer to bare-metal. >> >> # Enabling OSv on OpenStack >> >> Actually there should not be any big problems. The steps are that >> building OSv qcow2 image first and boot it via Nova then. You may face some >> problems because OSv image need many new Qemu features, such as >> virtio-rng-io/vhost and enable-kvm flag is necessary. >> >> Fortunately, I don't meet any problems with network, Neutron (actually I >> thought before network in OpenStack maybe hang me for a long time). OSv >> need a tap device and Neutron does good job on it. And then I could access >> OSv service very well. >> >> # OSv based demo >> >> The work I finished is only a memcached cluster. And the result is >> obvious: memory throughout of OSv based instance has 3 times than it in >> traditional virtual machines, and 90% of performance on host OS[0][1]. >> Since their work on memcached is quite mature, consider OSv if you need >> build memcached instance. >> >> Another valuable demo cluster is Hadoop. When talking about Hadoop on >> OpenStack, the topic asked most frequently is the performance on virtual >> machines. A known experience is higher version Qemu would help fix disk I/O >> performance[2]. But how does the overlap in JVM/guest OS? I would love to >> find that, but don't have so much time. >> >> After of all, the purpose of this thread is to bring an interesting topic >> on cloud performance and hope more and more efficient clusters based on >> OpenStack (in production use). I don't have so much time on OSv because >> this just is my personal interest, but I could prove OSv is a valuable way >> and topic. >> >> [0] http://paste.openstack.org/show/121382/ >> [1] >> https://github.com/cloudius-systems/osv/wiki/OSv-Case-Study:-Memcached >> [2] >> https://www.openstack.org/summit/openstack-summit-atlanta-2014/session-videos/presentation/performance-of-hadoop-on-openstack >> >> -- >> Gareth >> >> *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* >> *OpenStack contributor, kun_huang@freenode* >> *My promise: if you find any spelling or grammar mistakes in my email >> from Mar 1 2013, notify me * >> *and I'll donate $1 or ￥1 to an open organization you specify.* >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > Zhipeng Huang > Research Assistant > Mobile Ad-Hoc Network Lab, Calit2 > University of California, Irvine > Email: zhipe...@uci.edu > Office: Calit2 Building Room 2402 > OpenStack, OpenDaylight, OpenCompute affcienado > > -- > You received this message because you are subscribed to the Google Groups > "OSv Development" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to osv-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] My notes and experiences about OSv on OpenStack
Here is introducing OSv to all OpenStack developers. OSv team is focusing on performance of KVM based guest OS, or cloud application. I'm interested in it because of their hard work on optimizing all details. And I had also worked on deploying OSv on OpenStack environment. However, since my work is only for private interests in off working time, my progress is pretty slow. So I have to share my experience and hope other engineers could join it: # OSv highlights in my mind 1, Super fast booting time means nearly zero down time services, an alternative way to dynamic flavor changing and time improvement for deploying instances in KVM based PaaS platform. 2, Great work on performance. Cloud engineers could borrow experience from their work on guest OS. 3, Better performance on JVM. We could imagine there are many overhead and redundancy in host OS/guest OS/JVM. Fixing that could help Java applications perform closer to bare-metal. # Enabling OSv on OpenStack Actually there should not be any big problems. The steps are that building OSv qcow2 image first and boot it via Nova then. You may face some problems because OSv image need many new Qemu features, such as virtio-rng-io/vhost and enable-kvm flag is necessary. Fortunately, I don't meet any problems with network, Neutron (actually I thought before network in OpenStack maybe hang me for a long time). OSv need a tap device and Neutron does good job on it. And then I could access OSv service very well. # OSv based demo The work I finished is only a memcached cluster. And the result is obvious: memory throughout of OSv based instance has 3 times than it in traditional virtual machines, and 90% of performance on host OS[0][1]. Since their work on memcached is quite mature, consider OSv if you need build memcached instance. Another valuable demo cluster is Hadoop. When talking about Hadoop on OpenStack, the topic asked most frequently is the performance on virtual machines. A known experience is higher version Qemu would help fix disk I/O performance[2]. But how does the overlap in JVM/guest OS? I would love to find that, but don't have so much time. After of all, the purpose of this thread is to bring an interesting topic on cloud performance and hope more and more efficient clusters based on OpenStack (in production use). I don't have so much time on OSv because this just is my personal interest, but I could prove OSv is a valuable way and topic. [0] http://paste.openstack.org/show/121382/ [1] https://github.com/cloudius-systems/osv/wiki/OSv-Case-Study:-Memcached [2] https://www.openstack.org/summit/openstack-summit-atlanta-2014/session-videos/presentation/performance-of-hadoop-on-openstack -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] How does Nova update time for compute nodes?
Thanks you Chen. What I'm finding is the '_report_state' function. Your answer really helps :) On Wed, Oct 8, 2014 at 11:28 AM, Chen CH Ji wrote: > following are code analysis, only FYI > > not sure fully understand the question, but I think > servicegroup/drivers/db.py might be a good place to look at > a timer function _report_state is called periodically ,when its updated, > the field will be updated > > class TimestampMixin(object): > created_at = Column(DateTime, default=lambda: timeutils.utcnow()) > updated_at = Column(DateTime, onupdate=lambda: timeutils.utcnow()) > > Best Regards! > > Kevin (Chen) Ji 纪 晨 > > Engineer, zVM Development, CSTL > Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com > Phone: +86-10-82454158 > Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, > Beijing 100193, PRC > > [image: Inactive hide details for Gareth ---10/08/2014 10:23:59 AM---Hi, > Nova guys I know that 'nova-manage service list' will output ']Gareth > ---10/08/2014 10:23:59 AM---Hi, Nova guys I know that 'nova-manage service > list' will output 'XXX' for compute nodes > > From: Gareth > To: OpenStack Development Mailing List > Date: 10/08/2014 10:23 AM > Subject: [openstack-dev] [nova] How does Nova update time for compute > nodes? > -- > > > > Hi, Nova guys > > I know that 'nova-manage service list' will output 'XXX' for compute nodes > is the time between api node and compute node are larger than > service_down_time. At the same time Nova update db cyclically. So my > question is how does Nova update that data? via crontab or something else? > > > -- > Gareth > > *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* > *OpenStack contributor, kun_huang@freenode* > *My promise: if you find any spelling or grammar mistakes in my email from > Mar 1 2013, notify me * > *and I'll donate $1 or ￥1 to an open organization you specify.* > ___ > 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 > > -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] How does Nova update time for compute nodes?
Hi, Nova guys I know that 'nova-manage service list' will output 'XXX' for compute nodes is the time between api node and compute node are larger than service_down_time. At the same time Nova update db cyclically. So my question is how does Nova update that data? via crontab or something else? -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] how do I change qemu execution path?
Hi I mean I could use another patch instead of "/usr/libexec/qemu-kvm" Thanks -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Horizon] Nominations to Horizon Core
Good job! zhenguo On Wed, Jul 2, 2014 at 9:55 AM, Zhenguo Niu wrote: > Thank you everyone, I'll do my best! > > 发自我的 iPhone > > > 在 Jul 1, 2014，22:37，"Lyle, David" 写道： > > > > Welcome Zhenguo and Ana to Horizon core. > > > > David > > > > > >> On 6/20/14, 3:17 PM, "Lyle, David" wrote: > >> > >> I would like to nominate Zhenguo Niu and Ana Krivokapic to Horizon core. > >> > >> Zhenguo has been a prolific reviewer for the past two releases providing > >> high quality reviews. And providing a significant number of patches over > >> the past three releases. > >> > >> Ana has been a significant reviewer in the Icehouse and Juno release > >> cycles. She has also contributed several patches in this timeframe to > both > >> Horizon and tuskar-ui. > >> > >> Please feel free to respond in public or private your support or any > >> concerns. > >> > >> Thanks, > >> David > >> > >> > >> ___ > >> OpenStack-dev mailing list > >> OpenStack-dev@lists.openstack.org > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [OpenStack][Nova] infinite attempts left
When run "nova-manage db sync" it outputs a lot of logs and "SQL connection failed. infinite attempts left" What does that means? -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [rally] Proposing Kun to Rally Core.
nice to join you guys ; ) On Monday, March 24, 2014, Hugh Saunders wrote: > +1 > Kun has been very active on gerrit, and contributed good patches, so will > be a great addition to the core team. > > > -- > Hugh Saunders > > > On 24 March 2014 07:31, Boris Pavlovic > > > wrote: > >> Hi stackers, >> >> >> I would like to propose Kun Huang to Rally Core team. >> As you saw already, he is doing a lot of good reviews, and catch a lot of >> nits and bugs, so he will be a good core reviewer. >> >> Here is detailed statistics for the latest 30 days: >> http://stackalytics.com/report/contribution/rally/30 >> >> Thoughts? >> >> >> Best regards, >> Boris Pavlovic >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [nova] server.name raise AttributeError
call for help
On Sun, Mar 16, 2014 at 12:20 AM, Gareth wrote:
> Hey, Nova guys
>
>File "/opt/stack/python-novaclient/novaclient/v1_1/servers.py", line 39,
> in __repr__
> return "" % self.name
>File
> "/opt/stack/python-novaclient/novaclient/openstack/common/apiclient/base.py",
> line 461, in __getattr__
> self.get()
>File
> "/opt/stack/python-novaclient/novaclient/openstack/common/apiclient/base.py",
> line 479, in get
> new = self.manager.get(self.id)
>File "/opt/stack/python-novaclient/novaclient/v1_1/servers.py", line 543,
> in get
> return self._get("/servers/%s" % base.getid(server), "server")
>File "/opt/stack/python-novaclient/novaclient/base.py", line 147, in _get
> _resp, body = self.api.client.get(url)
>File "/opt/stack/python-novaclient/novaclient/client.py", line 283, in get
> return self._cs_request(url, 'GET', **kwargs)
>File "/opt/stack/python-novaclient/novaclient/client.py", line 260, in
> _cs_request
> **kwargs)
>File "/opt/stack/python-novaclient/novaclient/client.py", line 242, in
> _time_request
> resp, body = self.request(url, method, **kwargs)
>File "/opt/stack/python-novaclient/novaclient/client.py", line 236, in
> request
> raise exceptions.from_response(resp, body, url, method)
> NotFound: Instance could not be found (HTTP 404) (Request-ID:
> req-e6208ee5-5fb3-4195-983f-9847124a9982)
>
>
> Looking this trace stack, we could know that I have a *server* object,
> and when called server.name, the *server* went to lazy load. That means
> this *server* object doesn't
> have name AttributeError from initializing. And all attributes of *server*are
> from nova api response. That is the response against nova get-server
> api didn't contain name
> keyword. So what case would make this happened?
>
> The following 404 error is understandable. In that runtime, my codes are
> trying to deleting a server. So during the lazy loading, the server has
> been already deleted which
> results that 404 error.
>
> My question is about that "self.name". Why does such a server object miss
> the "name" attribute?
>
> --
> Gareth
>
> *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball*
> *OpenStack contributor, kun_huang@freenode*
> *My promise: if you find any spelling or grammar mistakes in my email from
> Mar 1 2013, notify me *
> *and I'll donate $1 or ￥1 to an open organization you specify.*
>
--
Gareth
*Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball*
*OpenStack contributor, kun_huang@freenode*
*My promise: if you find any spelling or grammar mistakes in my email from
Mar 1 2013, notify me *
*and I'll donate $1 or ￥1 to an open organization you specify.*
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [nova] server.name raise AttributeError
Hey, Nova guys
File "/opt/stack/python-novaclient/novaclient/v1_1/servers.py",
line 39, in __repr__
return "" % self.name
File
"/opt/stack/python-novaclient/novaclient/openstack/common/apiclient/base.py",
line 461, in __getattr__
self.get()
File
"/opt/stack/python-novaclient/novaclient/openstack/common/apiclient/base.py",
line 479, in get
new = self.manager.get(self.id)
File "/opt/stack/python-novaclient/novaclient/v1_1/servers.py",
line 543, in get
return self._get("/servers/%s" % base.getid(server), "server")
File "/opt/stack/python-novaclient/novaclient/base.py", line 147, in _get
_resp, body = self.api.client.get(url)
File "/opt/stack/python-novaclient/novaclient/client.py", line 283, in get
return self._cs_request(url, 'GET', **kwargs)
File "/opt/stack/python-novaclient/novaclient/client.py", line 260,
in _cs_request
**kwargs)
File "/opt/stack/python-novaclient/novaclient/client.py", line 242,
in _time_request
resp, body = self.request(url, method, **kwargs)
File "/opt/stack/python-novaclient/novaclient/client.py", line 236,
in request
raise exceptions.from_response(resp, body, url, method)
NotFound: Instance could not be found (HTTP 404) (Request-ID:
req-e6208ee5-5fb3-4195-983f-9847124a9982)
Looking this trace stack, we could know that I have a *server* object, and
when called server.name, the *server* went to lazy load. That means this
*server* object doesn't
have name AttributeError from initializing. And all attributes of
*server*are from nova api response. That is the response against nova
get-server
api didn't contain name
keyword. So what case would make this happened?
The following 404 error is understandable. In that runtime, my codes are
trying to deleting a server. So during the lazy loading, the server has
been already deleted which
results that 404 error.
My question is about that "self.name". Why does such a server object miss
the "name" attribute?
--
Gareth
*Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball*
*OpenStack contributor, kun_huang@freenode*
*My promise: if you find any spelling or grammar mistakes in my email from
Mar 1 2013, notify me *
*and I'll donate $1 or ￥1 to an open organization you specify.*
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tempest] who builds other part of test environment
fixed! The reason is that .gitignore contains 'build/' but pep8 checking doesn't ignore it. So there are many mistakes in build//*.py. After removing build dir, everything runs well On Thu, Mar 6, 2014 at 11:55 AM, Gareth wrote: > The difference is that: in my local environment, running "tox -epep8" > failed but succeeded in Jenkins. So I guess the tox.ini may be different. > > > On Thu, Mar 6, 2014 at 11:38 AM, Joshua Hesketh < > joshua.hesk...@rackspace.com> wrote: > >> Hi Gareth, >> >> Tempest shouldn't touch the test that you are looking at. The Jenkins job >> should execute using the tox.ini in the rally repository so that part >> should be the same as your local environment. This is the relevant part >> loaded onto the Jenkin's slaves: >> https://github.com/openstack-infra/config/blob/master/modules/jenkins/files/slave_scripts/run-pep8.sh >> . >> >> What is the specific difference you were concerned with? >> >> Cheers, >> Josh >> >> Rackspace Australia >> >> On 3/6/14 1:33 PM, Gareth wrote: >> >> Hi >> >> Here a test result: >> http://logs.openstack.org/25/78325/3/check/gate-rally-pep8/323b39c/console.htmland >> its result is different from in my local environment. So I want to >> check some details of official test environment, for example >> /home/jenkins/workspace/gate-rally-pep8/tox.ini. >> >> I guess it is in tempest repo but it isn't. I didn't find any test >> tox.ini file in tempest repo. So it should be hosted in another repo. Which >> is that one? >> >> thanks >> >> -- >> Gareth >> >> *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* >> *OpenStack contributor, kun_huang@freenode* >> *My promise: if you find any spelling or grammar mistakes in my email >> from Mar 1 2013, notify me * >> *and I'll donate $1 or ￥1 to an open organization you specify.* >> >> >> ___ >> OpenStack-dev mailing >> listOpenStack-dev@lists.openstack.orghttp://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 >> >> > > > -- > Gareth > > *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* > *OpenStack contributor, kun_huang@freenode* > *My promise: if you find any spelling or grammar mistakes in my email from > Mar 1 2013, notify me * > *and I'll donate $1 or ￥1 to an open organization you specify.* > -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [tempest] who builds other part of test environment
The difference is that: in my local environment, running "tox -epep8" failed but succeeded in Jenkins. So I guess the tox.ini may be different. On Thu, Mar 6, 2014 at 11:38 AM, Joshua Hesketh < joshua.hesk...@rackspace.com> wrote: > Hi Gareth, > > Tempest shouldn't touch the test that you are looking at. The Jenkins job > should execute using the tox.ini in the rally repository so that part > should be the same as your local environment. This is the relevant part > loaded onto the Jenkin's slaves: > https://github.com/openstack-infra/config/blob/master/modules/jenkins/files/slave_scripts/run-pep8.sh > . > > What is the specific difference you were concerned with? > > Cheers, > Josh > > Rackspace Australia > > On 3/6/14 1:33 PM, Gareth wrote: > > Hi > > Here a test result: > http://logs.openstack.org/25/78325/3/check/gate-rally-pep8/323b39c/console.htmland > its result is different from in my local environment. So I want to > check some details of official test environment, for example > /home/jenkins/workspace/gate-rally-pep8/tox.ini. > > I guess it is in tempest repo but it isn't. I didn't find any test > tox.ini file in tempest repo. So it should be hosted in another repo. Which > is that one? > > thanks > > -- > Gareth > > *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* > *OpenStack contributor, kun_huang@freenode* > *My promise: if you find any spelling or grammar mistakes in my email from > Mar 1 2013, notify me * > *and I'll donate $1 or ￥1 to an open organization you specify.* > > > ___ > OpenStack-dev mailing > listOpenStack-dev@lists.openstack.orghttp://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 > > -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [tempest] who builds other part of test environment
Hi Here a test result: http://logs.openstack.org/25/78325/3/check/gate-rally-pep8/323b39c/console.htmland its result is different from in my local environment. So I want to check some details of official test environment, for example /home/jenkins/workspace/gate-rally-pep8/tox.ini. I guess it is in tempest repo but it isn't. I didn't find any test tox.ini file in tempest repo. So it should be hosted in another repo. Which is that one? thanks -- Gareth *Cloud Computing, OpenStack, Distributed Storage, Fitness, Basketball* *OpenStack contributor, kun_huang@freenode* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [ironic] Disk Eraser
Hi guys I have another question about erasing all data from disk. When using dd from /dev/zero could set bytes to zero from LBA0 on a disk. But dd a whole disk will cost very very long time and the custom way is to dd key data on the disk, for example the first 512B as MBR. But this is not enough, some data still locates in disk which could bring some issues like device mapper. And my question is how Disk Eraser cleans all data on disk. dd is the tool, not a strategy. On Fri, Jan 17, 2014 at 4:14 PM, Robert Collins wrote: > On 16 January 2014 03:31, Alan Kavanagh > wrote: > > Hi fellow OpenStackers > > > > > > > > Does anyone have any recommendations on open source tools for disk > > erasure/data destruction software. I have so far looked at DBAN and disk > > scrubber and was wondering if ironic team have some better > recommendations? > > So for Ironic this is a moderately low priority thing right now - and > certainly I think it should be optional (what the default is is a > different discussion). > > It's low priority because there are -so- many other concerns about > sharing bare metal machines between tenants that don't have > comprehensive mutual trust, that it's really not viable today (even on > relatively recent platforms IMNSHO). > > -Rob > > > -- > Robert Collins > Distinguished Technologist > HP Converged Cloud > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [OpenStack][Horizon] poweroff/shutdown action in horizon
Hi all There is a confused word in horizon when stopping an instance. Please take a look at following snapshots: 1. In the action list of an install, there is an action that is "Shut Off" [image: Inline image 2] 2. If you press that, In the confirm window, we still call this action "Shut Off" [image: Inline image 1] 3. When doing this action, it is called "Powering off" [image: Inline image 3] 4. Shut off again after finished [image: Inline image 4] So should we use a unified name for it? For example we could use "Shuting down" instead. But I'm not sure for this, because horizon has a long history actually, maybe horizon developers choosing current verbs have a more rational reason. -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* <><><><>___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [OpenStack][Glance][Nova] create instance booting from iso
Hi all I also find the wiki: https://wiki.openstack.org/wiki/BootFromISO But are there some details about it, such as blueprint or patches. What's the progress of this feature now. Thanks -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [OpenStack][Swift] how does swift update obj count of container or account?
On Tue, Oct 22, 2013 at 5:33 PM, Alex Yang wrote: > Hi Gareth: > > The process of update object count to container db is synchronized. After > the DiskFile finish writing the data to disk, the object-server will make a > request to container servers and update the object count. If the request > failed, the request will be serialized on the disk, and the object-update > will update it to container servers asynchronously. > > The process of update object count from container db to account db is > asynchronized. The container-updater will loop all the container db files > in disk and update the object count the account servers > If I start my services like "swift-init main start"(container-updater will not be launched), the obj-count of account will be 0? for the reason that no container-updater reports data to account. But the truth is not that. The obj-count of account and container is correct in most of simple cases. > > > > 2013/10/22 Gareth > >> Hi >> >> How does Swift update container object count or account object count >> after PUT an object? Counting per request or something else? >> >> -- >> Gareth >> >> *Cloud Computing, OpenStack, Fitness, Basketball* >> *OpenStack contributor* >> *Company: UnitedStack <http://www.ustack.com>* >> *My promise: if you find any spelling or grammar mistakes in my email >> from Mar 1 2013, notify me * >> *and I'll donate $1 or ￥1 to an open organization you specify.* >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > > -- > 杨雨 > Email: alex890...@gmail.com > GitHub: https://github.com/AlexYangYu > Weibo: http://www.weibo.com/alexyangyu > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [OpenStack][Swift] how does swift update obj count of container or account?
Hi How does Swift update container object count or account object count after PUT an object? Counting per request or something else? -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Reminder: Project & release status meeting - 21:00 UTC
it seems that we didn't log this channel in here: http://eavesdrop.openstack.org/meetings/openstack-meeting/2013/ On Tue, Oct 8, 2013 at 6:12 PM, Thierry Carrez wrote: > Today in the project/release status meeting, we are 9 days before > release ! We'll look in particular into how far away Swift RC1 is, the > status of already-opened RC2 windows, and review havana-rc-potential > bugs to evaluate the need to open other ones. > > Feel free to add extra topics to the agenda: > [1] http://wiki.openstack.org/Meetings/ProjectMeeting > > All Technical Leads for integrated programs should be present (if you > can't make it, please name a substitute on [1]). Other program leads and > everyone else is very welcome to attend. > > The meeting will be held at 21:00 UTC on the #openstack-meeting channel > on Freenode IRC. You can look up how this time translates locally at: > [2] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20131008T21 > > See you there, > > -- > Thierry Carrez (ttx) > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Gate issues - what you can do to help
On Fri, Sep 27, 2013 at 9:43 PM, Sean Dague wrote: > Right now the gate is extremely full, there are a number of reasons for > that. What's more important right now is to try not to make it worse while > we get resolution on things. > > 1) Please *do not* Approve or Reverify stable/* patches. The pyparsing > requirements conflict with neutron client from earlier in the week is still > not resolved on stable/*. A stable/* approved patch will not get through > the gate, and it will just reset everyone else, adding 40 minutes to the > gate time for all patches in the queue. > This is not the first time say "please don't reverify or approve". Can we add a feature in the future to temporarily block all patches except tempest or some specified ones? Or privilege gate for some important patches. > > 2) Please help with the 2 bugs that Joe Gordon posted earlier. > > There is a Neutron issue, which looks like it might be a db deadlock - > https://bugs.launchpad.net/**neutron/+bug/1230407<https://bugs.launchpad.net/neutron/+bug/1230407>which > is bouncing jobs a lot in the gate > > There is a Volumes test fail https://bugs.launchpad.net/** > tempest/+bug/1226337 <https://bugs.launchpad.net/tempest/+bug/1226337>, > which looks like it is tgt quietly failing to spin up a volume, and cinder > not noticing. We've got a change in the check queue to try to enable more > debugging to get to the bottom of it. However more help on it would be > useful. > > -Sean > > -- > Sean Dague > http://dague.net > > __**_ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.**org > http://lists.openstack.org/**cgi-bin/mailman/listinfo/**openstack-dev<http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> > -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Swift] PTL Candidacy
Good plan! On Wed, Sep 25, 2013 at 6:40 AM, John Dickinson wrote: > I would like to nominate myself for PTL of Swift. > > I've been involved in OpenStack Swift since it started, and I'd like > to share a few of the thins in-progress and where I want to see Swift > go. > > Swift has always been a world-class storage system, proven at scale > and production-ready from day one. In the past few years Swift has > been deployed in public and private storage clouds all over the world, > and it is in use at the largest companies in the world. > > My goal for Swift is that everyone will use Swift, every day, even if > they don't realize it. And taking a look at where Swift is being used > today, we're well on our way to that goal. We'll continue to move > towards Swift being everywhere as Swift grows to solve more real-world > use cases. > > Right now, there is work being done in Swift that will give deployers > a very high degree of flexibility in how they can store data. We're > working on implementing storage policies in Swift. These storage > policies give deployers the ability to choose: > > (a) what subset of hardware the data lives on > (b) how the data is stored across that hardware > (c) how communication with an actual storage volume happens. > > Supporting (a) allows for storage tiers and isolated storage hardware. > Supporting (b) allows for different replication or non-replication > schemes. Supporting (c) allows for specific optimizations for > particular filesystems or storage hardware. Combined, it's even > feasable to have a Swift cluster take advantage of other storage > systems as a storage policy (imagine an S3 storage policy). > > As PTL, I want to help coordinate this work and see it to completion. > Many people from many different companies are working on it, in > addition to the normal day-to-day activity in Swift. > > I'm excited by the future of Swift, and would be honored to continue > to serve as Swift PTL. > > --John > > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [CI] can't receive mails from Jenkins
sorry everyone those mails are in my spam box ... On Thu, Sep 5, 2013 at 12:24 PM, Gareth wrote: > Hi, all > > I have faced this problem about 15 hours ago. Some activities here now > didn't notice me by mails: > > https://review.openstack.org/#/c/45081/ > https://review.openstack.org/#/c/45031/ > > Is this a personal issue or general one? or an old problem? > > -- > Gareth > > *Cloud Computing, OpenStack, Fitness, Basketball* > *OpenStack contributor* > *Company: UnitedStack <http://www.ustack.com>* > *My promise: if you find any spelling or grammar mistakes in my email > from Mar 1 2013, notify me * > *and I'll donate $1 or ￥1 to an open organization you specify.* > -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [CI] can't receive mails from Jenkins
Hi, all I have faced this problem about 15 hours ago. Some activities here now didn't notice me by mails: https://review.openstack.org/#/c/45081/ https://review.openstack.org/#/c/45031/ Is this a personal issue or general one? or an old problem? -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] proposing Alex Gaynor for core on openstack/requirements
I like this guy; his review is really helpful for my swift patch set. Thanks again, Alex. On Wed, Aug 21, 2013 at 1:45 AM, Alex Gaynor wrote: > Thanks everyone, I look forward to continuing to help out! > > Alex > > > On Tue, Aug 20, 2013 at 9:49 AM, Doug Hellmann < > doug.hellm...@dreamhost.com> wrote: > >> Without any objections, I've added Alex Gaynor to the requirements-core >> team. >> >> Welcome, Alex! >> >> >> On Sat, Aug 17, 2013 at 2:46 PM, Jeremy Stanley wrote: >> >>> On 2013-08-16 11:04:14 -0400 (-0400), Doug Hellmann wrote: >>> > I'd like to propose Alex Gaynor for core status on the >>> > requirements project. >>> [...] >>> >>> Agreed, I for one welcome his continued assistance. >>> -- >>> Jeremy Stanley >>> >>> ___ >>> 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 >> >> > > > -- > "I disapprove of what you say, but I will defend to the death your right > to say it." -- Evelyn Beatrice Hall (summarizing Voltaire) > "The people's good is the highest law." -- Cicero > GPG Key fingerprint: 125F 5C67 DFE9 4084 > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] Code review study
That's an interesting article and also meaningful for coders. If I have a patch more than 200 or 300 lines, to split this may be a good idea. Some time, an easy patch with a little more lines would prevent more reviewers to think about it. On Thu, Aug 15, 2013 at 10:12 AM, Robert Collins wrote: > This may interest data-driven types here. > > > https://www.ibm.com/developerworks/rational/library/11-proven-practices-for-peer-review/ > > Note specifically the citation of 200-400 lines as the knee of the review > effectiveness curve: that's lower than I thought - I thought 200 was > clearly fine - but no. > > -Rob > > -- > Robert Collins > Distinguished Technologist > HP Converged Cloud > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Stackalytics] 0.1 release
A suggestion: sort bugs number as int is much better than string, because '112' < '8' but actually 112 > 8 http://stackalytics.com/companies/unitedstack On Thu, Jul 25, 2013 at 9:31 AM, Alex Freedland wrote: > Roman, > > Thank you for your comment. I agree that is should not be the only way to > look at the statistics and that is why Stackalytics also measures the > number of contributions and soon will add the number of reviews. I do, > however, think it a useful statistic as because not all commits are created > equal. > > To your argument that the developers will write longer code just for the > sake of statistics, I think this will not happen en mass. First and > foremost, the developers care about their reputations and knowing that > their code is peer-reviewed, very few will intentionally write inefficient > code just to get their numbers up. Those few who will choose this route > will lose the respect of their peers and consequently will not be able to > contribute as much. > > Also, in order to deal with the situations where people can manipulate the > numbers, Stackalytics allows anyone in the community to correct the line > count where it does not make sense. ( > https://wiki.openstack.org/wiki/Stackalytics#Commits_metrics_corrections_and_a_common_sense_approach > ). > > We welcome any other improvements and suggestions on how to make OpenStack > statistics more transparent, meaningful and reliable. > > Alex Freedland > > > > > On Tue, Jul 23, 2013 at 7:25 AM, Roman Prykhodchenko < > rprikhodche...@mirantis.com> wrote: > >> I still think counting lines of code is evil because it might encourage >> some developers to write longer code just for statistics. >> >> On Jul 23, 2013, at 16:58 , Herman Narkaytis >> wrote: >> >> Hello everyone! >> >> Mirantis <http://www.mirantis.com/> is pleased to announce the release >> of Stackalytics <http://www.stackalytics.com/> 0.1. You can find >> complete details on the Stackalytics >> wiki<https://wiki.openstack.org/wiki/Stackalytics> page, >> but here are the brief release notes: >> >>- Changed the internal architecture. Main features include advanced >>real time processing and horizontal scalability. >>- Got rid of all 3rd party non-Apache libraries and published the >>source on StackForge under the Apache2 license. >>- Improved release cycle tracking by using Git tags instead of >>approximate date periods. >>- Changed project classification to a two-level structure: OpenStack >> (core, >>incubator, documentation, other) and StackForge. >>- Implemented correction mechanism that allows users to tweak metrics >>for particular commits. >>- Added a number of new projects (Tempest, documentation, Puppet >>recipes). >>- Added company affiliated contribution breakdown to the user's >>profile page. >> >> We welcome you to read, look it over, and comment. >> >> Thank you! >> >> -- >> Herman Narkaytis >> DoO Ru, PhD >> Tel.: +7 (8452) 674-555, +7 (8452) 431-555 >> Tel.: +7 (495) 640-4904 >> Tel.: +7 (812) 640-5904 >> Tel.: +38(057)728-4215 >> Tel.: +1 (408) 715-7897 >> ext 2002 >> http://www.mirantis.com >> >> This email (including any attachments) is confidential. If you are not >> the intended recipient you must not copy, use, disclose, distribute or rely >> on the information contained in it. If you have received this email in >> error, please notify the sender immediately by reply email and delete the >> email from your system. Confidentiality and legal privilege attached to >> this communication are not waived or lost by reason of mistaken delivery to >> you. Mirantis does not guarantee (that this email or the attachment's) are >> unaffected by computer virus, corruption or other defects. Mirantis may >> monitor incoming and outgoing emails for compliance with its Email Policy. >> Please note that our servers may not be located in your country. >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> ___ >> OpenStack-dev mailing list >> OpenStack-dev@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] problems in pypi.openstack.org
Hi https://jenkins.openstack.org/job/gate-glance-python27/4896/console xattr can't be installed correctly. And in http://pypi.openstack.org/openstack/xattr/ the xattr-0.7.1 was just updated several hours ago. Are any problems in it? BTW, Swift and Glance are influenced. <http://pypi.openstack.org/openstack/xattr/>-- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] common codes
Michael, thanks for your perspective. It's easy to understand. But I just have some questions, not specific problems. Yaguang, I like the 'import' way too. But is there a global timeline of making oslo mature? Is this decided by oslo team or release plan? On Tue, Jul 16, 2013 at 11:00 AM, Yaguang Tang wrote: > we put openstack common code in oslo > , and sync to other projects to keep the common code in each project is > aways up to date, when oslo is mature enough, then we will publish oslo as > a openstack common library. the common code in each project just need to > change from "from nova.openstack.common import something" > to "from oslo.openstack.common import something" after oslo is released , > as the common code is aways sync from oslo, so there isn't any big change. > > correct me if my understanding is wrong. > 在 2013-7-16 上午10:25，"Gareth" 写道： > >> Hi, all >> >> There are some common codes in most of projects, such as opnstack/common, >> db, and some else (?). I know a good way is using 'import oslo' is ok, >> instead of copy those codes here and there. And now we already have project >> oslo and trove, but how and when do we handle old codes, remove that in >> next major release? >> >> -- >> Gareth >> >> *Cloud Computing, OpenStack, Fitness, Basketball* >> *OpenStack contributor* >> *Company: UnitedStack <http://www.ustack.com>* >> *My promise: if you find any spelling or grammar mistakes in my email >> from Mar 1 2013, notify me * >> *and I'll donate $1 or ￥1 to an open organization you specify.* >> >> ___ >> 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 > > -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] common codes
Hi, all There are some common codes in most of projects, such as opnstack/common, db, and some else (?). I know a good way is using 'import oslo' is ok, instead of copy those codes here and there. And now we already have project oslo and trove, but how and when do we handle old codes, remove that in next major release? -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future
There're still keystone client conflict issues: https://review.openstack.org/#/c/36684/ It seems uncapping keystone client(remove upper bound) in some else project first is needed? On Fri, Jul 12, 2013 at 7:25 PM, Sean Dague wrote: > We are working towards uncapping all the clients, with the exception of > neutron client, because they need to make some incompatible changes on > their next major release. > > > On 07/12/2013 12:12 AM, Gareth wrote: > >> so, what's the final conclusion about this issue? >> >> >> On Fri, Jul 12, 2013 at 12:11 PM, Gareth > <mailto:academicgareth@gmail.**com >> wrote: >> >> Thanks, Monty >> >> but in my review >> https://review.openstack.org/#**/c/36684/<https://review.openstack.org/#/c/36684/>, >> Doug said >> we will go without upper bound with those python-*clients >> and in this one >> https://review.openstack.org/#**/c/36753/<https://review.openstack.org/#/c/36753/>, >> keystoneclient still keep '<0.4' and requirements test doesn't fail >> in keystoneclient >> (https://jenkins.openstack.**org/job/gate-cinder-** >> requirements/96/console<https://jenkins.openstack.org/job/gate-cinder-requirements/96/console> >> it failed on glanceclient) >> >> >> >> >> On Fri, Jul 12, 2013 at 11:54 AM, Monty Taylor > <mailto:mord...@inaugust.com>> wrote: >> >> >> >> On 07/11/2013 11:38 PM, Gareth wrote: >> > I heard there's a talk about this issue in #openstack-infra >> last night >> > (china standard time), what's the conclusion of that? >> > >> > BTW, how to find meeting log of #openstack-infra? I didn't >> find it >> > in >> http://eavesdrop.openstack.**org/<http://eavesdrop.openstack.org/> >> >> We don't log it currently. There is a wider conversation going >> on about >> which things we should log and which things we should not log >> ... but >> for the time being I've submitted this: >> >> >> https://review.openstack.org/**36773<https://review.openstack.org/36773> >> >> to add -infra. I think we talk about enough things that have >> ramifications on everyone in there that we should really capture >> it. >> > On Thu, Jul 11, 2013 at 11:35 PM, Dirk Müller > <mailto:d...@dmllr.de> >> > <mailto:d...@dmllr.de <mailto:d...@dmllr.de>>> wrote: >> > >> > >> See for example >> >> https://bugs.launchpad.net/**horizon/+bug/1196823<https://bugs.launchpad.net/horizon/+bug/1196823> >> > > This is arguably a deficiency of mox, which >> (apparently?) doesn't >> > let us mock properties automatically. >> > >> > I agree, but it is just one example. other test-only >> issues can >> > happen as well. >> > >> > Similar problem: the *client packages are not >> self-contained, they >> > have pretty strict dependencies on other packages. One >> case I already >> > run into was a dependency on python-requests: newer >> python-*client >> > packages (rightfully) require requests >= 1.x. running >> those on a >> > system that has OpenStack services from Grizzly or Folsom >> installed >> > cause a conflict: there are one or two that require >> requests to be < >> > 1.0. >> > >> > When you run gating on this scenario, I think the same >> flipping would >> > happen on e.g. requests as well, due to *client or the >> module being >> > installed in varying order. >> > >> > Greetings, >> > Dirk >> > >> > __**_ >> > OpenStack-dev mailing list >> > >> OpenStack-dev@lists.openstack.**org >> >> <mailto:OpenStack-dev@lists.**openstack.org >> > >> > >> <mailto:OpenStack-dev@lists.**openstack.org >> >>
Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future
so, what's the final conclusion about this issue? On Fri, Jul 12, 2013 at 12:11 PM, Gareth wrote: > Thanks, Monty > > but in my review https://review.openstack.org/#/c/36684/ , Doug said we > will go without upper bound with those python-*clients > and in this one https://review.openstack.org/#/c/36753/ , keystoneclient > still keep '<0.4' and requirements test doesn't fail in keystoneclient ( > https://jenkins.openstack.org/job/gate-cinder-requirements/96/console it > failed on glanceclient) > > > > > On Fri, Jul 12, 2013 at 11:54 AM, Monty Taylor wrote: > >> >> >> On 07/11/2013 11:38 PM, Gareth wrote: >> > I heard there's a talk about this issue in #openstack-infra last night >> > (china standard time), what's the conclusion of that? >> > >> > BTW, how to find meeting log of #openstack-infra? I didn't find it >> > in http://eavesdrop.openstack.org/ >> >> We don't log it currently. There is a wider conversation going on about >> which things we should log and which things we should not log ... but >> for the time being I've submitted this: >> >> https://review.openstack.org/36773 >> >> to add -infra. I think we talk about enough things that have >> ramifications on everyone in there that we should really capture it. >> > On Thu, Jul 11, 2013 at 11:35 PM, Dirk Müller > > <mailto:d...@dmllr.de>> wrote: >> > >> > >> See for example https://bugs.launchpad.net/horizon/+bug/1196823 >> > > This is arguably a deficiency of mox, which (apparently?) doesn't >> > let us mock properties automatically. >> > >> > I agree, but it is just one example. other test-only issues can >> > happen as well. >> > >> > Similar problem: the *client packages are not self-contained, they >> > have pretty strict dependencies on other packages. One case I >> already >> > run into was a dependency on python-requests: newer python-*client >> > packages (rightfully) require requests >= 1.x. running those on a >> > system that has OpenStack services from Grizzly or Folsom installed >> > cause a conflict: there are one or two that require requests to be < >> > 1.0. >> > >> > When you run gating on this scenario, I think the same flipping >> would >> > happen on e.g. requests as well, due to *client or the module being >> > installed in varying order. >> > >> > Greetings, >> > Dirk >> > >> > ___ >> > OpenStack-dev mailing list >> > OpenStack-dev@lists.openstack.org >> > <mailto:OpenStack-dev@lists.openstack.org> >> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> > >> > >> > >> > >> > -- >> > Gareth >> > >> > /Cloud Computing, OpenStack, Fitness, Basketball/ >> > /OpenStack contributor/ >> > /Company: UnitedStack <http://www.ustack.com>/ >> > /My promise: if you find any spelling or grammar mistakes in my email >> > from Mar 1 2013, notify me / >> > /and I'll donate $1 or ￥1 to an open organization you specify./ >> > >> > >> > _______ >> > 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 >> > > > > -- > Gareth > > *Cloud Computing, OpenStack, Fitness, Basketball* > *OpenStack contributor* > *Company: UnitedStack <http://www.ustack.com>* > *My promise: if you find any spelling or grammar mistakes in my email > from Mar 1 2013, notify me * > *and I'll donate $1 or ￥1 to an open organization you specify.* > -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future
Thanks, Monty but in my review https://review.openstack.org/#/c/36684/ , Doug said we will go without upper bound with those python-*clients and in this one https://review.openstack.org/#/c/36753/ , keystoneclient still keep '<0.4' and requirements test doesn't fail in keystoneclient ( https://jenkins.openstack.org/job/gate-cinder-requirements/96/console it failed on glanceclient) On Fri, Jul 12, 2013 at 11:54 AM, Monty Taylor wrote: > > > On 07/11/2013 11:38 PM, Gareth wrote: > > I heard there's a talk about this issue in #openstack-infra last night > > (china standard time), what's the conclusion of that? > > > > BTW, how to find meeting log of #openstack-infra? I didn't find it > > in http://eavesdrop.openstack.org/ > > We don't log it currently. There is a wider conversation going on about > which things we should log and which things we should not log ... but > for the time being I've submitted this: > > https://review.openstack.org/36773 > > to add -infra. I think we talk about enough things that have > ramifications on everyone in there that we should really capture it. > > On Thu, Jul 11, 2013 at 11:35 PM, Dirk Müller > <mailto:d...@dmllr.de>> wrote: > > > > >> See for example https://bugs.launchpad.net/horizon/+bug/1196823 > > > This is arguably a deficiency of mox, which (apparently?) doesn't > > let us mock properties automatically. > > > > I agree, but it is just one example. other test-only issues can > > happen as well. > > > > Similar problem: the *client packages are not self-contained, they > > have pretty strict dependencies on other packages. One case I already > > run into was a dependency on python-requests: newer python-*client > > packages (rightfully) require requests >= 1.x. running those on a > > system that has OpenStack services from Grizzly or Folsom installed > > cause a conflict: there are one or two that require requests to be < > > 1.0. > > > > When you run gating on this scenario, I think the same flipping would > > happen on e.g. requests as well, due to *client or the module being > > installed in varying order. > > > > Greetings, > > Dirk > > > > ___ > > OpenStack-dev mailing list > > OpenStack-dev@lists.openstack.org > > <mailto:OpenStack-dev@lists.openstack.org> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > -- > > Gareth > > > > /Cloud Computing, OpenStack, Fitness, Basketball/ > > /OpenStack contributor/ > > /Company: UnitedStack <http://www.ustack.com>/ > > /My promise: if you find any spelling or grammar mistakes in my email > > from Mar 1 2013, notify me / > > /and I'll donate $1 or ￥1 to an open organization you specify./ > > > > > > ___ > > 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 > -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future
I heard there's a talk about this issue in #openstack-infra last night (china standard time), what's the conclusion of that? BTW, how to find meeting log of #openstack-infra? I didn't find it in http://eavesdrop.openstack.org/ On Thu, Jul 11, 2013 at 11:35 PM, Dirk Müller wrote: > >> See for example https://bugs.launchpad.net/horizon/+bug/1196823 > > This is arguably a deficiency of mox, which (apparently?) doesn't let us > mock properties automatically. > > I agree, but it is just one example. other test-only issues can happen as > well. > > Similar problem: the *client packages are not self-contained, they > have pretty strict dependencies on other packages. One case I already > run into was a dependency on python-requests: newer python-*client > packages (rightfully) require requests >= 1.x. running those on a > system that has OpenStack services from Grizzly or Folsom installed > cause a conflict: there are one or two that require requests to be < > 1.0. > > When you run gating on this scenario, I think the same flipping would > happen on e.g. requests as well, due to *client or the module being > installed in varying order. > > Greetings, > Dirk > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] The danger of capping python-*clients in core projects, and forbidding it in the future
good idea for global requirements Let's submit a multi-project bug on launchpad, and be serious for changing these global requirements in following days On Thu, Jul 11, 2013 at 7:12 PM, Mark McLoughlin wrote: > On Wed, 2013-07-10 at 17:07 -0500, Dolph Mathews wrote: > > On Wednesday, July 10, 2013, Sean Dague wrote: > > > > > Yesterday in the very exciting run around to figure out why the gate > was > > > broken, we realized something interesting. Because of the way the gate > > > process pip requirements (one project at a time), on a current gate > run we > > > actually install and uninstall python-keystoneclient 4 times in a > normal > > > run, flipping back and forth from HEAD to 0.2.5. > > > > > > http://paste.openstack.org/**show/39880/< > http://paste.openstack.org/show/39880/>- shows what's going on > > > > > > The net of this means that if any of the projects specify a capped > client, > > > it has the potential for preventing that client from being tested in > the > > > gate. This is very possibly part of the reason we ended up with a > broken > > > python-keystoneclient 0.3.0 released. > > > > > > > I think we need to get strict on projects and prevent them from capping > > > their client requirements. That will also put burden on clients that > they > > > don't break backwards compatibility (which I think was a goal > regardless). > > > However there is probably going to be a bit of pain getting from where > we > > > are today, to this world. > > > > > > Thanks for investigating the underlying issue! I think the same > > policy should apply a bit further to any code we develop and consume > > ourselves as a community (oslo.config, etc). I have no doubt that's the > > standard we strive for, but it's all too easy to throw a cap into a > > requirements file and forget about it. > > I don't think we've ever capped oslo.config anywhere. Got a pointer to > what triggered that concern? > > We should/could be capping oslo.config like this: > > oslo.config>=1.1.0,<2.0 > > because the API stability commitment is that we won't break the API > without bumping the release number to 2.0. I don't anticipate doing 2.0 > soon/ever, so I've never pushed ahead with that capping. > > Cheers, > Mark. > > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron] [jenkins] [tempest] Trouble with a patch
nice jobs! On Wed, Jul 10, 2013 at 8:12 AM, Jeremy Stanley wrote: > On 2013-07-09 23:55:03 + (+), Kyle Mestery (kmestery) wrote: > > Thanks for the note Jeremy! Can you shoot another reply on this > > thread so those of us with patches failing can resubmit? > > Yep, now that https://review.openstack.org/36349 has merged you > should be safe to recheck any proposed changes or reverify any > approved changes which failed with that error. > -- > Jeremy Stanley > > ___ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Gareth *Cloud Computing, OpenStack, Fitness, Basketball* *OpenStack contributor* *Company: UnitedStack <http://www.ustack.com>* *My promise: if you find any spelling or grammar mistakes in my email from Mar 1 2013, notify me * *and I'll donate $1 or ￥1 to an open organization you specify.* ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Tempest] - how to debug
Great thanks, Sean!
I'm now working on this.
On Fri, Jun 14, 2013 at 7:39 PM, Davanum Srinivas wrote:
> Just for comparison wsgi http header default is 8192
>
> https://github.com/eventlet/eventlet/blob/master/eventlet/wsgi.py#L19
>
> -- dims
>
> On Fri, Jun 14, 2013 at 7:27 AM, Sean Dague wrote:
> > Start with that link, follow the fails from the Jenkins results post
> >
> > http://logs.openstack.org/32178/2/check/gate-swift-pep8/2650 : SUCCESS
> in
> > 42s
> >
> http://docs-draft.openstack.org/32178/2/check/gate-swift-docs/2480/doc/build/html/
> > : SUCCESS in 1m 09s
> > http://logs.openstack.org/32178/2/check/gate-swift-python26/2728 :
> SUCCESS
> > in 2m 50s
> > http://logs.openstack.org/32178/2/check/gate-swift-python27/2726 :
> SUCCESS
> > in 1m 08s
> >
> http://logs.openstack.org/32178/2/check/gate-tempest-devstack-vm-full/21501
> > : FAILURE in 51m 26s
> >
> http://logs.openstack.org/32178/2/check/gate-tempest-devstack-vm-quantum/28634
> > : FAILURE in 20m 13s
> >
> http://logs.openstack.org/32178/2/check/gate-tempest-devstack-vm-postgres-full/21208
> > : FAILURE in 47m 29s
> > http://logs.openstack.org/32178/2/check/gate-grenade-devstack-vm/8777 :
> > SUCCESS in 13m 53s (non-voting)
> >
> >
> > When you go to
> >
> http://logs.openstack.org/32178/2/check/gate-tempest-devstack-vm-full/21501
> >
> > You'll see a top level directory with console.html (the test run), and
> logs
> > directory, which includes all the screen logs for all the services run by
> > devstack.
> >
> > Start with the console log to figure out where the fail happened
> >
> > The console log is big, so typically jump all the way to the end and work
> > backwards. This will also ensure you find the actual critical fail, and
> not
> > trip over some early red herrings that are things working as designed but
> > with scary messages.
> >
> > Working backwards on this run gets you the following:
> >
> > 2013-06-07 19:16:35.349 |
> > ==
> > 2013-06-07 19:16:35.349 | FAIL:
> >
> tempest.api.object_storage.test_object_services.ObjectTest.test_get_object_using_temp_url[gate]
> > 2013-06-07 19:16:35.350 |
> > --
> > 2013-06-07 19:16:35.381 | _StringException: Traceback (most recent call
> > last):
> > 2013-06-07 19:16:35.381 | File
> >
> "/opt/stack/new/tempest/tempest/api/object_storage/test_object_services.py",
> > line 334, in test_get_object_using_temp_url
> > 2013-06-07 19:16:35.382 | metadata=metadata)
> > 2013-06-07 19:16:35.382 | File
> >
> "/opt/stack/new/tempest/tempest/services/object_storage/account_client.py",
> > line 62, in delete_account_metadata
> > 2013-06-07 19:16:35.382 | resp, body = self.post('', headers=headers,
> > body=None)
> > 2013-06-07 19:16:35.382 | File
> > "/opt/stack/new/tempest/tempest/common/rest_client.py", line 266, in post
> > 2013-06-07 19:16:35.382 | return self.request('POST', url, headers,
> > body)
> > 2013-06-07 19:16:35.382 | File
> > "/opt/stack/new/tempest/tempest/common/rest_client.py", line 394, in
> request
> > 2013-06-07 19:16:35.382 | resp, resp_body)
> > 2013-06-07 19:16:35.382 | File
> > "/opt/stack/new/tempest/tempest/common/rest_client.py", line 444, in
> > _error_checker
> > 2013-06-07 19:16:35.382 | raise exceptions.BadRequest(resp_body)
> > 2013-06-07 19:16:35.382 | BadRequest: Bad request
> > 2013-06-07 19:16:35.382 | Details: Header Line Too Long
> >
> >
> > So yes, this was related to your change, which changes max header
> lengths.
> > At this point it's probably worth setting up tempest locally and poking
> this
> > on your code to figure out if a tempest change is also needed to match
> the
> > new behavior, or if this is actually legitimately a break in behavior.
> >
> > That being said, I notice the review is -2ed by a person already as
> well, so
> > getting that resolved would be important.
> >
> > -Sean
> >
> > On 06/14/2013 02:38 AM, Gareth wrote:
> >>
> >> https://review.openstack.org/#/c/32178/
> >>
> >> here
> >>
> >>
> >> On Fri, Jun 14, 2013 at 2:25 PM, Eugene Nikanorov
> >> mailto:enikano...@mirantis.com>> wrote:
> >>
> >> Could you give a link to your review?
