| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-30 | |||
| 19:35:19 | dansmith | mriedem: I got it | |
| 19:35:25 | mriedem | thanks | |
| 19:35:27 | dansmith | sorry I wasn't paying attention to that | |
| 19:36:12 | openstackgerrit | Matt Riedemann proposed openstack/nova master: DNM: Run test_volume_backed_live_migration and iscsi test https://review.openstack.org/508163 | |
| 19:38:49 | jaypipes | efried: yeah, prolly. | |
| 19:39:01 | efried | jaypipes ight. | |
| 19:39:02 | jaypipes | efried: you can put it in nova/api/openstack/placement/ | |
| 19:39:06 | efried | ack | |
| 19:39:18 | jaypipes | efried: and the other in /nova/scheduler/ somewhere | |
| 19:39:28 | efried | jaypipes It's in utils at the moment, will leave it there. | |
| 19:39:31 | jaypipes | efried: should just be a POD object (plain ol' data) | |
| 19:39:37 | jaypipes | efried: sure, that's cool | |
| 19:39:38 | efried | yuh | |
| 19:40:06 | sdague | mriedem: is ceph going to eventually work on the super conductor stuff? | |
| 19:40:24 | mriedem | sdague: the problem isn't superconductor + ceph, | |
| 19:40:24 | sdague | oh, I guess the issue is grenade doesn't do that yet | |
| 19:40:27 | mriedem | the problem there is grenade | |
| 19:40:29 | mriedem | yup | |
| 19:41:12 | mriedem | sdague: which i half heartedly posted https://review.openstack.org/#/c/509803/ just to see how bad things blew up | |
| 19:41:17 | mriedem | but didn't really dig into it | |
| 19:41:35 | mriedem | appears to be a discover_hosts issue | |
| 19:41:49 | mriedem | http://logs.openstack.org/03/509803/1/check/gate-grenade-dsvm-neutron-ubuntu-xenial/d8414a5/logs/grenade.sh.txt.gz | |
| 19:44:07 | mriedem | yeah the configs don't get set properly, because e.g. nova-cpu.conf has api_database stuff in it http://logs.openstack.org/03/509803/1/check/gate-grenade-dsvm-neutron-ubuntu-xenial/d8414a5/logs/etc/nova/nova-cpu.conf.txt.gz | |
| 19:46:32 | openstackgerrit | Merged openstack/nova master: Pass the correct image to build_request_spec in conductor.rebuild_instance https://review.openstack.org/515530 | |
| 19:52:04 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: add nested resource providers https://review.openstack.org/377138 | |
| 19:52:05 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: allow filter providers in tree https://review.openstack.org/377215 | |
| 19:52:05 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: adds REST API for nested providers https://review.openstack.org/384807 | |
| 19:52:06 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: update client to set parent provider https://review.openstack.org/385693 | |
| 19:52:36 | jaypipes | cdent: turned out that you identified some useless code that should be removed. so I did. ^ | |
| 20:02:07 | sdague | mriedem: yeh, let me try a thing with that | |
| 20:02:49 | cdent | jaypipes: yay less code! | |
| 20:08:36 | cfriesen | when live-migrating with block-migration = "auto", does anyone know offhand where we do the check to see if block migration is needed or not? | |
| 20:10:51 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Add _get_providers_with_any_resource method https://review.openstack.org/514197 | |
| 20:10:51 | openstackgerrit | Eric Fried proposed openstack/nova master: _get_usages_by_provider_and_rc not filter on RC ID https://review.openstack.org/514649 | |
| 20:10:52 | openstackgerrit | Eric Fried proposed openstack/nova master: Add _get_traits_by_rp_ids method https://review.openstack.org/511184 | |
| 20:10:52 | openstackgerrit | Eric Fried proposed openstack/nova master: Add ProviderSummaryList object https://review.openstack.org/514198 | |
| 20:10:53 | openstackgerrit | Eric Fried proposed openstack/nova master: More caches: ProviderSummary, ProviderSummaryList https://review.openstack.org/514199 | |
| 20:10:53 | openstackgerrit | Eric Fried proposed openstack/nova master: Add AggregatedProviderSummary[List] objects https://review.openstack.org/514200 | |
| 20:10:54 | openstackgerrit | Eric Fried proposed openstack/nova master: Add has_resources to AggregatedProviderSummary https://review.openstack.org/514650 | |
| 20:10:54 | openstackgerrit | Eric Fried proposed openstack/nova master: AggregatedProvierSummary.as_allocation_request_obj https://review.openstack.org/514651 | |
| 20:10:55 | openstackgerrit | Eric Fried proposed openstack/nova master: placement: rewrite AllocationCandidates.get_by_filters https://review.openstack.org/479766 | |
| 20:10:58 | efried | jaypipes In other news, if you have some time to look at this WIP patch ^ there's either a SQL bug or a test case bug. | |
| 20:11:14 | efried | jaypipes This one: https://review.openstack.org/514197 | |
| 20:11:54 | jaypipes | efried: wasn't that alex_xu's? | |
| 20:12:05 | efried | jaypipes alex_xu and I have been pair programming it. | |
| 20:12:11 | jaypipes | cfriesen: mriedem would know best. | |
| 20:12:18 | jaypipes | efried: k. | |
| 20:12:47 | mriedem | ummm | |
| 20:12:53 | efried | jaypipes Gah, pair "developing", per edleafe | |
| 20:12:59 | efried | which is different. | |
| 20:13:05 | mriedem | cfriesen: you're going to have to check the code | |
| 20:13:49 | jaypipes | mriedem: you're all about that flag. | |
| 20:14:37 | cfriesen | jaypipes: mriedem: heh...I think I found it. git history is my friend | |
| 20:14:59 | cfriesen | efried: someone's developing a pair? | |
| 20:16:20 | efried | cfriesen It's a slow process. But actually more efficient than one at a time. | |
| 20:17:09 | openstackgerrit | Matt Riedemann proposed openstack/nova master: api-ref: document caveats with scheduler hints https://review.openstack.org/516442 | |
| 20:17:13 | mriedem | sdague: how is this for documented ambiguity? :) ^ | |
| 20:18:02 | sdague | mriedem: yeh, pretty much | |
| 20:18:10 | mriedem | mordred: do you ever have to rely on scheduler hints? | |
| 20:19:26 | clarkb | mriedem: I think any of that would be largely transparent to infra at least since we are just "public" cloud ocnsumers for the most part. and since infracloud is single tenant we don't need any special scheduling we just schedule to any of our nodes | |
| 20:20:40 | mriedem | clarkb: ok. i just figure anyone that is a user of openstack and has to rely on scheduler hints for their app to work, probably has a hell of a time making that app work across different clouds - but i have no idea if something like that exists in the wild | |
| 20:21:16 | clarkb | I know ovh schedules us to dedicate resources so we don't noisy neighbor their customers | |
| 20:21:25 | clarkb | they do this with a flavor just for us not sure if that involves scheduler hints | |
| 20:21:32 | clarkb | but ya we don't directly interact with scheduler hints at least | |
| 20:21:54 | mriedem | clarkb: yeah that wouldn't be scheduler hints, just extra specs and host aggregates | |
| 20:22:25 | openstackgerrit | Eric Fried proposed openstack/nova master: Parse granular resources/traits from extra_specs https://review.openstack.org/515151 | |
| 20:22:25 | openstackgerrit | Eric Fried proposed openstack/nova master: Granularize resources_from_{flavor|request_spec} https://review.openstack.org/515223 | |
| 20:22:26 | openstackgerrit | Eric Fried proposed openstack/nova master: ResourceRequest.to_querystring() https://review.openstack.org/515811 | |
| 20:23:26 | mriedem | i need to know if cloud x has a scheduler hint so i can tell it which lpar i want my powervm instance on | |
| 20:23:32 | mriedem | because lpar 44 is the one i want | |
| 20:26:41 | jaypipes | mriedem: and how would a cloud user know that lpar 44 is the one they want? :) | |
| 20:27:45 | sdague | jaypipes: probably the same way they'd know which az they wanted, it was documented somewhere. | |
| 20:28:28 | jaypipes | sdague: heh | |
| 20:29:10 | jaypipes | sdague: my point is that the AZ is a publicly-visible grouping construct that OpenStack exposes. LPARs are not publicly-visible constructs... | |
| 20:30:05 | jaypipes | sdague: in the same sense that on AWS I cannot request a particular compute host (because, well, as a cloud user, I don't *know* what the compute hosts are...) | |
| 20:30:48 | jaypipes | sdague: but maybe you're just pulling my leg... I can't tell :) | |
| 20:31:38 | mriedem | i'm just using a ridiculous example | |
| 20:32:11 | mriedem | but yeah, just saying, one cloud/product docs could have any number of weird things tailored for their users | |
| 20:34:33 | mriedem | if we actually cared, we'd have some kind of scheduler_hints API to return what *this* cloud supports for scheduler hints, so it would at least be discoverable | |
| 20:35:12 | jaypipes | mriedem: sure, agreed. discoverable, not interoperable... | |
| 20:35:25 | mriedem | right, neither are flavors | |
| 20:35:32 | jaypipes | mriedem: ack | |
| 20:35:53 | jaypipes | mriedem: but standard resource classes and os-traits are getting us much closer in that respect. | |
| 20:44:56 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Transform keypair.import notification https://review.openstack.org/467514 | |
| 21:00:33 | mriedem | this is fun, http://logs.openstack.org/96/516396/1/check/legacy-tempest-dsvm-py35/ecb9db4/logs/screen-n-api.txt.gz#_Oct_30_18_01_18_122380 | |
| 21:00:41 | mriedem | can't find that request in the scheduler logs to see why NoValidHost | |
| 21:04:29 | mriedem | ah because we overwrite the NoValidHost message before returning to the api | |
| 21:04:34 | mriedem | dansmith: http://logs.openstack.org/96/516396/1/check/legacy-tempest-dsvm-py35/ecb9db4/logs/screen-n-super-cond.txt.gz?level=TRACE#_Oct_30_18_01_18_003148 | |
| 21:05:44 | mriedem | (409 {"errors": [{"status": 409, "request_id": "req-7eec8dd2-f65c-43fa-b3df-cdf7a236aa03", "title": "Conflict", "detail": "There was a conflict when trying to complete your request.\n\n Inventory changed while attempting to allocate: Another thread concurrently updated the data. Please retry your update "}]}) | |
| 21:17:05 | mriedem | e-r seems to be dead so can't tell how bad this is http://status.openstack.org/elastic-recheck/ | |
| 21:21:59 | mriedem | https://bugs.launchpad.net/nova/+bug/1728722 | |
| 21:22:01 | openstack | Launchpad bug 1728722 in OpenStack Compute (nova) "Resize test fails in conductor during migration/instance allocation swap: "Unable to replace resource claim on source host"" [High,New] | |
| 21:22:30 | mriedem | ok, so what's probably happening is conductor is trying to 'claim' allocations in placement at the same time as the scheduler for a concurrent test, and capacity changed so we have to retry client-side, just like in the scheduler | |
| 21:25:13 | openstackgerrit | Merged openstack/nova master: rp: break functions out of _set_traits() https://review.openstack.org/509908 | |
| 21:25:41 | openstackgerrit | Merged openstack/nova master: Fix live migration grenade ceph setup https://review.openstack.org/508271 | |
| 21:25:49 | openstackgerrit | Merged openstack/nova master: Transform instance.trigger_crash_dump notification https://review.openstack.org/396225 | |
| 21:30:59 | cfriesen | mriedem: is there a bug for the fact that rebuilding a boot-from-volume instance changes the reported image without changing the volume contents? Or are we just tracking that under https://bugs.launchpad.net/nova/+bug/1482040 ? | |
| 21:31:00 | openstack | Launchpad bug 1482040 in OpenStack Compute (nova) "rebuild volume-backed instance with image does not replace image in root disk" [Undecided,Confirmed] | |
| 21:31:29 | mriedem | just tracking that under that bug | |
| 21:32:46 | cfriesen | is there any concensus on how to handle that? if not, should we bring it up at the Forum? | |