Re: [Openstack] null ring gz files?

2011-06-03 Thread Andiabes
Curious to know what is this empty ring useful for Sent from my iPad On Jun 3, 2011, at 7:49 PM, Jon Slenk wrote: > hi, > > solution: don't get confused/mislead into trying "rebalance". just do > "write_ring". > > thanks. > > ___ > Mailing list

Re: [Openstack] null ring gz files?

2011-06-03 Thread Jon Slenk
hi, solution: don't get confused/mislead into trying "rebalance". just do "write_ring". thanks. ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help :

[Openstack] null ring gz files?

2011-06-03 Thread Jon Slenk
hi, I haven't found a way to do this, I suspect it isn't supported -- is there a way to have a null/zero/empty ring? (I realize it probably isn't The Right Way to do things, but it would be possibly awfully expediently helpful just now. :-) thanks. ___

Re: [Openstack] nova.sh behind a firewall

2011-06-03 Thread Andy Bierman
oops - that is the wrong link. here is the essence... [install python-software-properties, then these steps, then ./nova.sh install] 1.gedit /usr/lib/python2.6/dist-packages/softwareproperties/ppa.py 2.Find line 88, change "keyserver.ubuntu.com" to "

Re: [Openstack] XML and JSON for API's

2011-06-03 Thread Bryan Taylor
Format wars are so tiring. What formats we Openstack should output is a marketing question, not a technical one. We should be trying to figure out how to do more formats, not fewer, because customers don't want us making choices that place constraints on them, especially when those are tied to

[Openstack] nova.sh behind a firewall

2011-06-03 Thread Andy Bierman
Hi, Not sure anybody else ran into this problem installing nova, but if add-apt-repository is timing out, your firewall is probably blocking port 11371. Try this: http://superuser.com/questions/64922/how-to-work-around-blocked-outbound-hkp-port-for-apt-keys Andy _

Re: [Openstack] Feedback on HTTP APIs

2011-06-03 Thread Thorsten von Eicken
Really? The way I understand it, when I retrieve resource X I will get a bookmark link for X. But when I retrieve resource Y that happens to have a reference to X this references will not include the bookmark link for X, it will just include X's URL. I'd then have to ret

Re: [Openstack] swauth_novaldap released

2011-06-03 Thread Greg Holt
Very, very cool! Just curious, what's the reason for the account, user -> user, account switch in swift3.py? On Jun 3, 2011, at 9:25 AM, Akira YOSHIYAMA wrote: > Hi Stackers, > > I'm pleased to announce swauth_novaldap, an auth-n/z driver for Swift > to use Nova user/profile data in LDAP. > >

[Openstack] swauth_novaldap released

2011-06-03 Thread Akira YOSHIYAMA
Hi Stackers, I'm pleased to announce swauth_novaldap, an auth-n/z driver for Swift to use Nova user/profile data in LDAP. http://www.debian.or.jp/~yosshy/swauth_novaldap/ swauth_novaldap has 2 benefits: * Nova and Swift share their user and group information. * Swift can use LDAP as a s

Re: [Openstack] XML and JSON for API's

2011-06-03 Thread James Weir
Perfect...can't ask for more than that. One extra thing is IF we decide to support XML, then it would be nice to also support gzip-compressed, allowing the XML to be compressed when sent - this helps save some bandwidth ;) This is usually supported in most application/web servers when sendin

Re: [Openstack] Feedback on HTTP APIs

2011-06-03 Thread Mark Washenberger
I do not intend to suggest any disagreement on my part. In fact, I'm very happy for Thorsten's input here to help motivate this feature. However: > Looks like the > implementation hasn't yet added support for that, but it will. Aren't we being a bit presumptuous? "Jorge Williams" said: >

Re: [Openstack] XML and JSON for API's

2011-06-03 Thread James Weir
No objections. -- James On 6/3/11 3:52 PM, Ed Leafe wrote: On Jun 3, 2011, at 9:23 AM, James Weir wrote: Reading through the thread, I completely agree with the reasons why from a technical perspective OpenStack would wish to support JSON over XML. I do prefer JSON, however, as George (Re

Re: [Openstack] XML and JSON for API's

2011-06-03 Thread Jorge Williams
On Jun 2, 2011, at 10:41 PM, Mark Nottingham wrote: > The problem I mentioned before, though, is that XML Schema brings more issues > to the table than it solves. > > 1) People inevitably use schema to generate bindings to [insert language], > and because of the complexity of the underlying da

Re: [Openstack] XML and JSON for API's

2011-06-03 Thread Ed Leafe
On Jun 3, 2011, at 9:23 AM, James Weir wrote: > Reading through the thread, I completely agree with the reasons why from a > technical perspective OpenStack would wish to support JSON over XML. I do > prefer JSON, however, as George (Reese) mentioned there are a lot of people > still wishing t

Re: [Openstack] XML and JSON for API's

2011-06-03 Thread Jay Pipes
On Fri, Jun 3, 2011 at 9:23 AM, James Weir wrote: > At the very minimum until/if OpenStack supports XML, when I client wishes to > receive media type "application/xml" OpenStack should return a: > > HTTP: 415 response > The server is refusing to service the request because the entity of the > requ

Re: [Openstack] XML and JSON for API's

2011-06-03 Thread James Weir
Hi All, Reading through the thread, I completely agree with the reasons why from a technical perspective OpenStack would wish to support JSON over XML. I do prefer JSON, however, as George (Reese) mentioned there are a lot of people still wishing to parse XML. To continue OpenSTack adoption

Re: [Openstack] XML and JSON for API's

2011-06-03 Thread Jay Pipes
Glance will Accept XML content types as soon as we have users demanding such. One such user, James Weir from uShareSoft, created a blueprint on May 20th for it: https://blueprints.launchpad.net/glance/+spec/glance-xml Recently, the folks on the Titan team have been working on refactoring the XML

Re: [Openstack] Feedback on HTTP APIs

2011-06-03 Thread Jorge Williams
The whole idea behind the "bookmark" links is to give you the functionality that you want -- that is a URL without a version number in it. Looks like the implementation hasn't yet added support for that, but it will. -jOrGe W. On Jun 2, 2011, at 5:04 PM, Thorsten von Eicken wrote: We neither

Re: [Openstack] XML and JSON for API's

2011-06-03 Thread Andy Bierman
IMO, defining an API by providing 1 example of the API is not really interoperable. The point of defining a schema is to specify the 'contract' the API provider will honor, so a developer coding against the API knows what to write (for that particular message exchange). As for extensibility, YAN

Re: [Openstack] Integrating GlusterFS with OpenStack

2011-06-03 Thread Shehjar Tikoo
Devin Carlen wrote: Hi Shehjar, Nova's block device volume service currently has support for several backends and is made in an abstract way so that adding support for Gluster should be a reasonably simple implementation. There is a new project called Lunr being developed that aims to separate

Re: [Openstack] XML and JSON for API's

2011-06-03 Thread George Reese
A lot of the arguments against both XML and JSON seem to boil down to "here's why XML sucks..." The reality is, for whatever reason, good or bad, a lot of people prefer to parse complex data in XML. There's a big market for it. Supporting both formats doesn't add horrible complexity. -George

Re: [Openstack] Integrating GlusterFS with OpenStack

2011-06-03 Thread Devin Carlen
Hi Shehjar, Nova's block device volume service currently has support for several backends and is made in an abstract way so that adding support for Gluster should be a reasonably simple implementation. There is a new project called Lunr being developed that aims to separate the volume code fro

[Openstack] Integrating GlusterFS with OpenStack

2011-06-03 Thread Shehjar Tikoo
Hi All We're aiming to integrate Gluster with Openstack in a way that allows GlusterFS to be used as the storage for application volumes as well as VMs. I am interested in hearing your ideas on how such an integration can be performed. Being the openstack experts, could you please share some i