| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-05-24 | |||
| 15:29:20 | smcginnis | That was actually an end user request where they didn't care about nova AZs matching cinder AZs. | |
| 15:29:35 | mriedem | so if you set allow_availability_zone_fallback=True in cinder and cross_az_attach=False in nova, you're just screwing your users | |
| 15:29:55 | mriedem | smcginnis: then they should have set cross_az_attach=False (or left the default) | |
| 15:30:03 | mriedem | sorry, True | |
| 15:30:13 | mriedem | cross_az_attach=True by default, which means we don't care | |
| 15:30:34 | savvas | mriedem: now from a production perspective, it would make sense to have nova define the best pool to provision though. Any suggestions for that? To create an instance with the "any availability zone" selected or via cli left blank? | |
| 15:30:38 | mriedem | i'm fairly certain that when i wrote https://github.com/openstack/nova/blob/81bdbd0b50aeac9a677a0cef9001081008a2c407/nova/virt/block_device.py#L80 it was to fix a bug which was hacked around by allow_availability_zone_fallback in cinder | |
| 15:31:07 | mriedem | savvas: if you don't need to be in a specific az, then you don't specify one | |
| 15:31:23 | mriedem | smcginnis: we (and by we i mean you or one of your henchmen) should investigate removing allow_availability_zone_fallback | |
| 15:31:30 | mriedem | via deprecation first of course | |
| 15:31:33 | savvas | mriedem: right, but then creation fails as it will try to put the volume in nova again | |
| 15:31:45 | mriedem | savvas: i don't understand that statement | |
| 15:31:56 | mriedem | you mean if you set cross_az_attach=False? | |
| 15:31:58 | savvas | your cross_az_attach fixed that when I define an AZ, it will grab the right volume zone | |
| 15:32:09 | savvas | but if I don't define/select an AZ to create the instance in | |
| 15:32:11 | savvas | it still fails | |
| 15:32:13 | mriedem | savvas: the default instance az in nova matches the default volume az in cinder | |
| 15:32:20 | mriedem | which is 'nova' | |
| 15:32:33 | smcginnis | mriedem: Well, there's the non-Nova case to account for too. So I think it's still needed. You just can't misconfigure your nova and cinder settings like that. | |
| 15:32:37 | cdent | melwitt, edleafe: in case it wasn't clear from my posting, I totally prefer a new porcelain api over transitioning the existing cruft. Was merely trying to pose an alternative/observation/etc. But as sdague eloquently pointed out in #openstack-dev last night, unless we put some muscle behind it, it is for naught. Got spare muscle? | |
| 15:32:43 | mriedem | smcginnis: psh non-nova case | |
| 15:33:10 | mriedem | smcginnis: allow_availability_zone_fallback is also not interoperable | |
| 15:33:30 | smcginnis | mriedem: Not sure I follow what you mean. | |
| 15:33:36 | savvas | mriedem: right, however leaving that blank is what would leave nova to determine the best node to spawn the instance on right? This would be a desirable feature when automating provisioning tasks | |
| 15:33:40 | mriedem | smcginnis: on one cloud i can create a volume with az=foo even though it doesn't exist, on another cloud i can't create a volume in az=foo because it doesn't exist and it's enforced | |
| 15:33:43 | edleafe | cdent: I know that you were just being hypothetical | |
| 15:33:57 | mriedem | smcginnis: it's per-cloud configurable API behavior | |
| 15:33:59 | edleafe | cdent: And no, no spare muscles at the moment :) | |
| 15:34:02 | mriedem | which is by definition not interoperable | |
| 15:34:10 | cdent | not so much hypothetical as omnithetical | |
| 15:34:24 | sdague | cdent: I also think it's far more work than people imagine. Even the code itself is a lot of work, but in lessons learn from nova v3 and the current api-ref effort, the code is only a small amount of the total work | |
| 15:34:49 | cdent | sdague: no dispute | |
| 15:35:04 | smcginnis | mriedem: If that's the concern, we have much bigger fish to fry than AZ enforcement. | |
| 15:35:08 | mriedem | smcginnis: maybe i should propose a deprecation patch in cinder and people can discuss i there | |
| 15:35:17 | mriedem | smcginnis: it's also complexity | |
| 15:35:23 | mriedem | which the foundation is apparently caring about now | |
| 15:35:30 | mriedem | hell, even thingee might get behind this | |
| 15:35:34 | mriedem | being foundation + cinder guy | |
| 15:35:34 | smcginnis | mriedem: And deprecate the nova option too? | |
| 15:35:38 | mriedem | smcginnis: which one? | |
| 15:35:47 | mriedem | cross_az_attach? | |
| 15:35:56 | smcginnis | mriedem: Yep. | |
| 15:36:12 | mriedem | i'd like to | |
| 15:36:12 | smcginnis | mriedem: Same argument, if that is set on one cloud and not another, you get different behavior. | |
| 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 | cdent | jmlowe: did you show it some bourbon? | |
| 15:36:53 | jmlowe | nova list shows an instance, nova delete sayas it's not there | |
| 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 | 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:50:55 | mriedem | savvas: is this at all related to what you're seeing? https://bugs.launchpad.net/nova/+bug/1497253 | |
| 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 ? | |