| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-01 | |||
| 16:42:25 | dansmith | mriedem: I mean the destroying the BR and setting cell_id on the instance mapping in one transaction | |
| 16:42:39 | dansmith | melwitt: right | |
| 16:43:26 | mnaser | i assume mriedem is concerned about updating instance mapping and creating instance in a single transaction | |
| 16:43:43 | mnaser | cause you can create but fail updating instance mapping | |
| 16:43:51 | mnaser | and end up with a listable but not retrievable instance | |
| 16:43:59 | mriedem | that's what https://review.openstack.org/#/c/586713/ is for | |
| 16:44:16 | mriedem | we update the mapping immediately after creating the instance, | |
| 16:44:25 | mriedem | but i'm not sure what should happen if we fail to update the mapping | |
| 16:44:32 | dansmith | destroy the instance | |
| 16:44:37 | dansmith | leave the BR in place | |
| 16:44:44 | mriedem | that's what it's doing right now | |
| 16:44:45 | mriedem | my patch | |
| 16:44:51 | dansmith | that's what we should do | |
| 16:44:57 | melwitt | mnaser: yeah, would have to take a look at what we can do with finding that out. jaypipes do you know how we can print/log whether something is occurring in a single db transaction when we're doing sqlalchemy queries while we're testing something? | |
| 16:45:00 | mriedem | but, | |
| 16:45:00 | dansmith | if we double fail on all DBs then we can't do anything anyway | |
| 16:45:12 | mriedem | if we have an empty mapping and no instance and a build request, | |
| 16:45:23 | dansmith | melwitt: one writer should mean one transaction AFAIK | |
| 16:45:24 | mriedem | the build request will always show as status BUILDING or whatever | |
| 16:45:53 | mnaser | thing is stale records in db that don't impact api aren't too much of a problem | |
| 16:46:19 | mnaser | having an instance mapping point to a cell where the instance doesnt exist => no confusing instance when listing instances | |
| 16:46:20 | dansmith | mriedem: the other thing we can do, which I'd rather not, but is look up mappings during a list and either filter those instances or fix the mappings on the fly | |
| 16:46:24 | mriedem | i don't think you can delete a scheduling instance though, unless you force delete it? | |
| 16:46:46 | mriedem | dansmith: i thought about fixing on the fly, | |
| 16:46:46 | dansmith | mriedem: I mean NFO the record you just created | |
| 16:46:47 | mriedem | however, | |
| 16:47:09 | mriedem | if we create the instance but fail to update the mapping, we won't have created the bdms and tags in the cell db either | |
| 16:47:11 | melwitt | dansmith: it should, but IIRC there are ways in which queries might not be a single transaction (from a db standpoint) even if you put them under the same decorator. it would be nice to be able to verify if we could | |
| 16:47:16 | mriedem | so the instance could be mapped, but it would be incomplete | |
| 16:47:42 | dansmith | melwitt: only if you're doing nested transactions or force commit, AFAIK | |
| 16:48:07 | jaypipes | melwitt: you mean can we inject log messages after running various DB statements in the placement service to log whether there were results? | |
| 16:48:16 | mriedem | i don't know what NFO means, urbandictionary suggests Near Fatal Orgasm | |
| 16:48:18 | jaypipes | melwitt: not quite sure what you're asking, sorry... | |
| 16:48:19 | dansmith | mriedem: sure, but that's going to affect the listable instance anyway | |
| 16:48:24 | dansmith | mriedem: nuke from orbit | |
| 16:48:40 | melwitt | jaypipes: I mean is there a way to log/print/see whether a series of queries we made really translated into a single database transaction? | |
| 16:48:43 | dansmith | mriedem: although I like yours better | |
| 16:48:51 | mriedem | probably gonna need to serialize these conversations for context | |
| 16:48:57 | melwitt | jaypipes: in general, this isn't about placement | |
| 16:49:02 | mnaser | as an operator i would rather have an instance_mapping that's invalid pointing to an non-existant instance (but not showing any instances in list) rather than instance showing in list and not retrievable | |
| 16:49:05 | jaypipes | melwitt: ah, you mean a single COMMIT was issued... | |
| 16:49:37 | mriedem | dansmith: maybe you want to just look at https://review.openstack.org/#/c/586713/ and leave whatever thoughts | |
| 16:49:46 | jaypipes | melwitt: that would prolly be something we could add to oslo.db's transaction context manager. Basically, output a LOG.info("Committing transaction") when the context manager completes without an exception? | |
| 16:49:50 | mriedem | oh you did | |
| 16:50:12 | mnaser | my single transaction change was updated here -- https://review.openstack.org/#/c/586742/ .. but no testing etc | |
| 16:50:24 | gnuoy | melwitt, sorry, just so I'm clear, there needs to be an [api_database] section in the neutron.conf that neutron-metadata-agent is using? | |
| 16:50:32 | dansmith | mnaser: I know, but there are several things we're trying to accomplish with the dance around creating/destroying those records | |
| 16:50:47 | dansmith | mnaser: mostly around trying to preserve api semantics that have existed for a long time | |
| 16:51:19 | mnaser | dansmith: makes sense, i dont have that much context about it then :p | |
| 16:51:35 | dansmith | mnaser: mriedem: maybe we should have a non-text conversation about that whole process to make sure we're still doing what we want | |
| 16:51:54 | dansmith | I'm not likely to be able to focus on it if we do it here, I just have too many parallel threads running | |
| 16:52:23 | melwitt | jaypipes: I guess so :) just curious if there's a way to sanity check that in a unit test or func test environment (temporarily), the sql commands that are issued to the database. I had thought that it's not guaranteed that everything you put under one transaction context manager is a single transaction, from a low-level database standpoint. maybe there's no way to check that? anyway, this is all just my curiosity, so sorry for the | |
| 16:52:23 | melwitt | distraction | |
| 16:53:19 | mnaser | dansmith: i agree :) | |
| 16:55:08 | mriedem | yeah, also, | |
| 16:55:29 | melwitt | gnuoy: I'm not 100% sure but I think no, the neutron-metadata-agent is a neutron thing and the nova part is a metadata proxy that sends to the agent | |
| 16:55:40 | mriedem | i'd kind of like to squash these 2 for loops in schedule_and_build_instance for sanity before making changes in here, but not sure how backportable that all is, since we likely need at least one fix going back to pike | |
| 16:56:06 | mriedem | mnaser: are you still on pike? | |
| 16:56:07 | dansmith | melwitt: FYI I'm not going to be around for the nova meeting tomorrow. I'm sure I will be sorely missed. | |
| 16:56:31 | mnaser | mriedem: no, queens everywhere at this point | |
| 16:56:34 | melwitt | dansmith: yes, we will prepare ourselves emotionally | |
| 16:56:47 | gnuoy | melwitt, yeah I assumed querying the nova api db would be a nova task which is why the guide seems odd when it says that neutron needs it. | |
| 16:57:25 | melwitt | gnuoy: well, the guide is saying the neutron metadata API proxy (emphasis on the proxy) needs it. the nova piece that proxies to the neutron agent needs it | |
| 16:57:44 | dansmith | gnuoy: melwitt: there is no [api_database] in the _neutron_ config | |
| 16:58:03 | jaypipes | melwitt: no need to apologize! it's an interesting problem. | |
| 16:58:59 | gnuoy | is the guide trying to tell me that nova-api-metadata service needs an [api_database] section? | |
| 17:01:00 | melwitt | dansmith: do you know if the metadata service and the neutron metadata API proxy the same service? their code is together in the tree | |
| 17:01:27 | dansmith | melwitt: they neutron proxy is in the neutron tree no? | |
| 17:01:28 | melwitt | *are the same | |
| 17:02:13 | dansmith | melwitt: but gnuoy was asking about an api_database section in a neutron.conf file, which wouldn't be the case, unless neutron has a section for that as well | |
| 17:02:28 | mnaser | neutron does not have `api_database` section | |
| 17:02:32 | dansmith | right | |
| 17:02:34 | mriedem | neutron has a metadata agent that makes requests to the nova metadata api | |
| 17:02:41 | dansmith | right | |
| 17:02:57 | mriedem | https://docs.openstack.org/nova/latest/user/cellsv2-layout.html#neutron-metadata-api-proxy | |
| 17:02:58 | dansmith | I assume the confusion is over the configuration of the api_db for the _nova_ metadata side | |
| 17:03:05 | mriedem | "The Neutron metadata API proxy should be global across all cells, and thus be configured as an API-level service with access to the [api_database]/connection information." | |
| 17:03:09 | dansmith | separate from neutron's proxy of/to that | |
| 17:03:40 | melwitt | so what is the "neutron metadata API proxy" then? it's a nova service isn't it? is it our metadata service? | |
| 17:03:43 | mriedem | maybe that should say 'nova metadata api' to avoid confusion it's something in neutron | |
| 17:03:51 | dansmith | no | |
| 17:03:56 | dansmith | mriedem: yeah | |
| 17:04:18 | mnaser | melwitt: neutron has a 'software' that runs in the netns for each tenant/etc which listens of 169.254.169.254 and proxies those requests out to nova metadata api | |
| 17:04:35 | dansmith | right, which is the neutron metadata proxy | |
| 17:04:36 | mnaser | i assume thats the neutron metadata api proxy as i understand it | |
| 17:04:37 | mriedem | https://docs.openstack.org/neutron/latest/install/controller-install-ubuntu.html?highlight=metadata%20proxy#configure-the-metadata-agent | |
| 17:04:38 | melwitt | mnaser: thanks | |
| 17:04:52 | mnaser | but yeah, i think that doc should say Nova Metadata API rather than neutron metadata api proxy | |
| 17:05:03 | gnuoy | I will raise a PR for the docs | |
| 17:05:11 | gnuoy | Thanks everyone for the help | |
| 17:05:13 | melwitt | gnuoy: thanks. sorry for all that confusion | |
| 17:05:20 | gnuoy | np at all | |
| 17:05:25 | dansmith | mnaser: yeah, and apparently I wrote that | |
| 17:05:42 | dansmith | just a mind-o I'm guessing | |
| 17:05:43 | mnaser | writing long docs can get exhuasting :P | |
| 17:06:04 | mnaser | i'll have to deal with the image backend stuff again soon :( | |
| 17:06:19 | melwitt | godspeed | |
| 17:06:23 | mriedem | https://ibm-blue-box-help.github.io/help-documentation/nova/Metadata_service_FAQ/ is actually pretty nice | |
| 17:06:33 | openstackgerrit | Vishakha Agarwal proposed openstack/nova master: 'Updated_at' is NULL when show aggregate info https://review.openstack.org/580271 | |
| 17:06:38 | mnaser | we're setting up a new az as a cell and i dont want glance downloading stuff 24x7 because we have an expensive 10g link across az's | |