Earlier  
Posted Nick Remark
#openstack-nova - 2017-10-12
17:55:12 dansmith if so, there's no scattering
17:56:02 mriedem not sure i follow,
17:56:13 mriedem couldn't we use the scatter/gather thing on this today? https://github.com/openstack/nova/blob/master/nova/compute/api.py#L3995
17:56:29 dansmith mriedem: you list migrations for an instance, right?
17:56:29 mriedem it would just run the db query concurrently per cell and munge the results
17:56:37 mriedem not this api
17:56:46 mriedem this is all migrations regardless of instance
17:56:49 dansmith oh
17:57:14 dansmith don't we have one that is per instance?
17:57:17 mriedem we do
17:57:24 dansmith *awesome*
17:57:33 mriedem but paging that one would be more like paging simple tenant usage i think,
17:57:36 mriedem which was weird
17:57:46 dansmith anyway,
17:58:46 dansmith I would think just doing linear paging for that would be fine yeah
17:58:49 dansmith until someone complains
17:59:41 mriedem yup cool
18:00:01 mriedem only cburgess would have that many migration records to page anyway
18:00:07 cburgess Do what?
18:00:21 mriedem migrating like a mofo
18:00:24 cburgess yes
18:00:26 cburgess yes we do..
18:00:28 cburgess *sigh*
18:00:39 mriedem well then do we have the spec for you! https://review.openstack.org/#/c/506030/
18:10:02 _ix Hello friends. I can think of a way to do this, but I was hoping there might be a better way. I'm looking to determine whether some of our nodes that are believed to be running in an HA capacity are in fact running on the same hypervisors.
18:10:35 _ix Is there a way to determine from the guest VM which hypervisor host it's running on, at instantiation or otherwise?
18:12:03 dansmith _ix: you can do this from the nova api
18:13:04 _ix I'm familiar with that approach, but I was hoping to register a custom fact with puppet, and instead just used puppetdb to keep an eye on the status of these nodes.
18:14:35 _ix I would suspect that the guest never needs to know who its host is.
18:15:25 dansmith or shouldn't
18:15:41 dansmith I don't know that we expose the sanitized host id or not
18:15:44 dansmith in metadata I mean
18:15:50 dansmith I kinda expect not, but I'd have to look
18:16:22 mriedem i looked, didn't see it
18:34:57 mriedem we should be able to remove the safe_connect decorator now can't we? https://github.com/openstack/nova/blob/master/nova/scheduler/client/report.py#L56
18:35:04 mriedem that was for the newton->ocata transition
18:35:12 mriedem placement is definitely required at this point and a hard failure if it's not there
18:35:39 mriedem and in ocata nova-compute doesn't start either if placement isn't configured for the compute node
18:37:44 dansmith it's also confusing,
18:37:48 dansmith because 404 -> None
18:37:50 dansmith instead of explody
18:43:09 mriedem yeah that's what made me think of it, per gibi's comment in your change
18:43:24 dansmith yeah I just saw that
18:44:01 mriedem shall i patchify the removification?
18:44:56 dansmith if and as you wishitifcate
18:48:57 edleafe dansmith: question on serializing: for returning the list of lists of Selection objects over RPC, will they be automagically primitivized? Or do they need to be manually converted?
18:49:22 dansmith edleafe: should be automatic
18:49:30 edleafe dansmith: thx
18:49:35 dansmith edleafe: because of the NovaObjectSerializer we pass to rpc setup
18:57:53 melwitt couple of easy reviews if anyone can look https://review.openstack.org/#/c/509968 and https://review.openstack.org/#/c/510823
18:59:02 melwitt gibi might be interested in the first one ^
19:06:58 mriedem done and done
19:08:58 melwitt thx mriedem
19:52:14 openstackgerrit Merged openstack/nova master: Add snapshot id to the snapshot notifications https://review.openstack.org/453077
20:31:42 openstackgerrit Merged openstack/nova master: Elevate existing RequestContext to get bandwidth usage https://review.openstack.org/509968
20:32:22 openstackgerrit Merged openstack/nova master: Make expected notifications output easier to read in tests https://review.openstack.org/510823
20:59:12 mriedem nova tastic meeting in 1 minute
20:59:32 melwitt be there or be a rhombus
21:05:04 openstackgerrit Ed Leafe proposed openstack/nova master: Add Selection objects https://review.openstack.org/499239
21:05:04 openstackgerrit Ed Leafe proposed openstack/nova master: Add alternate hosts https://review.openstack.org/486215
21:05:05 openstackgerrit Ed Leafe proposed openstack/nova master: Change RPC for select_destinations() https://review.openstack.org/510159
21:05:05 openstackgerrit Ed Leafe proposed openstack/nova master: Return Selection objects from the scheduler driver https://review.openstack.org/495854
21:05:06 openstackgerrit Ed Leafe proposed openstack/nova master: WIP - Make conductor pass and use host_lists https://review.openstack.org/511358
21:05:06 openstackgerrit Ed Leafe proposed openstack/nova master: Move the claim_resources method to scheduler utils https://review.openstack.org/511357
21:27:26 openstackgerrit Merged openstack/nova master: Nix bug msg from ConfGroupForServiceTypeNotFound https://review.openstack.org/511261
21:29:53 efried woot. 5 rechecks.
21:35:11 takashin mriedem: Would you take a look at https://review.openstack.org/#/c/334732/ ? I fixed response codes in the spec.
21:36:47 mriedem takashin: i'll add it to my list
21:37:26 takashin mriedem: Thank you.
21:38:04 mriedem takashin: btw, you might be interested in this https://review.openstack.org/#/c/511351/
21:38:14 mriedem really anything related to migration status i'm going to send your way now
21:39:32 takashin mriedem: okay. I will check it.
21:47:13 openstackgerrit Matt Riedemann proposed openstack/nova-specs master: Spec for flavor description https://review.openstack.org/501017
21:48:55 sapd_ Hi everybody!
21:50:56 sapd_ I'm upgrade from openstack ocata to pike version. But I had an error when I use admin to list all server in all tenants
21:51:10 sapd_ The error is: TypeError: Can't upgrade a READER transaction to a WRITER mid-transaction
21:51:17 mriedem melwitt: ^
21:53:03 sapd_ Please help me! @@
21:54:41 mriedem sapd_: i think this https://review.openstack.org/#/c/511538/
21:54:57 mriedem apply that patch
21:55:23 melwitt ah, yep.
21:55:31 sapd_ I saw this path. I use context.py from master branch, But It can't help me :((
21:56:46 melwitt sapd_: did you restart services after applying the patch? did you apply it to all of your API hosts?
21:56:59 mriedem did you clean out stale pycs?
21:57:41 sapd_ yes. I did.
21:58:40 sapd_ But It doesn't change anything.
22:00:21 mriedem melwitt: would that also be needed in conductor since we check quota there too?
22:00:27 melwitt sapd_: do you have a trace you can pastebin? one thing that's weird is how there would be a write during a instance list
22:01:01 melwitt mriedem: yeah, you're right
22:01:22 melwitt sapd_: did you patch your nova-conductors too?
22:03:29 sapd_ No I just path on nova-api! does it matter?
22:04:16 melwitt sapd_: yes. nova-conductor runs the same code during instance create, so that needs to be patched too
22:06:47 sapd_ Hi melwitt, I got another error after apply that path: This service is older (v16) than the minimum (v22) version of the rest of the deployment. Unable to continue.
22:07:18 dansmith melwitt: that backport to pike won't affect instance listing will it?
22:07:45 sapd_ This service is older (v16) than the minimum (v22) version of the rest of the deployment. Unable to continue. (HTTP 400) (Request-ID: req-308498b1-848c-4c2d-833a-9341e6f6586e)
22:07:45 sapd_ root@capt-admin-1:/opt# openstack server list --project CS-Labs
22:08:28 dansmith sapd_: you have some unupdated api nodes I think
22:09:05 melwitt dansmith: thinking ... about whether a concurrent boot request could cause that in an instance list. it seems like not because it should be the request that wanted to write that fails
22:09:29 sapd_ I have three nova-api nodes, But I stop two nodes, Only one node up now.
22:09:31 melwitt I'm currently not understanding how it's the instance list that could fail with an attempt to upgrade to write

Earlier   Later