Re: [openstack-dev] GUI for Swift object storage

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

Re: [openstack-dev] [election][tc] announcing candidacy

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

Re: [openstack-dev] [all][tc][openstack-helm] On the problem of OSF copyright headers

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

[openstack-dev] [swift] change in review policy: normally one +2 is sufficient

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

Re: [openstack-dev] [all][tc][ptls] final stages of python 3 transition

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

Re: [openstack-dev] [swift][swift3][s3] Keep containers unique among a cluster

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.

Re: [openstack-dev] [all][requirements] uncapping eventlet

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

Re: [openstack-dev] container name in swift

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

Re: [openstack-dev] [Swift][Keystone] Swift vs Keystone permission models

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

Re: [openstack-dev] [glance] Does glance_store swift driver support range requests ?

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 >>>

Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases

On 14 Nov 2017, at 16:08, Davanum Srinivas wrote: > On Wed, Nov 15, 2017 at 10:44 AM, John Dickinson <m...@not.mn> wrote: >> >> >> On 14 Nov 2017, at 15:18, Mathieu Gagné wrote: >> >>> On Tue, Nov 14, 2017 at 6:00 PM, Fox, Kevin M <kevin@pnnl.go

Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases

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

Re: [openstack-dev] Need help with Openstack Swift Installation and configuration with S3

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

Re: [openstack-dev] [Openstack-operators] Upstream LTS Releases

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

Re: [openstack-dev] [tc][election] Question for candidates: How do you think we can make our community more inclusive?

t; >> Given the recent layoffs, 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

Re: [openstack-dev] how to write python object in openstack swift

o 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 <m...@not.mn> wrote: > >> If you've got an arbitrary object in Python, you

Re: [openstack-dev] how to write python object in openstack swift

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

Re: [openstack-dev] [tc][nova][mogan] How to show respect to the original authors?

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

Re: [openstack-dev] Anyone know CNCF and how to get their landscape 'tweaked'

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

[openstack-dev] [swift] Denver PTG topic planning

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

Re: [openstack-dev] [swift] Optimizing storage for small objects in Swift

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

Re: [openstack-dev] [swift] Optimizing storage for small objects in Swift

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

Re: [openstack-dev] [api][horizon][all] Poorly Pagination UX

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]

[openstack-dev] [swift] upcoming impact to configuration in Swift 2.15.0

ze = 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 deeply saddened by this bug and the extra work it may cause operators. Jo

Re: [openstack-dev] [ptg] Strawman Queens PTG week slicing

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

Re: [openstack-dev] [requirements] Do we care about pypy for clients (broken by cryptography)

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

[openstack-dev] [swift] new additional team meeting

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

Re: [openstack-dev] [tc][all] Missing answers on Pike release goals

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

Re: [openstack-dev] [doc][ptls][all] Documentation publishing future

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

Re: [openstack-dev] [ptg] How to slice the week to minimize conflicts

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

Re: [openstack-dev] [ptg] ptgbot: how to make "what's currently happening" emerge

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

Re: [openstack-dev] [nova] [glance] [cinder] [neutron] [keystone] - RFC cross project request id tracking

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

Re: [openstack-dev] [swift] Adding our developments to Assosciated projects list

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

[openstack-dev] [monasca][swift][storyboard] migration experience

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

Re: [openstack-dev] [kolla][all][tc] Starting a core reviewer mentorship program for Kolla deliverables

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

Re: [openstack-dev] [oslo][kolla][openstack-helm][tripleo][all] Storing configuration options in etcd(?)

On 21 Mar 2017, at 15:34, Alex Schultz wrote: > On Tue, Mar 21, 2017 at 3:45 PM, John Dickinson <m...@not.mn> wrote: >> I've been following this thread, but I must admit I seem to have missed >> something. >> >> What problem is being solved by storing

Re: [openstack-dev] [oslo][kolla][openstack-helm][tripleo][all] Storing configuration options in etcd(?)

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

Re: [openstack-dev] [keystone][all] Reseller - do we need it?

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

Re: [openstack-dev] [ptls] Project On-Boarding Rooms

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

Re: [openstack-dev] [cinder][glance][horizon][keystone][nova][qa][swift] Feedback needed: Removal of legacy per-project vanity domain redirects

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 >>>

Re: [openstack-dev] [docs][release][ptl] Adding docs to the release schedule

On 1 Mar 2017, at 10:07, Alexandra Settle wrote: > On 3/1/17, 5:58 PM, "John Dickinson" <m...@not.mn> wrote: > > > > On 1 Mar 2017, at 9:52, Alexandra Settle wrote: > > > Hi everyone, > > > > I would like to propose

Re: [openstack-dev] [docs][release][ptl] Adding docs to the release schedule

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. > >

[openstack-dev] [swift] thoughts on the PTG

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

Re: [openstack-dev] [tripleo] Fwd: TripleO mascot - how can I help your team?

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

Re: [openstack-dev] Call for mentors and funding - Outreachy

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

Re: [openstack-dev] [Swift][swiftclient][horizon] Improve UX by enabling HTTP headers configuration in UI and CLI

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 >

Re: [openstack-dev] [all][py3][swift][devstack] USE_PYTHON3 works! (well somewhat)

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

Re: [openstack-dev] [all][py3][swift][devstack] USE_PYTHON3 works! (well somewhat)

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

Re: [openstack-dev] [all][infra] Proposed changes to unit-test setup

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

Re: [openstack-dev] [security] FIPS Compliance (Was: [requirements][kolla][security] pycrypto vs cryptography)

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),

Re: [openstack-dev] [gnocchi] new measures backlog scheduling

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

[openstack-dev] [all][ptg] how are cross-project sessions scheduled?

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

Re: [openstack-dev] [all] Embracing new languages in OpenStack

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

Re: [openstack-dev] [oslo] New and next-gen libraries (a BCN followup)

>>> >>> Thanks, >>> Jay Faulkner >>> 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

Re: [openstack-dev] [tripleo] Ocata specs

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

[openstack-dev] [all] planning the PTG -- lessons from Swift's midcycles

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

Re: [openstack-dev] [tc] open question to the candidates

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

Re: [openstack-dev] [all][elections][TC] TC candidacy

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 >

Re: [openstack-dev] TC candidacy

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 >> focus on co

[openstack-dev] TC candidacy

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

[openstack-dev] [Swift] PTL candidacy

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

Re: [openstack-dev] mod_wsgi: what services are people using with it?

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

Re: [openstack-dev] mod_wsgi: what services are people using with it?

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

Re: [openstack-dev] [all][tc][ptl] establishing project-wide goals

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

Re: [openstack-dev] [all][tc][ptl] establishing project-wide goals

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

Re: [openstack-dev] [all][tc][ptl] establishing project-wide goals

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

Re: [openstack-dev] [all][infra] Binary Package Dependencies - not only for Python

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

Re: [openstack-dev] [nova] os-capabilities library created

On 11 Aug 2016, at 15:14, Ed Leafe wrote: > On Aug 11, 2016, at 4:50 PM, John Dickinson <m...@not.mn> 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 &g

Re: [openstack-dev] [all] versioning the api-ref?

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

Re: [openstack-dev] [all][tc][ptl] establishing project-wide goals

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

Re: [openstack-dev] [nova] os-capabilities library created

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

Re: [openstack-dev] [all][infra] Constraints are ready to be used for tox.ini

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

Re: [openstack-dev] [requirements] History lesson please

On 9 Aug 2016, at 11:33, Ian Cordasco wrote: >   > > -Original Message- > From: John Dickinson <m...@not.mn> > Reply: OpenStack Development Mailing List (not for usage questions) > <openstack-dev@lists.openstack.org> > Date: August 9, 2016 at 13:

Re: [openstack-dev] [requirements] History lesson please

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

Re: [openstack-dev] [tempest][swift][radosgw] Can we please merge the fix for the RFC 7230 violation issue?

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

Re: [openstack-dev] using feature branches, Swift's experiences

On 19 Jul 2016, at 11:56, Dean Troyer wrote: > On Tue, Jul 19, 2016 at 12:27 PM, John Dickinson <m...@not.mn> wrote: > >> Overall, using long-lived upstream feature branches has been very helpful >> for us and overall a positive experience. >> >> I've seen

Re: [openstack-dev] [tc][all] Plugins for all

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

[openstack-dev] using feature branches, Swift's experiences

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

[openstack-dev] [swift] crypto-review review, soft-freeze on master

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

[openstack-dev] [swift] OpenStack Swift 2.8.0 has been released

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

Re: [openstack-dev] [release][reno][infra] merging tags between branches is confusing our release notes

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

[openstack-dev] [swift] Exploring the feasibility of a dependency approach

ed message: > From: John Dickinson <m...@not.mn> > To: Thierry Carrez <thie...@openstack.org> > Cc: Flavio Percoco <flape...@gmail.com> > Subject: Re: Exploring the feasibility of a dependency approach > Date: Wed, 01 Jun 2016 13:58:21 -0700 > > > > O

Re: [openstack-dev] [stable][all] Tagging kilo-eol for "the world"

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

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

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

Re: [openstack-dev] [all][tc] Languages vs. Scope of "OpenStack"

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: >

Re: [openstack-dev] [tc] supporting Go

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:

Re: [openstack-dev] [tc] supporting Go

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

Re: [openstack-dev] [keystone][oslo][designate][zaqar][nova][swift] using pylibmc instead of python-memcached

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

Re: [openstack-dev] [tc] supporting Go

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

Re: [openstack-dev] Team blogs

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

Re: [openstack-dev] [tc] supporting Go

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

Re: [openstack-dev] [tc] supporting Go

penstack-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, >>>>> >>>>> In reference to >>

[openstack-dev] [swift] specs are dead. long live ideas

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

Re: [openstack-dev] [tc] supporting Go

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 3, 2

Re: [openstack-dev] [tc] supporting Go

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 <m...@not.mn >> <mailto:m...@not.mn>> wrote: >> >> >> As a starting point, what would you lik

Re: [openstack-dev] [tc] supporting Go

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/GridEngine/GridEngineCloud.html > &g

Re: [openstack-dev] [tc] supporting Go

like functionality be included ? Would the aim be to produce > equivalent libraries ? > > Tim > > > > > On 03/05/16 17:58, "John Dickinson" <m...@not.mn> wrote: > >> TC, >> >> In reference to >> http://lists.openstack.org/pi

[openstack-dev] [tc] supporting Go

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

[openstack-dev] [Swift] going forward

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

Re: [openstack-dev] [Swift] Erasure coding and geo replication

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   2   3   >