Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-08-14
16:48:04 dansmith dtantsur: I don
16:48:13 vdrok dtantsur: hrm, so it seems we'll have vcpus=0 and vcpus_used=something during deployment
16:48:28 dansmith dtantsur: don't really know what the whole PATCH thing is, nor the behavior of node.properties
16:48:30 dtantsur vdrok: this has to be fixed, but that's not the biggest problem
16:48:47 dtantsur dansmith: this is where we take inventory from. tl;dr it can be changed from API at any moment
16:49:59 dansmith dtantsur: by the admin yes?
16:50:02 dtantsur yes
16:50:21 dansmith dtantsur: so ironic discovers it but admin can override?
16:50:21 dtantsur it's not even absolutely crazy: they can power the instance down, and install more RAM in it..
16:50:33 dtantsur dansmith: the admin sets it initially, but they can change it
16:51:29 vdrok dtantsur: also if we'll be reporting the resources as used if vcpus=0 in get_inventory, does it mean we'll be doing for maintenance'd nodes too?
16:52:19 vdrok ditto for bad power state
16:52:28 dtantsur yes, this is fine
16:52:38 dtantsur we're mostly concerned about reporting wrong inventory for active nodes
16:54:09 vdrok but then, even if it changes, this is all a part of the same periodic task? like, properties changed, _node_resource sees new value, and uses it in get_inventory
16:54:23 vdrok *and it gets used in
16:55:51 dtantsur right, and the Placement sees free resources to schedule on >_<
16:56:13 dtantsur may be not a huge deal, unless the change all of cpus, memory and disk at the same time
16:56:32 dansmith dtantsur: well, it's not a problem at all once RC is in place right?
16:56:48 dtantsur dansmith: as long as all flavors are using it - yes
16:57:12 dtantsur maybe I should not worry about it too much. just document it as a known issue..
16:57:38 dansmith known issue, which goes away in queens when we require RC for all ironic scheduling
16:57:59 dtantsur right, yeah
16:58:52 dtantsur dansmith: it is fine if my changes will affect get_available_resources result too? I'm not sure what it is for
16:59:03 dtantsur and how it is related to get_inventory
16:59:14 dansmith get_inventory will override the other, AFAIK
16:59:35 dtantsur ah, good
17:08:03 openstackgerrit Chris Dent proposed openstack/nova master: Reset client session when placement endpoint not found https://review.openstack.org/493536
17:08:34 cdent gibi, jaypipes, edleafe ^ finally a test for that. much more boring than original plan, but gets the main
17:18:07 openstackgerrit Ghanshyam Mann proposed openstack/nova master: Update api doc with latest updates in api framework https://review.openstack.org/493041
17:19:39 gmann alex_xu: ^^ update api framework doc, some part i will fix in part2 where i ll mention way to add API step by step
17:20:08 gmann alex_xu: i think once this is merged we should add this in pike also.
17:20:41 gmann this is release wise doc and it should be sync with code for pike repo
18:00:18 cdent gmann: did something change to cause the across the board failures in gate but not check in https://review.openstack.org/#/c/489754/
18:08:02 gmann cdent: ah yea, this got merged before -https://review.openstack.org/#/c/491591/
18:08:18 gmann cdent: we moved is_scheduler_filter_enabled from test.py to common
18:08:33 gmann cdent: if you can change that, i can reapprove
18:08:41 cdent yeah, will do, thanks gmann
18:08:54 gmann same way like https://review.openstack.org/#/c/491591/2/tempest/scenario/test_security_groups_basic_ops.py
18:08:58 gmann cdent: thanks
18:14:34 cdent gmann, done. not tested locally, but I think I got it right
18:15:00 gmann cdent: sure, ll check
18:15:04 gmann thanks
18:18:11 cdent dansmith can you re+W this: https://review.openstack.org/#/c/480924/ Andreas says it’s stuck and needs that
18:18:15 cdent please and thank you
18:26:11 cdent thanks melwitt! hadn’t realized you were around
18:27:12 melwitt np
18:53:46 mnaser cdent https://bugs.launchpad.net/nova/+bug/1661360 is this considered resolved in master now? im asking because i am wondering if its good to drop https://github.com/openstack/puppet-nova/blob/master/manifests/wsgi/apache_api.pp#L113
18:53:47 openstack Launchpad bug 1661360 in tripleo "InstanceNotFound due to missing osapi_compute service version when running nova-api under wsgi" [Critical,Fix released]
18:54:06 cdent one sec mnaser
18:54:08 tasker is there a blueprint to support volume snapshots attached to an image-backed instance?
18:57:39 cdent mnaser: yes, it is safe to deploy under wsgi now, but it is important to use the correct app. the one that is deployed by pbr (via the wsgi_scripts entry point) is the right one. it is: nova-placement-api
18:57:52 cdent mnaser: sorry nova-api-wsgi
18:58:08 mnaser cdent https://github.com/openstack/puppet-nova/blob/master/manifests/params.pp#L52 looks like that's put in place
18:58:12 cdent there’s also one for metadata under wsgi now too: nova-metadata-wsgi
18:58:30 mnaser cdent cool! i'll remove the warning, see how puppet ci reacts to deploying via wsgi and report back if i run into anything, thank you!
18:58:44 cdent mnaser: good luck. I hope it works. it’s much better
18:59:03 mnaser cdent i've been looking forward for it since newton :p
18:59:17 cdent time moves in waves
18:59:55 melwitt tasker: do you mean just snapshotting a volume? you can already do that in cinder
19:01:13 tasker melwitt: via the createImage API call. if the instance is image-based, it does nothing with respect to any attached volumes -- it will only snapshot the volumes if the core instance is volume-backed.
19:01:29 melwitt oh, I see
19:02:02 tasker I've looked at the code up to O and seen no change to the under-lying logic. I was wondering if there's a blueprint.
19:02:11 tasker maybe someone else has the same use-case?
19:02:34 melwitt yeah, I'm not aware of any blueprints up for that. doing a quick check
19:03:20 tasker I've also done a quick look and I'm not seeing anything yet -- thought I'd ask here in case anyone knew of anything.
19:03:45 openstackgerrit Chris Dent proposed openstack/nova master: Always use application/json accept header in report client https://review.openstack.org/489772
19:03:47 melwitt understood. yeah, I haven't heard of anyone working on that
19:04:31 melwitt tasker: of course, right after I say that, I noticed this https://blueprints.launchpad.net/nova/+spec/snapshot-instance-and-volume
19:05:01 melwitt but that's from 2015 and nothing was done with it
19:06:51 efried cdent The basis for the placement-uses-ksa-adapter change: https://review.openstack.org/#/c/488137/ -- seems like you might be interested...
19:07:40 cdent efried: yup it’s in my queue but I’m totally tapped out now, been a long day, need foods. I’m probably boring enough to come back and look after dinner though
19:08:40 efried cdent Heh. No hurry, I imagine. This is for a pike bp that got pushed to queens, so I'm not sure it's likely to get approved before that bp is refreshed and reapproved.
19:15:21 tasker melwitt: good find. it at least confirms someone else has the desired use-case.
19:15:53 tasker pity it never went anywhere.
19:20:04 openstackgerrit Merged openstack/nova master: [placement] Make placement_api_docs.py failing https://review.openstack.org/480924
19:35:36 tasker melwitt: thanks for your help!
19:36:03 melwitt np
19:50:43 smcginnis Anyone around that can help with a volume detach problem?
19:51:11 smcginnis We're trying to merge a patch to update grenade for pike, but it's failing grenade.
19:51:36 smcginnis Volume created and attached with Ocata, then after it upgrades and tries to detach in Pike it fails.
19:51:55 smcginnis Nova tells cinder to begin_detaching, which places the volume status in "detaching"
19:52:08 smcginnis Then never makes it back to Cinder to do the actual detach.
19:52:23 smcginnis And grenade ends up timing out waiting for the volume state to go from detaching to available.
19:52:53 dansmith smcginnis: link?
19:53:30 smcginnis dansmith: Sorry, gotta find my tabs now. Looking...
19:53:52 smcginnis dansmith: Here is the grenade log.
19:53:54 smcginnis http://logs.openstack.org/57/493057/10/check/gate-grenade-dsvm-neutron-multinode-ubuntu-xenial/3004b34/logs/grenade.sh.txt.gz#_2017-08-14_17_21_46_226
19:54:35 smcginnis Last item here is a call to servers with a DELETE on os-volume_attachments:
19:54:38 smcginnis http://logs.openstack.org/57/493057/10/check/gate-grenade-dsvm-neutron-multinode-ubuntu-xenial/3004b34/logs/new/screen-n-api.txt.gz
19:54:42 smcginnis But nothing ever makes it down to Cinder.
19:54:56 smcginnis jgriffith, ildikov: Feel free to add more findings ^^
19:55:55 jgriffith smcginnis seems like a good enough summary; just to note that that volume_attachments is the nova route table entry, NOT Cinder attachments API
19:56:08 jgriffith that call goes; and nothing is ever actually issued to cinder, cinderclient etc
19:56:21 jgriffith at least not that I could find
19:56:49 ildikov good summary
19:57:29 oomichi toabctl: thanks, but need to update https://review.openstack.org/#/c/398308 again
19:57:59 dansmith smcginnis: so it looks like that delete call is later than the latest thing in n-cpu.log
19:58:21 dansmith the detach happens on the compute, IIRC
19:58:46 smcginnis dansmith: Check under /new

Earlier   Later