Earlier  
Posted Nick Remark
#openstack-nova - 2019-09-06
19:59:36 efried aspiers: beaut, thanks for following up. +A
20:04:15 aspiers efried: yw. Don't hesitate to ask if I can (attempt to) help explain other oddities in the remaining two patches
20:22:07 mriedem artom: dansmith: since stephen and sean aren't around, i'll ask you this https://review.opendev.org/#/c/621476/62/nova/api/openstack/compute/server_topology.py@66
20:22:10 mriedem since i don't know numa
20:22:53 dansmith same pagesize on all cells, is that what you mean?
20:22:57 mriedem yeah
20:23:21 dansmith they will all have a pagesize and they'll all be identical
20:23:30 dansmith I asked that earlier in artom's series
20:23:42 mriedem if they will all have a page size why is that conditional?
20:24:12 dansmith oh, not sure they will all always have a pagesize, but if any do, they'll be the same
20:24:35 dansmith now, that's a libvirt/x86 thing.. I can imagine power allowing multiples because some team in DB2 asked for it in 1996
20:24:54 mriedem ok, that works for me
20:24:55 dansmith all that probably depends on the hypervisor and arch
20:25:11 mriedem this is an intel (tm) api so don't worry about it
20:25:15 dansmith so I'm sure this api will be broken for other ones that aren't considered here
20:25:19 dansmith WONderful
20:25:46 mriedem powerstackers was burned out of governance b/c eric wouldn't lead them anymore
20:25:59 mriedem and the z folks have moved onto openshift on mainframes
20:26:06 dansmith shocking
20:26:37 mriedem has to be weird when the german customers ask for sles + openshift on their z mainframe
20:52:51 mriedem so this is the 2.78 server numa topology command output right now in the proposed change: http://paste.openstack.org/show/772110/
20:52:54 mriedem that....sucks
20:58:12 sean-k-mooney libvirt/qemu support having muliple page size even in the same numa node but we dont support that in openstack and likely never will
20:58:40 mriedem sean-k-mooney: ok i'll stop writing up that spec for ussuri
20:58:43 mriedem i thought you'd be on board
20:58:48 mriedem but i guess you don't like that kind of excitement
20:59:10 sean-k-mooney if you want to debug it when it does not work feel free
20:59:23 mriedem heh
20:59:31 mriedem obviously i'm joking
20:59:55 mriedem i've been trying to come up with some kind of hardware schmorgasbord name generator thing to get your goat
21:00:45 sean-k-mooney just pick 3 random letters and its proably some future NFV hardware thing
21:00:51 mriedem FUK
21:01:01 sean-k-mooney :)
21:01:09 mriedem failover uber kernel
21:01:13 mriedem it's a new DR thing
21:01:28 sean-k-mooney i thought it was a brexit reference
21:01:35 sean-k-mooney but ok :)
21:01:37 mriedem you've been boris'ed
21:01:59 mriedem btw https://www.youtube.com/watch?v=dXyO_MC9g3k if you haven't seen that, it's pretty good
21:02:35 sean-k-mooney i have not, i look forword to it :)
21:04:12 mriedem ok, time for some cli design,
21:04:15 mriedem who's in?
21:04:17 mriedem http://paste.openstack.org/show/772111/
21:05:02 mriedem that's better than before, but the list of nodes in json string is not great,
21:05:23 sean-k-mooney is that the output for the toplogy api?
21:05:25 mriedem but if you dumped each node dict as a separate property, what would you name the property? because that host_node field is only in the response for admins,
21:05:29 mriedem yeah, in the cli
21:05:31 mriedem proposed cli
21:05:55 mriedem so if you're an admin, you could name each one as node{host_node} so like node0 and node1
21:06:01 sean-k-mooney can we pretty print the json blob
21:06:11 mriedem but if you're not admin, calling them node0 or node1 could make the user think they are actually on those physical host numa nodes
21:06:57 mriedem hmm, maybe
21:14:58 sean-k-mooney its a litte more readable. http://paste.openstack.org/show/772112/ i didnt put it in the ascis table
21:15:11 sean-k-mooney but you could also do somithing like
21:15:44 mriedem that's what i already have http://paste.openstack.org/show/772111/
21:16:02 sean-k-mooney |node.[0].cpu_pinning | {"0": 0,"1": 5}
21:16:10 mriedem anyway, i've got this better than it was so i'll push it up and someone else can hack on it
21:16:22 mriedem it's not even my patch
21:17:48 sean-k-mooney the latest windows update sucks ...
21:17:57 mriedem 10...?
21:18:02 sean-k-mooney ya
21:18:07 mriedem i'm rocking 7
21:18:28 sean-k-mooney it install an update last night and now its haning if i boot it in a vm
21:18:49 sean-k-mooney if i reboot the host indo the same windwos install its fine
21:21:35 sean-k-mooney i did like 7. i think i still have my 7 ultimate 64bit dvd around somewhere.
21:21:57 mnaser efried_afk: thanks for driving the SIGHUP patches stuff, i ran out of bandwidth
21:22:15 efried mnaser: yahyoubetcha. Glad to have that fixed finally.
21:22:37 prometheanfire os-brick update is breaking nova :( https://review.opendev.org/680339
21:22:59 efried prometheanfire: does cinder know?
21:23:04 efried (I didn't click yet)
21:23:15 mnaser AttributeError: 'module' object has no attribute 'NVMeConnector'
21:23:50 mnaser https://github.com/openstack/os-brick/commit/0f057aee6e0351bdef68fadf1fc56ac315027c98
21:23:53 prometheanfire no, test fails were in nova so pinged you first
21:24:01 mnaser im guessing those are the fails
21:24:11 mnaser the module was renamed
21:24:24 openstackgerrit Matt Riedemann proposed openstack/python-novaclient master: Microversion 2.78 - show server topology https://review.opendev.org/670790
21:25:15 sean-k-mooney are the nova unit test mocking stuff in os-bricks
21:25:20 prometheanfire try import except import?
21:25:33 mnaser btw
21:25:36 mnaser there is some context here https://review.opendev.org/#/c/643421/
21:27:08 sean-k-mooney ok so we are importing the conector object in the test
21:27:41 mnaser `initiator.NVME` that was left around for backwards compat
21:28:01 mnaser but the connector did not keep a backwards compat
21:29:07 mnaser i mean as a work around you could fall back to asserting the initiator used instead of the connector used
21:29:45 sean-k-mooney so the real driver code use the factory method to consurct it
21:29:47 sean-k-mooney https://github.com/openstack/nova/blob/master/nova/virt/libvirt/volume/nvme.py#L34
21:30:04 mnaser sean-k-mooney: it uses `initiator.NVME` which is still around
21:30:23 sean-k-mooney i think the real fix is to not assert thing abot the data type of an external lib
21:30:39 mnaser https://github.com/openstack/os-brick/blob/0f057aee6e0351bdef68fadf1fc56ac315027c98/os_brick/initiator/connector.py#L117-L122
21:30:40 mnaser cause thats still around
21:30:52 sean-k-mooney mnaser: yes but i guess they considerd as part of the public interface
21:31:01 sean-k-mooney and the conector object are not
21:31:30 mnaser maybe the test should mock `connector.InitiatorConnector.factory` and make sure it calls it with initiator.NVME ?
21:31:39 mnaser which is enough to know we are doing the right thing(tm)
21:32:00 sean-k-mooney maybe but its stil mocking stuff we dont own
21:32:06 sean-k-mooney but that seams safer
21:32:16 mnaser well at least it makes sure that we're creating a connector with the right type of initiator
21:32:16 sean-k-mooney sice we are mocking somethign we are calling
21:32:29 mnaser which i think is the biggest thing that test is supported to do..
21:32:43 sean-k-mooney right but that is not novas job to test

Earlier   Later