Re: [openstack-dev] [new][cloudpulse] Announcing a project to HealthCheck OpenStack deployments

Jay Pipes writes: > On 05/12/2015 02:16 PM, Fox, Kevin M wrote: >> Nagios/watever As A Service would actually be very useful I think. > Frankly, so do tenants. Tenants install software on their images using > configuration management tools like mentioned above... I don't see a reason to > have Na

Re: [openstack-dev] [oslo] eventlet 0.17.3 is now fully Python 3 compatible

Victor Stinner writes: >> Is there already a static analysis tool that helps find these things? (Would >> a >> pylint check for the above be useful? Some of them would be hard to find >> reliably, but a bunch of the above would be trivial) > > I read that hacking has some checks. It's quite easy

Re: [openstack-dev] Regarding openstack swift implementation

Hello, On Tue, Apr 21, 2015 at 7:34 AM, Subbulakshmi Subha < subbulakshmisubh...@gmail.com> wrote: > I want to simulate it one javasim,so I want to know how are objects stored > in the partitions in swift.I computed the md5 hash of the objects url, n > the medium of storage is hashmap,so I want t

Re: [openstack-dev] [kolla][tripleo] Optional Ansible deployment coming

On 03/31/2015 03:30 PM, Steven Dake (stdake) wrote: > Hey folks, > > One of our community members submitted a review to add optional Ansible > support to deploy OpenStack using Ansible and the containers within Kolla. > Our main objective remains: for third party deployment tools to use Kolla as a

Re: [openstack-dev] [kolla] Re: Questions about kolla

On Mon, Mar 30, 2015 at 3:42 PM, Steven Dake (stdake) wrote: > We plan to dockerize any service needed to deploy OpenStack. We haven’t > decided if that includes ceph, since ceph may already be dockerized by > someone else. But it does include the HA services we need as well as the > rest of th

Re: [openstack-dev] [infra] What do people think of YAPF (like gofmt, for python)?

On Thu, Mar 26, 2015 at 5:02 PM, James E. Blair wrote: > This is purposefully done to ensure that developers do not inadvertently > run code on their workstations from a source they may not trust. > Sure, but is that really make a difference between having some scripts in a tox.ini that are ru

Re: [openstack-dev] [infra] What do people think of YAPF (like gofmt, for python)?

On Thu, Mar 26, 2015 at 12:22 AM, Monty Taylor wrote: > git review is used by a ton of people who write in non-python. I think > adding openstack-specific style enforcement to it would make it way less > generally useful. > I think if we wanted to do that we could just extend git-review run_scr

Re: [openstack-dev] [kolla] Re: Why we didn't use k8s in kolla?

Hello, So if I understand correctly Kubernetes was avoided since there is no control point and using fig/docker-compose would get you a top to the bottom deployment that easy to control. At this point is there any reasons not using something like ansible+docker plugin instead? I have used extensi

Re: [openstack-dev] [oslo.config][kolla] modular backends for oslo.cfg

On Tue, Mar 24, 2015 at 11:40 AM, Flavio Percoco wrote: > This however won't remove the need of a config file. For instance, > plugins like etcd's will need the host/port options to be set > somewhere - or passed as a cli parameter. > Yes totally! I have been using command line switches in my e

[openstack-dev] [oslo.config][kolla] modular backends for oslo.cfg

Hello, While on a long oversea flight with Sebastien Han we were talking how he had implemented ceph-docker with central configuration over etcd. We quickly came up to the conclusion that if we wanted to have that in Kolla it would be neat if it was done straight from oslo.config so that would qui

Re: [openstack-dev] [OpenStack-Infra] [infra] Infra cloud: infra running a cloud for nodepool

cor...@inaugust.com (James E. Blair) writes: > A group of folks from HP is interested in starting an effort to run a > cloud as part of the Infrastructure program with the purpose of > providing resources to nodepool for OpenStack testing. HP is supplying > two racks of machines, and we will oper

Re: [openstack-dev] [Keystone] Deprecation of Eventlet deployment in Kilo (Removal for "M"-release)

Morgan Fainberg writes: > The Keystone development team is planning to deprecate deployment of Keystone > under Eventlet during the Kilo cycle. Support for deploying under eventlet > will > be dropped as of the “M”-release of OpenStack. great! glad there is one project that start making deploym

Re: [openstack-dev] Pluggable Auth for clients and where should it go

On Wed, Feb 18, 2015 at 8:54 PM, Dean Troyer wrote: > I think one thing needs to be clarified...what you are talking about is > utilizing keystoneclient's auth plugins in neutronclient. Phrasing it as > 'novaclient parity' reinforces the old notion that novaclient is the model > for doing things

Re: [openstack-dev] The root-cause for IRC private channels (was Re: [all][tc] Lets keep our community open, lets fight for it)

"Daniel P. Berrange" writes: > Personally I think all our IRC channels should be logged. There is really > no expectation of privacy when using IRC in an open collaborative project. Agreed with Daniel. I am not sure how a publicly available forum/channel can be assumed that there is not going to

Re: [openstack-dev] [devstack] [third-party] how to use a devstack external plugin in gate testing

Sean Dague writes: > I'm going to be -1ing most new or substantially redone drivers at this > point. External plugins are a better model for those. +1 Chnmouel __ OpenStack Development Mailing List (not for usage questions

Re: [openstack-dev] [devstack] [third-party] how to use a devstack external plugin in gate testing

Jaume Devesa writes: > Following the conversation... > > We have seen that glusterfs[1] and ec2api[2] use different approach > when it comes to repository managing: whereas glusterfs is a single > 'devstack' directory repository, ec2api is a whole project with a > 'devstack' directory on it. > >

Re: [openstack-dev] [openstack-announce] [keystonemiddleware] keystonemiddlware release 1.3.0

On Thu, Dec 18, 2014 at 8:25 PM, Morgan Fainberg wrote: > > * http_connect_timeout option is now an integer instead of a boolean. > * The service user for auth_token middlware can now be in a domain other > than the default domain. > fyi it has a fix in there as well so you can now use it in you

Re: [openstack-dev] [hacking] proposed rules drop for 1.0

On Tue, Dec 9, 2014 at 12:39 PM, Sean Dague wrote: > 1 - the entire H8* group. This doesn't function on python code, it > functions on git commit message, which makes it tough to run locally. > I do run them locally using git-review custom script features which would launch a flake8 before sendi

Re: [openstack-dev] Alembic 0.7.0 - hitting Pypi potentially Sunday night

Hello, On Fri, Nov 21, 2014 at 10:10 PM, Mike Bayer wrote: > 1. read about the new features, particularly the branch support, and > please let me know of any red flags/concerns you might have over the coming > implementation, at > http://alembic.readthedocs.org/en/latest/tutorial.html#running-ba

Re: [openstack-dev] [devstack] external plugin support for Devstack

On Mon, Nov 24, 2014 at 3:32 PM, Sean Dague wrote: > We should also make this something which is gate friendly. I think the > idea had been that if projects included a /devstack/ directory in them, > when assembling devstack gate, that would be automatically dropped into > devstack's extra.d dire

[openstack-dev] [devstack] external plugin support for Devstack

Hello, Thanks to the work of Dean and others we have a pretty solid plugins/extras support in Devstack. People can add new features in devstack within just a single file and that add a whole new feature or driver to devstack. It seems that there is quite a bit of people who wants to have those ex

Re: [openstack-dev] [devstack] keystone doesn't restart after ./unstack

Hi, If you do ./unstack.sh you probably want to do ./stack.sh back again to restack, ./rejoin-stack.sh is here when you have your screen session killed and want to rejoin it without having to ./stack.sh the full shenanigan again. Cheers, Chmouel On Tue, Nov 4, 2014 at 1:52 PM, Angelo Matarazzo <

Re: [openstack-dev] [Horizon] [Devstack]

On Fri, Oct 24, 2014 at 12:27 PM, Yves-Gwenaël Bourhis < yves-gwenael.bour...@cloudwatt.com> wrote: > Le 23/10/2014 23:55, Gabriel Hurley a écrit : > > 1) If you’re going to store very large amounts of data in the > > session, then session cleanup is going to become an important issue to > >

Re: [openstack-dev] Travels tips for the Paris summit

On Wed, Oct 15, 2014 at 10:25 AM, Thierry Carrez wrote: > I found this: > http://www.topito.com/top-meilleurs-restaurants-vegetariens-paris > > The "Creperies" (Brittany pancakes) are also great choices for > vegetarians since you can easily pick a vegetarian filling. > my vegetarians friends a

Re: [openstack-dev] 2 Minute tokens

On Wed, Oct 1, 2014 at 3:47 AM, Adam Young wrote: > 1. Identify the roles for the APIs that Cinder is going to be calling on > swift based on Swifts policy.json FYI: there is no Swifts policy.json in mainline code, there is one external middleware available that provides it here https://github

Re: [openstack-dev] [kolla] Kolla Blueprints

On Tue, Sep 30, 2014 at 6:41 PM, Steven Dake wrote: > > I've done a first round of prioritization. I think key things we need > people to step up for are nova and rabbitmq containers. > > For the developers, please take a moment to pick a specific blueprint to > work on. If your already working

Re: [openstack-dev] [keystone][swift] Has anybody considered storing tokens in Swift?

On 30/09/2014 01:05, Clay Gerrard wrote: eventual consistency will only affect container listing and I don't think there is a need for container listing in that driver. well now hold on... if you're doing an overwrite in the face of server failures you could still get a stale read if a serve

Re: [openstack-dev] [keystone][swift] Has anybody considered storing tokens in Swift?

On Mon, Sep 29, 2014 at 11:47 PM, Dmitry Mescheryakov < dmescherya...@mirantis.com> wrote: > As a result of operation #1 the token will be saved into Swift by the > Keystone. But due to eventual consistency it could happen that validation > of token in operation #2 will not see the saved token. Pr

Re: [openstack-dev] [kolla] Diagnosing problems with containers

On Fri, Sep 26, 2014 at 4:29 PM, Lars Kellogg-Stedman wrote: > As people are starting to look at Kubernetes and Docker, there have Nice, thanks for sharing! I think that may be nice to have this in a blog article (if it wasn't done already) Chmouel

Re: [openstack-dev] [all][tripleo] New Project -> Kolla: Deploy and Manage OpenStack using Kubernetes and Docker

On Thu, Sep 25, 2014 at 6:02 AM, Clint Byrum wrote: > However, this does make me think that Keystone domains should be exposable > to services inside your cloud for use as SSO. It would be quite handy > if the keystone users used for the VMs that host Kubernetes could use > the same credentials t

Re: [openstack-dev] [Nova] [All] API standards working group

On Wed, Sep 24, 2014 at 12:18 AM, Jay Pipes wrote: > Yes, I'd be willing to head up the working group... or at least > participate in it. I am certainly interested, count me in. Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.or

Re: [openstack-dev] [all][tripleo] New Project -> Kolla: Deploy and Manage OpenStack using Kubernetes and Docker

On Wed, Sep 24, 2014 at 12:40 AM, Steven Dake wrote: > I'm pleased to announce the development of a new project Kolla which is > Greek for glue :). Kolla has a goal of providing an implementation that > deploys OpenStack using Kubernetes and Docker. This project will begin as a > StackForge proje

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

On Fri, Sep 19, 2014 at 6:58 PM, Donald Stufft wrote: > So you can remove all that code and just let requests/urllib3 handle it on > 3.2+, 2.7.9+ and for anything less than that either use conditional > dependencies to have glance client depend on pyOpenSSL, ndg-httpsclient, > and pyasn1 on Pytho

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

On Thu, Sep 18, 2014 at 1:58 PM, Donald Stufft wrote: > Distributions are not the only place that people get their software from, > unless you think that the ~3 million downloads requests has received > on PyPI in the last 30 days are distributions downloading requests to > package in their OSs.

Re: [openstack-dev] Please do *NOT* use "vendorized" versions of anything (here: glanceclient using requests.packages.urllib3)

Ian Cordasco writes: > urllib3 do that automatically. I haven’t started to investigate exactly > why they do this. Likewise, glance client has custom certificate > verification in glanceclient.common.https. Why? I’m not exactly certain this probably come from pre-requests port uses when it was u

Re: [openstack-dev] [all] OpenStack bootstrapping hour - Friday Sept 19th - 3pm EST

Sean Dague writes: > Episode 0 - Mock best practices will kick off this Friday, Sept 19th, > from 3pm - 4pm EST. Our experts for this will be Jay Pipes and Dan ah too bad this is when the week-end start in Europe (and usually mean family time for me) but no complaining I guess there is no hours

Re: [openstack-dev] adding RSS feeds to specs repositories

Doug Hellmann writes: > I have completed a series of patches [1] for (I think) all of the > specs repositories to add RSS feeds so that when specs are approved > and merged they are easily publicized. Col, thanks for setting this up. [...] > I originally thought we would want to add these

Re: [openstack-dev] memory usage in devstack-gate (the oom-killer strikes again)

On Tue, Sep 9, 2014 at 12:24 AM, Joe Gordon wrote: > 1) Should we explicitly set the number of workers that services use in > devstack? Why have so many workers in a small all-in-one environment? What > is the right balance here? This is what we do for Swift, without setting this up it would

Re: [openstack-dev] Review change to nova api pretty please?

On Sat, Aug 30, 2014 at 11:28 AM, Alex Leonhardt wrote: > Is there a list of things "not to send to this list" somewhere accessible > (link?) that I could review, to not send another (different) request by > mistake and possibly upset or annoy people on here ? There is this document : https://

Re: [openstack-dev] [specs] script to help with spec reviews to convert them in html or pdf

On Sat, Aug 16, 2014 at 7:34 PM, Jeremy Stanley wrote: > Not to detract from your suggestion, but if the specs project in > question has a docs job then the link zuul leaves for it in each > check report takes you to a draft rendering of the specs with the > change applied rather than a log of th

[openstack-dev] [specs] script to help with spec reviews to convert them in html or pdf

Hello, If like me you find it difficult to read a large text file like the rst specs inside gerrit diff interface viewer, I have created a script that gets rst files in a review to generate them in a html or pdf files and open it with your desktop default viewer (linux/mac) . Script is available

Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit

On Wed, Aug 13, 2014 at 6:27 PM, James E. Blair wrote: > If it is not worth looking at a job that is run by the OpenStack CI > system, please propose a patch to openstack-infra/config to delete it > from the Zuul config. We only want to run what's useful, and we have > other methods (the silent

Re: [openstack-dev] [all] 3rd Party CI vs. Gerrit

On Wed, Aug 13, 2014 at 3:05 PM, James E. Blair wrote: > You may have noticed that this has merged, along with a further change > that shows the latest results in a table format. (You may need to > force-reload in your browser to see the change.) > Very cool!! this is really nice UI, super use

Re: [openstack-dev] [devstack] Core team proposals

On Thu, Aug 7, 2014 at 8:09 PM, Dean Troyer wrote: > Please respond in the usual manner, +1 or concerns. +1, I would be happy to see Ian joining the team. Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack

Re: [openstack-dev] Tox run failure during installation of dependencies in requirements

On Wed, Aug 6, 2014 at 12:19 PM, Narasimhan, Vivekanandan < vivekanandan.narasim...@hp.com> wrote: > Timeout: > ( object at 0x37e4790>, 'Connection to pypi.python.org timed out. (connect > timeout=15)') > I think this error message is pretty self explanatory Chmouel

Re: [openstack-dev] Thoughts on the patch test failure rate and moving forward

Hello, Thanks for writing this summary, I like all those ideas and thanks working hard on fixing this. > * For all non gold standard configurations, we'll dedicate a part of > our infrastructure to running them in a continuous background loop, > as well as making these configs available

Re: [openstack-dev] REST API access to configuration options

On Tue, Jul 15, 2014 at 9:54 AM, Henry Nash wrote: > Do people think this is a good idea? Useful in other projects? Concerned > about the risks? FWIW, we have this in Swift for a while and we actually uses it for different testing in cloud capabilities. I personally find it useful for clien

Re: [openstack-dev] Using tmux instead of screen in devstack

On Tue, Jul 1, 2014 at 2:11 PM, Anant Patil wrote: > Hi, > > I use tmux (an alternative to screen) a lot and I believe lot of other > developers use it. I have been using devstack for some time now and would > like to add the option of using tmux instead of screen for creating > sessions for open

Re: [openstack-dev] Fwd: Fwd: Debian people don't like bash8 as a project name (Bug#748383: ITP: bash8 -- bash script style guide checker)

Sean Dague writes: > bashate ftw. +1 to bashate Chmouel ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] masking X-Auth-Token in debug output - proposed consistency

On Fri, Jun 13, 2014 at 4:47 AM, Xuhan Peng wrote: > Since I'm working the neutron client code change, by looking at your code > change to nova client, looks like only X-Auth-Token is taken care of in > http_log_req. There is also password in header and token id in response. > Any particular reas

Re: [openstack-dev] masking X-Auth-Token in debug output - proposed consistency

On Thu, Jun 12, 2014 at 1:59 PM, Sean Dague wrote: > The only thing it makes harder is you have to generate your own token to > run the curl command. The rest is there. > Well I would have imagine that the curl command debug are here so people can easily copy and paste them and/or tweak them, bu

Re: [openstack-dev] masking X-Auth-Token in debug output - proposed consistency

On Thu, Jun 12, 2014 at 12:58 PM, Chmouel Boudjnah wrote: > > On Wed, Jun 11, 2014 at 9:47 PM, Sean Dague wrote: > >> Actually swiftclient is one of the biggest offenders in the gate - >> >> http://logs.openstack.org/96/99396/1/check/check-tempest-dsvm-full/4501f

Re: [openstack-dev] masking X-Auth-Token in debug output - proposed consistency

On Wed, Jun 11, 2014 at 9:47 PM, Sean Dague wrote: > Actually swiftclient is one of the biggest offenders in the gate - > > http://logs.openstack.org/96/99396/1/check/check-tempest-dsvm-full/4501fc8/logs/screen-g-api.txt.gz#_2014-06-11_15_20_11_078 > I'd be happy to fix that but that would make

Re: [openstack-dev] Selecting more carefully our dependencies

On Thu, May 29, 2014 at 11:25 AM, Thomas Goirand wrote: > So I'm wondering: are we being careful enough when selecting > dependencies? In this case, I think we haven't, and I would recommend > against using wrapt. Not only because it embeds six.py, but because > upstream looks uncooperative, and

Re: [openstack-dev] [Swift] storage policies merge plan

On Tue, May 27, 2014 at 10:02 AM, Hua ZZ Zhang wrote: > Do it make sense to support storage policy work in devstack so that it can > be more easily tested? > > -Edward Zhang > > I don't think storage policy on one VM (which has other OpenStack services) like usually setup for devstack is very p

Re: [openstack-dev] Spec repo names

jebl...@openstack.org (James E. Blair) writes: > about this, the more I think that the right answer is that we should > stick with codenames for the spec repos. The codenames are actually I hereby +1 this, except old timers that i don't think many people knows the OpenStack components by their p

[openstack-dev] [swift] swiftclient functional tests gate for python-swiftclient

tests/unit/test_multithreading.py R tests/unit/test_swiftclient.py R tests/unit/test_utils.py R tests/unit/utils.py M tox.ini 13 files changed, 320 insertions(+), 2 deletions(-) Approvals: Alistair Coles: Looks good to me (core reviewer); Approved Chmouel Boudjnah: Looks good to me (core reviewer) Jenkins

Re: [openstack-dev] SSL in Common client

Chmouel Boudjnah writes: > Most modern OSes have SSL compression by default, only Debian stable was > still enabling it. I mean "have SSL compression *disabled* by default". Chmouel. ___ OpenStack-dev mailing list OpenStack-dev@lis

Re: [openstack-dev] SSL in Common client

Rob Crittenden writes: > From what I found nothing has changed either upstream or in swift. If you are asking about the ability to disable SSL compression it is up to the OS to provide that so nothing was added when we changed swiftclient to requests. Most modern OSes have SSL compression by de

Re: [openstack-dev] Gerrit downtime and upgrade on 2014-04-28

On Wed, Apr 23, 2014 at 12:40 AM, James E. Blair wrote: > There are a few changes that will impact developers. We will have more > detailed documentation about this soon, but here are the main things you > should know about: > What plugins are going to be enabled under gerrit? I am asking that

Re: [openstack-dev] Gerrit downtime and upgrade on 2014-04-28

On Fri, Apr 25, 2014 at 6:10 PM, Zaro wrote: > Gerrit 2.8 allows setting label values on patch sets either thru the > command line[1] or REST API[2]. Since we will setup WIP as a -1 score > on a label this will just be a matter of updating git-review to set > the label on new patchsets. I'm no

Re: [openstack-dev] [SWIFT] swift and authorization policy

I haven't done a full review but I like what you did and this should be the proper way to handle ACL for keystoneauth. I am not sure tho that forking oslo.common.policy is any better than copy/pasting it with its dependences. I would suggest we move `swift-keystoneauth` to its own project part of

Re: [openstack-dev] [Devstack] add support for ceph

On Fri, Apr 18, 2014 at 6:32 AM, Sean Dague wrote: > That being said, there are 2 devstack sessions available at design > summit. So proposing something around addressing the ceph situation > might be a good one. It's a big and interesting problem. > I have add a session that just do that here

Re: [openstack-dev] Reviewing spelling and grammar errors in blueprints Re: [Nova] nova-specs

On Thu, Apr 17, 2014 at 9:41 AM, Stefano Maffulli wrote: > Please don't -1 if it's a minor grammar/spelling mistake that doesn't > prevent proper understanding of the blueprint by a person skilled in the > art. > or it may be acceptable that the reviewer can always do the minor spelling correcti

Re: [openstack-dev] [tripleo] /bin/bash vs. /bin/sh

FWIW: we are using bash in devstack if we were going to try to make it POSIX bourne shell (or whatever /bin/sh is) it would have been a huge pain. On Tue, Apr 15, 2014 at 1:25 PM, Dougal Matthews wrote: > Another +1 for using bash. Sounds like an easy win. > > > On 15/04/14 12:31, Ghe Rivero wr

[openstack-dev] [Devstack] add support for ceph

Hello, We had quite a lengthy discussion on this review : https://review.openstack.org/#/c/65113/ about a patch that seb has sent to add ceph support to devstack. The main issues seems to resolve around the fact that in devstack we support only packages that are in the distros and not having to

[openstack-dev] [Aws as a seervice] Jumpgate review

A good article mentioned here: http://bodenr.blogspot.fr/2014/03/managing-openstack-softlayer-resources.html for me, it's a gateway instead of I think our better approach of drivers inside openstack. I would imagine it's not a static one and would pass down everything it doesn't know about. If

Re: [openstack-dev] [MagnetoDB] Best practices for uploading large amounts of data

Maksym Iarmak wrote: > I suggest taking a look, how Swift and Ceph do such things. under swift (and CEPH via the radosgw which implement swift API) we are using POST and PUT which has been working relatively well Chmouel ___ OpenStack-dev mailing list O

Re: [openstack-dev] [nova][qa][all] Home of rendered specs

Thierry Carrez wrote: >> specs instead of docs because docs.openstack.org >> > should only contain what is actually >> > implemented so keeping specs in another subdomain is an attempt to avoid >> > confusion as we don't expect every approved blueprint to get implemented

Re: [openstack-dev] [marconi] sample config files should be ignored in git...

On Thu, Mar 27, 2014 at 7:29 PM, Kurt Griffiths < kurt.griffi...@rackspace.com> wrote: > P.S. - Any particular reason this script wasn't written in Python? Seems > like that would avoid a lot of cross-platform gotchyas. > I think it just need to have someone stepping up doing it. Chmouel __

Re: [openstack-dev] [Ceilometer][QA][Tempest][Infra] Ceilometer tempest testing in gate

On Tue, Mar 18, 2014 at 5:21 PM, Sean Dague wrote: > So I'm still -1 at the point in making UCA our default run environment > until it's provably functional for a period of time. Because working > around upstream distro breaks is no fun. > I agree, if UCA is not very stable ATM, this os going t

Re: [openstack-dev] [Ceilometer][QA][Tempest][Infra] Ceilometer tempest testing in gate

On Tue, Mar 18, 2014 at 2:09 PM, Sean Dague wrote: > We've not required UCA for any other project to pass the gate. Is it that bad to have UCA in default devstack, as far as I know UCA is the official way to do OpenStack on ubuntu, right? Chmouel. _

Re: [openstack-dev] Moving swift3 to stackforge (was: Re: [OpenStack-Infra] Intermittent failures cloning noVNC from github.com/kanaka)

On Sat, Mar 15, 2014 at 4:28 AM, Pete Zaitcev wrote: > I think we should've not kicked it out. Maybe just re-fold it > back into Swift? > we probably would need to have a vote/chat of some sort first. Chmouel ___ OpenStack-dev mailing list OpenStack-d

Re: [openstack-dev] Replication multi cloud

On Thu, Mar 13, 2014 at 6:39 PM, Marco Fargetta wrote: > Hi Chmouel, > > using this approach should I need to have the same users in both keystone? > yes. > > Is there any way to map user A from cloud X to user B in cloud Y? > not without some changes to swsync (or other software), container sy

[openstack-dev] Moving swift3 to stackforge (was: Re: [OpenStack-Infra] Intermittent failures cloning noVNC from github.com/kanaka)

On Thu, Mar 13, 2014 at 3:44 PM, Sean Dague wrote: > In Juno I'd really be pro removing all the devstack references to git > repos not on git.openstack.org, because these kinds of failures have > real impact. > > Currently we have 4 repositories that fit this bill: > > SWIFT3_REPO=${SWIFT3_REPO:-

Re: [openstack-dev] Replication multi cloud

You may be interested by this project as well : https://github.com/stackforge/swiftsync you would need to replicate your keystone in both way via mysql replication or something like this (and have endpoint url changed as well obviously there). Chmouel On Thu, Mar 13, 2014 at 5:25 PM, Marco Fa

Re: [openstack-dev] [Nova client] gate-python-novaclient-pypy

FYI: this is all over for all clients that gates with pypy : http://logs.openstack.org/28/74328/2/check/gate-python-swiftclient-pypy/c0058f2/console.html On Mon, Mar 10, 2014 at 10:37 AM, Gary Kotton wrote: > Hi, > The client gate seems to be broken with the following error: > > 2014-03-10 08:

Re: [openstack-dev] [Nova] FFE Request: Ephemeral RBD image support

On Fri, Mar 7, 2014 at 12:30 AM, Matt Riedemann wrote: > What would be awesome in Juno is some CI around RBD/Ceph. I'd feel a lot > more comfortable with this code if we had CI running Tempest Seb has been working to add ceph support into devstack which could be a start, https://review.opensta

Re: [openstack-dev] [Neutron][FYI] Bookmarklet for neutron gerrit review

if peoples like this why don't we have it directly on the reviews? Chmouel. On Tue, Mar 4, 2014 at 10:00 PM, Carl Baldwin wrote: > Nachi, > > Great! I'd been meaning to do something like this. I took yours and > tweaked it a bit to highlight failed Jenkins builds in red and grey > other Jenk

Re: [openstack-dev] [oslo][all] config sample tools on os x

On Thu, Feb 20, 2014 at 10:22 AM, Julien Danjou wrote: > I'm pretty sure it'd be OK to use getopt in a portable way rather than > specifically the GNU version, but I had no idea if it was acceptable. If > everybody think it is, I can give it a try. > In which sort of system setup other than maco

Re: [openstack-dev] [oslo][all] config sample tools on os x

On Thu, Feb 20, 2014 at 12:17 AM, Sergey Lukjanov wrote: > tools/config/generate_sample.sh isn't working on OS X due to the getopt > usage. Any recipes / proposals to fix it? I have a workaround at least. > thanks for the workaround, I had a look on this while reporting bug https://bugs.launchp

Re: [openstack-dev] [openstack-announce] python-heatclient 0.2.7 released

On Wed, Feb 19, 2014 at 1:50 AM, Steve Baker wrote: > Changes in this release: > https://launchpad.net/python-heatclient/+milestone/v0.2.7 It is probably worth mentioning[1] that python-heatclient is now using the requests library instead of its homegrown httpclient library which should make thin

Re: [openstack-dev] pep8 gating fails due to tools/config/check_uptodate.sh

On Wed, Feb 5, 2014 at 4:20 PM, Doug Hellmann wrote: > Including the config file in either the developer documentation or the > packaging build makes more sense. I'm still worried that adding it to the > sdist generation means you would have to have a lot of tools installed just > to make the sdis

Re: [openstack-dev] Python 3 compatibility

On Mon, Feb 3, 2014 at 5:29 PM, Julien Danjou wrote: > Last, but not least, trollius has been created by Victor Stinner, who > actually did that work with porting OpenStack in mind and as the first > objective. > AFAIK: victor had plans to send a mail about it to the list later this week. Chmo

Re: [openstack-dev] [Heat] How to model resources in Heat

Zane Bitter writes: > As I said, figuring this all out is really hard to do, and the > existing resources in Heat are by no means perfect (we even had a > session at the Design Summit devoted to fixing some of them[1]). If > anyone has a question about a specific model, feel free to ping me or >

Re: [openstack-dev] Hierarchicical Multitenancy Discussion

On Tue, Jan 28, 2014 at 7:35 PM, Vishvananda Ishaya wrote: > The key use case here is to delegate administration rights for a group of > tenants to a specific user/role. There is something in Keystone called a > "domain" which supports part of this functionality, but without support > from all of

Re: [openstack-dev] Hacking repair scripts

On Tue, Jan 28, 2014 at 2:13 AM, Joshua Harlow wrote: > Thought people might find it useful and it could become a part of > automatic repairing/style adjustments in the future (similar to I guess > what go has in `gofmt`). nice, it would be cool if this can be hooked directly in th editors (ie:

Re: [openstack-dev] [requirements][oslo] Upgrade six to 1.5.2?

On Wed, Jan 22, 2014 at 11:17 AM, Julien Danjou wrote: > On Tue, Jan 21 2014, ZhiQiang Fan wrote: > > > six 1.5.2 has been released on 2014-01-06, it provides urllib/urlparse > > compatibility. Is there any plan to upgrade six to 1.5.2? (since it is > > fresh new, may need some time to test) > >

Re: [openstack-dev] a "common" client library

On Thu, Jan 16, 2014 at 8:40 PM, Donald Stufft wrote: > > On Jan 16, 2014, at 2:36 PM, Joe Gordon wrote: > > 2) major overhaul of client libraries so they are all based off a common > base library. This would cover namespace changes, and possible a push to > move CLI into python-openstackclient

Re: [openstack-dev] a "common" client library

On Thu, Jan 16, 2014 at 5:23 PM, Jay Pipes wrote: > Right, but requests supports chunked-transfer encoding properly, so > really there's no reason those clients could not move to a > requests-based codebase. > We had that discussion for swiftclient and we are not against it but unfortunately the

Re: [openstack-dev] a "common" client library

On Thu, Jan 16, 2014 at 4:37 PM, Jesse Noller wrote: > Can you detail out noauth for me; and I would say the defacto httplib in > python today is python-requests - urllib3 is also good but I would say from > a *consumer* standpoint requests offers more in terms of usability / > extensibility > FY

Re: [openstack-dev] a "common" client library

On Thu, Jan 16, 2014 at 12:38 PM, Chris Jones wrote: > Once a common library is in place, is there any intention to (or > resistance against) collapsing the clients into a single project or even a > single command (a la busybox)? that's what openstackclient is here for https://github.com/opens

Re: [openstack-dev] [oslo.config] Centralized config management

On Thu, Jan 9, 2014 at 7:53 PM, Nachi Ueno wrote: > One example of such case is neuron + nova vif parameter configuration > regarding to security group. > The workflow is something like this. > > nova asks vif configuration information for neutron server. > Neutron server ask configuration in neu

Re: [openstack-dev] [all] Organizing a Gate Blocking Bug Fix Day

On Thu, Jan 9, 2014 at 1:46 PM, Sean Dague wrote: > Specifically I'd like to get commitments from as many PTLs as possible > that they'll both directly participate in the day, as well as encourage the > rest of their project to do the same > I'll be more than happy to participate (or at least on

Re: [openstack-dev] [Nova] libvirt unit test errors

On Tue, Jan 7, 2014 at 2:28 PM, Gary Kotton wrote: > 2014-01-07 > 11:59:47.428| > Requirement already satisfied (use --upgrade to upgrade): markupsafe in > ./.tox/py27/lib/python2.7/site

Re: [openstack-dev] [Ceilometer] Dynamic Meters in Ceilometer

On Mon, Jan 6, 2014 at 12:52 PM, Kodam, Vijayakumar (EXT-Tata Consultancy Ser - FI/Espoo) wrote: > In this case, simply changing the meter properties in a configuration file > should be enough. There should be an inotify signal which shall notify > ceilometer of the changes in the config file. Th

Re: [openstack-dev] [OpenStack-Dev] IDE extensions in .gitignore

I am not sure if this is the global .gitignore you are thinking of but this > is the one I am in favor of: > > https://help.github.com/articles/ignoring-files#global-gitignore > > > Maintaining .gitignore in 30+ repositories for a potentially infinite > number of editors is very hard, and thankfull

[openstack-dev] Gate is broken right now

Hello, We currently have an issue with the grenade job due of an new release of boto. Sean was kind of enough (on his vacaion) to fix/workaround it here: https://review.openstack.org/63907 but we need to wait until some +2ers awake for the devstack-gate repos. Chmouel.

Re: [openstack-dev] [Tempest][qa] Adding tags to commit messages

On Tue, Dec 24, 2013 at 9:42 AM, Masayuki Igawa wrote: > And, how about do we the tagging about the services in the subject(1st > line)? I think it would be nice to keep the subject simple, the linux kernel have been doing this for a while which just the subsystem in the subject at first, i.e:

[openstack-dev] [testr] debugging failing testr runs

Hello, I was wondering what was the strategy to debug a failed run with tox? I was trying to see which tests was failing with python-keystoneclient and py33 and this is the type of error i am getting : http://paste.openstack.org/show/gc3xMk34ELuSF5Fk1mvP/ (bet it with tox directly or from the v

  1   2   >