19:01:24 <notmyname> #startmeeting swift
19:01:25 <openstack> Meeting started Wed May  1 19:01:24 2013 UTC.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:29 <openstack> The meeting name has been set to 'swift'
19:01:45 <notmyname> hi all. welcome to our first meeting since the portland summit
19:02:25 <notmyname> I don't have a huge agenda this week, but I'd like to talk about 1) summit follow up 2) swift API and 3) blueprints
19:02:43 <notmyname> sot to start with...
19:02:48 <notmyname> #topic summit follow up
19:03:13 <notmyname> How was the summit for you? what was good or bad? what would you like to see different in the next one?
19:03:36 <davidhadas> Need 2 days (or more ) next time
19:03:42 <davidhadas> (instead of 1)
19:04:06 <creiht> I would have liked to see the discussion times more around actuall dev of swift rather than findings or showing off tools
19:04:16 <notmyname> davidhadas: agreed, but I'm not sure that could have been predicted based on previous tech sessions submitted
19:04:19 <swifterdarrell> ++ on more sessions for swift
19:04:36 <creiht> if you want to discuss findings, or show off tools, then those should be done in the other sessions (like what hp did for their perf stuff)
19:04:37 <davidhadas> notmyname: you askd about next time - this was no critic
19:05:36 <davidhadas> but the talk about what needs to be developed to benchmark swift was good
19:05:37 <notmyname> creiht: good feedback. I'd like to see gholt talk about sssync at a summit ;-)
19:05:50 <creiht> notmyname: well don't tell me that :)
19:06:07 <davidhadas> I'd like to see gholt
19:06:09 <davidhadas> :)
19:06:21 <dfg> i'm looking at him right now- its not that cool
19:06:28 <dfg> :)
19:06:30 <clayg> :)
19:06:33 <creiht> haha
19:06:46 <davidhadas> dfg: The mistory man
19:07:07 <dfg> he does wear a cape...
19:07:07 <shri> this was my first openstack summit. Loved the sessions on swift. Would've loved a session on getting started with swift development
19:07:21 <notmyname> I think we can try to get some more talks about swift code. how do you think that would look?
19:07:44 <clayg> creiht: so two talks specifically that I *enjoyed* that fit into the "findings" bucket was KT & Seagate, I also really liked the unsession stuff about more dev... I hope next time we can just make more time for both
19:07:49 <swifterdarrell> shri: notmyname: that'd be a great break-out session on a 2nd or 3rd day which was well-advertised the first day
19:07:51 <notmyname> shri: glad you could come. we had one at the san diego summit be ran out of space in this one. maybe an unconference session on that would be good?
19:08:15 <davidhadas> Such talks about code shoudl be apart from the design meetings - not instead
19:08:29 <creiht> clayg: I'm not saying they were bad talks, I'm just saying given how the format is they would be better suited for the other sessions
19:08:31 <davidhadas> design meetings were very good  - too short and too little
19:08:36 <shri> notmyname: yeah.. that would be good
19:08:50 <notmyname> I heard a suggestion for basic hackathon-style tracks at the summit. eg show up and you have a bugfix in master at the end of the day
19:08:55 <torgomatic> the rooms need some whiteboards; it's hard to discuss when your only tool is a slide projector
19:09:09 <creiht> Several people comminucated to me that the would have liked to see more design oriented sessions during the design part of the summit for swift
19:09:21 <clayg> davidhadas: creiht: notmyname: in past summits, I've found the hallway track was often better at talking code just because of all the noise in the rooms?  There'd be like 30 people... and sometimes it's hard to keep everyone on topic...
19:09:23 <shri> i attended one session on getting started with openstack development, not swift development
19:09:24 <notmyname> historically, we've had trouble with the design style sessions with swift.
19:10:17 <creiht> they are difficult all around (the other teams have the same issues)
19:10:20 <davidhadas> clayg: agree - but....  its hard to get all the right pepole at the same time in the halllway
19:10:30 <creiht> davidhadas: ++
19:10:32 <clarkb> shri: fwiw bootstrappign at the openstack level should be sufficient to get you going. we have intentionally made it so that moving across projects is easy to do
19:10:44 <creiht> more so as the number of active contributors increases
19:10:52 <shri> I see
19:11:04 <litong> @notmyname, I think that the session that you gave on Swift update and what is next is always good and useful and serve a good purpose to level the field.
19:11:37 <litong> +recognize Sam being the top contributor, that was very nice.
19:12:12 <notmyname> litong: ya, the state of the project is fun. I enjoy it, and I'm glad you did. but that's completely separate from the tech tracks :-)
19:12:37 <shri> also, i liked the swift sessions because there was lot of interaction and discussions. they weren't about a couple of speakers talking and rest of us simply consuming.
19:12:51 <notmyname> so what I'm hearing is that we need more time and we need more design/code talks
19:12:57 <notmyname> shri: +1
19:13:03 <clayg> notmyname: +1
19:13:16 <davidhadas> +2
19:13:17 <swifterdarrell> yup
19:13:21 <creiht> preference should be given to design/code talks durring the design part of the summit
19:13:29 <swifterdarrell> and also to prioritize sessions for design/code if space is tight
19:13:31 <torgomatic> notmyname: +1
19:13:47 <shri> notmyname: +1
19:13:50 <clayg> hrmm... I'm definately *not* saying that design/code session should be a priority
19:13:52 <notmyname> shri: FYI http://swiftstack.com/blog/2013/02/12/swift-for-new-contributors/
19:14:12 <swifterdarrell> it may be debatable, but it was said ;)
19:14:14 <clayg> but if everyone else feels that way that should definately put that out there - I liked the sessions we had, and the unconference
19:14:47 <clayg> I'd like more time, so we can have more space for some of the stuff that happened in the unconference
19:15:14 <shri> notmyname: cool. Will go through this in more details.
19:15:15 <clayg> notmyname: can you just go ahead and make everyone happy cause that would be great...
19:15:24 <swifterdarrell> ya, the ideal would be time enough for showing off cool tools and findings *and* actual code design discussions
19:15:32 <notmyname> clayg: working on it. (we still haven't voted in a meeting for you)
19:15:56 <adrian17od> I wasn't at this summit but weren't the sessions selected based on votes?
19:16:03 <notmyname> adrian17od: no
19:16:20 <notmyname> well, if you consider my input as the only vote... ;-)
19:16:24 <adrian17od> If we want to prioritise more dev/design sessions that would mean leaving that system.
19:16:33 <creiht> my only argument is that the tools and findings should be in the other talk tracks
19:16:45 <notmyname> good feedback. thansk
19:17:04 <creiht> adrian17od: the other tracs are voted on, then there are secret teams of people that select which talks make it
19:17:37 <notmyname> ya, I think the other tracks were voted. the tech tracks (for all projects) are up to the respective PTL
19:17:47 <adrian17od> I see.
19:18:22 <notmyname> any other comments about the summit or input on changes?
19:18:30 <notmyname> before we move on
19:18:38 <davidhadas> well about the chocolates...
19:18:45 <creiht> otherwise I do agree with clayg that the content of most of the discussions was good
19:19:27 <notmyname> #topic swift API
19:19:38 <clayg> we should have one!
19:19:44 <notmyname> I'm sure there are strong feelings on this topic
19:20:04 <clayg> meh
19:20:09 <creiht> SOAP
19:20:17 <notmyname> the current state is that we have a pretty good API. it's very stable. but there are a few warts, and the state of middleware is somewhat fuzzy
19:20:30 <notmyname> ie, is middleware part of the api or not
19:20:41 <swifterdarrell> can we just wait for the OpenStack API As A Service project?
19:20:41 <creiht> fuzzy wuzzy was a middleware
19:20:43 <notmyname> I'm not proposing that we decide this now
19:20:43 <davidhadas> notmyname: this is a big issue
19:20:45 <torgomatic> some is, some isn't?
19:20:57 <notmyname> yes
19:21:01 <davidhadas> torgomatic: which part is?
19:21:26 <swifterdarrell> I liked the distinction of API 1.1 being some incremental changes to core stuff (fixing the warts)
19:21:33 <notmyname> indeed
19:21:35 <swifterdarrell> That's probably something with broad support
19:21:44 <swifterdarrell> anything regarding middleware is going to be more contentious
19:21:49 <dfg> btw- before i forget I'm completely rewriting how bulk delete and expand archive are going to work.
19:22:00 <notmyname> but overall, we need to first have a sense of what the api is before we can even figure out what 1.1 is
19:22:04 <notmyname> dfg: oh goody
19:22:04 <torgomatic> davidhadas: tempurl maybe? I dunno, I'm just throwing that idea out there
19:22:21 <notmyname> dfg: I'll come back to you ;-)
19:22:22 <clayg> but asside from what... quoting etags did we really identify anything that should be changed in v1.1?
19:22:37 <notmyname> there are 2 APIs in swift: internal and external
19:22:37 <dfg> ya- i'm not expecting anyone to really care, hopefully
19:22:40 <creiht> there were quite a few things
19:22:50 <creiht> clayg: but I can't remember off the top of my head
19:23:19 <davidhadas> We need order in the middleware - this is not a trivial issue. But we probably need to have mandatory middleware as a first filter which is actualy part of Core Swift
19:23:28 <notmyname> the external api is what clients can use (defined [in part] at http://docs.openstack.org/api/openstack-object-storage/1.0/content/)
19:23:31 <swifterdarrell> clayg: I don't remember the details but I felt like there were about 3 or 4 little things
19:23:51 <notmyname> the docs site incidentally calls that the object storage 1.0 api spec
19:24:00 <clayg> creiht: yeah i sorta remember something on the etherpad... but then a lot of stuff we couldn't agree... and then I don't know if there was a final list of like "purposed changes to v1.1"
19:24:26 <notmyname> although it's certainly not something that we code to. it's more something that's written based on what's in the code
19:24:26 <creiht> clayg: yeah I think the next step would be to take that and start on a blueprint
19:24:48 <notmyname> well, I think the first step is to make sure we have an answer to what swift 1.0 is
19:25:03 <davidhadas> Q  - do we treat the small changes from 1.0 to 1.1 as a API change that requires us to support both?
19:25:22 <creiht> davidhadas: absolutely
19:25:24 <clayg> notmyname: wow, so that page opens with auth v1.0 specification, and we can't even get x-storage-token deprecated properly!
19:25:34 <davidhadas> creiht: than why do it?
19:25:47 <creiht> backwards compatability?
19:25:58 <creiht> clients are still going to be using v1.0 for quite some time
19:26:08 <creiht> or why do the clean up?
19:26:11 <davidhadas> creiht: but from now on to start supporting to versions - seems more pain than not doing any change
19:26:30 <creiht> sure there will be extra work
19:26:52 <creiht> but if nobody sees value in cleaning up the api, then there is an argument to be made for not doing it
19:26:55 <clayg> davidhadas: I think part of the value comes from defining the layout and abstractions *needed* to support different versions - part of a pre-req for v2.0
19:27:07 <notmyname> davidhadas: ya, but it doesn't have to be hugely painful eg: if api_version > 1.0: etag = '"%s"' % etag
19:27:16 <notmyname> clayg: yes
19:27:55 <notmyname> creiht: absolutely. no need to find extra work to do. we've got enough as-is
19:28:13 <notmyname> (but I think an API cleanup is beneficial to us all and thing we should do it)
19:28:22 <davidhadas> Ok - it all depends on the details - but I doubt if it makes sense - unless we gain something significant with it and if not  - it should all be delayed to 2.0
19:28:59 <davidhadas> (or  - better so - we ne dto find ways to add it without disrupting the clients and without getting info if ver == 1.0
19:29:45 <notmyname> I think the todo items are to 1) decide about middleware and 2) define what the 1.0 api is (based on the first answer)
19:30:02 <notmyname> which comes down to, "who's going to do it?"
19:30:07 <davidhadas> notmyname: can you detail "1"?
19:30:12 <creiht> davidhadas: yeah I'm not fond of adding a lot of speghetti if code for different api versions
19:30:27 <creiht> there are other ways to handle it
19:31:12 <notmyname> davidhadas: as an example, is the staticweb part of the official API? if a cluster doesn't use it, is it really a swift cluster? what about public containers?
19:31:29 <davidhadas> creiht: yeh - either it is a disruptive change with real value (going to 2.0) or it is not  - so keep the API and extend it - cleanup semms like neigher
19:31:52 <notmyname> (public containers is a difference in eg rackspace's swift product and what's in "vanilla swift"
19:32:08 <davidhadas> notmyname: so would this lead to code moving from middleware to core?
19:32:16 <notmyname> davidhadas: no
19:32:19 <clayg> well about the chocolates...
19:32:41 <davidhadas> clayg: that too long... :)
19:32:43 <clayg> I really don't want "is it implemented in middleware" to be a pre-req for "is it core"
19:32:45 <notmyname> something written as middleware is an implementation detail. eg catch_errors is vital, but it's implemented as middleware
19:32:54 <clayg> if it's *easier* to add a feature in middleware that's where it should go
19:33:04 <clayg> oh heh :)
19:33:08 <notmyname> "core" to me is "in the source tree"
19:33:25 <notmyname> (which has implications for a "contrib" section, but I digress...)
19:33:46 <notmyname> so how do we answer these questions? how do you want to do it?
19:33:46 <davidhadas> my poimnt before is that middleware is a big problem as it always come before the core and we do not know how to "wrap it" with core code
19:33:50 <davidhadas> E.g.
19:34:00 <notmyname> a mailing list seems that it will invite too many cooks into the kitchen
19:34:17 <creiht> Maybe we need source code amnesty to ensure a proper data democracy
19:34:17 <notmyname> IRC is hard to get everyone together
19:34:22 <adrian17od> Seems to me like the first job is to write up the API specification for 1.0
19:34:29 <notmyname> adrian17od: yes
19:34:34 <davidhadas> If we want to filter our ilegal headers (that middleware can send, but a client is not allowed to) we have no way to ensure that.
19:34:46 <notmyname> we could have this dicussion on the openstack wiki
19:35:21 <adrian17od> The discussion needs to happen around a doc so the wiki sounds like a good place
19:35:45 <notmyname> anyone object to discussing the api definition on the openstack wiki?
19:35:52 <notmyname> wait, shoudl we vote here?
19:35:55 <notmyname> clayg: ?
19:36:02 * creiht sighs
19:36:14 <notmyname> creiht: not helpful. what's your concern?
19:36:20 <davidhadas> I like the idea on working with Etherpad even when we are not in the same room
19:36:44 <creiht> I just don't think you are going to get a lot of useful collaboration on a wiki
19:37:14 <adrian17od> The alternative is gerrit?
19:37:31 <davidhadas> creiht: how about virtual design session(s) with Etherpad and IRC
19:37:56 <notmyname> davidhadas: I like etherpad, but I don't like how you can't tell who said what even a day after the discussion (ie after people leave the page)
19:38:02 <litong> why can't we treat the api specification doc just like any other patch. anyone care can voice with comments.
19:38:13 <notmyname> and a virtual design session has the problem of scheduling
19:38:16 <swifterdarrell> what does Etherpad give you that a wiki doesn't?  real-time editing, lack of formatting, and a bunch of distracting colors?
19:38:32 <notmyname> creiht: what woudl you prefer to a wiki page?
19:38:44 <creiht> nm
19:39:06 <clayg> creiht: but.. but... you LEAD the api discussion at teh summit!
19:39:18 <clayg> I'm all hoping you had the plan over here :'(
19:39:20 <creiht> and then it got off in the weeds with specs and such
19:39:33 <clayg> ahhh...
19:39:35 <creiht> I just wanted to clean things up
19:39:41 <davidhadas> swifterdarrell: a chance to get pepole attention for a while on a problem  - in other words a chance to brainstorm
19:39:47 <creiht> and there seems to not be a lot of political will for that
19:39:53 <creiht> so it's notmyname's call
19:40:10 <clayg> for the clean up?  I think that is totally in the list of 2 things to be done?
19:40:42 <clayg> oh... maybe i read that wrong
19:40:49 <torgomatic> I dunno, a cleanup in core code plus a recrappification middleware sounds like a decent enough approach to me
19:41:02 <notmyname> creiht: I think there is a strong desire to make things better. but I don't think we can do that responsibly in a global community of deployers and contributors without first defining what it is we are actually changing
19:41:22 <creiht> notmyname: ok then go do that, then I'll see about changing stuff :)
19:41:28 <clayg> I think in my mind I put "creiht | clayg: yeah I think the next step would be to take that and start on a blueprint" on my list
19:41:37 <swifterdarrell> davidhadas: IRC is a decent online place to have a real-time conversation and a wiki is a decent place to store formatted information multiple people can edit;  I see Etherpad as a failure to attempt to combine those both?  But that's just my personal opinion.
19:42:11 <notmyname> davidhadas: would you object too strongly in a wiki doc?
19:42:30 <creiht> clayg: well that *was* my next plan of action
19:42:44 <davidhadas> notmyname: no objections
19:42:57 <clayg> notmyname: what about using that doc you linked as a starting point?
19:43:20 <swifterdarrell> wiki + irc seems good to me; I mean your problem will be getting people to care and actively participate more that it'll be what tools to use
19:43:21 <notmyname> I'll put together a starting doc on the openstack wiki and send an email when it's done
19:43:39 <swifterdarrell> if you have people caring and participating, they'll use whatever tools work
19:44:13 <davidhadas> torgomatic: I learn a new word every day   :) "recrappification"
19:44:21 <creiht> lol
19:44:22 <davidhadas> that is awsome
19:44:33 <torgomatic> I make up a new word every day, so we'll get along great. :)
19:44:44 <davidhadas> good
19:44:53 <swifterdarrell> ...for when the initial crapification wasn't bad enough...
19:45:14 <notmyname> ok, so moving on to 2 small things
19:45:23 <notmyname> #topic blueprints
19:45:42 <notmyname> (for the record, I really don't think blueprints are all that great)
19:45:49 <creiht> there are no small things left in swift :)
19:46:06 <notmyname> blueprints are what we have to help let others know what's going on inside of swift
19:46:07 <swifterdarrell> notmyname: I'll go on record as agreeing with that.
19:46:18 <creiht> yeah we can vote on that!
19:46:26 <notmyname> :-)
19:47:01 <notmyname> so I'm asking you to use them.
19:47:06 <notmyname> The goal is that you add one for stuff you are doing and then target it to havana. This allows people external to your org know what's going on and what to expect when. It also has the side benefit of promoting Swift (indirectly) by showing constant activity.
19:47:45 <notmyname> so please use blueprints. at least with a short note saying "hey, I'm working on this"
19:48:01 <notmyname> for example, dfg should make a blueprint about his bulk middleware refactoring
19:48:02 <notmyname> :-)
19:48:06 <briancline> yeah, I usually end up digging through the bug list because a lot of existing blueprints are pretty thin
19:48:13 <notmyname> dfg: I told you I'd come back to you about that
19:48:14 <briancline> and review.*
19:48:17 <swifterdarrell> then you reference the bp in the commit message and it helps reviewers understand the context of why the whizzbang should be connected to the frombulator instead of the wackyjigg?
19:48:34 <dfg> ya- i could do that i guess...
19:48:39 <notmyname> dfg: thanks
19:48:42 <creiht> I look forward to the recrapification blueprint
19:48:49 <dfg> oh- you were being serious?
19:48:52 <dfg> :)
19:48:54 <creiht> lol
19:49:03 <notmyname> torgomatic: I don't think there's one for the threadpool stuff
19:49:38 <notmyname> #topic other
19:50:03 <torgomatic> notmyname: there sure isn't. I don't like blueprints since they lack both comments and notify-on-edit, but I can throw one up anyway
19:50:04 <davidhadas> This is a good topic
19:50:15 <notmyname> it's come up a few times in the past week, so I'll mention it here. If you want to stay involved in IRC conversations, IRC bouncers are a great thing. I recommend http://znc.in
19:50:32 <creiht> or a shell somewhere an irssi
19:50:39 <notmyname> torgomatic: I completely agree re blueprints
19:50:46 <clayg> irssi o/
19:50:54 <briancline> +1 for irssi in a tmux session
19:51:11 <notmyname> anything else for anyone?
19:51:17 <clayg> notmyname: yeah can you ask in some sort of "openstacky" meeting how we can go about making blueprints useful?
19:51:32 <creiht> there were some comments about that recently on the mailing list
19:51:35 <clayg> like.. do other projects use them successfully?  HOW?
19:51:50 <clayg> creiht: notmyname is like my personal hacker news for the mailing list
19:51:56 <clayg> he must not have upvoted that thread for me
19:52:18 <notmyname> clayg: I'll ask around again
19:52:35 <briancline> notmyname: not 100% swift but I'm curious what kind of effort there is currently behind moderating and pushing the ask.* site more
19:52:53 * clayg goes to ask how to use blueprints
19:53:21 <notmyname> reed: want to comment in here?
19:53:37 * reed reading
19:53:38 <notmyname> reed: re ask.o.o
19:53:45 <litong> @notmyname, I would like to ask about the two ctrl-C to end swift client process/threads. wondering how everybody feels about that.
19:53:59 <notmyname> litong: let's take that to #openstack-swift
19:54:06 <litong> k.
19:54:06 <briancline> it seems like a terrific resource as more and more people start to use it, but I've noticed it could use some help with retagging some of the questions that come in, editing when someone pastes in code/config/output blocks without formatting it into a block, etc.
19:54:14 <reed> briancline, ask.o.o needs more moderators
19:54:25 <notmyname> reed: what about migrating answers content?
19:54:47 <notmyname> reed: or auto-moderating ATCs for the project they've contributed to?
19:54:53 <briancline> granted they're little things, but they make a huge difference when perusing for questions to chime in on
19:54:54 <reed> notmyname, at the moment there is no concrete action item for that, it's very very hard to do
19:55:11 <reed> notmyname, explain 'automoderating'
19:55:19 <reed> oh, make them moderators?
19:55:36 <notmyname> reed: IIRC, I have about 1 karma on ask.o.o
19:55:37 <notmyname> ya that
19:55:46 <reed> I can make you a moderator right now
19:55:50 <reed> who else?
19:56:13 <reed> https://ask.openstack.org/about/ has some suggestions on what the questions and answers should look like
19:56:20 <notmyname> reed: is it organized per project or across all of openstack?
19:56:23 <briancline> me too -- so far I haven't found enough yet that I can usefully chime in on, so I've no powers yet to make those kinds of small tweaks to help make it useful in other ways
19:56:39 <briancline> in terms of karma
19:56:49 <reed> it's a generic Q&A site for openstack, it has tags that you can export as RSS
19:57:18 <reed> and it has email push capabilities: you can subscribe to 'interesting tags' and get email notifications of new questions tagged interesting
19:57:26 <notmyname> reed: my first response would be people who have answered the launchpad questions in swift (we've had great response from swift devs for LP answers)
19:58:14 <notmyname> any other quick questions in the last 2 minutes of our time?
19:58:29 <reed> I've looked into the 'how to import Q&A from LP' and I found the task very complex
19:59:11 <notmyname> thanks everyone for attending this week's meeting. see you in 2 weeks
19:59:11 <reed> left me wondering if it makes sense to spend lots of resources to move content from there
19:59:14 <notmyname> #endmeeting