[Openstack] MySQL connection gone away handling in OpenStack projects

[Unmesh Gurjar]

Hi,

The current handling of the 'SQL server has gone away' is different across 
OpenStack projects (eg. Nova uses MySQLPingListener, whereas Glance retries the 
db operation to recover connection).
I am curious to know if the fix implemented in 
https://review.openstack.org/5552 will be used across all projects (through 
openstack-common) ?

Thanks & Regards,
Unmesh G.
___
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] Python novaclient boot command parameters

[Unmesh Gurjar]

Hi All,

I had recently submitted changes to the Python novaclient repo for adding the 
support to specify user_data, availability_zone and security_groups in the 
'nova boot' command. The OpenStack API v1.1 spec for the create server API does 
not mention these parameters. Shouldn't these parameters be a part of the 
create server API spec?

Would it be suitable to have these parameters (user data, availability zone, 
security groups, networks) in the 'nova boot' command or whether there should 
be a new 'nova boot-ext' command that will accept these parameters? Should I 
remove the support that I have earlier added for the above parameters in 'nova 
boot' command? I will also be adding support to specify 'networks' at the time 
of instance creation. Should this also be a part of 'nova boot-ext' command?

Thanks,
Unmesh G.


___
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] Unable to start nova-api

[Unmesh Gurjar]

Trinath,

You probably have a wrong config setting. Please check the value of
'network_api_class' in your nova.conf and confirm that the module with the
specified class exists.

The default value of this parameter is "nova.network.api.API", so you
should expect class 'API' in nova/network/api.py of your Nova codebase.

Regards,
Unmesh.

On Tue, Feb 5, 2013 at 3:23 PM, Trinath Somanchi  wrote:

> Hi-
>
>
>
> When I start the nova-api  service, I’m getting this error:
>
>
>
> Can anyone help me troubleshoot the issue
>
>
>
> root@NewFolsomController:/etc/nova# nova-api
> --flagfile=/etc/nova/nova.conf
>
> 2013-02-05 12:29:29 DEBUG nova.utils [-] Inner Exception: No module named
> api from (pid=19874) import_class
> /usr/lib/python2.7/dist-packages/nova/utils.py:78
>
> 2013-02-05 12:29:29 CRITICAL nova [-] Class API could not be found: No
> module named api
>
> 2013-02-05 12:29:29 TRACE nova Traceback (most recent call last):
>
> 2013-02-05 12:29:29 TRACE nova   File "/usr/bin/nova-api", line 51, in
> 
>
> 2013-02-05 12:29:29 TRACE nova servers.append(service.WSGIService(api))
>
> 2013-02-05 12:29:29 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/nova/service.py", line 326, in __init__
>
> 2013-02-05 12:29:29 TRACE nova self.app = self.loader.load_app(name)
>
> 2013-02-05 12:29:29 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/nova/wsgi.py", line 388, in load_app
>
> 2013-02-05 12:29:29 TRACE nova return deploy.loadapp("config:%s" %
> self.config_path, name=name)
>
> 2013-02-05 12:29:29 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 247, in
> loadapp
>
> 2013-02-05 12:29:29 TRACE nova return loadobj(APP, uri, name=name,
> **kw)
>
> 2013-02-05 12:29:29 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 272, in
> loadobj
>
> 2013-02-05 12:29:29 TRACE nova return context.create()
>
> 2013-02-05 12:29:29 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710, in
> create
>
> 2013-02-05 12:29:29 TRACE nova return self.object_type.invoke(self)
>
> 2013-02-05 12:29:29 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 144, in
> invoke
>
> 2013-02-05 12:29:29 TRACE nova **context.local_conf)
>
> 2013-02-05 12:29:29 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/paste/deploy/util.py", line 56, in
> fix_call
>
> 2013-02-05 12:29:29 TRACE nova val = callable(*args, **kw)
>
> 2013-02-05 12:29:29 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/paste/urlmap.py", line 25, in
> urlmap_factory
>
> 2013-02-05 12:29:29 TRACE nova app = loader.get_app(app_name,
> global_conf=global_conf)
>
> 2013-02-05 12:29:29 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 350, in
> get_app
>
> 2013-02-05 12:29:29 TRACE nova name=name,
> global_conf=global_conf).create()
>
> 2013-02-05 12:29:29 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 710, in
> create
>
> 2013-02-05 12:29:29 TRACE nova return self.object_type.invoke(self)
>
> 2013-02-05 12:29:29 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 144, in
> invoke
>
> 2013-02-05 12:29:29 TRACE nova **context.local_conf)
>
> 2013-02-05 12:29:29 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/paste/deploy/util.py", line 56, in
> fix_call
>
> 2013-02-05 12:29:29 TRACE nova val = callable(*args, **kw)
>
> 2013-02-05 12:29:29 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/nova/api/auth.py", line 48, in
> pipeline_factory
>
> 2013-02-05 12:29:29 TRACE nova filters = [loader.get_filter(n) for n
> in pipeline[:-1]]
>
> 2013-02-05 12:29:29 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 354, in
> get_filter
>
> 2013-02-05 12:29:29 TRACE nova name=name,
> global_conf=global_conf).create()
>
> 2013-02-05 12:29:29 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 366, in
> filter_context
>
> 2013-02-05 12:29:29 TRACE nova FILTER, name=name,
> global_conf=global_conf)
>
> 2013-02-05 12:29:29 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 458, in
> get_context
>
> 2013-02-05 12:29:29 TRACE nova section)
>
> 2013-02-05 12:29:29 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 517, in
> _context_from_explicit
>
> 2013-02-05 12:29:29 TRACE nova value = import_string(found_expr)
>
> 2013-02-05 12:29:29 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/paste/deploy/loadwsgi.py", line 22, in
> import_string
>
> 2013-02-05 12:29:29 TRACE nova return
> pkg_resources.EntryPoint.parse("x=" + s).load(False)
>
> 2013-02-05 12:29:29 TRACE nova   File
> "/usr/lib/python2.7/dist-packages/pkg_resources.py", line 1989, in load
>
> 2013-02-05 12:29:29 TRACE nova entry = __import__(self.module_name,
> 

Re: [Openstack] Nova.Scheduler TypeError: can't compare datetime.datetime to NoneType

[Unmesh Gurjar]

Greg,

IMO, this qualifies as a bug.

To debug what's causing this scenario is your case, I would suggest
checking the database connection setting in nova.conf on your Compute &
Controller host. AFAIK, it either means Compute's status is not being
updated (Compute service down) or its being updated in a different database
server.

Hope it helps.

Regards,
Unmesh G.

On Fri, Feb 8, 2013 at 5:55 AM, Greg Chavez  wrote:

>
> So I'm getting this when I try to boot a Cirros image in scheduler.log.  I
> have a controller node, network node, and one compute node setup with
> Folsom on RHEL 6.  Any ideas?  Thanks!
>
> 2013-02-07 19:21:45 WARNING nova.scheduler.manager
> [req-358f5c96-e236-4167-b6a9-ccc02c853d41 65fdf1a86cfa4e50aafb6c132106e00f
> cec6647113c74b66b308de14032e591a] Failed to schedule_run_instance: can't
> compare datetime.datetime to NoneType
> 2013-02-07 19:21:45 WARNING nova.scheduler.manager
> [req-358f5c96-e236-4167-b6a9-ccc02c853d41 65fdf1a86cfa4e50aafb6c132106e00f
> cec6647113c74b66b308de14032e591a] [instance:
> 1a318b16-7d98-40ef-acb9-63d705542200] Setting instance to ERROR state.
> 2013-02-07 19:21:45 1688 ERROR nova.openstack.common.rpc.amqp [-]
> Exception during message handling
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp Traceback
> (most recent call last):
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp   File
> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/amqp.py", line
> 276, in _process_data
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp rval =
> self.proxy.dispatch(ctxt, version, method, **args)
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp   File
> "/usr/lib/python2.6/site-packages/nova/openstack/common/rpc/dispatcher.py",
> line 145, in dispatch
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp return
> getattr(proxyobj, method)(ctxt, **kwargs)
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp   File
> "/usr/lib/python2.6/site-packages/nova/scheduler/manager.py", line 118, in
> run_instance
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp context,
> ex, request_spec)
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp   File
> "/usr/lib64/python2.6/contextlib.py", line 23, in __exit__
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp
> self.gen.next()
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp   File
> "/usr/lib/python2.6/site-packages/nova/scheduler/manager.py", line 106, in
> run_instance
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp
> requested_networks, is_first_time, filter_properties)
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp   File
> "/usr/lib/python2.6/site-packages/nova/scheduler/multi.py", line 69, in
> schedule_run_instance
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp return
> self.drivers['compute'].schedule_run_instance(*args, **kwargs)
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp   File
> "/usr/lib/python2.6/site-packages/nova/scheduler/filter_scheduler.py", line
> 73, in schedule_run_instance
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp
> filter_properties, instance_uuids)
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp   File
> "/usr/lib/python2.6/site-packages/nova/scheduler/filter_scheduler.py", line
> 251, in _schedule
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp
> elevated, topic)
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp   File
> "/usr/lib/python2.6/site-packages/nova/scheduler/host_manager.py", line
> 284, in get_all_host_states
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp
> host_state.update_from_compute_node(compute)
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp   File
> "/usr/lib/python2.6/site-packages/nova/scheduler/host_manager.py", line
> 125, in update_from_compute_node
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp if
> self.updated and self.updated > compute['updated_at']:
> 2013-02-07 19:21:45 1688 TRACE nova.openstack.common.rpc.amqp TypeError:
> can't compare datetime.datetime to NoneType
>
> --
> \*..+.-
> --Greg Chavez
> +//..;};
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>


-- 
Thanks & Regards,
Unmesh G.
___
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] n-api installation problem with devstack (on Ubuntu )

[Unmesh Gurjar]

Swapnil,

>From the n-api logs available on the bug, it looks like the EC2 port
(default 8773) is being used by some other service. You can check this
using 'netstat -pan |grep 8773'.
You can either configure the EC2 port (by specifying 'ec2_listen_port' in
nova.conf) or configure the other service to use a different port.

Hope it helps.

~Unmesh G.

On Wed, Feb 13, 2013 at 4:06 PM, swapnil khanapurkar <
contact2swapni...@gmail.com> wrote:

> Hi All,
>
> I posted below bug on launchpad, but i didn't get any response from
> the team, may be its not that active as openstack mailing list.
>
> I am facing an issue detailed here [
> https://bugs.launchpad.net/devstack/+bug/1122764 ].
>
>
> Thanks
> Swapnil
>
> ___
> Mailing list: https://launchpad.net/~openstack
> Post to : openstack@lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>



-- 
Thanks & Regards,
Unmesh G.
___
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] [Glance] No Kernel_ID returned with glance add command

[Unmesh Gurjar]

Kazim,

In any case, the command should have returned either a successful or failed
response. It might be helpful if you paste the exact output of this command.

To move forward, I would suggest having a look at the Glance API logs,
which would indicate what is going wrong in your case. You might also want
to specify the 'debug' option in the glance add command.

Hope this helps.


-- 
Thanks & Regards,
Unmesh G.

On Thu, Feb 21, 2013 at 5:09 PM, Muhammad Kazim  wrote:

> Hi,
> I am installing OpenStack, i have installed all services including Nova,
> Keystone, Glance. I run this command to add cirros image,
> sudo glance add -A 999888777666 name="cirros-0.3.0-i386" is_public=true
> container_format=aki disk_format=aki < cirros-0.3.0-i386-vmlinuz
> I don't get any error with this command, but it doesn't show any output
> such as Kernel_ID. Also images are not added. Please help regarding this
> issue.
>
> Regards
> Kazim
>
> ___
> 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] VM creation failure

[Unmesh Gurjar]

Javier,

The stack trace you provided indicates that the allocate network call from
Compute (to nova-network) timed out. I would suggest checking the
nova-network logs, that might give some insight.
Also, IMO, the create instance request is being served by Compute means the
RabbitMQ is working. You might want to ensure that nova-network has also
connected to the same AMPQ server (as Compute is).

Regards,
Unmesh G.

On Tue, Feb 26, 2013 at 2:16 PM, Javier Alvarez wrote:

>  Hello JuanFra,
>
> How can I check that? I have rabbitmq-server running on the controller
> node and I have set rabbit_host property in the .conf files. Also, if I
> restart nova-compute service, I get the following message:
>
> 2013-02-26 09:43:52 INFO nova.rpc.common [-] Connected to AMQP server on
> 172.16.8.1:5672
>
> Is there any other test I could do to verify everything is properly
> working?
>
> Thanks,
>
> Javi
>
>
> On 25/02/13 20:09, JuanFra Rodriguez Cardoso wrote:
>
> Hi:
>
>  Have you ensured your messaging queue is working correctly?
>
>  Regards,
> JuanFra
>
>
> 2013/2/25 Javier Alvarez 
>
>> Hello,
>>
>> I'm trying to setup OpenStack Essex on Debian and I'm getting an error
>> when creating new VMs. The problem arises when trying to allocate the
>> network of the VM, but I'm not sure why it's happening, I'm using
>> nova-network, and that's the log output:
>>
>> 2013-02-25 18:20:28 AUDIT nova.compute.manager
>> [req-4d211944-bd5c-4e88-a8df-c4a9167676e2 36a7e60b4d134307b61e06949d33735e
>> 9558f53959a04cc992c3f8b6d91bfb9f] [instance:
>> 8c5b2d4a-c715-4f4d-8d74-a6bdccbe1b60] Starting instance...
>> 2013-02-25 18:20:40 INFO nova.virt.libvirt.connection [-] Compute_service
>> record updated for bscgrid21
>> 2013-02-25 18:20:40 INFO nova.compute.manager [-] Updating host status
>> 2013-02-25 18:21:28 ERROR nova.rpc.common
>> [req-4d211944-bd5c-4e88-a8df-c4a9167676e2 36a7e60b4d134307b61e06949d33735e
>> 9558f53959a04cc992c3f8b6d91bfb9f] Timed out waiting for RPC response: timed
>> out
>> 2013-02-25 18:21:28 TRACE nova.rpc.common Traceback (most recent call
>> last):
>> 2013-02-25 18:21:28 TRACE nova.rpc.common   File
>> "/usr/lib/python2.7/dist-packages/nova/rpc/impl_kombu.py", line 490, in
>> ensure
>> 2013-02-25 18:21:28 TRACE nova.rpc.common return method(*args,
>> **kwargs)
>> 2013-02-25 18:21:28 TRACE nova.rpc.common   File
>> "/usr/lib/python2.7/dist-packages/nova/rpc/impl_kombu.py", line 567, in
>> _consume
>> 2013-02-25 18:21:28 TRACE nova.rpc.common return
>> self.connection.drain_events(timeout=timeout)
>> 2013-02-25 18:21:28 TRACE nova.rpc.common   File
>> "/usr/lib/python2.7/dist-packages/kombu/connection.py", line 167, in
>> drain_events
>> 2013-02-25 18:21:28 TRACE nova.rpc.common return
>> self.transport.drain_events(self.connection, **kwargs)
>> 2013-02-25 18:21:28 TRACE nova.rpc.common   File
>> "/usr/lib/python2.7/dist-packages/kombu/transport/amqplib.py", line 262, in
>> drain_events
>> 2013-02-25 18:21:28 TRACE nova.rpc.common return
>> connection.drain_events(**kwargs)
>> 2013-02-25 18:21:28 TRACE nova.rpc.common   File
>> "/usr/lib/python2.7/dist-packages/kombu/transport/amqplib.py", line 94, in
>> drain_events
>> 2013-02-25 18:21:28 TRACE nova.rpc.common return
>> self.wait_multi(self.channels.values(), timeout=timeout)
>> 2013-02-25 18:21:28 TRACE nova.rpc.common   File
>> "/usr/lib/python2.7/dist-packages/kombu/transport/amqplib.py", line 100, in
>> wait_multi
>> 2013-02-25 18:21:28 TRACE nova.rpc.common chanmap.keys(),
>> allowed_methods, timeout=timeout)
>> 2013-02-25 18:21:28 TRACE nova.rpc.common   File
>> "/usr/lib/python2.7/dist-packages/kombu/transport/amqplib.py", line 159, in
>> _wait_multiple
>> 2013-02-25 18:21:28 TRACE nova.rpc.common channel, method_sig, args,
>> content = read_timeout(timeout)
>> 2013-02-25 18:21:28 TRACE nova.rpc.common   File
>> "/usr/lib/python2.7/dist-packages/kombu/transport/amqplib.py", line 132, in
>> read_timeout
>> 2013-02-25 18:21:28 TRACE nova.rpc.common return
>> self.method_reader.read_method()
>> 2013-02-25 18:21:28 TRACE nova.rpc.common   File
>> "/usr/lib/python2.7/dist-packages/amqplib/client_0_8/method_framing.py",
>> line 221, in read_method
>> 2013-02-25 18:21:28 TRACE nova.rpc.common raise m
>> 2013-02-25 18:21:28 TRACE nova.rpc.common timeout: timed out
>> 2013-02-25 18:21:28 TRACE nova.rpc.common
>> 2013-02-25 18:21:28 ERROR nova.compute.manager
>> [req-4d211944-bd5c-4e88-a8df-c4a9167676e2 36a7e60b4d134307b61e06949d33735e
>> 9558f53959a04cc992c3f8b6d91bfb9f] [instance:
>> 8c5b2d4a-c715-4f4d-8d74-a6bdccbe1b60] Instance failed network setup
>> 2013-02-25 18:21:28 TRACE nova.compute.manager [instance:
>> 8c5b2d4a-c715-4f4d-8d74-a6bdccbe1b60] Traceback (most recent call last):
>> 2013-02-25 18:21:28 TRACE nova.compute.manager [instance:
>> 8c5b2d4a-c715-4f4d-8d74-a6bdccbe1b60]   File
>> "/usr/lib/python2.7/dist-packages/nova/compute/manager.py", line 571, in
>> _allocate_network
>> 2013-02-25 18:21:28 TRACE nova.comput

Re: [Openstack] Cinder + Live migration

[Unmesh Gurjar]

Hi Paras,

AFAIK, this should be possible in grizzly.
Here is the related bug: https://bugs.launchpad.net/nova/+bug/1074054


-- 
Thanks & Regards,
Unmesh G.

On Wed, Apr 17, 2013 at 10:04 PM, Paras pradhan wrote:

> Hi,
>
> If we boot a instance from cinder volume. Is it possible to setup live
> migrations? Hypervisor would be KVM
>
> Thanks
> Paras.
>
>
> ___
> 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] problem in authenticating...

[Unmesh Gurjar]

Kamaill,

I think that is caused because of the wrong HTTP header in the second curl
command. It should be 'X-Auth-Token' instead of 'XX-Auth-Token'.
Give it a try and get back if you have any issue.

-Unmesh.


On Tue, Apr 23, 2013 at 1:17 PM, Study Kamaill  wrote:

> THis is the output ::  ---
>
> root@swift-workshop:~# curl -v -H 'X-Auth-User: admin:admin' -H
> 'X-Auth-Key: admin' http://127.0.0.1/auth/v1.0/
> * About to connect() to 127.0.0.1 port 80 (#0)
> *   Trying 127.0.0.1... connected
> > GET /auth/v1.0/ HTTP/1.1
> > User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1
> zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> > Host: 127.0.0.1
> > Accept: */*
> > X-Auth-User: admin:admin
> > X-Auth-Key: admin
> >
> < HTTP/1.1 200 OK
> < X-Storage-Url: http://127.0.0.1:80/v1/AUTH_admin
> < X-Auth-Token: AUTH_tk2ef67e3e0bce4dfb8191044cfc2101d8
> < X-Storage-Token: AUTH_tk2ef67e3e0bce4dfb8191044cfc2101d8
> < X-Trans-Id: tx44471930f35c4cf68c960e0850adace3
> < Content-Length: 0
> < Date: Tue, 23 Apr 2013 07:05:01 GMT
> <
> * Connection #0 to host 127.0.0.1 left intact
> * Closing connection #0
> root@swift-workshop:~# curl -v -H 'XX-Auth-Token:
> AUTH_tk2ef67e3e0bce4dfb8191044cfc2101d8' http://127.0.0.1:80/v1/AUTH_admin
> * About to connect() to 127.0.0.1 port 80 (#0)
> *   Trying 127.0.0.1... connected
> > GET /v1/AUTH_admin HTTP/1.1
> > User-Agent: curl/7.22.0 (i686-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1
> zlib/1.2.3.4 libidn/1.23 librtmp/2.3
> > Host: 127.0.0.1
> > Accept: */*
> > XX-Auth-Token: AUTH_tk2ef67e3e0bce4dfb8191044cfc2101d8
> >
> < HTTP/1.1 401 Unauthorized
> < Content-Length: 131
> < Content-Type: text/html
> < X-Trans-Id: txc073152b8f78467e93a64677d437ef1b
> < Date: Tue, 23 Apr 2013 07:05:54 GMT
> <
> * Connection #0 to host 127.0.0.1 left intact
> * Closing connection #0
> UnauthorizedThis server could not verify that you are
> authorized to access the document you
> requested.root@swift-workshop:~#
>
> ___
> 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-network: how to remove

[Unmesh Gurjar]

Arindam,

You can do it using 'nova-manage service disable --host 
--service ' command. Similarly, you can enable the network service
in controller node.


-Unmesh.


On Thu, Apr 25, 2013 at 9:16 PM, Arindam Choudhury  wrote:

> Hi,
>
> I mistakenly installed nova-network in a compute node and its became the
> default one. Though I can start the nova-network in the controller, it does
> not start the dnsmasq. How to disable the nova-network from the compute
> node and enable the one in the controller?
>
> ___
> 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] [Cinder] Loading cinder.conf

[Unmesh Gurjar]

Hi,

AFAIK, there are no additional changes required (other than restarting the
service so that it loads the new conf settings). Assuming you have done
that, can you check what is the 'volume_driver' from the service start up
logs?


~Unmesh.

On Mon, Jul 15, 2013 at 10:44 AM, zan tosh  wrote:

> Ray
>
> I am wondering why I see the default driver even after I changed the entry
> in cinder.conf. I un-commented the line for volume_driver and changed the
> driver name. I tried to print volume driver in the __init__ and I see it
> still pointing to LVMISCSIDriver. It seems I am missing something and its
> not loading values from cinder.conf.
>
> ~z
>
>
> On Mon, Jul 15, 2013 at 10:33 AM, Ray Sun  wrote:
>
>> Yes, that's the default driver. See cinder/volume/manager.py
>> volume_manager_opts = [
>> cfg.StrOpt('volume_driver',
>>default='cinder.volume.drivers.lvm.LVMISCSIDriver',
>>help='Driver to use for volume creation'),
>> ]
>>
>> Best Regards
>> -- Ray
>>
>>
>> On Mon, Jul 15, 2013 at 12:51 PM, zan tosh  wrote:
>>
>>> I use devstack (Grizzly/stable). I have been trying to use a different
>>> volume driver by muncommenting and modifying the below line in cinder.conf
>>> under etc/cinder
>>> # Driver to use for volume creation (string value)
>>> #volume_driver=cinder.volume.drivers.lvm.LVMISCSIDriver
>>>
>>> But when VolumeManager is loaded I see it still refers to the default
>>> LVMISCSIDriver. Is there any other change to load cinder.conf?
>>>
>>> Any suggestions?
>>>
>>> Tahnks
>>>
>>> ___
>>> 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
>
>
___
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] Malformed Requests

[Unmesh Gurjar]

Hi Justin,

Looking at the endpoints in the auth response (v2.0/tokens), probably the
URL should be
http://openstack.cloud.fandingo.org:8776/v1/4457698fa26d4ce59f1811e91521f6c4/volumes/detail
instead
of
http://openstack.cloud.kerrygroup.net:8776/v1/4457698fa26d4ce59f1811e91521f6c4/volumes/detail.


Hope it helps!


On Thu, Jul 25, 2013 at 12:15 AM, Justin Brown wrote:

> Hello,
>
> I'm having some trouble getting Nova and Cinder to communicate with
> the API and Horizon in Grizzly.
>
> Any request that I make against those services always returns HTTP
> 400, malformed request url. Requests to Keystone and Glance work fine.
>
> I've only found a couple other people with this issue, and it seemed
> to always be related to typos in their service endpoint URLs. I don't
> think that is my problem.
>
> Here are my endpoints for Cinder and Nova, respectively
> http://openstack.cloud.fandingo.org:8776/v1/$(tenant_id)s
> http://openstack.cloud.fandingo.org:8774/v2/$(tenant_id)s
>
> Now, if I try something simple like `cinder --debug list`, I get the
> following output. Note that the CMS auth-token is quite long, so I
> have omitted it.
>
> REQ: curl -i http://localhost:35357/v2.0/tokens -X POST -H
> "Content-Type: application/json" -H "Accept: application/json" -H
> "User-Agent: python-cinderclient" -d '{"auth": {"tenantName": "admin",
> "passwordCredentials": {"username": "justi
> n", "password": "secret"}}}'
>
> RESP: [200] {'date': 'Wed, 24 Jul 2013 18:10:30 GMT', 'content-type':
> 'application/json', 'content-length': '7281', 'vary': 'X-Auth-Token'}
> RESP BODY: {"access": {"token": {"issued_at":
> "2013-07-24T18:10:30.957542", "expires": "2013-07-25T18:10:30Z", "id":
> "<>", "tenant": {"description": null, "enabled": true,
> "id": "4457698fa26d4ce59f1811e91521f6c4", "name": "admin"}},
> "serviceCatalog": [{"endpoints": [{"adminURL":
> "
> http://openstack.cloud.fandingo.org:8774/v2/4457698fa26d4ce59f1811e91521f6c4
> ",
> "region": "Fandingo", "internalURL":
> "
> http://openstack.cloud.fandingo.org:8774/v2/4457698fa26d4ce59f1811e91521f6c4
> ",
> "id": "0494bbe29b014d6da63e519eafa734da", "publicURL":
> "
> http://openstack.cloud.fandingo.org:8774/v2/4457698fa26d4ce59f1811e91521f6c4
> "}],
> "endpoints_links": [], "type": "compute", "name": "nova"},
> {"endpoints": [{"adminURL":
> "http://openstack.cloud.fandingo.org:9696/";, "region": "Fandingo",
> "internalURL": "http://openstack.cloudfandingo.org:9696/";, "id":
> "ad160008203d4de0b96ed7def7ed1269", "publicURL":
> "http://openstack.cloud.fandingo.org:9696/"}], "endpoints_links": [],
> "type": "network", "name": "quantum"}, {"endpoints": [{"adminURL":
> "http://openstack.cloud.fandingo.org:9292";, "region": "Fandingo",
> "internalURL": "http://openstack.cloud.fandingo.org:9292";, "id":
> "0d8f052422ea42eabcfb53212d5a563a", "publicURL":
> "http://openstack.cloud.fandingo.org:9292"}], "endpoints_links": [],
> "type": "image", "name": "glance"}, {"endpoints": [{"adminURL":
> "
> http://openstack.cloud.fandingo.org:8776/v1/4457698fa26d4ce59f1811e91521f6c4
> ",
> "region": "Fandingo", "internalURL":
> "
> http://openstack.cloud.fandingo.org:8776/v1/4457698fa26d4ce59f1811e91521f6c4
> ",
> "id": "17090aacab934d13b6ce735e78e317c9", "publicURL":
> "
> http://openstack.cloud.fandingo.org:8776/v1/4457698fa26d4ce59f1811e91521f6c4
> "}],
> "endpoints_links": [], "type": "volume", "name": "cinder"},
> {"endpoints": [{"adminURL":
> "http://openstack.cloud.fandingo.org:8773/services/Admin";, "region":
> "Fandingo", "internalURL":
> "http://openstack.cloud.fandingo.org:8773/services/Cloud";, "id":
> "42556805f93d41ef87c9657b9d0cc52a", "publicURL":
> "http://openstack.cloud.fandingo.org:8773/services/Cloud"}],
> "endpoints_links": [], "type": "ec2", "name": "ec2"}, {"endpoints":
> [{"adminURL": "http://openstack.cloud.fandingo.org:35357/v2.0";,
> "region": "Fandingo", "internalURL":
> "http://openstack.cloud.fandingo.org:5000/v2.0";, "id":
> "1af520b8fced4335aaeb5fa13515aaa5", "publicURL":
> "http://openstack.cloud.fandingo.org:5000/v2.0"}], "endpoints_links":
> [], "type": "identity", "name": "keystone"}], "user": {"username":
> "justin", "roles_links": [], "id": "84888243a24940d78cf190bcc5166d75",
> "roles": [{"name": "_member_"}, {"name": "admin"}], "name": "justin"},
> "metadata": {"is_admin": 0, "roles":
> ["9fe2ff9ee4384b1894a90878d3e92bab",
> "3c8337f7a64a4bd8967d971f1debeea8"]}}}
>
> That looks fine. The error happens on the second curl command:
> REQ: curl -i
> http://openstack.cloud.kerrygroup.net:8776/v1/4457698fa26d4ce59f1811e91521f6c4/volumes/detail
> -X GET -H "X-Auth-Project-Id: admin" -H "User-Agent:
> python-cinderclient" -H "Accept: application/json" -H "X-Auth-Token:
> <>"
>
> RESP: [400] {'date': 'Wed, 24 Jul 2013 18:10:31 GMT',
> 'content-length': '65', 'content-type': 'application/json;
> charset=UTF-8', 'x-compute-request-id':
> 'req-54484df2-dfdf-447a-