19:01:39 <notmyname> #startmeeting swift
19:01:40 <openstack> Meeting started Wed Jun 26 19:01:39 2013 UTC.  The chair is notmyname. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:41 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:41 <vvechkanov|2> o/
19:01:43 <openstack> The meeting name has been set to 'swift'
19:01:57 <torgomatic> o/
19:02:01 <notmyname> Good morning or afternoon to everyone!
19:02:16 <notmyname> we've got several things to discuss today
19:02:17 <notmyname> https://wiki.openstack.org/wiki/Meetings/Swift
19:02:28 <notmyname> first, general stuff
19:02:33 <notmyname> #topic general stuff
19:03:00 <notmyname> 1.9.0 RC has been cut and is on the milestone-proposed branch
19:03:06 <notmyname> tons of great stuff in it
19:03:18 <notmyname> please take time to review it and do any tests
19:03:35 <notmyname> unless something comes up before next tuesday, this is what we'll release as 1.9.0 (final)
19:03:40 <davidhadas> when was the cut time?
19:04:13 <notmyname> davidhadas: sometime between midnight-ish pacific last night and whenever ttx got my email in france :-)
19:04:46 <notmyname> any questions about 1.9.0?
19:04:50 <davidhadas> :) do we want to add account-acl to 1.9? I think its is mmmmmmerging
19:05:02 <notmyname> no
19:05:46 <davidhadas> interesting :)
19:05:49 <creiht> awww
19:06:07 <dfg> is nested slo's and the bulk name change thing in 1.9?
19:06:30 <notmyname> dfg: https://review.openstack.org/#/c/30956/ is not
19:06:40 <notmyname> dfg: I think the "name change thing" is
19:06:59 <dfg> this one: https://review.openstack.org/#/c/34107/
19:07:28 <notmyname> dfg: yes, but checking
19:07:38 <davidhadas> notmyname: any reason after we did refactor swift with two patchs and got the work done to use it with accoung acls we are not adding it in?
19:08:14 <davidhadas> This was something we said we will do in Portland
19:08:56 <notmyname> dfg: yes, that's included
19:09:20 <notmyname> davidhadas: there will still be at least one more release before the openstack havana cycle is done
19:09:41 <portante> do you mean one more release and then the final release of havana?
19:09:46 <davidhadas> I am sure - but this is no reason not to include it :)
19:09:51 <portante> or one more release that constitutes havana?
19:10:06 <notmyname> portante: not sure yet
19:10:38 <portante> k
19:10:47 <zaitcev> means we need to act on https://blueprints.launchpad.net/swift/+spec/diskfile-databasebroker-as-apis Right Now in order to see it in Havana
19:11:06 <notmyname> quick poll: who is going to be going to Hong Kong for the next summit?
19:11:21 <creiht> we don't know for sure yet on our side
19:11:22 * torgomatic isn't sure yet
19:11:25 <portante> notmyname: I am not
19:11:43 <portante> zaitcev: yes we are working on that
19:11:45 <creiht> likely just 1 of us though
19:11:56 <davidhadas> No decision yet
19:11:57 * swifterdarrell isn't sure yt
19:11:59 <swifterdarrell> *yet
19:12:08 <torgomatic> creiht: just one from the Cloud Files team?
19:12:12 <creiht> torgomatic: yes
19:12:13 <litong> need approval from management.
19:12:37 <litong> that normally won't come until close to the summit date.
19:12:59 <notmyname> good to know. as the summit approaches, the topics discussed will be influenced by who can be there
19:13:26 <notmyname> ok, next up
19:13:31 <notmyname> #topic PBR
19:13:47 <notmyname> there's a proposal to use it for swift. it's already used for python-swiftclient
19:13:58 <notmyname> there have been some complaints about it
19:14:05 <creiht> Pabst Blue Ribbon?
19:14:08 <zaitcev> Such as what?
19:14:15 <notmyname> and I believe mordred is lurking to hear any concerns
19:14:22 <notmyname> torgomatic: swifterdarrell: ?
19:14:22 <mordred> heyhey
19:14:44 <swifterdarrell> I like pbr okay, especially since I've already gone through the work to package it for python-swiftclient.
19:14:49 <notmyname> mordred: could you give a 1 line summary of what PBD does?
19:14:51 <creiht> I think mordred just likes tweaking that stuff once a round so that he gets to be an ATC for every project :)
19:15:03 <notmyname> *PBR
19:15:13 <mordred> creiht: that's DEFINITELY my goal :)
19:15:43 * mordred proposes a new super-atc label for people with commits in all projects...
19:15:59 <mordred> notmyname: so - the basic thing is
19:16:03 <creiht> notmyname: I just heard word that there is a good chance none of us may be there
19:16:22 <notmyname> creiht: hmmm (but what's new? *zing*!
19:16:25 <mordred> notmyname: pbr is a library that enapsulates all of the various build operations and standards that we were copying around all of the projects
19:16:37 <clayg> I think there used to be this idea that swift wanted to not include depends that weren't available on old distros because we want to be easy to package... but I'm not sure that's still true (e.g. xattr>=newest-version-evar)
19:16:57 <portante> my vote would be to try to use pbr for Havana
19:16:59 <mordred> most notable features relevant for swift are: declarative config, tag-based-versioning
19:17:08 * portante not that I really understand what I am saying but hey
19:17:18 <notmyname> mordred: what is "declarative config"?
19:17:19 <mordred> it also does some other things - like authors and changelog generation, but the intent is to disable those for swift
19:17:32 <torgomatic> one thing I find weird about pbr is that it's a run-time dependency; it seems like it only provides any utility at build-time
19:17:35 <mordred> notmyname: instead of putting code in setup.py, you put build info in setup.cfg
19:17:40 <notmyname> mordred: I think a question is what benefit it brings beyond "well everyone else is using it"
19:17:42 <mordred> torgomatic: it doesn't have to be a run-time dep
19:17:53 <torgomatic> mordred: oh? do tell...
19:18:01 <clayg> mordred: I thought the __version__ stuff imported from pbr?
19:18:02 <mordred> torgomatic: and there is a bug that's got a patch up to be fixed that will make that even more the case
19:18:09 * clayg goes to get his head back on stright
19:18:17 <notmyname> mordred: if it is a run-time dep, that needs to change
19:18:28 <mordred> clayg: the version stuff does import from pbr - but the version stuff just draws from pkg_resources
19:18:42 <mordred> so if you don't want it runtime- you can totally just make the pkg-resources call yourself
19:18:50 <clayg> notmyname: rly?  dnspython is a "runtime dependency" because of setuptools and requires.txt - why should pbr be different?
19:19:26 <notmyname> clayg: now we get back to those fun dependency requirements questions :-)
19:19:41 <mordred> notmyname: the main benefit you'll get other than just doing what other people do is the tag-based-versions and releasing things by pushing tags
19:19:42 <notmyname> clayg: I'm not sure it is
19:19:50 <torgomatic> if I can build packages for swift[client] that need pbr at build-time only, that'd be nice
19:20:30 <notmyname> mordred: I like that feature, but not at the expense of making every packagers life harder because I didn't want to update a string in a file
19:20:47 <mordred> torgomatic: you can totally do that
19:20:47 <swifterdarrell> Does it even matter if pbr is a run-time dep?  Every distro for which a pbr-using package is built, will need to have pbr packaged...  not that I don't think it'd be better if it weren't, but as far as a reason to not use it...
19:21:25 * notmyname withdraws previous "if ... then that needs to change" statement ;-)
19:21:27 <mordred> notmyname: and I don't think it should make packagers life harder - at least I certianly hope it wouldn't
19:21:46 <torgomatic> mordred: got any pointers on how?
19:22:08 <mordred> torgomatic: we just need to modify the swift pbr patch to use pkg_resources call for the version call
19:22:13 <notmyname> creiht: any RAX perspective? is it a pain point or an improvement that you can take advantage of?
19:22:16 <mordred> torgomatic: I can make that patch and show it to you
19:22:24 <torgomatic> mordred: that would be very nice
19:22:44 <zaitcev> I'm trying to see if get_manpath() in pbr is the right one. I remember I had to fix it somewhere, but I forgot what package
19:22:45 <notmyname> #action mordred modify the swift pbr patch to use pkg_resources call for the version call
19:22:49 <clayg> yeah I mean idk... if I "import swiftclient.version" it says I need pbr
19:22:58 <mordred> yeah. we'll fix that
19:23:01 <clayg> i see pbr imported in swift/__init__ so I ...
19:23:04 <clayg> oh :D
19:23:56 <notmyname> so the patch as proposed to swift now still needs work? and pbr's use in python-swiftclient should be update to remove swift's transitive runtime dependency?
19:24:05 <notmyname> mordred: ^ or is pbr itself going to change?
19:25:27 <notmyname> ...
19:26:46 <notmyname> maybe we should come back to that? :-)
19:26:51 <clayg> but... i mean pkg_resources returns a string for version... not a VersionInfo instance
19:27:01 <clayg> why can't we just depend on and package pbr?
19:27:11 <clayg> like... who cares?
19:27:45 <zaitcev> okay, I verified pbr has okay get_manpath(). What the heck, let's do that Declarative Mumbo-Jumbo, it promises to save code a bit.
19:28:27 <torgomatic> clayg: it just seems weird to me that there's a runtime dependency on a thing that looks at git metadata to make a version tag, because at runtime there isn't any git metadata floating around
19:28:46 <torgomatic> I mean, it's not the end of the world, but it does seem weird
19:29:04 <mordred> sorry - got pulled away for a sec
19:29:14 <mordred> notmyname: I will change the swift patch
19:29:15 <notmyname> but since the runtime dependency is going to be resolved by mordred's new patch, that concern should go away
19:29:19 <mordred> notmyname: and Ill put in a patch to swiftclient
19:29:23 <notmyname> ok, sounds good :-)
19:29:24 <torgomatic> notmyname: works for me
19:29:27 <notmyname> thanks
19:29:38 <creiht> To me, it still really to give us very little, for the cost of depending on another package
19:29:39 <notmyname> next topic then
19:29:52 <notmyname> or not
19:29:56 <creiht> lol
19:29:57 <creiht> move on
19:30:01 <notmyname> heh
19:30:04 <clayg> well i guess if there's a new patch coming we'll wait
19:30:13 <notmyname> #topic openstack-hacking
19:30:24 <notmyname> https://review.openstack.org/#/c/33861/ has been proposed
19:30:52 <notmyname> I'm not a fan of starting to use yet another external test dependency, but I want to get other thoughts
19:31:02 <creiht> yay more of "not adding much value" :)
19:31:19 <portante> how do other openstack projects use it?
19:31:26 <notmyname> I was thinking about -2'ing that patch until I saw it on the agenda for today's meeting
19:31:26 <portante> in addition to other tools?
19:31:48 <notmyname> mordred: if you're still here, you may have some good info for us about openstack-hacking
19:31:51 <portante> Or as the only way of enforcing coding standards
19:32:02 <mordred> I know many things :)
19:32:05 <notmyname> portante: I think it's the nova code standards
19:32:24 <portante> does the nova coding standards apply to all the other groups?
19:32:33 <portante> or projects?
19:32:34 <notmyname> portante: I'll let you guess ;-)
19:32:40 <portante> :)
19:32:41 <mordred> pretty much everyone else has decided to adopt some or all of them now
19:32:56 <clayg> I think it *started* as a nova standard
19:33:03 <mordred> they are done as a flake8 plugin, so it's possible to choose to only enforce some of them
19:33:03 <clayg> either way it all seems fine to me
19:33:08 <portante> then it might be worth for us to do the same
19:33:25 <mordred> it did - and most of them (it turns out) actually derive from google's python style guidelines
19:33:26 <clayg> redbo whined when the new pep8 started enforcing indent rules but he survived
19:33:28 <notmyname> mordred: so if that patch get's merged what's added for us to get code merged?
19:33:30 <clayg> +1 dont' care
19:33:44 <davidhadas> chmouel: suggested as a topic but could not attend today - maybe we should postpone to next meeting before deciding
19:34:04 <torgomatic> I'll give the hacking patch a resounding "meh"
19:34:05 <mordred> notmyname: it the same process as before
19:34:05 <portante> not that we have to immediately change all our code, but let's start using it for what we do at first
19:34:27 <notmyname> davidhadas: I had the same concerns as him, I think
19:34:36 <torgomatic> if others want it, that's fine; I'll neither help nor hinder
19:34:37 <notmyname> portante: how so?
19:34:45 <davidhadas> ok
19:34:53 <notmyname> torgomatic: well, we've said that before (eg pbr)
19:35:08 <swifterdarrell> The patch to add hacking stuff didn't seem to have to change much of the existing source-base, right?  Mostly stuff related to doc-string formatting?  That's what I remember, anyway
19:35:11 <creiht> portante: I'm not looking forward to the, oh you are using hacking.txt now, why aren't you following x,y, and z?
19:35:12 <swifterdarrell> It seems fine to me
19:35:26 <notmyname> swifterdarrell: yes, but it added something to tox.ini that changes what is run
19:35:33 <clayg> creiht: not everything is as slippery a slope as you make it out to be
19:35:38 <creiht> lol
19:35:46 <zaitcev> sometimes it's an abyss
19:35:46 <creiht> I just said I'm not looking forward to it
19:35:52 <clayg> lol
19:35:55 <creiht> not that it is the end of the world
19:35:57 <zaitcev> Warning: No matches found for: python-hacking
19:36:06 <zaitcev> oh great, another thing to package
19:36:11 <swifterdarrell> creiht: well, at least there's still Christmas...
19:36:30 <notmyname> how do new contributors find the guidelines and test before they submit? does it add any packaging requirements?
19:36:36 <portante> creiht: yes, that is always possible
19:36:39 <creiht> I just think we spend way too much time on this minutiae rather than real problems
19:36:51 <swifterdarrell> zaitcev: mordred: wait, seriously?  It's another package to get the hacking plugin?
19:37:01 <swifterdarrell> I *do* think that depending on something not in PyPi is bullshit
19:37:08 <torgomatic> creiht: +1
19:37:11 * clayg doesn't say anything about creiht's and clayg "fixing" the saio doc lately
19:37:12 <mordred> it's in pypi
19:37:13 <torgomatic> swifterdarrell: it's in pypi as "hacking"
19:37:17 <zaitcev> No, maybe it's in flake8, I'm looking right now
19:37:17 <swifterdarrell> oh, okay...
19:37:20 <torgomatic> not "python-hacking"
19:37:26 * swifterdarrell settles down and takes a deep breath ;)
19:37:29 <portante> ;)
19:37:44 * portante always with them negatives waves, moriarty
19:37:56 * portante its a mother beautiful bridge and its gonna be there
19:38:14 <notmyname> ok, so then the patch should be reviewed as normal and not blocked for any meta-reason
19:38:39 <notmyname> let's move on to all that important stuff then ( creiht, torgomatic ) ;-)
19:38:56 <notmyname> #topic smallest swift config
19:39:02 <davidhadas> We would like to start up with a swift/doc/… describing a current 3 replica small configuration (2 nodes) and describing how it can be extended to a full size swift cluster – any thoughts/suggestions?
19:39:03 <notmyname> davidhadas: not sure what's the issue here
19:39:12 <notmyname> davidhadas: ok, do it :-)
19:39:15 <creiht> haha
19:39:25 <davidhadas> Next topic than :)
19:39:29 <notmyname> heh :-)
19:39:35 <creiht> see the important stuff is so easy
19:39:39 <notmyname> #topic placement control middleware
19:39:50 <portante> what is this exactly?
19:39:55 <davidhadas> SO here there is a new blueprint
19:40:12 <davidhadas> https://blueprints.launchpad.net/swift/+spec/cluster-sync-policy
19:40:16 <notmyname> #link https://blueprints.launchpad.net/swift/+spec/cluster-sync-policy
19:40:47 <davidhadas> Basically it is a step in the direction of enabling an assembly of N clusters
19:40:48 <notmyname> davidhadas: seems that the tl;dr is hooks for some sort of placement policy, and these can be managed in middleware
19:41:14 <davidhadas> tl;dr?
19:41:30 <portante> does the middleware need something from the core?
19:41:33 <notmyname> "too long; didn't read" ie summary
19:41:39 <notmyname> davidhadas: and IMO if it can be handled in middleware, then it's perhaps something that can be deferred
19:41:58 <davidhadas> THe idea is to add to container sync a level of automation in teh way containers which have container sync are created
19:43:05 <notmyname> davidhadas: is there a question you'd specifically like answered about the blueprint?
19:43:31 <notmyname> davidhadas: or about the topic in general?
19:43:47 <portante> davidhadas: so what does that mean for the core code?
19:43:58 <davidhadas> I would like to hear first reaction and fiurst objctions to understand if we should ivest in making this part of swift
19:44:23 <davidhadas> i.e. if others would be interested in such an approach
19:44:33 <portante> as middleware, it should be first developed and put in place and demonstrated before considered part of swift
19:44:33 <notmyname> davidhadas: do you anticipate any changes required in swift that would need to be done not in middleware?
19:44:43 <davidhadas> so we can develop it with time to allow a multi-caluter env with placement control
19:44:47 <portante> unless it has some core component that needs to change to enable efficient operation
19:45:02 <davidhadas> This is too early to say
19:45:05 <torgomatic> I think Swift is getting better at having geographically-distributed clusters, and IMHO that's way nicer than container-sync
19:45:16 <torgomatic> but that's just me
19:45:22 <clayg> torgomatic: +1 not just you
19:45:52 <davidhadas> I would like as a first stagte to build it as a middleware without changing swift - but with time I see it part of swift
19:46:03 <portante> sounds reasonable
19:46:08 <portante> go for it
19:46:12 <davidhadas> torgomatic: the region approach does not allow placement control which is critical for certain customers
19:47:03 <notmyname> davidhadas: like portante said, implementing it as middleware as a first step and demonstrating how it works is a great way to proceed
19:47:24 <notmyname> davidhadas: any other questions about it?
19:47:36 <davidhadas> no - sounds good
19:47:44 <notmyname> great :-)
19:47:48 <zaitcev> I can't imagine this monstrous container-sync in middleware. Surely it needs a background process of some kind. Currently IIRC container-sync parasites on replicator.
19:47:49 <clayg> davidhadas: I think also any improvements to container-sync would be appreciated
19:47:51 <notmyname> #topic directory storage
19:48:07 <notmyname> I have no idea what this is? who added it to the meeting and what is it?
19:48:37 <clayg> zaitcev: seperate daemon yeah?
19:48:39 <portante> is this the storage_directory() code changes in DiskFile and db.py?
19:48:44 <davidhadas> clayg: I agree but this is orthogonbal
19:49:05 <portante> davidhadas: ^^^
19:49:06 <notmyname> portante: the meeting agenda page has "Directory storage  - can we move forward with this?"
19:49:08 <davidhadas> Storage directory is me asking how are we going to continue with this pathc
19:49:21 <notmyname> what path?
19:49:32 <davidhadas> 2 weeks ago we said that we want to have it combined with time to the diskFile and since we did not progress
19:49:54 <davidhadas> https://review.openstack.org/#/c/32563/
19:50:22 <portante> currently the DiskFile work is in a refactoring phase ... I was unavailable due to the Red Hat summit (in Boston!) and am now back on the case
19:50:33 <notmyname> davidhadas: looks like a good idea. what did you need addressed here that shouldn't be addressed in gerrit on the patch?
19:50:52 <davidhadas> A decission to cont with it
19:51:12 <notmyname> why wouldn't you?
19:51:25 <davidhadas> Its for the reviewers to review - not for me to do :)
19:51:30 <davidhadas> I did what I could
19:51:32 <davidhadas> ;/
19:51:33 <portante> the gist of the issue, IIRC, is that the patch proposed a function that behaved differently based on the arguments
19:52:00 <notmyname> ok, then let's address the code issues in the patch in gerrit as code reviews. no need to do code reviews in here
19:52:01 <portante> there is refactoring work in the DiskFile stuff coming that might make this cleaner
19:52:11 <portante> notmyname: k
19:52:21 <notmyname> #topic other
19:52:24 <notmyname> anything else?
19:53:08 <notmyname> ok. thanks for your time, everyone :-)
19:53:11 <notmyname> #endmeeting