| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-29 | |||
| 16:06:39 | dansmith | sauloaugusto: that doesn't sound like a cells-related thing | |
| 16:07:30 | dansmith | (the cells code doesn't do anything special with users/tenants) | |
| 16:07:33 | cdent | efried: having allocations against physical hosts (instead of the cluster) cannot work because instances move and we've declared the virt driver is not allowed to manipulate allocations | |
| 16:07:56 | efried | cdent Yeah, I see where that's a problem. I don't have an answer for that. | |
| 16:08:08 | cdent | thus inventory on resource pools | |
| 16:08:17 | efried | and resultant hackage. | |
| 16:08:25 | efried | which is unfortunate. | |
| 16:08:32 | maciejjozefczyk | jaypipes mgagne: Need to go. Let me know in bug report about what you decided okey ;) I'll update the patch then | |
| 16:08:33 | cdent | because that is the level at which accounting is desired | |
| 16:08:43 | jaypipes | maciejjozefczyk: will do, thanks mate :) | |
| 16:09:49 | efried | cdent Well, at the very least the resource pools should not be children in the same tree. They should be roots. | |
| 16:10:15 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Rollback instance.image_ref on failed rebuild https://review.openstack.org/538961 | |
| 16:10:16 | mriedem | artom: here is the fix ^ let me know when you have an LP bug number so i can update the references in here | |
| 16:10:33 | artom | mriedem, yep, writing it up as we speak | |
| 16:11:02 | cdent | efried: remind me (because I'm half asleep) of the mechanism to go from a root (when in nova-scheduler) to the compute node where the spawn can be called? | |
| 16:11:14 | sauloaugusto | dansmith: I think that is related , because the error start after I do themigration steps from nova . After that I start to see the Can't upgrade a READER transaction to a WRITER mid-transaction error on nova-api.log . | |
| 16:11:20 | cdent | efried: if the root is in fact not that compute-monde | |
| 16:11:26 | artom | mriedem, so we're rolling back the image but not other things that could change, like keypair? | |
| 16:11:43 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add regression test for bug 1735407 https://review.openstack.org/526095 | |
| 16:11:45 | openstack | bug 1735407 in OpenStack Compute (nova) "[Nova] Evacuation doesn't respect anti-affinity rules" [Medium,In progress] https://launchpad.net/bugs/1735407 - Assigned to Balazs Gibizer (balazs-gibizer) | |
| 16:11:45 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Add late server group policy check to rebuild https://review.openstack.org/525242 | |
| 16:11:48 | mriedem | artom: yeah - which was my original complaint in the earlier fix | |
| 16:12:03 | dansmith | sauloaugusto: the migration steps from no cells to one cell were required before pike | |
| 16:12:09 | efried | cdent Not sure we quite have that mechanism yet. | |
| 16:12:13 | mriedem | artom: we can't really roll everything back with what we have today in the conductor code | |
| 16:12:35 | mriedem | we'd either have to change the rpc cast to a call, or move the code that changes the instance from the api to conductor | |
| 16:12:37 | cdent | efried: indeed, thus why I've been modelling it the way I've been | |
| 16:12:40 | efried | cdent Yeah, a way to tie these brother-roots back to the compute host for purposes of allocation and deploy. | |
| 16:12:44 | cdent | if it is a child you know where to go | |
| 16:12:50 | mriedem | hell, maybe we should have just moved the instance.save() from api to conductor... | |
| 16:12:50 | artom | mriedem, yeah... I guess it's fine as a bandaid for now? Ideally we need to come back to this and fix it properly, maybe like what Andrey was proposing | |
| 16:12:52 | cdent | because | |
| 16:12:54 | cdent | it is a child | |
| 16:13:04 | mriedem | artom: yes this is a "tactical fix" | |
| 16:13:13 | cdent | a resource provider withing a compute-node is _obviously_ a child | |
| 16:13:22 | efried | cdent But if it's a child, the scheduler will happily deploy an instance with VCPU from pool1, MEMORY_MB from pool2, and DISK_GB from pool3. | |
| 16:13:24 | cdent | and it seems to me that the ironic model might be the thing that's weird | |
| 16:13:25 | artom | mriedem, heh, code for "someone else can deal with it once I'm retired" ;) | |
| 16:13:38 | efried | cdent Unless you *always* use a numbered granular group. Which doesn't seem like the right answer. | |
| 16:13:43 | mriedem | maybe - it's just something one of my old managers at ibm always said, | |
| 16:13:48 | cfriesen | jaypipes: for https://bugs.launchpad.net/nova/+bug/1742747 do we look at the cpu_allocation_ratio of the first host aggregate, or do we look for the first host aggregate that has cpu_allocation_ratio set? | |
| 16:13:49 | openstack | Launchpad bug 1742747 in OpenStack Compute (nova) "RT overrides default allocation_ratios for ram cpu and disk" [Undecided,In progress] - Assigned to Maciej Jozefczyk (maciej.jozefczyk) | |
| 16:13:54 | mriedem | "do we have a tactical fix while we work on the long-term strategic fix" | |
| 16:14:16 | artom | mriedem, not a bad way of thinking | |
| 16:14:26 | efried | I was doing a word puzzle the other day where the clue was "strategic" and the answer was "tactical". I thought how the IBM ppt-jockeys would flip out at that. | |
| 16:14:38 | artom | awaugama, you around? Since you're the cause of all this, if we build you our proposed tactical fix, you want to try and break it again? | |
| 16:14:39 | sauloaugusto | dansmith: Yes I did that, and I get get list o admin instances , and also create new instances at that . The problem that I can not do nothing at all other tenants . | |
| 16:14:53 | artom | Maybe if we let QE loose on it *before* merging it, we'll avoid the pain? | |
| 16:15:03 | awaugama | artom: I can do some sanity checks on it | |
| 16:15:09 | mriedem | artom: that never seems to happen | |
| 16:15:13 | mriedem | until it's in product | |
| 16:15:24 | awaugama | artom, and *Technically* I'm just the warning light, i'm not the cause of the issue | |
| 16:15:47 | artom | awaugama, hah, sorry, should have added a ;) or /s in there somewher e:) | |
| 16:15:52 | awaugama | ;) | |
| 16:15:58 | cdent | efried: these issues are why I pressed rado to start talking about and experimenting with this stuff. I think the sort of gravitational mechanics of nested providers is going to have lots of weird | |
| 16:16:23 | cdent | and I'd much prefer to see us working from concrete situations then not | |
| 16:16:48 | efried | cdent Agree. At the moment I'm actually leaning towards the thing I originally said was the worst idea: always using a single numbered request group. | |
| 16:17:59 | Spazmotic | Always good when the best idea is your worst idea | |
| 16:21:07 | cdent | efried: I guess we have time to experiement... | |
| 16:25:35 | artom | mriedem, https://bugs.launchpad.net/nova/+bug/1746032 | |
| 16:25:36 | openstack | Launchpad bug 1746032 in OpenStack Compute (nova) "By rebuilding twice with the same "forbidden" image one can circumvent scheduler rebuild restrictions" [Undecided,New] | |
| 16:27:34 | mriedem | artom: L145 https://etherpad.openstack.org/p/nova-ptg-rocky | |
| 16:28:14 | artom | mriedem, oh hey and I'll actually be there this time :) | |
| 16:28:32 | mriedem | we can finally meet, face to face, and settle all the scores | |
| 16:28:38 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Enhance service restart in functional env https://review.openstack.org/512552 | |
| 16:28:38 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reproduce bug 1724172 in the functional test env https://review.openstack.org/512553 | |
| 16:28:39 | openstack | bug 1724172 in OpenStack Compute (nova) "Allocation of an evacuated instance is not cleaned on the source host if instance is not defined on the hypervisor" [Undecided,In progress] https://launchpad.net/bugs/1724172 - Assigned to Balazs Gibizer (balazs-gibizer) | |
| 16:28:39 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: cleanup evacuated instances not on hypervisor https://review.openstack.org/512623 | |
| 16:28:39 | mriedem | there can be only one | |
| 16:28:49 | artom | ... one of *what*? | |
| 16:29:00 | mriedem | idk, i'm just thinking about the quickening | |
| 16:29:04 | mriedem | even though that was scotland | |
| 16:29:29 | artom | Man, your references are out of control! | |
| 16:31:40 | edleafe | cdent: I've been following along, but don't have a clear picture of how things are arranged. Is there a diagram or something that would illustrate this? | |
| 16:32:22 | cdent | edleafe: a) which "this"?, b) I wish I never showed up today because I simply don't have the capacity to actual engage well with this topic | |
| 16:32:31 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Rollback instance.image_ref on failed rebuild https://review.openstack.org/538961 | |
| 16:32:32 | mriedem | artom: ok here we go, single patch ^ | |
| 16:32:55 | edleafe | cdent: the arrangement of entities in vmware | |
| 16:33:09 | edleafe | and which is the "root" that placement would be selecting | |
| 16:34:20 | mriedem | stable/newton is still open....but not sure we want to hold up EOL for this fix | |
| 16:35:03 | Spazmotic | Korea in.. 6 days | |
| 16:35:05 | Spazmotic | Whew | |
| 16:36:06 | dansmith | man, newton is like the undead release | |
| 16:36:15 | efried | edleafe I was considering drawing that up, along with an executive summary of this conversation, and putting it all in a response to the ML thread. | |
| 16:36:32 | artom | Can we call U 'undead'? As an hommage? | |
| 16:36:53 | cdent | edleafe: not that I'm aware of at this time, but I'll check with rado. if efried is able to do something (even if it has errors), that provides at least a starting point | |
| 16:37:10 | cdent | the "root" I was thinking of was "compute-node" | |
| 16:37:11 | mriedem | i'll say it again, the path to LTS upstream is just never EOL'ing anything | |
| 16:37:21 | edleafe | cdent: ok, thanks. I assumed that there must be some internal documentation that would be helpful | |
| 16:38:12 | cdent | edleafe: could very well be, but if there are pretty pictures I haven't seen them. That doesn't mean it doesn't exist. I interact _very_ little on that side of things. | |
| 16:38:55 | Spazmotic | Anyone know any of the cores familiar with XenAPI drivers? Besides Garbutt that is, I got his attention on but was curious if any others were familiar that I could poke :D | |
| 16:39:14 | openstackgerrit | Stephen Finucane proposed openstack/nova master: mypy: Add type annotations to 'nova.pci' https://review.openstack.org/538224 | |
| 16:39:14 | openstackgerrit | Stephen Finucane proposed openstack/nova master: mypy: Add 'types' module https://review.openstack.org/538225 | |
| 16:39:17 | edleafe | cdent: ok, cool. If you come across something, post it so we can all better understand what is needed | |
| 16:41:07 | efried | Spazmotic Maybe bauzas ? | |
| 16:41:36 | artom | Wasn't Bob Ball xenapi? Is he still around? | |
| 16:41:37 | Spazmotic | I know the driver isn't looked at too frequently by folks, so just didn't want to bark up the wrong trees wwhen I had questions or was looking for some eyeballs. | |
| 16:41:42 | Spazmotic | Yeah bob's still around but he's no longer core | |
| 16:42:09 | Spazmotic | He always gives me good ideas though so.. love me some Bob | |
| 16:47:27 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Rollback instance.image_ref on failed rebuild https://review.openstack.org/538961 | |