Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-03-06
10:24:18 gibi bauzas: this the that API patch for bandwidht, turning the functionalty on https://review.openstack.org/#/c/636360/
10:24:28 gibi bauzas: mriedem already +2-d it
10:24:44 bauzas I know, I was planning to vote on it soon
10:24:49 gibi bauzas: cool. thanks
10:33:38 openstackgerrit Balazs Gibizer proposed openstack/nova master: Test macvtap port with resource request https://review.openstack.org/641309
10:33:59 gibi it is a functional test only patch ^^
10:34:02 gibi sean-k-mooney: ^^
10:52:58 openstackgerrit Neil Jerram proposed openstack/nova master: Allow utime call to fail on Flat image base file https://review.openstack.org/641315
11:06:21 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Store InstancePCIRequest.numa_policy in DB https://review.openstack.org/624444
11:06:22 openstackgerrit Stephen Finucane proposed openstack/nova master: fakelibvirt: Add ability to generate fake PCI devices https://review.openstack.org/640409
11:06:22 openstackgerrit Stephen Finucane proposed openstack/nova master: tests: Create PCI tests for NUMA'y tests https://review.openstack.org/640826
11:06:48 stephenfin gibi, bauzas: Any chance you could take a look at those today (or at least the bottom one)?
11:07:47 bauzas stephenfin: sure, I dedicated my time today for reviews
11:07:57 bauzas spread the word
11:08:26 gibi stephenfin: looking
11:14:09 gibi stephenfin: I'm +2 on the whole series. It really made those sriov tests more readable at the end
11:14:32 stephenfin gibi: Sweet. Thanks.
11:15:37 stephenfin gibi: I'd been thinking about maybe using Jinja2 templates for that entire file, but I'll tackle that later/separately :)
11:16:00 stephenfin gibi: If it's not too much, this might also be of interest to you https://review.openstack.org/#/c/636383/ (another clean up'y one)
11:18:31 gibi stephenfin: I will check that after launch
11:18:34 gibi lunch
11:18:38 stephenfin ta :)
11:46:11 openstackgerrit Neil Jerram proposed openstack/nova master: Allow utime call to fail on qcow2 image base file https://review.openstack.org/641315
12:25:51 openstackgerrit Merged openstack/nova master: Fix WeighedHost logging regression https://review.openstack.org/641143
13:15:58 openstackgerrit Eric Fried proposed openstack/nova master: Warn if group_policy is missing from flavor https://review.openstack.org/641289
13:23:21 frickler eandersson: check whether your compute endpoint is v2 or v2.1. the former doesn't support microversions.
13:24:47 frickler probably osc should do some better guarding against that
13:25:39 sean-k-mooney frickler: osc does not support auto microversions either but yes if you pass one explcitly i coudl check that you are not using the v2 endpoint
13:26:36 frickler sean-k-mooney: see the backlog from yesterday. "openstack --os-compute-api-version 2.15 server group create anti-affinity-test --policy soft-anti-affinity" fails when I change my compute endpoint url from /v2.1 to /v2
13:27:39 sean-k-mooney frickler: sure you are using an explcitly microverions it could guard against that but osc doese not really have any special logic to handel microversions
13:29:38 frickler sean-k-mooney: hmm, o.k., maybe then nova should throw an error when the client requests 2.15 instead of silently falling back to 2.0 behaviour
13:30:03 sean-k-mooney that woudl be a backwards incompatiable chagne
13:30:12 sean-k-mooney and would break those that expect it
13:30:34 sean-k-mooney the v2 endpoint is unversioned so by deffinion it shoudl not be doing version checks
13:30:54 yonglihe sean-k-mooney: hi, good morning
13:31:26 openstackgerrit Andrey Volkov proposed openstack/nova stable/rocky: Check hosts have no instances for AZ rename https://review.openstack.org/641351
13:32:05 frickler sean-k-mooney: hmm, o.k., let's wait for eandersson to confirm whether I located his issue before continuing that discussion ;)
13:38:19 mriedem sean-k-mooney: https://blueprints.launchpad.net/nova/+spec/libvirt-neutron-sriov-livemigration is next in the runways slot but is that going to make stein in the next 24 hours?
13:38:40 mriedem my guess is no looking at the state of the series
13:40:34 yonglihe mriedem, sean-k-mooney: any suggest on https://review.openstack.org/#/c/621476/? sean-k-mooney had quiet a lot concern about the sockets/threads/cores that reported to user.
13:41:39 mriedem yonglihe: the contents of that regarding numa are not my strong area so i will have to defer to sean-k-mooney and stephenfin and others
13:43:03 yonglihe ok, i collected them into https://docs.google.com/document/d/1kRRZFq_ha0T9mFDOEzv0PMvXgtnjGm5ii9mSzdqt1VM/edit# , might be easier to work on. sean-k-mooney , stephenfin.
13:43:19 mriedem tssurya: i copied you on an email to jose about https://review.openstack.org/#/c/613039/ since he's at cern as well - just fyi
13:43:33 yonglihe but seems time for stein is quite tight.
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?

Earlier   Later