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
, 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 Walsh has a new python-cloudservers
library (and accompanying
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.
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 devin.car...@gmail.commailto:devin.car...@gmail.com
Date: Thu, 3 Feb 2011 12:02:38 -0800
To: Monsyne Dragon
+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:
] 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 thought
I'd kick up the dust again.
I'm
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?
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
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:
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
, 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
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
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.
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.
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 work
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/*
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.
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
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
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
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
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
[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'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
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
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:
+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
+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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
# 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
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
+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
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
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:
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
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
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
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
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
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
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
=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.
1 - 100 of 219 matches
Mail list logo
