Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-04-08
16:33:12 openstackgerrit Balazs Gibizer proposed openstack/nova master: Prepare _heal_allocations_for_instance for nested allocations https://review.openstack.org/637954
16:33:21 stephenfin dansmith, jaypipes: Briefly, do you recall any previous examples of us removing a model/table from 'nova/db/sqlalchemy/models.py'. I assume I need a migration?
16:33:37 stephenfin only example I can see 0951cf3d194edbee213673a525c1291245958264. I assume that's mostly all there is to it?
16:34:32 stephenfin (context is that I want to remove 'nova.db.sqlalchemy.models.Cell' without having the tests b**** at me)
16:35:24 sean-k-mooney stephenfin: quick question
16:35:36 sean-k-mooney http://logs.openstack.org/78/647578/3/check/openstack-tox-docs/38e7bf6/job-output.txt.gz#_2019-04-08_16_20_39_533258 this fails in the gate.
16:35:41 sean-k-mooney i know how to fix it
16:35:58 sean-k-mooney but i get the same error locally but the tox command succeeded
16:36:26 stephenfin sean-k-mooney: The gate doesn't run 'tox -e releasenotes', instead calling 'sphinx-build' directly
16:36:45 sean-k-mooney you mean it does not run tox -e docs
16:36:53 stephenfin Sorry, yeah
16:37:02 sean-k-mooney ok why does the gate not do that
16:37:26 stephenfin So I'd say the 'sphinx-build' call in 'tox.ini' is missing a '-W' flag
16:37:51 sean-k-mooney ah
16:37:54 sean-k-mooney ok
16:38:07 sean-k-mooney any reason i should not fix that in a seperate patch?
16:38:40 stephenfin sean-k-mooney: mordred et al. would have the full context, but I suspect it was to ensure documentation was reproducible. Some projects (including us) use the 'docs' target to do more than simply call 'sphinx-build'
16:38:46 openstackgerrit Lee Yarwood proposed openstack/nova master: libvirt: Avoid using os-brick encryptors when device_path isn't provided https://review.openstack.org/649951
16:38:47 sean-k-mooney its really unititive for the docs tox env to pass but the docs job to fail
16:39:31 openstackgerrit Balazs Gibizer proposed openstack/nova master: Prepare _heal_allocations_for_instance for nested allocations https://review.openstack.org/637954
16:39:31 stephenfin sean-k-mooney: I _think_ there was a patch from Takashi that fixed that but if not, you should add it, yes
16:39:31 openstackgerrit Balazs Gibizer proposed openstack/nova master: Refactor _heal_allocations_for_instance to make place for port healing https://review.openstack.org/637953
16:39:32 openstackgerrit Balazs Gibizer proposed openstack/nova master: nova-manage: heal port allocations https://review.openstack.org/637955
16:39:34 lyarwood stephenfin: so regarding the novaclient backports, I'm not even sure that stable/stein is open at the moment
16:40:12 sean-k-mooney stephenfin: ok ill look for Takashi's patch and if i dont find it ill add one
16:40:22 mordred stephenfin: I didnm't do it
16:40:55 mriedem lyarwood: it's not, final release is wednesday
16:41:03 sean-k-mooney mordred: i was just confused by why the docs job on the nova-spec repo did not use the docs tox env
16:41:38 sean-k-mooney the docs tox env does not treat warnings as errors so i was confused by why it "passed" locally but failed in the gate
16:41:40 stephenfin mriedem, lyarwood: Ah, so any backports to stable/rocky must wait for stable/stein to open first, I guess?
16:41:52 mordred stephenfin: actualy - I believe the gate now runs tox -edocs ... it might be hysterical raisins that nova-specs is using an old job?
16:41:57 lyarwood Yeah I believe so
16:42:03 mordred sean-k-mooney: ^^
16:42:20 mordred stephenfin, sean-k-mooney: the job you want is "openstack-tox-docs"
16:42:37 sean-k-mooney mordred: i can check the gate config and fix it too.
16:42:45 stephenfin mordred++
16:43:11 sean-k-mooney mordred: i just wanted to make sure there wasnt a reason not to do it the normal way before i made any changes
16:43:23 stephenfin Hmm, weird, .zuul.yaml says we're using openstack-specs-jobs which uses openstack-tox-docs
16:43:44 jaypipes sean-k-mooney: you working on a rebase of https://review.openstack.org/#/c/629589/?
16:44:16 stephenfin and what was introduced by AJaeger over six months ago (openstack/openstack-zuul-jobs@76deef484)
16:44:39 sean-k-mooney jaypipes: not presently but i will later or tomorow
16:44:52 jaypipes k
16:45:09 sean-k-mooney jaypipes: oh i see adrianc updated https://review.openstack.org/#/c/620115/
16:45:29 jaypipes sean-k-mooney: yeah, and I'm +2 on it.
16:45:37 jaypipes sean-k-mooney: thus my question to you :)
16:45:40 sean-k-mooney other then rebase ontop did you have anything you wanted me to change in https://review.openstack.org/#/c/629589/
16:46:03 jaypipes sean-k-mooney: other than fixing some typos I noted in a review previously, I don't think so.
16:47:00 sean-k-mooney ok ill let you know when its done. thanks for review it. im currently working on my imagemetada prefilter spec
16:48:06 jaypipes sean-k-mooney: np.
16:54:15 mriedem efried: i have done your bidding https://review.openstack.org/#/c/648800/
16:54:27 efried Thanks mriedem
16:54:58 efried all good points
16:57:36 openstackgerrit Balazs Gibizer proposed openstack/nova master: cache neutron ports in heal allocation https://review.openstack.org/638207
16:58:49 openstackgerrit Sylvain Bauza proposed openstack/nova-specs master: Proposes NUMA affinity for vGPUs https://review.openstack.org/650963
17:04:39 dansmith stephenfin: I dunno about removing a whole model or table, but should be the same as a column
17:05:15 stephenfin dansmith: OK, I'll give it a go. Should we still have placeholder migrations or are they not done anymore?
17:05:15 dansmith stephenfin: i.e. remove the object and db model in this release, then in the next release add a schema migration to drop it
17:05:34 dansmith stephenfin: unrelated to this you mean?
17:05:37 dansmith oh wow, okay
17:05:40 stephenfin yeah
17:05:42 dansmith I thought that was on the PTL release checklist
17:06:28 dansmith I mean, there's no new reason why we shouldn't, other than that we haven't really had to use them ever, but I'm not aware of any discussion or decision about it
17:09:24 openstackgerrit Stephen Finucane proposed openstack/nova master: Add placeholder migrations for Stein backports https://review.openstack.org/650964
17:09:44 stephenfin dansmith, melwitt, efried_lunch: They're there if we need them anyway ^
17:23:43 bauzas stephenfin: others, FWIW, https://wiki.openstack.org/wiki/Nova/ReleaseChecklist
17:24:25 bauzas blame myself as I'm technically the release czar (heh)
17:24:28 stephenfin dansmith: Hmm, the tests are complaining that I'm not allowed to use 'drop' in migration. Is removing the 'cells' table (cells v1) a valid exception?
17:24:52 dansmith stephenfin: yep, specifically to catch this case, so you have to add an exception
17:24:59 stephenfin dansmith: If I don't do that, I see 'AssertionError: Models and migration scripts aren't in sync:'
17:25:38 dansmith stephenfin: oh right, so I think you have to leave the model too if there's not an exception path for that
17:25:51 dansmith (we've only done this a couple times since some of those modernized tests)
17:25:57 stephenfin dansmith: there is not, no
17:26:07 stephenfin so just leave the model with a TODO to remove in a future release?
17:26:30 dansmith yeah, so leave that but you could neuter it in some way, but definitely remove all the *use* of it yeah
17:26:40 stephenfin (y) less work for me
17:26:46 dansmith stephenfin: you could probably rename the model, right? Call it "class CellsThingDONOTUSE(..)"
17:27:34 stephenfin Um, I guess I could, yeah :D
17:42:35 openstackgerrit sean mooney proposed openstack/nova-specs master: add spec for image metadata prefiltering https://review.openstack.org/647578
17:44:06 sean-k-mooney stephenfin: the nova-specs docs issue was because i had not rebased against mater where warnings are treated as errors
17:44:19 sean-k-mooney stephenfin: so the tox env and jobs is fine upstream
18:13:03 openstackgerrit Merged openstack/nova master: trivial: Remove dead code https://review.openstack.org/649562
18:13:10 openstackgerrit Merged openstack/nova master: hacking: Fix dodgy check https://review.openstack.org/649563
18:13:19 openstackgerrit Merged openstack/nova master: zvm: Remove dead code https://review.openstack.org/649564
18:13:27 openstackgerrit Merged openstack/nova master: trivial: Remove dead 'ALIAS' constant https://review.openstack.org/649565
18:13:38 openstackgerrit Merged openstack/nova master: trivial: Remove unused constants, functions https://review.openstack.org/649567
18:13:47 openstackgerrit Merged openstack/nova master: trivial: Remove dead resource tracker code https://review.openstack.org/649569
18:36:10 mriedem dansmith: a quick hot take if you will on the path to dropping this online data migration added in ocata: https://github.com/openstack/nova/blob/master/nova/objects/build_request.py#L484 - options: (1) drop it and just assume people are ok (2) add a nova-status upgrade check and drop it or (3) add an api migrations script which just does the query and delete (not a blocker migration, just query for those records and delete th
18:36:31 mriedem i'm partial to #3 which if #1 is true, should be a no-op
18:39:27 dansmith surely we can delete with extreme prejudice
18:39:47 dansmith the case would be what? something created in mitaka that didn't boot that people still want to be able to see in nova-list?
18:43:00 dansmith mriedem: ^
18:43:49 mriedem yeah i guess, but we're already deleting with prejudice in the online data migration
18:44:23 mriedem because you literally can't load the thing otherwise
18:44:26 mriedem so nova-list won't work anyway
18:44:28 dansmith mriedem: I mean delete all of the code
18:44:50 mriedem so #1
18:45:01 dansmith if we really need a delete in a schema migration, then I guess, but I'd rather not create the confusion about why it was okay in this case, personally
18:46:07 mriedem i think the only thing that scares me is people doing skip upgrades from let's say mitaka in this case to train, but we've said time and again we don't support that and you have to roll through,
18:46:20 mriedem so if you do that and hit this, your action would be to just drop those records from your api db manually
18:47:29 dansmith yeah, that's a really long skip

Earlier   Later