19:00:22 #startmeeting swift 19:00:23 Meeting started Wed Jul 23 19:00:22 2014 UTC and is due to finish in 60 minutes. The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:24 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:00:26 The meeting name has been set to 'swift' 19:00:32 who's here? 19:00:40 who's on first 19:00:44 yo 19:00:55 hello 19:00:56 o/ 19:01:01 g'day 19:01:11 o/ 19:01:26 #link https://wiki.openstack.org/wiki/Meetings/Swift 19:01:37 not a ton on the agenda 19:02:06 thanks for coming. let's get started :-) 19:02:07 o/ 19:02:28 first up, just in case you missed it, yesterday I tagged and released python-swiftclient 2.2.0 19:02:47 that includes the storage policy settings (and context-sensitive help and tempurl generate) 19:02:55 Nice work 19:02:57 so thanks for working on that (code and reviews) 19:03:20 speaking of clients.... 19:03:36 I just saw this today (or was reminded of it): https://review.openstack.org/#/c/109047/ 19:03:51 looks like the keystone project has made some changes in organization of code 19:04:20 basically, this means that if you deploy keystone with swift, you'll have another repo to track, manage, package, and deploy. have fun 19:04:25 and update your configs 19:05:18 yay, more complexity.. people are going to love that. 19:05:21 also, the deadline for talk submissions for the openstack paris summit is rapidly approaching. please do that soon. I think the deadline is monday 19:05:41 and book your hotels sooner than later 19:05:57 * torgomatic should probably figure out if he's going or not 19:06:32 before we get into covering specific patches, what else is on your mind? 19:07:42 * portante is sorry his is late 19:07:43 ok, that's easy :-) 19:07:45 I'm back from Germany, the infra meet up went well. 19:07:59 mattoliverau: ah! good to hear 19:08:14 mattoliverau: any concerns or things from the -infra team that we can solve? 19:08:14 I have an update on the auto abandon issue 19:08:27 please tell :-) 19:09:00 Well firstly thanks everyone for taking a look at my FormPost patch, that will be useful for infra moving to swift for log storage 19:09:37 On the auto adbandon side 19:09:41 notmyname: i actually had something to talk about and forgot to put it on the TODO thing so whenever we have time... 19:09:54 dfg: ok, great. after mattoliverau then 19:10:08 I put the auto abandon up for discussion at the meet up. 19:10:08 Infra don't like the idea of turning it back on, as most projects complained, and developers kept asking to get it un-abandoned. 19:10:22 In essence they felt it make for a poor overall user-experience.\ 19:10:40 I floated the idea of turning it back on, but allowing projects to opt in... but they thought this would make it unpredictable for users. 19:10:40 The idea is now that cores can abandon changes, and now with dash boards you can set up a filter to display any changes with a -1 score and haven't been touched in x timeframe. 19:10:45 *cough*unlike gate errors which are tottally a good thing*cough* 19:11:03 lol, yeah, we talked alot about gate errors believe me! 19:11:29 looking at simplifying some of the checks to remove gate bugs.. but that's a side track 19:11:41 back to report.. 19:11:43 mattoliverau: ok. what's next then? 19:11:48 I have a filter we can add to the dash board for this. 19:11:57 who controls what user counts as "core team"? More importantly, will that person let me add a bot to core so that we can have our automation back? 19:12:25 torgomatic: lol I thought of that too. I can look into that ;) 19:12:34 And if it would make it easier for you guys to get your work done, I'd like to volunteer to add the list to the dashboard, and then keep an eye on the it, attempt to ping owners of changes that look to be abandoned.. and when they are (abandoned) contact a core (via channel or a list at meetings) for you guys to abandon. 19:12:34 I know it isn't exactly what you wanted, as it isn't completely hands off, but I hope it helps. 19:12:44 torgomatic: depends on how much beer you buy me :-) 19:12:44 * torgomatic thinks that "less automation" is usually the wrong way to go 19:13:27 hehe 19:13:29 until we find a more automated way for us that is ;) 19:13:37 mattoliverau: you're referring to the "swift review dashboard" I put together? 19:13:45 notmyname: yup 19:13:54 mattoliverau: awesome. totally go for it 19:13:56 OR can just make a new one, but that way everyone can see 19:14:25 mattoliverau: there's nothing special about the one I made other than there are some links to it. and links can be easily changed 19:14:40 it isn't "owned" by anyone (or everyone owns it, actually) 19:14:53 Cool, leave it with me I'll raise the patch :) Do we want the same timeframe as before, 2weeks, or make it 4 weeks of negitive non update? 19:14:56 mattoliverau: thanks. anything else? 19:15:39 notmyname: I already have the search, just wanted to wait for the meeting before I submitted a patch :) 19:15:41 mattoliverau: start with 4 19:15:46 notmyname: k 19:15:49 if there aren't other strong opinions 19:16:38 sounds good thanks mattoliverau 19:16:41 notmyname: infra know there are issues with gate bugs and are working hard to fix them, most of the discussions were based on it... other then that I have nothing 19:16:57 mattoliverau: I'm glad you went and thanks for sharing :-) 19:17:05 dfg: what's up? 19:17:13 ok 19:17:29 i wanted to see if we can add a new flag in the commit msgs 19:17:41 if there was a change in the "API" 19:18:09 basically, i want to try playing around with only upgrading a single node in a cluster to be able to compare performance between releases 19:18:15 dfg: similar to the "DocImpact" one? 19:18:19 a canary node or whatever 19:18:21 notmyname: ya 19:18:29 dfg: swift-only or openstack-wide? 19:18:36 so the various internal APIs, not client-facing? or both? 19:18:38 and I'd like an easy way to be able to see if there's any code changes that would prevent this 19:18:45 torgomatic: both / all 19:18:55 swift-only 19:19:14 anything that would prevent what i said above 19:19:25 dfg: and you want a constant string or marker so you can grep git output? 19:19:32 just updraging a dtorage node. just upgrading a proxy, etc 19:19:38 notmyname: ya 19:19:53 makes total sense and seems completely reasonable to me 19:20:51 doing it swift-only means it will be more convention than automated. in both cases it will need to be enforced by reviewers 19:21:14 dfg: got a proposal for a string or tag to use? 19:21:17 i think it would really stream line a release process if we could do this. but with all the changes its hard to know if its possible 19:21:23 idk. 19:21:34 API-Change or something 19:21:43 dfg, and can you highlight one or two existing commits that would have benefited from that? 19:22:02 portante: how do you mean? 19:22:25 i imagine bvery few of our commits would have this flag. but without it its hard to be sure 19:22:36 like, commit abcdefg changed XYZ so it could have had API-Change applied 19:22:51 i can't think of one right now. 19:22:51 portante: not to speak for dfg, but I think some of the possibilities would be to experiment different implementations. once the api is set, then you can tell when your alt-obj-server will break 19:22:58 and commit hijklmnop changes xzy but it would not apply 19:23:29 So we will need to document it somewhere and make sure its easy to find for swift devs and new reviewers. maybe it would be something other projects are interested in too 19:23:33 ...as opposed to "this is a pain point today that needs to be fixed" 19:23:38 okay, I guess I am not quite following what is being asked, so I'll watch and see how this plays out 19:23:44 mattoliverau: yes. 19:23:59 dfg: before I say more, is that kinda what you were thinking about? 19:24:02 my formpost patch would be a good candidate as it added x-delete-at to the formpost middleware api. 19:24:28 this basically arose when I wanted to start tryign to do this canary node idea and people were like. its not expected behavior that a cluster can run longf term with 2 different versions of swift. 19:24:50 it didn't change or break the middleware, but would alert people (via grep) that something had changed api wise 19:25:08 imo thats almost never the case- we usually can have 2 different versions but its hard to prove without going through every single commit0 which is a lot of work 19:25:51 i'm not even thinking about the client (is that bad :) ) i 19:26:02 seems like a commit message tag is one way. `git notes` is another (but local, I think) 19:26:03 'm mostly talking about internal stuff 19:26:10 dfg, sounds like a reasonable thing to work towards 19:26:21 mattoliverau, portante: i think this patch would be another current example: https://review.openstack.org/#/c/72157/ 19:27:20 tdasilva_: yup, that looks like one too 19:27:20 dfg: any change or just breaking changes? eg what about stuff added as opposed to stuff changed? 19:27:35 dfg: so if you were to take the above patch as an example you wanted to try out, would you deploy one proxy server and a set of storage nodes that implemented the account-to-account copy change along side all the others? 19:27:41 all i'm interested in is the canary node use case 19:28:04 portante: let me look 19:29:04 makes perfect sense to me 19:29:08 mattoliverau: I agree it may be useful to others too, but let's first keep scope a lot smaller and see what works for us 19:29:18 mattoliverau: and yes, you're right that it would need to be documented 19:30:31 notmyname: sure, we can test it out, then think about floating the idea to other projects :) 19:31:27 i guess we'd flag that account copy thing but thats really what I'm interested in. if the proxy server needed a specific change in the object server and would produce weird results thats what i'm mostly talking about. memcache keys- that kind of stuff 19:31:46 k that makes sense to me then 19:31:59 for whatever that is worth ... 19:32:02 that patch probably should be flagged because the client would see weird results- but thats not reallly what i brought this up for. 19:32:05 if that makes sense 19:32:30 dfg: here's what I suggest: let's decide on the tag to use (eg APIChanges) and then I'll send an email to all swift-core about it and then let's start asking contributors to add it to patches 19:33:03 notmyname: +1 19:33:05 notmyname: sounds good. and as it is put to use we'll further define what it means 19:33:16 are we looking at APIChanges: [proxy|object|container|account] or just a catch all? 19:33:29 #vote sure why not 19:33:49 imo for now, just APIChanges and let it play out to see what makes sense 19:34:01 dfg: +1 19:34:14 sounds good 19:34:16 +1 19:34:16 ok 19:34:29 yay! making decisions! 19:34:34 +1 19:34:56 dfg: anything else from you on that? 19:35:05 any other questions for dfg or others about this? 19:35:12 no. i'll not talk for another couple months :) 19:35:16 should it be APIChanges or APIImpact (so it in-lines with an exiting notifier)? 19:35:27 mattoliverau: APIChanges 19:35:30 k 19:36:25 #agreed add APIChanges in the commit message of patches that affect an internal node-to-node or external API 19:36:51 anything else before we move on to patch reviews? 19:38:14 goodes: were you the one who volunteered to look into adding keystone support to swiftclient without using keystone client? 19:38:28 not i 19:38:40 goodes: heh, ok 19:38:45 then its a mystery 19:38:46 notmyname: i was going to give it a shot if nobody else was doing it. 19:38:47 #topic patch reviews 19:38:53 I was looking into a move operation between containers 19:39:01 hurricanerix: ah, cool. I don't htink anyone else is. have you looked at it yet? 19:39:20 hurricanerix: my hoped-for timeline is to get that in the juno timeframe 19:39:33 ie I think it's important to add before the next integrated release 19:40:40 hurricanerix: have you looked at it yet? 19:40:48 notmyname: a little bit. it doesn't really look that hard. i can probably have a draft done by next week to get some feedback on. 19:40:56 hurricanerix: great! thanks 19:41:09 ok, let's move on to the priority reviews page 19:41:12 https://wiki.openstack.org/wiki/Swift/PriorityReviews 19:41:31 several things have been taken care of since last week (which is great) 19:41:45 we still need some eyes on the keystone v3 patches 19:41:53 both in swiftclient and swift 19:42:50 who can look at those this week? 19:42:59 if anyone needs help with keystone v3 setup i have a few gists with some notes 19:43:12 see? acoles will help you get up and running :-) 19:43:22 e.g. changes to devstack to config swift for v3 19:43:31 WTF, I can take a look 19:43:56 i'd like to help, but won't be able to get to it this week, but will try next Monday 19:44:01 ok 19:44:10 acoles: can you repost those gists here? :) 19:44:21 * portante the slacker ... 19:44:22 peluse_: can you share the links to your gists? 19:44:33 portante: sure just a mo 19:44:33 or in channel post meeting : 19:44:41 mattgriffin: its acoles that has them and I'd like to see too :) 19:44:51 other matt* 19:44:53 acoles: I meant 19:45:04 https://gist.github.com/alistairncoles/ae9d5f92063b58afeb88 19:45:17 lol, i fail at typing, but it is early for me :P 19:45:34 ^^ bunch of stuff on that gist 19:45:41 acoles: thanks 19:46:08 notmyname: maybe i should put that link under the priority reviews 19:46:28 acoles: Good idea +1 19:46:47 acoles: done 19:47:23 notmyname: thx 19:47:37 I added the migration middleware to the priority reviews page 19:47:45 from gvernik 19:48:09 sounds good 19:48:10 etiher we need to beat it into shape and merge it or give him a fair response of "no, not gonna happen" 19:48:21 * notmyname personally likes the concept 19:48:59 can someone commit to looking at it this week? 19:49:32 * peluse_ raised his hand last time :) 19:49:36 heh 19:49:55 gvernik: can you confirm it rebases/merges cleanly against master? 19:49:55 i think my last feedback was to ask if the scope could be reduced to just swift to swift migration 19:50:04 to make review easier? 19:50:24 notmyname: it is, i rebased it before 1-2 weeks 19:51:00 gvernik: ok, thanks 19:51:06 i think the scope of swift-swift has less value, s3 to swift is much better, or file system to swift 19:51:43 I think its a great idea, I said so in the comments, once I've caught up from my trip etc. I'll take a look at it.. if that helps. 19:51:49 gvernik: yes, those are good, but smaller scope is easier to merge in the first place 19:51:54 mattoliverau: yes, it does. thanks 19:52:00 filesystem to swift is good IMO; S3 to Swift is a pain in my rear to test since I have to take out a credit card :) 19:52:25 what would you prefer to start with? file system to swift or swift to swift? 19:52:46 or s3 to swift, wich is cool :) 19:52:57 i like file system to swift :) 19:53:11 personally, I see more value in filesystem to swift, as it helps my support guys perform ingestions of data from big NFS-mounted things into Swift 19:53:17 that's just my use case though 19:53:35 mattoliverau: how about you and I look at it this week, as-is, and report back to gvernik next week? 19:53:40 gvernik: work for you? 19:53:48 sure 19:53:54 sounds good to me :) 19:53:55 typically they're going into an environment which lacks Swift and setting one up, so Swift -> Swift doesn't help them much... still nifty, just not my #1 target 19:54:09 I'd be happy to see and test both FS -> Swift and Swift -> Swift 19:54:12 torgomatic: ya, but acoles does have that use case of swift-swift :-) 19:54:20 i'll _try_ to take another look but am heading on vacation so can't promise 19:54:34 acoles: ah, ok. when will you be back (and have a great time!) 19:54:38 #link http://xkcd.com/1172/ 19:54:44 :) 19:54:58 notmyname: away next week 19:55:14 acoles: ok 19:55:45 speaking of people not being around.... 19:56:10 tdasilva_: portante: what do you know about your now-coworkers of chmouel and cschwede? haven't seen them much since y'all bought them :-) 19:56:30 redhat is chewing its cud perhaps? 19:56:35 ;) 19:56:37 lol 19:56:57 I got an email from them, so they are alive, but I have not had a chance to talk to them either 19:57:01 ok 19:57:11 hoping to talk to them next week 19:57:14 and they appear to be in the channel ... 19:57:18 if you do see them in the hallowed halls of red hat, tell them we miss them :-) 19:57:40 ok, looks like we don't have time to cover any other specific reviews this week 19:57:42 i think cshwede is still celebrating 7-1 :( 19:57:52 yes! 19:57:58 suffice to say, go look at the priority reviews page and review stuff 19:58:18 and we've got to figure out what do to with -specs 19:58:31 we havent' been executing well on that front IMO 19:58:40 so...topic for next meeting, I guess :-) 19:58:59 and with that... 19:59:10 later on... 19:59:37 thanks everyone for coming. see you next week 19:59:39 #endmeeting