Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-07-21
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 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)
15:54:28 mriedem blarg
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?
16:06:45 melwitt cdent ^
16:07:36 cdent melwitt: the name of the variable might be misleading
16:09:30 cdent melwitt: just a sec I’ll refresh my memory
16:10:38 cdent melwitt: the value in the dictionary is the id of a provider of that resource class that makes it available via sharing
16:10:43 melwitt it looks like sharing_providers is a dict where the key is resource class ID and each value is a list of resource provider IDs?
16:11:00 cdent of it items() is sorted by the value, then anything provider which is not one that shares comes first
16:12:03 melwitt non sharing providers always have lower IDs?
16:14:08 cdent no, the value will be None if it a non sharing provider
16:14:31 melwitt okay, so the Nones get sorted ahead of the lists of IDs
16:15:37 cdent yeah
16:15:45 cdent and it’s not none, sorry it’s an empty list
16:15:54 cdent it’s hard to track :(
16:16:19 melwitt okay, thanks. now this makes a lot more sense
16:29:43 cdent leakypipes: can you clarify your comment on https://review.openstack.org/#/c/485209/2/nova/tests/functional/api/openstack/placement/gabbits/shared-resources.yaml . Are you saying it should be 1 provider or something else? It currently returns 0, which doesn’t align with what you seem to be saying
16:31:31 leakypipes cdent: it's currently returning 1, which is correct.
16:31:40 leakypipes cdent: $.resource_providers.`len`: 1
16:32:29 cdent it is not returning 1, that’s why the xfail: true is there
16:33:03 cdent eXpected fail
16:35:13 leakypipes cdent: oh, sorry
16:36:11 leakypipes cdent: didn't catch the xfail thing
16:36:21 leakypipes cdent: I can investigate that then.
16:36:51 cdent i’ve got a better version of the test, will push it up without the xfail
16:37:39 cdent leakypipes: I can do it if you like, now that I know what the correct thing is I should be able to some reasonable poking
16:37:53 leakypipes cdent: sure, please do if you'd like
16:38:00 cdent ✔

Earlier   Later