| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-08-01 | |||
| 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 | distraction | |
| 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: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 | |
| 17:07:09 | mnaser | one thing i'll have to figure out and work more on is making sure API can survive one site going down.. so running apis in both sites.. or idk yet | |
| 17:07:27 | dansmith | mnaser: not yet :) | |
| 17:07:39 | mriedem | dansmith: heh sound familiar? https://ibm-blue-box-help.github.io/help-documentation/nova/Metadata_service_FAQ/#q-i-want-to-use-userdata-with-heat-but-my-data-is-over-the-16k-limit-what-should-i-do | |
| 17:07:50 | dansmith | mriedem: heh | |
| 17:08:01 | mnaser | lol ^ | |
| 17:08:15 | mnaser | but yeah i have to solve the image thing first.. | |
| 17:08:45 | mnaser | i was thinking it would be nice if the drivers that are all in cinder got extracted to a seperate library | |
| 17:08:48 | mnaser | say moved to os-brick | |
| 17:08:55 | mnaser | and then nova and cinder could use the same drivers to interact with stuff | |
| 17:09:08 | openstackgerrit | Merged openstack/nova master: Cache is_bfv check in ResourceTracker https://review.openstack.org/584962 | |
| 17:15:38 | melwitt | mnaser: has that been proposed before? I would think it would be more complex than just loading a driver and calling the same methods no matter the driver on the nova side | |
| 17:16:15 | mnaser | melwitt: i dunno, it was just an idea. i'm sure there are a lot of complexities involved but it would greatly reduce the duplicate code across cinder and nova | |
| 17:18:25 | openstack | bug 1784705 in OpenStack Compute (nova) "ResourceTracker.stats can leak across multiple ironic nodes" [High,In progress] https://launchpad.net/bugs/1784705 - Assigned to Matt Riedemann (mriedem) | |
| 17:18:25 | openstackgerrit | Merged openstack/nova master: Add recreate test for RT.stats bug 1784705 https://review.openstack.org/587614 | |
| 17:19:15 | dansmith | mriedem: I'm going to rebase your fix with my thing on top since it's in merge conflict now | |
| 17:19:34 | mriedem | gdi | |
| 17:19:35 | mriedem | ok | |
| 17:19:38 | mriedem | was just working on backports | |
| 17:19:54 | mriedem | oh i suppose my other RT changes caused the merge conflict | |
| 17:20:53 | dansmith | from what? | |
| 17:20:58 | mriedem | https://review.openstack.org/584962 ? | |
| 17:21:12 | dansmith | oh yeah, that one for yours, | |
| 17:21:23 | dansmith | but something else removed the _for_node() bit | |
| 17:23:51 | openstack | bug 1784705 in OpenStack Compute (nova) "ResourceTracker.stats can leak across multiple ironic nodes" [High,In progress] https://launchpad.net/bugs/1784705 - Assigned to Matt Riedemann (mriedem) | |
| 17:23:51 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/queens: Add recreate test for RT.stats bug 1784705 https://review.openstack.org/587921 | |
| 17:38:17 | openstackgerrit | Dan Smith proposed openstack/nova master: Make ResourceTracker.stats node-specific https://review.openstack.org/587636 | |