Thanks for the info. It does seem like most OpenStack projects have some
concept of a "scheduler", as you mentioned. Perhaps that's expected in any
distributed system.
Is it expected or assumed that Gantt will become the common scheduler for all
OpenStack projects? That is, is Gantt's plan and/
On Aug 12, 2014, at 11:08 AM, Doug Hellmann wrote:
>
> On Aug 12, 2014, at 1:44 PM, Dolph Mathews wrote:
>
>>
>> On Tue, Aug 12, 2014 at 12:30 AM, Joe Gordon wrote:
>>
>>
>>
>> On Fri, Aug 8, 2014 at 6:58 AM, Kyle Mestery wrote:
>> On Thu, Aug 7, 2014 at 1:26 PM, Joe Gordon wrote:
>> >
If you do not have the gatekeeper explicitly referenced in your proxy pipeline,
Swift will automatically add it.
--John
On Aug 19, 2014, at 3:09 AM, Daisuke Morita
wrote:
>
> Hi,
>
> Can gatekeeper middleware be removed from pipeline?
> This does not mean that i want to use Swift without
I think Anne makes some excellent points about the pattern being proposed being
unlikely to be commonly implemented across all the programs (or, at best, very
difficult). Let's not try to formalize another "best practice" that works many
times and force it to work every time. Here's an alternate
Swift 2.1.0.rc1 has been tagged as our release candidate for 2.1.0. The plan is
to let this RC soak for a week and then do the final release on Sept 1.
Please check it out and report any issues that you find.
Tag applied:
http://git.openstack.org/cgit/openstack/swift/commit/?id=8d02147d04a41477
I'm happy to announce that Swift 2.1.0 has been released. This release includes
several useful features that I'd like to highlight.
First, Swift's data placement algorithm was slightly changed to improve adding
capacity. Specifically, now when you add a new region to an existing Swift
cluster,
To test Swift directly, I used the CLI tools that Swift provides for managing
rings. I wrote the following short script:
$ cat remakerings
#!/bin/bash
swift-ring-builder object.builder create 16 3 0
for zone in {1..4}; do
for server in {200..224}; do
for drive in {1..12}; do
swift-ring-builder o
On Sep 17, 2014, at 8:43 PM, Jay Faulkner wrote:
> Comments inline.
>
>> -Original Message-
>> From: Monty Taylor [mailto:mord...@inaugust.com]
>> Sent: Wednesday, September 17, 2014 7:34 PM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] Log Rationalization --
I just release python-swiftclient 2.3.0
In addition to some smaller changes and bugfixes, the biggest changes are the
support for Keystone v3 and a refactoring that allows for better testing and
extensibility of the functionality exposed by the CLI.
https://pypi.python.org/pypi/python-swiftclie
During the past month, Swift contributors have gathered in Austin,
Hong Kong, and online to discuss projects underway. There are some
major efforts underway, and I hope to lay them out and tie them
together here, so that we all know what the goals for the next six
months are.
The biggest feature s
Please keep those discussing in the open. #openstack-swift would be a great
place to discuss what you did and figure out a general solution for others.
--john
On Nov 20, 2013, at 2:52 PM, Christian Schwede wrote:
> Thanks John for the summary - and all contributors for their work!
>
>> Other
Pete Zaitcev has been involved with Swift for a long time, both by contributing
patches and reviewing patches. I'm happy to announce that he's accepted the
responsibility of being a core reviewer for Swift.
Congrats, Pete.
--John
signature.asc
Description: Message signed with OpenPGP using
Just to add to the story, Swift uses "X-Trans-Id" and generates it in the
outer-most "catch_errors" middleware.
Swift's catch errors middleware is responsible for ensuring that the
transaction id exists on each request, and that all errors previously uncaught,
anywhere in the pipeline, are caug
How are you proposing that this integrate with Swift's account and container
quotas (especially since there may be hundreds of thousands of accounts and
millions (billions?) of containers in a single Swift cluster)? A centralized
lookup for quotas doesn't really seem to be a scalable solution.
On Dec 3, 2013, at 8:05 AM, Jay Pipes wrote:
> On 12/03/2013 10:04 AM, John Dickinson wrote:
>> How are you proposing that this integrate with Swift's account and container
>> quotas (especially since there may be hundreds of thousands of accounts and
>> millions (b
On Dec 5, 2013, at 1:36 AM, Maru Newby wrote:
>
> On Dec 3, 2013, at 12:18 AM, Joe Gordon wrote:
>
>>
>>
>>
>> On Sun, Dec 1, 2013 at 7:04 PM, John Dickinson wrote:
>> Just to add to the story, Swift uses "X-Trans-Id" and generates i
I'm happy to announce that we've released Swift 1.11.0. You can find
the high-level Launchpad details (including a link to the tarball) at
https://launchpad.net/swift/icehouse/1.11.0.
As always, you can upgrade to this release without any downtime to your
users.
Swift 1.11.0 is the work of 26 con
The basic upgrade process for all versions of Swift follow the same basic
pattern:
First for storage nodes:
On a single "canary" node:
1) stop background processes
2) upgrade packages
3) restart/reload main processes
4) start background processes
And if everything goes well there, perform the sa
Another option would be to use what we already have to our benefit. Instead of
trying to provision two meeting rooms (-meeting and -meeting-alt), use the
various other IRC channels that we already have for team meetings. This would
allow for meetings to be at the same time, but it would free up
I've seen several disconnected messages about tags in commit messages. I've
seen what is possible with the DocImpact tag, and I'd like to have some more
flexible tagging things too. I'd like to use tags for things like keeping track
of config defaults changing, specific ongoing feature work, and
On Dec 29, 2013, at 2:05 PM, Michael Still wrote:
> On Mon, Dec 30, 2013 at 8:12 AM, John Dickinson wrote:
>> I've seen several disconnected messages about tags in commit messages. I've
>> seen
>> what is possible with the DocImpact tag, and I'd like to
On Dec 29, 2013, at 5:24 PM, Michael Still wrote:
> On Mon, Dec 30, 2013 at 11:51 AM, John Dickinson wrote:
>> On Dec 29, 2013, at 2:05 PM, Michael Still wrote:
>
> [snip]
>
>>> Perhaps step one is to work out what tags we think are useful and at
>>> wha
On Dec 30, 2013, at 4:49 PM, Angus Salkeld wrote:
> On 30/12/13 13:44 -0600, Kevin L. Mitchell wrote:
>>
>> On Mon, 2013-12-30 at 11:04 +0100, Flavio Percoco wrote:
>>> I like the idea of having custom tags. I'm a bit concerned about the
>>> implications this might have with cross-project colla
Yep, you should follow https://bugs.launchpad.net/keystone/+bug/1190149 and the
related patches in each project.
--John
On Jan 16, 2014, at 10:30 PM, Miller, Mark M (EB SW Cloud - R&D - Corvallis)
wrote:
> Hello,
>
> I have come across a bug or limitation when using an Apache2 SSL-WSGI fro
Today I'm happy to announce that we have released Swift 1.12.0. As
always, this is a stable release and you can upgrade to this version
of Swift with no customer downtime.
You can download the code for this release at
https://launchpad.net/swift/icehouse/1.12.0 or bug your package
provider for the
I've been keeping an eye on this thread, and it seems I actually have a few
minutes to spend on a response today.
To first answer the specific question, while there are some minor technical
concerns about oslo logging, the bigger concerns are non-technical. Some things
I'm concerned about from
On Feb 5, 2014, at 4:04 PM, Ryan Hsu wrote:
> Also, I have added a section noting crucial bugs/patches that are blocking
> Minesweeper.
Can we just put flags around them and move on?
signature.asc
Description: Message signed with OpenPGP using GPGMail
Historically, the Swift team meetings have been every other week. In order to
keep better track of things (and hopefully to get more specific attention on
languishing reviews), we're moving to a weekly meeting schedule.
New meeting time: every Wednesday at 1900UTC in #openstack-meeting
The meet
Sounds like a good plan. My only concern with the import is that the users are
matched up, and it looks like that's being handled. The only reason I've wanted
to keep LP Answers open is to not lose that content, and this takes care of
that. Thanks for doing it, and lgtm.
--John
On Feb 6, 201
As many of you surely noticed, we had some significant significant
gate issues in the last day. It's fixed now, and I've got the details below.
The root cause of the issue was a lack of proper testing in python-
swiftclient. We've made some improvements here in the last few hours,
but improving th
I'm pleased to announce a couple of big releases for python-swiftclient:
versions 1.9.0 and 2.0.2. You can find them both on PyPI:
https://pypi.python.org/pypi/python-swiftclient/2.0.2
https://pypi.python.org/pypi/python-swiftclient/1.9.0
So why the two releases? The 2.0.2 release is the result o
I'm please to announce that OpenStack Swift 1.13 has been released.
This release has some important new features (highlighted below), and
it also serves as a good checkpoint before Swift's final release in
the Icehouse cycle.
Launchpad page for this release: https://launchpad.net/swift/icehouse/1.
Thanks for doing this, Stef. I've closed LP answers for Swift. All new
questions should go to ask.openstack.org
--John
On Mar 3, 2014, at 3:26 PM, Stefano Maffulli wrote:
> And we're done!
>
> All questions and answers on Launchpad Answers have been imported in Ask
> OpenStack
>
> Check it
This is great!
Sean, I agree with your analysis.
gate-swift-pep8 (yes)
gate-swift-docs (yes)
gate-swift-python27 (yes)
gate-swift-tox-func (yes)
check-swift-dsvm-functional (yes)
check-tempest-dsvm-full(to further ensure glance/heat/cinder checking)
check-grenade-dsvm (I can go either wa
All,
I'm happy to say that the Swift 2.2.1 release candidate is available.
http://tarballs.openstack.org/swift/swift-2.2.1c1.tar.gz
Please take a look, and if nothing is found, we'll release this as the final
2.2.1 version at the end of the week.
This release includes a lot of great improvemen
I'm happy to announce the release of Swift 2.2.1. The work of 28 contributors
(including 8 first-time contributors), this release is definitely
operator-centric. I recommend that you upgrade; as always you can upgrade to
this release with no customer downtime.
Get the release: https://launchpad
On May 1, 2014, at 10:32 AM, Shyam Prasad N wrote:
> Hi Chuck,
> Thanks for the reply.
>
> The reason for such weight distribution seems to do with the ring rebalance
> command. I've scripted the disk addition (and rebalance) process to the ring
> using a wrapper command. When I trigger the
To add some color, Swift supports both single conf files and conf.d
directory-based configs. See
http://docs.openstack.org/developer/swift/deployment_guide.html#general-service-configuration.
The "single config file" pattern is quite useful for simpler configurations,
but the directory-based on
One of the advantages of the program concept within OpenStack is that separate
code projects with complementary goals can be managed under the same program
without needing to be the same codebase. The most obvious example across every
program are the "server" and "client" projects under most pro
This week's Swift team meeting will spend time looking at the Swift-related
conference talks and summit design sessions.
https://wiki.openstack.org/wiki/Meetings/Swift
If you are leading a session topic or giving a conference talk, please attend
this week's meeting. I want to make sure you have
tl;dr: (1) the current tag names used don't work and we need
something else. (2) Swift (at least) needs to burn a
release number with a new tag
The current process of release is:
1) branch milestone-proposed (hereafter, m-p) from master
2) tag m-p with an RC tag (eg 1.13.1.rc1)
* note that si
Can you explain how PKI info is compressible? I thought it was encrypted, which
should mean you can't compress it right?
--John
On May 21, 2014, at 8:32 AM, Morgan Fainberg wrote:
> The keystone team is also looking at ways to reduce the data contained in the
> token. Coupled with the co
M, Dolph Mathews wrote:
>
> On Wed, May 21, 2014 at 10:41 AM, John Dickinson wrote:
> Can you explain how PKI info is compressible? I thought it was encrypted,
> which should mean you can't compress it right?
>
> They're not encrypted - just signed and then ba
On May 21, 2014, at 4:26 PM, Adam Young wrote:
> On 05/21/2014 03:36 PM, Kurt Griffiths wrote:
>> Good to know, thanks for clarifying. One thing I’m still fuzzy on, however,
>> is why we want to deprecate use of UUID tokens in the first place? I’m just
>> trying to understand the history here.
I'm happy to announce that python-swiftclient 2.1.0 has just been released!
https://pypi.python.org/pypi/python-swiftclient/
This release includes support for Python 3.3. I want to specifically thank
Tristan Cacqueray, Chmouel Boudjnah, Alex Gaynor, and Christian Schwede for
working on the py3
We've been working for a long time on the feature/ec branch in the swift repo.
It's now "done" and needs to be merged into master to be generally available.
Here's how the integration is going to work:
1) The feature/ec branch will be refactored into a series of dependent
reviewable patches
2)
The series of patches implementing storage policies in Swift has been proposed
to master. The first patch set is https://review.openstack.org/#/c/96026/.
This is a major feature in Swift, and it requires a lot of work in reviewing
and integrating it. In order to focus as reviewers, Swift is unde
For both the security and the log line length, Swift is by default just
displaying the first 16 bytes of the token.
--John
On Jun 11, 2014, at 12:39 PM, Morgan Fainberg wrote:
> This stems a bit further than just reduction in noise in the logs. Think of
> this from a case of security (with
On Mar 19, 2014, at 12:27 PM, Julien Danjou wrote:
> On Wed, Mar 19 2014, Kurt Griffiths wrote:
>
>> That begs the question, *why* is that unlikely to change?
>
> Because that project is Swift.
If you look at the Swift code, you'll see that swob is not a replacement for
either Pecan or Falcon
tl;dr: Icehouse won't have storage policies; merging the work into master will
be in "logical chunks" after Swift's contribution to the Icehouse release.
Here's a quick update on what's been going on in the Swift community with
storage policies.
Many Swift contributors have been working on stor
On Mar 25, 2014, at 12:11 PM, Kurt Griffiths
wrote:
>> As a quick review, storage policies allow objects to be stored across a
>> particular subset of hardware...and with a particular storage algorithm
>
> Having worked on backup software in the past, this sounds interesting. :D
>
> What is t
I'm pleased to announce that Alistair Coles and Christian Schwede have both
joined the Swift core team. They have both been very active in the Swift
community, contributing both code and reviews. Both Alistair and Christian work
with large-scale production Swift clusters, and I'm happy to have t
I'm announcing my candidacy for Swift PTL. I've been involved with Swift
specifically and OpenStack in general since the beginning. I'd like to continue
to serve in the role as Swift PTL.
Swift has grown quite a bit over the last 4 years. In this past year, we've
added major new features refact
I'd like to announce my Technical Committee candidacy.
I've been involved with OpenStack since it began. I'm one of the original
authors of Swift, and I have been serving as PTL since the position was
established. I'm employed by SwiftStack, a company building management and
integration tools f
I put together links to every candidate's nomination email at
https://wiki.openstack.org/wiki/Governance/TechnicalCommittee/candidates
--John
On Apr 18, 2014, at 8:29 AM, Anita Kuno wrote:
> On 04/18/2014 11:22 AM, Anita Kuno wrote:
>> Voting for the TC Election is now open and will remain
I had completely missed the links Anita had put together. Use her list (ie the
officially updated one).
https://wiki.openstack.org/wiki/TC_Elections_April_2014#Candidates
Sorry about that, Anita!
--John
On Apr 18, 2014, at 11:33 AM, John Dickinson wrote:
> I put together links to ev
I've pushed the initial schedule for the Swift summit sessions to
http://junodesignsummit.sched.org.
There were 21 sessions proposed for 8 available slots, so most are not able to
be selected. (Thanks Cinder for taking one of our proposed ones!)
Swift's sessions are split over two days. When se
On Sep 19, 2014, at 5:46 AM, John Griffith wrote:
>
>
> On Fri, Sep 19, 2014 at 4:33 AM, Thierry Carrez wrote:
> Vishvananda Ishaya wrote:
> > Great writeup. I think there are some great concrete suggestions here.
> >
> > A couple more:
> >
> > 1. I think we need a better name for Layer #1 th
I'm announcing my candidacy for Swift PTL. I've been involved with Swift
specifically and OpenStack in general since the beginning. I'd like to continue
to serve in the role as Swift PTL.
In my last candidacy email[1], I talked about several things I wanted to focus
on in Swift.
1) Storage pol
> On Oct 29, 2014, at 3:32 PM, Eoghan Glynn wrote:
>
>
> Folks,
>
> I haven't seen the customary number-crunching on the recent TC election,
> so I quickly ran the numbers myself.
>
> Voter Turnout
> =
>
> The turnout rate continues to decline, in this case from 29.7% to 26.7%.
>
Adam,
I'm not sure why you've marked Swift URLs as having their own scheme. It's true
that Swift doesn't have the concept of "admin" URLs, but in general if Swift
were to assume some URL path prefix, I'm not sure why it wouldn't work (for
some definition of work).
Other issues might be the fac
Through extensive work from the entirety of the Swift dev team over the past
year, storage policies have landed in Swift. Last Friday, we merged commit
1feaf6e2 which brings storage polices into master.
I especially would like to publicly thank Paul Luse (Intel), Clay Gerrard
(SwiftStack), and
Great questions. I'll answer inline.
On Jun 27, 2014, at 2:54 AM, Eoghan Glynn wrote:
>
> Hi Swiftsters!
>
> A basic question about swift eventual- versus strong-consistency.
> The context is potentially using swift as a store for metric data.
>
> Say datapoints {p1, p2, ..., p_i} are stored
In general, you're right. It's pretty important to know what's going on in the
cluster. However, the checks for these background daemons shouldn't be done in
the wsgi servers. Generally, we've stayed away from a lot of process monitoring
in the Swift core. That it, Swift already works around fai
I'm happy to announce that Swift 2.0.0 has been officially released! You can
get the tarball at http://tarballs.openstack.org/swift/swift-2.0.0.tar.gz.
This release is a huge milestone in the history of Swift. This release includes
storage policies, a set of features I've often said is the most
There are a couple of places to look to see the current dev effort in Swift
around ACLs.
In no particular order:
* Supporting a service token in Swift https://review.openstack.org/#/c/105228/
* Adding policy engine support to Swift https://review.openstack.org/#/c/89568/
* Fixing ACLs to work wi
We've been chatting in IRC, but for the mailing list archives, yes! we'd love
to see patches to improve this.
--John
On Jul 15, 2014, at 1:22 PM, Tatiana Al-Chueyr Martins
wrote:
> Hello!
>
> I'm new to both Swift and OpenStack, I hope you can help me.
>
> Considering statsd is enabled, ea
I'm happy to announce that python-swiftclient 2.2.0 has been released.
This release has the following significant features:
* Ability to set a storage policy on container and object upload
* Ability to generate Swift temporary URLs from the CLI and SDK
* Added context-sensitive help to the CLI co
Using hostnames instead of IPs is, as mentioned above, something under
consideration in that patch.
However, note that until now, we've intentionally kept it as just IP addresses
since using hostnames adds a lot of operational complexity and burden. I
realize that hostnames may be preferred in
th
> the ip address. In this case swift copy objects that related to the node.
>
> If above understanding is true, it is better to have ability for using FQDN
> in Ring
> files in addition to ip addresses. What do you think?
>
> On Thursday, July 24, 2014 12:55 A
but
in the absence of a decision, we've so-far defaulted to "less code has less
bugs" and not yet written or merged it.
--John
On Jul 23, 2014, at 10:07 PM, Osanai, Hisashi
wrote:
>
> Thank you for the quick response.
>
> On Thursday, July 24, 2014 12:51 PM,
On Jul 24, 2014, at 3:25 PM, Sean Dague wrote:
> On 07/24/2014 06:15 PM, Angus Salkeld wrote:
>> On Wed, 2014-07-23 at 14:39 -0700, James E. Blair wrote:
>>> OpenStack has a substantial CI system that is core to its development
>>> process. The goals of the system are to facilitate merging good
I'm happy to share that Paul Luse has join Swift's core reviewer team. Paul has
provided a ton of leadership, insight, and code during the past year. He was
instrumental in getting storage policies written, and he's actively involved in
the current work around erasure code support.
Welcome, Pau
Can you please add Swift as well?
--John
On Aug 4, 2014, at 9:54 AM, Andreas Jaeger wrote:
> Great, I've updated my patch to add neutron and nova to the index page.
>
> For now read the specs using:
> http://specs.openstack.org/openstack/neutron-specs/
> http://specs.openstack.org/openstack/
Alex,
You raise two issues, so let me address them independently.
First, you discuss protecting memcache for unauthorized access. Yes, this is
something that every deployer of memcache (whether in conjunction with Swift or
not) needs to consider. Unchecked access to memcache can allow informati
I would like to nominate myself for PTL of Swift.
I've been involved in OpenStack Swift since it started, and I'd like
to share a few of the thins in-progress and where I want to see Swift
go.
Swift has always been a world-class storage system, proven at scale
and production-ready from day one. I
I tagged and released a new version of python-swiftclient this morning,
specifically to get around some painful dependency issues (especially on older
systems). Find the new version at
https://pypi.python.org/pypi/python-swiftclient/1.7.0 on pypi. Below is the tag
message:
This release is prom
I'd like to announce my candidacy to the OpenStack Technical Committee.
As the Swift PTL, I've been involved in the TC for a while (and the PPB before
that and the POC before that). I've seen OpenStack grow the very beginning, and
I'm very proud to be a part of it.
As we all know, OpenStack has
Co-reviewing each other's patches and discussing changes in #openstack-swift
would be good ways to ensure that you are working in the same direction.
--John
On Oct 12, 2013, at 3:49 PM, Brian Curtin wrote:
> Hi,
>
> I just had a look at the python-swiftclient reviews in Gerrit and noticed
>
This week's team meeting is cancelled since most of the active contributors
will all be together in Austin for the Swift hackathon during the regularly
scheduled meeting time.
Regular bi-weekly meetings will resume on October 30 at 1900UTC in
#openstack-meeting
--John
signature.asc
Descri
A random off-the-top-of-my-head use case would be to subscribe to events from
creating or changing objects in a particular Swift account or container. This
would allow much more efficient listings in Horizon for active containers (and
may also be consumed by other listeners too).
--John
On N
Swift uses marker+limit for pagination when listing containers or objects (with
additional support for prefix, delimiters, and end markers). This is done
because the total size of the listing may be rather large, and going to a
correct "page" based on an offset gets expensive and doesn't allow f
> -----Original Message-
>> From: John Dickinson [mailto:m...@not.mn]
>> Sent: Wednesday, November 13, 2013 10:09 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Ceilometer][Horizon] The future or
>>
Peter Portante (from Red Hat) has been very active with Swift patches, reviews,
and community discussion during the last seven months and has been added as a
member of Swift core.
Peter has been a pleasure to work with, and I'm happy to add him. Welcome,
Peter!
--John
__
The RC for Swift 1.9.0 has been cut, and baring any issues discovered, will be
finalized next Tuesday.
Please take some time to try it out and run through your tests.
Cahngelog: https://github.com/openstack/swift/blob/milestone-proposed/CHANGELOG
Launchpad milestone page: https://launchpad.net/s
On Jul 1, 2013, at 8:03 AM, Mark McLoughlin wrote:
> Hey Thierry
>
> I actually didn't notice this go by last week, the other thread got all
> the attention.
>
> On Wed, 2013-06-26 at 14:51 +0200, Thierry Carrez wrote:
>> Hi everyone,
>>
>> Yesterday at the TC meeting we agreed that as a firs
I really like the Solution 2 proposal.
On Jul 1, 2013, at 12:32 PM, Thierry Carrez wrote:
> Thierry Carrez wrote:
>
> Solution (2) is to make everything a "Program". Some have a goal of
> producing an 'integrated' piece and those must go through incubation.
> Something like:
>
> """
> 'OpenSt
I'm pleased to announce that Swift 1.9.0 has been released. This has
been a great release with major features added, thanks to the combined
effort of 37 different contributors.
Full release notes: https://github.com/openstack/swift/blob/master/CHANGELOG
Download: https://launchpad.net/swift/havana
Take a look at the proxy config, starting here:
https://github.com/openstack/swift/blob/master/etc/proxy-server.conf-sample#L70
The error_suppression_interval and error_suppression_limit control the window
you are looking for. With the default values, 10 errors in 60 seconds will
prevent the pr
Last week we wrote a blog post about introducting erasure codes into Swift.
Today, I'm happy to share more technical details around this feature.
We've posted an overview of our design and some of the tradeoffs in the feature
at
http://swiftstack.com/blog/2013/07/17/erasure-codes-with-openstack
Boudjnah wrote:
> On Thu, Jul 18, 2013 at 12:42 AM, John Dickinson wrote:
>>* Erasure codes (vs replicas) will be set on a per-container basis
>
> I was wondering if there was any reasons why it couldn't be as
> per-account basis as this would allow an operator to have
clouds, I don't think
> you can make the assumption that all users/clients will understand the
> storage/latency tradeoffs and benefits.
>
>
> On Thu, Jul 18, 2013 at 8:11 AM, John Dickinson wrote:
> Check out the slides I linked. The plan is to enable an EC policy that is
&
we want to down the road offer user defined classes of storage
>> (like how S3 does reduced redundancy), I'm cool with that, just that it
>> should be orthogonal to the implementation of EC.
>>
>> --
>> Chuck
>>
>>
>> On Thu, Jul 1
count or container level, the billing number generator will
need to correlate particular bytes with a particular service level. That would
be in ceilometer, slogging, or whatever other people are using.
>
> DH
>
> On Thu, Jul 18, 2013 at 9:37 PM, John Dickinson wrote:
> Yes, and I&#x
For those playing along from home, this question has been discussed at
https://answers.launchpad.net/swift/+question/233444
--John
On Aug 3, 2013, at 10:34 AM, kalrey wrote:
> hi openstackers，
> I'm a learner of swift. I took some benchmark about swift last week and the
> result is not pleas
All,
The Swift functional tests have been running as an advisory for a bit now on
all Swift patches. Everything appears to be plumbed together correctly, and the
tests have been added as gating tests for every merge into master.
Thanks to the -infra team for all their hard work.
--John
si
They were non-voting. The change is that they are now voting.
--John
On Aug 5, 2013, at 9:17 PM, Chmouel Boudjnah wrote:
> On Mon, Aug 5, 2013 at 10:59 PM, John Dickinson wrote:
>> The Swift functional tests have been running as an advisory for a bit now on
>> all Swift patc
Today we have released Swift 1.9.1 (RC1).
The tarball for the RC is at
http://tarballs.openstack.org/swift/swift-milestone-proposed.tar.gz
This release was initially prompted by a bug found by Peter Portante
(https://bugs.launchpad.net/swift/+bug/1196932) and includes a patch
for it. All clusters
We (SwiftStack) are hosting a Swift Hackathon in Austin, Texas on October
15-17. We're bringing together Swift contributors to meet and hack for a few
days.
http://swifthackathon.eventbrite.com
Our plan is to provide a few days of hacking together with just a few rules: 1)
No slide decks and 2
Swift 1.9.1, as described below, has been released. Download links to the
tarball are at https://launchpad.net/swift/havana/1.9.1
--John
On Aug 7, 2013, at 10:21 AM, John Dickinson wrote:
> Today we have released Swift 1.9.1 (RC1).
>
> The tarball for the RC is
1 - 100 of 246 matches
Mail list logo
