Earlier  
Posted Nick Remark
#openstack-nova - 2017-01-20
12:46:21 bauzas just taking a few mins for refueling myself at $lunch, and then back quickly
12:46:26 BobBall snikitin: Sure - the xenapi drive could easily translate NaN to None if it makes more sense up the stack
12:51:59 snikitin BobBall: I checked. It works with sleep(10)! Thank you!
12:53:44 dims sean-k-mooney : nah. no need to rush it. py35 is just experiment anyway at the moment
12:54:09 markus_z sdague: We could make the testing gap for live-migration a little smaller with https://review.openstack.org/#/c/347471/ Would be nice if you could find the time for that.
12:54:26 markus_z mriedem: Maybe you too, I answered your questions there ^
12:55:40 sean-k-mooney dims: ok ill try and get a linux bridge devstack enviornment up and running next week and we can also look into adding a linux bridge job to os-vif also going forward
12:55:53 dims ++ sean-k-mooney thansk!
13:08:26 jaypipes dims: what's the latest status on the mox3 thing? has that revert merged?
13:09:06 dims jaypipes : y, should be green. please rebase if you still see an issue
13:09:18 jaypipes dims: will do. cheers!
13:25:57 mriedem getting this resource providers patch in, which is pretty simple, closes out the aggregates stuff for ocata https://review.openstack.org/#/c/407309/
13:26:01 mriedem needs another core ^
13:26:20 leakypipes mriedem: I'm on it, captain.
13:26:28 leakypipes oh wait, that's mine.
13:26:29 mriedem leakypipes: it's yours
13:26:30 mriedem ha
13:26:30 leakypipes never mind :)
13:27:21 mriedem leakypipes: you could deal with the -1 on this though https://review.openstack.org/#/c/404472/
13:27:43 leakypipes mriedem: ya, will do.
13:28:02 leakypipes mriedem: just trying to get sahid's reserved CPUs patches reviewed.
13:28:08 mriedem melwitt_: sdague: i got the discover_hosts running in d-g http://logs.openstack.org/05/423005/2/check/gate-tempest-dsvm-neutron-full-ubuntu-xenial/2704d02/logs/discover-hosts.txt.gz
13:28:50 mriedem needs to be fixed up for stable branches though
13:28:53 mriedem and grenade
13:29:22 mriedem http://logs.openstack.org/05/423005/2/check/gate-tempest-dsvm-neutron-multinode-full-ubuntu-xenial-nv/d230b29/logs/discover-hosts.txt.gz
13:29:56 openstackgerrit Timofey Durakov proposed openstack/nova: Make all timestamps formats equal https://review.openstack.org/421981
13:32:23 tbachman a little levity
13:32:26 tbachman is
13:32:27 tbachman needed
13:33:33 leakypipes tbachman: indeed :(
13:34:32 mfeoktistov Hello! Dear cores, can you please look at https://review.openstack.org/#/c/312488/
13:36:45 openstackgerrit OpenStack Proposal Bot proposed openstack/nova: Updated from global requirements https://review.openstack.org/422323
13:37:33 sdague mriedem: cool
13:39:52 sdague mriedem: once I get some breakfast and this set of grenade results, I'll take a look
13:40:28 mriedem the d-g change isn't really ready yet, i need to make it conditional on branches, or put a script in devstack to run discover_hosts and then d-g would only run it if that script exists
13:40:37 mriedem https://review.openstack.org/#/c/423005/2/devstack-vm-gate.sh
13:41:23 mriedem if you have input on what's the preferred approach there that would be good
13:42:13 leakypipes tbachman: :)
13:43:45 mdbooth mriedem: NFS https://review.openstack.org/#/c/383859/
13:43:59 mriedem blarg shared file systems
13:44:09 mdbooth I've actually been hammering on this over the last couple of days because it fixes another bug too
13:44:40 mdbooth If you suspend an instance with an attached volume, the volume can be unmounted while it's suspended
13:44:48 mdbooth So it fails when you resume it
13:44:55 mdbooth Confirmed this patch fixes that bug
13:45:53 mdbooth https://review.openstack.org/#/c/383859/
13:46:24 mdbooth Except it's not a race, it's entirely deterministic in this case
13:47:20 mriedem ok
13:47:55 mriedem i'll be honest i'm going to have a very distracted day today, trying to wrap things up before flying out for vacation tomorrow
13:48:03 BobBall snikitin: Glad to hear it
13:48:14 mdbooth Ah, it's already in there
13:49:20 openstackgerrit ChangBo Guo(gcb) proposed openstack/nova: Set access_policy for messaging's dispatcher https://review.openstack.org/408494
13:50:40 mdbooth Unrelated, can anybody check my memory for me: https://review.openstack.org/#/c/376350/ . The behaviour of reboot where is tries to fix potential local hypervisor problems is intentional, right?
13:51:21 mdbooth i.e. recreating backing files and rewriting the domain xml.
13:51:53 mdbooth Both of these behaviours are undesirable, imho, but iiuc they're relied upon by operators. Is that right?
13:52:13 mdbooth sdague: ^^^
13:52:20 openstackgerrit OpenStack Proposal Bot proposed openstack/nova: Updated from global requirements https://review.openstack.org/422323
13:52:25 bauzas mriedem: FYI, the scheduler change is blocked because also another problem due to us not having yet a fixture for our functional tests
13:52:58 bauzas mriedem: sdague: there is a Gabbi fixture in our gabbi branch, but not for the functional tests
13:53:32 bauzas sdague: any reason why when calling the placement API using urllib2 and noauth2 middleware, it still returns 401 ?
13:55:19 mdbooth mriedem: I ran the latest patch version against the devstack nfs CI, btw. It passed.
13:55:24 johnthetubaguy melwitt_: mriedem: I have been reading that quota stuff just now, any reason we can't change ProjectUserQuota to have user_id column as nullable, and just kill the Quota table? (or add a nullable user_id into the Quota table, and kill ProjectUserQuota)?
13:56:05 mriedem johnthetubaguy: i don't know off the top of my head, i know the tables are used based on resource type
13:56:17 mriedem i don't know how much of that is still valid after the move
13:57:49 johnthetubaguy mriedem: no worries, I am going to keep reading
13:58:57 mriedem i would assume things stay the same in those tables when we move to the api db, they might change their function or necessity after the counting quotas stuff is in, but i'd probably lean toward making any changes to the data model in a later release
14:03:10 sahid mdbooth: about https://review.openstack.org/#/c/376350/ - i do not understand your points
14:03:40 sahid if there the domain XML can be caorrupted in someways to we probzbly have to fix the root cause
14:03:50 sahid same for the disks of instance
14:05:46 openstackgerrit OpenStack Proposal Bot proposed openstack/nova: Updated from global requirements https://review.openstack.org/422323
14:05:55 mdbooth sahid: I've posted a hopefully clearer response on the review.
14:05:58 sahid if you can explaining or at least report a bug so i could fix both of these issues but like that it's just you want something broken to stay broken
14:06:11 mdbooth Specific bugs misses the point.
14:07:05 mdbooth sahid: I was also unaware of this apparently undocumented design decision, which is why I'm hoping to get some additional input.
14:07:43 sahid yes because that seems weird the hard-reboot should be helpfull when the guest operating system get stuck
14:08:04 mdbooth It's about the hypervisor rather than the guest OS, I think.
14:08:12 mdbooth Well, I guess it's about either.
14:08:24 sahid but i do not think it's how operators should repair an instance "broken"
14:09:03 mdbooth It's like: steps to take before defenestrating the instance:
14:09:07 mdbooth 1. reboot
14:09:09 mdbooth 2. ...
14:09:37 sahid but we need to be clear on what we are talking about, the qemu process or the guest operating system ?
14:09:57 mdbooth s/qemu process/hypervisor/
14:10:12 mdbooth The aspect of reboot I'm talking about relates to the hypervisor
14:10:17 mdbooth Not the guest OS
14:10:34 sahid that seems really sad so... we really want to fix an issue like that
14:10:40 mdbooth What issue?
14:10:49 sahid the one you are talking about, no ?
14:10:56 mdbooth I'm not talking about an issue
14:11:02 mdbooth I'm talking about *any* issue
14:11:24 mdbooth I'm talking about an imaginary, as yet undiscovered bug which has resulted in inconsistent state in the hypervisor
14:11:49 mdbooth One of the goals of reboot is to try to get the instance going again anyway
14:12:03 mdbooth It would be nice if it wasn't
14:12:12 mdbooth But to the best of my knowledge, it is
14:15:54 sahid ok so you don't want me to fix this because there is an imaginary/undiscovered bug
14:16:03 mdbooth Incidentally, as I mentioned in one of my review comments, I think this is a very useful tool for operators to have. However, I also think it's problematic and ironically a potential source of bugs to do it in reboot.
14:16:13 sahid interesting... i have 2 well real bugs to show you because of this code
14:16:34 mdbooth sahid: No, I don't want you to do this because (IIUC) operators rely on this behaviour.
14:16:47 mdbooth Ideally we would separate it from reboot.
14:17:00 sahid if they do, so we should explain to them they should not i guess
14:17:11 sahid rscue and rebuild are better

Earlier   Later