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

Thomas Goirand zigo at debian.org
Tue Oct 18 21:44:06 UTC 2016


On 10/18/2016 11:33 AM, Turbo Fredriksson wrote:
> On Oct 18, 2016, at 12:55 AM, Thomas Goirand wrote:
> 
>> Hum... Hardly. I'd prefer if we added a Debian specific Alembic
>> migration script, that'd be easier. Either that, or a script to drop in
>> the doc folder. Patch welcome. [1]
> 
> 
> I'd prefer that any upgrade is automatic.

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

> Every other project I've
> ever used that had major changes [in db or otherwise] (OpenLDAP comes
> to mind - which was really, REALLY scary!) have taken care of this
> automatically.
> 
> Yes, it's _A LOT_ (!!) of work, takes _A LOT_ of time, but it's in
> the "job description"..

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

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

> I'm threading on thin ice here (and I do apologize a little - try to
> read it as a constructive criticism and not a banter), but what did
> you think your job as DD/DM was/is? Just download the new version(s),
> copy the debian dir from the old version, update the version in the
> change log and then run 'debuild'??
> 
> Any fool can do THAT! And that's what they do on RedHat/CentOS et all,
> but I've said it before - we're Debian GNU/Linux, we're better than
> that!

I fully agree with that.

> YOU are responsible for making sure ANY upgrade (from basically any
> version in the past!) goes smoothly and that downtime for the user
> is minimal.

Yes.

> You can not rely on upstream to do this for you, neither can you
> put that job on the user..

I haven't done that, just asked if you had time to help, since you're a
dd and seem knowledgeable. You also experienced the issue, and fixed it.
Now, let's investigate further together, ok?

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';

As much as I can see, the instance_uuid column is added to the
build_requests table in
nova/db/sqlalchemy/api_migrations/migrate_repo/versions/013_build_request_extended_attrs.py.
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.

In Mitaka, only a single file creates the build_requests table (in
006_build_request.py), and there's no such thing as instance_uuid in there.

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

> I might be a little paranoid, but your company that you do the packing
> for, they're making money from Openstack installations and upgrades,
> do they not? So it's in their (if not in yours) best interest to not
> make this easy.

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

Cheers,

Thomas Goirand (zigo)




More information about the Openstack-devel mailing list