| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-24 | |||
| 16:02:58 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Add missing parameter https://review.opendev.org/682886 | |
| 16:02:58 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Use compression by default for 'SshDriver' https://review.opendev.org/684393 | |
| 16:03:56 | stephenfin | mriedem: Seeing as we're on a docs roll, could you take a look at https://review.opendev.org/#/c/671298/, please? Maybe efried or gibi too | |
| 16:05:37 | gibi | stephenfin: done | |
| 16:05:47 | mriedem | hmm | |
| 16:07:21 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Document global options for nova-manage https://review.opendev.org/677443 | |
| 16:07:21 | openstackgerrit | Stephen Finucane proposed openstack/nova master: config: Explicitly register 'remote_debug' CLI opts https://review.opendev.org/677444 | |
| 16:07:21 | openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP: docs: Rewrite nova-manage docs to use proper directives https://review.opendev.org/677509 | |
| 16:12:15 | shilpasd | mriedem: hi, to verify performance for changes https://review.opendev.org/#/c/612626/ Ignore root_gb for BFV in simple tenant usage API, i have written test program http://paste.openstack.org/show/779196/, please go through once and share any suggestions/corrections if any | |
| 16:12:52 | mriedem | shilpasd: you should paste that into the patch and/or the bug report | |
| 16:13:04 | shilpasd | ok, will do that | |
| 16:13:32 | shilpasd | mriedem: thanks, will paste along with test results | |
| 16:15:05 | dansmith | stephenfin: comment on that db sync one | |
| 16:15:32 | dansmith | stephenfin: If you just did what you said in the commit message, I'd be good, but I feel like you're regressing the verbiage in there | |
| 16:15:50 | dansmith | maybe mriedem has an opinion | |
| 16:16:00 | dansmith | I mean, I bet he does, but maybe he'll tell us what it is | |
| 16:17:17 | stephenfin | makes sense. I can respin | |
| 16:17:18 | mriedem | dansmith: i just said the same thing :) | |
| 16:17:29 | mriedem | and said "maybe dan has an opinion on this" | |
| 16:17:37 | dansmith | heh nice | |
| 16:18:48 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Note use of 'nova-manage db sync --config-file' https://review.opendev.org/671298 | |
| 16:18:49 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Correct 'nova-manage db sync' documentation https://review.opendev.org/677508 | |
| 16:18:49 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Document global options for nova-manage https://review.opendev.org/677443 | |
| 16:18:50 | openstackgerrit | Stephen Finucane proposed openstack/nova master: config: Explicitly register 'remote_debug' CLI opts https://review.opendev.org/677444 | |
| 16:18:50 | openstackgerrit | Stephen Finucane proposed openstack/nova master: WIP: docs: Rewrite nova-manage docs to use proper directives https://review.opendev.org/677509 | |
| 16:22:24 | stephenfin | dansmith, mriedem: okay, took what dansmith said and made it a thing ^ | |
| 16:22:47 | dansmith | looks okay to me, but mriedem was more specific about details, so I'll let him ack it first | |
| 16:27:24 | mriedem | you and gibi can approve | |
| 16:50:29 | ozzzo | after rebuilding controllers in my dev cluster, is is possible to re-register the existing HV, or do I need to rebuild them? | |
| 16:51:12 | openstackgerrit | Merged openstack/nova master: objects: use all_things_equal from objects.base https://review.opendev.org/681397 | |
| 16:51:18 | openstackgerrit | Merged openstack/nova master: Func test for migrate reschedule with pinned compute rpc https://review.opendev.org/683385 | |
| 16:51:25 | openstackgerrit | Merged openstack/nova master: Add evacuate vs rebuild contributor doc https://review.opendev.org/683245 | |
| 16:51:59 | artom | mriedem, so, I think I figured out the NUMA LM thing | |
| 16:52:56 | artom | We filter out 'accepted' migrations in https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L4422 | |
| 16:53:08 | artom | (That's called from the update resources periodic task | |
| 16:53:10 | artom | ) | |
| 16:54:10 | artom | But we only set the 'preparing' status here: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L7020 | |
| 16:54:23 | artom | (It's created with 'accepted' by the conductor) | |
| 16:54:23 | mriedem | and we set accepted in the live migration task | |
| 16:54:44 | artom | So there's a window between doing the claim and setting the status when the resource tracker periodic can kick in and miss the migration | |
| 16:55:07 | artom | And free the incoming instance's resources because it's still on the source according to the DB | |
| 16:55:10 | mriedem | compared to the cold migrate / resize of https://www.health.harvard.edu/blog/common-anticholinergic-drugs-like-benadryl-linked-increased-dementia-risk-201501287667 | |
| 16:55:12 | mriedem | oops | |
| 16:55:12 | mriedem | ha | |
| 16:55:18 | artom | Dementia indeed | |
| 16:55:22 | mriedem | 'pre-migrating' | |
| 16:55:40 | artom | I guess now we know why pre-migrating exists :) | |
| 16:55:58 | mriedem | https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L4408-L4412 | |
| 16:56:18 | artom | Yep, saw that | |
| 16:56:19 | sean-k-mooney | pre-migration is the default status no? | |
| 16:56:26 | sean-k-mooney | at least for cold migraitons | |
| 16:56:37 | artom | sean-k-mooney, it's one giant mess | |
| 16:56:37 | mriedem | artom: ok so i guess just remove 'accepted' from that db api query and see if ya.wang can reproduce with his test script right? | |
| 16:57:02 | artom | mriedem, as an initial smoke test, yeah, but I'm not sure that's the correct permanent solution | |
| 16:57:39 | mriedem | why? if you haven't realized yet, the migration status stuff and the rt is all very tightly coupled | |
| 16:57:55 | artom | Well... | |
| 16:57:56 | sean-k-mooney | mriedem: i like that comment :) not the reason why its needed but i like the phrasing | |
| 16:58:04 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Rework the PCI passthrough guides https://review.opendev.org/635243 | |
| 16:58:04 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Remove 'adv-config', 'system-admin' subdocs https://review.opendev.org/684402 | |
| 16:58:05 | artom | The migration status is technically part of our API, no? | |
| 16:58:26 | artom | And... even it isn't - as you said, it's all tightly coupled, I'd be afraid to break something else | |
| 16:58:55 | artom | Ideally we would implement your TODO | |
| 16:59:08 | artom | Though I suppose one doens't hurt the other | |
| 16:59:11 | sean-k-mooney | if we removed accepted we would need to add it to migration_get_in_progress_by_instance right | |
| 16:59:16 | mriedem | artom: "accepted" is only set while a live migration is in-progress | |
| 16:59:22 | mriedem | and that api is for getting in-progress migrations | |
| 16:59:34 | mriedem | the only reason it didn't matter before was because the RT filtered out anything that wasn't evacuate/resize/cold migrate | |
| 16:59:59 | artom | mriedem, that's a good point | |
| 17:00:15 | mriedem | artom: specifically this v | |
| 17:00:16 | mriedem | https://review.opendev.org/#/c/634606/86/nova/compute/resource_tracker.py | |
| 17:00:21 | mriedem | _is_trackable_migration | |
| 17:00:41 | mriedem | so accepted is definitely an in-progress live migration and something we track now | |
| 17:00:42 | artom | Yeah, I remember that | |
| 17:00:50 | artom | Yep, fair enough | |
| 17:01:02 | artom | If we removed that method entirely we don't need to filter out accepted anymore | |
| 17:01:14 | sean-k-mooney | should we be adding accepted here too https://github.com/openstack/nova/blob/master/nova/db/sqlalchemy/api.py#L4438 | |
| 17:01:48 | sean-k-mooney | it would be kind of nice if we had 1 list | |
| 17:01:56 | sean-k-mooney | that was shared between those two | |
| 17:02:38 | mriedem | sean-k-mooney: idk, pre-migrating isn't in that list either | |
| 17:03:06 | sean-k-mooney | its not clear that pre-migration means its in progress | |
| 17:03:30 | ozzzo | is this not the correct channel to ask for help with Nova? | |
| 17:03:33 | artom | sean-k-mooney, so, I tracked it up the rabbit hole, that one's only used in the server migrations API | |
| 17:03:35 | sean-k-mooney | you can end up in pre-migration if you do an evac to the same host | |
| 17:03:41 | mriedem | a lot of that crap was added for the /servers/{server_id}/migration apis added awhile back so you could list in-progress live migrations specifically and cancel/force-complete them | |
| 17:03:53 | mriedem | so i wouldn't be surprised if a lot of this is biased to live migratoin only | |
| 17:04:03 | mriedem | artom: yup ^ | |
| 17:04:43 | artom | ozzzo, if you're looking for help running/deploying Nova, #openstack in the place | |
| 17:04:53 | artom | ozzzo, this channel is for development (see /topic) | |
| 17:05:00 | ozzzo | no, nobody ever answers a question in #openstack | |
| 17:05:05 | ozzzo | I tried that a few weeks ago | |
| 17:05:30 | ozzzo | I've been idling in there and I see noobs come in asking questions every day, and nobody ever answers | |
| 17:05:46 | sean-k-mooney | ozzzo: if we are not too busy we sometime help if its not a specifc deployment issue | |
| 17:05:51 | ozzzo | they don't even recommend another channel, just silence | |
| 17:05:52 | sean-k-mooney | ozzzo: what is the question? | |
| 17:06:02 | mriedem | ozzzo: sounds like an opportunity for you to be the change in that channel :) | |
| 17:06:05 | ozzzo | after rebuilding controllers in my dev cluster, is is possible to re-register the existing HV, or do I need to rebuild them? | |
| 17:06:33 | dansmith | ozzzo: see topic | |
| 17:07:07 | sean-k-mooney | if you start and stop the compute agents it shoudl recreate the compute service recorred but it wont rebuild any instance info | |
| 17:07:36 | sean-k-mooney | for a dev environment its normally simpler to redeploy as its only a hand full of nodes | |
| 17:08:07 | sean-k-mooney | ozzzo: if you are using devstack you can often just do a git pull and restart the service instead of unstacking and stacking again | |