Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-09-05
15:26:50 mriedem but new requests for scheduling would also fail with NoValidHost
15:27:02 mriedem is the latter something you're OK with?
15:27:11 melwitt tssurya, dansmith: ack for canceling
15:27:17 pvc mriedem i see thank you
15:27:37 pvc can i use to my openstack queens for testing?
15:27:58 mriedem pvc: you can do whatever you want in your local environment
15:31:40 pvc both on controller and compute?
15:34:20 mriedem pvc: that patch only applies to compute
15:37:30 pvc if i push it, the ceph volume extension on fly will be okay also right
15:37:50 openstackgerrit Matt Riedemann proposed openstack/nova stable/rocky: Fix nova-status "_check_resource_providers" check https://review.openstack.org/600098
15:40:55 mriedem pvc: i don't know what that means
15:41:07 mriedem but i also can't speak for this patch because i haven't looked at it in awhile
15:41:18 mriedem if it fixes your bug, and it applies to queens, then i guess you find out
15:42:20 openstackgerrit Matt Riedemann proposed openstack/nova stable/queens: Fix nova-status "_check_resource_providers" check https://review.openstack.org/600101
15:43:27 mriedem naichuans: bauzas: efried: i added an item to the ptg etherpad about the libvirt/xenapi driver implementation for reshaper - my libvirt patch is only written to handle the existing upgrade case of moving a single VGPU inventory class from the root provider to a new child provider, it does not intend to handle multiple child providers for multiple VGPU types b/c we didn't support that yet, so we wouldn't reshape *from* that sc
15:43:27 mriedem io yet
15:43:45 mriedem but i'm worried that maybe there are things to come with multi-vgpu child providers that i'm not appreciating
15:43:57 mriedem although i figured that might be handled with traits?
15:44:23 mriedem if you have multiple vgpu type providers on the same host, they'd be children under the same root with separate traits describing the vgpu type per provider
15:44:45 efried I would think so, yes.
15:46:32 bauzas mriedem: yeah, and I agree with you
15:46:37 bauzas mriedem: that's the comment I said
15:46:54 mriedem ok cool
15:46:59 bauzas mriedem: if we need *more* types, then that's a new change
15:47:15 bauzas for the moment, we only support one, hence your change being good
15:47:26 mriedem bauzas: also, on that libvirt change, i haven't actually tested that with a real system that has vgpu inventory on it
15:47:46 bauzas mriedem: tbh, that's the problem I have, my machine has been passed to another one...
15:47:50 mriedem so if you have a setup like that, or are able to do it quicker than me, that would be great if you could actually make sure this does the needful
15:47:54 mriedem ah
15:48:03 bauzas mriedem: yeah sure, it's just...
15:48:11 bauzas you know, hardware etc.
15:49:56 mriedem i'm sure sean-k-mooney has some hardware that he nabbed from intel on the way out
15:52:19 sean-k-mooney mriedem: unfortunetly not but i have some hardware i bought on ebay
15:52:26 sean-k-mooney what was it in relation too?
15:55:08 mriedem vgpu testing for my reshaper patch
15:57:05 pvc just a quick question mriedem
15:57:25 pvc what release does the cinder volume in-use state extension supported?
15:57:28 sean-k-mooney mriedem: ah unforunetly i dont have any vgpu suff currently.
16:00:01 dansmith mriedem: so do you think we squashed it? http://status.openstack.org/elastic-recheck/#1789484
16:04:15 mgagne Lets say your Ironic instance only has 2 physical nics and you don't want a 3rd interface attached because it just wouldn't work. Would Nova check for this limitation and fail at the API level?
16:05:43 mriedem pvc: let me go back to your original question: https://review.openstack.org/#/c/590188/ will not be backported upstream
16:05:45 mriedem because it's for a feature
16:06:04 mriedem even though it says it's a bug, it's a bug related to implementing a feature
16:06:31 pvc i see thank you :)
16:07:40 mriedem volume extend support was added in pike https://specs.openstack.org/openstack/nova-specs/specs/pike/implemented/nova-support-attached-volume-extend.html
16:08:26 pvc yes but on LVM driver only. for rbd is not yet supported
16:09:01 mriedem sure, that's not a bug though
16:09:36 mriedem more specifically, it's supported for iscsi and fibrechannel volume types
16:09:42 mriedem which is more than just lvm
16:09:58 pvc yes do you have idea when is the implementation for rbd?
16:10:12 mriedem the next patch in that series https://review.openstack.org/#/c/594273/
16:10:27 mriedem but the blueprint isn't approved - it has to be discussed during the weekly nova meeting
16:11:45 pvc i see thank you so much for your time :)
16:15:42 openstackgerrit Matt Riedemann proposed openstack/nova stable/pike: Fix nova-status "_check_resource_providers" check https://review.openstack.org/600113
16:23:30 openstackgerrit Matt Riedemann proposed openstack/nova stable/ocata: Fix nova-status "_check_resource_providers" check https://review.openstack.org/600119
16:32:19 jaypipes mgagne: no, it would not fail at the API level, AFAIK. it would fail during node provisioning in ironic virt driver.
16:33:29 openstackgerrit melanie witt proposed openstack/nova stable/rocky: Make scheduler.utils.setup_instance_group query all cells https://review.openstack.org/599732
16:37:51 openstackgerrit melanie witt proposed openstack/nova stable/queens: Make scheduler.utils.setup_instance_group query all cells https://review.openstack.org/599766
16:50:59 openstackgerrit Merged openstack/nova master: Fix nova-status "_check_resource_providers" check https://review.openstack.org/599875
16:51:05 openstackgerrit Merged openstack/nova master: Fix DB archiver AttributeError due to wrong table name attribute used https://review.openstack.org/599878
16:54:39 mriedem alex_xu: Kevin_Zheng: yikun: replied in https://review.openstack.org/#/c/591976/ re: the changes-since == changes-before debate
16:54:50 mriedem cdent: edleafe: from an API SIG pov you might have input on ^
16:55:04 mriedem would be interesting to know if any other APIs in openstack have filtering capability like that
16:55:34 cdent mriedem: been a while since I looked at that so not caught up on the issues
16:56:06 cdent nova drove the existence of changes-since, yeah?
16:56:07 mriedem the big debate is what to do if changes-since == changes-before
16:56:27 mriedem umm, i'm assuming so...
16:57:35 mriedem glance has some funky filter-based filtering stuff using operators
16:59:53 mgagne jaypipes: I was referring to the attach-interface action, the hotplug feature
17:00:38 mgagne hmm I think I reworded my question before sending, might not have been clear then :-/
17:09:34 openstackgerrit Elancheran S proposed openstack/nova master: Add exact match aggregate image properties matcher/filter https://review.openstack.org/593167
17:10:27 mgagne ok, it seems it would fail on Ironic side with NoFreePhysicalPorts exception which would be mapped to a Bad Request at the Ironic API. This will be mapped to VirtualInterfacePlugException in Nova virt driver. There is a generic try catch in compute manager which will raise InterfaceAttachFailed. And API will map to HTTPInternalServerError
17:11:59 openstackgerrit Elancheran S proposed openstack/nova stable/pike: Add exact match aggregate image properties matcher/filter https://review.openstack.org/599870
17:12:12 sean-k-mooney mgagne: not in all cases. i know cisco added a thing where you can attach more interfaces then avaialble to a ironic system via neutron turnk port extition
17:12:50 mgagne sean-k-mooney: yes, I'm concerned about "flat" networks where there is no trunk involved
17:13:27 mgagne and about the UX in case of failure.
17:13:41 sean-k-mooney one thing i was not aware of and maybe you can clarify. do we today allow you to attach an interface to an ironic node after its deployed?
17:13:49 mgagne yes
17:14:15 sean-k-mooney mgagne: and if we execeed the available interfaces we get an error or silent failure today?
17:15:11 mgagne if you have flat networks, Nova will fail with a 500 error without much information about the reason. This is what I understood from reading the code.
17:15:42 sean-k-mooney and you would like to chage that to a vifplug exception
17:15:55 sean-k-mooney well VirtualInterfacePlugException
17:15:55 mgagne attach/detach for Ironic was added in Pike: https://docs.openstack.org/releasenotes/nova/pike.html#new-features (2nd item)
17:16:27 mgagne sean-k-mooney: it would be a much better UX if the user got a 400 instead of a 500
17:18:13 sean-k-mooney so you want to make it a 400 calls bad request rather then a 500 server error as its an enduser error to try to attach more interface then phyically avaialble
17:18:37 mgagne yes, anything in the 4XX range
17:19:17 mgagne because I don't think it's a server side error from the user perspective
17:19:25 sean-k-mooney i mean that seam reasonable. i think i reivewd or partly reviewd code from you on this topic
17:20:11 mgagne could be 406, 409. I'm not an expert.
17:20:36 mgagne so you are the person I want to be friend with =)
17:21:40 sean-k-mooney im not an expert either but i dont think 409 or 406 is correct
17:22:03 sean-k-mooney 406 is for content type mismatches e.g. server say i speak json and you give it xml
17:22:09 openstackgerrit melanie witt proposed openstack/nova stable/pike: Add functional test for affinity with multiple cells https://review.openstack.org/599840
17:22:10 openstackgerrit melanie witt proposed openstack/nova stable/pike: Make scheduler.utils.setup_instance_group query all cells https://review.openstack.org/599841
17:22:38 sean-k-mooney 409 is for rases e.g. you tried to update something but someone else also did please retry
17:22:47 mgagne so 400 looks fine
17:23:26 mgagne or 402 if you want to make them pay for that feature =)
17:25:00 sean-k-mooney mgagne: i would use 400 or 418 if you are felling exotic or british
17:26:12 sean-k-mooney i would be tempted by 412 but i would have to read rfc 7232 so see if its correct or not
17:26:28 mgagne hehe so my question is how to raise that exception from Ironic to Nova API without losing much details.

Earlier   Later