Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-12-13
12:53:45 sean-k-mooney RTNETLINK answers: Cannot assign requested address
12:54:17 adrianc sean-k-mooney: libvirt in the case of macVtap will just set the mac on the vf netdev not the vf index (e.g 'administrative mac') and restores it to the previous value on teardown
12:54:55 adrianc sean-k-mooney: enjoy the christmas event !
12:54:58 sean-k-mooney ya, ill combine our two patches and also fix the unit test which strangly passed form me before but whatever
12:55:57 adrianc ack thanks, on my setup i managed to live migrate with ping running within the migrating VM so it seems to be working
12:59:47 openstackgerrit Merged openstack/nova stable/pike: Make supports_direct_io work on 4096b sector size https://review.openstack.org/619254
12:59:50 openstackgerrit Matt Riedemann proposed openstack/nova stable/rocky: Make compute rpcapi version calculation check all cells https://review.openstack.org/624982
13:27:04 stephenfin sean-k-mooney: Before I submit the next version of this, thoughts on https://review.openstack.org/#/c/624444/1/nova/objects/instance_pci_requests.py ?
13:28:48 cdent mriedem, stephenfin: jaypipes was +W on this before I found (and fixed) a race, so if you're inclined to give it a gander: https://review.openstack.org/#/c/617941/
13:29:42 stephenfin cdent: mriedem has already taken a look at that, so if he has time I'll leave it to him
13:30:02 cdent ✔
13:30:43 sean-k-mooney thanks i stephenfin so the default numa afinity policy was ment to keep backward compatiblyt with existing behavior whic was the legacy policy im not sure if https://github.com/openstack/nova/blob/f572527d2b7f93b0c2108118c2f240f2dd1cf968/nova/pci/stats.py#L155 does that
13:31:32 mriedem i looked at one file in there :)
13:31:41 stephenfin sean-k-mooney: nope, but the function called on the next line after that does https://github.com/openstack/nova/blob/f572527d2b7f93b0c2108118c2f240f2dd1cf968/nova/pci/stats.py#L240
13:31:41 sean-k-mooney i assuem it does but i hate the fact we assuem things in the code. e.g. that if cpu_policy is not dedicated it is shared.
13:31:50 stephenfin mriedem: Oh :) I can take a look so
13:32:35 mriedem cdent: just this yeah? https://review.openstack.org/#/c/617941/30..31/nova/tests/functional/test_nova_status.py
13:32:47 cdent mriedem: that was the latest change, yes
13:33:06 sean-k-mooney stephenfin: so yes it will do the right thing eventrully i just prefer to set the vaules as early as possibel rather then doing late tests
13:33:26 cdent the race there didn't show up for test after test after test, and then it was at the good slot in the gate and failed
13:34:07 mriedem cdent: done
13:35:17 sean-k-mooney stephenfin: its up to you ill remove my -1 but its just a style thing i guess i prefer to explitly state thing up front rather then defenively check later
13:36:12 stephenfin sean-k-mooney: I can add it. No harm
13:36:45 cdent mriedem: I and my lines removed stats thank you
13:37:31 openstackgerrit Stephen Finucane proposed openstack/nova master: conf: Call out where pci.alias should be set https://review.openstack.org/624445
13:37:31 openstackgerrit Stephen Finucane proposed openstack/nova master: objects: Store InstancePCIRequest.numa_policy in DB https://review.openstack.org/624444
13:37:38 sean-k-mooney stephenfin: ok other then that i was happy with the change over all however looks like the unit tests were less so
13:37:49 stephenfin sean-k-mooney: Yeah, one test that I missed. Fixed now
13:39:19 stephenfin gibi, mriedem: Could you take a look at this follow up docs patch today? https://review.openstack.org/#/c/614322/
13:39:39 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Add irrelevant-files for grenade-py3 jobs https://review.openstack.org/624997
13:46:05 gibi stephenfin: +2 from my side
13:46:18 frickler mriedem: now that my stable patches have merged, can we talk about a new round of releases? would save me from having to run on custom-built pkgs. I'd mostly be interested in pike and queens currently
13:46:19 stephenfin gibi: Thank you
13:54:45 mriedem frickler: we normally do the releases in order starting from the most recent, so rocky->queens->pike,
13:54:55 mriedem idk if melwitt was planning a stable release soon or not
13:58:50 frickler melwitt: mriedem: at least I'd say it looks like a nice bunch of things has piled up at https://docs.openstack.org/releasenotes/nova/rocky.html#relnotes-18-0-3-38-stable-rocky
14:00:34 gibi nova team meeting is starting on #openstack-meeting
14:03:52 mriedem frickler: i'll bring it up in the team meeting
14:06:15 frickler mriedem: cool, thx
14:08:42 mriedem lyarwood: want to hit this backport https://review.openstack.org/#/c/624813/
14:13:08 lyarwood mriedem: LGTM, I don't think I've actually asked but you don't have an issue with me proxying stable core votes in changes like this right?
14:14:18 mriedem lyarwood: you see me doing that on yours right?
14:14:30 lyarwood mriedem: right, just checking.
14:14:45 mriedem i think it's ok for clean backports on clear bug fixes
14:15:15 lyarwood yeah agreed, I still feel slightly uneasy about it sometimes but this example is simple etc.
14:15:24 mriedem if it's something like stephen's series here https://review.openstack.org/#/c/588570/ then that's a different story
14:15:58 lyarwood stephenfin: ^ I was going to ask if you wanted to drop this btw
14:16:16 stephenfin lyarwood: Oh, yeah. I'll abandon that now
14:16:16 mriedem with extended maintenance it's less bad if we screw up on stable b/c we have time to fix it,
14:16:29 lyarwood stephenfin: thanks
14:16:31 mriedem plus we just have fewer people reviewing stable and i hate to let fixes sit for months
14:16:48 lyarwood yup indeed, cool that's clear now thanks.
14:26:14 stephenfin sean-k-mooney: Thoughts on this? https://review.openstack.org/#/c/625011/ Could be a more programmatic solution to https://review.openstack.org/#/c/624445/
14:33:10 cdent mnaser, coreycb, anyone else: I'll spin up an etherpad on the "path internal to nova to happy placement extraction" topic and invite you to help refine it. Won't be today, but soon
14:37:26 openstackgerrit Stephen Finucane proposed openstack/nova master: Summarize output of sample configuration generator https://review.openstack.org/625014
14:37:46 gibi mriedem: when you have a minute, can you check back to https://review.openstack.org/#/c/624740/
14:37:49 openstackgerrit sean mooney proposed openstack/nova master: Libvirt: do not set mac when unplugging macvtap vf https://review.openstack.org/624842
14:38:42 frickler coreycb: did you make progress with building pike with stestr? otherwise we should maybe also consider reverting https://review.openstack.org/580492 before the next stable/pike release
14:39:49 frickler mriedem: melwitt: ^^ not sure whether you had seen that some weeks ago. stestr isn't in the original set of pike reqs, so building the latest release there was broken on ubuntu
14:40:31 frickler also sorry that I didn't remember to mention that for the meeting
14:41:48 openstack Launchpad bug 1806079 in OpenStack Compute (nova) "revert use of stestr in stable/pike" [Wishlist,In progress] - Assigned to Corey Bryant (corey.bryant)
14:41:48 frickler oh, there's https://bugs.launchpad.net/nova/+bug/1806079 for that already
14:42:40 mriedem gibi: looking
14:43:04 gibi adrianc: hi! we talked about sriov after the bandwidth demo in Berlin. I think I see the way forward how to influence which VF nova-compute chooses for a neutron port https://review.openstack.org/#/c/623543
14:43:23 mriedem frickler: yes i specifically requested that from mtreinish for reasons stated in the patch/bug
14:43:40 mriedem https://review.openstack.org/#/c/621227/2//COMMIT_MSG@12
14:43:41 gibi adrianc: the patch is still WIP but the the logic is already visible
14:44:13 frickler mriedem: yeah, I was just reading that. if it reverts cleanly, I guess it should be fine to carry the revert on the ubuntu branch
14:44:26 mriedem yeah
14:44:26 mriedem frickler: as coreycb said, they can carry it as a patch for them on pike
14:45:03 gibi mriedem: futurist added to the nova lower-constraints when the global lower constraints was moved from the global requirement to per project
14:45:14 adrianc gibi: Hi, ill put this in my review list
14:45:25 gibi adrianc: cool
14:45:38 mriedem gibi: and that was done blindly via automation,
14:45:46 gibi mriedem: I guess so
14:45:47 mriedem before your change, nova didn't use futurist, so this is the first usage of it,
14:45:52 gibi mriedem: true
14:45:53 mriedem which means, we should use what we gate against,
14:45:58 mriedem so use the version from u-c
14:46:24 gibi mriedem: when u-c changes then our lower constraints can diverge from u-c is that OK?
14:46:31 mriedem yeah
14:46:36 mriedem we have a lower-constraints unit test job for that,
14:46:46 mriedem but upper-constraints is used in both unit/functional/tempest integration testing
14:46:59 mriedem lower-constraints is kind of a 'cover your bare ass' job
14:47:05 cdent mriedem: its broken until https://review.openstack.org/#/c/622972/
14:47:56 gibi mriedem: OK, then I will fix up the patch by bumping the lower constraints of futurist to 1.8.0
14:50:29 mnaser cdent: cool thanks
14:50:32 adrianc gibi: is there also code that deals with the migration use-case ? (cold and live-migration)
14:50:47 openstackgerrit Merged openstack/os-vif master: Create iproute.IPRoute() inside a context https://review.openstack.org/624831
14:51:32 gibi adrianc: not yet. that patch series only works with boot, delete, re-schedule. I'm working on the instance move cases
14:52:37 gibi cdent: I can try my patch with your lower constraint fix to see if everything works after both
14:52:40 adrianc gibi: ack :)
14:53:00 gibi adrianc: ohh one more thing, interface detach works as well :)
14:54:24 adrianc gibi: good to know! sean-k-mooney ^ hopefully the direct support will go smoothly
15:03:26 sean-k-mooney gibi: well i intend to detach the interface at the hypervior level but i wont actully be detaching the interface form a neutron point of view
15:03:49 sean-k-mooney adrianc: ^
15:04:35 sean-k-mooney from a nova and neutron point of view the interfce need to remain attached to the instance as it does in the macvtap case for schduling to work
15:05:06 sean-k-mooney so i plan on only detaching at the libvirt level
15:05:19 gibi sean-k-mooney: a think we are thinking about two different use case. you are working on live-migrate and I work on detaching a port that has bandwidth allocation in placement
15:05:35 sean-k-mooney gibi: yep

Earlier   Later