Wednesday, 2011-08-24

*** anotherjesse has quit IRC00:21
*** anotherjesse has joined #openstack-dev00:21
*** nati has quit IRC00:32
*** hisaharu has quit IRC00:36
anotherjesseheyo mtaylor - around?00:38
jeblairguess not00:39
mtaylorhey00:40
jeblairhiya!00:40
jeblair17:36 <anotherjesse> recipes don't even finish because people change stuff without notifying anyone00:40
jeblair17:37 <anotherjesse> do we:00:40
jeblair17:37 <anotherjesse> make puppet log to syslog00:40
jeblair17:37 <anotherjesse> and store a syslog of the install and run - so that we can see errors?00:40
anotherjessemtaylor: I was helping jeblair work on why keystone wasn't installing00:41
anotherjessemtaylor: and relaying that a major reason tests fail is because the deploy doesn't finish due to changes in how things should interact00:41
mtayloryes ... this is fun :)00:41
anotherjesseif jenkins just blows away the env when deployment fails - is there a standard way of storing logs or ?? so we can see that?00:41
jeblairso we can probably have the nodes syslog to the jenkins slave, so we'll have the info there00:42
mtayloryes- if we can report them back, jenkins will keep them00:42
jeblairbut how will they be stored?00:42
mtaylorwhat would be GREAT is if we could have the nodes syslog to the slave AND cat to stdout/stderr on the slave while that's running00:42
mtayloressentially, in the jenkins job - when we run "./deploy_stuff.sh" ... anything that prints to the screen will get stored as the job log in jenkins00:43
anotherjesseYES00:43
jeblairi imagine we should be able to do something like that, especially if we do it during the build phase, before the test job actually kicks off00:43
mtaylorso if we can have deploy_stuff kick the machines and then stream their output, I think we'll have win00:43
anotherjesseI think at one point we had 2 different jobs00:44
anotherjessedeploy00:44
mtaylorextra bonus points come later when we write a jenkins output parsing thing to pick out errors and highlight them and stuff, but just having the log at all for now would be big win00:44
anotherjessetest00:44
mtayloryeah - a deply and then a test.00:44
anotherjesseand test had a pre-req of deploy00:44
*** novas0x2a|laptop has quit IRC00:44
anotherjesseoh - so jeblair said you might have an updated package for the keystone?00:44
jeblairthat makes sense.  so we stream the logs till that's done.  how did you determine when deploy was complete?00:44
mtayloryup. and then if we use a lock/latch to make sure that another deploy doesn't run before the test is done ... but yeah00:44
mtayloranotherjesse: I do, I was going to upload it here in just a bit00:44
mtayloranotherjesse: (that's tied up based on an email I was just about to send you, actually)00:45
anotherjessecan you shove it somewhere I can download - wget is good with me00:45
anotherjesseno apt needed00:45
mtayloranotherjesse: k. will do00:45
mtaylorjeblair: well... for determining the deploy is done ...00:45
mtaylorjeblair: w you could have the nodes get/post to a url on the slave (for instance) at the end of the deploy run00:46
anotherjessejeblair: when the deploy.sh fails or succeeds - with test-signals?00:46
znsmtaylor: is there something we need to do to have it show up on the LP page for Keystone? Or is that what you are working on?00:46
mtaylorzns: yes. working on that right now00:46
anotherjessezns: you can actually add yourself00:46
znsmtaylor: cool!00:46
anotherjessezns: we know because devcamcar added dash to openstack too early00:47
anotherjesseI had admin - updated!00:47
jeblairwell the real end of the deployment is when the machines have booted, installed an os, openstack, and started services...00:47
znsanotherjesse: I started down that path but decided not to do double work. Was waiting on mtaylor or soren.00:48
anotherjessejeblair: but should the deploy_stuff be responsible for it00:48
anotherjessejeblair: it can "spin00:48
anotherjesseright?00:48
anotherjesse(I say this because when we add other architectures/deployments we don't want the main CI system to have to know how to check for each type of deploy00:49
mtaylorzns: yes. I shall get a thing sorted for you on that by the end of the evening00:49
jeblairso all the deploy script really needs to do is hit djeep's reboot url00:50
jeblairand then we just wait some amount of time, and the openstack should be running00:50
znsmtaylor: no rush, but thank you!00:50
jeblairbut i'm not sure when we decide that is done (it's especially complicated since openstack might not actually end up running)00:50
anotherjessejeblair: well - the end of a preseed includes a post-inst instruction00:50
anotherjessejeblair: that usually (in cobbler as well) makes a http call to say I'm done00:50
jeblairbut puppet has to run too00:51
anotherjessejeblair: but then a reboot and puppet run00:51
anotherjessejeblair: ya00:51
anotherjessejeblair: so in this cause the deploy_djeep.sh would probably check via looking for a successful puppet run on each box00:51
anotherjessethen return success00:51
jeblairwe could do that by watching syslog messages00:51
anotherjesseand timeout after X minutes (probably set by CI environment - deploy arch X with script Y in time Z)00:52
anotherjessejeblair: each script can do their own thing… so sure syslog messages!00:52
anotherjessemtaylor: eta on deb00:53
anotherjessedon't make me package it myself ;p00:53
anotherjessejeblair: actually - let's not wait on keystone00:57
jeblairok00:58
anotherjessesince the CI part doesn't care if the install worked - it is actually bettter that it didn't00:58
anotherjessesince we need to gather up and report that it didn't00:58
jeblairkong looked like it was trying to talk to keystone00:58
jeblairit hung on: connect(3, {sa_family=AF_INET, sin_port=htons(5000), sin_addr=inet_addr("10.0.0.100")}, 1600:58
anotherjessejeblair: right - but at this moment the important thing for CI to do:00:58
jeblairwhile running test_002_verify_nova_auth00:58
anotherjessereport an error on deployment with all the logs00:59
anotherjessesince this will happen DAILY00:59
anotherjessekeystone (working on 2.0 api), nova (breathing), glance (adding private images)00:59
anotherjesseeach cause the recipes to be broken00:59
jeblairokay, we can focus on the deploy+syslog stuff then00:59
anotherjesseand we need to make sure jenkins captures the logs and share them00:59
anotherjessesince in my opinion - you are done except the error logs right?01:00
anotherjesseif you have it so it is able to kick the boxes, then either capture the status of the deploy with nice logs01:00
anotherjessethen if success run the tests01:00
jeblairerror logs, wait for completion, and probably a mutex around the whole thing to prevent multiple runs01:00
anotherjesseyou don't care what the recipes are01:00
*** dragondm has quit IRC01:00
anotherjessejeblair: ya01:00
anotherjessethanks be to a broken package - we are unblocked! ;p01:01
jeblair:)01:01
*** thor_ has joined #openstack-dev01:01
jeblairanotherjesse: thanks for your help01:01
*** troytoman is now known as troytoman-away01:02
jeblairi'm about to head out to dinner, so i'll probably resume this tomorrow.  i'll let you know when i have that working01:02
mtayloranotherjesse: just realized my packages were old - rebuilding - emailing in a sec01:02
mtayloranotherjesse: oh - maverick ok?01:03
jeblairmtaylor: maverick is what the nodes are running01:04
anotherjessemtaylor: maverick is good01:04
*** nati has joined #openstack-dev01:11
*** mfer has joined #openstack-dev01:16
*** mfer has quit IRC01:16
*** anotherjesse has quit IRC01:20
*** jakedahn has quit IRC01:28
*** thor_ has quit IRC01:39
*** rods has quit IRC02:10
*** jakedahn has joined #openstack-dev02:12
*** zns has quit IRC02:22
*** ecarlin has joined #openstack-dev02:44
*** anotherjesse has joined #openstack-dev02:54
*** ecarlin has quit IRC03:11
*** ecarlin has joined #openstack-dev03:14
*** anotherjesse has quit IRC03:14
*** zns has joined #openstack-dev03:22
*** vladimir3p has quit IRC03:27
*** mdomsch_ has joined #openstack-dev03:52
*** ecarlin has quit IRC04:07
*** ecarlin has joined #openstack-dev04:07
*** ecarlin has quit IRC04:18
*** jakedahn has quit IRC04:50
*** zaitcev has quit IRC04:59
*** zns has quit IRC05:13
*** mdomsch_ has quit IRC05:20
*** tsuzuki_ has joined #openstack-dev05:47
*** openpercept_ has joined #openstack-dev06:03
*** nati has quit IRC06:10
*** nati has joined #openstack-dev06:38
*** reidrac has joined #openstack-dev06:54
*** mszilagyi has joined #openstack-dev07:00
*** openpercept_ has quit IRC07:02
*** nickon has joined #openstack-dev07:16
*** mnour has joined #openstack-dev10:23
*** mnour has quit IRC10:28
*** rods has joined #openstack-dev10:32
*** nickon has quit IRC10:39
*** mnour has joined #openstack-dev10:41
*** tsuzuki_ has quit IRC10:54
*** markvoelker has joined #openstack-dev11:22
*** mdomsch has quit IRC11:44
*** Adri2000 has quit IRC11:58
*** bsza has joined #openstack-dev12:02
ttxsoren: there are a number of posted bugs in Nova around security groups -- since you recently touched that area, could you help triage those bugs ? Search for "authorize", "source", or "group" to find them12:10
*** lts has joined #openstack-dev12:16
*** mfer has joined #openstack-dev12:17
*** Adri2000 has joined #openstack-dev12:18
*** zul has quit IRC12:25
*** zul has joined #openstack-dev12:30
*** zul has quit IRC12:39
sorenttx: I'll see if I can squeeze it in today.12:40
*** zul has joined #openstack-dev12:52
*** zul has quit IRC12:55
*** zul has joined #openstack-dev12:55
*** ewindisch has quit IRC13:09
*** mattray has joined #openstack-dev13:10
*** joesavak has joined #openstack-dev13:32
*** jsavak has joined #openstack-dev13:32
*** zns has joined #openstack-dev13:38
*** joesavak has quit IRC13:44
*** joesavak has joined #openstack-dev13:44
*** lorin1 has joined #openstack-dev13:44
*** jsavak has quit IRC13:44
*** jsavak has joined #openstack-dev13:44
*** lorin1 has left #openstack-dev13:45
*** ameade has joined #openstack-dev13:48
sandywalsh_0x44, is this a wip? https://github.com/rackspace/python-novaclient/pull/6613:56
*** bcwaldon has joined #openstack-dev13:57
*** ecarlin has joined #openstack-dev14:12
jaypipesDaviey: ping.14:16
jaypipessandywalsh: what, you can't tell from the pull request status? ;)14:17
*** markmc has joined #openstack-dev14:18
*** alekibango has joined #openstack-dev14:18
Davieyjaypipes: hola14:21
sandywalshjaypipes, yeah, if only we had some system we could use that worked with github and give us a workflow ... hmm14:22
sandywalsh*gave14:22
*** misheska has joined #openstack-dev14:24
*** alekibango has quit IRC14:29
*** alekibango has joined #openstack-dev14:30
openstackgerritJustin Shepherd proposed a change to openstack/glance: Bug lp:829654  https://review.openstack.org/33114:30
openstackgerritJustin Shepherd proposed a change to openstack/glance: Bug lp:829654  https://review.openstack.org/33114:33
*** code_franco has joined #openstack-dev14:37
*** martine has joined #openstack-dev14:38
jaypipesjeblair: any reason the above notification from gerrit is doubled up? ^^14:39
*** amccabe has joined #openstack-dev14:45
jaypipesOutlook Web Access, I want to strangle thee with a garden hose.14:47
jeblairjaypipes: second patchset.  We could probably have gerritbot add more words to indicate patchset numbers14:47
jaypipesjeblair: ah, I see. yes, that would be terrific. low priority, backburner, etc etc14:48
jeblairjaypipes: noted14:49
*** dragondm has joined #openstack-dev14:55
*** rnirmal has joined #openstack-dev14:55
openstackgerritA change was merged to openstack/glance: Bug lp:829654  https://review.openstack.org/33115:03
openstackgerritJustin Shepherd proposed a change to openstack/glance: Bug lp:829064  https://review.openstack.org/33215:03
*** reidrac has quit IRC15:05
*** rnirmal has quit IRC15:05
*** rnirmal has joined #openstack-dev15:05
openstackgerritA change was merged to openstack/glance: Bug lp:829064  https://review.openstack.org/33215:14
*** nati has quit IRC15:18
*** RobertLaptop has quit IRC15:21
annegentlemtaylor: can you help me figure out why a build is working but the FTP is copying 0 files?15:28
_0x44sandywalsh: Yes, that is. You can close it since I need to rebase it on top of other changes that have been merged and I'll resubmit.15:29
bcwaldonjaypipes: question about FF15:32
jaypipesbcwaldon: shoot15:33
bcwaldonis it just features we are blocking from trunk, or everything?15:33
jaypipesbcwaldon: just features.15:33
*** vladimir3p has joined #openstack-dev15:33
bcwaldonjaypipes: cool, so something like this can go in fine: https://code.launchpad.net/~ken-pepple/nova/lp828600/+merge/7231915:33
jaypipesbcwaldon: and I've already moved all non-Implemented features out to RPB milestone.15:33
jaypipesbcwaldon: for glance, that is.15:33
jaypipesbcwaldon: absolutely on kpepple_'s mp.15:34
bcwaldoncool15:34
bcwaldonthere are a bunch of those15:34
bcwaldonjaypipes: things that I approve now to get into trunk won't go into d4 without being re-proposed to milestone-proposed, right?15:37
jaypipesbcwaldon: that is correct.15:37
bcwaldonso what's the point of FF?15:37
jaypipesbcwaldon: so that features can continue to go into trunk15:37
jaypipesbcwaldon: it's just that features don't go into the milestone proposed branch, which was cut early yesterday morning...15:38
bcwaldonoh okay, so anything can go into trunk, but it needs ffe to make it into milestone-proposed15:38
jaypipesbcwaldon: just have to keep an eye on where the merge proposal is targeted to go to :)15:38
jaypipesbcwaldon: exactly.15:38
bcwaldonjaypipes: cool, thanks bud15:39
jaypipesnp problem.15:39
*** anotherjesse has joined #openstack-dev15:40
ttxjaypipes, bcwalson: well, not exactly15:40
ttxFF is about handling the post-D4 pre-release period15:41
ttxi.e. we shoudn't introduce new features after the last milestone15:41
ttx(or at least, not disrupting features)15:41
jaypipesttx: isn't that what I said above? :)15:42
ttxjaypipes: hmm, no15:42
ttxbcwaldon> oh okay, so anything can go into trunk, but it needs ffe to make it into milestone-proposed15:42
ttxthat's wrong ^15:42
bcwaldonttx: please correct me, as I jsut approved some testing branches15:43
ttxok, I explain15:43
ttxrather than cutting the release branch at D4, we decided to keep trunk open for two weeks after D415:43
ttxuntil "RBP"15:44
ttxAt Release Branch Point, we cut a release branch on which only critical bugfixes land.15:44
ttxand we open Essex15:44
*** anotherjesse has quit IRC15:44
ttxbetween D4 and RBP though, we need to be careful with what lands in trunk15:44
jaypipesttx: yes, I understand that, but I was specifically referring to D4's milestone-proposed branch, not the RBP.15:44
ttxbetween D4 and RBP, only features that get the PTL go-ahead (i.e. targeted to diablo-rbp) should be accepted15:45
jaypipesttx: i.e. the branch we will be releasing tomorrow morning?15:45
ttxbugfixes branch can go in without issue15:45
*** zns has quit IRC15:45
jaypipesttx: right, but doesn't that start *after* D4 is released tomorrow?15:45
jaypipesttx: or did that start when the milestone-proposed branch for D4 was cut?15:46
ttxjaypipes: it did start when the milestone branch was cut15:46
ttxThe idea is to have "most new features" in the last milestone.15:46
ttxif you add them to trunk after the D4 milestone branch is cut... that defaets the purpose15:47
*** mnour has quit IRC15:47
ttxSo in summary:15:47
jaypipesttx: ok, sorry bcwaldon, I thought that was starting *after* D4 was released. my bad.15:47
ttxCurrently:15:47
jaypipesttx: yes, I suppose you are right. just confiusion on my part. sorry.15:47
bcwaldonall I was worried about here was whether I could send in bugfix branches, so I think I'm good there15:47
ttxRBP-targeted features, and any bugfix can land to trunk15:47
ttxD4-targeted bugs can land to milestone-proposed15:48
ttxAfter D4 is released:15:48
ttxRBP-targeted features, and any bugfix can land to trunk15:48
ttxBetween RBP and release:15:48
ttxanything can land to trunk15:48
ttxRC bugfixes can land to milestone-proposed15:48
ttxAfter release:15:49
ttxanything can land to trunk15:49
ttxdoes that make it clearer ?15:49
bcwaldonthe 'Between RBP and release' is still confusing15:49
bcwaldonnope, got it15:49
bcwaldonjust clicked15:49
ttxAfter RBP, you have two branches: trunk is Essex, and milestone-propsoed in the Diablo release branch15:50
openstackjenkinsProject nova build #1,289: SUCCESS in 3 min 23 sec: https://jenkins.openstack.org/job/nova/1289/15:50
openstackjenkinsTarmac: added unit tests for version.py15:50
* jaypipes apologizes for any confusion he has wrought.15:50
*** Capashen has joined #openstack-dev15:50
bcwaldonyeah, that's what I didn't realize at first15:50
bcwaldonno, i needed this spelled out anyways ;)15:50
ttxyes, that timeframe is a bit confusing... but it buys us two extra weeks for sneaking in last features :)15:51
ttx(compared to Essex opening at D4 branch cut time)15:51
CapashenHi. While testing glance (diablo), I'm having #827034 bug. Now I can't delete images with Glance any more. Is there any workaround ? Thanks15:52
jaypipesCapashen: one sec, looking...15:53
jaypipesCapashen: the workaround is in the bug report :)15:54
jaypipesCapashen: need to make a slight modification to your config files...15:54
Capashenyou mean the [filter:context] part ?15:56
bcwaldonCapashen: yep15:57
Capashenactually I have these two lines and I have the bug15:57
bcwaldonCapashen: did you restart all your glance services?15:57
CapashenI didn't modify conf file, these lines were already there15:58
*** joesavak has quit IRC15:58
bcwaldonah, okay15:58
*** jsavak has quit IRC15:58
bcwaldonjaypipes: any thoughts?15:59
jaypipesCapashen: please pastebin your two conf files. thanks!16:00
jaypipess1rp_: status on https://bugs.launchpad.net/glance/+bug/820090?16:00
uvirtbotLaunchpad bug 820090 in glance "Logging str(Exception) considered harmful" [Medium,In progress]16:00
*** joesavak has joined #openstack-dev16:01
*** jsavak has joined #openstack-dev16:01
*** hisaharu has joined #openstack-dev16:01
ttxjaypipes, vishy: do you think you can put milestone-proposed in a D4-shippable shape by the end of the day ?16:02
ttxjaypipes, vishy: if yes, just send me an email by EOD saying "ship it" and I'll do so in the morning.16:02
ttxjaypipes, vishy: if not, we can use tomorrow for the last fixes.16:03
jaypipesttx: yes. waiting on some test results from shep and sending email out on a couple bug bounties.16:03
*** nati has joined #openstack-dev16:03
ttxjaypipes: ideally you would sync with Vish, I'd rather release both at around the same time.16:04
jaypipesttx: will do.16:04
ttxdabo: I did address your comment on https://code.launchpad.net/~ttx/nova/lp820962/+merge/7271216:05
Capashenjaypipes, http://pastebin.com/Wu2zyA07 (config file), http://pastebin.com/iP6u7cZ0 (error)16:05
openstackjenkinsProject nova build #1,290: SUCCESS in 3 min 16 sec: https://jenkins.openstack.org/job/nova/1290/16:06
openstackjenkins* Tarmac: add rainy day test to to_global16:06
openstackjenkinsfixed to_global to catch correct error from incorrect mac addresses16:06
openstackjenkins* Tarmac: similar to lp828614: add rainy day test and fix exception error catch to AddrFormatError16:06
openstackjenkins* Tarmac: added unit tests for version.py16:06
openstackjenkins* Tarmac: Adds a use_deprecated_auth flag to make sure creds generated using nova-manage commands will work with noauth.16:06
daboNeed some review and feedback on: https://code.launchpad.net/~ed-leafe/nova/scheduler-multifilter/+merge/7247816:06
dabottx: approved16:07
bcwaldonttx: should that bug go into d4?16:08
ttxbcwaldon: I'd say yes, but i'll let vishy decide16:09
ttxcan't be judge and jury.16:09
bcwaldonok, I'll put a note on that bug report16:09
ttxI pmed it on it already16:09
bcwaldonok, I'll be quiet ;)16:09
*** zaitcev has joined #openstack-dev16:11
*** zns has joined #openstack-dev16:14
zykes-is a packager for el5 + 6 a wanted thing ?16:15
mtaylorDaviey: see openstack mailing list - I somehow forgot to explicitly add you to the phonebook-like list of people16:17
Davieymtaylor: bet it was intentional :P16:18
notmynamemtaylor: good post16:18
bcwaldonsoren: This branch is waiting on your review -> https://code.launchpad.net/~ken-pepple/nova/lp828596/+merge/7231016:18
notmynamemtaylor: for the record, RAX cloud files is deployed on ubuntu, but we also use our own packages ;-)16:18
kpepple_bcwaldon: i just soren on their because he asked for unittests on his blog :)16:18
mtaylornotmyname: damn. that would have been one more thing I could have added to that list :)16:19
bcwaldonkpepple_: that's fine, just wanted him to see these things get fixed :)16:19
mtaylorDaviey: and yes - it was a deliberate attack on you.16:20
Davieymtaylor: heh.. knew it..  well you failed.. I was on the CC. :)16:20
mtaylorDaviey: dammit jaypipes! stop lying to me!16:20
Davieynotmyname: Where are those branches kept, for RAX packaging?16:20
*** jsavak has quit IRC16:20
*** joesavak has quit IRC16:21
*** joesavak has joined #openstack-dev16:21
notmynamemtaylor: I kinda like the way our packages are done. use github pages (just a cool hack IMO) and we have a static repo for every version. the static repo for every version was actually at the request of cloud builders. our packages are https://github.com/crashsite/swift_debian  (http://crashsite.github.com/swift_debian/)16:21
notmynameDaviey: ^16:21
*** jsavak has joined #openstack-dev16:22
mtaylornotmyname: well - we could totally do a static repo for each version16:22
*** RobertLaptop has joined #openstack-dev16:22
mtaylornotmyname: I was already thinking static repo for each major release series, but per version would be easy enough16:22
notmynamemtaylor: one of the reasons we use our own packages is because we need to guarantee that when we rekick a box it gets a known version of the code16:23
Davieynotmyname: Doesn't look that active?16:23
mtaylornotmyname: coupla quick questions re: that ... when you say "every version" - you mean each swift release, right? not each commit-generated package16:23
mtaylornotmyname: ++ to know version of code16:23
notmynameDaviey: how do you mean? we update ot for every release we do16:23
notmynamemtaylor: ya, every release16:24
mtaylornotmyname: for the "static repo for each version" approach, you'd likely be fine with a _second_ repo for the backported depends, yah?16:24
Davieynotmyname: Ahh, you are not tracking development snapshots?16:24
jaypipesnotmyname: what about non-Lucid? Is that somewhere else?16:25
mtaylornotmyname: so, in theory, we could have trunk repo and release repo which each actually contained backported depends, and then a set of repos for each release + a depends repo? (or would you want the backported library depends in each repo?)16:25
notmynameDaviey: we ignore the openstack packaging. we do our best to make a swift release every time we deploy at RAX, but it doesn't always work for openstack16:25
bcwaldonjaypipes: gonna get the swift branch done today?16:25
bcwaldonjaypipes: I know you're swamped ;)16:25
notmynamejaypipes: no non-lucid. we target last LTS16:25
jaypipesbcwaldon: it's already done.16:25
jaypipesbcwaldon: waiting on shep to give feedback on a customer system.16:25
jaypipesnotmyname: gotcha16:25
jaypipesnotmyname: just curious :)16:25
glencant, do we have Yagi set up in Alpha yet?16:25
notmynamejaypipes: next LTS and we'll have non-lucid :-)16:26
bcwaldonjaypipes: okay, all I can go on is what's in gerrit...16:26
mtaylornotmyname: I think the static-repo-per-release is TOTALLY doable (and a great idea - I'm adding it to the list whether you use it or not :) )16:26
vishysoren: ping16:26
glencoops, wrong window. sorry16:26
notmynamemtaylor: I don't think we'd have much use for a per commit package16:26
mtaylornotmyname: no, I don't expect you would16:26
jaypipesbcwaldon: right, sorry, I'll add a comment saying "ready to re-review..."16:26
bcwaldonjaypipes: did you address the test failure?16:26
Davieynotmyname: nice patch :) https://github.com/crashsite/swift_debian/blob/master/patches/debian-changes-1.0.2-116:26
mtaylornotmyname: I'm most curious about the backported depends part and how you'd like to model that16:26
notmynamewow, I didn't expect to get this many responses ;-). unfortunately, I have a meeting I have to run off to now16:27
jaypipesbcwaldon: talking about the uneven chunk number thing?16:27
mtaylornotmyname: GAH16:27
mtaylornotmyname: I will keep bugging you about backport depends. :)16:27
openstackjenkinsProject nova build #1,291: SUCCESS in 3 min 16 sec: https://jenkins.openstack.org/job/nova/1291/16:27
openstackjenkins* Tarmac: Fix default hostname generator so that it won't use underscores, and use minus signs instead.16:27
openstackjenkins* Tarmac: - rebuilds are functional again16:27
openstackjenkins- OSAPI v1.1 rebuild will accept adminPass or generate a new one, returning it in a server entity16:27
openstackjenkins- OSAPI v1.0 will generate a new password, but it doesn't communicate it back to the user16:27
openstackjenkins* Tarmac: add rainy day test to to_global16:27
openstackjenkinsfixed to_global to catch correct error from incorrect mac addresses16:27
openstackjenkins* Tarmac: similar to lp828614: add rainy day test and fix exception error catch to AddrFormatError16:27
Davieynotmyname: I think you are getting interest, because it's the first some of us have heard about it :)16:27
bcwaldonjaypipes: no, the unittest shep pointed out related to 'checksum'16:27
notmynamemtaylor: yes, do. and ping florian too16:27
jaypipesbcwaldon: hmm, lemme check... might have not seen that.16:27
notmynameDaviey: it's not been a secret (we've talked about it here before). just something we don't really advertise16:28
bcwaldonjaypipes: and I think there are merge conflicts16:28
Davieynotmyname: oh aye. I knew you had packages..16:28
jaypipesbcwaldon: :( ok, gimme a few.16:28
bcwaldonjaypipes: cheer up, jay!16:28
redboWe also do our own packages for cloudfiles because some functionality we use has been removed from openstack packages.16:28
redboAnd occasionally someone just goes and breaks them for a week or two.  And we kind of need to be able to control those things.16:29
jaypipesbcwaldon: :(16:29
_0x44redbo: Ostensibly the purpose of CI is to keep code that breaks out of trunk, so when we get better functional testing we should be able to gate on that.16:30
jaypipesbcwaldon: just rebased to master.. no merge conflicts.16:32
bcwaldonjaypipes: hmm, maybe I was seeing things16:32
*** jsavak has quit IRC16:33
*** joesavak has quit IRC16:33
*** markmc has quit IRC16:33
*** joesavak has joined #openstack-dev16:34
*** jsavak has joined #openstack-dev16:34
s1rp_ jaypipes: not sure what the status of lp820090; i wasn't able to reproduce the issue bcwaldon was seeing with the unit-test16:35
mtaylorDaviey: tell me something ... why the HELL have people started listing python depends that look like this: 2.6.6-3~ ?16:36
mtaylorDaviey: it makes backporting things senslessly brutal16:37
bcwaldons1rp_: refresh my memory, where did I say I was seeing a failure?16:37
s1rp_bcwaldon: this was the webob version check, you had 1.8.7 of webob and the test still failed for you (even though it passed for jaypipes, jkoelker, and i)16:38
bcwaldons1rp_: We resolved that. It was the echo -n problem16:38
s1rp_bcwaldon: actually, on second thought, yeah.. exactly16:38
Davieymtaylor: Used to say > than just before X, i think.  Depends on the context. :/16:38
bcwaldons1rp_: I think this is a different bug16:38
bcwaldons1rp_: isn't this fixed?16:39
mtaylorDaviey: well ... it's giving me hives :)16:39
s1rp_bcwaldon: hmm, not sure... checking trunk16:39
bcwaldons1rp_: https://review.openstack.org/#change,19916:40
bcwaldons1rp_: that's the MP where I had the weird webob issue. The bug jay is asking about doesn't appear to have made it in yet16:40
s1rp_bcwaldon: they're the same (AFAIK), bug just didn't get marked Fix Commited16:41
bcwaldons1rp_: I'd support you in that satement :)16:41
Davieymtaylor: Good :)16:41
*** zns has quit IRC16:42
s1rp_jaypipes: bcwaldon: ok just marked lp820090 as "Fix Committed"16:42
mtaylorDaviey: https://code.launchpad.net/~mordred/swift/fix-python-depend/+merge/72753 please review me16:43
redboexhibit one: ^  :)16:44
*** blamar has joined #openstack-dev16:44
Capashenjaypipes, Do i need to comment the bug about 'is_image_visible' even if the bug is in "invalid" state ?16:52
sandywalsh_0x44, cool, will do16:52
*** mfer is now known as mfer-lunch16:55
*** zns has joined #openstack-dev16:56
*** Capashen has quit IRC16:59
zulmtaylor: dh_python2 transition is happening in oneiric17:07
mtaylorzul: ok. say words to me about that17:07
mtaylorzul: nm. found the page17:08
zulmtaylor: i can point you to a wiki page: http://wiki.debian.org/Python/TransitionToDHPython217:08
mtaylorzul: is that going to mean horrible badness for our backport things? or will the fact that we also backport debhelper be fine?17:09
mtaylorzul: OH - I see the thing in the wiki page17:10
mtaylorzul: why in the HELL do they have that version requirement?17:10
mtaylorzul: that makes me livid angry17:10
zulmtaylor: python-supprot and python-central has been deprecated17:11
zuland i cant spell17:11
mtaylorzul: that's fine. they both suck anyway17:11
*** mfer-lunch is now known as mfer17:11
mtaylorwhy does that mean I need to depend on 2.6.6-3~ though?17:11
zulim not 100% sure17:12
zulyou might have to backport debhelper, i think debian has a backport project that you might want to look at as well17:13
mtaylorthey do - but last time I checked it was not what I needed17:14
mtaylorsigh17:14
*** novas0x2a|laptop has joined #openstack-dev17:14
* mtaylor needs to have yet another bitch session about the life of an upstream dev at the next UDS17:14
mtaylorI'm guessing that this: "dh_python2: egg renaming fixed" is the reason that they're saying 2.6.6-3~ is required17:14
mtaylorthing is - I _REALLY_ don't want to maintain a backport of python in our repo17:15
mtaylornor do I want to declare a 2.6.6-3~ depend in our packaging, because then we'll need to maintain forked packaging for pre-wheezy and pre-oneiric17:15
* mtaylor may just start punching random people17:15
mtaylorzul: are you ok with not listing 2.6.6-3~ until something starts breaking?17:16
openstackjenkinsProject burrow build #34: SUCCESS in 11 sec: https://jenkins.openstack.org/job/burrow/34/17:16
openstackjenkinsTarmac: More docs for backend modules.17:16
zulmtaylor: not really because its a requirement for getting it into main17:17
*** ecarlin has quit IRC17:17
mtaylorzul: ASS ASS ASS ASS ASS17:17
mtaylorzul: (that's not at you, just at the situation)17:17
zulmtaylor: sure sure :)17:17
mtaylorok, welp- we're going to have to maintain extra forky backport branches now17:18
mtaylorBALLS ASS ASS BALLS17:18
* mtaylor is very angry at debian and ubuntu right now17:18
mtaylorVERY ANGRY17:18
mtayloras in, they can suck it angry17:18
mtaylormaking decisions that makes it significantly harder for me to release packages for something that they've called an LTS means that the LTS moniker is nothing but a joke17:19
mtaylorand should cease being used17:20
* mtaylor calms down17:23
mtaylorzul: sorry for ranting17:23
zulmtaylor: no worries17:23
Davieymtaylor: need more detail?17:23
mtaylorzul: it's just that my new proposed stuff would handle this situation gracefully, but that's off the table until the summit, which means that I will have to refactor/design something NEW in the next 3 weeks to handle this17:24
mtaylorexcept that the new thing still needs to be mostly like the old thing17:24
mtaylorDaviey: I want to punch someone in the face17:24
zulyeah suckey17:24
mtaylorDaviey: no, I GET it - I just think it was handled terribly17:25
Davieymtaylor: So, i'm still missing enough context.17:25
mtaylorDaviey: let me sum up17:25
mtaylorDaviey: oneiric main contains a hard requirement that python packages depend on python-all (>= 2.6.6-3~)17:26
mtaylorDaviey: so, if we're taking our current approach, which is package for current dev and then just make renamed packages for backports17:26
Davieymtaylor: seems so.17:26
mtaylorDaviey: then maverick and lucid backports stop working17:26
Davieymtaylor: ok17:26
zulis maverick actually supported anymore?17:26
mtaylorDaviey: I am NOT going to push new python v into the openstack ppa (because that's ridiculous)17:26
mtaylorby us it is17:27
mtaylorbut that's beside the point17:27
mtaylorbecause LUCID also breaks17:27
mtaylorand that is supported even by canonical17:27
DavieyI don't thik you need to backport python!17:27
mtaylorso the process problem remains even so17:27
mtaylorof course I don't17:27
Davieymtaylor: So.. You were on the call i had with you 2 weeks ago?17:27
mtaylorBUT - I will need to maintain divergent packaging for pre-natty17:27
Davieymtaylor: which is exactly as we agreed, no?17:28
mtaylorDaviey: no. I was on no call where we discussed divergent packaging17:28
mtaylorthe only thing we discussed on that call was packaging change approvals - and riots17:28
mtaylorI mean - it's irrelevant, because we have to do it. :)17:28
Davieymtaylor: So, we DID discuss having snapshot packages for supported releases.17:29
DavieySuch as, lp:~openstack-ubuntu-packagers/ubuntu/natty/glance/ubuntu17:29
DavieyThat banch get maintains for natty etc17:29
Davieyit's not development version, which is always tip17:29
openstackjenkinsProject nova build #1,292: SUCCESS in 3 min 10 sec: https://jenkins.openstack.org/job/nova/1292/17:29
openstackjenkinsTarmac: Fixes iscsiadm commands to run properly.17:29
mtaylorDaviey: I think we're using too many words that are too similar here17:29
Davieymtaylor: Okay, perhaps we should have made notes from that call.17:30
mtaylorDaviey: it's fair - I didn't make them either :)17:30
Davieylp:~openstack-ubuntu-packagers/glance/ubuntu <-- Always development version of ubuntu.17:30
mtaylorDaviey: yes.17:30
Davieywhen we get near or at a ubuntu release, lp:~openstack-ubuntu-packagers/ubuntu/RELEASE/glance/ubuntu gets cut17:30
mtaylorDaviey: and is used to build packages against glance trunk17:30
DavieySo we always planned to have multiple branches per release17:31
Davieya one size fits all is unlikely to work17:31
mtaylorok. that's different from that I'm talking about17:31
mtaylorand, not to be too snarky, not at all what I'm caring about at the moment17:31
Davieyis it?17:31
mtayloryes17:31
mtaylorthat's about ubuntu cutting releases and being able to maintain those moving forward17:31
Davieymtaylor: It sounds to me that you want a one-size branch for all releases, no?17:31
mtaylorwhat I'm talking about is being able to build a trunk package for an old release17:31
mtaylorwell, that's what we have right now17:32
Davieydistro releases, not openstack17:32
mtayloryes. trunk openstack for old distro17:32
Davieyso this is *exactly* what you are talking about.17:32
mtaylorwell yeah - I get the mechanism you're talking about17:32
Davieylp:~openstack-ubuntu-packagers/glance/ubuntu <-- build trunk natty packages from that, for exaple.17:32
mtaylorall I'm talking about is from a trunk packaging perspective, before there was not a technical reason to have the divergence, just a possibly organizational one17:33
Daviey^^ once natty is released.. Ubuntu does not really care about that branch.17:33
uvirtbotDaviey: Error: "^" is not a valid command.17:33
DavieyIt's purely for PPA support, aiui17:33
mtaylorDaviey: right. sorry, this is why I said we're talking about different things17:33
mtaylorbecause _I_ don't care about natty being released17:33
Davieymtaylor: Yes.. i get that.17:33
mtaylorsorry ... I feel like we're REALLY close to getting each other here :)17:34
Davieymtaylor: a quick call might help?17:34
mtaylorDaviey: possibly - all I'm saying is, I get _how_ we can do the divergent packaging branches per distro release17:34
mtaylorit's just that up until now there was no technical need on openstack's side to do so17:35
mtaylorand, other than ubuntu main inclusion, there still isn't17:35
Davieymtaylor: This was always going to happen...17:35
mtaylorbecause it's only an ubuntu main inclusion POLICY thing that's causing the divergence17:35
DavieyYou don't think openstack can support every supported release for ever, based on one branch do you?17:35
mtaylorand so I'm angry that a policy choice and not a technical one forced the diverge17:35
mtaylorno. I didn't - I knew at some point we were going to hit it - I'm just miffed at the why17:36
*** jsavak has quit IRC17:36
*** joesavak has quit IRC17:36
Davieymtaylor: I think you are putting too much weight into policy.17:37
mtaylorcause here's the thing ... build-depend: python-all (> 2.6) WILL get python > 2.6.6-3~ on oneiric - because oneiric has that version of python17:37
mtaylorso the hard depend line is meaningless17:37
mtaylorand yet makes using that control file unchanged for maverick impossible17:37
mtaylorthat's what I'm saying17:38
mtaylorit's not that GLANCE actually needs 2.6.6-3~17:38
mtaylorit doesn't17:38
mtaylorso that build depend require is encoding a need that doesn't need to be expressed because it's implicit in the platform17:38
vladimir3pfolks, any chance to get some reviews for https://code.launchpad.net/~vladimir.p/nova/volume_type_extradata/+merge/72762 This one is quite urgent as we would like to have it in till Friday. Thanks17:39
*** SpamapS has joined #openstack-dev17:41
*** joesavak has joined #openstack-dev17:45
*** jsavak has joined #openstack-dev17:45
*** zns has quit IRC17:47
chmouelsandywalsh: about python-novaclient, I have updated #74 in http://bit.ly/pcQTbX but I am not sure how to attach it properly to update the merge request. any objections for me to merge it directly in the repo17:47
chmouelor should I create a new pull req?17:48
sandywalshchmouel, I'd just make a new pull request. Easier17:48
*** zns has joined #openstack-dev17:51
openstackgerritKevin L. Mitchell proposed a change to openstack/glance: Add functional tests  https://review.openstack.org/33317:53
mtaylorchmouel, sandywalsh: speaking of python-novaclient ... who's the right contact person to talk to about getting that migrated to gerrit?17:53
chmouelnot sure tbh17:54
jaypipesVek: rock on.17:56
*** rnirmal has quit IRC17:56
zykes-hmmm, wonder if i can use openshift with openstack17:57
sandywalshmtaylor, good question ... honestly I assumed gerrit was still a WIP, so it hasn't been on our radar at all really.17:57
*** code_franco has quit IRC17:57
openstackgerritJay Pipes proposed a change to openstack/glance: Fixes LP Bug #827660 - Swift driver fail 5G upload  https://review.openstack.org/31118:00
uvirtbotLaunchpad bug 827660 in glance "Cannot store files greater than 5GB in Swift" [Critical,In progress] https://launchpad.net/bugs/82766018:00
*** Capashen has joined #openstack-dev18:01
*** ecarlin has joined #openstack-dev18:03
mtaylorsandywalsh: we've got plans for moving nova and swift both over ... glance and keystone and openstack-ci itself are fully in - it's really just a question of coordinating with you to get that moving18:04
mtaylorsandywalsh: (I know it's not a fully official project  yet - but other things seem to depend on it, which makes it official in my eyes :) )18:04
*** jsavak has quit IRC18:06
*** joesavak has quit IRC18:06
*** joesavak has joined #openstack-dev18:06
zykes-what's not a official project ?18:06
bcwaldonjaypipes: deploying your latest swift patchset to functionally test18:06
*** jsavak has joined #openstack-dev18:07
jaypipesbcwaldon: rock on.18:09
zykes-is there any .debs for diablo out ?18:20
mtaylorzykes-: tons of them - for what?18:22
zykes-swift, nova, glance18:22
zykes-guess there's nothing yet for keystone etc18:22
mtaylorpublishing today18:25
mtaylorhad to sort out a few build deps in the ppa18:25
zykes-for keystone ?18:25
zykes-ooh, nice18:25
*** mnour has joined #openstack-dev18:28
*** mfer has quit IRC18:29
*** hisaharu has quit IRC18:30
*** mfer has joined #openstack-dev18:31
jaypipesVek, _cerberus_: excellent work on the functional keystone tests. great stuff.18:33
*** hisaharu has joined #openstack-dev18:35
sandywalshmtaylor, sounds good, we certainly want to follow the herd. Is there a laundry list of the steps required anywhere?18:36
openstackgerritJay Pipes proposed a change to openstack/glance: Fixes LP Bug #827660 - Swift driver fail 5G upload  https://review.openstack.org/31118:38
uvirtbotLaunchpad bug 827660 in glance "Cannot store files greater than 5GB in Swift" [Critical,In progress] https://launchpad.net/bugs/82766018:38
*** jakedahn has joined #openstack-dev18:44
bcwaldonjaypipes: is the change in glance/api/v1/images.py going to cause any weirdness wrt image size18:45
openstackgerritA change was merged to openstack/glance: Fixes LP Bug #827660 - Swift driver fail 5G upload  https://review.openstack.org/31118:56
uvirtbotLaunchpad bug 827660 in glance "Cannot store files greater than 5GB in Swift" [Critical,In progress] https://launchpad.net/bugs/82766018:56
bcwaldonjaypipes: !18:56
openstackgerritKevin L. Mitchell proposed a change to openstack/glance: Add functional tests  https://review.openstack.org/33318:56
_cerberus_jaypipes: thanks man :-)18:59
zykes-mtaylor: was there packages for keystone coming ?19:00
*** ecarlin has quit IRC19:00
*** jsavak has quit IRC19:03
*** joesavak has quit IRC19:03
claygjaypipes, bcwaldon: in swift deleting the large object manifest doesn't delete the chunks19:03
*** zns has quit IRC19:03
bcwaldonclayg: I actually saw that too, but blamed it on cloud files acting poorly. I was having trouble with my account while testing.19:04
bcwaldonclayg: I'll file a bug19:04
claygalso the swift client put_object can read any file like object, and you can use the "content-length" kwarg to limit how much data is read19:05
bcwaldonclayg: if you think it19:05
zykes-should one run swift service vms on compute nodes? like nova nodes19:05
claygmaybe I shouldn't throw stones - it's not like I'm going to rewrite it :D19:05
bcwaldonclayg: ...'s a simple fix, I would encourage you to merge prop :)19:05
ttxvishy: yo19:10
*** joesavak has joined #openstack-dev19:12
*** jsavak has joined #openstack-dev19:12
*** zns has joined #openstack-dev19:13
ttxvishy: backporting my fix to MP19:15
*** mattray has quit IRC19:15
zykes-MP ?19:16
*** mattray has joined #openstack-dev19:17
*** zns has quit IRC19:17
ttxzykes-: milestone-proposed19:18
ttxhttp://wiki.openstack.org/BranchModel19:18
zulmtaylor: ping around still?19:18
*** med_out has joined #openstack-dev19:19
ttxvishy: for your approve pleasure at https://code.launchpad.net/~ttx/nova/mp820962/+merge/7277519:19
sandywalshso, now that Keystone has been blessed as part of Nova, does that mean the existing Nova Basic Auth will get ripped out?19:19
ttx"as part of Nova" ?19:20
*** med_out is now known as medberry19:20
medberry"as part of OpenStack"19:20
* ttx will regret "bzr lp-open"19:20
ttxsandywalsh: I think that's Vish's plan for Essex, yes19:21
jaypipesnotmyname: https://bugs.launchpad.net/glance/+bug/833285. Could use your insight...19:27
uvirtbotLaunchpad bug 833285 in glance "swift store delete only removes manifest" [High,Confirmed]19:27
notmynamejaypipes: working as designed19:29
notmynamethe manifest file is separate19:30
notmynameyou (the client) is responsible for managing the parts of a large object19:30
*** ecarlin has joined #openstack-dev19:31
jaypipesnotmyname: well, poop. :)19:31
notmynamejaypipes: one "simple" way to do it would be to HEAD the manifest, do a listing of the parts (from the x-object-manifest header), delete the parts19:32
notmynameso you don't have to keep a list of the parts19:32
jaypipesnotmyname: ya, that's what I was thinking, too...19:32
jaypipesnotmyname: coolio. I'll get that done.19:32
notmynamejaypipes: the header value is container/objectprefix, so make sure you do a prefix query for the listing (and make sure you get the full listing, not just the first <listing_limit> chunks)19:33
mtaylorzul: whazzup?19:33
zulmtaylor: can you add a openstack-dashboard tarball as well?19:34
mtaylorzul: yes.19:35
zulmtaylor: thanks19:35
openstackjenkinsProject nova-milestone build #20: SUCCESS in 19 sec: https://jenkins.openstack.org/job/nova-milestone/20/19:37
openstackjenkinsTarmac: Correcting OSAPI v1.1 rebuild19:37
openstackjenkinsProject nova build #1,293: SUCCESS in 3 min 12 sec: https://jenkins.openstack.org/job/nova/1293/19:37
openstackjenkinsTarmac: The notifiers API was changed to take a list of notifiers. Some people might want to use more than one notifier so hopefully this will be accepted into trunk.19:37
jaypipesnotmyname: will do. thx for the heads up!19:38
vishyttx: thanks19:55
*** jakedahn has quit IRC19:55
*** jakedahn has joined #openstack-dev19:56
*** jakedahn_ has joined #openstack-dev19:59
*** jakedahn_ has joined #openstack-dev19:59
*** zns has joined #openstack-dev20:01
*** jakedahn has quit IRC20:02
*** jakedahn_ is now known as jakedahn20:02
*** zns has quit IRC20:06
*** ecarlin has quit IRC20:07
bengrueWhat does "ffe" stand for?20:09
bengruef___ for essex?20:09
mtaylorbengrue: "feature freeze exception"20:09
bengruefuuuuuuuuuuuuuu for essex?20:09
medberryFeature Freeze Exception ?20:09
bengrueah.20:09
bengruethanks.20:09
zykes-mtaylor: was there packages incoming for keystone ?20:09
mtaylorzykes-: yes20:10
zykes- oh, eta ?20:10
*** ecarlin has joined #openstack-dev20:10
mtaylorzykes-: https://launchpad.net/~keystone-core/+archive/trunk20:11
mtaylorzykes-: they are queues20:11
mtaylorqueued20:11
ttxbengrue: we are slowing down on features, at least until essex opens (Sep 8)20:15
bengrueyeah, got it.20:15
bengrueI was confused until I put together the "ffe" with the "disapprove:" before it.20:16
ttxthe idea being to fix more bugs than we add, avoid last-minute regressions...20:16
bengrueNow sense is made.20:16
ttxand help the doc team getting some stable picture.20:16
ttx(and let the downstream packagers catch up)20:16
bengrueAh, Thierry!  Okay.20:17
ttxand... you got the picture :)20:17
bengrueStill mapping names to irc-names; learning the environ; etc.20:17
bengrueyeah, got it.20:17
*** Capashen has quit IRC20:20
*** mwhooker has joined #openstack-dev20:21
vishydprince: ping20:24
vishyblamar: hey is dprince around?20:27
vishybcwaldon: ^^20:27
bcwaldonvishy: just headed out20:27
bcwaldonvishy: email20:27
vishyah ok was going to ask him to backport this to milestone proposed: https://code.launchpad.net/~dan-prince/nova/ec2_admin_noauth/+merge/7264720:28
vishybut i can do it20:28
bcwaldonvishy: might as well, it's pretty simple20:28
openstackjenkinsProject burrow build #35: SUCCESS in 11 sec: https://jenkins.openstack.org/job/burrow/35/20:31
openstackjenkinsTarmac: Added client API unit tests, moved exceptions to main burrow module, and added more WSGI frontend tests.20:31
ttxok, going to get some evening back. See you in ~10 hours20:34
vishytr3buchet: our networking changes broke a pretty common use case20:34
tr3buchetvishy: uh oh20:42
tr3buchetvishy: what happened?20:42
vishybcwaldon: did you make your rebuild bugfix against the milestone revision so it can apply cleanly or does it need a backport as well?20:42
vishytr3buchet: we are storing the interface for vlans in the networks table now20:42
bcwaldonvishy: I proposed the same branch twice. I had that tought, but it didn't occur to me to do anything at the time.20:42
bcwaldonvishy: should I remake a branch for you?20:43
tr3buchetvishy: right20:43
*** ameade has quit IRC20:43
vishywhat if you are plugged into a different eth device20:43
vishy?20:43
tr3buchetvishy: i'm pretty sure i made that change20:43
vishywhat if some hosts are plugged in to eth3 for example20:43
tr3buchetwhat if what is plugged into a different eth device?20:43
tr3buchetoh20:43
vishyyeah, oops :(20:44
tr3buchetnonhomogeneous hosts?20:44
vishywe probably need to change the flag to override the value from the db20:44
vishyor have an override flag of some sort20:44
tr3bucheti only see 3 scenarios, homogeneous hosts, nonhomogeneous hosts, or changing things up mid go20:45
vishynonhomog happens in a lot of deploys20:45
tr3bucheti wasn't aware20:45
tr3buchetwithin the same zone?20:45
vishyfor example, sometimes there are two nics on network hosts and only one on compute20:45
vishyadmittedly most deployers can probably constrain to one eth device if they have to20:46
vishybut there are failure scenarios where you want to switch20:46
bcwaldonvishy: looking at rev 1148 in milestone-proposed, it seems like the branch went in cleanly20:46
vishyfor example if one of the eth devices fails20:46
tr3buchethmmm, we can coopt the bridge_interface parameter20:46
tr3buchetwell bridge interface comes from either flat_interface or vlan_interface20:47
vishybcwaldon: ah didn't realize it merged already.  Yes looks like it didn't pull in any other revissions20:47
tr3buchetvishy: lets say we replace vlan_interface and flat_interface with bridge_interface (can do backwards compatibility in there, with defaults to none. if the flag is set it overrides the db20:47
bcwaldonvishy: yeah, I'll be more careful next time20:47
*** code_franco has joined #openstack-dev20:48
vishybcwaldon: no worries :)20:48
vishytr3buchet: i think that makes sense20:48
tr3bucheti've been wanting to yank those two flags for a while anyway20:48
tr3buchetwant me to take a stab at it? is there a bug filed yet?20:49
*** AhmedSoliman has joined #openstack-dev20:50
*** raker has joined #openstack-dev20:55
*** zns has joined #openstack-dev21:04
*** ecarlin has quit IRC21:04
vladimir3pvish: ping21:08
vladimir3pvishy: ping21:09
vishyhey21:09
vladimir3pvishy: hey. Just pushed last part of changes for volume types21:09
zykes-mtaylor: is dashboard also getting built ?21:09
vishyvladimir3p: I saw that21:10
vladimir3pvishy: any chance to get review?21:10
mtaylorzykes-: no. that's on my todo list21:10
zykes-ah21:10
vishyyes i will review it once i finish catching up on emails21:10
vladimir3pvishy: cool, thanks. another question:21:10
vladimir3pvishy: for VSA should I wait untill volume types will be merged, or should I take this changes to my branch and propose VSA together with volume type & other our changes?21:11
vladimir3pvishy: if I will merge the code and propose it, the system will think that this is one huge proposal ...21:12
vishyin the merge proposal21:12
vishyif you put in prereq-branch21:13
vishy(it is in the advanced settings) it will ignore the changes from that branch in the diff21:13
vladimir3pvishy: cool !!! thanks21:13
vishyso put in the volume-type code as a prereq for vsa21:13
*** zns1 has joined #openstack-dev21:14
zykes-vsa ?21:15
vladimir3pzykes-: VSA==Virtual Storage Array21:17
*** zns has quit IRC21:19
*** martine has quit IRC21:21
vladimir3pvishy: btw, can you pls change volume types blueprint assignee to me? thanks21:23
vishysure21:23
vishyvladimir3p: did you end up using any stuff from Ben/mcgrue?21:23
*** lts has quit IRC21:25
vladimir3pvishy: we were in contact during these days. I tried to take his first version for volume_types_extra_data OS APIs, but it didn't work for me and I wrote it from scratch21:26
vishyok21:27
*** mfer is now known as mfer-food21:33
zykes-vladimir3p: that is ?21:33
exltsoren: I stopped reading when I hit "Debian releases are rare and unpredictable." - seriously: grow the fuck up.21:34
vladimir3pzykes-: new multi-tenant block storage for nova. The idea is to allow different storage vendors to deploy their storage stacks/RAIDs in VMs21:34
zykes-hmm21:34
zykes-blueprint?21:34
vladimir3pzykes-: https://blueprints.launchpad.net/nova/+spec/nova-virtual-storage-array21:35
*** amccabe has quit IRC21:35
sorenexlt: Err.. It's true. They're years apart and you never know ahead of time when they happen.21:35
sorenexlt: ...and that's fine. That's how Debian works.21:36
exltthey are nearly clockwork at ~24 months, give or take a few months21:36
sorenExactly.21:36
soren?21:36
sorenIt happens when it happens. It's not something you can plan your own release cycle by.21:37
exltLTS releases are even more rare, and any smart deployment would be set up on a stable release - ubuntu 6 month releases are not what I would consider stable in any way21:37
sorenAgain: This is fine. I don't think it's a bad thing for Debian to do this.21:37
sorenIt's just a bad thing for us to sync with. Because we can't.21:37
sorenUbuntu's releases are stable in the sense that they stop being in flux at predictable times, which is exactly what we need.21:38
sorenexlt: I don't see why this statement is so upsetting. Releases that are years apart give or take a few months is exactly what I call rare and unpredictable.21:39
exltwell, I'm not going to have a childish argument with you about the pros and cons of various linux distributions - my point is that it would be nice if you would do the same - it is entirely unbecoming of the openstack project as a whole21:40
notmyname /topic21:41
*** letterj has joined #openstack-dev21:41
*** ChanServ sets mode: +v letterj21:41
*** scotticus has joined #openstack-dev21:41
*** letterj has left #openstack-dev21:41
exltheh21:42
exltpoint taken21:42
*** letterj has joined #openstack-dev21:42
*** ChanServ sets mode: +v letterj21:42
exltbut I think it is dev-related21:43
notmynameexlt: no, I was looking for the evesdrop link. I thought it was in the topic21:43
sorenexlt: I'd be happy to discuss this somewhere else. I'm geniuinely confused what the problem is.21:43
mtaylorso - not to wade in and make things worse ...21:43
notmynameexlt: and I inadvertently had a space in the input field21:44
*** mfer-food is now known as mfer21:44
sorenexlt: I think Debian is great. I really do. When I grow up, I want to be a DD.21:44
mtaylorbut I think you guys may be talking about different things ... I think soren is considering release being tied to releasing with a release of a distro21:44
sorenexlt: I just don't think Debian release cycle is something I want to attempt to sync up with, because I haven't a clue how I'd do that.21:44
mtaylorsoren: yeah?21:44
exltthat is precisely your problem, in my opinion - you are very biased to *your* way of doing things, and dismissing many other valid opinions as rubbish - that is very immature21:44
sorenexlt: Can you help me improve, then?21:45
sorenI don't understand how I'm being immature.21:45
*** zns1 has quit IRC21:46
exltsince I no longer work on the project actively, and merely follow major changes through the list, I doubt I would be able to assist you with becoming a better human - I just think you are young - experience and keeping an open mind will help, not a single other person's advice21:47
sorenI can assure you it will never change if you won't even tell me what the problem is.21:48
notmynameok, personal attacks probably aren't good for anyone. keep away from that, and it's a good discussion21:48
mtaylornotmyname: ++21:48
mtaylorI'm much more interested in finding where our assumptions about what we're trying to achieve are likely different so that we can deal with those. assessments of people's personal motivations or behavioral tendencies is way out of scope21:49
zykes-exlt: why quit the project ?21:49
vishybcwaldon: if you are still here can you smokestack lp:~vladimir.p/nova/volume_type_extradata ? i don't seem to be able to login21:50
bcwaldonvishy: yep21:50
exltzykes-: I went back to school after 25ish years :-) (no longer work at Rackspace)21:50
zykes-oh21:50
zykes-that's sad ;p21:50
bcwaldonvishy: running meow21:51
*** jsavak has quit IRC21:51
*** joesavak has quit IRC21:51
vishythx21:51
creihtsoren: so I'm curious what OS you would run a production cluster on?21:51
creiht(and version)21:51
sorencreiht: Depends on what I'll run on said cluster.21:51
sorencreiht: (other than the OS)21:52
soren...and how much time I have available to deal with it.21:52
exltI wish I could give concrete advice - it is a perception that I have - reading through argumentative emails that tend, in my opinion to espouse one way of doing things, and that everything else is rubbish - well, that leads me to believe that personalities *do* cause development issues21:52
notmynamesoren: mtaylor: exlt: the truth is that the current packages aren't being used by major deployers and there are inconsistencies in the way things are done with packaging (as mtaylor pointed out in his email). you all have good experience with packaging. let's get something better than what we have21:52
sorenUbuntu for sure. Version: Depends.21:52
creihtsoren: if you were running Rackspace operations for their Nova deployment, what version of Ubuntu would you run21:53
creihtOr any isp wanting to set up their cloud21:53
sorencreiht: Crack-of-the-day Nova?21:53
creihtand perhaps a better question for everyone, is who are packages for... developers? deployment?21:54
mtaylorsoren: how about the upcoming diablo release21:54
sorenI probably wouldn't run that in production at all :)21:54
sorenmtaylor: Oneiric.21:54
* creiht sighs21:54
mtaylorcreiht: and I would argue that packages are for deployment21:54
mtaylorcreiht: I'm pretty sure devs are doing to pip install or whatnot21:54
creihtsoren: so you would run an os that only has support for 6 months in a production setup?21:54
sorencreiht: a) It's 18 months.21:55
notmynamemtaylor: devs will install from source with their latest topic branch ;-)21:55
sorencreiht: ..and b) I'd upgrade come LTS release time (next April).21:55
sorencreiht: ..and stay there for "a while".21:55
mtaylornotmyname: yes. that's what I meant - with any depends installed via venv or pip21:55
creihtso you have 1000 nodes running your cloud, and you are going to go through and do a OS upgrade to all of those?21:56
creihtI guess what I am getting at, is that most people who are going to do production deployments are going to use LTS21:56
sorenYeah, and I woulnd't test it either.21:56
sorenDuh.21:56
creihtand I am wondering how LTS is any different than debian release scheduling?21:56
sorenFor one: It's predictable.21:57
* exlt sighs..21:57
sorenFor most of my production stuff I run Lucid, but if running Lucid means I need to backport a bunch of stuff to get my application to run, I'll stronly consider going with a newer version.21:58
sorenexlt: To respond to your comment earlier: If I've spent a lot of time building something and someone else decides to throw it away, I at the very least want it to be for the right reasons. This involves explaining why things were done a particular way.22:00
sorenexlt: Too many times have I seen people think something is stupid, start over, itereate half a million times and end up with something that's almost identical to what they wanted to replace.22:00
exltsoren: sorry, I don't really understand what you are referring to22:01
sorenexlt: Your comment at 21:52 UTC.22:01
creihthttps://wiki.ubuntu.com/LTS22:02
creihtA new LTS version is usually released every 2 years22:02
creiht*usually*22:02
creihthttps://wiki.ubuntu.com/PReleaseSchedule22:02
creihtWhile no decision to make this release an LTS has been made, here are the Ubuntu LTS Release Details22:02
creihtI'm still uncertain how that is any more certain that what Debian provides?22:02
exltsoren: ah - that had absolutely nothing to do with code or anything - that was in answer to how I might help you improve22:03
sorenexlt: I see.22:03
exltoh, and that I do think personality plays a role in dev22:03
sorenSure.22:03
exltparticularly if people speak loudly and tend to drown others out22:03
creihtBut circling back around to what notmyname was saying, the current packaging situation is not working for any current real production deployments22:04
exltright22:04
creihtI apploud mtaylor's efforts in wanting to fix that22:04
creihtsoren: perhaps you could email the mailing list how you could propose fixing those issues?22:04
creihtif you don't agree with mtaylor?22:04
exltoh, he did.22:05
sorencreiht: I think I made it quite clear that I don't.22:05
exltthat's why I started typing a little bit ago22:05
sorenTake the Swift packaging for instance.22:05
mtaylorwhich brings me back to the point that I believe soren and I have different definitions of what the good outcome here is22:05
sorenThe Swift team decided to fork the packaging.22:05
exltsoren: you are not listening..22:06
sorenIf it's really because I didn't keep the packaging in git, I'm just speechless.22:06
creihtsoren: I think that has been hashed through several times already22:06
exltgit is not the issue22:06
mtaylorI think this has very very little to do with git v. bzr22:06
sorenPlease explain what it is then (that I didn't already point out in my e-mail).22:07
notmynameour packaging came first...how is that a fork? ;-)22:07
creihtlol22:07
mtaylorthere are two things ... one is where the packaging gets published - that has nothing to do with git v. bzr in any case22:07
mtaylorthe other thing is how the packaging is worked on22:07
sorenI was told to consolidate everything. I did. After a while, you guys started doing your own packaging. Why was that?22:07
* exlt needs to go work on stuff - back later to read logs, since I started this..22:08
creihtsoren: like I said, that has already been hashed through, I'm not sure I can say anything more that hasn't already been said22:08
creihtif you still don't understand, I'm sorry22:08
sorenSo am I.22:08
sorenIs it different from what I point out in  my e-mail?22:08
mtaylorfor how the packaging is worked on, where it is worked on at this point communicates a specific focus, and has some specific connotations22:08
mtaylorif we align process with ubuntu, it's very clear that it's an ubuntu target and goals and not an openstack project one, and it means a second set of processes have to be learned to collaborate22:09
sorencreiht: Namely that Rackspace expects to want different behaviour of the packages in certain situations and so wants to have separate packaging.22:09
sorencreiht: Is that completely off?22:09
mtaylorif we align process with OpenStack, then we have similar tooling for OpenStack folks to use, and we can produce an OpenStack output22:10
*** code_franco has quit IRC22:10
* creiht sighs22:10
sorenmtaylor: A couple of months ago, everything used the same tooling. The situation was the same.22:10
mtaylorsoren: tooling isn't what I'm talking about22:10
mtaylorit's process22:10
mtaylorpackaging did NOT use the same process as the rest of openstack22:10
*** alekibango has quit IRC22:11
sorenRight.22:11
notmynamesoren: 2 main reasons for out own packages: 1) we need a static repo that will not change after a new release (rekicking a box much install the same version the rest of the cluster has) 2) Rackspace product organization has different release requirements. sometimes we need a release out-of-band with openstack and need to use it22:11
sorennotmyname: That sounds like reasons for having a different repository. Not different packaging?22:12
*** alekibango has joined #openstack-dev22:12
mtaylorit used process much more similar to how ubuntu works on packages - which is fine, it's a fine process... it's just that having a different process didn't really work to help difference of opinions get ironed out22:12
*** alekibango has quit IRC22:12
*** alekibango has joined #openstack-dev22:12
mtaylorI believe what notmyname refers to _might_ require different both things ... but I think we can design something that might allow us to serve those sorts of things out of the public repo22:12
notmynamesoren:  number 2 means our own packaging. we need to include code that isn't in the openstack repo22:12
sorenmtaylor: This was also done for specific reasons.22:13
mtaylorwe might not be able to and notmyname may still have to run his own22:13
sorennotmyname: Oh? What sort of stuff?22:13
mtaylorsoren: I know it was. I'm just saying that the results are not being viewed with success by many of the non-ubuntu stakeholders in the OpenStack project. especially if we view success in terms of use of the output22:13
notmynamemtaylor: the first requirement is the big one that openstack packaging can "fix", IMO. the second is a separate issue22:13
mtaylornotmyname: agree.22:14
mtaylornotmyname: I would like the second one to be as painless as possible - but it's not really my job to provide that for you :)22:14
notmynamemtaylor: agreed22:14
notmynamesoren: it doesn't matter what sort of stuff.22:14
bcwaldonvishy: your smokestack jobs passed, btw22:15
sorennotmyname: It would help my understanding. Are we talking about patches to Swift itself od or packaging differences?22:15
sorens/ od //22:15
notmynamesoren: patches to swift that need to land in our production deployment before an openstack release happens22:16
sorennotmyname: Ok.22:16
notmynamesoren: 2 recent examples are container metadata and quarantine improvements22:16
notmynamerecent == within the pat 6 months22:17
sorenOk.22:18
sorenI'm still missing why that required maintaining completely separate packaging, though.22:19
letterjvishy: I've been looking around for documentation and deployment instructions for the current nova volume api.   Is there more than this http://nova.openstack.org/devref/volume.html#module-nova.volume.manager?22:19
*** bcwaldon has quit IRC22:20
*** gholt has joined #openstack-dev22:20
* gholt waves22:20
notmynamesoren: until recently, the lucid builds were broken, things in your packages are autostarted, features like reload are not included in your packages. basically, our operations people do not feel that the openstack packages are reliable enough to use in live deployments. I think this can be solved22:20
sorennotmyname: You've had commit access to the packaging branch all along, though.22:21
sorennotmyname: (all of swift-core has)22:21
gholtI thought I'd jump in say that I split away from OS packaging because I felt I had little control over it and I needed such control.22:22
gholtWhat OS packaging wants/needs seems to be different with what I've needed/wanted and that's fine.22:22
gholtI just don't want folks to get all mad at me because I don't happen to use whatever philosophic packaging they're making.22:23
openstackgerritYogeshwar Srikrishnan proposed a change to openstack/keystone: Redefining credential types.  https://review.openstack.org/33422:23
gholtAlso, the OS packaging seemed to move around, break without testing, not have things auto-built, etc. at various stages.22:24
notmyname(^ all addressed by mtaylor)22:24
gholtI didn't have time to track what was up, so I went to the easy-stand-by: do it yerself22:24
gholtWhich was easy since I was already doing it myself before OS anyway. :)22:24
alekibangoi think what openstack really needs is good testing.22:25
gholtThat's probably enough from me. :D22:25
*** gholt has left #openstack-dev22:25
*** RobertLaptop has quit IRC22:26
sorennotmyname: Can you explain how? I'm clearly missing something.22:26
creihtI would also like to pipe in that what mtaylor is proposing would likely solve a lot of the issues that we had initially with packaging22:26
notmynamesoren: how what? how mtaylor addressed things? just that these were they issues (or the types of issues) that he mentioned in his first emal22:27
notmynameemail22:27
sorencreiht: If I ask what those were are you just going to sigh again? Because that's getting old.22:27
sorennotmyname: Well, yes, he mentioned them, but how are the changes he's making solving this?22:27
notmynamesoren: I'm not claiming that there are any answers now. I'm not a packaging expert. I never claimed to be. I simply want to see the concerns addressed.22:28
vishyvladimir3p: reviewed22:29
creihtsoren: the same thing that gholt has said, the same thing that we have repeatedly said on IRC and the mailing lists22:30
creihtI'm at a loss how we can make it any clearer to you22:30
creihtmtaylor seems to get our issues (as with many others which can be seen from the mailing list responses)22:31
vladimir3pvishy: thanks. any issues (aside of rebase)?22:31
vishydidn't see any.  Got a pep error but i think it is in trunk22:31
Davieycreiht: many people are also NOT responding, as I don't think it will help.22:31
vishybecause it didn't look like you made any changes to the file that had the error22:31
Davieycreiht: Please be aware that soren is not alone in frustrations and concerns.22:32
vladimir3pvishy: yep, there are 2 of them in trunk and I decided to leave them22:32
daboI see 3 pep errors in trunk22:32
vishydid our pep gate get turned off?22:32
creihtDaviey: would any of those people *not* be on the Ubuntu team?22:32
vladimir3pvishy: regarding to rebase. does 1479 an official D4?22:32
vishy1479 is where we branched milestone-proposed22:33
creihtbut yeah, this isn't going much anywhere now22:33
creihttime for dinner22:33
vladimir3pvishy: how about changes after 1479?22:33
vishyvladimir3p: actually22:33
vishywe aren't trying to get this into d4 are we?22:34
vladimir3pvishy: yep22:34
vishythere is an FFE for merging after d422:34
Davieycreiht: Yes, because Debian packaging hasn't exactly been a smooth ride.22:34
notmynameDaviey: that's good to know. the reality is that the current packaging isn't in use by major deployers. let's figure out why and if those issues can be addressed.22:34
vishyso I don't think you need to do the rebase after all22:34
Davieynotmyname: Where did you get that data?22:34
sorenDaviey: notmyname *is* a major deployer.22:35
vladimir3pvishy: great! thre are some changes that we would like to have (like small one you've done for iscsiadm)22:35
vishyyes that is in d4 already22:35
Davieysoren: A or THE?22:35
vladimir3pvishy: so, should I leave it as is?22:35
vishyyes22:35
vladimir3pvishy: great, thanks22:35
* notmyname agrees with chuck. not much more to be resolved right now. time to go home22:37
sorenDaviey: It's free software. No way to know :)22:37
vladimir3pfolks, any chance to get more eyes on https://code.launchpad.net/~vladimir.p/nova/volume_type_extradata/+merge/72762 ? thanks22:42
*** mattray has quit IRC22:44
*** mfer has quit IRC22:59
tr3buchet5~5~5~5~5~5~5~5~5~5~5~5~5~5~5~5~5~5~5~5~5~5~5~5~5~5~5~5~23:03
tr3buchetvishy: you never answered my question23:04
vishyah sorry didn't see that23:05
vishythere is a question but no bug23:05
tr3buchetalright i'll create a bug and start working on it23:05
vishytr3buchet: https://answers.launchpad.net/nova/+question/16904123:06
vishycan you link the bug there?23:06
vishythx23:06
letterjvishy: Did you see my question?23:06
tr3buchetsure23:07
vishyletterj: not a whole lot of docs there23:08
vishy:)23:08
vishyany showstopper bugs that anyone knows about for D-4?23:10
vishywe have 8 hrs to get anything else into the milestone23:10
*** bengrue has quit IRC23:11
tr3buchetvishy: you want this in the milestone?23:12
vishytr3buchet: no23:13
tr3buchethttps://bugs.launchpad.net/nova/+bug/83342623:13
uvirtbotLaunchpad bug 833426 in nova "Nonhomogeneous networks not supported" [Undecided,New]23:13
tr3buchetk good. i didn't want to stay up all night messing with it23:13
vishyd4 is fine without it, edge case, but we want it in D-final23:13
tr3buchetsure.23:13
vishytr3buchet: thx, btw.  It is nice to have someone else that understands the networking code, so I don't have to do all of those fixes myself :)23:15
vishyI know it was probably painful to get up to speed23:16
tr3buchetvishy: no problem23:17
tr3buchetvishy: anything else i can help with to get this out the door?23:18
openstackgerritJames E. Blair proposed a change to openstack/openstack-ci: Add watch_deploy script.  https://review.openstack.org/33523:19
vishytr3buchet: only if you know of some bugs that i haven't found that need to make milestone23:19
*** JStoker has quit IRC23:20
tr3bucheti do not!23:20
tr3buchet\o/23:20
*** medberry is now known as med_out23:25
*** RobertLaptop has joined #openstack-dev23:27
openstackgerritA change was merged to openstack/openstack-ci: Add watch_deploy script.  https://review.openstack.org/33523:29
*** bsza has quit IRC23:29
*** jakedahn has quit IRC23:39
*** jakedahn has joined #openstack-dev23:39
*** novas0x2a|laptop has quit IRC23:45
*** gholt has joined #openstack-dev23:54
gholtsoren: mtaylor: [I'm back home now] Generally speaking, I'm not sure it should be a required goal that the OS packaging should be used by any one deployer. Just take in all the input and provide something useful to someone and I'd think you'd be golden.23:56
gholtDon't take it personal if some crazy operator does something else. :)23:56
mtaylorgholt: well, yes. HOWEVER, if I could actually meet your needs that would be stellar23:56
mtaylorif I don't, that's cool too23:56
gholtYeah23:57
mtaylorI just want to make sure that we're actually responding to actual needs, and it seems like we've got some folks who are involved who have them :)23:57
*** zul has quit IRC23:57
gholtHehe. I remember there was a requirement at some point that any Ubuntu packaging had to start any and all services by default, which our ops didn't much like.23:58
mtaylorbecause, if we could change, say, 2 things and you guys would start using our packages and have that be a win for you, then you'll have more skin in the game to review and provide bugfixes to changes ... and then our packages will be better23:58
mtaylorand it's things like that which I want to fix23:58
gholtBut, if that were the only thing, it'd be an easy "base it off OS packaging with a few tweaks" thing. Which is where I'd like to get.23:58
mtayloropenstack isn't exactly like a desktop file indexer23:59
mtaylortotally23:59
mtaylorI want it to be possible/easy to use our packages in real deployments, ALSO sensible to make derived packages and both of those should be less work than just going off and doing your own damned thing23:59

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