[Openstack-community] OpenStack Community Weekly Newsletter (June 22-29)
Highlights of the week OpenStack Events at OSCON Discounted Passes http://www.openstack.org/blog/2012/06/openstack-events-at-oscon-discounted-passes/ We have quite a few activities planned for OSCON to celebrate OpenStack's second birthday. Kicking off with the first OpenStack Day http://www.oscon.com/oscon2012/public/content/open-stack, Tuesday July 17, there will be lots of OpenStack speakers, events and community members in attendance. Full details on the blog. Thoughts on improving OpenStack GIT commit practice/history http://berrange.com/posts/2012/06/27/thoughts-on-improving-openstack-git-commit-practicehistory/ Daniel P. Berrangé http://berrange.com/ started a discussion about git commit practice based on his personal experience over the past few months getting involved with OpenStack Nova through learning the codebase, examining its history, writing code and participating in reviews. There is a discussion about it also on the OpenStack developer list https://lists.launchpad.net/openstack/msg13742.html. Sumo nodes for OpenStack Swift: Mixing storage and proxy services for better performance and lower TCO http://www.zmanda.com/blogs/?p=812 Zmanda present a novel way to build storage clouds with higher throughput bandwidth but with lower initial hardware purchase cost and lower ongoing IT-related costs by using nodes in a Swift cloud which mix storage and proxy services. How to improve our bug triaging? http://markmail.org/message/zouvoxu7dmo5bduw Thierry Carrez started an important conversation. At the beginning of the month we had a BugTriage day that allowed us to make the Nova bug database much more relevant and triage a lot of incoming new bugs. However, since then, the numbers went up again. How would you resolve this issue? A collection of utilities for cleaning up the database http://markmail.org/message/gygnjvdy3njwfrtg Lars Kellogg-Stedman released a small collection of tools to clear things out of the Nova database that constantly fills with garbage while testing and developing. More. http://openstack.markmail.org/thread/gygnjvdy3njwfrtg Improving git Commit Messages http://markmail.org/message/6br5qtic644utqcg Brian Waldon wrote a short guide in Nova's HACKING.rst on how to write useful commit messages. Setuptools-git http://markmail.org/message/pmwaixxmiyvdw3lk The OpenStack Infra team wrote a setuptools plugin which adds git vcs support to setuptools *Heat* Version 4 Released http://markmail.org/message/iowxhm2ey7pfsdod The Heat developers are pleased to announce the release of the Heat API version 4. We have added many new features including Ubuntu Precise host support. Heat is a project designed to work with OpenStack that provides a programmable interface to orchestrate multiple cloud applications implementing CloudFormation. More. http://openstack.markmail.org/thread/iowxhm2ey7pfsdod Recent updates of DevStack http://markmail.org/message/rezv6qk3ygkz3rq4 Dean Troyer sent a quick summary of recent significant DevStack changes. Upcoming Events * OSCON http://www.openstack.org/assets/oscon-pavilion-prospectus-2012.pdf Jul 16 -- 20, 2012 -- Portland, OR Sponsor http://www.openstack.org/assets/oscon-pavilion-prospectus-2012.pdf * 13th International Free Software Forum -- OpenStack Track http://wiki.openstack.org/FISL13 Jul 25 -- 28, 2012 -- Porto Alegre, Brazil Coordination http://wiki.openstack.org/FISL13 * 2012 OpenStack APEC Conference http://openstack.csdn.net/index.html Aug 10 -- 11, 2012 -- Bejing+Shanghai, China Details http://openstack.csdn.net/index.html * Call for proposals for linux.conf.au 2013 http://markmail.org/message/cbmtzazcefh6d6bw Other news * OpenStack Project 2012-06-26 meeting summary http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-26-21.02.html and full log http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-26-21.02.log.html Welcome new contributors Celebrating the first patches submitted this week by: * ncode aka Juliano Martinez * David Scannell, Gridcentric * Sean M. Collins * Iryoung Jeong /The weekly newsletter is a way for the community to learn about all the various activities occurring on a weekly basis. If you would like to add content to a weekly update or have an idea about this newsletter, please leave a comment./ -- Mailing list: https://launchpad.net/~openstack-community Post to : openstack-community@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-community More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Jenkins vs SmokeStack tests Gerrit merge blockers
On 06/28/2012 11:58 PM, Monty Taylor wrote: On 06/28/2012 01:49 PM, Dan Prince wrote: - Original Message - From: Monty Taylor mord...@inaugust.com To: openstack@lists.launchpad.net Sent: Thursday, June 28, 2012 11:13:28 AM Subject: Re: [Openstack] Jenkins vs SmokeStack tests Gerrit merge blockers On 06/28/2012 07:32 AM, Daniel P. Berrange wrote: Today we face a situation where Nova GIT master fails to pass all the libvirt test cases. This regression was accidentally introduced by the following changeset https://review.openstack.org/#/c/8778/ If you look at the history of that, the first SmokeStack test run fails with some (presumably) transient errors, and added negative karma to the change against patchset 2. If it were not for this transient failure, it should have shown the regression in the libvirt test case. The libvirt test case in question was one that is skipped, unless libvirt is actually present on the host running the tests. SmokeStack had made sure the tests would run on such a host. There were then further patchsets uploaded, and patchset 4 was approved for merge. Jenkins ran its gate jobs and these all passed successfully. I am told that Jenkins will actually run the unittests that are included in Nova, so I would have expected it to see the flawed libvirt test case, but it didn't. I presume therefore, that Jenkins is not running on a libvirt enabled host. Kind of - it's sadly more complex than that ... The end result was that the broken changeset was merged to master, which in turns means any other developers submitting changes touching the libvirt area will get broken tests reported that were not actually their own fault. This leaves me with the following questions... 1. Why was the recorded failure from SmokeStack not considered to be a blocker for the merge of the commit by Gerrit or Jenkins or any of the reviewers ? 2. Why did SmokeStack not get re-triggered for the later patch set revisions, before it was merged ? The answer to 1 and 2 is largely the same - SmokeStack is a community contributed resources and is not managed by the CI team. Dan Prince does a great job with it, but it's not a resource that we have the ability to fix should it start messing up, so we have not granted it the permissions to file blocking votes. I would add that if anyone else is interested in collaborating on making SmokeStack better I'm more than happy to give access. Its all open source and has been since Cactus. As is now SmokeStack can can cast a -1 vote and hopefully this is proving to be useful. I'm open to suggestions. I think it's stellar! The tests that smokestack runs could all be written such that they are run by jenkins. I actually put in quite a bit of work to maintain an openstack_vpc job on Jenkins post-Cactus. When we talked about gating on this job at the Diablo conference the idea didn't seem to get very far... I kind of saw that as the end of the line for maintaining an openstack_vpc job and eventually it went away. Not sure who deleted it, but anyway. The way I see it there is value in both testing systems. Rather than complaining about why one system exists and/or doesn't port its tests to the other why don't we build on each others strengths. Seeing a green verified +1 from both Jenkins and SmokeStack on a review should be very encouraging... and if one of the two systems fails it might require further investigation. I completely agree with that. I'm still hoping we'll see more systems from more people so that the set of combinations get larger. I think also there's clearly value in running tests, like how SmokeStack is doing right now, that aren't necessarily part of the gate, but which pro-actively provide useful information to the reviewers. The repos that run the jenkins tests are all in git and managed by openstack's gerrit. If there are testing profiles that it runs that we as a community value and want to see part of the gate, anyone is welcome to port them. 3. Why did Jenkins not ensure that the tests were run on a libvirt enabled host ? This is a different, and slightly more complex. We run tests in virtualenvs so that the process used to test the code can be consistently duplicated by all of the developers in the project. This is the reason that we no longer do ubuntu package creation as part of the gate - turns out that's really hard for a developer running on OSX to do locally on their laptop - and if Jenkins reports an blocking error in a patch, we want a developer to be able to reproduce the problem locally so that they can have a chance at fixing it. The ability for developers to test things locally is very important. For that matter SmokeStack all started with a project called openstack_vpc, a project to spin up groups of cloud servers installed with the latest OpenStack code. A developer can use a project like openstack_vpc to spin up a set of servers in the cloud which builds and installs custom built packages for a set
Re: [Openstack] Nova and asynchronous instance launching
On Fri, Jun 29, 2012 at 5:19 AM, Devin Carlen de...@openstack.org wrote: On Jun 28, 2012, at 9:01 AM, Jay Pipes wrote: On 06/27/2012 06:51 PM, Doug Davis wrote: Consider the creation of a Job type of entity that will be returned from the original call - probably a 202. Then the client can check the Job to see how things are going. BTW - this pattern can be used for any async op, not just the launching of multiple instances since technically any op might be long-running (or queued) based on the current state of the system. Note that much of the job of launching an instance is already asynchronous -- the initial call to create an instance really just creates an instance UUID and returns to the caller -- most of the actual work to create the instance is then done via messaging calls and the caller can continue to call for a status of her instance to check on it. In this particular case, I believe Devin is referring to when you indicate you want to spawn a whole bunch of instances and in that case, things happen synchronously instead of asynchronously? Devin, is that correct? If so, it seems like returning a packet immediately that contains a list of the instance UUIDs that can be used for checking status is the best option? Yep, exactly. The client still waits synchronously for the underlying RPC to complete. Sound like a performance issue. I think this symptom can be much eased if we spend sometime fixing whatever bottleneck causing this (slow AMQP, scheduler, or network)? Now that Nova API has got multprocess enabled, we'd move to next bottleneck in long path of 'launching instance'. Devin, is it possible that you provide more details about this issue so that someone else can reproduce it? Or am I missing something here? -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Regards Huang Zhiteng ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] inter vm communication issue
Hi, I am a colleague of Bram working with him on these same systems. We are now experiencing other issues related to networking on our nodes: - we gave openstack eth0 as the vlan interface - eth0 en eth1 are still slaves in a bond0 (mode 6) == we are seeing a big number of dropped packets on the eth1 interface, this under heavy load causing an unstable network on our VMs My guess would be because we are directly using eth0 as vlan interface while it is a slave in a bond is creating these issues. Or should this not create issues? If so while we managed to avoid inter VM communication issues by using eth0 as vlin int. instead of our bond0 (= eth0+eth1) this still leaves the issue of why a bond interface would function as the openstack vlan interface? Regards, Tom Op vrijdag 1 juni 2012, om 15:28 heeft Bram De Wilde het volgende geschreven: The bond was the culprit! As we have been breaking our heads over this for close to 2 days it seems important enough to report here: On our ubuntu 12.04 systems we had 2 bonded interfaces configured with an ip of 10.0.0.0/24 in an adaptive load balancing mode. We used this mode = 6 type bonding a bonding is not supported by the switch administrator. This appears not to be compatible with vlan tagged multi-host networking. @Vish: thanx for the suggestion, any idea where we would have to post this issue as a bug? I guess not openstack but rather the ifenslave people? I would suspect this not to occur with other, switch based bonding modes but as we have no support for this I am unable to test... This explained the inter vm communication to be really unreliable an drop out after a while. Using the eth0 interface instead of the bond0 as the vlan interface the network now is stable as ever. Happy openstack users we will now be configuring our private cloud for stable operation in our department, thanx all! We will be working on a solution for the name resolution in vlan tagged multi-host configurations, I will keep you posted as we progress. Kind regards, Bram On 1-jun-2012, at 10:02, Vishvananda Ishaya wrote: On Jun 1, 2012, at 12:46 AM, Bram De Wilde wrote: Thanx Vish, On the name resolution: would you consider this a bug (I can file one if you would like) or a feature? Bug if it is an easy fix :) Could this be fixed by changing the /usr/bin/nova-dhcpbridge script to load all mac, hostname, ip combinations for the database instead of just the physical hosts one? Or would this create other issues? We would have to do some investigation into special settings. We want to make sure that the host doesn't respond to dhcp requests from other hosts. If it is possible to set up dnsmasq to do name resolution for the other hosts without handing ip addresses then we could do it this way. Someone will have to look into it. It might have to be something a little more complicated like writing out a hosts file in addition to the dhcp file and telling dnsmasq to use it. If you want to investigate the easiest way to configure dnsmasq to do this, that would be a big help. Vish ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net (mailto:openstack@lists.launchpad.net) Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] RFC: Thoughts on improving OpenStack GIT commit practice/history
Vaze, Mandar wrote: I particularly hate the single-line Fixes bug 1234566-type commit messages. I assume your concern was regarding commits where Fixes bug 1234566 is the first and ONLY line. Yes, that is the particularly offensive form :) Plus there is restriction on how long the first line of the commit message can be. Not everyone is able to describe their change in one short sentence. So typically *I* put Fixes bug 1234567 on the *first* line followed by additional lines describing the change. Brian suggested the following addition to HACKING.rst in https://review.openstack.org/#/c/9118 : The first line of the commit message should provide an accurate description of the change, not just a reference to a bug or blueprint. It must be followed by a single blank line. I agree with him: fixes bug XX is a useless shortlog line that gives you no information whatsoever about the nature of the change. You have to look somewhere else (in the rest of the commit message, in the diff, or on the bug tracker) to have the beginning of an idea. So anything else (even Fixes bug about scheduler) is more useful. Regards, -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] RFC: Thoughts on improving OpenStack GIT commit practice/history
On Fri, Jun 29, 2012 at 04:57:06AM +, Vaze, Mandar wrote: I particularly hate the single-line Fixes bug 1234566-type commit messages. I assume your concern was regarding commits where Fixes bug 1234566 is the first and ONLY line. Fixes bug 1234566 comes from Wiki. Plus there is restriction on how long the first line of the commit message can be. Not everyone is able to describe their change in one short sentence. At the very least it is always possible to describe what area of the code is being changed, so that you alert the reviewers you are familiar with that area. So typically *I* put Fixes bug 1234567 on the *first* line followed by additional lines describing the change. IMHO that is one of the most unhelpful things you can do. If you are a reviewer scanning through your email for patches to review and you see a subject line Fixes bug 123456 you are given no useful information. Few people will bother to go find out what 'bug 123456' is, when there are plenty of other patches pending with useful subject lines. It is also pretty useless for people skimming through the online patch summaries in GIT history. As in my first mail this thread, the bug number should be just a line item at the end of the commit message, and the commit message first line should be a complete self-contained description. http://wiki.openstack.org/GerritWorkflow#Committing_Changes should be updated when this discussion is concluded. Yep, totally agreed. 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 :| ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] RFC: Thoughts on improving OpenStack GIT commit practice/history
At the very least it is always possible to describe what area of the code is being changed, so that you alert the reviewers you are familiar with that area. Yes, Makes sense. -Mandar __ Disclaimer:This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova and asynchronous instance launching
Note that I do distinguish between a 'real' async op (where you really return little more than a 202) and one that returns a skeleton of the resource being created - like instance.create() does now. So the latter approach at least provides a way to poll on the resource status, so as to figure out if and when it becomes usable. In the happy-path, eventually the instance status transitions to ACTIVE and away we go. However, considering the unhappy-path for a second, is there a place for surfacing some more context as to why the new instance unexpectedly went into the ERROR state? For example even just an indication that failure occurred in the scheduler (e.g. resource starvation) or on the target compute node. Is the thought that such information may be operationally sensitive, or just TMI for a typical cloud user? Cheers, Eoghan ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova and asynchronous instance launching
Right - examining the current state isn't a good way to determine what happened with one particular request. This is exactly one of the reasons some providers create Jobs for all actions. Checking the resource later to see why something bad happened is fragile since other opertaons might have happened since then, erasing any error message type of state info. And relying on event/error logs is hard since correlating one particular action with a flood of events is tricky - especially in a multi-user environment where several actions could be underway at once. If each action resulted in a Job URI being returned then the client can check that Job resource when its convinient for them - and this could be quite useful in both happy and unhappy situations. And to be clear, a Job doesn't necessarily need to be a a full new resource, it could (under the covers) map to a grouping of event logs entries but the point is that from a client's perspective they have an easy mechanism (e.g. issue a GET to a single URI) that returns all of the info needed to determine what happened with one particular operation. thanks -Doug __ STSM | Standards Architect | IBM Software Group (919) 254-6905 | IBM 444-6905 | d...@us.ibm.com The more I'm around some people, the more I like my dog. Eoghan Glynn egl...@redhat.com 06/29/2012 06:00 AM To Doug Davis/Raleigh/IBM@IBMUS cc openstack@lists.launchpad.net, Jay Pipes jaypi...@gmail.com Subject Re: [Openstack] Nova and asynchronous instance launching Note that I do distinguish between a 'real' async op (where you really return little more than a 202) and one that returns a skeleton of the resource being created - like instance.create() does now. So the latter approach at least provides a way to poll on the resource status, so as to figure out if and when it becomes usable. In the happy-path, eventually the instance status transitions to ACTIVE and away we go. However, considering the unhappy-path for a second, is there a place for surfacing some more context as to why the new instance unexpectedly went into the ERROR state? For example even just an indication that failure occurred in the scheduler (e.g. resource starvation) or on the target compute node. Is the thought that such information may be operationally sensitive, or just TMI for a typical cloud user? Cheers, Eoghan ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Nova and New Hardware
Hi- I'm new this community. And in need of help.. I have gone through Tilera support in the web documentation. Can any one guide me on How to enable NON x_86 arch. support in Openstack like enabling Tilera board support or some other Hardware architecture support in an already installed openstack compute machine. Is there any specific installation and usage guide for this. Thanking you... -- Regards, -- Trinath Somanchi, +91 9866 235 130 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [OpenStack][Nova] Issues with run_tests.sh, no tests are run when import libvirt is present
Hello, I'm sorry to restart the topic ( https://lists.launchpad.net/openstack/msg13621.html), but i accidentally deleted the message in my inbox :S. I'm still having the same problem, each time i add import libvirt to the file diangostics.py (https://review.openstack.org/#/c/8839/) the entire test suit won't run. *With the import* present i get the following output: -- Ran 0 tests in 0.000s OK Running PEP8 and HACKING compliance check... 2 imports missing in this test environment *Without the import *present it get this output: -- Ran 3030 tests in 233.326s OK (SKIP=22) Running PEP8 and HACKING compliance check... 11 imports missing in this test environment The problem now is that, according to the OpenStack conventions, the import must be present. However, with the import present i can't get any of the tests to run. I'm no expert in Python, so could someone please help me out here? Regards, Leander ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] [metering] resource metadata changes and billing
tl;dr: Ceilometer should ignore resource metadata when computing sums or maximum values for counters through the API. One of the things we discussed early during the design meetings was the need to track metadata along with resources so providers could use the metadata to determine the rate to charge for using the resource (for example, flavor or availability group of an instance). While working on the mongodb driver, I've been thinking about how that requirement changes what the API we defined needs to do. At first I thought we would need to try to return multiple values from the sum and max calls so the values could be associated with the resource metadata and a given time range. I've decided that implementing that inside the ceilometer API will be very complex, and unlikely to produce the correct result. I want to work through my reasoning here in case someone else can find a fault in it or propose a solution I wasn't able to find. First, the scenario: A user boots an instance, lets it run for some time (period 1), then changes the metadata in some way that does not result in the instance being recreated but does result in something the provider would decide introduces a different charge structure. For example, the amount of RAM allocated to the instance might be increased. After running with the new settings for a period of time (period 2), the user changes them back to their original value and the instance continues to run (period 3). The specific change to the metadata doesn't matter (RAM is just an example), except that the metadata change should not require an instance to be recreated because when that happens the user actually gets a new instance (at least I believe they do based on feedback during an early meeting, please correct me if I'm wrong). Getting a new instance simplifies things immensely, since the new instance is a completely new resource and so we can ignore those cases for the rest of this discussion. Another important point in the way the scenario is constructed is that the metadata values go from value A to B and then back to their original value A. That means any signature we calculate for the metadata will be the same during periods 1 and 3. Now we would like for v1/USERS/USER_ID/RESOURCES/instance_id/cpu/VOLUME to return the amount of CPU time used by the instance. However, if that time is billed at a different rate depending on the size of the server then the RAM change will cause a difference in billing rates. We therefore need to return a sequence of 3-tuples containing the total for the counter, the resource metadata, and the time range during which the metadata was in effect. There are two problems implementing this in a generic way in the API server. First, it turns out to be surprisingly difficult to write an efficient query to compute that time range in the case described because it is not easy to recognize the ranges for period 1 and period 3 as being interrupted by period 2 (finding min or max for a value is easy, but finding the endpoint of period 1 is not because the signature for the metadata is the same for period 1 and 3). Second, while calculating ranges is difficult in itself, what is even more difficult is recognizing *important* changes in the metadata that actually imply a change in the billing rate. The logic for that is up to the deployer and their billing rules. There are ways to compute the ranges by using multiple queries [1], and we could create some sort of way for the query to specify which fields in the metadata for a given type of resource are important. Both calculations would be expensive to apply in the API server, though, and I think they can be solved more efficiently on the client-side. If the client grabs all (or a large portion) of the data and processes it sequentially, it is easy to test the metadata fields to find changes and treat that condition as the boundary between the time ranges. My conclusion from all of this (over-)thinking is that the ceilometer API should assume the simple case and ignore the metadata changes when computing the sum or maximum value for a counter over a range of time. More complex processing will be left up to the caller, who can ask for raw metering data in manageable chunks and process them outside of the API. I could be persuaded to do something more complicated if the problems described above can be solved in a relatively simple way, but even then I think we should push that to the v2 API. Thoughts? There-and-back-again-ly, Doug [1] Find the min time for a (resource, metadata) pair; find min time for any different (resource, metadata) pair greater than the first time; find max for original pair with timestamp less than second min; use the max as starting point to determine the next range; loop. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help :
[Openstack] Bugs for Client libraries back to their own projects
Hello everyone, Once upon a time, each OpenStack client library was independent and had its own project in Launchpad. Then when Core projects came to rely on them, we pulled them in as official projects but since we didn't want to create Core projects for each of them, we considered them separate deliverables for the parent core project. When we released Nova we would release two tarballs. This resulted in client library tarballs following the same versioning as the parent (server-side) project, the same download pages in Launchpad, and by extension, the same Bugs pages. So we transfered client bugs from their project (python-novaclient) to the parent project (Nova) and used a tag to identify them. And we taught people to use that. But we couldn't get rid of the client projects in Launchpad, because Launchpad likes to have a project to link specific source packages to. Confusion ensued. The PPB decided recently to create a new category of projects, separate from Core, called the Library projects. Client libraries are no longer forced to follow versions and milestones from the corresponding server project. And they are no longer forced to live in someone else's apartment... so we can revert back to using their own project for bugs and end the confusion. So unless someone explains why we shouldn't do it, next week I'll start the process of migrating back all bugs tagged python-*client from their parent project to their own project. Cheers and sorry again for this historical confusion, which I certainly played a role in creating. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [metering] resource metadata changes and billing
On Fri, Jun 29 2012, Doug Hellmann wrote:
Thoughts?
Please correct me if I'm wrong.
What I understand is that you're saying that something like:
GET
v1/[SOURCES/SOURCE/]USERS/USER_ID/RESOURCES/RESOURCE_ID/METER/VOLUME
as defined in the current API draft, for a counter like instance CPU
time or RAM size has no sense because it can depends on other metadata
From the instance.
That sounds right in many case, especially instances.
The best way to fix this is to not return a sum, but a set of documents
describing the different changes.
E.g. for an (simplified) instance liked you described
GET v1/users/jd/instances/1234
{
id: 1234,
name: foobar,
…,
memory: 1024,
cpu_time: 393010,
start: 2012-06-01 00:00:00,
end: 2012-06-12 12:00:00,
}
{
id: 1234,
name: foobar,
…,
memory: 2048,
cpu_time: 1231294,
start: 2012-06-12 12:00:01,
end: 2012-06-26 13:24:43
}
{
id: 1234,
name: foobar,
…,
memory: 1024,
cpu_time: 4013510,
start: 2012-06-26 13:24:44,
end: 2012-06-30 23:59:00,
}
Doing this does not sounds like too much crazy. You just have to iterate
over each record concerning instance 1234. You create a first document
From the first record. Then if you encounter a meter that is:
- a delta (i.e. cpu_time), you sum up to the data you got from the
latest record in your document
- an incremented counter, you replace the last one with this one
- an absolute counter (i.e. memory) you start a new document, keep the
latest values from incremented counters (so you can substract the
value and start from 0), and reset all delta counters to 0.
If none of the absolute counter (RAM, number of CPU, …) changes, you'll
end up with only one document for the whole period. If one change,
you'll get multiple document describing the resources consumed for each
span time.
WDYT?
--
Julien
pgpJHpowFKbmg.pgp
Description: PGP signature
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
[Openstack] Jenkins and transient failures
One of the things that's really bugging me these days is transient failures, such as the inability to download a package, causing a gate job to fail. It seems to me that we can distinguish test failure from environment build failure easily enough, and automatically retry in the latter case. Is this possible in practice with our current CI infrastructure? -- Kevin L. Mitchell kevin.mitch...@rackspace.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Unit tests, individual vs. test suite
Lately I've been noticing that some individual unit tests fail for me, even though the overall test suite succeeds. So, for example: $ /opt/stack/nova$ ./run_tests.sh snip OK (SKIP=5) $ /opt/stack/nova$ ./run_tests.sh test_virt_drivers AbstractDriverTestCase test_add_to_aggregateERROR 0.02 test_agent_updateERROR 0.02 etc. And yet, if I scroll up and look at the earlier run (where everything passed) I see it running AbstractDriverTestCase with all green. What's happening here? Does this mean that tests are coupled in some unhealthy way such that they can only be run in a particular order? -Andrew ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova and asynchronous instance launching
However, considering the unhappy-path for a second, is there a place for surfacing some more context as to why the new instance unexpectedly went into the ERROR state? I assume the philosophy is that the API has validated the request as far and it can, and returned any meaningful error messages, etc. Anything that fails past that point is something going wrong from the cloud provider and there is nothing the user could have done to avoid the error, so any additional information won't help them. However on the basis that up-front validation is seldom perfect, and things can change while a request is in flight I think that being able to tell a user that, for example, their request failed because the image was deleted before it could be downloaded would be useful. One approach might be to make the task_state more granular and use that to qualify the error. In general our users have found having the state shown as vm_state (task_state) was useful as it shows progress during things like building. Phil From: openstack-bounces+philip.day=hp@lists.launchpad.net [mailto:openstack-bounces+philip.day=hp@lists.launchpad.net] On Behalf Of Doug Davis Sent: 29 June 2012 12:45 To: Eoghan Glynn Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Nova and asynchronous instance launching Right - examining the current state isn't a good way to determine what happened with one particular request. This is exactly one of the reasons some providers create Jobs for all actions. Checking the resource later to see why something bad happened is fragile since other opertaons might have happened since then, erasing any error message type of state info. And relying on event/error logs is hard since correlating one particular action with a flood of events is tricky - especially in a multi-user environment where several actions could be underway at once. If each action resulted in a Job URI being returned then the client can check that Job resource when its convinient for them - and this could be quite useful in both happy and unhappy situations. And to be clear, a Job doesn't necessarily need to be a a full new resource, it could (under the covers) map to a grouping of event logs entries but the point is that from a client's perspective they have an easy mechanism (e.g. issue a GET to a single URI) that returns all of the info needed to determine what happened with one particular operation. thanks -Doug __ STSM | Standards Architect | IBM Software Group (919) 254-6905 | IBM 444-6905 | d...@us.ibm.commailto:d...@us.ibm.com The more I'm around some people, the more I like my dog. Eoghan Glynn egl...@redhat.commailto:egl...@redhat.com 06/29/2012 06:00 AM To Doug Davis/Raleigh/IBM@IBMUS cc openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net, Jay Pipes jaypi...@gmail.commailto:jaypi...@gmail.com Subject Re: [Openstack] Nova and asynchronous instance launching Note that I do distinguish between a 'real' async op (where you really return little more than a 202) and one that returns a skeleton of the resource being created - like instance.create() does now. So the latter approach at least provides a way to poll on the resource status, so as to figure out if and when it becomes usable. In the happy-path, eventually the instance status transitions to ACTIVE and away we go. However, considering the unhappy-path for a second, is there a place for surfacing some more context as to why the new instance unexpectedly went into the ERROR state? For example even just an indication that failure occurred in the scheduler (e.g. resource starvation) or on the target compute node. Is the thought that such information may be operationally sensitive, or just TMI for a typical cloud user? Cheers, Eoghan ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Unit tests, individual vs. test suite
On Fri, 2012-06-29 at 10:34 -0500, Andrew Bogott wrote: $ /opt/stack/nova$ ./run_tests.sh test_virt_drivers AbstractDriverTestCase test_add_to_aggregateERROR 0.02 test_agent_updateERROR 0.02 etc. And yet, if I scroll up and look at the earlier run (where everything passed) I see it running AbstractDriverTestCase with all green. Try: ./run_tests.sh nova.tests.test_virt_drivers and see if there's any difference with the full path as compared to the abbreviated path? -- Kevin L. Mitchell kevin.mitch...@rackspace.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [OpenStack] duplicate option: scheduler_host_manager
Leander, As the error message indicates, it usually comes when the option is found in more than one place. Thanks, Joseph (w) 703-248-6160 (f) 703-812-3712 http://www.east.isi.edu/~jsuh Information Sciences Institute University of Southern California 3811 N. Fairfax Drive Suite 200 Arlington, VA, 22203, USA - Original Message - From: Leander Bessa Beernaert leande...@gmail.com To: openstack@lists.launchpad.net Sent: Friday, June 29, 2012 11:45:49 AM Subject: [Openstack] [OpenStack] duplicate option: scheduler_host_manager Hello, I'm working on this patch https://review.openstack.org/#/c/8839/ and i keep running into this error https://jenkins.openstack.org/job/gate-nova-python26/1333/testReport/%3Cnose.suite/ContextSuite%20context=nova/tests__setup/ Can someone shed some light on the subject? Regards, Leander ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] setuptools-git
On 06/29/2012 04:06 AM, Alan Pevec wrote: On Thu, Jun 28, 2012 at 9:56 PM, Monty Taylor mord...@inaugust.com wrote: https://review.openstack.org/9109 Why is setuptools_git added in pip-requires, I thought that's for run-time, not build-time dependencies? Hey Alan! We use pip-requires as part of building the virtualenvs. Once we start using it, setuptools-git is pretty much required for running setup.py, so many common actions in our workflow will require it. It's a good question though - and I consider the current existence of it in pip-requires purely a convenience hack. We don't have a strong place in our infrastructure to indicate setup_requires entries. I'll work on that next. Monty ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [metering] resource metadata changes and billing
On Fri, Jun 29 2012, Doug Hellmann wrote: We do have counters for RAM and CPU separate from instance. But the rate at which the provider bills for those things may vary based on metadata. My example may be bad because it uses 2 values we're measuring, one of which also shows up in the metadata for another. As a different example, take the instance display name. The display name is under the control of the user and is extremely unlikely to reflect a change in the billing rate. However, changing the display name changes the metadata for the instance. A naive implementation of the processing loop would pick that up and generate multiple documents even though there is no need to do so. Yep, but the display name is not a counter. Memory is a counter. An instance is made of several counter. We need to split metered objects based on their absolute counter changing (memory, number of core…), not based on random metadata, i.e. a resource have several meters. So what was considered as metadata (like memory) so far should changed to become a meter of an resource (like an instance) and have for this one a special type (not sure about the type name to use). We may need to refine our model to be a bit more hierarhical like: resource -- counter #1 of type 'relative' | `- counter #2 of type 'absolute' ` counter #3 of type 'if-i-change-you-need-to-split-the-resource-in-several-stuff' etc… -- Julien pgp0SCtPP0cCp.pgp Description: PGP signature ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] setuptools-git
Should there be a separation of build-time setup.py and run-time setup.py?? I'm not sure if something like that is possible (maybe with a setuptools variant, distribute or something similar??) On 6/29/12 4:06 AM, Alan Pevec ape...@gmail.com wrote: On Thu, Jun 28, 2012 at 9:56 PM, Monty Taylor mord...@inaugust.com wrote: https://review.openstack.org/9109 Why is setuptools_git added in pip-requires, I thought that's for run-time, not build-time dependencies? Cheers, Alan ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [metering] resource metadata changes and billing
On Fri, Jun 29, 2012 at 1:19 PM, Julien Danjou jul...@danjou.info wrote: On Fri, Jun 29 2012, Doug Hellmann wrote: We do have counters for RAM and CPU separate from instance. But the rate at which the provider bills for those things may vary based on metadata. My example may be bad because it uses 2 values we're measuring, one of which also shows up in the metadata for another. As a different example, take the instance display name. The display name is under the control of the user and is extremely unlikely to reflect a change in the billing rate. However, changing the display name changes the metadata for the instance. A naive implementation of the processing loop would pick that up and generate multiple documents even though there is no need to do so. Yep, but the display name is not a counter. Memory is a counter. An instance is made of several counter. We need to split metered objects based on their absolute counter changing (memory, number of core…), not based on random metadata, i.e. a resource have several meters. I don't think I've made the problem clear. I'm not talking about wanting to calculate the different usage for CPU, RAM, etc. The different counters are calculated separately, so we can keep the amounts for CPU and RAM completely separate, and the API allows the outside user to ask for the amounts for each counter for a resource (or globally for a user/project). The problem is in deciding how the metadata associated with a meter event might cause the provider to change the rate they want to charge for that usage. So what was considered as metadata (like memory) so far should changed to become a meter of an resource (like an instance) and have for this one a special type (not sure about the type name to use). That only solves part of the problem, though. As a provider I may want to charge different flat rates for the amount of RAM being used. For example, 1 unit for 1024 MB of RAM but 2 units for 4096 MB. That means when the size of the VM changes, we need to produce multiple totals (the length of time that the VM had 1024 MB RAM and then the length of time it had 4096 MB RAM). I might also want to change the rate I bill when a VM is migrated between hosts or availability zones (I think we said migration caused a new instance to be created, but bear with me). The availability zone for an instance is clearly metadata and not something we can track via a counter. We may need to refine our model to be a bit more hierarhical like: resource -- counter #1 of type 'relative' | `- counter #2 of type 'absolute' ` counter #3 of type 'if-i-change-you-need-to-split-the-resource-in-several-stuff' That's an interesting idea, and it might solve the problem. At this point in the Folsom schedule though, I would much rather implement a pared down API that handles the simple cases but makes the caller do a bit more data manipulation for complex cases, in favor of focusing on counting more things than we do now. Is that a reasonable approach? etc… -- Julien ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] hostnames on kvm images with periods
I have setup Essex on Centos 6.2 64 bit as per http://fedoraproject.org/wiki/Getting_started_with_OpenStack_EPEL I am using kvm/libvirt I can create images fine with nova boot. If I choose the name to be my.test.server, nova shows the name as local.test.server correctly, however, when I ssh to the newly created image the hostname is just local . If i choose the name to be: local-test-server, it gets set correctly on the new instance . I have been able to reproduce this one two separate machines. Is this expected behavior? Am I missing some critical step? Thanks! Drew ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] setuptools-git
On 06/29/2012 10:30 AM, Joshua Harlow wrote: Should there be a separation of build-time setup.py and run-time setup.py?? I’m not sure if something like that is possible (maybe with a setuptools variant, distribute or something similar??) Well, we use distribute already - but the problem isn't really build-time vs. run-time as much as it has to do with our use of virtualenv. HOWEVER - I think I just had an idea of how to make this slighly cleaner. Let me poke at it. On 6/29/12 4:06 AM, Alan Pevec ape...@gmail.com wrote: On Thu, Jun 28, 2012 at 9:56 PM, Monty Taylor mord...@inaugust.com wrote: https://review.openstack..org/9109 https://review.openstack.org/9109 Why is setuptools_git added in pip-requires, I thought that's for run-time, not build-time dependencies? Cheers, Alan ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova and asynchronous instance launching
On 06/29/2012 04:25 AM, Huang Zhiteng wrote: Sound like a performance issue. I think this symptom can be much eased if we spend sometime fixing whatever bottleneck causing this (slow AMQP, scheduler, or network)? Now that Nova API has got multprocess enabled, we'd move to next bottleneck in long path of 'launching instance'. Devin, is it possible that you provide more details about this issue so that someone else can reproduce it? Actually, Vish, David Kranz and I had a discussion about similar stuff on IRC yesterday. I think that an easy win for this would be to add much more fine-grained DEBUG logging statements in the various nova service pieces -- nova-compute, nova-network, etc. Right now, there are areas that seem to look like performance or locking culprits (iptables save/restore for example), but because there isn't very fine-grained logging statements, it's tough to say whether: a) A process (or greenthread) has simply yielded to another while it waits for something b) A process is doing something that is blocking or c) A process is doing some other work but no log statements are being logged about that work, which makes it seem like some other work is taking much longer than it really is This would be a really easy win for a beginner developer or someone looking for something to assist with -- simply add informative LOG.debug() statements at various points in the API call pipelines Best, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] setuptools-git
On Fri, Jun 29, 2012 at 7:19 PM, Monty Taylor mord...@inaugust.com wrote: We use pip-requires as part of building the virtualenvs. Once we start using it, setuptools-git is pretty much required for running setup.py, so many common actions in our workflow will require it. It's a good question though - and I consider the current existence of it in pip-requires purely a convenience hack. We don't have a strong place in our infrastructure to indicate setup_requires entries. I'll work on that next. test-requires is also used when building venv and until there are separate build-requires, seems to be a better place for deps such as this Trouble is that openstack.common.setup.parse_requirements() parses pip-requires and puts everything there into egg-info, which should be only run-time deps. Cheers, Alan ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova and asynchronous instance launching
An assumption is being made here that the user and cloud provider are unrelated. But I think there are many projects under development where a cloud-based service is being provided on top of an OpenStack infrastructure. In that use case, the direct user of OpenStack APIs and the cloud provider may be the same entity. It would be really nice if when an application fires up an instance that enters the error state, there was an api that could get the reason why it failed with as much information as the OpenStack code that set the instance state to ERROR had. If we are concerned that such information is sensitive and a public provider might not want to give it all to users, this could be an admin-only API. There are many variations of how the information is controlled. -David If we are concerned that a public provider might not want to give some information to users, this could be an admin-only API. On 6/29/2012 11:40 AM, Day, Phil wrote: However, considering the unhappy-path for a second, is there a place for surfacing some more context as to why the new instance unexpectedly went into the ERROR state? I assume the philosophy is that the API has validated the request as far and it can, and returned any meaningful error messages, etc. Anything that fails past that point is something going wrong from the cloud provider and there is nothing the user could have done to avoid the error, so any additional information won't help them. However on the basis that up-front validation is seldom perfect, and things can change while a request is in flight I think that being able to tell a user that, for example, their request failed because the image was deleted before it could be downloaded would be useful. One approach might be to make the task_state more granular and use that to qualify the error. In general our users have found having the state shown as vm_state (task_state) was useful as it shows progress during things like building. Phil *From:*openstack-bounces+philip.day=hp@lists.launchpad.net [mailto:openstack-bounces+philip.day=hp@lists.launchpad.net] *On Behalf Of *Doug Davis *Sent:* 29 June 2012 12:45 *To:* Eoghan Glynn *Cc:* openstack@lists.launchpad.net *Subject:* Re: [Openstack] Nova and asynchronous instance launching Right - examining the current state isn't a good way to determine what happened with one particular request. This is exactly one of the reasons some providers create Jobs for all actions. Checking the resource later to see why something bad happened is fragile since other opertaons might have happened since then, erasing any error message type of state info. And relying on event/error logs is hard since correlating one particular action with a flood of events is tricky - especially in a multi-user environment where several actions could be underway at once. If each action resulted in a Job URI being returned then the client can check that Job resource when its convinient for them - and this could be quite useful in both happy and unhappy situations. And to be clear, a Job doesn't necessarily need to be a a full new resource, it could (under the covers) map to a grouping of event logs entries but the point is that from a client's perspective they have an easy mechanism (e.g. issue a GET to a single URI) that returns all of the info needed to determine what happened with one particular operation. thanks -Doug __ STSM | Standards Architect | IBM Software Group (919) 254-6905 | IBM 444-6905 | d...@us.ibm.com mailto:d...@us.ibm.com The more I'm around some people, the more I like my dog. *Eoghan Glynn egl...@redhat.com mailto:egl...@redhat.com* 06/29/2012 06:00 AM To Doug Davis/Raleigh/IBM@IBMUS cc openstack@lists.launchpad.net mailto:openstack@lists.launchpad.net, Jay Pipes jaypi...@gmail.com mailto:jaypi...@gmail.com Subject Re: [Openstack] Nova and asynchronous instance launching Note that I do distinguish between a 'real' async op (where you really return little more than a 202) and one that returns a skeleton of the resource being created - like instance.create() does now. So the latter approach at least provides a way to poll on the resource status, so as to figure out if and when it becomes usable. In the happy-path, eventually the instance status transitions to ACTIVE and away we go. However, considering the unhappy-path for a second, is there a place for surfacing some more context as to why the new instance unexpectedly went into the ERROR state? For example even just an indication that failure occurred in the scheduler (e.g. resource starvation) or on the target compute node. Is the thought that such information may be operationally sensitive, or just TMI for a typical cloud user? Cheers, Eoghan ___ Mailing list:
Re: [Openstack] setuptools-git
On 06/29/2012 10:48 AM, Alan Pevec wrote: On Fri, Jun 29, 2012 at 7:19 PM, Monty Taylor mord...@inaugust.com wrote: We use pip-requires as part of building the virtualenvs. Once we start using it, setuptools-git is pretty much required for running setup.py, so many common actions in our workflow will require it. It's a good question though - and I consider the current existence of it in pip-requires purely a convenience hack. We don't have a strong place in our infrastructure to indicate setup_requires entries. I'll work on that next. test-requires is also used when building venv and until there are separate build-requires, seems to be a better place for deps such as this Trouble is that openstack.common.setup.parse_requirements() parses pip-requires and puts everything there into egg-info, which should be only run-time deps. Yeah - good call. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] setuptools-git
On 06/29/2012 10:48 AM, Alan Pevec wrote: On Fri, Jun 29, 2012 at 7:19 PM, Monty Taylor mord...@inaugust.com wrote: We use pip-requires as part of building the virtualenvs. Once we start using it, setuptools-git is pretty much required for running setup.py, so many common actions in our workflow will require it. It's a good question though - and I consider the current existence of it in pip-requires purely a convenience hack. We don't have a strong place in our infrastructure to indicate setup_requires entries. I'll work on that next. test-requires is also used when building venv and until there are separate build-requires, seems to be a better place for deps such as this Trouble is that openstack.common.setup.parse_requirements() parses pip-requires and puts everything there into egg-info, which should be only run-time deps. I just put up another possibility for review before I read this - check it out and see what you think - we can also go test-requires if you like that better. Monty ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova and New Hardware
Hello Trinath, We're working on general bare-metal provisioning framework including several architecture types such as x86-64/i386/ARM/tilera. The target release for this is Folsom. That's not merged into upstream yet. We're going to request whole review before August. Please refer the following launchpad and wiki page. https://blueprints.launchpad.net/nova/+spec/general-bare-metal-provisioning-framework http://wiki.openstack.org/GeneralBareMetalProvisioningFramework Thanks, Mikyung - Original Message - From: Trinath Somanchi trinath.soman...@gmail.com To: openstack@lists.launchpad.net Sent: Friday, June 29, 2012 7:51:51 AM Subject: [Openstack] Nova and New Hardware Hi- I'm new this community. And in need of help.. I have gone through Tilera support in the web documentation. Can any one guide me on How to enable NON x_86 arch. support in Openstack like enabling Tilera board support or some other Hardware architecture support in an already installed openstack compute machine. Is there any specific installation and usage guide for this. Thanking you... -- Regards, -- Trinath Somanchi, +91 9866 235 130 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] hostnames on kvm images with periods
I have also verified this happens as well with debian wheezy and essex. On Fri, 2012-06-29 at 13:42 -0400, Drewski wrote: I have setup Essex on Centos 6.2 64 bit as per http://fedoraproject.org/wiki/Getting_started_with_OpenStack_EPEL I am using kvm/libvirt I can create images fine with nova boot. If I choose the name to be my.test.server, nova shows the name as local.test.server correctly, however, when I ssh to the newly created image the hostname is just local . If i choose the name to be: local-test-server, it gets set correctly on the new instance . I have been able to reproduce this one two separate machines. Is this expected behavior? Am I missing some critical step? Thanks! Drew ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] RFC: Thoughts on improving OpenStack GIT commit practice/history
On 6/27/12 8:40 AM, Daniel P. Berrange wrote: On Wed, Jun 27, 2012 at 03:24:21PM +0200, Vincent Untz wrote: Hi, It'd be really great if we could first improve Gerrit to handle the patch series workflow in a better way. Without such a change, pushing patch series to Gerrit is really no fun for anyone :/ Yep, no argument that Gerrit could do with some improvements, but having submitted a number of non-trivial patch series to Nova, I don't think current Gerrit UI is a complete blocker to adoption. It is not ideal, but it isn't too painful if you're aware of what to look for. I think the main problem is that since the patch dependancies are not obvious in the UI, reviewers tend to miss the fact that they're reviewing a patch that's part of a series. I agree that patchsets are better than monolithic patches. Today, though, I am working on a 3-patch set and the process is driving me crazy. a) Any time Jenkins has a hiccup, I have to resubmit the entire patchset. This obscures any reviews or votes that might be attached to other patches in the set. b) Similarly, any time I change a single patch in the set, I have to resubmit the whole set, which causes review history to be obscured, even for those patches which have not changed at all. Case b) would be entirely solved via a fix to this: http://code.google.com/p/gerrit/issues/detail?id=71. That would also help with a) but not resolve it entirely... the best solution to a) would be a 'retrigger' button in Jenkins or a 'prompt Jenkins to re-review' button in Gerrit. The fact that people (including me) are submitting trivial edits to patches only in order to nudge Jenkins is pretty stupid. -A ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Performance metrics
On 06/21/2012 02:21 PM, Rick Jones wrote: TSO and GRO can cover a multitude of path-length sins :) That is one of the reasons netperf does more than just bulk transfer :) When I was/am measuring scaling of an SMP node I would use aggregate, burst-mode, single-byte netperf TCP_RR tests to maximize the packets per second while minimizing the actual bandwidth consumed. And if there is a concern about flows coming and going there is the TCP_CRR test which is like the TCP_RR test but each transaction is a freshly created and torn-down TCP connection. It doesn't do TCP_CRR, and it is not geared towards the scores/hundreds/thousands of isntances, but I've just put a script into the netperf repository at netperf.org which will use novaclient.v1_1 to launch three instances of a specified flavor and run the runemomniaggdemo.sh script on one of them, targeting the other two. http://www.netperf.org/svn/netperf2/trunk/doc/examples/netperf_by_flavor.py Is it only my second bit of Python, so I'm sure it has lots of room for improvement, but perhaps it will be of use to folks and help act as a seed crystal. happy benchmarking, rick jones ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova and asynchronous instance launching
You don't really expect a client (think ec2-like-user) to analyze debug info do you? I really think we need a nice consistent way for people to see what's going on with long-running operations. Debug info isn't that to me. thanks -Doug __ STSM | Standards Architect | IBM Software Group (919) 254-6905 | IBM 444-6905 | d...@us.ibm.com The more I'm around some people, the more I like my dog. Jay Pipes jaypi...@gmail.com Sent by: openstack-bounces+dug=us.ibm@lists.launchpad.net 06/29/2012 01:46 PM To Huang Zhiteng winsto...@gmail.com cc openstack@lists.launchpad.net Subject Re: [Openstack] Nova and asynchronous instance launching On 06/29/2012 04:25 AM, Huang Zhiteng wrote: Sound like a performance issue. I think this symptom can be much eased if we spend sometime fixing whatever bottleneck causing this (slow AMQP, scheduler, or network)? Now that Nova API has got multprocess enabled, we'd move to next bottleneck in long path of 'launching instance'. Devin, is it possible that you provide more details about this issue so that someone else can reproduce it? Actually, Vish, David Kranz and I had a discussion about similar stuff on IRC yesterday. I think that an easy win for this would be to add much more fine-grained DEBUG logging statements in the various nova service pieces -- nova-compute, nova-network, etc. Right now, there are areas that seem to look like performance or locking culprits (iptables save/restore for example), but because there isn't very fine-grained logging statements, it's tough to say whether: a) A process (or greenthread) has simply yielded to another while it waits for something b) A process is doing something that is blocking or c) A process is doing some other work but no log statements are being logged about that work, which makes it seem like some other work is taking much longer than it really is This would be a really easy win for a beginner developer or someone looking for something to assist with -- simply add informative LOG.debug() statements at various points in the API call pipelines Best, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova and asynchronous instance launching
On 06/29/2012 05:45 PM, Doug Davis wrote: You don't really expect a client (think ec2-like-user) to analyze debug info do you? I really think we need a nice consistent way for people to see what's going on with long-running operations. Debug info isn't that to me. thanks -Doug Also, see: http://wiki.openstack.org/MailingListEtiquette particularly the first point, re: HTML email. Cheers, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova and asynchronous instance launching
True that's all useful info but I thought the original problem being addressed was how the end-user could know what's going on for long-running ops. thanks -Doug __ STSM | Standards Architect | IBM Software Group (919) 254-6905 | IBM 444-6905 | d...@us.ibm.com The more I'm around some people, the more I like my dog. Jay Pipes jaypi...@gmail.com 06/29/2012 06:03 PM To Doug Davis/Raleigh/IBM@IBMUS cc openstack@lists.launchpad.net, Huang Zhiteng winsto...@gmail.com Subject Re: [Openstack] Nova and asynchronous instance launching I'm not expecting a client to do anything, and I'm not sure where you got that from my response below... I'm talking about adding debug statements into the nova-compute/nova-network logs that an *operator* or *core developer* would use to determine which parts of the code are taking that most amount of time. -jay On 06/29/2012 05:45 PM, Doug Davis wrote: You don't really expect a client (think ec2-like-user) to analyze debug info do you? I really think we need a nice consistent way for people to see what's going on with long-running operations. Debug info isn't that to me. thanks -Doug __ STSM | Standards Architect | IBM Software Group (919) 254-6905 | IBM 444-6905 | d...@us.ibm.com The more I'm around some people, the more I like my dog. *Jay Pipes jaypi...@gmail.com* Sent by: openstack-bounces+dug=us.ibm@lists.launchpad.net 06/29/2012 01:46 PM To Huang Zhiteng winsto...@gmail.com cc openstack@lists.launchpad.net Subject Re: [Openstack] Nova and asynchronous instance launching On 06/29/2012 04:25 AM, Huang Zhiteng wrote: Sound like a performance issue. I think this symptom can be much eased if we spend sometime fixing whatever bottleneck causing this (slow AMQP, scheduler, or network)? Now that Nova API has got multprocess enabled, we'd move to next bottleneck in long path of 'launching instance'. Devin, is it possible that you provide more details about this issue so that someone else can reproduce it? Actually, Vish, David Kranz and I had a discussion about similar stuff on IRC yesterday. I think that an easy win for this would be to add much more fine-grained DEBUG logging statements in the various nova service pieces -- nova-compute, nova-network, etc. Right now, there are areas that seem to look like performance or locking culprits (iptables save/restore for example), but because there isn't very fine-grained logging statements, it's tough to say whether: a) A process (or greenthread) has simply yielded to another while it waits for something b) A process is doing something that is blocking or c) A process is doing some other work but no log statements are being logged about that work, which makes it seem like some other work is taking much longer than it really is This would be a really easy win for a beginner developer or someone looking for something to assist with -- simply add informative LOG.debug() statements at various points in the API call pipelines Best, -jay ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] OpenStack Community Weekly Newsletter (June 22-29)
Highlights of the week OpenStack Events at OSCON Discounted Passes http://www.openstack.org/blog/2012/06/openstack-events-at-oscon-discounted-passes/ We have quite a few activities planned for OSCON to celebrate OpenStack's second birthday. Kicking off with the first OpenStack Day http://www.oscon.com/oscon2012/public/content/open-stack, Tuesday July 17, there will be lots of OpenStack speakers, events and community members in attendance. Full details on the blog. Thoughts on improving OpenStack GIT commit practice/history http://berrange.com/posts/2012/06/27/thoughts-on-improving-openstack-git-commit-practicehistory/ Daniel P. Berrangé http://berrange.com/ started a discussion about git commit practice based on his personal experience over the past few months getting involved with OpenStack Nova through learning the codebase, examining its history, writing code and participating in reviews. There is a discussion about it also on the OpenStack developer list https://lists.launchpad.net/openstack/msg13742.html. Sumo nodes for OpenStack Swift: Mixing storage and proxy services for better performance and lower TCO http://www.zmanda.com/blogs/?p=812 Zmanda present a novel way to build storage clouds with higher throughput bandwidth but with lower initial hardware purchase cost and lower ongoing IT-related costs by using nodes in a Swift cloud which mix storage and proxy services. How to improve our bug triaging? http://markmail.org/message/zouvoxu7dmo5bduw Thierry Carrez started an important conversation. At the beginning of the month we had a BugTriage day that allowed us to make the Nova bug database much more relevant and triage a lot of incoming new bugs. However, since then, the numbers went up again. How would you resolve this issue? A collection of utilities for cleaning up the database http://markmail.org/message/gygnjvdy3njwfrtg Lars Kellogg-Stedman released a small collection of tools to clear things out of the Nova database that constantly fills with garbage while testing and developing. More. http://openstack.markmail.org/thread/gygnjvdy3njwfrtg Improving git Commit Messages http://markmail.org/message/6br5qtic644utqcg Brian Waldon wrote a short guide in Nova's HACKING.rst on how to write useful commit messages. Setuptools-git http://markmail.org/message/pmwaixxmiyvdw3lk The OpenStack Infra team wrote a setuptools plugin which adds git vcs support to setuptools *Heat* Version 4 Released http://markmail.org/message/iowxhm2ey7pfsdod The Heat developers are pleased to announce the release of the Heat API version 4. We have added many new features including Ubuntu Precise host support. Heat is a project designed to work with OpenStack that provides a programmable interface to orchestrate multiple cloud applications implementing CloudFormation. More. http://openstack.markmail.org/thread/iowxhm2ey7pfsdod Recent updates of DevStack http://markmail.org/message/rezv6qk3ygkz3rq4 Dean Troyer sent a quick summary of recent significant DevStack changes. Upcoming Events * OSCON http://www.openstack.org/assets/oscon-pavilion-prospectus-2012.pdf Jul 16 -- 20, 2012 -- Portland, OR Sponsor http://www.openstack.org/assets/oscon-pavilion-prospectus-2012.pdf * 13th International Free Software Forum -- OpenStack Track http://wiki.openstack.org/FISL13 Jul 25 -- 28, 2012 -- Porto Alegre, Brazil Coordination http://wiki.openstack.org/FISL13 * 2012 OpenStack APEC Conference http://openstack.csdn.net/index.html Aug 10 -- 11, 2012 -- Bejing+Shanghai, China Details http://openstack.csdn.net/index.html * Call for proposals for linux.conf.au 2013 http://markmail.org/message/cbmtzazcefh6d6bw Other news * OpenStack Project 2012-06-26 meeting summary http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-26-21.02.html and full log http://eavesdrop.openstack.org/meetings/openstack-meeting/2012/openstack-meeting.2012-06-26-21.02.log.html Welcome new contributors Celebrating the first patches submitted this week by: * ncode aka Juliano Martinez * David Scannell, Gridcentric * Sean M. Collins * Iryoung Jeong /The weekly newsletter is a way for the community to learn about all the various activities occurring on a weekly basis. If you would like to add content to a weekly update or have an idea about this newsletter, please leave a comment./ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova and asynchronous instance launching
There's only 1 rpc call unless you're running cactus or something. All schedulers have a loop...not API. min-count is unfortunately special cased right now to be a single call vs cast, though. I was going to fix that real soon. Problem is scheduler creating the DB records vs API in this case. I can expand on this when I'm not replying from a phone. :) There's some other things that would be nice to do here with the API but the call can change to a cast with no API behavior change (except for speeding up the response :) - Chris On Jun 27, 2012, at 12:53 PM, Devin Carlen de...@openstack.org wrote: We filed a blueprint for this yesterday: https://blueprints.launchpad.net/nova/+spec/launch-instances-async Currently if a user attempts to create a lot of instances with a single API call (using min_count) the request will hang for a long time while all RPC calls are completed. For a large number of instances this can take a very long time. The API should return immediately and asynchronously make RPC calls. We are looking for creative ways to work around this problem, but in the meantime I'd like to hear from folks on what they think the preferred solution would be. Devin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OVF vs. bare container formats for qcow2 images
On 04/01/2012 11:15 AM, Lorin Hochstein wrote: On Mar 29, 2012, at 12:40 PM, Daniel P. Berrange wrote: On Wed, Mar 28, 2012 at 04:41:28PM -0400, Lorin Hochstein wrote: All: Given that I have a qcow2 image from somewhere (e.g., downloaded it from a uec-images.ubuntu.com http://uec-images.ubuntu.com, created one from a raw image using qemu-img) that i want to add to glance: 1. How can I tell whether it's an ovf or bare container format? You are mixing up terminology here. Disk image formats are things like raw, qcow2, vmdk, etc. OVF refers to the format of a metadata file provided alongside the disk image, which describes various requirements for running the image. The two are not tied together at all, merely complementary to each other. Thanks, that clears things up. I was confused by this language, which sounded to me like the metadata was embedded in the disk image file: http://glance.openstack.org/formats.html The container format refers to whether the virtual machine image is in a file format that also contains metadata about the actual virtual machine. In addition, the docs have examples like this, which clearly aren't meaningful: http://glance.openstack.org/glance.html#important-information-about-uploading-images Just to add to the confusion the OVF can contain both the metadata file and the disk image file in a single archived file. An OVF package consists of several files, placed in one directory. A one-file alternative is the OVA package, which is a TAR file with the OVF directory inside. http://en.wikipedia.org/wiki/Open_Virtualization_Format#Technical_description I think that what you are reading above refers to the single file alternative. $ glance add name=My Image is_public=true \ container_format=ovf disk_format=raw /tmp/images/myimage.iso I'll propose a change to the docs for that. Whenever I add a qcow2 image to glance, I always choose ovf, even though it's probably bare, because I saw an example somewhere, and it just works, so I keep doing it. But I don't know how to inspect a binary file to determine what its container is (if file image.qcow2 says it's a QEMU QCOW2 Image (v2), does that mean it's bare?). In particular, why does the user need to specify this information? If you simply have a single someimage.qcow2 file, then you simply have a disk image. Thus there is no OVF metadata involved at all. eg, this is the (qcow2) disk image: http://uec-images.ubuntu.com/precise/current/precise-server-cloudimg-amd64-disk1.img While this is an OVF metadata file that optionally accompanies the disk image http://uec-images.ubuntu.com/precise/current/precise-server-cloudimg-amd64.ovf Gotcha. It's not clear to me how you would specify the OVF metadata file when adding an image file to glance. Take care, Lorin -- Lorin Hochstein Lead Architect - Cloud Services Nimbis Services, Inc. www.nimbisservices.com https://www.nimbisservices.com/ ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] HA inside VMs (via Corosync/Pacemaker)
Hey all, I would like to setup a highly available service *inside* two KVM instances, so I have created a security group to contain all required service ports, so clients can connect to either VM and that works. And both instances have their own designated IP address, provided by nova itself. And now I want to allocate a custom private IP address (I just chose one from the higher address range, since I've a quite a big one (/21) and it was planned to use higher numbers for HA service IPs. But how do I teach OpneStack to let traffic to these KVMs via its designated Service IP? I took a look at the iptables rules, however, they are created automatically, and I did not get it really right what it all wants to tell me yet and what is there for what (not every rule uses -m comment --comment $hint). :-) So how do I teach OpneStack custom provided IP addresses? Best regards, Christian. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] HA inside VMs (via Corosync/Pacemaker)
Seems like you could use a floating ip for this. You can define a range for internal floating ips by using a separate floating ip pool. On Jun 29, 2012 7:06 PM, Christian Parpart tra...@gmail.com wrote: Hey all, I would like to setup a highly available service *inside* two KVM instances, so I have created a security group to contain all required service ports, so clients can connect to either VM and that works. And both instances have their own designated IP address, provided by nova itself. And now I want to allocate a custom private IP address (I just chose one from the higher address range, since I've a quite a big one (/21) and it was planned to use higher numbers for HA service IPs. But how do I teach OpneStack to let traffic to these KVMs via its designated Service IP? I took a look at the iptables rules, however, they are created automatically, and I did not get it really right what it all wants to tell me yet and what is there for what (not every rule uses -m comment --comment $hint). :-) So how do I teach OpneStack custom provided IP addresses? Best regards, Christian. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Unit tests, individual vs. test suite
On 6/29/12 10:57 AM, Kevin L. Mitchell wrote: On Fri, 2012-06-29 at 10:34 -0500, Andrew Bogott wrote: $ /opt/stack/nova$ ./run_tests.sh test_virt_drivers AbstractDriverTestCase test_add_to_aggregateERROR 0.02 test_agent_updateERROR 0.02 etc. And yet, if I scroll up and look at the earlier run (where everything passed) I see it running AbstractDriverTestCase with all green. Try: ./run_tests.sh nova.tests.test_virt_drivers and see if there's any difference with the full path as compared to the abbreviated path? That works! So, what's happening exactly? Is the qualified.test.path used as a cwd for running the test? -A ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] How do I stop image-create from using /tmp?
I'm running nova image-create for the first time, and on the compute node I see: qemu-img convert -f qcow2 -O qcow2 -s 98a8efe9ec114b489eb163c64661441a /virt/pools/openstack_2/instance-0011/disk /tmp/tmpH9KkUZ/98a8efe9ec114b489eb163c64661441a I am concerned to see this operation dropping a disk image into /tmp. What if the disk image is larger than the root filesystem? Is there a way to have OpenStack put these temporary images somewhere else? I would prefer instance_dir by default, instead of /tmp, because instance_dir has already been provisioned with enough space to meet the needs of disk images, but an explicit parameter would probably be a better option. -- Lars Kellogg-Stedman l...@seas.harvard.edu | Senior Technologist| http://ac.seas.harvard.edu/ Academic Computing | http://code.seas.harvard.edu/ Harvard School of Engineering and Applied Sciences | ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Still Failing: quantal_folsom_nova_trunk #60
Title: quantal_folsom_nova_trunk
General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_nova_trunk/60/Project:quantal_folsom_nova_trunkDate of build:Fri, 29 Jun 2012 07:28:33 -0400Build duration:2 min 49 secBuild cause:Started by user zulBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesNo ChangesConsole Output[...truncated 1366 lines...]Download error on http://pypi.python.org/simple/setuptools-git/: [Errno 101] Network is unreachable -- Some packages may not be found!Couldn't find index page for 'setuptools_git' (maybe misspelled?)Download error on http://pypi.python.org/simple/: [Errno 101] Network is unreachable -- Some packages may not be found!No local packages or download links found for setuptools-git>=0.4Traceback (most recent call last): File "setup.py", line 100, in py_modules=[]) File "/usr/lib/python2.7/distutils/core.py", line 112, in setup_setup_distribution = dist = klass(attrs) File "/usr/lib/python2.7/dist-packages/setuptools/dist.py", line 221, in __init__self.fetch_build_eggs(attrs.pop('setup_requires')) File "/usr/lib/python2.7/dist-packages/setuptools/dist.py", line 245, in fetch_build_eggsparse_requirements(requires), installer=self.fetch_build_egg File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 576, in resolvedist = best[req.key] = env.best_match(req, self, installer) File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 821, in best_matchreturn self.obtain(req, installer) # try and download/install File "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 833, in obtainreturn installer(requirement) File "/usr/lib/python2.7/dist-packages/setuptools/dist.py", line 294, in fetch_build_eggreturn cmd.easy_install(req) File "/usr/lib/python2.7/dist-packages/setuptools/command/easy_install.py", line 602, in easy_installraise DistutilsError(msg)distutils.errors.DistutilsError: Could not find suitable distribution for Requirement.parse('setuptools-git>=0.4')ERROR:root:Error occurred during package creation/buildERROR:root:Command '['/usr/bin/schroot', '-r', '-c', 'quantal-amd64-a368577b-46dc-4394-9eed-8a78d1b4d420', '-u', 'jenkins', '--', 'python', 'setup.py', 'sdist']' returned non-zero exit status 1INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/nova/quantal-folsom-proposed /tmp/tmpYCtnco/novamk-build-deps -i -r -t apt-get -y /tmp/tmpYCtnco/nova/debian/controlpython setup.py sdistTraceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 138, in raise esubprocess.CalledProcessError: Command '['/usr/bin/schroot', '-r', '-c', 'quantal-amd64-a368577b-46dc-4394-9eed-8a78d1b4d420', '-u', 'jenkins', '--', 'python', 'setup.py', 'sdist']' returned non-zero exit status 1Error in sys.excepthook:Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwdu(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 138, in raise esubprocess.CalledProcessError: Command '['/usr/bin/schroot', '-r', '-c', 'quantal-amd64-a368577b-46dc-4394-9eed-8a78d1b4d420', '-u', 'jenkins', '--', 'python', 'setup.py', 'sdist']' returned non-zero exit status 1Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure--
Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications
Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications
More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Still Failing: quantal_folsom_nova_trunk #61
Title: quantal_folsom_nova_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_nova_trunk/61/Project:quantal_folsom_nova_trunkDate of build:Fri, 29 Jun 2012 07:36:10 -0400Build duration:5 min 7 secBuild cause:Started by user zulBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesNo ChangesConsole Output[...truncated 4446 lines...]Build-Time: 47Distribution: quantal-folsomFail-Stage: buildInstall-Time: 41Job: nova_2012.2+git201206290736~quantal-0ubuntu1.dscPackage: novaPackage-Time: 129Source-Version: 2012.2+git201206290736~quantal-0ubuntu1Space: 20724Status: attemptedVersion: 2012.2+git201206290736~quantal-0ubuntu1Finished at 20120629-0741Build needed 00:02:09, 20724k disc spaceERROR:root:Error occurred during package creation/buildERROR:root:Command '['sbuild', '-d', 'quantal-folsom', '-n', '-A', 'nova_2012.2+git201206290736~quantal-0ubuntu1.dsc']' returned non-zero exit status 2INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/nova/quantal-folsom-proposed /tmp/tmpyHtjVl/novamk-build-deps -i -r -t apt-get -y /tmp/tmpyHtjVl/nova/debian/controlpython setup.py sdistgit log -n1 --no-merges --pretty=format:%Hgit log 0dc32690fe158e4cb11c2c9bcc65acaf73b94a7a..HEAD --no-merges --pretty=format:[%h] %sbzr merge lp:~openstack-ubuntu-testing/nova/quantal-folsom --forcedch -b -D quantal --newversion 2012.2+git201206290736~quantal-0ubuntu1 Automated Ubuntu testing build:dch -b -D quantal --newversion 2012.2+git201206290736~quantal-0ubuntu1 Automated Ubuntu testing build:debcommitbzr builddeb -S -- -sa -us -ucbzr builddeb -S -- -sa -us -ucdebsign -k9935ACDC nova_2012.2+git201206290736~quantal-0ubuntu1_source.changessbuild -d quantal-folsom -n -A nova_2012.2+git201206290736~quantal-0ubuntu1.dscTraceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 138, in raise esubprocess.CalledProcessError: Command '['sbuild', '-d', 'quantal-folsom', '-n', '-A', 'nova_2012.2+git201206290736~quantal-0ubuntu1.dsc']' returned non-zero exit status 2Error in sys.excepthook:Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwdu(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 138, in raise esubprocess.CalledProcessError: Command '['sbuild', '-d', 'quantal-folsom', '-n', '-A', 'nova_2012.2+git201206290736~quantal-0ubuntu1.dsc']' returned non-zero exit status 2Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Fixed: quantal_folsom_nova_trunk #62
Title: quantal_folsom_nova_trunk General InformationBUILD SUCCESSBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_nova_trunk/62/Project:quantal_folsom_nova_trunkDate of build:Fri, 29 Jun 2012 08:18:20 -0400Build duration:6 min 28 secBuild cause:Started by user zulBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: 4 out of the last 5 builds failed.20ChangesNo ChangesConsole Output[...truncated 12528 lines...]deleting and forgetting pool/main/n/nova/nova-api-os-compute_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-api-os-volume_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-api_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-cert_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-common_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-compute-kvm_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-compute-lxc_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-compute-qemu_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-compute-uml_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-compute-xcp_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-compute-xen_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-compute_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-console_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-consoleauth_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-doc_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-network_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-objectstore_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-scheduler_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-vncproxy_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-volume_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-xcp-network_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/nova-xcp-plugins_2012.2+git201206281633~quantal-0ubuntu1_all.debdeleting and forgetting pool/main/n/nova/python-nova_2012.2+git201206281633~quantal-0ubuntu1_all.debINFO:root:Pushing changes back to bzr testing branchPushed up to revision 402.INFO:root:Storing current commit for next build: d01e0bc661b7a266ee79df4bd3277e6489f749e9INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/nova/quantal-folsom-proposed /tmp/tmpHH8M0R/novamk-build-deps -i -r -t apt-get -y /tmp/tmpHH8M0R/nova/debian/controlpython setup.py sdistgit log -n1 --no-merges --pretty=format:%Hgit log 0dc32690fe158e4cb11c2c9bcc65acaf73b94a7a..HEAD --no-merges --pretty=format:[%h] %sbzr merge lp:~openstack-ubuntu-testing/nova/quantal-folsom --forcedch -b -D quantal --newversion 2012.2+git201206290819~quantal-0ubuntu1 Automated Ubuntu testing build:dch -b -D quantal --newversion 2012.2+git201206290819~quantal-0ubuntu1 Automated Ubuntu testing build:debcommitbzr builddeb -S -- -sa -us -ucbzr builddeb -S -- -sa -us -ucdebsign -k9935ACDC nova_2012.2+git201206290819~quantal-0ubuntu1_source.changessbuild -d quantal-folsom -n -A nova_2012.2+git201206290819~quantal-0ubuntu1.dscdput ppa:openstack-ubuntu-testing/folsom-trunk-testing nova_2012.2+git201206290819~quantal-0ubuntu1_source.changesreprepro --waitforlock 10 -Vb /var/lib/jenkins/www/apt include quantal-folsom nova_2012.2+git201206290819~quantal-0ubuntu1_amd64.changesbzr push lp:~openstack-ubuntu-testing/nova/quantal-folsom+ [ ! 0 ]+ jenkins-cli build quantal_folsom_deployEmail was triggered for: FixedTrigger Success was overridden by another trigger and will not send an email.Sending email for trigger: Fixed-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Failure: quantal_folsom_python-keystoneclient_trunk #19
Title: quantal_folsom_python-keystoneclient_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_python-keystoneclient_trunk/19/Project:quantal_folsom_python-keystoneclient_trunkDate of build:Fri, 29 Jun 2012 12:01:54 -0400Build duration:1 min 19 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: 3 out of the last 5 builds failed.40ChangesDo not display None in pretty tables for fields with no valueby vuntzeditkeystoneclient/utils.pyConsole Output[...truncated 1033 lines...]hard linking tests/test_service_catalog.py -> python-keystoneclient-0.1.1.2/testshard linking tests/test_shell.py -> python-keystoneclient-0.1.1.2/testshard linking tests/test_utils.py -> python-keystoneclient-0.1.1.2/testshard linking tests/utils.py -> python-keystoneclient-0.1.1.2/testshard linking tests/v2_0/__init__.py -> python-keystoneclient-0.1.1.2/tests/v2_0hard linking tests/v2_0/test_auth.py -> python-keystoneclient-0.1.1.2/tests/v2_0hard linking tests/v2_0/test_discovery.py -> python-keystoneclient-0.1.1.2/tests/v2_0hard linking tests/v2_0/test_ec2.py -> python-keystoneclient-0.1.1.2/tests/v2_0hard linking tests/v2_0/test_endpoints.py -> python-keystoneclient-0.1.1.2/tests/v2_0hard linking tests/v2_0/test_roles.py -> python-keystoneclient-0.1.1.2/tests/v2_0hard linking tests/v2_0/test_services.py -> python-keystoneclient-0.1.1.2/tests/v2_0hard linking tests/v2_0/test_tenants.py -> python-keystoneclient-0.1.1.2/tests/v2_0hard linking tests/v2_0/test_tokens.py -> python-keystoneclient-0.1.1.2/tests/v2_0hard linking tests/v2_0/test_users.py -> python-keystoneclient-0.1.1.2/tests/v2_0hard linking tools/generate_authors.sh -> python-keystoneclient-0.1.1.2/toolshard linking tools/install_venv.py -> python-keystoneclient-0.1.1.2/toolshard linking tools/pip-requires -> python-keystoneclient-0.1.1.2/toolshard linking tools/test-requires -> python-keystoneclient-0.1.1.2/toolshard linking tools/with_venv.sh -> python-keystoneclient-0.1.1.2/toolscopying setup.cfg -> python-keystoneclient-0.1.1.2Writing python-keystoneclient-0.1.1.2/setup.cfgcreating distCreating tar archiveremoving 'python-keystoneclient-0.1.1.2' (and everything under it)ERROR:root:Error occurred during package creation/buildERROR:root:[Errno 2] No such file or directory: '/tmp/tmpBEOEh_/git/python-keystoneclient/dist/python-keystoneclient-0.1.0.1.tar.gz'INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/python-keystoneclient/quantal-folsom-proposed /tmp/tmpBEOEh_/python-keystoneclientmk-build-deps -i -r -t apt-get -y /tmp/tmpBEOEh_/python-keystoneclient/debian/controlpython setup.py sdistTraceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 138, in raise eIOError: [Errno 2] No such file or directory: '/tmp/tmpBEOEh_/git/python-keystoneclient/dist/python-keystoneclient-0.1.0.1.tar.gz'Error in sys.excepthook:Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwdu(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 138, in raise eIOError: [Errno 2] No such file or directory: '/tmp/tmpBEOEh_/git/python-keystoneclient/dist/python-keystoneclient-0.1.0.1.tar.gz'Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Still Failing: quantal_folsom_python-novaclient_trunk #14
Title: quantal_folsom_python-novaclient_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_python-novaclient_trunk/14/Project:quantal_folsom_python-novaclient_trunkDate of build:Fri, 29 Jun 2012 13:01:54 -0400Build duration:1 min 18 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: 4 out of the last 5 builds failed.20ChangesIndicate unused variables and other misc. house cleaning.by josheditnovaclient/shell.pyeditnovaclient/v1_1/security_groups.pyeditnovaclient/v1_1/servers.pyeditnovaclient/utils.pyeditnovaclient/base.pyedittests/v1_1/test_servers.pyeditnovaclient/__init__.pyeditnovaclient/v1_1/shell.pyConsole Output[...truncated 1055 lines...]hard linking tests/v1_1/test_floating_ips.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_hosts.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_images.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_keypairs.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_limits.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_quota_classes.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_quotas.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_security_group_rules.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_security_groups.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_servers.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_shell.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_usage.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/testfile.txt -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/utils.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tools/install_venv.py -> python-novaclient-2.6.1.15/toolshard linking tools/nova.bash_completion -> python-novaclient-2.6.1.15/toolshard linking tools/pip-requires -> python-novaclient-2.6.1.15/toolshard linking tools/test-requires -> python-novaclient-2.6.1.15/toolshard linking tools/with_venv.sh -> python-novaclient-2.6.1.15/toolscopying setup.cfg -> python-novaclient-2.6.1.15Writing python-novaclient-2.6.1.15/setup.cfgcreating distCreating tar archiveremoving 'python-novaclient-2.6.1.15' (and everything under it)ERROR:root:Error occurred during package creation/buildERROR:root:[Errno 2] No such file or directory: '/tmp/tmpERlhzv/git/python-novaclient/dist/python-novaclient-2.6.1.12.tar.gz'INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/python-novaclient/quantal-folsom-proposed /tmp/tmpERlhzv/python-novaclientmk-build-deps -i -r -t apt-get -y /tmp/tmpERlhzv/python-novaclient/debian/controlpython setup.py sdistTraceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 138, in raise eIOError: [Errno 2] No such file or directory: '/tmp/tmpERlhzv/git/python-novaclient/dist/python-novaclient-2.6.1.12.tar.gz'Error in sys.excepthook:Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwdu(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 138, in raise eIOError: [Errno 2] No such file or directory: '/tmp/tmpERlhzv/git/python-novaclient/dist/python-novaclient-2.6.1.12.tar.gz'Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Still Failing: precise_folsom_python-novaclient_trunk #15
Title: precise_folsom_python-novaclient_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/precise_folsom_python-novaclient_trunk/15/Project:precise_folsom_python-novaclient_trunkDate of build:Fri, 29 Jun 2012 13:01:54 -0400Build duration:1 min 22 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: 4 out of the last 5 builds failed.20ChangesIndicate unused variables and other misc. house cleaning.by josheditnovaclient/__init__.pyedittests/v1_1/test_servers.pyeditnovaclient/shell.pyeditnovaclient/v1_1/shell.pyeditnovaclient/utils.pyeditnovaclient/v1_1/servers.pyeditnovaclient/v1_1/security_groups.pyeditnovaclient/base.pyConsole Output[...truncated 794 lines...]hard linking tests/v1_1/test_floating_ips.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_hosts.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_images.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_keypairs.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_limits.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_quota_classes.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_quotas.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_security_group_rules.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_security_groups.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_servers.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_shell.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/test_usage.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/testfile.txt -> python-novaclient-2.6.1.15/tests/v1_1hard linking tests/v1_1/utils.py -> python-novaclient-2.6.1.15/tests/v1_1hard linking tools/install_venv.py -> python-novaclient-2.6.1.15/toolshard linking tools/nova.bash_completion -> python-novaclient-2.6.1.15/toolshard linking tools/pip-requires -> python-novaclient-2.6.1.15/toolshard linking tools/test-requires -> python-novaclient-2.6.1.15/toolshard linking tools/with_venv.sh -> python-novaclient-2.6.1.15/toolscopying setup.cfg -> python-novaclient-2.6.1.15Writing python-novaclient-2.6.1.15/setup.cfgcreating distCreating tar archiveremoving 'python-novaclient-2.6.1.15' (and everything under it)ERROR:root:Error occurred during package creation/buildERROR:root:[Errno 2] No such file or directory: '/tmp/tmp2d8875/git/python-novaclient/dist/python-novaclient-2.6.1.12.tar.gz'INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/python-novaclient/precise-folsom-proposed /tmp/tmp2d8875/python-novaclientmk-build-deps -i -r -t apt-get -y /tmp/tmp2d8875/python-novaclient/debian/controlpython setup.py sdistTraceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 138, in raise eIOError: [Errno 2] No such file or directory: '/tmp/tmp2d8875/git/python-novaclient/dist/python-novaclient-2.6.1.12.tar.gz'Error in sys.excepthook:Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwdu(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 138, in raise eIOError: [Errno 2] No such file or directory: '/tmp/tmp2d8875/git/python-novaclient/dist/python-novaclient-2.6.1.12.tar.gz'Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Still Failing: quantal_folsom_python-novaclient_trunk #15
Title: quantal_folsom_python-novaclient_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_python-novaclient_trunk/15/Project:quantal_folsom_python-novaclient_trunkDate of build:Fri, 29 Jun 2012 14:01:54 -0400Build duration:1 min 48 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: 4 out of the last 5 builds failed.20ChangesAdd hypervisor information extension.by kevin.mitchelledittests/v1_1/test_shell.pyaddtests/v1_1/test_hypervisors.pyedittests/v1_1/fakes.pyaddnovaclient/v1_1/hypervisors.pyeditnovaclient/v1_1/shell.pyeditnovaclient/v1_1/client.pyConsole Output[...truncated 1057 lines...]hard linking tests/v1_1/test_hosts.py -> python-novaclient-2.6.1.16/tests/v1_1hard linking tests/v1_1/test_hypervisors.py -> python-novaclient-2.6.1.16/tests/v1_1hard linking tests/v1_1/test_images.py -> python-novaclient-2.6.1.16/tests/v1_1hard linking tests/v1_1/test_keypairs.py -> python-novaclient-2.6.1.16/tests/v1_1hard linking tests/v1_1/test_limits.py -> python-novaclient-2.6.1.16/tests/v1_1hard linking tests/v1_1/test_quota_classes.py -> python-novaclient-2.6.1.16/tests/v1_1hard linking tests/v1_1/test_quotas.py -> python-novaclient-2.6.1.16/tests/v1_1hard linking tests/v1_1/test_security_group_rules.py -> python-novaclient-2.6.1.16/tests/v1_1hard linking tests/v1_1/test_security_groups.py -> python-novaclient-2.6.1.16/tests/v1_1hard linking tests/v1_1/test_servers.py -> python-novaclient-2.6.1.16/tests/v1_1hard linking tests/v1_1/test_shell.py -> python-novaclient-2.6.1.16/tests/v1_1hard linking tests/v1_1/test_usage.py -> python-novaclient-2.6.1.16/tests/v1_1hard linking tests/v1_1/testfile.txt -> python-novaclient-2.6.1.16/tests/v1_1hard linking tests/v1_1/utils.py -> python-novaclient-2.6.1.16/tests/v1_1hard linking tools/install_venv.py -> python-novaclient-2.6.1.16/toolshard linking tools/nova.bash_completion -> python-novaclient-2.6.1.16/toolshard linking tools/pip-requires -> python-novaclient-2.6.1.16/toolshard linking tools/test-requires -> python-novaclient-2.6.1.16/toolshard linking tools/with_venv.sh -> python-novaclient-2.6.1.16/toolscopying setup.cfg -> python-novaclient-2.6.1.16Writing python-novaclient-2.6.1.16/setup.cfgcreating distCreating tar archiveremoving 'python-novaclient-2.6.1.16' (and everything under it)ERROR:root:Error occurred during package creation/buildERROR:root:[Errno 2] No such file or directory: '/tmp/tmpW7J2Px/git/python-novaclient/dist/python-novaclient-2.6.1.12.tar.gz'INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/python-novaclient/quantal-folsom-proposed /tmp/tmpW7J2Px/python-novaclientmk-build-deps -i -r -t apt-get -y /tmp/tmpW7J2Px/python-novaclient/debian/controlpython setup.py sdistTraceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 138, in raise eIOError: [Errno 2] No such file or directory: '/tmp/tmpW7J2Px/git/python-novaclient/dist/python-novaclient-2.6.1.12.tar.gz'Error in sys.excepthook:Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwdu(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 138, in raise eIOError: [Errno 2] No such file or directory: '/tmp/tmpW7J2Px/git/python-novaclient/dist/python-novaclient-2.6.1.12.tar.gz'Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Still Failing: precise_folsom_nova_trunk #65
Title: precise_folsom_nova_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/precise_folsom_nova_trunk/65/Project:precise_folsom_nova_trunkDate of build:Fri, 29 Jun 2012 18:01:54 -0400Build duration:5 min 21 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesAbility to read deleted system metadata records.by brian.lamareditnova/compute/manager.pyeditnova/db/sqlalchemy/api.pyConsole Output[...truncated 3464 lines...]Build-Time: 47Distribution: precise-folsomFail-Stage: buildInstall-Time: 58Job: nova_2012.2+git201206291802~precise-0ubuntu1.dscPackage: novaPackage-Time: 121Source-Version: 2012.2+git201206291802~precise-0ubuntu1Space: 20652Status: attemptedVersion: 2012.2+git201206291802~precise-0ubuntu1Finished at 20120629-1807Build needed 00:02:01, 20652k disc spaceERROR:root:Error occurred during package creation/buildERROR:root:Command '['sbuild', '-d', 'precise-folsom', '-n', '-A', 'nova_2012.2+git201206291802~precise-0ubuntu1.dsc']' returned non-zero exit status 2INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/nova/precise-folsom-proposed /tmp/tmp8NeIQg/novamk-build-deps -i -r -t apt-get -y /tmp/tmp8NeIQg/nova/debian/controlpython setup.py sdistgit log -n1 --no-merges --pretty=format:%Hgit log 0dc32690fe158e4cb11c2c9bcc65acaf73b94a7a..HEAD --no-merges --pretty=format:[%h] %sbzr merge lp:~openstack-ubuntu-testing/nova/precise-folsom --forcedch -b -D precise --newversion 2012.2+git201206291802~precise-0ubuntu1 Automated Ubuntu testing build:dch -b -D precise --newversion 2012.2+git201206291802~precise-0ubuntu1 Automated Ubuntu testing build:debcommitbzr builddeb -S -- -sa -us -ucbzr builddeb -S -- -sa -us -ucdebsign -k9935ACDC nova_2012.2+git201206291802~precise-0ubuntu1_source.changessbuild -d precise-folsom -n -A nova_2012.2+git201206291802~precise-0ubuntu1.dscTraceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 138, in raise esubprocess.CalledProcessError: Command '['sbuild', '-d', 'precise-folsom', '-n', '-A', 'nova_2012.2+git201206291802~precise-0ubuntu1.dsc']' returned non-zero exit status 2Error in sys.excepthook:Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwdu(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 138, in raise esubprocess.CalledProcessError: Command '['sbuild', '-d', 'precise-folsom', '-n', '-A', 'nova_2012.2+git201206291802~precise-0ubuntu1.dsc']' returned non-zero exit status 2Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Fixed: quantal_folsom_python-novaclient_trunk #16
Title: quantal_folsom_python-novaclient_trunk General InformationBUILD SUCCESSBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_python-novaclient_trunk/16/Project:quantal_folsom_python-novaclient_trunkDate of build:Fri, 29 Jun 2012 20:25:16 -0400Build duration:3 min 21 secBuild cause:Started by user adamBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: 3 out of the last 5 builds failed.40ChangesNo ChangesConsole Output[...truncated 2083 lines...]Status: successfulVersion: 2.6.1.16+git201206292025~quantal-0ubuntu1Finished at 20120629-2028Build needed 00:01:38, 1796k disc spaceINFO:root:Uploading package to ppa:openstack-ubuntu-testing/folsom-trunk-testinggpg: Signature made Fri Jun 29 20:26:51 2012 EDT using RSA key ID 9935ACDCgpg: Good signature from "Openstack Ubuntu Testing Bot (Jenkins Key) <ja...@shingle-house.org.uk>"gpg: Signature made Fri Jun 29 20:26:51 2012 EDT using RSA key ID 9935ACDCgpg: Good signature from "Openstack Ubuntu Testing Bot (Jenkins Key) <ja...@shingle-house.org.uk>"Checking signature on .changesGood signature on /tmp/tmp3_48e0/python-novaclient_2.6.1.16+git201206292025~quantal-0ubuntu1_source.changes.Checking signature on .dscGood signature on /tmp/tmp3_48e0/python-novaclient_2.6.1.16+git201206292025~quantal-0ubuntu1.dsc.Uploading to ppa (via ftp to ppa.launchpad.net): Uploading python-novaclient_2.6.1.16+git201206292025~quantal-0ubuntu1.dsc: done. Uploading python-novaclient_2.6.1.16+git201206292025~quantal.orig.tar.gz: done. Uploading python-novaclient_2.6.1.16+git201206292025~quantal-0ubuntu1.debian.tar.gz: done. Uploading python-novaclient_2.6.1.16+git201206292025~quantal-0ubuntu1_source.changes: done.Successfully uploaded packages.INFO:root:Installing build artifacts into /var/lib/jenkins/www/aptSkipping inclusion of 'python-novaclient' '2.6.1.16+git201206292025~quantal-0ubuntu1' in 'quantal-folsom|main|amd64', as it has already '2012.2+git201206221431~quantal-0ubuntu1'.Deleting files just added to the pool but not used.(to avoid use --keepunusednewfiles next time)deleting and forgetting pool/main/p/python-novaclient/python-novaclient_2.6.1.16+git201206292025~quantal-0ubuntu1_all.debINFO:root:Pushing changes back to bzr testing branchPushed up to revision 43.INFO:root:Storing current commit for next build: a11788515e800a95d5b83448c2a9403eed509bdfINFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/python-novaclient/quantal-folsom-proposed /tmp/tmp3_48e0/python-novaclientmk-build-deps -i -r -t apt-get -y /tmp/tmp3_48e0/python-novaclient/debian/controlpython setup.py sdistgit log -n1 --no-merges --pretty=format:%Hgit log 0248ae78ecf5b7e9cddf74b9e25714b0bf02d60b..HEAD --no-merges --pretty=format:[%h] %sbzr merge lp:~openstack-ubuntu-testing/python-novaclient/quantal-folsom --forcedch -b -D quantal --newversion 2.6.1.16+git201206292025~quantal-0ubuntu1 Automated Ubuntu testing build:dch -b -D quantal --newversion 2.6.1.16+git201206292025~quantal-0ubuntu1 Automated Ubuntu testing build:debcommitbzr builddeb -S -- -sa -us -ucbzr builddeb -S -- -sa -us -ucdebsign -k9935ACDC python-novaclient_2.6.1.16+git201206292025~quantal-0ubuntu1_source.changessbuild -d quantal-folsom -n -A python-novaclient_2.6.1.16+git201206292025~quantal-0ubuntu1.dscdput ppa:openstack-ubuntu-testing/folsom-trunk-testing python-novaclient_2.6.1.16+git201206292025~quantal-0ubuntu1_source.changesreprepro --waitforlock 10 -Vb /var/lib/jenkins/www/apt include quantal-folsom python-novaclient_2.6.1.16+git201206292025~quantal-0ubuntu1_amd64.changesbzr push lp:~openstack-ubuntu-testing/python-novaclient/quantal-folsomEmail was triggered for: FixedTrigger Success was overridden by another trigger and will not send an email.Sending email for trigger: Fixed-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Fixed: precise_folsom_python-keystoneclient_trunk #17
Title: precise_folsom_python-keystoneclient_trunk General InformationBUILD SUCCESSBuild URL:https://jenkins.qa.ubuntu.com/job/precise_folsom_python-keystoneclient_trunk/17/Project:precise_folsom_python-keystoneclient_trunkDate of build:Fri, 29 Jun 2012 20:29:25 -0400Build duration:3 min 25 secBuild cause:Started by user adamBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: 2 out of the last 5 builds failed.60ChangesNo ChangesConsole Output[...truncated 1595 lines...]Space: 1184Status: successfulVersion: 0.1.1.2+git201206292029~precise-0ubuntu1Finished at 20120629-2032Build needed 00:01:05, 1184k disc spaceINFO:root:Uploading package to ppa:openstack-ubuntu-testing/folsom-trunk-testinggpg: Signature made Fri Jun 29 20:31:35 2012 EDT using RSA key ID 9935ACDCgpg: Good signature from "Openstack Ubuntu Testing Bot (Jenkins Key) <ja...@shingle-house.org.uk>"gpg: Signature made Fri Jun 29 20:31:35 2012 EDT using RSA key ID 9935ACDCgpg: Good signature from "Openstack Ubuntu Testing Bot (Jenkins Key) <ja...@shingle-house.org.uk>"Checking signature on .changesGood signature on /tmp/tmpu6WssC/python-keystoneclient_0.1.1.2+git201206292029~precise-0ubuntu1_source.changes.Checking signature on .dscGood signature on /tmp/tmpu6WssC/python-keystoneclient_0.1.1.2+git201206292029~precise-0ubuntu1.dsc.Uploading to ppa (via ftp to ppa.launchpad.net): Uploading python-keystoneclient_0.1.1.2+git201206292029~precise-0ubuntu1.dsc: done. Uploading python-keystoneclient_0.1.1.2+git201206292029~precise.orig.tar.gz: done. Uploading python-keystoneclient_0.1.1.2+git201206292029~precise-0ubuntu1.debian.tar.gz: done. Uploading python-keystoneclient_0.1.1.2+git201206292029~precise-0ubuntu1_source.changes: done.Successfully uploaded packages.INFO:root:Installing build artifacts into /var/lib/jenkins/www/aptSkipping inclusion of 'python-keystoneclient' '0.1.1.2+git201206292029~precise-0ubuntu1' in 'precise-folsom|main|amd64', as it has already '2012.2+git201206251354~precise-0ubuntu1'.Deleting files just added to the pool but not used.(to avoid use --keepunusednewfiles next time)deleting and forgetting pool/main/p/python-keystoneclient/python-keystoneclient_0.1.1.2+git201206292029~precise-0ubuntu1_all.debINFO:root:Pushing changes back to bzr testing branchPushed up to revision 33.INFO:root:Storing current commit for next build: 3ed4007e1136c7a0266f51c5b6b98e88997a5f60INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/python-keystoneclient/precise-folsom-proposed /tmp/tmpu6WssC/python-keystoneclientmk-build-deps -i -r -t apt-get -y /tmp/tmpu6WssC/python-keystoneclient/debian/controlpython setup.py sdistgit log -n1 --no-merges --pretty=format:%Hbzr merge lp:~openstack-ubuntu-testing/python-keystoneclient/precise-folsom --forcedch -b -D precise --newversion 0.1.1.2+git201206292029~precise-0ubuntu1 Automated Ubuntu testing build:dch -b -D precise --newversion 0.1.1.2+git201206292029~precise-0ubuntu1 Automated Ubuntu testing build:debcommitbzr builddeb -S -- -sa -us -ucbzr builddeb -S -- -sa -us -ucdebsign -k9935ACDC python-keystoneclient_0.1.1.2+git201206292029~precise-0ubuntu1_source.changessbuild -d precise-folsom -n -A python-keystoneclient_0.1.1.2+git201206292029~precise-0ubuntu1.dscdput ppa:openstack-ubuntu-testing/folsom-trunk-testing python-keystoneclient_0.1.1.2+git201206292029~precise-0ubuntu1_source.changesreprepro --waitforlock 10 -Vb /var/lib/jenkins/www/apt include precise-folsom python-keystoneclient_0.1.1.2+git201206292029~precise-0ubuntu1_amd64.changesbzr push lp:~openstack-ubuntu-testing/python-keystoneclient/precise-folsomEmail was triggered for: FixedTrigger Success was overridden by another trigger and will not send an email.Sending email for trigger: Fixed-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Failure: precise_folsom_quantum_trunk #15
Title: precise_folsom_quantum_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/precise_folsom_quantum_trunk/15/Project:precise_folsom_quantum_trunkDate of build:Fri, 29 Jun 2012 20:32:50 -0400Build duration:2.6 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: 1 out of the last 5 builds failed.80ChangesImplement IP address allocation.by gkottoneditquantum/tests/unit/test_api_v2.pyeditquantum/db/models_v2.pyeditquantum/db/db_base_plugin_v2.pyeditquantum/common/exceptions.pyeditquantum/api/v2/base.pyeditquantum/api/v2/router.pyeditquantum/tests/unit/test_db_plugin.pyConsole OutputStarted by an SCM changeBuilding remotely on pkg-builderCheckout:precise_folsom_quantum_trunk / /var/lib/jenkins/slave/workspace/precise_folsom_quantum_trunk - hudson.remoting.Channel@56c88357:pkg-builderUsing strategy: DefaultLast Built Revision: Revision f54a788cae726b8e1480e27c0a416c66a7afb373 (origin/master)Checkout:quantum / /var/lib/jenkins/slave/workspace/precise_folsom_quantum_trunk/quantum - hudson.remoting.LocalChannel@42eb0c97Wiping out workspace first.Cloning the remote Git repositoryCloning repository originFetching upstream changes from https://github.com/openstack/quantum.gitCommencing build of Revision 681d096ef26247f6f8db8faca1abe9ae6a186562 (origin/master)Checking out Revision 681d096ef26247f6f8db8faca1abe9ae6a186562 (origin/master)No emails were triggered.[precise_folsom_quantum_trunk] $ /bin/sh -xe /tmp/hudson591172915766251728.sh+ /var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package -jINFO:root:Creating tarball using git archiveERROR:root:Error occurred during package creation/buildERROR:root:local variable 'tarball_dst' referenced before assignmentINFO:root:Complete command log:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 135, in raise eUnboundLocalError: local variable 'tarball_dst' referenced before assignmentBuild step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Failure: quantal_folsom_quantum_trunk #16
Title: quantal_folsom_quantum_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/quantal_folsom_quantum_trunk/16/Project:quantal_folsom_quantum_trunkDate of build:Fri, 29 Jun 2012 20:32:53 -0400Build duration:3.8 secBuild cause:Started by an SCM changeBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: 1 out of the last 5 builds failed.80ChangesImplement IP address allocation.by gkottoneditquantum/db/models_v2.pyeditquantum/tests/unit/test_db_plugin.pyeditquantum/tests/unit/test_api_v2.pyeditquantum/common/exceptions.pyeditquantum/api/v2/base.pyeditquantum/db/db_base_plugin_v2.pyeditquantum/api/v2/router.pyConsole OutputStarted by an SCM changeBuilding remotely on pkg-builderCheckout:quantal_folsom_quantum_trunk / /var/lib/jenkins/slave/workspace/quantal_folsom_quantum_trunk - hudson.remoting.Channel@56c88357:pkg-builderUsing strategy: DefaultLast Built Revision: Revision f54a788cae726b8e1480e27c0a416c66a7afb373 (origin/master)Checkout:quantum / /var/lib/jenkins/slave/workspace/quantal_folsom_quantum_trunk/quantum - hudson.remoting.LocalChannel@42eb0c97Wiping out workspace first.Cloning the remote Git repositoryCloning repository originFetching upstream changes from https://github.com/openstack/quantum.gitCommencing build of Revision 681d096ef26247f6f8db8faca1abe9ae6a186562 (origin/master)Checking out Revision 681d096ef26247f6f8db8faca1abe9ae6a186562 (origin/master)No emails were triggered.[quantal_folsom_quantum_trunk] $ /bin/sh -xe /tmp/hudson8557260322014164511.sh+ /var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package -jINFO:root:Creating tarball using git archiveERROR:root:Error occurred during package creation/buildERROR:root:local variable 'tarball_dst' referenced before assignmentINFO:root:Complete command log:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 135, in raise eUnboundLocalError: local variable 'tarball_dst' referenced before assignmentBuild step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Fixed: precise_folsom_python-novaclient_trunk #17
Title: precise_folsom_python-novaclient_trunk General InformationBUILD SUCCESSBuild URL:https://jenkins.qa.ubuntu.com/job/precise_folsom_python-novaclient_trunk/17/Project:precise_folsom_python-novaclient_trunkDate of build:Fri, 29 Jun 2012 20:29:32 -0400Build duration:4 min 8 secBuild cause:Started by user adamBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: 3 out of the last 5 builds failed.40ChangesNo ChangesConsole Output[...truncated 1706 lines...]Status: successfulVersion: 2.6.1.16+git201206292029~precise-0ubuntu1Finished at 20120629-2033Build needed 00:01:50, 1788k disc spaceINFO:root:Uploading package to ppa:openstack-ubuntu-testing/folsom-trunk-testinggpg: Signature made Fri Jun 29 20:31:40 2012 EDT using RSA key ID 9935ACDCgpg: Good signature from "Openstack Ubuntu Testing Bot (Jenkins Key) <ja...@shingle-house.org.uk>"gpg: Signature made Fri Jun 29 20:31:40 2012 EDT using RSA key ID 9935ACDCgpg: Good signature from "Openstack Ubuntu Testing Bot (Jenkins Key) <ja...@shingle-house.org.uk>"Checking signature on .changesGood signature on /tmp/tmpVSbyyt/python-novaclient_2.6.1.16+git201206292029~precise-0ubuntu1_source.changes.Checking signature on .dscGood signature on /tmp/tmpVSbyyt/python-novaclient_2.6.1.16+git201206292029~precise-0ubuntu1.dsc.Uploading to ppa (via ftp to ppa.launchpad.net): Uploading python-novaclient_2.6.1.16+git201206292029~precise-0ubuntu1.dsc: done. Uploading python-novaclient_2.6.1.16+git201206292029~precise.orig.tar.gz: done. Uploading python-novaclient_2.6.1.16+git201206292029~precise-0ubuntu1.debian.tar.gz: done. Uploading python-novaclient_2.6.1.16+git201206292029~precise-0ubuntu1_source.changes: done.Successfully uploaded packages.INFO:root:Installing build artifacts into /var/lib/jenkins/www/aptSkipping inclusion of 'python-novaclient' '2.6.1.16+git201206292029~precise-0ubuntu1' in 'precise-folsom|main|amd64', as it has already '2012.2+git201206221431~precise-0ubuntu1'.Deleting files just added to the pool but not used.(to avoid use --keepunusednewfiles next time)deleting and forgetting pool/main/p/python-novaclient/python-novaclient_2.6.1.16+git201206292029~precise-0ubuntu1_all.debINFO:root:Pushing changes back to bzr testing branchPushed up to revision 41.INFO:root:Storing current commit for next build: a11788515e800a95d5b83448c2a9403eed509bdfINFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/python-novaclient/precise-folsom-proposed /tmp/tmpVSbyyt/python-novaclientmk-build-deps -i -r -t apt-get -y /tmp/tmpVSbyyt/python-novaclient/debian/controlpython setup.py sdistgit log -n1 --no-merges --pretty=format:%Hgit log 0248ae78ecf5b7e9cddf74b9e25714b0bf02d60b..HEAD --no-merges --pretty=format:[%h] %sbzr merge lp:~openstack-ubuntu-testing/python-novaclient/precise-folsom --forcedch -b -D precise --newversion 2.6.1.16+git201206292029~precise-0ubuntu1 Automated Ubuntu testing build:dch -b -D precise --newversion 2.6.1.16+git201206292029~precise-0ubuntu1 Automated Ubuntu testing build:debcommitbzr builddeb -S -- -sa -us -ucbzr builddeb -S -- -sa -us -ucdebsign -k9935ACDC python-novaclient_2.6.1.16+git201206292029~precise-0ubuntu1_source.changessbuild -d precise-folsom -n -A python-novaclient_2.6.1.16+git201206292029~precise-0ubuntu1.dscdput ppa:openstack-ubuntu-testing/folsom-trunk-testing python-novaclient_2.6.1.16+git201206292029~precise-0ubuntu1_source.changesreprepro --waitforlock 10 -Vb /var/lib/jenkins/www/apt include precise-folsom python-novaclient_2.6.1.16+git201206292029~precise-0ubuntu1_amd64.changesbzr push lp:~openstack-ubuntu-testing/python-novaclient/precise-folsomEmail was triggered for: FixedTrigger Success was overridden by another trigger and will not send an email.Sending email for trigger: Fixed-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
[Openstack-ubuntu-testing-notifications] Build Still Failing: precise_folsom_nova_trunk #66
Title: precise_folsom_nova_trunk General InformationBUILD FAILUREBuild URL:https://jenkins.qa.ubuntu.com/job/precise_folsom_nova_trunk/66/Project:precise_folsom_nova_trunkDate of build:Fri, 29 Jun 2012 20:29:16 -0400Build duration:5 min 53 secBuild cause:Started by user adamBuilt on:pkg-builderHealth ReportWDescriptionScoreBuild stability: All recent builds failed.0ChangesNo ChangesConsole Output[...truncated 3464 lines...]Build-Time: 47Distribution: precise-folsomFail-Stage: buildInstall-Time: 42Job: nova_2012.2+git201206292029~precise-0ubuntu1.dscPackage: novaPackage-Time: 107Source-Version: 2012.2+git201206292029~precise-0ubuntu1Space: 20652Status: attemptedVersion: 2012.2+git201206292029~precise-0ubuntu1Finished at 20120629-2035Build needed 00:01:47, 20652k disc spaceERROR:root:Error occurred during package creation/buildERROR:root:Command '['sbuild', '-d', 'precise-folsom', '-n', '-A', 'nova_2012.2+git201206292029~precise-0ubuntu1.dsc']' returned non-zero exit status 2INFO:root:Complete command log:INFO:root:Destroying schroot.bzr branch lp:~openstack-ubuntu-testing/nova/precise-folsom-proposed /tmp/tmpp3Vf91/novamk-build-deps -i -r -t apt-get -y /tmp/tmpp3Vf91/nova/debian/controlpython setup.py sdistgit log -n1 --no-merges --pretty=format:%Hgit log 0dc32690fe158e4cb11c2c9bcc65acaf73b94a7a..HEAD --no-merges --pretty=format:[%h] %sbzr merge lp:~openstack-ubuntu-testing/nova/precise-folsom --forcedch -b -D precise --newversion 2012.2+git201206292029~precise-0ubuntu1 Automated Ubuntu testing build:dch -b -D precise --newversion 2012.2+git201206292029~precise-0ubuntu1 Automated Ubuntu testing build:debcommitbzr builddeb -S -- -sa -us -ucbzr builddeb -S -- -sa -us -ucdebsign -k9935ACDC nova_2012.2+git201206292029~precise-0ubuntu1_source.changessbuild -d precise-folsom -n -A nova_2012.2+git201206292029~precise-0ubuntu1.dscTraceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 135, in raise esubprocess.CalledProcessError: Command '['sbuild', '-d', 'precise-folsom', '-n', '-A', 'nova_2012.2+git201206292029~precise-0ubuntu1.dsc']' returned non-zero exit status 2Error in sys.excepthook:Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/apport_python_hook.py", line 68, in apport_excepthookbinary = os.path.realpath(os.path.join(os.getcwdu(), sys.argv[0]))OSError: [Errno 2] No such file or directoryOriginal exception was:Traceback (most recent call last): File "/var/lib/jenkins/tools/openstack-ubuntu-testing/bin/build-package", line 135, in raise esubprocess.CalledProcessError: Command '['sbuild', '-d', 'precise-folsom', '-n', '-A', 'nova_2012.2+git201206292029~precise-0ubuntu1.dsc']' returned non-zero exit status 2Build step 'Execute shell' marked build as failureEmail was triggered for: FailureSending email for trigger: Failure-- Mailing list: https://launchpad.net/~openstack-ubuntu-testing-notifications Post to : openstack-ubuntu-testing-notifications@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-ubuntu-testing-notifications More help : https://help.launchpad.net/ListHelp
