| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2022-04-07 | |||
| 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 | |
| 14:55:52 | sean-k-mooney | ok its sqla | |
| 14:55:58 | sean-k-mooney | ya no worries | |
| 15:12:06 | bauzas | as I wrote on https://ptg.opendev.org/ptg.html, next discussion will be at 4pmUTC | |
| 15:22:45 | bauzas | stephenfin: you got my review-prio flag on your placement SQLA db series | |
| 15:31:58 | stephenfin | bauzas: thanks | |
| 15:37:38 | sean-k-mooney | we proably should have proceeded witht he nova adgenda and then asked them to ping us in highsight | |
| 15:40:45 | gibi | next time we will be smarter :) | |
| 15:42:38 | gibi | maybe we need to punt the rest of the nova topic to friday? | |
| 15:44:40 | sean-k-mooney | we coudl i guess | |
| 15:44:55 | sean-k-mooney | i kind of wanted to finish today if we did not have other topics | |
| 15:45:11 | sean-k-mooney | so that we could sync with neutron or cinder tomorrow | |
| 15:45:15 | sean-k-mooney | or tc | |
| 15:45:29 | sean-k-mooney | without worring about conflicts | |
| 15:47:29 | gibi | yeah | |
| 15:47:43 | gibi | let see how fast the tc session goes | |
| 15:55:35 | opendevreview | Balazs Gibizer proposed openstack/nova stable/train: Reproduce bug 1944759 https://review.opendev.org/c/openstack/nova/+/836993 | |
| 15:55:36 | opendevreview | Balazs Gibizer proposed openstack/nova stable/train: Store old_flavor already on source host during resize https://review.opendev.org/c/openstack/nova/+/836994 | |
| 16:00:54 | bauzas | folks, what should we do ? | |
| 16:02:03 | gibi | I think this tc discussion is useful | |
| 16:02:15 | bauzas | artom_: melwitt: gibi: sean-k-mooney: Uggla: elodilles: could we have our arbiterd session by 1630UTC ? | |
| 16:02:37 | gibi | bauzas: works for me | |
| 16:02:38 | bauzas | I tend to agree with sean-k-mooney, ideally we should free ourselves tomorrow as soon as we can | |