Open Stack

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?

> In the mean time, it would be good to document this expectation in the
> config.

For sure.

Michael