| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-22 | |||
| 07:18:28 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: add snapshot function https://review.openstack.org/534240 | |
| 07:18:28 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: Spawn and destroy function of z/VM driver https://review.openstack.org/527658 | |
| 07:18:29 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: add get console output https://review.openstack.org/543344 | |
| 07:18:29 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: add power actions https://review.openstack.org/543340 | |
| 07:27:00 | openstackgerrit | Merged openstack/nova master: Add unit tests for EmulatorThreadsTestCase https://review.openstack.org/538699 | |
| 09:06:05 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: Spawn and destroy function of z/VM driver https://review.openstack.org/527658 | |
| 09:06:06 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: add power actions https://review.openstack.org/543340 | |
| 09:06:06 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: add snapshot function https://review.openstack.org/534240 | |
| 09:06:07 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: add get console output https://review.openstack.org/543344 | |
| 09:21:45 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: add snapshot function https://review.openstack.org/534240 | |
| 09:21:46 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: add power actions https://review.openstack.org/543340 | |
| 09:21:47 | openstackgerrit | jichenjc proposed openstack/nova master: z/VM Driver: add get console output https://review.openstack.org/543344 | |
| 09:26:54 | gmann_ | mayur_ind: will be good if you attach logs etc on bug. with 500 it is not possible to check what went wring | |
| 09:37:19 | Kevin_Zheng | gmann_ Hi, could you spare a few minutes and help me with some test issue? I'm working on some functional tests that have to verify the request_id, it seems that the req['openstack.request_id'] is not translated to context.request_id in functional tests, could you tell me where do we generate the context in functional tests? I have difficulties to find it | |
| 09:45:40 | Kevin_Zheng | gmann_ Never mind, I got it | |
| 09:45:59 | gmann_ | Kevin_Zheng: ohk :), in QA meeting which is about to close | |
| 10:11:42 | openstackgerrit | sahid proposed openstack/nova-specs master: virt: allow instances to be booted with trusted VFs https://review.openstack.org/485522 | |
| 10:44:30 | gmann_ | gibi: can you check if all ok from notification wise - https://review.openstack.org/#/c/554090/2 | |
| 10:49:50 | gibi | gmann_: I opened it and I will try to check it today | |
| 11:07:12 | stephenfin | lyarwood: When you're about, any chance you could test the combination of these two patches to see if it resolves your '[pci] passthrough_whitelist' concerns? https://review.openstack.org/#/c/554632/ https://review.openstack.org/#/c/552874/ | |
| 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 | |