Earlier  
Posted Nick Remark
#openstack-nova - 2018-01-10
17:08:49 mriedem maciejjozefczyk: that's because it pulls the object from the db and runs it through ComputeNode._from_db_object which sets the 'default' allocation ratios (hardcoded in code) if not set in config
17:08:59 mdbooth cfriesen: When the ephemeral disk is too big, does the mkfs choke causing the spawn to fail?
17:09:14 maciejjozefczyk mriedem: I'll check it tomorrow why then it is changed to 0
17:09:25 maciejjozefczyk mriedem: thats the real cause, yes?
17:09:51 mriedem yeah i don't know what is changing it to 0.0 before we hit placement
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

Earlier   Later