Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-04-28
16:19:03 cfriesen sfinucan: you still around?
16:19:15 sfinucan cfriesen: For another 5 mins, yup
16:19:19 sfinucan what's up?
16:20:11 cfriesen sfinucan: looking at _add_cpu_pinning_constraint() I don't think the code matches the docs for the case where flavor_thread_policy is "prefer" and image_thread_policy is "isolate"
16:20:36 cfriesen sfinucan: the way it's supposed to work is that if the flavor is "prefer" or not set then the image can set whatever it wants
16:20:55 sfinucan cfriesen: I think it's the other way round, no?
16:21:02 sfinucan image takes priority
16:21:09 cfriesen https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/virt-driver-cpu-thread-pinning.html
16:21:12 sfinucan i.e. image unset = set the flavor
16:21:14 cfriesen flavor takes priority
16:21:34 cfriesen from the link "This will only be honored if the flavor specifies the ‘prefer’ policy, either explicitly or implicitly as the defalt option. This ensures that the cloud administrator can have absolute control over threads policy if desired."
16:22:37 sfinucan cfriesen: Ah
16:22:50 sfinucan so the actual admin guide docs agree with the code https://docs.openstack.org/admin-guide/compute-cpu-topologies.html
16:22:59 sfinucan "Image metadata takes precedence over flavor extra specs."
16:23:15 sfinucan which means the spec needs to be updated
16:24:04 sfinucan cfriesen: Is there any reason image metadata shouldn't take priority?
16:25:27 cfriesen sfinucan: then the docs are wrong. look at the code in _add_cpu_pinning_constraint() for the cpu_policy. if the flavor says it's dedicated, then it's dedicated and we don't even look at the image
16:26:20 cfriesen historically the flavor took priority since it was set by the admin. If the admin didn't set it in the flavor, then the image was allowed to set it
16:26:38 cfriesen and if the flavor set it to shared the image was allowed to set it to shared
16:27:04 dane-fichter dansmith: I'm working on trying to modify the Instance object and I can't figure out the unit test failures
16:27:13 dane-fichter dansmith: do you have a sec?
16:27:42 dansmith dane-fichter: I'm drugged up and snot-filled, but I can try
16:28:24 sfinucan cfriesen: Aye. I was looking at 'cpu_thread_policy' for a bit there
16:28:37 sfinucan damn. So both docs need to be fixed, I guess
16:29:04 sfinucan cfriesen: I've to grab a lift home, but could you file a bug and I'll take a look later or on Monday?
16:29:15 dane-fichter dansmith: ok so here's the unit test failures: http://logs.openstack.org/11/457711/2/check/gate-nova-python27-ubuntu-xenial/7429f62/console.html#_2017-04-25_21_51_45_406244
16:29:18 cfriesen sfinucan: can do
16:29:23 sfinucan I'm guessing we need to fix the docs because we can't break existing deployments
16:29:33 sfinucan At least, not without a cycle of warnings
16:29:44 dane-fichter dansmith: it kinda looks like the "new" instance version isn't being added to the versioned objects registry?
16:29:46 cfriesen sfinucan: we changed the code behaviour for the thread policy from Mitaka to Newton
16:29:58 sfinucan cfriesen: On purpose?
16:30:10 cfriesen sfinucan: nope. looks like an accident
16:30:21 sfinucan cfriesen: lovely
16:30:30 cfriesen in mitaka if the flavor policy was "prefer" we would use the image thread policy
16:31:00 cfriesen in newton if the flavor policy is "prefer" we'll use "prefer", if the flavor policy is "none" we'll use the image thread policy
16:31:45 cfriesen correction, in mitaka if the flavor policy was "none" or "prefer" we would use the image thread policy
16:31:49 sfinucan damn. That was my '_get_flavor_image_meta' centralization patch, I bet
16:32:26 sfinucan OK, stick that in the report too. I don't know what we'll be able to do about it (is it a bug or a feature now?) but there should probably an errata reno added at least
16:32:34 dansmith dane-fichter: that's kinda weird looking
16:32:47 cfriesen sfinucan: looks like it was ndipanov actually
16:32:56 cfriesen will write it up
16:32:58 dane-fichter dansmith: yeah I haven't been able to figure it out
16:33:27 dane-fichter dansmith: I thought maybe the new version of Instance isn't added to the versioned objects registry
16:33:57 dane-fichter dansmith: here's the patch btw https://review.openstack.org/#/c/457711/2
16:34:11 dansmith dane-fichter: well, that isn't really a thing, but agree that it seems to be something up with the manifest and the instance object
16:34:13 dansmith yeah, looking at ti
16:36:30 dansmith dane-fichter: gimme a few
16:36:36 dansmith dane-fichter: sorry if I get snot on your patch
16:36:49 dane-fichter dansmith: lol it's quite all right
16:36:57 dane-fichter dansmith: thanks for helping
16:37:05 dansmith well, I haven't helped yet
16:37:16 dansmith I might just hand you back a snotty still-broken patch
16:41:00 dansmith dane-fichter: it's failing to look up your new object
16:41:07 dansmith not instance
16:41:42 dane-fichter dansmith: hmm ok. do I need to register it with something besides the nova object registry?
16:41:49 dansmith oh I see why
16:42:09 dansmith because you just inherited from the persistent mixin, not the base NovaObject
16:42:12 dansmith so it's not being registered
16:46:04 dane-fichter dansmith: hmm I tried inheiriting from base.NovaObject and that's still failing
16:46:10 dansmith dane-fichter: left some other comments in there
16:46:26 dansmith dane-fichter: unless you're planning to add a lot more to this, I think we can probably reduce this to something way less expensive
16:47:08 dane-fichter dansmith: less expensive in terms of space?
16:47:27 dansmith dane-fichter: space, complexity, brain power, characters, columns, etc :)
16:47:41 dane-fichter dansmith: I suppose it could just be a list of UUIDs
16:47:46 dansmith yar :)
16:47:54 dane-fichter we don't really need all this fluff
16:49:08 dansmith dane-fichter: I think you're also missing an import in objects/__init__.py to cause it to get defined at all maybe?
16:49:17 dansmith anyway, I think it likely doesn't need to be an object
16:49:23 dansmith certainly not two levels of them
16:49:27 dane-fichter dansmith: yup that's gotta be it
17:02:30 openstack bug 1687067 in OpenStack Compute (nova) "problems with cpu and cpu-thread policy where flavor/image specify different settings" [Undecided,New] https://launchpad.net/bugs/1687067
17:02:30 cfriesen I just reported bug 1687067. sfinucan will look at it monday, but it's kind of messy. The behaviour changed from Mitaka to Newton, and the current behaviour doesn't match the Mitaka spec anymore. Do we codify the mismatch or go back and fix the code?
17:13:17 openstackgerrit Samantha Blanco proposed openstack/nova master: Deprecate flavor-rxtx policy https://review.openstack.org/444036
17:24:57 cfriesen wow...openstack-manuals is all wrong about what happens when images and flavors specify the same options.
17:27:24 cfriesen is it possible to explicity specify a flavor extra spec value of None?
17:40:53 cfriesen If anyone wants to review some docs, I just proposed https://review.openstack.org/461110 to align the docs with the current nova codebase.
17:56:59 oomichi dansmith: hi, can we get your feedback on https://review.openstack.org/#/c/408955/ ? That is long-living one on our queue, and takashin needs your help
18:28:41 openstackgerrit Rafael Folco proposed openstack/nova master: Delete inventory has its own method DELETE https://review.openstack.org/460147
18:38:52 openstackgerrit Steve Noyes proposed openstack/nova master: Add Cinder v3 detach to shutdown_instance https://review.openstack.org/456877
18:48:36 openstackgerrit christopher.uhler proposed openstack/nova master: Libvirt volume driver for Veritas HyperScale https://review.openstack.org/443951
18:56:58 openstackgerrit christopher.uhler proposed openstack/nova master: Libvirt volume driver for Veritas HyperScale https://review.openstack.org/443951
19:26:16 bsilverman o/
19:27:36 bsilverman does anyone have the bug number for the issue of nova-scheduler not checking pCPU fitting logic when migrating a NUMA pinned instance?
19:27:57 bsilverman I can't seem to find it, I must be searching the wrong terms or something.
19:40:47 mtreinish mriedem: so is that big ml thread where mordred is writing walls of text and I'm keeping away from about using the catalog for the glance endpoint?
19:40:58 mtreinish because I want to do that, it'll make my life easier for the glance wsgi transition
19:41:14 openstackgerrit Matt Riedemann proposed openstack/nova master: Remove compatibility code for flavors https://review.openstack.org/460377
19:41:14 openstackgerrit Matt Riedemann proposed openstack/nova master: Don't lazy-load flavor.projects during destroy() https://review.openstack.org/461032
19:41:25 mriedem mtreinish: glance wsgi transition?
19:41:28 mriedem in devstack?
19:41:44 mtreinish mriedem: the cross project goal of getting everything deployed as a wsgi app
19:41:46 mriedem mtreinish: we're going to make nova use the service catalog by default
19:42:00 mtreinish ok cool
19:42:10 mriedem the debate is about leaving a backdoor for ops to use the existing CONF.glance.api_servers super awesome load balancer
19:42:19 mtreinish https://review.openstack.org/#/c/459451/ is failing because nova doesn't know about the new glance endpoint url
19:42:20 mriedem i haven't read anything past this morning though
19:42:55 mtreinish ok
19:49:32 openstackgerrit dane-fichter proposed openstack/nova master: Add trusted certificates to InstanceExtras https://review.openstack.org/457711
19:51:49 mordred mriedem, mtreinish: tl;dr operators like the new ability to just get it from the catalog - but would like to not have glance_api_servers removed because for some number of them what it does provide is good enough

Earlier   Later