| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-05 | |||
| 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 | efried: from the spec: "* For both numbered and un-numbered ``resources``, a single | |
| 18:13:28 | jaypipes | *resource_class*:*count* will never be split across multiple RPs. | |
| 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 | valid for e.g. DISK_GB. If you want to be able to split, use separate | |
| 18:13:28 | jaypipes | numbered groups." | |
| 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 | efried | There wasn't disagreement about what was meant. People either didn't care at the time, or changed minds afterwards. | |
| 18:22:42 | openstackgerrit | Eric Berglund proposed openstack/nova master: WIP: PowerVM: Cold Migrate & Resize https://review.openstack.org/553583 | |
| 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 | openstackgerrit | Merged openstack/nova master: Use a pythonic delete. https://review.openstack.org/554792 | |
| 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:58 | jaypipes | odyssey4me: hi Jesse, yes, that's normal. you need to reconcile your cell to host mappings. | |
| 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: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 | :param use_same_provider: | |
| 18:28:11 | efried | If True, (the default) this RequestGroup represents requests for | |
| 18:28:11 | efried | resources and traits which must be satisfied by a single resource | |
| 18:28:11 | efried | provider. If False, represents a request for resources and traits | |
| 18:28:11 | efried | in any resource provider in the same tree, or a sharing 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 | jaypipes | odyssey4me: https://docs.openstack.org/nova/latest/cli/nova-manage.html#nova-cells-v2 | |
| 18:29:05 | odyssey4me | tyvm, appreciate your time jaypipes | |
| 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. | |
| 18:50:02 | jaypipes | efried: if there's only one PF available, and the image/flavor needs >1 SRIOV VF, then IMHO, that compute node with only a single PF shouldn't be a legit destination node. | |
| 18:50:31 | efried | jaypipes: If I don't care about HA, and I said resources1=SRIOV_NET_VF:1&required1=CUSTOM_PHYSNET_A&resources2=SRIOV_NET_VF:1&required2=CUSTOM_PHYSNET_B (because that's the only way I can get two VFs on separate physnets), and I was *forced* to use two separate PFs to make that happen, I would not be able to land an instance on a node with just one PF. | |
| 18:50:42 | jaypipes | efried: the whole purpose of having multiple VFs is to allow active/failover for links... | |
| 18:50:50 | efried | When HA is the issue, yes. | |
| 18:54:25 | jaypipes | welcome back | |
| 18:56:23 | efried | Was that my glitch or a server thing? | |
| 18:56:30 | efried | Did I miss stuff? | |
| 18:56:37 | efried | Here's what I was about to say: | |
| 18:58:03 | efried | Look, I'm (still) not arguing that there are cases where it will be useful to force split. I'm (still) asserting that we're going to need to be able to handle both. One behavior will be the default, and the other will require some extra syntax to make it happen. I'm not convinced we truly need *either* immediately. So I've been advocating for the default being the one that's in the spec, because that's the one that make | |