| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-06-21 | |||
| 15:13:59 | mriedem | so the thinking is, the compute node resource provider has a trait for that capability flag, and if the server create request has tagged nics/bdms, we put a required trait in the request spec for the scheduler to use fo filtering hosts | |
| 15:14:03 | jaypipes | mriedem: that seems like a fine one to me, sure | |
| 15:14:21 | mriedem | ok coll | |
| 15:14:23 | mriedem | *cool even | |
| 15:32:07 | efried | sfinucan Looks like actdiag will generate SVG with the -T option. Guessing if it's not there already, this would have to be enabled via the docs builder code. | |
| 15:32:37 | sfinucan | efried: I'm using SVG atm (which is why you can copy paste the text) | |
| 15:33:01 | efried | sfinucan Oh, okay. I thought I saw an email that said you were frustrated by that. | |
| 15:33:29 | sfinucan | aha - no, sorry, I should have said I'd managed to figure that one out | |
| 15:33:37 | sfinucan | but not the other one. My mistake :) | |
| 15:33:50 | sfinucan | Though I have figured out the other one now, give or take | |
| 15:34:07 | efried | sfinucan Oh, was about to propose a patch for that. | |
| 15:34:32 | efried | My current crude workaround is jamming \n in the strings by trial/error. | |
| 15:34:40 | sfinucan | efried: Do anyway. Mine is kind of hacky (monkey patching stuff) | |
| 15:34:47 | sfinucan | ...though maybe not as hacky as yours :D | |
| 15:35:09 | efried | I'm looking to see if there's block size and/or autowrap options in the tooling. But I assume you've already done that. | |
| 15:46:44 | openstackgerrit | Markus Zoeller (markus_z) proposed openstack/nova master: docs: Explain the flow of the "serial console" feature https://review.openstack.org/476188 | |
| 15:48:30 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Explain why API services are filtered out of GET /os-services https://review.openstack.org/476189 | |
| 15:49:37 | mgagne | mriedem: what kind of exception do you suggest it raises? https://review.openstack.org/#/c/454322/18/nova/virt/libvirt/driver.py@1420 | |
| 15:51:56 | efried | sfinucan Looks like the best we can do (without hacking the source) is specify box height/width and sprinkle in newlines. | |
| 15:53:26 | mriedem | mgagne: the volume driver's default implementation for the extend_volume method could be just to raise NotImplementedError | |
| 15:53:38 | sfinucan | efried: Hmm, I wonder if hacking the source is such a bad thing though? | |
| 15:53:48 | sfinucan | I mean, IMO the current implementation is broken | |
| 15:54:00 | mriedem | mgagne: the libvirt driver code would have to handle that and translate it to some NovaException, like ExtendVolumeNotSupported or something | |
| 15:54:03 | mgagne | mriedem: so just reraise the NotImplementedError exception? | |
| 15:54:12 | mgagne | ok, that was my question | |
| 15:54:16 | melwitt | dansmith: +1 to skipping the cells meeting today | |
| 15:54:51 | mgagne | there are 2 things: virt might not support extend volume. volume driver within virt driver might not support extend volume. we need to handle both cases. first can be handled by capabilities. I'm not sure about the second one. | |
| 15:55:05 | efried | sfinucan I don't disagree. But where are you planning to hack? | |
| 15:55:19 | mgagne | so you suggest we reuse ExtendVolumeNotSupported if volume driver does not support extend volume? | |
| 15:55:21 | mriedem | mgagne: related comment here https://review.openstack.org/#/c/454322/18/nova/compute/manager.py@6891 | |
| 15:55:31 | sfinucan | efried: https://review.openstack.org/476159 | |
| 15:56:05 | mgagne | yes, handled that part, I'm not sure about the volume driver as it was not explicitly mentionned. will use the same exception then | |
| 15:56:43 | efried | sfinucan Yeah, that'd do it... partway. What about automatically adjusting the box size, though? With just this, you're going to get cut off. | |
| 15:57:01 | mriedem | mgagne: we could use different exceptions if we want, like you could raise ExtendVolumeNotSupported for the capabilities check, and subclass that with an ExtendVolumeNotSupportedForVolumeType exception if the volume driver doesn't support it - with that one having the type in the exception message | |
| 15:57:10 | mriedem | mgagne: i don't think it makes a ton of difference though | |
| 15:57:22 | mgagne | ok, will use ExtendVolumeNotSupported as suggested | |
| 15:57:29 | mriedem | the difference in error message that goes into the fault could be useful for an operator | |
| 15:57:56 | mriedem | but you tell me :) you're the one deploying this | |
| 15:58:16 | sfinucan | efried: You mean make all boxes bigger? | |
| 15:58:27 | sfinucan | I was trying to avoid that to stop stuff going off screen | |
| 15:58:30 | mgagne | haha, I have a totally different implementation and we fully support the feature so this code path is never used =) | |
| 15:58:45 | efried | sfinucan Well, not necessarily, though that would be easiest (changing the default box height). | |
| 15:59:09 | efried | sfinucan I was talking about scaling the box size dynamically according to font face/size + number of lines after your autowrap. | |
| 16:00:38 | efried | sfinucan ...which sounds pretty difficult to me. | |
| 16:01:02 | sfinucan | efried: That depends on how that tool is implemented | |
| 16:01:14 | sfinucan | efried: If they wrap text, then generate the box, it should be fine | |
| 16:01:41 | sfinucan | If the other way around, it might be tough/impossible as you'd need to resize an existing 'rect' and move anything below it too | |
| 16:01:50 | efried | sfinucan Still not sure how you would account for font face | |
| 16:02:27 | efried | sfinucan Oh, I guess it has a "measuring" facility built in. | |
| 16:02:29 | efried | Which makes sense. | |
| 16:02:46 | sfinucan | Yeah, it does that for us | |
| 16:03:27 | sfinucan | It's actually a surprisingly robust, well-tests bit of code, IMO | |
| 16:03:37 | openstackgerrit | Ildiko Vancsa proposed openstack/nova master: Add Cinder v3 detach to swap_volume https://review.openstack.org/456971 | |
| 16:06:57 | openstackgerrit | melanie witt proposed openstack/nova master: Add get_count_by_vm_state() to InstanceList object https://review.openstack.org/446244 | |
| 16:06:58 | openstackgerrit | melanie witt proposed openstack/nova master: Add scatter_gather_all_cells() utility https://review.openstack.org/475957 | |
| 16:06:58 | openstackgerrit | melanie witt proposed openstack/nova master: Remove 'reserved' count from used limits https://review.openstack.org/446242 | |
| 16:07:01 | openstackgerrit | melanie witt proposed openstack/nova master: Remove useless quota_usage_refresh from nova-manage https://review.openstack.org/446243 | |
| 16:07:02 | openstackgerrit | melanie witt proposed openstack/nova master: Count instances to check quota https://review.openstack.org/416521 | |
| 16:07:07 | openstackgerrit | melanie witt proposed openstack/nova master: Make Quotas object favor the API database https://review.openstack.org/410945 | |
| 16:07:10 | openstackgerrit | melanie witt proposed openstack/nova master: Add online migration to move quotas to API database https://review.openstack.org/410946 | |
| 16:09:35 | sfinucan | efried: I'll take another look-see and see if we can stop it truncating characters | |
| 16:09:58 | openstackgerrit | Eric Fried proposed openstack/nova master: Add formatting to scheduling activity diagram https://review.openstack.org/476204 | |
| 16:09:59 | efried | sfinucan ^^ Manual formatting; feel free to squash it into yours if you like. | |
| 16:10:06 | sfinucan | Ta :) | |
| 16:12:56 | cfriesen_ | mriedem: for "nova show --minimal" do we want to keep the pre-2.47 "flavor" field name, or change it to "flavor:original_name" to reflect what's in the REST API response? | |
| 16:13:31 | mriedem | cfriesen_: i'd keep it the same | |
| 16:13:37 | mriedem | in the --minimal case | |
| 16:13:38 | mriedem | since it's a single field | |
| 16:13:45 | mriedem | the namespace flavor: is for the multi-field show details | |
| 16:14:15 | efried | sdague mriedem We had an unfortunate miscue last week; events conspired to blow up the PowerVM driver. Fix is here https://review.openstack.org/#/c/475926/ - in-house +1s and passing our CI :) | |
| 16:14:54 | mriedem | ha, isn't that the exact same change where i said the ci was failing | |
| 16:14:55 | mriedem | ? | |
| 16:15:09 | mriedem | "The CI failed but I guess that's an unrelated known issue so this seems fine." | |
| 16:15:27 | efried | mriedem Yes, precisely; the CI was indeed failing for totally unrelated reasons. | |
| 16:15:46 | efried | ...but by the time we got around those, that guy had merged, and broke it further down the line. | |
| 16:17:10 | mriedem | ok +2 | |
| 16:17:17 | efried | mriedem Thanks | |
| 16:22:14 | efried | sfinucan Note the last box in the Scheduler lane is truncated: http://docs-draft.openstack.org/59/476159/1/check/gate-nova-docs-ubuntu-xenial/bf9b0cb//doc/build/html/scheduling.html?highlight=scheduling | |
| 16:30:03 | mriedem | gibi_: going to probably want your input on this one https://review.openstack.org/#/c/403568/ | |
| 16:30:43 | mriedem | gibi_: re: the question about whether or not we should or need to provide the network info for the instance in the instance.shutdown.end notification | |
| 16:30:52 | mriedem | since at that point it's really already deallocated | |
| 16:31:08 | mriedem | you would have it in the instance.shutdown.start notification | |
| 16:31:21 | mriedem | so maybe this is really just fixing the instance.shutdown.end notification to be accurate | |
| 16:32:21 | kfox1111 | anyone know the status of virtfs integration? | |
| 16:32:45 | mriedem | kfox1111: no status? | |
| 16:33:05 | kfox1111 | not implemnted yet? :/ | |
| 16:33:11 | mriedem | as in, | |
| 16:33:16 | mriedem | no one is working on that | |
| 16:33:23 | kfox1111 | bummer. k. | |
| 16:33:31 | mriedem | i vaguely remember manila folks talking about something similar maybe pre-atx summit? | |
| 16:33:57 | kfox1111 | yeah. it handles the manilla case well. | |
| 16:34:09 | kfox1111 | also hpc/htc on nova. | |
| 16:34:29 | mriedem | https://review.openstack.org/#/c/310050 | |
| 16:35:08 | mriedem | kfox1111: ^ is what you want | |
| 16:35:18 | mriedem | or as close as virtfs has gotten to nova land | |
| 16:35:40 | kfox1111 | yeah something like that. | |
| 16:35:43 | kfox1111 | thanks for the link. | |
| 16:39:25 | sfinucan | efried: Yeah, saw that. Wasn't sure if/how I could fix it | |
| 16:39:42 | sfinucan | Maybe your patch addresses it - I haven't checked yet | |
| 16:40:06 | efried | sfinucan Yes, mine does address it, but manually by setting box heights. The other option is as discussed above, adding an autosize facility. | |