| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-18 | |||
| 23:52:36 | melwitt | this series has been such a pain | |
| 23:54:44 | mriedem | ok. i decided that between two evils on my todo list, doing forum session recaps was easier for now. :) | |
| 23:54:53 | mriedem | and i can continue to say i'm not reviewing your series becaues i'm waiting for you to update it | |
| 23:55:19 | melwitt | yup, that you can. | |
| #openstack-nova - 2017-05-19 | |||
| 00:15:16 | melwitt | dansmith: is it ever possible to change the return type of a remotable method? like is there a way for new code to know old code is calling so the return type can be formatted to what the old code expects? | |
| 00:15:53 | dansmith | melwitt: nope | |
| 00:16:10 | dansmith | pass a flag or create a new method | |
| 00:16:14 | dansmith | ideally the latter | |
| 00:16:28 | melwitt | okay. so to change all count() to return a dict instead of an int, I have to do something like that | |
| 00:16:44 | dansmith | yeah | |
| 00:17:28 | melwitt | I'm trying to think if it's even possible for old code to call new code count(). it's only called in nova-api | |
| 00:17:42 | melwitt | Quotas.count() | |
| 00:17:44 | dansmith | if you change it you should make a new method | |
| 00:17:48 | dansmith | don't cheat :) | |
| 00:18:01 | melwitt | :( | |
| 00:18:19 | melwitt | the hard part is thinking of a name that isn't dumb | |
| 00:18:39 | dansmith | count_less_sucky_than_the_first_attempt() | |
| 00:18:44 | melwitt | lol, I wish | |
| 00:19:36 | melwitt | maybe count_as_dict since probably peeps will expect an integer | |
| 00:19:56 | dansmith | oh please please call it count_dicts() | |
| 00:21:35 | melwitt | I don't get it | |
| 00:24:17 | cfriesen | I think that's cause you're too mature | |
| 00:24:43 | melwitt | I shall use that excuse :) | |
| 00:26:26 | dansmith | I shall remain immature and unashamed | |
| 00:33:10 | fishbone_ | Hello all, I am having a serious problem. I am performing an upgrade from Newton to Ocata and every time I run the upgrade for nova-compute I receive "ERROR: could not access cell mapping database - has api db been created?" | |
| 00:35:06 | cfriesen | fishbone: have you read the nova upgrade notes in the release notes? | |
| 00:35:50 | fishbone_ | cfriesen: yes I believe so, it only seemed to mention designate changes | |
| 00:37:37 | fishbone_ | I see all of my nova services except for the compute services are up | |
| 00:37:58 | fishbone_ | I have tried creating the cells database manually and also by using the simple_cells command | |
| 00:38:07 | cfriesen | fishbone: I think the section you want begins with "A new nova-manage command has been added which will upgrade a deployment to cells v2..." at https://docs.openstack.org/releasenotes/nova/ocata.html | |
| 00:39:03 | cfriesen | dansmith: is this correct? ^ | |
| 00:39:11 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi: cached images should be cleaned up by time https://review.openstack.org/465954 | |
| 00:42:23 | fishbone_ | cfriesen: Thanks for the link, although I tried that method as well. I have my system backed up and was able to retry using that command from scratch. Also the issue only seems to lie with the compute hosts, my controller node can access the api database fine | |
| 00:42:40 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi: cached images should be cleaned up by time https://review.openstack.org/465954 | |
| 00:53:38 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi: cached images should be cleaned up by time https://review.openstack.org/465954 | |
| 01:20:23 | mriedem | fishbone_: "could not access cell mapping database" has nothing to do with the computes | |
| 01:20:31 | mriedem | you're getting that from running nova-manage db sync right? | |
| 01:20:53 | mriedem | nova.conf on the compute node doesn't need access to the API database (or any database for that matter) | |
| 01:22:00 | fishbone_ | mriedem: I didn't think so either, however; I don't get the error when syncing the database, that seems to work with no errors. I get it when upgrading nova-compute on the compute nodes | |
| 01:22:34 | mriedem | why are you running nova-manage db sync on the compute nodes? | |
| 01:23:33 | mriedem | also fyi https://docs.openstack.org/developer/nova/cells.html#upgrade-minimal | |
| 01:24:02 | mriedem | what you're hitting is this https://github.com/openstack/nova/blob/master/nova/cmd/manage.py#L649 | |
| 01:24:11 | mriedem | when it's trying to automatically sync the nova_cell0 database | |
| 01:25:16 | mriedem | anyway, you shouldn't need to sync the db from the compute nodes | |
| 01:28:51 | fishbone_ | mriedem, are you saying the error can be ignored, I don't think I am able to compete the nova-compute installation because of this error | |
| 01:29:16 | fishbone_ | mriedem: Is there a way to suppress that sync process? | |
| 01:29:40 | mriedem | i'm saying you don't need to sync the database from a compute node | |
| 01:29:49 | mriedem | the compute node doesn't have direct access to the database | |
| 01:29:52 | mriedem | or shouldn't | |
| 01:33:30 | fishbone_ | mriedem: Do you know why I may be getting that error on a compute host then? | |
| 01:34:04 | fishbone_ | mriedem: I get the error even if I do a fresh install of nova-compute after removing old cofig files | |
| 01:34:10 | fishbone_ | config* | |
| 01:34:52 | mriedem | i assume because the compute host doesn't have direct access to the cell0 database | |
| 01:35:06 | mriedem | but it's weird that the sync on the nova (cell) database would not fail in that case | |
| 01:35:45 | mriedem | https://docs.openstack.org/ocata/install-guide-ubuntu/nova-compute-install.html doesn't say anything about running db sync from the compute host though | |
| 01:35:53 | mriedem | that's all done on the controller https://docs.openstack.org/ocata/install-guide-ubuntu/nova-controller-install.html | |
| 01:37:22 | fishbone_ | mriedem: Yes it is strange, I get the error at the apt install nova-compute" step | |
| 01:37:43 | mriedem | hmm, so that's something baked into the package then? | |
| 01:37:53 | mriedem | like a post-install script as part of the package? | |
| 01:38:07 | mriedem | are you using ubuntu packages? | |
| 01:38:22 | fishbone_ | mriedem: yes, I am using the ubuntu repositories | |
| 01:39:14 | openstackgerrit | Jianghua Wang proposed openstack/nova master: Skip policy rules on attach_network for none network allocation https://review.openstack.org/465903 | |
| 01:40:39 | mriedem | fishbone_: ok well those seem wrong, i'd probably report a bug against the ubuntu nova package LP site | |
| 01:41:01 | mriedem | fishbone_: on your control node, if you run "nova-manage cell_v2 list_cells" do you see 2 listed? | |
| 01:41:38 | mriedem | https://launchpad.net/ubuntu/+source/nova for reporting bugs against ubuntu nova packages btw | |
| 01:42:37 | mriedem | if list_cells shows 2 cells then i think you're good to go | |
| 01:46:56 | fishbone_ | mriedem: Yes it shows properly, however; the compute nodes are unable to install the appropriate packages | |
| 01:47:00 | mriedem | mdbooth: lyarwood: btw, hooray for completely differnt code paths for attaching a volume during boot and after boot https://review.openstack.org/#/c/443951/18/nova/virt/libvirt/volume/vrtshyperscale.py@44 | |
| 01:47:10 | fishbone_ | mriedem: they fail with the error | |
| 01:47:49 | mriedem | fishbone_: is there a way to ignore post-install scripts, or force the install? sorry but i haven't heard of this one, definitely sounds like a bug in the assumptions the packages are making | |
| 01:48:51 | mriedem | fishbone_: also https://ask.openstack.org/en/question/103660/ocata-install-nova-error/ | |
| 01:49:26 | fishbone_ | mriedem: I haven't tried that, I will, and thanks for all your help, I'll update soon | |
| 01:50:14 | mriedem | fishbone_: see if you have a nova_api_cell0 or nova_cell0 db | |
| 01:50:28 | mriedem | you can also see that via nova-manage cell_v2 list_cells --verbose | |
| 01:50:43 | mriedem | sounds like some people in that forum thread hit some issues with mismatched db names and the connection URL in the api db | |
| 01:50:44 | mriedem | for cell0 | |
| 01:50:49 | fishbone_ | mriedem: I saw that article, it didn't seem to work for me, I have the nova_cell0 database | |
| 01:51:08 | mriedem | is that what's in the database_connection for the cell0 cell_mapping in the nova_api database though? | |
| 01:51:24 | fishbone_ | mriedem: I followed the docs, which say that it should be named as nova_cell0 | |
| 01:51:40 | mriedem | i'd check your db :) | |
| 01:51:46 | fishbone_ | mriedem: I cross referenced that in those 2 databases and they do match | |
| 01:51:51 | mriedem | ok | |
| 01:56:08 | openstackgerrit | guang-yee proposed openstack/nova master: make sure to rebuild claim on recreate https://review.openstack.org/466143 | |
| 02:03:29 | openstackgerrit | Wang Shilong proposed openstack/nova master: Lustre support https://review.openstack.org/446288 | |
| 02:15:22 | openstackgerrit | Yongfeng Du proposed openstack/nova master: Update the file for IPv4-only or IPv6-only network https://review.openstack.org/465891 | |
| 02:16:10 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Add tags fields for server list detail/show api-ref https://review.openstack.org/465842 | |
| 02:22:07 | fishbone_ | mriedem: it seems to be an issue with the compute hosts themselves, I tried a fresh install with a host that was not already in the nova database and received no errors duing installation | |
| 02:22:42 | fishbone_ | mriedem: It must be specific to upgrading a pre-integrated hypervisor | |
| 02:44:43 | fishbone_ | mriedem: it seems simply adding the database directives in the config files allowed the install to go through, perhaps due to the hypervisors being from prior to the cell creation | |
| 02:54:53 | openstackgerrit | Naichuan Sun proposed openstack/nova master: xenapi: cached images should be cleaned up by time https://review.openstack.org/465954 | |
| 02:55:06 | mriedem | fishbone_: hmm, not sure | |
| 02:55:17 | mriedem | but cool that you found a workaround | |
| 02:55:28 | mriedem | still, i'd open a bug against the ubuntu packagers, | |
| 02:55:34 | mriedem | the nova-compute package shouldn't be running nova-manage db sync | |
| 02:57:20 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Should not allow security group from other project pass API layer check when booting https://review.openstack.org/466160 | |
| 03:08:06 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: Add tags fields for server list detail/show api-ref https://review.openstack.org/465842 | |
| 03:09:45 | fishbone_ | mriedem: yep, it worked after that. I agree with you, I will go and open a bug for this | |
| 03:12:32 | openstackgerrit | falseuser proposed openstack/nova master: [BugFix] Include the video ram when comparing the difference of two flavors https://review.openstack.org/460388 | |
| 03:30:12 | openstackgerrit | Tao Li proposed openstack/nova master: Fix the display of updated_at time when using memcache driver. https://review.openstack.org/414463 | |
| 03:36:00 | openstackgerrit | Tao Li proposed openstack/nova master: Change log level from ERROR to DEBUG for NotImplemented https://review.openstack.org/465797 | |