| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-01-23 | |||
| 14:45:56 | sdague | alex_xu: it would be extremely useful to me to get a mailing list post out about what went wrong, what this allows, and what the fall out from various fixing options would be | |
| 14:46:29 | sdague | because otherwise everyone needs to build that up in their own head from scratch, and it's hard to agree on path forward unless we all agree where we stand | |
| 14:46:51 | edleafe | jroll: good question | |
| 14:47:05 | alex_xu | sdague: i see now. I will investigate more, then send out an email | |
| 14:47:09 | jroll | edleafe: I'd like to have that in my docs for the ironic install guide, I guess | |
| 14:47:20 | jroll | though, if it doesn't work until pike, idk | |
| 14:47:20 | edleafe | jroll: I'm still not clear on whether we need to add the resource class to the flavor | |
| 14:47:37 | jroll | edleafe: how else do we map a flavor to said resource class? | |
| 14:47:52 | edleafe | jroll: or if there is some other mapping | |
| 14:47:56 | sdague | alex_xu: thank you | |
| 14:47:57 | edleafe | jroll: jinx | |
| 14:48:02 | alex_xu | sdague: np | |
| 14:48:48 | edleafe | jroll: my understanding is that the flavor will be: CUSTOM_IRONIC_CLASS: 1 | |
| 14:49:13 | edleafe | jroll: and that placement will find a provider for that class | |
| 14:49:15 | jroll | edleafe: where, in the flavor? e.g. how do I create said flavor? | |
| 14:49:33 | edleafe | jroll: IOW, no disk/ram/cpu BS like now | |
| 14:50:13 | openstackgerrit | Pawel Koniszewski proposed openstack/nova: live-mig: Add claims and proper resource tracking https://review.openstack.org/244489 | |
| 14:50:14 | openstackgerrit | Pawel Koniszewski proposed openstack/nova: libvirt: pass libvirt reference methods to migration https://review.openstack.org/328997 | |
| 14:50:15 | openstackgerrit | Pawel Koniszewski proposed openstack/nova: libvirt: live-migrate updates NUMA and cpus in the XML https://review.openstack.org/286744 | |
| 14:50:21 | edleafe | jroll: well, like any other flavor, but not sure what changes the custom RC stuff will need | |
| 14:50:41 | jroll | edleafe: sure, so just nova flavor-key my-flavor set CUSTOM_FOO_THING=1? | |
| 14:50:43 | jroll | right | |
| 14:50:47 | edleafe | jroll: jaypipes had all this on his mental whiteboard | |
| 14:51:17 | jroll | edleafe: so here's the thing, if we require this to be set up for a smooth upgrade to pike, then we need to be able to make a working flavor in ocata | |
| 14:51:34 | edleafe | jroll: agreed | |
| 14:51:54 | jroll | edleafe: and we're three days from feature freeze and this is but a butterfly in jaypipes' brain, correct? | |
| 14:52:20 | edleafe | jroll: unless that butterfly laid some eggs in cdent's brain, yet | |
| 14:52:25 | edleafe | s/yet/yes | |
| 14:52:52 | edleafe | jroll: He may have written it up somewhere - I can dig for it | |
| 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 | |