| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-06 | |||
| 09:49:57 | kashyap | zigo: Some new APIs too | |
| 09:50:44 | zigo | Is there any incompatibilities? | |
| 09:51:32 | zigo | If there are bugfixes, then I can try to do my best to get the latest version from Buster backported. But that's a whole of a different story to have this backport being mandatory because of API breaks. | |
| 09:51:33 | kashyap | zigo: That's a broad question, you mean API incompat? | |
| 09:51:36 | kashyap | zigo: No, not really | |
| 09:51:38 | zigo | Yeah... | |
| 09:52:03 | kashyap | zigo: Isn't it too much to backport the 'Buster' versions? Rather than introducing the bit more conservative 3.2.0 and 2.9.0 (QEMU)? | |
| 09:52:15 | zigo | If 3.2.0 is still backward compatible with 3.0.0, then just require 3.0.0 and I'll do what I can to get the backport done. It's just nicer to not have it mandatory. | |
| 09:52:30 | kashyap | zigo: libvirt guarantees API compatibility "forever" | |
| 09:52:35 | zigo | Oh ! | |
| 09:52:42 | zigo | So why are you willing to even require anything? | |
| 09:53:13 | kashyap | Wait, let me retract that :-) | |
| 09:53:26 | kashyap | Read here about API guarantees: https://libvirt.org/support.html | |
| 09:54:12 | zigo | Another thing: isn't Nova only interested in the python-libvirt API, rather than the engine behind? | |
| 09:54:12 | kashyap | zigo: I meant, the "forever" part applies to ABI compatibility from the primary public API | |
| 09:55:05 | zigo | " IOW they will be ABI compatible forever." <--- Read this, indeed ! | |
| 09:55:34 | zigo | That's the Linux kernel userland API policy (though here, ABI, which is even nicer). | |
| 09:55:38 | kashyap | zigo: Each Compute node runs libvirt daemon | |
| 09:56:19 | zigo | Linuz told Debian folks (at Debconf in portland) that he didn't understand why it wasn't a common practice on all the Linux echosystem, and I very much agree ! :) | |
| 09:58:00 | zigo | Ok, so libvirt C lib is super-stable, but is there anything new in 3.2.0 that you would need that isn't in 3.0.0 ? | |
| 09:59:05 | kashyap | zigo: Yeah, like I said 3.2.0 libvirt (in conjunction with QEMU 2.9.0) by default saves a ton of headache in the CPU modelling area | |
| 10:02:03 | kashyap | zigo: But if it's too much time and effort, it's alright, can settle on 3.0.0 & 2.8.0 | |
| 10:04:10 | zigo | Great, thanks. Just do that, and advise for 3.0.0, then I'll keep in mind that backporting is prefered. | |
| 10:04:38 | zigo | The real issue isn't "too much effort", right now, it's not. The issue is: I don't know if it's going to be hard or even impossible in one year from now. | |
| 10:04:54 | zigo | Anyway, thanks so much for your care. | |
| 10:07:23 | kashyap | zigo: Email sent. | |
| 10:26:55 | openstackgerrit | Chris Dent proposed openstack/nova master: Move test_report_client out of placement namespace https://review.openstack.org/558911 | |
| 11:58:43 | kashyap | Anyone also seeing these timeout issues: | |
| 11:58:43 | kashyap | http://logs.openstack.org/84/534384/24/check/neutron-tempest-multinode-full/594b6f8/job-output.txt.gz#_2018-04-06_05_44_18_306935 | |
| 12:01:36 | efried | kashyap: Things have been pretty flaky the last couple of days. I haven't been paying close enough attention to say whether it's that same issue over and over, but could very well be. | |
| 12:01:43 | efried | I bet mriedem knows more. | |
| 12:03:35 | kashyap | I just wanted to be mindful before I blindly hit 'recheck' | |
| 12:06:40 | cdent | efried, edleafe : a) what day is it? b) do either of you recall what the state of multiple member_of params is? | |
| 12:07:09 | jroll | kashyap: there's been something about a certain provider giving lots of timeouts | |
| 12:07:19 | kashyap | jroll: Ah, I see. | |
| 12:07:34 | kashyap | That explains the 'recheck's by others while I was asleep | |
| 12:08:36 | fried_rice | a) Thanks cdent; b) Spec merged: https://review.openstack.org/#/c/555413/ original series nearing completion, new work not started. | |
| 12:08:41 | fried_rice | as far as I know. | |
| 12:08:43 | jroll | ah yes, limestone, which is the provider for that job | |
| 12:09:03 | cdent | thanks fried_rice | |
| 12:09:23 | fried_rice | cdent: Original bp topic https://review.openstack.org/#/q/topic:bp/alloc-candidates-member-of+(status:open+OR+status:merged) | |
| 12:09:59 | cdent | yeah, had that, was more a question of "is someone on the hook for that?" | |
| 12:14:13 | fried_rice | cdent: Not sure, actually. Either dansmith or edleafe I would imagine. | |
| 12:14:41 | cdent | fried_rice: I've noted the need for someone in the weekly report | |
| 12:14:51 | fried_rice | ack | |
| 12:53:39 | mriedem | arvindn05: dansmith: i just thought of something fun with the image-based traits spec, | |
| 12:53:50 | mriedem | if we rebuild with a new image that has some required traits on it, | |
| 12:54:05 | mriedem | will we run through placement during scheduling again? | |
| 12:54:12 | mriedem | i.e. https://review.openstack.org/#/c/546357/ | |
| 12:54:52 | mriedem | we flagged our individual filters on what can run during rebuild based on quantitative resources or not, but traits on the image would be...qualitative? | |
| 12:59:12 | mriedem | arvindn05: i left a comment in the spec https://review.openstack.org/#/c/541507/9/specs/rocky/approved/glance-image-traits.rst@151 - we'll likely need an amendment for that | |
| 13:01:56 | ArchiFleKs | Hi, I have a weird issue, on a compute node I cannot launch nova-compute, I tried "/openstack/venvs/nova-16.0.10/bin/python -v /openstack/venvs/nova-16.0.10/bin/nova-compute --debug" manually and it just exit, I have no log on the nova side, just python loading : http://paste.openstack.org/show/718596/ (I'm running openstack-ansible) | |
| 13:03:56 | figleaf | cdent: fried_rice: I believe that dansmith was working on that | |
| 13:04:09 | fried_rice | ack | |
| 13:04:34 | figleaf | with the notion that member_of(a,b) is an OR and member_of(a)&member_of(b) is an AND | |
| 13:06:45 | fried_rice | right. The spec update that dansmith merged should say that, I believe. (Haven't reread it since the review.) | |
| 13:12:40 | mriedem | claudiub|2: i'm seeing a failed hyperv CI run from last night, http://cloudbase-ci.com/nova/324720/5/Hyper-V_logs/192.168.3.143-compute01/neutron-hyperv-agent.log.gz | |
| 13:12:44 | mriedem | looks like this is the culprit | |
| 13:12:50 | mriedem | AttributeError: 'NoneType' object has no attribute 'startswith' | |
| 13:12:56 | mriedem | in File "/opt/stack/neutron/neutron/plugins/ml2/plugin.py", line 1864, in _device_to_port_id | |
| 13:13:22 | openstackgerrit | Eric Fried proposed openstack/nova master: add lower-constraints job https://review.openstack.org/555961 | |
| 13:13:29 | jroll | is there work being done (already done?) to move the instance groups (and thus affinity) work to use placement aggregates instead of host aggregates? | |
| 13:13:48 | mriedem | instance groups don't use aggregates | |
| 13:14:21 | jroll | mmm, maybe I'm misinformed then - let's just say affinity | |
| 13:14:39 | mriedem | figleaf had a distance etherpad i think for ideas on modeling affinity in placement | |
| 13:14:51 | mriedem | but there is no planned work for this in rocky as far as i know, we didn't talk about it at the ptg | |
| 13:15:14 | jroll | okay, thanks mriedem | |
| 13:16:42 | figleaf | mriedem: jroll: I think the closest we are getting to affinity is the member_of work, using placement aggs | |
| 13:17:26 | mriedem | placement aggregates are on resource providers though, and server group affinity filtering is on instances, so i'm not sure how that translates | |
| 13:17:34 | mriedem | since placement doesn't have a concept of consumer groups | |
| 13:18:59 | jroll | right, though I don't care as much about the server group concept as I do aggregate affinity | |
| 13:19:20 | jroll | figleaf: that is not exposed to the user (yet), correct? | |
| 13:19:32 | figleaf | mriedem: yeah, that's what I meant by "the closest we are getting". We're not re-creating every detail of Nova (at least not this cycle) | |
| 13:19:44 | figleaf | jroll: no, not yet | |
| 13:19:57 | jroll | cool. thanks | |
| 13:19:59 | jroll | :) | |
| 13:21:02 | mriedem | claudiub|2: https://bugs.launchpad.net/neutron/+bug/1761748 - not sure if that's what is causing the nova-compute service to say it's down in this CI run though | |
| 13:21:02 | openstack | Launchpad bug 1761748 in neutron "hyperv: Unable to get ports details for devices: AttributeError: 'NoneType' object has no attribute 'startswith'" [Undecided,New] | |
| 13:21:20 | mriedem | jroll: ok, i don't know what aggregate affinity is then :) | |
| 13:21:27 | mriedem | i think that's an oath only thing right now | |
| 13:21:48 | mriedem | and https://review.openstack.org/#/c/529135/ | |
| 13:22:47 | jroll | mriedem: well, ironic users in general want to create groups of baremetal machines based on locality/power/rack/etc, and do affinity between those groups. aggregates seem the most sensible | |
| 13:22:48 | sean-k-mooney | mriedem: jroll i would assume just passing member_of as part of resouce request to allocation_candiades | |
| 13:23:22 | mriedem | jroll: i think that's this https://review.openstack.org/#/c/529135/ | |
| 13:23:55 | jroll | sean-k-mooney: yes, that's what the spec provides, I'm trying to map that in my head to the future, as /allocation_candidates is not exposed to users | |
| 13:24:21 | mriedem | jroll: currently none of placement is exposed to users, per policy anyway | |
| 13:24:24 | jroll | mriedem: yeah, I'm hearing that dan hates this | |
| 13:24:26 | jroll | right | |
| 13:24:30 | sean-k-mooney | mriedem: jroll e.g. Resouce1:PCPU4,MEMORY_MB=1024 Resource1:member_of=<aggreagte uuid here> | |
| 13:24:31 | jroll | I'm aware of this :) | |
| 13:25:04 | mriedem | jroll: L17 https://etherpad.openstack.org/p/nova-ptg-rocky-placement | |
| 13:25:04 | sean-k-mooney | jroll: its not exposed to users but you can model this in the flavor | |
| 13:25:20 | mriedem | i didn't think this was the same thing as the "allow host or node uuid for aggregates in the API" thing | |
| 13:25:28 | mriedem | i thought that was a different spec, but couldn't find it | |
| 13:26:09 | jroll | mriedem: right, saw the etherpad, wasn't in the session. I don't see an explicit f this in the etherpad, so maybe it'll still happen | |
| 13:26:24 | jroll | trying to get a read on what to expect in the future, I guess | |
| 13:26:25 | mriedem | i didn't like it either | |
| 13:26:26 | mriedem | fwiw | |
| 13:26:28 | jroll | heh | |
| 13:27:15 | jroll | sean-k-mooney: I'm not doing a flavor per system type per rack, but thanks :) | |