| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-06 | |||
| 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/ | |
| 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 | |
| 14:14:47 | mriedem | and if it's fairly nebulous we don't really know how anyone is using it | |
| 14:15:02 | cdent | traits are part of the (immutable?) api of placement | |
| 14:15:08 | cdent | so how it is used in placement is stuck | |
| 14:15:16 | cdent | how it is used in nova, though, that's different | |
| 14:15:33 | mriedem | with microversions the placement api isn't immutable | |
| 14:15:34 | cdent | (not disagreeing with you) | |
| 14:15:43 | mriedem | but yes i don't expect how placement handles traits to change much | |
| 14:15:50 | cdent | it is in the sense that we'll never raise the minimum | |
| 14:15:54 | mriedem | and yes how they are incorporated into nova is the messy part | |
| 14:16:08 | mriedem | or could be messy | |
| 14:16:27 | mriedem | right now traits-based scheduling from queens is pretty straight forward | |
| 14:16:48 | mriedem | 'put me on a host with trait=foo, got it' | |
| 14:22:30 | mriedem | mmedvede: i got a pkvm ci failure setting up devstack here https://dal05.objectstorage.softlayer.net/v1/AUTH_3d8e6ecb-f597-448c-8ec2-164e9f710dd6/pkvmci/nova/20/324720/5/check/tempest-dsvm-full-xenial/b59cb03/devstacklog.txt.gz | |
| 14:22:41 | mriedem | Connecting to cirros-builder.novalocal (cirros-builder.novalocal)|9.114.111.40|:80... failed: No route to host. | |
| 14:23:26 | mriedem | jgwentworth: fyi, i had emailed the virtuozzo team about their CI failing at least a week ago, so it's a known issue | |
| 14:23:42 | mriedem | ImagePropertiesFilter always kicks out whatever their trying to use for an image | |
| 14:25:55 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Skip placement on rebuild in same host https://review.openstack.org/546357 | |
| 14:33:15 | odyssey4me | howdy everyone, thanks again for your help so far - we have an upgrade task failing which might be due to new changes in rocky... would this be a change in something that needs to happen? http://logs.openstack.org/78/558078/2/check/openstack-ansible-upgrade-ubuntu-xenial-nv/3dc2358/logs/ara-report/result/b9fe5b27-00e6-455b-9a10-71b2046663c5/ | |
| 14:33:33 | edmondsw | fyi, someone is trying to add suppz support to the libvirt driver, but seems to be doing that off on their own | |
| 14:33:36 | edmondsw | https://ask.openstack.org/en/question/113484/add-support-for-a-new-driver-in-nova/ | |
| 14:33:45 | edmondsw | I tried to point them in the right direction | |
| 14:34:29 | jgwentworth | mriedem: okay, so virtuozzo CI currently broken and being worked on | |
| 14:36:13 | mriedem | lyarwood: so in https://review.openstack.org/#/c/544238/4/nova/virt/libvirt/driver.py we also can't do the swap if both volumes are encrypted? | |
| 14:36:52 | mriedem | jgwentworth: it's a known issue, i'm not sure how actively they are working to fix it | |
| 14:38:17 | mriedem | odyssey4me: that looks like the new 'disabled' colum in the nova_api.cell_mappings table, has the nova_api db been synced before running this? | |
| 14:38:27 | lyarwood | mriedem: correct | |
| 14:38:48 | mriedem | tssurya: ^ | |
| 14:39:53 | odyssey4me | mriedem well, that's a queens to rocky upgrade, so yes - it was done in the queens deployment | |
| 14:40:18 | kashyap | lyarwood: Probably that should point also be documented as a note in the code? (With current limitations.) | |
| 14:40:27 | mriedem | odyssey4me: if you're upgrading to rocky and you already created the cell0 mapping in queens, you don't need to do it again | |
| 14:41:25 | mriedem | odyssey4me: although, map_cell0 should be smarter, it has a check for DBDuplicateEntry for running it when it already exists | |