Wednesday, 2019-10-16

*** gyee has quit IRC00:45
*** nanzha has joined #openstack-swift01:21
*** spsurya has joined #openstack-swift01:59
*** baojg has quit IRC02:11
*** zaitcev has quit IRC02:50
*** psachin has joined #openstack-swift04:02
openstackgerritMerged openstack/swift master: py38: Provide readinto() interface for RingReader  https://review.opendev.org/68859104:03
openstackgerritMerged openstack/swift master: swift-account-audit: clean up some error formatting  https://review.opendev.org/68852904:03
*** baojg has joined #openstack-swift04:27
*** pcaruana has joined #openstack-swift04:37
openstackgerritTim Burke proposed openstack/swift stable/train: CHANGELOG for 2.23.1  https://review.opendev.org/68884804:52
*** tkajinam has quit IRC05:04
*** pcaruana has quit IRC05:14
*** hoonetorg has quit IRC05:35
*** tkajinam has joined #openstack-swift05:42
*** hoonetorg has joined #openstack-swift05:48
*** pcaruana has joined #openstack-swift06:13
*** nanzha has quit IRC06:34
*** nanzha has joined #openstack-swift06:43
ktsuyuzakihello06:46
ktsuyuzakioops, my nick was changed...06:46
*** ktsuyuzaki is now known as kota_06:46
kota_ok06:46
*** takamatsu has joined #openstack-swift07:08
*** tesseract has joined #openstack-swift07:12
*** tesseract has quit IRC07:14
openstackgerritMerged openstack/swift master: tests: Stop invoking python just to get the real source directory  https://review.opendev.org/68882607:14
*** tesseract has joined #openstack-swift07:14
*** e0ne has joined #openstack-swift07:19
*** rdejoux has joined #openstack-swift07:29
*** rpittau|afk is now known as rpittau08:12
*** tkajinam has quit IRC08:16
*** takamatsu has quit IRC08:21
*** takamatsu has joined #openstack-swift08:36
*** nanzha has quit IRC08:40
*** nanzha has joined #openstack-swift08:43
openstackgerritOpenStack Proposal Bot proposed openstack/swift master: Imported Translations from Zanata  https://review.opendev.org/68888309:02
*** nanzha has quit IRC09:14
*** nanzha has joined #openstack-swift09:21
*** rcernin has quit IRC09:54
*** NM has joined #openstack-swift10:41
*** NM has quit IRC10:59
*** rcernin has joined #openstack-swift11:30
*** nanzha has quit IRC11:55
*** tomha has joined #openstack-swift12:50
*** tomha has quit IRC12:53
openstackgerritAlexandre Lécuyer proposed openstack/swift feature/losf: EC frags are the ones with the #  https://review.opendev.org/68684613:00
openstackgerritAlexandre Lécuyer proposed openstack/swift feature/losf: In _get_vfile(), handle the case when a referenced object has been punched  https://review.opendev.org/65925413:06
*** NM has joined #openstack-swift13:13
ormandjis there any support for immutability? i didn't see any in docs, but figured i'd ask13:21
ormandj(WORM support)13:22
*** NM has quit IRC13:24
rledisezormandj: it's currently not possible in Swift. The eventually consistent model of Swift makes it really difficult to implement13:24
ormandjfair enough, thank you for the direct answer13:25
*** NM has joined #openstack-swift13:25
rledisezormandj: what are you trying to achieve. do you need immutability like you need guarantee. because if your looking to publish an object, you can play with ACL or tempurl so only you can write, and "others" can read13:28
ormandjimmutability, so there is no way possible to tamper with data after write as defined by policy13:28
ormandjto include the original writer (in this case, it would be software)13:29
rledisezormandj: ok, so it's what I was saying, not possible13:29
ormandjwe had looked at ACLs as an option but hadn't found a way to make it happen. this is unfortunate, as it is becoming more and more required by certain types of customers13:30
ormandjthank you again for the info13:30
tdasilvaormandj: would versioning help?13:30
ormandjtdasilva: as long as old versions cannot be deleted :) a typical scenario would be ransomware concerns13:30
ormandjbackups are no good if the software creating them is on a compromised machine and the backups can be mutated, for example13:31
ormandjSEC/FINRA requires this kind of functionality13:31
tdasilvaormandj: would your users be able to modify the container metadata itself or just be given write/read acls to it?13:35
tdasilvaormandj: checkout https://github.com/openstack/swift/blob/master/test/functional/test_versioned_writes.py#L508 maybe something like that could help13:35
ormandjwell, in this case, let's say you have backup software X. X would need write access to actually commit the backup to the object store13:35
ormandjwould there by any way to restrict X to write only, with no ability to delete/mutate/etc?13:36
ormandj(looking through that test file now)13:37
ormandjhm - is the idea you'd create a versions container that X software would have no access to, then create a container that it would have access to but no permissions to update version container location/feature, then as writes happen they end up being written to both the container as well as the second versions container13:40
ormandjso X could delete from the original container it was uploaded to, but not the versions container?13:40
tdasilvaCorrect, but while using history mode. New writes or deletes just cause new writes into versions container.13:42
ormandjdoes the data physically exist in two containers? ie: storage consumption is doubled?13:44
ormandjand if the original container is deleted, does the data persist in the versions container?13:44
ormandj(thanks for all of the help, as always)13:45
*** rcernin has quit IRC13:57
tdasilvaormandj: data is not duplicated. latest version is stored on versioned (primary) container while older versions are on versions (secondary) container14:07
tdasilvaif using history mode, if object is deleted, we actually store a delete marker14:08
tdasilvaand keep the object in the versions container14:08
ormandjhm, ok14:22
ormandjif you delete the primary container, does the data persist in secondary?14:23
ormandji'm assuming so based on your description - we'll just test all this - thanks for all the tips14:26
tdasilvaormandj: yes, you would have to delete each container separately14:29
tdasilvaand to delete the primary container, you would need to issue a delete to all objects in that container first, which would ensure the data is moved to the versions container14:29
tdasilvaormandj: Now here comes the curve ball....having said all that, we are currently working on a new version of object versioning and I just realized we don't have such "functionality" in this new version. so I'm writing that down as something we need to look into14:31
ormandjhah, well, look into the SEC/FINRA requirements, amazon implements this as 'object lock'14:45
ormandjif you can cover those bases while implementing your versioning14:45
ormandjyou'd remove a barrier for a lot of clients14:45
ormandjhttps://aws.amazon.com/blogs/storage/protecting-data-with-amazon-s3-object-lock/14:48
tdasilvayeah, I saw the aws 'object lock' feature and that looked very interesting. It does however put as back into the issue of eventual consistency within swift14:48
ormandjyeah14:49
ormandjbut even with eventual consistency, if you enforce the WORM model, i'm not fully clear on how that causes a problem14:49
ormandj1) create container with policy in place that disallows any data mutation/deletes, only new commits 2) ?14:50
tdasilvaheh, number 1 is the real challenge14:52
ormandjcouldn't the existing ACL stuff just be updated to support a new restriction that disallows any of the operations that would mutate/delete/etc data?14:53
tdasilvaswift could write data in any handoff device14:53
tdasilvaormandj: but a write can be used as a "delete"14:53
ormandjcan't the ACL system be updated to prevent that? or perhaps i'm missing something.14:56
ormandjor is the eventual consistency thing you are describing the whole PUT to replace not actually checking when you submit the PUT if the object already exists14:58
ormandjthus no ACL check can be done at that point that would block the PUT?14:58
tdasilvaexactly, a PUT has no way of checking if something already exists14:58
tdasilvaand being 100% certain14:59
ormandjmaybe add a policy that can be applied to containers that turns on a consistency model for this?15:00
ormandjthat'd be nice to have for other reasons, too15:12
ormandji suppose there's some performance implications there with blocking processes (aside from the obvious performance hit with it enabled)15:14
*** NM has quit IRC15:22
openstackgerritMerged openstack/swift feature/losf: EC frags are the ones with the #  https://review.opendev.org/68684615:25
*** gyee has joined #openstack-swift15:28
*** diablo_rojo has joined #openstack-swift15:48
*** rdejoux has quit IRC15:57
*** NM has joined #openstack-swift15:59
*** tesseract has quit IRC16:08
*** diablo_rojo has quit IRC16:20
*** diablo_rojo has joined #openstack-swift16:20
*** psachin has quit IRC16:29
*** NM has quit IRC16:29
rledisezormandj: timburke: would it be acceptable to have an "eventually immutable" possibility? i imagine setting a metadata on object that flag it immutable, then during replication, if the flag is set on an older version, the new version is cleaned up instead of the older16:34
tdasilvarledisez, ormandj sorry for not getting back, just been dealing with multiple things today. anyway, i think a feature like 'object lock' would require either changes in swift in how we write to handoffs or change in the backend of where we write swift data to. for example we could have a storage policy with 1 replica and the backing "device" be a strong consistent layer that is doing replication16:37
tdasilvathe fact that aws require object-lock to be turned on to new buckets only makes me thing they are in a similar situation16:38
tdasilvabasically requires a new storage policy16:38
timburkerledisez, interesting idea... i think it'd have to be set on the initial PUT -- but what about when all old "immutable" replicas are unavailable and a new "immutable" write comes in? presumably we'd go out to handoffs, but how should replication resolve it? no matter what we do, we're going to end up removing data that was PUT with the "immutable" flag and for which we sent back a 201...16:43
rlediseztimburke: i would say the older wins (opposite of current policy)16:47
rledisezit could event be a different policy with different diskfile with reverted replication  behavior (keep older timestramp)16:47
rledisezbut i guess there would be many corner cases16:48
*** rpittau is now known as rpittau|afk16:50
*** e0ne has quit IRC17:01
*** baojg has quit IRC17:02
rlediseztimburke: just so you know, at OVH we regularly get this request of "immutable" object17:07
timburkei'm sure17:10
*** NM has joined #openstack-swift17:12
*** spsurya has quit IRC17:58
*** NM has quit IRC17:59
*** NM has joined #openstack-swift18:05
*** e0ne has joined #openstack-swift18:18
ormandjyeah, it's a huge need for certain industries, unfortunately it's a hard problem with a non-consistent backing store hah18:22
*** diablo_rojo has quit IRC18:32
*** diablo_rojo has joined #openstack-swift18:35
*** e0ne has quit IRC18:57
*** NM has quit IRC18:58
openstackgerritTim Burke proposed openstack/swift master: WIP: Allow internal clients to use null namespace  https://review.opendev.org/68213818:58
*** NM has joined #openstack-swift19:10
*** NM has quit IRC19:47
*** NM has joined #openstack-swift19:50
*** rdejoux has joined #openstack-swift20:03
*** pcaruana has quit IRC20:28
*** NM has quit IRC20:28
*** NM has joined #openstack-swift20:32
claygso... I need to bounce 😞20:54
claygbut for the meeting... I'd guess @timburke and @tdasilva will be able to say whatever neeeds to be said for versioning20:55
claygif there's a review I'm putting off please ping a few at me and I'll be sure to put in some time20:55
claygya'll have a good afternood20:55
kota_morning20:57
timburkekota_! glad you're doing ok -- family and everyone ok, too?21:00
kota_timburke: sure. thx!21:00
*** ormandj has quit IRC21:09
*** ormandj has joined #openstack-swift21:10
*** NM has quit IRC21:27
tdasilvaforgot to mention, if anyone has a chance, it would be good to present swift at fosdem again next year: https://lists.fosdem.org/pipermail/fosdem/2019q4/002891.html21:46
tdasilvaalecuyer, rledisez, cschwede ^^^21:46
tdasilvaunfortunately i won't be able to make it this itme21:47
alecuyertdasilva:  thanks for the heads-up! we could try with romain, maybe talk about versioning and other things you are all working on21:49
timburketdasilva, oh wow... i hadn't realized how much larger the py3 docker image is compared to the py2 one... funny21:51
timburkestill way smaller than what i made for myself for keystone and barbican, though; those were like 165-180MB21:52
*** diablo_rojo has quit IRC23:10
*** gyee has quit IRC23:16
*** tkajinam has joined #openstack-swift23:31
*** diablo_rojo has joined #openstack-swift23:45

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!