| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-16 | |||
| 17:59:45 | openstackgerrit | Eric Fried proposed openstack/nova master: WIP: Use update_provider_tree from resource tracker https://review.openstack.org/520246 | |
| 17:59:45 | openstackgerrit | Eric Fried proposed openstack/nova master: Fix nits in update_provider_tree series https://review.openstack.org/531260 | |
| 17:59:48 | efried | There, ffs. mgoddard Sorry dude | |
| 18:00:39 | lyarwood | mdbooth: sure, thanks again | |
| 18:00:47 | melwitt | jaypipes: scheduler question for you ... when the filter scheduler does the compute node prune based on placement before going through the scheduler filters, does it take into consideration overcommit values set by aggregate? | |
| 18:01:28 | jaypipes | melwitt: no | |
| 18:01:53 | jaypipes | melwitt: placement has no concept of "aggregate overcommit" | |
| 18:03:22 | melwitt | jaypipes: k, that's what I was thinking | |
| 18:05:02 | melwitt | jaypipes: we're seeing issues where all of the overcommit was set via aggregates, so placement is filtering out very many nodes that can actually serve requests given overcommit | |
| 18:05:31 | melwitt | as a workaround I was thinking, have to set overcommit per compute node in nova.conf to get around this | |
| 18:06:51 | jaypipes | melwitt: I'll be honest, I didn't know about setting overcommit via aggregate. | |
| 18:07:04 | jaypipes | melwitt: sounds like a half (quarter?)-baked feature | |
| 18:07:27 | melwitt | heh. well, it's the AggregateCoreFilter and friends | |
| 18:07:48 | jaypipes | melwitt: and as we've discussed before, aggregates and Ironic don't mix. at all... | |
| 18:08:06 | jaypipes | melwitt: or is this not an ironic thing? | |
| 18:08:13 | melwitt | this is not an ironic thing | |
| 18:08:24 | jaypipes | kk | |
| 18:08:47 | melwitt | since they're doing overcommit via aggregate, placement is returning only like 6 nodes when 20+ can fulfill given overcommit | |
| 18:08:47 | jaypipes | melwitt: still sounds like a half-baked "feature" to me... | |
| 18:09:20 | melwitt | meaning, you expect setting overcommit per compute node should be the fully baked way? | |
| 18:09:44 | melwitt | just trying to understand how they should proceed going forward | |
| 18:09:46 | jaypipes | melwitt: yes. it's the *only* way. | |
| 18:11:47 | melwitt | k. I think the concern there is it hurts usability of aggregates. setting them per aggregate (a few times) vs setting them per compute node (a lot of times) | |
| 18:11:48 | cdent | overcommit by aggregate. interesting. yet another thing I've never heard of before. I can see the appeal | |
| 18:12:19 | melwitt | since aggregate means "bucket of like compute nodes" I can see how one would want to set overcommit same per bucket | |
| 18:12:33 | melwitt | *since aggregate usually means | |
| 18:12:56 | openstackgerrit | Jay Pipes proposed openstack/nova master: add _has_provider_trees() utility function https://review.openstack.org/531474 | |
| 18:12:56 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: _get_trees_matching_all() https://review.openstack.org/531512 | |
| 18:12:57 | openstackgerrit | Jay Pipes proposed openstack/nova master: add tests for _get_trees_matching_all() with trait https://review.openstack.org/531899 | |
| 18:12:57 | openstackgerrit | Jay Pipes proposed openstack/nova master: add test for scenario with sum of child resources https://review.openstack.org/534339 | |
| 18:13:31 | jaypipes | melwitt: an aggregate in placement doesn't have any metadata associated with it at all. it's a pure grouping mechanism. | |
| 18:14:30 | efried | stephenfin Not sure which two comments were the ones holding you back. Let us know if we can clarify anything further. Thanks for the review! | |
| 18:14:31 | melwitt | jaypipes: yeah, I understand. just pointing out the high level effect on the usability in this case | |
| 18:14:40 | jaypipes | melwitt: the problem with the aggregate overcommit thing in Nova is what happens when the compute node's allocation ratio is != the aggregate's allocation ratio? also, what happens when a compute node is in multiple aggregates? which allocation ratio should be used? all these things are not issues in placement because we don't store metadata for aggregates. | |
| 18:15:11 | melwitt | jaypipes: good points | |
| 18:15:24 | melwitt | especially the multiple aggregates | |
| 18:16:38 | jaypipes | melwitt: and I'm not trying to be argumentative. just pointing out that there are definitely some things we won't be porting over to placement land... | |
| 18:17:15 | melwitt | jaypipes: understood. I'm not trying to be argumentative either. just looking to understand and be able to explain it to ppl :) | |
| 18:17:21 | melwitt | so thanks | |
| 18:18:55 | jaypipes | melwitt: when discussing a similar thing with operators (having to set traits on compute node resource provider records individually instead of relying on agg metadata) I had suggested a simple CLI tool that would essentially apply a particular trait to all providers associated with an aggregate. they seemed responsive to that idea. | |
| 18:26:14 | efried | jaypipes edleafe cdent gibi For all the hubbub, we may still want to implement an accessor for provider generation. Given the way I'm using it e.g. in https://review.openstack.org/#/c/532564/9/nova/scheduler/client/report.py@1046 | |
| 18:26:19 | melwitt | jaypipes: k, I'll mention that to them. we'll be looking at how to change over from the Aggregate<resource> filters and configure the deployment to set it per compute node | |
| 18:27:09 | melwitt | s/it/overcommit/ | |
| 18:27:56 | edleafe | efried: what's the reason you can't just use generation = self._provider_tree.generation? | |
| 18:28:21 | efried | edleafe ProviderTree doesn't have a generation. A single provider does. | |
| 18:28:43 | efried | edleafe Back to the thing where individual providers are hidden in the ProviderTree. | |
| 18:29:03 | edleafe | efried: ok, I thought there was something I was missing | |
| 18:29:26 | efried | ProviderTree.snapshot(rp_uuid).generation *works* - it's just wildly inefficient. | |
| 18:30:25 | edleafe | efried: are there other atts besides generation that you have a need to access? | |
| 18:31:14 | openstackgerrit | Lee Yarwood proposed openstack/nova master: rbd: flatten images when creating/unshelving an instance https://review.openstack.org/457886 | |
| 18:31:43 | efried | edleafe Yes, the complex ones (aggs, traits, inventory) which we *must* copy out. Primitives, though... maybe parent_uuid? Eventually name? | |
| 18:32:16 | efried | edleafe More will shake out once drivers start implementing update_provider_tree. | |
| 18:33:11 | edleafe | efried: so are you thinking something like: ptree.getattr(rp_uuid, attname) ? | |
| 18:34:42 | efried | edleafe Initially I was just thinking about ptree.generation_for(rp_uuid), qua https://review.openstack.org/532922 | |
| 18:35:16 | edleafe | efried: well, that's why I asked if you will need this for more than just generation | |
| 18:35:39 | efried | edleafe Surely. Even so, the idea of N accessors was discussed on Monday and jaypipes expressed a preference for doing it this way. | |
| 18:35:49 | edleafe | efried: it would suck to have ptree.name_for(rp_uuid), ptree.parent_uuid_for(rp_uuid), etc. | |
| 18:35:55 | efried | agreeeeed. | |
| 18:36:10 | efried | edleafe I think what I'm actually coming around to is that we shouldn't do the deep copy of the nested children in .snapshot() - at least not by default. | |
| 18:36:46 | efried | edleafe Then at least we're only throwing away one provider's worth of stuff we copied for no reason. | |
| 18:38:11 | sean-k-mooney | stephenfin: jaypipes i ran all the tempest smoke test + senario test + tox -e py35,py27,functional,pep8,docs locally on https://review.openstack.org/#/c/534307/2 here http://paste.openstack.org/show/645744/ all passed so just waiting on the gate to do the same. | |
| 18:38:15 | edleafe | or have snapshot() take an optional rp_uuid | |
| 18:38:32 | edleafe | and only return that provider w/o children | |
| 18:38:54 | efried | edleafe It already does take rp_uuid; that's how you tell it which provider you want to snapshot. | |
| 18:41:23 | esberglu | stephenfin: Asked around and it turns out that nova-networking isn't supported. You okay with leaving bit in for now and removing it in a follow up? | |
| 18:41:34 | esberglu | Trying to avoid respinning the series if possible | |
| 18:42:02 | sean-k-mooney | esberglu: nova-networking has not been removed yet. it will be in early rocky | |
| 18:42:28 | esberglu | sean-k-mooney: This is in regards to powervm virt driver support | |
| 18:42:52 | esberglu | It only supports neutron | |
| 18:43:27 | sean-k-mooney | esberglu: oh well if povervm never supported nova-net before or you have already dropped(or never supported) cells v1 then you dont need nova-networks support | |
| 18:44:02 | efried | esberglu fyi stephenfin is on UK time, so may be gone for the evening. | |
| 18:44:22 | esberglu | efried: ahh thanks for the info | |
| 18:45:28 | efried | esberglu And gibi is also euro. So you might as well respin the series and they should be able to nail 'em quick in the morning (like 4am for us). | |
| 18:46:53 | sean-k-mooney | efried: are you east coast or west? | |
| 18:47:12 | efried | sean-k-mooney Central (Texas) | |
| 18:47:27 | sean-k-mooney | ah ok | |
| 18:47:31 | efried | I think esberglu is either Central or East | |
| 18:47:47 | esberglu | central | |
| 18:48:26 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: vSCSI volume driver https://review.openstack.org/526094 | |
| 18:49:10 | sean-k-mooney | ya unlike me stephen starts early and finishes early. i generally stay later but start later to give more us overlap in my day. also i hate have 2 7 oclocks in my day unless the frist on is 7 pm | |
| 18:50:10 | efried | sean-k-mooney Sounds like you coordinate way more than we do :) | |
| 18:51:14 | efried | As far as meetings go, I consider a successful week to be one with three IRC meetings and zero in-person or phone meetings. | |
| 18:52:28 | efried | (at least, zero in-person meetings that don't involve choking the persons involved) | |
| 18:52:52 | openstackgerrit | Claudiu Belu proposed openstack/nova master: tests: fixes mock autospec usage https://review.openstack.org/447505 | |
| 18:53:18 | sean-k-mooney | efried: haha i would love that. lately i have not had much internal meeting but in the past i had. i like beeing on irc when most of the nova,neutron and kolla core team are about too so haveing a slightly later day helps | |
| 18:53:41 | efried | Mm. I believe cdent is of similar philosophy. | |
| 18:54:03 | edleafe | efried: I have 3 phone meetings *today* | |
| 18:54:28 | cdent | ... that's more side-effect than goal | |
| 18:58:37 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM driver: ovs vif https://review.openstack.org/422512 | |
| 18:58:37 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: SEA https://review.openstack.org/523216 | |
| 18:58:38 | openstackgerrit | Eric Berglund proposed openstack/nova master: PowerVM Driver: vSCSI volume driver https://review.openstack.org/526094 | |
| 19:01:10 | sean-k-mooney | efried_nomnom: esberglu is there a reason you are not using and os-vif plugin intead of https://review.openstack.org/#/c/422512/40/nova/virt/powervm/vif.py | |
| 19:02:17 | efried_nomnom | sean-k-mooney The main reason is probably because os-vif didn't exist when we wrote this stuff, or even when we first started porting it in tree. | |
| 19:02:51 | sean-k-mooney | efried_nomnom: os-vif has been around for 3 maybe 4 cycles now | |
| 19:03:11 | sean-k-mooney | efried_nomnom: it would be nice to convert in rocky | |
| 19:03:23 | efried_nomnom | Duly noted. esberglu ^ for the to-do list? | |
| 19:03:59 | efried_nomnom | Also sean-k-mooney we wouldn't know how to do that offhand. But since you've volunteered to guide us.... :) | |
| 19:04:06 | cfriesen | I'm trying to figure out if a bug is in nova or libvirt/qemu. Do we have any functional/tempest tests of live migration with a config drive and an attached cinder volume? | |
| 19:04:45 | Roamer` | hmm, if mriedem is really on vacation, could I interest any of you in taking a quick look at https://review.openstack.org/140733/ - the StorPool libvirt volume attachment driver? :) The Cinder and os-brick support is in, and Nova's requirements.txt has a dependency on the new version of os-brick now. | |
| 19:05:31 | Roamer` | of course, "leave it till he gets back" might also be kind of reasonable... although it may be cutting it a bit too close to the January 25th deadline | |