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
> i
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 t
Hi Chris,
2011/9/7 Chris Behrens
> 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
> communication on this list
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
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 man
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
>see
Johannes Erdfelt writes:
> On Wed, Sep 07, 2011, Sandy Walsh 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
> recei
On Sep 7, 2011, at 11:46 AM, Jay Pipes wrote:
> On Wed, Sep 7, 2011 at 2:19 PM, Chris Behrens
> 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 in
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 Taylor:
>>> I'm working on an incident system that my compan
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
OpenSta
On Wed, Sep 07, 2011, Sandy Walsh 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 of emails (4?) that were m
On Wed, Sep 07, 2011, Monty Taylor 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 the branch- meani
On Wed, Sep 7, 2011 at 2:19 PM, Chris Behrens
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 alternate solution t
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 publ
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 Taylor:
I'm working on an incident system that my company, as an OpenStack operator,
will use to support our deploymen
On Wed, Sep 7, 2011 at 7:57 AM, Anne Gentle 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 will be:
>
> compu
On Wed, Sep 7, 2011 at 1:19 PM, Johannes Erdfelt wrote:
> On Wed, Sep 07, 2011, 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 wh
On Wed, Sep 7, 2011 at 1:03 PM, Johannes Erdfelt wrote:
> On Wed, Sep 07, 2011, Jay Pipes wrote:
>> On Wed, Sep 7, 2011 at 12:24 PM, Johannes Erdfelt
>> wrote:
>> > Why do core members have that "merge and close" option? Wouldn't it make
>> > more sense to restrict that to the Jenkins account?
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 07, 2011, 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 publicly,
On Wed, Sep 07, 2011, Jay Pipes wrote:
> On Wed, Sep 7, 2011 at 12:24 PM, Johannes Erdfelt
> 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 gated trunk, even with githu
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 h
On Wed, Sep 7, 2011 at 12:24 PM, Johannes Erdfelt wrote:
> On Wed, Sep 07, 2011, Jay Pipes wrote:
>> On Wed, Sep 7, 2011 at 11:34 AM, Sandy Walsh
>> 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"
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 cor
On Wed, Sep 7, 2011 at 12:38 PM, Monsyne Dragon 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: https://launchpad.ne
On Wed, Sep 07, 2011, Jay Pipes wrote:
> On Wed, Sep 7, 2011 at 11:34 AM, Sandy Walsh
> 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 ga
On Wed, Sep 7, 2011 at 12:13 PM, Kevin L. Mitchell
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 access to the openstack
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 m
On Wed, Sep 7, 2011 at 10:59 AM, Jay Pipes wrote:
> On Wed, Sep 7, 2011 at 11:42 AM, Kevin L. Mitchell
> 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 in
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 fr
On Wed, Sep 7, 2011 at 11:34 AM, Sandy Walsh 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
__
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 proj
On Wed, Sep 7, 2011 at 11:42 AM, Kevin L. Mitchell
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.
>
> So far as I know,
On Wed, Sep 7, 2011 at 11:18 AM, Sandy Walsh 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
https://github.com/rack
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" ... p
On Wed, Sep 7, 2011 at 6:54 AM, Soren Hansen 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 information in a structu
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
From
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
I'd be fine with that, too, Anne.
Cheers!
jay
On Wed, Sep 7, 2011 at 7:57 AM, Anne Gentle 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. S
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 [george.re
use case ?
/Zee
On Wed, Sep 7, 2011 at 3:02 PM, George Reese wrote:
> 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 :
> >> I'm working on an incident system that my company, as an OpenStack
> operat
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 wrote:
> +1
>
> __
+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.
_
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 n
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 :
>> 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 y
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 if
Sorry do you mean by security incidents ? kindly explain
/Zeeshan
On Wed, Sep 7, 2011 at 2:20 PM, Soren Hansen wrote:
> 2011/9/7 Bryan Taylor :
> > I'm working on an incident system that my company, as an OpenStack
> operator,
> > will use to support our deployment of OpenStack.
>
> Can you exp
2011/9/7 Sandy Walsh :
> 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 reliably detect
people
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
storag
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 the
2011/9/7 Bryan Taylor :
> 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 | http://www.ubuntu.com/
OpenSt
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
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
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 compon
54 matches
Mail list logo
