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

[Turbo Fredriksson]

On Oct 18, 2016, at 10:44 PM, Thomas Goirand wrote:

> That is what an alembic migration script will do, it's just IMO the best
> way to implement it (that's what upstream uses).

Ok, fair enough. I don't have any opinion what so ever on HOW it's done,
just that it's done! :)

> Sure, I agree, I just don't agree with the way you propose to fix it. :)

If you rather argue with upstream to fix this properly, the better.
But from my point of view (which I've done on several occasions) is
just overwrite the upstream provided config file and substitute with
my own..

Granted, I don't think I've ever been in the position where the configuration
is created at build time from the source, but still..

> Using something in the postinst means we would address only the case
> where people are using dbconfig-common. Adding an Alembic migration
> script / patch will address *EVERY* case. IE: It will run when you do a
> db-sync (which is what the postinst does if you configured with
> dbconfig-common).

Well, it wasn't done in this case. Granted, there was a bug in Mitaka
that prevented this from happening correctly, but still.

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 :(

> 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.

> Now, let's investigate further together, ok?

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.

> 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

> In there, it's directly set with a unique constraint. So I'm not so sure
> how you got it with multiple times the same value.

No idea either!

> So, how did you end up in such a state? Did you run some of the Newton
> beta releases migration script?

No. Not that I know of any way. I've been VERY, VERY (!!) weary about
upgrading, because every time I've done so, things mysteriously just
break :(.

And that's within the same Openstack release!


I don't know if any of the commands I ran before all this "did something".
I only discovered this _after_ trying to upgrade stuff (and failing) at
which time I had to start digging.. So I don't know what the table looked
like _before_ all this..



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".

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 say "seem" because I'm not sure what I'm doing here! I'm basically trying
things out. Not in complete randomness, but close :D

Which is why I don't think I can/should provide actual code. I rather just
file a bug report and then discuss the correct way to solve this..



My issue on launch pad about this:

  https://bugs.launchpad.net/nova/+bug/1633734


But this is just for Nova. I'm still having problem with a couple of the
other services (Cinder and . On _one_ of my controllers at least. I'm still digging into
that..

> Rest assured that there's no conflict of interest here.


Ok :). Just sain' :D
--
Life sucks and then you die