19:01:01 <notmyname> #startmeeting swift
19:01:02 <openstack> Meeting started Wed May 15 19:01:01 2013 UTC.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:06 <openstack> The meeting name has been set to 'swift'
19:01:15 <notmyname> welcome to the swift meeting
19:01:18 <notmyname> thanks for coming
19:01:22 <creiht> may this be a swift meeting
19:01:27 <portante> oy
19:01:44 <notmyname> two major topics I want to cover today
19:01:48 <notmyname> 1) swift API
19:01:56 <notmyname> 2) portante want's to talk about LFS
19:02:10 <notmyname> then we can have open discussion, if necessary
19:02:15 <notmyname> #topic Swift API
19:02:29 <notmyname> https://wiki.openstack.org/wiki/Swift/API
19:02:53 <notmyname> the goal for this is to define what the swift v1.0 is
19:03:22 <notmyname> with the goal of having a) a stating point for vx.y and b) testing if all these other systems that are coming out really support swift
19:03:32 <notmyname> so there are notes on that wiki now
19:03:53 <notmyname> and I'd like to have it finalize by the next meeting (ie 2 weeks from now)
19:03:54 <davidhadas> Can you elaborate on the list of middlewar?
19:04:04 <davidhadas> e
19:04:10 <portante> and what does the "-" mean?
19:04:20 <notmyname> - means NA
19:04:35 <notmyname> ie that piece of middleware doesn't define an external API
19:04:37 <torgomatic> dash indicates non-user-facing middleware, so the question of "is it part of the API" does not apply
19:05:03 <notmyname> I want to be very clear that middleware does _not_ equal optional functionality. it's a particular way to implement features
19:05:40 <notmyname> and I think we should have the v1.0 API as a very low bar for all existing clusters and future clusters to meet
19:06:10 <notmyname> ie, what's the smallest useful subset of swift functionality that we can define that doesn't exclude existing clusters today, but defines enough to mean something
19:06:36 <notmyname> later, we can have 1.1 or 2.0 or whatever, and I hope those (in addition to fixing things) will include more functionality
19:06:52 <davidhadas> notmyname: so if its a way to implement functionality - than defining a middleware as "no" means it is not part of swift in 1.0?
19:07:19 <notmyname> davidhadas: it means that the functionality it defines isn't part of the 1.0 spec
19:07:29 <portante> does having a v1.1 or v2.0 API mean that the URL will change then?
19:07:29 <notmyname> similar to the features listed below
19:07:45 <notmyname> portante: the version string in the path? yes, I'd think so
19:08:08 <davidhadas> notmyname: so whats the benefit of taking important functions out?
19:08:22 <zaitcev> I see that OPTIONS is supported while CORS is not. What good is OPTIONS by itself?
19:08:29 <portante> In cases where auth is used, the storage urls are discovered
19:08:33 <davidhadas> it just leads to client claiming to be 'compliant' when theyt have missing functions
19:08:40 <notmyname> davidhadas: to make sure that existing clusters that have installed "Swift" can still be called swift
19:09:20 <notmyname> davidhadas: eg we can't define staticweb as part of the spec in such a way that Rackspace cloud files can no longer be called swift because they use a CDN for public access
19:09:43 <davidhadas> notmyname: here is my problem - I am fine with clusters implementing minimal function as needed - I am less fine with clients not supporting middleware
19:10:03 <davidhadas> Otherwise we are going to have an impossible eco system
19:10:04 <portante> davidhadas: what do you mean?
19:10:16 <portante> not supporting middleware?
19:10:44 <davidhadas> portante: if you define a stripped off API than you will have missing functions also in clients
19:10:47 <portante> that a client breaks because we define a middleware package to be part of the API?
19:10:50 <chmouel> i.e: not adding slo to swiftclient?
19:11:15 <creiht> why does the api define what you can call swift?
19:11:42 <notmyname> creiht: because there is no other way to do any sort of validation of it
19:11:43 <zaitcev> Why is missing fuctions in clients a problem at all? Duplicity does not support tempauth, fine. Because it makes no sense to support tempauth in Duplicity!
19:11:45 <davidhadas> Maybe 'compliant'  clients should support a fuller set of options - and can detect what the cluster actually support with OPTIONS
19:11:46 <creiht> why can't there be "optional" parts of api?
19:12:14 <creiht> notmyname: those seem to be orthoginal
19:12:32 <creiht> you define a set of api that swift *does* and *can* support
19:13:03 <creiht> you define a separate set of tests to define what designates a "swift" installation which *may* include api requirements
19:13:20 <notmyname> creiht: sure, I think there could be optional parts. but one way to do that is to talk about a 1.0 feature set and a 2.0 feature set
19:13:33 <cschwede> creiht: i like that idea
19:13:47 <davidhadas> creiht: so in order for an option to be supported you need it supported in both service and client  - which means there will be a many different things called swift outthere which standartization suppose to remove
19:14:15 <notmyname> davidhadas: clients will end up supporting whatever the api is when the client is written
19:14:53 <davidhadas> notmyname: right - so this is why I am suggesting to not define all the middleware (or most) as outside of 1.0
19:15:10 <notmyname> creiht: we can't test an installation beyond api compliance
19:15:14 <davidhadas> since than they will not be supported by most
19:15:30 <portante> It seems like what clients end up actually using is orthoginal to a service offers
19:15:35 <creiht> and why is this our worry?
19:15:43 <davidhadas> part of the Swift power is in the eco system it creates and clients play that part
19:16:01 <creiht> I'm concerned about the api spec being muddied by compliance
19:16:15 <portante> creiht: can you say more?
19:16:17 <notmyname> creiht: compliance is derived from a spec, not the other way around
19:16:39 <portante> creiht: what do you mean by muddied?
19:16:42 <davidhadas> We can have API 1.0 inclusive and indicate that some of the API is optional to the server but not the client
19:16:48 <torgomatic> look, if I'm writing a client and I need to use e.g. formpost's functionality, I need to know if that functionality is part of Swift's core API or not
19:16:53 <notmyname> davidhadas: I agree. my thought has been to keep 1.0 limited because we never started with a spec. we're only defining it after the fact here
19:16:54 <torgomatic> if it's core, I'm just going to assume it's there and use it
19:17:02 <torgomatic> if it's not core, I have to check and see if it's there
19:17:30 <torgomatic> in either case, I'm gonna write the client, but the included-in-API-ness of formpost affects how careful I have to be
19:17:38 <torgomatic> so in that sense, having a defined list is really helpful
19:17:39 <davidhadas> torgomatic: so as a client you may be requried to support it bu checking if this option is enabled
19:18:05 <torgomatic> davidhadas: yes. and that's fine by me. I just need to know if it's functionality that's always there or if I have to check for it
19:18:07 <notmyname> the other concern I have is now that other storage systems are starting to claim "Swift api" support, we have no way to say if they are or aren't. and if a large company "supports swift" but breaks things or doesn't implement things, we suffer with no recourse
19:18:45 <notmyname> davidhadas: torgomatic: similar to browser support for features
19:18:50 <portante> so does the functional test suite go a long way to help define that compliance?
19:18:51 * creiht has a laggy connection
19:18:57 <cschwede> notmyname: are there any plans implementing a client which is able to verify if a cluster is api-compliant?
19:19:02 <notmyname> portante: I think so, yes
19:19:22 <portante> we at red hat storage are planning on using it that way
19:19:28 <ogelbukh> is it correct to say that 'yes' middlewares are in pipeline in default config file
19:19:30 <creiht> notmyname: I could care less about htat... we also say we have an S3 api, but there is no compliance that determines that
19:19:31 <portante> it being the functional test suite
19:19:35 <ogelbukh> and 'no' middlewares are not?
19:19:36 <zaitcev> Okay, I think I see what David is trying to say. However, it would really be helpful if he had 1 specific example. For example: all 1.0 clients are to use markers to list directories.
19:19:41 <notmyname> cschwede: yes. the functional tests are a good start, but not sufficient. a separate test suite is important, and I've had some interest from people to write it
19:19:50 <creiht> I'm worried we are going to get too far in the weeds if we worry about compliance
19:19:51 <notmyname> cschwede: but it will be a community effort
19:19:56 <creiht> we define the api
19:19:56 <davidhadas> cschwede: formal certification can definatly be a way to go
19:19:59 <creiht> it is what it is
19:20:10 <torgomatic> ogelbukh: that'd probably be a good thing to do, but right now it's not the case
19:20:31 <creiht> compliance can be worried about in another discussion, and is more of a board/TC issue then what we decide
19:20:38 <creiht> who decides openstack compliance?
19:20:44 <notmyname> ogelbukh: sort of, but that gets back as middleware as an implementation detail as opposed to a feature set
19:20:45 <ogelbukh> torgomatic: that's how i understand that client need to check if specific call is supported in particular deployment )
19:21:08 <notmyname> creiht: we set the api for swift, so ultimately it's us
19:21:11 <ogelbukh> notmyname: ok, got it
19:21:12 <portante> creiht: you mean to say that we define what the Swift API is, but we don't have to define how an implementation becomes compliant to it?
19:21:30 <portante> or is compliant to it?
19:21:50 <creiht> I'm just saying that they are totally different discussions
19:21:53 <davidhadas> portante: lets not go there  - not now :)
19:21:56 <notmyname> the openstack foundation enforces the openstack trademark. as such, they want to be able to test for api compliance
19:21:58 <creiht> an API is an API
19:22:15 <creiht> no decision of the API spec should be driven by any notion of compliance
19:22:28 <portante> creiht: agreed
19:22:40 <notmyname> compliance derives from the API. agreed that it comes later. the important thing is setting 1.0 right now
19:22:41 <creiht> and middleware currently is absolutely optional currently
19:22:43 <portante> it does not seem that notmyname is saying that
19:22:45 <davidhadas> I agree with creiht that wether we do compliance or not is a different Q
19:22:57 <davidhadas> We nee dtoi discuss what is the content of the API first
19:22:58 <creiht> otherwise we should have a static pipeline that auto-includes all the middleware
19:22:59 <portante> I think we are all in agreement
19:23:15 <creiht> we are talking about API then, why is complaince even coming up then?
19:23:25 <davidhadas> creiht: optional is fine for the server side - lets not make it optional for client side also
19:23:38 <davidhadas> ( at least not all of it before considering each one)
19:23:39 <notmyname> creiht: because as soon as we define an API, you have something to measure cloud files against
19:23:52 <creiht> api definition has nothing to do with defining how the client uses it
19:23:57 * creiht sighs
19:24:28 <cschwede> what about including data security? ie 'a swift cluster is required to have at least X copies of every object'?
19:24:46 <notmyname> cschwede: I'd be opposed to that
19:24:59 <creiht> I think this API stuff has goteen way too far in the weeds for me anyways
19:25:02 <creiht> do what you will
19:25:04 <dfg> we could jest make it 1 :)
19:25:05 <torgomatic> cschwede: I wouldn't. API definitions are just about what the client can see, and the client can't see replicas
19:25:06 <dfg> just
19:25:10 <creiht> I gotta run unfortunately
19:25:27 <portante> creiht: perhaps worth have a further discussion another time then
19:25:41 <notmyname> so, I'd like us to be able to vote on the api wiki page by next meeting
19:25:49 <portante> it seems like notmyname and creiht actually are agreeing, but I could be wrong
19:26:02 <swifterdarrell> I got the impression they weren't?
19:26:07 * swifterdarrell shrugs
19:26:10 <creiht> should we define how we specify the api on the wiki so that we can make sure we certify it as an API? :)
19:26:10 <notmyname> portante: on the api part, yes :-)
19:26:13 <swifterdarrell> hard to tell ;)
19:26:19 <creiht> lol
19:26:34 * portante can't we all just get along
19:26:47 <shri> do we have examples of any middleware is not optional? If we're saying it is just a diff way of implementing, do we have two ways of doing something but one of them HAS to be in the pipeline?
19:26:49 <cschwede> that's correct, but if i offer an something like "swift compliant cluster" I would expect a replicated cluster. Otherwise being API compliant can mean everything in the backend?
19:27:04 <notmyname> cschwede: true
19:27:13 <notmyname> #link https://wiki.openstack.org/wiki/Swift/API
19:27:13 <portante> yes, and I think we want that
19:27:16 <creiht> the fact that we are still discussiing compliance shows that notmyname and myself do not agreed
19:27:20 * creiht is now out
19:27:26 <notmyname> portante: "we" == red hat ;-)
19:28:02 <cschwede> ok
19:28:17 <portante> yes, red hat wants the back end to not be defined by the API
19:28:23 <portante> how replication is handled, etc.
19:28:46 <portante> how many copies, level of robustness, etc. we would not want specified in the API
19:28:50 <torgomatic> well, an API (IMHO) is a series of requests that I can make and responses that I can expect to receive
19:28:55 <ogelbukh> shri: healthcheck middleware, for example - if it's not there, the cluster is not API 1.0
19:28:56 <davidhadas> Lets agree on what is 1.0 and if exludes as much as possible or includes whats need to be supported by clinets - I think the latter + defining what is optional and how a client knows that it is optional
19:29:00 <torgomatic> s/series/set/
19:29:01 <portante> the API should just be about how to interface to it
19:29:03 <notmyname> shri: I'd argue that large objects should be part of the API, and at least static large objects are defined in middleware
19:29:19 <portante> torgomatic: agreed
19:29:34 <torgomatic> so I don't care if my data is stored on 3 separate disks, erasure-coded, chucked into memory, or written on basalt tablets by a room full of stonecarvers
19:29:47 <cschwede> portante: that's ok for me, but i think we should add a note to the doc stating that this doesn't say anything about the backend implementation
19:29:49 * portante loud room
19:29:57 <notmyname> so right now we have the API docs that are sort of a mishmash of most things that swift's codebase can do
19:30:15 <notmyname> cschwede: anyone can edit ;-)
19:30:51 <cschwede> notmyname: :)
19:31:10 <notmyname> so it seems that perhaps the wiki page should be restructured slightly to avoid the "middleware" question
19:31:18 <notmyname> and be for function-oriented
19:31:22 <notmyname> anyone disagree?
19:31:35 * lpabon aye!
19:31:37 <shri> If there aren't too many, why not move mandatory middlewares into core and make it part of the API? The others remain as they are
19:31:56 <lpabon> i mean, i agree, not disagree
19:31:58 <notmyname> shri: middleware is an implementation detail
19:32:03 <notmyname> ok
19:32:11 <davidhadas_> notmyname: definatly function
19:32:15 <notmyname> #task reorganize the api wiki to be more function-oriented
19:32:31 <notmyname> #action reorganize the api wiki to be more function-oriented
19:32:35 <notmyname> that's it
19:32:47 <cschwede> shri: depending on whom you ask there might be a lot of different mandatory middlewares
19:33:13 <shri> notmyname, cschwede: I see
19:33:33 <davidhadas_> notmyname: and can we define it from the perspective of the client rather than the server?
19:33:53 <notmyname> davidhadas_: yes, I think that's the end result (as torgomatic pointed out)
19:34:31 <notmyname> we can all edit the wiki, so please do so and we'll get it into shape in the next two weeks
19:34:36 <notmyname> next topic
19:34:45 <notmyname> #topic internal API (LFS)
19:34:53 <notmyname> portante wanted to talk about this
19:34:56 <portante> I posted a blue print: https://blueprints.launchpad.net/swift/+spec/diskfile-databasebroker-as-apis
19:34:57 <notmyname> portante: the floow is yours
19:35:39 <portante> zaitcev talked about the LFS patch at summit, and what came out of that was two levels of effort:
19:36:09 <portante> the first level being closer to what the original LFS patch is about, a proxy server internal layer that defines what controllers to use
19:36:14 <portante> all in the proxy
19:36:46 <portante> but if I understood all the discussion at summit, there was a groundswell of interest in defining a second layer of internal APIs for use
19:37:05 * notmyname likes that second part
19:37:11 <portante> They exist mostly already, but they are not agreed upon as an API
19:37:22 <notmyname> portante: so what are you looking for as a next step?
19:37:33 <portante> Today the are encoded as the DiskFile class in swift/obj/server.py,
19:37:34 <notmyname> zaitcev: lpabon: ^^
19:38:02 <portante> and swift/common/db.py DatabaseBroker class for account and container
19:38:11 <zaitcev> I figured that the "first level" seems too ambitious. We are already using what portante is talking about, just informally. And this "VFS for Swift" is going to take like a year or something.
19:38:27 <zaitcev> you can see the size of it here https://github.com/zaitcev/swift-lfs
19:38:45 <notmyname> zaitcev: got a compare link?
19:39:09 <zaitcev> You mean, a patch like  git diff origin master?
19:39:26 <portante> today, the gluster-swift integration monkey patches the DiskFile class with its own, and replaces the _get_broker(sp?) method for container and account to replace the database broker class
19:39:38 <notmyname> portante: zaitcev: my understanding is that you want a formal declaration like "DiskFile and DBBroker are stable" or something like that?
19:39:57 <portante> yes, and that the mechanism for substituting is acceptable
19:40:10 <zaitcev> Something like that but more realistic than that, I would think
19:40:26 <zaitcev> Like a promise to be considerate when inevitable change rolls in.
19:40:33 <notmyname> :-)
19:41:06 <portante> for example, instead of having _get_broker() method, define it to return a class of those above classes, drop the leading underscore and allow it to be overridden in a subclass
19:41:31 <portante> and add that same method to how the object server does it.
19:41:59 <torgomatic> so have some spot where you can easily say "use this class, not that class"?
19:42:02 <portante> the key question in my mind is: are those classes in a shape that we are willing to declare them an API?
19:42:05 <notmyname> portante: I'd guess that we'd all be ok with refactors that allow easy replacement. and once we know there are people doing that, it becomes harder for us to change things
19:42:20 <portante> yes
19:42:25 <portante> yes
19:42:27 <portante> to both of you
19:42:51 <portante> you can see our current code on github at:
19:43:10 <portante> https://github.com/gluster/gluster-swift
19:43:18 <notmyname> I'm a little more hesitant to formally define an internal API in the same way the external api is defined, if only because we do feel that the swift implementation is important (but I do love you guys)
19:43:51 <portante> we agree
19:43:56 <notmyname> :-) yay
19:44:01 <gholt> we? there's a lot of wees around
19:44:14 <portante> we want to reuse as much code as possible
19:44:19 <portante> we redhat
19:44:25 <portante> sorry
19:44:51 <davidhadas_> I think there should be no problem with having a low level API to a device being completely open
19:44:52 <gholt> I was teasing both you and and notmyname
19:44:57 <notmyname> gholt: I'm assuming that "we the swift maintainers as a group" think that the particular implementation of swift in the openstack sourcetree is imortant
19:45:00 <zaitcev> Oh now you've done it, Peter. It's Red Hat with a space. Please report to the branding team for additional training :-)
19:45:16 <portante> ;)
19:45:22 <davidhadas_> A device in Swift doe snot have to be a "local physical disk" - and it is still Swift
19:45:55 <davidhadas_> But my worry is that I think it does require work to get the API to be generic and sutiable to become external
19:46:06 <notmyname> I'd love to use such abstractions to swap out implementations better suited to particular filesystems or storage types
19:46:16 <zaitcev> This is not good enough for UFO, unless you want to include those wonderful object storage devices like IBM HPSS.
19:46:19 <davidhadas_> notmyname: +1
19:46:29 <portante> zaitcev: what do you mean?
19:47:07 <cschwede> notmyname: +1
19:47:09 <portante> notmyname: yes, so what do we feel comfortable enough with DiskFile and DatabaseBroker today?
19:47:19 <portante> to declare them an API?
19:47:24 <portante> I don't personally.
19:47:29 <notmyname> portante: well, you're the first one making alternates :-)
19:47:42 <torgomatic> I'd like to see a little more refactoring first.
19:47:44 <portante> I believe we need to smooth out the interfaces fisxrst
19:47:49 <portante> agreed
19:47:53 <zaitcev> Right.
19:48:34 <portante> the biggest thing is to prevent the caller from having to know how a class works internally
19:48:38 <torgomatic> specifically, I want data to go like this: (http/wsgi) <---> ObjectController <---> python datastructures in memory <---> DiskFile <---> (disk)
19:48:44 <davidhadas_> notmyname: The Q is if the current call signitures of DiskFile is the one we should use  - I assume it may not be... and we would need to make it into an external API by thinking what is the right API
19:48:44 <torgomatic> that may be just me, though
19:49:15 <notmyname> davidhadas_: seems like we still need some adjustment
19:49:40 <portante> for example, the work to push the fd down into the DiskFile class
19:49:48 <portante> currently a work in progress right now
19:49:49 <zaitcev> that's done is it not
19:50:21 <portante> almost
19:51:01 <portante> on the database broker side, the work that davidhaddas_ and zaitcev are doing with db_file field exposed would also be useful to cap off
19:51:34 <davidhadas_> So there seem to be partial agreement taht can help us go some way - to move from the current DiskFile API to a 'proper' one that can be used as an external one. And we need to do thae same for DBs
19:51:44 <portante> torgomatic: regarding python datastructures in memory, wouldn't we want to allow a way to pull data off the wire and put in on disk with as few memory copies as possible?
19:52:02 <notmyname> cool. portante, zaitcev, do you think you'll be able to have it done in the next 2 weeks (ie next meeting)?
19:52:12 <portante> perhaps
19:52:22 <portante> I have been working towards that, and hope to do so
19:52:23 <torgomatic> portante: well, yes. I'm not saying slurp everything, just that there's the handoff point
19:52:33 <portante> torgomatic: great
19:52:41 <gholt> I'm pretty sure very little can get merged in two weeks. ;P
19:52:52 <torgomatic> e.g. ObjectController reads a chunk, passes it to DiskFile for writing, lather-rinse-repeat
19:53:01 <notmyname> gholt: :-)
19:53:37 <gholt> To the point of initial review, yes. done? nope
19:53:38 <portante> what I have been looking at right now as how DiskFile is constructed and where its input values come from, and where else they are used
19:53:45 <notmyname> 7 minutes left
19:53:55 <portante> I think we are good on this topic
19:54:03 <notmyname> cool
19:54:10 <portante> tentative approval for the work, we'll check back in two weeeks
19:54:15 <portante> minus one e
19:54:19 <notmyname> great :-)
19:54:39 <notmyname> ok, thanks for your time everyone
19:55:00 <notmyname> I think we're done. anyone have anything for 5 minutes?
19:55:22 <notmyname> ok
19:55:24 <notmyname> #endmeeting