Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-12-07
15:12:26 mriedem shrug. we neutered quite a bit of the n-net specific apis in rocky, there are a couple lingering that i think would be priority to remove first, and maybe the os-cells api
15:12:58 mriedem i also wouldn't want that to distract from the other stuff that's already not getting attention, so close to the 2nd milestone
15:13:15 dansmith that's why I'm saying we don't have to do anything, just remove the test and land a reno
15:13:22 dansmith but that's just MHO
15:13:34 dansmith the test job Imean
15:13:35 mriedem remove the entire nova-cells-v1 job you mean?
15:13:36 mriedem yeah
15:14:04 mriedem it is using neutron at this point, so it doesn't really help cern as a n-net 50% user to keep it around
15:14:11 mriedem since cern is cells v2 now
15:14:15 dansmith yeah
15:14:30 dansmith melwitt is on the worst call evar right now, so maybe just pause until she's done and can opine
15:15:17 melwitt haha :) yeah....
15:17:27 melwitt mriedem: definitely ok with me to disable snapshot tests. and no strong opinion about removing the entire job. I think we'd be ok removing the job considering everyone's moved/moving off of it. I think nectar is the only other one? and mgagne_?
15:18:22 mriedem sorrison said they are on pike i think, and v1 but looking at v2
15:18:29 mriedem mgagne_ i think is still on mitaka
15:18:55 dansmith removing the tests several releases ahead of both of those would help send a message that it's time
15:18:59 dansmith as if cern being on it wasn't enough
15:20:48 dansmith continuing to whittle away at what it tests is also fine, but looking at how stressed the gate is, one fewer devstack runs for each nova patch seems like a decent win to me
15:21:47 melwitt yeah, on one hand I think we could disable the snapshot tests and if all is well after that, then we have some coverage for sorrison and mgagne_ sake. but if the job keeps being a thorn and failing then look again at removing the entire job
15:21:49 mriedem fwiw it's also tempest and devstack that run it
15:22:22 mriedem alternative is, move it to experimental
15:22:24 mriedem so it's run on deman
15:22:26 mriedem *demand
15:22:29 dansmith mriedem: yeah, that would be good
15:22:44 melwitt yeah, that's a nice alternative I didn't think of
15:22:47 mriedem caught me with my pants down https://review.openstack.org/#/q/topic:rm-nova-cells-v1-job+(status:open+OR+status:merged)
15:22:51 dansmith nova, tempest and devstack is a lot of running a heavy job for something we're just going to disable if any tests fail :/
15:22:51 mriedem ok i'll change those
15:42:40 lei-zh Hi jaypipes sean-k-mooney, would you take a look at https://review.openstack.org/#/c/601596/ and https://review.openstack.org/#/c/622893/ when you have spare time
15:44:16 sean-k-mooney lei-zh: yes ill add them to my review queue
15:44:47 lei-zh sean-k-mooney: thanks
15:45:02 lei-zh we have split the original spec into two specs, one general and one specific to libvirt driver implementation, hope this will be helpful for people to understand
15:45:23 sean-k-mooney lei-zh: do you know waht is the state of the code/ci for this is?
15:45:38 sean-k-mooney lei-zh: ok i was wondering why it was split but that makes sense
15:47:20 lei-zh sean-k-mooney: we have worked out some poc code and will continue to improve them
15:48:12 sean-k-mooney cool is as part of the poc is there a way to test this without real persitent memory . i belive qemu can fake it with a file backed correct
15:48:27 sean-k-mooney just wondering how feasibel testing this would be
15:49:48 lei-zh sean-k-mooney: ci is also in the list but we plan to start working on that when the code is more ready
15:51:55 lei-zh sean-k-mooney: currently my colleagues are testing this on real hardware, I'm not sure about qemu simulation, I will ask them about this and sync with you
15:52:44 sean-k-mooney ya no worries. it would be nice to test this upstream at somepoint but its not a blocker
15:53:38 lei-zh yeah, thanks for pointing out that
16:03:30 openstackgerrit Matt Riedemann proposed openstack/nova master: Move nova-cells-v1 to experimental queue https://review.openstack.org/623538
16:04:02 mriedem https://review.openstack.org/#/q/topic:bug/1807407+(status:open+OR+status:merged)
16:07:58 openstackgerrit Merged openstack/nova stable/rocky: Add description of custom resource classes https://review.openstack.org/619122
16:08:05 openstackgerrit Merged openstack/nova stable/rocky: Mention meta key suffix in tenant isolation with placement docs https://review.openstack.org/617535
16:09:25 cdent mriedem++ on cellsv1 job experimental
16:10:31 sean-k-mooney jaypipes: stephenfin hopefully a quick one but can ye look at https://review.openstack.org/#/c/612534/
16:12:06 mriedem cdent: jaypipes: i'm going to need you guys to tell me if we can remove the SchedulerReportClient lock https://review.openstack.org/#/c/623246/2//COMMIT_MSG@11
16:12:13 mriedem since between you guys and efried_cya_jan it was added
16:13:23 cdent looking
16:16:59 jaypipes mriedem: I don't see any reason for it.
16:17:10 jaypipes mriedem: there's no state being fetched on init.
16:17:59 jaypipes mriedem: was more than likely just a copy/pasta from something else.
16:18:20 openstackgerrit Balazs Gibizer proposed openstack/nova master: Ensure that allocated PF matches the used PF https://review.openstack.org/623543
16:18:46 mriedem jaypipes: did you see the change in which it was added?
16:18:57 mriedem https://review.openstack.org/#/c/493536/
16:19:08 mriedem i guess it was added for safety precautions
16:19:17 cdent mriedem, jaypipes: based on the commit message on https://review.openstack.org/493536 it looks gratuitous
16:19:17 mriedem if we're meh on that now, then sure we can remove it
16:19:53 mriedem if i'm going to remove the lock, i might as well also make it a singleton in the api since we don't need 70 of these created when it's used in 3 places
16:20:01 jaypipes mriedem: from the commit message: "I've made the _client method synchronized so that in the unlikely event that the resource tracker is trying to do its update job while some other thing is happening, we won't waste the client. This may not be necessary, but probably doesn't harm anything."
16:20:25 mriedem i know, i read it
16:20:39 cdent given that I never synchronize anything, I'm guess somewhere along the way it was suggested as a "maybe you should..." and I just did, without any real data
16:21:20 jaypipes cdent: either that, or copy/pasta from somewhere in the resource tracker way back when... not sure, either way, I'm pretty sure it's unnecessary.
16:21:48 cdent we'll find out soon enough, I reckon
16:22:58 melwitt bauzas: reminder that review comments on the reshaper patch await your reply https://review.openstack.org/599208
16:23:01 cdent generally speaking, unless we can come up with a really good reason for a lock, we should not
16:23:35 bauzas melwitt: ok, I was thinking those details were pretty nitty, but I'll then provide a new revision
16:24:15 mriedem bauzas: if you thought that, you could have said so weeks ago...
16:24:34 melwitt bauzas: ok. you don't necessarily have to push a new revision but could make a comment in response so we know your thoughts
16:24:35 mriedem or talked with artom
16:32:26 openstackgerrit Matt Riedemann proposed openstack/nova stable/rocky: Ignore MoxStubout deprecation warnings https://review.openstack.org/623545
16:52:42 openstackgerrit Matt Riedemann proposed openstack/nova stable/rocky: Note the aggregate allocation ratio restriction in scheduler docs https://review.openstack.org/623546
16:56:49 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: Note the aggregate allocation ratio restriction in scheduler docs https://review.openstack.org/623547
17:09:02 nicolasbock Hi, I have a server on Newton that after a migration attempt shows `task_state = resize_finish`, `status = RESIZE`. I can't resize confirm or start the server. I don't see any obvious error messages in the nova-compute logs on either the old nor the new hypervisor.
17:09:02 artom mriedem, bauzas, are we seriously OK with the length of those methods? I won't be a pain just for the hell of it, and I understand that sometimes old code grows beyond what we want, but brand new code?
17:09:08 artom I dunno, I just have trouble with that
17:09:24 nicolasbock The resized disks have the same md5sum on either hypervisor
17:09:31 artom If everyone's overruling me there's not much I can do, but I wanted to at least make that point
17:09:46 mriedem artom: i'm not disagreeing with your comments
17:10:00 nicolasbock Basically, I am wondering what the problem could be?
17:10:21 artom mriedem, ok, cool, thanks :)
17:10:45 mriedem nicolasbock: looks like something probably failed during the resize (maybe a db change?) where the task_state was not set to None
17:10:52 mriedem so check the compute and conductor logs for errors
17:11:22 nicolasbock the logs on the destination ?
17:11:29 nicolasbock And thanks mriedem
17:12:07 mriedem yeah finish resize happens on the dest machine
17:13:08 mriedem db errors would be in conductor logs though
17:13:25 nicolasbock The compute only says: `nova-compute.log:2018-12-07 17:08:04.883 26498 INFO nova.compute.manager [-] [instance: 585b884f-29be-4bb1-8f95-8f5e4c02127d] During sync_power_state the instance has a pending task (resize_finish). Skip.`
17:14:11 mriedem this is where that task_state would be set https://github.com/openstack/nova/blob/newton-eol/nova/compute/manager.py#L3913
17:14:20 nicolasbock I am going through the conductor logs now
17:14:21 mriedem and then task_state=None when done https://github.com/openstack/nova/blob/newton-eol/nova/compute/manager.py#L3946
17:14:39 mriedem if something blew up in there, this should reset the task_state to None https://github.com/openstack/nova/blob/newton-eol/nova/compute/manager.py#L3954
17:14:45 mriedem but if you're having db problems, it's a crapshoot
17:15:45 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Note the aggregate allocation ratio restriction in scheduler docs https://review.openstack.org/623552
17:20:29 nicolasbock I don't see any DB errors either. Strange.
17:50:42 aspiers mriedem_lunch: thanks a lot for the quick reply - will get you those confirmations about volume-backed and config drive ASAP
18:10:57 openstack bug 1799727 in OpenStack Compute (nova) rocky "CPU_Allocation_Ratio from nova.conf doesn't update exisiting providers" [High,In progress] https://launchpad.net/bugs/1799727 - Assigned to Matt Riedemann (mriedem)
18:10:57 openstackgerrit Merged openstack/nova stable/rocky: Add functional recreate test for bug 1799727 https://review.openstack.org/614563
18:11:03 openstackgerrit Merged openstack/nova stable/rocky: Provide allocation_ratio/reserved amounts from update_provider_tree() https://review.openstack.org/614564

Earlier   Later