| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-12 | |||
| 12:37:50 | efried | ~800 unread emails. Sigh. | |
| 12:37:50 | edleafe | efried: but no, nothing other than the usual | |
| 12:37:57 | efried | edleafe: Cool, thanks. | |
| 12:40:18 | jaypipes | stephenfin: sure. after scheduler meeting works for me. | |
| 12:40:20 | efried | Hi gibi | |
| 12:42:30 | jaypipes | johnthetubaguy: currently, we have nothing in the os-traits library or in nova that identifies "conflicting" traits. for example, there's nothing preventing an admin from decorating a compute node with both the STORAGE_DISK_HDD and STORAGE_DISK_SSD traits at the same time. We will need some logic somewhere (not in the virt driver I would hope) to process conflicts in requested traits between the flavor and image I would think? | |
| 12:43:51 | openstackgerrit | sahid proposed openstack/nova-specs master: libvirt: add support for virtio-net rx/tx queue sizes https://review.openstack.org/539605 | |
| 12:44:00 | cdent | can we call that rope? If you try it, it doesn't work, you investigate, you see why, don't do that again | |
| 12:44:22 | cdent | putting _meaning_ into the traits (rather than just beign symbols) will get messy | |
| 12:44:44 | cdent | jaypipes: ^ | |
| 12:44:58 | efried | jaypipes, cdent: Yeah, I agree we don't want to try to get too clever - *especially* outside of virt driver - about inter-trait semantics like that. | |
| 12:45:27 | efried | For the SSD/HDD example, if I'm not using trees, and I have both kinds of disk on my compute host, that could be a valid configuration. | |
| 12:45:58 | cdent | welcome back efried | |
| 12:46:01 | efried | Even if I am using trees, it's not certain I would split the local disk out from the compute node RP | |
| 12:46:04 | efried | Thanks cdent! | |
| 12:46:24 | efried | oh, you mean in the request | |
| 12:46:44 | efried | So if I make a resource request that has both of those traits, in one request group, it doesn't make sense. | |
| 12:47:57 | efried | ...and would *usually* fail in GET /a_c. Unless you've got the aforementioned host with both kinds of disk on it. | |
| 12:50:49 | jaypipes | efried: for sure. | |
| 12:54:09 | edleafe | I agree that there shouldn't be meaning in traits. If there needs to be logic added, it should be in the layer that is applying the traits, not in the trait API. | |
| 12:55:34 | efried | What we NEED is trait metadata | |
| 12:55:42 | efried | And aggregate metadata. | |
| 12:55:48 | edleafe | somebody shoot that guy | |
| 12:57:36 | jaypipes | heh | |
| 12:58:12 | cdent | actually, I'd prefer trait traits | |
| 13:00:01 | jaypipes | cdent: lol | |
| 13:01:28 | edleafe | that's silly. What we need are aggregates of traits | |
| 13:01:34 | edleafe | with metadata, of course | |
| 13:03:30 | cdent | why have aggregates when we can have trait traits traits? | |
| 13:04:03 | cdent | (I actually do think it would be much more easy to reason about the world if we only had traits and not aggregates) | |
| 13:04:18 | cdent | but I'm a faceted classification kind of guy | |
| 13:04:55 | edleafe | we've been through this. There really is no difference. I prefer traits because it's shorter to type | |
| 13:05:02 | jaypipes | buffalo buffalo buffalo buffalo buffalo buffalo buffalo | |
| 13:06:06 | cdent | parkay | |
| 13:07:03 | cdent | If traits is shorter than aggregates and that's good, then _clearly_ tags are the way to go | |
| 13:07:48 | arvindn05 | continue the discussion on #openstack-meeting-alt ? | |
| 13:07:50 | jaypipes | hehe | |
| 13:08:07 | jaypipes | arvindn05: in 55 minutes, no? | |
| 13:08:17 | edleafe | arvindn05: in 52 minutes, sure | |
| 13:08:20 | edleafe | jinx | |
| 13:08:21 | jaypipes | arvindn05: daylight savings... :) | |
| 13:08:21 | arvindn05 | ah...DST :) | |
| 13:08:24 | jaypipes | yup | |
| 13:08:30 | jaypipes | gets me every time. | |
| 13:09:40 | arvindn05 | would have thought outlook adjusted...oh well...extra hour for me :) | |
| 13:11:01 | arvindn05 | edleafe: cdent: latest patch set on https://review.openstack.org/#/c/541507/ addresses other concerns..can you add your review and original +1's? | |
| 13:11:39 | edleafe | arvindn05: I have that and a bunch of others open for review today. | |
| 13:12:23 | cdent | yup, already have that open in tab | |
| 13:12:43 | arvindn05 | great...thanks. | |
| 13:13:22 | arvindn05 | i think i need a workflow +1...i am guessing that should come from matt? | |
| 13:24:40 | stephenfin | johnthetubaguy: They should. I'll fix them up and ping you then, if that's OK? | |
| 13:25:17 | Spazmotic | Welcome home, BTW, efried | |
| 13:25:58 | efried | Spazmotic: Thanks! | |
| 13:26:12 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Remove '[conductor] topic' opt https://review.openstack.org/499179 | |
| 13:27:21 | stephenfin | johnthetubaguy: Actually, it was just the commit message so I stripped out that line (there's no rocky equivalent) and sent it through. Fancy hitting https://review.openstack.org/#/c/508487 though? | |
| 13:30:59 | Spazmotic | c'mon tempest-full.. don't play with me | |
| 13:31:21 | Spazmotic | My achey breaky heart and all that. | |
| 13:32:22 | sahid | jaypipes: we have some kind of agrements on this spec: https://review.openstack.org/#/c/539605/ if we can have you to make a first +2 | |
| 13:33:29 | sahid | cfriesen: any chance you have a look at this https://review.openstack.org/#/c/511188/ ? | |
| 13:37:18 | openstackgerrit | Merged openstack/nova master: Raise a proper exception in unit test https://review.openstack.org/550914 | |
| 13:37:27 | johnthetubaguy | stephenfin: I think all the others need the same treatment? | |
| 13:37:45 | johnthetubaguy | stephenfin: happy to hit the whole chain though, all seem like good tidy ups | |
| 13:44:11 | ShilpaSD | stephenfin: Hi | |
| 13:46:42 | jaypipes | sahid: done | |
| 13:47:37 | kashyap | jaypipes, johnthetubaguy: Does this require a specification? Also a config change: https://review.openstack.org/#/c/511188/ | |
| 13:47:42 | kashyap | Err, wrong link | |
| 13:47:42 | sahid | jaypipes: thanks | |
| 13:48:13 | kashyap | jaypipes: johnthetubaguy Correct one: https://review.openstack.org/#/c/534384/ ("Allow to specify granular CPU feature flags") | |
| 13:48:48 | johnthetubaguy | jaypipes: +1 on the conflict resolution, I was more thinking about operator per flavor restrictions, like allow trait overrides on a specific flavor | |
| 13:49:30 | johnthetubaguy | kashyap: that is libvirt only, and via config, I think, so you could argue it was a specless blueprint | |
| 13:49:37 | jaypipes | kashyap: I prefer https://review.openstack.org/#/c/497733/. | |
| 13:49:53 | kashyap | johnthetubaguy: Right; I'll go file that spec-less Blueprint | |
| 13:50:51 | kashyap | jaypipes: Hi, this is a bit more imminent, the commit message gives the rationale: https://review.openstack.org/#/c/534384/ | |
| 13:50:58 | kashyap | jaypipes: I see the spec you linked to is the long-term solution | |
| 13:51:22 | kashyap | But to solve the immediate performance problems for all the users, I'd argue the above config approach is the cleanest | |
| 13:51:39 | johnthetubaguy | not sure, there is make available to guest and require from guest so restrict to hosts that have it | |
| 13:51:46 | johnthetubaguy | I guess its just two sides of the problem? | |
| 13:52:18 | kashyap | johnthetubaguy: Can you expand on this: "require from guest so restrict to hosts that have it" | |
| 13:52:39 | jaypipes | kashyap: adding yet more configuration options to nova.conf? that is specific to a single virt driver and doesn't solve the problem for the rest of them? | |
| 13:52:43 | johnthetubaguy | an image or flavor might "require" pcid | |
| 13:52:54 | johnthetubaguy | regardless the operator might want to provide pcid to the guest | |
| 13:53:00 | johnthetubaguy | seems like two different things | |
| 13:53:16 | kashyap | jaypipes: I'm with you on not sleep-walking into adding more and more config options. | |
| 13:53:19 | kashyap | jaypipes: But ... | |
| 13:53:57 | kashyap | jaypipes: This is an exceptional scenario. The executive summary is: In light of applying the "Meltdown" CVE fixes, those guests using custom CPU models will incur 30% additional performance penalty! | |
| 13:54:13 | kashyap | jaypipes: So, I don't take the adding a new config option approach very lightly | |
| 13:54:39 | kashyap | jaypipes: Yeah, there is a case to be made for that, too: allowing operators to configure _per_ flavor | |
| 13:54:53 | kashyap | (But that's a different problem. I wanted to address this immediate isolated problem.) | |
| 13:55:01 | jaypipes | kashyap: it's more of an image thing than a flavor thing, right? | |
| 13:55:18 | johnthetubaguy | neither, its an operator problem here | |
| 13:55:33 | johnthetubaguy | kashyap: you need more context in the git commit message, and less about those additional use cases | |
| 13:55:44 | dansmith | yeah, this is a pretty important one, IMHO | |
| 13:55:58 | johnthetubaguy | ideally we would turn it on everywhere to avoid the performance issue, but its not available everywhere, and that would break live-migrate | |
| 13:55:59 | dansmith | and on par with other virt conf options we have | |
| 13:56:04 | johnthetubaguy | dansmith: +1 | |
| 13:56:08 | kashyap | johnthetubaguy: I wrote additional context in my first commit message. | |
| 13:56:32 | kashyap | johnthetubaguy: Here's all the additional context: https://review.openstack.org/#/c/534384/2//COMMIT_MSG | |
| 13:56:43 | kashyap | (But I was asked to remove it from the commit by mdbooth.) | |
| 13:56:49 | kashyap | Damned if I did, damned if I didn't | |
| 13:57:19 | johnthetubaguy | kashyap: maybe somewhere in between, without the sub headings | |