| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-04-24 | |||
| 18:25:52 | sean-k-mooney | that was... fun to fix | |
| 18:26:10 | jaypipes | melwitt, mnaser: "The api_context_manager.writer decorators are not nestable." <-- I am almost positive that statement is incorrect. AFAIK, any methods that are decorated by transaction context manager will *enlist* the decorated function's DB calls into an existing transaction (and if there is no existing transaction, one will automatically be created the first time a SQL statement is called (via ORM or core expression API in sqlalchemy) | |
| 18:27:32 | melwitt | jaypipes: I thought the same thing so I tried that approach first, and in my func test I found that if the 2nd create() failed, the 1st create() remained in the sqlite database anyway | |
| 18:28:06 | jaypipes | melwitt: are they using the same RequestContext? | |
| 18:28:11 | melwitt | so I changed to the approach that's currently in the patch now | |
| 18:28:12 | melwitt | yes | |
| 18:28:21 | jaypipes | hmmm. | |
| 18:29:20 | jaypipes | melwitt: and both in the same thread of execution, yeah? | |
| 18:29:26 | jaypipes | melwitt: both create() calls, that is... | |
| 18:29:30 | melwitt | it's possible I did something wrong but I'm not sure how. I had originally decorated a function in compute/api with a writer decorator and just put all 3 create() calls in it | |
| 18:29:45 | melwitt | yeah | |
| 18:30:13 | jaypipes | melwitt: interesting. | |
| 18:30:27 | melwitt | the create() methods themselves are not decorated but they call decorated methods inside them. I dunno if that might be why | |
| 18:30:40 | jaypipes | melwitt: ftr, engineface's transaction context manager *should* only enlist into a single transaction (here is the relevant code, FWIW: https://github.com/openstack/oslo.db/blob/master/oslo_db/sqlalchemy/enginefacade.py#L1050-L1052) | |
| 18:30:59 | jaypipes | melwitt: ok, lemme look further into this and see what might be causing this issue. | |
| 18:31:33 | jaypipes | melwitt: just wanted to make sure that all the calls were actually expected to be in the same RequestContext | |
| 18:31:42 | jaypipes | s/to be in the/using the/ | |
| 18:32:12 | melwitt | jaypipes: ok, thanks. I don't want to take up too much of your time on this | |
| 18:32:34 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Microversion 2.73: Support adding the reason behind a server lock https://review.opendev.org/648662 | |
| 18:32:59 | jaypipes | melwitt: not a worry, Melanie :) | |
| 18:33:05 | melwitt | jaypipes: it's a little complex in that the create() methods will use the object's internal self._context but all the objects self._context are set to the same RequestContext | |
| 18:33:41 | melwitt | but maybe that aspect can cause a break in the decorator nesting-ness? I'm not sure | |
| 18:34:49 | jaypipes | yeah, not entirely sure either :) will dig further. | |
| 18:56:02 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Microversion 2.73: Support adding the reason behind a server lock https://review.opendev.org/648662 | |
| 19:07:17 | melwitt | jaypipes: based on the code you linked, it really should work to nest it so I went back and tried it all again and it looks like it does indeed work properly. I must have messed something up last time, sorry for that :( being able to nest makes the code 1000x better so thank you for pointing it out. I'm going to respin | |
| 19:12:28 | melwitt | jaypipes++ | |
| 19:12:50 | tssurya | mriedem: following up on our discussion yesterday regarding filters/sorting I have a doubt here: https://review.opendev.org/#/c/648662/6/nova/api/openstack/compute/schemas/servers.py@544 could you leave a comment when you get time ? | |
| 19:21:33 | dansmith | tssurya: see if I answered your question | |
| 19:21:48 | melwitt | turns out what I did wrong was not pass the RequestContext to the decorated outer method. it needs to be passed in for the decorator to start the transaction and then that will get used by the subsequent create() methods | |
| 19:22:14 | tssurya | dansmith: thanks looking | |
| 19:23:15 | tssurya | dansmith: ah you mean do something like 'sort_key': multi_params(VALID_SORT_KEYS_V273) ?, | |
| 19:23:23 | dansmith | tssurya: yeah | |
| 19:23:29 | tssurya | got it, I'll try to update that patch :) thanks! | |
| 19:25:40 | openstackgerrit | melanie witt proposed openstack/nova master: Create request spec, build request and mappings in one transaction https://review.opendev.org/586742 | |
| 19:36:34 | jaypipes | melwitt: no worries, Melanie! :) | |
| 19:40:23 | openstackgerrit | Dan Smith proposed openstack/nova master: Add image type capability flags and trait conversions https://review.opendev.org/652710 | |
| 19:40:24 | openstackgerrit | Dan Smith proposed openstack/nova master: Expose Hyper-V supported image types https://review.opendev.org/655137 | |
| 19:40:24 | openstackgerrit | Dan Smith proposed openstack/nova master: Make libvirt expose supported image types https://review.opendev.org/653454 | |
| 19:42:01 | JamesBenson | hey all | |
| 19:42:04 | JamesBenson | I'm getting a nova_compute issue with this error: https://paste.fedoraproject.org/paste/EZYsQ8eDlp9gDjA8BB1YiA/ | |
| 19:42:12 | JamesBenson | This is with a xen hypervisor | |
| 19:42:38 | JamesBenson | I'm installed os_xenapi with pip | |
| 19:46:27 | dansmith | oh so you're the one! | |
| 19:51:59 | JamesBenson | dansmith??? | |
| 19:52:09 | dansmith | JamesBenson: ...guy still using xen :) | |
| 19:52:43 | JamesBenson | dansmith, trust me, this is the first time and only because we are getting software that is based off of the xen hypervisor. | |
| 19:52:54 | JamesBenson | needless to say, I'm finding bugs. | |
| 19:53:03 | dansmith | I'm assuming this is the nova-compute log, but it looks really strange. definitely seems like you're failing to import os_xenapi for some reason that I can't help you with | |
| 19:53:27 | JamesBenson | yes, nova-compute log | |
| 19:53:31 | dansmith | the db accesses are super strange, but I'd resolve the import issue first in case that is kicking it into some weird state where it's trying to survey the db when it shouldn't | |
| 19:53:33 | JamesBenson | it's coming from kolla-ansible | |
| 19:53:54 | JamesBenson | So in the docker container, I can open python console and import sucessfully | |
| 19:54:49 | JamesBenson | I did have to tar the dir in site-packages, cp it over and expand... but console did work. | |
| 19:55:28 | dansmith | it's hard to tell from the traces, but I guess it's possible that os_xenapi is trying to access the db on init and that is preventing it from being imported, but that has been disallowed for many years | |
| 19:55:32 | dansmith | so I wouldn't know what to say | |
| 20:01:06 | JamesBenson | dansmith, are you familiar with kolla? | |
| 20:02:21 | dansmith | nope | |
| 20:09:04 | JamesBenson | Is it possible to check that nova is using openstack's os-xenapi instead of python-os-xenapi? | |
| 20:09:19 | JamesBenson | I've never played with nova code explicitly. | |
| 20:15:39 | efried | JamesBenson: The nova requirements.txt file lists: | |
| 20:15:39 | efried | requirements.txt:os-xenapi>=0.3.3 # Apache-2.0 | |
| 20:16:02 | efried | which means whatever happens when you say pip install 'os-xenapi>=0.3.3' | |
| 20:16:56 | efried | aspiers: done, thanks for the reminder. | |
| 20:18:51 | efried | sean-k-mooney: re libvirt-video-device-models, the action from last week was for kashyap to have a look at it and I would approve it if he was on board. | |
| 20:19:25 | efried | I know kashyap has been one-armed-wallpaperer busy for the past few days... | |
| 20:36:10 | sean-k-mooney | efried: ya that fine | |
| 20:36:18 | sean-k-mooney | it cna wait until after the ptg | |
| 20:36:37 | sean-k-mooney | i was going to add it to the runway list but noticed it wasnt approved so held off | |
| 20:36:55 | sean-k-mooney | i have set a workflow -1 on the nova patch in the inerim | |
| 20:40:47 | JamesBenson | efried, so I wonder why it wasn't installed by default | |
| 20:41:16 | efried | sorry, I wasn't following the conversation, let me read scrollback... | |
| 20:41:39 | gmann | efried: regarding PT schedule, can we move 'API inconsistency cleanup' L276 on Thursday or friday ? I would not be available on Saturday due to my flight | |
| 20:41:46 | gmann | PTG | |
| 20:42:03 | efried | gmann: Roger that, will shuffle, thanks for the heads up. | |
| 20:42:17 | gmann | efried: thanks . | |
| 20:42:18 | JamesBenson | efried, sean-k-mooney could you provide insight too, I've seen you in kolla :-) | |
| 20:42:36 | efried | you haven't seen *me* in kolla :P | |
| 20:42:52 | JamesBenson | sorry to pick on you explicitly, oh man, sorry efried! | |
| 20:43:00 | sean-k-mooney | JamesBenson: context? | |
| 20:43:16 | efried | (I have nothing against kolla, just completely ignorant/inexperienced there) | |
| 20:43:44 | sean-k-mooney | reading back | |
| 20:43:57 | JamesBenson | sean-k-mooney: I'm doing kolla with xen, the nova_compute container is having issues with os_xenapi and six, I had to manually install them, but still vomits on itself. | |
| 20:44:34 | JamesBenson | sean-k-mooney, check out the paste for the error log... | |
| 20:45:41 | sean-k-mooney | JamesBenson: i honestly did not know kolla-ansible supproted xen i always used it with kvm | |
| 20:45:58 | JamesBenson | likewise, until we got software that needs a xenblanket... | |
| 20:46:48 | sean-k-mooney | i would gues in addtion to installing xen you might need to run some db migrations | |
| 20:47:27 | sean-k-mooney | oh xen server is supported now https://github.com/openstack/kolla-ansible/blob/23415bf8bb8179a966d1c10bd46e6cb9045f2b5d/doc/source/reference/compute/xenserver-guide.rst | |
| 20:47:28 | JamesBenson | doing this little experiment, I'm finding bugs in several different openstack processes... :-( | |
| 20:47:37 | JamesBenson | yeah | |
| 20:47:54 | sean-k-mooney | what version of python are you using | |
| 20:48:02 | sean-k-mooney | i assume python 2 | |
| 20:48:03 | JamesBenson | this is version 2 still | |
| 20:48:24 | sean-k-mooney | ya it 2.7 from the logs cool | |
| 20:49:05 | sean-k-mooney | so this is in the cells scater gather code | |
| 20:49:26 | sean-k-mooney | we indocuded explcitly use fo eventlets there | |
| 20:49:43 | JamesBenson | ? | |
| 20:50:08 | sean-k-mooney | in stien we intoduced a parallel cell list feature | |
| 20:50:14 | JamesBenson | yes, I think it was failing at the cells spot in ansible | |
| 20:50:23 | JamesBenson | I'm deploying using 7.0.1 | |
| 20:50:54 | sean-k-mooney | it was implemented using eventlets expclitly but that means in stien you need to monkey patch the nova api now | |