Re: [Openstack] Integration tests
Matt Dietz wrote: Ditto On 9/12/11 2:10 PM, Sandy Walsh sandy.wa...@rackspace.com wrote: From: Jay Pipes [jaypi...@gmail.com] Can we discuss pulling novaclient into Nova's source tree at the design summit? +1 Someone should file it at summit.openstack.org, then :) -- 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] Integrating new Dashboard with Cactus Nova setup
Alle martedì 13 settembre 2011, Rasika Karunathilaka ha scritto: Hi Team, I have successfully configured Openstack Nova Cactus release on Ubuntu 11.04 and it is working fine on my two node cluster. However I would like to integrate latest dashboard into Cactus nova deployment and get rich features of the new dashboard. I have already downloaded source of keystone and dashboard and configured them so that I could login to dashboard. However my existing nova instance is not correctly associated with new dashboard. Therefore all the link inside my new dashboard display error messages as Unable to get usage info:invalid service catalog service: nova Unable to retreive image infor from glance: Invalid service catalog service: glance (HTTP 404) Could you please direct me towards documentation to correct the above? or Highly appreciate your help to resolve this. Cheers! Rasika Karunathilaka Hi I'm not the maintainer of my answer could not be considered *official*. I think you couldn't do this, because since the Cactus release a lot of things were improved, inserted, renamed, featured, so you risk to spend a lot of time debugging and patching incompatible versions. Next nova release is very close so...it could be worthable to wait this major milestone and try the latest dashboard on it. just my 2 cents :) Carlo ___ 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] Reminder: OpenStack team meeting - 21:00 UTC
Hello everyone, Our team meeting will take place at 21:00 UTC this Tuesday in #openstack-meeting on IRC. PTLs, if you can't make it, please name a substitute on [2]. We are one week before Diablo final release, so I'd like us to focus on release-critical bugs for Nova and Glance. We'll therefore review the status at: https://launchpad.net/glance/+milestone/2011.3 https://launchpad.net/nova/+milestone/2011.3 We need to make sure all known release-critical bugs are listed in those lists, with assignees committed to delivering a bugfix ASAP :) Check out how that meeting time translates for *your* timezone: [1] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20110913T21 See the meeting agenda, edit the wiki to add new topics for discussion: [2] http://wiki.openstack.org/Meetings/TeamMeeting Cheers, -- 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] Integration tests
done From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Thierry Carrez [thie...@openstack.org] Sent: Tuesday, September 13, 2011 6:57 AM To: openstack@lists.launchpad.net Subject: Re: [Openstack] Integration tests Matt Dietz wrote: Ditto On 9/12/11 2:10 PM, Sandy Walsh sandy.wa...@rackspace.com wrote: From: Jay Pipes [jaypi...@gmail.com] Can we discuss pulling novaclient into Nova's source tree at the design summit? +1 Someone should file it at summit.openstack.org, then :) -- 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 This email may include confidential information. If you received it in error, please delete it. ___ 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] Diablo 4 dashboard error Unable to get usage info: (OperationalError) no such column: vm_state
hi when i run the diablo-4 dashboard,Has the following error : Unable to get usage info: (OperationalError) no such column: vm_state uselect id,image_ref,project_id,user_id,vcpus,hostname,display_name,host,vm_state,instance_type_id,launched_at,terminated_at from instances where (terminated_at is NULL or terminated_at '2011-09-01 00:00:00') and (launched_at '2011-09-13 15:55:32.288462') and project_id='cloud' () Don't know who met didn't ? 2011-09-14 atkisc ___ 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] Diablo 4 dashboard error Unable to get usage info: (OperationalError) no such column: vm_state
vm_state was added to the instance model in d4 - if you are upgrading, you will need to migrate: nova-manage db sync A On Tue, Sep 13, 2011 at 9:21 AM, atkisc atk...@gmail.com wrote: ** hi when i run the diablo-4 dashboard,Has the following error : Unable to get usage info: (OperationalError) no such column: vm_state uselect id,image_ref,project_id,user_id,vcpus,hostname,display_name,host,vm_state,instance_type_id,launched_at,terminated_at from instances where (terminated_at is NULL or terminated_at '2011-09-01 00:00:00') and (launched_at '2011-09-13 15:55:32.288462') and project_id='cloud' () Don't know who met didn't ? 2011-09-14 -- atkisc ___ 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] Diablo 4 dashboard error Unable to get usage info: (OperationalError) no such column: vm_state
It may help you to know that the issue you are having is a Nova issue, not a Dashboard issue. You should open a question on launchpad.net/nova and paste your full stack trace. On Sep 13, 2011, at 9:21 AM, atkisc wrote: hi when i run the diablo-4 dashboard,Has the following error : Unable to get usage info: (OperationalError) no such column: vm_state uselect id,image_ref,project_id,user_id,vcpus,hostname,display_name,host,vm_state,instance_type_id,launched_at,terminated_at from instances where (terminated_at is NULL or terminated_at '2011-09-01 00:00:00') and (launched_at '2011-09-13 15:55:32.288462') and project_id='cloud' () Don't know who met didn't ? 2011-09-14 atkisc ___ 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] [Swift] [Keystone] Account migration
Hello Stackers, With swauth, Swift accounts are identified by reseller_prefix_hash. Under Keystone (with swift_auth and Swift's lazy provisioning), I see the Swift account now has the format reseller_prefix_tenantId. So, if we have existing Swift account data with the old format, how would one go about migrating from the old format to the Keystone format? Is there a plan to do so within the Diablo time-frame? Thanks, Liem ___ 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] [Swift] [Keystone] Account migration
Swift treats the hash or tenantid part of the account as an opaque string. (Technically, the first one isn't a hash but a uuid.) I don't think there is any migration path because there is nothing to migrate. But I may be missing something. --John On Sep 13, 2011, at 2:55 PM, Nguyen, Liem Manh wrote: Hello Stackers, With swauth, Swift accounts are identified by reseller_prefix_hash. Under Keystone (with swift_auth and Swift’s lazy provisioning), I see the Swift account now has the format reseller_prefix_tenantId. So, if we have existing Swift account data with the old format, how would one go about migrating from the old format to the Keystone format? Is there a plan to do so within the Diablo time-frame? Thanks, Liem ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp smime.p7s Description: S/MIME cryptographic 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] [Swift] [Keystone] Account migration
Thanks, John, for pointing out the uuid thing :). So, let's say I have stored data into a Swift account with a UUID. When I switch to using Keystone, I would like to continue using my old account, since I have a bunch of data in it. However, the account format has changed (under Keystone). So, if I have lazy provisioning on (account_autocreate), would I *accidentally* have 2 Swift accounts instead of one? Ideally, if I can migrate all the old account Ids to use the new format, that would guarantee consistency between the old accounts and any newly-created accounts. Am I missing something here? Liem -Original Message- From: John Dickinson [mailto:m...@not.mn] Sent: Tuesday, September 13, 2011 1:11 PM To: Nguyen, Liem Manh Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [Swift] [Keystone] Account migration Swift treats the hash or tenantid part of the account as an opaque string. (Technically, the first one isn't a hash but a uuid.) I don't think there is any migration path because there is nothing to migrate. But I may be missing something. --John On Sep 13, 2011, at 2:55 PM, Nguyen, Liem Manh wrote: Hello Stackers, With swauth, Swift accounts are identified by reseller_prefix_hash. Under Keystone (with swift_auth and Swift's lazy provisioning), I see the Swift account now has the format reseller_prefix_tenantId. So, if we have existing Swift account data with the old format, how would one go about migrating from the old format to the Keystone format? Is there a plan to do so within the Diablo time-frame? Thanks, Liem ___ 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] [Swift] [Keystone] Account migration
Why would the account need to change? Can the swift account reference in keystone be set to the old value? If not, then yes you will have 2 swift accounts. On Sep 13, 2011, at 3:48 PM, Nguyen, Liem Manh wrote: Thanks, John, for pointing out the uuid thing :). So, let's say I have stored data into a Swift account with a UUID. When I switch to using Keystone, I would like to continue using my old account, since I have a bunch of data in it. However, the account format has changed (under Keystone). So, if I have lazy provisioning on (account_autocreate), would I *accidentally* have 2 Swift accounts instead of one? Ideally, if I can migrate all the old account Ids to use the new format, that would guarantee consistency between the old accounts and any newly-created accounts. Am I missing something here? Liem -Original Message- From: John Dickinson [mailto:m...@not.mn] Sent: Tuesday, September 13, 2011 1:11 PM To: Nguyen, Liem Manh Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [Swift] [Keystone] Account migration Swift treats the hash or tenantid part of the account as an opaque string. (Technically, the first one isn't a hash but a uuid.) I don't think there is any migration path because there is nothing to migrate. But I may be missing something. --John On Sep 13, 2011, at 2:55 PM, Nguyen, Liem Manh wrote: Hello Stackers, With swauth, Swift accounts are identified by reseller_prefix_hash. Under Keystone (with swift_auth and Swift's lazy provisioning), I see the Swift account now has the format reseller_prefix_tenantId. So, if we have existing Swift account data with the old format, how would one go about migrating from the old format to the Keystone format? Is there a plan to do so within the Diablo time-frame? Thanks, Liem ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp smime.p7s Description: S/MIME cryptographic 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] [Swift] [Keystone] Account migration
If there is an existing swift customer with swift account 'foo' and nova project 'bar', there is no way to have them belong to the same Keystone tenant. I think that is the data migration issue. Jason -Original Message- From: openstack-bounces+jason.rouault=hp@lists.launchpad.net [mailto:openstack-bounces+jason.rouault=hp@lists.launchpad.net] On Behalf Of Nguyen, Liem Manh Sent: Tuesday, September 13, 2011 2:49 PM To: John Dickinson Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [Swift] [Keystone] Account migration Thanks, John, for pointing out the uuid thing :). So, let's say I have stored data into a Swift account with a UUID. When I switch to using Keystone, I would like to continue using my old account, since I have a bunch of data in it. However, the account format has changed (under Keystone). So, if I have lazy provisioning on (account_autocreate), would I *accidentally* have 2 Swift accounts instead of one? Ideally, if I can migrate all the old account Ids to use the new format, that would guarantee consistency between the old accounts and any newly-created accounts. Am I missing something here? Liem -Original Message- From: John Dickinson [mailto:m...@not.mn] Sent: Tuesday, September 13, 2011 1:11 PM To: Nguyen, Liem Manh Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [Swift] [Keystone] Account migration Swift treats the hash or tenantid part of the account as an opaque string. (Technically, the first one isn't a hash but a uuid.) I don't think there is any migration path because there is nothing to migrate. But I may be missing something. --John On Sep 13, 2011, at 2:55 PM, Nguyen, Liem Manh wrote: Hello Stackers, With swauth, Swift accounts are identified by reseller_prefix_hash. Under Keystone (with swift_auth and Swift's lazy provisioning), I see the Swift account now has the format reseller_prefix_tenantId. So, if we have existing Swift account data with the old format, how would one go about migrating from the old format to the Keystone format? Is there a plan to do so within the Diablo time-frame? Thanks, Liem ___ 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 smime.p7s Description: S/MIME cryptographic 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] [Swift] [Keystone] Account migration
Swift uses the entire account string as part of the lookup. Therefore a different account string means that everything associated with that account (account, containers, and objects) would have to be rehashed. That's basically a fancy way of saying copy the data from the old account to the new one, or, as was originally stated, migrate. There are no plans to migrate accounts in swift from one account string to another (ie account rename). --John On Sep 13, 2011, at 3:57 PM, Souza, Bob wrote: John, If you migrate a user's account ID from uuid to reseller_prefix_tenant, dhw would you find an object that was stored in the ring based on is (uuid, container, object) tuple? Or maybe you are suggesting that is bad idea? b -Original Message- From: openstack-bounces+bob.souza=hp@lists.launchpad.net [mailto:openstack-bounces+bob.souza=hp@lists.launchpad.net] On Behalf Of John Dickinson Sent: Tuesday, September 13, 2011 4:11 PM To: Nguyen, Liem Manh Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [Swift] [Keystone] Account migration Swift treats the hash or tenantid part of the account as an opaque string. (Technically, the first one isn't a hash but a uuid.) I don't think there is any migration path because there is nothing to migrate. But I may be missing something. --John On Sep 13, 2011, at 2:55 PM, Nguyen, Liem Manh wrote: Hello Stackers, With swauth, Swift accounts are identified by reseller_prefix_hash. Under Keystone (with swift_auth and Swift's lazy provisioning), I see the Swift account now has the format reseller_prefix_tenantId. So, if we have existing Swift account data with the old format, how would one go about migrating from the old format to the Keystone format? Is there a plan to do so within the Diablo time-frame? Thanks, Liem ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp smime.p7s Description: S/MIME cryptographic 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] [Swift] [Keystone] Account migration
Without changing the account id, how do I map the uuid of the old account to a Keystone tenant Id? For a given tenantId, I would like to be able to reference both the corresponding Swift account and Nova project, right? Liem -Original Message- From: John Dickinson [mailto:m...@not.mn] Sent: Tuesday, September 13, 2011 2:01 PM To: Nguyen, Liem Manh Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [Swift] [Keystone] Account migration Why would the account need to change? Can the swift account reference in keystone be set to the old value? If not, then yes you will have 2 swift accounts. On Sep 13, 2011, at 3:48 PM, Nguyen, Liem Manh wrote: Thanks, John, for pointing out the uuid thing :). So, let's say I have stored data into a Swift account with a UUID. When I switch to using Keystone, I would like to continue using my old account, since I have a bunch of data in it. However, the account format has changed (under Keystone). So, if I have lazy provisioning on (account_autocreate), would I *accidentally* have 2 Swift accounts instead of one? Ideally, if I can migrate all the old account Ids to use the new format, that would guarantee consistency between the old accounts and any newly-created accounts. Am I missing something here? Liem -Original Message- From: John Dickinson [mailto:m...@not.mn] Sent: Tuesday, September 13, 2011 1:11 PM To: Nguyen, Liem Manh Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [Swift] [Keystone] Account migration Swift treats the hash or tenantid part of the account as an opaque string. (Technically, the first one isn't a hash but a uuid.) I don't think there is any migration path because there is nothing to migrate. But I may be missing something. --John On Sep 13, 2011, at 2:55 PM, Nguyen, Liem Manh wrote: Hello Stackers, With swauth, Swift accounts are identified by reseller_prefix_hash. Under Keystone (with swift_auth and Swift's lazy provisioning), I see the Swift account now has the format reseller_prefix_tenantId. So, if we have existing Swift account data with the old format, how would one go about migrating from the old format to the Keystone format? Is there a plan to do so within the Diablo time-frame? Thanks, Liem ___ 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-poc] Meeting tomorrow
Jay Pipes wrote: As for the API coordinator, I thought we had already voted yes on that? My position on the API coordinator is that there is no need for amending our governance and creating an official position for that. I'm all in favor of a technical meritocracy where someone that cares about a subject (or is paid to care about a subject) and does a great job of owning the subject ends up being respected by his peers and be responsible for it. So if Jorge wants to work on API guidelines and convergence efforts, I don't think that needs to be voted by the PPB beforehand. He can just start working on that and do a great job at it. And anyone interested can join him. The PPB /could/ be called to resolve conflicts (between PTLs, or between people working on API guideliens and PTLs) if there are any, under its attribution of ensuring commonality and integration between projects -- but I surely hope concerns can be directly addressed between the interested parties. And by the way (and before anyone inserts snarky comments), that also applies to the release management job. Anyone interested is free to help me there. And everyone can ultimately appeal to the PPB if there is disagreement. This is a duty, not a set of rights. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ Mailing list: https://launchpad.net/~openstack-poc Post to : openstack-poc@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack-poc More help : https://help.launchpad.net/ListHelp
