| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-04-07 | |||
| 12:57:11 | bauzas | https://github.com/openstack/devstack/blob/master/lib/nova#L818 | |
| 12:57:46 | bauzas | and https://github.com/openstack/devstack/blob/master/lib/nova#L847 | |
| 12:58:00 | sean-k-mooney | in generall its simpler to have one config file per cell and run the comand once per cell | |
| 12:58:04 | Uggla | for devstack I use my patch by configuring a git remote on my repo and "pulling" it | |
| 12:58:10 | bauzas | context : https://docs.openstack.org/nova/latest/admin/cells.html#configuring-a-new-deployment | |
| 12:58:27 | sean-k-mooney | Uggla: ok so you set NOVA_REPO and NOVA_BRANCH before you stacked | |
| 12:58:48 | sean-k-mooney | and you did not already have /opt/stack/nova right | |
| 12:58:56 | sean-k-mooney | before you ran stack.sh | |
| 12:59:09 | Uggla | not sorry, I had a already installed devstack and replace the code with mine + restart | |
| 12:59:19 | sean-k-mooney | oh ok | |
| 12:59:41 | sean-k-mooney | so doing sudo systemctl restart devstack@n-* | |
| 12:59:47 | Uggla | yep | |
| 12:59:50 | sean-k-mooney | works only for python changes | |
| 12:59:59 | sean-k-mooney | if you chagne the db you have to manually sync again | |
| 13:00:15 | Uggla | ack | |
| 13:00:43 | sean-k-mooney | 99% of the time we are not touching the db so we dont usually call that out | |
| 13:00:52 | Uggla | do we agree that the doc for db migration is this one: https://docs.openstack.org/nova/latest/admin/upgrades.html | |
| 13:01:07 | sean-k-mooney | yes it is | |
| 13:01:34 | sean-k-mooney | """Using the newly installed nova code, run the DB sync. First run nova-manage api_db sync, then nova-manage db sync. nova-manage db sync should be run for all cell databases, including cell0. If necessary, the --config-file argument can be used to point to the correct nova.conf file for the given cell.""" | |
| 13:01:45 | Uggla | any objection if I propose a minor update to make it clearer ? | |
| 13:02:15 | sean-k-mooney | im not sure what is not clear but sure we can review it | |
| 13:02:28 | sean-k-mooney | its always ok to propose updates to docs ectra | |
| 13:02:34 | sean-k-mooney | we will just review it as normal | |
| 13:02:47 | sean-k-mooney | you could add an example i guess | |
| 13:02:47 | Uggla | sean-k-mooney, that's clearly what I was looking. And I was confuse by the fact that it was not clear for me is all cells will be updated or not. | |
| 13:03:52 | Uggla | And more confuse by that: --local_cell Only sync db in the local cell: do not attempt to fan-out to all cells | |
| 13:03:59 | sean-k-mooney | well it says ""nova-manage db sync should be run for all cell databases"" | |
| 13:04:14 | sean-k-mooney | that imperitive directing you to run it for each cell | |
| 13:05:04 | sean-k-mooney | Uggla: feel free to add a note with examples or other changes if you think it would help make it cleaner | |
| 13:05:11 | Uggla | I agree, but I had the doubt if it was automatic or normal. | |
| 13:07:53 | sean-k-mooney | Uggla: https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L193-L195= | |
| 13:08:22 | Uggla | sean-k-mooney, clearly I understood it incorrectly. But I think this is mainly due to: "Only sync db in the local cell: do not attempt to fan-out to all cells" --> so without this option I thought it will configure all cells | |
| 13:08:46 | sean-k-mooney | not quite | |
| 13:09:00 | sean-k-mooney | without it it will do cell0 and the curernt cell | |
| 13:09:21 | sean-k-mooney | each nova.conf will only have one cell db configured | |
| 13:09:46 | sean-k-mooney | we do not have the code required to loop over all the cells in the api db and update them automatically | |
| 13:09:57 | sean-k-mooney | so without --local_cell it does cell0 and the local cell | |
| 13:10:04 | sean-k-mooney | with it it only does the local cell | |
| 13:10:09 | sean-k-mooney | cell1 in this case | |
| 13:10:27 | sean-k-mooney | cell0 is speical its not a real cell | |
| 13:10:42 | sean-k-mooney | it used for instance that could not be schduled to a host | |
| 13:10:48 | Uggla | I'm not clear. What is local cell ? | |
| 13:10:51 | sean-k-mooney | and a few other internal usecases | |
| 13:11:01 | sean-k-mooney | it the one that is reference in the nova.conf | |
| 13:11:26 | sean-k-mooney | in the [database]/connection value | |
| 13:12:18 | sean-k-mooney | so | |
| 13:12:20 | sean-k-mooney | [database] | |
| 13:12:22 | sean-k-mooney | connection = mysql+pymysql://root:password@127.0.0.1/nova_cell1?charset=utf8 | |
| 13:13:09 | sean-k-mooney | by default devstack generates /etc/nova/nova.conf with that pointign at cell0 | |
| 13:13:21 | Uggla | ok back to my previous question, do you have cases where nova.conf does not contain cell0 ? | |
| 13:13:36 | Uggla | or is it only devstack specific ? | |
| 13:13:43 | sean-k-mooney | no you do | |
| 13:13:50 | sean-k-mooney | the conductor config dont point to cell0 | |
| 13:13:57 | sean-k-mooney | they point to there cell db | |
| 13:14:20 | sean-k-mooney | whcih will be cell1 or in osp we call it just nova | |
| 13:17:25 | Uggla | ok it clear now. thx. | |
| 13:22:06 | Uggla | \o/ my code is working. At least the index part... ;) | |
| 13:35:07 | Uggla | and the creation part. Seems I manage to discuss with manila ! | |
| 13:53:52 | spatel | sean-k-mooney i have opened this bug for my issue - https://bugs.launchpad.net/nova/+bug/1968054 | |
| 13:54:25 | sean-k-mooney | that does not seem like a nova issue | |
| 13:54:39 | sean-k-mooney | the error is with conencting to the rabbitmq right | |
| 13:56:41 | bauzas | reminder : nova sessions start in 4 mins | |
| 14:02:29 | bauzas | nova sessions start now | |
| 14:02:37 | sean-k-mooney | joining | |
| 14:02:37 | bauzas | https://www.openstack.org/ptg/rooms/newton | |
| 14:02:50 | sean-k-mooney | spatel: that looks like you are having internal network issue with connectivty between your comptues and the contoler | |
| 14:03:41 | spatel | This is all running behind single switch so its hard to say network issue. all other nodes are happy | |
| 14:04:00 | spatel | as soon as i restart my nova-compute everything came back | |
| 14:04:20 | spatel | look like some thread crashed and never recover until manually restart | |
| 14:04:52 | sean-k-mooney | it could be related to dns | |
| 14:04:53 | spatel | Out of 20 compute 2 nodes encounter with this issue.. | |
| 14:05:06 | sean-k-mooney | https://github.com/openstack/nova/commit/fe1ebe69f358cbed62434da3f1537a94390324bb | |
| 14:06:12 | spatel | I have everything using IP address | |
| 14:06:21 | spatel | i have found similar bug but not sure its related to my issue or not - https://bugs.launchpad.net/oslo.messaging/+bug/1934937 | |
| 14:07:05 | sean-k-mooney | spatel: the error are not coming from nova so i woudl think its unlikely this is a nova bug it proably an oslo one if its not related to your infra | |
| 14:07:35 | spatel | i don't think its related to infra for sure | |
| 14:08:12 | spatel | i may post same bug to oslo | |
| 14:08:44 | sean-k-mooney | you can just add them to the bug | |
| 14:08:54 | sean-k-mooney | you dont need to create a second one | |
| 14:24:12 | spatel | sean-k-mooney how do i add them in existing bug? | |
| 14:24:49 | spatel | affected project? | |
| 14:26:01 | sean-k-mooney | yes | |
| 14:26:22 | spatel | done, thanks | |
| 14:41:00 | opendevreview | Stephen Finucane proposed openstack/placement master: db: Replace implicit conversion of SELECT into FROM https://review.opendev.org/c/openstack/placement/+/800910 | |
| 14:41:01 | opendevreview | Stephen Finucane proposed openstack/placement master: db: Replace 'as_scalar()' with 'scalar_subquery()' https://review.opendev.org/c/openstack/placement/+/801100 | |
| 14:41:01 | opendevreview | Stephen Finucane proposed openstack/placement master: db: Update 'select()' calls https://review.opendev.org/c/openstack/placement/+/801103 | |
| 14:41:02 | opendevreview | Stephen Finucane proposed openstack/placement master: db: Remove use of non-integer/slice indices https://review.opendev.org/c/openstack/placement/+/801104 | |
| 14:41:02 | opendevreview | Stephen Finucane proposed openstack/placement master: db: Replace deprecated 'FromClause.select().whereclause' parameter https://review.opendev.org/c/openstack/placement/+/801105 | |
| 14:41:03 | opendevreview | Stephen Finucane proposed openstack/placement master: db: Use explicit transactions https://review.opendev.org/c/openstack/placement/+/801106 | |
| 14:41:03 | opendevreview | Stephen Finucane proposed openstack/placement master: db: Remove unnecessary use of '_mapping' https://review.opendev.org/c/openstack/placement/+/801107 | |
| 14:41:04 | opendevreview | Stephen Finucane proposed openstack/placement master: tests: Restore - don't reset - warning filters https://review.opendev.org/c/openstack/placement/+/828119 | |
| 14:41:05 | opendevreview | Stephen Finucane proposed openstack/placement master: db: Use Row, not LegacyRow https://review.opendev.org/c/openstack/placement/+/828305 | |
| 14:41:05 | opendevreview | Stephen Finucane proposed openstack/placement master: tox: Enable SQLAlchemy 2.0 warnings https://review.opendev.org/c/openstack/placement/+/801108 | |
| 14:52:49 | stephenfin | gibi: Fixed that placement issue. Can you relook at https://review.opendev.org/c/openstack/placement/+/801103 and https://review.opendev.org/c/openstack/placement/+/800910 when you get a chance (maybe after CI runs if you want) | |
| 14:53:01 | gibi | stephenfin: added to my review list | |
| 14:53:24 | stephenfin | sean-k-mooney: melwitt: bauzas: I'll need one of you folks to be the other +2/+W when you've time ^ | |
| 14:53:52 | stephenfin | Context is this SQLA 2.0 stuff came up in the TC call earlier and I thought these had merged already :) | |
| 14:54:00 | bauzas | stephenfin: ack, will look | |
| 14:54:04 | stephenfin | ta | |
| 14:55:42 | sean-k-mooney | ah ws going to ask | |