Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-12-04
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: Add uuid column to BlockDeviceMapping https://review.openstack.org/242602
14:32:06 openstackgerrit Matthew Booth proposed openstack/nova master: Make BlockDeviceMapping object support uuid https://review.openstack.org/242603
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: allow filter providers in tree https://review.openstack.org/377215
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: adds REST API for nested providers https://review.openstack.org/384807
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: Make _Provider really private https://review.openstack.org/523932
15:37:22 openstackgerrit Eric Fried proposed openstack/nova master: ProviderTree.uuid_set() https://review.openstack.org/520243
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 ?
16:33:26 openstack Launchpad bug 1729806 in OpenStack Compute (nova) "nova-manage update_cell does not check if the same combination of transport_url and database_connection already exists" [Low,In progress] - Assigned to Surya Seetharaman (tssurya)
16:33:37 mriedem ildikov: i looked at the diff, comments in https://review.openstack.org/#/c/330285/
16:34:50 openstackgerrit Eric Fried proposed openstack/nova master: Make _Provider really private https://review.openstack.org/523932
16:36:24 dansmith tssurya: you could check before create, which isn't as good as a constraint, but it'd be an easy thing to do
16:36:29 openstackgerrit Silvan Kaiser proposed openstack/nova master: Added mount fstype based validation of Quobyte mounts https://review.openstack.org/522245
16:36:32 ildikov mriedem: tnx!
16:37:09 mriedem ildikov: and another one just now
16:37:18 mriedem ildikov: the shelved offloaded case probably needs some thought
16:37:23 mriedem could also see what johnthetubaguy thinks
16:37:39 ildikov mriedem: ok, I'll wait a bit longer before touching it :)
16:37:47 mriedem for all intents and purposes, a reserved volume is going to be the same as an in-use volume to nova
16:37:51 ildikov mriedem: sigh, I will look into the comments shortly
16:38:16 johnthetubaguy I was a touch worried about the change in shelved offloaded
16:38:28 mriedem there is an api behavior change with attaching a volume to a shelved offloaded instance with the new flow,
16:38:37 mriedem where the volume is left 'reserved' rather than 'in-use'
16:38:42 johnthetubaguy yeah, that seemed nasty
16:38:44 mriedem i could see client side app tooling failing / timing out on that
16:38:46 mriedem like tempest even
16:38:57 mriedem lots of client code waits for an attachment to go to in-use before it considers it done
16:39:07 johnthetubaguy yes, good point
16:39:10 tssurya dansmith: Yes, that is what I am doing in my review, I was just trying to add the constraint part too
16:39:42 dansmith tssurya: sounds like we might not be able to do the constraint part.. since urls can't be large, I'm not sure converting it to something other than text is a good idea

Earlier   Later