Earlier  
Posted Nick Remark
#openstack-nova - 2019-03-06
13:43:34 mriedem tssurya: since we've got <24 hours to land that
13:43:42 mriedem yonglihe: yes it is
13:43:53 tssurya mriedem: ack, thanks
13:44:17 mriedem tssurya: i'm of course assuming cern is very small and everyone knows everyone else and what they are working on...
13:44:42 sean-k-mooney yonglihe: o/
13:44:43 tssurya mriedem: yep I am going to pass by his office now :)
13:44:50 mriedem tssurya: oh heh i was just joking
13:44:51 mriedem but cool
13:45:13 openstackgerrit Merged openstack/nova master: Validate bandwidth configuration for other VIF types https://review.openstack.org/636383
13:45:22 openstackgerrit Merged openstack/nova master: Further de-dupe os-vif VIF tests https://review.openstack.org/636384
13:46:40 sean-k-mooney yonglihe: so overall i dont think the datamodel is quite right. given the time constraitns i personally would be more comfortable waiting for train to finalise it but i can take a look at the google doc. etherpad thens to be a good choice for this kind of thing also
13:47:54 sean-k-mooney yonglihe: one of the main issues is the current proposed api is coupeling cpu topology and numa topology but they are independnt fo each other which is why im concerned the current data model is missleading
13:48:31 openstackgerrit Matt Riedemann proposed openstack/nova stable/rocky: Fix WeighedHost logging regression https://review.openstack.org/641355
13:49:37 yonglihe sean-k-mooney, yeah, i get that. it's mass. how about delete the cpu topology toltally.
13:51:00 bauzas gibi: +Wd with a comment on https://review.openstack.org/#/c/636360/23
13:51:02 yonglihe considerating the time factor, it's up to you choosing what we can do on the stein, or postpone to next release. both ok for me.
13:51:19 sean-k-mooney you could or you could group it seperatly. e.g. in the toployg endpoint you get back a dict with two fields {cpu_toplolgoy:{}, numa_toplogy[{},{}]}
13:51:49 gibi bauzas: thanks, replied
13:52:05 tssurya mriedem: josecastroleon is working on it
13:52:10 bauzas gibi: great, that works with me
13:52:17 gibi cool
13:52:19 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: Fix WeighedHost logging regression https://review.openstack.org/641359
13:52:20 bauzas for docs, I dunno where to land docs
13:52:30 bauzas given that's both neutron/nova
13:53:03 bauzas stephenfin: thoughts for doc'ing bandwith RPs feature ?
13:53:08 bauzas in nova, neutron or both ?
13:53:22 gibi bauzas: from nova perspective only the API limitations and the vrit driver dependency are externally visible, the rest is neutron configuration and neutron API
13:53:30 bauzas stephenfin: how can we write some admin notes given docs are now per project ?
13:53:47 stephenfin bauzas: Depends on where most of the work has to be done. It _feels_ like more of a neutron thing, IMO
13:54:02 bauzas oki doki, I'm good with this
13:54:22 stephenfin bauzas: SR-IOV networking is probably the closest thing we have and that is in the neutron guide, though we do have references to it in our docs
13:54:43 mriedem tssurya: thanks
13:54:44 bauzas that's my point, we probably still need references to it
13:55:32 stephenfin sean-k-mooney: what was the reply to mriedem's question about the libvirt-neutron-sriov-livemigration spec? You think it's reasonable to land
13:56:06 stephenfin (FWIW, I have reviewed it myself multiple times and I don't _think_ any of jaypipes' comments were too serious)
13:56:31 yonglihe sean-k-mooney: good idea, then seems I could not do much on that tonight, and I would like to hear more from you. so after I had a good sleep, than I can catch all comment from you, and trying to change the patch and to see what happens then. anyway, thanks a lot. have a good one.
13:56:47 sean-k-mooney stephenfin: i did not see that question
13:57:24 sean-k-mooney mriedem: ah you were asking if it would make stien in the next 24 hours
13:58:02 sean-k-mooney the main issue i think has been the lack of review so i dont know if people will raise issue
13:58:53 sean-k-mooney mriedem: i think it could land but if you would prefer to defer to train to give it more scurtiny then i can live with that too
13:59:16 sean-k-mooney the neuton depency has merged so its all on the nova side at this point
13:59:52 mriedem i personally think it's probably high risk at this point but i also haven't reviewed it
14:01:17 sean-k-mooney ya thats fair. its less high risk then the numa stuff since sriov live migration never work before in any scenairo so we cant break it more then it was but obviosly we want it to be right
14:02:16 sean-k-mooney mriedem: artom has modifed the openlab request to see if we could get sriov capably servers so we can test it as part of that effort too
14:03:16 stephenfin mriedem: I would suggest taking a glance. There's one patch that is rather bulky but the rest seem compact/grokable. Definitely would benefit from someone with a deep knowledge of the live migration flow too
14:03:24 stephenfin The NUMA stuff is far more involved, yeah
14:07:23 sean-k-mooney ... i need to resovle a merge conflict with gibi's stuff ill work on that now
14:08:00 sean-k-mooney it should be small but we merged a few thing in the last 36 hours that conflicted with this code
14:09:55 mriedem yeah honestly i'm going to be focusing in 2 blueprints today most likely, the rbd extend volume one and maybe we can get the data migration part of melwitt's counting quotas from placement in stein, but i don't know about the rest of it
14:10:01 mriedem *on
14:10:36 mriedem i've taken about a week off from the cross-cell resize stuff and despite it not getting in stein our product team needs it by end of the month so i have to start working on that more
14:10:38 sean-k-mooney mriedem: sure no worries. ill resolve the merge confilcit anyway and redeploy locally to test.
14:11:21 mriedem alex_xu: if i find something that does not require a lot of prior context i will ping you
14:11:33 mriedem although it's late now
14:11:56 mriedem gibi: i left some comments on that neutron docs patch,
14:12:14 mriedem gibi: it reminded me - we don't have any sort of minimum compute service version check from the api for min bw provider support right?
14:12:31 alex_xu mriedem: cool, I empty tomorrow for help something
14:13:10 mriedem gibi: and maybe we don't because of what we talked about the other day with bauzas - if the compute/neutron agent are upgraded to stein then they report inventory, otherwise they don't and the scheduler shouldn't pick them for these types of workloads
14:14:00 gibi mriedem: we dont have compute version checks for the reason you described
14:14:11 mriedem yeah ok
14:24:08 sean-k-mooney jaypipes: thanks for taking the time to review the sriov stuff yesterday just seeing it now ill sync with adrianc to adress all the feedback and we will respin.
14:25:03 adrianc already addressed the comments will upload a PS soon
14:25:40 sean-k-mooney adrianc: ah cool. i was distracted in neutron land the last 2 days
14:25:40 adrianc sean-k-mooney, shall i rebase the direct and indirect patches on top ?
14:25:50 sean-k-mooney am sure
14:25:58 adrianc promise not to loose a PS :)
14:27:00 sean-k-mooney hehe i trust you not to :) i generally work my way from the bottom up and cherrypick the later patches when working on a chain like this
14:27:28 sean-k-mooney that or use interactive rebases if its just my own patches
14:28:22 jaypipes ok, thanks adrianc and sean-k-mooney. will review it as soon as I see the new patches.
14:28:34 sean-k-mooney :)
14:30:08 adrianc sean-k-mooney: gotcha thanks !
14:30:29 adrianc jaypipes: thanks for the inputs
14:36:57 openstackgerrit Adrian Chiris proposed openstack/nova master: Sep methods to free claimed and allocated devs https://review.openstack.org/616120
14:36:57 openstackgerrit Adrian Chiris proposed openstack/nova master: Allow per-port modification of vnic_type and profile https://review.openstack.org/607365
14:36:58 openstackgerrit Adrian Chiris proposed openstack/nova master: Add get_instance_pci_request_from_vif https://review.openstack.org/619929
14:39:20 mriedem https://www.youtube.com/watch?v=jk8SToEQPGw
14:40:44 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Fix WeighedHost logging regression https://review.openstack.org/641398
14:42:04 mtreinish mriedem: I like that the top comments on that are trying to explain the joke...
14:43:25 mriedem mtreinish: i like that you are gone for weeks at a time and only show up, in this channel of all places, when i drop a simpsons video
14:45:14 mtreinish I think that I have my priorities straight
14:45:31 mriedem i don't disagree
14:46:04 sean-k-mooney adrianc: by the way i am assuming you are crurrently rebasing https://review.openstack.org/#/c/620115 on the ohter changes. the final change in the seriese does not use any of the funcitions you modified so that should be a straight cherrypick at the end
14:46:41 openstackgerrit Matt Riedemann proposed openstack/nova stable/rocky: Handle missing exception in instance creation code https://review.openstack.org/641401
14:46:54 openstackgerrit Adrian Chiris proposed openstack/nova master: SR-IOV Live migration indirect port support https://review.openstack.org/620115
14:47:46 adrianc sean-k-mooney: yes
14:47:52 sean-k-mooney :)
14:48:11 mriedem takashin: when you get a chance can you backport https://review.openstack.org/#/c/636271/ please?
14:52:35 mriedem mtreinish: while you're here, see how this job runs tempest with --concurrency=4 http://logs.openstack.org/72/638072/14/check/nova-next/c8ecf61/job-output.txt.gz#_2019-03-06_08_18_20_021174
14:52:43 mriedem but yet it looks like a lot of the tests are running serially
14:52:58 mriedem the first 7 are on the same worker
14:53:19 mriedem unless that just means the other workers were running slower tests at the same time?
14:53:48 mriedem yeah i suppose that's all it is
14:54:43 mtreinish mriedem: yeah I think that's what's going on
14:54:46 mriedem man there are tests in tempest that really just don't belong there
14:54:47 mriedem tempest.api.compute.servers.test_list_server_filters.ListServerFiltersTestJSON.test_list_servers_filter_by_shutoff_status [72.172009s] ... ok
14:54:54 mtreinish the stackviz view is good for visualizing that: http://logs.openstack.org/72/638072/14/check/nova-next/c8ecf61/logs/stackviz/#/stdin/timeline
14:54:56 mriedem create a server, stop it, wait for it to be stopped
14:55:05 HD|Laptop hey all
14:55:08 openstackgerrit Jose Castro Leon proposed openstack/nova master: Extend volume for libvirt network volumes (RBD) https://review.openstack.org/613039
14:55:13 mriedem we could test shutoff server filtering in functional tests

Earlier   Later