| *** winston-d has joined #openstack-dev | 00:30 | |
| *** lorin1 has joined #openstack-dev | 00:55 | |
| *** sutidba has joined #openstack-dev | 01:08 | |
| *** lorin1 has quit IRC | 01:40 | |
| *** sutidba has quit IRC | 02:25 | |
| *** lorin1 has joined #openstack-dev | 03:37 | |
| *** lorin1 has quit IRC | 03:39 | |
| *** sutidba has joined #openstack-dev | 03:39 | |
| *** sutidba has quit IRC | 04:48 | |
| *** stevezd has quit IRC | 04:49 | |
| *** stevezd has joined #openstack-dev | 04:50 | |
| *** sutidba has joined #openstack-dev | 04:52 | |
| *** sutidba has quit IRC | 04:52 | |
| *** reidrac has joined #openstack-dev | 07:05 | |
| *** AhmedSoliman has joined #openstack-dev | 08:10 | |
| HugoKuo | thanks for any suggestion https://answers.launchpad.net/nova/+question/163798 | 09:49 |
|---|---|---|
| chmouel | hey soren any chance to add a || : to the modprobe nbd in init script of nova-compute | 10:49 |
| chmouel | for host that doensn't (it rackspace cloud servers) have it to not fail | 10:50 |
| *** AhmedSoliman has quit IRC | 11:01 | |
| *** markvoelker has joined #openstack-dev | 11:14 | |
| soren | chmouel: That'll just delay the failure, won't it? | 11:20 |
| soren | chmouel: We don't "modprobe ndb" because we're bored. We do it because we need nbd to be available. | 11:20 |
| soren | notmyname: python-webob updated in glance-core/trunk (lucid, maverick, and natty) | 11:53 |
| chmouel | yeah but in case we want to install for quick testing and dev deployment on a cloudservers where the nbd part is not tested... | 12:11 |
| soren | How so? | 12:29 |
| chmouel | testing puppet recipes for examples on a cloud servers | 12:31 |
| chmouel | or I could create a dummy nbd.ko that does nothing if you don't like to add that but that's a bit of a strech for testing | 12:32 |
| *** Binbin has joined #openstack-dev | 12:35 | |
| notmyname | soren: thanks | 12:58 |
| soren | chmouel: Well, your tests would be false. With nbd, your install won't actually *work*. Reporting success would be a lie. | 13:01 |
| soren | chmouel: Err... *without* nbd, I mean. | 13:01 |
| chmouel | or i can just compile proper nbd module for cs | 13:02 |
| soren | That would be ideal. | 13:04 |
| soren | I wanted to do that at some point, but lacked the proper kernel headers and config. | 13:05 |
| soren | (not being in the mood to screw around with pvgrub) | 13:05 |
| chmouel | let's see if major can give us that | 13:06 |
| *** dweimer_ is now known as dweimer | 13:10 | |
| chmouel | soren: that should do it curl -onbd.ko -L http://goo.gl/gDmpl && insmod nbd.ko | 13:30 |
| chmouel | ubuntu maverick from RS Cloud | 13:30 |
| *** dprince has joined #openstack-dev | 13:38 | |
| *** negronjl has joined #openstack-dev | 13:52 | |
| *** jkoelker has joined #openstack-dev | 14:03 | |
| *** kbringard has joined #openstack-dev | 14:09 | |
| *** kbringard has quit IRC | 14:20 | |
| *** kbringard has joined #openstack-dev | 14:20 | |
| *** vladimir3p has joined #openstack-dev | 14:22 | |
| *** jaypipes has joined #openstack-dev | 14:25 | |
| *** cp16net_ has joined #openstack-dev | 14:34 | |
| notmyname | ttx: ping. I'd like to talk about bringing swift more in line with last week's PPB decision (component rather than project) | 14:37 |
| ttx | notmyname: let me grab a drink first. | 14:38 |
| notmyname | to dull the pain? ;-) | 14:39 |
| chmouel | lol | 14:39 |
| notmyname | ttx: I briefly chatted with gholt this morning. I missed some of the conversation you had this weekend | 14:40 |
| notmyname | ttx: I think the major points to discuss are versioning and release schedules. are there other things too? | 14:41 |
| *** scotticus has joined #openstack-dev | 14:41 | |
| ttx | notmyname: not on the top of my mind (from a release management perspective) | 14:42 |
| notmyname | ok | 14:42 |
| *** gholt has joined #openstack-dev | 14:42 | |
| notmyname | ttx: should we move to a nova-esque versioning scheme? | 14:42 |
| ttx | notmyname: that would be ideal from a "product" perspective, but I've yet to find a way of doing it that preserves the "milestones are production-ready" aspect of Swift, being a stable project | 14:44 |
| notmyname | ttx: well, should we even advertise that "milestones are production-ready"? | 14:44 |
| gholt | If RAX is going to use them in prod, then yes? | 14:45 |
| notmyname | ttx: if it's all components of a single project, then it doesn't make sense to release half of it one way. | 14:45 |
| ttx | notmyname: I think so. We can't expect that with components of varying degrees of stability, all will use the same distribution channels for the same things | 14:45 |
| ttx | hmm | 14:46 |
| *** dprince has quit IRC | 14:46 | |
| gholt | Oh, I get your point. Component | 14:46 |
| ttx | notmyname: I guess there are two solutions | 14:46 |
| gholt | How do you release a component to the world and not the project. | 14:46 |
| notmyname | gholt: I would say that you don't | 14:46 |
| ttx | notmyname: pure version number alignment, which is good to present an uniform view of "OpenStack core projects" | 14:47 |
| gholt | ttx: btw, we're now irc, posterous, wordpress, twitter, and gist. Maybe a bit of email too, I can't remember. :) | 14:47 |
| ttx | in which case you release every 6 months, which means you probably need to have your own RAX internal releases for internal deployment purpose | 14:47 |
| ttx | gholt: I bet we can split it even more :) | 14:48 |
| notmyname | ttx: (which we will have regardless) | 14:48 |
| gholt | I would really like to have publicly acknowledged RAX releases, but I don't know how to do that within the OpSt-is-one-project thing. | 14:48 |
| notmyname | gholt: agreed | 14:49 |
| ttx | But I agree with gholt that a stable component should be "released" more often than every 6 months... so we could also say "milestones are production-ready" | 14:49 |
| notmyname | for the project as a whole, perhaps swift as a separate release should be downplayed | 14:49 |
| ttx | in my mind we provide three distribution channels, all valid for some kind of use | 14:50 |
| ttx | one is the per-commit, the other is the monthly, the last one is the 6-months | 14:50 |
| gholt | I think we're still talking autonomy, heh. | 14:50 |
| ttx | At this point, Nova is only production-ready every 6 months, so it uses the "6months" as production-ready | 14:51 |
| gholt | But, yeah, we could unofficially declare swift milestones as prodready | 14:51 |
| ttx | At this point Swift is stable enough so that the monthly is production-ready | 14:51 |
| ttx | Could come a time where the per-commit would also be production-ready | 14:51 |
| notmyname | ttx: I would argue that we shouldn't be talking about nova as production ready or swift as production ready if they are both components | 14:51 |
| gholt | ttx: Doubtful | 14:51 |
| gholt | ttx: There's /real/ qa that needs to be done for a release, which OpSt isn't doing (yet) | 14:52 |
| gholt | notmyname: Yeah, it'd have to be unofficial-but-everyone-knows-whats-up I think. :/ | 14:52 |
| ttx | gholt: if you don't commit that often anymore, you could hook the QA system to the commit tests | 14:52 |
| ttx | gholt: so it could happen, one day :) | 14:53 |
| gholt | ttx: Yes, but that's not 100% "certified". QA may have to write a new test, etc. | 14:53 |
| ttx | notmyname: I think we need to accept the fact that the different components have verying degrees of stability | 14:53 |
| gholt | ttx: There really have to be people involved in certifying something as prodready | 14:53 |
| ttx | varying* | 14:53 |
| ttx | notmyname: so the main difference is the versioning | 14:54 |
| ttx | notmyname: the advantage of the current versioning is that it makes it clear that milestoens are as good as 6month releases | 14:55 |
| ttx | the drawback is that it dilutes the "product" aspect | 14:55 |
| gholt | It's a bit dichotomatic. One project! But multiple stages of stability and release packages. | 14:55 |
| notmyname | ttx: but if openstack is the project and swift, nova, keystone, etc are all components, then we should do a release for the project, not components | 14:56 |
| ttx | gholt: yes.. you can think of it as the linnux kernel, I guess. subcomponents definitely have varying degrees of stability | 14:56 |
| gholt | Yeah, but you don't release production ready kernel 2.6.32.xfs etc, etc. | 14:56 |
| gholt | There's just one kernel release (and lots of unofficial ones, but anyway...) :) | 14:56 |
| ttx | notmyname: right, so one way to do it is to adopt the common versioning | 14:56 |
| ttx | while still communicating that milestones are in fact QAed, so not just for evaluation purposes | 14:57 |
| gholt | So, I mean, if we take the kernel approach, an OpenStack release is only all prodready components. | 14:57 |
| ttx | one drawback of common versioning is that it won't let you insert milestones easily | 14:57 |
| ttx | (what we discussed with gholt) | 14:58 |
| notmyname | ttx: unless the last stanza of the version string is a milestone for the project | 14:58 |
| notmyname | 2011.d4-swift7 | 14:58 |
| gholt | Yeah, but I am okay with ~diablo-3rax1 for instance. | 14:58 |
| ttx | true, we can insert diablo-3.1 | 14:59 |
| gholt | I mean, it's not ideal from my point of view; but I don't rule the world. :) | 14:59 |
| ttx | I hope it would be exceptional enough (i.e. a feature that can't wait 2-3 weeks) | 14:59 |
| *** heckj has joined #openstack-dev | 14:59 | |
| notmyname | ttx: it should be (especially from us [rax] who are doing our own swift packaging anyway) | 15:00 |
| ttx | notmyname: the other difference is how the last milestone is handled (though that's still a bit up in the air for Nova/Glance) | 15:00 |
| ttx | notmyname: one option is to cut diablo-4 and open Essex at the same time, then use the last 4 weeks to push only bugfixes to the milestone-proposed branch and cut a release from it | 15:01 |
| notmyname | ttx: I prefer an openstack release to take the last tested milestone for the release rather than new dev work between the last milestone and the final release | 15:01 |
| ttx | so you can still work on features in Essex | 15:01 |
| notmyname | ttx: ya, so the last milestone becomes, essentially, a rc1 | 15:01 |
| ttx | the drawback of that approach is that there is 8 weeks between diablo-4 and essex-1 | 15:02 |
| ttx | hmm... we could do an essex-1 around the same time as diablo release though. | 15:02 |
| ttx | to "release" the work that was done in trunk while milestone-proposed was maturing | 15:03 |
| notmyname | ttx: that only seems to matter if the milestones are something more that checkpoint releases | 15:03 |
| ttx | notmyname: sure, but I'm trying to address the "time-to-market" concern that gholt raised | 15:03 |
| notmyname | ttx: if the project is released as prod-ready only once every 6 months, then a gap between diablo-X and essex-Y is not that important | 15:03 |
| ttx | time-based makes sense if it's often enough | 15:03 |
| *** Vasichkin has joined #openstack-dev | 15:04 | |
| ttx | notmyname: fwiw we are working to automate the milestone release so much that it won't be costly to do one anymore | 15:05 |
| ttx | especialy an essex-0 one that is not expected to be QAed, for example | 15:05 |
| notmyname | that's great. but I think that perhaps reinforces that milestones shouldn't be "prod-ready certified" | 15:05 |
| *** lorin1 has joined #openstack-dev | 15:06 | |
| gholt | I think that's what we're all coming to grips with. :) | 15:06 |
| gholt | RAX releases will just have to be unofficial-but-what-we-use. | 15:06 |
| gholt | RAX!=OpSt I think we have to get used to that. | 15:06 |
| ttx | notmyname: I still think that a component with good QA track record in its "milestone" channel will generate a lot of attention for that channel | 15:07 |
| gholt | In my opinion, of course. hehe | 15:07 |
| ttx | Like Chrome does | 15:07 |
| notmyname | gholt: as we have said all along, that will be the way other deployers work too. so it shouldn't be a big deal | 15:07 |
| gholt | ttx: What do you mean by the Chrome thing? I'm not familiar | 15:08 |
| ttx | Chrome is released through three channels. Daily, Beta and Release | 15:08 |
| gholt | Ah, Release is pretty infrequent I take it? | 15:08 |
| ttx | it's like every 3 months | 15:08 |
| gholt | Gotcha, the Beta is the 3 week thing | 15:09 |
| ttx | but the Beta channel was proven to be quite usable | 15:09 |
| ttx | so people started using it to get the latest and greatest faster | 15:09 |
| gholt | Yeah, I see, that's fine by me. milestones aren't OpSt supported, but Swift milestones are used in prod by RAX, so... I get it. | 15:09 |
| ttx | As long as we all have the same channels, I don't mind if people realize that Swift "milestone" channel is actually as stable as the release and start using that. | 15:10 |
| notmyname | gholt: swift milestones may or may not be the exact version we use at rax | 15:10 |
| soren | ttx: I took the liberty of amending the tarmac config so that tests are also run before merges into the nova and glance milestone branches are accepted. | 15:10 |
| gholt | notmyname: True, just a general "feeling" folks would get, though not 100% always true. | 15:10 |
| notmyname | indeed :-) | 15:10 |
| ttx | soren: ack | 15:10 |
| gholt | ttx: As a for instance, during certain times rax won't be able to release a milestone to our prod. | 15:11 |
| gholt | ttx: Which means that milestone won't be as tested (by rax qa). | 15:11 |
| ttx | gholt: right | 15:11 |
| gholt | There's currently no way to indicate that, but maybe it's not important. | 15:11 |
| ttx | gholt: Ideally we'd move as much of what RAX qa does to the continuous integration system | 15:12 |
| notmyname | doesn't seem as important to me since the project is what we are promoting, not the components | 15:12 |
| gholt | ttx: Yeah, but I don't see that happening unless OpSt wants to spend a /lot/ of money. :) | 15:13 |
| gholt | ttx: But... they might. Who knows | 15:13 |
| ttx | gholt: ok, then it also makes sense that project milestones are not strictly dependent on RAX internal QA. | 15:14 |
| ttx | as we basically separate them. | 15:14 |
| notmyname | I agree with that | 15:14 |
| ttx | better that they happen on the same milestones, but we shouldn't guarantee that | 15:14 |
| notmyname | essentially, OS will have their own release cycle and RAX will cut and QA their own internal releases as needed. they may or may not line up with milestones | 15:15 |
| *** reidrac has quit IRC | 15:15 | |
| ttx | since "the project" has no way to force RAX to do QA on a specific branch. | 15:15 |
| notmyname | and for our sanity (those of us who work on swift at rax) we would want then to line up as much as possible, but there is nothing forcing that | 15:15 |
| *** mdomsch has joined #openstack-dev | 15:15 | |
| ttx | notmyname: so the idea would be to adopt the common milestone plan ? Milestones every 4 weeks ? | 15:16 |
| notmyname | to me that seems most in line with the recent PPB decision | 15:16 |
| ttx | notmyname: that's the sanest way of acting as a component of a product, indeed | 15:17 |
| ttx | then we could force any project that is core to follow the same plan | 15:17 |
| notmyname | indeed (I still don't agree with that decision, but I'm trying to go along as best I can ;-) ) | 15:17 |
| ttx | which definitely reinforces the "common project" aspect | 15:17 |
| ttx | notmyname: I appreciate that. | 15:18 |
| notmyname | s/agree/like/ | 15:18 |
| ttx | notmyname: I'll think about the versioning change and see how we can proceed | 15:19 |
| notmyname | ttx: so I would propose that instead of swift 1.4.2 we move to whatever is the common scheme and whenever the next milestone is | 15:19 |
| ttx | notmyname: that would make it diablo-3 on July 28 | 15:20 |
| ttx | by then the "version in progress" is changed to 2011.3 | 15:20 |
| notmyname | which is probable when we'd do the next milestone anyway (in the old swift-as-a-project model) | 15:20 |
| ttx | notmyname: my hope is that we don't disrupt you too much in that alignment process, so that's good | 15:21 |
| ttx | notmyname: btw, if "every-4-weeks" is always wrong for you, we can certainly decide a different (common) frequency at the next design summit | 15:21 |
| ttx | notmyname: I'll give it some extra thought, in case there is something I missed | 15:23 |
| gholt | ttx: notmyname: Sorry, wandered off. I'm cool with what you guys have been discussing. BTW, we joked we should rename PTLs to CTLs. ;) | 15:25 |
| *** Binbin has quit IRC | 15:25 | |
| ttx | heh | 15:26 |
| *** lorin1 has quit IRC | 15:46 | |
| *** lorin1 has joined #openstack-dev | 15:47 | |
| zul | soren: im in the middle of packaging quantum and keystone for ubuntu, i was thinking of something like 2011.d3~<date> for a package version | 15:55 |
| *** cp16net_ has quit IRC | 15:59 | |
| vladimir3p | Folks, HELP !!! Was there any change related to NBD or networking. I suddenly noticed that I couldn't access newly spawned instances in my dev environment. I'm using FlatDHCP mode and it seems like IPs are assigned properly from fixed range pool. At the same time I can ping IP of my bridge, but can't ping instance's IP | 16:08 |
| vladimir3p | the only strange thing I noticed in nova-compute.log is inability to operate with nbd | 16:08 |
| vladimir3p | in another enviromnet (working with nova from 2-3 weeks) there are no nbd-related messages at all and everything works as expected. But nova.conf files are identical | 16:09 |
| jaypipes | vishy: ^^? | 16:12 |
| *** cp16net_ has joined #openstack-dev | 16:12 | |
| *** gholt has left #openstack-dev | 16:37 | |
| *** foxtrotdelta has joined #openstack-dev | 16:49 | |
| *** sutidba has joined #openstack-dev | 16:49 | |
| *** cp16net_ has quit IRC | 16:53 | |
| *** jdurgin has joined #openstack-dev | 16:54 | |
| *** cp16net_ has joined #openstack-dev | 16:59 | |
| *** ohnoimdead has joined #openstack-dev | 17:07 | |
| vishy | vladimir3p any odd messages in the console log? | 17:12 |
| *** jaypipes has quit IRC | 17:14 | |
| *** sutidba has quit IRC | 17:15 | |
| *** kbringard has quit IRC | 17:15 | |
| *** kbringard has joined #openstack-dev | 17:15 | |
| *** mgius has joined #openstack-dev | 17:18 | |
| *** jaypipes has joined #openstack-dev | 17:28 | |
| mtaylor | zul: so - that's actually a thing soren and I have been talking about - how to do trunk versions on projects that are on github in general | 17:30 |
| zul | mtaylor: yeah i talking to ttx about it last week | 17:30 |
| mtaylor | zul: since we need a monotonically increasing number ... date will be tricky because there can be multiple trunk commits in a given day | 17:30 |
| zul | mtaylor: right in my case i usually take a snapshot though | 17:30 |
| mtaylor | zul: I'm thinking that using the jenkins build number might not be a terrible idea for the trunk packages we automatically cut | 17:31 |
| mtaylor | zul: I'm not sure what you mean by "take a snapshot" | 17:31 |
| zul | mtaylor: a weekly upload of an openstack project | 17:31 |
| creiht | mtaylor: they should be uuids :) | 17:31 |
| mtaylor | creiht: haha. funny :) | 17:31 |
| notmyname | ttx: jbryce has asked me to not unwind the current state for things with swift until later. so all that stuff we talked about this morning: let's hold off for now (ie don't change anything yet) | 17:31 |
| mtaylor | zul: you and I may be trying to solve slightly separate problems then | 17:32 |
| mtaylor | zul: I'm talking about the packages we cut on every commit to trunk | 17:32 |
| zul | mtaylor: right thats not so interesting for me since i care about only one really | 17:32 |
| mtaylor | zul: which is automatic/automated ... and thus the need for an increasing number so that package versions are properly increasing | 17:33 |
| mtaylor | zul: for your weekly snapshots, what are you using those for (what is their aim?) | 17:33 |
| zul | mtaylor: so our users who use the ubuntu archive to get their packages | 17:33 |
| mtaylor | zul: ah - so that's a thing we'll probably want to align with ttx ... | 17:34 |
| zul | mtaylor: right | 17:34 |
| mtaylor | zul: (I'm still having my first coffee, so I might be a little slow) | 17:35 |
| mtaylor | ttx: some back! | 17:35 |
| zul | mtaylor: heh thats ok im always slow :) | 17:35 |
| *** kbringard has quit IRC | 17:48 | |
| *** kbringard has joined #openstack-dev | 17:48 | |
| *** nati has joined #openstack-dev | 17:54 | |
| *** nati has quit IRC | 18:01 | |
| *** nati has joined #openstack-dev | 18:01 | |
| *** cp16net__ has joined #openstack-dev | 18:06 | |
| *** cp16net_ has quit IRC | 18:07 | |
| *** dprince has joined #openstack-dev | 18:21 | |
| *** bcwaldon has joined #openstack-dev | 18:22 | |
| *** mszilagyi has joined #openstack-dev | 18:25 | |
| ttx | notmyname: sure | 18:39 |
| *** zaitcev has joined #openstack-dev | 18:40 | |
| ttx | mtaylor: let me read backlog | 18:40 |
| ttx | mtaylor, zul: it's kinda the same issue, since you want the "snapshot" packages to be upgraded from and to PPA packages | 18:43 |
| ttx | so they need to use the same rule | 18:43 |
| ttx | mtaylor: I think soren's idea was to use a Jenkins-local increment. So using the jenkins build number sounds the simplest | 18:44 |
| mtaylor | ttx: cool. that's what I was thinking | 18:45 |
| zul | cool | 18:45 |
| ttx | though we also discussed an easy way to link back to the github reference | 18:45 |
| zul | whats the jenkins local-increment anyways? | 18:45 |
| ttx | I mean the git commit id | 18:45 |
| mtaylor | zul: each job in jenkins has a job id which always increases - it's not special - it's just a source of an always increasing number (so that packages know how to upgrade from one another properly) | 18:46 |
| zul | mtaylor: right | 18:47 |
| mtaylor | ttx: I'm all ears on that second one - maybe jeblair will have good thoughts on that on friday | 18:47 |
| ttx | mtaylor: but doing 2011.3~d3~20110704.1245-6d4e3a4d8b9e9e0f-0ubuntu1~oneiric1 will be a bit long :) | 18:47 |
| zul | i would like still have a release cut for oneiric for quantum and keystone though | 18:47 |
| mtaylor | ttx: yes. on the other hand- who really cares if it's long? | 18:47 |
| zul | i do | 18:48 |
| zul | :) | 18:48 |
| mtaylor | zul: well yes - we just have to make sure that the actual release version compares numerically properly to the trunk releases | 18:48 |
| zul | mtaylor: right | 18:48 |
| mtaylor | zul, so 2011.3~d3~20110704.1245-6d4e3a4d8b9e9e0f-0ubuntu1~oneiric1 would lead to the release of 2011.3~d3 which would lead to the release of 2011.3 | 18:49 |
| ttx | mtaylor: being able to link to the date and commit ID while still properly incrementing indeed has value | 18:49 |
| mtaylor | ttx: for the trunk commit-based packages, I think that having the git id in there is not problematic - and for the larger releases (2011.3~d3 or 2011.3) - we should have tags in the repo anyway | 18:50 |
| ttx | mtaylor: IIRC we discussed showing the first 4 char or so of the commitID. But maybe full ID makes more sense | 18:50 |
| ttx | mtaylor: just ask soren when he'll be back | 18:51 |
| mtaylor | ttx: getting all of this sorted is my #1 priority this week - so I might be a bit annoying about it this week | 18:54 |
| ttx | mtaylor: let me annoy you first. Could you change the reviewer team on the three lp:~hudson-openstack/*/milestone-proposed branches to ~openstack-release ? | 18:57 |
| ttx | vishy: ping | 18:59 |
| mtaylor | ttx: done | 18:59 |
| ttx | cool, thanks | 18:59 |
| vishy | ttx: pong | 19:00 |
| ttx | vishy: I'd like some time with you before the meeting today... whenever it suits you best | 19:00 |
| vishy | during the cancelled poc meeting? | 19:01 |
| ttx | vishy: sure. | 19:01 |
| vishy | s/poc/ppb | 19:01 |
| nati | CI Meeting? | 19:07 |
| ttx | mtaylor: ^ | 19:10 |
| *** johnpur has joined #openstack-dev | 19:22 | |
| *** ChanServ sets mode: +v johnpur | 19:22 | |
| *** lorin1 has quit IRC | 19:34 | |
| *** vladimir3p_ has joined #openstack-dev | 19:37 | |
| *** ameade has joined #openstack-dev | 19:39 | |
| *** vladimir3p has quit IRC | 19:39 | |
| vladimir3p_ | vishy: Hi, sorry was away. There is nothing strange in console. compute.log complains about inability to access /dev/ndb14 and... "instance instance-00000087: ignoring error injecting data into image 3 (Unexpected error while running command" | 19:43 |
| vishy | i actually meant in the vm log | 19:44 |
| vladimir3p_ | vishy: but instance is shown as running with assigned fixed IP. Its console shows instance name (i-00...) and time | 19:44 |
| vishy | if you only get instance name and time then your kernel is not booting | 19:44 |
| vishy | usually that happens when you try to boot a 64 bit kernel on a 32 bit host or the image is corrupted somehow | 19:45 |
| vladimir3p_ | vishy: ok ... it is a standart tty image ... | 19:45 |
| vishy | perhaps it didn't download properly from glance? | 19:45 |
| vladimir3p_ | vishy: hm.. probably. I switched to glance recently | 19:45 |
| vladimir3p_ | vishy: let me see how glance recognizes them... | 19:45 |
| vishy | you have glance_servers flag set? | 19:46 |
| vishy | I think it just creates a 0K file if it fails to download sometimes | 19:46 |
| vladimir3p_ | vishy: in nova conf I have --image_service=nova.image.glance.GlanceImageService and --glance_api_servers=my_ip | 19:47 |
| vladimir3p_ | Found 2 public images... | 19:47 |
| vladimir3p_ | ID Name Disk Format Container Format Size | 19:47 |
| vladimir3p_ | ---------------- ------------------------------ -------------------- -------------------- -------------- | 19:47 |
| vladimir3p_ | 4 psp3 raw ovf 795391330 | 19:47 |
| vladimir3p_ | 3 tty-anso raw ovf 24346106 | 19:47 |
| *** BK_man is now known as BK_man_ | 19:47 | |
| vishy | that doesn't look right | 19:47 |
| vishy | where is the kernel and ramdisk? | 19:47 |
| *** BK_man has joined #openstack-dev | 19:48 | |
| vishy | + it is ovf instead of ami | 19:48 |
| vladimir3p_ | vishy: ok, it is interesting... let me upload another image to it | 19:48 |
| BK_man | hi all | 19:49 |
| BK_man | please clarify - do we need a some kind of test for nova-api graceful shutdown fix? https://code.launchpad.net/~chemikadze/nova/gracefull-shutdown | 19:49 |
| BK_man | if not - please approve that branch :-) | 19:50 |
| *** nati has quit IRC | 19:57 | |
| *** nati has joined #openstack-dev | 19:58 | |
| ttx | Team meeting in one hour in #openstack-meeting | 19:59 |
| *** ohnoimdead_ has joined #openstack-dev | 20:08 | |
| *** dprince has quit IRC | 20:09 | |
| *** ohnoimdead has quit IRC | 20:11 | |
| *** ohnoimdead_ is now known as ohnoimdead | 20:11 | |
| *** ohnoimdead has quit IRC | 20:12 | |
| *** nati has quit IRC | 20:13 | |
| *** mdomsch has quit IRC | 20:27 | |
| *** nati has joined #openstack-dev | 20:27 | |
| *** nati has quit IRC | 20:37 | |
| *** nati has joined #openstack-dev | 20:37 | |
| *** rods has joined #openstack-dev | 20:41 | |
| *** ohnoimdead has joined #openstack-dev | 20:44 | |
| *** ohnoimdead has quit IRC | 20:44 | |
| *** ohnoimdead has joined #openstack-dev | 20:44 | |
| *** troytoman-away is now known as troytoman | 20:49 | |
| ttx | Meeting starting NOW in #openstack-meeting, please join | 21:00 |
| *** cp16net__ has quit IRC | 21:07 | |
| *** lorin1 has joined #openstack-dev | 21:26 | |
| vishy | tr3buchet: ping | 21:27 |
| *** markvoelker has quit IRC | 21:39 | |
| mtaylor | ttx: ping | 21:40 |
| ttx | mtaylor: yawn, yes ? | 21:40 |
| mtaylor | ttx: just saw your comment to soren that you'd worked on a script to do the launchpad release thing ... I'd love to get that integrated in to jenkins at some point (or discuss whether/how much that makes sense) | 21:41 |
| mtaylor | ttx: but for now - go to sleep | 21:41 |
| ttx | mtaylor: we'd like to automate the whole process, we have it 90% covered currently | 21:41 |
| mtaylor | agree | 21:41 |
| ttx | with various scripts | 21:42 |
| ttx | If you're curious, see http://wiki.openstack.org/HowToRelease | 21:42 |
| *** markvoelker has joined #openstack-dev | 21:42 | |
| * jaypipes off to upgrade to 11.04... back in an hour or so.. :) | 21:43 | |
| *** jaypipes has quit IRC | 21:43 | |
| ttx | jaypipes: or so you think, <evil laughter> | 21:43 |
| *** lorin1 has quit IRC | 21:47 | |
| *** lorin1 has joined #openstack-dev | 21:48 | |
| *** foxtrotdelta has quit IRC | 21:53 | |
| *** ameade has quit IRC | 22:00 | |
| *** lorin1 has quit IRC | 22:04 | |
| *** lorin1 has joined #openstack-dev | 22:05 | |
| *** kbringard has quit IRC | 22:06 | |
| *** bcwaldon has quit IRC | 22:17 | |
| *** troytoman is now known as troytoman-away | 22:42 | |
| *** markvoelker has left #openstack-dev | 22:48 | |
| *** mgius_ has joined #openstack-dev | 22:52 | |
| *** jkoelker has quit IRC | 22:54 | |
| *** mgius has quit IRC | 22:54 | |
| *** mgius_ is now known as mgius | 22:54 | |
| *** Vasichkin has quit IRC | 23:04 | |
| *** rods has quit IRC | 23:25 | |
| *** cp16net_ has joined #openstack-dev | 23:36 | |
| *** nati has quit IRC | 23:39 | |
| *** cp16net_ has quit IRC | 23:48 | |
| johnpur | is anyone running swift on 11.04? i am seeing some wierd xfs timeout errors... | 23:59 |
Generated by irclog2html.py 2.14.0 by Marius Gedminas - find it at mg.pov.lt!