| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-11-14 | |||
| 14:38:33 | efried | gibi The test results changed rather dramatically. | |
| 14:38:43 | kashyap | sean-k-mooney: Yeah, bled this morning, trying to shave a yak. | |
| 14:38:49 | efried | gibi The good news is that all the results now at least seem to have the proper resources in them. | |
| 14:39:02 | efried | gibi I think the problems are now limited to crossing aggregates. | |
| 14:39:56 | sean-k-mooney | kashyap: im currently hitting a issue with nova that is proably unrelated to centos to be honest just have not seen it last time i stacked on ubuntu. devstack is not finding the nova compute agent in the cells db and devstack is failing because of this | |
| 14:40:47 | gibi | efried: I feel that is actually a good news. From having multiple problems we managed to go done to one single issue | |
| 14:41:19 | efried | gibi Oh, definitely agree. | |
| 14:41:23 | efried | Just made for a tough rebase :) | |
| 14:42:31 | kashyap | sean-k-mooney: I see, afraid I don't know the cause of it. | |
| 14:42:48 | mriedem | bhagyashris: something probably failed server-side, because nova-compute will upload the image data to glance | |
| 14:44:09 | sean-k-mooney | kashyap: im restacking with reclone=true to make sure eveything is uptodate but basically im seeing openstack --os-cloud devstack-admin --os-region RegionOne compute service list --host silpixa00385232 --service nova-compute -c ID -f value fail. | |
| 14:44:30 | kashyap | sean-k-mooney: In the past 'reclone=true' screwed me up. Let me dig up the reason, I recall writing it down why it's "bad" | |
| 14:44:40 | kashyap | IIRC, it messes up with Git remotes | |
| 14:45:21 | sean-k-mooney | kashyap: hehe i have been using devstack for 4 years i know why it can be bad but in this case its safe enough as it will just do a git pull on all the repos in /opt/stack | |
| 14:45:40 | bhagyashris | mriedem: but there is no optional parameter --file at the time of creation of instance snapshot so thats why the snapshot created at glance is in queued state | |
| 14:45:45 | kashyap | sean-k-mooney: Ah, okay, you're well-scarred then. | |
| 14:46:09 | mriedem | bhagyashris: i think you might be misunderstanding what the nova image-create operation does | |
| 14:46:17 | mriedem | it's not the same as glance image-create and image-upload | |
| 14:46:37 | sean-k-mooney | kashyap: enough so to be imune to the fact it will happliy destroy your system if you dont speak to it firmly form time to time yes | |
| 14:47:00 | kashyap | sean-k-mooney: I use this little ugly script as a 'hook' to update all the repos -- http://paste.openstack.org/show/626273/ | |
| 14:47:10 | kashyap | sean-k-mooney: Heh, indeed | |
| 14:48:57 | sean-k-mooney | kashyap: yes that is basically what reclone=true does in the git_clone fuction https://github.com/openstack-dev/devstack/blob/master/functions-common#L493-L566 but it also support gerrit references,branches and tags | |
| 14:48:58 | bhagyashris | bhagyashris: I will go through nova image-create code | |
| 14:49:07 | kashyap | sean-k-mooney: Yeah, that's why I use a minimal script that uses `virt-builder` that sets up DevStack env from scratch, if I'm taking too much time to debug the darn thing. (Should clean up the script) -- https://kashyapc.fedorapeople.org/virt/openstack/setup-devstack-vm.bash | |
| 14:49:21 | bhagyashris | mriedem: I will go through nova image-create code | |
| 14:49:40 | kashyap | sean-k-mooney: Ah, noted; okay I'll be a bit less fearful of it, and give it a whirl next time | |
| 14:50:05 | mriedem | bhagyashris: nova-api creates an image in glance and then casts to the nova-compute service to actually snapshot the disk and upload the file to glance for the snapshot image, | |
| 14:50:17 | mriedem | so if the image was stuck in queued state forever, something probably failed on the nova-compute side | |
| 14:51:39 | jianghuaw_ | bauzas, jaypipes: are you around? | |
| 14:51:41 | sean-k-mooney | reclone=true is safe, PIP_UPGRADE=ture is not and should be a last resort as it ignores the upper-constriants file | |
| 14:52:51 | jianghuaw_ | bauzas, jaypipes: Have some questions on how to report nested resource providers and traits from drivers. | |
| 14:52:56 | bhagyashris | mriedem: ohh ok. Thank you :) | |
| 14:53:37 | bauzas | jianghuaw: over the phone, sorry | |
| 14:54:09 | jianghuaw_ | bauzas, ok. May chat with you later. | |
| 14:56:22 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Handle InstanceNotFound when setting password via metadata https://review.openstack.org/519659 | |
| 15:00:00 | openstackgerrit | Jianghua Wang proposed openstack/nova master: XenAPI: Unit tests must mock os_xenapi calls https://review.openstack.org/499573 | |
| 15:04:11 | jaypipes | jianghuaw_: just got back. what's up? | |
| 15:05:41 | jianghuaw_ | jaypipes, my problem is how to report the nested resource providers and traits from drivers to resource provider. Should we use the existing get_inventory()? | |
| 15:05:57 | jaypipes | sean-k-mooney: what is stephenfin's opinion? | |
| 15:06:11 | jianghuaw_ | jaypipes, or should we define new interfaces? | |
| 15:06:26 | jaypipes | jianghuaw_: no, we will need to define a new update_inventory() interface to the virt driver API. | |
| 15:06:44 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add FlavorPayload.description for versioned notifications https://review.openstack.org/514782 | |
| 15:06:45 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add microversion to allow setting flavor description https://review.openstack.org/515213 | |
| 15:07:02 | sean-k-mooney | jaypipes: i think he as ok with either version. but stephenfin if you are around maybe you can comment | |
| 15:07:19 | jianghuaw_ | what's the data structure return by update_inventory()? | |
| 15:08:23 | sean-k-mooney | jaypipes: there are two patches from rodolfo that are effect by this. https://review.openstack.org/#/c/487405/ and https://review.openstack.org/#/c/484386/ | |
| 15:08:52 | jaypipes | jianghuaw_: I was thinking a boolean. The update_inventory() would accept a ProviderTree object and the virt driver would update the providers in the ProviderTree appropriately, returning whether anything changed. | |
| 15:09:05 | jaypipes | sean-k-mooney: understood. I will try to get to those today. | |
| 15:10:03 | sean-k-mooney | jaypipes: thanks jay. and no worries it would be good to come to a dession but soon but i also want to make the right one so lets not rush. | |
| 15:10:55 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Validate new image via scheduler during rebuild https://review.openstack.org/519662 | |
| 15:10:55 | jianghuaw_ | jaypipes, so everything is done in driver. resource tracker just trigger the update. right? | |
| 15:12:19 | efried | jaypipes So I'm clear, does ProviderTree include the resources, or just the provider hierarchy? | |
| 15:12:49 | openstackgerrit | Ilya Shakhat proposed openstack/nova master: Initialize osprofiler in uWSGI application https://review.openstack.org/519664 | |
| 15:13:14 | sean-k-mooney | efried: i think the full tree with the resouces. at least that is what i had assumed at the PTG | |
| 15:13:36 | jianghuaw_ | jaypipes, do you have a rough plan on when will start to add the interface of update_inventory()? | |
| 15:13:36 | jaypipes | jianghuaw_: for now, yes, that's the plan. eventually, a generic device manager may also get called... but that's later on. | |
| 15:13:50 | efried | sean-k-mooney That would make sense if the method is called update_inventory | |
| 15:13:55 | jaypipes | efried: no, inventory records are kept in the ProviderTree for each resource class the provider provides | |
| 15:14:24 | jianghuaw_ | jaypipes, just wonder if it's proper time to start n-rp work for vgpu in XenAPI. | |
| 15:16:02 | openstackgerrit | Xuanzhou Perry Dong proposed openstack/nova master: Check for volume size https://review.openstack.org/519666 | |
| 15:16:10 | efried | jianghuaw_ If you do, you'll have to base it on the series in progress, starting at https://review.openstack.org/#/c/377138/ | |
| 15:17:35 | jianghuaw_ | efried, thanks. yes I have been looking at this series of patches. | |
| 15:18:26 | efried | jianghuaw_ But also note that we (jaypipes, alex_xu, me, etc.) haven't yet written the GET /allocation_candidates affordance for nrp. | |
| 15:18:52 | efried | Which could make the scheduling results... unpredictable. | |
| 15:19:56 | jianghuaw_ | efried, I see. I had some testing today. I understood n-rp has not been completed yet. But wonder if we can do things in parallel. | |
| 15:20:14 | sean-k-mooney | efried: is the numbered traits syntax for associating tratis and resouce requests that was discussed at the summit still going ahead for pike. | |
| 15:20:29 | sean-k-mooney | sorry queens | |
| 15:20:40 | efried | jianghuaw_ To some extent, in the sense that more than one person can be proposing patches for the various pieces of functionality; but in this case, they should probably be proposed on that same series. Which can get confusing for rebases. | |
| 15:21:09 | efried | sean-k-mooney Yes, and good progress has been made there. At this point it's stalled waiting for the big refactor series starting at https://review.openstack.org/#/c/516778/ | |
| 15:21:50 | sean-k-mooney | efried: good to hear is the requesting traits via flavours work integrated with this also | |
| 15:21:57 | jianghuaw_ | efried, understood. | |
| 15:22:41 | efried | sean-k-mooney Yes. The code to parse granular resources & traits from flavor extra specs, pass to the scheduler, pass to GET /allocation_candidates, parse in placement from the querystring, and pass to the internal methods - all that is done. | |
| 15:23:15 | efried | sean-k-mooney The remaining piece is to make said internal methods actually Do The Right Thing with that information, which will bump the placement microversion; and then switch on the support from the scheduler side. | |
| 15:23:48 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/pike: Validate new image via scheduler during rebuild https://review.openstack.org/519672 | |
| 15:24:32 | efried | sean-k-mooney You can see that stuff here: https://review.openstack.org/#/q/topic:bp/granular-resource-requests | |
| 15:25:16 | sean-k-mooney | efried: ah ok, so yes good progress is certenly apt. that will make my verified boot friend very happy to hear once i translate it for them. | |
| 15:27:37 | sean-k-mooney | jaypipes: on that note im going to split all the stateful traits into seperate patches. i know currently we do not want to standardies stateful traits so until we come to a dession on how to model the state of capablities ill advise the use of CUSTOM_ traits | |
| 15:30:08 | jaypipes | jianghuaw_: I'd appreciate another week to get more n-r-p stuff merged. | |
| 15:30:32 | jaypipes | sean-k-mooney: there's no such thing as a stateful trait... I'll respond to you on those patches. | |
| 15:31:05 | jianghuaw_ | jaypipes: cool. Thanks. | |
| 15:31:31 | sean-k-mooney | jaypipes: :) i know but without inventing another entity to tag ever resouce provider with and request every where we request a trait im inventing that term untill we have something better | |
| 15:32:20 | sean-k-mooney | jaypipes: but for now ill reduce the scope of those patches to just capabilities with no state implied as you suggesed in the patch reviews previously | |
| 15:32:41 | jaypipes | sean-k-mooney: whether or not a particular trait is applied to a specific resource provider is not relevant to what the trait represents. | |
| 15:32:46 | jaypipes | sean-k-mooney: that's all I'm saying. | |
| 15:33:23 | jaypipes | sean-k-mooney: if a node supports UEFI boot mode, then it supports UEFI boot mode. Whether or not that node is *booted* using UEFI boot mode is entirely a different thing. | |
| 15:34:43 | jianghuaw_ | jaypipes, I'd appreciate if you can have time to review these patches again: https://review.openstack.org/#/c/512965 https://review.openstack.org/#/c/516217/ | |
| 15:34:45 | sean-k-mooney | jaypipes: yep understood traits solves the fomer. i had hoped it could be used to solve the later but if we want to use something else for that then that is fine too so long as we can eventually solve both | |
| 15:41:17 | crlb | Hello jaypipes, can I ask you about change #516796? | |
| 15:41:43 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/ocata: Validate new image via scheduler during rebuild https://review.openstack.org/519681 | |
| 15:41:46 | efried | sean-k-mooney What patches are we talking about? | |
| 15:42:35 | sean-k-mooney | efried: https://review.openstack.org/#/q/status:open+project:openstack/os-traits+branch:master+topic:verified_boot | |
| 15:43:10 | efried | sean-k-mooney Thanks. We had a discussion along these lines with the ironic folks too. Did you see the summary in the ML? | |
| 15:43:29 | sean-k-mooney | efried: also https://review.openstack.org/#/c/514737/ but im less concured about that one but it does better illistrate the type of configuration associated with the capablities that we would like to model eventurally | |
| 15:44:00 | sean-k-mooney | efried: no but i was aware that disscution was going to take place | |
| 15:45:02 | efried | sean-k-mooney Here's the summary -- and there's a link to the video recording if you want to sit through the whole thing (and see costumes): http://lists.openstack.org/pipermail/openstack-dev/2017-November/124200.html | |
| 15:46:24 | sean-k-mooney | efried: oh cool thanks. ya i will try and let it play in the background to get up to speed. that said im not sure how much time i will have on this or any topic going forword | |
| 15:46:53 | efried | understood | |
| 15:49:13 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/newton: Validate new image via scheduler during rebuild https://review.openstack.org/519684 | |
| 15:49:49 | mriedem | dansmith: bauzas: https://review.openstack.org/#/q/I11746d1ea996a0f18b7c54b4c9c21df58cc4714b | |
| 15:50:05 | mriedem | tristanC: any other way you want to advertise this? | |