[Openstack] nova service in dashboard cannot work.
Hi, First I installed nova, glance, keystone and python-novaclient from git and them work fine. Now I am ready to use dashboard. I use clouderbuilders's git and according devstack scripts to install it. Now it seems I can login in webGUI and get some things fine(images, floating, flavor), but the nova service (instances, overview) cannot work. The error show # Unable to get service info: This error may be caused by a misconfigured nova url in keystone's service catalog, or by missing openstackx extensions in nova. See the dashboard README. # and log in nova-api.log is: DEBUG routes.middleware [81bffc26-38d2-40b3-af79-a5081580fd78 admin 1] No route matched for GET /1/admin/services from (pid=32233) __call__ /usr/lib/pymodules/python2.7/routes/middleware.py:97 I checked my keystone db, it is: mysql> select * from endpoint_templates \G; *** 1. row *** id: 1 region: RegionOne service_id: 1 public_url: http://10.200.200.2:8774/v1.1/%tenant_id% admin_url: http://10.200.200.2:8774/v1.1/%tenant_id% internal_url: http://10.200.200.2:8774/v1.1/%tenant_id% enabled: 1 is_global: 1 version_id: NULL version_list: NULL version_info: NULL *** 2. row *** id: 2 region: RegionOne service_id: 2 public_url: http://10.200.200.2:9292/v1.1/%tenant_id% admin_url: http://10.200.200.2:9292/v1.1/%tenant_id% internal_url: http://10.200.200.2:9292/v1.1/%tenant_id% enabled: 1 is_global: 1 version_id: NULL version_list: NULL version_info: NULL *** 3. row *** id: 3 region: RegionOne service_id: 3 public_url: http://127.0.0.1:5000/v2.0 admin_url: http://127.0.0.1:35357/v2.0 internal_url: http://127.0.0.1:5000/v2.0 enabled: 1 is_global: 1 version_id: NULL version_list: NULL version_info: NULL Also I install openstackx from git and put --osapi path in my nova.conf How to resolve this issue? thanks! -- 非淡薄无以明志，非宁静无以致远 ___ 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 Packaging
because i am user.. i am welcoming the new distro to be tested here in our meruvian.. so we can try java-cloud solution on top of it F On Sat, Nov 12, 2011 at 3:02 AM, Chris Wright wrote: > * Tim Bell (tim.b...@cern.ch) wrote: > > > > We would be very interested to know where we can get a recent, stable > Diablo++ release for RHEL 6. We appreciate the speed of development for > Essex but there is also a need for a pre-tested base on Diablo+fixes stable > functionality for the potential production users to integrate to. > > You may need to help w/ some testing there since the (Diablo) packaging > for EPEL is still a work in progress... > > http://fedoraproject.org/wiki/OpenStack#OpenStack_in_EPEL > > thanks, > -chris > > ___ > 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 Newsletter – November 11, 2011
OpenStack Community Newsletter – November 11, 2011 HIGHLIGHTS * New weekly graphs of commit activities on OpenStack main repositories * The OpenStack wiki now accepts Launchpad ID for login (thank you, Chmouel) * OpenStack packaging coordination effort hangs out on irc.freenode.net #openstack-packaging * The OpenStack devroom was accepted at FOSDEM 2012: shine your passport, meet developers in Bruxelles, Feb 4-5 EVENTS * Webinar: Converging OpenStack with NexentaStor Storage Nov 16, 2011 – Register on https://www3.gotomeeting.com/register/389257862 * LinuxCon Brazil Nov 17 – Oct 18, 2011 – Sao Paulo, Brazil https://events.linuxfoundation.org/events/linuxcon-brazil DEVELOPER COMMUNITY * Provide feedback for Image API v 2.0 proposal http://is.gd/6rQzwq GENERAL COMMUNITY * Installation instructions for Swift on CentOS http://wiki.openstack.org/InstallInstructions/Swift/CentOS (thank you, Peter) * An OpenStack security primer, by Matt Joyce http://www.music-piracy.com/?p=494 * OpenStack Wiki Recent Changes – http://wiki.openstack.org/RecentChanges * Nexenta Volume Driver http://wiki.openstack.org/NexentaVolumeDriver * Quantum Essex Roadmap http://wiki.openstack.org/QuantumEssexRoadmap COMMUNITY STATISTICS * A new format for the community statistics: the gallery below shows the activity on some of the OpenStack repositories, lines of code added and removed by the developers during the past week. Let us know what else you would like to see on a weekly basis. Contributions to glance week 44 Contributions to glance week 44 Contributions to keystone week 44 Contributions to keystone week 44 Contributions to manuals week 44 Contributions to manuals week 44 Contributions to nova week 44 Contributions to nova week 44 Contributions to swift week 44 Contributions to quantum week 44 Contributions to swift week 44 Contributions to swift week 44 This 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] Openstack Packaging
* Tim Bell (tim.b...@cern.ch) wrote: > > We would be very interested to know where we can get a recent, stable > Diablo++ release for RHEL 6. We appreciate the speed of development for > Essex but there is also a need for a pre-tested base on Diablo+fixes stable > functionality for the potential production users to integrate to. You may need to help w/ some testing there since the (Diablo) packaging for EPEL is still a work in progress... http://fedoraproject.org/wiki/OpenStack#OpenStack_in_EPEL thanks, -chris ___ 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 Packaging
We would be very interested to know where we can get a recent, stable Diablo++ release for RHEL 6. We appreciate the speed of development for Essex but there is also a need for a pre-tested base on Diablo+fixes stable functionality for the potential production users to integrate to. Tim Bell CERN ___ 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] Keystone's stable/diablo branch
Keystone needs your help testing!
The goal of this branch is to be completely compatible with diablo,
while including as many improvements as possible. Pending your
satisfaction, we'd like to tag this branch in the coming days.
Browse stable/diablo: https://github.com/openstack/keystone/tree/stable/diablo
As is, the stable/diablo branch includes the following changes since
our "2011.3" tag:
- Improved: Documentation!
- Added: Initial schema & data migration support (although no schema
changes have been made)
- Fixed: Duplicated entries in logs (bug 844959)
- Fixed: Version controller looked for templates in the wrong path
- Fixed: Returned inappropriate status codes (bug 843226)
- Fixed: Content types provided by echo client, legacy middleware,
swift middleware
- Fixed: Tenant ID was returned as Service ID in the auth response (bug 882760)
- Fixed: GET /users/{user_id} did not return user name (bug 887833)
- Removed: Execute bit from example keystone.conf
WADLs & XSDs:
- Removed: Atom link from complexType for a Role (bug 859937)
- Removed: Response representation from a HEAD method
Middleware:
- Added: X_TENANT_NAME and X_TENANT_ID headers
- Reverted: X_TENANT header (now deprecated) to use TENANT_NAME
- Fixed: Provided (application/json) in Accept header instead of (text/json)
- Fixed: EC2 middleware used outdated token structure
- Fixed: Swift middleware referenced 'roleref.roleId'
keystone-manage:
- Added: User names to keystone-manage user list
- Fixed: --help not showing usage options
- Fixed: lists of 'objects' and 'actions' were out of date (bug 877504)
Testing:
- Improved: Test coverage!
- Fixed: Running PEP8 in a virtualenv (bug 885380)
Thank you,
-Dolph
___
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 Packaging
Hi, For those who are interested in packaging Openstack for your $DISTRO$ (ubuntu, fedora, debian, etc, etc), we have started an IRC channel on freenode called #openstack-packaging. Stop by if you want to discuss packaging. Regards chuck ___ 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] Bad rsync return code after adding two new disks
I added two new new disks: sdb1 in 192.168.0.12 and sdb1 in 192.168.0.13. (both of these storage nodes already had sda3 which was in zone 2 and 3 respectively). I added a new zone and these two new disks in that zone. Then did rebalance and distributed the ring files all across the cluster. Did I miss any other step? I started noticing these errors (there are some successful rsync as well). > Nov 11 12:12:48 b001 object-replicator Successful rsync of > /srv/node/sda3/objects/19498/86d at [192.168.0.12]::object/sdb1/objects/19498 > (0.209) > Nov 11 12:12:48 b001 object-replicator Bad rsync return code: ['rsync', > '--recursive', '--whole-file', '--human-readable', '--xattrs', > '--itemize-changes', '--ignore-existing', '--timeout=30', '--contimeout=30', > '/srv/node/sda3/objects/51119/350', > '[192.168.0.12]::object/sdb1/objects/51119'] -> 5 > Nov 11 12:12:48 b001 object-replicator Bad rsync return code: ['rsync', > '--recursive', '--whole-file', '--human-readable', '--xattrs', > '--itemize-changes', '--ignore-existing', '--timeout=30', '--contimeout=30', > '/srv/node/sda3/objects/32937/efe', > '[192.168.0.12]::object/sdb1/objects/32937'] -> 5 Same with .13: > Nov 11 12:13:43 b001 object-replicator Successful rsync of > /srv/node/sda3/objects/11047/10d at [192.168.0.13]::object/sdb1/objects/11047 > (0.168) > Nov 11 12:13:43 b001 object-replicator Bad rsync return code: ['rsync', > '--recursive', '--whole-file', '--human-readable', '--xattrs', > '--itemize-changes', '--ignore-existing', '--timeout=30', '--contimeout=30', > '/srv/node/sda3/objects/92247/966', > '[192.168.0.13]::object/sdb1/objects/92247'] -> 5 > Nov 11 12:13:43 b001 object-replicator Bad rsync return code: ['rsync', > '--recursive', '--whole-file', '--human-readable', '--xattrs', > '--itemize-changes', '--ignore-existing', '--timeout=30', '--contimeout=30', > '/srv/node/sda3/objects/50409/be4', > '[192.168.0.13]::object/sdb1/objects/50409'] -> 5 any suggestions? I also noticed this in .12: Nov 11 12:16:16 b002 object-replicator @ERROR: max connections (2) reached -- try again later --sharif -- Sharif Islam Senior Systems Analyst/Programmer FutureGrid (http://futuregrid.org) Pervasive Technology Institute, Indiana University Bloomington ___ 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] Stable branch reviews
Mark McLoughlin writes: > On Fri, 2011-11-11 at 12:11 +0400, Yuriy Taraday wrote: >> I wonder if we should keep Change ID consistent in stable and master >> branches so that if one merged something into master, reviewers >> and archaeologists can easily find both related changes in master and all >> backports of specific change. >> >> The simple scenario is: push change into master, then cherry-pick it on top >> of stable branch(es). Change-Id will be the same, Gerrit will allow one to >> find all such backports by clicking on Change-Id. > > If gerrit can handle it, that would be great. But I'm not sure it does It does work as Yuriy described, and seems to be in keeping with gerrit philosophy. Maybe we should update the wiki to incorporate that. Here's an example: https://review-dev.openstack.org/#q,I1729eb6fb7027808650bae9a87b2d95cc5c5a0f7,n,z > In the mean time, we make sure that all commits to the stable branch > include "cherry picked from X" in the commit message to help > tracking. > > Also, I'm experimenting with using git-notes to keep track of e.g. why > patches on master weren't cherry-picked into stable: > > http://wiki.openstack.org/StableBranch#Keeping_Notes Why not (also) leave review comments to that effect in gerrit? If you started them out with something like "Reviewed for stable inclusion", they'd be easy to spot when scanning the collapsed comments. -Jim ___ 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] Stable branch reviews
On Fri, 2011-11-11 at 12:11 +0400, Yuriy Taraday wrote: > I wonder if we should keep Change ID consistent in stable and master > branches so that if one merged something into master, reviewers > and archaeologists can easily find both related changes in master and all > backports of specific change. > > The simple scenario is: push change into master, then cherry-pick it on top > of stable branch(es). Change-Id will be the same, Gerrit will allow one to > find all such backports by clicking on Change-Id. If gerrit can handle it, that would be great. But I'm not sure it does In the mean time, we make sure that all commits to the stable branch include "cherry picked from X" in the commit message to help tracking. Also, I'm experimenting with using git-notes to keep track of e.g. why patches on master weren't cherry-picked into stable: http://wiki.openstack.org/StableBranch#Keeping_Notes Cheers, Mark. ___ 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 at FOSDEM
Hi everyone, Our OpenStack devroom was accepted for FOSDEM, February 4-5, 2012 in Brussels. It was actually grouped with other "Open Source virtualization and cloud" projects in a giant devroom (550-seat auditorium) that lasts the full 2 days ! Expect a CFP in the coming weeks... See other devrooms at: http://fosdem.org/2012/devrooms_for_2012 -- 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] Stable branch reviews
I wonder if we should keep Change ID consistent in stable and master branches so that if one merged something into master, reviewers and archaeologists can easily find both related changes in master and all backports of specific change. The simple scenario is: push change into master, then cherry-pick it on top of stable branch(es). Change-Id will be the same, Gerrit will allow one to find all such backports by clicking on Change-Id. Kind regards, Yuriy. On Wed, Nov 9, 2011 at 19:50, Thierry Carrez wrote: > Hi everyone, > > Since there seems to be some confusion around master vs. stable/diablo > vs. core reviewers, I think it warrants a small thread. > > When at the Design Summit we discussed setting up stable branches, I > warned about the risks that setting them up brings for trunk development: > > 1) Reduce resources affected to trunk development > 2) Reduce quality of trunk > > To mitigate that, we decided that the group doing stable branch > maintenance would be a separate group (i.e. *not* core developers), and > we decided that whatever ends up in the stable branch must first land in > the master branch. > > So a change goes like this: > * Change is proposed to trunk > * Change is reviewed by core (is it appropriate, well-written, etc) > * Change lands in trunk > * Change is proposed to stable/diablo > * Change is reviewed by stable team (is it relevant for a stable update, > did it land in trunk first) > * Change lands in stable/diablo > > This avoids the aforementioned risks, avoids duplicating review efforts > (the two reviews actually check for different things), and keep the > teams separate (so trunk reviews are not slowed down by stable reviews). > > Note that this does not prevent core developers that have an interest in > stable/diablo from being in the two teams. > > Apparently people in core can easily mistake master for stable/diablo, > and can also +2 stable/diablo changes. In order to avoid mistakes, I > think +2 powers on stable/diablo should be limited to members of the > stable maintenance team (who know their stable review policy). > > That should help avoid mistakes (like landing a fix in stable/diablo > that never made it to master), while not preventing individual core devs > from helping in stable reviews. > > 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 > ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
