19:00:22 <notmyname> #startmeeting swift
19:00:23 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:26 <openstack> The meeting name has been set to 'swift'
19:00:32 <notmyname> who's here?
19:00:40 <torgomatic> who's on first
19:00:44 <peluse_> yo
19:00:55 <gvernik> hello
19:00:56 <mattoliverau> o/
19:01:01 <goodes> g'day
19:01:11 <tdasilva_> o/
19:01:26 <notmyname> #link https://wiki.openstack.org/wiki/Meetings/Swift
19:01:37 <notmyname> not a ton on the agenda
19:02:06 <notmyname> thanks for coming. let's get started :-)
19:02:07 <acoles> o/
19:02:28 <notmyname> first up, just in case you missed it, yesterday I tagged and released python-swiftclient 2.2.0
19:02:47 <notmyname> that includes the storage policy settings (and context-sensitive help and tempurl generate)
19:02:55 <mattoliverau> Nice work
19:02:57 <notmyname> so thanks for working on that (code and reviews)
19:03:20 <notmyname> speaking of clients....
19:03:36 <notmyname> I just saw this today (or was reminded of it): https://review.openstack.org/#/c/109047/
19:03:51 <notmyname> looks like the keystone project has made some changes in organization of code
19:04:20 <notmyname> 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 <notmyname> and update your configs
19:05:18 <mattoliverau> yay, more complexity.. people are going to love that.
19:05:21 <notmyname> 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 <notmyname> and book your hotels sooner than later
19:05:57 * torgomatic should probably figure out if he's going or not
19:06:32 <notmyname> 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 <notmyname> ok, that's easy :-)
19:07:45 <mattoliverau> I'm back from Germany, the infra meet up went well.
19:07:59 <notmyname> mattoliverau: ah! good to hear
19:08:14 <notmyname> mattoliverau: any concerns or things from the -infra team that we can solve?
19:08:14 <mattoliverau> I have an update on the auto abandon issue
19:08:27 <notmyname> please tell :-)
19:09:00 <mattoliverau> 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 <mattoliverau> On the auto adbandon side
19:09:41 <dfg> 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 <notmyname> dfg: ok, great. after mattoliverau then
19:10:08 <mattoliverau> I put the auto abandon up for discussion at the meet up.
19:10:08 <mattoliverau> 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 <mattoliverau> In essence they felt it make for a poor overall user-experience.\
19:10:40 <mattoliverau> 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 <mattoliverau> 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 <notmyname> *cough*unlike gate errors which are tottally a good thing*cough*
19:11:03 <mattoliverau> lol, yeah, we talked alot about gate errors believe me!
19:11:29 <mattoliverau> looking at simplifying some of the checks to remove gate bugs.. but that's a side track
19:11:41 <mattoliverau> back to report..
19:11:43 <notmyname> mattoliverau: ok. what's next then?
19:11:48 <mattoliverau> I have a filter we can add to the dash board for this.
19:11:57 <torgomatic> 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 <mattoliverau> torgomatic: lol I thought of that too. I can look into that ;)
19:12:34 <mattoliverau> 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 <mattoliverau> I know it isn't exactly what you wanted, as it isn't completely hands off, but I hope it helps.
19:12:44 <notmyname> 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 <torgomatic> hehe
19:13:29 <mattoliverau> until we find a more automated way for us that is ;)
19:13:37 <notmyname> mattoliverau: you're referring to the "swift review dashboard" I put together?
19:13:45 <mattoliverau> notmyname: yup
19:13:54 <notmyname> mattoliverau: awesome. totally go for it
19:13:56 <mattoliverau> OR can just make a new one, but that way everyone can see
19:14:25 <notmyname> 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 <notmyname> it isn't "owned" by anyone (or everyone owns it, actually)
19:14:53 <mattoliverau> 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 <notmyname> mattoliverau: thanks. anything else?
19:15:39 <mattoliverau> notmyname: I already have the search, just wanted to wait for the meeting before I submitted a patch :)
19:15:41 <notmyname> mattoliverau: start with 4
19:15:46 <mattoliverau> notmyname: k
19:15:49 <notmyname> if there aren't other strong opinions
19:16:38 <acoles> sounds good thanks mattoliverau
19:16:41 <mattoliverau> 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 <notmyname> mattoliverau: I'm glad you went and thanks for sharing :-)
19:17:05 <notmyname> dfg: what's up?
19:17:13 <dfg> ok
19:17:29 <dfg> i wanted to see if we can add a new flag in the commit msgs
19:17:41 <dfg> if there was a change in the "API"
19:18:09 <dfg> 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 <notmyname> dfg: similar to the "DocImpact" one?
19:18:19 <dfg> a canary node or whatever
19:18:21 <dfg> notmyname: ya
19:18:29 <notmyname> dfg: swift-only or openstack-wide?
19:18:36 <torgomatic> so the various internal APIs, not client-facing? or both?
19:18:38 <dfg> 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 <dfg> torgomatic: both / all
19:18:55 <dfg> swift-only
19:19:14 <dfg> anything that would prevent what i said above
19:19:25 <notmyname> dfg: and you want a constant string or marker so you can grep git output?
19:19:32 <dfg> just updraging a dtorage node. just upgrading a proxy, etc
19:19:38 <dfg> notmyname: ya
19:19:53 <notmyname> makes total sense and seems completely reasonable to me
19:20:51 <notmyname> 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 <notmyname> dfg: got a proposal for a string or tag to use?
19:21:17 <dfg> 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 <dfg> idk.
19:21:34 <dfg> API-Change or something
19:21:43 <portante> dfg, and can you highlight one or two existing commits that would have benefited from that?
19:22:02 <dfg> portante: how do you mean?
19:22:25 <dfg> i imagine bvery few of our commits would have this flag. but without it its hard to be sure
19:22:36 <portante> like, commit abcdefg changed XYZ so it could have had API-Change applied
19:22:51 <dfg> i can't think of one right now.
19:22:51 <notmyname> 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 <portante> and commit hijklmnop changes xzy but it would not apply
19:23:29 <mattoliverau> 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 <notmyname> ...as opposed to "this is a pain point today that needs to be fixed"
19:23:38 <portante> 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 <notmyname> mattoliverau: yes.
19:23:59 <notmyname> dfg: before I say more, is that kinda what you were thinking about?
19:24:02 <mattoliverau> my formpost patch would be a good candidate as it added x-delete-at to the formpost middleware api.
19:24:28 <dfg> 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 <mattoliverau> it didn't change or break the middleware, but would alert people (via grep) that something had changed api wise
19:25:08 <dfg> 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 <dfg> i'm not even thinking about the client (is that bad :) ) i
19:26:02 <notmyname> seems like a commit message tag is one way. `git notes` is another (but local, I think)
19:26:03 <dfg> 'm mostly talking about internal stuff
19:26:10 <portante> dfg, sounds like a reasonable thing to work towards
19:26:21 <tdasilva_> mattoliverau, portante: i think this patch would be another current example: https://review.openstack.org/#/c/72157/
19:27:20 <mattoliverau> tdasilva_: yup, that looks like one too
19:27:20 <notmyname> dfg: any change or just breaking changes? eg what about stuff added as opposed to stuff changed?
19:27:35 <portante> 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 <dfg> all i'm interested in is the canary node use case
19:28:04 <dfg> portante: let me look
19:29:04 <torgomatic> makes perfect sense to me
19:29:08 <notmyname> 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 <notmyname> mattoliverau: and yes, you're right that it would need to be documented
19:30:31 <mattoliverau> notmyname: sure, we can test it out, then think about floating the idea to other projects :)
19:31:27 <dfg> 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 <portante> k that makes sense to me then
19:31:59 <portante> for whatever that is worth ...
19:32:02 <dfg> 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 <dfg> if that makes sense
19:32:30 <notmyname> 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 <torgomatic> notmyname: +1
19:33:05 <dfg> notmyname: sounds good. and as it is put to use we'll further define what it means
19:33:16 <acoles> are we looking at APIChanges: [proxy|object|container|account] or just a catch all?
19:33:29 <torgomatic> #vote sure why not
19:33:49 <dfg> imo for now, just APIChanges and let it play out to see what makes sense
19:34:01 <notmyname> dfg: +1
19:34:14 <peluse_> sounds good
19:34:16 <mattoliverau> +1
19:34:16 <acoles> ok
19:34:29 <notmyname> yay! making decisions!
19:34:34 <tdasilva_> +1
19:34:56 <notmyname> dfg: anything else from you on that?
19:35:05 <notmyname> any other questions for dfg or others about this?
19:35:12 <dfg> no. i'll not talk for another couple months :)
19:35:16 <mattoliverau> should it be APIChanges or APIImpact (so it in-lines with an exiting notifier)?
19:35:27 <notmyname> mattoliverau: APIChanges
19:35:30 <mattoliverau> k
19:36:25 <notmyname> #agreed add APIChanges in the commit message of patches that affect an internal node-to-node or external API
19:36:51 <notmyname> anything else before we move on to patch reviews?
19:38:14 <notmyname> goodes: were you the one who volunteered to look into adding keystone support to swiftclient without using keystone client?
19:38:28 <goodes> not i
19:38:40 <notmyname> goodes: heh, ok
19:38:45 <mattoliverau> then its a mystery
19:38:46 <hurricanerix> notmyname: i was going to give it a shot if nobody else was doing it.
19:38:47 <notmyname> #topic patch reviews
19:38:53 <goodes> I was looking into a move operation between containers
19:39:01 <notmyname> hurricanerix: ah, cool. I don't htink anyone else is. have you looked at it yet?
19:39:20 <notmyname> hurricanerix: my hoped-for timeline is to get that in the juno timeframe
19:39:33 <notmyname> ie I think it's important to add before the next integrated release
19:40:40 <notmyname> hurricanerix: have you looked at it yet?
19:40:48 <hurricanerix> 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 <notmyname> hurricanerix: great! thanks
19:41:09 <notmyname> ok, let's move on to the priority reviews page
19:41:12 <notmyname> https://wiki.openstack.org/wiki/Swift/PriorityReviews
19:41:31 <notmyname> several things have been taken care of since last week (which is great)
19:41:45 <notmyname> we still need some eyes on the keystone v3 patches
19:41:53 <notmyname> both in swiftclient and swift
19:42:50 <notmyname> who can look at those this week?
19:42:59 <acoles> if anyone needs help with keystone v3 setup i have a few gists with some notes
19:43:12 <notmyname> see? acoles will help you get up and running :-)
19:43:22 <acoles> e.g. changes to devstack to config swift for v3
19:43:31 <peluse_> WTF, I can take a look
19:43:56 <tdasilva_> i'd like to help, but won't be able to get to it this week, but will try next Monday
19:44:01 <notmyname> ok
19:44:10 <portante> acoles: can you repost those gists here? :)
19:44:21 * portante the slacker ...
19:44:22 <mattoliverau> peluse_: can you share the links to your gists?
19:44:33 <acoles> portante: sure just a mo
19:44:33 <mattoliverau> or in channel post meeting :
19:44:41 <peluse_> mattgriffin:  its acoles that has them and I'd like to see too :)
19:44:51 <peluse_> other matt*
19:44:53 <mattoliverau> acoles: I meant
19:45:04 <acoles> https://gist.github.com/alistairncoles/ae9d5f92063b58afeb88
19:45:17 <mattoliverau> lol, i fail at typing, but it is early for me :P
19:45:34 <acoles> ^^ bunch of stuff on that gist
19:45:41 <notmyname> acoles: thanks
19:46:08 <acoles> notmyname: maybe i should put that link under the priority reviews
19:46:28 <mattoliverau> acoles: Good idea +1
19:46:47 <notmyname> acoles: done
19:47:23 <acoles> notmyname: thx
19:47:37 <notmyname> I added the migration middleware to the priority reviews page
19:47:45 <notmyname> from gvernik
19:48:09 <gvernik> sounds good
19:48:10 <notmyname> 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 <notmyname> can someone commit to looking at it this week?
19:49:32 * peluse_ raised his hand last time :)
19:49:36 <notmyname> heh
19:49:55 <notmyname> gvernik: can you confirm it rebases/merges cleanly against master?
19:49:55 <acoles> i think my last feedback was to ask if the scope could be reduced to just swift to swift migration
19:50:04 <acoles> to make review easier?
19:50:24 <gvernik> notmyname: it is, i rebased it before 1-2 weeks
19:51:00 <notmyname> gvernik: ok, thanks
19:51:06 <gvernik> i think the scope of swift-swift has less value, s3 to swift is much better, or file system to swift
19:51:43 <mattoliverau> 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 <notmyname> gvernik: yes, those are good, but smaller scope is easier to merge in the first place
19:51:54 <notmyname> mattoliverau: yes, it does. thanks
19:52:00 <torgomatic> 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 <gvernik> what would you prefer to start with? file system to swift or swift to swift?
19:52:46 <gvernik> or s3 to swift, wich is cool :)
19:52:57 <tdasilva_> i like file system to swift :)
19:53:11 <torgomatic> 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 <torgomatic> that's just my use case though
19:53:35 <notmyname> mattoliverau: how about you and I look at it this week, as-is, and report back to gvernik next week?
19:53:40 <notmyname> gvernik: work for you?
19:53:48 <gvernik> sure
19:53:54 <mattoliverau> sounds good to me :)
19:53:55 <torgomatic> 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 <torgomatic> I'd be happy to see and test both FS -> Swift and Swift -> Swift
19:54:12 <notmyname> torgomatic: ya, but acoles does have that use case of swift-swift :-)
19:54:20 <acoles> i'll _try_ to take another look but am heading on vacation so can't promise
19:54:34 <notmyname> acoles: ah, ok. when will you be back (and have a great time!)
19:54:38 <torgomatic> #link http://xkcd.com/1172/
19:54:44 <torgomatic> :)
19:54:58 <acoles> notmyname: away next week
19:55:14 <notmyname> acoles: ok
19:55:45 <notmyname> speaking of people not being around....
19:56:10 <notmyname> 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 <portante> redhat is chewing its cud perhaps?
19:56:35 <portante> ;)
19:56:37 <notmyname> lol
19:56:57 <portante> 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 <notmyname> ok
19:57:11 <tdasilva_> hoping to talk to them next week
19:57:14 <portante> and they appear to be in the channel ...
19:57:18 <notmyname> if you do see them in the hallowed halls of red hat, tell them we miss them :-)
19:57:40 <notmyname> ok, looks like we don't have time to cover any other specific reviews this week
19:57:42 <tdasilva_> i think cshwede is still celebrating 7-1 :(
19:57:52 <portante> yes!
19:57:58 <notmyname> suffice to say, go look at the priority reviews page and review stuff
19:58:18 <notmyname> and we've got to figure out what do to with -specs
19:58:31 <notmyname> we havent' been executing well on that front IMO
19:58:40 <notmyname> so...topic for next meeting, I guess :-)
19:58:59 <notmyname> and with that...
19:59:10 <peluse_> later on...
19:59:37 <notmyname> thanks everyone for coming. see you next week
19:59:39 <notmyname> #endmeeting