| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-04-07 | |||
| 12:56:22 | sean-k-mooney | no you have to do this for all installers | |
| 12:57:09 | sean-k-mooney | nova-manage can try and discover all the cells via the api db technially but that assuem either you store the password in the db which we discurage or you use the same password on all db instances | |
| 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 | |