| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-19 | |||
| 18:01:07 | openstackgerrit | Matthew Booth proposed openstack/nova master: Fix libvirt volume tests passing invalid disk_info https://review.openstack.org/529328 | |
| 18:01:07 | openstackgerrit | Matthew Booth proposed openstack/nova master: Pass disk_info dict to libvirt_info https://review.openstack.org/529329 | |
| 18:01:08 | openstackgerrit | Matthew Booth proposed openstack/nova master: Expose volume host type and path independent of libvirt config https://review.openstack.org/530786 | |
| 18:01:09 | openstackgerrit | Matthew Booth proposed openstack/nova master: Don't generate fake disk_info in swap_volume https://review.openstack.org/530787 | |
| 18:01:09 | openstackgerrit | Matthew Booth proposed openstack/nova master: Local disk serial numbers for the libvirt driver https://review.openstack.org/529380 | |
| 18:15:36 | lyarwood | mdbooth: ack, I might rewrite both tests using the conf objects and format_dom calls | |
| 18:38:02 | openstackgerrit | Jim Rollenhagen proposed openstack/nova master: Ironic: negotiate microversion to allow downgrade to Pike https://review.openstack.org/535786 | |
| 19:13:34 | cfriesen | found an interesting glance/nova interworking issue. if doing a snapshot, and cinder/glance are both on ceph, nova tries to shortcut the snapshot then set the location in glance. But by default glance won't let you set the location of an image, so this fails. | |
| 19:16:09 | cfriesen | correction, not cinder, but when instance backend is ceph. | |
| 19:57:39 | cburgess | cfriesen Sounds like nova is doing the right thing but glance just isn't configured properly. Sounds like maybe a release note or something is needed? | |
| 19:57:54 | cburgess | cfriesen I suspect cinder will run into the same issue. | |
| 20:22:17 | fried_rolls | you gotta be effin kidding me. The bottom three patches, all +W'd, got zuul -1 with (three *different*) spurious failures. The fourth patch - the first one with a -1 - passed. | |
| 20:24:05 | openstackgerrit | OpenStack Proposal Bot proposed openstack/nova master: Updated from global requirements https://review.openstack.org/535919 | |
| 20:25:32 | ildikov | fried_rice: mine got a time_out error on the gate, sooo close, but no... | |
| 20:26:46 | fried_rice | Boo. I feel your pain. | |
| 20:43:30 | fried_rice | figleaf regarding https://review.openstack.org/#/c/526540/17/nova/scheduler/client/report.py@390 -- the only possible reason I can see for it having been split out before was LOG.warning vs .error. | |
| 20:43:59 | fried_rice | figleaf But given that the error text is (at least) as descriptive as what was there before, are you cool with it? | |
| 20:55:35 | openstackgerrit | Ihar Hrachyshka proposed openstack/nova master: DNM testing whether lib/neutron switch breaks this repo https://review.openstack.org/535947 | |
| 21:02:27 | cfriesen | cburgess: I've been diving down into the rathole of the nova/glance interaction. turns out glance's policy stuff is all mucked up, so that enabling nova's snapshot in this case requires glance to be configured insecurely. It might be possible to use service tokens to fix it, but nova doesn't send them by default. | |
| 21:02:39 | cfriesen | speaking of which...anyone know why send_service_user_token is False by default? | |
| 21:03:19 | cfriesen | cburgess: the glance folks suggested a workaround of a separate glance node that is configured less secure, which is only accessible by other openstack components. kind of icky if you ask me. | |
| 21:08:02 | figleaf | fried_rice: It just seemed like a bigger behavior change than it set out to be | |
| 21:08:13 | figleaf | fried_rice: it's not a showstopper by any stretch | |
| 21:08:20 | fried_rice | coolcool. | |
| 21:09:58 | leakypipes | fried_rice: k, your patches are now reviewed up to the WIPs. | |
| 21:10:11 | fried_rice | leakypipes Thanks dude. Starting to work through 'em. | |
| 21:10:17 | leakypipes | yup, np | |
| 21:11:52 | openstackgerrit | Matthew Edmonds proposed openstack/nova master: Fix bad autospec usage https://review.openstack.org/535806 | |
| 21:15:21 | edmondsw | claudiub ^ fixed a pep8 error. Interested in how you feel about that patch | |
| 21:16:20 | edmondsw | I'm not against using the fixture you got in oslotests if the performance is better, but this might be quicker to merge and doesn't preclude your changes coming later | |
| 21:16:44 | edmondsw | doesn't have a significant performance impact at this small scale that I've detected | |
| 21:20:26 | edmondsw | cfriesen send_service_user_token is False by default simply because you have to configure credentials for that to work | |
| 21:21:06 | edmondsw | I'd like for send_service_user_token to go away, and just have the code detect whether it has credentials or not and use that as the determining factor, but that's a nit | |
| 21:22:37 | openstackgerrit | Hongbin Lu proposed openstack/nova master: Handle RPC timeout on get_console_output https://review.openstack.org/525335 | |
| 21:28:03 | cburgess | cfriesen Thats very icky, especially considering that its worked this way for a while (the nova side I mean). | |
| 21:28:20 | cburgess | nova merged this stuff shortly after Tokyo | |
| 21:37:56 | cfriesen | cburgess: I think it might be related to the glance v1/v2 stuff | |
| 21:38:06 | cburgess | cfriesen Hmm yeah I think you might be right. | |
| 21:59:39 | openstackgerrit | Jim Rollenhagen proposed openstack/nova master: Ironic: negotiate microversion to allow downgrade to Pike https://review.openstack.org/535786 | |
| 23:00:00 | fried_rice | leakypipes Still around? | |
| 23:04:19 | fried_rice | leakypipes Cancel, I see it now. | |
| 23:28:24 | openstackgerrit | Eric Fried proposed openstack/nova master: Raise on API errors getting aggregates/traits https://review.openstack.org/526540 | |
| 23:28:24 | openstackgerrit | Eric Fried proposed openstack/nova master: ProviderTree.populate_from_iterable https://review.openstack.org/520756 | |
| 23:28:25 | openstackgerrit | Eric Fried proposed openstack/nova master: Track tree-associated providers in report client https://review.openstack.org/526541 | |
| 23:28:25 | openstackgerrit | Eric Fried proposed openstack/nova master: SchedulerReportClient.set_aggregates_for_provider https://review.openstack.org/533808 | |
| 23:28:26 | openstackgerrit | Eric Fried proposed openstack/nova master: report client: get_provider_tree_and_ensure_root https://review.openstack.org/521098 | |
| 23:28:26 | openstackgerrit | Eric Fried proposed openstack/nova master: ComputeDriver.update_provider_tree() https://review.openstack.org/521187 | |
| 23:28:27 | openstackgerrit | Eric Fried proposed openstack/nova master: SchedulerReportClient._delete_provider https://review.openstack.org/535463 | |
| 23:28:27 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: SchedulerReportClient.update_from_provider_tree https://review.openstack.org/533821 | |
| 23:28:28 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Use update_provider_tree from resource tracker https://review.openstack.org/520246 | |
| 23:28:28 | openstackgerrit | Eric Fried proposed openstack/nova master: Fix nits in update_provider_tree series https://review.openstack.org/531260 | |
| 23:28:29 | openstackgerrit | Eric Fried proposed openstack/nova master: Move refresh time from report client to prov tree https://review.openstack.org/535517 | |
| 23:50:14 | Spazmotic | Hrm. | |
| 23:50:40 | fried_rice | Do tell | |
| 23:50:49 | Spazmotic | Just reading over what leaky said | |
| 23:51:07 | fried_rice | Yeah, I still think there's a hole there. | |
| 23:51:16 | fried_rice | I meant to put it on the PTG agenda, but I think I forgot. | |
| 23:51:20 | fried_rice | ... | |
| 23:51:59 | Spazmotic | https://github.com/openstack/nova/blob/master/nova/api/openstack/placement/handlers/allocation.py#L335-L343 | |
| 23:52:24 | Spazmotic | This is what I see.. It's if the set allocations POST call doesn't receive any data, it pulls all the consumers allocations that exist and runs allocation.used = 0 | |
| 23:52:28 | fried_rice | Spazmotic You going to be at the PTG? | |
| 23:52:44 | Spazmotic | Nah i'll be in Korea and honestly i think i'm too new to the scene to cause a fuss :D | |
| 23:53:08 | Spazmotic | I will re-read the code tonight, maybe I just don't understand it properly | |
| 23:55:33 | fried_rice | Spazmotic Oh, and the other thing was a way to add/update/delete individual pieces of allocation rather than the whole payload. | |
| 23:55:42 | fried_rice | Spazmotic I'm not sure there's really a good use case for that. | |
| 23:55:54 | fried_rice | ...IF we have proper concurrency management | |
| 23:56:25 | fried_rice | The amount of data just isn't that onerous. And you'd want to have the existing allocation before you tried sending an update anyway. If for no other reason than to have the current generation :) | |
| 23:56:48 | Spazmotic | Hmm. I guess I can understand that to ensure no double allocations. | |
| 23:57:59 | Spazmotic | I think the only use case that I could think of immediately was the ability to manage the allocations of a resource provider without having to touch multi-tenant full libraries of allocations, which just feels a bit top heavy for that ability. But without a redesign of how taht works it seems unavoidable for the immediate future. | |
| #openstack-nova - 2018-01-20 | |||
| 00:00:46 | Spazmotic | I will head to the gym and think on it. Poor brain. | |
| 00:00:58 | fried_rice | Spazmotic You don't have to muck with allocations for anything other than the single consumer you're dealing with. | |
| 00:01:32 | Spazmotic | Well my brain was on something like data-loss scenarios for resource providers and there is no current way to clear out a resource provider and avoid the stuck allocations. | |
| 00:01:55 | fried_rice | Data loss like how? | |
| 00:01:57 | Spazmotic | For something like large cinder hosts later, or even large compute nodes, the ability to remove those resource allocations to free up the usages for the tenant | |
| 00:02:16 | Spazmotic | Well data_loss is a bit of a specific term, but even a compute_node going down with no intention to ever return | |
| 00:02:25 | Spazmotic | Or going down to be headshot and coming back up empty and fresh | |
| 00:02:45 | fried_rice | Okay, yes, one can imagine some kind of healing periodic task that goes through all consumers in placement and makes sure they still exist in the world. If not, delete their allocations. | |
| 00:03:17 | fried_rice | But there's nothing about the API, current or imagined, that's going to help with the intricacies of that scenario. | |
| 00:04:15 | Spazmotic | I'm not sure if a self heal would be able to detect it really, the only idea that my brain could grasp at is a manual call to empty a reserve host. The only way I could see a self heal identifying that is if you set a timeout for a RP to come back online or wipe it out, which seems dangerous :D | |
| 00:05:21 | fried_rice | Right you are. No universally good solution there. | |
| 00:05:58 | Spazmotic | Thanks for the morning discussion man.. i gotta get moving and get to the gym | |
| 00:25:41 | Spazmotic | oh.. and resizing allocations would be a nice usecase for that ability as well I think. I think right now you're correct that the amount of allocations would not be too bad to manage, but I was more thinking in a future of Placements being its own product. You could easilly start to see tenant allocations pushing 10,000+ which seems a bit heavy for every time small allocation changes would need to be made, like | |
| 00:25:41 | Spazmotic | changing the resource values of a single allocation. | |
| 00:25:53 | Spazmotic | whew... alright that's enough placement insanity i need some wine this weekend to make myself stop thinking hehehe | |
| 00:28:22 | fried_rice | Spazmotic Drinking sounds like a good plan. But I am curious to know what kind of scenario would have a *single* consumer with tens of thousands of allocations. | |
| 00:30:50 | fried_rice | I need to bail now too, but I'm interested in continuing this conversation. Have a good weekend. | |
| 00:57:38 | alex_xu | sean-k-mooney: yea, I assume granular request needs more magic sql to be done, that is hard to finish in this release. so supporting single request group first | |
| 02:08:46 | openstackgerrit | Brianna Poulos proposed openstack/nova master: Add trusted_certs object https://review.openstack.org/489408 | |
| 02:08:46 | openstackgerrit | Brianna Poulos proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204 | |
| 02:48:02 | openstackgerrit | Merged openstack/nova master: Pass multiattach flag to reserve_block_device_name https://review.openstack.org/531244 | |
| 02:48:10 | openstackgerrit | Merged openstack/nova master: ProviderTree.data => ProviderData https://review.openstack.org/533244 | |
| 02:48:20 | openstackgerrit | Merged openstack/nova master: SchedulerReportClient.set_traits_for_provider https://review.openstack.org/532564 | |
| 04:08:41 | Spazmotic | Will try to spend tonight learning more about semaphores for concurrency avoidance.. | |
| 04:14:31 | Spazmotic | oslo hurts me | |
| 13:45:11 | Spazmotic | Busy day.. no coding today.. talk you all tomorrow | |
| 14:48:28 | efried | mgoddard set_traits_for_provider has merged FYI | |
| 17:44:09 | openstackgerrit | Michael Bayer proposed openstack/nova master: Generalize DB conf group copying https://review.openstack.org/484908 | |
| 20:47:44 | openstackgerrit | Brianna Poulos proposed openstack/nova master: Add trusted_image_certificates to REST API https://review.openstack.org/486204 | |
| 22:10:44 | openstackgerrit | Merged openstack/nova master: Updated from global requirements https://review.openstack.org/535919 | |
| 22:27:38 | openstackgerrit | Merged openstack/nova master: Track associated sharing RPs in report client https://review.openstack.org/526539 | |