| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-03-19 | |||
| 13:45:11 | efried | kaisers1: mikal is the expert on that. I believe he's in Australia, so time zones may be a bit of a challenge. I'm sure I can at least dig up the spec for the privsep work. Stand by... | |
| 13:45:55 | efried | kaisers1: Meanwhile, if you want to see some examples for how mikal has transitioned existing code over to privsep: https://review.openstack.org/#/q/topic:bp/hurrah-for-privsep+(status:open+OR+status:merged) | |
| 13:47:03 | dansmith | kaisers1: you should be using privsep not rootwrap for new things | |
| 13:47:21 | dansmith | kaisers1: the whole point of privsep is to replace rootwrap, and doing so does indeed get you root escalation for your code | |
| 13:47:52 | efried | dansmith: Is there a spec (I can't find one) or documentation for how to use privsep? | |
| 13:48:12 | dansmith | efried: there's lots of code now | |
| 13:48:22 | kaisers1 | I did read the spec | |
| 13:48:32 | kaisers1 | dansmith: thanks for the inputs! | |
| 13:48:47 | efried | kaisers1: For my edification, where did you find that spec? | |
| 13:49:00 | kaisers1 | efried: https://specs.openstack.org/openstack/oslo-specs/specs/liberty/privsep.html | |
| 13:49:04 | dansmith | privsep was born of lots of conversation and design, I'm sure there are things to read, but I expect a lot of the formal documentation focuses on capability contexts, which we've short-circuited to a single root one, | |
| 13:49:07 | efried | ah, in oslo. | |
| 13:49:10 | dansmith | so it may be more reading than you need | |
| 13:49:40 | efried | So yeah, kaisers1 you may do best following the code examples I linked above. | |
| 13:50:05 | kaisers1 | efried: will do, thanks! | |
| 13:50:09 | dansmith | definitely | |
| 13:50:10 | efried | enjoy | |
| 13:54:22 | jaypipes | ugh, the warnings barfed out in py36 test runs is getting ridiculous. | |
| 13:55:09 | edleafe | Scheduler subteam meeting in 5 minutes in #openstack-meeting-alt | |
| 13:55:53 | cdent | jaypipes: fun, isn't it? | |
| 13:57:04 | tssurya | dansmith: I am really sorry about this accidental rebase : https://review.openstack.org/#/c/553831/; could you please rebase it to the right topic before someone +W's it ? | |
| 13:57:44 | jaypipes | cdent: makes it very annoying to run tests. | |
| 13:58:16 | cdent | jaypipes: I keep meaning to find some to fix and then forget for whatever reason | |
| 13:58:50 | dansmith | tssurya: it doesn't really matter | |
| 13:59:16 | tssurya | dansmith: ok, yea still sorry | |
| 13:59:42 | dansmith | tssurya: it's not a problem, gerrit-review does that | |
| 13:59:58 | dansmith | tssurya: in the future -R will prevent you from rebasing the thing underneath you if you intentionally don't want it to move | |
| 14:00:29 | tssurya | dansmith: yep will keep that in mind next time | |
| 14:00:33 | tssurya | thank you | |
| 14:00:38 | dansmith | np | |
| 14:05:04 | Maddy | Hello, I was hitting this bug https://bugs.launchpad.net/nova/+bug/1717547 and I see that the workaround for that is not using the image parameters name as 'version', 'context' and 'method'. | |
| 14:05:05 | openstack | Launchpad bug 1717547 in OpenStack Compute (nova) "Creating snapshot fails when image metadata has version field" [Low,Confirmed] | |
| 14:05:14 | Maddy | This is not good because the user needs to be aware of that. One solution is make Glance to deny use of these parameters name on it's images. Other solution is to rename the variables in Nova 'Call' function to begin with '_' (underscore), but for that we also need to enforce Glance to now allow parameters beginning with '_' (underscore). | |
| 14:05:24 | Maddy | What's your thoughts about that? Any better solution? In case not, what do you think about implementing one the above solutions? | |
| 14:14:33 | openstackgerrit | Jay Pipes proposed openstack/nova master: add test for scenario with sum of child resources https://review.openstack.org/534339 | |
| 14:14:33 | openstackgerrit | Jay Pipes proposed openstack/nova master: tests for alloc candidates with nested and traits https://review.openstack.org/531899 | |
| 14:14:34 | openstackgerrit | Jay Pipes proposed openstack/nova master: add _get_usages_from_trees() function https://review.openstack.org/534967 | |
| 14:14:34 | openstackgerrit | Jay Pipes proposed openstack/nova master: _get_trees_matching_all_resources() sum children https://review.openstack.org/534866 | |
| 14:14:35 | openstackgerrit | Jay Pipes proposed openstack/nova master: WIP - populate alloc cands for trees https://review.openstack.org/534968 | |
| 14:14:35 | openstackgerrit | Jay Pipes proposed openstack/nova master: validate provider summary structure https://review.openstack.org/536516 | |
| 14:20:55 | openstackgerrit | Jay Pipes proposed openstack/nova master: add test for scenario with sum of child resources https://review.openstack.org/534339 | |
| 14:20:55 | openstackgerrit | Jay Pipes proposed openstack/nova master: tests for alloc candidates with nested and traits https://review.openstack.org/531899 | |
| 14:20:56 | openstackgerrit | Jay Pipes proposed openstack/nova master: add _get_usages_from_trees() function https://review.openstack.org/534967 | |
| 14:20:56 | openstackgerrit | Jay Pipes proposed openstack/nova master: _get_trees_matching_all_resources() sum children https://review.openstack.org/534866 | |
| 14:20:57 | openstackgerrit | Jay Pipes proposed openstack/nova master: WIP - populate alloc cands for trees https://review.openstack.org/534968 | |
| 14:20:57 | openstackgerrit | Jay Pipes proposed openstack/nova master: validate provider summary structure https://review.openstack.org/536516 | |
| 14:23:26 | openstackgerrit | Merged openstack/nova-specs master: Add host info to instance action events https://review.openstack.org/543277 | |
| 14:27:44 | jaypipes | efried: ^^ I'm getting that nested providers in allocation candidates series back inline... | |
| 14:27:53 | efried | jaypipes: Cool dude. | |
| 14:28:33 | efried | Did you see my potentially earth-shattering dissenting opinion on the "split one resource across multiple providers" thing? | |
| 14:28:45 | jaypipes | efried: no. link? | |
| 14:29:22 | efried | jaypipes: https://review.openstack.org/#/c/534339/ -- my last comment, on PS5 before rebases | |
| 14:38:01 | mriedem | dansmith: replied in https://review.openstack.org/#/c/543277/ | |
| 14:38:16 | mriedem | still don't see the need for hostId in the action events API, but people at the PTG wanted it | |
| 14:38:48 | dansmith | mriedem: I'm commenting about the rst syntax, using `` instead of " | |
| 14:40:25 | mriedem | oh, heh | |
| 14:40:46 | mriedem | i can push a doc cleanup patch on that | |
| 14:41:34 | kashyap | mriedem: melwitt: Heya, I've read the full chat between you both, dansmith, et al (including the quip: "besides the fix, you can also configure nova for other goodies!"). | |
| 14:41:49 | kashyap | Not to discuss this to death, but 3 quick points: | |
| 14:42:03 | dansmith | mriedem: that's all I was saying :) | |
| 14:42:16 | kashyap | (2) The two Nova config options thing just causes untold pain for all vendors with all their unique deployment tools; and just wastes precious time all around for little gain. | |
| 14:42:16 | kashyap | (1) I want to do the Right Thing & not rush anything in. | |
| 14:42:20 | kashyap | (3) On your point: "well, what I mean is if you use it and it breaks something in queens/pike/ocata then we're probably not going to fix things to accommodate the various flags they enable" — That's a good point. Yes, we have to loudly and clearly document that "NB: There's a huge combination of CPU flags possible, just by virtue of them being available in a given CPU. It's not reasonable to | |
| 14:42:26 | kashyap | test all combinations; so if an Operator wants to try certain flags, it's their responsibility to test if that works in their environment". | |
| 14:44:22 | openstackgerrit | Chris Dent proposed openstack/nova master: Move placement exceptions into the placement package https://review.openstack.org/549862 | |
| 14:44:44 | kashyap | melwitt: mriedem: As a last point, as dansmith also said in different words on Friday here — | |
| 14:44:55 | kashyap | It is not sensible to create an intentionally incompatible syntax in the Nova config file when the actual Nova code to process the config options is largely identical in both cases. | |
| 14:45:34 | openstackgerrit | Chris Dent proposed openstack/nova master: Optional separate database for placement API https://review.openstack.org/362766 | |
| 14:47:16 | openstackgerrit | Chris Dent proposed openstack/nova master: Isolate placement database config https://review.openstack.org/541435 | |
| 14:47:29 | openstackgerrit | Chris Dent proposed openstack/nova master: WIP: Ensure that os-traits sync is attempted only at start of process https://review.openstack.org/553857 | |
| 14:51:12 | openstackgerrit | Lenny Verkhovsky proposed openstack/nova master: Adding NVMEoF for libvirt driver https://review.openstack.org/482640 | |
| 15:01:41 | openstackgerrit | Matt Riedemann proposed openstack/nova-specs master: Address review comments from afdc828db3c9d0205b6ded268db24f5cdf857fa6 https://review.openstack.org/554251 | |
| 15:04:32 | openstackgerrit | Silvan Kaiser proposed openstack/nova master: Exec systemd-run with privileges in Quobyte driver https://review.openstack.org/554195 | |
| 15:06:19 | kaisers1 | efried: fyi https://review.openstack.org/#/c/554195/2 | |
| 15:06:30 | openstackgerrit | Eric Fried proposed openstack/nova master: Report client: Remove version discovery comment https://review.openstack.org/554253 | |
| 15:06:41 | efried | jaypipes, mriedem, cdent ^ | |
| 15:06:45 | efried | kaisers1: ack | |
| 15:06:55 | efried | edleafe: also --^ | |
| 15:06:57 | cfriesen | is github.com enforcing ssh versions now? I just got a "Peer reports incompatible or unsupported protocol version." | |
| 15:07:48 | efried | Could that be what kashyap was running into earlier? | |
| 15:08:14 | kashyap | efried: Probably; it's gone now. I'm able to fetch 'https' from git.o.o. | |
| 15:08:42 | kashyap | cfriesen: I also had troubles this morning w/ GitHub as my 'origin' for Nova | |
| 15:08:57 | cfriesen | looks like they're "weak crypto" versions of https | |
| 15:09:07 | cfriesen | bah, they're *disabling* | |
| 15:09:26 | kashyap | Yeah, apparently | |
| 15:09:58 | efried | Cause it's crucial that the content of a public repo be strongly encrypted. | |
| 15:10:14 | efried | Is that, what, so we don't get MITMs injecting viruses into the codebase for us? | |
| 15:11:03 | efried | tox -e py27 -- trojan_horse ? | |
| 15:11:30 | jaypipes | edleafe, cdent: do we have a bug in placement that diga might be able to pick up? he's looking for some work in placement/scheduler. | |
| 15:12:14 | cfriesen | is it possible to use SSH URLs with github? | |
| 15:12:27 | cfriesen | I don't see any on the nova page | |
| 15:12:55 | jroll | cfriesen: yep, git@github.com:openstack/nova | |
| 15:13:03 | jroll | need to add your public key in settings | |
| 15:13:08 | edleafe | jaypipes: diga: there's always https://bugs.launchpad.net/nova/+bugs?field.tag=placement as a starting point | |
| 15:13:20 | cfriesen | jroll: thanks | |
| 15:13:25 | jroll | np | |
| 15:13:48 | diga | edleafe: Sure, will go through it | |
| 15:14:49 | diga | jaypipes: Thank you for your help | |
| 15:16:43 | jaypipes | diga: if I come across something for you, I will let you know. | |
| 15:17:01 | diga | jaypipes: Sure | |