| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-10-08 | |||
| 15:50:25 | artom | dansmith, left some thoughts about exception handling in your series | |
| 15:50:35 | artom | dansmith, tell me if I'm way off base | |
| 15:51:13 | dansmith | artom: ack, thanks | |
| 15:51:32 | dansmith | mriedem: looks like the bulk of our aggregate docs are in the user guide.. is that where you think I should put my stuff? | |
| 15:53:20 | mriedem | dansmith: rebase, that all recently moved and just merged | |
| 15:53:38 | mriedem | https://docs.openstack.org/nova/latest/admin/aggregates.html | |
| 15:53:54 | dansmith | mriedem: like, this week? | |
| 15:53:57 | mriedem | yeah | |
| 15:54:02 | dansmith | mkay | |
| 15:54:07 | mriedem | https://review.opendev.org/#/c/667133/ | |
| 15:54:13 | mriedem | merged last night | |
| 15:54:41 | mriedem | efried: before i make changes please ack that i've answered your questions here https://review.opendev.org/#/c/686835/2/nova/tests/functional/test_boot_from_volume.py@192 | |
| 15:56:55 | mriedem | dansmith: if we had docs on the image cache in general i'd say that would be a good place but we don't have any docs about the image cache :( | |
| 15:57:06 | dansmith | heh | |
| 15:58:27 | mriedem | i guess another place you could stuff it is https://docs.openstack.org/nova/latest/admin/manage-the-cloud.html if that aggregates page isn't a good fit | |
| 16:01:05 | dansmith | erm, the aggregates page seems better than that | |
| 16:01:15 | dansmith | but obviously something image- or imagecache-specific would be better | |
| 16:01:33 | dansmith | I'll add it here in minimal detail and then we should probably shoot for some imagecache doc | |
| 16:02:34 | dansmith | looks like something has reshuffled in that aggregates doc to put the usage section after the more advanced topics | |
| 16:02:41 | mriedem | i think a pretty simple image cache doc could start with a high level description, list of drivers that support it, and the related config options | |
| 16:03:00 | mriedem | dansmith: you'll have to wrestle with stephenfin about that | |
| 16:04:09 | dansmith | heh yeah all the google linkage is broken now after that admin/user shuffleup | |
| 16:04:47 | mriedem | yeah i'm not surprised, the patch didn't account for redirects | |
| 16:06:16 | dansmith | yeah that new aggregates page is just kindof a mess and the ordering makes no sense | |
| 16:06:24 | dansmith | I guess I'll just chuck my thing at the bottom | |
| 16:06:34 | openstackgerrit | Merged openstack/nova master: compute: refactor volume bdm rollback error handling https://review.opendev.org/656500 | |
| 16:06:41 | openstackgerrit | Merged openstack/nova master: doc: Improve PDF document structure https://review.opendev.org/682746 | |
| 16:06:51 | openstackgerrit | Merged openstack/nova master: docs: Remove a whole load of unused images, most remainder https://review.opendev.org/686211 | |
| 16:06:57 | openstackgerrit | Merged openstack/nova master: trivial: Change name of network provided by NeutronFixture https://review.opendev.org/686798 | |
| 16:07:05 | openstackgerrit | Merged openstack/nova master: nova-net: Stop mocking the instance network cache https://review.opendev.org/686799 | |
| 16:07:16 | openstackgerrit | Merged openstack/nova master: trivial: Make it obvious where we're getting our names from https://review.opendev.org/686800 | |
| 16:09:13 | mriedem | luckily infra has a report of active docs 404s | |
| 16:10:35 | sean-k-mooney | the most annoying thing about google+docs is it does not priorties latest | |
| 16:10:47 | mriedem | http://files.openstack.org/docs-404s/ | |
| 16:11:11 | dansmith | sean-k-mooney: that's probably good since we apparently just break our latest a lot | |
| 16:11:49 | mriedem | 5 /nova/latest/user/aggregates.html | |
| 16:11:55 | mriedem | yeah we should have a redirect for that | |
| 16:11:58 | mriedem | stephenfin: ^ | |
| 16:13:33 | stephenfin | Did I miss one? | |
| 16:13:39 | stephenfin | crap, yeah, let me add it now | |
| 16:15:05 | mriedem | dansmith: just for tracking: https://bugs.launchpad.net/nova/+bug/1847302 | |
| 16:15:05 | openstack | Launchpad bug 1847302 in OpenStack Compute (nova) "doc: need admin guide for the image cache" [Undecided,New] | |
| 16:16:04 | openstackgerrit | Dan Smith proposed openstack/nova master: Add cache_image() driver method and libvirt implementation https://review.opendev.org/687137 | |
| 16:16:04 | openstackgerrit | Dan Smith proposed openstack/nova master: Add cache_image() support to the compute rpc, api, and manager https://review.opendev.org/687138 | |
| 16:16:05 | openstackgerrit | Dan Smith proposed openstack/nova master: Add cache_images() to conductor https://review.opendev.org/687139 | |
| 16:16:05 | openstackgerrit | Dan Smith proposed openstack/nova master: Add image caching API for aggregates https://review.opendev.org/687140 | |
| 16:16:06 | openstackgerrit | Dan Smith proposed openstack/nova master: WIP: Add image precaching docs for aggregates https://review.opendev.org/687348 | |
| 16:17:09 | openstackgerrit | Matt Riedemann proposed openstack/nova master: doc: fix formatting in mitigation-for-Intel-MDS-security-flaws https://review.opendev.org/687350 | |
| 16:18:47 | dansmith | gibi: (or mriedem) are there any examples of not-instance-related notifications I can copy for image pre-caching? | |
| 16:19:03 | mriedem | there are notifications for aggregates and services | |
| 16:19:11 | mriedem | agg add/remove host i think | |
| 16:19:41 | dansmith | ah yep | |
| 16:20:19 | mriedem | there are also the more generic compute_task.* ones but i'm guessing we should follow the aggregate ones since this is on the aggregates route | |
| 16:20:45 | dansmith | well, the aggregates ones are api-centric, but this would be host-centric | |
| 16:20:48 | mriedem | aggregate.image.cache.start|end? | |
| 16:20:51 | dansmith | i.e. "host foo started downloading a thing" | |
| 16:21:01 | dansmith | no, I want it to be host-specific so you can monitor progress | |
| 16:22:03 | dansmith | although I guess notify_about_aggregate_update could be sent from the conductor | |
| 16:22:08 | dansmith | as long as it mentions the host | |
| 16:22:42 | dansmith | that would allow us to notify about timeouts, etc | |
| 16:23:13 | mriedem | i think notify_about_aggregate_update is the legacy thing | |
| 16:23:21 | mriedem | notify_about_aggregate_action is the versioned notification thing | |
| 16:23:44 | mriedem | there is also a legacy notify_about_host_update for things on the os-hosts api | |
| 16:23:48 | dansmith | okay | |
| 16:23:51 | mriedem | and that's likely closer to what you're looking for | |
| 16:24:15 | mriedem | i don't think those got converted to versioned notifications b/c the os-hosts api is deprecated | |
| 16:27:10 | openstackgerrit | Stephen Finucane proposed openstack/nova master: docs: Add redirects for '/user/aggregates' https://review.opendev.org/687353 | |
| 16:27:15 | stephenfin | mriedem: ^ | |
| 16:27:38 | mriedem | yar matey | |
| 16:30:02 | mriedem | huh, that patch is triggering functional jobs, must have something missing in our zuul yaml blacklist | |
| 16:30:19 | dansmith | mriedem: so, I'm not really sure what the rules are on our new notifications.. I think I could use AggregatePayload to convey what I want, but not sure if I should | |
| 16:30:47 | dansmith | i.e. AggregatePayload(name="aggregate.imagecache.start", uuid=agg.uuid, hosts=[this_compute]) | |
| 16:30:59 | mriedem | no i don't think that's what you want | |
| 16:31:52 | mriedem | my guess is you'll end up creating a new single purpose thing like VolumeUsagePayload and MetricsPayload | |
| 16:32:48 | mriedem | so, | |
| 16:32:56 | mriedem | maybe you're thinking of something like this: | |
| 16:33:08 | mriedem | 1. generic aggregate payload based thing to start the operation sent from conductor | |
| 16:33:17 | mriedem | 2. start/end notifications per compute which would be a new payload | |
| 16:33:28 | mriedem | 3. end version of #1 in conductor once it's done processing all hosts | |
| 16:33:58 | mriedem | so if a consumer cares about only the overall op being done and not the host specific details they can just listen for that | |
| 16:34:04 | dansmith | yeah | |
| 16:34:14 | mriedem | so for 1 and 3 you'd use notify_about_aggregate_action | |
| 16:34:17 | mriedem | with a new action | |
| 16:34:19 | dansmith | so is that a new notification and payload? | |
| 16:34:20 | mriedem | #2 will be a new payload | |
| 16:34:44 | mriedem | notify_about_aggregate_action is what's used for the existing aggregate actions like create/delete/update meta/add and remove host | |
| 16:34:51 | dansmith | meaning, AggregateImageNotification, AggregateImagePayload | |
| 16:34:52 | sean-k-mooney | is the per host version too verbose. not that i think its a bad idea but im wonder would you jsut wait for the conductor start/end | |
| 16:34:57 | mriedem | i think 1 and 3 above fit into that with a new 'cache_images' action or something | |
| 16:35:29 | dansmith | sean-k-mooney: I'm already waiting in the conductor.. I want them to be able to construct the per-host status from notifications if they want, which was part of the original discussion | |
| 16:35:38 | mriedem | i would start with the 1 and 3 cases in conductor since that's pretty trivial | |
| 16:35:54 | sean-k-mooney | dansmith: ah ok | |
| 16:35:57 | mriedem | and then separately bake in the new per-host payload and such | |
| 16:35:59 | mriedem | with gibi's input | |
| 16:36:16 | dansmith | mriedem: yep, separate patch fo'sho | |
| 16:36:47 | sean-k-mooney | dansmith: ya i was wondering if people would go to the effort of reconstructing the hot view but i can see wanting to do that | |
| 16:37:04 | sean-k-mooney | *host | |
| 16:37:23 | dansmith | sean-k-mooney: I want them to be able to so I can use that to deflect requests for a full reporting API, at least initially | |
| 16:37:33 | mriedem | was just going to say that ^ | |
| 16:37:36 | sean-k-mooney | :) | |