| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-09-04 | |||
| 10:48:12 | brinzhang | Emm.. I am in https://review.opendev.org/#/c/673133/14 this patch | |
| 10:48:28 | brinzhang | I will test in master now | |
| 10:49:08 | sean-k-mooney | if you have a typo like incorrect indentaion or other syntax errors test discovery will fail | |
| 10:49:10 | brinzhang | http://paste.openstack.org/show/770638/ it's a wrong director | |
| 10:50:02 | sean-k-mooney | it will also fail if you if you have tempory filtes create by some edirtor like emacs where it adds a # to the filename | |
| 10:51:07 | Sundar | gibi, Yes, we want to maximize the overlap by kicking off the binding as early as possible and wait for the ARQs as late as possible, but that is not easy without major surgery. So, I'll be content with dong it inside or after _build_resources. However, if we do: "with .... : foo(); bar()", then only foo() and bar() are done concurrently while wait | |
| 10:51:08 | Sundar | ing for the event, right? Also, foo and bar must both be Cyborg-related. | |
| 10:51:29 | gibi | Sundar: yes, only foo and bar will be parallel because when the with wait context manager exits it waits for the events | |
| 10:51:33 | gibi | Sundar: I don't see why foo and bar needs to be Cyborg related | |
| 10:52:27 | brinzhang | sean-k-mooney: I will delete the edit patch https://review.opendev.org/#/c/673133/14, and then re-fetch it. | |
| 10:53:21 | Sundar | gibi: The timeout in the with will cover both foo and bar. Is it reasonable to impose that Cyborg ARQ bind timeout on non-Cyborg activities? it is 300 seconds by default. If it is ok, it will get us more concurrency. | |
| 11:00:13 | gibi | Sundar: the timeout is not for foo and bar it is for waiting for the events | |
| 11:01:17 | gibi | Sundar: also if the boot process cannot procede without such events then it is OK to wait for the events | |
| 11:03:50 | Sundar | gibi: What do you think of waiting for the events in _build_resources, but actually querying Cyborg for ARQs only in the virt driver's spawn? If we do the query when the event comes, we have to store the ARQs in the instance object (or elsewhere), which will require changes to objects and db. | |
| 11:05:16 | gibi | Sundar: I think it is better to wait earlier than potenitally loosing notifications as we start waiting too late | |
| 11:05:46 | gibi | Sundar: I think you should also ask others, like dansmith about this problem | |
| 11:07:27 | gibi | Sundar: if you start waiting in _build_resources then I would do the query in the virt driver instead of passing the ARQ down | |
| 11:07:38 | gibi | Sundar: to limit the impact | |
| 11:07:49 | Sundar | gibi: Great. That's what I had in mind. :) | |
| 11:08:26 | Sundar | Thank you very much, gibi. | |
| 11:08:37 | Sundar | Have a good day. | |
| 11:08:42 | gibi | Sundar: same to you | |
| 11:14:43 | sean-k-mooney | gibi: would you have time to review https://review.opendev.org/#/q/topic:bp/image-metadata-prefiltering+(status:open+OR+status:merged) today? im aiming to get that merged and free up a runway slot by the end of the week | |
| 11:15:05 | sean-k-mooney | the 3 remaining pataches are relitivly short | |
| 11:15:30 | gibi | sean-k-mooney: I will try... | |
| 11:16:48 | sean-k-mooney | gibi: thanks if you dont get to it its ok i have others to bug too like bauzas | |
| 11:17:50 | sean-k-mooney | bauzas: feel like re reviewing https://review.opendev.org/#/q/topic:bp/image-metadata-prefiltering+(status:open) | |
| 11:20:48 | kashyap | aspiers: gibi: Commented here: https://review.opendev.org/#/c/644565/49/nova/virt/libvirt/utils.py@546 | |
| 11:21:25 | sean-k-mooney | artom: i see you currently dont have any ci jobs running using the multi numa job so im going to swap it over too the new lables for FN | |
| 11:21:42 | artom | sean-k-mooney, sure | |
| 11:21:45 | sean-k-mooney | im also going to reduce the concurance to 1 | |
| 11:22:24 | artom | sean-k-mooney, unless I'm missing something, the ball's in the reviewers's court | |
| 11:22:39 | sean-k-mooney | assuming you are happy with them for testingin im going to then swap to testing the cpu work stephen has been doinging | |
| 11:22:55 | gibi | kashyap: thanks! | |
| 11:23:17 | artom | Though I need to play with the func test some more - the RPC pinning tests didn't pick up a thing they should have picked up | |
| 11:23:39 | artom | sean-k-mooney, yep, that's fair, again much thanks for all your help | |
| 11:24:04 | sean-k-mooney | thats the last patch in the seriese right e.g. it wont block other patches landing | |
| 11:24:16 | artom | Func tests? Don't think so | |
| 11:24:27 | artom | We can still land tests after FF, right? | |
| 11:24:34 | sean-k-mooney | yes | |
| 11:24:41 | artom | Even assuming the worst and don't get them sorted before then | |
| 11:24:48 | sean-k-mooney | although its better to do it before | |
| 11:24:57 | artom | That's the plan :) | |
| 11:32:38 | brinzhang | sean-k-mooney, artom: I remember the unit test or functional test can run any linux env, depend on the devstack or openstack env is not necessary, is that? | |
| 11:32:56 | sean-k-mooney | brinzhang: correct | |
| 11:33:06 | sean-k-mooney | you do not need openstack or devstack to run them | |
| 11:33:08 | brinzhang | sean-k-mooney, artom: I checked to the master and run the test, also report the error | |
| 11:33:27 | sean-k-mooney | what os are you running on? | |
| 11:33:34 | brinzhang | Centos7 | |
| 11:33:48 | sean-k-mooney | brinzhang: you might want to clone a clean copy of nova and try it again | |
| 11:34:11 | sean-k-mooney | brinzhang: ok i tested on popos and it worked fine | |
| 11:34:19 | sean-k-mooney | i can check on rhel8 | |
| 11:34:31 | brinzhang | On Monday, It runs ok, but today I git pull | |
| 11:35:00 | sean-k-mooney | i know some test fail in rhel8 but i think that is due to the version of python it uses | |
| 11:35:53 | brinzhang | Emm, in my env, I was installed py27 and py37,the default is py27 | |
| 11:37:01 | sean-k-mooney | no i mean that using py36 on rhel8 some things fail that pass on py36 on pop_os/ubunutu | |
| 11:37:09 | brinzhang | Clone the clean code is so slowly, sometimes maybe disconnect, I don’t want to do that. | |
| 11:37:45 | sean-k-mooney | brinzhang: well i was only suggesting that since it might be related to unclean files in your working directory | |
| 11:38:02 | sean-k-mooney | have you checked there are no tempory files created by your ide/editor | |
| 11:38:13 | sean-k-mooney | im checking master on rhel8 now | |
| 11:38:51 | sean-k-mooney | i guess i can check with a centos container too | |
| 11:39:33 | brinzhang | I will check again in my working directory too, and try to clone it in another directory | |
| 11:40:00 | sean-k-mooney | you can do a local clone by the way | |
| 11:40:39 | sean-k-mooney | e.g. mkdir temp; cd temp; git clone ~/repos/nova; cd nova; tox -e ... | |
| 11:41:46 | sean-k-mooney | it passed for me on rhel8 | |
| 11:41:54 | sean-k-mooney | with no failurs at all | |
| 11:42:03 | sean-k-mooney | which is better then it normally does | |
| 11:42:38 | aspiers | sean-k-mooney: the issue with stestr and temporary editor files (e.g. from emacs) is fixed | |
| 11:43:08 | sean-k-mooney | aspiers: as of when | |
| 11:43:11 | aspiers | sean-k-mooney: https://github.com/mtreinish/stestr/issues/238 | |
| 11:43:26 | aspiers | 2 weeks ago | |
| 11:43:29 | sean-k-mooney | aspiers: i have hit its since march | |
| 11:43:30 | aspiers | or 3 | |
| 11:43:38 | aspiers | yeah you need to upgrade your stestr | |
| 11:43:45 | aspiers | 2.5.0 | |
| 11:44:02 | sean-k-mooney | maybe im just using whicever version tox installs | |
| 11:44:05 | aspiers | Turns out that reporting bugs sometimes helps get them fixed ;-) | |
| 11:44:14 | sean-k-mooney | although i have not recreate all my envs since then | |
| 11:44:24 | aspiers | stestr>=1.0.0 # Apache-2.0 | |
| 11:44:28 | aspiers | from test-requirements | |
| 11:44:36 | aspiers | we should bump that | |
| 11:44:36 | brinzhang | sean-k-mooney: yeah, cloning, but so slowly... | |
| 11:44:51 | sean-k-mooney | brinzhang: if your doing it locally it should be fast | |
| 11:45:00 | sean-k-mooney | e.g. the file system clone i suggested above | |
| 11:46:24 | brinzhang | git clone ~/repos/nova what do you mean? isnot use git clone https://review.opendev.org/openstack/nova clone to another directory? | |
| 11:47:28 | brinzhang | this is the clone speed "Receiving objects: 3% (21352/550825), 6.94 MiB | 27.00 KiB/s" | |
| 11:50:40 | openstackgerrit | Eric Fried proposed openstack/nova master: Bump min for oslo.service & .privsep to fix SIGHUP https://review.opendev.org/679974 | |
| 11:53:54 | openstackgerrit | Silvan Kaiser proposed openstack/nova stable/stein: Exec systemd-run without --user flag in Quobyte driver https://review.opendev.org/660705 | |
| 12:26:25 | sean-k-mooney | brinzhang: git can use filesystem urls | |
| 12:26:45 | sean-k-mooney | brinzhang: so if you have a copy of a git repo you can clone a second copy using the file sytem path | |
| 12:27:09 | sean-k-mooney | so for example i keep my dev repos under ~/repos | |
| 12:27:27 | sean-k-mooney | if i do "mkdir ~/temp; cd temp" | |
| 12:27:53 | efried | alex_xu, luyao: Are you around? | |
| 12:28:39 | sean-k-mooney | then do "git clone ~/repos/openstack/nova" | |
| 12:29:00 | sean-k-mooney | it give me a clean copy of the nova git tree in ~/temp/nova | |
| 12:29:37 | brinzhang | sean-k-moony: Clone completed in another directory, and run tox -e ok, you are right, maybe the tempory file cause this issue. | |
| 12:30:13 | luyao | efried: I'm here | |
| 12:30:36 | brinzhang | sean-k-moony: I know your mean now, and I do it like you were said :P | |
| 12:35:22 | efried | luyao: Do you need any help to make progress on the vpmem series at this point? Do you understand what dansmith is asking for on the bottom two patches? | |
| 12:38:11 | luyao | efried: I do have some questions on the patch anout DB change. | |