Re: [Openstack] Network Service for L2/L3 Network Infrastructure blueprint

Hello Hiroshi-san >> Do you mean that the former API is an interface that is >> defined in OpenStack project, and the latter API is >> a vendor specific API? > My understanding is that yes, that's what he means. I also think so. In addition, I feel it is issue that what network functions should

Re: [Openstack] Network Service for L2/L3 Network Infrastructure blueprint

Hi Hiroshi, On Tuesday, February 15, 2011 at 15:47, Hiroshi DEMPO wrote: Hello Hisaharu san > > I am not sure about the differences between generic network API and > plugin X specific network service API. > > Do you mean that the former API is an interface that is > defined in OpenStack project,

Re: [Openstack] Network Service for L2/L3 Network Infrastructure blueprint

Hello Hisaharu san I am not sure about the differences between generic network API and plugin X specific network service API. Do you mean that the former API is an interface that is defined in OpenStack project, and the latter API is a vendor specific API? Thanks Hiroshi > -Original Messag

Re: [Openstack] Queue Service

On Mon, Feb 14, 2011 at 7:57 PM, Paul Voccio wrote: > Looking at the swift docs, they reference a container like so: > >  METHOD /v1// HTTP/1.1 Yeah, this has worked out well for us. Delegated access, authentication methods that don't provide the account name otherwise, anonymous access... And

Re: [Openstack] Queue Service

Looking at the swift docs, they reference a container like so: METHOD /v1// HTTP/1.1 http://docs.rackspacecloud.com/files/api/v1/cf-devguide-20110112.pdf For the openstack api, it also includes the account id in the request: POST /v1.1/214412/images HTTP/1.1 Host: servers.api.openstack.org Con

Re: [Openstack] Queue Service

On Tue, Feb 15, 2011 at 12:49:01AM +, Paul Voccio wrote: > Dropping the account_id, would this also assume that there can be more > than one queue per account? Yeah. Think of the queue name as an extra namespace layer much like a swift container, except you don't create or delete them, they ju

Re: [Openstack] Queue Service

Maybe not. I thought more on the way home. Dropping the account_id, would this also assume that there can be more than one queue per account? On 2/14/11 5:54 PM, "Eric Day" wrote: >Yeah, for anonymous access that would be the case. Those are not needed >when the request comes in with OpenStack

Re: [Openstack] OpenStack Compute API 1.1

Thoughts below From: Justin Santa Barbara mailto:jus...@fathomdb.com>> Date: Mon, 14 Feb 2011 15:40:04 -0800 To: Paul Voccio mailto:paul.voc...@rackspace.com>> Cc: "openstack@lists.launchpad.net" mailto:openstack@lists.launchpad.net>> Subject: Re: [Openstack]

Re: [Openstack] Queue Service

Yeah, for anonymous access that would be the case. Those are not needed when the request comes in with OpenStack Auth headers (like nova). Do you think we should be repeating the account id in the URI when the auth headers are present? -Eric On Mon, Feb 14, 2011 at 11:44:58PM +, Paul Voccio

Re: [Openstack] Queue Service

Eric, Just looking at the http operations. Shouldn't the calls be around the account then the queue? GET /$account_id/queue/id to list all the queues GET /$account_id/queue/id/message/id Am I off here? Thoughts? pvo On 2/14/11 5:07 PM, "Eric Day" wrote: >I've summarized the original emai

Re: [Openstack] OpenStack Compute API 1.1

Ah - well, I was sort of expecting that we'd all go the other way and agree some core functionality, and I thought that volumes should definitely be part of that. I'd hope that the core functionality would always be part of the core API, and I'd include images & volumes in that list. I think that

Re: [Openstack] OpenStack Compute API 1.1

Justin - Thought some more on your comments wrt images being in the 1.1 api spec. I agree with you that it doesn't make sense in the long term to have them in the compute api since the service will delegate to glance in the long term. I would propose that in the 1.2 or other future spec that /i

Re: [Openstack] Queue Service

I've summarized the original email and added more sections for review and discussion here: http://wiki.openstack.org/QueueService In particular there are details on the various components of the queue service, a draft at what the REST operations will look like, and a couple brief examples. Pleas

Re: [Openstack] OpenStack Compute API 1.1

Thoughts below: From: Justin Santa Barbara mailto:jus...@fathomdb.com>> Date: Mon, 14 Feb 2011 14:32:52 -0800 To: mailto:openstack@lists.launchpad.net>> Subject: Re: [Openstack] OpenStack Compute API 1.1 Some thoughts... General: * Are we writing the OpenStack API, or are we writing the do

Re: [Openstack] OpenStack Compute API 1.1

Some thoughts... General: - Are we writing the OpenStack API, or are we writing the document for the next version of Cloud Servers? In my opinion, the two need to be separate. For example, specifications of resource limits and rate limits, supported compression encodings, timeout o

Re: [Openstack] OpenStack Compute API 1.1

On Mon, Feb 14, 2011 at 4:39 PM, Gabe Westmaas wrote: > Thanks Jay, I promise I will make more useful wikis soon :) Hehe, sorry if I came across as grumpy. Was just doing some old fashioned rib-poking, that's all ;) > Jorge answered most of the questions you had, I just wanted to point out that

Re: [Openstack] OpenStack Compute API 1.1

Thanks Jay, I promise I will make more useful wikis soon :) Jorge answered most of the questions you had, I just wanted to point out that I pulled the main IPv6 items out and put them in the wiki now. There isn't too much that changed there, but wanted to point out what was new anyway. Gabe

Re: [Openstack] OpenStack Compute API 1.1

On Feb 14, 2011, at 3:35 PM, Jay Pipes wrote: > On Mon, Feb 14, 2011 at 4:27 PM, Jorge Williams > wrote: >> On Feb 14, 2011, at 3:08 PM, Jay Pipes wrote: >> I'll work with Anne to make the source documents available to you guys so >> you can do a diff etc. Give me a couple of days to get this

Re: [Openstack] OpenStack Compute API 1.1

On Mon, Feb 14, 2011 at 4:27 PM, Jorge Williams wrote: > On Feb 14, 2011, at 3:08 PM, Jay Pipes wrote: > I'll work with Anne to make the source documents available to you guys so you > can do a diff etc.  Give me a couple of days to get this working, existing > docs are built into the implementa

Re: [Openstack] OpenStack Compute API 1.1

On Feb 14, 2011, at 3:08 PM, Jay Pipes wrote: > The reason I haven't responded yet is because it's difficult for me to: > > diff -u some.pdf other.pdf > > In all seriousness, the wiki spec page says this about the differences > in the 1.1 OpenStack API: > I'll work with Anne to make the sour

Re: [Openstack] OpenStack Compute API 1.1

The reason I haven't responded yet is because it's difficult for me to: diff -u some.pdf other.pdf In all seriousness, the wiki spec page says this about the differences in the 1.1 OpenStack API: ==start wiki== OS API 1.1 Features IPv6 Extensions Migrate to OpenStack namespace ==end wiki==

Re: [Openstack] OpenStack Compute API 1.1

Bumping this to the top of the list. One of the key deliverables for Cactus is a complete and usable OpenStack Compute API. This means that using only the API and tools that interact with the OpenStack Compute API Nova can be installed and configured; once running all of the Nova features and funct

Re: [Openstack] Queue Service

Hi Adrian, Yes, you've covered some of what my soon-to-send "API implementation" email already covers. :) On Mon, Feb 14, 2011 at 06:32:40PM +, Adrian Otto wrote: > Ordered delivery of messages is a feature that I recognize is central to the > design of a queue service. A queue must be durab

Re: [Openstack] Queue Service

Hi Pete, Two initial use cases are a comparable service to what other public cloud providers already have (similar HTTP/REST API, but eventually with more features) and a flexible, high-performance queue/event system for backend log and event processing for other OpenStack services (see the messag

Re: [Openstack] Proposed OpenStack Service Requirements

On Sun, Feb 13, 2011 at 01:37:29PM -0500, Todd Willey wrote: > On Wed, Feb 9, 2011 at 1:38 PM, Eric Day wrote: > > * Firehouse - So far we've not discussed this too much, but I > >  think when we did there was agreement that we need it. As more > >  service come into the picture, we want the abili

Re: [Openstack] Queue Service

Pete, Queues are essential for highly concurrent use cases, and batch processing. It's the core of what you need to build a cloud-specific application. Reference: http://www.eecs.harvard.edu/~mdw/proj/seda/ Adrian On Feb 14, 2011, at 10:20 AM, Pete Zaitcev wrote: > On Mon, 14 Feb 2011 09:51:4

Re: [Openstack] Queue Service

Eric, Ordered delivery of messages is a feature that I recognize is central to the design of a queue service. A queue must be durable (persistent) in order to provide reliable ordering capability. Having this feature simplifies implementation of applications that consume the queue. I agree this

[Openstack] Metadata schema design

I've coded support for metadata on instances. This is part of the CloudServers API, and I needed it for my idea about metadata hints to the scheduler. https://code.launchpad.net/~justin-fathomdb/nova/justinsb-metadata/+merge/49490 However, Jay Pipes has raised some (very valid) design questions o

Re: [Openstack] Queue Service

On Mon, 14 Feb 2011 09:51:42 -0800 Eric Day wrote: > [] A queue service can > not only provide a useful public cloud service, but can also provide > one of the building blocks for other services. > I'm looking forward to your feedback. Thanks! Do you have a specific application and/or testbed i

[Openstack] Queue Service

Hi everyone, When looking at other services to include as part of OpenStack, the first that comes to mind for many is a queue. A queue service can not only provide a useful public cloud service, but can also provide one of the building blocks for other services. I've been leading an effort to rese

Re: [Openstack] Build Failures on hudson

It's not using the -f flag because it doesn't run the tests in a virtualenv... -jay On Mon, Feb 14, 2011 at 12:28 PM, Brian Schott wrote: > We are having an issue where the first x509 test is creating an empty > database in the CA subdirectory and all subsequent tests fail.  Is your > Hudson s

Re: [Openstack] Build Failures on hudson

We are having an issue where the first x509 test is creating an empty database in the CA subdirectory and all subsequent tests fail. Is your Hudson server using -f flag on run_tests? Sent from my iPhone On Feb 14, 2011, at 1:18 AM, Vishvananda Ishaya wrote: > The intermittent failure on hud

Re: [Openstack] Contribute to the PyCon talk on OpenStack!

Is twisted vs eventlet vs threads vs processes vs Tornado vs Django too much of a sore wound? We've only been around 9 months and we've already tried all of them! Ewan. > -Original Message- > From: openstack-bounces+ewan.mellor=citrix@lists.launchpad.net > [mailto:openstack-bounces

Re: [Openstack] documentation contributions

On Mon, Feb 14, 2011 at 10:25 AM, Thierry Carrez wrote: > Jay Pipes wrote: >> IMHO, we should not be letting *any* significant new code into >> OpenStack projects without: >> >> a) docstrings for all methods -- these turn into our API >> documentation, so they are critical > > Agreed. > >> b) Full

Re: [Openstack] documentation contributions

Jay Pipes wrote: > IMHO, we should not be letting *any* significant new code into > OpenStack projects without: > > a) docstrings for all methods -- these turn into our API > documentation, so they are critical Agreed. > b) Full RST docs for any new feature added. No exceptions. One issue is th

Re: [Openstack] documentation contributions

Firstly, Anne, I think I can speak for any number of developers and users of OpenStack in giving you a big THANK YOU for all the excellent work you and others have done on the OpenStack documentation. I've said it before, but professional software has professional documentation, and you've pushed o

Re: [Openstack] Contribute to the PyCon talk on OpenStack!

On Mon, 14 Feb 2011 09:14:16 -0500, Ed Leafe wrote: As some of you know, I agreed to propose, prepare and give a talk at next month's US PyCon in Atlanta. I felt that it would be a missed opportunity to have one of the biggest and most significant open source project in Python not repres

[Openstack] documentation contributions

Hi all -- This release brings yet another web property to our collection and so far it is a hit - docs.openstack.org. I'm thrilled at how it has turned out, and am indebted to all who helped. This site is the first step towards providing admin docs in addition to developer docs. So if you're wonde

[Openstack] Contribute to the PyCon talk on OpenStack!

As some of you know, I agreed to propose, prepare and give a talk at next month's US PyCon in Atlanta. I felt that it would be a missed opportunity to have one of the biggest and most significant open source project in Python not represented at the largest Python conference. The talk was