Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-05-12
15:41:33 dansmith show_multiple_locations = True
15:41:49 sean-k-mooney https://github.com/openstack/devstack-plugin-ceph/commit/62ea04c8d180c5419300ddc7784c5c46f9fcbdad
15:42:02 dansmith I think ^ is what we need for the check we do
15:42:12 dansmith not sure the difference between that and the show-direct-url one
15:42:19 dansmith because, AFAIK, the locations are the direct url
15:43:11 dansmith ah,
15:43:12 jsuchome so show_multiple_locations also implies the location info is present?
15:43:18 dansmith that commit implies that one impliesthe other
15:43:19 dansmith yeah
15:45:46 sean-k-mooney lyarwood's job is curerntly running https://zuul.openstack.org/stream/9b459dcfc0cd46d0a13ce5a5a1be2afe?logfile=console.log so we will know one way or another in about an hour
15:45:56 sean-k-mooney maybe too
15:46:00 sean-k-mooney *two
15:46:22 sean-k-mooney but if we need to add anything else we can do that quickly once its done
15:47:08 jsuchome well that allowed_direct_url_schemes is a must, we only fire the new download handler if it is set
15:47:35 sean-k-mooney so we need that in nova i can see if that is set by the plugin
15:48:17 dansmith it won't be
15:48:23 dansmith I thought lyarwood did it in his change
15:48:47 lyarwood sorry I missed that
15:48:56 lyarwood [glance]/allowed_direct_url_schemes=['rbd']?
15:49:10 sean-k-mooney ya i was about to ask the same https://opendev.org/openstack/nova/src/branch/master/nova/conf/glance.py#L64
15:49:32 dansmith lyarwood: not sure what group, but yes, hang on
15:49:53 sean-k-mooney its in the glance group
15:49:59 jsuchome yep
15:50:27 dansmith if 'rbd' in CONF.glance.allowed_direct_url_schemes:
15:50:27 sean-k-mooney do we plan to turn this on by default
15:50:36 dansmith no
15:50:49 jsuchome it should be documented
15:50:56 sean-k-mooney ok we proably should remove the deprecation of that option in jsuchome patch
15:51:01 sean-k-mooney i assume it already does that
15:51:22 dansmith the spec says we will undeprecate it yes
15:51:28 sean-k-mooney k
15:51:39 jsuchome does it need a release note?
15:51:46 dansmith yes
15:51:56 sean-k-mooney the feature would even without the undeprecation
15:52:01 sean-k-mooney the same one can cover both
15:52:39 jsuchome ok, than it's another change for 574301
15:53:18 dansmith jsuchome: I probably wouldn't pile that in there personally
15:56:48 jsuchome OK, another patch, no problem
15:57:03 dansmith jsuchome: at least for the moment, we can always squash
15:57:24 dansmith I think that by the time you get all the test stuff in this patch it will be plenty meaty
15:57:54 dansmith one could argue that it could go in my first patch to remove the plug point, but that just means it has two semi-related atomic changes
15:57:57 dansmith patches are cheap
15:58:30 jsuchome yeah, and for tommorrow I got to work on the tests, I can see they are not enough
15:58:38 dansmith cool
16:09:26 openstackgerrit Balazs Gibizer proposed openstack/nova master: WIP: allow disabling image cache for raw images https://review.opendev.org/727261
16:09:30 gibi dansmith, sean-k-mooney: I looked at how easy is to disable the image cache and this is my first stab on it (seem to work in devstack) ^^
16:10:19 gibi I will have to disappear now but feedback is appreciated
16:11:12 dansmith gibi: I don't understand that
16:13:52 sean-k-mooney dansmith: i assumed it was just me :)
16:14:19 sean-k-mooney also i expected to not underdstand that when looking at that code
16:18:44 dansmith yeah
16:19:05 dansmith I'll have to get all dug-in to that code again to really be able to speak intelligently about it,
16:19:15 dansmith but that surely seems to be basically doing the same thing as above at first glance
16:22:01 dansmith sean-k-mooney: ah, maybe because this is the Flat implementation
16:22:30 dansmith but I really thought that it still cached even though it flattened the image before giving it to the instance, which this doesn't seem to change
16:23:32 sean-k-mooney dansmith: it is cached
16:23:37 sean-k-mooney we copy it
16:23:48 sean-k-mooney on line 598
16:24:00 sean-k-mooney https://review.opendev.org/#/c/727261/1/nova/virt/libvirt/imagebackend.py@598
16:24:08 dansmith yeah
16:24:15 dansmith I wonder if gibi tested this and we're missing something, or he's assuming something else
16:24:37 sean-k-mooney well this would also have to be done for qcow right
16:24:38 dansmith sean-k-mooney: we only copy if it doesn't exist, and he's passing self.path as the target
16:24:54 dansmith but, so does the "if generating" case above
16:25:32 sean-k-mooney right so if self.path whcih shoudl be the imnstance disk path does not exist
16:25:33 dansmith so I wonder if we're normally in Flat to grab the base image, and this makes for another case where we just download the image to our target when not caching and that somehow bypasses,
16:25:44 sean-k-mooney before we would take the else path and create a copy form the base path
16:25:46 dansmith but I think the call path to the caching is too loopy to tell that
16:26:10 sean-k-mooney i think this will actully work but only for the flat backend
16:26:10 dansmith disabling the image cache entirely is also somewhat of a way-too-big hammer to solve this problem
16:26:17 dansmith it's a workaround maybe, but it's really a terrible one
16:26:26 sean-k-mooney ya
16:26:37 sean-k-mooney did you see my converstaion with gibi this morining
16:26:43 dansmith I did
16:26:50 dansmith well, I skimmed it
16:27:05 sean-k-mooney cool what do you think of the idea of creating allocation for the cached images inplacment
16:27:12 dansmith sean-k-mooney: I suggested that yesterday
16:27:13 sean-k-mooney so we can track how much is being used
16:27:17 sean-k-mooney ok cool
16:27:27 dansmith we have to be able to do it separately if the cache is on a different filesystem though,
16:27:35 dansmith which will get messy, especially if you move it later
16:27:46 sean-k-mooney ya
16:27:48 dansmith and we'll need new healing stuff to make sure we can recover from getting out of sync
16:28:03 sean-k-mooney and if people put the cache on nfs or somehting it will be even worse
16:28:18 dansmith yes
16:28:35 dansmith so yeah, it's a thing, but it's not trivial for sure
16:28:36 sean-k-mooney when you say self heling are you thinking nova audit or a periodic taks in the agent
16:29:03 dansmith yeah, just anything that causes us to leak some allocations for images that are no longer cached,
16:29:09 dansmith and also notice that new images are on disk that aren't allocated
16:29:29 dansmith because we already tell customers they can sideload images into the disk cache and nova will (rightly) use them propery
16:29:33 dansmith but wouldn't have alocations for them
16:29:34 sean-k-mooney dansmith: ideally i was think as well that it would make the caching best efffort. e.g. it would check if it was in the cache. if not check if it can create an allcotion for the image and cache it if it can and dont cache if it cant
16:30:01 dansmith yes, but if it can't then it has to delete that allocation of course,
16:30:14 dansmith and if everything goes nuts during that, we have to be able to heal away those stale ones when we reboot
16:30:14 sean-k-mooney dansmith: do we actully support the sideloading or just it should work
16:30:25 dansmith and if images get sideloaded, we have to notice, and if images get locally deleted, we have to notice
16:30:36 dansmith sean-k-mooney: it does work and we (redhat) have prescribed it in a few cases :)
16:31:02 sean-k-mooney .... im glad you have added the image cacahing feature in teh api to have an alternitive noew
16:31:03 dansmith and I know people have in the past manually purged images from that cache before the timer fires
16:31:35 dansmith sean-k-mooney: yep, but that only works (by design) per aggregate, and doesn't let you purge,

Earlier   Later