[Openstack] Host Aggregates ...

Hi Armando, I finally got around to reading https://blueprints.launchpad.net/nova/+spec/host-aggregates. Perhaps you could elaborate a little on how this differs from host capabilities (key-value pairs associated with a service) that the scheduler can use when making decisions? The distribute

Re: [Openstack] Proposal to add Kevin Mitchell to nova-core

3746 ^ 0 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: Wednesday, November 09, 2011 9:59 AM To: openstack

Re: [Openstack] Proposal to add Johannes Erdfelt to nova-core

9 * 3 - 26 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: Wednesday, November 09, 2011 10:02 AM To: open

Re: [Openstack] Submitting code to Novaclient

Speaking of ... it's probably about time to get this folded in to the regular infrastructure, since it's pretty important to the project. Shall we set up a time to move it to the openstack org on github and add it to gerrit/jenkins? On 11/02/2011 12:23 PM, Sandy Walsh wrote: > Yo

Re: [Openstack] Submitting code to Novaclient

You're doing it right, we've all just been tied up with some production stuff. I'll try and take some time this afternoon to clear the queue. Sorry for the delay ... and thanks for the submissions! -S From: openstack-bounces+sandy.walsh=rackspace@lists.launc

Re: [Openstack] Which nova scheduler for different hardware sizes?

I'm hoping to land this branch asap. https://review.openstack.org/#change,1192 It replaces all the "kind of alike" schedulers with a single DistributedScheduler. -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounce

Re: [Openstack] Push vs Polling (from Versioning Thread)

+1 Dragon From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Monsyne Dragon [mdra...@rackspace.com] Sent: Thursday, October 27, 2011 4:14 PM To: George Rees

Re: [Openstack] describing APIs for OpenStack consumers

scription of the output. That could at least provide a starting point >>> for generating WADLs... >>> >>> (Of course, I propose this, having little idea of what actually goes in >>> a WADL, but still... ;) >> >> I've worked with WADL and WSDL bef

Re: [Openstack] +1, All services should have WADLs

: Mark Nottingham [m...@mnot.net] Sent: Thursday, October 27, 2011 10:38 AM To: Sandy Walsh Cc: Mellquist, Peter; Joseph Heck; openstack@lists.launchpad.net Subject: Re: [Openstack] +1, All services should have WADLs I'm totally on board with having the interface being machine-consumable at ru

Re: [Openstack] +1, All services should have WADLs

ttingham [m...@mnot.net] Sent: Thursday, October 27, 2011 10:16 AM To: Sandy Walsh Cc: Mellquist, Peter; Joseph Heck; openstack@lists.launchpad.net Subject: Re: [Openstack] +1, All services should have WADLs On 26/10/2011, at 11:17 PM, Sandy Walsh wrote: > As discussed at the summit, I agree th

Re: [Openstack] +1, All services should have WADLs

That's still human generated, just with nicer tools. I'm thinking WADL from implementation code. -S From: Jorge Williams Sent: Wednesday, October 26, 2011 12:29 PM To: Sandy Walsh Cc: Mellquist, Peter; Joseph Heck; openstack@lists.launchpad.n

Re: [Openstack] +1, All services should have WADLs

As discussed at the summit, I agree there should be some form of IDL (WADL being the likely candidate for REST), I think manually crafting/maintaining a WADL (or XML in general) is a fools errand. This stuff is made for machine consumption and should be machine generated. Whatever solution we ad

[Openstack] Welcome to Nova Orchestration ...

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] We

Re: [Openstack] Developer conference documentation

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 o

Re: [Openstack] Problem when Scheduling across zones

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] o

Re: [Openstack] dashaboard+keystone+nova+glance work well？

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 [openstack-bo

Re: [Openstack] Community metrics, developers' engagement

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 : openstack

Re: [Openstack] Nova DB Connection Pooling

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: openstack-bounces+sandy.walsh=rackspace@lists.

Re: [Openstack] Nova DB Connection Pooling

/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 the

Re: [Openstack] Nova DB Connection Pooling

unchpad.net Subject: Re: [Openstack] Nova DB 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, Sta

Re: [Openstack] Nova Notification System Configuration?

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 [openstack-bounces+sandy.walsh=rackspace@list

Re: [Openstack] Nova Gerrit Move

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 ra

Re: [Openstack] Proposal to add Chris Behrens to nova-core

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: Thursd

Re: [Openstack] novaclient+keystone problem AttributeError: 'unicode' object has no attribute 'items'

Heh, seems we're both running in the same direction. If you're using Keystone with Nova, you also have to use Keystone with Glance (assuming you're using Glance). Is this the case? -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net

Re: [Openstack] novaclient+keystone problem AttributeError: 'unicode' object has no attribute 'items'

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 ___

Re: [Openstack] Integration tests

@lists.launchpad.net Subject: Re: [Openstack] Integration tests Matt Dietz wrote: > Ditto > > On 9/12/11 2:10 PM, "Sandy Walsh" wrote: > >> From: Jay Pipes [jaypi...@gmail.com] >> >>> Can we discuss pulling novaclient into Nova's source tree at the design

Re: [Openstack] Integration tests

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. __

[Openstack] Screencasts ...

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. ___

Re: [Openstack] A possible alternative to Gerrit ...

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: openstack-bounces+sandy.walsh=rackspace@lis

Re: [Openstack] A possible alternative to Gerrit ...

he only real "con" I can think 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

Re: [Openstack] A possible alternative to Gerrit ...

7;t consider this the +2" ... 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@list

Re: [Openstack] Standardizing External APIs

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

Re: [Openstack] Standardizing External APIs

+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. _

Re: [Openstack] A possible alternative to Gerrit ...

ad 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: [Op

Re: [Openstack] A possible alternative to Gerrit ...

gt; > *From:* openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net > [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on > behalf of Stefano Maffulli [smaffu...@gmail.com] > *Sent:* Monday, Septembe

Re: [Openstack] A possible alternative to Gerrit ...

tefano 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 mailto:sandy.wa...@rackspace.com>> That said, whether we use roundabout or use the code

Re: [Openstack] A possible alternative to Gerrit ...

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 th

Re: [Openstack] A possible alternative to Gerrit ...

> 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 "lgtm"s to determine if a commit is approved to be merg

Re: [Openstack] A possible alternative to Gerrit ...

Thanks Jay, I was messing around with my website last night (adding django) ... so the new url of the mockup is http://www.darksecretsoftware.com/static/hubcap.html -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-boun

Re: [Openstack] A possible alternative to Gerrit ...

d.net 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 sp

[Openstack] A possible alternative to Gerrit ...

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

Re: [Openstack] New nova service proposal

>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. Unl

Re: [Openstack] Why are we using github again?

"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;

Re: [Openstack] Why are we using github again?

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

Re: [Openstack] Improving test coverage and how you can help out!

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

Re: [Openstack] Questions About test_localization.py

Exactly. -S From: Zed A. Shaw [zeds...@zedshaw.com] What if you think we just ditch this unit test and I wrote a "gettext checker" similar to pep8? That might be way more useful, since these aren't failures in code, just failure in convention, and then I

Re: [Openstack] Questions About test_localization.py

> 3. Maybe, write out a list of _() calls that aren't translated yet. Not sure > if this is best in a test or as a tool though. > > What you think? Good idea. I like the way pep8 is run after the tests succeed. I can still hook it into bzr pre-commit or run it independently. +1 as a tool -S T

Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?

___ From: Soren Hansen [so...@linux2go.dk] > I can think of a number of reasons why using ipv6 addresses are a bad idea. Sorry for the red-herring on the IPv6 thing. I only mentioned it in terms of being able to use it for zone-routing. I wasn't proposing usi

Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?

From: Ewan Mellor [ewan.mel...@eu.citrix.com] > If so, then I would say that your proposed limitation above is not > acceptable. We don't want a situation where tenants have to stop using the > EC2 API as soon as their service provider wants to offer a rich set of > offerings. Hmm, two concer

Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?

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: M

Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?

+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 [openstack-bounces

Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?

How is nova-- any different than: ---- Where // (or some subset of them) are reserved/regulated? -S This email may include confidential information. If you received it in error, please delete it. ___ Mai

Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?

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: nova.compute.api:

Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?

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: nova.compute.api:create_instance() vs. nova.business_layer:create_instance()

Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?

mment? -S 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

Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?

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 en

Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?

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 R

Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?

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 ch

Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?

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 : openstack@lists

Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?

+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

Re: [Openstack] Cross-zone instance identifiers in EC2 API - Is it worth the effort?

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

Re: [Openstack] distributed and heterogeneous schedulers

treading on another services updates) ... perhaps some sort of atomic time check/update? -S From: Dong-In David Kang [dk...@isi.edu] Sent: Monday, June 06, 2011 11:45 AM To: Sandy Walsh Cc: Mark Washenberger; openstack@lists.launchpad.net; Jay Pipes; Ed

[Openstack] Distributed Scheduler - Developer Docs ...

https://code.launchpad.net/~sandy-walsh/nova/zones-dev-docs/+merge/62870 Please let me know how it needs to be changed (I'm sure it does). Or, if there are illustrations you'd like to see to make some point clear, that would be good to know too. Cheers, Sandy Confidentiality Notice: This e-mail mes

Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...

des listen for Flavors on their Stripe only This implies we 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

Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...

t without creating a single point of failure? Regardless ... it's a great idea and definitely one that deserves more consideration. Thanks! -S ____ From: Soren Hansen [so...@linux2go.dk] Sent: Tuesday, May 24, 2011 4:56 PM To: Sandy Walsh Cc: openstack

Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...

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:

Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...

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

Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...

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 t

Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...

ated ID's)? -S 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

Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...

Thanks to all for the input. I don't think we've really come to any conclusions for the near term. Unless someone screams, we will be proceeding along the following lines: 1. Adding PUT /zones/server/ to create an instance that will return a Reservation ID (a UUID). It will also accept a num-in

Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...

nd like great features albeit ones that could wait on a future revision of the api. Apologies if I'm speaking out of turn and should just read up on scheduler code! "Sandy Walsh" said: > ___ > Mailing list: https://launchpad.net/~ope

Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...

From: Jorge Williams > So this is 2.0 API stuff -- right. Well, we need it now ... so we have to find a short term solution. > Why not simply have a request on the server list with the reservation id as a > parameter. > This can easily be supported as an extension. > > So GET /servers/detail?R

Re: [Openstack] OpenStack API, Reservation ID's and Num Instances ...

Cool, I think you all understand the concerns here: 1. We can't treat the InstanceID as a ReservationID since they do two different things. InstanceID's are unique per instance and ReservationID's might span N instances. I don't like the idea of overloading these concepts. How is the caller sup

[Openstack] OpenStack API, Reservation ID's and Num Instances ...

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 allocat

Re: [Openstack] python-novaclient vs. python-openstack.compute

from that quarter. Gabe On Wednesday, May 18, 2011 10:03am, "Sandy Walsh" 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 contri

Re: [Openstack] python-novaclient vs. python-openstack.compute

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

Re: [Openstack] python-novaclient vs. python-openstack.compute

d not separate. -S ________ 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&#x

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 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

Re: [Openstack] python-novaclient

Awesome ... thanks S! -S From: openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net [openstack-bounces+sandy.walsh=rackspace@lists.launchpad.net] on behalf of Soren Hansen [so...@linux2go.dk] Sent: Monday, May 16, 2011 4:43 PM To: openstack

Re: [Openstack] dist-scheduler-1 merge

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 s

Re: [Openstack] dist-scheduler-1 merge

we really need to clean up the parameter lists coming from nova.compute.api:create() into the schedulers ... it's *args/**kwargs hell right now. From: Lorin Hochstein [lo...@isi.edu] Sent: Friday, May 13, 2011 11:50 AM To: Sandy Walsh Cc: do...@pand

Re: [Openstack] Zones / distributed scheduler question

From: Lorin Hochstein [lo...@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 f

Re: [Openstack] Zones / distributed scheduler question

merge-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...@is

Re: [Openstack] Zones / distributed scheduler question

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 instance

Re: [Openstack] Extending Openstack's scheduling capabilities

Hi Luis, To create a new Scheduler you simply have to derive from the nova.scheduler.Scheduler class and override the schedule() method. Pretty simple. But, as you mention, the existing schedulers are rather light. Here is the link to my summit presentation on Zones and the new Distributed S

Re: [Openstack] Discussion on October Design Summit Locations

+1 Orlando is where people go to die ... but don't. > PLEASE FOR THE LOVE OF ALL THAT IS HOLY DO NOT MAKE ME GO TO ORLANDO > FOR ANOTHER CONFERENCE. kthxbye > > Monty Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and c

Re: [Openstack] Separation of IRC Channels

Yup, seems to work for Django. From: Josh Kearney [j...@jk0.org] I like this approach. On Wed, May 4, 2011 at 1:19 PM, Ant Messerli mailto:amess...@rackspace.com>> wrote: So it sounds like the better path would be to just keep two channels for now, see how that

Re: [Openstack] Proposing an Identity Service in OpenStack (a.k.a. Auth)

Excellent ... timely and much needed! For completeness here is the link to Zone AuthZ requirements: http://wiki.openstack.org/FederatedAuthZwithZones Look forward to helping out where I can. -S From: openstack

Re: [Openstack] API for remotely controlling nova-manage

I think part of the problem is there are some operations in nova-manage that require nova to not be running: - creating the initial project - creating the initial user etc for anything beyond these basic bootstrapping operations, layering something on the admin-only portion of the OS API is pre

Re: [Openstack] Proposal for Ed Leafe to join Nova-Core

+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 Su

Re: [Openstack] distributed and heterogeneous schedulers

note 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] distr

Re: [Openstack] distributed and heterogeneous schedulers

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 > s

Re: [Openstack] distributed and heterogeneous schedulers

this is all ephemeral and are raw python data structures. ie. make them as rich as you like. We could replace the AZ stuff with the scheduler/zone manager approach to lessen confusion? -S From: Jay Pipes [jaypi...@gmail.com] Sent: Friday, April 15, 201

Re: [Openstack] distributed and heterogeneous schedulers

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 t

Re: [Openstack] Summit Talk: Information session on Zones? Any interest?

> > 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

[Openstack] Summit Talk: Information session on Zones? Any interest?

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 e-m

Re: [Openstack] distributed and heterogeneous schedulers

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

Re: [Openstack] distributed and heterogeneous schedulers

> 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 > a

Re: [Openstack] Commas and semicolons

-S 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" wrote: > >Capabilities are just multi-value key-value pair

Re: [Openstack] Cactus RCFreeze now in effect

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! >

<    1   2   3   >