21:00:37 <notmyname> #startmeeting swift
21:00:38 <openstack> Meeting started Wed Sep 26 21:00:37 2018 UTC and is due to finish in 60 minutes.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
21:00:39 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
21:00:41 <openstack> The meeting name has been set to 'swift'
21:00:57 <notmyname> who's here for the swift team meeting?
21:01:01 <timburke> o/
21:01:12 <kota_> hello
21:01:23 <mattoliverau> o/
21:01:29 <tdasilva> hi
21:01:33 <rledisez> hi o/
21:01:42 <m_kazuhiro> o/
21:01:58 <notmyname> welcome
21:02:08 <notmyname> tdasilva: thanks for running last week's meeting
21:02:35 <tdasilva> yw
21:02:43 <notmyname> and it seems I never updated the agenda for this week's meeting, so we'll have to be spontaneous this week :-)
21:04:10 * notmyname feels like there was something to say, but then the train of thought got derailed
21:04:26 <notmyname> what do we need to bring up this week?
21:04:37 <notmyname> I've seen timburke and zaitcev working on py3 fixes
21:05:12 <kota_> nice
21:05:12 <tdasilva> one left over action item from last week was : https://review.openstack.org/#/c/447129/
21:05:13 <patchbot> patch 447129 - swift - Configure diskfile per storage policy - 20 patch sets
21:05:34 <notmyname> tdasilva: IIRC we're waiting to hear from gluster people on that
21:05:41 <mattoliverau> Did the gluster people get back to us?
21:05:49 <notmyname> is that still the case? we've got 3 +2s on it. when do we just land it? :-)
21:05:58 <tdasilva> yeah, we should be able to go ahead
21:06:04 <tdasilva> and land it
21:06:23 <kota_> :)
21:06:28 <mattoliverau> Quick someone hit the +A now :)
21:06:29 <notmyname> done!
21:06:36 <mattoliverau> \o/
21:06:46 <kota_> ¥o/
21:06:55 <notmyname> kota_: money arms :-)
21:06:57 <rledisez> \o/
21:07:13 <rledisez> i didn't had a chance to mention that:
21:07:13 <rledisez> one point about p 447129 is the naming. some people think that (replication|erasure_coding).fs is not a good naming for the default module. but maybe .xfs
21:07:14 <patchbot> https://review.openstack.org/#/c/447129/ - swift - Configure diskfile per storage policy - 20 patch sets
21:07:20 <rledisez> i guess now .fs is the good one ;)
21:07:48 <kota_> oh, it was not changed as back slash...
21:07:57 <notmyname> well, as long as we change it before we tag a release, we can still rename it
21:08:00 <mattoliverau> Lol, I was more like .df but it's fs now :p
21:08:00 <notmyname> rledisez: ^
21:08:02 <notmyname> if we want
21:08:12 <timburke> rledisez: was i right about the losf variants planning on ending with .losf?
21:08:19 <rledisez> ok, so, let's vote ? .fs / .xfs / .df / other idea?
21:08:36 <rledisez> timburke: yes, it will probably be .losf (right now we use .kv in our deployement, but it's a bad naming)
21:09:01 <timburke> notmyname: we could also rename it later anyway, and just keep the two entrypoints around pointing to the same thing
21:09:08 <rledisez> except if you find a cool name for losf :)
21:09:27 <tdasilva> i think .fs is fine
21:09:28 <timburke> mmm. yeha, i kinda understand .kv, too
21:10:09 <notmyname> #startvote should we keep .fs or change it? .fs .xfs .df other
21:10:09 <timburke> naming things is hard :-(
21:10:10 <openstack> Begin voting on: should we keep .fs or change it? Valid vote options are , fs, xfs, df, other.
21:10:11 <openstack> Vote using '#vote OPTION'. Only your last vote counts.
21:10:13 <mattoliverau> Well df was for diskfile, they could be used on none xfs (in theory).
21:10:15 <notmyname> it worked!
21:10:25 <notmyname> yeah, I don't like .df for the reasons mentioned
21:10:27 <kota_> +1 for .fs. even we assume users use xfs but it's a general purpose file system impl IIRC.
21:10:36 <rledisez> #vote fs
21:10:37 <notmyname> it's an abstraction, not the implementation
21:10:41 <tdasilva> #vote fs
21:10:45 <kota_> i.e. we could use .fs with ext4
21:10:51 <kota_> $vote fs
21:10:54 <timburke> #vote fs or xfs
21:10:54 <openstack> timburke: fs or xfs is not a valid option. Valid options are , fs, xfs, df, other.
21:10:56 <kota_> no
21:11:01 <kota_> #vote fs
21:11:01 <timburke> #vote fs
21:11:14 <rledisez> kota_: exactly, that was the purpose of .fs, to be generic enought on a POSIX filesystem. it should work *theoricaly*
21:11:18 <m_kazuhiro> #vote fs
21:11:23 <kota_> i hit a lot of money today :/
21:11:24 <mattoliverau> Good points, so fs meaning it's using a fs
21:11:48 <clayg> #vote fs
21:11:48 <notmyname> I'm seeing a consensus here :-)
21:11:50 <mattoliverau> K, sold
21:12:06 <mattoliverau> #vote fs
21:12:07 <notmyname> #endvote
21:12:08 <openstack> Voted on "should we keep .fs or change it?" Results are
21:12:09 <openstack> fs (7): rledisez, tdasilva, kota_, mattoliverau, m_kazuhiro, clayg, timburke
21:12:23 <notmyname> good news! the current +A can stay :-)
21:12:29 <notmyname> (now for just a few dozen hours in the gate)
21:12:38 <mattoliverau> Lol
21:12:53 <rledisez> thx all for the great reviews on that patch, i'm glad it's landed, next step is (maybe) LOSF itself ;)
21:12:59 <notmyname> rledisez: nice!
21:13:05 <notmyname> tdasilva: were there any other follow-ups from last week?
21:13:28 <timburke> idk that it should work on any POSIX filesystem -- do they necessarily support xattrs? what size?
21:13:49 <notmyname> tdasilva: "any filesystem you want, as long as it's xfs"
21:13:53 <timburke> (neither here nor there, i suppose)
21:14:15 <tdasilva> looking at logs
21:14:20 <kota_> shhhh :P
21:14:37 <rledisez> timburke: it's theoritical. but with the requirement on unlimited xattr, i think only XFS, JFS and ZFS are candidate (and I can't recommend JFS…)
21:15:01 <rledisez> oh, and reiserfs also
21:15:46 <notmyname> rledisez: yeah, we've got the code paths to support .meta files. it would be interesting, perhaps, to use that if we can't use xattrs in the normal write path. would have some downsides, though (eg more inodes)
21:16:25 <tdasilva> rledisez loves to hear 'more inodes' :P
21:17:03 <notmyname> tdasilva: did you find anything else?
21:17:29 <tdasilva> nope, we had a long talk on PUT+POST, but don't think there's anything new to discuss there yet
21:17:57 <notmyname> cool
21:18:04 <clayg> 😒
21:18:22 <notmyname> today I was looking at all the patches that have landed in order to see if we should to at least a minor version release
21:18:36 <clayg> new swifts are the best swifts
21:18:45 <timburke> speaking of, i'd like to thank clayg and mattoliverau for landing https://review.openstack.org/#/c/604937/
21:18:46 <patchbot> patch 604937 - swift - Allow kmip_keymaster to be configured in proxy-ser... (MERGED) - 1 patch set
21:18:58 <notmyname> there's been a lot of patches that have landed (git shortlog -ne 2.19.0.. | wc -l  -> 116), but I don't think there's anything *critical*
21:19:35 <notmyname> the one timburke just mentioned is good, as is the KEEPIDLE patch. and maybe the '-' in etags one. but those are the only 3 that would make any material difference to users
21:19:49 <notmyname> all the others were py3 and tests and some other misc cleanups
21:20:18 <notmyname> so I do not think we should tag a release upstream right now.
21:21:07 <notmyname> #topic open discussion
21:21:17 <notmyname> anything else to bring up or questions to ask?
21:21:45 <rledisez> just one question about encryption
21:21:47 <tdasilva> notmyname: would it make sense to create a list of patches we would like to see in the next release?
21:22:05 <notmyname> tdasilva: yeah, that's normally what we do on the priority reviews page.
21:22:09 <notmyname> #link https://wiki.openstack.org/wiki/Swift/PriorityReviews
21:22:22 <rledisez> is there anything in roadmap about getting the encryption key from the user (eg: in a header during the request). then forget about the key
21:22:28 <notmyname> I need to clean that up. there are a few that have landed and a few (like PUT+POST) that have changed
21:23:00 <notmyname> rledisez: no, not from the swiftstack side of things. do you have a requirement from users on that?
21:23:43 <clayg> I like that notmyname he's a straight shooter
21:24:06 <rledisez> notmyname: no strong requests, i was just discussing about encryption with an internal user this afternoon
21:24:12 <timburke> i always find that weird -- why trust the server with your key? encrypt/decrypt client-side
21:24:24 <notmyname> rledisez: cool. let us know if it's something that we need to think about usptream
21:24:29 <notmyname> tdasilva: I know, right?!
21:24:30 <rledisez> I had to explain than a security issue in swift/keystone middleware might expose the data, even if they are encrypted
21:24:38 <timburke> like, i get that AWS lets you do it, but that doesn't seem ipso facto a good thing
21:24:53 <mattoliverau> rledisez: I remember it coming up, but in that case things like container sync would have trouble, so kept it out of scope. Unless we have a real need
21:25:40 <timburke> mattoliverau: i think what would have to happen is that you'd sync the encrypted data
21:26:08 <rledisez> mattoliverau: it depends, if the data can be transferred encrypted (eg: if it only depends on the user key, not the object name &co), it could be doable
21:26:57 <mattoliverau> Yeah, but as a put? Yeah, it would mean a change to how container sync works. So out off until or if we ever need it
21:27:49 <mattoliverau> Having the key was easier ;)
21:28:08 <timburke> *maybe* this becomes interesting if the client doesn't actually know the key? if the client provides a barbican or kmip key identifier instead, and the proxy needs to go retrieve the real key?
21:28:15 <notmyname> or change the put path to say "treat it like encrypted, but we're not giving you the key this time". IDK. lots to think about if we need to implement it
21:29:02 <notmyname> anyway, I'm going to specifically not think about it any more until rledisez tells me it's a critical user problem :-)
21:29:35 <mattoliverau> Lol
21:29:51 <rledisez> notmyname: you won't be disturbed by me in the next few month about that ;)
21:29:59 <notmyname> wonderful!
21:30:06 <notmyname> rledisez: do you have any other prereq patches for LOSF? all the ones I knew about have been merged (or marked as merged)
21:31:11 <rledisez> notmyname:  there is still one, but it's a WIP: https://review.openstack.org/#/c/561631/
21:31:12 <patchbot> patch 561631 - swift - WIP - abstract FS operations in replicator/reconst... - 2 patch sets
21:31:18 <rledisez> so, for now everything is merged
21:31:34 <notmyname> cool
21:31:43 <notmyname> anything else from anyone? kota_ m_kazuhiro are you good?
21:32:15 <timburke> oh yeah... what do people think about the approach in https://review.openstack.org/#/c/603209/ ? should i clean it up enough that tests are actually passing? or should we leave things as they are?
21:32:16 <patchbot> patch 603209 - swift - WIP: Refactor load_libc_function and _LibcWrapper - 1 patch set
21:32:17 <kota_> it's ok to me. no items to bring today from me.
21:32:41 <m_kazuhiro> I have one small patch for general task queue. And it is ready for review.
21:32:58 <kota_> timburke: oh nice. I'm interested in that one.
21:33:26 <notmyname> m_kazuhiro: can you please link it?
21:33:46 <m_kazuhiro> It is patch 601950 .
21:33:46 <patchbot> https://review.openstack.org/#/c/601950/ - swift - Enable to configure object-expirer in object-serve... - 4 patch sets
21:35:02 <notmyname> m_kazuhiro: thank you. I will add it to the priority reviews page when I clean it up today
21:35:08 <m_kazuhiro> This patch contains upgrade impact of object expirer.
21:35:13 <m_kazuhiro> notmyname: thank you!
21:35:56 <notmyname> anything else from anyone? or shall we close the meeting?
21:36:56 <notmyname> I'll take silence as a vote to end the meeting :-)
21:37:04 <notmyname> thanks for coming today, and thank you for your work on swift
21:37:07 <notmyname> #endmeeting