| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-22 | |||
| 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 | |
| 13:09:59 | sean-k-mooney | sq4ind: well you resocce useage exceed you cappasity currently 175104>122355.0 by a ratio of 1.4 | |
| 13:10:20 | sq4ind | sean-k-mooney, but how: | |
| 13:10:20 | sq4ind | [root@nova0 ~]# free -m | |
| 13:10:20 | sq4ind | total used free shared buff/cache available | |
| 13:10:20 | sq4ind | Mem: 120694 6338 113954 9 402 107727 | |
| 13:10:20 | sq4ind | Swap: 3815 0 3815 | |
| 13:10:21 | sq4ind | ? | |
| 13:10:38 | sean-k-mooney | if the ratio is not set in the RP and is at the default of 1.0 then it would fail with that message | |
| 13:10:48 | sean-k-mooney | free -m show current inuse | |
| 13:10:52 | sean-k-mooney | memory | |
| 13:10:57 | sean-k-mooney | not the reseved memory | |
| 13:11:16 | sean-k-mooney | if you are using kvm it does not preallocate the vm memory and only allocates as guests use it | |
| 13:11:35 | efried | mriedem: I went ahead and made that change -----^ | |
| 13:11:54 | efried | ...and rechecked the devstack side - although there's no way the devstack change fails because of this tweak. | |
| 13:12:04 | sean-k-mooney | sq4ind: what does the hyperviors api say is used on nova0 | |
| 13:12:05 | efried | because now we're both setting and checking the new value. | |
| 13:12:39 | efried | mriedem: I think we'd be looking for the nova patch itself to fail tempest now, because it's using devstack with os_region_name set. | |
| 13:13:07 | mriedem | aye aye | |
| 13:13:17 | sq4ind | sean-k-mooney, | |
| 13:13:19 | sq4ind | | current_workload | 0 | | |
| 13:13:19 | sq4ind | | disk_available_least | 252971 | | |
| 13:13:19 | sq4ind | | free_disk_gb | 492681 | | |
| 13:13:22 | sq4ind | | free_ram_mb | 110067 | | |
| 13:13:26 | sq4ind | | host_ip | 10.252.16.190 | | |
| 13:13:30 | sq4ind | | host_time | 13:12:45 | | |
| 13:13:34 | sq4ind | | hypervisor_hostname | nova0.linguamatics.com | | |
| 13:13:38 | sq4ind | | hypervisor_type | QEMU | | |
| 13:13:44 | sq4ind | | hypervisor_version | 2009000 | | |
| 13:13:48 | sq4ind | | id | 1 | | |
| 13:13:49 | sean-k-mooney | sq4ind: pastbing might be simpler | |
| 13:13:50 | openstackgerrit | Kashyap Chamarthy proposed openstack/nova master: libvirt: Allow to specify granular CPU feature flags https://review.openstack.org/534384 | |
| 13:13:52 | sq4ind | | load_average | 0.10, 0.05, 0.06 | | |
| 13:13:56 | sq4ind | | local_gb | 492834 | | |