16:00:59 #startmeeting Cinder 16:00:59 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 16:01:03 The meeting name has been set to 'cinder' 16:01:08 hi 16:01:09 Hi 16:01:12 hi 16:01:17 hi 16:01:19 hi o/ 16:01:19 hello 16:01:21 @! 16:01:21 <_pewp_> jungleboyj (^▽^)/ ʸᵉᔆᵎ 16:01:51 hi 16:02:03 Hey everyone. 16:02:15 Morning 16:02:18 hello 16:02:30 hi 16:02:43 hey 16:03:38 hi 16:03:49 Looks like a good crowd joining. 16:04:55 Ok. Lets get started. 16:05:00 #topic announcements 16:05:26 Don't really have any big announcements other than the fact that smcginnis_vaca is out the rest of the week. 16:05:32 Just for awareness. 16:06:28 So, we can move on to our topics for the week. 16:06:40 #topic Image Encryption Spec 16:06:49 mhen: Luzi 16:06:58 o/ 16:07:02 hi again :) 16:07:04 as already mentioned on the ML, we created an etherpad to discuss the location for the proposed image encryption code: 16:07:10 #link image encryption library discussion https://etherpad.openstack.org/p/library-for-image-encryption-and-decryption 16:07:11 Luzi, hey 16:07:23 we would like to receive input and comments from all involved projects, so please participate if possible :) 16:08:20 I guess there's no need for discussing this here since this should happen in the etherpad right? 16:08:27 Yes. Have been trying to get time to review. 16:08:34 eharney: Have you reviewed yet? 16:08:54 eharney reviewed our original spec 16:08:57 jungleboyj: i wrote about a couple of concerns there -- those concerns generally still exist 16:09:06 #link image encryption proposal https://review.openstack.org/#/c/608663/ 16:09:13 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 erlon, that would be great thanks :) 16:09:46 regarding the comments on the spec 16:09:52 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 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 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 at least that's our view on this 16:10:59 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 but they are different encryption schemes that may have different properties and security guarantees 16:11:22 so i'm not really sure that plays out well 16:12:15 "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 I don't know if is possible, but using the same encryption for both would be better for usability 16:12:53 erlon, that'd mean that we'd use LUKS containers for the encrypted image format 16:12:59 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 if it's already encrypted* 16:13:15 I think I have brought this before and there was some reason why it wasn't possible 16:13:25 erlon, and handling LUKS containers needs cryptsetup and root, also on user side 16:14:10 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 eharney, can you link that patch? 16:14:39 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 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 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 iirc qemu-img needs a plain-text key file right? 16:16:21 for creating LUKS containers 16:16:28 thanks i just want to get an idea of it :) 16:17:17 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 eharney, raise "TODO:FIXME", exception.FIXME is the proper one :p 16:17:44 :) 16:18:44 anyway, need to think more on design and less on implementation here 16:19:13 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 at least from my understanding 16:19:59 imo using another encryption format or re-using LUKS is a design decision that heavily impacts implementation 16:20:25 but we can continue in the comments on the spec if you prefer 16:21:03 Sounds like there is still a lot of discussion required around this. 16:21:34 yes 16:21:36 Would rather take our time on the design and get it right given how complicated Encryption is. 16:21:38 yeah, i'll pick through the spec some more and continue there, not sure what else to add here forn ow 16:22:13 okay, please look at the spec and the library discussion etherpad if you have time 16:22:32 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 #action eharney to do more review of the spec. 16:23:21 eharney, please add your points to the etherpad then :) 16:24:06 so that would be all from our side then, thanks everyone for your attention :) 16:24:15 * mhen bows 16:24:21 Ok. Sounds good. 16:24:26 thanks 16:24:29 * jungleboyj bows back ? 16:25:15 #topic User Survey Forum Topic Planning 16:25:31 So, I added this topic as I want to make sure we don't forget this for the summit. 16:26:11 jungleboyj, do we have any document we can start from? 16:26:26 So, we wanted to address the comments from the feedback. 16:26:40 erlon: :-) Yeah, that seems to be the first step here is to create an etherpad. 16:27:36 Lets start here: 16:27:44 #link: https://etherpad.openstack.org/p/cinder-berlin-forum-survey-feedback 16:29:43 jungleboyj, Im confused about this survey, is this about the questions that we send to the openstack survey? 16:30:24 Thinking I can summarize the feedback in there and then we can decide how we want to proceed. 16:30:47 erlon: No, this is to discuss the information they sent to us during the last survey. 16:30:52 Address the concerns. 16:31:22 jungleboyj, hmm, got it we had some notes from the PTG etherpad right? 16:31:40 some feature requests, and other things 16:31:43 Right. 16:32:12 They have sent me an updated excel sheet with more info and translations. 16:32:26 I can link that in the etherpad and start organizing the responses. 16:33:05 I pull all that into the etherpad and we can discuss at next week's meeting. Sound ok to everyone? 16:33:17 sounds good 16:34:25 Ok. Had hoped to get more done on that this week but have been fighting another fire. 16:35:46 #action jungleboyj To make the translated feedback available. 16:36:04 #action jungleboyj To summarize concerns in the etherpad above. 16:36:25 #action team to discuss in next week's meeting to prepare for the Summit. 16:36:41 Ok. Anyone have other questions about that? 16:37:45 Ok. 16:37:56 #topic Volume revert-snapshot errors 16:37:59 erlon: 16:38:49 erlon: You still around? 16:38:57 ooops 16:39:01 energy drop 16:39:03 :-) 16:39:15 Boo. That happened here the other day. 16:39:20 did I miss something? have you guys solved my problem already? 16:39:23 :) 16:39:31 No, erlon_ Your turn. 16:39:42 ok 16:40:34 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 #link https://specs.openstack.org/openstack/cinder-specs/specs/pike/cinder-volume-revert-by-snapshot.html 16:41:14 the spec says: 409, if volume and snapshot's status are not 'available' or 16:41:15 the sizes of volume and snapshot are not equal. 16:41:36 just need to confirm if this is a bug or a design change on the implementation 16:42:01 jungleboyj, that is why I was asking about Tommy 16:42:09 but someone else here could also know 16:43:06 erlon_: Interesting. 16:43:29 I am not sure if that was a change from the Spec or a Bug in Implementation. 16:44:12 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 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 They are going to lose any additional data they added either way though. Right? 16:44:32 so, in theory, for LVM that would be OK 16:45:46 erlon_: Would be nice if we could get hold of Tommy to verify what happened. 16:45:46 jungleboyj, yes they will, but for Cinder, the volume still have the bigger size 16:46:09 yeap, he will definitely know that 16:47:20 well, just a head ups to see if I could get any feedback from someone other than Tommy 16:47:34 I'm good if nobody has any clue 16:47:43 erlon_: Oh you are saying we could get into a state where the volume is actually smaller than Cinder says. 16:48:35 Because then that is a problem. 16:48:42 sounds like a bug 16:48:43 jungleboyj, yes, if the backend does not handle that and allow the revert 16:49:04 erlon_: Then that is definitely a but. 16:49:06 *bug 16:49:15 the thing being is that for LVM, the revert operation does not shrink the size of the volume 16:49:32 Was assuming that if it reverted to a different sized volume that the size would be updated. 16:50:28 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 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 erlon_: Got it. 16:50:43 but that does not happens to other drivers, like SolidFire 16:51:09 ganso: Can you shrink a volume though? 16:51:24 no, cinder does not allow that 16:51:34 jungleboyj: oh nvm, forgot that Manila has this functionality, not Cinder 16:52:36 Im not aware of LVM limitations about extending/reverting snapshots 16:52:37 ganso: Ok, was confused for a minute. 16:53:26 So, we would have to have some sort of special case for changing the volume size in the DB? 16:53:30 s/shrinked/shrunk 16:54:36 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 s/clock/block/ 16:55:03 erlon_: That would be the two options. :-) 16:55:23 Anyone have a strong opinion on the direction to go here? 16:55:43 lol, dont need the 2. If you don't allow that to happen, dont need to set the proper size 16:56:00 Right. 16:57:32 So, it seems ok to allow the revert. 16:57:45 If I want to go back to that snapshot, I want to go to that snapshot. 16:58:00 I may be annoyed in the future when it is smaller, but then I have to remember I reverted. 16:58:04 Extend it again. 16:58:21 But, then we have a bug and we need to make sure that the size in the DB is right. 16:59:03 Anyone have a concern about fixing the bug and leaving the function? 16:59:23 jungleboyj, I don't know if there was any architectural problem related to revert to a small size 16:59:45 Ill try to talk to Tommy or if not able to understand if there would be any 16:59:47 erlon_: You willing to check into it? 16:59:55 jungleboyj, ye 16:59:57 p 17:00:07 erlon_: Ok. You may need to e-mail him. Don't see him on IRC anymore. 17:00:27 Lets start there and then discuss next week if necessary. 17:00:46 #action erlon_ To follow up with Tommy on the design choice and get back to us. 17:00:50 jungleboyj, good point Ill do that 17:00:51 And we are at time. 17:00:57 Thank you everyone! 17:01:04 Talk to you next week. 17:01:08 jungleboyj: Thanks. 17:01:12 #endmeeting