| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-23 | |||
| 14:05:51 | ildikov | Miracles exist when we have amazing and dedicated people to make them happen. :) | |
| 14:06:00 | gibi | ildikov: \o/ | |
| 14:06:02 | rgerganov | efried_back_wed, no luck trying to register a nested RP with the provider_tree | |
| 14:06:12 | ildikov | gibi: :) | |
| 14:07:00 | efried_back_wed | rgerganov Okay; leave some words on the patch, or send me an email, and I can dig in some more tomorrow (or maybe for a few minutes tonight) | |
| 14:07:33 | rgerganov | efried_back_wed, sure, I am digging into this right now, will post all findings that I have at the end of the day | |
| 14:07:48 | efried_back_wed | rgerganov ++ | |
| 14:08:11 | openstackgerrit | Radoslav Gerganov proposed openstack/nova master: WIP: VMware: implement update_provider_tree() https://review.openstack.org/536348 | |
| 14:09:01 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Avoid suspending guest with attached vGPUs https://review.openstack.org/535693 | |
| 14:10:44 | mriedem | andreykurilin: can you take a look at the novaclient change to support 2.59 https://review.openstack.org/#/c/516168/ and the small patch after it for 2.60? | |
| 14:11:11 | andreykurilin | looking | |
| 14:12:56 | cdent | rgerganov: is your code that's not working viewable somewhere? | |
| 14:13:13 | rgerganov | cdent: https://review.openstack.org/#/c/536348/3 | |
| 14:13:16 | cdent | oh never mind, actually read the log | |
| 14:13:18 | cdent | thanks | |
| 14:14:24 | mriedem | avolkov: i had some questions in the osc-placement patch for aggregates, which is the first one to add microversion support https://review.openstack.org/#/c/505643/ | |
| 14:14:41 | mriedem | avolkov: i'm not sure how to expose in the help output that --os-placement-api-version 1.1 needs to be used | |
| 14:14:52 | mriedem | besides just adding it directly into the help | |
| 14:18:21 | Roamer` | mriedem, sorry if I'm starting to annoy you, I guess you didn't have time yesterday to take a look at 140733 - the StorPool driver? It's just that it seems that there might not be much time for us to make changes if something should appear to be not quite right... and yes, I do realize that you have a lot to look at, and an exception for a new driver is kind of low priority, I know | |
| 14:19:48 | jroll | mriedem: you didn't secretly fix the segfault thing yesterday, did you? seems to be passing now. | |
| 14:21:56 | openstackgerrit | Alex Xu proposed openstack/nova master: placement: enable required traits from the flavor extra specs https://review.openstack.org/536085 | |
| 14:22:11 | cdent | rgerganov: two things: a) what kind of error are you getting with regard to "no luck", b) if you're putting some vcpus (and other inventory classes) in resource pools child providers, then they can't also be in the parent. it appears that's what your code is currently doing? | |
| 14:22:22 | alex_xu | gibi: I added the release note, thanks for the review | |
| 14:22:46 | alex_xu | bauzas: efried_back_wed I will address the nits tommorow, thanks for the review | |
| 14:22:59 | alex_xu | gibi: also the functional test! | |
| 14:23:24 | gibi | alex_xu: I'm totally OK to have the functional test in a separate followup | |
| 14:23:55 | rgerganov | cdent, you mean that we can't have VCPU in both parent and childs? | |
| 14:23:57 | mriedem | jroll: nope | |
| 14:24:23 | alex_xu | gibi: thanks, will try to submit a separate followup tomorrow | |
| 14:24:24 | jroll | yay | |
| 14:24:48 | cdent | rgerganov: it can be in both places, but they cannot overlap. Any inventory of the same type associated with the child provider needs to be subtracted from the parent. | |
| 14:25:03 | mriedem | Roamer`: i still have the tab open | |
| 14:25:13 | rgerganov | cdent, this is not the problem that I have now | |
| 14:25:30 | rgerganov | cdent, when you start nova-compute udpate_provider_tree is being called twice | |
| 14:25:37 | cdent | rgerganov: yeah, I get that, was just noting it for future reference | |
| 14:26:03 | cdent | first in init and then in the periodic job? | |
| 14:26:54 | rgerganov | cdent, both calls come from _update_available_resource in the RT | |
| 14:28:08 | rgerganov | cdent, on the first call the provider tree seems to be correct and both parent and child RP are updated in placement | |
| 14:28:23 | rgerganov | cdent, on the second call I get 409 from placement | |
| 14:28:31 | gibi | alex_xu: I'm +2 on the last patch too, thanks for the reno | |
| 14:28:41 | alex_xu | gibi: thanks for the review! | |
| 14:29:15 | rgerganov | cdent, because it tries to create the nested RP again | |
| 14:29:36 | cdent | rgerganov: how close together are those jobs, by timestamp? | |
| 14:30:19 | rgerganov | cdent, they are far away because I am tracing the code | |
| 14:30:39 | rgerganov | cdent, like couple of seconds away | |
| 14:30:56 | cdent | It seems like the provider tree isn't getting a chance to update its cache of the rp generation | |
| 14:31:05 | rgerganov | cdent, correct | |
| 14:31:35 | cdent | It behaves the same way with the debugger not involved? | |
| 14:31:43 | rgerganov | yes | |
| 14:32:07 | rgerganov | on the first call the provider tree has both parent and child and the call to placement succeds | |
| 14:32:53 | rgerganov | on the second call it has only the parent and when the driver adds the child and placement is called, we get 409 | |
| 14:34:44 | cdent | rgerganov: and the message with the 409 is what? | |
| 14:35:24 | rgerganov | cdent, Failed to create resource provider record in placement API for UUID 4be176f1-b09f-48dd-82d7-d9c1c86fb68b. Got 409: {"errors": [{"status": 409, "request_id": "req-69d31b34-bc50-4178-a569-ebaef4734cbd", "detail": "There was a conflict when trying to complete your request.\n\n Conflicting resource provider name: vdc already exists. ", "title": "Conflict"}]}. | |
| 14:37:00 | cdent | rgerganov: thanks, looking at the calling code now | |
| 14:44:47 | edmondsw | gibi tx for reviewing the powervm SEA patch! Are you planning to look at the powervm vscsi patch as well? | |
| 14:45:02 | openstackgerrit | Jackie Truong proposed openstack/nova master: Add trusted_certs object https://review.openstack.org/489408 | |
| 14:45:02 | cdent | rgerganov: on the second request, when the provider tree doesnt have the child, have you traced what's happening in _ensure_resource_provider. It seems like in there is where it could be going awry and not creating a full tree | |
| 14:46:05 | gibi | edmondsw: I cannot promise that it will fit before the feature freeze | |
| 14:47:19 | edmondsw | gibi ok. If you get to it, thanks. If not, maybe someone else will | |
| 14:48:55 | gibi | edmondsw: please ping me daily, that will help me not to forget | |
| 14:49:28 | edmondsw | gibi you asked for it... ;) | |
| 14:49:34 | edmondsw | thanks | |
| 14:50:55 | edmondsw | stephenfin do you also want daily reminders? ;) | |
| 14:50:58 | gibi | :) | |
| 14:51:22 | stephenfin | edmondsw: Nope, it'll be done :) | |
| 14:51:33 | openstack | bugzilla.redhat.com bug 1534669 in openstack-nova "emulator_threads_policy needs improvement when hyper threading is enabled" [Medium,New] - Assigned to sfinucan | |
| 14:51:43 | edmondsw | stephenfin thanks! | |
| 14:51:56 | rgerganov | cdent, correct, this method doesn't fetch the full tree on the second call | |
| 14:52:13 | rgerganov | cdent, self._refresh_associations doesn't do what we expect | |
| 14:58:34 | edmondsw | bauzas johnthetubaguy any chance you could look at https://review.openstack.org/#/c/526094/ adding powervm cinder volume support? | |
| 15:02:31 | openstackgerrit | Jackie Truong proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204 | |
| 15:03:43 | mriedem | melwitt: want to hit this 3 LOC patch for 2.60 support in novaclient? https://review.openstack.org/#/c/536621/ | |
| 15:09:45 | melwitt | mriedem: got it | |
| 15:09:47 | bauzas | mriedem: I can look | |
| 15:09:54 | bauzas | heh, snap | |
| 15:10:12 | mriedem | thanks, that'll likely be it for queens | |
| 15:14:39 | openstackgerrit | Matt Riedemann proposed openstack/osc-placement master: Usage docs and initial release note for osc-placement https://review.openstack.org/536858 | |
| 15:16:39 | openstackgerrit | int32bit proposed openstack/nova master: Set server status to ERROR if rebuild failed https://review.openstack.org/536268 | |
| 15:22:14 | openstackgerrit | Jackie Truong proposed openstack/python-novaclient master: Microversion 2.61 - Add trusted_image_certificates https://review.openstack.org/500396 | |
| 15:25:50 | alex_xu | mriedem: in case you have time https://review.openstack.org/#/q/topic:bp/request-traits-in-nova+(status:open+OR+status:merged), I have last two patches waiting for one more +2, appreciate if you can help it | |
| 15:27:56 | mriedem | alex_xu: ok, also looks like https://review.openstack.org/#/c/536083/4/nova/scheduler/client/report.py overlaps with something dansmith was working on | |
| 15:28:05 | mriedem | to use the 1.12 allocation candidates format for the move operations in the report client | |
| 15:29:40 | dansmith | mriedem: I think that patch just has two remaining failures to look at but I've been kinda absorbed with other things lately | |
| 15:31:43 | melwitt | mriedem: on the set status to ERROR upon rebuild failure patch, do you think it would be worth adding a fault message to the instance along with the ERROR state? I was thinking since the instance is sitting with the wrong imageref, it might be helpful to give some guidance in the fault message in case someone doesn't know how to recover https://review.openstack.org/#/c/536268/ | |
| 15:32:50 | sean-k-mooney | stephenfin: for the record that refactor is annoying. i have all but 1 test passing now howerver the pci request spec object has like 8 required field not just the 4 in the alias schema definition | |
| 15:32:54 | mriedem | yeah a fault is probably necessary, i thought we'd have one on there but apparently we only use wrap_instance_fault in the compute manager | |
| 15:33:14 | stephenfin | sean-k-mooney: Really? What are the other ones? | |
| 15:33:48 | dansmith | melwitt: so can you push up a change to add a fault so we can get moving on that? | |
| 15:34:07 | sean-k-mooney | stephenfin: http://paste.openstack.org/show/650978/ | |
| 15:34:26 | melwitt | dansmith: yep, let me do that | |
| 15:34:44 | sean-k-mooney | stephenfin: the commented out ones should be deleted | |
| 15:35:20 | dansmith | melwitt: cool | |
| 15:35:48 | sean-k-mooney | stephenfin: also i found that some test use device_id instead of product id so i have to support both and while the alias uses device_type the db uses dev_type so i have to convert when i create the spec | |
| 15:37:00 | stephenfin | sean-k-mooney: You can probably drop capability_type | |
| 15:37:06 | sean-k-mooney | stephenfin: anyway when i get the last test passing ill push up the new revision. | |
| 15:37:12 | stephenfin | Per my comment in nova/pci/request.py | |
| 15:37:40 | stephenfin | But otherwise, yeah, I figured it wouldn't be super easy but it is a much better design long-term, IMO | |
| 15:37:44 | sean-k-mooney | stephenfin: nope you will get an invalid key exception unless i specificlally add code to drop it | |
| 15:38:12 | stephenfin | sean-k-mooney: I'm working through the CPU pinning code again. Every time I go through this, I have to relearn it | |
| 15:38:34 | stephenfin | sean-k-mooney: But nothing except tests use it | |