Open Stack

He's a simple example to (hopefully) make it clear:

$ cd /srv/node/vdc/quarantined/containers/3a7b4bae41a17d0f54b247c727b4f0cd

$ ls -l

total 20
-rw------- 1 swift swift 18432 Aug 15  2016 
3a7b4bae41a17d0f54b247c727b4f0cd.db

$ sudo swift-container-info ./3a7b4bae41a17d0f54b247c727b4f0cd.db
Traceback (most recent call last):
   File "/usr/bin/swift-container-info", line 32, in <module>
     print_info('container', *args, **vars(options))
   File "/usr/lib/python2.7/dist-packages/swift/cli/info.py", line 327, 
in print_info
     info = broker.get_info()
   File "/usr/lib/python2.7/dist-packages/swift/container/backend.py", 
line 501, in get_info
     with self.get() as conn:
   File "/usr/lib/python2.7/contextlib.py", line 17, in __enter__
     return self.gen.next()
   File "/usr/lib/python2.7/dist-packages/swift/common/db.py", line 366, 
in get
     self.possibly_quarantine(*sys.exc_info())
   File "/usr/lib/python2.7/dist-packages/swift/common/db.py", line 347, 
in possibly_quarantine
     renamer(self.db_dir, quar_path, fsync=False)
   File "/usr/lib/python2.7/dist-packages/swift/common/utils.py", line 
1094, in renamer
     os.rename(old, new)
OSError: [Errno 16] Device or resource busy


On 15/06/17 14:06, Mark Kirkwood wrote:
> Thanks for the explanation Clay!
>
>
> As to why, well suppose you have a quarantined container...and want to 
> see where it thinks it should be. - you'll call swift-container-info 
> on it right? That calls get_info - so will attempt to re-quarantine 
> the file...which is unexpected - and scary (it will try to move away 
> the directory too)! Also means you can't get the metadata as the 
> script bails before printing it.
>
> regards
>
> Mark
>
>
> On 15/06/17 13:55, Clay Gerrard wrote:
>> Pretty sure that's true and mostly optimistic on the part of the db 
>> replicator which is more in the data path for replication - than say 
>> rsync object replication.
>>
>> If you look at ssync or ec reconstructor you'll see it's quite 
>> possible for them to trip built in DiskFile quarantine behavior 
>> during replication as well!
>>
>> I wouldn't say it's "by design" but we've never been shy to 
>> quarantine anytime we encounter invalid data - the storage wsgi 
>> servers can quarantine for example - if you happen to hit the right 
>> object at the right time.
>>
>> Why?  ;)
>>
>> -Clay
>>
>> On Wed, Jun 14, 2017 at 6:16 PM Mark Kirkwood 
>> <mark.kirkwood at catalyst.net.nz 
>> <mailto:mark.kirkwood at catalyst.net.nz>> wrote:
>>
>>     This was highlighted to me recently, and after doing some
>>     experiments it
>>     seems that the 'job descriptions' for replicators vs auditors is
>>     different for objects vs containers (and probably accounts).
>>
>>     For objects:
>>
>>     - replicator will move objects to where they should go
>>
>>     - auditor will check validity + quarantine as required
>>
>>
>>     For containers (and possibly accounts - haven't checked but code 
>> looks
>>     similar)
>>
>>     - replicator will move objects to where they should go and check
>>     validity + quarantine as required
>>
>>     - auditor will check validity and quarantine as required
>>
>>
>>     This looks a bit like the container replicator is treading on the
>>     auditors toes - is this intended and/or am I missing something?
>>
>>
>>     In terms of *why* this happens, it seems to be due to:
>>
>>     - ContainerBroker.get_info using a self.get which resolves to
>>     DatabaseBroker.get
>>
>>     - DatabaseBroker.get calls self.possibly_quarantine
>>
>>     So anywhere that these brokers call 'get_info' results in a 
>> potential
>>     quarantine...this *looks* like it might be accidental function
>>     creepage
>>     - thoughts?
>>
>>     (This code analysis done on Mitaka/2.7.0)
>>
>>
>>     regards
>>
>>     Mark
>>
>>
>>
>>     _______________________________________________
>>     Mailing list:
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>     Post to     : openstack at lists.openstack.org
>>     <mailto:openstack at lists.openstack.org>
>>     Unsubscribe :
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
>>
>
>
> _______________________________________________
> Mailing list: 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
> Post to     : openstack at lists.openstack.org
> Unsubscribe : 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack