| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-09-06 | |||
| 15:01:00 | stephenfin | efried: Ah, this is the bug in the oslo.config sphinxext module, right? | |
| 15:01:10 | bauzas | efried: dansmith: mriedem: others, sorry had to leave urgently because I missed my kids at schoold | |
| 15:01:25 | bauzas | I'm fine with punting the question about PCI future at the pth | |
| 15:01:27 | bauzas | pth | |
| 15:01:29 | bauzas | shit | |
| 15:01:30 | bauzas | ptg | |
| 15:02:06 | bauzas | but my take on it is "we can do some generic device refactoring in nova, while cyborg raises up" | |
| 15:02:15 | bauzas | I don't think it's a problem to us | |
| 15:02:20 | bauzas | and the community | |
| 15:02:49 | efried | bauzas: Okay, please take a look at https://review.openstack.org/#/c/591037/ when you get a chance then. | |
| 15:03:18 | efried | stephenfin: I don't think it has to do with sphinxext | |
| 15:03:53 | efried | stephenfin: If the default is [] I would think the sphinx doc should display it as []. But that's the confusing part (to the user). | |
| 15:04:42 | mriedem | efried: btw, i don't mean to minimize your gpu/pci/cyborg thing, i was just airing out my anxiety over the amount of stuff we have loaded up | |
| 15:04:58 | mriedem | which mostly makes me want to crawl in a hole | |
| 15:07:19 | efried | mriedem: Duly noted. But I should point out that I am expected to be making certain things happen to the benefit of those who sign my paycheck. I.e. I'm not totally free to work on a thing just because it's deemed a priority for nova-at-large, if that is to the exclusion of working on a thing that's a slightly-lesser-priority-for-nova-but-#1-priority-for-employer. | |
| 15:07:56 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/rocky: Configure placement DB context manager for nova-manage/status https://review.openstack.org/600464 | |
| 15:07:57 | mriedem | efried: yup i know, same here | |
| 15:08:53 | bauzas | heh, we're all on the same boat | |
| 15:09:05 | dansmith | heh | |
| 15:09:32 | bauzas | or you would see me more often | |
| 15:16:42 | mriedem | well, | |
| 15:16:48 | mriedem | we don't all get august off... | |
| 15:26:23 | bauzas | mriedem: touché, my point being on the 45 other weeks :p | |
| 15:30:29 | efried | stephenfin: Hm, actually it looks like there *is* a sphinx bug https://docs.openstack.org/nova/latest/configuration/config.html#pci <== the default is showing up as u'' here | |
| 15:31:08 | efried | I mean, it's still confusing if you're looking at the source; not sure how many admins do that vs looking at the html. | |
| 15:31:13 | efried | and if that bug gets fixed... | |
| 15:33:34 | dansmith | mriedem: looks like the latest rev of the configurable instance list behavior is failing unit tests | |
| 15:33:54 | dansmith | she's out until next week, but maybe we can get that landed then, if I don't get a chance to fix some trivial test failure before then | |
| 15:34:17 | mriedem | landed in denver you mean? | |
| 15:34:20 | mriedem | i saw the tests failing | |
| 15:35:22 | dansmith | landed in denver yeah | |
| 15:36:34 | dansmith | hmm, it's in the middle of her stack now, | |
| 15:36:38 | dansmith | which is probably why it's breaking | |
| 15:36:47 | dansmith | I dunno why | |
| 15:36:58 | dansmith | why it's in the middle I mean | |
| 15:50:18 | cdent | sigh, how we supposed to think about forum when the ptg hasn't even happened yet? | |
| 15:50:35 | mriedem | guh so https://review.openstack.org/#/c/585475/ is still failing | |
| 15:51:06 | mriedem | gmann: do you have any ideas on the tempest test failing your change https://review.openstack.org/#/c/585475/ ? | |
| 15:51:39 | mriedem | cdent: oh that's easy | |
| 15:52:09 | mriedem | nova at the edge, LTS releases, API v3, <insert generic thing that will never amount to anything> | |
| 15:52:22 | mriedem | oh FFU | |
| 15:52:27 | mriedem | can't forget FFU | |
| 15:52:33 | mriedem | FFU & U! | |
| 15:53:02 | mriedem | well, i can't say they won't amount to anything, they will amount to SIG formation where those SIGs don't do anything | |
| 16:04:51 | mriedem | melwitt: looks like we need a rocky series for novaclient bug tracking https://launchpad.net/python-novaclient | |
| 16:05:19 | melwitt | mriedem: oh, I missed that | |
| 16:05:44 | melwitt | poor ol novaclient | |
| 16:06:40 | melwitt | need to do all our libs actually | |
| 16:12:55 | melwitt | mriedem: added rocky and stein to novaclient | |
| 16:13:35 | mriedem | thanks | |
| 16:16:06 | openstackgerrit | Eric Fried proposed openstack/nova master: fup: Fix import order and test nit https://review.openstack.org/600474 | |
| 16:18:11 | melwitt | looks like the other libs (os-traits, os-vif, placement-osc-plugin) just follow "trunk" and no series needed? it's not consistent | |
| 16:26:55 | openstack | Launchpad bug 1709902 in OpenStack Compute (nova) "source host allocation not cleaned up in placement after evacuation" [Medium,Fix released] - Assigned to Balazs Gibizer (balazs-gibizer) | |
| 16:26:55 | nicolasbock | Hi, say I was hit by https://bugs.launchpad.net/nova/+bug/1709902 and have a few VMs now that are running somewhere where they are not supposed to | |
| 16:27:25 | nicolasbock | How would I get them to be correctly registered again? | |
| 16:36:48 | stephenfin | efried: Sorry, was on a call (and follow-ups). Yeah, I think you mentioned that issue before to me, hence why I brought it up again | |
| 16:37:18 | efried | stephenfin: It didn't sound familiar, so if I brought it up, I purged the memory. | |
| 16:37:52 | efried | stephenfin: See latest comment, not sure where to go from here. Back to PS2, or put really awkward words in, or <something else>...? | |
| 16:38:18 | stephenfin | efried: But, as you've summarized on the review, using that default is the correct thing to do. Confusingly, the default reflects the _processed_ result, i.e. once oslo.config has gone and merged all those disparate 'alias' values into one list | |
| 16:38:59 | stephenfin | efried: I'm also not 100% sure that the bug upstream is a bug as it's hiding the above fact from the user | |
| 16:39:29 | efried | Well, the bug just complains that you break if you use square brackets. Which is true. | |
| 16:39:31 | stephenfin | efried: The changes they've made to the help text are valid and should be retained. It's just the changes to default that need to be removed | |
| 16:39:43 | stephenfin | efried: In nova.conf? | |
| 16:39:49 | efried | yeah | |
| 16:40:06 | efried | it breaks when we try to process it. | |
| 16:40:12 | efried | not an oslo problem, a nova problem. | |
| 16:40:14 | stephenfin | efried: Yeah, then our docs are wrong. We never supported use of list values for that option | |
| 16:40:22 | stephenfin | Yup, a nova docs problem | |
| 16:41:08 | stephenfin | Fixing this by adding processing of lists would be a feature, not a bug fix, as you've pointed out. Fixing it by correcting the docs, on the other hand, is a must do | |
| 16:43:09 | stephenfin | efried: That make sense? | |
| 16:43:59 | efried | stephenfin: Yeah, I get it. And their add definitely helps. But don't you feel like we should mention that you *can't* use a square-bracket list, despite the fact that the default makes it look like you can? | |
| 16:44:31 | stephenfin | efried: The default in the code but not the docs. I think a comment would be a-ok | |
| 16:45:36 | stephenfin | I wouldn't put it into the docstring since that's going to show up in the HTML docs and nova.conf templates, neither of which will actually have that default | |
| 16:47:01 | efried | stephenfin: But only because there's a bug? | |
| 16:47:20 | stephenfin | efried: Is it a bug or is it a feature? :) | |
| 16:47:25 | efried | stephenfin: The default being [] is something that *should* show up in the docs | |
| 16:47:31 | efried | because that's how it shows up in code. | |
| 16:48:16 | stephenfin | efried: Right, but recall what I said above. The default for these MultiStrOpt opts applies to the final value, not each individual entry | |
| 16:48:43 | stephenfin | Not a great design decision in oslo.config, if you ask me, but not something one could fix without breaking the world | |
| 16:49:17 | efried | ? | |
| 16:49:17 | efried | alias = '' | |
| 16:49:17 | efried | stephenfin: sorry, I don't follow. You mean that by saying the default is '' it's actually saying that omitting it is equivalent to specifying | |
| 16:49:53 | efried | cause... it ain't, I'm pretty sure. If you did that, you would either get '' or [''] | |
| 16:50:15 | efried | whereas omitting it you get [] | |
| 16:50:21 | efried | f idk | |
| 16:50:45 | efried | maybe I'm the one thinking too hard about this, and it's obvious to admins | |
| 16:51:00 | melwitt | I was thinking it was a bug that a list doesn't work and that we would fix it. did someone not want to fix it? | |
| 16:51:04 | efried | but seeing default=[] makes me think that I would use [...] to specify multiple values. | |
| 16:51:23 | efried | melwitt: Yeah, they fixed that in PS2 but I shot it down because we don't want to do more work on pci code. | |
| 16:51:25 | stephenfin | efried: Yeah, which is why the docs lie | |
| 16:51:30 | melwitt | (I just commented on the review but now see it's being discussed still here) | |
| 16:51:48 | stephenfin | melwitt: We don't want/need to do that. It's a feature. The bug is in the documentation, IMO | |
| 16:51:51 | efried | melwitt: or as stephenfin put it, fixing it to take a list would be a "feature". | |
| 16:52:26 | melwitt | oh, okay. stephenfin definitely knows more than me about the intention when it was created, so if a list was not meant to work, then I agree, doc bug | |
| 16:52:57 | melwitt | I had thought because of the examples in the config help, it was supposed to work as a list | |
| 16:53:04 | stephenfin | `MultiStrOpt`s are meant to be defined multiple times in a nova.conf. No reason to support defining it multiple ways. More JSON is the last thing anyone needs | |
| 16:53:21 | stephenfin | melwitt: Clearly so did whoever wrote the docs (probably me, tbf) :) It's wrong though | |
| 16:53:37 | melwitt | I see | |
| 16:54:31 | stephenfin | ouch | |
| 16:55:28 | stephenfin | efried: Personally, I'd stick in a comment saying "this means the option is undefined" and leave it at that. There are bigger battles to be fought | |