| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-08-31 | |||
| 15:28:46 | openstackgerrit | Eric Fried proposed openstack/nova master: [placement] api-ref GET /traits name:startswith https://review.openstack.org/499682 | |
| 15:29:05 | mriedem | gibi: replied in https://review.openstack.org/#/c/499399/ - basically, you're correct, but this is for backporting to pike, and we don't really support things like shared resource providers yet anyway | |
| 15:29:25 | mriedem | i think when we do, we remove this code and have conductor call the scheduler to sort that all out during the move operation | |
| 15:31:34 | openstackgerrit | Eric Fried proposed openstack/nova master: [placement] Update user doc with api-ref link https://review.openstack.org/499635 | |
| 15:37:11 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Create allocations against forced dest host during evacuate https://review.openstack.org/499399 | |
| 15:45:51 | mriedem | gah, why do we have nova.tests.unit.scheduler.test_utils and nova.tests.unit.scheduler.test_scheduler_utils?! | |
| 15:47:49 | artom | Back when I worked web hosting support, I reeeaaally wanted to answer those type of why questions ("why is server down?") with "because god hates you." | |
| 15:49:37 | vdrok | good morning folks! in ironic, we sometimes hit the issue with one of the smoke tests in tempest not being able to boot an instance on a specific host as RescheduledException happens. the reason seems to be this piece of code https://review.openstack.org/#/c/499545/2/nova/scheduler/utils.py. Is there a better way to achieve this kind of thing? as this does not look pretty | |
| 15:50:13 | openstackgerrit | Lucian Petrut proposed openstack/nova master: HyperV: Perform proper cleanup after failed instance spawns https://review.openstack.org/499690 | |
| 15:51:32 | vdrok | basically, for ironic it would be good to distinguish cases when len(force_hosts)==1 and still do reschedules in this case, as there are multiple nodes assigned to the host | |
| 15:54:14 | mriedem | 1:M :( | |
| 15:54:35 | mriedem | plus forcing anything | |
| 15:55:07 | vdrok | basically the failing test is https://github.com/openstack/tempest/blob/master/tempest/scenario/test_server_multinode.py#L40, we could skip it. but it kinda helps to ensure that hash ring works | |
| 15:57:06 | bauzas | mriedem: FWIW, I'm writing a new spec for changing the boot request to be using the requested_destination flag | |
| 15:57:16 | bauzas | mriedem: and no "force" flag to be used | |
| 15:57:39 | bauzas | mriedem: so we could just send force_hosts in hell | |
| 15:57:45 | bauzas | that said, there is a flaw | |
| 15:58:19 | bauzas | since live-migrate and evacuate only accept a single string for passing a target, the usual tuple (host,node) isn't possible | |
| 15:58:45 | bauzas | so in Ironic, you can't specify a specific ironic node to boot against | |
| 15:58:50 | bauzas | oops | |
| 15:58:51 | bauzas | to move | |
| 15:59:41 | vdrok | well, we don't live migrate or evacuate yet :) tho I've seen a spec to enable it in case of boot from volume | |
| 16:00:26 | bauzas | exactly this | |
| 16:00:39 | bauzas | so that's why it wasn't a problem for the move operations | |
| 16:01:07 | mriedem | there are TODOs all over the code when doing nodes[0] though | |
| 16:01:14 | bauzas | but if I'm writing a new spec for modifying the boot operation to use the same, then I need to think about how to pass a destination that is an Ironic node | |
| 16:01:44 | bauzas | mriedem: yeah, because Ironic doesn't support both evacuate and live-migrate so we don't really care | |
| 16:02:02 | mriedem | cleaning up the hundred TODOs around request spec usage in the code would also be nice | |
| 16:02:13 | mriedem | i'm going to be starting on some stuff like that in the conductor task api code | |
| 16:02:40 | bauzas | mriedem: you know that I was having an approved BP for cleaning up that mess | |
| 16:03:10 | bauzas | mriedem: the scheduler-claims vamped up all my implementation and review time but I seriously consider working on that again for Queens | |
| 16:03:29 | bauzas | that and the API microversion for changing how we pass a destination when booting | |
| 16:05:36 | dansmith | yeah, that mess was giving me heartache yesterday | |
| 16:06:46 | dansmith | gibi: around? | |
| 16:07:01 | dansmith | gibi: I think I'm failing a bunch of tests because of notification things, is that right? http://logs.openstack.org/50/498950/3/check/gate-nova-tox-functional-ubuntu-xenial/0a8068d/testr_results.html.gz | |
| 16:07:20 | bauzas | it wasn't fun I was away when you folks had those problems with the force flag and the Requestspec :( | |
| 16:07:51 | bauzas | drop me a ping next time, because I hardly read the ML when I'm off | |
| 16:18:56 | mriedem | lbragstad: at some point you should educate us on the new enhanced password in sql hashing stuff you guys have in keystone in pike, i saw that in release notes | |
| 16:19:03 | mriedem | we are storing cell mapping creds in the db | |
| 16:20:32 | lbragstad | mriedem: oh - it's pretty straight forward, most of the context for the change is in https://bugs.launchpad.net/keystone/+bug/1668503 | |
| 16:20:34 | openstack | Launchpad bug 1668503 in OpenStack Security Notes "sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing" [High,Fix committed] - Assigned to Luke Hinds (lhinds) | |
| 16:21:05 | lbragstad | mriedem: we generate a mapping of supported hashing mechanisms and use that when dealing with things we need to hash | |
| 16:21:14 | abhi89 | Hi guys.. can someone please review https://review.openstack.org/#/c/485121/.. | |
| 16:21:35 | lbragstad | mriedem: we pulled most of the password hashing logic into a separate module https://github.com/openstack/keystone/blob/master/keystone/common/password_hashing.py] | |
| 16:23:07 | mriedem | lbragstad: cool, thanks. sounds like dansmith has an alternative that he's been keeping secret too. | |
| 16:23:26 | lbragstad | mriedem: for hashing cells mapping creds? | |
| 16:23:52 | mriedem | for not storing them in the db | |
| 16:24:39 | lbragstad | interesting | |
| 16:24:52 | lbragstad | mriedem: after they are hashed, where are they stored? | |
| 16:25:19 | mriedem | config | |
| 16:25:29 | mriedem | something, idk | |
| 16:25:30 | lbragstad | ahh | |
| 16:25:33 | mriedem | that's why it's a secret | |
| 16:25:37 | dansmith | lbragstad: there's some way of configuring access creds by host/db, like DSN-based stuff | |
| 16:25:44 | dansmith | I haven't done it myself, you should talk to zzzeek, maybe in the oslo channel or something | |
| 16:25:57 | mriedem | dansmith: do you know if tripleo has this built in yet? | |
| 16:26:07 | mriedem | because i know they were complaining at one point about storing creds in the db | |
| 16:26:14 | dansmith | mriedem: not for creds reasons, | |
| 16:26:19 | mriedem | we could copy this into devstack | |
| 16:26:22 | dansmith | but for source ip, which I think was a similar thing | |
| 16:26:59 | dansmith | s/thing/solution/ | |
| 16:27:43 | lbragstad | interesting | |
| 16:44:38 | mriedem | ugh this always drives me crazy | |
| 16:44:39 | mriedem | "remote: (W) No changes between prior commit a0be7d3 and new commit d375135" | |
| 16:44:46 | mriedem | i'm re-ordering a series of changes to split some apart | |
| 16:44:59 | mriedem | when i try to git review, it won't let me b/c the base change hasn't changed at all | |
| 16:45:27 | mriedem | anyone know a special trick here? rebase doesn't work as i'm up to date | |
| 16:46:16 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add recreate test for forced host evacuate not setting dest allocations https://review.openstack.org/499678 | |
| 16:46:17 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Create allocations against forced dest host during evacuate https://review.openstack.org/499399 | |
| 16:46:18 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Refactor out claim_resources_on_destination into a utility https://review.openstack.org/499718 | |
| 16:46:27 | mriedem | update the commit message i guess | |
| 16:47:33 | user1124 | hello | |
| 16:47:38 | user1124 | i have a qq | |
| 16:47:59 | user1124 | does the nova policy for listing flavors actually work? | |
| 16:48:32 | user1124 | os_compute_api:flavors | |
| 16:48:37 | user1124 | os_compute_api:flavors:discoverable | |
| 16:57:36 | melwitt | kashyap: thanks for confirming that with Eric | |
| 17:06:57 | melwitt | mriedem: more swap volume fun https://review.openstack.org/#/c/407346/ swapping a bootable volume on a BFV instance for a non-bootable volume results in problems. that patch changes to deny bootable -> non-bootable in the API which seems right to me. I wanted to get more opinions | |
| 17:59:49 | openstackgerrit | Eric Fried proposed openstack/nova stable/pike: [placement] Update user doc with api-ref link https://review.openstack.org/499748 | |
| 18:00:03 | efried | Whee, stable branch bot notifications ^ | |
| 18:00:24 | cburgess | Anyone know if a resize of an instance will update the flavor extra specs stored in the instance_extra table for the instaince? | |
| 18:06:27 | dansmith | cburgess: it should yeah | |
| 18:06:32 | cburgess | Cool | |
| 18:06:35 | cburgess | Thanks | |
| 18:20:33 | mriedem | melwitt: swap from BFV to non-BFV, that's great | |
| 18:21:53 | melwitt | haha, yep | |
| 18:27:13 | efried | [resource providers] How does an individual resource get assigned an arbitrary property/value? | |
| 18:27:47 | efried | E.g. how does a PCI_DEVICE get a PCI address associated with it? | |
| 18:28:31 | efried | Perhaps the answer is, "In placement, it doesn't" ? | |
| 18:28:49 | dansmith | efried: in placement, it doesn't | |
| 18:28:57 | dansmith | efried: placement tracks resource types and quantities | |
| 18:29:03 | dansmith | it's not a k=v store | |
| 18:29:28 | openstackgerrit | Merged openstack/nova master: [placement] Update user doc with api-ref link https://review.openstack.org/499635 | |
| 18:29:37 | dansmith | placement tracks how many are present and allocated, | |
| 18:29:38 | dansmith | nova has to track *which* one is allocated | |
| 18:30:18 | efried | dansmith So placement knows how many, but not individual identifiers (UUIDs) | |
| 18:30:31 | efried | and nova knows which ones are allocated | |
| 18:30:32 | dansmith | correct, with an exception | |
| 18:30:39 | efried | where does the split occur? | |
| 18:31:06 | dansmith | if a pci device has multiple VFs, it might be modeled as a resource provider of VF_THINGY resources | |