Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-12-04
13:47:34 jaypipes sean-k-mooney2: why can't VFs be created at runtime?
13:48:18 sean-k-mooney2 jaypipes: the linux kernel does not have an interface to do so without removeing and reallocating all vfs on the pf
13:48:51 sean-k-mooney2 our nics and technically dpdk can
13:49:14 jaypipes sean-k-mooney2: interesting. why didn't nvidia enhance the existing SR-IOV drivers/VF interface instead of inventing a whole new interface?
13:49:34 openstackgerrit Jay Pipes proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807
13:49:34 openstackgerrit Jay Pipes proposed openstack/nova master: placement: allow filter providers in tree https://review.openstack.org/377215
13:49:35 openstackgerrit Jay Pipes proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693
13:50:34 sean-k-mooney2 jaypipes: well sriov is a standard by the pcisig and when you create a vf you need to create a new pci endpoint on the host pcie bus for that vf which is no trivial in hardware at runtime
13:50:53 jaypipes alex_xu: great catch on https://review.openstack.org/#/c/384807. I've updated and added a new func test to catch CannotDeleteParentResourceProvider
13:51:24 jaypipes sean-k-mooney2: and what's different about mdev in that respect?
13:52:37 sean-k-mooney2 they are attached to a new bus /sys/bus/mdev and not the pci bus. you create them by echoing a uuid to a file under a partent device then acress them via the uuid after tehy are created
13:53:16 jaypipes sean-k-mooney2: ack. but why couldn't the PCI spec be changed to allow a similar functionality? I'm just curious
13:54:27 sean-k-mooney2 jaypipes: im guessing backwards compatiblity but im not sure. one of the other advanatages of vfio-mdevs ist that it does not need hardware support. it can all be done in the driver
13:54:47 jaypipes sean-k-mooney2: ack
13:55:40 sean-k-mooney2 so if you had a nic without sriov with say 4 tx/rx pairs and you impmented mdev support you could create 4 mdevs one for each queue pair and use it like 4 nics. sriov would require hardware support to do the same
13:57:18 jaypipes sean-k-mooney2: or just use PowerVM, which solves all problems for everyone.
13:57:37 efried Correction: Since Newton.
13:57:49 jaypipes heh
13:58:11 sean-k-mooney2 jaypipes: :) certily solve my problem of exposing intel ad vaule in hardware
13:59:09 openstackgerrit Lajos Katona proposed openstack/nova master: Extend ServerMovingTests with custom resources https://review.openstack.org/497399
13:59:33 sean-k-mooney2 so any way i may have to backport whatever i come upwith to pike hence my earlir question though im trying to avoid that give howmuch is changeing in this space
14:00:01 edleafe Scheduler subteam meeting starting now in #openstack-meeting-alt
14:00:23 sean-k-mooney2 oh im late for a meeting too...
14:01:13 efried sean-k-mooney2 It would be a tough backport, because yeah, queens is going to have huge deltas in this area.
14:02:01 alex_xu jaypipes: there is another comment at https://review.openstack.org/#/c/377215/66
14:03:37 sean-k-mooney2 efried: yep and doing it in a way that will be upgradable to queens will be very hard which is why im trying to push that out of scope but first i need to understand if its technically possible or not
14:04:50 efried sean-k-mooney2 It might be doable for custom resource classes. What did you have in mind?
14:06:59 sean-k-mooney2 custom resouce class create by neutron ovs agent extention, + os-vif plugin to create mdevs during plug + new vnic type to request a vhost-vfio port like we do with sriov
14:07:51 sean-k-mooney2 + the smallest patch to nova possibel to cover xml generation changes in libvirt driver and doing the resouce claim in placement.
14:13:18 gibi sean-k-mooney2: be aware that in pike custom resource classes only works if it is reported by the nova-compute in the RP that represents the compute node. All the other option needs either shared RP or nested RP
14:13:50 jaypipes alex_xu: responded.
14:16:22 alex_xu jaypipes: yea, the uuid and name aren't in opposition, but sorry, I didn't get what your mean about the 'member_of'
14:20:52 openstackgerrit Silvan Kaiser proposed openstack/nova master: Added mount fstype based validation of Quobyte mounts https://review.openstack.org/522245
14:23:18 openstackgerrit Silvan Kaiser proposed openstack/nova master: Added mount fstype based validation of Quobyte mounts https://review.openstack.org/522245
14:27:13 jaypipes alex_xu: that was responding to bauzas' comment about using member_of instead of tree. member_of is for aggregates, not for provider trees.
14:28:19 alex_xu jaypipes: ah, got it
14:31:00 bauzas jaypipes: oh my bad, you're right
14:31:57 bauzas jaypipes: tbc, I'm not opiniated by which key we should use, just the point that we need to make sure it works with a call having all of them :)
14:32:06 openstackgerrit Matthew Booth proposed openstack/nova master: Make BlockDeviceMapping object support uuid https://review.openstack.org/242603
14:32:06 openstackgerrit Matthew Booth proposed openstack/nova master: Add uuid column to BlockDeviceMapping https://review.openstack.org/242602
14:32:14 jaypipes bauzas: ack
14:32:31 bauzas "tree" is maybe a bit difficult to understand, but I'm not an English folk :)
14:45:22 sean-k-mooney2 gibi: ah yes that is a good point. i would prefer to use nested resouce providers as logically the mdev resouce are a nested resouce of a parent device. in my case a pcie device but technically mdevs could be childern of device on buses other the pci bus.
14:46:39 gibi sean-k-mooney2: I agree that the best would be to have nest RPs for it
14:46:52 efried jaypipes bauzas alex_xu Oh, I wasn't following the conversation in here; I left a (verbose, as usual) comment.
14:47:05 jaypipes efried: on what?
14:48:15 jaypipes efried: in any case, I'm currently adding func tests that add member_of and uuid filters to a tree filter.
15:01:03 alex_xu efried: I don't the tree and resources will work as your expected. The 'GET /resource_providers' just a simple filtering, it is different with the filtering of 'GET /allocation_candidates'
15:02:40 efried jaypipes alex_xu Sorry, I was talking about https://review.openstack.org/#/c/377215/
15:02:44 efried I'm coming at it from the perspective of how I think the REST API should work, not looking at the code.
15:03:14 efried The func tests jaypipes is suggesting should bear out what I said in my comment; and if not, it's a bug that we can fix, right?
15:04:43 openstackgerrit Takashi NATSUME proposed openstack/nova master: [placement] Add sending global request ID in delete https://review.openstack.org/525231
15:07:13 jianghuaw_ bauzas, the vGPU relative calls have been there since the minimal version of XS supported by nova. So there is no need to check XenServer's version.
15:07:38 openstackgerrit Jay Pipes proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807
15:07:38 stephenfin dansmith: Question on this patch for you https://review.openstack.org/#/c/514309/
15:07:38 openstackgerrit Jay Pipes proposed openstack/nova master: placement: allow filter providers in tree https://review.openstack.org/377215
15:07:39 openstackgerrit Jay Pipes proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693
15:07:52 jaypipes bauzas, alex_xu, efried: k, func tests added for tree filter + uuid/member_of
15:08:19 dansmith stephenfin: where?
15:08:29 bauzas jianghuaw_: gtk
15:08:36 stephenfin dansmith: The 'tempest-dsvm-neutron-src-oslo.versionedobjects' job
15:08:53 stephenfin dansmith: I migrated that because it seemed we were the only caller
15:09:15 bauzas jianghuaw_: kaboom then
15:09:34 stephenfin But I see now that there are many 'tempest-dsvm-neutron-src-{library}' jobs and '{library}' is usually wildcarded, so that should probably live in oslo.versionedobjects
15:09:42 jianghuaw_ bauzas, thanks:-)
15:10:26 dansmith stephenfin: sorry, I blame the early hour for my confusion but.. what are you asking? if other projects have o.vo jobs?
15:11:21 stephenfin dansmith: Yes. Just a sanity check
15:12:18 dansmith stephenfin: tbh, that's not a thing I know and I would expect it to be more of a core oslo thing, policy for running library jobs against projects that use them and such
15:12:42 dansmith stephenfin: I think nova, neutron, ironic at least use o.vo
15:12:49 jianghuaw_ bauzas, I guess this one would be much easier as you ever +2/+w on it:-) https://review.openstack.org/#/c/516217
15:13:11 bauzas jianghuaw_: next one :)
15:13:25 jianghuaw_ cool:-)
15:13:26 efried jaypipes It would be nice to have a func test for resources + tree -- I think that was a main concern of alex_xu's. But we can do it in a followup too.
15:13:27 stephenfin dansmith: That's fair. I picked on you as you were the one that enabled the test for nova (commit ac96f95 in openstack-infra/project-config). No good deed :)
15:13:34 stephenfin I'll go bug AJaeger
15:13:50 dansmith stephenfin: probably at the behest (and handholding) of some infra deity :)
15:17:27 openstackgerrit Takashi NATSUME proposed openstack/nova master: Fix 500 error while passing 4-byte unicode data https://review.openstack.org/407514
15:20:53 efried jaypipes I was about to rebase "make _Provider private" -- did you have any feedback on uuid_set() (https://review.openstack.org/#/c/520243/) so I can hit it at the same time?
15:37:22 openstackgerrit Eric Fried proposed openstack/nova master: ProviderTree.uuid_set() https://review.openstack.org/520243
15:37:22 openstackgerrit Eric Fried proposed openstack/nova master: Make _Provider really private https://review.openstack.org/523932
15:37:28 efried jaypipes ^
15:40:00 mdbooth dansmith: You mentioned last week that you didn't think I could add a unique constraint to the uuid column in the first instance. You also say the same explicitly in a comment, so I assume there's a good reason. Do you recall what it is?
15:41:31 dansmith mdbooth: you can if it's nullable I think, but I think I thought you were asserting that you were going to create the column and make it non-nullable/unique right away and that's what I was trying to say was not okay
15:41:57 mdbooth dansmith: Yeah, I was going for unique/nullable.
15:42:17 mdbooth Any reason I shouldn't add the unique constraint to your patch?
15:42:49 dansmith if you can add it to the schema without code changes or moving data, then it's cool to add it yeah
15:43:05 mdbooth Will do, thanks
15:45:10 tssurya mriedem: ping
15:51:52 openstackgerrit Balazs Gibizer proposed openstack/nova master: Add late server group policy check to rebuild https://review.openstack.org/525242
15:51:55 mdbooth dansmith: Second question: update by uuid. I'm assuming that when you were adding this first time round you anticipated needing this. I don't think I need it. I could add it for completeness, or omit it until there's a caller. Personal preference would be the latter.
15:53:37 dansmith mdbooth: I probably had it for tests or something, but sure, no need to have it if there is no user
15:59:22 openstackgerrit Jackie Truong proposed openstack/python-novaclient master: Microversion 2.57 - Add trusted_image_certificates https://review.openstack.org/500396
16:07:37 mdbooth dansmith: Thanks
16:13:09 ildikov mriedem: hi, I updated the patch with the fixes to your comments
16:13:30 ildikov mriedem: I didn't have the stomach as of yet at least to do the split...
16:13:45 mriedem ildikov: ok
16:14:30 ildikov mriedem: if you have time plz continue to review and I will fix it in either one or two patches
16:15:16 mriedem i hope to get to it today, but have to work on some other stuff this morning
16:16:45 ildikov appreciated if you can get to it today
16:33:24 tssurya mriedem: I am stuck on this - https://bugs.launchpad.net/nova/+bug/1729806/comments/1 , because both those columns are of type "Text()" and SQL doesn't allow text type columns to have a unique constraint; any pointers on how you usually do this in nova ?

Earlier   Later