Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-12-07
14:49:39 openstackgerrit Merged openstack/nova master: Update compute API.get() stubs for test_disk_config https://review.openstack.org/615345
14:49:49 openstackgerrit Merged openstack/nova master: Update compute API.get() stubs in test_access_ips https://review.openstack.org/615346
14:50:25 openstackgerrit Lee Yarwood proposed openstack/nova stable/rocky: Add secret=true to fixed_key configuration parameter https://review.openstack.org/623507
14:51:00 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: Add secret=true to fixed_key configuration parameter https://review.openstack.org/623509
14:52:28 openstackgerrit Lee Yarwood proposed openstack/nova stable/pike: Add secret=true to fixed_key configuration parameter https://review.openstack.org/623510
15:03:53 openstackgerrit Dan Smith proposed openstack/nova master: Make compute rpcapi version calculation check all cells https://review.openstack.org/623284
15:03:53 openstackgerrit Dan Smith proposed openstack/nova master: Only warn about not having computes nodes once in rpcapi https://review.openstack.org/623282
15:03:54 openstackgerrit Dan Smith proposed openstack/nova master: Make service.get_minimum_version_all_cells() cache the results https://review.openstack.org/623283
15:04:23 dansmith mriedem: melwitt: ^ this should be good now I think. also fixed something in the base patch that was causing a non-deterministic run in the later patches
15:05:24 melwitt cool, thanks
15:07:21 mriedem on an unrelated note, i propose that we disable snapshot tests in the cells v1 job http://logs.openstack.org/47/623247/2/check/nova-cells-v1/18338f0/job-output.txt.gz
15:07:34 mriedem snapshot with cells v1 in tempest is historically racy https://bugs.launchpad.net/nova/+bug/1620761
15:07:35 openstack Launchpad bug 1620761 in OpenStack Compute (nova) "test_create_second_image_when_first_image_is_being_saved intermittently times out in teardown in cells v1 job" [Undecided,Invalid]
15:07:48 mriedem given the deprecated nature of cells v1 and the state of the gate, the less we can fail on the better
15:08:33 dansmith mriedem: fine with me
15:08:47 mriedem alright then
15:09:26 dansmith I also wouldn't be opposed to making a statement in stein that cellsv1 is deprecated fully, we're not going to test it anymore, and we'll be ripping the code out at whatever pace we feel is achievable
15:09:59 dansmith we know that the removal of v1 and n-net aren't trivial, so the actual removal will take time, but I think we could go ahead and drive the stake through the heart
15:10:21 openstackgerrit Surya Seetharaman proposed openstack/nova master: API microversion 2.68: Handles Down Cells https://review.openstack.org/591657
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?

Earlier   Later