| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-24 | |||
| 15:35:47 | mriedem | cross_az_attach? | |
| 15:35:56 | smcginnis | mriedem: Yep. | |
| 15:36:12 | smcginnis | mriedem: Same argument, if that is set on one cloud and not another, you get different behavior. | |
| 15:36:12 | mriedem | i'd like to | |
| 15:36:18 | mriedem | true | |
| 15:36:29 | mriedem | you know what, | |
| 15:36:30 | jmlowe | I think I've botched adding cellsv2, I'm on newton | |
| 15:36:35 | sdague | cdent: and, the reference point that everyone keeps referencing is git, which isn't doing those calls over a network, with a token validation in the middle. I'm not actually sure how applicable a porcelain approach is to REST services. It's at least a research project to even figure it out | |
| 15:36:40 | mriedem | we should just allow passing all of the things you need to create a volume in to nova, | |
| 15:36:42 | mriedem | volume type, | |
| 15:36:43 | mriedem | volume az, | |
| 15:36:46 | mriedem | volume qos | |
| 15:36:47 | mriedem | everything | |
| 15:36:53 | jmlowe | nova list shows an instance, nova delete sayas it's not there | |
| 15:36:53 | cdent | jmlowe: did you show it some bourbon? | |
| 15:37:06 | mriedem | jmlowe: sec | |
| 15:37:17 | smcginnis | mriedem: There are some who would be in favor of that. | |
| 15:37:23 | edleafe | sdague: writing an SDK is sort of like writing a porcelain wrapper (but much simpler), and that was a LOT of work | |
| 15:37:28 | mriedem | jmlowe: see #3 https://docs.openstack.org/developer/nova/cells.html#faqs | |
| 15:37:40 | jmlowe | cdent: I'm going to need some bourbon to steady my nerves here in a minute if I don't figure this out | |
| 15:37:48 | mriedem | jmlowe: if that fixes your problem, i can die happy | |
| 15:37:56 | edleafe | creating a full orchestrator would be an order of magnitude more | |
| 15:39:05 | sdague | mriedem: that might be a good nova-status check | |
| 15:39:33 | jmlowe | wait, so --cell_uuid is the source not the destination? | |
| 15:39:48 | mriedem | jmlowe: do you have a single nova database? | |
| 15:39:49 | jmlowe | that may have been my gross conceptual error | |
| 15:39:53 | mriedem | i.e. you're not using cells v1? | |
| 15:40:10 | mriedem | sdague: yeah maybe, would have to think about it | |
| 15:40:23 | sdague | mriedem: anyway, faq is great | |
| 15:40:44 | mriedem | jmlowe: i'm assuming you have a basic deployment with 2 cells, cell0 and cell1 | |
| 15:40:46 | sdague | ffaq items probably moving into "am I ok" checks is better | |
| 15:41:03 | mriedem | sdague: sure, but faq is cheap and easy today | |
| 15:41:08 | sdague | yep | |
| 15:41:15 | mriedem | jmlowe: nova-manage cell_v2 list_cells | |
| 15:41:23 | jmlowe | ran the simple setup, figured out I forgot to create a new db for cell0, created db, did map_cell0/map_cell_and_hosts/map_instances | |
| 15:41:24 | mriedem | will tell you what you have setup, i'm guessing there are 2 entries | |
| 15:41:47 | mriedem | ok, when you run map_instances, it should be pointing at the non-cell0 cell | |
| 15:41:53 | mriedem | which is your existing main 'nova' database | |
| 15:41:55 | mriedem | with the instances | |
| 15:42:55 | jmlowe | yep, ok, that was not what I was doing | |
| 15:45:28 | jmlowe | so that I can stop panicking, is there a way to go back to no cells in newton? | |
| 15:47:09 | mriedem | i don't think nova-manage cell_v2 delete_cell existed in newton, | |
| 15:47:14 | mriedem | i mean you could hack the db, | |
| 15:47:26 | mriedem | but honestly i can't really advise how to rollback | |
| 15:47:48 | mriedem | jmlowe: i think the reason you're getting the 404 on instance delete is because the instance isn't mapped to the cell probably | |
| 15:48:12 | mriedem | we might not have had the list_cells command either - you'd have to see what's in the nova_api db cell_mappings table | |
| 15:48:15 | mriedem | are there 2 entries in there? | |
| 15:48:25 | jmlowe | there are two in there | |
| 15:48:36 | mriedem | ok, one is pointing at your nova_cell0 db? | |
| 15:48:39 | mriedem | and the other is pointing at your nova db? | |
| 15:48:53 | jmlowe | ok, did map_instances, this time with the correct uuid, no luck with nova show | |
| 15:49:19 | mriedem | do you see the uuid for the instance in the nova_api.instance_mappings table? | |
| 15:50:01 | mriedem | savvas: i'm not sure how that is going to affect this - yes nova will pick a host which may be in an AZ, but i didn't think we set instance.availability_zone in that case if the user didn't explicitly request an az | |
| 15:50:36 | jmlowe | http://paste.openstack.org/show/610573/ | |
| 15:50:55 | mriedem | savvas: is this at all related to what you're seeing? https://bugs.launchpad.net/nova/+bug/1497253 | |
| 15:50:55 | openstack | Launchpad bug 1497253 in OpenStack Compute (nova) "different availability zone for nova and cinder when AZ is not explicitly given" [Low,In progress] - Assigned to Roman Podoliaka (rpodolyaka) | |
| 15:52:05 | mriedem | jmlowe: right so 0bbfb73d-f761-4c43-ad72-ab47a559615e is your main cell | |
| 15:52:06 | mriedem | with the nova db | |
| 15:52:30 | jmlowe | correct, I did 'nova-manage cell_v2 map_instances --cell_uuid 0bbfb73d-f761-4c43-ad72-ab47a559615e' | |
| 15:52:43 | mriedem | jmlowe: is there an entry in the nova_api.instance_mappings table with the instance uuid you're looking for and cell 0bbfb73d-f761-4c43-ad72-ab47a559615e ? | |
| 15:53:36 | savvas | mriedem: yes, let me explain why I would like to have nova determine the best node. Basically these would be nodes with local ssd storage, not clustered. So I want instances to have volumes on their own hypervisors but all hypervisors serve the same purpose. Therefore when an instance is to be created, all AZs would qualify and based on available resources nova should determine which AZ to pick. Now I figured if you don't | |
| 15:53:36 | savvas | explicitly define the AZ, it will trigger nova to determine the best candidate, however that action fails as it will try to create the volume in the default "nova" AZ again | |
| 15:55:02 | mriedem | savvas: does this patch fix your issue? https://review.openstack.org/#/c/225119/ | |
| 15:55:02 | savvas | so your cross_az_attach fix works like a charm when explicitly defining an AZ, but not when trying to let nova determine the best AZ/node | |
| 15:55:27 | jmlowe | http://paste.openstack.org/show/610574/ | |
| 15:55:59 | savvas | mriedem: YES! That looks exactly like it | |
| 15:56:33 | savvas | mriedem: thanks for the help! | |
| 15:56:38 | mriedem | savvas: so where does the failure actually happen? on the cinder side? | |
| 15:57:10 | jmlowe | yes, the particular instance I'm after is present in the instance mappings mapped to cell0 | |
| 15:57:34 | jmlowe | is it a problem that there is no transport url for cell0 in cell_mappings? | |
| 15:57:58 | savvas | mriedem: well cinder works just fine, it does what it is beign told. Nova's just not telling cinder which AZ to use if you don't explicitly define the AZ for instance creating | |
| 15:58:38 | mriedem | jmlowe: the problem is the instance is mapped to cell0 | |
| 15:58:49 | jmlowe | yes | |
| 15:59:02 | openstackgerrit | Andrey Volkov proposed openstack/nova master: [placement] Add api-ref for resource classes https://review.openstack.org/467596 | |
| 15:59:26 | savvas | mriedem: https://review.openstack.org/#/c/225119/ this right here what you just sent me is exactly what I am seeing | |
| 15:59:55 | mriedem | jmlowe: so i think what probably happened was, the instances got mapped to cell0 by mistake, somehow, i'm not sure how - but now when you run map_instances with the correct cell 0bbfb73d-f761-4c43-ad72-ab47a559615e it does nothing b/c they are already mapped, | |
| 16:00:02 | jmlowe | should the database connection for cell0 and the legacy nova be different? | |
| 16:00:05 | mriedem | jmlowe: so i think you basically need to purge your instance_mappings table | |
| 16:00:17 | mriedem | jmlowe: they should be separate databases yes | |
| 16:00:27 | mriedem | you will have 3 separate databases: nova_api, nova_cell0 and nova | |
| 16:00:36 | jmlowe | ok, just checking | |
| 16:00:53 | mriedem | so i think you need to purge the instance_mappings table, and then re-map with the proper cell uuid 0bbfb73d-f761-4c43-ad72-ab47a559615e | |
| 16:01:05 | jmlowe | no harm in ' delete from instance_mappings;' ? | |
| 16:01:07 | mriedem | purging that table shouldn't be a problem since it's all wrong anyway | |
| 16:01:19 | mriedem | dansmith: right? ^ | |
| 16:01:30 | dansmith | yeah | |
| 16:01:50 | jmlowe | rerunning mapping | |
| 16:01:54 | mriedem | savvas: ok can you reply to the question i put in the commit messagE? | |
| 16:02:32 | mriedem | savvas: i.e. the volume gets created successfully but in the default 'nova' AZ, | |
| 16:02:44 | mriedem | which is different from the explicit non-default AZ that the instance is in, | |
| 16:02:47 | mriedem | and that's the bug, right? | |
| 16:02:51 | mriedem | but the boot request doesn't actually fail? | |
| 16:03:31 | savvas | no the boot request is accepted, it then tries to create a volume in AZ nova (default), when it fails it removes the attempted volume creation and leaves the new instance in error state | |
| 16:04:05 | mriedem | savvas: so is nova actually passing availability_zone='nova' to cinder when creating the volume? | |
| 16:04:08 | mriedem | or None? | |
| 16:04:33 | savvas | I believe it selects nova for it not being defined, but I can't tell for sure | |
| 16:04:37 | mriedem | edleafe: in the absence of bauzas, can a compute host live in more than one AZ? | |
| 16:04:47 | savvas | I've been using openstack for a week so I am still finding my way ;) | |
| 16:04:53 | mriedem | savvas: that's kind of important, because if nova is passing az=None then it's a different issue | |
| 16:04:58 | mriedem | savvas: you're a pro now | |