| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-10 | |||
| 17:10:11 | maciejjozefczyk | mriedem: I'll find it for you ;) bb | |
| 17:10:18 | mriedem | godspeed | |
| 17:11:42 | diga | cdent: | |
| 17:11:49 | diga | cdent: - Here I got the error after adding scenarios - http://paste.openstack.org/show/641294/ | |
| 17:12:26 | diga | cdent: changes are made in git diff - http://paste.openstack.org/show/641293/ | |
| 17:12:28 | cdent | diga: do you have a work in progress that you post up to gerrit so there's code to look at? | |
| 17:13:10 | diga | cdent: I have submit the patch yet, Let me submit the patch then | |
| 17:13:20 | diga | s/have/haven't | |
| 17:14:15 | diga | cdent: yes, I am working on this as per jaypipes suggestions | |
| 17:14:43 | cdent | diga: note that DbDeadLock is already handled, what's not handled is ConcurrentUpdate | |
| 17:15:28 | diga | cdent: okay | |
| 17:15:46 | cdent | _set_allocations method already has the retry handing on it | |
| 17:16:00 | cdent | but it is only set up for handling db api exceptions, which ConcurrentUpdate is not | |
| 17:16:28 | mriedem | sdague: this is the novaclient change for the file injection deprecation and userdata + rebuild stuff https://review.openstack.org/#/c/528128/ - closes out that bp and unblocks the next novaclient change in the series for the next microversion; client release freeze is creeping up so i'd like to get some reviews on this stuff | |
| 17:16:40 | diga | okk, I will work on it then | |
| 17:17:10 | cdent | diga: let me know if/how I can help | |
| 17:17:51 | diga | cdent: currently main challenge in nova is to reproduce the issue, db part is reproduced, but how to reproduce ConcurrentUpdate | |
| 17:18:00 | diga | cdent: some pointers can be helpful | |
| 17:18:03 | mriedem | diga: i have a devstack patch that reproduces it... | |
| 17:18:46 | cdent | diga: I think you can probably do something similar to what you've done in your existing test, but put the side effect on the method that increase the generation | |
| 17:18:46 | mriedem | https://review.openstack.org/#/c/507918/ | |
| 17:19:01 | cdent | diga: _increment_provider_generation | |
| 17:19:41 | diga | cdent: okay | |
| 17:20:07 | diga | mriedem: I will take a look at it | |
| 17:20:47 | mriedem | it's probably not very helpful though for recreating a concurrent update failure in a unit test | |
| 17:21:00 | mriedem | it was just something i think i noticed while investigating failures in that devstack patch | |
| 17:21:14 | diga | mriedem: but it needs to rerun devstack with this change | |
| 17:21:40 | diga | mriedem: ok, got it | |
| 17:29:08 | stephenfin | artom: https://review.rdoproject.org/r/#/c/11283/ | |
| 17:34:37 | diga | mriedem: Thanks for sharing the link, it will be certainly helpful | |
| 17:34:54 | diga | cdent: thanks for your help | |
| 17:35:24 | diga | cdent: mriedem : will ping you if I need any help, will update you by tomorrow | |
| 17:38:25 | cfriesen | mdbooth: sorry, was off in a meeting. Yes, the initial spawn fails when the ephemeral disk is too big. I wonder if we could change the default based on size, to either use something else or just not format it instead of choking. | |
| 17:39:55 | mdbooth | cfriesen: I think it has to be considered part of the api. I think the only change we can make to it without a microversion bump is a minimal change to make it not fail. | |
| 17:40:21 | mdbooth | cfriesen: So we could, for eg, not format it at all, but only in the case that we know it would cause a failure to build. | |
| 17:41:52 | cfriesen | mdbooth: agreed. I'll open a bug and maybe propose a fix. | |
| 18:53:51 | openstackgerrit | melanie witt proposed openstack/nova master: Detach volume after deleting instance with no host https://review.openstack.org/340614 | |
| 18:55:18 | mriedem | stvnoyes: finally got that multiattach snapshot test to pass http://logs.openstack.org/86/531386/7/check/tempest-full/2f25c03/job-output.txt.gz#_2018-01-10_02_15_35_840008 | |
| 18:56:01 | stvnoyes | excellent. I've been working on libvirt 3.10. Finally got past the dependency issues working on getting stack up now | |
| 18:56:33 | mriedem | for the tempest patch, it's getting big, so i might need to think about splitting it up | |
| 18:56:40 | mriedem | mtreinish: how do you feel about this? https://review.openstack.org/#/c/266605/25/tempest/api/compute/volumes/test_attach_volume.py | |
| 18:56:53 | melwitt | is anyone willing to please review the local delete patch ^ if an instance with attached volumes etc goes into error state, when it's deleted the volumes and networks aren't disconnected from the instance and have to be manually disconnected in order to be used again | |
| 18:56:56 | mriedem | should i do the first patch with the config option and 1 test, then add the other tests in subsequent patches? | |
| 19:01:06 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: vSCSI volume driver https://review.openstack.org/526094 | |
| 19:04:02 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add pagination and Changes-since filter support for os-migrations. https://review.openstack.org/330406 | |
| 19:04:03 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add index(updated_at) on migrations table. https://review.openstack.org/531132 | |
| 19:04:03 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Fix comment in MigrationSortContext https://review.openstack.org/532368 | |
| 19:05:31 | ameeda | Hello, when I try to deploy overcloud on baremetal using undercloud "installed at vm" I got this error "No compute node record for host undercloud: ComputeHostNotFound_Remote: Compute host undercloud could not be found." from nova-compute.log file | |
| 19:05:43 | ameeda | what can I do with that ? | |
| 19:10:00 | openstackgerrit | Mark Goddard proposed openstack/nova master: WIP: Send traits to ironic on server boot https://review.openstack.org/508116 | |
| 19:10:00 | openstackgerrit | Mark Goddard proposed openstack/nova master: Add get_traits() method to ComputeDriver https://review.openstack.org/532287 | |
| 19:10:01 | openstackgerrit | Mark Goddard proposed openstack/nova master: Add support to scheduler client for setting traits https://review.openstack.org/532539 | |
| 19:10:01 | openstackgerrit | Mark Goddard proposed openstack/nova master: Call get_traits() in the resource tracker https://review.openstack.org/532290 | |
| 19:10:02 | openstackgerrit | Mark Goddard proposed openstack/nova master: Implement get_traits() for the ironic virt driver https://review.openstack.org/532288 | |
| 19:10:45 | rybridges | Hey guys. Got another question for you today. Is there a way to update the user-data on an instance after it is in the build state during the boot flow? I have a hunch that it is not possible because once the instance is in the build state, the user-data and config driver stuff have already been written out onto the that instance's partition on the hypervisor. Meaning in order to update the user data | |
| 19:10:47 | rybridges | on the instance after it is built, we would need some api capable of modifying user data on the instance. does something like that exist? | |
| 19:19:11 | melwitt | I'm not sure if it's done yet but the plan was to allow user data to be provided during a rebuild | |
| 19:19:25 | rybridges | hmm | |
| 19:19:45 | rybridges | i am talking more from a coding point of view rather than from a user's point of view | |
| 19:19:51 | rybridges | like in the code of the boot flow | |
| 19:20:10 | rybridges | is there a way to update that user data after the instance has already been built | |
| 19:21:04 | rybridges | so for example | |
| 19:22:01 | rybridges | if you update the user data at this point https://github.com/OpenStack/nova/blob/stable/ocata/nova/compute/api.py#L944 | |
| 19:22:09 | rybridges | which is before the instance is actually created on the HV | |
| 19:22:28 | rybridges | then when the instance is actually created on the HV, it will get your user data | |
| 19:22:55 | rybridges | but if you do it after that... I am thinking it wont update because updating would involve rewriting a file on the hypervisor | |
| 19:34:06 | melwitt | rybridges: so you're saying you want to modify the user data after it's been provided by the end user? | |
| 19:34:34 | melwitt | but it's not the end user themselves who want to update it? | |
| 19:35:03 | melwitt | it sounds like what you want is the vendor data stuff | |
| 19:41:34 | melwitt | https://docs.openstack.org/nova/latest/user/vendordata.html | |
| 19:48:49 | rybridges | eh.. not quite. That's okay. Thanks melwitt | |
| 19:52:12 | mriedem | he's looking for the server create hook | |
| 19:52:17 | mriedem | which has been deprecated forever | |
| 20:01:59 | mtreinish | mriedem: what do you want me to look at there? | |
| 20:04:16 | mriedem | mtreinish: so i've got the 3 tests in there passing, | |
| 20:04:26 | mriedem | but, that patch also has some setup stuff so it's getting large, | |
| 20:04:44 | mriedem | was thinking about changing that to just be the first test, and then put 1 patch per new test on top of that in a series | |
| 20:04:58 | mriedem | since there are a bunch of TODOs in there for more tests, i didn't want to hold that single patch for all of the tests | |
| 20:05:23 | mtreinish | mriedem: sure, that sounds like a sane way to handle it | |
| 20:05:26 | mriedem | ok | |
| 20:05:36 | mriedem | just wanted to make sure since it's going to be a bit of work | |
| 20:05:52 | mtreinish | I did quickly look at the tests the other day when you linked me to them and they seemed fine to me | |
| 20:06:22 | mtreinish | mriedem: I mean it's not that long a patch with the 3 tests in one. I'd be fine reviewing it as is too | |
| 20:06:23 | mriedem | the two patches below that one are ready to go | |
| 20:06:29 | mtreinish | it's really your call | |
| 20:06:33 | mriedem | yeah i knew you would probably, but for others | |
| 20:06:35 | mriedem | i'll split it up | |
| 20:06:43 | mriedem | plus then it will rock my tempest stats! | |
| 20:07:00 | mtreinish | heh, got to maintain your top 10 committer status :) | |
| 20:07:09 | mriedem | you know it | |
| 20:08:10 | mriedem | heh i didn't know that was still a thing http://stackalytics.com/?release=all&module=tempest&metric=commits | |
| 20:08:31 | mriedem | soon i can catch up with old man dague | |
| 20:09:30 | mtreinish | mriedem: heh, nice | |
| 20:20:48 | sdague | mriedem: yeh, well... you youngins | |
| 20:20:59 | mriedem | i can hear your fist shaking from here | |
| 20:52:50 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM driver: ovs vif https://review.openstack.org/422512 | |
| 20:53:12 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: SEA https://review.openstack.org/523216 | |
| 20:53:46 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: vSCSI volume driver https://review.openstack.org/526094 | |
| 20:57:20 | mriedem | this was added in 2014: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L1022 | |
| 20:57:26 | mriedem | seems it might be time to remove the get() | |