Earlier  
Posted Nick Remark
#openstack-nova - 2018-11-29
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?
14:06:11 s10 I can reproduce this bug even without Heat, with small terraform config...
14:08:46 mnaser s10: what release?
14:09:51 s10 mnaser: I tried it with the Pike. I can try it with the Queens, if those fixes weren't backported to Pike.
14:10:56 maciejjozefczyk sean-k-mooney: Hey, I finally took time to check https://review.openstack.org/#/c/591607
14:12:00 maciejjozefczyk sean-k-mooney: If you have a minute please look also at: https://review.openstack.org/#/c/614167
14:12:06 maciejjozefczyk Its related
14:12:43 sean-k-mooney maciejjozefczyk: hi
14:12:56 sean-k-mooney yes i saw the follow up patch
14:13:26 sean-k-mooney i only tested the first one because it was a single node deployment and i did not have to worry about updgrades
14:14:32 maciejjozefczyk Ok
14:14:55 sean-k-mooney so just looking at https://review.openstack.org/#/c/591607/9/nova/network/neutronv2/api.py@2914
14:15:29 sean-k-mooney the value of the port id will be a neutron port uuid not an int right
14:16:18 sean-k-mooney or is it a nova port id form the nova virtural interface table
14:17:17 maciejjozefczyk this 'id' is a sequence from table
14:17:37 maciejjozefczyk so it will always be int
14:18:00 sean-k-mooney ok what i was concerned about really was trying to maintian the order of interface withing the guest if possible
14:18:42 sean-k-mooney but to be honest i dont think there is a good way to do that so the code as written is proably fine
14:18:43 maciejjozefczyk https://github.com/openstack/nova/blob/master/nova/objects/virtual_interface.py#L36
14:19:23 openstackgerrit Balazs Gibizer proposed openstack/nova master: Deprecate the unversioned notifications https://review.openstack.org/603079
14:19:26 sean-k-mooney ya i assume it was this object
14:19:36 maciejjozefczyk For me its not a ideal solution also, but its only one source of real order of interfaces, that I know in nova
14:20:09 maciejjozefczyk It was like first idea how to make it after Vlad comment
14:20:52 s10 mnaser: Same thing with Queens. In Pike volumes are stuck in attaching state, in Queens - in reserved.
14:21:08 mnaser s10: indeed sounds like a bug
14:21:16 sean-k-mooney maciejjozefczyk: ya if you are sorting by that id and not the uuid i think the code makes sense
14:21:27 mnaser unfortunately i dont run this setting on and i'm a bit out of cycles to dig in deeper :X
14:21:36 sean-k-mooney i can leve that feedback on the reivew
14:22:11 s10 mnaser: and easy to reproduce. Just set CPU quota for the project to 1 and then create 2 instances with 1vcpu each in parallel.
14:22:36 mnaser s10: oh i can see it but digging into solution and all, but out of time for that :)

Earlier   Later