| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-05 | |||
| 17:56:07 | openstack | Launchpad bug 1717915 in oslo.messaging "nova services and transport_url, cannot connect to vhost if specified" [Undecided,New] | |
| 17:56:07 | melwitt | owalsh: do you know if/how things got resolved here? https://bugs.launchpad.net/nova/+bug/1717915 | |
| 17:57:01 | jaypipes | after a certain point, I just don't feel like doing any reviews -- or at least don't feel like leaving any *positive* reviews. seems like we go out of our way sometimes to -1 for things that just aren't particularly important. | |
| 17:58:34 | jaypipes | efried: speaking of negative reviews... what is the current status on the whole "use case" around granular request groups *not* meaning that the resource providers will be different for each group? | |
| 17:59:57 | arvindn051 | jaypipes: just taking it as constructive criticism...you guys have been at this a lot more than i have :) | |
| 18:00:36 | efried | jaypipes: I recently wrote up a decent synopsis in a spec review. Finding... | |
| 18:00:39 | arvindn051 | i am sure there are more edge cases...but if we want to guard against known one by adding few lines of code...should be fine | |
| 18:01:23 | jaypipes | scenario described for this test case.") | |
| 18:01:23 | jaypipes | efried: since I "solved" that "use case" with the whole "sum the inventories for like resource classes for a tree" and that was -1'd by you (https://review.openstack.org/#/c/534339/) because it would not make sense ("No, I think that, under the current design, if you want two VFs, you should specify them in separate granular request groups, even if they're identical, so that you'll still get a viable candidate in the | |
| 18:02:34 | efried | jaypipes: https://review.openstack.org/#/c/555081/4/specs/rocky/approved/cpu-resources.rst@412 while I go read that... | |
| 18:02:39 | jaypipes | arvindn051: I'm referring to my own frustration... not even considering whether you may or may not be frustrated by the constant back and forth (I would be if I were you) | |
| 18:03:18 | jaypipes | efried: yeah, I've read that over and over. And it directly contradicts your own statement on the sum resources patch. | |
| 18:04:47 | efried | jaypipes: Sorry, which statement/patch? | |
| 18:05:22 | mriedem | arvindn051: if you want to handle the edge case check in a follow up that's fine with me | |
| 18:05:28 | arvindn051 | jaypipes: thanks. i am just starting out with contributing to the project...so learning pains is how i am taking it. So close to getting it checked in :) | |
| 18:05:34 | jaypipes | efried: "No, I think that, under the current design, if you want two VFs, you should specify them in separate granular request groups, even if they're identical, so that you'll still get a viable candidate in the scenario described for this test case." | |
| 18:05:47 | mriedem | arvindn051: add the check on top and i'll approve this | |
| 18:07:42 | efried | jaypipes: We talked about that some more in IRC afterwards IIRC, and I gave up on the idea that we would separate out the *results* for that kind of request. But there's nothing contradictory there. Specifying two identical VFs in separate numbered request groups allows you to get viable results whether you have (available inventory in) one PF or multiple. | |
| 18:08:07 | efried | jaypipes: I also realized later that we can't separate out the results without changing the response format, because dict. | |
| 18:08:52 | efried | jaypipes: So I accepted that, in such cases where placement had to combine those results, the caller would have to pick them apart again (based on their request, I guess). | |
| 18:09:40 | efried | jaypipes: In any case, like I said in that comment, we're going to need both semantics at some point. It's just a matter of which one is the default. | |
| 18:10:08 | efried | Someone who feels strongly that it should be opposite to what's in the spec should propose an amendment to that spec. | |
| 18:10:29 | efried | and/or an addition to the syntax that will enable the other. | |
| 18:10:30 | openstackgerrit | Matt Riedemann proposed openstack/nova master: [placement] Fix incorrect exception import https://review.openstack.org/558916 | |
| 18:11:20 | efried | mriedem: Do I get to +2 this again now? ^ :P | |
| 18:11:42 | efried | (jk, need to wait for melwitt to relook anyway) | |
| 18:11:45 | mriedem | efried: i'm sure melwitt would be fast to hit it | |
| 18:12:11 | efried | I can't believe I made a typo on the word whose typo I was fixing. | |
| 18:12:14 | melwitt | yeah geez yall | |
| 18:12:27 | efried | I blame the one-handed dvorak typing because fried chicken in the other hand. | |
| 18:13:00 | melwitt | fried chicken, good excuse | |
| 18:13:28 | jaypipes | numbered groups." | |
| 18:13:28 | jaypipes | valid for e.g. DISK_GB. If you want to be able to split, use separate | |
| 18:13:28 | jaypipes | While such a split could be seen to be sane for e.g. VFs, it is clearly not | |
| 18:13:28 | jaypipes | *resource_class*:*count* will never be split across multiple RPs. | |
| 18:13:28 | jaypipes | efried: from the spec: "* For both numbered and un-numbered ``resources``, a single | |
| 18:14:06 | jaypipes | efried: that, I believe, is the source of much confusion. | |
| 18:16:18 | melwitt | guh the server_group func tests are such a thorn in our side. another random failure http://logs.openstack.org/84/534384/24/check/nova-tox-functional/94444cd/testr_results.html.gz | |
| 18:16:35 | efried | jaypipes: How is that unclear? | |
| 18:17:28 | efried | If it said, "If you want to split," instead of "If you want to *be able to* split," perhaps. | |
| 18:18:27 | efried | And the third bullet in that same list is clear. | |
| 18:20:45 | jaypipes | efried: I strongly disagree that this is clear. otherwise we wouldn't have such strong disagreement about what was meant. | |
| 18:21:20 | jaypipes | melwitt: s/server_group func tests/server_group/ | |
| 18:22:13 | melwitt | fair :) | |
| 18:22:42 | openstackgerrit | Eric Berglund proposed openstack/nova master: WIP: PowerVM: Cold Migrate & Resize https://review.openstack.org/553583 | |
| 18:22:42 | efried | There wasn't disagreement about what was meant. People either didn't care at the time, or changed minds afterwards. | |
| 18:23:06 | efried | I'll grant that part of the problem may have been "too many words in spec". I've been working on that issue in subsequent specs. | |
| 18:24:12 | jaypipes | efried: or thought it meant one thing when in actuality it meant another. | |
| 18:25:09 | efried | I'm sure I'm having trouble seeing it because I wrote it, but to me this is crystal: "Separate groups (numbered or un-numbered) may return results from the same RP. That is, you are not guaranteeing RP exclusivity by separating groups. (If you want to guarantee such exclusivity, you need to do it with traits.)" | |
| 18:25:46 | jaypipes | efried: it's a subtle but extremely important distinction that "use_same_provider=True" meant (for you) that the resources from the single request group would be met by the same provider, which dansmith and I thought it meant that the resources in granular request groups would be met by different providers. | |
| 18:26:09 | odyssey4me | Hi everyone. I wonder if someone could help just verify whether this is normal or not. I'm trying to use the openstack client to disable a service, but it errors out. This is on a test environment which was deployed with Pike, then upgraded to Queens. I've tried this with the scheduler, consoleauth and conductor services, all with the same result.: https://gist.github.com/odyssey4me/5cec9c69dcf0f118f7a62464df64b480#file-output-log-L74 | |
| 18:26:09 | openstackgerrit | Merged openstack/nova master: Use a pythonic delete. https://review.openstack.org/554792 | |
| 18:26:58 | efried | we're talking about the code now? (Cause use_same_provider isn't part of the spec.) There's no way use_same_provider=True could be construed (or even used) to signify anything *between* request groups. | |
| 18:26:58 | jaypipes | odyssey4me: hi Jesse, yes, that's normal. you need to reconcile your cell to host mappings. | |
| 18:27:24 | jaypipes | efried: use_same_provider=False is set on numbered request groups. | |
| 18:27:46 | jaypipes | efried: which makes it seem that resource providers will not be the same for each numbered request group. | |
| 18:27:48 | odyssey4me | jaypipes apologies for my ignorance - what exactly does that mean? got a doc link or something for me? | |
| 18:27:55 | efried | vice versa jaypipes | |
| 18:28:05 | jaypipes | efried: I'm not saying you meant to cause this confusion, just that it obviously is confusing to some people. | |
| 18:28:11 | efried | in any resource provider in the same tree, or a sharing provider. | |
| 18:28:11 | efried | provider. If False, represents a request for resources and traits | |
| 18:28:11 | efried | resources and traits which must be satisfied by a single resource | |
| 18:28:11 | efried | If True, (the default) this RequestGroup represents requests for | |
| 18:28:11 | efried | :param use_same_provider: | |
| 18:28:42 | jaypipes | odyssey4me: yeah, sec, grabbing one | |
| 18:28:44 | efried | To put it in context, though, a RequestGroup is *one* request group. This says nothing of how this RequestGroup interacts with other RequestGroups. | |
| 18:29:05 | odyssey4me | tyvm, appreciate your time jaypipes | |
| 18:29:05 | jaypipes | odyssey4me: https://docs.openstack.org/nova/latest/cli/nova-manage.html#nova-cells-v2 | |
| 18:29:33 | jaypipes | odyssey4me: also try this: | |
| 18:29:34 | jaypipes | https://docs.openstack.org/nova/latest/cli/nova-status.html#upgrade | |
| 18:29:39 | jaypipes | nova-manage status check | |
| 18:30:31 | odyssey4me | ooh, a new command :) | |
| 18:30:53 | jaypipes | odyssey4me: sorry, that should have been nova-status upgrade check | |
| 18:31:13 | odyssey4me | with return codes and everything, fancy :) | |
| 18:31:22 | odyssey4me | yeah, got that - it says all is well | |
| 18:31:23 | jaypipes | odyssey4me: you can thank mriedem for it. | |
| 18:32:00 | mriedem | i think that's microversion 2.53 you're hitting | |
| 18:32:05 | odyssey4me | many thanks to mriedem then - we shall make use of this in ways similar to keystone doctor | |
| 18:32:20 | mriedem | odyssey4me: the services API only allows enabling/disabling 'compute' services once you're on cells v2 | |
| 18:32:43 | mriedem | b/c those compute service are mapped to a cell in the api db, but other non-compute services aren't | |
| 18:32:45 | mriedem | plus, | |
| 18:32:56 | mriedem | it doesn't make sense to disable non-compute services, as that doesn't mean/do anything | |
| 18:33:07 | odyssey4me | ok, then something's probably wrong in our config or something - because this started life as pike, so cellsv2 should have just been there from the start | |
| 18:33:27 | mriedem | odyssey4me: https://docs.openstack.org/releasenotes/nova/pike.html#id23 | |
| 18:33:32 | mriedem | The PUT /os-services/disable, PUT /os-services/enable and PUT /os-services/force-down APIs to enable, disable, or force-down a service will now only work with nova-compute services. If you are using those APIs to try and disable a non-compute service, like nova-scheduler or nova-conductor, those APIs will result in a 404 response. | |
| 18:33:35 | odyssey4me | oh doesn't it? I'm trying to do a nice process of disable, then shut down, then wipe the containers | |
| 18:34:09 | mriedem | check that release note | |
| 18:34:21 | odyssey4me | aha, I see | |
| 18:34:25 | jaypipes | efried: could you please explain to me your comment on https://review.openstack.org/#/c/534339/ then? If I have a single compute node with 2 PFs with 2 SRIOV_NET_VFs, and I request 4 SRIOV_NET_VF, how exactly are you proposing that we determine that that compute node is a good match for the request? | |
| 18:34:31 | odyssey4me | so I shouldn't be so nice and just wipe them :) | |
| 18:34:51 | efried | jaypipes: stand by | |
| 18:35:30 | odyssey4me | ok, many thanks - it makes much more sense now.. effectively it's no longer a thing, so don't do it | |
| 18:35:33 | mriedem | odyssey4me: likely a relic of your upgrade tooling | |
| 18:35:45 | mriedem | worked going from pre-cellsv2 to cellsv2, but not cellsv2+ | |
| 18:36:03 | mriedem | and yeah, was never a use in disabling / enabling non-compute services | |
| 18:36:40 | efried | jaypipes: I'm not sure which comment you're referring to, but to answer this: "If I have a single compute node with 2 PFs with 2 SRIOV_NET_VFs, and I request 4 SRIOV_NET_VF, how exactly are you proposing that we determine that that compute node is a good match for the request?" | |
| 18:38:08 | efried | jaypipes: Without knowing beforehand whether the compute node has one PF or two or four, or how many VFs are available on any of them, the most flexible way to issue that request and have the highest chance of landing *somewhere* would be: resources1=VF:1&resources2=VF:1&resources3=VF:1&resources4=VF:1 | |
| 18:38:55 | efried | that's of course assuming there are no traits in play (which in the case of PFs there likely would be, to represent nets or whatever) | |
| 18:39:34 | efried | One can envision a HAWeigher that would prefer results that were "spread". Etc. etc. | |
| 18:42:04 | jaypipes | efried: wow... | |