*** anotherjesse has quit IRC | 00:21 | |
*** anotherjesse has joined #openstack-dev | 00:21 | |
*** nati has quit IRC | 00:32 | |
*** hisaharu has quit IRC | 00:36 | |
anotherjesse | heyo mtaylor - around? | 00:38 |
---|---|---|
jeblair | guess not | 00:39 |
mtaylor | hey | 00:40 |
jeblair | hiya! | 00:40 |
jeblair | 17:36 <anotherjesse> recipes don't even finish because people change stuff without notifying anyone | 00:40 |
jeblair | 17:37 <anotherjesse> do we: | 00:40 |
jeblair | 17:37 <anotherjesse> make puppet log to syslog | 00:40 |
jeblair | 17:37 <anotherjesse> and store a syslog of the install and run - so that we can see errors? | 00:40 |
anotherjesse | mtaylor: I was helping jeblair work on why keystone wasn't installing | 00:41 |
anotherjesse | mtaylor: and relaying that a major reason tests fail is because the deploy doesn't finish due to changes in how things should interact | 00:41 |
mtaylor | yes ... this is fun :) | 00:41 |
anotherjesse | if 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 |
jeblair | so we can probably have the nodes syslog to the jenkins slave, so we'll have the info there | 00:42 |
mtaylor | yes- if we can report them back, jenkins will keep them | 00:42 |
jeblair | but how will they be stored? | 00:42 |
mtaylor | what 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 running | 00:42 |
mtaylor | essentially, in the jenkins job - when we run "./deploy_stuff.sh" ... anything that prints to the screen will get stored as the job log in jenkins | 00:43 |
anotherjesse | YES | 00:43 |
jeblair | i 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 off | 00:43 |
mtaylor | so if we can have deploy_stuff kick the machines and then stream their output, I think we'll have win | 00:43 |
anotherjesse | I think at one point we had 2 different jobs | 00:44 |
anotherjesse | deploy | 00:44 |
mtaylor | extra 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 win | 00:44 |
anotherjesse | test | 00:44 |
mtaylor | yeah - a deply and then a test. | 00:44 |
anotherjesse | and test had a pre-req of deploy | 00:44 |
*** novas0x2a|laptop has quit IRC | 00:44 | |
anotherjesse | oh - so jeblair said you might have an updated package for the keystone? | 00:44 |
jeblair | that makes sense. so we stream the logs till that's done. how did you determine when deploy was complete? | 00:44 |
mtaylor | yup. and then if we use a lock/latch to make sure that another deploy doesn't run before the test is done ... but yeah | 00:44 |
mtaylor | anotherjesse: I do, I was going to upload it here in just a bit | 00:44 |
mtaylor | anotherjesse: (that's tied up based on an email I was just about to send you, actually) | 00:45 |
anotherjesse | can you shove it somewhere I can download - wget is good with me | 00:45 |
anotherjesse | no apt needed | 00:45 |
mtaylor | anotherjesse: k. will do | 00:45 |
mtaylor | jeblair: well... for determining the deploy is done ... | 00:45 |
mtaylor | jeblair: w you could have the nodes get/post to a url on the slave (for instance) at the end of the deploy run | 00:46 |
anotherjesse | jeblair: when the deploy.sh fails or succeeds - with test-signals? | 00:46 |
zns | mtaylor: 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 |
mtaylor | zns: yes. working on that right now | 00:46 |
anotherjesse | zns: you can actually add yourself | 00:46 |
zns | mtaylor: cool! | 00:46 |
anotherjesse | zns: we know because devcamcar added dash to openstack too early | 00:47 |
anotherjesse | I had admin - updated! | 00:47 |
jeblair | well the real end of the deployment is when the machines have booted, installed an os, openstack, and started services... | 00:47 |
zns | anotherjesse: I started down that path but decided not to do double work. Was waiting on mtaylor or soren. | 00:48 |
anotherjesse | jeblair: but should the deploy_stuff be responsible for it | 00:48 |
anotherjesse | jeblair: it can "spin | 00:48 |
anotherjesse | right? | 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 deploy | 00:49 |
mtaylor | zns: yes. I shall get a thing sorted for you on that by the end of the evening | 00:49 |
jeblair | so all the deploy script really needs to do is hit djeep's reboot url | 00:50 |
jeblair | and then we just wait some amount of time, and the openstack should be running | 00:50 |
zns | mtaylor: no rush, but thank you! | 00:50 |
jeblair | but i'm not sure when we decide that is done (it's especially complicated since openstack might not actually end up running) | 00:50 |
anotherjesse | jeblair: well - the end of a preseed includes a post-inst instruction | 00:50 |
anotherjesse | jeblair: that usually (in cobbler as well) makes a http call to say I'm done | 00:50 |
jeblair | but puppet has to run too | 00:51 |
anotherjesse | jeblair: but then a reboot and puppet run | 00:51 |
anotherjesse | jeblair: ya | 00:51 |
anotherjesse | jeblair: so in this cause the deploy_djeep.sh would probably check via looking for a successful puppet run on each box | 00:51 |
anotherjesse | then return success | 00:51 |
jeblair | we could do that by watching syslog messages | 00:51 |
anotherjesse | and timeout after X minutes (probably set by CI environment - deploy arch X with script Y in time Z) | 00:52 |
anotherjesse | jeblair: each script can do their own thing… so sure syslog messages! | 00:52 |
anotherjesse | mtaylor: eta on deb | 00:53 |
anotherjesse | don't make me package it myself ;p | 00:53 |
anotherjesse | jeblair: actually - let's not wait on keystone | 00:57 |
jeblair | ok | 00:58 |
anotherjesse | since the CI part doesn't care if the install worked - it is actually bettter that it didn't | 00:58 |
anotherjesse | since we need to gather up and report that it didn't | 00:58 |
jeblair | kong looked like it was trying to talk to keystone | 00:58 |
jeblair | it hung on: connect(3, {sa_family=AF_INET, sin_port=htons(5000), sin_addr=inet_addr("10.0.0.100")}, 16 | 00:58 |
anotherjesse | jeblair: right - but at this moment the important thing for CI to do: | 00:58 |
jeblair | while running test_002_verify_nova_auth | 00:58 |
anotherjesse | report an error on deployment with all the logs | 00:59 |
anotherjesse | since this will happen DAILY | 00:59 |
anotherjesse | keystone (working on 2.0 api), nova (breathing), glance (adding private images) | 00:59 |
anotherjesse | each cause the recipes to be broken | 00:59 |
jeblair | okay, we can focus on the deploy+syslog stuff then | 00:59 |
anotherjesse | and we need to make sure jenkins captures the logs and share them | 00:59 |
anotherjesse | since in my opinion - you are done except the error logs right? | 01:00 |
anotherjesse | if you have it so it is able to kick the boxes, then either capture the status of the deploy with nice logs | 01:00 |
anotherjesse | then if success run the tests | 01:00 |
jeblair | error logs, wait for completion, and probably a mutex around the whole thing to prevent multiple runs | 01:00 |
anotherjesse | you don't care what the recipes are | 01:00 |
*** dragondm has quit IRC | 01:00 | |
anotherjesse | jeblair: ya | 01:00 |
anotherjesse | thanks be to a broken package - we are unblocked! ;p | 01:01 |
jeblair | :) | 01:01 |
*** thor_ has joined #openstack-dev | 01:01 | |
jeblair | anotherjesse: thanks for your help | 01:01 |
*** troytoman is now known as troytoman-away | 01:02 | |
jeblair | i'm about to head out to dinner, so i'll probably resume this tomorrow. i'll let you know when i have that working | 01:02 |
mtaylor | anotherjesse: just realized my packages were old - rebuilding - emailing in a sec | 01:02 |
mtaylor | anotherjesse: oh - maverick ok? | 01:03 |
jeblair | mtaylor: maverick is what the nodes are running | 01:04 |
anotherjesse | mtaylor: maverick is good | 01:04 |
*** nati has joined #openstack-dev | 01:11 | |
*** mfer has joined #openstack-dev | 01:16 | |
*** mfer has quit IRC | 01:16 | |
*** anotherjesse has quit IRC | 01:20 | |
*** jakedahn has quit IRC | 01:28 | |
*** thor_ has quit IRC | 01:39 | |
*** rods has quit IRC | 02:10 | |
*** jakedahn has joined #openstack-dev | 02:12 | |
*** zns has quit IRC | 02:22 | |
*** ecarlin has joined #openstack-dev | 02:44 | |
*** anotherjesse has joined #openstack-dev | 02:54 | |
*** ecarlin has quit IRC | 03:11 | |
*** ecarlin has joined #openstack-dev | 03:14 | |
*** anotherjesse has quit IRC | 03:14 | |
*** zns has joined #openstack-dev | 03:22 | |
*** vladimir3p has quit IRC | 03:27 | |
*** mdomsch_ has joined #openstack-dev | 03:52 | |
*** ecarlin has quit IRC | 04:07 | |
*** ecarlin has joined #openstack-dev | 04:07 | |
*** ecarlin has quit IRC | 04:18 | |
*** jakedahn has quit IRC | 04:50 | |
*** zaitcev has quit IRC | 04:59 | |
*** zns has quit IRC | 05:13 | |
*** mdomsch_ has quit IRC | 05:20 | |
*** tsuzuki_ has joined #openstack-dev | 05:47 | |
*** openpercept_ has joined #openstack-dev | 06:03 | |
*** nati has quit IRC | 06:10 | |
*** nati has joined #openstack-dev | 06:38 | |
*** reidrac has joined #openstack-dev | 06:54 | |
*** mszilagyi has joined #openstack-dev | 07:00 | |
*** openpercept_ has quit IRC | 07:02 | |
*** nickon has joined #openstack-dev | 07:16 | |
*** mnour has joined #openstack-dev | 10:23 | |
*** mnour has quit IRC | 10:28 | |
*** rods has joined #openstack-dev | 10:32 | |
*** nickon has quit IRC | 10:39 | |
*** mnour has joined #openstack-dev | 10:41 | |
*** tsuzuki_ has quit IRC | 10:54 | |
*** markvoelker has joined #openstack-dev | 11:22 | |
*** mdomsch has quit IRC | 11:44 | |
*** Adri2000 has quit IRC | 11:58 | |
*** bsza has joined #openstack-dev | 12:02 | |
ttx | soren: 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 them | 12:10 |
*** lts has joined #openstack-dev | 12:16 | |
*** mfer has joined #openstack-dev | 12:17 | |
*** Adri2000 has joined #openstack-dev | 12:18 | |
*** zul has quit IRC | 12:25 | |
*** zul has joined #openstack-dev | 12:30 | |
*** zul has quit IRC | 12:39 | |
soren | ttx: I'll see if I can squeeze it in today. | 12:40 |
*** zul has joined #openstack-dev | 12:52 | |
*** zul has quit IRC | 12:55 | |
*** zul has joined #openstack-dev | 12:55 | |
*** ewindisch has quit IRC | 13:09 | |
*** mattray has joined #openstack-dev | 13:10 | |
*** joesavak has joined #openstack-dev | 13:32 | |
*** jsavak has joined #openstack-dev | 13:32 | |
*** zns has joined #openstack-dev | 13:38 | |
*** joesavak has quit IRC | 13:44 | |
*** joesavak has joined #openstack-dev | 13:44 | |
*** lorin1 has joined #openstack-dev | 13:44 | |
*** jsavak has quit IRC | 13:44 | |
*** jsavak has joined #openstack-dev | 13:44 | |
*** lorin1 has left #openstack-dev | 13:45 | |
*** ameade has joined #openstack-dev | 13:48 | |
sandywalsh | _0x44, is this a wip? https://github.com/rackspace/python-novaclient/pull/66 | 13:56 |
*** bcwaldon has joined #openstack-dev | 13:57 | |
*** ecarlin has joined #openstack-dev | 14:12 | |
jaypipes | Daviey: ping. | 14:16 |
jaypipes | sandywalsh: what, you can't tell from the pull request status? ;) | 14:17 |
*** markmc has joined #openstack-dev | 14:18 | |
*** alekibango has joined #openstack-dev | 14:18 | |
Daviey | jaypipes: hola | 14:21 |
sandywalsh | jaypipes, yeah, if only we had some system we could use that worked with github and give us a workflow ... hmm | 14:22 |
sandywalsh | *gave | 14:22 |
*** misheska has joined #openstack-dev | 14:24 | |
*** alekibango has quit IRC | 14:29 | |
*** alekibango has joined #openstack-dev | 14:30 | |
openstackgerrit | Justin Shepherd proposed a change to openstack/glance: Bug lp:829654 https://review.openstack.org/331 | 14:30 |
openstackgerrit | Justin Shepherd proposed a change to openstack/glance: Bug lp:829654 https://review.openstack.org/331 | 14:33 |
*** code_franco has joined #openstack-dev | 14:37 | |
*** martine has joined #openstack-dev | 14:38 | |
jaypipes | jeblair: any reason the above notification from gerrit is doubled up? ^^ | 14:39 |
*** amccabe has joined #openstack-dev | 14:45 | |
jaypipes | Outlook Web Access, I want to strangle thee with a garden hose. | 14:47 |
jeblair | jaypipes: second patchset. We could probably have gerritbot add more words to indicate patchset numbers | 14:47 |
jaypipes | jeblair: ah, I see. yes, that would be terrific. low priority, backburner, etc etc | 14:48 |
jeblair | jaypipes: noted | 14:49 |
*** dragondm has joined #openstack-dev | 14:55 | |
*** rnirmal has joined #openstack-dev | 14:55 | |
openstackgerrit | A change was merged to openstack/glance: Bug lp:829654 https://review.openstack.org/331 | 15:03 |
openstackgerrit | Justin Shepherd proposed a change to openstack/glance: Bug lp:829064 https://review.openstack.org/332 | 15:03 |
*** reidrac has quit IRC | 15:05 | |
*** rnirmal has quit IRC | 15:05 | |
*** rnirmal has joined #openstack-dev | 15:05 | |
openstackgerrit | A change was merged to openstack/glance: Bug lp:829064 https://review.openstack.org/332 | 15:14 |
*** nati has quit IRC | 15:18 | |
*** RobertLaptop has quit IRC | 15:21 | |
annegentle | mtaylor: can you help me figure out why a build is working but the FTP is copying 0 files? | 15:28 |
_0x44 | sandywalsh: 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 |
bcwaldon | jaypipes: question about FF | 15:32 |
jaypipes | bcwaldon: shoot | 15:33 |
bcwaldon | is it just features we are blocking from trunk, or everything? | 15:33 |
jaypipes | bcwaldon: just features. | 15:33 |
*** vladimir3p has joined #openstack-dev | 15:33 | |
bcwaldon | jaypipes: cool, so something like this can go in fine: https://code.launchpad.net/~ken-pepple/nova/lp828600/+merge/72319 | 15:33 |
jaypipes | bcwaldon: and I've already moved all non-Implemented features out to RPB milestone. | 15:33 |
jaypipes | bcwaldon: for glance, that is. | 15:33 |
jaypipes | bcwaldon: absolutely on kpepple_'s mp. | 15:34 |
bcwaldon | cool | 15:34 |
bcwaldon | there are a bunch of those | 15:34 |
bcwaldon | jaypipes: things that I approve now to get into trunk won't go into d4 without being re-proposed to milestone-proposed, right? | 15:37 |
jaypipes | bcwaldon: that is correct. | 15:37 |
bcwaldon | so what's the point of FF? | 15:37 |
jaypipes | bcwaldon: so that features can continue to go into trunk | 15:37 |
jaypipes | bcwaldon: it's just that features don't go into the milestone proposed branch, which was cut early yesterday morning... | 15:38 |
bcwaldon | oh okay, so anything can go into trunk, but it needs ffe to make it into milestone-proposed | 15:38 |
jaypipes | bcwaldon: just have to keep an eye on where the merge proposal is targeted to go to :) | 15:38 |
jaypipes | bcwaldon: exactly. | 15:38 |
bcwaldon | jaypipes: cool, thanks bud | 15:39 |
jaypipes | np problem. | 15:39 |
*** anotherjesse has joined #openstack-dev | 15:40 | |
ttx | jaypipes, bcwalson: well, not exactly | 15:40 |
ttx | FF is about handling the post-D4 pre-release period | 15:41 |
ttx | i.e. we shoudn't introduce new features after the last milestone | 15:41 |
ttx | (or at least, not disrupting features) | 15:41 |
jaypipes | ttx: isn't that what I said above? :) | 15:42 |
ttx | jaypipes: hmm, no | 15:42 |
ttx | bcwaldon> oh okay, so anything can go into trunk, but it needs ffe to make it into milestone-proposed | 15:42 |
ttx | that's wrong ^ | 15:42 |
bcwaldon | ttx: please correct me, as I jsut approved some testing branches | 15:43 |
ttx | ok, I explain | 15:43 |
ttx | rather than cutting the release branch at D4, we decided to keep trunk open for two weeks after D4 | 15:43 |
ttx | until "RBP" | 15:44 |
ttx | At Release Branch Point, we cut a release branch on which only critical bugfixes land. | 15:44 |
ttx | and we open Essex | 15:44 |
*** anotherjesse has quit IRC | 15:44 | |
ttx | between D4 and RBP though, we need to be careful with what lands in trunk | 15:44 |
jaypipes | ttx: yes, I understand that, but I was specifically referring to D4's milestone-proposed branch, not the RBP. | 15:44 |
ttx | between D4 and RBP, only features that get the PTL go-ahead (i.e. targeted to diablo-rbp) should be accepted | 15:45 |
jaypipes | ttx: i.e. the branch we will be releasing tomorrow morning? | 15:45 |
ttx | bugfixes branch can go in without issue | 15:45 |
*** zns has quit IRC | 15:45 | |
jaypipes | ttx: right, but doesn't that start *after* D4 is released tomorrow? | 15:45 |
jaypipes | ttx: or did that start when the milestone-proposed branch for D4 was cut? | 15:46 |
ttx | jaypipes: it did start when the milestone branch was cut | 15:46 |
ttx | The idea is to have "most new features" in the last milestone. | 15:46 |
ttx | if you add them to trunk after the D4 milestone branch is cut... that defaets the purpose | 15:47 |
*** mnour has quit IRC | 15:47 | |
ttx | So in summary: | 15:47 |
jaypipes | ttx: ok, sorry bcwaldon, I thought that was starting *after* D4 was released. my bad. | 15:47 |
ttx | Currently: | 15:47 |
jaypipes | ttx: yes, I suppose you are right. just confiusion on my part. sorry. | 15:47 |
bcwaldon | all I was worried about here was whether I could send in bugfix branches, so I think I'm good there | 15:47 |
ttx | RBP-targeted features, and any bugfix can land to trunk | 15:47 |
ttx | D4-targeted bugs can land to milestone-proposed | 15:48 |
ttx | After D4 is released: | 15:48 |
ttx | RBP-targeted features, and any bugfix can land to trunk | 15:48 |
ttx | Between RBP and release: | 15:48 |
ttx | anything can land to trunk | 15:48 |
ttx | RC bugfixes can land to milestone-proposed | 15:48 |
ttx | After release: | 15:49 |
ttx | anything can land to trunk | 15:49 |
ttx | does that make it clearer ? | 15:49 |
bcwaldon | the 'Between RBP and release' is still confusing | 15:49 |
bcwaldon | nope, got it | 15:49 |
bcwaldon | just clicked | 15:49 |
ttx | After RBP, you have two branches: trunk is Essex, and milestone-propsoed in the Diablo release branch | 15:50 |
openstackjenkins | Project nova build #1,289: SUCCESS in 3 min 23 sec: https://jenkins.openstack.org/job/nova/1289/ | 15:50 |
openstackjenkins | Tarmac: added unit tests for version.py | 15:50 |
* jaypipes apologizes for any confusion he has wrought. | 15:50 | |
*** Capashen has joined #openstack-dev | 15:50 | |
bcwaldon | yeah, that's what I didn't realize at first | 15:50 |
bcwaldon | no, i needed this spelled out anyways ;) | 15:50 |
ttx | yes, 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 |
Capashen | Hi. While testing glance (diablo), I'm having #827034 bug. Now I can't delete images with Glance any more. Is there any workaround ? Thanks | 15:52 |
jaypipes | Capashen: one sec, looking... | 15:53 |
jaypipes | Capashen: the workaround is in the bug report :) | 15:54 |
jaypipes | Capashen: need to make a slight modification to your config files... | 15:54 |
Capashen | you mean the [filter:context] part ? | 15:56 |
bcwaldon | Capashen: yep | 15:57 |
Capashen | actually I have these two lines and I have the bug | 15:57 |
bcwaldon | Capashen: did you restart all your glance services? | 15:57 |
Capashen | I didn't modify conf file, these lines were already there | 15:58 |
*** joesavak has quit IRC | 15:58 | |
bcwaldon | ah, okay | 15:58 |
*** jsavak has quit IRC | 15:58 | |
bcwaldon | jaypipes: any thoughts? | 15:59 |
jaypipes | Capashen: please pastebin your two conf files. thanks! | 16:00 |
jaypipes | s1rp_: status on https://bugs.launchpad.net/glance/+bug/820090? | 16:00 |
uvirtbot | Launchpad bug 820090 in glance "Logging str(Exception) considered harmful" [Medium,In progress] | 16:00 |
*** joesavak has joined #openstack-dev | 16:01 | |
*** jsavak has joined #openstack-dev | 16:01 | |
*** hisaharu has joined #openstack-dev | 16:01 | |
ttx | jaypipes, vishy: do you think you can put milestone-proposed in a D4-shippable shape by the end of the day ? | 16:02 |
ttx | jaypipes, vishy: if yes, just send me an email by EOD saying "ship it" and I'll do so in the morning. | 16:02 |
ttx | jaypipes, vishy: if not, we can use tomorrow for the last fixes. | 16:03 |
jaypipes | ttx: yes. waiting on some test results from shep and sending email out on a couple bug bounties. | 16:03 |
*** nati has joined #openstack-dev | 16:03 | |
ttx | jaypipes: ideally you would sync with Vish, I'd rather release both at around the same time. | 16:04 |
jaypipes | ttx: will do. | 16:04 |
ttx | dabo: I did address your comment on https://code.launchpad.net/~ttx/nova/lp820962/+merge/72712 | 16:05 |
Capashen | jaypipes, http://pastebin.com/Wu2zyA07 (config file), http://pastebin.com/iP6u7cZ0 (error) | 16:05 |
openstackjenkins | Project 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_global | 16:06 |
openstackjenkins | fixed to_global to catch correct error from incorrect mac addresses | 16:06 |
openstackjenkins | * Tarmac: similar to lp828614: add rainy day test and fix exception error catch to AddrFormatError | 16:06 |
openstackjenkins | * Tarmac: added unit tests for version.py | 16:06 |
openstackjenkins | * Tarmac: Adds a use_deprecated_auth flag to make sure creds generated using nova-manage commands will work with noauth. | 16:06 |
dabo | Need some review and feedback on: https://code.launchpad.net/~ed-leafe/nova/scheduler-multifilter/+merge/72478 | 16:06 |
dabo | ttx: approved | 16:07 |
bcwaldon | ttx: should that bug go into d4? | 16:08 |
ttx | bcwaldon: I'd say yes, but i'll let vishy decide | 16:09 |
ttx | can't be judge and jury. | 16:09 |
bcwaldon | ok, I'll put a note on that bug report | 16:09 |
ttx | I pmed it on it already | 16:09 |
bcwaldon | ok, I'll be quiet ;) | 16:09 |
*** zaitcev has joined #openstack-dev | 16:11 | |
*** zns has joined #openstack-dev | 16:14 | |
zykes- | is a packager for el5 + 6 a wanted thing ? | 16:15 |
mtaylor | Daviey: see openstack mailing list - I somehow forgot to explicitly add you to the phonebook-like list of people | 16:17 |
Daviey | mtaylor: bet it was intentional :P | 16:18 |
notmyname | mtaylor: good post | 16:18 |
bcwaldon | soren: This branch is waiting on your review -> https://code.launchpad.net/~ken-pepple/nova/lp828596/+merge/72310 | 16:18 |
notmyname | mtaylor: 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 |
mtaylor | notmyname: damn. that would have been one more thing I could have added to that list :) | 16:19 |
bcwaldon | kpepple_: that's fine, just wanted him to see these things get fixed :) | 16:19 |
mtaylor | Daviey: and yes - it was a deliberate attack on you. | 16:20 |
Daviey | mtaylor: heh.. knew it.. well you failed.. I was on the CC. :) | 16:20 |
mtaylor | Daviey: dammit jaypipes! stop lying to me! | 16:20 |
Daviey | notmyname: Where are those branches kept, for RAX packaging? | 16:20 |
*** jsavak has quit IRC | 16:20 | |
*** joesavak has quit IRC | 16:21 | |
*** joesavak has joined #openstack-dev | 16:21 | |
notmyname | mtaylor: 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 |
notmyname | Daviey: ^ | 16:21 |
*** jsavak has joined #openstack-dev | 16:22 | |
mtaylor | notmyname: well - we could totally do a static repo for each version | 16:22 |
*** RobertLaptop has joined #openstack-dev | 16:22 | |
mtaylor | notmyname: I was already thinking static repo for each major release series, but per version would be easy enough | 16:22 |
notmyname | mtaylor: 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 code | 16:23 |
Daviey | notmyname: Doesn't look that active? | 16:23 |
mtaylor | notmyname: coupla quick questions re: that ... when you say "every version" - you mean each swift release, right? not each commit-generated package | 16:23 |
mtaylor | notmyname: ++ to know version of code | 16:23 |
notmyname | Daviey: how do you mean? we update ot for every release we do | 16:23 |
notmyname | mtaylor: ya, every release | 16:24 |
mtaylor | notmyname: for the "static repo for each version" approach, you'd likely be fine with a _second_ repo for the backported depends, yah? | 16:24 |
Daviey | notmyname: Ahh, you are not tracking development snapshots? | 16:24 |
jaypipes | notmyname: what about non-Lucid? Is that somewhere else? | 16:25 |
mtaylor | notmyname: 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 |
notmyname | Daviey: 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 openstack | 16:25 |
bcwaldon | jaypipes: gonna get the swift branch done today? | 16:25 |
bcwaldon | jaypipes: I know you're swamped ;) | 16:25 |
notmyname | jaypipes: no non-lucid. we target last LTS | 16:25 |
jaypipes | bcwaldon: it's already done. | 16:25 |
jaypipes | bcwaldon: waiting on shep to give feedback on a customer system. | 16:25 |
jaypipes | notmyname: gotcha | 16:25 |
jaypipes | notmyname: just curious :) | 16:25 |
glenc | ant, do we have Yagi set up in Alpha yet? | 16:25 |
notmyname | jaypipes: next LTS and we'll have non-lucid :-) | 16:26 |
bcwaldon | jaypipes: okay, all I can go on is what's in gerrit... | 16:26 |
mtaylor | notmyname: 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 |
vishy | soren: ping | 16:26 |
glenc | oops, wrong window. sorry | 16:26 |
notmyname | mtaylor: I don't think we'd have much use for a per commit package | 16:26 |
mtaylor | notmyname: no, I don't expect you would | 16:26 |
jaypipes | bcwaldon: right, sorry, I'll add a comment saying "ready to re-review..." | 16:26 |
bcwaldon | jaypipes: did you address the test failure? | 16:26 |
Daviey | notmyname: nice patch :) https://github.com/crashsite/swift_debian/blob/master/patches/debian-changes-1.0.2-1 | 16:26 |
mtaylor | notmyname: I'm most curious about the backported depends part and how you'd like to model that | 16:26 |
notmyname | wow, I didn't expect to get this many responses ;-). unfortunately, I have a meeting I have to run off to now | 16:27 |
jaypipes | bcwaldon: talking about the uneven chunk number thing? | 16:27 |
mtaylor | notmyname: GAH | 16:27 |
mtaylor | notmyname: I will keep bugging you about backport depends. :) | 16:27 |
openstackjenkins | Project 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 again | 16:27 |
openstackjenkins | - OSAPI v1.1 rebuild will accept adminPass or generate a new one, returning it in a server entity | 16:27 |
openstackjenkins | - OSAPI v1.0 will generate a new password, but it doesn't communicate it back to the user | 16:27 |
openstackjenkins | * Tarmac: add rainy day test to to_global | 16:27 |
openstackjenkins | fixed to_global to catch correct error from incorrect mac addresses | 16:27 |
openstackjenkins | * Tarmac: similar to lp828614: add rainy day test and fix exception error catch to AddrFormatError | 16:27 |
Daviey | notmyname: I think you are getting interest, because it's the first some of us have heard about it :) | 16:27 |
bcwaldon | jaypipes: no, the unittest shep pointed out related to 'checksum' | 16:27 |
notmyname | mtaylor: yes, do. and ping florian too | 16:27 |
jaypipes | bcwaldon: hmm, lemme check... might have not seen that. | 16:27 |
notmyname | Daviey: it's not been a secret (we've talked about it here before). just something we don't really advertise | 16:28 |
bcwaldon | jaypipes: and I think there are merge conflicts | 16:28 |
Daviey | notmyname: oh aye. I knew you had packages.. | 16:28 |
jaypipes | bcwaldon: :( ok, gimme a few. | 16:28 |
bcwaldon | jaypipes: cheer up, jay! | 16:28 |
redbo | We also do our own packages for cloudfiles because some functionality we use has been removed from openstack packages. | 16:28 |
redbo | And 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 |
jaypipes | bcwaldon: :( | 16:29 |
_0x44 | redbo: 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 |
jaypipes | bcwaldon: just rebased to master.. no merge conflicts. | 16:32 |
bcwaldon | jaypipes: hmm, maybe I was seeing things | 16:32 |
*** jsavak has quit IRC | 16:33 | |
*** joesavak has quit IRC | 16:33 | |
*** markmc has quit IRC | 16:33 | |
*** joesavak has joined #openstack-dev | 16:34 | |
*** jsavak has joined #openstack-dev | 16:34 | |
s1rp_ | jaypipes: not sure what the status of lp820090; i wasn't able to reproduce the issue bcwaldon was seeing with the unit-test | 16:35 |
mtaylor | Daviey: tell me something ... why the HELL have people started listing python depends that look like this: 2.6.6-3~ ? | 16:36 |
mtaylor | Daviey: it makes backporting things senslessly brutal | 16:37 |
bcwaldon | s1rp_: 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 |
bcwaldon | s1rp_: We resolved that. It was the echo -n problem | 16:38 |
s1rp_ | bcwaldon: actually, on second thought, yeah.. exactly | 16:38 |
Daviey | mtaylor: Used to say > than just before X, i think. Depends on the context. :/ | 16:38 |
bcwaldon | s1rp_: I think this is a different bug | 16:38 |
bcwaldon | s1rp_: isn't this fixed? | 16:39 |
mtaylor | Daviey: well ... it's giving me hives :) | 16:39 |
s1rp_ | bcwaldon: hmm, not sure... checking trunk | 16:39 |
bcwaldon | s1rp_: https://review.openstack.org/#change,199 | 16:40 |
bcwaldon | s1rp_: 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 yet | 16:40 |
s1rp_ | bcwaldon: they're the same (AFAIK), bug just didn't get marked Fix Commited | 16:41 |
bcwaldon | s1rp_: I'd support you in that satement :) | 16:41 |
Daviey | mtaylor: Good :) | 16:41 |
*** zns has quit IRC | 16:42 | |
s1rp_ | jaypipes: bcwaldon: ok just marked lp820090 as "Fix Committed" | 16:42 |
mtaylor | Daviey: https://code.launchpad.net/~mordred/swift/fix-python-depend/+merge/72753 please review me | 16:43 |
redbo | exhibit one: ^ :) | 16:44 |
*** blamar has joined #openstack-dev | 16:44 | |
Capashen | jaypipes, 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 do | 16:52 |
*** mfer is now known as mfer-lunch | 16:55 | |
*** zns has joined #openstack-dev | 16:56 | |
*** Capashen has quit IRC | 16:59 | |
zul | mtaylor: dh_python2 transition is happening in oneiric | 17:07 |
mtaylor | zul: ok. say words to me about that | 17:07 |
mtaylor | zul: nm. found the page | 17:08 |
zul | mtaylor: i can point you to a wiki page: http://wiki.debian.org/Python/TransitionToDHPython2 | 17:08 |
mtaylor | zul: is that going to mean horrible badness for our backport things? or will the fact that we also backport debhelper be fine? | 17:09 |
mtaylor | zul: OH - I see the thing in the wiki page | 17:10 |
mtaylor | zul: why in the HELL do they have that version requirement? | 17:10 |
mtaylor | zul: that makes me livid angry | 17:10 |
zul | mtaylor: python-supprot and python-central has been deprecated | 17:11 |
zul | and i cant spell | 17:11 |
mtaylor | zul: that's fine. they both suck anyway | 17:11 |
*** mfer-lunch is now known as mfer | 17:11 | |
mtaylor | why does that mean I need to depend on 2.6.6-3~ though? | 17:11 |
zul | im not 100% sure | 17:12 |
zul | you might have to backport debhelper, i think debian has a backport project that you might want to look at as well | 17:13 |
mtaylor | they do - but last time I checked it was not what I needed | 17:14 |
mtaylor | sigh | 17:14 |
*** novas0x2a|laptop has joined #openstack-dev | 17:14 | |
* mtaylor needs to have yet another bitch session about the life of an upstream dev at the next UDS | 17:14 | |
mtaylor | I'm guessing that this: "dh_python2: egg renaming fixed" is the reason that they're saying 2.6.6-3~ is required | 17:14 |
mtaylor | thing is - I _REALLY_ don't want to maintain a backport of python in our repo | 17:15 |
mtaylor | nor 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-oneiric | 17:15 |
* mtaylor may just start punching random people | 17:15 | |
mtaylor | zul: are you ok with not listing 2.6.6-3~ until something starts breaking? | 17:16 |
openstackjenkins | Project burrow build #34: SUCCESS in 11 sec: https://jenkins.openstack.org/job/burrow/34/ | 17:16 |
openstackjenkins | Tarmac: More docs for backend modules. | 17:16 |
zul | mtaylor: not really because its a requirement for getting it into main | 17:17 |
*** ecarlin has quit IRC | 17:17 | |
mtaylor | zul: ASS ASS ASS ASS ASS | 17:17 |
mtaylor | zul: (that's not at you, just at the situation) | 17:17 |
zul | mtaylor: sure sure :) | 17:17 |
mtaylor | ok, welp- we're going to have to maintain extra forky backport branches now | 17:18 |
mtaylor | BALLS ASS ASS BALLS | 17:18 |
* mtaylor is very angry at debian and ubuntu right now | 17:18 | |
mtaylor | VERY ANGRY | 17:18 |
mtaylor | as in, they can suck it angry | 17:18 |
mtaylor | making 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 joke | 17:19 |
mtaylor | and should cease being used | 17:20 |
* mtaylor calms down | 17:23 | |
mtaylor | zul: sorry for ranting | 17:23 |
zul | mtaylor: no worries | 17:23 |
Daviey | mtaylor: need more detail? | 17:23 |
mtaylor | zul: 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 this | 17:24 |
mtaylor | except that the new thing still needs to be mostly like the old thing | 17:24 |
mtaylor | Daviey: I want to punch someone in the face | 17:24 |
zul | yeah suckey | 17:24 |
mtaylor | Daviey: no, I GET it - I just think it was handled terribly | 17:25 |
Daviey | mtaylor: So, i'm still missing enough context. | 17:25 |
mtaylor | Daviey: let me sum up | 17:25 |
mtaylor | Daviey: oneiric main contains a hard requirement that python packages depend on python-all (>= 2.6.6-3~) | 17:26 |
mtaylor | Daviey: so, if we're taking our current approach, which is package for current dev and then just make renamed packages for backports | 17:26 |
Daviey | mtaylor: seems so. | 17:26 |
mtaylor | Daviey: then maverick and lucid backports stop working | 17:26 |
Daviey | mtaylor: ok | 17:26 |
zul | is maverick actually supported anymore? | 17:26 |
mtaylor | Daviey: I am NOT going to push new python v into the openstack ppa (because that's ridiculous) | 17:26 |
mtaylor | by us it is | 17:27 |
mtaylor | but that's beside the point | 17:27 |
mtaylor | because LUCID also breaks | 17:27 |
mtaylor | and that is supported even by canonical | 17:27 |
Daviey | I don't thik you need to backport python! | 17:27 |
mtaylor | so the process problem remains even so | 17:27 |
mtaylor | of course I don't | 17:27 |
Daviey | mtaylor: So.. You were on the call i had with you 2 weeks ago? | 17:27 |
mtaylor | BUT - I will need to maintain divergent packaging for pre-natty | 17:27 |
Daviey | mtaylor: which is exactly as we agreed, no? | 17:28 |
mtaylor | Daviey: no. I was on no call where we discussed divergent packaging | 17:28 |
mtaylor | the only thing we discussed on that call was packaging change approvals - and riots | 17:28 |
mtaylor | I mean - it's irrelevant, because we have to do it. :) | 17:28 |
Daviey | mtaylor: So, we DID discuss having snapshot packages for supported releases. | 17:29 |
Daviey | Such as, lp:~openstack-ubuntu-packagers/ubuntu/natty/glance/ubuntu | 17:29 |
Daviey | That banch get maintains for natty etc | 17:29 |
Daviey | it's not development version, which is always tip | 17:29 |
openstackjenkins | Project nova build #1,292: SUCCESS in 3 min 10 sec: https://jenkins.openstack.org/job/nova/1292/ | 17:29 |
openstackjenkins | Tarmac: Fixes iscsiadm commands to run properly. | 17:29 |
mtaylor | Daviey: I think we're using too many words that are too similar here | 17:29 |
Daviey | mtaylor: Okay, perhaps we should have made notes from that call. | 17:30 |
mtaylor | Daviey: it's fair - I didn't make them either :) | 17:30 |
Daviey | lp:~openstack-ubuntu-packagers/glance/ubuntu <-- Always development version of ubuntu. | 17:30 |
mtaylor | Daviey: yes. | 17:30 |
Daviey | when we get near or at a ubuntu release, lp:~openstack-ubuntu-packagers/ubuntu/RELEASE/glance/ubuntu gets cut | 17:30 |
mtaylor | Daviey: and is used to build packages against glance trunk | 17:30 |
Daviey | So we always planned to have multiple branches per release | 17:31 |
Daviey | a one size fits all is unlikely to work | 17:31 |
mtaylor | ok. that's different from that I'm talking about | 17:31 |
mtaylor | and, not to be too snarky, not at all what I'm caring about at the moment | 17:31 |
Daviey | is it? | 17:31 |
mtaylor | yes | 17:31 |
mtaylor | that's about ubuntu cutting releases and being able to maintain those moving forward | 17:31 |
Daviey | mtaylor: It sounds to me that you want a one-size branch for all releases, no? | 17:31 |
mtaylor | what I'm talking about is being able to build a trunk package for an old release | 17:31 |
mtaylor | well, that's what we have right now | 17:32 |
Daviey | distro releases, not openstack | 17:32 |
mtaylor | yes. trunk openstack for old distro | 17:32 |
Daviey | so this is *exactly* what you are talking about. | 17:32 |
mtaylor | well yeah - I get the mechanism you're talking about | 17:32 |
Daviey | lp:~openstack-ubuntu-packagers/glance/ubuntu <-- build trunk natty packages from that, for exaple. | 17:32 |
mtaylor | all 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 one | 17:33 |
Daviey | ^^ once natty is released.. Ubuntu does not really care about that branch. | 17:33 |
uvirtbot | Daviey: Error: "^" is not a valid command. | 17:33 |
Daviey | It's purely for PPA support, aiui | 17:33 |
mtaylor | Daviey: right. sorry, this is why I said we're talking about different things | 17:33 |
mtaylor | because _I_ don't care about natty being released | 17:33 |
Daviey | mtaylor: Yes.. i get that. | 17:33 |
mtaylor | sorry ... I feel like we're REALLY close to getting each other here :) | 17:34 |
Daviey | mtaylor: a quick call might help? | 17:34 |
mtaylor | Daviey: possibly - all I'm saying is, I get _how_ we can do the divergent packaging branches per distro release | 17:34 |
mtaylor | it's just that up until now there was no technical need on openstack's side to do so | 17:35 |
mtaylor | and, other than ubuntu main inclusion, there still isn't | 17:35 |
Daviey | mtaylor: This was always going to happen... | 17:35 |
mtaylor | because it's only an ubuntu main inclusion POLICY thing that's causing the divergence | 17:35 |
Daviey | You don't think openstack can support every supported release for ever, based on one branch do you? | 17:35 |
mtaylor | and so I'm angry that a policy choice and not a technical one forced the diverge | 17:35 |
mtaylor | no. I didn't - I knew at some point we were going to hit it - I'm just miffed at the why | 17:36 |
*** jsavak has quit IRC | 17:36 | |
*** joesavak has quit IRC | 17:36 | |
Daviey | mtaylor: I think you are putting too much weight into policy. | 17:37 |
mtaylor | cause 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 python | 17:37 |
mtaylor | so the hard depend line is meaningless | 17:37 |
mtaylor | and yet makes using that control file unchanged for maverick impossible | 17:37 |
mtaylor | that's what I'm saying | 17:38 |
mtaylor | it's not that GLANCE actually needs 2.6.6-3~ | 17:38 |
mtaylor | it doesn't | 17:38 |
mtaylor | so that build depend require is encoding a need that doesn't need to be expressed because it's implicit in the platform | 17:38 |
vladimir3p | folks, 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. Thanks | 17:39 |
*** SpamapS has joined #openstack-dev | 17:41 | |
*** joesavak has joined #openstack-dev | 17:45 | |
*** jsavak has joined #openstack-dev | 17:45 | |
*** zns has quit IRC | 17:47 | |
chmouel | sandywalsh: 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 repo | 17:47 |
chmouel | or should I create a new pull req? | 17:48 |
sandywalsh | chmouel, I'd just make a new pull request. Easier | 17:48 |
*** zns has joined #openstack-dev | 17:51 | |
openstackgerrit | Kevin L. Mitchell proposed a change to openstack/glance: Add functional tests https://review.openstack.org/333 | 17:53 |
mtaylor | chmouel, sandywalsh: speaking of python-novaclient ... who's the right contact person to talk to about getting that migrated to gerrit? | 17:53 |
chmouel | not sure tbh | 17:54 |
jaypipes | Vek: rock on. | 17:56 |
*** rnirmal has quit IRC | 17:56 | |
zykes- | hmmm, wonder if i can use openshift with openstack | 17:57 |
sandywalsh | mtaylor, 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 IRC | 17:57 | |
openstackgerrit | Jay Pipes proposed a change to openstack/glance: Fixes LP Bug #827660 - Swift driver fail 5G upload https://review.openstack.org/311 | 18:00 |
uvirtbot | Launchpad bug 827660 in glance "Cannot store files greater than 5GB in Swift" [Critical,In progress] https://launchpad.net/bugs/827660 | 18:00 |
*** Capashen has joined #openstack-dev | 18:01 | |
*** ecarlin has joined #openstack-dev | 18:03 | |
mtaylor | sandywalsh: 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 moving | 18:04 |
mtaylor | sandywalsh: (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 IRC | 18:06 | |
*** joesavak has quit IRC | 18:06 | |
*** joesavak has joined #openstack-dev | 18:06 | |
zykes- | what's not a official project ? | 18:06 |
bcwaldon | jaypipes: deploying your latest swift patchset to functionally test | 18:06 |
*** jsavak has joined #openstack-dev | 18:07 | |
jaypipes | bcwaldon: rock on. | 18:09 |
zykes- | is there any .debs for diablo out ? | 18:20 |
mtaylor | zykes-: tons of them - for what? | 18:22 |
zykes- | swift, nova, glance | 18:22 |
zykes- | guess there's nothing yet for keystone etc | 18:22 |
mtaylor | publishing today | 18:25 |
mtaylor | had to sort out a few build deps in the ppa | 18:25 |
zykes- | for keystone ? | 18:25 |
zykes- | ooh, nice | 18:25 |
*** mnour has joined #openstack-dev | 18:28 | |
*** mfer has quit IRC | 18:29 | |
*** hisaharu has quit IRC | 18:30 | |
*** mfer has joined #openstack-dev | 18:31 | |
jaypipes | Vek, _cerberus_: excellent work on the functional keystone tests. great stuff. | 18:33 |
*** hisaharu has joined #openstack-dev | 18:35 | |
sandywalsh | mtaylor, sounds good, we certainly want to follow the herd. Is there a laundry list of the steps required anywhere? | 18:36 |
openstackgerrit | Jay Pipes proposed a change to openstack/glance: Fixes LP Bug #827660 - Swift driver fail 5G upload https://review.openstack.org/311 | 18:38 |
uvirtbot | Launchpad bug 827660 in glance "Cannot store files greater than 5GB in Swift" [Critical,In progress] https://launchpad.net/bugs/827660 | 18:38 |
*** jakedahn has joined #openstack-dev | 18:44 | |
bcwaldon | jaypipes: is the change in glance/api/v1/images.py going to cause any weirdness wrt image size | 18:45 |
openstackgerrit | A change was merged to openstack/glance: Fixes LP Bug #827660 - Swift driver fail 5G upload https://review.openstack.org/311 | 18:56 |
uvirtbot | Launchpad bug 827660 in glance "Cannot store files greater than 5GB in Swift" [Critical,In progress] https://launchpad.net/bugs/827660 | 18:56 |
bcwaldon | jaypipes: ! | 18:56 |
openstackgerrit | Kevin L. Mitchell proposed a change to openstack/glance: Add functional tests https://review.openstack.org/333 | 18:56 |
_cerberus_ | jaypipes: thanks man :-) | 18:59 |
zykes- | mtaylor: was there packages for keystone coming ? | 19:00 |
*** ecarlin has quit IRC | 19:00 | |
*** jsavak has quit IRC | 19:03 | |
*** joesavak has quit IRC | 19:03 | |
clayg | jaypipes, bcwaldon: in swift deleting the large object manifest doesn't delete the chunks | 19:03 |
*** zns has quit IRC | 19:03 | |
bcwaldon | clayg: I actually saw that too, but blamed it on cloud files acting poorly. I was having trouble with my account while testing. | 19:04 |
bcwaldon | clayg: I'll file a bug | 19:04 |
clayg | also 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 read | 19:05 |
bcwaldon | clayg: if you think it | 19:05 |
zykes- | should one run swift service vms on compute nodes? like nova nodes | 19:05 |
clayg | maybe I shouldn't throw stones - it's not like I'm going to rewrite it :D | 19:05 |
bcwaldon | clayg: ...'s a simple fix, I would encourage you to merge prop :) | 19:05 |
ttx | vishy: yo | 19:10 |
*** joesavak has joined #openstack-dev | 19:12 | |
*** jsavak has joined #openstack-dev | 19:12 | |
*** zns has joined #openstack-dev | 19:13 | |
ttx | vishy: backporting my fix to MP | 19:15 |
*** mattray has quit IRC | 19:15 | |
zykes- | MP ? | 19:16 |
*** mattray has joined #openstack-dev | 19:17 | |
*** zns has quit IRC | 19:17 | |
ttx | zykes-: milestone-proposed | 19:18 |
ttx | http://wiki.openstack.org/BranchModel | 19:18 |
zul | mtaylor: ping around still? | 19:18 |
*** med_out has joined #openstack-dev | 19:19 | |
ttx | vishy: for your approve pleasure at https://code.launchpad.net/~ttx/nova/mp820962/+merge/72775 | 19:19 |
sandywalsh | so, 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 medberry | 19:20 | |
medberry | "as part of OpenStack" | 19:20 |
* ttx will regret "bzr lp-open" | 19:20 | |
ttx | sandywalsh: I think that's Vish's plan for Essex, yes | 19:21 |
jaypipes | notmyname: https://bugs.launchpad.net/glance/+bug/833285. Could use your insight... | 19:27 |
uvirtbot | Launchpad bug 833285 in glance "swift store delete only removes manifest" [High,Confirmed] | 19:27 |
notmyname | jaypipes: working as designed | 19:29 |
notmyname | the manifest file is separate | 19:30 |
notmyname | you (the client) is responsible for managing the parts of a large object | 19:30 |
*** ecarlin has joined #openstack-dev | 19:31 | |
jaypipes | notmyname: well, poop. :) | 19:31 |
notmyname | jaypipes: 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 parts | 19:32 |
notmyname | so you don't have to keep a list of the parts | 19:32 |
jaypipes | notmyname: ya, that's what I was thinking, too... | 19:32 |
jaypipes | notmyname: coolio. I'll get that done. | 19:32 |
notmyname | jaypipes: 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 |
mtaylor | zul: whazzup? | 19:33 |
zul | mtaylor: can you add a openstack-dashboard tarball as well? | 19:34 |
mtaylor | zul: yes. | 19:35 |
zul | mtaylor: thanks | 19:35 |
openstackjenkins | Project nova-milestone build #20: SUCCESS in 19 sec: https://jenkins.openstack.org/job/nova-milestone/20/ | 19:37 |
openstackjenkins | Tarmac: Correcting OSAPI v1.1 rebuild | 19:37 |
openstackjenkins | Project nova build #1,293: SUCCESS in 3 min 12 sec: https://jenkins.openstack.org/job/nova/1293/ | 19:37 |
openstackjenkins | Tarmac: 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 |
jaypipes | notmyname: will do. thx for the heads up! | 19:38 |
vishy | ttx: thanks | 19:55 |
*** jakedahn has quit IRC | 19:55 | |
*** jakedahn has joined #openstack-dev | 19:56 | |
*** jakedahn_ has joined #openstack-dev | 19:59 | |
*** jakedahn_ has joined #openstack-dev | 19:59 | |
*** zns has joined #openstack-dev | 20:01 | |
*** jakedahn has quit IRC | 20:02 | |
*** jakedahn_ is now known as jakedahn | 20:02 | |
*** zns has quit IRC | 20:06 | |
*** ecarlin has quit IRC | 20:07 | |
bengrue | What does "ffe" stand for? | 20:09 |
bengrue | f___ for essex? | 20:09 |
mtaylor | bengrue: "feature freeze exception" | 20:09 |
bengrue | fuuuuuuuuuuuuuu for essex? | 20:09 |
medberry | Feature Freeze Exception ? | 20:09 |
bengrue | ah. | 20:09 |
bengrue | thanks. | 20:09 |
zykes- | mtaylor: was there packages incoming for keystone ? | 20:09 |
mtaylor | zykes-: yes | 20:10 |
zykes- | oh, eta ? | 20:10 |
*** ecarlin has joined #openstack-dev | 20:10 | |
mtaylor | zykes-: https://launchpad.net/~keystone-core/+archive/trunk | 20:11 |
mtaylor | zykes-: they are queues | 20:11 |
mtaylor | queued | 20:11 |
ttx | bengrue: we are slowing down on features, at least until essex opens (Sep 8) | 20:15 |
bengrue | yeah, got it. | 20:15 |
bengrue | I was confused until I put together the "ffe" with the "disapprove:" before it. | 20:16 |
ttx | the idea being to fix more bugs than we add, avoid last-minute regressions... | 20:16 |
bengrue | Now sense is made. | 20:16 |
ttx | and help the doc team getting some stable picture. | 20:16 |
ttx | (and let the downstream packagers catch up) | 20:16 |
bengrue | Ah, Thierry! Okay. | 20:17 |
ttx | and... you got the picture :) | 20:17 |
bengrue | Still mapping names to irc-names; learning the environ; etc. | 20:17 |
bengrue | yeah, got it. | 20:17 |
*** Capashen has quit IRC | 20:20 | |
*** mwhooker has joined #openstack-dev | 20:21 | |
vishy | dprince: ping | 20:24 |
vishy | blamar: hey is dprince around? | 20:27 |
vishy | bcwaldon: ^^ | 20:27 |
bcwaldon | vishy: just headed out | 20:27 |
bcwaldon | vishy: email | 20:27 |
vishy | ah ok was going to ask him to backport this to milestone proposed: https://code.launchpad.net/~dan-prince/nova/ec2_admin_noauth/+merge/72647 | 20:28 |
vishy | but i can do it | 20:28 |
bcwaldon | vishy: might as well, it's pretty simple | 20:28 |
openstackjenkins | Project burrow build #35: SUCCESS in 11 sec: https://jenkins.openstack.org/job/burrow/35/ | 20:31 |
openstackjenkins | Tarmac: Added client API unit tests, moved exceptions to main burrow module, and added more WSGI frontend tests. | 20:31 |
ttx | ok, going to get some evening back. See you in ~10 hours | 20:34 |
vishy | tr3buchet: our networking changes broke a pretty common use case | 20:34 |
tr3buchet | vishy: uh oh | 20:42 |
tr3buchet | vishy: what happened? | 20:42 |
vishy | bcwaldon: 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 |
vishy | tr3buchet: we are storing the interface for vlans in the networks table now | 20:42 |
bcwaldon | vishy: 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 |
bcwaldon | vishy: should I remake a branch for you? | 20:43 |
tr3buchet | vishy: right | 20:43 |
*** ameade has quit IRC | 20:43 | |
vishy | what if you are plugged into a different eth device | 20:43 |
vishy | ? | 20:43 |
tr3buchet | vishy: i'm pretty sure i made that change | 20:43 |
vishy | what if some hosts are plugged in to eth3 for example | 20:43 |
tr3buchet | what if what is plugged into a different eth device? | 20:43 |
tr3buchet | oh | 20:43 |
vishy | yeah, oops :( | 20:44 |
tr3buchet | nonhomogeneous hosts? | 20:44 |
vishy | we probably need to change the flag to override the value from the db | 20:44 |
vishy | or have an override flag of some sort | 20:44 |
tr3buchet | i only see 3 scenarios, homogeneous hosts, nonhomogeneous hosts, or changing things up mid go | 20:45 |
vishy | nonhomog happens in a lot of deploys | 20:45 |
tr3buchet | i wasn't aware | 20:45 |
tr3buchet | within the same zone? | 20:45 |
vishy | for example, sometimes there are two nics on network hosts and only one on compute | 20:45 |
vishy | admittedly most deployers can probably constrain to one eth device if they have to | 20:46 |
vishy | but there are failure scenarios where you want to switch | 20:46 |
bcwaldon | vishy: looking at rev 1148 in milestone-proposed, it seems like the branch went in cleanly | 20:46 |
vishy | for example if one of the eth devices fails | 20:46 |
tr3buchet | hmmm, we can coopt the bridge_interface parameter | 20:46 |
tr3buchet | well bridge interface comes from either flat_interface or vlan_interface | 20:47 |
vishy | bcwaldon: ah didn't realize it merged already. Yes looks like it didn't pull in any other revissions | 20:47 |
tr3buchet | vishy: 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 db | 20:47 |
bcwaldon | vishy: yeah, I'll be more careful next time | 20:47 |
*** code_franco has joined #openstack-dev | 20:48 | |
vishy | bcwaldon: no worries :) | 20:48 |
vishy | tr3buchet: i think that makes sense | 20:48 |
tr3buchet | i've been wanting to yank those two flags for a while anyway | 20:48 |
tr3buchet | want me to take a stab at it? is there a bug filed yet? | 20:49 |
*** AhmedSoliman has joined #openstack-dev | 20:50 | |
*** raker has joined #openstack-dev | 20:55 | |
*** zns has joined #openstack-dev | 21:04 | |
*** ecarlin has quit IRC | 21:04 | |
vladimir3p | vish: ping | 21:08 |
vladimir3p | vishy: ping | 21:09 |
vishy | hey | 21:09 |
vladimir3p | vishy: hey. Just pushed last part of changes for volume types | 21:09 |
zykes- | mtaylor: is dashboard also getting built ? | 21:09 |
vishy | vladimir3p: I saw that | 21:10 |
vladimir3p | vishy: any chance to get review? | 21:10 |
mtaylor | zykes-: no. that's on my todo list | 21:10 |
zykes- | ah | 21:10 |
vishy | yes i will review it once i finish catching up on emails | 21:10 |
vladimir3p | vishy: cool, thanks. another question: | 21:10 |
vladimir3p | vishy: 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 |
vladimir3p | vishy: if I will merge the code and propose it, the system will think that this is one huge proposal ... | 21:12 |
vishy | in the merge proposal | 21:12 |
vishy | if you put in prereq-branch | 21:13 |
vishy | (it is in the advanced settings) it will ignore the changes from that branch in the diff | 21:13 |
vladimir3p | vishy: cool !!! thanks | 21:13 |
vishy | so put in the volume-type code as a prereq for vsa | 21:13 |
*** zns1 has joined #openstack-dev | 21:14 | |
zykes- | vsa ? | 21:15 |
vladimir3p | zykes-: VSA==Virtual Storage Array | 21:17 |
*** zns has quit IRC | 21:19 | |
*** martine has quit IRC | 21:21 | |
vladimir3p | vishy: btw, can you pls change volume types blueprint assignee to me? thanks | 21:23 |
vishy | sure | 21:23 |
vishy | vladimir3p: did you end up using any stuff from Ben/mcgrue? | 21:23 |
*** lts has quit IRC | 21:25 | |
vladimir3p | vishy: 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 scratch | 21:26 |
vishy | ok | 21:27 |
*** mfer is now known as mfer-food | 21:33 | |
zykes- | vladimir3p: that is ? | 21:33 |
exlt | soren: I stopped reading when I hit "Debian releases are rare and unpredictable." - seriously: grow the fuck up. | 21:34 |
vladimir3p | zykes-: new multi-tenant block storage for nova. The idea is to allow different storage vendors to deploy their storage stacks/RAIDs in VMs | 21:34 |
zykes- | hmm | 21:34 |
zykes- | blueprint? | 21:34 |
vladimir3p | zykes-: https://blueprints.launchpad.net/nova/+spec/nova-virtual-storage-array | 21:35 |
*** amccabe has quit IRC | 21:35 | |
soren | exlt: Err.. It's true. They're years apart and you never know ahead of time when they happen. | 21:35 |
soren | exlt: ...and that's fine. That's how Debian works. | 21:36 |
exlt | they are nearly clockwork at ~24 months, give or take a few months | 21:36 |
soren | Exactly. | 21:36 |
soren | ? | 21:36 |
soren | It happens when it happens. It's not something you can plan your own release cycle by. | 21:37 |
exlt | LTS 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 way | 21:37 |
soren | Again: This is fine. I don't think it's a bad thing for Debian to do this. | 21:37 |
soren | It's just a bad thing for us to sync with. Because we can't. | 21:37 |
soren | Ubuntu's releases are stable in the sense that they stop being in flux at predictable times, which is exactly what we need. | 21:38 |
soren | exlt: 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 |
exlt | well, 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 whole | 21:40 |
notmyname | /topic | 21:41 |
*** letterj has joined #openstack-dev | 21:41 | |
*** ChanServ sets mode: +v letterj | 21:41 | |
*** scotticus has joined #openstack-dev | 21:41 | |
*** letterj has left #openstack-dev | 21:41 | |
exlt | heh | 21:42 |
exlt | point taken | 21:42 |
*** letterj has joined #openstack-dev | 21:42 | |
*** ChanServ sets mode: +v letterj | 21:42 | |
exlt | but I think it is dev-related | 21:43 |
notmyname | exlt: no, I was looking for the evesdrop link. I thought it was in the topic | 21:43 |
soren | exlt: I'd be happy to discuss this somewhere else. I'm geniuinely confused what the problem is. | 21:43 |
mtaylor | so - not to wade in and make things worse ... | 21:43 |
notmyname | exlt: and I inadvertently had a space in the input field | 21:44 |
*** mfer-food is now known as mfer | 21:44 | |
soren | exlt: I think Debian is great. I really do. When I grow up, I want to be a DD. | 21:44 |
mtaylor | but 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 distro | 21:44 |
soren | exlt: 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 |
mtaylor | soren: yeah? | 21:44 |
exlt | that 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 immature | 21:44 |
soren | exlt: Can you help me improve, then? | 21:45 |
soren | I don't understand how I'm being immature. | 21:45 |
*** zns1 has quit IRC | 21:46 | |
exlt | since 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 advice | 21:47 |
soren | I can assure you it will never change if you won't even tell me what the problem is. | 21:48 |
notmyname | ok, personal attacks probably aren't good for anyone. keep away from that, and it's a good discussion | 21:48 |
mtaylor | notmyname: ++ | 21:48 |
mtaylor | I'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 scope | 21:49 |
zykes- | exlt: why quit the project ? | 21:49 |
vishy | bcwaldon: if you are still here can you smokestack lp:~vladimir.p/nova/volume_type_extradata ? i don't seem to be able to login | 21:50 |
bcwaldon | vishy: yep | 21:50 |
exlt | zykes-: I went back to school after 25ish years :-) (no longer work at Rackspace) | 21:50 |
zykes- | oh | 21:50 |
zykes- | that's sad ;p | 21:50 |
bcwaldon | vishy: running meow | 21:51 |
*** jsavak has quit IRC | 21:51 | |
*** joesavak has quit IRC | 21:51 | |
vishy | thx | 21:51 |
creiht | soren: so I'm curious what OS you would run a production cluster on? | 21:51 |
creiht | (and version) | 21:51 |
soren | creiht: Depends on what I'll run on said cluster. | 21:51 |
soren | creiht: (other than the OS) | 21:52 |
soren | ...and how much time I have available to deal with it. | 21:52 |
exlt | I 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 issues | 21:52 |
notmyname | soren: 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 have | 21:52 |
soren | Ubuntu for sure. Version: Depends. | 21:52 |
creiht | soren: if you were running Rackspace operations for their Nova deployment, what version of Ubuntu would you run | 21:53 |
creiht | Or any isp wanting to set up their cloud | 21:53 |
soren | creiht: Crack-of-the-day Nova? | 21:53 |
creiht | and perhaps a better question for everyone, is who are packages for... developers? deployment? | 21:54 |
mtaylor | soren: how about the upcoming diablo release | 21:54 |
soren | I probably wouldn't run that in production at all :) | 21:54 |
soren | mtaylor: Oneiric. | 21:54 |
* creiht sighs | 21:54 | |
mtaylor | creiht: and I would argue that packages are for deployment | 21:54 |
mtaylor | creiht: I'm pretty sure devs are doing to pip install or whatnot | 21:54 |
creiht | soren: so you would run an os that only has support for 6 months in a production setup? | 21:54 |
soren | creiht: a) It's 18 months. | 21:55 |
notmyname | mtaylor: devs will install from source with their latest topic branch ;-) | 21:55 |
soren | creiht: ..and b) I'd upgrade come LTS release time (next April). | 21:55 |
soren | creiht: ..and stay there for "a while". | 21:55 |
mtaylor | notmyname: yes. that's what I meant - with any depends installed via venv or pip | 21:55 |
creiht | so 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 |
creiht | I guess what I am getting at, is that most people who are going to do production deployments are going to use LTS | 21:56 |
soren | Yeah, and I woulnd't test it either. | 21:56 |
soren | Duh. | 21:56 |
creiht | and I am wondering how LTS is any different than debian release scheduling? | 21:56 |
soren | For one: It's predictable. | 21:57 |
* exlt sighs.. | 21:57 | |
soren | For 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 |
soren | exlt: 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 |
soren | exlt: 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 |
exlt | soren: sorry, I don't really understand what you are referring to | 22:01 |
soren | exlt: Your comment at 21:52 UTC. | 22:01 |
creiht | https://wiki.ubuntu.com/LTS | 22:02 |
creiht | A new LTS version is usually released every 2 years | 22:02 |
creiht | *usually* | 22:02 |
creiht | https://wiki.ubuntu.com/PReleaseSchedule | 22:02 |
creiht | While no decision to make this release an LTS has been made, here are the Ubuntu LTS Release Details | 22:02 |
creiht | I'm still uncertain how that is any more certain that what Debian provides? | 22:02 |
exlt | soren: ah - that had absolutely nothing to do with code or anything - that was in answer to how I might help you improve | 22:03 |
soren | exlt: I see. | 22:03 |
exlt | oh, and that I do think personality plays a role in dev | 22:03 |
soren | Sure. | 22:03 |
exlt | particularly if people speak loudly and tend to drown others out | 22:03 |
creiht | But circling back around to what notmyname was saying, the current packaging situation is not working for any current real production deployments | 22:04 |
exlt | right | 22:04 |
creiht | I apploud mtaylor's efforts in wanting to fix that | 22:04 |
creiht | soren: perhaps you could email the mailing list how you could propose fixing those issues? | 22:04 |
creiht | if you don't agree with mtaylor? | 22:04 |
exlt | oh, he did. | 22:05 |
soren | creiht: I think I made it quite clear that I don't. | 22:05 |
exlt | that's why I started typing a little bit ago | 22:05 |
soren | Take the Swift packaging for instance. | 22:05 |
mtaylor | which brings me back to the point that I believe soren and I have different definitions of what the good outcome here is | 22:05 |
soren | The Swift team decided to fork the packaging. | 22:05 |
exlt | soren: you are not listening.. | 22:06 |
soren | If it's really because I didn't keep the packaging in git, I'm just speechless. | 22:06 |
creiht | soren: I think that has been hashed through several times already | 22:06 |
exlt | git is not the issue | 22:06 |
mtaylor | I think this has very very little to do with git v. bzr | 22:06 |
soren | Please explain what it is then (that I didn't already point out in my e-mail). | 22:07 |
notmyname | our packaging came first...how is that a fork? ;-) | 22:07 |
creiht | lol | 22:07 |
mtaylor | there are two things ... one is where the packaging gets published - that has nothing to do with git v. bzr in any case | 22:07 |
mtaylor | the other thing is how the packaging is worked on | 22:07 |
soren | I 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 | |
creiht | soren: like I said, that has already been hashed through, I'm not sure I can say anything more that hasn't already been said | 22:08 |
creiht | if you still don't understand, I'm sorry | 22:08 |
soren | So am I. | 22:08 |
soren | Is it different from what I point out in my e-mail? | 22:08 |
mtaylor | for how the packaging is worked on, where it is worked on at this point communicates a specific focus, and has some specific connotations | 22:08 |
mtaylor | if 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 collaborate | 22:09 |
soren | creiht: Namely that Rackspace expects to want different behaviour of the packages in certain situations and so wants to have separate packaging. | 22:09 |
soren | creiht: Is that completely off? | 22:09 |
mtaylor | if we align process with OpenStack, then we have similar tooling for OpenStack folks to use, and we can produce an OpenStack output | 22:10 |
*** code_franco has quit IRC | 22:10 | |
* creiht sighs | 22:10 | |
soren | mtaylor: A couple of months ago, everything used the same tooling. The situation was the same. | 22:10 |
mtaylor | soren: tooling isn't what I'm talking about | 22:10 |
mtaylor | it's process | 22:10 |
mtaylor | packaging did NOT use the same process as the rest of openstack | 22:10 |
*** alekibango has quit IRC | 22:11 | |
soren | Right. | 22:11 |
notmyname | soren: 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 it | 22:11 |
soren | notmyname: That sounds like reasons for having a different repository. Not different packaging? | 22:12 |
*** alekibango has joined #openstack-dev | 22:12 | |
mtaylor | it 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 out | 22:12 |
*** alekibango has quit IRC | 22:12 | |
*** alekibango has joined #openstack-dev | 22:12 | |
mtaylor | I 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 repo | 22:12 |
notmyname | soren: number 2 means our own packaging. we need to include code that isn't in the openstack repo | 22:12 |
soren | mtaylor: This was also done for specific reasons. | 22:13 |
mtaylor | we might not be able to and notmyname may still have to run his own | 22:13 |
soren | notmyname: Oh? What sort of stuff? | 22:13 |
mtaylor | soren: 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 output | 22:13 |
notmyname | mtaylor: the first requirement is the big one that openstack packaging can "fix", IMO. the second is a separate issue | 22:13 |
mtaylor | notmyname: agree. | 22:14 |
mtaylor | notmyname: 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 |
notmyname | mtaylor: agreed | 22:14 |
notmyname | soren: it doesn't matter what sort of stuff. | 22:14 |
bcwaldon | vishy: your smokestack jobs passed, btw | 22:15 |
soren | notmyname: It would help my understanding. Are we talking about patches to Swift itself od or packaging differences? | 22:15 |
soren | s/ od // | 22:15 |
notmyname | soren: patches to swift that need to land in our production deployment before an openstack release happens | 22:16 |
soren | notmyname: Ok. | 22:16 |
notmyname | soren: 2 recent examples are container metadata and quarantine improvements | 22:16 |
notmyname | recent == within the pat 6 months | 22:17 |
soren | Ok. | 22:18 |
soren | I'm still missing why that required maintaining completely separate packaging, though. | 22:19 |
letterj | vishy: 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 IRC | 22:20 | |
*** gholt has joined #openstack-dev | 22:20 | |
* gholt waves | 22:20 | |
notmyname | soren: 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 solved | 22:20 |
soren | notmyname: You've had commit access to the packaging branch all along, though. | 22:21 |
soren | notmyname: (all of swift-core has) | 22:21 |
gholt | I 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 |
gholt | What OS packaging wants/needs seems to be different with what I've needed/wanted and that's fine. | 22:22 |
gholt | I 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 |
openstackgerrit | Yogeshwar Srikrishnan proposed a change to openstack/keystone: Redefining credential types. https://review.openstack.org/334 | 22:23 |
gholt | Also, 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 |
gholt | I didn't have time to track what was up, so I went to the easy-stand-by: do it yerself | 22:24 |
gholt | Which was easy since I was already doing it myself before OS anyway. :) | 22:24 |
alekibango | i think what openstack really needs is good testing. | 22:25 |
gholt | That's probably enough from me. :D | 22:25 |
*** gholt has left #openstack-dev | 22:25 | |
*** RobertLaptop has quit IRC | 22:26 | |
soren | notmyname: Can you explain how? I'm clearly missing something. | 22:26 |
creiht | I would also like to pipe in that what mtaylor is proposing would likely solve a lot of the issues that we had initially with packaging | 22:26 |
notmyname | soren: how what? how mtaylor addressed things? just that these were they issues (or the types of issues) that he mentioned in his first emal | 22:27 |
notmyname | 22:27 | |
soren | creiht: If I ask what those were are you just going to sigh again? Because that's getting old. | 22:27 |
soren | notmyname: Well, yes, he mentioned them, but how are the changes he's making solving this? | 22:27 |
notmyname | soren: 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 |
vishy | vladimir3p: reviewed | 22:29 |
creiht | soren: the same thing that gholt has said, the same thing that we have repeatedly said on IRC and the mailing lists | 22:30 |
creiht | I'm at a loss how we can make it any clearer to you | 22:30 |
creiht | mtaylor seems to get our issues (as with many others which can be seen from the mailing list responses) | 22:31 |
vladimir3p | vishy: thanks. any issues (aside of rebase)? | 22:31 |
vishy | didn't see any. Got a pep error but i think it is in trunk | 22:31 |
Daviey | creiht: many people are also NOT responding, as I don't think it will help. | 22:31 |
vishy | because it didn't look like you made any changes to the file that had the error | 22:31 |
Daviey | creiht: Please be aware that soren is not alone in frustrations and concerns. | 22:32 |
vladimir3p | vishy: yep, there are 2 of them in trunk and I decided to leave them | 22:32 |
dabo | I see 3 pep errors in trunk | 22:32 |
vishy | did our pep gate get turned off? | 22:32 |
creiht | Daviey: would any of those people *not* be on the Ubuntu team? | 22:32 |
vladimir3p | vishy: regarding to rebase. does 1479 an official D4? | 22:32 |
vishy | 1479 is where we branched milestone-proposed | 22:33 |
creiht | but yeah, this isn't going much anywhere now | 22:33 |
creiht | time for dinner | 22:33 |
vladimir3p | vishy: how about changes after 1479? | 22:33 |
vishy | vladimir3p: actually | 22:33 |
vishy | we aren't trying to get this into d4 are we? | 22:34 |
vladimir3p | vishy: yep | 22:34 |
vishy | there is an FFE for merging after d4 | 22:34 |
Daviey | creiht: Yes, because Debian packaging hasn't exactly been a smooth ride. | 22:34 |
notmyname | Daviey: 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 |
vishy | so I don't think you need to do the rebase after all | 22:34 |
Daviey | notmyname: Where did you get that data? | 22:34 |
soren | Daviey: notmyname *is* a major deployer. | 22:35 |
vladimir3p | vishy: great! thre are some changes that we would like to have (like small one you've done for iscsiadm) | 22:35 |
vishy | yes that is in d4 already | 22:35 |
Daviey | soren: A or THE? | 22:35 |
vladimir3p | vishy: so, should I leave it as is? | 22:35 |
vishy | yes | 22:35 |
vladimir3p | vishy: great, thanks | 22:35 |
* notmyname agrees with chuck. not much more to be resolved right now. time to go home | 22:37 | |
soren | Daviey: It's free software. No way to know :) | 22:37 |
vladimir3p | folks, any chance to get more eyes on https://code.launchpad.net/~vladimir.p/nova/volume_type_extradata/+merge/72762 ? thanks | 22:42 |
*** mattray has quit IRC | 22:44 | |
*** mfer has quit IRC | 22:59 | |
tr3buchet | 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~5~ | 23:03 |
tr3buchet | vishy: you never answered my question | 23:04 |
vishy | ah sorry didn't see that | 23:05 |
vishy | there is a question but no bug | 23:05 |
tr3buchet | alright i'll create a bug and start working on it | 23:05 |
vishy | tr3buchet: https://answers.launchpad.net/nova/+question/169041 | 23:06 |
vishy | can you link the bug there? | 23:06 |
vishy | thx | 23:06 |
letterj | vishy: Did you see my question? | 23:06 |
tr3buchet | sure | 23:07 |
vishy | letterj: not a whole lot of docs there | 23:08 |
vishy | :) | 23:08 |
vishy | any showstopper bugs that anyone knows about for D-4? | 23:10 |
vishy | we have 8 hrs to get anything else into the milestone | 23:10 |
*** bengrue has quit IRC | 23:11 | |
tr3buchet | vishy: you want this in the milestone? | 23:12 |
vishy | tr3buchet: no | 23:13 |
tr3buchet | https://bugs.launchpad.net/nova/+bug/833426 | 23:13 |
uvirtbot | Launchpad bug 833426 in nova "Nonhomogeneous networks not supported" [Undecided,New] | 23:13 |
tr3buchet | k good. i didn't want to stay up all night messing with it | 23:13 |
vishy | d4 is fine without it, edge case, but we want it in D-final | 23:13 |
tr3buchet | sure. | 23:13 |
vishy | tr3buchet: 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 |
vishy | I know it was probably painful to get up to speed | 23:16 |
tr3buchet | vishy: no problem | 23:17 |
tr3buchet | vishy: anything else i can help with to get this out the door? | 23:18 |
openstackgerrit | James E. Blair proposed a change to openstack/openstack-ci: Add watch_deploy script. https://review.openstack.org/335 | 23:19 |
vishy | tr3buchet: only if you know of some bugs that i haven't found that need to make milestone | 23:19 |
*** JStoker has quit IRC | 23:20 | |
tr3buchet | i do not! | 23:20 |
tr3buchet | \o/ | 23:20 |
*** medberry is now known as med_out | 23:25 | |
*** RobertLaptop has joined #openstack-dev | 23:27 | |
openstackgerrit | A change was merged to openstack/openstack-ci: Add watch_deploy script. https://review.openstack.org/335 | 23:29 |
*** bsza has quit IRC | 23:29 | |
*** jakedahn has quit IRC | 23:39 | |
*** jakedahn has joined #openstack-dev | 23:39 | |
*** novas0x2a|laptop has quit IRC | 23:45 | |
*** gholt has joined #openstack-dev | 23:54 | |
gholt | soren: 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 |
gholt | Don't take it personal if some crazy operator does something else. :) | 23:56 |
mtaylor | gholt: well, yes. HOWEVER, if I could actually meet your needs that would be stellar | 23:56 |
mtaylor | if I don't, that's cool too | 23:56 |
gholt | Yeah | 23:57 |
mtaylor | I 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 IRC | 23:57 | |
gholt | Hehe. 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 |
mtaylor | because, 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 better | 23:58 |
mtaylor | and it's things like that which I want to fix | 23:58 |
gholt | But, 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 |
mtaylor | openstack isn't exactly like a desktop file indexer | 23:59 |
mtaylor | totally | 23:59 |
mtaylor | I 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 thing | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!