| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-03-15 | |||
| 15:00:29 | bauzas | one when you want to get the Service object | |
| 15:01:03 | bauzas | and one in the nova manage command when you list all the hosts | |
| 15:02:44 | bauzas | the only problem that I see is that we don't persist the Service object which is populated when we call the above | |
| 15:03:16 | bauzas | but if you ServiceList.get_all(), you'll get the right value for the AZ | |
| 15:03:25 | mriedem | jaypipes: replied to the replies, now reviewing the RT tests | |
| 15:06:04 | dansmith | bauzas: that's exactly my point, we can't trust it on Service and we can't get it by get_all() from inside the cell | |
| 15:06:09 | dansmith | bauzas: because it will call out to aggregates | |
| 15:12:45 | bauzas | dansmith: yeah, yet another upcall :( | |
| 15:13:14 | dansmith | bauzas: it seems to me that this is already partially broken and just making instance.az be correct is the solution | |
| 15:13:27 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: guest.BlockDevice should only use the target device of a disk https://review.openstack.org/402163 | |
| 15:15:25 | cfriesen | question...how is the "task_log" table intended to be pruned? Is this intended to be managed by the cloud operator? | |
| 15:17:48 | bauzas | dansmith: well, it would certainly require more than what I originally thought | |
| 15:18:06 | bauzas | dansmith: one way could be to set instance.host in the conductor | |
| 15:18:14 | dansmith | bauzas: right that's what I'm doing | |
| 15:18:15 | bauzas | not by the compute | |
| 15:18:18 | dansmith | no, not host | |
| 15:18:20 | dansmith | instance.az | |
| 15:18:24 | dansmith | we don't need to set host in conductor, | |
| 15:18:28 | dansmith | and that breaks all kinds of stuff | |
| 15:21:35 | bauzas | dansmith: well, it could work given https://github.com/openstack/nova/blob/master/nova/availability_zones.py#L163-L169 | |
| 15:21:43 | cfriesen | another database question....how is stale information in the API DB supposed to be cleaned up to prevent indefinite DB growth? | |
| 15:22:22 | dansmith | bauzas: I'm not sure what that has to do with it, but setting instance.host in conductor breaks everything (else) so not an option | |
| 15:22:22 | bauzas | cfriesen: we just discussed that, and we're trying to identify all stale contents | |
| 15:22:37 | bauzas | dansmith: yeah, lemme rephrase | |
| 15:23:29 | bauzas | dansmith: I'm considering the time between when we set instance.az after a schedule, and when we set instance.host as a temporary situation where we return something on the API that could be different | |
| 15:24:38 | bauzas | dansmith: because we only return the "real" AZ where the host is only only when the compute is setting instance.host | |
| 15:24:59 | bauzas | before that, we return the original instance.az | |
| 15:25:02 | bauzas | anywaty | |
| 15:25:10 | bauzas | let's not overthink that | |
| 15:25:15 | bauzas | do your change and I'll weight it | |
| 15:25:22 | dansmith | it's not wrong in that cast anyway | |
| 15:25:24 | dansmith | *case | |
| 15:25:25 | dansmith | yeah | |
| 15:28:35 | dansmith | gdi, we have too many tests | |
| 15:33:07 | openstackgerrit | Mikhail Feoktistov proposed openstack/nova master: Add is_vz_container function https://review.openstack.org/445947 | |
| 15:34:25 | mriedem | jaypipes: jroll: JayF: cdent: edleafe: ok, final comments are in https://review.openstack.org/#/c/441544/ | |
| 15:34:33 | mriedem | i'm -1 for several issues in test_resource_tracker | |
| 15:37:22 | jroll | mriedem: cool, ty | |
| 15:40:53 | cdent | mriedem: since you're in a reviewing state of mind, getting these from edleafe would clear up some lose ends: https://review.openstack.org/#/c/428800/ https://review.openstack.org/#/c/416752/ https://review.openstack.org/#/c/416751/ (related to inventory handling) | |
| 15:42:06 | mriedem | gonna have to queue up | |
| 15:43:56 | johnthetubaguy | heh, you should ask my wife, she is really picky about queues | |
| 15:45:01 | cdent | my recollection is that the use of "up" there is incorrect and would require a forfeit of some kind. Either running around the quad naked or having to get the next two rounds in, depending on your class. | |
| 15:46:31 | dansmith | bauzas: https://github.com/openstack/nova/blob/master/nova/conductor/tasks/migrate.py#L49-L55 | |
| 15:46:39 | dansmith | bauzas: that ignores the stored az I think :) | |
| 15:46:47 | bauzas | FWIW, using "queue" in French has a terrible meaning | |
| 15:47:32 | bauzas | dansmith: yet another reason to fix that then | |
| 15:47:41 | dansmith | yeah | |
| 15:47:52 | bauzas | those AZ issues are so fun | |
| 15:48:31 | bauzas | dansmith: FWIW, the only nova thing which cares about AZs is just the AZ filter | |
| 15:48:53 | mdbooth | lyarwood johnthetubaguy: re https://bugs.launchpad.net/nova/+bug/1672624 if this were BZ I'd close it NOTABUG. | |
| 15:48:53 | openstack | Launchpad bug 1672624 in OpenStack Compute (nova) "Ceph volumes attached to local deleted instance could not be correctly handled" [Undecided,New] | |
| 15:48:53 | bauzas | if you don't use it, that's just a nice but useless metadata | |
| 15:49:34 | mdbooth | But not because it's the operator's fault, just because it's an ephemeral fault outside Nova's control which will eventually resolve itself automatically. | |
| 15:50:02 | bauzas | dansmith: oh wait | |
| 15:50:20 | bauzas | dansmith: we need to keep the original AZ | |
| 15:50:23 | bauzas | for the Spec object | |
| 15:50:40 | bauzas | dansmith: ie. not having the Spec.az mentioning the "real" AZ | |
| 15:51:24 | dansmith | I'm not changing that | |
| 15:51:39 | bauzas | dansmith: but if you boot an instance, it will change instance.az | |
| 15:51:54 | dansmith | and when you finish the cleanup of the spec object usage, you'll get the original az at that point | |
| 15:52:35 | bauzas | yeah, we need to lookup the spec | |
| 15:52:45 | bauzas | not hydrating from the instance | |
| 15:52:55 | dansmith | bauzas: which is the cleanup step, no? | |
| 15:52:58 | dansmith | the TODO(bauzas) | |
| 15:53:03 | bauzas | yup | |
| 16:06:12 | openstackgerrit | Stephen Finucane proposed openstack/nova master: trivial: Remove \r\n line endings from JSON sample https://review.openstack.org/446040 | |
| 16:06:13 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Duplicate JSON line ending check to pep8 https://review.openstack.org/446041 | |
| 16:07:48 | cdent | rfolco: I don't think I'm understanding your question on the DELETE stuff: "Question: Do you think we need a test for 404 and another one for nop (where microversion matches) ?" | |
| 16:09:14 | sfinucan | Could I get someone to look at the above ^ Not possible to build docs locally while things remain this way | |
| 16:11:15 | dansmith | bauzas: explain to me why it makes sense to boot an instance into az foo, land it in az bar, and then resize to foo? | |
| 16:12:01 | bauzas | it's not possible if you specified a AZ | |
| 16:12:06 | bauzas | dansmith: ^ | |
| 16:12:21 | dansmith | bauzas: so the reason to preserve the original request is to know if they didn't request one? | |
| 16:12:28 | bauzas | dansmith: the only case where you can be in foo and then bar is when you did *not* specify an AZ | |
| 16:12:41 | dansmith | right, so, I'm thinking.. | |
| 16:12:48 | dansmith | if I don't ask, I land in bar, | |
| 16:13:00 | dansmith | then I look in metadata, see bar, and boot one in foo to make sure I'm different, | |
| 16:13:15 | dansmith | making the first one resize and leave bar would be kinda bad no? | |
| 16:13:22 | rfolco | cdent, I actually was referring to 444497, if we needed to handle all possible/existing status_codes there. So, for this one you mean 409 test on gabbi ? | |
| 16:13:53 | cdent | yeah, inventory.yaml needs a test of the 409 cases when trying to delete inventories | |
| 16:14:19 | rfolco | cdent, gotcha, sorry for mixing things. | |
| 16:14:50 | cdent | no problem, the process is working. | |
| 16:15:02 | bauzas | dansmith: that's why when you nova show the instance, you're getting the original expressed AZ | |
| 16:15:25 | dansmith | bauzas: show from where, the rest api? | |
| 16:15:28 | bauzas | yeah | |
| 16:16:33 | dansmith | bauzas: okay but metadata will disagree | |
| 16:17:11 | bauzas | I wrote a stupid disclaimer explaining how I think AZs are currently broken in Nova https://docs.openstack.org/developer/nova/aggregates.html#availability-zones-azs | |
| 16:17:41 | dansmith | well, anyway, my point is, if we honor what the instance is currently in, or what was(n't) requested, I think we're fine | |
| 16:18:00 | bauzas | lemme consider that | |
| 16:18:18 | dansmith | I think if I didn't specify anything, then the cloud deciding to keep it in the same az is fine | |
| 16:18:27 | bauzas | as I said, the real nova thing which cares about AZs is the AZfilter | |
| 16:18:36 | bauzas | so, lemme look at the filter code | |
| 16:18:46 | dansmith | right, but presumably it is looking at what is in the reqspec, | |
| 16:18:50 | dansmith | which right now comes from instance.az | |
| 16:18:55 | bauzas | https://github.com/openstack/nova/blob/master/nova/scheduler/filters/availability_zone_filter.py#L47 | |
| 16:19:05 | bauzas | forget the specific line | |
| 16:19:13 | bauzas | it takes what's in the spec | |
| 16:19:19 | dansmith | right | |
| 16:19:34 | bauzas | and compares with if the host is in an aggregate | |
| 16:19:53 | bauzas | if not, it defaults to the conf opt | |