Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-21
14:40:23 mriedem we have to go back up to the scheduler manager and retry by getting a fresh set of allocation candidates
14:40:38 mriedem until CONF.num_retries or whatever
14:40:52 leakypipes mriedem: well, we could also retry the same host if we get that specific error.
14:41:51 leakypipes mriedem: the issue is we'd need to put somehting into the claim_resources() report client method to distinguish between 409 Conflict for concurrent update and 409 Conflict for InvalidInventory (which is returned when the capacity was exceeded by another thread and thus the same claim request would fail)
14:41:54 mriedem i'm happy with that,
14:42:02 mriedem i just wasn't sure if we could do it
14:43:04 leakypipes mriedem: yup. gimme about an hour. I'll add a dependent patch before that one that adds the error condition distinguishing thing
14:43:14 leakypipes mriedem: and then mod the patch to retry same host on concurrent update
14:43:58 mriedem ack
14:46:41 figleaf leakypipes: I have a small but significant bug in https://review.openstack.org/#/c/483566/ as long as you're fixing the 409 claim conflict
14:47:36 figleaf leakypipes: Also, did we agree that the number of alternates would be based on CONF.scheduler.max_attempts?
14:47:49 leakypipes figleaf: yeah
14:47:54 figleaf ok
14:51:22 mriedem vdrok: https://review.openstack.org/#/c/419975/18..19/doc/source/support-matrix.ini ?
14:51:35 mriedem you dropped that in PS19
14:51:42 mriedem otherwise i'd +2
14:53:19 vdrok mriedem: stephenfin asked to move it to a separate change to avoid conflict with doc migration
14:54:04 vdrok mriedem https://review.openstack.org/486148
14:55:23 openstackgerrit Matt Riedemann proposed openstack/nova master: Implement interface attach/detach in ironic virt driver https://review.openstack.org/419975
14:55:42 mriedem vdrok: ack, +
14:55:43 mriedem +2
14:56:11 mriedem very simple +W for someone https://review.openstack.org/#/c/419975/
14:56:19 vdrok Thanks!
14:56:41 mriedem yw
14:58:16 melwitt mriedem: does that one imply we also need to update the hypervisor matrix?
14:58:40 mriedem melwitt: see ^
14:58:41 mriedem :)
14:58:47 mriedem https://review.openstack.org/486148
14:59:08 melwitt oh, heh
14:59:12 mriedem stephenfin, the kaiser of docs, asked to move it
14:59:31 melwitt brought down the hammer
14:59:59 stephenfin All Hail Stephen
15:00:13 stephenfin *too
15:00:42 mriedem only if markus_z is around
15:03:16 melwitt mriedem: I didn't notice this till now, but do you think "other" is the right place for this type of release note? or should it be under "upgrade"? https://review.openstack.org/#/c/386008/10/releasenotes/notes/quota-show-detail-access-d6f37282d288fa33.yaml
15:03:56 mriedem melwitt: sdague asked me about this exact same one earlier in the week :)
15:04:17 melwitt give me the scoop
15:04:21 mriedem if it were a new rule, other would be fine i think,
15:04:32 mriedem since it's changing the default for an existing rule, upgrade seems more appropriate
15:04:43 mriedem i think of it like config options
15:05:01 melwitt that's what I thought, I hadn't noticed it was "other" when I +2ed it. guess I'll change it and re +2
15:10:01 openstackgerrit melanie witt proposed openstack/nova master: Change default policy to view quota details https://review.openstack.org/386008
15:12:59 openstackgerrit Merged openstack/python-novaclient master: Updated from global requirements https://review.openstack.org/485950
15:46:24 mriedem ildikov: at some point we'll have to talk about the connection_info stuff going on in https://review.openstack.org/#/c/330285/ because i don't get it
15:46:31 mriedem did cinder regress that in the api
15:46:32 mriedem ?
15:46:53 mriedem i'm not sure why nova needs to stitch things back together
15:47:19 ildikov mriedem: the information that's coming back from Cinder in the new calls is everything in one dict
15:47:27 ildikov mriedem: so there's no nested dict anymore
15:47:42 ildikov mriedem: whatever was under the 'data' key is in connection_info
15:47:47 mriedem oh
15:47:54 ildikov mriedem: so we put back the 'data' key for now
15:47:56 mriedem ok we need to separate that out into a different change then
15:48:03 ildikov mriedem: too much effort to remove it...
15:48:11 ildikov mriedem: it's already separated out
15:48:29 mriedem where?
15:48:32 ildikov mriedem: I just try to fix the old flow tests in the attach patch before upload the extended chain
15:48:37 mriedem ah ok
15:48:49 mriedem ok yeah the amount of test change in that patch really scared me
15:48:53 ildikov mriedem: but I can upload where I am now if you want to take a look
15:49:01 mriedem finish up :)
15:49:07 mriedem i don't have time to dig into it again today probably
15:49:08 ildikov ok :)
15:49:36 ildikov I have functional tests failing, which is kinda interesting, but I will figure that out
15:49:42 ildikov unit tests are fine now
15:50:01 ildikov I will upload when it's fixed or when I gave up for today... :)
15:50:09 ildikov and then move on to the new tests
15:50:19 ildikov mriedem: do you have any preference for the new tests?
15:50:32 ildikov mriedem: like kinda duplicate what we have just with the new flow?
15:50:39 mriedem ildikov: that's probably what i'd do
15:50:52 mriedem the functional api sample tests don't need to change at all
15:50:53 ildikov mriedem: do we want less code lines or complete separation?
15:50:55 mriedem or shouldn't need to
15:51:02 mriedem i want separation
15:51:12 ildikov I have 15 tests failing...
15:51:22 mriedem mucking with the old tests (1) loses coverage on the old flow and (2) makes it much harder to review IMO
15:51:28 ildikov ok, I prefer that too, so at least we are on the same page
15:51:41 mriedem fwiw that's what i did in the swap volume new style attachments change
15:52:17 ildikov honestly I wanted to see tests working and deal with finalizing them when we are kinda fine with the code
15:52:22 ildikov maybe wasn't the best idea
15:52:37 ildikov still helped understanding a few things though, so oh well
15:52:47 ildikov next time I will do it differently... :)
15:53:36 ildikov mriedem: I think we're good with the direction, I will ping you if I get this up at a reasonable time today so at least you know it's there
15:54:26 mriedem https://bugs.launchpad.net/nova/+bug/1704293
15:54:28 mriedem blarg
15:54:28 openstack Launchpad bug 1704293 in OpenStack Compute (nova) "We can not set volume's type when creating a vm from image by creating a volume" [Undecided,Won't fix] - Assigned to liuxiuli (liu-lixiu)
16:00:50 jangutter mriedem: would something like this (create non-standard volume/port/etc and attach it to the created server) ever be covered by the osc CLI?
16:01:47 openstackgerrit Jay Pipes proposed openstack/nova master: claim resources in placement API during schedule() https://review.openstack.org/483566
16:01:48 openstackgerrit Jay Pipes proposed openstack/nova master: placement: add retry tight loop claim_resources() https://review.openstack.org/486170
16:01:49 mriedem jangutter: that's the way you do it today
16:01:51 leakypipes mriedem: ^
16:01:55 mriedem which was my response in the bug report
16:02:17 leakypipes mriedem: I ended up hiding the tight retry loop in the scheduler report client's claim_resources() method.
16:02:27 leakypipes mriedem: so no changes needed to the scheduler patch.
16:02:31 mriedem leakypipes: sneaky sis
16:02:40 leakypipes mriedem_afk: :)
16:02:49 jangutter mriedem: argh, sorry, my verbage unclear... I meant, doing that in "one go"
16:03:08 jangutter mriedem: I think that's not just a can of worms, but a can of worm factory.
16:03:33 melwitt leakypipes: question for you, if this sort is to get non-shared resources first, does that mean "sharing_providers" has non-shared resources in it? https://review.openstack.org/#/c/485088/6/nova/objects/resource_provider.py@1060
16:04:47 melwitt just confused about what's going on there. and how does sorting them make non-shared be first?

Earlier   Later