Tuesday, 2011-06-14

*** ohnoimdead has quit IRC00:37
*** heckj has quit IRC00:39
*** cloudgroups has joined #openstack-dev01:08
*** cloudgroups has left #openstack-dev01:09
*** pmullaney has quit IRC01:41
*** jdurgin has quit IRC01:47
*** vladimir3p has joined #openstack-dev02:38
HugoKuohi guys03:35
HugoKuoI saw the new feature list of Cactus http://www.openstack.org/blog/2011/04/openstack-announces-cactus-release/   over here03:36
HugoKuoAnd it mentioned "Multi-cluster region support, which allows administrators to manage servers in clusters, and create fault zones and availability zones"03:36
HugoKuoIt's different from MultiZones right?03:37
*** Binbin has joined #openstack-dev04:34
*** Binbin has quit IRC04:34
*** Binbin has joined #openstack-dev04:34
*** Zangetsue has joined #openstack-dev04:50
*** openpercept_ has joined #openstack-dev06:09
*** reidrac has joined #openstack-dev07:02
*** vladimir3p has quit IRC07:06
*** zaitcev has quit IRC07:36
*** openpercept_1 has joined #openstack-dev07:50
*** openpercept_ has quit IRC07:51
*** openpercept_1 is now known as openpercept_07:51
*** openpercept_ has quit IRC07:51
*** openpercept_ has joined #openstack-dev07:51
*** Binbin has quit IRC09:06
*** Binbin has joined #openstack-dev09:07
*** Binbin has quit IRC09:29
*** Binbin has joined #openstack-dev09:42
*** chmouel has quit IRC09:49
*** chmouel has joined #openstack-dev09:50
*** Binbin has quit IRC10:16
*** markvoelker has joined #openstack-dev11:02
*** pmullaney has joined #openstack-dev13:03
sorenttx: For lp:~ttx/nova/lp791627 you should probably uncommit, and commit again with '--author "Vladimir Popovski <something suiteable>"'. This should make the Authors check fail (you should add Vladimir to Authors) and hopefully the CLA check as well?13:08
ttxsoren: I can do that. Thought it was OK to commit it that way, with the proposed patch being posted on the bug.13:11
ttxI need to dig into why the unit test fails anyway, so I'll bump the proposal into work in progress.13:12
*** ameade has joined #openstack-dev13:23
*** pyhole has quit IRC13:26
*** pyhole has joined #openstack-dev13:26
*** openpercept_ has quit IRC13:47
openstackjenkinsProject nova build #1,003: SUCCESS in 2 min 58 sec: http://jenkins.openstack.org/job/nova/1003/13:49
openstackjenkinsTarmac: Fixed bug 79661913:49
uvirtbotLaunchpad bug 796619 in nova "Revoke cert by user and project broken" [Medium,Fix committed] https://launchpad.net/bugs/79661913:49
openstackjenkinsProject nova-tarball-bzr-delta build #250: STILL FAILING in 11 sec: http://jenkins.openstack.org/job/nova-tarball-bzr-delta/250/13:54
openstackjenkinsTarmac: Fixed bug 79661913:54
uvirtbotLaunchpad bug 796619 in nova "Revoke cert by user and project broken" [Medium,Fix committed] https://launchpad.net/bugs/79661913:54
*** jkoelker has joined #openstack-dev14:24
*** vladimir3p has joined #openstack-dev14:34
*** dragondm has joined #openstack-dev14:40
*** pyhole has quit IRC14:46
ttxnotmyname: morning! so I see two concerns with announcing "due to internal constraints, we actually decided to do 1.4.1 next week"14:46
ttxnotmyname: the first is that the date is announced a bit late. Having dates pre-announced well in advance allows the community to sync their work with it14:46
*** pyhole has joined #openstack-dev14:46
ttxnotmyname: the second is that the project release schedule appears to be solely driven by RAX operational needs14:46
ttxnotmyname: those two aren't critical in any way, but they definitely affect the ability to grow a community long-term14:46
ttxnotmyname: that's just my opinion, as PTL you can choose what suits you best -- if you want more input maybe we can defer the decision until today's meeting14:47
notmynamettx: ack. I've been talking to a few people around here too about it (still RAX, but not cloud files/swift people). give me a few minutes and I'll carry on with the conversation. I'd like to make a decision on it this morning14:57
ttxnotmyname: ack14:57
*** bcwaldon has joined #openstack-dev15:06
*** Zangetsue has quit IRC15:11
*** reidrac has quit IRC15:14
notmynamettx: ok, I'm ready15:28
ttxo/15:28
notmynameI've talked to a bunch of people now. just wanted to get a variety of opinions15:29
notmynamebut it doesn't make a choice much easier since most of them are fine with either one ;-)15:30
*** heckj has joined #openstack-dev15:30
ttxnotmyname: I think it all boils down to whether this will happen again (and I see no reason why it wouldn't ?)15:31
ttxIf it's a one-off, better hav ethe release in the open so that there is no "internal release"15:31
*** johnpur has joined #openstack-dev15:31
*** ChanServ sets mode: +v johnpur15:31
ttxIf RAX needs to ability to "trigger" Swift internal releases with a one week notice, then having a parallel schedule for te project would be preferable IMHO15:32
notmynameunfortunately, that's what we're trying to get away from. for the sake of both RAX and the community, we want to have our releases be all in the open. this gives RAX operational simplicity and the community a "stamp of approval" since RAX is running it at scale in production15:33
ttxbecause in the long run, doing so repeatedly will probably prevent a community to build around  the project15:33
ttxnotmyname: do you think what happens now (the need to release with one-week notice) is exceptional, or will be the rule ?15:33
notmynamebut right now, the dev community for swift /is/ rackspace. we don't have others contributing code15:34
notmynameI think it's unusual. but not so much that it will /never/ happen again15:34
ttxnotmyname: It's a chicken-and-egg issue, you won't have a community is the project is seen as RAX pet project :)15:34
ttxnotmyname: If it's unusual, probably better to release 1.4.1 next week15:35
ttxif it happens again and again, we could revise that decision and the need for something else15:35
notmynamewhy would a frequent release prevent others from contributing code?15:35
ttxit's not about frequence. it's the one week notice.15:35
ttxnotmyname: if you say: "I release every two weeks" a community can sync on that plan15:35
ttxIf you say, "I don't know, you'll be warned one week in advance", nobody can sync their own work on that.15:36
notmynamefor deployers, yes. for coders, I don't think that holds15:36
ttxnotmyname: agreed that it's less of a problem for developers... But those need to come from somewhere, and that sopmwehere is probably a company deploying it.15:37
ttxnotmyname: I don't really want to argue with you over that -- I'm fine with your decision, and as I said we'll see if it happens so often that my concern about community would be relevant.15:38
ttxIf it remains "unusual" and the release schedule is "mostly predictable" I guess a community can strive with that15:39
notmynameI'll be trying to reach out to some more of the deployers soon. I'm trying to give as much advance notice as possible to the community for swift releases15:41
notmynamethose 2 sentences are actually 2 separate thoguhts15:41
notmynameok. based on your feedback and the feedback I have from the others I have talked to, I think we should target 1.4.1 for next week on June 2015:42
ttxnotmyname: ok, when do you want to have the branch point for the milestone-proposed branch ?15:43
ttxFriday morning ?15:43
ttxor earlier ?15:43
daboannegentle: Hey, I found a great new documentation tool: http://www.asciiflow.com/15:43
annegentledabo: ha! fun.15:44
notmynamettx: it should be the current trunk tip15:45
notmynamettx: all the necessary changes have landed15:45
notmynamettx: well, except for any versioning/changelog updates15:45
notmynameI don't remember if they need to go in before or after the branch15:45
ttxnotmyname: the changelog needs to go before, the versioning needs to go after15:46
notmynameok15:46
notmynamettx: we'll get the changelog updated and merged asap15:47
notmynamettx: thanks. btw, I do feel bad that this is coming with so little notice :-)15:47
ttxnotmyname: basically, when you're OK with it you can push ("1.4.2",False) to trunk, and I'll merge from the previous rev15:47
notmynamettx: great. will do15:47
ttxI need to merge trunk into milestone-propsoed, but I can do it from the last "1.4.1" revision from trunk.15:48
ttxnotmyname: raw notes at: http://wiki.openstack.org/HowToRelease ("External milestone release")15:48
notmynamethank you15:48
*** BK_man has quit IRC15:48
ttxnotmyname: i'll propose-merge trunk into milestone-proposed tomorrow morning if everything is ok.15:49
ttxnotmyname: want me to update the planned release date on 1.4.1 in LP ?15:50
notmynamettx: sure. one less thing for me to do then :-)15:51
heckjdabo: damn, that's a great little tool!15:51
ttxnotmyname: should I create a "1.4.2" for future targeting, without a release date atm ?15:53
ttxnotmyname: then maybe you can review the blueprints on https://launchpad.net/swift/+milestone/1.4.1 and retarget them if they will hit 1.4.2 rather than 1.4.115:53
notmynameya, but it looks like I've got 2 things that need to land for 1.4.1 first.15:54
notmynameyes, I'll update bugs/blueprints15:54
ttxnotmyname: ok, take your time, I create 1.4.2 for future reference15:54
*** BK_man has joined #openstack-dev15:56
openstackjenkinsProject nova build #1,004: SUCCESS in 2 min 54 sec: http://jenkins.openstack.org/job/nova/1004/15:59
openstackjenkinsTarmac: Cleaned up pep8 errors using the current version of pep8 located in pip-requires. This is to remove the cluttered output when using the virtualenv to run pep8 (as you should). This will make development easier until the virtualenv requires the latest version of pep8 (see bug 721867).15:59
uvirtbotLaunchpad bug 721867 in nova "Use latest pep8 in pip-requires" [Undecided,Incomplete] https://launchpad.net/bugs/72186715:59
*** pyhole has quit IRC16:01
*** pyhole has joined #openstack-dev16:01
openstackjenkinsProject nova-tarball-bzr-delta build #251: STILL FAILING in 12 sec: http://jenkins.openstack.org/job/nova-tarball-bzr-delta/251/16:04
openstackjenkinsTarmac: Cleaned up pep8 errors using the current version of pep8 located in pip-requires. This is to remove the cluttered output when using the virtualenv to run pep8 (as you should). This will make development easier until the virtualenv requires the latest version of pep8 (see bug 721867).16:04
uvirtbotLaunchpad bug 721867 in nova "Use latest pep8 in pip-requires" [Undecided,Incomplete] https://launchpad.net/bugs/72186716:04
*** zaitcev has joined #openstack-dev16:13
*** bsa has joined #openstack-dev16:26
*** bsa has quit IRC16:29
*** Tv has joined #openstack-dev16:30
*** bsa has joined #openstack-dev16:30
jaypipesmarkwash: around?16:31
openstackjenkinsProject swift build #278: SUCCESS in 29 sec: http://jenkins.openstack.org/job/swift/278/16:31
openstackjenkinsTarmac: rename st to swift16:31
*** mgius has joined #openstack-dev16:31
jaypipesbcwaldon: heya, ping me when you get a chance.. want to skype about the serializer stuff with you and markie mark.16:35
bcwaldonjaypipes: Definitely. Maybe around 1:30?16:37
bcwaldonjaypipes: or 2, markie mark is complaining16:37
jaypipesbcwaldon: coolio. just ping me when you're ready. :)16:37
markwashjaypipes: 2 is good for me. . go eastern!16:38
jaypipesmarkwash: yeppers. 2 it is. and EST rocks.16:38
markwashjaypipes: more like EDT! zing!16:38
markwash:-)16:39
notmynamettx: 1.4.2 marked as approved, just waiting on lp16:44
openstackjenkinsProject swift build #279: SUCCESS in 28 sec: http://jenkins.openstack.org/job/swift/279/16:47
openstackjenkinsTarmac: updated changelog for 1.4.116:47
*** jdurgin has joined #openstack-dev17:00
*** bcwaldon has quit IRC17:33
*** markvoelker has quit IRC17:36
*** markvoelker has joined #openstack-dev17:41
*** pyhole has quit IRC17:52
*** pyhole has joined #openstack-dev17:52
notmynamettx: why did I get "No approved revision specified." from hudson?18:00
notmynamettx: https://code.launchpad.net/~notmyname/swift/1.4.2-dev/+merge/6457318:00
*** bcwaldon has joined #openstack-dev18:03
*** markvoelker has quit IRC18:11
*** markvoelker has joined #openstack-dev18:13
*** mcclurmc_home has joined #openstack-dev18:27
ttxnotmyname: no clue... Try again, if it fails again we'll ping mtaylor18:31
creihtexlt: you around?18:45
*** nati has joined #openstack-dev18:54
natiHi all. CI meeting is here?18:57
ttxnati: in #openstack-meeting.18:58
natiThank you!18:59
notmynamettx: trying again19:05
*** dprince has joined #openstack-dev19:06
ttxnotmyname: worked.19:08
openstackjenkinsProject swift build #280: SUCCESS in 27 sec: http://jenkins.openstack.org/job/swift/280/19:16
openstackjenkinsTarmac: bumped version to 1.4.219:16
notmynamettx: yay19:16
*** bcwaldon_ has joined #openstack-dev19:38
*** bcwaldon_ has quit IRC19:39
*** bobS has joined #openstack-dev19:39
sorenEr... wtf is this? https://github.com/crashsite/swift_debian19:40
*** dfg has joined #openstack-dev19:42
*** bsa has quit IRC19:43
*** bobS has quit IRC19:43
notmynamesoren: pretty much what it says in the description19:44
*** bsa has joined #openstack-dev19:44
sorenWhy does it exist?19:44
sorenWhy do we have two different efforts to do this packaging?19:44
gholtI'll forward you the email from John Purrier.19:46
sorenPlease do.19:46
gholtAre you soren@ubuntu.com or the other .dk one, or?19:46
*** glange has joined #openstack-dev19:46
sorenThey all land in the same place, so whichever.19:47
gholtOh, 'cause I have been sending you stuff regarding that git repo since May 26th at the least. :)19:47
sorenPerhaps GMail doesn't find your e-mails sufficiently interesting.19:47
gholtNice, thank you.19:48
sorenGMail. Not me :)19:48
gholtSo hard to detect tone over IRC, heh.19:49
sorenSorry :)19:49
gholtSummation: We're going to be making packages for Rackspace Cloud Files anyway; so we'd love to share those; but they aren't official OpenStack; so they're there. Same as, say, Red Hat or SUSE or w/e.19:50
ttxgholt: except that they seem to imply the "official packaging" is insufficient for some reason ?19:51
sorenThat's so not the same thing.19:51
gholtI really don't want to go through all this once again.19:51
sorenWE can't share packaging code with the RedHat people, because it's a completely different system.19:51
gholtYou guys may if you'd like.19:51
notmynamethis was discussed on the mailing list and resolved in early may19:51
ttxgholt: I must have missed the first occurence of that discussion. /me reads back19:52
sorenThere's no way in heck I'd have OK'ed a resolution that meant there would be two *completely* separate efforts to package Swift. Not if I had understood what was being said, at least.19:53
sorenThis is ridiculous. If *Rackspace* of all companies isn't even using the official packages, how on earth are we supposed to expect anyone else to take them seriously?19:54
* ttx could use a pointer to that discussion19:54
*** scotticus has joined #openstack-dev19:54
notmynamettx: started with an email from John Purrier on May 6 with a subject of "Swift PPAs"19:55
sorenhttps://lists.launchpad.net/openstack/msg02214.html19:55
sorenWhoops, sorry.19:55
sorenNot that one.19:56
sorenhttps://lists.launchpad.net/openstack/msg02213.html19:56
ttxnotmyname: found it, started with an email from soren apparently.19:56
ttxgholt: makes a bit more sense with context, thanks.19:58
sorenWeird. This one never reached me: https://lists.launchpad.net/openstack/msg02279.html19:58
ttxsoren: too bad, that's the important one. Did you get the one from john after that one ?19:59
ttx(purrier)19:59
openstackjenkinsProject nova build #1,005: SUCCESS in 2 min 56 sec: http://jenkins.openstack.org/job/nova/1005/19:59
openstackjenkinsTarmac: Changed requests with malformed bodies to return a HTTP 400 Bad Request instead of a HTTP 500 error.19:59
sorenI did.19:59
*** dolphm has joined #openstack-dev19:59
soren...but I never expected "Gholt/Notmyname own the Rackspace specific deployment issues and will maintain the Rackspace Cloud specific packages." would mean that the Rackspace Cloud Files team would completely ignore the official packages and packaging code and just do their own thing.20:03
openstackjenkinsProject nova-tarball-bzr-delta build #252: STILL FAILING in 12 sec: http://jenkins.openstack.org/job/nova-tarball-bzr-delta/252/20:04
openstackjenkinsTarmac: Changed requests with malformed bodies to return a HTTP 400 Bad Request instead of a HTTP 500 error.20:04
sorenJust glancing at the changes being applied to that github repo, all of it seems completely generic and not Rackspace Cloud specific at all.20:04
heckjis there a tag for the diablo-1 cut on lp:nova?20:07
gholtsoren: I do keep emailing you the diffs as we make them and try to follow what being changed on your side. Perhaps you're not getting those emails either?20:10
sorengholt: E-mails with patches (rather than merge proposals) get filed differently (I've been assuming they were just e-mails from Launchpad telling me about updates to lp:swift).20:13
sorengholt: So I may have them filed away somewhere.20:13
heckjttx: when we cut the diablo-1 nova release, was that tagged? branched? (trying to reproduce from source)20:13
sorenheckj: Trouble is, it wasn't cut from trunk.20:13
sorenheckj: It was cut from a milestone-propesed branch.20:14
heckjsoren: Ah!20:14
mtaylorsoren: wasn't that branch merged back in to trunk?20:14
heckjI've been looking in the wrong place then!20:14
ttxheckj: maybe clearer with http://wiki.openstack.org/BranchModel (or not)20:15
mtaylorttx: hrm. ok. somehow I missed that20:15
mtaylorttx: why in god's name would we not merge the milestone-proposed branch back to trunk?20:15
* mtaylor should maybe just shut up and go back in to his hole20:16
sorenmtaylor: Because noone has bothered to.20:17
heckjttx: thanks - exactly what I needed20:18
mtaylorsoren: ok. so it's not policy that we _don't_ do that?20:18
sorenmtaylor: It also looks a bit silly. In the ideal world (where nothing except "Final = False" changes on the milestone-proposed branch after branching it off), the merge back would be an empty diff.20:18
heckjttx: when we cut diablo-2, will that be tagged in lp:~hudson-openstack/nova/milestone-proposed?20:18
ttxheckj: yes.20:19
mtaylorsoren: not entirely - it would merge the tag back in to trunk20:19
ttxdiablo-& was tagged there20:19
ttxdiablo-1 even20:19
sorenmtaylor: The merge prop would look empty.20:33
mtaylorah yes20:33
mtaylorgood point20:33
*** markwash has quit IRC20:44
*** dprince has quit IRC20:46
*** markwash has joined #openstack-dev20:55
ttxmtaylor: also the value of a tag that doesn't apply to a straight revision of trunk is debatable.20:55
ttxafter all, it's not the branch the release was cut from, technically.20:55
mtaylordoesn't matter- tags can apply to sub-revisions20:55
mtaylorand if you then pulled/branched to that tag version, you'd get a tree that was the tree that was cut from20:56
mtaylorBUT20:56
ttxMeeting in 5 minutes in #openstack-meeting20:56
*** nati has quit IRC20:56
mtaylortotally not worth stuff20:56
*** ohnoimdead has joined #openstack-dev20:57
*** nati has joined #openstack-dev20:57
*** dolphm has quit IRC21:04
*** bcwaldon has quit IRC21:06
*** bcwaldon has joined #openstack-dev21:07
openstackjenkinsProject nova build #1,006: SUCCESS in 3 min 2 sec: http://jenkins.openstack.org/job/nova/1006/21:19
openstackjenkinsTarmac: Phew ... ok, this is the last dist-scheduler merge before we get into serious testing and minor tweaks. The heavy lifting is largely done.21:19
openstackjenkinsThis branch adds an OS API POST /zone/boot command which returns a reservation ID (unlike POST /servers which returns a single instance_id).21:19
openstackjenkinsThis branch requires v2.5 of python-novaclient21:19
openstackjenkinsAdditionally GET /servers can now take an optional reservation_id parameter, which will return all the instances with that reservation ID across all zones.21:19
*** glenc has quit IRC21:21
*** glenc has joined #openstack-dev21:22
*** johnpur has quit IRC21:23
openstackjenkinsProject nova-tarball-bzr-delta build #253: STILL FAILING in 11 sec: http://jenkins.openstack.org/job/nova-tarball-bzr-delta/253/21:25
openstackjenkins* Tarmac: Changed requests with malformed bodies to return a HTTP 400 Bad Request instead of a HTTP 500 error.21:25
openstackjenkins* Tarmac: Phew ... ok, this is the last dist-scheduler merge before we get into serious testing and minor tweaks. The heavy lifting is largely done.21:25
openstackjenkinsThis branch adds an OS API POST /zone/boot command which returns a reservation ID (unlike POST /servers which returns a single instance_id).21:25
openstackjenkinsThis branch requires v2.5 of python-novaclient21:25
openstackjenkinsAdditionally GET /servers can now take an optional reservation_id parameter, which will return all the instances with that reservation ID across all zones.21:25
openstackjenkinsProject nova build #1,007: SUCCESS in 2 min 57 sec: http://jenkins.openstack.org/job/nova/1007/21:29
openstackjenkinsTarmac: Changed requests with malformed bodies to return a HTTP 400 Bad Request instead of a HTTP 500 error.21:29
*** bcwaldon has quit IRC21:29
*** ohnoimdead has quit IRC21:29
*** ameade has quit IRC21:30
*** glange has left #openstack-dev21:39
*** nati has quit IRC21:40
*** troytoman-away is now known as troytoman21:53
*** vladimir3p has quit IRC21:53
*** ecarlin has joined #openstack-dev22:04
*** zedas has quit IRC22:05
*** dragondm has quit IRC22:12
*** vladimir3p has joined #openstack-dev22:19
*** mcclurmc_home has quit IRC22:20
openstackjenkinsProject nova build #1,008: SUCCESS in 2 min 54 sec: http://jenkins.openstack.org/job/nova/1008/22:29
openstackjenkinsTarmac: Updated so that we use a 'tmp' subdirectory under the Xen SR when staging migrations. Fixes an issue where you would get a 'File exists' error because the directory under 'images' already existed (created via the rsync copy).22:29
openstackjenkinsProject nova-tarball-bzr-delta build #254: STILL FAILING in 11 sec: http://jenkins.openstack.org/job/nova-tarball-bzr-delta/254/22:34
openstackjenkinsTarmac: Updated so that we use a 'tmp' subdirectory under the Xen SR when staging migrations. Fixes an issue where you would get a 'File exists' error because the directory under 'images' already existed (created via the rsync copy).22:34
*** ecarlin has quit IRC22:51
*** markvoelker has quit IRC22:52
*** bsa has quit IRC22:52
*** troytoman is now known as troytoman-away23:43

Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!