For those of you not on the Orchestration team mailing list, you can sign up
here:
https://launchpad.net/~nova-orchestration
Cheers,
Sandy
Sent: Thursday, October 20, 2011 8:46 AM
To: nova-orchestrat...@lists.launchpad.net
Subject: [Nova-orchestration]
Just added slides for Orchestration and Advanced Scheduling to wiki.
(sparse etherpad URL's on title slides)
-Sandy
From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf
You seem to doing things correctly.
Can you paste the output from 'nova zone-list' in the parent zone please?
-Sandy
From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net]
perhaps unrelated, but I added a branch to novaclient a while ago that allows
you to reuse a token, so you don't have to re-auth. This is, of course, library
only ... not cmdline.
From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
Great video on the topic: http://blip.tv/djangocon/keynote-david-eaves-5571777
-S
This email may include confidential information. If you received it in error,
please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to :
/MultiClusterZones
-S
From: Joshua Harlow [harlo...@yahoo-inc.com]
Sent: Tuesday, September 27, 2011 12:14 AM
To: Sandy Walsh; Devin Carlen; Soren Hansen
Cc: openstack
Subject: Re: [Openstack] Nova DB Connection Pooling
It seems like it would be good to talk about this during
POST .../zone/boot has been removed and integrated into POST .../servers/boot
now, so there isn't really anything that shouldn't be public now. zone/select
is still required for bursting scenarios.
From:
Try getting started with the Yagi Readme
https://github.com/Cerberus98/yagi
If you get stuck from there, just ping us again.
Hope it helps!
-S
From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
Connection Pooling
We really need to hear from Sandy Walsh on this thread so he can elaborate on
how the distributed scheduling works (with multiple mysql databases).
Devin
On Sep 26, 2011, at 6:41 AM, Soren Hansen wrote:
2011/9/26 Pitucha, Stanislaw Izaak stanislaw.pitu...@hp.com:
The pain
Thanks Mark, that's a great reference.
I had two things really trip me up yesterday. All my own fault of course, but
perhaps an area we can improve upon?
1. After making changes to my gerrit branch I fell back on old habits and did a
'git commit -a' vs. 'git commit -a --amend' which caused a
Pff, I want to know how he escaped for so long?!
+1
From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of
Brian Waldon [brian.wal...@rackspace.com]
Sent:
Hi Roman,
I ran into this too and have it fixed in this commit:
https://github.com/SandyWalsh/python-novaclient/commit/cfab90bddf2325915fb93af63e9efd31793cd55d
But it's part of a larger branch.
If you are unable to patch, let me know and I'll break this out as a solo
branch.
-S
@lists.launchpad.net
Subject: Re: [Openstack] Integration tests
Matt Dietz wrote:
Ditto
On 9/12/11 2:10 PM, Sandy Walsh sandy.wa...@rackspace.com wrote:
From: Jay Pipes [jaypi...@gmail.com]
Can we discuss pulling novaclient into Nova's source tree at the design
summit?
+1
Someone should file
Here's a wiki page of some screencasts I put together of recent Nova changes
I've been working on.
Please feel free to add your own.
http://wiki.openstack.org/DemoVideos
-S
This email may include confidential information. If you received it in error,
please delete it.
From: Jay Pipes [jaypi...@gmail.com]
Can we discuss pulling novaclient into Nova's source tree at the design
summit?
+1
This email may include confidential information. If you received it in error,
please delete it.
ugh ... this whole conversation has moved into the absurd (and not due to your
suggestion Vish :)
I agree with Soren, let's move on to more important issues. I apologize for
taking us off course.
-S
From:
=rackspace@lists.launchpad.net] on
behalf of Stefano Maffulli [smaffu...@gmail.com]
*Sent:* Monday, September 05, 2011 12:35 PM
*To:* openstack@lists.launchpad.net
*Subject:* Re: [Openstack] A possible alternative to Gerrit ...
2011/9/5 Sandy Walsh sandy.wa...@rackspace.com
mailto:sandy.wa
to decide between growing our own (in any form) and simply using LP,
I'd vote LP.
-S
From: Soren Hansen [so...@linux2go.dk]
Sent: Wednesday, September 07, 2011 8:54 AM
To: Sandy Walsh
Cc: Monty Taylor; openstack@lists.launchpad.net
Subject: Re: [Openstack
+1
From: George Reese [george.re...@enstratus.com]
This should fall under the more general push notifications API.
This email may include confidential information. If you received it in error,
please delete it.
From: George Reese [george.re...@enstratus.com]
Sent: Wednesday, September 07, 2011 10:41 AM
To: Sandy Walsh
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] Standardizing External APIs
See:
http://broadcast.oreilly.com/2011/04/proposal-for-cloud-state-notifications.html
and
http
... perhaps just lgtm (no !) heh
-S
PS Notice the funky new stylings thanks to Jake Dahn!
From: Josh Kearney [j...@jk0.org]
Sent: Wednesday, September 07, 2011 12:05 PM
To: Soren Hansen
Cc: Sandy Walsh; openstack@lists.launchpad.net
Subject: Re: [Openstack] A possible
of.
-S
From: Jay Pipes [jaypi...@gmail.com]
Sent: Wednesday, September 07, 2011 12:24 PM
To: Sandy Walsh
Cc: Josh Kearney; Soren Hansen; openstack@lists.launchpad.net
Subject: Re: [Openstack] A possible alternative to Gerrit ...
On Wed, Sep 7, 2011 at 11:18
I don't think there's any proposal to stop gated trunk nor to bypass initial
approval from CI.
The intention of integrating hubcap and roundabout is to provide these two
critical pieces of functionality, but simply remove gerrit from the equation.
That said, whether we use roundabout or use
[smaffu...@gmail.com]
Sent: Monday, September 05, 2011 12:35 PM
To: openstack@lists.launchpad.net
Subject: Re: [Openstack] A possible alternative to Gerrit ...
2011/9/5 Sandy Walsh
sandy.wa...@rackspace.commailto:sandy.wa...@rackspace.com
That said, whether we use roundabout or use the code
The coarse status granularity of GitHub's pull request is a
non-starter for automated patch queue management and a gated trunk.
Period. Solutions such as roundabout and hubcap must use hacks such as
looking in review comments for one or more lgtms to determine if a
commit is approved to be
Subject: Re: [Openstack] A possible alternative to Gerrit ...
Sandy Walsh wrote:
Last night I did some hacking on HubCap. HubCap is a simple script that
monitors Pull Requests in GitHub. It spits out a static HTML page of the
requests workflow status.
[...]
I won't speak on behalf of Monty Taylor
Hey!
Last night I did some hacking on HubCap. HubCap is a simple script that
monitors Pull Requests in GitHub. It spits out a static HTML page of the
requests workflow status.
It infers workflow status by looking for keywords in the comments. It's so
simple it's stupid. The last keyword from
I also considered making it part of the existing scheduler service,
but wasn't sure how to add a time-delayed message to the scheduler queue
for the follow-up. If that's possible, then there would not need to be a
separate service; the scheduler can simply follow up itself.
Unless
How is this: http://wiki.openstack.org/GerritWorkflow
Better than this: http://wiki.openstack.org/LifeWithBzrAndLaunchpad
At the last summit, we said it wasn't a bzr vs git issue but, rather, a
workflow issue. People hated LP and loved github. But now it seems we're only
using github for git.
A man with one watch knows what time it is. A man with two is never sure.
- Some guy
From: Jesse Andrews [anotherje...@gmail.com]
Sent: Friday, August 26, 2011 9:54 PM
To: Sandy Walsh
Cc: Josh Kearney; Johannes Erdfelt; openstack@lists.launchpad.net
Soren, that's an awesome utility to have. I'll certainly be using to shore up
some coverage.
Nice work!
-S
From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf
Ugh, sorry, burned again by outlook web. Let me continue ...
I'm still stewing on this but at first blush this seems like an artificial
abstraction. What do we really gain from having another layer above the service
api's? Can't they just live at the service api?
For example:
+1
I think the work really lives with formalizing the contracts at the
nova.[service].api level and pushing the discrepancies into the respective
public API's.
-S
From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
Won't an IPv6 address do that by it's very nature?
-S
From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of
Chris Behrens [chris.behr...@rackspace.com]
Sent:
From: Jorge Williams
Sent: Saturday, July 09, 2011 2:28 AM
To: Sandy Walsh
Cc: Soren Hansen; openstack@lists.launchpad.net
Subject: Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it
worth the effort?
On Jul 8, 2011, at 10:44 PM, Sandy Walsh wrote:
Wow, really? Is EC2 really
+1 to Soren's argument that ec2 is the 1000lb gorilla and should be central to
nova. We definitely need to support it with as close to 100% compatibility as
we can.
Sounds like the only option is to embrace and extend it. Do everything it can
do, and layer on what we need provided it doesn't
Ugh ...
... but at first blush, it doesn't seem like such a *bad* thing?
This email may include confidential information. If you received it in error,
please delete it.
___
Mailing list: https://launchpad.net/~openstack
Post to :
I don't think this is a technical issue, it's a business issue. If we want
adoption, we have to reduce switching friction. Sadly, this means EC2
bugs/nuances and all.
The better a job we do of this, the easier it will be for users to transition
from EC2 to OpenStack and benefit from all the
Isn't there a concern of leaking internal Zone information to the outside world
(particularly in the Service Provider model)? If so, we're back to the mapping
table.
And, when multi-instance boot commands are more common (provision me 10
servers vs. 1), then more people will be searching by
From: Jorge Williams [jorge.willi...@rackspace.com]
What you are proposing that we try to achieve with EC2 what the Wine folks
want to achieve with the Windows API. It's a different problem. It's a much
harder problem because it involves reverse
Agreed.
That's the downside of not having control of an API. Unless we do the Embrace
and Extend thing, but that just seems fraught with problems if Amazon should
zig when we zag.
That said, top-level Zones may still operate using EC2 API, but all child-zones
may be OS-API. We'd only need
# Flavors * # Stripes queues, but queues are lightweight
anyway.
Still stewing on the ramifications of all this.
-S
From: Vishvananda Ishaya [vishvana...@gmail.com]
Sent: Wednesday, May 25, 2011 3:42 PM
To: Sandy Walsh
Cc: Soren Hansen; openstack@lists.launchpad.net
From: Brian Lamar [brian.la...@rackspace.com]
Sent: Tuesday, May 24, 2011 11:30 AM
To: Sandy Walsh
Cc: openstack@lists.launchpad.net
Subject: Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...
Only a small scream on PUT /zones/server/
PUT would
Hmm, not sure I like changing the return type based on the input type. Return
types should be consistent.
From: Ed Leafe
If we are going to add an optional parameter to specify the number of
instances, would it be acceptable to specify that when
POST isn't an issue for me. I honestly don't know why I wrote PUT ... I blame
the Canadian holiday.
From: Ed Leafe
On May 24, 2011, at 11:05 AM, Sandy Walsh wrote:
Hmm, not sure I like changing the return type based on the input type. Return
Yup ... agreed.
I'll press on in this direction (POST with zone generated ID's)
-S
From: Todd Willey [t...@ansolabs.com]
Sent: Tuesday, May 24, 2011 12:13 PM
To: Sandy Walsh
Cc: Brian Lamar; openstack@lists.launchpad.net
Subject: Re: [Openstack
Hi everyone,
We're deep into the Zone / Distributed Scheduler merges and stumbling onto an
interesting problem.
EC2 API has two important concepts that I don't see in OS API (1.0 or 1.1):
- Reservation ID
- Number of Instances to create
Typical use case: Create 1000 instances. The API
code!
Sandy Walsh sandy.wa...@rackspace.com said:
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Cool, I
I agree with all of your points. Having to maintain a client library wasn't on
our list of fun things to do.
The only thing I can see in Jacobian's python-openstack.compute branch that
differs from his old Rackspace API library is the addition of the auth URL and
a rebranding.
We added that
From: Sandy Walsh
Sent: Wednesday, May 18, 2011 9:07 AM
To: Soren Hansen; openstack@lists.launchpad.net
Subject: RE: [Openstack] python-novaclient vs. python-openstack.compute
I agree with all of your points. Having to maintain a client library wasn't on
our list of fun things
Thanks Dan,
I wasn't so much worried about the technical details but rather if your group
plans on making a new client or contributing to python-novaclient (or
something)?
Cheers,
-Sandy
___
Mailing list: https://launchpad.net/~openstack
Post to
, May 18, 2011 10:03am, Sandy Walsh sandy.wa...@rackspace.com
said:
Thanks Dan,
I wasn't so much worried about the technical details but rather if your group
plans on making a new client or contributing to python-novaclient (or
something)?
Cheers,
-Sandy
The HostFilter stuff is going on in here:
https://code.launchpad.net/~sandy-walsh/nova/dist-sched-2a
I see your point about making it easy for the user to request an instance based
on a pre-defined type. I don't know how the process would go for determining
what goes in the db and what stayed
Hi Lorin,
Zones can have multiple parents. Child Zones don't know their parents ...
parents only know about children.
Sharing services across Zones isn't permitted (since they would need to share a
DB and AMQP).
You could solve the problem by using the Capabilities to determine where
-props in.
Expect to see the first to land, hopefully, tomorrow. This will give you a good
idea of the capabilities functionality and the extension points. You can have a
sneak peak at lp:~sandy-walsh/nova/dist-sched-1
Cheers,
-S
From: Lorin Hochstein [lo...@isi.edu
...@isi.edu]
Sent: Thursday, May 12, 2011 12:26 AM
To: Sandy Walsh
Cc: Openstack; do...@pandora.east.isi.edu
Subject: Re: [Openstack] Zones / distributed scheduler question
Sandy:
I took a quick look at see how capabilities are represented and how the
information flows from the ComputeManager
Excellent ... timely and much needed!
For completeness here is the link to Zone AuthZ requirements:
http://wiki.openstack.org/FederatedAuthZwithZones
http://wiki.openstack.org/FederatedAuthZwithZonesLook forward to helping out
where I can.
-S
From:
Hey guys,
I don't understand how adding more data to the *instances* table will be used
for scheduling?
Perhaps what you're talking about is metadata in Glance on the source images?
If so, that data would simply be added to the required-capabilities that get
passed into the scheduler during
Each update from the services are atomic updates ... fully self contained.
Why does this need to be in a persistent store?
-S
From: Jay Pipes [jaypi...@gmail.com]
you still need a persistent data store for attributes of the host. Just
because you
about hadoop ... didn't know that!
-S
From: Jagane Sundar [jag...@sundar.org]
Sent: Friday, April 15, 2011 3:39 PM
To: Sandy Walsh; Jay Pipes; Ed Leafe
Cc: Mark Washenberger; openstack@lists.launchpad.net
Subject: RE: [Openstack] distributed
+1
From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net
[openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of
Jay Pipes [jaypi...@gmail.com]
Sent: Friday, April 15, 2011 4:55 PM
To: openstack@lists.launchpad.net
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
Hear Hear!
From: Jay Pipes [jaypi...@gmail.com]
Thanks, Thierry, for all your assistance during the last couple weeks
organizing the various freezes. It's a thankless job and often very
frustrating. You keep your cool at all times. Thanks for that!
From: Glen Campbell
Sent: Thursday, April 14, 2011 10:37 AM
To: Sandy Walsh; openstack@lists.launchpad.net
Subject: Commas and semicolons
On 4/14/11 6:19 AM, Sandy Walsh sandy.wa...@rackspace.com wrote:
Capabilities are just multi-value key-value pairs
From: Soren Hansen [so...@openstack.org]
2. the current load the host is under
I still question the usefulness of nr. 2. A host that is almost
completely idle right now might be under tremendous pressure a minute
from now and vice versa. Even if we had useful statistics (and trend
We're just running into this problem with distributed scheduler.
The problem is Provision 1000 servers ... how do we load balance this across
hosts across zones?
It busts the current dump the requests into the queue and let the workers
feast approach in place currently.
I have a plan for it,
I've been getting a lot of questions about Zones lately.
How much interest is there for an informational session on Zones and, I guess,
Distributed Scheduler and roadmap?
(pending an available slot at the summit ... things are filling up quickly I
gather)
-S
Confidentiality Notice: This
From: Justin Santa Barbara [jus...@fathomdb.com]
I would very much appreciate a Current State of Zones presentation
that would precede a discussion session on what zones should look like
in Diablo and beyond. We want to be sure that our zones design
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/owner/servers/ so
owner would be the owner. This could be anything depending on what
the authenticated user has access to do and what the authz
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
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 user
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 expensive
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.
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
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 have
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
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
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
subjects
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
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
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
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
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
one last note for completeness:
http://etherpad.openstack.org/r7eSWs0b8k
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
+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
+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
+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
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
Cc: openstack@lists.launchpad.net
Subject
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
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
(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 hybrid
From: Eric Day [e...@oddments.org]
On Thu, Mar 24, 2011 at 12:23:42AM +, 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 check I
mentioned before allow us
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:
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:
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
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
[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 for that.
Like, if someone
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
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
, 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
stack
101 - 200 of 219 matches
Mail list logo
