| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-06 | |||
| 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 :) | |
| 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/ | |
| 13:38:56 | jroll | mriedem: yes, exactly. maybe there's a new api eventually, maybe instance groups affinity moves to use placement aggregates, maybe it's traits. dunno, need to think about it | |
| 13:39:13 | finucannot | leakypipes: Does this sound like something you could tackle today? https://review.openstack.org/#/c/553072/ | |
| 13:39:30 | mriedem | jroll: yeah, needs some thought - gut feeling is traits isn't the answer here | |
| 13:39:34 | jroll | agree | |
| 13:39:36 | mriedem | munging aggregates with traits i mean | |
| 13:39:54 | mriedem | cdent: yes that's readily apparent already :) | |
| 13:40:03 | mriedem | bbiab | |
| 13:40:54 | cdent | jroll: meh, if people want that kind of rope, maybe that's what the rope should do? | |
| 13:41:05 | jroll | cdent: not when they leave me to clean up the mess :P | |
| 13:41:14 | cdent | traits are effectively the same thing as labels in k8s, aren't they? | |
| 13:41:15 | jroll | I mean my specific downstream, to be clear :) | |
| 13:41:32 | cdent | that's a good point. If it's you on the hook to suffer, slap away | |
| 14:02:39 | leakypipes | finucannot: morning sir! :) | |
| 14:11:32 | kashyap | mriedem: I think you're the closest to ACK this: https://review.openstack.org/#/c/544238/ ("libvirt: Block swapping to an encrypted volume when using QEMU to decrypt") | |
| 14:11:39 | kashyap | Trivial diff-stat, though. | |
| 14:14:30 | mriedem | cdent: the other thing with giving that rope is people build solutions off it, and then when the time comes that we want to change anything related to it, we break those solutions | |