Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-10-03
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 bauzas sean-k-mooney: my point is that I just want to init_nova() honestly
09:51:24 sean-k-mooney is that an issue
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 sean-k-mooney: $ git grep test\.nested | wc -l
12:02:47 mdbooth 348
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
12:05:34 nicolasbock I suppose I am missing a `resource-class-name`
12:05:50 nicolasbock But what do I put there?
12:08:32 openstackgerrit Elod Illes proposed openstack/nova stable/ocata: Fix the help for the disk_weight_multiplier option https://review.openstack.org/607537
12:11:55 sean-k-mooney nicolasbock: was the vm migrated
12:12:09 nicolasbock Yes sean-k-mooney
12:12:38 sean-k-mooney mdbooth: was lookin at an edgecase recently where if cleanup on the source fail we dont update the vm host
12:14:29 sean-k-mooney nicolasbock: e.g. when you finish migrating the instace if the post migrate job on the source node failts to say unplug a vif we fail before we update the instace db record to refect that the vm is running on the new node
12:14:49 sean-k-mooney mdbooth: did you ever proposea a patch for ^
12:15:12 mdbooth sean-k-mooney: Probably.
12:17:27 sean-k-mooney nicolasbock: are the placement allocation currently associated with the vm correct for the host it is actully on

Earlier   Later