| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-10-12 | |||
| 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 | |
| 22:09:33 | dansmith | melwitt: instance list didn't use scatter/gather in pike | |
| 22:10:15 | mriedem | sapd_: you're getting that when trying to start up those other 2 services? or the one that is upgraded? | |
| 22:11:31 | mriedem | although we filter out osapi_compute services from that api... | |
| 22:11:54 | dansmith | mriedem: it's also the kind of thing that could be misinterpreted | |
| 22:13:58 | melwitt | dansmith: yeah, I was thinking if an instance list is trying to use the cell cache and some other boot request comes in and mucks with the DB transaction context it could cause instance list to fail | |
| 22:14:20 | melwitt | even if instance list isn't using scatter gather, the quota check for the boot request does | |
| 22:14:46 | dansmith | I'm not sure what is shared between those two operations that would cause such a thing | |