| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-04-18 | |||
| 15:25:28 | efried | Where's ol mriedem today? | |
| 15:25:29 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Bump MIN_{LIBVIRT,QEMU}_VERSION for "Rocky" https://review.openstack.org/558783 | |
| 15:25:30 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: Drop MIN_LIBVIRT_SET_ADMIN_PASSWD https://review.openstack.org/562312 | |
| 15:25:31 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Drop MIN_LIBVIRT_PARALLELS_SET_ADMIN_PASSWD https://review.openstack.org/562313 | |
| 15:25:35 | gibi | melwitt, efried: I've got the approval today to travel to the Vancouver summit so I can help with the onboarding session | |
| 15:25:43 | efried | cool | |
| 15:26:14 | melwitt | gibi: woot, coolness | |
| 15:26:40 | gibi | melwitt, efried: If you have any material about past onboarding sessions then link it to me so I can try thinkig about what I will talk about there | |
| 15:29:31 | efried | dansmith: Should this return True for the 404 case? https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L1849-L1855 | |
| 15:30:34 | efried | dansmith: I noticed the return value is only checked in this call: https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L3799-L3808 | |
| 15:30:40 | gibi | melwitt: do we plan to have a nova-neutron cross project discussion on the summit? | |
| 15:31:00 | efried | dansmith: So I guess my question is, can/should we still short-circuit there if the instance is already gone? | |
| 15:31:10 | melwitt | gibi: yes, we have this http://forumtopics.openstack.org/cfp/details/124 | |
| 15:31:45 | gibi | melwitt: cool, it even contains the bandwidth topic I wanted to add | |
| 15:32:48 | melwitt | gibi: as for past onboarding session material, I'm not sure anyone has anything saved. last time's session was ad hoc, and the time before I wasn't helping with (I was in the room for only the end of it). dansmith, is there any linkable material from the boston onboarding session that gibi could look at? | |
| 15:32:55 | dansmith | efried: well, does 404 there always refer to the allocation? or could it refer to the RP? | |
| 15:33:27 | dansmith | melwitt: we posted an annotated log of an instance boot in devstack | |
| 15:33:41 | efried | dansmith: It refers to the consumer being gone. | |
| 15:33:47 | dansmith | melwitt: that might still exist, but it's probably worth re-generating it at this point, if you're going to do that same schtick | |
| 15:34:00 | dansmith | efried: you mean the allocation yeah/ | |
| 15:34:35 | gibi | dansmith, melwitt: thanks | |
| 15:34:36 | melwitt | gibi: this time I'm going to try to prepare some slides in case we need them. apparently this is the sort of thing the foundation recommends we do or at least have available if the room is total newcomers https://www.slideshare.net/JayBryant2/openstack-cinder-onboarding-education-boston-summit-2017 | |
| 15:35:16 | efried | dansmith: Looking at what compute manager does after that, it'll try to get that allocation again, and short-circuit out at *that* point. | |
| 15:35:41 | dansmith | efried: tbh, I would still raise a NotFound there instead of returning a boolean, but it should return False, since the code is using that to determine if the other side of the migration was new or not.. "it's already gone" is not what it's checking for | |
| 15:35:43 | efried | dansmith: So the harm is only one redundant placement call (and an info log). | |
| 15:36:20 | dansmith | efried: see above.. this is not just trying to nuke the allocation, it needs to know whether it existed or not | |
| 15:36:26 | cfriesen | efried: I'm thinking of the [glance]/api_servers or [neutron]/url | |
| 15:36:55 | efried | dansmith: Okay. So the report client method is doing the right thing; it's just that that thing is a bit confusing. | |
| 15:37:18 | dansmith | efried: well, like I said, if it raised NotFound there and we were catching it, I think it might be a little more obvious | |
| 15:37:29 | efried | :return: True if the instance's allocations were deleted; False if they were not (which is also the case if the allocations weren't there to begin with) | |
| 15:37:29 | efried | dansmith: The docstring would say: | |
| 15:37:31 | cfriesen | efried: although, I guess those are now optional rather than required | |
| 15:37:38 | dansmith | efried: instead of "did we delete it?" we'd be saying "We deleted it" or "it didn't exist" which is what we're really after | |
| 15:37:59 | efried | cfriesen: Correct. | |
| 15:38:24 | efried | cfriesen: deprecated, in the latter case. In the former case, only use api_servers if you actually *need* multiple endpoints. | |
| 15:38:47 | efried | cfriesen: There was work over the past couple of releases to make that happen. I can find the bp if you like... | |
| 15:39:18 | efried | cfriesen: https://review.openstack.org/#/q/topic:bp/use-ksa-adapter-for-endpoints | |
| 15:39:52 | efried | cfriesen: Note the one that's still open. I would welcome someone jumping in and finishing that one... | |
| 15:39:53 | cfriesen | efried: thanks | |
| 15:41:37 | openstackgerrit | Merged openstack/nova master: Fix docs for confirmResize action https://review.openstack.org/562062 | |
| 15:42:32 | gibi | melwitt: OK. If you need help perparing or reviewing such slideset then I'm happy to help | |
| 15:43:06 | melwitt | thanks | |
| 15:43:07 | openstackgerrit | Nguyen Hai proposed openstack/nova-specs master: Follow the new PTI for document build https://review.openstack.org/551802 | |
| 15:49:36 | arvindn05 | jaypipes: wanted to get your thoughts on role of placement during rebuild | |
| 15:50:07 | openstackgerrit | Nguyen Hai proposed openstack/nova-specs master: Follow the new PTI for document build https://review.openstack.org/551802 | |
| 15:50:59 | openstackgerrit | Nguyen Hai proposed openstack/nova-specs master: Follow the new PTI for document build https://review.openstack.org/551802 | |
| 15:56:31 | jaypipes | arvindn05: currently deep in the middle of teasing apart the @safe_connect decorator from the placement report client... may be some time until I can get to that :( | |
| 15:59:29 | arvindn05 | ahh..ok...will bounce the idea off matt for now :) | |
| 16:17:42 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Deduplicate notification samples Rocky - 7 https://review.openstack.org/560748 | |
| 16:42:02 | openstackgerrit | Jay Pipes proposed openstack/nova master: mock utils.execute() in qemu-img unit test https://review.openstack.org/562339 | |
| 16:44:27 | openstack | bug 1764556 in OpenStack Compute (nova) ""nova list" fails with exception.ServiceNotFound if service is deleted and has no UUID" [Undecided,Fix released] https://launchpad.net/bugs/1764556 | |
| 16:44:27 | cfriesen | melwitt: had a thought on bug 1764556. If we deleted the compute node, recreated it, and migrated the instance back prior to the upgrade to Pike I think we could end up with the DB in the problem state. On the other hand, that seems like a pretty unlikely scenario. | |
| 16:47:50 | melwitt | cfriesen: what would be the full sequence there? sorry, I forgot what the original sequence was regarding deleting of the service, migration, re-create service, migrate etc | |
| 16:48:24 | cfriesen | melwitt: boot instance, migrate instance, delete compute node, create new compute node with same name, migrate instance to new compute node, upgrade to pike | |
| 16:50:49 | melwitt | okay. does seem unlikely but I wouldn't be surprised if someone someday would happen to do it | |
| 16:54:04 | cfriesen | melwitt: our local solution is to modify the online data migration in pike to put uuids on deleted services | |
| 16:54:30 | openstackgerrit | Merged openstack/os-vif master: Add lower-constraints job https://review.openstack.org/556056 | |
| 16:55:32 | melwitt | ack | |
| 16:56:24 | phuongnh | hi all, I would like to add one more line in file https://review.openstack.org/#/c/462759/3/os_traits/hw/cpu/x86.py for CPU_FPGA | |
| 16:56:44 | phuongnh | the link to this cpu type is: https://en.wikipedia.org/wiki/Field-programmable_gate_array | |
| 16:56:51 | bmace | does anyone know or have any pointers to why stable/queens global-requirements is pinned to version 9.1 of python-novaclient when 10.1 seems to be the queens version of python-novaclient from what I can see? | |
| 16:56:56 | phuongnh | Do I need to propose a blueprint in launchpad? | |
| 16:57:45 | melwitt | jaypipes: what's the procedure for proposing a new cpu type to os-traits? ^ | |
| 16:58:28 | jaypipes | phuongnh: that's not a CPU type. | |
| 16:58:48 | jaypipes | melwitt: the procedure to add any trait is simply to propose a patch to os-traits. | |
| 16:58:57 | jaypipes | melwitt: the issue here is that CPU_FPGA isn't a trait. | |
| 16:59:15 | melwitt | thanks | |
| 16:59:27 | phuongnh | thanks jaypipes | |
| 17:01:28 | melwitt | bmace: I think there was a problem with 10.1 not working with queens openstackclient. I have to look to see where/how that was noted (probably in some review somewhere) | |
| 17:02:46 | bmace | melwitt: if you have more info or it was just certain projects that would be very helpful. i think without it there are some issues getting multi-attach to work correctly through heat. | |
| 17:04:40 | melwitt | bmace: okay, let me look into it and get back to you. I think mriedem might be able to point to some details about it but he's not around at the moment | |
| 17:05:14 | bmace | melwitt: sure thing, thanks very much for your time looking into it. | |
| 17:24:20 | openstackgerrit | sahid proposed openstack/nova master: compute: introduce cpu_shared_set option https://review.openstack.org/561912 | |
| 17:48:29 | cfriesen | melwitt: bmace: I think this might be it: https://review.openstack.org/#/c/538070/ | |
| 17:49:18 | melwitt | cfriesen: looks like it, thank you | |
| 17:50:32 | bmace | cfriesen: melwitt: thanks much. interesting comment from matt. i'm pretty sure there are issues with multi-attach through heat not working without the 10.x novaclient | |
| 17:51:12 | melwitt | yeah, I'm wondering what in 10.0.0 is required for multi-attach | |
| 17:53:19 | bmace | melwitt: i'll chat with the person that was investigating the issue and get some more details. i think i recall it being at least in part related to the microversion or some such. | |
| 17:55:18 | melwitt | bmace: okay. yeah, the client itself has a version range it supports, maybe that's the missing piece. the microversion needed for multi-attach might have been added in 10.0.0, so even though there might not be anything else special in the client needed about it, the fact that 9.1.1 can't send the required microversion could break it. we have to look at it | |
| 17:55:54 | bmace | melwitt: i think that was the issue, and from what i recall the microversion may not have been right until 10.1 | |
| 17:56:36 | melwitt | guh, okay. I'm not immediately sure what we can do about this. I'm not sure if we could just bump the microversion in a 9.1.2 to deal with this | |
| 17:57:23 | bmace | right, and trying to bump up the global-requirement to 10.1 back in stable queens might be a bigger change than people are comfortable with. | |
| 17:58:04 | melwitt | yeah. I don't know the details around why osc couldn't work with 10.1.0 and what it would take to make it work. or the other way around, how we could get 10.1.0 to work with osc | |
| 17:58:15 | melwitt | but that's another angle to look at | |
| 17:58:49 | bmace | from what i saw in the review it seemed like the only reason the requirement wasn't approved was because matt said it wasn't needed? | |
| 17:59:25 | bmace | oh, nevermind, reading through that link to the january mailing list now where there was some reported breakage | |
| 17:59:35 | melwitt | yeah | |
| 18:01:04 | melwitt | from the comments, it sounds like it's fixable, just that it wasn't going to make it in time for queens and also it was thought nothing requires >= 10.0.0 in queens | |
| 18:01:22 | melwitt | *fixing osc wasn't going to make it in time for queens | |
| 18:02:04 | melwitt | but if the latter isn't really true, we could fix it, AFAIK | |
| 18:03:03 | bmace | sure, it comes down to how much people actually want multi-attach to work in queens. | |
| 18:03:13 | melwitt | fix osc, release osc, bump the queens requirement. I want to check with mriedem to see if that's the best way forward or if there's another solution | |
| 18:03:34 | bmace | sounds good, thanks again. | |
| 18:03:41 | melwitt | we definitely want multi-attach to work in queens. just a matter of how to go about fixing it | |
| 18:04:04 | melwitt | thanks for letting us know about this problem | |
| 18:04:16 | bmace | sure thing! :) | |
| 18:25:43 | openstack | bug 1764556 in OpenStack Compute (nova) ""nova list" fails with exception.ServiceNotFound if service is deleted and has no UUID" [Undecided,New] https://launchpad.net/bugs/1764556 | |
| 18:25:43 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add functional recreate test for bug 1764556 https://review.openstack.org/562041 | |
| 18:58:41 | openstackgerrit | melanie witt proposed openstack/nova master: Make scheduler.utils.setup_instance_group query all cells https://review.openstack.org/540258 | |
| 18:59:53 | melwitt | dansmith: updated to scope the query only for targeted cell for move operations, else scatter-gather ^ | |