Re: [Openstack] openstack-common
> -Original Message- > From: Mark McLoughlin [mailto:mar...@redhat.com] > Sent: 03 January 2012 13:35 > To: Ewan Mellor > Cc: openstack@lists.launchpad.net; Jason Koelker > Subject: RE: [Openstack] openstack-common > > On Tue, 2012-01-03 at 19:54 +, Ewan Mellor wrote: > > I'd love to see openstack-common get off the ground, so I'm all in > > favor of this. > > > > One question: why do you feel that you need such strong backwards > > compatibility? If someone makes a change in openstack-common and > > makes simultaneous changes in all OpenStack projects to match, isn’t > > that sufficient? > > No, I really don't think it is sufficient. Unless we want packagers to > hunt us down with sharp implements :) > > Each of the projects are separated by an API which we maintain some > compatibility around. So, in theory, you can use e.g. Essex Glance with > Diablo Nova. If you make it so that Glance requires Essex Common and > doesn't work with Diablo Common, but Nova requires Diablo Common and > doesn't work with Essex common ... you're screwed. Yeah, that's fair enough. I didn't think of the Essex Glance with Diablo Nova case. You'd definitely like to be able to update the supporting libraries first. Cheers, Ewan. ___ 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
On 01/03/2012 02:11 PM, Jason Kölker wrote: > On Tue, 2012-01-03 at 21:38 +, Mark McLoughlin wrote: >>> As a related note, I'm going to get the current repo moved in to gerrit >>> today or tomorrow. >> >> It's more Jason's call, but I think we're basically asking you to hold >> off on that for a little while. We may decide to start a new repo. > > I've got Melange going off a non-master branch from my github repo at > the moment, so we could start with a clean repo and not have to worry > about breaking melange while we figure out the api on our side should > look like after surveying the other projects. > > I'm 50/50 on the blank slate approach. I'm leaning towards just taking > what is there as is, and just start refactoring it as needed. Since > melange is running off the other branch, we won't have to worry about > compat at first and can make sweeping changes. > > One thing I would like to ask is if we could not use > run_tests.sh/run_tests.py in the jenkins job as I'd like to remove it. > Currently in the setup.cfg there is a note on how to get the same output > (style wise) with nosetests. The only downside is I haven't written a > nose venv plugin yet, but if we move it to tox, then that shouldn't be > needed anyway. I'd be for that 1000% and will work with you on making it happen not just in openstack-common, but across the board. I have been wanting to kill run_tests.py since the first day that we imported nova into the code repos. If we can get this tox off the ground, then we're potentially in GREAT shape. BUT - you already have the nose plugin and the pep8 checker done, so consider me sold on that! :) Feature request - can you add an option to tissue that will cause it to output in pylint-compat format? (because we already have a jenkins thing that reads that output. In our jenkins jobs, we do this: pep8 blah | perl -ple 's/: ([WE]\d+)/: [$1]/' > pep8.txt Which is a silly filter, but I'd love to have less stupid things in jenkins jobs. Also, have you seen the way that py.test displays tracebacks? Monty ___ 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
On Tue, 2012-01-03 at 13:49 -0800, Monty Taylor wrote: > > It's more Jason's call, but I think we're basically asking you to hold > > off on that for a little while. We may decide to start a new repo. > > Oh - ok. My bad - I'll learn to read entire threads next time... > > Let let me know when it's ready to go or if there's anything you want > from me helpwise. Sorry, my bad on not keeping up with things ;). If you get a chance go ahead and pull it into gerrit as is, we can handle any changes we want through reviews. (See my note in the other email about preferring to run the tests with nosetests vs run_tests.sh though). Happy Hacking! 7-11 ___ 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
On Tue, 2012-01-03 at 21:38 +, Mark McLoughlin wrote: > > As a related note, I'm going to get the current repo moved in to gerrit > > today or tomorrow. > > It's more Jason's call, but I think we're basically asking you to hold > off on that for a little while. We may decide to start a new repo. I've got Melange going off a non-master branch from my github repo at the moment, so we could start with a clean repo and not have to worry about breaking melange while we figure out the api on our side should look like after surveying the other projects. I'm 50/50 on the blank slate approach. I'm leaning towards just taking what is there as is, and just start refactoring it as needed. Since melange is running off the other branch, we won't have to worry about compat at first and can make sweeping changes. One thing I would like to ask is if we could not use run_tests.sh/run_tests.py in the jenkins job as I'd like to remove it. Currently in the setup.cfg there is a note on how to get the same output (style wise) with nosetests. The only downside is I haven't written a nose venv plugin yet, but if we move it to tox, then that shouldn't be needed anyway. Happy Hacking! 7-11 ___ 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
Answers inline. On Jan 3, 2012, at 11:32 AM, Alejandro Comisario wrote: > > So, lets get down to business. > > # 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 ( > PUT , GET) enters the proxy, but for example, if we restart one proxy server, > so the memcached service is empty, is the restarted proxy node going to the > neighbor memcache on nex request, lookup for what it needs, and cache the > answer on itself so the next query is solved locally ? Memcache works as a distributed lookup. So the keys that were stored on the server that was restarted are no longer cached. The proxies share a memcache pool (at least in the example proxy config), so requests are fetched from that pool. Since the keys are balanced across the entire memcache pool, roughly 1/N memcache requests will be local (where N == the number of proxy servers). > > # 2 the documentation says regarding "For each request, it will look up the > location of the account, container, or object in the ring (see below) and > route the request accordingly" in what way the proxy actually does the > look-up regarding WHERE is an object / container in the cluster ? does it > connect to any datanode asking for an object location ? does the proxy have > any locally sotarge data ?? The proxy does not store any data locally (not even to buffer reads or writes). The proxy uses the ring to determine how to handle the read or write. The ring is a mapping of the storage volumes that, given an account, container, and object, provides the final location of where the data is to be stored. The proxy then uses this information to either read or write the object. > > # 3 Maybe it has to do with the previous question but, every dataNode knows > everything that is stored on the cluster (container service) or only knows > the object that has itself, and the replicas of its objects? Things are stored in swift deterministically, so data nodes don't know where everything is stored, but they know how to find where it should be stored (ie the ring). > > # 4 We are building a production cluster of 24 datanodes, having 6 drives > each (144 immediate drives) we know, that a good default number of partitions > per drive is 100, so the math for creating the ring will be (24 nodes * 6 > drives * 100 partitions) but we know the at the end of the year, the amount > of datanodes (and drives also) could be 2x or 3x more. So, for the initial > setup, can we build the RING with our 144 drives and 100 partitions per drive > so we can modify the ring / partitions later and rebalance? or is safer to > think about future infrastructure increase, and build the ring with those > numbers in mind ? Your partition power should take into account the largest size your cluster can be. You cannot change the partition power after you deploy the ring unless you migrate everything in your cluster (a manual process of GET from the old ring and PUT to the new ring), so it is important to select the proper partition power up front. > > # 5 We put a new object into the cluster, the proxy decides where to write > the object (is it in a round-robin manner ?) is the proxy server giving a > "Created" response when the 1st replica is actually writen and put into the > account and container SQLite databases ? or there is and ok just when the > OBJECT service actually wrote the data on disc ? The proxy sends the write to 3 object servers. The object servers write to disk and then send a request to the container servers to update the container listing. The object servers then return success to the proxy. After 2 object servers have returned success, the proxy can return success to the client. > > Hope, we can shed some lights regarding this doubts. There are obviously some details I've glossed over in the short answers above. Much of the complexity in swift comes from failure scenarios. Please ask if you need more detail. --John 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] openstack-common
On 01/03/2012 01:38 PM, Mark McLoughlin wrote: > On Tue, 2012-01-03 at 13:04 -0800, Monty Taylor wrote: >> Operationally they'll need to be able to make the change in a way that >> it can be sequenced. We don't have a concept of simultaneous tied >> changes. So a the change you describe would need to look like: >> >> Land change to openstack-common to add something new >> Land changes to dependent projects to use that new thing >> Land change to openstack-common to remove now deprecated thing. > > Yes, but for packaging and release sanity, the removal must come much > later. > >> As a related note, I'm going to get the current repo moved in to gerrit >> today or tomorrow. > > It's more Jason's call, but I think we're basically asking you to hold > off on that for a little while. We may decide to start a new repo. Oh - ok. My bad - I'll learn to read entire threads next time... Let let me know when it's ready to go or if there's anything you want from me helpwise. Monty ___ 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
On Tue, 2012-01-03 at 13:04 -0800, Monty Taylor wrote: > Operationally they'll need to be able to make the change in a way that > it can be sequenced. We don't have a concept of simultaneous tied > changes. So a the change you describe would need to look like: > > Land change to openstack-common to add something new > Land changes to dependent projects to use that new thing > Land change to openstack-common to remove now deprecated thing. Yes, but for packaging and release sanity, the removal must come much later. > As a related note, I'm going to get the current repo moved in to gerrit > today or tomorrow. It's more Jason's call, but I think we're basically asking you to hold off on that for a little while. We may decide to start a new repo. 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] openstack-common
On Tue, 2012-01-03 at 19:54 +, Ewan Mellor wrote: > I'd love to see openstack-common get off the ground, so I'm all in > favor of this. > > One question: why do you feel that you need such strong backwards > compatibility? If someone makes a change in openstack-common and > makes simultaneous changes in all OpenStack projects to match, isn’t > that sufficient? No, I really don't think it is sufficient. Unless we want packagers to hunt us down with sharp implements :) Each of the projects are separated by an API which we maintain some compatibility around. So, in theory, you can use e.g. Essex Glance with Diablo Nova. If you make it so that Glance requires Essex Common and doesn't work with Diablo Common, but Nova requires Diablo Common and doesn't work with Essex common ... you're screwed. This may not sound like much of a practical concern, but it's exactly why packagers curse the Java and Ruby worlds for their sloppiness. It's really painful. And, IMHO, if we allow it to happen, it will be an even bigger problem with the APIs in openstack-common than the inter-project APIs. 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] openstack-common
On 01/03/2012 02:54 PM, Ewan Mellor wrote: I'd love to see openstack-common get off the ground, so I'm all in favor of this. One question: why do you feel that you need such strong backwards compatibility? If someone makes a change in openstack-common and makes simultaneous changes in all OpenStack projects to match, isn’t that sufficient? This is somewhat related to the recent thread on gating commits on integration tests. There has to be at least some level of backwards compatibility to ensure that tests don't explode when changes are going in across multiple repos. It's also nice to set expectations for projects that want to use openstack-common, but aren't an openstack core project but perhaps would like to be eventually. -- Russell Bryant ___ 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
Operationally they'll need to be able to make the change in a way that it can be sequenced. We don't have a concept of simultaneous tied changes. So a the change you describe would need to look like: Land change to openstack-common to add something new Land changes to dependent projects to use that new thing Land change to openstack-common to remove now deprecated thing. As a related note, I'm going to get the current repo moved in to gerrit today or tomorrow. Monty On 01/03/2012 11:54 AM, Ewan Mellor wrote: > I'd love to see openstack-common get off the ground, so I'm all in favor of > this. > > One question: why do you feel that you need such strong backwards > compatibility? If someone makes a change in openstack-common and makes > simultaneous changes in all OpenStack projects to match, isn’t that > sufficient? > > Ewan. > >> -Original Message- >> From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net >> [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net] >> On Behalf Of Mark McLoughlin >> Sent: 03 January 2012 08:58 >> To: openstack@lists.launchpad.net >> Cc: Jason Koelker >> Subject: [Openstack] openstack-common >> >> 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 >> release N+2 >> >> There have been several attempts at kick-starting openstack-common, >> each attempt >> beginning with moving a number of existing APIs from Glance or Nova >> into a new >> repository. None of these attempts have quite managed to reach the >> point where >> they were ready for other OpenStack projects to depend on the library. >> >> This proposal marks the beginning of yet another attempt. The idea is >> to create >> a new openstack-common repository, seed it with Jason Kölker's >> excellent >> infrastructure from his repository[1] and begin importing individual >> APIs while applying the principles above during the review process for >> each proposed API. >> >> [1] - https://github.com/jkoelker/openstack-common >> >> >> ___ >> 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
Re: [Openstack] openstack-common
On Tue, 2012-01-03 at 19:54 +, Ewan Mellor wrote: > I'd love to see openstack-common get off the ground, so I'm all in > favor of this. > > One question: why do you feel that you need such strong backwards > compatibility? If someone makes a change in openstack-common and > makes simultaneous changes in all OpenStack projects to match, isn’t > that sufficient? No "simultaneous" change is ever actually simultaneous. We see this all the time with interop between keystone (in particular), nova, and glance. Once openstack-common gets into the picture, the interop problems stand to be significantly worse; if one tiny change is not backwards compatible, you break *everything* that uses openstack-common. The good thing, of course, is that it'll be noticed quickly; the bad thing is that all work gets significantly impeded until the fix(es) go in. Speaking from experience: it is possible to preserve N+2 backwards compatibility while still making major enhancements. It can be a pain in the butt sometimes, but it is doable, and, in cases like openstack-common, I think it is necessary. -- Kevin L. Mitchell ___ 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 and trusted computing
Hey Mark, I agree with the comments you have made on the merge prop so far, and I'm glad you've been working with the authors to find something more amenable. I'm all for keeping the responsibilities of nova small and adding plug-in points and extensibility to support these types of features. Vish On Jan 3, 2012, at 7:00 AM, Mark Washenberger wrote: > Nova folks, > > I have some concerns about the approach adopted in the trusted computing > blueprint > > https://blueprints.launchpad.net/nova/+spec/trusted-computing-pools > http://wiki.openstack.org/TrustedComputingPools > > Basically, the assumption of this blueprint is that Nova has to be > responsible for caching the "trust" status of hosts. In order to do this > without allowing hosts to lie to the scheduler, a long lived component must > be created. My sense is that this approach is too invasive and > inappropriately pushes responsibilities from the "trust" infrastructure into > Nova. > > I have been working with Fred Yang to try to address these concerns--and I'm > confident that Nova can adjust in a reasonable way to accommodate trusted > computing. However, the blueprint appears to have been approved with the > approach I don't like baked in, and I don't want to overstep. > > So I ask: Is there a consensus among nova-core that the approach given in the > blueprint needs to be changed? Or the other way around, is there a consensus > approving of this approach? > > Thanks > > > Mark Washenberger > Rackspace Hosting > Software Developer > mark.washenber...@rackspace.com > > > ___ > 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] Testing SSL?
I am looking at how others are testing SSL and was wondering if there is a suggested method to do this. For a submission I am doing for kombu enabling SSL, the code changes are mainly passing config down through kombu but I was wondering if there is a method (smoke test), unit test (does that make sense?) for ensuring that SSL is actually working as suggested. For this kombu change would it make sense to test that the kombu library passes the SSL config all the way through or is this more of testing kombu (which openstack doesn't seem like it should be getting in the business of)? This seems like a similar question that could be asked for other SSL changes others are doing, are they adding tests (smoke or unit) that ensure SSL got turned on or are they relying on the underlying implementation (ie apache, rabbitmq, kombu...) and just making sure the correct config is passed to that implementation? 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
[Openstack] various questinons about connections to rabbitmq
Hi all, Could someone explain what's the relation between the internal threading and number of rabbitmq connections that can exist on a single service? (in diablo final) I'm wondering under what circumstances can I get multiple connections from a single compute or network manager to the rabbitmq server when using kombu library? Can it use any connection pooling mechanism instead? I can see that it's not used by default, since there are multiple connections started from both of those services at the moment. The source of those questions is a strange thing I noticed where the number of open connections just keeps growing in my cluster, finally hitting open files limit on rabbitmq, ... which is a bad thing of course. From the network dump it seems that most "idle" requests are method:get_instance_nw_info and then service gets the response with addresses, bridges etc. correctly. But each connection like that just stays open for a long time. It seems that sometimes the number of connection spikes up much more than the average - but I didn't get the occasion to capture it. So far all compute and network services have between 1 and 3 connections open each. Did someone see this in their own environment and can give more details on this behavior? Regards, Stanisław Pitucha Cloud Services Hewlett Packard ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] [OpenStack] OpenStack with Xen
On 01/04/2012 01:05 AM, Guilherme Birk wrote:
> I've already have a Nova configuration working with kvm. Now I want to
> install and configure the Xen enviroment. Anyone can recomend any
> material or tutorial where I can find how to install, configure and then
> integrate with OpenStack ?
FYI, XCP has just been uploaded to Debian SID , so you might want to
have a try with it. But I have to warn you that there are few issues
that aren't yet fixed. Namely:
1/ XCP version reporting is broken. http://paste.debian.net/150865/ I
had to hack around. In
/usr/lib/python2.7/dist-packages/nova/virt/xenapi_conn.py, in the def
get_product_version(self):, I've just put: return (6, 10, 3) instead of
previously return tuple(int(part) for part in product_version.split('.'))
Note that upstream authors (Mike and Jon) are working on using
PLATFORM_VERSION instead of currently PRODUCT_VERSION so we have a real
fix, and not a hack as above.
2/ We need a python-xenapi package, which has already been worked out,
but this is still in the Git of alioth.debian.org, until 2/ is fixed.
Once we got this done, then nova-compute-xen can be built correctly.
3/ You'd better use both nova and xen-api from Alioth's Git, as there
are other fixes that haven't been uploaded to SID yet, but that I've
fixed already.
Last, I haven't yet succeed in having either console or network
connectivity in an instance. Hints would be welcome here (let's hope
I'll get more help from Citrix here...).
Last, I hope to find more people interested in running OpenStack with
XCP, and hope we can fix all the remaining issues together. :)
Cheers,
Thomas Goirand (zigo)
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] openstack-common
I'd love to see openstack-common get off the ground, so I'm all in favor of this. One question: why do you feel that you need such strong backwards compatibility? If someone makes a change in openstack-common and makes simultaneous changes in all OpenStack projects to match, isn’t that sufficient? Ewan. > -Original Message- > From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net > [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net] > On Behalf Of Mark McLoughlin > Sent: 03 January 2012 08:58 > To: openstack@lists.launchpad.net > Cc: Jason Koelker > Subject: [Openstack] openstack-common > > 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 > release N+2 > > There have been several attempts at kick-starting openstack-common, > each attempt > beginning with moving a number of existing APIs from Glance or Nova > into a new > repository. None of these attempts have quite managed to reach the > point where > they were ready for other OpenStack projects to depend on the library. > > This proposal marks the beginning of yet another attempt. The idea is > to create > a new openstack-common repository, seed it with Jason Kölker's > excellent > infrastructure from his repository[1] and begin importing individual > APIs while applying the principles above during the review process for > each proposed API. > > [1] - https://github.com/jkoelker/openstack-common > > > ___ > 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
The link below is for those platforms using the XenAPI toolstack - those are specifically Xen.org's Xen Cloud Platform (pure open-source project) and Citrix XenServer (Citrix product, albeit open-source and with a free edition). I can't get anyone in the habit of calling this option 'XenAPI' so you'll usually see it described as 'XenServer'. Platforms using the Xen hypervisor but not using the XenAPI toolstack (SUSE Linux, Oracle Enterprise Linux, RHEL / CentOS 5) can be used through libvirt, though you may need to do some hacking of your own to make that work. Ewan. From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net [mailto:openstack-bounces+ewan.mellor=citrix@lists.launchpad.net] On Behalf Of Joshua Harlow Sent: 03 January 2012 10:13 To: Brad Hall; Guilherme Birk Cc: openstack Subject: Re: [Openstack] [OpenStack] OpenStack with Xen So there is a naming convention that we need to get resolved here also. It confused me and probably confuses other. Is this for Xen (vanilla xen) or for XenServer (sometimes also called Xen)? Maybe in the future everyone can start specifying which they mean also, just for everyone's sanity. On 1/3/12 9:32 AM, "Brad Hall" wrote: There is one guide here: http://wiki.openstack.org/XenServerDevelopment Thanks, Brad On Jan 3, 2012, at 9:05 AM, Guilherme Birk wrote: > I've already have a Nova configuration working with kvm. Now I want to > install and configure the Xen enviroment. Anyone can recomend any material or > tutorial where I can find how to install, configure and then integrate with > OpenStack ? > ___ > 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] Problems with run_tests.sh on 11.10
On 01/03/2012 11:41 AM, Soren Hansen wrote: > 2012/1/2 Monty Taylor : >> Do you think someone would be willing to accept that patch? Or should we >> make our own branch with the patch applied and reference that in the >> pip-requires? > > If this is something we want to use for anything half serious, I think > we should create a branch of our own (or pester upstream hard enough > that they finally get around to fixing it). > Ok. I will do both of those things. The patch I've got now should be something that upstream should apply, as it fixes the problem as well as the problem is going to get fixed given the tooling. Monty ___ 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] Problems with run_tests.sh on 11.10
2012/1/2 Monty Taylor : > Do you think someone would be willing to accept that patch? Or should we > make our own branch with the patch applied and reference that in the > pip-requires? If this is something we want to use for anything half serious, I think we should create a branch of our own (or pester upstream hard enough that they finally get around to fixing it). -- 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] Do we really need a CLA? [was Re: Using Gerrit to verify the CLA]
On Tue, Jan 3, 2012 at 7:02 AM, Rick Clark wrote: > > 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. Good to know. > 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. Fun, fun, fun. I seem to recall jQuery having some growing pains where they had to after-the-fact start doing CLA. Might be worth talking to them, if there gets to be some momentum behind reconsidering CLAs. Oregon State University Open Source Lab has a lot of knowledge around CLA options, and they have the http://www.harmonyagreements.org project. ___ 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] Tempita usage?
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: 1. 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?) 2. 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) 3. 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). 4. Write output created by formatter class to domain.xml file (and continue as normal). 5. Profit! Some of the benefits I think exist with this: 1. XML escaping will actually happen (does this happen right now?) 2. 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) 3. 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). 4. 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). 5. 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). 6. 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
Re: [Openstack] Multinode installation (with devstack on the master)
Hey Sagar,
Are you able to produce logs from n-cpu? If you are in the screen session,
you should be able to switch to the window (ctrl-a + [number]) of that name
and use ctrl-a + [ to enable interactive scrollback (uses vim keybindings).
I think there is a chance that some data from a previous run could have
been left in your instances directory, which might cause launch errors. It
is possible that glance is part of the problem, but I can't tell for sure
without more info.
Anthony
On Sun, Jan 1, 2012 at 7:56 AM, Frost Dragon wrote:
> Hi,
> Regarding the error I described in my previous post, I ran 'screen -r'
> and switched to the g-api screen. I found this message being displayed:
>
> 2012-01-01 10:43:22DEBUG [eventlet.wsgi.server] Traceback (most
>> recent call last):
>> File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 351, in
>> handle_one_response
>> write(''.join(towrite))
>> File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 301, in
>> write
>> _writelines(towrite)
>> File "/usr/lib/python2.7/socket.py", line 334, in writelines
>> self.flush()
>> File "/usr/lib/python2.7/socket.py", line 303, in flush
>> self._sock.sendall(view[write_offset:write_offset+buffer_size])
>> File "/usr/lib/python2.7/dist-packages/eventlet/greenio.py", line 307,
>> in sendall
>> tail = self.send(data, flags)
>> File "/usr/lib/python2.7/dist-packages/eventlet/greenio.py", line 286,
>> in send
>> total_sent += fd.send(data[total_sent:], flags)
>> error: [Errno 104] Connection reset by peer
>> 2012-01-01 10:43:22DEBUG [eventlet.wsgi.server] 10.2.0.1 - -
>> [01/Jan/2012 10:43:22] "GET /v1/images/2 HTTP/1.1" 200 66288 0.123545
>> Traceback (most recent call last):
>> File "/usr/lib/python2.7/dist-packages/eventlet/greenpool.py", line 80,
>> in _spawn_n_impl
>> func(*args, **kwargs)
>> File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 514, in
>> process_request
>> proto = self.protocol(socket, address, self)
>> File "/usr/lib/python2.7/SocketServer.py", line 641, in __init__
>> self.finish()
>> File "/usr/lib/python2.7/dist-packages/eventlet/wsgi.py", line 456, in
>> finish
>> BaseHTTPServer.BaseHTTPRequestHandler.finish(self)
>> File "/usr/lib/python2.7/SocketServer.py", line 694, in finish
>> self.wfile.flush()
>> File "/usr/lib/python2.7/socket.py", line 303, in flush
>> self._sock.sendall(view[write_offset:write_offset+buffer_size])
>> File "/usr/lib/python2.7/dist-packages/eventlet/greenio.py", line 307,
>> in sendall
>> tail = self.send(data, flags)
>> File "/usr/lib/python2.7/dist-packages/eventlet/greenio.py", line 286,
>> in send
>> total_sent += fd.send(data[total_sent:], flags)
>> error: [Errno 32] Broken pipe
>>
>
> A bit of googling led me to this thread:
> https://bugs.launchpad.net/horizon/+bug/862664 So is horizon the cause of
> this problem? I'm using stable/diablo from devstack right now. I can't find
> this glance.py file within the horizon folder in /opt/stack.
>
> Thanks and Regards,
> Sagar
>
>
___
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
http://docs.vmd.citrix.com/ http://www.citrix.com/English/ps2/products/feature.asp?contentID=2300356 Get the free version - you don't need any of the paid features to run OpenStack. Or alternatively, if you want to do everything from the source upwards (lots of work, but obviously great if you want to know how it all goes together): http://xen.org/products/cloudxen.html Cheers, Ewan. From: Guilherme Birk [mailto:guib...@hotmail.com] Sent: 03 January 2012 10:14 To: Ewan Mellor Subject: RE: [Openstack] [OpenStack] OpenStack with Xen Yes, I'm already looking at this. But i think that to use this tutorial I already need a XenServer configured. I'm gonna look for this now. Thanks for your help ! From: ewan.mel...@eu.citrix.com To: guib...@hotmail.com; openstack@lists.launchpad.net Date: Tue, 3 Jan 2012 18:05:06 + Subject: RE: [Openstack] [OpenStack] OpenStack with Xen 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
Re: [Openstack] Openstack configuration with single interface and with external dhcp
Hi, try to put eth0 on network host in promiscuous mode: ifconfig eth0 promisc Cheers! :) On Tue, Jan 3, 2012 at 3:45 PM, Rasika Karunathilaka < rasika.karunathil...@gmail.com> wrote: > > Team, > I need to configure Openstack on private vlan where DHCP ips are pushed > from external DHCP server to the private vlan. I don't have control over > DHCP or the network and I want to setup Openstack on my vlan. Further the > two boxes I got have only single interface on each. Is this setup possible > ? as I am struggling with this setup for about two weeks now, can you > please provide a guide. > Right now I have set it up with FlatDHCP where both machines are having > br100 on eth0. Further, network_host is pointed to nova-network machine. > DHCP is initiated on 192.168.104.255 range on br100 ( Fixed IP range). I > have configured 10 floating ips on openstack,which are given by external > DHCP. When a VM start on Network host machine I could assign floating ip to > an instance then that instance is accessible from other machines on our > dhcp network, But when the vm is booted on other compute machine, I can't > access it from public network. But I could access the vm from nova-network > host machine using both public and private ip, Can you please help me on > this ? > > Cheers! > Rasika > > > ___ > Mailing list: https://launchpad.net/~openstack > Post to : openstack@lists.launchpad.net > Unsubscribe : https://launchpad.net/~openstack > More help : https://help.launchpad.net/ListHelp > > -- - MSc. Correa, J.L. ___ 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
So there is a naming convention that we need to get resolved here also. It confused me and probably confuses other. Is this for Xen (vanilla xen) or for XenServer (sometimes also called Xen)? Maybe in the future everyone can start specifying which they mean also, just for everyone's sanity. On 1/3/12 9:32 AM, "Brad Hall" wrote: There is one guide here: http://wiki.openstack.org/XenServerDevelopment Thanks, Brad On Jan 3, 2012, at 9:05 AM, Guilherme Birk wrote: > I've already have a Nova configuration working with kvm. Now I want to > install and configure the Xen enviroment. Anyone can recomend any material or > tutorial where I can find how to install, configure and then integrate with > OpenStack ? > ___ > 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] Problems with run_tests.sh on 11.10
On 01/03/2012 12:11 AM, Mark McLoughlin wrote: > On Mon, 2012-01-02 at 12:50 +0100, Soren Hansen wrote: >> 2011/12/30 John Griffith : >>> Oops, sorry about that. Forgot to check it in the venv, which reveals the >>> issue: >>> >>> % tools/with_venv.sh >>> jdg@grumpy ~/Projects/OpenStack/nova >>> % python >>> Python 2.7.2+ (default, Oct 4 2011, 20:06:09) >>> [GCC 4.6.1] on linux2 >>> Type "help", "copyright", "credits" or "license" for more information. >> import M2Crypto >>> Traceback (most recent call last): >>> File "", line 1, in >>> File "/usr/local/lib/python2.7/dist-packages/M2Crypto/__init__.py", line >>> 22, in >>> import __m2crypto >>> ImportError: /usr/local/lib/python2.7/dist-packages/M2Crypto/__m2crypto.so: >>> undefined symbol: SSLv2_method >> >> >> Ah, yes. That's because M2Crypto hasn't kept up wit the removal of >> SSLv2 from OpenSSL. >> >> It's fixed in the Ubuntu packages, so if you remove the M2Crypto line >> from pip-requires and put this instead: >> >> -e >> bzr+http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/m2crypto/precise/#egg=M2Crypto >> >> You should be fine. (Yes, the line in pip-requires should start with >> "-e") > > In Nova, install_venv.py just uses the system M2Crypto package on Fedora > rather than pip installing it. > > I think that makes most sense - consider it a system library which we > prefer to use from the underlying distro rather than from PyPi. The problem I have with that, actually, is that install_venv.py in some cases winds up installing something to the system as a whole, which is not advertised and might be surprising to a user. I'm sure we could go back and forth on that though, and I totally hear the arguments on the other side. However - I do have a patch which works across ubuntu and fedora just fine. I'm going to do my best to get it upstreamed (since I would hope that M2Crypto would want a pip install of their code to work) In the mean time, figuring out the best place to put it is one of my tasks for today. Monty ___ 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
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
[Openstack] Openstack configuration with single interface and with external dhcp
Team, I need to configure Openstack on private vlan where DHCP ips are pushed from external DHCP server to the private vlan. I don't have control over DHCP or the network and I want to setup Openstack on my vlan. Further the two boxes I got have only single interface on each. Is this setup possible ? as I am struggling with this setup for about two weeks now, can you please provide a guide. Right now I have set it up with FlatDHCP where both machines are having br100 on eth0. Further, network_host is pointed to nova-network machine. DHCP is initiated on 192.168.104.255 range on br100 ( Fixed IP range). I have configured 10 floating ips on openstack,which are given by external DHCP. When a VM start on Network host machine I could assign floating ip to an instance then that instance is accessible from other machines on our dhcp network, But when the vm is booted on other compute machine, I can't access it from public network. But I could access the vm from nova-network host machine using both public and private ip, Can you please help me on this ? Cheers! Rasika ___ 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
There is one guide here: http://wiki.openstack.org/XenServerDevelopment Thanks, Brad On Jan 3, 2012, at 9:05 AM, Guilherme Birk wrote: > I've already have a Nova configuration working with kvm. Now I want to > install and configure the Xen enviroment. Anyone can recomend any material or > tutorial where I can find how to install, configure and then integrate with > OpenStack ? > ___ > 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] Several questions about HOW SWIFT WORKS
Hi everyone ! Since we are using swift for a time now, we would like to know a few things in a deep way about how some things actually works in SWIFT. Imagine the setup where im putting all the doubts is as follow : + 2 proxyNodes + 10 dataNodes ( 5 zones ) So, lets get down to business. # 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 ( PUT , GET) enters the proxy, but for example, if we restart one proxy server, so the memcached service is empty, is the restarted proxy node going to the neighbor memcache on nex request, lookup for what it needs, and cache the answer on itself so the next query is solved locally ? # 2 the documentation says regarding "For each request, it will look up the location of the account, container, or object in the ring (see below) and route the request accordingly" in what way the proxy actually does the look-up regarding WHERE is an object / container in the cluster ? does it connect to any datanode asking for an object location ? does the proxy have any locally sotarge data ?? # 3 Maybe it has to do with the previous question but, every dataNode knows everything that is stored on the cluster (container service) or only knows the object that has itself, and the replicas of its objects? # 4 We are building a production cluster of 24 datanodes, having 6 drives each (144 immediate drives) we know, that a good default number of partitions per drive is 100, so the math for creating the ring will be (24 nodes * 6 drives * 100 partitions) but we know the at the end of the year, the amount of datanodes (and drives also) could be 2x or 3x more. So, for the initial setup, can we build the RING with our 144 drives and 100 partitions per drive so we can modify the ring / partitions later and rebalance? or is safer to think about future infrastructure increase, and build the ring with those numbers in mind ? # 5 We put a new object into the cluster, the proxy decides where to write the object (is it in a round-robin manner ?) is the proxy server giving a "Created" response when the 1st replica is actually writen and put into the account and container SQLite databases ? or there is and ok just when the OBJECT service actually wrote the data on disc ? Hope, we can shed some lights regarding this doubts. Thanks ! Cheers. -- Alex ___ 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] Metadata and File Injection
> I can't tell you how to run your business. All I know is that if a > client of mine gave me a functional requirement specification that > would > be perfectly met by DHCP, but they had a piece of paper from the > mid-90's that said "DHCP isn't allowed. Just because." on which they > refused to budge, I'd pass on the contract. I personally don't want to > facilitate stupid policies. That's my policy. I love the happy world you live in. Selling to enterprises is 80% working around idiotic policies made in the mid-90s. This is entirely my point. I don't care that you could engineer the system in different ways. So could I. None of that is going to change the policies that people have in place, so if OpenStack is going to be used outside of green-field deployments, then it's going to have to be flexible in the ways that it works. > > Regardless of those four, your one seems like a complete deal-breaker > > to me. If that's true (and it's not something that I'm aware of one > > way or another) then we shouldn't even be having this discussion. We > > can't build a solution that can't reliably configure Windows VMs. > > a) I don't think we should generally limit ourselves to whatever > Windows > can support. I didn't say that we should. I said that we have to have a system that can support Windows guests. That doesn't mean that we can't have a richer system for other OSs. This thread started with the proposal that we should remove non-DHCP support. I say that that is infeasible (regardless of the Windows issue). I didn't say that we can't have richer systems that rely on DHCP -- we totally can. We have to support both though. Ewan. ___ 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] 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
[Openstack] openstack-common
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 release N+2 There have been several attempts at kick-starting openstack-common, each attempt beginning with moving a number of existing APIs from Glance or Nova into a new repository. None of these attempts have quite managed to reach the point where they were ready for other OpenStack projects to depend on the library. This proposal marks the beginning of yet another attempt. The idea is to create a new openstack-common repository, seed it with Jason Kölker's excellent infrastructure from his repository[1] and begin importing individual APIs while applying the principles above during the review process for each proposed API. [1] - https://github.com/jkoelker/openstack-common ___ 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] Attempting to start up swift-proxy and failing on startup
Thanks Chmouel that did the trick!
--
Best Regards,
JJ Asghar
From: launch...@chmouel.com [mailto:launch...@chmouel.com] On Behalf Of Chmouel
Boudjnah
Sent: Tuesday, January 03, 2012 1:28 AM
To: Asghar, Jonathan Edward (HP Cloud Services NOC)
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Attempting to start up swift-proxy and failing on
startup
Hi,
You won't need the default_swift_cluster setting usually comment it and your
swift cluster should start. if you really do then the format specified is
incorrect, look at the commented config file here :
https://github.com/gholt/swauth/blob/master/etc/proxy-server.conf-sample#L43
Cheers,
Chmouel.
On Tue, Jan 3, 2012 at 3:40 AM, Asghar, Jonathan Edward (HP Cloud Services NOC)
mailto:jonathan.asg...@hp.com>> wrote:
Hi, I was attempting to start up a swift proxy on a test environment and it
seems I'm running into a wall. My object-nodes are working fine from what I
can see but it seems that my proxy won't start at all.
The error I get starting it up is this:
root@proxy:~# swift-init proxy start
Starting proxy-server...(/etc/swift/proxy-server.conf)
Traceback (most recent call last):
File "/usr/bin/swift-proxy-server", line 22, in
run_wsgi(conf_file, 'proxy-server', default_port=8080, **options)
File "/usr/lib/python2.7/dist-packages/swift/common/wsgi.py", line 123, in
run_wsgi
loadapp('config:%s' % conf_file, global_conf={'log_name': log_name})
File "/usr/lib/pymodules/python2.7/paste/deploy/loadwsgi.py", line 204, in
loadapp
return loadobj(APP, uri, name=name, **kw)
File "/usr/lib/pymodules/python2.7/paste/deploy/loadwsgi.py", line 225, in
loadobj
return context.create()
File "/usr/lib/pymodules/python2.7/paste/deploy/loadwsgi.py", line 625, in
create
return self.object_type.invoke(self)
File "/usr/lib/pymodules/python2.7/paste/deploy/loadwsgi.py", line 168, in
invoke
app = filter(app)
File "/usr/lib/pymodules/python2.7/swauth/middleware.py", line 1463, in
auth_filter
return Swauth(app, conf)
File "/usr/lib/pymodules/python2.7/swauth/middleware.py", line 123, in
__init__
raise Exception('Invalid cluster format')
Exception: Invalid cluster format
My proxy-server.conf is as follows:
root@proxy:~# cat /etc/swift/proxy-server.conf
[DEFAULT]
bind_port = 443
cert_file = /etc/swift/cert.crt
key_file = /etc/swift/cert.key
workers = 8
user = swift
[pipeline:main]
pipeline = healthcheck cache swauth proxy-server
#pipeline = healthcheck cache auth proxy-server
[app:proxy-server]
use = egg:swift#proxy
allow_account_management = true
[filter:swauth]
use = egg:swauth#swauth
set log_name = swauth
super_admin_key = swauthkey
default_swift_cluster = https://10.0.0.2:443/v1
#[filter:auth]
#use = egg:swift#auth
#ssl = true
[filter:healthcheck]
use = egg:swift#healthcheck
[filter:cache]
use = egg:swift#memcache
memcache_servers = 10.7.11.9:11211
root@proxy:~#
I've done the googling on this, and it looks like most people have trouble with
the auth part, it's either "uth" or "sauth" or "wauth" when it should be
"swauth." As you can see I've tried both (the commented line) but my goal is
swauth so I'm asking with this configuration.
Any advice or direction would be greatly appreciated! Thanks!
--
Best Regards,
JJ Asghar
HP Cloud Services
512-619-0722 - Cell
___
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] Do we really need a CLA? [was Re: Using Gerrit to verify the CLA]
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. 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. 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. 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. 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 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
[Openstack] nova and trusted computing
Nova folks, I have some concerns about the approach adopted in the trusted computing blueprint https://blueprints.launchpad.net/nova/+spec/trusted-computing-pools http://wiki.openstack.org/TrustedComputingPools Basically, the assumption of this blueprint is that Nova has to be responsible for caching the "trust" status of hosts. In order to do this without allowing hosts to lie to the scheduler, a long lived component must be created. My sense is that this approach is too invasive and inappropriately pushes responsibilities from the "trust" infrastructure into Nova. I have been working with Fred Yang to try to address these concerns--and I'm confident that Nova can adjust in a reasonable way to accommodate trusted computing. However, the blueprint appears to have been approved with the approach I don't like baked in, and I don't want to overstep. So I ask: Is there a consensus among nova-core that the approach given in the blueprint needs to be changed? Or the other way around, is there a consensus approving of this approach? Thanks Mark Washenberger Rackspace Hosting Software Developer mark.washenber...@rackspace.com ___ 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 Swift S3 API with Keystone
See http://wiki.openstack.org/GerritWorkflow On Jan 3, 2012, at 8:11, Akira Yoshiyama wrote: Hi, I hope to merge my patches to upstream. What should I do? Thank you, Akira Yoshiyama 2012/01/03 21:32 : > Is it possible to use Swift’s S3 API if Keystone is being used for auth?** > ** > > ** ** > > Looking back at this thread ( > https://lists.launchpad.net/openstack/msg05203.html) it appears Akira > Yoshiyama has a patch to allow this functionality but it’s not been merged > (submitted?) yet. Is there an alternative? > > ** ** > > Thanks > > ** ** > > Adrian > > > > ___ > 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] Using Swift S3 API with Keystone
Hi Akira: See the following wiki pages for info on how to contribute patches: - http://wiki.openstack.org/HowToContribute - http://wiki.openstack.org/GerritWorkflow Take care, Lorin -- Lorin Hochstein, Computer Scientist USC Information Sciences Institute 703.812.3710 http://www.east.isi.edu/~lorin On Jan 3, 2012, at 7:47 AM, Akira Yoshiyama wrote: > Hi, > > I hope to merge my patches to upstream. What should I do? > > Thank you, > Akira Yoshiyama > > 2012/01/03 21:32 : > Is it possible to use Swift’s S3 API if Keystone is being used for auth? > > > > Looking back at this thread > (https://lists.launchpad.net/openstack/msg05203.html) it appears Akira > Yoshiyama has a patch to allow this functionality but it’s not been merged > (submitted?) yet. Is there an alternative? > > > > Thanks > > > > Adrian > > > > ___ > 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] Integration test gating on trunk
Mark McLoughlin wrote: > There were quite a few issues with gating the stable branch just before > the holidays and it took a while to work through them. Meanwhile, the > commits were blocked from merging. That's not such a big deal for the > stable branch since it only really affected me, but it's a different > story with master. That was indeed annoying, but I think most issues were fixed on that occasion. In all cases, I realistically expect false negatives to pop up whenever we turn that on, and the start of essex-3 sounds like the right point in time to turn that on and bear the consequences (end of essex-3 would suck, essex-4 or later would suck). So my USD0.02 go to enabling it ASAP. And schedule plenty of time for express fixes in CI in the next week(s) :) -- 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] [Glance] Decision to defer 2.0 Images API implementation to F release series
Jay Pipes wrote: > Happy New Year, Stackers! > > This is a quick note to announce that I made the decision over the > last week to defer implementation of the proposed OpenStack Images API > 2.0 [1] in Glance to the "F" release series (Foxtrot?). +1! It's clear you can't complete it with the Essex time remaining, and better spend it working on stability and consistency rather than introducing entropy in an incomplete implementation :) PS: F naming contest will start as soon as we have the final location for the next design summit. -- 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
[Openstack] unsubscribe
-- Mr. Jeffrey Courtade P: 240.342.6745 Veteran of a Thousand Psychic Wars. Janitor Extraordinaire Specializing in Sky hooks, Anti-gravity Jacks, Accretion disk navigation and singularity elimination. ___ 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] Automatically confirmed after 24 hours on Resize API
Created https://bugs.launchpad.net/nova/+bug/911217 to track the issue, please comment there. -- 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] openstack nova-comoute boot instance error (diablo)
Pádraig Brady wrote: > On 12/24/2011 03:47 AM, darkfower wrote: >> hi,everybody: >> >> when i new create a kvm instance , error as flollow: >> >> >> 2011-12-24 11:45:17,937 INFO nova.virt.libvirt_conn [-] Instance >> instance-0001 spawned successfully. >> 2011-12-24 11:45:18,126 ERROR nova.exception [-] DB exception wrapped. >> (nova.exception): TRACE: Traceback (most recent call last): >> (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 >> "/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: >> 2011-12-24 11:45:18,140 WARNING nova.compute.manager [-] Error during >> power_state sync: exceptions must be old-style classes or derived from >> BaseException, not NoneType > > I've seen this due to greenthread clearing the exception, > thus None is reraised, rather than the original exception. > nova.utils.save_and_reraise_exception() was created to avoid this, > so perhaps there is a missing use of this? Could you please file a bug (with details like version used) about this at: https://bugs.launchpad.net/nova/+filebug Mailing-lists make awful bug trackers. -- 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] Using Swift S3 API with Keystone
Hi, I hope to merge my patches to upstream. What should I do? Thank you, Akira Yoshiyama 2012/01/03 21:32 : > Is it possible to use Swift’s S3 API if Keystone is being used for auth?** > ** > > ** ** > > Looking back at this thread ( > https://lists.launchpad.net/openstack/msg05203.html) it appears Akira > Yoshiyama has a patch to allow this functionality but it’s not been merged > (submitted?) yet. Is there an alternative? > > ** ** > > Thanks > > ** ** > > Adrian > > > > ___ > 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] Reminder: OpenStack Project meeting - 21:00 UTC
Hello everyone, Happy new year to everyone in the OpenStack community ! 2011 was the year of OpenStack explosive growth. Let's all make 2012 the year of OpenStack usability and ubiquity! Our weekly project & release status meeting will take place at 21:00 UTC this Tuesday in #openstack-meeting on IRC. PTLs, if you can't make it, please name a substitute on [2]. This is the "back to work" meeting: we'll look at Essex-3 status and each PTL will remind everyone of the coming deadlines and priorities. You can doublecheck what 21:00 UTC means for your timezone at [1]: [1] http://www.timeanddate.com/worldclock/fixedtime.html?iso=20120103T21 See the meeting agenda, edit the wiki to add new topics for discussion: [2] http://wiki.openstack.org/Meetings/ProjectMeeting (new URL!) Cheers, -- 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
[Openstack] Do we really need a CLA? [was Re: Using Gerrit to verify the CLA]
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
[Openstack] Using Swift S3 API with Keystone
Is it possible to use Swift's S3 API if Keystone is being used for auth? Looking back at this thread (https://lists.launchpad.net/openstack/msg05203.html) it appears Akira Yoshiyama has a patch to allow this functionality but it's not been merged (submitted?) yet. Is there an alternative? Thanks Adrian ___ 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] Metadata and File Injection
2012/1/2 Ewan Mellor : >> > In the context of this discussion, that means that OpenStack needs >> > to work in DHCP-free environments, because we already know of many. >> The only one I'm familiar with is Rackspace where I think (and please >> do correct me if I'm wrong) DHCP isn't used only because Windows >> instances can't be configured with DHCP if they have multiple >> interfaces. > DHCP may be forbidden because: > * it has been deemed less reliable than pushing fixed IP addresses > from an asset database. If you already have a comprehensive asset > database, why push the addresses to a DHCP server to have it push them > to your hosts when you can push them to the host directly? Because Nova isn't likely to interface with your asset database. It maintains has its own database for these things. Also, how do you push something from an asset database, if you don't have network connectivity? > * it has been deemed less reliable than pushing addresses from the > virt layer. By whom and for what reasons? Every single operating system of any relevance at all understands DHCP. It's an extremely widely used system. It may not be perfect, but that will hold true for any replacement we decide to build. You'll simply be replacing the bugs, problems and idiosyncracies with a different set of bugs, problems and idiosyncracies. > Why go to the effort of making a DHCP service highly available, and > making sure that the failover is quicker than the timeout that causes > guests to decide to take zeroconf addresses instead? Just set the lease time to a couple of weeks. If you can't manage to fix a dead dnsmasq within that timeframe, that's probably the least of your problems. > * it has been deemed a security risk. Compromising the DHCP server > gives you all sorts of easy attacks. The DHCP server runs on the network controller. If your network controller is compromised, you're pretty screwed anyway, afaics. > This one actually seems like a very reasonable concern in the case of > tenant networks in a cloud. Pushing the address from the virt layer > takes away that attack vector altogether. ...and replaces it with another. > * the guy who is installing the cloud doesn't control the network, and > so the DHCP server isn't his and/or he's not allowed to run one of his > own. This seems likely in an academic environment or pilots within an > enterprise. a) This isn't a reason. It's just repeating the original non-problem: "it's not allowed". b) There are several ways in which we can ensure that our DHCP stuff doesn't bleed into the rest of the network. dnsmasq already won't respond to requests from mac addresses that it doesn't know about, but if that isn't good enough (why would this be? what's so darned special about dhcp requests anyway?), we can add extra strict filtering in a couple of places. > Note that none of these has to be specifically a decision about > OpenStack or clouds in general. They might just be blanket policies > from simpler times. That doesn't make them any easier to change. I can't tell you how to run your business. All I know is that if a client of mine gave me a functional requirement specification that would be perfectly met by DHCP, but they had a piece of paper from the mid-90's that said "DHCP isn't allowed. Just because." on which they refused to budge, I'd pass on the contract. I personally don't want to facilitate stupid policies. That's my policy. > Regardless of those four, your one seems like a complete deal-breaker > to me. If that's true (and it's not something that I'm aware of one > way or another) then we shouldn't even be having this discussion. We > can't build a solution that can't reliably configure Windows VMs. a) I don't think we should generally limit ourselves to whatever Windows can support. (Much like how I don't think we should have a hard dependency on hypervisors that have a Xenstore-like backdoor into the guest) b) I don't think I've heard any reason why we couldn't just configure one of the NIC's over DHCP, and then fetch the remaining network config from a network-connected metadata service. -- 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] Using Gerrit to verify the CLA
On Fri, 2011-12-30 at 09:41 -0800, James E. Blair wrote: > In short, the process for new developers will be: > > 1) Sign CLA via Echosign > 2) Record signature in wiki > 3) Apply for membership in openstack-cla > 4) Contribute! > > With only step 3 being added by this change. > > I'd like to enable this check on Thursday, January 5th. Please make > sure you have signed the CLA and entered your name on the wiki page by > then: > > http://wiki.openstack.org/HowToContribute > http://wiki.openstack.org/Contributors Nice work. Do you have a sense of how many past contributors haven't signed the CLA or added themselves to the wiki? Also, how does this work for the corporate CLA? 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] Integration test gating on trunk
Hi James, On Thu, 2011-12-29 at 14:51 -0800, James E. Blair wrote: > 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. There were quite a few issues with gating the stable branch just before the holidays and it took a while to work through them. Meanwhile, the commits were blocked from merging. That's not such a big deal for the stable branch since it only really affected me, but it's a different story with master. Do you feel those issues were one-offs and we won't see similar issues again? How about leaving it for another week and seeing how many issues crop up? Bear in mind that, from your perspective, each might be fairly minor and fixed quickly, but if it means other folks struggling to figure out what's going on for half a day, that will get old quickly. Maybe my concern is really that the number of people who can fix issues is quite small - with the stable branch issues it seemed to be one of you, Monty or Jesse - and it's not always even very clear whether the issue is with one's commit or tests themselves. 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] Problems with run_tests.sh on 11.10
On Mon, 2012-01-02 at 12:50 +0100, Soren Hansen wrote: > 2011/12/30 John Griffith : > > Oops, sorry about that. Forgot to check it in the venv, which reveals the > > issue: > > > > % tools/with_venv.sh > > jdg@grumpy ~/Projects/OpenStack/nova > > % python > > Python 2.7.2+ (default, Oct 4 2011, 20:06:09) > > [GCC 4.6.1] on linux2 > > Type "help", "copyright", "credits" or "license" for more information. > import M2Crypto > > Traceback (most recent call last): > > File "", line 1, in > > File "/usr/local/lib/python2.7/dist-packages/M2Crypto/__init__.py", line > > 22, in > > import __m2crypto > > ImportError: /usr/local/lib/python2.7/dist-packages/M2Crypto/__m2crypto.so: > > undefined symbol: SSLv2_method > > > Ah, yes. That's because M2Crypto hasn't kept up wit the removal of > SSLv2 from OpenSSL. > > It's fixed in the Ubuntu packages, so if you remove the M2Crypto line > from pip-requires and put this instead: > > -e > bzr+http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/precise/m2crypto/precise/#egg=M2Crypto > > You should be fine. (Yes, the line in pip-requires should start with > "-e") In Nova, install_venv.py just uses the system M2Crypto package on Fedora rather than pip installing it. I think that makes most sense - consider it a system library which we prefer to use from the underlying distro rather than from PyPi. 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
