[Openstack] Keystone + Euca2ools
Hi All, Is it possible to be pointed in the direction of where Keystone is up to with euca2ools? I noticed a post from a short while back on some patch required to make Keystone work with euca2ools - what are the plans around this? Are there any instructions on this? Cheers, Kev ___ 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] Several questions about HOW SWIFT WORKS
On Tue, Jan 3, 2012 at 6:32 PM, Alejandro Comisario alejandro.comisa...@mercadolibre.com wrote: # 1 we have memcache service running on each proxy, so as far as we know, memcache actually caches keystone tokens and object paths as the request ( W.R.T the keystone token caching; in trunk the swift/keystone middleware will use the configuration from keystone.conf configuration (via keystone auth_token middleware) and not from swift/proxy_server.conf. It supports multiple memcached servers as described by John but you probably want to make sure the configuration match between the two. Chmouel. ___ 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] Presence in Fosdem 2012
Hi, will Openstack present in Fosdem 2012 ? http://fosdem.org/2012 BR Zeeshan ___ 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] Presence in Fosdem 2012
Hi, Thierry sent an email that a room has been booked for OpenStack, see his email here: http://www.mail-archive.com/openstack@lists.launchpad.net/msg05389.html Chmouel. On Wed, Jan 4, 2012 at 11:08 AM, Zeeshan Ali Shah zas...@pdc.kth.se wrote: Hi, will Openstack present in Fosdem 2012 ? http://fosdem.org/2012 ___ 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] Presence in Fosdem 2012
Zeeshan Ali Shah wrote: Hi, will Openstack present in Fosdem 2012 ? http://fosdem.org/2012 Yes, we'll be heavily present in the Open source Virtualization and Cloud devroom. Expect ~3 hours of OpenStack goodness. The schedule should be announced in the next days. -- 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] Keystone + Euca2ools
Yup,You need two things :1- enable the Keystone pipeline into nova.conf and api-paste.ini2- modify files :/usr/local/lib/python2.6/dist-packages/keystone-1.0-py2.6.egg/keystone/middleware/ec2_token.pyreplace : o = urlparse(FLAGS.keystone_ec1_url)by o = urlparse(FLAGS.keystone_ec2_url)and token_id = result['auth']['token']['id']by token_id = result['access']['token']['id']3- into nova.conf :--keystone_ec2_url=http://172.16.40.11:5000/v2.0/ec2tokensShould be good :) Nuage Co - Razique Mahrouarazique.mahr...@gmail.com Le 4 janv. 2012 à 10:29, Kevin Jackson a écrit :Hi All,Is it possible to be pointed in the direction of where Keystone is upto with euca2ools?I noticed a post from a short while back on some patch required tomake Keystone work with euca2ools - what are the plans around this?Are there any instructions on this?Cheers,Kev___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
Re: [Openstack] [OpenStack] OpenStack with Xen
Hi, Does the nova-compute DomU need to be a PV guest? I have it now on a HVM guest,which it is causing the problem * Errno 2: No such file or directory: '/sys/hypervisor/uuid'.* ** If so ,what should i do if i still want to use this HVM without reinstalling everything again on a PV guest?Thanks. Yours, Jeff 2012/1/4 Ewan Mellor ewan.mel...@eu.citrix.com Is this what you’re looking for? ** ** http://wiki.openstack.org/XenServerDevelopment ** ** Cheers, ** ** Ewan. ** ** *From:* openstack-bounces+ewan.mellor=citrix@lists.launchpad.net[mailto: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net] *On Behalf Of *Guilherme Birk *Sent:* 03 January 2012 09:06 *To:* Openstack Mail List *Subject:* [Openstack] [OpenStack] OpenStack with Xen ** ** 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 ? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Sincerely yours, Jeff ___ 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 PPA team
Hi everyone, TL;DR summary: An openstack-ppa [1] team in Launchpad was created to take clear responsibility of maintaining the various OpenStack PPAs. Those will be reworked in order to fill holes not covered in our distribution landscape and to avoid carrying false expectations. Long version: The OpenStack PPAs in Launchpad (providing various packages of OpenStack projects for various versions of Ubuntu) have a long and conflicted history. They started as core-dev-maintained trunk daily packages, then were made an integrated part of OpenStack release process, then were maintained by a team common with Ubuntu developers (while still being owned by OpenStack core dev teams), to finally be versed into the CI bucket (mostly because the same members happen to work on it). The net result was that nobody was really owning them, and issues were left unfixed. In order to clearly delimit responsibility between teams (and to own the new PPAs), a separate openstack-ppa team [1] was created. This team was seeded with interested members of openstack-ci but is open to new members with Launchpad PPA and Debian packaging experience. Bugs can be filed against the openstack-ppa project [2] in Launchpad, or existing packaging bugs that need to be fixed in OpenStack PPAs can be marked as also affecting project openstack-ppa. The team will encourage collaboration with Ubuntu to share packaging trees, and maintain a limited number of unified PPAs that are clearly targeted to developer/tester audiences. Those PPAs will be considered like another downstream distribution of OpenStack and not special-cased: in particular producing PPA packages after a given openstack milestone or release will no longer be a formal part of the official OpenStack release process (which should only produce tarballs that are consumed by a set of downstream distributions). This will dramatically reduce the time necessary to produce OpenStack milestones and releases and put all distributions on an equal footing. To have a rough idea of what we plan to do, you can have a look at the bugs at [3]. In particular, we plan to deprecate the release PPAs since they carry a false expectation of being maintained with stable branch updates and be production-ready. We also plan to regroup the PPAs (avoid having separate PPAs per project) to avoid duplication of effort and stale PPAs. Feel free to join Monty, Soren and me and help bootstrapping this team. [1] https://launchpad.net/~openstack-ppa [2] https://launchpad.net/openstack-ppa [3] https://bugs.launchpad.net/openstack-ppa -- 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] Integration test gating on trunk
Hi Jim, A couple of questions for you: 1) You mentioned how to coordinate changes between glance and nova but what about devstack. Does that same process apply to devstack as well? For example if there were a configuration file change (api-paste changes often and can cause failures) would I push the required change to devstack first and then nova? Or would we need to make devstack handle multiple versions of the configuration files? 2) Where are the devstack instances running (public cloud, private Openstack cloud, etc.). If the public cloud is down for maintenance does that mean code can't land? Are there any plans to run this on a private or OpenStack backed cloud? Regardless of what we are doing is there a backup plan in place so that code can land? 3) Are there any plans on making this run on branches in merge prop (before we approve them)? I would love to know that devstack passes ahead of time before I approve a branch. Thanks, Dan -Original Message- From: James E. Blair cor...@inaugust.com Sent: Thursday, December 29, 2011 5:51pm To: OpenStack Mailing List openstack@lists.launchpad.net Subject: [Openstack] Integration test gating on trunk Hi, A few weeks ago, I wrote about turning on an integration test gating job for the stable/diablo branch. That's been running for a while now, and during that time with help from Anthony Young and Jesse Andrews, we've been able to address the issues we saw and make the job fairly reliable. At the last design summit, we agreed that we should gate trunk development of at least nova and its immediate dependencies on some kind of integration test. The biggest change this introduces to developer workflow is how to handle changes that affect more than one project. At the design summit, it was decided that such changes should be authored so that the system continues to function as each is merged in order. In other words, if you need to modify nova and glance, you might make a change to nova that accepts old and new behaviors from glance, then change glance. The job we've been developing uses devstack to set up nova, glance, and keystone, and then runs the relevant exercise.sh tests. Obviously that's not a lot of testing, but it does at least ensure that nova can perform its basic functions, which, again, was an important milestone identified at the summit. Once tempest is ready for this, we'll start using it. At this point, I believe the testing infrastructure is stable enough for us to turn on gating for all branches of nova, glance, and keystone (also python-novaclient, devstack, and openstack-ci, which are involved in the setup and running of the tests). I would not be surprised if we run into some problems. We might see transient network errors in the test setup, in which case you can just re-trigger the job (you can vote Approved again), and we can see if there's some caching or local mirroring we can do to reduce that risk. We might encounter non-deterministic behavior in the setup and running of OpenStack, in which case it would be best to treat that as a bug in devstack or the affected component and improve the software. I think that kind of problem is the sort of thing that our CI system should be uncovering, so even though it's annoying if it affects landing a patch you're working on, I think it's a net positive to the effort overall. Also, we just might catch real bugs. Having said that, the Jenkins job has been running in silent mode on master for several days with few false errors. My feeling from the design summit was that it was generally understood there would be a shakedown period, and people are willing to accept some risk and some extra work for the benefits an integration test gating job will brink. I think we're at that point, so I'd like to turn this job on Tuesday, January 3rd. -Jim ___ 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] OpenStack with Xen
On Wed, Jan 4, 2012 at 9:06 AM, jeffrey coho jeffreycohob...@gmail.com wrote: Hi, Does the nova-compute DomU need to be a PV guest? Yes, I think so. I don't know if it is possible to expose that to an HVM guest. You could ask on the Xen mailing lists. I have it now on a HVM guest,which it is causing the problem Errno 2: No such file or directory: '/sys/hypervisor/uuid'. If so ,what should i do if i still want to use this HVM without reinstalling everything again on a PV guest?Thanks. You can convert an HVM guest to a PV guest although there is several subtle steps (especially for XenServer/XCP guests) that I can't recall off the top of my head, but If you ask on the Xen lists and Xen IRC you will likely get some pointers. Hope that helps. Thanks, Todd -- Todd Deshane http://www.linkedin.com/in/deshantm http://blog.xen.org/ http://wiki.xen.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] openstack-common
Openstack-common could be great. There are lots of use cases that make a lot of sense to put in openstack common. Configuration loading, context, some aspects of logging, wsgi middleware, some parts of utils--those seem to me like great opportunities to save time and effort, both writing and reading code, through code reuse. Unfortunately, openstack-common could also be horrible. When a problematic module makes it into openstack-common it gets enshrined in rough consensus and is much harder to change or replace. If there are divergent use cases for that module, no doubt the common implementation of it will be riddled with conditional code paths, with each path only truly being exercised by one project (illusory reuse). If the module frequently has to change, then backwards compatibility requirements will make the code even more complicated and harder to understand and change. The requirement that there is no other API in OpenStack competing for this consensus means that, when a spaghetti-code module ought to be simply replaced or removed from common, fewer people will be willing to do this work because they now have to change the calling code in N projects. We need to think carefully about how we will avoid and address this problem. I have a few proposals. I'm not 100% certain of any of these, but I'd like for you to consider them. 1) The process of adding code to common should require input from every core project. This might take the form of requiring one core member from each to approve the merge. 2) We should plan to be restrictive about what lands in common. We should plan to fight complexity and illusory reuse before something lands in common rather than relying exclusively on iterating on it after it is in common. 3) Rather than forking jkoelker/openstack-common, we should create a new project and merge sections in piecemeal. This creates the opportunity to review each part separately. 4) Above and beyond #2 and #3, our first steps should err on the side of safety. So while I feel that a lot of the modules in the current openstack-common github repo definitely belong there, I am really worried about the web framework and serialization code. That code in particular feels likely to change and likely to have different uses in different projects. As such it will probably bite us with complexity both from backwards compatibility and illusory reuse. Maybe we can refactor and rewrite to avoid these problems, but we should probably do that before adding it to common rather than after. As always, just my 2 cents, but I hope there are others out there who are similarly concerned that openstack-common might not be worth it if we just try to go full-tilt on code reuse. Mark McLoughlin mar...@redhat.com said: Hey, As Jason says - another year, another openstack-common thread! :-) I've just written up the plan Jason and I have for openstack-common: http://wiki.openstack.org/CommonLibrary (also pasted below to make it easier to reply to) I guess what we're trying to do is quickly get this thing into good enough shape to do a first release. Even if that release only contains a handful of APIs, but they meet the criteria below, then we'll have a really solid foundation to build on. Thoughts? Cheers, Mark. The openstack-common project intends to produce a python library containing infrastructure code shared by OpenStack projects. The APIs provided by the project should be high quality, stable, consistent and generally useful. The existence of an API in openstack-common should be indicitative of rough consensus across the project on that API's design. New OpenStack projects should be able to use an API in the library safe in the knowledge that, by doing so, the project is being a good OpenStack citizen and building upon established best practice. To that end, a number of principles should be adhered to when considering any proposed API for openstack-common: 1) The API is generally useful and is a good fit - e.g. it doesn't encode some assumptions specific to the project it originated from, it should follow a style consistent with other openstack-common APIs and should fit generally in a theme like error handling, configuration options, time and date, notifications, WSGI, etc. 2) The API is already in use by a number of OpenStack projects 3) There is a commitment to adopt the API in all other OpenStack projects (where appropriate) and there are no known major blockers to that adoption 4) The API represents the rough consensus across OpenStack projects 5) There is no other API in OpenStack competing for this rough consensus 6) It should be possible for the API to evolve while continuing to maintain backwards compatibility with older versions for a reasonable period - e.g. compatibility with an API deprecated in release N may only be removed in
Re: [Openstack] Integration test gating on trunk
Dan Prince dan.pri...@rackspace.com writes: Hi Jim, A couple of questions for you: 1) You mentioned how to coordinate changes between glance and nova but what about devstack. Does that same process apply to devstack as well? For example if there were a configuration file change (api-paste changes often and can cause failures) would I push the required change to devstack first and then nova? Or would we need to make devstack handle multiple versions of the configuration files? Yes, the same is true for coordinating changes across all of the projects, including devstack (one change at a time in sequence). 2) Where are the devstack instances running (public cloud, private Openstack cloud, etc.). If the public cloud is down for maintenance does that mean code can't land? Are there any plans to run this on a private or OpenStack backed cloud? Regardless of what we are doing is there a backup plan in place so that code can land? They are currently running in the Rackspace public cloud. There is a cache of N machines (N==5 currently) running and ready to receive devstack installs for this test, with new ones being added by a frequent Jenkins job[1] to replace those consumed. That helps smooth over operational errors and short outages. If all of those are consumed, the job will fail, and we won't be able to land patches. Considering the importance of RS public cloud availability, I think that waiting until it's up again is probably going to be a viable option. If there is some sort of extended outage, we can discuss disabling the job. In the medium to long term, we plan on mitigating this risk by consuming VMs from multiple cloud providers. HP has offered its public cloud for this purpose. I'd like the normal mode of operation to launch VMs on both (all?) of the cloud providers participating to balance load and resource usage, and of course that gets us higher availability, at least for the kind of scenario you described. 3) Are there any plans on making this run on branches in merge prop (before we approve them)? I would love to know that devstack passes ahead of time before I approve a branch. Yes, running tests when patchsets are uploaded is in the plan. With the new gerrit trigger plugin we installed last week, we have the technical capability to run Jenkins jobs on proposal, approval, or merge. I believe we will start working on that soon, after we address some security concerns. -Jim [1] https://jenkins.openstack.org/job/devstack-launch-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] Using Gerrit to verify the CLA
Mark McLoughlin mar...@redhat.com writes: Nice work. Do you have a sense of how many past contributors haven't signed the CLA or added themselves to the wiki? I don't know. Also, how does this work for the corporate CLA? We're not changing the CLA process at all, so the existing process still stands: Note that: If you are contributing on behalf of a company or organization, someone at your company or organization needs to sign the Corporate Contributor License Agreement. A list of current companies and organizations with an existing Corporate CLA is available for your review. I'm not going to interpret that; I'm just going to make sure that the people currently on the wiki are in the launchpad group, and then add to the instructions an item to also request membership in the launchpad group. There is no technical verification of corporate CLA compliance. -Jim ___ 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] Tempita usage?
No argument from me. Feel free to propose a branch that does the things you describe below. I'm sure you'll get feedback in code review :) Cheers! -jay On Tue, Jan 3, 2012 at 2:17 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: I was wondering if there has been any thought or consideration of removing tempita and replacing it with “just python”. Personally the current tempita usage (libvirt.xml.template) seems to be heading down a hairy path and I wanted to see others opinions on say replacing this with something that doesn’t require a whole templating language to use. Some of this may just be my bias against templating languages from experience in different projects @ yahoo (they always start to get hairy, especially when u start to code in them). Some thoughts: Assuming we can get a libvirt.domain.xsd (?) we can use a xsd-object model utility to transform that xsd into a python object model (there seem to be a couple of these?) http://www.rexx.com/~dkuhlman/generateDS.html or http://pyxsd.org/ (or something else?) Create a exposed “tree” representation of the sections of the libvirt domain xml that we are interested in (and only those that we are interested in) as python objects and have current code create these objects (which right now is basically a set of python hashes getting sent to the tempita library) Pass the root element of this exposed “tree” representation to a formatter class (which itself could use pyxsd objects, or tempita – for backward compatibility, or something else, but I have a strong preference for keeping a single language in use, instead of a tempita language and a python language). Write output created by formatter class to domain.xml file (and continue as normal). Profit! Some of the benefits I think exist with this: XML escaping will actually happen (does this happen right now?) We can have a underlying object layer which comes directly from the libvirt.domain.xsd (and possibly have versions of this to work with different libvirt versions) We can have an exposed object layer which will attempt to be version independent of the underlying layer and only contain methods/properties that we will use with libvirt (ie the xsd will have many properties/fields we will not use, thus we should not expose them). We can have a formatter layer that will know how to use this exposed layer and return a object that can convert the exposed layer into a string, thus allowing for different implementations (or at least a separation of what is exposed, how its formatted and what the formatter internally uses). We can have the if statements and loops and such that are starting to get put in the template code in python code (thus u don’t have to context switch into a templating language to make changes, thus making it easier to work with libvirt). Possible remove a dependency (always good). Thoughts? -Josh ___ 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] swift release 1.4.5
It's time again for a swift release. We have cut the swift 1.4.5 release and it's headed to QA. We expect it to be validated by the end of this week and it should land for public use early next week. Below is the changelog for this release. The highlights are the swift-orphans and swift-oldies tools and the fix to swift-init to support swift-object-expirer. As always, you will be able to upgrade to this release with no downtime for your users. Full changelog for swift (1.4.5) * New swift-orphans and swift-oldies command line tools to detect orphaned Swift processes and long running processes. * Command line tool swift now supports marker queries. * StaticWeb middleware improved to save an extra request when possible. * Updated swift-init to support swift-object-expirer. * Fixed object replicator timeout handling [bug 814263]. * Fixed accept header 503 vs. 400 [bug 891247]. * More exception handling for auditors. * Doc updates for PPA [bug 905608]. * Doc updates to explain replication more clearly [bug 906976]. * Updated SAIO instructions to no longer mention ~/swift/trunk. * Fixed docstrings in the ring code. * PEP8 Updates. smime.p7s Description: S/MIME cryptographic 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] Tempita usage?
Fwiw, I'm +1 on this :-) I look forward to reviewing the branch... d On 04 Jan 2012 - 14:51, Jay Pipes wrote: No argument from me. Feel free to propose a branch that does the things you describe below. I'm sure you'll get feedback in code review :) Cheers! -jay On Tue, Jan 3, 2012 at 2:17 PM, Joshua Harlow harlo...@yahoo-inc.com wrote: I was wondering if there has been any thought or consideration of removing tempita and replacing it with ???just python???. Personally the current tempita usage (libvirt.xml.template) seems to be heading down a hairy path and I wanted to see others opinions on say replacing this with something that doesn???t require a whole templating language to use. Some of this may just be my bias against templating languages from experience in different projects @ yahoo (they always start to get hairy, especially when u start to code in them). Some thoughts: Assuming we can get a libvirt.domain.xsd (?) we can use a xsd-object model utility to transform that xsd into a python object model (there seem to be a couple of these?) http://www.rexx.com/~dkuhlman/generateDS.html or http://pyxsd.org/ (or something else?) Create a exposed ???tree??? representation of the sections of the libvirt domain xml that we are interested in (and only those that we are interested in) as python objects and have current code create these objects (which right now is basically a set of python hashes getting sent to the tempita library) Pass the root element of this exposed ???tree??? representation to a formatter class (which itself could use pyxsd objects, or tempita ??? for backward compatibility, or something else, but I have a strong preference for keeping a single language in use, instead of a tempita language and a python language). Write output created by formatter class to domain.xml file (and continue as normal). Profit! Some of the benefits I think exist with this: XML escaping will actually happen (does this happen right now?) We can have a underlying object layer which comes directly from the libvirt.domain.xsd (and possibly have versions of this to work with different libvirt versions) We can have an exposed object layer which will attempt to be version independent of the underlying layer and only contain methods/properties that we will use with libvirt (ie the xsd will have many properties/fields we will not use, thus we should not expose them). We can have a formatter layer that will know how to use this exposed layer and return a object that can convert the exposed layer into a string, thus allowing for different implementations (or at least a separation of what is exposed, how its formatted and what the formatter internally uses). We can have the if statements and loops and such that are starting to get put in the template code in python code (thus u don???t have to context switch into a templating language to make changes, thus making it easier to work with libvirt). Possible remove a dependency (always good). Thoughts? -Josh ___ 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] swift release 1.4.5
John Dickinson wrote: It's time again for a swift release. We have cut the swift 1.4.5 release and it's headed to QA. We expect it to be validated by the end of this week and it should land for public use early next week. [...] From an OpenStack release management perspective, we'll cut a milestone-proposed branch early tomorrow and release next Tuesday, once we get your internal QA go-ahead (and no critical issue is raised from community milestone-proposed testing). Regards, -- 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] Do we really need a CLA? [was Re: Using Gerrit to verify the CLA]
Hi Rick, On Tue, 2012-01-03 at 09:02 -0600, Rick Clark wrote: Hey Mark, First of all, orthogonally, we are very lucky to not have Copyright Assignment crushing this project. That is what the management at Rackspace wanted, only NASA's inability to sign such a document prevented it. Copyright assignment would certainly be worse than an Apache-style CLA. IANAL, but I was told by lawyers when we were in the planning stages of starting Openstack, that while in the US submitting code under the Apache License 2.0 was enough to bind the submitter to it, that is not the case in all countries. Some countries require explicit acceptance to be bound by it. I've cc-ed Richard Fontana who I'm sure can comment on that. As far as changing anything about the way the CLA works, until we have a foundation, the discussion of which seems to have stalled, we, as a group, have no real authority to change anything. Sure, I understand and eagerly await some progress/discussion on the foundation. I was very disappointed at the level of engagement in the important discussions started by ttx on the foundation@ list in October. Even before the foundation is established, though, I'd hope that we as a community could have sensible discussions about things like our CLA policy. We have a bigger hole in the Corporate CLA, IMHO. I have been told that since it is necessary for a corporate signer to explicitly name their individual contributers, and we have no way of updating the document, openstack is potentially left open to a lawsuit, if an employee unspecified in the CLA, contributes something they consider IP. I seriously hate all this legal stuff. I'll leave that one for Richard too :-) Cheers, Mark. Cheers, Rick On 01/03/2012 06:22 AM, Mark McLoughlin wrote: Hey, I'm not sure whether this has been discussed recently, but do we really need a CLA? I had a long discussion with Richard Fontana about the Apache CLA in the context of another project and I came away from that convinced that the Apache CLA is fairly pointless. Compare the CLA to the Apache License 2.0 - there's a couple of fairly minor, arbitrary differences but, on the whole, they're the same. So, the CLA is effectively just the contributor granting OpenStack LLC the contribution under the Apache License 2.0. There are other ways to go about this: - Put in place an assumption that anyone contributing to the project (e.g. by pushing to gerrit) are contributing under the existing license of the project. - Follow the kernel's approach of making Signed-off-by: in each mean that you are contributing (and have the right to contribute) the code under the existing license of the project (http://goo.gl/lRhmQ) - Have a contributor agreement which explicitly says I am the Copyright holder and submit my contributions under the Apache License 2.0 Each of these schemes are used elsewhere and have significant advantages over the current CLA scheme - e.g. less bureaucracy, not as scarey to new contributors, less chance of the CLA being confused with copyright assignment, etc. 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 ___ 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
Yes, it needs to be a PV VM at the moment. It needs to know the UUID of the VM that it lives in, which is why it's looking in /sys/hypervisor/uuid. We could add a flag to OpenStack to let you pass this in, but there's not really any point, because the performance with the PV VM will be far superior to the HVM one anyway. To convert it, you need to install a Xen kernel (suffix -virtual if you're on Ubuntu), and then switch it to PV mode using the XenServer CLI: UUID=$(xe vm-list --minimal name-label='Whatever you called it') xe vm-param-set uuid=$UUID HVM-boot-policy= xe vm-param-set uuid=$UUID PV-bootloader=pygrub Before you reboot, make sure that the grub config has been set up correctly. It needs to refer to the new kernel, obviously. Also, the device names are going to change across the reboot - your root disk is going to stop being /dev/sda1 (or whatever) and turn into /dev/xvda1. (An exception to this is on Ubuntu Maverick, which uses /dev/sdX in the PV kernel too.) Most modern installations use disk labels rather than device names these days, so you should be OK, but it's worth checking. Also, there's a bug in some versions of Pygrub such that it will fail to boot if you have a submenu declaration in your grub.cfg. If that's the case (common on Ubuntu if you have upgraded your kernel at any point) then you'll need to remove the submenu declaration and its matching close-brace. After that, reboot, and it should come up in PV mode. If it fails to come up, set HVM-boot-policy back to 'BIOS order' and you can boot back into HVM mode and figure out what went wrong. Cheers, Ewan. From: jeffrey coho [mailto:jeffreycohob...@gmail.com] Sent: 04 January 2012 06:07 To: Ewan Mellor Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] [OpenStack] OpenStack with Xen Hi, Does the nova-compute DomU need to be a PV guest? I have it now on a HVM guest,which it is causing the problem Errno 2: No such file or directory: '/sys/hypervisor/uuid'. If so ,what should i do if i still want to use this HVM without reinstalling everything again on a PV guest?Thanks. Yours, Jeff 2012/1/4 Ewan Mellor ewan.mel...@eu.citrix.commailto:ewan.mel...@eu.citrix.com Is this what you're looking for? http://wiki.openstack.org/XenServerDevelopment Cheers, Ewan. From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.netmailto:citrix@lists.launchpad.net [mailto:openstack-bounces+ewan.mellormailto:openstack-bounces%2Bewan.mellor=citrix@lists.launchpad.netmailto:citrix@lists.launchpad.net] On Behalf Of Guilherme Birk Sent: 03 January 2012 09:06 To: Openstack Mail List Subject: [Openstack] [OpenStack] OpenStack with Xen 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 ? ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp -- Sincerely yours, Jeff ___ 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] Update on integration test gating
Hi, We encountered some problems today that delayed several patches from going in (I believe they have all been merged now). It was a bit of a rough day, but I'm pleased that several people pitched in to help identify and solve those problems, and we've made some good progress overall. Here's a quick update: 1) Syslogs are now available. If your patch runs into a problem, here's where to look: first, follow the link in Gerrit to Jenkins for the failed gate-integration-tests-devstack job. For example: https://jenkins.openstack.org/job/gate-integration-tests-devstack-vm/273/ To see the output from devstack (ie, install, setup, and test output), click the [raw] link next to Console Log to see the full console output. eg: https://jenkins.openstack.org/job/gate-integration-tests-devstack-vm/273/consoleText To see the syslog output from the OpenStack components themselves, click the syslog.txt link under Build Artifacts. eg: https://jenkins.openstack.org/job/gate-integration-tests-devstack-vm/273/artifact/logs/syslog.txt That starts right before devstack is invoked. 2) Nova's install_requires in setup.py has been removed, reducing our dependency on external network resources. A number of jobs failed because the website of the developer of pylint was slow or unavailable for much of the day. This brought to our attention that nova's setup.py was including the contents of pip-requires as the setuptools install_requires, which gets installed when python setup.py develop is run. Monty Taylor, Dean Troyer, and Anthony Young all pitched in to identify the problem and devise a solution. Here's the commit message from Monty's patch to nova: --- Loading install_requires with the contents of pip-requires isn't getting us any real beneift and is causing issues. a) It can conflict with installing nova into an environment where deps have been installed from packages (devstack) b) It breaks the ability to use -e git urls in pip-requires which we want to start using for python-novaclient and python-keystoneclient c) It causes spurious network traffic when we're trying to test things. At the same time, since we are not expecting anyone to install nova from setup.py for production, the normal benefit of the feature is not needed. --- With that change in, we should avoid seeing a repeat of the bulk of the problems today. Our inclination for how to handle dependencies going forward is: * List OS package dependencies in devstack wherever possible. * List python dependencies that are not yet available in OS packages in devstack, considering each one a bug that should be resolved by an OS package being available. 3) Anthony identified a bug in nova that appears non-deterministically in the integration test job: https://bugs.launchpad.net/nova/+bug/912033 Any future patches have the potential to run into it until it's fixed, though it seems to be rather infrequent. The exercise.sh output looks like: SKIP swift SKIP volumes PASS euca FAILED floating_ips And the relevant syslog entry: Jan 4 21:01:17 devstack-1325709057 2012-01-04 21:01:17,430 INFO nova.api.openstack.wsgi [15ac1bc9-d5c7-4f89-8c65-1d8870c4d4e3 d70af9385f7b4cbb828d54d6d1045a33 cb276eb4e5fe489ea73b696c69d5e0a6] http://127.0.0.1:8774/v1.1/cb276eb4e5fe489ea73b696c69d5e0a6/servers/detail returned with HTTP 404 Thanks again to everyone who helped and those who were patient as their patches were struggling to be merged. -Jim ___ 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 HACKING compliance testing tool
Hi Everyone, I have started working on a tool to test for nova HACKING compliance. Although I have implemented only three rules (more on the way), it already flags 115 HACKING compliance issues. If you are interested in adding more tests or fixing some current problems, the code can be found on github ( https://github.com/cloudscaling/nova-HACKING) best, Joe Gordon ___ 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 Foundation] OpenStack Mission Goals
Added the general list because this needs awareness. I think the idea that commuity pressure should be required is bullshit. That's a weakness of the leaders of the community. They don't get off the hook because the community isn't yammering at them... otherwise we'd vote on every damned thing (maybe we should rather than having elected leaders?). A commitment to open discussion and discourse that doesnt get followed through by the leaders whom commit to it is essentially a betrayal to the community. No different than being elected to congress and ignoring the promises to the people and the fact you're in the position with the responsibility to help all of them. When it is a private organization committing to transition to a foundation and there is no accountability or transparency it is tragically reminiscent of third world regimes alleging their transition to democracy. So, what's the truth, oh transitional leaders? Where's the schedule? Where's the open communication and community involvement? Jan On Jan 4, 2012, at 7:25 PM, Rick Clark r...@openstack.org wrote: I think some community pressure is in order. After the initial PR bump of the announcement, perhaps the pressure is a bit low. I really hope that this is more than a PR. I have been surprised how many people think a foundation already exists. Perhaps we can make some suggestions. I suggest that as of the next election cycle, all of the PPB is elected, including the Chair. On 01/04/2012 06:19 PM, Cole Crawford wrote: Hey Jan! Hope that's not the case. That would be a sad day for Openstack!! From: Jan Drake jan_dr...@hotmail.commailto:jan_dr...@hotmail.com Date: Wed, 4 Jan 2012 16:18:04 -0800 To: sandy.wa...@rackspace.commailto:sandy.wa...@rackspace.com Cc: foundat...@lists.openstack.orgmailto:foundat...@lists.openstack.org, openstack@lists.launchpad.netmailto:openstack@lists.launchpad.net Subject: Re: [OpenStack Foundation] OpenStack Mission Goals So, no messages since October. Rumor has it the effort is dead or indefinitely delayed... what's the deal? Jan From: jan_dr...@hotmail.commailto:jan_dr...@hotmail.com Date: Fri, 21 Oct 2011 09:18:46 -0700 To: sandy.wa...@rackspace.commailto:sandy.wa...@rackspace.com CC: foundat...@lists.openstack.orgmailto:foundat...@lists.openstack.org Subject: Re: [OpenStack Foundation] OpenStack Mission Goals +1 On Oct 20, 2011, at 9:49 AM, Sandy Walsh sandy.wa...@rackspace.commailto:sandy.wa...@rackspace.com wrote: +1 How can you decide if you want to join a foundation if you don't know what it stands for? -S I think a discussion about what OpenStack is and isn't should definitely be had before the Foundation is set up. Otherwise, I imagine people will view the Foundation as being some sort of Wild West land grab, where companies are trying to shape what OpenStack is by fiat or by trying to buy control. Just a thought, -jay ___ Foundation mailing list foundat...@lists.openstack.orgmailto:foundat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation This email may include confidential information. If you received it in error, please delete it. ___ Foundation mailing list foundat...@lists.openstack.orgmailto:foundat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation ___ Foundation mailing list foundat...@lists.openstack.orgmailto:foundat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation ___ Foundation mailing list foundat...@lists.openstack.orgmailto:foundat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation ___ Foundation mailing list foundat...@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation ___ 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 HACKING compliance testing tool
Hey! Awesome. I think this is a great idea. FWIW, Jason Kölker made a nose plugin that does pep8 called tissue: https://github.com/jkoelker/tissue I think tissue should probably stay tissue, as pep8 integration for nose is a thing that non-openstack folks would need. But it might be nice to take a peek at that and add a thing to nova-hacking that provides a nose plugin so that it would be easy to integrate to jenkins/gerrit once it's solid and we're happy about it. (I'll also be happy to work with you on getting this run as part of trunk gating if/when we reach the point where we all happy with it.) Kick ass. Monty On 01/04/2012 08:25 PM, Joe Gordon wrote: Hi Everyone, I have started working on a tool to test for nova HACKING compliance. Although I have implemented only three rules (more on the way), it already flags 115 HACKING compliance issues. If you are interested in adding more tests or fixing some current problems, the code can be found on github (https://github.com/cloudscaling/nova-HACKING) best, Joe Gordon ___ 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
