Re: [Openstack] development document: how to write a filter module to swift
Thanks for that document !We'll see how/ where integrate it into Swift documentation.Regards,Razique Nuage Co - Razique Mahrouarazique.mahr...@gmail.com Le 30 nov. 2011 à 00:29, pf shineyear a écrit :http://wiki.openstack.org/development/swift/filterit's not perfect but i think this can help some people at the beginning. if someone can help me to move this document toSwift Developer Documentation i will say thank you. ___Mailing list: https://launchpad.net/~openstackPost to : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore 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] Providing packages for stable releases of OpenStack
Hi everyone, Yesterday, Vish and Monty raised the need for the OpenStack project to provide a maintained set of packages for stable versions of OpenStack on yet-unsupported versions of distributions. TL;DR summary: The resources needed to do that properly are bigger than you think (and doing that will alienate some distro packaging resources), so we'll either do a terrible job at it, or lose focus on the development release. If there is a need, it should be done as an alternate distribution, not inside the OpenStack project. Long version: First let me agree on the need. A very good, very stable distribution of OpenStack on stable versions of distributions (a.k.a. stable/diablo on Lucid) is definitely needed. The 2011.3 release PPA does not provide that and bears false expectations, so it should die a painful death, and quickly. That doesn't mean we, as an upstream project, should necessarily enter the distribution business to cure the deficiencies of their model. I think distributions are separate projects with a separate skillset -- if we try to do it we'll dilute our effort *and* alienate the existing distributions. Those should compete between them, not with us. Providing a production-ready, maintained distribution channel is more than just building packages for Lucid, unfortunately. That is good for test packages (like our trunk PPA). A production channel needs to be always installable and upgradeable (unlike our trunk PPAs that are routinely broken). Any backport in there needs to be watched for security updates. You commit to maintain it for a given length in time. Our resources are limited and the skillset is particular. Last month Monty was arguing we should not provide packages as project deliverables at all, for the precise reason that we could not gate on packaging with only a few people with that skill (he apparently changed his mind ?). Resources are limited, so where do we stop ? Where does user convenience end ? What distributions and series should we support ? What versions of OpenStack ? How long do we support them ? Do we support Diablo on OpenSUSE 10.1 for 5 years ? For every combination added, the resources are spread even thinner. We used to limit the scope of the OpenStack project to producing code, and letting downstream distributions do what they do best, i.e. integrating and distributing. We only provided test/evaluation PPAs for user convenience, since the cost/benefit ratio was reasonable. Everyone was at his place, happy and collaborating on packaging. If we do production PPAs, we create competition and conflicts. Monty says I do not care about conflicts with distros -- but that's a sure way of losing distro packagers help. For example, the current packaging team working on Ubuntu packages is about 6 people, 4 of which happen to work for the distro. My point is that if there is such a need for OpenStack on Lucid, then a new distribution (99% based on Lucid) will address that. It does not have to be OpenStack itself. My fear is that we would do a very bad job at this, and it would reflect on the project as a whole. Branding ours official won't make it better than unofficial ones, but will alienate distros. I prefer this to be done separately: that ensures that OpenStack remains focused on code and keeps collaborating with every distro on an equal footing. And if you're so interested by this, you could be in both projects. A last remark: we are already doing this. And we are not being successful with it. Swift last release PPA [1] provides a decent production channel, updated roughly every month, for running stable Swift on stable Ubuntu. If it was a wild success and everyone was collaborating on packaging work for it... it could prove me wrong. But for some reason, nobody (including Rackspace) is using that. They are using their own packaging and their own repositories. Why ? And what makes you think that generalizing that idea to every project would suddenly make it work ? [1] https://launchpad.net/~swift-core/+archive/release -- Thierry Carrez (ttx) Release Manager, OpenStack ___ 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] Cloud Computing StackExchange site proposal
I think that the main problem is that we have many places to search for information, but a few people giving helpful answers. A lot of newcomers join the forum but particular setups problems sometimes leads to packaging problems, bugs and we as moderators have to redirect the user to re-post his problem on launchpad, starting over. I think that we have to split packaging and developing questions vs implementations doubts, concept misunderstanding, etc. The main reason of people dropping Openstack on pre-production or testing environments its cause they aren't even mid experienced python developers, and they cant find a solution in a matter of time that they experience with the product leaves them a good taste to invest more time trying to implement it later. I read a lot of that's and end-user question, etc don't you guys forget that actually the end-users are Companies sysadmins maybe trying to deliver an real IaaS based on an Opensource product like Openstack. We have a huge Openstack implementation using almost every core product, and our environment is growing everyday faster than we expected, but when we approach to implement a new service, or integrate for example Keystone with Swift or Nova, we fought for days, fixing a lot of code and ended-up on a packaging problem, cloning the Cloudbuilders repo were the code was already fixed. That sensation to cross up docs, and blogs, and examples, and launchap question to get just to a test env, ends on companies leaving Openstack as a possible solution. We're pretty comfortable at python so we love to face issues like this, but imagine a sysadmin reading the docs, following line but line ending up with a non-working environment asking himself why he did wrong, and maybe a magic oh you have to chmod all this folder was missing on the docs. docs.openstack.org must be the bible for users that want to try openstack out, the forums and the IRC to help final users out, and launchpad for issuing bugs, we need to work on getting an updated documentation, getting a my instances get stucked on scheduling or i cannot ssh into instances should not exist with a clean and clear doc. We see a lot of people stuck in a single node installation, or on his devstack setup thinking about going back with they 3 vmware esxis nodes to create they VMs, and they never experience the real benefits of running a true IaaS all the way. Leaving the people googling or blogging up a few minutes after their setup is not good at all for the platform, we try to write up very detailed installation posts on the forums that are very usefull for the users, with tips and common issues that we faced installing the product. We're helping out everyday on the IRC and the forums to reduce the traffic o users hitting common issues, and of course Anne you can count on us to improve the docs, so that sysadmins loose their fears and feeling of this being too greeny to production and surprise themselves like we do everyday after 5 months later running all of our applications and our productive infrastructure over Openstack ( +1000 phy +6000 instances ) Sorry for the long writing . My two cents! Regards Leandro Reox Sr. Infrastructure Engineer at mercadolibre.com On Tue, Nov 29, 2011 at 10:37 PM, Lloyd Dewolf lloydost...@gmail.comwrote: On Tue, Nov 29, 2011 at 11:16 AM, Stefano Maffulli stef...@openstack.org wrote: On Tue, 2011-11-29 at 10:10 -0800, Lloyd Dewolf wrote: Where do I find this previous discussion? around here: https://lists.launchpad.net/openstack/msg02169.html What do you think of the requirements we're gathering for the QA system? I'd like your opinion on that as we move on. Thanks Stefano. I really like everyone reframing the discussion to figure out what our needs are as opposed to ... shiny! I do think stackexchange (SE) is miles [1] ahead and the only system that will meet the majority of our requirements. If we can get our own Area51 then it's by far the best immediate solution. I spoke to a friend at Area51, and he suggested we might have different results if we tried again. So I feel like this is on the table if we want to pursue. Of course, having very active SE participants (high reputation) put the proposal forward and committing to it carries a lot of weight. My reputation [2] is weak today, but I'm sure myself and others could ramp up the levels quickly over the next few months. Cheers, Lloyd -- 1. See I'm getting used to United States customary units, http://en.wikipedia.org/wiki/Customary_units 2. http://stackexchange.com/users/25765?tab=accounts ___ 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
Re: [Openstack] Providing packages for stable releases of OpenStack
On Wed, Nov 30 2011, Thierry Carrez wrote: Hi Thierry, TL;DR summary: The resources needed to do that properly are bigger than you think (and doing that will alienate some distro packaging resources), so we'll either do a terrible job at it, or lose focus on the development release. If there is a need, it should be done as an alternate distribution, not inside the OpenStack project. With my Debian developer and Debian OpenStack packaging team hat on, I must say that you're totally right about this. All upstreams projects trying to do packaging does a terrible job at it, because that's not something you can improvise. It's more important to understand the needs of the packagers (e.g. a proper setup.py) than to try to do their jobs worse. -- Julien Danjou // eNovance http://enovance.com // ✉ julien.dan...@enovance.com ☎ +33 1 49 70 99 81 ___ 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] Providing packages for stable releases of OpenStack
On Wed, 2011-11-30 at 10:32 +0100, Thierry Carrez wrote: TL;DR summary: The resources needed to do that properly are bigger than you think (and doing that will alienate some distro packaging resources), so we'll either do a terrible job at it, or lose focus on the development release. If there is a need, it should be done as an alternate distribution, not inside the OpenStack project. I think the conclusion is fair, especially if you consider that for the OpenStack project to convincingly do binary distributions we would also need to support a wider range distros/platforms. But if a thriving community effort around doing producing binary distributions of OpenStack for multiple platforms did happen to develop, I think it would be valid to leave open the possibility of that effort joining the project. That doesn't look terribly likely right now, though. Cheers, Mark. ___ 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] Australian OpenStack User Group meet up Sydney
Hello all, Not sure if this is the right place to post this, I apologise in advance if it isn't. Australian OpenStack User Group is meeting for the first time in Sydney and I would like to extend an invitation to all who may wish to attend. Details follow: When: Tuesday, December 13, 2011 6:30 PM to 11.30pm Where: Harbour View Hotel 18 Lower Fort Rd, The Rocks Sydney Sydney RSVP limit: 60 Yes RSVPs, If you plan to attend, please take a moment to RSVP. (You can RSVP No or Yes.) For more details, see the full listing: http://aosug.openstack.org.au/events/40240882/ Cheers, Kavit Kavit Munshi Solutions Director Aptira Pty Ltd 1800 APTIRA http://aptira.com attachment: image001.jpg___ 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] Lloyd Learning Docs website content processes
Lloyd Dewolf wrote: 2. Lloyd will log Thierry ttx Carrez's solid openstack.org/security content from http://etherpad.openstack.org/8hWNQwkWf9 to http://launchpad.net/openstack-manuals , if it is not already there. He will do a copyedit to the etherpad, and also upload his revision to openstack-manuals. We'll take it from there based on the process Anne is updating to the wiki. Note that the content was pushed to www.openstack.org webmaster for publication, without much result yet (the idea was to quickly replace nothing with something, and then improve incrementally). It would be great if we could have a more dynamic way to review/update the main website content (in the same way we control the docs site contents): it could prove useful in further revisions. -- Thierry Carrez (ttx) Release Manager, OpenStack ___ 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] Proposal for Mark McLoughlin to join nova-core
2011/11/29 Vishvananda Ishaya vishvana...@gmail.com: Mark is maintaining openstack for Fedora and has made some excellent contributions to nova. He has also been very prolific with reviews lately. Lets add him to core and make his reviews count towards potential merges! I'd be delighted to have Mark on the core team. +1 -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ 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] Providing packages for stable releases of OpenStack
I think there are two distinct use cases here. To me, the PPA's have always been a QA tool. I wanted people willing to help test OpenStack to be able to do so with as little effort as possible. Building packages per-commit gave us that. It seems incredibly counterintuitive to me that someone who wants to help us verify the stable branches need to jump through more hoops to do so. IMO we should be as least as concerned about the quality of stable updates as anything else. This is why I think we should be offering a PPA with per-commit builds from the stable branch(es). This is completely different from a production PPA. I wouldn't dream of pointing people to the above mentioned PPA for their production environment. If someone wants to offer this outside of (but perhaps in cooperation with) OpenStack, that'd be great. I'd be delighted to see companies taking this on and offering a supported OpenStack distribution, but I don't think this is our job for pretty much all the same reasons Thierry outlines. I propose we start building packages from the stable branches and put them in an appropriately named/labeled PPA, such as nova-core/diablo-qa or nova-core/diablo-not-for-production (or perhaps under openstack-stable-maint). At the same time, I'd like to propose that we limit ourselves to fewer supported versions of Ubuntu (for trunk builds as well as these new, stable branch builds). Specifically: * Most recent LTS * Most recent release (which may or may not be an LTS) * Current development release LTS's would go out of support when the subsequent LTS's first point release is released. Non-LTS's would go out of support a month after the subsequent release is out. This means that right now, we'd build: * Lucid (until 12.04.1 is released (July 2012)) * Oneiric (until May 2012) * Precise (until (probably) July 2014) This gives people ample opportunity to upgrade to the next release and at the same time reduces the amount of releases we need to worry about significantly. I think we'd get a valuable QA tool back and we'd reduce the burden of maintaining the per-commit packages by having fewer distro versions to worry about. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ 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] How to using keystone with ldap
Maybe this link can help you out : http://mirantis.blogspot.com/2011/08/ldap-identity-store-for-openstack.html Regards 2011/11/30 DeadSun mwjpi...@gmail.com Now I according to keystone/test/etc/ldap.conf.template to set ldap configuration in my keystone.conf But I have no idea that wich dn in ldap keystone used and there is no dn in keystone.ldif . How to set it? Anyone using keystone with ldap can help me? -- 非淡薄无以明志，非宁静无以致远 ___ 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] Providing packages for stable releases of OpenStack
Soren Hansen wrote: I propose we start building packages from the stable branches and put them in an appropriately named/labeled PPA, such as nova-core/diablo-qa or nova-core/diablo-not-for-production (or perhaps under openstack-stable-maint). [...] That would work (and inside the current project). Just two remarks: * Expectations are difficult to control. Even if we use an intimidating name, some people will still expect this to provide more than it actually does. For example, people kept thinking that the 2011.3 release PPA would be updated, while it explicitly said it wouldn't. * I don't think that's what Vish and Monty are after -- they specifically mentioned the lack of a production-ready distribution channel as the problem that we needed to solve -- Thierry Carrez (ttx) Release Manager, OpenStack ___ 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] Providing packages for stable releases of OpenStack
On Wed, 2011-11-30 at 13:07 +0100, Soren Hansen wrote: I think there are two distinct use cases here. Totally agree. We need to make it as easy as possible for people to test upstream git branches and releases. To me, the PPA's have always been a QA tool. I wanted people willing to help test OpenStack to be able to do so with as little effort as possible. Building packages per-commit gave us that. It seems incredibly counterintuitive to me that someone who wants to help us verify the stable branches need to jump through more hoops to do so. IMO we should be as least as concerned about the quality of stable updates as anything else. This is why I think we should be offering a PPA with per-commit builds from the stable branch(es). This is completely different from a production PPA. I wouldn't dream of pointing people to the above mentioned PPA for their production environment. If someone wants to offer this outside of (but perhaps in cooperation with) OpenStack, that'd be great. I'd be delighted to see companies taking this on and offering a supported OpenStack distribution, but I don't think this is our job for pretty much all the same reasons Thierry outlines. I propose we start building packages from the stable branches and put them in an appropriately named/labeled PPA, such as nova-core/diablo-qa or nova-core/diablo-not-for-production (or perhaps under openstack-stable-maint). I'm not convinced that distribution specific packaging is the best way to go about this. I want Fedora users to be able to test out, and get involved with, upstream as easily as Ubuntu users are. Same for other distros. The thought of getting into the game of maintaining this upstream packaging for multiple distros, and e.g. having to make sure any dependencies are packaged for these distros ... ugh. I don't have anything concrete to offer as an alternative, but I'd love to see something like devstack that runs either from git or tarballs and supports multiple distributions. Or maybe the answer is for OpenStack to publish everything to pypi and something like devstack which uses a virtualenv. There's also the likes of jhbuild, GARGNOME, minuteman and surely more - perhaps we can take a leaf out of their books? But until something like this exists, I guess you're right - throwing out the per-commit PPAs is a backward step. However, I think Thierry's point was about PPAs containing packaged releases (e.g. 2011.3.1) Cheers, Mark. ___ 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] Providing packages for stable releases of OpenStack
2011/11/30 Thierry Carrez thie...@openstack.org: Soren Hansen wrote: I propose we start building packages from the stable branches and put them in an appropriately named/labeled PPA, such as nova-core/diablo-qa or nova-core/diablo-not-for-production (or perhaps under openstack-stable-maint). [...] That would work (and inside the current project). Just two remarks: * Expectations are difficult to control. Even if we use an intimidating name, some people will still expect this to provide more than it actually does. For example, people kept thinking that the 2011.3 release PPA would be updated, while it explicitly said it wouldn't. The reason I want the PPA name to be scary looking is exactly because of the lesson learned from those PPA's. It's easy to miss the disclaimers on Launchpad (and if you happen to find the PPA info somewhere else, there might be no disclaimer at all!). The PPA name is the most obvious place to put this. Only if you're running someone else's script to enable it will you never see it. Some people will still miss it, but I think it's the best we can do. * I don't think that's what Vish and Monty are after -- they specifically mentioned the lack of a production-ready distribution channel as the problem that we needed to solve Right. I agree we shouldn't do that. Someone else should. But I don't want that to hold back the creation of the per-commit PPA for diablo/stable which I find important for QA purposes. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ 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] Providing packages for stable releases of OpenStack
Hi, TL;DR summary: The resources needed to do that properly are bigger than you think (and doing that will alienate some distro packaging resources), so we'll either do a terrible job at it, or lose focus on the development release. If there is a need, it should be done as an alternate distribution, not inside the OpenStack project. As Julien Danjou wrote, we ( OpenStack Debian GNU/Linux packagers [1]) discussed your mail. We are comfortable with the idea that OpenStack focuses on development and that packaging is left to the packagers involved in each distribution. Packaging related patches from Julien Danjou were recently accepted upstream (https://review.openstack.org/#dashboard,1669). This is the kind of cooperation that makes it possible to maintain packages matching the Debian GNU/Linux quality standard. We are confident in our ability to provide stable packages in the future. OpenStack packaging is not an easy task. It currently fits nicely in Debian GNU/Linux. However, as it evolves towards a system widely used in production, it will face new challenges and the communities working on packaging for each distribution will provide valuable input to developers. Creating a packaging team with representatives for each distribution and electing someone to represent them in the Policy Board could achieve this. Cheers [1] PKG OpenStack page : https://alioth.debian.org/projects/openstack/and corresponding packages: http://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org http://qa.debian.org/developer.php?packages=nova http://qa.debian.org/developer.php?packages=glance attachment: loic.vcf signature.asc Description: OpenPGP digital signature ___ 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] Providing packages for stable releases of OpenStack
2011/11/30 Mark McLoughlin mar...@redhat.com: On Wed, 2011-11-30 at 13:07 +0100, Soren Hansen wrote: I propose we start building packages from the stable branches and put them in an appropriately named/labeled PPA, such as nova-core/diablo-qa or nova-core/diablo-not-for-production (or perhaps under openstack-stable-maint). I'm not convinced that distribution specific packaging is the best way to go about this. That's a valid discussion. At the moment, this is what we do for trunk commits. This is how we generally propose that people test things out. I don't see any reason why the mechanics for testing the stable branches should be different. So, a discussion about these mechanisms shouldn't be isolated to the context of the stable branch. I want Fedora users to be able to test out, and get involved with, upstream as easily as Ubuntu users are. I'd be happy for us to build Fedora packages as well, fwiw. Same for other distros. The thought of getting into the game of maintaining this upstream packaging for multiple distros, and e.g. having to make sure any dependencies are packaged for these distros ... ugh. Yes, this is a lot of work. This is one of the primary reasons we chose a reference platform to begin with: Being able to focus the efforts and actually succeed rather than trying to do everything and fail. We had (and have) people involved in the project that could actually take this on. If someone wants to do the same for Fedora (and other distros), that'd be awesome. I don't have anything concrete to offer as an alternative, but I'd love to see something like devstack that runs either from git or tarballs and supports multiple distributions. For production, we recommend people use packages. I think there's a lot of value in using the same installation mechanism for QA as for production. There's also the likes of jhbuild, GARGNOME, minuteman and surely more - perhaps we can take a leaf out of their books? I hope I'n not stepping on anyone's toes, but I consider those things to be relics from a time before things such as PPA's became prevalent. -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ 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] dashboard don't support chinese
hi:
i am a chinese, i want use dashboard in chinese;is there anyone can help me?
thanks
in the /var/log/apache/error.log:
[Wed Nov 30 21:31:24 2011] [error] DEBUG:django_openstack.api:admin_api
connection created using token ee56dcd8ff2ef8e02001 and url
http://192.168.1.2:8774/v1.1/1;
[Wed Nov 30 21:31:24 2011] [error] ERROR:django_openstack.forms:Nonspecific
error while handling form
[Wed Nov 30 21:31:24 2011] [error] Traceback (most recent call last):
[Wed Nov 30 21:31:24 2011] [error] File
/opt/openstack-dashboard/django-openstack/django_openstack/forms.py, line
177, in maybe_handle
[Wed Nov 30 21:31:24 2011] [error] return form, form.handle(request, data)
[Wed Nov 30 21:31:24 2011] [error] File
/opt/openstack-dashboard/django-openstack/django_openstack/syspanel/views/flavors.py,
line 56, in handle
[Wed Nov 30 21:31:24 2011] [error] int(data['flavorid']))
[Wed Nov 30 21:31:24 2011] [error] File
/opt/openstack-dashboard/django-openstack/django_openstack/api.py, line 450,
in flavor_create
[Wed Nov 30 21:31:24 2011] [error] name, int(memory), int(vcpu), int(disk),
flavor_id))
[Wed Nov 30 21:31:24 2011] [error] File
/opt/openstackx/openstackx/admin/flavors.py, line 34, in create
[Wed Nov 30 21:31:24 2011] [error] return self._create('/admin/flavors',
body, flavor)
[Wed Nov 30 21:31:24 2011] [error] File
/opt/openstackx/openstackx/api/base.py, line 40, in _create
[Wed Nov 30 21:31:24 2011] [error] resp, body =
self.api.connection.post(url, body=body)
[Wed Nov 30 21:31:24 2011] [error] File
/opt/openstackx/openstackx/api/connection.py, line 81, in post
[Wed Nov 30 21:31:24 2011] [error] return self._cs_request(url, 'POST',
**kwargs)
[Wed Nov 30 21:31:24 2011] [error] File
/opt/openstackx/openstackx/api/connection.py, line 63, in _cs_request
[Wed Nov 30 21:31:24 2011] [error] **kwargs)
[Wed Nov 30 21:31:24 2011] [error] File
/opt/openstackx/openstackx/api/connection.py, line 48, in request
[Wed Nov 30 21:31:24 2011] [error] raise exceptions.from_response(resp,
body)
[Wed Nov 30 21:31:24 2011] [error] ApiException: Cannot create instance_type
with name \\u6d4b\\u8bd5 and flavorid 10 (HTTP 500)
[Wed Nov 30 21:31:24 2011] [error] DEBUG:django_openstack.api:admin_api
connection created using token ee56dcd8ff2ef8e02001 and url
http://192.168.1.2:8774/v1.1/1
in the /var/log/nova/nova-api.log:
(nova.exception): TRACE: File
/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py, line 1359, in
flush
(nova.exception): TRACE: self._flush(objects)
(nova.exception): TRACE: File
/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py, line 1447, in
_flush
(nova.exception): TRACE: raise
(nova.exception): TRACE: TypeError: exceptions must be old-style classes or
derived from BaseException, not NoneType
(nova.exception): TRACE:
(nova.instance_types): TRACE: Traceback (most recent call last):
(nova.instance_types): TRACE: File
/usr/lib/python2.7/dist-packages/nova/compute/instance_types.py, line 56, in
create
(nova.instance_types): TRACE: rxtx_cap=rxtx_cap))
(nova.instance_types): TRACE: File
/usr/lib/python2.7/dist-packages/nova/db/api.py, line 1334, in
instance_type_create
(nova.instance_types): TRACE: return IMPL.instance_type_create(context,
values)
(nova.instance_types): TRACE: File
/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py, line 101, in
wrapper
(nova.instance_types): TRACE: return f(*args, **kwargs)
(nova.instance_types): TRACE: File
/usr/lib/python2.7/dist-packages/nova/db/sqlalchemy/api.py, line 3331, in
instance_type_create
(nova.instance_types): TRACE: raise exception.DBError(e)
(nova.instance_types): TRACE: DBError: exceptions must be old-style classes or
derived from BaseException, not NoneType
(nova.instance_types): TRACE:
2011-11-30 21:31:24,376 ERROR nova.api.openstack [-] Caught error: Cannot
create instance_type with name 娴.. and flavorid 10
(nova.api.openstack): TRACE: Traceback (most recent call last):
(nova.api.openstack): TRACE: File
/usr/lib/python2.7/dist-packages/nova/api/openstack/__init__.py, line 64, in
__call__
(nova.api.openstack): TRACE: return req.get_response(self.application)
(nova.api.openstack): TRACE: return self.app(env, start_response)
(nova.api.openstack): TRACE: File
/usr/lib/pymodules/python2.7/webob/dec.py, line 159, in __call__
2011-11-30 21:31:00,938 INFO nova.api.openstack.wsgi [-] GET
http://192.168.1.2:8774/v1.1/1/flavors/detail?fresh=1322659860.88
2011-11-30 21:31:03,445 INFO nova.api.openstack.wsgi [-] GET
http://192.168.1.2:8774/v1.1/1/admin/services?fresh=1322659863.39
2011-11-30 21:31:24,293 INFO nova.api.openstack.wsgi [-] POST
http://192.168.1.2:8774/v1.1/1/admin/flavors
(nova.exception): TRACE: File
/usr/lib/python2.7/dist-packages/nova/exception.py, line 78, in _wrap
(nova.exception): TRACE: return f(*args, **kwargs)
(nova.exception): TRACE: File
Re: [Openstack] Proposal for Lorin Hochstein to join nova-core
+1 ... good call! From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Vishvananda Ishaya [vishvana...@gmail.com] Sent: Tuesday, November 29, 2011 2:03 PM To: openstack (openstack@lists.launchpad.net) Subject: [Openstack] Proposal for Lorin Hochstein to join nova-core Lorin has been a great contributor to Nova for a long time and has been participating heavily in reviews over the past couple of months. I think he would be a great addition to nova-core. Vish ___ 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] Lloyd Learning Docs website content processes
On Wed, Nov 30, 2011 at 2:45 AM, Thierry Carrez thie...@openstack.org wrote: Lloyd Dewolf wrote: 2. Lloyd will log Thierry ttx Carrez's solid openstack.org/security content from http://etherpad.openstack.org/8hWNQwkWf9 to http://launchpad.net/openstack-manuals , if it is not already there. He will do a copyedit to the etherpad, and also upload his revision to openstack-manuals. We'll take it from there based on the process Anne is updating to the wiki. Note that the content was pushed to www.openstack.org webmaster for publication, without much result yet (the idea was to quickly replace nothing with something, and then improve incrementally). It would be great if we could have a more dynamic way to review/update the main website content (in the same way we control the docs site contents): it could prove useful in further revisions. Fantastic! We're of the same mind. And I'm so thankful for how hard you've pushed this forward over these past months. 1. I'm trying to motivate a revision in the same spirit as what you wrote to get online as soon as possible. From there we can look to come together to evolve the processes and communications 2. With a documented process with public visibility, we will now have a foundation where people can step forward as stakeholders, and we can quantify the time to publish. From here we can align with people's workloads, and negotiate the priority of our items. Thanks,Lloyd ___ 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] Cloud Computing StackExchange site proposal
Hi guys. When we have any kind of trouble, we hit the logs right away, and when we see the stacks, what i want to do is to copy paste the error, and wait for the search engine to do its job, since at this point i consider myself a user, so, i try to think like one, and most of the time what i want, is not to ask for a problem, but to see if someone already has it. Today i think there are enough data on launchpad to solve, or al least, give a very accurate hint about 90% of the problem a user may face (nova, swift, glance, maybe keystone) when they are stuck, but some times the search are not accurate enough for a search regarding an issue i know its there. so ... maybe i ended up using google search to look into lauchpad. So ... first, launchpad works pretty well as a QA site for openstack projects, but at least, i feel theres no a good way to show all the experience is stored there to a fresh user, so a more than good search engine i think is a must, mainly because having lack of resources for showing an answer that is already solved to a user, lead to the user to, 90% of the time, duplicate a question, and so .. a lot of admin work ( maybe deleting those, or teling the user it was already answered on THIS link), or the feeling of the QA system to be forsaken because of the amount of questions unsolved. A forum is more than ok also, because it gives the feeling of community and unity where the user feels confortable, but mixing that with a QA system, its a little difficult. Making posts promoted to FAQS or post becoming GUIDES and going into the FAQS, and the search engine suggesting something like Ok, if you didnt find your answer, maybe you are having troubles because of an implementation or a setup problem, why dont you go to the IMPLEMENTATION AND MOST IMPORTANT GUIDES to see if you can improve that and fix your real problem ?? is a nice to have, make the user confortable that they can find what they need, whitout asking for it ... in wich case, they actually can. As a last note, from mercadolibre since we have a lot already tested, and working into production ( nova clusters, nova volumes, keystone, swift, glance ) we can really share our experience in the form of THE DEFINITVE GUIDE TO ... or something that, maybe doesnt actually fix a certain user problem, but helps them understand how things gets configured, and actually how they work 2gether, we can really help on this, but i think this guides need to be put in a place where the user actually knows they exists, and no like just one post on the forum, or a question on launchpad. The official documentation is a great starting point, its has been greatly improved and we've always used it every time we tried a new openstack part of the solution, so .. nicely done there Anne. hope this gives a little user perspective. --- Alejandro mercadolibre.com On 11/30/2011 06:39 AM, Leandro Reox wrote: I think that the main problem is that we have many places to search for information, but a few people giving helpful answers. A lot of newcomers join the forum but particular setups problems sometimes leads to packaging problems, bugs and we as moderators have to redirect the user to re-post his problem on launchpad, starting over. I think that we have to split packaging and developing questions vs implementations doubts, concept misunderstanding, etc. The main reason of people dropping Openstack on pre-production or testing environments its cause they aren't even mid experienced python developers, and they cant find a solution in a matter of time that they experience with the product leaves them a good taste to invest more time trying to implement it later. I read a lot of that's and end-user question, etc don't you guys forget that actually the end-users are Companies sysadmins maybe trying to deliver an real IaaS based on an Opensource product like Openstack. We have a huge Openstack implementation using almost every core product, and our environment is growing everyday faster than we expected, but when we approach to implement a new service, or integrate for example Keystone with Swift or Nova, we fought for days, fixing a lot of code and ended-up on a packaging problem, cloning the Cloudbuilders repo were the code was already fixed. That sensation to cross up docs, and blogs, and examples, and launchap question to get just to a test env, ends on companies leaving Openstack as a possible solution. We're pretty comfortable at python so we love to face issues like this, but imagine a sysadmin reading the docs, following line but line ending up with a non-working environment asking himself why he did wrong, and maybe a magic oh you have to chmod all this folder was missing on the docs. docs.openstack.org http://docs.openstack.org must be the bible for users that want to try openstack out, the forums and the IRC to help final users out, and launchpad for issuing bugs, we need to
[Openstack] future-me -was- Re: Vulnerability Management concerns: negativity count
On Thu, Nov 24, 2011 at 2:58 PM, Soren Hansen so...@linux2go.dk wrote: 2011/11/24 Lloyd Dewolf lloydost...@gmail.com: Future-me will be proud that we have a robust solution (which I feel like you guys are challenging me to brainstorm on) and that we've never had a premature disclosure. We're not quite a point yet where I'd consider that last point any sort of success. To me, it's kind of like celebrating that the shuttle hasn't exploded yet when the spaceship is still on the launch pad. I'm not inviting you to my happy place Soren! ;-) It's a popular communicate technique used to build consensus. I find it often worthwhile to present things in a number of ways as we all use different lens, and we don't want to limit our audience (particularly prematurely). Examples of variations of this technique are: * Amazon's working backwards http://www.shmula.com/start-with-the-customer-and-work-backwards/324/ http://www.allthingsdistributed.com/2006/11/working_backwards.html * Automattic often drafts the blog post and help pages before starting on design and implimentation. The very best to you, Lloyd ___ 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] Providing packages for stable releases of OpenStack
On Wed, Nov 30, 2011 at 4:07 AM, Soren Hansen so...@linux2go.dk wrote: To me, the PPA's have always been a QA tool. I wanted people willing to help test OpenStack to be able to do so with as little effort as possible. Building packages per-commit gave us that. +1 I don't have any insights on the implementation details, and agreethat it is hard to do well, but it is essential for quality. It's more than the level of effort for testing, we need to eliminatevariability, and everyone be able to point to the same thing and say,is good. But working on this today, would it introduce great variability verseswhat will be deployed to production? I hesitate to suggest this mightbe a problem for six months from now when everyone has had some timeto work out the details of their own flavors, and worked with thoseflavors with customers. Still without something how do we measure quality. ___ 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] Providing packages for stable releases of OpenStack
On 11/30/2011 7:59 AM, Soren Hansen wrote: I don't have anything concrete to offer as an alternative, but I'd love to see something like devstack that runs either from git or tarballs and supports multiple distributions. For production, we recommend people use packages. I think there's a lot of value in using the same installation mechanism for QA as for production. This, for us, is the main issue. We use devstack for various things but unfortunately install from source is very different from install for production, more so in python/openstack than some other technologies. When we are testing a new build to see whether a problem was fixed or a new feature is working we just want to change the pointer to the ppa. I understand that if some source change induces the need for a packaging change then an auto-created ppa will stop working. It is also true that creating packages as part of a build process may end up favoring some packaging system over another. Still, I don't think that is a reason to force users to have their own (or, cringe, manual) processes to create packages that can feed into a test-for-production environment when jenkins can just do it for a few popular systems. -David ___ 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] Lloyd Learning Docs website content processes
On Wed, Nov 30, 2011 at 6:18 AM, Lloyd Dewolf lloydost...@gmail.com wrote: On Wed, Nov 30, 2011 at 2:45 AM, Thierry Carrez thie...@openstack.org wrote: Lloyd Dewolf wrote: 2. Lloyd will log Thierry ttx Carrez's solid openstack.org/security content from http://etherpad.openstack.org/8hWNQwkWf9 to http://launchpad.net/openstack-manuals , if it is not already there. He will do a copyedit to the etherpad, and also upload his revision to openstack-manuals. We'll take it from there based on the process Anne is updating to the wiki. Note that the content was pushed to www.openstack.org webmaster for publication, without much result yet (the idea was to quickly replace nothing with something, and then improve incrementally). It would be great if we could have a more dynamic way to review/update the main website content (in the same way we control the docs site contents): it could prove useful in further revisions. Fantastic! We're of the same mind. And I'm so thankful for how hard you've pushed this forward over these past months. 1. I'm trying to motivate a revision in the same spirit as what you wrote to get online as soon as possible. From there we can look to come together to evolve the processes and communications 2. With a documented process with public visibility, we will now have a foundation where people can step forward as stakeholders, and we can quantify the time to publish. From here we can align with people's workloads, and negotiate the priority of our items. Thanks,Lloyd Ugg, sorry for the formatting again. I thought this was resolved in the latest Google Chrome Canary. ___ 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] Cloud Computing StackExchange site proposal
On Wed, 2011-11-30 at 10:26 -0300, Alejandro Comisario wrote: Today i think there are enough data on launchpad to solve, When you say 'enough data in launchpad' what do you mean exactly? A forum is more than ok also, because [...] lets avoid talking about tools. I'd like to understand what features we want to offer to new users searching for answers to their questions. And I'd also like to understand what features are important for experts and developers in order for them to participate in giving answers, when needed. Making posts promoted to FAQS or post becoming GUIDES and going into the FAQS, and the search engine suggesting something like [...] If I understand correctly, you would like to have a system where a question from a new user can be marked as FAQ and that question, with the relevant answer can go populate a list of FAQs. Is that what you have in mind? Ok, if you didnt find your answer, maybe you are having troubles because of an implementation or a setup problem, why dont you go to the IMPLEMENTATION AND MOST IMPORTANT GUIDES to see if you can improve that and fix your real problem ?? The Documentation and Guides should be the first stop for anybody looking for answers, right? /stef ___ 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] Proposal for Lorin Hochstein to join nova-core
+1! On 11/30/11 8:05 AM, Sandy Walsh sandy.wa...@rackspace.com wrote: +1 ... good call! From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Vishvananda Ishaya [vishvana...@gmail.com] Sent: Tuesday, November 29, 2011 2:03 PM To: openstack (openstack@lists.launchpad.net) Subject: [Openstack] Proposal for Lorin Hochstein to join nova-core Lorin has been a great contributor to Nova for a long time and has been participating heavily in reviews over the past couple of months. I think he would be a great addition to nova-core. Vish ___ 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] Proposal for Mark McLoughlin to join nova-core
+1 from me, too On 11/30/11 4:47 AM, Soren Hansen so...@linux2go.dk wrote: 2011/11/29 Vishvananda Ishaya vishvana...@gmail.com: Mark is maintaining openstack for Fedora and has made some excellent contributions to nova. He has also been very prolific with reviews lately. Lets add him to core and make his reviews count towards potential merges! I'd be delighted to have Mark on the core team. +1 -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ 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] Cloud Computing StackExchange site proposal
I would like to see a way to identify the version (or milestone) the question pertains to, perhaps via a select box. OpenStack is moving quickly and I expect many questions will become irrelevant just as quickly. There could also be an All option, if the question is about something fundamental (e.g. ping and ssh don't work). Maybe there could also be an option for people with enough reputation/karma/points to edit the version. Of course you could do this with a tag but that's easily forgotten and people will often invent their own tags for the same version. Everett On Tue, Nov 29, 2011 at 12:16 PM, Stefano Maffulli stef...@openstack.orgwrote: On Tue, 2011-11-29 at 10:10 -0800, Lloyd Dewolf wrote: Where do I find this previous discussion? around here: https://lists.launchpad.net/openstack/msg02169.html What do you think of the requirements we're gathering for the QA system? I'd like your opinion on that as we move on. thanks stef ___ 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] Providing packages for stable releases of OpenStack
On 30 Nov 2011 - 13:57, Loic Dachary wrote: Hi, TL;DR summary: The resources needed to do that properly are bigger than you think (and doing that will alienate some distro packaging resources), so we'll either do a terrible job at it, or lose focus on the development release. If there is a need, it should be done as an alternate distribution, not inside the OpenStack project. As Julien Danjou wrote, we ( OpenStack Debian GNU/Linux packagers [1]) discussed your mail. We are comfortable with the idea that OpenStack focuses on development and that packaging is left to the packagers involved in each distribution. Packaging related patches from Julien Danjou were recently accepted upstream (https://review.openstack.org/#dashboard,1669). This is the kind of cooperation that makes it possible to maintain packages matching the Debian GNU/Linux quality standard. We are confident in our ability to provide stable packages in the future. OpenStack packaging is not an easy task. It currently fits nicely in Debian GNU/Linux. However, as it evolves towards a system widely used in production, it will face new challenges and the communities working on packaging for each distribution will provide valuable input to developers. Creating a packaging team with representatives for each distribution and electing someone to represent them in the Policy Board could achieve this. Very +1. d Cheers [1] PKG OpenStack page : https://alioth.debian.org/projects/openstack/and corresponding packages: http://qa.debian.org/developer.php?login=openstack-de...@lists.alioth.debian.org http://qa.debian.org/developer.php?packages=nova http://qa.debian.org/developer.php?packages=glance begin:vcard fn:Loic Dachary n:Dachary;Loic org:Artisan Logiciel Libre adr:;;12 bd Magenta;Paris;;75010;France email;internet:l...@dachary.org title:Senior Developer tel;work:+33 4 84 25 08 05 tel;home:+33 9 51 18 43 38 tel;cell:+33 6 64 03 29 07 note:Born 131414404 before EPOCH. url:http://dachary.org/ version:2.1 end:vcard ___ 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] [nova-testing] Efforts for Essex
On Tue, Nov 29, 2011 at 12:21 PM, Soren Hansen so...@linux2go.dk wrote: It's been a bit over a week since I started this thread. So far we've agreed that running the test suite is too slow, mostly because there are too many things in there that aren't unit tests. We've also discussed my fake db implementation at length. I think we've generally agreed that it isn't completely insane, so that's moving along nicely. Duncan has taken the first steps needed to split the test suite into unit tests and everything else: https://review.openstack.org/#change,1879 Just one more core +1 needed. Will someone beat me to it? Only time will tell :) Thanks, Duncan! Anything else around unit testing anyone wants to get into The Great Big Plan[tm]? Actually, yeah... one more thing :-) Jay and I were chatting about organization of infrastructure last night/this morning (on the review comments for the branch I submitted). He said that I should raise a concern I expressed for wider discussion: right now, tests are all piled into the tests directory. Below are my thoughts on this. I think such an approach is just fine for smaller projects; there's not a lot there, and it's all pretty easy to find. For large projects, this seems like not such a good idea for the following reasons: * tests are kept separate from the code they relate to * there are often odd test module file naming practices required (e.g., nova/a/api.py and nova/b/api.py both needing test cases in nova/tests/) * there's no standard exercised for whether a subpackage gets a single test case module or whether it gets a test case subpackage * test modules tend to be very long (and thus hard to navigate) due to the awkwardness of naming modules when all the code lives together * it makes it harder for newcomers to find code; when they live together, it's a no-brainer OpenStack is definitely not a small project, and as our test coverage becomes more complete, these issues will have increased impact. I would like to clean all of this up :-) And I'm volunteering to do the work! Here's the sort of thing I envision, using nova.volume as an example: * create nova/volume/tests * move all scheduler-related tests (there are several) from nova/tests into nova/volume/tests * break out tests on a per-module basis (e.g., nova/volume/driver.py would get the test module nova/volume/tests/test_driver.py, etc.) * for modules that have already been broken out at a more fine-grained level, keep (smaller test case modules are nice!) * only nova/*.py files will have a test case module in nova/tests * bonus: update the test runner to print the full dotted path so it's immediately (and visually) clear where one has to go to address any failures Given approval, this work would be done in its own blueprint. All this work would be done in small chunks (probably one branch per module) so that it will be easy to review and adjust the approach as needed. Thoughts? d -- Soren Hansen | http://linux2go.dk/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ 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] [nova-testing] Efforts for Essex
I need to catch up a bit with this thread, but I wanted to mention I have a huge patch coming that refactors almost all of the scheduler tests into true unit tests. I'd started this for other reasons and I hope it jives with the plans here. But if anyone is looking at the scheduler tests, we should sync up. - Chris On Nov 30, 2011, at 1:07 PM, Duncan McGreggor dun...@dreamhost.com wrote: On Tue, Nov 29, 2011 at 12:21 PM, Soren Hansen so...@linux2go.dk wrote: It's been a bit over a week since I started this thread. So far we've agreed that running the test suite is too slow, mostly because there are too many things in there that aren't unit tests. We've also discussed my fake db implementation at length. I think we've generally agreed that it isn't completely insane, so that's moving along nicely. Duncan has taken the first steps needed to split the test suite into unit tests and everything else: https://review.openstack.org/#change,1879 Just one more core +1 needed. Will someone beat me to it? Only time will tell :) Thanks, Duncan! Anything else around unit testing anyone wants to get into The Great Big Plan[tm]? Actually, yeah... one more thing :-) Jay and I were chatting about organization of infrastructure last night/this morning (on the review comments for the branch I submitted). He said that I should raise a concern I expressed for wider discussion: right now, tests are all piled into the tests directory. Below are my thoughts on this. I think such an approach is just fine for smaller projects; there's not a lot there, and it's all pretty easy to find. For large projects, this seems like not such a good idea for the following reasons: * tests are kept separate from the code they relate to * there are often odd test module file naming practices required (e.g., nova/a/api.py and nova/b/api.py both needing test cases in nova/tests/) * there's no standard exercised for whether a subpackage gets a single test case module or whether it gets a test case subpackage * test modules tend to be very long (and thus hard to navigate) due to the awkwardness of naming modules when all the code lives together * it makes it harder for newcomers to find code; when they live together, it's a no-brainer OpenStack is definitely not a small project, and as our test coverage becomes more complete, these issues will have increased impact. I would like to clean all of this up :-) And I'm volunteering to do the work! Here's the sort of thing I envision, using nova.volume as an example: * create nova/volume/tests * move all scheduler-related tests (there are several) from nova/tests into nova/volume/tests * break out tests on a per-module basis (e.g., nova/volume/driver.py would get the test module nova/volume/tests/test_driver.py, etc.) * for modules that have already been broken out at a more fine-grained level, keep (smaller test case modules are nice!) * only nova/*.py files will have a test case module in nova/tests * bonus: update the test runner to print the full dotted path so it's immediately (and visually) clear where one has to go to address any failures Given approval, this work would be done in its own blueprint. All this work would be done in small chunks (probably one branch per module) so that it will be easy to review and adjust the approach as needed. Thoughts? d -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ 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] Providing packages for stable releases of OpenStack
On Nov 30, 2011, at 4:18 AM, Thierry Carrez wrote: Soren Hansen wrote: I propose we start building packages from the stable branches and put them in an appropriately named/labeled PPA, such as nova-core/diablo-qa or nova-core/diablo-not-for-production (or perhaps under openstack-stable-maint). [...] That would work (and inside the current project). Just two remarks: * Expectations are difficult to control. Even if we use an intimidating name, some people will still expect this to provide more than it actually does. For example, people kept thinking that the 2011.3 release PPA would be updated, while it explicitly said it wouldn't. * I don't think that's what Vish and Monty are after -- they specifically mentioned the lack of a production-ready distribution channel as the problem that we needed to solve I won't speak for Monty, but Soren's suggestion checks all of my boxes. The use case I'm trying to fill is user's with existing infrastructure (or even older openstack installs!) that are evaluating diablo. We can't expect these users to upgrade to Oneiric. I just want to be able to tell them a place to go that they can install on Lucid that will actually work. I don't mind making it clear that they will have to take responsibility for maintaining packages if they want to take it into production. There are so many barriers of entry to getting started with OpenStack, so I'm just trying to pull down as many of those as I can. Vish -- Thierry Carrez (ttx) Release Manager, OpenStack ___ 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] [nova-testing] Efforts for Essex
On 30 Nov 2011 - 19:26, Chris Behrens wrote: I need to catch up a bit with this thread, but I wanted to mention I have a huge patch coming that refactors almost all of the scheduler tests into true unit tests. Nice! I'd started this for other reasons and I hope it jives with the plans here. But if anyone is looking at the scheduler tests, we should sync up. I was going to actually use the scheduler as the example when I sent this email out, but I switched to something a bit cleaner instead... so this is great news! Can't wait to see it :-) d - Chris On Nov 30, 2011, at 1:07 PM, Duncan McGreggor dun...@dreamhost.com wrote: On Tue, Nov 29, 2011 at 12:21 PM, Soren Hansen so...@linux2go.dk wrote: It's been a bit over a week since I started this thread. So far we've agreed that running the test suite is too slow, mostly because there are too many things in there that aren't unit tests. We've also discussed my fake db implementation at length. I think we've generally agreed that it isn't completely insane, so that's moving along nicely. Duncan has taken the first steps needed to split the test suite into unit tests and everything else: https://review.openstack.org/#change,1879 Just one more core +1 needed. Will someone beat me to it? Only time will tell :) Thanks, Duncan! Anything else around unit testing anyone wants to get into The Great Big Plan[tm]? Actually, yeah... one more thing :-) Jay and I were chatting about organization of infrastructure last night/this morning (on the review comments for the branch I submitted). He said that I should raise a concern I expressed for wider discussion: right now, tests are all piled into the tests directory. Below are my thoughts on this. I think such an approach is just fine for smaller projects; there's not a lot there, and it's all pretty easy to find. For large projects, this seems like not such a good idea for the following reasons: * tests are kept separate from the code they relate to * there are often odd test module file naming practices required (e.g., nova/a/api.py and nova/b/api.py both needing test cases in nova/tests/) * there's no standard exercised for whether a subpackage gets a single test case module or whether it gets a test case subpackage * test modules tend to be very long (and thus hard to navigate) due to the awkwardness of naming modules when all the code lives together * it makes it harder for newcomers to find code; when they live together, it's a no-brainer OpenStack is definitely not a small project, and as our test coverage becomes more complete, these issues will have increased impact. I would like to clean all of this up :-) And I'm volunteering to do the work! Here's the sort of thing I envision, using nova.volume as an example: * create nova/volume/tests * move all scheduler-related tests (there are several) from nova/tests into nova/volume/tests * break out tests on a per-module basis (e.g., nova/volume/driver.py would get the test module nova/volume/tests/test_driver.py, etc.) * for modules that have already been broken out at a more fine-grained level, keep (smaller test case modules are nice!) * only nova/*.py files will have a test case module in nova/tests * bonus: update the test runner to print the full dotted path so it's immediately (and visually) clear where one has to go to address any failures Given approval, this work would be done in its own blueprint. All this work would be done in small chunks (probably one branch per module) so that it will be easy to review and adjust the approach as needed. Thoughts? d -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ 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] [nova-testing] Efforts for Essex
It'll be a couple days yet. I was refactoring a few things in the scheduler and while re-doing some tests, I ended up going down this rabbit hole of re-doing all of the tests. It's turned into a 6500 line diff so far... :) which is a bit much for just the refactoring that I need to get in first. So, I'm currently splitting these out into a couple of different reviews. - Chris On Nov 30, 2011, at 1:53 PM, Duncan McGreggor wrote: On 30 Nov 2011 - 19:26, Chris Behrens wrote: I need to catch up a bit with this thread, but I wanted to mention I have a huge patch coming that refactors almost all of the scheduler tests into true unit tests. Nice! I'd started this for other reasons and I hope it jives with the plans here. But if anyone is looking at the scheduler tests, we should sync up. I was going to actually use the scheduler as the example when I sent this email out, but I switched to something a bit cleaner instead... so this is great news! Can't wait to see it :-) d - Chris On Nov 30, 2011, at 1:07 PM, Duncan McGreggor dun...@dreamhost.com wrote: On Tue, Nov 29, 2011 at 12:21 PM, Soren Hansen so...@linux2go.dk wrote: It's been a bit over a week since I started this thread. So far we've agreed that running the test suite is too slow, mostly because there are too many things in there that aren't unit tests. We've also discussed my fake db implementation at length. I think we've generally agreed that it isn't completely insane, so that's moving along nicely. Duncan has taken the first steps needed to split the test suite into unit tests and everything else: https://review.openstack.org/#change,1879 Just one more core +1 needed. Will someone beat me to it? Only time will tell :) Thanks, Duncan! Anything else around unit testing anyone wants to get into The Great Big Plan[tm]? Actually, yeah... one more thing :-) Jay and I were chatting about organization of infrastructure last night/this morning (on the review comments for the branch I submitted). He said that I should raise a concern I expressed for wider discussion: right now, tests are all piled into the tests directory. Below are my thoughts on this. I think such an approach is just fine for smaller projects; there's not a lot there, and it's all pretty easy to find. For large projects, this seems like not such a good idea for the following reasons: * tests are kept separate from the code they relate to * there are often odd test module file naming practices required (e.g., nova/a/api.py and nova/b/api.py both needing test cases in nova/tests/) * there's no standard exercised for whether a subpackage gets a single test case module or whether it gets a test case subpackage * test modules tend to be very long (and thus hard to navigate) due to the awkwardness of naming modules when all the code lives together * it makes it harder for newcomers to find code; when they live together, it's a no-brainer OpenStack is definitely not a small project, and as our test coverage becomes more complete, these issues will have increased impact. I would like to clean all of this up :-) And I'm volunteering to do the work! Here's the sort of thing I envision, using nova.volume as an example: * create nova/volume/tests * move all scheduler-related tests (there are several) from nova/tests into nova/volume/tests * break out tests on a per-module basis (e.g., nova/volume/driver.py would get the test module nova/volume/tests/test_driver.py, etc.) * for modules that have already been broken out at a more fine-grained level, keep (smaller test case modules are nice!) * only nova/*.py files will have a test case module in nova/tests * bonus: update the test runner to print the full dotted path so it's immediately (and visually) clear where one has to go to address any failures Given approval, this work would be done in its own blueprint. All this work would be done in small chunks (probably one branch per module) so that it will be easy to review and adjust the approach as needed. Thoughts? d -- Soren Hansen| http://linux2go.dk/ Ubuntu Developer| http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ ___ 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
[Openstack] Events in 2012 that OpenStack should not miss
Hello all, I'd like to compile a list of events, conferences and such, around the world where OpenStack should be represented. I have started with the few events I'm already aware of. You'll see that most of them are US-centric and I'm interested in other events around the world where you think OpenStack should be. What event do you think the OpenStack community should be going to, presenting or sponsoring? Add them to the etherpad: http://etherpad.openstack.org/OpenStackEvents2012 thanks stef ___ 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] How to using keystone with ldap
Thanks Leandro But I also according this article, when I add ldif to ldap, it show error: $ sudo ldapadd -Y EXTERNAL -H ldapi:/// -f keystone-2012.1/keystone/backends/ldap/keystone.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry cn=keystone,cn=schema,cn=config ldap_add: Other (e.g., implementation specific) error (80) additional info: olcObjectClasses: Duplicate option before ( keystoneEnabled ) MAY ( mail $ userPassword ) ) 2011/11/30 Leandro Reox leandro.r...@gmail.com Maybe this link can help you out : http://mirantis.blogspot.com/2011/08/ldap-identity-store-for-openstack.html Regards 2011/11/30 DeadSun mwjpi...@gmail.com Now I according to keystone/test/etc/ldap.conf.template to set ldap configuration in my keystone.conf But I have no idea that wich dn in ldap keystone used and there is no dn in keystone.ldif . How to set it? Anyone using keystone with ldap can help me? -- 非淡薄无以明志，非宁静无以致远 ___ 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] how to list all account and get disk usage info?
take a look at this: https://github.com/notmyname/slogging It collects usage information for swift, including storage usage and traffic statistics. (it has pretty good documentation - just build from source in doc/) On Wed, Nov 30, 2011 at 6:45 PM, pf shineyear shin...@gmail.com wrote: my question is for swift but, this python code not for swift, it's for nova can anyone tell me how do that in swift? thanks. On Thu, Dec 1, 2011 at 10:29 AM, Tom Fifield fifie...@unimelb.edu.auwrote: Hi, Is this for Swift? Regards, Tom On 12/01/2011 09:41 AM, pf shineyear wrote: hi all : does anyone know how to list all account and get each account's disk usage info? because i want to get every account disk usage info for bill per hour. thanks. __**_ Mailing list: https://launchpad.net/~**openstackhttps://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~**openstackhttps://launchpad.net/~openstack More help : https://help.launchpad.net/**ListHelphttps://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] How to using keystone with ldap
Seems like you jave duplicated attributes on your openldap try listing everythin with ldap search adapting the command below and then delete duplicate ldapsearch -s base -b -D cn=Administrator,cn=users,dc=domain,dc=com -w 'password' -x -h 192.168.3.10 objectClass=* subschemasubentry Regards On Nov 30, 2011 11:16 PM, DeadSun mwjpi...@gmail.com wrote: Thanks Leandro But I also according this article, when I add ldif to ldap, it show error: $ sudo ldapadd -Y EXTERNAL -H ldapi:/// -f keystone-2012.1/keystone/backends/ldap/keystone.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 adding new entry cn=keystone,cn=schema,cn=config ldap_add: Other (e.g., implementation specific) error (80) additional info: olcObjectClasses: Duplicate option before ( keystoneEnabled ) MAY ( mail $ userPassword ) ) 2011/11/30 Leandro Reox leandro.r...@gmail.com Maybe this link can help you out : http://mirantis.blogspot.com/2011/08/ldap-identity-store-for-openstack.html Regards 2011/11/30 DeadSun mwjpi...@gmail.com Now I according to keystone/test/etc/ldap.conf.template to set ldap configuration in my keystone.conf But I have no idea that wich dn in ldap keystone used and there is no dn in keystone.ldif . How to set it? Anyone using keystone with ldap can help me? -- 非淡薄无以明志，非宁静无以致远 ___ 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
