| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-23 | |||
| 14:52:55 | jroll | edleafe: I mean, if it isn't written down at this point, I don't believe it will happen, which means this can't be mandatory fora pike upgrade | |
| 14:52:56 | jroll | okm, | |
| 14:52:58 | jroll | ok* | |
| 14:53:06 | jroll | thanks | |
| 14:53:15 | jroll | all I've seen is maybe an extra spec | |
| 14:53:18 | edleafe | jroll: I'll let you know what I find | |
| 14:53:25 | jroll | edleafe: thank you | |
| 14:56:40 | sfinucan | vladikr: Comments left on https://review.openstack.org/#/c/421186/2 | |
| 14:58:17 | vladikr | sfinucan, thanks | |
| 15:00:12 | amrith | andreykurilin, the token there is something that the client (trove client) would have created and passed to the server. so the auth and token creation is done on the trove client side and the API service (or TM) on the trove control plane uses those credentials. That would be a keystone token. | |
| 15:01:08 | andreykurilin | amrith: oh, sorry. I wrote the wrong question :( it should be : what is tenant there | |
| 15:01:33 | amrith | project_id | |
| 15:01:46 | dansmith | sdague: sfinucan: johnthetubaguy: bauzas: The two patches at the head of this series have been +1 from jenkins for a while and have seen little review. They're not super complicated and I'd really like to see them get in while we work on the third, which is the major goal for ocata for cells: https://review.openstack.org/#/c/396775 | |
| 15:02:18 | andreykurilin | amrith: nice | |
| 15:02:23 | bauzas | dansmith: okay, I can take a look now | |
| 15:02:30 | dansmith | thanks | |
| 15:02:32 | sfinucan | dansmith: Likewise | |
| 15:04:46 | dansmith | also thanks :) | |
| 15:06:52 | ildikov | johnthetubaguy Hi, Can you make it to the meeting today? | |
| 15:12:33 | openstackgerrit | Stephen Finucane proposed openstack/nova: scheduler: Don't modify RequestSpec.numa_topology https://review.openstack.org/419479 | |
| 15:13:14 | sfinucan | dansmith, sahid: If ye could take another look at ^, I'd be mighty appreciative | |
| 15:13:41 | bauzas | dansmith: comments in your bottom change | |
| 15:14:18 | dansmith | bauzas: thanks | |
| 15:14:20 | dansmith | sfinucan: yep | |
| 15:15:42 | bauzas | dansmith: just wanted to make sure we have a limit but not a marker, right? | |
| 15:16:59 | dansmith | bauzas: the marker is handled in that code | |
| 15:17:17 | bauzas | dansmith: mmm? lemme look, I maybe missed it | |
| 15:17:21 | dansmith | bauzas: we pass the marker down to all the sub-list commands and honor the limit at the top | |
| 15:20:22 | bauzas | dansmith: I'm seeing it now | |
| 15:20:46 | bauzas | dansmith: but I actually wonder how it works with 2 cells not having the same number of instances in there | |
| 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 | |