Re: [Openstack] [openstack-dev] Cinder-service connectivity issues

2015-03-25 Thread Vishvananda Ishaya 
Based on the checkin times in your post, it looks like time is out of sync 
between your nodes. The one reporting down is reporting time in the future. I 
would install ntp and make sure the clocks are in sync.

Vish

On Mar 25, 2015, at 2:33 AM, Kamsali, RaghavendraChari (Artesyn) 
 wrote:

>  
> Please find attachment log (c-api) , when I execute command cinder create 1.
>  
>  
> From: Kamsali, RaghavendraChari (Artesyn) 
> [mailto:raghavendrachari.kams...@artesyn.com] 
> Sent: Wednesday, March 25, 2015 1:39 PM
> To: Ritesh Nanda
> Cc: openstack-...@lists.openstack.org; openstack@lists.openstack.org
> Subject: Re: [Openstack] Cinder-service connectivity issues
>  
> FYI,
>  
> From: Ritesh Nanda [mailto:riteshnand...@gmail.com] 
> Sent: Wednesday, March 25, 2015 1:09 PM
> To: Kamsali, RaghavendraChari [ENGINEERING/IN]
> Cc: openstack@lists.openstack.org; openstack-...@lists.openstack.org
> Subject: Re: [Openstack] Cinder-service connectivity issues
>  
> Can you run cinder-scheduler , volume service in debug mode and paste the 
> logs.
>  
> Regards,
> Ritesh 
>  
> On Wed, Mar 25, 2015 at 12:10 AM, Kamsali, RaghavendraChari (Artesyn) 
>  wrote:
> Hi,
>  
> My setup is shown below having  three networks (management, storage, 
> data/virtual) .
>  
>  
> 
>  
> Am facing issue when I bring up the setup as shown above scenario , could 
> anyone help me to figure out did I configured incorrectly or doing anything 
> wrong .
>  
> On Controller Node
>  
> SERVICES ENABLED: (c-sch,c-api)
> Management-> 192.168.21.108
> Storage-> 10.130.98.97
>  
> Cinder_configarations :
>  
> my_ip : 10.130.98.97 (also tried 19.2168.21.108)
> glance_host:10.130.98.97 (also tried 192.168.21.108)
> iscsi_ip_address: 10.130.98.97 (also tried 192.168.21.108)
>  
> 
>  
>  
> 
>  
> On Storage Node
>  
> SERVICES ENABLED: (c-vol)
> Management -> 192.1689.21.107
> Stroage -> 10.130.98.136
>  
> my_ip : 10.130.98.97 (also tried 19.2168.21.108)
> glance_host:10.130.98.97 (also tried 192.168.21.108)
> iscsi_ip_address: 10.130.98.97 (also tried 192.168.21.108)
> lvmdriver-1.iscsi_ip_address   : 10.130.98.136 (also tried 192.168.21.107)
>  
>  
> 
>  
>  
> Thanks and Regards,
> Raghavendrachari kamsali | Software Engineer II  | Embedded Computing
> Artesyn Embedded Technologies | 5th Floor, Capella Block, The V, Madhapur| 
> Hyderabad, AP 500081 India
>  
> 
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> 
> 
> 
>  
> --
>  With Regards 
>  Ritesh Nanda
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [Nova] How to confirm I have the right database schema when checkout to another branch?

2014-06-20 Thread Vishvananda Ishaya 
You need to remove the old .pyc files in the migrate_repo/versions directory. I 
have an alias in my .gitconfig to allow me to checkout a branch and delete pycs 
in one command:

[alias]
cc = !"TOP=$(git rev-parse --show-toplevel); find $TOP -name '*.pyc' 
-delete; git-checkout”

so i can do:

git cc some-branch

Vish

On Jun 11, 2014, at 7:54 PM, 严超  wrote:

> Hi, All:
> When I checkout nova to another branch. how to confirm I have the 
> right database schema ?
> When I run "nova-manage db sync", I've got below error:
> 
> 2014-06-11 22:53:27.977 CRITICAL nova [-] KeyError: 
> 
> 2014-06-11 22:53:27.977 TRACE nova Traceback (most recent call last):
> 2014-06-11 22:53:27.977 TRACE nova   File "/usr/local/bin/nova-manage", line 
> 10, in 
> 2014-06-11 22:53:27.977 TRACE nova sys.exit(main())
> 2014-06-11 22:53:27.977 TRACE nova   File 
> "/opt/stack/nova/nova/cmd/manage.py", line 1376, in main
> 2014-06-11 22:53:27.977 TRACE nova ret = fn(*fn_args, **fn_kwargs)
> 2014-06-11 22:53:27.977 TRACE nova   File 
> "/opt/stack/nova/nova/cmd/manage.py", line 885, in sync
> 2014-06-11 22:53:27.977 TRACE nova return migration.db_sync(version)
> 2014-06-11 22:53:27.977 TRACE nova   File 
> "/opt/stack/nova/nova/db/migration.py", line 32, in db_sync
> 2014-06-11 22:53:27.977 TRACE nova return IMPL.db_sync(version=version)
> 2014-06-11 22:53:27.977 TRACE nova   File 
> "/opt/stack/nova/nova/db/sqlalchemy/migration.py", line 44, in db_sync
> 2014-06-11 22:53:27.977 TRACE nova return 
> versioning_api.upgrade(get_engine(), repository, version)
> 2014-06-11 22:53:27.977 TRACE nova   File 
> "/usr/local/lib/python2.7/dist-packages/migrate/versioning/api.py", line 186, 
> in upgrade
> 2014-06-11 22:53:27.977 TRACE nova return _migrate(url, repository, 
> version, upgrade=True, err=err, **opts)
> 2014-06-11 22:53:27.977 TRACE nova   File "", line 2, in _migrate
> 2014-06-11 22:53:27.977 TRACE nova   File 
> "/usr/local/lib/python2.7/dist-packages/migrate/versioning/util/__init__.py", 
> line 160, in with_engine
> 2014-06-11 22:53:27.977 TRACE nova return f(*a, **kw)
> 2014-06-11 22:53:27.977 TRACE nova   File 
> "/usr/local/lib/python2.7/dist-packages/migrate/versioning/api.py", line 345, 
> in _migrate
> 2014-06-11 22:53:27.977 TRACE nova changeset = schema.changeset(version)
> 2014-06-11 22:53:27.977 TRACE nova   File 
> "/usr/local/lib/python2.7/dist-packages/migrate/versioning/schema.py", line 
> 82, in changeset
> 2014-06-11 22:53:27.977 TRACE nova changeset = 
> self.repository.changeset(database, start_ver, version)
> 2014-06-11 22:53:27.977 TRACE nova   File 
> "/usr/local/lib/python2.7/dist-packages/migrate/versioning/repository.py", 
> line 225, in changeset
> 2014-06-11 22:53:27.977 TRACE nova changes = 
> [self.version(v).script(database, op) for v in versions]
> 2014-06-11 22:53:27.977 TRACE nova   File 
> "/usr/local/lib/python2.7/dist-packages/migrate/versioning/repository.py", 
> line 189, in version
> 2014-06-11 22:53:27.977 TRACE nova return self.versions.version(*p, **k)
> 2014-06-11 22:53:27.977 TRACE nova   File 
> "/usr/local/lib/python2.7/dist-packages/migrate/versioning/version.py", line 
> 173, in version
> 2014-06-11 22:53:27.977 TRACE nova return self.versions[VerNum(vernum)]
> 2014-06-11 22:53:27.977 TRACE nova KeyError: 
> 2014-06-11 22:53:27.977 TRACE nova 
> 
> 
> Best Regards！
> Chao Yan
> --
> My twitter：Andy Yan @yanchao727
> My Weibo：http://weibo.com/herewearenow
> --
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Glance - and the use of the "project_id:%(project_id)" rule

2014-06-26 Thread Vishvananda Ishaya 
IIRC glance uses owner instead of project_id as the field in various places 
representing the tenant that owns the object. Perhaps you might try 
“project_id:%(owner)s”

Vish

On May 2, 2014, at 7:21 AM, Michael Hearn  wrote:

> Having played with the policies and rules within glance's policy.json file I 
> have not had any success using the rule, "project_id:%(project_id)" to 
> restrict api usage.
> Without changing user/role/tenant  I have had success using 
> project_id:%(project_id)" with cinder.
> I cannot find anything to suggest glance's policy engine cannot parse the 
> rule but would like confirmation.  
> Can anyone verify this?.
> 
> This is using icehouse, glance 0.12.0
> 
> ~Mike 
> 
> 
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] [openstack-dev] [qa] "nova get-password" does not seem to work

2014-10-15 Thread Vishvananda Ishaya 
Get password only works if you have something in the guest generating the
encrypted password and posting it to the metadata server. Cloud-init for
windows (the primary use case) will do this for you. You can do something
similar for ubuntu using this script:

https://gist.github.com/vishvananda/4008762

If cirros has usermod and openssl installed it may work there as well. Note
that you can pass the script in as userdata (see the comments at the end).

Vish

On Oct 15, 2014, at 8:02 AM, Danny Choi (dannchoi)  wrote:

> Hi,
> 
> I used devstack to deploy Juno OpenStack.
> 
> I spin up an instance with cirros-0.3.2-x86_64-uec.
> 
> By default, useranme/password is cirrus/cubswin:)
> 
> When I execute the command “nova get-password”, nothing is returned.
> 
> localadmin@qa4:/etc/nova$ nova show vm1
> +--++
> | Property | Value
>   |
> +--++
> | OS-DCF:diskConfig| MANUAL   
>   |
> | OS-EXT-AZ:availability_zone  | nova 
>   |
> | OS-EXT-STS:power_state   | 1
>   |
> | OS-EXT-STS:task_state| -
>   |
> | OS-EXT-STS:vm_state  | active   
>   |
> | OS-SRV-USG:launched_at   | 2014-10-15T14:48:04.00   
>   |
> | OS-SRV-USG:terminated_at | -
>   |
> | accessIPv4   |  
>   |
> | accessIPv6   |  
>   |
> | config_drive |  
>   |
> | created  | 2014-10-15T14:47:56Z 
>   |
> | flavor   | m1.tiny (1)  
>   |
> | hostId   | 
> ea715752b11cf96b95f9742513a351d2d6571c4fdb76f497d64ecddb   |
> | id   | 1a3c487e-c3a3-4783-bd0b-e3c87bf22c3f 
>   |
> | image| cirros-0.3.2-x86_64-uec 
> (1dda953b-9319-4c43-bd20-1ef75b491553) |
> | key_name | cirros-key   
>   |
> | metadata | {}   
>   |
> | name | vm1  
>   |
> | os-extended-volumes:volumes_attached | []   
>   |
> | private network  | 10.0.0.11
>   |
> | progress | 0
>   |
> | security_groups  | default  
>   |
> | status   | ACTIVE   
>   |
> | tenant_id| c8daf9bd6dda40a982b074322c08da7d 
>   |
> | updated  | 2014-10-15T14:48:04Z 
>   |
> | user_id  | 2cbbafae01404d4ebeb6e6fbacfa6546 
>   |
> +--++
> localadmin@qa4:/etc/nova$ nova help get-password
> usage: nova get-password  []
> 
> Get password for a server.
> 
> Positional arguments:
>  Name or ID of server.
> Private key (used locally to decrypt password) (Optional).
>  When specified, the command displays the clear (decrypted) VM
>  password. When not specified, the ciphered VM password is
>  displayed.
> localadmin@qa4:/etc/nova$ nova get-password vm1 
>   <[NOTHING RETURNED]
> localadmin@qa4:/etc/nova$ 
> 
> Am I missing something?
> 
> Thanks,
> Danny
> ___
> OpenStack-dev mailing list
> openstack-...@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



signature.asc
Description: Message signed with OpenPGP using GPG