Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2021-07-13
16:43:29 sean-k-mooney in nova.conf
16:43:32 lyarwood sean-k-mooney: rbd image backend
16:44:01 alistarle It it for a case when you used RBD as a glance store, then you replace it with a swift one, and you want to progressively move out from ceph
16:44:10 sean-k-mooney so the request is to flaten the snapshots effectivly in ceph and then have new shapshots go to swift
16:44:18 dansmith alistarle: okay I thought I asked you this question on the spec
16:44:41 sean-k-mooney alistarle: well one thing we do not support is changing the nova image_types backend
16:45:01 sean-k-mooney including via a move operation like cold migrate
16:45:04 lyarwood sean-k-mooney: you wouldn't, that doesn't control where the image is
16:45:05 dansmith alistarle: maybe what you want is to be able to tell nova-compute which glance backend you want to snapshot to, to create a flattened snapshot in the desired store, which may not be the rbd one?
16:45:31 sean-k-mooney lyarwood: well im aware of that but the usecase given was removing ceph
16:45:36 alistarle I think it is a good catch dansmith
16:45:38 dansmith telling it not to use rbd snapshotting "just because" is more confusing
16:45:42 lyarwood dansmith: does Glance support moving images between backends?
16:45:56 dansmith lyarwood: copying, yes, but that's not what I mean
16:46:00 lyarwood sean-k-mooney: dropping rbd just for Glance AFAICT
16:46:14 sean-k-mooney alistarle: is ^ the case
16:46:26 dansmith lyarwood: I meant tell nova "specifically create a flattened snapshot and upload it to a specific glance backend"
16:46:45 sean-k-mooney dansmith: that i think would be useful in other cases too
16:47:00 dansmith lyarwood: I don't think glance really exposes parent-child relationships anyway, so you couldn't expect to copy/move a hierarchy between backends
16:47:01 sean-k-mooney adding a glance store parater to the snapshot api i think woudl be resonable
16:47:03 dansmith either way,
16:47:14 alistarle So you think it is better to change the snapshot API to allow users to choose which glance backend to use to snap the image ?
16:47:14 dansmith I think it's quite clear that this can't be a specless bp :)
16:47:35 alistarle Yeah I see you point, for sure it will require a spec in that case
16:47:46 dansmith alistarle: that's not what I was suggesting, although that might also be an option.. the problem is, many ops will *not* want users to choose the pathologically terrible option, which you seem to want :)
16:48:10 alistarle But actually we will need to do the same code, so if a user explicitly specify a glance store, we need to bypass the direct_snapshot process
16:48:11 dansmith I was suggesting a conf option for nova-compute to tell it "always snapshot to glance backend X" or something
16:48:34 dansmith instead of letting a user choose
16:48:54 alistarle Because as of now, rbd image_backend do not care about glance config, he will magically decide to use ceph because VM disk is stored in ceph
16:49:08 sean-k-mooney i kind of dislike doing this per host but i guess a host level config might be useful for an edge deployment
16:49:55 sean-k-mooney alistarle: correct although that is partly be desgin
16:50:01 alistarle Oh I see, so instead of putting a config option to "disable direct snapshot", we put an option to "choose a glance backend"
16:50:27 alistarle And if we specify this option, we skip the direct_snapshot to always call glance
16:50:37 sean-k-mooney alistarle: well not nessisarly
16:50:48 sean-k-mooney if the specifed backedn was ceph
16:51:03 sean-k-mooney then direct would stil make sense
16:51:03 dansmith sean-k-mooney: letting users choose the backend on snapshot will mean they try all kinds of things that won't work or are terrible for performance
16:51:06 sean-k-mooney if the vm was backed by that ceph cluster
16:51:14 dansmith sean-k-mooney: like a user who is currently on ceph always choosing the file backend, causing us to always flatten and upload when we shouldn't be
16:51:43 sean-k-mooney dansmith: yes although i was wondiering if people woudl want to do that for data reducnace reasons
16:52:17 sean-k-mooney e.g. normally backup to local edge site with a snapshot and ocationally do it to central site
16:52:31 dansmith sean-k-mooney: I mean, it would be nice, but I think we'd need policy, defaults, and some sort of way to know which ones the compute can even talk to
16:52:48 dansmith sean-k-mooney: yeah, but not backup from one edge site to another.. that would be terribad
16:52:58 dansmith so we'd have to have some mapping of who can do what, etc
16:53:13 sean-k-mooney ya which is not realy somethng a normal user woudl be aware off
16:53:20 dansmith for sure
16:53:34 sean-k-mooney so we have 2 pothtial host level cofnig options
16:53:49 sean-k-mooney disableing direct snapshto whihc to me feels more like a workaround option
16:53:58 sean-k-mooney and dansmith's glance backend option
16:54:13 sean-k-mooney *glance store
16:54:43 dansmith yup.. the former is a workaround for sure, and as we've noted here, hard to even grok what or why you'd want it,
16:54:52 sean-k-mooney im a little concerned the host level glance store option will have implications for shelve and cross cell migration
16:55:08 dansmith but the latter is at least useful for migrating in or out of some thing, or directing snapshots to an appropriate on- or off-site location depending
16:55:32 dansmith sean-k-mooney: well, whatever the default is today already does, AFAIK
16:55:51 sean-k-mooney i do think i prefer the store approch
16:56:06 sean-k-mooney ya fair we just assume that glance is accable everywhere
16:56:17 gibi we have 5 minutes left, is there any other topic today? if not the we can continue this of course
16:56:27 dansmith spec on this for sure tho
16:56:49 gibi the spec it is
16:56:53 gibi then
16:57:07 gibi alistarle: please note that we have spec freeze on Thursday for Xena
16:57:32 lyarwood Quick one from me, I'm out for the next ~2 or so weeks, stephenfin is babysitting some stuff while I'm gone.
16:57:48 gibi lyarwood: thanks for the headsup
16:58:27 gibi if nothing else for today, then I will close the meeting but you can continue discussing the snapshot issue
16:59:18 gibi than thanks for joining
16:59:21 opendevmeet Meeting ended Tue Jul 13 16:59:21 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:59:21 gibi #endmeeting
16:59:21 opendevmeet Log: https://meetings.opendev.org/meetings/nova/2021/nova.2021-07-13-16.00.log.html
16:59:21 opendevmeet Minutes (text): https://meetings.opendev.org/meetings/nova/2021/nova.2021-07-13-16.00.txt
16:59:21 opendevmeet Minutes: https://meetings.opendev.org/meetings/nova/2021/nova.2021-07-13-16.00.html
17:14:49 alistarle Sorry guy's I just miss the end of the meeting
17:15:13 melwitt gibi: ack re: the consumer type spec, I'm happy to propose it in the placement repo, either way, lmk what you think
17:15:21 alistarle So if I understand well I need to write a spec for that and freeze is Thursday, so it is dead for Xena right ?
17:15:27 melwitt stephenfin: ack, will look at the update on your patch
17:19:53 sean-k-mooney alistarle: it would be challanging to land by thursday yes
17:20:13 sean-k-mooney alistarle: i would still suggest working on the spec and a poc of the implementaiton
17:20:28 sean-k-mooney but likely it would be a yoga change at this point
17:21:35 sean-k-mooney alistarle: im not sure if dansmith woudl agree but i could maybe see adding a [workarounds]disable_direct_snapshot=True|False config option as a bug in xena
17:22:06 dansmith zI dunno,
17:22:13 sean-k-mooney alistarle: but i think as a long term feature it would need a spec and that likely cant land in xena
17:22:24 dansmith I was having a hard time seeing the value, and clearly lyarwood was as well
17:22:41 dansmith it's definitely a workaround, but doesn't really fit what the workarounds conf section was supposed to be
17:23:05 sean-k-mooney dansmith: so am i in that apprcoh but as a workaround option we could remvoe it in a sort period of time
17:23:13 dansmith I think I'd rather see it done as a generally-useful thing to avoid landing the workaround and then never closing on it
17:23:23 sean-k-mooney dansmith: i think we have a similar workaroud alredy
17:23:26 alistarle Actually it is not really an issue for me to see it in Yoga if it need more work, my only concern is if I need to wait 6 month to work on it
17:23:29 sean-k-mooney for live snapshots
17:23:46 dansmith alistarle: you can work on it now, just don't expect to merge before Y opens
17:23:47 sean-k-mooney https://docs.openstack.org/nova/latest/configuration/config.html#workarounds.disable_libvirt_livesnapshot
17:24:21 alistarle Oh I see, there is a dedicated workaround section
17:24:37 alistarle But does the workaround section follow the same deprecation cycle than others ?
17:24:39 sean-k-mooney alistarle: on no you would not need to wait 6 months
17:24:42 lyarwood I'd be happy with another workaround to disable_live_directsnapshot with this replacement approach being worked on in Y
17:25:10 sean-k-mooney we have actully just created the yoga spec folder
17:25:54 sean-k-mooney so you could actully submit a spec to that folder for next cycle which we coudl review, and then you could work on the implemation to merge in early y
17:26:27 sean-k-mooney althoguh we normally dont approve specs for the next release until later in the cycle
17:26:59 sean-k-mooney alistarle: yes workaround follow the same dperecation cycle
17:27:18 sean-k-mooney alistarle: although we have in the passed intoduced workarounds as deprecated imidetly
17:27:26 dansmith if alistarle is fine with Y, then why not do it just once, in Y?
17:29:09 alistarle Actually I don't really care about when it will be officially released, as I can backport my commit easily, I just hope we can freeze the implementation as soon as possible, so I will not backport a different commit in the future

Earlier   Later