14:07:09 <jokke_> #startmeeting glance
14:07:10 <openstack> Meeting started Thu Sep 19 14:07:09 2019 UTC and is due to finish in 60 minutes.  The chair is jokke_. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:07:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:07:13 <openstack> The meeting name has been set to 'glance'
14:07:16 <jokke_> #topic roll-call
14:07:17 <abhishekk> o/
14:07:21 <jokke_> sorry for late start
14:07:23 <jokke_> o/
14:07:37 <rosmaita> o/
14:08:20 <jokke_> we have empty schedule so lets get started and see how much stuff wil come up
14:08:31 <jokke_> #topic release updates
14:08:47 <jokke_> glance 19.0.0b1 was tageed this week
14:08:55 <jokke_> tagged even
14:09:31 <jokke_> that was our milestone release for T3 to promote people testing specially the caching changes
14:09:40 <abhishekk> is it?
14:09:50 <jokke_> hopefully someone finds it helpful
14:10:15 <abhishekk> cool
14:10:20 <jokke_> abhishekk: yup, it was released yesterday
14:10:55 <abhishekk> have we tagged client as well?
14:12:13 <abhishekk> so, client is yet needs to be released
14:12:33 <jokke_> I hope so ... my client release patch was abandoned so I assume someone felt more important taking care of it
14:13:07 <abhishekk> I haven't seen any release patch for client
14:14:46 <jokke_> there is new 2.17.0 tag
14:15:24 <abhishekk> https://review.opendev.org/#/c/675319/
14:15:40 <abhishekk> thierry has done it
14:16:23 <jokke_> so I guess ttx looks after out release patches from now on
14:16:26 <abhishekk> rosmaita, has proposed 2nd patch on it
14:16:58 <jokke_> we'll just assume ttx knows when and what to release :P
14:17:04 <abhishekk> :D
14:18:04 <jokke_> that should be all, apart from RC time approaching quickly
14:18:13 <abhishekk> so we do need rc1 for rethinking FS and location compatibility patch
14:18:14 <jokke_> so reviews reviews reviews
14:19:46 <jokke_> #topic Open Discussion
14:19:52 <belmoreira> any change for https://review.opendev.org/#/c/671707/ to be included in Train release?
14:21:25 <rosmaita> belmoreira: i think it is fine, i just have not had time to actually test it
14:21:33 <jokke_> belmoreira: so that is good one to bring up. I have few questions about the approach/need
14:22:02 <rosmaita> jokke_: tell us more
14:22:10 <abhishekk> should it be treated as bug??
14:22:20 <jokke_> belmoreira: iirc we already delete all custom properties from the image when it gets deleted.
14:22:34 <jokke_> Yeah, why do we actually need this and why it's filed as bug?
14:23:46 <jokke_> and is there something this does that the revised (which doesn't anymore delete the id from images table) purge doesn't address
14:24:32 <rosmaita> well, all the rows other than ID, like name, etc
14:24:36 <belmoreira> in order to be completely compliant with GDPR we can't continue to have something that was deleted by a user
14:25:14 <belmoreira> and in image tables we continue to have important information allowing to track the user
14:25:37 <belmoreira> also we can't purge this table because the problem of UUID reutilization
14:26:03 <belmoreira> that's why we propose to obfuscate this information
14:27:51 <jokke_> 5cc9d999352c21d3f4b5c39d3ea9d4378ca86544 modified purge in a way that it does not delete the ID from images table anymore
14:27:54 <jokke_> that's my point
14:28:03 <jokke_> and we did backport that as well
14:28:05 <rosmaita> yes, but the owner is still in there
14:32:42 <abhishekk> so, still wonder why it is treated as bug :o
14:32:54 <rosmaita> because purge doesn't purge?
14:33:19 <abhishekk> only because it is related to ossn-0075?
14:33:24 <jokke_> but this is request for new feature because don't want to use purge
14:34:02 <abhishekk> +1
14:34:05 <rosmaita> i disagree -- the fix for ossn-0075 left some stuff around that it shouldn't have
14:34:07 <belmoreira> no... obfuscate complements purge
14:34:15 <rosmaita> so this change fixes that fix
14:34:32 <rosmaita> i don't see what the big deal is about this
14:34:44 <rosmaita> the operator wants to respect ossn-0075
14:35:00 <rosmaita> but also wants to purge the db
14:35:51 <rosmaita> but i think the key point here is that the patch was posted in july, so if this should be a feature, someone should have told belmoreira a bit sooner than this week
14:36:27 <jokke_> rosmaita: and like I said that was addressed on the patch pointed out above. _IF_ purge leaves data behind that is considered as personal data under GDPR regulations, we should fix purge, not introduce yet another command to do th job purge was supposed to do
14:37:50 <abhishekk> we should have reviewed it earlier :(, but due to lack of visibility or overload of work we missed it
14:37:59 <abhishekk> belmoreira, sorry for that
14:38:03 <jokke_> what comes problematic about that is _if_ user id is considered such personal data that cannot be stored for audit purposes under those regulation once user deletes that resource, we would need to scrape all logfiles for that as well
14:38:35 <rosmaita> well, i assume log files are purged at some point
14:38:47 <belmoreira> jokke_ we do...
14:38:47 <rosmaita> you need the userid in the logs to see who's doing stuff
14:38:58 <rosmaita> so i don't think this is a slippery slope
14:39:15 <rosmaita> but i think jokke_ has a good point that we should just put this into the 'purge' command
14:39:25 <rosmaita> then it is definitely a bug fix and not a feature
14:39:35 <abhishekk> that makes sense
14:39:53 <jokke_> and all it needs to touch if that is the owner uuid
14:39:59 <rosmaita> so a "regular" purge will obfuscate the images table but not delete anything
14:40:26 <abhishekk> so no need of purge_images_table as well?
14:40:38 <jokke_> rosmaita: not from the images table, it will still clean the rest of the tables
14:40:58 <belmoreira> in my opinion will be less confusing if we have it as a different action
14:41:09 <jokke_> abhishekk: that is still needed for those who don't care about the OSSN-0075 and wants to just wipe everything
14:41:31 <abhishekk> ack
14:41:37 <rosmaita> right, we still have regular purge and dangerous purge
14:41:54 <abhishekk> haha
14:41:55 <rosmaita> but why not obfuscate all columns?
14:42:27 <jokke_> yeah, the point of splitting those two were that purge can be used for clienup while still making sure the uuid won't be reused
14:42:29 <belmoreira> ops already rely in the purge feature (purging images or not) and changing that behaviour is always problematic
14:43:09 <abhishekk> we can add flag to existing purge command to toggle for obfuscate or purge??
14:43:18 <rosmaita> belmoreira: well, it wouldn't really change, it will purge all tables except 'images' and will obfuscate all deleted rows in images table
14:43:37 <rosmaita> i don't know if we need a flag, when you purge, your intention is to delete everything
14:43:40 <jokke_> abhishekk: that doesn't change anything about it being just yet another command to do the job
14:43:47 <rosmaita> we have to keep the uuid around because of ossn-0075
14:43:59 <abhishekk> yep
14:44:12 <jokke_> so my question really is is there reason to keep the obfuscated data in the db?
14:44:17 <belmoreira> but can we make sure that is the bahaviour that small/private clouds would like to have?
14:44:45 <belmoreira> jokke_ ossn-0075
14:44:46 <jokke_> which turns to a question, why don't you purge instead as that doesn't expose the security issue
14:45:25 <belmoreira> jokke_ now i'm lost
14:45:26 <jokke_> belmoreira: my point exactly. purge as of how it works atm. does not expose the system to OSSN-0075
14:46:05 <rosmaita> yes, but it leaves the 'owner' (at least) in the images table in deleted rows taht are not removed
14:46:11 <rosmaita> i am missing your point, i think
14:46:11 <belmoreira> but leaves the "owner" i nthe images table
14:46:51 <jokke_> and my point is, is there any reason it should if it's a problem having it there?
14:47:40 <jokke_> as in is there any reason why purge shouldn't just remove the owner uuid from the record and we don't need obfuscate
14:47:58 <rosmaita> ok, now i understand
14:48:23 <rosmaita> you are arguing "no 'obfuscate' commmand" you are not arguing "no obfuscation"
14:48:28 <rosmaita> philosophical difference
14:48:35 <rosmaita> (the use/mention distinction)
14:50:05 <jokke_> yes, so I'm not expert by any means on GDPR, I do not know if storing uuid of the user is considered as personal information and we should worry in the first place. If it is, then we should just whack it out with purge which does not open ossn-0075 anymore
14:51:03 <rosmaita> i agree with jokke_ , though i would say let's just reset all the deleted rows to default values (except for the id) so we never have to worry again
14:51:03 <belmoreira> as operator I prefer to run small/descriptive commands. In that case purge is not purge anymore
14:51:54 <rosmaita> belmoreira: well, it effectively purges the images table
14:52:15 <jokke_> it purges everything _but_ the images table
14:52:28 <abhishekk> we have 8 minutes left
14:52:53 <rosmaita> yeah, that's what i meant by "effectively" -- it's a functional purge because the data is gone, but the rows are still there
14:53:26 <belmoreira> this means that we remove the 2 level purge, right?
14:53:30 <rosmaita> but, we should probably listen to the only operator in the room! :)
14:53:57 <rosmaita> no, we'd still have to have the "dangerous" purge for people who really want to clean out the db and don't care about ossn-0075
14:54:22 <belmoreira> right
14:54:48 <rosmaita> so the change erno is suggesting is that we just automatically do obfuscation as part of the "regular" purge process
14:54:59 <rosmaita> then you don't need an extra command
14:55:00 <belmoreira> I'm fine with that...
14:55:12 <rosmaita> i think it is a cleaner solution
14:55:19 <jokke_> So outside of preference of usage. Lets talk about how we need to prioritize this. If we want to introduce obfuscation feature as it's proposed now, it's really not a bug, lets get lite spec for it and schedule it for U, if we just need to whack owner on current purge as it doesn't meet privacy requirements, I'm fine getting that in as bugfix and even backporting it as far as the OSSN-0075
14:55:25 <jokke_> migitation patch was backported
14:55:44 <rosmaita> i agree, on bugfix
14:55:50 <abhishekk> so we can include that in rc1
14:56:12 <rosmaita> but i still wonder about the other values, i think just reset them to the defaults and then this will never come up again
14:56:29 <jokke_> what other values
14:56:40 <rosmaita> checksum, visibility, etc
14:56:53 <belmoreira> rosmaita +1
14:57:05 <rosmaita> just reset everything except the image id
14:57:49 <abhishekk> fine by me as well
14:58:05 <jokke_> well none of them are personal information, so definitely not GDPR consideration. Which is what has been causing my confusion of this proposal in the first place
14:58:38 <jokke_> as it was based on GDPR issue, but it was touching stuff all over the place
14:58:40 <abhishekk> last 2 minutes to agree on
14:59:04 <rosmaita> i don't see the problem with just resetting it all
14:59:10 <rosmaita> but that's just me
14:59:13 <abhishekk> Note: are we going to host next meeting?
14:59:15 <rosmaita> (and belmoreira and abhishekk)
14:59:21 <jokke_> good point
14:59:25 <jokke_> No meeting next week
14:59:43 <abhishekk> ack
14:59:55 <rosmaita> hey, this is not specifically related to belmoreira's patch, but jokke_ and abhishekk should look at this: https://review.opendev.org/#/c/671707/3/glance/db/sqlalchemy/api.py@1469
15:00:06 <jokke_> kk
15:00:09 <rosmaita> it is bound to bite us in the butt eventually
15:00:25 <jokke_> will be on #os-glance if there is still something, we're out of meeting time
15:00:30 <jokke_> Thanks all!
15:00:32 <rosmaita> bye
15:00:34 <jokke_> #endmeeting