Open Stack

On 05/15/2013 05:38 AM, Michael Still wrote:
> On Tue, May 14, 2013 at 11:26 PM, Russell Bryant <rbryant at redhat.com> wrote:
>> On 05/14/2013 02:52 AM, Michael Still wrote:
>>> Hi.
>>>
>>> Russell -- I was reviewing https://review.openstack.org/#/c/28950/,
>>> and I think I found a new bug. This code assumes that both the source
>>> and destination for a migration have the same value set for
>>> CONF.instances_path.
>>>
>>> So... Do we think that's true? Do we assume that this value is set to
>>> the same value deployment wide? I can see cases where that might be
>>> surprising to deployers.
>>>
>>> I think we need a policy discussion here, so I'm hoping this thread
>>> will help us decide.
>>
>> Is there ever a case where *not* setting it to the same thing is useful?
> 
> I'm not sure. I can think of cases where admins might have different
> sized filesystems depending on how they setup machines, but surely if
> you're managing a cluster of many machines you'd standardise them all
> as much as possible.
> 
>> So, let's start with this:
>>
>>   We assume that the value of the instances_path configuration option
>>   is the same across an entire migration domain, meaning that we expect
>>   it to be the same for the source and destination of any migration.  In
>>   practice this may mean across a host aggregate, a cell, or an entire
>>   deployment, depending on the specifics of the deployment.
>>
>> Now, poke holes in it.  Is it bad?  Why?  What code makes this
>> assumption now that would have to change?
> 
> I think the biggest reason its bad is that its an opportunity for
> confusion -- migrations fail if this isn't true, but its not obvious
> to a deployer that they're failing for this reason. Perhaps we should
> test this assumption in the code as part of the shared storage
> detection?

Interesting I see this discussion here - just now, I changed the instances_path to an NFS
share, added the right SELinux context, made nova: owner of it, restarted all instances,
ensured qpid is up, etc.

Setup: All services on a single host, Grizzly, RDO.

Since then, it's been failing w/ errors like below:
======
[ ~(keystone_admin)]# tail  /var/log/nova/conductor.log
2012-04-18 07:31:56.893 11196 CRITICAL nova [-] need more than 0 values to unpack
2012-04-18 09:41:03.738 41546 CRITICAL nova [-] need more than 0 values to unpack
======

I'm trying to debug this issue w/ Flavio Percoco.

> 
>> In the mean time, it would be good to document this expectation in the
>> config.
> 
> For sure.
> 
> Michael
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 


-- 
/kashyap