Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-01-23
15:20:58 bauzas dansmith: but lemme look at that
15:20:59 dansmith bauzas: how what works?
15:21:13 bauzas my brain is just fried by the scheduler upcall so I could be misunderstanding
15:21:36 bauzas dansmith: so, you construct a global limit and you pass it down to the cell-related instance.get_all() call
15:21:48 bauzas with leaving the marker, right?
15:22:27 dansmith the global limit is just to make sure that we don't keep querying cells for more instances
15:22:47 dansmith so if you limit=100 and we return 90 from the first cell, then the second cell should only fetch 10, and the third cell 0
15:23:27 dansmith sfinucan: why no test on that filter change/
15:24:08 bauzas dansmith: right, I understood that
15:24:17 sfinucan dansmith: Because I couldn't figure out where to slot it in 🙈
15:24:34 bauzas I'm thinking of the limit=50 and cell1 having 60
15:25:04 dansmith bauzas: then we'll limit=50 on the first cell, and then limit will be zero afterwards, an we will never call the next one
15:25:08 bauzas in that case, we get the first 50 elements and we set the marker to the 50th injstance
15:25:09 dansmith bauzas: and return 50 instances
15:25:17 bauzas right
15:25:51 bauzas so, next call would get the cell1 marker to the 50th instance, so a new limit of 50 would return the 10 left + 40 from cell2 if we have enough, right?
15:26:24 bauzas I think I see the logic
15:26:32 bauzas we consume all instances from cell to cell
15:26:48 bauzas and the marker is just related to the cell currently half-checked
15:26:57 dansmith right
15:28:01 bauzas dansmith: because there is huge assumption that we get once the cells, and we don't get again
15:28:22 dansmith bauzas: I'm not sure what you mean
15:28:41 bauzas dansmith: you only set your global cells value once, right?
15:28:58 dansmith bauzas: you mean we never re-query the list of cells currently
15:29:00 dansmith ?
15:29:07 bauzas yeah, your TODO
15:29:15 bauzas I mean your FIXME sorry
15:29:17 jroll edleafe: line 70 here is the major reason I need to figure out what a flavor looks like https://review.openstack.org/#/c/345081/6/install-guide/source/include/configure-nova-flavors.rst
15:29:23 dansmith bauzas: that's correct -- what does that have to do with the limit/marker thing?
15:29:51 bauzas dansmith: because we could imagine that we look over 3 cells
15:30:13 bauzas have the marker in the middle of the 2nd cell
15:30:27 bauzas and then all instances newly created in cell1 would never appear
15:30:32 bauzas in a further call
15:30:44 edleafe jroll: yeah, I see that
15:30:57 dansmith sfinucan: test_numa_topology_filters.py ?
15:31:37 edleafe jroll: looking through the flavor docs, they are super-VM centric. So I think extra-specs will have to be used for now
15:31:49 dansmith bauzas: that's the sorting problem we've already identified, right? either way, pagination is always lossy and if you are sorted on something like uuid you'd not see those new instances even in a single cell currently
15:31:52 edleafe jroll: the other resource classes are hard-coded into flavors
15:32:04 jroll edleafe: bleh
15:32:06 edleafe jroll: which I wanted flavors to DIAFF long ago
15:32:17 edleafe s/which/which is
15:32:20 bauzas dansmith: sure, I just wanted to make sure we are at the same page
15:32:22 jroll edleafe: now I'm wondering how nova behaves if nothing is set but resource classes :P
15:32:27 jroll I guess this is why we CI
15:32:31 dansmith bauzas: yes, we're on the same marker :)
15:33:02 edleafe jroll: cdent is away ATM, but I'll pick his brain when he gets back
15:33:10 openstackgerrit Maciej Szankin proposed openstack/nova: conf: Resolve TODOs in 'database' https://review.openstack.org/393695
15:33:30 jroll edleafe: yeah, fair, thanks
15:34:07 bauzas dansmith: since you're working on a new PS, maybe writing this scenario into a unittest could be nice to me
15:34:36 bauzas dansmith: like, create 3 cells, iterate over 1 and then the 2nd, add a new instance to cell1 and make sure that it's never read
15:35:02 bauzas dansmith: because I think that it could be something important for operators wanting to have multi-cells
15:35:17 bauzas and they could come to us and say 'why can't I see my new instances?"
15:35:18 dansmith bauzas: ...really?
15:35:32 bauzas dansmith: well, at least documenting it then
15:35:33 dansmith bauzas: but it's a marker/limit query and that situation exists today
15:35:45 bauzas something saying that we know our limitations
15:36:05 dansmith but it's exactly the way it behaves today :)
15:37:17 sfinucan So I'm clear, the marker is applied before the limit, right?
15:37:43 bauzas dansmith: okay then nevermind
15:37:49 vladikr dansmith, I have reworked the "sriov-pf-passthrough-neutron-port-vlan" series according to your suggestion to get the vlan from the info_cache, could you please take a look when you have the time, before it hits the code freeze ? https://review.openstack.org/#/q/topic:bp/sriov-pf-passthrough-neutron-port-vlan
15:37:50 sfinucan I'm curious what would happen if there was nothing matching the marker in the first cell but we hadn't indexed any others yet. I'm guessing '_get_instances_by_filters' will return nothing and limit wouldn't be deprecated, but just making sure :)
15:41:04 purplerbot <edleafe> jroll: unless that butterfly laid some eggs in cdent's brain, yet [2017-01-23 14:52:19] [n 22sr]
15:41:04 cdent jroll, edleafe: re [t 22sr] no catepillars, just maggots
15:41:23 jroll :|
15:41:31 edleafe cdent: so extra_specs is all we got?
15:42:13 cdent I vaguely recall this being discussed in a review and that extra_specs was the way to go for now because we hadn't had a chance to kill flavors
15:42:15 edleafe cdent: and do we have the code in place to convert 'resource_class' in extra_specs to an actual ironic request?
15:42:24 cdent but I wouldn't want to be held to that version of the truth
15:43:28 edleafe god, extra_specs is some special kind of suck
15:43:50 openstackgerrit Balazs Gibizer proposed openstack/nova: Transform instance.trigger_crash_dump notification https://review.openstack.org/396225
15:44:01 cdent it doesn't look like it, but my understanding was that for this cycle we weren't planning to. all we were caring about was getting the inventory right, not using it (in the ironic case)
15:44:27 amrith andreykurilin, looks like https://review.openstack.org/#/c/423086/ is trying to fix something related to what you are addressing; I've set that one to depend on your change; let's see how all three together do
15:45:03 edleafe cdent: so what jroll needs is to be able to write the guidance for ironic operators for ocata so that they are in a good place when pike rolls out
15:45:05 dansmith sfinucan: ah, we probably need to skip NotFound if we have a marker and limit!=0
15:45:06 cdent edleafe, jroll I'm sorry I don't know more. My devious plan to get people to correct me when I'm wrong or leave things out in the rp updates has been a fail
15:45:15 dansmith sfinucan: that's what the intent is, otherwise the marker would always have to be in cell1
15:45:26 dansmith which wouldn't be the case after we can have multiple
15:45:43 jroll cdent: and my plan to make sure that's in a good place has been undermined by a million other things to do
15:46:02 cdent plans suck, or something
15:46:30 andreykurilin amrith: it should fix only tests...
15:46:50 amrith andreykurilin, I don't even understand that test
15:46:55 sfinucan jroll: And review all the code, like a good core :)
15:47:04 jroll sfinucan: I'll think about it
15:47:06 jroll :)
15:47:11 amrith why it makes sense for a test to inspect some internal attributes of the nova client object I know not
15:47:16 sfinucan heh :)
15:47:20 andreykurilin amrith: heh
15:47:21 amrith seems like that test would be more appropriate if it were in nova
15:47:26 amrith but this is a test in trove :)
15:47:41 amrith the fix seems to correct for the fact that the variable is no longer context.user but why should trove care?
15:47:47 amrith my 2c worth
15:48:00 amrith let's see if it passes tests; I'll fix the test a different way if it does and dep on your change
15:48:00 cdent jroll, edleafe: I reckon for the guideance the thing to do at this stage is establish a pattern of people setting the resource class on the ironic side so that the inventory setting, established in this patch: https://review.openstack.org/#/c/404472/ can happen
15:48:32 jroll cdent: I agree, I just don't think we can require that for a pike upgrade, if people can't transition their flavors in ocata
15:49:04 cdent Unfortunately I can't really comment on that: I don't have enough of a picture of all the pieces
15:50:18 edleafe jroll: I can't imaging flavors being nuked any time soon - they're just too entrenched to kill without splattering their guts all over
15:50:45 edleafe jroll: so I would recommend going the extra_specs route for the foreseeable future
15:50:57 edleafe jroll: it sucks bigly, but that's all we have to work with
15:51:32 jroll edleafe: if we're only tracking resources the new way (as we just said we wanted to in pike), then the existing flavors (which include cpu/ram/gb) won't work. which means we need to be able to make new flavors (with only resource classes) in ocata, and those need to work (I think?).
15:53:24 mriedem buenos dias

Earlier   Later