| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-05 | |||
| 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... | |
| 18:42:54 | jaypipes | efried: and what about DISK_GB? if we don't get a single provider that has 1024 GB of disk space from a single disk, do we break the request into two requests for 512 MB from two different resource providers? | |
| 18:43:12 | efried | not unless you want two disks. | |
| 18:43:30 | jaypipes | efried: the resource is not a disk. The resource is DISK_GB. i.e. an amount of GB of disk space. | |
| 18:43:55 | efried | Right. Point is that the *caller* understands the semantics of that, though. Not placement. | |
| 18:44:41 | efried | So if you want two 512GB disks, you say resources1=DISK_GB:512&resources2=DISK_GB:512. They may come from the same provider (which will respond with DISK_GB:1024 and you'll have to go back to your request to figure out that you wanted to split it up) or they may come from separate providers. | |
| 18:45:45 | efried | It would be nice if the user didn't have to know that the systems in the cloud have one disk or ten, on PF or eight, etc. He just wants his instance to land. | |
| 18:46:06 | efried | Or maybe that's wrong. Maybe there needs to be tight coupling between the flavors and the exact topology of the cloud. | |
| 18:46:18 | efried | but that doesn't seem very... cloudy to me. | |
| 18:46:50 | jaypipes | efried: I just want to make sure we're tackling real-world problems. | |
| 18:47:12 | efried | okay: what's the real-world problem that demands separation? NUMA? | |
| 18:47:28 | jaypipes | efried: I don't believe that there is a viable use case for a request for 4 SRIOV VFs and the requester doesn't care whether the VFs are provided by a single PF or two PFs. | |
| 18:47:56 | efried | FWIW, we implemented exactly that use case in powervm for SR-IOV. | |
| 18:48:08 | efried | For HA. | |
| 18:48:37 | jaypipes | efried: when does a requester of SRIOV VFs *not* want HA? | |
| 18:48:52 | openstackgerrit | Merged openstack/nova master: Avoid showing password in log https://review.openstack.org/558694 | |
| 18:49:02 | openstackgerrit | Merged openstack/nova master: Add __repr__ for NovaException https://review.openstack.org/555812 | |
| 18:49:11 | efried | When there's only one PF available. | |