[PKG-Openstack-devel] ValueError: Field `instance_uuid' cannot be None

Thomas Goirand zigo at debian.org
Wed Oct 19 12:36:30 UTC 2016


On 10/19/2016 12:20 PM, Turbo Fredriksson wrote:
> Also, in this upgrade, you also need to run a couple of more commands
> to configure and create the 'cell0' DB etc.
> 
> They didn't work correctly either :(

Please let me know what commands. The only thing that I can tell is that
an install from scratch of Newton works. I can't really tell for the
upgrade. Our best bet here is to push fixes in master, then have the
patches backported to stable/newton (and in the mean while, push that as
a debian/patches file). But I need to know what to do. Didn't you save
this in your history or something?

>> I haven't done that
> 
> In a sense you did - you expected the commands you do now to work, even
> for this major upgrade. They might work fine within a Openstack release,
> but in this case, "a bunch" of other commands and stuff needed to be done.
> 
> And that was NOT done in the packages. Which is my point I'm trying (and
> apparently failing) to make.

You are perfectly making your point, and it's well received. Please be
specific about what you've done to fix things, and we'll wired this into
a debian/patches file for the upstream Alembic migratios.

> Fair enough. And I do apologize again for the tone, but this have been
> on my hate list ever since I started with Openstack in around April - bad
> (or complete absence of) documentation. And "The Upgrade Path"!!
> 
> I'm fully aware that this is upstreams "fault", but still that bleeds down
> to you and I don't intend it the way it may look.

No worries. Just keep in mind that I'm always for improvements,
especially for upgrades. As for upstream "fault", best is to fix this
into some grenade tests, so it doesn't happen again. You may also open a
thread within openstack-dev at lists.openstack.org to (nicely) complain
about the current situation, and ask upstream for help.

>> Now, if you don't have the time to write the patch, could you at least
>> provide me with the SQL query that you performed to fix the problem? Is
>> it something like this?
>>
>> DELETE from nova.build_requests WHERE instance_uuid='NULL';
> 
> Pretty much. Because I looked at the table before, and it ONLY contained
> entries like that, I simply ran "delete from build_request" :).
> 
> But your way is safer :D

Ok. That's rather easy to do then.

> 
> But this time a couple of extra commands had to be run. See
> 
>   http://docs.openstack.org/releasenotes/nova/newton.html#upgrade-notes
> 
> Basically, create the cell0 mapping, create the cell0 DB the mapping
> created a reference to (have to do this manually, because 'db sync' don't
> do that - including giving the nova-api user full access to that DB) and
> _then_ run "db sync".

Could you translate this into some easy to understand list of command
that would need to be done in the postinst? It's actually a bit hard for
me to figure it out just by reading you or the release notes.

> Also, it _seems_ like I had to configure the transport_url and identity_url
> as well. At least some of the services don't seem to work with the "old"
> way, but I can't be 100% sure about that (because of the DB problems).

I haven't experienced this.

> My issue on launch pad about this:
> 
>   https://bugs.launchpad.net/nova/+bug/1633734

This is a good thing that you opened this bug.

This should fix the problem:
https://review.openstack.org/388668

Cheers,

Thomas Goirand (zigo)




More information about the Openstack-devel mailing list