That's a great question.
A quick google search shows a few like Swift Explorer, Cyberduck, and
Gladinet. But since Swift supports the S3 API (check with your cluster
operator to see if this is enabled, or examine the results of a `GET
/info` request), you can use any available S3 GUI client as
On 4 Sep 2018, at 12:16, Julia Kreger wrote:
Greetings Stackers!
I hereby announce my candidacy for a position on the OpenStack
Technical
Committee.
In many respects I consider myself a maverick, except reality is
sometimes
entirely different than my own self perception, upon reflection.
On 28 Aug 2018, at 9:59, Jeremy Stanley wrote:
[Obligatory disclaimer: I am not a lawyer, this is not legal advice,
and I am not representing the OpenStack Foundation in any legal
capacity here.]
TL;DR: You should not be putting "Copyright OpenStack Foundation" on
content in Git repositories,
During today's Swift team meeting[1], we discussed the idea of
relaxing review guidelines. We agreed the normal case is "one core
reviewer's approval is sufficient to land code".
We've long had a "one +2" policy for trivial and obviously correct
patches. Put simply, the old policy was one of "nor
On 20 May 2018, at 17:19, Thomas Goirand wrote:
On 05/20/2018 06:24 PM, Matthew Treinish wrote:
On Sun, May 20, 2018 at 03:05:34PM +0200, Thomas Goirand wrote:
Thanks for these details. What exactly is the trouble with the Swift
backend? Do you know? Is anyone working on fixing it? At my com
On 14 May 2018, at 13:43, Pete Zaitcev wrote:
On Thu, 10 May 2018 20:07:03 +0800
Yuxin Wang wrote:
I'm working on a swift project. Our customer cares about S3
compatibility very much. I tested our swift cluster with
ceph/s3-tests and analyzed the failed cases. It turns out that lots
of th
I've discovered that eventlet 0.23.0 (released April 6) does break
things for Swift. I'm not sure about other projects yet.
https://bugs.launchpad.net/swift/+bug/1769749
--John
On 7 May 2018, at 13:50, Doug Hellmann wrote:
Excerpts from Michel Peterson's message of 2018-05-07 17:54:02 +03
no
On 2 Apr 2018, at 11:46, Jialin Liu wrote:
> Hi,
> Can a container name in openstack swift contains / ?
> e.g.,
> abc/111/mycontainer
>
>
> Best,
> Jialin
> __
> OpenStack Development Mailing List (not for usage questions)
On 22 Nov 2017, at 22:08, Adrian Turjak wrote:
> Hello fellow openstackers,
>
> I'm trying to figure something out that confuses me around how Swift
> handles roles from Keystone, and what the ACLs allow.
>
> In the Swift config you can specify roles which can manage the
> containers for their p
On 15 Nov 2017, at 7:40, Jay Pipes wrote:
> On 11/15/2017 06:28 AM, Duncan Thomas wrote:
>> On 15 November 2017 at 11:15, Matt Keenan wrote:
>>> On 13/11/17 22:51, Nikhil Komawar wrote:
>>>
>>> I think it will a rather hard problem to solve. As swift store can be
>>> configured to store objects
On 14 Nov 2017, at 16:08, Davanum Srinivas wrote:
> On Wed, Nov 15, 2017 at 10:44 AM, John Dickinson wrote:
>>
>>
>> On 14 Nov 2017, at 15:18, Mathieu Gagné wrote:
>>
>>> On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M wrote:
>>>> The pressure
On 14 Nov 2017, at 15:18, Mathieu Gagné wrote:
> On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M wrote:
>> The pressure for #2 comes from the inability to skip upgrades and the fact
>> that upgrades are hugely time consuming still.
>>
>> If you want to reduce the push for number #2 and help deve
To do this you want to use the `swift3` middleware, available at
https://github.com/openstack/swift3. Its `README.md` file has installation
instructions.
Also note that the Swift community is currently integrating the `swift3`
middleware into Swift's code repo. In the future, you will not need
On 7 Nov 2017, at 15:28, Erik McCormick wrote:
> Hello Ops folks,
>
> This morning at the Sydney Summit we had a very well attended and very
> productive session about how to go about keeping a selection of past
> releases available and maintained for a longer period of time (LTS).
>
> There was a
offs, I suspect many of the responses will be
>> predicable, but you might find some worthwhile nuggets there
>> nonetheless.
>>
>> I'm not aware of such an initiative so far but I do think it would be
>> useful, and perhaps something we can partner with
ByteIO(image) to make it a file-like object.
>
> So far, it works well, but I believe it is not the best way in terms of
> performance.
>
> Best,
> Jialin
>
> On Thu, Oct 5, 2017 at 8:25 AM, John Dickinson wrote:
>
>> If you've got an arbitrary object in Python,
If you've got an arbitrary object in Python, you'll need to serialize it to a
file-like object. You could keep it in memory and use a `StringIO` type, or you
could serialize it to disk and `open()` it like any other file.
Ultimately, Swift is storing arbitrary bytes and doesn't care what they ar
On 20 Sep 2017, at 9:25, Michael Still wrote:
> Dims, I'm not sure that's actually possible though. Many of these files
> have been through rewrites and developed over a large number of years.
> Listing all authors isn't practical.
>
> Given the horse has bolted on forking these files, I feel li
I submitted an issue on the landscape[1], but there's been no activity or
comments on it. It looks like David Flanders had some interaction on it a long
time ago [2].
Big poster-pictures like this inevitably get used to promote marketing messages
(the linked ML thread explicitly says that was t
We've created an etherpad for organizing the topics we'll discuss in Denver at
the PTG.
https://etherpad.openstack.org/p/swift-ptg-queens
I'd like to encourage operators who run Swift clusters to attend the Denver
PTG. This will be the most productive time for the whole community to get
togeth
On 16 Jun 2017, at 10:51, Clint Byrum wrote:
> This is great work.
>
> I'm sure you've already thought of this, but could you explain why
> you've chosen not to put the small objects in the k/v store as part of
> the value rather than in secondary large files?
I don't want to co-opt an answer f
Alex, this is fantastic work and great info. Thanks for sharing it.
Additional comments inline.
On 16 Jun 2017, at 6:54, Alexandre Lécuyer wrote:
> Swift stores objects on a regular filesystem (XFS is recommended), one file
> per object. While it works fine for medium or big objects, when you h
On 14 Jun 2017, at 9:03, Ivan Kolodyazhny wrote:
> Hi stackers,
>
>
>
> There are several bugs in Horizon [1], [2] and [3] related to pagination.
> TBH, these issues are reproducible via CLI too. Unfortunately, all of them
> are related to our API’s implementation [4].
>
> Bugs [1] and [2] can’t
um_data_fragments = 7
ec_num_parity_fragments = 6
ec_object_segment_size = 1048576
```
## Need more help?
Please feel free to ask any questions either here on the mailing list
or in #openstack-swift on freenode IRC.
Thank you for placing your trust in us to store your data in Swift. We
are all deep
On 1 Jun 2017, at 7:38, Thierry Carrez wrote:
> Thierry Carrez wrote:
>> In a previous thread[1] I introduced the idea of moving the PTG from a
>> purely horizontal/vertical week split to a more
>> inter-project/intra-project activities split, and the initial comments
>> were positive.
>>
>> We
On 31 May 2017, at 5:34, Monty Taylor wrote:
> On 05/31/2017 06:39 AM, Sean McGinnis wrote:
>> On Wed, May 31, 2017 at 06:37:02AM -0500, Sean McGinnis wrote:
>>> We had a discussion a few months back around what to do for cryptography
>>> since pycrypto is basically dead [1]. After some discussi
In Boston, one of the topics is how to better facilitate communication in our
global community. Like some other OpenStack projects, we've decided to add an
additional meeting that is better scheduled for different time zones.
Our current meeting is remaining: 2100UTC on Wednesdays in #openstack-
On 23 May 2017, at 8:05, Doug Hellmann wrote:
> Excerpts from Sean McGinnis's message of 2017-05-23 08:58:08 -0500:
- Is it that the reporting process is too heavy ? (requiring answers
from projects that are obviously unaffected)
>>>
>>> I've thought about this, OSC was unaffected
On 22 May 2017, at 15:50, Anne Gentle wrote:
> On Mon, May 22, 2017 at 5:41 PM, Sean McGinnis
> wrote:
>
>> On Mon, May 22, 2017 at 09:39:09AM +, Alexandra Settle wrote:
>>
>> [snip]
>>
>>> 1. We could combine all of the documentation builds, so that each
>> project has a single doc/source
On 18 May 2017, at 2:27, Thierry Carrez wrote:
> Hi everyone,
>
> For the PTG events we have a number of rooms available for 5 days, of
> which we need to make the best usage. We also want to keep it simple and
> productive, so we want to minimize room changes (allocating the same
> room to the
On 18 May 2017, at 2:57, Thierry Carrez wrote:
> Hi again,
>
> For the PTG events we have, by design, a pretty loose schedule. Each
> room is free to organize their agenda in whatever way they see fit, and
> take breaks whenever they need. This flexibility is key to keep our
> productivity at th
On 14 May 2017, at 4:04, Sean Dague wrote:
> One of the things that came up in a logging Forum session is how much effort
> operators are having to put into reconstructing flows for things like server
> boot when they go wrong, as every time we jump a service barrier the
> request-id is reset
Nejc,
Great to see stuff being built on and around Swift. There's no special process
for adding stuff to that page. It's a .rst file in the Swift code repo
(https://github.com/openstack/swift/blob/master/doc/source/associated_projects.rst)
and you can submit a patch for it via the normal patch
Moasca-teers
As the migration away from Launchpad and to Storyboard moves forward,
the Swift team has been considering making the move. Monasca has
already made the move, so I'd love to hear your thoughts on that
process.
1) How did you do the change? All at once or gradually? If you did it
over
On 12 Apr 2017, at 18:54, Michał Jastrzębski wrote:
> I was also thinking of having "cores just for single thing" in Kolla,
> but I think that won't really work as most of our code is variation of
> other parts with very little unique things to this, it's tuning up
> details that takes most of o
On 21 Mar 2017, at 15:34, Alex Schultz wrote:
> On Tue, Mar 21, 2017 at 3:45 PM, John Dickinson wrote:
>> I've been following this thread, but I must admit I seem to have missed
>> something.
>>
>> What problem is being solved by storing per-server service
I've been following this thread, but I must admit I seem to have missed
something.
What problem is being solved by storing per-server service configuration
options in an external distributed CP system that is currently not possible
with the existing pattern of using local text files?
--John
On 16 Mar 2017, at 14:10, Lance Bragstad wrote:
> Hey folks,
>
> The reseller use case [0] has been popping up frequently in various
> discussions [1], including unified limits.
>
> For those who are unfamiliar with the reseller concept, it came out of
> early discussions regarding hierarchical
I'm interested in having a room for Swift.
--John
On 15 Mar 2017, at 11:20, Kendall Nelson wrote:
> Hello All!
>
> As you may have seen in a previous thread [1] the Forum will offer project
> on-boarding rooms! This idea is that these rooms will provide a place for
> new contributors to a giv
On 8 Mar 2017, at 11:04, Andreas Jaeger wrote:
> On 2017-03-08 17:23, Brian Rosmaita wrote:
>> On 3/8/17 10:12 AM, Monty Taylor wrote:
>>> Hey all,
>>>
>>> We have a set of old vanity redirect URLs from back when we made a URL
>>> for each project:
>>>
>>> cinder.openstack.org
>>> glance.opensta
On 1 Mar 2017, at 10:07, Alexandra Settle wrote:
> On 3/1/17, 5:58 PM, "John Dickinson" wrote:
>
>
>
> On 1 Mar 2017, at 9:52, Alexandra Settle wrote:
>
> > Hi everyone,
> >
> > I would like to propose that we introduce a “Review do
On 1 Mar 2017, at 9:52, Alexandra Settle wrote:
> Hi everyone,
>
> I would like to propose that we introduce a “Review documentation” period on
> the release schedule.
>
> We would formulate it as a deadline, so that it fits in the schedule and
> making it coincide with the RC1 deadline.
>
> F
The PTG was great. Not only was there three full days of Swift-specific dev
work, we had lots of opportunity to work with other projects. Here's a quick
rundown of the highs and lows of the week.
The first obvious benefit to the PTG is the relatively easy access to other
projects. Yes, there's
On 16 Feb 2017, at 15:01, Chris Dent wrote:
> On Thu, 16 Feb 2017, Dan Prince wrote:
>
>> And yes. We are all OpenStack developers in a sense. We want to align
>> things in the technical arena. But I think you'll also find that most
>> people more closely associate themselves to a team within Op
On 13 Feb 2017, at 20:17, Mahati C wrote:
> Hello everyone,
>
> An update on the Outreachy program, including a request for volunteer
> mentors and funding. For those of you who are not aware, Outreachy helps
> people from underrepresented groups get involved in free and open source
> software
On 10 Feb 2017, at 7:07, Denis Makogon wrote:
> Greetings.
>
> I've been developing Swift middleware that depends on specific HTTP headers
> and figured out that there's only one way to specify them on client side -
> only in programmatically i can add HTTP headers to each Swift HTTP API
> metho
On 3 Jan 2017, at 10:38, Doug Hellmann wrote:
> Excerpts from John Dickinson's message of 2017-01-03 09:02:19 -0800:
>>
>> On 2 Jan 2017, at 13:06, Davanum Srinivas wrote:
>>
>>> Folks,
>>>
>>> Short Story :
>>> [1] has merged in devstack, it adds support for a python 3.5 based
>>> up/down devst
On 2 Jan 2017, at 13:06, Davanum Srinivas wrote:
> Folks,
>
> Short Story :
> [1] has merged in devstack, it adds support for a python 3.5 based
> up/down devstack test that just starts services and brings them down.
> see [2] for a test run.
>
> Need help from swift folks:
> Swift still needs w
On 22 Nov 2016, at 10:47, Andreas Jaeger wrote:
> When we (infra) changed the unit test jobs to not set up databases by
> default, we created special python-db and tox-db jobs that set up both
> MySQL and PostgreSQL databases. And that complicated the setup of those
> projects and lead to proble
On 18 Nov 2016, at 8:14, Dean Troyer wrote:
>> -Original Message-
>> From: Luke Hinds
> [...]
>>> for non security related functions, but when it comes to government
>>> compliance and running OpenStack on public clouds (and even private for the
>>> Telcos / NFV), not meeting FIPS will
On 14 Nov 2016, at 13:57, gordon chung wrote:
> hi,
>
> one issue i've noticed with our 'backlog' scheduling is that we register
> all our new measures in a single folder/filestore object. this folder or
> object in most production cases can grow quite large (tens/hundreds of
> thousands). so we
I've been fielding questions about the upcoming PTG, but one has come
up that I don't know how to answer.
How will cross-project sessions at the PTG be scheduled?
>From looking at the "Event Layout" section on
https://www.openstack.org/ptg, it seems to imply that each team in the
left column will
On 7 Nov 2016, at 10:31, Ash wrote:
> On Mon, Nov 7, 2016 at 9:58 AM, Hayes, Graham wrote:
>
>> On 07/11/2016 17:14, Flavio Percoco wrote:
>>> Greetings,
>>>
>>> I literally just posted a thing on my blog with some thoughts of what
>> I'd expect
>>> any new language being proposed for OpenStack
gt;>> OSIC
>>>
>>
>> Right I don't think the intention would be to implement it from scratch, but
>> to do some basic analysis of what exists (and think about and document the
>> patterns), and try to find the common parts (which likely involves renaming
&
On 1 Nov 2016, at 14:46, Zane Bitter wrote:
> On 01/11/16 15:13, James Slagle wrote:
>> On Tue, Nov 1, 2016 at 7:21 PM, Emilien Macchi wrote:
>>> Hi,
>>>
>>> TripleO (like some other projects in OpenStack) have not always done
>>> good job in merging specs on time during a cycle.
>>> I would li
The Swift team has been doing midcycles for a while now, and as the new PTG
gets closer, I want to write down our experience with what has worked for us. I
hope it is beneficial to other teams, too.
## Logistics of the event
- 2 rooms is ideal, but can make due with one larger room
- move table
On 3 Oct 2016, at 12:31, Doug Hellmann wrote:
>
> I think that's the balance we want to
> have: listen to input, collect information, then clearly set the
> direction without over-prescribing the implementation.
In light of this statement, would you reevaluate previous decisions you've made
reg
On 27 Sep 2016, at 9:21, Sean McGinnis wrote:
> I would like to announce my candidacy for a position on the Technical
> Committee.
>
> I work for Dell EMC with over a decade (quite a bit over, but I don't want to
> think about that) in storage and software development. I have been involved in
>
On 29 Sep 2016, at 16:00, gordon chung wrote:
>
> On 29/09/16 04:35 PM, John Dickinson wrote:
>>
>> I am concerned that there is a current focus on preserving the status
>> quo. There's focus on policies and rules instead of use cases; there's
>> f
I am throwing my hat into the ring for the TC election.
I've been a part of OpenStack since it started. I've seen it grow from
a few dozen people into the very large community we have today. During
the past 6 years, I've seen controversial topics come and go and the
community grow and adapt. I've
I'd be honored to continue to serve as your PTL for OpenStack Swift.
## Looking back at the Newton cycle
During the Newton cycle, the Swift community has delivered at-rest
encryption. This feature is the culmination of a more than year of
work, and it enables Swift to be deployed in places where
On 17 Aug 2016, at 15:27, Nick Papadonis wrote:
> comments
>
> On Wed, Aug 17, 2016 at 4:53 PM, Matthew Thode
> wrote:
>
>> On 08/17/2016 03:52 PM, Nick Papadonis wrote:
>>
>>> Thanks for the quick response!
>>>
>>> Glance worked for me in Mitaka. I had to specify 'chunked transfers'
>>> and i
I don't know of people running Swift in production with mod_wsgi. The original
doc you referenced and the related work done upstream was done several years
ago, IIRC by IBM. Personally, I've never deployed Swift that way.
However, I too am really interested in the general answers to your questio
On 15 Aug 2016, at 1:37, Thierry Carrez wrote:
> Doug Hellmann wrote:
>> [...]
>> Choosing to be a part of a community comes with obligations as well
>> as benefits. If, after a lengthy discussion of a community-wide
>> goal, involving everyone in the community, a project team is
>> resolutely
On 12 Aug 2016, at 13:31, Doug Hellmann wrote:
> Excerpts from John Dickinson's message of 2016-08-12 13:02:59 -0700:
>>
>> On 12 Aug 2016, at 7:28, Doug Hellmann wrote:
>>
>>> Excerpts from John Dickinson's message of 2016-08-11 15:00:56 -0700:
On 10 Aug 2016, at 8:29, Doug Hellmann w
On 12 Aug 2016, at 7:28, Doug Hellmann wrote:
> Excerpts from John Dickinson's message of 2016-08-11 15:00:56 -0700:
>>
>> On 10 Aug 2016, at 8:29, Doug Hellmann wrote:
>>
>>> Excerpts from Doug Hellmann's message of 2016-07-29 16:55:22 -0400:
One of the outcomes of the discussion at the le
bindep is great, and we've been using it in Swift for a while now. I'd
definitely recommend it to other projects.
Andreas, I didn't see a patch proposed to Swift to move the file. I don't want
to get in the way of your tool, though. Is there a patch that will be proposed,
or should I do that my
On 11 Aug 2016, at 15:14, Ed Leafe wrote:
> On Aug 11, 2016, at 4:50 PM, John Dickinson wrote:
>
>> Is this intended to be a cross-project thing? The message is tagged
>> "[nova]", so I'm kinda surprised I saw it, but the library seems to be
>> calle
On 11 Aug 2016, at 15:02, Brian Rosmaita wrote:
> I have a question about the api-ref. Right now, for example, the new
> images v1/v2 api-refs are accurate for Mitaka. But DocImpact bugs are
> being generated as we speak for changes in master that won't be
> available to consumers until Newton
On 10 Aug 2016, at 8:29, Doug Hellmann wrote:
> Excerpts from Doug Hellmann's message of 2016-07-29 16:55:22 -0400:
>> One of the outcomes of the discussion at the leadership training
>> session earlier this year was the idea that the TC should set some
>> community-wide goals for accomplishing
On 3 Aug 2016, at 16:47, Jay Pipes wrote:
> Hi Novas and anyone interested in how to represent capabilities in a
> consistent fashion.
>
> I spent an hour creating a new os-capabilities Python library this evening:
>
> http://github.com/jaypipes/os-capabilities
>
> Please see the README for exa
On 11 Aug 2016, at 10:03, Andreas Jaeger wrote:
> TL;DR: upper-constraints can be used now for all tox based jobs
>
> With any software package, you will need additional packages to run it.
> Often, there's a tight coupling: The software package will only run with
> specific other package versio
On 9 Aug 2016, at 11:33, Ian Cordasco wrote:
>
>
> -Original Message-
> From: John Dickinson
> Reply: OpenStack Development Mailing List (not for usage questions)
>
> Date: August 9, 2016 at 13:17:08
> To: OpenStack Development Mailing List
> S
I'd like to advocate for *not* raising minimum versions very often. Every time
some OpenStack project raises minimum versions, this change is propagated to
all projects, and that puts extra burden on anyone who is maintaining packages
and dependencies in their own deployment. If one project need
On 8 Aug 2016, at 9:50, Jay Pipes wrote:
> Tempest devs,
>
> Let me please draw your attention to a LP bug that may not seem particularly
> high priority, but I believe could be resolved easily with a patch already
> proposed.
>
> LP bug 1536251 [1] accurately states that Tempest is actively v
On 19 Jul 2016, at 11:56, Dean Troyer wrote:
> On Tue, Jul 19, 2016 at 12:27 PM, John Dickinson wrote:
>
>> Overall, using long-lived upstream feature branches has been very helpful
>> for us and overall a positive experience.
>>
>> I've seen some other teams
I've been trying to follow this thread, but I'll admit I'm confused about what
is being asked about or proposed. I'm not sure what "plugins for all" means.
Is "plugins for all" a way to make every plugin in an OpenStack project work
the same way? How would that work? There's a huge set of divers
Swift has now used 4 feature branches and landed 3 of them:
* feature/sp -- for storage policy functionality (landed)
* feature/ec -- for erasure codes (landed)
* feature/hummingbird -- for golang WIP
* feature/crypto -- for at-rest encryption (landed)
Overall, using long-lived upstream featu
As mentioned in IRC and on
https://wiki.openstack.org/wiki/Swift/PriorityReviews, Swift is now under a
soft freeze for master.
The patches for the crypto functionality have been proposed to
feature/crypto-review. The initial plan is to spend two weeks in this soft
freeze (until June 24) to get
I'm happy to announce that OpenStack Swift 2.8.0 has been released.
This release includes several feature improvements and important
bug fixes, and I recommend that everyone upgrade as soon as possible.
As always, you can upgrade to this version with no end-user downtime.
The full release notes c
On 8 Jun 2016, at 11:13, Doug Hellmann wrote:
> tl;dr: The switch from pre-versioning to post-versioning means that
> sometimes master appears to be older than stable/$previous, so we
> merge "final" tags from stable/$previous into master to make up for
> it. This introduces versions into the hi
Forwarded message:
> From: John Dickinson
> To: Thierry Carrez
> Cc: Flavio Percoco
> Subject: Re: Exploring the feasibility of a dependency approach
> Date: Wed, 01 Jun 2016 13:58:21 -0700
>
>
>
> On 30 May 2016, at 2:48, Thierry Carrez wrote:
>
>> John Di
open swift/swiftclient patches to stable/kilo have been abandoned
--John
On 2 Jun 2016, at 4:45, Jesse Pretorius wrote:
> Hi Tony,
>
> OpenStack-Ansible is just waiting for the requirements repository and the
> swift repository kilo-eol tags. Once they're done we'd like to bump the
> SHA's for
My responses are inline and to question 5, which, like you, I think is the key.
On 25 May 2016, at 3:48, Sean Dague wrote:
> I've been watching the threads, trying to digest, and find the way's
> this is getting sliced doesn't quite slice the way I've been thinking
> about it. (which might just m
summary:
* Defining the scope of OpenStack projects DOES NOT define the
languages needed to implement them. The considerations are
orthogonal.
* We've already defined OpenStack--it's whatever it takes to
fulfill its mission statement.
On 19 May 2016, at 6:19, Thierry Carrez wrote:
> Hi
On 16 May 2016, at 8:14, Dmitry Tantsur wrote:
> On 05/16/2016 05:09 PM, Ian Cordasco wrote:
>>
>>
>> -Original Message-
>> From: Dmitry Tantsur
>> Reply: OpenStack Development Mailing List (not for usage questions)
>>
>> Date: May 16, 2016 at 09:55:27
>> To: openstack-dev@lists.opens
You're absolutely right. If we can get as good (or even close) to the same
performance eg with PyPy, then we should absolutely do that! I've had many
public and private conversations over the last year or so that have that same
basic message as I've been looking at the ongoing Golang work in the
On 13 May 2016, at 1:14, Steve Martinelli wrote:
> /me gets the ball rolling
>
> Just when python3 support for keystone was looking like a reality, we've
> hit another snag. Apparently there are several issues with python-memcached
> in py3, putting it simply: it loads, but doesn't actually work
On 11 May 2016, at 13:11, Robert Collins wrote:
>
> So, given that that is the model - why is language part of it? Yes,
> there are minimum overheads to having a given language in CI - we need
> to be able to do robust reliable builds [or accept periodic downtime
> when the internet is not cooper
On 9 May 2016, at 15:53, Monty Taylor wrote:
> On 05/09/2016 05:45 PM, Robert Collins wrote:
>> IIRC mediawiki provides RSS of changes... maybe just using the wiki
>> more would be a good start, and have zero infra costs?
>
> We'd actually like to start using the wiki less, per the most recent
>
On 9 May 2016, at 13:16, Gregory Haynes wrote:
>
> This is a bit of an aside but I am sure others are wondering the same
> thing - Is there some info (specs/etherpad/ML thread/etc) that has more
> details on the bottleneck you're running in to? Given that the only
> clients of your service are the
ions)
>> Subject: Re: [openstack-dev] [tc] supporting Go
>>
>> On 08/05/2016 10:21, Thomas Goirand wrote:
>>> On 05/04/2016 01:29 AM, Hayes, Graham wrote:
>>>> On 03/05/2016 17:03, John Dickinson wrote:
>>>>> TC,
>>>>>
>>>>
If you're working on an idea for Swift, you've probably already spent a lot of
time thinking deeply about it. Working with other people in the community to
further develop your idea is wonderful, and by the time we're all reviewing the
code, it's really important that we all think deeply about t
On 3 May 2016, at 14:50, Doug Hellmann wrote:
> Excerpts from John Dickinson's message of 2016-05-03 13:01:28 -0700:
>>
>> On 3 May 2016, at 12:19, Monty Taylor wrote:
>>
>>> On 05/03/2016 01:45 PM, Michael Krotscheck wrote:
>>>> On Tue, May
On 3 May 2016, at 12:19, Monty Taylor wrote:
> On 05/03/2016 01:45 PM, Michael Krotscheck wrote:
>> On Tue, May 3, 2016 at 9:03 AM John Dickinson > <mailto:m...@not.mn>> wrote:
>>
>>
>> As a starting point, what would you like to see addres
Go compiler that the user may want to install on their systems.
>
> Rayson
>
> ==
> Open Grid Scheduler - The Official Open Source Grid Engine
> http://gridscheduler.sourceforge.net/
> http://gridscheduler.sourceforge.net/GridEngin
>
> How would Oslo like functionality be included ? Would the aim be to produce
> equivalent libraries ?
>
> Tim
>
>
>
>
> On 03/05/16 17:58, "John Dickinson" wrote:
>
>> TC,
>>
>> In reference to
>> http://lists.openstack.org/pi
TC,
In reference to
http://lists.openstack.org/pipermail/openstack-dev/2016-May/093680.html and
Thierry's reply, I'm currently drafting a TC resolution to update
http://governance.openstack.org/resolutions/20150901-programming-languages.html
to include Go as a supported language in OpenStack p
At the summit last week, the Swift community spent a lot of time discussing the
feature/hummingbird branch. (For those who don't know, the feature/hummingbird
branch contains some parts of Swift which have been reimplemented in Go.)
As a result of that summit discussion, we have a plan and a goa
There's no significant change with the global EC clusters story in the 2.7
release. That's something we're discussing next week at the summit.
--John
On 19 Apr 2016, at 22:47, Mark Kirkwood wrote:
> Hi,
>
> Has the release of 2.7 significantly changed the assessment here?
>
> Thanks
>
> Mark
1 - 100 of 246 matches
Mail list logo
