Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-29
21:09:35 mriedem PciDevice objects are used to model a tree, right? where you can have a PciDevice.dev_type = 'type-PF' with children PciDevices that are type-VF, yeah?
21:10:11 mriedem and the allocation of each device is in the 'status' field, so allocated/claimed/available etc
21:11:25 mriedem jaypipes: right? ^
21:12:43 dansmith mriedem: correct as I understand it
21:12:52 dansmith there should be a parent_id relating vf to pf
21:14:09 mriedem yup ok
21:39:26 openstackgerrit Eric Fried proposed openstack/nova master: Use a static resource tracker in compute manager https://review.openstack.org/620711
21:40:37 efried jaypipes: I think this is ready now ^ Lots of test changes. However, I think there's going to be a manual rebase needed when I restack the series.
21:41:32 efried heh, yup
21:45:55 openstackgerrit Eric Fried proposed openstack/nova master: Reduce calls to placement from _ensure https://review.openstack.org/615677
21:45:55 openstackgerrit Eric Fried proposed openstack/nova master: SIGHUP n-cpu to clear provider tree cache https://review.openstack.org/615646
21:45:56 openstackgerrit Eric Fried proposed openstack/nova master: Commonize _update code path https://review.openstack.org/615705
21:45:56 openstackgerrit Eric Fried proposed openstack/nova master: Consolidate inventory refresh https://review.openstack.org/615695
21:45:57 openstackgerrit Eric Fried proposed openstack/nova master: Rip out the SchedulerClient https://review.openstack.org/617049
21:45:57 openstackgerrit Eric Fried proposed openstack/nova master: Rip the report client out of SchedulerClient https://review.openstack.org/617042
21:45:58 openstackgerrit Eric Fried proposed openstack/nova master: Use a static resource tracker in compute manager https://review.openstack.org/620711
21:46:00 efried rebase only ^
22:28:00 mriedem tis your white whale matey
22:29:53 mriedem tonight, during TNF?!
22:30:05 mriedem there will be brees slips all over it
22:32:32 mriedem heh wrong channel
22:56:05 openstackgerrit Eric Fried proposed openstack/nova master: Consolidate inventory refresh https://review.openstack.org/615695
22:56:05 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Reduce calls to placement from _ensure https://review.openstack.org/615677
22:56:06 openstackgerrit Eric Fried proposed openstack/nova master: Rip the report client out of SchedulerClient https://review.openstack.org/617042
22:56:06 openstackgerrit Eric Fried proposed openstack/nova master: Commonize _update code path https://review.openstack.org/615705
22:56:07 openstackgerrit Eric Fried proposed openstack/nova master: Use a static resource tracker in compute manager https://review.openstack.org/620711
22:56:07 openstackgerrit Eric Fried proposed openstack/nova master: Rip out the SchedulerClient https://review.openstack.org/617049
22:57:41 efried jaypipes: Ran out of time tonight, still need to fix up the tests for the now-WIP above. That will cause failures up the chain, and I'm guessing there will be manual rebases needed there once I do fix the tests. But other than that, everything in the series should be ready.
23:12:48 pacharya_ Hi need some help with nova instance info cache table. Due to some network connectivity issues nova received empty list during the heal instance info cache periodic task and instance cache table got updated with same.
23:13:09 pacharya_ now the list and get API for that instance does not have any IPs listed
23:13:17 pacharya_ Does anyone know how to fix this?
23:43:55 jaypipes efried: cool, will get to it again tomorrow morning.
#openstack-nova - 2018-11-30
00:38:10 openstackgerrit Surya Seetharaman proposed openstack/nova master: WIP: API microversion bump for handling-down-cell https://review.openstack.org/591657
02:38:52 openstackgerrit Alex Xu proposed openstack/nova master: Parse the numa topology from the new flavor when resize instance https://review.openstack.org/620874
02:57:41 openstackgerrit Matt Riedemann proposed openstack/nova master: WIP: Drop pre-cinder 3.44 version compatibility https://review.openstack.org/621061
03:15:44 openstackgerrit Brin Zhang proposed openstack/nova-specs master: Support for changing deleted_on_termination after boot https://review.openstack.org/580336
03:25:20 openstackgerrit Merged openstack/nova master: Add I/O Semaphore to limit concurrent disk ops https://review.openstack.org/609180
03:25:31 openstackgerrit Merged openstack/nova stable/pike: Fix NoneType error in _notify_volume_usage_detach https://review.openstack.org/614872
03:25:46 openstackgerrit Merged openstack/nova stable/queens: Default embedded instance.flavor.is_public attribute https://review.openstack.org/619351
03:39:51 openstackgerrit Brin Zhang proposed openstack/nova-specs master: Support for changing deleted_on_termination after boot https://review.openstack.org/580336
05:30:07 openstackgerrit Alex Xu proposed openstack/nova master: Parse the numa topology from the new flavor when resize instance https://review.openstack.org/620874
06:53:10 openstackgerrit Alex Xu proposed openstack/nova master: Parse the new PCI request from flavor extra specs when resize https://review.openstack.org/621077
06:53:10 openstackgerrit Alex Xu proposed openstack/nova master: Parse the numa topology from the new flavor when resize instance https://review.openstack.org/620874
07:11:19 openstackgerrit Filippo Inzaghi proposed openstack/python-novaclient master: Add Python 3.6 classifier to setup.cfg https://review.openstack.org/621093
07:25:09 openstack Launchpad bug 1795920 in OpenStack Compute (nova) "SR-IOV shared PCI numa not working " [Undecided,Confirmed]
07:25:09 ohorecny2 Everyone: Do you know some closer information about this bug: https://bugs.launchpad.net/nova/+bug/1795920 , please? I mean, if anybody is working on it or if you have some proposals how to fix it.
07:53:59 openstack Launchpad bug 1805984 in OpenStack Compute (nova) "Placement is not aware of disable compute nodes" [Undecided,New]
07:53:59 belmoreira mriedem: thanks for ping me. See: https://bugs.launchpad.net/nova/+bug/1805984 https://bugs.launchpad.net/nova/+bug/1805989
07:54:00 openstack Launchpad bug 1805989 in OpenStack Compute (nova) "Weight policy to stack/spread instances and "max_placement_results"" [Undecided,New]
08:21:50 openstackgerrit Yikun Jiang proposed openstack/nova master: Use new ``initial_xxx_allocation_ratio`` CONF https://review.openstack.org/602804
09:23:37 kashyap alex_xu: If you're still about: https://review.openstack.org/#/c/620327/
10:09:15 openstackgerrit Yikun Jiang proposed openstack/nova master: Add compute_node ratio online data migration script https://review.openstack.org/609995
10:09:15 openstackgerrit Yikun Jiang proposed openstack/nova master: Add ratio online data migration when load compute node https://review.openstack.org/613499
10:09:15 openstackgerrit Yikun Jiang proposed openstack/nova master: Use new ``initial_xxx_allocation_ratio`` CONF https://review.openstack.org/602804
10:09:43 openstackgerrit Merged openstack/nova-specs master: Re-propose numa-aware-live-migration spec https://review.openstack.org/599587
10:24:57 gibi jackding: hi! the last open patch for the io semaphor work has merged https://review.openstack.org/#/c/609180/ Does it mean that the bp io-semaphore-for-concurrent-disk-ops is done?
12:37:25 openstackgerrit Elod Illes proposed openstack/nova master: Transform scheduler.select_destinations notification https://review.openstack.org/508506
12:40:56 artom bauzas, thanks for the +W on the NUMA migration spec :) What wasn't clear about the table? Matt had come up with some improved wording, so I can reword in a amendment patch
12:41:38 sean-k-mooney artom you could have just said the new code would only work if both the source and dest node supported it
12:42:41 sean-k-mooney for the other 3 cases the old workflow will be used so you dont really need the table but i could follow it in its redered from much easier then in the raw rst doc
12:43:18 sean-k-mooney i only read the raw rst doc normally so its a little annoying to have to read the rendered version
12:45:41 sean-k-mooney leakypipes: im going to send an email to the list regrading the serialisation of os-vif objects
12:46:29 sean-k-mooney leakypipes: so that kuryr-kubernetes are aware that this will break in the future https://github.com/openstack/kuryr-kubernetes/commit/7cc187806b42fee5ea660f86d33ad2f59b009754
12:47:31 sean-k-mooney leakypipes: and that everything they are doing in this file is using os-vif out of contract https://github.com/openstack/kuryr-kubernetes/blob/master/kuryr_kubernetes/objects/vif.py
12:48:24 sean-k-mooney i have told them we do not allow external plugins to define there own vif object 3 releases ago but we definetly do support serialising and prestingign between potically differed versions of os-vif
12:49:07 artom sean-k-mooney, yeah, the rst doc is unreadable for the table
12:50:48 sean-k-mooney artom: anyway the spec is merged and it was more of a nit i think then anything else so i would not worry about it
12:51:23 leakypipes sean-k-mooney: ack, thanks for getting that conversation started. if you need a spellcheck before sending out, lemme know :P
12:51:47 sean-k-mooney people keep telling me that specs are appreently not documentation so as long as we understand what you ment its all good
12:52:39 leakypipes sean-k-mooney: I actually don't understand why kuryr-kubernetes is defining os-vif objects at all (versus just defining the things in os-vif itself)
12:53:17 sean-k-mooney leakypipes: they did not know that they were not ment too so they did it really early on
12:53:47 leakypipes sean-k-mooney: ok
12:53:55 leakypipes sean-k-mooney: can we undo that? :)
12:53:59 sean-k-mooney more recently the have added it to os-vif when i pointed out that it would break going forward if tehy didnt
12:54:11 sean-k-mooney get rid of there objects yes
12:54:39 sean-k-mooney i ment to do it in rocky but move from intel to redhat and didnt get around to it
12:55:26 jangutter sean-k-mooney, leakypipes: Re: ( https://review.openstack.org/#/c/607610/ ), I left the option open to do the "duelling options" right till the runway engages... mainly to keep progress unblocked, with the idea to update the spec with the decision made.
12:56:23 sean-k-mooney jangutter: i personally hate updateing spec retroactivly. so im happy to conceed just to avoid that
12:56:41 sean-k-mooney well almost
12:57:47 jangutter sean-k-mooney, leakypipes: I have been selling tickets, but I'm pretty sure I can track down the people and refund them with only a limited loss of kneecaps.
12:58:30 sean-k-mooney jangutter: if you want to continue the discussion over code review then we can
12:59:41 sean-k-mooney i would like to see if we can merge the spec soon however and move on to th code as we only have until midle of febuary to release os-vif and i would prefer to have this mered earlier then later.
12:59:46 sean-k-mooney e.g. the code
12:59:58 jangutter sean-k-mooney, leakypipes: on that note, do you think the spec is in a good enough shape for a wider review?
13:00:21 jangutter sean-k-mooney: agreed on that, want to fixup the code early next week to match the spec in any case.
13:01:58 sean-k-mooney jangutter: i would like to see if we can get an os-vif release in the next 2 weeks and alost another one at the end of january to give some time to test it with nova, so sound good.
13:02:20 sean-k-mooney jangutter: i think the spec i fine for wider review
13:05:22 leakypipes jangutter: I do, which is what I said in the review last night :)
13:09:20 jangutter leakypipes, sean-k-mooney: thanks! Any idea who would be sufficiently interested and ... I want to say "still haven't lost hope in all that is good"?
13:15:45 leakypipes jangutter: give it a few hours. you'll have lost all faith in humanity by that point.
13:17:31 jangutter leakypipes: you're describing what I call "Monday".
13:17:52 leakypipes happy Friday.
13:17:58 sean-k-mooney jangutter: well i woudl recommend starting with the nova specs core team since they are the only people that can give you the remaining +2 and +w
13:20:59 sean-k-mooney jangutter: dansmith might have some input on ovo versionng and the inheritance/compostion element of the rest https://review.openstack.org/#/admin/groups/302,members it does not jump out at me as an area the rest are stongly invovled in
13:21:00 jangutter sean-k-mooney: (facepalm, didn't notice that nova-specs and nova have different ACLs)
13:21:21 sean-k-mooney ya nova specs is much smaller
13:48:05 openstack Launchpad bug 1404867 in OpenStack Compute (nova) queens "Volume remains in-use status, if instance booted from volume is deleted in error state" [Medium,Fix committed] - Assigned to Mohammed Naser (mnaser)
13:48:05 s10 Hello. We've faced a bug, that is claimed to be fixed by in https://bugs.launchpad.net/nova/+bug/1404867 . I added a comment about conditions, in which it can happen during the bulk instances creation by Heat.
13:48:11 s10 When instances are created in parallel, they can fail to build because of the quota.recheck_quota=True in nova.conf, and then it's impossible to remove volumes without admin intervention, because volumes are stuck in 'attaching' state.
13:48:12 s10 What will be the right approach to fix this bug?

Earlier   Later