Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-03-22
11:27:04 gibi gmann_: left a response and +2 in the review :)
11:33:53 gmann_ gibi: got it, thanks for confirmation
11:39:47 openstackgerrit Zhenyu Zheng proposed openstack/nova master: Noauth should also use request_id from compute_req_id.py https://review.openstack.org/555266
11:39:49 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova master: t https://review.openstack.org/555267
11:39:49 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova master: Add host field to InstanceActionEvent https://review.openstack.org/555146
12:13:06 openstackgerrit Zhenyu Zheng proposed openstack/nova master: WIP https://review.openstack.org/553288
12:16:09 openstackgerrit Raoul Hidalgo Charman proposed openstack/nova master: Expose shutdown retry interval as config setting https://review.openstack.org/552483
12:18:50 openstackgerrit Zhenyu Zheng proposed openstack/nova master: WIP https://review.openstack.org/553288
12:21:27 openstackgerrit Eric Young proposed openstack/nova master: Support extending attached ScaleIO volumes https://review.openstack.org/554679
12:24:23 sean-k-mooney bauzas: o/
12:25:14 openstackgerrit Zhenyu Zheng proposed openstack/nova master: WIP https://review.openstack.org/553288
12:25:47 efried morning nova
12:25:59 sean-k-mooney efried: morning :)
12:27:03 openstackgerrit Matthew Edmonds proposed openstack/nova master: make PowerVM capabilities explicit https://review.openstack.org/547169
12:30:33 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova master: Extract generate_hostid method into utils.py https://review.openstack.org/555282
12:31:02 Spaz-Work Morning daylight novaers
12:31:23 edmondsw efried lost your +1 on https://review.openstack.org/#/c/547169 with a commit message update
12:31:30 efried ...
12:31:42 openstackgerrit Zhenyu Zheng proposed openstack/nova master: WIP https://review.openstack.org/553288
12:31:59 edmondsw since we decided to use specless bps, needed to remove the old bp reference
12:32:00 efried edmondsw: Oh, other drivers do it this way?
12:32:04 edmondsw yep
12:32:06 efried cool.
12:32:12 efried +1
12:32:18 edmondsw tx
12:32:57 edmondsw stephenfin that would be a quick review if you have a minute... https://review.openstack.org/#/c/547169
12:39:09 sean-k-mooney efried: fyi i left some comments on https://review.openstack.org/#/c/554305 last night/30 seconds ago. do you think allowing traits by resouces_class is resonable? not full granular support but just enough to cover 80% of usecases
12:39:16 efried responding right now.
12:39:33 efried sean-k-mooney: done
12:41:06 efried sean-k-mooney: Oh, I missed your 30-seconds-ago comment - we crossed in the mail. Looking...
12:41:30 sean-k-mooney cool reading. an ya im aware 99% of the time traits are specific to resouces classes to you wont get conflicts
12:41:51 efried okay, you brought up a more viable example. Is it possible for GPUs and CPUs to have the same traits?
12:42:15 efried I wonder if it makes sense for us to name those traits differently. HW_CPU_X vs HW_GPU_X
12:42:17 sean-k-mooney efried: ya i think come gpus support sse instructions
12:42:37 efried Be interested to see how jaypipes feels about that.
12:42:38 sean-k-mooney efried: i see pros and cons to that
12:42:41 efried yeah
12:43:30 efried but again, in that case maybe it makes sense to force them to use granular in the flavor for the time being, just so we can defer this discussion and get the majority of the function we need right away.
12:43:39 sean-k-mooney so ya clip notes version i dont think we need GPU1:trait:X=required,GPU2:trait:Y=required in image but gpu:trait:x=required,cpu:trait:y=reqiured would be nice unless we namspace all the traits
12:44:04 sean-k-mooney efried: well images are use creatable but flavors are not
12:44:26 efried Hum. I wonder if that's a problem in and of itself.
12:44:48 efried Aren't we giving the user the power to hog resources now?
12:45:14 sean-k-mooney HW_CPU_X vs HW_GPU_X would "fix" this but we duplicate the traits in some cases
12:45:15 openstackgerrit Zhenyu Zheng proposed openstack/nova master: WIP https://review.openstack.org/553288
12:45:16 sean-k-mooney am no
12:45:26 sean-k-mooney the user can not request a gpu via the image
12:45:55 sean-k-mooney they would have to select a flavor with a gpu as we dont have resaouce request on the image just traits
12:46:08 cdent good morning jaypipes, edleafe, efried: I believe we had some discussions about what counts as a valid uuid recently, I have some related concerns within placement: We save uuids as strings of length 36, but in most (but not all) places we json schema validate incoming uuids to accept both the '-' and not '-' forms. In the dict format of putting allocations we do _not_, we only accept '-'.
12:46:52 efried do we always save them with the hyphens?
12:47:20 efried even if they're sent in without?
12:47:23 cdent efried: as far as I know we dont' process them as uuids, so we take what's given
12:47:39 cdent that's why I'm raising the issue
12:47:53 efried So it'd be possible for me to create e.g. two separate resource providers with UUIDs A-B-C-D-E and ABCDE??
12:47:59 sean-k-mooney cdent: minus is not valide for uuids only hyphens so we should either convert or rais an exception and return a 300
12:48:18 sean-k-mooney efried: both of those would be invalid
12:48:36 sean-k-mooney the asci represention of a uuid is not arbitrary it has a fixed format
12:48:47 cdent efried: That is my concern, yes, but I haven't had a chance to check it yet
12:48:53 efried I'm shorthanding. A{8}-B{4}-C{4}-D{4}-E{12}
12:49:29 efried cdent: Okay, sounds like a thing to do. Should be an easy enough func test to write.
12:49:34 sean-k-mooney efried: ah wel that format requires the hypens
12:50:05 cdent efried: yeah, was just checking in first before digging harder
12:50:49 efried sean-k-mooney: What cdent is saying is that the placement API is allowing either 12345678-ABCD-ABCD-ABCD-12345678ABCD or 12345678ABCDABCDABCD12345678ABCD as inputs, but may in fact be interpreting those as *different* values.
12:51:01 efried ...which would be bad. Like crossing the streams.
12:51:35 sean-k-mooney efried: ya so is placement using ovo for its data sturctures
12:52:36 sean-k-mooney ovo has 2 uuid fields one is a strict check and the other just emits a warnign if the format is invalid. if we use ovo internally in the strict form we can prevent incorrect uuids form getting to the db
12:53:26 sean-k-mooney efried: for the 12345678ABCDABCDABCD12345678ABCD case i would be happy if the api returned a 400 bad request in that case
12:53:46 efried Which we can't do without a new microversion.
12:54:14 sean-k-mooney efried: ya but i would be in favor of a microversion for this
12:54:26 efried Although part of what cdent is about to find out is, even though the schema will pass that, maybe something further down will reject it.
12:55:14 sean-k-mooney efried: well the db field is a varchar(36) so it wont so it would have to be somthing in the python code before it hits the db layer
12:55:17 efried sean-k-mooney: I would too (be in favor of a new microversion to lock this down), but think about it from a consumer standpoint. They don't have to use the new microversion in order to start passing in their UUIDs with hyphens.
12:55:59 efried It'd be kind of weird, like "use this new microversion so you can make sure I'm using hyphens in my UUIDs for me."
12:56:07 sean-k-mooney yes the microversion is just stopping them passing without hypens
12:56:27 efried I sorta doubt consumers will bother with it, considering they would then have to do a 406-and-retry-with-lower-microversion branch.
12:57:04 sean-k-mooney efried: well i gues we need to first check what the behavior is today
12:57:07 efried yuh
12:57:13 efried iiuc, cdent is on that.
12:57:14 sean-k-mooney perhaps we normalise it at some point
12:57:21 efried if we'd just quit bugging him :P
12:58:09 sean-k-mooney :) but if we didnt bug him that would just give him more time to get pulled into internal meetings
12:58:30 cdent this came about because of internal discussions
12:59:10 efried (cdent probably works from home, huh. I'm shouting at his dog.)
13:00:32 cdent no dog, and apparently you weren't loud enough to wake the cat
13:04:11 sq4ind hi guys
13:04:19 sq4ind have a problem after upgrade to queens
13:05:02 sq4ind I cannot live migrate instances, I am getting error on nova-conductor:
13:05:17 sq4ind Setting instance to ACTIVE state.: NoValidHost: No valid host was found. Unable to move instance 220a6584-02ae-4a22-9940-6f64bbb4a1d8 to host nova0 There is not enough capacity on the host for the instance.
13:05:31 sq4ind but there is planty of resources
13:06:06 sq4ind in the placement-api : Over capacity for MEMORY_MB on resource provider 52c0c39e-30f9-4bd8-84e9-af5c35aac61f. Needed: 2048, Used: 175104, Capacity: 122355.0
13:06:32 sq4ind Placement API returning an error response: Unable to allocate inventory: Unable to create allocation for 'MEMORY_MB' on resource provider '52c0c39e-30f9-4bd8-84e9-af5c35aac61f'. The requested amount would exceed the capacity.
13:06:36 sq4ind any idea ?
13:06:51 efried allocation ratio thing?
13:06:57 sq4ind default
13:06:59 sq4ind 1.5
13:07:14 sean-k-mooney sq4ind: did you set allocation in aggregates or on compute node nova.conf
13:07:23 sq4ind on compute
13:07:37 sean-k-mooney sq4ind: oh ok. we broke the aggregate allocation ratios
13:08:38 sean-k-mooney sq4ind: can you share the full resouce provider info for 52c0c39e-30f9-4bd8-84e9-af5c35aac61f
13:08:53 sq4ind it looks like the resources are not being properly updated
13:09:45 openstackgerrit Eric Fried proposed openstack/nova master: Change compute mgr placement check to region_name https://review.openstack.org/554759

Earlier   Later