| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-10 | |||
| 08:45:50 | openstackgerrit | Michael Still proposed openstack/nova master: We don't need utils.trycmd any more. https://review.openstack.org/554439 | |
| 08:45:50 | openstackgerrit | Michael Still proposed openstack/nova master: Move image conversion to privsep. https://review.openstack.org/554437 | |
| 08:45:51 | openstackgerrit | Michael Still proposed openstack/nova master: We no longer need rootwrap. https://review.openstack.org/554438 | |
| 08:46:17 | zigo | kashyap: I did it but there are still ci failures. | |
| 08:50:33 | kashyap | zigo: Let me look; this shouldn't certainly cause CI failures | |
| 08:51:22 | kashyap | Hmm, I see "IBM PowerKVM CI" failing | |
| 09:14:29 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi: Support live migration in pooled multi-nodes environment https://review.openstack.org/489451 | |
| 09:28:56 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi: Use XAPI pool instead of aggregate pool for shared SR migration https://review.openstack.org/554154 | |
| 09:53:59 | openstackgerrit | Chris Dent proposed openstack/nova master: Use nova.db.api directly https://review.openstack.org/543262 | |
| 10:05:05 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi(N-R-P): Add API to support vgpu resource provider create https://review.openstack.org/520313 | |
| 10:25:41 | Tahvok | Should horizon respect the live migration when host aggregates are enabled? Because when I live migrate an instance, it still gives me an option to choose to live migrate an instance to a host not part of the host aggregate | |
| 10:46:35 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi(N-R-P):Get vgpu info from `allocations` https://review.openstack.org/521717 | |
| 10:52:00 | openstackgerrit | Petersingh Anburaj proposed openstack/nova master: Making consistent used of GiB and MiB in Doc https://review.openstack.org/559985 | |
| 11:05:06 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/queens: libvirt: Block swapping to an encrypted volume when using QEMU to decrypt https://review.openstack.org/559987 | |
| 12:19:28 | openstackgerrit | Yikun Jiang (Kero) proposed openstack/osc-placement master: Initialize 'result' variable in functional.base https://review.openstack.org/560004 | |
| 12:28:31 | efried | code: https://review.openstack.org/#/q/topic:bp/nested-resource-providers-allocation-candidates+(status:open+OR+status:merged) | |
| 12:28:31 | efried | spec: https://review.openstack.org/#/c/556873/ | |
| 12:28:31 | efried | naichuans: No, not yet. Keep an eye on blueprint nested-resource-providers-allocation-candidates | |
| 12:49:11 | efried | claudiub: Does autospec work for method signatures? | |
| 12:51:50 | efried | yes, yes it does. | |
| 12:53:06 | claudiub | sorry, I didn't see it in time. :) | |
| 12:53:15 | claudiub | and yes, it does, that was the whole point of it. :) | |
| 12:54:37 | claudiub | efried: although arguably there is still one case in which it doesn't get applied, one case I've missed in the original implementation: https://review.openstack.org/#/c/557923/ | |
| 12:54:39 | efried | claudiub: Knew it worked that way for objects, wasn't sure about methods. | |
| 12:56:24 | claudiub | efried: also, keep in mind that this has a +2, so it might merge soon. Hopefully it won't affect nova_powervm: https://review.openstack.org/#/c/470775/ | |
| 12:57:26 | efried | claudiub: If you have a moment, I'm hitting a place where the autospec doesn't seem to be working as expected... | |
| 12:57:34 | claudiub | sure, what's up | |
| 12:57:41 | efried | looking at this patch: https://review.openstack.org/#/c/552242/ | |
| 12:58:04 | efried | Look at the signature of e2fsck here https://review.openstack.org/#/c/552242/12/nova/privsep/fs.py | |
| 12:58:16 | efried | accepts (image, flags='-fp') | |
| 12:58:51 | claudiub | sure | |
| 12:58:52 | efried | Then look at the first usage here: https://review.openstack.org/#/c/552242/12/nova/virt/xenapi/vm_utils.py | |
| 12:59:03 | efried | note extra kwarg check_exit_code | |
| 12:59:26 | efried | So I thinks to myself, I thinks, "Okay, let's autospec here: https://review.openstack.org/#/c/552242/12/nova/tests/unit/virt/xenapi/test_vm_utils.py" | |
| 12:59:39 | efried | ...but when I do that, the test still passes. | |
| 13:00:05 | efried | i.e. the autospec doesn't seem to be catching that extra kwarg. | |
| 13:00:55 | claudiub | i might be blind, but where are you autospecing it? | |
| 13:00:56 | efried | It's probably me being blind. | |
| 13:01:11 | efried | @mock.patch('...', autospec=True) | |
| 13:01:21 | efried | is that a legit way to do that? | |
| 13:02:02 | claudiub | i might be really blind as a bat then. but yeah, there's a reason why it passes | |
| 13:03:41 | claudiub | or, wait, that only aplies to object methods. hm. anyways, there is an issue with mock.patch autospec, which i've addressed in oslotest. what happened was that mock.patch's autospec didn't consume the self / cls argument of object / class methods | |
| 13:04:08 | efried | I remember that issue. But in this case there are no classes involved, are there? | |
| 13:04:09 | claudiub | it should be the case now, since it's just a function. | |
| 13:04:44 | efried | it's possible my venv has an old oslotest, lemme check... | |
| 13:04:57 | claudiub | can you check if the mock.patch autospec works as expected with this patch on top? https://review.openstack.org/#/c/470775/ | |
| 13:04:59 | efried | finucannot: you around this week? | |
| 13:05:16 | efried | claudiub: okay. | |
| 13:05:27 | finucannot | efried: Yes, but I'm focused on getting the numa-aware-vswitch PoC out the door | |
| 13:05:41 | stephenfin | oops | |
| 13:05:50 | claudiub | that patch basically enforces the oslotest's mock.patch behaviour. | |
| 13:07:52 | mriedem | jianghuaw_: does the citrix xenserver CI have any multinode job to test live migration for this series? https://review.openstack.org/#/c/489451/ | |
| 13:15:21 | efried | claudiub: Okay, first I upgraded oslotest in my venv (3.2.0 => 3.4.1). Then I patched in https://review.openstack.org/#/c/557923/ (which presumably also means I'm getting as-yet-unreleased oslotest whatever). Then I merged in https://review.openstack.org/#/c/470775/ with the patch in question. | |
| 13:15:28 | efried | claudiub: None of this yielded the expected failure. | |
| 13:16:09 | claudiub | interesting | |
| 13:16:21 | claudiub | i'll take a look today as well | |
| 13:16:44 | claudiub | but later on, I have a meeting soon, so I have to prepare for that. :) | |
| 13:17:01 | claudiub | but thanks for catching it. :) | |
| 13:18:18 | openstack | Launchpad bug 1698010 in OpenStack Compute (nova) "neutron-based instances should not use the nova-network 'dhcp_domain' option" [High,In progress] - Assigned to Stephen Finucane (stephenfinucane) | |
| 13:18:18 | madhaviy | mriedem: I am checking fix proposed for LP bug https://bugs.launchpad.net/nova/+bug/1698010, by stephenfin , is there any other way to avoid using dhcp_domain from nova.conf during config_drive metadata creation | |
| 13:19:08 | efried | claudiub: Ahcrap, I think I know what's happening. | |
| 13:19:28 | efried | The method in question is decorated with a thing that accepts *a, **k | |
| 13:19:56 | claudiub | oh, I see. | |
| 13:20:13 | claudiub | interesting. :) | |
| 13:20:25 | efried | sure would be nice to be able to get around that somehow. But that sounds like black magic to me. | |
| 13:21:01 | claudiub | also, just an fyi, there are still a few other cases in which autospec is not working properly, for example sqlalchemy tends to have decorators which inject arguments in to the call. can't really autospec that. :) | |
| 13:22:40 | claudiub | well, autospecs are almost useless for methods which have *args / **kwargs | |
| 13:23:08 | claudiub | not entirely, but still. | |
| 13:26:59 | mriedem | madhaviy: i don't remember the details of that, but i do remember that the proposed patch wasn't going to work per garyk's comments. i also seem to remember an openstack-dev ML thread about this, but don't recall those details either. i would have to go back and dig into all of this and load it up into my head, which i'm not going to do right now (busy with other stuff), so unless you can summarize it's going to have to wait. | |
| 13:29:10 | mriedem | i don't see any links to ML discussion in the patches though | |
| 13:31:31 | mriedem | this reminds me, i think it's very weird that the use_neutron config option is deprecated https://docs.openstack.org/nova/latest/configuration/config.html#DEFAULT.use_neutron even though it's in our install guide and is required while we still have nova-network around | |
| 13:31:50 | mriedem | if anyone is going through their logs and sees a deprecation warning for using use_neutron, there isn't anything they can do about it | |
| 13:32:20 | mriedem | i think oslo.service or one of the oslo libraries even has a flag where you can force services to not start if they are using deprecated options, so you can flush those out in pre-prod | |
| 13:33:20 | mriedem | in other words, wouldn't it make more sense to *not* deprecate options required to run nova with neutron, until at least we've removed nova-network? | |
| 13:33:38 | mriedem | stephenfin: thoughts? ^ | |
| 13:35:07 | stephenfin | mriedem: You can filter out those warnings if you want. The intention is "this warning currently exists but is going away soon". The reason it's going away is given in the message | |
| 13:35:32 | stephenfin | *this option currently exists | |
| 13:36:15 | openstackgerrit | Raoul Hidalgo Charman proposed openstack/nova master: Expose shutdown retry interval as config setting https://review.openstack.org/552483 | |
| 13:37:00 | efried | claudiub: Yeah, I recognize that; what I'm asking for in this case is a way to signal that I want to get around the decorator and autospec the actual method underneath it. | |
| 13:38:58 | cdent | efried: not really possible, your method has been redefined | |
| 13:39:24 | cdent | the original form is sort of gone | |
| 13:39:24 | efried | cdent: Yeah, hence "black magic" | |
| 13:39:41 | cdent | that would be darker than black | |
| 13:41:07 | lpetrut | efried: you may be able to retrieve the decorated methods, we do it in a few cases to avoid lock decorators within unit tests: https://github.com/openstack/os-win/blob/e0d7032dfb042f56fd02a52796b186cd8d67d240/os_win/_utils.py#L82 | |
| 13:41:16 | mriedem | madhaviy: here is that ML thread http://lists.openstack.org/pipermail/openstack-dev/2017-September/121762.html | |
| 13:41:38 | efried | lpetrut: ooooo | |
| 13:42:50 | cdent | efried, lpetrut: too dark | |
| 13:43:03 | efried | ima try it anyway | |
| 13:43:08 | efried | cdent: hold my soul | |
| 13:43:23 | cdent | efried: wouldn't it be better to extract the thing you want to test to an undecorated thing? | |
| 13:44:05 | efried | cdent: I tried that first. Because it's already extracted thusly. But the decorator itself makes the test suite freak out. (It's the privsep entrypoint) | |
| 13:44:21 | cdent | it's all a bit smelly to me (not your soul (but maybe?)) | |
| 13:44:36 | cdent | but we already know how I feel about complexity in tests... | |
| 13:44:44 | efried | I'm trying to soften the blows I keep on dishing out to mikal | |
| 13:45:06 | efried | cdent: FYI: https://review.openstack.org/#/c/552242/ | |
| 13:47:40 | mriedem | madhaviy: there is also a thread in the operators ML with some other options | |
| 13:51:28 | claudiub | efried: yeah, as lpetrut said, we're getting the undecorated method is some unit tests in os-win, but that would only be needed for decorators which has some sort of special behaviour (adds / injects new arguments). even if we do autospec the undecorated methods, there are still plenty of cases in which the methods expects some sort of key-value argument, something like: | |
| 13:51:32 | madhaviy | mriedem: thanks. But I do not see any conclusion out of this discussion. Can we get back dhcp_domain conf option (not to deprecate) | |
| 13:51:33 | claudiub | if kwargs.get("something"): then do something | |
| 13:51:47 | claudiub | I've seen this in some oslo libs. | |