I agree user shouldn’t have to update DB.
There needs to be some periodic cleanup task that “fixes” the
vm_state/task_state for “stuck” instances.
-Mandar
From: openstack-bounces+mandar.vaze=vertex.co...@lists.launchpad.net
[mailto:openstack-bounces+mandar.vaze=vertex.co...@lists.launchpad.net]
I’m also getting the same error on latest master branch (updated today)
Using setup created by devstack
-Mandar
From: openstack-bounces+mandar.vaze=vertex.co...@lists.launchpad.net
[mailto:openstack-bounces+mandar.vaze=vertex.co...@lists.launchpad.net] On
Behalf Of .?o 0 O??
Sent: Monday, March
= keystone.catalog.backends.templated.TemplatedCatalog
-- 原始邮件 --
发件人: "Andiabes"mailto:andi.a...@gmail.com>>;
发送时间: 2012年3月26日(星期一) 晚上7:25
收件人: "Mandar Vaze"mailto:mandar.v...@vertex.co.in>>;
抄送: " .。o 0 O泡泡 "<501640...@qq.c
I've configured mélange IPAM using devstack (Added mélange and m-svc to
ENBALED_SERVICES in stackrc before I executed stack.sh)
I'm using quantum network manager.
As you can see that 10.0.0.0 and 10.0.0.1 addresses are assigned to VMs created
using dashboard/horizon - so I didn't specify any net
be executed (and in what order) to get a
"working" setup for nova+quantum+mélange
Regards,
-Mandar
From: openstack-bounces+mandar.vaze=vertex.co...@lists.launchpad.net
[mailto:openstack-bounces+mandar.vaze=vertex.co...@lists.launchpad.net] On
Behalf Of Mandar Vaze
Sent: Tuesday, March 2
Troy,
Thanks for your help.
`melange policy create -t {tennant} name={block_name} desc={policy_name}`
(This should return the
policy_id for the next command)
`melange unusable_ip_octet create -t {tennant} policy_id={policy_id} octet=0`
`melange unus
I create my instance using cirros-0.3.0-x86_64-blank image
Default username/password for the instance is listed on the very last line in
“View Log”
-Mandar
From: openstack-bounces+mandar.vaze=vertex.co...@lists.launchpad.net
[mailto:openstack-bounces+mandar.vaze=vertex.co...@lists.launchpad.net
Troy,
I've setup nova+quantum+mélange using devstack.
devstack creates networks using tenant_id ="default" (This in itself looks
incorrect, since it should be valid UUID for one of the tenant from keystone DB
- but I can imagine that stack.sh can't get UUID for demo or admin tenants
easily)
So
I saw an old question posted here :
https://answers.launchpad.net/nova/+question/164689
But I am not trying live migration.
I have nfs mounted instances_path - so when I try to spawn an instance I
run into the above errors. Especially following :
File "/usr/lib/python2.7/dist-packages/libvirt.py
It would be great if someone can spare some time to have a look at these :
https://review.openstack.org/#/c/6451/ : I've addressed comments from
first review cycle - Second patch set needs to be reviewed and
approved
https://review.openstack.org/#/c/6452/ : Brad Hall reviewed - But more
review an
Hi,
I'm working on python program that needs to get images detail from glance.
I was using "get_admin_context" earlier to do all the work in nova side,
but this doesn't seem to work when I query glance.
I get "401 Not Authorized" error.
I think I need to get auth_token from keystone, and use it w
>
> Please help me understand on how modifying nova.conf with the respective
> options can help bringing up tilera like machines up either from command
> line or from GUI.
>
http://wiki.openstack.org/HeterogeneousTileraSupport Seems to have a lot
of information.
> http://wiki.openstack.org/Gene
See if mounting as nfsv3 helps
See https://answers.launchpad.net/nova/+question/164689,
specifically comment #11
-Mandar
On Tue, Jul 3, 2012 at 7:18 PM, Leander Bessa Beernaert wrote:
> Hello all,
>
> I've been trying to get the live migration to work according to the guide
> http://docs.openst
>
> So i've managed to get my instances to launch, thx Mandar!
>
Does that mean you used nfsv3 ? Based on the comments on the URL, several
people (all ??) seems to have problem with nfsv4
*Anne, Is it possible to add this to FAQ (or relevant document(s) )? *(after
Leander confirms that nfs v3 sol
Not sure if you are able to debug this, but a while ago there was a bug
where instance.id was passed where instance.uuid was expected. This used to
cause some problem.
It looks like you are using distribution package rather than devstack
installation, so it is likely that the issue is now fixed. Ca
using nfsv4.
>
> Any ideas?
>
>
> On Fri, Jul 6, 2012 at 7:57 PM, Leander Bessa Beernaert <
> leande...@gmail.com> wrote:
>
>> Thanks for the tip, it's a better than nothing :)
>>
>> Regards,
>> Leander
>>
>> On Fri, Jul 6, 2012 at 6:3
Mon, Jul 9, 2012 at 10:31 PM, Leander Bessa Beernaert <
leande...@gmail.com> wrote:
> There is no error, it just doesn't do anything :s.
>
> I've left the instance alone for 3 hours now and it's still stuck on the
> original compute node.
>
> On Mon, Jul 9, 201
17 matches
Mail list logo