Re: [Openstack] distributed and heterogeneous schedulers

Let's not confuse instance metadata with Compute Node Capabilities. When scheduling, the instance has not been created yet. We have to make decisions on where the instance will ultimately reside on a number of factors: 1. the capabilities of the host hypervisor (the Compute node) 2. the current

Re: [Openstack] Federated Identity Management (bursting and zones)

From: Eric Day [e...@oddments.org] > Well, they should start off with what the request specifies. For > the 1.1 API, this takes the for of POST /v1.1//servers/ so > would be the owner. This could be anything depending on what > the authenticated user has access to do and what the authz system > d

Re: [Openstack] Federated Identity Management (bursting and zones)

Myself and Eric were chatting a little more about this on IRC yesterday http://paste.openstack.org/show/1108/ Eric made an interesting observation that we don't need to call them Resource Groups, since they're just collections of UUID's (or URI's or URN's or whatever). They could refer to Users

Re: [Openstack] Federated Identity Management (bursting and zones)

. don't allocate new instances in Zones running low on available networks? -S From: Vishvananda Ishaya [vishvana...@gmail.com] Sent: Tuesday, April 05, 2011 4:31 PM To: Sandy Walsh Cc: Eric Day; openstack@lists.launchpad.net Subject: Re: [Openstack] Fede

Re: [Openstack] Federated Identity Management (bursting and zones)

From: Vishvananda Ishaya [vishvana...@gmail.com] > Ok so we are aggregating at the service layer. That does make optimization a > bit easier. Especially > if the user can specify with the OnBehalfOf idea a subset of the instances he > wants to list. Yeah, previously it would have been expensi

Re: [Openstack] Federated Identity Management (bursting and zones)

From: Vishvananda Ishaya [vishvana...@gmail.com] > I think account/action tuple isn't too complicated. If we decide not to use > use the resource_groups as > tags, meaning multiple can be applied to same object, then we probably need > this functionality. Or else we > will have some crazy use

Re: [Openstack] Federated Identity Management (bursting and zones)

card for all perhaps? (Jon, can_isolate, *) Returning a large list of resource groups shouldn't be unmanageable. In reality it's still probably 1-2 orders or magnitude smaller than the resource ID's. It's certainly in the realm of most LDAP servers. -S > Vish On Apr 5, 2011, at 4

Re: [Openstack] Federated Identity Management (bursting and zones)

Doh! I'm an idiot. Write that down. Eric, you're correct, we don't need to sync the AuthZ servers. We only need to pass the Resource Group ID's along after the user authenticates (thanks Jorge for reminding me.) This is along the lines of what you have been suggesting with different User accou

Re: [Openstack] Federated Identity Management (bursting and zones)

From: Eric Day [e...@oddments.org] > The extra cost is this introduces a new type. If we are going with an > authenticated user returning a list of accounts or account/action > tuples, then having another type for resource groups seems > excessive. It seems we only need one mapping layer here, not

Re: [Openstack] Federated Identity Management (bursting and zones)

From: Vishvananda Ishaya [vishvana...@gmail.com] > Eric: > I agree that your suggestion is simpler, but I think we are too limited if we > remove multi-membership and per- > object overrides. Imagine that alice is an organization that has 10 users > and a lot of instances. If i create a group >

Re: [Openstack] Federated Identity Management (bursting and zones)

> From: Vishvananda Ishaya [vishvana...@gmail.com] > I don't see how one would give access to an entire organization at once. We don't need to. When a user auths into the SP world we get a set of permissions for that user from MyCo. If everyone in MyCo auth'ed against the SP they would all hav

Re: [Openstack] Federated Identity Management (bursting and zones)

From: Eric Day [e...@oddments.org] > Service Provider zones could be configured to access authz.myco.com > for any authentication requests that come in for the myco.com namespace. Hmm, yes I think that might be possible (with the obvious performance concerns). My concern was that we would have

Re: [Openstack] Federated Identity Management (bursting and zones)

Phew, ok, I've boiled down the various federated AuthZ discussions with eday, vish & jorge. I've superseded the old blueprint since the bulk of the work is clearly in the Federated AuthZ camp and not the AuthN camp. http://wiki.openstack.org/FederatedAuthZwithZones Shorter and more succinct.

Re: [Openstack] Federated Identity Management (bursting and zones)

For those of you following along at home ... there was a big IRC discussion around this: http://paste.openstack.org/show/1075/ Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entit

Re: [Openstack] Federated Identity Management (bursting and zones)

ishvananda Ishaya [vishvana...@gmail.com] Sent: Wednesday, March 30, 2011 7:29 PM To: Sandy Walsh Cc: Jay Pipes; openstack@lists.launchpad.net Subject: Re: [Openstack] Federated Identity Management (bursting and zones) I think authz is simplest if we just give it the responsibility of mapping

Re: [Openstack] Federated Identity Management (bursting and zones)

From: Jay Pipes [jaypi...@gmail.com] > Come to think of it, there's no reason that role A would need to have similar > privileges in zones X and Y. More likely than not, they would have different privileges, and therefore a federated authz service wouldn't really make sense. I see your point, I

Re: [Openstack] Federated Identity Management (bursting and zones)

From: Vishvananda Ishaya [vishvana...@gmail.com] > So we can have a set of standard groups defined, and if Alice's AuthN returns > one of those groups, she can launch. It means we will probably have to > define some sort of openstack-compatible authn groups. True ... I'll give some thought to t

Re: [Openstack] Federated Identity Management (bursting and zones)

From: Jon Slenk [jsl...@internap.com] > I think that if the system used capabilities/ZBAC then there would be no such weird prompting. I see your point, but I'm assuming AuthZ has to be federated as well. We don't know about Alice, she lives in her private cloud. We have to ask her AuthZ system

Re: [Openstack] Federated Identity Management (bursting and zones)

So, I assuming having the auth service external, this would imply one HA Auth service per business. It would span regions, data centers, zones, etc. Otherwise it gets really messy. I've started mapping out some use cases (with event trace) here http://wiki.openstack.org/ZonesOauth It's really l

Re: [Openstack] OpenStack Design Summit - Fall 2011 Location Request

+1 for Non-North America -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Stephen Spector [stephen.spec...@openstack.org] Sent: Tuesday, March 29, 2011 12:52 PM

Re: [Openstack] Feature Freeze status

From: Todd Willey [t...@ansolabs.com] > I, too, appreciate people taking their time to write blueprints. I also appreciate people who take time to write code, even if it doesn't come with a blueprint. People who take their creative energy to contribute to something I love earn enough favor that my

Re: [Openstack] Feature Freeze status

+1 From: Ewan Mellor [ewan.mel...@eu.citrix.com] > Blueprints should be regarded in the same way as docstrings. Sure, you can > write the code faster without docstrings, and the code will work just as > well, but it will take everyone else twice as long

Re: [Openstack] Federated Identity Management (bursting and zones)

one last note for completeness: http://etherpad.openstack.org/r7eSWs0b8k Thanks Vish ... that's what I was looking for. For others: https://code.launchpad.net/~anso/nova/authn_and_authz/+merge/52119

Re: [Openstack] Federated Identity Management (bursting and zones)

.html Will review. <http://plansthis.com/auth>-S From: Vishvananda Ishaya [vishvana...@gmail.com] Sent: Monday, March 28, 2011 6:21 PM To: Sandy Walsh Subject: Re: [Openstack] Federated Identity Management (bursting and zones) Some work was done in the A

Re: [Openstack] Federated Identity Management (bursting and zones)

gement solution, option 2 :). The IdM solution can be extensible to support other Identity Federation protocols as well such as SAML. Khaled On Mon, Mar 28, 2011 at 11:17 AM, Jay Pipes mailto:jaypi...@gmail.com>> wrote: On Mon, Mar 28, 2011 at 10:15 AM, Sandy Walsh mailto:sandy.wa...@

[Openstack] Federated Identity Management (bursting and zones)

Currently, we link Nova deployments (aka Zones) with a single admin account. All operations done in the child zone are done with this admin account. Obviously this needs to change. A simple operation such as "get_all_servers" should only return the servers that User X owns. In the current implem

Re: [Openstack] core dev

+1 for the Sprinkle-laden Trey Bucket. From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Trey Morris [trey.mor...@rackspace.com] Sent: Thursday, March 24, 2011 6:4

Re: [Openstack] vSphere support merged

Awesome! Impressive work everyone! -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Ewan Mellor [ewan.mel...@eu.citrix.com] Sent: Friday, March 25, 2011 7:23

Re: [Openstack] A single cross-zone database?

the benefits of single database through separate caching schemes; and easy to layer on to the existing solution. Certainly a great topic for the design summit, imho. -S From: Andy Smith [andys...@gmail.com] Sent: Wednesday, March 23, 2011 10:23 PM To: Sandy Walsh C

Re: [Openstack] Instance IDs and Multiple Zones

+1 Great discussion and not anything that should be blocking distributed scheduler. -S From: Eric Day [e...@oddments.org] Ok. :) The original statement felt like it was written with negative connotations, and I just wanted to say I think it's all been

Re: [Openstack] OpenStack API - Where do I find ?

Hi Sheshadri, Openstack compute (nova) supports both the Amazon EC2 API and the Rackspace 1.0 API currently. The RS API spec is available here: http://docs.rackspacecloud.com/servers/api/v1.0/cs-devguide-20110112.pdf There is a python client library available here: https://github.com/rackspace

Re: [Openstack] Instance IDs and Multiple Zones

> From: Eric Day [e...@oddments.org] > > On Thu, Mar 24, 2011 at 12:23:42AM +0000, Sandy Walsh wrote: > > Regardless of how we delineate it or which ID scheme we use, we have no way > > of detecting collisions. > Why not? Some schemes such as the ID.DNS name + ssl cert

Re: [Openstack] Instance IDs and Multiple Zones

(sorry Eric, meant to send to the list) -S From: Eric Day [e...@oddments.org] > Do we want this namespace per zone, deployment, resource owner, or some other > dimension? Good question. We can prevent collisions at the zone level and within a deployment (single provider / multi-zone). But hybri

Re: [Openstack] Instance IDs and Multiple Zones

From: Ewan Mellor [ewan.mel...@eu.citrix.com] > For example, if I charge my customers for a month of usage, even if they only > run the VM for a part of that month, then my billing system needs to be able > to say "that VM has moved from here to here, but it's actually the same VM, > so I'm cha

Re: [Openstack] Instance IDs and Multiple Zones

Pvo brought up a good use case for naming a little while ago: Migrations. If we use the instance id (assume UNC) to provide hints to the target zone, this means the instance id would need to change should the instance move locations. That's a no-no by everyone's measure. So, now I'm thinking m

Re: [Openstack] Instance IDs and Multiple Zones

Good conversation guys. Certainly something we need to get settled out sooner than later. On naming: No matter how we shake it out (prefixes, mac address, time, etc), we're essentially fabricating our own form of UUID ... trying to pick some unique qualifier(s) to avoid collisions. I think t

Re: [Openstack] A single cross-zone database?

Yup, that's a fair assessment. That said, even without SDB and caching it's going to be tight for Cactus anyway. There are lots of little issues that are cropping up once I got down to 100'. -S From: Justin Santa Barbara mailto:jus...@fathomdb.com>> Sandy: Hav

[Openstack] A single cross-zone database?

Hi y'all, getting any sleep before Feature Freeze? As you know, one of the main design tenants of OpenStack is Share Nothing (where possible). http://wiki.openstack.org/BasicDesignTenets That's the mantra we've been chanting with Zones. But it does cause a problem with a particular Use Case: "

Re: [Openstack] Queue Service Implementation Thoughts

I'm sure you've seen this: http://nichol.as/benchmark-of-python-web-servers?source=g -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Eric Day [e...@od

Re: [Openstack] Crazy Idea for API Formats

__ From: Michael Mayo [m...@openstack.org] Subject: Re: [Openstack] Crazy Idea for API Formats On Mar 4, 2011, at 10:55 PM, Sandy Walsh wrote: > Interesting ... do I get back an instance object or just a key/value dict? I'm thinking an actual instance object. And we would provide code

Re: [Openstack] Crazy Idea for API Formats

Interesting ... do I get back an instance object or just a key/value dict? Is the attraction not having complex/multi-package client libraries to import? If the client was: obvious to download, easy to install/update and had a full object model ... would that be better? -S

Re: [Openstack] Multiple Versions in Openstack API

I agree that, while it's a pain, supporting old versions of the API is the best way to grow adoption. For many shops, simply supporting OpenStack API is a large engineering effort ... having to revisit it every version update might bust the camels back. Easy to see why Amazon goes back so far.

Re: [Openstack] server affinity

I think these additional/optional request parameters (aka metadata) should just be part of the context that is created when a command is issued and passed around for all services to use as needed. So I guess that would be a vote for #2 -S From: Jorge W

Re: [Openstack] server affinity

Was just speaking with dabo about this and we agree that metadata is a bad name for this capability. I don't really care about what we call it, but metadata has some preconceived notions/meanings. Perhaps Criteria? Currently we have *some* criteria for creating a new instance on the Openstack

Re: [Openstack] How to deal with 'tangential' bugs?

+1 From: Dan Prince [dan.pri...@rackspace.com] Sent: Monday, February 28, 2011 4:20 PM If you really need to write a test case ahead of time (perhaps even to make your case that a bug exists) why not just create a launchpad bug and then attach the test case as a

Re: [Openstack] Novatools ...

Thanks Thierry for summarizing the concerns. I have a new version in https://github.com/rackspace/python-novatools This does the following: 1. Renames the cmdline tool to nova. The package is still python-novatools 2. Ups the version # to 2.1 3. Changes the license to Apache for 2.1+. Prior versi

Re: [Openstack] Novatools ...

But will he continue to pull merges on a rapidly changing series of patches up to RC on April 14th and beyond? -S So we have perhaps a decent chance of getting things rolling there? I think it is worth pursuing. --andy Confidentiality Notice: This e-mail message (including any attached or

Re: [Openstack] Novatools ...

Thanks Jay. Yes, to the best of my knowledge nothing should have changed to keep novatools from working with cloudservers/RS API. This was the situation right up to the rebranding. Now, a merge would be much harder. -S *If* Sandy's minimal changes were merged, then python-cloudservers would be

Re: [Openstack] Novatools ... where to place in /nova/?

I, mistakingly, changed the subject so I could focus on the install directory. Sorry for creating a rift. Hopefully, I'm going to move it in such a way that we don't need to mess with the python path for nova and a user can still install it if desired. -S _

Re: [Openstack] Novatools ...

Some great discussion going on here folks but, in an attempt to prevent this turning into a full-on Painting the Bike Shed debate, here are the assumptions I'm proceeding with: 1. Eventually there will be a "super tool" to aggregate the various services. It will be built/named later by someone.

Re: [Openstack] Novatools ... where to place in /nova/?

Hmm, that's a little tricky since oscompute will be contain the cmdline tool and the client tool to the REST API (cmdline is just a shell interface over the client). It would mean splitting things up and the setup.py would get complicated. To Eric's point .../clients/python/* .../clients/ruby/

Re: [Openstack] Novatools ... where to place in /nova/?

Yup, this looks like the "super tool" that jay was talking of earlier (odd too, since that's something I'm using accused of being) I kind of like it as well, since it permits swift, nova and glance to have their own client tools, but fit within the larger umbrella (and tab-completion/hints wor

Re: [Openstack] Steps that can help stabilize Nova's trunk

Jay, Nice to see this issue being addressed ... it's a big deal. >From reading this (long) thread, my biggest source of confusion was so many >"we're doing something on this front too ..." messages. Would it be possible to get a summary of the various integration testing efforts underway so we

Re: [Openstack] Burrow (queue service)

> Let me know if there are any questions I didn't answer thoroughly enough. Looks like a fun project Eric. I only got caught up on the ML this weekend and I'm behind again already. Some questions that I jotted down from the previous discussions were: 1. Will broadcast queues be supported? 2.

Re: [Openstack] Novatools ...

Jay, I totally see your argument. Are you proposing a more plug-in type mechanism like nova-manage/django-admin (but uses the public API)? Or, perhaps, similar to the Citrix 'xe' umbrella? Is this part of the longer term discussion (as we still need something now)? -S

Re: [Openstack] Novatools ...

Thanks Eric, I agree. It would be great to do 'bzr branch lp:nova' and have all the client tools we need. Especially given the fact that the client tools are now required by the system itself. I suspect it will also be needed for integration testing. This also prevents more PPA administration.

Re: [Openstack] Novatools ...

Perfect. Objections? (naming bun-fights discouraged ;) -S From: John Purrier Sent: Thursday, February 24, 2011 1:39 PM To: Sandy Walsh; Andy Smith; so...@openstack.org; Rick Clark Cc: Paul Voccio; Matt Dietz; Josh Kearney; openstack@lists.launchpad.net Subject

Re: [Openstack] Novatools ...

ry 24, 2011 1:05 PM To: Sandy Walsh; Andy Smith; so...@openstack.org; Rick Clark Cc: Paul Voccio; Matt Dietz; Josh Kearney; openstack@lists.launchpad.net Subject: RE: Novatools ... Including ttx and the mailing list. It seems as if the API experience for OpenStack is going to be a hierarchical

Re: [Openstack] Review days for nova-core members

+1 ... sounds awesome. The code review process is our greatest strength, IMHO. I like the idea of not over-thinking things, trying them and adjusting as required. Fail fast. Let's do it! -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net

[Openstack] Proposal to be a member of Nova Core ...

I'd like to help out on the review process as per http://wiki.openstack.org/Governance/Approved/CoreDevProcess I like quiet walks in the park and black and white movies. -Sandy Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclu

Re: [Openstack] Review days for nova-core members

I'll throw my hat in the ring for core if deemed worthy. Soren's point about 1 review day per # core developers was refreshing. I had previously held back from applying because I was afraid all my time would be tied up with reviews. ? From: openstack-

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

Thanks for the feedback Soren. I agree that caching can be error prone. When I first read your email I started to panic that we were taking the wrong tack. But, the more I think about it, it's probably not that bad. For basic routing operations, I *think* the caching should be fine. "Do you h

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

Thanks Dragon! Had another conversation with Jay on this as well. I think the caching with the smart use of instance/customer naming will go a long way to helping the search. More comments below ... -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sa

Re: [Openstack] Multi-Cluster/Zone - Devil in the Details ...

Thanks for feedback Ed. Comments in [] below ... From: Ed Leafe [e...@leafe.com] On Feb 16, 2011, at 10:26 AM, Sandy Walsh wrote: Isn't the instance name usually supplied by the user/originator? [Sorry, yes the instance name is passed in o

[Openstack] Multi-Cluster/Zone - Devil in the Details ...

Hi y'all Like they say "The devil is in the details". I'm at the stage where the parent zones will talk to the child zones and there are some interesting implementation issues: Problem 1. I'd like to pass the incoming HTTP Request object along to the Scheduler so I don't have to remarshall the

Re: [Openstack] Allowing clients to pass capability requests through tags?

Phew. I was thinking this was going to be an overloaded capability on the zone name. Carry on. Nothing to see here. -S From: Eric Day [e...@oddments.org] Sent: Friday, February 11, 2011 1:36 PM To: Sandy Walsh Cc: Justin Santa Barbara; openstack

Re: [Openstack] Allowing clients to pass capability requests through tags?

Heh, hate to be the one to bust up the URI love-fest :) The issue I have with a single URI being used as the heuristic for node selection is that it is very rigid. Different business units have different views on the network: * Operations may view it as geography/data centers. * Consumers may vi

Re: [Openstack] Allowing clients to pass capability requests through tags?

Agreed. Ed Leafe (dabo) is slated to work on the scheduler plugins that make the decisions for which zone to use. https://blueprints.launchpad.net/nova/+spec/bexar-distributed-scheduler You might want to review that one a

Re: [Openstack] Multi Clusters in a Region ...

name of a child zone, in which case the parent's zone-add operation should fail. But I'm going to worry about that one right now. -S From: Eric Day [e...@oddments.org] Sent: Thursday, February 10, 2011 1:55 PM To: Sandy Walsh Cc: openstack@lists.l

Re: [Openstack] Multi Clusters in a Region ...

t's a good idea. Keep it coming! -Sandy _ ___ From: Eric Day [e...@oddments.org] Sent: Wednesday, February 09, 2011 1:17 PM To: Sandy Walsh Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Multi Clusters in a Region ... Hi Sandy, Replying via emai

Re: [Openstack] Do these commands belong in the API or nova-manage?

k, admin-only OpenStack API it is ... thanks for the prompt feedback guys! -S From: Jay Pipes [jaypi...@gmail.com] Sent: Tuesday, February 08, 2011 7:09 PM To: Devin Carlen Cc: Sandy Walsh; openstack@lists.launchpad.net Subject: Re: [Openstack] Do these

[Openstack] Do these commands belong in the API or nova-manage?

Quick question ... For multi-cluster/zones I have a bunch of commands that need to be exposed to administrators: 1. CRUD child zones 2. CRUD hosts to a zone 3. CRUD zone & host capabilities to a zone Do you think these belong in the admin-only OpenStack API or only available via nova-manage?

Re: [Openstack] Multi Clusters in a Region ...

@lists.launchpad.net] on behalf of Sandy Walsh [sandy.wa...@rackspace.com] Sent: Monday, January 31, 2011 3:26 PM To: openstack@lists.launchpad.net Subject: [Openstack] Multi Clusters in a Region ... Hi y'all, Now that the Network and API discussions have settled down a little I though

Re: [Openstack] Pondering multi-tenant needs in nova.

+1 From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Eric Day [e...@oddments.org] Sent: Monday, February 07, 2011 1:35 AM To: Jay Pipes Cc: openstack@lists.

Re: [Openstack] Pondering multi-tenant needs in nova.

I think, but I'm not sure, that Glen is suggesting to just keep a URI for the enterprise element. This might map to a database, LDAP, etc. and it might be internal to Nova or external (likely). One plug-in for tentant structure might from a database, in which your proposal would be perfect (p

Re: [Openstack] Pondering multi-tenant needs in nova.

> There's no good reason for Nova to have to model an organization internally; > it certainly wouldn't match all the possible org structures available. +1 From: Devin Carlen mailto:devin.car...@gmail.com>> Date: Thu, 3 Feb 2011 12:02:38 -0800 To: Monsyne Dragon mailto:mdra...@rackspace.com>> C

Re: [Openstack] Pondering multi-tenant needs in nova.

Sounds very LDAP. Would it make sense to have a plug-in so we could mimic a pre-existing corp LDAP structure? -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of

[Openstack] Multi Clusters in a Region ...

Hi y'all, Now that the Network and API discussions have settled down a little I thought I'd kick up the dust again. I'm slated to work on the Multi Cluster in a Region BP for Cactus. This also touches on Zone/Host Capabilities and Distributed Scheduler, so feedback is important. https://bluep

Re: [Openstack] [RFC] OpenStack API

API (1.0) support already exists in the code, it is currently the Rackspace Cloud API. Version 1.1 of that API (in Cactus) should have an Openstack namespace and extensibility. > [...] > Developing an Open Stack Cloud System-level CLI might be a good start ... As part of the above spec, Sandy Wal

[Openstack] Free PyCharm license for Openstack Developers ...

The nice folks at JetBrains were kind enough to grant OpenStack developers a free license to PyCharm. So, if you care to give it a try ... -S IMPORTANT: THIS IS TO CERTIFY THE RIGHT TO USE THE JETBRAINS SOFTWARE PRODUCT, GRANTED BY JETBRAINS S.R.O. UNDER THE TERMS AND CONDITIONS OF THE LICEN

Re: [Openstack] [RFC] OpenStack API

nsibility. > [...] > Developing an Open Stack Cloud System-level CLI might be a good start ... As part of the above spec, Sandy Walsh has a new python-cloudservers library (and accompanying cloudservers CLI tool) that, with adequate rebranding, should just be w

Re: [Openstack] [RFC] OpenStack API

Good discussion guys. Given the date, I agree this doesn't seem like a Bexar thing. Clearly, I'm going to need to wrap my head around comparing 1.0 to 1.1 details. My obvious fear, as an API consumer, is when adopting changes involves a large engineering effort. A point release says to me "Meh

Re: [Openstack] [RFC] OpenStack API

Thanks John. That's a good summary of the plan. I still have a few questions, if you could indulge me ... Seems like there are two issues being debated, one customer-facing, one Nova-developer-facing: Customer-facing: Will OS 1.1 remain backward compatible with 1.0? In other words, is 1.1 truly

Re: [Openstack] Easy API

issing something or just crazy in these assumptions. Look forward to your feedback ... in the meanwhile I'll look at easy-api. Cheers, Sandy From: Andy Smith [andys...@gmail.com] Sent: Wednesday, December 29, 2010 4:08 PM To: Matt Dietz Cc: Jesse Andrew

Re: [Openstack] Merging baby steps or full branches

While I completely understand the rationale for this approach, I'm not a fan. As you say, it's harder to spot dead code, code may be introduced into trunk without tests, rollbacks are harder (if not near impossible), reviewers have to go back and look at other merges to get the big picture, etc.

Re: [Openstack] Suspend and locking instances

I wonder if this bp should be split into two topics: 1. instance locking 2. instance suspend I think they merit a split. -Sandy From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.ne

[Openstack] Test Frameworks ...

Hi y'all, I'm working on the Admin API blueprint https://blueprints.launchpad.net/nova/+spec/admin-only-api And while looking at the code I discovered that the openstack API unittests were only available via nosetests and don't get run from runtests.py. The reason being that nosetests uses an a

<    1   2   3