19:01:56 <notmyname> #startmeeting swift
19:01:57 <openstack> Meeting started Wed Jun 12 19:01:56 2013 UTC.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:58 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:02:00 <openstack> The meeting name has been set to 'swift'
19:02:12 <notmyname> welcome all. agenda (or topics) for today are on https://wiki.openstack.org/wiki/Meetings/Swift
19:02:40 <davidhadas> agenda is a plus for future meetings also :)
19:02:46 <notmyname> first up, reminder about the hong kong summit
19:02:55 <notmyname> hong kong summit
19:02:56 <notmyname> nov 5-8: http://www.openstack.org/summit/openstack-summit-hong-kong-2013/
19:02:56 <notmyname> us visa: http://hongkong.usconsulate.gov/acs_hkvisa.html
19:03:09 <notmyname> get your passport and visa ready if you haven't yet
19:03:21 <gareth_kun> welcome
19:03:29 <notmyname> #info get travel arrangements ready for the HK summit
19:03:43 <creiht> "They must have a U.S. passport valid for at least six months"
19:03:45 <creiht> interesting
19:04:03 <notmyname> also, I believe hotel blocks open up this week (according to an email sent last week), so that stuff is coming up soon too
19:04:04 <creiht> oh I guess that means doesn't expire within 6 months
19:04:16 <notmyname> creiht: I think that's common to most international travel
19:04:22 <davidhadas> creiht: standard procedure - same for pepole going to the US
19:04:23 <chmouel> yep
19:04:23 <shri> when is the call for papers?
19:04:44 <creiht> notmyname: yeah my first thought was that it had to have been valid for 6 months
19:05:00 <notmyname> shri: not sure on the conference side. the summit (tech) side will be much closer to the event
19:05:08 <notmyname> shri: normally about a month out
19:05:12 * creiht needs to figure out if he would like to visit anywhere else in china
19:05:18 <davidhadas> creiht: you need to be at least 6 month old also
19:05:27 <notmyname> creiht: let me answer that for you: yes
19:05:27 <creiht> davidhadas: hehe
19:05:54 <notmyname> ok, next release
19:05:57 <notmyname> #topic next release
19:06:06 <notmyname> we had a bunch of good patches merged yesterday
19:06:39 <notmyname> torgomatic is working on a affinity on writes patch right now. that's the last major part of global clusters, and once that lands I'd like to do a release
19:06:52 <notmyname> it's been a while, and we've had lots of other stuff land too
19:06:56 <davidhadas> notmyname: how about trying to get account acls in before next release?
19:07:15 <davidhadas> its in the oven...
19:07:22 <torgomatic> for certain values of "right now", at least. Actual right now, I'm here in a meeting. ;)
19:07:23 <notmyname> that's my next question: what else needs to land? any other outstanding patches that are in gerrit now?
19:07:31 <davidhadas> all infrustructure is there now that we merged get_info
19:07:37 <creiht> notmyname: should we give some time with an RC before we release so that those region features can be tested fairly well before release?
19:08:06 <notmyname> creiht: yes, to some extent. we're testing it as we go with a global clsuter we have
19:08:25 <creiht> notmyname: I imagine dfg would like to get his slo of slos patch in
19:08:31 <creiht> but he has been on vacation
19:08:31 <notmyname> ya
19:08:39 <creiht> he should be back soonish
19:08:43 <notmyname> I'd like to have the final patches land next week and then do a release on June 27
19:08:52 <notmyname> that's 2 weeks from tomorrow
19:09:06 <creiht> that seems reasonable
19:09:13 <davidhadas> notmyname: a bit pressed fro acount acls - I assume it would take 2 weeks to score
19:09:45 <davidhadas> So few more days would be great
19:09:58 <davidhadas> If we get it great - if not, next time
19:10:20 <notmyname> davidhadas: when do you expect to submit it?
19:10:25 <creiht> davidhadas: I imagine there will be room for more releases before Havana
19:10:39 <notmyname> yes, there will be
19:10:56 <davidhadas> I will try to send first version before weekend - working now on tests and need to close one or two items
19:11:11 <notmyname> ok, great
19:11:21 * portante working towards getting series of patches for DiskFile refactoring into the release following June 27th
19:11:34 <davidhadas> Lets target adding it in
19:11:39 <notmyname> the next release will be 1.9
19:12:07 <notmyname> I don't think 1.8.1 is appropriate, but I'm willing to hear arguments
19:12:18 <portante> agreed
19:12:20 <davidhadas> sounds sexy to me
19:12:30 <notmyname> davidhadas: that's what we're going for ;-)
19:12:47 <creiht> notmyname: no 2.0? :)
19:13:07 <notmyname> not yet :-)
19:13:16 <davidhadas> creiht: lets do the 2.* inline with an openstack release
19:13:30 <creiht> global clusters seems like a big enough feature to bump to 2.0
19:13:42 <creiht> not sure if there will be a feature more important than that in a while
19:13:51 <davidhadas> but I have no idea if after 1.9 its 2.0 or 1.a or 1.10
19:13:51 <creiht> unless we are going to do like 1.10 1.11 etc
19:14:04 <notmyname> I'm fine with 1.10, 1.11, etc
19:14:11 <torgomatic> that's the nice thing about integers: there are so many of them
19:14:13 <creiht> notmyname: what would constitute 2.0?
19:14:15 <portante> perhaps save 2.0 bump to API changes?
19:14:25 <notmyname> creiht: not sure yet, but I'd tend to agree with portante
19:14:32 <creiht> meh
19:14:34 <creiht> :)
19:14:34 <notmyname> breaking changes
19:14:39 <portante> yes
19:14:55 <creiht> well nothing would break because you would still have backwards compat :)
19:15:02 <notmyname> we've got some other stuff planned that may constitute a more major version bump :-)
19:15:14 <portante> do tell?
19:15:19 <notmyname> not yet :-)
19:15:24 <creiht> notmyname: meh
19:15:25 <portante> ;0
19:15:25 <creiht> :)
19:15:30 <notmyname> let's move on though, to other topics for today
19:15:44 <creiht> notmyname: if it is that super awesome, then it can be 3.0 :)
19:15:49 <notmyname> #info next release targeted as 1.9 for June 27
19:16:03 <davidhadas> Am I still connected - last message I see is from 22:12
19:16:06 <notmyname> creiht: it's teh awesomz!!11!!!
19:16:22 <notmyname> davidhadas: looks like lag
19:16:27 <notmyname> #topic API specs
19:16:35 <notmyname> https://wiki.openstack.org/wiki/Swift/API
19:16:39 <torgomatic> davidhadas: I see your message, though if you're not seeing mine, I don't know how much good this reply will do
19:16:54 <notmyname> I've added some stuff to the API wiki page
19:17:10 <notmyname> mostly comments based on when things were implemented
19:18:02 <notmyname> I'd love more feedback on the wiki page
19:18:06 <portante> did we arrive at a decision for how to gauge what is in or out?
19:18:20 <davidhadas_> I got disconnected
19:18:24 <portante> from the last meeting, I thought notmyname was considering options
19:18:57 <davidhadas_> What is the current topic?
19:19:08 <portante> API specs
19:19:08 <notmyname> portante: ya, but I didn't hear from anyone :-)
19:19:08 <notmyname> I'm becoming convinced that we realy just need a decision to be made
19:19:20 <notmyname> like "everything in folsom or essex is v1.0"
19:19:28 <torgomatic> if only we had some kind of leader to make that decision ;)
19:19:32 <portante> ;0
19:19:33 <notmyname> hmm ;-)
19:19:45 <creiht> that could make a good decision?
19:19:46 <creiht> ;)
19:19:59 * portante ow!
19:20:05 <notmyname> I'll put together a more formal proposal around that and send it to the mailing list
19:20:08 <notmyname> creiht: ouch!
19:20:14 <creiht> I kid I kid :)
19:20:24 <davidhadas_> lets call clay and vote
19:20:47 <clayg> api v1.0 is so 3 years ago
19:21:00 <notmyname> #action notmyname to make a formal proposal to the mailing list with decisions made as to what's in and out
19:21:26 <notmyname> ok, next topic
19:21:36 <notmyname> #topic internal API changes
19:21:36 <notmyname> How backwards compatible do we need to be with internal (i.e. non-user-facing) interfaces? This question was inspired by https://review.openstack.org/22820, which changes the format of a data structure in the WSGI environment that other middlewares may use, though none in the Swift codebase do.
19:21:49 <notmyname> who proposed that item? ^
19:21:53 <torgomatic> o/
19:21:57 <gareth_kun> that's my issue
19:22:09 <torgomatic> I'm just trying to get a sense of what people feel is important to have compatibility on
19:22:15 <torgomatic> obviously, the client API must not change
19:22:38 <torgomatic> and obviously, if I rename a method in swift.common.utils or something, that's okay
19:22:53 <portante> but isn't that talking about on disk data?
19:23:02 <davidhadas_> torgomatic: its just the same since someone may use it
19:23:14 <portante> acls stored in metadata on disk
19:23:25 * clayg snikers at "obviously" when coming from the 204->200 point the clients at the spec guy
19:23:33 <notmyname> we can't not change anything because somebody somewhere may change it
19:23:34 <creiht> lol
19:23:39 <davidhadas_> we simply cant have such restrictions assuming we want to grow and prosper
19:23:40 <gareth_kun> torgomatic: is that a good way to change something and have release notes for next release?
19:23:47 <torgomatic> portante: the on-disk ACLs aren't the contentious part there; it was the changes to the WSGI environment
19:23:57 <torgomatic> so, just curious what people usually care about
19:24:11 <torgomatic> portante: the on-disk ACLs are backwards-compatible in that change
19:24:13 <creiht> in the past, we have chosen to keep things for backwards compatibility with a deprecation warning
19:24:20 <creiht> and then take it out in a future version
19:24:34 <clayg> gah, that review is huge - do I need to understand that issue to under the current topic?
19:24:41 <davidhadas_> any version should support growing from previous one(s) with whatever is on disk
19:24:58 <davidhadas_> But I am not sure if one or ones and how many ones
19:25:00 <creiht> we've always had upgrade in place as well
19:25:06 <creiht> if it is a data format issue
19:25:17 <torgomatic> clayg: the issue is: an earlier version of that patch changed the value of env['keystone.identity'] that the middleware was emitting (leaking?)
19:25:19 <notmyname> upgrade plans are important (eg ring formats, pickle->json)
19:25:23 * portante wonders if there is a good summary somewhere about that discussion
19:26:07 <clayg> torgomatic: yeah but so that's the same thing as changing a method name in utils right?
19:26:08 <creiht> One does not simply run an upgrade script on a swift cluster :)
19:26:30 <torgomatic> clayg: seemed that way to me, but chmouel disagreed
19:26:35 <torgomatic> hence this discussion :)
19:26:42 <portante> clayg: not so sure, because a filter can be written and used outside of the make swift code base
19:26:45 <clayg> chmouel: wtf?
19:26:54 <creiht> if there are data changes that are cluster wides, the updates *must* happen in place
19:26:59 <notmyname> heh
19:26:59 <portante> that is why we are working on the DiskFile refactoring
19:27:06 <torgomatic> creiht: definitely
19:27:09 <clayg> portante: yeah middleware that's not in core is tough to keep up with master
19:27:47 <creiht> I think we should still keep backwords compatible functions that are depricated for a release or two so that outside utilities can catch up
19:28:00 <clayg> portante: but I mean this is way not as bad as something like swob, or the fact that our memcche client gripes about a deprecated kwarg "timeout"
19:28:13 <davidhadas_> We should have defined APIs - e.g. the auth API is a good example which we agree to not change (only extend - unless we do a major release for example 2.0)
19:28:14 <chmouel> clayg: heu i'm talking about the middleware
19:28:15 <notmyname> portante: but isn't the difference witht he DiskFile stuff that it is introducing a new API that is relatively stable (ie we agree to to change it). no such agreement is there with env vars
19:28:19 <chmouel> the api that middleware is based on
19:28:21 <chmouel> and get into the chain
19:28:28 <chmouel> not swift.common.utils and such
19:29:02 <creiht> notmyname: I think that there is still an implicit agreement to try to play well together
19:29:10 <notmyname> of course
19:29:13 <portante> notmyname: yes, but, as an example, gluster today has to track the code changes made to make sure we are not broken by any code change assumptions
19:29:14 <davidhadas_> But ethe rest... there is no difference between what's in mmcache, whats in environment and whats in the runtime as for function names, parameters etc
19:29:42 <portante> the external-middleware models will have to do the same, and to verify one did not miss anything is a real pain
19:30:01 * portante shouts up from the whole we dug
19:30:21 <davidhadas_> portante: so the DiskFile should fix that hopefully as we are making it an official API that will not change unless we declare ands warn of that change etc.
19:30:31 <portante> agreed
19:30:55 <portante> so we have to be careful to define clearly what external filters can expect for their API
19:31:12 <clayg> heh, well it's not even going to be "official official" - it just reduces the surface area a bit
19:31:13 * portante look another API definition popping up there too
19:31:31 <davidhadas_> So as far as I can see there are only two levels - either an official API - in which case we proactivly make sure we can change before we change or at least pre-warn, and all the rest where we continue as usual and try to be fair
19:31:33 <clayg> like if you "reach around" the abstraction you're prolly gunna get bent
19:31:37 <davidhadas_> but not prevent progress
19:31:45 <portante> clayg: true
19:32:19 <notmyname> so the issue on this one is the keystone.identity env var. seems that the var is already "scoped" by name to be keystone. I can't imagine that eg swiftstack auth should require keystone's data structure to not change
19:32:25 <creiht> yeah the internal api thing scares me a bit
19:32:48 <creiht> I don't want to hamper innovation inside of swift
19:32:56 <clayg> davidhadas_: well having a good abstraction that's more or less stable *accelerates* progress, and not just disk file, if we renamed "get_logger" or "readconf" we'd break a bunch of stuff
19:33:04 <creiht> for example, what if we decide to rewrite the object server in C to get better io?
19:33:14 <creiht> that api abstraction totally goes away
19:33:29 <portante> I would have to review the discussions, more but can somebody tell report on what existing middleware might get burned by the keystone.* wsgi change?
19:33:34 <creiht> It would seem more important to define the REST api between the services first
19:33:36 <clayg> creiht: yeah but we already have a loose internal api that allows that
19:33:41 <davidhadas_> clayg: agreed. But whatever we decide to fixate  - we need to think about it before we fixate it and than say it out load
19:33:42 <notmyname> creiht: not it's "external" one. ya, that
19:33:43 <clayg> heh yeah
19:33:59 <creiht> like define what the object server REST api is
19:34:01 <torgomatic> I dunno, I like the Linux kernel model: syscalls Shall Not Change(tm), and if an internal API gets changed, all callers get updated by the changer
19:34:14 <notmyname> creiht: isn't that what' portante is doing with LFS? :-)
19:34:25 <torgomatic> if you're maintaining a driver outside of the kernel, it's up to you to keep up with internal API changes
19:34:26 <notmyname> torgomatic: but that's only for stuff in the kernel right?
19:34:30 * portante hopes he is doing that
19:34:48 <creiht> notmyname: I'm not entirely sure... I was under the impression that it was an internal api from a code perspective
19:34:57 <creiht> but then again I'm only going by what I hear you guys talk about
19:35:27 <portante> creiht: it will end being external once we get more than one backend implemented that is available to the community
19:35:32 <portante> end up
19:35:45 <creiht> portante: ok, I guess I need to look at it closer then
19:36:00 <davidhadas_> Lets create a wiki page where we define what we preceive as an external API that extensions can rely to not change without prewarning
19:36:14 <clayg> I think we're pretty loose on "defined" api's (previous topic was, yeah we should have one for the *public client api*) - i'm not sure what we're going to decide here
19:36:17 <portante> creiht: thanks, that would be great
19:36:32 <notmyname> perhaps "internal" vs "external" is confusing? an API s external, but it doesn't mean it's available to an end user
19:36:37 <clayg> ... except maybe - yes continue to try and not break stuff other poeople are probably using
19:36:40 <notmyname> it's all perspective
19:36:52 <torgomatic> basically, I want to know what sorts of non-client-breaking changes are likely to piss off other Swift devs if they get approved
19:36:53 <portante> notmyname: true
19:37:20 <creiht> portante: of course my list of things to look at is ever increasing :/
19:37:28 <davidhadas_> torgomatic: so lets document that
19:37:28 <clayg> torgomatic: easy, the one that's make some other swift dev have to change their code
19:37:31 <notmyname> torgomatic: so how do we answer that?
19:37:58 <torgomatic> notmyname: well, I was hoping to do that with a quick straw poll here, just to get a feel for things
19:38:23 <portante> torgomatic: go for it
19:38:48 <torgomatic> sure
19:39:17 <portante> torgomatic: can you frame it succinctly?
19:39:23 <portante> the straw poll that is?
19:39:30 <torgomatic> so, who here gets annoyed when things change in the WSGI environment? how about utility functions? other stuff?
19:39:30 <creiht> straw man poll?
19:39:37 <clayg> torgomatic: but it's impossible even your lowest bar "and obviously, if I rename a method in swift.common.utils or something, that's okay" is *NOT* ok - you can't change the name of get_logger
19:39:49 <creiht> lol
19:40:07 <clayg> is there *anything* else you can think of that we could *ALL* agree is totally safe to change?
19:40:27 <notmyname> does all this come down to "don't break things we know people are using and have good release ntoes"?
19:40:36 <chmouel> notmyname: +1
19:40:43 <creiht> I think it is a lot like how we have handled api things
19:40:48 <creiht> additive is fine
19:40:55 <torgomatic> notmyname: sure, could be
19:40:56 <notmyname> and it may be that we don't know what people are using until a review
19:40:59 <creiht> if you are going to radically change something, then we need some extra care
19:41:01 <litong> @notmyname, a product in my view should only insist on the confirmation of the external API
19:41:15 <litong> anything developed based on internal methods are at risk anyway.
19:41:23 <notmyname> creiht: agreed, but realizing that we can be a litle more free with non-client things
19:41:26 <portante> but is middleware internal methods?
19:41:27 <clayg> I think chmouel has to defined why he thinks the wsgi environ is scared or a similar +2 is likely to come up
19:41:29 <litong> there is no one there to ensure it will be always there like that.
19:41:39 <clayg> it's not obvious to me why that would be consumed by anyone except the guy setting it
19:41:51 <chmouel> clayg: I'd say whatever other middleware which is non core would use
19:41:51 <notmyname> portante: IMO, yes. middleware is an implementation detail not a definition of "optional"
19:41:52 <litong> we should not define that many APIs, it will be a big problem down the road for a product.
19:42:00 <creiht> notmyname: sure, I just expect a "best effort" at making sure we don't make changes that are likely to break things
19:42:10 <notmyname> I agree
19:42:20 <torgomatic> alright
19:42:22 <notmyname> torgomatic: what else would you like to see?
19:42:22 <creiht> and that goes for those that review the changes as well
19:42:23 <chmouel> creiht: good for me
19:42:23 <notmyname> ok
19:42:29 <torgomatic> notmyname: I'm done
19:42:29 <portante> but we allow other folks to write middleware and use with core, right?
19:42:31 * davidhadas_ volnteers to try and create a list
19:42:42 * portante willing to be done
19:42:44 <davidhadas_> with typos!
19:42:54 <notmyname> #agreed don't make changes that are likely to break things
19:42:55 <notmyname> :-)
19:42:57 <clayg> portante: I've done that with many a middleware sure
19:43:05 <creiht> lol
19:43:18 <notmyname> #topic DiskFile status
19:43:25 <notmyname> portante: can you give a 3 minute summart?
19:43:25 <creiht> I think we have been fairly reasonable so far... there have been a couple of misses, but I think we have learned from them
19:43:28 <davidhadas_> notmyname: you skipped some items
19:43:28 <notmyname> sumary?
19:43:34 <portante> yes
19:43:35 <davidhadas_> in the agenda
19:43:37 <notmyname> davidhadas_: I'm not going in order
19:43:44 <portante> working through test case failures
19:44:03 <clayg> chmouel: so this was a *real* breaking change between the keystone-client middleware and the keystone-auth middleware in swift?
19:44:08 <notmyname> davidhadas_: (I want enough time to discuss yours, so a quick DiskFile overview should work)
19:44:18 <portante> stumbled on quarantine semantics of when an object gets quarantined
19:44:30 <clayg> chmouel: like ours was getting changed to look for a variable somewhere that the upstream middleware wasn't putting it?
19:44:30 <portante> based on refactoring of the APIs
19:44:45 <portante> working to propose that topic separately
19:44:46 <chmouel> clayg: which one are you talking about the review about the ACL ?
19:44:57 <portante> working on refactoring the reader code like the writer
19:44:59 <notmyname> chmouel: clayg: cna you discuss in #openstack-swift?
19:45:15 <notmyname> portante: is that your next patch?
19:45:17 <gareth_kun> clayg: breaking users who use env['keystone.identity'] defined in swifft, not keystone headers
19:45:42 <portante> next patch will likely be the quarantine refactoring
19:45:48 <portante> then reader done like writer
19:46:10 <portante> then API definition (this is private, this is public, this is reference implmemetation kinda stuff)
19:46:25 <notmyname> ok
19:46:40 <portante> would love input on quarantine issue from someone willing to listen on the problem
19:46:46 <portante> that is the status for DiskFile
19:46:53 <notmyname> portante: ok thanks
19:47:09 <notmyname> let's discuss quarantine issues in IRC or in a review
19:47:17 <notmyname> IRC=#openstack-swift
19:47:20 <portante> great
19:47:34 <notmyname> #topic path control
19:47:39 <notmyname> Path Control: Create an open interface to control the path used by Swift within devices (where within the device a/c/o/tmp/qurentined/async are placed).
19:47:39 <notmyname> Make sure any code approaching the device go via a central function (e.g. storage_directory() in utils) allowing monkey patching it or offering other ways to extend it
19:47:39 <notmyname> While we do it , we can extend storage_directory() to also append the basedir and device since this seem to be required by all its users.
19:47:46 <notmyname> I'm not sure really what this is? davidhadas_?
19:48:06 <davidhadas> I wanted to hear your views on this one
19:48:48 <portante> this feels like it will end up being related to the "backend" in use one we get the DiskFile refactoring, and DatabaseBroker refactoring, in place
19:48:51 <notmyname> have a single function in utils that determines where stuff lives on disk? seems reasonable. maybe even something good to have in DiskFile itself
19:48:54 <davidhadas> first , si getting all swift code handling the path to go via a central place  - we can use this for ring doubling where we want to control the path
19:49:07 <portante> notmyname: agreed
19:49:23 <notmyname> davidhadas_: what's your concern?
19:49:48 <davidhadas> second I want te the path control function to be made external API such that installations can decide to change it at will
19:49:58 <portante> Essentially, when one looks at the three servers, there is an "understood" way of dealing with things on disk unites DatabaseBroker classes and DiskFile
19:50:03 <davidhadas> If this is ok with everyone I have no concerns
19:50:16 <creiht> davidhadas: can you share a use case to help us understand it better?
19:50:41 <portante> *that unites
19:50:46 <notmyname> davidhadas: it sounds like something reasonable to be in DiskFile (eg portante doesn't want to name things the same way on disk in gluster)
19:51:39 <portante> notmyname: or even for XFS today, where we would want to use a different path for tempfiles that take advantage of XFS allocation groups behaviors
19:51:42 <davidhadas> 1. Disk doubling. 2. I can do SAIO with multiple swift regionss on one with this 3. We may decide to use a special path for containers and trat it with more cache based on that path
19:52:07 <notmyname> creiht: I've got a hypothetical use case of having different storage policies using different top-level directories (objects/ and objects-reduced-redundancy/ and etc)
19:52:15 <portante> davidhadas: can't that be done today with device paths and mount_check = False?
19:52:17 <davidhadas> 3 is kind of hardware and system specific - but different pepole may have their own
19:52:56 <portante> This feels very much tied to backends for DiskFile
19:52:59 <davidhadas> portante: No - this allows chnaging the path on the fly as well
19:53:04 <portante> but when wearing bear glasses ...
19:53:13 <creiht> I guess I was more cuious why you would change it on the fly?
19:53:26 * portante echos creiht
19:53:42 <davidhadas> portante: it is related to backends - I think it is a different issue from DiskFile  - BUt I also think it it can be combined to a threesome with DiskFIle and DB
19:54:32 <davidhadas> creiht: it asallows for exampel to create two swift domains in one - as you know we are into domains
19:54:34 <davidhadas> :)
19:54:39 <portante> a backend implementation might allow for this, but not sure changing specifically to get flexibility for the current implementation is the right way to go
19:54:48 <davidhadas> Different domains for example may have different QoS
19:55:00 <creiht> I guess it is difficult for me to visualize this without seeing some code
19:55:01 <portante> that most likely can be done with device paths, no?
19:55:14 <notmyname> davidhadas: I'd like to see the way things are stored more abstracted. eg what if my storage doesn't use directories? in that way, this proposal seems to be most appropriate under something like DiskFile rather than a sibline to it
19:55:30 <notmyname> sibling
19:55:53 <torgomatic> creiht: I am in the same boat with you
19:56:11 <davidhadas> notmyname: I cant see that, but I am ok with having this combined as long as I am not forced to implement a DiskFile simply to control the path
19:56:33 <notmyname> davidhadas: a DiskFile that allows you to control the path? ;-)
19:56:34 <portante> davidhadas: one should be able to subclass an implementation
19:56:50 <davidhadas> portante: sure np
19:57:10 <portante> gluster is doing that for the current implementation
19:57:30 <portante> we just tweak a few things and reuse the reader
19:57:31 <notmyname> davidhadas: does all that sound ok to you? questions answered?
19:57:47 <davidhadas> yes
19:57:51 <notmyname> great
19:57:57 <notmyname> thanks for bringing it up
19:58:26 <notmyname> reminder: next meeting is in 2 weeks, get your passport ready if you are going to HK, release tentatively on June 27
19:58:31 <notmyname> thanks for your time
19:58:33 <notmyname> have a great day
19:58:36 <notmyname> #endmeetign
19:58:38 <notmyname> #endmeeting