| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-10-03 | |||
| 09:03:01 | stephenfin | Oh, perfect :) | |
| 09:03:07 | stephenfin | I'll review that now | |
| 09:38:38 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Add minimal documentation for RDP consoles https://review.openstack.org/606992 | |
| 09:38:38 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Rewrite the console doc https://review.openstack.org/606148 | |
| 09:38:39 | openstackgerrit | Stephen Finucane proposed openstack/nova master: conf: Allow 'nova-xvpvncproxy' to be called with CLI args https://review.openstack.org/606929 | |
| 09:38:39 | openstackgerrit | Stephen Finucane proposed openstack/nova master: doc: Add minimal documentation for MKS consoles https://review.openstack.org/606993 | |
| 09:47:20 | bauzas | does anyone know how to unstack/stack devstack with OFFLINE=True for a single project ? | |
| 09:47:37 | bauzas | I mean, I have all my stack but I just want to reinstall nova from master | |
| 09:49:22 | sean-k-mooney | bauzas: unstack, then manually git pull/checkout master on the nova repo set OFFLINE=True and stack | |
| 09:50:13 | sean-k-mooney | devstack wont update any of the projects and just used what is availabel | |
| 09:50:44 | sean-k-mooney | if you are unlucky you might need to pip install requirements form master if they have changed but that rarely is required | |
| 09:51:01 | bauzas | sean-k-mooney: that was my plan but I had the assumption that it would redeploy *all* projects from ENABLED_SERVICES | |
| 09:51:20 | sean-k-mooney | bauzas: it will | |
| 09:51:24 | sean-k-mooney | is that an issue | |
| 09:51:24 | bauzas | sean-k-mooney: my point is that I just want to init_nova() honestly | |
| 09:51:40 | sean-k-mooney | oh well dont unstack then | |
| 09:51:47 | bauzas | sean-k-mooney: my need is just that now that I reshaped some inventories, I just want to reshape back | |
| 09:52:22 | sean-k-mooney | just checkout the branch you want and run sudo systemctl restart devstack@n-* | |
| 09:53:16 | sean-k-mooney | if reshape is done by nova manage change restart to stop, then run nova manage and then start | |
| 09:55:29 | sean-k-mooney | as long as there are no schema migrations in between your current branch and the one your going to and no requiremetns changes you dont need to restack to change commit. just git checkout and restart service X | |
| 09:58:13 | cdent | yeah, that's what I was going to suggest | |
| 10:08:28 | stephenfin | bauzas: Could you look at pushing https://review.openstack.org/#/c/456572/ through? | |
| 10:17:37 | bauzas | sean-k-mooney: the problem is that the inventories are reshaped | |
| 10:17:50 | bauzas | sean-k-mooney: so a DB sync won't work, right? | |
| 10:17:59 | bauzas | because all the tables are there | |
| 10:18:14 | sean-k-mooney | bauzas: you can always drop the tables and then sync i guess | |
| 10:19:03 | bauzas | if I'm dropping the tables, I miss eg. https://github.com/openstack-dev/devstack/blob/master/lib/nova#L722-L723 | |
| 10:19:17 | bauzas | sean-k-mooney: ^ | |
| 10:20:36 | sean-k-mooney | i dont think there is any magical way to reshape witout deleting the reshaped RPs and restarting nova compute | |
| 10:20:45 | sean-k-mooney | that is what i ment by droping the tables | |
| 10:21:33 | bauzas | I think I'll just unstack/unstack for this time, and snapshot the DB | |
| 10:22:15 | bauzas | so, when I want to go backwards, I'll just use the dumpfile | |
| 10:22:17 | sean-k-mooney | ya that would work but other then for local testing is there a reason you are trying to downgrade? | |
| 10:22:35 | bauzas | sean-k-mooney: no, just testing indeed | |
| 10:23:31 | sean-k-mooney | if you have never used it https://www.heidisql.com/ is a great little tool for working with dbs | |
| 10:23:51 | bauzas | well | |
| 10:23:55 | sean-k-mooney | you need to run it under wine however | |
| 10:24:02 | bauzas | just for what I want, a mysqldump is enough | |
| 10:36:33 | sean-k-mooney | the one thing that annoys me more then the fact that we use a 80 charter line lenght is that we configure pep8 on spec for 79 charters | |
| 10:43:06 | openstackgerrit | sean mooney proposed openstack/nova-specs master: Add spec for sriov live migration https://review.openstack.org/605116 | |
| 10:57:24 | stephenfin | That moment of panic where you submit a review and spot a group of comments on older patchsets from the corner of your eye | |
| 10:57:48 | stephenfin | What *did* Stephen of June 2018 have to say about this... | |
| 11:08:59 | mdbooth | stephenfin: Fancy a bash at this one: https://review.openstack.org/#/c/605436/ I bitch about python3 in it ;) | |
| 11:09:24 | openstackgerrit | sean mooney proposed openstack/nova-specs master: Add spec for sriov live migration https://review.openstack.org/605116 | |
| 11:39:48 | sean-k-mooney | mdbooth: one basic question regarding https://review.openstack.org/#/c/605436/5. the compaute manger runs on the compute agent which is singel treaded but uses eventlets. so there is no paralleism but there is concurancy. so the lock you are aquiring is the mockey patched greenthread lock. is the reason we need the lock in the first place the fact we are doing db io and eventlets is cause us to yeild | |
| 11:39:51 | sean-k-mooney | allow another invocation of the fuction to start concurrently which races | |
| 11:40:43 | mdbooth | sean-k-mooney: Without going into details of locking, I find it's safest to ignore eventlets entirely when considering locking. | |
| 11:41:01 | mdbooth | When you tie yourself in knots trying to second guess a scheduler, you make lots of mistakes. | |
| 11:41:11 | sean-k-mooney | mdbooth: if we did not have eventlets in this case we would not need to lock | |
| 11:41:41 | mdbooth | It has multiple threads of execution. | |
| 11:41:49 | mdbooth | I don't care how we achieve that. | |
| 11:42:08 | sean-k-mooney | the compute manager is exectued from the compute agent right which does not have workers so only one thread | |
| 11:42:22 | mdbooth | Eventlets or python's 'threading' all have the same issues. | |
| 11:43:06 | sean-k-mooney | mdbooth: yes but my point is eventlets intoduced the concurency so that therefor we need a lock to be correct | |
| 11:43:33 | mdbooth | sean-k-mooney: We have concurrency. | |
| 11:43:55 | sean-k-mooney | if we did not have eventlets the previous code would have been correct because it would have been singel threaded | |
| 11:44:02 | sean-k-mooney | mdbooth: yep i know | |
| 11:44:28 | mdbooth | sean-k-mooney: Sure. We do have concurrency, though. It uses eventlets. | |
| 11:44:30 | sean-k-mooney | just makeing sure i understand the subtelties of the patch. this is an example of why i hate eventlets it hides concurancy | |
| 11:44:50 | mdbooth | sean-k-mooney: It doesn't really by the time you get into the compute manager. | |
| 11:45:16 | mdbooth | You just ignore eventlets entirely and assume you have multiple concurrent threads. How they're implemented isn't all that important in that code. | |
| 11:45:32 | mdbooth | If we later switched to a multi-threaded model, it would still be fine. | |
| 11:46:07 | sean-k-mooney | mdbooth: well if you were new to nova or did not think about it at the time then you can write races because of eventlets easier then if it was expcitly threaded | |
| 11:46:47 | mdbooth | Honestly, I never consider eventlets. I assume it's explicitly threaded. | |
| 11:47:11 | mdbooth | It's not, but that doesn't have any bearing on writing safe code, except when there's bugs in eventlet. | |
| 11:47:39 | sean-k-mooney | mdbooth: most new people i have talked to that work on openstack dont think about threads at all because the say oh its python and that has a gil so i dont need to care | |
| 11:48:13 | mdbooth | sean-k-mooney: That is just one of many issues with python in the real world :( | |
| 11:48:59 | mdbooth | Also, the gil doesn't prevent overlapping threads of execution, it just stops them running at the same time. The problems are the same. | |
| 11:49:15 | sean-k-mooney | mdbooth: yes and no. there perception is normally correct. its eventlets that violates the paradime | |
| 11:49:42 | mdbooth | As an old curmudgeon, I think python has been extremely detrimental to software engineering, particular in education | |
| 11:50:32 | mdbooth | No, it would not be correct. If you have a multi-threaded python program, even though the gil prevents multiple threads running concurrently, you still need locks. | |
| 11:50:43 | sean-k-mooney | mdbooth: i self taught myself c++ as my first langage then java so ya i like to understand exactly what is going on | |
| 11:51:46 | mdbooth | Basically: eventlets or python-multithreading: I don't care. It shouldn't change how your write code. | |
| 11:51:49 | sean-k-mooney | learning c++ fist made me a better engineer then learing python would have. | |
| 11:52:04 | mdbooth | They both use fake threading. | |
| 11:53:03 | openstackgerrit | Matthew Booth proposed openstack/nova master: Run evacuate tests with local/lvm and shared/rbd storage https://review.openstack.org/604400 | |
| 11:53:13 | mdbooth | I think ^^^ might fix that weird issue I was hitting | |
| 11:53:42 | mdbooth | There's a shortcut in service_is_up if the service is forced down, and we forced it down | |
| 11:54:29 | sean-k-mooney | mdbooth: yes i know if it was expcitly multi thraded it would be incorrect without the lock. anyway cool ill take a look at that too | |
| 11:55:10 | mdbooth | sean-k-mooney: Don't worry about ^^^ btw. Will just wait until zuul has voted. | |
| 11:55:22 | mdbooth | sean-k-mooney: I knew I was missing something simple there. | |
| 11:55:53 | sean-k-mooney | waith why was it forced down? | |
| 11:56:12 | sean-k-mooney | oh so you could evacuate | |
| 11:56:16 | mdbooth | The test_evacuate.sh script which ran before the second round... | |
| 11:56:18 | mdbooth | yeah | |
| 11:57:22 | sean-k-mooney | ha yet anthoer race this tiem between test :) | |
| 12:00:22 | nicolasbock | Morning | |
| 12:01:58 | nicolasbock | I have a run-away server, i.e. a VM that's running on a hypervisor different than what Nova thinks. So far I haven't quite been able to get the placement service to help me update Nova's view of reality... | |
| 12:02:22 | nicolasbock | I can see the server with 'openstack server show 2aa3a324-bf22-4e0c-912a-d7c52f59f1fd' | |
| 12:02:36 | nicolasbock | And it lists the wrong hypervisor | |
| 12:02:47 | mdbooth | 348 | |
| 12:02:47 | mdbooth | sean-k-mooney: $ git grep test\.nested | wc -l | |
| 12:02:54 | mdbooth | I'm not moving that ;) | |
| 12:03:13 | mdbooth | sean-k-mooney: Feel free to write a follow-up patch | |
| 12:03:22 | nicolasbock | I can also check that with 'openstack resource provider allocation show 2aa3a324-bf22-4e0c-912a-d7c52f59f1fd' | |
| 12:03:57 | sean-k-mooney | mdbooth: ok i would have just done nested=common.nested in test.py | |
| 12:04:34 | nicolasbock | The VM is really running on 6cbb84b0-02f4-4ee3-9df2-151475b1effe | |
| 12:04:47 | mdbooth | sean-k-mooney: Sure. I don't want to mess with test.nested here, though. | |
| 12:04:52 | nicolasbock | But `openstack resource provider allocation set --allocation rp=6cbb84b0-02f4-4ee3-9df2-151475b1effe 2aa3a324-bf22-4e0c-912a-d7c52f59f1fd` is not working | |
| 12:05:31 | sean-k-mooney | mdbooth: ok ill submist a follow up patch. eventully... i have added it to my whiteboard | |