<div dir="ltr">Hi Ellie<div><br></div><div>I think you got most of it.</div><div><br></div><div>The object storage implementation was built on top of the "archive_enabled" feature.  Both must be enable for the object storage to kick in.  Or in other words it is only when a file (email) must be archive that it will go into object storage.</div><div><br></div><div>You can enable this with the following in Imap.conf<br></div><div><br></div><div><div><div>archive_enabled: yes<br></div><div>archive_days: 0  (this will make sure that all emails will go strait into archive,  and if object storage is enable it will go into object storage instead)</div></div><div><br></div><div>object_storage_enabled: yes</div><div>object_storage_dummy_spool: /var/objectstore</div><div><br></div></div><div>You can check functionality by cross checking files in the object_storage_dummy_spool and information in the user database </div><div><br></div><div>sqlite3 message.db  (message.db is the database created in each user directory in the spool directory.)</div><div>sqlite> SELECT * FROM user_msg;  (will dump the information)<br></div><div><br></div><div><span style="background-color:rgb(255,255,0)">54d78bfa187279fad2fa93356f0546dbcfd9b6ab</span>|{"mboxs":{"uid":<span style="background-color:rgb(255,0,0)">user.ray.MyStuff.toto.abc</span>.<span style="background-color:rgb(0,255,0)">1</span>}}<br></div><div><br></div><div>-in yellow is the message GUID (used as file name in the all object storage implementations)</div><div>-In red is where the file should be if not in object storage.<br></div><div>-In greed is what the file name should be if not in object storage. </div><div><br></div><div>Note: you can have many "uid:" tags for one message_guid  if the same email is in multiple mailboxes.  (Since the delayed deletion and rename of mailboxes imply copying all emails and removing old ones, this is a huge gain in performance in object storage solution, as it eliminate all file movement. It only add and remove tags in the database)</div><div>----------------<br></div><div><br></div><div>There was many reason for this supplied dummy solution.</div><div>1- All object storage solution are not easy to setup.  The dummy solution is there to make sure someone can test easily the functionality.</div><div>2- I am not a fan of #ifdef.  The alternative was to supply "dummy" functions calls for the code to compile.  (if object_storage_enabled is not defined in Imapd.conf this code is simply not used.)<br></div><div>3-This solution is also super lite compare to object storage deployment.<br></div><div>4-It is also a guide to measure performance of the different implementations.</div><div><br></div><div>I may have time in a few weeks to test your changes if you can wait.  If not you can contact Jean-Francois at OpenIo to help test the OpenIo solution. He can probably help document the missing dependencies at the same time.  (At the moment of development of the object storage solution, OpenIo was in the middle of eliminating dependencies, so the long list of dependencies was getting shorter)</div><div><br></div><div>Important to say that OpenIo have a real test going on now.  Hopefully they should be able to tell us more about that soon.</div><div><br></div><div>As for Caringo it is a bit more complicate.  Caringo is not an open source solution.  Therefore the SDK is not public.  You need an account to get it. </div><div><br></div><div>Finally I plead guilty for the Sqlite dependency.  Sorry for that and thanks for fixing this.   </div><div>As you find out the alternative was to include --enable-httpd, (It is using small portion of code added by Ken for httpd ; the opening/creation of the database with version support.;  The version support is mandatory if we need to change the database format one day)</div><div><br></div><div>Thanks<br></div><div>Raymond</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-11-06 2:44 GMT-05:00 ellie timoney via Cyrus-devel <span dir="ltr"><<a href="mailto:cyrus-devel@lists.andrew.cmu.edu" target="_blank">cyrus-devel@lists.andrew.cmu.edu</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">At present, our master branch unconditionally builds in the object<br>
storage functionality (using the objectstore_dummy implementation).<br>
There's a few ways this isn't great:<br>
<br>
* it has an undocumented dependency on lib/sqldb, but doesn't try to<br>
link it in, so the build fails unless you --enable-httpd, which is<br>
currently the only thing that tries to link in lib/sqldb.  (This is<br>
what's causing the HarborMaster build failures, fwiw.)<br>
* it brings in a bunch of experimental code with no way to compile that<br>
out<br>
* there's some configure settings for dealing with it, but they don't<br>
interact well together<br>
<br>
I had a chat with Ken and Nicola today, and have put together some<br>
changes, with the following goals:<br>
<br>
* as light a touch as reasonable<br>
* add an --enable-objectstore configure option (default: no) to control<br>
whether objectstore code is built at all<br>
* keep the existing --with-openio[...] and --with-caringo options for<br>
selecting the backend<br>
* ditch the --enable-dummy_objstore option altogether<br>
* use the dummy implementation only if objectstore is enabled but<br>
neither backend has been selected<br>
<br>
The changes are on the "v30/optional-objectstore" branch on my github,<br>
for now:<br>
<a href="https://github.com/elliefm/cyrus-imapd/tree/v30/optional-objectstore" rel="noreferrer" target="_blank">https://github.com/elliefm/cyrus-imapd/tree/v30/optional-objectstore</a><br>
<br>
This isn't on master yet cause there's some caveats:<br>
<br>
The implementation necessitates a bunch of "#ifdef ENABLE_OBJECTSTORE"<br>
around the code paths that use it (imap/append.c and imap/mailbox.c).  I<br>
don't much care for this -- it makes maintenance and testing down the<br>
track fiddly.  But the alternatives seem to be the current state, which<br>
we already know is broken, or adding a no-op objectstore implementation.<br>
 The latter seems pretty nasty from the way we use this: there's lots of<br>
code like "if the option is set in imapd.conf, do it the objectstore<br>
way, otherwise, do it the normal way".  If we were to just drop in a<br>
no-op objectstore implementation then cyrus admins would be only a<br>
config setting away from data loss, and that feels all kinds of wrong.<br>
So, #ifdefs.<br>
<br>
The dummy implementation is not a no-op implementation, it's a flat<br>
file-based emulation.  "Dummy" is possibly a misleading name here, by<br>
which I mean, it mislead me until I read the code.  Maybe we should<br>
rename it, but for now: light touch.<br>
<br>
The caringo/openio detection code is pretty frail and needs attention.<br>
For example, if you --with-caringo=yes without having the dependencies<br>
installed, it just happily adds the dependencies straight into<br>
LDFLAGS(!)... which makes subsequent unrelated checks that try to<br>
compile a code fragment fail unexpectedly.  The openio path has the good<br>
grace to fail clumsily on its own when the dependencies are missing,<br>
though it is just as guilty of blatting into stuff it shouldn't touch.<br>
<br>
The --enable-objectstore option still has the undocumented dependency on<br>
--enable-http (in order to bring in lib/sqldb).  Light touch.  I'll end<br>
up fixing this at some point anyway if no-one else does first, because<br>
the backup code I'm working on has a similar dependency.<br>
<br>
I'm not sure about the terminology here -- "object store" / "object<br>
storage" / various capitalisations / without spaces.  I've just made<br>
some wild guesses for now.  If you have an opinion, tell me about it.<br>
<br>
The imapd.conf setting for enabling object storage is always present,<br>
whether the feature is compiled in or not.  There's a fair bit of work<br>
in making this not the case (changing the scripts that generate<br>
lib/imapopts.[ch] and man/imapd.conf.5 from lib/imapoptions).  And we<br>
already have other settings that are nonsensical unless optional<br>
features are compiled in, so there's precedent in just leaving it as is<br>
-- at least for now. Light touch.<br>
<br>
And for all that, I don't have the dependencies for either Caringo or<br>
OpenIO handy, so I haven't tested those code paths beyond verifying that<br>
it fails as expected when I try to enable them.  I've tried not to alter<br>
what was already there, but I can't verify that I haven't accidentally<br>
broken something somehow.  If you've been able to get either of these<br>
actually working, I'd appreciate if you could try again with my branch<br>
and let me know if it still works.  It does pass our tests without<br>
objectstore, and with the dummy objectstore implementation.<br>
<br>
So, those sure are some caveats hey.<br>
<br>
I think the main questions at this point are:<br>
<br>
* are we happy with the combination of --enable-objectstore to turn the<br>
feature on, plus --with-[backend] to select a backend, and default to<br>
dummy if no other backend was selected?<br>
* are we happy/comfortable/resigned to the #ifdef'd approach to<br>
compiling it out?<br>
* did I manage to avoid breaking anything that used to work?<br>
<br>
If those are yes, then I'll merge it onto master, and the rest can be<br>
figured out as we go.<br>
<br>
Cheers,<br>
<br>
ellie<br>
</blockquote></div><br></div></div>