Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2017-08-31
15:13:59 sdague efried: api-ref doesn't need backporting
15:14:04 sdague only master is published
15:14:22 efried right, okay
15:14:53 efried sdague But the rst...
15:15:12 sdague efried: what about it?
15:15:21 efried could be backported
15:15:49 efried to provide the link for readers @pike level
15:16:44 sdague efried: oh, in that case you probably want to split the 2 up
15:16:49 sdague do the parameter fix first
15:16:55 sdague then do the rst separate
15:17:01 sdague because we don't backport api-ref
15:17:18 efried And we can't have a separate thing that just drops to pike?
15:17:29 efried has to be a backport?
15:17:37 sdague efried: you could modify the backport
15:17:43 sdague and drop that field
15:17:48 sdague sorry, that file
15:17:57 sdague it's just a cleaner backport if it was 2 patches
15:17:58 efried Yeah, wfm.
15:18:12 efried I'll split it up. And open a bug, cause that's required to backport, yah?
15:19:04 sdague efried: sure
15:25:03 openstackgerrit Matt Riedemann proposed openstack/nova master: Add recreate test for forced host evacuate not setting dest allocations https://review.openstack.org/499678
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

Earlier   Later