I'm working on an incident system that my company, as an OpenStack operator,
will use to support our deployment of OpenStack. Our first features all involve
outside tools creating incidents, but It seems like it would be beneficial to
define a standard incident API so that core openstack
There's been a lot of interest in a finer-grained Vary function (i.e.,
something that lets you specify the cache key on something more flexible than
just whole headers). We're working a a spec in the background, but of course
caches will need to support it...
Cheers,
On 05/09/2011, at 3:43
Monty Taylor wrote:
I understand some of you are not comfortable with Gerrit [...]
Thanks for this explanation.
With this many devs, there will NEVER (and I cannot stress that word
never enough is a textual email) be full agreement on developer tooling.
However, what we can do is take in the
2011/9/7 Bryan Taylor btay...@rackspace.com:
I'm working on an incident system that my company, as an OpenStack operator,
will use to support our deployment of OpenStack.
Can you explain what you mean by incidents?
--
Soren Hansen | http://linux2go.dk/
Ubuntu Developer |
Thanks for the reply Monty.
The major argument I've heard to date about using something other than Gerrit
is the effort gone into tying into the CI system. I buy those arguments and
support not reinventing the wheel. Roundabout seemed like the logical point of
integration for hubcap, but if
Hello again -
In yesterday's team meeting, Brian Lamar brought up a good point - why name
the API projects after the project name, why not the product name? This
makes a lot of sense to me. So the names for the API repos will be:
compute-api
identity-api (should this be auth-api?)
image-api
2011/9/7 Sandy Walsh sandy.wa...@rackspace.com:
We're talking simple string parsing here. The last keyword from a user is
that users vote. Multiple pull requests would be equally easy to support with
a !new_vote command (or some such thing).
The critical point has never been whether we could
Sorry do you mean by security incidents ? kindly explain
/Zeeshan
On Wed, Sep 7, 2011 at 2:20 PM, Soren Hansen so...@linux2go.dk wrote:
2011/9/7 Bryan Taylor btay...@rackspace.com:
I'm working on an incident system that my company, as an OpenStack
operator,
will use to support our
Hi everyone,
As announced at the meeting yesterday, the session proposal for the main
tracks of the Design Summit is now open at http://summit.openstack.org
-- you have until September 27 to submit your session topics.
I wrote a blog post about the process at: http://wp.me/pqeAF-bX
Let me know
Good points Soren ... I completely understand those use cases.
I think LP does that stuff very well. Since the motive from the last summit was
to go Github, my immediate (developer) reaction is to think of how Hubcap would
handle them.
But standing back, it brings us back to the debate of why
+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.
I meant what is the use case since i have used eucalyptus in production and
now using opennebula for venus-c.eu project, so i want to see what is the
usecase/userstory for this push notification idea.
/Zee
On Wed, Sep 7, 2011 at 3:52 PM, Sandy Walsh sandy.wa...@rackspace.comwrote:
+1
use case ?
/Zee
On Wed, Sep 7, 2011 at 3:02 PM, George Reese george.re...@enstratus.comwrote:
This should fall under the more general push notifications API.
On Sep 7, 2011, at 6:20 AM, Soren Hansen wrote:
2011/9/7 Bryan Taylor btay...@rackspace.com:
I'm working on an incident system
See:
http://broadcast.oreilly.com/2011/04/proposal-for-cloud-state-notifications.html
and
http://broadcast.oreilly.com/2010/02/towards-event-driven-cloud-apis.html
On Sep 7, 2011, at 7:52 AM, Sandy Walsh wrote:
+1
From: George Reese
I'd be fine with that, too, Anne.
Cheers!
jay
On Wed, Sep 7, 2011 at 7:57 AM, Anne Gentle a...@openstack.org wrote:
Hello again -
In yesterday's team meeting, Brian Lamar brought up a good point - why name
the API projects after the project name, why not the product name? This
makes a lot of
I like it and +1 for identity-api since it will have both authZ and authN
capabilities.
From: openstack-bounces+joe.savak=rackspace@lists.launchpad.net
[mailto:openstack-bounces+joe.savak=rackspace@lists.launchpad.net] On
Behalf Of Anne Gentle
Sent: Wednesday, September 07, 2011 6:57
Great links ... thanks George.
Sounds very much like the work that cerberus and dragon have done
http://www.mail-archive.com/openstack@lists.launchpad.net/msg02278.html
https://github.com/Cerberus98/yagi
http://wiki.openstack.org/SystemUsageData
-S
On Wed, Sep 7, 2011 at 6:54 AM, Soren Hansen so...@linux2go.dk wrote:
The critical point has never been whether we could reliably detect
people's votes (even though I really dislike parsing free-form text to
extract critical information like this). Even though Launchpad offers
voting
Yup, if you look at
http://www.darksecretsoftware.com/static/hubcap.html
you'll see there's a slot there for core non-core approvals. We get the core
approvers from the repos teams.
I like the idea of another keyword than !lgtm for cores to say I approve, but
don't consider this the +2 ...
On Wed, Sep 7, 2011 at 11:18 AM, Sandy Walsh sandy.wa...@rackspace.com wrote:
Yup, if you look at
http://www.darksecretsoftware.com/static/hubcap.html
you'll see there's a slot there for core non-core approvals. We get the
core approvers from the repos teams.
And where are the comments in
On Wed, Sep 7, 2011 at 11:42 AM, Kevin L. Mitchell
kevin.mitch...@rackspace.com wrote:
On Wed, 2011-09-07 at 11:24 -0400, Jay Pipes wrote:
In addition, this doesn't prevent anyone on the core team from doing a
straight close and merge of the pull request into trunk, potentially
breaking trunk.
On Wed, 2011-09-07 at 11:24 -0400, Jay Pipes wrote:
In addition, this doesn't prevent anyone on the core team from doing a
straight close and merge of the pull request into trunk, potentially
breaking trunk.
So far as I know, there's no requirement that someone have merge
authority on a
On Wed, Sep 7, 2011 at 11:34 AM, Sandy Walsh sandy.wa...@rackspace.com wrote:
But yes, there is a risk that a core member could just hit merge and close
and break trunk. That's perhaps the only real con I can think of.
That's the entire point of gerrit and a gated trunk, Sandy :)
-jay
Heh. Like I mentioned at the top of the thread, it's just a hack. We're
currently merging with Roundabout to handle the Jenkins integration and make
roundabout's workflow strategies pluggable.
So, right now only the pull request and core members are real, the votes are
faked out.
The output
On Wed, Sep 7, 2011 at 10:59 AM, Jay Pipes jaypi...@gmail.com wrote:
On Wed, Sep 7, 2011 at 11:42 AM, Kevin L. Mitchell
kevin.mitch...@rackspace.com wrote:
On Wed, 2011-09-07 at 11:24 -0400, Jay Pipes wrote:
In addition, this doesn't prevent anyone on the core team from doing a
straight
On Wed, 2011-09-07 at 11:59 -0400, Jay Pipes wrote:
So far as I know, there's no requirement that someone have merge
authority on a project in order to comment on pull requests. Do cores
have direct access to the openstack repos right now, and if they do,
what's to stop them from merging
On Wed, Sep 7, 2011 at 12:13 PM, Kevin L. Mitchell
kevin.mitch...@rackspace.com wrote:
On Wed, 2011-09-07 at 11:59 -0400, Jay Pipes wrote:
So far as I know, there's no requirement that someone have merge
authority on a project in order to comment on pull requests. Do cores
have direct
On Wed, Sep 07, 2011, Jay Pipes jaypi...@gmail.com wrote:
On Wed, Sep 7, 2011 at 11:34 AM, Sandy Walsh sandy.wa...@rackspace.com
wrote:
But yes, there is a risk that a core member could just hit merge and
close and break trunk. That's perhaps the only real con I can think of.
That's the
On Wed, Sep 7, 2011 at 12:38 PM, Monsyne Dragon mdra...@rackspace.com wrote:
This is basically what gerrit and our current LP setup do. it's just a
matter of permissions.
Couldn't have said it better myself! Thanks, Monsyne!
-jay
___
Mailing list:
On Sep 7, 2011, at 10:34 AM, Sandy Walsh wrote:
Heh. Like I mentioned at the top of the thread, it's just a hack. We're
currently merging with Roundabout to handle the Jenkins integration and make
roundabout's workflow strategies pluggable.
So, right now only the pull request and core
On Wed, Sep 7, 2011 at 12:24 PM, Johannes Erdfelt johan...@erdfelt.com wrote:
On Wed, Sep 07, 2011, Jay Pipes jaypi...@gmail.com wrote:
On Wed, Sep 7, 2011 at 11:34 AM, Sandy Walsh sandy.wa...@rackspace.com
wrote:
But yes, there is a risk that a core member could just hit merge and
close
On 09/07/2011 04:13 AM, Sandy Walsh wrote:
Thanks for the reply Monty.
My pleasure! Thanks for both your interest and your energy on the subject!
For the record ... bugs can be filed against any element of the CI
system at:
https://bugs.launchpad.net/openstack-ci
The major argument I've
On Wed, Sep 07, 2011, Jay Pipes jaypi...@gmail.com wrote:
On Wed, Sep 7, 2011 at 12:24 PM, Johannes Erdfelt johan...@erdfelt.com
wrote:
Why do core members have that merge and close option? Wouldn't it make
more sense to restrict that to the Jenkins account?
I still think you can do a
On Wed, Sep 07, 2011, Jay Pipes jaypi...@gmail.com wrote:
The problem is that instead of spending time coding on features and
bugs for Nova, Glance, Swift and Keystone, a bunch of devs are instead
spending time working on an alternate solution to what has already
been decided by the PPB,
FWIW, we've received excellent support from the CI team on Gerrit and it
is working well for Keystone. The workflow has been simplified with the
rfc.sh script and the system has been available and performing reliably.
The ability to pull down, modify, and resubmit reviews works well and is
simple
On Wed, Sep 7, 2011 at 1:03 PM, Johannes Erdfelt johan...@erdfelt.com wrote:
On Wed, Sep 07, 2011, Jay Pipes jaypi...@gmail.com wrote:
On Wed, Sep 7, 2011 at 12:24 PM, Johannes Erdfelt johan...@erdfelt.com
wrote:
Why do core members have that merge and close option? Wouldn't it make
more
On Wed, Sep 7, 2011 at 1:19 PM, Johannes Erdfelt johan...@erdfelt.com wrote:
On Wed, Sep 07, 2011, Jay Pipes jaypi...@gmail.com wrote:
The problem is that instead of spending time coding on features and
bugs for Nova, Glance, Swift and Keystone, a bunch of devs are instead
spending time
On Wed, Sep 7, 2011 at 7:57 AM, Anne Gentle a...@openstack.org wrote:
Hello again -
In yesterday's team meeting, Brian Lamar brought up a good point - why name
the API projects after the project name, why not the product name? This
makes a lot of sense to me. So the names for the API repos
An incident is a form of ticket that recognizes that an existing
requirement (customer or internal) isn't being met.
On 09/07/2011 06:20 AM, Soren Hansen wrote:
2011/9/7 Bryan Taylorbtay...@rackspace.com:
I'm working on an incident system that my company, as an OpenStack operator,
will use to
On Sep 7, 2011, at 9:21 AM, Jay Pipes wrote:
The problem is that instead of spending time coding on features and
bugs for Nova, Glance, Swift and Keystone, a bunch of devs are instead
spending time working on an alternate solution to what has already
been decided by the PPB, discussed
On Wed, Sep 7, 2011 at 2:19 PM, Chris Behrens
chris.behr...@rackspace.com wrote:
On Sep 7, 2011, at 9:21 AM, Jay Pipes wrote:
The problem is that instead of spending time coding on features and
bugs for Nova, Glance, Swift and Keystone, a bunch of devs are instead
spending time working on an
On Wed, Sep 07, 2011, Monty Taylor mord...@inaugust.com wrote:
Part of this also comes from a semantic difference in how github and
gerrit view the world. On github, you develop on your personal fork, and
then you submit one of the branches in your fork to be pulled - so the
unit of review is
On Wed, Sep 07, 2011, Sandy Walsh sandy.wa...@rackspace.com wrote:
... and that's only from my first few days using Gerrit.
I'd also like to add that the when merges fail, it's not easy to figure
out why.
I had a proposed branch the was approved and then failed to merge. I
received a handful
I'm skeptical, because usually ticket creation has to be a two way
interaction because the entity asking for the ticket has to know that it
succeeded end to end and should receive a URI back so that they can
record it.
There should be a well defined API that forms the boundary between
On Sep 7, 2011, at 1:19 PM, Bryan Taylor wrote:
An incident is a form of ticket that recognizes that an existing requirement
(customer or internal) isn't being met.
On 09/07/2011 06:20 AM, Soren Hansen wrote:
2011/9/7 Bryan Taylorbtay...@rackspace.com:
I'm working on an incident system
On Sep 7, 2011, at 11:46 AM, Jay Pipes wrote:
On Wed, Sep 7, 2011 at 2:19 PM, Chris Behrens
chris.behr...@rackspace.com wrote:
On Sep 7, 2011, at 9:21 AM, Jay Pipes wrote:
The problem is that instead of spending time coding on features and
bugs for Nova, Glance, Swift and Keystone, a
Johannes Erdfelt johan...@erdfelt.com writes:
On Wed, Sep 07, 2011, Sandy Walsh sandy.wa...@rackspace.com wrote:
... and that's only from my first few days using Gerrit.
I'd also like to add that the when merges fail, it's not easy to figure
out why.
I had a proposed branch the was
Has anyone tried the xen (not xenserver) snapshot support?
From looking at how xen + libvirt is used, it would seem like the support
isn't there since from what I was looking at the xen image would have to be a
qcow2 format (and also have libvirt use a tap: disk instead of a file). From
seeing
On 09/07/2011 02:55 PM, Monsyne Dragon wrote:
Presumably you mean creating a support ticket when an error condition is
reported by OpenStack?
For Nova (compute) we have a notification api that reports various conditions.
Yes.
Nova itself would not interface with a ticketing (aka incident
Hi all,
We are hard at work getting Keystone documentation and core
functionality in place for the Diablo release. That doesn't mean we aren't
thinking ahead to Essex. You'll notice under the keystone wiki
(http://wiki.openstack.org/keystone) a call for blueprints. Please peruse
Hi Chris,
2011/9/7 Chris Behrens chris.behr...@rackspace.com
Thanks. I see them. It's not that I didn't think there would be responses.
I'm just trying to keep us on track to trying to resolve the issues while I
still complain that *I* feel we should have had some more/earlier/better
What is the expected behavior when an object uploaded using Large Object
Support
is referenced as the source for a server-side copy using X-Copy-From?
I'm still learning python, but I think what I've read is that the proxy
will do a self.get
on the aggregate file, which will then be too big
A server-side copy will consolidate the file to one object. The new target
object has the same limitations as other objects in the system (5GB).
--John
On Sep 7, 2011, at 5:34 PM, Caitlin Bestler wrote:
What is the expected behavior when an object uploaded using Large Object
Support
is
Wouldn't this mean that versions of the API for projects would then have a
version that is reflective of the release and not a spec number? Version
1.1 doesn't mean anything in Diablo if it doesn't adhere to the 1.1 guide?
The api would be versioned for diablo and we would start a new version
-Original Message-
From: Jay Pipes [mailto:jaypi...@gmail.com]
Sent: Wednesday, September 07, 2011 9:28 AM
To: Paul Voccio
Cc: Ewan Mellor; openstack-poc@lists.launchpad.net
Subject: Re: [Openstack-poc] API compatibility
On Wed, Sep 7, 2011 at 12:16 PM, Paul Voccio
55 matches
Mail list logo
