| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-15 | |||
| 14:11:26 | mriedem | it'd be straight sql | |
| 14:11:34 | mriedem | well, orm | |
| 14:11:55 | bauzas | mriedem: dansmith: well, do you think it could be turnable by opt ? | |
| 14:12:09 | bauzas | or by command | |
| 14:12:16 | bauzas | like "purge --archive" | |
| 14:12:42 | dansmith | bauzas: I know that's a concern, but unless you have a suggestion going forward I don't see what the options are | |
| 14:13:04 | dansmith | bauzas: just make archive_deleted_rows do it.. no need to overthink it | |
| 14:14:09 | bauzas | dansmith: sorry I could be confused | |
| 14:16:03 | bauzas | dansmith: you mean I should amend the archive_deleted_rows subcommand to delete the spec records ? | |
| 14:16:12 | dansmith | yes | |
| 14:16:15 | bauzas | okay | |
| 14:16:43 | bauzas | lemme write that soon, ideally this week | |
| 14:16:56 | bauzas | mriedem: you said you gonna write a bug report for this ? | |
| 14:17:37 | dansmith | bauzas: I'd really appreciate quick follow-up on the az thing with concrete suggestions | |
| 14:17:40 | bauzas | dansmith: for https://review.openstack.org/#/c/439754/23/nova/api/metadata/base.py I don't think we need to change this if we consider looking up the host AZ, nope ? | |
| 14:18:03 | dansmith | bauzas: you mean what was being done before? | |
| 14:18:05 | mriedem | bauzas: i'm working on something related to it | |
| 14:18:11 | bauzas | dansmith: the logic in that method is that we use the instance.az field to match with the host AZ information | |
| 14:18:32 | bauzas | dansmith: yeah, I don't see why we need to make it cellsv2-aware | |
| 14:18:43 | bauzas | if we fix instance.az | |
| 14:18:46 | dansmith | bauzas: because metadata runs in the cell and can't access the api database to look at az stuff | |
| 14:19:32 | bauzas | orly? | |
| 14:19:45 | dansmith | yarly! | |
| 14:20:04 | bauzas | I thought it was on top | |
| 14:20:27 | dansmith | bauzas: no, and definitely not if we're just using it to build configdrive | |
| 14:20:32 | bauzas | I see | |
| 14:20:39 | bauzas | lemme reconsider the problem then | |
| 14:21:54 | bauzas | dansmith: what really blocks us is https://github.com/openstack/nova/blob/67af1eefc5c1cf8cde4b4becb933808850acec2d/nova/availability_zones.py#L190 | |
| 14:22:34 | bauzas | dansmith: but conceptually, we need to know where the instance is located, hence why we call the AggregateList object | |
| 14:22:58 | dansmith | why are we doing that late instead of just making sure az gets set properly when the instance gets rescheduled or whatever? | |
| 14:23:17 | dansmith | we're taking this lookup hit every time we build metadata, but we should just make sure that we set the thing properly in the first place right? | |
| 14:25:40 | dansmith | like in schedule_and_build() and build_and_run(), we should be able to lookup and fix instance.az once so metadata never has to look again, right? | |
| 14:25:54 | dansmith | since we know the host it's going to land on each time | |
| 14:27:06 | bauzas | dansmith: well, it's something I discussed in the past | |
| 14:27:26 | bauzas | now that we have RequestSpec, I'm in favor of updating instance.az to the right value | |
| 14:27:47 | bauzas | semantically, we kept that unchanged in the past because we wanted to know what the user originally expressed | |
| 14:27:59 | bauzas | but now we have the Spec object that targets that | |
| 14:28:12 | dansmith | if the user expressed something, then we would be limiting the scheduling to that az anyway, no? | |
| 14:28:31 | bauzas | dansmith: yup, but we default that field for some unknown reason | |
| 14:28:38 | bauzas | we set it anyway | |
| 14:28:46 | dansmith | to nova if it was unset, right? | |
| 14:28:50 | bauzas | well, I actually know | |
| 14:29:12 | bauzas | yeah, if the user didn't ask for an AZ, we set it to a conf opt value | |
| 14:29:27 | bauzas | if the user asked for an AZ, then I agree with your statement | |
| 14:29:39 | dansmith | so metadata right now reports the actual az it landed on correct? | |
| 14:30:50 | dansmith | it looks to me like we use instance.az in several other places | |
| 14:31:20 | bauzas | dansmith: for the metadata, yes | |
| 14:31:27 | dansmith | no, for other things too | |
| 14:31:36 | dansmith | nova/network/neutronv2/api.py: zone = 'compute:%s' % instance.availability_zone | |
| 14:31:38 | bauzas | dansmith: for other places, AFAICT, I think we return that too | |
| 14:31:42 | dansmith | nova/virt/block_device.py: return instance.availability_zone | |
| 14:32:03 | dansmith | is having instance.az being incorrect not affecting those places as well? | |
| 14:32:11 | bauzas | yup | |
| 14:32:13 | dansmith | like, shouldn't making it be the actual az the instance is on be better? | |
| 14:32:37 | bauzas | yeah, as I said, I agree, we should update instance.az to the right value | |
| 14:32:56 | bauzas | and use spec_obj.availability_zone for knowing the original request | |
| 14:33:14 | dansmith | okay | |
| 14:33:18 | dansmith | grim | |
| 14:33:20 | dansmith | oops | |
| 14:33:50 | dane-fichter | mriedem: could you unblock this change, please? https://review.openstack.org/#/c/351232/ | |
| 14:34:09 | jaypipes | mriedem: so, is there anything on the ironic virt driver patch you'd like me to change? | |
| 14:35:01 | openstackgerrit | Rafael Folco proposed openstack/nova master: DELETE all inventory for a resource provider https://review.openstack.org/416669 | |
| 14:35:01 | openstackgerrit | Rafael Folco proposed openstack/nova master: [placement] Raising http codes on old microversion https://review.openstack.org/444497 | |
| 14:35:04 | mriedem | dane-fichter: done, left a comment | |
| 14:35:08 | mriedem | jaypipes: let me check your replies | |
| 14:37:14 | dansmith | bauzas: do I really need elevated context here/ https://github.com/openstack/nova/blob/67af1eefc5c1cf8cde4b4becb933808850acec2d/nova/availability_zones.py#L190 | |
| 14:38:09 | jaypipes | mriedem: I can add a code comment about raising an exception if resource class is None in Queens, if you'd like. | |
| 14:38:46 | mriedem | jaypipes: let me look first, might be just follow up stuff | |
| 14:38:53 | mriedem | doing a few things at once | |
| 14:40:27 | bauzas | dansmith: I left a proposal in https://review.openstack.org/#/c/439754/23 by saying we could amend instance.az once we schedule a target | |
| 14:40:43 | bauzas | every time we touch instance.host actually | |
| 14:41:03 | dansmith | bauzas: this is what I'm testing right now: http://pastebin.com/raw/iWBb9wt5 | |
| 14:41:31 | dansmith | bauzas: for the old and new build operations | |
| 14:41:44 | bauzas | dansmith: for the elevated context, I think it's a legacy from the past | |
| 14:41:54 | dansmith | bauzas: okay I thought so too just checking | |
| 14:41:59 | bauzas | dansmith: now we use objects, we don't really need elevated | |
| 14:44:53 | bauzas | dansmith: hmmpppfff, instance.host isn't set on the conductor after we schedule | |
| 14:45:04 | bauzas | I thought it was the case but no | |
| 14:45:15 | bauzas | dansmith: we just use that for calling the right compute service | |
| 14:45:27 | dansmith | right, I'll change | |
| 14:45:30 | bauzas | dansmith: AFAICS, instance.host is only set when the instance is spawning | |
| 14:45:34 | dansmith | yeah, yeah | |
| 14:45:57 | bauzas | yeah we unfortunately need to do that change at the same time or we would enter the magical world of race conditions | |
| 14:46:18 | bauzas | but but | |
| 14:46:22 | bauzas | wait | |
| 14:46:41 | dansmith | huh? | |
| 14:46:45 | bauzas | if we need to lookup the aggregate for knowing where the host is | |
| 14:46:59 | bauzas | and that being in the compute section, it would be an upcall right? | |
| 14:47:01 | dansmith | if we haven't build the instance yet, we can just set it | |
| 14:47:18 | dansmith | we know where we're intending for it to go, and if it reschedules, we change it again | |
| 14:48:31 | bauzas | I'm not opposed to that, I'm just saying there is an amount of time where we could show a result where the instance is part of an AZ while it's not yet having an host | |
| 14:48:47 | dansmith | yeah, so? | |
| 14:48:56 | dansmith | also, can we not use this? https://github.com/openstack/nova/blob/master/nova/objects/service.py#L141-L141 | |
| 14:49:14 | dansmith | the host actually knows what AZ it's in right? | |
| 14:51:04 | dansmith | hmm, maybe that's different | |
| 14:51:36 | bauzas | mmm | |
| 14:51:56 | bauzas | I just discover that | |
| 14:52:01 | bauzas | oh wait | |
| 14:52:34 | bauzas | yeah that's because the services are within AZs, not the compute nodes | |
| 14:52:55 | dansmith | but the api hides that az, so it must be different | |