16:00:59 <jungleboyj> #startmeeting Cinder
16:00:59 <openstack> Meeting started Wed Oct 17 16:00:59 2018 UTC and is due to finish in 60 minutes.  The chair is jungleboyj. Information about MeetBot at http://wiki.debian.org/MeetBot.
16:01:00 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
16:01:03 <openstack> The meeting name has been set to 'cinder'
16:01:08 <xyang> hi
16:01:09 <whoami-rajat> Hi
16:01:12 <eharney> hi
16:01:17 <Luzi> hi
16:01:19 <mhen> hi o/
16:01:19 <yikun> hello
16:01:21 <jungleboyj> @!
16:01:21 <_pewp_> jungleboyj (^▽^)/ ʸᵉᔆᵎ
16:01:51 <walshh_> hi
16:02:03 <jungleboyj> Hey everyone.
16:02:15 <woojay> Morning
16:02:18 <ganso> hello
16:02:30 <tbarron> hi
16:02:43 <erlon> hey
16:03:38 <e0ne> hi
16:03:49 <jungleboyj> Looks like a good crowd joining.
16:04:55 <jungleboyj> Ok.  Lets get started.
16:05:00 <jungleboyj> #topic announcements
16:05:26 <jungleboyj> Don't really have any big announcements other than the fact that smcginnis_vaca is out the rest of the week.
16:05:32 <jungleboyj> Just for awareness.
16:06:28 <jungleboyj> So, we can move on to our topics for the week.
16:06:40 <jungleboyj> #topic Image Encryption Spec
16:06:49 <jungleboyj> mhen: Luzi
16:06:58 <mhen> o/
16:07:02 <Luzi> hi again :)
16:07:04 <mhen> as already mentioned on the ML, we created an etherpad to discuss the location for the proposed image encryption code:
16:07:10 <mhen> #link image encryption library discussion https://etherpad.openstack.org/p/library-for-image-encryption-and-decryption
16:07:11 <erlon> Luzi, hey
16:07:23 <mhen> we would like to receive input and comments from all involved projects, so please participate if possible :)
16:08:20 <mhen> I guess there's no need for discussing this here since this should happen in the etherpad right?
16:08:27 <jungleboyj> Yes.  Have been trying to get time to review.
16:08:34 <jungleboyj> eharney:  Have you reviewed yet?
16:08:54 <mhen> eharney reviewed our original spec
16:08:57 <eharney> jungleboyj: i wrote about a couple of concerns there -- those concerns generally still exist
16:09:06 <mhen> #link image encryption proposal https://review.openstack.org/#/c/608663/
16:09:13 <erlon> Luzi, nice, Its in my TODO list, I should get some time later this week or beginning of next to review the spec
16:09:35 <mhen> erlon, that would be great thanks :)
16:09:46 <mhen> regarding the comments on the spec
16:09:52 <mhen> the question was raised why we are not doing the image encryption on top of the volume’s LUKS layer for "upload-to-image" but instead propose to re-encrypt the volume data into an image
16:10:02 <mhen> as commented in the spec we consider volumes and images to be separate resources that each have their own format and encryption, able to be transformed into one another
16:10:22 <mhen> if such images were to be reused in any other way (e.g. “image save” in OSC, “server create --image” in Nova), handling this special case (double encryption) with the additional LUKS layer would be a nightmare to get consistently implemented everywhere images are handled
16:10:37 <mhen> at least that's our view on this
16:10:59 <eharney> this proposal assumes that if someone decides they want to encrypt images, and they are using cinder volume encryption, then the image encryption isn't needed because they are interchangeable
16:11:10 <eharney> but they are different encryption schemes that may have different properties and security guarantees
16:11:22 <eharney> so i'm not really sure that plays out well
16:12:15 <mhen> "the image encryption isn't needed because they are interchangeable" - our spec doesn't mean to imply that, does it sound to you like that?
16:12:21 <erlon> I don't know if is possible, but using the same encryption for both would be better for usability
16:12:53 <mhen> erlon, that'd mean that we'd use LUKS containers for the encrypted image format
16:12:59 <eharney> not re-encrypting the volume upon upload to image if it's already encryption with cinder/luks encryption, is what i'm referring to
16:13:06 <eharney> if it's already encrypted*
16:13:15 <erlon> I think I have brought this before and there was some reason why it wasn't possible
16:13:25 <mhen> erlon, and handling LUKS containers needs cryptsetup and root, also on user side
16:14:10 <eharney> luks doesn't necessarily require cryptsetup, qemu-img also supports it, i'm using it now in the WIP NFS encryption patch
16:14:34 <Luzi> eharney, can you link that patch?
16:14:39 <mhen> eharney, you are referring to the currently existing case of the "inherited" image encryption in Cinder copy_to_image that we decided to keep right?
16:15:17 <mhen> eharney, we could as well remove that behavior but that would break existing LUKS-based images (originating from cinder) in existing infrastructures
16:16:01 <eharney> Luzi: https://review.openstack.org/#/c/597148/  (warning: it's still generally a mess, but the code is there in some form)
16:16:12 <mhen> iirc qemu-img needs a plain-text key file right?
16:16:21 <mhen> for creating LUKS containers
16:16:28 <Luzi> thanks i just want to get an idea of it :)
16:17:17 <eharney> it can use plain-text key files, it can also use other ways to transfer the key in which are more secure, iirc
16:17:37 <erlon> eharney, raise "TODO:FIXME", exception.FIXME is the proper one :p
16:17:44 <eharney> :)
16:18:44 <eharney> anyway, need to think more on design and less on implementation here
16:19:13 <mhen> also if you ever were to read from an encrypted image that is in LUKS format, you can't stream the content without exposing it via temporary file (qemu-img convert) or dmcrypt endpoint (cryptsetup)
16:19:27 <mhen> at least from my understanding
16:19:59 <mhen> imo using another encryption format or re-using LUKS is a design decision that heavily impacts implementation
16:20:25 <mhen> but we can continue in the comments on the spec if you prefer
16:21:03 <jungleboyj> Sounds like there is still a lot of discussion required around this.
16:21:34 <mhen> yes
16:21:36 <jungleboyj> Would rather take our time on the design and get it right given how complicated Encryption is.
16:21:38 <eharney> yeah, i'll pick through the spec some more and continue there, not sure what else to add here forn ow
16:22:13 <mhen> okay, please look at the spec and the library discussion etherpad if you have time
16:22:32 <eharney> i'm still a bit wary of this idea of requiring openstacksdk, especially when we already have a library used for encryption (cursive)
16:22:44 <jungleboyj> #action eharney to do more review of the spec.
16:23:21 <mhen> eharney, please add your points to the etherpad then :)
16:24:06 <mhen> so that would be all from our side then, thanks everyone for your attention :)
16:24:15 * mhen bows
16:24:21 <jungleboyj> Ok.  Sounds good.
16:24:26 <eharney> thanks
16:24:29 * jungleboyj bows back ?
16:25:15 <jungleboyj> #topic User Survey Forum Topic Planning
16:25:31 <jungleboyj> So, I added this topic as I want to make sure we don't forget this for the summit.
16:26:11 <erlon> jungleboyj, do we have any document we can start from?
16:26:26 <jungleboyj> So, we wanted to address the comments from the feedback.
16:26:40 <jungleboyj> erlon:  :-)  Yeah, that seems to be the first step here is to create an etherpad.
16:27:36 <jungleboyj> Lets start here:
16:27:44 <jungleboyj> #link:  https://etherpad.openstack.org/p/cinder-berlin-forum-survey-feedback
16:29:43 <erlon> jungleboyj, Im confused about this survey, is this about the questions that we send to the openstack survey?
16:30:24 <jungleboyj> Thinking I can summarize the feedback in there and then we can decide how we want to proceed.
16:30:47 <jungleboyj> erlon:  No, this is to discuss the information they sent to us during the last survey.
16:30:52 <jungleboyj> Address the concerns.
16:31:22 <erlon> jungleboyj, hmm, got it we had some notes from the PTG etherpad right?
16:31:40 <erlon> some feature requests, and other things
16:31:43 <jungleboyj> Right.
16:32:12 <jungleboyj> They have sent me an updated excel sheet with more info and translations.
16:32:26 <jungleboyj> I can link that in the etherpad and start organizing the responses.
16:33:05 <jungleboyj> I pull all that into the etherpad and we can discuss at next week's meeting.  Sound ok to everyone?
16:33:17 <erlon> sounds good
16:34:25 <jungleboyj> Ok.  Had hoped to get more done on that this week but have been fighting another fire.
16:35:46 <jungleboyj> #action jungleboyj  To make the translated feedback available.
16:36:04 <jungleboyj> #action jungleboyj  To summarize concerns in the etherpad above.
16:36:25 <jungleboyj> #action team to discuss in next week's meeting to prepare for the Summit.
16:36:41 <jungleboyj> Ok.  Anyone have other questions about that?
16:37:45 <jungleboyj> Ok.
16:37:56 <jungleboyj> #topic Volume revert-snapshot errors
16:37:59 <jungleboyj> erlon:
16:38:49 <jungleboyj> erlon:  You still around?
16:38:57 <erlon_> ooops
16:39:01 <erlon_> energy drop
16:39:03 <jungleboyj> :-)
16:39:15 <jungleboyj> Boo.  That happened here the other day.
16:39:20 <erlon_> did I miss something? have you guys solved my problem already?
16:39:23 <erlon_> :)
16:39:31 <jungleboyj> No, erlon_  Your turn.
16:39:42 <erlon_> ok
16:40:34 <erlon_> so, I was playing with the revert snapshot, and noticed that the API is not blocking operations when the users tries to revert to a snapstho with smaller size than the volume size
16:40:38 * jungleboyj taps the microphone ... is this thing on?
16:40:51 <erlon_> #link https://specs.openstack.org/openstack/cinder-specs/specs/pike/cinder-volume-revert-by-snapshot.html
16:41:14 <erlon_> the spec says: 409, if volume and snapshot's status are not 'available' or
16:41:15 <erlon_> the sizes of volume and snapshot are not equal.
16:41:36 <erlon_> just need to confirm if this is a bug or a design change on the implementation
16:42:01 <erlon_> jungleboyj, that is why I was asking about Tommy
16:42:09 <erlon_> but someone else here could also know
16:43:06 <jungleboyj> erlon_:  Interesting.
16:43:29 <jungleboyj> I am not sure if that was a change from the Spec or a Bug in Implementation.
16:44:12 <jungleboyj> I am of two minds here.  If they extended the volume and they revert they are going to lose the size change.
16:44:17 <erlon_> jungleboyj, I tested for LVM, which does not handle this situation, but LVM increase the snapshot size when you extend the volume
16:44:28 <jungleboyj> They are going to lose any additional data they added either way though.  Right?
16:44:32 <erlon_> so, in theory, for LVM that would be OK
16:45:46 <jungleboyj> erlon_: Would be nice if we could get hold of Tommy to verify what happened.
16:45:46 <erlon_> jungleboyj, yes they will, but for Cinder, the volume still have the bigger size
16:46:09 <erlon_> yeap, he will definitely know that
16:47:20 <erlon_> well, just a head ups to see if I could get any feedback from someone other than Tommy
16:47:34 <erlon_> I'm good if nobody has any clue
16:47:43 <jungleboyj> erlon_:  Oh you are saying we could get into a state where the volume is actually smaller than Cinder says.
16:48:35 <jungleboyj> Because then that is a problem.
16:48:42 <ganso> sounds like a bug
16:48:43 <erlon_> jungleboyj, yes, if the backend does not handle that and allow the revert
16:49:04 <jungleboyj> erlon_:  Then that is definitely a but.
16:49:06 <jungleboyj> *bug
16:49:15 <erlon_> the thing being is that for LVM, the revert operation does not shrink the size of the volume
16:49:32 <jungleboyj> Was assuming that if it reverted to a different sized volume that the size would be updated.
16:50:28 <erlon_> let's  say, You create a volume, take a snapshot, extend it, and revert to the snapshot. ON LVM, when you extend, the snapshot size (in the storage size) gets extended too
16:50:40 <ganso> erlon_: I'd say that if this kind of operation is allowed, then LVM should shrink the volume back. Same if the volume has been shrinked, and then reverted to a bigger one
16:50:41 <jungleboyj> erlon_:  Got it.
16:50:43 <erlon_> but that does not happens to other drivers, like SolidFire
16:51:09 <jungleboyj> ganso:  Can you shrink a volume though?
16:51:24 <erlon_> no, cinder does not allow that
16:51:34 <ganso> jungleboyj: oh nvm, forgot that Manila has this functionality, not Cinder
16:52:36 <erlon_> Im not aware of LVM limitations about extending/reverting snapshots
16:52:37 <jungleboyj> ganso:  Ok, was confused for a minute.
16:53:26 <jungleboyj> So, we would have to have some sort of special case for changing the volume size in the DB?
16:53:30 <ganso> s/shrinked/shrunk
16:54:36 <erlon_> jungleboyj, well I think that the best approach would be either not allow the operation and clock in the API, or set the volume size to the proper size on DB
16:54:50 <erlon_> s/clock/block/
16:55:03 <jungleboyj> erlon_:  That would be the two options.  :-)
16:55:23 <jungleboyj> Anyone have a strong opinion on the direction to go here?
16:55:43 <erlon_> lol, dont need the 2. If you don't allow that to happen, dont need to set the proper size
16:56:00 <jungleboyj> Right.
16:57:32 <jungleboyj> So, it seems ok to allow the revert.
16:57:45 <jungleboyj> If I want to go back to that snapshot, I want to go to that snapshot.
16:58:00 <jungleboyj> I may be annoyed in the future when it is smaller, but then I have to remember I reverted.
16:58:04 <jungleboyj> Extend it again.
16:58:21 <jungleboyj> But, then we have a bug and we need to make sure that the size in the DB is right.
16:59:03 <jungleboyj> Anyone have a concern about fixing the bug and leaving the function?
16:59:23 <erlon_> jungleboyj, I don't know if there was any architectural problem related to revert to a small size
16:59:45 <erlon_> Ill try to talk to Tommy or if not able to understand if there would be any
16:59:47 <jungleboyj> erlon_:  You willing to check into it?
16:59:55 <erlon_> jungleboyj, ye
16:59:57 <erlon_> p
17:00:07 <jungleboyj> erlon_:  Ok.  You may need to e-mail him. Don't see him on IRC anymore.
17:00:27 <jungleboyj> Lets start there and then discuss next week if necessary.
17:00:46 <jungleboyj> #action erlon_ To follow up with Tommy on the design choice and get back to us.
17:00:50 <erlon_> jungleboyj, good point Ill do that
17:00:51 <jungleboyj> And we are at time.
17:00:57 <jungleboyj> Thank you everyone!
17:01:04 <jungleboyj> Talk to you next week.
17:01:08 <whoami-rajat> jungleboyj: Thanks.
17:01:12 <jungleboyj> #endmeeting