| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-06 | |||
| 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 | http://logs.openstack.org/84/534384/24/check/neutron-tempest-multinode-full/594b6f8/job-output.txt.gz#_2018-04-06_05_44_18_306935 | |
| 11:58:43 | kashyap | Anyone also seeing these timeout issues: | |
| 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 | 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: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: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 | sean-k-mooney | jroll: its not exposed to users but you can model this in the flavor | |
| 13:25:04 | mriedem | jroll: L17 https://etherpad.openstack.org/p/nova-ptg-rocky-placement | |
| 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 :) | |
| 13:28:29 | mriedem | i remember one thing from the ptg was at least some sentiment that if we did do this in nova, we wouldn't want to munge the host and node concept into the existing host aggregate API today, since that could be really confusing | |
| 13:28:50 | mriedem | you'd need like a hypervisor (node) aggregate API or something so it's clear that it's different | |
| 13:28:56 | sean-k-mooney | jroll: sure but somthing line Resouce1:PCPU4,MEMORY_MB=1024 Resource1:member_of=<aggreagte uuid here> should work the question then becomes how to get that to placement | |
| 13:28:59 | mriedem | os-hypervisors is the API today for compute nodes | |
| 13:29:02 | mriedem | os-services is the one for hosts | |
| 13:29:43 | jroll | mriedem: yeah, totally understand that, I was fairly surprised when jay introduced that spec to be honest | |
| 13:29:52 | mriedem | as for the comments in the etherpad about using the placement-req-filter stuff, the question is how do you transfer the user request to the nova scheduler, and i think that's what the policy part was for in jay's spec | |
| 13:29:54 | sean-k-mooney | jroll: flavors is the only way that works today but we have discussed allowing resouce requests via neutron port and glance images too | |
| 13:30:18 | jroll | sean-k-mooney: I really don't want to design a feature over irc right now, sorry | |
| 13:31:02 | mriedem | so i'm not sure how we leverage placement-req-filter with ironic node aggregates in placement yet | |
| 13:31:07 | sean-k-mooney | jroll: no worries just giving one option. i think we agree this is a valid usecase that should be supported. how is a question that can be adressed later | |
| 13:31:54 | mriedem | not sure if traits would get us there, traits are the new metadata bastard child | |
| 13:33:12 | openstackgerrit | Tyler Blakeslee proposed openstack/nova master: Use six.text_type instead of str in NovaException __repr__ https://review.openstack.org/559169 | |
| 13:33:16 | jroll | mriedem: yeah, makes sense, thank you | |
| 13:33:47 | sean-k-mooney | mriedem: i think jay would argue this is not a qualitive capablity of the resouce accounting so traits are not the best way but use it would work with traits | |
| 13:34:15 | sean-k-mooney | e.g. custom_rack1 but again that is not user facing | |
| 13:37:31 | mriedem | jroll: i think i get what you meant by "alloc candidates aren't exposed to the user" - in that there is no user-facing compute API to translate a request for node aggregates (in placement) to the nova scheduler | |
| 13:38:34 | cdent | mriedem: traits can take us anywhere we want to go, if we're willing. Such is the danger of traits. | |
| 13:38:52 | finucannot | leakypipes: I was literally just tab completing your name. Morning o/ | |