Re: [Openstack] openstack OS image
On 07/08/2013 04:40 AM, Min Pae wrote: > http://lmgtfy.com/?q=openstack+vm+image+download > > What you want is the 4th link (as of this writing) Saying "the 4th link on google" is meaningless, since depending on your country, language, etc., the results in google are different. Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Grizzly official packages
On 04/05/2013 03:32 PM, skible.openst...@gmail.coma wrote: > Hi there, > > How can i add the official grizzly packages to ubuntu 12.10 ? > > This seems to work fine on ubuntu 12.04 but not sure it does on 12.10 ! > deb http://ubuntu-cloud.archive.canonical.com/ubuntu > precise-updates/grizzly main > > regards, > Stacker Hi, I cannot talk for Ubuntu, but I've prepared some non-official packages for Debian available here: deb http://archive.gplhost.com/debian grizzly main deb http://archive.gplhost.com/debian grizzly-backports main These are to use with Debian wheezy. The grizzly-backports repository is for dependencies, not core packages, though the grizzly repository also contains some python modules. In fact, the split is more an internal choice (eg: grizzly-backports are Debian packages which I don't maintain directly, for example packages maintained in the Python module team). As packages gets slowly approved by the FTP masters, I will soon be able to upload all of these in Debian Experimental. I'm in fact waiting for Wheezy to be released, so that I can upload Folsom in SID/testing, and Grizzly in Experimental. At least that's the plan. I have made a small page announcing this, available here: http://www.gplhost.com/software-openstack.html I believe that the Folsom howto is still valid for Grizzly. Here it is: https://wiki.debian.org/OpenStackHowto/Folsom At some point, we will fork this howto and add some Grizzly things in it. I also intend to add more stuff in the meta-packages, for example to provide heat setup as well. I'd be happy to have any feedback on these packages, so please do write to the PKG Openstack list if you have any issue (eg: PKG OpenStack ). Cheers, Thomas Goirand (zigo) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Name it Hood!
On Fri Jan 25 2013 06:29:32 AM CST, Monty Taylor wrote: > > f) Hood is only 4 letters. Think about that when you think about typing > > hatfield a lot. Also, if we name it hatfield, we're going to have to > > have the M summit somewhere that has a town called McCoy. Oh! I didn't realized that was the reason why the next summit will be in Gortland ;) > > g) I'll buy you a beer at the summit if you vote for Hood. And will you also sign my PGP key? These go 2gether! :) Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Blueprint proposal: Drop setuptools_git for including data/config files
On 12/18/2012 05:29 PM, Sascha Peilicke wrote: > On 12/17/2012 04:47 PM, Thomas Goirand wrote: >> This >> means that absolutely all of our packages have to embed a patch in >> debian/patches to "fix" the "wrong" MANIFEST.in. >> >> We've spent quite some time on that. Or rather, should I say: it's a >> real time waster. >> >> While I do agree that the MANIFEST.in should be generated automatically, >> I don't think it should be stored in a "wrong" way on github. > So it should either contain something meaningful or be removed. In their > current state, these files are just worthless. Exactly! On 12/18/2012 07:50 PM, Mark McLoughlin wrote: > 1) You don't build packages from the tarballs produced by upstream. > I don't understand why you don't use tarballs, but I'm willing > to assume it's not something you can (or want to) change. In many ways, it's very convenient to do what we do. We could go back to use tarballs, but if it is avoidable, I want to keep the current system. > 2) Instead you use git-buildpackage which I know nothing about. Shortly, git-buildpackage uses an upstream branch (often called "master") containing upstream code, and a Debian branch containing that, plus the debian folder. Typing "git-buildpackage" does all the magic needed to build a Debian package, with the added bonus that you don't have to build where your package is stored (usually, we build in ../build-area), which means no risk to modify any files in your Git repository. > 3) You work from git repositories forked from upstream e.g. > > http://anonscm.debian.org/gitweb/?p=openstack/python-novaclient.git;a=shortlog;h=refs/heads/debian/experimental > > which AFAICT just add a debian/ directory to the source tree Yes. > 4) 'get-vcs-source' somehow generates a tarball from this tree. I'm > guessing it does 'git archive' rather than > 'python setup.py sdist' but I'm not sure. Some more digging > turns up: > > http://anonscm.debian.org/gitweb/?p=openstack/openstack-pkg-tools.git;a=blob_plain;f=pkgos.make;hb=HEAD > > and it seems that yes, you're using 'git archive' That's correct, you've found out quite well. Also, "get-vcs-source" fetches the master branch from upstream (git add remote, git fetch...). The repository is either git://github.com/openstack/.git, or we just override the UPSTREAM_GIT variable before including /usr/share/openstack-pkg-tools/pkgos.make (that's needed for python modules which are not on the github.com/openstack repo). > 5) I'm guessing there are two issues with these 'git archive' > generated tarballs - (a) there's no versioninfo file so > setuptools doesn't know have a version number and (b) there's > no .git directory so setuptools doesn't have an accurate way of > building a manifest > > I'm not completely clear what setuptools commands are failing > because of issue (b) All the above is exactly right! One of the reasons we are happy to use git archive is that this produces a Debian orig.tar.xz (notice the xz, and not just gz) from *any* commit, if we want to. Let me explain how it works. Let's say I want to make a snapshot release of Ceilometer for the commit hash 23ff2f9bbfc14e435c4c04fba473cf2a829b (this is an actual real life example, in fact...). Then, to do that, I just do: git checkout master git log # find out what's the name of the tag... git tag 2013.1_g0.4+23ff2f9bbf 23ff2f9bbfc14e435c4c04fba473cf2a829b git checkout debian/experimental git merge -X theirs 23ff2f9bbfc14e435c4c04fba473cf2a829b Then I edit my debian/changelog so it matches the tag: ceilometer (2013.1~g0.4+23ff2f9bbf-1) experimental; urgency=low * Initial release (Closes: #693406). -- Thomas Goirand Wed, 14 Nov 2012 14:41:52 + (the important bit is of course the version number above) Then I generate the orig.tar.xz: ./debian/rules get-vcs-source cp ../ceilometer_2013.1~g0.4+23ff2f9bbf.orig.tar.xz ../build-area Then I just build: git-buildpackage Another reason why git is convenient, is that we can cherry pick -x stuff from upstream, do branching, etc. Well, do I really have to convince people of this list that git is convenient? :) Probably not. > 6) However, you seem to be saying that issue (b) isn't an issue but > rather inaccurate MANIFEST.in files are the problem. How exactly > are they causing a problem. If we delete those files from > upstream git, does that work for you? Well, it be better if the MANIFEST.in could be stored correctly in upstream Git repositories, so we wouldn't have to deal with them. Cur
Re: [Openstack] Blueprint proposal: Drop setuptools_git for including data/config files
On 12/18/2012 12:17 AM, Thierry Carrez wrote: > Thomas Goirand wrote: >> [No pun intended, but it'd be nice if stackers had a bit more >> consideration for our work in Debian, and stop thinking only with >> Ubuntu, Ubuntu, Ubuntu, Ubuntu, Ubuntu, Ubuntu, ... in mind.] > > There is nothing Ubuntu-specific in this. And nothing bzr-specific > either. Fedora uses the same process with success. I agree we can > improve the tooling so that it's a bit more flexible to various use > cases, but don't make it a question of supporting only Ubuntu vs. the > rest of the world. It's been a long time since we only supported Ubuntu. > > Cheers, Hi Thierry, It's a shame you only reply about this, and now I regret writing these lines. That was in brackets, and not so important. The rest of my post was more valuable, IMO. Cheers, Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Packaging Horizon
On Sat Sep 15 2012 03:55:09 AM CST, Gabriel Hurley wrote: > Either way works, you just have to compile the file once and ship it in > the distro package. For at least Debian, this would make the package non-free. Everything has to be compiled from source. > If you can't compile it yourself then you could perhaps use the one from > Adam/Ubuntu, or I can do it and send you the final output file. That isn't the way. Thomas > > -Original Message- > > From: openstack-bounces+gabriel.hurley=nebula@lists.launchpad.net > > [mailto:openstack- > > bounces+gabriel.hurley=nebula@lists.launchpad.net] On Behalf Of > > Adam Gandelman > > Sent: Friday, September 14, 2012 11:19 AM > > To: openstack@lists.launchpad.net > > Subject: Re: [Openstack] Packaging Horizon > > > > On 09/14/2012 05:06 AM, Matthias Runge wrote: > > > Hi, > > > > > > currently, I'm trying to package horizon RC1 for Fedora. > > > > > > Since, Fedora does not have node.js included, and also doesn't have > > > LESS included, it won't work per default. > > > > > > Do you have suggestions for me? > > > Thanks > > > > We faced the same issue in Ubuntu [1]. Ended up compiling and > > compressing the CSS and JS at packaging time, shipping those + the > > manifest.json with the package and enabling COMPRESS_OFFLINE=True by > > default. Users who might want to make use of lessc and node later can > > just install node-less and set COMPRESS_OFFLINE=False. > > > > Adam > > > > [1] https://bugs.launchpad.net/horizon/+bug/1024326 > > > > ___ > > Mailing list: https://launchpad.net/~openstack > > Post to : openstack@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~openstack > > More help : https://help.launchpad.net/ListHelp > > > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Openstack-devel] Ubuntu and Debian package diff for nova
On Wed Sep 5 2012 05:09:05 PM CST, YunQiang Su wrote: > In Ubuntu, nova-compute and nova-compute-* depends on each other, > will it cause some problem? I think that's fine and the way to go. Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Openstack-devel] Ubuntu and Debian package diff for nova
Hi,
Thanks Ola, for this work.
I am Cc-ing the launchpad list of Openstack, to put the Ubuntu devs in
the loop. For those who don't know about Debian Openstack packaging
team, here's the team:
- Thomas Goirand (zigo): myself
- Loic Dachary
- Ghe Rivero
- Julien Danjou
- Ola Lundqvist
There may have been some other contributors (especially Debconf
translations), but that's the main team. I'm not sure if Julien still
wants to get involved in the Debian packaging of Openstack, since he is
busy on the Ceilometer project.
What happened is that Debian and Ubuntu packages have drifted in
different direction, since Julien did his work about a year ago. This
isn't necessary a bad thing, we can both learn from this, and enhance
both packages. But at some point, this has to stop: we are duplicating
our work, and that's not a good thing.
One of the problem we have in Debian, is that we have a strong allergy
to bzr. We use Git, and we are happy to do so, and I don't believe that
any of us wishes to go back to using bzr, for the same reasons Openstack
itself moved to Github. Also, since we use Git, it's easy for us to
import "upstream" code, which is a way better.
To the Ubuntu packaging team: would you consider working with Git for
the Openstack packages?
This way, we would have a chance to merge our work. If this doesn't
happen, I don't think any of the Debian Developers working on Openstack
would like to use bzr, which would make collaboration quite difficult.
If Ubuntu people move to Git, then at least *I* would be interested in
working together with Ubuntu folks to re-merge the packaging work. This
would be very beneficial to both Ubuntu and Debian, and what's below
proves it. At least, Ubuntu would benefit from our Debconf work AND all
the l10n translations, making it a lot more easy to install Openstack.
Let me give my comments what I see/know in the differences commented by
Ola below.
On 09/05/2012 03:42 AM, Ola Lundqvist wrote:
> High level summary:
> ===
> - The diff is very large. You can get a feeling about the difference by just
>reading debian/control below.
> - Debian dependency for nova-compute-xen, nova-api-* should probably be
> adjusted.
nova-compute-xen are ok, it's the Ubuntu side which is wrongly using
libvirt. I'm not sure for nova-api-*, can anyone comment?
> - Adjustment to the rest should be considered.
It's a little bit too late in the release cycle, I'm fearing the release
team reaction here.
> - Debian has usr/bin/nova-consoleauth part of nova-console package while
> ubuntu
>has it in the nova-consoleauth package. Debian still provide the
> nova-consoleauth
>package but it seems to be quite empty.
> - Quite different .init files.
Why did you even bother commenting the .init / .upstart files? It's
clear enough: Ubuntu uses upstart, and we use sysv-rc. If Ubuntu still
has some .init files, it's because I did the effort, about a year ago,
to have my work merged there. But since, it hasn't been merged, so what
you see in Ubuntu is a *very* old version of what I did.
> - Different patch set.
That's is a lot more worrisome.
> Detailed summary below:
> ===
>
> debian/control
> --
> - build dependency differences. The difference is large, so it is
>better to look into the detailed diff file instead. In general
>ubuntu has a large list of Build-Depends-Indep and just two
>small ones for Build-Depends. Debian has the opposite.
I don't think that's a huge problem. Maybe we should fix that in
Wheezy+1. Also, it's to be noted that there's so many build dependency,
only to satisfy the unit tests.
> general:
> - Different descriptions for the binary packages
> - When ubuntu use ${ostack-lsb-base}
That also comes from a year and a half ago, when I tried to merge stuff.
Then Julien came along, and deleted all my Ubuntu compat work.
> debian use lsb-base (>= 3.0.6) or lsb-base or
> ${ostack-lsb-base}
There shouldn't be a version depend on lsb-base. Any lsb-base is fine, IMO.
> python-nova:
> - Dependency difference for python-nova. Ubuntu has the following depds
> that debian is lacking:
> openssh-client, python-netaddr, python-feedparser,
> python-xattr, python-daemon, python-suds, python-iso8601
Is this with the package in Precise? If so, then we *must* fix this.
> - ubuntu provide XB-Python-Version: ${python:Versions} for python-nova.
> nova-common:
We don't care about XB-Python-Version, IMO.
> - Dependency difference for nova-common where debian has the following
> that ubuntu is lacking.
> python-iso8601, dbconfig-common, sqlite3
>Debian suggest: python-pysqlite2 | python-mysqldb | python-pyg
Re: [Openstack] [ceilometer] Weekly irc meetings day and time change?
On 08/30/2012 04:20 PM, Julien Danjou wrote: > On Thu, Aug 30 2012, Angus Salkeld wrote: > >> I'd like to attend but am in Australia. I am quite flexible so it might >> be easier to say what times don't suit. >> Basically midnight - 6am which in UTC is 14:00 to 20:00 > > That's gonna be a tough one. :) > > In the same idea, living in France, I'd exclude UTC 22:00 to 04:00. > > So that let us with UTC 04:00 to 14:00 and 20:00 to 22:00 > > Doug being in the US in IIRC UTC-7 that would exclude > UTC 07:00 to UTC 13:00. > > Finally letting us with UTC 04:00 to 06:00 and 20:00 to 22:00. > > So finally, I would propose to use UTC 21:00: > - 23:00 for me (and Nick most of the time I guess) in France > - 14:00 for Doug > - 7:00 for Angus > > or UTC 06:00: > - 08:00 for me (and Nick most of the time I guess) in France > - 23:00 for Doug > - 16:00 for Angus > > (Hope I did not get the math wrong) If it's the former, I wont ever attend, no way I can get up at 5am (Shanghai is GMT+8). This has always been at this time, and never, I can go online. The later is ok though. Thomas P.S: I'd like to contribute to the ceilometer project. I haven't yet (though I've done quite some work on the Debian packaging of the rest of Openstack), and I'd like to know in which area I could start implementing. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] XCP with DevStack
On 06/01/2012 08:18 PM, John Garbutt wrote: > Hi, > > I assume you are using xcp-xapi in Ubuntu. First of all, is it all running > correctly (i.e. xe vm-list is returning correctly): > http://wiki.xen.org/wiki/Using_XCP_-_preparing_the_toolstack > > It turns out the current DevStack will not work with this, but I have pushed > some changes to support it: > https://review.openstack.org/#/c/7673/ > > The networking configuration can be a little confusing, there is an overview > on the wiki: > http://wiki.openstack.org/XenServer/NetworkingFlags IMO, the overview is far than enough. Having the relevant xe commands that would do the setup in a nice tutorial is IMO mandatory for such setup to be attractive. > The DevStack flags are there to configure each of the VIFs on the DomU, the > defaults can be seen here: > https://github.com/openstack-dev/devstack/blob/master/tools/xen/xenrc > > If things are still un clear, do ask some more questions. I wrote it before, and I will write it again: a shell script is not, and will never replace, a documentation. What you need to do is write enough documentation so that an experienced admin can write his own script, not the other way around! So please write a decent tutorial. > I have plans to document this exact setup in some detail in the near future. > Feel free to add to these docs on the wiki. Please go ahead, I'd be happy to add some of it in the README.Debian for XCP + Openstack. Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] HVM + Xen Hypervisor via libvirt possible?
On 06/22/2012 05:56 PM, Daniel P. Berrange wrote: >> 3. or some good reasons to migrate from Xen to KVM? > I'd favour KVM for a variety of reasons, but lets not turn this into a > bikeshed discussion about which is best ;-P Let's put it this way: if you want to run with libvirt and Openstack, then yes, you should probably switch to KVM. But if you want to keep Xen, then you should probably switch to XCP. Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] HVM + Xen Hypervisor via libvirt possible?
On 06/22/2012 02:04 PM, Li Wang wrote: > We use CentOS in production environment. There is the Zeus project, > right? I'll do some research on it Well, if you use CentOS, then why not using XCP, the open source appliance, from Citrix? It's CentOS based... I heard about the Zeus project, but I'm not sure how fare they are with this. I'm Cc-ing Mike and Jon, upstream for XCP, maybe they will be able to tell how far they've gone, and if it's already in Fedora. Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] HVM + Xen Hypervisor via libvirt possible?
On Fri Jun 22 2012 11:22:13 AM CST, Li Wang wrote: > Thanks all for replying. > > We want to stick on to the Xen Hypervisor for some reason. > > 1. Does the community plan to support this feature? > 2. Could I submit this request to the blueprint? My team would like to > contribute on it if necessary. > 3. or some good reasons to migrate from Xen to KVM? Hi, why sticking with libvirt? There's XCP available in both Debian and Ubuntu, so there's no reason to use libvirt for Xen anymore! Just apt-get install xcp-xapi in your dom0 and use XenAPI. Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [devstack] Easing maintenance of list of distro packages to install
On 06/20/2012 06:06 PM, Vincent Untz wrote: > Hi, > > In devstack, we currently have two separate lists of packages to > install: one for Ubuntu (in files/apts/) and one for Fedora (in > files/rpms/). > > This has two issues: > > - this leads to incomplete updates for dependencies. It happens that >someone updates the apts files but not the rpms ones. (shameless >plug: https://review.openstack.org/#/c/8475/ needs some review love) > > - this just doesn't scale when adding support for another distro, >especially as rpm-based distros don't all share the same package >names (hence files/rpms/ cannot really be shared). > > I'd like us to move to a new scheme where we have one list of packages > (say the Ubuntu one, for instance) and instead of adding another one > Fedora, openSUSE, etc., we have translation tables to map package names > from Ubuntu to other distros. The issue that I find here is that there might not be a 1 to 1 mapping. For example, the built binary nova packages in Debian aren't the same as the ones in Ubuntu (not the same number of binaries, etc). So what you'd have to maintain would be a list of package for a certain type of action. For example, rather than a package X is called Y in Ubuntu, and Z in Fedora, you need to store something like: to install nova in Debian, I need: a, b and c packages. > Supporting a new distro is then a matter of adding a translation table > (+ hacking the code to change the right config files, obviously) Well, what we've been trying to do in Debian was to use Debconf for configuring, so we don't need "hacks" to configure (eg: you can use preseeding). That's the ultimate goal, but I'm not sure if we have it done 100% yet. Did you have a look on Ghe Rivero debostack? On 06/20/2012 09:17 PM, Dean Troyer wrote: > The simple fact is that we really only > develop DevStack on Ubuntu, anything else is a second-class citizen by > definition. You're here talking only for yourself. The "we" isn't everyone, you just happen to be included in it! :) Also, it isn't very nice to see this sentence written again and again in this list. I'd suggest not writing it again, and making the necessary efforts so that there's more involvement in other distros. For example, more testings of Essex in Debian would be appreciated, considering we freeze Wheezy in few days. Cheers, Thomas Goirand (zigo) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OpenStack immaturity
hi Jim! This is Thomas / GPLHost. Do you remember me? :) I've noticed that despite GPLHost involvement in promoting Openstack and maintaining it in Debian, as well as my recent effort to have XCP in Debian as well, allowing anyone to use Xen together with Openstack, GPLHost is never listed anywhere on the Openstack website or other materials. Could you make this change? Do you need a .ai logo or something similar? Cheers, thomas goirand (from my phone) - Original message - > I agree 100% with Michael. We need more users to come forward publicly. > We are working on an updated tool for submitting that data (and a > t-shirt incentive!), but in the meantime please send me your company > name or clients names that we can list. I have already been chatting > with many of you about this separately, but for all those I haven't — > please stand up and identify yourselves as an OpenStack user! > > Jim > > > From: mailto:raja.me...@wipro.com>> > Date: Fri, 6 Apr 2012 11:43:41 + > To: Mark Collier > mailto:mark.coll...@rackspace.com>>, > mailto:saur...@safewlabs.com>> Cc: > mailto:openstack@lists.launchpad.net>> > Subject: Re: [Openstack] OpenStack immaturity > > +2 , I go with Saurabh. > > > Thanks > Meena Raja > > > From: > openstack-bounces+raja.meena=wipro@lists.launchpad.net<mailto:openstack-bounces+raja.meena=wipro@lists.launchpad.net> > [mailto:openstack-bounces+raja.meena=wipro@lists.launchpad.net] On > Behalf Of Mark Collier Sent: Friday, April 06, 2012 4:54 PM To: Saurabh > Cc: openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net> > Subject: Re: [Openstack] OpenStack immaturity > > > +1 well said > > > > Saurabh mailto:saur...@safewlabs.com>> wrote: > > > Hey Guys > > One of the user stories from my company. We are an SME and our customers > are SMEs too. We are working on releasing documents in detail as well as > discussing with the customers, for releasing the entire customizations > to the community. We are working on releasing all these in the form of a > cookbook. We want to all to benefit from our experience as giving back > to the community is a strong part of the open source ecosystem. > > If people call OpenStack immature they should learn it's a community > built product, if they feel it lacks in some way they should report to > the community or feel free to fix stuff themselves :) . > > Stop worrying about gartner, if you feel it's something that can be > improved , improve it and give it back. > > Cheers > On Fri, Apr 6, 2012 at 3:17 PM, Michaël Van de Borne > mailto:michael.vandebo...@cetic.be>> wrote: > I'm about to install OpenStack for a customer in a few days. It's an SME > and their first production cloud would be limited to a few hosts and > about 60 VMs. Do you feel it'd be worth getting their feedback about > deployment and usage? > > yours, > > michaël > > > > > Michaël Van de Borne > > R&D Engineer, SOA team, CETIC > > Phone: +32 (0)71 49 07 45 Mobile: > +32 (0)472 69 57 16, Skype: > mikemowgli > > www.cetic.be<http://www.cetic.be>, rue des Frères Wright, 29/3, B-6041 > Charleroi > > Le 06/04/12 02:28, Michael March a écrit : > I've been giving this thread some thought and it dawned on my that we > need to expand this page: > > http://openstack.org/user-stories/ > > Pretty much everyone featured on that page are 'big' organizations and > there really isn't any detail on their experiences of trying to deploy > (and maintain) Openstack. There's definitely not stories that a > mid-range sized IT shop could related to. > > This lack of antidotal user experiences I think contributes the > perceived immaturity of OpenStack. > > > -- > > Michael F. March - mma...@gmail.com<mailto:mma...@gmail.com> > Ph: (415) 894-9269 Fax: > (602)296-0400 Twitter: cowmix -- > Skype: Cowmix > > > > > ___ > > Mailing list: > https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack> > > Post to : > openstack@lists.launchpad.net<mailto:openstack@lists.launchpad.net> > > Unsubscribe : > https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack> > > More help : https://help.launchpad.net/ListHelp > > ___ > Mailing list: > https://launchpad.net/~openstack<https://launchpad.net/%7Eopenstack> > Post to : > openstack@lists.launchpad.net<mailto:openstack@l
Re: [Openstack] [OpenStack] Xen Hypervisor
On 03/26/2012 04:35 PM, John Garbutt wrote: > I certainly changed the plugin so it always required the host_uuid, but > I also changed the “call_plugin” code in xenapi_conn to ensure we always > pass the host_uuid. > > > > Indeed it looks like in the code path below, that you should get the > host_uuid passed all the way though. > > > > I have not tested with XCP myself, only with XenServer 6. I am afraid I > will not get chance to try this out till Wednesday (currently on > holiday). One other useful log will be from XCP where it logs the > parameters passed into the plugin (on XenSever it is > /var/log/xensource.log, it could be /var/log/xcp.log? or xapi.log, can’t > remember I am afraid) You should be able to track the host_uuid to > ensure it gets from nova->xapi client->xapi server->plugin > > > > If you want to move on with your deployment a work around is to add this > into the xenhost plugin: > > > > Change: > > host_uuid=arg_dict[‘host_uuid’] > > Into: > > host_uuid=_run_command(“xe host-list | grep > uuid”).split(“:”)[-1].strip() Hi John, Why not using: xe host-list --minimal instead of the grep, split, strip code, which adds useless complexity? Also, this piece of code doesn't seem to be resistant to having more than one host as reply (in which case the UUID would be separated by a coma, if I'm not mistaking). Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Please stop the devstack non-sense!
On 03/21/2012 08:48 PM, Narayan Desai wrote: > Ghe, while you're right that these two workloads are different, > deployers need developers to use a representative environment during > development, or the code doesn't work when it hits real deployments. > We've now been bitten during our initial deployment of cactus, our > upgrade to diablo, and our recent tests preparing for the essex upgrade > because we can't run our management infrastructure on a single system. > > During cactus, we had issues when we tried to run multiple nova-network > servers distinctly from the api service. IIRC during the diablo release, > we had issues with keystone and horizon. This time, we had issues with > glance/keystone integration. I'm not saying that things haven't > improved, it just seems that each release has a new issue caused by the > assumption that all services will be running on the same host. > > As we get more users with large deployments, these sorts of issues will > only become a bigger deal, and will hinder large scale adoption. > -nld With my Debian Developer hat on, I'd like to send a reminder ... When Wheezy will be released, we'll have Essex in (if everything goes as planned). Then when Wheezy +1 gets out, will will also need to allow an upgrade path for Openstack (otherwise, it's considered an RC bug in Debian). And I believe that Ubuntu will have the issue as well (since 2012.4 will be an LTS, right?). I just hope that Openstacker will keep in mind how much of a commitment it is to allow upgrade from release to release + 4 (or +5) in a project like Openstack which goes so fast. :) Cheers, Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Openstack-devel] [Xen-API] nova-xcp-network plugin searching for a xapi0 interface
Hi Ewan, Thanks for your answer. On 03/21/2012 07:05 AM, Ewan Mellor wrote: >> -Original Message- >> >>> Also, have you tried using DevStack first? It is a good way to get >> the hang of how the flags work. >> >> No it's not! DevStack is for testing with XenServer, and assumes that >> you'd be working with Ubuntu. Here, I'm testing the Debian packages >> that >> we are working on in Debian. Please don't direct me to DevStack, this >> wont help. > > DevStack _will_ help, and that's why we keep telling you to go look > there, and I have no idea why you keep refusing. You are writing the above as if I was being difficult, and refusing to do my homework. That isn't the case. I have read the scripts, and I did understand most of it, but some parts are really not easy to understand without the necessary background knowledge. Namely, the network setup, which is what I am having issue with currently. I'm trying to get the VLAN manager to work, and that mode isn't what Devstack is setting-up: it's setting-up a FlatDHCP. I may try to do a FlatDHCP to check if it works as expected, but that's not really satisfying in production for a public cloud. > You don't have to > run it, but it's up-to-date, and it's working, so it's a nice, clean, > self-documenting example of at least one way that someone has managed > to make this work. I really *don't agree* with the above. It's not self-documenting, it's clearly a big hack (not clean at all) that works only in your specific case (eg: if using CentOS and XenServer 5.6 with Ubuntu Oneiric). As you said it's "one way" to do things only, and it's all but helping to write a user documentation or a successful package. > If you have differences between your system and DevStack because of > the differences between Debian and Ubuntu or XenServer and XCP, then > fine. If you have differences that you don't understand, then you're > probably doing it wrong. That's why we tell you, on a weekly basis, > to go look at DevStack if you want to see how a flag should be set. I don't think that the issue is with flags. > You can either do this the easy way, by following other people's > working systems, or you can do it the hard way, by deep-diving > into every single detail. I'm fine if you want to do it the hard > way -- you'll certainly learn a lot, and it's probably very > interesting and useful knowledge for the future. Just don't keep > complaining that it's all too hard and then refuse to take the > easy option. > > Ewan. I don't "keep complaining that it's too hard", I complain that there's little to zero documentation of what is being done, and that one has to double-guess what is going on in Devstack. You seem to believe that Devstack is enough to replace a real documentation. If that is the case, then you are doing a big mistake here. Remember that I'm a Debian Developer, and that I've been running a hosting business since 2003. I consider myself as an advance user, which understands what a vlan is, how bridge is working, and that with all this, it should be enough knowledge to understand what's going on in a normal product. It's simply not the case with XCP + Openstack which is lacking documentation. Have you, by the way, noticed that there's even a bug that has been filled in Launchpad, about the lack of docs concerning bridging, OVS and networking? In a shorter way: if I'm telling you that Devstack isn't enough to understand what's going on, please trust me! Lucky, John Garbutt, Dave Scott and Salvatore Orlando have understand all this, and are trying to help me. As Salvatore just wrote, I am convince that I'm very close to have the setup working. Salvatore Orlando has written back to me with some very valuable information which I need to take time to understand now. I'll read it carefully today, as I'm sure it will help. Thomas P.S: It well may be that there's a bug in Kronos, because when I do "xe vlan-create", on the screen it's printed "script failing" or something. I'll test it one more time in order to get the exact error message, and probably will work with Mike on debugging this issue, which may be related to the upgrade to the latest version of Open vSwitch (which is 1.4.0 in Debian). ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [OpenStack] Xen Hypervisor
On 03/21/2012 12:56 AM, Alexandre Leites wrote: > Hi folks, > > First let me say that i'm trying to install xen hypervisor and integrate > it with OpenStack for more than one week. I'm studying OpenStack for a > company and this company doesn't allow us to use ready scripts (Why? > they want to be different from the whole world). > > I have used some links for references: > https://github.com/openstack-dev/devstack/blob/master/tools/xen/README.md > http://wiki.openstack.org/XenAPI > http://wiki.openstack.org/XenServer/DevStack > http://wiki.openstack.org/XenServer/Install > http://wiki.openstack.org/XenServerDevelopment > http://wiki.openstack.org/XenXCPAndXenServer > http://wiki.xen.org/wiki/XAPI_on_Ubuntu > http://wiki.xen.org/xenwiki/XAPI_on_debian > https://github.com/openstack/openstack-chef/tree/master/cookbooks/xenserver > https://review.openstack.org/#change,5419 > > Me and my coworker are trying to install this and integrate on a running > and tested OpenStack infrastructure, so this machines will have just > nova-compute service. He is trying with XCP and I with XenServer, so let > me introduces our tries: > > 1. XCP On Ubuntu (Kronos) > * Install fine > * Doesn't work Hi, I've been working with Mike from Citrix on these packages. What exactly did you install? Just what was available in Ubuntu? These packages would need to be upgraded to what I've uploaded recently in Debian SID. There are some notes available here: http://wiki.xen.org/wiki/XCP_toolstack_on_a_Debian-based_distribution When you say "Doesn't work", it isn't helpful to know what's wrong. Can you describe a bit more what doesn't work? Also, I would advise to try what's in Debian SID, which is more up-to-date. BTW, if some Ubuntu folks are reading, I would strongly advise to allow xen-api 1.3.2-4 to be taken from SID, and replace the (buggy, with sometimes wrong dependencies) 1.3-15 version. Cheers, Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Please stop the devstack non-sense!
On 03/21/2012 01:35 AM, Mark McLoughlin wrote: > However, I do think devstack is seriously useful for upstream developers I have never denied that fact. :) Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [OpenStack] using xenapi hypervisor
On 03/20/2012 02:19 AM, Eduardo Nunes wrote: > I wanna use the xenpi as a hypervisor, i see there are many tutorials, > but almost all of then is using the devstack, i don't wanna use the > devstack, is there a tutorial about how i create a domU, what image i > sould use on the domU, an the conf of xen? I can see I'm not the only one feeling very frustrated here... :) Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Please stop the devstack non-sense!
Nothing is really structured with functions. It's not really possible to run the scripts twice either (it's not idempotent, AFAIC). Yes, one can read the devstack scripts and try to understand how it works. But it's not easy to follow when you don't know what it's supposed to be doing. And let's say one could read and type what it does, while adapting it to an environment (Openstack + Kronos in SID, in my case), that doesn't give explanations of why things are like that, and what kind of configuration choice the user may have. That doesn't help either to write a proper documentation or explaining to users how all this is supposed to work. What's making it even worse, is that many people are telling that this non-sense scripting is supposed to be a *DOCUMENTATION* ?!? There's absolutely *nothing* in the scripts that is explaining why things are done. There's comments like this: # Create vlans for vm and management create_vlan $PUB_DEV $PUB_VLAN $PUB_NET create_vlan $VM_DEV $VM_VLAN $VM_NET create_vlan $MGT_DEV $MGT_VLAN $MGT_NET or (in stack.sh): # Install and start mysql-server apt_get install mysql-server How about just removing the comment on top of the create_vlan calls? They don't explain anything at all. Absolutely everything is like this in the scripts. Things are done, but nothing explains what will be the consequences, what can be done differently, etc. It's as if in C, you would write: a = b; // Move the content of b into a. Thanks, I know the C language, and I understand what I read. Now, *WHY* are we moving the content b into a is the interesting bit which is missing. And I've been told again, again and again, please use Devstack, because this is tested. I'd reply that it has been tested in a few cases, which matches some of the developers. These scripts are broken in my environment. Reading the scripts doesn't help me to understand. That doesn't help me to test my packages. That doesn't help me to write documentation. I also think that developers should be using a packaged installation, and not just a local checkout. There are many things that can happen between the packaged environment and the git checkout. What I experienced with the Python script rights and the dhcpbridge script being searched in /usr/share/python2.7/dists/bin (sic!) is a very good example of this. I don't think anyway that if you are a developer, you will be working on absolutely all packages (nova, glance, keystone, swift, quantum...) that we have available in Openstack. In most cases, you'd be working on *one* of the Git checkout, and the rest of could well be downloaded and installed, either through the PPA, or from Ubuntu directly. So why using devstack which will checkout absolutely all components from Github? This doesn't make sense either. Also, if this continues, none of the developers will be testing the final result (eg: the packages). And finally, absolutely nothing prevents you from using Git and using the packaged version of all openstack modules. In Debian, we always use git for packaging, and git-buildpackage, which uses the source code from Github. Last, the attitude to say "please use devstack" to our users will stop among the community. This is *not* an answer to our users either. Is Devstack helpful? I'm sure it is, but for developers only. It's just bad to think about it as "self-documenting" Openstack, or to think that it's the solution for everything. It has never been its purpose, and it isn't taking that path, and thinking that it does is a huge mistake. Hoping that I will be heard and understood, Thomas Goirand (zigo) P.S: there's no aggressiveness intended above, I'm just trying to make a point. And it's not directed to anyone in particular, but to everyone pushing for devstack (IMO) too much, and making it very difficult for both users, people writing documentation or packaging (I'm both 3 at same time). ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Xen-API] nova-xcp-network plugin searching for a xapi0 interface
On 03/20/2012 12:05 AM, John Garbutt wrote: > This sounds a lot like a configuration issue with your guest network bridge. > Are you OK to supply your nova.conf file? Sure! Here it is: --sql_connection=mysql://nova:admin@127.0.0.1/nova --novncproxy_base_url=http://:6080/vnc_auto.html --rabbit_host= --glance_api_servers=:9292 --network_manager=nova.network.manager.VlanManager --vlan_interface=br100 --dhcpbridge=/usr/bin/nova-dhcpbridge --firewall_driver=nova.virt.xenapi.firewall.Dom0IptablesFirewallDriver --connection_type=xenapi --xenapi_connection_url=https:// --xenapi_connection_username=root --xenapi_connection_password=XXX --reboot_timeout=600 --rescue_timeout=86400 --resize_confirm_window=86400 --auth_strategy=keystone --allow_admin_api --allow_resize_to_same_host --logdir=/var/log/nova --state_path=/var/lib/nova --lock_path=/var/lock/nova --vncserver_listen=0.0.0.0 --force_dhcp_release --use_deprecated_auth --use_project_ca --verbose Note that since I restarted xcp-xapi, it seems that the xapi0 bridge is created each time I create a VM, which is what I was expecting. So that parts seems to work now, but the issue is that now, I have no networking at all (eg: I can't reach the instance from the Openstack domU). Here's what "xe network-list" returns on my dom0: uuid ( RO): name-label ( RW): br100 name-description ( RW): network for nova bridge br100 bridge ( RO): xapi0 So it really is nova who created this. But shouldn't it be linked to my xenbr0 as well? What is the normal networking setup that should be done? There's absolutely zero documentation which I could find about this. Of course, I'll write one directly in our Debian packages as soon as this works. > Also, have you tried using DevStack first? It is a good way to get the hang > of how the flags work. No it's not! DevStack is for testing with XenServer, and assumes that you'd be working with Ubuntu. Here, I'm testing the Debian packages that we are working on in Debian. Please don't direct me to DevStack, this wont help. > I'm not familiar with the design of the Nova plugins but my guess is that > they're trying to use the "Host internal management network" -- a network > from which VMs can access the XenAPI (i.e. talk to xapi in domain 0). > > On recent XCP versions the default bridge name changed to "xenapi" to make it > easier to distinguish from a firewall rules PoV. As per Mike on IRC, (from Citrix, upstream for XCP, XenServer and Kronos), each time there's a new network being created, XCP create a xapiX bridge automatically. I shouldn't have even try to bring the xapi0 bridge myself, XCP does it (if it doesn't, then there's an issue). > Note that the actual linux bridge (or openvswitch) is created on demand so > you won't see it in "brctl show" or "ovs-vsctl show" until it's being used. > > Try changing "xapi0" to "xenapi" in the plugins and see if they work better? Nop, that wont help, xapi0 is really what to expect. My only issue now is to have it connected to the br100 of Openstack in my domU. Thanks for the help already, Cheers, Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] nova-xcp-network plugin searching for a xapi0 interface
Hi, When I start instances with Nova, using XCP on a Debian dom0, it seems that the Nova XenAPI plugin needs to access to a xapi0 network interface. If it's not their, the plugin just fails, and there's a python stack dump. So I have created a bridge called xapi0 on my dom0, and now I can start instances. But then, I have no network connectivity to my VMs. I wonder what this xapi0 network interface is for, and what is the correct networking model to have connectivity to my instances. When starting VMs, I don't see any network topology change in the dom0, or in my Openstack domU, which I think isn't right. Is the "normal" setup supposed to work with Quantum? Can it work without it? Can someone from the XenServer team enlighten me with the necessary knowledge? (The documentation about the necessary network setup is very scarce: I didn't find anything!) Cheers, Thomas P.S: Apart from that, it seems to work now with our Debian packages, even though it seems *very* slow to start instances, and I still can't get in the console of the VMs... :( ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] dnsmasq: cannot run lease-init script /usr/lib/python2.7/dist-packages/bin/nova-dhcpbridge: No such file or directory
On 03/17/2012 06:08 PM, Ghe Rivero wrote: > Hi Thomas, > you can use the flag: > dhcpbridge=/usr/bin/nova-dhcpbridge > in nova.conf. > > Ghe Rivero Ok, I'll do that, thanks! However, I really think that by default this should be corrected. I feels really weird that nova is trying to search a file in such a non-existent folder. Thomas > On 3/16/12, Thomas Goirand wrote: >> Hi, >> >> When running with the following nova.conf: >> >> --sql_connection=mysql://nova:admin@127.0.0.1/nova >> --novncproxy_base_url=http://:6080/vnc_auto.html >> --rabbit_host= >> --glance_api_servers=:9292 >> --network_manager=nova.network.manager.VlanManager >> --connection_type=xenapi >> --xenapi_connection_url=https:// >> --xenapi_connection_username=root >> --xenapi_connection_password=X >> --reboot_timeout=600 >> --rescue_timeout=86400 >> --resize_confirm_window=86400 >> --auth_strategy=keystone >> --allow_admin_api >> --allow_resize_to_same_host >> --logdir=/var/log/nova >> --state_path=/var/lib/nova >> --lock_path=/var/lock/nova >> --force_dhcp_release >> --use_deprecated_auth >> --use_project_ca >> --verbose >> >> when I create an instance, I have: >> >> (nova.rpc.common): TRACE: Stderr: 'sh: 1: >> /usr/lib/python2.7/dist-packages/bin/nova-dhcpbridge: not >> found\n\ndnsmasq: cannot run lease-init script >> /usr/lib/python2.7/dist-packages/bin/nova-dhcpbridge: No such file or >> directory\n' >> >> in my nova-network.log. So I did: >> >> mkdir /usr/lib/python2.7/dist-packages/bin >> ln -s /usr/bin/nova-dhcpbridge /usr/lib/python2.7/dist-package \ >> /bin/nova-dhcpbridge >> >> as a temporary fix hack. >> >> I wonder what is the best way to fix this, or if this is a known issue... >> >> Cheers, >> >> Thomas >> >> P.S: As always, I am *not* running Devstack, and I am *not* interested >> in using it, I'm working on the Debian packaging here... >> >> ___ >> Mailing list: https://launchpad.net/~openstack >> Post to : openstack@lists.launchpad.net >> Unsubscribe : https://launchpad.net/~openstack >> More help : https://help.launchpad.net/ListHelp >> > ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] dnsmasq: cannot run lease-init script /usr/lib/python2.7/dist-packages/bin/nova-dhcpbridge: No such file or directory
Hi, When running with the following nova.conf: --sql_connection=mysql://nova:admin@127.0.0.1/nova --novncproxy_base_url=http://:6080/vnc_auto.html --rabbit_host= --glance_api_servers=:9292 --network_manager=nova.network.manager.VlanManager --connection_type=xenapi --xenapi_connection_url=https:// --xenapi_connection_username=root --xenapi_connection_password=X --reboot_timeout=600 --rescue_timeout=86400 --resize_confirm_window=86400 --auth_strategy=keystone --allow_admin_api --allow_resize_to_same_host --logdir=/var/log/nova --state_path=/var/lib/nova --lock_path=/var/lock/nova --force_dhcp_release --use_deprecated_auth --use_project_ca --verbose when I create an instance, I have: (nova.rpc.common): TRACE: Stderr: 'sh: 1: /usr/lib/python2.7/dist-packages/bin/nova-dhcpbridge: not found\n\ndnsmasq: cannot run lease-init script /usr/lib/python2.7/dist-packages/bin/nova-dhcpbridge: No such file or directory\n' in my nova-network.log. So I did: mkdir /usr/lib/python2.7/dist-packages/bin ln -s /usr/bin/nova-dhcpbridge /usr/lib/python2.7/dist-package \ /bin/nova-dhcpbridge as a temporary fix hack. I wonder what is the best way to fix this, or if this is a known issue... Cheers, Thomas P.S: As always, I am *not* running Devstack, and I am *not* interested in using it, I'm working on the Debian packaging here... ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] XCP + OpenStack
I have updated the wiki at: http://wiki.xen.org/wiki/XCP_toolstack_on_a_Debian-based_distribution :) Thomas On 03/13/2012 10:55 PM, Todd Deshane wrote: > On Mon, Mar 12, 2012 at 2:10 PM, Eduardo Nunes > wrote: >> I read all the docs about it but i dont get it, what release shold i use, i >> run the xcp under the linux or i run linux under the xcp? > > You actually have two options for XCP. You can install XCP as a distro > itself (CD/PXE install) by downloading the ISO from > http://xen.org/download/xcp/index.html. > > The second option is that you can get an XCP-like system that includes > the XCP XAPI toolstack by installing the xcp-xapi package on Ubuntu or > Debian by following these instructions > http://wiki.xen.org/wiki/Project_Kronos > > Soon you will be able to do the same on Fedora/CentOS as well, but > work is still in progress. > (http://wiki.xen.org/wiki/Project_Zeus_Fedora_Spec) > > I cover these and other details about XCP and Xen in this talk: > http://www.cloudstack.org/build-a-cloud-day-videos/202-introduction-to-the-xen-cloud-platform.html > > Do contact me if you want to discuss any of these things in more detail. > > Thanks, > Todd > ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] XCP + OpenStack
Hi, Below is my view, Mike and Jon are welcome to correct me if needed. On 03/14/2012 06:27 AM, Todd Deshane wrote: > Looks like the Debian repos on Xen.org are out of date. I'm not sure > if the intention was to drop them once the packages got into SID or if > they would be staging/unstable packages that existed before they got > picked up by SID...(adding Mike and Jon to the CC to clarify). I think that was the plan yes, and that Mike didn't update the xen.org repositories. > The > wiki does include adding a line for the Debian experimental repo, That became completely wrong, and can potentially be harmful. > so > the packages in it would be used instead of the Xen.org repo since > they are newer. There's nothing in Debian experimental that a user would need, and nothing XCP related either. Everything is in Debian SID / testing. >> I don't know for Ubuntu though, but I suspect it should be the same. >> Maybe you know better, and can tell me what the status is in Ubuntu? > > There is an xcp-xapi package (and its dependencies) in 12.04 universe. The problem is that the Ubuntu package is outdated. It's version 1.3-15, when SID has 1.3.2-3. If someone has contacts with Ubuntu people, it'd be worth asking them to pull the package from SID. Sending a bug report on Launchpad for that would be worth. Note that I personally don't care at all about the state in Ubuntu, so I wont do this work. > The Ubuntu PPA is up-to-date and is the right place for Ubuntu users > that want the latest packages going forward. I'd be very careful if having XCP in Ubuntu proper, but having an outdated (buggy) package. Potentially, this may harm XCP users who will not know that they should use the PPA. > I believe the packages in > the PPA are always a couple weeks ahead of the packages that are in > Ubuntu universe. The PPA has version 1.3.2-1, which is about 2 months old it's missing few fixes (taken from debian/changelog, only the Ubuntu relevant parts): * Added /etc/xen as an empty directory for xcp-networkd (Closes: #663352). * xcp-networkd depends on openvswitch-datapath-dkms * Fix bug in vif hotplug script which prevented vm shutdowns I'd worry only about that last issue, which is really a blocker. The patch is here: http://anonscm.debian.org/gitweb/?p=pkg-xen/xen-api.git;a=blob;f=debian/patches/fix-vif-script;h=690e6ae5072c258b36699ef89815882a218c196a;hb=e9990da415a88f5f08b236a70e25630351552b2f > Once Ubuntu 12.04 and Debian Wheezy go stable we'll want to update the > wiki to be explicit about what is in the distros and what is not, I believe you can already do that, at least for SID/wheezy. Note that Debian 7.0 Wheezy is planned to be frozen next June. > but > I think we'll always have development packages that will be available > for testers/early adopters in Debian SID and the PPA. Early testers, IMO, should use Git: git clone https://github.com/xen-org/xen-api.git Then, you should make sure to have both master and debian branches, get in the debian branch, and do: git-buildpackage > I'm assuming > that stable packages will be maintained in Wheezy and that development > packages will be maintained in Debian SID right? Right, that's how it is always done in Debian. I hope that Citrix will decide that a long term support (2/3 years) will start after Ubuntu 12.04 is released, and that fixes will always be pushed there. Also, we can sometimes do some Wheezy backports if we need newer features. backports.debian.org is now officially part of Debian! I'd be happy to provide / maintain Wheezy backports later. Cheers, Thomas Goirand (zigo) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] XCP + OpenStack
On 03/13/2012 10:55 PM, Todd Deshane wrote: > On Mon, Mar 12, 2012 at 2:10 PM, Eduardo Nunes > wrote: >> I read all the docs about it but i dont get it, what release shold i use, i >> run the xcp under the linux or i run linux under the xcp? > > You actually have two options for XCP. You can install XCP as a distro > itself (CD/PXE install) by downloading the ISO from > http://xen.org/download/xcp/index.html. > > The second option is that you can get an XCP-like system that includes > the XCP XAPI toolstack by installing the xcp-xapi package on Ubuntu or > Debian by following these instructions > http://wiki.xen.org/wiki/Project_Kronos Todd, I'd like to point out that these instructions are really outdated, and that the packaged version in Debian SID works a way better than using the Citrix repositories that haven't been updated since quite some time. I don't know for Ubuntu though, but I suspect it should be the same. Maybe you know better, and can tell me what the status is in Ubuntu? Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Openstack-devel] XENAPI_PLUGIN_FAILURE with kronos
On 03/13/2012 06:57 PM, John Garbutt wrote: > A few possible issues: > * you might not have the execute permissions set on the xenhost plugin file? > On XenServer that means it fails to register the plugin. Yup, it was that. Thanks for the hint. IMO, the error message should have been a little bit more explicit, as I really wasn't expecting something like this... Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Openstack-devel] XENAPI_PLUGIN_FAILURE with kronos
Hi all, Thanks for those trying to help. Indeed, it was a stupid Unix right issue. The python scripts of nova for XCP aren't chmod +x in the Git (well, in fact, some are, some aren't chmod +x). Now it does seem to work. I'm testing more now, the debian packaging already chmod +x the python files now. Sorry for the noise, Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Openstack-devel] XENAPI_PLUGIN_FAILURE with kronos
On 03/13/2012 02:32 PM, Renuka Apte wrote: > You need to install the xenapi plugins: > > If you are using devstack (https://github.com/openstack-dev/devstack), the > code below from build_domU.sh does this for you. I'm part of the debian Openstack packaging team, and I worked with Mike on packaging XCP in Debian (project Kronos). I do not wish to try devstack, I wish to fix the Debian packaging! > # Checkout nova > if [ ! -d $TOP_DIR/nova ]; then > env GIT_SSL_NO_VERIFY=true git clone $NOVA_REPO > cd $TOP_DIR/nova > git checkout $NOVA_BRANCH > fi > > # Install plugins > cp -pr $TOP_DIR/nova/plugins/xenserver/xenapi/etc/xapi.d /etc/ > chmod a+x /etc/xapi.d/plugins/* > yum --enablerepo=base install -y parted > mkdir -p /boot/guest I'm not using CentOS, but Debian (project Kronos). And in there, you just need to do: apt-get install nova-xcp-plugins nova-xcp-network which installs the above in the correct folders (which are *NOT* the same as for CentOS). I'd love to have a bit of help from Citrix to test all this by the way. Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Openstack with Xen
On 03/10/2012 06:10 PM, Armando M. wrote: > That's great! if you find gaps, it's a wiki...feel free to fill them up > or ask the authors to do so. You are in a great position due to your > packaging experience, and your input would be very valuable. This is on my TODO, when I will consider that I'm ready myself with Openstack + XCP, which isn't the case yet. For the moment, I write notes in README.Debian files. Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Openstack with Xen
- Original message - > Kronos is great for developers we didn't write the packaging for developers only!!! > However, suggesting > Kronos to people looking to set up small OpenStack pilots is plain wrong. It is *not*, that is the only way to get things tested and fixed before Wheezy. If anyone finds an issue in the SID packages, I welcome them to use reportbug and submit issues on the Debian bug tracker, and we'll fix things asap. Cureently, we had zero bugs sent by users... So it means that, either because of silly suggestion that Kronos isn't production ready (based on no real fact...) nobody is testing it, or that the packages are perfect. :) > So In the end it is about making the users informed of what their options > are; Maybe you'd better let them know that we will take care of any issue that they might find, and that we need some testers!!! > they can then choose based on the above considerations They will wrongly think that XCP/Kronos is buggy if we continue this way. That's just plain wrong. > and on what > it's available on the wiki: http://wiki.openstack.org/XenServer This wiki needs to be updated with more Kronos stuff IMO. Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Openstack with Xen
- Original message - > Xenserver is the better tested path, so it might make more sense to try > that first. PLEASE, don't recommend to others to use XenServer instead of XCP (eg, Kronos). I have spent enough time with Mike on packaging XCP in Debian so that the latest (version 1.3.2-2) is in SID since few days. If everyone is pushing away users, then we will *never* have feedback! > You can get a free license for Xenserver. Follow the > instructions on this page for installation: > http://wiki.openstack.org/XenServer/Install Once you have a trial > version, you can obtain the free license by signing up for a new account > at citrix.com Which is not needed. Please use the latest SID, and do: apt-get install xcp-xapi then read the README.Debian Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [ubuntu-cloud] Update on Ubuntu automated testing and CI of Openstack
- Original message - > On Thu, Feb 9, 2012 at 4:57 PM, Robbie Williamson > wrote: > > On 02/09/2012 05:21 AM, Ghe Rivero wrote: > > > Wow! Openstack is really getting to much love from Ubuntu, nice! I > > > wish we have so many resources to the same with Debian. Keep the > > > good work > > guys! > > > Ghe Rivero > > > > > > > I could be 100% wrong here, but I think Debian has agreed (or are in > > talks) to use Ubuntu as the upstream for OpenStack, thus allowing our > > testing to "trickle" down. There's not really such thing anymore. Our Debian packages aren't the same as from Ubuntu now, and we take the code from Github. So openstack on github is our upstream (even though many developers sending code there are from Ubuntu). Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Nova] Essex dead wood cutting
On 01/29/2012 12:04 PM, Ewan Mellor wrote: > That includes Citrix XenServer, Red Hat RHEL and RHEV, Oracle VM, > Novell SLES, and VMware ESX. > > Basically the answer is that you need a commercial hypervisor > (because SVVP certification takes weeks to do, and months up front to > get the drivers and hypervisor perfect). Given the fact that XCP is derived from XenServer, and that both use the same hypervisor, would XCP in Debian (eg: Kronos) be included in the "commercial hypervisor" definition above? On 01/29/2012 11:22 PM, Anne Gentle wrote: > Does anyone have writing resources we could request an assist from to > write up the XenServer instructions on the docs.openstack.org site in > time for the Essex release? > I'd prefer to start with a writeup for XenServer rather than > XCP but would of course work with you on the vision here. This task > looks like a great opportunity to improve the docs. As part of my Debian packaging work on both Openstack and XCP, I'm writing README.Debian on how to setup everything. Unfortunately, what I had to work with didn't have enough feature to support Openstack + XCP, but I've been told that this has been now fixed, over the last few weeks. So as soon as git.debian.org works again (sic!...) I'll be able to restart a session to get the latest version of XCP from Citrix packaged in Debian, then hopefully networking and console will both work, and I'll be able to finish my README.Debian. Note that currently, we already have in Debian: - nova-xcp-plugins - nova-xcp-network which are both needed to be installed in the XCP dom0. I've also sent patches to be able to choose the toolstack with debconf (eg: xm vs xl), and another patch to *not* start xend if xl is chosen. Once that is done (eg: latest version of XCP from Mike and Jon at Citrix), and tested, you'll be more than welcome to pickup info from there. I'll point you where to find the files. Cheers, Thomas Goirand (zigo) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] XCP and Openstack questions
ttp://en.wikipedia.org/wiki/Open_Virtualization_Format > > They can be exported from XenServer using XenCenter. VMware have a > tool too, but I expect that those that VMware generate won't work > with OpenStack yet, because they'll use VMDK for the disk images, > and I'd be surprised if OpenStack can handle that. Since I asked, I understood it. Do you know if the OVF files exported by VirtualBox would work? I think Virtualbox is the most easy tool on the desktop, and I think many would be happy to use it to build OVH images. It's also packaged in Debian, so that's an easy thing to recommend for our users. >> 3/ Console >> on the same wiki page, it tells about using VNC. While this does work, >> I >> didn't have access to the login prompt. What's the way, if using >> openstack, to tell that the console is hvc0 (or whatever is the Xen >> console device name)? > > That's dependent on the in-guest setup. I think on latest Sid you'll need to > have an entry in /etc/init/hvc0.conf, similar to this: > > start on stopped rc RUNLEVEL=[2345] > stop on runlevel [!2345] > > respawn > exec /sbin/getty -L hvc0 9600 linux This is an upstart script, that's really not for Debian, but for Ubuntu! I can adapt it, however, the issue is that images that we find on the net wont have this by default. So, I thought that best would be to have added, automatically by XenServer / XCP, a parameter on the command like like: tty1=hvc0 (or similar), so that such thing wouldn't be needed. Any thoughts? >> Then, what's the normal way to access to the console, without using >> such >> hack (eg: customers obviously, wouldn't have ssh access to the dom0 in >> order to do port forwarding)? > > Anthony Young at Rackspace has recently reworked all of this. > It should be the same on XenAPI and KVM now. > https://review.openstack.org/#change,2949. That went in last week. Cool. I'll have a look to the latest version of Nova in Git then, and use our weekly snapshot that we release in Experimental (or maybe, just the e3 packages...). >> For the moment, I have this: >> >> root@GPLHost:openstack>_ ~# euca-get-console-output i-0002 >> i-0002 >> 2012-01-12T16:53:09Z >> FAKE CONSOLE OUTPUT of instance >> >> I'd like to have something better than a "FAKE CONSOLE"! :) > > That still needs to be implemented. Now that Anthony has done > a lot of the heavy lifting on the VNC console side, getting text > consoles done too shouldn't be too hard. I'll be looking forward this happens then! Let's hope it's going to be finished for the e release, and Wheezy. Thomas Goirand (zigo) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Openstack packages tags in Debian
On 01/21/2012 03:45 PM, Thomas Goirand wrote: > Hi, > > I have spent quite some time making sure that we have nice tags for > Openstack in Debian, making it easier to find each of our daemons and > programs. I have also pushed for a new tag called "Suite::openstack", so > that it's easy now to find absolutely all packages related to openstack > with a very simple query. > > Now, since there's a lot of packages (more than 50 binary packages!!!), > and that I did it only with my limited knowledge, I must have done few > mistakes. So if you are interested, I would welcome anyone to review the > work, and submit more tags, also removing the ones which are wrong. > > Everything is there: > http://debtags.debian.net/ > > And if you want more specifically to show all Openstack packages in > Debian, you can go there: > http://debtags.debian.net/reports/maint/openstack-de...@lists.alioth.debian.org > > Cheers, > > Thomas Goirand (zigo) When I'm at it, for Ubuntu maintainers, you might want to read this: http://www.enricozini.org/2012/debian/debtags-for-derivatives/ so you can import the tags directly from Debian in Ubuntu, which will save much of the (quite boring) work... Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Openstack packages tags in Debian
Hi, I have spent quite some time making sure that we have nice tags for Openstack in Debian, making it easier to find each of our daemons and programs. I have also pushed for a new tag called "Suite::openstack", so that it's easy now to find absolutely all packages related to openstack with a very simple query. Now, since there's a lot of packages (more than 50 binary packages!!!), and that I did it only with my limited knowledge, I must have done few mistakes. So if you are interested, I would welcome anyone to review the work, and submit more tags, also removing the ones which are wrong. Everything is there: http://debtags.debian.net/ And if you want more specifically to show all Openstack packages in Debian, you can go there: http://debtags.debian.net/reports/maint/openstack-de...@lists.alioth.debian.org Cheers, Thomas Goirand (zigo) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] XCP and Openstack questions
Hi Todd, and other openstackers, With the release of XCP 1.3-15 in Debian SID (which I uploaded 4 days ago), we have a python-xenapi package, and I already modified nova to build-depends on it, and nova-compute-xen to depends on it. I've tested it, and it works. However, all this is for the moment only in the git on alioth.debian.org, where we keep all our packaging work in Debian. I already started writing a README.xcp_and_openstack to document how to do an Openstack + XCP setup. However, there's still a lot that I don't know, and I'd be delighted to get help. Let me enumerate my issues. 1/ Networking I'm unsure what network manager will work with XCP. On this page: http://wiki.openstack.org/XenServerDevelopment it's written to use: --network_manager=nova.network.manager.FlatManager But would the VLan manage work? Also, should I use openvswitch? If yes, how does this work? Does OpenStack + XCP still use nova-network? Is all traffic for the VMs routed through it as with KVM and libvirt? Should I still create a bridge on the nova-network domU? How does Openstack injects IP addresses in an XCP VM? Can this even be done? Should I use dnsmaq on my nova domU? I did: nova-manage network create private 10.0.0.0/8 1 64 That seem to work. Now, how would I do to add a single, public, IP address, and assign it to a VM? 2/ Images What are OVF images? How to generate it? Where to download some? 3/ Console on the same wiki page, it tells about using VNC. While this does work, I didn't have access to the login prompt. What's the way, if using openstack, to tell that the console is hvc0 (or whatever is the Xen console device name)? Then, what's the normal way to access to the console, without using such hack (eg: customers obviously, wouldn't have ssh access to the dom0 in order to do port forwarding)? For the moment, I have this: root@GPLHost:openstack>_ ~# euca-get-console-output i-0002 i-0002 2012-01-12T16:53:09Z FAKE CONSOLE OUTPUT of instance I'd like to have something better than a "FAKE CONSOLE"! :) I hope I can have these concerns addressed so I can move forward, Thanks to anyone who can help, Cheers, Thomas Goirand ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [OpenStack] OpenStack with Xen
On 01/04/2012 01:05 AM, Guilherme Birk wrote:
> I've already have a Nova configuration working with kvm. Now I want to
> install and configure the Xen enviroment. Anyone can recomend any
> material or tutorial where I can find how to install, configure and then
> integrate with OpenStack ?
FYI, XCP has just been uploaded to Debian SID , so you might want to
have a try with it. But I have to warn you that there are few issues
that aren't yet fixed. Namely:
1/ XCP version reporting is broken. http://paste.debian.net/150865/ I
had to hack around. In
/usr/lib/python2.7/dist-packages/nova/virt/xenapi_conn.py, in the def
get_product_version(self):, I've just put: return (6, 10, 3) instead of
previously return tuple(int(part) for part in product_version.split('.'))
Note that upstream authors (Mike and Jon) are working on using
PLATFORM_VERSION instead of currently PRODUCT_VERSION so we have a real
fix, and not a hack as above.
2/ We need a python-xenapi package, which has already been worked out,
but this is still in the Git of alioth.debian.org, until 2/ is fixed.
Once we got this done, then nova-compute-xen can be built correctly.
3/ You'd better use both nova and xen-api from Alioth's Git, as there
are other fixes that haven't been uploaded to SID yet, but that I've
fixed already.
Last, I haven't yet succeed in having either console or network
connectivity in an instance. Hints would be welcome here (let's hope
I'll get more help from Citrix here...).
Last, I hope to find more people interested in running OpenStack with
XCP, and hope we can fix all the remaining issues together. :)
Cheers,
Thomas Goirand (zigo)
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Openstack + XCP (both on SID): XenAPI python script failing
On 01/01/2012 03:23 AM, Ewan Mellor wrote: > The operation it's trying to perform is high up your callstack, at vmops.py > line 826. It's deciding whether to do a VDI.resize or a VDI.resize_online, > based on the host version number. This is because the VDI.resize_online > feature was removed in XenServer 6.0. > > How is XCP advertising itself in host.software_version? We will have to > update the version check to cover XCP too. At the moment, it's just checking > whether host.software_version['product_version'] is 6.0 or above, which is > appropriate for XenServer but not XCP. > > Cheers, > > Ewan. Ewan, Thanks for your help, now it does really work! What I had to do was hacking in /usr/share/pyshared/nova/virt/xenapi_conn.py line 473. Since this function fails (eg: python stack dump), I hacked the return of a version using: return (5, 10, 3) as you told me it needed version 6, once I replaced the 5 by a 6, my XCP instanced got started successfully by nova! :) Now, we got to fix this hack into a real fix, and release this in SID. Do you know why get_product_version() in xenapi_conn.py fails? Cheers, Thomas Goirand (zigo) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Openstack + XCP (both on SID): XenAPI python script failing
On 01/01/2012 03:23 AM, Ewan Mellor wrote: > The operation it's trying to perform is high up your callstack, > at vmops.py line 826. It's deciding whether to do a VDI.resize > or a VDI.resize_online, based on the host version number. This > is because the VDI.resize_online feature was removed in > XenServer 6.0. > > How is XCP advertising itself in host.software_version? We will > have to update the version check to cover XCP too. At the moment, > it's just checking whether host.software_version['product_version'] > is 6.0 or above, which is appropriate for XenServer but not XCP. > > Cheers, > > Ewan. Hi Ewan, Thanks for your reply. Well, the issue is that the version thing seems totally broken, I had to hack in it, otherwise I'd have nothing. I heard that there's a file somewhere to set the version of XCP, but I don't know where. I'll ask Mike and Jon next week (if they are back on IRC). Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Openstack + XCP (both on SID): XenAPI python script failing
On 12/31/2011 02:47 AM, Johannes Erdfelt wrote: > On Sat, Dec 31, 2011, Thomas Goirand wrote: >> On 12/31/2011 02:03 AM, Johannes Erdfelt wrote: >>> On Sat, Dec 31, 2011, Thomas Goirand wrote: >>>> 2011-12-30 17:38:59,348 DEBUG nova.virt.xenapi.vmops [-] Resizing up VDI >>>> 1aacb195-9301-410b-989f-49bdce3a4813 from 0GB to 20GB from (pid=14409) >>>> _resize_instance /usr/lib/python2.7/dist-packages/nova/virt/xe >>> >>> This is likely the problem. The initial VDI is 0GB (probably 0 bytes). >>> >>> Can you confirm the image you are trying to boot is > 0 bytes? >> >> The image is about 500 MB (it's a lucid image). I'm following the guide >> here: >> >> http://wiki.openstack.org/XenServerDevelopment > > That's a pretty good guide. Can you confirm that glance actually thinks > the image is larger than 0 bytes? > > You can do that using the 'glance index' command. Here's the output (reformatted by hand to fit in this mail): root@GPLHost:os>_ # glance index ID Name Disk Format Size lucid_ami ami 524288000 kernelaki 4099360 ramdisk ari 7988037 >> The EC2 API doesn't seem to work on my domU by the way (euca2ools says >> "connection refused"). Is there something I should enable for it? > > It should be enabled automatically, unless you have disabled it via the > enabled_apis option. It seems that the issue was the addition of this in my nova.conf: --enabled_apis=osapi If I remove it, then all APIs ports are listening, and euca2ools are working. Unsurprisingly, I got the same issue with the EC2 as I have with the nova API. Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Openstack + XCP (both on SID): XenAPI python script failing
On 12/31/2011 02:03 AM, Johannes Erdfelt wrote: > On Sat, Dec 31, 2011, Thomas Goirand wrote: >> 2011-12-30 17:38:59,348 DEBUG nova.virt.xenapi.vmops [-] Resizing up VDI >> 1aacb195-9301-410b-989f-49bdce3a4813 from 0GB to 20GB from (pid=14409) >> _resize_instance /usr/lib/python2.7/dist-packages/nova/virt/xe > > This is likely the problem. The initial VDI is 0GB (probably 0 bytes). > > Can you confirm the image you are trying to boot is > 0 bytes? > > JE Hi Johannes, The image is about 500 MB (it's a lucid image). I'm following the guide here: http://wiki.openstack.org/XenServerDevelopment The EC2 API doesn't seem to work on my domU by the way (euca2ools says "connection refused"). Is there something I should enable for it? Cheers, Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Openstack + XCP (both on SID): XenAPI python script failing
Hi, When I did: nova boot test --flavor --image then I have the following python dump in nova-compute.log: 2011-12-30 17:38:59,348 DEBUG nova.virt.xenapi.vmops [-] Resizing up VDI 1aacb195-9301-410b-989f-49bdce3a4813 from 0GB to 20GB from (pid=14409) _resize_instance /usr/lib/python2.7/dist-packages/nova/virt/xe 2011-12-30 17:38:59,362 ERROR nova.virt.xenapi.vmops [-] instance 1: Failed to spawn (nova.virt.xenapi.vmops): TRACE: Traceback (most recent call last): (nova.virt.xenapi.vmops): TRACE: File "/usr/lib/python2.7/dist-packages/nova/virt/xenapi/vmops.py", line 199, in spawn (nova.virt.xenapi.vmops): TRACE: vdis = self._create_disks(context, instance, image_meta) (nova.virt.xenapi.vmops): TRACE: File "/usr/lib/python2.7/dist-packages/nova/virt/xenapi/vmops.py", line 180, in _create_disks (nova.virt.xenapi.vmops): TRACE: self._resize_instance(instance, vdi["vdi_uuid"]) (nova.virt.xenapi.vmops): TRACE: File "/usr/lib/python2.7/dist-packages/nova/virt/xenapi/vmops.py", line 826, in _resize_instance (nova.virt.xenapi.vmops): TRACE: str(new_disk_size)) (nova.virt.xenapi.vmops): TRACE: File "/usr/lib/python2.7/dist-packages/nova/virt/xenapi_conn.py", line 500, in call_xenapi (nova.virt.xenapi.vmops): TRACE: return tpool.execute(f, *args) (nova.virt.xenapi.vmops): TRACE: File "/usr/lib/python2.7/dist-packages/eventlet/tpool.py", line 76, in tworker (nova.virt.xenapi.vmops): TRACE: rv = meth(*args,**kwargs) (nova.virt.xenapi.vmops): TRACE: File "/usr/lib/python2.7/dist-packages/XenAPI.py", line 235, in __call__ (nova.virt.xenapi.vmops): TRACE: return self.__send(self.__name, args) (nova.virt.xenapi.vmops): TRACE: File "/usr/lib/python2.7/dist-packages/XenAPI.py", line 138, in xenapi_request (nova.virt.xenapi.vmops): TRACE: result = _parse_result(getattr(self, methodname)(*full_params)) (nova.virt.xenapi.vmops): TRACE: File "/usr/lib/python2.7/dist-packages/XenAPI.py", line 209, in _parse_result (nova.virt.xenapi.vmops): TRACE: raise Failure(result['ErrorDescription']) (nova.virt.xenapi.vmops): TRACE: Failure: ['SR_OPERATION_NOT_SUPPORTED', 'OpaqueRef:476adb81-e7a6-d286-f459-35772aeb4411'] What's happening? What kind of operation Openstack is trying to do on the SR (eg: what's the "xe" equivalent?)? Why could it fail? Cheers, Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] CRITICAL XENAPI_MISSING_PLUGIN xenhost
On 12/30/2011 03:02 AM, Ewan Mellor wrote:
> It's a JSON dictionary. It looks like it's only purpose is for the
> administrator to set arbitrary key-value pairs, and then get them again
> later. It looks completely useless and overdone to me. Both xapi and Nova
> already have databases -- I've no idea why someone felt the need to add a
> third.
>
> I'd not worry about it if I were you -- as long as the path is set to a
> directory it can write in, then it'll just quietly stick '{}' in the
> xenhost.conf and get on with life.
>
> Ewan.
Thanks Ewan, got it to work with {} in the file.
Thomas
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] CRITICAL XENAPI_MISSING_PLUGIN xenhost
Hi Ewan, Yes, fixing the path is easy, but *what is in this file*? (see below: it was what I was specifically asking for) I've been searching for quite some time on the net, and didn't find any info about this, and I have no access to a XCP / XenServer machine... Is that file shipped by default with a XenServer? Cheers, Thomas On 12/29/2011 01:47 PM, Ewan Mellor wrote: > It looks like it creates the file if it's not there -- it's just not smart > enough to create /usr/etc if *that's* missing. I reckon if you fix the path, > everything will work fine. > > I've no idea why that path was chosen even for XenServer (CentOS 5 based). > Something like /etc/openstack would be more appropriate in either > environment, in my opinion. > > Cheers, > > Ewan. > >> -Original Message- >> From: Thomas Goirand [mailto:tho...@goirand.fr] >> Sent: 28 December 2011 21:25 >> To: Ewan Mellor >> Cc: Johannes Erdfelt; openstack@lists.launchpad.net >> Subject: Re: [Openstack] CRITICAL XENAPI_MISSING_PLUGIN xenhost >> >> [...] >> >> '/usr/etc/xenhost.conf'"] >> >> I don't really mind the path issue (the issue is in the xenhost python >> script, I can fix it and set it to /etc/xcp/xenhost.conf instead), but >> what does the plugin expect to see in this file? >> >> Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] CRITICAL XENAPI_MISSING_PLUGIN xenhost
On 12/29/2011 10:40 AM, Ewan Mellor wrote: > You need chmod a+x /etc/xapi.d/plugins/* > > If you just want to install a package, Xen.org are building an RPM > for XenServer / XCP with these plugins: > http://downloads.xen.org/XCP/openstack/openstack-xen-plugins/. > > Cheers, > > Ewan. Hi, Thanks, but that's not what I'm trying to do here. I'm not interested in the RPM packages at all. I had a quick look though, in this package. I'm working on the Debian packaging of both XCP and OpenStack. I worked closely with Mike and Jon from Citrix, and last week, I uploaded XCP in Debian SID (that would be the first milestone of the project Kronos). I'm currently modifying nova packaging so that these files are packaged in a convenient "nova-xcp-pluggins". I have found out (by myself) that the plugin directory in Debian isn't: /etc/xapi.d/pluggins but rather: /usr/lib/xcp/plugins which indeed makes a lot more sense in a packaged, FHS respecting, environment, and I know both Jon and Mike worked on that. Now, I'm having another error though: (nova): TRACE: Failure: ['XENAPI_PLUGIN_FAILURE', 'host_data', 'IOError', "[Errno 2] No such file or directory: '/usr/etc/xenhost.conf'"] I don't really mind the path issue (the issue is in the xenhost python script, I can fix it and set it to /etc/xcp/xenhost.conf instead), but what does the plugin expect to see in this file? Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] CRITICAL XENAPI_MISSING_PLUGIN xenhost
- Original message - > On Thu, Dec 29, 2011, Thomas Goirand wrote: > > What am I doing wrong? What's that plugin thing about? Note that I've > > put stuff in /etc/xapi.d, like the "xenhost" python script, but it > > doesn't seem that's enough. > > Did you place it in /etc/xapi.d or /etc/xapi.d/plugins? The latter is > the correct path. > > JE The later, though I did that mistake first! :) any idea? Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] CRITICAL XENAPI_MISSING_PLUGIN xenhost
Hi, I'm trying to have both XenAPI (XCP, which I uploaded last week in SID) to work with Openstack (the version currently in experimental). Despite bug #909373 which I hacked my way around, nova-compute refuses to start with the below error. What am I doing wrong? What's that plugin thing about? Note that I've put stuff in /etc/xapi.d, like the "xenhost" python script, but it doesn't seem that's enough. By the way, if these have to be installed in the dom0, wouldn't it be wise to have it packaged as "openstack-xcp-xapi-plugin" or something similar? If so, what exactly should I put in this package? All what I have in plugins/xenserver/xenapi/etc/xapi.d? Should xcp-xapi be restarted after these are installed? Cheers, Thomas Goirand (zigo) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova Subteam Changes
- Original message - > 2011/12/9 Paul Voccio : > We put *every* single meeting in this > project in US business hours, *every* single meeting *outside* European > and Japanese business hours If I may, also *every* time it's out of reach for an normal humain living in GMT+8 (China, Singapore...). NO it is *NOT* easy to get up at 5am to spend time on IRC. Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Git repository for packaging
On 10/20/2011 04:55 PM, Dave Walker wrote: > On Thu, Oct 20, 2011 at 03:06:53PM +0800, Thomas Goirand wrote: >> I've found my way through https://github.com/openstack, and I'm >> happy to see that mostly everything is there now. However, I've >> found still missing: >> >> - python-novaclient >> - the debian folder for packaging files (there's no branch for that >> either) >> >> Is there any plan to fix this? > > I'm not sure this is a core project as yet. Currently it's developed > on https://github.com/rackspace/python-novaclient . Best, IMHO, would be to maintain python-novaclient directly inside the nova project, since this way we can do a version depend. Also, there's no branch or tags in this repository. How do I get the latest stable (Diablo)? On 10/20/2011 04:55 PM, Dave Walker wrote: > diablo-stable only opened for business yesterday. [...] Give > us a chance, please. Sorry, I didn't know. > You are also welcome to propose these patches if it is blocking you. What's blocking me is only knowing what patch is or not in the github stable/diablo branch. On 10/20/2011 07:43 PM, Chuck Short wrote: > Also with the packaging branches they are still located on launchpad at: > > https://code.launchpad.net/~openstack-ubuntu-packagers > > For Ubuntu specific nova you can find it at: > > https://code.launchpad.net/~ubuntu-server-dev What I'm trying to do here is maintaining my Debian packages in Git, using git-buildpackage, and then upload to SID. I believe the above are maintained in BZR, right? IMHO, it would make sense to switch to git-buildpackage instead. > As Dave said, all the patches we are carrying have either been > submitted upstream already or have been cherrypicked from the essex > branch. > > Thanks > chuck Thanks for the info, but... I'm not interested in essex (I'm doing package work in include Diablo in SID) and telling me that all the patches has been submitted doesn't help, I need to know which one I'll be able to find in the stable/diablo branch currently in github. So, let me rephrase my question: how many, and which of the patches carried in the current Debian package in Oneiric are already upstreamed in the stable/diablo branch in github? Cheers, Thomas Goirand (zigo) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Git repository for packaging
Hi, I've found my way through https://github.com/openstack, and I'm happy to see that mostly everything is there now. However, I've found still missing: - python-novaclient - the debian folder for packaging files (there's no branch for that either) Is there any plan to fix this? Also, I've seen numerous patches in debian/patches in the Ubuntu package. Why aren't these sent to the "upstream" github diablo branch? Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Glance unit test failing on SID, bad state for Nova in SID
On 09/25/2011 08:42 PM, Vishvananda Ishaya wrote:
> It looks like you need to update python-novaclient to a newer version.
>
> Nova depends on python-novaclient for some tests, but it is shipped
> separately.
>
> Vish
Hi Vish,
Yes you are right, that was the issue. Thanks a lot, and sorry to have
missed that.
However, in this case, Nova *must* have a versionned (build)dependency
on python-novaclient! Can this be added upstream (maybe, by the new QA
team?), so that this is fixed? I will anyway, add it to my Debian
package before the upload.
Would it make sense to, in the future, have python-novaclient to be
included in nova itself, so that we can depend with python-novaclient
(=${binary:Version})? If not, I think we need a strategy so that such
important dependency isn't forgotten next time.
Also, what is the reason so that the unit test suite is having || true,
thus silently building a package even with such quite serious issue?
I still have one failed test:
==
ERROR: test_spawn_with_network_info
(nova.tests.test_libvirt.LibvirtConnTestCase)
--
Traceback (most recent call last):
File
"/root/sources/diablo/nova/nova-2011.3/nova/tests/test_libvirt.py", line
887, in test_spawn_with_network_info
network_info = _fake_network_info(self.stubs, 1)
NameError: global name '_fake_network_info' is not defined
--
Was there some Ubuntu specific patches added in libvirt 0.9.2-4ubuntu13?
Thomas
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
[Openstack] Glance unit test failing on SID, bad state for Nova in SID
Hi, During the build process, I could see: test_add_image_with_image_data_as_file ERROR Any idea why it's doing this? Apart form that single unit test which is failing, Swift and Glance seems to build with no issue in SID. I didn't actually ran and test them *yet* on my test servers, since I want to be able to test Nova as well at the same time (I'm doing just few functional tests before uploading to SID). But for Nova, it seems to be more problematic. The package now builds, since the debian/rules has: ./run_tests.sh -N || true So it builds only because the tests are allowed to fail (see below the traceback: as much as I remember the traceback content, the issue is still the same as 2 months ago with the test suite). We had some discussions already about it, and Soren wrote that the issues were with python-webob and python-eventlet. So I took the version from Oneiric, built and used it instead of what was available in SID. Few remarks: python-webob in Debian SID: 1.1.1, in Oneric 1.0.8 python-eventlet in Debian SID: 0.9.16, in Oneric: 0.9.15 For webob, there was no debian/patches. For python-eventlet, it was insignificant (at least for what I could see). Rerunning the test suite after using the Ubuntu version didn't show any improvement. Since Soren seemed to say that the issue was in the distribution (eg: dependencies in SID are different than in Ubuntu), and not Nova itself, is there any other dependency which I should look into? What has been changed/fixed/patched in Ubuntu so that the unit test is working? What would be the next course of action that you would advise? Cheers, Thomas Goirand (zigo) P.S: After an extremely long period of time, I finally got the "pkg-openstack" project approved on Alioth, to track bugs as a team (I was unlucky to request for the project the same day Alioth got migrated to new hardware). Please register to "openstack-de...@lists.alioth.debian.org" after 24 hours, if you want to receive future bug reports in Debian. Note that I'm doing this since this list is a "subscriber only post" type, so it is a bad fit for sending Debian BTS bug reports. Please do not use that list for anything else than reading bug reports, post here instead for any other topic. -- Nova unit test traceback: == ERROR: -- Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/nose/suite.py", line 208, in run self.setUp() File "/usr/lib/pymodules/python2.6/nose/suite.py", line 291, in setUp self.setupContext(ancestor) File "/usr/lib/pymodules/python2.6/nose/suite.py", line 314, in setupContext try_run(context, names) File "/usr/lib/pymodules/python2.6/nose/util.py", line 478, in try_run return func() File "/root/sources/diablo/nova/nova-2011.3/nova/tests/__init__.py", line 47, in setup from nova.network import manager as network_manager File "/root/sources/diablo/nova/nova-2011.3/nova/network/manager.py", line 60, in from nova import manager File "/root/sources/diablo/nova/nova-2011.3/nova/manager.py", line 60, in from nova.scheduler import api File "/root/sources/diablo/nova/nova-2011.3/nova/scheduler/api.py", line 20, in from novaclient import v1_1 as novaclient ImportError: cannot import name v1_1 -- Ran 0 tests in 0.002s FAILED (errors=1) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Openstack in China kick-off conference, Tuesday 6th of September 2011
On 09/09/2011 10:46 AM, ben wrote: > Hi all, > This is the slides and photos from OpenStack conference in china. > slides: http://goo.gl/VNuOj > photos: http://goo.gl/mUCT2 > > Cheers, > Ben I've put a link to it on the site, plus the presentations that we received from the speakers (eg: we don't have all of them, but nearly). Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Openstack in China kick-off conference, Tuesday 6th of September 2011
Hi, The conference of yesterday was, according to both attendees, other speakers and organizers, quite successful. There was around 400 attendees, and the conference room was full, which was better than we expected. Some attendees even traveled form far away in China just to attend the conference (I could speak to someone from Guangzhou for example). We've seen lots of big and smaller companies showing a big interest in Openstack, and there's good hopes for having many new OpenStack users (and to a lesser degree, also contributors). I'd like to publicly thanks all the speakers that came from abroad, and also thanks Du Yujie from C2SC and Michael from China Telecom for all their work. On our organizer debriefing after the conference, we all agreed that we shall make other events on a schedule basis. I'd be happy to see some workshops organized as well. As soon as we have them, we'll put the presentations (PPT / ODP) online on the www.openstack-china.org website. Thomas Goirand On 09/02/2011 02:31 AM, Thomas Goirand wrote: > Hi, > > I am the initiator of a conference in Shanghai about OpenStack (well, in > fact, me from GPLHost, and Du Yujie from CS2C). Since I started this > idea last may, talking with John Engates (Rackspace CTO) during the > Beijing , we had lots of other companies joining the event as > organizers (Intel, China Telecom, etc.) and many co-organizers too. > > The one-day event will initiate a new Openstack comunity in China, and > feature the overview of OpenStack for all developers, users, ecosystem > partners, open source enthusiasts, and cloud computing technologists the > first half of the day, followed by a technical research talk in the > afternoon. As an attendee, you should expect to: > > - Learn why we initiate COSUG (China OpenStack User Group), what COSUG > will contribute to Chinese enterprises and developers, how COSUG works > in the future and How to get involved in the COSUG as an individual > contributor, user or participating organization. > > - Learn the history and vision of OpenStack, and why organizations > across the world are backing the open source cloud platform > > - Gain a clear understanding of OpenStack technologies, including a > feature overview and popular use cases > - Hear directly from organizations who are implementing the technology > - Have an opportunity to network with COSUG members. > > To discuss this emerging enabling open-source technology, OpenStack > Shanghai Event invites you to join the conference to feature technical > presentation. > > See you on the 6th of September 2011 in Shanghai. > > For more details about the event (list of topics, list of speakers with > descriptions, companies joining the event, sponsor lists, location, > schedule, etc.), please see this site: > > http://www.openstack-china.org/en/event.html > > Entrance is for free, but we ask everyone to kindly register here: > > http://www.openstack-china.org/en/event-registration.php > > Cheers, > > Thomas Goirand ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Openstack in China kick-off conference, Tuesday 6th of September 2011
Hi, I am the initiator of a conference in Shanghai about OpenStack (well, in fact, me from GPLHost, and Du Yujie from CS2C). Since I started this idea last may, talking with John Engates (Rackspace CTO) during the Beijing , we had lots of other companies joining the event as organizers (Intel, China Telecom, etc.) and many co-organizers too. The one-day event will initiate a new Openstack comunity in China, and feature the overview of OpenStack for all developers, users, ecosystem partners, open source enthusiasts, and cloud computing technologists the first half of the day, followed by a technical research talk in the afternoon. As an attendee, you should expect to: - Learn why we initiate COSUG (China OpenStack User Group), what COSUG will contribute to Chinese enterprises and developers, how COSUG works in the future and How to get involved in the COSUG as an individual contributor, user or participating organization. - Learn the history and vision of OpenStack, and why organizations across the world are backing the open source cloud platform - Gain a clear understanding of OpenStack technologies, including a feature overview and popular use cases - Hear directly from organizations who are implementing the technology - Have an opportunity to network with COSUG members. To discuss this emerging enabling open-source technology, OpenStack Shanghai Event invites you to join the conference to feature technical presentation. See you on the 6th of September 2011 in Shanghai. For more details about the event (list of topics, list of speakers with descriptions, companies joining the event, sponsor lists, location, schedule, etc.), please see this site: http://www.openstack-china.org/en/event.html Entrance is for free, but we ask everyone to kindly register here: http://www.openstack-china.org/en/event-registration.php Cheers, Thomas Goirand ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Issues with Packaging and a Proposal
On 08/26/2011 12:46 AM, Monty Taylor wrote:
>> What would be the use of "pristine-tarball" ? Prepare .tar.gz for
>> generic distributions, like RPMs or let's say Gentoo?
>
> Nope. It helps in generation of tarballs for the debian packaging too.
> Check out the --git-pristine-tar option to git-buildpackage. It's pretty
> cool... I think you'll like it.
I still don't get it. If we use:
--git-upstream-branch=upstream-${whatever}
that will create the orig.tar.gz for us automatically, and since we are
upstream authors, why do we need a "pristine-tarball" branch for?
As much as I understand, the pristine-tar thing is to be used when
there's a tarball from upstream, and we need to keep tracks of a delta.
But since we aren't even producing tarballs for Openstack, I don't get
what would be the point. Can you enlighten me? :)
Thomas
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Issues with Packaging and a Proposal
On 08/25/2011 06:38 PM, Soren Hansen wrote:
> That doesn't mean that using a linux distro (not a PPA, an actual
> distro) as a distrubtion channel is the wrong thing to do. It just means
> that we don't trust our own code quality very much. When we released
> Cactus, we were reasonably happy with it. After working on Diablo for a
> little bit, we realised how many bugs we'd fixed, so if people came and
> asked for help, it was entirely likely that their problems were solved
> in Diablo, so we asked them to try that.
Why fixes weren't backported to Cactus then? Sorry, I don't know Ubuntu
enough. But in Debian, we have point releases for that (and in the mean
while, stable-proposed-updates), isn't there something like that in
Ubuntu for the current stable? (I honestly don't know)
>> (don't get me started on the broken 2.6.6-3~ thing)
>
> I'll probably regret this, but what's the problem?
I didn't understand what even is the 2.6.6-3~. Please explain!
>> This is not unique to PPAs. Our repo can be just as trustworthy. In
>> fact, we're shipping software which runs large portions of your data
>> center, so if you don't trust us to make it, well, you're sort of
>> screwed.
>
> Just because we're good at writing OpenStack doesn't mean we're good at
> maintaining Debian-style build infrastructure. They're very different
> things. I trust Canonical's buildd admins and maintainers much more than
> you or me to run these things. Sorry if you find that offensive, but
> that's the way I feel.
I believe that if we need help from the Debian community to maintain
some buildd for OpenStack, it may be found. I can ask the DSA about it.
The only thing that might then be needed would be the sponsoring of the
hardware. If Rackspace / Dell / Intel provides it, I think it wont be an
issue to find people to help maintaining buildd. At least it doesn't
hurt to ask.
>> BTW - the "can't reach the internet from the builders" is only really a
>> concern in a project like Debian and Ubuntu where you have random people
>> uploading random un-reviewed things.
>
> How do you figure that? As you pointed out yourself, the Sphinx build
> tried to connect to the Internet. I don't know exactly what it was
> trying to fetch, but it seems obvious that whatever it does fetch
> probably factors into the build in one way or another. If what it gets
> back is broken (or worse: compromised) that might break our stuff as
> well.
I agree with Soren here. Having buildd cut-off from the internet ensure
that a given package isn't trying to access the outside. It *must* not,
and we have to make sure of it, since it is a quite common mistake. But
is that a hard thing to do? (sorry, I never tried building a buildd, I
don't know what it involves...)
>> No. After Cactus was released, it didn't build because of issues in
>> python-eventlet related to the OpenSSL transition.
> Yes. *Because of issues in python-eventlet*. Forking *the packaging*
> because of lack of Debian support when the real problem is with the
> state of OpenStack's dependencies isn't going to help.
The issue with python-eventlet was because due to some removal of some
functions in OpenSSL, if I remember correctly, which made
python-eventlet not being able to build during the transition.
Controling python-eventlet wouldn't have change the issue with OpenSSL
which was due to licensing issues. Ubuntu was just not affected because
things are migrated from Debian at once from SID, but it's not an issue
about controlling packages here.
>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634406
>
> Because of python-webob being out of date.
I've missed the reply from Jay Pipes... :(
Does it means that Cactus cannot build with webob 1.0.8+?
> Using backports (especially locally maintained ones) means that you're
> all alone in dealing with security or any sort of other issues. That's
> the sort of stuff that makes it hard for me to sleep. Clearly, I care
> too much.
Right, that's an issue. But it depends how much things are in the
backports. To some degree, it can be tolerable. What kind of libs are
you thinking about here?
Also, if running in backports.d.o, you are not alone, there's the Debian
security team to help, and most of the time the original maintainer.
That's of course not the case for a *private* backport repo.
>> I don't think that c) is valid (see above), and I don't think PPAs >>
are more trustworthy than a private repository with a well
>> maintained GPG key and a ${whatever}-archive-keyring package
>> published. As long as the release file is signed, you have the same
>> security, IMHO. Please let me know if/why I'm wrong here.
>
> It's not just about gatekeeping and signing of Packages and Release
> files. It's also about trusting its reproducability.
Sorry, I don't understand here. Maintaining a private Debian repo by
itself is extremely simple, I don't get where you are seeing an issue.
The *only* advantage of a PPA is to have automated buildd for multiple
ar
Re: [Openstack] Issues with Packaging and a Proposal
On 08/25/2011 06:47 PM, Soren Hansen wrote: > ..and not every (in fact, hardly any at all) backport involves > cherry-picking anything. But *maintaining* it does, while an issue is fixed in trunk. I've just read that this has been an issue in Cactus (eg: bugs fixed in Diablo, but not fixed in Cactus). Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Issues with Packaging and a Proposal
On 08/25/2011 05:00 AM, Monty Taylor wrote: > - PPAs do not allow me to upload packages to be built for wheezy or > squeeze nor host them. > - We need to provide a set of packages that someone who is basing their > environment on squeeze can be assured will work. > - We will be maintaining backported dependency packages from now until > the cows come home. As I wrote, I did that already, and I'd be very happy to continue doing so in a more official channel. If you want a simple script for maintaining a Debian repo AND a yum repo, here's what we use internally: http://git.gplhost.com/gitweb/?p=mgmt-scripts.git;a=blob;f=scripts/scan_archive;h=db7647732b989b35ae7d8a48c80a48ecf67e4612;hb=c61a4daf9c7795d9f328e1d0d51dd76d45295c38 If someone wants to use one of the packaged alternatives, that's fine too, but this involves more work. For the RPM repository, the issue is that *packages* have to be signed, not the Release file. What we do here is that we have a build machine that holds the packages to be uploaded, then we use this script that uses rsync over ssh to sign the packages: http://git.gplhost.com/gitweb/?p=mgmt-scripts.git;a=blob;f=scripts/yum-pull-sign-createrepo;h=398465bc98a123b938e8600019b4a4210c00;hb=c61a4daf9c7795d9f328e1d0d51dd76d45295c38 It's a bit hackish, but it works, and we found it safer to have a virtual machine just for signing packages with nothing else installed. > If you (or I) do a one-off backport, we then upload a source package and > then, often, don't shove the code anywhere. That's because a lot of the > time it's easiest just to do dget, hack version, debuild -S, dput. Outch! Bad habit. Better do: git checkout upstream-squeeze-backport git cherry-pick -x git push git-buildpackage cd .. dput *.changes IMHO, that's not much more work, and at least, you're keeping a track of what you're doing. It should always be done this way, in an idea world. Cheers, Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Issues with Packaging and a Proposal
On 08/25/2011 01:59 AM, Monty Taylor wrote: > This is one of the things we should discuss. I was talking about adding > the packaging branches to the main repo - so master would be the actual > VC used by the project devs. It would look like: > master - main development target > pristine-tarball - pristine-tarball diff information > upstream-* - packaging 'upstream branch' > debian-* - debian packaging branches By all means, *please* avoid "master" as a branch name. Call it bleeding-edge/unstable/testing/devel if you want, but simply not "master". :) What would be the use of "pristine-tarball" ? Prepare .tar.gz for generic distributions, like RPMs or let's say Gentoo? >> Unless I didn't understand what you mean by "one-off" (please elaborate >> so that we avoid confusions), if backports are to be uploaded to >> backports.debian.org, then we'd better take care that they are >> maintained correctly. So having a branch for it sounds like a >> requirement to me. I wouldn't take the responsibility to upload to >> backports.d.o if we don't take it seriously. I'm already feeling quite >> bad that I've left the current packages in the air without fixes, with >> the build process totally broken... :( > > Sorry - I should indicate here. (forgive me if I sound snarky) - I don't > really personally care about backports.d.o - it's the backported library > packages that go into the openstack repo I care about. > > BUT - I may have been unclear here - I think there should definitely be > a repo and it should match the standards above, I just don't think it > needs to have a branch that's related to upstream VC. > > Monty In that case, we could maintain the upstream-*-backports and debian-*-backports branch in Alioth. I believe maintaining a Git for what we release in *.debian.org is always good (eg: backports.d.o or just normal main). That's what is cool with the distributed part of Git: it is easy to do that, and merge from one repo to another. Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Issues with Packaging and a Proposal
#x27;m thrilled to see it > happen I think that's more a mater of communication. With some maintainers, it's going to be easy. With others, it will be harder. > but I don't believe Debian is suitable as a reference platform Which is the "reference platform" is another debate entirely. When it goes down to me only, I'm fine with Ubuntu being the reference, as long as we *also* care for SID/Squeeze-backports, which hasn't been the case (at least over the last month). Having jenkins to do unit tests with a SID and Squeeze-backport chroot would certainly help to get things in a much better shape. I think that would be the first step. If I can help for that, please let me know. Cheers, Thomas Goirand ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Issues with Packaging and a Proposal
Hi Monty, I've been quite pleased to read your mail. Thanks for that. On 08/24/2011 11:56 PM, Monty Taylor wrote: > This deals with: > - Lack of Debian support. > - PPAs are Async. > - Not integrated with CI. > - Lack of RPM support. > - PPA Fragmentation. If I may add as well my personal view on it. It's just my 2 cents, and my view on it, nothing so important, especially that I haven't been involved much in the development/packaging of Openstack yet. IMHO, there's an issue with things not being built in SID indeed. I've been struggling to build Nova in SID. Cactus doesn't build anymore at all. Diablo does if you build with the docs and the unit tests, which obviously isn't what we want (and I wouldn't upload like this). There's (pardon me) shitloads of errors printing on the screen when I build, and it's scary. Sorry, I didn't work on it much yet (since I'm currently working on packaging Xen API and other stuff, which at the end will benefit Openstack too), but sooner or later, I'll go back to it. As I understand it from a distance, this happens because SID is evolving at a different pace than Ubuntu. To upload Cactus in SID, I had to wait for the correct timeframe, and the window was very short where Cactus could build. But at the end, in SID, we're seeing a technology preview of the issues we're going to face sooner or later in Ubuntu. So we'd better face the issues directly, no? Also, if Rackspace is using Debian, I guess they are using the current stable (Squeeze) in production. If so, then they are doing Squeeze backports. That's what I've been working with too (I'm running a Squeeze backport of Cactus). Then why aren't we sharing the efforts here, and have OpenStack's built being uploaded to backports.debian.org for everyone to use? I can see a silly duplication of work here that could save time for everyone. FYI, my Cactus backport for Squeeze is at: http://ftparchive.gplhost.com/debian openstack main which sux too... > I'm suggesting: > - we move all packaging to git > - we manage it consistently via git-buildpackage Definitively, using git-buildpackage is a time saver. Having the packaging and the "upstream" sources in the same Git tree, and being able to switch from one to another is very convenient! It also forces to have a really working clean Makefile target. > As Thomas Goirand suggested, we will add a packaging branch to the repo > of each of our projects and have git-buildpackage do the right thing. We > can have gerrit set different ACLs for the packaging branch so that a > different set of folks (the packaging team) can handle the reviewing of > that branch. Combining this with a pristine-tar and having Jenkins push > some tags back to the repo on package release, it means that we can > trace any release of software back to our code repo, and that only the > repo is needed to re-create any particular release. If I may suggest... In many Debian packaging team, we use the following naming scheme for the Git branches: - upstream-sid - debian-sid - upstream-lucid - debian-lucid - upstream-squeeze - debian-squeeze - upstream-squeeze-backports - debian-squeeze-backports This isn't carved into the stones of the Debian policy manual, but it's nearly a standard that many DDs are using. Just for the sake of example (no offense I hope, to name the obvious), if you want to build a Squeeze backport, you'd just do: git checkout debian-squeeze-backports git-buildpackage --git-upstream-branch=upstream-squeeze-backports \ --git-debian-branch=debian-squeeze-backports The branch named "master" is to be avoided because it doesn't express anything at all. Also, if you don't like git-buildpackage, there are alternatives, like the "git-stuff" package from Daniel Baumann. It might be a bit too experimental and has no documentation, but it's quite cool. Just adding a tag to a branch does: - Create the debian/changelog - Builds - (eventually) uploads > Having branches on top of upstream source is almost useless here, as in > most cases we're doing one-off backports. Unless I didn't understand what you mean by "one-off" (please elaborate so that we avoid confusions), if backports are to be uploaded to backports.debian.org, then we'd better take care that they are maintained correctly. So having a branch for it sounds like a requirement to me. I wouldn't take the responsibility to upload to backports.d.o if we don't take it seriously. I'm already feeling quite bad that I've left the current packages in the air without fixes, with the build process totally broken... :( Again, that was just my 2 cents... Cheers, Thomas Goirand (zigo) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Where to find the Debian packaging for nova/swift/glance
Hi Monty, Thanks for your quick reply. On 08/24/2011 12:09 AM, Monty Taylor wrote: > Hi Thomas! > > Packaging for nova is _currently_ (like, this morning) on launchpad - as > is all of nova dev. (this will be changing soon) However, we do not keep > packaging in the upstream source tree. It shouldn't be in the main tree, but in a *branch* (eg, in that branch, you would do "git merge master" and only work in the debian folder)... > However, I'm working on rolling out an all new and improved packaging > tooling that should make it easier for you to collaborate with us > (git-buildpackage is certainly involved- as are builds for debian hosts) > > Gimme, like, 4 more hours and I'll have something to point you at as far > as that goes. Take your time, I'm heading to bed at this time (it's midnight here in Shanghai...). Just ping me if it changes! :) > However, in the mean time, packaging can be found at: > > lp:~openstack-ubuntu-packagers/nova/ubuntu Ok, so if I understand you, it didn't change, and it's still using bzr, right? So we have: - git for "upstream" source - bzr for the packaging Indeed, this needs to change! :) Also, I have tried building Diablo v3 in SID. And it's quite horrible. Building the doc with sphinx fails horribly with loads of errors printed (but ignored), and the unit tests are simply failing to even start. Can one of the core developers have a look into what's happening? I can't do any packaging work, and even less upload to Debian, if it stays like this, and I'd be really happy to be able to have all in sync between Debian and Ubuntu if possible. Cheers, Thomas Goirand (zigo) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Where to find the Debian packaging for nova/swift/glance
Hi, Since Diablo is approaching, I'd like to try the Dv3 and get it packaged for SID, instead of the current Cactus release which miserably fails to build. But since there was some move to Github, I'm not sure where to get the Debian files. I did: git clone https://github.com/openstack/nova.git and got the source code. I was expecting to find the debian folder inside a debian branch, but I didn't. Is the debian packaging still on launchpad? If so, can this be moved as a branch of the repository above, so that I can use git-buildpackage, like I would normally do with other packages? Cheers, Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Ubuntu run instance error + xen
On 08/20/2011 05:40 AM, Joshua Harlow wrote: > So what I’ve figured out is the following seems to work with xen4. The naming of sda vs xvda has nothing to do with the hypervisor, and a lot to do with your kernel. Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Ubuntu run instance error + xen
On 08/20/2011 01:26 AM, Joshua Harlow wrote: > Ok but I am going through libvirt instead of xenapi since I am just > using a debian + xen-hypervisor package. > > Also going through libvirt seems to be better, since it doesn’t make > your setup as “strongly” connected to xen. > > For those using the following in debian/ubunbu would the usage of the > xenapi still work? > > ii libxenstore3.0 4.0.1-2 > Xenstore communications library for Xen > ii linux-image-2.6.32-5-xen-amd64 2.6.32-35 > Linux 2.6.32 for 64-bit PCs, Xen dom0 support > ii xen-hypervisor-4.0-amd64 4.0.1-2 > The Xen Hypervisor on AMD64 > ii xen-qemu-dm-4.0 4.0.1-2 > Xen Qemu Device Model virtual machine hardware > emulator > ii xen-utils-4.04.0.1-2 > XEN administrative tools > ii xen-utils-common 4.0.0-1 > XEN administrative tools - common files > ii xenstore-utils 4.0.1-2 > Xenstore utilities for Xen > > Since I thought xenserver was a separate product? The support of sdX vs xvdX doesn't depend on your hypervisor, but on the Linux kernel that you run. Please see the Squeeze release notes about it (which I cared to write ...). Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Ubuntu run instance error + xen
On 08/20/2011 01:52 AM, Joshua Harlow wrote: > For my nova/virt/libvirt.xml.template on my compute node. > > The following is being done. > > #if $type == 'xen' > #set $disk_prefix = 'sd' > #set $disk_bus = 'scsi' > linux > /dev/xvda > > Should that be /dev/sda for the /root node here? *NO* ! There's never a reason to use sda instead of xvda (unless you are running an antediluvian kernel for your domU). This isn't your issue. Please read the Debian release notes about Xen that I wrote. Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Ubuntu run instance error + xen
On 08/19/2011 01:31 PM, Isaku Yamahata wrote: > It looks you specified "root=/dev/xvda", but the disk that is > instantiated is /dev/sda. > But I didn't see why it happened. Did you customized the template > for libvirt, libvirt.xml.template? This seems wrong then, because under Xen, you should use xvda, not sda anymore. Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Please welcome OpenStack's new community manager, Stefano Maffulli
On 08/18/2011 03:55 AM, Jay Pipes wrote: > I'd also like to thank Stephen Spector for his work as Community > Manager. He is taking on a new role, but will be instrumental in > helping Stefano get up to speed, and will continue to focus on making > sure the October design summit comes off with out a hitch. Will Stephen leave Rackspace and Openstack? Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] OCCI on OpenStack
- Original message - > Hi Amine and everyone else, > > My name is Hareesh and I am engaged in the EU FP7 project SAIL on behalf > of Ericsson, specifically in Work Package D: Cloud Networking. > > As part of Ericsson's prototyping effort in WP-D, we have been working > on a implementation of OCCI on OpenStack during the summer.That work has > been progressing well and we have a nearly ready prototype in the lab. I'm also interested by it. Would you be able to share even an unfinished patch? Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Unable to publish an image on debian 6
On 08/16/2011 05:41 AM, Joshua Harlow wrote: > Hi all, > > I am using debian 6 (wheezy) + nova-diablo-3 + glance (from git) and > have installed the needed python pkgs and have the correct servers and > such running. > > I am seeing the following error when running the following: > > #uec-publish-tarball ttylinux-uec-i386-11.2_2.6.35-16_1.tar.gz ttbb i386 The script itself is totally broken, it has nothing to do with nova itself. If I remember well, it has to do with the "name" parameter somewhere. I didn't have time to investigate further, but it would need to be repaired at some point. Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] What would it take to add Debian in the unit tests of Jenkins?
Since few days/weeks (I'm not sure when), nova doesn't build at all. I'd be very happy if Jenkins had a test suite in Debian SID too... Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] nova on Debian
Hi Simon,
I'm the Debian developer responsible for the package in Debian.
On 07/21/2011 07:58 PM, Simon Guerrero wrote:
> Hi folks
>
> I've been trying to get an install of openStack working on Debian
> (sid, for my sins). I figured a good start point might be the
> Ubuntu Maverick guide.
The word "unstable" doesn't mean "crashes often", but "is updated
often". So it doesn't mean that it's going to fail just because you are
using SID!!!
> I followed the guide, then the "Installing Nova On A Single Host"
> guide. I had to make a few changes, but it looked generally OK.
> However, I'm finding nova-compute won't start because it gets a
> "Permission Denied" error, namely:
>
> (nova.exception): TRACE: if ret is None:raise
> libvirtError('virConnectOpenAuth() failed')
> (nova.exception): TRACE: libvirtError: unable to connect to
> '/var/run/libvirt/libvirt-sock', libvirtd may need to be started:
> Permission denied
Unfortunately, I haven't been able to find out what the problem was.
Nova is part of the libvirt group in Debian, as you can see in the postinst:
if [ "$1" = "configure" ]; then
if dpkg-vendor --derives-from ubuntu ; then
LIBVIRTGRP=libvirtd
else
LIBVIRTGRP=libvirt
fi
if ! getent group ${LIBVIRTGRP} | grep -qE '\'
then
adduser nova ${LIBVIRTGRP}
fi
fi
Indeed, there's a difference between Debian and Ubuntu. In Ubuntu,
libvirt group is libvirtd, but in Debian it's libvirt, hence the
postinst above for nova-compute.
But it still doesn't work. The only way to have it working is to set
more permissive rights for the socket file in
/var/run/libvirt/libvirt-sock. That is done by tweaking the
configuration files of libvirt-bin (eg: if you put 777 for the variable
unix_sock_rw_perms in /etc/libvirt/libvirtd.conf).
I didn't have time to investigate the issue, but it's possible that
somewhere in the Nova code, there's something that uses the group
libvirtd instead of libvirt. Help on this would be much much appreciated.
If you don't really care, just put 777 in unix_sock_rw_perms and go with
it, but of course, that's a security issue!!!
> Looks like it might be a problem with euca2ools. It seems to be taking
> the path "images/aki-lucid/image" and trying to remove the end of it,
> but doing a rather greedy match on "image" and ending up taking out the
> start too!
No, when you put the permissions above for the libvirt socket file,
euca2ools are working just fine.
> Can anyone help, especially with the Permission Denied error? I figured
> if I could get this running, the modified instructions might be useful
> to other Debianites in the meantime...
It'd be great if you could report the issue in the Debian bts (use
"reportbug" on the shell to do that, or one of the graphical version if
you like it more this way), and write about the workaround in it.
Also, there's more grave issues we are facing in Debian. It's been a
while that Nova simply doesn't build anymore. It used to be just an
issue with the test suite, but now it's more serious. It did before, but
now that SID has evolved, there's lots of issues, possibly because of
some python modules that have been upgraded. For sure, sphynx is also
totally broken... :(
I've been quite alone working on the Debian port. I'd appreciate a lot
to have some help.
Thomas
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [Keystone] Tenants and service relationship...
On 08/11/2011 05:11 AM, Yogeshwar Srikrishnan wrote: > Keystone would have different endpoint_template for each of those > regions.Endpoint Template represents the template of a consumable > service (URL) and is made of parameters that also provide information > like region, service name as well. A tenant could be mapped to each of > the different endpoint_templates via the endpoint association. > > Ex: > Service X could be present in Regions R1 and R2 > This case we would have endpoint_templates mapped for the same service > for each region. > endpoint_templates > > ET1 => (for Service X and Region R1) > ET2=> (for Service X and Region R2) > > Regards > Yogesh Is it possible to have keystone to authenticate against a MySQL database of users too? Sorry if my question sounds a bit newby-ish, since I didn't try keystone yet. Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova (Cactus) unit test is failing #634406
- Original message - > Hi Thomas, > > I don't think it's because nobody cares. You may have just posted to > the mailing list on release day :) I didn't realize it, sorry! It seems I'm the specialist to ask for stuff at the worst moment! :) If its released, then I guess I should get working on the Debian version of the "d" release then! thomas (from my phone) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova (Cactus) unit test is failing #634406
I'd be happy to have anyone helping me with what's bellow. If needed, I can provide access to a SID server for it... It's quite disappointing to see that nobody seems to care. Thomas On 07/29/2011 10:04 PM, Thomas Goirand wrote: > Hi, > > As per: > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634406 > > Cactus doesn't pass its unit tests anymore in SID and testing. > > Can anyone have a look and provide a fix for it? I would happily upload > a fix for that. I not really willing to upload pre-versions of Diablo, I > think it's better to just support whatever is stable, at least for the > Debian port. > > Thomas Goirand (zigo) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Nova (Cactus) unit test is failing #634406
Hi, As per: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634406 Cactus doesn't pass its unit tests anymore in SID and testing. Can anyone have a look and provide a fix for it? I would happily upload a fix for that. I not really willing to upload pre-versions of Diablo, I think it's better to just support whatever is stable, at least for the Debian port. Thomas Goirand (zigo) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Fwd: Bug#633600: nova: inadequate copyright file
Hi, Seems debian/copyright isn't correct and needs some refinement. I don't think that openwrt-x86-ext2.image and openwrt-x86-vmlinuz should be in the original sources at all. These are sourceless files, and cannot fit Debian at all. Thomas Original Message Subject: Bug#633600: nova: inadequate copyright file Resent-Date: Mon, 11 Jul 2011 23:54:02 + Resent-From: Mike O'Connor Resent-To: debian-bugs-d...@lists.debian.org Resent-CC: Thomas Goirand Date: Mon, 11 Jul 2011 19:50:39 -0400 From: Mike O'Connor Reply-To: Mike O'Connor , 633...@bugs.debian.org To: Debian Bug Tracking System Source: nova Version: 2011.2-1 Severity: serious Justification: Policy 12.5 In reviewing this source package, I find several problems with the copyright file: tools/ajaxterm/sarissa* are LGPL, but this is not mentioned in debian/copyright. The rest of ajaxterm is public domain In the smoketests directory, i find: openwrt-x86-ext2.image openwrt-x86-vmlinuz one seems to be a kernel, the other an ext2 image with a kernel and grub. The licenses for these are not mentioned in debian/copyright, and I do not find source for these The license and copyright notice from nova/virt/xenapi/fake.py does not appear contrib/boto_v6 is under a MIT like license that is not mentioned in debian/copyright, nor are its copyright holders bin/nova-manage carries a BSD license which is not mentioned in debian/copyright, nor are its copyright holders bye, stew ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Fwd: Bug#631834: python-novaclient and simh: error when trying to install together
On 06/28/2011 05:18 PM, Thierry Carrez wrote: > Thomas Goirand wrote: >> Less fun guys. Here's what an upload to SID revealed (see below). >> >> I'll conflict the 2 packages, I guess the issue is in Ubuntu as well. > > Indeed... Created LP: #802882 to track that. Seems that this issue solved itself, as the latest upload of simh in Debian fixes the conflicting files. I don't know the status in Ubuntu. Has the "st" issue of swift conflicting with suckless-tools been addressed already? Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Ubuntu Cloud Days
On 07/06/2011 08:33 PM, Ahmed Kamal wrote: > On 07/05/2011 10:22 PM, Soren Hansen wrote: >> 2011/7/5 Thierry Carrez: I see that the Ubuntu Cloud Days are coming up July 25-26 via an IRC channel (https://wiki.ubuntu.com/UbuntuCloudDays). I received a message from Ahmed Kamal (k...@ubuntu.com) about this event: [...] ** Is anyone from OpenStack going to present or is planning to? I want to make sure that we are represented at this event. Thanks, >>> I should be presenting something at this online event, though I'm not >>> sure yet what exactly :) >> Me too. :) >> > Thanks a lot Thierry and Soren! It's a pleasure to have you at UCD. May > I ask you to please pick your preferred time slot at > https://wiki.ubuntu.com/UbuntuCloudDays/Timetable as soon as possible. > If unsure what you'll be presenting, just write TBD. Thanks May I ask why you decided to make an Ubuntu event in the middle of Debconf11? Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Fwd: Bug#631834: python-novaclient and simh: error when trying to install together
Less fun guys. Here's what an upload to SID revealed (see below). I'll conflict the 2 packages, I guess the issue is in Ubuntu as well. Thomas Original Message Subject: Bug#631834: python-novaclient and simh: error when trying to install together Resent-Date: Mon, 27 Jun 2011 16:18:02 + Resent-From: Ralf Treinen Resent-To: debian-bugs-d...@lists.debian.org Resent-CC: Vince Mulhollon , Thomas Goirand Date: Mon, 27 Jun 2011 17:50:15 +0200 From: Ralf Treinen Reply-To: Ralf Treinen , 631...@bugs.debian.org To: sub...@bugs.debian.org Package: simh,python-novaclient Version: simh/3.8.1-2 Version: python-novaclient/2.4-2 Severity: serious User: trei...@debian.org Usertags: edos-file-overwrite Date: 2011-06-27 Architecture: amd64 Distribution: sid Hi, automatic installation tests of packages that share a file and at the same time do not conflict by their package dependency relationships has detected the following problem: WARNING: The following packages cannot be authenticated! mime-support python2.6-minimal libdb4.8 libexpat1 python2.6 python-minimal python python-support python-argparse python-httplib2 python-pkg-resources python-prettytable python-novaclient simh Authentication warning overridden. Can not write log, openpty() failed (/dev/pts not mounted?) Selecting previously deselected package mime-support. (Reading database ... 9217 files and directories currently installed.) Unpacking mime-support (from .../mime-support_3.51-1_all.deb) ... Selecting previously deselected package python2.6-minimal. Unpacking python2.6-minimal (from .../python2.6-minimal_2.6.7-1_amd64.deb) ... Selecting previously deselected package libdb4.8. Unpacking libdb4.8 (from .../libdb4.8_4.8.30-8_amd64.deb) ... Selecting previously deselected package libexpat1. Unpacking libexpat1 (from .../libexpat1_2.0.1-7_amd64.deb) ... Selecting previously deselected package python2.6. Unpacking python2.6 (from .../python2.6_2.6.7-1_amd64.deb) ... Selecting previously deselected package python-minimal. Unpacking python-minimal (from .../python-minimal_2.6.6-14_all.deb) ... Selecting previously deselected package python. Unpacking python (from .../python_2.6.6-14_all.deb) ... Selecting previously deselected package python-support. Unpacking python-support (from .../python-support_1.0.13_all.deb) ... Selecting previously deselected package python-argparse. Unpacking python-argparse (from .../python-argparse_1.1-1_all.deb) ... Selecting previously deselected package python-httplib2. Unpacking python-httplib2 (from .../python-httplib2_0.7.0-1_all.deb) ... Selecting previously deselected package python-pkg-resources. Unpacking python-pkg-resources (from .../python-pkg-resources_0.6.16-1_all.deb) ... Selecting previously deselected package python-prettytable. Unpacking python-prettytable (from .../python-prettytable_0.5-1_all.deb) ... Selecting previously deselected package python-novaclient. Unpacking python-novaclient (from .../python-novaclient_2.4-2_all.deb) ... Selecting previously deselected package simh. Unpacking simh (from .../simh_3.8.1-2_amd64.deb) ... dpkg: error processing /var/cache/apt/archives/simh_3.8.1-2_amd64.deb (--unpack): trying to overwrite '/usr/share/man/man1/nova.1.gz', which is also in package python-novaclient 2.4-2 configured to not write apport reports dpkg-deb: error: subprocess paste was killed by signal (Broken pipe) Processing triggers for man-db ... Errors were encountered while processing: /var/cache/apt/archives/simh_3.8.1-2_amd64.deb E: Sub-process /usr/bin/dpkg returned an error code (1) This is a serious bug as it makes installation fail, and violates sections 7.6.1 and 10.1 of the policy. An optimal solution would consist in only one of the packages installing that file, and renaming or removing the file in the other package. Depending on the circumstances you might also consider Replace relations or file diversions. If the conflicting situation cannot be resolved then, as a last resort, the two packages have to declare a mutual Conflict. Please take into account that Replaces, Conflicts and diversions should only be used when packages provide different implementations for the same functionality. Here is a list of files that are known to be shared by both packages (according to the Contents file for sid/amd64, which may be slightly out of sync): /usr/bin/nova /usr/share/man/man1/nova.1.gz This bug is assigned to both packages. If you, the maintainers of the two packages in question, have agreed on which of the packages will resolve the problem please reassign the bug to that package. You may also register in the BTS that the other package is affected by the bug. -Ralf. PS: for more information about the detection of file overwrite errors of this kind see http://edos.debian.net/file-overwrites/. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net
Re: [Openstack] Bug#631830: /etc/sudoers.d/nova_sudoers uses wrong path of brctl
On 06/27/2011 11:29 PM, Martin Zobel-Helas wrote: > Package: nova-common > Version: 2011.2-1 > Severity: important > Tags: patch > > Hi Thomas, > > i played around with nova i bit today, and found a small error, which > took me a while to find: > > --- nova_sudoers2011-06-27 17:26:14.0 +0200 > +++ nova_sudoers.new2011-06-27 17:27:30.0 +0200 > @@ -24,7 +24,7 @@ >/sbin/vgcreate, \ >/usr/bin/virsh, \ >/usr/bin/qemu-nbd,\ > - /usr/sbin/brctl, \ > + /sbin/brctl, \ >/usr/sbin/vblade-persist, \ >/sbin/pvcreate, \ >/sbin/aoe-discover, \ Is this a difference between Ubuntu and Debian, or is it a bug in Cactus? Cheers, Thomas Goirand (zigo) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Conflicting st binary name
- Original message - > On Fri, Jun 10, 2011 at 2:50 AM, Thomas Goirand > wrote: > We decided the overlap was minimal > and to just conflict on the issue. > See discussion towards the bottom of this bug: > https://bugzilla.redhat.com/show_bug.cgi?id=693363 > > Of course it would be simpler to rename. Conflicting isn't a fix, it's declaring a breakage. Sooner or later, there will be the issue in Ubuntu, when that window manager will get in. So yes, I do beleive we should rename, if it has only small consequences. Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Conflicting st binary name
Hi, There's a bug report in the Debian BTS [1] against Nova in SID concerning the "st" binary shipped by Swift. Shall we consider renaming the binary "st" to something else? I know that a window manager has nothing to do with us, but there might be corner cases where it might be really annoying. Thomas [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=629998 ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Uploaded Openstack Cactus in SID
On 06/09/2011 02:22 AM, Soren Hansen wrote: > Perhaps you missed it, but there was a thread on this list earlier a > couple of days ago about setting up an > openstack-packag...@lists.ubuntu.com that would allow non-subscribers > to post there. How does that sound? Yes, I missed it. That'd be really cool indeed. Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Uploaded Openstack Cactus in SID
Hi, FYI, I have uploaded Openstack to SID today. Both Swift, Glance and Nova are in. While the ftp-masters checked for the debian/copyright, they've found out that something was missing in it. The folder contrib/boto_v6/ isn't mentioned in the copyright file. So please, (Soren, or anyone), add the following: Files: contrib/boto_v6/* Copyright: (c) 2006-2010, Mitch Garnaat http://garnaat.org/ (c) 2010, Eucalyptus Systems, Inc. License: BSD-Style Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. I know I should normally go through bzr, merge prop., etc, but this is quite trivial, and I don't think anyone can even disagree that this is a needed addition to the copyright file. As for the packages in Debian SID, please test them and report any issue. I'll try to make a package for the latest version of Swift, but I don't need to be as fast as the Ubuntu maintainer. Also, if any patches were to be backported to Openstack in Ubuntu, let me know, and I'll happily amend the SID packages. This upload was made on my own name on the maintainer field, because I still didn't get a reply for having the openstack@lists.launchpad.net as open post, or having an Alioth mailing list to collect bug reports. Thomas Goirand (zigo) P.S: Special thanks to the pkg-python-modules who quickly worked on python-eventlet and the python + OpenSSL issue, so that upload was finally possible. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Upload of Swift & Glance in Debian Experimental
On 05/30/2011 03:37 PM, Thierry Carrez wrote: > Would this "Maintainer" field be the only delta between Ubuntu and > Debian packages ? If yes, it might be worth to try to converge somewhere > else... Yes, because I sent all my patches to Soren, and he merged it (after the Cactus release though). But the goal really IS to have the delta as small as possible. However, you are missing the point. My point was to have bug reports sent to this list, and share maintainership in Debian with others. Currently, it's simply not possible, because bug reports wouldn't reach this list at all. On 05/31/2011 12:41 AM, Chuck Short wrote: > Hi, > > As much as I would to keep the openstack packaging diff between Ubuntu > and Debian to a minimum, we are definitely going to be making changes > to the debian packaging for Ubuntu and creating a delta between the > two packages. Well, currently isn't it the opposite way? Eg: me trying to maintain the Debian package out of the Ubuntu one, and trying to keep the delta as small as possible? > There are several reasons why we will be doing this: > > - Openstack promotion to main - in oneiric we are going to be promoting > openstack to main. Based on the feedback we receive from the main > inclusion team we are going to make some changes to the debian > packaging. See above. It's opposite way. You're going to use the Ubuntu packaging proposed by Soren, and I'll derive from that in Debian. > - Stabilization: In natty we did a weekly snapshot of nova so that > users can test out features on an ongoing basis. It also allowed us > to tell Soren and Thierry that program X is missing in the sudoers > file. If we sync from Debian we will loose this feature that our > users and developers in Ubuntu have used in the past. Nobody is proposing to sync from Debian (well, unless the main platform for Openstack becomes Debian, but that's another debate). > - Feature support: For Ubuntu Cloud we are still determining which > features that we want to support. An example of this if we want to > support Xen as well as LXC or KVM. This might or might not cause a > diff in the debian packaging. > > With that being said I would be happy to work with the Debian > Openstack team, and contributing Ubuntu patches back into Debian > when it makes sense for Debian. If you have any questions please > let me know. What me (and maybe Soren as well?) are trying to do here, is to have a single development branch, rather than fork of the packaging. As said above, my remarks are just for Debian bug reports: I wanted them to go in this list, but it's not possible currently, unless this list becomes an open post one, which was my request... Nothing more, nothing less! So comments about delta of the packaging aren't that much relevant... Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Upload of Swift & Glance in Debian Experimental
Hi Luca, thanks for this prompt reply. - Original message - > Hi Thomas! > > Il 28/05/2011 09:00, Thomas Goirand ha scritto: > > I previously uploaded Swift to Experimental, but the email I used was > > one in Ubuntu launchpad, which unfortunately is a "subscriber only > > post" type of list (eg openstack@lists.launchpad.net). > > Those lists trigger a bounce, and we don't want contact addresses which > generate them, so... > > > It seems that Swift got rejected, but I don't know for what reason. > > Would you be kind enough to let me know why? > > ... it was rejected, it was asked to reupload with another maintainer > address. Package was otherwise OK, IIRC. That's what I thought, but I had no way to be sure of it without asking. It was a wise decision. :) > > Of course, for further upload, I wont do the same mistake. Please bare > > with me, as Glance, which I also uploaded, has the same issue. Note > > that Glance has a build-depends on python-swift, so it can't be > > uploaded before Swift. > > Yes, we're holding glance for a new swift upload. You should consider > moving away from openstack@lists.launchpad.net for glance too, by > uploading 2011.2-2 or, if you prefer not wasting a revision, reupload as > 2011.2-1 after we rejected the old one. The only issue is that I don't want to use my email address as maintainer, because I am hoping to have others join a team of maintainers, and since I asked for an Alioth package to have a mailing list the day before the maintenance, I am guessing that my request for a new Alioth list/project has been lost... I'll wait a day or 2 more and ask again for a new Alioth project, then upload again. Best would be to reject Glance, so the debian/changelog diff with Ubuntu is kept to minimum (I'm trying to work as much as possible with upstream which is people from Ubuntu). Thanks. Cheers, Thomas (from my phone) P.S to Openstackers: I really would have like to avoid creating a separate list for the Debian pkgs of Openstack, especially because I will have to have a diff in the debian/control (maintainer field will have to be different) but as you see, Launchpad prevents me from doing so. Any solution from Canonical/Ubuntu would be welcome... ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova not building on SID with python2.7
- Original message - > So, first you need to get a fresh snapshot of pyopenssl (or backport > the patch for the removed SSLv2 stuff to a released version) built. > Then you need to get eventlet built against this new pyopenssl snapshot. > Then you can build Nova with Python 2.7. This doesn't work like this in Debian: I do not own the pyopenssl package, so I need to wait until the pkg-python-modules team does it. I can send a patch against the package, and if it takes more than a week or 2 without an upload, then I can NMU (non maintainer upload) in the delayed queue. But I wont just fix like that, that would be considered as rude to not work with current maintainers. I suppose you (Soren) know already how it works in Debian, but not everyone might, and I think it is best to make sure that everyone understand why I'm not uploading Nova to Debian right now. Thomas (from my phone) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova not building on SID with python2.7
There we go, we got the answer. Now, most likely, Ubuntu will be affected. Let's hope the transition is smoother than in Debian. Of course, this is currently a blocker for me to upload Nova in SID (Swift and Glance have already been uploaded to Experimental, it's just waiting for FTP-Masters approval). So the only way currently is to use my (personal) Squeeze Debian repository: deb http://ftparchive.gplhost.com/debian openstack main Hoping it wont take too long to get fixed... Thomas Original Message Subject: Re: [Python-modules-team] [Openstack] Nova not building on SID with python2.7 Date: Thu, 26 May 2011 09:16:29 +0200 From: Sandro Tosi To: Thomas Goirand CC: python-modules-t...@lists.alioth.debian.org On Thu, May 26, 2011 at 09:06, Thomas Goirand wrote: > == > ERROR: Failure: ImportError > (/usr/lib/pymodules/python2.7/OpenSSL/SSL.so: undefined symbol: > SSLv2_method) > -- This is because OpenSSL 1.0.0 removed SSLv2 support; it will be solved by pyopenssl upstream, sooner or later. -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Nova not building on SID with python2.7
On 05/20/2011 06:15 AM, Soren Hansen wrote: > 2011/5/19 Thomas Goirand : >> Since SID is using python2.7, there's loads of errors, and building Nova >> simply doesn't work. > > Can you be more specific? Ubuntu has been on Python 2.7 since Natty, > so it most definitely should work. Below is just an example. It does that all the time for the clean, build, install, etc. targets of debian/rules. debian/rules override_dh_auto_clean make[1]: Entering directory `/home/zigo/src/build/nova/nova-2011.2' dh_auto_clean Traceback (most recent call last): File "setup.py", line 37, in from nova.utils import parse_mailmap, str_dict_replace File "/home/zigo/src/build/nova/nova-2011.2/nova/utils.py", line 42, in from eventlet import event ImportError: No module named eventlet dh_auto_clean: python2.7 setup.py clean -a returned exit code 1 >> Even the debian/rules clean target fails, not finding the Eventlet python >> module. > > Eventlet probably just needs a no-change rebuild to pick up the new > python versions in the archive. Bug the maintainers (*cough* Monty > *cough*). Maybe. But the issue is that I tried to rebuild it, and it doesn't build anymore. It's well documented here already by Lucas Nussbaum: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=625137 Because of this, I've put the python-modules-team as Cc:, hoping that the issue will get a higher priority, knowing that it is blocking others. I believe that a patch to the package would help speed-up solving the issue. Note that after rebuilding pyopenssl-0.10, it seems that the error is not the same as what has been reported: == ERROR: Failure: ImportError (/usr/lib/pymodules/python2.7/OpenSSL/SSL.so: undefined symbol: SSLv2_method) -- Traceback (most recent call last): File "/usr/lib/pymodules/python2.7/nose/loader.py", line 390, in loadTestsFromName addr.filename, addr.module) File "/usr/lib/pymodules/python2.7/nose/importer.py", line 39, in importFromPath return self.importFromDir(dir_path, fqname) File "/usr/lib/pymodules/python2.7/nose/importer.py", line 86, in importFromDir mod = load_module(part_fqname, fh, filename, desc) File "/home/zigo/src/rebuild/python-eventlet-0.9.14/eventlet/green/OpenSSL/__init__.py", line 1, in import rand, crypto, SSL, tsafe File "/home/zigo/src/rebuild/python-eventlet-0.9.14/eventlet/green/OpenSSL/rand.py", line 1, in from OpenSSL.rand import * File "/usr/lib/pymodules/python2.7/OpenSSL/__init__.py", line 11, in import rand, crypto, SSL, tsafe ImportError: /usr/lib/pymodules/python2.7/OpenSSL/SSL.so: undefined symbol: SSLv2_method Cheers, Thomas Goirand (zigo) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
[Openstack] Nova not building on SID with python2.7
Hi, Since SID is using python2.7, there's loads of errors, and building Nova simply doesn't work. Even the debian/rules clean target fails, not finding the Eventlet python module. I had to hack a "python2.6 setup.py clean -a" to make it work. And that is only an example, there's lots of hacks like that I had to do to build the Debian package in SID. It seems to only be an issue with building and setup.py, but I'm not so sure of it. Is that due to the transition to python 2.7 not finished in SID? If that is the case, I don't get why only Nova is affected, and not Swift and Glance. What are your thoughts? Thomas Goirand (zigo) P.S: I have uploaded Swift, Glance to Debian experimental today, but not Nova yet, due to this issue (it doesn't build...) ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Reminder: OpenStack team meeting - 21:00 UTC
On 05/10/2011 08:32 PM, Thierry Carrez wrote: > We've been through that before... Sorry then. > The current time was picked to > accomodate from Japan to Western Europe, which represents about 95% of > our developers. > > We /could/ do rolling meeting times, but PTLs and release manager are > necessary in that meeting, so we still need to accomodate from > California to Western Europe, which doesn't add so many options... And > the benefit should outweigh the resulting confusion. Thanks for the explanations. Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Reminder: OpenStack team meeting - 21:00 UTC
On 05/10/2011 04:05 PM, Thierry Carrez wrote: > Hello everyone, > > Our weekly team meeting will take place at 21:00 UTC this Tuesday in > #openstack-meeting on IRC. Each weeks, it's at that time. Here, that makes it 5am, and I don't really wana wake up just to chat on IRC, but still would like to be there, especially because I couldn't attend the design summit, and that I'm currently trying to get up-to-speed to what's going on. Would it be possible to not schedule it always at the same time? If that's only an issue for me, and that it's perfect time for others, then I'd understand to not change the time though... But as much as I can tell, even in California, that's 2pm, which is quite late already. Cheers, Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] API for remotely controlling nova-manage
On 04/18/2011 02:30 AM, ksan...@doubleclix.net wrote: > Couple of points: > a) We do need a North-facing interface that supports headless operation incl > billing, reporting and so forth > b) IMHO, REST APIs are better than SOAP interfaces > c) Also JSON might be a good choice > d) There are already other cloud APIs available like the vCloud, OCCI et al. > OCCI might fit your requirements. We really do not want to yet another cloud > API > with it's own programming model, if possible. > Cheers > I've found the OCCI specs (provided that it isn't the Oregon Coast Culinary Institute that you were talking about:) ). What I found is mostly unreadable empty specs, and not adapted to the practical needs I described, which is simply to grant access to user accounts and Nova projects. As for vCloud, this seems to be quite proprietary and bound to VMware. So, could you be a bit more specific of what you think should be implemented? I may need to re-read the OCCI PDFs, if you are sure this address the need I expressed. Thomas ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
